RE: JCSP, CSP Networking, and other some other points

[Bob Gustafson <bobgus@xxxxxxx>]

I agree. Occam is a 'solution in waiting' for multi-core processors. A
few of you University Lecturers could give out releases to the trade
press about Occam, JCSP, CSP..  (or is Occam a trademark ??)

(I am getting duplicate emails for all recent posts to this list - is
anyone else?)

Bob G

On Tue, 2009-02-24 at 07:54 -0600, Andrzej Lewandowski wrote:
> Good. JCSP as software product is really solid (I am talking about RC 1.0
> that I was using in commercial application).
> 
> By the way, why CSP community is silent when it regards programming
> multicore processors? There is a lot of nonsense being published recently
> regarding this topic, various "thread and parallel" amateurs trying to find
> "silver bullets" that in most cases look like "philosophical stone". Even
> Wall Street Journal and New York Times write how hard is programming
> multicore processors.
> 
> In the meantime, CSP community is sitting in Ivory Tower. Isn't CSP, JCSP
> and such good tools for multicore, and will multicore be the next
> missing/ignored opportunity for CSP community?
> 
> A.L. 
> 
> -----Original Message-----
> From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Chalmers,
> Kevin
> Sent: Tuesday, February 24, 2009 7:26 AM
> To: Andrzej Lewandowski; java-threads@xxxxxxxxxx; occam-com@xxxxxxxxxx
> Subject: RE: JCSP, CSP Networking, and other some other points
> 
> Nothing within the core underlying functionality will change (unless Peter
> adds anything).  We are really talking externally.  For example, typed
> channels shouldn't be a problem and would utilise the existing channels
> underneath.  Library wise, we can consider support for Swing (AWT is old),
> etc.  Don't think of this as a modification exercise, more an extension.
> 
> Kevin Chalmers,
> Lecturer,
> School of Computing,
> Edinburgh Napier University,
> Merchiston Campus,
> Edinburgh, EH10 5DT
> 
> t: +44 (0)131 455 2484
> 
> 
> 
> > -----Original Message-----
> > From: Andrzej Lewandowski [mailto:lewando@xxxxxxxxxxxxx]
> > Sent: 24 February 2009 12:38
> > To: Chalmers, Kevin; java-threads@xxxxxxxxxx; occam-com@xxxxxxxxxx
> > Subject: RE: JCSP, CSP Networking, and other some other points
> > 
> > " I have had a couple of emails recently asking about progress with
> > JCSP and
> > with one thing or another we haven't had much time to work on updating
> > the
> > core JCSP package.."
> > 
> > DON'T FIX IT IF IS NOT BROKEN. First of all.
> > 
> > A.L.
> > 
> > -----Original Message-----
> > From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of
> > Chalmers,
> > Kevin
> > Sent: Tuesday, February 24, 2009 4:04 AM
> > To: java-threads@xxxxxxxxxx; occam-com@xxxxxxxxxx
> > Subject: JCSP, CSP Networking, and other some other points
> > 
> > All,
> > 
> > This email is going to cover a few different points so bear with me a
> > little
> > :)
> > 
> > First of all JCSP.  I have had a couple of emails recently asking about
> > progress with JCSP and with one thing or another we haven't had much
> > time to
> > work on updating the core JCSP package.  We have discussed
> > possibilities of
> > taking JCSP to a Java 1.5/6 version, and utilising various parts of the
> > Java
> > API to simplify / increase performance, but I don't think any concrete
> > decisions were made.  So my first question is really about where we
> > should
> > be taking the core JCSP package?  What sort of functionality are people
> > looking for that we don't yet support?  I am, finally, going to try and
> > put
> > various JCSP versions / packages up on the repository, including an
> > updated
> > JCSP Micro Edition and Jon's JCSP Robot Edition.  Possibly Groovy, but
> > that's a discussion point I feel, as it is not really Java as such.
> > 
> > Secondly, and probably most important from my point of view, is CSP
> > Networking (for want of a better term).  As some of you may know, I
> > have
> > been working on a generalised protocol and architecture for JCSP, which
> > we
> > can re-implement on the various CSP platforms/frameworks (occam,
> > C++CSP,
> > PyCSP, etc.), and thereby gain some form of inter-framework
> > communication.
> > We are still very much in an early stage, so this is sort of general
> > call
> > out to interested parties who would like to either contribute some
> > insight,
> > or, even better, help take things forward.  I am currently working with
> > John
> > Markus in Tromso (when I can) to try and get PyCSP and JCSP to
> > interact.  So
> > far I have JCSP sending strings to Python, and Python acknowledging and
> > sending back a reply, so we are making some progress.  At a quick
> > count, we
> > have seven frameworks probably looking at having some network
> > functionality
> > (JCSP, PyCSP, occam, Transterpreter, C++CSP, Haskell CSP, CSO (Scala)),
> > and
> > it would be pretty good if we could get an Erlang version as well.  I
> > am
> > hoping to start a project with this, so as time goes on we can set up
> > the
> > various resources that we need.
> > 
> > Related to this request is a question on a C/C++ reference library for
> > the
> > protocol and architecture.  I am currently thinking about the best
> > method to
> > go about having a standard native library which each CSP framework can
> > essentially hook into, thus reducing the overall maintenance /
> > development
> > work.  To simplify the description of the architecture a little,
> > essentially
> > there are a series of queues (infinitely buffered channels) which
> > receive
> > messages for incoming network channels, and TX/RX processes to handle
> > network comms.  When it comes down to it, there is nothing that
> > essentially
> > requires CSP semantics within the architecture (there is no
> > synchronisation
> > between the TX/RX processes and the networked channels as the channels
> > are
> > infinitely buffered), and any shared state can happily be protected
> > within a
> > standard critical region.  So currently I am considering two different
> > approaches:
> > 
> > 1) Use C++CSP to develop the library, which requires C++CSP and Boost.
> > 2) Use Intel Thread Building Blocks.  Only requires one library.
> > 
> > The last time I talked to Neil, he was unsure if C++CSP was 100%
> > Windows
> > compatible, and also I would have to strip out the existing C++CSP
> > Networking functionality, meaning it wouldn't be an exact version.  TBB
> > I'm
> > not as familiar with however, so if anyone knows any problems with the
> > library let me know.  If you have any insights into either it could be
> > useful also.
> > 
> > Cheers,
> > 
> > Kevin
> > 
> > Kevin Chalmers,
> > Lecturer,
> > School of Computing,
> > Edinburgh Napier University,
> > Merchiston Campus,
> > Edinburgh, EH10 5DT
> > 
> > t: +44 (0)131 455 2484
> > 
> > 
> > 
> > Napier University is the best modern university in Scotland* and number
> > one
> > in Scotland for graduate employability**
> > (*Guardian University Guide 2009)
> > (**HESA 2008)
> > 
> > This message is intended for the addressee(s) only and should not be
> > read,
> > copied or disclosed to anyone else out-with 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. 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.
> > Napier University is a registered Scottish charity. Registration number
> > SC018373
> > 
> > 
> > 
> 
> 
> Napier University is the best modern university in Scotland* and number one
> in Scotland for graduate employability**
> (*Guardian University Guide 2009)
> (**HESA 2008)
> 
> This message is intended for the addressee(s) only and should not be read,
> copied or disclosed to anyone else out-with 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. 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.
> Napier University is a registered Scottish charity. Registration number
> SC018373
> 
> 
> 
> 
>