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 %
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.
Several questions arise from these pdd's:
1) Are above pdd's valid, WRT this 3 key opcodes?
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 s
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
>> suppo
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 ha
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
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?
> >>
> > A
# New Ticket Created by Leon Brocard
# Please include the string: [perl #17402]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17402 >
classes/array.pmc had a duplicate defined_keyed which gcc under
Jagwyre complained. Her
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 tha
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
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
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 t
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 op
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 s
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],
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 P1[0;1],
# New Ticket Created by "Aldo Calpini"
# Please include the string: [perl #17405]
# in the subject line of all future correspondence about this issue.
# 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 als
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, sinc
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 w
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'
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 + (K
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
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_ke
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 an
Should these be implemented:
- machine dependent, like now: (INTVAL)SELF->cache.num_val | ...
- SELF.get_integer() | ...
- or just throw an exception
leo
28 matches
Mail list logo
