Scala Internals

I was wondering why there were no summaries of the Scala meetings since
November last year. Is there any specific reason or did I miss something?

After reviewing the control dependences of the inlining algorithm, I've come up with an improved version that skips work once it's known for a callsite that no inlining will be made.

The commits at
  https://github.com/magarciaEPFL/scala/commits/fasterTypeFlow
revolve on how the type-flow is computed, because that's the earliest we can know whether some inlining decision is bound to be negative.

Those willing to review or test it are welcome to provide feedback.

On Sun, Jan 29, 2012 at 12:33 PM, iulian dragos wrote:
> The IDE only needs to have a monotonically increasing sequence of
> version numbers.

Where "increasing" is measured by...

If it figures out that 2.10 is later than 2.9 then I take it that it
is number-aware.

> v2.10.0-M1-75-g91f82dfaaf-
>
> The date would be useful when dealing with daily snapshots, indeed.
> But it should come before the git hash, to ensure proper ordering.

That's what the "75" in the above is for. That's guaranteed to be
increasing for as long as it's describing against the same tag. It
would reset to 0 when we tag v2.10.0-M2, but I assume it figures out
that M2 is later than M1.

C:\Projects\Kepler>git describe HEAD --abbrev=7 --match dev
fatal: No names found, cannot describe anything

I have been dissatisfied with the github gem for a while and finally I
gave in and started applying the github api directly. I bet any heavy
github users can think of ALL KINDS of places they'd like to
streamline the interface.

In order to speed up operations yielding new scalax.collection.Graph
instances, it would be nice for Graph instances to structurally share
data just like List, Set etc. manage to. But how could structural
sharing be achieved despite nodes and edges being represented by inner
class instances?

Peter

Hi,

as far as I remember it came up already before Java 7. I'm interested and wondering if there are plans on how to go forward with regard to the Java version Scala is depending on ...

At the moment Scala is still supporting Java 5 (EOL'd October 2009) and Java 6 (EOL'd July 2012), so when the version after 2.10 is released everything older than Java 7 is not publicly supported anymore.
What about having 2.10 as the last version targeting Java > 5 and bumping up the Java version for 2.11 to Java 7? (Of course Typesafe can sell support for to provide additional builds ...)

By moving the baseline to Java 7, I see at least these benefits, which might save effort in the long term:

Changes to Google Privacy Policy and Terms of Service

Is this email not displaying properly?
View it in your browser.

Dear Google user,