On Wed, Jan 02, 2002 at 11:02:34PM -0500, the keyboard of Jeff G was alleged to have
written:
> [snip]
> rarified atmosphere didn't affect my brain too badly. Same goes for the
> known-incomplete PerlHash class. It works, but has no collision
> [snip]
Huh? Wha? What did I miss? What is this Perl
Jeff G:
# Same
# goes for the # known-incomplete PerlHash class. It works, but
# has no collision resolution yet.
What kind of backend data structure are you using--flat array, buckets
(array of arrays) or chains (array of linked lists)? If y
On Thursday 03 January 2002 12:33 am, Bryan C. Warnock wrote:
> Looks like the chunk_base logic doesn't work on 64-bit Solaris. Every
> test failure I checked was centered around an inaccesable address coming
> out of STACK_CHUNK_BASE(*top) [line 85] . I'll dig deeper tomorrow. Er,
> today.
Pa
Looks like the chunk_base logic doesn't work on 64-bit Solaris. Every test
failure I checked was centered around an inaccesable address coming out of
STACK_CHUNK_BASE(*top) [line 85] . I'll dig deeper tomorrow. Er, today.
--
Bryan C. Warnock
[EMAIL PROTECTED]
I have come down off the mountain, and bear a partially-written article
for perl.com on how to roll your own PMCs and what this means. Should
hit perl.com sometime within the next two months, with any luck.
It needs the final bit written, and as I've just spent the better part
of a week at almost
On Wednesday 02 January 2002 03:28 pm, David M. Lloyd wrote:
> Here's how things build on Solaris now:
>
> 32-bit: Perfect, beautiful, couldn't be better.
> 32-bit with 64-bit ints: OK, but many PMC tests fail, don't know why yet.
> 64-bit: Horrid. About 25% of tests are crashing, don't know why
On Wed, Jan 02, 2002 at 11:49:40PM +, Alex Gough wrote:
> On Wed, 2 Jan 2002, Steve Fink wrote:
>
> > This patch makes pmc2c.pl emit #line directives to .c files so the
>
> Good plan, saves me hitting M-x revert-buffer every time I try to
> change something when hunting. Is this likely to m
On Wed, 2 Jan 2002, Steve Fink wrote:
> This patch makes pmc2c.pl emit #line directives to .c files so the
Good plan, saves me hitting M-x revert-buffer every time I try to
change something when hunting. Is this likely to make it harder to
charge through the actual C with a debugger, if so, can
Oops, left out a chunk. I get confused when I have too many
interfering local changes. Here's a snippet for classes/Makefile.in
that needs to be applied along with the previous pmc2c.pl patch for
#lines.
Index: classes/Makefile.in
==
On Tue, Oct 16, 2001 at 05:29:50PM -0400, James Mastros wrote:
> On Tue, 16 Oct 2001, Dan Sugalski wrote:
> > Ummm. Well. I think that you'll find this pretty much the case already (or
> > planned, at least, as some of the bits aren't done yet) so I'm not sure
> > that it'd really buy anything oth
This patch makes pmc2c.pl emit #line directives to .c files so the
debugger can trace the code back to the editable source. However, I
also have a larger patch that supersedes this one, but it changes
behavior. I just wanted to get this out first in case the later one is
deemed a bad idea.
The la
Index: docs/vtables.pod
===
RCS file: /home/perlcvs/parrot/docs/vtables.pod,v
retrieving revision 1.5
diff -u -r1.5 vtables.pod
--- docs/vtables.pod8 Dec 2001 21:24:15 - 1.5
+++ docs/vtables.pod2 Jan 2002 21:24:06 -0
Small cleanup patch:
- genclass.pl attempts to put $Id$ into generated files
but the $Id$ string gets mangled when it's committed.
This patch fixes the existing .pmc files and fixes genclass.pl.
- Makes capitalization in .pmc header match actual filenames
- The command for calling gencl
Here's how things build on Solaris now:
32-bit: Perfect, beautiful, couldn't be better.
32-bit with 64-bit ints: OK, but many PMC tests fail, don't know why yet.
64-bit: Horrid. About 25% of tests are crashing, don't know why yet.
The 32-bit with 64-bit ints problems should be duplicatable on a
At 03:07 PM 1/2/2002 -0500, Melvin Smith wrote:
>At 10:31 AM 1/2/2002 -0600, David M. Lloyd wrote:
>>Silence this warning.
>>
>>Index: io/io_os.c
>>===
>>RCS file: /home/perlcvs/parrot/io/io_os.c,v
>>retrieving revision 1.2
>>diff -u
At 10:31 AM 1/2/2002 -0600, David M. Lloyd wrote:
>Silence this warning.
>
>Index: io/io_os.c
>===
>RCS file: /home/perlcvs/parrot/io/io_os.c,v
>retrieving revision 1.2
>diff -u -r1.2 io_os.c
>--- io/io_os.c 2 Jan 2002 04:10:50 -
Silences this warning.
Index: chartypes/unicode.c
===
RCS file: /home/perlcvs/parrot/chartypes/unicode.c,v
retrieving revision 1.4
diff -u -r1.4 unicode.c
--- chartypes/unicode.c 31 Dec 2001 20:00:37 - 1.4
+++ chartypes/unic
On Wed, Jan 02, 2002 at 12:41:47PM -0500, Tzadik Vanderhoof wrote:
> There is a (relatively) new feature of the $/ variable which allows you to
> set it to a numeric reference, i.e:
>
> $/ = \80;
This is good and useful because the semantics of <> are inherently
record-oriented. In the past, t
In message <20020102054642$[EMAIL PROTECTED]>
"David & Lisa Jacobs" <[EMAIL PROTECTED]> wrote:
> Here is a short list of TODOs that I came up with for STRINGs. First, do
> these look good to people? And second, what is the preferred method for
> keeping track of these (patch to the TO
In message <007f01c1930c$9d326220$[EMAIL PROTECTED]>
"Peter Gibbs" <[EMAIL PROTECTED]> wrote:
> Another correction to string_transcode; this function now seems to work okay
> (tested using a dummy 'encode' op added to my local copy of core.ops)
Applied, thanks.
Tom
--
Tom Hughes ([E
The array_test #44 within pmc.t is segfaulting.
Ilya
Hi. I've had a feature in mind for a while now, but I missed my chance to
make it an RFC. I was told that I could still present it by using this
list, so here goes.
There is a (relatively) new feature of the $/ variable which allows you to
set it to a numeric reference, i.e:
$/ = \80;
This
Silence this warning.
Index: io/io_os.c
===
RCS file: /home/perlcvs/parrot/io/io_os.c,v
retrieving revision 1.2
diff -u -r1.2 io_os.c
--- io/io_os.c 2 Jan 2002 04:10:50 - 1.2
+++ io/io_os.c 2 Jan 2002 16:30:52 -
@@ -1
This patch fixes a pointer deref problem if sizeof(INTVAL) >
sizeof(opcode_t).
Index: core.ops
===
RCS file: /home/perlcvs/parrot/core.ops,v
retrieving revision 1.67
diff -u -r1.67 core.ops
--- core.ops2 Jan 2002 00:55:03 -
At 10:09 AM 1/2/2002 -0600, David M. Lloyd wrote:
>The incorrect assumption here is that you are building Parrot with the
>same compiler and architecture (read: integer and pointer sizes) that Perl
>was built with. Specifically, it allows my perl (64-bit ints but
>otherwise 32-bit) to build a ful
The incorrect assumption here is that you are building Parrot with the
same compiler and architecture (read: integer and pointer sizes) that Perl
was built with. Specifically, it allows my perl (64-bit ints but
otherwise 32-bit) to build a full 64-bit Parrot under Solaris. Maybe it
helps other m
At 09:39 AM 1/2/2002 -0600, David M. Lloyd wrote:
>Is it 'incorrect' to build Parrot with ints that are bigger than opcodes?
No.
>My 'some 64-bitness' build is generating warnings and failing tests
>because of the pointer mismatch (long * vs long long *) between INTVAL and
>opcode_t.
This proba
Is it 'incorrect' to build Parrot with ints that are bigger than opcodes?
My 'some 64-bitness' build is generating warnings and failing tests
because of the pointer mismatch (long * vs long long *) between INTVAL and
opcode_t.
Also, just out of curiosity, why is it INTVAL and opcode_t, rather tha
On Wed, Jan 02, 2002 at 10:30:14AM -0500, Andy Dougherty wrote:
> This is a gentle reminder to please keep the MANIFEST file sorted and
> up-to-date.
Urgh, we have been naughty, haven't we? Thanks, applied.
--
"MSDOS didn't get as bad as it is overnight -- it took over ten years
of careful deve
This is a gentle reminder to please keep the MANIFEST file sorted and
up-to-date. The enclosed patch fixes things for the moment. (I used the
Unix sort command, which does a case-sensitive sort. Feel free to
disagree and use a case-insensitive sort if you wish.) But in either
case, please do at
On Wed, Jan 02, 2002 at 01:38:28PM +, Nicholas Clark wrote:
> This clears up about 458 of these:
Cool. Thanks, applied.
--
heh, yeah, but Aretha could be reading out /etc/services and
kick just so much ass :)
This clears up about 458 of these:
In file included from jit.c:11:
include/parrot/jit_struct.h:44: warning: missing initializer
include/parrot/jit_struct.h:44: warning: (near initialization for
`op_assembly[0].string_constant_value.info[0].flag')
include/parrot/jit_struct.h:68: warning: missing i
With all the warnings turned on, there are many many warnings of the form:
ccore_ops.c: In function `Parrot_end':core_ops.c:25: warning: unused parameter
`cur_opcode'
core_ops.c:25: warning: unused parameter `interpreter'
core_ops.c: In function `Parrot_noop':
core_ops.c:30: warning: unused para
ANNOUNCE: YAPC::Europe::2002 (Munich) - Call for Papers
Call for Participation will follow in a couple of weeks, when we should
have some accommodation organised.
http://www.yapc.org/Europe/
Look forward to seeing you there.
--
Ciao
Richard Foley
Ciao - shorter than AufWiederSehen!
p
This quietens a warning in the Tokenizer test:
--- languages/miniperl/Miniperl/Tokenizer.pm~ Wed Jan 2 07:25:43 2002
+++ languages/miniperl/Miniperl/Tokenizer.pmWed Jan 2 07:34:56 2002
@@ -3,7 +3,7 @@
use strict;
use vars qw($VERSION);
-$VERSION = '0.01';
+$VERSION = '0.02';
#---
35 matches
Mail list logo
