@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.
@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.
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 @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 @firstname.lastname@example.org is using for development and testing.