At 05:09 PM 2/15/2001 -0800, Hong Zhang wrote:
> > ...and because of this you can't randomly access the string, you are
> > reduced to sequential access (*). And here I thought we could have
> > left tape drives to the last millennium.
> >
> > (*) Yes, of course you could cache your sequential ac
At 09:13 PM 2/15/2001 -0500, Ken Fox wrote:
>Hong Zhang wrote:
> > The memory barriers are always needed on SMP, whatever algorithm
> > we are using.
>
>I was just pointing out that barriers are an alternative to mutexes.
>Ref count certainly would use mutexes instead of barriers.
Not really they
At 02:08 PM 2/15/2001 -0800, Hong Zhang wrote:
> > Hong Zhang wrote:
> >
> > > This code should NEVER work, period. People will just ask for trouble
> > > with this kind of code.
> >
> > Actually I meant to have specified ">>" as the mode, i.e. append, then
> > what I originally said holds true.
Hong Zhang wrote:
> The memory barriers are always needed on SMP, whatever algorithm
> we are using.
I was just pointing out that barriers are an alternative to mutexes.
Ref count certainly would use mutexes instead of barriers.
> The memory barrier can be easily coded in assembly, or intrinsic
David Mitchell wrote:
> To get my head round PDD 2, I've just written the the outline
> for the body of the add() method for a hypophetical integer PMC class:
[... lots of complex code ...]
I think this example is a good reason to consider only having one
argument math ops. Instead of dst->add(a
Damien Neil wrote:
DN> {
DN>my $fh = IO::File->new("file");
DN>do_stuff($fh);
DN> }
DN>
DN> sub do_stuff { ... }
Simon Cozens wrote:
SC> No, it can't, but it can certainly put a *test* for not having
SC> references there.
Dan Sugalski wrote:
DS> Yes it can tell, actually--we do have the
> There are several concurrent GC algorithms that don't use
> mutexes -- but they usually depend on read or write barriers
> which may be really hard for us to implement. Making them run
> well always requires help from the OS memory manager and that
> would hurt portability. (If we don't have OS
> ...and because of this you can't randomly access the string, you are
> reduced to sequential access (*). And here I thought we could have
> left tape drives to the last millennium.
>
> (*) Yes, of course you could cache your sequential access so you only
> need to do it once, and build balance
Alan Burlison wrote:
> I think you'll find that both GC *and* reference counting scheme will
> require the heay use of mutexes in a MT program.
There are several concurrent GC algorithms that don't use
mutexes -- but they usually depend on read or write barriers
which may be really hard for us to
> On Thu, Feb 15, 2001 at 03:59:54PM -0800, Hong Zhang wrote:
> > The concept of characters have nothing to do with codepoints.
> > Many characters are composed by more than one codepoints.
>
> This isn't true.
What do you mean? Have you seen people using multi-byte encoding
in Japan/China/Korea
On Thu, Feb 15, 2001 at 03:59:54PM -0800, Hong Zhang wrote:
> The concept of characters have nothing to do with codepoints.
> Many characters are composed by more than one codepoints.
This isn't true.
--
* DrForr digs around for a fresh IV drip bag and proceeds to hook up.
Coffee port.
Firewa
On Thu, Feb 15, 2001 at 11:16:29PM +, Simon Cozens wrote:
> On Thu, Feb 15, 2001 at 02:31:03PM -0800, Hong Zhang wrote:
> > Personally I like the UTF-8 encoding. The solution to the
> > variable length can be handled by a special (virtual)
> > function like
>
> I'm expecting that the virtual,
> On Thu, Feb 15, 2001 at 02:31:03PM -0800, Hong Zhang wrote:
> > Personally I like the UTF-8 encoding. The solution to the
> > variable length can be handled by a special (virtual)
> > function like
>
> I'm expecting that the virtual, internal representation will not
> be in a UTF but will simpl
On Thu, Feb 15, 2001 at 02:31:03PM -0800, Hong Zhang wrote:
> Personally I like the UTF-8 encoding. The solution to the
> variable length can be handled by a special (virtual)
> function like
I'm expecting that the virtual, internal representation will not
be in a UTF but will simply be an array
> > http://news.bbc.co.uk/hi/english/sci/tech/newsid_1156000/1156212.stm
This nuclear/dynamite stuff is making me sad.
Wanna contribute in the name of perl ?? Lets see... China + UN = $perl_revenue
Hi, All,
I want to give some of my thougts about string encoding.
Personally I like the UTF-8 encoding. The solution to the
variable length can be handled by a special (virtual)
function like
class String {
virtual UV iterate(/*inout*/ int* index);
};
So in typical string iteration, the co
Hong Zhang wrote:
> That was not what I meant. Your code already assume the existence of
> reference counting. It does not work well with any other kind of garbage
> collection. If you translate the same code into C without putting in
> the close(), the code will not work at all.
Wrong, it does
> Hong Zhang wrote:
>
> > This code should NEVER work, period. People will just ask for trouble
> > with this kind of code.
>
> Actually I meant to have specified ">>" as the mode, i.e. append, then
> what I originally said holds true. This behaviour is predictable and
> dependable in the curre
Hong Zhang wrote:
> This code should NEVER work, period. People will just ask for trouble
> with this kind of code.
Actually I meant to have specified ">>" as the mode, i.e. append, then
what I originally said holds true. This behaviour is predictable and
dependable in the current perl implemen
> {
> my $fh = IO::File->new("file");
> print $fh "foo\n";
> }
> {
> my $fh = IO::File->new("file");
> print $fh "bar\n";
> }
>
> At present "file" will contain "foo\nbar\n". Without DF it could just
> as well be "bar\nfoo\n". Make no mistake, this is a major change to t
Branden wrote:
> Just set autoflush, if you're lazy...
And say goodbye to performance...
> > The problem is
> > that you can not only count on $fh's DESTROY being called at the end of
> > the block, you often can't count on it ever happening.
>
> Anyway, the file would be flushed and closed...
> "TB" == Tim Bunce <[EMAIL PROTECTED]> writes:
TB> As a part of that the weak reference concept, bolted recently into
TB> perl5, could be made more central in perl6.
TB> Around 92.769% of the time circular references are known to be
TB> circular by the code that creates them (like a
Damien Neil wrote:
> On Thu, Feb 15, 2001 at 08:07:39AM -0300, Branden wrote:
> > I think you just said all about why we shouldn't bother giving objects
> > deterministic finalization, and I agree with you. If we explicitly want
to
> > free resources (files, database connections), then we explicit
On Thu, Feb 15, 2001 at 08:07:39AM -0300, Branden wrote:
> I think you just said all about why we shouldn't bother giving objects
> deterministic finalization, and I agree with you. If we explicitly want to
> free resources (files, database connections), then we explicitly call close.
> Otherwise,
To get my head round PDD 2, I've just written the the outline
for the body of the add() method for a hypophetical integer PMC class:
chiefly to get a feel for how it needs to handle all the various
permutations, like whether the destination pmc is trashable etc.
Could you Wise Ones tell me whethe
Tim Bunce wrote:
> On Thu, Feb 15, 2001 at 08:21:03AM -0300, Branden wrote:
> > And don't forget that if we stick with refcounting, we should try to
find a
> > way to break circular references, too.
>
> As a part of that the weak reference concept, bolted recently into perl5,
> could be made more
On Thu, Feb 15, 2001 at 08:21:03AM -0300, Branden wrote:
> Hong Zhang
> > > A deterministic finalization means we shouldn't need to force
> programmers
> > > to have good ideas. Make it easy, remember? :)
> >
> > I don't believe such an algorithm exists, unless you stick with reference
> > count.
Hong Zhang
> > A deterministic finalization means we shouldn't need to force
programmers
> > to have good ideas. Make it easy, remember? :)
>
> I don't believe such an algorithm exists, unless you stick with reference
> count.
>
Either doesn't exist, or is more expensive than refcounting. I guess
Damien Neil wrote:
> Using object lifetime to control state is almost never a good idea,
> even if you have deterministic finalization. A much better approach
> is to have methods which allow holders of the object to control it,
> and a finalizer (DESTROY method) which cleans up only if necessary
29 matches
Mail list logo
