---
We need private methods for objects.
---
just a comment on how this is done for ruby:
code
#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
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;
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
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
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]
or
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
usually
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 pointer
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 Unix
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.
Dan
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.
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 there might have
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
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
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
fail (and
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 hold off on applying
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 key_inc has an off-by-one
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 patch
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 ensure
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 pair
Revision 1.89 of MANIFEST introduced io/io_unix.c, but configure dies
becuase the file isn't there...
- D
[EMAIL PROTECTED]
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
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
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
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 date.
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 MANIFEST from
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 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
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
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
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
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 for
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
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
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
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 hash
35 matches
Mail list logo
