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 Napie

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:\Prog

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 com

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

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 tidie

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
t

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.

--

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 ma