Re: [perl #31949] [TODO] finhish complex PMC
Ion Alexandru Morega [EMAIL PROTECTED] wrote: Fixed, tested. (the tests were there, only commented out) Great, thanks. I only added implementations for MMD_Complex and MMD_DEFAULT. I suppose more could be written, but how much is too much? That's difficult to say and needs benchmarks with common usage patterns. But I can imagine that CFloat could be special cased too, but who knows. But before implementing more, we have to fix MMD inheritance anyway. regards, alexm Thanks, applied. leo
Re: spurious assembleur directives get in the way of oneliner return implementation
Stéphane Payrard [EMAIL PROTECTED] wrote:
.return -1, name
Sadly, the .return directive and other are overloaded to express
user stack operations.
| PARAM reg{ $$ = MK_I(interp, cur_unit, restore, 1,
$2); }
| RESULT var { $$ = MK_I(interp, cur_unit, restore, 1,
$2); }
| ARG var { $$ = MK_I(interp, cur_unit, save, 1, $2); }
| RETURN var { $$ = MK_I(interp, cur_unit, save, 1, $2); }
Yes, this dual meaning of these directive is a PITA. E.g. the usage of
C.param is the reason that:
.sub foo
# get args
.param int bar
isn't parsed correctly. So I'd like to get rid of that the sooner the
better.
But, as you said, it might be used. So I'd propose:
- deprecate the usage of these directives for stack calling conventions
- for now, we go with Dan's syntax:
.return( list )# a different token
.yield( list )# same syntax
.yield list # pas de problem
--
stef
leo
Re: cvs commit: parrot/languages/tcl/lib/macros boolean.imc
Will Coleda [EMAIL PROTECTED] wrote:
Given a pmc, set a register to indicate whether
it is true or false from Tcl's POV.
inline op istrue(out INT, in PMC) {
with an approprate get_bool() vtable slot.
leo
Re: [perl #31987] Should predefined pmcs inherit nci methods?
Sam Ruby [EMAIL PROTECTED] wrote: Concrete example: should ResizablePMCArray inherit sort from FixedPMCArray? Yes. But the inheritance should be (and is AFAIK already partially) in the method lookup. But it's not quite finished. Objects derived from PMCs inherit methods of the parent, but one level only. PMC inheritance isn't followed yet IIRC. I'm assuming the answer is yes, as classes defined via the subclass opcode seem to inherit non-vtable methods. In fact, I've made a number of assumptions, any of which could invalidate the attached patch. I'll look through it. But we'll very likely not do the static inheritance by duplicating NCI method slots. That would prevent to override a base class method. - Sam Ruby leo
Re: So long, and thanks for all the fish!
The Perl 6 Summarizer [EMAIL PROTECTED] wrote: I tried, I really did, but I'm afraid that I must raise the white flag ..- Dan, Leo and the rest of the p6i team have done fantastic work Thanks for the flowers and of course for all your precise summaries. ... But if any of you are thinking I could do that! then don't let me stop you -- there's an awful lot goes on on the lists, and there's a lot of interested people who don't have the time to keep up with them. A regular summary helps the interested but busy people get a grasp of how the Perl 6 project is getting on, and that can only be a good thing. Yep, so please, interested folks, sharpen your pencil ... -- Piers Cawley -- Former Perl 6 Summarizer Thanks again, and maybe ex-former any tine, leo
Re: [perl #31992] [BUG] YetAnotherGarbageCollectionBug(tm)
Will Coleda [EMAIL PROTECTED] wrote: I noticed after a recent update that parts of the tcl test suite started failing. I finally tracked it down to the fact that I was NOT running with '-G'. tcl.pl dies at 19, removing or die fixes that. To your problem: Ctclobject is an abstract object, it doesn't have a vtable. But the bundling code *does* Cpmc_register this PMC. This leads to an empty vtable slot, dereferencing that NULL is an operation, which many systems don't like. After fixing that (or better working around - Cpmc_register shouldn't be called) it dies later and as usual by loosing CTclWords - it seems. My gut feeling is that CTclArray isn't quite up to data. It duplicates at firt sight just CPerlHash. But the latter has recent changes WRT hash creation, which aren't in CTclArray. I'd first reduce CTclArray to a bare minimum. Specifically the creation functions (init, clone) should be inherited (or follow the CPerlHash conventions). The same applies to any PMC that can hold pointers to other PMCs. These changes are necessary to make a PMC compliant with incremental GC. Please grep through the docs and the sources for DOD_WRITE_BARRIER. leo
Re: [perl #31987] Should predefined pmcs inherit nci methods?
Sam Ruby [EMAIL PROTECTED] wrote: I'm assuming the answer is yes, as classes defined via the subclass opcode seem to inherit non-vtable methods. In fact, I've made a number of assumptions, any of which could invalidate the attached patch. I've applied the non-inheritance pieces of the patch. - Sam Ruby Thanks, leo
Re: cvs commit: parrot/languages/tcl/lib/macros boolean.imc
Danke. Making this a macro was, at least, a step up from the function call I had.
I haven't done anything real with the PMCs yet (just cargo-culted them mostly from
their Perl* counterparts)
Though I have to wonder how this will work with inter-language-operability.
Thanks, Leo.
Leopold Toetsch wrote:
Will Coleda [EMAIL PROTECTED] wrote:
Given a pmc, set a register to indicate whether
it is true or false from Tcl's POV.
inline op istrue(out INT, in PMC) {
with an approprate get_bool() vtable slot.
leo
Re: [perl #31987] Should predefined pmcs inherit nci methods?
Leopold Toetsch wrote: Sam Ruby [EMAIL PROTECTED] wrote: Concrete example: should ResizablePMCArray inherit sort from FixedPMCArray? Yes. But the inheritance should be (and is AFAIK already partially) in the method lookup. But it's not quite finished. Objects derived from PMCs inherit methods of the parent, but one level only. PMC inheritance isn't followed yet IIRC. I'm puzzled as to what works and what doesn't work. I added a __add__ method to pyobject and I can't access it from pyint... however I can access sort from ResizablePMCArray. Weird. I'm assuming the answer is yes, as classes defined via the subclass opcode seem to inherit non-vtable methods. In fact, I've made a number of assumptions, any of which could invalidate the attached patch. I'll look through it. But we'll very likely not do the static inheritance by duplicating NCI method slots. That would prevent to override a base class method. I did make it so that methods declared on one PMC would override methods declared in any parent... perhaps you are talking about methods defined at runtime in the bytecode? If you can sketch out what you would find to be an acceptable approach, I'll take a look at implementing it. Meanwhile, I'll see if I can isolate a test case. - Sam Ruby
Re: So long, and thanks for all the fish!
All~ I am willing to try and take on this responsibility. I have been reading p6i for several years now and always appreciated the summary, so what better way to give back. Any advice/scripts that Piers (or anyone else) can provide me would be appreciated. Matt -- Computer Science is merely the post-Turing Decline of Formal Systems Theory. -??? On Fri, 15 Oct 2004 10:05:21 +0200, Leopold Toetsch [EMAIL PROTECTED] wrote: The Perl 6 Summarizer [EMAIL PROTECTED] wrote: I tried, I really did, but I'm afraid that I must raise the white flag ..- Dan, Leo and the rest of the p6i team have done fantastic work Thanks for the flowers and of course for all your precise summaries. ... But if any of you are thinking I could do that! then don't let me stop you -- there's an awful lot goes on on the lists, and there's a lot of interested people who don't have the time to keep up with them. A regular summary helps the interested but busy people get a grasp of how the Perl 6 project is getting on, and that can only be a good thing. Yep, so please, interested folks, sharpen your pencil ... -- Piers Cawley -- Former Perl 6 Summarizer Thanks again, and maybe ex-former any tine, leo
Re: [perl #31987] Should predefined pmcs inherit nci methods?
At 9:33 AM -0400 10/15/04, Sam Ruby wrote: Leopold Toetsch wrote: Sam Ruby [EMAIL PROTECTED] wrote: Concrete example: should ResizablePMCArray inherit sort from FixedPMCArray? Yes. But the inheritance should be (and is AFAIK already partially) in the method lookup. But it's not quite finished. Objects derived from PMCs inherit methods of the parent, but one level only. PMC inheritance isn't followed yet IIRC. I'm puzzled as to what works and what doesn't work. I added a __add__ method to pyobject and I can't access it from pyint... however I can access sort from ResizablePMCArray. Weird. There are two basic classes of methods here. (And classes of classes, something I'm regretting, and I think we'll redo once I get a handle on metaclasses and just unify it all)[1] The first is the vtable method stuff. There's a static single inheritance scheme when Parrot's built. These methods are the *C* methods (not NCI or bytecode) and they get filled in at parrot build time. There's no runtime inheritance, lookups, or anything. The fixed method is what's called. (That the fixed method may then delegate to parrot methods confounds things a bit) The second is the *parrot* method stuff. These generally do a search of the hierarchy, at least if you're making a method call on a thing that's a ParrotObject. If you're making a method call on something else it depends on whether the method invocation code for that thing knows how to traverse the hierarchy. So basically it's a bit of a muddle, and it needs swamping out. [1] And yes, I am being dragged deep into objects. Kicking and screaming, but still.. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: So long, and thanks for all the fish!
Piers, Thanks for all the work you've done in keeping us up-to-date with Perl 6 developments. Your summaries have been crucial in convincing folks out there that much progress is being made, and that Perl 6 will be a language worth the wait. Kind regards, Paul Grassie [EMAIL PROTECTED] I tried, I really did, but I'm afraid that I must raise the white flag to my teacher training for the next while and give up writing the Perl 6 Summary until at least after Christmas. I've had a great time doing this for the last two and a half years, I hope you've all enjoyed it too. It's been a privilege to see the progress that's been made with Parrot since I started. Dan, Leo and the rest of the p6i team have done fantastic work -- it's only when you stop to think about what Parrot looked like two years ago and then compare it with the recent release that you get a real sense of how far we've come. Thanks guys. Thanks to the language folks, Larry, Allison, Damian, and all the many and various denizens of perl6-language. Following the list has been an education. Every time I find myself thinking a proposal is simply poisonous, along comes Larry in fugu-chef mode to extract the good stuff that sets your mind a tingling and chuck away the stuff that would leave you paralyzed and dying on the floor. I don't know how he does it, but I'm very glad that he can. It's no wonder that p6l felt like it was spinning its wheels for a while there while Larry was busy being ill. Thanks to O'Reilly for continuing to publish the summaries on perl.com, and to Robert Spier and Ask for holding their archives on perl.org (and for all the other work they do for perl.org, including the various RT installations). The work they did in getting the perl6 lists onto groups.google.com made the task of working out appropriate URLs for messages far easier than in the bad old days. Thanks to everyone who ever sent me feedback; I've mentioned Warnock's dilemma many times in these summaries, it's always good to be gently lifted from its horns by a word or two of praise or damnation. While I'm about it, thanks to Bryan Warnock for first identifying his dilemma and for writing the original Perl 6 summaries that gave me the idea in the first place. Thanks to you all for reading, whether you sent me feedback or not. I'm not about to stop writing. I'm slowly working through chromatic's 'Write Your Life' project. It's far easier than summarizing; all the material I need is already in my head, and I can bash out words even when I don't have net access. I may not have stopped writing the summaries for good either; I just haven't got computrons to spare for writing them at the moment. But if any of you are thinking I could do that! then don't let me stop you -- there's an awful lot goes on on the lists, and there's a lot of interested people who don't have the time to keep up with them. A regular summary helps the interested but busy people get a grasp of how the Perl 6 project is getting on, and that can only be a good thing. Sorry things have rather fizzled out; I just didn't realise until I started quite how demanding this course would be. And I don't just mean because I've got to wear a suit. -- Piers Cawley -- Former Perl 6 Summarizer http://www.bofh.org.uk/
Re: [Proposal] JIT, exec core, threads, and architectures
On Oct 14, 2004, at 12:10 PM, Leopold Toetsch wrote: Proposal: * we mandate that JIT code uses interpreter-relative addressing - because almost all platforms do it - because some platforms just can't do anything else - and of course to avoid re-JITting for every new thread FYI, the PPC JIT does already do parrot register addressing relative to the interpreter pointer, which as you said is already in a CPU register. This is actually less instructions than using absolute addressing would require (one rather than three). We do still re-JIT for each thread on PPC, though we wouldn't have to (just never changed it to not). But, we use this currently, because there is one issue with threads: With a thread, you don't start from the beginning of the JITted code segment, but rather you need to start with a specific Parrot function call, somewhere in the middle. But you can't just jump to that instruction, because it would not have the setup code needed when entering the JITted section. So currently, we use a technique whereby the beginning of the JITted section has, right after the setup code, a jump to the correct starting address--in the main thread case, this is just a jump to the next instruction (essentially a noop), but in the thread case, it's a jump to the function which the thread is going to run. So right now the JITted code for a secondary thread differs by one instruction from that for the main thread. We'll need to work out a different mechanism for handling this--probably just a tiny separate JITted section to set things up for a secondary thread, before doing an inter-section jump to the right place. JEff
Re: So long, and thanks for all the fish!
The Perl 6 Summarizer wrote: I tried, I really did, but I'm afraid that I must raise the white flag to my teacher training for the next while and give up writing the Perl 6 Summary until at least after Christmas. Bad food, lousy dental care, and now the childrens' education is entrusted to a chap who can't figure out how to smack one of the little buggers with a ruler. Five hundred years of empire come to this... Thanks to the language folks, Larry, Allison, Damian, and all the many and various denizens of perl6-language. Following the list has been an education. Every time I find myself thinking a proposal is simply poisonous, along comes Larry in fugu-chef mode to extract the good stuff that sets your mind a tingling and chuck away the stuff that would leave you paralyzed and dying on the floor. Yeah, we blowfish appreciate him, too. Thanks to everyone who ever sent me feedback; I've mentioned Warnock's dilemma many times in these summaries, it's always good to be gently lifted from its horns by a word or two of praise or damnation. Speaking of fishing ... I'm not about to stop writing. I'm slowly working through chromatic's 'Write Your Life' project. It's far easier than summarizing; all the material I need is already in my head, and I can bash out words even when I don't have net access. Just because Speedo sells an 'XXL' bathing suit doesn't make it a good idea to buy one ... (http://www.budlight.com - lifestyle - radio ads - Mr. Tiny Thong Bikini Wearer.mp3) A regular summary helps the interested but busy people get a grasp of how the Perl 6 project is getting on, and that can only be a good thing. Sorry things have rather fizzled out; I just didn't realise until I started quite how demanding this course would be. And I don't just mean because I've got to wear a suit. Oh, man! The speedo comment was supposed to be a joke, not foreshadowing... You, sir, have done a fine job of summarizing two lists. Frankly, I try to read just one in real time and it stumps me: I'm impressed at the amount of work (and free time) you've given us. I appreciate it, and I thank you for it. That'll do, Piers. That'll do. :) =Austin
Re: [perl #31987] Should predefined pmcs inherit nci methods?
Dan Sugalski wrote:
At 9:33 AM -0400 10/15/04, Sam Ruby wrote:
Leopold Toetsch wrote:
Sam Ruby [EMAIL PROTECTED] wrote:
Concrete example: should ResizablePMCArray inherit sort from
FixedPMCArray?
Yes. But the inheritance should be (and is AFAIK already partially) in
the method lookup. But it's not quite finished. Objects derived from
PMCs inherit methods of the parent, but one level only. PMC inheritance
isn't followed yet IIRC.
I'm puzzled as to what works and what doesn't work. I added a __add__
method to pyobject and I can't access it from pyint... however I can
access sort from ResizablePMCArray. Weird.
There are two basic classes of methods here. (And classes of classes,
something I'm regretting, and I think we'll redo once I get a handle on
metaclasses and just unify it all)[1]
The first is the vtable method stuff. There's a static single
inheritance scheme when Parrot's built. These methods are the *C*
methods (not NCI or bytecode) and they get filled in at parrot build
time. There's no runtime inheritance, lookups, or anything. The fixed
method is what's called. (That the fixed method may then delegate to
parrot methods confounds things a bit)
The second is the *parrot* method stuff. These generally do a search of
the hierarchy, at least if you're making a method call on a thing that's
a ParrotObject. If you're making a method call on something else it
depends on whether the method invocation code for that thing knows how
to traverse the hierarchy.
So basically it's a bit of a muddle, and it needs swamping out.
It still doesn't make sense to me. Try adding the following line to
both fixedpmcarray.pmc and perlint.pmc:
METHOD INTVAL inheritme() { return 42; }
Then try running the following:
.sub _main @MAIN
print test 1\n
$P0 = new ResizablePMCArray
$I1 = $P0.inheritme()
print $I1
print \n
print test 2\n
$P0 = new Boolean
$I1 = $P0.inheritme()
print $I1
print \n
.end
The output I get is:
test 1
42
test 2
Method 'inheritme' not found
in file '(unknown file)' near line -1
Apparently FixedPMCArray and PerlInt are different kinds of classes?
In any case, I would like to create some PMCs to represent Python
classes. And I would like to implement as many of the methods as I can
in C. And I would like such methods to be inherited.
I'm OK with a temporary solution (like the patch I provided) until a
real solution can be put in place.
Suggestions welcome.
[1] And yes, I am being dragged deep into objects. Kicking and
screaming, but still..
- Sam Ruby
Re: [perl #31992] [BUG] YetAnotherGarbageCollectionBug(tm)
Leopold Toetsch via RT wrote: Will Coleda [EMAIL PROTECTED] wrote: I noticed after a recent update that parts of the tcl test suite started failing. I finally tracked it down to the fact that I was NOT running with '-G'. tcl.pl dies at 19, removing or die fixes that. In my rush to get check back in to duplicate the bug, I created the same bug I did before since I hadn't pruned empty directories. Fixed. To your problem: Ctclobject is an abstract object, it doesn't have a vtable. But the bundling code *does* Cpmc_register this PMC. This leads to an empty vtable slot, dereferencing that NULL is an operation, which many systems don't like. After fixing that (or better working around - Cpmc_register shouldn't be called) it dies later and as usual by loosing CTclWords - it seems. My gut feeling is that CTclArray isn't quite up to data. It duplicates at firt sight just CPerlHash. But the latter has recent changes WRT hash creation, which aren't in CTclArray. Yup. Tcl* are all (except TclWord) cargo culted from the first time I submitted a patch. They've not been kept current since they were uncompilable until a week or two ago. I'd first reduce CTclArray to a bare minimum. Specifically the creation functions (init, clone) should be inherited (or follow the CPerlHash conventions). The same applies to any PMC that can hold pointers to other PMCs. These changes are necessary to make a PMC compliant with incremental GC. Please grep through the docs and the sources for DOD_WRITE_BARRIER. Hey, finally one of the GC bugs is my fault! I've claimed the ticket, I'll see what I can do.
