new ICU 2.4 release available
Dan wrote ("What's up for 0.0.10", 19 Dec 2002)
[..] here's a list of the things I'd like us
to work on specifically for 0.0.10. [...]
[...]
*) Get ICU building and (hopefully) integrated
As of Dec 20, there is a new ICU release, 2.4.
http://oss.software.ibm.com/icu/download/2.4/
There have apparently been api and build changes, so upgrading the
parrot icu tree seems indicated.
Mitchell Charity
(The change is rather too large for a patch.)
Btw - Is there any interest in having a GNU GLOBAL or LXR cross-referenced
web copy of the parrot code?
[CVS ci] mark3 - PMC/Buffer unification #9 + #19418
This is the next step in PMC/Buffer unification. - mark_used and buffer_lives are both substituted by: void pobject_lives(INTERP *, PObj *) - the mark vtable function is adjusted to above signature - the string_header and buffer_header pools are now only pointers to the real pools managed in sized_header_pools - this saves ~150 lines and increases bench_newp.pasm loops by ~10% - ticket #19418 is included (ia64.s is in config/gen/platform) leo
[perl #19493] [PATCH] Documentation updates in vtables.pod
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #19493] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19493 > Hi, during the holidays I have been looking in the possibility of targeting the Quantum Computing Language, http://tph.tuwien.ac.at/~oemer/qcl.html, for Parrot. I thing the first step to that is adding complex numbers as a PMC to Parrot. Working on that I found a couple of minor quirks in vtables.pod. i. The example with incrementing '1a' in Perl5 is broken. Incrementing '1a' gives '2'. Incrementing 'a9' gives 'b0'. ii. The flags in the PMC structure seem to have the prefix 'PObj_' not 'PMC_'. A patch fixing i. and ii. is attached. Happy New Year, Bernhard Schmalhofer -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr für 1 ct/ Min. surfen! -- attachment 1 -- url: http://rt.perl.org/rt2/attach/46333/36324/b50384/vtables.pod.patch vtables.pod.patch Description: vtables.pod.patch
Re: [perl #19358] [PATCH] Test fix for P6C.
At 1:58 AM + 12/23/02, Joseph F.Ryan (via RT) wrote: This patch should fix a bug in the test suite (specifically, at parrot/languages/perl6/t/compiler/1.t) that was causing one test to fail. Seems to be nothing more than a typo. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19359] [PATCH] Extending P6C strings.
At 2:16 AM + 12/23/02, Joseph F.Ryan (via RT) wrote: This patch will extend interpolating string support to include \c[^], \c[NAME], \c[NAME;NAME], \u, \l, \e, \U[], \L[], and \E[]. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19363] [PATCH] Radii Support for P6C.
At 5:28 AM + 12/23/02, Joseph F.Ryan (via RT) wrote: This patch adds full numeral support, including 0b0, 0c0, 0d0, 0x0, specific radii notation, and dotted-radii notation. This doesn't mean *everything* with numbers is done; for instance, "formatted" (underscore separated) numbers still aren't implemented for radii-bases yet. Applied, thanks. (Your filenames are a bit dodgy in some of these patches--things are in different directories) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19367] [PATCH] Bug Fixes for P6C.
At 7:29 AM + 12/23/02, Joseph F.Ryan (via RT) wrote:
This patch adds further extends interpolating strings to add support
for \0, \0[], \0[;], and \x[;].
Also, Bug fixes:
- \e worked incorrectly (and thus broke a test); fixed
- Literal backslashes ('\\') broke the parse; fixed
- \c[;] didn't work right; fixed
- If \c[] or \c[;] might returned a literal backslash (such as
\c[REVERSE SOLIDUS]), the op-tree would become malformed; fixed.
- \c[^J] corrupted the op-tree; fixed
Applied, with a bit of force required. Thanks.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: [perl #19369] [PATCH] P6C compiler tests for tickets 19359, 19363, 19367.
At 7:41 AM + 12/23/02, Joseph F.Ryan (via RT) wrote: This patch adds tests that cover the changes made by tickets 19359, 19363, and 19367. Applied, though we need to do something about the non-descriptive test file names... In the future, if you could patch MANIFEST when adding files, that'd be great. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[perl #19500] [PATCH] fix to disallow negative zero
# New Ticket Created by Michael Joyce
# Please include the string: [perl #19500]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=19500 >
Hello.
The core parrot op neg() allows zero to become negative. That shouldn't
happen. I've attached a patch to this email that corrects the problem by
testing if neg() was passed a value of zero. I've also attached a patch that
adds a new test to make sure that zero cannot become negative.
See also http://mathworld.wolfram.com/CountingNumber.html (zero is neither
positive nor negative)
Michael.
PS. I hope I've done this right. Please let me know if I didn't.
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/46352/36351/45ddee/core.ops.patch
-- attachment 2 --
url: http://rt.perl.org/rt2/attach/46352/36352/1d39c1/number.t.patch
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.240
diff -u -r1.240 core.ops
--- core.ops 27 Dec 2002 09:33:11 - 1.240
+++ core.ops 27 Dec 2002 21:25:37 -
@@ -1703,21 +1703,29 @@
=cut
inline op neg(inout INT) {
+ if($1 == 0.0)
+goto NEXT();
$1 = -($1);
goto NEXT();
}
inline op neg(inout NUM) {
+ if($1 == 0.0)
+goto NEXT();
$1 = -($1);
goto NEXT();
}
inline op neg(out INT, in INT) {
+ if($2 == 0.0)
+goto NEXT();
$1 = -($2);
goto NEXT();
}
inline op neg(out NUM, in NUM) {
+ if($2 == 0.0)
+goto NEXT();
$1 = -($2);
goto NEXT();
}
Index: t/op/number.t
===
RCS file: /cvs/public/parrot/t/op/number.t,v
retrieving revision 1.27
diff -u -r1.27 number.t
--- t/op/number.t 14 Dec 2002 01:17:04 - 1.27
+++ t/op/number.t 27 Dec 2002 21:26:41 -
@@ -1,6 +1,6 @@
#! perl -w
-use Parrot::Test tests => 36;
+use Parrot::Test tests => 37;
use Test::More;
output_is(<
Re: [perl #19406] [PATCH] creates a script which describes source files
At 4:25 PM + 12/24/02, [EMAIL PROTECTED] (via RT) wrote: This patch creates a script tools/dev/extract_file_descriptions.pl It produces a browsable list of file names with brief descriptions, and is intended to help familiarize new developers with the layout of parrot. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19462] [PATCH] Supress alignment warnings in jit.h and debug.h
At 11:42 PM + 12/26/02, Bruce Gray (via RT) wrote: Summary: Whenever jit.h or debug.h are '#include'ed, gcc 3.x emits warnings about structure padding. These patches fix the problem. Note: I am not convinced that this is the right way to handle these warnings on *every* platform. We may need a different approach to best handle the Crays and toasters. Due to the high number of errors on our major development platform (Linux), please apply for (at least) the short term. Applied, thanks. (Though I'll note that Linux isn't the major development platform :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19463] [PATCH] Sanity check for alignptrs/test_c.in
At 12:15 AM + 12/27/02, Bruce Gray (via RT) wrote: This patch gives Configure's pointer alignment test a better error message for missing input. Hopefully this won't happen, but in case it does... Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #17507] [PATCH] lib/Parrot/Configure/Step.pm - more litter cleanup
At 6:03 PM -0600 12/26/02, Bruce Gray wrote: (Take 2: even "RT-Send-CC: perl6-internals at perl.org" is not getting out to the mailing list.) URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17507 On 2002-09-22, I opened this ticket and submitted a patch. On 2002-12-11, I updated (in RT) the ticket with more info, and brought the patch up-to-date with CVS. RT did not echo the update to the mailing list, so no one but me saw the update. I have appended a copy of the update for peer review, and for the mailing list archives. I have attached the most current version, step_move_if_diff_v3.patch Unless any objections are raised, please apply. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19465] [PATCH] method_util.h lacks Vim local variables
At 12:23 AM + 12/27/02, Bruce Gray (via RT) wrote: The file 'method_util.h' is missing the standard comment block that sets the behavior for the Vim editor. This patch adds the comment. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19467] [PATCH] win32.h - MinGW #pragma warnings
At 1:22 AM + 12/27/02, Bruce Gray (via RT) wrote: The gcc compiler in MinGW (win32) emits warnings for invalid pragmas in win32.h (platform.h). This patch uses '#ifndef __GNUC__' to hide the pragmas from gcc. Nope--there are more compilers that aren't gcc than just MinGW. Is there a MinGW specific #define that can be tested instead? -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19470] [PATCH] --cc=FOO fails for Win32
At 2:19 AM + 12/27/02, Bruce Gray (via RT) wrote: In hints/mswin32.pl, there is code in place to customize the build environment based on the value of $cc. However, $cc is only populated by the 'cc' from the local 'perl -V'; the command-line flag '-cc=FOO' is not used here. This patch corrects that problem, as well as missing 'link', 'ar', and 'slash' values for MinGW. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19500] [PATCH] fix to disallow negative zero
At 9:39 PM + 12/27/02, Michael Joyce (via RT) wrote: The core parrot op neg() allows zero to become negative. That shouldn't happen. I've attached a patch to this email that corrects the problem by testing if neg() was passed a value of zero. I've also attached a patch that adds a new test to make sure that zero cannot become negative. Applied, with a bit of twidding on the int case. (And I'm not sure the check is actually necessary, but...) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [perl #19467] [PATCH] win32.h - MinGW #pragma warnings
[cc'ed to Brent Dax for his specific attention] On Fri, 27 Dec 2002 20:34:33 -0500, "Dan Sugalski" wrote: >At 1:22 AM + 12/27/02, Bruce Gray (via RT) wrote: >>The gcc compiler in MinGW (win32) emits warnings for invalid >>pragmas in win32.h (platform.h). >>This patch uses '#ifndef __GNUC__' to hide the pragmas from gcc. > >Nope--there are more compilers that aren't gcc than just MinGW. >Is there a MinGW specific #define that can be tested instead? Could you take a second look at the patch? Your comments sound like you think I want to: "hide the pragmas from gcc, but let MinGW see them" when really I want to: "hide the pragmas from gcc (which is the same as MinGW in this case)" The C compiler in MinGW *is* gcc, just like the compiler in CygWin is gcc. MinGW and CygWin are just the environments surrounding the build tools and the runtime libs. Any version of gcc will complain about the "#pragma warning()" lines. "#ifndef __GNUC__" is what I meant to say, because gcc is the only compiler that I *know* chokes on those pragmas. It seems likely that some other compilers (Borland?, Mars?) will also choke on them, but I don't yet know what they are, so I did not change the code for them yet. Having said that, I see that nested "#ifndef __GNUC__", #ifndef __BORLAND", "#ifndef __MARS__", etc will be sub-optimal. The better choice is to only make the pragmas visible to the specific compiler that understands them. Now that I have done more checking, I think that compiler is Microsoft's. If Brent Dax will verify that his original intent was for those pragmas to apply only to Microsoft's C compiler, then an improvement would be to change one line of the patch from +#ifndef __GNUC__ to +#ifdef _MSC_VER Please let me know if I have misunderstood you, or have muddied the issue further. -- Thank you, Bruce Gray
[perl #19511] [PATCH] Pointers in List_chunk not initialized
# New Ticket Created by Bruce Gray # Please include the string: [perl #19511] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19511 > On Win32, these tests are segfaulting due to invalid pointers in List_chunk structs: t/op/string.t 97-98 t/pmc/intlist.t3-4 t/pmc/pmc.t80 The problem is caused by list.c/allocate_chunk not initializing the pointers. This patch corrects the problem. -- Hope this helps, Bruce Gray -- attachment 1 -- url: http://rt.perl.org/rt2/attach/46396/36388/e02d85/list_chunk_initialize.patch Index: list.c === RCS file: /cvs/public/parrot/list.c,v retrieving revision 1.23 diff -u -r1.23 list.c --- list.c 27 Dec 2002 09:33:11 - 1.23 +++ list.c 28 Dec 2002 03:37:35 - @@ -187,6 +187,10 @@ Parrot_block_GC(interpreter); chunk = (List_chunk *)new_bufferlike_header(interpreter, sizeof(*chunk)); chunk->items = items; +chunk->n_chunks = 0; +chunk->n_items = 0; +chunk->next = NULL; +chunk->prev = NULL; Parrot_allocate_zeroed(interpreter, (Buffer *)chunk, size); Parrot_unblock_DOD(interpreter); Parrot_unblock_GC(interpreter);
[perl #19516] imcc whitespace sensitive parsing error
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #19516] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19516 > Whitespace sensitive imcc issue... $ cat find_close.imc .sub MAIN $S0 = "\\" print $S0 end .end $ make find_close ../../imcc/imcc -o find_close.pasm find_close.imc last token = ["\\" ] (error) line 2: parse error Didn't create output asm. make: *** [find_close.pasm] Error 69 but.. $ cat find_close.imc .sub MAIN $S0 = "\\" print $S0 end .end $ make find_close perl -I../../../lib ../../../assemble.pl find_close.pasm > find_close.pbc ../../../parrot find_close.pbc \ -- Will "Coke" Coleda
[perl #19517] RT issue
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #19517] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=19517 > (I don't see an RT queue, so I'm sending this to the parrot queue) I have a dev.perl.org account. my email is currently set to "will at coleda.com". http://bugs6.perl.org/rt2/Ticket/Create.html?Queue=1 tells me: > Create a new ticket > We do not allow tickets to be created via the web interface. > To create an email for the parrot queue, please send an email to: > bugs-parrot at rt.perl.org > For proper tracking, you should send the email from wcoleda at infomg.com. Which -used- to be my email address, but is no longer. ?? -- Will "Coke" Coleda
LXR or GLOBAL Re: new ICU 2.4 release available
>Btw - Is there any interest in having a GNU GLOBAL or LXR cross-referenced >web copy of the parrot code? Yes, definitely. We could probably even put it on parrotcode.org or dev.perl.org/perl6. Do you have a recommendation between GLOBAL and LXR? -R
Re: [perl #19517] RT issue
>(I don't see an RT queue, so I'm sending this to the parrot queue) There is one, but it's not visible to you. [EMAIL PROTECTED] is the shortest address to get there. >I have a dev.perl.org account. my email is currently set to "will at >coleda.com". > > For proper tracking, you should send the email from wcoleda at >infomg.com. > >Which -used- to be my email address, but is no longer. I think this is related to ticket #285, which you can't see. It deals with synchronization of the two datasets. I'll see about getting this done in the next week or so, and if it doesn't look like it will happen in a timely fashion, I will just update your address. -R (on vacation this week.)
