Re: [perl #48014] [DEPRECATED] PMC union struct
Christoph Otto wrote: So you're saying that multiple inheritance in its current state should be allowed to continue, and that there's only a problem with ATTRs if a PMC tries to extend two PMCs, both of which have their own ATTRs? I'm saying that multiple inheritance between two C-level PMCs with different attributes never worked before, so it's no loss that it doesn't work now. If this is the case, I'm happy. The PMCs I've found which use multiple inheritance (LuaFunction, TclInt and TclFloat) all have one parent which appears to be a generic or abstract PMC type for that language (LuaAny and TclObject, respectively). I'll get to work on a patch to propagate ATTRs to children and post it here when it gets close to ready. Sounds good. Thanks! Allison
Re: [perl #48014] [DEPRECATED] PMC union struct
Christoph Otto wrote:
The PMC UnionVal deprecation can't be completed until Parrot has
improved ATTR
reuse between extending PMCs. I'm rewriting code to minimize dependence on
the PMC_x_val macros, but I can't eliminate them completely without better
inheritance support. I'd like to implement whatever the long-term
solution is, which seems to mean multiple inheritance regarding ATTRs.
I've been puzzling over how to implement this in a way that would work
similarly to the current PMC_x_val macros. The problem with allowing
multiple inheritance is that we can't simply copy ATTRs from parents
into the same slot in their children when multiple parents have an ATTR
in the same slot.
This doesn't make sense. The PMC_x_val macros accessed the union value
of the PMC. Any PMC that used them had a fixed set of attributes, either:
- a buffer
- two pointers
- two integers
- a float, or
- a string
Because it was a union value, the PMC could use one and only one of the
alternatives, and the parent and child had to use the same alternative.
So, when you're translating an old-style PMC to a new-style PMC, you'll
define one of:
- a buffer
ATTR void * _bufstart;
ATTR size_t _buflen;
- two pointers
ATTR DPOINTER * _struct_val;
ATTR PMC * _pmc_val;
- two integers
ATTR INTVAL _int_val;
ATTR INTVAL _int_val2;
- a float
ATTR FLOATVAL _num_val;
- a string
ATTR STRING * _string_val;
And hopefully give it a more meaningful name than the original.
Parent and child had to have the same struct in the original (because
every PMC defined the same union val struct), and so still have to have
the same struct in the new version. It is progress: at least the struct
members will have more meaningful names, and it will become possible to
subclass these older PMCs from within PIR. More progress will come later
with enhancements to inheritance, but that's no reason to hold up the
deprecation of the union struct.
The best I've been able to come up with is to use yet another Hash to
store the ATTRs, turning the GETATTR/SETATTR macros into something like
the following (modulo supporting code):
#define GETATTR_PMCType_foo(interp, pmc, x) {
x = (AttrTypeGoesHere)parrot_hash_get(interp, pmc-attr_hash,
key_new_cstring(interp, PMCType_foo));
}
This would allow the accessor macros to work on PMCs similarly to how
PMC_x_val is used now, i.e. they'll DTRT as long as the PMC is in the
right inheritance tree.
This is overkill. Accessor macros already work on PMCs similarly to how
PMC_x_val is used.
Allison
Re: [perl #48014] [DEPRECATED] PMC union struct
Christoph Otto wrote: Allison Randal wrote: (Actually, at the moment you're required to declare all parent attributes in the ATTR list before the child attributes, so inherited attributes *are* child attributes.) When I say attributes, I mean the things that are declared in .pmc files right after the pmclass line, e.g. ATTR INTVAL foo_refs; /*foo refcount*/ These do not appear to be passed down to extending PMCs. This is a problem for e.g UnManagedStruct/ManagedStruct, where PMC_int_val is used the same way by both PMCs. Right, at the moment it is absolutely required that the first ATTR declarations of the child are manual copies of the ATTR declarations of the parent. Otherwise, the inheritance won't work at all. (Ultimately, inheritance will automatically copy the parent's attributes and prepend them onto the front of the child's attribute list, but at the moment it has to be done manually.) What I'd like is for the pmc2c code to be smart enough to make ATTRs from an extended PMC accessible by an extending PMC through the GET_ATTR/SET_ATTR macros. If I could get a description of how such a patch should behave from our architect, I'd be glad to write one up and submit it for review. The fix actually goes in a different place. The GET_ATTR/SET_ATTR macros will be correctly generated for all child attributes. What really needs to change is to add the parent's attribute list to the child's attribute list during PMC parsing in Pmc2c. Take a look at lib/Parrot/Pmc2c/Parser.pm. (I can give more specific guidance after the release, working on milestone items at the moment.) Allison
Re: [perl #41825] [BUG] morph vtable override not working in PIR
Jonathan Worthington wrote: 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? 'morph' was added specifically for the Perl 5 behavior of changing types when assigned to. But really, a more accurate representation of Perl 5 behavior would be to have a single Scalar PMC that can act as a string, int, or number. So, yes, it's possible that 'morph' could be deprecated. It needs a review of current uses to make sure that they're either unnecessary (most examples I've seen are), or can be cleanly substituted with something else. 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. 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 #48014] [DEPRECATED] PMC union struct
Christoph Otto via RT wrote: I'm running into a snag trying to implement this. It turns out that many lines which use the PMC_x_val macros use them on different types of PMCs, especially parents and children (e.g. FixedPMCArray and ResizablePMCArray). There are also some instances where the PMCs with a related purpose but no inheritance (e.g. RetContinuation and ExceptionHandler) have the unionval used in the same way on a line of code. What's the right way to fix these cases to use the GETATTR/SETATTR macros? Tough to answer without looking at the code, but... The GET_ATTR/SET_ATTR macros will work on inherited attributes as well as child attributes. (Actually, at the moment you're required to declare all parent attributes in the ATTR list before the child attributes, so inherited attributes *are* child attributes.) If two unrelated PMCs are being called in the same line of code, that probably means it should really be a vtable function call instead of direct access into the data struct. Allison
Re: [perl #41825] [BUG] morph vtable override not working in PIR
Andrew Whitworth via RT wrote: Okay, I did some work on this last night, and here's the current status. 1) Modified the behavior of the morph PIR override so that it takes a string in trunk. We previously weren't able to override this method at all, so nobody is used to the old way at the PIR level. This does mean that for the time-being the PIR implementation of morph is different from the C implementation of it. However, the benefit is that the PIR-level API doesn't need to change later when the C-level API does. 2) Created a branch morph_pmc_type to make the switch from void morph(INTVAL type) to void morph(STRING *type). Most of the conversion is already done. I have some more changes to make and some general cleanup before I call the work in the branch done, however. 3) I've added a test for the behavior to t/oo/vtableoverride.t in trunk If nobody has any complaints about this work, I'll add the old flavor of morph to DEPRECATED.pod, and then merge the branch in sometime after 0.9.0 or 0.9.1. 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. Allison
Re: [perl #61870] [BUG] [META] Trac system borks authenticated user's privileges
Bob Rogers wrote: I can't log in, though that may just be because I've forgotten the password. But the odd thing is that the Reset Password page says The email and username do not match a known account, even though I know my ID is rgrjr and there are only a few possible email addresses I would have used (and Firefox even remembered my first choice). Your account had no email address associated with it. I just deleted the old account, so re-register and I'll regrant you permissions. Allison
Re: [perl #61870] [BUG] [META] Trac system borks authenticated user's privileges
Bob Rogers wrote: What about those of us who can't log in? I can't even reset my password, let alone update anything . . . It won't let you log in at all? Or, once you log in it won't let you do anything? I just reset your password, let me know if you don't get an automated email about the update. Allison
Re: [perl #61870] [BUG] [META] Trac system borks authenticated user's privileges
Our trac admins report that this is caused by users who don't have their email authenticated (that is, Trac sends you a test email, and you confirm that you got it, so Trac knows the address is valid). When we upgraded, existing users needed to re-authenticate their email addresses, but the upgrade process doesn't include resending the authentication emails. When you update your email address in trac, it should resend the authentication request. Once you confirm the change, you'll be set. Allison
Re: [perl #61870] [BUG] [META] Trac system borks authenticated user's privileges
Allison Randal wrote: Our trac admins report that this is caused by users who don't have their email authenticated (that is, Trac sends you a test email, and you confirm that you got it, so Trac knows the address is valid). When we upgraded, existing users needed to re-authenticate their email addresses, but the upgrade process doesn't include resending the authentication emails. When you update your email address in trac, it should resend the authentication request. Once you confirm the change, you'll be set. I just confirmed this with my account. Adding a name and email address under 'Preferences' destroyed my privileges, and made the following error message appear at the top of each page: Warning: acct_mgr.web_ui.MessageWrapper object at 0x814f76cc It also emailed me a verification message, and once I followed the steps in the message, my permissions were all restored. Our admins also mentioned that this unhelpful error message is filed as a bug in the TracAccountManager plugin: http://trac-hacks.org/ticket/4125 Allison
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
Will Coleda via RT wrote:
On Thu Aug 28 00:03:51 2008, alli...@perl.org wrote:
The plan is to make the regular variants (like 'add') create a new
destination PMC, and then deprecate the old n_* variants (like 'n_add').
Does this include n_not , n_bnot, and n_bnots ?
Yes. The 'not', 'abs', 'bnot', and 'bnots' opcodes already have
2-argument variants, the 'n_*' alternates are unnecessary.
The task also involves modifying the corresponding vtable functions
('logical_not', 'absolute', 'binary_not', 'binary_nots') so they return
a new PMC, rather than morphing the existing destination PMC. (Many of
them already do this, so the 'n_*' variants were actually already doing
the same thing as the regular opcodes.)
Allison
Re: [perl #60048] [BUG] [MMD] CGP Does Not Work with PCC Runcore Reentry
Will Coleda via RT wrote: Apparently remove the files isn't exactly what was meant here. This probably removes the need for the remove_pic branch, which is in the process of taking this to its literal extreme. We do need to remove the files, and the remove_pic branch is on the right track. There's just a couple lines of code here and there that have to be kept. The only other place to look is in the JIT code. In src/jit.c, in the 'parrot_build_asm' function, it's using the 'pic_callr__' opcode to invoke a NCI function/JITted sub. src/jit.c:1624 (op_func[PARROT_OP_pic_callr___pc].fn)(jit_info, interp); This opcode may need a new non-PIC variant, and should certainly be converted to use one of the standard calling conventions (PCC or C). (I can come back and look into it in a few days, I'm providing information here to help guide anyone else who takes a crack at it.) BTW, the other failing test in the remove_pic branch was simply because there are fewer elements in the packfile directory now that 'pic_index' has been removed. Fixed in r34401. Allison
Re: [perl #60048] [BUG] [MMD] CGP Does Not Work with PCC Runcore Reentry
Will Coleda via RT wrote: I created a branch (remove_pic) to remove src/pic.c; This led to the removal of pic.ops, and changes in imc, packfile... lots of references to PIC. chromatic mentioned on #parrot that if we remove PIC, we're going to break all the predereferenced runcores. After some discussion, this probably means ripping out: 16:42 @chromatic Everything other than the default core, the nearly-useless profiling core, and the gc-debug core. He mentioned this in a conversation, but I don't believe it. AFAICT, he's drawing the conclusion from the fact that these cores call some functions (or a function) in src/pic.c. But, the functions I've examined had a small nugget of code that could be moved out of PIC, so the rest of the PIC function could be safely deleted. CGP is too important to be deprecated over something as small as this. Allison
Re: Optimizing PMC-based MMD
chromatic wrote: Within the cmp op bodies, we *know* the arity and most of the types of MMD- participant arguments at compile time. We can get the types of PMC participants within the body of the op itself. Thus we could avoid most of the argument marshalling and counting and analysis if we had a way to perform cached MMD lookup without constructing a CallSignature PMC. That would clear up a third of the work. This we should open up to general discussion. The consequence of short-cutting like this is that individual PMCs will no longer be able to override 'cmp' to do something other than multi-dispatch. At the moment, developers still have the option of providing their own quick comparison, which gives an even more extreme speedup than this shortcut. So, question for language developers and other PMC developers, how important is the ability to define a 'cmp' vtable function that's called when the 'cmp' opcode is invoked? Or, is defining a 'cmp' multi for your PMC type enough? Another area for optimization is invoking a Sub from a signature PMC; I believe we're throwing away and recalculating valuable information, though we may have to wait for dramatic improvements until we can unify contexts and CallSignature. Providing a new way of invoking Subs that uses CallSignatures all the way down is already planned in the coming series of calling conventions refactors. The final opportunity for optimization is making the PMC multis defined in PMCs use PCC instead of C calling conventions. Corresponding multis written in PIR already use PCC, and we want to support that, so we should unify our approach. That would remove the NCI expense here, though that's probably minor in comparison to the CallSignature PMC expense. Changing all NCI calls to something more like PCC calls is already planned in the coming series of calling conventions refactors. Changing the Pmc2c generator to build PCC subs instead of NCI Subs is a quick change that could happen now. The calling conventions refactors are non-critical (some will likely land after 1.0), because the interface will stay the same, it's only the internals that will change. Allison
Re: [perl #60046] [META] November 2008 release
James Keenan via RT wrote: On Wed Dec 17 13:29:59 2008, kjs wrote: I thought I closed it last time. Trying again :-) kjs The ticket has 3 dependencies which are still open. Is it possible that the ticket cannot be resolved until these dependencies are resolved? Yes, but you can just remove the dependencies. Clearly the release has already happened without them, so they aren't really dependencies. Allison
Re: [perl #60626] [DEPRECATED] Old-style MMD functions
Will Coleda via RT wrote: * Parrot_mmd_add_function - src/inter_create.c //make_interpreter Delete that line from src/inter_create.c. Also delete the line before which initializes 'interp-binop_mmd_funcs' to NULL. These two lines are initializing the storage for the old MMD subsystem, which is never used anymore. Note that this implies deprecating all functions that refer to 'interp-binop_mmd_funcs'. (It looks like those are all caught in this list, just double-check to make sure. Ah, I don't see 'dump_mmd' in this list, it can also be removed, as it doesn't do anything anymore.) * mmd_cvt_to_types - src/multidispatch.c //Parrot_mmd_get_cached_multi_sig 'Parrot_mmd_get_cached_multi_sig' is only called by 'mmd_distance', which is only called by 'Parrot_mmd_sort_candidates'. 'Parrot_mmd_sort_candidates' is called all over the place (I standardized on that when I did the MMD cleanup). Let's see what chromatic's MMD sort cleanup does. If it eliminates the call to 'mmd_distance' then problem solved. If not, then let's break the deprecation of 'mmd_cvt_to_types' out into a separate ticket for refactoring the unholy trio of 'mmd_cvt_to_types', 'Parrot_mmd_get_cached_multi_sig', and 'mmd_distance'. Allison
Re: [perl #60564] [TODO] Refactor contexts to be PMCs
Patrick R. Michaud via RT wrote: Can (should) we do one or more of the following...? 1. Mark GC as a dependency for this ticket 2. Mark this ticket as stalled waiting for GC issues 3. Move this ticket to the new Trac ticket queue This would help remove this from our active ticket queue, since we're not likely to make much progress on it until after GC refactors are done. Go with #2 for now. I only submitted the ticket so the patch wouldn't be lost on my laptop. The GC refactor will start in 2 weeks, so the wait won't be terribly long, but it's good to have the status show that this isn't a ticket in need of active work. Allison
Re: [perl #60564] [TODO] Refactor contexts to be PMCs
Andrew Whitworth via RT wrote: Since I'm monkeying around in the relevant code anyway, this might be a good task for the next calling_conventions branch. Or, if you prefer, we could create a second branch for this conversion and do the work there. The general consensus on this one is to wait until after the GC refactor (which is the next big branch after the I/O). Contexts are recycled so rapidly, that the current GC would be really slow. Allison
Re: [perl #49276] [TODO] Refactor tools/util/smokeserv-server.pl
Will Coleda wrote: Is the smoke server still used? Can support for the smoke server be dropped? +1 from me; I vote for smolder. +1, on not maintaining two independent solutions for the same problem. Allison
Re: [perl #57438] [DEPRECATED] [PDD19] .pragma n_operators
Will Coleda via RT wrote: This appears to be the only .pragma; should we leave a placeholder or just remove .pragma entirely when we remove this particular one? Nuke it. Allison
Re: [perl #60044] [BUG?] rethrow just throwing?
Martin D Kealey wrote: What about keeping track of where the exception was originally created? If we have lazy exceptions, then knowing where the fault they represent was detected is probably more important than were (exactly) it was triggered. Or does this all amount to the same thing? Is an exception only lazy because there's an enclosing dynamic scope that catches it and transmogrifies it into an Uncaught Exception? Or if not, could we have both back-traces available? A created_by back-trace and a thrown_by back-trace? Theoretically, yes. But 99% of the time, the useful information is where the exception was thrown, so the extra effort of tracking both doesn't add enough value to be worth it. But, if someone did need to track both (perhaps for a research project), they could just subclass the Exception class and add a creation backtrace. Allison
Re: [perl #53210] [TODO] change new_from_string to init_str
Andrew Whitworth via RT wrote: 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. [...] 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. - Would need a new vtable function 'init_str'. void init_str(STRING *initializer) Or alternatively, if we find we need to exactly duplicate the interface of 'new_from_string': void init_str(STRING *initializer, INTVAL flags) - The 'new' opcode would need two additional variants that take a STRING initializer instead of a PMC initializer: =item Bnew(out PMC, in STR, in STR) =item Bnew(out PMC, in PMC, in STR) - The 'pmc_new' function would need two new variants, in addition to 'pmc_new' (which calls VTABLE_init), 'pmc_new_init' (which takes an extra PMC argument and calls VTABLE_init_pmc), and 'pmc_new_noinit' (which doesn't call any vtable init), and the constant versions of each. pmc_new_init_str(PARROT_INTERP, INTVAL base_type, ARGIN(STRING *init)) Allison
Re: [perl #43831] [CAGE] Document how we do function decoration
Andrew Whitworth via RT wrote: 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). Agreed. Once 2) and 3) are done, ticket can be closed. Allison
[perl #31143] [TODO] Interpreter - share MMD tables
On Wed Oct 15 17:48:28 2008, Whiteknight wrote: With the pdd27mmd branch merged in now, what's the status of this request? The MMD table is now just a namespace, and namespaces are shareable between interpreters. So, resolved. Allison
Re: [perl #60044] [BUG?] rethrow just throwing?
Patrick R. Michaud wrote: On Fri, Oct 24, 2008 at 12:18:40PM -0700, Allison Randal wrote: (I suppose technically we should stop calling this a stack trace since it's not a stack. But return continuation chain trace is just too verbose.) backtrace Exactly the word I was looking for. Allison
Re: [perl #60044] [BUG?] rethrow just throwing?
Will Coleda wrote: Allison Randal wrote: ...you expect 'rethrow' to keep the stack trace of the original 'die'? Yes. The way to do this is to add stack trace information to the Exception's 'stacktrace' attribute when the exception is first thrown, and print that out for an unhandled exception, instead of printing out the literal current path of execution. (This is why I added the 'stacktrace' attribute.) But, the implementation isn't currently using this feature. Largely, we just haven't decided what information to store in 'stacktrace'. I'd say a data structure is more useful than a string, because it can be manipulated by various HLLs to the format of their stacktrace dumps. So, what information do the HLL developers want from the original stack trace? (I suppose technically we should stop calling this a stack trace since it's not a stack. But return continuation chain trace is just too verbose.) Allison
Re: [perl #60044] [BUG?] rethrow just throwing?
Will Coleda (via RT) wrote: I would expect both of these programs to output the same thing, but it looks like rethrow is generating the same output that throw would here. What is the difference supposed to be between these two ops? The two ops are intentionally almost entirely the same. The only difference is that 'throw' creates a new iterator of exception handlers, while 'rethrow' pulls the next exception handler off the iterator. So, 'rethrow' cannot be called on an exception that hasn't been thrown before. And if 'throw' is called on an exception that's already been thrown before, it will return to the first exception handler again, instead of the next exception handler in the chain of handlers. $ cat foo.pir sub foo :main bar() end sub bar baz() end sub baz die eek end $ ../../parrot foo.pir eek current instr.: 'baz' pc 24 (foo.pir:10) called from Sub 'bar' pc 19 (foo.pir:6) called from Sub 'foo' pc 7 (foo.pir:2) $ cat bar.pir sub foo :main push_eh eh bar() pop_eh end eh: .get_results($P0) rethrow $P0 end sub bar baz() end sub baz die eek end $ ../../parrot bar.pir eek current instr.: 'foo' pc 16 (bar.pir:9) I don't understand the problem. Is it that you expect 'rethrow' to keep the stack trace of the original 'die'? Allison
Re: Parrot on mobile platforms?
Ovid wrote: I can't speak for Android, but I know one of the constraints on the iPhone is memory. This, as I recall, is part of the reason why they don't have garbage collection available and force people to manage memory directly (this, I might add, is a pain). Since I generally don't worry about memory, I've no idea if Parrot is a memory hog. It's light on memory compared to other virtual machines, but would require some work to get it down to mobile phone size. That being said, I can't imagine Apple would be terribly keen to endorse anything which requires jail breaking the phone. Don't we have contacts in Apple? Getting official approval for trying this out might be a nice thing. In fact, I already know an iPhone developer who would be a great fit for a challenge like this (if he's interested). Yes, but the mobile group is completely separate from the open source group. Still, it's worth asking. Allison
Re: [perl #60048] CGP Does Not Work with PCC Runcore Reentry
chromatic (via RT) wrote: Several tests fail with the CGP runcore (parrot -C) when multidispatch re-enters bytecode -- in specific, anything that calls into src/pic.c from Parrot_pcc_invoke_sub_from_sig_object causes failures. The problem appears to be that CGP's PIC tries to poke into the bytecode directly to find get_params and similar opcodes, while parameter-passing information is in a context after Parrot_pcc_invoke_sub_from_sig_object. One workaround is to enforce the use of the normal runcore only for calls back into Parrot from Parrot_pcc_invoke_sub_from_sig_object, but that's just a workaround. A better solution is to fix the PIC code to look in the appropriate place in the context for return values. That seems like a good task for the calling conventions branch. I've been debating whether src/pic.c should be removed entirely. It's a swodge of code that only gives a tiny speedup for 4 opcodes: 'infix', 'get_params', 'set_args', and 'set_returns'. And the 'infix' opcode has been deprecated and will be removed in the calling conventions branch (it was a nasty hack for the old MMD system). And it's not even really the right speedup for 'get_params', 'set_args', and 'set_returns'. There are also a pile of old, nasty MMD functions that should be deleted and are only called from src/pic.c. Allison
[perl #46677] [TODO] [C] Merge fixedbooleanarray.pmc with functions from BigInt PMC
On Tue Sep 23 22:34:38 2008, cotto wrote: I propose to reject this ticket. Reducing code duplication is a good idea, but it's not at all clear to me what this ticket is referring to. If someone cares to point out what code should be merged, great. Otherwise this ticket is too vague to be useful. Ticket rejected, and comment removed from code in r32039. Allison
[perl #40392] [CAGE] convert Cexit_fatal to a catchable exception
On Mon Sep 22 06:37:24 2008, Whiteknight wrote: 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. In the process of changing 'internal_exception' to 'exit_fatal' we reviewed those calls, and changed as many as possible to real exceptions. (Basically, if it could be converted to an exception, it was, if it couldn't be, it was left as 'exit_fatal'.) Closing this ticket. Allison
Re: [perl #59636] [BUG] t/op/bitwise.t fails on Darwin
James Keenan via RT wrote: On Sat Oct 18 16:28:22 2008, coke wrote: I'm submitting some every night at midnight on my osx/x86 box; if it's obviously a temp directory and the right time frame, it's probably me. Coke, can you confirm that the test is failing for you now? And, what version of Mac OS? So it seems to be failing consistently on Darwin regardless of platform. It's passing on Mac OS 10.5.5 on my Intel laptop. Which makes it difficult to debug the failure. Also, tonight I confirmed that the failure began at the recent merge in r31668. For the record, the svn diff of the test file at that point was: $ svn diff -r 31667:31668 t/op/bitwise.t Index: t/op/bitwise.t === --- t/op/bitwise.t (revision 31667) +++ t/op/bitwise.t (revision 31668) @@ -552,11 +552,11 @@ loop: if $P1 100 goto done ## shift number and i_number into $P2 and $I2. -n_shl $P2, number, $P1 +shl $P2, number, $P1 $I1 = $P1 shl $I2, i_number, $I1 ## compare in I registers. -$P3 = n_mod $P2, integer_modulus +$P3 = mod $P2, integer_modulus $I3 = $P3 if $I2 = 0 goto pos_check ## The register op gave a negative result, but the modulus will always be However, as this test is passing on many other platforms, it's quite possible that the failure is due to something that happened elsewhere in r31668. I would suggest reverting that one change to see if it solves the problem, but the n_mod and n_shl opcodes don't exist anymore. Could you run the attached modified version of the test file and send me the output? Allison ## The PMC shl op will promote Integer to Bigint when needed. We can't stuff a ## BigInt in an I register, but we can produce the same result modulo wordsize. ## [Only we cheat by using the word size minus one, so that we don't have to ## deal with negative numbers. -- rgr, 2-Jun-07.] .sub main :main ## Figure out the wordsize. We need integer_modulus because assigning a ## too-big BigInt throws an error otherwise. .include 'sysinfo.pasm' .local int i_bytes_per_word, i_bits_per_word_minus_one .local pmc bits_per_word_minus_one, integer_modulus i_bytes_per_word = sysinfo .SYSINFO_PARROT_INTSIZE i_bits_per_word_minus_one = 8 * i_bytes_per_word dec i_bits_per_word_minus_one bits_per_word_minus_one = new 'Integer' bits_per_word_minus_one = i_bits_per_word_minus_one integer_modulus = new 'BigInt' integer_modulus = 1 integer_modulus = bits_per_word_minus_one ## Test shifting a positive number. new $P0, 'Integer' set $P0, 101 test_shift($P0, integer_modulus) ## Test shifting a negative number. set $P0, -101 test_shift($P0, integer_modulus) .end .sub test_shift .param pmc number .param pmc integer_modulus new $P1, 'Integer' set $P1, 1 .local int i_number i_number = number ## Start the loop. loop: if $P1 100 goto done ## shift number and i_number into $P2 and $I2. say \nno error before shl $S0 = typeof number print typeof first argument 'number' is say $S0 $S0 = typeof $P1 print typeof second argument '$P1' is say $S0 shl $P2, number, $P1 say no error after shl $S0 = typeof $P2 print typeof result '$P2' is say $S0 $I1 = $P1 shl $I2, i_number, $I1 ## compare in I registers. say \nno error before mod $S0 = typeof $P2 print typeof first argument '$P2' is say $S0 $S0 = typeof integer_modulus print typeof second argument 'integer_modulus' is say $S0 $P3 = mod $P2, integer_modulus say no error after mod $S0 = typeof $P3 print typeof result '$P3' is say $S0 $I3 = $P3 if $I2 = 0 goto pos_check ## The register op gave a negative result, but the modulus will always be ## positive. If the truncated result is correct, then the difference will ## be the most negative INTVAL, which is the only number for which -x==x. $I4 = $I3 - $I2 $I5 = - $I4 if $I4 == $I5 goto ok goto bad pos_check: if $I2 == $I3 goto ok bad: print oops; not ok: print i_number print ' ' print $I1 print ' gives I ' print $I2 print ' vs. P ' print $P3 print .\n print $I5 print \n ok: ## set up for the next one inc $P1 goto loop done: print done.\n .end
Re: [perl #45965] [RFC] Should slot names still have __ in front?
chromatic wrote: On Wednesday 15 October 2008 17:33:58 Will Coleda via RT wrote: With the attached patch, parrot builds and tests with no errors[0]. A re-configure is necessary to regenerate a file. [0] well, no additional or unexpected errors. Works for me. +1 to apply. +1 Allison
Re: [perl #36249] [TODO] Document policy on breakage, er, backward compatibility.
jerry gay wrote: On Thu, Oct 16, 2008 at 10:12 AM, Andrew Whitworth via RT [EMAIL PROTECTED] wrote: 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. replace 0.8 with 0.50 or so. we're not close enough to release at 0.8 to worry about this yet. Change that to 1.0, which is when we'll start guaranteeing API stability. And, we have discussed it considerably. The most likely scenario so far is: - Yearly major release (1.0, 2.0, 3.0...), which may contain substantial API changes. - Half-yearly minor release (1.5, 2.5, 3.5...), which may contain minor API changes, and deprecation notices for the next major release. - Regular (two/three month?) point releases (1.x.x, 2.x.x...) primarily bug and security fixes, which will contain no API deletions, but may contain minor API additions, and deprecation notices for the next major or minor release. This continues our time-based release policy, which has worked well for the development release process. Features that don't make it into one major or minor release get rolled into the branch for the next major or minor release, so we don't have an insane rush to cram features in just before a release. Allison
Re: [perl #58988] [RFC] Parrot_get_runtime_prefix function
NotFound (via RT) wrote: The Parrot_get_runtime_prefix in src/library.c return a char *, forcing the places that currently uses it to be more complicated than desired for no real gain. I added and used a STRING * variant named Parrot_get_runtime_path (that name makes more sense to me) in r31216 The question is: must we retain the old variant, kill it, deprecate it, use his name for the new version, or revert the change and stay with the char * way? 'STRING *' is vastly preferable to 'char *' anywhere it can be used. Mark the old one as deprecated, replace all calls to 'Parrot_get_runtime_prefix' with calls to 'Parrot_get_runtime_path', and after a standard one release deprecation cycle remove the old function. Allison
Re: [perl #59240] Automate publishing of docs/*
Chris Davaz wrote: Ahh, cool I didn't even know we had parrot.org. Publishing docs/book/* would be nice. On Tue, Sep 23, 2008 at 10:27 PM, Will Coleda: On Tue, Sep 23, 2008 at 9:04 AM, via RT Chris Davaz: I suggest we automate the publishing of everything under docs/* and putting it under parrotcode.org/docs in HTML format for easy access. This would probably help productivity and maybe even attract new developers. Just my two cents... we're moving to http://www.parrot.org/ ; I think Allison has said we're going to automate this publishing process. Yes, we're moving to docs.parrot.org, a site generated using a fork of the perldoc.perl.org generation code. (Ideally, this will end up being the 'make html' target, so anyone can generate a mirror of the same site.) Allison
Re: [perl #46295] [CAGE] [pdd15oo] Review the docs w.r.t. the new OO implementation
Andrew Whitworth via RT wrote: 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? This ticket can be closed. We have a general documentation review pass coming up preparing for the 1.0 release, and this is just part of that. Doesn't need a separate ticket. Allison
Re: [perl #57438] [DEPRECATED] [PDD19] .pragma n_operators
Andrew Whitworth via RT wrote: After the pdd27mmd merge, all the n_* opcodes are gone now. I assume the .pragma n_operators can disappear with them? Yes. (The n_* opcodes aren't quite all gone yet, but nearly and soon.) Allison
Re: [perl #59636] [BUG] t/op/bitwise.t fails on Darwin
James Keenan via RT wrote: Still failing on Darwin/PPC as of r32014: http://smolder.plusthree.com/app/public_projects/tap_stream/6320/163 Looking at the specific test in question, this may be an integer size problem. And I should note that it's also been failing on Darwin/i386: http://smolder.plusthree.com/app/public_projects/tap_stream/6316/163 What version of Darwin and what x86 hardware? Allison
[perl #38432] [BUG] Exception thrown from constructor leads to oddness
On Wed Oct 15 12:42:23 2008, coke wrote: Here's yet another updated version (this time for the exception handler) of the test that doesn't segfault, but still generates incorrect output (generates both an OK line and a NOK line) It looks like the exception handler is resuming after the exception is handled. (Resuming by default, instead of only resuming when the resume continuation is explicitly invoked.) Allison
Re: [perl #59544] open(null) kills parrot
NotFound wrote: Where to put a test for this? There is no t/ops/io.t and creating a file for each io opcode seems excessive Create a t/ops/io.t. We'll add to it in the I/O milestone (the next one on the list, which I'll create a branch for later this week). Allison
Re: [perl #59658] Build failure in src/pmc/float.c -- non-constant intiializer
jerry gay wrote: .\src\pmc\float.c(3340) : warning C4204: nonstandard extension used : non-constant aggregate initializer there are now hundreds of these warnings in that build. we do have warnings ratcheted up pretty high, but i don't think it's worth relaxing them for this construct unless it's very difficult to change the code generator--i assume this is generated code, since it's in so many pmc .c files. i may get a chance to investigate further this evening, if somebody hasn't beaten me to it. Yes, that's generated code, it's part of the initialization of MULTIs declared in a PMC. I was hoping to avoid all those C strings. But, try r31879. Allison
Re: [perl #59782] [PATCH] add pmc_cmp VTABLE function
Christoph Otto (via RT) wrote: In response to a question about comparison operators in Pipp*, Allison suggested that I add a variant cmp VTABLE function which returns a PMC instead of an INTVAL. This patch adds such a function, named pmc_cmp. It's named pmc_cmp rather than cmp_pmc to try to avoid confusion with the other cmp_* functions, since the type name in this function name refers to the return type rather than the argument type. Hmmm... we don't use that convention anywhere else (putting the type first to indicate that it's a return type, rather than an argument type). The closest we come is the 'get' and 'set' vtable functions which are 'get_returntype_keyed_argumenttype'. The 'shift' and 'pop' vtable functions both use 'shift_pmc' and 'pop_pmc' to indicate that the return type is a PMC. So, let's stick with 'cmp_pmc' for this one. Otherwise, thumbs up, looks great! Allison
Re: [svn:parrot] r31385 - trunk/docs/book
jerry gay wrote: i believe (without looking) that the pmc pdd calls them vtable functions. i really wish the vtable methods meme would die. they're not methods. they are a collection functions which define the api to access the pmc, parrot's abstract data type. Yup. vtable functions is what I've been standardizing on everywhere I find the old vtable method. Allison
Re: [svn:parrot] r31385 - trunk/docs/book
Patrick R. Michaud wrote: I'm not at all arguing that this automatically means we should call them methods, but at a conceptual level they certainly seem a lot like methods, and the vtable implementations contain references to things like SELF and STATICSELF that make them look awfully method-like. Regardless, I'll be happy to call them entries, methods, functions or whatever the consensus and documentation ends up saying they are. :-) They're all executable code entities of one sort or another. It's mainly a matter of choosing names that clearly mark different things as different. I picked vtable functions because they're directly invoked C function pointers (even the PIR vtable overrides are C function pointers that then do an override lookup). This differentiates them from from methods which are sub-like objects that take an invocant argument passed separately from the other arguments, are stored in the Class object, and can be invoked using the obj.'method'() syntax. There are plenty of other possible naming schemes, but this one works well enough for our purposes. Oh, and vtable entries was another common old way of referring to them, but I've been updating those to vtable function too, because entry seems a little vague (though, it's technically accurate, because the vtable is a whole set of functions (a table of functions) for the PMC, so a single vtable function is an entry in that vtable). Allison
Re: throw oddities in pdd23
Stephen Weeks wrote: Commit 31294 implements this behavior. Can I get confirmation that it's correct? Just looked over the diff. Perfect. Thanks! Allison
Re: [svn:parrot] r31305 - in branches/pdd27mmd: include/parrot src
chromatic wrote: On Sunday 21 September 2008 03:17:18 [EMAIL PROTECTED] wrote: +dod_unregister_pmc(interp, sig_object); [...] That's far away from registering the PMC; is there a way to move them closer together? We could register it after it's returned from 'Parrot_build_sig_object_from_varargs' instead of as soon as it's created in the function. That'd only be a few lines away with the register and unregister the same function. But with the current garbage collector, I feel safer registering the signature object as soon as it's created. Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
jerry gay wrote: Patrick R. Michaud wrote: Other languages have adopted the Perl shortname of hash as well, including Ruby and this odd little creature known as Parrot. Perhaps we should rename Parrot's Hash class to AssociativePMCArray? 1/2 ;-) I wouldn't mind. I mean, various languages will certainly have a type called Hash, but that doesn't mean the core Parrot type needs to be. And really, it would fit in better with our general PMC naming scheme, and might open up the door for AssociativeStringArray, AssociativeIntegerArray, and AssociativeBooleanArray. we should call gather and take by their proper names where they're defined. aggregating coroutine is more precise and descriptive than is gather, however gather is much easier to say in polite company, and is therefore a better name to use at the language level. By this reasoning, we should also change the other exceptions: .CONTROL_RETURN = .CONTROL_SUB_RETURN (or .CONTROL_SUB_EXIT) .CONTROL_BREAK= .CONTROL_LOOP_EXIT .CONTROL_CONTINUE = .CONTROL_LOOP_NEXT and perhaps add .CONTROL_LOOP_REPEAT there as well. Note that I'm not at all opposed to this -- if we're going to do it for one, we really ought to do it for all. agreed. precision is of little benefit unless it's consistent across related functionality. H... yeah, I like that idea. Especially since 'break' and 'continue' mean different things in different languages and different contexts (like 'break' and 'continue' in gdb, for example). Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Patrick R. Michaud wrote: It's also a little unique that the take/yield can happen from called subs deep within the coroutine, and doesn't have to occur within the coroutine itself. That's a general characteristic of all the control exceptions: they can be caught by any outer dynamic scope, not just the immediate surrounding dynamic scope. Allison
Re: Parrot 0.7.1 Manu Aloha released
Patrick R. Michaud wrote: I sent the appropriate patch to the webmaster, but it hasn't been applied yet (and I lack a commit bit for the parrotcode.org site). Once that's applied, the url should be fixed. Thanks, applied. I also updated parrot.org. Allison
Re: New Parrot mailing list
Patrick R. Michaud wrote: On Thu, Sep 18, 2008 at 11:00:31AM +0200, Allison Randal wrote: We'll likely end up with messages scattered between both lists for a little while, but the perl6-internals/parrot-porters addresses are deprecated and will be disabled after a sensible deprecation cycle (and after the automatic RT posts have been shifted to parrot-dev). Will we also be able to get svn commits to the new mailing list, or at least to *a* mailing list? The svn commits are a different mailing list, which will stay where it is until we move the subversion server to parrot.org. (Then the new commits mailing list will be [EMAIL PROTECTED]) The new mailing list will not automatically update tickets in the RT queue, for that CC [EMAIL PROTECTED] on the message. Wouldn't it be possible to have the new mailing list manager check for [perl #n] in the message subject and automatically forward it (controlling for loops as appropriate)? Yes, almost certainly. But we're also moving to a new ticket queue, so I'd rather not invest the time in hacking up the new infrastructure to interface with the old infrastructure. There's a question on the new system of whether we should continue to have tickets forward to the main development list like we do now, or have them forward to a separate 'parrot-tickets' mailing list like we do with commit log messages. What seems best to you all? (If we do separate the lists, anyone has the option to have them all file into the same mail folder, it just gives others the option of separating ticket traffic from regular messages.) Allison
Re: New Parrot mailing list
James E Keenan wrote: I set up the Google Group, because I know a number of people are using it. Can I see a show of hands of people who are only using NNTP and would have difficulty switching to a regular email subscription or Google Group? (I can't send to a newsgroup from my email client, so Jim, could you forward this on?) And only just now found that Jim had CC'd the parrot mailing list as well as the news group that I wasn't able to reply to. I wouldn't be sad to see NNTP go. Allison
Re: New Parrot mailing list
James E Keenan wrote: That's false. I replied to the newsgroup, which is mirrored by the mailing list. Whenever I've posted to the list (independent of posts to RT), the posts have been mirrored by the mailing list. You asked we to forward this on, so I did exactly what I've done for hundreds of other posts over the last two years. Makes sense. There's likely a delay from the time a post goes to the newsgroup before it makes it to the mailing list, so I replied to the direct message (where you CC'd the newsgroup), long before it hit the mailing list. (IIRC, I've been caught by this before.) Thanks for forwarding it on, exactly as I asked. :) Allison
Re: New Parrot mailing list
Andy Dougherty wrote: I use NNTP. I much prefer the command-line news interface to Google Groups, but I guess I wouldn't go so far as to say I would have difficulty switching to a regular email subscription. Or, to put it another way: If there were an NNTP interface, I would definitely use it, but I wouldn't want anyone else to be stuck implementing and maintaining it just for my occasional use. I wonder why no one has developed a command-line NNTP-like interface for email? Maybe following mailing lists via RSS and feed readers has satisfied the need enough that no one got around to it? This looks interesting, if anyone's motivated: http://www.methodize.org/nntprss/ Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Patrick R. Michaud wrote: What's the language-agnostic term for this, then? Well, 'gather' is basically a clever use of a coroutine, and 'take' is basically a 'yield'. But, what's unique about the construct is that it aggregates the results. So, 'gather' is an aggregating coroutine and 'take' is an aggregating yield. To allow for a distinction in the control exception types, call it 'CONTROL_YIELD_AGGREGATE'. Aggregating coroutine and aggregating yield aren't nearly as zippy as 'gather' and 'take', but they're more meaningful to a broader audience, which may help the feature spread. Allison
Re: throw oddities in pdd23
Stephen Weeks wrote: This has now been committed to trunk. I'm pretty sure that I updated every exception handler in the tree. Apologies if my comments on this thread and update to the exceptions PDD weren't clear. The resume continuation should continue to live within the exception object, not be passed as a separate argument to the handler. The change to remove the exception message string as a separate parameter to the handler is correct, thanks for making that. -- (The current text of PDD23 is accurate:) Active exception handlers (if any) will be invoked with IEXCEPTION as the only parameter, and the return continuation stored within that exception object. -- Please revert the branch merge or make another update. Thanks! Allison
New Parrot mailing list
The new Parrot mailing list (replacing perl6-internals/parrot-porters) is [EMAIL PROTECTED]. If you were subscribed to the old list, you're now subscribed to the new list. If you were a digest subscriber to the old list, you're now a digest subscriber to the new list. More information about the list and public archives are available at: http://lists.parrot.org/mailman/listinfo/parrot-dev A Google group for the list has been created at: http://groups.google.com/group/parrot-dev We'll likely end up with messages scattered between both lists for a little while, but the perl6-internals/parrot-porters addresses are deprecated and will be disabled after a sensible deprecation cycle (and after the automatic RT posts have been shifted to parrot-dev). The new mailing list will not automatically update tickets in the RT queue, for that CC [EMAIL PROTECTED] on the message. Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Patrick R. Michaud wrote: I'm not sure about this last comment -- I think I can imagine that other language implementations (including new ones we haven't thought of yet but suddenly becomes possible with Parrot) might want to make use of gather/take semantics if they're readily available -- especially because they can be very hard to otherwise implement when they're not readily available. And compile-time constants are pretty cheap. :-) Absolutely. But for that it shouldn't be called CONTROL_TAKE, because that's meaningless outside Perl 6. So, I think we can't always say oh, only one dynamic language needs this feature so it shouldn't be global -- we need to also consider those dynamic-languages-yet-to-be-written because Parrot is such an incredible platform for creating them. Yes, that's not the principle. The principle is that global things should be language-agnostic, and not use terminology that's confusing to all the other languages. Allison
Re: ExceptionHandler enhancement proposal
Bob Rogers wrote: Yes, once we have the ability to have exception handlers only handle specific types of exceptions, then they'll allow all other types of exceptions to pass through. (Which means we won't end up with the infinite exception handler loops we currently get if exception handlers aren't disabled as soon as they're used.) Are you sure? What if the body of a catch-all error handler signals an error? Methinks the handler must truly be taken out of scope before it is invoked in order to avoid infinite exception handler loops. Yes, of course a catch-all exception handler will always catch all exceptions. But, a catch-all exception handler is intended to catch all exceptions, and therefore can't make any assumptions about the exception object other than the defined standard exception interface. The problem now isn't that the same exception handler is being called twice (once on the first exception, and once on the exception thrown from within the handler). The problem is that the exception handlers were written assuming that they'd only ever get one kind of exception. When they get a different kind of exception the second time, they aren't expecting it, and make some terrible mistake, which throws another exception, but they don't know how to handle that one and make a terrible error and throw another exception, and so get themselves into an infinite loop. The 'can_handle' method is the only required interface for checking whether a particular handler will accept a particular exception. All other checks should be hidden behind that method. Hmm. The only way to find out whether a Lisp handler will handler a given exception is to call it; if the answer is yes, it will never return. So I'm hoping a 'can_handle' method that either returns false or transfers control to somewhere else can be made to work. For that, you would implement a catch-all handler (completely ignoring 'can_handle'), and then rethrow any exceptions you can't handle. Allison
Re: throw oddities in pdd23
Patrick R. Michaud wrote: PDD23:67 has: : =item Bthrow IEXCEPTION : : Throw an exception consisting of the given IEXCEPTION PMC. Active exception : handlers (if any) will be invoked with IEXCEPTION as the only parameter. : : : =item Bthrow IEXCEPTION [ , ICONTINUATION ] : : Throw an exception consisting of the given IEXCEPTION PMC after taking : a continuation at the next opcode. When a ICONTINUATION is passed in, : it will use that instead. Active exception handlers (if any) will be : invoked with IEXCEPTION and the given continuation as parameters. This looks weird in a couple of respects. The second Cthrow opcode shows ICONTINUATION as an optional parameter, which would seem to be in conflict with the first form (i.e., they end up being identical if ICONTINUATION is omitted). Next, reading the above makes it look as though exception handlers can sometimes be invoked with a single parameter (the exception) and sometimes with two parameters (the exception and a continuation). Perhaps it would be better to have a consistent calling interface? (I do suppose we could say that the second parameter is always optional.) I suspect much of the confusion comes from when Cthrowcc was (apparently) eliminated in favor of a single Cthrow opcode, but pdd23 wasn't made internally consistent. Yes, Cthrow and Cthrowcc were collapsed into one opcode, and left some editing junk behind. I just changed it to one entry for Cthrow. Also, note that the single-argument Cthrow opcode is currently doing more than simply cause exception handlers to be invoked -- it's also takes a resume continuation and stores it in the IEXCEPTION PMC itself (src/ops/core.ops:817). This would seem to be in conflict with the next sentence at pdd23:80 : : Any type of PMC can be thrown as an exception. Clearly we cannot use the single-argument Cthrow on a PMC that doesn't have a resume attribute for us to store the resume continuation. Personally I like the idea that any PMC can be thrown as an exception, which would seem to argue against forcing resume continuations into the thrown PMC (which might not have a slot for them). So, rather than saying that anything thrown as an exception contains its resume continuation, perhaps we should say that all handlers are invoked with the exception and resume continuation as arguments, and the single-argument throw simply takes a continuation at the next instruction to pass to the handler(s). Alternatively, we could say that Cthrow only places a resume continuation into PMCs that does exception, but somehow I find this less desirable than the above approach. Okay, PDD cleaned up. The code to directly support throwing any arbitrary type would require significant circumlocution (read: inefficient, difficult to maintain), so it's not desirable. It's not just a matter of removing the return continuation from the exception object, we'd have to remove all metadata from the exception object (stacktrace, payload, handler iterator, type and severity information), and either pass all that information as arguments throughout the system (expensive and error-prone) or store it as global state information (error-prone, and bad for a clean implementation of concurrency). But, an individual HLL can store any arbitrary PMC value as the payload of an exception object, and act as if it had thrown an arbitrary PMC as an exception. Allison
Re: [perl #58886] [BUG] :named argument handling in PIR
Will Coleda (via RT) wrote: [...] I would expect one of the following things to happen here, either: - an error is generated when test2 is parsed because there is no name for the named parameter, or - test2's blarg .param should default to being named 'blarg', so both calls should work identically. Even more confusing, this code: Yes, we need better error checking and better error reporting in named argument handling. We need a general invocation refactor, but can do it in small stages. Let's go with defaulting to the same name as the .param on the bare :named. Allison
Re: [perl #58866] calling a PIR sub with 206 params segfaults parrot
Christoph Otto (via RT) wrote: I was looking at #45357 ([TODO] Which exception should be thrown with register overflow?) and found that Parrot doesn't like subs with more than 205 params. This seems like a perfectly reasonable limit, but perhaps the behavior could be more user-friendly.* Maybe an EXCEPTION_ERR_OVERFLOW should be thrown here instead? Using the attached patch to reproduce: $ perl mktoomanyargs.pltoomanyargs.pir ./parrot toomanyargs.pir Segmentation fault (core dumped) *On the other hand, we may choose to be overtly hostile to users who do things like call subs with 206 parameters. It's a design decision. It certainly shouldn't segfault. But, the question is: why does it segfault at 206 parameters? Throwing an exception to avoid an error we don't understand isn't good for the long-term health of the VM. Allison
Re: ExceptionHandler enhancement proposal
Stephen Weeks wrote:
ExceptionHandler currently has a can_handle method that checks whether
the EH has been disabled or not. I propose adding some attributes to
store the minimum severity the EH will handle and the list of exception
types the EH will handle, methods to set and get these properties, and
extend can_handle to check the exception against these properties.
Yes, this was spec'd but not yet implemented, and can be implemented
now. ('can_handle' was intended to be expanded for this.)
Once this is in place, I understand we can remove the disable exception
handler functionality currently in place and replace it with setting
handled types appropriately.
Yes, once we have the ability to have exception handlers only handle
specific types of exceptions, then they'll allow all other types of
exceptions to pass through. (Which means we won't end up with the
infinite exception handler loops we currently get if exception handlers
aren't disabled as soon as they're used.)
Questions that have been raised about this proposal on IRC include:
* Minimum severity, range of severities, list of severities?
Minimum and maximum (which define a range if both are set). Let's skip
selective lists (I'll handle severity 2, 8, and 42 is less useful).
* List of types, or single type?
- Note that you could create multiple EHs that refer to the same
label or sub that handle different exception types.
A list of types. Ultimately exception types will likely be more than
just integer types, but the integer types will do for now.
Also, the 'can_handle' method can be overloaded to check *any* attribute
of the exception to decide if that handler can handle it. We may want to
canonize this by allowing Parrot's ExceptionHandler PMC to store a sub
object that is run by 'can_handle' on the exception to determine if it's
appropriate.
Any proposals on naming or other API considerations?
The 'can_handle' method is the only required interface for checking
whether a particular handler will accept a particular exception. All
other checks should be hidden behind that method.
Any other thoughts or comments?
Make it so, Mr. Crusher. :)
Allison
Re: [perl #39313] [TODO] or [BUG] improve PMC compiler
Klaas-Jan Stol wrote: This ticket doesn't seem to be closeable as is.Would it be good enough if pmc2c.pl spit out an error on the above definition, or is this even something that pmc2c.pl should be concerned about? The goal of the ticket should be for pmc2c.pl to entirely parse the input PMC files. Either passing through uncooked C, or doing transformations. Silently dropping code on the floor is not acceptable. Pmc2c is just a series of regular expressions. It looks for specific patterns, and if it finds them, builds relevant C code out of them. It has no ability to check for arbitrary syntax that *doesn't* match a pattern. It's a preprocessor (macro substitution), not a language parser. What could be done is have it dump anything leftover after the extraction into the resulting C file. Then you'd get a C error on compilation. wouldn't a PGE-based compiler be helpful? Yes, certainly desirable, but we're not shooting for that level of bootstrapping in the 1.0 release. When we eliminate all dependencies on Perl, we'll move over to a PGE-based compiler, and keep the generated C code checked into the repository like we keep the generated flex/bison files checked in. Allison
Re: [perl #58236] [TODO][PDD19] make decision on open issue on .return directive in pdd19
Klaas-Jan Stol wrote: Allison: I made the following changes in pirc/new: .arg - .set_arg .result - .get_result .return - .tailcall (in context of .return foo() , which thus is now: .tailcall foo() ) .return - .set_return (in long-style returning : .begin/end_return .yield - .set_yield ( in long-style yielding : .begin/end_yield) From your answers in your previous reply I deduce you support such changes. Can you reconfirm, then I'll make the appropriate changes in PDD19. Thumbs up, thanks! Allison
Re: [svn:parrot] r30941 - branches/pdd27mmd/src
NotFound wrote: By the way, as mentioned in other thread there is a problem with plain %s in parrot printf-alike functions. It does not handle well a NULL c string. This must be fixed. And before, given the current implementation, the behavior of string_make and his successor in the strings pdd, when receiving a NULL c string must be documented and implemented, or we risk to plague the code base with lots of more workarounds. This should be submitted as a separate ticket with example code/error messages. Allison
Re: [perl #58794] [PATCH] remove the obsolete .past search in try_bytecode_extensions
Reini Urban (via RT) wrote: Old: Guess extensions, so that the user can drop the extensions leaving it up to the build process/install whether or not a .pbc, .pasm, .past or a .pir file is used. New: Search only for .pbc, .pasm, and .pir in that order. The .past file-extension is *long* deprecated said particle on #parrot. Thanks, approved for application in trunk. Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Patrick R. Michaud wrote: On Sat, Sep 13, 2008 at 01:55:05PM -0400, Will Coleda wrote: +CONTROL_TAKE } exception_type_enum; Tcl can currently deal with OK, CONTINUE, BREAK, ERROR, and RETURN. What's TAKE? TAKE is like CONTROL_RETURN except that it signals that we expect execution to continue after the point of the TAKE. It's quite similar to a .yield operation for coroutines. Would CONTROL_YIELD make more sense? I would have known what yield meant. It might be a bit misleading, because it doesn't actually correspond to a .yield (and thus I can envision CONTROL_YIELD as yet another exception type). I'm still brainstorming ways to get the gather/take semantics we need by using Parrot's .yield, but so far I haven't come up with a good way to do it. Eventually we'll need to stop defining exception types as a global enum, and let individual languages define their own. EXCEPTION_TAKE really doesn't make sense for anything other than Perl 6. Not today, but someday. Allison
Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.
Vasily Chekalkin wrote: And another question. Should all lvalue occurences of PMC_*_val(SELF) be replaced with VTABLE_set_*_native? (Except for VTABLE method implementation of cause) In general, yes. You'll have to check each PMC to see if they have the appropriate VTABLE_set_*(_native) vtable function defined. (Ultimately, the storage for these PMCs should all be changed to ATTRs and the accessors to GET_ATTR_* and SET_ATTR_*.) Allison
Re: [perl #46651] [TODO] [C] Make a better interface for hash creation
Christoph Otto via RT wrote: On Mon Oct 22 07:01:59 2007, pcoch wrote: In src/pmc/hash.pmc:thaw() there is the todo item: /* TODO make a better interface for hash creation ... do this. Where do we want to go with this? Ax the ticket. Vague plans for future change aren't useful. Allison
Re: [svn:parrot] r30941 - branches/pdd27mmd/src
chromatic wrote: That C string leaks. We should have a diagnostic printf which supports the %Ss format we use in exception formatting strings. We have one, it's called PIO_fprintf. But, it's only used once in the repository, in an STM macro. Added to the I/O milestone tasklist. Allison
Re: [svn:parrot] r30941 - branches/pdd27mmd/src
NotFound wrote: On Wed, Sep 10, 2008 at 9:21 AM, Allison Randal [EMAIL PROTECTED] wrote: chromatic wrote: That C string leaks. We should have a diagnostic printf which supports the %Ss format we use in exception formatting strings. We have one, it's called PIO_fprintf. But, it's only used once in the repository, in an STM macro. We have more: PIO_printf, PIO_eprintf, Parrot_printf, Parrot_eprintf and Parrot_fprintf. The Parrot_ ones are a wrapper around the PIO_s, with added check for extern usage, and that does not need #include io files. Yes, to be more accurate, we have a whole range of PIO functions. But, the fact that they're used so rarely makes me doubt whether they're particularly reliable. The eprintf ones are adequate for diagnostic messages. But note that his usage with a NULL interpreter argument is flawed, only adequate for plain strings. But if you have a parrot string surely you have a parrot interpreter. Aye, that part shouldn't be a problem. Allison
Re: Why Some MMD Tests Fail
jerry gay wrote: On Mon, Sep 8, 2008 at 1:09 AM, Allison Randal [EMAIL PROTECTED] wrote: a) Do abstract base classes as currently implemented in Parrot serve any useful purpose? If not, eliminate them. can they be replaced by roles? Potentially, yes. In the case of the scalar PMC it would make quite a bit of sense as a role (composing in behavior common to scalar data types). For the default PMC it makes less sense. But then, I can see some argument there that default shouldn't be a PMC at all. Allison
Save the date: Parrot Developer Summit, November 15-16, 2008
Google has graciously agreed to host the first ever Parrot Developer Summit. November 15th and 16th, 2008 on Google's Mountain View campus. You can find directions to the campus at: http://code.google.com/events/visitors More details to follow. Hope to see you there! Allison
Re: More MMD Branch Diagnosis
chromatic wrote: t/op/calling_61.pir crashes because Parrot's trying to treat the number -1 as a PMC. Why? The desired MMD sub should take two PMCs and returns an INTVAL (frame #5, signature PP-I), but the invoked MMD sub takes two PMCs and returns a PMC. The crash comes in convert_arg, where the C function has returned INTVAL -1, but the argument passing code expects that it has returned and Integer PMC. Because 0x isn't a valid PMC pointer, there's a crash. If you look at src/pmc/integer.pmc, the cmp MULTIs there return INTVALs (signature IJPP), but the MULTI registration code declares them as signature PJPP. I modified Parrot::Pmc2c::MULTI to improve the return-value-of-cmp regexp and the test passes. Excellent! Go ahead and apply. This will also fix the PGE build problem, which is the same segfault caused by the wrong signature on the NCI sub. Allison
Re: [perl #54110] [BUG] segfault in infix/n_infix with string arguments
Patrick R. Michaud wrote: Just for clarification: IIUC, the n_* opcodes and their semantics aren't really going away -- they're simply being renamed to not have the leading n_ prefix. It's the existing add, sub, mul, div, etc. opcodes that are being eliminated. Yes. That is, calling 'add', 'sub', etc. will now create a new PMC for the result on all the builtin PMCs. But, HLL/application developers will have the option of writing their own PMCs that reuse the destination PMC instead of a creating a new one. [...] This would seem to indicate that the string variants of the various math opcodes are also going away (and that's okay with me). So, if we can just get an official ruling that the add_p_p_s, sub_p_p_s, etc. opcodes are going away, then we can close this ticket as moot. Yes, these string variants only existed because of the unintelligent way the infix/n_infix opcodes blindly redispatched. In the branch, where the math opcodes are real opcodes, there are no string variants and we're not adding them. So, ticket can be reclassified as irrelevant. Allison
Re: [perl #57920] [PATCH] Suggestion for Parrot Configure test of AIO
Will Coleda wrote: Instead of spending time fixing a probe that isn't being used, we should rip it out. If we eventually need it again, we can start from here, but there's no point in probing for features that we never use. It's wasting developer (and less importantly, CPU) time better spent elsewhere. Generally agreed. In this case, hold this ticket for the I/O milestone, which is next (sometime in the next few days). I've added it to the I/O tasklist. In the meantime, let's get Andy's patch applied (if it isn't already). Allison
Re: [perl #52054] [CAGE]: Make all PDDs conform to coding standards
Christoph Otto wrote: If those are your thoughts on the subject, then it seems to make sense to add the pdd format test to make test. The attached patch does this. I'll apply it and mark this ticket as resolved before the next #parrotsketch unless there are any objections. Excellent idea. Thanks! Allison
Re: [perl #58374] [TODO][PDD19] Decide on maximum identifier length and implement this.
Christoph Otto via RT wrote: If there isn't a technical reason why this is necessary, there's no reason to create such a limitation. If there is such a reason, just pick something big and make the code enforce it. The PDD should of course be kept in sync with reality, but that simply entails a simple edit/commit once the issue is settled. There is currently no need to limit the length of identifiers. Keep the note about possible future limits, because we may someday need a limit. (And because it's useful to document that there is currently no limit.) Allison
Re: Why Some MMD Tests Fail
chromatic wrote: The scalar PMC is abstract, but it contains multis that need registration with the MMD system at initialization time. PMCs containing multis register those multis in their Parrot_PMC name_class_init() functions. At least, non-abstract PMCs do. I ran into a similar problem with my vtable cloning work. We may need to initialize abstract PMCs somehow. Yes. I changed scalar to a non-abstract PMC with init a few days ago, but reverted it. (Abstract with init doesn't work, because the abstract class is never registered with Parrot, and therefore doesn't exist for multiple dispatch.) The current top two options in my mind: a) Do abstract base classes as currently implemented in Parrot serve any useful purpose? If not, eliminate them. b) Should abstract base classes be participating in multiple dispatch? If not, move the multi declarations to other real classes. Allison
Re: [perl #51464] [TODO] [PDD] add date stamps to PDD's
Christoph Otto via RT wrote: Is this something we want to go ahead with or should this ticket be rejected? I've had it on my hiveminder todo list for over a month now. The problem is, it's not only a matter of annoying fiddly bookkeeping work now, it's also annoying fiddly bookkeeping work eternally into the future. And, it doesn't actually solve the original problem of knowing when a PDD was significantly updated, because whoever edited the PDD might have just forgotten to update the manual date stamp. So, ticket rejected. The only authoritative information on revisions to a PDD is the commit logs. Allison
Re: [perl #55196] [BUG] print/say opcodes have different float precision
Christoph Otto via RT wrote: I'll sign up to do the grunt work to fix the failing tests if someone makes a decision on what the consistent behavior should be. This falls under the I/O PDD, the next milestone. Hold for a couple of days. I've added it to the tasklist for the milestone: http://www.parrot.org/wiki/io-tasklist Allison
Re: [perl #48014] [DEPRECATED] PMC union struct
NotFound wrote: Given that the name will be mainly used via macros, a long and meaningful name can be used, such as Parrot_PMCdata_PMCname That's a good refinement, we can make the change after the next release. The attached patch does it. There is a lot of changes, I suspect many of them are candidates for replacing with use of the SET_ATTR and GET_ATTR macros. Maybe defining a macro SELF_DATA_TYPE will be a convenient shortcut. Reading through the updated code, it seems that (using Task as an example): Parrot_PMCdata_Task is not much clearer than the original Parrot_Task was. Let's go with: Parrot_Task_attributes (Fortunately, with the string PMCdata in all the type names, it should be easy to write an automatic search-and-replace.) I only modified and tested parrot core, surely several languages needs some patching. Also, don't fixed line length codingstd. I expect approval before taken care of that, Otherwise approved, and thanks! Allison
[perl #39117] [TODO] Using v?snprintf/strlcpy/strlcat when useful
Agreed that this particular ticket is not useful. Resolve it and replace it with a [CAGE] ticket with explicit instructions on converting all existing 'sprintf', 'strcat', etc calls with calls to 'snprintf', 'strlcat', etc. (Also include a list of all calls that should be converted.) This can wait a couple of weeks until we dive into the String implementation milestone. Allison
Re: pdd30_install
I've just committed an initial pass on the Installation PDD. It's looking good, definitely a good start. I've included some comments to seed further discussion and development of the draft. Also, we'll need to include more details on the installation of Parrot itself (the draft leans pretty heavily toward language installation, because that's the current problem). Thanks, Reini, for putting this together. It's much easier to talk about the architectural decisions and the reasons behind them when we abstract away to a design document. Allison
Re: [ PATCH ] Broken link on parrotcode.org dev page - list item Parrot Testing Status
Ronald Schmidt wrote: I applied for an account and built what seems to me to be an appropriate Parrot Testing Status page. My proposed link target is http://www.parrot.org/wiki/some-testing-status-tools . If someone wants to set me up as a site editor I will fix the link myself otherwise the page is available for someone else to fix the link. Someone else beat me to granting you editor access. But, while I was in there anyway, I went ahead and switched the Wiki tab at the top to point to the top-level parrot.org wiki page. Allison
Re: [perl #52054] [CAGE]: Make all PDDs conform to coding standards
Christoph Otto wrote: The non-draft PDDs are all passing t/codingstd/pdd_format.t as of r30810, but two of the draft PDDs aren't. Since they're still drafts and as such are very likely to change, it doesn't seem worthwhile to bring them into compliance or to have a test depend on them. I propose that pdd_format.t be split into 2 otherwise identical tests; one for draft PDDs and one for final PDDs. The draft test could be permanently TODO'd, which would indicate if any of the drafts were broken without messing up the test results. The final PDD test could become part of make test and this ticket could be marked resolved. I'll submit a patch if this seems to be a reasonable solution. I just updated the draft PDDs so they pass. For as long as the 'draft' directory exists, I'd like the PDDs there to be subjected to the same formatting standards as the approved ones, even if they aren't official yet. Allison
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
jerry gay wrote: the sugar for what can be on the left side of an equals sign needs to be changed. simply having a first parameter with OUT isn't enough. the same thing happens for $P0 = push $S1 which is legal pir syntax, but obscure at best. ops must have some means of specifying (perhaps an attribute like C:returns or C:rvalue?) that allows them to be on the right side of the equals. only this class of ops allows the syntax described above. Yes, agreed. Allison
Re: How may I help maintain parrot.org?
Alejandro Gómez de Argüello y de Laburu wrote: Following the instructions I found in How to Get Involved at the parrot.org website, I hereby volunteer to help maintain said website by updating existing pages or adding new content, or in other ways such as my skills and time allow. Thanks for volunteering! Editor access granted. At the moment (since we just migrated), the biggest thing that's helpful is checking for broken links. The next thing that will be helpful is checking pages for out-of-date content. Even someone new to the project can try out the instructions a page gives and see if they still work. If they don't work, and you're not sure how they should work, you can check with us here. Allison
new Parrot website
The new Parrot website http://www.parrot.org/ is now live. Please take a look, create an account for yourself, and report any broken links you find. Just creating an account will allow you to create wiki pages. If you'd like to help out with content on other parts of the site, let me know and I'll grant you editor privileges. The Docs tab still points to the old site until we get docs.parrot.org set up (it'll be automatically generated from the repository). The Wiki tab also still points to the old wiki. After a few weeks we'll redirect parrotcode.org to parrot.org. Enjoy, Allison
Re: new Parrot website
Moritz Lenz wrote: Creating an account leads directly to the front page again, without any indication if it was successful or not. There should be a message just below the mission statement box and just above the first story on the main page. Possibly we should make the text red or put it in a red box to make it more obvious. Please do. I'd like to update the download page in a similar way as we recently did with the old page. (My account name is Moritz, surprise surprise) Editor permission granted. Allison
Re: new Parrot website
Alejandro Gómez de Argüello y de Laburu wrote: The How to Get Involved page at https://www.parrot.org/dev/get-involved has a broken link: clicking on Report or fix a bug in this website takes me to https://www.parrot.org/dev/site.html -- which says Page not found. The page at https://www.parrot.org/dev/todo.html gives me the same error. Fixed. (Changed the link for reporting a bug to information on submitting a ticket.) Also, attempting to upload a picture resulted in the following message: * The selected file /tmp/tmp_CJJgR1 could not be uploaded, because the destination files/pictures/picture-26.jpg is not properly configured. * Failed to upload the picture image; the pictures directory doesn't exist or is not writable. Ah, it was a permissions problem created in the launch, while moving things over from the test site. Fixed. (And I just uploaded a picture for my user to test that it works now.) The How to Get Involved page at https://www.parrot.org/dev/get-involved tells me how to get involved in Parrot development, but it does not tell me how I might help out with content on other parts of the site or what that would imply. A brief note about the latter on said page may yield some offers to help with parrot.org itself. Added a brief note. Thanks! Allison
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
Klaas-Jan Stol wrote: On Tue, Sep 2, 2008 at 2:28 PM, Allison Randal [EMAIL PROTECTED] wrote: I'm not clear on why we need to reserve 'if', 'unless' and 'null' either, since they never appear in locations that could be confused with variables. there's not a strict reason, no. In fact, it would be possible to allow them, although the implementation of that will require a number of special cases in the grammar (but doable, as far as my experiments showed me). We're marking them as a special case now to treat them as reserved words. The only concern would be (as Andrew indicated as well), that you could write: if null null goto goto if you had declared null and goto as .locals. That's more of a stylistic custom than something to enforce in the parser. But, like I said, this definitely isn't an urgent modification, just a general matter of clarity and consistency in PIR. Allison
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
Klaas-Jan Stol wrote: This must make the following syntax rule illegal: target = null because if null is declared as a .local, you can't know whether you want to nullify target, or want to set target's value to that of the .local variable null. I take it this is no problem; just stick to null target if you actually want to set target to 0/null. Yes, that's reasonable. The syntactic sugar was confusing in that case anyway. (Seemed like you were assigning a null value to the destination register, rather than nullifying the PMC in the destination register.) This belongs in a general category of opcodes where the standard transformation of call the opcode with the first argument stuck before an '=' sign doesn't really make sense. Allison
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
Klaas-Jan Stol wrote:
So, preferably, the special words in PIR will be allowed as identifiers
('if','unless', 'null') and PIR will DWIM. What about the type identifiers:
int, num, pmc, string; should these be allowed as identifiers? The currently
special PIR words such as if, unless, null are ops, and as opnames are
allowed as identifiers, allowing 'if', 'unless' and 'null' makes sense. The
type names on the other hand, are not related to PASM code, so I'd vote to
have them as 'reserved' words; but I'd just like to check now.
AFAIK, you can never use a variable in any position where you can use a
type name. So, you can't declare a variable named 'foo' and then use it
as a type:
.local string foo
* .local foo thingy # (* not valid syntax)
And also, you can't use a type name as a variable, if you haven't
actually declared a variable of that name:
* pmc = hello # (* not valid syntax)
So, there's no reason this couldn't be valid syntax, because there's no
ambiguity:
.local pmc pmc
pmc = new String
pmc = hello
(maybe the
general feeling is that there must be no reserved words in PIR...)
Not no reserved words just the smallest set of reserved words
possible, which means not reserving words we don't need to reserve.
I'm not clear on why we need to reserve 'if', 'unless' and 'null'
either, since they never appear in locations that could be confused with
variables.
Allison
Re: [svn:parrot-pdd] r30622 - trunk/docs/pdds/draft
Bob Rogers wrote: Allison Randal wrote: +Monkeypatching is certainly possible, but not encouraged. Cool; a new term in Allison-speak! ;-} As much as linguists love creating new words, I can't claim credit for this one: http://en.wikipedia.org/wiki/Monkey_patch More later, Allison
Re: [svn:parrot-pdd] r30622 - trunk/docs/pdds/draft
Bob Rogers wrote:
+{{ There seems to be an implied basic assumption here that language
+interoperability is the responsibility of the language
+implementor. It is not. We cannot require that language
+implementors design and implement their languages according to some
+global specification.
If you are not happy with that assumption, then I'm surprised you
bothered to commit this draft at all, even as a starting point.
Design is a process. If you don't understand what I'm getting at, then
it means I haven't explained it well enough yet. And, revising the draft
to help you understand also produces a design document, so it's doubly
useful.
Even
then, surely, it must *still* be the responsibility of the language
implementor not to introduce gratuitous barriers to interoperability?
As a case in point, consider keyword (named) parameters in Lisp.
Kea-CL does not use Parrot named parameters to implement key, partly
for ANSI compliance and partly for efficiency. This currently makes it
problematic (though not impossible) for other languages to call Lisp
functions that accept keywords. You can either say I'm a bad boy for
not fully using Parrot features and require me to design and
implement ... according to some global specification, forcing me to
solve the performance vs. compliance vs. interoperability tradeoff in
each sub, or allow me to do my own thing internally and accept the need
for glue around the edges (which in turn requires compliance with
another specification).
Well, my main question from that is what it is about Parrot named
parameters that don't work for Kea-CL. (It may be something we can fix.)
But, what I expect from Kea-CL with a unique parameter-passing style is
that your libraries clearly document how to call the subroutines. That's
all. If people find libraries written in your language too obtuse to
bother with, then they simply won't use them.
There are an awful lot of musts in the draft, where there should be
only free will.
Another example is object system metamodel compatibility. I am not
an expert on metamodels, but all the ones I *think* I know make it very
hard for me to imagine inheritance across language boundaries without
some very careful design and coding on the part of language implementors
on both sides of the boundary. (Who will no doubt be grateful for some
global specification to help them in that work. ;-)
The interoperability infrastructure is the vtable functions. You can
have absolutely any metamodel you want, just provide a minimal set of
functionality so Parrot can instantiate objects from your class, invoke
methods, and get and set attribute values.
Inheritance across language boundaries works by proxying and delegation.
It's true that a class in one language won't know how to, for example,
look up a method in a parent class from another language. So, it can't
poke directly into the parent and do the lookup, but it can ask the
parent to do the lookup. Poking directly into the parent breaks
encapsulation anyway, generally a bad idea.
Do you really think that Parrot can subsume all object system metamodels
well enough to provide all the infrastructure? Just the CLOS and Perl 6
MOPs are each complicated enough on their own; I'm tempted to advocate
$n^2$ metamodel interfaces in order to break the problem down into
manageable chunks. (And, not incidentally, push the problems onto the
people who understand them.)
If you mean Do you think Parrot can build an enormous and complex
interoperability infrastructure that handles all possible language
semantics now and in the future?, the answer is absolutely not, and
let's avoid that like the plague. The point is to keep it as barebones
as possible, and leave each language to implement whatever custom
behavior they need behind the vtable function interface.
+{{ It's not possible to define a sub that can't be called externally
--allison }}
Not now, true. Except that we currently support .sub foo :anon ...
for compilation-unit scoping. Are you saying you object to language
scoping of subs?
Sure, but if that scoped sub was returned as a subroutine object to
another language, it could be invoked as a subroutine by that language.
+{{ Exporting is very much a Perl idea, not much applicability for exporting
+outside of Perl. --allison}}
Eh? I think we are having another terminology issue. By export I
meant make public. Perl is not the only language to use this term;
just off the top of my head I can think of CL and Erlang.
Ah, by export I mean inject into the caller's namespace (Perl
terminology). Any subroutines stored in a namespace are already public,
so I'm not sure what you meant.
I *could* represent CL strings explicitly as vectors of characters
instead of using the String type. But that would mean that I couldn't
use the wealth of Parrot string ops, and would be inviting more
interoperability problems to boot. Ditto
[perl #47992] [RFE] 'parrot foo' automatically finds and invokes foo.pbc
As mentioned in RT #49168, I'm in favor of a --language flag, that selects the default PBC/PIR file to run, and passes all other arguments to the ':main' sub in that file. It can also select default paths based on the options set the the configuration file for that language. Then, using the $0 argument to 'main' in src/main.c, we can treat the name of the executable as setting the --language option, so, if 'perl6' is an alias to 'parrot', then: $ perl6 myfile.pl is the same as: $ parrot --language=perl6 myfile.pl I'm opposed to the command-line pattern of: $ parrot perl6 myfile.pl We don't want people to have to type 'parrot' every time they run a script with a language implemented on Parrot, so there's no value in providing a shortcut that only does half the job. It could also lead to some nasty conflicts, if someone happens to have a source file with the same name as one of their installed languages. Allison
Re: [perl #58236] [TODO][PDD19] make decision on open issue on .return directive in pdd19
Klaas-Jan Stol (via RT) wrote: The parentheses surrounding the arguments are mandatory. Besides making sequence break more conspicuous, this is necessary to distinguish this syntax from other uses of the C.return directive that will be probably deprecated. The open issue of the 'probably deprecation' should be decided on; what return directive is meant here that supposedly would be deprecated? Will it? (any need?) Yes, it will be deprecated, or at least renamed. The C.return directive without parentheses is an old convention for passing a single return result, and must always be sandwiched between C.begin_return and C.end_return. And, there's another C.return without parentheses that performs a tail-call, invoking a sub or method reusing the same return continuation. This should also be renamed. The only directive that should be named C.return is the one that returns a value or values (i.e. it's syntactic sugar for a whole collection of low-level directives/opcodes). Allison
