Julian Samaroo

With more and more features using/relying on the eager API (which has only 1 scheduler), I'm considering making `SchedulerOptions` an internal API, and ripping out most of its functionality and...

Could FileTrees gain some logic to allow saving/loading a filetree from/to a DArray? That would mimic some of the code we're removing.

Alternatively, I think everyone could benefit from the scheduler having a basic understanding of memory pressure and have the option for data to be moved to disk when we're nearing...

Here's my plans for a "storage subsystem" that I'm working on: - `Storage` abstract type, currently a subtype of `Processor` to let it fit the `move()` dispatch - Memory/disk capacity...

Regarding FileTrees.jl: the above proposal could support `Storage` objects which use FileTrees to save/load data in a particular tree format on-disk, allowing users to keep data neatly organized in whatever...

Yeah, the lazy nature of the `DArray` breaks under a lot of regular array operations. Per #226, we'll probably just want to make the `DArray` eager (like the `DTable`), potentially...

Even if the invocation is simple, Dagger itself is pretty complex, and that particular API may change going forward, so it might be good to have it just in case....

The above already exists in Dagger; now we need to inform Dagger about thunks that use different kinds of processors simultaneously.

I would probably check out the tests for somewhat extensive examples of how to use each API. Is there something in particular you feel is missing?

I'll add actual DaggerFlux reverse CI once we're sure that we can access the `juliagpu` BK queue.