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!
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)
@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.
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.
@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.
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 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. :)
This is a private instance that @email@example.com is using for development and testing.