On Thu, 8 Feb 2001 17:39:01 +, Nicholas Clark wrote:
On Thu, Feb 08, 2001 at 12:26:59PM -0500, Dan Sugalski wrote:
(Including Archive::Tar as part of the base perl distribution's not
inappropriate, assuming we can get permission. )
Since it's already part of the "standard distribution"
On Thu, 8 Feb 2001 17:49:45 -0200, Branden wrote:
I've never actually used PPM, only read about it in
the web. I guess their file format is a disguised .tar.gz, right?
It's a combination of an XML file, file extension "PPD", which describes
the properties and dependencies, and platforms, and a
On Thu, Feb 08, 2001 at 01:40:52PM -0500, Dan Sugalski wrote:
Seperated documentation is no documentation.
At some point things are going to get split out, unless you wedge the docs
into the actual program itself. (You were, after all, talking about config
files and XS modules, and those
Clayton Scott wrote:
PPM uses files containing a modified form of the Open Software
Distribution (OSD) specification for information about software
packages. These description files, which are written in Extensible
Markup Language (XML) code, are referred to as 'PPD' files.
Information
Nicholas Clark wrote:
I take it "Lunix" is Linux.
BSDi isn't FreeBSD, NetBSD or OpenBSD
Nothing they list seems to be VMS
Pace are still developing variants of Acorn's RISC OS to run set top boxes
As I understood it there were about 39 variants of Unix ever, and they
seem
to have 12 listed.
On Fri, Feb 09, 2001 at 10:28:49AM -0200, Branden wrote:
Other important issue I don't know yet: Is there an Archive::Zip module for
Perl? How cross-platform is it? Can we bundle it with Perl (licensing
issues)? Is it stable? Will it give us the support we need (access to
individual files in
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 fast
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
We're having a blizzard in Kansas City. After breakfasting, changing
the litter box, and hiking to work through the snow, I am finally
looking at Conway's RFC 271. Guess which one of the earlier
activites it reminds me of.
I agree with Branden that the inheritance semantics is screwy.
I think
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, data.
I had the time to do a research in Internet about rpm/jar. The correct URLs
are:
* http://www.rpm.org
* http://java.sun.com/products/jdk/1.1/docs/guide/jar/
I found great utilitaries in http://www.rpm.org/software.html, we could
probably steal some of them for `par'. I found out that most of
On Fri, Feb 09, 2001 at 06:17:34PM -0200, Branden wrote:
I had the time to do a research in Internet about rpm/jar. The correct URLs
are:
* http://www.rpm.org
* http://java.sun.com/products/jdk/1.1/docs/guide/jar/
I found great utilitaries in http://www.rpm.org/software.html, we could
Branden wrote:
If object validity checking were incorporated int Cbless the customary
return of an object
[snip]
I don't think I quite understood you. Are you thinking `new' is the only one
that would have pre/post to validate arguments? Actually every method call
would
Jarkko Hietaniemi wrote:
Whatever we do I would much prefer being package format agnostic
instead of tying ourselves too tightly with some single format.
Any ideas on how to do that? Without breaking requirements?
I actually agree that being able to use tgz is good, and better compression
Johan Vromans wrote:
Would the POST be executed if the open fails? Why? Why not?
sub readit {
POST {
close F;
}
open F, " $f" or die;
scalar(F)
}
Yes, because the flow of control passed it before the
On Fri, Feb 09, 2001 at 06:46:26PM -0200, Branden wrote:
Jarkko Hietaniemi wrote:
Whatever we do I would much prefer being package format agnostic
instead of tying ourselves too tightly with some single format.
Any ideas on how to do that? Without breaking requirements?
There isn't a
Jarkko Hietaniemi wrote:
There isn't a software problem another abstraction layer can't fix...
"...except the problem of too many layers of abstraction". tchrist
(for those of you who didn't get the reference)
--
John Porter
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 reachable,
Branden wrote:
For example, with tgz it would be complex to deal
with running without extracting,
What? tar -z not good enough for you?
... than have too much flexibility and end up with some distribution
problems (like `oh! I don't have bzip2 and the developper only supplied a
bzip2
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
On Fri, Feb 09, 2001 at 04:05:54PM -0500, John Porter wrote:
Jarkko Hietaniemi wrote:
There isn't a software problem another abstraction layer can't fix...
"...except the problem of too many layers of abstraction". tchrist
(for those of you who didn't get the reference)
Well, I
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 ratio
On Fri, Feb 09, 2001 at 04:07:51PM -0500, John Porter wrote:
Branden wrote:
For example, with tgz it would be complex to deal
with running without extracting,
What? tar -z not good enough for you?
I believe that that wognt work ugnless you have gnu tar.
"Get New Utilities" as I've
On Fri, Feb 09, 2001 at 04:09:28PM -0500, John Porter wrote:
Jarkko Hietaniemi wrote:
(for those of you who didn't get the reference)
Well, I certainly heard the reference before even hearing of Perl or Tom...
I only ever saw it with his name on it.
I believe the first part of it
At 11:32 AM 2/9/2001 -0200, Branden wrote:
Nicholas Clark wrote:
that I really don't know: in the same platform, different compilers
generate
incompatible binaries? Because if this happens (and will still happen
on
Perl 6) the platform identification should be os/cpu/compiler. Perhaps
At 09:42 AM 2/9/2001 +, Michael G Schwern wrote:
On Thu, Feb 08, 2001 at 01:40:52PM -0500, Dan Sugalski wrote:
Seperated documentation is no documentation.
At some point things are going to get split out, unless you wedge the docs
into the actual program itself. (You were, after all,
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 per
On Fri, Feb 09, 2001 at 02:53:43PM -0600, Jarkko Hietaniemi wrote:
On Fri, Feb 09, 2001 at 06:46:26PM -0200, Branden wrote:
problems (like `oh! I don't have bzip2 and the developper only supplied a
bzip2 version of the archive', or `oh! I'll have to do zip, tgz, bzip2,
whatever3 versions
On Fri, Feb 09, 2001 at 09:18:55PM +, Nicholas Clark wrote:
On Fri, Feb 09, 2001 at 04:07:51PM -0500, John Porter wrote:
Branden wrote:
For example, with tgz it would be complex to deal
with running without extracting,
What? tar -z not good enough for you?
I believe
On Fri, Feb 09, 2001 at 09:22:13PM +, Nicholas Clark wrote:
On Fri, Feb 09, 2001 at 02:53:43PM -0600, Jarkko Hietaniemi wrote:
On Fri, Feb 09, 2001 at 06:46:26PM -0200, Branden wrote:
problems (like `oh! I don't have bzip2 and the developper only supplied a
bzip2 version of the
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?
Correct.
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 garbage
On Fri, Feb 09, 2001 at 09:22:13PM +, Nicholas Clark wrote:
Code to do unzip (yes, even including the whole of zlib just like gcc,
xfree86 and several other things I can't remember offhand that irritate
me as I have libz.so) is small enough to go in the perl core if needed.
Even after
"David L. Nicol" wrote:
# with POST
sub find_first_line_matching_array($\@){
open F, shift or die "could not open: $!";
POST{close F};
while(F){
foreach $w (@{$_[0]}){
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; return
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 memory of %baz
36 matches
Mail list logo
