Re: [perl #36258] [RFE] parrotbug should include the SVN revision.
Probably not. I was merely trying to save an RFE I saw in one of leo's mails. If it looks like it's there, feel free to close the ticket. chromatic wrote: On Sun, 2005-06-12 at 07:27 -0700, Will Coleda wrote: BTW: a nice to have: include SVN revision of local copy in bug report. It looks like it's already in the contents of myconfig at the end of the bug report; is there more to do here? -- c
Re: m4 build failure on OS X.
Verified, still borked in r8328 William Coleda wrote: With a fairly recent parrot (8308) oolong:~/research/parrot/languages/m4 coke$ make cc -g -pipe -fno-common -no-cpp-precomp -I/usr/local/include -pipe -fno-common -Wno-long-double -I../../include -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization -falign-functions=16 -Wno-shadow -c src/eval.c c++ -dynamiclib -L/usr/local/lib -flat_namespace -o ../../runtime/parrot/dynext/m4_eval_compiler.dylib eval.o ld: Undefined symbols: _PackFile_Segment_new_seg _Parrot_compreg _Parrot_switch_to_cs _const_string _mem_sys_allocate _pmc_new _string_from_cstring /usr/bin/libtool: internal link edit command failed make: *** [../../runtime/parrot/dynext/m4_eval_compiler.dylib] Error 1
m4 build failure on OS X.
With a fairly recent parrot (8308) oolong:~/research/parrot/languages/m4 coke$ make cc -g -pipe -fno-common -no-cpp-precomp -I/usr/local/include -pipe -fno-common -Wno-long-double -I../../include -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization -falign-functions=16 -Wno-shadow -c src/eval.c c++ -dynamiclib -L/usr/local/lib -flat_namespace -o ../../runtime/parrot/dynext/m4_eval_compiler.dylib eval.o ld: Undefined symbols: _PackFile_Segment_new_seg _Parrot_compreg _Parrot_switch_to_cs _const_string _mem_sys_allocate _pmc_new _string_from_cstring /usr/bin/libtool: internal link edit command failed make: *** [../../runtime/parrot/dynext/m4_eval_compiler.dylib] Error 1
RT, parrot releases
I've: - opened tickets for 0.2.2 and 0.2.3, - moved any child tickets that are children of the tickets for 0.1.3, 0.1.4, 0.2.0 tickets to the 0.2.2 release (nine altogether). - resolved the old release tickets. Chip - Check out https://rt.perl.org/rt3/Ticket/Display.html?id=36256 and obviously feel free to delete any child tickets that you don't think belong on the 0.2.2 release, or add any that you think are a priority. I'm not trying to set policy, just document it. Will "Recording Secretary" Coleda
[perl #32642] Remove Perl* PMCs from parrot's basic PMCs
This ticket was updated to reflect that both scheme and Tcl still used Perl*
pmcs.
Attached is a patch for scheme that removes the Perl* from it.
FYI, the following two tests fail before and after my patch. (Updated
LANGUAGES.STATUS to reflect this.)
Failed Test Stat Wstat Total Fail Failed List of Failed
---
scheme/t/logic/defines.t2 512122 16.67% 9-10
Leaving this for the Scheme mainters to apply.
Regards.
Index: Scheme/Generator.pm
===
--- Scheme/Generator.pm (revision 8308)
+++ Scheme/Generator.pm (working copy)
@@ -192,10 +192,10 @@
if ($from =~ /P/) {
$self->_add_inst ('', 'clone',[$to,$from]);
} elsif ($from =~ /I/) {
- $self->_add_inst ('', 'new',[$to,'.PerlInt']);
+ $self->_add_inst ('', 'new',[$to,'.Integer']);
$self->_add_inst ('', 'set',[$to,$from]);
} elsif ($from =~ /N/) {
- $self->_add_inst ('', 'new',[$to,'.PerlNum']);
+ $self->_add_inst ('', 'new',[$to,'.Float']);
$self->_add_inst ('', 'set',[$to,$from]);
}
}
@@ -209,22 +209,22 @@
if (exists $node->{value}) {
my $value = $node->{value};
if ($value =~ /^[-+]?\d+$/) {
- $self->_add_inst ('', 'new',[$return,'.PerlInt']);
+ $self->_add_inst ('', 'new',[$return,'.Integer']);
$self->_add_inst ('', 'set',[$return,$value]);
}
elsif ($value =~ /^[-+]?((\d+\.\d*)|(\.d+))([eE][-+]?\d+)?$/) {
- $self->_add_inst ('', 'new',[$return,'.PerlNum']);
+ $self->_add_inst ('', 'new',[$return,'.Float']);
$self->_add_inst ('', 'set',[$return,$value]);
}
else { # assume its a symbol
- $self->_add_inst ('', 'new',[$return,'.PerlString']);
+ $self->_add_inst ('', 'new',[$return,'.String']);
$self->_add_inst ('', 'set',[$return,"\"$value\""]);
}
}
elsif (exists $node->{children}) {
my $children = $node->{children};
-$self->_add_inst ('', 'new', [$return,'.PerlUndef']);
+$self->_add_inst ('', 'new', [$return,'.Undef']);
for (reverse @$children) {
if (exists $_->{children}) {
my $arg0 = _get_arg($_, 0);
@@ -314,7 +314,7 @@
# check for empty list
$self->_add_inst('', 'typeof', [$type, $list]);
- $self->_add_inst('', 'eq', [$type,'.PerlUndef',"DONE_$label"]);
+ $self->_add_inst('', 'eq', [$type,'.Undef',"DONE_$label"]);
my $copy = $self->_new_pair;
@@ -328,7 +328,7 @@
$self->_add_inst('', 'set', [$list,$list.'[1]']);
$self->_add_inst('', 'typeof', [$type,$list]);
- $self->_add_inst('', 'eq', [$type,'.PerlUndef',"FINISH_$label"]);
+ $self->_add_inst('', 'eq', [$type,'.Undef',"FINISH_$label"]);
$temp = $self->_new_pair;
$self->_add_inst('', 'set', [$copy.'[1]',$temp]);
@@ -724,7 +724,7 @@
my $temp = $self->_generate(_get_arg($node,1));
$self->_add_inst ('', 'typeof',[$return,$temp]);
- $self->_add_inst ('', 'ne', [$return,'.PerlUndef',"FAIL_$label"]);
+ $self->_add_inst ('', 'ne', [$return,'.Undef',"FAIL_$label"]);
$self->_add_inst ('', 'set', [$return,1]);
$self->_add_inst ('', 'branch', ["DONE_$label"]);
$self->_add_inst ("FAIL_$label", 'set', [$return,0]);
@@ -742,7 +742,7 @@
my $label = $self->_gensym ();
my $return = $self->_save_1 ('P');
- $self->_add_inst ('', 'new',[$return,'.PerlUndef']);
+ $self->_add_inst ('', 'new',[$return,'.Undef']);
my @reverse = reverse _get_args($node);
@@ -774,7 +774,7 @@
$self->_add_inst ('', 'set',[$return,'0']);
my $type = $self->_save_1 ('I');
$self->_add_inst ("NEXT_$label", 'typeof',[$type,$list]);
- $self->_add_inst ('', 'eq',[$type,'.PerlUndef', "DONE_$label"]);
+ $self->_add_inst ('', 'eq',[$type,'.Undef', "DONE_$label"]);
$self->_add_inst ('', 'ne',[$type,'.Array', "ERR_$label"]);
$self->_add_inst ('', 'inc',[$return]);
$self->_add_inst ('', 'set',[$list,$list.'[1]']);
Index: Scheme/Builtins.pm
===
--- Scheme/Builtins.pm (revision 8308)
+++ Scheme/Builtins.pm (working copy)
@@ -10,7 +10,7 @@
write =>
[['# Write function', ''],
['write_ENTRY', 'typeof', 'I0', 'P5'],
- ['', 'ne', 'I0', '.PerlUndef', 'write_N_UNDEF'],
+ ['', 'ne', 'I0', '.Undef', 'write_N_UNDEF'],
['', 'print', '"()"'],
['', 'branch', 'write_RET'],
['write_N_UNDEF','ne', 'I0', '.Scratchpad', 'write_N_LAMBDA'],
@@ -31,7 +31,7 @@
['', 'restore', 'P6'],
['', 'set', 'P5', 'P6[1]'],
['', 'typeof', 'I0', 'P5'],
- ['', 'eq', 'I0', '.PerlUndef', 'write_KET'],
+ ['', 'eq', 'I0', '.Undef', 'write_KET'],
['', 'ne', 'I0', '.Array', 'write_DOT'],
['', 'print', '" "'],
['', 'branch', 'write_NEXT'],
@@ -49,42 +49,42 @@
['','typeof', 'I16', 'P16'],
['',
None vs. Undef vs. Null
open currently returns an Undef PMC if it fails to open a file. Should it instead return a None? Or, IMO, a Null? Someone should probably do a cleanup in the core on None vs. Undef vs. Null to insure they are used consistently and appropriately. FWIW, it also seems unfair (or at least, unobvious) that there is are C and C opcodes, but no corresponding codes for Undef or None.
PGE, s/ub/st/
Is it possible to do substitutions with PGE yet? If so, how?
Re: Parrot bc?
From languages/LANGUAGES.STATUS: N: bc A: Bernhard Schmalhofer D: Needs antlr and Python S: Not working and not yet in Parrot SVN M: Yes V: 0.1.2 Ron Blaschke wrote: I'm feeling rather dumb asking this, but F says: Currently GNU bc is only used for doublechecking Parrot bc. Now, my question is: Where is "Parrot bc?" Ron
Re: [perl #31178] [TODO] IO - off with its head! er, opcodes!
Note: Any tickets which list "will-parrotodo ..." as the requestor don't need to have replies sent back to the requester - they are placeholders generated from now long gone TODO files. Followup probably should go to the list, though. And, "chip claimed a ticket???!?" * gets the vapors. Chip Salzenberg via RT wrote: IO doesn't belong as opcodes. Design a standard IO library ... base it on something sane that already exists ... and get all those IO functions the heck out of our opcode space.
PGE, namespace'd rules.
Looking through the PGE test examples, it *looks* like subrules are just globals. (so, if I refer to in a rule, there should be a Match object in a global named "frob") e.g., from the PIR code generated for the phone test: name = "digits" subpat = "\\d+" rulesub = p6rule_compile(subpat) store_global name, rulesub name = "exch" subpat = "\\(\\)" rulesub = p6rule_compile(subpat) store_global name, rulesub name = "_MASTER" subpat = ":w -" rulesub = p6rule_compile(subpat) match = rulesub(target) What if I want to use a namespace other than the root one, to avoid collision with other rules? (I mean, I can store the rule in any global I want, but how do I refer to the rule later on?) (especially for library modules, or your compiler infrastructure, where you don't want to trounce a pre-existing rule in the caller or the generated code) Further, how does this interact with other globals in the same namespace? What if I have a Tcl global called "digits"? Regards?
Bus error during IMC compilation
Making some modifications to the tcl PIR, I just got the following error: (cd ../../ && ./parrot --output=languages/tcl/lib/tcllib.pbc languages/tcl/lib/tcllib.imc) make: *** [lib/tcllib.pbc] Error 138 running through gdb, I see: (gdb) run languages/tcl/lib/tcllib.imc Starting program: /Users/coke/research/parrot/parrot languages/tcl/lib/tcllib.imc Reading symbols for shared libraries . done Reading symbols for shared libraries . done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x0097 0x9000423c in szone_malloc () (gdb) bt #0 0x9000423c in szone_malloc () #1 0x90003a5c in malloc_zone_malloc () #2 0x900039c0 in malloc () #3 0x000fb51c in imcstack_new () at imcc/stacks.c:10 #4 0x000316d0 in imc_reg_alloc (interpreter=0xd00180, unit=0xd831d0) at imcc/reg_alloc.c:144 #5 0x00018b90 in imc_compile_unit (interp=0xd00180, unit=0xd831d0) at imcc/imc.c:72 #6 0x00018ddc in imc_close_unit (interp=0xd00180, unit=0xd831d0) at imcc/imc.c:140 #7 0x0001e8c0 in yyparse (interp=0xd00180) at imcc/imcc.y:416 #8 0x4058 in main (argc=1, argv=0xbae8) at imcc/main.c:571 oolong:~/research/parrot coke$ uname -a Darwin oolong 8.1.0 Darwin Kernel Version 8.1.0: Tue May 10 18:16:08 PDT 2005; root:xnu-792.1.5.obj~4/RELEASE_PPC Power Macintosh powerpc
Re: [svn:parrot] rev 8287 - in trunk/languages/tcl: . lib lib/commands t
With this patch, Tcl is now failing the same two tests for me that it's been failing for leo: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/cmd_break.t 1 256 21 50.00% 2 t/cmd_continue.t1 256 21 50.00% 2 Failed 2/39 test scripts, 94.87% okay. 2/238 subtests failed, 99.16% okay. Now that they're out in the open, as it were, I might be able to fix them. So, failing tests: bad; Patch: good. [EMAIL PROTECTED] wrote: Author: coke Date: Tue Jun 7 17:16:15 2005 New Revision: 8287 Modified: trunk/languages/tcl/TODO trunk/languages/tcl/lib/commands/append.imc trunk/languages/tcl/lib/commands/array.imc trunk/languages/tcl/lib/commands/catch.imc trunk/languages/tcl/lib/commands/for.imc trunk/languages/tcl/lib/commands/foreach.imc trunk/languages/tcl/lib/commands/global.imc trunk/languages/tcl/lib/commands/incr.imc trunk/languages/tcl/lib/commands/lappend.imc trunk/languages/tcl/lib/commands/namespace.imc trunk/languages/tcl/lib/commands/set.imc trunk/languages/tcl/lib/commands/unset.imc trunk/languages/tcl/lib/commands/upvar.imc trunk/languages/tcl/lib/expression.imc trunk/languages/tcl/lib/get_var.imc trunk/languages/tcl/lib/interpret.imc trunk/languages/tcl/lib/tclword.imc trunk/languages/tcl/t/cmd_catch.t trunk/languages/tcl/t/tcl_pir_compiler.t trunk/languages/tcl/tcl.imc_template Log: Add support for true globals, instead of just faking it. Includes a test for generic parrot interoperability in tcl_pir_compiler.t update some error handlers based on feedback from Leo (that, and the old style seems to break with the other parts of this patch.) Switch lib/get_var.imc to use multisubs for hopefully better dispatch, but definitely cleaner code. now passing strings instead of PMCs to avoid extraneous boxing/unboxing.
Re: r8223 - HLL support 4
Done. Thanks! William Coleda wrote: Cool. This means I don't have to do a lookup everytime I want to use one of my own types (per type per sub). Tcl will be patched shortly to take advantage. Leopold Toetsch wrote: The first steps for HLL language and type support are in. You can now dynamically load a HLL _group PMC library by just including a .HLL line in PASM/PIR, e.g. .HLL "Tcl", "tcl_group" ... $P0 = new .TclInt # Integer constant Note that $P0 = new TclInt also seems to work (no dot) The ".HLL" pragma registers at compile time the given HLL language name within src/hll.c and loads the given library with Parrot_load_lib(). Please note that this does not yet work for .pbc files as the HLL isn't stored in the PBC yet (this will come soon). See also t/dynclass/foo.t for 2 examples. Have fun, leo
Re: r8223 - HLL support 4
Cool. This means I don't have to do a lookup everytime I want to use one of my own types (per type per sub). Tcl will be patched shortly to take advantage. Leopold Toetsch wrote: The first steps for HLL language and type support are in. You can now dynamically load a HLL _group PMC library by just including a .HLL line in PASM/PIR, e.g. .HLL "Tcl", "tcl_group" ... $P0 = new .TclInt # Integer constant Note that $P0 = new TclInt also seems to work (no dot) The ".HLL" pragma registers at compile time the given HLL language name within src/hll.c and loads the given library with Parrot_load_lib(). Please note that this does not yet work for .pbc files as the HLL isn't stored in the PBC yet (this will come soon). See also t/dynclass/foo.t for 2 examples. Have fun, leo
Re: TclLists <-> TclStrings
Yeah, the PIR I showed was a bit of a hack based on current functionality. Thinking about it more, I think we do need to have true morphing between TclLists and TclStrings, especially we get to true language interopability.
This is a problem with the current set of vtables, because while I can extract the string
value from a list using vtables, I don't think there's a vtable for "extract
list".
Now, I can certainly hack things up in Tcl like our combination of examples,
where I call non-standard methods on any PMCs I see to force this conversion.
What I really want is the ability to say:
$S0 = $P0 # get string value of PMC, whatever it is. This is currently doable.
this way I can support either
puts "this is a string"
or
puts [list this is a list]
Without having any special method. Any PMC that gets passed into Tcl."puts"()
can be printed without having to know it's type.
The problem comes with automatically treating things like lists instead of
strings. Because of the current lack of vtable support, creating a method is
the way of doing something like:
set a [list a b c]
lappend a d e f
lappend take the variable "a", treats it like a list, and then adds 3 more
elements. This version works fine, but:
set a "a b c"
lappend a d e f
needs to somehow get the list representation of the named variable. So, of your four methods
listed, I don't need "listToString", because get_string works just fine for that. that
leaves the two "...toList" methods. Which I *can* add, but it means that if anyone wants
to use tcl from the another language, they are going to have support my PMC interface... Isn't
extending the basic interface the best way to acheive this? ( I realize that from the calling
standpoint, a generic METHOD looks like a vtable; but I'd like to use only standard mechanisms for
this, so Tcl isn't balkanized from the rest of the languages)
Regards.
Leopold Toetsch wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
Tcl has a need to be able to convert between Lists and Strings. All of the
morphing samples that are in, say, PerlUndef are for scalars.
Right now, I have a PIR method, "_Tcl::__stringToList" that takes a string,
and then uses the tcl parser to split it up into a list.
What I'd like to do is create a "set_string_native" method on TclList,
While it's certainly doable to morph a list to a string and vv, it's a
bit tedious and it doesn't really match you description above.
I'd just do:
pmclass TclString ... {
METHOD PMC* stringToList() {
// create new list and return it
}
METHOD PMC* listToString() {
return SELF; // already a string
}
}
pmclass TclList ... {
METHOD PMC* listToString() {
// create new string from the list and return it
}
METHOD PMC* stringToList() {
return SELF;
}
}
$P1 = $P0."stringToList"()
leo
Re: State of ParTcl [r8193]
Thanks very much to Matt for his recent checkins, cleaning up tclparser.pmc,
and eliminating a bit of unnecessary code.
The compiler broke after some recent checkins (not Matt's fault). I've added a
test for this which is now passing, which should hopefully *keep* it passing.
=-)
With Matt's recent cleanup to tclparser, I'm now seeing 100% success on the tcl
test suite. Even
env TEST_PROG_ARGS=--gc-debug make test
is working:
All tests successful.
Files=39, Tests=236, 70 wallclock secs (29.83 cusr + 14.04 csys = 43.87 CPU)
I've also added tests for inline (unique to ParTcl), which lets you do:
puts "This is Tcl"
inline PASM {
print "This is PASM\n"
}
as well as some other minor missing tests.
William Coleda wrote:
With Leo's recent fixes to , the following now works:
.sub main @MAIN
load_bytecode "languages/tcl/lib/tcllib.pbc"
.local pmc tcl_compiler,compiled_sub
tcl_compiler = compreg "TCL"
compiled_sub = compile tcl_compiler, "puts {ok 1}"
compiled_sub()
.end
Additionally, at Leo's suggestion, I've just removed quite a bit of
duplicated code from languages/tcl/classes/ - now that multiple
inheritance is working, we can simply inherit these methods. There are
some methods that are still there that I don't think are tcl-specific -
if anyone can do more cleanup here (esp. in tcllist.pmc), I'd appreciate
it.
I currently have one failing test (cmd_continue, test 2) - this is, I
think, the same test that leo had been reporting as failing for a while.
I have some other pending code which seems to be tickling this GC bug.
Hopefully I'll be able to track this down.
Re: [perl #35976] [PATCH] Add Unicode, Hex, and Octal escapes to Tcl
Because this appears to have been written primarily for perl implementors.
It does the following escapes:
1 \xhh1..2 hex digits
2 \ooo1..3 oct digits
3 \cX control char X
4 \x{h..h}1..8 hex digits
5 \u 4 hex digits
6 \U 8 hex digits
7-15 \a, \b, \t, \n, \v, \f, \r, \e, \?
Per:
http://www.tcl.tk/man/tcl8.5/TclCmd/Tcl.htm#M16
does 12 different backslash substitutions. While there is some substantial
overlap, there are escapes I need that this doesn't provide, but worse, escapes
you provide that I don't want.
Regards.
Leopold Toetsch wrote:
Will Coleda (via RT) wrote:
The attached patch provides a (possibly naive) implementation of the
remaining escape characters from:
Withouht further looking: can't you use
src/string.c:string_unescape_cstring(), which has all these escapes
already?
leo
Re: takers wanted: a C job - list.c and arrays
They certainly can. Tickets can have child tickets, or pre-requisite tickets, each of which can have its own takers. The long term planning is the sort of thing that could also go in docs/ROADMAP. Regards. Leopold Toetsch wrote: Yeah. As these are several steps, I'd like to have some takers first, or interest, or ...Except the first item its more a long term plan. I don't know if tickets really track it all. ~jerry leo
State of ParTcl [r8149]
With Leo's recent fixes to , the following now works:
.sub main @MAIN
load_bytecode "languages/tcl/lib/tcllib.pbc"
.local pmc tcl_compiler,compiled_sub
tcl_compiler = compreg "TCL"
compiled_sub = compile tcl_compiler, "puts {ok 1}"
compiled_sub()
.end
Additionally, at Leo's suggestion, I've just removed quite a bit of duplicated
code from languages/tcl/classes/ - now that multiple inheritance is working, we
can simply inherit these methods. There are some methods that are still there
that I don't think are tcl-specific - if anyone can do more cleanup here (esp.
in tcllist.pmc), I'd appreciate it.
I currently have one failing test (cmd_continue, test 2) - this is, I think,
the same test that leo had been reporting as failing for a while. I have some
other pending code which seems to be tickling this GC bug. Hopefully I'll be
able to track this down.
Re: [svn:parrot] rev 7965 - in trunk: . config/gen/makefiles languages/m4/src
If someone wanted to convert languages/tcl in such a fashion, that would be cool. [EMAIL PROTECTED] wrote: Author: bernhard Date: Tue May 3 14:32:31 2005 New Revision: 7965 Added: trunk/languages/m4/src/builtin.pir - copied, changed from rev 7963, trunk/languages/m4/src/builtin.imc trunk/languages/m4/src/freeze.pir - copied, changed from rev 7963, trunk/languages/m4/src/freeze.imc ...
State of ParTcl [r7928]
The garbage collection issues that were stopping ParTcl's test suite (FYI, *not* Tcl's test suite) from working seem to be gone now! I've gotten passing reports on all tests (that aren't TODO'd) from OS X, FreeBSD, and Linux. ParTcl is part of the parrot svn repository. See: http://www.parrotcode.org/source.html Once you've downloaded parrot, follow the instructions in ./README to build parrot itself, and then in ./languages/tcl/README to build and test Tcl. Any feedback is, of course, greatly appreciated. Now that these pesky GC bugs are (hopefully) dealt with, back to actually implementing features. As usual, volunteers welcome. Regards.
Re: [perl #34999] [TODO] remove more old stuff
Matt Diephouse wrote: Leopold Toetsch wrote: classes/pmcarray.pmc wrapper for PerlArray I'm not sure what was discussed here. I believe this is a remnant from before it was decided that we'd use "Resizable" and "Fixed" for container types; Anything that's using PMCArray should be switched to ResizablePMCArray (or FixedPMCArray if that's all it needs) (or, if that fails due to an unimplemented feature, to PerlArray, with a TODO to add the appropriate functionality to ResizablePMCArray) Regards.
Re: [perl #32646] [TODO] Convert Perl* PMCs to dynamic classes.
Per Leo, this is unnecessary, as Perl will be one of the magic dynamic pmcs that will sneakily load the dynamic library for you if you have yet to do so. Bernhard Schmalhofer via RT wrote: [coke - Fr 26. Nov 2004, 16:21:31]: Like all other language specific PMCs, Perl PMCs should only be loaded at runtime if necessary. When the Perl PMCs are dynamic, then the tests need to look up the type dynamically. As this also works for static types, the tests can be prepared for that in advance. See also the diffs between the SVN revisions 7896 and 7897
Re: State of the Tcl [r7896]
Leopold Toetsch wrote: William Coleda <[EMAIL PROTECTED]> wrote: Still some GC bugs kicking around that neither Leo nor I have been able to find yet. (Note that the bug in [string] may actually be a PGE leak, as that code uses the glob rules). Well there are GC and other bugs, probably. I get really strange results when running the tcl tests: $ make test Failed Test Stat Wstat Total Fail Failed List of Failed --- t/cmd_continue.t1 256 21 50.00% 2 *but* I see much more failing: some of cmd_concat, cmd_insert, cmd_proc, and cmd_string, which aren't shown in the summary. These are probably the TODO tests - you still get the failure output when they run, but they don't count against the total. Turning off DOD/GC gives this result: $ TEST_PROG_ARGS=-G make test All tests successful. Files=36, Tests=228, 43 wallclock secs (35.93 cusr + 6.15 csys = 42.08 CPU) again with above failing tests unnoticed. Running with -G didn't flush output w/o newlines properly, which is fixed now. Thanks Some more remarks: lib/tclword.imc: .local pmc me me = interpinfo 16 #INTERPINFO_CURRENT_OBJECT setattribute me, "TclWord\x00chunks", emptyArray this is extremly prone to errors. We don't guarantee that the constant 16 stays the current object. Just use C here, which does the same: setattribute self, "TclWord\x00chunks", emptyArray Heh. I had done this before, and, as today, it didn't work. self wasn't recognized as a variable: __init was not declared as a method. Fixed. tcl.imc: $P2 = parser."parse"(input_line_PMC,zero,zero) (retcode,retval) = interpret($P1) $P1 / $P2 seems to be a typo, which happens to work as it's likely that the register allocator will use the same register. Good catch, thank you. That'd've been easier to see if it failed. ^_^ Also, I see you found a bug in my fix to dynclasses/tclstring.pmc - I forgot to actually mark the strings. Sadly, with all these updates, no changes in test status. (Even with your other GC fix for lisp).
Re: [svn:parrot] rev 7886 - in trunk: . config/gen/makefiles dynclasses languages/tcl/lib/commands languages/tcl/lib/macros
Ah. That would explain why I had to back in and delete the file that I had already deleted - because I deleted the wrong file! Fixed. Leopold Toetsch wrote: [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: --- trunk/MANIFEST (original) +++ trunk/MANIFEST Tue Apr 19 16:51:10 2005 @@ -50,7 +50,6 @@ -classes/boolean.pmc [] I don't understand this change to MANIFEST. classes/boolean.pmc is for sure used, but $ perl tools/dev/manicheck.pl doesn't complain at all. leo
State of the Tcl [r7890]
Still some GC bugs kicking around that neither Leo nor I have been able to find yet. (Note that the bug in [string] may actually be a PGE leak, as that code uses the glob rules). Failed TestStat Wstat Total Fail Failed List of Failed --- t/cmd_global.t3 768 33 100.00% 1-3 t/cmd_proc.t 3 768 53 60.00% 1-3 t/cmd_rename.t2 512 22 100.00% 1-2 t/cmd_return.t1 256 11 100.00% 1 t/cmd_string.t1 256351 2.86% 27 Recent commits: 1) eliminate a .boolean macro for truth checking, and use the appropriate override in TclString; and 2) fix another (apparently only potential) GC bug in TclString; and 3) add a "make tclsh" target to both tcl/ and tcl/examples - this will run the interactive version of tcl. (a stripped down version at the moment, of course).
RT Cleanup
There are some potentially crufty tickets out there. Can the relevant experts verify if these can be closed before we get the next release out? Win32: (10 tickets) http://rt.perl.org/rt3/NoAuth/parrot/List.html?Field=Platform&Value=mswin32 http://rt.perl.org/rt3/NoAuth/parrot/List.html?Field=Platform&Value=Win32 Cygwin: (3 tickets) http://rt.perl.org/rt3/NoAuth/parrot/List.html?Field=Platform&Value=cygwin Linux: (one sparc, one fedora) http://rt.perl.org/rt3/NoAuth/parrot/List.html?Field=Platform&Value=Linux Freebsd: (2 tickets) http://rt.perl.org/rt3/NoAuth/parrot/List.html?Field=Platform&Value=freebsd Mac OS X: (1 ticket) http://rt.perl.org/rt3/Ticket/Display.html?id=24177 ICU: (3 tickets) http://rt.perl.org/rt3/Ticket/Display.html?id=28405 http://rt.perl.org/rt3/Ticket/Display.html?id=28473 https://rt.perl.org/rt3//Ticket/Display.html?id=30847
Re: State of the Tcl [r7876]
More updates: 1) changed the tclparser PMC to emit actual real_exceptions in several cases; and 2) Added a divide method to TclInt to override the default Integer behavior of promotion to float (This is necesssary because Tcl's floats stringify with ".0", always - so while [expr 6.0 / 2] is "3.0", [expr 6 / 2] is "3"); and 3) Fixed a stupid mistake involving [linsert]/[lindex]. Apologies. ... Down to the following failures: Failed TestStat Wstat Total Fail Failed List of Failed --- t/cmd_global.t3 768 33 100.00% 1-3 t/cmd_proc.t 3 768 53 60.00% 1-3 t/cmd_return.t1 256 11 100.00% 1 t/cmd_string.t1 256351 2.86% 27 Failed 4/36 test scripts, 88.89% okay. 8/228 subtests failed, 96.49% okay. Again, if you're seeing anything other than this failing, please open an RT ticket. Thanks. William Coleda wrote: Ok. I was somewhat surprised to hear about the Tcl breakages recently. I expect that Tcl is going to work on all of Parrot's supported OSen. Here are some recent improvements. o fixed the most gratuitous GC errors that Leo diagnosed. o committed a patch so that PGE is built by default (per chip). This simplifies the Tcl build process. o add "--gc-error" to the default test build for Tcl. That leaves the following test failures: Failed Test Stat Wstat Total Fail Failed List of Failed --- cmd_expr.t 1 256401 2.50% 2 cmd_global.t 3 768 33 100.00% 1-3 cmd_join.t 6 1536 76 85.71% 2-7 cmd_linsert.t 4 1024 54 80.00% 1 3-5 cmd_llength.t 5 1280 55 100.00% 1-5 cmd_proc.t 3 768 53 60.00% 1-3 cmd_rename.t 2 512 22 100.00% 1-2 cmd_return.t 1 256 11 100.00% 1 cmd_string.t 1 256351 2.86% 27 tcl_command_subst.t1 256 81 12.50% 8 The [expr] failure is a result of recent MMD changes, I think. Many of the other failures seem to be more GC issues. Help tracking these down is appreciated. If anyone is seeing any test failures for Tcl that are NOT on this list, please open an RT ticket. (see: languages/tcl/README) Regards.
State of the Tcl [r7870]
Ok. I was somewhat surprised to hear about the Tcl breakages recently. I expect that Tcl is going to work on all of Parrot's supported OSen. Here are some recent improvements. o fixed the most gratuitous GC errors that Leo diagnosed. o committed a patch so that PGE is built by default (per chip). This simplifies the Tcl build process. o add "--gc-error" to the default test build for Tcl. That leaves the following test failures: Failed Test Stat Wstat Total Fail Failed List of Failed --- cmd_expr.t 1 256401 2.50% 2 cmd_global.t 3 768 33 100.00% 1-3 cmd_join.t 6 1536 76 85.71% 2-7 cmd_linsert.t 4 1024 54 80.00% 1 3-5 cmd_llength.t 5 1280 55 100.00% 1-5 cmd_proc.t 3 768 53 60.00% 1-3 cmd_rename.t 2 512 22 100.00% 1-2 cmd_return.t 1 256 11 100.00% 1 cmd_string.t 1 256351 2.86% 27 tcl_command_subst.t1 256 81 12.50% 8 The [expr] failure is a result of recent MMD changes, I think. Many of the other failures seem to be more GC issues. Help tracking these down is appreciated. If anyone is seeing any test failures for Tcl that are NOT on this list, please open an RT ticket. (see: languages/tcl/README) Regards.
Re: [FYI] enhanced backtraces
Cool. Can I co-opt this so I can get tcl-like backtraces when running tcl code? If so, how? =-) Jens Rieks wrote: Hi, the new backtrace code is in. If a parrot program aborts due to an error, a backtrace is shown. Examples: Null PMC access in invoke() current instr.: 'd' pc 149 (t/op/debuginfo_4.imc:24) called from Sub 'c' pc 116 (t/op/debuginfo_4.imc:18) called from Sub 'b' pc 85 (t/op/debuginfo_4.imc:13) called from Sub 'a' pc 54 (t/op/debuginfo_4.imc:8) called from Sub 'main' pc 23 (t/op/debuginfo_4.imc:3) Null PMC access in invoke() current instr.: 'rec' pc 111 (t/op/debuginfo_8.imc:12) called from Sub 'rec' pc 71 (t/op/debuginfo_8.imc:8) ... call repeated 90 times called from Sub 'main' pc 24 (t/op/debuginfo_8.imc:2) maximum recursion depth exceeded current instr.: 'main' pc 21 (t/op/debuginfo_7.imc:2) called from Sub 'main' pc 21 (t/op/debuginfo_7.imc:2) ... call repeated 999 times Lexical 'nosuchlex' not found current instr.: 'Test2 :: foo' pc 35 (t/op/debuginfo_6.imc:10) called from Sub 'Test2 :: main' pc 25 (t/op/debuginfo_6.imc:5) If you use "debug 1", a backtrace is shown even for exceptions cought with an exception handler. jens PS: filenames are still wrong for included files, because only one filename is stored per bytecode segment (AFAIK). Cf. src/sub.c:615ff
Re: [perl #35018] [PATCH] Recent ASCII changes, Tcl Breakage
Leopold Toetsch wrote: Will Coleda <[EMAIL PROTECTED]> wrote: The recent conversion to mostly defaulting to ascii has broken Tcl (*again*). ./parrot languages/tcl/tcl.pbc languages/tcl/examples/hello.tcl No, I don't think so. $ ./parrot languages/tcl/tcl.pbc languages/tcl/examples/hello.tcl Hello World $ ./parrot -G languages/tcl/tcl.pbc languages/tcl/examples/hello.tcl Hello World $ ./parrot --gc-debug languages/tcl/tcl.pbc languages/tcl/examples/hello.tcl parrot: encodings/fixed_8.c:190: fixed8_set_position: \ Assertion `pos < (iter->str)->obj.u._b._buflen' failed. Aborted I've already described the problem, but you might have missed it. So here it is again: In dynclasses/tclparser.pmc:class_init() you are creating strings like C, which are static globals in this file. These strings are not anchored on the stack nor registered with the Parrot DOD registry. All this strings created here vanish after the first DOD run. To fix it please try: - create an FixedStringArray with the size of the amount of strings - stuff all the strings into the array - C this array HTH, leo Two things: 1) Leo's suggestion fixes most of the issues I had with svn-current. 2) Bah! This code worked in my sandbox for quite some time. Adding "--gc-debug" to the tcl test suite to avoid introducing more gc-related bugs in the future.
Re: [RFC] .local, .syn, etc.
Matt Diephouse wrote: William Coleda <[EMAIL PROTECTED]> wrote: 6) avoid using ".local" to mean something different based on context (macro or not) I'm not sure what you mean. .local inside a macro is actually a label, not a variable. From the imcc docs: --- Macros support labels, defined using B<.local>, that are local to a given macro expansion. The syntax looks something like this: .macro SpinForever (Count) .local $LOOP: dec .COUNT# ".local $LOOP" defines a local label. branch .$LOOP # Jump to said label. .endm ---
[RFC] .local, .syn, etc.
Currently, the following syntax is allowed, and used in examples and code throughout the repository: .local String foo foo = new String .sym String bar bar = new String But... this isn't actually enforced. You can do: .local String foo foo = new Blorp Basically, anything that isn't one of the basic types is interpreted as "pmc". After a discussion on #parrot, there are a few options that came up. This is a grab bag, and hopefully a basis for discussion: 1) make .local String foo (and .sym) equivalent to: .local pmc foo foo = new String 2) make .local String foo (and .syn) a compile time error: just allow "pmc". [1] 3) Allow an initializer as part of the declaration: .local string foo = ascii:"foo" which would be equivalent to .local string foo foo = ascii:"foo" 4) Have .sym and .local take on different possible syntaxes. 5) eliminate one of .sym or .local 6) avoid using ".local" to mean something different based on context (macro or not) 7) Add ".lexical" No firm syntax was discussed for this, but something like: .lexical pmc foo # with optional quotes for hard-to-parse variable names would be equivalent to todays: .local pmc foo foo = find_lex -1, "foo" And give the ability to provide something other than the default "-1" there. 8) add ".global"... Similar to #7. [1] This discussion arose because I was curious if a patch that implemented #2 (and fixed all the resulting errors) would be accepted.
Re: [PATCH] Dynamic Perl, 2 [t/]
Or, rather, find the attached patch here: https://rt.perl.org/rt3/Ticket/Attachment/110536/75860/dynamic_perl2.patch (whoops) William Coleda wrote: Attached find the second patch in the "make perl dynamic" series. This attacks most of the simplistic cases under t/*. Many instances of PerlUndef and PerlArray are left alone, as they still have no equivalents in some cases. (no, you can't always s/PerlUndef/Undef). Some of the expected code for the tests changes here - Floats and PerlNum's don't stringify the same. Also includes a small change to config/gen/config_pm/config_lib.in More to come...
Dynamic Perl, Part 1 [IMCC]
There are two open tickets about removing the core's dependance on Perl* PMCs,
and instead, making them dynamically loadable and using the language agnostic
PMCs for internal use.
Talking about this with Leo on IRC, he expressed an interest in getting these
changes in chunks to make them a little more digestable.
Attached, find the first trivial chunk, which removes as much Perl* from IMCC internals and tests as possible without writing actually writing any new PMC code.
PerlArray is going to be the hardest to pull out, as there is no other
Array-style pmc that does everything it does. (or, at least, I can't find one.
=-)
? foo.pir
? imcc/.pcc.c.swp
? src/asmfun.s
Index: imcc/parser_util.c
===
RCS file: /cvs/public/parrot/imcc/parser_util.c,v
retrieving revision 1.98
diff -b -u -r1.98 parser_util.c
--- imcc/parser_util.c 25 Mar 2005 10:19:55 - 1.98
+++ imcc/parser_util.c 8 Apr 2005 03:26:44 -
@@ -885,7 +885,7 @@
/* OP _p_k_p_k_p_k =>
* set py, p_k
* set pz, p_k
- * new px, .PerlUndef
+ * new px, .Undef
* OP px, py, pz
* set _p_k_px
*/
@@ -944,7 +944,7 @@
}
}
/* make a new undef */
-iNEW(interpreter, unit, preg[0], str_dup("PerlUndef"), NULL, 1);
+iNEW(interpreter, unit, preg[0], str_dup("Undef"), NULL, 1);
/* emit the operand */
INS(interpreter, unit, name, 0, preg, 3, 0, 1);
/* emit the LHS op */
Index: imcc/pcc.c
===
RCS file: /cvs/public/parrot/imcc/pcc.c,v
retrieving revision 1.92
diff -b -u -r1.92 pcc.c
--- imcc/pcc.c 4 Apr 2005 16:03:26 - 1.92
+++ imcc/pcc.c 8 Apr 2005 03:26:47 -
@@ -711,7 +711,7 @@
* inc $I2
* goto next_arg_N
* over_flow_1_N:
- * new P3, .PerlArray
+ * new P3, .PerlPMCArray
* over_flow_N:
* push P3, arg
* next_arg_N:
Index: imcc/t/imcpasm/optc.t
===
RCS file: /cvs/public/parrot/imcc/t/imcpasm/optc.t,v
retrieving revision 1.13
diff -b -u -r1.13 optc.t
--- imcc/t/imcpasm/optc.t 24 Mar 2005 14:08:17 - 1.13
+++ imcc/t/imcpasm/optc.t 8 Apr 2005 03:26:47 -
@@ -16,19 +16,19 @@
pir_2_pasm_like(<<'CODE', <<'OUT', "in P param");
.sub _main
-$P0 = new PerlUndef
+$P0 = new Undef
$P0 = 42
foo($P0)
noop
end
.end
.sub foo prototyped
-.param PerlUndef a
+.param Undef a
print a
.end
CODE
/_main:
- new (P\d+), \d+ # \.PerlUndef
+ new (P\d+), \d+ # \.Undef
set \1, 42
set_p_pc (P\d+), foo
@pcc_sub_call_\d:
@@ -53,8 +53,8 @@
pir_2_pasm_like(<<'CODE', <<'OUT', "in, out P param");
.sub _main
.local Sub sub
-.local PerlUndef x
-x = new PerlUndef
+.local Undef x
+x = new Undef
x = 42
newsub sub, .Sub, _sub
.pcc_begin prototyped
@@ -67,7 +67,7 @@
end
.end
.pcc_sub _sub prototyped
-.param PerlUndef a
+.param Undef a
a = a + 1
.pcc_begin_return
.return a
@@ -76,7 +76,7 @@
CODE
/_main:
set P16, P1
- new P5, \d+ # \.PerlUndef
+ new P5, \d+ # \.Undef
set P5, 42
newsub P0, \d+, _sub
@pcc_sub_call_\d:
@@ -102,11 +102,11 @@
pir_2_pasm_like(<<'CODE', <<'OUT', "in, out P param, P var");
.sub _main
.local Sub sub
-.local PerlUndef x
-x = new PerlUndef
+.local Undef x
+x = new Undef
x = 42
-.local PerlUndef y
-y = new PerlUndef
+.local Undef y
+y = new Undef
y = 10
newsub sub, .Sub, _sub
.pcc_begin prototyped
@@ -120,7 +120,7 @@
end
.end
.pcc_sub _sub prototyped
-.param PerlUndef a
+.param Undef a
a = a + 1
.pcc_begin_return
.return a
@@ -129,9 +129,9 @@
CODE
/_main:
set P16, P1
- new P5, \d+ # \.PerlUndef
+ new P5, \d+ # \.Undef
set P5, 42
- new P16, \d+ # \.PerlUndef
+ new P16, \d+ # \.Undef
set P16, 10
newsub P0, \d+, _sub
@pcc_sub_call_\d+:
@@ -158,22 +158,22 @@
pir_2_pasm_like(<<'CODE', <<'OUT', "in, out different P param");
.sub _main
.local Sub sub
-.local PerlUndef x
-x = new PerlUndef
+.local Undef x
+x = new Undef
x = 42
newsub sub, .Sub, _sub
.pcc_begin prototyped
.arg x
.pcc_call sub
ret:
-.local PerlUndef y
+.local Undef y
.result y
.pcc_end
print y
end
.end
.pcc_sub _sub prototyped
-.param PerlUndef a
+.param Undef a
a = a + 1
.pcc_begin_return
.return a
@@ -182,7 +182,7 @@
CODE
/_main:
set P16, P1
- new P5, \d+ # \.PerlUndef
+ new P5, \d+ # \.Undef
set P5, 42
newsub P0, \d+, _sub
@pcc_sub_call_\d:
@@ -208,15 +208,15 @@
pir_2_pasm_like(<<'CODE', <<'OUT', "in, out different P param, interfer");
.sub _main
.local Sub sub
-.local PerlUndef x
-x = new PerlUndef
+.local Undef x
+x = new Undef
x = 42
newsub sub,
Tcl, unicode...
I've been trying to add unicode support into Tcl... adding the parser support worked fine, so that I was able (in my sandbox) to get: puts \u30b3\u30fc\u30d2\u30fc Working... because puts is just iso-8859-01, and the unicode was just unicode. Once I started trying to do mix and match, I started getting a lot of runtime exceptions. I can't seem to find a combination of implemented methods at the moment that'll let me limp by. There are 30 unimplmented methods in charset/unicode.h (and a few in ascii & binary)- The one that's holding me up right now is: oolong:~/research/parrot coke$ cat foo.pir .sub main @MAIN $S1 = chr 0x30b3 $I1 = index $S1, "a" .end oolong:~/research/parrot coke$ ./parrot foo.pir unimplemented unicode in file 'foo.pir' near line 3 Any help would be greatly appreciated.
Re: other language compiler to parrot?
As far as I know, no one is working on these at the moment. Volunteers welcome, of course. ^_^ [EMAIL PROTECTED] wrote: hi,all have a Php compiler to parrot project? have a ruby compiler to parrot project?
Tcl, unicode, transcoding strings ... almost.
(whoops) I just added octal and hex escapes to my local copy of the Tcl parser. I was working on unicode when I noticed that not all of the transcodes are done yet. This works: $S0 = unicode:"" $S1 = chr 0x30b3 $S0 .= $S1 print $S0 print "\n" This does not: $S0 = ascii:"" $S1 = chr 0x30b3 $S0 .= $S1 It fails with: Cross-type string appending (fixed_8/ascii) (utf8/unicode) unsupported Similarly, the default iso encoding doesn't allow conversion to unicode either. FYI, the charset:"string constant" documentation in imcc doesn't mention "unicode", though unicode appears to be a valid choice. Now, to work around the transcoding issue, I thought I'd just keep all my strings as unicode... but I can't do this, as part of my parsing involves adding single characters based on their value. e.g.: if I have something like puts \11WHEE Then I have to generate a string like this: $S1 = chr $I1 ... and that string defaults to iso, which can't be transcoded to unicode. So, anyone want to implement iso to unicode translation? (it looks like there *is* an implementation for ASCII, but as I noted above, it generates an exception). Regards.
Tcl, unicode, transcoding strings.
I just added octal and hex escapes to my local copy of the Tcl parser. I was working on unicode when I noticed that not all of the transcodes are done yet. This works:
Re: tcl parser.
Leopold Toetsch wrote: William Coleda <[EMAIL PROTECTED]> wrote: When invoking a PIR-defined object from C, what's the proper call? pmc_new ? (Does that handle class_init) ? I don't understand the question. Do you want to instantiate an object? If yes, just do the same as the respective opcodes are doing: I was referring to the class initialization, not the instance initialization. But it's moot, as the __class_init method has a @LOAD on it, so, yes, it's loaded. Sadly, my problem was more mundane. Note to self, if you're going to have several boolean flags for an overloaded method, be sure to pass the flags in in the correct order. Eliminating that bug brings us to 97.4% for languages/tcl. Looks like recent changes have exposed an issue where I was cheating with namespaces, leaving two failures due to a bad signature spec in a method call made by the new PMC parser. Back to 100%, whee!
tcl parser.
The tcl parser (lib/parse.imc) has been removed and migrated to a method in a PMC. (Anyone looking for a C task could go through and cleanup the parse method in tclparser.pmc - it's basically copied directly from the assembler style with many gotos, no loops, etc. If you make changes, just make sure no *more* tests fail in languages/tcl. =-) One error I'm having trouble tracking down is when parsing code like: puts "\n" The quoted string triggers a recursive call to the parser (which appears to succeed). When that parser invocation returns, it takes the results, and passes them into languages/tcl/tclword.imc:concat_words, which then dumps core. Seems to not like the getattribute call on the object that's passed in. When invoking a PIR-defined object from C, what's the proper call? pmc_new ? (Does that handle class_init) ? FYI, There are still a few tests failing in tcl at the moment, but I think most of them are related to this issue.
Re: make test failures
Here's another round with version 1192, OS X; more tests, but more failures, too: Failed Test Stat Wstat Total Fail Failed List of Failed --- t/builtins/goto.t1 256?? ?? % ?? t/builtins/grep.t 186 33.33% 1-6 t/builtins/io/readline_chomped.t 32 66.67% 1-2 t/builtins/list/join.t 269 34.62% 1-3 7-9 19-21 t/builtins/list/reverse.t 306 20.00% 10 12 16 19-20 27 t/builtins/list/zip.t 121 8.33% 10 t/builtins/map.t186 33.33% 1-6 t/builtins/sort.t63 50.00% 2 4 6 t/builtins/strings/uc.t 51 20.00% 5 t/builtins/true.t81 12.50% 8 t/builtins/undef.t 623 4.84% 27 32 36 t/data_types/array.t48 12 25.00% 13-18 34-37 47-48 t/data_types/array_ref.t425 11.90% 35-36 38 41-42 t/data_types/hash.t 538 15.09% 4 20-26 t/data_types/hash_ref.t 497 14.29% 5 19-22 48-49 t/data_types/pair.t 1 25643 18 41.86% 35-43 t/operators/inc.t 264 15.38% 22-25 t/pugsbugs/die_and_end.t 1 256 12 200.00% 1 t/statements/for.t 208 40.00% 3-4 7-8 13-14 17-18 t/statements/if.t 161 6.25% 8 t/statements/loop.t 81 12.50% 8 t/statements/try.t 101 10.00% 1 t/subroutines/currying.t 72 28.57% 6-7 t/subroutines/sub_return_values.t 54 18 33.33% 25-29 35-39 46-51 53-54 Failed 24/118 test scripts, 79.66% okay. 115/2867 subtests failed, 95.99% okay.
make test failures
ghc of 6.2 on OS X 10.3 with pugs svn-latest. Failed Test Stat Wstat Total Fail Failed List of Failed --- t/builtins/goto.t1 256?? ?? % ?? t/builtins/grep.t 186 33.33% 1-6 t/builtins/io/readline_chomped.t 32 66.67% 1-2 t/builtins/list/join.t 269 34.62% 1-3 7-9 19-21 t/builtins/list/reverse.t 306 20.00% 10 12 16 19-20 27 t/builtins/list/zip.t 121 8.33% 10 t/builtins/map.t186 33.33% 1-6 t/builtins/sort.t63 50.00% 2 4 6 t/builtins/strings/uc.t 51 20.00% 5 t/builtins/undef.t 623 4.84% 27 32 36 t/data_types/array.t48 12 25.00% 13-18 34-37 47-48 t/data_types/array_ref.t362 5.56% 35-36 t/data_types/hash.t 538 15.09% 4 20-26 t/data_types/hash_ref.t 405 12.50% 5 19-22 t/operators/inc.t 264 15.38% 22-25 t/pugsbugs/die_and_end.t 1 256 12 200.00% 1 t/pugsbugs/string_escaping.t 11 100.00% 1 t/statements/for.t 208 40.00% 3-4 7-8 13-14 17-18 t/statements/if.t 161 6.25% 8 t/statements/loop.t 81 12.50% 8 t/statements/try.t 101 10.00% 1 t/subroutines/currying.t 72 28.57% 6-7 t/subroutines/sub_return_values.t 54 18 33.33% 25-29 35-39 46-51 53-54 Failed 23/115 test scripts, 80.00% okay. 101/2809 subtests failed, 96.40% okay.
Re: [perl #34430] [PATCH] MRO breaks Tcl
Switching tclobject seems to work fine here. I suspect you might have something else going on. Committed the change to tclobject, removed my local hack to src/pmc.c, passes 100% now. Regards. Leopold Toetsch wrote: Will Coleda <[EMAIL PROTECTED]> wrote: Attached is a patch that allows "(cd languages/tcl && make test)" to work again. Looks like an unguarded access in MRO. Didn't self apply so Leo could poke at it, in case the tcl pmcs are exploiting a hole in pmc2c2.pl. The C is defined as an abstract class, i.e. it has no VTABLE. Per convention, such abstract classes should be lower case. Is there a specific reason that it's an abstract PMC? I tried to get rid of "abstract noinit" in that PMC, which produced these failing tests: cmd_break.t 1 256 21 50.00% 2 cmd_continue.t1 256 21 50.00% 2 cmd_linsert.t 4 1024 54 80.00% 1 3-5 cmd_string.t 6 1536356 17.14% 26-27 29-31 34 leo
Re: Calling PIR from a PMC
Jeff Horwitz wrote: On Mon, 14 Mar 2005, William Coleda wrote: How does one call a PIR-defined sub from C? use the Parrot_call_sub_* API. Ah, thank you, much better. Now, given the perldoc for src/extend.c, "void* Parrot_call_sub(Parrot_INTERP interpreter, Parrot_PMC sub, const char *signature, ...)" Call a parrot subroutine the given function signature. The first char in "signature" denotes the return value. Next chars are argu- ments. The return value of this function can be void or a pointer type. If only the first character is the return value, how does one deal with subroutines that return multiple values?
Calling PIR from a PMC
How does one call a PIR-defined sub from C? My current best guess is, to invoke the PIR sub "Tcl::Joe": PMC *invokeme; STRING *Tcl,*joe; Tcl = string_from_const_cstring(INTERP, "Tcl", 3); joe = string_from_const_cstring(INTERP, "joe", 3); invokeme = Parrot_find_global(INTERP, Tcl, joe); VTABLE_invoke(INTERP,invokeme,); But I don't know what to put as the argument for "next" to VTABLE_invoke - I see some items in dynclasses/*.pmc use the string "next", the code seems to allow for NULL - neither of them seem to actually invoke my method. (a .sub with a single "print" statement) Do I need to be setting up the calling conventions in my calling code? Is there some other step I'm missing? Is this already documented somewhere?
Re: [perl #34356] Module to query parrot-config
Here's the sample from the perldoc: .sub _some # store the config data into $P0 $P0 = _config() # Retrieve and print a key $P1 = $P0["cc"] print "Your C compiler is " print $P1 print "\n" .end .include "library/config.imc" Which, when run on my OS X box, gives: oolong:~/research/parrot coke$ ./parrot foo.imc Your C compiler is cc How's that? Adrian Lambeck wrote: This might be it - how do I access the data ? Am Sonntag, 6. MÃrz 2005 20:13 schrieb Will Coleda via RT: Whoops, had already cd'd... it's actually in 'runtime/parrot/library/config.imc' Is this what you're looking for? William Coleda wrote: Already exists. perldoc parrot/library/config.imc Regards. Lambeck (via RT) wrote: # New Ticket Created by Lambeck # Please include the string: [perl #34356] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=34356 > It would be nice to have a module that returns the installed parrot config. Other applications (hopefully a lot) that configure depending on parrot might need this. I mean something like App::Info::HTTPD::Apache (http://search.cpan.org/~dwheeler/App-Info-0.44/). I am not into App::Info so I can not decide what is neccessary to make it return parrot specific values ... Adrian Lambeck
Re: [perl #34356] Module to query parrot-config
Whoops, had already cd'd... it's actually in 'runtime/parrot/library/config.imc' Is this what you're looking for? William Coleda wrote: Already exists. perldoc parrot/library/config.imc Regards. Lambeck (via RT) wrote: # New Ticket Created by Lambeck # Please include the string: [perl #34356] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=34356 > It would be nice to have a module that returns the installed parrot config. Other applications (hopefully a lot) that configure depending on parrot might need this. I mean something like App::Info::HTTPD::Apache (http://search.cpan.org/~dwheeler/App-Info-0.44/). I am not into App::Info so I can not decide what is neccessary to make it return parrot specific values ... Adrian Lambeck
Re: [perl #34356] Module to query parrot-config
Already exists. perldoc parrot/library/config.imc Regards. Lambeck (via RT) wrote: # New Ticket Created by Lambeck # Please include the string: [perl #34356] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=34356 > It would be nice to have a module that returns the installed parrot config. Other applications (hopefully a lot) that configure depending on parrot might need this. I mean something like App::Info::HTTPD::Apache (http://search.cpan.org/~dwheeler/App-Info-0.44/). I am not into App::Info so I can not decide what is neccessary to make it return parrot specific values ... Adrian Lambeck
Release 0.1.12
So Dan's string stuff has been rolled into cvs main (along with a huge # of leo addon patches...) What's the current status of the new GC system? Still need testing? I'd recommend postponing any of the architectural/design items that were slated for 0.1.12 to 0.2.0 at the latest, perhaps another point release if we can get to them sooner... However, until we get Dan (#1) back, there's not much we can do here, I think. Will Coleda (aka #6)
Re: Dan MIA?
To avoid a warnocking, Yup. Stopped in briefly on #parrot about 2 weeks ago, but basically MIA. Leo is currently working on release 0.1.12. Jesse is working on getting the TPF milestones more documented. Regards. Edward Peschko wrote: hey, just thought I'd take parrot's pulse really quick.. last thing I heard from Dan that he was back (about a month ago) and haven't heard from him since. Has he since gone MIA again? Ed
Parrot_get_runtime_prefix
in src/library.c (main branch), I find:
const char*
Parrot_get_runtime_prefix(Interp *interpreter, STRING **prefix_str)
{
static STRING *s;
static int init_done;
static const char *prefix;
int free_env;
char *env;
if (!*runtime_prefix)
return NULL;
if (!init_done) {
/* stat()ing the top level directory doesn't work reliably as often
...
init_done is never initialized here. What's up?
Re: Release 0.1.2 ?
After some distractions I got back to this today. After doing the merge and resolving all the conflicts (of which there really weren't that many), I get it to build, and then get a: 0x0002c3b0 in string_index (interpreter=0xd001a0, s=0x3002fd8, idx=0) at src/string.c:747 747 return (INTVAL)CHARSET_GET_CODEPOINT(interpreter, s, idx); Even with an invocation of "./parrot" (no args). I'll keep poking at it. Looks like a bootstrapping problem on string initialization. Leopold Toetsch wrote: Will Coleda wrote: ..., I can now think about integrating Dan's string branch into main. I should be able to get this done over the weekend. How does it look like? leo
Re: OS X tests
Just did a fresh checkout and now I no longer get test failures on OS X. (not specifying a -prefix) Leopold Toetsch wrote: Will Coleda wrote: I don't know if this is related to my build problems on OS X which have gone warnocked. Trying to build without specifying a --prefix to Configure causes all the dynclasses to fail I can't reproduce that here - it tests 100% fine. Strange. leo
Recent RT work
Thanks to Matt Diephouse, about 30+ tickets have just been properly marked as resolved. (Though I physically closed them, he did all the legwork. Someone make him a bugadmin, please.) This leaves 268 documented issues in RT, plus whatever is lurking in CVS. >50% of these are -new-, despite the fact that some of them are > 2.5 years old http://rt.perl.org/rt3/NoAuth/parrot/Overview.html shows a few dozen of these tickets are platform specific. Some of those tickets are very old. Can someone from the various platforms verify if these are able to be closed? (Win32, mswin32, vms, os2, cygwin, MacOS X, linux, freebsd). The current "Hall of Shame" ticket is #760. http://rt.perl.org/rt3/Ticket/Display.html?id=760 Originally posted by Josh Wilmes in July 2002, with a quick reply by Dan... Josh himself followed up in October of that year to indicate this was still an issue.
build troubles
did a fresh checkout and build... large number of dynclasses tests failed. I then made clean, configured with prefix=`pwd`... now the build itself fails: oolong:~/research/parrot_strings coke$ make Compiling with: xx.c cc -g -pipe -pipe -fno-common -no-cpp-precomp -I/usr/local/include -pipe -fno-common -Wno-long-double -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral -Wformat-security -Wpacked -Wdisabled-optimization -falign-functions=16 -Wno-shadow -I./include -I/usr/local/include -DHAS_JIT -DPPC -DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c ./parrot -o runtime/parrot/include/parrotlib.pbc runtime/parrot/library/parrotlib.imc src/string.c:269: failed assertion `p' make: *** [runtime/parrot/include/parrotlib.pbc] Abort trap Which is: p = strstr(build_path, "blib");/* .../blib/lib/... */ assert(p); Any ideas on how to both build AND pass the tests? oolong:~/research/parrot_strings coke$ uname -a Darwin oolong 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov 7 16:06:51 PST 2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Power Macintosh powerpc
Re: release plan
From the ROADMAP - =head1 NEXT RELEASE (0.1.2) This release has a ticket opened as [perl #33916]. http://rt.perl.org/rt3/Ticket/ModifyLinks.html?id=33916 has a list of all the open issues which must be completed for this release. -snip- I insured the major items you mentioned were listed as children of this ticket. I also added in the biggest missing DESIGN issues (incomplete PDDs) and any pre-existing RT documentation tickets. (I did not see open tickets for either the new GC system or Dan's major string patch.) This is obviously only a initial pass, feel free to remove any RT tickets here. (If you like, you can use the docs/ROADMAP to capture notes and I can transfer information to the RT system from there.) Conversely, if there are other issues that you decide you'd like to get included in this release, we can simply add them to the URL above - once all the child tickets are closed and the release is cut, we can close the release ticket. Please let me know if you would like me to make the use.perl.org announcement again for this incremental release. Regards. Leopold Toetsch wrote: William Coleda <[EMAIL PROTECTED]> wrote: What needs to be completed to cut 0.1.2 ? (0.1.1 was cut > 100 days ago) Yeah. 0.1.2 should be out in about 2 weeks. It should contain: - Dan's unicode string changes I'd be happy if people check out that branch and test it. Merging the branch back to HEAD needs a bit of CVS knowledge. - The generational GC system is nearly complete. It'll hit CVS in a few days. - Documentation updates. Some should be fairly easy, e.g. bringing imcc docs WRT calling conventions up-to-date. Other changes are more invasive, e.g. fixing (or tossing?) pdd05. Leo, Dan, if you can provide a list of tasks, I can work on the administrivia. Great, thanks. Thanks! leo
Re: test_main.c oversight
This is now moved and updated. No cvs magic was used in the relocation of this file. William Coleda wrote: If it's an example, let's move it to "example/c/test_main.c", then, and update the comment in the beginning of the file that says: =head1 DESCRIPTION THIS FILE IS NO LONGER USED. with your note. Brent 'Dax' Royal-Gordon wrote: William Coleda <[EMAIL PROTECTED]> wrote: Then lets remove the file to avoid further confusion. test_main.c is being retained as an example of a non-trivial, but still clean, Parrot embedding. imcc/main.c is way too complicated and incestuous with internals to fill this role.
Speaking of a ROADMAP...
What needs to be completed to cut 0.1.2 ? (0.1.1 was cut > 100 days ago) Leo, Dan, if you can provide a list of tasks, I can work on the administrivia. Thanks!
Re: test_main.c oversight
If it's an example, let's move it to "example/c/test_main.c", then, and update the comment in the beginning of the file that says: =head1 DESCRIPTION THIS FILE IS NO LONGER USED. with your note. Brent 'Dax' Royal-Gordon wrote: William Coleda <[EMAIL PROTECTED]> wrote: Then lets remove the file to avoid further confusion. test_main.c is being retained as an example of a non-trivial, but still clean, Parrot embedding. imcc/main.c is way too complicated and incestuous with internals to fill this role.
Re: test_main.c oversight
Then lets remove the file to avoid further confusion. Leopold Toetsch wrote: [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: I don't find define of "Parrot_setflag()" in test_main.c. src/test_main.c is unused. Why do you want to compile it? leo
task cleanup
Consolidated DESIGN_TODO, KNOWN_ISSUES into the "ROADMAP". If you have more details about any of these issues (Many of them were one liners), please either: o add the detail to this file, or o open a ticket for the item with with detail. Also, if you know that an item is obsolete, feel free to delete it from this file. (Or close out the corresponding RT ticket, if there is one.) Regards.
Re: Roadmap, RT, TODO...
Leopold Toetsch wrote: William Coleda <[EMAIL PROTECTED]> wrote: I had great plans to flesh it out more than I have, but work has intruded. I've checked in what I have so far in docs/ROADMAP. I really appreciate the effort putting all that together. But it's not that simple. E.g. the TODO WRT pdd05: this pdd is totally outdated. It describes the function-based run-core before the times, where ops2c.pl did exist. Or: most of what is listed under DESIGN, are documentation TODOs. Design is a special kind of documentation that, in my mind, needs to be broken out. If these PDDs are outdated, then the design needs to be "redone", that is, re-documented. Before creating a detailed list of items, these should be verified against the implementation. That's a big job. Many (especially pdd) docs need updating. A Parrot Documentation Group would be really awesome. There already are fairly large lists of items that need collation. That is, I am not creating any items on the list. Having them in a central location should make the project more manageable. That's really my goal here, to facilitate some PM. I'd appreciate it if you opened TODO tickets in RT regarding which PDDs you think are currently out of date, btw. Well, and the file isn't really a ROADMAP (yet). Nope. But I'm not in a position to set policy or determine what is due in certain release. That's what you and Dan are for, I'm just trying to provide the ability to capture this information in a single location. (now docs/ROADMAP, eventually RT)
RT Hall of Shame [perl #15308]
This week's Hall of Shame ticket is [perl #15308] http://rt.perl.org/rt3/Ticket/Display.html?id=15308 Originally submitted in July of 2002 by Scott Walters, the only activity on the warnocked ticket was a ping to the list in April of 2004 asking if someone could rule on the patch. No followups were received. This patch was an effort to take feedback Dan provided on the mailing list about a particular topic, and get it into the documentation in CVS. This ticket has had no (real) activity since it was originally submitted *914* days ago. See you next week!
Roadmap, RT, TODO...
Now that Dan's back, I'd like to make sure we have a roadmap in place for moving forward. I had great plans to flesh it out more than I have, but work has intruded. I've checked in what I have so far in docs/ROADMAP. I would like to eventually have every single outstanding task documented in RT, and a custom report that lets us get a more project-style overview of remaining tasks. I'll work with Robert on this (unless someone wants to take this item.). Once everything is in RT, then this file will be obsolete. We have a ways to go before then, however. The current items listed in the file are from a small subset in the docs directory. In my mind, the most important section here are those DESIGN items which are still outstanding. I would ask that anyone with a few tuits go through http://rt.perl.org/rt3 and close out any low hanging fruit. (If you're not a bug admin, and you think something's closeable, ping me or one of the other bugadmins and we can close out the ticket.) Again, I think the medium term goal needs to be to get everything into RT with all the appropriate meta data (parents, children, dependencies, time estimates, etc.). For now, this file will be a good intermediate step until we can get the data in, and get a report to get it out. Regards. # Copyright: 2001-2004 The Perl Foundation. All Rights Reserved. # $Id: ROADMAP,v 1.1 2005/01/20 06:34:26 coke Exp $ =head1 NAME ROADMAP =head1 PURPOSE As of this writing, there is no one place in which all remaining parrot work is documented. There are various TODO files, the RT queue, comments in the source code and the documentation. This document is a first pass at unifying this information and providing a single point of reference for anyone interested in the current state of the parrot, whether they are developers looking for items to work on, or external users looking for an idea of when they can expect a release. This document is not meant to contain all the metadata regarding particular tasks, but merely provide a summary of the tasks. =head1 OVERVIEW The tasks that are remaining are broken down into the following categories, roughly listed in the order which a task might progress. =head2 METADATA Each task has certain metadata associated with it which must be tracked. =head2 DESIGN These are pending design decisions which must be made before any code can be written to implement them. =head2 TODO Any item, whether visible to parrot users or hidden behind an API, that has already been designed (but not implemented) belongs here. =head2 BUGFIX Any items which have been implemented but don't work as expected. =head2 PORTABILITY Any items which are specific to a particular platform or require special attention for cross-platform compatibilty. =head2 DOCUMENTATION Any items pertaining to source, API, or user level documentation. =head2 HIGH LEVEL LANGUAGES Parrot currently ships with several partial language implementations. Any tasks which are specific to those languages, or affect cross-language compatibility will be listed here. =head1 ISSUES =head2 METADATA =over 4 =item * To be included: docs/pmc, docs/resources, docs/*.pod, anything in CVS not in docs, RT. (That is, quite a bit.) =back =head2 DESIGN =over 4 =item * PDD10 (Embedding) must be completed. =item * PDD12 (Assembly) must be completed. =item * PDD13 (Bytecode) must be completed. =item * Describe the behavior of init_pmc_props. L =item * Describe the behavior of the serialization functions. (freeze, thaw, thawfinish, visit). L =item * Describe the behavior of C. L =item * Describe the components of a C. L =back =head2 TODO =over 4 =item * Create opcode_process.pl L =item * Fill in the remaining functions from the EDA, verify that the test suite still passes, integrate the library into the rest of Parrot, provide PMC types and suitable opcodes. Conversion to and from Parrot strings, conversion to and from floating point types, sprintf output of bignumbers. L =item * Implement the parrot equivalent of perl5's C<$0>, based on recent (January 2005) mailing list activity. =item * C does not search the library path to load the file. L =item * The debugger needs to clone the interpreter to "allow people to play into the debugger and then continue the normal execution of the program." L =item * parrot doesn't catch the exception thrown by the op C. L =item * C op is documented but unimplemented. L =item * There is no way to do a case insenstive match. L =back =head2 BUGFIX =head2 PORTABILITY =over 4 =item * ParrotIO uses integral file descriptors, which may not be portable. L =back =head2 DOCUMENTATION =head2 HIGH LEVEL LANGUAGES =over 4 =item * Items in languages/tcl/TODO must be completed. =item * Pass the pie-thon test suite. =back =head1 FUTURE This document should eventually be obsoleted by use of the RT ticketing system. Every task that is to be done should be documented in the system, and re
Re: [perl #33815] resove ticket via e-mail
This is a deployment of RT for issuings regarding http://www.parrotcode.org, not the ticketing system for RT itself. I would suggest checking http://www.bestpractical.com/rt/. Regards. prashanth (via RT) wrote: # New Ticket Created by prashanth # Please include the string: [perl #33815] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=33815 > Hi, I want to set RT to resolve ticket via mail by requester or CC. please any body give the solution how to set scrips and how to send mail to resolve tickets via mail. regards, prashanth.
Re: crashing parrot for fun and profit.
So, it's possible for someone to crash parrot by writing questionable PIR? ^_^
(This was working fine for quite some time, btw.)
Also, what do I need to do to save these subroutines? I'm doing dynamic
dispatch based on the tcl commands, so
proc foo {} {
puts "foo"
}
defines a sub in parrot's "Tcl" namespace called "foo".
When I want to execute this sub later, I do a find_global "Tcl", "foo", then invoke what I get back.
So, if defining a subroutine isn't sufficient to avoid the subroutine from getting
garbage collected, what do you recommend? Is this /just/ because I'm using pir_compiler?
could I expect the same thing to happen to subs that are defined in the "Tcl"
namespace at the time the interpreter is begun?
Leopold Toetsch wrote:
William Coleda <[EMAIL PROTECTED]> wrote:
Running the tcl "examples/bench.tcl" script, I get the following backtrace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0021cb38 in Parrot_Sub_invoke (interpreter=0xd001a0, pmc=0xed2b60,
next=0xf20284) at classes/sub.c:239
239 if (interpreter->code->cur_cs != sub->seg) {
Any chance this is a parrot issue and not a tcl issue?
It's GC related (running it with -G succeeds).
It seems that you aren't always storing compiled code objects away. So
these get GCed. E.g.
commands/proc.imc:106
$P0 = compile pir_compiler, proc_body
The compilation result C<$P0> remains unanchored.
leo
languages/perl6
What's going to happen to the perl6 work in progress that's in the parrot repository now that there is a separate svn repository?
More questions for the compiler FAQ...
Is it possible to: 1) define methods for a PMC/Object in C that aren't vtable methods? How? 2) call subroutines defined in bytecode from C? How?
crashing parrot for fun and profit.
Running the tcl "examples/bench.tcl" script, I get the following backtrace:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x0021cb38 in Parrot_Sub_invoke (interpreter=0xd001a0, pmc=0xed2b60,
next=0xf20284) at classes/sub.c:239
239 if (interpreter->code->cur_cs != sub->seg) {
(gdb) bt
#0 0x0021cb38 in Parrot_Sub_invoke (interpreter=0xd001a0, pmc=0xed2b60,
next=0xf20284) at classes/sub.c:239
#1 0x00067d74 in Parrot_invokecc (cur_opcode=0xf20280, interpreter=0xd001a0)
at ops/core.ops:440
#2 0x001d617c in runops_slow_core (interpreter=0xd001a0, pc=0xf20280) at
src/runops_cores.c:147
#3 0x00048e90 in runops_int (interpreter=0xd001a0, offset=0) at
src/interpreter.c:742
#4 0x00042aa8 in runops (interpreter=0xd001a0, offs=0) at src/inter_run.c:81
#5 0x00015750 in Parrot_runcode (interpreter=0xd001a0, argc=2,
argv=0xbce4) at src/embed.c:768
#6 0x00015508 in Parrot_runcode (interpreter=0xd001a0, argc=2,
argv=0xbce4) at src/embed.c:700
#7 0x3f18 in main (argc=2, argv=0xbce4) at imcc/main.c:603
Any chance this is a parrot issue and not a tcl issue?
I'm also seeing the following on a slightly different tcl script:
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x000625a8 in Parrot_find_global_p_sc_sc (cur_opcode=0xd2235c,
interpreter=0xd001a0) at ops/var.ops:305
305 if (!$2)
(gdb) bt
#0 0x000625a8 in Parrot_find_global_p_sc_sc (cur_opcode=0xd2235c,
interpreter=0xd001a0) at ops/var.ops:305
#1 0x001d617c in runops_slow_core (interpreter=0xd001a0, pc=0xd2235c) at
src/runops_cores.c:147
#2 0x00048e90 in runops_int (interpreter=0xd001a0, offset=0) at
src/interpreter.c:742
#3 0x00042aa8 in runops (interpreter=0xd001a0, offs=0) at src/inter_run.c:81
#4 0x00015750 in Parrot_runcode (interpreter=0xd001a0, argc=2,
argv=0xbce4) at src/embed.c:768
#5 0x00015508 in Parrot_runcode (interpreter=0xd001a0, argc=2,
argv=0xbce4) at src/embed.c:700
#6 0x3f18 in main (argc=2, argv=0xbce4) at imcc/main.c:603
Re: [NUDGE] split on REs
Yes, I was using a regular expression, not a rules. =-) Patrick R. Michaud wrote: On Wed, Dec 29, 2004 at 08:09:10PM -0500, William Coleda wrote: I'd like to get Tcl's [namespace] implemented, but this will be very difficult until I can do: $P0 = split "::+", $S0 or something equivalent with PGE. Nudge noted. At the moment I've been holding off on progressing too far with PGE because the rule "match semantics" are in the midst of being redefined somewhat (based on discussions on perl6-language and other places) and the changes being contemplated have some non-trivial implications for PGE's internals. Out of curiosity (so I can better work towards supporting your need), are you really intending to do the equivalent of: $P0 = split "\:\:+", $S0 i.e., separating $S0 based on sequences of two or more literal colons? (Colons are metacharacters in p6rules.) Pm
[NUDGE] split on REs
I'd like to get Tcl's [namespace] implemented, but this will be very difficult until I can do: $P0 = split "::+", $S0 or something equivalent with PGE.
Re: dynclasses/*py* broke the build
Looks good, thanks. Sam Ruby wrote: William Coleda wrote: (Resend from the right account so it'll make it to the list.) This is on OSX. Looks very similar to an issue that I think Sam has already fixed once. I have some tcl stuff pending that I can't verify works in a clean build until I have clean build. =-) Sorry about that... I've committed what I hope to be a fix. - Sam Ruby
Re: cvs commit: parrot/dynclasses pyproxyclass.pmc pyproxytype.pmc
Not quite:
ld: multiple definitions of symbol _PROXY_STRING
pyproxytype.o definition of _PROXY_STRING in section (__DATA,__common)
pyproxyclass.o definition of _PROXY_STRING in section (__DATA,__common)
Sam Ruby wrote:
cvsuser 04/12/13 19:12:07
Modified:dynclasses pyproxyclass.pmc pyproxytype.pmc
Log:
PROXY must conflict with a prefixed C constant on MAC/OSX
Revision ChangesPath
1.2 +4 -4 parrot/dynclasses/pyproxyclass.pmc
Index: pyproxyclass.pmc
===
RCS file: /cvs/public/parrot/dynclasses/pyproxyclass.pmc,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- pyproxyclass.pmc 13 Dec 2004 21:50:58 - 1.1
+++ pyproxyclass.pmc 14 Dec 2004 03:12:06 - 1.2
@@ -1,6 +1,6 @@
/*
Copyright: 2001-2003 The Perl Foundation. All Rights Reserved.
-$Id: pyproxyclass.pmc,v 1.1 2004/12/13 21:50:58 rubys Exp $
+$Id: pyproxyclass.pmc,v 1.2 2004/12/14 03:12:06 rubys Exp $
=head1 NAME
@@ -24,7 +24,7 @@
#include "parrot/parrot.h"
static INTVAL dynclass_PyProxyClass;
-STRING *PROXY;
+STRING *PROXY_STRING;
pmclass PyProxyClass extends PyObject dynpmc group python_group {
@@ -43,7 +43,7 @@
if (pass) {
dynclass_PyProxyClass = Parrot_PMC_typenum(INTERP, "PyProxyClass");
-PROXY = const_string(INTERP, "__proxy__");
+PROXY_STRING = const_string(INTERP, "__proxy__");
}
}
@@ -101,7 +101,7 @@
internal_exception(1, "Invoke() called on a PyProxyClass object");
INTERP->ctx.current_object = REG_PMC(2) =
-VTABLE_getprop(INTERP, proxy, PROXY);
+VTABLE_getprop(INTERP, proxy, PROXY_STRING);
return VTABLE_invoke(INTERP, (PMC*)PMC_struct_val(SELF), next);
}
1.2 +4 -4 parrot/dynclasses/pyproxytype.pmc
Index: pyproxytype.pmc
===
RCS file: /cvs/public/parrot/dynclasses/pyproxytype.pmc,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- pyproxytype.pmc 13 Dec 2004 21:50:58 - 1.1
+++ pyproxytype.pmc 14 Dec 2004 03:12:06 - 1.2
@@ -1,6 +1,6 @@
/*
Copyright: 2001-2003 The Perl Foundation. All Rights Reserved.
-$Id: pyproxytype.pmc,v 1.1 2004/12/13 21:50:58 rubys Exp $
+$Id: pyproxytype.pmc,v 1.2 2004/12/14 03:12:06 rubys Exp $
=head1 NAME
@@ -67,7 +67,7 @@
STRING *BASES;
STRING *CLASS;
STRING *INIT;
-STRING *PROXY;
+STRING *PROXY_STRING;
pmclass PyProxyType extends PyType dynpmc group python_group {
@@ -88,7 +88,7 @@
BASES = const_string(INTERP, "__bases__");
CLASS = const_string(INTERP, "__class__");
INIT = const_string(INTERP, "__init__");
-PROXY = const_string(INTERP, "__proxy__");
+PROXY_STRING = const_string(INTERP, "__proxy__");
}
}
@@ -128,7 +128,7 @@
object = REG_PMC(5);
}
-VTABLE_setprop(INTERP, proxy, PROXY, object);
+VTABLE_setprop(INTERP, proxy, PROXY_STRING, object);
REG_PMC(5) = proxy;
return next;
Re: Dynamic libs don't seem to work
Can you give us a copy of the generated "myconfig" file in the top level parrot directory? Klaas-Jan Stol wrote: Hello, I just got a fresh cvs checkout, compiled it, compiled pge and tried to make tcl. This is what I get: (cd ../../ && ./parrot --output=languages/tcl/lib/tcllib.pbc languages/tcl/lib/tcllib.imc) Couldn't load 'tcl_group': tcl_group: cannot open shared object file: No such file or directory error:imcc:Unknown PMC type 'TclString' in file 'languages/tcl/lib/commands/upvar.imc' line 13 included from 'languages/tcl/lib/tcllib.imc' line 1 make: *** [lib/tcllib.pbc] Error 17 Also: - when doing "make test", all tests with dynamic pmc seem to fail. - following instructions in dynoplibs and trying to execute the "test.pasm" in dynoplibs/ doesn't work either. Couldn't load 'myops_ops': myops_ops: cannot open shared object file: No such file or directory Couldn't load 'foo': foo: cannot open shared object file: No such file or directory Couldn't load 'libnci': libnci: cannot open shared object file: No such file or directory error:imcc:parse error, unexpected IDENTIFIER, expecting PARROT_OP in file 'dynoplibs/test.pasm' line 43 Obviously, there is something wrong with dynamic libs. I don't get what I'm doing wrong. This should all work right? Perljam (sorry, don't know his real name) told me on IRC he did a fresh checkout, and it all worked. Any ideas? thanks, klaas-jan
Re: [perl #32545] [PATCH] [TODO] remove Perl dependancy on split opcode
Thanks, applied!
James deBoer wrote:
Attached is a patch that changes the split opcode to use an Array
instead of a PerlArray.
It also updates the documentation to note this.
All the tests still pass, and a grep in the languages/ directory shows
that no language implementations are effected.
- James
Will Coleda (via RT) wrote:
# New Ticket Created by Will Coleda # Please include the string:
[perl #32545]
# in the subject line of all future correspondence about this issue. #
http://rt.perl.org:80/rt3/Ticket/Display.html?id=32545 >
The split opcode currently uses a PerlArray to house its result. It
should use a non-language specific class.
? classes/.array.pmc.swp
Index: ops/string.ops
===
RCS file: /cvs/public/parrot/ops/string.ops,v
retrieving revision 1.28
diff -u -r1.28 string.ops
--- ops/string.ops 28 Sep 2004 11:26:49 - 1.28
+++ ops/string.ops 6 Dec 2004 19:16:59 -
@@ -561,7 +561,7 @@
=item B(out PMC, in STR, in STR)
-Create a new PerlArray PMC $1 by splitting the string $3 with
+Create a new Array PMC $1 by splitting the string $3 with
regexp $2. Currently implemented only for the empty string $2.
=cut
@@ -589,7 +589,7 @@
}
op split(out PMC, in STR, in STR) :base_core {
-PMC *res = $1 = pmc_new(interpreter, enum_class_PerlArray);
+PMC *res = $1 = pmc_new(interpreter, enum_class_Array);
STRING *r = $2;
STRING *s = $3;
int slen = string_length(interpreter, s);
@@ -599,6 +599,7 @@
goto NEXT();
if (string_length(interpreter, r))
internal_exception(1, "Unimplemented split by regex");
+VTABLE_set_integer_native(interpreter, res, slen);
for (i = 0; i < slen; ++i) {
STRING *p = string_substr(interpreter, s, i, 1, NULL, 0);
/* TODO first set empty string, then replace */
svn
Is there a plan at any point to move to an svn repository from cvs? I'd like to work on a patch to move all the perl* pmcs into dynclasses, which would involve quite a bit of file moving, and I'll happily wait for svn if we're going that way, since it'll be smoother.
Re: [perl #32906] Can't make TCL
You mean, someone actually tried to use Tcl? *Rub eyes* Whoops. File got added to the tcl makefile based on a local copy of the command. Committed update to MANIFEST and the join file (which isn't complete or tested, btw.) Try again? Matthew Zimmerman (via RT) wrote: # New Ticket Created by Matthew Zimmerman # Please include the string: [perl #32906] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=32906 > --- osname= linux osvers= 2.4.21-4.elsmp arch= i386-linux-thread-multi cc= gcc 3.3.3 20040412 (Red Hat Linux 3.3.3-7) --- Flags: category=core severity=high ack=no --- I can't get TCL to `make', on the most recent CVS checkout: [EMAIL PROTECTED] ~/personal/devel/parrot $ cd languages/tcl [EMAIL PROTECTED] ~/personal/devel/parrot/languages/tcl $ make make: *** No rule to make target `lib/commands/join.imc', needed by `lib/tcllib.imc'. Stop. --- Summary of my parrot 0.1.1 configuration: configdate='Mon Dec 6 12:02:34 2004' Platform: osname=linux, archname=i386-linux-thread-multi jitcapable=1, jitarchname=i386-linux, jitosname=LINUX, jitcpuarch=i386 execcapable=1 perl=/usr/bin/perl Compiler: cc='gcc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp -lpthread -lm -L/usr/lib -licuuc -licudata -lpthread -lm' Dynamic Linking: share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC', load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=1234, nv=double, numvalsize=8, doublesize=8 --- Environment: HOMELANGLANGUAGELD_LIBRARY_PATHLOGDIRPATH PERL5LIBSHELL
Re: [perl #32868] [PATCH] target 'help' in 'parrot/docs/Makefile'
Thanks, applied. Bernhard Schmalhofer (via RT) wrote: # New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #32868] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=32868 > Hi, this patch adds a target 'help' to 'parrot/docs/Makefile'. A list of available targets should be printed. CU, Bernhard
Tcl - new [commands]
Added some more list-based commands.
Added upvar (alias to caller's variables), uplevel (execute code in caller's
scope). (or your caller's caller, or...)
Also added a non-standard "inline" command so you can do:
oolong:~/research/parrot/languages/tcl/examples coke$ cat inline.tcl
inline PIR {
.sub junk
$P0 = new String
$P0 = "nifty"
store_lex 0, "a", $P0
.end
}
puts $a
oolong:~/research/parrot/languages/tcl/examples coke$ make inline
cd ../../../ && ./parrot languages/tcl/tcl.pbc languages/tcl/examples/inline.tcl
nifty
Volunteers welcome. =-)
PGE issues
A few issues with the recent CVS doings... 1) runtime/parrot/library/runtime/PGE.pir doesn't compile by default. Which it can't, because: 2) PGE doesn't build by default. Should it? If so, then... 3) cd compilers/pge && make fails: c++ -dynamiclib -L/usr/local/lib -flat_namespace -o pge.dylib pge_parse.o pge_gen.o pge_opt.o pge_parsep5.o pge_parseglob.o ld: multiple definitions of symbol _pge_cmeta pge_parse.o definition of _pge_cmeta in section (__DATA,__common) pge_parseglob.o definition of _pge_cmeta in section (__DATA,__common) ld: multiple definitions of symbol _pge_ctype pge_parse.o definition of _pge_ctype in section (__DATA,__common) pge_parseglob.o definition of _pge_ctype in section (__DATA,__common) /usr/bin/libtool: internal link edit command failed make: *** [pge.dylib] Error 1 This is on OS X: Darwin oolong 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc It did work for a little while.
p6ge compiler's namespace...
Should the compilation sub for p6g3 be in the root namespace as it is currently, or moved to, say, a "p6ge" namespace?
Re: [perl #32547] [TODO] Tcl - Support \u escapes
Was an RT ticket ever created for the underlying parrot issue here? Will Coleda (via RT) wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #32547] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=32547 > Need unicode support for \u escapes, and for "string wordend", "string wordstart", "string is", "string bytelength", etc. You can currently create unicode strings in parrot, but you can't get them into utf-8, which means you can't easily print them out.
Tcl - basic list support
Finally added in rudimentary list support in tcl (using dynclasses/tcllist.pmc) So the following tcl: set a [list a b c] lappend a d e f puts [llength $a] will now print 6. More list stuff to come soon, shortly after the exception-related test failures go away. =-)
Re: exceptions
I switched to local exception handler blocks, and am still getting the same failure mode. Of course, it works fine in a simple, single file example. I've checked everything back in so you can take a look. Once you build tcl, from the top level directory, try: oolong:~/research/parrot_8075 coke$ cat error.tcl set a(b) 2 puts $a(b) This SHOULD trigger the exception handler in languages/tcl/lib/command/set.imc. Instead, the stack trace ends with: 3718 set_eh P20 - P20=Exception_Handler=PMC(0x401b5d8) 3720 find_lex P18, -1, S17- P18=Array=PMC(0x401b578), , S17="a" And, again, exit value of 0. Leopold Toetsch wrote: William Coleda <[EMAIL PROTECTED]> wrote: I just noticed some test failures in the tcl suite. exception syntax will change slightly. set P4, P5["_invoke_cc"] especially these constructs (resumable handling). Please use currently a local handler: newsub ignore, .Exception_Handler, catch set_eh ignore # ops that might fail clear_eh catch: Even better, stuff above 2 handler install lines into a macro, as the syntax will likely be: new ignore, .Exception_Handler push_eh ignore, catch leo
exceptions
I just noticed some test failures in the tcl suite. Looks like the following code: print "HERE?\n" set_eh ignore find_lex lexical, -1, var clear_eh Does the following at runtime: 3713 print "HERE?\n" HERE? 3715 set_eh P20 - P20=Exception_Handler=PMC(0xf8eb30) 3717 find_lex P18, -1, S17- P18=Array=PMC(0xf8eb48), , S17="b" And just stops. Exit code 0. Here's my exception handler: .namespace [ "_Tcl"] .emit __default_handler: set P4, P5["_invoke_cc"] set P5, P5["_P5"] invoke P4 .eom And here's where I define the invoke pmc used above: .local pmc ignore newsub ignore, .Exception_Handler, __default_handler Any ideas?
Re: First public release of grammar engine
Patrick R. Michaud wrote: P6GE assumes that it is part of the parrot distribution in the F directory. Simply type C in this directory to build the F shared library it needs. oolong:~/research/parrot/compilers/p6ge coke$ make cc -I ../../include -c -o p6ge_parse.o p6ge_parse.c p6ge_parse.c:23:20: malloc.h: No such file or directory p6ge_parse.c: In function `p6ge_parse_new': p6ge_parse.c:105: warning: assignment makes pointer from integer without a cast p6ge_parse.c: In function `p6ge_parse_literal': p6ge_parse.c:156: warning: assignment makes pointer from integer without a cast p6ge_parse.c: In function `p6ge_parse_quant': p6ge_parse.c:227: warning: assignment makes pointer from integer without a cast make: *** [p6ge_parse.o] Error 1 oolong:~/research/parrot/compilers/p6ge coke$ uname -a Darwin oolong 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc Regards.
Parrot Ticket Summary
Here's a simple report of new/open tickets from RT. It's generated using the RT command line tool Robert just pointed me at (plus some perl scripts) Feedback about what's useful, not, and missing is appreciated. Once we have a decent idea of what sort of report will be useful, Robert can generate a report directly from the API, rather than the ad-hoc method I'm using now. (which will improve accuracy and speed.) bash-2.05b$ ./gen_report Parrot Ticket Summary There are currently 277 new/open tickets. The oldest ticket was created on: 12Dec2001 [#192] The average (mean) age of tickets is: 63 weeks Platforms All: 1 cygwin: 3freebsd: 3 Linux: 3MacOS X: 2mswin32: 5 os2: 1 other: 2Unspecified: 252 vms: 1 Win32: 7 Languages BASIC: 1tcl: 4Unspecified: 272
Re: [perl #32223] [PATCH] Build dynclasses by default.
Whoops, thanks applied. Bernhard Schmalhofer via RT wrote: It looks like the the 'all' target wasn't properly changed, when applying the patch. Applying the updated patch from ticket 31643 should fix this. CU, Bernhard
Re: Tail calls and continuations
Is it sufficient to provide a mechanism for the compiler writers to indicate that tail call should be used? For example, I have a few cases in tcl where I have something like: ($I0,$P0) = interpret($P1) .return($I0,$P0) Where I'd be happy to have to write: .return_tailcall(interpret($P1)) or somesuch. Leopold Toetsch wrote: AFAIK the only problem with tailcalls and tail-recursive functions is to prperly detect them in some optimizer, or to convert to such tailcalls.
Re: [PATCH] dynclass build
"Thanks, Applied" Dan Sugalski wrote: At 3:51 PM +0100 11/4/04, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: Are we comfortable adding the dynclasses to the default build target? I think it can go in. Done.
Re: [perl #25255] IMCC - no warning on duplicate .local vars
That is to say, the file and line number appear to be off. Will Coleda via RT wrote: Also, the errors message isn't reporting properly. Help?
Re: [PATCH] Re: [perl #31978] [BUG] dynclasses broken
oolong:~/research/parrot/include/parrot coke$ uname -a
Darwin oolong 7.5.0 Darwin Kernel Version 7.5.0: Thu Aug 5 19:26:16 PDT 2004;
root:xnu/xnu-517.7.21.obj~3/RELEASE_PPC Power Macintosh powerpc
perl is "v5.8.1-RC3"
All tests successful, 4 tests and 52 subtests skipped.
Files=122, Tests=1943, 422 wallclock secs (181.27 cusr + 101.12 csys = 282.39 CPU)
Brent Royal-Gordon via RT wrote:
Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
At the same time, I'm not sure why we need this construct in a header:
struct Parrot_Interp;
typedef struct Parrot_Interp *Parrot_Interp;
We don't need it. There was some discussion a while a go. This typedef
should just be removed.
The embedding interface needs the typedef, but it doesn't need it to
have the same name as the struct. The struct is the odd man out
here--the standard used elsewhere in Parrot is:
Struct: struct parrot_whatever_t {...};
Internal typedef: typedef struct parrot_whatever_t Whatever;
External typedef: typedef struct parrot_whatever_t *Parrot_Whatever;
See the String/Parrot_String/parrot_string_t triplet for another
example of this.
I've written a patch to implement this change:
Patch is 1979 lines, or ~81kb, and implements the scheme above.
Amusingly, Parrot is about 172kb smaller with this patch applied--all
those function declarations, I guess. I've reordered the files in the
patch so that the interesting stuff is near the top, and the
machine-generated stuff is at the bottom.
As you might suspect, most of this patch was done with a
one-liner--the moral equivalent of:
find . -xtype f | xargs perl -i -pe 's/struct\s+Parrot_Interp/Interp/'
(although I added some extra code to tell me how many changes were
made in each file).
There are a few files that used macros to shorten declarations
involving a "struct Parrot_Interp *"; these are now unnecessary and
occasionally counterproductive, but I haven't attempted to remove
them.
I've tested this out on my Linux box, navi:
Linux navi 2.4.18-opt #2 SMP Sun May 23 17:39:01 PDT 2004 i686 GNU/Linux
This is perl, v5.8.2 built for i686-linux-thread-multi
and everything seems to work. However, I'd appreciate testing from
people on other platforms, particularly ones with their own platform
files.
Testing or no, I'll apply this in a day or two if there are no objections.
Re: [perl #31992] [BUG] YetAnotherGarbageCollectionBug(tm)
Leopold Toetsch via RT wrote: Will Coleda <[EMAIL PROTECTED]> wrote: I noticed after a recent update that parts of the tcl test suite started failing. I finally tracked it down to the fact that I was NOT running with '-G'. tcl.pl dies at 19, removing "or die" fixes that. In my rush to get check back in to duplicate the bug, I created the same bug I did before since I hadn't pruned empty directories. Fixed. To your problem: C is an abstract object, it doesn't have a vtable. But the bundling code *does* C this PMC. This leads to an empty vtable slot, dereferencing that NULL is an operation, which many systems don't like. After fixing that (or better working around - C shouldn't be called) it dies later and as usual by loosing C - it seems. My gut feeling is that C isn't quite up to data. It duplicates at firt sight just C. But the latter has recent changes WRT hash creation, which aren't in C. Yup. Tcl* are all (except TclWord) cargo culted from the first time I submitted a patch. They've not been kept current since they were uncompilable until a week or two ago. I'd first reduce C to a bare minimum. Specifically the creation functions (init, clone) should be inherited (or follow the C conventions). The same applies to any PMC that can hold pointers to other PMCs. These changes are necessary to make a PMC compliant with incremental GC. Please grep through the docs and the sources for DOD_WRITE_BARRIER. Hey, finally one of the GC bugs is my fault! I've claimed the ticket, I'll see what I can do.
Re: cvs commit: parrot/languages/tcl/lib/macros boolean.imc
Danke. Making this a macro was, at least, a step up from the function call I had.
I haven't done anything real with the PMCs yet (just cargo-culted them mostly from
their Perl* counterparts)
Though I have to wonder how this will work with inter-language-operability.
Thanks, Leo.
Leopold Toetsch wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
Given a pmc, set a register to indicate whether
it is true or false from Tcl's POV.
inline op istrue(out INT, in PMC) {
with an approprate get_bool() vtable slot.
leo
Re: parrotcode.org: release 0.1.1?
http://www.parrotcode.org/ has been updated (Thanks, ask.) The use.perl.org announcement is at: http://use.perl.org/article.pl?sid=04/10/12/1530208&tid=33&tid=42 Dan Sugalski wrote: At 6:35 AM -0700 10/12/04, Will Coleda wrote: Is there an announcement on use.perl.org yet? Not that I see, no. On Tue, Oct 12, 2004 at 10:39:39AM +0200, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 8:37 AM -0400 10/11/04, William Coleda wrote: >>This is set to go, pending an article on use.perl.org. > If Leo's comfortable that things are Working Fine, then push it out > to parrotcode.org. While there's always more breakage report after a release then before, the release should be ok. leo -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: parrotcode.org: release 0.1.1?
This is set to go, pending an article on use.perl.org. Dan Sugalski wrote: At 3:41 PM +0200 10/10/04, Jerome Quelin wrote: Hey guys, We should update http://www.parrotcode.org to reflect the latest version since 0.1.1 is out! Is it something underway waiting for sync, or is it a forgetting? Probably a forgetting. :) Might not be too bad an idea to wait a day or two just in case, if we need to sort out any quirks that showed up after release.
Re: macros, local variables...
Leopold Toetsch wrote: .macro swapP (A,B) $P0 = .A .A = .B .B = $P0 .endm (untested) Seems to work, thanks. *But* we have an opcode called *exchange* ... It's even JITted on i386. This was just an example. Thanks. leo
Re: [perl #31910] ICU bug with fresh CVS Checkout
Failed Test Stat Wstat Total Fail Failed List of Failed --- t/library/parrotlib.t6 1536 66 100.00% 1-6 t/pmc/nci.t 1 256461 2.17% 47 t/pmc/sys.t 1 256 11 100.00% 1 t/src/basic.t2 512 32 66.67% 2-3 t/src/exit.t 3 768 33 100.00% 1-3 t/src/extend.t 13 332813 13 100.00% 1-13 t/src/hash.t 9 2304109 90.00% 1-9 t/src/intlist.t 4 1024 44 100.00% 1-4 t/src/io.t 19 486420 19 95.00% 1-17 19-20 t/src/list.t 2 512 22 100.00% 1-2 t/src/sprintf.t 3 768 33 100.00% 1-3 t/src/string.t 1 256 11 100.00% 1 4 tests and 99 subtests skipped. Failed 12/122 test scripts, 90.16% okay. 62/1937 subtests failed, 96.80% okay. make: *** [test] Error 2 William Coleda wrote: Makes. I just started make test, but it doesn't look good. t/library/parrotlib# Failed test (t/library/parrotlib.t at line 47) # got: 'Parrot VM: Can't stat runtime/parrot/include/parrotlib.pbc, code 2. # ' # expected: 'runtime/parrot/include/datatypes.pasm # ' # '(cd . && ./parrot -b --gc-debug "/Users/coke/research/parrot-11/t/library/parrotlib_1.imc")' failed with exit code 138 t/library/parrotlibNOK 1# Failed test (t/library/parrotlib.t at line 56) # got: 'Parrot VM: Can't stat runtime/parrot/include/parrotlib.pbc, code 2. etc. Jens Rieks wrote: c++ -o parrot -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lm -lpthread -lm -L/usr/local/lib -licuuc -lpthread -lm ld: warning can't open dynamic library: libicudata.dylib.30 (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: Undefined symbols: _icudt30_dat referenced from libicuuc.dylib.30 expected to be defined in libicudata.dylib.30 make: *** [parrot] Error 1 does c++ -o parrot -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lm -lpthread -lm -L/usr/local/lib -licuuc -licudata -lpthread -lm work? jens
Re: [perl #31910] ICU bug with fresh CVS Checkout
Makes. I just started make test, but it doesn't look good. t/library/parrotlib# Failed test (t/library/parrotlib.t at line 47) # got: 'Parrot VM: Can't stat runtime/parrot/include/parrotlib.pbc, code 2. # ' # expected: 'runtime/parrot/include/datatypes.pasm # ' # '(cd . && ./parrot -b --gc-debug "/Users/coke/research/parrot-11/t/library/parrotlib_1.imc")' failed with exit code 138 t/library/parrotlibNOK 1# Failed test (t/library/parrotlib.t at line 56) # got: 'Parrot VM: Can't stat runtime/parrot/include/parrotlib.pbc, code 2. etc. Jens Rieks wrote: c++ -o parrot -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lm -lpthread -lm -L/usr/local/lib -licuuc -lpthread -lm ld: warning can't open dynamic library: libicudata.dylib.30 (checking for undefined symbols may be affected) (No such file or directory, errno = 2) ld: Undefined symbols: _icudt30_dat referenced from libicuuc.dylib.30 expected to be defined in libicudata.dylib.30 make: *** [parrot] Error 1 does c++ -o parrot -L/usr/local/lib -g imcc/main.o blib/lib/libparrot.a -lm -lpthread -lm -L/usr/local/lib -licuuc -licudata -lpthread -lm work? jens
