Hi Antonio,
On Tue, Apr 04, 2006 at 10:16:32AM +0200, Antonio Cuni wrote:
def ll_list_is_true(lst):
return lst is not None and len(lst) != 0
I hoped that the rtyper was smart enough to convert 'len(lst)' into my
low-level op 'list_len', but it wasn't: indeed, it generated code that
Hi Armin, hi Niklaus
Armin Rigo wrote:
I see you added SomeOOList to annoation.model.lltype_to_annotation().
There is already a generic 'def len()' in the base class SomeObject, so
that's how the annotator is happy with your ll function's 'len(lst)'.
Fine here. If you wanted a .length() method
Hi Antonio
Antonio Cuni wrote:
I've spent last days working on this topic: I tried to refactor the code
for making rlist type-system specific as rtuple, rclass and others
already was.
It has been a bit difficult because it was my first hacking in the
rpython directory: I had to read the
Niklaus Haldimann wrote:
Oops, I didn't intend to invalidate your work. ;) I actually checked
your user directory yesterday, because you said in an earlier mail that
you would work on the branch there. But since I didn't see any changes
related to rlist I assumed you decided to postpone this ...
Hi Niklaus,
you have just preceded me by about 2 hours... I would have sent a mail
about rlist anyway.
I've spent last days working on this topic: I tried to refactor the code
for making rlist type-system specific as rtuple, rclass and others
already was.
It has been a bit difficult because
Hi,
I've spent last hours reading sources in the rpython directory, trying
to deeper understand how lltypesystem and ootypesystem work: I've
noticed that the low level representations of strings and lists are the
same in both typesystem.
My question is: is it a design choice or nobody has
Hi Antonio
Antonio Cuni wrote:
I've spent last hours reading sources in the rpython directory, trying
to deeper understand how lltypesystem and ootypesystem work: I've
noticed that the low level representations of strings and lists are the
same in both typesystem.
My question is: is it a
