2023-08-16 00:46:33 <dave0       > just from a google search for "arm unaligned access" the answer seems to be no
2023-08-16 00:51:37 <dave0       > hmm it's more a tentative "no" .. this stack overflow says "yes, if ... <explanation>"   https://stackoverflow.com/questions/38535738/does-aarch64-support-unaligned-access
2023-08-16 00:52:15 <dave0       > short answer yes with an `if`, long answer no with a `but`
2023-08-16 02:28:14 <rendar      > DKordic, i was just wondering about what ordering usually forth takes
2023-08-16 04:15:54 <xelxebar    > KipIngram: Depends. https://developer.arm.com/documentation/ddi0406/c/Application-Level-Architecture/Application-Level-Memory-Model/Alignment-support/Unaligned-data-access
2023-08-16 04:16:48 <veltas      > Yeah there are ARM chips that will cause abort, some will return swapped bytes, some will work but without atomicity and worse performance
2023-08-16 04:17:01 <veltas      > 'ARM' is pretty broad
2023-08-16 04:21:12 <veltas      > DKordic: I wasn't talking about closures, that's the one thing I thought to myself that you can't implement that way
2023-08-16 04:22:47 <veltas      > Ugh I hate the ARM website, that massive banner and contents pane cover 60% of the screen unless I zoom out on this laptop
2023-08-16 04:23:03 <veltas      > Probably even worse on my old thinkpad
2023-08-16 04:34:42 <rendar      > sorry i got disconnected
2023-08-16 06:07:21 <MrMobius    > ya the stack overflow link is for aarch64 which is not cortex m
2023-08-16 06:10:54 <veltas      > Coretex M4 allows unaligned access of 'real memory'
2023-08-16 06:11:00 <veltas      > Cortex*
2023-08-16 06:11:17 <veltas      > But special peripheral memory it can be unpredictable
2023-08-16 06:12:49 <veltas      > Not sure about M3, would guess lower M's all cause crash or return unpredictable results
2023-08-16 06:45:27 <xelxebar    > Hrm, doubles feel like mainly a workaround 32-bit limitations. Would suspect that 64-bit forths don't make much use of them, but is that true?
2023-08-16 06:47:44 <KipIngram   > I have no double words in my 64-bit system, and haven't missed them at all.  I can't think of any application I'm likely to write that will need 128-bit integers.
2023-08-16 06:48:23 <KipIngram   > 128-bit floats might occasionally be useful, though.  My calculator uses those and has 34-digit precision across the board.
2023-08-16 06:49:23 <KipIngram   > Not supporting double ints leaves you able to use . to indicate floating point quantity.
2023-08-16 06:52:48 <KipIngram   > This chip I'm targeting for the new work has 32-bit floating point support, but not 64-bit.  That's a little sad - single precision float really isn't very accurate by modern standards.  I think I'd lean toward implementing double ints on there and possibly not implement floating point at all.  For high accuracy work just use double ints and write fixed point algorithms.  Chuck would approve anyway.
2023-08-16 06:53:03 <KipIngram   > He was never too keen on floating point.
2023-08-16 07:41:45 <xelxebar    > Could be interesting to gather examples of Forth numeric code and see what people are doing.
2023-08-16 07:42:18 <xelxebar    > I agree that floats are annoying. The impedance mismatch between base 10 and power-of-2 base is also a nuisance.
2023-08-16 07:42:57 <xelxebar    > That said, if your problem natural has error bounds that scale exponentially with the result, then they're kind of golden.
2023-08-16 07:43:35 <rendar      > when i type an incorrect word, stack is wiped, why is that?
2023-08-16 07:43:35 <xelxebar    > That's likely often the case with physics sims of non-chaotic systems.
2023-08-16 07:44:07 <xelxebar    > rendar: Ew. What Forth are you using?
2023-08-16 07:44:13 <rendar      > gforth
2023-08-16 07:44:46 <rendar      > https://bpa.st/JJWQ
2023-08-16 07:45:45 <xelxebar    > Huh. Indeed, I see the same thing.
2023-08-16 07:45:49 <xelxebar    > That's absolutely bizzare.
2023-08-16 07:46:07 <rendar      > but that's gforth, one of the most used Forth out there
2023-08-16 07:47:03 <xelxebar    > Yeah, I don't know gforth at all. Maybe it's in some special exception mode with a separate stack?
2023-08-16 07:48:01 <xelxebar    > Yeah, that looks like what's probably happening.
2023-08-16 07:48:27 <xelxebar    > Try running `123 throw` and you'll see similar behavior.
2023-08-16 08:01:57 <rendar      > hmm why is that? separate stack?
2023-08-16 08:02:59 <crc         > THROW will invoke ABORT or ABORT" both of which clear the data stack.
2023-08-16 08:03:34 <rendar      > hmm i see
2023-08-16 08:08:09 <xelxebar    > crc: This says that throw "jumps to the dynamically next enclosing catch". How is ABORT related to this?
2023-08-16 08:08:17 <xelxebar    > This: https://gforth.org/manual/Exceptions-Tutorial.html
2023-08-16 08:08:36 <KipIngram   > xelxebar: Floating point is really just a method that lets us ignore certain aspects of our solution process.  They're a "shortcut."
2023-08-16 08:09:16 <KipIngram   > render: I regard that (losing your stack on any error) as rather poor.
2023-08-16 08:09:31 <KipIngram   > The more common procedure is to wipe the RETURN STACK and restart the interpreter.
2023-08-16 08:09:57 <KipIngram   > In my system I snapshot my system (including stack) state before I start interpreting each line, and if any error occurs I restore that state.
2023-08-16 08:10:11 <KipIngram   > That is, I discard the effect of words executed "so far" on the line.
2023-08-16 08:10:21 <xelxebar    > KipIngram: I agree that floats are often blindly used when your problem space is specced with reals, and this causes all sorts of headache.
2023-08-16 08:10:35 <KipIngram   > The idea is that when I have command history working, if I make a mistake on a line I can just up-arrow back to the line, fix it, and hit Enter again.
2023-08-16 08:11:04 <KipIngram   > Floats are a dangerous shortcut for people that don't know what they're doing.  They're "wonderful," but there are land mines there you can step on.
2023-08-16 08:11:59 <KipIngram   > I agree the mismatch between base-10 daily life and base-2 floating point can be a nuisance at times.  You can also show, though, that base-2 floats have better accuracy for a given number of bits that higher base systems.
2023-08-16 08:12:40 <xelxebar    > If you really know what you're doing, though, there are certain problems where ieee floats have really nice mechanical sympathy with the error propagation of your system.
2023-08-16 08:12:47 <KipIngram   > There's a classic paper out there, titled something like "What Every Computer Scientist Should Know About Floating Point."  Or maybe "Every Programmer."
2023-08-16 08:12:57 <KipIngram   > That's a good paper and if you haven't read it I highly recommend it.
2023-08-16 08:13:11 <KipIngram   > Yes, I agree with that.
2023-08-16 08:13:52 <KipIngram   > I've done a fair bit of scientific modeling in my time, and I've always used floating point for it.
2023-08-16 08:14:15 <KipIngram   > I recognize that it all CAN be done fixed point, and there might even be advantages in that, but I'm not experienced on that front.
2023-08-16 08:14:59 <KipIngram   > If I sat down to do it I'd almost certainly make some mistakes.  At least if it were a wide dynamic range problem.
2023-08-16 08:15:29 <KipIngram   > I guess I could handle "dollars and cents" work in fixed point without fouling up - not a lot of trouble to get yourself into there.
2023-08-16 08:17:37 <KipIngram   > Chuck claimed that his transistor circuitry simulator, in OKAD, was superior in accuracy to the simulators in big expensive chip simulation packages.  He took a fixed point approach in OKAD.
2023-08-16 08:18:07 <KipIngram   > And in the end, he got his chips to work, so he must have been doing something right.
2023-08-16 08:18:56 <KipIngram   > There's a "key voltage parameter" in transistor theory - I think he chose that voltage as his "unit" rather than just using mV or something "standard."
2023-08-16 08:19:28 <KipIngram   > Or maybe he chose his unit so that that important voltage had value 4096 or something like that.
2023-08-16 08:19:59 <KipIngram   > But at any rate, he fit his units system to his physics.
2023-08-16 08:20:17 <KipIngram   > Very typical "Chuck move>"
2023-08-16 08:20:22 <KipIngram   > move"
2023-08-16 08:24:50 <crc         > xelxebar: I've never delved much into CATCH/THROW; if there is a CATCH that may prevent calling ABORT.
2023-08-16 08:25:22 <KipIngram   > I don't have any kind of general mechanism of that sort in my system either.
2023-08-16 08:26:10 <KipIngram   > I do use ERR as a sort of "trap door" through recovery and back to the interpreter - there's likely a bit of machinery there I could generalize if I noodled into it.
2023-08-16 08:27:00 <KipIngram   > Just provide some "alternate destination" mechanism.
2023-08-16 08:27:53 <KipIngram   > I should probably keep that in the back of my mind for this 32655 system.
2023-08-16 08:28:41 <KipIngram   > I've never had to use such things much in the past, but recently I've been doing a good bit of try: / except: in Python.
2023-08-16 08:29:25 <KipIngram   > Once in a while in my testing a test step can fail to acquire its data files, and in my report generator I need to handle those cases gracefully.  Just create an empty graph, rather than crash.
2023-08-16 08:29:43 <KipIngram   > Typically it looks like this:
2023-08-16 08:29:45 <KipIngram   > try:
2023-08-16 08:29:55 <KipIngram   >   <something here makes x and y vectors>
2023-08-16 08:29:57 <KipIngram   > except:
2023-08-16 08:30:07 <KipIngram   >   x = [0] ; y = [0]
2023-08-16 08:30:12 <KipIngram   > So, pretty simple.
2023-08-16 08:34:32 <crc         > I've used try/except in python a few times. Never used THROW/CATCH in Forth though.
2023-08-16 08:35:04 <KipIngram   > Nor have I - haven't used it or implemented it.
2023-08-16 08:36:06 <KipIngram   > Redirecting flow on errors seems like it would be pretty easy - I'm not sure how you'd know when to change it back, though.
2023-08-16 08:37:18 <KipIngram   > Just thinking about it it seems like you'd need some "standard scope" for the new error handling destination to apply to.  How long does THROW "last"?
2023-08-16 08:37:54 <KipIngram   > Everything between THROW and CATCH?
2023-08-16 08:38:17 <KipIngram   > THROW could compile a change to the error destination, and catch could compile code to restore normal error handling.
2023-08-16 08:38:45 <KipIngram   > That's the first thing I'd explore, I think.
2023-08-16 09:14:08 <veltas      > xelxebar: Doubles are there to work around 16-bit forth limitations (because lots of computers were 16-bit or similar small size and 32-bit is necessary for many typical applications)
2023-08-16 09:14:53 <veltas      > 64-bit support was nice in 32-bit forths but 128-bit is as you say a bit redundant, double's are pretty antiquated on new systems
2023-08-16 09:15:25 <veltas      > But it's baked into how a lot of words work, and the syntax generally, so the standard is stuck with them
2023-08-16 09:16:49 <veltas      > Although I like that I can take the same calculation code and run it on an 8-bit computer and it will still work
2023-08-16 09:18:49 <veltas      > crc: I used to defend CATCH/THROW but it's just badly designed. Taking an xt is weird, it saves/restores input state as well as the return stack, it restores the height of the data stack
2023-08-16 09:20:37 <veltas      > Would have been more helpful to document more general return stack access and make it a deviation to use anything other than one return address for call frame
2023-08-16 09:27:26 <veltas      > I'm starting to think FORTH 83 or a previous was the last good Forth standard, there's not a lot of additions to ANS that's designed well or fits with the language
2023-08-16 09:33:41 <veltas      > Oh FORTH 83 uses floored division lol
2023-08-16 09:33:46 <veltas      > Can't do anything right
2023-08-16 09:34:59 <veltas      > Interesting article here on differences with fig forth https://atariwiki.org/wiki/Wiki.jsp?page=Converting%20FIG-Forth%20Programs%20to%20Forth-83
2023-08-16 09:44:11 <veltas      > KipIngram: CATCH pushes relevant state to save to return stack, and updates a user variable with the new catch frame (saving previous frame pointer to return stack as well)
2023-08-16 09:44:38 <veltas      > Then if it completes normally it removes the frame
2023-08-16 09:45:00 <veltas      > THROW restores state from the catch frame pointer and resumes in CATCH with an error code instead of 0
2023-08-16 09:45:18 <veltas      > Well actually it will resume after CATCH in the colon def, with the 'error state'
2023-08-16 09:45:30 <veltas      > And you use IF or CASE to determine what needs to be done
2023-08-16 09:46:18 <veltas      > It doesn't need to go on return stack, but IMO that's the only place that makes sense to store this, it just requires an addressable return stack
2023-08-16 09:46:21 <veltas      > Which most are
2023-08-16 09:46:59 <veltas      > If I ever write THROW/CATCH I'll link it to you, because it's not too complicated and code is probably better than my explanation
2023-08-16 09:59:52 <xelxebar    > veltas: Oh, that's some nice historical context. Cheers.
2023-08-16 10:13:18 <KipIngram   > Ok, I think that concurs with what I was thinking.  THROW compiles run time actions to establish the alternate error handling, and CATCH compiles runtime actions not only to handle possible errors but also to restore normal error handling going forward.  Seems pretty sensible.
2023-08-16 10:13:41 <xelxebar    > So there's forth 79, 83, then ans.
2023-08-16 10:13:55 <KipIngram   > Right, and they do have some noticeable differences.
2023-08-16 10:14:06 <KipIngram   > And there's also FIG.
2023-08-16 10:14:24 <KipIngram   > Forth Interest Group.  They circulated a number of Forth implementations for various processors back in the day.
2023-08-16 10:14:29 <xelxebar    > Interesting. How does 2012 fit in the picture?
2023-08-16 10:14:33 <KipIngram   > FIG is basically older than the ones you listed.
2023-08-16 10:14:38 <xelxebar    > Oh! That's where "FIG" comes from.
2023-08-16 10:14:40 <KipIngram   > I'm not familiar with 2012 changes.
2023-08-16 10:14:44 <KipIngram   > Right.  :-)
2023-08-16 10:15:05 <KipIngram   > My knowledge of Forth machinery is heavily shaped by FIG ideas.
2023-08-16 10:15:24 <KipIngram   > A guy named McCabe wrote a book called Forth Fundamentals.
2023-08-16 10:15:36 <KipIngram   > Volume 1 describes all the "under the hood" stuff and is large FIG-based.
2023-08-16 10:16:14 <xelxebar    > Neat. Are there package libraries of forth applications out there for these different standards?
2023-08-16 10:16:17 <KipIngram   > Volume 2 is a glossary, and for non-primitives it gives typical Forth definitions for the words.
2023-08-16 10:16:38 <KipIngram   > I don't know - probably but likely "disorganized" and somewhta random?
2023-08-16 10:17:20 <KipIngram   > Forth doesn't really embrace the "library" idea the way many other languages do, and you even have the language's creator advocating explicitly against the idea.
2023-08-16 10:17:44 <xelxebar    > Thttps://archive.org/details/forthfundamental0001mcca
2023-08-16 10:18:40 <KipIngram   > One problem there is that the form compiled Forth code takes in RAM isn't very easy to "save off" for later reloading.  Forth leans heavily toward transporting code only in source form - you recompile it when you load it, so that all the addresses are properly coordinated with what other things you've compiled.
2023-08-16 10:18:49 <xelxebar    > Published 1983, coincidentally (maybe?)
2023-08-16 10:18:52 <KipIngram   > I.e., I'm not aware of any Forth "objec code format."
2023-08-16 10:19:08 <KipIngram   > object
2023-08-16 10:21:31 <KipIngram   > So that basically means that if you want to share your code, you have to share your source, and that raises IP protection issues and so forth.
2023-08-16 10:22:21 <xelxebar    > Sounds like a strange idea, too. Any object code would have to be JITed or interpreted at runtime, and Forth is so close to the metal, you might as well consider the source a kind of ASCII bytecode.
2023-08-16 10:22:44 <KipIngram   > You could obfuscate it by changing all the names to gibberish and things like that.  You could also probably, if your Forth supported the idea, compile and and then decompile it, which would resolve control structures into jump-based code.  That would make it a bit harder to reverse engineer as well.
2023-08-16 10:36:50 <KipIngram   > I agree with that last remark you made.
2023-08-16 10:37:38 <KipIngram   > Forth certainly can be close to the metal, but you can also distance yourself from it by as much as you want and still be writing Forth.
2023-08-16 10:37:58 <KipIngram   > That's a key thing I love about the language - it can serve at all levels, and it "stays the same" so to speak.
2023-08-16 10:38:40 <KipIngram   > In C, for example, you can write a code hierachy, but there's a distinctly different syntax (functions and function calls) for invoking that, as compared to generating your code by using built in operators.
2023-08-16 10:39:08 <KipIngram   > But in Forth invoking a primitive looks exactly the same as invoking a very very high level word - it's just the same bottom to top.
2023-08-16 10:39:43 <KipIngram   > And in direct and indirect threaded Forths that "sameness" is reflected in the compiled code too.
2023-08-16 10:40:07 <KipIngram   > To run a primitive, you add its CFA to your definition.  To run a high level word, you add it's CFA to your definition.
2023-08-16 10:41:25 <KipIngram   > This 32655 work I'm planning will be a little different - the compiler output will look more like machine code, with explicit "call" operations to invoke definitions - it'll just be a virtual machine code rather than the native ARM machine code.
2023-08-16 10:41:39 <KipIngram   > Look more like F18a machine code.
2023-08-16 10:42:06 <KipIngram   > Really the whole idea here is an "inexact F18A emulation."
2023-08-16 10:43:15 <KipIngram   > I want to be pretty rigorous about that, too - I want to write an F18A-like emulator using ARM code, and then I want EVERYTHING else to be written in that vm code.
2023-08-16 10:46:57 <KipIngram   > The F18A has a "call" opcode.  It uses whatever amount of cell is left as the target spec.
2023-08-16 10:48:09 <KipIngram   > I'm considering adding some additional call opcodes that don't use the entire remainder of the cell, but rather only some portion of it.  However, that would mean that I needed to save not only the return address but also the extant instruction word when I made a call.
2023-08-16 10:48:31 <KipIngram   > So, that would add a bit of overhead both in performance and RAM use - I may drop that idea.
2023-08-16 10:48:50 <KipIngram   > It would just make code modestly more compact.
2023-08-16 10:49:05 <MrMobius    > you could make it only jump to the address on the top of the stack
2023-08-16 10:49:32 <KipIngram   > Yes, that's possible too, but then I'd be having the same issues with lit.
2023-08-16 10:50:07 <KipIngram   > I may also include a call that uses the entirity of the following cell as the target.  That's not so valuable on the 32655, because it only has 128k of RAM.  But it would expand the call range on a desktop.
2023-08-16 10:50:31 <KipIngram   > And given that I plan to have vocabularies be in different RAM blocks, the call and the target might get pretty far apart.
2023-08-16 10:50:47 <KipIngram   > So the capability will be there, but will likely go unused on the 32655.
2023-08-16 10:51:57 <KipIngram   > lit does face exactly the same issues.  On the F18A, it does the same trick - uses the remainder of the cell as the literal value.  But then there's also @p+ which loads from the program counter address and post-increments - that's basically "lit that uses the whole next cell"
2023-08-16 10:53:47 <KipIngram   > I think a lit+call approach would definitely be lower performance.
2023-08-16 10:53:56 <KipIngram   > Since it would involve diddling around with the stack as well.
2023-08-16 10:54:53 <KipIngram   > I rather like basic idea used in the F18a - locality in your code will mean that many calls will need a fairly small offset (I'm going to implement this as a relative call).
2023-08-16 10:55:40 <KipIngram   > For a variety of reasons the compiler for this is going to be osmewhat more complex / smart than a usual Forth compiler.
2023-08-16 10:56:03 <KipIngram   > Very simple vm, but making optimal use of it will require those smarts.
2023-08-16 10:56:36 <KipIngram   > All that code, though, will be written in vm code, so will be portable across platforms.
2023-08-16 11:02:12 <MrMobius    >  the difference in performance might not matter much since you need cycles for the interpreting anyway
2023-08-16 11:26:25 <veltas      > KipIngram: Hi just saw your reply, no THROW does not compile anything. It can be run entirely dynamically. I don't know if it's a "compile-only" word in standard but in any sensible implementation it's just a regular word
2023-08-16 11:27:48 <veltas      > Something like this (a sketch, I would guess this doesn't execute but it's not far off) https://i.imgur.com/rLTwtA6.png
2023-08-16 11:28:48 <veltas      > And set CATCH-FRAME in CATCH... I forgot
2023-08-16 11:29:02 <veltas      > But you get the idea (?)
2023-08-16 11:54:04 <veltas      > KipIngram, xelxebar: To make Forth objects you need to keep track of links, this limits what kind of things you can do but doesn't limit your possibilities, it just constrains how you do it
2023-08-16 11:54:21 <veltas      > Unless you have a fixed address space in which case you don't need linking at all
2023-08-16 11:54:54 <veltas      > But basically you need to *link* things, rather than just take addresses of things and 'keep' them where they could change on relinking
2023-08-16 11:55:15 <veltas      > And then the object can be ELF or something that keeps track of symbols
2023-08-16 11:56:52 <veltas      > This is usually easy, e.g. if I am writing a colon def and use a variable, then add an entry to the link table for the variable where the 'address' literal/immediate goes
2023-08-16 11:58:33 <veltas      > But sometimes it's harder, like if I have a variable containing an address... that address will be incorrect, so I need to do things differently or manually say to link it to the table. But that's just one extra little detail and things work
2023-08-16 11:59:08 <veltas      > So you can't make arbitrary forth code into objects, but some code will work, and most code can be adapted
2023-08-16 12:02:04 <KipIngram   > The way I've always thought of it is that within any block you might want to load, there are fields that depend on where you load it.  I usually think about having those be relative offsets from the load point in the object format, and the the loader will run through those and add the load address to each offset.
2023-08-16 12:02:24 <KipIngram   > You might have several blocks, meant to be placed at different locations, in a single file of this form.
2023-08-16 12:02:44 <KipIngram   > It's one of those things where the idea is very simple but the implementation can be tedious.
2023-08-16 12:03:04 <veltas      > Yeah that's what I'm talking about
2023-08-16 12:03:15 <veltas      > I don't think the implementation is too tedious...
2023-08-16 12:03:46 <KipIngram   > The main hurdle to implementation is that most Forth systems compile in-RAM code that doesn't readily tell you which fields fit into this category and which don't.
2023-08-16 12:03:47 <veltas      > In a sense, your basic Forth image you create (if you create one at all) is already under the same kinds of restrictions as object generating Forth would be
2023-08-16 12:04:04 <veltas      > Well design the system around it, or write a system in the system
2023-08-16 12:04:13 <veltas      > But any good Forth system can be adapted for this
2023-08-16 12:04:22 <KipIngram   > so it would be pretty easy to write a "compile source to object" utility, but harder to write a "save off compiled RAM content to object" utility.
2023-08-16 12:04:59 <veltas      > Yes, but you get to *run* the "compile source to object" code as well, so you can have it generate content in advance etc
2023-08-16 12:05:07 <KipIngram   > I've never had a lot of interest in it - I'm writing mostly for myself, so I will always have all the source, and it doesn't take long to load and compile it.
2023-08-16 12:05:19 <veltas      > But anything with an address that's not detected by normal compilation routines would need manual linking
2023-08-16 12:05:49 <veltas      > i.e. CREATE stuff would "just work", but if I do HERE CONSTANT X I'd need to use LINK or whatever I will call it
2023-08-16 12:07:46 <veltas      > Yeah it's usually not interesting and it's not something I've spent energy on, I've just conceptualised it
2023-08-16 12:08:16 <veltas      > But it's necessary for a 'professional desktop forth', because organisations need to output an executable object without the source
2023-08-16 12:08:49 <veltas      > And I like to have an answer if someone says "Forth can't do that"... Forth can do it, and there are Forths that do it. It's just not something you'll see the open source or hobbyist community worry about
2023-08-16 12:09:27 <veltas      > Likewise if you keep dictionary list separate from the definitions then you can remove the names of everything and the object becomes more ... proprietary
2023-08-16 12:09:56 <veltas      > And you can make the entry point not link to the interpreter, so it can't be programmed maliciously, or leave out entire parts of the main forth image
2023-08-16 12:12:53 <KipIngram   > Right - yes.  A related issue comes up if you start thinking about trying to move compiled code in RAM (like, as part of a garbage collector or something).  What if you recognize the need to do that when you have addresses on the stack?   Once something is on the stack, you have no idea what sort of thing it "is" anymore.  Any data structures you've built with link fields, etc.
2023-08-16 12:13:05 <KipIngram   > Go down that road and the bookkeeping rapidly becomes troublesome.
2023-08-16 12:13:28 <KipIngram   > Just so easy to compile source to RAM and leave it right there for the duration.
2023-08-16 12:13:44 <veltas      > I'm saying just create a symbol table and get the OS to set the runtime addresses for you
2023-08-16 12:13:52 <veltas      > But yeah no address on the 'stack' would work
2023-08-16 12:13:58 <veltas      > There's no magic wand
2023-08-16 12:14:36 <KipIngram   > Back in the early days of the Macintosh, they leaned heavily on the concept of "handles."  A handle was a pointer to a pointer, and the system kept the actual pointers in a table so that they knew where they all were.
2023-08-16 12:14:38 <veltas      > I don't actually know the ELF layout well but I'm assuming there's a table for each symbol with offsets of where that symbol's address needs to be loaded
2023-08-16 12:14:46 <KipIngram   > That allowed them to move stuff around willy nilly.
2023-08-16 12:15:05 <KipIngram   > Kind of like our LPT - we can move logical pages to new physical pages and just update the LPT to reflect that.
2023-08-16 12:15:09 <veltas      > Yeah that allows things like 'compacting'
2023-08-16 12:15:29 <veltas      > Where you reduce fragmentation of running memory ... very pre-virtual-memory issue
2023-08-16 12:15:52 <KipIngram   > I've probably give thought to almost all of these tricks re: Forth at one point in time or another, but just never got to the point of regarding any of it as "worth it."
2023-08-16 12:16:04 <KipIngram   > given
2023-08-16 12:17:03 <veltas      > Well I wonder only because it's a question of whether Forth is 'feasible' for business use
2023-08-16 12:17:34 <veltas      > And fortunately I can answer 'yes' Forth can do this, if you really want, it's entirely practical and feasible
2023-08-16 12:17:45 <KipIngram   > I certainly think Forth could be valuable in businesses that do embedded development, but I think you mean "business software"?
2023-08-16 12:18:12 <veltas      > I mean if I said Forth is practical 'in general' then I'd have to show it could do this
2023-08-16 12:18:38 <veltas      > Or that it wasn't actually needed
2023-08-16 12:19:09 <veltas      > But sometimes it really is necessary to hide your source code, or at least in our society it's expected and I couldn't convince companies otherwise
2023-08-16 12:19:26 <KipIngram   > Well, I'm taking a halfway approach to it in this next system.  I plan to have each vocabulary, thus each process's private dictionary, in a separate region.  The idea is that if I want to I can just deallocate one and later reload from source.
2023-08-16 12:19:40 <veltas      > And also sometimes you want to avoid the extra runtime cost of compiling from source every time you turn the key, that would be useful for embedded too right?
2023-08-16 12:20:00 <KipIngram   > I certainly think that will have value for things that are like bash commands - load and compile a utility, use it, and then discard it.
2023-08-16 12:20:22 <MrMobius    > couldnt you say Forth had it's chance for all of those things?
2023-08-16 12:20:23 <KipIngram   > Operationally it'll just be like "running a command," but it will be compiling and running every time.
2023-08-16 12:20:53 <KipIngram   > I think the primary barrier Forth faced is that it doesn't support large team programming very well.
2023-08-16 12:21:19 <veltas      > It doesn't support monkeys on keyboards programming
2023-08-16 12:21:36 <KipIngram   > That article veltas linked the other day that focused mostly on Lisp said some similar things about it, and pointed to C's very good "team approachability" as one of hte reasons for its success.
2023-08-16 12:21:40 <KipIngram   > Right.
2023-08-16 12:21:44 <KipIngram   > That's more what I meant.
2023-08-16 12:21:54 <veltas      > There are cases of it being used with big teams, I don't think that's the main issue anyway
2023-08-16 12:22:15 <veltas      > I think the main issue is people find it easier to program with even a small, basic, but well defined syntax
2023-08-16 12:22:24 <KipIngram   > Well, the exceptions weren't sufficient to get it any real momentum.
2023-08-16 12:22:39 <veltas      > And it's easy to see that in the difference between C and Lisp. Lisp has more flexibility and features, but C is "good enough"
2023-08-16 12:22:39 <MrMobius    > someone was making a big deal on a forum a while ago about two people working on the same project since that's more than you usually hear being able to work together
2023-08-16 12:23:02 <KipIngram   > Right - I was just about to mention the "good enough" thing, which you brought up the other day, too.
2023-08-16 12:23:05 <veltas      > How often do people actually try to work together?
2023-08-16 12:23:12 <veltas      > On Forth these days?
2023-08-16 12:23:25 <KipIngram   > I imagine it's pretty rare.
2023-08-16 12:23:27 <MrMobius    > I mean work together as in work on different parts of the same project
2023-08-16 12:23:45 <MrMobius    > which doesnt really seem to happen with forth
2023-08-16 12:23:51 <veltas      > I've had people I don't know give me PR's for my spectrum forth in really deep parts of the system
2023-08-16 12:24:06 <veltas      > I've supported crc and I'm sure crc has other stories of collaboration on retro and ilo
2023-08-16 12:24:22 <MrMobius    > thats neat but working on the forth is different than working on a project in forth
2023-08-16 12:25:34 <veltas      > Well personally I've read all sorts of Forth code and I actually find it often more readable than most languages, especially C
2023-08-16 12:25:46 <KipIngram   > I totally agree.
2023-08-16 12:25:59 <KipIngram   > Assuming the Forth is anything close to well-written.
2023-08-16 12:26:00 <veltas      > Where for some reason in C people have a capacity to write incredibly unreadable code
2023-08-16 12:26:35 <KipIngram   > I think an immediate issue there is that C code can sprawl out over pages and pages and it's hard to hold all of the logic in your head at any given moment.
2023-08-16 12:26:35 <veltas      > Part of the reason Forth is well written is a hindrance... it's harder to write. It better be easy to follow or you'll get lost mid-development
2023-08-16 12:27:07 <KipIngram   > Agree again - it's not easy to write good Forth, and it definitely requires a degree of experience working with the language.
2023-08-16 12:27:28 <KipIngram   > There's a mind set you need to be able to get into.
2023-08-16 12:27:42 <veltas      > This is one of the business barriers, it's not easy to start writing Forth, for businesses that's a problem
2023-08-16 12:28:15 <KipIngram   > I think the way I write my code might be *harder* for other Forth programmers to read, but I'm used to it now and have no problem at all reading it.
2023-08-16 12:28:28 <veltas      > I don't think so, what I've seen makes sense to me
2023-08-16 12:28:29 <KipIngram   > I just know what to "expect from my old self," so to speak.
2023-08-16 12:28:45 <KipIngram   > I didn't really mean that it makes no sense at all.
2023-08-16 12:28:53 <veltas      > I need to ask some questions but a little documentation would probably be enough to onboard someone... if you ever wanted to do that
2023-08-16 12:29:14 <KipIngram   > I do want to - I know you guys don't believe me but I really do intend to put something out there at some point.
2023-08-16 12:29:25 <veltas      > I'm not saying anything
2023-08-16 12:29:48 <KipIngram   > But here I am, about to re-approach the whole business in a new way, so in my mind I don't really have anything yet.
2023-08-16 12:30:16 <veltas      > Tonight I'm looking at my block editor and I'll probably upload that too
2023-08-16 12:30:28 <KipIngram   > Maybe if I get up a good head of steam on this project I'll decide that I'm never going any further with the old one and then I'd feel fine sticking it on github.
2023-08-16 12:30:30 <veltas      > It's just the starting forth editor really
2023-08-16 12:30:53 <veltas      > crc's got a very short editor, I think it's like one or two blocks
2023-08-16 12:30:55 <MrMobius    > I can believe that some people have an easier time reading Forth than C but I think C is easier to read for most people. It's definitely easier and faster for me and it's not for lack of experience with either.
2023-08-16 12:31:04 <crc         > I've had a fair amount of collab w/others on my forths over the years.
2023-08-16 12:32:12 <MrMobius    > crc, thats cool. were there projects people implemented with your forths where multiple people worked together too?
2023-08-16 12:32:29 <crc         > MrMobius: yes
2023-08-16 12:34:08 <veltas      > Look at some of the testimonies of Forth Inc... although they might be biased lol
2023-08-16 12:34:17 <veltas      > And MPEForth et al
2023-08-16 12:34:56 <veltas      > I can't say it empirically but rationally I see all the components required for collaboration available in a typical forth system
2023-08-16 12:36:12 <crc         > re: block editor: https://forth.works/temp/block-editor.txt is the basic one in my system; I have a few additional ones in my blocks
2023-08-16 12:40:57 <crc         > MrMobius: with others, I worked on a variety of projects including a utility to display sheet music from ABC format music files, several games, a partial set of userland tools for Linux, and adaptions to make the systems more usable with a screen reader/braille input.
2023-08-16 12:54:09 <vms14       > My old self always surprises me
2023-08-16 12:55:14 <vms14       > I usually get surprised for how stupid can be
2023-08-16 12:55:25 <vms14       > But sometimes does smart stuff
2023-08-16 12:55:47 <vms14       > It's like I'm being more stupid every day xD
2023-08-16 12:57:57 <KipIngram   > lmao
2023-08-16 12:58:04 <KipIngram   > I've had both experiences too.
2023-08-16 12:59:29 <KipIngram   > Somehow I just find this conditional return style of programming very "comfortable" to me.  It bothers me just a little bit that I pay the call/return overhead even if I immediately leave and don't execute the code, but that's probably not really a very significant overhead.
2023-08-16 13:03:11 <KipIngram   > I have a *feeling* (possibly just a "hope") that I'll feel the same way about the communicating synchronous processes when I get that setup so that it's easy for me to use it.
2023-08-16 13:03:29 <KipIngram   > Simple little threads interacting instead of one more complex thread.
2023-08-16 13:03:58 <KipIngram   > And I want that to all be "painless" enough for me to just "use it" when it makes sense, without a lot of labor.
2023-08-16 13:13:38 <vms14       > Do you tend to overwrite the dot word '.' ?
2023-08-16 13:13:45 <thrig       > ...
2023-08-16 13:14:13 <vms14       > Mine actually has some sort of dual behavior
2023-08-16 13:14:29 <vms14       > It prints on screen, but you can attach it to a file handle
2023-08-16 13:15:17 <vms14       > For example if I use curses I would try to overwrite it
2023-08-16 13:15:30 <vms14       > And make it call addstr
2023-08-16 13:16:28 <vms14       > In the js version the attachment behavior was with dom objects, so you print directly on the textContent of the object attached
2023-08-16 13:16:35 <crc         > I use . for line length comments in konilo's blocks; in retroforth it's a sigil for processing floats.
2023-08-16 13:17:10 <KipIngram   > No, i usually don't redefine .
2023-08-16 13:17:32 <vms14       > Kipingram so it's better to hace special purpose dotlike words?
2023-08-16 13:17:38 <vms14       > Have
2023-08-16 13:17:43 <KipIngram   > I would.
2023-08-16 13:17:49 <vms14       > Hmm
2023-08-16 13:18:08 <crc         > I have n:put for displaying numbers, s:put for displaying strings, c:put for characters, etc
2023-08-16 13:19:18 <vms14       > Mine prints an element from the stack
2023-08-16 13:21:39 <KipIngram   > Yeah, that's what . traditionall does.
2023-08-16 13:21:51 <KipIngram   > Prints the number in the current BASE and with a space after it.
2023-08-16 13:22:07 <KipIngram   > I have (.) that does that without the space and then : .  (.) SPACE ;
2023-08-16 13:25:02 <KipIngram   > vms14: A typical Forth might offer words <# and # and #> which can be used to emit individual digits of a number; that gives you the opportunity to intersperse whatever formatting characters you want to.
2023-08-16 13:25:33 <vms14       > word { my $element = get; if (ref $element) { pr represent_element $element } else { pr $element } } '.';
2023-08-16 13:25:38 <vms14       > this is my dot word
2023-08-16 13:25:52 <vms14       > pr is another wrapper
2023-08-16 13:26:02 <KipIngram   > Why on earth does it have conditionals in it?
2023-08-16 13:27:05 <vms14       > https://hastebin.com/share/iguvezesil.perl
2023-08-16 13:27:15 <vms14       > KipIngram: cause it looks if it's an object
2023-08-16 13:27:29 <KipIngram   > I see.  Kind of non-Forthy.
2023-08-16 13:27:30 <vms14       > ref $element would return something if the element is not a number or a string
2023-08-16 13:27:37 <vms14       > yeah, totally non forthy
2023-08-16 13:27:44 <vms14       > my lang has nothing to do with forth :/
2023-08-16 13:27:49 <vms14       > I just stole his stack
2023-08-16 13:27:59 <vms14       > one of them
2023-08-16 13:28:10 <KipIngram   > :-)
2023-08-16 13:28:38 <vms14       > represent_element is some kind of to_string
2023-08-16 13:29:15 <vms14       > a bit big
2023-08-16 13:30:44 <vms14       > https://hastebin.com/share/ticegizoke.perl
2023-08-16 13:30:54 <vms14       > I did not remember about the circular data
2023-08-16 13:30:56 <vms14       > :0
2023-08-16 13:31:56 <vms14       > mainly takes the type of the object and looks for a word defined in the "dictionary" named represent.typeofdata
2023-08-16 13:32:28 <vms14       > this way to give a to_string method to any object you only need to define : represent.objectype  ... ;
2023-08-16 13:32:43 <vms14       > including perl objects
2023-08-16 13:32:58 <vms14       > : represent.IO::Socket  'haha ;
2023-08-16 13:33:59 <vms14       > https://hastebin.com/share/towacotovi.perl
2023-08-16 13:34:28 <vms14       > : represent.scalar dup defined [ dup numberp not [ ''~a' format ] if ] [ drop 'nil ] if.else ;
2023-08-16 13:34:54 <vms14       > scalar is any string or number
2023-08-16 13:35:01 <vms14       > or undefined value
2023-08-16 13:38:14 <vms14       > it's an abomination, but I like it
2023-08-16 13:38:57 <vms14       > the name that suits it most is dirtylang
2023-08-16 13:39:15 <vms14       > and the motto could be "So dirty that it works"
2023-08-16 13:39:30 <vms14       > or "So dirty that it's written in perl"
2023-08-16 13:42:46 <vms14       > need a dirty logo too
2023-08-16 13:43:56 <vms14       > but first needs documentation
2023-08-16 14:36:04 <vms14       > what do you thing about dual behavior?
2023-08-16 14:36:11 <vms14       > for example I have reverse and len
2023-08-16 14:36:17 <vms14       > both work with lists and strings
2023-08-16 14:36:52 <vms14       > would you have a reverse.string and a reverse.list?
2023-08-16 14:37:00 <vms14       > I like how it is now
2023-08-16 14:37:10 <vms14       > think*
2023-08-16 14:40:35 <KipIngram   > Forth generally adheres to fixed operation words.  A Forth person usually wouldn't have words making decisions of that sort - he'd just have a word for each case and he'd run the right one because he knew what he was doing.
2023-08-16 14:41:44 <KipIngram   > That said, I have talked about a type-aware system that would let me do work similar to what I might do in Octave or Matlab etc.  That, however, is something I'd regard more as a high-end application rather than being "the native system behavior."
2023-08-16 14:42:00 <vms14       > hmm
2023-08-16 14:42:53 <vms14       > It's weird that I take forth as inspiration and do absolutely all the inverse
2023-08-16 14:43:06 <KipIngram   > :-)  You just have other inspirations as well.
2023-08-16 14:43:08 <vms14       > but actually from forth I just took the stack and the colon words
2023-08-16 14:43:16 <vms14       > the other stuff is stolen from perl and lisp
2023-08-16 14:43:34 <KipIngram   > Look, "really smart software" is the norm these days - there's a huge effort to make things as idiot-proof as possible.  If they could have the software read your mind they would.
2023-08-16 14:43:44 <vms14       > saying this just makes me realize how weird it is
2023-08-16 14:44:04 <vms14       > ah, I look for ease in this case
2023-08-16 14:44:18 <vms14       > I like len to give me the length of a string or the length of a list
2023-08-16 14:44:35 <vms14       > also unification somehow can be good
2023-08-16 14:44:46 <vms14       > this is why I try to overwrite the dot word .
2023-08-16 14:45:08 <vms14       > I have to think about that
2023-08-16 14:45:13 <KipIngram   > Sure - that's a normal expectation for len - that's how it works in Python.
2023-08-16 14:45:18 <vms14       > I'd like the user to be able to overwrite .
2023-08-16 14:45:22 <KipIngram   > Forth is the odd man out in that case for sure.
2023-08-16 14:45:37 <KipIngram   > You mean redefine . right?
2023-08-16 14:45:52 <KipIngram   > Forth will let you redefine anything any time.
2023-08-16 14:45:54 <vms14       > yes, but not forever
2023-08-16 14:45:58 <vms14       > like in a context
2023-08-16 14:46:13 <KipIngram   > Ah.  Well, you could create a vocabulary and put your redefinition in there.
2023-08-16 14:46:29 <KipIngram   > Then if that vocabulary is in your search order you'll get the new one - if it's not you'll get the old one.
2023-08-16 14:46:30 <vms14       > yeah, actually it's lexical scope, so you can do whatever you want if you have your own scope
2023-08-16 14:46:39 <vms14       > outside that scope nothing happens
2023-08-16 14:46:58 <KipIngram   > Are you talking about changing it for new compiles, or changing it for words already compiled?
2023-08-16 14:47:19 <vms14       > there's no compile and no dictionary
2023-08-16 14:47:32 <vms14       > they're environments
2023-08-16 14:48:13 <vms14       > oh, that reminds me my old problem and the reason I made that fake compile
2023-08-16 14:48:29 <vms14       > they are solved with environments
2023-08-16 14:48:43 <KipIngram   > I see.
2023-08-16 14:48:44 <vms14       > words will still use the nearest definition
2023-08-16 14:48:57 <KipIngram   > Well, any forth will let you create a new definition using the same name as an existing word.
2023-08-16 14:49:06 <KipIngram   > Usually, though, that doesn't change words already compiled.
2023-08-16 14:49:13 <vms14       > yeah with forget you can do stuff like that also
2023-08-16 14:49:23 <vms14       > and you can make environments or whatever you want
2023-08-16 14:49:24 <KipIngram   > Often a special mechanism if offered for doing that - you have to plan from the outset to have that word changeable that way.
2023-08-16 14:49:39 <vms14       > that's the nice thing of forth, as a language it can be extended as you like
2023-08-16 14:49:48 <KipIngram   > My system would in theory let me change words in a way that would affect previously compiled words - I can do that for any word if I want to.
2023-08-16 14:49:56 <KipIngram   > Default : won't do it, but I could write one that would.
2023-08-16 14:50:13 <KipIngram   > It's easy enough to do manually in the rare cases I might want to do it.
2023-08-16 14:50:32 <KipIngram   > Just compile the new definition, grab an address related to it, and shove that address into the right spot in the old word's header.
2023-08-16 14:51:08 <vms14       > I'm trying to document it a bit
2023-08-16 14:51:23 <vms14       > https://termbin.com/wghwt
2023-08-16 14:51:36 <vms14       > but I should stop and think first on how I should document it
2023-08-16 14:51:45 <vms14       > I'm just writing whatever comes to my mind xD
2023-08-16 14:52:12 <vms14       > I think the first thing is a hello world
2023-08-16 14:52:14 <KipIngram   > LaTeX?  :-)
2023-08-16 14:52:19 <KipIngram   > It makes stuff pretty!
2023-08-16 14:52:31 <vms14       > that's at least the first thing I look when I want to know about a language
2023-08-16 14:52:56 <vms14       > KipIngram: I have to make some kind of format to autognerate pdf using latex or postscript
2023-08-16 14:52:57 <KipIngram   > Well, somewhere in there you should have an alphabetic list of words with a description of exactly what each one does.
2023-08-16 14:53:02 <vms14       > and man pages and html
2023-08-16 14:53:20 <vms14       > but I see that this format decision isn't letting me document the language
2023-08-16 14:53:29 <KipIngram   > Yeah, I've got a basic setup for editing LaTex files and making pdfs from them.
2023-08-16 14:53:38 <vms14       > KipIngram: I had a database with word names and their info
2023-08-16 14:53:41 <vms14       > it was super cool
2023-08-16 14:53:45 <vms14       > 'wordname doc
2023-08-16 14:53:49 <vms14       > and you had the info
2023-08-16 14:53:55 <vms14       > I have to do it again
2023-08-16 14:54:13 <KipIngram   > Yeah, that's nice.  It's not too hard to set something like that up in Forth, if you plan for a little.
2023-08-16 14:54:36 <vms14       > in my case a database in my lang is a hash table
2023-08-16 14:54:52 <vms14       > 'databasename.db magic.hash
2023-08-16 14:55:04 <KipIngram   > That whole business I plan for remote comments - what I actually want is a whole hyperlinked wiki that I can get into.  So, source -> comments -> docs -> deeper docs, etc.
2023-08-16 14:55:14 <KipIngram   > I think of it as precisely a wiki.
2023-08-16 14:55:18 <vms14       > it creates a berkeley db named 'databasename.db' and pushes a hash on the stack
2023-08-16 14:55:38 <vms14       > you can use the stack as you wish, and whatever you put on it, it will be persistent
2023-08-16 14:55:43 <KipIngram   > You've really tried hard to leverage existing complex tools.
2023-08-16 14:55:54 <vms14       > the next time you do 'databasename.db magic.hash  you will get the hash with those values
2023-08-16 14:55:54 <KipIngram   > That's pretty much the exact opposite of the Forth approach.
2023-08-16 14:56:01 <KipIngram   > Especially if you ask Chuck.
2023-08-16 14:56:52 <vms14       > I also have serialize and deserialize to serialize any kind of data you might want to add
2023-08-16 14:57:12 <vms14       > KipIngram: yeah, I'm doing almost the whole opposite of forth
2023-08-16 14:57:14 <vms14       > sorry :/
2023-08-16 14:57:32 <vms14       > but I'm cheating since the day 1
2023-08-16 14:57:59 <vms14       > it makes no sense to not use what I already have, I'm using perl
2023-08-16 14:58:22 <vms14       > I wonder what part of the forth philosophy agrees with my lang
2023-08-16 14:58:45 <vms14       > can you describe the forth philosophy?
2023-08-16 14:59:01 <vms14       > simplicity and factoring is the only I know
2023-08-16 14:59:19 <vms14       > and the fact you have no limits
2023-08-16 15:00:33 <vms14       > also the goal is to use the language for any task I want to achieve
2023-08-16 15:00:48 <vms14       > it needs stuff like lists, hashes, sockets, db, etc
2023-08-16 15:01:51 <vms14       > KipIngram: how would you structure that wiki info?
2023-08-16 15:02:19 <vms14       > I need to think about documentation
2023-08-16 15:02:37 <vms14       > I'd like to get a nice intro
2023-08-16 15:03:01 <vms14       > where you can get a general idea and start jumping to other topics
2023-08-16 15:03:31 <thrig       > other programmers maybe ship docs about the API and call it good
2023-08-16 15:04:36 <vms14       > I only have code with 0 comments as documentation
2023-08-16 15:06:02 <vms14       > perl always had very good documentation
2023-08-16 15:06:09 <vms14       > I like perldoc
2023-08-16 15:09:12 <KipIngram   > Oh, I don't know in detail yet - the mechanism would support any strucure I wanted.  To the extent I've thought about it, I've envisioned three types of stuff - comments, which help immediately grok the source code.  Then "documentation, which explains the basic system operation and so on, and then "detailed technical reference, withou address maps, header layout, etc.
2023-08-16 15:09:45 <KipIngram   > don't know where that ou at the end of withou came from.
2023-08-16 15:10:21 <vms14       > for the words I think it can be handy to have categories
2023-08-16 15:10:29 <KipIngram   > On the 32655 system that deepest level would include details on the built in peripherals and the way the system approached working with them, etc.
2023-08-16 15:10:46 <KipIngram   > Categories are good, yes.
2023-08-16 15:10:49 <vms14       > like words that operate on strings, words that do X...
2023-08-16 15:11:01 <KipIngram   > Memory access, arithmetic and logic, etc.
2023-08-16 15:11:03 <vms14       > and you can see all words that operate on strings
2023-08-16 15:11:08 <KipIngram   > Compiling words, etc.
2023-08-16 15:11:26 <vms14       > I had related words
2023-08-16 15:11:46 <vms14       > on the documentation of a word it would show at the end a list of related words
2023-08-16 15:12:39 <vms14       > documentation is harder than what I've expected
2023-08-16 15:12:40 <vms14       > xd
2023-08-16 15:14:21 <vms14       > if I had some type declarations I could autogenerate groups of words that use that type of data
2023-08-16 15:21:23 <vms14       > I'll start with the hello world
2023-08-16 15:21:32 <vms14       > it's funny cause it will be several hello worlds
2023-08-16 15:21:52 <vms14       > " Hello, world!" .cr
2023-08-16 15:22:24 <vms14       > 'Hello, .sp 'world! .cr
2023-08-16 15:24:21 <vms14       > [ Hello, world! ] ' join .cr
2023-08-16 15:24:33 <vms14       > wow this one gives a segfault on rlwrap
2023-08-16 15:25:05 <vms14       > [ Hello, world! ] space join .cr
2023-08-16 15:29:30 <vms14       > oh it's the comma wtf
2023-08-16 15:29:38 <vms14       > hahahaha how broken is my lang
2023-08-16 15:31:04 <thrig       > rlwrap segfaulting does not seem encouraging
2023-08-16 15:31:11 <vms14       > it's not rlwrap
2023-08-16 15:31:58 <vms14       > it could be me breaking the system
2023-08-16 15:32:39 <vms14       > but it's likely to be a bug
2023-08-16 15:32:55 <vms14       > ah I know
2023-08-16 15:33:12 <vms14       > it's cause I override '.' in curses and load it with a init.file
2023-08-16 15:33:13 <thrig       > segfaults are usually not not bugs
2023-08-16 15:33:14 <vms14       > XDDD
2023-08-16 15:33:31 <vms14       > '.' is calling curses addstr without a initscr
2023-08-16 15:33:40 <vms14       > therefore the segfault
2023-08-16 15:33:54 <vms14       > it's not the comma, I just can't execute .
2023-08-16 15:34:15 <vms14       > a reason to not override it
2023-08-16 15:34:44 <vms14       > now it works if I don't load curses
2023-08-16 15:35:10 <vms14       > https://termbin.com/31pl
2023-08-16 15:35:29 <thrig       > probably you should always call initscr, or have a list-of-things-that-will-trigger-an-initscr
2023-08-16 15:36:42 <vms14       > I could wait to override '.' until initscr is called
2023-08-16 15:36:58 <vms14       > and recover when endscr
2023-08-16 15:37:14 <vms14       > but it looks like I should not override it
2023-08-16 15:37:23 <vms14       > just call it addstr
2023-08-16 15:39:57 <vms14       > brb
2023-08-16 16:15:32 <vms14       > https://termbin.com/t9jm
2023-08-16 16:15:43 <vms14       > will this scare them? xd
2023-08-16 16:16:26 <veltas      > segfaults as designed
2023-08-16 16:17:46 <thrig       > iconv(3) was segfaulting on me so I went with libutf8proc instead
2023-08-16 18:45:12 <veltas      > Okay well I'm going to write PACKAGE first
2023-08-16 18:45:22 <veltas      > nn
2023-08-16 20:31:34 <vms14       > https://termbin.com/i7ji
2023-08-16 20:34:03 <vms14       > if for some reason you want to play with the lang, this is a script you can just call with perl
2023-08-16 20:34:22 <vms14       > https://termbin.com/0c9zh
2023-08-16 20:34:29 <vms14       > perl this.file
2023-08-16 20:34:44 <vms14       > I use rlwrap as it does not have readline features
2023-08-16 20:35:22 <vms14       > rlwrap -A -b '' -f /home/vms/words -c --no-children --no-warnings perl this.file "$@"
2023-08-16 20:35:54 <vms14       > and words can be created with this:  perl this.file e "words '.cr do.list" > words
2023-08-16 20:46:26 <vms14       > meh I have a lot of stuff to document
2023-08-16 22:34:49 <xelxebar    > lbuffer #guix
2023-08-16 22:34:55 <xelxebar    > Gah