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!
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
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
On Wed, Jan 02, 2002 at 01:38:28PM +, Nicholas Clark wrote:
This clears up about 458 of these:
Cool. Thanks, applied.
--
ZenHam heh, yeah, but Aretha could be reading out /etc/services and
kick just so much ass :)
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 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
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
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 probably
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
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 full
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 -
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 -
@@
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;
The array_test #44 within pmc.t is segfaulting.
Ilya
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 ([EMAIL
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 TODO file,
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, those
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
+++
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 -
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 -r1.2 io_os.c
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
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
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 other
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 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 make it
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 yet.
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
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.
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
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
30 matches
Mail list logo
