[perl #41892] [BUG] t/stm/llqueue segment violation on test #2
On Mon Mar 19 10:22:42 2007, coke wrote: test TODOd for next release, thanks for the report. (Hopefully it'll get fixed shortly after the release.) On Sun Mar 18 08:07:05 2007, [EMAIL PROTECTED] wrote: I get SIGSEGV in t/stm/llqueue, test #2 openSuSe 10.2 linux 2.6.18.8-0.1-xen i686 athlon Tested at parrot svn revision 17614 t/stm/llqueueok 1/2 # Failed test (t/stm/llqueue.t at line 59) # got: '' # expected: 'sum is 4950 # ' # './parrot -D40 --gc-debug /home/uniejo/parrot/parrot/t/stm/llqueue_2.pir' failed with exit code [SIGNAL 11] t/stm/llqueueNOK 2# Looks like you failed 1 test of 2. t/stm/llqueuedubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 2 Failed 1/2 tests, 50.00% okay It looks like this test is passing now (on Debian/x86, at least). If someone doesn't mind confirming this, we can close this ticket.
[perl #58704] [BUG] t/src/compiler.t failures with VC++ / Win32
# New Ticket Created by Tim Heckman # Please include the string: [perl #58704] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58704 Output of prove -v t\src\compiler.t is attached. The generated linker command is incorrect. The /L option doesn't work with the Microsoft linker link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe -Lblib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib But, if I run this command using the documented linker option of /LIBPATH it *still* fails. link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe /LIBPATH:blib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib The only way I've been able to make this command line work is like this: link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe blib\lib\libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib I am not sure why this is. C and C++ are not my areas of expertise, so I may be doing something wrong here. I have tried it with the Visual Studio tools for both 2005 (professional edition) and 2008 (express edition) with the same results. It looks like this would require a change to lib\Parrot\Test.pm to emit a Visual Studio-specific linker command line. This has been turning up in the Smolder reports since early August. See for example http://smolder.plusthree.com/app/public_projects/report_details/5249 The GCC toolchain on Win32 does not have these failures. See http://smolder.plusthree.com/app/public_projects/report_details/5251 --Tim t/src/compiler 1..6 ok 1 # SKIP compreg disabled/imcc_compile_pir() not exported # 'link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe -Lblib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib' failed with exit code 96 # Failed to build 't\src\compiler_2.exe': LINK : warning LNK4044: unrecognized option '/Lblib\lib'; ignored # compiler_2.obj : error LNK2001: unresolved external symbol _PMCNULL # t\src\compiler_2.exe : fatal error LNK1120: 1 unresolved externals # Failed test 'Parrot Compile API Single call' # at t/src/compiler.t line 112. not ok 2 - Parrot Compile API Single call # 'link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_3.obj src\parrot_config.obj -out:t\src\compiler_3.exe -Lblib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib' failed with exit code 96 # Failed to build 't\src\compiler_3.exe': LINK : warning LNK4044: unrecognized option '/Lblib\lib'; ignored # compiler_3.obj : error LNK2001: unresolved external symbol _PMCNULL # t\src\compiler_3.exe : fatal error LNK1120: 1 unresolved externals # Failed test 'Parrot Compile API Multiple Calls' # at t/src/compiler.t line 194. not ok 3 - Parrot Compile API Multiple Calls # 'link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_4.obj src\parrot_config.obj -out:t\src\compiler_4.exe -Lblib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib' failed with exit code 96 # Failed to build 't\src\compiler_4.exe': LINK : warning LNK4044: unrecognized option '/Lblib\lib'; ignored # compiler_4.obj : error LNK2001: unresolved external symbol _PMCNULL # t\src\compiler_4.exe : fatal error LNK1120: 1 unresolved externals # Failed test 'Parrot Compile API Multiple 1st bad PIR' # at t/src/compiler.t line 287. not ok 4 - Parrot Compile API Multiple 1st bad PIR # 'link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_5.obj src\parrot_config.obj -out:t\src\compiler_5.exe -Lblib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib' failed with exit code 96 # Failed to build 't\src\compiler_5.exe': LINK : warning LNK4044: unrecognized option '/Lblib\lib'; ignored # compiler_5.obj : error LNK2001: unresolved external symbol _PMCNULL # t\src\compiler_5.exe : fatal error LNK1120: 1 unresolved externals # Failed test 'Parrot Compile API Multiple 2nd bad PIR' # at t/src/compiler.t line 380. not ok 5 - Parrot Compile API Multiple 2nd bad PIR # 'link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_6.obj src\parrot_config.obj -out:t\src\compiler_6.exe -Lblib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib' failed with exit code 96 # Failed to build 't\src\compiler_6.exe': LINK : warning LNK4044: unrecognized option '/Lblib\lib'; ignored # compiler_6.obj : error LNK2001: unresolved external symbol _PMCNULL # t\src\compiler_6.exe : fatal error LNK1120: 1 unresolved externals # Failed test 'Parrot Compile API Multiple bad PIR' # at t/src/compiler.t line 472. # Looks like you failed 5 tests of 6. not ok 6 - Parrot
Re: [perl #58704] [BUG] t/src/compiler.t failures with VC++ / Win32
On Tue, Sep 9, 2008 at 5:23 AM, via RT Tim Heckman [EMAIL PROTECTED] wrote: # New Ticket Created by Tim Heckman # Please include the string: [perl #58704] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58704 link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe -Lblib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib But, if I run this command using the documented linker option of /LIBPATH it *still* fails. link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe /LIBPATH:blib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib What are the error messages in this case? -- Salu2
[perl #41825] [BUG] morph vtable override not working in PIR
On Tue Nov 20 20:58:35 2007, [EMAIL PROTECTED] wrote: On Wed Mar 14 07:49:33 2007, [EMAIL PROTECTED] wrote: Hi, Given the following: .namespace ['A'] .sub 'morph' :method :vtable say 'morphing!' .end .sub main :main $P0 = newclass 'A' $P1 = new 'A' morph $P1, .Undef .end the 'morph' vtable method doesn't get called Works for me in 0.5.0 (r22925), if I remove :method from the 'morph' declaration. Can you confirm? I'm still seeing the broken behavior in r30915.
Re: [perl #58704] [BUG] t/src/compiler.t failures with VC++ / Win32
NotFound wrote: On Tue, Sep 9, 2008 at 5:23 AM, via RT Tim Heckman [EMAIL PROTECTED] wrote: # New Ticket Created by Tim Heckman # Please include the string: [perl #58704] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58704 link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe -Lblib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib But, if I run this command using the documented linker option of /LIBPATH it *still* fails. link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe /LIBPATH:blib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib What are the error messages in this case? It seems to ignore /LIBPATH C:\work\parrotlink -nologo -nodefaultlib -debug -machine:x86 -debug t/src/c ompiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe /LIBPATH:blib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib compiler_2.obj : error LNK2001: unresolved external symbol _PMCNULL t\src\compiler_2.exe : fatal error LNK1120: 1 unresolved externals C:\work\parrot --Tim
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Sat, 6 Sep 2008, chromatic wrote:
On Saturday 06 September 2008 20:19:56 James Keenan via RT wrote:
test_17787.c: In function 'main':
test_17787.c:45: error: 'SIGRTMIN' undeclared (first use in this function)
test_17787.c:45: error: (Each undeclared identifier is reported only once
test_17787.c:45: error: for each function it appears in.)
test_17787.c:46: error: 'SIGRTMAX' undeclared (first use in this function)
If they're not in signal.h in Darwin, where are they? (And if they're not in
signal.h in Darwin, can someone squelch the rumor that Mac OS X is a
Unix-like platform? POSIX 2001!)
... or we could use SIGUSR for the tests, I suppose. We're not using
real-time signals elsewhere in Parrot right now.
Parrot's also not using AIO anywhere either, so the whole probe is kind of
pointless right now. Mainly, I was just hoping that a minor fix would
help solve Patrick's problem of Configure.pl hanging during the aio probe.
I don't know if it actually made any difference.
Anyway, here's a minimally disruptive patch to change SIGRTMIN to SIGUSR1.
I also got rid of the completely-unused logic to add
SIGRTMIN + atoi(argv[1]), since that no longer makes any sense.
This patch also gets rid of the probing for SIGRTMIN and SIGRTMAX. If
parrot actually wants to use them, it should get them from a separate
probe, rather than relying on them as a side effect of this test. At the
moment, parrot doesn't use either one, so this does not change any
functionality.
After this patch, the probe will still be useless, since aio still isn't
used anywhere, but perhaps it will now pass on Darwin and not hang
elsewhere.
diff -r -u parrot-current/config/auto/aio/aio.in
parrot-andy/config/auto/aio/aio.in
--- parrot-current/config/auto/aio/aio.in 2008-09-08 08:38:49.0
-0400
+++ parrot-andy/config/auto/aio/aio.in 2008-09-09 07:45:03.0 -0400
@@ -36,14 +36,7 @@
int i = 42;
int cnt = 4;
-/* For internal use, we usually use
- SIGRTMIN + argv[1].
- Usually, that's set to
- SIGRTMIN + 1
- by the calling program.
-*/
-my_sig = SIGRTMIN + atoi(argv[1]);
-printf(SIGRTMIN=%d SIGRTMAX=%d\n, SIGRTMIN, SIGRTMAX);
+my_sig = SIGUSR1;
fd = open(MANIFEST, O_RDONLY);
if (fd 0)
diff -r -u parrot-svn/config/auto/aio.pm parrot-andy/config/auto/aio.pm
--- parrot-svn/config/auto/aio.pm 2008-09-08 08:38:49.0 -0400
+++ parrot-andy/config/auto/aio.pm 2008-09-09 07:46:14.0 -0400
@@ -49,14 +49,13 @@
my $errormsg = _first_probe_for_aio($conf, $verbose);
if ( ! $errormsg ) {
-my $test = $conf-cc_run(1); # Use signal RTMIN + 1
+my $test = $conf-cc_run();
# if the test is failing with sigaction err
# we should repeat it with a different signal number
# This is currently not implemented.
if (
-$test =~ /SIGRTMIN=(\d+)\sSIGRTMAX=(\d+)\n
-INFO=42\n
+$test =~ /INFO=42\n
ok/x
)
{
@@ -66,8 +65,6 @@
$conf-data-set(
aio= 'define',
HAS_AIO= 1,
-D_SIGRTMIN = $1,
-D_SIGRTMAX = $2,
);
}
else {
--
Andy Dougherty [EMAIL PROTECTED]
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Tue, Sep 09, 2008 at 08:46:33AM -0400, Andy Dougherty wrote: Parrot's also not using AIO anywhere either, so the whole probe is kind of pointless right now. Mainly, I was just hoping that a minor fix would help solve Patrick's problem of Configure.pl hanging during the aio probe. I don't know if it actually made any difference. The minor fix (preventing the infinite loop in the probe) has made a _huge_ difference, thanks. Pm
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Tue, Sep 9, 2008 at 8:46 AM, Andy Dougherty [EMAIL PROTECTED] wrote: Parrot's also not using AIO anywhere either, so the whole probe is kind of pointless right now. Instead of spending time fixing a probe that isn't being used, we should rip it out. If we eventually need it again, we can start from here, but there's no point in probing for features that we never use. It's wasting developer (and less importantly, CPU) time better spent elsewhere. Regards. -- Will Coke Coleda
Re: [perl #58704] [BUG] t/src/compiler.t failures with VC++ / Win32
Tim Heckman wrote: NotFound wrote: On Tue, Sep 9, 2008 at 5:23 AM, via RT Tim Heckman [EMAIL PROTECTED] wrote: # New Ticket Created by Tim Heckman # Please include the string: [perl #58704] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58704 link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe -Lblib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib But, if I run this command using the documented linker option of /LIBPATH it *still* fails. link -nologo -nodefaultlib -debug -machine:x86 -debug t/src/compiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe /LIBPATH:blib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib What are the error messages in this case? It seems to ignore /LIBPATH C:\work\parrotlink -nologo -nodefaultlib -debug -machine:x86 -debug t/src/c ompiler_2.obj src\parrot_config.obj -out:t\src\compiler_2.exe /LIBPATH:blib\lib libparrot.lib kernel32.lib ws2_32.lib msvcrt.lib oldnames.lib compiler_2.obj : error LNK2001: unresolved external symbol _PMCNULL t\src\compiler_2.exe : fatal error LNK1120: 1 unresolved externals C:\work\parrot /LIBPATH adds a path to the library search path, which isn't used here for libparrot.lib because the path to the library is already specified, i.e. your FC:\work\parrot\libparrot.lib. Note that there are two libparrot.lib files: $PARROT_HOME/libparrot.lib, the import library for the dynamic libparrot.dll, and $PARROT_HOME/blib/lib/libparrot.lib, the static Parrot library. Try deleting your $PARROT_HOME/libparrot.lib and you should see LIBPATH working. Embedding Parrot on Windows using the DLL is currently broken because PMCNULL is not properly exported. That's why you receive the latter unresolved symbol error. The static library (in blib/lib) doesn't suffer from this. Ron
Re: [perl #54110] [BUG] segfault in infix/n_infix with string arguments
On Fri, Sep 05, 2008 at 05:20:45PM -0700, Christoph Otto via RT wrote: On Tue, May 13, 2008 at 9:48 AM, via RT Patrick R. Michaud The infix and n_infix opcodes cause segfaults when invoked with string arguments. (Kubuntu 8.04, x86, r27472) $ cat z.pir .sub main :main $P0 = new 'Float' $P0 = 3 n_mul $P1, $P0, 4 say $P1# 12 .end $ ./parrot z.pir Segmentation fault $ Is this bug going to continue to be relevant, since the pdd27mmd branch has removed the n_* opcodes (and presumably trunk will too after the branch is merged back)? Just for clarification: IIUC, the n_* opcodes and their semantics aren't really going away -- they're simply being renamed to not have the leading n_ prefix. It's the existing add, sub, mul, div, etc. opcodes that are being eliminated. So, trying the above code in the pdd27mmd branch (and changing the 'n_mul' to 'mul'), I now get: $ cat x.pir .sub main :main $P0 = new 'Float' $P0 = 3 mul $P1, $P0, '4' say $P1# 12 .end $ ./parrot x.pir error:imcc:The opcode 'mul_p_p_sc' (mul3) was not found. Check the type and number of the arguments in file 'x.pir' line 5 $ This would seem to indicate that the string variants of the various math opcodes are also going away (and that's okay with me). So, if we can just get an official ruling that the add_p_p_s, sub_p_p_s, etc. opcodes are going away, then we can close this ticket as moot. If they're not going away, then this ticket is still relevant. It would also be relevant because Parrot trunk fails on the non-n_ versions of the opcodes in the same way: $ cat x.pir .sub main :main $P0 = new 'Float' $P0 = 3 $P1 = new 'Float' mul $P1, $P0, '4' say $P1# 12 .end $ ./parrot x.pir Segmentation fault Pm
Re: [perl #45357] [TODO] Which exception should be thrown with register overflow?
It seems that the error condition refers to the case where too many arguments are passed (#args #params).It's not really overflow in that sense, IMHO, just too many arguments passed. I think an exception is already thrown when that happens, not sure. kjs On Tue, Sep 9, 2008 at 12:02 AM, chromatic [EMAIL PROTECTED] wrote: On Monday 08 September 2008 12:57:00 Christoph Otto via RT wrote: On Tue Sep 11 03:32:51 2007, pcoch wrote: Having a look through PDD03 I noticed the TODO item left by Chip: =head3 Overflow If too many values are provided to fit into the given target registers, Parrot will throw an exception. Note that if the final target is a P register with FLAT set, then this exception can never occur. XXX - FIXME - which exception? We really could use an exception subsystem. Oh, wait, that's my job. Never mind. --Chip What should we do here? Do we already have an exception subsystem? Has this been designed/implemented? Given the way Parrot currently regards registers, is this ticket still relevant? It looks like it. How about EXCEPTION_ERR_OVERFLOW? It's already an exception type. -- c
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Tue, 9 Sep 2008, Will Coleda wrote: On Tue, Sep 9, 2008 at 8:46 AM, Andy Dougherty [EMAIL PROTECTED] wrote: Parrot's also not using AIO anywhere either, so the whole probe is kind of pointless right now. Instead of spending time fixing a probe that isn't being used, we should rip it out. If we eventually need it again, we can start from here, but there's no point in probing for features that we never use. It's wasting developer (and less importantly, CPU) time better spent elsewhere. In general, I'd agree. However, in this particular case, fixing it was easier for me than figuring out all the steps necessary to rip it out. -- Andy Dougherty [EMAIL PROTECTED]
[perl #58278] [BUG] Slurpy params give Cannot morph a Perl6Scalar. error
Hello.
There is patch that fixes this error (and makes first 6 tests from
S06/slurpy-params.t passing). Unfortunately it triggers bug from #58718
--
Bacek.
diff --git a/languages/perl6/src/parser/actions.pm b/languages/perl6/src/parser/actions.pm
index 349f433..27ddcd0 100644
--- a/languages/perl6/src/parser/actions.pm
+++ b/languages/perl6/src/parser/actions.pm
@@ -1068,7 +1068,8 @@ method signature($/) {
),
PAST::Op.new(
:inline(
-'%r = new Perl6Scalar, %0',
+'%r = new Perl6Scalar',
+'%r.infix:=(%0)',
'$P0 = get_hll_global [Bool], True',
'setprop %r, readonly, $P0'
),
@@ -1089,8 +1090,7 @@ method signature($/) {
),
PAST::Op.new(
:inline(
-'%r = new Perl6Scalar',
-'%r.infix:=(%0)'
+'%r = clone %0'
),
PAST::Var.new(
:name($parameter.name()),
[perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Tue Sep 09 05:57:40 2008, coke wrote: On Tue, Sep 9, 2008 at 8:46 AM, Andy Dougherty [EMAIL PROTECTED] wrote: Parrot's also not using AIO anywhere either, so the whole probe is kind of pointless right now. Instead of spending time fixing a probe that isn't being used, we should rip it out. If we eventually need it again, we can start from here, but there's no point in probing for features that we never use. It's wasting developer (and less importantly, CPU) time better spent elsewhere. Coke: I lean toward this position -- less is more -- but will implement whatever is decided. Perhaps you can discuss this in parrotsketch today? Thank you very much. kid51
Re: [perl #58278] [BUG] Slurpy params give Cannot morph a Perl6Scalar. error
Patch rejected; the patch appears to eliminate Perl6Scalar
entirely from the 'is copy' semantics, this means we'd be without
an appropriate Scalar container for something like
sub foo($a is copy) { ... }
In general I think much of the signature handling in Rakudo needs
a significant refactor, so I'm a bit reluctant to apply small
tweaks until that happens.
Thanks!
Pm
@@ -1089,8 +1090,7 @@ method signature($/) {
),
PAST::Op.new(
:inline(
-'%r = new Perl6Scalar',
-'%r.infix:=(%0)'
+'%r = clone %0'
),
PAST::Var.new(
:name($parameter.name()),
request for help (only a little :-): build pirc on linux
hi, recently I had a good look at Parrot's Makefile to figure out what link flags I need to link PIRC against libparrot. This worked out quite well, and I'm now able to link in libparrot so PIRC can now call all Parrot functions. (the only major thing that needs to be done to get rid of IMCC is generate PBC from the PASM assembly instructions that are being generated) However, I'm on windows, and don't have a linux box. My request, then, is as follows: could anybody on linux check out whether s/he can build PIRC (in compilers/pirc/new) and link against libparrot? I'd like to know that it can work on Linux as well. I put the commands that I'm using in the README file (but that's for MSVC on windows), but I don't have any knowledge on how to do this on linux. thanks in advance, kjs
Re: request for help (only a little :-): build pirc on linux
I put the commands that I'm using in the README file (but that's for MSVC on windows), but I don't have any knowledge on how to do this on linux. There is no README file in compilers/pirc/new -- Salu2
Re: Why Some MMD Tests Fail
jerry gay wrote: On Mon, Sep 8, 2008 at 1:09 AM, Allison Randal [EMAIL PROTECTED] wrote: a) Do abstract base classes as currently implemented in Parrot serve any useful purpose? If not, eliminate them. can they be replaced by roles? Potentially, yes. In the case of the scalar PMC it would make quite a bit of sense as a role (composing in behavior common to scalar data types). For the default PMC it makes less sense. But then, I can see some argument there that default shouldn't be a PMC at all. Allison
Re: Why Some MMD Tests Fail
On Tuesday 09 September 2008 09:51:37 Allison Randal wrote: jerry gay wrote: can they be replaced by roles? Potentially, yes. In the case of the scalar PMC it would make quite a bit of sense as a role (composing in behavior common to scalar data types). For the default PMC it makes less sense. But then, I can see some argument there that default shouldn't be a PMC at all. When I revised vtable initialization, I reordered PMC class initialization to start at the top of the hierarchy and proceed in inheritance order. This means that PMCs can clone their parent vtables and override only the specific function pointers they provide. Abstract PMCs gave me a little trouble because they don't have vtables (they only exist as names). This isn't really a problem for core PMCs, because they can refer to functions defined in other PMCs as they all get compiled together into libparrot. That's a real violation of encapsulation for dynpmcs though, and it's the reason why we export some 12,000 functions from libparrot. In the case of MMD, we also need to initialize MMD table entries for roles and other abstract PMCs. We need a way of initializing vtable function pointers given a vtable and the name of a PMC, and then we can likely support both features. (We might even use the same mechanism for performing vtable swaps when a Key PMC stops holding an INTVAL and starts holding a STRING or a PMC, for example. Call it the ultimate in PIC.) -- c
[perl #58724] [pirc] Smolder Failures
# New Ticket Created by Will Coleda # Please include the string: [perl #58724] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58724 http://smolder.plusthree.com/app/public_projects/report_details/5297#first_failure (but there's more than one) All the failures seem to be from compilers/pirc. -- Will Coke Coleda
Re: [perl #58724] [pirc] Smolder Failures
Will Coleda (via RT) wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #58724] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58724 http://smolder.plusthree.com/app/public_projects/report_details/5297#first_failure (but there's more than one) All the failures seem to be from compilers/pirc. Should be fixed with r30934. Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Smolder graphs for larger timespans useless
Hi, the graphs on http://smolder.plusthree.com/app/public_graphs/start/8 become pretty useless as soon as I select a larger time span (say, 5 days): instead of displaying data, it mostly displays a gray area of fancy 3D shadows. Maybe the graph generation could be tweaked, or a simple, traditional 2D lines plot could be used instead? Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
Re: Smolder graphs for larger timespans useless
Moritz Lenz wrote: the graphs on http://smolder.plusthree.com/app/public_graphs/start/8 become pretty useless as soon as I select a larger time span (say, 5 days): instead of displaying data, it mostly displays a gray area of fancy 3D shadows. I agree that the shadows can cause a problem. But I think the main point is that there is a lot of data. Just for the months of August there were 1,638 smoke reports submitted. It's hard to usefully cram 1,638 into a 600 pixel area. Maybe the graph generation could be tweaked, or a simple, traditional 2D lines plot could be used instead? I could add the option for 2D graphs as well. But I'm not sure that will be enough for more than a couple of days worth of data. Maybe I need to find something smarter than GD::Graph for large data sets. Any ideas? -- Michael Peters Plus Three, LP
Re: Smolder graphs for larger timespans useless
Michael Peters wrote: Moritz Lenz wrote: the graphs on http://smolder.plusthree.com/app/public_graphs/start/8 become pretty useless as soon as I select a larger time span (say, 5 days): instead of displaying data, it mostly displays a gray area of fancy 3D shadows. I agree that the shadows can cause a problem. But I think the main point is that there is a lot of data. Just for the months of August there were 1,638 smoke reports submitted. It's hard to usefully cram 1,638 into a 600 pixel area. Aye. But I think 5 days is not too much to ask for ;-) Maybe the graph generation could be tweaked, or a simple, traditional 2D lines plot could be used instead? I could add the option for 2D graphs as well. But I'm not sure that will be enough for more than a couple of days worth of data. Maybe I need to find something smarter than GD::Graph for large data sets. Any ideas? Piping to gnuplot usually works very well for me. Thinking more of it, I think a scatter plot would be better for a graph with many discontinuities. (800 data points on 600 pixels are no problem for gnuplot, haven't tried with much more yet, but I think it scales well). Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/
More MMD Branch Diagnosis
t/op/calling_61.pir crashes because Parrot's trying to treat the number -1 as
a PMC. Why?
Parrot_convert_arg (interp=0x804f040, st=0xbf8b70c0) at src/inter_call.c:905
905 if (key-vtable-base_type != enum_class_Key)
(gdb) bt
#0 Parrot_convert_arg (interp=0x804f040, st=0xbf8b70c0)
at src/inter_call.c:905
#1 0xb7d39d51 in set_nci_P (interp=0x804f040, st=0xbf8b70c0, val=0x)
at src/nci.c:150
#2 0xb7d3ce40 in pcf_P_JPP (interp=0x804f040, self=0x80da230)
at src/nci.c:1771
#3 0xb7e3532e in Parrot_NCI_invoke (interp=0x804f040, pmc=0x80da230,
next=0x0)
at ./src/pmc/nci.pmc:309
#4 0xb7d1c534 in Parrot_pcc_invoke_sub_from_sig_object (interp=0x804f040,
sub_obj=0x80da230, sig_obj=0x80f38f8) at src/inter_call.c:2471
#5 0xb7d27b80 in Parrot_mmd_multi_dispatch_from_c_args (interp=0x804f040,
name=0xb7f2bc3e cmp, sig=0xb7f03acf PP-I) at src/multidispatch.c:629
#6 0xb7e00166 in Parrot_default_cmp (interp=0x804f040, pmc=0x80f3930,
value=0x80f3914) at ./src/pmc/default.pmc:2447
#7 0xb7ccacfa in Parrot_lt_p_i_ic (cur_opcode=0x8127c88, interp=0x804f040)
at src/ops/cmp.ops:315
The desired MMD sub should take two PMCs and returns an INTVAL (frame #5,
signature PP-I), but the invoked MMD sub takes two PMCs and returns a PMC.
The crash comes in convert_arg, where the C function has returned INTVAL -1,
but the argument passing code expects that it has returned and Integer PMC.
Because 0x isn't a valid PMC pointer, there's a crash.
If you look at src/pmc/integer.pmc, the cmp MULTIs there return INTVALs
(signature IJPP), but the MULTI registration code declares them as signature
PJPP. I modified Parrot::Pmc2c::MULTI to improve the return-value-of-cmp
regexp and the test passes.
-- c
Index: lib/Parrot/Pmc2c/MULTI.pm
===
--- lib/Parrot/Pmc2c/MULTI.pm (revision 30934)
+++ lib/Parrot/Pmc2c/MULTI.pm (working copy)
@@ -93,7 +93,7 @@
# prepend the short signature return type
if ($self-name =~ /^i_/) {
$short_sig = v . $short_sig;
-} elsif ($self-name =~ /^is_/ or $self-name =~ /^cmp_/) {
+} elsif ($self-name =~ /^is_/ or $self-name =~ /\bcmp\b/) {
$short_sig = I . $short_sig;
} else {
$short_sig = P . $short_sig;
Save the date: Parrot Developer Summit, November 15-16, 2008
Google has graciously agreed to host the first ever Parrot Developer Summit. November 15th and 16th, 2008 on Google's Mountain View campus. You can find directions to the campus at: http://code.google.com/events/visitors More details to follow. Hope to see you there! Allison
Re: More MMD Branch Diagnosis
chromatic wrote: t/op/calling_61.pir crashes because Parrot's trying to treat the number -1 as a PMC. Why? The desired MMD sub should take two PMCs and returns an INTVAL (frame #5, signature PP-I), but the invoked MMD sub takes two PMCs and returns a PMC. The crash comes in convert_arg, where the C function has returned INTVAL -1, but the argument passing code expects that it has returned and Integer PMC. Because 0x isn't a valid PMC pointer, there's a crash. If you look at src/pmc/integer.pmc, the cmp MULTIs there return INTVALs (signature IJPP), but the MULTI registration code declares them as signature PJPP. I modified Parrot::Pmc2c::MULTI to improve the return-value-of-cmp regexp and the test passes. Excellent! Go ahead and apply. This will also fix the PGE build problem, which is the same segfault caused by the wrong signature on the NCI sub. Allison
Re: [perl #54110] [BUG] segfault in infix/n_infix with string arguments
Patrick R. Michaud wrote: Just for clarification: IIUC, the n_* opcodes and their semantics aren't really going away -- they're simply being renamed to not have the leading n_ prefix. It's the existing add, sub, mul, div, etc. opcodes that are being eliminated. Yes. That is, calling 'add', 'sub', etc. will now create a new PMC for the result on all the builtin PMCs. But, HLL/application developers will have the option of writing their own PMCs that reuse the destination PMC instead of a creating a new one. [...] This would seem to indicate that the string variants of the various math opcodes are also going away (and that's okay with me). So, if we can just get an official ruling that the add_p_p_s, sub_p_p_s, etc. opcodes are going away, then we can close this ticket as moot. Yes, these string variants only existed because of the unintelligent way the infix/n_infix opcodes blindly redispatched. In the branch, where the math opcodes are real opcodes, there are no string variants and we're not adding them. So, ticket can be reclassified as irrelevant. Allison
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
Will Coleda wrote: Instead of spending time fixing a probe that isn't being used, we should rip it out. If we eventually need it again, we can start from here, but there's no point in probing for features that we never use. It's wasting developer (and less importantly, CPU) time better spent elsewhere. Generally agreed. In this case, hold this ticket for the I/O milestone, which is next (sometime in the next few days). I've added it to the I/O tasklist. In the meantime, let's get Andy's patch applied (if it isn't already). Allison
Re: [svn:parrot] r30941 - branches/pdd27mmd/src
On Tuesday 09 September 2008 15:34:21 [EMAIL PROTECTED] wrote: [pdd27mmd] Fix failing coding standards test for line length. Modified: branches/pdd27mmd/src/multidispatch.c === === --- branches/pdd27mmd/src/multidispatch.c (original) +++ branches/pdd27mmd/src/multidispatch.c Tue Sep 9 15:34:21 2008 @@ -619,12 +619,14 @@ #if MMD_DEBUG fprintf(stderr, candidate found for '%s', with signature '%s'\n, name, sig); - fprintf(stderr, type of candidate found: %s\n, string_to_cstring(interp, VTABLE_name(interp, sub))); + fprintf(stderr, type of candidate found: %s\n, + string_to_cstring(interp, VTABLE_name(interp, sub))); #endif That C string leaks. We should have a diagnostic printf which supports the %Ss format we use in exception formatting strings. -- c
[perl #54800] ignoring named arguments if there is an optional positional argument missing
rakudo: sub foo($x?, :$y = 2){ say $x~|~$y}; foo(:y(3));
exp_evalbot
OUTPUT[|]
This appears to be a bug in Parrot (now RT#54860). When that's fixed
this one should be fixed also.
RT#54860 is fixed, verified:
rakudo: sub foo($x?, :$y = 2){ say $x~|~$y}; foo(:y(3));
OUTPUT[Use of uninitialized value|3]
[perl #58636] Must Instantiate Class PMCs Before Using Them in HLL Mappings
With this commit r30847, partcl lua are broken. $ ./parrot languages/lua/lua.pbc Segmentation fault #0 0xb7c93a03 in pmc_new_noinit (interp=0x804f040, base_type=86) at src/pmc.c:300 #1 0xb7c4dd5b in Parrot_register_HLL_type (interp=0x804f040, hll_id=1, core_type=17, hll_type=86) at src/hll.c:362 #2 0xb7dc59ce in Parrot_ParrotInterpreter_thawfinish (interp=0x804f040, pmc=0x8214800, info=0xbfd136b8) at ./src/pmc/parrotinterpreter.pmc:670 #3 0xb7c930bc in visit_loop_todo_list (interp=0x804f040, current=0x8214800, info=0xbfd136b8) at src/pmc_freeze.c:1609 #4 0xb7c93276 in run_thaw (interp=0x804f040, image=0x82218e4, what=VISIT_THAW_NORMAL) at src/pmc_freeze.c:1700 #5 0xb7c934f0 in Parrot_thaw (interp=0x804f040, image=0x82218e4) at src/pmc_freeze.c:1820 #6 0xb7c8e030 in PackFile_Constant_unpack_pmc (interp=0x804f040, constt=0x822e4e0, self=0x8237c00, cursor=0xb6748fe8) at src/packfile.c:3588 #7 0xb7c8df88 in PackFile_Constant_unpack (interp=0x804f040, constt=0x822e4e0, self=0x8237c00, cursor=0xb6748e78) at src/packfile.c:3542 #8 0xb7c8dc8c in PackFile_ConstTable_unpack (interp=0x804f040, seg=0x822e4e0, cursor=0xb6748e74) at src/packfile.c:3338 #9 0xb7c8b3aa in PackFile_Segment_unpack (interp=0x804f040, self=0x822e4e0, cursor=0xb6748e70) at src/packfile.c:1614 #10 0xb7c8b8ce in directory_unpack (interp=0x804f040, segp=0x822e388, cursor=0xb6748e60) at src/packfile.c:1808 #11 0xb7c8b3aa in PackFile_Segment_unpack (interp=0x804f040, self=0x822e388, cursor=0xb6701040) at src/packfile.c:1614 #12 0xb7c8a303 in PackFile_unpack (interp=0x804f040, self=0x822e388, packed=0xb6701000, packed_size=747344) at src/packfile.c:877 #13 0xb7c3d7d5 in Parrot_readbc (interp=0x804f040, fullname=0xbfd146fb languages/lua/lua.pbc) at src/embed.c:506 #14 0xb7ea49db in imcc_run (interp=0x804f040, sourcefile=0xbfd146fb languages/lua/lua.pbc, argc=1, argv=0xbfd13a98) at compilers/imcc/main.c:1039 #15 0x08048998 in main (argc=1, argv=0xbfd13a98) at src/main.c:61 François.
[perl #51262] [BUG] Segfault in pdump
I've recently commited a fix on null string constants. I think it was the same problem described here. I compiled the pir file and pdumped without a problem, it shows the DATA = NULL my fix introduced. Can you verify the problem is gone?
[perl #55196] [BUG] print/say opcodes have different float precision
This falls under the I/O PDD, the next milestone. Hold for a couple of days. I've added it to the tasklist for the milestone: The print and say opcodes had already been changed some weeks ago, now both call PIO_printf on INT and NUM. By the way, now FLOATVAL_FMT is used instead of %f
[perl #58726] [PATCH] add the option encoding to Configure.pl
# New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #58726] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58726 Hello, this patch adds the option encoding to the configuration of Parrot: perl Configure.pl --encoding=UTF-8 According to this option a line like the following will be generated in the file include/parrot/config.h: #define PARROT_DEF_ENCODING UTF-8 In the function Parrot_charsets_encodings_init according to the macro the function Parrot_make_default_encoding will be called to set the specified default encoding. I attached a tar-file that holds one patch file (generated with diff -u) for each modified file. Gerd Pokorra patch.tar Description: Unix tar archive
Re: [perl #58726] [PATCH] add the option encoding to Configure.pl
On Tuesday 09 September 2008 11:07:09 [EMAIL PROTECTED] (via RT) wrote: I attached a tar-file that holds one patch file (generated with diff -u) for each modified file. This makes patches very difficult to review; can you send a single patch file instead? -- c
[perl #55372] [BUG] Segfault/double free when manually running perl6
On Sun Sep 07 15:19:22 2008, cotto wrote: On Thu Jun 12 10:23:06 2008, [EMAIL PROTECTED] wrote: On Thursday 12 June 2008 10:01:21 NotFound wrote: Some more details: adding: Parrot_set_flag(interp, PARROT_DESTROY_FLAG); in src/main.c it segfaults also when executing with perl6.pbc, and also a lot of parrot test fails. So it looks like there is a general problem of interpreter destruction in exits from the exception handler. That's why I added the flag in the fakecutables; I figured we'd never catch these problems unless we tested for them frequently. -- c I'm no longer seeing a double-free (linux/x86). The test in question still fails, but it doesn't fail quite as horribly. If there are no objections, I'll close this ticket before the next #parrotsketch. resolved
Re: [CAGE] Opportunities for Perl 5 programmers in Parrot project
James E Keenan wrote: This post is addressed to those of you who (a) have Perl 5 programming skills and (b) have been lurking on the list or on #parrot without yet dipping your toes in the water. I have a number of projects, some of which are already in the form of RT tickets, some not, which require only Perl 5 programming skills and common sense. I would like to share the joys of cage-cleaning with others. Wow! I was getting responses within hours, and I got a total of 6 responses in 24 hours. That's much better than the response to any previous calls for volunteers I've put out in Parrot (or any other OS project, for that matter). I started to respond individually last night, but got even more responses during the day today. Better still, of the 6 responses I got, 5 are from people whose names I have not previously seen on the Parrot. 3 are from people who were previously unknown to me. 1 is from a person I know only from the YAPC list. And another is from a person who responded to a post I made about the joys of collective hacking on the Perl Seminar NY list two years ago! And, based on email addresses, at least two are from countries whose country identifiers I have not previously seen on our list! In fact, we're in the unusual position of being oversubscribed: more volunteers than we (or, at least, I have) at the moment. So what I'm going to do is this: 1. I will encourage all of you who wrote me to get Bitcard accounts (http://tinyurl.com/5eqcw8) so that you're eligible to post patches through our RT interface (http://rt.perl.org/rt3/Public). One of the 6 already has an RT account; the others of you should get one. 2. I will file an RT for some cleanup work on the configuration steps tests and direct one person who specifically volunteered for that to that RT. (Of course, once an RT is filed, anyone can take a crack at it.) 3. I will file a separate RT for another project. This second RT will actually be a way to track progress on more than a dozen RTs focusing on smartlinks. I will encourage the other people who wrote me over the past night and day to work on those. 4. Any other Perl 5 projects connected to Parrot we can have people work on? Please let me know. Thank you very much. kid51
[perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Tue Sep 09 15:14:36 2008, [EMAIL PROTECTED] wrote: Generally agreed. In this case, hold this ticket for the I/O milestone, which is next (sometime in the next few days). I've added it to the I/O tasklist. In the meantime, let's get Andy's patch applied (if it isn't already). I extracted the attached patch from email text and applied it in r30946. All tests pass, but note that I still don't get correct detection of AIO capabilities on Darwin/PPC (OS X 10.4). The message I get with verbose-step=auto::aio is in the second attachment. Ticket remains open. Thanks to all who have contributed so far. kid51 auto::aio - Does your platform support AIO... /usr/bin/gcc -fno-common -no-cpp-precomp -pipe -I/opt/local/include -pipe -fno-common -Wno-long-double -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHASATTRIBUTE_MALLOC -DHASATTRIBUTE_NONNULL -DHASATTRIBUTE_NORETURN -DHASATTRIBUTE_PURE -DHASATTRIBUTE_UNUSED -DHASATTRIBUTE_WARN_UNUSED_RESULT -falign-functions=16 -fvisibility=hidden -W -Wall -Waggregate-return -Wcast-align -Wcast-qual -Wchar-subscripts -Wcomment -Wdisabled-optimization -Wendif-labels -Wextra -Wformat -Wformat-extra-args -Wformat-nonliteral -Wformat-security -Wformat-y2k -Wimplicit -Wimport -Winit-self -Winline -Winvalid-pch -Wmissing-braces -Wmissing-field-initializers -Wno-missing-format-attribute -Wmissing-include-dirs -Wpacked -Wparentheses -Wpointer-arith -Wreturn-type -Wsequence-point -Wno-shadow -Wsign-compare -Wstrict-aliasing -Wstrict-aliasing=2 -Wswitch -Wswitch-default -Wtrigraphs -Wundef -Wunknown-pragmas -Wno-unused -Wvariadic-macros -Wwrite-strings -Wbad-function-cast -Wdeclaration-after-statement -Wimplicit-function-declaration -Wimplicit-int -Wmain -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wnonnull -I./include -c test_19186.c c++ -undefined dynamic_lookup test_19186.o -o test_19186 -lm -lrt /usr/bin/ld: can't locate file for: -lrt collect2: ld returned 1 exit status (no) Setting Configuration Data: ( verbose = undef, ); Does your platform support AIO...no.
[perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
On Tue Sep 09 18:22:30 2008, [EMAIL PROTECTED] wrote:
I extracted the attached patch from email text and applied it in r30946.
For some reason, the first attachment -- Andy's patch -- didn't get
attached. Trying again.
diff -r -u parrot-current/config/auto/aio/aio.in
parrot-andy/config/auto/aio/aio.in
--- parrot-current/config/auto/aio/aio.in 2008-09-08 08:38:49.0
-0400
+++ parrot-andy/config/auto/aio/aio.in 2008-09-09 07:45:03.0 -0400
@@ -36,14 +36,7 @@
int i = 42;
int cnt = 4;
-/* For internal use, we usually use
- SIGRTMIN + argv[1].
- Usually, that's set to
- SIGRTMIN + 1
- by the calling program.
-*/
-my_sig = SIGRTMIN + atoi(argv[1]);
-printf(SIGRTMIN=%d SIGRTMAX=%d\n, SIGRTMIN, SIGRTMAX);
+my_sig = SIGUSR1;
fd = open(MANIFEST, O_RDONLY);
if (fd 0)
diff -r -u parrot-svn/config/auto/aio.pm parrot-andy/config/auto/aio.pm
--- parrot-svn/config/auto/aio.pm 2008-09-08 08:38:49.0 -0400
+++ parrot-andy/config/auto/aio.pm 2008-09-09 07:46:14.0 -0400
@@ -49,14 +49,13 @@
my $errormsg = _first_probe_for_aio($conf, $verbose);
if ( ! $errormsg ) {
-my $test = $conf-cc_run(1); # Use signal RTMIN + 1
+my $test = $conf-cc_run();
# if the test is failing with sigaction err
# we should repeat it with a different signal number
# This is currently not implemented.
if (
-$test =~ /SIGRTMIN=(\d+)\sSIGRTMAX=(\d+)\n
-INFO=42\n
+$test =~ /INFO=42\n
ok/x
)
{
@@ -66,8 +65,6 @@
$conf-data-set(
aio= 'define',
HAS_AIO= 1,
-D_SIGRTMIN = $1,
-D_SIGRTMAX = $2,
);
}
else {
[perl #51262] [BUG] Segfault in pdump
From: NotFound via RT [EMAIL PROTECTED] Date: Tue, 09 Sep 2008 10:47:05 -0700 I've recently commited a fix on null string constants. I think it was the same problem described here. I compiled the pir file and pdumped without a problem, it shows the DATA = NULL my fix introduced. Can you verify the problem is gone? I assume you are referring to r30756 of src/packdump.c? Yes, that does avoid the segfault (though it reports the string value as NULL instead of ''). But isn't this really a bug in PIO_printf handling of %.*s? -- Bob
