When launching my port, at the point it calls pm_run() it shows the
next traceback:
Traceback (most recent call first):
File "../lib/__bi.py", line 25, in __bi
AttributeError detected by interp.c:1315
Looking at the source code, the line 25 of __bi.py is "def abs(n):",
and in fact, it's the first python line on the file, and the line 1315
at interp.c it's related to LOAD_ATTR bytecode raising an
AttributeError as default option, since the object type that it's
being used for the attributes it's a None object. Using some traces on
the code it seems built-ins are not being correctly loaded, raising
the error at dict_setItem() at global.c:207 (i think is because
PM_PBUILTINS is NULL), previously raising another one at
global_loadBuiltins() at global.c:199 when calling
interpret(INTERP_RETURN_ON_NO_THREADS). I have found this last one
putting a PM_RETURN_IF_ERROR(retval); after it (it shouldn't have
one?) giving in both cases the same traceback.
Besides the fact that's running on QEmu using a multiboot header and
i'm using a print "hello world" line as main.py, the virtual machine
code it's the same that the V09 from the Mercurial repository. Anyone
knows what's the problem and how i can be able to solve it? It's just
the last pieze of the puzzle that i need to have p14p working on
x86... :-D
Host:
Pentium Dual-Core E5500 64bits
4GB RAM
Linux Ubuntu 11.04 64bits
Platform:
QEmu virtual machine 32bits, launched from command line using --kernel
parameter using main.out as kernel image
Multiboot header from Multiboot Specification example code
(http://www.gnu.org/software/grub/manual/multiboot/multiboot.html#Examples)
P14p desktop platform used as basis with default values (heap = 0x2000)
Compilation extra flags: -nostdinc -fno-builtin -nostdlib
-fno-stack-protector -m32
Using home-made stdlib for p14p required functions
Full code at http://code.google.com/r/piranna-p14p/source/browse
--
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux
Are you saying that with python 2.7 you have been able to reproduce the bug, and also check that with python 2.6 it works? They are awesome news!!! :-D Now it's too late at Spain, but i promise i'll try it tomorrow!!! :-)
Sended from my Android cell phone, please sorry the lack of format on the text and my fat thumbs :-P
--
You are subscribed to the "python-on-a-chip" (or p14p for short) Google Group.
Site: http://groups.google.com/group/python-on-a-chip
Ok, so now i'll go to clean up my code and upload it. It's from the
branch v09, but since it was so easy to solve, i don't think i will
have problems updating it to v10 :-)
2012/2/15 pir...@gmail.com <pir...@gmail.com>:
--
Python 2.7 has bytecodes that are NOT supported. CPython 2.7's bytecodes are similar to CPython 3.0 and I tried to port to CPython 3.0, but ran into a wall (details are here: http://code.google.com/p/python-on-a-chip/issues/detail?id=14 see, especially, the attachment: dwh-WhyNotPython30.txt )
!!Dean
> Python 2.6 is REQUIRED at this time.
>
I think it would be an interesting thing to have it in huge words in a very visible place like the main page of the readme files... ;-) And if it's there yet, my apologices, i didn't saw it :-(
> Python 2.7 has bytecodes that are NOT supported. CPython 2.7's bytecodes are similar to CPython 3.0 and I tried to port to CPython 3.0, but ran into a wall (details are here: http://code.google.com/p/python-on-a-chip/issues/detail?id=14 see, especially, the attachment: dwh-WhyNotPython30.txt )
>
Good forensics! :-D Would you be able to take a look for 2.7? Python 3 is desirable (and with compile time modulable unicode support would be a plus :-P), but i think a full fledget Python 2.7.2 would be a good treat being the last of the 2.x series if it's not so much difficult to add support for it... :-)
!!Dean