Did SERC at RMIT go away?

[Ulf Wiger]

On Mon, 26 Jul 2004 22:03:53 -0700 (PDT), Eli Liang <eliliang@REDACTED> 
wrote:

> Thanks for this link.  I was able to download and print out the book.  
> www.serc.rmit.edu.au is still down for me though, although it matters 
> less to me now though.
>
> I have three unrelated questions:
>
> 1) The usual timer built into Erlang is on a millisecond granularity 
> (... after XXX ...).  What would I use if I needed a microsecond 
> granularity timer?  Is there such a thing in Erlang?

No. erlang:now() will give you timestamps with microsecond granularity
(accuracy will depend on the underlying operating system and hardware),
but the scheduler in Erlang doesn't operate with microsecond precision.
This includes the timer wheel, AFAIK. Not even millisecond timers can
be guaranteed to fire at the exact millisecond specified -- for most
Erlang programs currently being written, this is not an issue.


> 2) In the Programming Rules and Convention guide, it discusses the use 
> of hardware device drivers with Erlang-like interfaces.  Are there any 
> open source examples of such hardware drivers around that I can look at?

I'll pass on that one.  (:



> 3) Is there any specification methods being used in Erlang to develop 
> large systems?  UML doesn't seem appropriate for Erlang.  I've found 
> Huch's "Erlang Specification Method" and Castro's "Event Modeling 
> Language", but I don't seem to find much about either.  (In fact, I 
> can't seem to even unpack the former as it seems to be corrupted.  
> Anyone have a plain postscript file of this?)

One used to be able to say that SDL is at least a halfway-decent way
of modeling applications to be written in Erlang (even if Erlang in
some areas actually has a higher abstraction level than SDL.) But
nowadays, SDL has really been integrated into UML. One conclusion of
this might be that UML 2.0 is more suited to Erlang development than
UML 1.5 (it's undoubtably so); another is that SDL now _less_ suited
to Erlang development.  ;)

I believe that modeling support for functional languages is a problem
area, and so is modeling support for concurrency (UML has some
fundamental flaws in this regard.) This is a problem, but I personally
believe that it's amply offset by the productivity and clarity gains
that come from using Erlang. Others might disagree...

/Uffe
-- 
Ulf Wiger