Meaning of "restart" in *.ops files?
What does "restart" mean in op files, as in "restart ADDRESS(resume);"? Also, why does the find_global op use it? I couldn't find it explained anywhere. Also, on a vaguely related topic, in "Parrot_jit_cpcf_op", what does "cpcf" stand for? JEff
Re: yield op?
On Fri, 9 Jan 2004, Leopold Toetsch wrote: > Michal Wallace <[EMAIL PROTECTED]> wrote: > > > Hey all, > > > When you invoke a Coroutine, it calls swap_context() > > Can you have a look at imcc/t/syn/pcc.t, there is an coroutine > iterator test. Yep, it has the same problem. The patch below exposes it. Comment out the first zero=0 line and you get an infinite stream of sixes. With both in there it prints two numbers and ends. (This is without Luke's patch) The principle seems to be that you can't modify anything in the context without screwing up the continuation's registers. Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ -- Index: t/syn/pcc.t === RCS file: /cvs/public/parrot/imcc/t/syn/pcc.t,v retrieving revision 1.28 diff -u -r1.28 pcc.t --- t/syn/pcc.t 16 Dec 2003 08:53:44 - 1.28 +++ t/syn/pcc.t 10 Jan 2004 03:41:28 - @@ -489,6 +489,8 @@ output_is(<<'CODE', <<'OUT', "coroutine iterator"); .sub _main + .local int zero + zero=0 .local int i i=5 newsub $P0, .Coroutine, _addtwo @@ -500,6 +502,7 @@ ret_addr: .result $I2 .pcc_end +zero = 0 print $I2 print "\n" savetop
Properties for builtin types?
Is there a list of the properties for the builtin types? My searches through the archives leads me to believe there is no such beast. Is there any consensus on what some of the properties will be? I am not looking for a complete or authoritative list. I am just trying to finish off a section of the wiki and maybe write some test cases. Thanks, Mik PS - If this hits the list 4 times, it is my mail server not me. No. Really. --- Mik Firestone [EMAIL PROTECTED] "Marriage is what happens when blackmail is no longer effective" -- Victoria Balloon ( my wife )
Re: Configure.pl Error
Harry Jackson wrote:
I am now trying to get Parrot running on debian and have noticed the
following error while running "perl Configure.pl"
Determining some sizes...Linker failed (see test.ldo) at
lib/Parrot/Configure/Step.pm line 233
Parrot::Configure::Step::cc_build() called at
config/auto/sizes.pl line 39
Configure::Step::runstep('undef') called at
lib/Parrot/Configure/RunSteps.pm line 68
Parrot::Configure::RunSteps::runsteps('Parrot::Configure::RunSteps','jitcapable',0,'debugging',1)
called at Configure.pl line 94
This is a very minimal system at the moment so I might not have
everything installed. I am hoping that someone may have seen his before.
For anyone that ever encounters this problem in the future delete the
source tree and check out the source again. It worked for me.
H
Re: cvs commit: parrot/imcc imcc.l
At 07:36 PM 1/9/2004 +0100, Leopold Toetsch wrote: Melvin Smith <[EMAIL PROTECTED]> wrote: > At 09:01 AM 1/9/2004 +0100, Leopold Toetsch wrote: > Which is why I hoped people would pitch in and help fix the tests. Its not tests only. There's already production code out there using Parrot - ask Dan or read his blog. And of course macros are used not only in tests, they are in library code and so on. Dan is smart enough not to arbitrarily update his tree with a current unstable CVS shapshot that is temporarily in flux. You don't update "production" code everytime a new revision appears in CVS. You wait until a release. In between releases, I would like to have opportunity to break things, honestly, while we are still in the alpha stage. > This is alpha code, and my approach is to do what needs to be done > and force us to deal with it sooner than later. That's ok. But we also had some priorities nailed down. First is to fix current bugs and to finally implement the pdd03 changes. I know, that one bug is related to macros, but changing the generated labels from line-numbers to an incremented counter wil very likely fix that too. I understand, but in real life I might get time to work on a small mod, and large mods sometimes have to wait for a larger "coding window." I think its time we create a branch for imcc2 mods. That way we can work in parallel on these things at a more granular pace and not affect Parrot for extended periods of time. We can then backpatch some of the changes as soon as they work rather than waiting to merge the branch (such as dup labels and PCC stuff) but the branch will be available for people to experiment with. I'll create the branch as soon as I get some significant stuff to commit, maybe this weekend. -Melvin
Re: cvs commit: parrot/imcc imcc.l
At 08:44 PM 1/9/2004 +, Harry Jackson wrote: Melvin Smith wrote: But, if you want macros to stay, let them stay. So, are they staying, staying for now or not sure yet? I have a few hundred lines of imcc that uses macros and if they are being removed then I would rather change now and save myself some pain later. I think we are going to have an alternative to C<.constant> builtin to IMCC, the best suggestion seems to be C<.define> As far as macros, I guess we will keep them for the near future. I think its time to create a new branch for imcc development, so lets see how things work out. It may be that we can keep them in some form. One thing to consider: when we put an API on top of IMCC, macros won't translate; they are only for the text version. -Melvin
Re: cvs commit: parrot/imcc imcc.l
Melvin Smith <[EMAIL PROTECTED]> wrote: > At 09:01 AM 1/9/2004 +0100, Leopold Toetsch wrote: >>Melvin, that's not the way to go. We can remove them from the lexer, >>when we have an external substitute. Just removing it breaks a lot of >>existing code. Failing tests may hide other problems and so on. > Which is why I hoped people would pitch in and help fix the tests. Its not tests only. There's already production code out there using parrot - ask Dan or read his blog. And of course macros are used not only in tests, they are in library code and so on. > This is alpha code, and my approach is to do what needs to be done > and force us to deal with it sooner than later. That's ok. But we also had some priorities nailed down. First is to fix current bugs and to finally implement the pdd03 changes. I know, that one bug is related to macros, but changing the generated labels from line-numbers to an incremented counter wil very likely fix that too. > But, if you want macros to stay, let them stay. Currently yes, until there is an external macro processor. > -Melvin leo
Re: cvs commit: parrot/imcc imcc.l
Melvin Smith wrote: But, if you want macros to stay, let them stay. So, are they staying, staying for now or not sure yet? I have a few hundred lines of imcc that uses macros and if they are being removed then I would rather change now and save myself some pain later. H
[CONGRATS] Dan for 1st commercial use of Parrot :)
:)
Re: [PATCH] Continuations now close over register stacks
On Fri, 9 Jan 2004, Luke Palmer wrote: > Very rarely would you not savetop before creating a *real* continuation. > But again, very rarely would you actually create a *real* continuation > (depending on your language). RetContinuations are almost always a > better choice for traditional languages, and languages like Python with > no support for continuations. Gotcha. It just looked odd to me that you had to call savetop... But now I see that's because I was doing the wrong thing all along. :) Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: [PATCH] Continuations now close over register stacks
On Fri, 9 Jan 2004, Leopold Toetsch wrote: > Michal Wallace <[EMAIL PROTECTED]> wrote: > > > newsub $P1, .Continuation, done > > For returning just use a .RetContinuation. Or still better, just omit > $P1 totally here: > > > .pcc_call $P0, $P1 Aha! I like that even better. :) Thanks! Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: BUG: coroutine + exception = stack_height segfault
On Fri, 9 Jan 2004, Jeff Clites wrote: > On Jan 9, 2004, at 12:24 AM, Leopold Toetsch wrote: > > > Michal Wallace <[EMAIL PROTECTED]> wrote: > >> #!/bin/env parrot > >> # > >> # yieldbug.imc > >> # > >> # This program should print dots forever. > >> # Instead it prints a few dots and then segfaults. > > > > It does print dots forever here. > > It does for me too. But based on a previous email, I assume you are > getting the crash after applying Luke's continuations patch? (I haven't > tried your script with that applied.) Crap. Yes, this code works for me too on the unpatched version. I should have been more careful. But... I had based this example on a much larger program that has the same bug in either version of parrot. It loops through a list of iterators. It works fine if I comment out the two exception handler lines: newsub P0, .Exception_Handler, __py__catch set_eh P0 But with those two lines there it segfaults immediately with the stack_height assertion failure. I'll try to boil it down again tonight. Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ --
Re: cvs commit: parrot/imcc imcc.l
At 09:01 AM 1/9/2004 +0100, Leopold Toetsch wrote: Melvin Smith <[EMAIL PROTECTED]> wrote: > IMCC macros are gone. Volunteers feel free to reimplement a > pre-processor (outside of IMCC) using the macro expansion code > that was removed from IMCC. Melvin, that's not the way to go. We can remove them from the lexer, when we have an external substitute. Just removing it breaks a lot of existing code. Failing tests may hide other problems and so on. Which is why I hoped people would pitch in and help fix the tests. This is alpha code, and my approach is to do what needs to be done and force us to deal with it sooner than later. But, if you want macros to stay, let them stay. -Melvin
Re: [RFC] Parrot runtime include files and .constant macros
At 08:58 AM 1/9/2004 +0100, Leopold Toetsch wrote: Melvin Smith <[EMAIL PROTECTED]> wrote: > This also means .pasm files won't be able to .include these anymore, > you'd have to use IMC. Why not just make .const work in both modes? Because pure PASM doesn't currently use type names. .const expects a type of (int|string|num) and isn't the same thing as .constant -Melvin
Re: [PATCH] The Return of the Priority DOD
Leopold Toetsch writes: > Luke Palmer <[EMAIL PROTECTED]> wrote: > > ... I'm not > > against somebody else maintaining the patch in the meantime :-) > > I went again through the patch and the original one from Sept, 5th. But > it seems that one thing is missing in both: > > *If* all PMCs which needs_early_DOD are seen live, the DOD run is > aborted. But completing the DOD run also resets live bits of non-dead > objects, which is missing now. > > It seems, that in that case we still need to walk the PMC arenas and > reset all live bits. OTOH when ARENA_DOD_FLAGS is on, this isn't too > expensive because it can be done my masking a full word worth of 8 PMCs > at once. So its still a lot faster then the eager case - hopefully. > > Or am I missing something? I don't think you are. I would have thought that GC be the one to reset the live bits, but there was a lot of DOD that I didn't completely understand. I don't remember explicitly taking such a thing out, but I could have inadvertently. Thanks for looking through the patch. Luke
cpansmoke setup
Hi All, After reading a few articles, I've decided I'd like try to use one of my home servers as a cpansmoke machine. I'm just not 100% sure how to get the automatic testing working in my particular case. I have two servers: a mail server and an "everything else" server which will be the testing machine. The CPANPLUS Tester Guide [1] suggests that I use Mail::Audit to filter my mail and automatically run cpansmoke. Should I simply cut and paste the suggested filter from the guide into Mail::Audit's popread script and run it on my "everything else" server via cron on a set interval? Where would the mail end up going in the end? Since I have direct access to the mail server, is there a better way to go about this? Note: testing directly on the mail server is not an option. Any advice would be greatly appreciated. Thanks in advance, -Brian Cassidy [1] http://search.cpan.org/~autrijus/CPANPLUS-0.048/lib/CPANPLUS/TesterGuide.pod http://www.gordano.com - Messaging for educators.
Re: [perl #24837] [PATCH] .cvsignore files for Parrot m4
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > This patch adds some .cvsignore files to the recently added 'languages/m4'. > It tells CVS that is OK to have a generated Makefile and generated test > input and result files. Thanks, applied. leo
Re: BUG: coroutine + exception = stack_height segfault
Jeff Clites writes: > On Jan 9, 2004, at 12:24 AM, Leopold Toetsch wrote: > > >Michal Wallace <[EMAIL PROTECTED]> wrote: > >>#!/bin/env parrot > >># > >># yieldbug.imc > >># > >># This program should print dots forever. > >># Instead it prints a few dots and then segfaults. > > > >It does print dots forever here. > > It does for me too. But based on a previous email, I assume you are > getting the crash after applying Luke's continuations patch? (I haven't > tried your script with that applied.) Ahh, that could make sense. I didn't do any work on the Coroutine PMC, so it's probably not doing what it should with the new register stack semantics. Luke
Re: BUG: coroutine + exception = stack_height segfault
On Jan 9, 2004, at 12:24 AM, Leopold Toetsch wrote: Michal Wallace <[EMAIL PROTECTED]> wrote: #!/bin/env parrot # # yieldbug.imc # # This program should print dots forever. # Instead it prints a few dots and then segfaults. It does print dots forever here. It does for me too. But based on a previous email, I assume you are getting the crash after applying Luke's continuations patch? (I haven't tried your script with that applied.) JEff
Re: yield op?
Michal Wallace <[EMAIL PROTECTED]> wrote: > Hey all, > When you invoke a Coroutine, it calls swap_context() Can you have a look at imcc/t/syn/pcc.t, there is an coroutine iterator test. leo
Re: [PATCH] Continuations now close over register stacks
Michal Wallace writes: > On Thu, 8 Jan 2004, Luke Palmer wrote: > > .sub __main__ > > newsub $P0, .Closure, _func > > savetop > > newsub $P0, .Continuation, done > > > > So the restoretop after the invoke has something to pop (and so your > > register state isn't screwed up when you get back). > > > Thanks Luke. > > I changed my compiler to call savetop before every function > call, and that passes my tests but I'm having trouble > visualizing why. Would I ever NOT want to call savetop > before creating a continuation? Very rarely would you not savetop before creating a *real* continuation. But again, very rarely would you actually create a *real* continuation (depending on your language). RetContinuations are almost always a better choice for traditional languages, and languages like Python with no support for continuations. You won't get in trouble mixing RetContinuations with real ones, as long as you don't try to use RetContinuations like Continuations, and only use them to return downward. Luke
Re: cvs commit: parrot/imcc imcc.l
Melvin Smith <[EMAIL PROTECTED]> wrote: > IMCC macros are gone. Volunteers feel free to reimplement a > pre-processor (outside of IMCC) using the macro expansion code > that was removed from IMCC. Melvin, that's not the way to go. We can remove them from the lexer, when we have an external substitute. Just removing it breaks a lot of existing code. Failing tests may hide other problems and so on. leo
Re: [PATCH] Continuations now close over register stacks
Michal Wallace <[EMAIL PROTECTED]> wrote: > newsub $P1, .Continuation, done For returning just use a .RetContinuation. Or still better, just omit $P1 totally here: > .pcc_call $P0, $P1 leo
Re: [PATCH] Continuations now close over register stacks
Luke Palmer <[EMAIL PROTECTED]> wrote: > .sub __main__ > newsub $P0, .Closure, _func > savetop No - not for plain subroutines/closures. > Or you could do as PCC does and use a .RetContinuation, which doesn't > close over the stacks, when you don't actually need a full continuation. Yep. > Luke leo
Re: [RFC] Parrot runtime include files and .constant macros
Melvin Smith <[EMAIL PROTECTED]> wrote: > This also means .pasm files won't be able to .include these anymore, > you'd have to use IMC. Why not just make .const work in both modes? > -Melvin leo
Re: BUG: coroutine + exception = stack_height segfault
Michal Wallace <[EMAIL PROTECTED]> wrote: > #!/bin/env parrot > # > # yieldbug.imc > # > # This program should print dots forever. > # Instead it prints a few dots and then segfaults. It does print dots forever here. leo
yield op?
Hey all, When you invoke a Coroutine, it calls swap_context() from src/sub.c ... There's an else clause in there that either swaps or restores theinterpreter stack, but as far as I can tell, swap_context() is ONLY called when entering a coroutine - not when we're suspending it. That means all sorts of nasty things happen when the either coroutine or the calling context gets modified. For example, the code below counts up from 1 to forever. But if you uncomment the zero=0 line, it never gets higher than 1 because "zero" in __main__ and "x" in "_iterator" get assigned to the same register, and the context isn't properly restored. It seems to me that invoke() is doing the right thing by swapping the context, but that there needs to be a yield() method (and opcode?) to balance it out. It definitely needs more than a savetop or an "invoke" of ther return continuation, because neither of these things would let you fire a method on the coroutine instance. That's why I'm thinking we need a yield op. Am I on the right track here? Either way, what can I do to get this working? Sincerely, Michal J Wallace Sabren Enterprises, Inc. - contact: [EMAIL PROTECTED] hosting: http://www.cornerhost.com/ my site: http://www.withoutane.com/ -- #!/bin/env parrot # uncomment the second zero=0 line to see the magic bug :) .sub __main__ .local Coroutine itr .local object return .local object counter newsub itr, .Coroutine, _iterator .local object zero zero = new PerlInt zero = 0 newsub return, .Coroutine, return_here loop: .pcc_begin non_prototyped .pcc_call itr, return return_here: .result counter .pcc_end print counter print " " ### zero = 0 print zero print "\n" goto loop end .end .pcc_sub _iterator non_prototyped .local object x x = new PerlInt x = 0 iloop: .pcc_begin_yield .return x .pcc_end_yield x = x + 1 goto iloop .end
Re: Archive tarball?
Luke Palmer <[EMAIL PROTECTED]> writes: > michael.firestone writes: >> Is there somewhere I can get the entire perl6-language archive in a >> tarball? > > I personally don't know, but there could be somewhere. > >> I am trying to work on turning the Apocalypses into story cards at >> http://p6stories.kwiki.org. It would be helpful to me if I could search >> the mailing list archives to make sure I incorporate any decisions made >> after each Apocalypse was written. As there is no search engine at this >> moment ( that is not a whine or a complaint, merely a statement ), the next >> best thing for me would be a tarball I could grep. > > Well, most of the decisions you'll find in the "official" documents: the > apocalypses, exegeses, and synopses. perl6-language has a lot of > brainstorming, and a lot of Larry saying something interesting in the > form of "maybe ...", but those could hardly be considered decisions. > > If worse comes to worst, you can always ask me. I manage to keep the > largest amount of the language in my head with the most time available > to answer questions :-) > > Oh, and thanks for the p6stories work. Of course the beauty of a Wiki is that you can just watch the RecentChanges page, proof read the new stories for up to date syntax and correct 'em as necessary. -- Beware the Perl 6 early morning joggers -- Allison Randal
RE: A modest question
On Thu, 2004-01-08 at 16:24, Jonathan Lang wrote: > In this example, there's no difference between the Dog and Tree roles; > however, this would almost certainly not be the case most of the time - at > the very least, a class with a Dog role would have @.legs, while a class > with the Tree role would have @.branches. However, if all that happens > when you specify a demand for the Dog role in a signature is that the > object must meet Dog's demands, then both crossPerson and Trog will be > accepted. I would consider that a mistake. All that doing a role should imply is that somehow, that class understands the syntax *and* semantics of the methods of that role. Introspection can't reliably reveal whether $some_object.bark accesses a property (noun) or a method (verb). It's true that looking for @.legs versus @.branches could get you closer, but I'm not sure that it's been decided whether methods of a role should blissfully ignore all of the object's state. Besides, in a delegation situation, there could easily be some sort of magic that handles those attributes that the introspection mechanism might miss. -- c
