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

[Bob Gustafson <bobgus@xxxxxxx>]

I rather enjoyed reading Geraint Jones's two books on Occam. The latest,
with Michael Goldsmith - "Programming In Occam 2 (2nd Edition)
(Paperback)" is available on Amazon. (1 is available new for $114.07 and
several used from $7.04 - The free markets can be curious.)


On Tue, 2009-02-24 at 08:44 -0600, Andrzej Lewandowski wrote:
> ... however, The World will not come and ask us for solution. Without active
> promotion, available tools (especially for debugging), advertizing,
> marketing and commercialization, without writing in popular and business
> journals, without making noise, CSP will stay where it is now: topic of
> obscure scientific conferences that nobody knows about.
> 
> There are about 10 books "by programmers for programmers" about thread
> programming in Java. All books about CSP I know require Ph.D.+ and have very
> little impact on programming practice. WHY NO POPULAR BOOKS?... Does anybody
> is expecting that average Java programmer will read (and understand) Hoare's
> book? Or Roscoe's, or Schneider's? How average Java programmer could learn
> that CSP and JCSP DO EXIST?... And how they could be convinced that JCSP is
> better than Java thread library?
> 
> A.L.
> 
> P.S. I will not write such a book :) I am currently in the business of
> Constraint Logic Programming, and I am trying to write a book about CLP for
> practitioners.... Sorry...
> 
> -----Original Message-----
> From: Mailing_List_Robot [mailto:sympa@xxxxxxxxxx] On Behalf Of Bob
> Gustafson
> Sent: Tuesday, February 24, 2009 8:03 AM
> To: occam-com@xxxxxxxxxx
> Subject: RE: JCSP, CSP Networking, and other some other points
> 
> 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
> > 
> > 
> > 
> > 
> > 
> 
>