Re: [perl #25960] [PATCH] COWed stack bug (was IMCC - PerlArray getting trounced)
Luke Palmer [EMAIL PROTECTED] wrote: Leopold Toetsch writes: As already stated: - COWed buffers need distinct buffer headers pointing to the same buffer memory - unCOWing (regstack_copy_chunk) allocates new buffer memory and resets the COW flag I headed in to fix this when I saw some new stuff in there. Has this been fixed? Yep. I can't find any more trails of memory corruption. COW copy of stacks is rewritten totally, s. stack_common.c. Luke leo
[perl #27042] [PATCH] C:/parrot/config/gen/platform/win32/exec.c (Parrot_Run_OS_Command)
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #27042]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27042
This patch implements Parrot_Run_OS_Command() for Win32.
I haven't diff'd the file as this replaces the entire file (1 function).
Whilst I'm posting this, I will mention the following build error when trying to
build parrot-latest timestamped
--
1077580846
Tue Feb 24 00:00:46 2004 UTC
(time of this cvs update)
---
platform.c
c:\parrot\src\platform.c(222) : error C2061: syntax error : identifier
'Parrot_set_sighandler'
c:\parrot\src\platform.c(222) : error C2059: syntax error : ';'
c:\parrot\src\platform.c(222) : error C2059: syntax error : 'type'
NMAKE : fatal error U1077: 'c:\Perl\bin\perl.exe' : return code '0x2'
I bypassed this by commenting out the following code section in src/platform.c
(207) as a temporary measure.
/*
** config/gen/platform/generic/signal.c:
*/
/*
* Signal handling stuff
*/
#ifdef PARROT_HAS_HEADER_SIGNAL
#include signal.h
/*
* for now use signal based functions
*/
/*
Parrot_sighandler_t
Parrot_set_sighandler(int signum, Parrot_sighandler_t handler)
{
return signal(signum, handler);
}
*/
#endif
I don;t undsrstand the build process well enough to offere a solution, but it
seems to have crept in with the spliting up of the platform specific files.
Nigel.
exec.c
Description: Binary data
Re: [perl #26911] Failing tests on Linux/x86
Simon Glover [EMAIL PROTECTED] wrote: I sent this a few days ago, but RT doesn't seem to have forwarded it to the list for some reason. A nasty error to track down. Actually already print hello\n end was segfaulting, when ... nv=long double, numvalsize=12, doublesize=8 ... Parrot was compiled with long doubles. The reason was, that --gc-debug incremented the version of pmc_ext (which isn't a real Buffer). Due to the bigger PObj size, this increment went beyond the current pmc_ext structure into the data pointer of the next pmc_ext. This bug was already lurking around a long time. Fixed. Also fixed is a bogus usage of HashEntry in t/src/hash_6. Other src/hash tests are still broken, but don't fail because no DOD is run. Thanks for reporting, leo
Re: [perl #27026] [PATCH] Native exec doc
Adam Thomason [EMAIL PROTECTED] wrote: Attached patch adds user documentation for the native object execution mechanism and fixes up associated bits of the Makefile. There might be minor errors since I'm not very familiar with the internals, so anyone who is may want to make corrections. Thanks, applied. leo
Re: [CVS ci] PLATFORMS
chromatic wrote:
On Mon, 2004-02-23 at 11:00, Leopold Toetsch wrote:
[ patch ]
Thanks applied.
I think this is right. I don't see anything which indicates CGoto
support,
when core_ops_cg.c gets compiled, CGoto is enabled.
... and I'm guessing at thread and signal support since two of the
tests ran in each, though the others all skipped.
t/pmc/threads.t
...
if ($^O eq 'linux' or $^O eq 'darwin') {
plan tests = 11;
We AFAIK don't have a config variable that states threads are ok, so
platforms are hardcoded currently.
Linux x86 with gcc-3.3.2 also seems to work correctly.
Yep.
-- c
leo
Re: [CVS ci] PLATFORMS
Unfortunately until we get this solved those of us on dyslexic systems can't update our local copies. So I'm waving an URGENT flag here. After a bit of self-education on the CVS FAQ, I've come to the conclusion that renaming (delete/add) PLATFORMS to PLATFORMS.txt is the best way to solve this. Am I right or wrong? Let those with greater knowledge speak... Mike On 24 Feb 2004, at 01:31, Will Coleda wrote: my .cvsrc has update -dP, and I still get the same problem with the platforms directory. (OS X) On Monday, February 23, 2004, at 04:50 PM, Michael Scott wrote: I have this problem too. cvs [update aborted]: could not chdir to platforms: Not a directory Same problem even if I do a new check out. cvs [checkout aborted]: could not chdir to parrot/platforms: Not a directory There is no local platforms directory, yet CVS wants to go to it, so I assume the problem is coming from the server end. There is still a platforms directory on the server. http://cvs.perl.org/cvsweb/parrot/platforms/ Mike On 23 Feb 2004, at 19:56, Leopold Toetsch wrote: Jonathan Worthington [EMAIL PROTECTED] wrote: Leo, [did try to send off list, but it bounced] Please help me fill out the blanks by sending or committing patches. Please make sure to have the latest and best Parrot from CVS. Earlier today you popped a new file in CVS called PLATFORMS. Unfortunately, there is also a directory there called platforms. I don't have a directory named platforms in parrot root. You seem to be missing the -P switch to cvs update. $ find . -name platforms $ find . -iname platforms ./PLATFORMS Jonathan leo -- Will Coke Coledawill at coleda dot com
Re: [perl #27042] [PATCH] C:/parrot/config/gen/platform/win32/exec.c (Parrot_Run_OS_Command)
Nigelsandever @ Btconnect . Com [EMAIL PROTECTED] wrote: This patch implements Parrot_Run_OS_Command() for Win32. Thanks, applied. Whilst I'm posting this, I will mention the following build error platform.c Should be fixed now. leo
Re: [CVS ci] PLATFORMS
Michael Scott [EMAIL PROTECTED] wrote: Unfortunately until we get this solved those of us on dyslexic systems can't update our local copies. So I'm waving an URGENT flag here. $ cvs remove -f platforms cvs server: Removing platforms cvs [server aborted]: could not chdir to platforms: No such file or directory $ touch platforms $ cvs add platforms cvs server: cannot add file `platforms' since the directory cvs server: `/cvs/public/parrot/platforms' already exists in the repository cvs [server aborted]: illegal filename overlap $ cvs remove -f platforms cvs server: Removing platforms cvs [server aborted]: could not chdir to platforms: No such file or directory $root/platforms did exist some time ago, but there seem to be still trails of it in CVS/* After a bit of self-education on the CVS FAQ, I've come to the conclusion that renaming (delete/add) PLATFORMS to PLATFORMS.txt is the best way to solve this. Better it get fixed in CVS. There could be more errors of this kind. Mike leo
Re: [CVS ci] PLATFORMS
Leopold Toetsch [EMAIL PROTECTED] wrote: $ touch platforms Argghh: $ mkdir platforms $ cvs add platforms Directory /cvs/public/parrot/platforms added to the repository $ cvs ci -mtest platforms cvs commit: Examining platforms $ cvs remove -f platforms cvs server: Removing platforms $ cvs ci -mtest platforms cvs commit: Examining platforms Sh.. leo
Re: [CVS ci] PLATFORMS
Same problem even if I do a new check out. cvs [checkout aborted]: could not chdir to parrot/platforms: Not a directory Does the following command work? $ cvs co '!parrot/platforms' parrot # the order should be preserved. Mike Arvindh __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools
Re: [perl #27042] [PATCH] C:/parrot/config/gen/platform/win32/exec.c (Parrot_Run_OS_Command)
--- via RT [EMAIL PROTECTED], [EMAIL PROTECTED] wrote: # New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #27042] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27042 ATTACHMENT part 2 application/octet-stream name=exec.c strcpy( cmd, /c ); You need the shell name first, otherwise the shell will think /c is its name instead of an option. strcat( cmd, string_to_cstring(interpreter, command) ); That's a memory leak. You need to string_cstring_free that. free( cmd ); That should be mem_sys_free __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools
Re: [CVS ci] PLATFORMS
On 24 Feb 2004, at 15:06, Arvindh Rajesh Tamilmani wrote: Does the following command work? $ cvs co '!parrot/platforms' parrot # the order should be preserved. on tcsh it gives me cvs co '!parrot/platforms' parrot tcsh: parrot/platforms: Event not found. but on sh it did seem to do the trick. cvs co '!parrot/platforms' parrot ? parrot/docs/html U parrot/include/parrot/packfile.h U parrot/pf/pf_items.c U parrot/src/packfile.c M parrot/src/stack_common.c M parrot/types/bignum.c Many thanks. Mike
RE: [CVS ci] PLATFORMS
Does the following command work? $ cvs co '!parrot/platforms' parrot # the order should be preserved. Arvindh this works for me on win32 --jerry ** This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance.
Re: [CVS ci] PLATFORMS
... and in tcsh (OS X) cvs co '\!parrot/platforms' parrot Mike
Object changes
I just committed a patch that may break code that's using things that're otherwise broken already. Notably: *) The signature of some ops changed *) Some words (attribute, method) are now completely spelled out The ops with changed signatures also had name changes, so PIR/PASM code that uses them should break properly. Note that some of the objects.t tests break -- I've not fixed them up yet. (There are a bunch, which is good. Until some twit comes and changes something, of course... :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [CVS ci] PLATFORMS
my .cvsrc has update -dP, and I still get the same problem with the platforms directory. (OS X) on -P, CVS prunes _empty_ directories only on its way out (having built all the directories before that). So -P fails in our case. __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools
Re: [perl #27003] bytecode (header?) problem in tru64/alpha
I followed up on the perlbug thread on this but so far it hasn't
showed up in p6i, so here's a manual resend.
--- cut here ---
I am unfortunately running out of time to look more into the matter of
bytecode reading being broken in Alpha. However, here are some notes
for those who want to try, as of src/byteorder.c 1.20 and
src/packfile.c 1.142. First of all note that I'm no Parrot or PBC
guru, I'm mostly going by what I think I can understand from
docs/parrotbyte.pod, version 2003.11.22.
(1) What is failing is ./parrot t/native_pbc/{integer_1,number_{1,2}.t},
all are saying:
PackFile_unpack: Not a Parrot PackFile!
Magic number was [0x4c524550] not [0x013155a1]
Parrot VM: Can't unpack packfile t/native_pbc/integer_1.pbc.
error:imcc:main: Packfile loading failed
(2) After some glaring at the hex dump of the pbc and the parrotbyte.pod
and pf/pf_items.c:PF_fetch_opcode() and src/byteorder.c:fetch_op_be()
(since pf/pf_items.c:PackFile_assign_transforms() has assigned
fetch_op_mixed() to be the transform, OPCODE_T_SIZE being 8 and
PARROT_BIGENDIAN being 0 for the 64-bit little-endian Alpha) it is
pretty obvious (?) what is happening:
04 00 00 0d 04 00 ac 1d a0 e1 c0 b8 70 2a 58 a0 p*X.
a1 55 31 01 4c 52 45 50 01 00 00 00 00 00 00 00 .U1.LREP
...
The fetch_op_be() reverts the eight bytes 50 45 52 4c 01 31 55 a1
to become a1 55 31 01 4c 52 45 50, and then in fetch_op_mixed()
the 0xa15531014c524550 gets masked to be the 0x4c524550.
(3) Now, does this make any sense? Not to me, not right now. Allow me
to list the issues I have (or things I don't understand at the moment):
(3a) Why is fetch_op_mixed() reading in 8 bytes at a time when the
.pbc is saying the wordsize is 4 (the first byte)? Yes, the native
wordsize is eight-sized, but the bytecode is four-sized.
(3b) The byteorder of the .pbc is 0 (the second byte), or little-endian.
Neat, that is the same as ours. But why are we then reading the
parrot magic (offset 16) in as a bigendian (fetch_op_be()) opcode,
and therefore reverting the bytes? Had we read in 4 bytes (see 3a)
we would have had the expected PARROT_MAGIC or 0x013155a1 right there
in the bytes a1 55 31 01.
(3c) In PF_fetch_opcode() we have
o = (pf-fetch_op)(**stream);
*((unsigned char **) (stream)) += pf-header-wordsize;
where stream is opcode_t** (and the pf-fetch_op is here the fetch_op_mixed).
This is supposed to read in the next opcode and advance the opcode cursor.
But I have a strong suspicion and spotty evidence that this cannot work
reliably. If the opcode_t requires alignment by eight, but the packfile
(pf) bytecode header says the wordsize is four, we have just set up
a time bomb that will go off real soon-- at the next opcode fetch.
(3c1) Assume *stream is X, something nicely aligned by eight.
(3c2) Assume an opcode is read.
(3c3) *stream is increased by four, it then being X+4.
(3c4) The next time around an attempt is made to call (pf-fetch_op)
with the *stream pointing to an address aligned by four but not by eight.
Kaboom. What I mean by spotty evidence is that after some hacking
around and getting the PARROT_MAGIC read properly (I replaced the o0x
with (o32)0x in the last branch of fetch_op_mixed() and one
more byte reverse for the magic in src/packfile.c:PackFile_unpack(), IIRC)
I got a SIGBUS at the o = (pf-fetch_op)(*stream) line, the next time
around. That was the point where I had to give up hacking this.
In general it is not portable across architectures to cast aligned
(like opcode_t, or long) and non-aligned (char, void) pointers back
and forth (like it is done at the PF_fetch_opcode() cursor increment
line). For example in x86 I believe one can, with impunity, but all
the world's not x86. In the case of wordsizes of the runtime and the
bytecode being different, I think only a non-aligned pointer could work
as the cursor.
--
Jarkko Hietaniemi [EMAIL PROTECTED] http://www.iki.fi/jhi/ There is this special
biologist word we use for 'stable'. It is 'dead'. -- Jack Cohen
Re: [perl #27003] bytecode (header?) problem in tru64/alpha
Jarkko Hietaniemi [EMAIL PROTECTED] wrote: I followed up on the perlbug thread on this but so far it hasn't showed up in p6i, so here's a manual resend. I've checked is some changes in the meantime, comments below inline. (3a) Why is fetch_op_mixed() reading in 8 bytes at a time when the .pbc is saying the wordsize is 4 Changed to fetch_buf_le_4() now. Please note I didn't try to fix the whole code, just to get Tru64 running. (3c) In PF_fetch_opcode() we have o = (pf-fetch_op)(**stream); I changed the signature to unsigned char* now. (3c3) *stream is increased by four, it then being X+4. (3c4) The next time around an attempt is made to call (pf-fetch_op) with the *stream pointing to an address aligned by four but not by eight. This should be gone now... In general it is not portable across architectures to cast aligned (like opcode_t, or long) and non-aligned (char, void) pointers back and forth ... but there are still might be issues. Aligning the cursor to 16 bytes in packfile.c comes to my mind. The PF_fetch_op() still gets an opcode_t* cursor, which might be misaligned. *But* AFAIK this misaligned thingy should never be dereferenced, so that a SIGBUS shouldn't get triggered. leo
Re: [CVS ci] PLATFORMS
... and in tcsh (OS X) cvs co '\!parrot/platforms' parrot a) to avoid the inconvenience of typing the above command (with the bang sequence properly escaped) and b) to fix the problem without _renaming_ anything, the following lines may be added to CVSROOT/modules: t -d parrot parrot parrot -a !parrot/platforms t I tried to reduce them to a single line entry, but the closest I could get is parrot -a !./parrot/platforms ./parrot The (minor ?) problem with the single line version is, when the parrot module is checked out, the current directory effectively becomes a CVS working directory. Arvindh __ Do you Yahoo!? Yahoo! Mail SpamGuard - Read only the mail you want. http://antispam.yahoo.com/tools
Re: [perl #26911] Failing tests on Linux/x86
On Tue, 24 Feb 2004, Leopold Toetsch wrote: Simon Glover [EMAIL PROTECTED] wrote: I sent this a few days ago, but RT doesn't seem to have forwarded it to the list for some reason. Fixed. Confirmed. The only failures I'm now getting are some of the object tests (which Dan has just broken), and the first couple of signals tests (which I'm going to look into when I have time). Thanks, Simon
Valgrind and parrot
Using valgrind 1.9.6 I find it impossible to use with parrot, is this a known issue, should I try and get someone to upgrade valgrind for me? The following impossible happens. switch% valgrind --num-callers=100 ./parrot examples/assembly/mops.pasm ==23809== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==23809== Copyright (C) 2002, and GNU GPL'd, by Julian Seward. ==23809== Using valgrind-1.9.6, a program instrumentation system for x86-linux. ==23809== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward. ==23809== Estimated CPU clock rate is 2846 MHz ==23809== For more details, rerun with: -v ==23809== vg_malloc_aligned(0x401C9020, 524288, 524288) bad alignment request valgrind: the `impossible' happened: vg_malloc_aligned Basic block ctr is approximately 0 sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==23809==at 0x401672B0: memalign (vg_clientfuncs.c:299) ==23809==by 0x808B9B7: Parrot_memalign (src/platform.c:221) ==23809==by 0x80C1DCE: alloc_objects (src/smallobject.c:386) ==23809==by 0x80C1B7E: get_free_object (src/smallobject.c:217) ==23809==by 0x80C200F: get_free_buffer (src/headers.c:87) ==23809==by 0x80C23DD: new_string_header (src/headers.c:330) ==23809==by 0x8085309: string_make (src/string.c:367) ==23809==by 0x81A3BFD: Parrot_Array_class_init (array.c:929) ==23809==by 0x81A126A: Parrot_initialize_core_pmcs (src/core_pmcs.c:65) ==23809==by 0x819D903: init_world (src/global_setup.c:76) ==23809==by 0x80BADE9: Parrot_init (src/embed.c:67) ==23809==by 0x807F472: make_interpreter (src/interpreter.c:1587) ==23809==by 0x80BADB6: Parrot_new (src/embed.c:41) ==23809==by 0x807D0D7: main (imcc/main.c:403) ==23809==by 0x42017588: __libc_start_main (in /lib/i686/libc-2.2.5.so) ==23809==by 0x807C490: (within /home/abergman/Dev/ponie/parrot/parrot) Cheers Arthur
Re: Valgrind and parrot
At 18:27 + 2/24/04, Arthur Bergman wrote: Using valgrind 1.9.6 I find it impossible to use with parrot, is this a known issue, should I try and get someone to upgrade valgrind for me? Current stable is 2.0.0, unstable is 2.1.0. I would think an update would be in order before send in bug reports to the valgrind folks... ;-) Liz
Re: Valgrind and parrot
--- Elizabeth Mattijsen [EMAIL PROTECTED] wrote:
At 18:27 + 2/24/04, Arthur Bergman wrote:
Using valgrind 1.9.6 I find it impossible to use with parrot, is
this a known issue, should I try and get someone to upgrade valgrind
for me?
Current stable is 2.0.0, unstable is 2.1.0. I would think an update
would be in order before send in bug reports to the valgrind folks...
;-)
Liz
Even in valgrind cvs
(http://webcvs.kde.org/cgi-bin/cvsweb.cgi/valgrind/coregrind/vg_malloc2.c)
the bug is there:
/* Check that the requested alignment seems reasonable; that is, is
a power of 2. */
switch (req_alignB) {
case 4:
case 8: case 16: case 32: case 64: case 128: case 256:
case 512: case 1024: case 2048: case 4096: case 8192:
case 16384: case 32768: case 65536: case 131072:
case 262144:
case 1048576:
/* can't be bothered to calculate larger ones */
break;
default:
VG_(printf)(vg_malloc_aligned(%p, %d, %d)\nbad alignment request,
a, req_alignB, req_pszB );
VG_(core_panic)(vg_malloc_aligned);
/*NOTREACHED*/
}
(524288 is missing)
__
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools
Re: [perl #27003] bytecode (header?) problem in tru64/alpha
On Tue, 24 Feb 2004, Jarkko Hietaniemi wrote:
I am unfortunately running out of time to look more into the matter of
bytecode reading being broken in Alpha. However, here are some notes
for those who want to try, as of src/byteorder.c 1.20 and
src/packfile.c 1.142. First of all note that I'm no Parrot or PBC
guru, I'm mostly going by what I think I can understand from
docs/parrotbyte.pod, version 2003.11.22.
(1) What is failing is ./parrot t/native_pbc/{integer_1,number_{1,2}.t},
all are saying:
PackFile_unpack: Not a Parrot PackFile!
Magic number was [0x4c524550] not [0x013155a1]
Parrot VM: Can't unpack packfile t/native_pbc/integer_1.pbc.
error:imcc:main: Packfile loading failed
That looks rather similar to what I get on SPARC. Here are
three variations I just got:
Solaris/SPARC/Sun cc, longsize=4:
# PackFile_unpack: Not a Parrot PackFile!
# Magic number was [0x20a54100] not [0x013155a1]
# Parrot VM: Can't unpack packfile t/native_pbc/number_1.pbc.
Linux/SPARC/gcc-3.3.3 20040125 (prerelease) (Debian), longsize=4
# PackFile_unpack: Not a Parrot PackFile!
# Magic number was [0x00469a30] not [0x013155a1]
Linux/SPARC/gcc-3.3.3 20040125 (prerelease) (Debian), longsize=8
# PackFile_unpack: Not a Parrot PackFile!
# Magic number was [0x1200] not [0x013155a1]
And, just to round out the report, on x86 with long-long opcodes,
(what you get if you build perl-5.8.3 with -Duse64bitint)
Linux/x86/gcc version 3.3.2 (Debian), longlongsize=8
# Failed test (t/native_pbc/integer.t at line 35)
# got: 'BYTECODE_-: Size in directory 32 doesn't match size at offset
(0x2d5f) -1064971727
# ^B: Size in directory 1431849286 doesn't match size at offset (0x2) 20010401
# section: sections are not back to back
# (: Size in directory 8 doesn't match size at offset (0x28) 0
# section: sections are not back to back
Clearly something very strange is going on. Alas, I don't have time
to investigate either.
--
Andy Dougherty [EMAIL PROTECTED]
Re: Valgrind and parrot
Goplat [EMAIL PROTECTED] wrote: case 1048576: /* can't be bothered to calculate larger ones */ Yep. Valgrind always failed here. I did submit several bugfixes. Didn't receive any answer. Sorry forgot to report, but my valgrind here was always patched; + case 524288: case 1048576: + case 1048576*2: + case 1048576*4: I also needed this on my rather old system: diff -r -ub valgrind-2.0.0/coregrind/vg_syscalls.c valgrind-2.0.0-leo/coregrind/ --- valgrind-2.0.0/coregrind/vg_syscalls.c Mon Nov 3 20:15:04 2003 +++ valgrind-2.0.0-leo/coregrind/vg_syscalls.c Mon Dec 1 16:33:56 2003 @@ -2237,6 +2237,7 @@ the number of bytes currently in that socket's send buffer. It writes this value as an int to the memory location indicated by the third argument of ioctl(2). */ +#if 0 case SIOCOUTQ: SYSCALL_TRACK( pre_mem_write, tid, ioctl(SIOCOUTQ), arg3, sizeof(int)); @@ -2244,6 +2245,7 @@ if (!VG_(is_kerror)(res) res == 0) VG_TRACK( post_mem_write,arg3, sizeof(int)); break; +#endif leo
Re: [perl #27003] bytecode (header?) problem in tru64/alpha
At 03:56 PM 2/24/2004 -0500, Andrew Dougherty wrote: On Tue, 24 Feb 2004, Jarkko Hietaniemi wrote: PackFile_unpack: Not a Parrot PackFile! Magic number was [0x4c524550] not [0x013155a1] Parrot VM: Can't unpack packfile t/native_pbc/integer_1.pbc. error:imcc:main: Packfile loading failed That looks rather similar to what I get on SPARC. Here are three variations I just got: Something has definitely gone wrong. My initial test cases with byteorder handling were done with x86 32-bit, Sparc 32-bit and Sparc 64-bit, and I was able to load bytecodes between the 3, however, packfile has been through some considerable changes since the byteordering support. -Melvin
[perl #27057] Let OrderedHash store STRING and FLOATVAL
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #27057] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27057 This patch adds the methods 'get_number_keyed', 'set_string_keyed' and 'set_number_keyed' to the OrderedHash PMC. The method 'set_string_keyed_str' is also included, but I can't figure out when it will be called. There are also a a couple of new PIR based tests in t/pmc/perlhash.t and t/pmc/orderedhash.t. Originally I wanted to add support for OrderedHash to dumper.imc, but in my devel version I get a 'Speicherfehler', aka segfault. CU, Bernhard -- /* [EMAIL PROTECTED] */ GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++ orderedhash_20040224.patch Description: Binary data
Re: Various newbie questions.
On Tue, 24 Feb 2004 [EMAIL PROTECTED] wrote: 2) I sent this question previously (22 Feb 2004 20:37 GMT) but it never made it onto the list. (I was unsubscribed!). If I make a change in win32.c, (now: config/gen/platform/win32/exec.c) what is the procedure (or where is this documented) to get platform.c re-generated and compiled into parrot.exe? The only mechanism I have found that does this is to nmake realclean configure.pl nmake which doesn't seem right somehow, but I think I've read every documentation file at least twice and nothing has leaped of the page as to the right way to do this. That seems right to me: platform.c is generated when configure runs, and so we don't want to delete it when we do a simple 'make clean', only when we do 'make realclean'. This is documented in the makefile itself, but I'm not sure if we document it elsewhere; if not, then we probably should. Incidentally, it's not only platform.c that behaves like this -- a number of other files have the same behaviour, either because they are platform dependent or because they depend on the particular configuration options chosen. The full list is in the Makefile -- see the section 'STICKY GENERATED FILES:'. Again, I'm not sure if these are documented anywhere else, but they should be. Simon
Re: cvs commit: parrot/src packfile.c
On Feb 24, 2004, at 9:38 AM, Leopold Toetsch wrote:
cvsuser 04/02/24 06:38:07
Modified:include/parrot packfile.h
pf pf_items.c
src packfile.c
Log:
try to fix Tru64 native PBC issues
The PARROT_BIGENDIAN case has a typo in pf_items.c, here's a patch to
make it compile again.
-garrett
Index: pf/pf_items.c
===
RCS file: /cvs/public/parrot/pf/pf_items.c,v
retrieving revision 1.6
diff -u -r1.6 pf_items.c
--- pf/pf_items.c 24 Feb 2004 14:38:05 - 1.6
+++ pf/pf_items.c 25 Feb 2004 00:03:47 -
@@ -588,7 +588,7 @@
if(pf-header-byteorder != PARROT_BIGENDIAN) {
pf-need_endianize = 1;
if (pf-header-wordsize == sizeof(opcode_t))
-pf-fetch_op = (opcode_t (*)unsigned char*)fetch_op_le;
+pf-fetch_op = (opcode_t (*)(unsigned char*))fetch_op_le;
else {
pf-need_wordsize = 1;
pf-fetch_op = fetch_op_mixed;
Re: Various newbie questions.
At 11:36 PM + 2/24/04, [EMAIL PROTECTED] wrote: If I make a change in win32.c, (now: config/gen/platform/win32/exec.c) what is the procedure (or where is this documented) to get platform.c re-generated and compiled into parrot.exe? The only mechanism I have found that does this is to nmake realclean configure.pl nmake which doesn't seem right somehow, but I think I've read every documentation file at least twice and nothing has leaped of the page as to the right way to do this. You at least need to rerun configure.pl, since that's what builds the proper platform.c/platform.h files. 3) Is this list now blocking unsubscribed posts since the recent spam/virus problem? I'd prefer to be unsubscribed as I find the list easier to follow through a news client than a flat list of unordered emails. I'm pretty sure that unsubscriber posts go into a holding queue, but that queue is depressingly large and may get flushed on occasion if the spam/virus load gets too high. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: cvs commit: parrot/src packfile.c
On Tue, 24 Feb 2004, Garrett Rooney wrote: The PARROT_BIGENDIAN case has a typo in pf_items.c, here's a patch to make it compile again. Thanks, applied. Simon
ezmlm options (was Various newbie questions.)
DS == Dan Sugalski [EMAIL PROTECTED] writes: 3) Is this list now blocking unsubscribed posts since the recent spam/virus problem? I'd prefer to be unsubscribed as I find the list easier to follow through a news client than a flat list of unordered emails. DS I'm pretty sure that unsubscriber posts go into a holding queue, but DS that queue is depressingly large and may get flushed on occasion if DS the spam/virus load gets too high. i know mailman has the option to subscribe from an address and not get mail sent to it. this is useful if you want to send from multiple addresses and not have to get duplicates or if you want to do what nigel asked. i just scanned the ezmlm docs and can't find a similar option. as for the flat list of unordered emails, get a better email reader.:) most decent ones can do threading by subject or reference headers. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Not quite there yet...
As folks have no doubt noticed, parrot's throwing test failures now -- 12 of the object tests fail. My fault, I'm doing partial checkins as I have bits of this done. Still to finish: *) Attribute inheritance from parent classes *) Object instantiation *) Attribute get/set ops Probably a few other things too, but that should be enough to warrant a 0.1.0 release with some documentation as to what does and doesn't work. Tomorrow, I hope... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [CVS ci] PLATFORMS
After a bit of self-education on the CVS FAQ, I've come to the conclusion that renaming (delete/add) PLATFORMS to PLATFORMS.txt is the best way to solve this. Better it get fixed in CVS. There could be more errors of this kind. Confused. What would you like me to do? Also. cvs update -dP should work just fine for this. at least it does for me. Unless -P doesn't work properly on case-insensitive filesystems. -R
[perl #27088] [PATCH] Escape strings in dumper
# New Ticket Created by Will Coleda # Please include the string: [perl #27088] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=27088 Minor patch to escape backslashes and double quotes in the data dumper. Only touches PerlString handling in library/dumper.imc dumper.patch Description: Binary data -- Will Coke Coledawill at coleda dot com
