Love the PyMite concept. This would be a serious weapon in my arsenal.
Sadly I've tried to compile it on 3 different operating systems and it fails every time. I've downloaded v9, tried the steps in src/platform/avr/README (which simply means "make" with no changes to the makefile or anything). It began to compile, then failed on a fresh Cygwin, failed a different way on a fresh Ubuntu 12.04 LTS Desktop, and failed a third way on a fresh Debian 6 (with several GCC and AVR-related packages added, and Python available already).
Without getting into too much troubleshooting detail here, does anybody know of *ANY* platform on which PyMite will **DEFINITELY** compile?? I will simply create that platform and try to "make" there. I have no taste for trying to troubleshoot a configuration of a C compiler that nobody else is using.
I understand AVR may not be the target most people are using. I do plan to transition to ARM at some point, especially if PyMite is as awesome as I think it would be. But AVR hardware is what I have available today, and PyMite is falling on its face so far. Not an auspicious start.
I recommend compiling for the desktop/posix platform first. You can get immediate results that way without having to flash a microcontroller. Please use the latest source from the repository instead of a release (releases are very dated): http://code.google.com/p/python-on-a-chip/source/checkout
The default build assumes a 64-bit host machine. If you are on a 64-bit architecture, just type make. If you are on a 32-bit arch, type "make PLATFORM=desktop". Let us know how it goes from there.
Oh, also, make sure your installed CPython is 2.6.x
> Love the PyMite concept. This would be a serious weapon in my arsenal.
> Sadly I've tried to compile it on 3 different operating systems and it fails every time. I've downloaded v9, tried the steps in src/platform/avr/README (which simply means "make" with no changes to the makefile or anything). It began to compile, then failed on a fresh Cygwin, failed a different way on a fresh Ubuntu 12.04 LTS Desktop, and failed a third way on a fresh Debian 6 (with several GCC and AVR-related packages added, and Python available already).
> Without getting into too much troubleshooting detail here, does anybody know of *ANY* platform on which PyMite will **DEFINITELY** compile?? I will simply create that platform and try to "make" there. I have no taste for trying to troubleshoot a configuration of a C compiler that nobody else is using.
> I understand AVR may not be the target most people are using. I do plan to transition to ARM at some point, especially if PyMite is as awesome as I think it would be. But AVR hardware is what I have available today, and PyMite is falling on its face so far. Not an auspicious start.
Using the same make command, the v9 source code actually got further than this (also on Debian). It produced an executable file /src/platform/desktop/main.out, which gives the following error when executed: Traceback: file "main.py" line 18, in main ImportError detected by module.c:99 ... which refers to the one important module in the system ( I looked).
Ubuntu and Cygwin, and Windows 7 were not usable as they all have Python 2.7 on them.
So it looks like it's compiling fine up until an error (that I've never seen) at src/vm/sli.c:194
The make.out shows the compiler is "cc". I assume this maps to gcc on your OS? Can you tell me what version?
In the mean-time, you can just comment out that if-statement because it's only catching a special case of ltoa when the maximum-negative value is the argument. See how far compilation goes after that.
/* Special case (can't convert it to positive value) */
/*
if (number == -2147483648)
{
sli_memcpy(buf, (unsigned char *)"-2147483648", 11);
return PM_RET_OK;
}
*/
> Using the same make command, the v9 source code actually got further than this (also on Debian). It produced an executable file /src/platform/desktop/main.out, which gives the following error when executed:
> Traceback: file "main.py" line 18, in main
> ImportError detected by module.c:99
> ... which refers to the one important module in the system ( I looked).
> Ubuntu and Cygwin, and Windows 7 were not usable as they all have Python 2.7 on them.
> cb750
> On Friday, June 22, 2012 4:20:03 PM UTC-5, dwhall wrote:
> I recommend compiling for the desktop/posix platform first. You can get immediate results that way without having to flash a microcontroller.
Correct - cc does map to gcc (standard gcc package for Debian 6). Version is shown in attached cc.out which is output of cc -v.
I applied the patch you suggested. Also used hg to verify that the working folder was at the head (it was). Looks like it compiled this time (see make.out).
Then I realized I also had to do a make ipm to try it out. So I did a "make PLATFORM=desktop ipm 2>&1 | tee ipm.out" from the system command shell (see attachment). As a test I hit Enter a few times. Then I keyed in the digit 1 and hit Enter (did those 3 times). Those caused the "Connection write error" that you see in the output. Then I hit Ctrl-D to quit. It output a traceback (as shown) and the process exited.
With CPython, this "1" input results in a correct output of "1" and another prompt. I saw this "1" test used in another post on this forum, where it also caused a fatal error, but now I can't find that again.
Since it complains of a broken pipe, I made sure I wasn't running it under Midnight Commander or some other shell. This is straight from dash on a tty (not a xterm etc.). Apparently dash is the standard shell on Debian 6. Not sure when they switched from "bash" to "dash"... I've not seen that one before. So I started a bash, and verified it was in fact GNU bash, a different binary, and repeated the test. Same result.
ipm on the desktop uses pipes as the I/O connection between the ipm-host program on the desktop and the ipm-target process running the VM. So don't redirect the I/O streams. Just do: "make PLATFORM=desktop ipm"
If you have any trouble, do a make clean just to be sure: "make clean; make PLATFORM=desktop ipm"
> Correct - cc does map to gcc (standard gcc package for Debian 6). Version is shown in attached cc.out which is output of cc -v.
> I applied the patch you suggested. Also used hg to verify that the working folder was at the head (it was). Looks like it compiled this time (see make.out).
> Then I realized I also had to do a make ipm to try it out. So I did a "make PLATFORM=desktop ipm 2>&1 | tee ipm.out" from the system command shell (see attachment). As a test I hit Enter a few times. Then I keyed in the digit 1 and hit Enter (did those 3 times). Those caused the "Connection write error" that you see in the output. Then I hit Ctrl-D to quit. It output a traceback (as shown) and the process exited.
> With CPython, this "1" input results in a correct output of "1" and another prompt. I saw this "1" test used in another post on this forum, where it also caused a fatal error, but now I can't find that again.
> Since it complains of a broken pipe, I made sure I wasn't running it under Midnight Commander or some other shell. This is straight from dash on a tty (not a xterm etc.). Apparently dash is the standard shell on Debian 6. Not sure when they switched from "bash" to "dash"... I've not seen that one before. So I started a bash, and verified it was in fact GNU bash, a different binary, and repeated the test. Same result.
Somehow the desktop platform is working now. (I'll proceed to explore its capability in the meantime.) I suspected interference from the redirection right away yesterday. So I'd already re-tested without that. And I repeated the same commands (with & without redirection) today, and it worked both ways today. The machine wasn't rebooted or touched in any way between days. I suspect the make clean is what fixed it, as I did not do a make clean before every single attempt yesterday. Only some of them.
So... moving on to the AVR build... fails horribly when i follow the instructions in the readme (unmodified makefile - standard AVR part number and clock frequency): make clean cd src/platform/avr make ... (does first invocation of avr-gcc) in file included from bytearray.c:27: pm.h:35:20: error: stdint.h: no such file or directory ... and goes way downhill from there. Hundreds of messages due to the missing header declarations. This machine has installed avr-gcc and all related packages I could find (binutils etc.).
So, try it another way: cd ~/python-on-a-chip make clean make PLATFORM=avr 2>&1 | tee make.out ... fails with an illegal bytecode (89/0x59/BUILD_CLASS). See attached make.out. Are we still supporting the AVR platform or is it history?
Fails the same way without redirection.
Alternatively, I've gotten my hands on a NXP LPC2478 (ARM 7 TDMI-S core with Thumb, 64 Kbyte RAM) on a decent board. Is there a generic ARM platform or some other platform in p14p that can run on that? Closest match I see in the code is the mbed platform. How would it react to that chip? I realize there would be no peripheral drivers. I'd add those as soon as I've seen it start up and not throw an error when I type "1".
On Tuesday, June 26, 2012 7:35:52 PM UTC-5, dwhall wrote:
> ipm on the desktop uses pipes as the I/O connection between the ipm-host > program on the desktop and the ipm-target process running the VM. So don't > redirect the I/O streams. Just do: "make PLATFORM=desktop ipm"
I try to support the platforms in src/platform/; however, I don't have the resources to regularly test on every platform. So I rely on the community to tell me when things go wrong. You've identified at least 2 issues with the avr platform. Thank you.
1) The #include trouble with stdint.h is new. I just installed avr-gcc 4.7.0 and got the same error. A stdint.h file exists, but it is a proxy; it doesn't have all the "int8_t" typedefs for which it is included. I'll have to dive into the docs to see what is the reason for this new proxy file.
2) The next error where BUILD_CLASS is not supported is partly a configuration issue and partly a "avr not keeping up with the baseline" issue. Each platform has a way to configure what features are supported. In the default branch (r09) the files src/platform/<platform>/pmfeatures.h and pmfeatures.py are where you set what features are supported. "Features" in general mean that for every feature you want, your platform needs to have enough program memory and RAM to support the feature. The Classes feature is a biggie, it takes about 1K of RAM above the 4K RAM minimum so that's why HAVE_CLASSES is not enabled for the avr platform by default. If your AVR has over 4K, you should enable HAVE_CLASSES.
However, the default baseline seems to have reached a point where it assumes all platforms support classes. It is difficult to conditionally include/exclude a specific function in a python file. So instead of trying to automate that in the build, I am relying on the programmers to take care of it for some platforms. If your platform doesn't have the RAM to support classes, you'll have to comment out the classes in src/lib/__bi.py . In the v10 branch (which is where future development is headed), nearly every feature is enabled, so this problem doesn't exist anymore.
No the mbed build won't be of help for you, it uses the mbed cloud compiler. The STM32 platform is cortex and uses the arm-none-eabi toolchain, so it might be a starting point.
> Somehow the desktop platform is working now. (I'll proceed to explore its capability in the meantime.) I suspected interference from the redirection right away yesterday. So I'd already re-tested without that. And I repeated the same commands (with & without redirection) today, and it worked both ways today. The machine wasn't rebooted or touched in any way between days. I suspect the make clean is what fixed it, as I did not do a make clean before every single attempt yesterday. Only some of them.
> So... moving on to the AVR build...
> fails horribly when i follow the instructions in the readme (unmodified makefile - standard AVR part number and clock frequency):
> make clean
> cd src/platform/avr
> make
> ... (does first invocation of avr-gcc)
> in file included from bytearray.c:27: pm.h:35:20: error: stdint.h: no such file or directory
> ... and goes way downhill from there. Hundreds of messages due to the missing header declarations. This machine has installed avr-gcc and all related packages I could find (binutils etc.).
> So, try it another way:
> cd ~/python-on-a-chip
> make clean
> make PLATFORM=avr 2>&1 | tee make.out
> ... fails with an illegal bytecode (89/0x59/BUILD_CLASS). See attached make.out. Are we still supporting the AVR platform or is it history?
> Fails the same way without redirection.
> Alternatively, I've gotten my hands on a NXP LPC2478 (ARM 7 TDMI-S core with Thumb, 64 Kbyte RAM) on a decent board. Is there a generic ARM platform or some other platform in p14p that can run on that? Closest match I see in the code is the mbed platform. How would it react to that chip? I realize there would be no peripheral drivers. I'd add those as soon as I've seen it start up and not throw an error when I type "1".
> Thanks for your advice so far.
> cb750
> On Tuesday, June 26, 2012 7:35:52 PM UTC-5, dwhall wrote:
> ipm on the desktop uses pipes as the I/O connection between the ipm-host program on the desktop and the ipm-target process running the VM. So don't redirect the I/O streams. Just do: "make PLATFORM=desktop ipm"
Thanks Dean - lots of helpful info there for anybody facing similar issues.
Sounds like I should buy a mbed board right away, since that's the reference platform. Plus I don't even have to set up the C compiler for it. You and I would both use the same compiler already. I'd buy the board for the sole purpose of running p14p. p14p seriously looks like the Holy Grail to me (no pun intended). It will be a really expressive and powerful platform with just a little bit of app-specific glue added in C.
So which mbed board do you recommend today? I mean solely in terms of maximizing compatibility and chances of success in executing p14p. I understand they've added at least 1 model in the last few months.
On Wednesday, June 27, 2012 10:46:17 PM UTC-5, dwhall wrote:
> I try to support the platforms in src/platform/; however, I don't have the > resources to regularly test on every platform. So I rely on the community > to tell me when things go wrong. You've identified at least 2 issues with > the avr platform. Thank you.
> Thanks Dean - lots of helpful info there for anybody facing similar issues.
> Sounds like I should buy a mbed board right away, since that's the reference platform. Plus I don't even have to set up the C compiler for it. You and I would both use the same compiler already. I'd buy the board for the sole purpose of running p14p. p14p seriously looks like the Holy Grail to me (no pun intended). It will be a really expressive and powerful platform with just a little bit of app-specific glue added in C.
> So which mbed board do you recommend today? I mean solely in terms of maximizing compatibility and chances of success in executing p14p. I understand they've added at least 1 model in the last few months.
> cb750
> On Wednesday, June 27, 2012 10:46:17 PM UTC-5, dwhall wrote:
> I try to support the platforms in src/platform/; however, I don't have the resources to regularly test on every platform. So I rely on the community to tell me when things go wrong. You've identified at least 2 issues with the avr platform. Thank you.
