an activitypub implementation in forth in which the source code reads as a tutorial for implementing activitypub

@djsundog Mix in some literate programming, and as a bonus initially release it via a tootstorm

@samis by the time you're done reading the thread you're running an instance

@djsundog Oh, and the source of the tootstorm is the first instance running the forth activitypub code.

@djsundog Is somebody actually working on this?

@h not that I know of, yet, but I am definitely considering an activitypub implementation in forth on baremetal pi and would hope it would be done well enough to serve as a tutorial when it was done - it will definitely be a goal.

@h of course, I haven't sat down to write any serious forth in well over 20 years and probably closer to 30 at this point so we'll see how it goes ;)

@djsundog Please let me know if somebody starts, I want to join!

@h @djsundog Is there a minimal Forth OS on baremetal Raspberry Pi that can, eg, read from a USB keyboard, put coloured text on HDMI, and read/write files to USB flash and SD card?

Cos I would be all over that if I could get one...

(and if I could annoy my wife long enough to switch the TV's input over to the Pi)

@djsundog @h and I also don't really know any Forth but it just feels like the fastest way to get *something* interactive happening on a baremetal tiny machine

@h @djsundog ugh I guess it would also be great if it had some kind of minimal TCP/IP stack in it and also some kind of Internet-based module and package management system that was easily revertible....

@djsundog @h but given a choice between

1) machine code
2) Forth
3) Linux

it seems like 2) might hit the sweet spot of 'minimal yet extensible'?

@natecull @djsundog @h
If you're considering implementing a bootable forth for the Pi hardware, I recommend it. The easiest way to get a handle on forth is by implementing it -- and I hear writing an OS for arm is easier than x86 (though I don't have any direct experience with it).

@natecull @djsundog It's the kind of thing that could be done on Win32 using FASM. But I've long departed Win32 in a previous life, in a past century.

@natecull @djsundog @h

Once there was Nix, then there was Guix. Now there is ... Fuix!

Your suistem has problem? I fuix.

@natecull @h @djsundog Forth does not lend itself well to package management, unfortunately. It's not clear what constitutes a "package", or how to specify the desirable attributes of a package's interface. Last but not least, it's equally unclear how to support modules written using screens instead of files (e.g., for simplicity, Kestrel's Forth interpreters are all primarily screen-oriented, and may include the ANS file wordset as a loadable extension to the language).

@vertigo @natecull @djsundog Even if there is no standard spec for portable modules, maybe it's possible to borrow an arbitrary module/package/library system from one of the most popular FOSS Forths like GForth or PForth?
Or possibly some of those packages can be converted into screen-oriented binaries for a target platform.
That doesn't seem like a major engineering challenge, I don't think.

@h @natecull @djsundog I'm not familiar with PForth, but I don't recall GForth using any packaging system.

ANS Forth relies on INCLUDE-FILE or INCLUDED statements (taking a file-handle or filename, respectively) to inject the source code at the point of inclusion. This is analogous to C's #include preprocessor directive.

SwiftForth does the same, but it additionally provides a means of building pathnames with standard components. With a dir naming convention, you can get NPM-like features.

@djsundog @natecull @h However, I'd advocate some additional processing of a module's name to help isolate the naming convention from the underlying filesystem (Kestrel's SL5 filesystem, for example, lacks sub-directories).

I've been thinking of exploring a solution to this problem in the future, based on my experiences working with packages in an Enterprise-IT context.

@vertigo @djsundog @natecull
You can make up for the lack of filesystem directories as namespaces having filenames look like long pathnames the way subdirectories are archived in .zip files or in GridFS for example.

@h @djsundog @natecull Yep; SL5 is intended to be used exactly that way. (Inspiration taken from IBM mainframes, which similarly lack subdirectories, even to this day!)

@vertigo @djsundog @h I wish we didn't *have* to fudge things like this, though?

Can we invent sensible filename or module systems for Forth?

@natecull @vertigo @djsundog FAT12 used to be a flat filesystem back in the early days. It wasn't until around MSDOS 3.x that FAT16 gained directories (and long non 8/3 filenames later with FAT32, and other filesystems).
Might as well use a FAT12-like pseudo-standard.

@natecull @h @djsundog Support for directories should be completely transparent to the end-user; the difference between /Foo/Bar/Baz and Foo.Bar.Baz should not matter to the user, and certainly not to the application. That applications are built with expectations of directories is itself an environmental dependency that I wish we could abstract away.

@vertigo @natecull @djsundog That can be abstracted for sure. I was referring to the FAT flat filesystem on the lower because it performs relatively well on limited hardware, and because every major OS and even cameras and phones support it.
Interop would be perfect.

@vertigo @natecull @djsundog

This is a FAT12 overview. I was wrong, FAT12 did introduce subdirectories. The lack of directories must have been in a previous version of MSDOS 1.0 or 2.0 with FAT8

FAT32 has long filenames and is built upon this same basic structure, only long filenames use more than one entry per directory table.

@h @natecull @djsundog To my knowledge, there never was a FAT8. FAT12 was introduced with DOS 1.0, and was a flat filesystem. Starting with MS-DOS 2.0, subdirectories were added using the same FAT12 disk structures; they only added a new directory type to support subdirectories.

@vertigo @natecull @djsundog
FAT8 is a name that was given to the original MSDOS 1.0 FAT in retrospective, as the original had no version number, and they had to be differentiated later.

@djsundog @natecull @vertigo

If a filename is longer than 8/3, its entry has a marker that indicates the filename continues in the next table entry.

@h @djsundog @natecull Ahh, that's not FAT12 though; that's ex-FAT, and IIRC, is patented.

@vertigo @djsundog @natecull

FAT32 is also known as VFAT.
It debuted around the time that the operating system Chicago / Windows 4.0 / a.k.a. MSDOS 7.0 was being built, which would later become Windows 95.

@natecull @djsundog @vertigo That takes less memory and simplifies the filesystem greatly, but possibly consumes some more CPU with directory entry handling. As is usually the case in these trade-offs, of course.

@h @natecull @djsundog Not really; directories are substantially more taxing on the CPU, since it must traverse a tree structure every time it needs to resolve a filename. A flat namespace can be made as simple as a list traversal, or for more performance, a single B-tree / skiplist search. Things get *really* hairy when symbolic links are involved. :)

@natecull @h not that I know of yet but that's also something I am interested in finding / assembling along the way

why's everyone talking about implementations of activitypub?

Sign in to participate in the conversation

This is a private instance that is using for development and testing.