DJ Sundog - from the toot-lab is a user on You can follow them or interact with them if you have an account anywhere in the fediverse.
DJ Sundog - from the toot-lab @djsundog

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

· Web · 5 · 10

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

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

@natecull @djsundog @h Come to think of it, porting FAT would make a great tutorial on how to code for Kestrel at a systems level.

@vertigo @djsundog @natecull
Maybe it will be an interesting thing to begin to form a little community around it, if you present a few challenges that can be contributed to the project. Filesystem support is maybe one that can be parallelised relatively well.

@vertigo @djsundog @natecull
Hahaaha, what's 40 years of lagging behind

But *when we catch up* ahhh.... there will be no more catch ups ever!

@h @djsundog @natecull Despite how few number files there are here, the volume of code is enormous. This is why I don't intend on supporting FAT out of the box. Compared to SL5, it's ginormous.

@vertigo @djsundog @natecull

Yeah, well. Something to think about when the time comes 😃
It doesn't have to be fully implemented, a FAT32 subset that supports long filenames would be enough.

@vertigo @djsundog @h Is this the SL5 you mention? Some wonderful 360 trivia there btw!

I guess I kinda hope that any USB or SD filesystem could be readable by Linux, Windows and Mac. I'd like to be able to transfer files. Is that too high a bar for a tiny machine?

@natecull @h @djsundog Yep, that's the one.

For the Kestrel-2DX, you can probably get away with a very simple FAT implementation that understands a single directory and short filenames in a handful of kilobytes. Support for long filenames and subdirectories will probably bloat the filesystem a bit; you'll probably be able to fit it into the 16KB of dictionary space, but you won't likely have much room for application logic.

I could be wrong, though.

@djsundog @h @natecull For Kestrel-3, you should have plenty of RAM to support all of FAT12/16/32 features, since the Kestrel-3 will have at least 512KB of RAM available.

@vertigo @djsundog @natecull

BTW the FAT32 patent loophole is trivial to implement. Amusing, even. 😃

Microsoft never lose money, but they stood to steal billions more if it hadn't been for this almost imperceptible legal oversight.

@natecull The limit there is the intersection between filesystems that Microsoft chooses to support (which consists of various forms of FAT, EXFAT, NTFS), filesystems that Apple chooses to support, filesystems that have drivers available for Linux. (Also, if you're using other devices, such as cameras, they almost always support one of FAT, EXFAT, or NTFS, and nothing else.)

@natecull @djsundog @vertigo When the time comes, of course.

Just looked up what's the Linux story about the FAT family of filesystems.
Pretty straightforward, in case anyone's interested.

"Clever Linux folk find way around Microsoft FAT file system patent"

@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

why's everyone talking about implementations of activitypub?