2024-08-18 00:00:01 <KipIngram   > I think "establishment" fits better - yeah.  Power seekers come in all stripes.
2024-08-18 00:41:27 <xentrac     > zelgomer: in if x @ 0 > x @ limit < then foo fi bar the containing if fi keeps the < or > from going past bar
2024-08-18 00:41:44 <xentrac     > veltas: the conduct of the Python Steering Committee was appalling
2024-08-18 00:45:55 <amby        > you could always have an option for destructive or non-destructive comparisons
2024-08-18 00:46:01 <amby        > the issue then becomes naming them
2024-08-18 01:55:54 <xentrac     > darkling: it seems clear that Tim didn't break the rules; https://chrismcdonough.substack.com/p/the-shameful-defenestration-of-tim gives the alternative point of view.  what he was doing was publicly debating a policy proposal, and there was no way to debate that policy proposal without doing the things they banned him for
2024-08-18 01:59:45 <zelgomer    > amby: that's what KipIngram does. i like to minimize my word set, though.
2024-08-18 02:01:47 <zelgomer    > regarding the python thing, again i just want to reiterate how ridiculous punitive suspension is in an open source project. it basically amounts to "we're upset by something you said, so we're going to withhold your free work from our users for three months."
2024-08-18 02:02:11 <xentrac     > oh, they're not suspending his code
2024-08-18 02:02:25 <xentrac     > they're suspending his participation in the governance structure
2024-08-18 02:02:35 <xentrac     > debating and voting on stuff
2024-08-18 02:03:28 <xentrac     > making proposals
2024-08-18 02:04:37 <zelgomer    > i thought python was a programming language
2024-08-18 02:05:39 <zelgomer    > this is like some hoa shit. just write your code and stop governing wtf
2024-08-18 02:05:47 <xentrac     > haha yeah
2024-08-18 02:06:18 <xentrac     > the problem is that these structures give power and influence to people who spend their time fighting
2024-08-18 02:24:40 <xentrac     > I learned last night that there's a new fourth edition of "Inside F83": https://www.forth.org/OffeteStore/1003_InsideF83.pdf
2024-08-18 02:24:43 <xentrac     > as of 12 years ago
2024-08-18 02:26:00 <xentrac     > (because I was wondering what kind of Forth would be best for running on FreeDOS, and so I looked at F83 and F-PC)
2024-08-18 02:27:45 <unjust      > https://www.holonforth.com/holon86.html here's another, i haven't used this more than installing it once and admiring the interface
2024-08-18 02:53:07 <xentrac     > it does look nice, but how close is it to Forth 2012?
2024-08-18 02:57:38 <xentrac     > ascii A of ReadPortA endof makes it look somewhat close but probably incompatible.  is ascii state-smart?
2024-08-18 03:00:01 <xentrac     > HolonForth's interface is pretty close to Smalltalk's browser, although sort of a defining feature of Smalltalk is that you can have many of those open at once
2024-08-18 03:01:44 <unjust      > i doubt it's very standard friendly
2024-08-18 03:03:25 <xentrac     > aha, https://www.holonforth.com/index.html says, "I admired the hierarchical presentation of classes in Smalltalk and wondered how the source browser could be applied to procedural source."
2024-08-18 03:03:45 <xentrac     > on the surface it doesn't look far from ANS 94
2024-08-18 03:10:31 <xentrac     > it seems like the only documentation of its Forth dialect is in `strings holon86.tex | less`
2024-08-18 03:16:30 <xentrac     > ah, it does have char and [char] so maybe it would be fine
2024-08-18 03:16:58 <xentrac     > the documentation for ascii says, "Alias for CHAR and [CHAR], state-smart, not ANS Forth but convenient."
2024-08-18 03:18:10 <xentrac     > so it seems like he was trying for ANS compliance insofar as it makes sense for a Forth system that doesn't compile a stream of source code
2024-08-18 03:19:28 <unjust      > if you have it running: in Help, Chapter: Develop, Section: Forth, Paragraph: ANS-Forth
2024-08-18 03:19:38 <xentrac     > ...but HolonForth doesn't implement value
2024-08-18 03:19:43 <unjust      > "Holon follows the ANS Forth standard."
2024-08-18 03:19:58 <unjust      > with some extra text, but i'd have to type the rest of it out
2024-08-18 03:20:27 <xentrac     > it does have at-xy
2024-08-18 03:20:46 <unjust      > are you hoping to run wmaze on dos?
2024-08-18 03:20:51 <xentrac     > yes
2024-08-18 03:21:03 <unjust      > there is gforth for dos btw
2024-08-18 03:21:10 <unjust      > but the last version i saw was 0.5.0
2024-08-18 03:21:21 <xentrac     > also pfe
2024-08-18 03:21:31 <unjust      > you also need an extra binary for dpmi
2024-08-18 03:22:00 <xentrac     > I think wmaze needs about 9K of RAM on a 16-bit Forth
2024-08-18 03:22:34 <xentrac     > what would be cooler would be running wmaze on UEFI
2024-08-18 03:22:37 <xentrac     > or BIOS
2024-08-18 03:23:52 <unjust      > don't know of a forth compiler with an 8086 backend
2024-08-18 03:25:23 <unjust      > i wonder if 4tH supports generation of PE executables out of the box though
2024-08-18 03:25:32 <xentrac     > not familiar with 4tH
2024-08-18 03:25:53 <xentrac     > it wouldn't be very surprising if someone had ported one of the MS-DOS Forths to run on BIOS or UEFI though
2024-08-18 03:26:12 <unjust      > true
2024-08-18 03:28:00 <xentrac     > somehow I had forgotten, if I ever knew, that F83 ran on CP/M-80 and the 68000 as well
2024-08-18 03:28:04 <unjust      > i wonder how viable it would be to implement just enough of the required INT 21h functions, plus some code to make sense of the MZ format, in part of something like SeaBIOS
2024-08-18 03:28:06 <xentrac     > I found that out last night
2024-08-18 03:28:55 <unjust      > though i guess if you do that, you might as well just tack that real mode onto your own pbr
2024-08-18 03:29:07 <unjust      > s/real mode/& code/
2024-08-18 03:29:10 <xentrac     > MBR?
2024-08-18 03:29:27 <unjust      > that would work too, was thinking of partition boot record
2024-08-18 03:29:34 <xentrac     > oh!
2024-08-18 03:30:40 <unjust      > seabios is pretty easy to work with though, i've used gdb to debug it via qemu for boot stuff
2024-08-18 03:30:47 <xentrac     > I haven't looked at it at all
2024-08-18 03:31:30 <unjust      > http://thebeez.home.xs4all.nl/4tH
2024-08-18 03:31:32 <xentrac     > the 8080 thing is kind of mindblowing, right?  F83 provided virtual memory, multitasking, an IDE with a (clumsy) screen editor, and a semi-high-level scripting language on a processor that was hardly more than a pocket calculator, in 64K of RAM
2024-08-18 03:31:49 <unjust      > definitely impressive
2024-08-18 03:32:09 <unjust      > i've never used an 8080
2024-08-18 03:32:26 <unjust      > the closest i got was an 8085
2024-08-18 03:32:50 <xentrac     > my H8 had an 8080 IIRC, but mostly I used an H89 with a Z80 in it
2024-08-18 03:33:12 <unjust      > ah ok
2024-08-18 03:33:26 <xentrac     > I wrote my first game in BASIC-80 on the Z80
2024-08-18 03:33:30 <xentrac     > it sucked
2024-08-18 03:33:50 <xentrac     > that was probably 01990
2024-08-18 03:34:11 <unjust      > author of 4tH also does youtube occassionally: https://www.youtube.com/@HansBezemer
2024-08-18 03:34:57 <unjust      > btw, why the leading zero on years? :)
2024-08-18 03:36:01 <xentrac     > oh, it's just https://longnow.org/ideas/long-now-years-five-digit-dates-and-10k-compliance-at-home/
2024-08-18 03:36:16 <unjust      > ah
2024-08-18 03:36:29 <unjust      > i see a leading 0 and expect octal
2024-08-18 03:37:11 <xentrac     > yeah.  maybe here I should say #01990
2024-08-18 03:37:38 <xentrac     > ;)
2024-08-18 03:39:23 <xentrac     > hmm, this is interesting: 4tH segregates "integers" into a separate "integer segment" from the "temporary storage" in the "character segment"
2024-08-18 03:40:18 <xentrac     > I wonder how that works with code like create foo 3 , 4 , 1 c, 17 c,
2024-08-18 03:44:50 <unjust      > dunno, should be interesting to compile that and look at what it produces
2024-08-18 03:46:15 <unjust      > i'm following 4.2 @ https://thebeez.home.xs4all.nl/4tH/4tHmanual.pdf
2024-08-18 03:49:20 <unjust      > and if you pull down the source via svn, it seems that the current version uses "4th.src" instead of the "example" directory listed in this manual
2024-08-18 03:51:42 <unjust      > i was sort of expecting those "segments" to be segments or sections with a binary
2024-08-18 03:52:44 <unjust      > if i tell 4th to (G)enerate the romans.scr example, it outputs some C source and {CodeSegment,StringSegment} are file scope char arrays
2024-08-18 03:53:14 <unjust      > s/with a binary/within a binary/
2024-08-18 03:53:35 <unjust      > (B)uild seems to generate what i'm guessing the manual calls H-code?
2024-08-18 03:56:33 <unjust      > $ cat /tmp/hoax.scr
2024-08-18 03:56:33 <unjust      > CREATE FOO 3 , 4 , 1 C, 17 C,
2024-08-18 03:56:34 <unjust      > ." OK?"
2024-08-18 03:56:56 <unjust      > here're the resultant CodeSegement and StringSegment arrays
2024-08-18 03:57:02 <unjust      > static dict CodeSegment [] = { {'\x5b',           3L}, {'\x5b',           4L}, {'\x05',           2L}
2024-08-18 03:57:05 <unjust      > };
2024-08-18 03:57:08 <unjust      > static char StringSegment [] = { '\x01', '\x11', '\x4f', '\x4b', '\x3f', '\x00'
2024-08-18 03:57:09 <unjust      > };
2024-08-18 04:01:51 <xentrac     > so it placed 1 and 17 at the beginning of the StringSegment
2024-08-18 04:02:00 <unjust      > followed by "OK?"
2024-08-18 04:02:20 <unjust      > i also tried doing some basic addition followed by dot
2024-08-18 04:02:23 <unjust      > 33 22 + .
2024-08-18 04:02:33 <xentrac     > and the 3 and 4 ended up in the code segment?  do they get put into the integer segment at startup?
2024-08-18 04:02:58 <unjust      > not sure, i don't see any mention of an IntegerSegment yet
2024-08-18 04:03:33 <xentrac     > I was thinking that for a dynamically-typed memory-safe Forth I'd have to put the 3, 4, 1, and 17 in the same region, contiguously
2024-08-18 04:04:04 <xentrac     > a more interesting case is create bar 32 allot  create foo bar , 4 , 17 c,
2024-08-18 04:05:00 <xentrac     > which illustrates the problem for memory-safety: you can c! into the region named by foo, but for type-safety that needs to not turn the bar pointer into a wild pointer that can corrupt memory
2024-08-18 04:06:18 <xentrac     > but it's fine if it turns it into, say, an integer
2024-08-18 04:06:26 <unjust      > would you still have normal pointers exposed in that setup?
2024-08-18 04:06:49 <unjust      > or would pointers basically be some sort of reference record/structure that refers to an actual location?
2024-08-18 04:07:29 <xentrac     > pointers would consist of a region and an offset
2024-08-18 04:08:00 <unjust      > type agnostic?
2024-08-18 04:08:30 <xentrac     > mostly, but dynamically distinguishable from integers, which is a kind of typing, just not a static kind
2024-08-18 04:08:54 <xentrac     > I was thinking, and maybe this is stupid, of putting the region in the low 32 bits and the offset in the high 32 bits; then an integer could be represented as an offset into region 0
2024-08-18 04:09:20 <unjust      > ok
2024-08-18 04:10:25 <unjust      > what if you use the MSB and allow for 63-bit integers?
2024-08-18 04:10:43 <unjust      > ie. if MSB is set then the remaining bits are the int
2024-08-18 04:10:54 <xentrac     > also totally reasonable, and checking for overflow might be no more difficult
2024-08-18 04:11:53 <unjust      > would having what might sometimes be the sign bit shifted left by 1 be much of nuisance?
2024-08-18 04:11:58 <unjust      > s/left/right/
2024-08-18 04:12:25 <xentrac     > dunno, I'd have to try it to be sure
2024-08-18 04:12:37 <xentrac     > the Forth 2012 standard says each create creates a new region, so by bounds-checking pointer arithmetic or pointer accesses you could not only prevent access to one object from corrupting another, you could dynamically detect a lot of bugs
2024-08-18 04:12:45 <xentrac     > this is super helpful in Python IME
2024-08-18 04:13:58 <xentrac     > the most common place for such tag bits (ever since the 68020 anyway) is the LSBs; that's what I used for them in Ur-Scheme
2024-08-18 04:14:05 <xentrac     > and what Emacs and OCaml use
2024-08-18 04:15:47 <unjust      > ok
2024-08-18 04:17:36 <xentrac     > I feel like integer overflow is fairly uncommon even in 32 bits (32-bit Emacs hits it at 27 bits IIRC)
2024-08-18 04:21:15 <unjust      > unless you're counting down and the loop termination condition isn't set to stop at 0?
2024-08-18 04:22:51 <xentrac     > well, signed integer overflow
2024-08-18 04:24:12 <xentrac     > funny thing, I learned last night that F83 implemented do loop with offset binary, so the loop ends when the sign bit changes crossing $8000.  I don't think I've ever seen offset binary used before
2024-08-18 04:24:21 <xentrac     > i.e., excess-32768
2024-08-18 04:25:52 <unjust      > interesting
2024-08-18 04:27:31 <unjust      > have you got the source? or the disassembly?
2024-08-18 04:28:58 <unjust      > i think i've seen some turbo pascal produced binaries do some branching/looping based on sign and carry, but i didn't have the original source, and where it occurred was not in the TPU/library code itself from what i remember
2024-08-18 04:30:41 <unjust      > ie. the disassembly at least had conditional jumps scattered amongst arithmetic without a preliminary cmp/test instruction
2024-08-18 04:46:13 <unjust      > "F83 provides a solution by using three numbers on the return stack to handle the indexing and looping. The number at the bottom of the three is the address of the word right after LOOP, providing LEAVE with the return address to terminate the looping."
2024-08-18 04:46:33 <unjust      > "The second number is the loop limit, offset by 8000H so that the index range from 0 to FFFFH becomes contiguous. The top number is the difference between the index and the limit, also offset by 8000H."
2024-08-18 04:47:06 <unjust      > "At the end of the loop, LOOP increments the top number on the return stack by either one or the amount specified in the case of +LOOP, and tests for overflow from bit 14 to bit 15. The overflow condition occurs when the 8000H boundary is crossed from either direction."
2024-08-18 04:47:34 <unjust      > "Therefore, both the positive and negative increments are handled correctly with a single run-time loop routine."
2024-08-18 12:45:33 <MrMobius    > One trick that uses to work on windows and probably still does is you could add whatever bytes you like to the end of an executable file
2024-08-18 12:47:19 <MrMobius    > So one way of making a "compiler" is to create a template program that reads any excess data at the end of its own file and interprets it. "compilation" is just copying the template and adding source or bytecode to the end
2024-08-18 12:48:54 <GeDaMo      > I believe that early versions of Turbo Pascal used a trick to simplify linking where they would copy the start of the IDE executable which contained the standard library to the target then just append the compiled program
2024-08-18 12:49:34 <MrMobius    > that's slick
2024-08-18 12:50:59 <MrMobius    > I have been slightly annoyed that most forths can't generate executables. I guess it's no worse than python and other scripting languages
2024-08-18 12:52:15 <user51      > Not related, but that reminded me of a hack I did maybe 12 years ago on Windows: Skype was forcing itself to auto-update, so I found out where it downloads the update, then replaced it with a blank file that had the same name.  No more auto-updates  :)
2024-08-18 12:52:53 <MrMobius    > there was a presentation on a forth for the HP-100LX which I think does create binaries but with the whole interpreter which isn't ideal. I think you could make words as referenced or not and only include those
2024-08-18 12:53:13 <MrMobius    > Hehe nice
2024-08-18 12:57:03 <user51      > MrMobius: How would the executable work?
2024-08-18 12:57:27 <MrMobius    > make=mark
2024-08-18 12:57:35 <MrMobius    > user51: what do you mean?
2024-08-18 12:58:27 <GeDaMo      > user51: the binary would be an interpreter, threaded or byte code would be appended
2024-08-18 12:59:22 <user51      > MrMobius: Well, maybe a better question would be what would be the result of a generated executable?  Wild guess, a clone of the the generating forth with its current state?
2024-08-18 13:02:13 <user51      > GeDaMo: Sounds reasonable, but that goes against the DIY spirit  :P  Wouldn't that be rather unportable?
2024-08-18 13:03:57 <GeDaMo      > Pfft! This is ##forth ! :P
2024-08-18 13:06:56 <MrMobius    > you could clone the whole forth but I like the idea of only including what you need
2024-08-18 13:08:04 <MrMobius    > which is harder than it sounds unless you stick to some rules and dont break them
2024-08-18 13:09:01 <MrMobius    > something like ' DUP , is tough if the address of DUP will change at link time since other words will be excluded changing its start address
2024-08-18 13:10:20 <user51      > Maybe every word could be redefined as itself, as in : dup dup ; but I can't promise anything.
2024-08-18 13:10:34 <MrMobius    > anyway, I've thought a lot about building a kind of nonstandard forth where it saves all your word definitions as strings so you can edit them and then figures out what to reconfigure
2024-08-18 13:11:41 <user51      > Stringly typed, literally  :D
2024-08-18 13:12:18 <MrMobius    > Hehe
2024-08-18 16:43:47 <user51      > Is there any meaningful or practical distinction between "desktop" forths and "CPU" forths?  "desktop" would refer running a forth on say, Windows or Linux.  "CPU" forth would be a forth implemented in assembler.
2024-08-18 16:53:35 <GeDaMo      > Desktop Forths can also be written in asm, I'm assuming you mean bare metal, no OS
2024-08-18 16:54:14 <unjust      > i think the only real difference is how much reliance your implementation has on other programs to perform system initialization and peripheral/resource abstraction
2024-08-18 16:55:21 <GeDaMo      > You might need some words for accessing specific hardware e.g. in and out instructions on x86
2024-08-18 17:00:58 <user51      > How'd I forget about jonesforth  :|
2024-08-18 17:01:03 <user51      > <<< send this guy back to lisp  :D
2024-08-18 17:03:02 <xentrac     > I think I do have the F83 source lying around somewhere, but what I was reading was C. H. Ting's book you were quoting from
2024-08-18 17:06:04 <xentrac     > MrMobius: I feel like a lot of times that I'd like to do things in a low-level language like Forth I'd also like things like small executables with minimal dependencies
2024-08-18 17:07:17 <xentrac     > F83 does have a metacompiler for regenerating the F83 executable, and F-PC has a cousin target compiler TCOM
2024-08-18 17:08:21 <unjust      > i'm interested in using high level languages as macro assemblers
2024-08-18 17:08:36 <unjust      > for that goal of generating small executables with minimal dependencies
2024-08-18 17:11:06 <xentrac     > I think in some Forth target compilers you have to do ' dup a, rather than ' dup , so that the target compiler knows to compile a reference to the xt rather than just an integer constant.  But that's not really any different from linking in C, or even generating addresses in PIC machine code
2024-08-18 17:12:06 <xentrac     > MrMobius: you may be aware that the first Forths Chuck Moore did in the 60s and 70s had word definitions as strings
2024-08-18 17:13:02 <xentrac     > yeah, I think one reasonable way to use Forth is as a scripting language for assembly
2024-08-18 17:13:33 <xentrac     > if you look at macro assemblers of the 60s like MIDAS, they were often fairly capable scripting languages
2024-08-18 17:15:39 <xentrac     > the LISP 1.5 sources in MIDAS we have keep the Lisp symbols in a hash table, to which INTERN adds things at runtime, but to initially build the hash table, there was a second implementation of the hashing algorithm in the MIDAS macro language which hashed the predefined symbols at assembly time
2024-08-18 17:16:48 <xentrac     > vaguely relatedly, I implemented https://nullprogram.com/blog/2023/09/30/ last night in bed on my phone, in C (using ed as unjust had suggested, which really wasn't much different from doing it in vim)
2024-08-18 17:18:33 <xentrac     > to understand better the differences between that hash trie structure (which heavily depends on mutability) and https://en.wikipedia.org/wiki/Hash_array_mapped_trie, which is FP-persistent and therefore perhaps more suitable for a Forth dictionary (where you want to be able to forget or marker)
2024-08-18 17:20:10 <amby        > forth is a macro assembler
2024-08-18 17:20:23 <amby        > or at least, one of the ways to arrive at forth is by extending a macro assembler
2024-08-18 17:21:30 <GeDaMo      > If you're bootstrapping, it's probably easier to write a Forth than a full assembler
2024-08-18 17:22:36 <amby        > i made an assembler for avr in forth not too long ago
2024-08-18 17:22:54 <amby        > because all the other avr assemblers are terrible
2024-08-18 18:20:03 <xentrac     > dunno, a full assembler isn't that hard to write, unless you're trying to fully cover a large instruction set
2024-08-18 18:21:01 <xentrac     > it's easier for some instruction sets than others
2024-08-18 18:21:15 <xentrac     > amby: what deficiencies did you want to correct?
2024-08-18 18:38:29 <unjust      > xentrac: was ed better or worse than vim on the phone for the way you code?
2024-08-18 18:59:45 <xentrac     > I'm not sure, I was surprised that it wasn't much worse
2024-08-18 19:00:20 <xentrac     > not sure if it was better, maybe
2024-08-18 19:00:27 <xentrac     > I did have to adjust to it a bit
2024-08-18 19:02:02 <xentrac     > because I realized, for example, that I was going to want to #include <stdlib.h> and return a different type from the function and change the type of a variable
2024-08-18 19:02:37 <xentrac     > doing that in insert mode was inconvenient so I wrote a comment about it
2024-08-18 19:02:50 <xentrac     > and then after I left insert mode I went back and made the changes
2024-08-18 19:03:34 <xentrac     > I had an amusing moment when I replaced an expression and forgot to backslash &
2024-08-18 19:04:08 <xentrac     > regular expressions in ed are doing a lot more work than they are in things like vim or Emacs
2024-08-18 19:04:42 <xentrac     > probably be interesting to translate Pike's super-small regex subset example code in C to Forth
2024-08-18 19:38:50 <MrMobius    > xentrac: interesting. how does the compiler/linker go back and fix the integers laid down with a, ?
2024-08-18 19:40:17 <MrMobius    > You could lay down an ID number then go back and fix them but that doesn't work so well if you've done math on the result of '
2024-08-18 21:02:44 <xentrac     > MrMobius: it needs some kind of ID symbol, yeah.  as I understand it, the only math Forth 2012 guarantees you can do on the result of ' is >body, which the target compiler can also handle specially
2024-08-18 21:55:38 <xentrac     > the usual way a linker works is that it has one or more blobs of machine code, and a list of "relocations", which generally consist of (symbol, relocationtype, blobpointer)
2024-08-18 21:56:30 <xentrac     > so it builds a symbol table and walks through the list; for each relocation in the list, it looks up the symbol in the symbol table and modifies the blob of machine code at the place indicated by the blobpointer using the symbol value in a way indicated by the relocationtype
2024-08-18 22:02:26 <xentrac     > in a case like , where you're just poking a pointer into an array, what it does is very simple: either just overwrite the cell pointed to with the symbol value, so it becomes a pointer to it, or add the symbol value to it (in which case those bytes need to be zero beforehand for this case, but which can also handle things like fixing up PC-relative offset fields)
2024-08-18 22:04:10 <xentrac     > but commonly there are a variety of other relocation types you need depending on your instruction set.  A cell-sized PC-relative field is pretty simple to handle, but for example especially on 64-bit you might have short jump instructions with an offset field smaller than an entire cell, and you need a different relocation type for those
2024-08-18 22:07:29 <xentrac     > and on SPARC, for example, the CALL instruction has a two-bit opcode field and a 30-bit subroutine address field, which is PC-relative but also counted in 32-bit words (because you can't jump to an arbitrary byte offset; SPARC instructions have to be cell-aligned)
2024-08-18 22:08:26 <xentrac     > so, if the symbol value is a byte address (as it normally is!) the linker has to shift it right by two bits, so it needs a special relocation type for that.  other SPARC relocation types put just the high 16 bits or the low 16 bits of a pointer into an instruction
2024-08-18 22:08:49 <xentrac     > MrMobius: is that helpful?  I don't want to overwhelm you with information you're only marginally interested in