- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Scala Meeting Report Draft for 2011-07-19
Wed, 2011-07-20, 12:45
Scala Meeting report,
2011-07-19
We are currently publishing a summary of each of the weekly meetings of the Scala Core Team.
This information is made available as a service to the community. It is by necessity rather brief and gives only a rough approximation of the main points of discussions explored during each meeting; it should not be taken as a source of reliable information, nor as a record of concrete or firm decisions, nor as anything other than a record of a simple discussion.
The summary that follows is primarily intended for Scala contributors and maintainers. If you are not a contributor to the Scala system, the information below is unlikely to be very useful to you, and you might lack some of the necessary background to make sense of all the discussion items.
We do not have enough people on the team to be able to write a more complete record, and we might also not have the resources to discuss every point in detail afterwards. Nevertheless, we hope that this record, cursory as it is, is better than nothing.
------------------------------------------------------------------------------
Scala Meeting 2011-07-19
People attending the meeting: Miguel, Grzegorz, Adriaan, Lukas, Heather, Vlad, Martin, Tiark, Mirco, Alex, Vojin, Toni, Iulian, Yuvi
- Miguel: focus on .NET Erasure, Mixin
- Grzegorz: got showcase running on GWT, still some hacks there, new contributors coming, working on broken signatures
- Adriaan: 2 talks on Scalathon, collected some CLAs
- Lukas: implementing state effects
- Heather: was on Scalathon, refactoring parallel graph processing framework, talk
- Vlad: working on Colladoc, some work on the optimizer, inlining the exception handler
- Martin: worked on reflection, e.g. getClass on an object gives Scala types
- Tiark: hacking on Delite, parallel scan operation, experimenting with the decompiler
- Mirco: working on completion in the IDE - more reliable, integrating the package object wizard, tests for the completion
- Alex: fixing tickets, writing paper on tries and snapshot operations
- Vojin: views for distributed collections, refactoring the distributed collection hierarchy, moved to builders - we will implement MapViews
- Toni: things for the company, got the hard drive with the ScalaDays videos, backporting stuff to 2.9.1, some nondeterministic stability problems with backporting
- Iulian: mostly fixing bugs, completion is working much better
- Yuvi: joining us on the meeting
* Scalathon
- Adriaan, Heather and Yuvi attended
- many people from the industry present - Quora, Foursquare, GridGain, in total more than a 100 people.
- two most important things - commercial users lunch and the community leader lunch. Got feedback from the community that needs to be assembled and organized.
- a suggestion - add the `From Language X to Scala` guides, like ` From Python to Scala`, not just `From Java to Scala`. Commercial users think this might be a good solution.
- a suggestion - Scala idioms guide (e.g., what to do with null values - use an Option constructor)
- some of the technical points that were discussed:
* scaladoc + implicits - how to display members available through implicit conversions? We could include the always available implicit-scope.
* third layer for reflect - separate APIs for tools and for users? Some symbol-related information maybe shouldn’t be visible to the user.
- looking into combining Colladoc and the GitHub documentation repo
- Colladoc - currently has: help pages, openid login, the final product is expected by August or September. The contributed doc comments are merged with the source code and a pull request with the changes is generated.
- CLAs: we don’t have a corporate CLA. Joe Pignato asked some lawyer about that.
* Broken signatures
- Grzegorz found some problems with broken signatures - JDT breaks when importing a type with a broken signature in the classfile. To solve this, the current hack is to parse all the types, generate Java files for them and use that for the classfiles. In the future this will have to be changed.
- examples of broken signature and inner-classes related problems: RedBlackTree, ParIterableLike, some xml stuff...
- we will put tests for the JDT-related builds on Jenkins
We are currently publishing a summary of each of the weekly meetings of the Scala Core Team.
This information is made available as a service to the community. It is by necessity rather brief and gives only a rough approximation of the main points of discussions explored during each meeting; it should not be taken as a source of reliable information, nor as a record of concrete or firm decisions, nor as anything other than a record of a simple discussion.
The summary that follows is primarily intended for Scala contributors and maintainers. If you are not a contributor to the Scala system, the information below is unlikely to be very useful to you, and you might lack some of the necessary background to make sense of all the discussion items.
We do not have enough people on the team to be able to write a more complete record, and we might also not have the resources to discuss every point in detail afterwards. Nevertheless, we hope that this record, cursory as it is, is better than nothing.
------------------------------------------------------------------------------
Scala Meeting 2011-07-19
People attending the meeting: Miguel, Grzegorz, Adriaan, Lukas, Heather, Vlad, Martin, Tiark, Mirco, Alex, Vojin, Toni, Iulian, Yuvi
- Miguel: focus on .NET Erasure, Mixin
- Grzegorz: got showcase running on GWT, still some hacks there, new contributors coming, working on broken signatures
- Adriaan: 2 talks on Scalathon, collected some CLAs
- Lukas: implementing state effects
- Heather: was on Scalathon, refactoring parallel graph processing framework, talk
- Vlad: working on Colladoc, some work on the optimizer, inlining the exception handler
- Martin: worked on reflection, e.g. getClass on an object gives Scala types
- Tiark: hacking on Delite, parallel scan operation, experimenting with the decompiler
- Mirco: working on completion in the IDE - more reliable, integrating the package object wizard, tests for the completion
- Alex: fixing tickets, writing paper on tries and snapshot operations
- Vojin: views for distributed collections, refactoring the distributed collection hierarchy, moved to builders - we will implement MapViews
- Toni: things for the company, got the hard drive with the ScalaDays videos, backporting stuff to 2.9.1, some nondeterministic stability problems with backporting
- Iulian: mostly fixing bugs, completion is working much better
- Yuvi: joining us on the meeting
* Scalathon
- Adriaan, Heather and Yuvi attended
- many people from the industry present - Quora, Foursquare, GridGain, in total more than a 100 people.
- two most important things - commercial users lunch and the community leader lunch. Got feedback from the community that needs to be assembled and organized.
- a suggestion - add the `From Language X to Scala` guides, like ` From Python to Scala`, not just `From Java to Scala`. Commercial users think this might be a good solution.
- a suggestion - Scala idioms guide (e.g., what to do with null values - use an Option constructor)
- some of the technical points that were discussed:
* scaladoc + implicits - how to display members available through implicit conversions? We could include the always available implicit-scope.
* third layer for reflect - separate APIs for tools and for users? Some symbol-related information maybe shouldn’t be visible to the user.
- looking into combining Colladoc and the GitHub documentation repo
- Colladoc - currently has: help pages, openid login, the final product is expected by August or September. The contributed doc comments are merged with the source code and a pull request with the changes is generated.
- CLAs: we don’t have a corporate CLA. Joe Pignato asked some lawyer about that.
* Broken signatures
- Grzegorz found some problems with broken signatures - JDT breaks when importing a type with a broken signature in the classfile. To solve this, the current hack is to parse all the types, generate Java files for them and use that for the classfiles. In the future this will have to be changed.
- examples of broken signature and inner-classes related problems: RedBlackTree, ParIterableLike, some xml stuff...
- we will put tests for the JDT-related builds on Jenkins
Thu, 2011-07-21, 06:57
#2
Re: Scala Meeting Report Draft for 2011-07-19
+1
On Wed, Jul 20, 2011 at 6:20 PM, Seth Tisue <seth@tisue.net> wrote:
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136
+1 206.650.3740
http://biosimilarity.blogspot.com
On Wed, Jul 20, 2011 at 6:20 PM, Seth Tisue <seth@tisue.net> wrote:
On Wed, Jul 20, 2011 at 7:45 AM, Aleksandar Prokopec
<aleksandar.prokopec@epfl.ch> wrote:
> Scala Meeting report, 2011-07-19
This is valuable. So glad to see these reports again. Thank you.
--
Seth Tisue - seth@tisue.net - http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
--
L.G. Meredith
Managing Partner
Biosimilarity LLC
7329 39th Ave SWSeattle, WA 98136
+1 206.650.3740
http://biosimilarity.blogspot.com
Thu, 2011-07-21, 17:18
#3
Re: Scala Meeting Report Draft for 2011-07-19
On Wed, Jul 20, 2011 at 08:45, Aleksandar Prokopec
wrote:
>
> * third layer for reflect - separate APIs for tools and for users? Some
> symbol-related information maybe shouldn’t be visible to the user.
I think this is important. The interface presently available I'd put
in some "internal" package, to indicate users shouldn't rely on that.
I understand "internal" is meant for implementation though.
The API has an staggering number of methods and information that might
be useful to someone somewhere, but this is really not how I'd
approach it. Design for the most common use cases, keep it *simple*.
Put the complexity somewhere that can be reached, but for which no
stability guarantees are made.
I know Seth Tisue also thinks it needs to be simpler. I think Josh
Suereth or Jorge Ortiz -- I don't recall which -- was expressing the
same opinion.
So, if reflection just *has* to go into 2.10, let it be an
easy-to-use, small API that handles the basics, and then develop that
based on input. I don't want Scala to be wedded to a giant white
elephant.
Wed, 2011-07-27, 01:17
#4
Re: Scala Meeting Report Draft for 2011-07-19
On Thu, Jul 21, 2011 at 12:15 PM, Daniel Sobral wrote:
> On Wed, Jul 20, 2011 at 08:45, Aleksandar Prokopec
> wrote:
>>
>> * third layer for reflect - separate APIs for tools and for users? Some
>> symbol-related information maybe shouldn’t be visible to the user.
>
> I think this is important. [...]
> Design for the most common use cases, keep it *simple*. [...]
+1 on a third layer that would deliberately be kept simple.
Martin's proposal for a complete API bristling with methods and
features may well be a very good one — I don't know enough about the
compiler to judge it. But I'm confident it isn't the right API to
expose to 90% of the people who are going to want to use a "Scala
reflection API". They, I mean we, will be intimidated and bewildered
by it.
> I know Seth Tisue also thinks it needs to be simpler. I think Josh
> Suereth or Jorge Ortiz -- I don't recall which -- was expressing the
> same opinion.
At Scalathon I think we had a whole angry mob together on this :-)
> So, if reflection just *has* to go into 2.10, [...]
My understanding is that there's talk of adding it in 2.9.x, even? I
could be wrong.
Wed, 2011-07-27, 17:17
#5
Re: Scala Meeting Report Draft for 2011-07-19
Sent from my phone
On Jul 27, 2011, at 2:04, Seth Tisue wrote:
> On Thu, Jul 21, 2011 at 12:15 PM, Daniel Sobral
> wrote:
>> On Wed, Jul 20, 2011 at 08:45, Aleksandar Prokopec
>> wrote:
>>>
>>> * third layer for reflect - separate APIs for tools and for
>>> users? Some
>>> symbol-related information maybe shouldn’t be visible to the user.
>>
>> I think this is important. [...]
>> Design for the most common use cases, keep it *simple*. [...]
>
> +1 on a third layer that would deliberately be kept simple.
>
> Martin's proposal for a complete API bristling with methods and
> features may well be a very good one — I don't know enough about the
> compiler to judge it.
That's not what I propose. Reflect. Internal is indeed the full
compiler view of reflected entities. Reflect.API has not been fleshed
out yet and can be as simple as we like. My main aim for the
architecture was to make arbitrary projections from internal to api
possible. I currently have not thought about what exactly should go
into API.
Cheers
martin
> But I'm confident it isn't the right API to
> expose to 90% of the people who are going to want to use a "Scala
> reflection API". They, I mean we, will be intimidated and bewildered
> by it.
>
>> I know Seth Tisue also thinks it needs to be simpler. I think Josh
>> Suereth or Jorge Ortiz -- I don't recall which -- was expressing the
>> same opinion.
>
> At Scalathon I think we had a whole angry mob together on this :-)
>
>> So, if reflection just *has* to go into 2.10, [...]
>
> My understanding is that there's talk of adding it in 2.9.x, even? I
> could be wrong.
>
Thu, 2011-07-28, 14:07
#6
Re: Scala Meeting Report Draft for 2011-07-19
On Jul 27, 12:09 pm, Martin Odersky wrote:
> That's not what I propose. Reflect. Internal is indeed the full
> compiler view of reflected entities. Reflect.API has not been fleshed
> out yet and can be as simple as we like. My main aim for the
> architecture was to make arbitrary projections from internal to api
> possible. I currently have not thought about what exactly should go
> into API.
Sounds good, thanks.
--
Seth Tisue | Northwestern University | http://tisue.net
lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
On Wed, Jul 20, 2011 at 7:45 AM, Aleksandar Prokopec
wrote:
> Scala Meeting report, 2011-07-19
This is valuable. So glad to see these reports again. Thank you.