Nabble - Scala

Re: [scala] New scala blog

2009-11-26T13:36:14Z

I'm always a bit cynical about how much re-use *really* occurs with most in-house corporate development...

But I'm in total agreement about the benefits of refactoring.

Maintainability is important, but too many people still think of software as something that is simply written and then sold.

On Thu, Nov 26, 2009 at 7:03 PM, Colin Howe <colinthehowe@...> wrote:

Nice post :-)

Although, I'd argue that many good things initially lead to more lines but eventually lead to fewer as re-use etc is increased.

Also, testing makes refactoring easier, which makes it easier to prune away excess baggage

On Thu, Nov 26, 2009 at 6:55 PM, Kevin Wright <kev.lee.wright@...> wrote:

Okay, I've been threatening this for quite some time now...
Finally got round to it :)

http://www.artima.com/weblogs/index.jsp?blogger=kevwright

enjoy!

Re: [scala] jvm5 build should be default?

2009-11-26T11:14:20Z

On Nov 25, 2009, at 9:11 PM, Jorge Ortiz wrote:

> LinkedIn has 100+ engineers stuck on Java 1.5 because of a blocker bug in Apple's 1.6 JDK. It certainly doesn't "work just fine".

Out of curiosity, which bug is this?

Blair

Re: [scala] New scala blog

2009-11-26T11:03:22Z

Nice post :-)

Although, I'd argue that many good things initially lead to more lines but eventually lead to fewer as re-use etc is increased.

Also, testing makes refactoring easier, which makes it easier to prune away excess baggage

On Thu, Nov 26, 2009 at 6:55 PM, Kevin Wright <kev.lee.wright@...> wrote:

Okay, I've been threatening this for quite some time now...
Finally got round to it :)

http://www.artima.com/weblogs/index.jsp?blogger=kevwright

enjoy!

[scala] New scala blog

2009-11-26T10:55:35Z

Okay, I've been threatening this for quite some time now...

Finally got round to it :)

http://www.artima.com/weblogs/index.jsp?blogger=kevwright

enjoy!

Re: [scala] jvm5 build should be default?

2009-11-26T10:02:42Z

On Thu, 2009-11-26 at 14:55 +0100, Antonio Cunei wrote:
> Therefore our planned naming scheme is just:
>
> * scala-2.7.x requires jvm 1.5
> * scala-2.7.x-jvm4 runs on jvm 1.4
>
> * scala-2.8.x requires jvm 1.6
> * scala-2.8.x-jvm5 runs on jvm 1.5

I am wondering if it won't be better to have the jvm suffix for both
builds given recent emails I've seen where people use the default build,
expect it to work with Java 5 and then email the list asking what's up.

I would hope that including the expected jvm in the name may improve the
situation. Is there a downside to this?

Best,
Ismael

Re: [scala] jvm5 build should be default?

2009-11-26T09:34:12Z

I just ran into a problem with ScalaTest that dovetails into this
discussion. The 1.0.1-SNAPSHOT (2.7.x compatible) was accidentally
built with 1.6 dependencies (String.isEmpty). Bill created a new 1.5
compatible snapshot a few days after it was brought to his attention.
My team is in the situation where most of the developers are on Macs
running 1.5, a few have Windows running 1.6 and all our target
deployment infrastructure is all Linux running 1.6.

The problem is that switching the build to 1.6 on the Macs introduces
a number of compatibilities with other Java-based software on the Mac
that we haven't had time to investigate / resolve (and won't have time
to deal with until after the project is live).

That all said, I think the right choice for Scala is: 1.6 VM by
default for 2.8, with a 1.5 VM build available separately.

My team will just stay on Scala 2.7.x until such time as we can
resolve the 1.6 VM problems (or we all upgrade to Snow Leopard).

On Thu, Nov 26, 2009 at 5:55 AM, Antonio Cunei <antonio.cunei@...> wrote:

> martin odersky wrote:
>>
>> It seems this is a really controversial affair, but we are making
>> progress. Here are some conclusions we drew from the discussion so
>> far:
>>
>> - there will be 1.5 and 1.6 versions shipped separately
>> (this one is not new)
>>
>> - the 1.6 version will refuse to run on a 1.5 VM. It turns out the
>> 1.6 classfile format already does a major version jump. because
>> of API changes in String, and because of the new fast bytecode
>> verifier format. The next Scala 2.8 builds for Java 1.6 will
>> generate classfiles with that major version, which cannot be
>> executed on a 1.5 machine. This also means that 1.6 classfiles
>> will load faster than 1.5 classfiles because of the changes in
>> the bytecode verifier.
>>
>> The only remaining question is what to label a default. I believe
>> we have to discuss specifics to find out what `default' should mean.
>> Toni will follow up explaining the current naming scheme so that
>> we can discuss it.
>>
>
> The current plan is pretty simple. We expect 1.6 to become eventually the VM
> of choice, so a switch to 1.6 as the default is unavoidable in the long
> term.
>
> Our concern is that switching the default during the lifetime of 2.8 would
> introduce a great deal of confusion. For example, we could end up having a
> "2.8.2" that runs on 1.5, and then a "2.8.3" that really requires 1.6:
> people upgrading would encounter breakage and confusion. If there is a good
> time to change the default, that is with the introduction of 2.8.
>
> Therefore our planned naming scheme is just:
>
> * scala-2.7.x requires jvm 1.5
> * scala-2.7.x-jvm4 runs on jvm 1.4
>
> * scala-2.8.x requires jvm 1.6
> * scala-2.8.x-jvm5 runs on jvm 1.5
>
>
> In the end it boils down simply to naming. We are willing and able to
> maintain two versions, so as long as the naming scheme is clear and simple
> there should be no confusion.
>
> Please let us know if you see any relevant problems with this scheme.
> Toni
>

--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

Re: [scala] jvm5 build should be default?

2009-11-26T07:23:30Z

As the outcome of not such an old discussion, Scala is now "kind"
enough for the JVM users to provide a 1.5 build. But Scala should move
ahead. As long as there is commitment (from the Scala Team or some
other respected outside body) to maintaint a jvm5 build *and* all
artifacts are properly versioned for the build/dependency management
tools to pick up, I see no reason to not have 1.6 as the default.

If we define a good policy now, we will be ready for the 1.6 --> 1.7
transition as well. Let's keep this in mind too.

On Thu, Nov 26, 2009 at 17:07, Josh Suereth <joshua.suereth@...> wrote:

> Tony, I think you may want to include the naming for maven/sbt users which
> is a "groupId"-"artifactId"-"version" pair, e.g.
>
>
> default - "org.scala-lang"-"scala-library"-"2.7.x" (requires jvm1.5)
> nightly - "org.scala-lang"-"scala-library"-"2.7.x-SNAPSHOT" (requires
> jvm1.5)
> jvm4 - "org.scala-lang"-"scala-library"-"2.7.x-jvm4" (requires jvm1.4)
> jvm4 nightly - "org.scala-lang"-"scala-library"-"2.7.x-jvm4-SNAPSHOT"
> (requires jvm1.4)
>
> If the maven-deployment buildfile currently doesn't allow this, let me know!
>
> - Josh
>
>
>
> On Thu, Nov 26, 2009 at 8:55 AM, Antonio Cunei <antonio.cunei@...>
> wrote:
>>
>> martin odersky wrote:
>>>
>>> It seems this is a really controversial affair, but we are making
>>> progress. Here are some conclusions we drew from the discussion so
>>> far:
>>>
>>> - there will be 1.5 and 1.6 versions shipped separately
>>> (this one is not new)
>>>
>>> - the 1.6 version will refuse to run on a 1.5 VM. It turns out the
>>> 1.6 classfile format already does a major version jump. because
>>> of API changes in String, and because of the new fast bytecode
>>> verifier format. The next Scala 2.8 builds for Java 1.6 will
>>> generate classfiles with that major version, which cannot be
>>> executed on a 1.5 machine. This also means that 1.6 classfiles
>>> will load faster than 1.5 classfiles because of the changes in
>>> the bytecode verifier.
>>>
>>> The only remaining question is what to label a default. I believe
>>> we have to discuss specifics to find out what `default' should mean.
>>> Toni will follow up explaining the current naming scheme so that
>>> we can discuss it.
>>>
>>
>> The current plan is pretty simple. We expect 1.6 to become eventually the
>> VM of choice, so a switch to 1.6 as the default is unavoidable in the long
>> term.
>>
>> Our concern is that switching the default during the lifetime of 2.8 would
>> introduce a great deal of confusion. For example, we could end up having a
>> "2.8.2" that runs on 1.5, and then a "2.8.3" that really requires 1.6:
>> people upgrading would encounter breakage and confusion. If there is a good
>> time to change the default, that is with the introduction of 2.8.
>>
>> Therefore our planned naming scheme is just:
>>
>> * scala-2.7.x requires jvm 1.5
>> * scala-2.7.x-jvm4 runs on jvm 1.4
>>
>> * scala-2.8.x requires jvm 1.6
>> * scala-2.8.x-jvm5 runs on jvm 1.5
>>
>>
>> In the end it boils down simply to naming. We are willing and able to
>> maintain two versions, so as long as the naming scheme is clear and simple
>> there should be no confusion.
>>
>> Please let us know if you see any relevant problems with this scheme.
>> Toni
>
>

my $0.02,
Christos
--
__~O
-\ <, Christos KK Loverdos
(*)/ (*) http://ckkloverdos.com

Re: [scala] jvm5 build should be default?

2009-11-26T07:21:53Z

Josh,

We can certainly do in the Maven deployment file all the renaming necessary
to adapt the version names to Maven's needs. I'll contact you shortly to
discuss the details.

Toni

Josh Suereth wrote:

Re: [scala] jvm5 build should be default?

2009-11-26T07:07:22Z

Tony, I think you may want to include the naming for maven/sbt users which is a "groupId"-"artifactId"-"version" pair, e.g.

default - "org.scala-lang"-"scala-library"-"2.7.x" (requires jvm1.5)
nightly - "org.scala-lang"-"scala-library"-"2.7.x-SNAPSHOT" (requires jvm1.5)
jvm4 - "org.scala-lang"-"scala-library"-"2.7.x-jvm4" (requires jvm1.4)
jvm4 nightly - "org.scala-lang"-"scala-library"-"2.7.x-jvm4-SNAPSHOT" (requires jvm1.4)

If the maven-deployment buildfile currently doesn't allow this, let me know!

- Josh

On Thu, Nov 26, 2009 at 8:55 AM, Antonio Cunei <antonio.cunei@...> wrote:

martin odersky wrote:

It seems this is a really controversial affair, but we are making
progress. Here are some conclusions we drew from the discussion so
far:

- there will be 1.5 and 1.6 versions shipped separately
(this one is not new)

- the 1.6 version will refuse to run on a 1.5 VM. It turns out the
1.6 classfile format already does a major version jump. because
of API changes in String, and because of the new fast bytecode
verifier format. The next Scala 2.8 builds for Java 1.6 will
generate classfiles with that major version, which cannot be
executed on a 1.5 machine. This also means that 1.6 classfiles
will load faster than 1.5 classfiles because of the changes in
the bytecode verifier.

The only remaining question is what to label a default. I believe
we have to discuss specifics to find out what `default' should mean.
Toni will follow up explaining the current naming scheme so that
we can discuss it.

The current plan is pretty simple. We expect 1.6 to become eventually the VM of choice, so a switch to 1.6 as the default is unavoidable in the long term.

Our concern is that switching the default during the lifetime of 2.8 would introduce a great deal of confusion. For example, we could end up having a "2.8.2" that runs on 1.5, and then a "2.8.3" that really requires 1.6: people upgrading would encounter breakage and confusion. If there is a good time to change the default, that is with the introduction of 2.8.

Therefore our planned naming scheme is just:

* scala-2.7.x requires jvm 1.5
* scala-2.7.x-jvm4 runs on jvm 1.4

* scala-2.8.x requires jvm 1.6
* scala-2.8.x-jvm5 runs on jvm 1.5

In the end it boils down simply to naming. We are willing and able to maintain two versions, so as long as the naming scheme is clear and simple there should be no confusion.

Please let us know if you see any relevant problems with this scheme.
Toni

Re: [scala] jvm5 build should be default?

2009-11-26T05:55:18Z

martin odersky wrote:

> It seems this is a really controversial affair, but we are making
> progress. Here are some conclusions we drew from the discussion so
> far:
>
> - there will be 1.5 and 1.6 versions shipped separately
> (this one is not new)
>
> - the 1.6 version will refuse to run on a 1.5 VM. It turns out the
> 1.6 classfile format already does a major version jump. because
> of API changes in String, and because of the new fast bytecode
> verifier format. The next Scala 2.8 builds for Java 1.6 will
> generate classfiles with that major version, which cannot be
> executed on a 1.5 machine. This also means that 1.6 classfiles
> will load faster than 1.5 classfiles because of the changes in
> the bytecode verifier.
>
> The only remaining question is what to label a default. I believe
> we have to discuss specifics to find out what `default' should mean.
> Toni will follow up explaining the current naming scheme so that
> we can discuss it.
>

The current plan is pretty simple. We expect 1.6 to become eventually the
VM of choice, so a switch to 1.6 as the default is unavoidable in the long
term.

Our concern is that switching the default during the lifetime of 2.8 would
introduce a great deal of confusion. For example, we could end up having a
"2.8.2" that runs on 1.5, and then a "2.8.3" that really requires 1.6:
people upgrading would encounter breakage and confusion. If there is a good
time to change the default, that is with the introduction of 2.8.

Therefore our planned naming scheme is just:

* scala-2.7.x requires jvm 1.5
* scala-2.7.x-jvm4 runs on jvm 1.4

* scala-2.8.x requires jvm 1.6
* scala-2.8.x-jvm5 runs on jvm 1.5

In the end it boils down simply to naming. We are willing and able to
maintain two versions, so as long as the naming scheme is clear and simple
there should be no confusion.

Please let us know if you see any relevant problems with this scheme.
Toni

Re: [scala] jvm5 build should be default?

2009-11-26T05:40:40Z

It seems this is a really controversial affair, but we are making
progress. Here are some conclusions we drew from the discussion so
far:

- there will be 1.5 and 1.6 versions shipped separately
(this one is not new)

- the 1.6 version will refuse to run on a 1.5 VM. It turns out the
1.6 classfile format already does a major version jump. because
of API changes in String, and because of the new fast bytecode
verifier format. The next Scala 2.8 builds for Java 1.6 will
generate classfiles with that major version, which cannot be
executed on a 1.5 machine. This also means that 1.6 classfiles
will load faster than 1.5 classfiles because of the changes in
the bytecode verifier.

The only remaining question is what to label a default. I believe
we have to discuss specifics to find out what `default' should mean.
Toni will follow up explaining the current naming scheme so that
we can discuss it.

Cheers

-- Martin

Re: [scala] jvm5 build should be default?

2009-11-26T05:31:05Z

On Wed, 2009-11-25 at 21:11 -0800, Jorge Ortiz wrote:
> LinkedIn has 100+ engineers stuck on Java 1.5 because of a blocker bug
> in Apple's 1.6 JDK.

Is that for Snow Leopard or Leopard or both?

Best,
Ismael

Re: [scala] jvm5 build should be default?

2009-11-26T05:27:11Z

Jorge Ortiz wrote:
> LinkedIn has 100+ engineers stuck on Java 1.5 because of a blocker bug
> in Apple's 1.6 JDK. It certainly doesn't "work just fine".
>
> --j

My concern is about clients (desktop software). It is reasonable
requirement to upgrade to latest version of java for their OS, but it's
not realistic to expect them to throw away hardware they bought not 10
years ago but 2 years ago or to buy new OS. How old laptop or desktop
computer of yours guys?

--
Best Regards,
Vladimir Kirichenko

signature.asc (267 bytes) Download Attachment

Re: [scala] jvm5 build should be default?

2009-11-26T02:25:59Z

As far as I can tell, Snow Leopard supports Intel 32-bit, and provides
Java 6. The only people left out are PowerPC users, if my sources are
correct. There's a Mac mini that just landed on my desk that will be
useful if this is true and a brick otherwise.

The link you pointed at is not for Snow Leopard.

2009/11/26 Vladimir Kirichenko <vladimir.kirichenko@...>:

> Dean Wampler wrote:
>> Unless I'm mistaken, 1.6 is now the default on Snow Leopard.
>> dean
>
> It doesn't change the fact that a lots of mac desktops, laptops and
> servers with power and intel x32 architectures and pre-snow-leopard OS
> versions still exist and could not be upgraded to snow leopard and apple
> is not going to upgrade java for them.
>
> http://support.apple.com/kb/HT3649
>
> ===========================
>
> This release updates Java SE 6 to version 1.6.0_15, J2SE 5.0 to version
> 1.5.0_20, and J2SE 1.4.2 to 1.4.2_22.
>
> This release is only for Mac OS X 10.5.8 or later versions of Mac OS X 10.5.
>
> This release of J2SE 5.0 and J2SE 1.4.2 supports all Intel and
> PowerPC-based Macs. Java SE 6 is available on 64-bit Intel-based Macs only.
>
> ===========================
>
> Yeah, I hate them too.
>
> --
> Best Regards,
> Vladimir Kirichenko
>
>

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

[scala] Re: [ANN] YaScalaDT 0.1.0 (eclipse plugin)

2009-11-26T01:53:22Z

I created a project on github

http://github.com/davidB/yascaladt-doc

to store info, issue,...

On Wed, Nov 25, 2009 at 09:40, David Bernard <david.bernard.31@...> wrote:

Hi,

As some my coworkers, some of you could interested by the first version of my first eclipse plugin ;). There is no site/doc yet.
Current feature :
* very basic editor (comment, string, keyword highlight)
* error marker from console output
* hyperlink/jumper on error/warning from console output

The last 2 features are present in all my editor/configuration and is a must have for me.
Marker/Hyperlink support scala-maven-plugin output. So you could create an extranel tool who call scala:cc (or scala:compile) and have error updated in your project.
I've not test but marker/jumper should work with sbt, builr but you need to custom the command to emit (print to console) the line
<path>: -1: compiling
then every marker for <path> (could be the root source dir => recursive) are removed/reset

There is no configuration panel.

The EPFL Scala plugin is not required, and both could work together (from my coworker).

https://sourceforge.net/projects/alchim/files/YaScalaDT/0.1.0/net_alchim31_eclipse_yascaladt_0.1.0.200911202226.jar/download

feedback welcome. (I already work of the second version, more info near)

/davidB

Re: [scala] jvm5 build should be default?

2009-11-25T21:11:49Z

LinkedIn has 100+ engineers stuck on Java 1.5 because of a blocker bug in Apple's 1.6 JDK. It certainly doesn't "work just fine".

--j

On Wed, Nov 25, 2009 at 8:18 PM, Rex Kerr <ichoran@...> wrote:

-1

From a personal perspective, I haven't used 1.5 in a year and a half. I've made everyone who uses a Mac with the Java analysis software I've written go to the trouble of downloading 1.6 for the older versions which works just fine--so if you want to go to the trouble of downloading Scala, you can either get 1.6 for your Mac or get the 1.5 version of Scala. If a few people running large servers that have fixed on 1.5 have to use a 1.5 build of the 2.8 libs, then that's unfortunate but I expect that they have the expertise to do it.

I suspect that in terms of total number of deployments, 1.6 will be vastly more common than 1.5, especially late into next year while 2.8 is still out. I certainly think it would be a bad idea to change which one is the default within the 2.8 series--that sort of stealth change is likely to cause a lot of breakages.

So I recommend planning for the present and future, not for the past, and making the 1.6 version the default, as it is now.

--Rex

On Wed, Nov 25, 2009 at 2:24 PM, Seth Tisue <seth@...> wrote:

I suggest that the jvm5 build be made the default, unmarked build and
the jvm6 one should be the special one.

Re: [scala] jvm5 build should be default?

2009-11-25T20:23:47Z

Ray Racine wrote:
> I'd say most people expect the latest Scala release to run on the latest
> JVM leveraging the latest capabilities.
> JDK 1.6 (Mustang) was released
> 12/12/2006, three years ago. 1.5 (Tiger) was released 9/29/2004 5
> years ago.

I'd say that is true for Sun-developed world only. Java 1.6 was released
for OSX a year ago. And never going to be released for hardware that was
produced 2 years ago. A lots of it still in retail, brand new with
hardware warranty.

--
Best Regards,
Vladimir Kirichenko

signature.asc (267 bytes) Download Attachment

Re: [scala] jvm5 build should be default?

2009-11-25T20:18:15Z

-1

From a personal perspective, I haven't used 1.5 in a year and a half. I've made everyone who uses a Mac with the Java analysis software I've written go to the trouble of downloading 1.6 for the older versions which works just fine--so if you want to go to the trouble of downloading Scala, you can either get 1.6 for your Mac or get the 1.5 version of Scala. If a few people running large servers that have fixed on 1.5 have to use a 1.5 build of the 2.8 libs, then that's unfortunate but I expect that they have the expertise to do it.

I suspect that in terms of total number of deployments, 1.6 will be vastly more common than 1.5, especially late into next year while 2.8 is still out. I certainly think it would be a bad idea to change which one is the default within the 2.8 series--that sort of stealth change is likely to cause a lot of breakages.

So I recommend planning for the present and future, not for the past, and making the 1.6 version the default, as it is now.

--Rex

On Wed, Nov 25, 2009 at 2:24 PM, Seth Tisue <seth@...> wrote:

I suggest that the jvm5 build be made the default, unmarked build and
the jvm6 one should be the special one.

Re: [scala] jvm5 build should be default?

2009-11-25T19:58:57Z

Dean Wampler wrote:
> Unless I'm mistaken, 1.6 is now the default on Snow Leopard.
> dean

It doesn't change the fact that a lots of mac desktops, laptops and
servers with power and intel x32 architectures and pre-snow-leopard OS
versions still exist and could not be upgraded to snow leopard and apple
is not going to upgrade java for them.

http://support.apple.com/kb/HT3649

===========================

This release updates Java SE 6 to version 1.6.0_15, J2SE 5.0 to version
1.5.0_20, and J2SE 1.4.2 to 1.4.2_22.

This release is only for Mac OS X 10.5.8 or later versions of Mac OS X 10.5.

This release of J2SE 5.0 and J2SE 1.4.2 supports all Intel and
PowerPC-based Macs. Java SE 6 is available on 64-bit Intel-based Macs only.

===========================

Yeah, I hate them too.

--
Best Regards,
Vladimir Kirichenko

signature.asc (267 bytes) Download Attachment

[scala] Re: GPCE'10 First Call for Papers (apologies for cross-postings)

2009-11-25T19:46:03Z

Hi all,

Scala is a great language for developing generative programming tools
and developing highly expressible and reusable components. The GPCE
conference is interested to hear about cutting-edge techniques of
generative
and component-based software. You can show what Scala can do in this
area by submitting a research paper or a tool demonstration to GPCE!

------------------------------------------------------------------------
CALL FOR PAPERS

Ninth International Conference on
Generative Programming and Component Engineering
(GPCE 2010)

October 10-13, 2010
Eindhoven, The Netherlands
(co-located with SLE 2010)

http://www.gpce.org
------------------------------------------------------------------------

IMPORTANT DATES

* Submission of abstracts: May 17, 2010
* Submission of papers: May 24, 2010
* Author notification: Jul 5, 2010

SCOPE

Generative and component approaches are revolutionizing software
development similar to how automation and components revolutionized
manufacturing. Generative Programming (concerning programs that
synthesize other programs), Component Engineering (concerning
modularity in application design), and Domain-Specific Languages
(DSLs) (concerning compact domain-specific notations for expressing
programs) are key technologies for automating program development.

The International Conference on Generative Programming and Component
Engineering is a venue for researchers and practitioners interested in
techniques that, through deploying components and program generation,
increase programmer productivity, improve software quality, and
shorten the time-to-market of software products. In addition to
exploring cutting-edge techniques of generative and component-based
software, our goal is to foster further cross-fertilization between
the software engineering and the programming languages research
communities.

SUBMISSIONS

Research papers:

10 pages in SIGPLAN proceedings style (sigplanconf.cls) reporting
original research results that contribute to scientific knowledge in
the areas listed below (the PC chair can advise on appropriateness).

Tool demonstrations:

Tool demonstrations should present tools that implement novel
generative and component-based software engineering techniques, and
are available for use. Any of the GPCE'10 topics of interest are
appropriate areas for research demonstrations. Purely commercial tool
demonstrations will not be accepted. Submissions should contain a tool
description of 4 pages in SIGPLAN proceedings style (sigplanconf.cls)
and a demonstration outline of up to 2 pages text plus 2 pages screen
shots. The four page description will, if the demonstration is accepted,
be published in the proceedings. The 2+2 page demonstration outline
will only be used by the PC for evaluating the submission.

TOPICS

GPCE seeks contributions in software engineering and in programming
languages related (but not limited) to:

* Generative programming
o Reuse, meta-programming, partial evaluation, multi-stage and
multi-level languages, step-wise refinement, generic programming
o Semantics, type systems, symbolic computation, linking and
explicit substitution, in-lining and macros, templates,
program transformation
o Runtime code generation, compilation, active libraries,
synthesis from specifications, development methods,
generation of non-code artifacts, formal methods, reflection
* Generative techniques for
o Product-line architectures
o Distributed, real-time and embedded systems
o Model-driven development and architecture
o Resource bounded/safety critical systems.
* Component-based software engineering
o Reuse, distributed platforms and middleware, distributed
systems, evolution, patterns, development methods,
deployment and configuration techniques, formal methods
* Integration of generative and component-based approaches
* Domain engineering and domain analysis
o Domain-specific languages including visual and UML-based DSLs
* Separation of concerns
o Aspect-oriented and feature-oriented programming,
o Intentional programming and multi-dimensional separation of
concerns
* Industrial applications of the above

Submissions must adhere to SIGPLAN's republication policy. Please
contact the program chair if you have any questions about how this
policy applies to your paper (chairs@...).

ORGANIZATION

General Chair: Eelco Visser (Delft University of Technology, The
Netherlands)
Program Chair: Jaakko J‰rvi (Texas A&M University, USA)
Publicity Chair: Giorgios Economopoulos (University of Southampton, UK)

Program Committee

* Sven Apel (University of Passau, Germany)
* Don Batory (University of Texas, USA)
* Martin Bravenboer (LogicBlox, USA)
* Krzysztof Czarnecki (University of Waterloo, Canada)
* Charles Consel (INRIA / LaBRI, France)
* Gabriel Dos Reis (Texas A&M University, USA)
* Ewen Denney (RIACS/NASA Ames, USA)
* Ronald Garcia (Carnegie Mellon University, USA)
* Magne Haveraaen (University of Bergen, Norway)
* Johan Lilius (≈bo Akademi University, Finland)
* Andres Lˆh (Utrecht University, The Netherlands)
* Mat Marcus (Canyonlands Software Design, USA)
* Marjan Mernik (University of Maribor, Slovenia)
* Klaus Ostermann (University of Marburg, Germany)
* Bruno C. d. S. Oliveira (Seoul National University, Korea)
* Hridesh Rajan (Iowa State University, USA)
* Sukyoung Ryu (Korea Advanced Institute of Science and Technology)
* Jo„o Saraiva (Minho University, Portugal)
* Sibylle Schupp (Hamburg University of Technology, Germany)
* Kwang Yi (Seoul National University, Korea)
* Mirko Viroli (University of Bologna, Italy)
* Alessandro Warth (Viewpoints Research Institute, USA)
* Edwin Westbrook (Rice University, USA)
* Jeremiah Willcock (Indiana University, USA)

Re: [scala] jvm5 build should be default?

2009-11-25T18:58:43Z

i am with martin on this one.

On Thu, Nov 26, 2009 at 5:22 AM, martin odersky <martin.odersky@...> wrote:

> The main advantage of the jvm6 build is better concurrency support
> through the use of the more modern FJ library. For the moment, only
> scala actors use this library (and there is an alternate, less
> performing build of them available for 1.5). But once the final 2.8
> release is out, there might already be some fast parallel collection
> classes included, which would also rely on 1.6.
>
> So, the tradeoff is: Do we want to make fast concurrency and
> parallelism the default, or rather support Java 1.5 by default? I am
> aware of the constraints of people working with legacy systems, but
> concurrency will quickly become the main reason for Scala. I want to
> make Scala the obvious choice for harnessing concurrency and
> parallelism. And I also realize that if the 1.6 build is not the
> standard, benchmarks such as shootout will likely use 1.5, and we will
> see bad results. For instance, all the highly publicized press how
> Scala actors lose out in the performance game to Kilim is fundametally
> due to the fact that we were stlil hanging on to 1.5.
>
> In the end I believe the switch to 1.6 default will inevitably occur
> over the coming year. Maybe now is on the early side, but given that
> there is an alternative 1.5 build I believe that people should be able
> to deal with it.
>
> The main point is we want to leapfrog Java and we won't be able to do that by
> clinging onto versions that Sun/Oracle itself no longer supports.
>
> Cheers
>
> -- Martin
>

--
.......__o
.......\<,
....( )/ ( )...

Re: [scala] jvm5 build should be default?

2009-11-25T18:50:45Z

+1 for staying with 1.5 for a while.
Not for any technical reason, but merely because a very large
percentage of servers are still 1.5, and cannot or will not upgrade
any time soon.

I seem to recall that when jdk 1.2 came out, some of its runtime features
(which XML impl, which Corba, etc) were enabled with system properties.
Would it be difficult to switch between pedantic&new concurrency that
way?

bob

Re: [scala] Why is containsSlice deprecated in 2.8?

2009-11-25T18:41:16Z

Funny this topic on "slices" should just today I was mulling over the fact that Scala needs a good "slice" library. Slices, Array-Like Slices, Vector-Like Slices, String Slices et al. can be pretty useful if one tends to walk the functional immutable side of the street.

The SML standard basis library is a good examples of a slice library.
See http://www.standardml.org/Basis/vector-slice.html#VECTOR_SLICE:SIG:SPEC for example.

Should the term "slice" be kept in reserve for a similar set of libraries in Scala?

On Wed, Nov 25, 2009 at 7:14 PM, Quenio dos Santos <queniodossantos@...> wrote:

Please keep it. It is much more meaningful than the alternative. I'll take a boolean function any time over a function that returns "special results" like "-1".

On Wed, Nov 25, 2009 at 4:50 AM, martin odersky <martin.odersky@...> wrote:

On Wed, Nov 25, 2009 at 12:16 AM, Seth Tisue <seth@...> wrote:
>
> Welcome to Scala version 2.8.0.Beta1-RC1 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_15).
>
> scala> "foobar" containsSlice "oba"
> <console>:5: warning: method containsSlice in trait SeqLike is deprecated: Should be replaced by <code>indexOfSeq(that) != -1</code>
> "foobar" containsSlice "oba"
> ^
> res0: Boolean = true
>
> I really like containsSlice; I use it all the time in my code. using -1
> as a sentinel value seems uglier and un-Scala-like to me.
>
> I went through my code and changed it to use indexOfSeq everywhere
> instead, to make the warnings go away, and it seemed to me that in every
> case, the resulting code was less elegant and less readable. Any chance
> of an un-deprecation?
>
> --

> Seth Tisue @ Northwestern University / http://tisue.net
> lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
>

I thougt it was not used much, and that what it did added little to
just spelling things out:

def containsSlice[B](that: Seq[B]): Boolean = indexOfSeq(that) != -1

So it got deprecated in the interest of keeping the API small. But
it's a borderline case. If people do care about it I am happy to
undeprecate.

Cheers

-- Martin

--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius

Re: [scala] jvm5 build should be default?

2009-11-25T18:11:59Z

On Wed, Nov 25, 2009 at 4:18 PM, Paul Phillips <paulp@...> wrote:

Not doing it now doesn't limit the opportunity to do it sometime in 2010.

Isn't that exactly what Martin wrote? I think you're in agreement.

Re: [scala] jvm5 build should be default?

2009-11-25T18:00:18Z

I'd say most people expect the latest Scala release to run on the latest JVM leveraging the latest capabilities. JDK 1.6 (Mustang) was released 12/12/2006, three years ago. 1.5 (Tiger) was released 9/29/2004 5 years ago.

If an individual, group or organization is cutting edge enough to dev/run/deploy on the soon to be freshly minted Scala 2.8 release then running on the current 3 year old latest JVM should be the default expectation.

2.8 on 1.6.

--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius

Re: [scala] jvm5 build should be default?

2009-11-25T17:08:07Z

Unless I'm mistaken, 1.6 is now the default on Snow Leopard.

dean

On Wed, Nov 25, 2009 at 6:56 PM, Vladimir Kirichenko <vladimir.kirichenko@...> wrote:

martin odersky wrote:

> In the end I believe the switch to 1.6 default will inevitably occur
> over the coming year.

Not in the mac world, people! Not in the mac world!

--
Best Regards,
Vladimir Kirichenko

--
Dean Wampler
coauthor of "Programming Scala" (O'Reilly)
- http://programmingscala.com

Re: [scala] jvm5 build should be default?

2009-11-25T16:56:37Z

martin odersky wrote:

> In the end I believe the switch to 1.6 default will inevitably occur
> over the coming year.

Not in the mac world, people! Not in the mac world!

--
Best Regards,
Vladimir Kirichenko

signature.asc (267 bytes) Download Attachment

Re: [scala] Why is containsSlice deprecated in 2.8?

2009-11-25T16:14:12Z

Please keep it. It is much more meaningful than the alternative. I'll take a boolean function any time over a function that returns "special results" like "-1".

On Wed, Nov 25, 2009 at 4:50 AM, martin odersky <martin.odersky@...> wrote:

On Wed, Nov 25, 2009 at 12:16 AM, Seth Tisue <seth@...> wrote:
>
> Welcome to Scala version 2.8.0.Beta1-RC1 (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_15).
>
> scala> "foobar" containsSlice "oba"
> <console>:5: warning: method containsSlice in trait SeqLike is deprecated: Should be replaced by <code>indexOfSeq(that) != -1</code>
> "foobar" containsSlice "oba"
> ^
> res0: Boolean = true
>
> I really like containsSlice; I use it all the time in my code. using -1
> as a sentinel value seems uglier and un-Scala-like to me.
>
> I went through my code and changed it to use indexOfSeq everywhere
> instead, to make the warnings go away, and it seemed to me that in every
> case, the resulting code was less elegant and less readable. Any chance
> of an un-deprecation?
>
> --

> Seth Tisue @ Northwestern University / http://tisue.net
> lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
>

I thougt it was not used much, and that what it did added little to
just spelling things out:

def containsSlice[B](that: Seq[B]): Boolean = indexOfSeq(that) != -1

So it got deprecated in the interest of keeping the API small. But
it's a borderline case. If people do care about it I am happy to
undeprecate.

Cheers

-- Martin

Re: [scala] jvm5 build should be default?

2009-11-25T15:27:42Z

On Wed, Nov 25, 2009 at 10:18 PM, Paul Phillips <paulp@...> wrote:

> On Wed, Nov 25, 2009 at 10:22:35PM +0100, martin odersky wrote:
>> So, the tradeoff is: Do we want to make fast concurrency and
>> parallelism the default, or rather support Java 1.5 by default?
>
> I don't see this as a matter of supporting 1.5 per se, but of providing
> a stable and currently practical baseline for people to orient around,
> and minimizing the burden on people shipping libraries. They have it
> hard enough with the binary compatibility situation. We've spent over a
> year working on 2.8 and it all works on 1.5. There are still millions
> of machines running 1.5. There will still be 2.8.1 after we have a
> better handle on the many tooling, distribution, compatibility, etc.
> issues which come with attempting to build against multiple JDKs.
>
> I think the cart is getting ahead of the horse. Concurrency cannot be
> the main reason for using scala if people won't or can't use scala
> because we are not responsive to their actual needs. Right now we don't
> need the extra layer of challenge the jvm5/jvm6 schism presents. Not
> doing it now doesn't limit the opportunity to do it sometime in 2010.

This is all true, but it's not at all clear to me that it's relevant.
Yes, 1.5 builds of the Scala toolchain must to be provided, but that
doesn't mean that that has to be done by EPFL. I don't see why a
combination of community support and third parties can't take up the
slack here and leave Martin and the EPFL team to do what they do best.

> It's funny to have to argue this with you because we have completely
> switched places!

When smart, knowledgeable, people disagree and find themselves
swapping positions that's usually a very strong indication that
there's no clear cut right answer.

Cheers,

Miles

--
Miles Sabin
tel: +44 (0)7813 944 528
skype: milessabin
http://www.chuusai.com/
http://twitter.com/milessabin

Re: [scala] jvm5 build should be default?

2009-11-25T15:20:20Z

Yes, but the path of least resistance is to build against the default version of Scala. If the default for Scala is 1.6, then library-writers have to make an extra effort to provide a library that is maximally compatible.

Also, I forgot to mention the Shootout. It should be possible to run the Scala code with several different environments. There's three different setups for Java, several different VMs (!) for JavaScript/Lua/Ruby/etc, each with their own numbers. I don't see why this isn't also possible for Scala.

--j

On Wed, Nov 25, 2009 at 3:17 PM, Ricky Clarkson <ricky.clarkson@...> wrote:

> If the default for Scala is 1.6, then library-writers
> have to go out of their way to offer two builds of their libraries if they also want to support 1.5.

Or just provide a 1.5 build.

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

Re: [scala] jvm5 build should be default?

2009-11-25T15:17:31Z

> If the default for Scala is 1.6, then library-writers
> have to go out of their way to offer two builds of their libraries if they also want to support 1.5.

Or just provide a 1.5 build.

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

Re: [scala] scala announce not cross posted

2009-11-25T15:12:51Z

Why not just add scala@... as a subscriber to the scala-announce mailing list? That shouldn't require admin access.

--j

On Wed, Nov 25, 2009 at 2:33 PM, Antonio Cunei <antonio.cunei@...> wrote:

I need to check whether it can be done; we have no control over the EPFL mailing list software at present, so that may or may not be possible.

I'll check with the admins!
Toni

martin odersky wrote:

I think scala announce should be cross-posted to Scala, if our mailing
list admins admit that.

Cheers
-- Martin

Re: [scala] jvm5 build should be default?

2009-11-25T14:52:33Z

+1

The vast majority of libraries don't use concurrency. It should be easy for these library-writers to release builds that work for the widest possible set of Scala users. If the default for Scala is 1.6, then library-writers have to go out of their way to offer two builds of their libraries if they also want to support 1.5. If the default for Scala is 1.5, no additional effort is necessary.

For the small subset of library-writers that care about additional concurrency features in 1.6 (or even 1.7, which adds even more concurrency libraries!), they can offer 1.6-only or 1.7-only builds.

For application-writers (as opposed to library-writers), the default should be correctness, not performance. If the default for Scala and for Scala libraries is 1.5, then application-writers don't need to worry about the correctness of their program (like the isEmpty bug). If the default for Scala and Scala libraries is 1.6, then application writers on 1.5 do need to worry about correctness, making sure to pick the right version of Scala and making sure that all their Scala libraries offer the right builds.

Application-writers that care about performance and fast concurrency already have to do a lot of tweaking: VM settings, GC settings, compiler settings, etc. Asking them to do some additional tweaking to use the most perfomant versions of Java, Scala, and their libraries is not much additional burden.

--j

On Wed, Nov 25, 2009 at 2:39 PM, David Pollak <feeder.of.the.bears@...> wrote:

On Wed, Nov 25, 2009 at 2:18 PM, Paul Phillips <paulp@...> wrote:

On Wed, Nov 25, 2009 at 10:22:35PM +0100, martin odersky wrote:
> So, the tradeoff is: Do we want to make fast concurrency and
> parallelism the default, or rather support Java 1.5 by default?

I don't see this as a matter of supporting 1.5 per se, but of providing
a stable and currently practical baseline for people to orient around,
and minimizing the burden on people shipping libraries. They have it
hard enough with the binary compatibility situation. We've spent over a
year working on 2.8 and it all works on 1.5. There are still millions
of machines running 1.5. There will still be 2.8.1 after we have a
better handle on the many tooling, distribution, compatibility, etc.
issues which come with attempting to build against multiple JDKs.

I think the cart is getting ahead of the horse. Concurrency cannot be
the main reason for using scala if people won't or can't use scala
because we are not responsive to their actual needs. Right now we don't
need the extra layer of challenge the jvm5/jvm6 schism presents. Not
doing it now doesn't limit the opportunity to do it sometime in 2010.

This is a very compelling argument, especially in light of the fact that the concurrency related pieces of Scala (e.g., the Actors library) could be packaged separately and specified as "JDK 1.6+ only".

It's funny to have to argue this with you because we have completely
switched places!

--
Paul Phillips | Giving every man a vote has no more made men wise
In Theory | and free than Christianity has made them good.
Empiricist | -- H. L. Mencken
up hill, pi pals! |----------* http://www.improving.org/paulp/ *----------

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

Re: [scala] jvm5 build should be default?

2009-11-25T14:39:58Z

On Wed, Nov 25, 2009 at 2:18 PM, Paul Phillips <paulp@...> wrote:

On Wed, Nov 25, 2009 at 10:22:35PM +0100, martin odersky wrote:
> So, the tradeoff is: Do we want to make fast concurrency and
> parallelism the default, or rather support Java 1.5 by default?

I don't see this as a matter of supporting 1.5 per se, but of providing
a stable and currently practical baseline for people to orient around,
and minimizing the burden on people shipping libraries. They have it
hard enough with the binary compatibility situation. We've spent over a
year working on 2.8 and it all works on 1.5. There are still millions
of machines running 1.5. There will still be 2.8.1 after we have a
better handle on the many tooling, distribution, compatibility, etc.
issues which come with attempting to build against multiple JDKs.

I think the cart is getting ahead of the horse. Concurrency cannot be
the main reason for using scala if people won't or can't use scala
because we are not responsive to their actual needs. Right now we don't
need the extra layer of challenge the jvm5/jvm6 schism presents. Not
doing it now doesn't limit the opportunity to do it sometime in 2010.

This is a very compelling argument, especially in light of the fact that the concurrency related pieces of Scala (e.g., the Actors library) could be packaged separately and specified as "JDK 1.6+ only".

It's funny to have to argue this with you because we have completely
switched places!

--
Paul Phillips | Giving every man a vote has no more made men wise
In Theory | and free than Christianity has made them good.
Empiricist | -- H. L. Mencken
up hill, pi pals! |----------* http://www.improving.org/paulp/ *----------

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

Re: [scala] scala announce not cross posted

2009-11-25T14:33:48Z

I need to check whether it can be done; we have no control over the EPFL
mailing list software at present, so that may or may not be possible.

I'll check with the admins!
Toni

martin odersky wrote:
> I think scala announce should be cross-posted to Scala, if our mailing
> list admins admit that.
>
> Cheers
> -- Martin
>