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

@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.

@h @djsundog @natecull Yes, that's what I meant. Be careful though; again, I do not believe FAT32 is unencumbered, and as well, do not store files with long filenames in the root directory (since the root directory still has a finite number of sectors reserved for it).

@vertigo @djsundog @natecull
You're right, FAT32 was not patents free at least until very recently, and I'm unsure about its current status.
I do know for a fact that Linux implements vfat support, which is what it uses to mount the flurry of SD cards, memory sticks, external phone storage and whatnot.
So taking a look at the Linux source for that filesystem module will probably be the best reference.

@h @djsundog @natecull I personally intend on continuing to use SL5 for my Kestrel platforms; some folks at SVFIG who are authors of Forth for CP/M systems back in the early 80s have told me that my filesystem is both more capable and yet still simpler than even CP/M's old filesystem layout.

I'll consider looking into FAT12/FAT16 only after I have a working SL5 implementation for it.

@vertigo @djsundog @natecull
FAT16 used to have a limitation of 512 entries in the root directory.
FAT32 does not have that limitation.

Explained here by the *ULTIMATE AUTHORITY* hahahaha

exFAT is what Microsoft calls its 64-bit version (it would have been FAT64, had they kept naming consistent) but few people know it, as most Windows systems use NTFS instead. I assume it must be used in some non-PC or small PC sort of mass storage device.

@h @djsundog @natecull Yeah, exFAT is the officially documented standard filesystem for SDXC and SDHC mass media.

@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

Sign in to participate in the conversation

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