Scala Plenary Meeting Report 2011/10/04

[Adriaan Moors]

This summary is intended for Scala contributors and maintainers, and assumes a certain familiarity with Scala's internals.
It is for your information only, provided “AS IS” with no warranties and it confers no rights (okay, if you ask nicely we'll think about it).

Scala Plenary Meeting Report 2011/10/04 (apologies for the delay)

Attending

Luc: fixes for generics, more bugfixing
Nada: lms javascript, simple example working
Grzegorz: Scala+GWT+IDE hacking and interview with Phil, (with Nada) recursive functions work in lms, we draw Koch snowflakes using canvas
Adriaan: continuous builds for virtualized-scala, finished up typedReifiedNew, documenting virtualized-scala to get ready for PEPM2012 tool paper (with Tiark)
Vlad: working on a submission for PEPM2012 (workshop of POPL)
Tiark: Delite struct flattening / struct of array <-> array of struct transform
Frederik: presentations for Typesafe
Tom: from Tubingen in Germany, research of database supported program execution, developed Ferry (used by Chris)
Vojin: hacking delite and lms, merged Tiark’s work on loop folding
Philipp: working on source contexts, talk next week
Lukas: upgrading jira and fisheye (review tool)
Chris: returned yesterday, starting off database integration in scala
Miguel: support for clr generics
Eugene: macro proposal, more details, split the proposal into several parts: core vs other (see https://github.com/xeno-by/kepler/tree/master/papers for more details)
Stefan: setting up stuff, project Sliq (relational database project)
Phil: typesafe stuff, paper on vector concat, scala-lang pages, working with Greg on GWT
Martin: reflection and staging, this week project planning, teaching
Heather: thread pools cleanup, students, semester projects, translating slides for programmation avancee
Manohar: benchmarking resources - establish how to deal with very different benchmarks - none of the targets have similar
Toni: company stuff
Alex: teaching, specialization tickets, meetings with students. Hacking on Delite with Vojin while working on collections support.
Trond: training courses
Iulian: build infrastructure is now built and served from our own servers, moved source code to github, beta11
Paul: driving around solving misteries in his van :) - performance work in case classes,
Tiark: hacking delite

Discussion

GitHub move status [adriaan]
what’s the ETA? which repo will it be based on? (I’m sitting on a lot of forks of scala/scala)
I set up Jenkins for scala-virtualized using my github repo (jenkins monitors integration branch, merges it into master and pushes back to github when ant build is successful), if we know which repo we’ll be using, can’t we start doing this already (stay with ant but move to github)
That is, if SBT build is not around the corner?

Disclaimer: the git plugin for jenkins is usable (by complementing it with the github plugin) but not great (merging integration branch into master and pushing back is a little rough: will need to hack plugin to disable pushing jenkins’s internal tags to github); they’re working on a rewrite, no idea about the ETA of that one, of course.

Discussion:

• scala/scala will be completely rewritten to
• enforce formatting: no trailing whitespace, no tabs, standard line-endings
• remove starr-s (doing it is not a problem, the problem is doing it nicely)
• we don’t want to have a list of starr urls
• challenge: we can’t rewrite the history once again, just inject the necessary code to download starr
• deadline: discuss with Josh
• Lukas: Jira and FishEye have links to svn -- we need to update them (keep svn readonly and leave old links in place / new links should point to git)
• we want to decouple the github move and sbt build

Range positions [martin]
Respecting range positions - decay in the ide which has to do with the fact that transformations in the typer or parser don’t respect range positions

• every checked in change - automatically check range positions
• range positions = not just a position point but start and end, contained in tree nodes (RangePosition is a subclass of Position) - there is map of RangePositions in CompilationUnit

invariants:

1. range positions of child nodes are contained in range pos of parent nodes
2. no overlap (except for transparent range positions)
3. rangepos cover whole program

problems:

• templates
• for

check files contain positions

rangeposition(start,point,end).focus == offsetposition(point) // escape from non-overlap invariant

JIRA Status report

• upgraded to the latest versions
• more logging enabled (to check to “Anonymous”)
• move to Assembla?
• slower than JIRA
• seems a bit less reliable
• only if we can’t fix JIRA

[Simon Ochsenreither]

Thanks for the update!

Two questions:

Regarding the scala/scala rewrite: Any chance to also fix the comment style to be in line with the stdle guide? Afair the proposal to do that was shot down because of “we can't rewrite the whole source, every fork will break” last time ... so if exactly this rewrite is happening now it might make sense to include that.


Regarding JIRA and “move to Assembla?”:
If we want to move from JIRA's “MBA-micromanages-work-of-developers”-style to a more developer-centered style, what about YouTrack? Wouldn't that more or less fit the requirements?

Bye,


Simon

[Josh Suereth]

On Tue, Oct 18, 2011 at 11:27 AM, Simon Ochsenreither <simon.och...@googlemail.com> wrote:

Thanks for the update!

Two questions:

Regarding the scala/scala rewrite: Any chance to also fix the comment style to be in line with the stdle guide? Afair the proposal to do that was shot down because of “we can't rewrite the whole source, every fork will break” last time ... so if exactly this rewrite is happening now it might make sense to include that.

If you have a command that works against all versions of Scala, I'm willing to try it.  As of now, I can't rewrite all history here without breaking the build-ability of all history.  

Currently we will be fixing some whitespace formatting issues and end of line styles.

[martin odersky]

On Tue, Oct 18, 2011 at 5:30 PM, Josh Suereth <joshua....@gmail.com> wrote:

On Tue, Oct 18, 2011 at 11:27 AM, Simon Ochsenreither <simon.och...@googlemail.com> wrote:

Thanks for the update!

Two questions:

Regarding the scala/scala rewrite: Any chance to also fix the comment style to be in line with the stdle guide? Afair the proposal to do that was shot down because of “we can't rewrite the whole source, every fork will break” last time ... so if exactly this rewrite is happening now it might make sense to include that.

What's the recommended style in the guide? Generally, I would be skeptical that we need conformity here. Comment style is probably the least of our standardization worries. I am totally easy with reading different versions of doc comments. In fact, they might all have their place. It's like insisting on blank lines or forbidding them. Depending on the context, blank lines can increase or decrease readability. One size does not fit all.

Cheers

 -- Martin

[Simon Ochsenreither]

The style guide recommends right-aligning the stars of ScalaDoc so that the text is consistently aligned.

/** 
  * 
  */

While in the standard library most comments use this style:

/** 
 * 
 */

Thanks and bye,

Simon

[martin odersky]

On Tue, Oct 18, 2011 at 6:29 PM, Simon Ochsenreither <simon.och...@googlemail.com> wrote:

The style guide recommends right-aligning the stars of ScalaDoc so that the text is consistently aligned.

/** 
  * 
  */

While in the standard library most comments use this style:

/** 
 * 
 */

I am not sure on either style. I also use the predominant scala library style. The right aligned one looks weird to me, to be honest. So changing the whole scala distro looks premature to me.

Btw, does Java have a recommended doc comment style?

 -- Martin

[Josh Suereth]

Which style guide recommends this?  I think the standard library follows general convention from Java, at least what I've seen.

- Josh

[Jason Zaugg]

Guys, this is a re-hash of an old conversation. I don't remember the conclusion, though.

https://groups.google.com/d/msg/scala-debate/LMKC2Pw6JT8/iHaUbUOy4pwJ

-jason

[martin odersky]

Thanks for the reminder. It did start to look familar. I think the conclusion was not to enforce the right-aligned style. I would be happy if the style guide would not require it either.

Cheers

 -- Martin

[Josh Suereth]

+1 on that.

[Som Snytt]

Speaking as a novi (novi === newbie), without a dog in the matter (except that I'd like scaladoc to support runnable @example [even as compiled to javascript] and I'd like it to do what Swing knew it needed, namely, a way to express "slices" of a fat interface [for pedagogic purposes, at least]):

I noticed somewhere the recommendation for the * aligned at the second star of /**.  I assumed it was another Martinism, like "+ (no space intervening) for string concat (though in fact he abjures the new scaladoc alignment).

My contribution to the conversation: as an adopter, it actually helps me to have mnemonic cues that I'm "not in Kansas anymore."

When I switched from C to Java, switching from K&R braces (where vi's ]] works) reminded me what I was up to.  My method braces are also line-ending, and it seems somehow pathetic when I see them on the next line.

Similarly, in adopting Scala, I follow Martinisms such as "+ religiously because it tells my brain which language my fingers are typing (where typing means "striking keys on a keyboard", and not what a typechecker does).

This issue is especially acute when coding as a novi in both Java and Scala. Just switching from "Foo foo" to "def foo: Foo" (while trivial) results in a certain number of "argh"-edit-recompile moments each day.

My reaction to the "new scaladoc convention":  Isn't that odd, but look, it makes perfect sense, because the indentation aligns with that other Scala convention, :se tabstop=2.  (I.e., the stars align with my method code.)

It's worth noting that four-space indentation looks legacy to me now.

Recall that in C, tabs were useful because they would print (on paper, which one never uses these days) at ts=8, but at ts=4 on a CRT. In these latter days, ts=2 (albeit tabs converted to spaces).  This is a powerful cue (to the brain, or whatever subsystems thereof) that we are coding in Scala and not in legacy languages.

In this spirit,
  /** This method does something
    * that will blow your mind
    */
  def foo: Foo = {
    something()
    mindBlowing // aligns with doc stars
  }
is cognitively useful.  Just as one likes to write a one-liner function if possible, one writes a one-liner doc comment (for the same reason, brevity) but later expands it by hitting <return> and writing more words.

I was raised to ensure my C code was "self-documenting."  I would propose that Scala's putative "dearth of documentation" is really a search for the sweet spot of self-documentaton, with many one-liners and occasional multi-liners.  Long docs are probably really @examples.

The old song goes, "Everything's up-to-date in Kansas City," so maybe one doesn't want a cue that one isn't in Kansas anymore.