scala extension repository and experimental

Martin,

I very much agree that an extension library could be very handy. The
big thing we need, IMHO is a "blessed" leader, as you stated this will
not be EPFL, but should be someone who will work with EPFL.

So, when you make your final decision, and appoint a leader, we can
all jump him with contributions and ideas.

Right now the whole thing feels like it's still in limbo. What are
you going to do about Scala.Io incubator? As work is actively
occuring here, I think the decision should be made soon, so that work
can continue uninhibited.

Sent from my iPhone

On Nov 6, 2009, at 5:29 AM, martin odersky
wrote:

> I am finding more and more good arguments for scala-extension and
> against experimental. One is code review. Pending on finding suitable
> tool support, we plan to go to a post submit code review process, with
> the intention of achieving very high code coverage. That's necessary
> for trunk but it would be a hindrance for extensions. I do not think
> it would work to demand code review for non-experimental things in
> trunk but to let experimental things slip in without code review.
>
> The other is build times. Even if the last mail on increased build
> times turns out to be a false alarm (not sure yet), increased build
> times for trunk diminsh the productivity of everyone., @experimental
> stuff adds to build times, but extension stuff does not.
>
> Cheers
>

On Fri, Nov 6, 2009 at 12:36 PM, Josh Suereth wrote:
> Martin,
>
> I very much agree that an extension library could be very handy.  The big
> thing we need, IMHO is a "blessed" leader, as you stated this will not be
> EPFL,  but should be someone who will work with EPFL.
>
> So, when you make your final decision, and appoint a leader, we can all jump
> him with contributions and ideas.
>
> Right now the whole thing feels like it's still in limbo.  What are you
> going to do about Scala.Io incubator?  As work is actively occuring here,  I
> think the decision should be made soon, so that work can continue
> uninhibited.
>
Can you tell me a bit more what the state of scala.io is?

Thanks

That's more of Jesse Eichar and others.  Jesse decided to take all the existing I/O Implementations and merge them into incubator, as that's where we thought things might end up living.

I'm only atcively working on the ARM piece.  Right now I'm trying to flush things out with examples to prevent breaking I/O's reliance on the ARM stuff.  In terms of the I/O library, I've been watching the code and discussions, but really Jesse has taken the lead here in determining how "well-formed a thought" we have there.

I do think this effort really needs the official 'blessing' so that others who are unsure of whether or not their work would amount to anything join in, knowing that the work we contribute is feeding the extension library, which could someday feed the scala-library.   Just formalizing that channel, IMHO, will help gain more contributors.

- Josh

On Fri, Nov 6, 2009 at 6:41 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Fri, Nov 6, 2009 at 12:36 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
> Martin,
>
> I very much agree that an extension library could be very handy.  The big
> thing we need, IMHO is a "blessed" leader, as you stated this will not be
> EPFL,  but should be someone who will work with EPFL.
>
> So, when you make your final decision, and appoint a leader, we can all jump
> him with contributions and ideas.
>
> Right now the whole thing feels like it's still in limbo.  What are you
> going to do about Scala.Io incubator?  As work is actively occuring here,  I
> think the decision should be made soon, so that work can continue
> uninhibited.
>
Can you tell me a bit more what the state of scala.io is?

Thanks

Hi all,

On Fri, 2009-11-06 at 06:58 -0500, Josh Suereth wrote:
> I do think this effort really needs the official 'blessing'

I agree. It would be good if the the scala-lang website mentioned the
incubator as a recognised route towards getting things included in Scala
proper. I think it's important to avoid fragmentation, so the extensions
should, in my opinion, be one of the projects in the incubator.

> so that others who are unsure of whether or not their work would
> amount to anything join in,

There should be no guarantees on that though. There's always the risk
that some work is not deemed appropriate for the standard library. In
other words, there should be appropriate channels from the incubator to
scala proper, but never guarantees that things will move in that
direction.

Best,
Ismael

On Fri, 2009-11-06 at 06:36 -0500, Josh Suereth wrote:
> I very much agree that an extension library could be very handy. The
> big thing we need, IMHO is a "blessed" leader, as you stated this will
> not be EPFL, but should be someone who will work with EPFL.

This would be useful and ideally it would be someone trusted by the EPFL
who also has the time and motivation to do the work. Not sure if there
are many people who meet the criteria though.

Best,
Ismael

On Fri, Nov 6, 2009 at 11:23 PM, Ismael Juma wrote:
> On Fri, 2009-11-06 at 06:36 -0500, Josh Suereth wrote:
>> I very much agree that an extension library could be very handy.  The
>> big thing we need, IMHO is a "blessed" leader, as you stated this will
>> not be EPFL,  but should be someone who will work with EPFL.
>
> This would be useful and ideally it would be someone trusted by the EPFL
> who also has the time and motivation to do the work. Not sure if there
> are many people who meet the criteria though.

Agree. Its a crucial role and a difficult job. They have to
simultaneously win the confidence of both EPFL and the
contributor-community, need to have a really good sense of library
design, and will at times face tough decisions that will inevitably
disappoint some people.

To a large extent, the success of the extension-repository initiative
depends upon appropriate leadership.

-Ben

With regard to Scala.io. 
I have taken the code Paul wrote,  compared it to the Java 7 Nio filesystem and have made several changes to the Paul's API.  Most of the changes were related to the discussions we had on this list but I also added some items to make the API more general so it can support multiple filesystems like the Java 7 NIO API.
I have just finished around 50 examples of how to use the API and am trying to finish the ScalaDocs and a couple of issues I found during writing the examples.
I wanted to publish the Scala docs and the examples for review this week but I am not quite done yet.  I am nearly ready so you can expect that early next week.
Jesse



On Fri, Nov 6, 2009 at 12:58 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:

That's more of Jesse Eichar and others.  Jesse decided to take all the existing I/O Implementations and merge them into incubator, as that's where we thought things might end up living.

I'm only atcively working on the ARM piece.  Right now I'm trying to flush things out with examples to prevent breaking I/O's reliance on the ARM stuff.  In terms of the I/O library, I've been watching the code and discussions, but really Jesse has taken the lead here in determining how "well-formed a thought" we have there.

I do think this effort really needs the official 'blessing' so that others who are unsure of whether or not their work would amount to anything join in, knowing that the work we contribute is feeding the extension library, which could someday feed the scala-library.   Just formalizing that channel, IMHO, will help gain more contributors.

- Josh

On Fri, Nov 6, 2009 at 6:41 AM, martin odersky <martin.odersky@epfl.ch> wrote:

On Fri, Nov 6, 2009 at 12:36 PM, Josh Suereth <joshua.suereth@gmail.com> wrote:
> Martin,
>
> I very much agree that an extension library could be very handy.  The big
> thing we need, IMHO is a "blessed" leader, as you stated this will not be
> EPFL,  but should be someone who will work with EPFL.
>
> So, when you make your final decision, and appoint a leader, we can all jump
> him with contributions and ideas.
>
> Right now the whole thing feels like it's still in limbo.  What are you
> going to do about Scala.Io incubator?  As work is actively occuring here,  I
> think the decision should be made soon, so that work can continue
> uninhibited.
>
Can you tell me a bit more what the state of scala.io is?

Thanks