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
The observation was that people at the time were adding clumsy
programming-language features to make,
which then executed commands it didn't really understand (ie, couldn't even
parse them),
and might it not be better just to add dependency operators (and others as
needed) to a well-designed comman
On Thursday 30 of August 2012 15:36:36 Jason Catena wrote:
> >>> 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
>>> 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
I kept expecting
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
> The basis does
> not request ftp.
I apologise for working with too little information. I have long
wanted to have TeX installed for the rare occasions when I want to
explore the TeX Book, so I took a chance. I'm waiting to find the
energy to solve the libc/libm/libl problem I encountered :-)
[Special to Lucio: Email to proxima.alt.za from Google's SMTP servers
is failing; it looks like they're listed in rbl.proxima.alt.za.]
On Thu, Aug 30, 2012 at 3:56 PM, Lucio De Re wrote:
>> But as I said, this is not to argument about Go developers' choices:
>> they do as they see fit
>
> I think
On Thu, Aug 30, 2012 at 12:26:26PM +0200, Lucio De Re wrote:
>
> For example, the kerTeX installation relies on an ftp client that
> accepts a URL on the command line.
Slight correction: this is not the kerTeX installation, this is sugar
for simplifying installation in the most common cases. The
> But as I said, this is not to argument about Go developers' choices:
> they do as they see fit
I think their philosophy is sound, not just an arbitrary choice. The
alternative is a commitment that can only be fulfilled by applying
resources best utilised on the focal issue.
For example, the ke
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
On Thu, Aug 30, 2012 at 09:41:14AM +0200, Lucio De Re wrote:
>
> The difficult bit for argumentative people to grasp is that the Go
> Team use features that are portable across bourne-like shells, they
> just refuse to commit to that level of compatibility. On the one
> hand, requiring Bash gives
> I am not familiar with the use of Bash in Go; I suspect that they stick
> to stuff that will work across Baash versions though.
The difficult bit for argumentative people to grasp is that the Go
Team use features that are portable across bourne-like shells, they
just refuse to commit to that lev
Lucio De Re wrote:
> All Bashes are equal,
Even this isn't true. Bash is at 4.2 and people still report "issues"
with 3.x. (Same with gawk; gawk is at 4.0.1, people still send it bug reports
about 3.1.3, which is 10 years old!)
I am not familiar with the use of Bash in Go; I suspect that they
39 matches
Mail list logo
