another yields the best of me :) - not the same yield though

Thread.`yield`() (backquotes)

2009/10/16 Razvan Cojocaru :
>
> funny but when dealing with Threads and fors, both can yield the best of you,
> in different ways...here's the other way:
>
> Now - I'm trying to call java.lang.Thread.yield() and obviously can't, since
> it's a reserved keyword in scala. I ended up creating a java class to give
> it a new name:
>
> class MoreThreads {
>        public static void scalayield () throws InterruptedException {
> java.lang.Thread.sleep(1); }
> }
>
> Is there a way that I can access it directly in scala?
>
> [kidding] Like a java.lang.Thread.notascalakeyword(yield)() ?
>
> -----
> Razie
> http://feeds.razie.com/RazvanTech
> --
> View this message in context: http://www.nabble.com/another-yields-the-best-of-me-%3A%29---not-the-sam...
> Sent from the Scala - User mailing list archive at Nabble.com.
>
>

use `yield` (between backticks)

On Fri, Oct 16, 2009 at 6:19 PM, Razvan Cojocaru <razvanc99@yahoo.com> wrote:

funny but when dealing with Threads and fors, both can yield the best of you,
in different ways...here's the other way:

Now - I'm trying to call java.lang.Thread.yield() and obviously can't, since
it's a reserved keyword in scala. I ended up creating a java class to give
it a new name:

class MoreThreads {
       public static void scalayield () throws InterruptedException {
java.lang.Thread.sleep(1); }
}

Is there a way that I can access it directly in scala?

[kidding] Like a java.lang.Thread.notascalakeyword(yield)() ?

-----
Razie
http://feeds.razie.com/RazvanTech
--
View this message in context: http://www.nabble.com/another-yields-the-best-of-me-%3A%29---not-the-same-yield-though-tp25928179p25928179.html
Sent from the Scala - User mailing list archive at Nabble.com.

--
  __~O
 -\ <,
(*)/ (*)

reality goes far beyond imagination

> Use back ticks: Thread.`yield`()

By the way: Using `Thread.yield' is generally not a good idea since its
behavior is undefined and varies from JVM to JVM. It may even be
implemented so that it actually does nothing.

If your code relies on `Thread.yield' there is definitely something
wrong with your strategy.

I wanted to cause something to crash in a multi-threaded test and used yield
to multiply multi-threaded activity on some unprotected collections - just
proving a point...

for (i <- 0 until 30) razie.Threads.run {
for (j <- 0 until 100) {
val s = rs(j)
m.put(s,s)
Thread.`yield`
m.get (s)
Thread.`yield`
}
}

phkoester wrote:
>
>> Use back ticks: Thread.`yield`()
>
> By the way: Using `Thread.yield' is generally not a good idea since its
> behavior is undefined and varies from JVM to JVM. It may even be
> implemented so that it actually does nothing.
>
> If your code relies on `Thread.yield' there is definitely something
> wrong with your strategy.
>
>

-----
Razie
http://feeds.razie.com/RazvanTech

Use back ticks: Thread.`yield`()

Razvan Cojocaru schrieb:
> funny but when dealing with Threads and fors, both can yield the best of you,
> in different ways...here's the other way:
>
> Now - I'm trying to call java.lang.Thread.yield() and obviously can't, since
> it's a reserved keyword in scala. I ended up creating a java class to give
> it a new name:
>
> class MoreThreads {
> public static void scalayield () throws InterruptedException {
> java.lang.Thread.sleep(1); }
> }
>
> Is there a way that I can access it directly in scala?
>
> [kidding] Like a java.lang.Thread.notascalakeyword(yield)() ?
>
> -----
> Razie
> http://feeds.razie.com/RazvanTech

>> Use back ticks: Thread.`yield`()

Nice, isn't it? Now Scala may be the first language to allow blanks in
identifiers:

scala> val `Hi, freaks!` = 2
Hi, freaks!: Int = 2

:)

(Internally, the blank is translated to something resembling `$u0020',
IIRC.)

Huah!

phkoester wrote:
>
> Use back ticks: Thread.`yield`()
>

-----
Razie
http://feeds.razie.com/RazvanTech

maintenance nightmare :)
jiri

On Fri, Oct 16, 2009 at 6:41 PM, Philip Köster <philip.koester@web.de> wrote:

Use back ticks: Thread.`yield`()

Nice, isn't it? Now Scala may be the first language to allow blanks in identifiers:

scala> val `Hi, freaks!` = 2
Hi, freaks!: Int = 2

:)

(Internally, the blank is translated to something resembling `$u0020', IIRC.)

--
web: http://dredwerkz.ic.cz
group: http://groups.google.com/group/dr3dwerkz
icq: 218 659 431

I'd suspend your checking in privileges... :)

phkoester wrote:
>
>>> Use back ticks: Thread.`yield`()
>
> Nice, isn't it? Now Scala may be the first language to allow blanks in
> identifiers:
>
> scala> val `Hi, freaks!` = 2
> Hi, freaks!: Int = 2
>
> :)
>
> (Internally, the blank is translated to something resembling `$u0020',
> IIRC.)
>
>

-----
Razie
http://feeds.razie.com/RazvanTech

>>>>> "Philip" == Philip Köster writes:

>>> Use back ticks: Thread.`yield`()

Philip> Nice, isn't it? Now Scala may be the first language to allow
Philip> blanks in identifiers:

as usual, Lisp was there first:

Welcome to Clozure Common Lisp Version 1.3-r11936 (DarwinX8664)!
? (setf |foo bar| 5)
5
? (+ |foo bar| |foo bar|)
10

Since we're here, can we have a (or, since everything seems to have already
been built, is there a) facility to allow Java code mingled with Scala?

remember how in C/C++ you could write assembly, something like
native {
...
}

So, how about a
Java {
...
}

executed in the same scope?

OR maybe

java def f= {
...
}

if it's easier to scope at method level...?

OR,

lang[Java] def = {
... // expert code in Java
}

Seth Tisue wrote:
>
>>>>>> "Philip" == Philip Köster writes:
>
> >>> Use back ticks: Thread.`yield`()
>
> Philip> Nice, isn't it? Now Scala may be the first language to allow
> Philip> blanks in identifiers:
>
> as usual, Lisp was there first:
>
> Welcome to Clozure Common Lisp Version 1.3-r11936 (DarwinX8664)!
> ? (setf |foo bar| 5)
> 5
> ? (+ |foo bar| |foo bar|)
> 10
>

On Fri, 2009-10-16 at 10:46 -0700, Razvan Cojocaru wrote:
> Since we're here, can we have a (or, since everything seems to have already
> been built, is there a) facility to allow Java code mingled with Scala?

Sorry guv, but this is definitely a Bad Idea.

The point at which to have multi-language capability is at the linker
level not at the editor level. Keep Scala files and Java files
separate. Scala can use Java and vice versa. The beauty of the JVM is
that Java, Scala, Groovy, Clojure, Jython, and JRuby can all be used in
the same system. But let a given file be for a given language.

Why would you want that?

On Fri, Oct 16, 2009 at 1:46 PM, Razvan Cojocaru <razvanc99@yahoo.com> wrote:

Since we're here, can we have a (or, since everything seems to have already
been built, is there a) facility to allow Java code mingled with Scala?

remember how in C/C++ you could write assembly, something like
native {
...
}

So, how about a
Java {
...
}

executed in the same scope?

OR maybe

java def f= {
...
}

if it's easier to scope at method level...?

OR,

lang[Java] def = {
... // expert code in Java
}


Seth Tisue wrote:
>
>>>>>> "Philip" == Philip Köster <philip.koester@web.de> writes:
>
>  >>> Use back ticks: Thread.`yield`()
>
>  Philip> Nice, isn't it? Now Scala may be the first language to allow
>  Philip> blanks in identifiers:
>
> as usual, Lisp was there first:
>
> Welcome to Clozure Common Lisp Version 1.3-r11936  (DarwinX8664)!
> ? (setf |foo bar| 5)
> 5
> ? (+ |foo bar| |foo bar|)
> 10
>
> --
> Seth Tisue @ Northwestern University / http://tisue.net
> lead developer, NetLogo: http://ccl.northwestern.edu/netlogo/
>
>


-----
Razie
http://feeds.razie.com/RazvanTech
--
View this message in context: http://www.nabble.com/another-yields-the-best-of-me-%3A%29---not-the-same-yield-though-tp25928179p25929580.html
Sent from the Scala - User mailing list archive at Nabble.com.

I don't see why you'd have the "file" as the language modularity unit when
you can have multiple classes in the same file and even multiple classes in
the same class...multiple languages in the same folder and the same
package...it's true that you can't have parts of a class in different
files...although that's what injection of methods does...

all languages share so many things - usually just the syntax and the
implied/assigned semantics are different. The end results are the same as
long as they are complete...(meaning you could compile any language into any
other language). A class is still a class, a member ... and so on...

since scala is scalable, why not scale it across languages as well? (does
that sentence make sense?)

I believe there is support for "compiler plugins". why not let me use the
hooks in the normal code to talk to my plugins (i.e.plugin the Java
compiler).

I'm thinking along the lines of JSR 223, which unified scripting platforms
in Java http://www.jcp.org/en/jsr/detail?id=223

Russel Winder-4 wrote:
>
> On Fri, 2009-10-16 at 10:46 -0700, Razvan Cojocaru wrote:
>> Since we're here, can we have a (or, since everything seems to have
>> already
>> been built, is there a) facility to allow Java code mingled with Scala?
>
> Sorry guv, but this is definitely a Bad Idea.
>
> The point at which to have multi-language capability is at the linker
> level not at the editor level. Keep Scala files and Java files
> separate. Scala can use Java and vice versa. The beauty of the JVM is
> that Java, Scala, Groovy, Clojure, Jython, and JRuby can all be used in
> the same system. But let a given file be for a given language.
>

What would you gain??

On Fri, Oct 16, 2009 at 2:31 PM, Razvan Cojocaru <razvanc99@yahoo.com> wrote:

I don't see why you'd have the "file" as the language modularity unit when
you can have multiple classes in the same file and even multiple classes in
the same class...multiple languages in the same folder and the same
package...it's true that you can't have parts of a class in different
files...although that's what injection of methods does...

all languages share so many things - usually just the syntax and the
implied/assigned semantics are different. The end results are the same as
long as they are complete...(meaning you could compile any language into any
other language). A class is still a class, a member ... and so on...

since scala is scalable, why not scale it across languages as well? (does
that sentence make sense?)

I believe there is support for "compiler plugins". why not let me use the
hooks in the normal code to talk to my plugins (i.e.plugin the Java
compiler).

I'm thinking along the lines of JSR 223, which unified scripting platforms
in Java http://www.jcp.org/en/jsr/detail?id=223


Russel Winder-4 wrote:
>
> On Fri, 2009-10-16 at 10:46 -0700, Razvan Cojocaru wrote:
>> Since we're here, can we have a (or, since everything seems to have
>> already
>> been built, is there a) facility to allow Java code mingled with Scala?
>
> Sorry guv, but this is definitely a Bad Idea.
>
> The point at which to have multi-language capability is at the linker
> level not at the editor level.  Keep Scala files and Java files
> separate.  Scala can use Java and vice versa.  The beauty of the JVM is
> that Java, Scala, Groovy, Clojure, Jython, and JRuby can all be used in
> the same system.  But let a given file be for a given language.
>
> --
> Russel.
> =============================================================================
> Dr Russel Winder      Partner
>                                             xmpp: russel@russel.org.uk
> Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
> 41 Buckmaster Road,   f: +44 8700 516 084   voip:
> 3Arussel [dot] winder [at] ekiga [dot] net" rel="nofollow">sip:russel.winder@ekiga.net
> London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder
>
>
>


-----
Razie
http://feeds.razie.com/RazvanTech
--
View this message in context: http://www.nabble.com/another-yields-the-best-of-me-%3A%29---not-the-same-yield-though-tp25928179p25930191.html
Sent from the Scala - User mailing list archive at Nabble.com.

Good Q.

I just had this issue again, where I had to create a Java class to work
around a compiler non-sensicality I didn't have time to debug. Granted - not
good enough of a reason, since it's likely some temporary bug in the 2.8
nightly...from a few nights ago...

Description Resource Path Location Type
overloaded method value setHeader with alternatives (x$1: java.util.List[_
<: java.lang.Object])Unit (x$1: Array[java.lang.Object])Unit cannot be
applied to (Array[java.lang.String]) PerfTestLoadSubs.scala
/sis_proto/src/com/sigma/sis/raz line 39 Scala Problem

Naftoli Gugenheim wrote:
>
> Why would you want that?
>

-----
Razie
http://feeds.razie.com/RazvanTech

Naftoli Gugenheim wrote:
>
> What would you gain??
>

Here's the actual reason, although far fetched and, after the "yields"
experience I know I'm not good at explaining stuff...

A------------
One thing about scala is the scriptability which combined with platform
independence, has the good chance to replace ksh, cmd.exe and the like...

Still, there's stuff that's better done in other
languages/scripts/things...simply because I didn't learn about a scala
library that does the same yet or I'm familiar with the other thing: "find .
-exec grep | cut | sort | wc" for instance. So why not let me write that
right there, where I need it, rather than goofy JNDI-indirected call to
another completely separate thing?

B--------------object-oriented world
push that to extreme and you'll ask yourself, since a container can
hold why can't a Class<?> hold a Method and a Method?
what's the big deal?

C-------------- google wave (or microsoft word)
did you see the demo? you simply drop in any object you want on the same
canvas and it's handled as long as the handler's available....I bet you that
20 years ago someone was asking why would you mix an active excel graph with
a paragraph of formatted text...

D-------------- personal scripting experience
I ended up mixing and matching many scripts on the same canvas and it works
well. you can prefix each line with the script name and I invoke the
specific compiler. you can define new languages on the fly - just plug them
into the "factory".

E------------- think 20 years from now
do you think there'll be a concept of "file" anywhere other than government
agencies and police departments? it's as arbitrary as "sector" is on the
hdd.

the class and the knowledge it contains are what matters, not how you
express that.

-----------

sorry, just some ideas I'm mulling over for some time, I'm most likely
incapable of explaining them... :)

cheers,

-----
Razie
http://feeds.razie.com/RazvanTech

 At first I liked jour idea  :

    lang[Java] def = {... }   
    lang[Whatever] def = {... }   

  But on second thought, one thing scala would loose is the ability to migrate to new
 VMs, It would be interesting if scala could outlive the Java VM, I know
 a dotNet port exists (although it's probably collecting dust at the moment), but who
 knows, another exciting VM might comes along, and scala could migrate to it, having to
 support N extra languages on this new VM would make it harder...


On Fri, Oct 16, 2009 at 2:31 PM, Razvan Cojocaru <razvanc99@yahoo.com> wrote:

I don't see why you'd have the "file" as the language modularity unit when
you can have multiple classes in the same file and even multiple classes in
the same class...multiple languages in the same folder and the same
package...it's true that you can't have parts of a class in different
files...although that's what injection of methods does...

all languages share so many things - usually just the syntax and the
implied/assigned semantics are different. The end results are the same as
long as they are complete...(meaning you could compile any language into any
other language). A class is still a class, a member ... and so on...

since scala is scalable, why not scale it across languages as well? (does
that sentence make sense?)

I believe there is support for "compiler plugins". why not let me use the
hooks in the normal code to talk to my plugins (i.e.plugin the Java
compiler).

I'm thinking along the lines of JSR 223, which unified scripting platforms
in Java http://www.jcp.org/en/jsr/detail?id=223


Russel Winder-4 wrote:
>
> On Fri, 2009-10-16 at 10:46 -0700, Razvan Cojocaru wrote:
>> Since we're here, can we have a (or, since everything seems to have
>> already
>> been built, is there a) facility to allow Java code mingled with Scala?
>
> Sorry guv, but this is definitely a Bad Idea.
>
> The point at which to have multi-language capability is at the linker
> level not at the editor level.  Keep Scala files and Java files
> separate.  Scala can use Java and vice versa.  The beauty of the JVM is
> that Java, Scala, Groovy, Clojure, Jython, and JRuby can all be used in
> the same system.  But let a given file be for a given language.
>
> --
> Russel.
> =============================================================================
> Dr Russel Winder      Partner
>                                             xmpp: russel@russel.org.uk
> Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
> 41 Buckmaster Road,   f: +44 8700 516 084   voip:
> 3Arussel [dot] winder [at] ekiga [dot] net" rel="nofollow">sip:russel.winder@ekiga.net
> London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder
>
>
>


-----
Razie
http://feeds.razie.com/RazvanTech
--
View this message in context: http://www.nabble.com/another-yields-the-best-of-me-%3A%29---not-the-same-yield-though-tp25928179p25930191.html
Sent from the Scala - User mailing list archive at Nabble.com.

Missed this one - (i should use the preview more often, eh?)

My conclusion was that scala is not the end all. There will be no ONE
language, but a few and all programmers will use constantly a few. one-two
for scripting, one-two JVM0-ish, one-two graphix etc.

WHY bother with the impracticality of the current arbitrary separation
between all those environments?

Razvan Cojocaru wrote:
>
>
> Naftoli Gugenheim wrote:
>>
>> What would you gain??
>>
>
> ...
>
>

-----
Razie
http://feeds.razie.com/RazvanTech

--------------------------------------------------
From: "Razvan Cojocaru"
Sent: Friday, October 16, 2009 3:31 PM
To:
Subject: Re: [scala-user] another yields the best of me :) - not the same
yield though

> I don't see why you'd have the "file" as the language modularity unit when
> you can have multiple classes in the same file and even multiple classes
> in
> the same class...multiple languages in the same folder and the same

The reason that holds this modularity is that each compiler (Java, JRuby,
Scala) must know what things they should process, and what they shoudn't..
for me, there makes no sense to let the Scala compiler 'delegate'
compilation to others JVM languages (I'm not even considering non-JVM ones),
because the interop, when needed with legacy libraries (I don't see any
other uses for such interoperability, since Scala does everything, even
more), is already supported.

With an IDE, the debug process can be transparent, you don't need the scala
environment to debug java classes, just let the java debug facilities do
that for you.

Cheers.

> package...it's true that you can't have parts of a class in different
> files...although that's what injection of methods does...
>
> all languages share so many things - usually just the syntax and the
> implied/assigned semantics are different. The end results are the same as
> long as they are complete...(meaning you could compile any language into
> any
> other language). A class is still a class, a member ... and so on...
>
> since scala is scalable, why not scale it across languages as well? (does
> that sentence make sense?)
>
> I believe there is support for "compiler plugins". why not let me use the
> hooks in the normal code to talk to my plugins (i.e.plugin the Java
> compiler).
>
> I'm thinking along the lines of JSR 223, which unified scripting platforms
> in Java http://www.jcp.org/en/jsr/detail?id=223
>
>
> Russel Winder-4 wrote:
>>
>> On Fri, 2009-10-16 at 10:46 -0700, Razvan Cojocaru wrote:
>>> Since we're here, can we have a (or, since everything seems to have
>>> already
>>> been built, is there a) facility to allow Java code mingled with Scala?
>>
>> Sorry guv, but this is definitely a Bad Idea.
>>
>> The point at which to have multi-language capability is at the linker
>> level not at the editor level. Keep Scala files and Java files
>> separate. Scala can use Java and vice versa. The beauty of the JVM is
>> that Java, Scala, Groovy, Clojure, Jython, and JRuby can all be used in
>> the same system. But let a given file be for a given language.
>>

Not necessarily. I didn't mean that assembly should be one of the supported
languages. Java definitely should be (and it's easy since the compiler is
built into the JDK) but the rest I was thinking scripting languages like
JavaScript, OGNL, ruby etc - in the spirit of the scripting JSR. Since the
scripting JSR is incorporated in JDK 6, I believe, we could simply use that
for the binding. All you would need then is the proper bindings for the
respective scripting language, most of them already available as Jar files.

Just like the backquotes, it basically would be a simple facility to tell
the parser that the respective section is not scala but a script of type
"[]"...

Maxime Lévesque wrote:
>
> At first I liked jour idea :
>
> lang[Java] def = {... }
> lang[Whatever] def = {... }
>
> But on second thought, one thing scala would loose is the ability to
> migrate to new
> VMs, It would be interesting if scala could outlive the Java VM, I know
> a dotNet port exists (although it's probably collecting dust at the
> moment), but who
> knows, another exciting VM might comes along, and scala could migrate to
> it, having to
> support N extra languages on this new VM would make it harder...
>
>
> On Fri, Oct 16, 2009 at 2:31 PM, Razvan Cojocaru
> wrote:
>
>>
>> I don't see why you'd have the "file" as the language modularity unit
>> when
>> you can have multiple classes in the same file and even multiple classes
>> in
>> the same class...multiple languages in the same folder and the same
>> package...it's true that you can't have parts of a class in different
>> files...although that's what injection of methods does...
>>
>> all languages share so many things - usually just the syntax and the
>> implied/assigned semantics are different. The end results are the same as
>> long as they are complete...(meaning you could compile any language into
>> any
>> other language). A class is still a class, a member ... and so on...
>>
>> since scala is scalable, why not scale it across languages as well? (does
>> that sentence make sense?)
>>
>> I believe there is support for "compiler plugins". why not let me use the
>> hooks in the normal code to talk to my plugins (i.e.plugin the Java
>> compiler).
>>
>> I'm thinking along the lines of JSR 223, which unified scripting
>> platforms
>> in Java http://www.jcp.org/en/jsr/detail?id=223
>>
>>
>> Russel Winder-4 wrote:
>> >
>> > On Fri, 2009-10-16 at 10:46 -0700, Razvan Cojocaru wrote:
>> >> Since we're here, can we have a (or, since everything seems to have
>> >> already
>> >> been built, is there a) facility to allow Java code mingled with
>> Scala?
>> >
>> > Sorry guv, but this is definitely a Bad Idea.
>> >
>> > The point at which to have multi-language capability is at the linker
>> > level not at the editor level. Keep Scala files and Java files
>> > separate. Scala can use Java and vice versa. The beauty of the JVM is
>> > that Java, Scala, Groovy, Clojure, Jython, and JRuby can all be used in
>> > the same system. But let a given file be for a given language.
>> >
>> > --
>> > Russel.
>> >
>> =============================================================================
>> > Dr Russel Winder Partner
>> > xmpp: russel@russel.org.uk
>> > Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
>> > 41 Buckmaster Road, f: +44 8700 516 084 voip:
>> > sip:russel.winder@ekiga.net
>> > London SW11 1EN, UK m: +44 7770 465 077 skype: russel_winder
>> >
>> >
>> >
>>
>>
>> -----
>> Razie
>> http://feeds.razie.com/RazvanTech
>> --
>> View this message in context:
>> http://www.nabble.com/another-yields-the-best-of-me-%3A%29---not-the-sam...
>> Sent from the Scala - User mailing list archive at Nabble.com.
>>
>>
>
>

-----
Razie
http://feeds.razie.com/RazvanTech