gmane.comp.lang.concurrency.pop.devel

Re: Little occam advice

Carl Ritson — 2011-01-27T21:22:51

Hi Kevin,



Unfortunately this use of mobile records (mobiles in mobile records) is not
supported by the present compiler.
The common working solution is to have separate arrays for the mobile
components, as below.

  PROC link.manager(...)
    MOBILE [100]NODE.ID nodes:
    MOBILE []MOBILE []BYTE names:
    MOBILE []MOBILE []BYTE protocols:
    MOBILE []MOBILE []BYTE address:

Which obviously makes the code a lot more bulky, but is probably the only
way to implement your example with the present compiler.

Cheers,

Carl

Little occam advice

Chalmers, Kevin — 2011-01-27T15:29:13

Hi folks,

I'm having a little problem trying to compile an occam-pi program. The error I'm getting is "Error 1 in routine loadmobile - ARRAYITEM for unsupported MOBILE type". A brief snippet of what I'm trying to do:

DATA TYPE NODE.ID
MOBILE RECORD
MOBILE []BYTE name:
MOBILE []BYTE protocol:
MOBILE []BYTE address:
INT64 attr1:
INT64 attr2:
INT32 attr3:
:

PROC link.manager(...)
MOBILE [100]NODE.ID nodes:
-- ...
SEQ
-- ...
input ? index; node.id
nodes[index] := node.id -- ******

The compiler doesn't seem to like the starred line - assigning a mobile value to an array. For mobile channel ends, not a problem, but mobile data types it just doesn't seem to like it. Any advice?

Cheers,

Kevin

Dr Kevin Chalmers PhD BEng(Hons) MBCS
Programme Leader Interactive Entertainment and Games Development
School of Computing
Edinburgh Napier University
Merchiston Campus
Edinburgh EH10 5DT
T 0131 455 2484
E k.chalmers-KJSHoIMUuCKFxr2TtlUqVg< at >public.gmane.org

Edinburgh Napier University is Edinburgh's top university for graduate employability (HESA 2010), and proud winner of the Queen's Anniversary Prize for Higher and Further Education 2009, awarded for innovative housing construction for environmental benefit and quality of life.

This message is intended for the addressee(s) only
and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects.
Edinburgh Napier University does not accept liability for any loss or
damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.

Edinburgh Napier University is a registered Scottish
charity.
Registration number SC018373

Re: compiling/linking occam-pi code in windows 7

Matt Jadud — 2010-12-15T12:42:39

Hi Vangelis,

I suspect this has to do with paths, and it probably isn't your fault
(eg. Java installation, etc.). Our build/install process is new from
the summer, and we occasionally find something like this. (What is odd
is that we haven't seen this already...)

We'll take a look. The Transterpreter auto-updates on Mac and Windows,
so once a fix is pushed, you'll get the update and things should be
fine.

Sorry for the inconvenience.

Cheers,
Matt

compiling/linking occam-pi code in windows 7

2010-12-15T11:25:40

 I have just downloaded the Transterpreter for both Windows and Mac OSX. I have
been playing with Arduino for quite a time and I wanted to see what OCCAM can
offer as an alternative.

I have got a little problem in compiling occam-pi code in win 7 and not be able
to find any relevant open forum to post my question, I decided to send it here.
My apologies for any inconvenience.

For testing the Arduino module, I used the Arduino UNO board on both Windows 7
and Mac OSX and it works perfectly well.   Then I wrote the following  occam
code to test the Desktop (TVM) and it works without problem on Mac OSX but it
gives an error in Windows 7.

#INCLUDE "course.module"

PROC main (CHAN BYTE scr!)
 SEQ
   out.string("Hello World!*n", 0, scr!)
   scr ! 'B'
   scr ! '*n'
   scr ! '*n'
   SEQ i = 1 FOR 10
     SEQ
       out.int(i, 0, scr!)
       scr ! 'A'
       scr ! '*n'
:

The error I get in Win 7 is the following:

Compiling: C:\Users\vangelis\Documents\DEVELOPMENT\Occam\test2.occ occbuild:
Command failed: C:\Programs\Transterpreter\bin\plinker.exe -o test2.tbc
C:\Programs\Transterpreter\posix\tvm\lib\forall.lib test2.tce  
compile exited with error code: 1

running again
C:\Programs\Transterpreter\bin\plinker.exe -o test2.tbc
C:\Programs\Transterpreter\posix\tvm\lib\forall.lib test2.tce

in a windows command shell, I get the following error:

Undefined global reference out.string at script/plinker.pl line 2789.

If I am not wrong out.string is declared in "course.module" but for some reason
the linker cannot find it. 

I do not know if this is related to my java installation. But on the other hand
I use jEdit for java development without any problem.

When I comment the two “out.XXX “ lines (see the following), it compiles
without any error in Win 7

#INCLUDE "course.module"

PROC main (CHAN BYTE scr!)
 SEQ
   --out.string("Hello World!*n", 0, scr!)
   scr ! 'B'
   scr ! '*n'
   scr ! '*n'
   SEQ i = 1 FOR 10
     SEQ
       --out.int(i, 0, scr!)
       scr ! 'A'
       scr ! '*n'
:

I use the Transterpreter-win-dev-20101104.0001.zip  distribution

Any suggestion?

-Vangelis

The status of JCSP

Russel Winder — 2010-08-07T09:48:43

As per my previous email, since there seems to be no effort available to
do a JCSP 1.1 release based on RC-5, I have released 1.1-rc5 from the
confines of the Codehaus snapshot repository into the Codehaus main
repository (*).  When the Maven repository next syncs up with the
Codehaus main repository, the jcsp-1.1-rc5 artefact will be out there in
the wild as the main representative of JCSP. 

I just hope the inconsistency between this and the information on
http://www.cs.kent.ac.uk/projects/ofa/jcsp/ won't confuse anyone too
much.

(*) And marked the "maven build" branch off trunk as being rc6-SNAPSHOT.
This branch only exists in the Git mirror at Codehaus of the Subversion
repository at Kent.  At some point there needs to be a merge so that the
Subversion repository at Kent has the Maven build, and the nascent
Gradle build, in the main repository.

GroovyCSP

Russel Winder — 2010-07-15T11:27:35

I think it is unacceptable that people have to use the Codehaus snapshot
repository to get JCSP so that they can use GroovyCSP from the GPars
0.10 release that is present in the main Maven repository.  I am
therefore proposing to push out JCSP 1.1-rc5 as a full release so it
gets into the main Maven repository.

Does this seem like a sensible strategy?  Any obvious pitfalls?

Re: Releasing JCSP 1.1.0

Russel Winder — 2010-07-12T18:00:50

Peter, 

On Wed, 2010-05-19 at 10:52 +0100, Russel Winder wrote:


As anticipated there is beginning to be a take up of GroovyCSP and hence
its dependency JCSP.  Admittedly slow just at the minute but these
things tend to increase with some acceleration.  I suspect the Grails
community will be the one that generates most take up.

So I have to return to the question of whether there will be a JCSP
1.1.0 release or whether it will remain 1.1-rc5 for the foreseeable
future.  If the former then it would be good if something happens.  If
the latter then I will rescind the 1.1-rc5-SNAPSHOT artefact and
formally release a 1.1-rc5 artefact to the main repository as the
official working version for everyone to use.

Thanks.

Re: Releasing JCSP 1.1.0

Russel Winder — 2010-05-19T09:52:53

Peter,

GPars 0.10.0 has now been released and I hope this will stimulate a
desire by many more people to use JCSP.

I would therefore like to push for JCSP to release 1.1.0.

I don't have permissions on the various machines on which action needs
taking to complete all the bits and pieces required to publish a
release, so I can't volunteer to step in as release manager.

I could complete all the bits and pieces need to release an artifact to
Maven on my Git mirror but I think would be the wrong thing to do
without all the appropriate changes to the Kent Subversion repository
and the main JCSP website.

Re: CSP and Actor Comparison

Sarah Mount — 2010-05-11T00:31:24


Thanks for this Rick;

the link to http://vl.fmnet.info/csp/ labelled "The CSP Archive" (at
the bottom of the page) is broken and should probably be removed. I
notice that, in general, there's a bit about CSP the calculus, but
little if anything about CSP the programming style or common idioms
that might attract practitioners. A more comprehensive entry would
probably need to be split over several pages and include code examples
and advantages over a variety of forms of concurrency, such as STM,
event-driven awfulness, and so on.

Sorry I don't have time to be more helpful!

Sarah

CSP and Actor Comparison

Rick Beton — 2010-05-01T13:09:18

Hi all,

I was frustrated to see that the Wikipedia comparison of CSP and the actor
model was almost non-existent.  The existing text on this subject seems
inadequate:

http://en.wikipedia.org/wiki/Actor_model#Contrast_with_other_models_of_message-passing_concurrency

It is almost totally concerned with Hoare's preliminary CSP ideas rather
than what we now know as CSP.  I'm no expert on CCS so cannot comment on
what it says with any certainty.  However, perhaps the remarks on CSP in
that section should just be deleted.

So I had a go at writing something clearer:

http://en.wikipedia.org/wiki/Communicating_sequential_processes#Comparison_with_the_Actor_Model

Please would you consider reviewing this and correcting any obvious howlers.

Regards,
Rick

Re: Releasing JCSP 1.1.0

Russel Winder — 2010-04-30T17:16:34

Peter,


So there can be no constitutional crises then :-)

I guess I am on a campaign to push JCSP out into "it's being used
widely".  If successful it will inevitably change things.  This doesn't
stop, or even conflict with, continued academic collaboration, but it
will likely lead to new needs and pressures. 


No problem with that.


I am not sure what release has necessitated in the past, but I would
guess something along the lines of the following:

1.  For new major and minor releases, create a maintenance branch.

2.  Tag appropriately for the release.

3.  Create the distribution tarball/zip and place in the appropriate
place(s).

4.  Update websites in appropriate places to publicize the release.

5.  Using the Codehaus mirror, upload artefacts to the Maven repository.

6.  Announce the new release to the world.

1-4 clearly require appropriate authority on the Kent systems, 5
requires appropriate authority on Codehaus.  5 will also require using
Git rather than Subversion, but I see that other commits to the
Subversion repository are being done using Git so 

If the could be automated, then it would be easier for the "release
manager(s)" whoever that might be to cause it all to happen correctly.  


Sounds like a good start for a road map for 1.2?  Perhaps it might be an
idea to start a wiki to enable people to contribute to generating a road
map?


I would suggest 1.2.  For me 1.1.1 and 1.1.2 would be simple bug fix
releases on 1.1.0 needed because things cannot wait till 1.2.


People have had two days to comment, and no-one has, so I propose that
be taken as "motion passed nem con".

If that is acceptable, we are down to the "housekeeping" of a release.
There are change in the Codehaus Git mirror of the Kent Subversion store
(Maven and Gradle build specification files) that really need to be
committed into the Subversion store.  I believe I don't have appropriate
permissions so I need to get someone who has to handle a pull request.

If we were to codify the release process (I made a bit of a start above,
perhaps this is another candidate for a collaborative wiki page?) we
could automate it using the Gradle build.

Thanks.

Re: Releasing JCSP 1.1.0

P.H.Welch — 2010-04-28T13:50:22

Hi Russel et al,


JCSP is an academic collaboration - informal and no constitution!
Things happen when it seems right and there is no serious objection.

In practice, I started the JCSP work back in 1996 and have made all
the releases (on http://www.cs.kent.ac.uk/projects/ofa/jcsp/) to date
(integrating work from lots of people and with particular assistance
for building releases from Neil, Kevin and Adam).

JCSP 1.1-rc5 is unfinished in various ways ... but no developments
(other than generics) have happend for too long.  We can't count
the generics version (now in the trunk) as a proper release just
yet because almost all the documentation needs changing.  We have
many plans for re-implemting the core algorithms (away from
synchronized/wait/notify towards java.util.concurrent) and for
other changes and new stuff.

So, I think we should freeze 1.1-rc5 as 1.1 (or 1.1.0) now.  When
The generics are documented, that can become 1.2 (or 1.1.2).  Etc.

Any objections?

Thanks,

Peter.

RE: Releasing JCSP 1.1.0

Chalmers, Kevin — 2010-04-28T10:17:23

I'll say yes, but Peter is effectively the owner.

Kevin

-----Original Message-----
From: Mailing_List_Robot [mailto:sympa< at >kent.ac.uk] On Behalf Of Russel Winder
Sent: 28 April 2010 11:12
To: Kent POP Developers
Subject: [pop-dev] Releasing JCSP 1.1.0

I am not sure what the official constitution is regarding JCSP and decision making, but I assume Adam and myself voting for making the current trunk, which is 1.1-rc5, into the 1.1.0 release, branching it for a 1.1.x maintenance branch, tagging it 1.1.0, and releasing it, doesn't constitute a sufficiency for a decision.  I guess I need to get a bit more pushy so as to get the people who need to say yes to say yes

Releasing JCSP 1.1.0

Russel Winder — 2010-04-28T10:12:12

I am not sure what the official constitution is regarding JCSP and
decision making, but I assume Adam and myself voting for making the
current trunk, which is 1.1-rc5, into the 1.1.0 release, branching it
for a 1.1.x maintenance branch, tagging it 1.1.0, and releasing it,
doesn't constitute a sufficiency for a decision.  I guess I need to get
a bit more pushy so as to get the people who need to say yes to say yes

RE: JCSP development

Russel Winder — 2010-04-21T11:25:04

Kevin,

Just a quick reaction.

On Wed, 2010-04-21 at 12:00 +0100, Chalmers, Kevin wrote:

I think some generics have already made it into the codebase so that
would make the Java floor 5.0.  5.0 is now beyond end of life, so this
really means 6.0.

Java ME is a special beast being really Java 1.1.8 plus an alternative
communications library.  Let's not discuss JavaCard, it isn't really
Java. 

And indeed NIO2 assuming Java 7 arrives before the heat death of the
Universe.  Certainly for remote objects NIO is going to be essential --
experience from people doing remote actor systems.


java.util.concurrent is great.  The JSR166y stuff is very good.  Overall
I would have thought this would allow for lots of refactoring of the
JCSP codebase, but I have not deep dived into it just yet.


AWT is far too heavyweight, which implied Swing or whatever has become
trendy recently :-)


I think an annotation based system for doing things would be advisable.
Sarah Mount's experience of using decorators in Python-CSP lead me to
believe using annotation in JCSP applications would make things a lot
simpler.

Indeed.

RE: JCSP development

Chalmers, Kevin — 2010-04-21T11:00:25

Hopefully I will have some more time in the summer to start looking at things again (this year has been quite hectic thus far).  I guess from my point of view the big change for 1.2 will be removing net and replacing it with net2.  There is some tidying up required which I might get round to, but there is some in the core package, and that is really Peter's territory (updating comments, ensuring correct use of features internally, etc.).  

I guess a move to Java 1.6 is long overdue.  We were holding the core to 1.3 support so that it could run in J2ME CDC, but I think with the advent of more powerful mobile devices this has become less of an issue.  Lower end devices (J2ME CLDC) and robots require a great deal of trimming of JCSP anyway, and should probably be their own build.

Maybe time to put some definite plans down:
* org.jcsp.net removed and org.jcsp.net2 renamed org.jcsp.net
* Investigation into new support from Java to optimise org.jcsp.net (e.g. nio)
* Code review undertaken and code tidied up accordingly
* Investigation into new concurrency support in Java and how it can support JCSP
* Updating GUI support.  I think it's about time we had a Swing library.  Do we keep AWT?
* ... ?

I'm really just throwing ideas out there to see what others think are priorities for a 1.2 release.  If we get two or three must haves for new features / support then we can start planning how we are going to do this.

Kevin

-----Original Message-----
From: Russel Winder [mailto:russel< at >russel.org.uk] 
Sent: 21 April 2010 11:16
To: Chalmers, Kevin
Cc: Kent POP Developers; GPars Developers
Subject: RE: [pop-dev] JCSP development

Kevin,

On Wed, 2010-04-21 at 10:24 +0100, Chalmers, Kevin wrote:

As far as I can see from my Git mirror of the Subversion repository, the last change on the trunk (other than my local changes to create a Maven
build) was 2009-08-11 which had many changes post the 1.1-RC4 tag but there have been no changes since the 1.1-RC5 release I made to the Maven repository.

So at present we have a release candidate that is a release candidate, which means it could be released.  However, I am not in a position to make any such call, I would just ensure that whatever was decided by whoever is the right group to make the decision was followed up by a release to the Maven repository.

I have been out pushing the Java and CSP line, and a lot of Groovy CSP.
I am hoping this will lead to new interest in JCSP.  For this reason I think there really needs to be a 1.1 release sooner rather than later and it would also be good to have a road map for 1.2.

On the trivial end of things, it should be noted that the infrastructure to make a build to upload to Maven is in my Git repository (and is available on the Codehaus Git repository) but has not been uploaded to the Subversion repository. 

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder< at >ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel< at >russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Edinburgh Napier University - one of the top 10 universities in the UK for graduate employability (HESA 2009) and proud winners of the Queen's Anniversary Prizes for Higher and Further Education 2009, awarded for innovative housing construction for environmental benefit and quality of life.

This message is intended for the addressee(s) only
and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. 
Edinburgh Napier University does not accept liability for any loss or
damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University. 

Edinburgh Napier University is a registered Scottish
charity.
Registration number SC018373

Re: JCSP development

Adam Sampson — 2010-04-21T10:27:45


This sounds like an eminently sensible idea to me; it'd be good to have
a new release of JCSP out there. Peter? Neil?


Cool. :)

Thanks,

RE: JCSP development

Russel Winder — 2010-04-21T10:15:51

Kevin,

On Wed, 2010-04-21 at 10:24 +0100, Chalmers, Kevin wrote:

As far as I can see from my Git mirror of the Subversion repository, the
last change on the trunk (other than my local changes to create a Maven
build) was 2009-08-11 which had many changes post the 1.1-RC4 tag but
there have been no changes since the 1.1-RC5 release I made to the Maven
repository.

So at present we have a release candidate that is a release candidate,
which means it could be released.  However, I am not in a position to
make any such call, I would just ensure that whatever was decided by
whoever is the right group to make the decision was followed up by a
release to the Maven repository.

I have been out pushing the Java and CSP line, and a lot of Groovy CSP.
I am hoping this will lead to new interest in JCSP.  For this reason I
think there really needs to be a 1.1 release sooner rather than later
and it would also be good to have a road map for 1.2.

On the trivial end of things, it should be noted that the infrastructure
to make a build to upload to Maven is in my Git repository (and is
available on the Codehaus Git repository) but has not been uploaded to
the Subversion repository.

RE: JCSP development

Chalmers, Kevin — 2010-04-21T09:24:46

The trunk is a little different from 1.1-RC5.  Generics were added at least.

Kevin

-----Original Message-----
From: Mailing_List_Robot [mailto:sympa< at >kent.ac.uk] On Behalf Of Russel Winder
Sent: 21 April 2010 09:51
To: Kent POP Developers
Cc: GPars Developers
Subject: [pop-dev] JCSP development

Hi,

I am not sure of the appropriate protocol hence this email.

GPars is looking to release its 0.10 mid-May, it is entering a beta cycle now.  This is the first release of GPars that will have GroovyCSP.
GroovyCSP is effectively just a wrapper around JCSP.  Currently we have JCSP 1.1-RC5 as the version in the Maven repository.  I would like to propose that this be released as 1.1.0 (it is a release candidate and as far as I know there have been no changes to the codebase since it was released), a maintenance branch taken to cover the need for bug-fix
releases, and that trunk is renumbered as 1.2.0-SNAPSHOT.   I guess my
question is what is the right way of making this proposal.

Thanks.

--
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder< at >ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel< at >russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Edinburgh Napier University - one of the top 10 universities in the UK for graduate employability (HESA 2009) and proud winners of the Queen's Anniversary Prizes for Higher and Further Education 2009, awarded for innovative housing construction for environmental benefit and quality of life.

This message is intended for the addressee(s) only
and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. 
Edinburgh Napier University does not accept liability for any loss or
damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University. 

Edinburgh Napier University is a registered Scottish
charity.
Registration number SC018373

JCSP development

Russel Winder — 2010-04-21T08:50:37

Hi,

I am not sure of the appropriate protocol hence this email.

GPars is looking to release its 0.10 mid-May, it is entering a beta
cycle now.  This is the first release of GPars that will have GroovyCSP.
GroovyCSP is effectively just a wrapper around JCSP.  Currently we have
JCSP 1.1-RC5 as the version in the Maven repository.  I would like to
propose that this be released as 1.1.0 (it is a release candidate and as
far as I know there have been no changes to the codebase since it was
released), a maintenance branch taken to cover the need for bug-fix
releases, and that trunk is renumbered as 1.2.0-SNAPSHOT.   I guess my
question is what is the right way of making this proposal.

Thanks.

Re: Error with the Transterpreter in the Gumstix

Sarah Mount — 2010-03-29T15:48:35

On 29 March 2010 13:54, Thiago Castro Ferreira
<thiago.castroferreira-/E1597aS9LRfJ/NunPodnw< at >public.gmane.org> wrote:

<snip errors>



Thiago,

I am not sure how familiar you are with makefiles and UNIX development
generally, but make is printing out every OS call it is making, so you
can follow what is happening here and where the error is. You will
also want to read the BitBake manual in some detail. I would guess
looking at this that either bitbake could not download a file for you
(which seems to be the error that you reported on the gumstix-users
list) or that you do not have some directory or file that is needed to
compile uCilbc (which is a version of libc and so will be necessary to
compile many other things on your buildroot). I would suggest that you
check that you have the most recent buildroot available then go
through the bitbake files for packages you are having problems with.
Bitbake will often download source files, patches and other files
directly from sourceforge or other websites. This makes it quite
brittle, since if a new version of a package becomes available or if a
website moves or something, this can break your build. So, often the
fix you need will be to go to the site containing the original sources
and alter your bitbake files to match reality.

Good luck!

Sarah

--
Sarah Mount, Senior Lecturer, University of Wolverhampton
website:  http://www.snim2.org/
twitter: < at >snim2

This email, together with any attachment, is for the exclusive and
confidential use of the addressee(s) and may contain legally
privileged information.  Any use, disclosure or reproduction without
the sender's explicit consent is unauthorised and may be unlawful.

Any e-mail including its content and any attachments may be monitored
and used by The University of Wolverhampton for reasons of security
and for monitoring internal compliance with the University's policy on
internet use. E-mail blocking software may also be used.  The
University cannot guarantee that this message or any attachment is
virus free or has not been intercepted and amended.

If you believe you have received this message in error please notify
the sender by email, telephone or fax and destroy the message and any
copies.