Custom Search
|
Date: September 28, 2005
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
In-reply-to:
<1127729264.4337c870581dc@xxxxxxxxxxxxxxx>
References:
<20050925005550.GA11142@xxxxxxxxxxxxxxxx> <20050925091520.GG30823@xxxxxxxxxxxxxxxx> <1127729264.4337c870581dc@xxxxxxxxxxxxxxx>
On Mon, Sep 26, 2005 at 12:07:44PM +0200, burak.emir@xxxxxxx wrote: > > - Scala doesn't currently work with Java 1.5. > > > What do you mean? I know compiling the compiler does not work, but most > programs > will run... Sorry, I'm probably misremembering. It's been some time sice I looked into this. > but since *that* compiler is being scrapped anyway, nobody bothered. How's nsc coming along, by the way? -- Jamie Webb
Date: September 27, 2005
From: Gilles Dubochet <gilles.dubochet@xxxxxxx>
References:
<20050925023123.GA14169@xxxxxxxxxxxxxxxx>
What development environment are you using for Scala? I use
Eclipse for Java development, and I would like to embed the
Scala interpreter in my project. Is there some way for me to
build Scala in Eclipse?
If you want to build the current Scala tools from the CVS in Eclipse, then the answer is “no, not yet”.
Building Scala is a complex process that only the very obscure Scala make file can do and nobody in the Scala team ever did that from within an IDE. We all compile from the console using make, and edit code in emacs or other editors.
However, the new Scala compiler (to be released soon) will come with an Ant script to compile it (much friendlier with IDEs than make), and the development of the Scala Eclipse plugin should restart soon.
Cheers, Gilles.
Date: September 27, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<1127826204.557.9.camel@xxxxxxxxxxxxxxx>
References:
<43393DA7.1040503@xxxxxxxx> <1127826204.557.9.camel@xxxxxxxxxxxxxxx>
hi nikolay,
i admit i was sloppy on this one and didnt check in its
entirety. i was supposing that class files without
$ or without $class ALWAYS contain only an interface
and that the real implementation is within the $ or $class
files.
thanks for pointing out.
ciao robertj
> That's not entirely correct. The aforementioned Scala object is
> translated into two JVM classes - the other being App
>
> public final class App extends java.lang.Object{
> public static scala.runtime.types.ScalaClassType getScalaType();
> public static scala.runtime.types.ClassType getScalaType();
> public static int $tag();
> public static final void main(java.lang.String[]);
> }
>
> All public methods of the App object are public static static members of
> the App class. From languages other than Java one should use the
> provided static members.
>>problem with this approach again is that the semantics
>>of scala objects are not preserved when i call this from
>>java. instead of having a singleton i can create as many
>>App objects as i like. wouldnt it be better to generate something
>>like this instead?
>>
>>public final class App$ extends java.lang.Object
>>implements scala.ScalaObject
>>{
>> public static final App$ MODULE$;
>> public final void main(java.lang.String[]);
>> public int $tag();
>> public scala.runtime.types.ScalaClassType getScalaType();
>> private App$();
>> public App$ getInstance();
>> public scala.runtime.types.ClassType getScalaType();
>> public static {};
>>}
>
>
> Since you are not supposed to access App$ this is not a major concern,
> although it might happen by accident. The best solution would be to hide
> the App$ class by, say, making it package-private. I'm not sure if that
> works if you don't put App in a package, though. On .NET this is much
> easier because App$ can be privately nested within App or assigned
> assembly-only visibility.
>
> Nikolay
>
Date: September 27, 2005
From: Nikolay Mihaylov <nikolay.mihaylov@xxxxxxx>
In-reply-to:
<43393DA7.1040503@xxxxxxxx>
References:
<43393DA7.1040503@xxxxxxxx>
Hi Robert
On Tue, 2005-09-27 at 14:40 +0200, robert kuzelj wrote:
> hi,
>
> i am having this object definition in scala
>
> object App
> {
> def main(args: Array[String]):Unit =
> {
> System.out.println("TEST");
> }
> }
>
>
> which is transformed into this jvm class-file
>
> public final class App$ extends java.lang.Object
> implements scala.ScalaObject
> {
> public static final App$ MODULE$;
> public final void main(java.lang.String[]);
> public int $tag();
> public scala.runtime.types.ScalaClassType getScalaType();
> public App$();
> public scala.runtime.types.ClassType getScalaType();
> public static {};
> }
That's not entirely correct. The aforementioned Scala object is
translated into two JVM classes - the other being App
public final class App extends java.lang.Object{
public static scala.runtime.types.ScalaClassType getScalaType();
public static scala.runtime.types.ClassType getScalaType();
public static int $tag();
public static final void main(java.lang.String[]);
}
All public methods of the App object are public static static members of
the App class. From languages other than Java one should use the
provided static members.
> problem with this approach again is that the semantics
> of scala objects are not preserved when i call this from
> java. instead of having a singleton i can create as many
> App objects as i like. wouldnt it be better to generate something
> like this instead?
>
> public final class App$ extends java.lang.Object
> implements scala.ScalaObject
> {
> public static final App$ MODULE$;
> public final void main(java.lang.String[]);
> public int $tag();
> public scala.runtime.types.ScalaClassType getScalaType();
> private App$();
> public App$ getInstance();
> public scala.runtime.types.ClassType getScalaType();
> public static {};
> }
Since you are not supposed to access App$ this is not a major concern,
although it might happen by accident. The best solution would be to hide
the App$ class by, say, making it package-private. I'm not sure if that
works if you don't put App in a package, though. On .NET this is much
easier because App$ can be privately nested within App or assigned
assembly-only visibility.
Nikolay
Date: September 27, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
hi,
i am having this object definition in scala
object App
{
def main(args: Array[String]):Unit =
{
System.out.println("TEST");
}
}
which is transformed into this jvm class-file
public final class App$ extends java.lang.Object
implements scala.ScalaObject
{
public static final App$ MODULE$;
public final void main(java.lang.String[]);
public int $tag();
public scala.runtime.types.ScalaClassType getScalaType();
public App$();
public scala.runtime.types.ClassType getScalaType();
public static {};
}
problem with this approach again is that the semantics
of scala objects are not preserved when i call this from
java. instead of having a singleton i can create as many
App objects as i like. wouldnt it be better to generate something
like this instead?
public final class App$ extends java.lang.Object
implements scala.ScalaObject
{
public static final App$ MODULE$;
public final void main(java.lang.String[]);
public int $tag();
public scala.runtime.types.ScalaClassType getScalaType();
private App$();
public App$ getInstance();
public scala.runtime.types.ClassType getScalaType();
public static {};
}
ciao robertj
Date: September 27, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<20050925023123.GA14169@xxxxxxxxxxxxxxxx>
References:
<20050925023123.GA14169@xxxxxxxxxxxxxxxx>
hi alan, i am using intellij (and sometimes eclipse) i have attached my syntax file for intellij. ciao robertj
<?xml version="1.0" encoding="UTF-8"?>
<filetype binary="false" description="scala" name="scala">
<highlighting>
<options>
<option name="LINE_COMMENT" value="//" />
<option name="COMMENT_START" value="/*" />
<option name="COMMENT_END" value="*/" />
<option name="HEX_PREFIX" value="" />
<option name="NUM_POSTFIXES" value="" />
<option name="HAS_BRACES" value="true" />
<option name="HAS_BRACKETS" value="true" />
<option name="HAS_PARENS" value="true" />
</options>
<keywords ignore_case="false">
<keyword name="abstract" />
<keyword name="case" />
<keyword name="catch" />
<keyword name="class" />
<keyword name="def" />
<keyword name="do" />
<keyword name="else" />
<keyword name="extends" />
<keyword name="false" />
<keyword name="final" />
<keyword name="finally" />
<keyword name="for" />
<keyword name="if" />
<keyword name="implicit" />
<keyword name="import" />
<keyword name="match" />
<keyword name="new" />
<keyword name="null" />
<keyword name="object" />
<keyword name="override" />
<keyword name="package" />
<keyword name="private" />
<keyword name="protected" />
<keyword name="return" />
<keyword name="sealed" />
<keyword name="super" />
<keyword name="this" />
<keyword name="throw" />
<keyword name="trait" />
<keyword name="true" />
<keyword name="try" />
<keyword name="type" />
<keyword name="val" />
<keyword name="var" />
<keyword name="while" />
<keyword name="with" />
<keyword name="yield" />
</keywords>
<keywords2>
<keyword name="Boolean" />
<keyword name="Byte" />
<keyword name="Char" />
<keyword name="Character" />
<keyword name="Double" />
<keyword name="Float" />
<keyword name="Int" />
<keyword name="Integer" />
<keyword name="Long" />
<keyword name="Short" />
<keyword name="Unit" />
<keyword name="boolean" />
<keyword name="byte" />
<keyword name="char" />
<keyword name="double" />
<keyword name="float" />
<keyword name="int" />
<keyword name="long" />
<keyword name="short" />
<keyword name="unit" />
</keywords2>
<keywords3>
<keyword name="Any" />
<keyword name="Array" />
<keyword name="Enumeration" />
<keyword name="Function" />
<keyword name="List" />
<keyword name="Option" />
<keyword name="PartialFunction" />
<keyword name="Ref" />
<keyword name="Some" />
<keyword name="Stream" />
<keyword name="String" />
<keyword name="Symbol" />
</keywords3>
<keywords4>
<keyword name="Iterable" />
<keyword name="Nil" />
<keyword name="None" />
<keyword name="Predef" />
</keywords4>
</highlighting>
</filetype>
Date: September 27, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<dh8s4h$p07$1@xxxxxxxxxxxxx>
References:
<43326C1E.3040203@xxxxxxxx> <dh8s4h$p07$1@xxxxxxxxxxxxx>
hi,
think the info below would be ideally put into
an wiki. anybody of the scala gurus any opinion
on that?
ciao robertj
>> it seems that scala has a big problem if package names
>> contain "scala" within.
>>
>> <code>
>> package org.pragmatico.scala.scunit;
>>
>> import java.text.DecimalFormat;
>> import scala.collection.mutable.ArrayBuffer;
>> </code>
>
>
> Just in case you are still looking for a way around this problem:
>
> <code>
> import java.text.DecimalFormat;
> import scala.collection.mutable.ArrayBuffer;
>
> package org.pragmatico.scala.scunit {
> ...
> }
> </code>
>
> That way the imports will be resolved outside the package, starting at
> the root.
>
> Cheers,
> Gilles.
>
>
Date: September 27, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<dh8s4h$p07$1@xxxxxxxxxxxxx>
References:
<43326C1E.3040203@xxxxxxxx> <dh8s4h$p07$1@xxxxxxxxxxxxx>
hi gilles,
> Just in case you are still looking for a way around this problem:
<hmm> my solution was to rename my package :-)
but this is of course far nicer.
>
> <code>
> import java.text.DecimalFormat;
> import scala.collection.mutable.ArrayBuffer;
>
> package org.pragmatico.scala.scunit {
> ...
> }
> </code>
>
> That way the imports will be resolved outside the package, starting at
> the root.
ciao robertj
Date: September 26, 2005
From: Gilles Dubochet <gilles.dubochet@xxxxxxx>
References:
<43326C1E.3040203@xxxxxxxx>
it seems that scala has a big problem if package names contain "scala" within. <code> package org.pragmatico.scala.scunit; import java.text.DecimalFormat; import scala.collection.mutable.ArrayBuffer; </code>
Just in case you are still looking for a way around this problem:
<code>
import java.text.DecimalFormat;
import scala.collection.mutable.ArrayBuffer;
package org.pragmatico.scala.scunit {
...
}
</code>
That way the imports will be resolved outside the package, starting at
the root.
Cheers, Gilles.
Date: September 26, 2005
From: burak.emir@xxxxxxx
In-reply-to:
<20050925091520.GG30823@xxxxxxxxxxxxxxxx>
References:
<20050925005550.GA11142@xxxxxxxxxxxxxxxx> <20050925091520.GG30823@xxxxxxxxxxxxxxxx>
Quoting Jamie Webb <j@xxxxxxxxxxxxxxx>: > On Sat, Sep 24, 2005 at 08:55:50PM -0400, Alan Gutierrez wrote: > > Has anyone had any success in embedding Scala in their Java > > application? > > Compiled Scala code is pretty much indistinguishable from Java code as > far as the JVM is concerned, so this is pretty easy. Things to watch > out for: > > - Scala doesn't currently work with Java 1.5. > What do you mean? I know compiling the compiler does not work, but most programs will run... The bugtracking system is running on Java1.5 Tomcat 5.something, that's why I am sure it's possible. Compiling the compiler fails because of yet another instance of that overloading-related bug. We have some stuff in our compiler that depends on Java's library, and the latter has a method overloaded in 1.5 that wasn't before. Easy fix is to remove/rewrite the code that has that dependency. Really easy, but since *that* compiler is being scrapped anyway, nobody bothered. cheers, Burak
Date: September 25, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<20050925093340.GA27373@xxxxxxxxxxxxxxxx>
References:
<20050925005550.GA11142@xxxxxxxxxxxxxxxx> <20050925091520.GG30823@xxxxxxxxxxxxxxxx> <20050925093340.GA27373@xxxxxxxxxxxxxxxx>
hi alan, > I was talking about embedding the Scala interpreter. Creating a > script context containing Java object and executing a Scala > program through the interpreter. i am not sure if that is such a good idea. - the scala interpreter is not feature complete in regards or scala features - scala as a language is a completely different beast compared to "scripting" languages. i wouldnt necessary force it upon a "normal user audiennce". why not go for groovy, jpython, or jruby ...? ciao robertj
Date: September 25, 2005
From: Alan Gutierrez <alan-scala@xxxxxxxxx>
In-reply-to:
<20050925091520.GG30823@xxxxxxxxxxxxxxxx>
References:
<20050925005550.GA11142@xxxxxxxxxxxxxxxx> <20050925091520.GG30823@xxxxxxxxxxxxxxxx>
* Jamie Webb <j@xxxxxxxxxxxxxxx> [2005-09-25 05:15]:
> On Sat, Sep 24, 2005 at 08:55:50PM -0400, Alan Gutierrez wrote:
> > Has anyone had any success in embedding Scala in their Java
> > application?
>
> Compiled Scala code is pretty much indistinguishable from Java code as
> far as the JVM is concerned, so this is pretty easy. Things to watch
> out for:
>
> - Scala doesn't currently work with Java 1.5.
>
> - You need scala.jar on your bootclasspath (the classpath won't do).
>
> - Avoid Scala-specific features in the API, i.e. it's usually easiest
> to write an interface in Java and then implement it in Scala rather
> than the other way around.
>
> - Be aware of Scala's name mangling. Most notably, if you want to
> instantiate a Scala class from Java, it will be called MyClass$class
> rather than just MyClass.
>
> I believe Burak has an example of a Scala servlet which runs in Tomcat
> on his site, which might be instructive.
I was talking about embedding the Scala interpreter. Creating a
script context containing Java object and executing a Scala
program through the interpreter.
--
Alan Gutierrez - alan@xxxxxxxxx
- http://engrm.com/blogometer/index.html
- http://engrm.com/blogometer/rss.2.0.xml
Date: September 25, 2005
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
In-reply-to:
<20050925005550.GA11142@xxxxxxxxxxxxxxxx>
References:
<20050925005550.GA11142@xxxxxxxxxxxxxxxx>
On Sat, Sep 24, 2005 at 08:55:50PM -0400, Alan Gutierrez wrote: > Has anyone had any success in embedding Scala in their Java > application? Compiled Scala code is pretty much indistinguishable from Java code as far as the JVM is concerned, so this is pretty easy. Things to watch out for: - Scala doesn't currently work with Java 1.5. - You need scala.jar on your bootclasspath (the classpath won't do). - Avoid Scala-specific features in the API, i.e. it's usually easiest to write an interface in Java and then implement it in Scala rather than the other way around. - Be aware of Scala's name mangling. Most notably, if you want to instantiate a Scala class from Java, it will be called MyClass$class rather than just MyClass. I believe Burak has an example of a Scala servlet which runs in Tomcat on his site, which might be instructive. -- Jamie Webb
Date: September 25, 2005
From: Alan Gutierrez <alan-scala@xxxxxxxxx>
What development environment are you using for Scala? I use
Eclipse for Java development, and I would like to embed the
Scala interpreter in my project. Is there some way for me to
build Scala in Eclipse?
It seems to require a special compilation step with pico.
If someone already has a .classpath and .project, please send
them my way.
--
Alan Gutierrez - alan@xxxxxxxxx
- http://engrm.com/blogometer/index.html
- http://engrm.com/blogometer/rss.2.0.xml
Date: September 25, 2005
From: Alan Gutierrez <alan-scala@xxxxxxxxx>
Has anyone had any success in embedding Scala in their Java
application?
--
Alan Gutierrez - alan@xxxxxxxxx
- http://engrm.com/blogometer/index.html
- http://engrm.com/blogometer/rss.2.0.xml
Date: September 23, 2005
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
In-reply-to:
<4334226C.7080102@xxxxxxx>
References:
<4332CF85.9020003@xxxxxxxx> <20050922161955.GA30823@xxxxxxxxxxxxxxxx> <4332EBCE.2060306@xxxxxxxx> <1127416258.433301c2ea074@xxxxxxxxxxxxxxx> <43330CC6.6070603@xxxxxxxx> <20050922203120.GB30823@xxxxxxxxxxxxxxxx> <4334226C.7080102@xxxxxxx>
On Fri, Sep 23, 2005 at 05:42:36PM +0200, Martin Odersky wrote: > The next version of Scala will require mixins to be labelled explicitly > as traits. This means that if you write standard classes, they will be > compiled much more the way you see them in Java. For traits/mixins we > need to apply essentially the same techniques as for all classes now. > But this is less of a problem for intercallability because traits do not > exist in Java. How will this affect the current distinction between traits and regular classes? i.e. will it still be possible to have stateful mixins? -- Jamie Webb
Date: September 23, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<4334226C.7080102@xxxxxxx>
References:
<4332CF85.9020003@xxxxxxxx> <20050922161955.GA30823@xxxxxxxxxxxxxxxx> <4332EBCE.2060306@xxxxxxxx> <1127416258.433301c2ea074@xxxxxxxxxxxxxxx> <43330CC6.6070603@xxxxxxxx> <20050922203120.GB30823@xxxxxxxxxxxxxxxx> <4334226C.7080102@xxxxxxx>
hi martin, > Jamie is correct. In current Scala every class can be used as a mixin. > When that happens, private variables can name-clash with other private > variables from other mixins, that's why they need to be name-mangled. > What's more, because every class can be used as a mixin, we need to > generate an interface for it, and the class itself is then renamed with > a $class suffix. > > The next version of Scala will require mixins to be labelled explicitly > as traits. This means that if you write standard classes, they will be > compiled much more the way you see them in Java. For traits/mixins we > need to apply essentially the same techniques as for all classes now. > But this is less of a problem for intercallability because traits do not > exist in Java. if we can get away with that X_$eq stuff i will be happy :-) then the only thing that is really of importance is: when? <bg> ciao robertj
Date: September 23, 2005
From: Martin Odersky <martin.odersky@xxxxxxx>
In-reply-to:
<20050922203120.GB30823@xxxxxxxxxxxxxxxx>
References:
<4332CF85.9020003@xxxxxxxx> <20050922161955.GA30823@xxxxxxxxxxxxxxxx> <4332EBCE.2060306@xxxxxxxx> <1127416258.433301c2ea074@xxxxxxxxxxxxxxx> <43330CC6.6070603@xxxxxxxx> <20050922203120.GB30823@xxxxxxxxxxxxxxxx>
Jamie Webb wrote:
On Thu, Sep 22, 2005 at 09:57:58PM +0200, robert kuzelj wrote:
...
Jamie is correct. In current Scala every class can be used as a mixin. When that happens, private variables can name-clash with other private variables from other mixins, that's why they need to be name-mangled. What's more, because every class can be used as a mixin, we need to generate an interface for it, and the class itself is then renamed with a $class suffix.what the heck is happening here? - why is private method mangled into public abstract void org$pragmatico$libscala$meta$A$foo() ?I'm guessing it's because multiple mixins can have the same private members, so they need to be renamed to avoid conflicts.- why isnt the private (java) modifier used?Dunno.- why isnt bar marked as "protected"?Scala allows protected access in more cases than Java, due to mixins and self-types.of course it might be that both "private" and "protected" are slightly different in scala than their counterparts in java. still it might be worth exploring that compiled articfact is as close to the semantics of the java platform as possible.These issues seem pretty minor though. They have no impact on correct Java code. And they are probably unavoidable.and then why is A defined as an interface with an accompanied class named "A$class"? there is no trait here just a pure class that does not even extend another class.So A can be used as a mixin. In that case, the resulting class implements the A interface and the code from A$class is pysically copied over. Not much that can be done about this one. Hopefully it's pretty rare to need to construct Scala objects in Java.
The next version of Scala will require mixins to be labelled explicitly as traits. This means that if you write standard classes, they will be compiled much more the way you see them in Java. For traits/mixins we need to apply essentially the same techniques as for all classes now. But this is less of a problem for intercallability because traits do not exist in Java.
Cheers -- Martin
-- Jamie Webb
Date: September 23, 2005
From: Martin Odersky <martin.odersky@xxxxxxx>
In-reply-to:
<20050922124505.GB1580@xxxxxxxxxxxxxxxx>
References:
<43326C1E.3040203@xxxxxxxx> <43328FDD.5090909@xxxxxxx> <20050922124505.GB1580@xxxxxxxxxxxxxxxx>
Jamie Webb wrote:
In fact, it avoids complexity for the spec, because package names are treated just as all other names, i.e. inner bindings take precedence over outer ones. If we would switch to absolute names, we would have to add special clauses to the spec and special treatment of packages in the compiler. But I concede that it is confusing, in particular so because Java behaves differently. I'll think about what we can do.This seems rather problematic. It's not just 'scala' and 'java' that are going to be affected, it's any name that might be used higher up; all the internet top-level domains to start with. And having got oneself into this predicament, is there a way out of it? Say I have a well-established com.sygneca.net package, and one day I decide to import net.n3.nanoxml into it, can it be done? Does this feature really warrant the complexity it adds?
-- Martin
Date: September 22, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<20050922203120.GB30823@xxxxxxxxxxxxxxxx>
References:
<4332CF85.9020003@xxxxxxxx> <20050922161955.GA30823@xxxxxxxxxxxxxxxx> <4332EBCE.2060306@xxxxxxxx> <1127416258.433301c2ea074@xxxxxxxxxxxxxxx> <43330CC6.6070603@xxxxxxxx> <20050922203120.GB30823@xxxxxxxxxxxxxxxx>
hi jamie, > And I think this is the direction Scala should take too, i.e. one should > be able to write the Scala accessor syntax, and it should be compiled > into the Java conventions. Of course, that could lead to confusion if > e.g. one defined both 'var foo' and 'def getFoo' in a class, but > that's easy to warn about and doesn't seem too troublesome. warning should do. >> public abstract void org$pragmatico$libscala$meta$A$foo() ? > I'm guessing it's because multiple mixins can have the same private > members, so they need to be renamed to avoid conflicts. problem with that mangled name is that any java programmer that gets this into his IDE and hits ctrl+space to open his intelli-sense dropdown will be completely shocked if he sees this. the reasoning will be something like this: i have never seen this, it has funny characters in it. its broken! if the name must be mangled maybe one must carefully think how it can be mangled without raising to much concern. > These issues seem pretty minor though. They have no impact on correct > Java code. that is not the issue. according to that i could even go and make even more mangled names. the issue is a social one: how much do i want to expose to the unattended that a certain code has NOT been written in java. and telling people that something has not been written in java does scare people. developers and managers alike. >>And they are probably unavoidable. i dont know but i hope not. > So A can be used as a mixin. In that case, the resulting class > implements the A interface and the code from A$class is pysically > copied over. Not much that can be done about this one. maybe that is so. but than again maybe a Factory should be created for every such interface. so that one would have a AFactory instead a A$class. no difference but every java programmer would immediatly inderstand what to do. >Hopefully it's pretty rare to need to construct Scala objects in Java. not for me. just right now i will develop a module that does expose a few class (3-5) as entrance points into that module. and i will do this for quite some modules if that works well. ciao robertj
Date: September 22, 2005
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
In-reply-to:
<43330CC6.6070603@xxxxxxxx>
References:
<4332CF85.9020003@xxxxxxxx> <20050922161955.GA30823@xxxxxxxxxxxxxxxx> <4332EBCE.2060306@xxxxxxxx> <1127416258.433301c2ea074@xxxxxxxxxxxxxxx> <43330CC6.6070603@xxxxxxxx>
On Thu, Sep 22, 2005 at 09:57:58PM +0200, robert kuzelj wrote: > > Especially, since it is common practice with the JavaBeans (and countless > > GUI > > and web service frameworks), and EJBs standards. > or for example jython/jruby. both of which i use and that know to > shortcut instance.setX(0) to instance.x = 0 And I think this is the direction Scala should take too, i.e. one should be able to write the Scala accessor syntax, and it should be compiled into the Java conventions. Of course, that could lead to confusion if e.g. one defined both 'var foo' and 'def getFoo' in a class, but that's easy to warn about and doesn't seem too troublesome. > > Maybe some more reaction from the list would show if the two of us are the > > only > > ones that feel the Scala language should be more forthcoming in these > > seemingly > > little details. I'd certainly like there to be some documentation which describes how Scala maps to Java. Unfortunately, this can't be just considered an implementation detail. > what the heck is happening here? > - why is private method mangled into > public abstract void org$pragmatico$libscala$meta$A$foo() ? I'm guessing it's because multiple mixins can have the same private members, so they need to be renamed to avoid conflicts. > - why isnt the private (java) modifier used? Dunno. > - why isnt bar marked as "protected"? Scala allows protected access in more cases than Java, due to mixins and self-types. > of course it might be that both "private" and "protected" are slightly > different in scala than their counterparts in java. still it might be > worth exploring that compiled articfact is as close to the semantics > of the java platform as possible. These issues seem pretty minor though. They have no impact on correct Java code. And they are probably unavoidable. > and then > why is A defined as an interface with an accompanied > class named "A$class"? there is no trait here just a pure class that > does not even extend another class. So A can be used as a mixin. In that case, the resulting class implements the A interface and the code from A$class is pysically copied over. Not much that can be done about this one. Hopefully it's pretty rare to need to construct Scala objects in Java. -- Jamie Webb
Date: September 22, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<91a2ba3e050922123042341cd6@xxxxxxxxxxxxxx>
References:
<4332CF85.9020003@xxxxxxxx> <20050922161955.GA30823@xxxxxxxxxxxxxxxx> <4332EBCE.2060306@xxxxxxxx> <1127416258.433301c2ea074@xxxxxxxxxxxxxxx> <91a2ba3e050922123042341cd6@xxxxxxxxxxxxxx>
> In the cases (apparently such as getters/setters) where there can > easily be commonality, I think Scala would suffer greatly in the long > run if it didn't take advantage of it. just to explain a bit more. from the feature set that scala exposes - blocks - type inteference - generics - abstract types and so on and despite the lack of decent tools for refactoring and large scale development etc. choosing scala as a programming language could be a no-brainer. but it is not and the reason for that is not so much a technical one but a social one. forcing a new way onto developers is usally no good strategy. a more evolutionary strategy will be more successful. give them the time to get used to it to adapt to the new ways by using old tools and concepts as long as possible. ciao robertj
Date: September 22, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<91a2ba3e050922123042341cd6@xxxxxxxxxxxxxx>
References:
<4332CF85.9020003@xxxxxxxx> <20050922161955.GA30823@xxxxxxxxxxxxxxxx> <4332EBCE.2060306@xxxxxxxx> <1127416258.433301c2ea074@xxxxxxxxxxxxxxx> <91a2ba3e050922123042341cd6@xxxxxxxxxxxxxx>
hi raoul, > Do you want Scala to be easily callable from Java? absolutely. fact of live for the foreseeable future will be that there will be still a lot of java code to interact with in both ways and a lot of other (dynamic) languages that expect a certain (byte)code structure. >There will probably be a time when that is a pain in the ass to implement. certainly >how much should Scala contort itself for Java? it should go for obvious things that will invoke a knee-jerk reaction in every java-programmer. getters/setters, access modifiers and classes and class names are top on the list imo. there are of course as abvious other things that are not even worth thinking about. making calling blocks from java easier is absolutely useless. there are no blocks in java so dont spend time on it. >And what about .Net? Can there be commonality? who cares about .net :-) no of course, if i would be using .net i would simple expect that certain conventions (implicit or explict) of that platform are adhered to too. no question about that! > In the cases (apparently such as getters/setters) where there can > easily be commonality, I think Scala would suffer greatly in the long > run if it didn't take advantage of it. it suffers just right now if you ask me. ciao robertj
Date: September 22, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<1127416258.433301c2ea074@xxxxxxxxxxxxxxx>
References:
<4332CF85.9020003@xxxxxxxx> <20050922161955.GA30823@xxxxxxxxxxxxxxxx> <4332EBCE.2060306@xxxxxxxx> <1127416258.433301c2ea074@xxxxxxxxxxxxxxx>
hi burak,
> Especially, since it is common practice with the JavaBeans (and countless GUI
> and web service frameworks), and EJBs standards.
or for example jython/jruby. both of which i use and that know to
shortcut instance.setX(0) to instance.x = 0
> Also, CSharp's properties are compiled to get_X and set_X so it should be able
> to use them from other IL languages.
>
> Maybe some more reaction from the list would show if the two of us are the
> only
> ones that feel the Scala language should be more forthcoming in these
> seemingly
> little details.
the bad thing is that it does not stop there. for example this class
class A
{
var a : Int = 0;
def getA: Int = 0;
def setA(_a: Int)={a = _a;}
private def foo: Unit = {}
protected def bar: Unit = {}
}
is compiled as this
public interface org.pragmatico.libscala.meta.A extends scala.ScalaObject{
public abstract int a();
public abstract void a_$eq(int);
public abstract int getA();
public abstract void setA(int);
public abstract void org$pragmatico$libscala$meta$A$foo();
public abstract void bar();
public abstract int $tag();
public abstract scala.runtime.types.ScalaClassType getScalaType();
}
what the heck is happening here?
- why is private method mangled into
public abstract void org$pragmatico$libscala$meta$A$foo() ?
- why isnt the private (java) modifier used?
- why isnt bar marked as "protected"?
of course it might be that both "private" and "protected" are slightly
different in scala than their counterparts in java. still it might be
worth exploring that compiled articfact is as close to the semantics
of the java platform as possible.
and then
why is A defined as an interface with an accompanied
class named "A$class"? there is no trait here just a pure class that
does not even extend another class.
ciao robertj
Date: September 22, 2005
From: Raoul Duke <raould@xxxxxxxxx>
In-reply-to:
<1127416258.433301c2ea074@xxxxxxxxxxxxxxx>
References:
<4332CF85.9020003@xxxxxxxx> <20050922161955.GA30823@xxxxxxxxxxxxxxxx> <4332EBCE.2060306@xxxxxxxx> <1127416258.433301c2ea074@xxxxxxxxxxxxxxx>
> Maybe some more reaction from the list would show if the two of us are the > only > ones that feel the Scala language should be more forthcoming in these > seemingly > little details. There are many things that make or break a new language in terms of popular success. I don't konw what the Scala project is shooting for, which would be significant in deciding what to do or not do. The small things are worthless w/out the large, and the large may be insufficient if the small quickly get in the way. Do you want Scala to be easily callable from Java? There will probably be a time when that is a pain in the ass to implement. How much should Scala contort itself for Java? And what about .Net? Can there be commonality? In the cases (apparently such as getters/setters) where there can easily be commonality, I think Scala would suffer greatly in the long run if it didn't take advantage of it. my $0.02, sincerely.
Date: September 22, 2005
From: burak.emir@xxxxxxx
In-reply-to:
<4332EBCE.2060306@xxxxxxxx>
References:
<4332CF85.9020003@xxxxxxxx> <20050922161955.GA30823@xxxxxxxxxxxxxxxx> <4332EBCE.2060306@xxxxxxxx>
Quoting robert kuzelj <robert.kuzelj@xxxxxxxx>:
> your proposal does generate the following (byte) code:
>
> public interface Test implements ScalaObject
> {
> int a();
> void a_$eq(int arg);
> }
>
> now if you can live happily in scala-land all of your time you must
> not care a bit. sadly i dont have that privilege.
> and belive me what concerns privileges when deciding tools & languages
> i am in a very fortunate position.
> but honestly i will have an extremly hard time to explain to my team
> why they must now use (sometimes) "aTestInstance.a_$eq(0);" when
> setting a value. just because i decided to use scala for one of our
> modules and that other (java) modules depend on.
>
+1
>From the Java point of view, it makes more sense to create setX and getX
>methods
instead of the X() and X_$eq.
Especially, since it is common practice with the JavaBeans (and countless GUI
and web service frameworks), and EJBs standards.
Also, CSharp's properties are compiled to get_X and set_X so it should be able
to use them from other IL languages.
Maybe some more reaction from the list would show if the two of us are the only
ones that feel the Scala language should be more forthcoming in these seemingly
little details.
cheers,
Burak
Date: September 22, 2005
From: Jon Pretty <jon.pretty@xxxxxxxxxxx>
In-reply-to:
<20050922124505.GB1580@xxxxxxxxxxxxxxxx>
References:
<43326C1E.3040203@xxxxxxxx> <43328FDD.5090909@xxxxxxx> <20050922124505.GB1580@xxxxxxxxxxxxxxxx>
Jamie Webb wrote:
>On Thu, Sep 22, 2005 at 01:05:01PM +0200, Martin Odersky wrote:
>
>
>
>This seems rather problematic. It's not just 'scala' and 'java' that
>are going to be affected, it's any name that might be used higher up;
>all the internet top-level domains to start with.
>
>And having got oneself into this predicament, is there a way out of
>it? Say I have a well-established com.sygneca.net package, and one day
>I decide to import net.n3.nanoxml into it, can it be done?
>
>Does this feature really warrant the complexity it adds?
>
>
Why not force users to explicitly specify if a package is being
referenced relatively? For example, by preceding relative package names
with a period, i.e.:
package com.sygneca.net;
import net.n3.nanoxml._; // this would import net.n3.nanoxml._,
which is almost certainly what you would want
import .client._; // would import everything in the package
com.sygneca.net.client
import .^.data._; // would import everything in the package
com.sygneca.data
import .^.^.google._; // would import everything in the package
com.google (though not recommended use)
import client._; // would import everything in the package
client
The exact syntax is something to be discussed, but it will save on
typing, and at least avoids the awkward situation described by Jamie above.
I think doing anything more complicated such as looking for packages in
more than one place (e.g. to make it easier to move packages) should be
fixed by refactoring in an IDE, not by the compiler.
Jon
--
Jon Pretty | Sygneca Ltd.
Date: September 22, 2005
From: Raoul Duke <raould@xxxxxxxxx>
Not that anybody asked me! But on the face of it, I'd really urge to just do the Java thing with imports. People who are moving things around for a massive code re-org can simply use grep and sed to fix things. I don't see that the relativeness buys much at all, and the ensuing confusion (and possible impossibilities per Jamie's note) is - as far as I can see so far - clearly not worth the price. Heck, wouldn't it make the scala compiler code smaller/easier/more robust, to boot? :-) $0.02, sincerely.
Date: September 22, 2005
From: Raoul Duke <raould@xxxxxxxxx>
In-reply-to:
<1127377371.16575.12.camel@xxxxxxxxxxxxxxxx>
References:
<91a2ba3e05091823452f116efb@xxxxxxxxxxxxxx> <91a2ba3e0509201453150821df@xxxxxxxxxxxxxx> <1127311620.2710.5.camel@xxxxxxxxxxxxxxxx> <91a2ba3e05092110474d56c8b8@xxxxxxxxxxxxxx> <1127377371.16575.12.camel@xxxxxxxxxxxxxxxx>
> You can also fool the scalac compiler by subclassing BlastLikerSAXParser > and overriding setContentHandler. This way, it will reference your class > in the generated bytecode. Interesting, thank you!
Date: September 22, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
hi, i just came accross §5.1.7 on attributes in the language specs. actually i am asking myself what to do with attributes - problem is that i dont see any use for them expect defining them on scala elements. but how do i use them? ciao robertj
Date: September 22, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<20050922161955.GA30823@xxxxxxxxxxxxxxxx>
References:
<4332CF85.9020003@xxxxxxxx> <20050922161955.GA30823@xxxxxxxxxxxxxxxx>
hi jamie,
> I don't know about the macro facilities (though IIRC they are likely to be
> similar to those in Dylan),
do you have a pointer where i can read about that?
>but no-op getters and setters are rarely necessary
> in Scala. Just use a var and be happy.
sure, i know. properties was only a simple example
which i just had at hand nevertheless there are examples
where macros would come in handy.
> The reason is that unlike in Java, you're not exposing the implementation by
> doing this, and you are free to add Scala-style getters and setters later
> without breaking anything. Try the following code:
>
> object Test
> {
> class A {
> var a : Int = 0;
> }
actually i dont have any issues with what you proposal from a conceptual
or syntax point of view. scala is just great in regards to this.
the reason why i wanted to have another way of defining properties is
that i wanted to circumvent something that i see as the biggest failure
of scala (that is the compiler).
your proposal does generate the following (byte) code:
public interface Test implements ScalaObject
{
int a();
void a_$eq(int arg);
}
now if you can live happily in scala-land all of your time you must
not care a bit. sadly i dont have that privilege.
and belive me what concerns privileges when deciding tools & languages
i am in a very fortunate position.
but honestly i will have an extremly hard time to explain to my team
why they must now use (sometimes) "aTestInstance.a_$eq(0);" when
setting a value. just because i decided to use scala for one of our
modules and that other (java) modules depend on.
ciao robertj
Date: September 22, 2005
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
In-reply-to:
<4332CF85.9020003@xxxxxxxx>
References:
<4332CF85.9020003@xxxxxxxx>
On Thu, Sep 22, 2005 at 05:36:37PM +0200, robert kuzelj wrote:
> is there any news on the plans on macro facilities?
>
> i would realy like to define my own property facilities.
I don't know about the macro facilities (though IIRC they are likely to be
similar to those in Dylan), but no-op getters and setters are rarely necessary
in Scala. Just use a var and be happy.
The reason is that unlike in Java, you're not exposing the implementation by
doing this, and you are free to add Scala-style getters and setters later
without breaking anything. Try the following code:
object Test
{
class A {
var a : Int = 0;
}
class B extends A {
override def a_=(x : Int) =
super.a = x - 1;
}
def main(argv : Array[String]) = {
val xs = List(new A, new B);
for(val x <- xs) {
x.a = 5;
Console.println(x.a);
}
}
}
(Note that if you want a read-only property, you need to use a def rather than
a val.)
-- Jamie Webb
Date: September 22, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<1127404801.4332d50162626@xxxxxxxxxxxxxxx>
References:
<4332CF85.9020003@xxxxxxxx> <1127404801.4332d50162626@xxxxxxxxxxxxxxx>
hi burak, > I must have missed any mail announcing a macro facility? Could you point me to > one (using gmane for instance)? Never heard of this before. well i wouldnt call it exactly "announcement" but here http://article.gmane.org/gmane.comp.lang.scala/1190 there is at least talk about macros and typebased reflection. thou i have no clue what "typebased" reflection means. but of course i was thinking, that this much more prominent on the agenda of yours. call it wishfull thinking: i feel the need for real good reflection and meta-programming support is far important than for example another DB-layer or even another ruby on rails clone. > Why not try m4, or the cpp for macro processing? because the fewer tools i need to do my build the fewer possibilities of error i have. ciao robertj
Date: September 22, 2005
From: burak.emir@xxxxxxx
In-reply-to:
<4332CF85.9020003@xxxxxxxx>
References:
<4332CF85.9020003@xxxxxxxx>
Hello Robert,
I must have missed any mail announcing a macro facility? Could you point me to
one (using gmane for instance)? Never heard of this before.
Why not try m4, or the cpp for macro processing?
cheers,
Burak
Quoting robert kuzelj <robert.kuzelj@xxxxxxxx>:
> hi,
>
> is there any news on the plans on macro facilities?
>
> i would realy like to define my own property facilities.
>
> i would like to define such a thing like this
>
> class Permission
> {
> @gsett name //that is for getter and setter return this
> }
>
> which expands to
>
> class Permission
> {
> private var name_ :String = null;
> def getName(): String = name_;
> def setName(_name: String): Permission = {name_ = _name;this}
> }
>
>
> will the macro facility be based on text substitution (C++ et al) or
> will it be more of a meta-level programming facility like for example
> in ruby and python?
>
> ciao robertj
>
Date: September 22, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
hi,
is there any news on the plans on macro facilities?
i would realy like to define my own property facilities.
i would like to define such a thing like this
class Permission
{
@gsett name //that is for getter and setter return this
}
which expands to
class Permission
{
private var name_ :String = null;
def getName(): String = name_;
def setName(_name: String): Permission = {name_ = _name;this}
}
will the macro facility be based on text substitution (C++ et al) or
will it be more of a meta-level programming facility like for example
in ruby and python?
ciao robertj
Date: September 22, 2005
From: Jamie Webb <j@xxxxxxxxxxxxxxx>
In-reply-to:
<43328FDD.5090909@xxxxxxx>
References:
<43326C1E.3040203@xxxxxxxx> <43328FDD.5090909@xxxxxxx>
On Thu, Sep 22, 2005 at 01:05:01PM +0200, Martin Odersky wrote: > It is according to the specs. Scala has relative package names. for > instance, in the program above, you could write > > import progamtico._; > > which would import everything in package org.pragmatico. The problem is > that your import statement > > import scala.collection.mutable.ArrayBuffer; > > then also looks in your package scala, not the global one which is > further outside, in the hierarchy. > > The advantage of this scheme is that package names need not be > absoluate, therefore thye can be shorter, and more easily adapated when > you move things from one package to another. But I agree it can be > confusing. Maybe we should try to give a warning in the case where you > have `scala' or `java' nested in your package name. This seems rather problematic. It's not just 'scala' and 'java' that are going to be affected, it's any name that might be used higher up; all the internet top-level domains to start with. And having got oneself into this predicament, is there a way out of it? Say I have a well-established com.sygneca.net package, and one day I decide to import net.n3.nanoxml into it, can it be done? Does this feature really warrant the complexity it adds? -- Jamie Webb
Date: September 22, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<43328FDD.5090909@xxxxxxx>
References:
<43326C1E.3040203@xxxxxxxx> <43328FDD.5090909@xxxxxxx>
hi martin, > It is according to the specs. Scala has relative package names. for > instance, in the program above, you could write > > import progamtico._; i see. i was only slightly aware of that feature. > which would import everything in package org.pragmatico. The problem is > that your import statement > > import scala.collection.mutable.ArrayBuffer; > > then also looks in your package scala, not the global one which is > further outside, in the hierarchy. > The advantage of this scheme is that package names need not be > absoluate, therefore thye can be shorter, and more easily adapated when > you move things from one package to another. i understand your point. thou i dont like it ;-) in the same way i dont like imports with a * in java. i find indirections when pointing to types a to big burden mentally. in python you could do something like this import org as o import o.pragmatico as p from p import * from o import * x = MyType() #where the heck comes MyType from. >But I agree it can be > confusing. Maybe we should try to give a warning in the case where you > have `scala' or `java' nested in your package name. why just a warning? why not making it plainly outlawed. usually using such package names is anyway not a good thing to do. and i was simply to lazy to go for a good packagename. ciao robertj
Date: September 22, 2005
From: Martin Odersky <martin.odersky@xxxxxxx>
In-reply-to:
<43326C1E.3040203@xxxxxxxx>
References:
<43326C1E.3040203@xxxxxxxx>
robert kuzelj wrote:
hi, it seems that scala has a big problem if package names contain "scala" within. <code> package org.pragmatico.scala.scunit; import java.text.DecimalFormat; import scala.collection.mutable.ArrayBuffer; </code> the above will yield the following error: compile.scala: [scalac] Compiling 4 source files to /mnt/sda2/data/payon/sandbox/target/build [scalac] /mnt/sda2/data/payon/sandbox/target/src/org/pragmatico/scala/scunit/scunit.scala:4: value collection is not a member of org.pragmatico.scala [scalac] import scala.collection.mutable.ArrayBuffer; [scalac] ^ i dont know if this is according to the specs...but it is very confusing. it took me about 2 hours before realising what the error is about.
It is according to the specs. Scala has relative package names. for instance, in the program above, you could write
import progamtico._;which would import everything in package org.pragmatico. The problem is that your import statement
import scala.collection.mutable.ArrayBuffer;then also looks in your package scala, not the global one which is further outside, in the hierarchy.
The advantage of this scheme is that package names need not be absoluate, therefore thye can be shorter, and more easily adapated when you move things from one package to another. But I agree it can be confusing. Maybe we should try to give a warning in the case where you have `scala' or `java' nested in your package name.
-- Martin
Date: September 22, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
hi, it seems that scala has a big problem if package names contain "scala" within. <code> package org.pragmatico.scala.scunit; import java.text.DecimalFormat; import scala.collection.mutable.ArrayBuffer; </code> the above will yield the following error: compile.scala: [scalac] Compiling 4 source files to /mnt/sda2/data/payon/sandbox/target/build [scalac] /mnt/sda2/data/payon/sandbox/target/src/org/pragmatico/scala/scunit/scunit.scala:4: value collection is not a member of org.pragmatico.scala [scalac] import scala.collection.mutable.ArrayBuffer; [scalac] ^ i dont know if this is according to the specs...but it is very confusing. it took me about 2 hours before realising what the error is about. ciao robertj
Date: September 22, 2005
From: Iulian Dragos <iulian.dragos@xxxxxxx>
In-reply-to:
<91a2ba3e05092110474d56c8b8@xxxxxxxxxxxxxx>
References:
<91a2ba3e05091823452f116efb@xxxxxxxxxxxxxx> <91a2ba3e0509201453150821df@xxxxxxxxxxxxxx> <1127311620.2710.5.camel@xxxxxxxxxxxxxxxx> <91a2ba3e05092110474d56c8b8@xxxxxxxxxxxxxx>
> many thanks for taking a look into the gory details! has a bug been
> entered into the tracking system, or should i go ahead and do that?
I filed a bug about this problem.
> (I'll probably just write the Parser wrapper code in Java itself for
> now instead of hacking the sources.)
You can also fool the scalac compiler by subclassing BlastLikerSAXParser
and overriding setContentHandler. This way, it will reference your class
in the generated bytecode. You can do that in Scala as follows:
package org.usine.blast.graph;
import org.biojava.bio.program.sax._;
class MyBlastParser extends BlastLikeSAXParser {
override def setContentHandler(ch: org.xml.sax.ContentHandler) =
super.setContentHandler(ch);
}
Then modify your Parser.scala accordingly:
[...]
//make a BlastLikeSAXParser
val parser = new MyBlastParser();
[..]
Regards,
Iuli
Date: September 21, 2005
From: Raoul Duke <raould@xxxxxxxxx>
Many thanks to all for all the information! The future of the Eclipse plug-in sounds exciting (although, personally I am a die-hard Emacs person, and didn't really want to get sucked into the world of Eclipse - I think of horror movies where the zombie is saying, "Join us!!! It is bliss!!! Even if your favourite key-bindings don't work any more!!!"). I will try running Ant with the other JRE (I'm trying out things like JamVM and SableVM) to get scalac/scala running in that as well. sincerely.
Date: September 21, 2005
From: Raoul Duke <raould@xxxxxxxxx>
In-reply-to:
<1127311620.2710.5.camel@xxxxxxxxxxxxxxxx>
References:
<91a2ba3e05091823452f116efb@xxxxxxxxxxxxxx> <91a2ba3e0509201453150821df@xxxxxxxxxxxxxx> <1127311620.2710.5.camel@xxxxxxxxxxxxxxxx>
> I think there is no way around it but to modify the Java library to make > that class public (until a new release of scalac fixes that bug). hello Iulian, many thanks for taking a look into the gory details! has a bug been entered into the tracking system, or should i go ahead and do that? (I'll probably just write the Parser wrapper code in Java itself for now instead of hacking the sources.) sincerely.
Date: September 21, 2005
From: Stéphane Micheloud <stephane.micheloud@xxxxxxx>
In-reply-to:
<43316ECE.3060605@xxxxxxxx>
References:
<433164BD.6050703@xxxxxxxx> <4331691E.4050503@xxxxxxx> <43316ECE.3060605@xxxxxxxx>
robert kuzelj wrote:
hi stephane,Add a symbolic link "scala --> scala-1.4.0.0" in the "share/" directory (or just rename it).ok that seems to work. thou sometimes the colors are sort of "innovative". black background and lightblue text for example.
We - actually one person in our lab - also have observed that strange behavior; in my case it works fine both on FC3 and WinXP.
well maybe i only need to get used to it :-) i will see if there is a pattern when this happens.We need to fix that issue *very soon* with a new release (1.4.0.1 ?!) of the Scala software.actually a description on the plugin page would fix that probably very fast.
Done (see "Known bugs & workarounds").
ciao robertj
Bye --S. Micheloud -- ======================================================================== Stephane Micheloud Tel: +41 21 693 7593 EPFL - I&C - LAMP Fax: +41 21 693 6660 IN BC 346 Station 14 http://lamp.epfl.ch/~michelou/ CH-1015 Lausanne, Switzerland mailto: stephane.micheloud@xxxxxxx ========================================================================
Date: September 21, 2005
From: robert kuzelj <robert.kuzelj@xxxxxxxx>
In-reply-to:
<4331691E.4050503@xxxxxxx>
References:
<433164BD.6050703@xxxxxxxx> <4331691E.4050503@xxxxxxx>
hi stephane, > Add a symbolic link "scala --> scala-1.4.0.0" in > the "share/" directory (or just rename it). ok that seems to work. thou sometimes the colors are sort of "innovative". black background and lightblue text for example. well maybe i only need to get used to it :-) i will see if there is a pattern when this happens. > We need to fix that issue *very soon* with a new > release (1.4.0.1 ?!) of the Scala software. actually a description on the plugin page would fix that probably very