Subject: Re: Scala paper: Actors that Unify Threads and Events - msg#00522

List: lang.scala

Date: Prev Next Index Thread: Prev Next Index

Terrance Sullivan wrote:
> As I recall from reading Philipp's early paper and the sense Erlang the
> language may have also possibly influenced his work on Scala Actors

Indeed, Scala's actors were influenced to a large extent by Erlang.

> (?), would suggest taking a look at YAWS (Yet Another Web Server) done
> in an Erlang/Actor style with interesting performance and robustness
> characteristics or YXA which is a similarly implemented instance of
> SIP. Certainly, the 15+ years Ericsson has acquired using Erlang/OTP on
> their production ATM switches would also suggest that this is a well
> founded technique.. Equally one could back track to some of the
> material at the Erlang.org site..

I agree. Existing Erlang work might be very helpful to look at. After
all, the programming models are very similar. I also recommend the
Erlang book ("Concurrent Programming in Erlang", 2nd ed. by Joe
Armstrong et al.). It contains a wealth of programming examples for
actor-style message passing concurrency. Most of them should be
straight-forward to write using Scala actors.

On the other hand, I fully agree with Warren that a comprehensive
example in Scala would be a very good thing.

Actually, some larger programs have been developed in our lab.
Unfortunately, they have to be re-written since the actor library has
been re-designed in the meantime. I'll take a look and see how much work
it is to update the old code.

Another point regarding "massive scalability". I think it is important
to note that large numbers of actors are not only interesting for
network applications such as web or Jabber servers (for connections/user
sessions).

Lightweight actors are also crucial if you intend to build general
abstractions on top of them. As a rather radical example, imagine
replacing all your normal objects with actors...

Cheers,
Philipp

> /Terry
>
> On 29-Jan-07, at 12:32 PM, Warren Henning wrote:
>
>> On 1/29/07, Philipp Haller <philipp.haller@xxxxxxx> wrote:
>>
>>> Feedback is very welcome!
>>
>>
>> What would help me the most in understanding actors is a practical
>> example that clearly shows how the actor system can be used to create
>> real-world massively scalable systems. What would be nice is a
>> complete, realistic program, not too short but not too long, either,
>> that I can compile and run involving something, say, network-related,
>> that I can try out on my home machine and play around with.
>>
>> Apparently a tutorial of some kind is underway on the actors library
>> and I eagerly await it.
>>
>> Warren Henning
>>
>

Was this page helpful?

Thread at a glance:

Previous Message by Date: click to view message preview

Re: How do I use DTD's with Scala 2.3.0's XML object literals?

Raphael,For the most part i went out of my way to implement the spec as it is... and I don't claim an xml object conforms to dtd. But for all situations where it matters (when you serialize something out, actually producing an XML document), you can have your DTD (and validate against it, too). Processing instructions are supported.Could you be more specific in your proposal in what you would like to see changed? I offered two alternatives in my preceding mail, which I both don't like. I am not sure which one you would prefer? cheers,BurakOn 1/30/07, Raphael James Cohn <raphaelcohn@xxxxxxxxx> wrote: Burak, Thank you for your comprehensive reply. I agree with you; DTDs are a nuisance, and they, along with processing instructions, make life for API developers hard, and, potentially users ("one has to go through the docElem method first, which one may find confusing and inconvenient"). However, if that's the XML spec, then we should stick with it. XML _is _ awkward to work with, primarily because its data structures are completely unlike those in use in most moden programming languages. That's why other pragmatic data forms are popular in the agile community (eg JSON and YAML; others argue that augmented TSV is good for tabular data). The work you've done with Scala makes it a whole lot easier to work with, and I think you should be very proud of that. I understand why you may not want to change this behaviour, but please be cautious. If you don't completely implement the spec, put it up in lights. Why? Because it violates the Principal of Least Surprise. Perhaps we could have at least have a sensible compiler message, eg "Processing instructions and DOCTYPEs are not supported? After all, people (including me) are going to just paste in their XML... It should also be very hard for a user to use a library and produce an invalid document. Any means by which it can be done (and which won't be supported) should be probably be noted. For example, XHTML is not XHTML 'officially' without the DTD. Whilst this might seem moot, there is at least two instances I can think of: IE6 and Excel's interpretation of CSS attributes. In both, the presence or absence of the DTD causes rendering changes! On another note, I was thinking it would be nice to have a way to tell the compiler to ignore whitespace. This matters in some XML documents, eg Jetty configuration files. I'd also love to be able to extend this syntax to general string and text templating. I think David Pollak referred to this. With multi-line strings, this would be a killer app. It would reduce to about 2 days what has just taken me 2 weeks in Java... Ta for the prompt reply, Raph ----- Original Message ----From: Burak Emir < burak.emir@xxxxxxxxx>To: Raphael James Cohn <raphaelcohn@xxxxxxxxx>Cc: scala@xxxxxxxxxxxxxxSent: Tuesday, 30 January, 2007 9:46:46 AMSubject: Re: How do I use DTD's with Scala 2.3.0's XML object literals?Hi Raphael, On 1/29/07, Raphael James Cohn < raphaelcohn@xxxxxxxxx> wrote: Hi,I'm using scala's wickedly cool XML object literals (great idea - no more need for Freemarker or Velocity for XML - could we have them for other things, too,please... like a compile time templating engine!) to generate XHTML reports for rehersal. To create valid XHTML, I need to have a DTD before the first element. However, the compiler complains if I have a method like this:- private def template(category: TestCategory) =<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"" http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> This won't work because I consciously left out DTDs from the parser. The biggest trouble is that DTDs would mess up Scala's "data model" (the XML people's slang for XML object mapping). They may only appear at the top :/ So there is a class scala.xml.Document (http://www.scala-lang.org/docu/files/api/scala/xml/Document.html ) which can contains XML nodes but is not regarded as a node itself. There are routines for writing out XML with a prefixed DTD declaration though, see Utility.toXML <head><meta http-equiv="content-type" content="application/xhtml+xml; charset=UTF-8"/> <title>{category.name} Testing Results</title><style type="text/css" media="all"> (SNIPPED lots of content)Removing the DTD causes it to compile.Does anybody know why?Additionally, does the compiler or API understand XML and HTML literals? Is ther a utility method I could use to convert strings? The compiler parses your XML and gives you the objects, not more, not less (XHTML is ok, plain HTML is not).Of course, the API offers methods for parsing XML, the easiest being ( http://www.scala-lang.org/docu/files/api/scala/xml/parsing/ConstructingParser.html)import scala.io.Sourceimport scala.xml.parsing.ConstructingParserval src = "" // there's also fromFile, fromInputStream, fromURL... val prs = ConstructingParser.fromSource(src , true/*preserve whitespace*/)val doc = prs.document // parses the documentval root= doc.docElem // the content nodeIf you know that your source does not have prologue (DTD, processing instructions or comments), you can directly tell the parser to grap the content node like this val root = prs.element(scala.xml.TopScope)(0) // parse an element, assuming no namespace bindings.The (0) at the end is necessary to get the "first" element, because the routine is designed to return a node sequence in some cases. Many thanksRaphFor information, the compile error (I'm using scalac in ant, with Scala 2.3.0) is:- I don't think we would add support for parsing the DTD, it is very easy to achieve, but from a design point of view it adds nothing but causes trouble. Certainly we don't want to have scala.xml.Document a node (something that can appear everywhere in an xml document).The alternative, making the parser clever enough to understand that something with a docype declaration is not a node, but a scala.xml.Document is also annoying, because then in order to do anything with it (traverse,transform,match,xpath...), one has to go through the docElem method first, which one may find confusing and inconvenient. cheers, Burak-- Burak EmirResearch Assistant / PhD CandidateProgramming Methods GroupEPFL, 1015 Lausanne, Switzerland http://lamp.epfl.ch/~emir Yahoo! Photos â NEW, now offering a quality print service from just 7p a photo. -- Burak EmirResearch Assistant / PhD CandidateProgramming Methods GroupEPFL, 1015 Lausanne, Switzerlandhttp://lamp.epfl.ch/~emir

Next Message by Date: click to view message preview

Re: Bug Report (#292): Java Annotations not fully available at runtime

Hello again,Is there a better place to discuss a contributed bug report? I like the list to be the focus of discussion, but didn't really want to just comment on an uninteresting bug here. I couldn't find a comment or feedback on the page though... My point: The getAnnotation is still failing for me even after I tried changing Annotation names (to avoid potential class with Some).I'm running inside Eclipse with Scala plugin version 2.4.9. Any ideas? Is it really just broken for me?Thanks,John HeintzOn 1/12/07, John D. Heintz <jheintz@xxxxxxxxx > wrote:Hello all,I couldn't figure out how to attach files to a bug report so I'm mailing two Eclipse projects in a zip file. Hope that's not a problem (let me know if it is, of course) The bug report: http://scala-webapps.epfl.ch/bugtracking/contribs/display.do?id=292 The short story is that field.getAnnotation(Some.class) returns null, instead of the Annotation object.I used the target:jvm-1.5 option, and indeed the Annotation is found if field.getDeclaredAnnotations() is used instead...John -- John D. Heintz Principal ConsultantNew Aspects of SoftwareAustin, TX(512) 633-1198 -- John D. HeintzPrincipal ConsultantNew Aspects of SoftwareAustin, TX(512) 633-1198

Previous Message by Thread: click to view message preview

Re: Scala paper: Actors that Unify Threads and Events

As I recall from reading Philipp's early paper and the sense Erlang the language may have also possibly influenced his work on Scala Actors (?), would suggest taking a look at YAWS (Yet Another Web Server) done in an Erlang/Actor style with interesting performance and robustness characteristics or YXA which is a similarly implemented instance of SIP. Certainly, the 15+ years Ericsson has acquired using Erlang/OTP on their production ATM switches would also suggest that this is a well founded technique.. Equally one could back track to some of the material at the Erlang.org site.. /Terry On 29-Jan-07, at 12:32 PM, Warren Henning wrote: On 1/29/07, Philipp Haller <philipp.haller@xxxxxxx> wrote: Feedback is very welcome! What would help me the most in understanding actors is a practical example that clearly shows how the actor system can be used to create real-world massively scalable systems. What would be nice is a complete, realistic program, not too short but not too long, either, that I can compile and run involving something, say, network-related, that I can try out on my home machine and play around with. Apparently a tutorial of some kind is underway on the actors library and I eagerly await it. Warren Henning

Next Message by Thread: click to view message preview

Re: Scala paper: Actors that Unify Threads and Events

Philipp, Does there exist any sample code for using JXTA for transport between Scala Actors? Thanks, David PS -- The more time I spend with Actors, the more I like them. Thanks for doing a rockin' job on them! On Jan 30, 2007, at 5:46 AM, Philipp Haller wrote: Terrance Sullivan wrote: As I recall from reading Philipp's early paper and the sense Erlang the language may have also possibly influenced his work on Scala Actors Indeed, Scala's actors were influenced to a large extent by Erlang. (?), would suggest taking a look at YAWS (Yet Another Web Server) done in an Erlang/Actor style with interesting performance and robustness characteristics or YXA which is a similarly implemented instance of SIP. Certainly, the 15+ years Ericsson has acquired using Erlang/ OTP on their production ATM switches would also suggest that this is a well founded technique.. Equally one could back track to some of the material at the Erlang.org site.. I agree. Existing Erlang work might be very helpful to look at. After all, the programming models are very similar. I also recommend the Erlang book ("Concurrent Programming in Erlang", 2nd ed. by Joe Armstrong et al.). It contains a wealth of programming examples for actor-style message passing concurrency. Most of them should be straight-forward to write using Scala actors. On the other hand, I fully agree with Warren that a comprehensive example in Scala would be a very good thing. Actually, some larger programs have been developed in our lab. Unfortunately, they have to be re-written since the actor library has been re-designed in the meantime. I'll take a look and see how much work it is to update the old code. Another point regarding "massive scalability". I think it is important to note that large numbers of actors are not only interesting for network applications such as web or Jabber servers (for connections/ user sessions). Lightweight actors are also crucial if you intend to build general abstractions on top of them. As a rather radical example, imagine replacing all your normal objects with actors... Cheers, Philipp /Terry On 29-Jan-07, at 12:32 PM, Warren Henning wrote: On 1/29/07, Philipp Haller <philipp.haller@xxxxxxx> wrote: Feedback is very welcome! What would help me the most in understanding actors is a practical example that clearly shows how the actor system can be used to create real-world massively scalable systems. What would be nice is a complete, realistic program, not too short but not too long, either, that I can compile and run involving something, say, network- related, that I can try out on my home machine and play around with. Apparently a tutorial of some kind is underway on the actors library and I eagerly await it. Warren Henning -- David Pollak http://blog.lostlake.org

Loading Comments...