Re: Just a thought
Vladimir Lipsky <[EMAIL PROTECTED]> wrote: > Parrot_loadbc(interpreter, pf); > Did you catch the difference between the 2nd actual parameter and > the function name? Maybe it's worth renaming? E.g. Parrot_loadpf() Sounds reasonable. Or Parrot_set_pf(). > 0x4C56 leo
Re: feature request: line numbers in errors?
Michal Wallace <[EMAIL PROTECTED]> wrote: > Is it possible to print out the line number > of the bad instruction when parrot encounters > an error and fails? Yep. I'll have a look at it. > I don't suppose there's one magic error routine > that controls all the error messages, and someone > could just add a line or two to handle this? :) Almost all runtime errors are going through internal_exception(). I'll add these two lines :) > Michal J Wallace leo
Re: python exceptions broken
Michal Wallace <[EMAIL PROTECTED]> wrote: > Looking more at exceptions here... I > used to be able to put arbitrary > stuff in the _message slot of a > ParrotException... Now we can only use > strings. Is that permanent? Depends on what exceptions finally are. But the standard entries like "_message" are not supposed to get anything different then a string for that. > PythonException will need to be able > to hold an arbitrary python object. Attach it as a property (s. setprop/getprop). > Michal J Wallace leo
Re: [perl #24584] [PATCH] 'in macro' vs. 'in file' in some imclexer.c error messages
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote: > I think the 'imclexer.c' is generated from 'imcc.l' during maintainance. So > I made the patch in both files. Just for imcc.l is enough. Thanks, applied. leo
Re: More object stuff
Michal Wallace <[EMAIL PROTECTED]> wrote:
> What is the _return_cc attribute on an
> exception? Can I use it to resume the
> code as if the exception never happened?
When an exception is resumable, you can return by invoking this return
continuation. But details (i.e. is C<_return_cc> put into P1
automatically) will probably change. t/pmc/exception.t has some
examples.
> Do I have to fill it in manually? Or
> could it be automatic?
If the exception originated in the opcode-loop, it can be resumable -
but not all are changed yet. Have a look at C in
*.ops. For these, setting the return continuation is done automatically.
> I'm picturing exceptions as continuations
> with an arbitrary message attached... Right
> now that message is a string, but eventually
> it could be any PMC... Is that about right?
There will be some default information and user fields.
> So, if I throw a WarningException, could I
> just say "ignore it... go to the next line"?
You can always resume your own exceptions that you C yourself.
> As for the message, I'm trying to think of
> a good reason to standardize that attached
> PMC. For example, if I try to open a file
> in python and it fails, I get an exception
> of class IOError... But if I call a perl
> routine that throws the perl equivalent...
> What should happen? Should I just catch
> PerlException instead?
I think, that we need classified ParrotExceptions. If HLLs POV differ
they can subclass these to their own needs.
> Each HLL is going to want its own class
> hierarchy for exceptions... But it might
> be nice to have a predefined hierarchy that
> parrot uses internally.
Yep.
> I know perl uses a return value instead of
> throwing an exception ("open or die", right?)..
Where die() is the exception.
> So would parrot's internal file-opener just
> throw a ParrotFileException? So perl's
> open() command catches it and returns 0,
> while python's open() command catches it
> and throws a new IOError?
Very probably yes.
> Michal J Wallace
leo
Re: [RFC] IMCC pending changes request for comments
On Tuesday, December 2, 2003, at 11:49 , Melvin Smith wrote: At 07:59 PM 12/2/2003 -0800, Steve Fink wrote: Do you really want to generate the extra unused code at the end of all the subroutines? I don't think you want to autodetect whether the code is guaranteed to return. Good point. Its easy to detect returns if the code uses high level IMC directives, but in cases where it is all low-level PASM, it could get a little troublesome. It would also add a few dead instructions here and there. Nix that idea. Maybe just pad the end of the compilation unit with the opcode equivalent of PMCNULL, to fire an exception rather than having undefined behavior? — Gordon Henriksen [EMAIL PROTECTED]
Re: get_pmc_keyed() in PerlString?
Sterling Hughes <[EMAIL PROTECTED]> wrote: > Should PerlString support a get_pmc_keyed() method (according to Perl > 5/6 semantics), or is this a point where its about time to start > implementing our own PMCs? get_pmc_keyed() seems a bit heavy to handle single chars in a PerlString (Each char would create a separate PMC with a PerlString attached to it). Can you use native STRINGs for that? > -Sterling leo
Re: get_pmc_keyed() in PerlString?
Am 04.12.2003 um 15:17 schrieb Leopold Toetsch:
Sterling Hughes <[EMAIL PROTECTED]> wrote:
Should PerlString support a get_pmc_keyed() method (according to Perl
5/6 semantics), or is this a point where its about time to start
implementing our own PMCs?
get_pmc_keyed() seems a bit heavy to handle single chars in a
PerlString (Each char would create a separate PMC with a PerlString
attached to it).
Can you use native STRINGs for that?
sure, if we only knew the type of the variable we're accessing:
function dump0($a)
{
echo printf("%s\n",$a[0]);
}
dump0("hallo"); // called with a string
dump0(array("thies", "arntzen")); // with an array
would produce (in php):
h// string offset
thies// array index
how do you think we should generate "good" imc code for that?
re,
thies
Re: get_pmc_keyed() in PerlString?
Thies C . Arntzen <[EMAIL PROTECTED]> wrote:
> Am 04.12.2003 um 15:17 schrieb Leopold Toetsch:
>> Can you use native STRINGs for that?
> sure, if we only knew the type of the variable we're accessing:
> function dump0($a)
> {
> echo printf("%s\n",$a[0]);
> }
> dump0("hallo"); // called with a string
> dump0(array("thies", "arntzen")); // with an array
> would produce (in php):
> h// string offset
> thies// array index
> how do you think we should generate "good" imc code for that?
dump0() is obviously non-prototyped (or takes PMCs) which doesn't differ
here. So I would do:
.sub _subscripted
.param pmc p
.param int idx
does I0, p, "array"
if I0, handle_array
.include "pmctypes.pasm"
typeof I0, p
eq I0, .PerlString, handle_string
# unhandled type
exit 1
.local pmc elem
handle_array:
elem = p[idx];
...
handle_string:
$S0 = p
$S1 = $S0[idx] # or substr $S1, p, idx, 1
elem = new .PerlString
elem = $S1
...
absolutely untested.
But it seems, that subscripting of string PMCs yields another PMC in the
general case, so its really probably simpler to use your proposed
change. You can easily experiment with custom PMCs, if you use
dynclasses/*.
> re,
> thies
leo
Re: More object stuff
On Dec 3, 2003, at 12:03 PM, Dan Sugalski wrote: At 12:17 PM +0100 12/3/03, Leopold Toetsch wrote: Dan Sugalski <[EMAIL PROTECTED]> wrote: > *) Exceptions we're happy with Create an Exception class hierarchy? I'm not 100% sure I want to go with a real OO style of exceptions, but that might just be the neo-luddite in me. I'm of the opinion that it's a conceptual mistake to model exceptions as objects. My main concrete argument is that it's an abuse of inheritance--you need a hierarchy of exception reasons, but using inheritance just to get a hierarchy is silly. (That is, it doesn't make sense to subclass if you are not changing behavior in some way.) In addition, I think it's overly restrictive. Fundamentally, I think raising an exception requires two things: (1) some indication of "reason" for the exception (used by the exception infrastructure to select the correct handler), and (2) a way for the originator of the exception to pass some arbitrary information to the handler (this information being opaque to the exception infrastructure). In C terms, that would mean that the signature is conceptually like: raise_exception(Reason reason, void* info); which in Parrot terms would probably shake down to: raise_exception(Reason reason, PMC* info); The "Reason" data type could either be a structured string, such as "parrot.io.staleFileHandle", or some sort of array of strings--just enough to indicate a hierarchy to be used for selecting a handler. The key point here is that the "reason" parameter is what is needed by the exception infrastructure to choose the correct handler (and to decide what to do if no handler is found), and "info" just has to be of a form agreed upon by the "thrower" and the "catcher". This sort of approach would work with languages such as Java which expect exceptions to be objects--in this case, the Java exception object would be passed as the "info", and the "reason" would be derived from the type of that object. For simpler languages (and possibly even for Perl6), "info" could just be a hash--no real need for a specialized type of object. I think the core of my thinking here is that exceptions don't really have behavior--at most they are a bag of data (which is what hashes are usually good for), and really they are a process for jumping the flow of execution, and sending along a bag of data to indicate why it just happened. That was a bit long-winded, but basically I'm saying that I'd like to see the pasm for raising an exception take the form: raise Px, .parrot.io.StaleFileHandle where Px may actually be null. No matter what approach we take, we're going to have issues throwing exceptions across language boundaries (ie, Perl exception handled by Python code), since different languages aren't going to agree on how to classify exceptions--and having exceptions be HLL objects seems to make this worse. Actually, in a sense this _might_ not be a problem: If we supply a decent reason hierarchy, then using our supplied parrot.* exception "reasons" would allow an exception thrown in one language to be handled in another; if a language-specific reason is used (e.g., perl.blah), then it's probably going to only end up being handled by code in the same language. (And that seems fine--even in Java if I create my own Exception subclass, then code I haven't written isn't expected to be catching that type of exception.) But having some standard types will make it possible to cross language boundaries meaningfully. Just some thoughts. One other thing: Long-term, it would be good to avoid having an exception handler stack which we push and pop as we do now, and instead use a variant of the zero-overhead approach used by C++ (and probably Java), wherein try-catch blocks incur zero execution overhead--CPU time is only consumed when an exception is actually thrown, and not when a "try" block is entered or exited. JEff
Re: [RFC] IMCC pending changes request for comments
On Dec 2, 2003, at 8:49 PM, Melvin Smith wrote: At 07:59 PM 12/2/2003 -0800, Steve Fink wrote: On Dec-02, Melvin Smith wrote: Do you really want to generate the extra unused code at the end of all the subroutines? I don't think you want to autodetect whether the code is guaranteed to return. Good point. Its easy to detect returns if the code uses high level IMC directives, but in cases where it is all low-level PASM, it could get a little troublesome. It would also add a few dead instructions here and there. Nix that idea. You could take the approach of putting in the return code unless you can tell for certain that it couldn't be reached, the idea being that this would lead to some unreachable code at first but as the compiler (or optimizer) becomes more sophisticated in its flow analysis this would gradually improve over time. JEff
[COMMIT] A few imcc tweaks
As discussed in the last IMCC RFC, I've committed a few of the changes. IMCC will now generate an error if the register type is unknown rather than just assign it a PMC register. P reg types are pmc, object, or a valid classname. Use pmc or object for "generic" P register to defer type checking. I think a few compilers will now be broken but the patches should be very simple to fix them. Also allow sub names without _ prepended, and allow @ to start labels. Tweak the fixup code a bit to use flags rather than looking for _ in symbol name. Added parser stubs for .global to grammar. -Melvin
