Aldo Calpini wrote:
I have to disagree. the corresponding Perl script
does not show this behaviour:
It all depends. :-)
$\ = \n;
$#a = 100;
print scalar(a);
$x = $a[1][0];
print scalar(a);
101
10001
Perl has to autoviv if it has to drill down.
--
John Douglas Porter
hello everybody,
here is my rough draft of the documentation for the
Parrot debugger. please review it (expecially the
boilerplate stuff like TITLE, HISTORY, etc. -- I don't
know if I have properly followed convention) (and if there
is one) and tell me if this should be sent as a patch.
I'm
John Porter wrote:
It all depends. :-)
[...]
Perl has to autoviv if it has to drill down.
good point. but since we don't have multidimensional
array access right now (at least AFAIK), this seems
to be a non-issue. I don't know if p6 will autovivify
the way p5 does (and I hope not). IMHO,
John Porter wrote:
Aldo Calpini wrote:
I have to disagree. the corresponding Perl script
does not show this behaviour:
$\ = \n;
$#a = 100;
print scalar(a);
$x = $a[1][0];
This _writes_ to a[1] by generating the entry:
P0, 100
P1 = new .PerlArray
P1 = 0
P0[1] = P1
I0 =
On Fri, Aug 02, 2002 at 03:11:41PM +0200, Leopold Toetsch wrote:
John Porter wrote:
Aldo Calpini wrote:
I have to disagree. the corresponding Perl script
does not show this behaviour:
$\ = \n;
$#a = 100;
print scalar(a);
$x = $a[1][0];
Perl has to autoviv if it has
On 2002/08/02 16:11:26 Nicholas Clark [EMAIL PROTECTED] wrote:
It does on reading. I forget the eloquent explanation about the how or
why, but all references bar the leftmost are vivified. (Even inside
defined). In effect, all bar the last reference are in lvalue context -
only the rightmost is
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #15942]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15942
The subroutine.pmc and sub.pmc problems ([perl #15920]) are gone now
that Dan
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #15943]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15943
Sorry, I missed this patch hunk from #15880 (but I still think
eventually the
On Thu, Aug 01, 2002 at 10:57:34AM -0700, Sean O'Rourke wrote:
My naive implementation would have an array of hashes for each sub, with
one entry for each level of scope within.
I would use an array of arrays or a linked-list of arrays. This is
hardly more difficult to implement (you just
That's me. Will fix.
/s
On Fri, 2 Aug 2002, Jarkko Hietaniemi wrote:
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #15942]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15942
On Tue, Jul 30, 2002 at 09:07:11PM -0700, Sean O'Rourke wrote:
- take a look at new in core.ops. Creating a new continuation captures
context, but the register holding that continuation is part of the
context. Unfortunately, it doesn't know what register it's in until after
it captures the
On Fri, Aug 02, 2002 at 05:20:45PM +0200, Jerome Vouillon wrote:
On Thu, Aug 01, 2002 at 10:57:34AM -0700, Sean O'Rourke wrote:
My naive implementation would have an array of hashes for each sub, with
one entry for each level of scope within.
I would use an array of arrays or a
On Fri, 2 Aug 2002, Jerome Vouillon wrote:
On Thu, Aug 01, 2002 at 10:57:34AM -0700, Sean O'Rourke wrote:
My naive implementation would have an array of hashes for each sub, with
one entry for each level of scope within.
I would use an array of arrays or a linked-list of arrays. This is
On Fri, 2 Aug 2002, Jerome Vouillon wrote:
On Tue, Jul 30, 2002 at 09:07:11PM -0700, Sean O'Rourke wrote:
- take a look at new in core.ops. Creating a new continuation captures
context, but the register holding that continuation is part of the
context. Unfortunately, it doesn't know
On Fri, Aug 02, 2002 at 08:50:27AM -0700, Sean O'Rourke wrote:
On Fri, 2 Aug 2002, Jerome Vouillon wrote:
On Thu, Aug 01, 2002 at 10:57:34AM -0700, Sean O'Rourke wrote:
My naive implementation would have an array of hashes for each sub, with
one entry for each level of scope within.
On Fri, 2 Aug 2002, Melvin Smith wrote:
At 08:50 AM 8/2/2002 -0700, Sean O'Rourke wrote:
Without performance numbers, this is hard to test, but it can potentially
turn a single a = b + c, which is just add P0, P1, P2 if a, b, and c
have been referenced, into a hideous five instructions:
At 06:14 PM 8/1/2002 +0200, Jerome Vouillon wrote:
Melvin, I think it would really help if you could explain us how you
would compile this code. Also, you should describe precisely what
invoke and new_pad (and maybe the other scratchpad-related
opcodes) do as far as scratchpads are concerned.
At 08:50 AM 8/2/2002 -0700, Sean O'Rourke wrote:
Without performance numbers, this is hard to test, but it can potentially
turn a single a = b + c, which is just add P0, P1, P2 if a, b, and c
have been referenced, into a hideous five instructions:
fetch_lex P0, 'a' # Because how we store
On Fri, 2002-08-02 at 10:43, Jerome Vouillon wrote:
Sure, you need a hash. But this can be a statically allocated hash,
mapping variable names to indices.
Could two parallel arrays work? One stores the lexicals (accessed by
index) and the other stores the names of the lexicals. Then to access
On Fri, Aug 02, 2002 at 11:15:09AM -0600, Jonathan Sillito wrote:
Could two parallel arrays work? One stores the lexicals (accessed by
index) and the other stores the names of the lexicals. Then to access a
lexical by name involves a sequential search through the (probably not
large) array of
On Thu, 1 Aug 2002, Dan Sugalski wrote:
At 9:42 PM +0100 8/1/02, Nicholas Clark wrote:
Am I allowed to write ancillary functions I want the JIT to call in
assembler? I presume that the JIT needs to go fast, and I suspect that there
are some bits that are easier to write in assembler (eg
At 4:28 PM +0200 8/2/02, Haegl wrote:
On 2002/08/02 16:11:26 Nicholas Clark [EMAIL PROTECTED] wrote:
It does on reading. I forget the eloquent explanation about the how or
why, but all references bar the leftmost are vivified. (Even inside
defined). In effect, all bar the last reference are in
# New Ticket Created by Mr. Nobody
# Please include the string: [perl #15948]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15948
I sent this patch before but it got the wordwraps
messed up, its enclosed as an
# New Ticket Created by Simon Glover
# Please include the string: [perl #15949]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15949
hash-num_buckets is unsigned, so we were getting a comparison between
signed
# New Ticket Created by Simon Glover
# Please include the string: [perl #15953]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=15953
A few more tests for the GC ops.
Simon
--- t/op/gc.t.old Fri Aug 2
On Wed, Jul 31, 2002 at 11:43:39PM +, Jürgen Bömmels wrote:
In the quest for removing warnings, I added an option --ccwarn to
Configure.pl. With this option I could selectivly turn on and off
warnings, and especially compile with -Werror, so I don't miss any
warnings. The simple warnings
At 06:14 PM 8/1/2002 +0200, Jerome Vouillon wrote:
On Wed, Jul 31, 2002 at 11:40:39AM -0600, Jonathan Sillito wrote:
So here is my take on a slightly simpler example:
sub foo {
my $x = 13;
return sub { print $x\n; };
}
$foo()
Melvin, I think it would really help if
27 matches
Mail list logo
