>
> On Sat, 10 Feb 2001, Branden wrote:
>
> > Suppose I have a string stored in $foo, say, "abcbca", and then I do:
> >
> > $bar = $foo;
> > $foo .= "xyzyzx";
> >
> > I see two ways of doing this: one is allowing a string value to be shared by
> > two or more variables, and the other on
On Sat, 10 Feb 2001, Buddha M Buck wrote:
> I think what he's thinking (in C terms) would be more like the following:
Right. It already has a technical name - copy-on-write. I should have
made it more clear that I recognized the intended mechanism. I was trying
to demonstrate that Perl-level
On Sat, 10 Feb 2001, Branden wrote:
> Suppose I have a string stored in $foo, say, "abcbca", and then I do:
>
> $bar = $foo;
> $foo .= "xyzyzx";
>
> I see two ways of doing this: one is allowing a string value to be shared by
> two or more variables, and the other one not.
Why would you
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, Feb 09, 2001 at 06:17:19PM -0500, Eric S. Raymond wrote:
> The obvious and cutting rejoinder for me to make would be:
> "Hey. If I believed this, I'd still be writing Perl."
Don't look now, but your bias is showing. :)
> What *is* going on over there, anyway? It is unfortunately t
Back to the GC issue, I was wondering something.
Suppose I have a string stored in $foo, say, "abcbca", and then I do:
$bar = $foo;
$foo .= "xyzyzx";
I see two ways of doing this: one is allowing a string value to be shared by
two or more variables, and the other one not.
If I allow s
On Fri, 9 Feb 2001, Eric S. Raymond wrote:
[...]
> minimalism) and I tried to, but there was some kind of ugly technical
> snafu with Skud's listserv and I couldn't get signed on.
listserv? We use ezmlm around here. :) If you still want to join in
then look at http://dev.perl.org/ - http://dev.p
> Eric Raymond's book-in-development ``The Art of Unix Programming'' says
> this about the future of Perl:
>> Perl usage has grown respectably, but the language itself has been stagnant
>> for two years or more.
> Bah. Looks like my Perl5-Porters summaries have been completely in vain. :)
yeah,
Dan Sugalski <[EMAIL PROTECTED]>:
> Yes, but you see, we're not generating code. All the rest of the stuff is
> irrelevant, and Real Hackers don't need to design--it's all self-evident.
> Besides, you only need to design if you're building one of those Cathedral
> thingies, and we all know how
> 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
At 07:06 PM 2/9/2001 +, Simon Cozens wrote:
> > Perl's internals are notoriously grubby; it's been understood for years
> that
> > the language's implementation needs to be rewritten from scratch, but an
> > attempt in 1999 failed and another seems presently stalled.
>
>If that other is Perl
On Friday 09 February 2001 14:06, Simon Cozens wrote:
> I'm not sure "stagnant" is the best choice of word to describe that.
It used to be that feeping creaturism was the scourge - folks clamoring for
a little stability in their tools and products. Now it seems what was once
"stability" is now
"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
Eric Raymond's book-in-development ``The Art of Unix Programming'' says
this about the future of Perl:
> Perl usage has grown respectably, but the language itself has been stagnant
> for two years or more.
Bah. Looks like my Perl5-Porters summaries have been completely in vain. :)
The past two
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 09:56 AM 2/9/2001 -0200, Branden wrote:
>Jarkko Hietaniemi wrote:
> > > Umm, one way or another I suspect UTF-8 will be in there.
> >
> > I suspect so too but very grudgingly. As Dan said dealing with
> > variable length data is a major pain. UTF-8 is certainly a much
> > better designed VLD
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
Joshua N Pritikin wrote:
> On Fri, Feb 09, 2001 at 02:13:46PM -0200, [EMAIL PROTECTED] wrote:
> > Could you be more specific about your intents about that language? Do
you
> > have more information about it (some interesting syntax, or some scripts
> > that could inspire new features or interestin
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 02:13:46PM -0200, [EMAIL PROTECTED] wrote:
> Joshua N Pritikin wrote:
> > Well yah! Perl6 array indeed. It also reminds me of PDL. i like the
> > data model. It looks like FAME done right.
>
> Are you suggesting we borrow some features of it? Take some inspiration on
>
At 10:49 AM 2/9/2001 -0500, Joshua N Pritikin wrote:
>On Fri, Feb 09, 2001 at 10:16:22AM -0500, [EMAIL PROTECTED] wrote:
> > At 09:36 AM 2/9/2001 -0500, Joshua N Pritikin wrote:
> > >Does everyone already know about www.kx.com ?
> >
> > What about it? Looks like yet another semi-specialized relati
On Fri, Feb 09, 2001 at 01:51:02PM -0200, [EMAIL PROTECTED] wrote:
> Joshua N Pritikin wrote:
> > Does everyone already know about www.kx.com ?
>
> Well, I found Kdb nothing awesome... The K language I thought it's a
> somewhat interesting, specially the part on "bulk operators", which I think
>
Joshua N Pritikin wrote:
> Does everyone already know about www.kx.com ?
>
Well, I found Kdb nothing awesome... The K language I thought it's a
somewhat interesting, specially the part on "bulk operators", which I think
is the same that is intended to do with Perl 6 arrays (@a + @b). And an
abstr
Joshua N Pritikin wrote:
> On Fri, Feb 09, 2001 at 01:51:02PM -0200, [EMAIL PROTECTED] wrote:
> > Well, I found Kdb nothing awesome... The K language I thought it's a
> > somewhat interesting, specially the part on "bulk operators", which I
think
> > is the same that is intended to do with Perl 6
Joshua N Pritikin wrote:
> On Fri, Feb 09, 2001 at 10:16:22AM -0500, [EMAIL PROTECTED] wrote:
> > At 09:36 AM 2/9/2001 -0500, Joshua N Pritikin wrote:
> > >Does everyone already know about www.kx.com ?
> >
> > What about it? Looks like yet another semi-specialized relational
database
> > company.
On Fri, Feb 09, 2001 at 10:16:22AM -0500, [EMAIL PROTECTED] wrote:
> At 09:36 AM 2/9/2001 -0500, Joshua N Pritikin wrote:
> >Does everyone already know about www.kx.com ?
>
> What about it? Looks like yet another semi-specialized relational database
> company. (With a far too clever website)
Am
Self-referencing definitions - it's a bit like time travel.
This was originally submitted back in December, but I never saw it show up,
and didn't see it in the archives, so I'm going to throw it to the meta
list for hacking before there are a slew of PDDs floating around.
(I'm withholding the
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
At 09:36 AM 2/9/2001 -0500, Joshua N Pritikin wrote:
>Does everyone already know about www.kx.com ?
What about it? Looks like yet another semi-specialized relational database
company. (With a far too clever website)
Dan
--
Does everyone already know about www.kx.com ?
--
May the best description of competition prevail.
(via, but not speaking for Deutsche Bank)
Hi.
This was posted on -language about packaging scripts/modules in a kind of a
zip file, for easy automated installing. This issue was brought up:
Branden wrote:
> Nicholas Clark wrote:
> > on perl 5 different configure options generate different binaries.
>
> Can this be standardized somehow?
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
Jarkko Hietaniemi wrote:
> > Umm, one way or another I suspect UTF-8 will be in there.
>
> I suspect so too but very grudgingly. As Dan said dealing with
> variable length data is a major pain. UTF-8 is certainly a much
> better designed VLD than most but it's still a pain.
>
I guess that's why
On Thu, Feb 08, 2001 at 09:55:17PM -0600, Jarkko Hietaniemi wrote:
> > Umm, one way or another I suspect UTF-8 will be in there.
>
> I suspect so too but very grudgingly.
If we abstract the string handling nicely, it can be added on later or even
separately. (Credo: We don't have to write all of
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
76 matches
Mail list logo
