Hello Tim and Simon, I'd be very interested in this, for MFCCs.jl and perhaps GaussianMixtures.jl. They currently use HDF5 and JLD, respectively, and I don't think I've put in any magic.
- is it wise to put in magic, even with container formats such as HDF5? - do you prefer questions about implementation on this list, the repo, or some other way (or not at all)? Cheers, ---david On Tuesday, September 29, 2015 at 9:24:13 PM UTC+2, Tim Holy wrote: > > Simon Danisch and I are pleased to introduce FileIO.jl > (https://github.com/JuliaIO/FileIO.jl), a package for centralizing the > handling of formatted files. The package contains utilities for querying > files/filenames by their extensions and/or magic bytes to deduce their > content. > It then allows package authors to "register" loaders/savers for detected > file > formats. > > Some of the advantages of using FileIO are: > > - For users, this may reduce the searching required to answer "is there a > julia package to load file X?" Now you can just try `load("X.ext")` and > see > what happens---if the loader has been registered, it will try to find the > right > package for you. > > - For developers, this allows you to decouple your package from others. If > you > want to work with images, you will (once I tag a new release of Images.jl) > no > longer need to make the Images package a dependency as long as you use > FileIO. > In your package code, you can say `load("myimage.png")` and everything > should > Just Work. > > - For users and developers, this reduces name conflicts among two > attractive > function names, `load` and `save`. If everyone imports those names from > FileIO, there need be no conflicts. > > The package is relatively small and is fairly extensively documented. > > While there are not a large number of formats currently registered, the > architecture already shows a lot of promise. For example, it can recognize > our > .jld files as HDF5 files, something that escapes the well-tested (and much > more > extensive) Unix `file` command. > > Best, > --Tim & Simon > >
