(or anything display: block) and it will enclose that element, regardless of the dimensions that result from the choice of fonts. With SVG, will have specified dimensions and won't care about what you put inside, or outside, of it. 2026-04-29 07:00:53 tpbsd: guessing it's supposed to look like this? https://ibb.co/sJJpZ0zv 2026-04-29 07:00:54 One solution is to turn all your text into paths. Another is to convert the SVG to a raster image, such as PNG. http://commons.wikimedia.org/ does the latter, for instance. 2026-04-29 07:01:09 +not 2026-04-29 07:02:13 MrMobius, no it's not 2026-04-29 07:02:15 tpbsd: I gather you do have Inkscape at hand? There's a command somewhere in it to convert text into paths; try using it on everything and upload the resulting SVG - it'd likely solve the font issue. 2026-04-29 07:03:06 iv4nshm4k0v, I do and it's used by qucs to make a pdf, but github cant render it :( 2026-04-29 07:03:35 The way PDF solves this problem is the glyph spacing is deterministic and openly documented for the "default" font families, so even if you use a different "Sans Serif" it will be positioned in the same place. It also allows embedding the glyphs you used for a non-default font (in TTF for example, but only including glyphs that were used). 2026-04-29 07:03:38 iv4nshm4k0v, which is a shame as xpdf renders it fine 2026-04-29 07:04:40 Embedding TTF with the glyphs you don't need removed is a lot saner than turning the fonts into paths 2026-04-29 07:05:04 My understanding of the standard is that it makes embedding non-standard glyphs /mandatory./ PDF that uses glyphs outside of the 'standard' Adobe fonts without embedding them is non-conforming. IIRC, anyway. 2026-04-29 07:05:41 Yes you're right, I didn't meant to imply otherwise 2026-04-29 07:05:49 tpbsd: But you can get the .svg out of Qucs, right? Load it into Inkscape, convert text into paths, upload the resulting SVG to the website, check if it renders ok everywhere? 2026-04-29 07:06:30 iv4nshm4k0v, qucs does pdf and other picture formats no problems 2026-04-29 07:06:54 iv4nshm4k0v, ok, Ill try that now 2026-04-29 07:07:00 The point of PDF is to get the same vector images to appear portably on any computer or printer. 2026-04-29 07:07:12 This should have been the goal of SVG... but for some reason it wasn't 2026-04-29 07:07:20 I guess because it was leaning on the existing HTML tech 2026-04-29 07:07:41 Yep. 2026-04-29 07:07:43 Regarding fonts anyway, the rest of SVG is portable I think 2026-04-29 07:08:05 But everyone wants text in their SVGs, not surprisingly, so it's not a minor thing 2026-04-29 07:09:04 I also can't help notice rendering of SVGs is really slow compared to equivalent PDFs 2026-04-29 07:09:17 Might be lack of interest or something, or it's just fundamentally slower 2026-04-29 07:10:52 The primitives are mostly all the same. I guess the XML library might be slow, for some reason? 2026-04-29 07:10:52 Other than that, my browser supports neither SVG nor PDF, so I'd have to download the schematics either way. However, all my output devices are strictly raster, so I kinda appreciate if a pre-rasterized version is available alongside the original vector graphics, such as how Commons does it. 2026-04-29 07:13:59 iv4nshm4k0v, I cant find a "convert text into paths," menu or command 2026-04-29 07:15:10 A quick DDG search suggests it's Path -> Object to Path. 2026-04-29 07:20:29 https://raw.githubusercontent.com/techman00172/schematics/refs/heads/main/moped-batt-chgr-inkscape.svg 2026-04-29 07:20:55 I might be misremembering, but I think that Kicad uses its own "technical drawing" fonts anyway, so when the schematics / PCB layout is exported to SVG or PDF, all the text is drawn as paths straight away. About the only downside I can think of is that such text is not searchable, though I think it's possible to put "invisible" text alongside the paths? OCRed PDFs do it like that, AIUI? 2026-04-29 07:21:00 can anyone please check that SVG, see if it renders ok, is test outside the boxes ? 2026-04-29 07:22:10 iv4nshm4k0v, kicad isnt among my favorites, but I guess I'll have to test it out soon for doing this purpose 2026-04-29 07:23:54 I don't quite suggest you to switch (I haven't used it in a few years myself, and no idea how well it works these days), but rather that it might be a feature to suggest to the developers of whatever tool(s) you actually use. 2026-04-29 07:25:11 iv4nshm4k0v, kicad is heavil developed and has the best capabilities of any FLOSS pcb cad for sure, but I never liked it 2026-04-29 07:25:55 I was kinda-sorta paid to use it; I've found it acceptable. 2026-04-29 07:30:35 iv4nshm4k0v, oh, I'm not critisizing kicad, Ive seen some fantastic boards designed with it. The problem is me, Im too set in my ways 2026-04-29 07:31:07 iv4nshm4k0v, Ive been using PCB (part of geda) for the last 20 years 2026-04-29 07:31:58 iv4nshm4k0v, someone checkedt the post incad processed file and the text is still overflowing 2026-04-29 07:32:24 I'm not going to spend more time on it 2026-04-29 07:35:32 I'm in the process of rebuilding my "big" containers so have no software to deal with SVG at hand right now. But I've downloaded the .svg file and see it uses a lot. Which text overflows? 2026-04-29 07:36:12 the text in the two boxes at the top of the image 2026-04-29 07:50:52 Hard to tell up from bottom when you look at the SVG file with less(1). Regardless, the texts I see there - coded as rather than paths - are: TL431, R2, R=10 kOhm, R3, R=2.2 kOhm, R4, R=10 kOhm, dc simulation, DC1, battery, U=12.6 V, T_2N2907_1, R7, R=1 kOhm, R6, R=4.7 kOhm, SCR, V2, U=17 V, R8, R=1 kOhm, D1N5711_1, transient, simulation, TR1, Type=lin, Start=0, Stop=2 ms, 2026-04-29 07:50:52 Limiting_Resistor_10W, R=5 Ohm, generator, ref, 0, 1m, 2m, -20, -15, -10, -5, 0, 5, 10, 15, Time, v(generator), v(ref), Volts, time: 213.572u, tran.v(generator): 14.5, time: 1.320m, tran.v(generator): 1.43, time: 286.848u, tran.v(ref): 0.268. There're a couple of fairly large (code-wise) elements, which I guess were the text converted into paths. 2026-04-29 07:52:44 he and veltas both saw the same problem, tho veltas windows was ok 2026-04-29 08:00:24 Sounds strange. Don't have the appropriate tools to investigate further ATM; will try to take another look at it later. 2026-04-29 08:01:42 iv4nshm4k0v, it's not important! do something more important to you :)) 2026-04-29 08:09:53 Vector graphics is kinda important to me. One of my earliest interests in computing, in fact. I pretty much learned matrix algebra back some 30+ years ago so I can understand vector graphics. 2026-04-29 08:12:44 ahh 2026-04-29 08:13:25 the SVG from qucs is as large as a png file, it doesnt seem very efficient 2026-04-29 08:15:58 Might depend on the resolution, for the PNG file. Laser printers do 600 dpi, and at that resolution, PNGs might become fairly bulky. Or it might not; http://users.am-1.org/~ivan/misc-2026/sfn.jwuV6E_kya-bDmZbN_G0mpjQuSMXlg9qt5ehp1Bzigk.png I've mentioned before turned out to be not that large. (Though it's a 600 dpi 1-bit-per-pixel image.) 2026-04-29 08:17:53 iv4nshm4k0v, the qucs print and image functions are very primitive, few options 2026-04-29 08:17:58 (Learned the /basics/ of matrix algebra, anyway.) 2026-04-29 08:17:58 As to Forth, another curious thing about Pygmy is that it defines NOT as an alias to 0=. Then, it suggests "-1 XOR" for "standard" NOT. And yet it also has "COM," in its built-in assembler (for the 8086 "NOT" opcode), allowing for (presumably much faster) CODE COM BX COM, NXT, END-CODE . 2026-04-29 08:49:05 That's like old Forths 2026-04-29 08:49:59 NOT is 0= as a logical operator and CPL was sometimes available to do -1 XOR 2026-04-29 08:50:48 And old Forths sometimes used 1 as the 'true' flag instead of -1 2026-04-29 09:10:13 Pygmy was modelled after cmForth, which is both old (1987), and designed by someone who wasn't all that big fan of standardizing Forth. But anyway, using -1 - unlike "non-zero" (like in, say, C, Perl, or Ecmascript) has the advantage of not needing separate sets of "logical" and "bitwise" operations; in C, 1 && 2 is true, but 1 & 2 is false. And Forth ops can't "short-circuit," either. 2026-04-29 09:10:13 Also, using 0 / -1 allows, in certain cases, to replace conditionals with bitwise arithmetics; say, flagvar && 123 can be written as FLAGVAR @ 123 AND (rather than FLAGVAR @ IF 123 ELSE 0 THEN .) ISTR some dialects of BASIC allowed for the same. Probably there were other languages back in the day following the same logic. (Contrast with how we have 0, NULL and false in C23, for some reason.) 2026-04-29 09:22:23 Whether you use 1 or -1 you can use the binary operators as logical operators ... except CPL/INVERT, which I think is why NOT was added as a special case for those old Forths 2026-04-29 09:22:39 And in later standards they avoided NOT as a name because nobody could agree on what that should do 2026-04-29 09:23:43 I often defined : NOT 0= ; just because I think it's a lot more readable, and it's trivial to do this on any Forth, so we all get to write it how we want it 2026-04-29 09:24:26 If the author of pygmy doesn't like standardising Forth then they're in good company, I think most of us don't like the standard even if we use it 2026-04-29 09:25:56 It's rather the author of cmForth who didn't (and, at a guess, still doesn't) like Forth standards. Pygmy's author followed the example... though I suppose he wasn't too big a fan, either. 2026-04-29 09:26:38 Sorry yeah 2026-04-29 09:26:48 -1 I don't like because it makes defining logical operators like < a little longer in assembly, but it's not a big deal 2026-04-29 09:27:44 Just adds an EAX DEC, or similar 2026-04-29 09:27:55 I guess, so long that 1 / -1 are used consistently, bitwise and logic operations can coincide. But like I've said, -1 allows for the use of bitwise operations in place of conditionals. And one another thing to keep in mind is that IF is 'zero' / 'non-zero'. 2026-04-29 09:30:31 Somehow, it reminds me that to get numerical addition in Ecmascript, you have to use "- -" rather than "+": x - - y is always arithmetical, while x + y concatenates strings if at least one of its arguments is a string. 2026-04-29 09:31:30 That's normal for relational/equality/logical to output specific values and the 'if' to be permissive, makes checking flags easier 2026-04-29 09:32:09 I.e. FLAGS MY-FLAG AND IF rather than FLAGS MY-FLAG AND 0<> IF 2026-04-29 09:33:05 Yep. 2026-04-29 09:33:27 What's weird is how we have all these low level languages and none of them seem to ever admit that stuff like carry/sign flags exist 2026-04-29 09:34:01 I guess they were waiting for RISC-V to come out... although you could just as easily simulate these bits on RISC-V if someone wanted them 2026-04-29 09:34:56 Although credit to Forth.... I'm not aware of another lang that exposes mixed multiplication/division in its standards 2026-04-29 09:35:41 It'd be hard to preserve flags between calls to Forth words. Like, say, 1 2 + DUP - would the flags be preserved after DUP? What if DUP itself needs arithmetics to correctly update the stack? 2026-04-29 09:36:28 I guess you could make sure the bits are preserved in NEXT and then have a word you use immediately after an arithmetic op that pushes the current flags 2026-04-29 09:37:07 In RISC-V you'd need to just use a special arithmetic word or your kernel would be really slow 2026-04-29 09:38:22 It's probably easier for all Forths to just add some special arithmetic words that pushes the result and the flags 2026-04-29 09:39:58 Haven't familiarized myself with RISC-V yet, so no idea how it fits there. At a guess, adding flag semantics to Forth would complicate the language beyond what's most Forthwrights find comfortable. 2026-04-29 09:40:23 It would make implemeting D+ et al easier 2026-04-29 09:40:51 Yeah it doesn't need to be standard but I'm surprised that it doesn't seem to be done in the wild 2026-04-29 09:42:26 RISC-V doesn't have arithmetic/bit flags 2026-04-29 09:43:28 Well, that much I do know. I /did/ read the Wikipedia article at one point. 2026-04-29 12:57:59 Yeah, apparently they do it with explicit value checking on the basis that it reduces the number of pipeline stalls. I guess they believe that winds up being faster in most cases. 2026-04-29 13:02:29 gahh one problem with starlink 'standby' speed is that firefox takes 20 minutes to update 2026-04-29 13:02:44 veltas: I've also always found it odd that the flags are never considered in most HLLs. 2026-04-29 13:08:55 My impression was that C in particular was initially intended to be a "very close hardware fit." You'd have thought they'd have covered... well, all of the hardware. 2026-04-29 13:09:48 Seems like a worthwhile time to mention this paper again: 2026-04-29 13:09:51 https://spawn-queue.acm.org/doi/pdf/10.1145/3212477.3212479 2026-04-29 13:11:26 I remember being pretty surprised when I learned that even assembly language in an x86 isn't really "directly controlling the hardware." 2026-04-29 13:12:54 I immediately lusted for an ability to microcode the thing, but then discovered later that that's not really a thing - apparently there's only a small bit of space for "firmware upgrades" that work as an adjunct to mostly ROM-based microcode that can't be changed. So it's really only an ability to do patches - not full replacements. 2026-04-29 13:13:49 I assume that "patch space" functions like a cache. 2026-04-29 13:16:32 Yeah x86 isn't very hardware-friendly anyway 2026-04-29 13:16:51 And was never intended to be 2026-04-29 13:17:10 Was initially meant to be programmer and application friendly, and later it was just backwards-compatibility friendly 2026-04-29 13:20:40 Doesn't Thinking Forth have a bit that says you shouldn't write ." !" and should write [CHAR] ! EMIT 2026-04-29 13:20:51 Or maybe it was a Rather book 2026-04-29 13:21:34 I don't explicitly remember that being in Thinking Forth, but it's been a LONG time since I've read it. 2026-04-29 13:21:48 I think it's dumb though, just write ." !" 2026-04-29 13:21:51 It's shorter and clearer 2026-04-29 13:22:30 I guess it just depends on what you value, speed or readability. 2026-04-29 13:23:15 You could have your compiler check for single-character ." instances. 2026-04-29 13:25:52 I doubt there are a lot of situations where ." !" will impact performance 2026-04-29 13:25:56 But I guess the "things you could have your compiler do" is a pretty slippery slope. 2026-04-29 13:26:09 I agree. 2026-04-29 13:26:19 It's premature optimisation, I would say 2026-04-29 13:27:10 Especially on desktop where e.g. my EMIT is basically >R RP@ 1 TYPE R> DROP 2026-04-29 13:27:17 I don't care much for that phrase. Not because I object to the idea - I think premature optimization is "a thing." I think the argument gets invoked to often, though - I've had people accuse me of it when what I'm really doing is trying to plan my design carefully. 2026-04-29 13:27:45 There's usually a "critical core bit" of a design, and trying to get that as right as possible doesn't quality as premature optimization in my mind. 2026-04-29 13:27:47 It also depends on how your EMIT is implemented. On an MCU, EMIT might be a primitive that interacts with built-in UART directly, with TYPE implemented on top of it. On a Unix Forth, TYPE would be a primitive that calls write(2), and EMIT would be more or less what veltas said. 2026-04-29 13:28:00 s/quality/qualify/ 2026-04-29 13:28:45 iv4nshm4k0v: Doesn't depend though, in that case EMIT is significantly slower than the overhead of calling TYPE, so the ." should be the same speed as EMIT 2026-04-29 13:28:51 Because the limiting factor is UART 2026-04-29 13:29:08 KipIngram: I think here, where we're writing code that's harder to read for very questionable performance gains is exactly what we mean by premature optimisation 2026-04-29 13:29:41 I think the argument against ." in the book might have been about saving space, rather than time 2026-04-29 13:29:55 I usually do mine the other way around anyway - I build EMIT on top of TYPE instead of vice versa, because generally I am making a system call and I don't want to be doing the syscall on every single character of a TYPE. 2026-04-29 13:30:41 I agree again - but the part I'm referring to as the "critical bit" of a design is usually right at the HEART of the performance. 2026-04-29 13:31:07 For example, in Forth the inner interpreter. You absolutely want that to be as efficient as possible. 2026-04-29 13:31:36 Because ." would be ... what (.") STRING, instead of LITERAL EMIT and I guess STRING, would need a full word for size, and then bytes, so would be 2 bytes larger 2026-04-29 13:31:40 In a classic forth anyway 2026-04-29 13:33:24 Anyway, I just have a bit of an emotional factor going re: "premature optimization," because some of the times I've been hit with that argument I definitely do NOT feel like what I'm doing is premature. Rather it feels like the most important part of my early planning. 2026-04-29 13:33:42 But like I said, I do think it's really common for folks to fall into actual real premature optimization. 2026-04-29 13:33:45 veltas: When an MCU has a built-in UART, a lone EMIT would boil down to just writing the value to an IO port or IO memory location. It doesn't have to actually wait while the data is being pushed off the hardware shift register. Repeated EMITs would have to wait, though. 2026-04-29 13:33:53 MOST of your code just isn't going to be performance critical. 2026-04-29 13:35:05 Depends on what you're trying to achieve. Granted, choosing hardware where most of your code /does/ end up being performance-critical sounds rather unwise. 2026-04-29 13:35:30 So if perf mattered then we'd presumably be sending many EMIT's, so it would have to wait for a non-full FIFO on average 2026-04-29 13:35:56 assuming the I/O isn't strictly ordered 2026-04-29 13:37:36 The point might be to reduce latency, or it might be to free up the MCU to do other important things as quickly as possible. 2026-04-29 13:37:38 I think the flip-side of "premature optimization" is "premature coding." 2026-04-29 13:38:12 There are plenty of programmers that just sit down and start hammering out code without really thinking their problem through. And often they're the ones that get praise for being "really fast coders." 2026-04-29 13:40:02 I just really don't think it's code smell to write ." !" I think writing [CHAR] ! EMIT without good reason is more smelly 2026-04-29 13:41:17 But I wouldn't judge anyone either way 2026-04-29 13:41:39 I tend to think that it's going to be fairly rare for I/O to be the performance bottleneck anyway. But that may just be a reflection of the applications I tend to think about. 2026-04-29 13:43:42 The counterargument there seems to be your editor - you're going to be pushing large amounts of text out to the screen, and it's nice if the screen can update fast. Ideally too fast to see happen. 2026-04-29 13:43:47 I'd be inclined to write $21 EMIT, but only because I mainly think of Forth as a 'small machine' programming language. Equivalently, in C, I'd putc ('!') or, on AVR, UDR = '!'. 2026-04-29 13:43:54 It's the bottleneck if you're printing a lot of bang characters 2026-04-29 13:45:19 So I set mine up the way I did because I just cared more about getting strings out fast than about getting single characters out fast. 2026-04-29 13:46:35 iv4nshm4k0v has a point - if you're sitting on Linux you're going to wind up calling a function that is string oriented anyway. 2026-04-29 13:47:10 And the real overhead is getting in and out of that function, since it's a system call. 2026-04-29 13:48:10 putc() puts the '!' character in a buffer unless the buffer's full, only then does it call write() 2026-04-29 13:49:07 I don't use the C library, though. 2026-04-29 13:51:14 Unless buffering is disabled with setvbuf(3). 2026-04-29 13:53:24 Yes although that's probably always a bad idea 2026-04-29 13:53:57 Well, if NetBSD's setvbuf(3) page is to be believed, stderr is unbuffered by default. (Also, it should've been putchar, or putc ('!', stdout).) 2026-04-29 13:57:24 The standard says stderr should not be fully buffered at the start of the program 2026-04-29 13:57:30 I.e. could be unbuffered or line buffered 2026-04-29 13:58:29 I would have guessed it was line buffered since I've never seen broken-up lines of stderr, but I don't know how feasible that would really be if it was unbuffered 2026-04-29 13:58:58 And also I use Linux mostly 2026-04-29 14:00:08 setvbuf's Linux man page says it's unbuffered too 2026-04-29 14:04:30 So if two threads print to stderr at a similar time you'll get two messages randomly mashed together 2026-04-29 14:04:38 Progress indicators are commonly done with something like fprintf (stderr, "\r%d%% done", percent); - i. e., with 'incomplete' lines. 2026-04-29 14:05:06 Commonly followed by fflush() which is faster than turning buffering off completely 2026-04-29 14:05:16 I would guess, but I have been wrong before 2026-04-29 14:07:57 I would be averse to writing to a single FILE *, or a file descriptor, from more than one thread (perhaps a dedicated one for logging, or progress reporting) myself. That said, unless a given FILE * call results in attempting to write more than a pageful of data, that should end up being done in a single write(2). 2026-04-29 14:07:57 I. e., unbuffered fputs ("Foo bar!\n", stderr) is ought to be more or less the same as write (2, "Foo bar!\n", 8); . 2026-04-29 14:08:14 stderr really is for logging though 2026-04-29 14:08:29 I guess the fix is just setvbuf it to line buffered if you want to do this 2026-04-29 14:13:20 True fputs might not do that 2026-04-29 14:13:45 And I guess depending on how sophisticated your fprintf is it won't automatically send it one character at a time 2026-04-29 14:15:59 I guess I'd need to take a look at libc sources, but I kinda suspect that "unbuffered" is a misnomer: I rather expect that the buffer gets flushed on every output library call. 2026-04-29 14:17:32 You're right about that 2026-04-29 14:17:51 But I'm wondering how many of the higher-level calls devolve into calling fputc repeatedly 2026-04-29 14:18:09 I could imagine an early printf being implemented that way, it's how printf() was first implemented 2026-04-29 14:18:58 But looking it up the modern printf() is optimised for unbuffered streams, I would guess this was done ages ago to make stderr work properly 2026-04-29 14:19:16 So it will attempt to write to a temporary buffer and *then* write the whole thing 2026-04-29 14:20:50 On other hand... it's a bit sad, this all makes these functions much more complicated 2026-04-29 14:21:07 And that was actually the problem that the stream buffering was trying to solve in the first place 2026-04-29 14:21:58 Because in e.g. early B there was no concept of this buffering, so each output function would handle its own buffers to achieve decent performance 2026-04-29 14:33:08 veltas: svg is for images, not documents, Scalable Vector Graphics. It was made to be scalable because they are paths and some kind of instructions to draw the thing instead of the thing itself 2026-04-29 14:33:48 with the web is cool because you can apply css to those individual paths and mess with them with js, idk to what extent though 2026-04-29 14:34:11 i never used them, but they seem to be the best for logos and buttons that you are going to animate 2026-04-29 14:34:54 for example gitlab's logo has a hover css style applied to it so it enlightens the path your cursor is in 2026-04-29 14:35:25 also with fonts i have seen people doing some tricks 2026-04-29 14:37:08 veltas: about the documentation, you were expecting a tutorial instead of explanation of the internals? 2026-04-29 14:40:06 that's the documentation i wrote 2026-04-29 14:40:09 https://gitlab.com/ohmycat/oh 2026-04-29 14:40:17 still think documenting it is a waste of time 2026-04-29 14:41:23 I had some feedback for you the other day but forgot it 2026-04-29 14:41:33 Because you left before I had a chance to feed it back 2026-04-29 14:41:45 :0 2026-04-29 14:42:21 now you have a repl to play with 2026-04-29 14:42:35 I think I was going to say I think your Forth is an ITC Forth 2026-04-29 14:42:41 might be a bit buggy and is not a standalone repl, i made it to evaluate random code while the app is running 2026-04-29 14:43:06 I think it should not be considered a forth though 2026-04-29 14:43:27 Okay your 'environment' uses ITC 2026-04-29 14:43:56 i guess it is, it's just function references all the way 2026-04-29 14:44:36 i should provide the words word 2026-04-29 14:45:14 I'm not sure I expected anything in particular, re whether it was tutorial or explanation of internals 2026-04-29 14:45:23 Explanation of internals is more interesting to me probably 2026-04-29 14:45:39 Tutorial might have been interesting too since your lang is so different to what I'm used to 2026-04-29 14:45:47 You seem to have a bit of a mix of both 2026-04-29 14:46:19 i added the words word 2026-04-29 14:46:45 i was thinking about an interactive tutorial 2026-04-29 14:46:52 playing with the dom and the canvas might be cool 2026-04-29 14:47:12 Interactive tutorials are popular for web stuff, too 2026-04-29 14:47:12 make-canvas 'red fill-style 0 0 32 32 rectangle 2026-04-29 14:58:19 haha, my AI hates Kicad and Qucs for sims, loves xschem, it describes Kicad simulator as "an afterthought" 2026-04-29 14:59:35 do you guys like rpn calculators? 2026-04-29 14:59:44 so looks like I'll be spending my time learning Xschem for a while 2026-04-29 15:00:17 vms14, I like RPN in Forth but can use either in a calculator 2026-04-29 15:00:19 i saw people supposedly making money by selling an rpn calculator on google play store 2026-04-29 15:00:45 and i have been training to make rpn calculators for years it seems 2026-04-29 15:01:05 also it is a "useful" application for someone i guess 2026-04-29 15:01:11 maybe there is some money to be earnt there! 2026-04-29 15:01:34 i don't think is the best way to make money, but it's something i seem to have been training for xd 2026-04-29 15:02:35 the problem in the west is that china will copy overnight and sell it for 1/2 our price because they have the best supply chains 2026-04-29 15:03:28 there is no point making something like that to sell in the west, china is now the worlds factory, they absolutely won that war 2026-04-29 15:04:08 we had best stick to digging up minerals and tourism, or livestock etc 2026-04-29 15:08:34 we can always buy from china and resell 2026-04-29 15:09:21 yeah, thats definitely a good idea, you get reliable supply and well made gear 2026-04-29 15:09:39 "well made" 2026-04-29 15:09:50 so well made that it dismantles 2026-04-29 15:09:56 it works well for EEVS in Australia where the Chinese want an agent to resell their cars 2026-04-29 15:10:01 hahah 2026-04-29 15:10:37 I have some very hitech, well made chinse gear, but yeah there is cheap junk available 2026-04-29 15:16:16 It's like Seiko, they make the cheapest watches out there and also some of the best and more expensive watches 2026-04-29 15:17:04 Well I won't say "most expensive watches" because there are watchmakers who sell a piece for a million euros but on planet earth... 2026-04-29 15:18:04 I've never seen a watch that I'd ever want to wear that costs more than like 20K 2026-04-29 15:18:17 And that's overpriced 2026-04-29 15:39:08 vms14: I like RPN calculators! 2026-04-29 15:39:42 vms14: have you seen Free42 or the DM42? 2026-04-29 15:42:10 MrMobius: i'll check now 2026-04-29 15:42:42 https://thomasokken.com/free42/ 2026-04-29 15:43:32 i was looking a video about the TI36x Pro because it seems some people love it 2026-04-29 15:43:41 https://www.reddit.com/r/StructuralEngineering/comments/zo0ex4/why_do_structural_engineers_in_particular_prefer/ 2026-04-29 15:44:38 i saw a cool video about an old one 2026-04-29 15:45:33 https://youtu.be/DneXoSq0L2M 2026-04-29 15:45:56 hp 97 S I/O 2026-04-29 15:46:48 i was thinking about reading the manual of one and trying to make an emulator 2026-04-29 15:46:59 and then sell it and get rich :D 2026-04-29 15:48:04 i'm thinking on something that would allow you to create your own buttons either as a sequence of other buttons or as code in my toy lang 2026-04-29 15:48:24 but i should try to replicate an existing one 2026-04-29 15:49:16 all that sounds good except the get rich part :) 2026-04-29 15:49:21 :/ 2026-04-29 15:49:36 that was the most interesting part 2026-04-29 15:49:54 there are a lot of emulators out there. making your own would be really fun 2026-04-29 15:50:18 you might make some money if you release it as a kit 2026-04-29 15:50:33 someone made or ported an HP41 emulator to an AVR and was selling kits not too long ago 2026-04-29 15:52:24 the good points are that a calculator is already a useful application and that while i have no interest in math, i have interest in rpn langs and i would have no problem adding a stack and make buttons that operate on it 2026-04-29 15:52:54 wonder if i'll end with rpn scratch 2026-04-29 15:53:08 physical buttons you mean? 2026-04-29 15:53:22 virtual, in a web app 2026-04-29 15:53:41 but i can map whatever the keyboard has like numbers and + - / etc 2026-04-29 16:48:13 nice 2026-04-29 17:48:25 i have this and i'm already bored xd 2026-04-29 17:48:27 https://ohmycat.gitlab.io/oh/oh.html 2026-04-29 17:48:55 and yes i should add the enter so you can input numbers higher than 9 2026-04-29 17:52:44 it could get interesting if i add sequences, then it is programming with buttons