2023-05-07 11:01:45 <KipIngram   > So, regarding local variables in Forth.  Some tasks involve "more than a couple" of data items.  Yes, it is definitely possible to argue that you can keep some of those in variables instead of on the stack, and that that can avoid the need to noodle around with a deep stack.  But, in this system I'm contemplating, I'm imagining solving some problems using these communicating synchronous processes, and those
2023-05-07 11:01:47 <KipIngram   > processes sometimes get started recursively using FORK or something along those lines.  Each recursive level has to have those variables if it needs to store data other than on the stack in the usual Forth way.
2023-05-07 11:02:23 <KipIngram   > They can't all use the same set of global variables.  One way or another they need new dynamic copies of the variables for their own use.
2023-05-07 11:02:57 <KipIngram   > This could be done by "user variables" that live in each threads task block.  Or by explicitly allocating memory dynamically.  Or by allocating locals on the stack.
2023-05-07 11:03:22 <KipIngram   > It has to be done somehow, and it might be that the ability to refer to some stack resident variables would be a good way to handle it.
2023-05-07 11:04:02 <KipIngram   > I suspect that either "user variables" or "stack based locals" would be the most efficient approaches.
2023-05-07 11:05:56 <KipIngram   > It would be easy in my stack frame system to give { a parameter (a local variable count) - those would just be indexed off of the frame pointer in the opposite direction from input parameters to the frame, and { would just move SP by that many cells in addition to what I have it do now.  } would continue to just restore SP and perhaps drop some number of parameters like it does now.
2023-05-07 11:06:37 <KipIngram   > I currently have words to access "parameters" - they just index in the positive direction from the frame pointer.  Words for locals would index negative.
2023-05-07 11:21:58 <KipIngram   > Using user variables would be equally easy and maybe slightly more efficient - in that case the space would be allocated along with the task block instead of when the words were called.
2023-05-07 11:22:22 <KipIngram   > And in that case they could have names in a more straightforward way.
2023-05-07 11:23:36 <KipIngram   > And would be accessible to all the code a thread ran regardless of whether or not that code also used stack frames.
2023-05-07 11:23:38 <vms14       > I've just installed debian
2023-05-07 11:23:44 <vms14       > I could use gforth
2023-05-07 11:23:54 <vms14       > but I'm curious about making my abomination in lisp
2023-05-07 11:24:04 <KipIngram   > Groovy.  Just plain debian?
2023-05-07 11:24:08 <KipIngram   > Not a derivative?
2023-05-07 11:24:14 <vms14       > no, just debian
2023-05-07 11:24:25 <KipIngram   > I've never used the straight debian.
2023-05-07 11:24:26 <vms14       > I'm not a debian fan, but I know the stuff just works
2023-05-07 11:24:28 <unjust      > did you at least uninstall systemd?
2023-05-07 11:24:34 <vms14       > haha no
2023-05-07 11:24:45 <KipIngram   > I'm mostly exposed to Ubuntu, Fedora, and CentOS.
2023-05-07 11:24:53 <vms14       > I come to debian precisely to not have to handle anything
2023-05-07 11:25:00 <vms14       > just install stuff and have it working
2023-05-07 11:25:26 <vms14       > I've already configured basic stuff, so now it's kind of usable
2023-05-07 11:25:47 <vms14       > I usually install debian without X, then install cwm and X.org
2023-05-07 11:25:58 <KipIngram   > Fedora was actually the first Linux I ever used, back in 2003 or so, when there were still quite a few rough edges.
2023-05-07 11:26:04 <vms14       > but this time I've just set gnome, althought I'm using cwm anyways
2023-05-07 11:26:17 <vms14       > I remember having fun with xubuntu xD
2023-05-07 11:26:30 <KipIngram   > Yes, I have used a couple of the other 'buntus.
2023-05-07 11:26:48 <vms14       > I was disappointer when I come to "normal" ubuntu
2023-05-07 11:26:48 <KipIngram   > When I wanted a very lightweight system that I could run from RAM on a work computer that had Windows installed on it.
2023-05-07 11:26:58 <vms14       > dissapointed*
2023-05-07 11:27:09 <vms14       > the ubuntu wm and app launcher just sucks
2023-05-07 11:27:27 <vms14       > I don't want to live without cwm anyways
2023-05-07 11:27:55 <KipIngram   > I'm not familiar with cwm.
2023-05-07 11:28:21 <thrig       > structs or local variables might improve: https://thrig.me/tmp/prng.txt
2023-05-07 11:28:22 <KipIngram   > I originally installed Fedora way back then because I wanted to be able to run an open source schematic capture and pcb layout system.
2023-05-07 11:28:40 <vms14       > it's a stacking wm, usually people does not like it and prefer a tiling
2023-05-07 11:28:59 <vms14       > but I love for example have a pdf reader as the background and terminals on top
2023-05-07 11:29:04 <KipIngram   > I see.  I did not enjoy Ubuntu while it was going through it's "unity" phase.
2023-05-07 11:29:25 <KipIngram   > I think they were trying to work their way to an os that would work well on tablets too, but they just never got there and eventually they went back to gnome.
2023-05-07 11:29:48 <KipIngram   > I don't know why tablets proved so problematic for them.
2023-05-07 11:29:53 <KipIngram   > But it just never gelled.
2023-05-07 11:30:15 <KipIngram   > If I could run a true and proper Linux on a tablet, I'd try one again.
2023-05-07 11:30:23 <vms14       > thrig: why do you use ksh?
2023-05-07 11:30:39 <unjust      > KipIngram: you can to some degree, depending on the SoC in the tablet
2023-05-07 11:30:46 <thrig       > windows 95 came out -> lets copy that!! (in FVWM) smartphones came out -> let's copy that!! (in GNOME or whatever)
2023-05-07 11:30:58 <vms14       > KipIngram: gnome always had good reputation working with touch systems
2023-05-07 11:31:17 <KipIngram   > unjust: I may try it out at some point.  I feel like the tablet format ought to be more usable than I've previously found it to be.
2023-05-07 11:31:30 <thrig       > I use ksh because it's a small shell that's included with OpenBSD. I could use zsh if I wanted to be slightly more productive
2023-05-07 11:31:32 <KipIngram   > I've always felt like iOS and Android mostly populate tablets with "tinkertoy" apps.
2023-05-07 11:31:37 <KipIngram   > Cutesy stuff.
2023-05-07 11:31:43 <KipIngram   > Rather than serious production tools.
2023-05-07 11:31:57 <vms14       > I'm happy I finally have chrome
2023-05-07 11:32:02 <KipIngram   > I feel like a PCB layout app done well on a tablet should be super-usable.
2023-05-07 11:32:05 <KipIngram   > But you can't find one.
2023-05-07 11:32:13 <vms14       > I had to live with that stupid fox
2023-05-07 11:32:14 <KipIngram   > Not a serious high-end one.
2023-05-07 11:32:40 <KipIngram   > Or at least you couldn't last time I looked.
2023-05-07 11:32:59 <KipIngram   > Schematic capture too - both of those things are highly graphical applications.
2023-05-07 11:33:02 <vms14       > I tend to stay 3 days on linux and come back to netbsd
2023-05-07 11:33:07 <vms14       > but it makes no sense
2023-05-07 11:33:10 <KipIngram   > And if you hear ME say something needs graphics, then it probably does.
2023-05-07 11:33:17 <KipIngram   > Because I try to do console as much as I possibly can.
2023-05-07 11:33:47 <vms14       > I'll try to feel comfortable in linux
2023-05-07 11:33:50 <KipIngram   > But the tablets I've seen seem more like entertainment toys than anything else.
2023-05-07 11:33:58 <unjust      > KipIngram: there're a communities with channels on this network (such as #linux-mediatek, #linux-rockchip, #linux-sunxi) that focus on improving mainline linux kernel support of SoCs from those respective vendors - i mention them as those are fairly common in Android tablets
2023-05-07 11:34:28 <unjust      > there are probably samsung and qualcomm communities around as well, but i haven't had any interaction with them
2023-05-07 11:35:39 <unjust      > i've had GNU/Linux running on a few tablets, but the lack of touch-oriented UI software was a hinderance to usability
2023-05-07 11:36:31 <unjust      > getting a decent UNIX-like operating system on such tablets is a great stepping stone to getting a proper operating system on cell/mobile phones which are built around very similar SoCs
2023-05-07 11:39:06 <unjust      > one of the biggest stumbling blocks is acquiring or defining the device tree for the SoC and its peripherals, so depending on your appetite for risk you do have the option of rolling a non-Android rootfs and running with the kernel shipped by your device vendor
2023-05-07 11:39:42 <vms14       > it's funny cause now I'll start having crashes and alike
2023-05-07 11:39:50 <vms14       > it's not a normal thing on bsd
2023-05-07 11:39:59 <vms14       > in linux is quite common
2023-05-07 11:40:35 <KipIngram   > unjust: I've just never developed skills at that low level.
2023-05-07 11:40:51 <KipIngram   > I've thought about it at times, but just haven't "gone there."
2023-05-07 11:41:23 <KipIngram   > I'm not sure I see why it's any harder than discovering the characteristics of a notebook or desktop.
2023-05-07 11:41:39 <KipIngram   > Ultimately it's the same sort of devices.
2023-05-07 11:41:44 <unjust      > lack of adequate documentation plays a massive role in that regard
2023-05-07 11:41:56 <KipIngram   > Yeah, that makes sense.
2023-05-07 11:42:12 <unjust      > it can be very difficult to get an application (or technical) reference manual for the system-on-chips in question
2023-05-07 11:42:50 <KipIngram   > Why doesn't someone just make a NOTEBOOK without an attached keyboard?
2023-05-07 11:43:28 <KipIngram   > Why has using an SoC been a "condition" of "tablet"?
2023-05-07 11:43:46 <KipIngram   > My notebook has like a 12 or 13 hour battery life - that's just fine.
2023-05-07 11:43:49 <vms14       > I just wanted to play the constructor game
2023-05-07 11:43:51 <vms14       > https://i.imgur.com/iAWs7tz.png
2023-05-07 11:44:23 <KipIngram   > And of course I know the answer.
2023-05-07 11:44:36 <KipIngram   > The market corresponding to what I want is just too small.
2023-05-07 11:44:36 <unjust      > usually it requires NDAs, finding leaked copies on chinese (or sometimes russian) websites, getting lucky and having a vendor that actually has some source code available for the GPL licenced stuff they've used/modified that they should freely give away ... but more often than not it amounts to reverse engineering the vendors build of patched but otherwise open-source software
2023-05-07 11:44:45 <KipIngram   > MOST people WANT the toy stuff.
2023-05-07 11:45:05 <KipIngram   > All most people want to do is watch movies and play games and update their Facebook and so on.
2023-05-07 11:45:44 <vms14       > hahaha
2023-05-07 11:45:58 <thrig       > people who write forth are just plain weird
2023-05-07 11:46:09 <vms14       > well I had a lot of time living with the restrictions netbsd imposes me
2023-05-07 11:46:15 <KipIngram   > But then I can modify my question.  Apparently there is a market for notebook PCs that involves hardware that supports Linux well.  Do  none of those people want to have a tablet form factor?
2023-05-07 11:46:19 <vms14       > which are several
2023-05-07 11:46:33 <KipIngram   > thrig: I accept that accusation.
2023-05-07 11:46:44 <vms14       > the main problem is programming language support
2023-05-07 11:46:50 <vms14       > this is why I used perl so much
2023-05-07 11:46:51 <KipIngram   > Many many people would regard how I spend my time tinkering with Forth as time wasted.
2023-05-07 11:47:14 <vms14       > and now I shouldn't even continue with my abomination, but use gforth
2023-05-07 11:47:21 <KipIngram   > I don't care, though - public acceptance has never been a particular big deal to me.
2023-05-07 11:47:30 <KipIngram   > As long as I dodge "public harassment" I'm happy.
2023-05-07 11:48:39 <vms14       > if you cared you would be using java or python now
2023-05-07 11:48:58 <thrig       > in theory rust is where the bling is?
2023-05-07 11:50:50 <KipIngram   > True.  I do use Python for a fair bit of my work scripting.
2023-05-07 11:50:55 <KipIngram   > Python and bash, mostly.
2023-05-07 11:51:10 <KipIngram   > Just because it feels like the shortest line from A to B in many cases.
2023-05-07 11:51:28 <KipIngram   > At home I can tinker and play and it doesn't really matter how quickly results appear.
2023-05-07 11:51:35 <KipIngram   > At work I need to get results produced.
2023-05-07 11:55:38 <KipIngram   > And I know how to do it with bash and  Python, so I do.
2023-05-07 11:57:14 <vms14       > I think I'll play with sbcl for a while
2023-05-07 11:57:28 <vms14       > now I can use a lot of libraries
2023-05-07 12:08:52 <vms14       > I feel kind of free, but no idea if I'll stay with linux for long
2023-05-07 12:28:14 <KipIngram   > You know, I did do that one system where my .: words put the header info for those words in a temporary location, such that a later .wipe dropped those headers completely.  It occurs to me that it would be easy as pie for me to use that same mechanism to contain names for stack parameters / locals that I access through the stack frame, and user variables within a thread block as well.  That would all be very
2023-05-07 12:28:16 <KipIngram   > straightforward, and would give me a way to use names for all of those things with no long-term cost in the dictionary.
2023-05-07 12:29:06 <KipIngram   > Right now I use fixed-name words, like 2@ or something, to access frame items.  But these headers would just associate temporary names with those operations.
2023-05-07 12:30:40 <KipIngram   > .wipe would continue to drop all of this later, when I was through compiling the relevant code.
2023-05-07 13:17:30 <KipIngram   > Anyway, short way of saying all that is that there are three places you can put thread-specific variables - in the thread's main RAM block, on a heap, or on the stack.
2023-05-07 13:19:36 <thrig       > or to tape, but let's not go there
2023-05-07 13:19:41 <KipIngram   > :-)
2023-05-07 13:20:00 <thrig       > ... renting a mcdonalds to try to read the Apollo tapes later ...
2023-05-07 13:20:16 <KipIngram   > Well, less humorously, yeah - disk resident would work too, but then the block would have to be recursively chosen if you had recursion going on.
2023-05-07 13:20:39 <KipIngram   > It's kind of interesting to think about what sort of things work well around disk storage in Forth.
2023-05-07 13:21:07 <KipIngram   > In past systems I've used a dedicated RAM region to store command history, but I think next time I implement it I'm going to use disk blocks.
2023-05-07 13:21:34 <KipIngram   > You know, this:
2023-05-07 13:21:39 <KipIngram   > https://www.youtube.com/watch?v=1W1_8IV8uhA
2023-05-07 13:21:54 <KipIngram   > is interesting.  It's a teaser video for a crowd-funded Star Trek movie effort some years ago.
2023-05-07 13:22:08 <KipIngram   > It never got made, not because their funding failed but because Paramount threw up legal objections.
2023-05-07 13:22:39 <KipIngram   > I think Paramount should absolutely own rights to the movies they make themselves, but at this point, with Roddenberry dead, I don't think anyone should own rights to "Star Trek as a concept."
2023-05-07 13:22:51 <KipIngram   > I think it should be fair game for anyone who can pull an effort off.
2023-05-07 13:23:00 <KipIngram   > I'd love to have gotten to see the movie that video was plugging.
2023-05-07 13:23:17 <thrig       > pretty sure the Klingon thing didn't go to court (is Klingon the language controlled by paramount, or not?)
2023-05-07 13:23:31 <KipIngram   > It basically would have been a prequel revolving around the birth of the starship class we saw in the original series.
2023-05-07 13:24:02 <KipIngram   > I feel fairly sure Paramount didn't actually develop that as an actual language, so I know what I think the answer should be.
2023-05-07 13:24:28 <KipIngram   > On the other hand, Tolkien actually fleshed out languages for his Middle Earth peoples, so that was a different situation.
2023-05-07 13:24:55 <thrig       > they hired a linguist iirc
2023-05-07 13:25:06 <KipIngram   > I think copyrights should definitely last the life of the original creator, but after that I'm of mixed feelings.
2023-05-07 13:25:12 <KipIngram   > It shouldn't just go on forever.
2023-05-07 13:25:37 <thrig       > it stopped being age of mickey mouse + 20 years only recently. but still too long
2023-05-07 13:25:47 <KipIngram   > Paramount?  Ok, well, fair enough.  I thought Klingon as a full language was something cooked up by the public, but I've never really looked into it.
2023-05-07 13:26:22 <KipIngram   > Yeah.  I'm not sure it should go beyond "life of creator" at all, though if a creator died early that might not be a fair way to do it.
2023-05-07 13:26:42 <KipIngram   > Maybe life of creator and spouse, and adulthood of children.  Maybe plus a few years.
2023-05-07 13:26:57 <thrig       > Marc Okrand made the language, For Star Trek III: The Search for Spock (1984), director Leonard Nimoy ... commissioned a full language ...
2023-05-07 13:27:02 <KipIngram   > If a successful writer dies young, he at least ought to be able to go feeling that his kids would be ok.
2023-05-07 13:27:24 <Zarutian_iPad> I am on the opinion that copyright of a work should be 14 years from the publishment of the work then each year beyond that the copyright holder can pay a fee that increases say 1.25x every year to keep the copyright active.
2023-05-07 13:28:02 <KipIngram   > I would be open to a longer period if the rights were kept within the family.  I mostly just don't want corporations to be able to snatch them up and keep them for ridiculous periods of time.
2023-05-07 13:28:06 <thrig       > "author dies" has the problem of "some lady owns the IP and controls it with an iron fist" (as happened for Borges)
2023-05-07 13:28:19 <KipIngram   > But if you tried to nuance it like that people would lawyer ways around it.
2023-05-07 13:28:40 <Zarutian_iPad> the starting fee can be like that of an overpriced coffee cup or some such
2023-05-07 13:28:45 <KipIngram   > Yeah, there's no "perfect answer."
2023-05-07 13:29:08 <KipIngram   > Ultimately we just have to decide on something, but I think at least in the example of Star Trek what we've decided on isn't really good.
2023-05-07 13:29:17 <KipIngram   > Those folks should have been able to make that movie.
2023-05-07 13:29:30 <KipIngram   > They were succeeding.
2023-05-07 13:29:55 <KipIngram   > And it looked like it was potentially a great addition to the lore.
2023-05-07 13:30:10 <KipIngram   > That teaser is just extremely well done.
2023-05-07 13:30:21 <thrig       > https://www.theguardian.com/culture/2016/apr/29/star-trek-fan-film-klingon-paramount-cbs-lawsuit
2023-05-07 13:30:23 <KipIngram   > If you haven't seen it it's worth the 20 minutes.
2023-05-07 13:30:37 <thrig       > ah, that was for the film
2023-05-07 13:30:55 <KipIngram   > Yeah, I followed some of it a few  years ago when I first came across that video.
2023-05-07 13:31:07 <KipIngram   > Things didn't look promising.
2023-05-07 13:32:57 <KipIngram   > Back to Forth, my thinking on what level dynamic memory should first come into a system has oscillated over the years.  I think I'm swinging back to the idea that it should be present right at the ground floor.  So many of the things I've been thinking about do need the ability to grab block of RAM.
2023-05-07 13:33:40 <KipIngram   > I'm back to thinking I should "start up" with a big chunk of RAM available and have ways of doling it out immediately available.
2023-05-07 13:42:30 <KipIngram   > Right away when I start up I need these five regions, for the tables, the bodies, the headers, and the disk buffers.  More for snapshots.  More for temporary headers.  More for child tasks.  Etc. etc.  It's getting to be a substantial list.
2023-05-07 13:42:56 <KipIngram   > More for pipes.
2023-05-07 14:00:40 <KipIngram   > https://people.cs.umass.edu/~emery/pubs/berger-pldi2001.pdf
2023-05-07 14:58:39 <jgaz        > Is there a good resource to help me understand how to go arbitrarily deep into the stack to perform operations? Ex. Go X deep and reverse the contents of the entire stack? I really feel like I need some flow-charts and semi-hand holding here.
2023-05-07 14:59:47 <thrig       > usually the e.g. gforth tutorials cover common stack dances
2023-05-07 15:01:02 <jgaz        > thrig, okay I'll look at the gforth tutorial.
2023-05-07 15:01:34 <jgaz        > thrig I'm working my way through Starting Forth and some things are not yet clicking.
2023-05-07 15:01:39 <jgaz        > thanks
2023-05-07 15:05:00 <thrig       > starting forth may require adjustments because the cell size is now often different
2023-05-07 15:06:42 <jgaz        > thanks
2023-05-07 15:19:00 <unjust      > jgaz: sequential calls to ROLL can reverse the stack
2023-05-07 15:20:32 <unjust      > 1 2 3 4 5  ok
2023-05-07 15:20:32 <unjust      > 1 ROLL .S <5> 1 2 3 5 4  ok
2023-05-07 15:20:41 <unjust      > 2 ROLL .S <5> 1 2 5 4 3  ok
2023-05-07 15:20:41 <unjust      > 3 ROLL .S <5> 1 5 4 3 2  ok
2023-05-07 15:20:50 <unjust      > 4 ROLL .S <5> 5 4 3 2 1  ok
2023-05-07 15:21:13 <unjust      > : REV 1 ?DO I ROLL LOOP ;
2023-05-07 15:21:36 <unjust      > 5 REV .S <5> 1 2 3 4 5  ok
2023-05-07 15:26:17 <tabemann    > the big thing about ROLL is that it's horribly inefficient
2023-05-07 15:29:01 <KipIngram   > Looks like the primary strategy for improving memory management efficiency is having a general purpose allocator at the bottom, but allocating large block from it which you then allocate fixed size items from with a simple free list scheme - so you'd get all the memory for all the child tasks, for example, of a given type that an application would need in one shot.  Then use it, with the app-specific fixed
2023-05-07 15:29:03 <KipIngram   > size allocator, and then when you're all done free it.
2023-05-07 15:29:18 <KipIngram   > Not too different from what I had thought about doing using ropes for the second layer.
2023-05-07 15:29:31 <unjust      > tabemann: prefer to write words to swap stack cells in place?
2023-05-07 15:29:31 <MrMobius    > jgaz: don't be afraid to use variables when you need to. this is Chuck Moore's advice. it is cute to keep everything in the first 3 levels of the stack but that doesnt really work beyond toy examples
2023-05-07 15:29:32 <KipIngram   > Though I'd envisioned a fixed size allocator for the bottom layer too.
2023-05-07 15:30:13 <KipIngram   > Yeah, ROLL is awful.
2023-05-07 15:30:14 <tabemann    > unjust: I prefer to just store values as local variables on the return stack, which I can easily access via LDR R6, [SP, #x] and STR R6, [SP, #x]
2023-05-07 15:30:26 <MrMobius    > you can also make a primitve type of object once you know how to use CREATE so you only have to store a pointer on the stack and can reference multiple pieces of data offset from that like members. that's what Chuck does for triangles for example
2023-05-07 15:30:27 <tabemann    > far, far more efficient
2023-05-07 15:30:31 <KipIngram   > ROT is bad in the same way, but at least it's the minimum case of ROLL.
2023-05-07 15:30:41 <KipIngram   > It's the "least bad" of all ROLLs.
2023-05-07 15:30:51 <tabemann    > the thing about ROT is that it's hard-coded
2023-05-07 15:30:57 <tabemann    > which speeds it up
2023-05-07 15:30:58 <KipIngram   > Yes.
2023-05-07 15:31:01 <tabemann    > but it's still inefficient
2023-05-07 15:31:04 <KipIngram   > True.  No loop required.
2023-05-07 15:31:10 <tabemann    > but arbitrary ROLL? ick
2023-05-07 15:31:32 <KipIngram   > Just a pair of xchg instructions.
2023-05-07 15:31:39 <KipIngram   > Which really isn't that bad.
2023-05-07 15:31:39 <unjust      > well he asked for a way to reverse the stack from an arbitrary location, seemed like the most concise way of achieving it
2023-05-07 15:31:49 <unjust      > s/location/depth/
2023-05-07 15:31:53 <KipIngram   > What made you want that?
2023-05-07 15:32:09 <KipIngram   > Just a toy problem to solve?
2023-05-07 15:32:33 <unjust      > < jgaz> Is there a good resource to help me understand how to go arbitrarily deep into the stack to perform operations? Ex. Go X deep and reverse the contents of the entire stack?
2023-05-07 15:32:57 <KipIngram   > I don't know of one.  It's a terrible thing to wind up needing to do.
2023-05-07 15:33:34 <KipIngram   > Most traditional Forths only offer PICK and ROLL for deep in the stack operations - there is no "store" equivalent of  PICK most of the time.
2023-05-07 15:34:09 <KipIngram   > I.e., you normally have PICK, which is sort of <n>@, but you don't have an <n>! to go with it.
2023-05-07 15:34:20 <tabemann    > if your're trying to reverse the stack you're doing things wrong
2023-05-07 15:34:23 <tabemann    > *you're
2023-05-07 15:34:34 <KipIngram   > Yeah, you executed your earlier code in a bad order.
2023-05-07 15:34:57 <tabemann    > if you really need to access things in the opposite order, push them onto the return stack then pop them one at a time
2023-05-07 15:34:59 <tabemann    > or
2023-05-07 15:35:11 <KipIngram   > Part of Forth programming is to arrange for the stack to be how you need it to be as much of the time as possible.
2023-05-07 15:35:13 <tabemann    > use local variables (which will probably internally use the return stack, as is the case with my Forth)
2023-05-07 15:36:31 <tabemann    > but yeah, reversing an arbitrary number of items on the stack tells you that you should probably reconsider what you're doing
2023-05-07 15:37:01 <KipIngram   > If you really wanted to do this, you'd probably need to use SP@ and make a pair of pointers to the top of stack and the deepest items and then loop over exchanging those slots, moving the pointers toward each other until you're done.
2023-05-07 15:37:12 <tabemann    > yes
2023-05-07 15:37:16 <KipIngram   > I.e., you'd wind up just using @ and ! on those pointers.
2023-05-07 15:37:47 <KipIngram   > You'd have to know whether your stack grows up or down, but you probably do know that (usually it's down), and you certainly could find out.
2023-05-07 15:38:07 <tabemann    > KipIngram, that doesn't work, though, if you're using a Forth that uses a TOS register
2023-05-07 15:38:22 <tabemann    > as is the case with most faster Forths
2023-05-07 15:38:33 <KipIngram   > But you could put a dummy item on the stack to get all of the original stack in RAM.
2023-05-07 15:38:40 <KipIngram   > But yes, you're right - I should have noted that.
2023-05-07 15:38:49 <KipIngram   > I imagine most Forths do cache the TOS.
2023-05-07 15:39:09 <tabemann    > what you'd have to do is stick a dummy value on the TOS
2023-05-07 15:39:16 <tabemann    > and then drop it once you're done
2023-05-07 15:39:20 <KipIngram   > I do that when I take a system snapshot - I DUP so that all the stack info is in RAM and thus in the snapshot.
2023-05-07 15:39:28 <KipIngram   > And then when I restore a snapshot I DROP.
2023-05-07 15:43:48 <tabemann    > bbiab
2023-05-07 15:47:44 <KipIngram   > Also, it looks like best practice in memory allocation is to handle small, medium, and large requests differently.  Requests for up to 64 bytes are considered "small," from there up to 128k medium, and larger than 128k large.
2023-05-07 15:48:13 <KipIngram   > The small allocator looks like it uses one memory region and it has a free list for each of the cell counts, 1-8.
2023-05-07 15:48:28 <thrig       > Very Large Stack Integration
2023-05-07 15:48:48 <KipIngram   > That's fine, but I suspect most of the stuff I'm thinking off will be either large or medium.
2023-05-07 15:49:28 <KipIngram   > That small list supports coalescing adjacent free blocks, if they're aligned right.
2023-05-07 15:50:51 <KipIngram   > I'm not sure I'm worried enough about small requests to fret too much over them - I might just allocate 64 bytes even if the request was for less.  Then it's just a fixed size allocator, pure and simple.
2023-05-07 17:37:42 <KipIngram   > The thing I don't like about a lot of documented RAM allocators is that there is management data in allocated chunks.  At least for my disk buffers, I want them to being right on a 4kB boundary, and for them to be contiguous with one another.  A large region allocated for those would want to have management data right at the beginning, which throws off that "start on a 4kB boundary."
2023-05-07 17:43:54 <MrMobius    > just curious, is there a hardware reason for the 4k boundary? like could each chunk really be 4.01K because you need 0.01K for meta data?
2023-05-07 17:58:24 <KipIngram   > Yeah, I want to be able to use shifts while indexint into the array of buffers.
2023-05-07 17:58:31 <KipIngram   > indexing
2023-05-07 17:58:53 <KipIngram   > But that's more an argument for having then contiguous.
2023-05-07 17:59:05 <KipIngram   > Strictly spaking I guess it wouldn't HAVE to start on a 4k boundary.
2023-05-07 17:59:22 <KipIngram   > The individual buffers wouldn't have anything to do with the memory management - they'd just all happen to be in the same big block.
2023-05-07 17:59:36 <KipIngram   > So maybe I should say no - except aesthetics.
2023-05-07 18:00:15 <KipIngram   > I don't plan to treat each buffer as an allocated item.
2023-05-07 18:00:21 <KipIngram   > Just the whole array of buffers.
2023-05-07 18:01:14 <KipIngram   > And also because a fixed size allocator is just really friendly in this regard - it doesn't need to store any data at all in an allocated block.
2023-05-07 18:01:25 <KipIngram   > Only in freed blocks, and then it's totally ok of course.
2023-05-07 18:02:31 <KipIngram   > So maybe I'm just trying to haul that nicety of the fixed size allocator into a domain that doesn't really support it.
2023-05-07 18:16:47 <veltas      > If you have a b-tree of free blocks (1 block per b-tree node), then you can find out whether nearby space to an allocated block is free or not quickly
2023-05-07 18:18:32 <veltas      > And if you have an array of different size classes of free block you can find an appropriate size free block quickly for allocations
2023-05-07 18:19:04 <veltas      > I believe all of this is possible without storing anything with allocated blocks
2023-05-07 18:20:06 <veltas      > And it's possible without storing anything in free blocks, if your lists of free blocks are represented compactly rather than within free blocks (which you want for disk access anyway)
2023-05-07 18:20:45 <veltas      > And you want that for flash so you can properly discard freed blocks
2023-05-07 18:22:13 <veltas      > If you make it this complicated you might as well implement journalling as well
2023-05-07 18:22:33 <veltas      > IMO just "keep it simple, simon"
2023-05-07 18:25:48 <KipIngram   > That's certainly a good point re: disk space - you don't want free blocks used at all.
2023-05-07 18:26:22 <KipIngram   > I'm primarily thinking about RAM management today, but whatever extent they could be similar would be good.
2023-05-07 18:26:36 <KipIngram   > (without sacrificing excessive performance).
2023-05-07 18:26:53 <veltas      > I think journalling allows you to simplify this a lot
2023-05-07 18:28:16 <veltas      > Bookkeeping and structural info can be kept in an almost linear fasion, in one part of disk, and loaded fully into RAM when mounting
2023-05-07 18:30:44 <veltas      > Journal it all until you run out of space and then rewrite the structure and update blocks as needed or in downtime
2023-05-07 18:31:00 <veltas      > And you can recover the journal in event of a crash
2023-05-07 18:32:18 <veltas      > So the 'fast data structure' that keeps track of all this in RAM, the disk just holds a compact linear form that can be quickly loaded/serialised from/to disk
2023-05-07 20:32:06 <vms14       > https://rosettacode.org/wiki/Draw_a_pixel#Forth
2023-05-07 20:32:17 <vms14       > I was able to run this example time ago with debian
2023-05-07 20:32:20 <vms14       > I can't anymore
2023-05-07 20:32:35 <vms14       > sdl is working, at least a hello sdl world in c works
2023-05-07 20:33:26 <vms14       > this is sad, I thought I could use gforth
2023-05-07 20:34:57 <thrig       > not the easiest thing to compile
2023-05-07 20:35:16 <vms14       > thrig: last time it worked by just installing gforth and libsdl-dev
2023-05-07 20:35:34 <vms14       > libsdl2-dev
2023-05-07 20:35:51 <vms14       > I assume something changed in gforth?
2023-05-07 20:36:08 <vms14       > it fails to compile the code it generates
2023-05-07 20:37:02 <vms14       > oh it works now
2023-05-07 20:37:03 <vms14       > :D
2023-05-07 20:37:13 <vms14       > just needed to install libtool-bin
2023-05-07 20:37:25 <vms14       > because libtool only wasn't cool enough
2023-05-07 20:38:37 <vms14       > I would like to have this working on netbsd
2023-05-07 20:39:43 <vms14       > ah, gforth stopped working on netbsd
2023-05-07 20:39:57 <vms14       > there's not a binary anymore, and I guess pkgsrc failed
2023-05-07 20:44:15 <unjust      > it shouldn't be too difficult to compile it yourself, without pkgsrc
2023-05-07 20:44:48 <vms14       > yeah
2023-05-07 20:45:34 <vms14       > the effort on making gforth work properly on netbsd would be much less than making a shitty lang that and the end is not exactly what I wanted
2023-05-07 20:45:42 <vms14       > at*
2023-05-07 20:46:19 <vms14       > but it's weird that the binary is present on all other archs except amd64
2023-05-07 20:46:28 <vms14       > it existed and was working, but not anymore
2023-05-07 20:47:44 <unjust      > probably lack of interest from pkg maintainers? it shouldn't be much more effort than to download the 0.7.3 tarball, extract it, then: mkdir build; cd build; ../configure; make; make install
2023-05-07 20:48:11 <vms14       > it failed don't remember why
2023-05-07 20:48:14 <unjust      > then setting GFORTHPATH and getting gforth.fi into the right place
2023-05-07 20:48:18 <vms14       > at least pkgsrc failed
2023-05-07 20:48:57 <vms14       > pkgsrc is at the end a makefil
2023-05-07 20:49:14 <thrig       > gforth for openbsd needs a few patches
2023-05-07 20:49:41 <thrig       > not a craaaaazy number like chromium needs, but not zero
2023-05-07 20:49:50 <unjust      > i ditched netbsd as my primary operating system a few years back because of the terrible state pkgsrc was in
2023-05-07 20:50:43 <vms14       > :0
2023-05-07 20:50:57 <vms14       > I love netbsd, but now I'm on linux and life is just easy
2023-05-07 20:51:18 <vms14       > still I can't stay more than 3 days outside netbsd for some reason
2023-05-07 20:52:08 <vms14       > I realized the real reason I like netbsd so much is because is the system that forces me to learn more, without counting stuff like plan9
2023-05-07 20:52:51 <vms14       > but also like to the minimalism and to launch top and see 26 processes running instead of 100
2023-05-07 20:53:08 <vms14       > Tasks: 182 total
2023-05-07 20:53:12 <vms14       > in debian
2023-05-07 20:53:19 <vms14       > it's 26 on netbsd xD
2023-05-07 20:53:36 <unjust      > it's a little unfair to compare netbsd to a fat linux distribution in that regard
2023-05-07 20:53:40 <thrig       > 62, but I'm running a bunch of things at the moment
2023-05-07 20:53:44 <vms14       > yeah
2023-05-07 20:53:52 <unjust      > compare it to a minimal userland based on busybox and musl
2023-05-07 20:54:14 <unjust      > and a well-optimised linux kernel, instead of a catch-all shipped by a popular distributor
2023-05-07 20:54:14 <vms14       > at least openbsd has chrome
2023-05-07 20:54:35 <vms14       > I wonder why we never stole it from openbsd
2023-05-07 20:54:56 <unjust      > is it a chromium build or google-chrome running under linux bin emulation?
2023-05-07 20:55:00 <vms14       > chromium
2023-05-07 20:55:22 <thrig       > with a billion patches because google don't care about bsd
2023-05-07 20:56:47 <thrig       > hmm, the virt has ~55 processes to run httpd, smtpd, rspamd, gmid
2023-05-07 20:56:49 <vms14       > no one cares about bsd
2023-05-07 20:57:18 <vms14       > I still wait for the sbcl team to add threads on netbsd's sbcl
2023-05-07 20:57:41 <vms14       > but a bsd user tends to do the stuff for itself
2023-05-07 20:57:58 <thrig       > openbsd sbcl has :SB-THREAD
2023-05-07 20:58:12 <thrig       > but compiling from quicklisp is sometimes a crapshoot
2023-05-07 21:03:03 <vms14       > 
ACTION wonders whether to betray netbsd with his sister

2023-05-07 21:03:10 <vms14       > her*
2023-05-07 21:14:53 <vms14       > I would live happy if Xen worked on this machine