2025-05-18 17:06:40 <user51      > Doing some easy stuff http://0x0.st/8v7X.forth
2025-05-18 17:08:16 <user51      > The isalpha is there because I wrote it in C first.  There's some fancier solutions in the thread, but it seems to me that anything fancier than a simple recursive approach is a bit of an injustice.
2025-05-18 18:31:38 <vms14       > user51 weren't you making your own forth?
2025-05-18 18:37:30 <user51      > vms14: I was always rewriting it from scratch because the code never quite felt right.  Basically, lots of little experiements and (rewritten) refinements to the code and my own understanding.  Eventually I ended up writing more or less the same code every rewrite and felt like I was getting dimnishing returns.
2025-05-18 18:40:17 <vms14       > yeah that's normal
2025-05-18 18:40:39 <vms14       > you have to learn what you are doing and that requires you to experiment
2025-05-18 18:41:17 <vms14       > you don't know how many times I have rewritten my abomination just to abandon it eventually xd
2025-05-18 18:41:34 <vms14       > but in some way it was worth because I learned and saw stuff
2025-05-18 18:42:25 <user51      > vms14: I also felt like the write-compile-repeat loop was a bit uninteractive, plus the compilation step felt somewhat redundant - if I'm writing another one my next shot would be a mix of FS 3IF and jonesforth.  I've mentioned a 'live assembler' before but never written one.
2025-05-18 19:13:57 <vms14       > being able to create code words in assembly on the repl must feel badass
2025-05-18 19:14:24 <vms14       > well I guess it feels like a mad scientist laughing while the world burns
2025-05-18 21:08:16 <MrMobius    > it probably feels scary
2025-05-18 21:08:24 <MrMobius    > since your REPL is about to crash
2025-05-18 21:22:35 <anthk_      > I'd like jonesforth if it used -1 as true
2025-05-18 22:57:35 <veltas      > I prefer 1 as true
2025-05-18 22:58:54 <veltas      > Because it is easier to generate 1 as the 'true' result in assembly on most archs, and potentially 'faster'
2025-05-18 23:01:26 <veltas      > The only bitwise op that is different to a logical op with 1 is "NOT" which I've been writing as 0= the whole time anyway because it's shorter to write and more tolerant of input vs INVERT
2025-05-18 23:06:19 <veltas      > The FORTH79 standard used 1 as 'true', and FORTH83 and later use -1
2025-05-18 23:07:08 <anthk_      > ah, but there aren't many Jupiter Ace's in use :p
2025-05-18 23:07:39 <vms14       > I would love to have one I guess
2025-05-18 23:07:51 <anthk_      > there's canace and xace
2025-05-18 23:07:54 <anthk_      > as emulators
2025-05-18 23:07:57 <vms14       > meh
2025-05-18 23:09:07 <anthk_      > http://jupiter-ace.co.uk/usermanual.html
2025-05-18 23:09:12 <veltas      > Who is responsible for FORTH-83 being so bad?
2025-05-18 23:09:50 <vms14       > I was actually reading a forth book that mentions people getting upset with 83 for making confusing and unnecessary changes
2025-05-18 23:09:54 <anthk_      > bad, why?
2025-05-18 23:09:56 <veltas      > It's weird how many things are better in FORTH-79, or at least things that just shouldn't 'break' between standard revisions
2025-05-18 23:10:52 <veltas      > Well they redefined 'true' to -1 instead of 1, and changed divison to floored instead of symmetric division, etc.
2025-05-18 23:11:28 <veltas      > FORTH-79 is closer to how actual mainstream CPU architectures work today, to further cement my opinion
2025-05-18 23:14:11 <vms14       > btw the book I'm reading is forth: a text and reference
2025-05-18 23:14:27 <vms14       > although I'm just starting it, but I like it so far
2025-05-18 23:17:28 <veltas      > The stack items tend to be numbered from 1, so PICK using 1-indexing makes sense there.  I.e. 1 PICK is the 1st stack item, 2 PICK is 2nd, etc.
2025-05-18 23:18:42 <vms14       > but memory and do loop and I assume other things start with 0
2025-05-18 23:18:52 <vms14       > so in this case it makes it a bit more consistent I guess
2025-05-18 23:19:02 <vms14       > that might be the reason?
2025-05-18 23:19:22 <veltas      > Lack of consistency is a defining trait of Forth
2025-05-18 23:19:31 <vms14       > about the -1 I have no idea why
2025-05-18 23:19:46 <veltas      > e.g. >IN doesn't put something in the 'IN stack' or move anything
2025-05-18 23:20:08 <vms14       > I did not feel forth to be inconsistent, but I'm just a noob so I cannot really say much
2025-05-18 23:20:27 <vms14       > php is inconsistent, more like a joke than a language
2025-05-18 23:20:38 <veltas      > I personally think 1 PICK getting 1st stack item makes sense
2025-05-18 23:20:51 <veltas      > I think you could do it either way, but when you pick one you need to keep it
2025-05-18 23:21:05 <veltas      > And that's the issue with FORTH-83, it started on a bad foot by changing so many of the words
2025-05-18 23:21:20 <anthk_      > starting forth needs a new PDF edition with ANS-Forth
2025-05-18 23:21:41 <veltas      > Starting FORTH 2nd edition is for ANS Forth I think?
2025-05-18 23:21:55 <vms14       > the book I mentioned shows the difference in both 83 and 79 when it explains a word
2025-05-18 23:21:57 <veltas      > That's the copy I have, and it's probably easier to find second hand copies of that
2025-05-18 23:22:32 <anthk_      > the online shared PDF is not, it's from 1981
2025-05-18 23:22:51 <veltas      > That's 1st edition
2025-05-18 23:22:53 <anthk_      > they have a web, and I mirrored it with wget but is not as portable
2025-05-18 23:23:32 <veltas      > How did you do a bitwise NOT operation in FORTH-79, did you have to do  -1 XOR  ?
2025-05-18 23:24:39 <vms14       > who has actually used forth 79? :0
2025-05-18 23:24:52 <vms14       > the only forth I have available is gforth and maybe pforth
2025-05-18 23:25:12 <veltas      > Someone in here was working with Jupiter ACE code which is close to FORTH-79
2025-05-18 23:25:13 <anthk_      > vms14: pforth here trye
2025-05-18 23:25:27 <anthk_      > too*
2025-05-18 23:25:51 <anthk_      > veltas: you can be really close by reading the manuals, they add missing words
2025-05-18 23:25:56 <vms14       > btw how can I bind the xlib.h library with gforth? I need to give it -l and -I directives
2025-05-18 23:26:03 <anthk_      > place it into a tape file and I wil be fine
2025-05-18 23:26:07 <anthk_      > vms14: system
2025-05-18 23:26:08 <anthk_      > ?
2025-05-18 23:26:20 <anthk_      > -I /usr/X11R6/include at openbsd
2025-05-18 23:26:51 <anthk_      > and -L /usr/X11R6/lib
2025-05-18 23:27:01 <vms14       > yeah but how I give those flags to gforth
2025-05-18 23:27:02 <anthk_      > in my machine
2025-05-18 23:27:03 <anthk_      > pkg-config --cflags --libs x11
2025-05-18 23:27:03 <anthk_      > -I/usr/X11R6/include -L/usr/X11R6/lib -lX11 -lxcb -lXau -lXdmcp
2025-05-18 23:27:11 <vms14       > I only see s" curses" add-lib which is -l
2025-05-18 23:27:58 <vms14       > I guess creating some object file and then a wrapper on it?
2025-05-18 23:28:03 <vms14       > that sucks
2025-05-18 23:29:27 <anthk_      > veltas:  -1 invert ?
2025-05-18 23:29:30 <vms14       > maybe I have more luck with pforth
2025-05-18 23:30:54 <veltas      > There's no INVERT in FORTH-79
2025-05-18 23:30:54 <anthk_      > -1 negate
2025-05-18 23:31:30 <veltas      > In FORTH-79 NOT and 0= are defined to be identical, which I think probably annoyed some people
2025-05-18 23:31:38 <veltas      > And there's no bitwise NOT
2025-05-18 23:31:55 <veltas      > That may well be why they insisted on -1 for 'true' in FORTH-83
2025-05-18 23:32:04 <anthk_      > ah ok
2025-05-18 23:32:19 <anthk_      > now I recall 0=
2025-05-18 23:32:42 <veltas      > In defense of FORTH-79, NOT is a readable human word instead of 0= for those 'logical not' scenarios
2025-05-18 23:33:12 <veltas      > But they should have defined a standard one's complement word
2025-05-18 23:33:30 <vms14       > I like the on and off words
2025-05-18 23:33:41 <anthk_      > so they defined it to match both as flags
2025-05-18 23:33:53 <vms14       > if using real hardware I would love to do something like: led on
2025-05-18 23:34:04 <anthk_      > because of 0= and invert
2025-05-18 23:35:09 <anthk_      > I'm using pforth with the web edition of starting forth, but I'm trying stuff on eforth too (the one under muxleq)
2025-05-18 23:35:14 <veltas      > ON and OFF are very common defs, yet not in any of the standards
2025-05-18 23:35:57 <vms14       > gforth has them, I thought they were a defined word by the book author
2025-05-18 23:36:12 <veltas      > This is one of the pitfalls of Forth, that the meaning of 'ON' and 'OFF' change significantly depending on the argument
2025-05-18 23:37:01 <vms14       > they are just 1 swap ! and 0 swap !
2025-05-18 23:37:22 <vms14       > or it is c! ?
2025-05-18 23:37:30 <veltas      > -1 in most Forths
2025-05-18 23:37:47 <veltas      > Very few embedded controllers are as simple to control GPIO as setting some addresses to 1 or 0, or -1 and 0.
2025-05-18 23:38:18 <veltas      > So ON/OFF is contrived, it's more useful for pure software programs than embedded programs like a washing machine controller
2025-05-18 23:38:57 <veltas      > Still useful for controlling 'flags' in high-level apps though
2025-05-18 23:39:36 <veltas      > E.g. I use  VISUAL ON  to enable the visual editor in my Forth startup block
2025-05-18 23:39:42 <vms14       > I want to do something like LED ON before dying and see a led shine
2025-05-18 23:40:36 <veltas      > In real life an LED is probably controlled by a single GPIO pin, and needs at minimum setting a particular bit of a register to control the output
2025-05-18 23:40:52 <veltas      > So if LED is an address/shift pair that could work, if ON was defined specially for it
2025-05-18 23:41:47 <veltas      > In my opinion with Forth you need to fearlessly reject conventions and just define words that make sense for the problem at hand
2025-05-18 23:42:20 <vms14       > if ON does not turn things ON then it's a scam and I want my money back
2025-05-18 23:42:36 <veltas      > And assume that the 'lexical scope' as some would call it will protect you from messing up stuff (and if not then removing defs from the dictionary lookup list is trivial usually anyway)
2025-05-18 23:43:16 <veltas      > My point vms14 is that the nature of 'ON' depends on the argument, but that shouldn't stop you from defining ON to make sense in your specific app
2025-05-18 23:43:39 <vms14       > yeah but you are right anyways
2025-05-18 23:44:03 <vms14       > I should not bend the hardware to work with ON but instead define a new word that makees forth bend to the hardware instead
2025-05-18 23:45:00 <veltas      > Often LEDs are connected directly to a GPIO and to leave the LED off you keep it tri-stated (e.g. set to 'input' direction), and to turn it off you connect it to ground (e.g. set to open-drain output, logic level 0).
2025-05-18 23:45:41 <veltas      > So turning it ON/OFF you often would change the direction, or if open-drain mode then maybe set logic level to 1 to turn off and 0 to turn on.
2025-05-18 23:46:33 <veltas      > If you have a Forth BLOCK that defines the LED behaviour then define ON and OFF in that block to turn the LED on or off
2025-05-18 23:46:46 <veltas      > And then in another BLOCK you can define it to do something else, based on context
2025-05-18 23:47:15 <veltas      > And those blocks can coexist
2025-05-18 23:47:45 <veltas      > Should have said "turn it on* you connect it to ground" earlier
2025-05-18 23:49:21 <anthk_      > uhm this eforth lacks d* and d- https://github.com/howerj/muxleq
2025-05-18 23:49:33 <vms14       > veltas do you use vocabularies?
2025-05-18 23:51:35 <veltas      > I've used vocabs and wordlists and I have found both to not feel very 'Forthy'
2025-05-18 23:52:08 <anthk_      > and the first m*/ I used as a base for d* and d- didn't work for negative numbers
2025-05-18 23:52:17 <veltas      > My recent favourite thing is to define a word called something like UNLINK which takes a range of words out of the dictionary list, so they cannot be found anymore
2025-05-18 23:52:48 <veltas      > You can do this any time as needed, if irrelevant words hide a useful word, or use it to make words 'private' in a module
2025-05-18 23:53:29 <veltas      > The definition of UNLINK is trivial, doesn't add any overhead, and doesn't change semantics of Forth much; unlike vocabs and wordlists
2025-05-18 23:54:52 <vms14       > but then those words are lost forever?
2025-05-18 23:55:02 <veltas      > anthk_: D* isn't standard is it?
2025-05-18 23:55:34 <vms14       > I saw the smudge bit which is what unlink might be messing with I guess
2025-05-18 23:55:37 <veltas      > They're still there where they're used, but can't be found anymore.  Unless you FORGET it all and reload it
2025-05-18 23:55:50 <veltas      > UNLINK works with/without smudge bit support
2025-05-18 23:56:25 <veltas      > The point of UNLINK is to remove the words from the linked list, so you don't need a smudge bit.  I don't really like smudge bits, I don't see the point.
2025-05-18 23:56:57 <veltas      > I don't use them for colon defs because I just don't add a word to the dictionary list until ;
2025-05-18 23:57:59 <anthk_      > 100 200 m* works
2025-05-18 23:58:27 <anthk_      > but just with two 'integers' giving me a double
2025-05-18 23:59:04 <anthk_      > I don't have m*/
2025-05-18 23:59:09 <anthk_      > which could be the useful one