> maybe a duplicate of #43485
>
> PIR code to reproduce:
>
> ..sub 'foo' :main
> $S0 = null
> $P0 = new 'Hash'
> # no crash without next line
> $P0['yum'] = 5
> $P1 = $P0[$S0]
> ..end
Fixed in r31566, together with a test adapted from this code.
Don't know if is related to #43
# New Ticket Created by I Sop
# Please include the string: [perl #59542]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=59542 >
maybe a duplicate of #43485
PIR code to reproduce:
..sub 'foo' :main
$S0 = null
$P0 =
ave only string keys, that trying to pull the keys out as PMCs
(presumably Strings) fails.
Aside from the ugly failure, this design seems broken in the face of
languages like Perl6 that expect to be able to use non-string hash keys.
Both for direct use by Perl6 internals, and for interoperability w
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #53464]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53464 >
Modify PGE to trim extra whitespace around #= keys
(which really shouldn&#
On Wed Nov 28 12:18:50 2007, kjs wrote:
> hi,
>
> IMCC allows for writing
>
> $P0 = $P1[10, 20]
>
> Looking into the yacc file, it seems there's something going on with
> slicing, just as the ".." syntax does (which is deprecated).
>
> I'm wondering what exactly is going on, what it is supposed
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #47930]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=47930 >
hi,
IMCC allows for writing
$P0 = $P1[10, 20]
Looking into the yacc file, it seems
n null
for nonexisting keys".
And even arrays will be changing to return a null PMC when we roll the
pdd15oo branch back in. So, agreed on preferring the null PMC.
Allison
bject line of all future correspondence about this issue.
># http://rt.perl.org/rt3/Ticket/Display.html?id=46391 >
>
>In src/dynpmc/gdbmhash.c there is the todo item:
>
>TODO: return None PMC for nonexisting keys.
>
>This is relevant when fetching keys, and ne
Ticket/Display.html?id=46391 >
In src/dynpmc/gdbmhash.c there is the todo item:
TODO: return None PMC for nonexisting keys.
This is relevant when fetching keys, and needs to be implemented.
Maybe not; see "None Must Die" [perl #40178] . . .
for nonexisting keys.
This is relevant when fetching keys, and needs to be implemented.
# New Ticket Created by Christoph Otto
# Please include the string: [perl #44893]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44893 >
This is just copy/paste from key.h to get this pdd back in sync.
Christoph
--- docs/pd
On Friday 17 August 2007 04:24:10 Badai Aqrandista wrote:
> Changed [ 'Test::More' ] to [ 'Test'; 'More' ]
Thanks, applied as r20648.
By the way, the justification for this is that PDD 15 says (or at least
should) that the proper approach to namespace nesting
On Thursday 16 August 2007 15:50:25 Badai Aqrandista via RT wrote:
> Sorry I just read the docs/submissions.pod and realized I shouldn't
> have submit the patch here. I'll resubmit it in proper way to
> parrotbug.
It's fine here; don't worry.
-- c
Hi,
Sorry I just read the docs/submissions.pod and realized I shouldn't
have submit the patch here. I'll resubmit it in proper way to
parrotbug.
--
Thanks,
Badai Aqrandista (cheepy)
==
--- runtime/parrot/include/test_more.pir(revision 20643)
+++ runtime/parrot/include/test_more.pir(patch
rt44663-cage-test-more-namespace-to-keys level 1)
@@ -12,7 +12,7 @@
# get the testing functions
.local
Hi chromatic,
Thanks for your prompt reply.
> The main change is to change all instances of [ 'Test::More' ] and the like to
> [ 'Test'; 'More' ].
Can you point to a document or a thread that explains about why this
change needs to happen?
I'm at work now. I'll work on it tonight.
--
Thanks,
On Wednesday 15 August 2007 13:42:39 Badai Aqrandista wrote:
Hi Badai,
> I'm new to the list. I'm a Perl Programmer doing web development in my
> day job and I'd like to help. I'll try to commit an hour or two per
> day to parrot project.
Welcome!
> Can you let me know what I should do to get t
Hi,
I'm new to the list. I'm a Perl Programmer doing web development in my
day job and I'd like to help. I'll try to commit an hour or two per
day to parrot project.
Can you let me know what I should do to get this done? I mean, do you
mean I need to change 'lib/Test/More.pm' or
'/runtime/parrot/
# New Ticket Created by chromatic
# Please include the string: [perl #44663]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44663 >
The Test::More namespace uses 'Test::More' instead of [ 'Test'; 'More' ]. I
prefer the la
From: chromatic <[EMAIL PROTECTED]>
Date: Sun, 24 Dec 2006 10:56:42 -0800
I'm writing tests for namespaces now (and fixing code), and testing the
keyed
variants is a real pain, mostly because creating nested Key PMCs in PIR is
so
face-stabbingly awful, if it's even possible.
It
I'm writing tests for namespaces now (and fixing code), and testing the keyed
variants is a real pain, mostly because creating nested Key PMCs in PIR is so
face-stabbingly awful, if it's even possible.
Without hard-coding the names, I'd love to see working PIR for creating a key
which can refer
On Mon, Jul 10, 2006 at 07:22:21PM -0700, Allison Randal wrote:
> Chip Salzenberg wrote:
> > I think that "hll" is the best I can think of, and given the existing
> > ".HLL" directive, its meaning is immediately clear:
>
> I like that.
Great!
> > Seems to me that we should have get_namespace pat
On Mon, Jul 10, 2006 at 06:57:06PM -0700, Matt Diephouse wrote:
> Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> >I really like both of these suggestions. We also noted on #parrot that
> >get_hll_global would really simplify things for the Tcl folks, which
> >currently go through a macro to achie
Chip Salzenberg wrote:
>
> Hrm. Relative is the usual apposite to absolute, but we have a three-way
> logic here, so appositives don't really work. I think that "hll" is the
> best I can think of, and given the existing ".HLL" directive, its meaning
> is immediately clear:
I like that.
> Seems
Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
On Mon, Jul 10, 2006 at 02:53:15PM -0700, Chip Salzenberg wrote:
> On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote:
> > On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
> > > Relative is the usual apposite to absolut
On Mon, Jul 10, 2006 at 02:53:15PM -0700, Chip Salzenberg wrote:
> On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote:
> > On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
> > > Relative is the usual apposite to absolute, but we have a three-way
> > > logic here, so
On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote:
> On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
> > Relative is the usual apposite to absolute, but we have a three-way
> > logic here, so appositives don't really work. I think that "hll" is the
> > best I can
On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote:
> Relative is the usual apposite to absolute, but we have a three-way
> logic here, so appositives don't really work. I think that "hll" is the
> best I can think of, and given the existing ".HLL" directive, its meaning
> is immediat
Chip Salzenberg <[EMAIL PROTECTED]> wrote:
{ Language implementors, please know I'm going to do everything I can to
make every commit break nothing. I did pretty well when I made namespace
[''] stop being [] -- I fixed all the HLLs in the selfsame patch, except
two bits of code generation
{ Language implementors, please know I'm going to do everything I can to
make every commit break nothing. I did pretty well when I made namespace
[''] stop being [] -- I fixed all the HLLs in the selfsame patch, except
two bits of code generation in TGE and PGE, which I fixed when they were
On Thu, Jul 06, 2006 at 05:39:45PM -0700, jerry gay wrote:
> am i silly to think that if i'm looking for globals from the current
> namespace, they're just as likely to be found closer to the namespace
> root, than further away? perhaps something like
>
>.namespace [ 'Foo'; 'Bar' ]
>$P0 =
es the need for creating and
passing in an empty array, because 'no argument' always means the same
thing as 'empty array' or 'no key' would mean. That's a really elegant
piece of consistency.
And I think it's a worthy goal to make
compiler writer's l
Chip Salzenberg wrote:
Well, I see a lot to like about this, but (and you knew there was a "but"
("but" that's my job now :-))), in descending order of difficulty:
And you do it so well. Thank you. :)
* The division into two categories ("global" and "symbol") leaves the third
category (c
en prove
> useful for real keys. And this makes keys even more compatible with the
> Array interface, which I think they might need to implement someday anyway.
>
> Allison, what do you think of zero-length keys, i.e. having [] construct a
> Key PMC describing no dimensions of lookup?
On 7/6/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
So here's an illustrative suggestion, which I think is a variant on one of
your also-rans, albeit one that leaves the common HLL case unmarked:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_cur_global 'x'
{ All you HLL implementors and other PIR users out there, please be assured
that I'll be providing as easy a transition as possible when/if these global
opcodes are adjusted. }
On Thu, Jul 06, 2006 at 11:53:59AM -0700, Allison Randal wrote:
> I ran through a number of possibilities, but so far
On Thu, Jul 06, 2006 at 12:11:47PM -0700, Allison Randal wrote:
> It's essentially the linguistic problem of being able to refer to
> something both by its full name and by the pronoun "it". (Otherwise known
> as "topic".) Only, currently "it" isn't represented by a word.
Well, we have three disti
b
with enough information to disambiguate. And when that gets unclear,
they throw in the full name again.
...I was hoping you'd say something like, "Oh
yeah, we're gonna need zero-length keys anyway for Perl 6". What is the
parameter to operator:postcircumfix [] when a user
Allison Randal wrote:
I had a much longer reply, but I'm going to let it steep overnight and
see what percolates.
I ran through a number of possibilities, but so far my favorite is:
find_global and store_global are truly 'global', that is, they always
require a fully specified namespace, in
voiding explicit
re-coding of a known bit of environmental information, as in "the first
floor of this building" rather than "the first floor of 123 main street".
> Chip Salzenberg wrote:
> >Allison, what do you think of zero-length keys, i.e. having [] construct a
>
Chip Salzenberg wrote:
--- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED --
On the other hand, we could extend the key PMC to represent emptiness,
i.e. zero dimensions. This seems useful for namespaces and could even prove
useful for real keys. And this makes keys even more compatible
ce [] > so that we could also have the
> matching C< find_global [], 'foo' >. Otherwise find_global becomes a
> two step operation for finding globals in the root HLL namespace.
Well, that's a bit problematic. The [] syntax is inherited from the key
syntax, and keys c
On Jan 20, 2006, at 21:34, Klaas-Jan Stol wrote:
Hi,
I tried to index aggregates using several types of keys (that is,
several types of values), and it seems only string and integer values
can be used as keys. A quick look at the source in
compilers/imcc/symreg.c confirms this, there is no
I think I remember reading one of the comments in the IMCC compiler
something to the effect of "if someone needs N keys they can just
convert to strings."
Sorry I can't find the exact wording right now, but it might point you
somewhere useful.
Amos Robinson
On 1/21/06, Klaas-J
Matt Fowles wrote:
Klaas-Jan~
On 1/20/06, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
Hi,
I tried to index aggregates using several types of keys (that is,
several types of values), and it seems only string and integer values
can be used as keys. A quick look at the source in
compiler
Klaas-Jan~
On 1/20/06, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I tried to index aggregates using several types of keys (that is,
> several types of values), and it seems only string and integer values
> can be used as keys. A quick look at the source in
>
Hi,
I tried to index aggregates using several types of keys (that is,
several types of values), and it seems only string and integer values
can be used as keys. A quick look at the source in
compilers/imcc/symreg.c confirms this, there is no case for 'N' values
(and a test makes
Leopold Toetsch wrote:
Klaas-Jan Stol wrote:
Leopold Toetsch wrote:
By far the simplest thing is either look at the opcode in
ops/core_ops.c or use a debugger and set a breakpoint at the
appropriate opcode, e.g.
So, apparently, it seems to me the get_pmc_keyed method is called.
Y
Klaas-Jan Stol wrote:
Leopold Toetsch wrote:
By far the simplest thing is either look at the opcode in
ops/core_ops.c or use a debugger and set a breakpoint at the
appropriate opcode, e.g.
So, apparently, it seems to me the get_pmc_keyed method is called.
Yep
.. I
tried to run the Par
Leopold Toetsch wrote:
On Jul 29, 2005, at 10:38, Klaas-Jan Stol wrote:
Anybody an idea what I'm doing wrong here?
By far the simplest thing is either look at the opcode in
ops/core_ops.c or use a debugger and set a breakpoint at the
appropriate opcode, e.g.
Parrot_set_p_p_kc (or _ki
On Jul 29, 2005, at 10:38, Klaas-Jan Stol wrote:
Anybody an idea what I'm doing wrong here?
By far the simplest thing is either look at the opcode in
ops/core_ops.c or use a debugger and set a breakpoint at the
appropriate opcode, e.g.
Parrot_set_p_p_kc (or _kic)
and step on from there
Hi,
I'm trying to extend the standard Hash PMC, if it returns "None",
because there was no value at the specified key, then I want to override
this behaviour by returning something else. In order to do that, I
should know what methods are called. That's where I'm running into
trouble. I can j
[1], you need a proxy
object to hold on to [ [EMAIL PROTECTED], 0 ] until the [1] comes in.
Having all the keys collected together before the first lookup
avoids that hackery.
--
Chip Salzenberg <[EMAIL PROTECTED]>
At 7:10 PM -0700 5/31/05, TOGoS wrote:
> The 'used as' type indicates whether this key
is to be used to do a by-integer-index (array)
access or by-string-index (hash) access.
Why not extend this to properties, too?
Because properties (and attributes) are metadata. At the moment
properti
explanation:
>
> Perl has keyed access on hashes and arrays:
>
> $v = @a[$k] and $v = %a{$k}
>
> Both would translate to Parrot's:
>
> v = a[k]
>
> and the meaning "indexed" vs "hashed" access would
> be lost. To get that
> in
ctually answer
> your question at all.
???
Anyway - and to run the risk of stating again something you already know -
here is a more verbose explanation:
Perl has keyed access on hashes and arrays:
$v = @a[$k] and $v = %a{$k}
Both would translate to Parrot's:
v = a[k]
and t
perl6-internals: the place to go to have people tell
you things you already know and not actually answer
your question at all.
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> TOGoS wrote:
>
> > Why not extend this to properties, too?
>
> > foo.hello becomes
> >
> > 'hello'
> > stri
TOGoS wrote:
Why not extend this to properties, too?
foo.hello becomes
'hello'
string
as-property
Because that's an attribute access:
$P0 = getattribute foo, "hello"
leo
> The 'used as' type indicates whether this key
> is to be used to do a by-integer-index (array)
> access or by-string-index (hash) access.
Why not extend this to properties, too?
foo['hello'] becomes
'hello'
string
as-offset
foo{'hello'} becomes
'hello'
string
and $a{$b} generates
$b
PMC
as-hash
and $a{3} generates
3
integer
as-hash
*If* a PMC supports it, it may complain if the basic type is
incorrect (that is, you pass in a string for array access) but
generally that's a bad thing -- the PMC should just convert. (Al
Will Coleda <[EMAIL PROTECTED]> wrote:
> .sub main @MAIN
> $P0 = new Integer
> store_global "Foo", unicode:"Bar", $P0
> print "ok 1\n"
> .end
> It generates the error:
> unimplemented unicode
Yep. charset/unicode.c:compute_hash() *was* unimplemented.
leo
# New Ticket Created by Will Coleda
# Please include the string: [perl #34660]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=34660 >
In my test bed, I've switched tcl over to using unicode for most of its
strings, so tha
Simon Glover <[EMAIL PROTECTED]> wrote:
> ... In both cases, I would expect to get '00', since the hash
> should be empty. Is this a bug in the code, or is an OrderedHash supposed
> to work this way (in which case a note to this effect in the
> documentation might be a good idea)?
Mixing keye
# New Ticket Created by Simon Glover
# Please include the string: [perl #33641]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=33641 >
This code:
new P0, .OrderedHash
set P0["foo"], "Foo"
delete P0["
Luke Palmer <[EMAIL PROTECTED]> wrote:
> There's a pretty bad problem with calling the vtable proxy methods with
> keys that aren't constant. Best illustrated by example:
Fixed. Thanks for reporting
leo
Luke Palmer <[EMAIL PROTECTED]> wrote:
> There's a pretty bad problem with calling the vtable proxy methods with
> keys that aren't constant. Best illustrated by example:
> .sub _main
> newclass $P0, "Foo"
>
> find_type $I0, "Foo"
There's a pretty bad problem with calling the vtable proxy methods with
keys that aren't constant. Best illustrated by example:
.sub _main
newclass $P0, "Foo"
find_type $I0, "Foo"
new $P1, $I0
$I1 = $P1["foo"]
$S0 = "foo&
+++ config/gen/config_pm.pl 2004-07-31 12:35:15.219763800 +0300
@@ -54,7 +54,7 @@
while() {
if(/<>/) {
my $k;
- for $k(Configure::Data->keys) {
+ for $k(sort { lc $a cmp lc $b || $a cmp $b } Configure::Data->keys) {
my $v=Configure::Data->get($k);
if(defined $v) {
$v =~ s/(["\\])/\\$1/g;
.
>
>> new P3, .Key
>> set P2, P1
> ^^
> typo?
Yes, and should be an assign.
>> Perl 6 supports using full on objects as keys in its hashes. It seems
>> that having parrot do the same would be a Good Thing.
>
> The main problem here is, what doe
--- Piers Cawley <[EMAIL PROTECTED]> wrote:
> new P10, .PerlHash
> new P1, .PerlString
> set P1, "Bar"
> new P2, .Key
> set P2, P1
Oops! should be assign!
This is one of the reasons I think code like
$P0 = new PerlString
$P0 = "foo"
should be illegal. If people were forc
r"
> new P2, .Key
> set P2, P1
^^^
C aliases the two PMCs, both are pointing to the same PMC
then. You'd like to use C here.
> new P3, .Key
> set P2, P1
^^
typo?
> Perl 6 supports using full on objects as keys in its hashes. It seems
> that
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Togos <[EMAIL PROTECTED]> wrote:
>> Should aggregate PMCs (like PerlHash) be able to take
>> PMCs as keys? I mean so that:
>
>> $P0 = $P1[$P2]
>
> Just use a Key PMC for $P2.
>
> $P2 = new Key
&g
Togos <[EMAIL PROTECTED]> wrote:
> Should aggregate PMCs (like PerlHash) be able to take
> PMCs as keys? I mean so that:
> $P0 = $P1[$P2]
Just use a Key PMC for $P2.
$P2 = new Key
$P2 = "key_string"
...
leo
Le Thu, May 20, 2004 at 12:03:52PM -0700, le valeureux mongueur TOGoS a dit:
> Should aggregate PMCs (like PerlHash) be able to take
> PMCs as keys? I mean so that:
>
> $P0 = $P1[$P2]
>
> where $P1 is a PerlHash, would work. The way it works
> now is that it complains tha
Should aggregate PMCs (like PerlHash) be able to take
PMCs as keys? I mean so that:
$P0 = $P1[$P2]
where $P1 is a PerlHash, would work. The way it works
now is that it complains that you can't use a PMC as a
key. So my compiler has to spit out about 20 lines of
code for every sub-el
Bernhard Schmalhofer <[EMAIL PROTECTED]> wrote:
> I noticed that I couldn't use compound keys for setting values in a
> PerlHash.
> Retrieving values seems to work OK.
Thanks, applied.
leo
# New Ticket Created by Bernhard Schmalhofer
# Please include the string: [perl #28151]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=28151 >
Hi,
I noticed that I couldn't use compound keys for setting val
for compilers. Perl6 has
> %P0[$key} and @P0[$key]. This syntax imposes some type restriction (or
> coercion) on the key and defines the operation.
I am not sure that Perl6 syntax imposes any type restriction on keys.
If so, it would probably invalidate my example of two-way hash accessed
Hi Stef,
Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> Le Mon, Feb 09, 2004 at 09:52:28PM +0100, le valeureux mongueur
> Leopold Toetsch a dit:
Trop long d'introduction. Pas de valeur.
[ precise summary snipped ]
>P3 = PO[P1]# regular keyed access without flag
># set a flag in P1
Le Mon, Feb 09, 2004 at 09:52:28PM +0100, le valeureux mongueur Leopold Toetsch a dit:
> Stéphane Payrard <[EMAIL PROTECTED]> wrote:
>
> > The implementation of the methods key_* in keys.c imposed
> > to the PMCs to be of type Key. I don't' see the interest
>
Stéphane Payrard <[EMAIL PROTECTED]> wrote:
> The implementation of the methods key_* in keys.c imposed
> to the PMCs to be of type Key. I don't' see the interest
> for atomic keys that could be mere PMCs.
> This concretely means that one can write the followi
The implementation of the methods key_* in keys.c imposed
to the PMCs to be of type Key. I don't' see the interest
for atomic keys that could be mere PMCs.
This concretely means that one can write the following and save a
intermediate register:
P3 = PO[P1]
instead of:
P3 = ne
Clinton A. Pierce <[EMAIL PROTECTED]> wrote:
> Any thought on when PerlHashes will be able to allow us to iterate over the
> keys? Possibly do things like:
Please have a look at iterator.pmc, iter.t, and array.pmc. Its currently
implemented partially for arrays only.
I'm
Any thought on when PerlHashes will be able to allow us to iterate over the
keys? Possibly do things like:
new P0, .PerlHash
set P0["skeleton"], value
set P0["master"], value
set P0["Odin'sBro"], value
set P0["USPO
Aldo Calpini wrote:
I was the proposer. I have written an Iterator PMC back in the ol'
0.0.8 days, but then I was distracted and never finished my work.
I will try to reimplement my addition to 0.0.9 and submit a patch
ASAP (probably after 07 jan ;-).
Thanks, great.
cheers,
Aldo
leo
Leopold Toetsch wrote:
> There is a nextkey_keyed mentioned in pdd02_vtables.pod, which would
> almost be all to implement aggregate iterators. Missing is IMHO how to
> reset (start) an iteration.
> Also not too long ago, there was some proposal WRT an iterator class.
I was the proposer. I have
Jerome Quelin wrote:
Hi there,
How can one retrieve the keys of a PerlHash in Parrot assembly? Is there
a way to traverse a hash?
Not yet.
There is a nextkey_keyed mentioned in pdd02_vtables.pod, which would
almost be all to implement aggregate iterators. Missing is IMHO how to
reset
Hi there,
How can one retrieve the keys of a PerlHash in Parrot assembly? Is there
a way to traverse a hash?
Jerome
--
[EMAIL PROTECTED]
Steve Fink (via RT) wrote:
> - In imcc.y:main(), the stacktop was being set to an uninitialized
> value, making stackwalking sometimes *really* slow, sometimes crash,
> and sometimes work perfectly fine.
Yes, already fixed
> - My bison does not accept actions that do not end in a semicol
diff -p -u -r1.22 imcc.y
--- imcc.y 22 Sep 2002 17:38:47 - 1.22
+++ imcc.y 25 Sep 2002 03:07:55 -
@@ -35,10 +35,14 @@ int expect_pasm;
static SymReg *regs[IMCC_MAX_REGS];
+/* Bit vector saying whether argument i is a key */
+static int keyvec = 0;
static i
index by strings ? ie
>
> my @array is indexed('a'..'z');
>
>So if parrot wants to provide a method for compound keys, then the
>HL should be able to specify what type it is expecting each level
>to be.
>
>But the question also exists how this flag s
So if parrot wants to provide a method for compound keys, then the
HL should be able to specify what type it is expecting each level
to be.
But the question also exists how this flag should be used/checked.
For example, does the op use it to test the PMC type before calling
the method to fetch th
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
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 %
Dan Sugalski wrote:
> At 9:51 AM +0200 9/13/02, Leopold Toetsch wrote:
>
>> and is a perl6 %h{"a"}[0][1] a PASM P2["a";0;1]?
>
> Yes.
Fine, thought so too, thanks for your quick answer.
I have already a patch for it, I'll make an entry in t/pmc/perlhash.t too.
_But_:
What about all these bo
At 9:51 AM +0200 9/13/02, Leopold Toetsch wrote:
>The same system with a PerlHash doesn't:
[Snip]
>So the question arises to the syntax gurus, should it work like this?
Yes.
>and is a perl6 %h{"a"}[0][1] a PASM P2["a";0;1]?
Yes.
--
Dan
--
ey_next, gives
the final result, which is @a[0][1] in perl6 - DWIM.
This is functional with variables as keys too.
set I0, 1
set I1, 1
set I2, P1[I0;I1]
print I2 => 2
The same system with a PerlHash doesn't:
new P2, .PerlHash
set P2["a"], P1 #
> Here is a patch, that is selfcontained in packfile.c,
s/packfile/packout/
of course, sorry
leo
inter but some structure
>data -> { int idx, PMC *next } and store the constant index there.
>
> 3)
> The easierst solution (for me): provide the possibility to call a
> callback, that fills the packed structure with the required data.
> Actually I have also this packed data, b
} and store the constant index there.
3)
The easierst solution (for me): provide the possibility to call a
callback, that fills the packed structure with the required data.
Actually I have also this packed data, because on building the keys I
assemble this packed data, which on PackFile_Constan
1 - 100 of 118 matches
Mail list logo
