Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> On Mon, Jan 08, 2001 at 01:24:06PM +, David Grove wrote:
> > This was the subject of a list and an RFC. I'd hope not to see what we
> > worked hard to come up with not go to waste, guys and gals. We came up
> > with a "least of all evils" solution
[Snipped perl-internals, this is off topic there]
Simon Cozens <[EMAIL PROTECTED]> wrote:
> I do not think that Bradley is suggesting that Perl would "go more GPL",
> because that would be indefensibly insane.
That is correct. Someone else did propose that, and it forked a tangent
about defens
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, AFAIK. The
only RFC about licensing that went in was (
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, I'm not certian that I'm completly following here. It seems that in
the v
> The only thing I remark is that I believe all of Perl should be the
> most exposed possible, so that unseen levels of introspection
> can be achieved. In that philosophy I wrote my idea about
> exposing the engine's guts.
I'm well-known as a non-delving-into-the-guts type of guy. I
Damian Conway wrote:
> # As Branden proposes:
>
> package From_STDIN;
>
> sub new { bless $_[1], $_[0] }
>
> sub MORE_DATA { $_[0]->getn($_[1]) }
> sub ON_FAIL { $_[0]->pushback($_[1]) }
>
> use overload "=~" => 1;
>
> package main;
>
> From_STDIN->new($fh) =~ /pat/;
>
>
>H. Potential
Damian Conway wrote:
>
> Branden wrote:
>
>> Then, what you proposed in RFC 93 through
>>
>> sub { ... } =~ m/.../;
>>
>> could be handled by
>>
>> my $mymatch = MyClassForMatchingFromFileHandles->new($myhandle);
>> $mymatch =~ m/.../;
>
> This is an
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 threads OR async I/O are available.
Is this portable enough for Perl? Ar
Branden wrote:
> I read your RFC 93. It mentions using a sub to read from the
> string. I just think it uses the sub in two conflicting ways, one
> for requesting more data from the stream and other for telling
> there was a match.
It's really using the sub as a interface to whatever
On Tue, Jan 09, 2001 at 09:53:10AM +1100, Damian Conway wrote:
>
>> I once brutalized Henry Spencer's engine into telling me when I was
>> on my way to a match. This was for a UI: I wanted to be able to say
>> that the input should only match this RE, and if they typed something
>
> I once brutalized Henry Spencer's engine into telling me when I was
> on my way to a match. This was for a UI: I wanted to be able to say
> that the input should only match this RE, and if they typed something
> that broke the match, I could beep and disallow the character.
>
On Mon, Jan 08, 2001 at 01:24:06PM +, David Grove wrote:
> This was the subject of a list and an RFC. I'd hope not to see what we
> worked hard to come up with not go to waste, guys and gals. We came up
> with a "least of all evils" solution, I think, and I feel very strongly
Where can this s
Good morning.
I've been thinking about defining atomic code units for a while, and I
even posted something about it to p5p a few years back. The idea has
matured since then, and I'd like to quickly outline it here:
I've been defining code atoms using three rules:
1. Atoms begin at branch desti
This was the subject of a list and an RFC. I'd hope not to see what we
worked hard to come up with not go to waste, guys and gals. We came up
with a "least of all evils" solution, I think, and I feel very strongly
that not protecting Perl from outright theft, especially using very iffy
licenses al
I have an idea. Send that japanese to Larry and have him translate it.
However he translates it, it's official.
p
Jeff Okamoto <[EMAIL PROTECTED]> wrote:
> > On Fri, Jan 05, 2001 at 09:42:12PM -0500, Brian Finney wrote:
> > > say we start with this number
> > > 123,456,789
> > >
> > > one
> On Fri, Jan 05, 2001 at 09:42:12PM -0500, Brian Finney wrote:
> > say we start with this number
> > 123,456,789
> >
> > one hundred twenty-three million four hundred fifty-six thousand seven hundred
> > eighty-nine
>
> satakaksikymmentäkolme miljoonaa neljäsataaviisikymmentäkuusi tuhatta
> sei
> "NI" == Nick Ing-Simmons <[EMAIL PROTECTED]> writes:
NI> Bart Lateur <[EMAIL PROTECTED]> writes:
>>
>> Apropos safe signals, isn't it possible to let perl6 handle avoiding
>> zombie processes internally? What use does having to do wait() yourself,
>> have anyway?
NI> Valid poi
Bart Lateur <[EMAIL PROTECTED]> writes:
>
>Apropos safe signals, isn't it possible to let perl6 handle avoiding
>zombie processes internally? What use does having to do wait() yourself,
>have anyway?
Valid point - perl could have a CHLD handler in C and stash away returned
status to pass to wait(
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 01:02 PM 1/6/01 -0500, Uri Guttman wrote:
>>that is what i would expect form a simple flag test and every N tests
>>doing a full event poll. and even up to 5-10% slowdown i would think is
>>a good tradeoff for the flexibilty and ease of design win we ge
Simon Cozens <[EMAIL PROTECTED]> writes:
>On Fri, Jan 05, 2001 at 11:42:32PM -0500, Uri Guttman wrote:
>> SC> 5x slowdown.
>>
>> not if you just check a flag in the main loop. you only check the event
>> system if you have pending events or signals, etc. the key is not
>> checking all events o
At 12:09 PM 1/6/01 -0600, Jarkko Hietaniemi wrote:
> > Some of this ground does need to be revisited, since perl 6 isn't going to
> > be perl 5, and the tradeoffs are going to be different. (I'm still not
> sure
> > that checking for pending events every opcode is the way to go, either.
> > Piggy
Nicholas Clark <[EMAIL PROTECTED]> writes:
>> sure if there are any non-two's complement machines out there anymore,
>
>However, as perl5 has a few 2s complement assumptions already polluting the
>source, unless we can find a 1s complement (or other) machine to test on, it
>seems sensible (to me
> But yes, I see no way to put perl solely under the GPL. That's just about
> the worst thing we could do, aside from making perl non-"free."
This is now *way way* off topic for perl6-internals. A relevant issue for
perl6-internals had been whether we could or should rely on an LPGL
library (gm
Damian wrote:
>
> I once wrote a C++-based regex engine (much simpler than Perl's!)
> just like this.
>
> Knowing why a regex failed *is* invaluable when matching regexes
> against file streams, but there are more possibilities than you
> mentioned:
>
> "Failed"Did n
On Mon, Jan 08, 2001 at 11:39:11AM +0100, Bart Lateur wrote:
> >This is the Perl interpreter:
> >while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
> >PERL_ASYNC_CHECK();
> >}
> >
> >The only problem is that right now, PERL_ASYNC_CHECK doesn't actually
> >do anything. :)
>
> I
On Sat, 6 Jan 2001 00:45:11 +, Simon Cozens wrote:
>No, it's exactly what Perl 5 does.
>
>This is the Perl interpreter:
>while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
>PERL_ASYNC_CHECK();
>}
>
>The only problem is that right now, PERL_ASYNC_CHECK doesn't actually
>do a
26 matches
Mail list logo
