libfxcg moves forward: libc and Python

[Tari]

There was discussion recently on the feasibility of porting Python to the Prizm. Merth and I have been working on implementing big chunks of the C library to support Python, then.

The fruits of those efforts have been accumulating in the pycompat branch, and at this point many of the harder functions are done (I just finished implementing the core of printf).

I have yet to really get things running on the device (mucked about with serial, but I need a scope to figure out what I need to do with that before things will really work), but most of the functions have been tested in a cross-hosted environment (that is, on a PC).

Because there's nothing terribly interesting to look at right now, here's a screenshot from testing printf:


Edit by Merth: I'm stickying this.
_________________


Ask questions the smart way · タリ

[TheStorm]

For serial you might want to see if the source to FXTerm is available, it should have all the code you need to implement it.
_________________

"Always code as if the person who will maintain your code is a maniac serial killer that knows where you live" -Unknown

"If you've done something right no one will know that you've done anything at all" -Futurama

"Have a nice day, or not, the choice is yours." Tom Steiner

<Michael_V> or create a Borg collective and call it The 83+
<Michael_V> Lower your slide cases and prepare to be silent linked. Memory clears are futile.

[Tari]

I was looking at that earlier and forgot about it by the time I got home from work.

Looks like the source for fxterm isn't available, though.
_________________


Ask questions the smart way · タリ

[MPoupe]

[Tari]

Indeed, I referred to the .chm documentation when documenting those on WikiPrizm and subsequently adding them to libfxcg.

As far as the docs go everything was working (nothing returned failure), I just couldn't see anything electrically, so I chalked it up to a hardware configuration issue- hence I need to poke at it with a scope.
_________________


Ask questions the smart way · タリ

[elfprince13]

Which Python version are you aiming to support initially? This sounds like a cool project
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative

[Tari]

I've been working against the latest 3.x release (3.2.3). I even found a bug and got it fixed.

I can get good chunks of it to build at this point, but it's rather unhappy about some Unicode things, which I'll have to investigate further.
_________________


Ask questions the smart way · タリ

[elfprince13]

How difficult would it be to maintain a 2.7 build alongside it?
_________________
StickFigure Graphic Productions || VSHI: Vermont Sustainable Heating Initiative

[Tari]

Turns out it shouldn't be too difficult to build 2.7 as well. I've hit a few more functions 2.7 depends on for compiling, but they're things that I'm sure need to be implemented at some point to get the thing to link (fseek..).

The unicode issues I was having stemmed from bad configure values, which have now been resolved.

Current stumbling block is the import machinery depending on a stat() implementation, which I'd rather not have to implement (I'm against making this thing look like a POSIX system). It feels like a regression since things indicate that defining DONT_HAVE_STAT should avoid using it, but I have yet to investigate the use of such in 3.x (I know 2.7 is using it to check if things are directories).
EDIT: after poking at it some, I think I'll have to implement stat(), but only in a very basic form.
_________________


Ask questions the smart way · タリ

[Tari]

I've updated the nightlies to track our pycompat branch rather than master, as nothing's changing on master.

Tarball: http://media.taricorp.net/libfxcg-latest.tar.bz2
Build log: http://media.taricorp.net/libfxcg-latest.log

Highlights:

• Simpler build. Compiling libfxcg itself can be done simply with `make' from the root of the source tree, and fewer linker options are required when compiling your own programs.
  
• Many standard library components: math functions, string manipulation (including printf!) and file I/O wrappers.
  
• Better header and function names.

Yes, you read that right. You can now use fopen() and friends.

Caveats: big chunks of the I/O stuff (particularly file I/O) are untested. There are probably also corner cases in other functions that need to be worked out yet. I/O to the standard streams (stdin, stdout, stderr) is directed to the serial port, which I'm not sure if it works (again, untested code).

Setting up this bleeding-edge version on your old PrizmSDK 0.3 should be fairly easy:

• Unpack the include directory to the SDK include directory. Overwrite files where prompted, but do not overwrite types.h (just skip that one).
  
• Unpack the contents of the lib directory to the SDK lib directory. Overwrite where applicable.
  
• Modify your makefiles to use libc. This should just be a matter of removing "-lfxcg" and "-nostdlib" from the CFLAGS and adding "-nostartfiles" to LDFLAGS.

Some programs will now fail to compile since we've been removing some crufty headers. In most cases you'll simply have to change inclusions- post for help in such a situation.

I strongly encourage everyone to try out these new features so I can fix the inevitable bugs and get feedback on the changes. Get to it!
_________________


Ask questions the smart way · タリ

[gbl08ma]

libfxcg now supporting printf and fopen, etc. - sweet!

printf will save me from using dozens of concat()s and itoa()s, and file I/O will make porting existing code much easier.

Are the old file I/O functions (syscalls) still supported? This is important to allow older code to build.
_________________
My blog, where I write about random things... | tiny URL shortener
View JPEG images on your Prizm | Utilities for the Casio Prizm - clock, stopwatch, calendar/agenda, add-in manager and more!

[KermMartian]

Yes, they are building this as a separate set of new features rather than removing any existing features/support, as far as I can tell. I agree that it's great both that we're getting a solid stdlib and that Python support may be here soon.
_________________

[gbl08ma]

I don't think Python will be much faster than Basic with the exception that IMO it's a "better" language, that can also be written on the calculator if a text editor is ever developed.
_________________
My blog, where I write about random things... | tiny URL shortener
View JPEG images on your Prizm | Utilities for the Casio Prizm - clock, stopwatch, calendar/agenda, add-in manager and more!

[KermMartian]

[gbl08ma]

OK... my failure to pass a parameter to the tar command made types.h be overwritten. Does anyone have the previous one, or from where can I get it...?

EDIT: this time my backup system worked and I have a copy of the old file...
_________________
My blog, where I write about random things... | tiny URL shortener
View JPEG images on your Prizm | Utilities for the Casio Prizm - clock, stopwatch, calendar/agenda, add-in manager and more!

[Tari]

[gbl08ma]

OK, so as said on SAX, here are a list of things that need fixing:
* disp_tools.hpp is broken
* keyboard.hpp is lacking the definition for KEY_PRGM_0 (it should be 71)
* there are conflicting types for malloc and realloc in stdlib.h

And here's my build log for CGlock, with some errors caused by the new libfxcg and others caused by my code: http://pastebin.com/dBrcTPPF
_________________
My blog, where I write about random things... | tiny URL shortener
View JPEG images on your Prizm | Utilities for the Casio Prizm - clock, stopwatch, calendar/agenda, add-in manager and more!

[merthsoft]

[Tari]

It's there in the build log.

The problem stems from the removal of headers that correspond to things which we don't have source for. My plan is to extract the relevant object files from the old libfxcg.a and throw them in git as straight-up blobs, then re-add the relevant headers with _FXCG_MINICOMPAT guards.
_________________


Ask questions the smart way · タリ

[merthsoft]

Haha, whoops, soory. No more posting for me until I get some sleep.
_________________
Shaun