[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: occam REPL
For your information, we have started the development of such a graphical
environment for OpenComRTOS (details now on website). There is already an
application level description in xml syntax, that is used as input for a
system generation utility (generating basically all datastructures and
template code. The user only has to fill in the "S" part in the tasks.
It is not occam, but a distributed RTOS in C with services very close to CSP
and was developed using formal modeling. The graphical front-end will allow
drawing up applications and graphically running tem (on top of Windows).
More to be seen as a tool for beginners as experienced developers only use
command line builds.
The idea of the REPL is what we call a test harness. Connect it to the input
ports and outputs ports, generate data using the right protocol on the
inputs and connect the outputs to a data gatering task with filing and
printing. This works fine for dataflow type application tasks, but is less
trivial for testing with real-time I/O and e.g. shared resources.
---------------------- FROM : --------------------------
Eric.Verhulst@xxxxxxxxxxxxxxxxxxxxxx
Skype me at: ericverhulstskype
Mob. +32 477 608339
Systematic Systems Development Methodologies
Trustworthy Embedded Components
http://www.OpenLicenseSociety.org
-----------------------------------------------------------
" "Concept" is a vague concept", L. Wittgenstein
-----Original Message-----
From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx] On
Behalf Of Andrew Delin
Sent: Sunday, August 20, 2006 4:29 AM
To: Damian Dimmich; occam-com@xxxxxxxxxx
Subject: RE: occam REPL
If our goal is to get the world to try CPA / POP, it's a good idea to give
them something fun to play with.
The majority of today's programmers use cool IDE's which offer syntax
support and component awareness.
So why not build an occam process diagramming tool that works in such an
environment?
Occam has an advantage here. Implicit in the occam approach is the drawing
of simple process diagrams, as in the Inmos occam tutorial. It would be a
'relatively easy' matter to create a graphical tool for these circles
(processes) and lines (channels), which then generate executable code in
occam-pi JCSP .Net, etc. You could add channel type definitions to the
connecting lines, and double-click the process circles to wire up the next
level of processes/channels within.
Such a tool could be integrated into a popular programming IDE's such as
Visual Studio .NET etc, which would encourage thinking about mixed-language
projects where occam has an important place.
The nice thing is the close correspondence between these process diagrams
and occam code, whereas OO trace and relationship diagrams (static and
dynamic views of objects) are much more abstract. I found it much harder to
draw OO diagrams and generate code from them. Frequently the OO code was
refactored to express a different OO implementation, but the diagram didn't
get updated. With an occam diagramming tool, however, you could edit the
occam code and the diagram would regenerate automatically.
Does anyone know the name of the occam process diagrams?
-Andrew
-----Original Message-----
From: owner-occam-com@xxxxxxxxxx [mailto:owner-occam-com@xxxxxxxxxx] On
Behalf Of Damian Dimmich
Sent: Saturday, 19 August 2006 8:50 PM
To: occam-com@xxxxxxxxxx
Subject: Re: occam REPL
Hello,
While I think that a graphical system for testing POP style sections of
programs would be really cool, I do think it could be done from the
commandline.
It would be possible to start processes up individually and get them going
as you hook them together.
A good way to test them would be to have the ability to send data down an
'unhooked' channel end and view the result at the other end. So REPL-style
you could do something
like:
pseudocode:
define channel x:
define channel y:
start proc foo with x in, y out.
x ! 3
-> output from foo here.
proc foo could have been loaded from a file previously with a 'use' or
'include' at the commandline.
The process would start executing in parallel with the commandline and block
when it reaches input.
It could get a bit messy if the process starts outputting before reading but
that could probably be solved somehow (another terminal?)
Damian
tjoccam@xxxxxxxxxxx wrote:
>> I'm not entirely convinced that a REPL-style interface would be the
>> best way to get people playing with process-oriented programming
>> (which seems to be your goal).
>> Wiring up incomplete process networks, and adding to them on-the-fly,
>> seems to me like something that would be difficult to achieve via a
>> textual interface.
>>
>
> That is where I think you may have been misled by standard paradigms.
An
> "incomplete process network" does not exist in occam, at least
> separately-compiled hardware-based occam (where all globals are
defined
> explicitly, as in a .PGM file for the occam configurer). Everything is
a
> self-sufficient black box that listens and talks. It exactly fits Mark
> Bereit's notion of a separate hardware node for everything.
>
> If you make sure one box understands the output of another, or of
several
> others (thus better than DOS/Unix pipes), then you can make a lot of
> individual sane components, test each one individually, then hook them
up
> in complex topologies (using multiplexers and the like), and get
rather
> interesting results out. The ALT is your friend here; it allows
infrequent
> parameter changes or resets controlled on another channel.
>
>
>> Not impossible, but potentially difficult enough that it would not
>> have the desired effect of stimulating experimentation. My suggestion
>>
> would be
>
>> to provide some kind of graphical interface for defining process
>>
> networks
>
>> interactively.
>>
>
> OK, but you need direct access to the atoms, the way a REPL gives it
to
> you - then hook them together graphically if you please, but be ready
to
> design sane startup and shutdown (or reset). I find pencil and paper
> better for that.
>
> Larry
>
>
>> Something like Simulink for Matlab. Perhaps the work by Hilderink and
>> his colleagues on gCSP would provide a good starting
>>
> point.
>
>> Allan
>> --
>> Allan McInnes <amcinnes@xxxxxxxxxx>
>> PhD Candidate
>> Dept. of Electrical and Computer Engineering Utah State University
>>
>>
>>
>>
>
>
>
>
>
>
>
>