Simon Cozens <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Larry Wall) writes:
> > Which basically comes down to this: an id represents a location in
> > memory for any objects that don't override the .id method.
>
> Aiee! No! Please don't let things override the address-in-memory method,
> as
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Date: Thu, 12 Dec 2002 17:33:06 -0800
> From: Larry Wall <[EMAIL PROTECTED]>
> Mail-Followup-To: [EMAIL PROTECTED]
> Content-disposition: inline
> X-SMTPD: qpsmtpd/0.20, http://develooper.com/code/qpsmtpd/
>
> On Wed, Dec 11, 2002 at 06:50:
> Date: Thu, 12 Dec 2002 17:07:21 -0800
> From: Larry Wall <[EMAIL PROTECTED]>
>
> It's not clear what .can should return for a multimethod, either.
> You'd have be able to return results like: "yes int can mult, but
> only if the second argument is an int or num". Basically, .can
> has a bad syn
> Date: Thu, 12 Dec 2002 16:26:28 -0500
> From: John Siracusa <[EMAIL PROTECTED]>
>
> On 12/12/02 4:01 PM, Larry Wall wrote:
> > On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
> > : So we'll _have_ to write $obj.*id when we mean $obj->UNIVERSAL::id;
> >
> > If you wish to be prec
Michael Lazzaro <[EMAIL PROTECTED]> writes:
> On Wednesday, December 11, 2002, at 06:56 PM, Simon Cozens wrote:
> > [EMAIL PROTECTED] (Michael Lazzaro) writes:
> >> Wel... yes and no. You can make the same argument for operators
> >> upon scalars, for example, since 'scalar' is arguably no m
On Thu, 12 Dec 2002, Sean O'Rourke wrote:
> # New Ticket Created by "Sean O'Rourke"
> # Please include the string: [perl #19090]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=19090 >
>
>
> The following defines a macro
On 12/13/02 5:09 AM, Luke Palmer wrote:
>> From: John Siracusa <[EMAIL PROTECTED]>
>> On 12/12/02 4:01 PM, Larry Wall wrote:
>>> On Thu, Dec 12, 2002 at 12:40:52PM -0600, Garrett Goebel wrote:
>>> : So we'll _have_ to write $obj.*id when we mean $obj->UNIVERSAL::id;
>>>
>>> If you wish to be preci
John Siracusa wrote:
>
> I'm saying that there are many kinds of objects that
> naturally want to have an "id" method or attribute
> that has nothing whatsoever to do with "this is the
> same object" comparisons.
[...]
> Using the method/attribute named "id" for "this is
> the same object" compari
On 12/13/02 10:49 AM, Garrett Goebel wrote:
> John Siracusa wrote:
>> Using the method/attribute named "id" for "this is
>> the same object" comparisons is just plain bad
>> Huffman coding. The "this is the same object"
>> method/attribute should have a name that reflects
>> the relative rarity of
Sean O'Rourke:
# +if (${jitcpuarch} eq 'ppc') {
# +print OUT <<'END';
# +#define VA_TO_VAPTR(x) (x)
# +END
# +} else {
# +print OUT <<'END';
# +#define VA_TO_VAPTR(x) (&(x))
# +END
# +}
How in the world does that...? Never mind, I don't think I want to
know. Might make my head explode or
Sean O'Rourke (via RT) wrote:
+if (${jitcpuarch} eq 'ppc') {
Shouldn't that better be ${cpuarch}. When JIT is disabled, ${jitcpuarch}
seems to be 'i386'. Also in case of 'miniparrot', ${cpuarch} is set to
'unknown' - suboptimal (s. config/auto/jit.pl).
leo
On Friday, December 13, 2002, at 06:56 AM, John Siracusa wrote:
I'm saying that there are many kinds of objects that naturally want to
have an "id" method or attribute that has nothing whatsoever to do
with "this is the same object" comparisons. But if "id" is chosen as
the name of the globa
On Thursday, December 12, 2002, at 06:55 PM, James Mastros wrote:
And I'd say (but who asked me -- IMHO, of course) that it should be
perfectly valid to write code like the above. (That IDs should be
unique across a process over all time.) If that'd require that an
object's ID be a combinat
Michael Lazzaro:
# On Thursday, December 12, 2002, at 06:55 PM, James Mastros wrote:
# > And I'd say (but who asked me -- IMHO, of course) that it should be
# > perfectly valid to write code like the above. (That IDs should be
# > unique across a process over all time.) If that'd require that a
On 12/13/02 12:44 PM, Michael Lazzaro wrote:
> On Thursday, December 12, 2002, at 06:55 PM, James Mastros wrote:
>> And I'd say (but who asked me -- IMHO, of course) that it should be
>> perfectly valid to write code like the above. (That IDs should be
>> unique across a process over all time.)
The only encompassing solution would seem to be to find a grammar rule
by which map,grep,etc are unambiguously methods of Array, but can
still be called in a fashion similar to [1]. That would, I suspect,
satisfy everyone.
On Friday, December 13, 2002, at 03:07 AM, Piers Cawley wrote:
What's w
Damian Conway writes:
> Famous last words. ;-)
>
>
> > Was it ever decided what C would look like with multiple streams?
>
> for zip(@x, @y, @z) -> $x, $y, $z {...}
>
> and its operator version:
>
> for @x ¦ @y ¦ @z -> $x, $y, $z {...}
>
>
> > Maybe we could just use
On Thu, Dec 12, 2002 at 09:39:18PM -0500, James Mastros wrote:
> On 12/12/2002 8:07 PM, Larry Wall wrote:
> > Ordinarily you'd test for subs with one of
> >
> > exists &Main::foo
> > &Main::foo.exists
> I thought that was now spelt exists %Main::{&foo} -- that the symbol
> tables were now
On Fri, Dec 13, 2002 at 09:56:15AM -0500, John Siracusa wrote:
> Using the method/attribute named "id" for "this is the same object"
> comparisons is just plain bad Huffman coding. The "this is the same object"
> method/attribute should have a name that reflects the relative rarity of its
> use.
On Fri, Dec 13, 2002 at 09:49:44AM -0600, Garrett Goebel wrote:
> Other common names for the proposed .id are:
>
> UUID: Universal Unique Identifier (DCE)
> GUID: Globally Unique Identfier (EFI)
>
> Of the 2, usage of "GUID" seems to be more common IMHO. Both of the above
> are identical in imple
Michael Lazzaro wrote:
I think this is one (rare) case where an UPPERCASE or unusual name might
not be a bad idea, so it will BRING ATTENTION to the fact that you're
using a unusual method.
$obj.ID;
$obj.IDENTITY;
If don't think we'll have much of a chance at teaching people to
_alwa
Jared> In languages/perl6/t/compiler/1_1.err, I get:
Jared>
Jared> Can't find loader Parrot_DynOp_core_0_0_7: ../imcc/imcc:
Jared> undefined symbol: Parrot_DynOp_core_0_0_7
Jared>
Jared> which is suspicious for the 0_0_7 when I actually checked out
Jared> 0_0_8.
Sean> You're right on the mark here
On Thursday, December 12, 2002, at 01:39 PM, Jared Rhine wrote:
Are we archiving our docs like the latest Literals doc somewhere
official, or should I just pick it out of the list archives?
Just grab it from the archives. We'll archive the approved sections
somewhere, but probably not the dr
On Thu, 12 Dec 2002, Jared Rhine wrote:
> On to some tests, although I'm curious to see how tests of literals
> turn out. Probably a lot of comparisons between different
> representations of the same thing.
Warning: most of the tests won't work now because the languages/perl6 is
woefully incomple
On Fri, Dec 13, 2002 at 09:16:34AM -0500, Simon Glover wrote:
> On Thu, 12 Dec 2002, Sean O'Rourke wrote:
> > The following defines a macro VA_TO_VAPTR(x) to convert va_list arguments
> > to pointers in a platform-independent way. Works for me on Linux-ppc.
> > Could someone with another CPU give
Dan --
OK.
The big rewrite is "done". There are still plenty of warts on the current
implementation,
not the least of which is a bunch of dead code that I still need to
remove. But, most
of the examples compile and run, including the ever popular (hi, acme!)
mandelzoom.
Queens.jako still does
Michael Lazzaro <[EMAIL PROTECTED]> writes:
> >> The only encompassing solution would seem to be to find a grammar rule
> >> by which map,grep,etc are unambiguously methods of Array, but can
> >> still be called in a fashion similar to [1]. That would, I suspect,
> >> satisfy everyone.
>
> On Fr
--- Michael Lazzaro <[EMAIL PROTECTED]> wrote:
>
> I'm more worried about storing them than creating them. The good
> thing
> about using memaddresses is that they're free; you don't need to
> store
> a separate ID in each and every object you ever create, on the off
> chance that something w
Michael Lazzaro wrote:
>
> I'm more worried about storing them than creating them.
> The good thing about using memaddresses is that they're
> free;
An UUID could be free up until the point where you request it.
> I think the odds of you wanting a truly unique ID for any
> given class are so l
--- Piers Cawley <[EMAIL PROTECTED]> wrote:
>
> Both of your proposed options are, frankly, vile. The
> multimethod/generic function approach has the advantage of putting
> the
> 'burden' of writing the generic function on the implementor rather
> than on the user. Given that implementation happ
Sean O'Rourke <[EMAIL PROTECTED]> wrote:
On Thu, 12 Dec 2002, Jared Rhine wrote:
> On to some tests, although I'm curious to see how tests of literals
> turn out. Probably a lot of comparisons between different
> representations of the same thing.
Warning: most of the tests won't work now becau
Austin Hastings <[EMAIL PROTECTED]> writes:
> --- Piers Cawley <[EMAIL PROTECTED]> wrote:
>
> >
> > Both of your proposed options are, frankly, vile. The
> > multimethod/generic function approach has the advantage of putting
> > the 'burden' of writing the generic function on the implementor
> >
32 matches
Mail list logo
