Re: No message for 6 months

["P.H.Welch" <P.H.Welch@xxxxxxxxx>]

> Have heard nothing re CPA 2003...

This was fixed ages ago - sorry, about time we announced it!

CPA 2003 will be on 7-10 Sept, 2003, at the University of Twente,
the Netherlands.  Our hosts are Jan Broenink and his team.

Jan is setting up the web site for CPA 2003.  Meanwhile, I am told
we will be at the conference hotel on the university campus - and
it looks really neat:

  http://www.drienerburght.nl/english/index.htm

CPA-2003 is a week earlier than last year's meeting.  I suspect
that submission/notification/camera-ready deadlines will therefore
be brought forward also by one week - i.e.

  Submission of full papers:      Monday, 2nd. June
  Tutorial / workshop proposals:  Monday, 2nd. June
  Notification of acceptance:     Monday, 30th. June
  Camera-ready copy:              Monday, 14th. July

But these dates have to be confirmed.

> Ping ...

Well ... there's lots going on at Kent, :).  Too darned busy with
teaching and chasing money though to communicate :(.  On-going:

  o KRoC - the Network Edition (with similar facilities to
    Quickstone's JCSP Network Edition - www.quickstone.com);

  o mobile *processes* for KRoC occam;

  o semantics for the above (another CSP extension);

  o continuing niggles over the semantics of PRI ALT!

  o KRoC channel commstime down to 16 nanosecs (on a 3.06 GHz. P4);

  o Raw Metal occam eXperiment (RMoX) - a native all-occam OS and/or
    embedded system harness for self-booting raw occam, currently
    limited to i86 processors.  No underlying Linux or Windows.
    32 priority levels.  Interrupts mapped to channel communications.
    Interrupt response times in nanoseconds.  Memory protection
    for untrusted utilities (e.g. C programs).  All-occam network
    driver processes.  The software architecture makes heavy use
    of mobile channel-ends, reported at CPA 2002 and introduced
    in KRoC 1.3.3;
  
  o oDoc - an occam html-generating documentaion tool, similar to
    javadoc.  This highlights a real need for some formal library
    mechanism - where "formal" means built into the language.

    IMPORTANT: does anyone have a proposal for such a library mechanism?
    Ours is loosely based on Java packages.  Is that a good idea?
  
  o upgrading the public JCSP release to Quickstone's many improvements;

  o oGraph - another attempt at a GUI/graphics toolset for KRoc.  This
    time, we're not using TCL/Tk or the GIMP toolkit - neither of which
    were totally robust when misused the highly concurrent way required
    by occam.  All widget/graphics code (above X primitives) has been
    locally generated - thanks Fred (who has nearly written up)!
  
  o C++CSP - a JCSP-like API for C++, with an occam/CCSP-like fast kernel;

  o occam -> JVM compiler: write in occam / utilise any Java library.

Credits: Mario Schweigler (KRoC-net), Fred Barnes (everything, of course,
but especially mobile processes, faster KRoC kernels, RMoX and oGraph),
Christian Jacobsen (RMoX, other mobile channel experiments), Jim Woodcock
and Ana Cavalcanti and Alistair McEwan and Xinbei Tang (semantics and
Grand Challenge applications), Ramsay Taylor and Adam Sampson (RMoX), 
Jonathon Stott (oGraph), Peter Maley (oDoc), Neil Brown (C++CSP),
James Bielby and Tom Shackell (occam -> JVM) ...

Will post something soon about why channel *ends* are so important and
why we are changing (actually have changed!) occam and JCSP to enforce
this point.  Yes, we are dictators ... but we try to justify ...

================================
MOST IMPORTANT OF ALL - PROBABLY
================================

We really need a new name for the extended occam language!  Just try
getting anything on "occam" past research council reviewers or panels.
It only takes one to black-ball.  Example: from two rather famous UK
Computer Science Professors reviewing the above research (without
reading anything published about it) - "the work of this research group
is focussed on old technolgy (CSP and occam) ... they need to change
the focus of their work".  Yes, sir.

So, come on folks, we need a new name so that there's a better chance
that uninformed prejudice will not autonmatically be invoked.  Make
them read something to realise what is being proposed!

Previous suggestions:

  occam-M  (mobile occam)    [guess not ... sigh  ]
  occam-D  (dynamic occam)   [       ditto        ]
  Breakspeare                [the beer at CPA 2002]
  Butts                      [       ditto        ]
  autonomy
  really-very-very-fast-and-very-very-safe-and-very-very-dynamic
  msp (mobile sequential processes)
  mobile
  kroc

Well - someone did say things had been too quiet ... ;)

Peter.