2023-02-10 01:00:13 <KipIngram   > joe9: I'm having a really hard time with this book.  I feel like I'm in kindergarten being taught my ABCs.  Seriously, how dead can they beat this horse?
2023-02-10 01:00:57 <KipIngram   > This really isn't a "plan9 book."  This is an "operating systems book," and man, it is BEGINNER.
2023-02-10 07:58:06 <veltas      > KipIngram: plan9 is an Operating System, and I would expect a manual to plausibly try and explain 'everything'
2023-02-10 07:59:21 <veltas      > For example the ZX Spectrum's manual assumes a beginner. Not assuming that would have left out most of their audience. The plan9 OS was meant to be used by advanced users and people who had never used a computer before alike
2023-02-10 07:59:56 <veltas      > Also there are features plan9 pioneered we take for granted now, that needed explaining
2023-02-10 08:00:46 <veltas      > And if it was written pre-2000 I would expect much more detail, because people didn't have the internet as it is now to search for everything they didn't get
2023-02-10 08:09:58 <veltas      > Yearly reminder that 2/ is not 2 / or 2 U/
2023-02-10 08:10:46 <veltas      > Although 1 RSHIFT is 2 U/
2023-02-10 09:21:16 <KipIngram   > Well, yes, everything should be explained.
2023-02-10 09:21:33 <KipIngram   > And there's nothing wrong with the book - there need to be books for absolute novices to study.
2023-02-10 09:21:54 <KipIngram   > I'm just pointing out that it's pitched at an extremely simplistic level - there's just a lot of handholding.
2023-02-10 09:22:35 <KipIngram   > Which is fine - just not terribly useful for me.  It means there's a lot of stuff to wade through that doesn't really "build" me.
2023-02-10 09:26:12 <KipIngram   > Something that focused more specifically on how plan9 differs from Unix, and why, would be be more "efficient" for me.
2023-02-10 09:26:42 <KipIngram   > And how those changes were implemented, etc.
2023-02-10 10:16:05 <KipIngram   > I generally have always liked the "everything is a file" approach - it seems plan9 takes that even further than Unix does.
2023-02-10 10:28:18 <KipIngram   > MrMobius - ok; must have been Zarutian (ipfs -> blocks).
2023-02-10 10:28:55 <KipIngram   > I definitely understand the desire for something "beyond blocks," but I've always felt like Forth should offer blocks, just because that is the fundamental way the hardware works, and Forth should provide "ground floor" access.
2023-02-10 10:29:18 <KipIngram   > Honestly even Forth's usual block system is still an abstraction of sorts, because it does that default buffer management for you.
2023-02-10 10:29:58 <KipIngram   > More fundamental would just be : block_read  ( addr n -- ) ... ; and : block_write  ( addr n -- ) ... ;
2023-02-10 10:30:12 <KipIngram   > which would leave the memory side of things to you as well.
2023-02-10 10:30:36 <KipIngram   > But at least it reduces the disk side to it's fundamental level.
2023-02-10 10:31:14 <KipIngram   > I usually go to a fair bit of trouble to make the "already resident in RAM" path through BLOCK as fast as I can possibly  make it.
2023-02-10 10:31:48 <KipIngram   > I usually structure it as a primitive, which does the residency test; if the block isn't 'resident then I launch a Forth definition to handle that.
2023-02-10 10:32:34 <KipIngram   > And I usually use quite a large number of block buffers.
2023-02-10 10:34:04 <thrig       > stinky noises about everything a file: https://www.youtube.com/watch?v=9-IWMbJXoLM
2023-02-10 10:34:08 <KipIngram   > Hey, has anyone ever suggested a really sleek way of loading and running pre-compiled Forth code?  And doing it in a way that lets you load some code, run it, and then unload it, without having to unload everything else you loaded afterward?
2023-02-10 10:34:22 <KipIngram   > I've thought about it at times, but it's just not really an easy situation for Forth to deal with.
2023-02-10 10:34:39 <KipIngram   > thrig: Always good to listen to the other guy's argument.
2023-02-10 10:35:34 <thrig       > there's some more at https://jeamland.net/talks/
2023-02-10 10:35:37 <KipIngram   > In this system I'm planning now the main problem with that kind of dynamic usage comes from the xt table.
2023-02-10 10:36:01 <KipIngram   > I could move the loaded code itself around in RAM without that much trouble - I'd just modify the xt table entries that pointed to it.
2023-02-10 10:36:41 <KipIngram   > But the xt table itself would wind up with holes in it - a word has to keep the same xt the whole time it's loaded, and in fact in this case would only work at a fixed position in the xt table, unless I went to a good bit of trouble.
2023-02-10 10:36:49 <KipIngram   > Since the compiled code actually contains xt's.
2023-02-10 10:37:15 <KipIngram   > But even if I recompile the source every time I load it, I'd still wind up with fragmentation in the xt table.
2023-02-10 10:38:06 <KipIngram   > Which can be coped with - it would be possible to re-use them, but in doing so then words from some one block of code I loaded would get scattered out over the table, and that would make it a lot harder to remove them later.
2023-02-10 10:40:42 <KipIngram   > The best I've thought of so far would be to specify on LOAD whether the code being loaded was "permanent" or "transient," and if transient use XT slots from the high end of the table.
2023-02-10 10:40:55 <KipIngram   > At least then there would come to be no holes in the permanent section of the table.
2023-02-10 10:41:13 <KipIngram   > And you'd expect that everything in the transient section would "go away" sooner or later.
2023-02-10 10:59:40 <KipIngram   > thrig: I'm having a hard time deciding is that guys complaints are really because of the general idea of "everything is a file," vs. just about the particular way they chose to use that concept in the specific design.
2023-02-10 10:59:50 <KipIngram   > It's sort of like how you can write bad code in any language.
2023-02-10 11:00:23 <KipIngram   > I.e., there would be "bad" everything-is-a-file designs as well as good ones.
2023-02-10 11:00:56 <KipIngram   > I agree that the setup he's describing here isn't a particularly friendly design.
2023-02-10 11:05:23 <KipIngram   > I think if I were doing a file-based interface for USB what i'd WANT would be 1) I plug in my device and 2) an item for that device appears in a USB device hierarchy.  As usual in Linux that hierarchy could be organized in several ways - by device type, by vendor, etc.  So I'd just use whichever organization I wanted to find it and then would open it and talk to it.
2023-02-10 11:05:25 <KipIngram   > End of story.
2023-02-10 11:05:32 <KipIngram   > I don't see the point of all those intervening layers.
2023-02-10 11:25:25 <KipIngram   > Hmmm.  It seems like at least part of what he's complaining about is that a completely inexperienced person can't just sit down and intuitively know what to do in Unix.
2023-02-10 11:25:36 <KipIngram   > But honestly, I don't regard that as a valid objection.
2023-02-10 11:25:49 <KipIngram   > Of course you have to learn to use a system - one shouldn't expect to not face that.
2023-02-10 11:26:28 <KipIngram   > I don't know a whole lot of Unix, but nonetheless the bit I do know (grep and sed most notably) tend to get me a long way.
2023-02-10 11:26:44 <KipIngram   > head and tail go on that list too.
2023-02-10 11:26:52 <KipIngram   > Just those four things, and you can figure most stuff out.
2023-02-10 11:27:07 <KipIngram   > I'm constantly writing pipelines involving those tools.
2023-02-10 11:28:27 <KipIngram   > And I have absolutely zero use for any argument that even tries to advocate Windows over Linux.
2023-02-10 11:28:45 <KipIngram   > I don't CARE if Microsoft got a thing or two right.
2023-02-10 11:29:06 <KipIngram   > They almost had to score well a time or two, given how big the damn thing is.
2023-02-10 11:29:14 <KipIngram   > Just by luck.
2023-02-10 11:38:39 <KipIngram   > I think one thinkg typically missing from Forth is what I'll call "transient name/value associations."  We can put anything we want in the dictionary, but for the most part the dictionary is "permanent."
2023-02-10 11:39:02 <KipIngram   > It seems like there needs to be some standard and ubiquitous way of making temporary associates between names and values.
2023-02-10 11:39:21 <KipIngram   > Maybe this is the category "environment variables" would fall into.
2023-02-10 11:39:38 <thrig       > or a registry!
2023-02-10 11:39:48 <KipIngram   > Ugh.
2023-02-10 11:39:53 <KipIngram   > But yeah.  I suppose.
2023-02-10 11:39:55 <thrig       > tee hee hee
2023-02-10 11:40:20 <KipIngram   > And you really shouldn't have to know which type a name was - there should be a unified way of accessing them.
2023-02-10 11:40:34 <KipIngram   > You just know that somehow, some way, that symbol is defined.
2023-02-10 11:41:05 <KipIngram   > This doesn't necessarily have to be super high performance.
2023-02-10 11:41:36 <KipIngram   > As in, maybe it's fine to resolve the association at runtime.
2023-02-10 11:42:11 <KipIngram   > Whereas I regard the dictionary as something to be accessed only at compile time.
2023-02-10 11:42:33 <KipIngram   > Or for interpretation, of course - you dodn't necessarily have to be compiling anything.
2023-02-10 12:18:29 <KipIngram   > joe9: I'm still having a little trouble getting used to how "arbitrary" the screen layout in acme seems.  It's almost as though you just type wherever you feel like on the window.
2023-02-10 12:30:57 <KipIngram   > joe9: Plan9 and Forth; let's kibbitz.  So it seems straightforward enough to arrange something like the notion of connecting your window to another system.  That would just involve being able to do some fancy plumbing on your input and output streams.  Fine - let's say we've got that working.
2023-02-10 12:31:18 <KipIngram   > So now you'd be able to sit at your computer and type into your window and execute words in the Forth dictionary of the remote machine.
2023-02-10 12:32:02 <KipIngram   > But I could envision wanting to mount remote Forth vocabularies in your own name space, so you might have vocabularies accessible to you that were spread out across several different machines.
2023-02-10 12:32:35 <KipIngram   > So let's say I have access to foo, on machine A, bar on machine B, and bam on machine C.  These are all in my search path.
2023-02-10 12:32:39 <KipIngram   > So now I type
2023-02-10 12:32:55 <KipIngram   > : distributed  foo bar bam ;
2023-02-10 12:32:59 <KipIngram   > distributed
2023-02-10 12:33:03 <KipIngram   > What happens?
2023-02-10 12:33:17 <KipIngram   > I don't see that as an easy thing to make sense of.
2023-02-10 12:33:25 <KipIngram   > My stack has to be on some one machine, somewhere.
2023-02-10 12:33:32 <KipIngram   > So only words on that machine can act on it.
2023-02-10 12:33:54 <KipIngram   > So unless we're going to go passing stack zones around from mahine to machine, I don't see what to do with that.
2023-02-10 12:34:29 <KipIngram   > Just being able to plumb the I/O doesn't handle that, and for that matter it may not handle even being able to FIND words on multiple machines at the same time.
2023-02-10 12:34:38 <KipIngram   > be able
2023-02-10 12:36:40 <KipIngram   > But it just feels like the goal for a distributed Forth system would be to be able to use words at will, defined anywhere in your network, in any combination you wanted to.
2023-02-10 12:36:54 <KipIngram   > The whole point of mounting a remote vocabulary would be to be able to use the tools it provided.
2023-02-10 12:37:52 <thrig       > cache coherency might get tricky with multiple systems and network outages and what
2023-02-10 12:37:57 <KipIngram   > I suppose in plan9 the idea is that by connecting your i/o to a remote server, you can use that servers commands, and at the other end those commands can access your targeted files whether they're on that server or not.
2023-02-10 12:38:00 <KipIngram   > So it all works out.
2023-02-10 12:38:29 <KipIngram   > But it requires connections not just at the i/o level but at the file level also, and in Forth we're left with the stack as a resource that doesn't fit into either one of those categories.
2023-02-10 12:38:37 <KipIngram   > You bet it could.
2023-02-10 12:38:59 <KipIngram   > Multi-core issues on steroids.
2023-02-10 12:39:19 <Zarutian_iPad> re Forth and distributed computing: I rather like the idea of sending small Forth VMs around
2023-02-10 12:39:24 <KipIngram   > So I guess my most interesting question is "how does the user stack work in a distributed system"?
2023-02-10 12:40:09 <KipIngram   > Zarutian_iPad: Yes, sending a whole chunk of work off somewhere to be processed and the results sent back (or sent to some third place) - that seems fairly doable.
2023-02-10 12:40:20 <KipIngram   > It's this very fine-grain distribution that looks problematic.
2023-02-10 12:40:27 <Zarutian_iPad> so, an VM would migrate around and access big dataset throug io like interfaces or some such
2023-02-10 12:40:35 <KipIngram   > Can you distribute a Forth *program* across a network?
2023-02-10 12:40:56 <KipIngram   > Yeah, if it was flow-based, I could see that working.
2023-02-10 12:41:09 <KipIngram   > The whole VM would travel around, but at any given time it would use resources only on the local machine.
2023-02-10 12:41:23 <KipIngram   > Then you'd send the whole thing, stack included, to the next machine you needed.
2023-02-10 12:42:10 <Zarutian_iPad> you could have a Forth VM spawn another, and to keep the snapshot sizes down one could use the save state trick of the zork machine
2023-02-10 12:42:38 <Zarutian_iPad> basically a run encoded xor delta from an wellknown vm snapshot
2023-02-10 12:42:49 <KipIngram   > So say you finish what you want to do with a VM on machine A.
2023-02-10 12:43:01 <KipIngram   > Now your task definition has to get sent to machine B.
2023-02-10 12:43:13 <KipIngram   > But how to you initialize the IP for when it's turned loose on machine B?
2023-02-10 12:43:28 <Zarutian_iPad> the vm stops at A snapshoted and sent to B
2023-02-10 12:43:29 <KipIngram   > Probably some kind of serialization is required here.
2023-02-10 12:44:06 <KipIngram   > The code that causes that transfer from A to B needs to know how to prepare the vm for continued execution on B.
2023-02-10 12:44:17 <Zarutian_iPad> to the vm itjust looks like a pause between instructions
2023-02-10 12:44:29 <KipIngram   > Yes.
2023-02-10 12:44:44 <KipIngram   > Which mean sit looks like nothing.
2023-02-10 12:45:22 <KipIngram   > It seems evident that it has to know the address of a word on B, to aim IP at.
2023-02-10 12:46:03 <KipIngram   > So B catches it, makes a few tweaks, and lets it run.  When it comes back from that word, it then may need to go somewhere else.
2023-02-10 12:46:03 <Zarutian_iPad> or just each vm having its own small address space
2023-02-10 12:47:12 <Zarutian_iPad> and there is a primitive instruction that tells the vm runner to stop the vm snapshot it and send it to particular place
2023-02-10 12:49:12 <KipIngram   > The thing is, though, this is only a useful scenario for fairly coarse distribution.
2023-02-10 12:49:26 <KipIngram   > Try to make it too fine grain and your performance will be pathetic.
2023-02-10 12:49:31 <Zarutian_iPad> but this kind of distributed computing is hard and I am not sure that forth might be suitable for it
2023-02-10 12:49:46 <KipIngram   > Well, that's kind of what I'm thinking too.
2023-02-10 12:50:04 <KipIngram   > On the other hand, a distributed block/file system might be very interesting.
2023-02-10 12:50:33 <KipIngram   > As would be being able to connect your window to a remote machine.
2023-02-10 12:50:51 <Zarutian_iPad> you could have a more restricted kind of words though. One kind that are PrimitiveRecursiveAlgorithm level and they need to specify the data stack effects
2023-02-10 12:51:37 <Zarutian_iPad> then you could fire them off to places
2023-02-10 12:52:01 <KipIngram   > Yeah;  like I said, I think coarse-grain multiprocessing could be interesting.
2023-02-10 12:52:12 <Zarutian_iPad> but you would need to do the ‘returning’ yourself so to speak by having such words fire back
2023-02-10 12:52:30 <Zarutian_iPad> bbl
2023-02-10 12:52:31 <KipIngram   > And maybe it would make sense in that setting to send your stack zone off to some other machine, for a significant amount of processing, and have the results come back.
2023-02-10 12:56:29 <Stalevar    > How do I tell what encoding it is if I have its mapping table?
2023-02-10 12:57:03 <Stalevar    > I can tell from first glance it's not one of most common encodings
2023-02-10 14:23:52 <KipIngram   > I don't know any way other than finding a list of encodings somewhere and compare until you're convinced.
2023-02-10 14:45:49 <Stalevar    > for enc in `iconv -l | tr -d / | tr A-Z a-z`; do printf '\xB0\xB1\xB2\xB3' | iconv -cf "$enc"; echo " $enc"; done | grep рст
2023-02-10 14:45:54 <Stalevar    > KipIngram, this
2023-02-10 14:59:40 <KipIngram   > You just look then to see which one seems sensible?
2023-02-10 15:01:16 <Stalevar    > KipIngram, there is only one encoding
2023-02-10 15:01:50 <Stalevar    > I know the position of certain letters in common encodings so I grepped for those which have other letters where I didn't expect
2023-02-10 15:01:58 <Stalevar    > and turns out there was only one
2023-02-10 16:00:59 <KipIngram   > What did it turn out to be?
2023-02-10 16:05:57 <KipIngram   > Useful: https://help.ubuntu.com/community/GtkComposeTable
2023-02-10 19:00:27 <KipIngram   > Well, finished scanning through that plan9 book.
2023-02-10 20:36:14 <KipIngram   > I do have to say that I am fairly curious about acme.  That's in spite of the fact that I am traditionally extremely "anti-mouse."
2023-02-10 20:36:27 <KipIngram   > Maybe part of me just would like to think that someone might "save it."
2023-02-10 20:36:52 <KipIngram   > I.e., maybe it's not the mouse itself I'm against, but rather traditional typical usage of it.
2023-02-10 20:37:26 <KipIngram   > I always wind up feeling like it's most often used in an attempt to make it so people can use the computer without learning anything.
2023-02-10 20:37:44 <KipIngram   > Like it's used to graft a massive help system onto applications.
2023-02-10 20:37:56 <KipIngram   > Which is mostly what I think menu systems are.
2023-02-10 20:38:30 <KipIngram   > I think 90% of the time, users could work faster with a keyboard-based interface, but then they wouldn't have the "crutch" offered by the menus.
2023-02-10 20:39:05 <KipIngram   > I wish I could just slap acme on my system as a package and play with it.
2023-02-10 20:39:26 <KipIngram   > I did install virtual box, but I haven't gone any further toward trying to bring up a plan9 system.
2023-02-10 20:40:05 <KipIngram   > Also, I don't have a mouse - I have a trackpad, and that's generally a fairly different experience.
2023-02-10 20:49:51 <KipIngram   > This looks interesting:
2023-02-10 20:49:53 <KipIngram   > https://www.cs.tufts.edu/~nr/cs257/archive/rob-pike/conc-win.pdf
2023-02-10 20:50:49 <KipIngram   > Window systems built with concurrent design - Pike claims the approach simplifies it, and elsewhere (what led me to this paper) was that he claimed that it eliminated the "clumsy main event loop otherwise required."
2023-02-10 20:51:06 <KipIngram   > The stuff I've been recently thinking about may be "concurrency in Forth."
2023-02-10 21:08:18 <Zarutian_iPad> wait isnt VNC or RemoteFrameBuffer a decendant of this?
2023-02-10 21:10:14 <Zarutian_iPad> it seems that the paper is talking about, in a way, the Mealy machine way of doing computation
2023-02-10 21:11:28 <Zarutian_iPad> a Mealy Machine is a function that take two arguments, input and old state, and returns two things, output and new state
2023-02-10 22:18:05 <KipIngram   > I'm just now getting started reading it.  Got sidetracked.
2023-02-10 22:39:46 <KipIngram   > I am definitely on board the the  "layers" idea, in spite of the memory requirements (basically you have a bitmap for every window, off-screen, and copy from those to construct the display when necessary).
2023-02-10 22:40:02 <KipIngram   > Vs. expecting clients to redraw portions of their window on demand.
2023-02-10 22:40:14 <KipIngram   > to me that's one of the big reasons to have a lot of RAM in the first place.
2023-02-10 22:47:34 <KipIngram   > What he seems to be advocating here is to not squash all the events together into one stream, only to then have to disentagnle them with a big switch statement.
2023-02-10 22:48:03 <KipIngram   > Instead, separate them into per-device streams, each handled by its own concurrent thread.
2023-02-10 22:51:50 <KipIngram   > This sounds promising:
2023-02-10 22:51:57 <KipIngram   > "A
2023-02-10 22:51:59 <KipIngram   > complete client that connects an operating system’s command interpreter to a window, including all processing of keyboard input such as echoing, typing correction, and so on, takes about 100 lines of
2023-02-10 22:52:01 <KipIngram   > Newsqueak, distributed across three processes (keyboard, mouse, and display)."
2023-02-10 23:47:16 <KipIngram   > So this is interesting to me, because this timer tick multi-threrad thing I've been thinking about provides a very good basis for communicating concurrent processes.  So if that structure really simplifies the construction of windowing systems, I may be in a really good position to take advantage of that.
2023-02-10 23:51:20 <KipIngram   > But these processes have to be able to communicate too - I need to get that wired in as cleanly and fundamentally as the concurrency looks like it will be.
2023-02-10 23:53:19 <KipIngram   > But Pike gives a description of the necessary channels in this paper.