Custom Search
|
Date: July 31, 2006
From: Andrew Lentvorski <bsder@xxxxxxxxxxx>
In-reply-to:
<1154291424.44cd16e0544ed@xxxxxxxxxxxxxxx>
References:
<1154291424.44cd16e0544ed@xxxxxxxxxxxxxxx>
philipp.haller@xxxxxxx wrote:
Hi all, I finally resolved the deadlock and stack overflow problems (scala.actors) that were reported by Andrew. I tested with Andrew's ping pong example exchanging 10.000.000 messages (attached).
PingPong is verified deadlock and stack overflow free on Linux. I still haven't gotten it to work correctly on OS X or Windows, but I think those are library path failures. I'm probably still picking up an old library.
Once I get things verified on OS X and Windows, I'll check for the ActorThreadCrash problem.
Thanks for being so responsive about this. I've been trying to sell the benefits of lightweight, concurrent messaging to some management types and this kind of response sure helps my case.
Thanks, -a
Date: July 31, 2006
From: Andrew Lentvorski <bsder@xxxxxxxxxxx>
In-reply-to:
<dd924de881.de881dd924@xxxxxxxxxxxx>
References:
<dd924de881.de881dd924@xxxxxxxxxxxx>
Sean Mc Dirmid wrote:
Are we still having problems compiling under OS X? I know G4's are hopeless, but I haven't had any problems under the Intels.
I'm using a G4. Grumble. It's probably the JIT then. Sigh. I'll mark it with Apple, but it's not likely to get fixed. Thanks, -a
Date: July 31, 2006
From: Andrew Lentvorski <bsder@xxxxxxxxxxx>
In-reply-to:
<9EE8C62A-77C6-4FDE-9D01-4DE40B7AD3C4@xxxxxxx>
References:
<9EE8C62A-77C6-4FDE-9D01-4DE40B7AD3C4@xxxxxxx>
sean mcdirmid wrote:
Drawbacks: must parenthesize, e.g., a ? b : c ? d : e must be written as a ? b ! (c ? d ! e);
I don't see that as a drawback. ;)I hope that "!" isn't being floated as the actual operator. Given that "!" has usage in conditional expressions already, something like:
! a ? b ! eactivates a lot of brain cells to read. Add the fact that "!" also has context in actors and it's starting to resemble Perl.
If a compound condition is desirable, it really should look and act like the C one and ":" needs to get added as an operator.
As an aside, what stops ":" from being an operator? This seems like a larger problem of being unable to add reasonable syntax extensions. Although, that's probably treading close to Lisp-macro territory.
-a
Date: July 31, 2006
From: "Raoul Duke" <raould@xxxxxxxxx>
I find all of this concurrenty stuff interesting (the new Scala agents sounds tremendous, and I've been sad for a while that Timber hasn't come out yet), but have to ask folks: how on earth do you debug things in this style? I think whenever somebody invents or implements a new paradigm they seem to skip the issue of debugging, which strikes me as 60% of the problem. I would very much appreciate hearing if a regular debugger can really be used to make sense of what is going on, or if folks have ideas for how to develop new types of debuggers or new features (e.g. the Alice inspector showing futures/promises etc.). sincerely.
Date: July 31, 2006
From: sean mcdirmid <sean.mcdirmid@xxxxxxx>
| Hi, I've just been experimenting with getting C-style condition _expression_ (a ? b : c) syntax to work in Scala. First, manual currying seems to get us most of the way there, where we substitute ! (a Scala operator) for : (not a Scala operator): class BoolWrapper0(val b : Boolean) { class Condition[A](ifTrue : A) { def  : B = if (b) ifTrue else ifFalse; } def ?[A](ifTrue : A) = new Condition(ifTrue); } implicit def coerceBool0(value : Boolean) = new BoolWrapper0(value); Importing the above code allows us to write expressions like the following: val y : String = (10 > 20) ? "never!" ! "always!"; which is equivalent to: val y : String = if (10 > 20) "never!" else "always!"; Why bother? Well, we can save some characters (4 + (sometimes) 2) and it looks more like an _expression_ than a statement. More importantly, unlike if, we can overload ?/!; e.g., we can have a version that works for signals: class BoolWrapper(signal : Signal[Boolean]) { .... class Condition[B](ifTrue : Signal[B]) { def  = { for (val c <- signal; val r <- if (c) ifTrue else ifFalse) yield r; } } def ?[A](ifTrue : Signal[A]) = new Condition(ifTrue); } Then we can write things like: val temperature = new Export(40); val text = (temperature > 72) ? "too hot" ! "ok"; temperature.current = 80; // text is now "too hot" Drawbacks: must parenthesize, e.g., a ? b : c ? d : e must be written as a ? b ! (c ? d ! e); |
Date: July 30, 2006
From: philipp.haller@xxxxxxx
Hi all, I finally resolved the deadlock and stack overflow problems (scala.actors) that were reported by Andrew. I tested with Andrew's ping pong example exchanging 10.000.000 messages (attached). There was a race inside `receive' which manipulated scheduling-related state non-atomically. Letting `receive' always submit a task item to the scheduler (fix for stack overflow problem) allowed for a simple fix by wrapping `receive' in a synchronized block. Note that we are not "over-locking" as the manipulation of scheduling-related state is now precisely isolated from the processing of messages. All my fixes are in Scala SVN and will be available in the next release. Cheers, -- Philipp
pingpong.scala
Description: Binary data
Date: July 30, 2006
From: philipp.haller@xxxxxxx
In-reply-to:
<44CA80F3.9050909@xxxxxxxxxxx>
References:
<44CA6395.4080705@xxxxxxxxxxx> <44CA80F3.9050909@xxxxxxxxxxx>
> > Exception in thread "Thread-1" java.lang.AbstractMethodError: > > As further information, this bug is repeatable on OS X and Windows. > Here is the test code that I used: > [...] I cannot reproduce the exception when compiling/running your code with the latest Scala release 2.1.7patch8283. Otherwise I have only tested with the latest SVN version (no problems), though. Cheers, -- Philipp
Date: July 30, 2006
From: philipp.haller@xxxxxxx
In-reply-to:
<44C7A56C.2020209@xxxxxxxxxxx>
References:
<44C6C234.7070000@xxxxxxxxxxx> <44C7A56C.2020209@xxxxxxxxxxx>
> > 3) OS X throws StackOverflowExceptions after about 800 messages > > This appears to be a bad interaction with the JVM thread scheduler. If > I slow down the ping/pong with a Thread.sleep(1), it pushes the > StackOverflow to a lot later in passing messages. If I use a > Thread.sleep(10), it seems to make the problem go completely away. > > Apparently, OS X isn't as aggressive about switching away from running > threads as other systems. On my Ubuntu box with linux 2.6.12 I got StackOverflowExceptions, too. The reason why they go away when using Thread.sleep(x) is because then "receive" almost always blocks. Thus, the call stack first gets unwound before the message is processed. I fixed this stack overflow problem by making "receive" submit a work item to the scheduler even if it could be readily processed by the current thread. This way, receive statements are always executed on an "empty" stack. I haven't checked in my changes into SVN, yet, as I am still working to fix the deadlock problem: > > 2) I get an occasional deadlock. > > This appears to be a real problem. I have changed the wait() statements > in WorkerThread to wait(5000) and rebuilt, but there is no recovery. > > Something in the scheduler itself has failed. > > I have currently only been running on Windows and OS X, so I'm going to > try this on Linux and see if there is a change that might help isolate > the fault. Trying to isolate the problem, I changed the scheduler to use the thread-pool executors of Java 1.5 (java.util.concurrent.Executor). On my machine the deadlock still occurs after about 1 out of 300.000 message sends. I attached the ping pong code I use for testing. Cheers, -- Philipp
pingpong.scala
Description: Binary data
Date: July 30, 2006
From: sean mcdirmid <sean.mcdirmid@xxxxxxx>
In-reply-to:
<eacep2$5sn$1@xxxxxxxxxxxxx>
References:
<eacep2$5sn$1@xxxxxxxxxxxxx>
| Hi, On Jul 28, 2006, at 9:36 AM, Shahbaz Chaudhary wrote:
Sounds like functional reactive programming (FRP). We are looking at doing FRP in Scala (a master's student has signed up for it), we haven't decided to go with combinators (similar to your approach above), connections (as in my SuperGlue paper at this year's ECOOP), or a more pure function-oriented implementation (similar to PLT Scheme's FatherTime). I'm not very enthusiastic about treating continuously changing values (signals) as streams of their future values. While this works, it doesn't seem to mesh well with the event handling that will often be used to propagate changes. As a result, I prefer syntax/semantics that avoids looking at these values as strings (see my SuperGlue paper, I even use a similar example). On the other hand, a stream-based signal might might work better in Scala with its support for for comprehensions. So here is how to do it (using map and flatMap, I don't know if "filter" fits in here): First, we define a Signal trait whose current value can be computed with an observer that is notified of changes in this value: trait Observer { def changed : Unit; } trait Signal[A] { def current(o : Observer) : A; def map[B](f : A => B) = new Signal[B] { def current(o : Observer) : B = f(Signal.this.current(o)); } def flatMap[B](f: A => Signal[B]): Signal[B] = new Signal[B] { def current(o : Observer) : B = f(Signal.this.current(o)).current(o); } } "map" and "flatMap" are expressed in obvious ways (essentially, to thunk the signal's current value). We define a base signal implementation that holds a list of observers and a slot for the signal's current value: class BaseSignal[A](initial : A) extends Signal[A] { var observers = new ListSet[Observer]; private var current0 = initial; def current(o : Observer) = if (o != null) observers = observers + o; current0; def current_=(value : A) = { current0 = value; var observers0 = observers; observers = new ListSet[Observer]; for (val o <- observers0) o.changed; } } Note that I'm flushing all of the observers after every change. In this way, we don't have to have a remove observer method and we can avoid glitches (the observer is re-installed when the client get's the value again). Ok, now we create some signals: val temperature = new BaseSignal(40); val x = for (val t <- temperature) yield if (t > 72) "terrible" else "excellent"; val prefix = new BaseSignal("Temperature "); val y = for (val t <- temperature; val p <- prefix; val q <- x) yield p + " " + t + " " + q; And build an observer to simulate a UI client: val o = new Observer { def changed = Console.println("CHANGED-TO: " + y.current(this)); } Console.println("ANSWER-IS: " + y.current(o)); And change the base signals: temperature.current_=(80); prefix.current_=("qihou"); Results: ANSWER-IS: Temperature 40 excellent CHANGED-TO: Temperature 80 terrible CHANGED-TO: qihou 80 terrible
Aggregation and averaging is a bit more difficult, but you can express these as combinators. The problem with a stream abstraction is that it doesn't make sense, you don't want to count how often a value changes, rather you want to compute how the value changes over time. If you want to reason about time explicitly (e.g., for doing simulations), you really need some of the heavy duty stuff they do in Yampa (Haskell's latest version of FRP). If you want to express user interfaces, implicit time is good enough (and more efficient).
I did this in my dissertation (in the evaluation chapter, you can dl at lamp.epfl.ch/~mcdirmid). It didn't work out very well because signals are too precise and in a parser you want to be less precise about what has changed (erring on the conservative side of course). It would work for small examples but suck up performance for larger pieces of code. I'm currently working on an incremental parser that does this but I'm not using signals/SynchVar's or anything like that. Instead, I'm using an iterative incremental algorithm to conservatively "refresh" nodes as their dependencies change.
Let me know how it turns out! Sean |
Date: July 30, 2006
From: Vijay Saraswat <vijay@xxxxxxxxxxxx>
In-reply-to:
<eag4sg$rle$1@xxxxxxxxxxxxx>
References:
<eacep2$5sn$1@xxxxxxxxxxxxx> <44C9DE9F.9040404@xxxxxxx> <eag4sg$rle$1@xxxxxxxxxxxxx>
I would encourage people to look at jcc: http://www.cse.psu.edu/~saraswat/jcc.html The source code is available from Source Forge at https://sourceforge.net/projects/mlang/In essence, jcc is an integration of timed concurrent constraint programming in Java. Computation is organized in the form of reactive synchronous programs, each running in a vat (event loop). Each vat hosts an agent. Parallel composition of agents is supported. Agents communicate via promises --- logic variables, with full unification. Concurrency is supported logically -- a single vat (with an arbitrary number of agents) is run on a single Java thread.
The constraint system implementation is designed to be extensible. The current version supports Herbrand constraints, with the usual Prolog unification.
If anyone wants to port it to Scala, please go ahead. I would be happy to answer questions about it. I did port it to Scala a few months ago, but need to clear it through the IBM source code release process since I now work for IBM. That will take some time.
Best, Vijay Shahbaz Chaudhary wrote:
Martin, thanks for the response. I wonder if you could help clear up another (academic) confusion for me:Are these SyncVars the same as logic variables used by logic and constraint programming languages? If so, how much and what kind of work is required to build a mini-prolog (or constraints or rules engine) in scala?Thanks( btw, I should have mentioned this in my first message to the mailing list, the programming guide for Scala, by itself, is a real gem. It helped clear up some functional programming concepts I didn't understand even after going through a couple of books)martin odersky wrote:Shahbaz Chaudhary wrote:Hi,I would like to know more about concurrency in Scala. Specifically I would like to know if it is possible to use a continuously updated (unbounded) list or stream, and operate on it the same way one might do operations against a basic list. The simplest example is perhaps a list which continuously inserts the temperature, a GUI component is updated whenever the temperature crosses a threshold:for(var x<- temperatureScanner)) yield x => if(x>72) statusbar="great!" else statusbar="terrible!" endSyncVar is indeed intended to be a building block for Mozart/Oz style concurrency. Based on it one should be able to do things like concurrent streams of values. AFAIK no one has yet done a high-level library based on this. But it should be possible: Given your example, one would need to define a SyncStream class which defines appropriate methods map, flatMap and filter. Each tail of the stream could me modelled by a SyncVar.My end goal is to have a small query engine which can operate not just on static data, but also on continuously streaming data.That looks like an interesting project!That looks like something Sean McDirmid is currently trying to do for the Eclipse plugin. But the technology he usesAnother example is a parser which checks for valid strings incrementally, so if "1 + 1" is a valid expression, an incremental parser responds in the following manner:"1" <=valid (perhaps some GUI component is green) "1 +" <=invalid (the same GUI component may now be set to red) "1 + 1" <=valid againis different. Cheers -- Martin
Date: July 29, 2006
From: "Raoul Duke" <raould@xxxxxxxxx>
In-reply-to:
<91a2ba3e0607281351i41af0118ncb7f5296e6ee9b08@xxxxxxxxxxxxxx>
References:
<91a2ba3e0607271141x44dde981j3b3f0d25ccaca035@xxxxxxxxxxxxxx> <44C93EB2.6070407@xxxxxxxxxxx> <87hd11q0m4.fsf@xxxxxxxxxxxxxxxxxx> <91a2ba3e0607281020h28141dbg6d0286bae0d98782@xxxxxxxxxxxxxx> <91a2ba3e0607281351i41af0118ncb7f5296e6ee9b08@xxxxxxxxxxxxxx>
http://therightabstractions.wikispaces.com/BSL is a quick brain-dump of my thoughts. I will try to expand further on them so people see what I'm getting at, and can say "that's impossible" or "that's stupid" or "that could be good" etc. sincerely. On 7/28/06, Raoul Duke <raould@xxxxxxxxx> wrote:
> I have some strong clear ideas about what I think would be good > aspects for a build system, but they (to me, at least) would require > a lot of work :-) I am going to try to get the ideas up on a wiki this > weekend and will post to the list in case anybody would care to look > at the thoughts. In the mean time, might I suggest calling this hypothetically excellent build-system-via-Scala-library "BSL" for "BSL Sucks Less"? :-) sincerely.
Date: July 29, 2006
From: Shahbaz Chaudhary <shahbazc@xxxxxxxxx>
In-reply-to:
<44C9DE9F.9040404@xxxxxxx>
References:
<eacep2$5sn$1@xxxxxxxxxxxxx> <44C9DE9F.9040404@xxxxxxx>
Are these SyncVars the same as logic variables used by logic and constraint programming languages? If so, how much and what kind of work is required to build a mini-prolog (or constraints or rules engine) in scala?
Thanks( btw, I should have mentioned this in my first message to the mailing list, the programming guide for Scala, by itself, is a real gem. It helped clear up some functional programming concepts I didn't understand even after going through a couple of books)
martin odersky wrote:
Shahbaz Chaudhary wrote:SyncVar is indeed intended to be a building block for Mozart/Oz style concurrency. Based on it one should be able to do things like concurrent streams of values. AFAIK no one has yet done a high-level library based on this. But it should be possible: Given your example, one would need to define a SyncStream class which defines appropriate methods map, flatMap and filter. Each tail of the stream could me modelled by a SyncVar.Hi,I would like to know more about concurrency in Scala. Specifically I would like to know if it is possible to use a continuously updated (unbounded) list or stream, and operate on it the same way one might do operations against a basic list. The simplest example is perhaps a list which continuously inserts the temperature, a GUI component is updated whenever the temperature crosses a threshold:for(var x<- temperatureScanner)) yield x => if(x>72) statusbar="great!" else statusbar="terrible!" endMy end goal is to have a small query engine which can operate not just on static data, but also on continuously streaming data.That looks like an interesting project!That looks like something Sean McDirmid is currently trying to do for the Eclipse plugin. But the technology he usesAnother example is a parser which checks for valid strings incrementally, so if "1 + 1" is a valid expression, an incremental parser responds in the following manner:"1" <=valid (perhaps some GUI component is green) "1 +" <=invalid (the same GUI component may now be set to red) "1 + 1" <=valid againis different. Cheers -- Martin
Date: July 29, 2006
From: Stefan Matthias Aust <nobody@xxxxxxxxx>
In-reply-to:
<1ba9d4a00607281313j66331fb7t3882f70cf0a9880c@xxxxxxxxxxxxxx>
References:
<91a2ba3e0607271141x44dde981j3b3f0d25ccaca035@xxxxxxxxxxxxxx> <44C93EB2.6070407@xxxxxxxxxxx> <87hd11q0m4.fsf@xxxxxxxxxxxxxxxxxx> <91a2ba3e0607281020h28141dbg6d0286bae0d98782@xxxxxxxxxxxxxx> <1ba9d4a00607281313j66331fb7t3882f70cf0a9880c@xxxxxxxxxxxxxx>
Steven Shaw schrieb: > Rake is good too. Ruby+make. Here's a nice presentation about the motivation behind Rake -> http://onestepback.org/articles/buildingwithrake/index.html, written by its creator, I think. -- Stefan Matthias Aust
Date: July 29, 2006
From: Sean Mc Dirmid <sean.mcdirmid@xxxxxxx>
Are we still having problems compiling under OS X? I know G4's are hopeless, but I haven't had any problems under the Intels. Sean ----- Original Message ----- From: Andrew Lentvorski <bsder@xxxxxxxxxxx> Date: Friday, July 28, 2006 6:52 pm Subject: OS X scratch compile failures > Here were some words from Apple about this: > > > Try the -Xint option to see if the problem goes away. If it > does, then > > it's likely a JIT compiler problem. If Scala is creating binary > > class-files itself, then this seems possible. -Xint will slow > things by > > about 10X. Also see the -Xfuture option. > > > > You might also turn on full bytecode validation. Scala might be > producing> mostly-valid bytecodes, but something subtle may be > tripping up the JITC. > > I can't recall the option or property to do this, though. Sorry. > > Just wanted to get this into the record. > > Thanks, > -a >
Date: July 28, 2006
From: Andrew Lentvorski <bsder@xxxxxxxxxxx>
In-reply-to:
<44CA6395.4080705@xxxxxxxxxxx>
References:
<44CA6395.4080705@xxxxxxxxxxx>
Andrew Lentvorski wrote:
Exception in thread "Thread-1" java.lang.AbstractMethodError:
As further information, this bug is repeatable on OS X and Windows. Here is the test code that I used:
<snip here>
package stest;
import scala.actors.multi.Process
case class Message;
class SrcThread extends Thread {
var dst : Process = null;
def setProcess(newDst : Process): unit = {
this.dst = newDst
}
override def run: unit = {
Thread.sleep(10000)
if (this.dst != null) {
dst ! Message
}
Thread.sleep(5000)
}
}
class DstProc extends Process {
override def run: unit = {
receiveWithin(5000) {
case unknown => {
System.out.println("Unknown message: "+unknown)
run
}
}
}
}
object ActorThreadCrash {
def main(args : Array[String]) : Unit = {
val srcThread = new SrcThread()
srcThread.start
val dstProc = new DstProc
dstProc.start
srcThread.setProcess(dstProc)
// Pause before shutdown
Thread.sleep(1000)
}
}
Date: July 28, 2006
From: "Raoul Duke" <raould@xxxxxxxxx>
In-reply-to:
<91a2ba3e0607281020h28141dbg6d0286bae0d98782@xxxxxxxxxxxxxx>
References:
<91a2ba3e0607271141x44dde981j3b3f0d25ccaca035@xxxxxxxxxxxxxx> <44C93EB2.6070407@xxxxxxxxxxx> <87hd11q0m4.fsf@xxxxxxxxxxxxxxxxxx> <91a2ba3e0607281020h28141dbg6d0286bae0d98782@xxxxxxxxxxxxxx>
I have some strong clear ideas about what I think would be good aspects for a build system, but they (to me, at least) would require a lot of work :-) I am going to try to get the ideas up on a wiki this weekend and will post to the list in case anybody would care to look at the thoughts.
In the mean time, might I suggest calling this hypothetically excellent build-system-via-Scala-library "BSL" for "BSL Sucks Less"? :-) sincerely.
Date: July 28, 2006
From: "Steven Shaw" <steshaw@xxxxxxxxx>
In-reply-to:
<91a2ba3e0607281020h28141dbg6d0286bae0d98782@xxxxxxxxxxxxxx>
References:
<91a2ba3e0607271141x44dde981j3b3f0d25ccaca035@xxxxxxxxxxxxxx> <44C93EB2.6070407@xxxxxxxxxxx> <87hd11q0m4.fsf@xxxxxxxxxxxxxxxxxx> <91a2ba3e0607281020h28141dbg6d0286bae0d98782@xxxxxxxxxxxxxx>
Rake is good too. Ruby+make.
Date: July 28, 2006
From: Andrew Lentvorski <bsder@xxxxxxxxxxx>
How do I send a message from a non-Process thread to a Process thread?What I have is an IO thread (extend Thread) which is selecting on incoming data. I would like to dispatch that data to different Process threads depending upon incoming address and port. However, when I try to send a message from my Thread to my Process I get:
Exception in thread "Thread-1" java.lang.AbstractMethodError: scala.actors.multi.TimerThread$WakedActor.$less(Ljava/lang/Object;Lscala/Function1;)Z
at scala.collection.mutable.PriorityQueue.fixUp(PriorityQueue.scala:29)
at
scala.collection.mutable.PriorityQueue.$plus$eq(PriorityQueue.scala:66)
at scala.actors.multi.TimerThread$.requestTimeout(TimerThread.scala:109)
at scala.actors.multi.MailBox$class.receiveWithin(MailBox.scala:135)
at scala.actors.multi.Process.receiveWithin(Process.scala:75)
at
com.soundcandi.stranscade.UDPPuncherDriver.loop(UDPPuncherDriver.scala:28)
at
com.soundcandi.stranscade.UDPPuncherDriver$$anonfun$0.apply(UDPPuncherDriver.scala:38)
at
com.soundcandi.stranscade.UDPPuncherDriver$$anonfun$0.apply(UDPPuncherDriver.scala:28)
at scala.actors.multi.Process.process(Process.scala:200)
at scala.actors.multi.Process.receiveMsg(Process.scala:236)
at scala.actors.multi.ReceiverTask.run(ReceiverTask.scala:19)
at scala.actors.multi.WorkerThread.run(WorkerThread.scala:34)
Any help would be appreciated. Forcing a select loop onto a receive
loop and maintaining transfer performance is going to be excruciating pain.
Thanks, -a
Date: July 28, 2006
From: "Raoul Duke" <raould@xxxxxxxxx>
In-reply-to:
<87hd11q0m4.fsf@xxxxxxxxxxxxxxxxxx>
References:
<91a2ba3e0607271141x44dde981j3b3f0d25ccaca035@xxxxxxxxxxxxxx> <44C93EB2.6070407@xxxxxxxxxxx> <87hd11q0m4.fsf@xxxxxxxxxxxxxxxxxx>
I can attest from personal use that "jam" is good, but Scons sounds like it might be better.
Something I fear is that there is a lot of personal taste involved in build systems. I think usability testing on a wide range of folks would be ideal. For example, I have had nothing but suffering with any "jam" based system and would never try to use them ever again. On the other hand, for small projects, Scons "just worked". Note, however, that I have read horror stories about Scons as well - basically there literally is no good build system out there as far as I can see. Everything falls down rather hard in some impressive ways. One basic thing, I think, would be to try to find out as much about how broken the already-existing systems are so you think architect to avoid those issues from the beginning. I have some strong clear ideas about what I think would be good aspects for a build system, but they (to me, at least) would require a lot of work :-) I am going to try to get the ideas up on a wiki this weekend and will post to the list in case anybody would care to look at the thoughts. sincerely.
Date: July 28, 2006
From: Andrew Lentvorski <bsder@xxxxxxxxxxx>
Here were some words from Apple about this:
Try the -Xint option to see if the problem goes away. If it does, then it's likely a JIT compiler problem. If Scala is creating binary class-files itself, then this seems possible. -Xint will slow things by about 10X. Also see the -Xfuture option. You might also turn on full bytecode validation. Scala might be producing mostly-valid bytecodes, but something subtle may be tripping up the JITC. I can't recall the option or property to do this, though. Sorry.
Just wanted to get this into the record. Thanks, -a
Date: July 28, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<91a2ba3e0607271141x44dde981j3b3f0d25ccaca035@xxxxxxxxxxxxxx> <44C93EB2.6070407@xxxxxxxxxxx>
Andrew Lentvorski <bsder@xxxxxxxxxxx> writes: > Well, I would start by looking at Scons. It is a build system written > in Python. Last I checked, they limited themselves to Python 1.5.2 > features, so it should run reasonably on Jython. >From reading the user manual, Scons strikes me as an excellent tool that already exists. I can attest from personal use that "jam" is good, but Scons sounds like it might be better. -Lex
Date: July 28, 2006
From: Lex Spoon <lex@xxxxxxxxxxxxx>
References:
<91a2ba3e0607271141x44dde981j3b3f0d25ccaca035@xxxxxxxxxxxxxx>
Raoul, there is nothing public right now, but an EPFL student Vincent
Pazeller is planning to build such a tool this winter.
There are several principles that make sense for such a tool. The
main ones IMHO are:
1. Use the language's support for language features such
as subroutines, lists, and maps. Every tool I have seen
that implements its own core language features does a
poor job. That includes make, ant, awk, and jam, just
to get started.
2. Be principled about the build/dependency graph. Specifically:
a. Have a reliable notion of dependencies built in; this
is the most important thing a build tool can help you with,
and it is essential for incremental rebuilds.
b. Support automatic dependency scanning directly; this should
not require an extra layer of coding.
c. Support circular dependencies and soft dependencies, so that
Latex files can be handled correctly.
There is much more one can say, but most build tools already break
even this short list. Impressively, ant breaks them all.
There are a lot of tools out there already. It would be cool to have
a Scala one just to experiment with Scala as a DSL host. However, I
also think that the vast majority of these tools just have not been
thought through very well, and that there is room to make a really
good build tool.
I have *not* thought about debugging, but that's an interesting
thought for future rounds of development.
Anyway, this is just a heads up. Time will tell how it goes!
-Lex
Date: July 28, 2006
From: martin odersky <martin.odersky@xxxxxxx>
In-reply-to:
<eacep2$5sn$1@xxxxxxxxxxxxx>
References:
<eacep2$5sn$1@xxxxxxxxxxxxx>
Shahbaz Chaudhary wrote:
SyncVar is indeed intended to be a building block for Mozart/Oz style concurrency. Based on it one should be able to do things like concurrent streams of values. AFAIK no one has yet done a high-level library based on this. But it should be possible: Given your example, one would need to define a SyncStream class which defines appropriate methods map, flatMap and filter. Each tail of the stream could me modelled by a SyncVar.Hi,I would like to know more about concurrency in Scala. Specifically I would like to know if it is possible to use a continuously updated (unbounded) list or stream, and operate on it the same way one might do operations against a basic list. The simplest example is perhaps a list which continuously inserts the temperature, a GUI component is updated whenever the temperature crosses a threshold:for(var x<- temperatureScanner)) yield x => if(x>72) statusbar="great!" else statusbar="terrible!" end
My end goal is to have a small query engine which can operate not just on static data, but also on continuously streaming data.
That looks like an interesting project!
That looks like something Sean McDirmid is currently trying to do for the Eclipse plugin. But the technology he usesAnother example is a parser which checks for valid strings incrementally, so if "1 + 1" is a valid expression, an incremental parser responds in the following manner:"1" <=valid (perhaps some GUI component is green) "1 +" <=invalid (the same GUI component may now be set to red) "1 + 1" <=valid again
is different. Cheers -- Martin
Date: July 28, 2006
From: Iulian Dragos <iulian.dragos@xxxxxxx>
In-reply-to:
<44C97AA4.2010906@xxxxxxxxxxx>
References:
<44C97AA4.2010906@xxxxxxxxxxx>
Andrew Lentvorski wrote:
I'd like to able to use the java.util.concurrent classes in Scala.How do I initialize them and call them? These are obviously using Java 1.5 generics, so I'm not sure how to do this.
Scalac has experimental code that interfaces with Java 5 generics. You have to enable it with -Xgenerics. I know there are some limitations, have a look here for some information about how Java 5 types are translated to Scala types: http://lamp.epfl.ch/~mihaylov/generics.html
Iulian
Date: July 28, 2006
From: Shahbaz Chaudhary <shahbazc@xxxxxxxxx>
Hi,I would like to know more about concurrency in Scala. Specifically I would like to know if it is possible to use a continuously updated (unbounded) list or stream, and operate on it the same way one might do operations against a basic list. The simplest example is perhaps a list which continuously inserts the temperature, a GUI component is updated whenever the temperature crosses a threshold:
for(var x<- temperatureScanner)) yield x => if(x>72) statusbar="great!" else statusbar="terrible!" end ... please excuse the made up syntax.(it gets more interesting if the values need to be continuously aggregated, or a continuously updated moving average is required)
My end goal is to have a small query engine which can operate not just on static data, but also on continuously streaming data.
Another example is a parser which checks for valid strings incrementally, so if "1 + 1" is a valid expression, an incremental parser responds in the following manner:
"1" <=valid (perhaps some GUI component is green) "1 +" <=invalid (the same GUI component may now be set to red) "1 + 1" <=valid againAs far as I can tell, the SyncVar functionality in Scala has to be extended to get Mozart/Oz type declarative concurrency, I'm just not sure how to do it in an elegant manner. If I'm wrong (i hope!) please tell me. Thanks.
Shahbaz
Date: July 28, 2006
From: Andrew Lentvorski <bsder@xxxxxxxxxxx>
I'd like to able to use the java.util.concurrent classes in Scala.How do I initialize them and call them? These are obviously using Java 1.5 generics, so I'm not sure how to do this.
Alternatively, an example of how to wrap them would be very nice. Thanks, -a
Date: July 27, 2006
From: "Raoul Duke" <raould@xxxxxxxxx>
In-reply-to:
<44C93EB2.6070407@xxxxxxxxxxx>
References:
<91a2ba3e0607271141x44dde981j3b3f0d25ccaca035@xxxxxxxxxxxxxx> <44C93EB2.6070407@xxxxxxxxxxx>
i will contribute another 'two cents' - the thing to watch out for are
all the problems that other systems have / re-create. I'd suggest
doing a lot of reading up on what problems folks have had with *all*
build systems, and think about what kind of architecture could be done
to avoid those. Example - if you realized that there was something
broken about the build system, and you wanted to update the engine,
how would your old "makefiles" work? If you can have it easily
upgraded, then you can allow for screwing things up and then fixing
them later. "{make,ant,scons,jam} considered harmful" usually turns up
amusing stories...
also, i'd suggest that it must be debugger friendly. if you have
declarative dependencies, think about how to make them debuggable.
having a set of libraries that people could use and experiment with
and patch as they come across weirdness, that is magically easily
upgradable w/out a lot of re-work done to the "makefiles" would i
think be the underlying magic that would make it successful where
others have sorta done well yet also done horribly in other respects.
sincerely.
On 7/27/06, Andrew Lentvorski <bsder@xxxxxxxxxxx> wrote:
Well, I would start by looking at Scons. It is a build system written in Python. Last I checked, they limited themselves to Python 1.5.2 features, so it should run reasonably on Jython. After that, you could probably start moving features to Scala little by little. -a
Date: July 27, 2006
From: Andrew Lentvorski <bsder@xxxxxxxxxxx>