On Fri, 9 Feb 2001 16:14:34 -0800, Mark Koopman wrote:
but is this an example of the way people SHOULD code, or simply are ABLE to
code this. are we considering to deprecate this type of bad style, and force
to a programmer to, in this case, supply a ref to %baz in the arguements to
this sub?
You should probably also take a look a Debian's packaging, the .deb.
It consists of an ar archive containing three files: one for the magic
(named debian-binary, containing "2.0"), one for the filesystem image
(filesystem.tar.gz)
On Fri, Feb 09, 2001 at 06:17:34PM -0200, Branden wrote:
|
Bart Lateur wrote:
On Fri, 09 Feb 2001 12:06:12 -0500, Ken Fox wrote:
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 obj; }
...
That is not a garbage
[Please be careful with attributions -- I didn't write any
of the quoted material...]
Russ Allbery wrote:
sub test {
my($foo, $bar, %baz);
...
return \%baz;
}
That's a pretty fundamental aspect of the Perl language; I use that sort
of construct
On Fri, 09 Feb 2001 13:19:36 -0500, Dan Sugalski [EMAIL PROTECTED] wrote:
Almost all refcounting schemes are messy. That's one of its problems. A
mark and sweep GC system tends to be less prone to leaks because of program
bugs, and when it *does* leak, the leaks tend to be large. Plus the code
On Sunday 11 February 2001 19:08, Jan Dubois wrote:
However, I couldn't solve the problem of "deterministic destruction
behavior": Currently Perl will call DESTROY on any object as soon as the
last reference to it goes out of scope. This becomes important if the
object own scarce external
On Sun, 11 Feb 2001 21:11:09 -0500, "Bryan C. Warnock"
[EMAIL PROTECTED] wrote:
On Sunday 11 February 2001 19:08, Jan Dubois wrote:
However, I couldn't solve the problem of "deterministic destruction
behavior": Currently Perl will call DESTROY on any object as soon as the
last reference to it
crossed to -internals
Jan Dubois:
Not necessarily; you would have to implement it that way: When you try to
open a file and you don't succeed, you run the garbage collector and try
again. But what happens in the case of XS code: some external library
tries to open a file and gets a failure.
