[perl #62730] Internal Parrot errors leak through when passing some kinds of pairs
On Thu Jan 29 02:16:23 2009, jonat...@jnthn.net wrote:
> .sub 'main'
> $S0 = 'foo'
> example('foo'=>42) # works
> # example($S0=>42) # what I want to work also
> .end
>
> .sub 'example'
> .param pmc foo :named('foo')
> say foo
> .end
>
> Uncomment the line I commented out, and IMCC gives a syntax error.
IMCC currently allows this "name"=>value syntax in three places: in a
.return directive, in an argument list to a subroutine, and in a target
list of returned values:
.return("name"=>value)
MySub("name"=>value)
("name"=>value) = MySub()
I assume that we want to be able to use SREGs (and string variables) in
all of these places? Or, are we looking to be more general to try and
include all stringifiable registers and variables here?
--
Andrew Whitworth
a.k.a Whiteknight
[perl #53210] [TODO] change new_from_string to init_str
On Tue Apr 22 10:05:57 2008, [EMAIL PROTECTED] wrote:
> We've been kicking around the idea of removing new_from_string for a
> while, but the pushback is always that it's useful to be able to create
> a new PMC with some initialization data, without first creating a PMC
> initializer that has to be garbage collected. So, instead of removing it
> entirely, make it a standard initialization option, passing a string
> argument instead of a PMC argument.
>
> Note, this will require changes to the "new" opcode, and to the
> low-level initialization functions ("pmc_new", etc). But, at least it'll
> be consistent, instead of a lone crack-headed different way of
> instantiating PMCs.
>
> Allison
Is this idea still being kicked around? What would all the new
interfaces look like? This seems like the kind of update that could be
tackled in the next month if we wanted something that was more
internally consistent.
--
Andrew Whitworth
a.k.a Whiteknight
[perl #42105] memory leak in PCCMETHOD together with Parrot_runops_fromc
On Tue Mar 27 09:42:00 2007, guest wrote:
> On Mon Mar 26 16:52:16 2007, [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > The following PMC leaks memory at about 55Mb/100 calls to `call()'
> >
> > #include "parrot/parrot.h"
> >
> > static INTVAL dynpmc_Foo;
> >
> > pmclass Foo dynpmc {
> > void class_init() {
> > if (pass) {
> > dynpmc_Foo = Parrot_PMC_typenum(INTERP, "Foo");
> >
> > }
> > }
> >
> >
> > void assign_pmc(PMC *sub) {
> > PMC_pmc_val(SELF) = sub;
> > }
> >
> > PCCMETHOD void call() {
> > PMC *sub = PMC_pmc_val(SELF);
> > Parrot_runops_fromc(INTERP, sub);
> >
> > }
> > }
> >
> > Cheers,
> > Rich
>
>
> as an update to this, I don't think the leak has anything to do with the
> call to Parrot_runops_fromc as the following snippet of code common to
> what the PCCMETHOD preprocessor spits out leaks memory too:
>
> METHOD void call() {
> PMC *code = PMC_pmc_val(SELF);
> INTVAL n_regs_used[] = { 0, 0, 0, 3 };
> opcode_t param_indexes[] = { 0, 1, 2 };
> opcode_t *current_args;
> PMC* _type = pmc_new(interp, enum_class_FixedIntegerArray);
> PMC* param_sig = Parrot_FixedIntegerArray_new_from_string(
> interp, _type,
> string_from_cstring(interp, "(2, 2, 34)", 0),
> PObj_constant_FLAG
> );
>
> PObj_live_CLEAR(param_sig);
> PObj_live_CLEAR(_type);
> }
>
> So it would seem that perhaps FixedIntegerArray objects are leaking
Is this still an issue? I've never even heard of the "PCCMETHOD
Compiler", does it still exist? Is it used? Is FixedIntegerArray known
to be leaking any memory?
--
Andrew Whitworth
a.k.a Whiteknight
[perl #50040] [BUG] GC makes a namespace entry disappear?
On Mon Mar 03 15:11:25 2008, rgrjr wrote: >From: Bob Rogers <[EMAIL PROTECTED]> >Date: Sun, 2 Mar 2008 11:28:08 -0500 > >. . . if I revert string.pmc in r26175 (the one experiment I didn't >bother trying), it does in fact work . . . > > And I notice that RT#50040 also no longer fails in r26175. (It had been > failing in periodic rechecks after renaming orig-structures.pir to > structures.pir, but those observations don't seem to have made it into > RT.) > > -- Bob > What's the status of this ticket now? From the last message here, it looks like maybe a solution was found (or an offending commit isolated). Does this still fail? If not, we can close this ticket. -- Andrew Whitworth a.k.a Whiteknight
[perl #38823] [BUG] solaris 10 w gcc
On Fri Mar 31 13:29:46 2006, leo wrote: > I've tried: > > $ perl Configure.pl --cc=gcc --link=gcc --ld=gcc --cxx=gcc > --verbose-step=gcc > > and got: > > Determining if your C compiler is actually gcc...gcc > -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -xarch=v8 -D_TS_ERRNO > -I./include -c test.c > gcc: language arch=v8 not recognized > > From perl -V: >Compiler: > cc='cc', ccflags ='-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > -xarch=v8 -D_TS_ERRNO', > optimize='-xO3 -xspace -xildoff', > > That is, our config system is still using perl5 config vars blindly w/o > further inspection and ignores commandline option at least partially. > > $ uname -a > SunOS z1.t2000.develooper.com 5.10 Generic_118833-03 sun4v sparc > SUNW,Sun-Fire-T200 > > $ perl -v > This is perl, v5.8.4 built for sun4-solaris-64int > > $ cc -V > cc: Sun C 5.8 2005/10/13 > > $ gcc --version > gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) > > > BTW compiling/testing Parrot w Sun cc 5.8 works fine (except some +-0 > quirks in complex.t) > > leo > This ticket is over two years old and the problem described appears to be, at least in part, dependent on the faulty config system of years gone by. Do we have any Solaris users who can double-check this and see if we still have a problem here? -- Andrew Whitworth a.k.a Whiteknight
[perl #39796] [TODO] Implement .loadlib pragma in IMCC
On Fri Jul 14 06:23:20 2006, coke wrote: > So, does .loadlib wipe the current .HLL pragma that's in effect? (if > it's intereacting with the other dot-pragmas, we need to document.) > > Regards. > > On Jul 14, 2006, at 7:17 AM, Audrey Tang wrote: > > > > > 在 2006/7/14 上午 6:45 時，Audrey Tang 寫到： > >> Changing it back to :immediate makes tests pass again. > >> > >> Alternately, skipping the Parrot_register_HLL part in IMCC makes > >> tests pass again. > > > > After several rounds of trial-and-error, I've committed r13294 that > > works around the problem: > > > > * Tcl: Change back to .loadlib. > > > > Simply adding this line to tcllib.pir: > > .loadlib 'dynlexpad' > > appears to fix the problem. > > > > According to leo, .loadlib acts like a dummy HLL, so there is > > an order dependency to be observed by .loadlib calls. > > > > This may not be a problem if Parrot_register_HLL_type takes the > > HLL name instead of the current max HLL_idx, but the current state > > renders this workaround neccessary. > > > > So this ticket is probably good to be closed again, though it still > > leaves me somewhat puzzled. :) > > > > Audrey > > -- > Will "Coke" Coleda > [EMAIL PROTECTED] > > This ticket is over two years old. Does the ".loadlib" pragma work without problems now? Does it still appear to interact negatively with the .HLL pragma? If the .loadlib pragma is implemented and doesn't cause any problems, we should close this ticket. -- Andrew Whitworth a.k.a Whiteknight
[perl #57430] [TODO] [PDD19] implement .HLL_map 'Foo' = 'Bar'
On Thu Jul 31 03:04:09 2008, kjs wrote: > Implemented in r29908. > > kjs > > On Wed, Jul 30, 2008 at 7:51 PM, via RT Will Coleda < > [EMAIL PROTECTED]> wrote: > > > # New Ticket Created by Will Coleda > > # Please include the string: [perl #57430] > > # in the subject line of all future correspondence about this issue. > > # http://rt.perl.org/rt3/Ticket/Display.html?id=57430 > > > > > > > =item .HLL_map = > > > > This is identical to the current implementation that uses a , for its > > syntax. > > > > This syntax needs to be added, and then the comma version can go > > through a deprecation cycle before removal. > > > > -- > > Will "Coke" Coleda > > This syntax was added by kjs++ and it appears to work properly. The deprecation of the comma form of .HLL_map is being handled by RT#57432, so we can close this ticket now. -- Andrew Whitworth a.k.a Whiteknight
[perl #58974] [TODO][IMCC] replace .return in tailcall context by .tailcall
On Sat Oct 18 07:38:32 2008, Whiteknight wrote: > > On Wed Sep 17 09:50:10 2008, kjs wrote: > > > as suggested by Allison, > > > .return in a tailcall context, like this: > > > > > > .return foo() > > > > > > will changed into: > > > > > > .tailcall foo() > > I've added ".tailcall" syntax to IMCC. It is supposed to be used instead > of ".return" in tailcall context. Using ".return" for this is deprecated. > > I haven't tested yet, but i assume there are going to be a lot of uses > of the old syntax throughout the repo that will need to be updated. Do > any of our code generators like PCT use the old syntax? If so, how hard > would it be to update them? > > Forgot to post this reply to perl6-internals -- Andrew Whitworth a.k.a Whiteknight
[perl #57028] Re: pdd25cx and PGE optable bugs -- detailed analysis
On Sat Aug 02 01:30:05 2008, allison wrote: > Alternatively, we may simply rip out the graph coloring register > allocator. Either way, we won't hold up the merge for it. > > Allison Do we have any kind of a verdict on this? Are we going to rip out the graph coloring allocator? I can take a stab at that task tonight or over the weekend, if that's the path that we want to take. -- Andrew Whitworth a.k.a Whiteknight
[perl #46295] [CAGE] [pdd15oo] Review the docs w.r.t. the new OO implementation
On Tue Oct 09 17:57:00 2007, rgrjr wrote: > From Allison: > >From: Allison Randal <[EMAIL PROTECTED]> >Date: Mon, 08 Oct 2007 12:22:41 -0700 > >You might submit a cage cleaner task for a deeper review of the OO >documentation. (I've been cleaning up the docs embedded in the code as I >work on the code, but the external docs will need sprucing up with some >of the new features.) > >Allison > > NB: Allison is talking about the pdd15oo branch here; patches should be > submitted against this branch. > > This could be viewed as two subtasks: > >1. Review the OO documentation for consistency and completeness; and > >2. Review the rest of the documentation for any tangential discusion > of OO technology that needs to be brought up to date. > >The second subtask is probably more important (but extra eyes on the > OO docs themselves certainly wouldn't hurt). > > -- Bob Rogers > http://rgrjr.dyndns.org/ The pdd15oo branch was merged in and conversation on this ticket stopped almost a year ago now. Is there still outstanding documentation work to do on this topic, besides the general "all documentation should be improved" work that always needs to be done? Are there any specific changes in the code that have not yet been reflected in the documentation? -- Andrew Whitworth a.k.a Whiteknight
[perl #39615] [TODO] get_outer op not defined in PDDs
On Fri Feb 22 00:59:47 2008, kjs wrote: > a patch was sent but never applied. > > I suggest to apply this patch, possibly with minor changes, and close > this ticket. Applied in r32003. I hope Allison doesn't mind if I close this ticket? -- Andrew Whitworth a.k.a Whiteknight
[perl #57438] [DEPRECATED] [PDD19] .pragma n_operators
On Tue Aug 05 05:58:41 2008, kjs wrote: > As far as I could see, it seems that the whole "n_operators" thing is > no > longer mentioned in pdd19. > > if it's what Pm thinks, just a change from ".pragma n_operators" to > ".n_operators", then that should be added. > > kjs > > On Sat, Aug 2, 2008 at 6:56 PM, Patrick R. Michaud > <[EMAIL PROTECTED]>wrote: > > > On Thu, Jul 31, 2008 at 10:07:49AM +0100, Klaas-Jan Stol wrote: > > > On Wed, Jul 30, 2008 at 9:06 PM, via RT Will Coleda wrote > > > > From PDD19: > > > > > > > > =item .pragma n_operators [deprecated] > > > > > > does this mean that by default all ops will have the n_ prefix by > > default? > > > That would imply some variants of these ops are removed (namely, > the > > > non-n_-prefixed ones). > > > > > > I guess what my question is, what's the reason for removing this? > > > > I think all this means is that the pragma itself is deprecated. > > I would presume that the n_operators remain, and that programs can > > continue to generate both n_ and non-n_ opcodes as needed. > > > > Pm > > After the pdd27mmd merge, all the n_* opcodes are gone now. I assume the ".pragma n_operators" can disappear with them? -- Andrew Whitworth a.k.a Whiteknight
[perl #59472] [TODO] Randomize hash seed
On Tue Sep 30 04:34:58 2008, bernhard wrote: > In src/hash.c:816 there is a TODO comment: > > /* TODO randomize */ > hash->seed = 3793; > > This needs to be investigated and probably implemented. I assume it would be easy to take Parrot_intval_time() as the seed here, or some function of it. Are there any specific boundaries on how large/small this number has to be, whether it has to be prime or pseudoprime, etc? I'll throw it together if somebody will tell me what the requirements are (if any). -- Andrew Whitworth a.k.a Whiteknight
[perl #40124] [TODO] Document HLL mappings
On Fri Nov 10 11:19:58 2006, chip wrote: > It's already true that HLLs can remap the basic types so that e.g. > parameter > passing creates a PerlArray rather than a base array. However the > mechanism is > not documented (AFAIK), and it should be. Haven't heard any information about this ticket in two years. I did a quick look-through and didn't see any documentation about HLL mapping. Considering it's been such a big topic in Rakudo development lately (among other things) maybe we have some people now willing to write some quick documentation about it? Or, if somebody can point me to the relevant code, I can try to hack together some docs for it. -- Andrew Whitworth a.k.a Whiteknight
[perl #57636] [TODO][PDD19] Document the reason for :unique_reg flag
On Sat Aug 16 02:36:27 2008, [EMAIL PROTECTED] wrote: > chromatic wrote: > > On Thursday 07 August 2008 08:26:19 Bob Rogers wrote: > > > >> I once suggested a "null register allocator" that would do this > >> globally, but this is a better idea. The only use case I can think > of > >> is debugging, particularly of the register allocator, but that's > still > >> important. > > > > In theory, that's what the vanilla register allocator does. In > practice, > > somehow something sometimes turns on the graph-based allocator, > which has a > > couple of bugs. PGE trips this occasionally. > > The graph-based allocator is currently completely disabled, and may be > ripped out. > > :unique_reg is a useful feature. For one thing, it's a compiler > optimization to skip the allocation code on certain variables. And, > we're likely to run through multiple register allocator algorithms > over > the years, so the ability to protect certain variables from register > alligators is likely to find future use. > > When disabling optimizations, you generally want to do it for the > smallest area possible, so turning off allocation for particular > variables is better than turning it off for an entire subroutine. But, > if we find that supporting :unique_reg for particular variables makes > it > overly difficult to implement future register allocators, we can > deprecate it then and switch to a per-subroutine selector. > > Allison I committed a small update to the :unique_reg documentation in PDD19 in r31995. This should satisfy the original purpose of this ticket (documenting the directive), so I'm going to mark it resolved. There was a lot of good information discussed here though, about register allocators and other stuff, so forgetting about this ticket entirely is probably not a good idea. I'll try to merge some more of these ideas into documentation in various files throughout /docs/ http://rt.perl.org/rt3/Ticket/Display.html?id=57636 -- Andrew Whitworth a.k.a Whiteknight
[perl #43831] [CAGE] Document how we do function decoration
On Thu Feb 28 12:56:30 2008, bernhard wrote: > On Do. 12. Jul. 2007, 08:58:41, petdance wrote: > > Is the documentation of funtion declaration taken care of in > docs/dev/seatbelts.pod ? Or is there more to do? > If I understand what is being asked for in the ticket name (which is very obtuse, and no explanation is given), we're talking about documenting the way our C functions are decorated? If so, then docs/dev/seatbelts.pod really does appear to be it (but it needs updating and expanding). I propose we need to: 1) Rename this ticket to something more descriptive 2) Rename seatbelts.pod to something more descriptive, like /docs/dev/C_Functions.pod or something. 3) Expand that documentation to include more cases (ARGIN, ARGMOD, ARGOUT, all the *_NULLOK variants of those, etc). Any suggestions? -- Andrew Whitworth a.k.a Whiteknight
[perl #36249] [TODO] Document policy on breakage, er, backward compatibility.
On Sat Jun 11 13:08:49 2005, chip wrote: > Short version: Up through version 0.8 or so, we promise to break > everything constantly (but not until we have a good reason). After > that, we will establish version number thresholds below which > individual APIs will not change. > > For example, only on a major version change are we allowed to even > consider breaking the embedding API. On the other hand, we may break > pasm somewhat more frequently: humans should only write pir, not pasm, > and it's not against the law to abuse silicon-based life forms. Has anybody put any thought into this? Do we have any documents or drafts which address this issue? We are getting close enough to the 0.8 release that's mentioned here as a specific milestone for getting this done. -- Andrew Whitworth a.k.a Whiteknight
[perl #31143] [TODO] Interpreter - share MMD tables
On Sun Aug 15 13:21:16 2004, coke wrote: > Make the MMD tables shareable between interpreters for faster > startup. (Though there are issues with this) > > (From the TODO file) With the pdd27mmd branch merged in now, what's the status of this request? -- Andrew Whitworth a.k.a Whiteknight
[perl #46405] [TODO] Reset stacktop or disable GC in Parrot_exit()
On Sat Oct 13 11:14:42 2007, pcoch wrote: > In src/exit.c:Parrot_exit() there is the todo item (with some context): > > /* call all the exit handlers */ > > TODO reset stacktop or better disable GC > > Make a decision as to which is better to do; reset stacktop or disable GC > and then implement as appropriate. I'm trying to figure out exactly what needs to be done here, the comments in the function are a little cryptic. After all the exit handlers are called, we want to perform a finalizing GC run, to make sure all custom destructors are called on all PMCs? Or, is finalization called from somewhere else automatically? That, and what is meant here by "reset stacktop"? I have no idea what that's supposed to mean. -- Andrew Whitworth a.k.a Whiteknight
[perl #45959] [TODO] Check arity of sub in mmd_maybe_candidate()
On Tue Oct 02 10:22:41 2007, pcoch wrote:
> In the file src/mmd.c there is the todo item within mmd_maybe_candiate():
>
> if (VTABLE_isa(interp, pmc, _sub)) {
> /* a plain sub stops outer searches */
> /* TODO check arity of sub */
>
> VTABLE_push_pmc(interp, cl, pmc);
In this, we want to only push on a candidate sub if the arity of the sub
matches the arity of the MMD call? If so, what do we compare it to?
Also, do we need to check the arity of MultiSub candidates too?
Are we sure that Parrot_mmd_maybe_candidate is the right place to be
checking arity on these subs?
--
Andrew Whitworth
a.k.a Whiteknight
[perl #48549] [DEPRECATED] [PDD19] Let .namespace (no args) have empty brackets
On Wed Jul 30 11:57:39 2008, coke wrote: > PDD19 lists this as deprecated now, changing from an [RFC] to > [DEPRECATED], re-opening from stalled. The big hangup for this ticket is that various parts of PCT and the CodeString PMC do not support empty brackets, and therefore PCT does not emit ".namespace []" in these situations. Since PCT is one of the biggest producers of PIR code, we obviously can't move forward on the deprecation of this feature until CodeString is updated to emit "[]" for an empty namespace instead of just saying ".namespace". I know pmichaud was talking about a major rewrite of PGE in the future, maybe this change could be included in the laundry list of things to do during that time? -- Andrew Whitworth a.k.a Whiteknight
[perl #56972] Error in link
On Wed Jul 16 00:14:32 2008, [EMAIL PROTECTED] wrote: > On your page > > http://www.parrotcode.org/faq/ > > you have a link labelled "LANGUAGES.STATUS". I think > that the href= for this link points to a wrong page. > Please check. > > Ronald Since we're migrating to www.parrot.org instead, is this much of an issue? If not, I think we can close this ticket. -- Andrew Whitworth a.k.a Whiteknight
[perl #40392] [CAGE] convert C to a catchable exception
On Mon Aug 04 20:49:25 2008, coke wrote: > On Mon Jun 09 16:49:46 2008, [EMAIL PROTECTED] wrote: > > On Thu Sep 21 14:38:40 2006, particle wrote: > > > parrot's source is littered with internal_exception() calls, the > bulk > > > (all?) of which should be converted to real_exception() calls. > > > internal exceptions are uncatchable, and might as well be called > > > C. that's bad, ya dig? > > > > > > For reference, I am attaching a list of files which, as of the date > of > > this post, contain the string 'internal_exception'. > > > > kid51 > > internal_exception is no more, it's now called "exit_fatal". Here is a > list of files/counts in the > repository as of today that use this (as opposed to test, define or > document it) > > lib/Parrot/Pmc2c/PCCMETHOD.pm > src/events.c > src/jit/alpha/jit_emit.h > src/jit/hppa/jit_emit.h > src/jit/ia64/jit_emit.h > src/jit/mips/jit_emit.h > src/jit/ppc/jit_emit.h > src/jit/sun4/jit_emit.h > src/ops/core.ops > src/packfile/pf_items.c > src/thread.c > src/tsq.c > > However, without a more clean delineation of which of these need to be > converted and which > can stay as is, this ticket is unclosable. Let's plan on closing it > out one way or 'tother before > the Sep '08 release. Sept 08 milestone came and went. Any updates on this ticket? Maybe this ticket should be closed out (since it's vague) and replaced with another ticket or tickets for individual places where exit_fatal should be replaced with real_exception, if any. -- Andrew Whitworth a.k.a Whiteknight
[perl #57690] [BUG] make headerizer breaks build
On Thu Aug 07 06:20:51 2008, coke wrote: > On Thu, Aug 7, 2008 at 8:21 AM, NotFound <[EMAIL PROTECTED]> wrote: > > On Thu, Aug 7, 2008 at 2:06 PM, Will Coleda <[EMAIL PROTECTED]> wrote: > > > >> make headerizer is trying to operate on files generated by make. Given > >> that it's supposed to be updating the header files based on the C > >> sources, this seems vaguely reasonable, so I would suggest that the > >> problem is actually that you're not supposed to do things in that > >> order. > > > > But make can fail if headerizer has not done his job before, because > > an include'd file may be not updated and thus the file that include it > > fails to compile. This is not theory, is failing now that way. > > headerizer doesn't need the full build. It just needs to have the > generated C files created that it's trying to modify. Those files > don't need to have been compiled. I think we're talking about two different errors now, and maybe we should split this ticket up (how do we do that, if it's even possible?). The original problem that I was trying to talk about, which still exists although it has been masked, is that running "make headerizer" creates problems in the IMCC-related header files. Function prototypes are being included before the necessary data type definitions that are required by them. So, for instance, the prototype for compilers/imcc/symreg.c:add_namespace is included before the definition of IMC_Unit. This probably isn't headerizer's fault, it's more likely the fault of IMCC for being so damn complicated. We could change all the function definitions in the IMCC related files to use "struct _IMC_Unit" instead of "IMC_Unit" which would resolve the problem. Alternatively, we could rearrange the way the header files are ordered/created, and ensure all function prototypes are included after all data type definitions. Neither fix should be too difficult, but I don't know which we would prefer to pursue. --Andrew Whitworth
[perl #34452] [TODO] Add return signature to Parrot_call_sub that returns multiple values
Is this still an issue? A quick check of src/embed.c shows that there is no function Parrot_call_sub. Has it been moved to some other location, or is it gone entirely? If it's completely gone, then this ticket is moot and should be closed. --Andrew Whitworth
[perl #34549] atan2() isn't IEEE compliant on OpenBSD/*BSD/Cygwin/Solaris
Is this still not resolved? This ticket has not seen any discussion since 2006. To double-check, I think we need people to check t/op/trans.t on: *Solaris *OpenBSD *NetBSD *Cygwin If it passes all these platforms, I think the ticket is resolved. If not, maybe we need to break this into more-specific sub-tickets for each failing platform. --Andrew Whitworth
[perl #53394] [BUG] Divide-by-zero error in test on Windows
This error hasn't been duplicated in nearly three months, and nobody else has commented on it. I'm marking this one resolved for now. --Andrew Whitworth
[perl #53394] [BUG] Divide-by-zero error in test on Windows
On Mon Jun 02 20:30:43 2008, coke wrote: > On Sat Apr 26 13:54:01 2008, ajr wrote: > > > > On Windows XP Home Edition, using gcc, the following test error is > > occurring: > > > > Divide by zero^M > > current instr.: 'life' pc 175 (examples\pir\life.pir:102) > > > > I am unable to duplicate this error. Can you provide more information > about your config? (which > version of gcc, what options did you pass to configure.pl, how did you > run the PIR, etc.) Can any of our windows users duplicate this bug? If not, it may not exist anymore. We should close this ticket if nobody can duplicate it. --Andrew Whitworth
[perl #56410] [PATCH] json reimplemented with pct
On Fri Jun 27 04:02:14 2008, kjs wrote: > without any internet connection at home you get really bored. > > that means, time for some fun :-) > Included is a patch that implements JSON with the PCT. As JSON is just a > data description (sub) language, I was not sure what the TOP rule should > contain; > I decided for now that it would be just * > > Running the pct-based JSON language, just input some string on the command > line, like [1, 2, 3], and the output is dumped to stdout. > > kjs Thanks, applied in r28923. --Andrew Whitworth
[perl #47888] [TODO] gc - possibly merge gmc branch back into trunk
I took another long look at this branch, and see nothing here that is salvageable for current use. I have deleted the branch as of r28915. --Andrew Whitworth
[perl #47674] [TODO] :vtable pragma should enable 'self'
On Wed Nov 21 07:45:53 2007, [EMAIL PROTECTED] wrote:
> Setting the :vtable pragma on a sub should enable the 'self' shortcut
> for the current invocant. As in the following code example where a
> method is called from within a vtable override:
>
>.sub main :main
> $P1 = newclass "Foo"
> $P2 = new "Foo"
> $S1 = $P2
> print $S1
>.end
>
>.namespace [ "Foo" ]
>
>.sub get_string :vtable
> self.'bar'()
> .return ("stringy thingy\n")
>.end
>
>.sub bar :method
> print "called bar\n"
>.end
>
> (Pulled from rejected ticket #42430.)
>
> Allison
Attached is a patch that does almost the right thing. It allows "self"
to be used in functions marked :vtable, not just functions marked
:method or ":vtable :method". However, the example above does not work.
The call to self.'bar'() triggers a "null PMC access in find_method()"
error. Without that method invocation, there is no error, and the
function works as expected (prints "stringy thingy").
I assume the :method invocation changes the PMC type of the self
parameter, or adds some kind of class field to it that isn't there
otherwise. I don't know enough about PCC internals to fix this part of
the problem, although I will keep looking at it.
--Andrew Whitworth
Index: compilers/imcc/imcc.l
===
--- compilers/imcc/imcc.l (revision 28866)
+++ compilers/imcc/imcc.l (working copy)
@@ -557,7 +557,8 @@
(r = IMCC_INFO(interp)->cur_unit->instructions->symregs[0]) &&
r->pcc_sub)
{
-if ((r->pcc_sub->pragma & P_METHOD) &&
+if (((r->pcc_sub->pragma & P_METHOD) ||
+ (IMCC_INFO(interp)->cur_unit->is_vtable_method)) &&
!strcmp(yytext, "self")) {
valp->sr = mk_ident(interp, "self", 'P');
IMCC_INFO(interp)->cur_unit->type |= IMC_HAS_SELF;
[perl #47674] [TODO] :vtable pragma should enable 'self'
With some help from DietCoke, we got most of the problem solved.
However, several tests are failing now, especially those dealing with
overriding the invoke vtable method.
One error specifically caught my eye, from t/pmc/namespace.t:1672:
.sub 'main' :main
$P0 = newclass 'Override'
$P1 = new 'Override'
$P2 = find_method $P1, 'foo'
.end
.namespace [ 'Override' ]
.sub 'find_method' :vtable
say "Finding method"
.end
With the patch, this test returns an error that we are passing one
parameter, but expecting 0. This is, I assume, desired behavior: We are
passing one parameter (the method name string 'foo'), but 'find_method'
isn't expecting any parameters. Changing the method to this fixes the
problem:
.sub 'find_method' :vtable
.param string name
say "Finding method"
.end
I suspect this is desired behavior, because the 'find_method' vtable
method should take the name of the method to find as a parameter
(otherwise, how do you know what to find?)
Some of the other tests deal with object invoking, such as "$P0()". With
the patch, many of these tests are failing because we aren't passing
enough parameters. For instance, the following test is failing because
we are passing 0 parameters, when it expects 1:
.namespace ['Foo']
.sub invoke :vtable
say "you invoked me!"
.return()
.end
.sub main :main
$P0 = newclass "Foo"
$P1 = new "Foo"
$P1()
say "got here"
.end
Changing the invocation to say "$P1($P1)" solves the error, but I doubt
this is desired. The parser is, I assume, trying to suck the object into
the self parameter, but it isn't being passed in the first place. On
invokes, we should be passing the object itself as a "self" parameter,
although I don't know how to make that happen.
On an odd note, generating PASM output of the above example with "$P1()"
and "$P1($P1)" using parrot -o both produce identical PASM files.
Neither generated PASM file executes, they both fail with segmentation
faults. I don't know yet if this is an artifact of the patch, a problem
with the PASM generator, or something else.
--Andrew Whitworth
Index: compilers/imcc/pcc.c
===
--- compilers/imcc/pcc.c (revision 28866)
+++ compilers/imcc/pcc.c (working copy)
@@ -313,7 +313,8 @@
SymReg *regs[2];
/* if this sub is a method, unshift 'self' as first param */
-if (sub->pcc_sub->pragma & P_METHOD) {
+if ((sub->pcc_sub->pragma & P_METHOD) ||
+(IMCC_INFO(interp)->cur_unit->is_vtable_method)) {
SymReg *self = get_sym(interp, "self");
if (!self) {
self = mk_symreg(interp, "self", 'P');
Index: compilers/imcc/imcc.l
===
--- compilers/imcc/imcc.l (revision 28866)
+++ compilers/imcc/imcc.l (working copy)
@@ -557,7 +557,8 @@
(r = IMCC_INFO(interp)->cur_unit->instructions->symregs[0]) &&
r->pcc_sub)
{
-if ((r->pcc_sub->pragma & P_METHOD) &&
+if (((r->pcc_sub->pragma & P_METHOD) ||
+ (IMCC_INFO(interp)->cur_unit->is_vtable_method)) &&
!strcmp(yytext, "self")) {
valp->sr = mk_ident(interp, "self", 'P');
IMCC_INFO(interp)->cur_unit->type |= IMC_HAS_SELF;
Index: t/pmc/namespace.t
===
--- t/pmc/namespace.t (revision 28866)
+++ t/pmc/namespace.t (working copy)
@@ -1679,7 +1679,10 @@
.namespace [ 'Override' ]
.sub 'find_method' :vtable
-say "Finding method"
+.param string name
+$S0 = "Finding method"
+$S1 = $S0 . name
+say $S1
.end
CODE
/Finding method/
[perl #55538] [RFC] ".macro_const" doesn't work in *.pir files
General consensus (at least from what I've heard) is that this is useful to add in PIR files, so I've applied the patch and a few other updates and tests for it in r28473. Resolving ticket. --Andrew Whitworth
[perl #55538] [RFC] ".macro_const" doesn't work in *.pir files
The attached patch allows the .macro_const directive to be used in PIR
files, not just in PASM files. Previous behavior, apparently, was only
to allow the .macro_const directive to be used when in "PASM mode",
which doesn't make much sense, considering that all our low-level work
is done in PIR and we are encouraging new users to learn PIR instead of
PASM.
If people think this is a good idea, I'll implement it and a test or two
for it.
--Andrew Whitworth
Index: compilers/imcc/imcc.l
===
--- compilers/imcc/imcc.l (revision 28320)
+++ compilers/imcc/imcc.l (working copy)
@@ -421,13 +421,10 @@
">>>=" return SHR_U_ASSIGN;
".=" return CONCAT_ASSIGN;
-".macro" {
-return read_macro(valp, interp, yyscanner);
-}
-
-".macro_const" {
+".macro_const" {
int c;
int start_line;
+int start_cond = YY_START;
BEGIN(macro);
c = yylex_skip(valp, interp, " ", yyscanner);
@@ -450,10 +447,14 @@
IMCC_INFO(interp)->cur_macro_name = NULL;
-BEGIN(emit);
+BEGIN(start_cond);
return MACRO;
}
+".macro" {
+return read_macro(valp, interp, yyscanner);
+}
+
".include" {
const int c = yylex(valp, yyscanner, interp);
if (c != STRINGC)
[perl #55364] [PATCH] Update GC system for PDD09 deprecation notes
On Thu Jun 05 15:44:05 2008, Whiteknight wrote: > PDD09 contained a number of deprecation notes, for functions and > macros whose names are to be updated. The attached patch makes these > changes globally, including in PDD09 and other documentation. The > following macros and functions are renamed: > > (*do_dod_run) -> (*do_gc_mark) > (*de_init_gc_system) -> (*finalize_gc_system) > DOD_trace_normal -> GC_trace_normal > DOD_trace_stack_FLAG -> GC_trace_stack_FLAG > DOD_lazy_FLAG -> GC_lazy_FLAG > DOD_finish_FLAG -> GC_finish_FLAG > DOD_no_trace_volatile_roots -> GC_no_trace_volatile_roots > DOD_WRITE_BARRIER -> GC_WRITE_BARRIER > DOD_WRITE_BARRIER_KEY -> GC_WRITE_BARRIER_KEY > Parrot_block_GC -> Parrot_block_GC_mark > Parrot_unblock_GC -> Parrot_unblock_GC_mark > Parrot_block_DOD -> Parrot_block_GC_sweep > Parrot_unblock_DOD -> Parrot_unblock_GC_sweep > > PDD09 includes a note "The phrase 'dead object detection' and > abbreviation 'DOD' are deprecated". I will note here that many many > other functions, macros, variables and flags use the abbreviation > "DOD" or "dod". Fixing all instances of those, if they indeed need > fixing, is outside the scope of this patch. This patch only removes > deprecation notes from PDD09 and updates the codebase to use the new > names described in that document. I've been testing this patch locally for about a week and there are no issues with it. If nobody has any questions/comments/objections I'd like to apply it later today. Anybody? --Andrew Whitworth
[perl #51944] Cygwin Readme
is this ticket (#51944) resolved? I don't see any outstanding todo items here that need to be considered further, and the submitted patch has already been applied. Can we close this, or is this a placeholder for us to further improve cygwin documentation? --Andrew Whitworth
[perl #51980] [PATCH] fixed multiple redefines of snprintf macro
On Sat Apr 05 21:33:49 2008, infinoid wrote: > On Fri Mar 21 09:03:08 2008, [EMAIL PROTECTED] wrote: > > there is a definition on my system for PARROT_HAS_SNPRINTF, but not a > > definition for PARROT_HAS_C99_SNPRINTF. I assume, on first glance that > > these two macros are one in the same and should be united. > > They are not. Please see the code in config/auto/snprintf/test.in - > this is a C program built and run by Configure.pl, to determine which > flavor of snprintf exists on a platform. The semantics of the return > value differ. So I don't think we should unite those two definitions. Okay, I figured there must be a reason why we have definitions for PARROT_HAS_C99_SNPRINTF and PARROT_HAS_SNPRINTF. I just couldn't find it when I looked. > Were there some warnings you were trying to fix? If so, what were the > warnings? We can try to find another way to fix them; please reopen the > ticket if this is the case. Just warnings about redefining the snprintf macro. It was defined in two different places, and it's definition was based on both of those two flags above. I was looking for a way to unify the definitions for snprintf, and I wanted to know if a unification could go further then that as well. --Andrew Whitworth
[perl #48549] [RFC][PIR] Let .namespace (no args) have empty brackets
My yacc is a little fuzzy (I made a funny!), but I think this simple little patch here should do the trick. I included two patch files, depending on how much you want to change. imccnamespacefix.patch: This fixes the brackets issue for the IMCC bison file. I don't have bison on my system, so I couldn't update the imccparse.c file pircnamespacefix.patch: This is an equivalent patch for the PIRC bison file. In both, the new syntax allows for: .namespace .namespace [] .namespace ['classname'] Again, I don't have Bison so I can't test it properly here. However, the patches are very very small and I don't forsee them being a problem (unless my knowledge of bison has degraded significantly in the past few months). --Andrew Whitworth pircnamespacefix.patch Description: Binary data imccnamespacefix.patch Description: Binary data
[perl #38929] [CAGE] [C] Get executable code out of .h files
src/jit_emit.h contains a large amount of both header-file stuff and executable code. I could gladly separate the two out, and create two new files: include/Parrot/jit_emit.h and src/jit_emit.c, which is probably the kind of stuff that people want to happen anyway. I can't find a good reason why we would need to keep executable code in this .h file, or why this file should be located in src/ instead of include/Parrot/. I haven't managed to read all 4100 lines of code in this file to determine why this might be. If somebody gives me the goahead, I'll take care of this today or early next week. --Andrew Whitworth
