Re: [ANN] SF parrot win32
Andrew Shitov wrote: I have no personal web site, so I create the project parrotwin32 on sourceforge : http://parrotwin32.sourceforge.net/ Cool, and I also promoted it at http://perl6.ru/parrotwin32/. But an attempt to run perl6.pbc faied: C:\Program Files\parrot-0.5.0-develbin/parrot.exe languages/perl6/perl6.pbc load_bytecode couldn't find file 'PGE.pbc' current instr.: 'parrot;Perl6::Compiler;__onload' pc 0 (perl6.pir:30) called from Sub 'parrot;Perl6::Compiler;main' pc -1 ((unknown file):-1) Probably setup.exe have to update an environment also? We have thousand tests in build tree, but nothing for testing install tree. So, there are missing part. Now, I append a new tools/install/smoke.pl. setup-parrot-0.5.0 is good for only running PIR file, I hope 0.5.1 allow to run others languages. François. -- Andrew Shitov __ [EMAIL PROTECTED] | http://www.shitov.ru
Platform testing for concurrency scheduler runloop
I'm about to turn on the concurrency scheduler runloop in Parrot trunk. Before I do, I'd like test results on as many platforms as possible (especially Windows, since it doesn't use POSIX threads). To test it, edit src/inter_create.c and uncomment the two lines that start with 'Parrot_cx Then run 'make test' and let me know if it fails any tests that passed before. Thanks, Allison
[perl #48312] [TODO] add get_fd method to ParrotIO
On Fri Dec 07 05:10:15 2007, coke wrote:
From PDD22:
Cgetfd retrieves the UNIX integer file descriptor of a stream object.
The opcode has been replaced by a 'get_fd' method on the ParrotIO
object.
--
This ticket is to track the creation of the get_fd method.
Also from PDD22:
=item Cget_fd
$I0 = $P1.get_fd()
For stream objects that are simple wrappers around a Unix filehandle,
Cget_fd retrieves the Unix integer file descriptor of the object.
This method doesn't exist on stream objects that aren't Unix
filehandles, so check Cdoes for the appropriate role, or Ccan for
the method before calling it.
No asynchronous version.
{{ NOTE: use a config probe (behind Cdoes or Ccan) to determine
support }}
[svn:parrot-pdd] r23568 - in trunk: . docs/pdds
Author: coke
Date: Fri Dec 7 05:15:47 2007
New Revision: 23568
Modified:
trunk/docs/pdds/pdd22_io.pod
Changes in other areas also in this revision:
Modified:
trunk/DEPRECATED.pod
Log:
[docs] Open two tickets to track the deprecation of one item and the feature
that is replacing it
Modified: trunk/docs/pdds/pdd22_io.pod
==
--- trunk/docs/pdds/pdd22_io.pod(original)
+++ trunk/docs/pdds/pdd22_io.podFri Dec 7 05:15:47 2007
@@ -257,7 +257,7 @@
the existing data in the buffer, a size change is non-disruptive, but if
the new size is smaller, it will truncate the buffer with a warning.
-=item Cget_fd
+=item Cget_fd [RT #48312]
$I0 = $P1.get_fd()
@@ -271,6 +271,7 @@
{{ NOTE: use a config probe (behind Cdoes or Ccan) to determine support }}
+
=back
=head2 Status Object PMC API
@@ -584,7 +585,7 @@
Cgetfd retrieves the UNIX integer file descriptor of a stream object.
The opcode has been replaced by a 'get_fd' method on the ParrotIO
-object.
+object. See RT #48310.
=item *
[perl #48310] [DEPRECATED] getfd opcode
# New Ticket Created by Will Coleda # Please include the string: [perl #48310] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=48310 From PDD22: Cgetfd retrieves the UNIX integer file descriptor of a stream object. The opcode has been replaced by a 'get_fd' method on the ParrotIO object. -- This ticket is to track the deprecation of the opcode.
[perl #48312] [TODO] add get_fd method to ParrotIO
# New Ticket Created by Will Coleda # Please include the string: [perl #48312] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=48312 From PDD22: Cgetfd retrieves the UNIX integer file descriptor of a stream object. The opcode has been replaced by a 'get_fd' method on the ParrotIO object. -- This ticket is to track the creation of the get_fd method.
[svn:parrot-pdd] r23567 - trunk/docs/pdds
Author: coke Date: Fri Dec 7 05:05:56 2007 New Revision: 23567 Modified: trunk/docs/pdds/pdd22_io.pod Log: [docs] Remove reference to will-be-deprecated opcode from pdd which was apparently already removed. Modified: trunk/docs/pdds/pdd22_io.pod == --- trunk/docs/pdds/pdd22_io.pod(original) +++ trunk/docs/pdds/pdd22_io.podFri Dec 7 05:05:56 2007 @@ -582,12 +582,6 @@ =item * -Cwrite prints to standard output but it cannot select another stream. -It only accepts a PMC value to write. This is redundant with the -Cprint opcode, so it will be deprecated. - -=item * - Cgetfd retrieves the UNIX integer file descriptor of a stream object. The opcode has been replaced by a 'get_fd' method on the ParrotIO object.
[perl #48320] [BUG] Example in pdd23 doesn't work
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #48320]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=48320
At the bottom of pdd23 there's an example of creating
and throwing an exception that doesn't work. I suspect
it may just be a case of the documentation being out of date
or things not catching up to the object model, but I'm filing
it as a 'bug' for the moment since the implementation doesn't
match an approved spec.
The code reads:
$P0 = new String
$P0 = something bad happened
$P1 = new ['parrot';'exception'], $P0 # create new exception object
throw $P1 # throw it
Running this (and converting String to 'String') results in:
$ cat x.pir
.sub main
$P0 = new 'String'
$P0 = something bad happened
$P1 = new ['parrot';'exception'], $P0
throw $P1
.end
$ ./parrot x.pir
error:imcc:syntax error, unexpected COMMA, expecting '\n' (',')
in file 'x.pir' line 4
$
More generally, it might be good to re-review the exceptions pdd
in light of recent changes to the object model and the availability
of PCCMETHODs for various capabilities.
Pm
Re: Platform testing for concurrency scheduler runloop
On Dec 7, 2007 5:23 AM, Allison Randal [EMAIL PROTECTED] wrote: I'm about to turn on the concurrency scheduler runloop in Parrot trunk. Before I do, I'd like test results on as many platforms as possible (especially Windows, since it doesn't use POSIX threads). To test it, edit src/inter_create.c and uncomment the two lines that start with 'Parrot_cx Then run 'make test' and let me know if it fails any tests that passed before. looks good to me. commit away! nice work. ~jerry
Re: [perl #47970] [BUG] json test fails with --gc-debug when Parrot built with ccache
On Nov 29, 2007, at 10:13 PM, Patrick R. Michaud wrote: Also, in case it matters, I'm on x86 (32-bit) for this. Pm Does it still occur after `ccache -C`? Since ccache uses md5, there's always the possibility you inadvertently discovered a collision in md5. Might want to back up ~/.ccache for posterity's stake.
Re: [perl #48226] [Patch] Option 'exec' for Parrot::Test::Harness
On Friday 07 December 2007 18:09:57 Joshua Juran wrote:
On Dec 5, 2007, at 5:57 PM, chromatic wrote:
Everything looks reasonable to me, except q{} versus q{ } which are
barely discernable and offers (to my mind) only disadvantages over ''
versus ' ' which is much more distinguishable.
Would vs. be a further improvement?
Not to me. If that were in the file, I'd probably forget all about this
discussion at some point in the future then :s//'/g on that line because
there's no interpolation.
-- c
Re: Platform testing for concurrency scheduler runloop
On Friday 07 December 2007 05:23:39 Allison Randal wrote: I'm about to turn on the concurrency scheduler runloop in Parrot trunk. Before I do, I'd like test results on as many platforms as possible (especially Windows, since it doesn't use POSIX threads). To test it, edit src/inter_create.c and uncomment the two lines that start with 'Parrot_cx Then run 'make test' and let me know if it fails any tests that passed before. On Ubuntu 7.10: t/src/vtables..1/4 # Failed test (t/src/vtables.t at line 142) # Exited with error code: [SIGNAL 139] # Received: # # Expected: # ok # ok # ok $ gcc -o v4 -Iinclude -Lblib/lib/ -lparrot t/src/vtables_4.c $ LD_LIBRARY_PATH=blib/lib gdb ./v4 ok ok ok Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1213491008 (LWP 8173)] 0xb7c6ee43 in pmc_new (interp=0x804a008, base_type=79) at src/pmc.c:70 70 PMC *const classobj = interp-vtables[base_type]-pmc_class; (gdb) p base_type $1 = 79 (gdb) bt #0 0xb7c6ee43 in pmc_new (interp=0x804a008, base_type=79) at src/pmc.c:70 #1 0xb7c70372 in Parrot_cx_runloop_end (interp=0x804a008) at src/scheduler.c:230 #2 0xb7c3f113 in Parrot_really_destroy (interp=0x804a008, exit_code_unused=0, arg_unused=0x0) at src/inter_create.c:380 #3 0xb7c2ed3c in Parrot_exit (interp=0x804a008, status=0) at src/exit.c:94 #4 0x080485d2 in main () PMC #79 is a Task PMC. This didn't go away on a realclean. I even moved ending the runloop to before the full DOD when destroying an interpreter, but to no effect. -- c
Re: Platform testing for concurrency scheduler runloop
Andy Dougherty wrote: Whether this is a defect in the vtables_4 test sourcefile for failing to initialize the vtables, or whether pmc_new ought to be more defensive, I can't say. Looks like a bug in the test, as there are other things in Parrot_exit that won't behave appropriately without an initialized vtable. PTC, this is a new test file you added a few days ago. Do you have some more details on what the 4th test is testing? Allison
Re: Platform testing for concurrency scheduler runloop
On Fri, 7 Dec 2007, Allison Randal wrote:
I'm about to turn on the concurrency scheduler runloop in Parrot trunk. Before
I do, I'd like test results on as many platforms as possible (especially
Windows, since it doesn't use POSIX threads).
To test it, edit src/inter_create.c and uncomment the two lines that start
with 'Parrot_cx Then run 'make test' and let me know if it fails any
tests that passed before.
On Solaris 8/SPARC, the only regression is in src/vtables.t
$ perl5.10 -Ilib t/src/vtables.t
1..4
ok 1 - Parrot_new_vtable
ok 2 - Parrot_clone_vtable
not ok 3 - Parrot_destroy_vtable # TODO vtable not NULL after destroy
# Failed (TODO) test (t/src/vtables.t at line 100)
# got: 'ok
# not ok
# '
# expected: 'ok
# ok
# '
# './t/src/vtables_3' failed with exit code 0
not ok 4 - parrot_alloc_vtables
# Failed test (t/src/vtables.t at line 142)
# Exited with error code: [SIGNAL 139]
# Received:
#
# Expected:
# ok
# ok
# ok
#
# Looks like you failed 1 test of 4.
Under the debugger, here's what I see
$ dbx vtables_4
(dbx) run
Running: vtables_4
(process id 3750)
ok
ok
ok
[EMAIL PROTECTED] ([EMAIL PROTECTED]) signal SEGV (no mapping at the fault
address) in pmc_new at line 70 in file pmc.c
70 PMC *const classobj = interp-vtables[base_type]-pmc_class;
(dbx) where
current thread: [EMAIL PROTECTED]
=[1] pmc_new(interp = 0x485318, base_type = 79), line 70 in pmc.c
[2] Parrot_cx_runloop_end(interp = 0x485318), line 232 in scheduler.c
[3] Parrot_really_destroy(interp = 0x485318, exit_code_unused = 0,
arg_unused = (nil)), line 380 in inter_create.c
[4] Parrot_exit(interp = 0x485318, status = 0), line 94 in exit.c
[5] main(argc = 1, argv = 0xffbefa8c), line 33 in vtables_4.c
(dbx) print *interp
*interp = {
ctx = {
state = 0x486580
bp= {
regs_n = 0x4866e0
regs_i = 0x4866e0
}
bp_ps = {
regs_p = 0x4867e0
regs_s = 0x4867e0
}
}
ctx_mem = {
free_list= 0x486430
n_free_slots = 81
}
arena_base= 0x487078
class_hash= 0x4eb110
vtables = 0x67e0a0
n_vtable_max = 81
n_vtable_alloced = 100
[ etc. ]
}
(dbx) print *interp-vtables
*interp-vtables = (nil)
The problem may well be in the vtables_4.c test file and not in pmc_new:
#include parrot/parrot.h
#include parrot/embed.h
#include parrot/vtables.h
int
main(int argc, char* argv[])
{
Interp *interp;
VTABLE *vtable;
interp = Parrot_new(NULL);
if (!interp) {
return 1;
}
parrot_alloc_vtables(interp);
[ . . . ]
In parrot_alloc_vtables, space is allocated for the vtables, but
it is all zeroed. It doesn't point anywhere useful. Thus when
Parrot_cx_runloop_end() calls pmc_new(), and it does:
PMC *const classobj = interp-vtables[base_type]-pmc_class;
things go boom.
Whether this is a defect in the vtables_4 test sourcefile for failing to
initialize the vtables, or whether pmc_new ought to be more defensive, I
can't say.
--
Andy Dougherty [EMAIL PROTECTED]
[svn:parrot-pdd] r23575 - trunk/docs/pdds
Author: pmichaud
Date: Fri Dec 7 11:10:06 2007
New Revision: 23575
Modified:
trunk/docs/pdds/pdd23_exceptions.pod
Log:
[docs]:
* Note non-working code in pdd23, reference RT#48320.
Modified: trunk/docs/pdds/pdd23_exceptions.pod
==
--- trunk/docs/pdds/pdd23_exceptions.pod(original)
+++ trunk/docs/pdds/pdd23_exceptions.podFri Dec 7 11:10:06 2007
@@ -410,11 +410,13 @@
exception. Other exceptions at the run-loop level are also generally
resumable.
- $P0 = new String
+ $P0 = new 'String'
$P0 = something bad happened
$P1 = new ['parrot';'exception'], $P0 # create new exception object
throw $P1 # throw it
+{{ The above example doesn't work in r23568 -- see RT#48320. }}
+
=head1 ATTACHMENTS
None.
Re: [perl #48226] [Patch] Option 'exec' for Parrot::Test::Harness
On Dec 5, 2007, at 5:57 PM, chromatic wrote:
Everything looks reasonable to me, except q{} versus q{ } which are
barely
discernable and offers (to my mind) only disadvantages over ''
versus ' '
which is much more distinguishable.
Would vs. be a further improvement?
Josh
Re: Platform testing for concurrency scheduler runloop
jerry gay wrote: looks good to me. commit away! nice work. I've got a clean report on our core platform targets, so committed in r23574. As usual, please report any issues. Thanks! Allison
Re: Platform testing for concurrency scheduler runloop
On Fri, Dec 07, 2007 at 08:45:03PM +0200, Allison Randal wrote: jerry gay wrote: looks good to me. commit away! nice work. I've got a clean report on our core platform targets, so committed in r23574. As usual, please report any issues. r23574 gives me failures in t/src/vtables.t and t/compilers/pge/perl6regex/context.t: Test Summary Report --- t/configure/115-auto_warnings.t(Wstat: 0 Tests: 4 Failed: 0) TODO passed: 4 t/configure/124-auto_alignptrs-05.t(Wstat: 0 Tests: 21 Failed: 0) TODO passed: 20 t/configure/146-auto_snprintf-01.t (Wstat: 0 Tests: 31 Failed: 0) TODO passed: 30 t/compilers/pge/perl6regex/context.t (Wstat: 256 Tests: 20 Failed: 1) Failed test number(s): 6 Non-zero exit status: 1 t/src/intlist.t(Wstat: 0 Tests: 4 Failed: 0) TODO passed: 1-4 t/src/io.t (Wstat: 0 Tests: 20 Failed: 0) TODO passed: 16-17, 19 t/src/vtables.t(Wstat: 256 Tests: 4 Failed: 1) Failed test number(s): 4 Non-zero exit status: 1 Files=475, Tests=9741, 405 wallclock secs ( 2.87 usr 0.71 sys + 186.81 cusr 50.72 csys = 241.11 CPU) Result: FAIL Failed 2/475 test programs. 2/9741 subtests failed. make: *** [test] Error 255 $ Running prove -v t/src/vtables.t gives: $ prove -v t/src/vtables.t t/src/vtables.. 1..4 ok 1 - Parrot_new_vtable ok 2 - Parrot_clone_vtable not ok 3 - Parrot_destroy_vtable # TODO vtable not NULL after destroy # Failed (TODO) test (t/src/vtables.t at line 100) # got: 'ok # not ok # ' # expected: 'ok # ok # ' # './t/src/vtables_3' failed with exit code 0 not ok 4 - parrot_alloc_vtables # Failed test (t/src/vtables.t at line 142) # Exited with error code: [SIGNAL 139] # Received: # # Expected: # ok # ok # ok # # Looks like you failed 1 test of 4. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/4 subtests Test Summary Report --- t/src/vtables.t (Wstat: 256 Tests: 4 Failed: 1) Failed test number(s): 4 Non-zero exit status: 1 Files=1, Tests=4, 1 wallclock secs ( 0.01 usr 0.00 sys + 0.95 cusr 0.16 csys = 1.12 CPU) Result: FAIL $ Running prove -v t/compilers/pge/perl6regex/context.t shows all tests passing. Running the harness directly with the --gc-debug flag (as 'make test' normally does) gives: $ perl t/harness --gc-debug t/compilers/pge/perl6regex/*.t t/compilers/pge/perl6regex/01-regex..ok t/compilers/pge/perl6regex/context...1/20 # Failed test (t/compilers/pge/perl6regex/context.t at line 96) # Exited with error code: 139 # Received: # 0 # Segmentation fault (core dumped) # # Expected: # 0 # t/compilers/pge/perl6regex/context...11/20 # Looks like you failed 1 test of 20. t/compilers/pge/perl6regex/context... Dubious, test returned 1 (wstat 256, 0x100) Failed 1/20 subtests Test Summary Report --- t/compilers/pge/perl6regex/context.t (Wstat: 256 Tests: 20 Failed: 1) Failed test number(s): 6 Non-zero exit status: 1 Files=2, Tests=764, 7 wallclock secs ( 0.12 usr 0.00 sys + 7.05 cusr 0.24 csys = 7.41 CPU) Result: FAIL Failed 1/2 test programs. 1/764 subtests failed. $ I don't know if this last failure is related to the ccache/gc-debug failure I wrote about in RT#47970, but it sure looks like it. I do know that the context.t test passes with --gc-debug in r23573 but not in r23574. I'm on Kubuntu 7.10 x86. If I can supply more details, let me know. Pm
