January 2000 - GiNaC-devel

Archiving of expressions
by Christian Bauer 19 Jan '00

19 Jan '00

Hi! The long-awaited archiving (aka I/O) of expressions is now implemented in the latest CVS version (except for the classes idx and structure and all classes derived from idx and indexed, because these seem still to be undergoing changes). A new chapter in the tutorial explains how to use the new features. There is now a global registry (implemented in registrar.*) for all archivable classes (= basic and derived classes). To implement archiving for you classes, do the following: - add the GINAC_DECLARE_REGISTERED_CLASS(foo, bar) line to the beginning of the class declaration - add the GINAC_IMPLEMENT_REGISTERED_CLASS(foo, bar) line to the beginning of the *.cpp file of the class - implement the unarchiving constructor and the archive() and unarchive() member functions in your class If your class doesn't add any member variables to its superclass which have to be stored in the archive, you must at least call the unarchiving constructor and the archive() function of the superclass (see add.cpp for an example of how to do this minimal implementation of archiving). If you _do_ have member variables which need to be stored, they have to be added to the archive_node in the archive() function and retrieved from there in the unarchiving constructor (see power.cpp for a simple example, matrix.cpp for a more complex one). The unarchive() function is almost always the same in all classes (for exceptions, see symbol.cpp and constant.cpp). Unarchiving of constants is currently sub-optimal. Only the three constants that we provide (Pi, Catalan, EulerGamma) can be unarchived. A global registry for all existing constants should be implemented. Also, archiving floating-point numbers will lose precision (because they are stored as a decimal fraction). This is being worked on. The small program "viewgar" in the tools directory is a stand-alone viewer for archive files. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/

1 0

Undefined symbols for ginsh
by Jeff Greco 19 Jan '00

19 Jan '00

To Whom It May Concern: I am using: Operating system: SunOS samsun 5.6 Generic_105181-03 sun4u sparc SUNW,Ultra-Enterprise Compiler: egcs-2.91.57 CLN: version 1.0.2 CLN and GiNaC are configured with default settings, except that CLN is only shared libraries. My linker is complaining about undefined symbols in 'ginsh_parser.o'. Any way that you can help is greatly appreciated. Here is the output from make: make all-recursive make[1]: Entering directory `/dumptruck/GiNaC-0.4.1' Making all in ginac make[2]: Entering directory `/dumptruck/GiNaC-0.4.1/ginac' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/dumptruck/GiNaC-0.4.1/ginac' Making all in check make[2]: Entering directory `/dumptruck/GiNaC-0.4.1/check' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/dumptruck/GiNaC-0.4.1/check' Making all in ginsh make[2]: Entering directory `/dumptruck/GiNaC-0.4.1/ginsh' /bin/sh ../libtool --mode=link g++ -g -O2 -o ginsh ginsh_parser.o ginsh_lexer.o ../ginac/libginac.la -lcln -lstdc++ g++ -g -O2 -o .libs/ginsh ginsh_parser.o ginsh_lexer.o ../ginac/.libs/libginac.so -lcln -lstdc++ -lcln -lstdc++ -R/usr/local/lib Undefined first referenced symbol in file rl_basic_word_break_characters ginsh_parser.o rl_readline_name ginsh_parser.o filename_completion_function ginsh_parser.o completion_matches ginsh_parser.o rl_completion_append_character ginsh_parser.o rl_line_buffer ginsh_parser.o rl_attempted_completion_function ginsh_parser.o ld: fatal: Symbol referencing errors. No output written to .libs/ginsh collect2: ld returned 1 exit status make[2]: *** [ginsh] Error 1 make[2]: Leaving directory `/dumptruck/GiNaC-0.4.1/ginsh' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/dumptruck/GiNaC-0.4.1' make: *** [all-recursive-am] Error 2 Thanks, Jeff Greco Jgreco(a)siichi.com

2 1

ToDo-list
by Richard B. Kreckel 12 Jan '00

12 Jan '00

Good morging, Higher forces (drunken collegues) have just urged me to send this mail to the list: ;*) Today I have written a little summary about possible future extensions of GiNaC accessible at <http://www.ginac.de/ToDo.html>. Feel free to comment on it. regards -rbk. PS: I have been wondering for a while about ASSERT. Don't we need two different kinds of assertions? One for things within the library like the GINAC_ASSERT(is_canonical()); at line 94 in ginac/mul.cpp and one like the GINAC_ASSERT(is_exactly_of_type(other, matrix)); at line 255 in matrix.cpp? (Both lines refer to current CVS stuff.) The first one marks an oops that can only happen to developers of the library, the second can happen to anybody. In a distribution, the first one may be ommitted from the normal runtime-library, but not the second, which may not even be fatal but only issue a warning. Maybe we do need a soft and a hard ASSERT??? -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

2 1

GiNaC porting status
by Richard B. Kreckel 10 Jan '00

10 Jan '00

I once wrote about 64-bit issues and that GiNaC builds fine on Linux/AXP except for shared libraries, where everything segfaulted immediately. Somebody guessed we were suffering from some "static initialization order fiasco". I haven't looked into that since then---which is good, since I just came across this quote from the current GCC caveats list <http://gcc.gnu.org/gcc-2.95/caveats.html>: : Exception handling may not work with shared libraries, particularly on : alphas, hppas, rs6000/powerpc and mips based platforms. Exception : handling is known to work on x86 GNU/Linux platforms with shared : libraries. So, it's not our problem, is it? Doesn't sound good, though. Happy hacking -rbk. -- Richard Kreckel <Richard.Kreckel(a)Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>

1 0