Re: tests for change #22539
Jim Cromie wrote:
Rafael Garcia-Suarez wrote:
2. you gave me an idea for a Grand Plan.
Heres a 'working' version of my earlier proposal,
patched against [EMAIL PROTECTED]
I hope you find it useful for regression testing of the optimizer,
and the opcode generation phases.
1st some changes to existing files:
1. test.pl addition.
I added unlike(). Comment there obviously means that this has come up
before, and I submit w/o researching, but heres my case.
Currently, one cannot expect a failure. like() does a positive match only
( ie =~ only, not !~). Since like has side effects of $tests++, and
reporting failure,
one cannot expect a mismatch.
While there, I took out a chunk that runs:$text =~ $rex;
a quick benchmark showed it ~ same as: $text =~ /$rex/;
when $rex is Regex, and more general.
2. Concise.pm changes;
1. juggle var declarations to gather 'rendering state', and comments
3. added +=head2 structure and content (Stickiness) into OPTIONS pod
4. introduced new terms: 'renderings', 'rendering-state', 'line-style'
5. added -banner option
6. refined compile() pod - maybe muddled it with details.
7. added tests to concise.t
2. juggled options to prioritize by visual effect, and grouped with =head2
according to mutual exclusivity w others. This makes patch look bigger.
3. to explain stickiness simply, it seemd approprate to add some grouping
structure, rather than trying to enumerate in prose. I left 'stickiness'
somewhat general, in order to avoid forward refs to functions, ie compile..
4. suggests a glossary
I introduce new terminology: rendering, stickiness, rendering-state,
line-style
tried abortively to formalize current terms : style vs line-style,
'format', 'mode', etc..
I didnt finish - it felt too editorial.
5. my addition of a "B::Concise::compile($coderef)" banner was
something of a mistake - one additional subtlety that it exacerbates
(not mentioned in pod) is that it is printed only when compile itself
is called, not when the coderef it builds is called. This may surprise
folks.
The option helps solve user probs that could result.
New files:
ext/B/t/OptreeCheck.pm. contains apparattus for use in optree_*.t
optree_check.t tests the apparatus itself.
optree_concise.t tests various Concise options and output.
optree_sort.t tests Dave Mitchell's recent INPLACE optimization.
optree_varinit.ttests Rafael's recent my $var=undef optimiations.
optree_samples.t various looks at simple code constructs.
assumptions:
moving common code to ext/B/t/OptreeCheck is 'allowed' (no grumbles
so far!)
torture testing, test-dev support, QA are the reasons to get GRAND,
cmd-line argument handling is a GOOD WAY to invoke torture tests,
support test-dev.
would require Getopt::Std be acceptable in a CORE test ?
I can well imagine that this should be on CPAN, not in CORE,
but im unsure how (or whether) add-on tests can/should attempt
to use outside facilities. For the time-being at least, it might be
core-able, as a means to further ends (more optimizations ?)
btw, heres a trivial test-script, should you wish to play with the patch.
[EMAIL PROTECTED] bc5]$ more toptree.sh
function runset {
echo $*
./perl -w -Ilib ext/B/t/optree_check.t$*
./perl -w -Ilib ext/B/t/optree_samples.t$*
./perl -w -Ilib ext/B/t/optree_concise.t$*
./perl -w -Ilib ext/B/t/optree_sort.t$*
./perl -w -Ilib ext/B/t/optree_varinit.t$*
echo $*
}
# try these too.
#runset selftest # has errs
#runset testmode=cross# use wrong t,nt purposely - has errors
#runset testmode=cross selftest
runset $*
./perl -w -Ilib ext/B/t/optree_samples.thelp
I welcome your comments, MACRO and MICRO.
jimc
concise-tests.patch.gz
Description: application/gzip
Re: Behaviour of PMCs on assignment
Togos <[EMAIL PROTECTED]> wrote: > $I1 = $I2 + $I3 > $P1 = $P2 + $P3 > Which, of course, doesn't work. But this is what > languages like Python or Ruby would expect to be able > to do, as they don't need Perl's fancy variable > objects -- a register is good enough. > sementics of That and other arguments are of course all correct. I just have the gut feeling that having both opcode and vtable variants blows core size up to an isane value. Can someone calculate opcode count (math, logical, bitwise...) and needed vtables so that we can estimate the increase. leo
Re: New SDL Parrot Bindings Underway
Hi, On Tuesday 30 March 2004 09:33, chromatic wrote: > Hi all, > > With the improved object system in place, I've been porting the existing > SDL Parrot bindings. Here's a sample program that draws the friendly > blue rectangle again: > > .pcc_sub _main non_prototyped, @MAIN > load_bytecode "library/sdl_app.imc" > load_bytecode "library/sdl_rect.imc" > load_bytecode "library/sdl_color.imc" > > .sym pmc app > .sym int app_type > > find_type app_type, 'SDL::App' > new app, app_type > > .sym pmc args > new args, .PerlHash > set args['height'], 480 > set args['width'], 640 > set args['bpp'], 0 > set args['flags'],1 > > app.'_new'( args ) > > .sym pmc rect > .sym int rect_type > > find_type rect_type, 'SDL::Rect' > new rect, rect_type > > new args, .PerlHash > set args['height'], 100 > set args['width'], 100 > set args['x'], 270 > set args['y'], 190 > > rect.'_new'( args ) > > .sym pmc color > .sym int color_type > > find_type color_type, 'SDL::Color' > new color, color_type > > new args, .PerlHash > set args['r'], 0 > set args['g'], 0 > set args['b'], 255 > > color.'_new'( args ) > > app.'_fill_rect'( rect, color ) > app.'_update_rect'( rect ) > > sleep 2 > > app.'_quit'() > end > .end > > As you can see, this is a lot simpler and quite a bit cleaner. I'll add > some documentation, port the existing examples to the new code, and > check it in. Why are you using an underscore in front of all method and label names? They are indicating global labels; it is not necessary to use them for method names. > Any preferences whether these files are 'library/sdl_rect.imc' or > 'library/sdl/rect.imc', by the way? I vote for library/SDL/*.imc, because this is consistent with the original C API file naming scheme. > -- c jens
Re: [perl #28079] [PATCH] Warnings fix
Adam Thomason <[EMAIL PROTECTED]> wrote: > Attached patch fixes a number of cast warnings issued by Intel C++ 8.0. > This greatly reduces the noise generated by the icc-using tinderbox. Thanks, applied. except for one line which is now: jit_info->arena.fixups->param.fptr = D2FPTR(addr); leo
Re: Parrot on Alpha/OpenBSD
On Sun, Mar 28, 2004 at 09:18:16PM +0200, Marcus Thiesen wrote: > He has a list of his machines in a Wiki (http://wiki.thinknow.de/), it is > German but I guess that the platform names are quite international. If you're > interested in a specific platform test just tell me and I'll try to get a > timeslot, as he doesn't run his machines 24/7 and they're all reachable only > via IPv6. Oooh. IodVax. OpenBSD on vax But it looks like that he'll need to implement his "bigger harddisk" TODO before parrot could test on that. Mmm. ssh over IPv6. Seems to work from here. Only this is the only IPv6 host that I have a shell account on. Nicholas Clark
Re: [BUG] another GC-related bug
Jens Rieks <[EMAIL PROTECTED]> wrote: > tar xzf err13.tgz > cd err13 >=2E./parrot languages/EBNF/main.imc ebnf/precedence1.ebnf > chrashes, running parrot with -G works. Can you look again please. It's still crashing but runs much further now. > jens leo
[perl #28093] delete_keyed of OrderedHash
# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #28093] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=28093 > Hi, this bug was biting me when trying to undefine macros in Parrot m4. After deleting a value, the OrderedHash gets confused when fetching values that still should be stored in the hash. Especially I got a 'PerlUndef' for the last inserted value. The cause was that the internal PerlArray gets spliced upon deletion of values. This messes up the mapping of the indexes stored in the PerlHash to the values stored in the PerlArray. The fix is not to do a delete in the PerlArray, but to overwrite the value with a PerlUndef. CU, Bernhard -- /* [EMAIL PROTECTED] */ +++ NEU bei GMX und erstmalig in Deutschland: TÃV-geprÃfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz orderedhash_20040330.patch Description: Binary data
Tinderbox "aniani" brocken
Tinderbox "aniani" is not working with the latest copy. I checked the other boxes and they seem fine. Part of the log: == about to cvs checkout parrot: /home/perlcvs: no such repository cvs checkout: authorization failed: server cvs.perl.org rejected access to /home/perlcvs for user anonymous cvs checkout: used empty password; try "cvs login" with a real password cvs checkout complete About to run build command: perl Configure.pl --defaults Parrot Version 0.0.9 Configure 2.0 Copyright (C) 2001-2002 Yet Another Society == --Abhijit Abhijit A. Mahabal http://www.cs.indiana.edu/~amahabal/
Some new classes
I just checked in stub code for the PMCArray and StringArray classes. Ultimately they should be auto-resizeable, PMC or String only arrays, though right now they aren't. (They wrap PerlArray right now, so they're far from efficient, but at least they're in to be used) Integer and Float arrays should probably go in, and we should add in the non-auto-resizing versions as well. Abusing these so they aren't just virtual wrappers, and are actually efficient (as they can all be done as a plain C array of pointers or values--they don't have to be, and probably shouldn't be, sparse) would certainly be a Good Thing. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: [BUG] another GC-related bug
Hi, On Tuesday 30 March 2004 17:03, Leopold Toetsch wrote: > Jens Rieks <[EMAIL PROTECTED]> wrote: > > tar xzf err13.tgz > > cd err13 > >=2E./parrot languages/EBNF/main.imc ebnf/precedence1.ebnf > > > > chrashes, running parrot with -G works. > > Can you look again please. It's still crashing but runs much further now. It is still crashing at the same (C code) point, but the bug is triggered later. I think that it is related to the heavy string usage of the parser. Running parrot with tracing enabled will crash it earlier than without. ../parrot -t languages/EBNF/main.imc ebnf/precedence1.ebnf 2>/dev/null GC GC GC GC DOD GC '(*' = code=10 ebnf/precedence1.ebnf:1:1 debug: calling EBNF::Parser::parseCommentSymbol ebnf/precedence1.ebnf:1:1 debug: comment start DOD DOD GC ebnf/precedence1.ebnf:1:19 debug: comment end DOD ' ' = code=1 '(*' = code=10 ebnf/precedence1.ebnf:2:1 debug: calling EBNF::Parser::parseCommentSymbol ebnf/precedence1.ebnf:2:1 debug: comment start DOD GC Speicherzugriffsfehler (DOD and GC should be printed to stderr, should'nt it?) gdb ../parrot [snip] (gdb) r languages/EBNF/main.imc ebnf/precedence1.ebnf Starting program: /home/jrieks/projekte/parrot/parrot languages/EBNF/main.imc ebnf/precedence1.ebnf [New Thread 16384 (LWP 12554)] [New Thread 32769 (LWP 12556)] [New Thread 16386 (LWP 12557)] [New Thread 32771 (LWP 12558)] '(*' = code=10 ebnf/precedence1.ebnf:1:1 debug: calling EBNF::Parser::parseCommentSymbol ebnf/precedence1.ebnf:1:1 debug: comment start ebnf/precedence1.ebnf:1:19 debug: comment end ' ' = code=1 '(*' = code=10 ebnf/precedence1.ebnf:2:1 debug: calling EBNF::Parser::parseCommentSymbol ebnf/precedence1.ebnf:2:1 debug: comment start ebnf/precedence1.ebnf:2:33 debug: comment end ' ' = code=1 'a' = code=3 '=' = code=13 ebnf/precedence1.ebnf:3:2 debug: Atom::created called for class EBNF::Sequence ebnf/precedence1.ebnf:3:2 debug: calling EBNF::Sequence::pushTerminal( 'a' ) ebnf/precedence1.ebnf:3:1 debug: end of terminal 'a' ebnf/precedence1.ebnf:3:2 debug: calling EBNF::Parser::definingSymbol ebnf/precedence1.ebnf:3:2 debug: Atom::created called for class EBNF::MetaIdentifier ebnf/precedence1.ebnf:3:2 debug: defining meta-identifier 'a' ebnf/precedence1.ebnf:3:2 debug: Atom::newTarget called for class EBNF::MetaIdentifier ebnf/precedence1.ebnf:3:2 debug: setTarget = EBNF::SingleDefinition ebnf/precedence1.ebnf:3:2 debug: Atom::newTarget called for class EBNF::SingleDefinition 'Q' = code=3 '|' = code=14 ebnf/precedence1.ebnf:3:4 debug: calling EBNF::DefinitionsList::pushTerminal( 'Q' ) ebnf/precedence1.ebnf:3:3 debug: end of terminal 'Q' ebnf/precedence1.ebnf:3:4 debug: calling EBNF::DefinitionsList::definitionSeperator ebnf/precedence1.ebnf:3:4 debug: Atom::newTarget called for class EBNF::DefinitionsList ebnf/precedence1.ebnf:3:4 debug: setTarget = EBNF::SingleDefinition 'x' = code=3 ',' = code=12 ebnf/precedence1.ebnf:3:6 debug: calling EBNF::SingleDefinition::pushTerminal( 'x' ) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 12554)] 0x080c0945 in pobject_lives (interpreter=0x82193d0, obj=0x40205120) at src/dod.c:141 141 if (*dod_flags & ((PObj_on_free_list_FLAG | PObj_live_FLAG) << nm)) (gdb) bt #0 0x080c0945 in pobject_lives (interpreter=0x82193d0, obj=0x40205120) at src/dod.c:141 #1 0x080b84c1 in list_mark (interpreter=0x82193d0, list=0x4109dd80) at src/list.c:1366 #2 0x0819d0cf in Parrot_Array_mark (interpreter=0x82193d0, pmc=0x40385ac0) at array.c:180 #3 0x080c0e48 in trace_children (interpreter=0x82193d0, current=0x40385ac0) at src/dod.c:382 #4 0x080c0b70 in trace_active_PMCs (interpreter=0x82193d0, trace_stack=1) at src/dod.c:300 #5 0x080c14d1 in Parrot_do_dod_run (interpreter=0x82193d0, flags=1) at src/dod.c:1029 #6 0x080bf884 in more_traceable_objects (interpreter=0x82193d0, pool=0x8239d20) at src/smallobject.c:110 #7 0x080bf916 in get_free_object (interpreter=0x82193d0, pool=0x8239d20) at src/smallobject.c:176 #8 0x080bfd60 in get_free_pmc (interpreter=0x82193d0, pool=0x8239d20) at src/headers.c:53 #9 0x08088226 in get_new_pmc_header (interpreter=0x82193d0, base_type=41, constant=0) at src/pmc.c:107 #10 0x0808847c in pmc_new_noinit (interpreter=0x82193d0, base_type=41) at src/pmc.c:214 #11 0x0808819c in pmc_new (interpreter=0x82193d0, base_type=41) at src/pmc.c:71 #12 0x080863fa in new_ret_continuation_pmc (interp=0x82193d0, address=0x8603404) at src/sub.c:433 #13 0x080c82ef in Parrot_invokecc (cur_opcode=0x8603400, interpreter=0x82193d0) at core.ops:430 #14 0x0808756d in runops_slow_core (interpreter=0x82193d0, pc=0x8603400) at src/runops_cores.c:146 #15 0x0807b5ed in runops_int (interpreter=0x82193d0, offset=0) at src/interpreter.c:833 #16 0x0807b68f in runops_ex (interpreter=0x82193d0, offset=0) at src/interpreter.c:863 #17 0x0807b854 in runops (interpreter=0x821
[perl #28087] [PATCH] wrong type for "status" in platform/win32/exec.c
# New Ticket Created by mrnobo1024
# Please include the string: [perl #28087]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28087 >
The second arg of GetExitCodeProcess should be a pointer to DWORD, not int,
this was causing a warning on mingw:
src/platform.c: In function `Parrot_Run_OS_Command':
src/platform.c:446: warning: passing arg 2 of `GetExitCodeProcess' from
incompatible pointer type
__
Do you Yahoo!?
Yahoo! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html--- config/gen/platform/win32/exec.c~ Wed Mar 3 16:06:08 2004
+++ config/gen/platform/win32/exec.cSat Mar 27 10:29:10 2004
@@ -4,7 +4,7 @@
*/
INTVAL
Parrot_Run_OS_Command(Parrot_Interp interpreter, STRING *command) {
-int status = 0;
+DWORD status = 0;
STARTUPINFO si;
PROCESS_INFORMATION pi;
int free_it = 0;
Re: Some new classes (dumper patch)
Hi, On Tuesday 30 March 2004 18:57, Dan Sugalski wrote: > I just checked in stub code for the PMCArray and StringArray classes. I've attached a patch for the data dumper. > Ultimately they should be auto-resizeable, PMC or String only arrays, > though right now they aren't. (They wrap PerlArray right now, so > they're far from efficient, but at least they're in to be used) > Integer and Float arrays should probably go in, and we should add in > the non-auto-resizing versions as well. > > Abusing these so they aren't just virtual wrappers, and are actually > efficient (as they can all be done as a plain C array of pointers or > values--they don't have to be, and probably shouldn't be, sparse) > would certainly be a Good Thing. The EBNF Parser is now using PMCArrays. jens Index: library/Data/Dumper/Default.imc === RCS file: /cvs/public/parrot/library/Data/Dumper/Default.imc,v retrieving revision 1.1 diff -u -w -r1.1 Default.imc --- library/Data/Dumper/Default.imc 14 Mar 2004 17:52:30 - 1.1 +++ library/Data/Dumper/Default.imc 30 Mar 2004 17:59:12 - @@ -248,9 +248,31 @@ .pcc_end_return .end +=item style."pmcPMCArray"( name, array ) + +Dumps an (PMC) Array. + +=cut + +.sub pmcPMCArray +S0 = "pmcPerlArray" +callmethod +.end + +=item style."pmcStringArray"( name, array ) + +Dumps an (string) Array. + +=cut + +.sub pmcStringArray +S0 = "pmcPerlArray" +callmethod +.end + =item style."pmcPerlArray"( name, array ) -Dumps an Array PMC. +Dumps an (Perl) Array. =cut @@ -267,7 +289,9 @@ (subindent, indent) = self."newIndent"() -print "PerlArray (size:" +typeof name2, array +print name2 +print " (size:" print array print ") ["
Re: [perl #28087] [PATCH] wrong type for "status" in platform/win32/exec.c
At 7:13 AM -0800 3/30/04, mrnobo1024 (via RT) wrote: The second arg of GetExitCodeProcess should be a pointer to DWORD, not int, this was causing a warning on mingw: src/platform.c: In function `Parrot_Run_OS_Command': src/platform.c:446: warning: passing arg 2 of `GetExitCodeProcess' from incompatible pointer type Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Some new classes (dumper patch)
At 7:02 PM +0100 3/30/04, Jens Rieks wrote: Hi, On Tuesday 30 March 2004 18:57, Dan Sugalski wrote: I just checked in stub code for the PMCArray and StringArray classes. I've attached a patch for the data dumper. Applied, thanks. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Fwd: TALK:4-5-04 "A (Grand?) Unified Theory of Storage Reclamation"
Local to Boston (as it's at MIT) but if anyone's in the area... (I may well go, but I'm not sure if I'll be able to do so) And no, I have no more detail than this. Forward begins= "A (Grand?) Unified Theory of Storage Reclamation" Speaker: David F. Bacon Host: Professor Martin Rinard Host Affiliation: Computer Architecture Group Date: 4-5-2004 Time: 3:30 PM - 5:00 PM Refreshments: 3:15 PM Location: Gates 7th Floor Lounge The two basic forms of automatic storage reclamation, tracing and = reference counting, were invented at the dawn of the high-level language = era over 40 years ago. Since then there have been many improvements and = optimizations, but all systems are based on one or the other of these = methods, which are uniformly viewed as being fundamentally different and = possessing very distinct performance properties. We have implemented = high-performance collectors of both types, and in the process observed = that the more we optimized them, the more similarly they behaved -- that - they seem to share some deep structure. We present a formulation of the two algorithms that shows that they are = in fact duals of each other. Intuitively, the difference is that = tracing operates on live objects, or "matter", while reference counting = operates on dead objects, or "anti-matter". For every operation by the = tracing collector, there is a precisely corresponding anti-operation by = the reference counting collector. Viewed in this light, we show that all high-performance collectors (for = example, deferred reference counting and generational collection) are in = fact hybrids of tracing and reference counting. We are developing a = uniform cost-model for the collectors to quantify the tradeoffs that - result from choosing different hybridizations of tracing and reference = counting. This will allow the correct scheme to be selected based on = system performance requirements and the expected properties of the = target application. Relevant URL(S): For more information please contact: Mary McDavitt, 617-253-9620, [EMAIL PROTECTED] ___ Seminars mailing list [EMAIL PROTECTED] http://lists.csail.mit.edu/mailman/listinfo/seminars
Re: [perl #28093] delete_keyed of OrderedHash
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > After deleting a value, the OrderedHash gets confused when fetching values > that still should be stored in the hash. Thanks, applied.
