Re: son of occam (was: Re: JCSP, CSP Networking, and other some other points)

[Matt Pedersen <matt@xxxxxxxxxxxxxxxxxxxx>]

Larry,

we are working on a 'new language' currently called ProcessJ which is
occam with a java syntex - semicolons, { } and all the stuff that people
'like' in a language - its is non oo, process oriented and pretty much
like oocam - we are working on code geenrators to translate ProcessJ to
occam-pi, java/JCSP and C with MPI.

with a little luck we should be able to talk about it some more at
this years CPA.
http://www.egr.unlv.edu/~matt/research/Joccam-content.html

(not it was called Joccam to begin with and was recently renamed to
ProcessJ) - there is more info to come shortly!

Matt

+-----------------------------------------------------------------------+
| Jan 'Matt' Pedersen, Ph.D.                 Office: TBE B384           |
| Assistant Professor                        E-mail: matt@xxxxxxxxxxx   |
| School of Computer Science                 Phone : +1 (702) 895-2557  |
| University of Nevada at Las Vegas          Fax   : +1 (702) 895-2639  |
| Las Vegas, NV, 89154-4019                  Home  : +1 (702) 792 2580  |
|             Home Page: http://www.cs.unlv.edu/~matt                   |
+-----------------------------------------------------------------------+

On Sun, 2 Aug 2009, Larry Dickson wrote:

> Hi all,
>
> I'm going to trail off this thread and change its name because I'm
> changing the subject a bit. Everybody seems to agree that occam is
> "dead" but is still the best way to do things, which is of course
> ironic. I have long wanted to move it in a more practical direction
> while keeping its cleanness and simplicity (NO OO), and now may have a
> business route to that (more on that later). I want to get some
> opinions from the list.
>
> (1) What should it look like - traditional occam (Python, etc) with
> indents and significant line-feeds, or C (java, etc) with semicolons?
>
> (2) What should an associated scripting language look like? I want to
> control everything from soup to nuts ultimately, which means bootup too.
>
> (3) What should get first attention as the analogue of the hardware
> link? USB? TCP/IP?
>
> (4) Is anyone doing a flavor of Transterpreter or similar project but
> retaining the full-interrupt Priority 0 of the Transputer?
>
> Larry Dickson
>
>
> On May 18, 2009, at 6:11 AM, Eric Verhulst wrote:
>
> >
> > Dear Chris,
> >
> > Occam might be dead as an industrial language but its legacy lives on.
> >
> > In attachment a screen dump from OpenVE, the GUI front-end for
> > OpenComRTOS.
> > We call this a pragmatic superset of CSP but the programming style is
> > similar. The current version is in C but C++ wrappers should not be a
> > problem.
> >
> > The problem shown on the screen dump is a parallel matrix
> > multiplication
> > even if OpenComRTOS was more designed for embedded applications (incl.
> > heterogeneous targets). You can see this in the topology diagram (our
> > standard demo mixes a Win32, a linux, a Leon 3 and a MicroBlaze). The
> > current implementation limit is 64K nodes, but granted, one would
> > need to
> > have a dedicated tool for handling such large networks. Given that all
> > meta-data is in XML format, it doen't need to have a GUI. For
> > performance
> > reasons, a better hardware would help as well, but if that' s
> > available,
> > it's a matter of porting a linkdriver.
> >
> > You can try out the WIN32 (and soon Linux) version for free by
> > downloading
> > it for free from our website. This version also emulates multi-node
> > targets.
> >
> > Best regards,
> >
> > Eric Verhulst
> >
> > ----------------------  FROM : --------------------------
> >   Eric.Verhulst@xxxxxxxxxxxxx
> >   Skype me at: ericverhulstskype
> >   Mob. +32 477 608339
> >   "Push the button High Reliability"
> >   http://www.altreonic.com
> > -----------------------------------------------------------
> > "From Deep Space to Deep Sea"
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > -----Original Message-----
> > From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of
> > P.H.Welch
> > Sent: donderdag 14 mei 2009 5:10
> > To: Ruth.Ivimey-Cook@xxxxxxxxxx; tjoccam@xxxxxxxxxxx
> > Cc: A.T.Sampson@xxxxxxxxxx; java-threads@xxxxxxxxxx; lewando@xxxxxxxxxxxxx
> > ;
> > occam-com@xxxxxxxxxx
> > Subject: Re: JCSP, CSP Networking, and other some other points
> >
> >
> > Hi,
> >
> > Just forwarding a posting from Chris Jones on the above ...
> >
> > Peter.
> >
> > ---------------------------------------------------------------------------
> > From: "Jones, Chris C (UK Warton)" <Chris.C.Jones@xxxxxxxxxxxxxx>
> > Sent: 08 May 2009 13:46
> > To: 'Larry Dickson'
> > Subject: RE: JCSP, CSP Networking, and other some other points
> >
> >
> > Larry,
> >
> > Sorry I do not know how to send this directly to the mailing thingy.
> >
> > You interest me greatly on the demise or potential future for occam.
> >
> > We would still be using occam if we could.  Many years ago, we
> > rewrote a
> > large code for simulating electromagneitc effects on aircraft -
> > particularly
> > lightning - into occam (it is about 140,000 lines now and was
> > proably about
> > 100,000 then).  We first analysed the main core of the algorithm in
> > CSP.  Of
> > course, we had transputers and the wonderful TDS.
> > It worked, was easy to maintain and continue to develop and we had
> > more
> > fundamental proof of the correctness of the implementation than we
> > can now
> > dream of.  Sadly, our T9000 machine never actually happened and we
> > accepted
> > parallel PowerPC processors with transputers handling the comms
> > instead.
> > Even more sadly, we had to rewrite our code back into the original
> > Fortran,
> > though by having gone through occam, it was much easier and bug free
> > than
> > the original had been.  That code would still be occam if we had not
> > been
> > forced to reveert to Fortran for lack of occam implementations on
> > other
> > commodity processors.
> >
> > Even now, we would write some applications in occam were there a
> > reasonable
> > way of programming a large parallel computer - we currently run 128
> > quad
> > cores with a Quadrics switch.  There are some issues
> > though:
> >
> > 1.  Lack of occam knowledge - actually this is far worse than it
> > sounds.
> > We lack parallel computing knowledge at a fundamental level.  Making
> > cals to
> > MPI libraries is not the same thing.
> >
> > 2.  Personnally, I'd like to see a development systems akin to the
> > old TDS -
> > I am so old I actually do not like the modern programme writing
> > pardigm with
> > thousnads of interlinked filelets requiring a compendium of flow
> > charts and
> > dependency diagrams and spreadsheets to track effects.
> > I am actually in a day-mare trying to sort out such a problem at the
> > moment.
> >
> > 3.  Access to standard libraries like LINPACK and NAG.  This may be
> > a solved
> > problem, I haven't looked recently.
> >
> > 4.  We would have to be able to identify an organisation that would
> > take
> > responsibility for supporting the compilers.
> >
> > The lack of knowledge of occam is an interesting one in its own
> > right since
> > we are moving towards this same situation on Fortran.  My daughter
> > has been
> > searching for a job in or around Edinburgh having completed her
> > physics
> > degree.  She found plenty of jobs requiring Fortran knowledge but
> > none for
> > Java.  Unfortunately the only programming language the university
> > would
> > teach was Java.  I had a scan across a range on UK universities and
> > found
> > the same was generally true - even including the Opne University.  I
> > draw
> > the concluding that Sun is trying to do with Java what it did
> > decades ago
> > for the early Sun workstations.
> > Edinburgh's stated justificaion was transportability, and then gave
> > out
> > homework involving proprietary and University only libraries!
> >
> > As a matter of interest, we have the following numbers of people
> > profient in
> > respective languages:
> >
> > Fortran   3
> > C         5
> > C++       1
> > Matlab    2
> > Tcl       3
> > PERL      1
> > Python    1
> > Pascal    2
> > Occam     1
> >
> > Java isn't even on the list and is not going to be for the forseealbe
> > future.  Even the new codes we are looking to develop over the next
> > 5 years
> > will all be largely Fortran.
> >
> > I would love to have transputers available again.  The pain of
> > making codes
> > run let alone well on Intel or AMD multi-core processors is not
> > pleasant.
> > Occam would be used here if we could obtain from its use it's primary
> > benefit of programming large multi processor machines.  I might even
> > realise
> > my dream of hybrid data and functional parallelism.  But this will not
> > happen till we have a reasonable way of launching code on multiple
> > processors from a perameterised architecture description - as we
> > could from
> > the old TDS.
> >
> >
> > Regards,
> > Chris.
> >
> >
> >
> > Dr Christopher C R Jones C.Eng. FIET
> > Technologist Consultant
> > BAE SYSTEMS (Military Air Solutions)
> > Warton Aerodrome
> > Preston
> > Lancashire PR4 1AX
> > * tel: 01772 854625
> > * fax: 01772 855262
> > * e-mail: chris.c.jones@xxxxxxxxxxxxxx
> > BAE Systems (Operations) Limited
> > Registered Office: Warwick House, PO Box 87, Farnborough Aerospace
> > Centre,
> > Farnborough, Hants, GU14 6YU, UK Registered in England & Wales
> > No: 1996687 Exported from the United Kingdom under the terms of the UK
> > Export Control Act 2002 (DEAL No ####)
> > <OpenComRTOS Matrix multiplication.pdf>
>
>
>