@Merth: I have seen that, but does that still require a python runtime?
I believe py2exe (see also: cx_freeze) just builds a package of the necessary dependencies and has a standard stub .exe that loads the interpreter core from a packaged dll and does its thing.
It's not really useful in this case, but offers a useful perspective on how light the interpreter's library needs are (very).
You might find Shed Skin useful, but there's a good chance it's too limited to be useful. If somebody find it interesting enough, I'll have a look at what's necessary to make the generated code Prizm-friendly.
It's not really useful in this case, but offers a useful perspective on how light the interpreter's library needs are (very).
You might find Shed Skin useful, but there's a good chance it's too limited to be useful. If somebody find it interesting enough, I'll have a look at what's necessary to make the generated code Prizm-friendly.
Globalmap wrote:
umm.... I hate to barge in, but what I meant was is it possible to code the program in python and comple it into a .g3a?
You're not barging in; it's your topic and we do tend to get into these sort of debates, especially when the topic of programming languages and their relative features and merits arises. As has been said, Python is normally an interpreted language, which means that we would want to write a .g3a Python interpreter, then let you run Python scripts stored in regular .py files in RAM or Flash. Tari wrote:
I believe py2exe (see also: cx_freeze) just builds a package of the necessary dependencies and has a standard stub .exe that loads the interpreter core from a packaged dll and does its thing.
It's not really useful in this case, but offers a useful perspective on how light the interpreter's library needs are (very).
Yeah, I didn't see it as being terribly useful in this case, but it is at least an example.
It's not really useful in this case, but offers a useful perspective on how light the interpreter's library needs are (very).
ibid. wrote:
You might find Shed Skin useful, but there's a good chance it's too limited to be useful. If somebody find it interesting enough, I'll have a look at what's necessary to make the generated code Prizm-friendly.
That would be very very neat, I think it's worth investigating.
After further investigation, shed skin appears to depend on several things we don't have. It links against libgc, and it complained about missing definitions for 'vector' when I created stub gc headers (skipping gc things would make it work, but leak memory like a sieve).
It also depends on PCRE, but I think that's just for the re module.
In short, we need more standard library bits for it to work.
It also depends on PCRE, but I think that's just for the re module.
In short, we need more standard library bits for it to work.
Darn, that's unfortunate. What about a skeletal Python interpreter for the Prizm, though; has anyone gone to greater depths in seeing what that might entail?
It configures but doesn't build! That's exciting enough that I think I'm going to work on it more:
Code:
It will probably work with standard library emulation, creating which is going to be my task.
Code:
[tari@Kirishima]$ CXX=sh3eb-elf-g++ CC=sh3eb-elf-gcc AR=sh3eb-elf-ar RANLIB=sh3eb-elf-ranlib CFLAGS=-nostdlib ./configure --host=sh3eb-elf --build=`config.guess`
[lots of lines snipped]
[tari@Kirishima]$ make
sh3eb-elf-gcc -c -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -nostdlib -I. -IInclude -I./Include -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
In file included from ./Modules/python.c:3:0:
Include/Python.h:25:19: fatal error: stdio.h: No such file or directory
compilation terminated.
make: *** [Modules/python.o] Error 1
It will probably work with standard library emulation, creating which is going to be my task.
I'd be happy to help out with it if you'd like. We have the glyph routines for the small font, I have rudimentary text input (although it would have to support multilineness, I guess), and I'm sure there's plenty of reference code out there to examine or even port.
About text input: I know this isn't really the most adequate thread to discuss it, but I think we should use system routines for text input instead of developing our own from scratch. Simon Lothar knows how to use them (but I don't think it is extensively documented anywhere), and they have been used in the latest version of the noteview add-in.
Using the syscalls for the cursor and its flags (shift, alpha, alpha lock) would help maintain coherence between different add-ins and the OS, as well as eventually benefit from things like the clipboard.
Just some thoughts
Using the syscalls for the cursor and its flags (shift, alpha, alpha lock) would help maintain coherence between different add-ins and the OS, as well as eventually benefit from things like the clipboard.
Just some thoughts
gbl08ma wrote:
Simon Lothar knows how to use them (but I don't think it is extensively documented anywhere), and they have been used in the latest version of the noteview add-in.
Gee, there's a fracking huge surprise. He remains obstinately silent in response to my PMs attempting to contact him.
Quote:
Using the syscalls for the cursor and its flags (shift, alpha, alpha lock) would help maintain coherence between different add-ins and the OS, as well as eventually benefit from things like the clipboard.
Just some thoughts
Absolutely agreed, but until you said that, I had little idea the OS even had coherent syscalls for such things. For example, as far as we know, each add-in implements its own math system. Just some thoughts
My concept, at least for initial versions, would be to throw all the stdio things over the link port, with the assumption that there would be some terminal on the other end.
This should be easier to manage than doing everything onscreen, and avoids the annoyances of managing everything on the screen.
This should be easier to manage than doing everything onscreen, and avoids the annoyances of managing everything on the screen.
Tari wrote:
My concept, at least for initial versions, would be to throw all the stdio things over the link port, with the assumption that there would be some terminal on the other end.
This should be easier to manage than doing everything onscreen, and avoids the annoyances of managing everything on the screen.
Oh, that's a great idea. That will save the trouble of trying to simultaneously debug graphics issues and Python issues. This should be easier to manage than doing everything onscreen, and avoids the annoyances of managing everything on the screen.
I'm not surprised if each add-in has its own math system, but text input has some syscalls (I'm not sure they do the whole work, but they at least help with the cursor and keyboard flags). And there are still many syscalls we are not sure what they do...
I've spent a while today working on adding the requisite headers, and it's coming along pretty well. I even appear to have found a bug in Python. I left off work with locale errors when compiling interpreter things for unicode objects.
Looking forward, we're going to want some prizm-specific libraries. Fortunately, native code extension modules are very easy to build into the interpreter, so it should be possible to simply build an interpreter blob that contains all the common modules.
Looking forward, we're going to want some prizm-specific libraries. Fortunately, native code extension modules are very easy to build into the interpreter, so it should be possible to simply build an interpreter blob that contains all the common modules.
KermMartian wrote:
gbl08ma wrote:
Simon Lothar knows how to use them (but I don't think it is extensively documented anywhere), and they have been used in the latest version of the noteview add-in.
Gee, there's a fracking huge surprise. He remains obstinately silent in response to my PMs attempting to contact him.
...
This might be useful, I don't know: [url=http://www.casio-scene.com/showthread.php?1377-Syscall-based-line-editor-(C-fx-9860)&p=12212#post12212]Link[/url]
Links to my calculator projects
I lurk #cemetech, if you want to contact me that and email are probably best.
I lurk #cemetech, if you want to contact me that and email are probably best.
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
» Go to Registration page
» Go to Registration page
» Goto page Previous 1, 2
» View previous topic :: View next topic
» View previous topic :: View next topic
Page 2 of 2
» All times are UTC - 5 Hours
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Advertisement