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
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
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
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
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
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
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
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
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.)
>
>
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:
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
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
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 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
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
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 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
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
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)
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
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
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.
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
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
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
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
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
27 matches
Mail list logo
