Re: [perl #41825] [BUG] morph vtable override not working in PIR
On Fri, Jan 16, 2009 at 11:34:05PM -0800, Allison Randal wrote: > > Not a string, a PMC (like Coke said). String type names are almost as > bad as type IDs. And check the performance on the branch, as I'm not > sure how heavily PGE is using morph. We may need both integer and PMC > versions of morph for the internals, but only allow the PMC one to be > overridden from PIR. Just for the record, AFAICT none of PGE/PCT/Rakudo make use of morph any longer. We now have the 'copy' opcode to do what the "morph workaround" was doing (and I don't think copy is using VTABLE_morph). Pm
Re: [perl #41825] [BUG] morph vtable override not working in PIR
Patrick R. Michaud wrote: Just for the record, AFAICT none of PGE/PCT/Rakudo make use of morph any longer. We now have the 'copy' opcode to do what the "morph workaround" was doing (and I don't think copy is using VTABLE_morph). We've been ripping out morph in all the core PMCs too. So, I'm comfortable transitioning to just a PMC argument to morph. Allison
Re: [perl #41825] [BUG] morph vtable override not working in PIR
Patrick R. Michaud wrote: Just for the record, AFAICT none of PGE/PCT/Rakudo make use of morph any longer. This is true AFAIK too. We now have the 'copy' opcode to do what the "morph workaround" was doing (and I don't think copy is using VTABLE_morph). IIRC, copy once used to, but stopped doing so when I realized that we morphed...and then copied right over whatever morph might have produced. :-) FWIW, I've yet to find a use case for morph in anything I've done in Rakudo. Between the copy op and our rebless_subclass dynop, we've got what we've needed to date. I'm curious - is anyone else doing a HLL on Parrot that uses morph? If nobody is, is it worth spending time on, or even worth keeping? Thanks, Jonathan
Re: [perl #41825] [BUG] morph vtable override not working in PIR
On Sat, Jan 17, 2009 at 11:11 AM, Jonathan Worthington wrote: > Patrick R. Michaud wrote: >> Just for the record, AFAICT none of PGE/PCT/Rakudo make use of >> morph any longer. > This is true AFAIK too. > >> We now have the 'copy' opcode to do what the "morph workaround" was doing >> (and I don't think copy is using VTABLE_morph). >> >> > IIRC, copy once used to, but stopped doing so when I realized that we > morphed...and then copied right over whatever morph might have produced. :-) > > FWIW, I've yet to find a use case for morph in anything I've done in > Rakudo. Between the copy op and our rebless_subclass dynop, we've got > what we've needed to date. > > I'm curious - is anyone else doing a HLL on Parrot that uses morph? If > nobody is, is it worth spending time on, or even worth keeping? > > Thanks, > > Jonathan > Tcl is using it, but only because we copied it from the Perl5 sample stuff a very long time ago. If it goes away, we can probably live with copy. -- Will "Coke" Coleda
Re: [perl #41825] [BUG] morph vtable override not working in PIR
> On Sat, Jan 17, 2009 at 11:11 AM, Jonathan Worthington >> I'm curious - is anyone else doing a HLL on Parrot that uses morph? If >> nobody is, is it worth spending time on, or even worth keeping? >> >> Thanks, >> >> Jonathan >> Even if the morph opcode isn't used often, the morph VTABLE interface is used quite a bit internally. There really isn't any easier and still standard way of changing between types for PMCs. It certainly beats having to invoke PMC methods internally to switch between types. --Andrew Whitworth
Re: [perl #41825] [BUG] morph vtable override not working in PIR
On Saturday 17 January 2009 10:36:13 Andrew Whitworth wrote: > Even if the morph opcode isn't used often, the morph VTABLE interface > is used quite a bit internally. There really isn't any easier and > still standard way of changing between types for PMCs. It certainly > beats having to invoke PMC methods internally to switch between types. I haven't been awake long, but could internal code call whatever the copy opcode calls? -- c
RE: Rakudo leaving the Parrot nest
> From: Patrick R. Michaud [mailto:pmich...@pobox.com] > [...] > Web site / blog / wiki > [...] > Currently Rakudo really does not have a dedicated website > providing basic information about it. There is the > http://rakudo.org/ site, but it's currently more of a > blog than a true web site. For example, someone visiting > rakudo.org would not be able to easily find out how to > download and run Rakudo Perl. > [...] > * The Perl Foundation hosts a "Perl 6 wiki" at > http://www.perlfoundation.org/perl6/index.cgi?perl_6 , > and Rakudo has a few pages there. Currently I find the > wiki to be not very well organized, and it's difficult to > find Rakudo out of the many other items that appear there. > Beyond that, I'm not impressed with the wiki engine the > site uses, but if a sizable group of people think that's > where Rakudo information should be centered then I can > live with it. The Perl 6 Wiki can be reorganized however you (and others) suggest. I'd be happy to do the wiki editing work. The November (Rakudo-based) wiki project should eventually provide a much better wiki engine than the current one. (BTW, what are your main issues with the current wiki engine, and preferred alternatives?) Best regards, Conrad Schneiker www.AthenaLab.com Official Perl 6 Wiki http://www.perlfoundation.org/perl6
Re: [perl #41825] [BUG] morph vtable override not working in PIR
From: Jonathan Worthington Date: Sat, 17 Jan 2009 17:11:23 +0100 I'm curious - is anyone else doing a HLL on Parrot that uses morph? Not me. -- Bob Rogers http://www.rgrjr.com/
Re: Rakudo leaving the Parrot nest
Sorry for the 'tldr' reply... On Jan 14, 9:01 pm, pmich...@pobox.com (Patrick R. Michaud) wrote: > Source code repository > -- > This is the immediate issue at hand, because we need to move Rakudo > out of the Parrot repository so that it can cleanly move to its new > home at parrot.org. I assume you're saying the parrot project will be moving from svn.perl.org to its own repo somewhere on the parrot domain. > Currently Rakudo Perl lives at > http://svn.perl.org/parrot/trunk/languages/perl6/, while the > spectest suite (on which development/testing depends) > lives at http://svn.pugscode.org/pugs/t/spec/. I propose a restructuring/divestiture of the pugscode and rakudo code repositories, as follows: 1. Centralize/reorganize the implementation-independent/agnostic resources, documentation, and tools under a new repository, which could be hosted at one of the perl6-related domain names I have, such as git:// (and http(s)://www.perlsix.org/git/perl6 for git-http-*), with automatic one-way (or two-way! with user impersonation) replication/mirroring to svn and/or bzr on launchpad.net/perl6. This repo would include both the human- readable (!) language specifications, and the machine- readable/testable language specifications (the spec tests), the standard grammar and its related tools, any global prelude, and all the other implementation-nonspecific items. The current pugscode user accounts can be migrated to whatever backs the authentication. 2. Leave the current svn.pugscode repo as is (except for the items listed above), so that all the other implementations and Perl6-related miscellany stored there can be migrated over to new repos as necessary. 3. Host the rakudo repository in git or whatever [else] is selected following the same convention, git/http(s)://www.perlsix.org/git/rakudo and http(s)://www.perlsix.org/svn/rakudo Use the same authentication store as http(s)://www.rakudo[perl].org (see below)... perhaps integrated with single-sign-on and unified-sign-on systems at launchpad.net, OpenID, BitCard, etc. > Many people have strongly suggested that we switch to > using "git" as our version control system. At the moment I'm > neither strongly in favor of nor strongly opposed to switching > version control systems, but we have to recognize that at least > two of Rakudo's "dependencies" (Parrot and the spectest suite) > are using Subversion and are likely to remain that way for > a while. We don't want to require non-developers to install a > lot of different source code control systems simply to run and > test the latest incarnation of Rakudo Perl. No, but for this use case, snapshots of the requisite Parrot release and then the client for whatever scm system Rakudo uses should be sufficient, since the spectest suite can be hosted in the same format, even if merely a one-way mirror. > Web site / blog / wiki > -- > Currently Rakudo really does not have a dedicated website > providing basic information about it. There is the > http://rakudo.org/site, but it's currently more of a > blog than a true web site. For example, someone visiting > rakudo.org would not be able to easily find out how to > download and run Rakudo Perl. As the site of a major implementation of a multi-implementation programming language, the www.rakudo(perl).* site(s) need to be similar in content to the sites, for the following use cases: www.ruby-lang.org www.python.org www.php.net 1. Obtain/Develop-ish category a. Download binaries/installer links b. Linux/BSD distribution/packages links (deb, rpm, launchpad) c. Build-from-source walkthrough (including dependencies) d. Contributor/developer initiation/training (1) git/svn training/walkthrough (2) bug-tracking system (launchpad.net?) links/tutorial (3) mailing list descriptions e. Spec-test progress/history/graphics f. Release announcements, developers' blog g. IRC links, logs h. gitweb and/or SVN::Web intefaces i. PCT tutorials/documentation 4. Discover-ish category a. Rakudo documentation, tutorials b. [Links to] Perl 6 documentation, specifications, tutorials c. User/community support forums & mailing lists (exposed through http, smtp, and nntp) d. Links to and/or aggregates of other/related blogs e. Links to Perl Foundation & development/benefactor news f. Link to www.perl.org or replicate much of its content g. Interactive web terminal to try out rakudo, "live" h. Links to sites/projects using rakudo I recommend hosting this site on the WebGUI CMS on a VPS I'll provide; I'll also provide a $30/year GoDaddy SSL certificate in perpetuity for privacy/security, though since it's an open-source project, the first year of the SSL cert may be free from GoDaddy. I have a VPS where the site (including all SCM repos) could be hosted; others' VPSes could provide backup destinations. One option is to set the http://www.rakudo.org page to redirect to http://ww
Re: [perl #41825] [BUG] morph vtable override not working in PIR
On Sat, Jan 17, 2009 at 2:12 PM, chromatic wrote: > I haven't been awake long, but could internal code call whatever the copy > opcode calls? I guess I don't know what people are talking about here with copy. But, I would be hesitant to remove morph in order to rely on some sideeffect of a different operation. If we want PMCs to be able to change their types, we want to use something that's specific for that behavior, not a copy that happens to be able to change the type of the things it copies. --Andrew Whitworth
