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 h

Re: [perl #17811] [PATCH] create pmcs with pmc initializer

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,

Re: Hi - Regarding JVM - parrot compatibility

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

Re: Indeterminate math

On 2002-10-14 at 20:49:52, Michael G Schwern wrote: > > It is also, as an example, the behavior required by the ECMAScript > > specification. > > Heh. "Because Javascript does it" is supposed to be an argument for? ;) Heh, indeed. :) But seriously, you could do worse. JavaScript receives a lot

RE: Lukasiewiczian logic (was Indeterminate math)

> 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

RE: Indeterminate math

Mark J. Reed wrote: > I realize the above is mathematically simplistic. The > real reason y = x/0 returns an error is because no matter what > value you assign to y, you aren't going to get x back via multiplying > y by 0. Well, that may be true in math; but there's no reason why it has to be tr

Lukasiewiczian logic (was Indeterminate math)

From: Andrew Rodland [EMAIL PROTECTED] > After much fighting with google to find the right spelling, Sorry bout that. Your searching was probably as difficult as my attempts to pronounce it. > it looks like "Lukasiewiczian NULL" is just the nifty NULL > that SQL has, and the nifty ways that it

Re: Indeterminate math

On Mon, Oct 14, 2002 at 08:25:43PM -0400, Mark J. Reed wrote: > On 2002-10-14 at 20:15:33, Michael G Schwern wrote: > > There are several verbal proofs why 1/0 is not +Infinity here: > > http://mathforum.org/dr.math/faq/faq.divideby0.html > > Yeah, that would be why I sent my followup. I did no

Re: Indeterminate math

On Mon, 14 Oct 2002, [EMAIL PROTECTED] wrote: : From: Mark J. Reed [EMAIL PROTECTED] : > Summary of values: : > : >1/0 +Inf : >-1/0 -Inf : >0/0 NaN : >Inf/0NaN : >Inf/Inf NaN : : Are Inf and NaN going to be standard i

Re: Indeterminate math

On Monday 14 October 2002 20:20, [EMAIL PROTECTED] wrote: > Are Inf and NaN going to be standard in Perl 6? As long as we're traveling > down that road, how about i (the square root of -1), or Lukasiwiscean Null? > (Sorry if I sound sarcastic, I'm actually honestly curious.) > After much fighting

Re: Indeterminate math

On 2002-10-14 at 20:15:33, Michael G Schwern wrote: > There are several verbal proofs why 1/0 is not +Infinity here: > http://mathforum.org/dr.math/faq/faq.divideby0.html Yeah, that would be why I sent my followup. I did not mean to imply that 1/0 is positive infinity in "real world math". How

Re: Indeterminate math

From: Mark J. Reed [EMAIL PROTECTED] > Summary of values: > >1/0 +Inf >-1/0 -Inf >0/0 NaN >Inf/0NaN >Inf/Inf NaN Are Inf and NaN going to be standard in Perl 6? As long as we're traveling down that road, how about i (

Re: Indeterminate math

On Mon, Oct 14, 2002 at 07:48:23PM -0400, Mark J. Reed wrote: > Actually, 1/0 is not NaN; it's +Infinity. You only get NaN out of > dividing by 0 if the numerator is either infinite or also 0. There are several verbal proofs why 1/0 is not +Infinity here: http://mathforum.org/dr.math/faq/faq.div

Re: Indeterminate math

On 2002-10-14 at 19:48:23, Mark J. Reed wrote: > Actually, 1/0 is not NaN; it's +Infinity. You only get NaN out of > dividing by 0 if the numerator is either infinite or also 0. > The reason most implementations throw an error on division by 0 > is that they either don't have a representation for

Re: Indeterminate math

Actually, 1/0 is not NaN; it's +Infinity. You only get NaN out of dividing by 0 if the numerator is either infinite or also 0. The reason most implementations throw an error on division by 0 is that they either don't have a representation for infinity (not a problem in IEEE floating point) or t

Re: Indeterminate math

On Mon, Oct 14, 2002 at 07:06:57PM -0400, Michael G Schwern wrote: > What happens when NaN is used in an expression? Is NaN + 0 == NaN? Actually, NaN is never equal to anything at all, even NaN. Many languages have an isNaN() function for that. -- David "cogent" Hand

Re: Indeterminate math

On Mon, Oct 14, 2002 at 05:45:23PM -0400, [EMAIL PROTECTED] wrote: > The problem with returning undef is that undef numifies to zero. Yes, but it does produce a warning. > It would make more sense if either 1/0 returned NaN, if Perl6 has NaN, or > throw an error, which Larry has indicated will

[perl #17936] [PATCH] MANIFEST

# New Ticket Created by Jürgen Bömmels # Please include the string: [perl #17936] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=17936 > There are again some files missing in MANIFEST. HINT: I have still [perl #16839] in

Re: Indeterminate math

At 10:38 PM +0100 10/14/02, Leon Brocard wrote: >Michael G Schwern sent the following bits through the ether: > >> 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?) > >This is proba

[perl #17935] [PATCH] Remove a warning

# New Ticket Created by Jürgen Bömmels # Please include the string: [perl #17935] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=17935 > /usr/local/bin/gcc -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Winline -Wshado

Re: untaintby property

On Mon, Oct 14, 2002 at 10:09:41AM -0400, [EMAIL PROTECTED] wrote: > SUMMARY > > The 'untaintby' property restricts which modules may untaint the data or > data derived from that data. > > DETAILS > > I was recently using a module I downloaded from CPAN and looking through > the code I discovere

RE: Indeterminate math

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 simpl

Re: [perl #17931] [PATCH] DOD/GC related

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

Re: Indeterminate math

Michael G Schwern sent the following bits through the ether: > 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?) This is probably the mathematician in me escaping, but I also remember

Re: Indeterminate math

On Mon, Oct 14, 2002 at 05:05:14PM -0400, 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

Indeterminate math

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 o

[perl #17931] [PATCH] DOD/GC related

# New Ticket Created by Leopold Toetsch # Please include the string: [perl #17931] # in the subject line of all future correspondence about this issue. # 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 peopl

RE: Draft Proposal: Declaring Classwide Attributes

On Mon, 14 Oct 2002, Larry Wall wrote: : We haven't solved the problem of instance methods that want to : reject class invocants at compile time. Though I suppose explicitly : declaring the type of the invocant would have that effect. I'm sure : there are some who would argue (and I might be one

Re: Draft Proposal: Declaring Classwide Attributes

On 2002-10-14 at 19:58:50, Piers Cawley wrote: > I would expect Class to inherit from Object (along with everything > else). It might be worth looking at a Smalltalk image or two at this > point... You might want to look at _Putting_Metaclasses_To_Work_ by Danforth and Forman - or at Ruby, which f

Re: [perl #17811] [PATCH] create pmcs with pmc initializer

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 n

Re: Draft Proposal: Declaring Classwide Attributes

On Monday, October 14, 2002, at 11:57 AM, Trey Harris wrote: >> class SomeClass { >> cmethod class_method {...} # via a keyword >> method instance_method {...} # via another keyword >> sub dont_care_method {...} # check it yourself, as

Re: Draft Proposal: Declaring Classwide Attributes

Austin Hastings <[EMAIL PROTECTED]> writes: > --- Larry Wall <[EMAIL PROTECTED]> wrote: >> If every Object happens to implement the Class interface, merely >> declaring the invocant as a Class would presumably have this effect, >> whether or not MD was in effect. I don't know whether that's a goo

Re: Draft Proposal: Declaring Classwide Attributes

In a message dated Mon, 14 Oct 2002, Michael Lazzaro writes: > So if the first two should be shorter than the third, one way to do > that would be something like: > > class SomeClass { > cmethod class_method {...} # via a keyword > method instance_method {

Re: Draft Proposal: Declaring Classwide Attributes

On Monday, October 14, 2002, at 10:28 AM, Larry Wall wrote: > On Mon, 14 Oct 2002, Larry Wall wrote: > And I should point out that this approach would be good not just for > type purity, but because it optimizes for the common case. Class > methods > are much rarer than instance methods. And

Re: untaintby property

I'd say the correct solution isn't to control which modules can accidentally untaint data (it seems pretty likely that no matter what we do, maliciously coded modules will be able to screw you over if they try to do so intentionally) but rather fix those aspects of tainting that allow any module t

Re: untaintby property

Larry said: > If properties aren't entirely passive, then it may be > possible to register a callback on the "tainted" property > itself that defeats any misguided attempt to untaint it. Callbacks on properties? That's too cool. By doing callbacks on tainted and on taintby, a module could be wri

Re: Draft Proposal: Declaring Classwide Attributes

On Mon, 14 Oct 2002, Larry Wall wrote: : We haven't solved the problem of instance methods that want to : reject class invocants at compile time. Though I suppose explicitly : declaring the type of the invocant would have that effect. I'm sure : there are some who would argue (and I might be one

Re: Draft Proposal: Declaring Classwide Attributes

--- Larry Wall <[EMAIL PROTECTED]> wrote: > On Sun, 13 Oct 2002, Michael Lazzaro wrote: > : My temporary hack while writing the proto-recipes was that we'd > have a > : property that would simply declare a method to be a class method, > but > : I'm having a hard time coming up with an acceptable

Re: Draft Proposal: Declaring Classwide Attributes

On Sun, 13 Oct 2002, Michael Lazzaro wrote: : My temporary hack while writing the proto-recipes was that we'd have a : property that would simply declare a method to be a class method, but : I'm having a hard time coming up with an acceptable name to suggest for it: : : method foo is class_

Re: untaintby property

If properties aren't entirely passive, then it may be possible to register a callback on the "tainted" property itself that defeats any misguided attempt to untaint it. It's unlikely to protect against malicious attempts, however. Larry

Re: your mail

On Sun, 13 Oct 2002, fearcadi wrote: : in : http://archive.develooper.com/perl6-language%40perl.org/msg11451.html : Larry Wall wrote: : > for @cases ^| @newcases -> $x is rw | $y {...} : : do I understand correctly that what happens is (more or less) -- : any($a,$b) := any($x,$y) I don't think

Re: Draft Proposal: Declaring Classwide Attributes

On Sun, 13 Oct 2002, Trey Harris wrote: : I was going to say the same thing, but then I remembered that Perl 6 : methods, unlike the sub 'methods' in Perl 5, won't get the invocant as the : first real argument--it will be the topic instead. And I don't think you : can do multiple-dispatch on topi

Re: Draft Proposal: Declaring Classwide Attributes

On Sun, 13 Oct 2002, Piers Cawley wrote: : I like that idea: : :class SomeClass { : method class_method ( Class $class: ... ) { ... } : method instance_method ( SomeClass $self : ... ) { ... } : method dont_care_method ( $self : ... ) { ... } :} : : Or

Re: perl6 operator precedence table

On Sun, 13 Oct 2002, Aaron Crane wrote: : Luke Palmer writes: : > Some of my students want to go: : > : > if ($x == 1 || 2) { ... } : > : > Now they can: : > : > if $x == 1 | 2 { ... } : : I like that a lot. (Some of my students also want to do that.) : : You can write an equivale

RE: perl6 operator precedence table

On Sun, 13 Oct 2002, fearcadi wrote: : in : http://archive.develooper.com/perl6-language%40perl.org/msg11440.html : Larry Wall wrote: : >I'm wondering whether the single ones could indicate parallel streams. : >We had the difficulty of specifying whether the C loop should : >terminate on the shor

Re: untaintby property

I think that if a package deliberately tries to untaint data, and then the data isn't untainted, there will be an error shortly. Perhaps you could be more specific about what you mean by "untainting things which shouldn't be untainted"? Did you mean globals? Otherwise, I'd think that if a packag

untaintby property

SUMMARY The 'untaintby' property restricts which modules may untaint the data or data derived from that data. DETAILS I was recently using a module I downloaded from CPAN and looking through the code I discovered that it untainted certain data that it had no business untainting (IMHO). The unt

Re: Hi - Regarding JVM - parrot compatibility (Assembly to Parrot)

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

Re: Hi - Regarding JVM - parrot compatibility

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 v

Hi - Regarding JVM - parrot compatibility

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 bytecod

Re: signal 11 when run on x86, JIT enabled

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

Re: Intlist question

Simon Glover wrote: > I've just tried to write PASM like: > > new P0, .IntList > new P1, .PerlInt > > set P1, 20 > set P0[0], P1 intlist takes only integers as data, no PMCs. > Simon leo