@MA Laforge
This looks a little bit like our first prototypes, with the addition of an
hierarchical format system.
I'm not sure if we really need a hierarchy. It seems hard to program
against some abstract type in this area, since you get so many edge cases.
It might be useful in some cases, but at least for now, FileIO works pretty
well without it.
In the end, I would rather like to have the hierarchy in the Julia objects
that get returned by load (e.g. AbstractString <: UTF8String etc)
Please consider the following points, that have lead to the current design:
- There are many IO libraries which should get dynamically loaded when the
format is detected (first argument for registry)
- we utilize magic bytes to recognize file formats (second argument for
registry)
- there are multiple IO libraries for the same formats and we need to
choose one dynamically
- we use dispatch in the same way, but just inside one module, to better
resolve ambiguities
>but something seems a little off about how I use/generate objects
I'm not really sure what you mean by that.
Best,
Simon
Am Samstag, 4. April 2015 17:41:14 UTC+2 schrieb Simon Danisch:
>
> Hi there,
>
> FileIO has the aim to make it very easy to read any arbitrary file.
> I hastily copied together a proof of concept by taking code from Images.jl.
>
> JuliaIO is the umbrella group, which takes IO packages with no home. If
> someone wrote an IO package, but doesn't have time to implement the FileIO
> interface, giving it to JuliaIO might be a good idea in order to keep the
> package usable.
>
> Concept of FileIO is described in the readme:
>
> Meta package for FileIO. Purpose is to open a file and return the
> respective Julia object, without doing any research on how to open the file.
>
> f = file"test.jpg" # -> File{:jpg}read(f) # -> Imageread(file"test.obj") # ->
> Meshread(file"test.csv") # -> DataFrame
>
> So far only Images are supported and MeshIO is on the horizon.
>
> It is structured the following way: There are three levels of abstraction,
> first FileIO, defining the file_str macro etc, then a meta package for a
> certain class of file, e.g. Images or Meshes. This meta package defines the
> Julia datatype (e.g. Mesh, Image) and organizes the importer libraries.
> This is also a good place to define IO library independant tests for
> different file formats. Then on the last level, there are the low-level
> importer libraries, which do the actual IO. They're included via Mike Innes
> Requires <https://github.com/one-more-minute/Requires.jl> package, so
> that it doesn't introduce extra load time if not needed. This way, using
> FileIO without reading/writing anything should have short load times.
>
> As an implementation example please look at FileIO -> ImageIO ->
> ImageMagick. This should already work as a proof of concept. Try:
>
> using FileIO # should be very fast, thanks to Mike Innes Requires
> packageread(file"test.jpg") # takes a little longer as it needs to load the
> IO libraryread(file"test.jpg") # should be fastread(File("documents",
> "images", "myimage.jpg") # automatic joinpath via File constructor
>
> Please open issues if things are not clear or if you find flaws in the
> concept/implementation.
>
> If you're interested in working on this infrastructure I'll be pleased to
> add you to the group JuliaIO.
>
>
> Best,
>
> Simon
>
