|Bill Allombert on Thu, 06 Nov 2003 13:51:21 +0100|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: Description system TODO list|
Hello PARI developers, I plan to fix the outstanding problems preventing release of PARI 2.2.7 and to allow gp2c to be compatible with PARI 2.2.7. > Here a list of issues that need to be ironed out > with the description system: > > 1) Changing a src/functions/xxx/yyy file does not trigger the rebuild > of src/desc/Def file. This is painful with CVS. I believe this is fixed for good now. > 2) This is a good time to get rid of 'valences'. Done. > 3) 'make install' should install sufficient data to build GP2C > in a fixed location: > dft.Config.in,src/desc/Def and probably src/desc/PARI/822.pm. That needs to happen. We have essentially to decide where we put the data. dft.Config.in belong to /usr/lib/pari. Maybe /usr/lib/pari/pari.cfg src/desc/Def belong to /usr/share/pari. Maybe /usr/share/pari/interface.gz We can eventually rename Def to something else. src/desc/PARI/822.pm belong to /usr/share/pari/PARI/822.pm unless we want to make it available to regular perl use (?) [BTW, if a perl expert could review the perl scripts to tell us what version of perl is required and what we can do about this, I will appreciate greatly.] Do you have idea for better name/path ? > 4) Make GP2C to use the above. This is implemented but not commited to CVS. > 5) Fix Math::PARI to use the above. (Ilya, my offer to help still stand). I suppose this wait for 3). > 6) Add the Description: material in GP2C to GP. Partly done, but there still some missing data: 1) Operators (+,-,&&,etc.) definition. 2) Member functions. 3) extra GP2C function. 4) internal GP2C interface. 1) I propose we add a directory symbolic_operators with file name named after the name of the PARI function without the g prefix. (add, sub, etc.). Inside we use the GP2C name of the operator (_!,_+_) as Name:. This avoid having non alphanumeric characters in filename. (And anyway _/_ is not a valid UNIX filename). Operators will need to live in a new Class: to not be read by GP. 2) I would like we chage the way member functions are handled inside GP to be just regular function named _.xxx in the database. When a.xxx is called, gp look up _.xxx in the database and call it. This would allow to install member function directly with install() and simplify handling a bit. In particular member function will not need to live in a new Class: 3) extra GP2C functions. They are functions usefull with gp2c but close to noop with GP, like gcopy. I will add them in a new class, though it would be nice to be able to activate them under GP for testing GP scripts that use them. Class: gp2c 4) internal GP2C interface. This is implementation of some gp2c interface that may depend of the PARI version. Class gp2c_internal. In short I propose to add 4 directories: functions/symbolic_operators Class: operators functions/member_functions functions/gp2c Class: gp2c functions/gp2c_internal Class: gp2c_internal Comments ? > 7) Document the Description: field format. I have written such a document. I will release it at some point (but please ask me a copy if you need it). > We can also add 'disabled' C-function in the interpretor that can > be enabled wih install() without the need for the prototype. I would like we implement this one. It can be especially useful on platform where install() does not work by adding the pointer to the function in the gp binary instead of dlopen() it. Cheers, Bill.