The Apocalypse on operators says that if one of the operands of a
hyperoperator is a scalar, then that scalar is (nominally) treated as an
array of copies of that scalar. In other words:
my $foo=1;
my @bar=(2, 3, 4);
my @baz=$foo ^+ @bar; # @baz=(3, 4, 5)
At 9:03 AM +0200 9/16/02, Leopold Toetsch wrote:
Ken Fox wrote:
Dan Sugalski wrote:
On lookup. The aggregate being queried by key is responsible for
complaining if the key its passed is something that it doesn't
like.
If %h{a}[0][1] is a PASM P2[a;0;1], then what is %h{a}{0}{1}?
It can't
In message [EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
Above docs state, that a gernal parrot op looks like this
op dest[dkey], src1[skey1], src2[skey2]
e.g.
add P0[P1], P2, P3[P4]
where P1 and P4 are keys and P0 and P3 are aggregates and P2 is a scalar.
Dan Sugalski wrote:
At 9:03 AM +0200 9/16/02, Leopold Toetsch wrote:
In PASM they look the same. But as Dan stated, and as tried to show in
my answer to Graham, the lookup succeeds only if the nested PMCs are
all of the correct type. This works now because an array doesn't
support a
On Wed, Sep 18, 2002 at 10:15:20AM +0200, Dan Sugalski wrote:
I've been thinking that we do need to have an extra flag to note
whether a key element should be taken as an array or hash lookup
element. The integer 1 isn't quite enough, since someone may have
done a %foo{1} and we only have
Tom Hughes wrote:
In message [EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
op dest[dkey], src1[skey1], src2[skey2]
e.g.
add P0[P1], P2, P3[P4]
There was however some discussion as to whether we wanted to limit
keyed access to just the set/assign opcodes in order
In message [EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
2) What PASM ops should above statement generate:
a) add_p_k_p_p_k (i.e. all variations of /p(_k)?/ )
b) add_p_k_p_k_p_k
if b) how to create a NULL key and how does it look like in PBC?
As things stand it
# New Ticket Created by Leon Brocard
# Please include the string: [perl #17402]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17402
classes/array.pmc had a duplicate defined_keyed which gcc under
Jagwyre
Maybe I should wait for the entire picture here, but in cases like this
(int $x, string $y) = some_function()
it would be nice to pass in both type _and_ number of return values. Or,
more generally, to consider the type of a list to be a list of the types
of its members. This means
Tom Hughes wrote:
If there is a plain P0 without [], the assembler hat to insert a NULL
key instead.
In other words we assume all PMC arguments have a key, so you can
never have a p in a opcode name with one of k/kc/ki/kic following it?
No - only if there is any p_k not for _kc/_ki_kic.
Leon Brocard (via RT) wrote:
classes/array.pmc had a duplicate defined_keyed which gcc under
Jagwyre complained. Here is a patch to remove one of the
duplicates. The tests still pass.
Leon
-INTVAL defined_keyed (PMC* key) {
+INTVAL exists_keyed (PMC* key) {
The second
On 18 Sep 2002, Tom Hughes wrote:
In message [EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
[ add Px[Ix], Py, Pz[Iz]
2) What PASM ops should above statement generate:
a) add_p_k_p_p_k (i.e. all variations of /p(_k)?/ )
b) add_p_k_p_k_p_k
if b) how to create a
On Wed, 18 Sep 2002, Leopold Toetsch wrote:
Tom Hughes wrote:
In message [EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
op dest[dkey], src1[skey1], src2[skey2]
e.g.
add P0[P1], P2, P3[P4]
There was however some discussion as to whether we wanted to limit
Thanks, applied.
/s
In message [EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
Tom Hughes wrote:
You will still get horrible op explosion for a three argument op as
even if you assume that all PMCs are keyed, there are four key types
which, with three operands, gives you 64 ops in total.
In message [EMAIL PROTECTED]
Sean O'Rourke [EMAIL PROTECTED] wrote:
Actually, if scratchpads become proper PMC's these ops would be incredibly
useful and common. For example, @a[0] = %b{1} + $c might become
add P0[@a;0], P0[%b;1], P0[$c]
This is rather speculative, but if
On 18 Sep 2002, Tom Hughes wrote:
In message [EMAIL PROTECTED]
Sean O'Rourke [EMAIL PROTECTED] wrote:
Actually, if scratchpads become proper PMC's these ops would be incredibly
useful and common. For example, @a[0] = %b{1} + $c might become
add P0[@a;0], P0[%b;1], P0[$c]
I couldn't find any example of using a MultiArray PMC.
I tried on my own, but failed miserably.
from what I've seen, it seems that is impossible to
properly initialize a multidimensional MultiArray.
I've tried this:
new P1, .MultiArray, 1000
set P1[0;0], 1
set
At 12:04 AM -0700 9/18/02, Brent Dax wrote:
The Apocalypse on operators says that if one of the operands of a
hyperoperator is a scalar, then that scalar is (nominally) treated as an
array of copies of that scalar. In other words:
my $foo=1;
my @bar=(2, 3, 4);
my @baz=$foo
Steve Fink wrote:
What should this do:
my $x = the letter x;
print yes if $x =~ /the { $x .= ! } .* !/;
Does this print yes?
If it's allowed at all, I think the match should succeed.
print yes if helo =~ /hel { .pos-- } lo/;
This definitely has to work. But remember the call
# New Ticket Created by Aldo Calpini
# Please include the string: [perl #17405]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17405
this one patches the Makefile to correctly build a
pdb.exe on Win32 (it should
At 11:25 AM +0100 9/18/02, Graham Barr wrote:
On Wed, Sep 18, 2002 at 10:15:20AM +0200, Dan Sugalski wrote:
I've been thinking that we do need to have an extra flag to note
whether a key element should be taken as an array or hash lookup
element. The integer 1 isn't quite enough, since
At 8:37 AM -0700 9/16/02, Sean O'Rourke wrote:
It seems to me that by making everything an exception, this patch goes too
far in a couple of ways. First, some fallback behaviors make sense. For
example, if a class implements set_bignum() but not set_int(), it makes
sense for default.pmc to wrap
On Wed, 18 Sep 2002, Damian Conway wrote:
Would it be correct for this to print 0? Would it be correct for this
to print 2?
my $n = 0;
aargh =~ /a* { $n++ } aargh/;
print $n;
Yes. ;-)
Wouldn't that print 2 if $n is lexical and 0 if it's localized? Or are
lexicals localized
On Wed, 2002-09-18 at 11:42, Piers Cawley wrote:
The Perl 6 Summary for the Week Ending 20020915
Happy birthday to me!
Indeed!
And thank you so much for this. You have a way of taking a tangled mess
of discussion that's even confusing the participants and making it easy
to digest (no pun
Tom Hughes wrote:
In message [EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
All 64 combinations would be a horror.
Indeed.
But I really vote for a predereferencing like solution.
I didn't really understand that part of your previous message, but I
don't see what
In message [EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
For _keyed operands I would propose:
The used keys are not coded into the opcode name (so no 64 variations),
but the opcode-number holds this information.
add_p_p_p (op #297)
app_p_k_p_p = #297 + (KEY1_FLAGS
On Fri, 13 Sep 2002, Sean O'Rourke wrote:
On Fri, 13 Sep 2002, Andy Dougherty wrote:
This test tests for
12! = 479001600
14! = 1278945280
However, 14! is really 87178291200.
Is the test deliberately trying to test for some 32-bit-specific
integer overflow behavior?
No,
On Wed, 18 Sep 2002, Andy Dougherty wrote:
That's what I would have thought, but it seems that 12! is already testing
recursive functions. Unless there's an objection, I'll just delete the
14! test.
Sure.
/s
Tom Hughes wrote:
In message [EMAIL PROTECTED]
Leopold Toetsch [EMAIL PROTECTED] wrote:
while (pc) {
argp1 = ...pmc_reg.registers[cur_opcode[1]];
if (*pc KEY1_MASK) {
key1 = ...pmc_reg.registers[cur_opcode[2]]; /* for p_k */
argp1 = get_keyed_entry(argp1,
The Perl 6 Summary for the Week Ending 20020915
Happy birthday to me!
Happy birthday to me!
Happy birthday dear me!
Happy birthday to me!
And, with a single breech of copyright, Piers was free. The production
of this summary was delayed by my turning 35 on the 15th
On Wed, 18 Sep 2002, Josh Jore wrote:
On Wed, 18 Sep 2002, Damian Conway wrote:
Would it be correct for this to print 0? Would it be correct for this
to print 2?
my $n = 0;
aargh =~ /a* { $n++ } aargh/;
print $n;
Yes. ;-)
Wouldn't that print 2 if $n is lexical
Aaron Sherman [EMAIL PROTECTED] writes:
On Wed, 2002-09-18 at 11:42, Piers Cawley wrote:
The Perl 6 Summary for the Week Ending 20020915
Happy birthday to me!
Indeed!
And thank you so much for this. You have a way of taking a tangled mess
of discussion that's even confusing the
33 matches
Mail list logo
