Release GiNaC 1.5.3
Hi everybody, GiNaC 1.5.3 is out and available. The changes are: * The parser now understands user-defined functions by default. The parsed identifier names can now contain underscores. As always, this release can be downloaded from http://www.ginac.de/Download.html Best wishes, Jens
Dear Jens, Jens Vollinga wrote:
As always, this release can be downloaded from http://www.ginac.de/Download.html
While building Debian packages, g++ 4.3.3 complained "parser/parser.cpp:69: error: cast from 'GiNaC::ex (*)(const GiNaC::exvector&)' to 'unsigned int' loses precision". (Besides, that's a weird error message!) Looking closer, I see that the tarball is not what's tagged in git. Since it doesn't build anyway, I suggest to cheat a bit and remove the tarballs and replace them with what's in git. Cheers -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi Richy, Richard B. Kreckel schrieb:
While building Debian packages, g++ 4.3.3 complained "parser/parser.cpp:69: error: cast from 'GiNaC::ex (*)(const GiNaC::exvector&)' to 'unsigned int' loses precision". (Besides, that's a weird error message!)
I cannot reproduce these problems, but I am using gcc 4.4. Later the day I can try it with gcc 4.3.3.
Looking closer, I see that the tarball is not what's tagged in git.
Eh? To me the tar package looks exactly like the release_1-5-3 tagged blob. The NEWS file, the changes in lexer.cpp, etc. are all in there. How did you find differences and what are they?
Since it doesn't build anyway, I suggest to cheat a bit and remove the tarballs and replace them with what's in git.
I am prepared to cheat ;-) but let's clarify first what is going on. Regards, Jens
Hi, all! Jens Vollinga wrote:
Richard B. Kreckel schrieb:
While building Debian packages, g++ 4.3.3 complained "parser/parser.cpp:69: error: cast from 'GiNaC::ex (*)(const GiNaC::exvector&)' to 'unsigned int' loses precision". (Besides, that's a weird error message!)
I cannot reproduce these problems, but I am using gcc 4.4. Later the day I can try it with gcc 4.3.3.
GCC 4.4.1 produces the same error over here. I suppose you aren't seeing it because your's is a 32-bit system?
Looking closer, I see that the tarball is not what's tagged in git.
Eh? To me the tar package looks exactly like the release_1-5-3 tagged blob. The NEWS file, the changes in lexer.cpp, etc. are all in there. How did you find differences and what are they?
Ooops, sorry. What I was seeing were some diffs in auto-generated files. -richy. -- Richard B. Kreckel <http://www.ginac.de/~kreckel/>
Hi Richy, Richard B. Kreckel schrieb:
GCC 4.4.1 produces the same error over here. I suppose you aren't seeing it because your's is a 32-bit system?
yes, it is related to 64bit systems. I fixed it in my repository and I will soon push it into public. I am going to do a 1.5.4 release soon. That'll be the cleanest way to progress. And yes, I should finally buy a new computer ... ;-) Regards, Jens
Dear all, On Fri, Jul 31, 2009 at 09:00:10AM +0200, Richard B. Kreckel wrote:
While building Debian packages, g++ 4.3.3 complained "parser/parser.cpp:69: error: cast from 'GiNaC::ex (*)(const GiNaC::exvector&)' to 'unsigned int' loses precision". (Besides, that's a weird error message!)
I think the error message is absolutely correct. The thing is that commit 5fc9d1ab ('Allow user defined functions to be parsed') contains (at least) two (unrelated) bugs. First of all, the parser can not read pow, sqrt, and user-defined classes any more. Secondly, the code is not going to work on 64-bit architectures due to the cast from integer into a pointer (to a function): ginac/parser/default_reader.tpl: for ( unsigned ser=0; ; ++ser ) { GiNaC::function f(ser); std::string name = f.get_name(); for ( std::size_t nargs=0; ; ++nargs ) { try { function::find_function(name, nargs); prototype proto = std::pair<std::string, std::size_t>(name, nargs); std::pair<prototype_table::iterator, bool> ins = reader.insert(std::pair<prototype,reader_func>(proto, (reader_func)ser)); // BAD BAD BAD: converting int into void* I think the above mentioned commit is wrong and should be reverted. Best regards, Alexei
participants (3)
-
Alexei Sheplyakov
-
Jens Vollinga
-
Richard B. Kreckel