John van V <[EMAIL PROTECTED]> wrote:
> I was really amused to see RMS and Eric Raymond agree for the first time
> in history where Chinese Linux companies were pirating the OS.
I actually doubt RMS agreed that they were "pirating". I am sure he would
have used the word "copyright infringement"
> As Rick pointed out, there's no problem with overloading =~ for an
> object, in the same way it's done with `eq', and one object's
> function could return either an object or a closure (a sub
> reference), so that a module could even hide the details of whether
> it's using the ob
Copied from p5p as it seemed kinda relevant.
Dan Sugalski wrote:
> >Roll on perl6...
>
> Well, besides "Just don't *do* that," any thoughts on how to handle this
> properly in p6?
Hmm. I've been half-following the async IO and signals thread in
perl6-internals. The first thing I would say is
Last year at the Open Source Expo in NY, I was really amused to see RMS and Eric
Raymond agree for the first time in history where Chinese
Linux companies were pirating the OS.
But how can you pirate free s/w ??? Makes no sense to the lay reader; in the end it
will be average people who supp
> Respectfully, as with the other
> issues, let's please give Larry his time at bat with the RFC as it stands
> rather than second guessing ourselves again redundantly after the fact.
very good, here's your lollipop ;)
> "RC" == Rocco Caputo <[EMAIL PROTECTED]> writes:
RC> Re: Writing the subsystems together.
RC> I think you misunderstand the other message's intent. The main loop,
RC> the interpreter, and I/O, are three separate subsystems. I think
RC> everyone agrees with you that they should b
Rocco Caputo wrote:
> Re: Writing the subsystems together.
>
> I think you misunderstand the other message's intent. The main loop,
> the interpreter, and I/O, are three separate subsystems. I think
> everyone agrees with you that they should be interchangeable, but
> their public interfaces are
On Mon, 8 Jan 2001 23:12:15 -0200, Filipe Brandenburger wrote:
>Rocco Caputo wrote:
>
>> ...
>> [ *** code *** ]
>>
>>This could very well be an event driven program, with all the tedious
>>mucking about with callbacks done under the hood. Regardless, it could
>>run the same as long as either th
At 0:59 -0500 2001.01.09, Bradley M. Kuhn wrote:
>Chris Nandor <[EMAIL PROTECTED]> wrote:
>
>> True, unless we stick to the same licensing scheme we have today for perl,
>> which, like it or not, has served Perl very, very well.
>
>As it turns out, this isn't an RFC under consideration by Larry, A
On Tue, Jan 09, 2001 at 12:41:30AM -0500, James Mastros wrote:
> On Mon, Jan 08, 2001 at 05:02:17PM -0600, Jarkko Hietaniemi wrote:
> > Wouldn't an incremental on-demand engine be much
> > more flexible and optimizable (e.g. finding 'the fast path' smells
> > like input-driven LRU to me)?
>
> Umm,
Damian Conway wrote:
>I'm well-known as a non-delving-into-the-guts type of guy. I don't have
I totally aggree with you that delving into the guts is the last thing we,
the people that use perl as a tool, want to do! The fact is that, the least
we know about the internals, the better
Nicholas Clark wrote:
>Branden wrote:
>> That's actually something I'd like to say about this ``subsystem''-based
>> design of perl6. For it to be successful, it's imperative that all the
>> modules
>> don't know about each other, so that it's possible to replace a subsystem
>> c
On Mon, Jan 08, 2001 at 11:12:15PM -0200, Filipe Brandenburger wrote:
> Rocco Caputo wrote:
>
> > ...
> > [ *** code *** ]
> >
> >This could very well be an event driven program, with all the tedious
> >mucking about with callbacks done under the hood. Regardless, it could
> >run the same as lon
On Mon, Jan 08, 2001 at 11:12:15PM -0200, Filipe Brandenburger wrote:
> In the other way around, what matters to the design of the file i/o
> subsystem is exactly the same thing: whether it will or won't be using
> blocking syscalls. I believe after the decision of whether we will or not
> allow b
14 matches
Mail list logo
