2022-12-05 04:28:15 <gordonjcp   > KipIngram: I should really look into Lisp some time
2022-12-05 04:28:20 <gordonjcp   > KipIngram: any pointers on getting started?
2022-12-05 08:07:56 <KipIngram   > gordonjcp: let me see if I can dig up any of the things I looked at in my history.  I knew absolutely  nothing about it before hand, but managed to find some notes out there on implementation of the really basic core.
2022-12-05 08:08:47 <KipIngram   > Apparently modern lisps have a lot of "optimizations" they put in to increase performance and I didn't learn anything about those.  But if the goal is just to "make it work," it looked not too much different in simplicity from Forth.  I felt like it was probably a similar level of project.
2022-12-05 08:10:11 <KipIngram   > If you want to look too, try to find something on "Lisp in Lisp"; apparently the "core engine" can be expressed in Lisp, and then if you look at that you see there's only a handful of function encapsulated in it - a set of things that each look not too hard to pull together.
2022-12-05 08:13:01 <KipIngram   > Also, here is a simple Lisp implementation in C:
2022-12-05 08:13:03 <KipIngram   > https://github.com/kimtg/ToyLisp
2022-12-05 08:13:43 <KipIngram   > This was a year ago or more so I'm a little fuzzy on it, but it wouldn't hurt me to peruse it again either, so I'll dig around a little.  Got a dentist appointment in a few minutes, but I'll look around later.
2022-12-05 08:17:34 <KipIngram   > There's also this, which bills itself as a 'three line Lisp' in Python.  One of those lines is really long, though, so it's not quite as simple as the label brags.  But it's not so long as to be ridiculous, either.
2022-12-05 08:17:36 <KipIngram   > https://github.com/techieji/nanolisp?ref=pythonawesome.com
2022-12-05 08:17:55 <KipIngram   > Neither of those is what I really want to find, though.
2022-12-05 08:23:12 <KipIngram   > http://kjetilvalle.com/posts/original-lisp.html
2022-12-05 08:24:27 <veltas      > olle: If you don't understand something just ask in here, there's no bar for entry
2022-12-05 08:25:35 <veltas      > We don't mind helping people who are brand spanking new to Forth or who have trouble with the basic words, because frankly it's not very active and we want more forthers
2022-12-05 08:31:07 <KipIngram   > Indeed.
2022-12-05 11:24:27 <lagash      > I'm excited for the upcoming Gforth 1.0! I tried the latest version uploaded to Google Play and actually made some progress!
2022-12-05 11:24:30 <lagash      > Now if only it could be built for F-Droid..
2022-12-05 11:25:11 <olle        > veltas: sure, thanks :)
2022-12-05 11:26:19 <thrig       > 1.0? ima wait for service pack 2
2022-12-05 11:28:53 <lagash      > Oh - there's already been a FRP - https://gitlab.com/fdroid/rfp/-/issues/2112
2022-12-05 11:30:56 <crc         > lagash: is there an anything on
2022-12-05 11:31:17 <crc         > when 1.0 is being released?
2022-12-05 11:33:04 <veltas      > What would be better than 1.0 is any version at all, without fanfare
2022-12-05 11:33:52 <veltas      > How long has it been now since a proper 'release'
2022-12-05 11:34:17 <veltas      > I worry they have not released for so long they feel compelled to do something special for the next
2022-12-05 11:36:21 <thrig       > Stable release   0.7.3 / June 14, 2014; 8 years ago
2022-12-05 12:06:16 <lagash      > crc: well, there was a mailing list post by Bernj about an upcoming 1.0..
2022-12-05 12:23:07 <crc         > I see a brief mention of this in July. https://lists.gnu.org/archive/html/gforth/2022-06/msg00002.html
2022-12-05 12:25:34 <crc         > but I'd temper expectations. See https://lists.gnu.org/archive/html/gforth/2018-01/msg00005.html when they were hoping to have 1.0 back in 2018.
2022-12-05 12:33:35 <lagash      > Regardless, Android support is shaping up.
2022-12-05 12:39:32 <KipIngram   > Wow; GForth's been around an awful long time to just now be getting to "1.0."
2022-12-05 12:41:24 <thrig       > wherein it is discovered that some humans attach actual meaning to a 1.0 (super buggy) or a 0.01 (hella stable)
2022-12-05 12:43:52 <KipIngram   > Do we know what this meaning is in this case?
2022-12-05 12:44:34 <Zarutian_iPad> this is why one should use named releases that have no rhyme nor reason to the names
2022-12-05 12:45:34 <KipIngram   > I would expect a "pre 1.0" release to be... "missing something" deemed critical to completeness.  And I just never felt like GForth seemed to be missing anything - if anything it had everything up to and including the kitchen sink.
2022-12-05 12:46:50 <KipIngram   > It's always felt "massive" to me.
2022-12-05 12:48:14 <Zarutian_iPad> which is to me sign of unfinished 1.0 release, bloated and yet to be rendered down
2022-12-05 12:48:34 <KipIngram   > Well, that's fair.
2022-12-05 12:48:37 <thrig       > chrome is at 100 something and with eight zerodays this year doesn't seem fit for production
2022-12-05 12:52:54 <crc         > "If your question is: Why is Gforth-1.0 (which is the next version) not out yet, the answer ist: Mostly because I have not found the time to complete the documentation."
2022-12-05 12:54:39 <KipIngram   > Interesting.  I always had the perception that GForth was the product of a rather substantial team - that makes it sound like it's mostly a one-person effort.
2022-12-05 12:55:40 <crc         > it's mostly anton and bernd; with occasional other help
2022-12-05 17:27:04 <vms14       > decay: were you the one who wondered about a remote multiuser forth?
2022-12-05 17:27:25 <decay       > yep.
2022-12-05 17:28:50 <vms14       > I'm wondering too xD
2022-12-05 17:29:21 <vms14       > won't be a real forth and also a super slow lang, but I'm going to be able to run multiple instances of the interpreter
2022-12-05 17:29:50 <vms14       > so should be easy to provide similar stuff like your idea
2022-12-05 17:31:18 <vms14       > the interpreter has a stack and several packages, packages could sync somehow, so I could have several interpreters running and sync the packages or changing the stack for every user (with race conditions and alike)
2022-12-05 17:32:15 <vms14       > still would be nice to be able to serialize the dictionary so it can be sent remotely, this way the cpu could be used from the user machine instead
2022-12-05 17:34:04 <vms14       > or can just be a server running several interpreters with their own stack, but the same dictionary
2022-12-05 17:34:50 <vms14       > it's easier that way as dictionaries are a reference so adding words could automatically affect the other interpreters
2022-12-05 17:35:38 <vms14       > this way only a socket for reading the source code and printing results is needed
2022-12-05 21:34:53 <KipIngram   > The traditional way of handling multiple users is to have two categories of variables; one set is referred to as "user variables," and they come per user.  One way of doing that is to keep them in the same block of RAM the stacks are in; each one has its own offset in that region.
2022-12-05 21:35:19 <KipIngram   > A pointer to that region is part of the context of a user session.
2022-12-05 21:35:47 <KipIngram   > It's pretty easy to know if a particular variable should be one system wide or per-user.
2022-12-05 21:36:18 <KipIngram   > Give each user a personal vocabulary so their definitions don't conflict with one another.
2022-12-05 21:36:41 <KipIngram   > They could still create more vocabularies, but they'd branch off of their own private vocabulary.