Re: ICU suggestion
On Thursday, Sep 25, 2003, at 00:41 Europe/Berlin, Robert Spier wrote: Which version of ICU is in parrot/icu. Maybe 2.6 would be the most likely to build. As an update would probably best be done by delete and replace, perhaps it could coincide with the great renaming? Actually, it would be best to do the update by applying 2.6 over whatever is there and committing. (Unless 2.6 is significantly different than whats there.) Unless you meant remove from the repository, such that it never existed in the first place when you said delete. Yes, I meant that. Say we apply 2.6 over what is there and it doesn't build, we then have to ask ourselves if the applying-over's to blame. Just seemed like one uncertainty that could be avoided. -R (CVS timelord) Mike (CVS backseatdriver)
Re: Pondering argument passing
Luke Palmer wrote: Dan Sugalski writes: ... For this, I think we're going to need a setp Ix, Py op which does indirect register addressing. Fair enough. I do suppose there will be a way to keep the register allocation intact while doing this. Or maybe these ops are for IMCC's personal use, and you can't use them alongside register allocation. If there is such an opcode, its for sure only for the register allocator, or at least the opcode only takes constant register numbers, so that its easy to track which regs are effected. Luke leo
Re: [ANNOUNCE] Another Trivia Language: URM
On Wed, 2003-09-24 at 11:08, Leopold Toetsch wrote: Further: as URM has an arbitrary amount of registers, it would be much simpler to target PIR code. r46 - r100 + r200 is currently for sure an error. OTOH translating this to $I46 = $I100 + $I200 Ok, fixed that and some other issues Leo addressed. Now I have my own register management and put all the not needed registers on the user stack. I've not rewritten the Makefiles because all the other languages/ Makefiles are either created by the parrot config or are really hardcoded Unix makefiles. Still have some open issues, but I believe it is enough for version 0.2 http://perl.thiesenweb.de/urmc-0.2.tar.bz2 Have fun, Marcus -- - |Marcus Thiesen ICQ# 108989768| - | www.thiesenweb.de | - 28A7 37CC AE2C BB6C D56D 8A3D E614 E56B 7546 75F2 signature.asc Description: This is a digitally signed message part
Re: [perl #24030] [PATCH] hash.t fails on OS X
Michael Scott [EMAIL PROTECTED] wrote: t/src/hash.t test 7 fails on Mac OS X 10.2.6 (gcc 3.3) because BIGLEN is too big: 9. 100_000 chars for the key doesn't seem to be very big. Wher does it fail? Can you debug/back-trace it? I've made it a bit smaller: 65536. This begs the questions: What is the maximum hash key size? What is the largest STRING? There are no limits except those imposed by UINTVAL (2^32-1) AFAIK. Mike leo
PIO tests
Here are some tests for the io.h API that should go in t/src/io.t. Maybe some of the expected results are debatable. Should PIO_parse_open_flags think that is the same as ? Should PIO_fdopen open ok on stdout with invalid flags like ;-) or ? Also, successive calls to PIO_seek with SEEK_CUR seem to be broken. Mike io.t Description: application/text
Re: [ANNOUNCE] Another Trivia Language: URM
Marcus Thiesen wrote: On Wed, 2003-09-24 at 11:08, Leopold Toetsch wrote: $I46 = $I100 + $I200 Ok, fixed that and some other issues Leo addressed. Now I have my own register management and put all the not needed registers on the user stack. Why? Parrot with the PIR assembler can handle an arbitrary register count. I'm sure you are not able to write a program (doing something useful) to force imc to spill registers :) I've not rewritten the Makefiles because all the other languages/ Makefiles are either created by the parrot config or are really hardcoded Unix makefiles. The latter is a bug of course. Anyway - if possible - put urm in languages/urm, create confige/gen/makefiles/urm.in, adapt makefiles.pl, run Configure, use Parrot:Config, replace hardcoded 'parrot' with config vars and try to get it running. If this step is too big (or you don't know, what I' talking about :), just drop me a mail, I'll have a look at it then. For the tests (thanks) you might consider reading perldoc Test::Simple and alike - BTW apropos: met Michael G Schwern and David Hand yesterday at the Vienna.pm TechMeet http://use.perl.org/~maks/journal/14901 Have fun, Marcus Thanks, leo
[perl #24038] [PATCH] PIO_parse_open_flags is too lenient
# New Ticket Created by Michael Scott # Please include the string: [perl #24038] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=24038 PIO_parse_open_flags thinks that is the same as . This could lead to errors such as using instead of . -- attachment 1 -- url: http://rt.perl.org/rt2/attach/65312/48707/af9b1f/io_c.patch io_c.patch Description: io_c.patch
Re: New NCI types (and I need an x86 boost for it)
Dan Sugalski wrote: ...I can, and have, written the C code to make this happen in build_nativecall.pl, but that doesn't help on the x86 platforms which build this stuff up dynamically. You allways can edit nci.c (or build_nativecall.pl) and undef (or mangle the define of) CAN_BUILD_CALL_FRAMES, so that the C code is used. Could someone take a look at build_nativecall.pl to see what the C looks like, and thump jit_emit.h appropriately? Thanks. I've added the 'b' signature, but its totally untested. Do you have a test case for 'b' and 'B', so that I can implement the latter? Dan leo
Re: Library code
Dan Sugalski wrote: Okay, we're starting to get some library code. I've a full (hopefully) ncurses interface .pasm file The ncurses lib is reall great. lib/ subdirectory for assembly and/or imcc library code? I'd rather kept all that stuff in runtime/parrot/* where there are already things to be installed then in a new /library dir. But anyway versioning, naming and that sill applies. Dan leo
Re: [perl #24030] [PATCH] hash.t fails on OS X
On Thursday, Sep 25, 2003, at 13:20 Europe/Berlin, Leopold Toetsch wrote: Michael Scott [EMAIL PROTECTED] wrote: t/src/hash.t test 7 fails on Mac OS X 10.2.6 (gcc 3.3) because BIGLEN is too big: 9. 100_000 chars for the key doesn't seem to be very big. Wher does it fail? Can you debug/back-trace it? (gdb) r Starting program: /Users/mike/Developer/Parrot/Tests/mem_test Reading symbols for shared libraries . done Program received signal EXC_BAD_ACCESS, Could not access memory. 0x5f30 in string_transcode () (gdb) bt #0 0x5f30 in string_transcode () #1 0x6de8 in string_compare () #2 0x43e4 in find_bucket () #3 0x4880 in hash_put () #4 0x2998 in main () #5 0x25a4 in _start (argc=1, argv=0xbdd4, envp=0xbddc) at /SourceCache/Csu/Csu-45/crt.c:267 #6 0x2424 in start () And just as I was going to get started on t/src/string.t too. I've made it a bit smaller: 65536. This begs the questions: What is the maximum hash key size? What is the largest STRING? There are no limits except those imposed by UINTVAL (2^32-1) AFAIK. Mike leo
Re: New NCI types (and I need an x86 boost for it)
On Thu, 25 Sep 2003, Leopold Toetsch wrote: Dan Sugalski wrote: ...I can, and have, written the C code to make this happen in build_nativecall.pl, but that doesn't help on the x86 platforms which build this stuff up dynamically. You allways can edit nci.c (or build_nativecall.pl) and undef (or mangle the define of) CAN_BUILD_CALL_FRAMES, so that the C code is used. I know, but I'd rather not if I can avoid it. Could someone take a look at build_nativecall.pl to see what the C looks like, and thump jit_emit.h appropriately? Thanks. I've added the 'b' signature, but its totally untested. Do you have a test case for 'b' and 'B', so that I can implement the latter? Let me see what I can do. Some of the curses stuff needs b. I don't know of anything offhand that needs B, but I may be able to find something there. Dan
Re: Library code
On Thu, 25 Sep 2003, Leopold Toetsch wrote: Dan Sugalski wrote: Okay, we're starting to get some library code. I've a full (hopefully) ncurses interface .pasm file The ncurses lib is reall great. :) Now we can have multicolored life! Woohoo! lib/ subdirectory for assembly and/or imcc library code? I'd rather kept all that stuff in runtime/parrot/* where there are already things to be installed then in a new /library dir. But anyway versioning, naming and that sill applies. Fair enough. I'd not realized we had a runtime directory. Dan
Re: [perl #24030] [PATCH] hash.t fails on OS X
On Thursday, Sep 25, 2003, at 16:06 Europe/Berlin, Michael Scott wrote: On Thursday, Sep 25, 2003, at 13:20 Europe/Berlin, Leopold Toetsch wrote: Michael Scott [EMAIL PROTECTED] wrote: t/src/hash.t test 7 fails on Mac OS X 10.2.6 (gcc 3.3) because BIGLEN is too big: 9. 100_000 chars for the key doesn't seem to be very big. Wher does it fail? Can you debug/back-trace it? (gdb) r Starting program: /Users/mike/Developer/Parrot/Tests/mem_test Reading symbols for shared libraries . done Program received signal EXC_BAD_ACCESS, Could not access memory. 0x5f30 in string_transcode () (gdb) bt #0 0x5f30 in string_transcode () #1 0x6de8 in string_compare () #2 0x43e4 in find_bucket () #3 0x4880 in hash_put () #4 0x2998 in main () #5 0x25a4 in _start (argc=1, argv=0xbdd4, envp=0xbddc) at /SourceCache/Csu/Csu-45/crt.c:267 #6 0x2424 in start () And just as I was going to get started on t/src/string.t too. I'm running tests on string_compare and string_transcode with 999 byte strings without complaint. I've made it a bit smaller: 65536. This begs the questions: What is the maximum hash key size? What is the largest STRING? There are no limits except those imposed by UINTVAL (2^32-1) AFAIK. Mike leo
Re: Library code
Dan Sugalski [EMAIL PROTECTED] wrote: Fair enough. I'd not realized we had a runtime directory. BTW some warnocked stuff: Date: Sat, 23 Aug 2003 17:01:36 +0200 From: Leopold Toetsch [EMAIL PROTECTED] Subject: some fun SubProxy ,--[ orig text ]-- | I have put together a (currently dynamic) class SubProxy, which takes a | filename and sublabel. On first invoke the file source gets loaded: | | _main: null P1 | load_pmc subproxy, P1 | new P3, .Key | set P3, ext.imc # file | new P4, .Key | set P4, _ext_main # sub label | push P3, P4 | new P0, .SubProxy | assign P0, P3 | | invokecc | print back\n | invokecc | print back\n | end | | Works fine. | Should I put that in dynclasses or core classes? `- Dynamic PMCs get loaded from runtime/parrot/dynext. C.include looks in current dir and in runtime/parrot/include. leo Dan leo
Re: [perl #24030] [PATCH] hash.t fails on OS X
Michael Scott [EMAIL PROTECTED] wrote: Program received signal EXC_BAD_ACCESS, Could not access memory. 0x5f30 in string_transcode () (gdb) bt #0 0x5f30 in string_transcode () Thanks for the backtrace - doesn't help much though. Anyway I've commited a patch to reenable 'debugging' per default, it can be turned off via 'debugging=0' in Configure. Can you please redo the bt after cvs update - thanks. leo
Re: [perl #24030] [PATCH] hash.t fails on OS X
Hi:
In case it helps, it looks like it's crashing at string.c:552, because
it's trying to call src-encoding-decode() but src-encoding is NULL.
(gdb) f 0
#0 0x6104 in string_transcode (interpreter=0x616400, src=0x623440,
encoding=0x19e43c, type=0x19a6fc, dest_ptr=0x0) at string.c:552
552 UINTVAL c = src-encoding-decode(srcstart);
(gdb) l
547 srcend = srcstart + src-bufused;
548 deststart = dest-strstart;
549 destend = deststart;
550
551 while (srcstart srcend) {
552 UINTVAL c = src-encoding-decode(srcstart);
553
554 if (transcoder1)
555 c = transcoder1(src-type, dest-type, c);
556 if (transcoder2)
(gdb) p encoding
$1 = (const struct parrot_encoding_t *) 0x19e43c
(gdb) p src
$2 = (struct parrot_string_t *) 0x623440
(gdb) p src-encoding
$3 = (const struct parrot_encoding_t *) 0x0
Here's another backtrace, with a little more info:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x6104 in string_transcode (interpreter=0x616400, src=0x623440,
encoding=0x19e43c, type=0x19a6fc, dest_ptr=0x0) at string.c:552
552 UINTVAL c = src-encoding-decode(srcstart);
(gdb) bt
#0 0x6104 in string_transcode (interpreter=0x616400, src=0x623440,
encoding=0x19e43c, type=0x19a6fc, dest_ptr=0x0) at string.c:552
#1 0x6fbc in string_compare (interpreter=0x616400, s1=0x625cd8,
s2=0x623440) at string.c:949
#2 0x45b0 in find_bucket (interpreter=0x616400, hash=0x6223e0,
head=0, key=0x6816b0) at hash.c:281
#3 0x4a4c in hash_put (interpreter=0x616400, hash=0x6223e0,
key=0x6816b0, value=0xbb50) at hash.c:406
#4 0x2b5c in main (argc=1, argv=0xbc2c) at CrashingTest.c:36
#5 0x27f8 in _start (argc=1, argv=0xbc2c, envp=0xbc34) at
/SourceCache/Csu/Csu-45/crt.c:267
#6 0x2678 in start ()
JEff
On Thursday, September 25, 2003, at 08:22 AM, Michael Scott wrote:
On Thursday, Sep 25, 2003, at 16:06 Europe/Berlin, Michael Scott wrote:
On Thursday, Sep 25, 2003, at 13:20 Europe/Berlin, Leopold Toetsch
wrote:
Michael Scott [EMAIL PROTECTED] wrote:
t/src/hash.t
test 7 fails on Mac OS X 10.2.6 (gcc 3.3) because BIGLEN is too big:
9.
100_000 chars for the key doesn't seem to be very big.
Wher does it fail?
Can you debug/back-trace it?
(gdb) r
Starting program: /Users/mike/Developer/Parrot/Tests/mem_test
Reading symbols for shared libraries . done
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x5f30 in string_transcode ()
(gdb) bt
#0 0x5f30 in string_transcode ()
#1 0x6de8 in string_compare ()
#2 0x43e4 in find_bucket ()
#3 0x4880 in hash_put ()
#4 0x2998 in main ()
#5 0x25a4 in _start (argc=1, argv=0xbdd4, envp=0xbddc)
at /SourceCache/Csu/Csu-45/crt.c:267
#6 0x2424 in start ()
And just as I was going to get started on t/src/string.t too.
I'm running tests on string_compare and string_transcode with 999
byte strings without complaint.
I've made it a bit smaller: 65536.
This begs the questions:
What is the maximum hash key size?
What is the largest STRING?
There are no limits except those imposed by UINTVAL (2^32-1) AFAIK.
Mike
leo
Re: ICU suggestion
Unless you meant remove from the repository, such that it never existed in the first place when you said delete. Yes, I meant that. That's quite doable, if people understand the repercussion. (rm -r is easy!) Say we apply 2.6 over what is there and it doesn't build, we then have to ask ourselves if the applying-over's to blame. Just seemed like one uncertainty that could be avoided. Point.. although this can generally be done properly with a little bit of CVS knowledge and checking. (I can do the clean application of the update if it is wanted.) But before anything happens, someone needs to say make it so. -R
Re: ICU suggestion
On Thu, 25 Sep 2003, Robert Spier wrote: Say we apply 2.6 over what is there and it doesn't build, we then have to ask ourselves if the applying-over's to blame. Just seemed like one uncertainty that could be avoided. Point.. although this can generally be done properly with a little bit of CVS knowledge and checking. (I can do the clean application of the update if it is wanted.) I'd really rather try an overlay first, if only because it'll mean less data to sync up and smaller commit messages. Dan
Re: ICU suggestion
Ok. New ICU (2.6.1) has been committed. -R
Re: ICU suggestion
On Thu, 25 Sep 2003, Robert Spier wrote: Ok. New ICU (2.6.1) has been committed. Cool, thanks much. Anyone care to take a shot at getting it building? (Might well be dead-trivial, I don't know) Dan
Re: ICU suggestion
Anyone care to take a shot at getting it building? (Might well be dead-trivial, I don't know) Dead trivial. ./configure --disable-layout --disable-tests --disable-samples -R
setline?
Sorry, I've been following this list with one eye tied behind my back... What happened to setline? Should I emit something else instead? Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
