Minimized Scalax IO branch

[Josh Suereth]

All,


I've started making the minimized scalax I/O branch on github.  This should only contain classes need to compile the I/O portions of scalax.  This is the first step towards making a releasable I/O library.  The branch is called "minimize".



Also, I've set up with the latest SBT project definitions so we can cross-build the library against scala versions 2.7.2, 2.7.3, 2.7.4 and 2.7.5 simulataneously.  Once I get approval, you'll see snapshots show up on scala-tools.org.


- Josh

[Josh Suereth]

We're actually trying to retain the ability to merge back into scalax when this project is "completed" or "matured".   The main reason I pushed for github is the ghpages feature of github.  It allows us to maintain a static website with documentation with no cost other than time.   There's also rumors of github->scalatools.org integration in the future.

Anyway, let us know if you'd like to help contribute!  We see this as a very important task to the evolution of scala.


- Josh

On Sun, Jun 21, 2009 at 1:13 PM, Stepan Koltsov <yo...@mx1.ru> wrote:

Why on github, not on bitbucket? scalax is stored in Mercurial.

Actually, IO is only part of scalax I use, so this is great!

And also, shouldn't scalax.io be renamed to something like
org.scalatools.io or something. I don't like package name scala* for
anything unofficial.

S.

[Josh Suereth]

All,

I've started trying to document what scalax currently provides and I'd like to make notes of what would need to take place to migrate to scala 2.8.0.  Here's the wiki page: http://wiki.github.com/eengbrec/Scalax.IO/fiile-api.

I see the following being somewhat important:

• Updating the current scalax.io to work with the new collections API
• Updating scalax APIs to make use of named and default parameters.
  

Anyone interested in helping define how the APIs should start looking?   The combination of default-parameters + implicit parameters provides some very interesting API possibilities.

- Josh