[perl #39760] [CAGE] make warnings (r13197 - x86-msvc-7.1)
I think the issue of inconsistent dll linkage has been resolved recently by adding the YYMALLOC and YYFREE #defines to imcc source. Can other windows people confirm this? Then this ticket can be closed. Thank you very much, kjs
Re: [perl #60000] [BUG][IMCC] an :immediate sub cannot load_bytecode
On Sun, Oct 19, 2008 at 5:02 PM, via RT Klaas-Jan Stol [EMAIL PROTECTED] wrote: # New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #6] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=6 when running code as this: .sub main :immediate load_bytecode foo.pir .end (assuming you have a file 'foo.pir'), IMCC can't handle this. This is because in pbc.c, a global structure called 'globals' is used to allow the different functions to share access to some data (in particular, the code segment stuff). As documented by a warning in imcc's sources, a load_bytecode will trigger a (nested) compilation phase, which will overwrite this data. Parrot won't output anything (windows) , possibly segfaulting. The fix would be to store this 'globals' structure in the imcc_info structure (I think). Or at the very least, store a local copy of it in the function that creates the nested compilation phase. After the nested phase is over, return the local value to the global store. This way should solve the problem relatively quickly, we really need to do a lot more work on IMCC to kill globals and make it more reentrant all the way around --Andrew Whitworth
Parrot Bug Summary
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Oct 20 13:00:02 2008 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with most open tickets
---
Numbers
Ticket Counts: 42 new + 615 open = 657
Created this week: 18
Closed this week: 50
---
New Issues
New issues that have not been responded to yet
1 - 2 weeks old
59810 [PATCH] store hash seed in parrot_string_t struct
59790 t/stm/basic_mt.t #4 hangs under cygwin since svn 31655-ish
59720 [BUG] Parrot doesn't allow two HLLs to have a class of the same name
59696 [TODO] Unimplemented Unicode Functions
2 - 3 weeks old
3 - 4 weeks old
4 - 5 weeks old
58990 [TODO] Design new spec coverage mechanism
58980 [TODO][IMCC] .return in a .begin/end_return will be replaced by
.set_return
58978 [TODO][IMCC] replace .result by .get_result
58976 [TODO][IMCC] .arg will be replaced by .set_arg
58932 [DEPRECATED] P6object .new_class('Foo::Bar') will create ['Foo';'Bar']
5 - 6 weeks old
58740 [CAGE] t/configure/*.t and t/steps/*.t: Cleanup test setup/teardown code
6 - 7 weeks old
58672 [TODO] implement method lookup iterators
58670 Parrot_print_backtrace() depends on __USE_GNU
58668 src/exceptions.c exposes brokenness in make cover
58590 [PATCH] dotnet make
58488 crashing parrot when calling create_lexinfo
7 - 8 weeks old
8 - 9 weeks old
58250 [TODO] Generate callgrind output
58188 [TODO] Parrot_find_encoding_converter
58108 [BUILD] languages/Makefile 'test' target has too many deps
58070 [RFC] Disallow .local declarations in long-style call statement
9 - 10 weeks old
58050 Segfault in make testr for t/compilers/imcc/syn/hll.t:2
10 - 11 weeks old
57680 [CAGE] Problems in find_write_record
57678 [CAGE] Poor Man's Deadlock Detection
57676 [CAGE] Check for shared status of STM handle
11 - 12 weeks old
57432 [DEPRECATED] [PDD19] .HLL_map with comma
57426 [TODO] [PDD19] Implement new .HLL directive
12 - 13 weeks old
57236 [TODO] pbc_to_exe --install pbc1 [pbc2...]
13 - 14 weeks old
57088 Tcl's [lsort] failure (aka inferior runloop problem)
14 - 15 weeks old
56782 [TODO] question in getNameForKey in Getopt::Obj
15 - 16 weeks old
56634 [RFC] future direction for config
16 - 17 weeks old
56458 Failure to promote RetContinuation objects
17 - 18 weeks old
18 - 19 weeks old
19 - 20 weeks old
20 - 21 weeks old
---
Overview of Open Issues
Platform Severity Tag Lang
aix 1abandoned 05005threads 0 Amber 0
All 1fatal 1bounce0 BASIC 0
bsdos 0High 0Bug 104 bc 0
cygwin2low 1compiler 0 befunge 0
cygwin_nt 0medium2configure 3 bf 0
darwin8none 1core 2 cola0
dec_osf 0Normal1dailybuild0 forth 0
dgux 0unknown 0docs 3 jako0
dos 0Wishlist 3duplicate 0 Lisp0
dynixptx 0 install 2 lolcode 0
freebsd 5 library 0 m4 0
generic 0 notabug 0 ook 0
gnu 0 notok 0 perl6 2
HPUX 2 ok0 plot0
irix 0 Patch35 punie 0
irix640 regex 2 pynie 0
Linux 2 sendToCPAN0 python 0
lynxos0 Todo283 ruby0
mac 0 unknown 0 scheme 0
machten 0 utilities 0 tcl 0
macos 0 wontfix 0 urm 0
MacOS X 8Zcode 0
mswin32 2
netbsd1
next 0
openbsd 2
os2 0
os390 0
other 0
powerux 0
qnx 0
riscos0
sco 0
Solaris 7
sunos 1
svr4 0
svr5 0
sysv 0
unicos0
unicosmk 0
unix 0
unknown 0
uts 0
vms 0
VOS 0
Win32 9
---
Ticket Status By Version
New or OpenResolved
---
Requestors with most open tickets
Paul
[perl #46677] [TODO] [C] Merge fixedbooleanarray.pmc with functions from BigInt PMC
On Tue Sep 23 22:34:38 2008, cotto wrote: I propose to reject this ticket. Reducing code duplication is a good idea, but it's not at all clear to me what this ticket is referring to. If someone cares to point out what code should be merged, great. Otherwise this ticket is too vague to be useful. Ticket rejected, and comment removed from code in r32039. Allison
[perl #60000] [BUG][IMCC] an :immediate sub cannot load_bytecode
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #6] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=6 when running code as this: .sub main :immediate load_bytecode foo.pir .end (assuming you have a file 'foo.pir'), IMCC can't handle this. This is because in pbc.c, a global structure called 'globals' is used to allow the different functions to share access to some data (in particular, the code segment stuff). As documented by a warning in imcc's sources, a load_bytecode will trigger a (nested) compilation phase, which will overwrite this data. Parrot won't output anything (windows) , possibly segfaulting. The fix would be to store this 'globals' structure in the imcc_info structure (I think). kjs
[perl #40392] [CAGE] convert Cexit_fatal to a catchable exception
On Mon Sep 22 06:37:24 2008, Whiteknight wrote: Sept 08 milestone came and went. Any updates on this ticket? Maybe this ticket should be closed out (since it's vague) and replaced with another ticket or tickets for individual places where exit_fatal should be replaced with real_exception, if any. In the process of changing 'internal_exception' to 'exit_fatal' we reviewed those calls, and changed as many as possible to real exceptions. (Basically, if it could be converted to an exception, it was, if it couldn't be, it was left as 'exit_fatal'.) Closing this ticket. Allison
Fw: Running Perl 6 Tests
It would help if I sent this to the correct mailing list. Oops. Cheers, Ovid --- On Mon, 20/10/08, Ovid [EMAIL PROTECTED] wrote: I've been doing some work integrating Perl 6 into vim and now I'm trying to figure out how to run individual Perl 6 tests. It appears that the incantation is along the lines of: perl t/harness --verbosity 1 t/01-sanity/02-counter.t However, in digging further, I found this: perl t/harness --verbosity 1 t/02-test-pm/1-basic.t That starts off with Statement not terminated properly at line 87, near (\Hello Wo and goes downhill from there. In fact, in reading through the Makefile, I don't see that this gets run unless you do 'make testtest' (added by particle back in Dec 2007). This doesn't appear to be documented. Is it supposed to be run? Should those Perl 6 tests be valid? Also, the way that t/00-parrot/06-op-inplace.t is written forces the test numbers to be out of sequence. This causes make test to fail, even though it's merely a parse error. The Test.pm module appears to work (I've only checked it superficially), so why not use that to make some of these tests a bit easier to write? Are we trying to avoid loading modules while testing core features? Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: Fw: Running Perl 6 Tests
On Mon, Oct 20, 2008 at 8:55 AM, Ovid [EMAIL PROTECTED] wrote: It would help if I sent this to the correct mailing list. Oops. Cheers, Ovid --- On Mon, 20/10/08, Ovid [EMAIL PROTECTED] wrote: I've been doing some work integrating Perl 6 into vim and now I'm trying to figure out how to run individual Perl 6 tests. It appears that the incantation is along the lines of: perl t/harness --verbosity 1 t/01-sanity/02-counter.t However, in digging further, I found this: perl t/harness --verbosity 1 t/02-test-pm/1-basic.t That starts off with Statement not terminated properly at line 87, near (\Hello Wo and goes downhill from there. In fact, in reading through the Makefile, I don't see that this gets run unless you do 'make testtest' (added by particle back in Dec 2007). This doesn't appear to be documented. Is it supposed to be run? Should those Perl 6 tests be valid? testtest and 02-test-pm/ should either be ripped out or heavily modified. it was intended to be tests required to pass in order to run pugs' Test.pm. rakudo never did use pugs' Test.pm, and no longer attempts to. these tests are failing, and not run by default. i'd like to see requirements for rakudo's Test.pm tested instead. Also, the way that t/00-parrot/06-op-inplace.t is written forces the test numbers to be out of sequence. This causes make test to fail, even though it's merely a parse error. The Test.pm module appears to work (I've only checked it superficially), so why not use that to make some of these tests a bit easier to write? Are we trying to avoid loading modules while testing core features? yes, 00-parrot tests are prerequisites to running Test.pm. they can't use the module to perform their tests. it does indeed look like the test numbers are out of order. ...time passes... it seems infix:**= is broken. the fix isn't obvious to me. perplexing... doubly so as t/spec/S03-operators/assign.t passes these. ~jerry ~jerry
Re: [perl #48549] [DEPRECATED] [PDD19] Let .namespace (no args) have empty brackets
On Thu, Oct 16, 2008 at 6:49 AM, jerry gay [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2008 at 11:42 AM, Andrew Whitworth via RT [EMAIL PROTECTED] wrote: On Wed Jul 30 11:57:39 2008, coke wrote: PDD19 lists this as deprecated now, changing from an [RFC] to [DEPRECATED], re-opening from stalled. The big hangup for this ticket is that various parts of PCT and the CodeString PMC do not support empty brackets, and therefore PCT does not emit .namespace [] in these situations. Since PCT is one of the biggest producers of PIR code, we obviously can't move forward on the deprecation of this feature until CodeString is updated to emit [] for an empty namespace instead of just saying .namespace. I know pmichaud was talking about a major rewrite of PGE in the future, maybe this change could be included in the laundry list of things to do during that time? since .namespace and .namespace [] mean the same thing, i don't see a reason this can't be converted in trunk and piecemeal. it's already listed as deprecated, so it's just a matter of tuits. i think i have some. am i alone? i've committed one-line changes to pge and tge that seem to have modified the behavior of .namespace with the root namespace to emit empty brackets in r32051. if this can be verified independently, this ticket can be closed. ~jerry
Re: Fw: Running Perl 6 Tests
--- On Mon, 20/10/08, jerry gay [EMAIL PROTECTED] wrote: yes, 00-parrot tests are prerequisites to running Test.pm. they can't use the module to perform their tests. it does indeed look like the test numbers are out of order. ...time passes... it seems infix:**= is broken. the fix isn't obvious to me. perplexing... doubly so as t/spec/S03-operators/assign.t passes these. Well, darn. I just submitted a patch that uses Test.pm. Not only does that make my patch wrong, but I didn't understand the semantics of all of the strange assignments (+^=?), so I assumed their values were correct. Bummer. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6
Re: [perl #60016] AutoReply: [PATCH] Make basic Perl 6 tests pass
OK, I've updated the patch. I've made the following assumptions: 1. I cannot load modules. 2. I cannot use subroutines. 3. I cannot use inline ops for the test counter (since that's what is being tested) The problem is that I've made the tests pass by assuming that the value of $a at each point is the correct value. I'm assuming from what Jerry has pointed out that these number should be sequential. It's a trivial fix to remedy this in the tests, but I didn't want to try and second-guess what was going on. I think this patch (or something similar) is important as those who want to play with Rakudo will see a test failure if they run 'make test' as the README instructs. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 perl6tests.patch Description: Binary data
Re: [perl #60000] [BUG][IMCC] an :immediate sub cannot load_bytecode
On Sunday 19 October 2008 14:02:58 Klaas-Jan Stol wrote: when running code as this: .sub main :immediate load_bytecode foo.pir .end (assuming you have a file 'foo.pir'), IMCC can't handle this. This is because in pbc.c, a global structure called 'globals' is used to allow the different functions to share access to some data (in particular, the code segment stuff). As documented by a warning in imcc's sources, a load_bytecode will trigger a (nested) compilation phase, which will overwrite this data. Parrot won't output anything (windows) , possibly segfaulting. The fix would be to store this 'globals' structure in the imcc_info structure (I think). That analysis sounds right to me as well. Is it affecting any language at the moment? As much as I hate modifying IMCC before a release, I wonder if it's a valuable fix. -- c
Re: [perl #59880] DOD crash in r31926, t/op/bitwise.t #27 on linux/x86_64
chromatic wrote:
2) What's setting an invalid pointer-to-a-PMC here?
This question is answered at the end of the following dump. (This is
one of the things I nopasted during our IRC discussion last week, thanks
for your guidance in producing it.)
One interesting question: the pointer-to-a-PMC is written a couple times
by the CPointer class, and then written by BigInt once. Was that expected?
(By the way, I've also reproduced this on one of the x86-32 gentoo boxes
I tried it on, so it is not x86-64 specific. It is also not specific to
one version of gcc.)
(gdb) break src/headers.c:324 if ((long)pmc 0xfff) == 0xde8
No source file named src/headers.c.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (src/headers.c:324 if ((long)pmc 0xfff) == 0xde8) pending.
(gdb) run t/op/bitwise_27.pir
Starting program: /work/parrot-dev/parrot-trunk/parrot t/op/bitwise_27.pir
[Thread debugging using libthread_db enabled]
warning: Lowest section in /usr/lib64/libicudata.so.38 is .hash at
0190
[New Thread 0x7f3245daf710 (LWP 1013)]
[Switching to Thread 0x7f3245daf710 (LWP 1013)]
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=5120)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=5120)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=0) at
src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=0) at
src/headers.c:324
324 if (!pmc)
(gdb) cont
Continuing.
Breakpoint 1, new_pmc_header (interp=0x13bd080, flags=1024)
at src/headers.c:324
324 if (!pmc)
(gdb) bt
#0 new_pmc_header (interp=0x13bd080, flags=1024) at src/headers.c:324
#1 0x7f3245753f78 in get_new_pmc_header (interp=0x13bd080,
base_type=52,
flags=1024) at src/pmc.c:267
#2 0x7f3245753bc3 in pmc_new (interp=0x13bd080, base_type=52)
at src/pmc.c:92
#3 0x7f324571ce74 in Parrot_build_sig_object_from_varargs (
interp=0x13bd080, sig=0x7f3245988b33 PPP-P, args=0x7fff4df4d770)
at src/multidispatch.c:477
#4 0x7f324571d5c6 in Parrot_mmd_multi_dispatch_from_c_args (
interp=0x13bd080, name=0x7f3245989310 modulus,
sig=0x7f3245988b33 PPP-P) at src/multidispatch.c:574
#5 0x7f32457fe59f in Parrot_default_modulus (interp=0x13bd080,
pmc=0x1517f00, value=0x1496a08, dest=0x1495e70)
at ./src/pmc/default.pmc:1673
#6 0x7f32456afaf8 in Parrot_mod_p_p_p (cur_opcode=0x15176a0,
interp=0x13bd080) at src/ops/math.ops:760
#7 0x7f3245754c2f in runops_slow_core (interp=0x13bd080, pc=0x15176a0)
at src/runops_cores.c:222
#8 0x7f3245714ed4 in runops_int (interp=0x13bd080, offset=0)
at src/interpreter.c:937
#9 0x7f32457158c3 in runops (interp=0x13bd080, offs=0)
at src/inter_run.c:101
#10 0x7f3245715b7a in runops_args (interp=0x13bd080, sub=0x14978b0,
obj=0x144a020, meth_unused=0x0, sig=0x7f324597fcfb vP,
ap=0x7fff4df4da40)
at src/inter_run.c:236
#11 0x7f3245715d6b in Parrot_runops_fromc_args (interp=0x13bd080,
sub=0x14978b0, sig=0x7f324597fcfb vP) at src/inter_run.c:300
#12 0x7f32456f781e in Parrot_runcode (interp=0x13bd080, argc=1,
argv=0x7fff4df4dd20) at src/embed.c:951
#13 0x7f3245958f38 in imcc_run_pbc (interp=0x13bd080, obj_file=0,
output_file=0x0, argc=1, argv=0x7fff4df4dd20) at
compilers/imcc/main.c:791
#14 0x7f3245959837 in imcc_run (interp=0x13bd080,
sourcefile=0x7fff4df4e165 t/op/bitwise_27.pir, argc=1,
argv=0x7fff4df4dd20) at compilers/imcc/main.c:1079
#15 0x00400c64 in main (argc=1, argv=0x7fff4df4dd20) at
src/main.c:61
(gdb) step
329 if (flags PObj_is_PMC_EXT_FLAG) {
(gdb)
330 flags |= PObj_is_special_PMC_FLAG;
(gdb)
331 pmc-pmc_ext = new_pmc_ext(interp);
(gdb)
new_pmc_ext (interp=0x13bd080) at src/headers.c:363
363 Small_Object_Pool * const pool =
interp-arena_base-pmc_ext_pool;
(gdb)
366 return (PMC_EXT *)pool-get_free_object(interp, pool);
(gdb)
gc_ms_get_free_pmc_ext (interp=0x13bd080, pool=0x13be7e0)
at src/gc/smallobject.c:275
275 PMC_EXT *free_list = (PMC_EXT *)pool-free_list;
(gdb)
278 if (!free_list) {
(gdb)
283 ptr = free_list;
(gdb)
284 pool-free_list = ptr-_next_for_GC;
(gdb)
285 ptr-_next_for_GC = NULL;
(gdb)
287
Re: Fw: Running Perl 6 Tests
On Mon, Oct 20, 2008 at 09:42:12AM -0700, jerry gay wrote: However, in digging further, I found this: perl t/harness --verbosity 1 t/02-test-pm/1-basic.t testtest and 02-test-pm/ should either be ripped out or heavily modified. it was intended to be tests required to pass in order to run pugs' Test.pm. 02-test-pm/ should be ripped out, especially since we expect the testing functions to become Perl builtins. As such they'll be tested by either the 01-sanity/ suite or by the spectest. The 00-parrot/ set of tests are basic sanity tests for Parrot, to say do we have something that is at least running under Parrot? The 01-sanity/ tests are the tests needed to be able to start running Test.pm and the test suite. Everything else comes from the official test suite, in t/spec/ of the Pugs repository. Pm
Re: [perl #48549] [DEPRECATED] [PDD19] Let .namespace (no args) have empty brackets
The big hangup for this ticket is that various parts of PCT and the CodeString PMC do not support empty brackets, and therefore PCT does not emit .namespace [] in these situations. [...] I know pmichaud was talking about a major rewrite of PGE in the future, maybe this change could be included in the laundry list of things to do during that time? i've committed one-line changes to pge and tge that seem to have modified the behavior of .namespace with the root namespace to emit empty brackets in r32051. if this can be verified independently, this ticket can be closed. Before closing this ticket we probably still need to update the .key method in the CodeString PMC so that it returns [] instead of when it's given an empty namespace array (and then verify that everything based on PCT still functions properly). Pm
Re: [perl #60016] AutoReply: [PATCH] Make basic Perl 6 tests pass
Sorry for the patch spam. I'm embarrassed that I didn't have this correct the first time (hey, YOU stay home and write tests for a strange platform while sick) The test will now fail, but they'll fail for the correct reason: **= is being misparsed, as pointed out earlier. You might not notice the tests failing, but that's because make test seems to run the harness 3 times and the failing test is in the first run. If you don't notice this, you won't notice these tests failing. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 perl6tests.patch Description: Binary data
Re: [perl #58974] [TODO][IMCC] replace .return in tailcall context by .tailcall
On Sat, Oct 18, 2008 at 07:40:36AM -0700, Andrew Whitworth via RT wrote: On Sat Oct 18 07:38:32 2008, Whiteknight wrote: On Wed Sep 17 09:50:10 2008, kjs wrote: I've added .tailcall syntax to IMCC. It is supposed to be used instead of .return in tailcall context. Using .return for this is deprecated. I haven't tested yet, but i assume there are going to be a lot of uses of the old syntax throughout the repo that will need to be updated. Do any of our code generators like PCT use the old syntax? If so, how hard would it be to update them? A good first approximation might be to do the following: ack \.return\s+[^(] On my system this returns about 750 candidates. Pm
Re: [perl #60000] [BUG][IMCC] an :immediate sub cannot load_bytecode
On Mon, Oct 20, 2008 at 6:18 PM, chromatic [EMAIL PROTECTED] wrote: On Sunday 19 October 2008 14:02:58 Klaas-Jan Stol wrote: when running code as this: .sub main :immediate load_bytecode foo.pir .end (assuming you have a file 'foo.pir'), IMCC can't handle this. This is because in pbc.c, a global structure called 'globals' is used to allow the different functions to share access to some data (in particular, the code segment stuff). As documented by a warning in imcc's sources, a load_bytecode will trigger a (nested) compilation phase, which will overwrite this data. Parrot won't output anything (windows) , possibly segfaulting. The fix would be to store this 'globals' structure in the imcc_info structure (I think). That analysis sounds right to me as well. Is it affecting any language at the moment? As much as I hate modifying IMCC before a release, I wonder if it's a valuable fix. -- c Let's wait with it. It has been like this for ages, but I only recently actually tested it. The comments indicating it's dangerous have been there for a while. For now, Just Don't Do It (writing :immediate subs that load_bytecode). kjs
Re: [perl #58988] [RFC] Parrot_get_runtime_prefix function
'STRING *' is vastly preferable to 'char *' anywhere it can be used. Mark the old one as deprecated, replace all calls to 'Parrot_get_runtime_prefix' with calls to 'Parrot_get_runtime_path', and after a standard one release deprecation cycle remove the old function. Replaced a remaining usage and added a note in the =item of Parrot_get_runtime_prefix about his deprecation in r32054 -- Salu2
[svn:parrot-pdd] r32055 - trunk/docs/pdds
Author: kjs
Date: Mon Oct 20 13:53:10 2008
New Revision: 32055
Modified:
trunk/docs/pdds/pdd19_pir.pod
Log:
[docs] update pdd19 w.r.t. RT#58236 (.arg-.set_arg, etc.)
+ update examples
Modified: trunk/docs/pdds/pdd19_pir.pod
==
--- trunk/docs/pdds/pdd19_pir.pod (original)
+++ trunk/docs/pdds/pdd19_pir.pod Mon Oct 20 13:53:10 2008
@@ -75,6 +75,10 @@
num pmc string unless
+{{ NOTE: compilers/pirc does not have any reserved words; all keywords and ops
+ can be used as identifiers.
+}}
+
{{ NOTE: The use of C:: in identifiers is deprecated. [See RT #48735] }}
=head3 Labels
@@ -589,17 +593,39 @@
=item .return var [:flag]*
+{{ Deprecated; use .set_return instead. See RT#58236. }}
+
+=item .set_return var [:flag]*
+
Between C.begin_return and C.end_return, specify one or
more of the return value(s) of the current subroutine. Available
flags: C:flat, C:named.
+=item .yield var [:flag]*
+
+{{ Deprecated; use .set_yield instead. See RT#58236. }}
+
+=item .set_yield var [:flag]*
+
+Between C.begin_yield and C.end_yield, specify one or
+more of the yield value(s) of the current subroutine. Available
+flags: C:flat, C:named.
+
=item .arg var [:flag]*
+{{ Deprecated. Use .set_arg instead. See RT#58236. }}
+
+=item .set_arg var [:flag]*
+
Between C.begin_call and C.call, specify an argument to be
passed. Available flags: C:flat, C:named.
=item .result var [:flag]*
+{{ Deprecated. Use .get_result instead. See RT#58236. }}
+
+=item .get_result var [:flag]*
+
Between C.call and C.end_call, specify where one or more return
value(s) should be stored. Available flags:
C:slurpy, C:named, C:optional, and C:opt_flag.
@@ -825,12 +851,29 @@
syntax from other uses of the C.return directive that will be probably
deprecated.
+{{ Since .return is deprecated in .begin_/end_return, do we still need and/or
+ want the parentheses?
+}}
+
=item .return var(args)
+{{ Deprecated. Use .tailcall instead. See RT#58236. }}
+
=item .return var.'somemethod'(args)
+{{ Deprecated. Use .tailcall instead. See RT#58236. }}
+
=item .return var.var(args)
+{{ Deprecated. Use .tailcall instead. See RT#58236. }}
+
+=item .tailcall var(args)
+
+=item .tailcall var.'somemethod'(args)
+
+=item .tailcall var.var(args)
+
+
Tail call: call a function or method and return from the sub with the
function or method call return values.
@@ -881,7 +924,7 @@
runtime/parrot/include, in that order. The first file of that name to be found
is included.
-{{ NOTE: the Cinclude directive's search order is subject to change. }}
+{{ NOTE: the C.include directive's search order is subject to change. }}
=item * C.macro identifier [parameters]
@@ -1143,7 +1186,7 @@
.param int c
...
.begin_return
- .return xy
+ .set_return xy
.end_return
...
.end
@@ -1158,13 +1201,13 @@
.local num y
.local str z
.begin_call
- .arg x
- .arg y
- .arg z
+ .set_arg x
+ .set_arg y
+ .set_arg z
.call $P0, $P1# r = _sub_label(x, y, z)
ret_addr:
.local int r # optional - new result var
- .result r
+ .get_result r
.end_call
=head2 NCI Call
@@ -1173,12 +1216,12 @@
dlfunc $P1, $P0, funcname, signature
...
.begin_call
- .arg x
- .arg y
- .arg z
+ .set_arg x
+ .set_arg y
+ .set_arg z
.nci_call $P1 # r = funcname(x, y, z)
.local int r # optional - new result var
- .result r
+ .get_result r
.end_call
=head2 Subroutine Call Syntactic Sugar
@@ -1208,7 +1251,7 @@
self._other_meth()
...
.begin_return
- .return xy
+ .set_return xy
.end_return
...
.end
@@ -1226,13 +1269,13 @@
newclass class, Foo
new obj, class
.begin_call
- .arg x
- .arg y
- .arg z
+ .set_arg x
+ .set_arg y
+ .set_arg z
.invocant obj
.meth_call _method [, $P1 ] # r = obj._method(x, y, z)
.local int r # optional - new result var
- .result r
+ .get_result r
.end_call
The return continuation is optional. The method can be a string
@@ -1244,9 +1287,9 @@
.return ()# return no value
- .return func_call() # tail call function
+ .tailcall func_call() # tail call function
- .return o.meth()# tail method call
+ .tailcall o.meth()# tail method call
Similarly, one can yield using the .yield directive
@@ -1259,13 +1302,13 @@
Arguments are Bsaved in reverse order onto the user stack:
- .arg y # save args in reversed order
- .arg x
+ .set_arg y # save args in reversed order
+ .set_arg x
call _foo#(r, s) = _foo(x,y)
.local int r
.local int s
- .result r# restore results in order
- .result s#
+ .get_result r# restore results in order
+ .get_result s#
and return values are Brestored in argument order from there.
[perl #60016] [PATCH] Make basic Perl 6 tests pass
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #60016] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60016 If you do this after building parrot: cd languages/perl6 make test This basic test suite will fail. That's because of this test program: t/00-parrot/06-op-inplace.t It was written before modules could be loaded and manually printed out ok $num lines, but it did so out of sequence. This causes Test::Harness to note a parse error and report a failure for the test suite, even though all tests pass. I've updated it to use Test and output test numbers in sequence without altering the semantics of the test. make test in languages/perl6 now passes on my MacBook. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Tech blog- http://use.perl.org/~Ovid/journal/ Twitter - http://twitter.com/OvidPerl Official Perl 6 Wiki - http://www.perlfoundation.org/perl6 perl6tests.patch Description: Binary data
[perl #39760] [CAGE] make warnings (r13197 - x86-msvc-7.1)
On Dom. 19 Oct. 2008 13:47:11, kjs wrote: I think the issue of inconsistent dll linkage has been resolved recently by adding the YYMALLOC and YYFREE #defines to imcc source. Can other windows people confirm this? Then this ticket can be closed. Thank you very much, Confirmed. Parrot r31997 on Windows Vista and MSVC9.
[perl #60030] [BUG] segfault after using substr
# New Ticket Created by Jeff Horwitz
# Please include the string: [perl #60030]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60030
a while back in #parrot, i reported a rakudo segfault when calling use
with a multilevel namespace:
./parrot --gc-debug languages/perl6/perl6.pbc -e 'use Foo::Bar'
chromatic was able to reproduce, but debugging proved to be difficult.
however, i've since been able to narrow it down to a simple pure-PIR test
case:
===
.sub doit
.param string s
$I0 = index s, '::'
say s
substr s, $I0, 2, /
say s
collect
say s
.end
.sub main :main
doit('Foo::Bar')
.end
[EMAIL PROTECTED] parrot]$ ./parrot foo.pir
Foo::Bar
Foo/Bar
Segmentation fault
===
i used the collect opcode instead of --gc-debug as it helped with debugging.
in any case, the backtrace shows that the string buffer for s is no longer
valid after collect:
(gdb) p *s
$1 = {cache = {_b = {_bufstart = 0x2b648e5d5ad8, _buflen = 8}, _ptrs = {
_struct_val = 0x2b648e5d5ad8, _pmc_val = 0x8}, _i = {
_int_val = 47710885206744, _int_val2 = 8},
_num_val = 2.357230931332755e-310, _string_val = 0x2b648e5d5ad8},
flags = 131328,
strstart = 0x2b648e5d5ad8 Address 0x2b648e5d5ad8 out of bounds,
bufused = 7, strlen = 7, hashval = 0, encoding = 0x60ab10,
charset = 0x60c250}
after seeing that, i ran it again, setting a watchpoint on s-strstart so
i could see exactly when it was freed. the culprit is compact_pool, and i
was able to get the backtrace from the corresponding free():
Breakpoint 4, 0x2b87ad29fa90 in free () from /lib64/libc.so.6
(gdb) bt
#0 0x2b87ad29fa90 in free () from /lib64/libc.so.6
#1 0x2b87ab8a09bc in mem__internal_free (from=0x2b87ad794010,
file=0x2b87abaa2dc8 src/gc/resources.c, line=531) at
src/gc/memory.c:328
#2 0x2b87ab9692d5 in compact_pool (interp=0x609080, pool=0x60a4e0)
at src/gc/resources.c:531
#3 0x2b87ab969390 in Parrot_go_collect (interp=0x609080)
at src/gc/resources.c:564
#4 0x2b87ab8275d9 in Parrot_collect (cur_opcode=0x983700,
interp=0x609080)
at src/ops/core.ops:1187
#5 0x2b87ab8dc65f in runops_slow_core (interp=0x609080, pc=0x983700)
at src/runops_cores.c:222
#6 0x2b87ab8adbd4 in runops_int (interp=0x609080, offset=22)
at src/interpreter.c:937
#7 0x2b87ab8ae5c3 in runops (interp=0x609080, offs=22)
at src/inter_run.c:101
#8 0x2b87ab8ae899 in runops_args (interp=0x609080, sub=0x960f18,
obj=0x663350, meth_unused=0x0, sig=0x2b87aba9bf03 vP,
ap=0x7f60ad50)
at src/inter_run.c:236
#9 0x2b87ab8aea8b in Parrot_runops_fromc_args (interp=0x609080,
sub=0x960f18, sig=0x2b87aba9bf03 vP) at src/inter_run.c:300
#10 0x2b87ab8943fe in Parrot_runcode (interp=0x609080, argc=1,
argv=0x7f60b048) at src/embed.c:951
#11 0x2b87aba75568 in imcc_run_pbc (interp=0x609080, obj_file=0,
output_file=0x0, argc=1, argv=0x7f60b048) at
compilers/imcc/main.c:791
#12 0x2b87aba75f77 in imcc_run (interp=0x609080,
sourcefile=0x7f60bc42 foo.pir, argc=1, argv=0x7f60b048)
at compilers/imcc/main.c:1079
#13 0x00400b14 in main (argc=1, argv=0x7f60b048) at
src/main.c:61
i'm not sure if this is compact_pool's fault or if it's just the
messenger, but obviously the string is still in use and shouldn't be
freed. 2 other things i noted:
1) this only segfaults if the original string is passed as an argument to
a subroutine. for example, this works just fine:
.sub main :main
$S0 = 'Foo::Bar'
$I0 = index $S0, '::'
say $S0
substr $S0, $I0, 2, /
say $S0
collect
say $S0
.end
2) substr has some COW semantics, which may be relevant, but i'm not sure.
-jeff
[perl #60020] [TODO] remove coding standards tests from 'make test' target
# New Ticket Created by Allison Randal # Please include the string: [perl #60020] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60020 1) Remove the coding standards tests from the main 'make test' target. 2) Add a step to the release manager's guide to run 'make codetest' and fix various stray spaces, lines that are too long, etc. before cutting the release. We'll try this for a couple of releases and see how it goes. Allison
Re: [perl #59940] [patch] convert perl tests to parrot
jerry gay wrote:
On Fri, Oct 17, 2008 at 4:00 PM, Mark Grimes [EMAIL PROTECTED] wrote:
The attached patch now includes the pir/pasm_error_output* tests in
pir. I have also added t/pmc/complex.t. Couple of issues:
1) I am not sure how to deal with pcc_sub's so I put them into
t/pmc/objects-pcc_sub.t
2) There appears to be a bug that shows up in complex.t -
complex_divide_by_zero_*(). I have skip'ed those tests and will submit
a simplified bug report and test.
This drops the test run time for these from 24 seconds to less than 2.
Also, this patch should hopefully apply cleanly. I had to make some
changes to the $Id: line in the patch by hand.
-Mark
On Fri, Oct 17, 2008 at 10:35 AM, Mark Grimes [EMAIL PROTECTED] wrote:
On Fri, Oct 17, 2008 at 12:39 AM, Christoph Otto via RT
[EMAIL PROTECTED] wrote:
You can fix the foo_error_bar tests by using an exception handler to
catch the (appropriate type of) exception.
The simplest way is to use push_eh with a label. If the exception is
raised, control will jump to that label. t/pmc/resizablestringarray.t
uses this style.
Thanks Christoph. That is pretty straight forward. I'll update and
send a new patch.
when I was on my PIRifying binge, but I didn't have nearly enough
patience at the time.
Agreed. Takes quite a bit of patients, but I have put together a vim
function and perl script that takes care of some of the more common
test idioms automatically. I'll make it public after I clean it up a
bit more.
Any suggestion on how to deal the the .pcc_sub tests. I admit, I don't
quite understand what pcc_sub are, and I get an error whenever they
are included:
error:imcc:syntax error, unexpected PCC_SUB, exprint $end ('.pcc_sub')
There are two tests in object.t that use them.
s/\.pcc_sub/\.sub/g; ## this will fix it
~jerry
Hi Mark,
I've reviewed the updated complex.t and string.t, and have a few suggestions.
The patch no longer applies cleanly to objects.t, and I thought it'd be
better to let you merge the recent changes from svn and add the .pcc_sub
tests, given Jerry's suggestion. I'll be glad to review and commit an updated
version.
It's a good idea to test for exception types rather than exact messages. This
keeps the tests passing if the wording of the message is changed. The
exception type is much more likely to remain constant. This recommended but
not a blocker.
Test messages for shouldn't be blank. If a test fails, it should be fairly
obvious from the output what went wrong. This makes debugging easier, which
is always a good goal.
In string.t, don't worry about preserving comments about failing tests if the
relevant test passes.
Use $P0 instead of P0. Both currently work, but the non-$ syntax is deprecated.
This is a minor nit, but -ve and +ve generally expand to negative and
positive. Changing out_of_bounds_substr_neg_ve_offset would increase
readability, although it's already a mouthful.
Again, thanks for working on this.
Christoph
[perl #60016] [PATCH] Make basic Perl 6 tests pass
On Mon Oct 20 09:46:08 2008, [EMAIL PROTECTED] wrote: \ This basic test suite will fail. That's because of this test program: t/00-parrot/06-op-inplace.t I've reported this a couple of times in http://rt.perl.org/rt3/Ticket/Display.html?id=59634 -- but no one paid attention. Since you're proposing a patch, I'll merge 59634 into this one. kid51
[perl #59880] DOD crash in r31926, t/op/bitwise.t #27 on linux/x86_64
Anyone taking a look at this test should take note of the fact that the immediately preceding test in this file is also experiencing failures on certain platforms: http://rt.perl.org/rt3/Ticket/Display.html?id=59638
[perl #50040] [BUG] GC makes a namespace entry disappear?
From: Andrew Whitworth via RT [EMAIL PROTECTED] Date: Mon, 20 Oct 2008 16:47:03 -0700 On Mon Mar 03 15:11:25 2008, rgrjr wrote: From: Bob Rogers [EMAIL PROTECTED] Date: Sun, 2 Mar 2008 11:28:08 -0500 . . . if I revert string.pmc in r26175 (the one experiment I didn't bother trying), it does in fact work . . . And I notice that RT#50040 also no longer fails in r26175. (It had been failing in periodic rechecks after renaming orig-structures.pir to structures.pir, but those observations don't seem to have made it into RT.) -- Bob What's the status of this ticket now? From the last message here, it looks like maybe a solution was found (or an offending commit isolated). Does this still fail? If not, we can close this ticket. -- Andrew Whitworth a.k.a Whiteknight I believe chromatic resolved this in a spate of GC hackery last spring. I'm not sure exactly when, but I haven't been bothered by it in a while. -- Bob Rogers http://rgrjr.dyndns.org/
