linuxfbp

[Paul Tarvydas]

This code is an experiment to see if FBP can be implemented using Linux as the FBP runtime.

I've replaced the command-line shell "bash" with "grash".  Less readable, but many fewer commands (about 8).

https://github.com/guitarvydas/linuxfbp

pt

[Thomas Backlund]

Hi Paul T,

This looks very cool.

Is "grash" your own invention? I haven't seen it before but it looks very to the point competent and something I would want to use.

I really like the idea of this "low level FBP", connecting processes together without adding too much magic to it. More or less jacking

into the UNIX philosophy.

I was active on this list about three years ago when we showed of Blockie's take on FBP (https://www.youtube.com/user/BlockieIO).

Since then we have dove deep down into Linux and taking a much more basic approach to "block based" programming, or rather infrastructure.

We have our first product (GPL licensed) out in early preview, it's called The SpaceGal Shell, space.sh, which is a module based automation tool written in Bash.
Proper version 1.0 should be out in a couple of months.

I'm gonna think about how to use LinuxFBP together with Space.. :)

Thanks for inspiring work!

Best regards,

Thomas Backlund

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Tarvydas]

On 2017-02-10 03:47 AM, Thomas Backlund wrote:

Hi Paul T,

This looks very cool.

Is "grash" your own invention?

Yes.

The intention was to show just how little of an O/S is needed to implement the fundamental concepts of FBP.

I, also, favour minimalistic syntax.  A stack machine (2 levels deep :-), an "assembler" that always has the keyword on the left and one parameter on the right (darned easy to parse, even in C :-).

...I really like the idea of this "low level FBP", connecting processes together without adding too much magic to it. More or less jacking

into the UNIX philosophy.

UNIX was a great idea, but, it should have been (or should be) built using concurrent modules, e.g. using Goroutines, where every parameter is a channel (nothing else).

Snap the modules together to get what you need, w/o having to download the whole O/S.

I worked on TUNIS, which was almost this idea - built in Concurrent Euclid.  Each part of the O/S was a (concurrent) module, e.g. file system, etc.  The main missing element was "deferred monitors" which appeared in the Turing+ language.  Well, and a consistent API - IP's only.

...We have our first product (GPL licensed) out in early preview, it's called The SpaceGal Shell, space.sh, which is a module based automation tool written in Bash.

I took a quick look, but I don't understand what problem it solves?  Can you describe it or send me a pointer?  I'm missing something.

...

I'm gonna think about how to use LinuxFBP together with Space.. :)

Thanks for inspiring work!

Excellent.

Thanks for being inspired!

pt

[Paul Morrison]

I have downloaded linuxfbp into some folders on my VirtualBox, running Xubuntu, and (greatly daring) ran "make". 

For those of us who are not Linux gurus, dumb question: what do I do next?!!!  How do I run "grash"?

Regards,

Paul M.

[Paul Tarvydas]

On 2017-02-13 12:23 PM, Paul Morrison wrote:
> I have downloaded linuxfbp into some folders on my VirtualBox, running
> Xubuntu, and (greatly daring) ran "make".
>
> For those of us who are not Linux gurus, dumb question: what do I do
> next?!!! How do I run "grash"?

a) Did make create a "bin" directory in your home dir? I have "~/bin"
on my PATH.

b) Can you run a terminal? In which case, you should be able to type
"grash test.gsh" at the command prompt.

More instructions gladly given...

pt

[Paul Morrison]

I created a bin folder in /home/paul - went to /home/paul/Documents/GitHub/linuxfbp - ran "make",  and I now see a folder called "grash" in bin, but it's empty...

Maybe my directory structure is screwed up...?

TIA

[Paul Tarvydas]

Clearly my instructions aren’t good enough, I’m assuming too much linux knowledge.

Sorry. I’ll try to post more thorough instructions.

pt

[Paul Tarvydas]

I added a few lines of instructions for linux.

Do a "git pull" to drag down the new README.md and see the first section.

This is not very complete, it should contain an installation script, but
this is *only* an experiment.

I will be glad to help if you get any error messages. You probably have
the directories already, so you might get redundant errors.

I'm guessing you didn't have ~/bin exported in the PATH ('cause I forgot
to say so).

The experiment is still in its infancy.

The first gotcha is that *nix pipes don't do "fan-in" correctly
(multiple outs to a single in). You *can* join the writers on a single
pipe, but as soon as one of the writers closes the pipe, it's done.

The silly fix is "dot.c" which takes 10 ins and produces one out.

Suggestions most welcome.

Next unsolved problem - subgraphs.

Thanks for your patience...

pt

[Paul Morrison]

Fantastic, Paul!  It worked - I think!  Should the output be 3 hello's, and then you have to hit enter?

Perhaps you could add the expected output to some of these test cases.  Also I have raised a PR to space the "simple instructions" as separate lines - it was a bit hard to read :-)

Onwards and upwards!

Paul M.

[Tom Young]

It might be nice to provide for "make check" which would build the program (if necessary) then run the test suite.
--- twy

Via phone

> --
> You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-progra...@googlegroups.com.

[Armando Drummond]

Paul,

We have a similar solution in Linux, also based on that "IP's" are (text) lines terminated by \n.

We use bash and I/O redirection to/from named pipes. I'm not sure if I understood your fan-in issue, but we use line-buffered output in order to send a whole IP to next pipe. If the output line has less than 4096 bytes, it is written atomically. In that way, many outputs to the same input preserves integrity and timing.

fprint(stderr,...) is already line-buffered, you must add fflush(stdout) after fprintf(stdout,...).  

Is it OK?

Armando

pt

--
You received this message because you are subscribed to the Google Groups "Flow Based Programming" group.

To unsubscribe from this group and stop receiving emails from it, send an email to flow-based-programming+unsubscri...@googlegroups.com.

[Paul Tarvydas]

On 2017-02-14 12:02 PM, Paul Morrison wrote:
> Fantastic, Paul! It worked - I think! Should the output be 3
> hello's, and then you have to hit enter?

In fact, you don't need to hit enter...

What happens is that the test mainline runs and forks its children.
(It's actually a race, does the mainline end before the children or v.v.?).

The mainline then terminates and the shell (bash) prints a new prompt.

The children run and produce output - after the new prompt.

If you look at the output upwards, you should see a shell prompt sitting
there by itself. Or, you can simply type a command (e.g. "echo
goodbye") then hit enter and that command will run, apparently without a
prompt.

>
> Perhaps you could add the expected output to some of these test
> cases. Also I have raised a PR to space the "simple instructions" as
> separate lines - it was a bit hard to read :-)

Yes, it is confusing. They were on separate lines when they left my
machine. Maybe I need to learn about the .md format...

pt

[Paul Tarvydas]

On 2017-02-15 02:39 PM, Armando Drummond wrote:
> Paul,
> We have a similar solution in Linux, also based on that "IP's" are
> (text) lines terminated by \n.
> We use bash and I/O redirection to/from named pipes. I'm not sure if I
> understood your fan-in issue, but we use line-buffered output in order
> to send a whole IP to next pipe. If the output line has less than 4096
> bytes, it is written atomically. In that way, many outputs to the same
> input preserves integrity and timing.
> fprint(stderr,...) is already line-buffered, you must add
> fflush(stdout) after fprintf(stdout,...).

Hi Armando

Thanks for asking the question. I went back to my tests and found that
I could not duplicate the "problem". After some more digging, I found
the man page pipe(7) which says that you are correct - many outputs can
be connected to one pipe and only the last close will close the pipe.
And, yes, any writes < PIPE_BUF (min 512) are atomic.

Thanks
pt