September 2006 - CLN-list

problems building on powerpc64
by Dmitry Khutornoy 05 Dec '07

05 Dec '07

Hello! I got problems with building CLN on PowerPC64. uname -a Linux blade1 2.6.5-7.252-pseries64 #1 SMP Tue Feb 14 11:11:04 UTC 2006 ppc64 ppc64 ppc64 GNU/Linux make ... In file included from base/cl_N.h:6, from base/cl_as_err.cc:7: ../include/cln/number.h: In constructor `cln::cl_number::cl_number()': ../include/cln/number.h:191: error: `cl_FN_tag' undeclared (first use this function) ../include/cln/number.h:191: error: (Each undeclared identifier is reported only once for each function it appears in.) And it seems i know why does it happen: <config.h> ... #ifndef __powerpc64__ #define __powerpc64__ 1 #endif ... <object.h> ... #if defined(__alpha__) || defined(__ia64__) || defined(__mips64__) || defined(__powerpc64__) || defined(__sparc64__) || defined(__x86_64__) #define cl_word_alignment 8 #endif ... // Definition of the tags. #if !defined(CL_WIDE_POINTERS) #if (cl_word_alignment == 2) #define cl_FN_tag 1 #define cl_SF_tag 3 // must satisfy the cl_immediate_p predicate! #endif #if (cl_word_alignment == 4) #define cl_FN_tag 1 #define cl_SF_tag 2 #endif #else // CL_WIDE_POINTERS // Single Floats are immediate as well. #define cl_FN_tag 1 #define cl_SF_tag 2 #define cl_FF_tag 3 #endif There is no branch defining tags for powerpc64 (cl_word_alignment==8) Please, tell me what values should i write in #define or explain what am i doing wrong. Thank you! -- Best regards, Dmitry mailto:khutornoy@gmail.com

3 5

How to cite cln
by Wilson Castro 28 Jul '07

28 Jul '07

Hello cln-developers and cln-listmoderator, I want to know how it is the correct form to cite cln. 1. first in a paper? 2. in a GNU-software for Linux that uses the library? best regards -- Ms. C. Wilson Castro Rojas Foundations of Informatics Group, Department of Informatics, University of Kaiserslautern, Germany, PO Box: 3049, Building: 34/423, Phone: ++49 631 205 2155, Fax: ++49 631 205 2156,

5 33

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