Ok, I get it now, thanks Larry.
I do still think that you can do what I suggest, but I realize that it's
not as easy as handing around a single pad, you would actually need to
maintain either a list of pads (outside of the built-in pad stack,
probably inside of C<$0>) or a list of C<$0>s, each wi
On Thu, Sep 02, 2004 at 10:43:48AM -0400, Aaron Sherman wrote:
: On Wed, 2004-09-01 at 17:00, Larry Wall wrote:
: > Okay, except that hypotheticality is an attribute of a variable's
: > value, not of the pad it's in.
:
: Yes, I think I got that part, and perhaps I was being unclear or am
: still m
We still have a lot of unhooked ops w/o a definite opcode number. These
are mainly the non-branching compare opcodes currently located in
ops/experimental.ops.
These opcodes have some limited usefullness for e.g.
bool_val = (a < b) && (c > d)
i.e. for expressions that do not branch on the comp
At 11:23 AM -0400 9/2/04, Andy Dougherty wrote:
I think the correct fix for this issue would be two patches to
Configure.pl: First, given the existing choice for $cc, pick the
appropriate $cxx compiler. Second, given the existing choices for $cc and
$cxx, pick the appropriate value for $link. I d
On Thu, 2004-09-02 at 11:27, Felix Gallo wrote:
> Although the next regex engine has to deal with the horribly
> crufty new perl6 syntax
Keep in mind that Perl 6 regexen are really just Perl 5 regexen with a
call stack and backtracking control. Absolutely everything else that I
see in P6 is eithe
At 12:19 PM -0400 9/2/04, Felix Gallo wrote:
Dan writes:
True enough. Oh, don't get me wrong, I think we can go faster than
the perl 5 regex engine. I just don't think we can do in 2 seconds
what takes perl 5 10 seconds... :-P
Yeah, I meant the other way around.
I know. :)
Lacking any kind of
Dan writes:
> True enough. Oh, don't get me wrong, I think we can go faster than
> the perl 5 regex engine. I just don't think we can do in 2 seconds
> what takes perl 5 10 seconds... :-P
Yeah, I meant the other way around. Lacking any kind of formal
specification for it, my general thought is
At 5:23 PM +0200 9/2/04, Leopold Toetsch wrote:
Dan Hursh <[EMAIL PROTECTED]> wrote:
How about a context->freakish that would allow
rotl Pdest, n, 5 # rotate 5 lowest ordered bits leaving
overkill probably. By 8, 16, 32, 64 ought do it. And that looks too
much.
Yeah. Larry's note about the
At 11:27 AM -0400 9/2/04, Felix Gallo wrote:
Dan writes:
I don't think we're going to be able to manage doing our matches in
20% of the time of the current regex engine. That's a bit ambitious,
even for me. :)
I dunno, there are a number of extant cases of languages that
manage to run regexes ju
On 2 Sep 2004 15:22:39 -, Andy Dougherty via RT
<[EMAIL PROTECTED]> wrote:
> I'm not quite sure if I understand you correctly, since you don't want c++
> if Configure.pl chooses gcc. Perhaps you meant icu's configure would find
> gcc? Or perhaps you mean 'g++' but happen to be calling it 'c++
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> A side point to Dan: In reading P6&PE, I don't see an op for deleting an
> entry from a pad.
$P0 = peek_pad
delete $P0["foo"]
Deleting by index/depth is unimplemented and marked as TODO in
classes/scratchpad.pmc
leo
Dan Hursh <[EMAIL PROTECTED]> wrote:
> How about a context->freakish that would allow
> rotl Pdest, n, 5 # rotate 5 lowest ordered bits leaving
overkill probably. By 8, 16, 32, 64 ought do it. And that looks too
much.
leo
Dan writes:
> I don't think we're going to be able to manage doing our matches in
> 20% of the time of the current regex engine. That's a bit ambitious,
> even for me. :)
I dunno, there are a number of extant cases of languages that
manage to run regexes just as fast as the current regex engine.
On Wed, 1 Sep 2004, Coneill @ Oneill . Net wrote:
> The attached patch fixes the solaris hints file to force the use of
> 'c++' for linking if Configure.pl finds gcc. Without this patch, it
> links with gcc which fails since it apparently can't find some of the
> c++ symbols from icu.
I'm not qu
On Wed, 2004-09-01 at 17:00, Larry Wall wrote:
> : Let's get concrete:
> :
> : rule foo { a $x:=(b*) c }
> : "abbabc"
> :
> : So, if I understand Parrot and Perl 6 correctly (heh, fat chance), a
> : slight modification to the calling convention of the closure that
> : represents a rule (
At 9:56 AM -0400 9/2/04, Felix Gallo wrote:
Dan writes:
[...]
Yes, and some of the initial list already has ops to do those bits,
though I fully plan on evil cheating versions for some extra speed.
If I recall correctly, someone with the best intentions attempted
to write a clear, object-oriente
Dan writes:
> [...]
> Yes, and some of the initial list already has ops to do those bits,
> though I fully plan on evil cheating versions for some extra speed.
If I recall correctly, someone with the best intentions attempted
to write a clear, object-oriented (but still C/C++ based) regex
engine
At 8:24 PM -0700 9/1/04, Steve Fink wrote:
On Sep-01, Dan Sugalski wrote:
This is a list of the semantics that I see as needed for a regex
engine. When we have 'em, we'll map them to string ops, and may well
add in some special-case code for faster access.
*) extract substring
*) exact string
Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
rotl Pdest, n, 32# rotate left in place by n 32-bitwise
These have merit. The only question then is what happens with the
rest of the bits. (If one rotates a 64 bit quantity with a 32-bit
rotate)
First, we should probably as
NB: The links are probably broken at present. Normal service will
hopefully be resumed once Google gets caught up with the perl6 lists.
The Perl 6 Summary for the week ending 2004-08-27
Where does the time go? I blame folk festivals. Once I'm getting busy
with the teacher training I'm goin
20 matches
Mail list logo
