Hi, just my 2¢ for the fanning out of pipes: if I remember correctly,
mycroftiv's hubfs (or some other software in his contrib) allowed one to
do exactly this.
hth
On 08/28/2012 09:41 PM, Dan Cross wrote:
> On Tue, Aug 28, 2012 at 8:56 PM, erik quanstrom wrote:
>>> And rc is not perfect. I've al
On Thu Aug 30 10:56:52 EDT 2012, charles.fors...@gmail.com wrote:
> As another example, also from Flex,
> J M Foster, I F Currie, "Remote Capabilities", The Computer Journal, 30(5),
> 1987, pp. 451-7.
>
> http://comjnl.oxfordjournals.org/content/30/5/451.full.pdf
very intersting. the paper says
On Thu Aug 30 16:08:23 EDT 2012, charles.fors...@gmail.com wrote:
> That's true, but the C compiler also does each .c in parallel up to NPROC.
>
> On 30 August 2012 18:18, erik quanstrom wrote:
>
> > > Even more common than reduce is map. No reason why you can't
> > > parallelize
> > >
> > >
That's true, but the C compiler also does each .c in parallel up to NPROC.
On 30 August 2012 18:18, erik quanstrom wrote:
> > Even more common than reduce is map. No reason why you can't
> > parallelize
> >
> > 8c *.c
>
> we already do—with mk.
>
> Even more common than reduce is map. No reason why you can't
> parallelize
>
> 8c *.c
we already do—with mk.
- erik
On Thu, 30 Aug 2012 15:35:47 +0530 Dan Cross wrote:
> On Wed, Aug 29, 2012 at 7:27 PM, erik quanstrom wrote
> :
> >> > rc already has non-linear pipelines. but they're not very convienient.
> >>
> >> And somewhat limited. There's no real concept of 'fanout' of output,
> >> for instance (though
> Errr ... no. Twice: mash was not VN code but brucee's preemptive strike
> against a POSIX shell for Lucent's Inferno;
> VN's Inferno had a shell with a different style done by Roger Peppe.
I do apologise. Mash was genial! The VN shell was remarkable in a
very different way.
++L
> anyway, a meld of Rc shell and mk? crazy idea.
What was mash?
-sl
The source of mash as VN inherited it from the defunct Lucent organisation
on 1 September 1999 remains in the tree,
so it wasn't lost.
On 30 August 2012 16:13, Charles Forsyth wrote:
>
> On 30 August 2012 16:13, Lucio De Re wrote:
>
>> Inferno (Vitanuova) released a "mash" a ways back, but appar
Errr ... no. Twice: mash was not VN code but brucee's preemptive strike
against a POSIX shell for Lucent's Inferno;
VN's Inferno had a shell with a different style done by Roger Peppe.
On 30 August 2012 16:13, Lucio De Re wrote:
> Inferno (Vitanuova) released a "mash" a ways back, but apparently
>> anyway, a meld of Rc shell and mk? crazy idea.
> Inferno (Vitanuova) released a "mash" a ways back, but apparently the sources
> were lost. It was mind-bogglingly interesting!
In case anyone's interested (like I was):
http://www.vitanuova.com/inferno/man/1/mash.html
--
Burton Samograd
Thi
> anyway, a meld of Rc shell and mk? crazy idea.
Inferno (Vitanuova) released a "mash" a ways back, but apparently the
sources were lost. It was mind-bogglingly interesting!
++L
As another example, also from Flex,
J M Foster, I F Currie, "Remote Capabilities", The Computer Journal, 30(5),
1987, pp. 451-7.
http://comjnl.oxfordjournals.org/content/30/5/451.full.pdf
On 30 August 2012 15:45, Charles Forsyth wrote:
> If you look at the paper I referenced, you will. Similar
On Thursday 30 of August 2012 10:41:38 erik quanstrom wrote:
> what i was saying is that mk knows and insures that the output files
> are there. the fact that it's not in the middle of the conversation is
> an implementation detail, imho.
>
> that is, mk is built on the assumption that programs
On Thu Aug 30 10:28:24 EDT 2012, cro...@gmail.com wrote:
> > said another way, we already have typed streams, but they're not
> > enforced by the operating system.
>
> Yes, but then every program that participates in one of these
> computation networks has to have that type knowledge baked in. Th
If you look at the paper I referenced, you will. Similar abilities appeared
in systems that supported persistence and persistent programming
languages (cf. Malcolm Atkinson, not Wikipedia).
On 30 August 2012 14:33, erik quanstrom wrote:
> i don't see that the os can really help here.
> On Thu, Aug 30, 2012 at 7:56 PM, erik quanstrom wrote:
> >> The thing is that mk doesn't really do anything to set up connections
> >> between the commands it runs.
> >
> > it does. the connections are through the file system.
>
> No. The order in which commands are run (or if they are run at
> Hmm, I'm afraid I'm off in the realm of thinking out loud at this
> point. Sorry if that's noisy for folks.
THANK YOU. if 9fans needs anything, it's more thinking.
i'm not an edison fan, but i do like one thing he said, which was
that he had not failed, but simply discovered that the $n ways
On Thu, Aug 30, 2012 at 7:56 PM, erik quanstrom wrote:
>> The thing is that mk doesn't really do anything to set up connections
>> between the commands it runs.
>
> it does. the connections are through the file system.
No. The order in which commands are run (or if they are run at all)
is based
> > grep -b. but in general if the bio library had an option to output
> > line-wise, then the problem could be avoided. otherwise, one would need to
> > mux the output.
>
>
> to quote you, erik,
> > pipes still preserve write boundaries, as does il
>
> so, hopefully, a dumb pipe to cat would
On Thu, Aug 30, 2012 at 7:03 PM, erik quanstrom wrote:
>> rejected such system-imposing structure on files in Unix-y type
>> environments since 1969.
> [...]
>> other threads of execution. Could we do something similar with pipes?
>> I don't know that anyone wants typed file descriptors; that wo
> The thing is that mk doesn't really do anything to set up connections
> between the commands it runs.
it does. the connections are through the file system.
- erik
On Thursday 30 of August 2012 09:47:59 you wrote:
> > caveat: output of one grep instance could end up in the midst of a /line/
> > of output of another grep instance.
>
> grep -b. but in general if the bio library had an option to output
> line-wise, then the problem could be avoided. otherwise
On Thu, Aug 30, 2012 at 7:51 PM, Dan Cross wrote:
> A parallel apply sort of thing could be used with xargs, of course;
> 'whatever | xargs papply foo' could keep some $n$ of foo's running at
> the same time. The magic behind 'papply foo `{whatever}' is that it
> knows how to interpret its argume
On Thu, Aug 30, 2012 at 7:11 PM, dexen deVries wrote:
> On Thursday 30 of August 2012 15:35:47 Dan Cross wrote:
>> (...)
>> Your example of running multiple 'grep's in parallel sort of reminded
>> me of this, though it occurs to me that this can probably be done with
>> a command: a sort of 'paral
> caveat: output of one grep instance could end up in the midst of a /line/ of
> output of another grep instance.
grep -b. but in general if the bio library had an option to output line-wise,
then the problem could be avoided. otherwise, one would need to mux the
output.
- erik
On Thursday 30 of August 2012 15:35:47 Dan Cross wrote:
> (...)
> Your example of running multiple 'grep's in parallel sort of reminded
> me of this, though it occurs to me that this can probably be done with
> a command: a sort of 'parallel apply' thing that can run a command
> multiple times conc
> rejected such system-imposing structure on files in Unix-y type
> environments since 1969.
[...]
> other threads of execution. Could we do something similar with pipes?
> I don't know that anyone wants typed file descriptors; that would
> open a whole new can of worms.
i don't see that the os
typed command languages:
I F Currie, J M Foster, Curt: The Command Interpreter Language for Flex
http://www.vitanuova.com/dist/doc/rsre-3522-curt.pdf
On Wed, Aug 29, 2012 at 7:27 PM, erik quanstrom wrote:
>> > rc already has non-linear pipelines. but they're not very convienient.
>>
>> And somewhat limited. There's no real concept of 'fanout' of output,
>> for instance (though that's a fairly trivial command, so probably
>> doesn't count), or
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.78.5331
Paul Haeberli, ConMan: A Visual Programming Language for Interactive
Graphics (1988)
I supervised a student who did an implementation for a Blit-like
environment on the Sun3 as a project;
unfortunately I didn't keep a copy. I remember
> > rc already has non-linear pipelines. but they're not very convienient.
>
> And somewhat limited. There's no real concept of 'fanout' of output,
> for instance (though that's a fairly trivial command, so probably
> doesn't count), or multiplexing input from various sources that would
> be nee
On Wed, Aug 29, 2012 at 2:04 AM, erik quanstrom wrote:
>> > the haahr/rakitzis es' if makes more sense, even if it's wierder.)
>>
>> Agreed; es would be an interesting starting point for a new shell.
>
> es is great input. there are really cool ideas there, but it does
> seem like a lesson learne
On Wednesday 29 of August 2012 09:06:35 arisawa wrote:
> Hello,
>
> On 2012/08/29, at 4:34, dexen deVries wrote:
> > now i see i can do:
> >
> > x=1 y=2 z=3
> >
> > ...and only `z' retains its new value in the external scope, while `x' and
> > `y' are limited in scope.
>
> No.
>
> ar% a=1 b=2
On Tuesday 28 of August 2012 16:34:10 erik quanstrom wrote:
> my knee-jerk reaction to my own question is that making it easier
> and more natural to parallelize dataflow. a pipeline is just a really
> low-level way to talk about it. the standard
> grep x *.[ch]
> forces all the *.[ch] to b
> > > > > The feature I want is the ability to pass not just character
> > > > > values in environment or pipes but arbitrary Scheme objects.
> > > > > But that requires changes at the OS level (or mapping them
> > > > > to/from strings, which is a waste if both sides can handle
> > > > > structure
On Tue, 28 Aug 2012 22:23:20 EDT erik quanstrom wrote:
> > On Tue, 28 Aug 2012 21:39:06 EDT erik quanstrom wr
> ote:
> > > > The feature I want is the ability to pass not just character
> > > > values in environment or pipes but arbitrary Scheme objects.
> > > > But that requires changes at the
> On Tue, 28 Aug 2012 21:39:06 EDT erik quanstrom
> wrote:
> > > The feature I want is the ability to pass not just character
> > > values in environment or pipes but arbitrary Scheme objects.
> > > But that requires changes at the OS level (or mapping them
> > > to/from strings, which is a wast
On Tue, 28 Aug 2012 21:39:06 EDT erik quanstrom wrote:
> > The feature I want is the ability to pass not just character
> > values in environment or pipes but arbitrary Scheme objects.
> > But that requires changes at the OS level (or mapping them
> > to/from strings, which is a waste if both sid
> var:[^ctl-a]*
> | ([^ctl-a]*) ctl-a list
sorry. s/list/var/
- erik
> The feature I want is the ability to pass not just character
> values in environment or pipes but arbitrary Scheme objects.
> But that requires changes at the OS level (or mapping them
> to/from strings, which is a waste if both sides can handle
> structured objects).
!? the ability to pass typ
> On Tue, 28 Aug 2012 16:34:10 EDT erik quanstrom
> wrote:
> > my knee-jerk reaction to my own question is that making it easier
> > and more natural to parallelize dataflow. a pipeline is just a really
> > low-level way to talk about it. the standard
> > grep x *.[ch]
> > forces all the *
Hello,
On 2012/08/29, at 4:34, dexen deVries wrote:
> now i see i can do:
>
> x=1 y=2 z=3
>
> ...and only `z' retains its new value in the external scope, while `x' and
> `y'
> are limited in scope.
No.
ar% a=1 b=2 c=3; echo $a $b $c
1 2 3
ar% a=() b=() c=()
ar% a=1 b=2 {c=3}; echo $a $b $c
On Tue, 28 Aug 2012 16:34:10 EDT erik quanstrom wrote:
> my knee-jerk reaction to my own question is that making it easier
> and more natural to parallelize dataflow. a pipeline is just a really
> low-level way to talk about it. the standard
> grep x *.[ch]
> forces all the *.[ch] to be g
> > the haahr/rakitzis es' if makes more sense, even if it's wierder.)
>
> Agreed; es would be an interesting starting point for a new shell.
es is great input. there are really cool ideas there, but it does
seem like a lesson learned to me, rather than a starting point.
> I think in order to r
On Wed, 29 Aug 2012 01:11:26 +0530 Dan Cross wrote:
> On Tue, Aug 28, 2012 at 8:56 PM, erik quanstrom wro=
>
> > perhaps (let's hope) someone else has better ideas.
>
> Well, something off the top of my head: Unix pipelines are sort of
> like chains of coroutines. And they work great for defi
> But something that may be interesting would
> be the ability to allow the stream of computations to branch; instead
> of pipelines being just a list, make them a tree, or even some kind of
> dag (if one allows for the possibility of recombining streams).
Rc has this. It's great. See section 10 o
On Tue, 28 Aug 2012 14:44:40 EDT erik quanstrom wrote:
> >=20
> > switch/case would make helluva difference over nested if/if not, if
> > defaulted to fall-through.
>
> maybe you have an example? because i don't see that. if not works
> fine, and can be nested. case without fallthrough is als
On Tue, Aug 28, 2012 at 8:56 PM, erik quanstrom wrote:
>> And rc is not perfect. I've always felt like the 'if not' stuff was a
>> kludge.
>
> no, it's certainly not. (i wouldn't call if not a kludge—just ugly.
Kludge perhaps in the sense that it seems to be to work around an
issue with the gr
On Tuesday 28 of August 2012 14:44:40 erik quanstrom wrote:
> (...)
> > variable scoping (better than subshel) would help writing larger
> > scripts, but that's not necessarily an improvement ;-) something
> > similar to LISP's `let' special form, for dynamic binding.
>
> there is variable scoping
>
> switch/case would make helluva difference over nested if/if not, if
> defaulted to fall-through.
maybe you have an example? because i don't see that. if not works
fine, and can be nested. case without fallthrough is also generally
what i want. if not, i can make the common stuff a functio
51 matches
Mail list logo
