On Sunday 11 February 2001 22:48, Jan Dubois wrote:
Doing full GC in this fashion after failed API calls will probably wipe
out any performance gain mark-and-sweep has over reference counting.
Well, after select failed API calls, not every call. And mark-and-sweep,
if that's the GC scheme
On Fri, Feb 09, 2001 at 04:15:42PM -0500, Dan Sugalski wrote:
On the other side, for a string that is matched against regexps, it doesn't
matter much if it has variable character length, since regexps normally read
all the string anyway, and indexing characters isn't much of a concern.
[moved to -internals]
On Mon, 12 Feb 2001 01:44:54 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Perl needs some level of tracking for objects with finalization attached to
them. Full refcounting isn't required, however. Also, the vast majority of
perl variables have no finalization attached
gentlemen (a small liberty, i admit) -
all of this *pointless* debate could be set aside - if all of you
would just renounce perl - and adopt ruby as your language
it's why larry has shut himself up in silence - feigning illness:
*true (not bolted-on) oo language
*modern (not
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?
The problem is that we cannot access individual files inside the archive
without decompressing the whole archive, what is
On Mon, Feb 12, 2001 at 12:36:53PM -0300, Branden wrote:
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?
The problem is that we cannot access individual files inside
On Monday 12 February 2001 10:36, Branden wrote:
The problem is that we cannot access individual files inside the archive
without decompressing the whole archive, what is possible with .tar (not
..gz) and .zip. Then we can assign a perl filehandle to access a file from
inside the archive and
Bart Lateur wrote:
On Fri, 9 Feb 2001 21:18:55 +, Nicholas Clark wrote:
* Archive::Tar is part of the Perl 5.6.0 distributions for Win32
(Activestate and IndigoPerl)
* And I'd like the normal module distributions on CPAN to still work.
Those are all .tar.gz.
I actually don't
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
The
Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
Also, the vast majority of perl variables have no finalization
attached to them.
That's true, but without static typing don't you have to treat them as if
they did? At the very least you need to do a "is it an object with a
Bryan C. Warnock wrote:
Is that '.tar and .zip' as in '.tar and .zip' or '.tar or .zip'?
.tar or .zip
Aren't most tars still unindexed, requiring a full file scan anyway?
That was one I was not aware of... One more reason to use .zip!
Hey, .tgz people... Java's jar has used .zip as its
Jarkko Hietaniemi wrote:
On Mon, Feb 12, 2001 at 12:36:53PM -0300, Branden wrote:
The problem is that we cannot access individual files inside the archive
without decompressing the whole archive, what is possible with .tar (not
I do not see a huge problem in decompressing the whole archive
Jan Dubois wrote:
On Mon, 12 Feb 2001 01:44:54 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Perl needs some level of tracking for objects with finalization attached
to
them. Full refcounting isn't required, however. Also, the vast majority
of
perl variables have no finalization attached to
On Monday 12 February 2001 12:40, Branden wrote:
Probably Perl 6 programs will be cached/distributed in optimized byte code
format.
I'm not sure about the leading 'probably'. Perl 6 programs will most likely
be like most other open-source programs in other languages - either source,
which
On Mon, 12 Feb 2001 16:13:10 +, Simon Cozens [EMAIL PROTECTED] wrote:
How much can we do in the compiler, and how much can we do in the
interpreter? If we're having cached bytecode, it makes sense to do
as much optimization as we can in the compiler. If not, we might
as well brute force
At 01:45 PM 02-12-2001 -0300, Branden wrote:
I think having both copying-GC and refcounting-GC is a good idea. I may be
saying a stupid thing, since I'm not a GC expert, but I think objects that
rely on having their destructors called the soonest possible for resource
cleanup could use a
Simon Cozens wrote:
How much can we do in the compiler, and how much can we do in the
interpreter? If we're having cached bytecode, it makes sense to do
as much optimization as we can in the compiler.
I thought, by PDD 1
(http:[EMAIL PROTECTED]/msg02116.html), it
was:
SOURCE CODE
Buddha Buck wrote:
At 01:45 PM 02-12-2001 -0300, Branden wrote:
Am I too wrong here?
It's... complicated...
Agreed.
Here's an example of where things could go wrong:
sub foo {
my $destroyme1 = new SomeClass;
my $destroyme2 = new SomeClass;
my @processme1;
At 12:25 PM 2/12/2001 -0500, Bryan C. Warnock wrote:
On Monday 12 February 2001 12:40, Branden wrote:
Probably Perl 6 programs will be cached/distributed in optimized byte code
format.
I'm not sure about the leading 'probably'. Perl 6 programs will most likely
be like most other open-source
On Mon, Feb 12, 2001 at 05:45:17PM +, Nicholas Clark wrote:
When I last tried it (over a year ago) running the 5.005 regression tests
with the standard libraries coming out of a zip file took about the same
time as running the regression tests with the standard libraries on disk.
[x86
[EMAIL PROTECTED] wrote:
I'm not planning on waiting for Perl 6 to start work on par, so Moore
isn't with us.
Agreed, with the condition that we all make the specification for it
together, and it remains compatible with `par' that will be shipped with
Perl 6.
And I'll probably ask you to
At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
Perl needs some level of tracking for objects with finalization attached to
them. Full refcounting isn't required, however.
I think I've heard you state that before. Can you be more specific? What
On Fri, Feb 09, 2001 at 06:17:34PM -0200, Branden wrote:
I put together a comparison table between par and rpm/jar.
You forgot deb, which I'd *much* rather deal with than rpm (if only
because I can point apt and dselect at CPAN). You also forgot the "Is
Vaporware?" category. ;)
| Available
On Sat, Feb 10, 2001 at 12:58:34AM +0100, Bart Lateur wrote:
* On a currently normal Pentium of 500MHz, 64Mb, ungzipping and
untarring a .tgz archive of 250k (the ungzipped file itself is roughly
1.5Mb) takes roughly 1 second. (ONE second!)
One second is too slow (for a Unix user it is,
On Mon, Feb 12, 2001 at 12:08:12PM -0500, [EMAIL PROTECTED] wrote:
On Sat, Feb 10, 2001 at 12:58:34AM +0100, Bart Lateur wrote:
* On a currently normal Pentium of 500MHz, 64Mb, ungzipping and
untarring a .tgz archive of 250k (the ungzipped file itself is roughly
1.5Mb) takes roughly 1
[EMAIL PROTECTED] wrote:
On Fri, Feb 09, 2001 at 06:17:34PM -0200, Branden wrote:
I put together a comparison table between par and rpm/jar.
You forgot deb, which I'd *much* rather deal with than rpm (if only
because I can point apt and dselect at CPAN). You also forgot the "Is
Just for those who don't read perl6-language, ESR has come on and is
reevaluating his statements. For the record, he gave Java and TCL a
much harder time.
At 04:13 PM 2/12/2001 +, Simon Cozens wrote:
How much can we do in the compiler, and how much can we do in the
interpreter? If we're having cached bytecode, it makes sense to do
as much optimization as we can in the compiler. If not, we might
as well brute force things to conserve compilation
At 11:01 PM 2/11/2001 -0800, Jan Dubois wrote:
[moved to -internals]
On Mon, 12 Feb 2001 01:44:54 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Perl needs some level of tracking for objects with finalization attached to
them. Full refcounting isn't required, however. Also, the vast majority of
At 09:49 AM 2/12/2001 -0800, Jan Dubois wrote:
On Mon, 12 Feb 2001 14:50:44 -0300, "Branden" [EMAIL PROTECTED]
wrote:
Actually I was thinking something like PMCs ($@%) being copy-GCed and
referred objects (new SomeClass) being refcounted. In this case above, every
operation would use
At 09:34 AM 2/12/2001 -0800, Jan Dubois wrote:
On Mon, 12 Feb 2001 16:13:10 +, Simon Cozens [EMAIL PROTECTED] wrote:
How much can we do in the compiler, and how much can we do in the
interpreter? If we're having cached bytecode, it makes sense to do
as much optimization as we can in the
On Mon, 12 Feb 2001 14:50:44 -0300, "Branden" [EMAIL PROTECTED]
wrote:
Actually I was thinking something like PMCs ($@%) being copy-GCed and
referred objects (new SomeClass) being refcounted. In this case above, every
operation would use refcount's, since they're storing objects in PMCs. What
Jan Dubois wrote:
Perl 5 basically clones on every assignment. As it uses refcounting, it
knows it doesn't need to clone a string if its refcount=1 and it's marked
as
temporary, i.e., only a temporary that will go away anyway knows about
this
string, so it's guaranteed no other reference to
At 04:21 PM 2/12/2001 -0300, Branden wrote:
Jan Dubois wrote:
You point out two disadvantages:
- It steal 2 bits from the SvTYPE flags. Flags are a *very* scarce
resource and shouldn't be used up unless there are very good reasons
for it.
- Using shared strings is not totally
[EMAIL PROTECTED] wrote:
What are we doing with it? We are killing perl2exe.
Not exactly.
The niches of:
1. "I don't want to use modules because the end-user might not have
them installed"
Yes.
2. "My end-users might not have Perl installed" Bundling a Perl
On Mon, 12 Feb 2001 13:33:52 -0500 (EST), Sam Tregar [EMAIL PROTECTED]
wrote:
It's reasonably obvious (which is to say "cheap") which variables aren't
involved with anything finalizable.
Probably a simple bit check and branch. Is that cheap? I guess it must
be.
Yes, but incrementing the
On Mon, Feb 12, 2001 at 04:01:31PM -0300, Branden wrote:
I don't really see much _conceptual_ difference between rpm, deb, and the
other package formats used by Linux.
debs store alot of information that rpm doesn't, and it would be good
to look at to steal good ideas. Also, and most
On Mon, Feb 12, 2001 at 01:50:39PM -0500, [EMAIL PROTECTED] wrote:
On Mon, Feb 12, 2001 at 04:01:31PM -0300, Branden wrote:
Loading a Perl module from a filehandle might
screw with DATA.
As resource files can be attached to the archive, I think not allowing
__DATA__ wouldn't be
On Mon, Feb 12, 2001 at 06:35:17PM +, Nicholas Clark wrote:
"par" stood for what?
Perl ARchive, just like jar (Java ARchive). "par" will be the utility
to create pars. To run a par, you'd use a seperate utility (so an
end-user doesn't have to carry around all the extra junk associated
par can do something similar. It can slap a copy of pun (and thus
perl) onto the archive. Its not simple, and its platform dependent,
but its useful. I'm more and more seeing par as a way of
embrace/extend/destroying perl2exe.
And I think we could squeeze something into 5.8.
Careful
On Mon, Feb 12, 2001 at 04:50:53PM -0300, Branden wrote:
2. "My end-users might not have Perl installed" Bundling a Perl
interpretor with your program (until perlcc is viable)
No. I don't expect Perl installation or any other otherwise executable or
installation program to
On Mon, Feb 12, 2001 at 04:01:31PM -0300, Branden wrote:
We'll just have to use something other than RSA most likely.
Why? Problems with exporting cryptosystems? If that's it, how does
Java/Netscape do it?
Nah, it's a pattent issue. Netscape (and other .jar consumers, assumedly)
licenced
On Mon, Feb 12, 2001 at 01:03:31PM -0600, Jarkko Hietaniemi wrote:
The problem of unpacking, or in other words, installing, or in other
words, embedded hardwired paths is hard. Think library paths: both
pure Perl libraries *and* shared libraries. In theory this is easy:
the portable (and
[EMAIL PROTECTED] wrote:
debs store alot of information that rpm doesn't, and it would be good
to look at to steal good ideas. Also, and most importantly, they have
dselect, which is similar, but much more powerful, than CPAN and the
CPAN shell. That's something to look at.
Could you
On Mon, Feb 12, 2001 at 02:19:54PM -0500, [EMAIL PROTECTED] wrote:
On Mon, Feb 12, 2001 at 01:03:31PM -0600, Jarkko Hietaniemi wrote:
The problem of unpacking, or in other words, installing, or in other
words, embedded hardwired paths is hard. Think library paths: both
pure Perl libraries
At 01:28 PM 2/12/2001 -0600, Jarkko Hietaniemi wrote:
On Mon, Feb 12, 2001 at 02:19:54PM -0500, [EMAIL PROTECTED] wrote:
Perl binary with a built-in @INC prefix something like
"/tmp/XpErLXX" and then do some s/// madness over the
binary.
Anyhow, this is easily solved by
Oh, I fully realize that *none* of this "self-extracting" nonsense is
going to be cross-platform by any means. For each variation of Unix
you'll need a seperate par binary, but its no worse than C. But Unix
really isn't a problem. Any Unix dist worth its weight in snot comes
with Perl.
The
On Mon, 12 Feb 2001, Dan Sugalski wrote:
I think I've heard you state that before. Can you be more specific? What
alternate system do you have in mind? Is this just wishful thinking?
This isn't just wishful thinking, no.
You picked the easy one. Maybe you can get back to the other two
On Mon, 12 Feb 2001 13:29:21 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
Perl needs some level of tracking for objects with finalization attached to
them. Full refcounting isn't required, however.
I
On Mon, Feb 12, 2001 at 01:33:52PM -0500, Sam Tregar wrote:
Perhaps. It's not rare in OO Perl which is coincidentally one area in
serious need of a speedup. I suppose I'm warped by my own experience -
all the code I see every day is filled with references and objects.
That's probably not
Dan Sugalski wrote:
...
doing software copy-on-write stuff, along with having to make the garbage
collector smart enough to deal with multiple PMCs pointing to identical
memory.
???
I thought that was the big deal of GC! Dealing with many references to the
same thing and free the thing when
At 04:57 PM 2/12/2001 -0300, Branden wrote:
Dan Sugalski wrote:
...
doing software copy-on-write stuff, along with having to make the garbage
collector smart enough to deal with multiple PMCs pointing to identical
memory.
???
I thought that was the big deal of GC! Dealing with many
At 01:33 PM 2/12/2001 -0500, Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
I think I've heard you state that before. Can you be more specific? What
alternate system do you have in mind? Is this just wishful thinking?
This isn't just wishful thinking, no.
You picked the
On Mon, Feb 12, 2001 at 02:41:01PM -0500, [EMAIL PROTECTED] wrote:
Oh, I fully realize that *none* of this "self-extracting" nonsense is
going to be cross-platform by any means. For each variation of Unix
Whew! I was starting to think I'm surrounded by tunnel visioned penguins.
you'll need
On Mon, Feb 12, 2001 at 01:03:31PM -0600, Jarkko Hietaniemi wrote:
The problem of unpacking, or in other words, installing, or in other
words, embedded hardwired paths is hard. Think library paths: both
pure Perl libraries *and* shared libraries.
True enough. The way Linux package managers
Language design is a very tough nut to crack, and we decided (as
a group) that we don't want a language designed by committee, we
want a languaged designed by Larry.
Right, but does it hurt to give general guide-posts on how the language is to
operate? If everybody knows that it is going
At 11:48 AM 2/12/2001 -0800, Edward Peschko wrote:
Rushing the process because of intermittent PR problems isn't going
to make Perl6 any better at achieving it's goal - solving tomorrow's
problems better than Perl5.
Again, I don't think that this would be rushing things at all. Give a
At 10:46 AM 2/12/2001 -0800, Jan Dubois wrote:
On Mon, 12 Feb 2001 13:29:21 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
Perl needs some level of tracking for objects with finalization
attached to
I have extended the RFC 88 Perl 5 reference implementation to
support rudimentary POST and CATCH blocks, for which I've used
"always" and "except" as the keywords.
The new version is http://www.avrasoft.com/perl6/try6-2021.txt
Save that file as Try.pm and perl -we "use Try regress = 1"
to run
Johan Vromans wrote:
[...] As a result, error messages become utterly useless. I almost
never see a Java program that reports "Cannot open file foo".
Instead, it reports a java.lang.ioerrorexception and a stracktrace
of several pages. Useless if you do not have the source, often
even if you
John Porter wrote:
There is no try, there is only do. :-)
Nonsense.
Traditionally Perl has had both the "do" and the "eval" block
forms, the latter which traps, the former which doesn't.
"try" is just a slightly souped-up "eval" that better handles the
class of problems introduced when
Dan Sugalski [EMAIL PROTECTED] writes:
At 10:38 AM 2/12/2001 -0500, Sam Tregar wrote:
On Mon, 12 Feb 2001, Dan Sugalski wrote:
Perl needs some level of tracking for objects with finalization attached to
them. Full refcounting isn't required, however.
I think I've heard you state
James Mastros wrote:
On Mon, Feb 12, 2001 at 01:03:31PM -0600, Jarkko Hietaniemi wrote:
The problem of unpacking, or in other words, installing, or in other
words, embedded hardwired paths is hard. Think library paths: both
pure Perl libraries *and* shared libraries.
True enough. The
At 01:59 PM 2/12/2001 -0700, Tony Olekshy wrote:
Dan Sugalski wrote:
I do wish people would get garbage collection and finalization split in
their minds. They are two separate things which can, and will, be dealt
with separately.
For the record:
THE GARBAGE COLLECTOR WILL HAVE
Tony Olekshy wrote:
Damian Conway wrote:
Actually, I do agree that Perl 6 ought to provide a universal
"destructor" mechanism on *any* block. For historical reasons, I
suppose it should be Ccontinue, though I would much prefer a
more generic name, such as Ccleanup.
Perl 6 ought to
John Porter wrote:
Tony Olekshy wrote:
I think "always" should be part of an explicit statement, such
as "try", not some implied property of block structure introduced
by a dangling clause.
Why?
There's an old engineering joke about instructions that go on and on
for pages about
Nicholas Clark wrote:
It makes them far more useful as tidy up things if they are tacked
on at runtime, not compile time.
If I understand, it is proposed that code like this:
{
Alpha;
POST { Beta };
Gamma;
POST { Delta };
Epsilon;
}
will
While I'm not in a position to rush Larry, we are starting in on the bits
of the internals that we can do without much input from him. It's slow
going (mainly because we've been waiting) but it has started.
well, I don't think that anyone should be in the position to 'rush' anyone else,
but
Dan Sugalski wrote:
[...] I wasn't talking about try{}/finally{} stuff. I was talking
about DESTROY (or its equivalent) for objects, which unfortunately
can't be tied to any one particular place in the code.
and, from another thread:
I really don't want to guarantee predictable
On Mon, Feb 12, 2001 at 05:33:05PM -0500, Dan Sugalski wrote:
package foo;
use attrs qw(cleanup_sub);
would be nice, but I don't know that he'll go for it. (Though it's the only
way I can think of to avoid AUTOLOAD being considered a potential destructor)
Fiat?
It's pretty hard (for
At 11:28 PM 2/12/2001 +0100, Robin Berjon wrote:
At 15:37 12/02/2001 -0500, Dan Sugalski wrote:
It *is* rare in OO perl, though. How many of the variables you use are
really, truly in need of finalization? .1 percent? .01 percent? Less? Don't
forget that you need to count every scalar in every
On Mon, Feb 12, 2001 at 01:58:57PM -0700, Tony Olekshy wrote:
- It does have in-flow presence, so it doesn't suffer from the
problem that "always" has; POST is a statement, not a dangling
clause. That fixes my main complaint with RFC 119. On the
other hand, now there's nothing
On Mon, Feb 12, 2001 at 01:28:56PM -0600, Jarkko Hietaniemi wrote:
On Mon, Feb 12, 2001 at 02:19:54PM -0500, [EMAIL PROTECTED] wrote:
You have to do that anyway to solve the "what version of glibc are you
using" problem (and others).
*minirant*
The world is not not glibc. The world is
On Mon, Feb 12, 2001 at 05:28:04PM -0300, Branden wrote:
Could you point me to some URLs? Like .deb file format? What's the good info
the have? What's dselect? How it works?
Start from sections 6, 7 and 8 of the Debian FAQ
http://www.debian.org/doc/FAQ/
dselect, aptitude and several other
"David L. Nicol" wrote:
POST{stuff} is a macro for
push (my) @Deferred_stuff, sub {stuff}; # my on first use in a space
Since the reference implementation requires try, @Deferred_stuff is
actually try's argument list (a bunch of tagged catch and finally
blocks). The "my" is provided by
75 matches
Mail list logo
