July 2006 - GiNaC-list

Re: [GiNaC-list] Python wrapper for a GiNaC derived library
by Vladimir Kisil 10 Aug '06

10 Aug '06

Ondrej Certik ondrej at certik.cz write on Thu Jul 20 00:13:29 CEST 2006 > We also created swiginac (http://swiginac.berlios.de/) for those, who > are interested in using ginac from python. > just my opinion: boost-python took ages to compile on my machine and > the errors were completely unreadable. swig compiles much faster, and > also it seems easier to learn. Do others have similar experience, or > totally different? I agree that both BoostPython and pyGiNaC have some issues and may be willing to make my library wrap in swiginac as well. However the swiginac is not supporting the new tinfo system and I cannot see right now how to patch it. Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

6 18

Results of GiNaC (& CLN) builds
by Richard Haney 06 Aug '06

06 Aug '06

Appended to this message is the result of building and testing GiNaC with "make check-TESTS". In summary, all three of the "runs" (run_exams, run_checks, run_times) failed although some of the subtests passed. Also appended are listings of the "exams.out", "checks.out", and "times.out" files. Here are some relevant system specs: OS: Windows XP gcc: gcc version 3.4.2 (mingw-special) ld: GNU ld version 2.15.91 20040904 installer package (for mingw tools): devcpp-4.9.9.2_setup.exe gdb: version 5.2.1 (from gdb-5.2.1-1.exe ) _mingw.h: #define __MINGW32_VERSION 3.7 w32api.h: #define __W32API_VERSION 3.2 bash (for environment variables & executing configure & make commands): GNU bash, version 2.05b.0(8)-release (i686-pc-cygwin) CLN: version 1.1.11 GiNaC: version 1.3.4 Hopefully, with my description of the problems someone can provide information on how to resolve them and perhaps clear up some other dubious points that this description suggests. Hopefully, the problems are even very simple to correct. I decided to build the readline library although I suppose I may have been able to use "cygreadline5.dll"; in fact a test (after I had partially built the readline library) suggested that this is likely so; I surmise that essential .dll linkage specifications tend to be more stable and universal (and compiler-independent) than are static library linkage specifications. (The static cygwin libraries were most likely built with an "ancient" gcc and I surmised that they probably would not be compatible with a more recent gcc's output -- I think I've tried linking to some of them before.) I also built the termcap library to use with the examples in the readline library build. First, I briefly describe the problems with CLN: In building CLN I had to do considerable finagling with the Makefiles. (Typically, as from earlier experience in building an earlier version of CLN and GiNaC, I had to temporarily comment out the mingw's make.exe so that Borland's make.exe (the next make.exe in PATH) would answer configure's question "checking whether make sets $(MAKE)" with the right answer: yes; the test with mingw's make.exe says "no", but "yes" seems to be the appropriate answer for mingw's make.exe. Also, I had to change "/cygdrive/c" to "C:" (and sometimes also "/usr/bin" to "C:/cygwin/bin") in the Makefile pathnames for build tools and libraries and add "--tag=CXX" to libtool lines, especially if I wanted to execute make in a subdirectory.) And I ran into one error with "make check" at "test_I_io", resulting in the output "Illegal number syntax" evidently from function read_number_bad_syntax() in "cl_read_err_bad.cc". But when I commented out that test for "test_I_io" in function test_I(), the "make check" run was otherwise fine. I also set up a run of only the "test_I_io" test and found that the error occurred when I compiled the tests modules with -O2 optimization, but the error did not occur when I compiled them with the no (i.e., -O0) optimization. I also tried to use gdb with tests.exe but found that I could not set breakpoints in cl_I_read.cc, cl_I_read_stream.cc, or cl_read_err_bad.cc even though I recompiled these modules with the "-g -O0" flags and then rebuilt "libcln.a" using these three rebuilt object modules. (I even tried removing these three modules from the library build and putting them in the "tests" directory, but I seem to have run into "order-of-initialization" problems as suggested in header file "cln/modules.h"; the linker error in this case was "C:/Dev-Cpp/lib/libmingw32.a(main.o)(.text+0x106):main.c: undefined reference to `WinMain@16'".) I also made sure the -s linker flag did not appear in the commands in building "libcln.a" as well as "tests.exe". (However, I surmise that libtool may be doing some rather mysterious things in getting "database" information from mysterious files; but in each case -s did not appear in the immediately subsequent g++ command line that I surmise is generated by libtool and that seemingly should be regarded as the unequivocal description of what g++ is doing to build "libcln.a".) I also set up a rebuild of tests.exe and used "drmingw tests.exe" and an intended exception/fault in "cl_read_err_bad.cc", but the stack traceback output I got seemed slightly erratic. (If I recall correctly, I think there was listed an extraneous call to cl_abort() before the call to read_number_bad_syntax().). I surmised later that the erratic output was probably due to the fact that most of the relevant object modules for tests.exe were built with -O2. I also set up a run to force linkage of tests.exe to link to the mpatrol library to see if the error could be due to heap-memory or C-memory-function errors, but even though I got a rather large, verbose, three-figure MB log file, that log file showed no memory errors. Unfortunately, read_number_bad_syntax() calls something like cl_abort() rather than returning control to the calling function with an error indication. As a result an after-failure call to an "outside hook" function cannot easily be made for setting breakpoints and examining variables with gdb -- note that gdb breakpoints _can_ be set in functions whose object modules are not a part of the CLN library. (But rebuilding the library after its input object modules have been built is rather time-consuming as well, discouraging experimentation.) So with the dependency of the test on using optimization (or not) in compiling and linking the "tests" modules, I figured the problem was probably connected with the "order-of-module-initialization" issues described in header file "cln/modules.h" (which issues are apparently dependent on optimization); and so I decided to proceed with building the readline libraries and GiNaC, and possibly come back to this issue with "test_I_io" later, depending on how successful I was with GiNaC. Problems with GiNaC: Because of earlier experience, I generally made modifications to all of GiNaC's Makefiles in accordance with the ideas discussed above for CLN. I also liberally listed library names (sometimes pathnames) for the various "LIBS" and "..._LIBS" variables (even though many of these variables are not used), and I included "-lstdc++ -lmingw32" for these variables because an earlier build of GiNaC suggested that they were needed. I figured that duplication of library names on command lines probably wouldn't hurt and the Makefiles could be more easily adjusted if necessary, if duplication problems did arise. And I decided I needed to copy "libreadline.5.dll" (and "libhistory.5.dll" even if not needed) to "C:\Dev-Cpp\bin", the binary folder for my mingw gcc 3.4.2 and other mingw tools. This "bin" is in my PATH variable used to search for executables. I also had to make several adjustments of to config.h to account for the fact that I actually did have a readline library even though configure said I didn't -- three macro variables should say I have readline and two should provide the version numbers. (I copied "libreadline.5.dll" to "C:\Dev-Cpp\bin" after I ran GiNaC's configure.) I also had to modify "ginsh_parser.cc" (in folder "ginsh") and "timer.h" and "timer.cpp" (in folder "check") to use header <ctime> and function clock() in place of header <sys/resource.h> and function getrusage(), which apparently are not in my mingw runtime libraries. I also commented out (with //) all the "#line" (presumably comment) lines in ginsh_parser.cc because a comment in an earlier version of GiNaC said some compilers may choke on them -- I was trying to make the setup as robust as possible. (By the way, ginsh.exe seems to be working as intended.) So after a horrendous amount of finagling and discovery of what works and what doesn't, I finally completed the "make check-TESTS" test for GiNaC. Since the problems don't seem to be obviously trivial, even if minor adjustments could fix them, I have decided to see if I can get some help on this. I could send a zip file of my most recently modified Makefiles (particularly the .rtf backup versions that have manual modifications highlighted in boldface) and modified .cc, .cpp, and .h files if anyone is interested. (I usually create the text-format Makefiles from the .rtf backup versions). I also use the "modified" time-stamps in backups with descriptive file names and output files to keep a chronological history of what I've tried. And I often use "touch -m --reference=..." to synchronize text versions with .rtf backup versions, which are easier to edit with WordPad. (A newly created "Makefile" from an .rtf backup is what I usually use as the reference in the touch command to synchronize the Makefile with its backup. And I often add date/time stamps in the file names for easy overviews in Windows Explorer with files sorted as to modified date/time. The date/time stamps in the file names also serve to keep the output file names distinct in a sequence of experimentally varied trial runs.) Richard Haney Here are the appended listings of files: make_check-TESTS_out.rtf: GiNaC will now take an exam with specific input (like a pupils' exam): examining several historic failures just out of paranoia........./exams.ref exams.out differ: char 39, line 2 FAIL: run_exams GiNaC will now run through some rather costly random consistency checks: checking consistency of numeric types.. passed checking consistency of symbolic functions.... passed checking symbolic matrix manipulations./checks.ref checks.out differ: char 153, line 6 FAIL: run_checks GiNaC will now run through some basic timings: timing commutative expansion and substitution.... passed size: 50 100 200 400 time/s: 0.19 0.719 3.109 13.8 timing Laurent series expansion of Gamma function.... passed order: 10 15 20 25 time/s: 0.16 0.51 2.49 9.349 timing determinant of univariate symbolic Vandermonde matrices./times.ref times.out differ: char 192, line 6 FAIL: run_times ====================================== 3 of 3 tests failed Please report to <ginac-list(a)ginac.de> ====================================== c:\Dev-Cpp\bin\make.exe: *** [check-TESTS] Error 1 exams.out: ----------several historic failures: Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. checks.out: ---------consistency of numeric types: (no output) ---------consistency of symbolic functions: (no output) ---------symbolic matrix manipulations: Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. times.out: -------commutative expansion and substitution: (no output) -------Laurent series expansion of Gamma function: (no output) -------determinant of univariate symbolic Vandermonde matrices: Assertion failed: e.op(1).is_equal(_ex2), file indexed.cpp, line 701 This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. ==== end of message ==== __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 21

Indexed vs labelled
by Vladimir V Kisil 01 Aug '06

01 Aug '06

Dear All, Browsing email on my vacation I noticed a discussion on indexed objects. So far my impression is that GiNaC FAQ is mainly written in do-not-do-this-and-that style. Some active GiNaC users (e.g. me) may wish to see more positive suggestion. For example, I would be grateful for answering such questions: Q4. "Indices" of various kinds proved to be useful in different areas of mathematics, e.g. linear algebra. If present idx and varidx classes are strictly reserved for differential geometric usage in spaces with fractional dimensions, are there plans to add some other classes, say "labels", which may be freely utilised for other purposes? Q5. I need expressions of the type \sum_{j=1}^n a_j b_j for an unspecified symbolic value n and quantities a_j and b_j *labelled* (rememberring that _indexed_ is already copyrighted) by j in this range. Since the varidx class for j is not encouraged and the Einstein summing convention is not "meaningful" in GiNaC, what is the recommended way to define such a sum in my program? Best wishes from the sunny Odessa ;-) Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk

3 2

Simplifying indexed expressions not working on multi-indices scalar_product
by Alejandro Limache 28 Jul '06

28 Jul '06

According to section 4.14.5 "Simplifying indexed expressions" of the tutorial, if I set: scalar_products sp; sp.add(A, B, 0); then: A~mu~nu*B.mu.nu should be replaced by zero when using .simplify_indexed(sp). This is not working. See my simple code below. Is this a bug?, any help will be appreciated Alejandro PS. I am using Ginac version 1.3.4 on debian this are the rpm I've got: ginac-tools_1.3.4-1_i386.deb libginac1.3c2a_1.3.4-1_i386.deb libginac-dev_1.3.4-1_i386.deb %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% #include <iostream> #include <ginac/ginac.h> using namespace std; using namespace GiNaC; int main (void) { symbol A("A"),B("B"),mu_sym("mu"),nu_sym("nu"); idx mu(mu_sym,3), nu(nu_sym,3); ex e, e1; scalar_products sp; sp.add(A,B,0); cout << "scalar_prod 1 index:" << endl; e= indexed(A,mu)*indexed(B,mu); cout <<e <<endl; cout << e.simplify_indexed(sp) << " ==> correct " << endl; cout << "scalar_prod 2 indices:" << endl; e1= indexed(A,mu,nu)*indexed(B,mu,nu); cout << e1 <<endl; cout << e1.simplify_indexed(sp) << " ==> wrong, it is not zero" << endl; return 0; }

3 10

Re: [GiNaC-list] [patch] Document that shared libraries are not supported on some weird platforms
by Richard Haney 22 Jul '06

22 Jul '06

Sheplyakov Alexei wrote: > On Wed, Jul 19, 2006 at 10:45:13PM +0200, Richard B. Kreckel wrote: [...] > > [[...]] Actually, you *can* > > specify the prefix at the make install step by saying make install > > prefix=/path/to/whereever. > Do you mean "make install DESTDIR=/some/weird/dir"? A perusal of the root Makefile shows that the juxtaposition "$(DESTDIR)$(bindir)" appears in many places throughout the Makefile and that "bindir" is defined in terms of "exec_prefix", which is defined in terms of "prefix", which is defined as the value set with the "--prefix=..." option on the configure command line. (In ginac/Makefile, "$(DESTDIR)$(libdir)" occurs throughout the Makefile with a similar dependence of "libdir" on the value of configure's "--prefix=..." option.) So it seems that "make install DESTDIR=/some/weird/dir" would only work as intended if "--prefix=..." was not specified on the configure command line. But has anyone tested this use of "DESTDIR"? The readline library build's INSTALL document mentions this as a way to install its library, but I figured that since the GiNaC documentation didn't mention this, it may perhaps be only a nonfunctional vestigial remnant from the origins of GiNaC build components. If this use of "DESTDIR" does work in place of specifying "--prefix=..." on the configure command line, shouldn't this fact be mentioned in the GiNaC installation write-up? It would simplify things considerably. Or if this use of "DESTDIR" only works when "shared" libraries are not built, shouldn't this fact be mentioned in the installation write-up, especially in the case of MinGW-based builds, where DLL-building is not currently supported? Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

How output from the configure script can be quite misleading
by Richard Haney 22 Jul '06

22 Jul '06

When I first tried building CLN and GiNaC a few years ago, I got a message from the configure script similar to the following, which is the typical output in the most recent builds: <begin quote> checking whether make sets $(MAKE)... ./configure: eval: line 1: unexpected EOF while looking for matching `"' ./configure: eval: line 2: syntax error: unexpected end of file no <end quote> Sheplyakov Alexei's recent comments about building without modifying Makefiles and my most recent tests seem to show that this error message does not indicate a fatal error for the build process, but merely indicates an "error" that is a "normal" result of the test and whose potential ill consequences the configure script is quite able to circumvent. So when I first tried building CLN & GiNaC a few years ago, I think I probably got a configure failure because readline headers and/or binary library (libreadline.a) could not be found and/or because the CLN library could not be found. So when I found that configure did not produce results that would allow an error-free build, I, as a newbie to the process, began perusing all of the output to see if I could find some clear indication as to why the build was failing. The output associated with "checking whether make sets $(MAKE)..." looked like a problem that I needed to correct somehow (in addition to the problems of getting the configure script to find headers and/or binary libraries). I don't recall how I stumbled upon the idea that letting my Borland make answer the configure script's question would solve the problem. Perhaps I just didn't have my gnu make in any of my PATH directories at some point. Anyway, when my Borland make was answering the configure script's question, the answer was simply a "yes" with no error messages. However, other tests showed that Borland make was not up to the task of building the library. So it seemed quite clear to me that I needed to comment out my gnu make when I wanted to run configure and then restore my gnu make when I wanted to run make. It is my guess that this situation has probably resulted in a lot of needless modification of Makefiles by me. So the point of this message is that the quoted output above regarding "checking whether make sets $(MAKE)" can be extremely misleading, especially to a newbie. If the configure script eventually comes up with the answer "no" (as above), it seems very likely that there is no problem here that requires "operator" intervention and/or adjustment in that regard, regardless of the error messages produced in the interim. Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [GiNaC-list] [patch] Document that shared libraries are not supported on some weird platforms
by Richard Haney 21 Jul '06

21 Jul '06

Sheplyakov Alexei wrote: > So I propose to document that shared libraries are not supported on > MinGW. What about this patch? > > Index: INSTALL > =================================================================== [...] > --- INSTALL 19 Oct 2005 20:54:13 -0000 1.54 > +++ INSTALL 20 Jul 2006 13:37:43 -0000 [...] > +To build ginsh modified version of GNU readline library is necessary. It > +is available at <http://gnuwin32.sourceforge.net/packages/readline.htm>. [...] There is one more thing about the proposed use of the modified readline library. Since it seems that the primary advantage of the modified readline library is that it might permit an "automatic" default linkage to legacy UNIX functions in libgw32c.a , there is also a need for "automatic" default include directories as well. Having to explicitly specify prototypes for legacy functions in libgw32c.a would seem to defeat or complicate the purpose of using libgw32c.a . I suppose one possibility would be to use cygwin headers as a last resort (included farthest down in the source code if their inclusion is needed) and to use cygwin include directories as default include directories to be searched _after_ the default MinGW gcc system include directories, but how would one specify that to gcc? All the methods I know for specifying include directories to gcc place those directories ahead of the standard gcc system directories in priority. So I suppose that in order for the modified readline and libgw32c.a to be effectively useful, gcc would need to be rebuilt with such default lower priority directories specified automatically, but then the default legacy header files would also need to be supplied with the MinGW gcc standard header files in the packaging of the MinGW gcc standard runtime libraries. There is also the question whether inclusion of such a legacy header for a function xyz could cause a conflict between the legacy and main system prototypes for another function uvw whose prototype is specified in that legacy header and also in a main system header. Moreover, macro definitions and the like used for prototypes in system header files are often extremely complex so that a "casual" programmer might be extremely intimidated in attempting to make any ad hoc debug adjustments as to specifying prototypes. (I remember once having to modify a MinGW gcc system header because a simple macro variable in it collided with a variable of the same name in a build package; but fortunately only a simple change in the variable name in the MinGW gcc system header was sufficient to solve the problem so that I didn't have to understand everything that the header file was doing and how it related to other parts of gcc and the runtime libraries. I think this event probably occurred when I was doing a build of CLN or GiNaC a few years ago.) Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [GiNaC-list] Results of GiNaC (& CLN) builds
by Richard Haney 21 Jul '06

21 Jul '06

Sheplyakov Alexei wrote: > You should definitely read this: > http://www.catb.org/~esr/faqs/smart-questions.html > > and this: > http://www.chiark.greenend.org.uk/~sgtatham/bugs.html > > WARNING! These pages *DO NOT HAVE ANYTHING TO DO* with GiNaC! > They try to give an idea how to ask questions the smart way. > > > I had to do several fresh starts of ginac from .tar.bz2 to find out > > a workable use of the patch. > As usual, > patch -p0 < where/the_patch/is Thanks for the information. I appreciate the helpful comments and information. But I didn't think I was being stupid or rude, and even though the references are likely to be helpful, I am taken aback by the seemingly implicit "prickly-pear" attitude of those articles, and moreover, I think that the advice misses the point that the world of ideas and systems tends to be quite a bit more complicated than what the author presumes. Contrary to what the author seems to believe, I do not think there is a universal, "true", "right", "one-size-fits-all" way to ask questions. Lots and lots of things in computer systems routinely seem to be "broken" and I don't think it is necessarily due to the fault of "Microsoft Windows" or the saving grace of UNIX/Linux systems design. For example, there seems to be no "html" target in GiNaC Makefiles in spite of what the documentation seems to indicate. It's not just GiNaC. It seems to be quite frequent that documentation is often out of sync with actual systems development. So I suppose "stupid" questions would be inevitable. I suppose I could write a book about what's "wrong" with modern computer systems. But that's not my purpose. What I'd like to do is to understand the design philosophy as to why certain legacy practices and legacy designs seem to be needed. So I try to frame my questions in a way that will solve the most problems most effectively rather than to interminably nitpick a million and one questions in protracted, excruciating detail. Design schemes and philosophies matter. (But I also agree that examples and pertinent detail matters.) The "right" level of abstraction matters. But abstraction is an extremely fluid commodity. There is a lot of arbitrariness to it. And it often has the danger of leading to factional ideologies, flame wars, religious wars, and so on. There are lots of unanswered questions I have about GiNaC and its build process. Here are a few of the seemingly more important ones: Why is it necessary to specify the installation root directory at the time of running configure? Why can't that be done _simply_ at the actual time of doing the installation? Why is it necessary to use libtool? Is libtool a "fixed", universal product? Or is it simply something that is tailored specifically to the particular build process, in this case GiNaC's. Why is it necessary to compile each library module twice? (I suppose the idea is that two different versions are needed for the two different potential forms of the library: "static" and "shared". Is this true?) If a .dll version is not possible, can all the excess machinations be eliminated by declaring "--disable-shared" on the configure command line? Shouldn't a comment to this effect be put in the installation documentation so that mingw-users don't needlessly go through the excess machinations in the hopes of getting a .dll? There are probably other important questions that ought to be asked here, but the above are the more salient ones that come to mind. Sheplyakov Alexei wrote: > ./configure && make && make check && make install > > works just fine. If you happen to know a standard, "legacy"(?) configuration of your system that GiNaC build is happy with, I would expect your results. But when systems have a horrendous variety of degrees of freedom for creative, alternative designs, it is amazing the build process works at all. In any case, I would think it important to design the general build process to be both robust and flexible. Maybe this is not the right place to ask this question, but it does seem to matter here the most (grep is such a common tool that I doubt if there is a specific, preferred forum for this): I have not been able to get (cygwin or any other) grep to do a routine, "recursive" sweep through _all_ subdirectories. I have only been able to get sweeps at only fixed depths by using, for example, "./*/*/*" for the filename specification. Can anyone explain how to get a complete recursive sweep through all subdirectories with grep? The documentation seems to be silent on precisely what's needed here. Examples would help.

3 3

Re: [GiNaC-list] Results of GiNaC (& CLN) builds
by Richard Haney 20 Jul '06

20 Jul '06

Or: Why GiNaC builds have not been straightforward It turns out that when the configure script tests for the existence of a usable readline function, it specifies -lreadline but not -ltermcap or the "curses" library, but modules in the readline static library apparently call functions that are not resolved by the linker. Those references are resolvable with the termcap library. (Readline installation documentation seems to say that the curses library can be used as an alternative to the termcap library.) A simple test program links quite well when both -readline and -ltermcap are properly specified. And by extracting the three object modules in libtermcap.a and inserting them in libreadine.a and by using this expanded libreadline.a, I was able to get the "make", "make check", and "make install" procedures to proceed without any need for modification of Makefiles; I did specify "--prefix=..." on the configure command line. (However, I did have to restart "make" because of errors due to timing out of subprocesses when the computer was put into hibernation; but there appears to be no deleterious effect as a result, and I had to copy my modified ginsh/ginsh_parser.cc from a previous build and either Sheplyakov's patched or my patched check/timer.h and check/timer.cpp as well as ginac/indexed.cpp with the assertion at line 701 commented out, and also Sheplyakov's patched "check/exam_archive.cpp".) Note that there seems to be no problem with unsatisfied "termcap" references when using the libreadline.5.dll and libhistory.5.dll that's created in the readline build, but of course, the configure script looks for libreadline.a, not libreadline.5.dll . One must manually modify ginsh/Makefile in order to use the .dll . So it would seem that the configure script should be modified to insert a -ltermcap or -lcurses (if that's the right name) -- or both (?) -- in the linker command line to test for readline, depending on what the script has found by prior tests -- or simply leave it a -lreadline only if neither of these extra libraries is found. If the unsatisfied references would never be needed for program flow, perhaps an option could be added to the linker command line to allow unresolved references (if there is such an option), or perhaps both -ltermcap and -lcurses could be specified along with an option to simply allow multiply-defined symbols and thus perhaps avoid any logic/decision-making fuss over which library should be used. These are just suggestions as to possibilities; I'm not familiar with the details here. Surprisingly, the unmodified ginsh/Makefile does put both -lreadline and -ltermcap on the linker command line to build ginsh. So it seems that -ltermcap was probably just inadvertently omitted in the configure script to test for the readline function. And incidentally, this supposed need for termcap seems to be counter to a comment and patch by Sheplyakov Alexei to the effect that termcap is being phased out; the details of this I'm not familiar with. Also, I used none other of Sheplyakov's and my patched files in GiNaC for this test run than those I specifically mentioned above as needing to be copied from a previous build. As for design of the configure script, it seems best that it should set the readline macros in config.h based on the headers found, regardless of whether a usable readline function is found. That would tend to simplify any debugging and manual adjustments needed when such a usable readline function is not found. But of course this would depend on the likelihood of various problematical states/scenarios when a usable readline function is not found. Incidentally, quite a bit of manual intervention, especially Makefile modification, was needed in building the readline/history libraries. Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Python wrapper for a GiNaC derived library
by Vladimir Kisil 20 Jul '06

20 Jul '06

Dear All, Recently Daniel Seidel produced a Python wrapper for my "cycle" library announced here on Wed Dec 28 11:16:33 CET 2005. The wrapper is based on the pyGiNaC (http://sourceforge.net/projects/pyginac/) and is an example how a derived GiNaC libraries may be used in the interactive mode. The wrapper can be found here: http://www.maths.leeds.ac.uk/~kisilv/pycycle.html If you are curious what cycles are, then an easy-reading (I hope ;-) overview is here (http://arxiv.org/abs/math.GM/0607387) Best wishes, Vladimir -- Vladimir V. Kisil email: kisilv(a)maths.leeds.ac.uk -- www: http://maths.leeds.ac.uk/~kisilv/

2 1