Hello!

For the last few days I have been working on a project I'm callling PyG3A.
Create a python file and turn it into a Prizm Addin with 1 command.

It is still a work in progress - most Python features do not currently work, but here is an example of what is currently implemented:


Code:

import fxcg.display
import fxcg.keyboard

def main() -> void:
    PrintXY(1, 1, "  Hello from Python!", 0, 0)

    key: int = None
    while 1:
        GetKey(ptr(key))


This produces the following C:

Code:

#include <fxcg/display.h>
#include <fxcg/keyboard.h>

void main(void) {
   PrintXY(1, 1, "  Hello from Python!", 0, 0);
   int key;
   while (1) {
      GetKey(&key);
   }
}


And works on the Prizm:


So, what do you think?
Will you use it once the program is more robust?
Do you have any suggestions?
What kind of options should the program have?

Please tell me here or make an issue on the GitLab.
That's very interesting! The current Python support on the CG-50 is somewhat underwhelming, because despite added performance and a true language compared to Casio BASIC, it doesn't have key input except for the interrupt key AC/ON. This could be a nice alternative!

I've seen a couple of "language" projects like this before, and most fail due to not knowing how to write parsers/compilers. You seem to know what you're doing however, so I'm really curious what you can do with it now!

Although I usually write pure C/asm with low-level tricks everywhere, I would probably make some simple programs with such as system, plus a great deal of publicity for Python enthusiasts that want true power at their fingertips.

I think a cool option would be support for CASIO's module as a built-in, so that you can compile programs from the official Python interpreter into add-ins directly (assuming of course you support the language features). This module which is called "casioplot" is of frightening simplicity with just 5 functions that almost directly map to syscalls after color conversion (some doc here in French).

My guess is you'll have the most trouble with object representations and data structures, since there are quite a lot of them. Do you have a plan for it? There are "simple" solutions like normal vectors for lists, self-balanced trees for set and dicts... it would just take a while to implement.

Also, do you want to enforce typing or allow some sort of dynamic variant type? On the one hand programs would be faster with static typing, on the other hand there are no easy C types to map complex data structures or objects to, so you'd need some sort of type analysis in your compiler or a runtime (x[index] is not the same thing depending on the type of x, unless you have objects with the __getitem__ method).

Well, good luck anyway. Very Happy
This is very nice! I wanted to create an add-in for the fx-CG50 for a while now but I'm not very familiar with C and because of that I wrote it as a python script for the calc which worked pretty well.
And now you could convert them into C programs and add-ins if you get everything implemented (which should run a lot faster)!

Can't wait to see how this project will turn out!
Lephe wrote:
That's very interesting! The current Python support on the CG-50 is somewhat underwhelming, because despite added performance and a true language compared to Casio BASIC, it doesn't have key input except for the interrupt key AC/ON. This could be a nice alternative!

I've seen a couple of "language" projects like this before, and most fail due to not knowing how to write parsers/compilers. You seem to know what you're doing however, so I'm really curious what you can do with it now!

Although I usually write pure C/asm with low-level tricks everywhere, I would probably make some simple programs with such as system, plus a great deal of publicity for Python enthusiasts that want true power at their fingertips.

I think a cool option would be support for CASIO's module as a built-in, so that you can compile programs from the official Python interpreter into add-ins directly (assuming of course you support the language features). This module which is called "casioplot" is of frightening simplicity with just 5 functions that almost directly map to syscalls after color conversion (some doc here in French).

My guess is you'll have the most trouble with object representations and data structures, since there are quite a lot of them. Do you have a plan for it? There are "simple" solutions like normal vectors for lists, self-balanced trees for set and dicts... it would just take a while to implement.

Also, do you want to enforce typing or allow some sort of dynamic variant type? On the one hand programs would be faster with static typing, on the other hand there are no easy C types to map complex data structures or objects to, so you'd need some sort of type analysis in your compiler or a runtime (x[index] is not the same thing depending on the type of x, unless you have objects with the __getitem__ method).


Well, good luck anyway. Very Happy


Currently, my biggest problem is things like pointers. I have methods ref and deref for & and *, but things like casting to void pointers, and other weird types will be annoying. I can do it using functions, but do think there would be a more pythonic way?

Currently, I'm forcing typing - but in the future I might infer types based on usage, kinda like TypeScript.

Quick question for anyone, do you think I should include fxcg libraries by default, so that I can do things like making print() run PrintXY?
I'm also wondering if I should keep track of the types needed in the libfxcg functions and cast and reference to match these types?
Quote:
Currently, I'm forcing typing - but in the future I might infer types based on usage, kinda like TypeScript.

Hmm I see, this means you will miss on Python features that rely pretty heavily on runtime typing (such as duck typing). I also suspect your type analysis would have a hard time with polymorphic data structures. For instance, what is the type of L1=[1,2]? If it's "list int", then what's the type of L2=[1,"str"] ? If that one is "list", then what's the type of L2[n] with n an integer?

I'm fairly certain you can't easily have both static types and polymorphic data structures like L2=[1,"str"]. To be honest, static types would be pretty nice and refreshing in my opinion, I would just suggest careful wording in the project name/description since users will constantly come with expectations of pure Python and hit all sorts of surprises. ^^

Quote:
Currently, my biggest problem is things like pointers. I have methods ref and deref for & and *, but things like casting to void pointers, and other weird types will be annoying. I can do it using functions, but do think there would be a more pythonic way?

Since your code is Python-driven and Python doesn't have pointers, you have the opportunity to do an initial analysis and decide how to use pointers.

For instance, you might decide to write a C wrapper around GetKey() that returns the value, which is much more Pythonic, and expose that in your fxcg module.

A general scheme might be like this: if a wrapper exists, pass all arguments by reference, and let the wrapper keep the pointers when it needs and remove them otherwise. This way you sort of let the C API regulate its own pointers without exposing them to Python. It wouldn't be strange in Python since passing arguments by value/reference looks exactly the same there (for lists/objects at least; for ints I suggest the return value method).

Quote:
Quick question for anyone, do you think I should include fxcg libraries by default, so that I can do things like making print() run PrintXY?
I'm also wondering if I should keep track of the types needed in the libfxcg functions and cast and reference to match these types?

I think it's absolutely fine to include fxcg libraries. In fact, why not support as much of the API as possible so that users of PyG3A are free to use all the functions to make elaborate programs? API support seems to be in the easier features here, so there's no reason to restrict it Smile

As for types, it depends on whether you want a PyG3A error or a GCC error on the call. Personally I think both are fine, and letting GCC emit errors saves you from either parsing or internalizing function prototypes + some logic for checking type compatibility which is sometimes slightly tricky.
Lephe wrote:
Quote:
Currently, I'm forcing typing - but in the future I might infer types based on usage, kinda like TypeScript.

Hmm I see, this means you will miss on Python features that rely pretty heavily on runtime typing (such as duck typing). I also suspect your type analysis would have a hard time with polymorphic data structures. For instance, what is the type of L1=[1,2]? If it's "list int", then what's the type of L2=[1,"str"] ? If that one is "list", then what's the type of L2[n] with n an integer?

I'm fairly certain you can't easily have both static types and polymorphic data structures like L2=[1,"str"]. To be honest, static types would be pretty nice and refreshing in my opinion, I would just suggest careful wording in the project name/description since users will constantly come with expectations of pure Python and hit all sorts of surprises. ^^

Quote:
Currently, my biggest problem is things like pointers. I have methods ref and deref for & and *, but things like casting to void pointers, and other weird types will be annoying. I can do it using functions, but do think there would be a more pythonic way?

Since your code is Python-driven and Python doesn't have pointers, you have the opportunity to do an initial analysis and decide how to use pointers.

For instance, you might decide to write a C wrapper around GetKey() that returns the value, which is much more Pythonic, and expose that in your fxcg module.

A general scheme might be like this: if a wrapper exists, pass all arguments by reference, and let the wrapper keep the pointers when it needs and remove them otherwise. This way you sort of let the C API regulate its own pointers without exposing them to Python. It wouldn't be strange in Python since passing arguments by value/reference looks exactly the same there (for lists/objects at least; for ints I suggest the return value method).

Quote:
Quick question for anyone, do you think I should include fxcg libraries by default, so that I can do things like making print() run PrintXY?
I'm also wondering if I should keep track of the types needed in the libfxcg functions and cast and reference to match these types?

I think it's absolutely fine to include fxcg libraries. In fact, why not support as much of the API as possible so that users of PyG3A are free to use all the functions to make elaborate programs? API support seems to be in the easier features here, so there's no reason to restrict it Smile

As for types, it depends on whether you want a PyG3A error or a GCC error on the call. Personally I think both are fine, and letting GCC emit errors saves you from either parsing or internalizing function prototypes + some logic for checking type compatibility which is sometimes slightly tricky.


I do plan on documenting what is required, is and isn't supported, and adding errors - but for now I'm just working on making the tool itself.

Yeah, having my own python libraries that interface with libfxcg would be better.
  
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
Page 1 of 1
» 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

 

Advertisement