At 07:44 PM 2/14/2001 +, Simon Cozens wrote:
>On Wed, Feb 14, 2001 at 08:32:41PM +0100, [EMAIL PROTECTED] wrote:
> > > DESTROY would get called twice, which is VERY BAD.
> >
> > *blink*
> > It is? Why?
> > I grant you it isn't the clearest way of programming, but "VERY BAD"?
>
>package Nuclear
On Wed, Feb 14, 2001 at 08:32:41PM +0100, [EMAIL PROTECTED] wrote:
> > DESTROY would get called twice, which is VERY BAD.
>
> *blink*
> It is? Why?
> I grant you it isn't the clearest way of programming, but "VERY BAD"?
package NuclearReactor::CoolingRod;
sub new {
Reactor->decrease_core_te
On Wed, Feb 14, 2001 at 02:10:59PM -0300, Branden wrote:
>
> Dan Sugalski wrote:
>
> > Plus there's nothing stopping you from having $obj->DESTROY in your own
> > code, though it may be inadvisable.
>
> It is (mainly) inadvisable because:
> 1. GC will call DESTROY when it collects the memory, s
On Wed, Feb 14, 2001 at 01:30:03PM -0300, Branden wrote:
> John Porter wrote:
> > James Mastros wrote:
> > > I'd think that an extension to delete is in order here. Basicly, delete
> > > should DESTROY the arg, change it's value to undef,...
> >
> > Huh? What delete are you thinking of? This is
Branden wrote:
> John Porter wrote:
> > > ...and trigger a GC that will get rid of the arg.
> >
> > No. Perl decides for itself when to do GC.
>
> The idea is to *allow* a programmer to explicitly destroy an object, for
> better (and sooner) resource disposal. The programmer wouldn't have to do
On Wed, Feb 14, 2001 at 01:25:26PM -0300, Branden wrote:
> The problem is when objects are shared by
> many variables. For example:
>
> $a = new Object();
> $b = $a;
> ...
> destroy $a; ## would call $a->DESTROY()
> ...
> $b->doSomething();## should die. Note
On Wed, Feb 14, 2001 at 01:43:22PM -0300, Branden wrote:
> As I wrote in the last post, this isn't what I'm talking about. I'm talking
> about destroying the object before the GC does.
Yah, so am I. I'm just saying that after the object is destroyed, don't
keep it around.
> Yeah, what about a na
[[ reply to this goes only to -internals ]]
Dan Sugalski wrote:
> *) People like it
Well, if people liking it is the only reason (either is the only on or
appears 3 times in a 5 item list, what is pretty much the same to me ;-)
[... the only reason] to add a feature to Perl, we'll probably end
David Mitchell wrote:
> James Mastros <[EMAIL PROTECTED]> wrote:
> > [snip about DESTORY predictablity not being neccessary]
> > You're probably right about that, Branden. Quite nice, but not
neccessary.
> Hmm, I'd have to say that predictability is very, *very* nice,
> and we shouldnt ditch it u
James Mastros wrote:
> On Wed, Feb 14, 2001 at 09:59:31AM -0500, John Porter wrote:
> > Huh? What delete are you thinking of? This is Perl, not C++.
> Umm, perldoc -f delete?
>
> Come to think of it, this doesn't mesh purticularly well with the current
> meaning of delete. It does, however, wit
At 10:12 AM 2/14/2001 -0300, Branden wrote:
>David Mitchell wrote:
> > James Mastros <[EMAIL PROTECTED]> wrote:
> > > ... do refcounting (or somthing like it) for DESTROY to get called at
>the right
> > > time if the class (or any superclass) has an AUTOLOAD, which is
>expensive.
> > ... the above
John Porter wrote:
> James Mastros wrote:
> > I'd think that an extension to delete is in order here. Basicly, delete
> > should DESTROY the arg, change it's value to undef,...
>
> Huh? What delete are you thinking of? This is Perl, not C++.
>
Agreed, definitely Perl is not C++.
> > ...and t
James Mastros wrote:
> On Wed, Feb 14, 2001 at 10:12:36AM -0300, Branden wrote:
> > Also, I think it would be valid for the programmer to explicitly say ``I
> > would like to DESTROY this object now'',
> I'd think that an extension to delete is in order here. Basicly, delete
> should DESTROY the
James Mastros <[EMAIL PROTECTED]> wrote:
> [snip about DESTORY predictablity not being neccessary]
> You're probably right about that, Branden. Quite nice, but not neccessary.
Hmm, I'd have to say that predictability is very, *very* nice,
and we shouldnt ditch it unless we *really* have to.
[ l
On Wed, Feb 14, 2001 at 09:59:31AM -0500, John Porter wrote:
> James Mastros wrote:
> > I'd think that an extension to delete is in order here. Basicly, delete
> > should DESTROY the arg, change it's value to undef,...
> Huh? What delete are you thinking of? This is Perl, not C++.
Umm, perldoc
James Mastros wrote:
> I'd think that an extension to delete is in order here. Basicly, delete
> should DESTROY the arg, change it's value to undef,...
Huh? What delete are you thinking of? This is Perl, not C++.
> ...and trigger a GC that will get rid of the arg.
No. Perl decides for itse
On Wed, Feb 14, 2001 at 10:12:36AM -0300, Branden wrote:
> David Mitchell wrote:
> > ... the above seems to imply a discussion that you only need to do
> expensive
> > ref-counting (or whatever) on objects which have a DESTROY method.
> > However, since you dont know in advance what class(es), if
David Mitchell wrote:
> James Mastros <[EMAIL PROTECTED]> wrote:
> > ... do refcounting (or somthing like it) for DESTROY to get called at
the right
> > time if the class (or any superclass) has an AUTOLOAD, which is
expensive.
> ... the above seems to imply a discussion that you only need to do
e
James Mastros <[EMAIL PROTECTED]> wrote:
> The idea is [for Larry] to declare "no, it isn't". Otherwise, you have to
> do refcounting (or somthing like it) for DESTROY to get called at the right
> time if the class (or any superclass) has an AUTOLOAD, which is expensive.
I'm coming in halfway th
At 06:35 PM 2/13/01 +, Nicholas Clark wrote:
> > This may be a naive question, but what is the benefit - aside from
> > consistency, and we don't need to rehash the litany on that - to AUTOLOAD
> > getting called for DESTROY? I've never actually seen any code that makes
> > use of it. I hav
At 10:32 AM 2/13/2001 -0800, Peter Scott wrote:
>At 01:16 PM 2/13/01 -0500, James Mastros wrote:
>>On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
>>Certainly AUTOLOAD gets
>> > called if DESTROY is called but not defined ... just
>> > like any other method.
>>The idea is [for Larry]
On Tue, Feb 13, 2001 at 10:32:26AM -0800, Peter Scott wrote:
> At 01:16 PM 2/13/01 -0500, James Mastros wrote:
> >On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
> >Certainly AUTOLOAD gets
> > > called if DESTROY is called but not defined ... just
> > > like any other method.
> >The i
At 01:16 PM 2/13/01 -0500, James Mastros wrote:
>On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
>Certainly AUTOLOAD gets
> > called if DESTROY is called but not defined ... just
> > like any other method.
>The idea is [for Larry] to declare "no, it isn't". Otherwise, you have to
>do
On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
> > >"It isn't possible to AUTOLOAD DESTROY." --perlmem(6)
>
> I'm not sure what that means. Certainly AUTOLOAD gets
> called if DESTROY is called but not defined ... just
> like any other method.
Yes, its a classic autoloader mistake
On Tue, Feb 13, 2001 at 01:09:11PM -0500, John Porter wrote:
> > James Mastros wrote:
> > >"It isn't possible to AUTOLOAD DESTROY." --perlmem(6)
[Note: that's a hypothetical quote.]
> I'm not sure what that means. Certainly AUTOLOAD gets
> called if DESTROY is called but not defined ... just
> l
> James Mastros wrote:
>
> >"It isn't possible to AUTOLOAD DESTROY." --perlmem(6)
I'm not sure what that means. Certainly AUTOLOAD gets
called if DESTROY is called but not defined ... just
like any other method.
--
John Porter
On Tue, Feb 13, 2001 at 12:40:45PM -0500, Dan Sugalski wrote:
> At 05:55 PM 2/12/2001 -0500, James Mastros wrote:
> >It's pretty hard (for me) to think of when you'd want an AUTOLOADed DESTROY,
> >since if you create /any/ objects of the class, DESTROY will be called.
> >"It isn't possible to AUT
At 05:55 PM 2/12/2001 -0500, James Mastros wrote:
>On Mon, Feb 12, 2001 at 05:33:05PM -0500, Dan Sugalski wrote:
> >package foo;
> >use attrs qw(cleanup_sub);
> >
> > would be nice, but I don't know that he'll go for it. (Though it's the
> only
> > way I can think of to avoid AUTOLOAD bei
On Mon, Feb 12, 2001 at 05:33:05PM -0500, Dan Sugalski wrote:
>package foo;
>use attrs qw(cleanup_sub);
>
> would be nice, but I don't know that he'll go for it. (Though it's the only
> way I can think of to avoid AUTOLOAD being considered a potential destructor)
Fiat?
It's pretty hard
At 17:33 12/02/2001 -0500, Dan Sugalski wrote:
>At 11:28 PM 2/12/2001 +0100, Robin Berjon wrote:
>>Couldn't we simply (for non-implementer values of simply) provide a way for
>>people to ask for finalization on an object ? Given that most of the time
>>it isn't needed, it wouldn't be too much of a
At 11:28 PM 2/12/2001 +0100, Robin Berjon wrote:
>At 15:37 12/02/2001 -0500, Dan Sugalski wrote:
> >It *is* rare in OO perl, though. How many of the variables you use are
> >really, truly in need of finalization? .1 percent? .01 percent? Less? Don't
> >forget that you need to count every scalar in
At 15:37 12/02/2001 -0500, Dan Sugalski wrote:
>It *is* rare in OO perl, though. How many of the variables you use are
>really, truly in need of finalization? .1 percent? .01 percent? Less? Don't
>forget that you need to count every scalar in every array or hash, and
>every iteration over a blo
At 01:44 PM 2/12/2001 -0800, Jan Dubois wrote:
>On Mon, 12 Feb 2001 16:28:00 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> >Yep, that's another issue, and one I keep forgetting about, though the fact
> >that we don't do predictable finalization on some objects isn't a good
>
>Yes, I know I pr
On Mon, 12 Feb 2001 16:28:00 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>Yep, that's another issue, and one I keep forgetting about, though the fact
>that we don't do predictable finalization on some objects isn't a good
Yes, I know I promised to shut up until you come up with a spec, but
At 09:08 PM 2/12/2001 +, Piers Cawley wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
> > >On Mon, 12 Feb 2001, Dan Sugalski wrote:
> > >
> > > > Perl needs some level of tracking for objects with finalization
> attached to
> > > > them. F
Dan Sugalski <[EMAIL PROTECTED]> writes:
> At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
> >On Mon, 12 Feb 2001, Dan Sugalski wrote:
> >
> > > Perl needs some level of tracking for objects with finalization attached to
> > > them. Full refcounting isn't required, however.
> >
> >I think I've hea
At 01:33 PM 2/12/2001 -0500, Sam Tregar wrote:
>On Mon, 12 Feb 2001, Dan Sugalski wrote:
>
> > >I think I've heard you state that before. Can you be more specific? What
> > >alternate system do you have in mind? Is this just wishful thinking?
> >
> > This isn't just wishful thinking, no.
>
>You
At 10:46 AM 2/12/2001 -0800, Jan Dubois wrote:
>On Mon, 12 Feb 2001 13:29:21 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> >At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
> >>On Mon, 12 Feb 2001, Dan Sugalski wrote:
> >>
> >> > Perl needs some level of tracking for objects with finalization
On Mon, 12 Feb 2001 13:33:52 -0500 (EST), Sam Tregar <[EMAIL PROTECTED]>
wrote:
>> It's reasonably obvious (which is to say "cheap") which variables aren't
>> involved with anything finalizable.
>
>Probably a simple bit check and branch. Is that cheap? I guess it must
>be.
Yes, but incrementin
On Mon, Feb 12, 2001 at 01:33:52PM -0500, Sam Tregar wrote:
> Perhaps. It's not rare in OO Perl which is coincidentally one area in
> serious need of a speedup. I suppose I'm warped by my own experience -
> all the code I see every day is filled with references and objects.
> That's probably not
On Mon, 12 Feb 2001 13:29:21 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
>>On Mon, 12 Feb 2001, Dan Sugalski wrote:
>>
>> > Perl needs some level of tracking for objects with finalization attached to
>> > them. Full refcounting isn't required, ho
On Mon, 12 Feb 2001, Dan Sugalski wrote:
> >I think I've heard you state that before. Can you be more specific? What
> >alternate system do you have in mind? Is this just wishful thinking?
>
> This isn't just wishful thinking, no.
You picked the easy one. Maybe you can get back to the other
At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
>On Mon, 12 Feb 2001, Dan Sugalski wrote:
>
> > Perl needs some level of tracking for objects with finalization attached to
> > them. Full refcounting isn't required, however.
>
>I think I've heard you state that before. Can you be more specific? Wh
i think Matz will agree with me...
(consider telling dave thomas and andy hunt, too...)
"a language author does not a god make"
-- a proverb from the days of cobol
> On Mon, Feb 12, 2001 at 12:11:19AM -0800, yaphet jones wrote:
> [Ruby]
>> *no god complex
>> *no high priests
>
> I'll
Sam Tregar wrote:
> On Mon, 12 Feb 2001, Dan Sugalski wrote:
> > Also, the vast majority of perl variables have no finalization
> > attached to them.
>
> That's true, but without static typing don't you have to treat them as if
> they did? At the very least you need to do a "is it an object with
On Mon, 12 Feb 2001, Dan Sugalski wrote:
> Perl needs some level of tracking for objects with finalization attached to
> them. Full refcounting isn't required, however.
I think I've heard you state that before. Can you be more specific? What
alternate system do you have in mind? Is this just
On Mon, Feb 12, 2001 at 12:11:19AM -0800, yaphet jones wrote:
[Ruby]
> *no god complex
> *no high priests
I'll tell Matz you said that.
--
hantai mo hantai aru:
The reverse side also has a reverse side.
-- Japanese proverb
gentlemen (a small liberty, i admit) -
all of this *pointless* debate could be set aside - if all of you
would just renounce perl - and adopt ruby as your language
it's why larry has shut himself up in silence - feigning illness:
*true (not bolted-on) oo language
*modern (not post-mod
At 11:36 PM 2/11/2001 -0500, Sam Tregar wrote:
>On Sun, 11 Feb 2001, Jan Dubois wrote:
>
> > However, I couldn't solve the problem of "deterministic destruction
> > behavior": Currently Perl will call DESTROY on any object as soon as the
> > last reference to it goes out of scope. This becomes im
On Sun, 11 Feb 2001, Jan Dubois wrote:
> However, I couldn't solve the problem of "deterministic destruction
> behavior": Currently Perl will call DESTROY on any object as soon as the
> last reference to it goes out of scope. This becomes important if the
> object own scarce external resources (
On Sun, 11 Feb 2001 21:11:09 -0500, "Bryan C. Warnock"
<[EMAIL PROTECTED]> wrote:
>On Sunday 11 February 2001 19:08, Jan Dubois wrote:
>> However, I couldn't solve the problem of "deterministic destruction
>> behavior": Currently Perl will call DESTROY on any object as soon as the
>> last referen
On Sunday 11 February 2001 19:08, Jan Dubois wrote:
> However, I couldn't solve the problem of "deterministic destruction
> behavior": Currently Perl will call DESTROY on any object as soon as the
> last reference to it goes out of scope. This becomes important if the
> object own scarce external
On Fri, 09 Feb 2001 13:19:36 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>Almost all refcounting schemes are messy. That's one of its problems. A
>mark and sweep GC system tends to be less prone to leaks because of program
>bugs, and when it *does* leak, the leaks tend to be large. Plus the
[Please be careful with attributions -- I didn't write any
of the quoted material...]
Russ Allbery wrote:
> >> sub test {
> >> my($foo, $bar, %baz);
> >> ...
> >> return \%baz;
> >> }
> That's a pretty fundamental aspect of the Perl language; I use that sort
Bart Lateur wrote:
> On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
> > 1. Cheap allocations. Most fast collectors have a one or two
> >instruction malloc. In C it looks like this:
> >
> > void *malloc(size) { void *obj = heap; heap += size; return obj; }
> > ...
>
> That is not a ga
On Fri, 9 Feb 2001 16:14:34 -0800, Mark Koopman wrote:
>but is this an example of the way people SHOULD code, or simply are ABLE to
>code this. are we considering to deprecate this type of bad style, and force
>to a programmer to, in this case, supply a ref to %baz in the arguements to
>this s
Mark Koopman <[EMAIL PROTECTED]> writes:
> > On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
> >
> >
> > That may work for C, but not for Perl.
> >
> > sub test {
> > my($foo, $bar, %baz);
> > ...
> > return \%baz;
> > }
> >
> > You may notice that only PART
Simon Cozens <[EMAIL PROTECTED]> writes:
> On Fri, Feb 09, 2001 at 04:14:34PM -0800, Mark Koopman wrote:
> > > sub test {
> > > my($foo, $bar, %baz);
> > > ...
> > > return \%baz;
> > > }
> > are we considering to deprecate this type of bad style
>
> What bad style?
Well,
At 01:05 AM 2/10/2001 +0100, Bart Lateur wrote:
>On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
> > 2. Work proportional to live data, not total data. This is hard to
> >believe for a C programmer, but good garbage collectors don't have
> >to "free" every allocation -- they just have t
On Fri, Feb 09, 2001 at 04:14:34PM -0800, Mark Koopman wrote:
> > sub test {
> > my($foo, $bar, %baz);
> > ...
> > return \%baz;
> > }
> are we considering to deprecate this type of bad style
What bad style?
--
DESPAIR:
It's Always Darkest Just Before it Gets
Mark Koopman <[EMAIL PROTECTED]> writes:
>> On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
>> That may work for C, but not for Perl.
>>
>> sub test {
>> my($foo, $bar, %baz);
>> ...
>> return \%baz;
>> }
> but is this an example of the way people SHOULD
> On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
>
>
> That may work for C, but not for Perl.
>
> sub test {
> my($foo, $bar, %baz);
> ...
> return \%baz;
> }
>
> You may notice that only PART of the locally malloced memory, gets
> freed. the memor
On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
>There are two main reasons advanced garbage collectors are fast:
>
> 1. Cheap allocations. Most fast collectors have a one or two
>instruction malloc. In C it looks like this:
>
> void *malloc(size) { void *obj = heap; heap += size; ret
At 04:53 PM 2/9/2001 -0500, Ken Fox wrote:
>Dan Sugalski wrote:
> > At 04:09 PM 2/9/2001 -0200, Branden wrote:
> > > If I change the way some objects are used so
> > > that I tend to create other objects instead of reusing the old ones, I'm
> > > actually not degrading GC performance, since its wo
At 10:21 PM 2/9/2001 +0100, Robin Berjon wrote:
>At 16:16 09/02/2001 -0500, Ken Fox wrote:
> >The general rule is the more space you "waste" the faster the collector
> >is. If you have memory to spare, then don't run the garbage collector as
> >often and your program will spend less total time gar
Dan Sugalski wrote:
> At 04:09 PM 2/9/2001 -0200, Branden wrote:
> > If I change the way some objects are used so
> > that I tend to create other objects instead of reusing the old ones, I'm
> > actually not degrading GC performance, since its work is proportional to
> > live data. Right?
>
> Cor
At 16:16 09/02/2001 -0500, Ken Fox wrote:
>The general rule is the more space you "waste" the faster the collector
>is. If you have memory to spare, then don't run the garbage collector as
>often and your program will spend less total time garbage collecting.
>In other words, the collection cost p
Branden wrote:
> Ken Fox wrote:
> > Some researchers have estimated that 90% or
> > more of all allocated data dies (becomes unreachable) before the
> > next collection. A ref count system has to work on every object,
> > but smarter collectors only work on 10% of the objects.
>
> Does this 90/10
At 06:30 PM 2/9/2001 +, Nicholas Clark wrote:
>On Fri, Feb 09, 2001 at 01:19:36PM -0500, Dan Sugalski wrote:
> > The less memory you chew through the faster your code will probably be (or
> > at least you'll have less overhead). Reuse is generally faster and less
> > resource-intensive than re
At 05:29 PM 2/9/2001 -0200, Branden wrote:
>Ken Fox wrote:
> > 2. Work proportional to live data, not total data. This is hard to
> > believe for a C programmer, but good garbage collectors don't have
> > to "free" every allocation -- they just have to preserve the live,
> > or reacha
[EMAIL PROTECTED] wrote:
> So, it's more a data preserver than a garbage collector ;-)
>
> Abigail
I find it odd that perl mallocs each string individually, for instance;
I had thought that it would only malloc massive pieces and do its own
allocation and freeing of it. Its laziness, of c
On Fri, Feb 09, 2001 at 12:06:12PM -0500, Ken Fox wrote:
>
> 2. Work proportional to live data, not total data. This is hard to
> believe for a C programmer, but good garbage collectors don't have
> to "free" every allocation -- they just have to preserve the live,
> or reachable, da
Ken Fox wrote:
> 2. Work proportional to live data, not total data. This is hard to
> believe for a C programmer, but good garbage collectors don't have
> to "free" every allocation -- they just have to preserve the live,
> or reachable, data. Some researchers have estimated that 90%
On Fri, Feb 09, 2001 at 01:19:36PM -0500, Dan Sugalski wrote:
> The less memory you chew through the faster your code will probably be (or
> at least you'll have less overhead). Reuse is generally faster and less
> resource-intensive than recycling. What's true for tin cans is true for memory.
At 04:09 PM 2/9/2001 -0200, Branden wrote:
>Dan Sugalski wrote:
> > At 12:06 PM 2/9/2001 -0500, Ken Fox wrote:
> > > 2. Work proportional to live data, not total data. This is hard to
> > > believe for a C programmer, but good garbage collectors don't have
> > > to "free" every allocation
Dan Sugalski wrote:
> At 12:06 PM 2/9/2001 -0500, Ken Fox wrote:
> > 2. Work proportional to live data, not total data. This is hard to
> > believe for a C programmer, but good garbage collectors don't have
> > to "free" every allocation -- they just have to preserve the live,
> > or
At 12:06 PM 2/9/2001 -0500, Ken Fox wrote:
>Branden wrote:
> > I actually don't understand how traversing a graph can be faster than
> > incrementing/decrementing/testing for zero on a refcount.
>
>There are two main reasons advanced garbage collectors are fast:
>
> 1. Cheap allocations. Most fas
Branden wrote:
> I actually don't understand how traversing a graph can be faster than
> incrementing/decrementing/testing for zero on a refcount.
There are two main reasons advanced garbage collectors are fast:
1. Cheap allocations. Most fast collectors have a one or two
instruction malloc
"Branden" <[EMAIL PROTECTED]> writes:
> Piers Cawley wrote:
> >"Branden" <[EMAIL PROTECTED]> writes:
> >> Of course, C++ has no GC, which is a good thing, but you can always
> >> fake it with Refcounts, which is much more efficient, and easily
> >> feasable with C++.
> >
> >Err... current researc
Piers Cawley wrote:
>"Branden" <[EMAIL PROTECTED]> writes:
>> Of course, C++ has no GC, which is a good thing, but you can always
>> fake it with Refcounts, which is much more efficient, and easily
>> feasable with C++.
>
>Err... current research shows that the refcount approach is one of the
>slo
David Mitchell wrote:
> Sorry, I misunderstood you. I think in fact we agree! What I was
> advocating was that Perl should automatically make accesses to
> individual shared variables safe, so 2 threads executing
> 1: $shared = 10; 2: $shared = 20;
>
> wont guarantee whether $shared ends up as 1
"Branden" <[EMAIL PROTECTED]> wrote:
> The thing with mandatory locks per variable, is that as long as you only
> want to access _that_ variable, it's ok, but if you want to make several
> uses of several variables and want to do it all at once, you've got a
> problem.
[ big snip ]
Sorry, I misu
David Mitchell wrote:
> I let the Perl developers do all
> the hard locking code behind the scenes, and I don't have to worry my
pretty
> little head about it.
> Now, there may be practical reasons why it isnt possible for perl to do
> this for me automatically (reasons, anyone?), but it's a nice
"Branden" <[EMAIL PROTECTED]> wrote:
> Well, mandatory locking is something we should definetly NOT have in Perl6.
> Most of perl's code today is not threaded, and I believe much of it will
> continue to be this way. The pseudo-fork thread behaviour that is being
> proposed also makes this ok. Eve
"Branden" <[EMAIL PROTECTED]> writes:
> Of course, C++ has no GC, which is a good thing, but you can always
> fake it with Refcounts, which is much more efficient, and easily
> feasable with C++.
Err... current research shows that the refcount approach is one of the
slowest forms of GC, and it d
At 12:54 PM 1/29/2001 -0800, Thomas Butler wrote:
>: Jeanna FOx wrote:
>: > It also looks like some features are impossible to turn off -- like the
>: > mandatory locking that jwz hates about Java. It's not safe to turn it
>: > off, but it's not really safe with it on either. Some people would ra
: Jeanna FOx wrote:
: > It also looks like some features are impossible to turn off -- like the
: > mandatory locking that jwz hates about Java. It's not safe to turn it
: > off, but it's not really safe with it on either. Some people would rather
: > loose the illusion of safety to get better pe
At 12:20 PM 1/29/2001 -0500, Jeanna FOx wrote:
>David Mitchell wrote:
> > Jeanna FOx <[EMAIL PROTECTED]> wrote:
> > > Everybody seems to be missing the fact that jwz bitching about Java's
> > > "32 bit non-object ints" means that at least he thinks they could be
> > > salvaged. What would he think
Jeanna FOx wrote:
> It also looks like some features are impossible to turn off -- like the
> mandatory locking that jwz hates about Java. It's not safe to turn it
> off, but it's not really safe with it on either. Some people would rather
> loose the illusion of safety to get better performance.
David Mitchell wrote:
> Jeanna FOx <[EMAIL PROTECTED]> wrote:
> > Everybody seems to be missing the fact that jwz bitching about Java's
> > "32 bit non-object ints" means that at least he thinks they could be
> > salvaged. What would he think of Perl's "224 bit non-object ints"?!
> > Don't get smu
> Perhaps you meant that Perl 6 is going to have homogeneous arrays, in
> which case an array of ints would keep 32 bits (per value) of int data in
> the array and auto-generate the extra flags and stuff when a value is
> extracted from the array. That's possible, but it's a special case of small
On Mon, Jan 29, 2001 at 03:14:04PM -0200, Branden wrote:
> Well, if a compiler can't figure it out that the types of the
> variables "Object" and "int" are different and it should make
> a conversion to assign one from the other, well, then the
> compiler writers are damn bad programmers!
The
Jeanna FOx wrote:
> Everybody seems to be missing the fact that jwz bitching about Java's
> "32 bit non-object ints" means that at least he thinks they could be
> salvaged. What would he think of Perl's "224 bit non-object ints"?!
> Don't get smug because Perl can iterate over an array of anything
Jarkko Hietaniemi <[EMAIL PROTECTED]> wrote:
> The desire to know the name of the runtime platform is a misdirected
> desire.
> What you really want to know is whether function Foo will be there,
what
> kind of signature it has, whether file Bar will be there, what kind of
> format it has,
Jeanna FOx <[EMAIL PROTECTED]> wrote:
> Everybody seems to be missing the fact that jwz bitching about Java's
> "32 bit non-object ints" means that at least he thinks they could be
> salvaged. What would he think of Perl's "224 bit non-object ints"?!
> Don't get smug because Perl can iterate over
J. David Blackstone wrote:
> Yeah, that was one of my disappointments when I finally made the
> Java plunge last month. I kind of expected integers to be objects in
> what I had heard was the "perfect, pure" OO language.
Everybody seems to be missing the fact that jwz bitching about Java's
"32 b
On Sun, Jan 28, 2001 at 11:07:10PM -0700, Nathan Torkington wrote:
> Jarkko Hietaniemi writes:
> > > True, but you can't do any of all that without knowing the platform
> > > accurately (nontrivial and requires core mod or XS). Once that's
> > > done, the rest is just a matter of extending File::
On Sun, Jan 28, 2001 at 11:54:13PM -0600, Jarkko Hietaniemi wrote:
> On Sun, Jan 28, 2001 at 08:56:33PM -0500, Michael G Schwern wrote:
> > On Sun, Jan 28, 2001 at 10:07:55PM +0100, Bart Lateur wrote:
> > > Uhm, I'm sorry, but that's not good enough. You cannot distinguish
> > > between Windows 95
On Mon, Jan 29, 2001 at 12:10:31AM -0600, Jarkko Hietaniemi wrote:
> Trivial? *cough* *snigger*
I'd write it up for you right now, but its too big to fit in the
margin.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
I've heard that semen tastes different depen
Jarkko Hietaniemi writes:
> > True, but you can't do any of all that without knowing the platform
> > accurately (nontrivial and requires core mod or XS). Once that's
> > done, the rest is just a matter of extending File::Spec
> > (trivial and pure Perl).
>
> Trivial? *cough* *snigger*
If it w
1 - 100 of 110 matches
Mail list logo
