[Caml-list] [ANN] OCamp - Reactive programming in the shell

[Caml-list] [ANN] OCamp - Reactive programming in the shell

[Frédéric Bour]

OCamp extends unix shells with constructions to express memoization, 
sharing of computations and reactive programming.

# Subcommands

## fire

Just wrap a unix command with "ocamp fire" to enable the extension:
   $ ocamp fire bash

This will spawn a new bash session where the following subcommands are 
enabled.

## hipp

   $ ocamp hipp <command>

Will memoize the output and exit status of <command>.
Later calls to the same <command> won't lead to actual execution, but 
just to a duplication of its previous output.
Concurrent calls to <command> will just share the same process, the 
beginning of the output being replayed to later callers.

The identity of a command is defined by its arguments and working 
directory.

## stir

   $ ocamp stir <command>

Indicate potential changes in the output if <command> was rerun.
Later calls to `hipp` will recompute <command> as if it was not yet 
memoized.

## (un)follow

   $ ocamp follow <command>

First, <command> is memoized if it was not the case yet.
Then changes to dependencies of <command> will trigger a reevaluation.
Use `stir` to notify a change.

(to follow is an hipp/stir reactivity).

## pull

   $ ocamp pull <command>

Closely related to `hipp`, but instead of marking dependency on the 
output of <command>, the dependency applies to the "effects" of <command>.

Thus, if `stir` is used:
- all pullers will be reevaluated.
- hippers will be reevaluated only if the output is different.

## Summary

   $ ocamp fire <command> - setup a new session alive until <command> exits
           pull <command> - mark dependency on effects of <command>
           hipp <command> - mark dependency on output of <command>
           stir <command> - notify that <command> might have been updated
           follow <command> - eval <command>, and reactively recompute it
                              whenever one of its dependencies change.
           unfollow <command> - stop recomputing <command> when 
dependencies
                                change

hipp and pull provide memoization.
stir and follow bring a flavor of reactive programming.

# Examples

## Fibonacci

   $ cat fib.sh
   #!/bin/sh
   ARG="$1"
   if [ "$ARG" -le 1 ]; then
     echo "$ARG"
   else
     A=`ocamp hipp ./fib.sh $((ARG-1))`
     B=`ocamp hipp ./fib.sh $((ARG-2))`
     echo $((A+B))
   fi

   $ time ocamp fire ./fib.sh 50
   12586269025
     real    0m0.391s
   user    0m0.153s
   sys     0m0.060s

## Build-system

`ocamp` provides simple primitives to construct and manage a dependency 
graph.

This might be a saner foundation to base a build-system on than make(1):
- the command focus on one specific problem
- no dsl is involved; rules can be plain unix commands, including a 
shell, rather than a make-flavored simulation of shell
- nothing is provided for resolving goals; indeed this is better left to 
tools specifically built for goal-search.

A quick'n'dirty script building ocamp itself is provided as an example.

# Future

The current release is a proof-of-concept and should be considered alpha 
quality.
The two features planned next are a way to make the graph persistent 
(all data is kept in memory atm) and an interface to debug and/or 
observe graph construction.

Note: code is undergoing legal review and should be available soon \o/

Re: [Caml-list] [ANN] OCamp - Reactive programming in the shell

[Frédéric Bour]

Code is finally available at:
     https://github.com/def-lkb/ocamp

Sorry for the little delay!

On 01/04/2015 22:32, Frédéric Bour wrote:
> OCamp extends unix shells with constructions to express memoization, 
> sharing of computations and reactive programming.
>
> # Subcommands
>
> ## fire
>
> Just wrap a unix command with "ocamp fire" to enable the extension:
>   $ ocamp fire bash
>
> This will spawn a new bash session where the following subcommands are 
> enabled.
>
> ## hipp
>
>   $ ocamp hipp <command>
>
> Will memoize the output and exit status of <command>.
> Later calls to the same <command> won't lead to actual execution, but 
> just to a duplication of its previous output.
> Concurrent calls to <command> will just share the same process, the 
> beginning of the output being replayed to later callers.
>
> The identity of a command is defined by its arguments and working 
> directory.
>
> ## stir
>
>   $ ocamp stir <command>
>
> Indicate potential changes in the output if <command> was rerun.
> Later calls to `hipp` will recompute <command> as if it was not yet 
> memoized.
>
> ## (un)follow
>
>   $ ocamp follow <command>
>
> First, <command> is memoized if it was not the case yet.
> Then changes to dependencies of <command> will trigger a reevaluation.
> Use `stir` to notify a change.
>
> (to follow is an hipp/stir reactivity).
>
> ## pull
>
>   $ ocamp pull <command>
>
> Closely related to `hipp`, but instead of marking dependency on the 
> output of <command>, the dependency applies to the "effects" of 
> <command>.
>
> Thus, if `stir` is used:
> - all pullers will be reevaluated.
> - hippers will be reevaluated only if the output is different.
>
> ## Summary
>
>   $ ocamp fire <command> - setup a new session alive until <command> 
> exits
>           pull <command> - mark dependency on effects of <command>
>           hipp <command> - mark dependency on output of <command>
>           stir <command> - notify that <command> might have been updated
>           follow <command> - eval <command>, and reactively recompute it
>                              whenever one of its dependencies change.
>           unfollow <command> - stop recomputing <command> when 
> dependencies
>                                change
>
> hipp and pull provide memoization.
> stir and follow bring a flavor of reactive programming.
>
> # Examples
>
> ## Fibonacci
>
>   $ cat fib.sh
>   #!/bin/sh
>   ARG="$1"
>   if [ "$ARG" -le 1 ]; then
>     echo "$ARG"
>   else
>     A=`ocamp hipp ./fib.sh $((ARG-1))`
>     B=`ocamp hipp ./fib.sh $((ARG-2))`
>     echo $((A+B))
>   fi
>
>   $ time ocamp fire ./fib.sh 50
>   12586269025
>     real    0m0.391s
>   user    0m0.153s
>   sys     0m0.060s
>
> ## Build-system
>
> `ocamp` provides simple primitives to construct and manage a 
> dependency graph.
>
> This might be a saner foundation to base a build-system on than make(1):
> - the command focus on one specific problem
> - no dsl is involved; rules can be plain unix commands, including a 
> shell, rather than a make-flavored simulation of shell
> - nothing is provided for resolving goals; indeed this is better left 
> to tools specifically built for goal-search.
>
> A quick'n'dirty script building ocamp itself is provided as an example.
>
> # Future
>
> The current release is a proof-of-concept and should be considered 
> alpha quality.
> The two features planned next are a way to make the graph persistent 
> (all data is kept in memory atm) and an interface to debug and/or 
> observe graph construction.
>
> Note: code is undergoing legal review and should be available soon \o/
>

Re: [Caml-list] [ANN] OCamp - Reactive programming in the shell

[Anthony Tavener]

[-- Attachment #1: Type: text/plain, Size: 4342 bytes --]

Hah! You were serious? I thought with commands like hipp and stir, and your
legal review notice at the end, that this was an April Fool's joke. :)

On Thu, Apr 2, 2015 at 12:38 PM, Frédéric Bour <frederic.bour@lakaban.net>
wrote:

> Code is finally available at:
>     https://github.com/def-lkb/ocamp
>
> Sorry for the little delay!
>
>
> On 01/04/2015 22:32, Frédéric Bour wrote:
>
>> OCamp extends unix shells with constructions to express memoization,
>> sharing of computations and reactive programming.
>>
>> # Subcommands
>>
>> ## fire
>>
>> Just wrap a unix command with "ocamp fire" to enable the extension:
>>   $ ocamp fire bash
>>
>> This will spawn a new bash session where the following subcommands are
>> enabled.
>>
>> ## hipp
>>
>>   $ ocamp hipp <command>
>>
>> Will memoize the output and exit status of <command>.
>> Later calls to the same <command> won't lead to actual execution, but
>> just to a duplication of its previous output.
>> Concurrent calls to <command> will just share the same process, the
>> beginning of the output being replayed to later callers.
>>
>> The identity of a command is defined by its arguments and working
>> directory.
>>
>> ## stir
>>
>>   $ ocamp stir <command>
>>
>> Indicate potential changes in the output if <command> was rerun.
>> Later calls to `hipp` will recompute <command> as if it was not yet
>> memoized.
>>
>> ## (un)follow
>>
>>   $ ocamp follow <command>
>>
>> First, <command> is memoized if it was not the case yet.
>> Then changes to dependencies of <command> will trigger a reevaluation.
>> Use `stir` to notify a change.
>>
>> (to follow is an hipp/stir reactivity).
>>
>> ## pull
>>
>>   $ ocamp pull <command>
>>
>> Closely related to `hipp`, but instead of marking dependency on the
>> output of <command>, the dependency applies to the "effects" of <command>.
>>
>> Thus, if `stir` is used:
>> - all pullers will be reevaluated.
>> - hippers will be reevaluated only if the output is different.
>>
>> ## Summary
>>
>>   $ ocamp fire <command> - setup a new session alive until <command> exits
>>           pull <command> - mark dependency on effects of <command>
>>           hipp <command> - mark dependency on output of <command>
>>           stir <command> - notify that <command> might have been updated
>>           follow <command> - eval <command>, and reactively recompute it
>>                              whenever one of its dependencies change.
>>           unfollow <command> - stop recomputing <command> when
>> dependencies
>>                                change
>>
>> hipp and pull provide memoization.
>> stir and follow bring a flavor of reactive programming.
>>
>> # Examples
>>
>> ## Fibonacci
>>
>>   $ cat fib.sh
>>   #!/bin/sh
>>   ARG="$1"
>>   if [ "$ARG" -le 1 ]; then
>>     echo "$ARG"
>>   else
>>     A=`ocamp hipp ./fib.sh $((ARG-1))`
>>     B=`ocamp hipp ./fib.sh $((ARG-2))`
>>     echo $((A+B))
>>   fi
>>
>>   $ time ocamp fire ./fib.sh 50
>>   12586269025
>>     real    0m0.391s
>>   user    0m0.153s
>>   sys     0m0.060s
>>
>> ## Build-system
>>
>> `ocamp` provides simple primitives to construct and manage a dependency
>> graph.
>>
>> This might be a saner foundation to base a build-system on than make(1):
>> - the command focus on one specific problem
>> - no dsl is involved; rules can be plain unix commands, including a
>> shell, rather than a make-flavored simulation of shell
>> - nothing is provided for resolving goals; indeed this is better left to
>> tools specifically built for goal-search.
>>
>> A quick'n'dirty script building ocamp itself is provided as an example.
>>
>> # Future
>>
>> The current release is a proof-of-concept and should be considered alpha
>> quality.
>> The two features planned next are a way to make the graph persistent (all
>> data is kept in memory atm) and an interface to debug and/or observe graph
>> construction.
>>
>> Note: code is undergoing legal review and should be available soon \o/
>>
>>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 5524 bytes --]

Re: [Caml-list] [ANN] OCamp - Reactive programming in the shell

[Frédéric Bour]

[-- Attachment #1: Type: text/plain, Size: 5250 bytes --]

I am trying to specialize in /elaborate jokes/ :).

The idea and implementation started as a joke… But with some hindsight, 
this might not be completely inappropriate.
In any case the current implementation is really just a proof of 
concept, not to be trusted at all.

On 02/04/2015 14:19, Anthony Tavener wrote:
> Hah! You were serious? I thought with commands like hipp and stir, and 
> your legal review notice at the end, that this was an April Fool's 
> joke. :)
>
> On Thu, Apr 2, 2015 at 12:38 PM, Frédéric Bour 
> <frederic.bour@lakaban.net <mailto:frederic.bour@lakaban.net>> wrote:
>
>     Code is finally available at:
>     https://github.com/def-lkb/ocamp
>
>     Sorry for the little delay!
>
>
>     On 01/04/2015 22:32, Frédéric Bour wrote:
>
>         OCamp extends unix shells with constructions to express
>         memoization, sharing of computations and reactive programming.
>
>         # Subcommands
>
>         ## fire
>
>         Just wrap a unix command with "ocamp fire" to enable the
>         extension:
>           $ ocamp fire bash
>
>         This will spawn a new bash session where the following
>         subcommands are enabled.
>
>         ## hipp
>
>           $ ocamp hipp <command>
>
>         Will memoize the output and exit status of <command>.
>         Later calls to the same <command> won't lead to actual
>         execution, but just to a duplication of its previous output.
>         Concurrent calls to <command> will just share the same
>         process, the beginning of the output being replayed to later
>         callers.
>
>         The identity of a command is defined by its arguments and
>         working directory.
>
>         ## stir
>
>           $ ocamp stir <command>
>
>         Indicate potential changes in the output if <command> was rerun.
>         Later calls to `hipp` will recompute <command> as if it was
>         not yet memoized.
>
>         ## (un)follow
>
>           $ ocamp follow <command>
>
>         First, <command> is memoized if it was not the case yet.
>         Then changes to dependencies of <command> will trigger a
>         reevaluation.
>         Use `stir` to notify a change.
>
>         (to follow is an hipp/stir reactivity).
>
>         ## pull
>
>           $ ocamp pull <command>
>
>         Closely related to `hipp`, but instead of marking dependency
>         on the output of <command>, the dependency applies to the
>         "effects" of <command>.
>
>         Thus, if `stir` is used:
>         - all pullers will be reevaluated.
>         - hippers will be reevaluated only if the output is different.
>
>         ## Summary
>
>           $ ocamp fire <command> - setup a new session alive until
>         <command> exits
>                   pull <command> - mark dependency on effects of <command>
>                   hipp <command> - mark dependency on output of <command>
>                   stir <command> - notify that <command> might have
>         been updated
>                   follow <command> - eval <command>, and reactively
>         recompute it
>                                      whenever one of its dependencies
>         change.
>                   unfollow <command> - stop recomputing <command> when
>         dependencies
>                                        change
>
>         hipp and pull provide memoization.
>         stir and follow bring a flavor of reactive programming.
>
>         # Examples
>
>         ## Fibonacci
>
>           $ cat fib.sh
>           #!/bin/sh
>           ARG="$1"
>           if [ "$ARG" -le 1 ]; then
>             echo "$ARG"
>           else
>             A=`ocamp hipp ./fib.sh $((ARG-1))`
>             B=`ocamp hipp ./fib.sh $((ARG-2))`
>             echo $((A+B))
>           fi
>
>           $ time ocamp fire ./fib.sh 50
>           12586269025
>             real    0m0.391s
>           user    0m0.153s
>           sys     0m0.060s
>
>         ## Build-system
>
>         `ocamp` provides simple primitives to construct and manage a
>         dependency graph.
>
>         This might be a saner foundation to base a build-system on
>         than make(1):
>         - the command focus on one specific problem
>         - no dsl is involved; rules can be plain unix commands,
>         including a shell, rather than a make-flavored simulation of shell
>         - nothing is provided for resolving goals; indeed this is
>         better left to tools specifically built for goal-search.
>
>         A quick'n'dirty script building ocamp itself is provided as an
>         example.
>
>         # Future
>
>         The current release is a proof-of-concept and should be
>         considered alpha quality.
>         The two features planned next are a way to make the graph
>         persistent (all data is kept in memory atm) and an interface
>         to debug and/or observe graph construction.
>
>         Note: code is undergoing legal review and should be available
>         soon \o/
>
>
>
>     -- 
>     Caml-list mailing list.  Subscription management and archives:
>     https://sympa.inria.fr/sympa/arc/caml-list
>     Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>     Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>


[-- Attachment #2: Type: text/html, Size: 9219 bytes --]