- CLN-list - ginac.de

integer conversion functions weirdness
by varg＠theor.jinr.ru 19 Oct '06

19 Oct '06

Hello! Functions for conversion from cl_I into built-in integer types are a little bit weird: if conversion fails, CLN just aborts the program. This weirdness is documented in the manual: \begin{quote} `int cl_I_to_int (const cl_I& x)' `unsigned int cl_I_to_uint (const cl_I& x)' `long cl_I_to_long (const cl_I& x)' `unsigned long cl_I_to_ulong (const cl_I& x)' Returns `x' as element of the C type CTYPE. If `x' is not representable in the range of CTYPE, a runtime error occurs. \end{quote} So my question is: how do I check if the variable of cl_I type can be converted to int (or any other built-in integer type[s])? Best regards, Alexei. -- All science is either physics or stamp collecting.

3 4

SGI Altix (SuSE/Itanium) problems
by Ryurick Marius Hristev 12 Oct '06

12 Oct '06

Hello, I am trying to compile cln on a SGI Altix machine, that is a SuSE 9.3 (linux) on Itanium (64 CPUs). The cln 1.1.13 gives me the following error: exam.s:89: Error: file number 2 already allocated (strangely the file may difer, e.g. tests.s while the error remains the same) The cln 1.1.11 (from opensuse) gave me this error: Testing test_I_io... Illegal number syntax: "0" Any suggestions much appreciated. Thank you. Cheers, -- Ryurick M. Hristev -- Systems Administrator (Unix) University of Queensland -- ITS Dept. mailto: r.hristev(a)uq.edu.au the greatest hacking experience: hack your own mind -- me

2 1

syntax error in tests/Makefile.in
by Ralf Wildenhues 11 Oct '06

11 Oct '06

Hello there, Your move from $() to ${} in makefiles introduced a small bug (aside, the rationale for this move seems rather difficult to understand to me). Cheers, Ralf 2006-10-11 Ralf Wildenhues <Ralf.Wildenhues(a)gmx.de> * tests/Makefile.in (VPATH): Fix syntax error. Index: tests/Makefile.in =================================================================== RCS file: /home/cvs/cln/tests/Makefile.in,v retrieving revision 1.9 diff -u -r1.9 Makefile.in --- tests/Makefile.in 16 Aug 2006 21:45:02 -0000 1.9 +++ tests/Makefile.in 11 Oct 2006 17:49:20 -0000 @@ -33,7 +33,7 @@ # Needed by ${LIBTOOL}. top_builddir = .. -VPATH = {(srcdir} +VPATH = ${srcdir} FILES_CC := $(notdir $(wildcard ${srcdir}/*.cc)) FILES_CC := $(filter-out %.i.cc, ${FILES_CC})

1 0

Anomaly when integer zero combined with extended float.
by Ray Buvel 09 Sep '06

09 Sep '06

I ran across an anomaly in CLN that occurs when an integer zero value is combined with an extended precision floating point number. Consider the following cl_R a,b,r; Now assign a cl_I variable whose value is zero to a, and a high precision cl_LF value to b. Then perform any of the following operations. r = a * b; r = b * a; r = a / b; In every case, the precision degrades to the default value. However, if the integer value in a is anything other than zero, the result has the precision of b. Since this only occurs for multiply and divide, I suspect it may be due to some shortcut that is taken when one of the operands is zero. The same anomaly occurs if the variables are declared cl_N and operand b is a high precision floating point complex number. The simplest way to demonstrate this behavior is to use the clnum Python module. The following session is on a 64-bit platform with version 1.1.9 of CLN. >>> from clnum import mpf >>> x=mpf(1,50) >>> x mpf('1.0',55) >>> 0*x # Results in default precision mpf('0.0',36) >>> 1*x # Preserves the precision mpf('1.0',55) Ray Buvel P.S. Is there another way to report anomalies other than posting to the list?

2 2

Re: CLN vs weird mixture of Cygwin and MinGW
by Richard Haney 08 Sep '06

08 Sep '06

--- "Sheplyakov Alexei" <varg(a)theor.jinr.ru> wrote: > On Tue, Aug 15, 2006 at 06:39:44PM -0700, Richard Haney wrote: [...] > > I chose to re-order those directories in PATH because of the > > conflict with versions of rm.exe , > Aha, I see! Otherwise you can't remove files created by Cygwin's > bash [and other utilities] (at least because of different > pathname conventions used by Cygwin and win32). Actually, the problem I noticed was that the non-Cygwin rm.exe was not removing symlinks. The non-Cygwin rm.exe requires the explicit extension .lnk (which seems typically "hidden" in Cygwin utilities output) in the name of the file to be removed; Cygwin rm.exe does not require the .lnk extension. > > If you insist on using Cygwin+MinGW, you need at least to I'm still a bit puzzled by the concern about the mixture of Cygwin+MinGW. My Cygwin installation has no gcc or associated binutils. So I'm puzzled as to why you think there could easily be a conflict. The existence of two versions of rm.exe was the only possible conflict for invocation (i.e., root) names in the two directories "C:\Dev-Cpp\bin" and "C:\cygwin\bin" in PATH. The first directory contains MinGW gcc and associated (MinGW) binutils (as, ld, ar, ...), and the second contains all the Cygwin stuff. That stuff seems pretty disjoint and independent between the two directories, and in fact it seems hard to imagine why configure and associated scripts would be concerned about the MinGW aspect of gcc and the associated binutils. Also, it is my impression that the "MinGW" ("mingw32") questions in the configure and associated scripts are really concerned with whether the MinGW "MSYS" package is being used (instead of Cygwin). That reference to mingw32 seems to have very little to do with MinGW gcc and its associated binutils. The MinGW "MSYS" package is in a different file hierarchy ("C:\msys\1.0.10" on my computer) from the MinGW gcc and associated binutils, even as distributed entirely in the official MinGW packages. So with this idea in mind, it seems that "--hosts=mingw32" (or any mingw32 variation) is a mistake. Please correct me if I am wrong. Best regards, Richard Haney __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Additional Missing ".exe"s in Makefile(.in)s... [Was: CLN vs weird mixture of Cygwin and MinGW [Was: ...]]
by Richard Haney 06 Sep '06

06 Sep '06

--- Sheplyakov Alexei <varg(a)theor.jinr.ru> wrote: > > [...] error in regard to the > > missing .exe extensions for executable targets in Makefiles. > > Autoconf does its job right, but CLN's tests/Makefile.in do not care > about $(EXEEXT). Attached patch should fix this. [...] > > Index: cln-1.1.13/tests/Makefile.in > =================================================================== > --- cln-1.1.13.orig/tests/Makefile.in 2006-08-13 14:21:23.000000000 > +0400 > +++ cln-1.1.13/tests/Makefile.in 2006-08-13 14:56:16.000000000 +0400 [...] Thanks. I would think the patch should also extend to the executables in target "clean" something as follows clean : force - $(RM) *.s *.o *.a exam tests main a.out core + $(RM) *.s *.o *.a exam$(EXEEXT) tests$(EXEEXT) main a.out core $(RM) -r .libs _libs I'm not sure about "main" or what its purpose is; no executable "main.exe" (nor even a file "main") seems to be created in my build even though there is a module "main.cc". Module "main.cc" looks like it is designed for experimental testing of type conversion and/or output, perhaps for debugging purposes. Also, I would think a similar patch for examples/Makefile.in and benchmarks/Makefile.in would also be appropriate since the associated Makefiles are used to build executables in the associated directories. Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

recent Makefile change
by Ralf Wildenhues 06 Sep '06

06 Sep '06

Hello, Just curious: Is there any technical reason for this recent change in the CVS version of CLN, or is that just for (non)readability? * Makefile.in: Convert from $(VAR) to ${VAR} syntax. * benchmarks/Makefile.in: Likewise. [...] Cheers, Ralf

2 3

CLN vs weird mixture of Cygwin and MinGW [Was: Results of building cln-1.1.13 ...]
by Richard Haney 30 Aug '06

30 Aug '06

--- Sheplyakov Alexei <varg(a)theor.jinr.ru> wrote: [...] > On Sun, Aug 13, 2006 at 07:42:59PM -0700, Richard Haney wrote: > > [...] [...] > On my Duron 800 with 512Mb RAM (running Debian GNU/Linux sid) running > GiNaC configure script takes about 1 minute. On ReactOS it is indeed > somewhat slower, but it is not *that* slow. Thanks, that's good to know. > > uname -s = CYGWIN_NT-5.1 > > You are trying to make win32 libraries with a mix of Cygwin and MinGW > tools. While it is certainly possible build win32 libraries/binaries > with such a setup, it is a little bit tricky, [...] Among the executables (".exe"s as well as scripts) in /bin and in /cygdrive/c/Dev-Cpp/bin , the only ones that could clash are the two versions of rm.exe that I mentioned. The /usr/bin and /usr/local/bin directories are not used. It seems that for a build only the MinGW tools (in /cygdrive/c/Dev-Cpp/bin ) are concerned with interpreting the contents of files (apart from whatever goes on in the interpretation of link files). I chose to re-order those directories in PATH because of the conflict with versions of rm.exe , but I could have done instead an override of, say, RM="C:/cygwin/bin/rm.exe" on the configure command line. > [...] so I suggest you to use > MSYS. > BTW, running shell scripts with MSYS is *much* faster. Thanks, that's good to know. I've been using cygwin because 1) (originally) msys seemed to have a bug in regard to setting the size defaults for the script window. 2) (later) I became used to using cygwin and was concerned that my experience (implicit knowledge) about cygwin would not carry over very easily or entirely to msys -- especially in regard pathnames conventions. 3) (most recently in regard to grep) I have subsequently learned that cygwin seems to have distinctly better tools -- at least in regard to grep -- and a larger variety of tools, whereas msys _seems_ to be a bit limited. So, I'm wondering about what bugs/limitations may be lurking in msys, which I have not tried much. > If you insist on using Cygwin+MinGW, you need at least to > > 1) give the configure script proper --build and --host arguments, > e.g., > > --build=i586-mingw32msvc --host=i586-mingw32msvc So why not i686 in place of i586 , since configure seems to think my computer is a i686 (whatever that is, precisely)? Also, the "msvc" seems to stand for "Microsoft Visual C/C++", or does that refer to a Microsoft DLL with the same string "msvc" in its name? Are there only a limited list of possible values for --build=... and --host=... ? Where are they defined (and/or described in human-readable form)? > > 2) make sure that directories with MinGW tools listed first in your > $PATH, > which is not the case with your setup: See comment above in regard to possible "clashes" between the directories, including "rm.exe". > > Hopefully, the config.log file will also help in determining why > > the default value for the Makefile INSTALL variable > There is no such a default. The value of this variable is determined > by the configure script, which is basically searches for required > program in your $PATH. By "default value" I meant the value that is set in the Makefiles in the absence of an override set on the configure command line. > > causes a crash in the doc directory for "make install". > I think it is either Cygwin bug or just your setup is horribly > broken. Yes, this is very much a puzzle still. It seems to me that a few years ago I tried copying a failing command line from make output and inserting that line directly in the cygwin bash shell and then the command worked as intended, and it seems to me that this "experiment" was concerned with the process of installing from the doc directory, but all of that was some time ago when I did that and I don't recall the details. Quite possibly it could have been the very same command that failed in this most recent case. Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 3

CLN vs weird mixture of Cygwin and MinGW [Was: Results of building cln-1.1.13 ...]
by Richard Haney 25 Aug '06

25 Aug '06

Hi Alexei and others who may wish to comment, --- Sheplyakov Alexei <varg(a)theor.jinr.ru> wrote: > If you insist on using Cygwin+MinGW, you need at least to > > 1) give the configure script proper --build and --host arguments, > e.g., > > --build=i586-mingw32msvc --host=i586-mingw32msvc I guess I really need to ask a question explicitly, rather than simply leaving the question implicit from my two messages ( http://www.cebix.net/pipermail/cln-list/2006-August/000228.html and http://www.cebix.net/pipermail/cln-list/2006-August/000229.html ). It _seems_ to me, based on my (admittedly limited) knowledge and on "grep"ing directories and exploring files as described in my first of the two messages, that > --build=i586-mingw32msvc --host=i586-mingw32msvc is incorrect because: (1) my processor is a Celeron processor, which seems to mean that the first part of the system type should be "i686" and not "i586" (as explained in my first of the two messages), and (2) because there is no meaningful occurrence of the string "msvc" in "C:/gnu/cln-1.1.13" or in "C:/gnu/cln-1.1.13/autoconf", which fact _seems_ to suggest that the second part of the system type should definitely not be the "mingw32msvc" that was suggested above. Moreover, $ uname --help [...] -s, --kernel-name print the kernel name [...] seems to suggest that "uname -s = CYGWIN_NT-5.1" in the config.log gives the best available idea of what should be considered the "kernel". So it _seems_ (to me, based on my admittedly limited knowledge) that the result from the configure output checking build system type... i686-pc-cygwin checking host system type... i686-pc-cygwin is the best possible information. I don't really know what the build process does with this information. But it seems to me that the fact that gcc and its associated tools (as, ld, ... ) are MinGW tools (which, as I understand it, means that they and their output, where applicable, link directly to the Windows system DLLs rather than to cygwin1.dll) should be of no real concern to the build process. So this suggests that there should be no need for information such as "mingw32" in the build process (specifically the scripts). Moreover, by comparing script names and other executable names in the two directories "C:/cygwin/bin" (the bin for cygwin executables) and "C:/Dev-Cpp/bin" (the bin for MinGW tools), the only potential conflict I found was the existence of two different versions of "rm.exe". So it seems that putting "C:/cygwin/bin" first in PATH was an appropriate arrangement in order for configure to use the cygwin version (of rm.exe), which deletes symlinks properly. (The alternative arrangement would have led to using RM=... explicitly on the configure command line or simply removing or renaming the rm.exe in "C:/Dev-Cpp/bin".) So my questions are these: Are my best guesses as described here mistaken? And if so, where are they mistaken? If using > --build=i586-mingw32msvc --host=i586-mingw32msvc on the configure command line really is a better practice, why? Also, does the description "weird mixture of Cygwin and MinGW" merely reflect that the author is simply unfamiliar with this use of Cygwin and MinGW? Or is there some other matter in this regard that I should consider? BTW, I think I have seen the use of Cygwin and MinGW tools in this way described, perhaps even by MinGW FAQ files, as something that seemed to be considered a "normal" option for development and porting. The alternative to cygwin bash (and its associated unix-style utilities), namely MinGW's msys system (including msys bash), originally seems to have been provided, not because of any real technical need or usefulness, but rather for the sake of completeness and project independence from cygwin. For those interested, note that I have described my reasons for using cygwin rather than msys in my message http://www.cebix.net/pipermail/cln-list/2006-August/000221.html . Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

CLN vs weird mixture of Cygwin and MinGW [Was: Results of building cln-1.1.13 ...]
by Richard Haney 22 Aug '06

22 Aug '06

--- Sheplyakov Alexei <varg(a)theor.jinr.ru> wrote: > If you insist on using Cygwin+MinGW, you need at least to > > 1) give the configure script proper --build and --host arguments, > e.g., > > --build=i586-mingw32msvc --host=i586-mingw32msvc I thought about this some more and also perused apparent script-file definitions since my last post on this subject. It appears that "uname -s = CYGWIN_NT-5.1" is _supposed_ to be the "kernel name". That sounds like some variant of "cygwin" would be the appropriate value, and not some variant of "mingw32". (But I can see why some variant of "msvc" _might_ be thought to be appropriate as part of the identification; however, no variant of "msvc" seems to be valid, as far as I can tell.) So it seems to me that the configure script is coming up with exactly the right value "i686-pc-cygwin" since my processor is a Celeron processor. But I suppose the answer may hinge upon what is considered a "kernel" for practical purposes. So I guess what's puzzling me is why there should be any problem with "Cygwin+MinGW" in the way that I'm doing it. I seem to recall that I read somewhere where even the Cygwin gcc project eventually came over to using MinGW gcc as the standard compiler for Cygwin. The only major difference was that the new gcc no longer used "cygwin1.dll" to satisfy links, but rather started using the Microsoft Windows system DLLs directly. I don't see how that should be of interest to the configure script; that fact seems to be something that would ordinarily be "hidden" from the configure script. Best regards, Richard __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0