scalax I/O and Resource Management Fork

[Josh Suereth]

Hi Scalax-ers,

This is Josh Suereth and Erik Engbrecht.   The BEAST has decided to improve Scala's I/O libraries as part of our contributions to Scala.   We were thinking we could take the Resource Management portions and I/O from scalax and try to evolve it independently (and under the same BSD license).   Our reasoning behind this is to minimize the scope of the project (mainly to good I/O in scala).  We believe that we can take the existing (and rather nice) scalax libraries and provide documentation/final touches.  We would also use SBT's new multi-scala-version release mechanism to promote this subset of scalax.   This way the library can easily be used across multiple versions of Scala.  We feel better support across Scala versions is critical to future commercial adoption, especially in larger, more conservative settings.

We don't want to split the community.  We believe a narrower focus will help us deliver a finished product in a shorter timeline.  We will keep a compatabile license with the end goal being merge back into scalax and hopefully scala itself.  We're calling the project scalax.io, and it's located on github.  We'd like to keep the community active and involved and invite all current members to contribute to the project.  We plan to have a 0.1 (complete with documentation) released in 2-3 months.  


- The BEAST

[Jesse Eichar-2]

THANK YOU!

Scala's IO is currently one of the biggest weaknesses for me.  I have
slowly been evolving a little scalax-like library to handle this sort
of thing as well ( against my wishes since scalax has not seemed very
healthy as of late.)

Please let me know when I can begin testing.  I am watching the repo
already and am excited to see what come from it.

A quick word to consider.  In my use cases one of the biggest wins
have been handling tree's of files/directories.  I requested and
helped introduce the Walker/FileTree to scalax.io and have privately
extended it so that there is more control for how directory trees can
be traversed.

The next big pluses are being able to easily read and write to files
without so much overhead of creating Readers/Writers, Channels etc...

Do you have any design ideas yet?  Maybe consider looking at the
design of the nnio that is coming in Java 7 for some inspiration (I
havent but seems like it might be a good idea).

My 2 cents,

Let me know if you want any design/code reviews/testing.  (This is
near and dear to my heart)

Jesse

On Sat, Jun 20, 2009 at 9:01 PM, Josh Suereth<joshua.suereth@...> wrote:

> Hi Scalax-ers,
>
> This is Josh Suereth and Erik Engbrecht.   The BEAST has decided to improve
> Scala's I/O libraries as part of our contributions to Scala.   We were
> thinking we could take the Resource Management portions and I/O from scalax
> and try to evolve it independently (and under the same BSD license).   Our
> reasoning behind this is to minimize the scope of the project (mainly to
> good I/O in scala).  We believe that we can take the existing (and rather
> nice) scalax libraries and provide documentation/final touches.  We would
> also use SBT's new multi-scala-version release mechanism to promote this
> subset of scalax.   This way the library can easily be used across multiple
> versions of Scala.  We feel better support across Scala versions is critical
> to future commercial adoption, especially in larger, more conservative
> settings.
>
> We don't want to split the community.  We believe a narrower focus will help
> us deliver a finished product in a shorter timeline.  We will keep a
> compatabile license with the end goal being merge back into scalax and
> hopefully scala itself.  We're calling the project scalax.io, and it's
> located on github.  We'd like to keep the community active and involved and
> invite all current members to contribute to the project.  We plan to have a
> 0.1 (complete with documentation) released in 2-3 months.
>
>
> - The BEAST
>

[Erik Engbrecht]

quick note - I just destroyed and recreated the repo, so you probably have to refollow.  I used the new hg-git plugin the hg to create it this time so we have the full revision history this time.

On Sat, Jun 20, 2009 at 3:46 PM, Jesse Eichar <jeichar.w@...> wrote:

THANK YOU!

Scala's IO is currently one of the biggest weaknesses for me.  I have
slowly been evolving a little scalax-like library to handle this sort
of thing as well ( against my wishes since scalax has not seemed very
healthy as of late.)

Please let me know when I can begin testing.  I am watching the repo
already and am excited to see what come from it.

A quick word to consider.  In my use cases one of the biggest wins
have been handling tree's of files/directories.  I requested and
helped introduce the Walker/FileTree to scalax.io and have privately
extended it so that there is more control for how directory trees can
be traversed.

The next big pluses are being able to easily read and write to files
without so much overhead of creating Readers/Writers, Channels etc...

Do you have any design ideas yet?  Maybe consider looking at the
design of the nnio that is coming in Java 7 for some inspiration (I
havent but seems like it might be a good idea).

My 2 cents,

Let me know if you want any design/code reviews/testing.  (This is
near and dear to my heart)

Jesse

On Sat, Jun 20, 2009 at 9:01 PM, Josh Suereth<joshua.suereth@...> wrote:
> Hi Scalax-ers,
>
> This is Josh Suereth and Erik Engbrecht.   The BEAST has decided to improve
> Scala's I/O libraries as part of our contributions to Scala.   We were
> thinking we could take the Resource Management portions and I/O from scalax
> and try to evolve it independently (and under the same BSD license).   Our
> reasoning behind this is to minimize the scope of the project (mainly to
> good I/O in scala).  We believe that we can take the existing (and rather
> nice) scalax libraries and provide documentation/final touches.  We would
> also use SBT's new multi-scala-version release mechanism to promote this
> subset of scalax.   This way the library can easily be used across multiple
> versions of Scala.  We feel better support across Scala versions is critical
> to future commercial adoption, especially in larger, more conservative
> settings.
>
> We don't want to split the community.  We believe a narrower focus will help
> us deliver a finished product in a shorter timeline.  We will keep a
> compatabile license with the end goal being merge back into scalax and
> hopefully scala itself.  We're calling the project scalax.io, and it's
> located on github.  We'd like to keep the community active and involved and
> invite all current members to contribute to the project.  We plan to have a
> 0.1 (complete with documentation) released in 2-3 months.
>
>
> - The BEAST
>

--
http://erikengbrecht.blogspot.com/

[Paul Phillips-3]

On Sat, Jun 20, 2009 at 03:01:32PM -0400, Josh Suereth wrote:
> We plan to have a 0.1 (complete with documentation) released in 2-3
> months.

Unfortunately paulp can't wait 2-3 months to do something about
scala.io.  It's intolerable to ship what's in there with 2.8.  I have a
partial rewrite in pieces to go with my 20 other git branches, but I'm
trying to fish or cut bait on all of them so I can focus on the pattern
matcher with no distractions.

I would encourage you to either target an incremental improvement and
maybe give me something I can work into trunk with a more aggressive
timeline, or failing that to document what you have in mind, and I'll
try not to paint us into too many corners.

--
Paul Phillips      | If this is raisin, make toast with it.
Imperfectionist    |
Empiricist         |
i'll ship a pulp   |----------* http://www.improving.org/paulp/ *----------

[Erik Engbrecht]

Paul,

  Which branch?  I'll take a look at it while I'm sorting out what's in scalax and see what I can do.

-Erik

On Sat, Jun 20, 2009 at 6:01 PM, Paul Phillips <paulp@...> wrote:

On Sat, Jun 20, 2009 at 03:01:32PM -0400, Josh Suereth wrote:
> We plan to have a 0.1 (complete with documentation) released in 2-3
> months.

Unfortunately paulp can't wait 2-3 months to do something about
scala.io.  It's intolerable to ship what's in there with 2.8.  I have a
partial rewrite in pieces to go with my 20 other git branches, but I'm
trying to fish or cut bait on all of them so I can focus on the pattern
matcher with no distractions.

I would encourage you to either target an incremental improvement and
maybe give me something I can work into trunk with a more aggressive
timeline, or failing that to document what you have in mind, and I'll
try not to paint us into too many corners.

--
Paul Phillips      | If this is raisin, make toast with it.
Imperfectionist    |
Empiricist         |
i'll ship a pulp   |----------* http://www.improving.org/paulp/ *----------

--
http://erikengbrecht.blogspot.com/