Re: No message for 6 months

["Ruth Ivimey-Cook" <Ruth.Ivimey-Cook@xxxxxxxxxx>]

P.H.Welch said:
> 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
process.

> 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        ]
Too geeky
>   really-very-very-fast-and-very-very-safe-and-very-very-dynamic
JPS.
>   msp (mobile sequential processes)
Possible, but I'm not sure.
>   kroc
Quite possible....

My suggestions:

 Razor            [as in Occam's]
 Pluralitas       [the first word from the latin for 'occams razor', and means
"plurality"]


Regards

Ruth.


-- 
Ruth Ivimey-Cook
Software engineer and technical writer.