Re: [perl #17931] [PATCH] DOD/GC related
Jason Gloudon wrote: On Mon, Oct 14, 2002 at 08:31:16PM +, Leopold Toetsch wrote: headers.c: - set PMCs and Buffers initially to live. This helps somwhat, that initially created objects are not killed immediately by a DOD run e.g. in midst of string_make But what happens where there is more than one DOD run ? Then we have the same problem - of course. As I said, my change is a slight improvement, but not a solution. The problem sounds like that the collector is not looking in all the appropriate places for these PMCs and Buffers. I have not looked in a while but has anyone added the necessary code to examine CPU registers for PMC and Buffer pointers ? Only the CPU stack is checked, no CPU registers. leo
Re: Indeterminate math
Sounds like a good place for fail, as described in Exegesis 4, so that it could be taken as undef or an exception depending on pragmata. This came up at YAPC::Europe. Someone [1] wanted to know if 1/0 would produce a divide by zero error in Perl 6, or if it would return a value representing an indeterminate result (undef?) It would make more sense for Perl, upon being given a simple bit of impossible math, to return undef (like other functions do on failure) than to generate an error. The error seems a throwback to earlier days of hardwired calculators. If nothing else it would make guarding against indeterminate math easier. Rather than the user having to trap an error, or do possibly complicated work to see if any of the denominators might be zero, you can just see if the result is undef. [1] I apologize for forgetting who. [2] Discussion of divide by zero and why it's not infinity [3] http://mathforum.org/dr.math/faq/faq.divideby0.html [3] I was always taught it's infinity. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One Don't worry, baby, my wrath can be pretty groovy. http://www.goats.com/archive/980804.html -- Adam Lopresto ([EMAIL PROTECTED]) http://cec.wustl.edu/~adam/ Who are you and what have you done with reality? --Jamin Gray
Re: Hi - Regarding JVM - parrot compatibility
--- Karthik Kumar [EMAIL PROTECTED] wrote: Hi Leon, --- Leon Brocard [EMAIL PROTECTED] wrote: Karthik Kumar sent the following bits through the ether: Can you please let me know if any work going on relative to this or any src code tree that you would me to look into. Hiya. I've have worked on the past on trying to get JVM bytecodes working inside Parrot, but mostly that hasn't got very far due to lack of free time or motivation. It's very easy to get simple stuff working due to the low number of JVM bytecodes. You can emulate iinc quite easily ;-) However, it's getting the classes and object system to work which is a little harder. IINC simulation is quite simple as you had mentioned. The simulation of the following: new anew getfield putfield getstatic putstatic invokevirtual invokespecial invokeinterface invokeinterface all deal with objects and they are not pretty straight-forward as you had mentioned. This may help: http://search.cpan.org/dist/Java-JVM-Classfile/ Cool. I saw that. That one seems cool. Good job !! In the past couple of weeks I've been wondering whether a hybrid scheme a la Inline::Java where we dispatch stuff to a real JVM may be a faster approach to get running. Why, what exactly did you have in mind? Well. What I had in mind is something like this - You write a java .class library , say some arithmetic. Then you write another language compatible with Parrot JVM , may be Perl6. Then from ther perl6 code you call that arithmetic lib. function. The parrotVM is smart enough to convert .class files to parrotVM compatible code and start using the same. ( arithmetic lib. is just a simple example i could think of ) . This is my brief idea. But as Ramesh was mentioning parrotVM is still under dev. So my q is - how far is object support possible in parrotVM. Does that need to be simulated or parrotVM is designed to be based on ooops. afaik at byte level the stuff is supposed to be freely and completely interchangeable. Let's say you got things from Perl-Parrot. it should be delectably simple to go from Parrot-Perl. so this wouldn't be a problem with Java bytecode. Perhaps you may have to specify to the compiler to compile down to Parrot target code. Or would it be simpler to just convert Java binary to Parrot binary cheers, Ramesh Any pointers on the same. Cheers. Karthik. __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com
Crazy idea of Linux running in Parrot
--- Bala Karthik [EMAIL PROTECTED] wrote: Hi Ramesh, That sounds exciting. Just wanted to clarify on your suggestion. Are you saying that the parrot compiler should be able to decipher the asm generated by any C code. Well... EIther we just compile C down to Parrot. Or work at an asm to parrot translator. The advantages I think are greater in the first, as we can build really tight code. But yes! you'll have to recompile all the programs. Yes, I am dreaming of porting Linux to run in Parrot. No, functional purpose. Just one of those dreams. Or hey does that mean we can use Parrot as a VM, sorta like VMWare. Branch two, would mean we translate at byte level from assembly to parrot. Would this be easier? I don't know. But you could just translate without needing to recompile all the stuff. Any idea on how to go around this ? I'm a newbie to this and i'm very much interested in contributing to the community :) . Your help would be highly appreciated. First way I think would be to write a back end to gcc. But that's tough. the way parrot is constantly changing. But another way would be to write a library with which you compile. So that the resultant code is parrot code. I really don't know whether this is feasible. Err. really pinging the community on this. But my dream is to run Linux on Parrot. Thanks, Bala. Ramesh Ananthakrishnan [EMAIL PROTECTED] wrote:well, that part exists. a proof of concept parrot to jvm translator stuff has already been done. As for full implementation well parrot's still er... changing. It's still being developed and so keeps changing pretty fast. I wouldn't go to translation at this time as it may be pretty hard to hit the forever changing target that's parrot now. I'm working on poring C to parrot. So that you can compile C programs into parrot assembly and have them work right off the bat. Once we get C across, it would b e pretty easy to port other languages and libraries to Parrot like Perl5.6, Ruby all of which have been built using standard C tools. (or so I hope ;-)). Anyway if you are intrested in it send me a line. Hey Hey wait a minute. There's this flashing big light bulb. Big idea coming up! O.K. This may be exceedingly stupid, but why not an assembly back to Parrot compiler. Howzaat. We wouldn't actually have to port C just the assembly stuff and voila' it just works. cheers, Ramesh Hi All, I am new to this parrot virtual machine aimed as a common denominator for perl and python. I had been going thru this list for some time. I would like to contribute to the parrot community. My interest here is - I am intereseted in writing a .class file -- .parrot bytecode and viceversa. In other words planning to bring in the jvm compatibility suite to parrot. Can you please let me know if any work going on relative to this or any src code tree that you would me to look into. Thanks in advance for letting me know this info. Good luck. Cheers. Karthik. __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com - Do you Yahoo!? Faith Hill - Exclusive Performances, Videos, more faith.yahoo.com __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com
Re: Indeterminate math
[EMAIL PROTECTED] wrote: From: Michael G Schwern [EMAIL PROTECTED] This came up at YAPC::Europe. Someone [1] wanted to know if 1/0 would produce a divide by zero error in Perl 6, or if it would return a value representing an indeterminate result (undef?) It would make more sense for Perl, upon being given a simple bit of impossible math, to return undef (like other functions do on failure) than to generate an error. The error seems a throwback to earlier days of hardwired calculators. The problem with returning undef is that undef numifies to zero. Why can't it return undef but +Inf, or undef but NaN for 0/0, which would then cause a warning/error/nothing, as required by pragma, following the 0 but true that has been discussed previously. Normal numification would presumably propogate the undef but +Inf value. R. -- Richard Nuttall Invisible Networks DDI: 01954 206361 Tel: 01954 22 Mob: 07798 528923 Fax: 01954 206360 Web: www.invisible.uk.net
Re: Lukasiewiczian logic (was Indeterminate math)
On Mon, Oct 14, 2002 at 06:27:48PM -0700, David Whipp wrote: it looks like Lukasiewiczian NULL is just the nifty NULL that SQL has, and the nifty ways that it affects logical and aggregate operations. Actually, something I wouldn't mind seeing in other languages -- I can't say if perl is one of those, but if it can be provided by expansion, that would be neato. Looks like the X value of the 4 (or 9) state logics that ASIC designers use. I suspect that it would be possible to implement this with properties and overloading. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2001-11/msg00124.html -- Paul Johnson - [EMAIL PROTECTED] http://www.pjcj.net
Re: [perl #17811] [PATCH] create pmcs with pmc initializer
On Mon, 14 Oct 2002, Leon Brocard wrote: Jonathan Sillito sent the following bits through the ether: I have been playing with classes and instances for parrot. In the process I found I needed a way to pass more information when creating new pmcs. So the attached patch adds the op: new (out PMC, in INT, in PMC) Oh, I see nobody has replied to this yet. Well, in the past this feature existed in Parrot, but then was taken out again, presumably because there was a better way to do it. However, I'm not sure what that way may be. Can anyone shed some light upon this? I have submitted a few patches that enables this feature though it has been forgotten for some reason :-). I believe it is needed because some pmcs ( not yet applied ) do need to know a few things on init par example matrices. My patches was 16933 and 16934 /Josef
RE: your mail
I don't think the Cfor construct would be dealing with real superpositions at the top level. I was just thinking about stealing the | and notation. so, |, , are special meta-comma operators that create a (meta:-) list with additional relation between entries. this (meta)list expands differently in for(...), when(...) , bits(...), any(...), all(...) . and probably in no special context it implies enclosing any(...) or all(...). so now we will have 4 comma operators : ; | , | , ; ? arcadi.
RE: perl6 operator precedence table
And I really do like | for any(). And I can see using it like this:
cases ^|= newcases;
to mean
for cases | newcases - $x is rw | $y {
$x = any($x, $y);
}
but then probably we should also have
cases = cases ^| newcases; is same as ( cases ^|= newcases; )
cases = cases ^, newcases; is same as ( cases ^,= newcases; )
the second creates a list of two-element arrays which may be useful.
Another question is whether using a superposition to represent parallel
streams in for is doing the any concept too much violence. Really,
it's more of a hyper-any, at least on the left:
for cases ^| newcases - $x is rw | $y {...}
But note that ^ automatically gives us the shorter of the two lists.
in analogy, may be here
for cases ^, newcases - $x is rw , $y {...}
will do the job . though not clear what happens when arrays have different
length. which proves that | is just special comma.
print arcadi =~ s/Larry/arcadi/ ;
Maybe...
Just thinking... :-)
Larry
arcadi
Re: Indeterminate math
Mathematically, 1/0 is not +Infinity. It's undefined/indeterminate in the set of rational numbers. The IEEE may say otherwise. Mathematically, 1/0 is whatever you define it to be. And it is perfectly correct to assume that operations happen in the extended real line, and thus that 1/0 is exactly +Inf. And probably more convenient. The only remote problem is that the extended real line isn't a proper field. But, who cares... -angel
Re: Indeterminate math
In a message dated Tue, 15 Oct 2002, Angel Faus writes: Mathematically, 1/0 is not +Infinity. It's undefined/indeterminate in the set of rational numbers. The IEEE may say otherwise. Mathematically, 1/0 is whatever you define it to be. Well, sure. That's as axiomatic as saying, mathematically, the number one is whatever you define it to be. But a mathematical system that has a definition which is inconsistent with the rest of the system is a flawed one. If you let 1/0 be *anything*, then ordinary algebraic logic falls apart. Those silly proofs where it is proven that 1 = 2, 1 + 1 = 1, etc., all depend on division by zero being possible (regardless of what its value is). You have to keep division by zero illegal to avoid these absurd results. Hence, to my mind at least, exception-throwing or NaN is a better solution than infinity. But will it really matter one way or the other? Probably not, so we should stop quibbling. Perhaps if someone could demonstrate a real-world need for either NaN or infinity in this case, or else a case for why exception-throwing should *not* go away, we'd be able to bring the discussion somewhere more fruitful. For my part: division by zero is so often a programmer error, and so rarely a useful thing to do, that it seems to me that exception-throwing should remain the behavior in Perl 6. Trey
Re: Indeterminate math
Mathematically, 1/0 is whatever you define it to be. Well, sure. That's as axiomatic as saying, mathematically, the number one is whatever you define it to be. But a mathematical system that has a definition which is inconsistent with the rest of the system is a flawed one. If you let 1/0 be *anything*, then ordinary algebraic logic falls apart. Those silly proofs where it is proven that 1 = 2, 1 + 1 = 1, etc., all depend on division by zero being possible (regardless of what its value is). You have to keep division by zero illegal to avoid these absurd results. Hence, to my mind at least, exception-throwing or NaN is a better solution than infinity. My point was that there is no stone-carved mandate of the ancient mathematicians saying whether the value of 1 / 0 is defined or not. I did not intend to say that you could assign it any value. It is general practice among mathematicians to say that is undefined, but it is also general practice among other respectable ocupations to say it is something like infinite, and both approaches can be formalized. But of course, as you said, this is largelly irrelevant to the actual discussion. My personal opinion is that a language that lets you add apples + oranges and get 0, shouldn't be too picky about 1 / 0 not being a proper number. -angel
Re: Object Instantiation
On Fri, 11 Oct 2002 14:05:30 -0700, Michael Lazzaro wrote: Maybe postfix ! on a class name means to autoinstantiate an object of the named class only if/when first accessed: our FancyCache $cache; # declare, but leave undef our FancyCache! $cache; # undef, but new() it if/when we need it our $cache returns FancyCache!; # the same (That's just a joke. Um, I think. Hmm...) Apart from the auto bit of autoinstantiate, that's almost what it means in Eiffel, except there it's a prefix !! operator. Actually, you can specify a subclass between the two shrieks, but perl lets you do that by sticking Class:: on the method name, which means we'd only need one shriek: # ! is the new .= our FancyCache $cache; # declare but leave undef our FancyCache $cache ! new; # create new instance our FancyCache $cache ! ReallyFancyCache::new; # create subclass instance Eiffel does let you omit the name of the constructor if there is a single argumentless constructor, but Eiffel constructors are all marked as such, which (at least so far) Perl6 constructors aren't. -- Peter Haworth [EMAIL PROTECTED] The Hotmail migration is becoming the IT equivalent of painting-the-Forth- bridge, evidently. Once you've think you've finished migrating one end, more FreeBSD boxes reappear at the other. So you have to start all over again. -- http://www.theregister.co.uk/content/28/23348.html
Re: Indeterminate math
On Tuesday, October 15, 2002, at 07:05 AM, Michael G Schwern wrote: This came up at YAPC::Europe. Someone [1] wanted to know if 1/0 would produce a divide by zero error in Perl 6, or if it would return a value representing an indeterminate result (undef?) It would make more sense for Perl, upon being given a simple bit of impossible math, to return undef (like other functions do on failure) than to generate an error. The error seems a throwback to earlier days of hardwired calculators. Well, if you're an exceptions guy like me, you'd *much* rather have it produce an error than a zero, which I assume undef would still evaluate to. NaN is another option, following some standard or other. [2] Discussion of divide by zero and why it's not infinity [3] http://mathforum.org/dr.math/faq/faq.divideby0.html [3] I was always taught it's infinity. Positive or negative infinity? (it's a trap!) -Ken
Prototype-Based Inheritance (was Re: Indeterminate math)
On Monday, October 14, 2002, at 07:54 PM, Mark J. Reed wrote:
Heh, indeed. :) But seriously, you could do worse. JavaScript
receives
a lot of (IMHO) undeserved criticism. The name is a blatant marketing
No, I've had to use it off-and-on for the past year... it deserves it.
:-) But enough of that.
I agree, prototype based inheritance is really useful sometimes.
(Those of you not subjected to JS may be more familiar with
Class::Classless, a quite nice perl5 implementation.)
I'd definitely like to see builtin support for instance based
inheritance. I've found many, many uses for Class::Classless, and have
made halfbreed variations of it for several special-case situations.
IMO the best situation would be to have both worlds collide; not
strictly class-based, not strictly proto-based, but a mix-and-match of
each in accordance to the particular problem you're trying to solve.
An interesting way to do this could simply be to allow object
instances, as well as normal classes, in the inheritance tree; you
could then mix a prototype-based object with, for example, several
class-based mixin behaviors, etc.
Something like:
my $obj = Something.new;# (1) obj based on a class
class MyClass is $obj {...} # (2) a class based on an obj!
my $obj2 = MyClass.new; # (3) obj based on a class based on
an obj
my $obj3 isa $obj; # (4) an obj based on another obj
my $obj4 isa $obj isa MyClass; # (5) obj + mixin (but what syntax???)
Note that (2) would have interesting implications if you changed $obj
runtime, but would be very uncommon. (4,5) could be quite common, tho.
And (4,5) need to use a word other than 'is', which means that
currently none of these syntaxes look anything alike. :-P
Mixing OO frameworks is quite useful in some real-world situations.
Sometimes it's more efficient to change your OO implementation than to
try to translate your problem to fit the one you're given.
MikeL
A concept for Exceptions
A brainstorm for your enjoyment, perusal, and general discussion... SUMMARY A proposal for an extension to the usual exception handling concept. The concept detailed here provides a mechanism for handling exceptions in one of three ways: changing the values being evaluated, setting the result of the entire expression, or throwing an exception as usual. JUSTIFICATION Why do I want to augment how exceptions are handled? Is everything about exceptions already invented? The answer is that I hate how Java handles exceptions. In Java it seems like every time you want to do something, you have to surround it with exception handlers. I find that in Java my code becomes buried in exceptions. Yes, the current every-block-is-a-try-block greatly helps this problem, but there's still the looming prospect of having to write mountains of CATCH blocks to handle every problem. What I propose here is a system that provides a technique for actually fixing the problems on the fly, instead of having to hand code error handling every step of the way. Furthermore, the techniques described here provide a way to make certain behaviors modifiable, so that everybody gets their own favorite flavor of ice cream, so to speak. This concept was inspired by the variety of preferences about how Perl6 should handle 1/0. Please note that this is not a proposal for *changing* how exceptions are handled, it's merely an *addition* to the standard techniques. EXCEPTIONCREATOR CLASS Each block gets a reference to an ExceptionCreator object. By default, blocks inherit their parent's reference, so we won't have to be moving and creating references a lot. When the interpretor gets to an error, it calls the ExceptionCreator's standard method for handling that specific type of exception: divByZero(), stringConcatenationUsingUndef(), whatever. The method for that type of exception calls the constructor of an Exception class that is devoted to handling just that type of exception. The Exception's constructor method, described in more detail on the next section, determines how the exception is handled. To change how certain exceptions behave, a block simply changes the methods of the existing ExceptionCreator to point to other subroutines. This approach allows for an ala carte style of exception configuration. Blocks can (through a module that makes this sort of thing easy), clone the ExceptionCreator object, then change just the methods that are desired. A reference to that new object is passed down the line to child blocks. You can also set the default ExceptionCreator reference, i.e. the ExceptionCreator used by default by all blocks in the entire program. By doing so, you can set how certain exceptions are handled by modules that you use but didn't write. For example, suppose I want all string concatenations using undef to be fatal (and I do). I simply override the default ExceptionCreator's concatUndef() method to something more fatal. The following are some of the standard exceptions that the interpretor might throw. I'm sure there a more. These are just the ones that come to mind. - divide by zero - numeric operation on non-numeric value - string concatenation using undef - use of tainted data in protected operation - unsuccesful attempt to open file Modules that provide alternate exception handlers should supply static methods for making the change to a given block. For example, to have div by zero evaluate to Inf instead of a fatal exception, you could simply add this code to your block: use Math::Inf::Exception; and voila, the import routine sets your block's ExceptionCreator for handling div by zero errors. EXCEPTION CLASS Every type of standard exception has its own class. The static constructor method, new, accepts one argument and returns one of three possible values. The input is a reference to the object that caused the exception. This is an optional argument in case no specific object threw the exception. An example of an object that threw an exception would the undef object used in a string concatenation. The constructor returns one of three values: an exception object, the DO_OVER constant, or the EXPRESSION constant. If an exception object is returned, that means that the interpretor should immediately exit the block, throwing the exception to that block's CATCH block, or its parent's CATCH block, and so on outward until somebody catches it. You know the routine. DO_OVER means to reevaluate the expression because the reference to the offending variable has been set to something else. For example, the undef might have been changed to an empty string. The interpretor will only call each type of exception once for each type of object. If the exception constructor just sets the value to another undef, the interpretor will make a nasty gesture are the handler, so enough of you, and throw its own UnhandledException exception. It must be noted
Re: Prototype-Based Inheritance (was Re: Indeterminate math)
Would it make sense for the syntax to be more like
my $obj3 = $obj.new;
Of course, that would kill my .= new idea for instantiation (since it would
call an instance-based new instead of class-based), but I'm getting less fond
of that syntax anyway (though I think .= should definitely be supported in the
language, and $a .= foo; should DTRT, ie, $a = $a.foo).
On Monday, October 14, 2002, at 07:54 PM, Mark J. Reed wrote:
Heh, indeed. :) But seriously, you could do worse. JavaScript
receives
a lot of (IMHO) undeserved criticism. The name is a blatant marketing
No, I've had to use it off-and-on for the past year... it deserves it.
:-) But enough of that.
I agree, prototype based inheritance is really useful sometimes.
(Those of you not subjected to JS may be more familiar with
Class::Classless, a quite nice perl5 implementation.)
I'd definitely like to see builtin support for instance based
inheritance. I've found many, many uses for Class::Classless, and have
made halfbreed variations of it for several special-case situations.
IMO the best situation would be to have both worlds collide; not
strictly class-based, not strictly proto-based, but a mix-and-match of
each in accordance to the particular problem you're trying to solve.
An interesting way to do this could simply be to allow object
instances, as well as normal classes, in the inheritance tree; you
could then mix a prototype-based object with, for example, several
class-based mixin behaviors, etc.
Something like:
my $obj = Something.new;# (1) obj based on a class
class MyClass is $obj {...} # (2) a class based on an obj!
my $obj2 = MyClass.new; # (3) obj based on a class based on
an obj
my $obj3 isa $obj; # (4) an obj based on another obj
my $obj4 isa $obj isa MyClass; # (5) obj + mixin (but what syntax???)
Note that (2) would have interesting implications if you changed $obj
runtime, but would be very uncommon. (4,5) could be quite common, tho.
And (4,5) need to use a word other than 'is', which means that
currently none of these syntaxes look anything alike. :-P
Mixing OO frameworks is quite useful in some real-world situations.
Sometimes it's more efficient to change your OO implementation than to
try to translate your problem to fit the one you're given.
MikeL
--
Adam Lopresto ([EMAIL PROTECTED])
http://cec.wustl.edu/~adam/
All I want is a warm bed, a kind word, and unlimited power.
Re: Indeterminate math
On Wed, Oct 16, 2002 at 02:54:37AM +1000, Ken Williams wrote: On Tuesday, October 15, 2002, at 07:05 AM, Michael G Schwern wrote: This came up at YAPC::Europe. Someone [1] wanted to know if 1/0 would produce a divide by zero error in Perl 6, or if it would return a value representing an indeterminate result (undef?) It would make more sense for Perl, upon being given a simple bit of impossible math, to return undef (like other functions do on failure) than to generate an error. The error seems a throwback to earlier days of hardwired calculators. Well, if you're an exceptions guy like me, you'd *much* rather have it produce an error than a zero, which I assume undef would still evaluate to. People have used the terms error and exception interchangably in this disucssion. To me, an error is something that stops program execution while an exception may or may not stop execution depending on what the user decides to do about exceptions. 1/0 could throw an exception, yet continue execution. Somewhere I expect we should be able to define a policy for what to do in these situations. use Policy DivideByZero = Nan; use Policy DivideByZero = Inf; use Policy DivideByZero = DivideByZeroException; I'm sure someone else can pick a better syntax than I. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Indeterminate math
On Wednesday, October 16, 2002, at 04:44 AM, Jonathan Scott Duff wrote: People have used the terms error and exception interchangably in this disucssion. To me, an error is something that stops program execution while an exception may or may not stop execution depending on what the user decides to do about exceptions. Agreed. I've meant exception in my comments, in the trappable sense of the term. I don't see much need for a true untrappable error - one man's error is another man's case. 1/0 could throw an exception, yet continue execution. Somewhere I expect we should be able to define a policy for what to do in these situations. use Policy DivideByZero = Nan; use Policy DivideByZero = Inf; use Policy DivideByZero = DivideByZeroException; I'm sure someone else can pick a better syntax than I. I don't think there are going to be many real situations when people would want Inf or Undef (99% of the rare cases where people think they might want it, they're probably wrong ;-), but NaN or Exception could indeed be common needs. -Ken
Re: [perl #17931] [PATCH] DOD/GC related
Leopold Toetsch (via RT) wrote:
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17931]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17931
I send this to the list first, because it's probably not a final
solution and people might have something better.
I did check in a correction for some of the obvious bugs.
Plus:
trace_dump uses now it's own interpreter which IMHO is the rigth thing
to do, so that generating trace output doesn't mess up the state (COW!)
of the interpreter, which is examined.
Tracing now is working almost again, it still fails on very long traces
due to probably trying to print some undefined data.
I changed the output of trace_dump to not print the first argument in
detail, when this is a PMC - of course - it should print no {IN,}OUT
arguments, but for a first test it's much better now.
Debug/trace should not change the observed interpreter in any aspect.
Also included:
- bugfix for sprintf(%%)
- use much less substr in sprintf (no more one for each char)
Tests including Befunge/make are working on my system.
leo
Re: A concept for Exceptions
From: [EMAIL PROTECTED] [EMAIL PROTECTED] Date: Tue, 15 Oct 2002 14:33:28 -0400 I like the idea of this. The finer details, like returning what to do, could be more elegant. But the extensibility idea is golden. To change how certain exceptions behave, a block simply changes the methods of the existing ExceptionCreator to point to other subroutines. This approach allows for an ala carte style of exception configuration. Blocks can (through a module that makes this sort of thing easy), clone the ExceptionCreator object, then change just the methods that are desired. A reference to that new object is passed down the line to child blocks. I think a clone should be implicit (and lazy). Exception handlers should be lexically (or dynamically?) scoped. Dynamically could be useful in that if a module generated some known exception, you could tell it what to do---on it's level. I worry that this could break things too easily, though. I definitely like this idea in that it eliminates a lot of redundancy. Instead of 10 CATCH blocks doing the same thing with different names, you just have one handler that does it all. Exceptions are always something that seemed tedious to me (though I have had some fun with them), and this might possibly relieve that. Let's see if we can come up with a more elegant method than the return constant thing. Luke
Values, Variables, Assignment
I was writing up a quick beginner-level summary on variables assignment yesterday evening, mostly to get my head around the syntax as it currently stands. You can see it at http://cog.cognitivity.com/perl6/var.html if desired. The 3 or 4 parts in red are things that I'm making up -- they either haven't been decided yet, or they were and I can't find the answer. If people would take a look and tell me where it's incorrect or stupid, I'd be grateful. MikeL
Perl 6 summary for week beginning 2002-10-07
Perl 6 summary for week beginning 2002-10-07 This is yet another Perl 6 summary, documenting what has happened over on the perl6-internals (where Parrot, the virtual machine that will run Perl 6 is discussed) and perl6-language (where Perl 6 language design is discussed) mailing lists. Piers is still off on holiday (bungee jumping and motocrossing, no doubt), so I'm still your host this week. A fairly quiet week, so let's start off with the perl6-internals list as usual. The Pumpking is dead, long live the pumpking! I am happy to report that we have a new Parrot pumpking. Jeff Goff has done great work in the past, but taking over is Steve Fink who has been active in Parrot since near the beginning. He's been extremely active this week, participating in almost all of the discussions and accepting patches left, right and center. http://makeashorterlink.com/?X18F23422 Variables have three parts Dan Sugalski decreed that vtables were about to get more complicated. Variables and values used to be simple, but now we need to have three parts for each thing: an optional name, a container and the contents of the container. There wasn't any discussion, but I expect Dan will rejig vtables some more anyway. http://makeashorterlink.com/?T29F12422 Line number metadata Juergen Boemmels explained that the line number information given by the setline opcode was quite verbose in the source and suggested adding line number metadata into Parrot bytecode. He proposed using the DWARF-2 debugging format (as used by the Mono project) so as not to reinvent the wheel. Dan promised some specs for moving this information out of band. This thread quickly got out of hand, with Nicholas Clark noticing that having column number information magically built in full debugging support for Befunge (a two-dimensional language) and Sean O'Rouke wishing to make source position a vector, thus generalising to scripting languages of any dimension. http://makeashorterlink.com/?A2BF52422 New array base Leopold Toetsch continued in his attempt to confuse the summariser with thousands of patches. He had rewritten the base routines from the array PMC as a working engine for list operations. It should be fast and simple, being based on chunks with fast index get and set. He committed this as list.c, and commented that most of the other array-style PMCs will start to use it as a base, and that it may replace the intlist PMC (and other typed array PMCs). http://makeashorterlink.com/?H2CF32422 Parrot_sprintf Continuing last week's sprintf in Parrot mention, Brent Dax committed a huge patch completing the feature set of Parrot_sprintf, including width and precision for ints and strings, and modified many little bits of code to use it. Inspiration then struck him, or rather, vtables did. He's rewritten it to use vtables, and split some of code out of misc.c and into the new spf_render.c and spf_vtable.c, which managed to turn into another huge patch. Looks like there is a portability issue on PPC systems with va_copy however. http://bugs6.perl.org/rt2/Ticket/Display.html?id=17791 http://bugs6.perl.org/rt2/Ticket/Display.html?id=17817 Nuke dem opcodes Simon Glover proposed a patch to get rid of the 2-element ne opcode, which at a first glance should be optimisable at compiler time and hence should not be in Parrot, barring complicated number precision issues. After a little discussion, Nicholas Clark pointed out that maybe we should do as C99 and state that constant folding will be done at compile time and at the precision of the compiling Parrot. Some of the opcodes where nuked, but it's important to keep some opcodes just in case of overloading. http://makeashorterlink.com/?F1DF46422 Getting Started Guide Cast your minds back, dear readers, if you will, to last week, where Erik Lechak proposed writing a getting started guide. Well, he did just that, starting from the beginning with the configure system and then all the way out. There were many comments and suggestions, and it would be great to see this as POD and in the repository soon. Unfortunately, it is not in the archive. Larry explains all Perl6-language had very few new threads this week. Instead, there were mostly little updates to previous threads, which makes it somewhat tricky to summarise. However, Larry Wall was everywhere this week, giving us detailed insights into the Perl 6 language. Larry clarified that to remove ambiguity, variable properties will surrounded in brackets and have repetitions of is: # instead of this: my $foo is rw cmp ; # we would have: my ($foo is foo is bar, $bar is baz) = (1,2); Additionally, it looked like class attributes had changed
Re: Values, Variables, Assignment
Date: Tue, 15 Oct 2002 12:24:56 -0700
From: Michael Lazzaro [EMAIL PROTECTED]
In Perl, variable names always begin with a special character called
a sigil,
Ahem, funny character. The Camel glossary has no entry for sigil
(though I realize it's common terminology).
Any value may be forced, however, into being an explicit type: this is
commonly known as casting or typecasting. Typecasting is the act of
transforming a value of one type into a value of another type. The
typecasting operator in Perl is as:
5 as int
5 as string
5 as MyNumber
Weren't we going to use constructor-style typecasting (at least as it
currently stands)?
int(5)
# or
int.new(5)
The keyword but is provided as a synonym for is. A typical use for but
is in expressions where the property is perhaps surprising in some
way.
Nope. Cbut is entirely different from Cis. I think the best
description is that Cis is for variables, and Cbut is for values.
I can't be sure this is always the case, however Indeed, many of
your examples use Cis when they should use Cbut.
Variables may be given two types of assertions, which are declared
using on get and on set:
my Dog $dog
on get { ... }
on set { ... };
I'd imagine that these, too, would be properties.
my Dog $dog is retriever {...} # :-P
Luke
Re: Indeterminate math
On Tue, Oct 15, 2002 at 01:44:50PM -0500, Jonathan Scott Duff wrote:
People have used the terms error and exception interchangably in
this disucssion. To me, an error is something that stops program
execution while an exception may or may not stop execution depending
on what the user decides to do about exceptions.
Unless I've missed my mark, Perl errors have always been trappable [1]. Does
that make them exceptions? We've been calling them errors for years now.
Put another way, is there a significant difference between:
eval {
$foo = 1/0;
print Bar;
}
if( $@ =~ /^Illegal division by zero/ ) {
... oops ...
}
and
try {
$foo = 1/0;
print Bar;
}
catch {
when /^Illegal division by zero/ {
... oops ...
}
}
(putting aside that exception handlers stack).
Whatever you call it, exception or error, it will halt the program if left
unhandled.
[1] Less the few odd really hard core the interpreter is having a bad trip
sort of errors.
--
Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/
Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Here's hoping you don't harbor a death wish!
Re: Indeterminate math
In a message dated Tue, 15 Oct 2002, Michael G Schwern writes:
On Tue, Oct 15, 2002 at 01:44:50PM -0500, Jonathan Scott Duff wrote:
People have used the terms error and exception interchangably in
this disucssion. To me, an error is something that stops program
execution while an exception may or may not stop execution depending
on what the user decides to do about exceptions.
Unless I've missed my mark, Perl errors have always been trappable [1]. Does
that make them exceptions? We've been calling them errors for years now.
The Perl trainers I've seen have been calling Perl errors exceptions for
years now, mostly, I think, to shut up the Javaphiles who think that
they're the only ones that have such a wondrous and unprecedented thing
(at least, that's why I always did it ;-)
Put another way, is there a significant difference between:
eval {
$foo = 1/0;
print Bar;
}
if( $ =~ /^Illegal division by zero/ ) {
... oops ...
}
and
try {
$foo = 1/0;
print Bar;
}
catch {
when /^Illegal division by zero/ {
... oops ...
}
}
None that I can see.
Trey
Re: Values, Variables, Assignment
On Tuesday, October 15, 2002, at 01:07 PM, Luke Palmer wrote: Any value may be forced, however, into being an explicit type: this is commonly known as casting or typecasting. Typecasting is the act of transforming a value of one type into a value of another type. The typecasting operator in Perl is as: 5 as int 5 as string 5 as MyNumber Weren't we going to use constructor-style typecasting (at least as it currently stands)? int(5) # or int.new(5) Not sure -- probably so, but now I'm thinking it couldn't work that way. I don't think typecasting can be constructor-based, because if you said ($obj as MyThing), and $obj was already a MyThing, you probably shouldn't be cloning it, whereas (MyThing.new($obj)) probably should. The keyword but is provided as a synonym for is. A typical use for but is in expressions where the property is perhaps surprising in some way. Nope. Cbut is entirely different from Cis. I think the best description is that Cis is for variables, and Cbut is for values. I can't be sure this is always the case, however Indeed, many of your examples use Cis when they should use Cbut. Thanks, I'll redo. I'm trying to look it up again, but I still can't find the thread. (Apparently I am the only one confused by this, but mighty confused I still be.) MikeL
Re: Indeterminate math
Put another way, is there a significant difference between:
eval {
$foo = 1/0;
print Bar;
}
if( $ =~ /^Illegal division by zero/ ) {
... oops ...
}
and
try {
$foo = 1/0;
print Bar;
}
catch {
when /^Illegal division by zero/ {
... oops ...
}
}
(putting aside that exception handlers stack).
Yeah. The latter is not valid syntax in any version of Perl. :)
try {
$foo = 1/0;
print Bar\n;
CATCH {
when /division by [zero|0]/ {
... ooops ...
}
}
}
Luke
Re: A concept for Exceptions
From: Luke Palmer [EMAIL PROTECTED] I like the idea of this. The finer details, like returning what to do, could be more elegant. But the extensibility idea is golden. Thanks Luke. Your email made me think of another way of explaining the concept. Basically, what I'm suggesting is that certain common types of exceptions could be handled in-place, instead of having to write exception handlers. Perl5 already does some things like this, e.g. undefs become empty strings and zeros when needed. I'm just suggesting formalizing the process more so that custom in-place exception handlers can be implemented. Does that make the return what to do concept a little more elegant? If not, feel free to work a Pygmalion with my Eliza Doolittle. -miko mail2web - Check your email from the web at http://mail2web.com/ .
Re: signal 11 when run on x86, JIT enabled
On Mon, Oct 14, 2002 at 10:06:54AM +0200, Leopold Toetsch wrote: Steve Fink wrote: The problem is that the JIT doesn't support tracing. No, the problem is, that restarting JIT is broken. So it's truely a bug and should not be marked with SKIP or TODO. ... I could imagine ways of fixing this -- make it drop into a non-JIT core if tracing is turned on, This is, what restart NEXT() does. That's what I originally thought, but there seemed to be no attempt at implementing this in the code, so I though it must not have been attempted yet -- hence the TODO. But either way -- anyone want to take a crack at it? If I remember correctly, it would essentially require making restart somehow compile down to the code for 'end', plus setting some flags so you know you're not really done yet. Then put the runops() call in a loop if it isn't already, to keep going until a true 'end' op is reached. For bonus points, re-enter JIT runops when tracing and debugging are turned back off. Or something like that. I'm not looking at the code right now.
getting started guide in pod
Well I hope there are some interested parties out there for this. The
new and improved getting started guide should be ready in pod by
Thursday. I have added more content and tried to incorporate the
suggestions that everyone gave to me. The document is growing as I
learn more. I have translated the document several times, but when I
want to add more content I go back to the original format because I find
writing in pod so distasteful.
Is there a module or a script out there that will let me write in
freestyle pod (allowing indentation and reasonable blank line
placement) and translate it to pod?
Just wondering: What would another documentation style have to provide
to make it an acceptable replacement for pod?
On a side note. If you replace the current libparrot_def.in file with
this (see listing below). The dll (win32) built with 'make shared' will
make the t/src tests pass (make sure libparrot.dll is in the path). The
majority of the tests pass. Some say that they fail, but on closer
inspection, the output and the expected output are the same. I have
verified this several times by compiling the test code myself. I am
left with the conclusion that the perl testing modules might be
malfunctioning somehow. I am currently looking at them.
Thanks,
Erik
LIBRARY libparrot
DESCRIPTION 'Parrot Interpreter'
EXPORTS
Parrot_new
Parrot_init
Parrot_setflag
Parrot_setwarnings
Parrot_readbc
Parrot_loadbc
Parrot_runcode
Parrot_destroy
Parrot_debug
Parrot_disassemble
Parrot_DynOp_core_${MAJOR}_${MINOR}_${PATCH}
internal_exception
intlist_new
intlist_get
intlist_push
intlist_pop
intlist_assign
intlist_unshift
intlist_shift
intlist_length
Parrot_sprintf_c
string_to_cstring
pmc_new
Re: A concept for Exceptions
At 2:33 PM -0400 10/15/02, [EMAIL PROTECTED] wrote: The constructor returns one of three values: an exception object, the DO_OVER constant, or the EXPRESSION constant. If an exception object is returned, that means that the interpretor should immediately exit the block, throwing the exception to that block's CATCH block, or its parent's CATCH block, and so on outward until somebody catches it. You know the routine. DO_OVER means to reevaluate the expression because the reference to the offending variable has been set to something else. While a nifty idea, this is not going to happen, at least not in the general case. Restartable exceptions are very, very difficult to do. (And parrot, alas, isn't going to be able to do them) You still need to establish an exception handler at the spot you want to restart at (which isn't free, alas) and you run into problems when you cross some internal boundaries in the interpreter. That won't stop you from throwing a continuation when you throw your own exceptions, which your own exception handlers can invoke when they see fit, but low-level exceptions like division by zero and suchlike things won't be able to do that. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
