gmane.comp.lang.scala.internals

Re: Max Overload

Chris Hodapp — 2012-05-25T23:11:34

Chris Vogt (I have to specify his last name to make sure it's clear that 
I'm not referring to myself in the third person) has pointed out that I can 
also accomplish what I need to by implementing the relatively less 
controversial default and named type parameters. I also indicated to him 
that I was willing to work on making that happen. I guess that means a SIP 
will need to be drafted. I will begin a discussion on debate, as prescribed 
by the SIP submission process documentation.

As a side-note: I do still think that what I've described here is an issue. 
It's just not holding me up from working on my SOC project anymore. 
Therefore, I reserve bring it up again in the future with a more 
fully-thought-out proposal.

On Tuesday, May 22, 2012 3:34:40 AM UTC-5, Chris Hodapp wrote:

Minor-to-miniscule: default ForkJoinWorkerThread doesn't call super.onStart (ExecutionContextImpl)

Som Snytt — 2012-05-25T23:04:34

< at >axel22:

Hi, I was looking at the behavior of some multithreaded code (and don't we
all?)...

since the ForkJoinPool update, ForkJoinWorkerThread.onStart is empty, but
it still recommends calling super (in case Doug Lea puts something back in).

The custom subclass in ExecutionContextImpl doesn't call super.

This isn't quite a bug waiting to happen; or at least, it's not a bug
lurking in the shadows with an evil grin on its face.  It's more like the
kind of bug you catch by not washing your hands with soap while singing
Happy Birthday two times.  (As they say in preschool.)

I don't mind making the totally trivial pull req, which is more fun for me
than for you; or maybe it's worth a //FIXME.

This is modulo my correct reading of the code, of course.  Really I just
wanted to try out the new PRP (pull request protocol)!  In truth, I'd be
nervous to submit a pull req, because wouldn't you know the test suite will
fail with a non-deterministic result.

Thanks!

Question about scopes

Eugene Burmako — 2012-05-25T17:39:56

https://github.com/scalamacros/kepler/blob/d4d397a8bf14da2fe61106f7f7b252557c2c18aa/src/compiler/scala/reflect/runtime/SymbolLoaders.scala#L63

Re: WeakIdentityHashMap

Stefan Zeiger — 2012-05-25T13:56:16

I need a cache for symbols, as in the LMS paper, but there's no scope 
where I could safely introduce a non-weak cache without the risk of 
either geting duplicate symbols or creating a memory leak, so I decided 
to use a weak global cache. Alternatively, I could create a fresh symbol 
each time and then run a clean-up as the first pass of the query 
compiler (where I can still rely on object identity) to merge the 
duplicate symbols. I'll have to implement it to find out whether the 
global cache actually makes things simpler and improves performance.

On 2012-05-25 15:22, ?iktor ?lang wrote:

Re: Question about classpaths

Paul Phillips — 2012-05-25T13:39:35


This formulation assumed immutable maps and the desire to keep both the
before and after classpaths; if one of those assumptions isn't the case,
then a new immutable map can be derived from the new entry, or we could use
mutable maps.

Re: Question about classpaths

Paul Phillips — 2012-05-25T13:36:08


It also calculates everything in one traversal instead of two, and finds
classes by looking up the name in a map rather than a linear search of the
whole package.

I am looking at how we can get incremental changes into classpaths, in

Interactions with classpath itself are fairly minimal; it should be easy to
backport internal-representation changes wholesale.  Changing ClassRep is
what made that commit touch so much.

DeltaClassPath[T](

If things were stored in a map this could look more like

  newEntry get name orElse (original get name)

I think this will win on all fronts (performance, simplicity, memory
utilization) without being hard to backport.

The first remaining question is whether any special magic is needed to

I don't remember how the time broke down.  I do know that reading all the
classes and building the classpath is a huge percentage of the global
initialization time, but obviously a lot of that happens before the weaving.

The second (harder) remaining question is how to feed classpat

Re: RE: Re: [scala] Fixes SI-5428. (#618)

Paul Phillips — 2012-05-25T13:25:14

More importantly, we should be more aggressive about quarantining
non-deterministic tests.  Sometimes the cause is uncertain, but usually
it's pretty clear whether the cause leads back to the test itself, as
opposed to some transient condition which could have hit any test. Also,
test/pending and test/disabled are buried in non-deterministic tests, many
of which have been there for years.  It would be nice to delete those if
they're not coming back.  It makes it impossible to safely move tests out
of pending, because you never know if it passing means that it really
works.  (Any test in pending involving actors is there because it is
non-deterministic, but it would be hard for anyone to know that.)

On Fri, May 25, 2012 at 1:43 AM, Aleksandar Prokopec <
aleksandar.prokopec-p8DiymsW2f8< at >public.gmane.org> wrote:

Re: Question about classpaths

martin odersky — 2012-05-25T13:24:35

work with but agree the new refactoring is better because no more contexts
are needed.

I am looking at how we can get incremental changes into classpaths, in
order to support resident compilers in more scenarios than we do now. I am
not yet sure how big a change it will be. Hopefully not big, because we'd
have to backport everything to 2.9.

For the moment, I was thinking of simply creating a

DeltaClassPath[T](
  original: ClassPath[T],
  oldEntry: ClassPath[T],
  newEntry: ClassPath[T])

that represents a substitution of one entry for another in an existing
classpath. Typically, oldEntry and newEntry are the same directory, but
seen at different times.

The first remaining question is whether any special magic is needed to
recompute classes and packages in a DeltaClassPath incrementally. Do you
have some experience how expensive the weaving of ClassReps in a
MergedClassParth is, relative to the computation of ClassReps in its
entries? If it's not very expensive, maybe we can just weave from scratch.

The

Re: WeakIdentityHashMap

√iktor Ҡlang — 2012-05-25T13:22:18

May I ask why you need it?

On Fri, May 25, 2012 at 2:40 PM, Stefan Zeiger <szeiger-QayF08W3+w1Wk0Htik3J/w< at >public.gmane.org> wrote:

Re: Question about classpaths

Paul Phillips — 2012-05-25T13:12:05

If you're messing with classpaths I would suggest looking at this, where I
did a lot of work.  I failed on several attempts to merge it and it can
only be harder now, but the changes to classpath specifically could be
extracted.

https://github.com/paulp/scala/blob/edb3b4969820d8dc28c8e21774ad129560fe4462/src/compiler/scala/tools/nsc/util/ClassPath.scala#L480

I'm not pointing to the whole commit, which I assume has too many
abstractions; only to the portion of ClassPath.scala from line 480 onward,
especially the "traverse" functions and the fact that they store the
entries in a map.

Re: Question about classpaths

Paul Phillips — 2012-05-25T12:59:47

No, you're right.  I don't know it's written like that (even if I did it)
but right now I'd be surprised if classpaths are ever compared for equality
- or if they are, if they ever turn up equal unless it's the exact same
classpath.

On Fri, May 25, 2012 at 5:42 AM, martin odersky <martin.odersky-p8DiymsW2f8< at >public.gmane.org>wrote:

Question about classpaths

martin odersky — 2012-05-25T12:42:41

Looking at classpaths I see:

  def sortString = join(split(asClasspathString).sorted: _*)

  override def equals(that: Any) = that match {
    case x: ClassPath[_]  => this.sortString == x.sortString
    case _                => false
  }

If I understand the logic correctly, this means that two classpaths are
considered equal if they contain the same entries, no matter in what order.
But I would have thought order matters here. For example
say your classpath is:

  dir1:dir2

and both directories contain a file A.class. Then the one in dir1 is
chosen. So, clearly that classpath is different from

  dir2:dir1

Or do I misunderstand something?

Cheers

 - Martin

WeakIdentityHashMap

Stefan Zeiger — 2012-05-25T12:40:13

I just needed a WeakIdentityHashMap for SLICK. It's not available in 
Scala or in Java (but a bunch of custom Java implementations are 
floating around, one of them even in a com.sun package in the JDK). 
Would it make sense to add one to the Scala library?

Here's what I came up with today (fully integrated into Scala 
collections, as far as I can tell): 
https://github.com/slick/slick/commit/922db71c03676e153c5f3d02673bd815cd71ca67

-sz

Re: lubs of structural types

martin odersky — 2012-05-25T10:25:35


I think it was a fear of bad performance.

In any case it will be best to fundamentally redesign lubs at some point,
so that they are primitive instead of computed.

Cheers

 - Martin

Re: Compiler error exception in macros

Jesús López González — 2012-05-25T09:17:09

That works nice. Thank you.

El viernes, 25 de mayo de 2012 11:04:21 UTC+2, Eugene Burmako escribió:
>

Re: Compiler error exception in macros

Eugene Burmako — 2012-05-25T09:04:21

The notion of the "current" invocation line is vague, because the
invocation might span several lines, it might be synthetic and so on.
That's why I decided not to provide a default value for it in the method
itself.

However, there is `c.enclosingPosition` [1] that quite often represents
what the developer wants. You can use it as the first parameter to c.abort
and similar functions.

[1]
https://github.com/scalamacros/kepler/blob/4cd9e664d192f29f4f0c9bb233d8a496fbcde703/src/library/scala/reflect/makro/Enclosures.scala#L37

On 25 May 2012 10:55, Jesús López González <jess3lg-Re5JQEeQqe8< at >public.gmane.orgm> wrote:

lubs of structural types

Lukas Rytz — 2012-05-25T08:55:39

In "def lub1" a comment says:

          // add a refinement symbol for all non-class members of lubBase
          // which are refined by every type in ts.

Why are structural type members (i.e. members in refinements that don't
have a matching member
in the underlying type) discarded?

scala> class A; class B
scala> if (true) new { def f: A = ??? } else new { def f: B = ??? }
res0: *Object* = $anon$1< at >5f18cd5


Note that if one of the two types specializes the other, the refinement is
kept (due to elimSub):

scala> if (true) new { def f: A = ??? } else new { def f: *Object* = ??? }
res1: Object{def f: Object} = $anon$1< at >454322ba


Historical reasons (before we had structural types)? Performance?

Thanks for insights!

Lukas

Re: Compiler error exception in macros

Jesús López González — 2012-05-25T08:55:27

Could you show how to deal with the 'position' argument? Why is it 
necessary? I am supposing it is useful for pointing to the current 
c.[abort/info/error] invocation line so, can it be done automatically?

El miércoles, 2 de mayo de 2012 16:49:49 UTC+2, Eugene Burmako escribió:
>

Re: RE: Re: [scala] Fixes SI-5428. (#618)

Aleksandar Prokopec — 2012-05-25T08:43:22

Agreed. There might be instances of nondeterministic test failures where 
we are unsure about the exact cause.

Re: RE: Re: [scala] Fixes SI-5428. (#618)

Lukas Rytz — 2012-05-25T08:38:48

On Fri, May 25, 2012 at 10:17 AM, Aleksandar Prokopec <
aleksandar.prokopec-p8DiymsW2f8< at >public.gmane.org> wrote:


I vote for "just merge" in cases where we know the error is unrelated, like
here.

Otherwise, I think there should also be a way to
re-run pr-scala-testsuite-linux-opt.

Re: RE: Re: [scala] Fixes SI-5428. (#618)

Aleksandar Prokopec — 2012-05-25T08:17:21

Yes, these kind of things sometimes happened to me with concurrency 
related tests, and also with ScalaCheck tests, since they generate test 
inputs (it may not be confined just to this instance).

So, question is - what is our workflow in these kinds of situations?
Do we rerun the build? Do we close the pull request (I don't think we 
should do this)? Or do we just merge in the pull request?

Cheers,
Alex


On 5/25/12 10:07 AM, gvojin-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org wrote: