Re: [DOCS] Documentation tools
> I've added the Perl modules for the docs tools to lib/Parrot/IO and > lib/Parrot/Docs. I've also added Pod-Simple (2.05) and Pod-Escapes > (1.03) which they use. I probably blinked.. but why are we including CPAN modules that we are not likely to change into the parrot repository? -R
[DOCS] Documentation tools
I've added the Perl modules for the docs tools to lib/Parrot/IO and lib/Parrot/Docs. I've also added Pod-Simple (2.05) and Pod-Escapes (1.03) which they use. Running perl tools/docs/write_docs.pl should build the html tree in docs/html. I'd be interested to know of any problems encountered. On the updating front, I finished examples and did the other *.c file directories (chartypes, encodings, io, pf, types). Now I think I'll look at classes. Mike
Re: Re: RT Cleanup
Andrew Dougherty wrote: On Wed, 4 Feb 2004, Steve Fink wrote: On Feb-02, Andrew Dougherty wrote: [EMAIL PROTECTED] 19184 languages/perl6/t/rx/call test error 1 years Keep this one open. The tests still fail. How recently did you check? I committed a reimplementation of perl6 regexes about a week ago. The above test still failed, but only due to a parrot memory corruption bug, and I committed something else the next day that coincidentally sidestepped the bug on my machine. It's probably a different bug than #19184, but here's what I just got for cd languages/perl6 make test (This is for perl5.00503, Solaris 8/SPARC, Sun Workshop compiler) Try cd languages/perl6 ./perl6 --force-grammar -e 1 # don't worry if it fails make test Except I never do 'make test' because, as you noticed, it takes forever to run. Use ./perl6 --test instead. (Or, in this case, maybe just ./perl6 --test t/rx/*.t) The slowest part of the perl6 compiler is simply loading in the Parse::RecDescent parser. That line loads it in once and reuses it for all the tests. I think nobody ever changed 'make test' to use it because if one test kills the process, then all remaining tests fail too. But perhaps I should have make test print at the very end: Hey, that took forever, didn't it? Maybe you should try using ./perl6 --test instead, as documented in [I forget where, and can't look it up right now]. t/rx/basic..Read on closed filehandle at P6C/TestCompiler.pm line 71. Use of uninitialized value at ../../lib/Parrot/Test.pm line 87. # Failed test (t/rx/basic.t at line 7) # got: 'error:imcc:main: Error reading source file t/rx/basic_1.pasm. # ' # expected: 'ok 1 # ok 2 # ok 3 # ok 4 # ok 5 # ok 6 # ok 7 # ok 8 # ok 9 # ' Odd... I'll take a look tonight, thanks. Finally, is it just me, or do these tests take a long time for everyone? Today, it took 21 minutes to run the perl6 test suite. While I appreciate the value of a comprehensive test suite, I wonder if there might be some way to speed things up a bit (apart from buying a faster machine, of course!) Oh, and the perl6 test suite is *far* from comprehensive. It's just slow.
Re: Alignment Issues with *ManagedStruct?
> "c" == chromatic <[EMAIL PROTECTED]> writes: c> I ran this program in lieu of the debugger: i recall an old trick i learned to get offsets into structs which would be easier to read than hex addresses: c> int main () c> { c> SDL_KeyboardEvent kbevent; c> printf( "0x%08X event\n", &kbevent ); c> printf( "0x%08X event.type\n", &kbevent.type ); printf( "%d event.type\n", (char *)&kbevent.type ) - (char *)&kbevent ; it can be made into a macro IIRC for ease of use. that could be done with a perl script for any structure and it could generate an offset map for the given environment. that map could be used by parrot to access members in a portable way. so the script would parse a structure, generate a set of those prints (with the right format output) and compile it with the same tools as parrot. run that little c program and save the output in a file. parrot reads that file and uses it as a name to offset map for that structure. want me to hack up this little script and c generation stuff? the hard part is parsing the struct so i would have to assume some simple format and not full c for the moment. the only thing needed by the parser is all the member names. uri -- Uri Guttman -- [EMAIL PROTECTED] http://www.stemsystems.com --Perl Consulting, Stem Development, Systems Architecture, Design and Coding- Search or Offer Perl Jobs http://jobs.perl.org
Re: Alignment Issues with *ManagedStruct?
On Wed, 2004-02-04 at 13:36, Leopold Toetsch wrote: > > As I understand it (and correct me if I'm wrong), SDL_keysym needs a > > byte of padding on my architecture within SDL_KeyboardEvent. > Brr. I don't know. I've to ask my debugger for that :) If you have > SDL_keysym alone, that needs 3 bytes additional alignment. But don't ask > me about the combined structure. Exactly my worry. Does it depend on the compiler? Architecture? Libraries? C specification? Phase of the moon? > But I'd say that there are four adjacent Uint8 taking one word, then is > another word (SDLkey sym). Or a structure starts aligned ... I ran this program in lieu of the debugger: #include #include #include int main () { SDL_KeyboardEvent kbevent; printf( "0x%08X event\n", &kbevent ); printf( "0x%08X event.type\n", &kbevent.type ); printf( "0x%08X event.which\n", &kbevent.which ); printf( "0x%08X event.state\n", &kbevent.state ); printf( "0x%08X event.keysym.scancode\n", &kbevent.keysym.scancode ); printf( "0x%08X event.keysym.sym\n", &kbevent.keysym.sym ); printf( "0x%08X event.keysym.mod\n", &kbevent.keysym.mod ); printf( "0x%08X event.keysym.unicode\n", &kbevent.keysym.unicode ); return(0); } Here's the output on my machine: 0x77E8 event 0x77E8 event.type 0x77E9 event.which 0x77EA event.state 0x77EC event.keysym.scancode 0x77F0 event.keysym.sym 0x77F4 event.keysym.mod 0x77F8 event.keysym.unicode > We don't have a notion of nested structures. They could go just inline, > i.e. without extra syntax. Pointers to structures are of course missing > too, that's a different thingy. Inlining's not a problem; it only has to be done once. This is one spot where C's lack of abstraction actually helps. :) -- c
[CVS ci] new errors{on,off} opcodes
This ... .include "errors.pasm" errorsoff .PARROT_ERRORS_GLOBALS_FLAG find_global P1, "no_such_global" defined I0, P1 ... allows working around current exception handler (COW) bug and is more perlish then the default pie-thonish behavior, which is: just throw an exception (the default still). leo
Re: Alignment Issues with *ManagedStruct?
Chromatic <[EMAIL PROTECTED]> wrote: > In this case, it doesn't, as the struct I'm emulating is: > typedef struct { > Uint8 type; /* SDL_KEYDOWN or SDL_KEYUP */ > Uint8 which;/* The keyboard device index */ > Uint8 state;/* SDL_PRESSED or SDL_RELEASED */ > SDL_keysym keysym; > } SDL_KeyboardEvent; > SDL_keysym itself is a struct: > typedef struct { > Uint8 scancode; /* hardware specific */ > SDLKey sym; /* SDL virtual keysym */ > SDLMod mod; /* current key modifiers */ > Uint16 unicode; /* translated character */ > } SDL_keysym; > SDLKey and SDLMod are both enums. > As I understand it (and correct me if I'm wrong), SDL_keysym needs a > byte of padding on my architecture within SDL_KeyboardEvent. Brr. I don't know. I've to ask my debugger for that :) If you have SDL_keysym alone, that needs 3 bytes additional alignment. But don't ask me about the combined structure. But I'd say that there are four adjacent Uint8 taking one word, then is another word (SDLkey sym). Or a structure starts aligned ... We don't have a notion of nested structures. They could go just inline, i.e. without extra syntax. Pointers to structures are of course missing too, that's a different thingy. > I can add > that padding manually, but I'm not convinced that'll be portable to > different architectures. Automatic alignment based on the data type sizes is for sure better. > -- c leo
Re: RT Cleanup
On Wed, 4 Feb 2004, Steve Fink wrote: > On Feb-02, Andrew Dougherty wrote: > > [EMAIL PROTECTED] 19184 languages/perl6/t/rx/call test error > >1 years > > > > Keep this one open. The tests still fail. > > How recently did you check? I committed a reimplementation of perl6 > regexes about a week ago. The above test still failed, but only due to > a parrot memory corruption bug, and I committed something else the > next day that coincidentally sidestepped the bug on my machine. It's probably a different bug than #19184, but here's what I just got for cd languages/perl6 make test (This is for perl5.00503, Solaris 8/SPARC, Sun Workshop compiler) Failed Test Status Wstat Total Fail Failed List of failed --- t/rx/basic.t 8 2048 88 100.00% 1-8 t/rx/call.t 2 512 22 100.00% 1-2 t/rx/special.t2 512 22 100.00% 1-2 All of the test failures look basically like this: t/rx/basic..Read on closed filehandle at P6C/TestCompiler.pm line 71. Use of uninitialized value at ../../lib/Parrot/Test.pm line 87. # Failed test (t/rx/basic.t at line 7) # got: 'error:imcc:main: Error reading source file t/rx/basic_1.pasm. # ' # expected: 'ok 1 # ok 2 # ok 3 # ok 4 # ok 5 # ok 6 # ok 7 # ok 8 # ok 9 # ' Finally, is it just me, or do these tests take a long time for everyone? Today, it took 21 minutes to run the perl6 test suite. While I appreciate the value of a comprehensive test suite, I wonder if there might be some way to speed things up a bit (apart from buying a faster machine, of course!) -- Andy Dougherty [EMAIL PROTECTED]
Re: Alignment Issues with *ManagedStruct?
On Wed, 2004-02-04 at 00:52, Leopold Toetsch wrote: > Pushing zero as offset should do The Right Thing, that is proper > aligning the item. Tighter packed structures can be achieved with > explicit offset parameters. In this case, it doesn't, as the struct I'm emulating is: typedef struct { Uint8 type; /* SDL_KEYDOWN or SDL_KEYUP */ Uint8 which;/* The keyboard device index */ Uint8 state;/* SDL_PRESSED or SDL_RELEASED */ SDL_keysym keysym; } SDL_KeyboardEvent; SDL_keysym itself is a struct: typedef struct { Uint8 scancode; /* hardware specific */ SDLKey sym; /* SDL virtual keysym */ SDLMod mod; /* current key modifiers */ Uint16 unicode; /* translated character */ } SDL_keysym; SDLKey and SDLMod are both enums. As I understand it (and correct me if I'm wrong), SDL_keysym needs a byte of padding on my architecture within SDL_KeyboardEvent. I can add that padding manually, but I'm not convinced that'll be portable to different architectures. That's the kind of padding I'd like unmanagedstruct.pmc to be able to do for me. > > Is this one for the TODO list, or did I catch a pumpking in good > > humours? > Takers wanted :) I'm happy to submit this as a TODO if I have the story straight. -- c
Re: crash in HEAD
Sterling Hughes writes: > Hey, > > The following PIR crashes CVS head: > > .sub _main > $P0 = new PerlUndef > .sym PerlUndef i > i = new PerlUndef > i = 0 > L0: > $I0 = 0 > $P1 = new PerlUndef > $P1 = 10 > unless i < $P1 goto L3 > $I0 = 1 > L3: > if $I0 goto L1 > goto L2 > L1: > print "hello\n" > $P0 = i > i = i + 1 > goto L0 > L2: > .end That crashes for the same reason that this crashes (or should crash, at least): .sub _main .end Because you're missing an C op. Luke > > Which is the php code generation of a for loop: > > for ($i = 0; $i < 10; $i++) { > echo "hello\n"; > } > > This has previously worked - do any changes need to be applied to the > code in order to have it working again? Is this just a current parrot > bug? > > (doesn't matter if you run this with the slowcore or the jit btw) > > -Sterling > > -- > "Reductionists like to take things apart. The rest of us are > just trying to get it together." > - Larry Wall, Programming Perl, 3rd Edition
Re: OO inheritance in a hacker style
On Wed, Feb 04, 2004 at 01:30:44AM -0500, Joseph Ryan wrote: > >Whether it should actually be in the language is up for debate. I'd say > >that if you need to do this with any frequency whatsoever, you're not > >thinking about roles right. A good example might be in order... :-) > > Well, what if the two classes you want to inherit from weren't > designed with roles in mind? For instance, there might be two > CPAN modules that each have a dozen methods that you want to > inherit, but they each have 1 that overlap whose conflict you > want to easily resolve. Same way you do it now. package Foo; use base qw(This That); sub conflicting_inherited_method { goto &{That->can("conflicting_inherited_method")}; } -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Cheating is often more efficient. - Seven of Nine
Re: RT Cleanup
On Feb-02, Andrew Dougherty wrote: > [EMAIL PROTECTED] 19184 languages/perl6/t/rx/call test error > 1 years > > Keep this one open. The tests still fail. How recently did you check? I committed a reimplementation of perl6 regexes about a week ago. The above test still failed, but only due to a parrot memory corruption bug, and I committed something else the next day that coincidentally sidestepped the bug on my machine. I would find it easy to believe that it is still happening on other machines. Could you give it a try and let me know? All perl6 tests should be passing right now.
crash in HEAD
Hey, The following PIR crashes CVS head: .sub _main $P0 = new PerlUndef .sym PerlUndef i i = new PerlUndef i = 0 L0: $I0 = 0 $P1 = new PerlUndef $P1 = 10 unless i < $P1 goto L3 $I0 = 1 L3: if $I0 goto L1 goto L2 L1: print "hello\n" $P0 = i i = i + 1 goto L0 L2: .end Which is the php code generation of a for loop: for ($i = 0; $i < 10; $i++) { echo "hello\n"; } This has previously worked - do any changes need to be applied to the code in order to have it working again? Is this just a current parrot bug? (doesn't matter if you run this with the slowcore or the jit btw) -Sterling -- "Reductionists like to take things apart. The rest of us are just trying to get it together." - Larry Wall, Programming Perl, 3rd Edition
Re: Some minor decisions and timetables
Leopold Toetsch writes: > I'd add some syntax additions and some notes: > > - Pn above is a NameSpace PMC, derived from Hash > - an interpreter has a current namespace > - located in the context, so that its restored after sub calls > >getinterp P2 >find_global Pn, P2["."] # get current NS >find_global Pz, P2[".."] # get parent NS >set Pz, Pn[".."] # same >find_global Py, P2["/"] # get root of namespaces >find_global Px, Pn["Foo"; "Bar"] # NS of Module Foo::Bar >find_global Pv, Pn["Foo"; "Bar"], "baz" # $Foo::Bar::baz var >find_global Pv, Pn["Foo"; "Bar"; "baz" ] # same >set P2["."], Px # switch current NS to Foo::Bar >find_global Pv, Pn["/"; "java"; "some"; "glob" ] # /java.some.glob ÂMe gusta mucho! This system allows neato things like anonymous namespaces, too. I was thinking of something similar for classes. An object holds a reference to a class PMC which is used to fetch its methods. This allows different metaclasses (which are, again, required for Perl 6[1]). Maybe said class PMC is, by default, just an anonymous namespace PMC. Luke
Re: Some minor decisions and timetables
Dan Sugalski <[EMAIL PROTECTED]> wrote: > Okay, here's a quick scoop and status. > *) I'd like to shoot for a Feb 14th release. Names wanted. (I'm > partial to the bleeding heart release, but not that partial) I had planned towards Feb 29th. A nice dated too this year. > *) Namespaces are going to use the: >find_global Px, [key; key; key], final_name_string > format. I may add in a dummy: >find_global Px, Pn[key], final_name > in the mean time just to make things work out. Pn will get ignored. > If you have the key and leave out the element, it returns a PMC that > represents that piece of the namespace. Yes, I know there are > objections, but it's a matter of taste and space savings. We'll cope. I'd add some syntax additions and some notes: - Pn above is a NameSpace PMC, derived from Hash - an interpreter has a current namespace - located in the context, so that its restored after sub calls getinterp P2 find_global Pn, P2["."] # get current NS find_global Pz, P2[".."] # get parent NS set Pz, Pn[".."] # same find_global Py, P2["/"] # get root of namespaces find_global Px, Pn["Foo"; "Bar"] # NS of Module Foo::Bar find_global Pv, Pn["Foo"; "Bar"], "baz" # $Foo::Bar::baz var find_global Pv, Pn["Foo"; "Bar"; "baz" ] # same set P2["."], Px # switch current NS to Foo::Bar find_global Pv, Pn["/"; "java"; "some"; "glob" ] # /java.some.glob > *) Just constant keys for names right now. We'll work on dynamic keys > later, if we don't already have 'em in. Dynamic keys are (still) working ;) > *) I like Tim's namespace idea (prepending the language) and we'll > put that in, though probably for the next release. That's not really difficult, if the namespace PMC handles above directory-like traversal keys. leo
Re: [perl #25960] [PATCH] COWed stack bug (was IMCC - PerlArray getting trounced)
Matt Fowles <[EMAIL PROTECTED]> wrote: > This patch make the problem case submitted by Jeff Clites work. All > tests pass, and his sample has been added to the tests. > struct RegisterChunkBuf* top = stack->top; > if (top->used > 1) { > +top->used--; Thanks for the patch *but*: That's changing the COWed copy. It does the right thing for the test case but is still wrong. As already stated: - COWed buffers need distinct buffer headers pointing to the same buffer memory - unCOWing (regstack_copy_chunk) allocates new buffer memory and resets the COW flag Its like string.c: make_COW_reference() and unmake_COW() This is needed for the register stacks and for stacks.c too. leo
Re: OO inheritance in a hacker style
Joseph Ryan writes: > >It's surely possible by modifying that class's DISPATCH. > > > >Whether it should actually be in the language is up for debate. I'd say > >that if you need to do this with any frequency whatsoever, you're not > >thinking about roles right. A good example might be in order... :-) > > > > > > Well, what if the two classes you want to inherit from weren't > designed with roles in mind? For instance, there might be two > CPAN modules that each have a dozen methods that you want to > inherit, but they each have 1 that overlap whose conflict you > want to easily resolve. C doesn't help you there. That would presumably forget I methods, leaving you with none. That doesn't sound too useful. If you could add a SomeClass:: on the front of the method, like: class Foo is Bar is Baz { forget Bar::frobnicate; } That looks backwards. It would certainly make more sense to specify which method you want to use, as opposed to specifying all the methods but the one you want to use. A syntax that is the opposite of forget -- one that lets you specify which method to use without typing that parameter list twice -- might be useful, but it's trivial enough to, er, forget for now. I wonder whether it's possible to say: class Foo is Bar is Baz { method frobnicate := &Baz::frobnicate; } I know my syntax there isn't right quite. :-) > Besides, "the user is not thinking about XXX right" sounds like we > need to give a ++ to the pythonometer ;) Let's say someone came on here and asked how to use regexes to make a socket connection. Surely "the user is not thinking about regexes right"... or sockets. Luke
Parrot Embedding Questions
Hi, I would like to add Parrot as a scripting engine for a software project. Embedding it is no problem, but I was wondering if the current implementation supports the embedder to provide functions to the Parrot bytecode applications? The idea is that I would like to access C functions the embedder provides in Perl(5/6) or any other language that will become Parrot bytecode. Is that possible in the present state or will something like that be implemented in the future? Looking at the way Parrot works it doesn't seem possible, but I might have missed something. Thanks in advance. -- Mattias Nordstrom Partner, Systems Design Realnode Ltd [EMAIL PROTECTED] http://www.realnode.com/
[perl #25960] [PATCH] COWed stack bug (was IMCC - PerlArray getting trounced)
# New Ticket Created by Matt Fowles # Please include the string: [perl #25960] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=25960 > All~ This patch make the problem case submitted by Jeff Clites work. All tests pass, and his sample has been added to the tests. While I am not certain that this is the correct way to solve the problem, it seems good to me. Matt Index: imcc/t/syn/pcc.t === RCS file: /cvs/public/parrot/imcc/t/syn/pcc.t,v retrieving revision 1.31 diff -u -r1.31 pcc.t --- imcc/t/syn/pcc.t 20 Jan 2004 01:50:47 - 1.31 +++ imcc/t/syn/pcc.t 4 Feb 2004 02:55:11 - @@ -1,6 +1,6 @@ #!perl use strict; -use TestCompiler tests => 34; +use TestCompiler tests => 35; ## # Parrot Calling Conventions @@ -1389,3 +1389,30 @@ 42.00 OUT } + +output_is(<<'CODE', <<'OUT', "COW handling on register stacks"); +.pcc_sub _main prototyped + $P1 = new PerlUndef + print $P1 + print ":" + _outer() + print $P1 + print "\n" + end +.end +.pcc_sub _outer prototyped + _inner() + .pcc_begin_return + .pcc_end_return +.end +.pcc_sub _inner prototyped + newsub $P1, .Exception_Handler, _ignore + .pcc_begin_return + .pcc_end_return +.end +.sub _ignore + noop +.end +CODE +: +OUT Index: src/register.c === RCS file: /cvs/public/parrot/src/register.c,v retrieving revision 1.41 diff -u -r1.41 register.c --- src/register.c 25 Jan 2004 19:33:27 - 1.41 +++ src/register.c 4 Feb 2004 02:55:13 - @@ -292,11 +292,11 @@ { struct RegisterChunkBuf* top = stack->top; if (top->used > 1) { +top->used--; /* Before we change anything, is this a read-only stack? */ if (PObj_COW_TEST((PObj*)top)) top = stack->top = regstack_copy_chunk(interpreter, stack->top, stack); -top->used--; } else { /* XXX: If this isn't marked COW, we should keep it around to
Re: Some minor decisions and timetables
On Tue, Feb 03, 2004 at 09:27:31PM +, Harry Jackson wrote: > Dan Sugalski wrote: > > > >*) I'll try and patch up the docs, and I'll concentrate on the PDDs, but > >any help on them is greatly appreciated. *Especially* IMCC docs. > > Do we need an NCI section in the IMCC.faq. If the vote is yes I do not > mind knocking something up. I'd vote yes! Thanks. Tim.
Re: [perl #25948] IMCC doesn't trace lifetimes properly
Dan Sugalski <[EMAIL PROTECTED]> wrote: > the following code trips up IMCC's temp lifetime tracing: Fix committed. leo
Re: Alignment Issues with *ManagedStruct?
Chromatic <[EMAIL PROTECTED]> wrote: > set layout['member'], .DATATYPE_INT > push layout, 0 > push layout, 0 Pushing zero as offset should do The Right Thing, that is proper aligning the item. Tighter packed structures can be achieved with explicit offset parameters. Its basically an one-liner in unmanagedstruct.pmc:205 if (offs == 0 && toff % data_size) advance (offs, toff) to data_size alignment > Is this one for the TODO list, or did I catch a pumpking in good > humours? Takers wanted :) > -- c leo