[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: No message for 6 months
> 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.
I would suggest a mite extra time, given the near miss of '02.
Has anyone any comments on whether there should be a conference CD?
Has anyone found the online paper database on wotug.org useful?
> o KRoC channel commstime down to 16 nanosecs (on a 3.06 GHz. P4);
That sounds like cheating! Getting a faster processor and all...
> 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?
I suggest we look into implementing some of the library stuff proposed for
occam-3 all that time ago. It seemed to make sense then...
I would imagine the requirements were that:
- the library source can:
+ define processes that can be run while the library is in use,
+ interface functions/procedures that encapsulate the interface.
+ hide names that are not required outside the library
- the importer program/library can:
+ define the scope of the library process and its procedures
+ optionally choose not to import names that are not required (as in perl).
> o upgrading the public JCSP release to Quickstone's many improvements;
How is Quickstone doing?
> o oGraph - another attempt at a GUI/graphics toolset for KRoc. This
> All widget/graphics code (above X primitives) has been locally
> generated - thanks Fred (who has nearly written up)!
Sounds interesting, but an equivalent to Xt is a long way from KDE :( Is there
any way of reusing higher level stuff like Gnome or Qt code, or are the
methodologies too different?
> 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 ...
As I think more and more about proprity, I am more and more convinced that it
is the message that has priority, not the process. The easy way of grouping
messages into a useful form is to give channel ends the priority, not the
> 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
> Previous suggestions:
> occam-M (mobile occam) [guess not ... sigh ]
> occam-D (dynamic occam) [ ditto ]
Fails the "contains occam" test.
> Breakspeare [the beer at CPA 2002]
> Butts [ ditto ]
> msp (mobile sequential processes)
Possible, but I'm not sure.
Razor [as in Occam's]
Pluralitas [the first word from the latin for 'occams razor', and means
Software engineer and technical writer.