Bill Allombert on Tue, 04 Oct 2011 11:35:25 +0200


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: Fwd: embedding GP in GUI applications (android-port)


On Tue, Oct 04, 2011 at 12:40:35AM -0400, Charles Boyd wrote:
> Hi,
> 
> > There is a distinction to make between the gp programm and the GP
> > interpreter.
> > The gp programm is a standalone exectutable that provide an interface to
> > the
> > GP interpretor which is included in libpari. In the context of a graphical
> > application you probably want to use the GP interpreter directly since gp
> > mostly
> > provide the text-based user interface which you do not need.
> >
> 
> This makes sense and I have applied it to my application, which has the
> basic design:
> 
> libpari (cross-compiled for arm-linux-androideabi) ---> libparidroid (a
> small wrapper library I wrote) ---> Android GUI (written in Java, makes
> callbacks to libparidroid using the Java Native Interface).
> 
> Yes, you can embed the GP interpretor in your C program, since the GP
> > interpretor
> > is part of the libpari library. See examples/minigp.c in the distribution
> > for
> > an example.
> >
> 
> I have some questions about this:
> 
> (1) Do I need to link against libreadline/libhistory to use the
> gp_add_history() function (and its relatives)?

Unfortunately gp_add_history() is not part of libpari.
If you want to use add_history(), you will need libhistory.

> (2) What would be a typical use case of using gp_read_stream(FILE *file)?

gp_read_stream() read the content of file and evalute it as a GEN.
It is more general than gp_read_file() which only read named files.

> [I am considering if it would be better/easier for my Java application to
> communicate with libpari through some kind of FIFO rather than making a
> callback each time there is some input to evaluate.]

I am not sure that would work: gp_read_stream() read the file until EOF.

> (3) How can I return a string from pari_err() or pari_warn() when a command
> is entered incorrectly? Android redirects stdout to /dev/null, so the only
> way to give an error message is by sending a string to the Java application.

You need to divert pariErr. Create you own PariOUT object which is defined in
paristio.h as follow:

typedef struct PariOUT {
  void (*putch)(char);
  void (*puts)(const char*);
  void (*flush)(void);
} PariOUT;

so define your own method
PariOUT droidErr = {droidputch, droidputs, droidflush};
and set pariErr=&droidErr

We might provide a better solution in the future.

> Also, is it alright if I use the PARI/GP icon from your website on the
> Google Code repository for this project and as the icon for PariDroid
> application on the phone?

For the website, I would suggest you modify slightly the logo (maybe just
add "droid" under PARI) so that people do not expect that clicking on the logo
bring them to the PARI web site.

For the icon, actually the logo was the icon initially so it should be fine.

> I put this up some time ago on the website, but I thought I should ask for
> permission to do this.
> 
> Here is the link to website: https://code.google.com/p/paridroid/

Excellent!

I have written an inline arm assembly level0 kernel for PARI (a long time ago), but I 
have never commited it because at the time it was very hard to know whether an
ARM platform has 32x32->64 unsigned multiplication (UMULL)

Do you know if android platform consistently provide UMULL and whether the performance are
better than four MUL ?

Also it may be possible to add a flag to Configure to generate the android pari.cfg
automatically, now that we know what to write.

Cheers,
Bill