<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.comp.lang.scala.internals">
    <title>gmane.comp.lang.scala.internals</title>
    <link>http://blog.gmane.org/gmane.comp.lang.scala.internals</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9839"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9837"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9836"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9833"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9832"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9823"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9822"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9818"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9805"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9779"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9774"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9773"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9754"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9752"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9725"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9702"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9682"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9672"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9662"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.comp.lang.scala.internals/9623"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9839">
    <title>Autorun for REPL</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9839</link>
    <description>&lt;pre&gt;https://github.com/scalamacros/kepler/commit/f8968b082d5499670e36068d3a0ab65e202c9242

Your thoughts?

&lt;/pre&gt;</description>
    <dc:creator>Eugene Burmako</dc:creator>
    <dc:date>2012-05-26T19:19:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9837">
    <title>compiler no longer builds without specialization</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9837</link>
    <description>&lt;pre&gt;Can anyone speculate on the nature of the dependency which has formed
between value classes and the specialization phase? The compiler now
crashes in erasure if it doesn't run.  If I remove "extends AnyVal" from
StringOps, it compiles.

% scalac -no-specialization
./src/library/scala/collection/immutable/StringOps.scala
error: no-symbol does not have an owner

     while compiling:
./src/library/scala/collection/immutable/StringOps.scala
        during phase: erasure
     library version: version 2.10.0-20120525-153506-b53b71c100
    compiler version: version 2.10.0-20120525-153506-b53b71c100
  reconstructed args: -no-specialization -d /tmp

  last tree to typer: Apply(constructor WrappedString)
              symbol: constructor WrappedString in class WrappedString
(flags: &amp;lt;method&amp;gt; &amp;lt;triedcooking&amp;gt;)
   symbol definition: def &amp;lt;init&amp;gt;(self: String):
scala.collection.immutable.WrappedString
                 tpe: scala.collection.immutable.WrappedString
       symbol owners: constructor WrappedString -&amp;gt; class Wrapp&lt;/pre&gt;</description>
    <dc:creator>Paul Phillips</dc:creator>
    <dc:date>2012-05-26T17:15:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9836">
    <title>Issue 2109 fix</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9836</link>
    <description>&lt;pre&gt;Hi,

   Previously I had an attempt to fix this&amp;lt;https://issues.scala-lang.org/browse/SI-2109&amp;gt;bug (or implement this feature), although the tests were failing, and I 
could not perform all the changes that was asked by Paul (like unifying 
with EncodingHeuristics). Here&amp;lt;https://github.com/aborg0/scala-1/commit/83f358bcf0e4e035540caad7feb09be89ca61a2a&amp;gt;is the commit I have currently.
   I am not sure how important was it, so I would like to ask, whether this 
worth adding before the 2.10 RCs, or not. Or what kind of changes do you 
propose?
   The wrong parts as I see:
 - no UTF-7 BOM support, I am not sure how could that be easily done, or is 
it important at all
 - the test settings have to be modified to pass the tests (removed the 
explicit UTF-8 encoding)
 - the IDE implementors might need further adjustments to support these 
files (I guess this should be easy)
 - I am not really good with git, so the encoding of the test files is not 
set to the proper encoding (neither for the eclipse/IDEA/... projects)&lt;/pre&gt;</description>
    <dc:creator>Gábor Bakos</dc:creator>
    <dc:date>2012-05-26T11:17:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9833">
    <title>Minor-to-miniscule: default ForkJoinWorkerThread doesn't call super.onStart (ExecutionContextImpl)</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9833</link>
    <description>&lt;pre&gt;&amp;lt; at &amp;gt;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!
&lt;/pre&gt;</description>
    <dc:creator>Som Snytt</dc:creator>
    <dc:date>2012-05-25T23:04:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9832">
    <title>Question about scopes</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9832</link>
    <description>&lt;pre&gt;https://github.com/scalamacros/kepler/blob/d4d397a8bf14da2fe61106f7f7b252557c2c18aa/src/compiler/scala/reflect/runtime/SymbolLoaders.scala#L63

&lt;/pre&gt;</description>
    <dc:creator>Eugene Burmako</dc:creator>
    <dc:date>2012-05-25T17:39:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9823">
    <title>Question about classpaths</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9823</link>
    <description>&lt;pre&gt;Looking at classpaths I see:

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

  override def equals(that: Any) = that match {
    case x: ClassPath[_]  =&amp;gt; this.sortString == x.sortString
    case _                =&amp;gt; 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
&lt;/pre&gt;</description>
    <dc:creator>martin odersky</dc:creator>
    <dc:date>2012-05-25T12:42:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9822">
    <title>WeakIdentityHashMap</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9822</link>
    <description>&lt;pre&gt;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

&lt;/pre&gt;</description>
    <dc:creator>Stefan Zeiger</dc:creator>
    <dc:date>2012-05-25T12:40:13</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9818">
    <title>lubs of structural types</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9818</link>
    <description>&lt;pre&gt;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&amp;gt; class A; class B
scala&amp;gt; if (true) new { def f: A = ??? } else new { def f: B = ??? }
res0: *Object* = $anon$1&amp;lt; at &amp;gt;5f18cd5


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

scala&amp;gt; if (true) new { def f: A = ??? } else new { def f: *Object* = ??? }
res1: Object{def f: Object} = $anon$1&amp;lt; at &amp;gt;454322ba


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

Thanks for insights!

Lukas
&lt;/pre&gt;</description>
    <dc:creator>Lukas Rytz</dc:creator>
    <dc:date>2012-05-25T08:55:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9805">
    <title>URL for latest nightly tarball?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9805</link>
    <description>&lt;pre&gt;Hi folks,

This appears to have completely evaporated. There used to be a symlink
to the latest build here,

  http://www.scala-lang.org/archives/downloads/distrib/files/nightly/distributions/scala-2.10.0.latest.tgz

That disappeared a while back, and I've been using

  https://scala-webapps.epfl.ch/jenkins/job/scala-nightly-main/ws/dists/latest/*zip*/latest.zip

since. But that doesn't appear to have updated since
2.10.0-20120504-065643-e52be82eef.

Can we have the symlink to the latest build on scala-lang.org back?

Cheers,


Miles

&lt;/pre&gt;</description>
    <dc:creator>Miles Sabin</dc:creator>
    <dc:date>2012-05-24T13:24:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9779">
    <title>Nightly Scaladoc with problem?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9779</link>
    <description>&lt;pre&gt;I was looking toward seeing Heather's recent pull request on Scaladoc
show up on nightly, but it's just not appearing there. Maybe nightly
is broken, but maybe the wrong build is getting published as
Scaladoc's nightly. It happened once before. Can someone look into it?

&lt;/pre&gt;</description>
    <dc:creator>Daniel Sobral</dc:creator>
    <dc:date>2012-05-23T15:00:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9774">
    <title>actors migration kit fails build</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9774</link>
    <description>&lt;pre&gt;hey vojin,

the commit

https://github.com/scala/scala/commit/e99fb0c93842d517b8a185458f405bace2bbb46b

fails the build in pack.xml
  https://scala-webapps.epfl.ch/jenkins/job/scala-checkin/5744/consoleFull

can you take a look at it?

thanks!
&lt;/pre&gt;</description>
    <dc:creator>Lukas Rytz</dc:creator>
    <dc:date>2012-05-23T13:44:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9773">
    <title>Class with factory method</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9773</link>
    <description>&lt;pre&gt;Hi,

This code does what you expect it to do in Scala but it's probably not 
what you want in many cases:

trait A {
   class Foo(x: Int) {
     def apply = println("A.Foo("+x+")")
   }

   def bar = (new Foo(42)).apply
}

trait B extends A {
   class Foo(x: Int) extends super.Foo(x) {
     def apply = println("B.Foo("+x+")")
   }
}

This is a common situation in the new driver architecture for SLICK 
(using a super-cake pattern). What I usually want is this:

trait A {
   class Foo(x: Int) {
     def apply = println("A.Foo("+x+")")
   }
   def createFoo(x: Int) = new Foo(x)

   def bar = createFoo(42).apply
}

trait B extends A {
   class Foo(x: Int) extends super.Foo(x) {
     def apply = println("B.Foo("+x+")")
   }
   override def createFoo(x: Int) = new Foo(x) // easy to forget!
}

A possible language support for this is not far from the SIP-13 implicit 
classes (except without the implicit and with no restrictions on the 
constructor parameters). All we need is a mechanism for auto-generating 
factory &lt;/pre&gt;</description>
    <dc:creator>Stefan Zeiger</dc:creator>
    <dc:date>2012-05-23T13:41:55</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9754">
    <title>Size increase of Scala Swing jar between 20120511 and 20120521</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9754</link>
    <description>&lt;pre&gt;Hi,

probably I'm just nitpicking, but maybe it is important:

Nothing was changed in swing/event between 20120511 and 20120521, but 11 
new class files appeared there, with names like

KeyTyped$$anonfun$copy$1.class
KeyPressed$$anonfun$copy$2.class
KeyReleased$$anonfun$copy$3.class

each one with ~ 1.5 kb size.

Is this expected?

Thanks,

Simon
&lt;/pre&gt;</description>
    <dc:creator>Simon Ochsenreither</dc:creator>
    <dc:date>2012-05-22T23:05:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9752">
    <title>abstraction?</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9752</link>
    <description>&lt;pre&gt;I can't decide, so was wondering about your opinion:

In the comments of https://github.com/scala/scala/pull/589 I argue that
we should get rid of SymCollector, as one its three subclasses isn't used,
and the other two may need to diverge to fix
https://issues.scala-lang.org/browse/SI-5318.

Then I argue that maybe we should keep them.

What do you think?

    abstract class SymCollector extends TypeCollector(List[Symbol]()) {
      protected def includeCondition(sym: Symbol): Boolean

      def traverse(tp: Type) {
        tp.normalize match {
          case TypeRef(_, sym, _) =&amp;gt;
            if (includeCondition(sym) &amp;amp;&amp;amp; !result.contains(sym)) result =
sym :: result
          case _ =&amp;gt;
        }
        mapOver(tp)
      }
    }

    /** A traverser to collect type parameters referred to in a type
     */
    object freeTypeParamsOfTerms extends SymCollector {
      // An inferred type which corresponds to an unknown type
      // constructor creates a file/declaration order-dependent crasher
      // situat&lt;/pre&gt;</description>
    <dc:creator>Adriaan Moors</dc:creator>
    <dc:date>2012-05-22T22:49:56</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9725">
    <title>scala meeting summary</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9725</link>
    <description>&lt;pre&gt;just a quick update from the meeting notes

on the critical path to M4:
- the pull request that implements exhaustivity for the new pattern matcher
is waiting for a review, but otherwise ready to go
  - unreachability &amp;amp; typetag-based type tests are next
- reflection refactoring: Martin is happy about the new design, but Eugene
&amp;amp; he are still ironing out the implementation, fixing tests

we'll cut M4 when these features are in master, which will either be by the
end of this week or early next week


we now have a pull request policy v0.1:
https://github.com/scala/scala/wiki/Pull-Request-Policy
&lt;/pre&gt;</description>
    <dc:creator>Adriaan Moors</dc:creator>
    <dc:date>2012-05-22T16:56:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9702">
    <title>ScalaReference building</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9702</link>
    <description>&lt;pre&gt;I think Latex and myself do not get along.  I'm trying to build the
ScalaReference (in the distribution build, not the original ant build) and
getting the following:

[error] kpathsea: Running mktexpk --mfmode / --bdpi 600 --mag 0+526/600
--dpi 526 ul9ro8r
[error] mktexpk: don't know how to create bitmap font for ul9ro8r.
[error] kpathsea: Appending font creation commands to missfont.log.
[info] [182] [183] (./ScalaReference.aux)
[info]
[info] LaTeX Warning: There were undefined references.
[info]
[info]  ) )
[info] (see the transcript file for additional information)
[info] !pdfTeX error: pdflatex (file ul9ro8r): Font ul9ro8r at 526 not found
[info]  ==&amp;gt; Fatal error occurred, no output PDF file produced!
[error] Latexmk: Missing input file: 'ScalaReference.tpt' from line
[error]   'Package thumbpdf Warning: Thumbnail data file
`ScalaReference.tpt' not found.'
[error] Latexmk: Reference `volatile-types' on page 137 undefined
[error] Latexmk: Reference `volatile-types' on page 137 undefined
[error] Latexmk: F&lt;/pre&gt;</description>
    <dc:creator>Josh Suereth</dc:creator>
    <dc:date>2012-05-22T13:33:14</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9682">
    <title>Max Overload</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9682</link>
    <description>&lt;pre&gt;In order to be able to allow DynamicProxy to accept explicit type 
parameters, I found that I needed to be able to override the *Dynamic 
methods on their type parameters. The so-called "overload hack" (i.e. 
having different-length implicit parameter lists that are always satisfied) 
allows this for cases of 1+ type parameter. However, this does not allow 
for a version with a zero-length type parameter list to coexist with the 
rest. More precisely, though you can define such a method, you cannot call 
it (or at least not with the regular syntax).

Code:
"""
object O {
def foo(x: Int) = x
def foo[A: TypeTag](x: Int) = x + 1
def foo[A: TypeTag, B: TypeTag](x: Int) = x + 2
}

object P {
def bar {
println(O.foo[Int, String](3)) // works
println(O.foo[Int](2)) // works
println(O.foo(1)) // error: ambiguous

}
}
"""

This happens because the typer is willing to let O.foo(1) become 
O.foo[Nothing](1) or O.foo[Nothing, Nothing](1). Furthermore, it does not 
prefer the version that the user actually wrote over the&lt;/pre&gt;</description>
    <dc:creator>Chris Hodapp</dc:creator>
    <dc:date>2012-05-22T08:34:40</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9672">
    <title>on a walkabout with src/{compiler, library}</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9672</link>
    <description>&lt;pre&gt;All -- on the off chance anyone has noticed that I've been relatively
scarce lately, and on the higher chance someone will notice eventually, I
wanted to let everyone know that I am attempting a more ambitious code
overhaul than is possible for me to undertake within master.  I don't know
whether it will work out, but my goal is to explore providing a more robust
and performant foundation for some future version of scala.

Many thanks to Typesafe for making it possible.  I'll have something to
look at after 2.10 is out.
&lt;/pre&gt;</description>
    <dc:creator>Paul Phillips</dc:creator>
    <dc:date>2012-05-21T22:47:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9662">
    <title>isInstanceOf and abstract types</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9662</link>
    <description>&lt;pre&gt;Can the situation be improved when we have tags for abstract types?

&lt;/pre&gt;</description>
    <dc:creator>Eugene Burmako</dc:creator>
    <dc:date>2012-05-21T21:14:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9623">
    <title>Mailing list reminder: Scala-internals</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9623</link>
    <description>&lt;pre&gt;Welcome to the "Scala-internals" mailing list.

This automatic reminder is sent once a month to the list,
to keep subscribers up-to-date with the mailing list services,
and to help keeping the list on topic.

-------------------------------------------------------------------

The "Scala-internals" mailing list:

This is the mailing list that developers of the Scala
compiler and libraries use to discuss the core internal
design and the implementation of the Scala system.

This list is normally only used by developers who
commit code to the Scala code base; it is open to the
general public in order to make the development process
more transparent.

Please only create new threads if you commit to the
Scala code base, and you need to discuss the internals
of the Scala system.

General programming questions and bug reports should be
addressed to "scala-user" instead. For all general
questions and other discussions, please use the
"scala-language" mailing list instead.

-------------------------------------------&lt;/pre&gt;</description>
    <dc:creator>Scala Mailing Lists</dc:creator>
    <dc:date>2012-05-21T13:32:02</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.comp.lang.scala.internals/9597">
    <title>JIRA is unavailable</title>
    <link>http://comments.gmane.org/gmane.comp.lang.scala.internals/9597</link>
    <description>&lt;pre&gt;
I cannot access this URL: https://issues.scala-lang.org/ - don't know whether this is planned or known already...
Chris       &lt;/pre&gt;</description>
    <dc:creator>Chris Marshall</dc:creator>
    <dc:date>2012-05-21T10:03:04</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.comp.lang.scala.internals">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.comp.lang.scala.internals</link>
  </textinput>
</rdf:RDF>

