RT GC [WAS Re: Bad programming considered harmless]
On Mon, 5 Feb 2001, Paul Makepeace wrote:
> On Mon, Feb 05, 2001 at 10:42:08PM +0000, Shevek wrote:
> > I later prove that it is possible to do a hard real time reference
> > counting garbage collector,
>
> I've heard of implementations of hard real time GCs but they're
> ultra-slow. Can you prove one comparably as fast as a non-real
> time one is possible? Constant factors are killers :-)
>
> Paul
Oh yes :-) But allocation is N time for a block size N, and memory
overhead is one pointer per block. I implemented it for cons cells, it was
beautiful, but one pointer per cons is a lot. However, it was hard real
time.
S.
--
Shevek
I am the Borg.
sub AUTOLOAD { ($s=$AUTOLOAD)=~s/.*:://; eval qq{ *$AUTOLOAD=$s
?sub {$s*&{$s-1}} :sub {1}; }; goto &$AUTOLOAD; } print &{'4'};
Re: Bad programming considered harmless
On Mon, 5 Feb 2001, Mark Fowler wrote:
> As for the real time nature of garbage collectors, Shevek and I (and some
> others) wrote a paper together on this, so I could say a lot here.
> Especially about how Perl is much more real time as it can do better at
> allocating and deallocating the same bit of memory (as it instantly
> knows when memory is free, unlike mark and sweep) and is a lot less likely
> to cause page faults. Of course, reference counting suffers from the
> dreaded deep free problem so if you don't program carefully you can very
I later prove that it is possible to do a hard real time reference
counting garbage collector, without the deep free problem, and without a
fallback mark and sweep. However, the other problems, including reference
cycles, still exist. Allocation time could be time proportional to the
requested region size, but that's fine as you can control allocation.
> very easily shoot yourself in the time constraint foot too.
Didn't we also manage mark and sweep in something approximating real time
with a high enough hard constant? I've been looking at a lot more systems
since then, region inference is interesting. You can free data which isn't
actually unreferenced. :-) Scary.
S.
--
Shevek
I am the Borg.
sub AUTOLOAD { ($s=$AUTOLOAD)=~s/.*:://; eval qq{ *$AUTOLOAD=$s
?sub {$s*&{$s-1}} :sub {1}; }; goto &$AUTOLOAD; } print &{'4'};
Re: PIMB T-shirts
It's been done. But go for it.
http://www.uiowa.edu/~commstud/adclass/camel/images/motorcycle.jpg
(http://www.uiowa.edu/~commstud/adclass/camel/JoeCool.html)
S.
On Tue, 16 Jan 2001, Alex Page wrote:
> On Tue, Jan 16, 2001 at 12:59:44PM +, Redvers Davies wrote:
>
> > There is a temptation to insert a joint into the mouth of the "Republic of
> > Perl" camel. Of course this would never happen[1].
>
> > [1] Something tells me that would have to be a trademark thing that O'Reilly
> > would protect.
>
> IANAL, but AFAIK parody is protected under trademark law, as long as you're not
>making profit (I presume beer money for the hassle of T-shirt making is excusable).
>
> Alex
>
--
Shevek
I am the Borg.
sub AUTOLOAD { ($s=$AUTOLOAD)=~s/.*:://; eval qq{ *$AUTOLOAD=$s
?sub {$s*&{$s-1}} :sub {1}; }; goto &$AUTOLOAD; } print &{'4'};
[OT] WTD: P2/400 CPU
Does anyone have a P2/400MHz CPU available (near Farringdon) at start of
play this morning? A server's just freaked one and is going to need one
pretty damn soon. This is if CEX don't have any in stock.
Ta.
S.
--
Shevek
I am the Borg.
sub AUTOLOAD { ($s=$AUTOLOAD)=~s/.*:://; eval qq{ *$AUTOLOAD=$s
?sub {$s*&{$s-1}} :sub {1}; }; goto &$AUTOLOAD; } print &{'4'};
Re: Mailman in Perl (Re: the list is dead, long live the list)
On Sun, 14 Jan 2001, David Cantrell wrote:
> rely on RPMs. The real reason I haven't switched is because it's really
> *nasty* trying to switch from one distro to another without a) losing
> valuable config data and b) ending up with a ton of unused junk on the disk
> which is nigh-on impossible to tell apart from stuff that's in use.
I had always committed to the nature of Unix being that one does end up
with a pile of stuff on disk which one doesn't use. The point is that this
doesn't matter. Unless you're upgrading something every day or every week,
the junk pile-up on a production server won't do much more than double or
treble the hard disk usage of the OS, which will be small compared to the
user data, and is still in a small order of magnitude.
I bet you have libc5 and libc6 installed...
It's still smaller than win2k...
S.
--
Shevek
I am the Borg.
sub AUTOLOAD { ($s=$AUTOLOAD)=~s/.*:://; eval qq{ *$AUTOLOAD=$s
?sub {$s*&{$s-1}} :sub {1}; }; goto &$AUTOLOAD; } print &{'4'};
Re: Directory Structures!
Am I right, now I look again, in thinking this can't be done as it
requires that every value be simultaneously a list and a hash? Maybe if
you tied things.
On Wed, 10 Jan 2001, Andy Williams wrote:
> $dirstruct{"mydir"}->{dir1}->{dir2}->["A.A","B.B"]
> $dirstruct{"mydir"}->{dir1}->{dir3}->{dir4}->["C.C","D.D"]
> $dirstruct{"mydir"}->{dir4}->{dir5}->["E.E"]
--
Shevek
I am the Borg.
sub AUTOLOAD { ($s=$AUTOLOAD)=~s/.*:://; eval qq{ *$AUTOLOAD=$s
?sub {$s*&{$s-1}} :sub {1}; }; goto &$AUTOLOAD; } print &{'4'};
Re: Directory to Data Structure
Something like:
{
local $"="'}->{'";
my $file = pop(@fp);
eval qq{push(\@{\$dirstruct{'@fp'}}, $file)};
}
Not as good as it might be.
On Wed, 10 Jan 2001, Andy Williams wrote:
> Hi
>
> I'm using File::Find to recursively get all the files from a directory
> structure, then splitting each $File::Find::name into an array.
> What I need to do is put this into a data structure like:
> $dirstruct{"mydir"}->{dir1}->{dir2}->["A.A","B.B"]
> $dirstruct{"mydir"}->{dir1}->{dir3}->{dir4}->["C.C","D.D"]
> $dirstruct{"mydir"}->{dir4}->{dir5}->["E.E"]
> The directory listing would be:
> /dir1/dir2/A.A
> /dir1/dir2/B.B
> /dir1/dir3/dir4/C.C
> /dir1/dir3/dir4/D.D
> /dir4/dir5/E.E
>
> I know I've done this before, but I'll be damned if I can find it or
> remember how I did it.
>
>
> my $directory = '\\gbu'; # Sorry it's on Windows!
>
> find(\&getfiles, $directory);
>
> getfiles($directory);
>
> sub getfiles {
> my $file = $File::Find::name;
> return if (! $file);
> if (-f $file) {
> $file =~ s/^\\//g;
> my @fp = split(/\//,$file);
> # Somehow need to get this into %DIRSTRUCT!!
> ...
> }
> }
>
>
> Please Help!
>
> TIA
>
> Andy
>
>
>
> "This sounds like a twelve-change-of-underwear trip."
>
>
>
>
--
Shevek
I am the Borg.
sub AUTOLOAD { ($s=$AUTOLOAD)=~s/.*:://; eval qq{ *$AUTOLOAD=$s
?sub {$s*&{$s-1}} :sub {1}; }; goto &$AUTOLOAD; } print &{'4'};
Re: one liner
On Mon, 8 Jan 2001, Michael Stevens wrote:
> I'm sure there are reasonable number of online manuals we'd all like
> printed copies of.
>
> Maybe we should see about costs for getting some of them printed fairly
> nicely and bound.
I think the uni offers such a service here.
--
Shevek
I am the Borg.
sub AUTOLOAD { ($s=$AUTOLOAD)=~s/.*:://; eval qq{ *$AUTOLOAD=$s
?sub {$s*&{$s-1}} :sub {1}; }; goto &$AUTOLOAD; } print &{'4'};
Re: Technical Meeting
On Fri, 5 Jan 2001, Andy Wardley wrote:
>Camelot
> An experimental Web Application Framework which makes (most) other
> so-called "Web Application Frameworks" look like a really silly
> idea. Br! That's chilly.
Naturally, this tempts me.
--
Shevek
I am the Borg.
sub AUTOLOAD { ($s=$AUTOLOAD)=~s/.*:://; eval qq{ *$AUTOLOAD=$s
?sub {$s*&{$s-1}} :sub {1}; }; goto &$AUTOLOAD; } print &{'4'};
Teaching Java and Perl
On Sat, 6 Jan 2001, Dean S Wilson wrote:
> I think that marketing is the key term in this mail. Java has a good
> marketing team and is being taught in universities at the moment,
> nothing better than having a lot of fresh faced advocates being
> spawned at the end of each term.
Having taught both, I can say that I would far rather teach undergraduates
Java for many reasons. In fact, they'd probably be better learning
something even more restrictive and more trivial. That doesn't make it
good.
--
Shevek
I am the Borg.
sub AUTOLOAD { ($s=$AUTOLOAD)=~s/.*:://; eval qq{ *$AUTOLOAD=$s
?sub {$s*&{$s-1}} :sub {1}; }; goto &$AUTOLOAD; } print &{'4'};
Re: Getting keys of mappe @list = qw/foo bar foo baz/;d hash?
On 4 Jan 2001, Piers Cawley wrote:
> Tony Bowden <[EMAIL PROTECTED]> writes:
>
> > On Wed, Jan 03, 2001 at 11:16:06AM +, Piers Cawley wrote:
> > > > How can I do this:
> > > > my @list = qw/foo bar foo baz/;
> > > > my %hash = map { $_ => 1 } @men;
> > > > my @sort = sort keys %hash;
> > > > print "We have @sort\n"; # foo bar baz
> > > > without the %hash?
> >
> > > my $last;
> > > do {print $_ unless $_ eq $last; $last = $_} for sort @list
> > > Dunno if it's quicker than the cunning tricks with map, but hey, it
> > > works.
> >
> > Ah, but my question was badly phrased. I needed to end up with @sort, not
> > a printed list ...
>
> Ah:
>
> do {push(@sorted, $_) unless $_ eq $last; $last = $_} for sort @list;
>
> Can't be bothered to benchmark it...
This would be very slow for the dutch national flag, as it sorts the large
list rather than the small one.
S.
--
Shevek
I am the Borg.
sub AUTOLOAD { ($s=$AUTOLOAD)=~s/.*:://; eval qq{ *$AUTOLOAD=$s
?sub {$s*&{$s-1}} :sub {1}; }; goto &$AUTOLOAD; } print &{'4'};
Re: Getting keys of mapped hash?
On Tue, 2 Jan 2001, Peter Corlett wrote:
> On Sat, Dec 30, 2000 at 06:35:18PM +, Tony Bowden wrote:
> > i.e. something akin to: my @sort = sort keys map { $_ => 1 } @list;
>
> I'm thinking that this might work:
>
> my @sort=sort keys %{ +{ map { $_ => undef } @list } };
Maybe I'm missing something here, but how is this different to
my @sort = sort @list;
?
S.
--
Shevek
I am the Borg.
sub AUTOLOAD { ($s=$AUTOLOAD)=~s/.*:://; eval qq{ *$AUTOLOAD=$s
?sub {$s*&{$s-1}} :sub {1}; }; goto &$AUTOLOAD; } print &{'4'};
