expose projects/tabs as a filesystem

Suggestions
1

The more I think of this, the more utility comes to mind. I mentioned this deep in another thread - I mention it here for criticism/improvements before I suggest it as a feature proper.

The idea is to expose Codea’s Project/Tab structure as a filesystem, something Codea code could read/write/modify using io.* the same as Lua and the regular filesystem on a normal PC.

This would allow “data files”, where right now we need to make big data lua code, with the attendant overhead. Extra points for allowing “binary” tabs - the tab would show, perhaps, a name and a comment about it’s contents. Font data, game data, saved games, etc - it’s an alternative to project/global storage, in a place that’s visible and easily manipulated (which isn’t a feature of storage currently).

But - it would go farther; utility type scripts (I’m thinking things like lint and code checkers, or even refactoring scripts) could be run against code in other projects. Indeed, self referential or even self-modifying code is possible in this way (as it is with persistent storage today and load(), but again this would be much more transparent to the user).

This would also make dealing with libraries trivial.

f = require("Cube/Font")
if (not f) then
   print "I'm sorry, I need Cube/Font to run - download it at BLAH BLAH"
end

(Hmm - can we make a call to generate a runtime error? I think we can, and should in that example, but I’m too tired to look it up).

And finally, it would allow for programs that generate useful output (something doing calculations, or a usage history - I’m thinking about code to do things like measure reaction time in an experimental setup) to put them somewhere where it can be exported to be used by other stuff, even via cut and paste. Right now, output is limited to print() (which i can’t cut/copy), the screen (again, no cut/copy), or persistent storage (where I could export a .codea project and hack it apart externally - very, very messy).

Files, as a concept, are insanely useful. Let’s use them.

(Note that NONE of this suggests writing directly to the iOS file system, or even to Codea’s Documents directory - things like plists and so on would be completely invisible).

Other than the time to implement, the only downside I can see of this would be a “rogue” project modifying another on-the-sly - that’s easily dealt with by making projects (other than the current one) read-only unless the user has removed the “write-protect tab” (a checkable option for each project, or each project/tab) explicitly.

Maybe this is useless because I forgot ________, or maybe it’s great but ________. or maybe it’s impossible because of _______. You fill in the blanks - I’m not proud, if this is silly, let me know. :slight_smile:

2

Even for something as simple as Spritely, the current level of storage is frustrating. I can save to project data. Which is nice because I can clear project data, but I can only clear ALL project data, meaning that I have to hold everything in memory and rewrite to storage if I want to use clear, and any failure in mid-write results in loss of records.

On the other hand, I can write to global – making it much easier for other programs to access the data – but I can’t clear the data. When an image is deleted, I go in and save a nil against that key, but it makes me worry that somewhere I’m leaving a big table of keys with no data.

And most frustrating of all, I can’t write to the project data of any other project, meaning that getting at the data requires copying code into a project to read / move it.

I’d be ecstatic if we could just drop the global / project / local system in favor of something that looks like folders, so I could save something like saveData(“/Spritely/image10”, imagedata) and delete or rewrite data by using the same path. Pair that with a universal table of keys, and you’d have a rudimentary file system.

Yeah, somewhere down the line we could think about protected paths (i.e. project folders that can’t be written to by other projects), but I could live without it.

Heck, I’d settle for a readKeys() that just told me what’s out there.

3

+1

4

There’s a part of me (that has infinite free time apparently) that wants to re-implement a filesystem and io.* over the top of the global store. I’d have to keep track of file names and such myself, but meh. Then you could just use a file manager app to maintain things.

Might be fun as a stunt, and proof of concept. Problem is, I’d want to support the same API as the for-reals lua io.* API, and I dont know it well enough… Not that that’s stopped me before.

5

Ooopss… someone is mentioning requireagain. I thought it was rejected. :slight_smile:

6

@bee Lua’s standard require will not work. It’s not rejected. It just fundamentally won’t work due to the way Lua searches for files when you require them. An alternative system would have to be written that creates a virtual filesystem, like @bortels mentioned, and has a specific function to access the contents of another project.

7

required() was thought of as not being, well, required. :slight_smile:

But as we all gain experience with the environment, these sorts of things may bear revisiting. I can’t predict for sure what will be the right way to implement things from the beginning, and I won’t hold the Codea devs to a higher standard.

I’m not actually suggesting the normal lua require() here anyway - I’m suggesting co-opting it in a way that’s useful to us in Codea’s environment. As fun as it is to poke Apple, access to the native filesystem is undesirable, even if restricted to Codea’s Documents directlry; but access to a filesystem of some sort is a proven solution to many issues, and if it’s clearly sandboxed away, Apple should have no issues with it. TLL may, because it’d take nonzero work to implement - but I suspect it’ll save them work in the long run. The principle of least surprise is a good thing, and being able to say “io.* works just like you’d expect in Lua, except you’re sandboxed into a private filesystem - no access to the native filesystem is available” could save a ton of documenting work…

8

@Bortels I like your idea of having a virtual filesystem for a require-alternative. I doubt Apple would have any issues with the feature. I need to give it some more thought though.

9

Of course when I requested for requireI meant it works in a sandboxed manner as it’s the way iOS app works. I know that accessing the real filesystem of iOS is prohibited.

10

@Simeon, is why I brought it up. I ask no promises - I’m happy you consider the ideas. I have faith you’ll implement the good stuff in time. (setContext() being a classic example - w00t on that!)