2024-06-12 00:59:50 <KipIngram   > veltas: So I was looking at that link you posted.  What is the idea behind uxn, anyway?  I've seen references to it a number of times.  Is it intended to run on some kind of bare metal, or is it some sort of a low-level "add on" to a more standard os?  Or both?  It just seems kind of primitive and I'm not sure what the "culture" around it is.
2024-06-12 02:22:51 <crc         > uxn is a portable virtual computer that 100rabbits created to provide a platform for their work. It runs on a bunch of systems, both bare metal and hosted.
2024-06-12 02:24:39 <crc         > From what I've gathered, they used to do iOS development and web stuff, and now build for their own platform.
2024-06-12 02:25:36 <crc         > https://100r.co/site/uxn_design.html has some details on this
2024-06-12 04:03:04 <KipIngram   > I think I may have seen a presentation video he did one time.  I see all the bits on the site veltas linked about living on a boat, and the guy that did this video lied on a boat.  A lot of the same sort of "frugal living" type stuff.
2024-06-12 04:04:12 <KipIngram   > s/lied/lived/
2024-06-12 08:16:47 <veltas      > I think it's meant for fun / creativity
2024-06-12 08:17:09 <veltas      > Not dissimilar to what a lot of us are doing
2024-06-12 09:26:58 <jackdaniel  > KipIngram: I think that the missing keyword is "sustainable computing", i.e a computing abstraction that may be bootstrapped by a single person. very much like forth
2024-06-12 10:20:51 <veltas      > I enjoy the frugality and the sustainability aspects too
2024-06-12 10:21:04 <veltas      > I'm frugal myself, well not quite as frugal...
2024-06-12 13:18:35 <KipIngram   > Yes, I find those interesting things to "observe vicariously."  Same as you, I like to try to "live simply" in some ways, but nowhere near that hard core.
2024-06-12 13:20:30 <KipIngram   > He seems also interested in "preserving past computational accomplishments."  That also strikes me as a good thing that we probably don't pay enough attention to overall.
2024-06-12 13:21:27 <KipIngram   > I watched a video last night on game ROM sites, which Nintendo has tried very hard to go after legally.  Far from being interested in preservation, Nintendo's attitude seems to be "unless we can make money from it, we'd rather just eradicate it from the world."
2024-06-12 13:25:49 <KipIngram   > I've always had a preference for software applications that store their data in human readable files.  I did a printed circuit board layout once using the PCB layout tool from gEDA (which is just called "PCB")  I decided late in the project that I wanted to change the geometry of my vias, and I had a LOT of them scattered around.
2024-06-12 13:26:20 <KipIngram   > PCB offered no way to do that en masse, but it stored the layout in an ASCII file, so I was able to use a global search and replace from an editor on that file, and the job was done.
2024-06-12 13:26:33 <KipIngram   > That wouldn't have been possible with a binary format.
2024-06-12 13:32:14 <KipIngram   > I think in a lot of cases the choice for binary is born from a desire to keep cntrol - they want to create a closed ecosystem and lock you into it.  If you can actually read the app's file format, you might do soemthing you didn't need them for, and that can't be allowed.
2024-06-12 13:32:20 <veltas      > Or alternatively a document binary format
2024-06-12 13:32:24 <veltas      > documented*
2024-06-12 13:32:41 <KipIngram   > Yes, that's almost as good.
2024-06-12 13:32:56 <veltas      > Bit harder to change but documented binary is better than nothing, almost as good as text, and necessary for many things
2024-06-12 13:32:58 <KipIngram   > And if the file is very large might be better / more efficient.
2024-06-12 13:33:11 <veltas      > e.g. PDF is 'text', but it's not really because it's full of compressed raw data streams
2024-06-12 13:33:23 <KipIngram   > Right.
2024-06-12 13:33:32 <veltas      > But it's still useful and e.g. can be converted to plain text format entirely by open source tools
2024-06-12 13:33:35 <veltas      > Because it's got specs
2024-06-12 13:33:43 <KipIngram   > One of the cases I really wish had been approached differently was FPGA configuration bit streams.
2024-06-12 13:33:49 <KipIngram   > I really wish those were documented.
2024-06-12 13:34:00 <KipIngram   > I'm sure we'd have all kinds of groovy third part tools if they were.
2024-06-12 13:34:07 <KipIngram   > s/part/party/
2024-06-12 13:34:48 <KipIngram   > In the early days of programmable logic, when we just had "PAL" chips, the format was either documented or painfully obvious.
2024-06-12 13:36:14 <KipIngram   > There would be a picture in the databook that showed a big grid of fuses you used to form your AND/OR map, and the binary file was literally just the bit values of those fuses, in sequence by rows.
2024-06-12 13:36:50 <KipIngram   > I've done a little work recently with pdf files and creating them.
2024-06-12 13:36:53 <veltas      > Has nobody reverse engineered this stuff?
2024-06-12 13:37:16 <KipIngram   > I wrote a report generator that takes the performance data from one of my test jobs and automatically creates a pdf file and a spreadsheet.
2024-06-12 13:37:28 <GeDaMo      > https://github.com/YosysHQ/icestorm
2024-06-12 13:37:42 <KipIngram   > I didn't delve as far into the pdf format as you've been - I just used a python module for it.
2024-06-12 13:37:47 <veltas      > The original PDF spec is a plain text spec that acts like a binary format, and performs much gymnastics to achieve binary format properties like random-access
2024-06-12 13:38:02 <KipIngram   > Not completely, I don't think (if you're talking about the config bit stream).
2024-06-12 13:38:05 <veltas      > And it makes you wonder why they bothered, if they were going to add a spec anyway
2024-06-12 13:38:42 <veltas      > I mean there's many cross-references that have fixed decimal number byte offsets of relevant objects in the file, at the end of the file
2024-06-12 13:39:08 <GeDaMo      > "GitHub - YosysHQ/icestorm: Project IceStorm - Lattice iCE40 FPGAs Bitstream Documentation (Reverse Engineered)"
2024-06-12 13:39:14 <veltas      > This is ludicrously more complicated/bloated than it would be if the offsets were simply 32-bit little endian numbers in a binary format
2024-06-12 13:39:43 <KipIngram   > GeDaMo - that is nice to see.
2024-06-12 13:39:50 <GeDaMo      > That's the only one I know of
2024-06-12 13:39:50 <veltas      > You've got all these key/value dictionaries, would rather just pack it with binary, would be much shorter
2024-06-12 16:03:36 <lf94        > Is there a Forth debugger?
2024-06-12 16:04:12 <lf94        > Basically always showing data stack, return stack, dictionary and heap
2024-06-12 16:04:40 <veltas      > Not a standard one
2024-06-12 16:04:44 <lf94        > Another question: is there some idiomatic way to say "conditional comment" ?
2024-06-12 16:05:02 <lf94        > Basically I have a bunch of tests after each word. I've been commenting them out with \
2024-06-12 16:05:09 <veltas      > https://www.complang.tuwien.ac.at/forth/gforth/Docs-html/Debugging.html
2024-06-12 16:05:19 <lf94        > I was thinking of creating a \? which becomes a comment if some global is true
2024-06-12 16:05:26 <veltas      > [if] [then]
2024-06-12 16:05:30 <lf94        > (maybe \! to set it)
2024-06-12 16:05:42 <lf94        > [if][then] is not as nice as writing
2024-06-12 16:05:46 <lf94        > \ at each line
2024-06-12 16:06:21 <lf94        > Should it be ?\ or \? you think
2024-06-12 16:08:03 <lf94        > I guess a step-through forth debugger is on my list of "to do"...
2024-06-12 16:11:15 <thrig       > or make the test code more distinct so it doesn't need to be manually twiddled
2024-06-12 16:32:20 <veltas      > lf94: ?\ is better
2024-06-12 16:32:28 <crc         > lf94: I've been (slowly) working on a debugger for my retroforth system. It has stack display, heap pointer display, string previews (for temporary strings), watching variables. Doesn't show return stack though.
2024-06-12 16:32:43 <veltas      > because you're doing a conditional comment, the condition comes before the comment is parsed
2024-06-12 16:33:40 <veltas      > : ?\ if 0 parse 2drop then ;  \ if you're not supporting blocks
2024-06-12 16:34:21 <veltas      > If you're supporting blocks personally I wouldn't bother with line-comments and would do : ?( if [char] ) parse 2drop then ;
2024-06-12 16:39:53 <veltas      > lf94: Adding a debugger is sort of trivial for non-STC forths because you can overwrite the NEXT routine to jump to debugging code
2024-06-12 16:40:16 <veltas      > For STC forths you would need to rely on the CPU's debugging features, which is very platform-specific
2024-06-12 16:40:53 <veltas      > In my experience CPU debugging features are relatively easy to use though, I can't speak for how easy they are to use on top of an OS though
2024-06-12 16:41:01 <GeDaMo      > I seem to remember an example where : was changed to add a value which was incremented every time the word was called for a simple profiler
2024-06-12 16:42:16 <veltas      > Looks like x86 debug registers are manipulated directly from userspace
2024-06-12 16:42:23 <lf94        > crc that sounds great
2024-06-12 16:42:29 <veltas      > So it's just as easy to write debugger on OS as it is baremetal
2024-06-12 16:42:53 <lf94        > Im surprised gforth doesn't have a debugger
2024-06-12 16:42:59 <lf94        > just that debug call
2024-06-12 16:43:28 <crc         > lf94: https://asciinema.org/a/CNoarrRX19lH1OhLOb1TJDhGr is a short demo
2024-06-12 16:43:34 <veltas      > That might be old documentation
2024-06-12 16:44:00 <veltas      > But I agree with what they said, that a debugger is mostly unnecessary in forths
2024-06-12 16:45:09 <lf94        > crc frickin' exactly :)
2024-06-12 16:47:40 <veltas      > Very nice crc
2024-06-12 16:54:23 <KipIngram   > I also think one can get by fine without a debugger in Forth, but I do plan one nonetheless.  I see it as potentially adding "convenience" to the debugging process.
2024-06-12 16:54:52 <KipIngram   > I don't know if I'll make use of special hardware features, though - I think I want something that's portable across platforms.
2024-06-12 16:58:01 <lf94        > Quality of life is a nice thing
2024-06-12 16:58:03 <lf94        > :)
2024-06-12 16:58:19 <lf94        > Plenty of times I've just wanted to "watch the stacks" but have to do it manually...
2024-06-12 16:58:37 <KipIngram   > In the past I've been able to do any debugging I needed to do just by pushing some simple word through my code.  It somehow lets me know it ran but doesn't "do anything" that affects my app code.
2024-06-12 16:58:50 <KipIngram   > Sometimes it just prints the item on the TOS without dropping it.
2024-06-12 16:59:08 <KipIngram   > Very early in a system's development, though, it might just "quit."  As in exit to the OS.
2024-06-12 16:59:26 <KipIngram   > The "debug info" then being "did I segfault or not?"
2024-06-12 17:01:43 <KipIngram   > lf94: Yes, I know what you mean.  What I think I'll wind up doing is use the Linux "alt screen" for my debug display.  So the primary screen will reflect what the app is doing; the alt screen will have the debug info.  And I'll be able to hotkey between them.
2024-06-12 17:04:12 <KipIngram   > I t hink it would be awfully nice if I could have a window into the source code there on the debug screen and have it indicate where the current execution point was, literaly in my code as typed.  I haven't really given thought to how hard it might be to achieve that, though.
2024-06-12 17:04:39 <KipIngram   > And then if you had the "common in debuggers" "step over" and "step into" options, you'd be in a pretty good situation, I think.
2024-06-12 17:04:57 <KipIngram   > Maybe "execute" and "execute into" are better phrases.
2024-06-12 17:05:13 <KipIngram   > "execute through" / "execute into"
2024-06-12 17:25:51 <veltas      > It's easy to add a breakpoint to ANY forth if the code is modifiable, just overwrite breakpoint with debug code
2024-06-12 17:25:57 <veltas      > And replace when it executes the debug
2024-06-12 17:26:59 <KipIngram   > Yep.
2024-06-12 17:27:47 <KipIngram   > I think I'd like the debugger to give me an accelerated way to do that.  If I solve that thing about mapping the compiled code in RAM to the source nicely.
2024-06-12 17:31:51 <KipIngram   > You know, it occurs to me that one thing I haven't given much thought to is debugging in a multi-thread environment.  I guess I'd like to be able to track that - for example be able to single-step more than one thread.  Then I could manually cause things to happen in whatever order I preferred, etc. to look for tricky thread sync bugs.
2024-06-12 17:33:34 <veltas      > I think usually with threads the breakpoint is 'global' and first thread to hit it stops
2024-06-12 17:33:45 <veltas      > So you just need to be able to handle entering debug code from any thread
2024-06-12 17:33:56 <veltas      > I don't think that should usually be too bad
2024-06-12 17:35:38 <KipIngram   > Yeah, I don't think it will be particularly difficult to handle (no more difficult than the overall thing, that is).  I just had never explicitly considered it before.
2024-06-12 17:35:50 <KipIngram   > Anyway, this work is well out in the future for me.
2024-06-12 17:36:32 <KipIngram   > I still think the way I want to start is to write an emulation of my vm, and set up to be able to develop Forth code for it on my notebook.
2024-06-12 17:37:03 <KipIngram   > I want everything OTHER than that emulation layer to be "binary portable," except where I'm coding for per-platform hardware.
2024-06-12 17:41:38 <veltas      > I think my opinion on this the easiest way to get a sort of 'VM' that's relatively 'portable' is just using a Forth, rather than actually having a VM
2024-06-12 17:41:42 <veltas      > And it will probably run faster
2024-06-12 17:41:53 <veltas      > And consider your 'Forth kernel' the VM
2024-06-12 17:42:33 <KipIngram   > I'm not 100% sure on the speed issue yet.  I've tinkered with the low-level code for it on x86 and there are reasons I think it could rival the speed of my prior Forths.
2024-06-12 17:42:55 <KipIngram   > Primarily because each fetch of a code cell from RAM gets me five or six vm opcodes.
2024-06-12 17:43:10 <KipIngram   > But that may not make that much difference once the code cells are all in cache.
2024-06-12 17:43:31 <KipIngram   > At any rate, I'm interested in trying the approach out at least once.
2024-06-12 17:44:04 <KipIngram   > My alternative would be indirect threaded, so that would be the speed I'd be comparing to.
2024-06-12 17:49:51 <veltas      > Yeah speed isn't my main concern, I just expect even a dumb STC forth to run a bit faster, and also be more natural to write
2024-06-12 17:50:25 <veltas      > Because forths are weird to write in stack-based vm's, for some reason
2024-06-12 17:50:36 <veltas      > I find it makes a lot more sense writing them on a normal CPU
2024-06-12 17:55:42 <olle        > https://github.com/olleharstedt/olleharstedt.github.io/blob/master/code/reportdsl/forthlike2.php#L18 - making some nice progress with my Forth-like DSL
2024-06-12 17:55:53 <olle        > I'm using set-php and set-sql to use php and sql dictionaries
2024-06-12 17:56:04 <olle        > sql dict create strings, php dict run codes directly
2024-06-12 18:02:42 <lf94        > veltas: maybe ill write something on top of gforth
2024-06-12 18:03:00 <lf94        > I can redefined : right?
2024-06-12 18:03:09 <lf94        > and use the old : in the redefinition
2024-06-12 18:04:25 <GeDaMo      > If necessary, you can do : old: : ; and then : : ... old: ... ;
2024-06-12 20:08:46 <dlowe       > IIRC, Adobe made encodings for Postscript called Type 1 and Type 3 (not sure where Type 2 went).  Type 3 was just postscript, but Type 1 was an obfuscated encoding used to protect proprietary fonts
2024-06-12 20:08:50 <dlowe       > PDF eventually grew out of the Type 1 format
2024-06-12 20:08:56 <dlowe       > I learned Postscript when it first came out, so there's my forth lineage :D
2024-06-12 20:10:21 <veltas      > Nice
2024-06-12 20:11:17 <veltas      > lf94: Yeah in any normal forth you can write : :
2024-06-12 20:11:34 <veltas      > Writing something on top of gforth sounds like a really good idea
2024-06-12 20:12:06 <veltas      > Too often people will focus on writing their own forth, not realising writing a forth is quite different to writing a forth application
2024-06-12 20:12:24 <veltas      > And you'll probably do a better job writing a forth after having some experience writing forth applications anyway
2024-06-12 20:13:07 <veltas      > But that temptation is always there because writing a forth is indeed as easy as it looks, and only has a handful of real hurdles
2024-06-12 20:37:46 <lf94        > nice
2024-06-12 20:38:13 <lf94        > yes I'm huge on actually using languages
2024-06-12 20:38:17 <lf94        > instead of toy shit
2024-06-12 22:15:31 <traveler    > I feel like I'm in the minority as someone who likes writing applications and isn't that interested in writing a forth.
2024-06-12 22:23:33 <KipIngram   > I'm interested in eventually writing applications, but I do quite love tinkering with the machinery.
2024-06-12 22:26:22 <lf94        > traveler: welcome to the minority B)
2024-06-12 22:34:35 <KipIngram   > traveler: At some point I want to build a full system from scratch (fpga processor, my own video and storage hardware, etc.) and write all the software for it, from the bare metal up.
2024-06-12 22:35:16 <KipIngram   > It's fun building Forths on top of an OS, but by the time it's time to do something with them  you're faced with living under the native OS and that just seems to "taint" the process so much the joy goes out of it.