[perl #48467] [BUG] assignment of objects creates Ref instead of copy
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #48467] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48467 > Using assign with an Object causes it to create a Ref instead of assigning a copy. For example, given the following Perl 6 code: my $x = 0; my $y = 3.2; $x = $y; $y++; say $x; # outputs "4.2", should be "3.2" Here's a PIR version of the code and its output: $ cat y.pir .sub main $P0 = subclass 'Float', 'Num' ## my $x = 0; $P1 = new 'Integer' $P1 = 0 .lex '$x', $P1 ## my $y = 3.2; $P2 = new 'Num' $P2 = 3.2 .lex '$y', $P2 ## $x = $y; $P3 = find_lex '$y' $P4 = find_lex '$x' morph $P4, 'Undef' assign $P4, $P3 ## $y++; $P5 = find_lex '$y' inc $P5 ## say '$x = ', $x; $P6 = find_lex '$x' print "$x = " say $P6 .end $ ./parrot y.pir $x = 4.2 This problem is blocking completion of a few 01-sanity tests -- for example, using typeof on a Ref object returns 'Ref' instead of the type of the referenced object. This is blocking completion of 07-ref.t and 07-isa.t tests. Resolving ticket #47828 (copy opcode) may also help with this particular issue, but at the moment we're a bit stuck. Pm
Re: Standards bearers (was "Re: xml and perl 6")
On Sunday 09 December 2007 22:04:30 Richard Hainsworth wrote: > I download pugs and parrot from > SVN repositories, written tests - one of which still hangs the > compilation of pugs. Indeed the test I wrote for pugs concerned the > ability of pugs to use existing CPAN modules. I have tried parrot with > SDL and the tests fail. My aim was to write a P6 GUI module so that from > the start it would be easy for P6 users to generate UI interfaces easily. If you send me or the Parrot list the Parrot test results, I will do my best to fix them. > Unfortunately, despite my eagerness, I am not a professional programmer > with the time or the skill to fix the problems. Where I can contribute > is to express a view about how P6 might best be developed. Hey, I'm a trained musician and sometimes novelist who develops software on the side, and the primary reasons @Larry absorbed me are that: 1) I transcribe conversations faster than anyone else on the team 2) I had a working keycard to O'Reilly's Tarsier meeting room in Sebastopol and the reason I keep working on this stuff is: 3) I'm some combination of too stubborn or too stupid not to keep working on it All it takes to make a contribution is a fraction of my stupid or my stubborn plus some spare time. -- c
Re: Platform testing for concurrency scheduler runloop
Andy Armstrong wrote: Again, let me know if you need more. I pushed it far enough that I was able to repeat the deadlock hang on OS 10.4.11, that's good. The interesting thing was the order of operations. The usual order is: call to Parrot_cx_init_scheduler initializing scheduler runloop started scheduler runloop sleeping in scheduler runloop call to Parrot_cx_runloop_end terminating scheduler runloop handling tasks in scheduler runloop Found task ID # 1 ended scheduler runloop with initialization, followed by running, followed by termination. The hang happened with: call to Parrot_cx_init_scheduler initializing scheduler runloop call to Parrot_cx_runloop_end started scheduler runloop terminating scheduler runloop sleeping in scheduler runloop where the call to terminate the runloop happens before the runloop even gets fully started. That gives me an area of code to focus on, in reviewing for sources of deadlocks. (This whole headache is because the scheduler is currently using mutex/lock variable sharing instead of STM. Which is nice confirmation to me that we should be moving the core sharing strategy to STM, after we more fully develop Parrot's STM implementation.) Allison
Re: [PROPOSAL] Remove Absolute PASM registers from PIR. (was: Re: [BUG] imcc register allocation does not consider PASM register usage)
On Dec 11, 2007 8:43 AM, Joshua Isom <[EMAIL PROTECTED]> wrote:
>
> On Dec 10, 2007, at 10:59 AM, Klaas-Jan Stol wrote:
>
> > In order to draw attention to this point, I changed the subject.
> >
> > Is there anybody who thinks the removal from PIR of $-less registers
> > ("absolute" or PASM registers) should not be done?
> >
> > kjs
> >
>
> Parrot provides a calling convention, but does not, that I know of,
> mandate that calling convention. In any computer, there are multiple
> calling conventions used(often leading to a lack of interoperability,
> but nevertheless present). The system itself uses specific registers.
> Mixing absolute and relative registers in PIR does cause problems, but
> a program that solely used absolute registers and its own calling
> convention shouldn't be necessarily forbidden. Currently parrot has
> several ops that assist a different language/calling convention, such
> as bsr, and others of it's ilk. Mixing those ops and the "standard"
> calling convention ops together will probably cause massive problems,
> but they still exist(even if they're there more because they were long
> ago rather than need to be).
I thought the parrot calling conventions were changed so, that it doesn't
use these specific regs.
(the old pcc said, that in I0, I1, I2 etc, special info about the invocation
can be found, while the args were stored in specific regs.)
I may be wrong.
kjs
Re: Standards bearers (was "Re: xml and perl 6")
At 10:23 AM +0300 12/11/07, Richard Hainsworth wrote: Darren Duncan wrote: At 9:04 AM +0300 12/10/07, Richard Hainsworth wrote: Equally, Something to replace CGI or DBI will be essential to the uptake of P6. I would far prefer to have a skilled and resourceful professional, such as yourself or Damian Conway write these modules than leave it to enthusiastic amateurs such as myself. I for one can assert that both of these are being produced right now. Also that neither is part of the Perl 6 kernal, though the kernal may enhanced over time to better support them. -- Darren Duncan A great relief. Fantastic. Where should I be looking to see what is happening. Is there some form of coordination of this module writing activity? Look in the ext/ subdirectory of Pugs version control to start with, as it contains a bunch of Perl 6 modules in various stages of completion, some doing http or web stuff, and some doing database stuff. One place to look for some coordination is on the perl6-users list. They were discussing a CGI replacement awhile ago, and Juerd made a proposal plus some example code, which became HTTP/ and Web/ under ext/. On various DBI lists there was some talk about DBI-2, which it ended up will have a foundation written for Parrot with bindings for Perl and other languages. There is also a mod_parrot project. There is also my Muldis DB project, a version of which is written in Perl 6, and which is being built rigorously. These efforts are all separate from each other, as per CPAN module development in general, and there is no one coordination point of all of it. But the work is still getting done nonetheless. As for standards, well those tend to be defacto. Whichever of these projects get functional and used will likely set the pace for what comes next, which may include forming the basis for more formal standards. -- Darren Duncan
Re: Status of docs/embed.pod and Parrot::Embed?
Andy Armstrong wrote: Where might a volunteer start? I also promised Yuval that I'd refactor Test::TAP::Model to use Test::Harness 3.00 - so to some extent I've answered my own question - but I'd like to get my hands dirty with Parrot proper too. There's a tricky spot at the very beginning where you need to learn just enough about the internals to solve one problem/accomplish one task. From there, it's just a matter of expanding your knowledge outward to accomplish the next task. We don't have an exact science for getting new contributors through that first bit. Even excellent documentation (which we don't have yet), isn't quite enough to carry contributors from "thinking" to "doing". What seems to work the best is if you pick a task or problem that's interesting to you, for whatever reason. The interest and curiosity keeps you motivated through the first task. Everyone's different, so the tasks that interest you won't be the same as the tasks that interest me or the next new contributor. Sometimes at hackathons I've gone through the ticket queue with new contributors until I see their eyes light up at a particular task. I know that's where they should start. Coding is just a little bit zen. "Programmer who can catch a fly with chopsticks can accomplish anything." Allison
Re: [PROPOSAL] Remove Absolute PASM registers from PIR. (was: Re: [BUG] imcc register allocation does not consider PASM register usage)
On Dec 11, 2007 8:43 AM, Joshua Isom <[EMAIL PROTECTED] Parrot provides a calling convention, but does not, that I know of, mandate that calling convention. In any computer, there are multiple calling conventions used(often leading to a lack of interoperability, but nevertheless present). The system itself uses specific registers. Mixing absolute and relative registers in PIR does cause problems, but a program that solely used absolute registers and its own calling convention shouldn't be necessarily forbidden. The thing is, PIR doesn't respect the register numbers anyway (even in the so-called "absolute" registers). So P33 in the PIR source may compile down to P0, and P0 in the PIR source may compile down to P15. (Try "-o file.pasm" on any random PIR file that uses "absolute" registers.) We're not eliminating a feature, we're just making it clear that the feature doesn't exist. (And eliminating the confusion of people expecting it to exist.) Currently parrot has several ops that assist a different language/calling convention, such as bsr, and others of it's ilk. Mixing those ops and the "standard" calling convention ops together will probably cause massive problems, but they still exist(even if they're there more because they were long ago rather than need to be). In PIR, 'bsr' only works within a compilation unit (that is, within a subroutine). It doesn't work between compilation units. So, you really have to fall back to PASM to fully use those features anyway. Klaas-Jan Stol wrote: I thought the parrot calling conventions were changed so, that it doesn't use these specific regs. Yes, the calling conventions now use 'get_params' and 'get_results' to specify where the arguments/return values should be stored, instead of using specific registers. Allison
Re: VMs in the news
On 11 Dec 2007, at 04:57, Randal L. Schwartz wrote: "Andy" == Andy Armstrong <[EMAIL PROTECTED]> writes: Andy> Rubinus (new Ruby runtime) Andy> http://www.infoq.com/news/2007/12/engine-yard-bets-big-rubinius I'm trying to figure out why Rubinous is building a squeak-like vm when squeak already has a vm. They would have been done faster had they generated Squeak bytecodes. It'd be interesting to get all these folk who are working on VMs around a table to chat about their respective rationales. Or perhaps somebody could podcast an interview with them? :) -- Andy Armstrong, Hexten
Re: [perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2 config steps
On Mon, 10 Dec 2007, James Keenan wrote: > The patch attached proposes to refactor Parrot configuration step > class inter::progs into two classes: inter::compiler and inter::progs. > > inter::compiler will search for a C compiler, process any --cc option > set on the command line and, if interactive configuration has been > requested via command-line option --ask, prompt the user for the > location of the desired C compiler. It will then conduct a basic > test of that compiler's functioning. If interactive configuration > has been requested, this step will print the introductory information > currently printed by inter::progs. I don't think this will work. Specifically, to conduct a "basic test of that compiler's functioning" you need to compile *and link* a program, but you haven't picked a linker yet. (Recall that at least on VMS and Win32, the linker can be a distinct program from the compiler.) You also haven't given the the user any opportunity to supply the appropriate ccflags that might be needed to compile with this particular compiler. For example, if you are using an add-on compiler that uses a non-standard #include directory, you might need to add a flag something like gcc's -nostdinc to get even a simple program compiling. For example, the Tendra compiler (tcc) won't ordinarily work without some added flags, such as -Ysystem. -- Andy Dougherty [EMAIL PROTECTED]
Re: [PATCH] [NQP] Use || in places where order matters
On Sun, Dec 09, 2007 at 10:36:19AM -0600, Jonathan Scott Duff wrote: >I understand that | and || may not actually be differentiated in >implementation yet, but they do different things according to the spec. >I've attached a patch for NQP to change | to || in places where I think it >matters. Applied in r23744, thanks! Pm
Re: [perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2 config st
>From: Andy Dougherty via RT >Date: 2007/12/11 Tue AM 08:38:17 CST >Subject: Re: [perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2 >config steps > >I don't think this will work. Specifically, to conduct a "basic test of >that compiler's functioning" you need to compile *and link* a program, but >you haven't picked a linker yet. Andy, that's what I thought at first, and you may well be correct. However, as I read the code in the current HEAD of config/inter/progs.pm, the *only* variable passed to the internal test_compiler subroutine is $cc (line 130). $cc is assigned to much farther up inside the runstep() method (lines 61-62), and immediately thereafter assigned to the 'cc' argument in the Parrot::Configure object (line 63). All the other values you mention are assigned between lines 64 and 130, but, AFAICT, none of those assignments depend on either $cc or the value assigned to 'cc' inside the configuration object. The test_compiler() method, *as written*, does not appear to depend at all on any of the other values located on the system or selected at the prompt, and it does not appear to depend on the Parrot::Configure object. If so, then the refactoring I suggested is plausible. Of course, it may very well be that test_compiler() was misconceived all along and that it *should* have been passed the current state of the Parrot::Configure object ($conf). What do you think? kid51
Re: VMs in the news
> "Andy" == Andy Armstrong <[EMAIL PROTECTED]> writes: Andy> Or perhaps somebody could podcast an interview with them? :) Perhaps you were joking, but I noted that as a potential show for FLOSS Weekly. Thanks for the idea. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: VMs in the news
On 11 Dec 2007, at 17:28, Randal L. Schwartz wrote: "Andy" == Andy Armstrong <[EMAIL PROTECTED]> writes: Andy> Or perhaps somebody could podcast an interview with them? :) Perhaps you were joking, but I noted that as a potential show for FLOSS Weekly. Thanks for the idea. Not joking just poking. I look forward to it. -- Andy Armstrong, Hexten
Re: VMs in the news
On Tuesday 11 December 2007 03:58:38 Andy Armstrong wrote: > It'd be interesting to get all these folk who are working on VMs > around a table to chat about their respective rationales. That may happen in early February. It did happen for a bit at Foo Camp this summer. > Or perhaps somebody could podcast an interview with them? :) Heh. Randal knows where to find at least me if he needs me. -- c
Re: [perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2 config st
On Tue, 11 Dec 2007, Jim Keenan wrote: > >From: Andy Dougherty via RT > >Date: 2007/12/11 Tue AM 08:38:17 CST > >Subject: Re: [perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2 > >config steps > > > > >I don't think this will work. Specifically, to conduct a "basic test of > >that compiler's functioning" you need to compile *and link* a program, but > >you haven't picked a linker yet. > > Andy, that's what I thought at first, and you may well be correct. > > However, as I read the code in the current HEAD of > config/inter/progs.pm, the *only* variable passed to the internal > test_compiler subroutine is $cc (line 130). $cc is assigned to much > farther up inside the runstep() method (lines 61-62), and immediately > thereafter assigned to the 'cc' argument in the Parrot::Configure object > (line 63). All the other values you mention are assigned between lines > 64 and 130, but, AFAICT, none of those assignments depend on either $cc > or the value assigned to 'cc' inside the configuration object. The > test_compiler() method, *as written*, does not appear to depend at all > on any of the other values located on the system or selected at the > prompt, and it does not appear to depend on the Parrot::Configure > object. If so, then the refactoring I suggested is plausible. I think you're missing three things: 1. test_compiler() calls cc_build(), which most definitely does need to use $ccflags and $link. 2. The settings of things like ccflags and ldflags *could* depend on the compiler, even if the current inter/progs.pm file doesn't actually implement that. Recognizing that some compilers are available on more than one platform, it makes sense to handle them in inter/progs.pm, not duplicate them in different hints files. For now, though, such information is buried in various hints files. For example, look at hints/linux.pm -- three different compilers are dealt with there. 3. Triggers (or callbacks) can change the flow in hidden ways. For example, the solaris hints file sets the value of $link depending on whether the user is using cc or gcc. > Of course, it may very well be that test_compiler() was misconceived all > along and that it *should* have been passed the current state of the > Parrot::Configure object ($conf). What do you think? cc_build() consults the global $conf, and hence doesn't need it passed in. I would certainly agree that the flow of information isn't well controlled here. Passing the object in sometimes and other times consulting the global object does seem like a recipe for confusion. It might make sense to always do one or the other. -- Andy Dougherty [EMAIL PROTECTED]
[perl #47828] [TODO] Implement the 'copy' opcode
Task description: Add an opcode 'copy' to src/ops/set.ops. Similar to 'clone'. - It takes two PMC arguments - It calls VTABLE_morph on $1, and then VTABLE_assign on the two. - It needs to call VTABLE_type to get the type of the source PMC to pass to 'morph' instead of calling $1->vtable->base_type, because the base_type won't be right for Object PMCs.
[perl #48020] [DEPRECATED] find_name opcode
The reports of find_name's death are greatly exaggerated. Rejecting ticket. Pm
Re: Status of docs/embed.pod and Parrot::Embed?
On 11 Dec 2007, at 09:20, Allison Randal wrote: Coding is just a little bit zen. "Programmer who can catch a fly with chopsticks can accomplish anything." Nah, I couldn't possibly code while I was running around trying to hit a fly with a stick :) I guess once I get some headspace I'll just pick a ticket and run with it, thanks. -- Andy Armstrong, Hexten
Re: Status of docs/embed.pod and Parrot::Embed?
On 11 Dec 2007, at 22:39, Tim Bunce wrote: Perhaps new contributors could make notes about stumblings blocks encountered along the way, so we know where to put signposts for others who follow. Good plan. I'll keep notes. -- Andy Armstrong, Hexten
Re: Status of docs/embed.pod and Parrot::Embed?
On Tue, Dec 11, 2007 at 11:20:39AM +0200, Allison Randal wrote: > Andy Armstrong wrote: >> >> Where might a volunteer start? >> >> I also promised Yuval that I'd refactor Test::TAP::Model to use >> Test::Harness 3.00 - so to some extent I've answered my own question - but >> I'd like to get my hands dirty with Parrot proper too. > > There's a tricky spot at the very beginning where you need to learn just > enough about the internals to solve one problem/accomplish one task. From > there, it's just a matter of expanding your knowledge outward to accomplish > the next task. We don't have an exact science for getting new contributors > through that first bit. Even excellent documentation (which we don't have > yet), isn't quite enough to carry contributors from "thinking" to "doing". > > What seems to work the best is if you pick a task or problem that's > interesting to you, for whatever reason. The interest and curiosity keeps > you motivated through the first task. Everyone's different, so the tasks > that interest you won't be the same as the tasks that interest me or the > next new contributor. Sometimes at hackathons I've gone through the ticket > queue with new contributors until I see their eyes light up at a particular > task. I know that's where they should start. Perhaps new contributors could make notes about stumblings blocks encountered along the way, so we know where to put signposts for others who follow. Tim.
Re: [perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2 config steps
> On Mon, 10 Dec 2007, James Keenan wrote: > >> The patch attached proposes to refactor Parrot configuration step >> class inter::progs into two classes: inter::compiler and inter::progs. >> Are we at any risk of redoing work here? Other OSS projects must presumably have faced the same problems. How do they deal with them, and can we lift those solutions? (Or are we aspiring to a higher standard?) -- Email and shopping with the feelgood factor! 55% of income to good causes. http://www.ippimail.com
Re: Standards bearers (was "Re: xml and perl 6")
duh. I'll learn to finish reading all the posts before adding my own *someday*. --- Darren Duncan <[EMAIL PROTECTED]> wrote: > At 10:23 AM +0300 12/11/07, Richard Hainsworth wrote: > >Darren Duncan wrote: > >>At 9:04 AM +0300 12/10/07, Richard Hainsworth wrote: > >>>Equally, Something to replace CGI or DBI will be essential to the > >>>uptake of P6. I would far prefer to have a skilled and resourceful > > >>>professional, such as yourself or Damian Conway write these > >>>modules than leave it to enthusiastic amateurs such as myself. > >> > >>I for one can assert that both of these are being produced right > >>now. Also that neither is part of the Perl 6 kernal, though the > >>kernal may enhanced over time to better support them. -- Darren > >>Duncan > > > >A great relief. Fantastic. > > > >Where should I be looking to see what is happening. Is there some > >form of coordination of this module writing activity? > > Look in the ext/ subdirectory of Pugs version control to start with, > as it contains a bunch of Perl 6 modules in various stages of > completion, some doing http or web stuff, and some doing database > stuff. > > One place to look for some coordination is on the perl6-users list. > They were discussing a CGI replacement awhile ago, and Juerd made a > proposal plus some example code, which became HTTP/ and Web/ under > ext/. > > On various DBI lists there was some talk about DBI-2, which it ended > up will have a foundation written for Parrot with bindings for Perl > and other languages. > > There is also a mod_parrot project. > > There is also my Muldis DB project, a version of which is written in > Perl 6, and which is being built rigorously. > > These efforts are all separate from each other, as per CPAN module > development in general, and there is no one coordination point of all > > of it. > > But the work is still getting done nonetheless. > > As for standards, well those tend to be defacto. Whichever of these > projects get functional and used will likely set the pace for what > comes next, which may include forming the basis for more formal > standards. > > -- Darren Duncan > Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Re: Standards bearers (was "Re: xml and perl 6")
It also helps that you consistently make incisive observations and contributions to conversations, even if they are a little tart sometimes. :) But on this general note, is there any current organization or location where small problems are being parcelled out? I'd love to help, but my time is as limited as everyone's If I could get small bites of work to do, maybe I could contribute something useful. Anyone requesting one black-box module or function at a time? Or am I pipe dreaming? --- chromatic <[EMAIL PROTECTED]> wrote: > On Sunday 09 December 2007 22:04:30 Richard Hainsworth wrote: > > > I download pugs and parrot from > > SVN repositories, written tests - one of which still hangs the > > compilation of pugs. Indeed the test I wrote for pugs concerned the > > ability of pugs to use existing CPAN modules. I have tried parrot > with > > SDL and the tests fail. My aim was to write a P6 GUI module so that > from > > the start it would be easy for P6 users to generate UI interfaces > easily. > > If you send me or the Parrot list the Parrot test results, I will do > my best > to fix them. > > > Unfortunately, despite my eagerness, I am not a professional > programmer > > with the time or the skill to fix the problems. Where I can > contribute > > is to express a view about how P6 might best be developed. > > Hey, I'm a trained musician and sometimes novelist who develops > software on > the side, and the primary reasons @Larry absorbed me are that: > > 1) I transcribe conversations faster than anyone else on the team > 2) I had a working keycard to O'Reilly's Tarsier meeting room in > Sebastopol > > and the reason I keep working on this stuff is: > > 3) I'm some combination of too stubborn or too stupid not to keep > working on > it > > All it takes to make a contribution is a fraction of my stupid or my > stubborn > plus some spare time. > > -- c > Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
[perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2 config steps
Steve Peters' posting didn't make it to RT, so I'm excerpting it here. [EMAIL PROTECTED] wrote: hints/linux.pm should really have separate flags for even g++, since some warnings just don't work on g++. I think it would be good if we could break out compilers separately from the operating system. This is especially useful for Sun Studio, where ccflags cross operating systems. Intel C tends to follow what the primary system compilers, but it still runs on three distinct operating system with some slight differences across the environments. Steve Peters [EMAIL PROTECTED]
[perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2 config steps
Resolved by withdrawal.
Re: Standards bearers (was "Re: xml and perl 6")
Paul Hodges wrote: But on this general note, is there any current organization or location where small problems are being parcelled out? I'd love to help, but my time is as limited as everyone's If I could get small bites of work to do, maybe I could contribute something useful. Anyone requesting one black-box module or function at a time? Or am I pipe dreaming? I've also been looking for something to do. Some organization ( or direction on where to go ) on this would be excellent. -- _ispy++ >> [EMAIL PROTECTED] :: use Perl;
[perl #48493] [CAGE] Parrot::Configure::Step: Explicitly pass all arguments to all methods
# New Ticket Created by James Keenan # Please include the string: [perl #48493] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48493 > Pursuant to discussion between Andy Dougherty and myself in http:// rt.perl.org/rt3/Ticket/Display.html?id=48459, review all subroutines in lib/Parrot/Configure/Step.pm to guarantee that the arguments which each needs are explicitly passed to it. In particular, revise cases where subroutines examine the Parrot::Configure object ($conf) without having it explicitly passed to the routine. The principal offenders appear to be: cc_build() cc_run() cc_run_capture() Step.pm manages to pass 'perl -c' because it declares a $conf which is a Parrot::Configure object. It manages to get away with this because the Parrot::Configure object is a singleton. Hence the constructor call at line 39 returns the same Parrot::Configure object that was created in Configure.pl. Then revise all calls to these subs in the step classes and subclasses underneath config/ so that $conf is explicitly passed. kid51
[perl #48495] [CAGE] vtable.tbl is source...
# New Ticket Created by Will Coleda # Please include the string: [perl #48495] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48495 > ... and should be in the src/ directory. It's referenced in a lot of places (docs, build, tools) and they all need to be updated to point to the new location. -- Will "Coke" Coleda
[perl #48497] [BUILD] Missing opcodes should be an error
# New Ticket Created by Will Coleda # Please include the string: [perl #48497] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48497 > When building parrot, we get the following warning: setstdout_p SKIPPED: not in ops.num nor ops.skip setstderr_p SKIPPED: not in ops.num nor ops.skip This should instead be an error and stop the build. If an opcode is in one of the primary ops files, it should be built with parrot; If it's experimental and we don't want it to be kept in ops.num forever, then it should be in experimental.ops.. Making this an error insures that whoever adds an opcode knows they need to add it to experimental.ops or to ops.num; These ops seem to have been committed in r13773 over a year ago and have apparently never been used. (for bonus points, once you make this an error, move these two ops into experimental.ops, since we don't know what their final disposition is.) -- Will "Coke" Coleda
Re: [perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2 config st
On Dec 11, 2007 12:40 PM, Andy Dougherty <[EMAIL PROTECTED]> wrote: > On Tue, 11 Dec 2007, Jim Keenan wrote: > > > >From: Andy Dougherty via RT > > >Date: 2007/12/11 Tue AM 08:38:17 CST > > >Subject: Re: [perl #48459] [PATCH]: Refactor config/inter/progs.pm into > > >2 config steps > > > > > > > >I don't think this will work. Specifically, to conduct a "basic test of > > >that compiler's functioning" you need to compile *and link* a program, but > > >you haven't picked a linker yet. > > > > Andy, that's what I thought at first, and you may well be correct. > > > > However, as I read the code in the current HEAD of > > config/inter/progs.pm, the *only* variable passed to the internal > > test_compiler subroutine is $cc (line 130). $cc is assigned to much > > farther up inside the runstep() method (lines 61-62), and immediately > > thereafter assigned to the 'cc' argument in the Parrot::Configure object > > (line 63). All the other values you mention are assigned between lines > > 64 and 130, but, AFAICT, none of those assignments depend on either $cc > > or the value assigned to 'cc' inside the configuration object. The > > test_compiler() method, *as written*, does not appear to depend at all > > on any of the other values located on the system or selected at the > > prompt, and it does not appear to depend on the Parrot::Configure > > object. If so, then the refactoring I suggested is plausible. > > I think you're missing three things: > > 1. test_compiler() calls cc_build(), which most definitely does need to > use $ccflags and $link. > > 2. The settings of things like ccflags and ldflags *could* depend on > the compiler, even if the current inter/progs.pm file doesn't actually > implement that. Recognizing that some compilers are available on more > than one platform, it makes sense to handle them in inter/progs.pm, not > duplicate them in different hints files. For now, though, such > information is buried in various hints files. For example, look at > hints/linux.pm -- three different compilers are dealt with there. > > 3. Triggers (or callbacks) can change the flow in hidden ways. For > example, the solaris hints file sets the value of $link depending on > whether the user is using cc or gcc. > > > Of course, it may very well be that test_compiler() was misconceived all > > along and that it *should* have been passed the current state of the > > Parrot::Configure object ($conf). What do you think? > > cc_build() consults the global $conf, and hence doesn't need it passed in. > I would certainly agree that the flow of information isn't well controlled > here. Passing the object in sometimes and other times consulting the > global object does seem like a recipe for confusion. It might make sense > to always do one or the other. > hints/linux.pm should really have separate flags for even g++, since some warnings just don't work on g++. I think it would be good if we could break out compilers separately from the operating system. This is especially useful for Sun Studio, where ccflags cross operating systems. Intel C tends to follow what the primary system compilers, but it still runs on three distinct operating system with some slight differences across the environments. Steve Peters [EMAIL PROTECTED]
Memory checking I've been working on lately
Now that I've got all but one function headerized, I'm running splint.
One of the things that splint is good at, and the reason I did all the
PARROT_CAN(NOT)_RETUN_NULL flags, is it'll keep track of when something
could be NULL or not. So splint complains here:
char * const p = malloc(n);
p->foo = ...
and not here
char * const p = mem_sys_allocate(n);
p->foo = ...
because mem_sys_allocate() is marked as PARROT_CANNOT_RETURN_NULL.
So I can do this in PackFile_new:
Index: src/packfile.c
===
--- src/packfile.c (revision 23681)
+++ src/packfile.c (working copy)
@@ -1119,24 +1119,14 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
-PARROT_CAN_RETURN_NULL
+PARROT_CANNOT_RETURN_NULL
PackFile *
PackFile_new(PARROT_INTERP, INTVAL is_mapped)
{
PackFile * const pf = mem_allocate_zeroed_typed(PackFile);
-if (!pf) {
-PIO_eprintf(NULL, "PackFile_new: Unable to allocate!\n");
-return NULL;
-}
pf->is_mmap_ped = is_mapped;
-
pf->header = mem_allocate_zeroed_typed(PackFile_Header);
-if (!pf->header) {
-PIO_eprintf(NULL, "PackFile_new: Unable to allocate header!
\n");
-PackFile_destroy(interp, pf);
-return NULL;
-}
/*
* fill header with system specific data
*/
Index: include/parrot/packfile.h
===
--- include/parrot/packfile.h (revision 23681)
+++ include/parrot/packfile.h (working copy)
@@ -453,7 +453,7 @@
PARROT_API
PARROT_WARN_UNUSED_RESULT
-PARROT_CAN_RETURN_NULL
+PARROT_CANNOT_RETURN_NULL
PackFile * PackFile_new(PARROT_INTERP, INTVAL is_mapped)
__attribute__nonnull__(1);
The other thing to come out of this instrumentation is when splint tells
us that we can be dereferencing NULL, as in here:
intlist_get(PARROT_INTERP, NOTNULL(IntList *list), INTVAL idx)
{
/* XXX list_get can return NULL RT #48367 */
void * const ret = list_get(interp, (List *)list, idx,
enum_type_INTVAL);
const INTVAL retval = ret == (void *)-1 ? 0 : *(INTVAL *)ret;
ret could be NULL, but we're not checking that, so it's possible to
de-refernece a NULL.
So that's what I'm workin' on, running splint, fixing headerizations,
etc. Let me know if anything shakes loose, or looks crazy, or causes
problems with your specific compiler. I'd especially like it if someone
non-GCC has compiler options that we can put into
PARROT_CANNOT_RETURN_NULL and its brethren so we have more compilers
watching our backs.
xoxo,
Andy
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: [perl #48459] [PATCH]: Refactor config/inter/progs.pm into 2config st
On Tue Dec 11 10:41:18 2007, doughera wrote: [snip] > > I think you're missing three things: > > cc_build() consults the global $conf, and hence doesn't need it passed > in. > I would certainly agree that the flow of information isn't well > controlled > here. Passing the object in sometimes and other times consulting the > global object does seem like a recipe for confusion. It might make > sense > to always do one or the other. > You're (unnumbered) fourth point is, IMHO, the decisive one. You have called my attention to two big puddles of parrot excrement sitting on the bottom of the cage. Neither cc_build() nor cc_run() fully encapsulates its arguments. This is what led me astray. Patch is withdrawn. Expect to see a [CAGE] ticket filed soon to make all these C-related Parrot::Configure::Step methods require all their arguments to be explicitly passed. You'll probably also see a new branch created to test out these revisions. Since this cage-cleaning can be accomplished by any competent Perl 5 hackers, I should ask: Are there any new Parrot folks out there who would like to take this job on? kid51 >
Re: [PROPOSAL] Remove Absolute PASM registers from PIR. (was: Re: [BUG] imcc register allocation does not consider PASM register usage)
From: Allison Randal <[EMAIL PROTECTED]> Date: Tue, 11 Dec 2007 11:51:52 +0200 The thing is, PIR doesn't respect the register numbers anyway (even in the so-called "absolute" registers). So P33 in the PIR source may compile down to P0, and P0 in the PIR source may compile down to P15. (Try "-o file.pasm" on any random PIR file that uses "absolute" registers.) We're not eliminating a feature, we're just making it clear that the feature doesn't exist. (And eliminating the confusion of people expecting it to exist.) The feature could continue to exist -- without the confusion -- by providing a way to disable register allocation altogether. The IMCC parseflags function already has code to select between the "vanilla" allocator and a graph-based allocator depending on optimization level; adding a "null" allocator ought to be useful for debugging. True? -- Bob Rogers http://rgrjr.dyndns.org/
Re: [perl #47828] [TODO] Implement the 'copy' opcode
On Tuesday 11 December 2007 12:35:19 Allison Randal via RT wrote:
> Task description:
>
> Add an opcode 'copy' to src/ops/set.ops. Similar to 'clone'.
>
> - It takes two PMC arguments
>
> - It calls VTABLE_morph on $1, and then VTABLE_assign on the two.
>
> - It needs to call VTABLE_type to get the type of the source PMC to pass
> to 'morph' instead of calling $1->vtable->base_type, because the
> base_type won't be right for Object PMCs.
Here's a first step. I added a stripped-down version of the code in RT #48467
as a second test, and it fails for me with:
set_pmc() not implemented in class 'Num'
I tried to debug it, but I have what they call "Stupid Fingers" tonight, and
as such can't tell if I need to add assign_pmc() to Class, Object, or
PMCProxy, or just go take a nap. Also holophoner lessons.
-- c
=== MANIFEST
==
--- MANIFEST (revision 23776)
+++ MANIFEST (local)
@@ -3262,6 +3262,7 @@
t/op/cc_state.t []
t/op/cmp-nonbranch.t[]
t/op/comp.t []
+t/op/copy.t []
t/op/debuginfo.t[]
t/op/exceptions.t []
t/op/gc.t []
=== src/ops/ops.num
==
--- src/ops/ops.num (revision 23776)
+++ src/ops/ops.num (local)
@@ -1246,3 +1246,4 @@
stm_wait_ic1216
stm_abort 1217
stm_depth_i1218
+copy_p_p 1219
=== src/ops/set.ops
==
--- src/ops/set.ops (revision 23776)
+++ src/ops/set.ops (local)
@@ -514,7 +514,6 @@
goto NEXT();
}
-
=item B(out PMC, invar PMC)
Makes a copy of the PMC in $2 and puts it in $1.
@@ -526,7 +525,6 @@
goto NEXT();
}
-
=item B(out PMC, invar PMC, in PMC)
Makes a copy of the PMC in $2 and puts it in $1, using the arguments in $3.
@@ -538,6 +536,19 @@
goto NEXT();
}
+=item B(inout PMC, invar PMC)
+
+Morphs the PMC in $1 to the type of the PMC in $2, then assigns $2 to $1.
+
+=cut
+
+inline op copy(inout PMC, invar PMC) :base_mem {
+ INTVAL type = VTABLE_type(interp, $2);
+ VTABLE_morph(interp, $1, type);
+ VTABLE_assign_pmc(interp, $1, $2);
+ goto NEXT();
+}
+
=back
=cut
=== t/op/copy.t
==
--- t/op/copy.t (revision 23776)
+++ t/op/copy.t (local)
@@ -0,0 +1,64 @@
+#! parrot
+# Copyright (C) 2007, The Perl Foundation.
+# $Id: /mirror/trunk/t/op/say.t 20627 2007-08-14T23:50:55.898359Z chromatic $
+
+=head1 NAME
+
+t/op/copy - Testing the copy opcode
+
+=head1 SYNOPSIS
+
+% prove t/op/copy.t
+
+=head1 DESCRIPTION
+
+Tests various PMCs with copy.
+
+=cut
+
+.sub 'main' :main
+.include 'include/test_more.pir'
+
+plan(3)
+
+test_basic()
+test_rt48467()
+.end
+
+.sub 'test_basic'
+.local pmc dest
+dest = new 'Integer'
+dest = 2
+
+.local pmc src
+src = new 'Float'
+src = 1.28
+
+dest = copy src
+isa_ok( dest, 'Float', 'copy should change type of PMC' )
+is( dest, 1.28, '... and its value' )
+.end
+
+.sub 'test_rt48467'
+.local pmc my_float
+my_float = subclass 'Float', 'Num'
+
+## my $x = 0;
+.local pmc dest
+dest = new 'Integer'
+dest = 0
+
+## my $y = 3.2;
+.local pmc src
+src = new 'Num'
+src = 3.2
+
+## $x = $y;
+dest = copy src
+
+## $y++;
+inc src
+
+## say '$x = ', $x;
+is( dest, 3.2, 'copy should make independent copies' )
+.end
[perl #48507] [BUG] oo - n_add, n_sub, etc. don't work with objects
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #48507] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=48507 > The n_add, n_sub, etc. opcodes don't seem to work when an object is used as the first source operand. Here's the test: $ cat x.pir .sub main :main $P0 = subclass 'Float', 'Num' $P1 = new 'Num' $P1 = 4.1 say $P1 n_add $P2, $P1, 5 say $P2 .end $ ./parrot x.pir 4.1 Object must be created by a class. current instr.: 'main' pc 22 (x.pir:8) $ The 'add' opcode seems to work, however. $ cat y.pir .sub main :main $P0 = subclass 'Float', 'Num' $P1 = new 'Num' $P1 = 4.1 say $P1 $P2 = new 'Num' add $P2, $P1, 5 say $P2 .end $ ./parrot y.pir 4.1 9.1 $ Pm
The headerizer and comment blocks
Tonight I've been working on getting the headerizer to automagically
update the comment blocks for each function in a .c file (.pmc files
will come later). The goal here is twofold:
1) The documentation is always consistent, because the declaration-
based documentation is computer-generated, and
2) The documentation is always up-to-date, because humans don't have
to remember to update the comment blocks.
Right now, it only updates src/tsq.c, a source file I picked at random
for experimentation and public discussion. I made it make comment
blocks look like this:
/*
=item C
Does a synchronized removal of the head entry off the queue and
returns it.
=cut
*/
PARROT_CAN_RETURN_NULL
QUEUE_ENTRY *
pop_entry(ARGINOUT(QUEUE *queue))
{
... function body...
I figured that the two big things that mattered in an item heading are
the return type and the function name. What do you think? Do we need
a list of arg names in the =item as well? A copy of the full
declaration? We certainly don't want the full declaration in the
=item itself because it would be absurdly long what with all the
PARROT_ macros and whatnot. But I could see it looking like:
=item CDoes anyone actually run something like perldoc src/filename.c to
look at the docs? I'm thinking that if nobody actually does that, we
could save the doc discussion until we're actually at a point where
we're generating docs. Right now, I think that what I've got as the
prototype above is 90% there, and gets rid of the tons of cut'n'paste
that are sprinkled throughout the C code.
Let me know your thoughts, so I can do more automation and run it on
the rest of the source files.
xoxo,
Andy
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
