Re: [Patch] Win32 thread primitives
threads_4 is testing killing threads. This is achieved by scheduling a
terminate event to the running interpreter. This can only succeed, if the
event system is running too.
see src/events.c/Parrot_new_terinate_event()
Though thr_windows.h doesn't contain error checking for now, it luckily
fails when the killed thread returns from runops and tries to LOCK the
interpreter_array_mutex. But before that the thread of the main interp had
time to call Parrot_really_destroy, loop interpreter_array, and free
interpreter_array_mutex. Here I see two solutions:
A) do not free the array and mutex asscociated with it at all; those are
global, malloced once, have no destructor, would it be a memory leak?
B) the very last thread do the work, it iterates thru array and if all tids
are null(except itself), free array and mutex.
On the another hand I didnt see that interpreters task queues and mutexes of
the shared pmc's(sub and Interp, probably) were freed up anywhere. It's that
normal?
And on the third hand, if I understood the code correctly ...
src/threads.c: 40: thread_func()
src/threads.c: 53: interpreter-thread_data-state |= THREAD_STATE_FINISHED;
src/threads.c: 312: pt_thread_join ()
src/threads.c: 321: if (interpreter-thread_data-state ==
THREAD_STATE_JOINABLE ||
src/threads.c: 322: interpreter-thread_data-state ==
THREAD_STATE_FINISHED) {
src/threads.c: 453: detach()
src/threads.c: 462: if (interpreter-thread_data-state ==
THREAD_STATE_JOINABLE ||
src/threads.c: 463: interpreter-thread_data-state ==
THREAD_STATE_FINISHED) {
lines 322, 463 never hold true, because of line 53. So pt_thread_join,
detach are never able do their work on threads that have runops-ed.
Argh, yes. Can you just #undef the CONST after including the windows.h?
Ok, done it.
win32_threads.patch
Description: Binary data
Re: [Patch] Win32 thread primitives
Vladimir Lipsky wrote:
threads_4 is testing killing threads. This is achieved by scheduling a
terminate event to the running interpreter. This can only succeed, if
the event system is running too.
see src/events.c/Parrot_new_terinate_event()
Though thr_windows.h doesn't contain error checking for now, it luckily
fails when the killed thread returns from runops and tries to LOCK the
interpreter_array_mutex. But before that the thread of the main interp
had time to call Parrot_really_destroy, loop interpreter_array, and free
interpreter_array_mutex.
This case can be considered as a programmers error (we should guard
against it if possible, though). When the main or first interpreter
terminates the packfile with the opcodes is destroyed. A still running
thread wouldn't have any more code to execute.
... Here I see two solutions:
A) do not free the array and mutex asscociated with it at all; those are
global, malloced once, have no destructor, would it be a memory leak?
B) the very last thread do the work, it iterates thru array and if all
tids are null(except itself), free array and mutex.
B) if any, but it's not only freeing the interpreter array. The last one
has to do all the work that the main interpreter should have done.
See also src/inter_create.c:Parrot_really_destroy()
On the another hand I didnt see that interpreters task queues and
mutexes of the shared pmc's(sub and Interp, probably) were freed up
anywhere. It's that normal?
There are presumably some more leaks in the code, yes - err no ;-)
And on the third hand, if I understood the code correctly ...
src/threads.c: 40: thread_func()
src/threads.c: 53: interpreter-thread_data-state |=
THREAD_STATE_FINISHED;
src/threads.c: 312: pt_thread_join ()
src/threads.c: 321: if (interpreter-thread_data-state ==
THREAD_STATE_JOINABLE ||
src/threads.c: 322: interpreter-thread_data-state ==
THREAD_STATE_FINISHED) {
src/threads.c: 453: detach()
src/threads.c: 462: if (interpreter-thread_data-state ==
THREAD_STATE_JOINABLE ||
src/threads.c: 463: interpreter-thread_data-state ==
THREAD_STATE_FINISHED) {
lines 322, 463 never hold true, because of line 53. So pt_thread_join,
detach are never able do their work on threads that have runops-ed.
I don't think so: in line 47 the thread enters the runloop, state is
JOINABLE (except when created detached). Another thread, which has the
TID of the thread can now join or detach it. Only when the thread
leaves its runloop, it's state is set to FINISHED. So at e.g. line 322
it can be JOINABLE (still running) or FINISHED. The JOIN() then gets the
return result, which possibly causes the caller to wait for the thread
to finish.
Argh, yes. Can you just #undef the CONST after including the windows.h?
Ok, done it.
Good.
Thanks, applied
leo
[svn meta] sorry
Sorry, I forgot to attach necessary legal bits to the last two patches I applied: new n_arithmetics tests Courtesy of Bob Rogers [Patch] Win32 thread primitives Courtesy of Vladimir Lipsky leo
Re: [Patch] Win32 thread primitives
And on the third hand, if I understood the code correctly ...
src/threads.c: 40: thread_func()
src/threads.c: 53: interpreter-thread_data-state |=
THREAD_STATE_FINISHED;
src/threads.c: 312: pt_thread_join ()
src/threads.c: 321: if (interpreter-thread_data-state ==
THREAD_STATE_JOINABLE ||
src/threads.c: 322: interpreter-thread_data-state ==
THREAD_STATE_FINISHED) {
src/threads.c: 453: detach()
src/threads.c: 462: if (interpreter-thread_data-state ==
THREAD_STATE_JOINABLE ||
src/threads.c: 463: interpreter-thread_data-state ==
THREAD_STATE_FINISHED) {
lines 322, 463 never hold true, because of line 53. So pt_thread_join,
detach are never able do their work on threads that have runops-ed.
I don't think so: in line 47 the thread enters the runloop, state is
JOINABLE (except when created detached). Another thread, which has the TID
of the thread can now join or detach it. Only when the thread leaves its
runloop, it's state is set to FINISHED. So at e.g. line 322
It's state is set to PREVIOUS_STATE+FINISHED
So it's never equal to just FINISHED
src/threads.c: 53: interpreter-thread_data-state |=
THREAD_STATE_FINISHED;
src/threads.c: 322: interpreter-thread_data-state ==
THREAD_STATE_FINISHED) {
Typo or what?
Re: [Patch] Win32 thread primitives
Vladimir Lipsky wrote: It's state is set to PREVIOUS_STATE+FINISHED So it's never equal to just FINISHED Ah, Yep. Works for JOINABLE, which is 0, but ... Typo or what? Inexact ;-) leo
[PROPOSAL] call syntax abstraction
Below is a POD that tries to the describe an extensible calling scheme that should cover most of our targets HLLs call syntax. Comments welcome, leo =head1 TITLE Calling convention abstraction =head1 ABSTRACT The current Parrot calling conventions as described in Fdocs/pdds/pdd03_calling_conventions.pod are not covering major parts of our target languages. The scheme isn't extensible and uses a lot of resources (opcodes, runloop dispatches, registers) to achieve it's work. This proposal describes an abstract, extensible, and more efficient alternative to pdd03. =head1 DESCRIPTIOON All the work related to function calls is done by dedicated opcodes. No registers are reserved currently, but during the transition phase and possibly thereafter, registers are/may be used. This will be specified after the implementation of the compatibly scheme is completed. =head2 Opcodes New Bvariable argument list opcodes: op args(inconst STR, ...)# call arguments op results(inconst STR, ...) # get return results op params(inconst STR, ...) # function parameters op returns(inconst STR, ...) # function return op yields(inconst STR, ...) # coroutine yield values The constant STR argument is a signature string denoting successional arguments to the opcode. An opcode to define return context: op results(inconst INT) # define return context And: op argcI(out INT)# amount of I args or returns op argcP(out INT)# amount of P op argcS(out INT)# amount of S op argcN(out INT)# amount of N =head2 Call opcodes cleanup While it's not strictly needed it's highly desirable to get rid of the current implicit register usage in call related opcodes. See also: Ihttp://xrl.us/fycc for an older discussion on that topic. op invoke(in PMC, in PMC)# $1 = sub/method, $2 = continuation op invoke(in STR, in PMC)# invocants are covered by args op invokecc(in PMC) # $1 = sub/meth, create continuation [1] op invokecc(in STR) # invocants are covered by args op tailcall(in PMC) # $1 = sub/method op tailcall(in STR) [1] if the called thing isa NCI PMC the creation of the continuation is skipped. =head2 Signature chars - current calling scheme coverage I... INTVAL var i... INTVAL constant N,n,S,s,P,p ... analog O... single PMC invocant @... call: flatten array to next args =head2 Signature chars - possible extensions @... call: flatten params/results: make array %... call: flatten **kw hash params(/results): make hash kX ... call: named arguments (key = X) OO ... call: 2 PMC invocants :... call: end of invocants marker nX ... params: default arguments (name = X) ?... params: optional part follows =P ... params/returns: clone P (or maybe cP) ... ruby code block E.g. args PP, P10, P20 # function call args OIS, P5, I10, S30 # method call args P:IS, P5, I10, S30 # same method call args P@, P0, P1 # flatten P1, args become P0, *P1 args %, P2 # P2 is a **kw hash args kPkP, $a, P0, $b, P1 # named arguments $a = P0, ... params ni, $i, 1 # default argument $i = 1 params P?PPP# await 1 - 4 arguments passed in =head2 Return context results 0 # void results 1 # 1 return result results n # n return result results -1 # list context As the Iresults_ic opcode goes before the call, we can attach a perlish return context to the return continuation and make it available in the called function. =head2 Simple example .sub main @MAIN args IN, I16, N16[1] invokecc foo [2] results I, I16 [3] .end .sub foo params IN, I16, N16 [4] ... returns I, 1[5] .end =head2 Comparison with current syntax .sub main @MAIN set I0, 1 [1] set I1, 1 set I2, 0 set I3, 0 set I4, 1 set I5, I16 set N5, N16 set S1, IN invokecc foo [2] set I16, I5[3] .end .sub foo set I16, I5[4} set N16, N5 ... set I0, 1 [5] set I1, 1 set I2, 0 set I3, 0 set I4, 0 set I5, 1 returncc .end =head2 opcode and dispatch count comparison current scheme proposed scheme opcodes call/result 29 9 dispatches10 3 opcodes param/ret 25 7 dispatches 9 2 opcodes overall 54 16 dispatches19 5 =head2 Example main .sub main @MAIN params @, P5# argv array like now params SS, S0, S1
should push (etc) be available via extend.h ?
Should There be a Parrot_PMC_push_pmc() [and friends?] in extend.h to allow parrot-extending code direct access to those vtable methods? Eventually, should extend.h contain methods to make calls on all public vtable methods? Nicholas Clark
Re: should push (etc) be available via extend.h ?
Nicholas Clark wrote: Should There be a Parrot_PMC_push_pmc() [and friends?] in extend.h to allow parrot-extending code direct access to those vtable methods? Eventually, should extend.h contain methods to make calls on all public vtable methods? Yep. Think so. But note that all vtables denoted MMD_ aren't vtable functions. And should they eventually even be autogenerated ;) Nicholas Clark leo
Re: should push (etc) be available via extend.h ?
On Tue, May 03, 2005 at 02:55:22PM +0200, Leopold Toetsch wrote: Nicholas Clark wrote: Should There be a Parrot_PMC_push_pmc() [and friends?] in extend.h to allow parrot-extending code direct access to those vtable methods? Eventually, should extend.h contain methods to make calls on all public vtable methods? Yep. Think so. But note that all vtables denoted MMD_ aren't vtable functions. I added 4 push variants to extend.h and extend.c And should they eventually even be autogenerated ;) Now, that bit I agree with. A task for someone who likes writing perl? Nicholas Clark
Re: object/method tailcalls ?
Bob Rogers wrote: How about extending .return to cover these: .return foo(x, ...) # tail function call .return o.foo(x, ...) # tail method call Done - rev 7959. More tests are welcome, as always. See imcc/t/syn/tail.t for existing ones. leo
Re: should push (etc) be available via extend.h ?
On Tue, 2005-05-03 at 14:48 +0100, Nicholas Clark wrote: And should they eventually even be autogenerated ;) Now, that bit I agree with. A task for someone who likes writing perl? I like writing Perl. Where can I find the source information, where should I write it, and how should it look? -- c
[perl #35195] [PATCH] @MAIN defined twice - behavior documented and tested
# New Ticket Created by jerry gay # Please include the string: [perl #35195] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org/rt3/Ticket/Display.html?id=35195 i couldn't find documentation on the behavior of IMCC if the @MAIN subpragma was defined on more than one subroutine, so i modified the documentation to reflect the system behavior, and provided a test. BTW the system runs the last subroutine marked as @MAIN. ~jerry MAIN_defined_twice.patch Description: Binary data
Pugs now embeds Parrot.
Because I want to embed PGE in Pugs, I end up embedding the entire libparrot. :-) As of two hours ago, if you set the PUGS_EMBED environment variable to parrot and run perl Makefile.PL, Pugs will build and link against Parrot, and provide a require_parrot() primitive for you. JIT works as one owuld expecte, too. Jeff Horwitz (of mod_parrot and more recently, mod_pugs fame) is now hacking away on hooking Pugs's IMC generator with the embedded Parrot, so we can have on-the-fly compilation without the need to call external pugscc. In other news, the Grin intermediate language used by JHC Haskell compiler looks very promising: http://repetae.net/john/computer/jhc/jhc.html Jhc's Grin - C compiler is only some 300 lines long, and unlike GHC, it does not link against a runtime system (RTS), so it should be relatively straightforward to make a Grin - Parrot compiler -- or even a Grin - Perl 6 compiler. Once that happens, we can then recompile Pugs with it, and finish the circle of bootstrapping. There are many other bootstrapping routes, but this one looks interesting. :-) Thanks, /Autrijus/ pgp8oRx3nBQow.pgp Description: PGP signature
Re: New version of PGE released
On Tue, May 03, 2005 at 02:33:25PM -0500, Patrick R. Michaud wrote: [snip the good bit] Three cheers for Patrick. Boo hiss to real life, especially when it gets in the way. Not yet implemented, but coming soon (rough priority order): - updated test harness/test suite - cut operations don't always work properly - subrules - character classes - interpolated variables - conjunctive matches - capture aliases - many, many potential optimizations Test, patches, comments, questions, etc. welcomed. Questions/comments about PGE installation and parrot issues probably belong on perl6-internals, modification and questions about PGE execution and internals probably go on perl6-compiler. Unless I hear otherwise I will probably announce minor changes only to perl6-compiler. Whilst I confess that it's unlikely to be me here, if anyone has the time to contribute some help, do you have a list of useful self-contained tasks that people might be able to take on? Nicholas Clark
Re: New version of PGE released
On Tue, May 03, 2005 at 09:22:11PM +0100, Nicholas Clark wrote: Whilst I confess that it's unlikely to be me here, if anyone has the time to contribute some help, do you have a list of useful self-contained tasks that people might be able to take on? Following some discussion on #perl6, it seems that porting the Parser part of PGE into Perl 6, using either rx// or rx:P5//, may be a good idea. Actually, porting the entirety of PGE to Perl 6 may be a good exercise for Perl 6, too. :) Thanks, /Autrijus/ pgpkDWkaIOwAg.pgp Description: PGP signature
Re: should push (etc) be available via extend.h ?
On Tue, May 03, 2005 at 10:35:50AM -0700, chromatic wrote:
On Tue, 2005-05-03 at 14:48 +0100, Nicholas Clark wrote:
And should they eventually even be autogenerated ;)
Now, that bit I agree with. A task for someone who likes writing perl?
I like writing Perl. Where can I find the source information, where
should I write it, and how should it look?
I don't know the full spec for the task. What I do know is that there are many
vtable methods, defined in vtable.tbl, accessible via Parrot::Vtable, and for
all the appropriate ones, a C wrapper would be useful. Currently they're
prototyped in include/parrot/extend.h and defined in src/extend.c. Those two
files also contain prototypes and definitions for some other non-vtable
functions useful to extenders. I assume that if the C wrappers are
autogenerated, then than would mean a new 100% autogenerated header file
#included by parrot/extend.h, and a new C file, leaving just the other
non-vtable functions in the existing 2 files.
I don't know what the list of appropriate functions to wrap is. I assume that
Leo/Chip can make a definitive criteria, but I'm guessing that it could be
most vtable methods except for the MMD ones, given what Leo has already
said.
For example, vtable.tbl defines:
INTVAL get_integer_keyed_int(INTVAL key)
The C code that wrap this is:
/*
=item CParrot_Int
Parrot_PMC_get_intval_intkey(Parrot_INTERP interp, Parrot_PMC pmc,
Parrot_Int key)
Return the keyed, signed integer value of the value in the PMC.
=cut
*/
Parrot_Int Parrot_PMC_get_intval_intkey(Parrot_INTERP interp, Parrot_PMC pmc,
Parrot_Int key) {
Parrot_Int retval;
PARROT_CALLIN_START(interp);
retval = VTABLE_get_integer_keyed_int(interp, pmc, key);
PARROT_CALLIN_END(interp);
return retval;
}
and looks like it can be autogenerated fairly easily from the parameter types
and return type declared in vtable.tbl, *except* for that choice of
name. Should we be regularising the C wrappers to have the same names as the
vtable entries?
ie s/Parrot_PMC_get_intval_intkey/Parrot_PMC_get_integer_keyed_int/
and similarly for quite a few other functions in extend.c?
Nicholas Clark
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 ...
First monthly slush - May 4
Starting May 4, to ease the transition to regular releases, we'll not so much freeze as slush the code base. Please don't do anything destabilizing (to the code base :-)) in the next few days. I expect the slush will last a few days as well. The plan is to make a release branch for each release, then merge its changes into the trunk after release. Now that we're subversioned, branching is much less painful than with CVS. So, once we make the branch -- and I'll announce when we do -- everybody can pick up with the development activity again. -- Chip Salzenberg [EMAIL PROTECTED]
New version of PGE released
The short story --- I've just committed a new, rewritten version of PGE to the Parrot repository. It's still somewhat preliminary and many rule features are still missing. On the other hand, it's now written entirely in PIR (no more C compiling!) and provides a stronger base platform for developing the rest of the features. More details are below, and in compilers/pge/README. Comments, suggestions, and test cases welcomed. The long story -- (Or, hey, what took you so long?) Well, I was working along in PGE late last year, and discovered that P6 rules capturing semantics weren't very clear. So, a few messages to p6l and a few weeks later the @Larry team proposes detailed semantics for capturing. (I'll present these in future messages.) Then Real Life intruded and kept me away from development for a few weeks. When I finally got a chance to look at PGE in detail again, I started adding things in the C parser and discovered that I really wanted dynamic hashes and arrays to work with. Since we're going to have to handle Unicode someday anyway, I decided to take a step backwards (rebuild the basic engine from scratch) so that we can start taking larger leaps forward. This divorces PGE from compiler issues, and which brings us to where we are today. Appearing in this version of PGE: - basic expressions, quantifiers, alternation - subpatterns (groups), including nested capturing subpatterns - \d, \s, \n, \w character classes Not yet implemented, but coming soon (rough priority order): - updated test harness/test suite - cut operations don't always work properly - subrules - character classes - interpolated variables - conjunctive matches - capture aliases - many, many potential optimizations The basic design remains the same, there's a rule parser, an expression tree, and a code generator. I briefly played with executing components of the expression tree to match strings but decided that it was actually a bit messier than doing code generation (and likely a bit slower as we had to test expression characteristics at pattern-match time instead of compile time). So, the difference now is that we have PIR code generating PIR instead of a C function generating PIR. The code generator tries to produce only the code needed for each component of the match, but I'm sure there will be a lot of optimizations we can come up with. Fortunately we can optimize in the expression tree before generating the code. I also continued using the bsr/ret scheme for calling components because it avoids much of the register passing overhead and recreating state information from one expression to the next. But it's easy enough for us to switch to use Parrot subroutine semantics if we ever decide we want that. The test suite is currently broken, I'll be fixing that next. As always we need more tests; the current tests are in t/p6rules and are fairly easy to write. Test, patches, comments, questions, etc. welcomed. Questions/comments about PGE installation and parrot issues probably belong on perl6-internals, modification and questions about PGE execution and internals probably go on perl6-compiler. Unless I hear otherwise I will probably announce minor changes only to perl6-compiler. Pm
Re: PMC flags
On Mon, 2005-05-02 at 08:58 +0200, Leopold Toetsch wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
1 bit for SVf_IOK
1 bit for SVf_NOK
1 bit for SVf_POK
1 bit for SVf_ROK
I'd not mess around with (or introduce) flag bits. The more that this
would only cover perl5 PMCs. Presuming that the Perl5 PMCs are subtypes
of Parrot core PMCs, I'd do ...
[... code doing a string isa check on the type ...]
The vtable functions Cisa and Cdoes, which take now a string, are a
bit heavy-weighted and might get an extension in the log run that take
an integer flag.
Unless this happens, this would be a HUGE performance hit. After all,
Sv*OK is called all over the place in the Perl 5 code, including many
places where performance is an issue.
[...]
2 bits to say what we're storing in the union
The vtable is that information:
INTVAL i = VTABLE_get_integer(interpreter, pmc);
FLOATVAL n = VTABLE_get_number(interpreter, pmc);
Here is some example P5 source from pp_pow in pp.c:
if (SvIOK(TOPm1s)) {
bool baseuok = SvUOK(TOPm1s);
UV baseuv;
if (baseuok) {
baseuv = SvUVX(TOPm1s);
} else {
IV iv = SvIVX(TOPm1s);
and here that is, run through the C pre-processor: pre-processor:
if *(sp-1)))-sv_flags 0x0001)) {
char baseuok = *(sp-1)))-sv_flags (0x0001|0x8000))
== (0x0001|0x8000));
UV baseuv;
if (baseuok) {
baseuv = ((XPVUV*) ((*(sp-1)))-sv_any)-xuv_uv;
} else {
IV iv = ((XPVIV*) ((*(sp-1)))-sv_any)-xiv_iv;
Notice that there is exactly no function calling going on there. To
change that to (pseudocode):
if (isa_int_test(TOPm1s)) {
bool baseuok = isa_uint_test(TOPm1s);
UV baseuv;
if (baseuok) {
baseuv = invoke_uint_vtable_get(TOPm1s);
} else {
IV iv = invoke_int_vtable_get(TOPm1s);
Well... even after JIT compilation, function call overhead is function
call overhead, no?
just do the right thing. Usually there is no need to query the PMC what
it is.
If you're writing a compiler from scratch, I can see that being mostly
true. However, in trying to port Perl 5 guts over to Parrot, there's a
lot of code that relies on knowing what's going on (e.g. if a value has
ever been a number, etc.)
Perl 6 Summary for 2004-04-26 through 2005-05-03
Perl 6 Summary for 2004-04-26 through 2005-05-03 All~ Welcome to another weeks summary. This week I shall endeavor not to accidentally delete my summary or destroy the world. So here we go with p6c. Perl 6 Compilers implicit $_ on for loops Kiran Kumar found a bug in pugs involving for loops which use $_ but don't iterate over it. Aaron Sherman and Luke Palmer confirmed the bug. No word as to its final status, but given the rate of development of pugs... http://xrl.us/fyof Pugs Darcs trouble Glenn Ehrlich noticed that pugs's darcs repository wasn't getting updated. Sam Vilain explained that occasionally a daemon needed to be kicked. http://xrl.us/fyog Memory Game v0.2 BÁRTHÁZI András announced the release of the latest version of Memory. He also put out a call for 85x75 pixel photos for the next version. http://xrl.us/fyoh Haddock for Pugs Stuart Cook decided that the easiest way for him to understand Pugs internals was to provide better documentation. To that end he started working with haddock to automatically generate cross linked documentation for pugs. He even met with some success. http://xrl.us/fyoi /haskell.org/haddock/ in http: is export trait Garrett Rooney wondered why the is export trait appeared to do nothing in Pugs. Stevan Little explained that it was just a place holder which, while it parses, does nothing semantically yet. http://xrl.us/fyoj Pugs 6.2.2 Autrijus proudly announced the release of Pugs 6.2.2. It features a great many changes. High on that list is a great number of speed ups and thread safe, dead lock free internal storage. http://xrl.us/fyok Pugs on Cygwin Rob Kinyon noticed that Pugs was having trouble on Cygwin. He has made some headway rectifying the situation, although work remains. http://xrl.us/fyom Pugs TODO model Stevan has put some more thought into the TODO model for Pugs. His latest suggestion, annotating todo tests with a flag indicating why they are not passing, seems a little less hackish then the last one and received general support. http://xrl.us/fyon Parrot hiding inside Pugs Autrijus wanted to embed the newly released PGE. PGE is written in PIR which runs on Parrot. So, Autrijus decided to embed Parrot into Pugs. He also posted an interesting link to JHC as a possible bootstrap solution. http://xrl.us/fyoo /repetae.net/john/computer/jhc/jhc.html in http: new PGE released Maybe I should have mentioned this first... Patrick R. Michaud released a new version of the Parrot Grammar Engine. It is written entirely in PIR and generates PIR code. It has many features but not enough tests... cough hint /cough http://xrl.us/fyop Parrot Monthly Release? Jared Rhine wondered the monthly releases included April. Chip announced that April's release would be slushier then most, but would start on the fourth. http://xrl.us/fyoq http://xrl.us/fyor t/op/debuginfo.t failure François Perrad noticed a failure in with debuginfo. Leo pointed out that it was an issue of flushing output handles. Francois provided a patch (well actually two). Warnock applies to the second. http://xrl.us/fyos ParTcl Happy? Will Coleda thought that ParTcl's GC bugs were finally fixed. Leo burst his bubble. Apparently these GC bugs can disappear and reappear according to sun spot activity. http://xrl.us/fyot segfault in load_bytecode Nick Glencross submitted a patch fixing a segfault in load_bytecode. Jens pointed out that it should use real_exception instead of internal_exception. chromatic offered to write the test. No official committed message though... http://xrl.us/fyou large PackFile tinker Leo implemented a change in the interpreter PackFile structure which has been under discussion for a long time. Unfortunately, it has the potential to break a lot of JIT stuff. Tests and fixes would be greatly appreciated. http://xrl.us/fyov PMC inheritance issue Nicholas Clark was having some trouble with his Perl5 PMCs. Later he posted a mea culpa email, but Leo provided some useful pointers anyway. http://xrl.us/fyow RT cleanup Bernhard Schmalhofer cleaned out an old ticket from RT. http://xrl.us/fyox RFC assign Px, Py Some time ago, Leo requested comments on the semantics of assign. Brent 'Dax' Royal-Gordon tried to de-Warnock the thread with his support. He also suggested a clone operator. http://xrl.us/fyoy NULL in real_exception Nicholas Clark was getting bitten by a NULL pointer deref in real_exception. Leo pointed him toward the correct approach. http://xrl.us/fyoz unary operator overhaul Having finished overhauling the infix operators, Leo set to work
disassemble segfaults
. . . but I can't figure out why. I thought the patch below would help, but it appears that the value of c is itself broken somehow. . . . This GDB was configured as i586-suse-linux... (gdb) r runtime/parrot/library/config.pbc Starting program: /usr/src/parrot/disassemble runtime/parrot/library/config.pbc [New Thread 16384 (LWP 24464)] [New Thread 32769 (LWP 24466)] [New Thread 16386 (LWP 24467)] [New Thread 32771 (LWP 24468)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 24464)] 0x08083966 in Parrot_disassemble (interpreter=0x8253d00) at src/embed.c:880 (gdb) bt #0 0x08083966 in Parrot_disassemble (interpreter=0x8253d00) at src/embed.c:880 #1 0x08082871 in do_dis (interpreter=0x8253d00) at src/disassemble.c:99 #2 0x0808283f in main (argc=2, argv=0xb554) at src/disassemble.c:79 (gdb) I find disassemble useful, but it seems subject to periodic bit rot. So, I think I would like to write some basic tests for it. Is it worth extending Parrot::Test to include disassemble_output_is, etc., or should I do something more special-purpose? -- Bob Rogers http://rgrjr.dyndns.org/ Index: embed.c === --- embed.c (revision 7955) +++ embed.c (working copy) @@ -877,7 +877,7 @@ if (line-label) PIO_printf(interpreter, L%li:\t, line-label-number); c = pdb-file-source + line-source_offset; -while (*c != '\n' c) +while (*c *c != '\n') PIO_printf(interpreter, %c, *(c++)); PIO_printf(interpreter, \n); line = line-next;
Re: disassemble segfaults
Bob~ On 5/3/05, Bob Rogers [EMAIL PROTECTED] wrote: . . . but I can't figure out why. I thought the patch below would help, but it appears that the value of c is itself broken somehow. . . . This GDB was configured as i586-suse-linux... (gdb) r runtime/parrot/library/config.pbc Starting program: /usr/src/parrot/disassemble runtime/parrot/library/config.pbc [New Thread 16384 (LWP 24464)] [New Thread 32769 (LWP 24466)] [New Thread 16386 (LWP 24467)] [New Thread 32771 (LWP 24468)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 24464)] 0x08083966 in Parrot_disassemble (interpreter=0x8253d00) at src/embed.c:880 (gdb) bt #0 0x08083966 in Parrot_disassemble (interpreter=0x8253d00) at src/embed.c:880 #1 0x08082871 in do_dis (interpreter=0x8253d00) at src/disassemble.c:99 #2 0x0808283f in main (argc=2, argv=0xb554) at src/disassemble.c:79 (gdb) I find disassemble useful, but it seems subject to periodic bit rot. So, I think I would like to write some basic tests for it. Is it worth extending Parrot::Test to include disassemble_output_is, etc., or should I do something more special-purpose? -- Bob Rogers http://rgrjr.dyndns.org/ Index: embed.c === --- embed.c (revision 7955) +++ embed.c (working copy) @@ -877,7 +877,7 @@ if (line-label) PIO_printf(interpreter, L%li:\t, line-label-number); c = pdb-file-source + line-source_offset; -while (*c != '\n' c) +while (*c *c != '\n') PIO_printf(interpreter, %c, *(c++)); PIO_printf(interpreter, \n); line = line-next; Not knowing any of the surrounding code, shouldn't that be while (c *c != '\n') Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -???
Re: Test::Builder change BAILOUT - BAIL_OUT
On Tue, 2005-05-03 at 15:36 -0700, Michael G Schwern wrote: Test::Simple/More/Builder 0.61 will introduce a change to Test::Builder whereby the BAILOUT() method becomes BAIL_OUT(). Additionally Test::More finally features a BAIL_OUT() function. Using cpansearch [1] I've determined that you all are the only current users of BAILOUT() on CPAN. Ponie, Parrot, Test::Class and XUL::Node. Parrot bundles Test::Builder 0.11 (from Test-Simple 0.41). Is it worth upgrading? -- c
Re: Test::Builder change BAILOUT - BAIL_OUT
On Tue, May 03, 2005 at 09:23:01PM -0700, chromatic wrote: Parrot bundles Test::Builder 0.11 (from Test-Simple 0.41). Is it worth upgrading? Couldn't hurt. A whole mess of is_deeply() bugs have been fixed since 0.41. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern ROCKS FALL! EVERYONE DIES! http://www.somethingpositive.net/sp05032002.shtml
Re: PMC flags
Aaron Sherman wrote: On Mon, 2005-05-02 at 08:58 +0200, Leopold Toetsch wrote: The vtable functions Cisa and Cdoes, which take now a string, are a bit heavy-weighted and might get an extension in the log run that take an integer flag. Unless this happens, this would be a HUGE performance hit. After all, Sv*OK is called all over the place in the Perl 5 code, including many places where performance is an issue. Here is some example P5 source from pp_pow in pp.c: I presume that Ponie eventually will run Parrot opcodes. pp_pow() is like all these functions part of the perl runloop. Therefore it'll be infix .MMD_POW, P1, P2, P3 which will do a MM dispatch depending on (P1, P2). That's all. No flags needed. If you're writing a compiler from scratch, I can see that being mostly true. However, in trying to port Perl 5 guts over to Parrot, there's a lot of code that relies on knowing what's going on (e.g. if a value has ever been a number, etc.) Most of the guts are called from the runloop. But there is of course XS code that messes with SV internals. leo
