On Wed, Jan 09, 2002 at 04:42:51PM +, Graham Barr wrote:
> On Tue, Jan 08, 2002 at 06:38:02PM -0500, Dan Sugalski wrote:
> > ># Attributes are done as a hash of hashes. Each interpreter has a
> > ># pointer to an attribute hash, whose keys are the attribute names. The
> > ># values will be has
If I apply the global_setup change it works a touch better...
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and ev
At 03:16 AM 1/9/2002 -0800, Brent Dax wrote:
>Okay, here it is. Attached is the regular expression patch. It
>currently segfaults on Windows because of a combination of two factors:
>
> 1) There are some bounds-checking issues in key.c
> 2) Windows's malloc() isn't as robust as Unix's
I've ap
On Mon, Jan 07, 2002 at 09:34:05PM +, Nicholas Clark wrote:
> I believe that this patch gets all of these:
Yes, right:
> --- ./include/parrot/vtable.h~Mon Jan 7 20:38:08 2002
> +++ ./include/parrot/vtable.h Mon Jan 7 20:42:43 2002
What's an RCS header doing in an auto-generated fi
On Wed, Jan 09, 2002 at 12:44:45PM -0800, Brent Dax wrote:
> Steve Fink:
> # On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote:
> #
> # Also, why specific opcodes for \w etc.? I would think you'd do those
> # as constants. (Constant bitmaps for 8-bit, or constant
> # MultiLevelFunkyThings
Thanks Gregor,
I think I'm the only one in the dark, Dan just has to handle what I send
him
since I don't have commit privs, so, heretofore, I've been unsure of
how CVS worked with the remote repository when I can't commit my own
changes. Basically what I've been doing is just checking out a CVS
Steve Fink:
# On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote:
# > Okay, here it is. Attached is the regular expression patch. It
#
# Is rx_advance necessary? What's the difference between
#
# /R/
#
# and
#
# /^(.*?R)/
#
# if you count the parens $& $1 $2 ... instead of $1 $2 $3 ..
This time in perlarray.pmc; they're both simple off-by-one errors.
Patch below fixes.
I've also added a regression test to guard against the reoccurence of
the bug. I've put this, plus the existing PerlArray tests, in a separate
file, pmc_perlarray.t, in line with what we've done for hashe
Dan, Melvin and Co. --
I find that if I've used cvs add and cvs remove for any added or removed
files, I can create a patch quite nicely from the root directory thusly:
$ cvs -q diff -NauR > ../foo.patch
YMMV.
Regards,
-- gregor
___
On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote:
> Okay, here it is. Attached is the regular expression patch. It
Is rx_advance necessary? What's the difference between
/R/
and
/^(.*?R)/
if you count the parens $& $1 $2 ... instead of $1 $2 $3 ...?
Speed, I guess?
(Okay, I r
At 02:55 PM 1/9/2002 -0500, Melvin Smith wrote:
>I suspect its the diff flags I use when I send to Dan. I use -urN (or
>--newfile)
>which should create the new file if it doesn't exist but this happened last
>time
>I made a new file as well. That always worked when I used to send patches
>to linu
I suspect its the diff flags I use when I send to Dan. I use -urN (or
--newfile)
which should create the new file if it doesn't exist but this happened last
time
I made a new file as well. That always worked when I used to send patches
to linux-kernel but I guess I could get with the program and
At 01:50 PM 1/9/2002 -0600, David M. Lloyd wrote:
>On Wed, 9 Jan 2002, Dan Sugalski wrote:
>
> > At 02:39 PM 1/9/2002 -0500, Melvin Smith wrote:
> > >Must be Dan's magic fingers again. I renamed io_os.c to io_unix.c but
> > >probably
> > >it got lost in the shuffle.
> >
> > Weird. It's in my local
At 02:50 PM 1/9/2002 -0500, Melvin Smith wrote:
>Just resynced, still missing io/io_unix.c, interestingly the other new file
>in the patch
>(io_win32.c) made it in.
Gah, I was looking at the manifest file--I thought that's where I'd
forgotten the change. Just added and committed io/io_unix.c to
On Wed, 9 Jan 2002, Dan Sugalski wrote:
> At 02:39 PM 1/9/2002 -0500, Melvin Smith wrote:
> >Must be Dan's magic fingers again. I renamed io_os.c to io_unix.c but
> >probably
> >it got lost in the shuffle.
>
> Weird. It's in my local MANIFEST from the patch, and CVS is convinced
> that it's up to
Just resynced, still missing io/io_unix.c, interestingly the other new file
in the patch
(io_win32.c) made it in.
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
(Embedded
At 02:39 PM 1/9/2002 -0500, Melvin Smith wrote:
>Must be Dan's magic fingers again. I renamed io_os.c to io_unix.c but
>probably
>it got lost in the shuffle.
Weird. It's in my local MANIFEST from the patch, and CVS is convinced that
it's up to date. Resync?
>To: Parrot Internals <[EMAIL PROTE
Must be Dan's magic fingers again. I renamed io_os.c to io_unix.c but
probably
it got lost in the shuffle.
-Melvin Smith
IBM :: Atlanta Innovation Center
[EMAIL PROTECTED] :: 770-835-6984
(Embedded
Revision 1.89 of MANIFEST introduced io/io_unix.c, but configure dies
becuase the file isn't there...
- D
<[EMAIL PROTECTED]>
At 07:19 PM 1/9/2002 +, Simon Glover wrote:
>On Wed, 9 Jan 2002, Dan Sugalski wrote:
>
> > At 07:15 PM 1/9/2002 +, Simon Glover wrote:
> > > OK, I think I've got it this time. The previous patch uncovered a bug in
> > > perlhash.pmc; index is actually the offset of a particular key pai
On Wed, 9 Jan 2002, Dan Sugalski wrote:
> At 07:15 PM 1/9/2002 +, Simon Glover wrote:
> > OK, I think I've got it this time. The previous patch uncovered a bug in
> > perlhash.pmc; index is actually the offset of a particular key pair
> > within the perlhash structure, so we need to ensu
At 07:15 PM 1/9/2002 +, Simon Glover wrote:
> OK, I think I've got it this time. The previous patch uncovered a bug in
> perlhash.pmc; index is actually the offset of a particular key pair
> within the perlhash structure, so we need to ensure that key->size is
> bigger than index.
This pa
On Wed, 9 Jan 2002, Dan Sugalski wrote:
> At 06:39 PM 1/9/2002 +, Simon Glover wrote:
>
> > On Wed, 9 Jan 2002, Simon Glover wrote:
> >
> > > Two separate bugs:
> > >
> > > 1. The index checks should use && and not ||, or else they'll always be
> > > true.
> > >
> > > 2. The check in
At 05:40 PM 1/9/2002 +, Simon Glover wrote:
> fromsize and tosize are both UINTVALs, so copysize should be one too.
Applied, thanks.
Dan
--"it's like this"---
Dan Sugalski e
At 06:39 PM 1/9/2002 +, Simon Glover wrote:
> On Wed, 9 Jan 2002, Simon Glover wrote:
>
> > Two separate bugs:
> >
> > 1. The index checks should use && and not ||, or else they'll always be
> > true.
> >
> > 2. The check in key_inc has an off-by-one error.
> >
> > Simon
> >
>
> Better
On Wed, 9 Jan 2002, Simon Glover wrote:
> Two separate bugs:
>
> 1. The index checks should use && and not ||, or else they'll always be
> true.
>
> 2. The check in key_inc has an off-by-one error.
>
> Simon
>
Better hold off on applying this patch; it makes test 5 in perlhash.t
fa
Two separate bugs:
1. The index checks should use && and not ||, or else they'll always be
true.
2. The check in key_inc has an off-by-one error.
Simon
--- key.c.old Wed Jan 9 17:58:59 2002
+++ key.c Wed Jan 9 18:01:33 2002
@@ -225,7 +225,7 @@
INTVAL key_element_type(struct
fromsize and tosize are both UINTVALs, so copysize should be one too.
Simon
--- memory.c.oldWed Jan 9 17:36:41 2002
+++ memory.cWed Jan 9 17:37:44 2002
@@ -81,7 +81,7 @@
void *
mem_realloc(void *from, UINTVAL fromsize, UINTVAL tosize) {
-INTVAL copysize = (fromsize > tos
On Wed, 9 Jan 2002, Dan Sugalski wrote:
> At 10:56 AM 1/9/2002 -0500, Andy Dougherty wrote:
> >For perl5, the main makefile calls (essentially)
> >
> > $(CC) -o perl
> >
> >while the parrot Makefile calls
> >
> > $(LD) -o test_main
> >
> >I tend to think parrot's wrong here, but t
At 02:22 AM 1/9/2002 -0500, Josh Wilmes wrote:
>I'll see what I can do as far as upgrading my lcc installation or
>reporting this as a bug to the lcc people. But for now, here is a
>workaround for this error, just to get the tinderbox going again:
Applied, thanks.
At 08:32 AM 1/9/2002 -0600, David M. Lloyd wrote:
>This patch adds macros to the config.h file for INTVAL and NUMVAL printf
>formats; I called them INTVAL_FMT and NUMVAL_FMT, although if those names
>are not appropriate I won't sweat it.
Applied, thanks.
D
At 10:56 AM 1/9/2002 -0500, Andy Dougherty wrote:
>On Wed, 9 Jan 2002, H . Merijn Brand wrote:
>
> > HP-UX is very unwilling at this stage, including two show-stoppers
> >
> > 1. The LDFLAGS is extended with flags from config that are meant to be
> passed
> >to cc, not to ld
>
>Odd. On most
On Tue, Jan 08, 2002 at 06:38:02PM -0500, Dan Sugalski wrote:
> ># Attributes are done as a hash of hashes. Each interpreter has a
> ># pointer to an attribute hash, whose keys are the attribute names. The
> ># values will be hash pointers. Those hashes will each have a key which
> ># is a PMC poi
On Wed, 9 Jan 2002, H . Merijn Brand wrote:
> HP-UX is very unwilling at this stage, including two show-stoppers
>
> 1. The LDFLAGS is extended with flags from config that are meant to be passed
>to cc, not to ld
Odd. On most Unix systems, $Config{ld} = 'cc'. Calling ld directly is
usuall
At 01:49 PM 1/9/2002 +, Nicholas Clark wrote:
>On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote:
> > 2) Windows's malloc() isn't as robust as Unix's
>
>In what way? Windows malloc() is getting upset with buggy allocations that
>a Unix malloc() will typically stomach? [ie perl6 bugs]
On Wed, Jan 09, 2002 at 03:16:40AM -0800, Brent Dax wrote:
> 2) Windows's malloc() isn't as robust as Unix's
In what way? Windows malloc() is getting upset with buggy allocations that
a Unix malloc() will typically stomach? [ie perl6 bugs]
or Windows malloc() is getting upset with legal but awkw
This patch adds macros to the config.h file for INTVAL and NUMVAL printf
formats; I called them INTVAL_FMT and NUMVAL_FMT, although if those names
are not appropriate I won't sweat it.
The detection mechanism is not that fancy. It just reads what you have
in $c{iv} and $c{nv} and hopefully recog
HP-UX is very unwilling at this stage, including two show-stoppers
1. The LDFLAGS is extended with flags from config that are meant to be passed
to cc, not to ld
2. Undefined symbols inhibit the basic build
a5:/pro/3gl/CPAN/parrot-current 101 > perl Configure.pl --default
Parrot Version 0.0.3
Okay, here it is. Attached is the regular expression patch. It
currently segfaults on Windows because of a combination of two factors:
1) There are some bounds-checking issues in key.c
2) Windows's malloc() isn't as robust as Unix's
This is only a problem on native Windows, not on Cygwin; I'
> ---
>
> We need private methods for objects.
>
> ---
just a comment on how this is done for ruby:
#initially objects are created with a given class
#say aFoo is an instance of class Foo
aFoo = Foo.new
#then we can add methods to aFoo
def aFoo.bar()
puts 'invoked bar'
end
#th
40 matches
Mail list logo
