In message <[EMAIL PROTECTED]>
Bart Lateur <[EMAIL PROTECTED]> wrote:
> On Thu, 06 Dec 2001 00:16:34 GMT, Tom Hughes wrote:
>
> >So far I have added as is_digit() call to the character type layer
> >to replace the existing isdigit() calls.
>
> There seems to be an overlap with the /\d
Dan --
> > > Either way is fine with me. Let me know and I'll check in an updated
> > > version...
> >
> >Well, uh, neither, actually. :) I think the implementation of "rotate"
> >is broken, since the parameters to rotate_entries are all stuffed up.
> >I'm amazed this compiles:
> >
> >core_ops.c:
On Thu, Dec 06, 2001 at 01:49:06PM -0500, Dan Sugalski wrote:
> >day jobs. (This would be the first question people would go to when
> >they wanted to confirm that you really are agents of evil corporations
> >intent on destroying our life, liberty, and pursuit of lower perl golf
> >scores.)
>
>
On 6 Dec 2001, Gregor N. Purdy wrote:
> Dan --
> The newly generated queens.pasm doesn't do rotate(). So, that's why
> it succeeds, I guess. I notice that
>
> grep 'clone|restore|save|rotate' *.t
>
> doesn't find any matches in t/op. That makes it real easy for things
> to drift.
There are cer
So for example, open in an int context does a raw open,
open in a scalar or PMC context does a fancy open (buffered
or whatever) and returns a IO object?
Also, if you want the interface to be the same for all
these ops, how do you want callbacks implemented?
1) Are we doing callbacks?
2) If so, I
Alex --
> > The newly generated queens.pasm doesn't do rotate(). So, that's why
> > it succeeds, I guess. I notice that
> >
> > grep 'clone|restore|save|rotate' *.t
> >
> > doesn't find any matches in t/op. That makes it real easy for things
> > to drift.
>
> There are certainly save and resto
At 03:39 PM 12/6/2001 -0500, [EMAIL PROTECTED] wrote:
>So for example, open in an int context does a raw open,
>open in a scalar or PMC context does a fancy open (buffered
>or whatever) and returns a IO object?
Nope. Open always takes a string. We don't get fancy otherwise, though we
may have wa
Simon Cozens writes:
> As mentioned in my other mail, I also edit perl.com for O'Reilly and
> Associates, who probably do have commercial interest in the development
> of Perl.
The other ORA editors keep asking me "should we sign more Perl 5
books? Is Perl 6 going to kill our sales?" and I keep
Tests passed...
---cut here---
new_key S0
clone_key S1,S0
size_key S1,5
key_size I0,S1
print "I0 (3) "
print I0
print "\n"
toss_key S0
#ke_type I1,S1,1
ke_set_value S1,0,5
ke_value I0,S1,0
ke_type I1,S1,0
print "I0 (5) I1 (0): "
print I0
print " "
print I
Brent & Co.,
Is there any reason why we couldn't break up configure (when it comes into
being) into chunks?
The last 5.7.2 grab I have puts the current one at 17.5 Klines. It's
weighty, a beast to maintain, and a beast to keep running through (should
something break halfway.)
Something st
Dan Sugalski sent the following bits through the ether:
> The Zork interpreter might be stack based, thinking about it, but it was
> hardly geared for speed, so I don't know that it'd count if it was.
For what it is worth, in my quest for learning more about VMs I've
taken a detailed look at th
In message <[EMAIL PROTECTED]>
James Mastros <[EMAIL PROTECTED]> wrote:
> Right. Unfornatly, after starting on this, I relized that that's the easy
> part. Unicode has a fairly-well defined way of figuring out if a character
> is a digit (see if it's category is Nd (Number/digit), and i
On Thu, 06 Dec 2001 00:16:34 GMT, Tom Hughes wrote:
>So far I have added as is_digit() call to the character type layer
>to replace the existing isdigit() calls.
There seems to be an overlap with the /\d/ character class in regexes.
Can't you use the same test? Can't you use the definition of th
On Thu, Dec 06, 2001 at 02:17:31AM +, Alex Gough wrote:
> Also, for string -> integer conversion I think we ought to be scanning
> for a float then turning the result into an integer (as 1234.56e2 is
> one).
Does scanning for a float include 1234,56e2 or any other locale specific
representa
From: Andrew J Bromage [mailto:[EMAIL PROTECTED]]
> On Wed, Dec 05, 2001 at 01:23:34PM -0500, Dan Sugalski wrote:
>
> > Besides, the only p-code machine I could think of was UCSD
> > Pascal running on the Apple IIs, and that seemed a bit old
> > to reference.
>
> FWIW, in the last days of Micro
At 11:05 PM 12/5/2001 -0500, Melvin Smith wrote:
>This patch fixes a infinite loop ('./test_prog --' for example) in the
>switch handling in test_prog and also modifies make_interpreter() to pass
>interpreter flags as constructor argument.
Applied, thanks.
At 10:15 AM 12/6/2001 +, Leon Brocard wrote:
>Dan Sugalski sent the following bits through the ether:
>
> > The Zork interpreter might be stack based, thinking about it, but it was
> > hardly geared for speed, so I don't know that it'd count if it was.
>
>For what it is worth, in my quest for
On Thu, Dec 06, 2001 at 12:54:54PM -0500, Dan Sugalski wrote:
> Not that I'm contemplating actually having parrot run z-code natively,
> but... is there anything in the Z machine that we might want to
> steal^Wreproduce?
I for one would like a PCKUP_FONEBOOTH_N_DIE op.
--
Michael G. Schwern
Would we prefer to leave the current system call names as-is (open,close
read,seek) as the direct call through versions and name
the IO routines pio_open, ... or go the route of Perl and do
sys_open, etc. for the raw system call versions and name the Parrot IO
API as the default names (open,close)
Well, it builds. The makefile needs serious abuse, the test harness just
flat doesn't work, and there are warnings about sloppy code all over, but
it builds and runs.
Whups, take that back. queens.pbc ACCVIOs and dies. Damn.
Dan
At 11:40 AM 12/5/2001 -0800, Steve Fink wrote:
>On Wed, Dec 05, 2001 at 11:02:34AM -0500, Dan Sugalski wrote:
> > At 06:29 PM 12/4/2001 -0800, Steve Fink wrote:
> > >Q: What about incremental matching?
> >
> > A: What about it?
>
>Is there any plan to support nonbuffered matching, as in, I have a
On Thu, 2001-12-06 at 13:32, Dan Sugalski wrote:
> Well, it builds. The makefile needs serious abuse, the test harness just
> flat doesn't work, and there are warnings about sloppy code all over, but
> it builds and runs.
>
> Whups, take that back. queens.pbc ACCVIOs and dies. Damn.
Interestin
At 01:19 PM 12/6/2001 -0500, Melvin Smith wrote:
>Would we prefer to leave the current system call names as-is (open,close
>read,seek) as the direct call through versions and name
>the IO routines pio_open, ... or go the route of Perl and do
>sys_open, etc. for the raw system call versions and nam
At 01:47 PM 12/6/2001 -0500, Gregor N. Purdy wrote:
>On Thu, 2001-12-06 at 13:32, Dan Sugalski wrote:
> > Well, it builds. The makefile needs serious abuse, the test harness just
> > flat doesn't work, and there are warnings about sloppy code all over, but
> > it builds and runs.
> >
> > Whups, ta
On Thu, Dec 06, 2001 at 01:47:54PM -0500, Gregor N. Purdy wrote:
> Either way is fine with me. Let me know and I'll check in an updated
> version...
Well, uh, neither, actually. :) I think the implementation of "rotate"
is broken, since the parameters to rotate_entries are all stuffed up.
I'm ama
At 07:07 PM 12/6/2001 +, Simon Cozens wrote:
>On Thu, Dec 06, 2001 at 01:47:54PM -0500, Gregor N. Purdy wrote:
> > Either way is fine with me. Let me know and I'll check in an updated
> > version...
>
>Well, uh, neither, actually. :) I think the implementation of "rotate"
>is broken, since the
Dan Sugalski wrote:
>
> At 12:52 AM 12/5/2001 -0500, Jeff G wrote:
> >The fact that the S registers are in fact generic struct registers is
> >not evident from outside the internal code. For those of us implementing
> >instructions, it might be useful to explicitly cast values like $1 to
> >the c
27 matches
Mail list logo
