[perl #43327] [TODO] config/inter/make.pm: Write unit tests
New file t/configure/108-inter_make.t committed to trunk in r21165. Resolving ticket.
[perl #42769] can't create a variable named 'object'
On Fr. 27. Apr. 2007, 14:02:49, smash wrote: > On Fri Apr 27 09:36:50 2007, particle wrote: > > it seems that 'object' is a reserved word in imcc, it's a synonym for > > 'pmc'. it seems undocumented, and i don't see a reason for it--we > > already have a word for 'pmc'. > > I removed 'object' from IMCC lexer and grammar, so it's not a reserved > word anymore and can be normally used as a variable name: > The patch from smash did not apply cleanly any more, so I manually applied it and add a test. The new patch is attached. Does anybody mind if 'object' is removed as an alias of 'pmc'? As 'object' hasn't been documented, I think that no deprecation cycle is necessary. Regards, Bernhard -- /* [EMAIL PROTECTED] */
[perl #43315] [TODO] config/inter/lex.pm: Write unit tests
5 new test files and refactored config/inter/lex.pm committed to trunk in r21166.
[perl #45307] [BUG] Misleading time-zone display at http://smoke.parrotcode.org/smoke/
# New Ticket Created by James Keenan # Please include the string: [perl #45307] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=45307 > At http://smoke.parrotcode.org/smoke/, we are told: "Note: Timezone is UTC." I just managed to generate my very first smoke test using 'make smoke'. That completed at about 10:43 EDT, so I would have expected the display to say that it was created at 14:43. Instead, it said that it was created at 07:43, which would be Pacific time. In other words, the timezone is localtime on the perl.org servers in LA. This meant that it took me some time to locate my smoke report. When I did so, UTC was correctly used on the individual smoke report. So we just have to fix it on the display page. Thank you very much. kid51
Re: [perl #42769] can't create a variable named 'object'
On Sep 9, 2007, at 7:18 AM, Bernhard Schmalhofer via RT wrote: On Fr. 27. Apr. 2007, 14:02:49, smash wrote: On Fri Apr 27 09:36:50 2007, particle wrote: it seems that 'object' is a reserved word in imcc, it's a synonym for 'pmc'. it seems undocumented, and i don't see a reason for it--we already have a word for 'pmc'. I removed 'object' from IMCC lexer and grammar, so it's not a reserved word anymore and can be normally used as a variable name: The patch from smash did not apply cleanly any more, so I manually applied it and add a test. The new patch is attached. Does anybody mind if 'object' is removed as an alias of 'pmc'? As 'object' hasn't been documented, I think that no deprecation cycle is necessary. I agree. -- Will "Coke" Coleda [EMAIL PROTECTED]
Re: [perl #43219] segfault in tcl
The original segfault that caused this ticket is closed, I think, but tcl is still segfaulting on darwin. I think there's another ticket open; feel free to merge them together. $ sw_vers ProductName:Mac OS X ProductVersion: 10.4.10 BuildVersion: 8R2218 gcc version 4.0.1 (Apple Computer, Inc. build 5363) svn revision 21166 backtrace on t/cmd_after.t: Program received signal EXC_BAD_ACCESS, Could not access memory.Reason: KERN_INVALID_ADDRESS at address: 0x00ec8d14 0x00094e20 in ascii_compare (interp=0x31003b0, lhs=0x35416f0, rhs=0x189e850) at src/charset/ascii.c:328 328 const int ret_val = memcmp(lhs->strstart, rhs- >strstart, min_len); (gdb) bt#0 0x00094e20 in ascii_compare (interp=0x31003b0, lhs=0x35416f0, rhs=0x189e850) at src/charset/ascii.c:328#1 0x4572 in string_equal (interp=0x31003b0, s1=0x35416f0, s2=0x189e850) at src/string.c:1327#2 0x000c354f in STRING_compare (interp=0x31003b0, search_key=0x35416f0, bucket_key=0x189e850) at src/ hash.c:142 #3 0x000c43e6 in parrot_hash_get_bucket (interp=0x31003b0, hash=0x3113c30, key=0x35416f0) at src/hash.c:849 #4 0x001aa9e3 in Parrot_Hash_exists_keyed_str (interp=0x31003b0, pmc=0x188a680, key=0x35416f0) at ./src/pmc/hash.pmc:879 #5 0x000c043a in is_loaded (interp=0x31003b0, path=0x35416f0) at src/ dynext.c:144 #6 0x000c0f57 in Parrot_load_lib (interp=0x31003b0, lib=0x3522b98, initializer_unused=0x0) at src/dynext.c:471#7 0x0021fbb8 in do_loadlib (interp=0x31003b0, lib=0x31b8ff0 "'tcl_ops'") at compilers/imcc/imcc.y:378#8 0x00221090 in yyparse (yyscanner=0x319a0a0, interp=0x31003b0) at compilers/imcc/imcc.y:503 #9 0x0022cf55 in compile_string (interp=0x31003b0, s=0x28a2c00 ".HLL 'Tcl', ''\n.loadlib 'tcl_ops'\n.namespace \n.include 'languages/tcl/ src/returncodes.pir'\n.sub '_anon' :anon\n.local pmc colons, split, epoch\ncolons = get_root_global ['_tcl'], 'colons'\n sp"..., yyscanner=0x319a0a0) at compilers/imcc/imcc.l:1172 #10 0x000b7ce6 in imcc_compile (interp=0x31003b0, s=0x28a2c00 ".HLL 'Tcl', ''\n.loadlib 'tcl_ops'\n.namespace \n.include 'languages/tcl/ src/returncodes.pir'\n.sub '_anon' :anon\n.local pmc colons, split, epoch\ncolons = get_root_global ['_tcl'], 'colons'\n sp"..., pasm_file=0, error_message=0xbfffee84) at compilers/imcc/ parser_util.c:725#11 0x000b7fe7 in imcc_compile_pir_ex (interp=0x31003b0, s=0x28a2c00 ".HLL 'Tcl', ''\n.loadlib 'tcl_ops'\n.namespace \n.include 'languages/tcl/src/ returncodes.pir'\n.sub '_anon' :anon\n.local pmc colons, split, epoch\ncolons = get_root_global ['_tcl'], 'colons'\nsp"...) at compilers/imcc/parser_util.c:835#12 0x000d1357 in pcf_P_Jt (interp=0x31003b0, self=0x1889eb8) at src/nci.c:2645#13 0x000a3e0e in Parrot_NCI_invoke (interp=0x31003b0, pmc=0x1889eb8, next=0x321f728) at ./src/pmc/nci.pmc:168 #14 0x001607cf in Parrot_Compiler_invoke (interp=0x31003b0, pmc=0x1889eb8, code_ptr=0x321f728) at ./src/pmc/ compiler.pmc:38#15 0x0003426b in Parrot_invokecc_p (cur_opcode=0x321f720, interp=0x31003b0) at src/ops/core.ops:424 #16 0x000e575e in runops_slow_core (interp=0x31003b0, pc=0x321f720) at src/runops_cores.c:191#17 0x000c60c3 in runops_int (interp=0x31003b0, offset=3) at src/interpreter.c:818 #18 0x000146a6 in runops (interp=0x31003b0, offs=3) at src/ inter_run.c:99 #19 0x00014948 in runops_args (interp=0x31003b0, sub=0x1889138, obj=0x282dc60, meth_unused=0x0, sig=0x23a490 "vP", ap=0xb15c "? ~O~H\001?I\021\003L?\n") at src/inter_run.c:213 #20 0x00014a88 in Parrot_runops_fromc_args (interp=0x31003b0, sub=0x1889138, sig=0x23a490 "vP") at src/inter_run.c:290 #21 0x867f in Parrot_runcode (interp=0x31003b0, argc=2, argv=0xb2b8) at src/embed.c:790#22 0x000af44c in imcc_run_pbc (interp=0x31003b0, obj_file=0, output_file=0x0, argc=2, argv=0xb2b8) at compilers/imcc/main.c:627#23 0x000afed7 in imcc_run (interp=0x31003b0, sourcefile=0xb36b "tcl.pbc", argc=2, argv=0xb2b8) at compilers/imcc/main.c:853#24 0x244e in main (argc=2, argv=0xb2b8) at src/main.c:60 On Do. 14. Jun. 2007, 19:10:02, coke wrote: With recent updates, tcl suite is MUCH faster, but is now segfaulting in several places. No clue when it last worked. Hi Coke, it looks like tcl is working again. Can I close the ticket? Regards, Bernhard -- /* [EMAIL PROTECTED] */ -- Will "Coke" Coleda [EMAIL PROTECTED]
[perl #42769] Names of basic PMC serve as keywords in PIR
On So. 29. Apr. 2007, 06:01:16, kjs wrote: In r21167 the keyword 'object', as a synonym of 'pmc', was removed from PIR. However the question from kjs remains to be answered: > related to this, I think that imcc also allows for built-in types as types. > such as ".local Array a" etc. (sorry can't check; don't have my own pc > around here, this is a public pc) (I added some notes about this and other > PIR cleanups in languages/PIR and I think also in compilers/pirc IIRC). > > IMHO, this is not needed; "pmc" is sufficient, and it'd be nice to keep PIR > as simple as possible, after all it's an intermediate language. Moreover, > everytime a built-in type is added (although not happening that often) the > grammar would have to be updated to stay consistent. I second the suggestion from kjs. It isn't helpful to be able to say: .local Array my_string my_string = new String Regards, Bernhard -- /* [EMAIL PROTECTED] */
[perl #45309] [PATCH] sign function
# New Ticket Created by Jörg Plate # Please include the string: [perl #45309] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=45309 > This patch implements the sign function for I, N, BigInt and Complex numbers. CREDITS |3 3 0 0 ++ src/ops/experimental.ops | 5756 1 0 ++- src/pmc/bigint.pmc | 3838 0 0 +++ src/pmc/complex.pmc | 3737 0 0 +++ src/pmc/float.pmc| 3838 0 0 +++ src/pmc/integer.pmc | 2727 0 0 ++ t/op/01-parse_ops.t |1 1 0 0 + t/op/arithmetics.t | 3736 1 0 ++- t/pmc/bigint.t | 2524 1 0 ++ ++- t/pmc/complex.t | 1918 1 0 +++- vtable.tbl |3 3 0 0 ++ 11 files changed, 281 insertions(+), 4 deletions(-) -- "I'm working on it." sign.diff Description: Binary data smime.p7s Description: S/MIME cryptographic signature PGP.sig Description: PGP signature
Re: [perl #45309] [PATCH] sign function
On Sun, Sep 09, 2007 at 10:56:20AM -0700, Jrg Plate wrote: > # New Ticket Created by Jörg Plate > # Please include the string: [perl #45309] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt3/Ticket/Display.html?id=45309 > > > > This patch implements the sign function for I, N, BigInt and Complex > numbers. What should the sign of a NaN be? undef? Nicholas Clark
Re: [perl #45309] [PATCH] sign function
At 21:16 +0100 9/9/07, Nicholas Clark wrote: >On Sun, Sep 09, 2007 at 10:56:20AM -0700, Jrg Plate wrote: > > # http://rt.perl.org/rt3/Ticket/Display.html?id=45309 > > > This patch implements the sign function for I, N, BigInt and Complex >> numbers. > >What should the sign of a NaN be? undef? Some, if not most, NAN's do have a sign. Positive overflow (infinity) and negative overflow are examples that certainly are signed quantities. The sign of zero, where there really are two bit patterns representing minus and plus zero, has been discussed and there might already be a resolution. NAN's only apply to floats. I can imagine a user-invented NaN that includes positive and negative versions. I would just return the sign bit from the left end of the binary. A better question might be just what is meant by the sign of a complex pair. -- --> From the U S of A, the only socialist country that refuses to admit it. <--
Re: [perl #45153] better TAP::Harness support
# from Parrot via RT # on Tuesday 04 September 2007 01:30 am: >With TAP::Parser, the attached patch and Parrot/TAP/Harness.pm in the >current directory[1], the tests can be run as: > > runtests --harness Parrot::TAP::Harness $(perl t/harness --files) The runtests code has been refactored into App::Prove, which allows parrot to make their own ./runtests such as the attached. This gets rid of the need for --harness argument, and also allows for additional argument flag customizations. ./runtests $(perl t/harness --files) Get TAP::Harness from the svn. Note: this distro also contains a lib/Test/Harness.pm and bin/prove -- neither of those are needed for this, and they *might* even cause trouble with the existing parrot test framework. http://svn.hexten.net/tapx/trunk Additionally, there is now parallel testing support with TAP::Harness::Parallel. http://scratchcomputing.com/svn/TAP-Harness-Parallel/trunk This works like: ./runtests --jobs 9 $(perl t/harness --files) And appears to yield a 30-40% decrease in wait time (assuming that tests do not have resource conflicts (shared tempfiles, etc.)) A cursory examination implies that some parrot tests do indeed have such conflicts, but you have to crank -j up to 25 to find them (which is borderline forkbombing.) t/pmc/io.t t/pmc/os.t t/dynoplibs/myops.t t/src/extend.t --Eric -- Like a lot of people, I was mathematically abused as a child. --Paul Graham --- http://scratchcomputing.com --- runtests Description: Perl program
Re: [perl #45309] [PATCH] sign function
On Sep 9, 2007, at 6:40 PM, Doug McNutt wrote: At 21:16 +0100 9/9/07, Nicholas Clark wrote: On Sun, Sep 09, 2007 at 10:56:20AM -0700, Jrg Plate wrote: # http://rt.perl.org/rt3/Ticket/Display.html?id=45309 > This patch implements the sign function for I, N, BigInt and Complex numbers. What should the sign of a NaN be? undef? Some, if not most, NAN's do have a sign. Positive overflow (infinity) and negative overflow are examples that certainly are signed quantities. The sign of zero, where there really are two bit patterns representing minus and plus zero, has been discussed and there might already be a resolution. NAN's only apply to floats. I can imagine a user-invented NaN that includes positive and negative versions. I would just return the sign bit from the left end of the binary. A better question might be just what is meant by the sign of a complex pair. -- --> From the U S of A, the only socialist country that refuses to admit it. <-- I'm curious as to why these ops should be added. These things can easily be done with PIR, and any compiler can auto generate the code for that. A complex pair doesn't have a sign, it has two. But then again, it as an absolute value that's convoluted.
[perl #45313] [Web] Add IRC Pointer to parrotcode.org
# New Ticket Created by chromatic # Please include the string: [perl #45313] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=45313 > I had a short discussion online today with someone who tried to write a compiler earlier this summer, but found our documentation lacking. He wasn't aware of the IRC-centric nature our development often has. Adding a prominent link to #parrot on the front page of parrotcode.org may help channel the curious to the best place for us to help them for now. -- c
Re: [perl #45313] [Web] Add IRC Pointer to parrotcode.org
Done. On Sep 9, 2007, at 11:09 PM, chromatic (via RT) wrote: # New Ticket Created by chromatic # Please include the string: [perl #45313] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=45313 > I had a short discussion online today with someone who tried to write a compiler earlier this summer, but found our documentation lacking. He wasn't aware of the IRC-centric nature our development often has. Adding a prominent link to #parrot on the front page of parrotcode.org may help channel the curious to the best place for us to help them for now. -- c -- Will "Coke" Coleda [EMAIL PROTECTED]
[perl #42790] [BUG] Tailcall with slurpy argument passing causes a memory leak
On Sun Jun 03 20:33:35 2007, [EMAIL PROTECTED] wrote:
> On Saturday 28 April 2007 16:43:06 Mehmet Yavuz Selim Soyturk wrote:
>
> > Next program makes a slurpy tailcall, and it causes a memory leak
> for me.
>
> Confirmed. Interestingly, the problem looks like a Key PMC somewhere
> gets
> garbage collected inappropriately.
>
> I tried various tricks to mark the call_state's PMC as live, but
> nothing fixed
> anything except for this patch, which hides the problem.
>
> Now I know that storing a PMC in a data structure that the GC doesn't
> check
> during mark and sweep is a problem, but liberal use of
> parrot_register_pmc()
> didn't fix things either.
>
> -- c
>
This code is segfaulting now (r21166)
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xdeadbef3
0x00010b42 in clone_key_arg (interp=0x31003b0, st=0xbfffef3c) at
src/inter_call.c:641
641 if (key && key->vtable->base_type == enum_class_Key) {
(gdb) bt
#0 0x00010b42 in clone_key_arg (interp=0x31003b0, st=0xbfffef3c) at
src/inter_call.c:641
#1 0x00011d06 in Parrot_convert_arg (interp=0x31003b0, st=0xbfffef3c) at
src/inter_call.c:
1104
#2 0x00011a69 in Parrot_process_args (interp=0x31003b0, st=0xbfffef3c,
param_or_result=PARROT_PASS_PARAMS) at src/inter_call.c:1036
#3 0x00011e82 in parrot_pass_args (interp=0x31003b0, src_ctx=0x3115010,
dest_ctx=0x3111c50, src_indexes=0x311d46c, dest_indexes=0x311d420,
param_or_result=PARROT_PASS_PARAMS) at src/inter_call.c:1169
#4 0x000345e0 in Parrot_get_params_pc (cur_opcode=0x311d420, interp=0x31003b0)
at
src/ops/core.ops:542
#5 0x000e575e in runops_slow_core (interp=0x31003b0, pc=0x311d420) at src/
runops_cores.c:191
#6 0x000c60c3 in runops_int (interp=0x31003b0, offset=29) at
src/interpreter.c:818
#7 0x000146a6 in runops (interp=0x31003b0, offs=29) at src/inter_run.c:99
#8 0x00014948 in runops_args (interp=0x31003b0, sub=0x1889e58, obj=0x282dc60,
meth_unused=0x0, sig=0x23a490 "vP", ap=0xb19c "@~^~H\001?I\021\003L?\n") at
src/
inter_run.c:213
#9 0x00014a88 in Parrot_runops_fromc_args (interp=0x31003b0, sub=0x1889e58,
sig=0x23a490 "vP") at src/inter_run.c:290
#10 0x867f in Parrot_runcode (interp=0x31003b0, argc=1, argv=0xb2f4) at
src/
embed.c:790
#11 0x000af44c in imcc_run_pbc (interp=0x31003b0, obj_file=0, output_file=0x0,
argc=1,
argv=0xb2f4) at compilers/imcc/main.c:627
#12 0x000afed7 in imcc_run (interp=0x31003b0, sourcefile=0xb3a3 "foo.pir",
argc=1,
argv=0xb2f4) at compilers/imcc/main.c:853
#13 0x244e in main (argc=1, argv=0xb2f4) at src/main.c:60
Re: [perl #42790] [BUG] Tailcall with slurpy argument passing causes a memory leak
On Sunday 09 September 2007 21:40:56 Will Coleda via RT wrote:
>
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0xdeadbef3
> 0x00010b42 in clone_key_arg (interp=0x31003b0, st=0xbfffef3c) at
> src/inter_call.c:641 641 if (key && key->vtable->base_type ==
> enum_class_Key) {
p key
p key->vtable
(my guess is the latter is 0xdeadbef3, which is really odd; collected vtables
should be 0xdeadbeef).
-- c
[perl #45013] Configure fails if prefix ends with '/'
On Tue Aug 28 19:01:12 2007, particle wrote: > On 8/28/07, via RT dakkar <[EMAIL PROTECTED]> wrote: > > # New Ticket Created by dakkar > > # Please include the string: [perl #45013] > > # in the subject line of all future correspondence about this issue. > > # http://rt.perl.org/rt3/Ticket/Display.html?id=45013 > > > > > > > I configured my parrot with: > > > > perl Configure.pl --prefix=/Users/dakkar/Perl6/ > > > > but I got this error: > > > > Generating makefiles and other build files... > > step gen::makefiles died during execution: > > config/gen/makefiles/root.in:26: line ends in a slash > > > > at Configure.pl line 336 > > > > I removed the '/' at the end of the value for the --prefix parameter, > > and everything configured correctly. > > > > > this is expected behavior. during configure, slashes may be inverted > on windows, changing '/' to '\'. unfortunately, make sees '\' ending a > line as a continuation character, leading to unexpected behavior. > therefore '/' is not allowed as an end of line character. > > however, the error message could use some help, because you didn't > really know that it would be used in some file at the end of some > line. we'll clear this up, thanks for reporting! > ~jerry My suggestion would be to modify the code that take the prefix arg to silently drop the trailing slash; if we're adding in the slash everywhere we need it later, this will avoid the users having to know the details of our makefile-gen process.
Re: [perl #42790] [BUG] Tailcall with slurpy argument passing causes a memory leak
On Sep 10, 2007, at 12:47 AM, chromatic wrote:
On Sunday 09 September 2007 21:40:56 Will Coleda via RT wrote:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xdeadbef3
0x00010b42 in clone_key_arg (interp=0x31003b0, st=0xbfffef3c) at
src/inter_call.c:641 641 if (key && key->vtable->base_type ==
enum_class_Key) {
p key
p key->vtable
(my guess is the latter is 0xdeadbef3, which is really odd;
collected vtables
should be 0xdeadbeef).
-- c
I'd already done an svn up, now at r21171, still segfaulting:
(gdb) p key
$1 = (PMC *) 0x1886030
(gdb) p key->vtable
$2 = (VTABLE *) 0xdeadbeef
(gdb) p key->vtable->base_type
Cannot access memory at address 0xdeadbef3
--
Will "Coke" Coleda
[EMAIL PROTECTED]
