Re: Autovivi

2002-08-14 Thread Leopold Toetsch
Uri Guttman wrote: [ CCs stripped ] ... what if you passed \$a{llama}{alpaca}? even as a read only param, you could deref later through the ref in another sub that gets passed it from this sub. If I understand Dan's proposal (a05111b55b977c7a65606@[63.120.19.221]) for a change in the

Re: [COMMIT] GC_DEBUG, Some GC Fixes, and Remaining GC Bugs

2002-08-14 Thread Mike Lambert
Somebody gimme a cookie. /me hands Steve a cookie. If the rx info object is going away, then obviously those parts of the patch need not be applied. But in the meantime, it's nice to have a Parrot that doesn't crash. I agree. My disclaimer about the regex code in my original email was to

[perl #16038] [PATCH] multidim arrays reworked

2002-08-14 Thread Josef Hook
I've moved all code into one file now. /Josef diff -urN parrot.orig/MANIFEST parrot/MANIFEST --- parrot.orig/MANIFESTMon Aug 12 17:59:49 2002 +++ parrot/MANIFEST Mon Aug 12 18:01:36 2002 -22,6 +22,7 classes/default.pmc classes/genclass.pl classes/intqueue.pmc

[perl #15981] tests for ops patch

2002-08-14 Thread Josef Hook
Sorry for the delay i've had a busy week. This patch adds the tests. /josef --- pmc.t.orig Wed Aug 14 14:51:56 2002 +++ pmc.t Wed Aug 14 14:43:00 2002 -1,6 +1,6 #! perl -w -use Parrot::Test tests = 65; +use Parrot::Test tests = 68; use Test::More; my

Re: Autovivi

2002-08-14 Thread [EMAIL PROTECTED]
From: Larry Wall [EMAIL PROTECTED] Perhaps there should be a way to declare a parameter to be pass-by-value, producing a modifiable variable that does not affect the caller's value. But I'm not sure saving one assignment in the body is worth the extra mental baggage. and later he

RE: Autovivi

2002-08-14 Thread Brent Dax
[EMAIL PROTECTED]: # Resolution: Use whatever default seems good, but provide the # freedom to get pass-by-value-modifiable, perhaps something like this: # # sub mysub ($name is m, $email is m) { ... } Of course! This *is* Perl after all--did you ever doubt that we would give you all

Re: [netlabs #801] [PATCH] PerlArray in scalar context

2002-08-14 Thread David M. Lloyd
On Fri, 12 Jul 2002, Sean O'Rourke wrote: # New Ticket Created by Sean O'Rourke # Please include the string: [netlabs #801] # in the subject line of all future correspondence about this issue. # URL: http://bugs6.perl.org/rt2/Ticket/Display.html?id=801 This patch makes the following

Re: Autovivi

2002-08-14 Thread Luke Palmer
From: Larry Wall [EMAIL PROTECTED] The default is pass-by-reference, but non-modifiable. If there's a pass-by-value, it'll have to be specially requested somehow. This is a minimal difference from Perl 5, in which everything was pass-by-reference, but modifiable. To get pass-by-value,

Re: [netlabs #801] [PATCH] PerlArray in scalar context

2002-08-14 Thread David M. Lloyd
On Wed, 14 Aug 2002, David M. Lloyd wrote: The problem was that the math vtable methods were giving up if the other side of the operator wasn't an int or a num. So the current version of PerlArray would make $x undef. I'm not sure getting the other thing's int value (as opposed to its

RE: Autovivi

2002-08-14 Thread David Whipp
Luke Palmer wrote: Since variables are copy-on-write, you get the speed of pass-by-reference with the mutability of pass-by-value, which is what everyone wants. If you have this, why would you want to do enforced const reference? That's not rhetorical; I'm actually curious. One reason I

[perl #16219] [PATCH] stack direction probe

2002-08-14 Thread via RT
# New Ticket Created by Jason Gloudon # Please include the string: [perl #16219] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16219 This is a config test for the direction of stack growth that makes the direction