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
On Fri, 9 Feb 2001 21:18:55 +, Nicholas Clark wrote:
>> What? tar -z not good enough for you?
>
>I believe that that wognt work ugnless you have gnu tar.
As a Windows user, I should add:
* Archive::Tar is part of the Perl 5.6.0 distributions for Win32
(Activestate and IndigoPerl)
* On a
"David L. Nicol" wrote:
> # with POST
> sub find_first_line_matching_array($\@){
> open F, shift or die "could not open: $!";
> POST{close F};
> while(){
> foreach $w (@{$_[0]}){
>
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
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 aft
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
On Fri, Feb 09, 2001 at 03:25:42PM -0600, Jarkko Hietaniemi wrote:
> I assume the next logical thing to add would be MD5?
Yes, well before zip (IMHO). It would make CPAN.pm a happy bunny, and should
make the world (feel) more secure.
This is now really perl5 isn't it?
Nicholas Clark
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 t
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?
>
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 vers
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
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, af
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
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 firs
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"
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
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.
So if he didn't coin it, then I think he "appropriated" it...
--
John Porter
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,
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
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
> b
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
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
[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 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 i
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()
>}
Yes, because the flow of control passed it before the
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
Branden wrote:
> >
> > If object validity checking were incorporated int C 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 po
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 co
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 the
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%
David L. Nicol wrote:
> 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'm in really doubt... Breakfasting? ;
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
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
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
This is the alpha version of the PDD about archives. I actually didn't have
the time to format it as a POD, and probably won't have the time to do it
until Monday, I don't even think I'll have time to check the lists on the
weekend. Nevertheless, I'm sending it on mail-message format for your
appr
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
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
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 li
I wrote:
> David L. Nicol wrote:
> > sub DirectBubbleSort() {
> > my ($i,$t) = (-1,0);
> > while (++$i <= $#$__) {
> > $$__[$i] > $$__[1+$i] and $t++ and @$__[$i,1+$i] = @$__[1+$i,$i];
> > };
> > $t and @$__ = DirectBubbleSort;
> > }
> >
> > @SomeList = DirectBubbleSort; # instead of D
On Fri, Feb 09, 2001 at 10:28:49AM -0200, Branden wrote:
> In http://www.w3.org/TR/NOTE-OSD.html#B they describe platform/cpu standard
> names, and we'll definetly need those for checking target architecture. Can
> we standardize upon those, or there's something missing? There's an issue
I take i
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.
> Informat
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 t
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, 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 distributio
50 matches
Mail list logo
