Hi, I plan to release 1.6.0 this weekend. Any non-maskable interrupts? Regards, Jens
On 05/20/2011 02:00 PM, Jens Vollinga wrote:
I plan to release 1.6.0 this weekend. Any non-maskable interrupts?
Yes. Analyzing... Please hang on... -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
On 05/20/2011 09:54 PM, Richard B. Kreckel wrote:
On 05/20/2011 02:00 PM, Jens Vollinga wrote:
I plan to release 1.6.0 this weekend. Any non-maskable interrupts?
Yes. Analyzing... Please hang on...
Fixed. Let the show go on! -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi! On 05/20/2011 02:00 PM, Jens Vollinga wrote:
I plan to release 1.6.0 this weekend. Any non-maskable interrupts?
Since the soname bumped, would it now be okay to consider this representation_label issue <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479163>? Wasn't the main argument that it's not important enough for breaking the ABI? -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
On 05/20/2011 02:00 PM, Jens Vollinga wrote:
I plan to release 1.6.0 this weekend. Any non-maskable interrupts?
Any objections to make the new soname libginac.so.2? If not, I'll commit a patch soon. Rationale: Okay, the old scheme was libginac-1.5.so.0, so it looks like no problem, but distributions might have packages named libginac1.5 and would prefer to continue with libginac2, because libginac0 breaks lexicographic ordering. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi, Am 22.05.2011 09:07, schrieb Richard B. Kreckel:
Any objections to make the new soname libginac.so.2?
Just a few questions ...
Rationale: Okay, the old scheme was libginac-1.5.so.0, so it looks like no problem, but distributions might have packages named libginac1.5 and would prefer to continue with libginac2, because libginac0 breaks lexicographic ordering.
As of commit f320e27e9 the name has changed to libginac.so. So, what do you mean with libginac0? Where does this 0 come from?!? More importantly, why does lexicographic ordering matter?!? Regards, Jens
Hi again, On Sun, May 22, 2011 at 1:01 PM, Jens Vollinga <jensv@nikhef.nl> wrote:
As of commit f320e27e9 the name has changed to libginac.so.
Not exactly, run objdump -p libginac.so | grep SONAME
So, what do you mean with libginac0? Where does this 0 come from?!?
I guess it comes from the SONAME, and a naming convention for shared library packages. Typically such packages are called after the library SONAME. Thus, a package containing libginac.so.0 is called libginac0.
More importantly, why does lexicographic ordering matter?!?
Because humans and (package management) software expect SONAMEs (and version numbers) to be increasing. Best regards, Alexei
Hi, Am 22.05.2011 14:54, schrieb Alexei Sheplyakov:
Not exactly, run
objdump -p libginac.so | grep SONAME
and the answer is: SONAME libginac.so.0 Looks good? Is it different at your box?
So, what do you mean with libginac0? Where does this 0 come from?!?
I guess it comes from the SONAME, and a naming convention for shared library packages. Typically such packages are called after the library SONAME. Thus, a package containing libginac.so.0 is called libginac0.
Ah, okay.
More importantly, why does lexicographic ordering matter?!?
Because humans and (package management) software expect SONAMEs (and version numbers) to be increasing.
Eh? I don't understand, yet. Human expectations aside, why does package management rely on lexicographical ordering? What I plan to do is to go from libginac-1.5.so to libginac.so. I don't want to encode the library version anymore into the name (yes, it creates some one-time extra work for distros). So, is this the actual dissent: you/richy want still a number in the name (which better is increasing)? Change the library name again when we do a ginac-3.0 release? I don't see a benefit, yet. Regards, Jens
Hi, On Sun, May 22, 2011 at 03:19:17PM +0200, Jens Vollinga wrote:
objdump -p libginac.so | grep SONAME
and the answer is:
SONAME libginac.so.0
Looks good? Is it different at your box?
It's the same on my box. But it's not exactly OK.
More importantly, why does lexicographic ordering matter?!?
Because humans and (package management) software expect SONAMEs (and version numbers) to be increasing.
Eh? I don't understand, yet. Human expectations aside, why does package management rely on lexicographical ordering?
Because it's simple and straightforward. `libginac2 is newer than libginac1.5' is quite clear, and `libginac0 is newer than libginac1.5' is a bit confusing.
What I plan to do is to go from libginac-1.5.so to libginac.so.
Correct. We want to change the library *file* name from libginac-1.5.so to libginac.so. Also we want to change the library SONAME from libginac-1.5.so.0 to libginac.so.2 (actually any integer bigger than 1.5 is OK).
So, is this the actual dissent: you/richy want still a number in the name (which better is increasing)?
We don't want to encode the ABI version into the file name. But there *must* be a version number in the SONAME. Otherwise distro people are going to hit us with a huge cluestick. And that version should be updated (preferably increased) whenever we introduce a binary incompatible change. To do so it's enough to update ginac_lt_current, ginac_lt_age, and ginac_lt_revision in configure.ac according to the instructions listed in the same file (actually, those instructions have been shamelessly copied from the libtool manual). Hope this helps, Alexei
--- check/bugme_chinrem_gcd.cpp | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/check/bugme_chinrem_gcd.cpp b/check/bugme_chinrem_gcd.cpp index 6a3f399..2a1bf29 100644 --- a/check/bugme_chinrem_gcd.cpp +++ b/check/bugme_chinrem_gcd.cpp @@ -57,8 +57,8 @@ static void check_extract_integer_content() static void integer_coeff_braindamage() { parser readme; - ex A = readme("3*x2 + 1"); - ex B = readme("9*x2 + 1"); + ex A = readme("3*x^2 + 1"); + ex B = readme("9*x^2 + 1"); ex g = chinrem_gcd(A, B); if (!g.is_equal(ex(1))) { std::cerr << "expected 1, got " << g << std::endl; -- 1.7.2.5
--- INSTALL | 3 +- ginac/Makefile.am | 19 +---- ginac/parser/builtin_fcns.def | 14 ---- ginac/parser/default_reader.cpp | 157 +++++++++++++++++++++++++++++++++++++++ ginac/parser/default_reader.tpl | 145 ------------------------------------ 5 files changed, 160 insertions(+), 178 deletions(-) delete mode 100644 ginac/parser/builtin_fcns.def create mode 100644 ginac/parser/default_reader.cpp delete mode 100644 ginac/parser/default_reader.tpl diff --git a/INSTALL b/INSTALL index 3be16c1..3c188b6 100644 --- a/INSTALL +++ b/INSTALL @@ -30,8 +30,7 @@ Known not to work with: is missing there. If you install from git, you also need GNU autoconf (>=2.59), automake (>=1.8), -libtool (>= 1.5), bison (>= 2.3), flex (>= 2.5.33), autogen (>= 5.6.0) to be -installed. +libtool (>= 1.5), bison (>= 2.3), flex (>= 2.5.33) to be installed. INSTALLATION diff --git a/ginac/Makefile.am b/ginac/Makefile.am index bc2e1b8..dce098d 100644 --- a/ginac/Makefile.am +++ b/ginac/Makefile.am @@ -13,7 +13,7 @@ libginac_la_SOURCES = add.cpp archive.cpp basic.cpp clifford.cpp color.cpp \ parser/parse_binop_rhs.cpp \ parser/parser.cpp \ parser/parse_context.cpp \ - parser/builtin_fcns.cpp \ + parser/default_reader.cpp \ parser/lexer.cpp \ parser/lexer.h \ parser/parser_compat.cpp \ @@ -67,22 +67,7 @@ ginacinclude_HEADERS = ginac.h add.h archive.h assertion.h basic.h class_info.h parser/parser.h \ parser/parse_context.h -EXTRA_DIST = function.pl version.h.in \ -parser/default_reader.tpl parser/builtin_fcns.def - -# Files produced by autogen(1) from templates -$(srcdir)/parser/builtin_fcns.cpp: $(srcdir)/parser/builtin_fcns.def $(srcdir)/parser/default_reader.tpl - set -e; if [ -n "$(AUTOGEN)" ]; then \ - cd $(srcdir)/parser; \ - $(AUTOGEN) -T default_reader.tpl builtin_fcns.def; \ - elif [ -f $@ ]; then \ - echo "WARNING: AutoGen is not available, the \"$@\" file WON'T be re-generated"; \ - else \ - echo "*** ERROR: the \"$@\" file does not exist, and AutoGen is not installed on your system"; \ - echo "*** Please install AutoGen (http://www.gnu.org/software/autogen)"; \ - exit 1; \ - fi - +EXTRA_DIST = function.pl version.h.in # Files which are generated by perl scripts $(srcdir)/function.h $(srcdir)/function.cpp: $(srcdir)/function.pl diff --git a/ginac/parser/builtin_fcns.def b/ginac/parser/builtin_fcns.def deleted file mode 100644 index 96cd0a2..0000000 --- a/ginac/parser/builtin_fcns.def +++ /dev/null @@ -1,14 +0,0 @@ -Autogen definitions ginacfcns; - -/* Thease are not functions, but anyway ... */ -function = { name = "sqrt"; }; - -function = { - name = "pow"; - args = 2; -}; - -function = { - name = "power"; - args = 2; -}; diff --git a/ginac/parser/default_reader.cpp b/ginac/parser/default_reader.cpp new file mode 100644 index 0000000..4f8c69c --- /dev/null +++ b/ginac/parser/default_reader.cpp @@ -0,0 +1,157 @@ +/** @file default_reader.cpp + * + * Implementation of the default and builtin readers (part of GiNaC's parser). + **/ + +/* + * GiNaC Copyright (C) 1999-2011 Johannes Gutenberg University Mainz, Germany + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "parse_context.h" +#include "power.h" +#include "operators.h" +#include "inifcns.h" +#ifdef HAVE_CONFIG_H +#include "config.h" +#endif + +#ifdef HAVE_STDINT_H +#include <stdint.h> // for uintptr_t +#endif + +namespace GiNaC +{ + +static ex sqrt_reader(const exvector& ev) +{ + return GiNaC::sqrt(ev[0]); +} +static ex pow_reader(const exvector& ev) +{ + return GiNaC::pow(ev[0], ev[1]); +} +static ex power_reader(const exvector& ev) +{ + return GiNaC::power(ev[0], ev[1]); +} + + +// function::registered_functions() is protected, but we need to access it +// TODO: add a proper const method to the `function' class, so we don't +// need this silly hack any more. +class registered_functions_hack : public function +{ +public: + static const std::vector<function_options>& get_registered_functions() + { + return function::registered_functions(); + } +private: + registered_functions_hack(); + registered_functions_hack(const registered_functions_hack&); + registered_functions_hack& operator=(const registered_functions_hack&); +}; + +// Encode an integer into a pointer to a function. Since functions +// are aligned (the minimal alignment depends on CPU architecture) +// we can distinguish between pointers and integers. +static reader_func encode_serial_as_reader_func(unsigned serial) +{ + uintptr_t u = (uintptr_t)serial; + u = (u << 1) | (uintptr_t)1; + reader_func ptr = (reader_func)((void *)u); + return ptr; +} + +const prototype_table& get_default_reader() +{ + using std::make_pair; + static bool initialized = false; + static prototype_table reader; + if (!initialized) { + + reader[make_pair("sqrt", 1)] = sqrt_reader; + reader[make_pair("pow", 2)] = pow_reader; + reader[make_pair("power", 2)] = power_reader; + std::vector<function_options>::const_iterator it = + registered_functions_hack::get_registered_functions().begin(); + std::vector<function_options>::const_iterator end = + registered_functions_hack::get_registered_functions().end(); + unsigned serial = 0; + for (; it != end; ++it) { + prototype proto = make_pair(it->get_name(), it->get_nparams()); + reader[proto] = encode_serial_as_reader_func(serial); + ++serial; + } + initialized = true; + } + return reader; +} + +const prototype_table& get_builtin_reader() +{ + using std::make_pair; + static bool initialized = false; + static prototype_table reader; + if (!initialized) { + + reader[make_pair("sqrt", 1)] = sqrt_reader; + reader[make_pair("pow", 2)] = pow_reader; + reader[make_pair("power", 2)] = power_reader; + enum { + log, + exp, + sin, + cos, + tan, + asin, + acos, + atan, + sinh, + cosh, + tanh, + asinh, + acosh, + atanh, + atan2, + Li2, + Li3, + zetaderiv, + Li, + S, + H, + lgamma, + tgamma, + beta, + factorial, + binomial, + Order, + NFUNCTIONS + }; + std::vector<function_options>::const_iterator it = + registered_functions_hack::get_registered_functions().begin(); + unsigned serial = 0; + for ( ; serial<NFUNCTIONS; ++it, ++serial ) { + prototype proto = make_pair(it->get_name(), it->get_nparams()); + reader[proto] = encode_serial_as_reader_func(serial); + } + initialized = true; + } + return reader; +} + +} // namespace GiNaC diff --git a/ginac/parser/default_reader.tpl b/ginac/parser/default_reader.tpl deleted file mode 100644 index 006fb90..0000000 --- a/ginac/parser/default_reader.tpl +++ /dev/null @@ -1,145 +0,0 @@ -[+ AutoGen5 template .cpp +][+ -COMMENT a part of GiNaC parser -- construct functions from a byte stream. -+][+ -(use-modules (ice-9 format)) - -(define (sequence start end . step) - (let ((step (if (null? step) 1 (car step)))) - (let loop ((n start)) - (if (> n end) '() (cons n (loop (+ step n))))))) -+]/* -[+ (dne " * " " * " ) +] - * - * If you want to change this file, edit either `[+ (def-file) +]' or - * `[+ (tpl-file) +]' file, and run the following command: - * - * autogen -T [+ (tpl-file) +] [+ (def-file) +] - */ -#include "parse_context.h" -#include "power.h" -#include "operators.h" -#include "inifcns.h" -#ifdef HAVE_CONFIG_H -#include "config.h" -#endif - -#ifdef HAVE_STDINT_H -#include <stdint.h> // for uintptr_t -#endif - -namespace GiNaC -{ -[+ FOR function +] -static ex [+ (get "name") +]_reader(const exvector& ev) -{ - return GiNaC::[+ (get "name") +]([+ - (let ((nargs (if (exist? "args") - (string->number (get "args")) 1))) - (format '#f "~{ev[~a]~^, ~}" (sequence 0 (- nargs 1)))) +]); -}[+ ENDFOR +] - -// function::registered_functions() is protected, but we need to access it -class registered_functions_hack : public function -{ -public: - static const std::vector<function_options>& get_registered_functions() - { - return function::registered_functions(); - } -private: - registered_functions_hack(); - registered_functions_hack(const registered_functions_hack&); - registered_functions_hack& operator=(const registered_functions_hack&); -}; - -// Encode an integer into a pointer to a function. Since functions -// are aligned (the minimal alignment depends on CPU architecture) -// we can distinguish between pointers and integers. -static reader_func encode_serial_as_reader_func(unsigned serial) -{ - uintptr_t u = (uintptr_t)serial; - u = (u << 1) | (uintptr_t)1; - reader_func ptr = (reader_func)((void *)u); - return ptr; -} - -const prototype_table& get_default_reader() -{ - using std::make_pair; - static bool initialized = false; - static prototype_table reader; - if (!initialized) { - [+ FOR function +] - reader[make_pair("[+ (get "name") +]", [+ - (if (exist? "args") (get "args") "1") - +])] = [+ (get "name") +]_reader;[+ - ENDFOR +] - std::vector<function_options>::const_iterator it = - registered_functions_hack::get_registered_functions().begin(); - std::vector<function_options>::const_iterator end = - registered_functions_hack::get_registered_functions().end(); - unsigned serial = 0; - for (; it != end; ++it) { - prototype proto = make_pair(it->get_name(), it->get_nparams()); - reader[proto] = encode_serial_as_reader_func(serial); - ++serial; - } - initialized = true; - } - return reader; -} - -const prototype_table& get_builtin_reader() -{ - using std::make_pair; - static bool initialized = false; - static prototype_table reader; - if (!initialized) { - [+ FOR function +] - reader[make_pair("[+ (get "name") +]", [+ - (if (exist? "args") (get "args") "1") - +])] = [+ (get "name") +]_reader;[+ - ENDFOR +] - enum { - log, - exp, - sin, - cos, - tan, - asin, - acos, - atan, - sinh, - cosh, - tanh, - asinh, - acosh, - atanh, - atan2, - Li2, - Li3, - zetaderiv, - Li, - S, - H, - lgamma, - tgamma, - beta, - factorial, - binomial, - Order, - NFUNCTIONS - }; - std::vector<function_options>::const_iterator it = - registered_functions_hack::get_registered_functions().begin(); - unsigned serial = 0; - for ( ; serial<NFUNCTIONS; ++it, ++serial ) { - prototype proto = make_pair(it->get_name(), it->get_nparams()); - reader[proto] = encode_serial_as_reader_func(serial); - } - initialized = true; - } - return reader; -} - -} // namespace GiNaC -- 1.7.2.5
--- INSTALL | 20 ++++++++++---------- 1 files changed, 10 insertions(+), 10 deletions(-) diff --git a/INSTALL b/INSTALL index 3c188b6..bfa4bdd 100644 --- a/INSTALL +++ b/INSTALL @@ -18,12 +18,13 @@ To build the GiNaC tutorial and reference manual the doxygen utility TeX are necessary. Known to work with: - - Linux on x86 and x86_64 using GCC 3.4, 4.0, 4.1, and 4.2. - - Linux on Alpha using GCC 3.4. - - Solaris on Sparc using GCC 3.4. + - Linux on x86 and x86_64 using + - GCC 3.4, 4.0, 4.1, 4.2, 4.3.x (x >= 1), 4.4, 4.5, and 4.6 + - Clang 2.8 - Windows on x86 using GCC 3.4 (MinGW) Known not to work with: + - Clang 2.7 and earlier due to poor C++ support. - GCC 4.3.0 due to the compiler bug, see <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35548>. - GCC 2.96 or earlier because proper exception and standard library support @@ -73,17 +74,16 @@ A few of the more important ones: More detailed installation instructions can be found in the documentation, in the doc/ directory. -The time the "make" step takes depends heavily on optimization levels. Large -amounts of memory (>128MB) will be required by the compiler, also depending -on optimization. To give you a rough idea of what you have to expect the -following table may be helpful. It was measured on an Athlon/800MHz with -"enough" memory: +The time the "make" step takes depends on optimization levels. To give you +a rough idea of what you have to expect the following table may be helpful. +It was measured on an Athlon X2/3GHz with 4Gb of RAM. step | GCC optimization | comment | -O1 | -O2 | --------------+---------+---------+---------------------------------------- -make | ~6m | ~8m | shared and static library -make check | ~8m | ~12m | largely due to compilation +make | ~1m | ~2m | shared library only (--disable-static), + | | | parallel compilation (MAKEFLAGS=-j2) +make check | ~6m | ~6m | largely due to compilation To install from git -- 1.7.2.5
Hello, On Fri, May 20, 2011 at 3:00 PM, Jens Vollinga <jensv@nikhef.nl> wrote:
I plan to release 1.6.0 this weekend.
It's a bugfix only release (unless I'm missing something important), so I think the version number should be 1.5.9. Also, see the patches (re)posted in reply to your message. Best regards, Alexei
Hi, Am 22.05.2011 14:19, schrieb Alexei Sheplyakov:
It's a bugfix only release (unless I'm missing something important), so I think the version number should be 1.5.9.
the ABI has changed. Due to 0c2f0f4c6d4118e817c5b9 expairseq has lost a method.
Also, see the patches (re)posted in reply to your message.
I'll do that soon. Thanks!! BTW, it seems we don't need autogen anymore. Do you plan to reuse it in the near future again or is it gone for good? If it is gone for good, I'll adapt the configure.ac then. Regards, Jens
It's a bugfix only release (unless I'm missing something important), so I think the version number should be 1.5.9.
the ABI has changed. Due to 0c2f0f4c6d4118e817c5b9 expairseq has lost a method.
++lt_current; lt_age = lt_revision = 0; And that's it. ABI version has very little to do with the release number. The former describes the library changes from the point of view of a linker, and the latter describes the library changes from the users' point of view. From the users' point of view the commit mentioned above is just a bugfix. Removing (overloaded) expairseq::is_polynomial() is a minor technical detail, and it does not justify bumping the minor version. (Still it's important to bump the SONAME so the linker can find out that this version is not binary compatible with the previous one).
BTW, it seems we don't need autogen anymore.
Correct.
Do you plan to reuse it in the near future again or is it gone for good?
No.
If it is gone for good, I'll adapt the configure.ac then.
Please do. Best regards, Alexei
Am 22.05.2011 15:28, schrieb Alexei Sheplyakov:
the ABI has changed. Due to 0c2f0f4c6d4118e817c5b9 expairseq has lost a method.
++lt_current; lt_age = lt_revision = 0;
so, THIS is what you and richy meant ... okay, right, fine ... m( Obviously there are still a few things to be done before a release, like always.
And that's it. ABI version has very little to do with the release number. The former describes the library changes from the point of view of a linker, and the latter describes the library changes from the users' point of view. From the users' point of view the commit mentioned above is just a bugfix. Removing (overloaded) expairseq::is_polynomial() is a minor technical detail, and it does not justify bumping the minor version. (Still it's important to bump the SONAME so the linker can find out that this version is not binary compatible with the previous one).
Correct. But why do you want to call it 1.5.9, still? I mean, we have done a lot of other things as well and the new git branching policy is coming into effect. What else do we need to justify a minor number increase? Regards, Jens
participants (3)
-
Alexei Sheplyakov
-
Jens Vollinga
-
Richard B. Kreckel