From jrheinlaender at gmx.de  Thu Sep  2 08:45:14 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Thu, 02 Sep 2010 11:15:14 +0430
Subject: [GiNaC-devel] Patch
Message-ID: <1283409914.7396.26.camel@localhost.localdomain>

Hello Alexei,

here is my first try at a patch (GiNaC 1.5.8.) Please let me know if it
is OK this way

Jan

----------------------------
1. Problem: MSVC chokes on "or" and "not"
2. Replaced with "||" and "!"

--- clifford.cpp.orig	2010-09-02 07:40:19 +0000
+++ clifford.cpp	2010-09-02 07:42:42 +0000
@@ -1291,11 +1291,11 @@
 	if (algebraic) // check if algebraic method is applicable
 		for (unsigned int i = 0; i < D; i++) 
 			if (pow(c.subs(mu == i, subs_options::no_pattern), 2).is_zero() 
-				or (not is_a<numeric>(pow(c.subs(mu == i,
subs_options::no_pattern), 2))))
+				|| (! is_a<numeric>(pow(c.subs(mu == i, subs_options::no_pattern),
2))))
 				algebraic = false;
 	lst V; 
 	ex v0 = remove_dirac_ONE(canonicalize_clifford(e
+clifford_prime(e)).normal())/2;
-	if (not v0.is_zero())
+	if (! v0.is_zero())
 		V.append(v0);
 	ex e1 = canonicalize_clifford(e - v0 *
dirac_ONE(ex_to<clifford>(c).get_representation_label())); 
 	if (algebraic) {
@@ -1312,7 +1312,7 @@
 			e1 = canonicalize_clifford(expand_dummy_sum(e, true));
 			V.remove_all();
 			v0 = remove_dirac_ONE(canonicalize_clifford(e1
+clifford_prime(e1)).normal())/2;
-			if (not v0.is_zero()) {
+			if (! v0.is_zero()) {
 				V.append(v0);
 				e1 = canonicalize_clifford(e1 - v0 *
dirac_ONE(ex_to<clifford>(c).get_representation_label())); 
 			}




From jrheinlaender at gmx.de  Thu Sep  2 15:57:44 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Thu, 02 Sep 2010 18:27:44 +0430
Subject: [GiNaC-devel] Patch
Message-ID: <1283435864.7396.67.camel@localhost.localdomain>

Hello Alexei,

thank you for your patience. Attached the patch

Best regards,
	Jan

----------------------------
1. Problem: MSVC chokes on "or" and "not"
2. Solution: Replaced with "||" and "!"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: clifford.cpp.patch
Type: text/x-patch
Size: 1109 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100902/42e49d2b/attachment.bin>

From jrheinlaender at gmx.de  Thu Sep  9 05:29:59 2010
From: jrheinlaender at gmx.de (Jan =?ISO-8859-1?Q?Rheinl=E4nder?=)
Date: Thu, 09 Sep 2010 07:59:59 +0430
Subject: [GiNaC-devel] Patch 2
Message-ID: <1284002999.2740.6.camel@localhost.localdomain>

Problem: Return type of function is "ex". MSVC complains that it cannot
convert "GiNaC::power*" to "ex"

Solution: Changed expression to "GiNaC::power" and removed
statusflags::dynallocated

-------------- next part --------------
A non-text attachment was scrubbed...
Name: function.cpp.patch
Type: text/x-patch
Size: 524 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100909/d72cfecf/attachment.bin>

From jrheinlaender at gmx.de  Thu Sep  9 05:31:50 2010
From: jrheinlaender at gmx.de (Jan =?ISO-8859-1?Q?Rheinl=E4nder?=)
Date: Thu, 09 Sep 2010 08:01:50 +0430
Subject: [GiNaC-devel] Patch 3
Message-ID: <1284003110.2740.8.camel@localhost.localdomain>

Problem: MSVC wants a const_iterator

Solution: Changed it

-------------- next part --------------
A non-text attachment was scrubbed...
Name: symmetry.cpp.patch
Type: text/x-patch
Size: 392 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100909/45d95367/attachment.bin>

From jrheinlaender at gmx.de  Thu Sep  9 05:39:29 2010
From: jrheinlaender at gmx.de (Jan =?ISO-8859-1?Q?Rheinl=E4nder?=)
Date: Thu, 09 Sep 2010 08:09:29 +0430
Subject: [GiNaC-devel] Patch 5
Message-ID: <1284003569.2740.17.camel@localhost.localdomain>

Problem: MSVC chokes on "struct"

Solution: Removed it
-------------- next part --------------
A non-text attachment was scrubbed...
Name: collect_vargs.cpp.patch
Type: text/x-patch
Size: 357 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100909/b899b3b1/attachment.bin>

From alexei.sheplyakov at gmail.com  Thu Sep  9 10:53:29 2010
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Thu, 9 Sep 2010 10:53:29 +0200
Subject: [GiNaC-devel] Patch 2
In-Reply-To: <1284002999.2740.6.camel@localhost.localdomain>
References: <1284002999.2740.6.camel@localhost.localdomain>
Message-ID: <AANLkTi=nwEsAcpsN8WkMRZACZiuPGi4Z6x2wdyiA5ZQK@mail.gmail.com>

Hello,

On Thu, Sep 9, 2010 at 5:29 AM, Jan Rheinl?nder <jrheinlaender at gmx.de> wrote:

> Problem: Return type of function is "ex". MSVC complains that it cannot
> convert "GiNaC::power*" to "ex"

This sounds like a compiler bug. ex is actually a wrapper around
GiNaC::ptr<basic>,
and ptr<T> has a ctor ptr::ptr(T* ). power* is a subclass of basic, so
conversion
from power* to ex should be fine. Well, the code is not performance
critical anyway,
so the patch is basically OK. However, could you please add the comment into
the source? Otherwise the code looks a bit silly/suboptimal and someone might
revert your patch by accident.

Best regards,
        Alexei


From jrheinlaender at gmx.de  Thu Sep  9 11:25:59 2010
From: jrheinlaender at gmx.de (Jan =?ISO-8859-1?Q?Rheinl=E4nder?=)
Date: Thu, 09 Sep 2010 13:55:59 +0430
Subject: [GiNaC-devel] Patch 3 updated description
Message-ID: <1284024359.2740.353.camel@localhost.localdomain>

symmetry::compare_same_type(): const-correctness fix

Problem: The method in question is const, therefore one should use const_iterator to
access indices. Some compilers (for instance, MSVC) are very strict
about this, and won't accept (invalid) code using non-const iterator.

Solution: Changed it to const_iterator


-------------- next part --------------
A non-text attachment was scrubbed...
Name: symmetry.cpp.patch
Type: text/x-patch
Size: 392 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100909/48c36220/attachment.bin>

From jrheinlaender at gmx.de  Thu Sep  9 15:05:40 2010
From: jrheinlaender at gmx.de (Jan =?ISO-8859-1?Q?Rheinl=E4nder?=)
Date: Thu, 09 Sep 2010 17:35:40 +0430
Subject: [GiNaC-devel] Patch 4
Message-ID: <1284037541.2740.373.camel@localhost.localdomain>

MSVC unknown functions/symbols

Problem: 
1. MSVC does not know __func__
2. MSVC does not like sizeof(void*) 
3. MSVC does not have __alignof__

Solution: 
1. a) Put AC_CPP_FUNC in acinclude.m4
   b) Added check to configure.ac
   c) Changed parser/debug.h

2. a) Added AC_CHECK_SIZEOF(void*) to configure.ac
   b) Changed polynomial/primes_factory.h

3. a) Added AC_CHECK_ALIGNOF(void*) to configure.ac
   b) Changed polynomial/primes_factory.h


-------------- next part --------------
A non-text attachment was scrubbed...
Name: acinclude.m4.patch
Type: text/x-patch
Size: 1149 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100909/7945bb4d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure.ac.patch
Type: text/x-patch
Size: 383 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100909/7945bb4d/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: debug.h.patch
Type: text/x-patch
Size: 270 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100909/7945bb4d/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: primes_factory.h.patch
Type: text/x-patch
Size: 621 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100909/7945bb4d/attachment-0003.bin>

From jrheinlaender at gmx.de  Thu Sep  9 15:07:07 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Thu, 09 Sep 2010 17:37:07 +0430
Subject: [GiNaC-devel] Patch 2
In-Reply-To: <AANLkTi=nwEsAcpsN8WkMRZACZiuPGi4Z6x2wdyiA5ZQK@mail.gmail.com>
References: <1284002999.2740.6.camel@localhost.localdomain>
	<AANLkTi=nwEsAcpsN8WkMRZACZiuPGi4Z6x2wdyiA5ZQK@mail.gmail.com>
Message-ID: <1284037627.2740.374.camel@localhost.localdomain>

Hello,

> > Problem: Return type of function is "ex". MSVC complains that it cannot
> > convert "GiNaC::power*" to "ex"
last try with ginac 1.5.8 the problem did not appear, so I am dropping
patch 2 for now.

Best regards,
	Jan




From alexei.sheplyakov at gmail.com  Thu Sep  9 15:28:01 2010
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Thu, 9 Sep 2010 15:28:01 +0200
Subject: [GiNaC-devel] Patch 4
In-Reply-To: <1284037541.2740.373.camel@localhost.localdomain>
References: <1284037541.2740.373.camel@localhost.localdomain>
Message-ID: <AANLkTikwmezcs2PwPgh_d_kgXu1YfgemtDhXaKeTuH-1@mail.gmail.com>

Hi again,

On Thu, Sep 9, 2010 at 3:05 PM, Jan Rheinl?nder <jrheinlaender at gmx.de> wrote:
> MSVC unknown functions/symbols

Threre are two problems here. First of all, could you please post a
unified patch? A unified
patch can be made with the following command

diff -Nru ginac.orig ginac.hacked


Secondly, I think your code itself is not completely correct.

> Problem:
> 1. MSVC does not know __func__

Please put something like this into the ginac/compiler.h file

#ifdef MSVC // or whatever it is
#define __func__ "unknown"
#endif

and #include "complier.h" when necessary.

> 2. MSVC does not like sizeof(void*)

This sounds a bit strange. AC_CHECK_SIZEOF(void*) definitely invokes
sizeof(void*).
Could you please exclude this change for now? We'll find the solution later on
(when the remaining issues will be ironed out).

> 3. MSVC does not have __alignof__

However it does have __alignof. Please put the following into ginac/compiler.h

#ifdef MSVC // or whatever it is
#define __alignof__ __alingof
#endif

Best regards,
            Alexei


From alexei.sheplyakov at gmail.com  Thu Sep  9 15:43:42 2010
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Thu, 9 Sep 2010 15:43:42 +0200
Subject: [GiNaC-devel] Patch 4
In-Reply-To: <1284037541.2740.373.camel@localhost.localdomain>
References: <1284037541.2740.373.camel@localhost.localdomain>
Message-ID: <AANLkTimMphaFv=Ay6ihG_T4btgL29zuVWGpFKtqKaDdK@mail.gmail.com>

Hi,

> 2. MSVC does not like sizeof(void*)

Could you please post the exact error message? May be the problem is
caused by something
else? (Otherwise AC_CHECK_SIZEOF(void*) could not possibly work)


From jrheinlaender at gmx.de  Thu Sep  9 17:02:00 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Thu, 09 Sep 2010 19:32:00 +0430
Subject: [GiNaC-devel] Patch 4
In-Reply-To: <AANLkTikwmezcs2PwPgh_d_kgXu1YfgemtDhXaKeTuH-1@mail.gmail.com>
References: <1284037541.2740.373.camel@localhost.localdomain>
	<AANLkTikwmezcs2PwPgh_d_kgXu1YfgemtDhXaKeTuH-1@mail.gmail.com>
Message-ID: <1284044520.2740.404.camel@localhost.localdomain>

Hello Alexei,

1.
2.
I agree with you.

> > 3. MSVC does not have __alignof__
> 
> However it does have __alignof. Please put the following into ginac/compiler.h
> 
> #ifdef MSVC // or whatever it is
> #define __alignof__ __alingof
> #endif

if we use the AC_CHECK_ALIGNOF method, wouldn't that have the advantage
that any future changes in MSVC behaviour (or any other compiler) would
be dealt with by the autoconf maintainers? Otherwise someone would have
to change compiler.h manually every time.

for __func__, since there is no pre-defined autoconf macro anyway, we
might as well use compiler.h

FYI: The macro is _MSC_VER

Best regards,
	Jan




From alexei.sheplyakov at gmail.com  Thu Sep  9 18:01:38 2010
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Thu, 9 Sep 2010 18:01:38 +0200
Subject: [GiNaC-devel] Patch 4
In-Reply-To: <1284044520.2740.404.camel@localhost.localdomain>
References: <1284037541.2740.373.camel@localhost.localdomain>
	<AANLkTikwmezcs2PwPgh_d_kgXu1YfgemtDhXaKeTuH-1@mail.gmail.com>
	<1284044520.2740.404.camel@localhost.localdomain>
Message-ID: <AANLkTikO_uSuJVCTvvT=yWLcTuxKqiokcpHovmqp8_SJ@mail.gmail.com>

Hi,

> if we use the AC_CHECK_ALIGNOF method, wouldn't that have the advantage
> that any future changes in MSVC behaviour (or any other compiler) would
> be dealt with by the autoconf maintainers?

In general I try to avoid using AC_CHECK_* things for computing compile-time
constants (like sizeof(foo), __alignof__(foo), etc). auto* tools
regenerate config.h
way too often, and that results in spurious recompilations. This is
not a problem
for users, but for it creates additional problems for developers. I
mean, when you
trying to find out which commit introduced a regression (say, with git
bisect), you
check out particular version and recompile the thing. auto* tools see
the timestamps
changed => re-generates Makefiles and config.h => and all files which
#include config.h
need to be recompiled => waste of time.Therefore I don't quite like
AC_CHECK_ALIGNOF
thing.

> Otherwise someone would have to change compiler.h manually every time.

I don't think such changes happen often. As a matter of fact, __alignof__ works
just fine with GCC versions 3.4 through 4.5, i.e. there were no
changes in 6 years.
Let's hope that ms authors are smart enough to not introduce
backward-incompatible
changes for no good reason, and use #define instead of autoconf macro.

As a last resort we can define alignof<T> template (a la boost).

Best regards,
        Alexei


From jgpeiro at gmail.com  Fri Sep 10 03:26:32 2010
From: jgpeiro at gmail.com (Jose Antonio Garcia Peiro)
Date: Fri, 10 Sep 2010 03:26:32 +0200
Subject: [GiNaC-devel] proposed integration algorithm
Message-ID: <AANLkTi=_HUpAXcO=Tn5exJ4uPrDkn0+dtVtAQAYdRbg8@mail.gmail.com>

Hi

I am very interested in GiNaC, but I also need symbolic integration,
and GiNaC only compute basic integrals. I wrote a simple recursive
routine that applies a basic integration rules, matching the input
function.
It is a good way to implement integration algoritm?

Thanks


int(c,x) = c*x
int(x,x) = x^2/2
int(f+g,x) = int(f,x) + int(g,x)
int(c*f,x) = c*int(f,x)
int( f^c*1,x) = f^(c+1)/(c+1) or log(f)
int( f^c*f',x) = f^(c+1)/(c+1) or log(f)

some examples:

cout << "int(1+x,x) = " << myinteg( 1 + x, x ) << endl;
                 // 1/2*x^2+x
cout << "int(3*x^2+x+6,x) = " << myinteg( 3*pow(x,2)+x+6, x ) << endl;
       // 1/2*x^2+x^3+6*x
cout << "int((3*x+5)^2*3,x) = " << myinteg( pow(3*x+5,2)*3, x ) <<
endl;       // 1/3*(5+3*x)^3
cout << "int((3*x+5)^(-1)*3,x) = " << myinteg( pow(3*x+5,-1)*3, x ) <<
endl;   // log(5+3*x)
cout << "int((3*x+5)^b*3,x) = " << myinteg( pow(3*x+5,b)*3, x ) <<
endl;       // (1+b)^(-1)*(5+3*x)^(1+b)


the code (with debug messages):
ex myinteg( const ex &f, const symbol &x ){
	
	exmap repls;

	cout << endl << "f(x) = " << f << endl;
	//int(c,x)		c*x
	if( !has( f, x ) ){
		cout << "match int(c,x)" << endl;
		return f*x;
	}

	//int(x,x)		x^2/2
	if( f.is_equal(x) ){
		cout << "match int(x,x)" << endl;	
		return pow(x,2)/2;
	}	

	//int(f+g,x)	int(f,x)+int(g,x)
	if( f.match( wild(0)+wild(1), repls ) ){
		cout << "match int(f+g,x)" << endl;
		cout << "wild(0)+wild(1) = " << repls << endl;
		ex f, g;
		for( exmap::const_iterator i=repls.begin(); i!=repls.end(); ++i){
			if(i->first.is_equal(wild(0)) ){
				f = i->second;
			}else if(i->first.is_equal(wild(1))){
				g = i->second;
			}
		}
		cout << "f = " << f << endl;
		cout << "g = " << g << endl;
		return myinteg( f, x ) + myinteg( g, x );
	}

	//int(c*f,x)		c*int(f,x)
	if( f.match( wild(0)*wild(1), repls ) ){
		cout << "match int(c*f,x)" << endl;
		cout << "wild(0)*wild(1) = " << repls << endl;
		ex c, f;
		for( exmap::const_iterator i=repls.begin(); i!=repls.end(); ++i){
			if(i->first.is_equal(wild(0)) ){
				c = i->second;
			}else if(i->first.is_equal(wild(1))){
				f = i->second;
			}
		}
		if( !has( c, x ) && has( f, x )){
			return c*myinteg( f, x );
		}if( has( c, x ) && !has( f, x )){
			return f*myinteg( c, x );
		}
	}


	//int( pow( f, c ), x )				pow( f, c+1 ) * pow( c+1, -1 ) if c != -1,
 or ln( f ) if c == -1
	if( f.match( pow(wild(0),wild(1)), repls ) ){
		cout << "match int( pow( f, c ), x )" << endl;
		cout << "pow(wild(0),wild(1)) = " << repls << endl;

		ex f, c;
		for( exmap::const_iterator i=repls.begin(); i!=repls.end(); ++i){
			if(i->first.is_equal(wild(0)) ){
				f = i->second;
			}else if(i->first.is_equal(wild(1))){
				c = i->second;
			}
		}
		cout << "f = " << f << endl;
		cout << "c = " << c << endl;
	
		if( has( f, x ) && !has( c, x ) ){
			ex dft = f.diff(x,1);
			ex df = 1;
			cout << "df/dft = " << df/dft << endl;
			if( !has(df/dft,x) ){
				cout << "!has(df/dft,x)" << endl;
		 		if( c.is_equal(-1) ){
					return log( f ) * (df/dft);
				}else{
					cout << "df = " << df << endl;
					cout << "dft = " << dft << endl;
					cout << "(df/dft) = " << (df/dft) << endl;
					cout << "(1/dft) = " << (1/dft) << endl;
					cout << "pow(dft,-1) = " << pow(dft,-1) << endl;
					cout << "f = " << f << endl;
					cout << "c = " << c << endl;
					cout << "(pow( f, c+1 )/( c+1 )) = " << (pow( f, c+1 )/( c+1 )) << endl;
					cout << "pow( f, c+1 )*pow( c+1, -1) = " << pow( f, c+1 )*pow(
c+1, -1) << endl;
					cout << "(pow( f, c+1 )/( c+1 ))*(df/dft) = " << (pow( f, c+1 )/(
c+1 ))*(df/dft) << endl;
					cout << "pow( f, c+1 )*pow( c+1, -1) = " << pow( f, c+1 )*pow(
c+1, -1)*df*pow( dft, -1) << endl;
					return (pow( f, c+1 )/( c+1 )) * (df/dft);
				}
			}
		}

	}
	

	
	//int( pow( f, c ) * f', x )				pow( f, c+1 ) * pow( c+1, -1 ) if c
!= -1,  or ln( f ) if c == -1
	if( f.match( wild(0)*pow(wild(1),wild(2)), repls ) ){
		cout << "match int( pow( f, c ) * f', x )" << endl;
		cout << "wild(0)*pow(wild(1),wild(2)) = " << repls << endl;
	 	ex df, f, c;
		for( exmap::const_iterator i=repls.begin(); i!=repls.end(); ++i){
			if(i->first.is_equal(wild(0)) ){
				df = i->second;
			}else if(i->first.is_equal(wild(1))){
				f = i->second;
			}else if(i->first.is_equal(wild(2))){
				c = i->second;
			}
		}

		cout << "f' = " << df << endl;
		cout << "f = " << f << endl;
		cout << "c = " << c << endl;
	
		if( has( f, x ) && !has( c, x ) ){
			ex dft = f.diff(x,1);
			cout << "df/dft = " << df/dft << endl;
			if( !has(df/dft,x) ){
				cout << "!has(df/dft,x)" << endl;
		 		if( c.is_equal(-1) ){
					return log( f ) * (df/dft);
				}else{
					return pow( f, c+1 )*pow( c+1, -1) * (df/dft);
				}
			}
		}
	}
	

	return 0;
}


From jrheinlaender at gmx.de  Fri Sep 10 05:14:49 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Fri, 10 Sep 2010 07:44:49 +0430
Subject: [GiNaC-devel] Patch 6
Message-ID: <1284088489.2740.410.camel@localhost.localdomain>

Problem: MSVC creates different symbols for "extern const ex _ex0" if it
is declared at top-level (inside GiNaC namespace) and if it is declared
inside the body of a function (also inside GiNaC namespace). When
linking, unresolved external symbols occur.

Solution: Moved the declaration out of the body of the function

Note: Instead of #include utils.h the same effect would probably be
achieved by 
namespace GiNaC {
  extern const ex _ex0;
}
at the beginning of the file.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: _ex0.patch
Type: text/x-patch
Size: 1373 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100910/f3372258/attachment.bin>

From jrheinlaender at gmx.de  Fri Sep 10 05:38:25 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Fri, 10 Sep 2010 08:08:25 +0430
Subject: [GiNaC-devel] Patch 4
Message-ID: <1284089905.2740.423.camel@localhost.localdomain>

Hello Alexei,

OK, so using compiler.h the patch reduces to a fourliner in that file
because compiler.h is being included in all the concerned files
(parse_binop_rhs.cpp, parser.cpp) already anyway.

The sizeof() problem miraculously disappeared...

Problem: 
1. MSVC does not have __func__, but has __FUNCTION__
2. MSVC does not have __alignof__, but has __alignof

Solution: 
Added #defines to compiler.h


-------------- next part --------------
A non-text attachment was scrubbed...
Name: compiler.h.patch
Type: text/x-patch
Size: 290 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100910/a320991e/attachment.bin>

From alexei.sheplyakov at gmail.com  Fri Sep 10 11:25:41 2010
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Fri, 10 Sep 2010 11:25:41 +0200
Subject: [GiNaC-devel] Patch 6
In-Reply-To: <1284088489.2740.410.camel@localhost.localdomain>
References: <1284088489.2740.410.camel@localhost.localdomain>
Message-ID: <AANLkTik2qtx34Fzc5W86Q+3RAif24rA0UuDtS_CaUnOM@mail.gmail.com>

Hi, Jan!

2010/9/10 Jan private <jrheinlaender at gmx.de>:
> Problem: MSVC creates different symbols for "extern const ex _ex0" if it
> is declared at top-level (inside GiNaC namespace) and if it is declared
> inside the body of a function (also inside GiNaC namespace). When
> linking, unresolved external symbols occur.
>
> Solution: Moved the declaration out of the body of the function

I'm afraid your patch is incorrect. The ex.h file is public, and utlis.h is not
(i.e. it's not supposed to be used by programs using GiNaC, and as you
might notice it is not even installed).  In other words, utils.h is supposed
to contain internal functions/variables which should not be exposed to
GiNaC users. Therefore including utils.h from ex.h is just plain wrong.

Also, moving declaration of _ex0 from the ex::ex() ctor scope for all compilers
is not wellcome. _ex0 should not be exposed to user code (in the past that
caused quite a number of problems due to static initialization order fiasco).

> Note: Instead of #include utils.h the same effect would probably be
> achieved by
> namespace GiNaC {
> ?extern const ex _ex0;
> }
> at the beginning of the file.

Please do so, and wrap that into _MSC_VER, and leave the code as is for
other compilers.

Thanks for your efforts.

Best regards,
        Alexei


From jrheinlaender at gmx.de  Sat Sep 11 06:00:46 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Sat, 11 Sep 2010 08:30:46 +0430
Subject: [GiNaC-devel] Patch7
Message-ID: <1284177646.2740.494.camel@localhost.localdomain>

Hello Alexei,

here is another hairy one, which is a compiler bug in my opinion:

Problem: MSVC does not include the exprseq::info() method, giving
unresolved symbols when linking

Solution (rather, workaround): Add an unarchiver :-)

Note: Someone else suggested adding a dummy method in exprseq.cpp

basic* dummy_func(void) { return new exprseq(); }

but I thought that maybe an unarchiver is at least remotely useful...

Have fun!
	Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: info.patch
Type: text/x-patch
Size: 809 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100911/69f40bf6/attachment.bin>

From jrheinlaender at gmx.de  Sat Sep 11 06:02:34 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Sat, 11 Sep 2010 08:32:34 +0430
Subject: [GiNaC-devel] Patch 8
Message-ID: <1284177754.2740.499.camel@localhost.localdomain>

Hello Alexei,

this is the last issue of GiNaC. All 58 tests passed sucessfully.

CLN has a lot of issues left, though :-(

Problem: MSVC cannot handle string constants above 16K

Solution: Split them up into pieces

Best regards,
	Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: time_uvar_gcd.cpp.patch
Type: text/x-patch
Size: 6380 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100911/7773cc4a/attachment.bin>

From jrheinlaender at gmx.de  Sat Sep 11 12:54:39 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Sat, 11 Sep 2010 15:24:39 +0430
Subject: [GiNaC-devel] Patch 6 version 2
In-Reply-To: <AANLkTik2qtx34Fzc5W86Q+3RAif24rA0UuDtS_CaUnOM@mail.gmail.com>
References: <1284088489.2740.410.camel@localhost.localdomain>
	<AANLkTik2qtx34Fzc5W86Q+3RAif24rA0UuDtS_CaUnOM@mail.gmail.com>
Message-ID: <1284202479.2740.609.camel@localhost.localdomain>

Problem: 
1. MSVC creates different symbols for "extern const ex _ex0" if it
is declared at top-level (inside GiNaC namespace) and if it is declared
inside the body of a function (also inside GiNaC namespace). When
linking, unresolved external symbols occur.
2. utils.h declares _num_1_p as const, but parse_binop_rhs.cpp omits the
const. MSVC creates different symbols for the two versions, causing
linking errors
3. parser.cpp mentions 
extern numeric* _num_1_p;
extern ex _ex0;
which cause linking problems

Solution: 
1. Moved the declaration out of the body of the function
2. added the const
3. omitted them because the code compiles without them (probably adding
a const would also solve the problem)

Note to 2: 
[basic.type.qualifier] says:

\begin{quote}
The cv-qualified or cv-unqualified versions of a type are distinct
types;
however, they shall have the same representation and alignment
requirements
(3.9)^46)

46)
The same representation and alignment requirements are meant to imply
interchangeability as arguments to functions, return values from
functions,
and members of unions.
\end{quote}

It is not clear how it's possible for cv-qualified and non-cv-qualified
type to have different mangled names without violating the above
requirements, but anyway - MSVC can do it :-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: _ex0.patch
Type: text/x-patch
Size: 1737 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100911/e8336a11/attachment.bin>

From alexei.sheplyakov at gmail.com  Sat Sep 11 21:30:23 2010
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Sat, 11 Sep 2010 21:30:23 +0200
Subject: [GiNaC-devel] Patch7
In-Reply-To: <1284177646.2740.494.camel@localhost.localdomain>
References: <1284177646.2740.494.camel@localhost.localdomain>
Message-ID: <AANLkTinufGnXffEAR5-LzVyw2OZFv450Xdgh4rvZO3nx@mail.gmail.com>

Hi, Jan!

> Problem: MSVC does not include the exprseq::info() method, giving
> unresolved symbols when linking
>
> Solution (rather, workaround): Add an unarchiver :-)
>
> Note: Someone else suggested adding a dummy method in exprseq.cpp
>
> basic* dummy_func(void) { return new exprseq(); }
>
> but I thought that maybe an unarchiver is at least remotely useful...

I don't think so. Could you please add that dummy function (with a
proper comment
and wrapped by #ifdef _MSC_VER) instead?

Best regards,
        Alexei


From git at ginac.de  Mon Sep 13 22:52:14 2010
From: git at ginac.de (Richard B. Kreckel)
Date: Mon, 13 Sep 2010 22:52:14 +0200 (CEST)
Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic
	computations branch, ginac_1-5, updated. release_1-4-0-248-gdb47e25
Message-ID: <20100913205215.15387F001E1@cebix.net>

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GiNaC -- a C++ library for symbolic computations".

The branch, ginac_1-5 has been updated
       via  db47e259edabbed2b8eb2fa1e4ed93588c26e304 (commit)
      from  cc94094751459129e1392a93dfa0264adac789a5 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit db47e259edabbed2b8eb2fa1e4ed93588c26e304
Author: Richard Kreckel <kreckel at ginac.de>
Date:   Mon Sep 13 22:39:05 2010 +0200

    Fix autoconf warning about AC_INIT use.
    
    Apparently, autoconf doesn't like the angle brackets in the bug-report
    argument any more. It comlains "not a literal: <ginac-list at ginac.de>".
    So let's remove it. And while at it, also provide tarname and url
    arguments.

-----------------------------------------------------------------------

Summary of changes:
 configure.ac |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations


From git at ginac.de  Mon Sep 13 22:52:15 2010
From: git at ginac.de (Richard B. Kreckel)
Date: Mon, 13 Sep 2010 22:52:15 +0200 (CEST)
Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic
	computations branch, master, updated. release_1-4-0-228-g8cce492
Message-ID: <20100913205215.2CC58F00079@cebix.net>

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GiNaC -- a C++ library for symbolic computations".

The branch, master has been updated
       via  8cce492692eb74d636a50f420fd79877e5d4981a (commit)
      from  5f896fa7f59bbce727e4bba23df9c4bbdbb55c29 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 8cce492692eb74d636a50f420fd79877e5d4981a
Author: Richard Kreckel <kreckel at ginac.de>
Date:   Mon Sep 13 22:39:05 2010 +0200

    Fix autoconf warning about AC_INIT use.
    
    Apparently, autoconf doesn't like the angle brackets in the bug-report
    argument any more. It comlains "not a literal: <ginac-list at ginac.de>".
    So let's remove it. And while at it, also provide tarname and url
    arguments.

-----------------------------------------------------------------------

Summary of changes:
 configure.ac |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)


hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations


From jrheinlaender at gmx.de  Tue Sep 14 10:57:03 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Tue, 14 Sep 2010 13:27:03 +0430
Subject: [GiNaC-devel] Patch 6 version 3
In-Reply-To: <AANLkTik2qtx34Fzc5W86Q+3RAif24rA0UuDtS_CaUnOM@mail.gmail.com>
References: <1284088489.2740.410.camel@localhost.localdomain>
	<AANLkTik2qtx34Fzc5W86Q+3RAif24rA0UuDtS_CaUnOM@mail.gmail.com>
Message-ID: <1284454623.16582.115.camel@localhost.localdomain>

Hello Alexei,

I found an error in this one so please use the attached file instead.

Problem: 
1. MSVC creates different symbols for "extern const ex _ex0" if it
is declared at top-level (inside GiNaC namespace) and if it is declared
inside the body of a function (also inside GiNaC namespace). When
linking, unresolved external symbols occur.
2. utils.h declares _num_1_p as const, but parse_binop_rhs.cpp omits the
const. MSVC creates different symbols for the two versions, causing
linking errors
3. parser.cpp mentions 
extern numeric* _num_1_p;
extern ex _ex0;
which cause linking problems

Solution: 
1. Moved the declaration out of the body of the function (for MSVC only)
2. added the const
3. added the const for _ex0 and removed _num_1_p because it is not 
referenced in the file at all

Note to 2: 
[basic.type.qualifier] says:

\begin{quote}
The cv-qualified or cv-unqualified versions of a type are distinct
types;
however, they shall have the same representation and alignment
requirements
(3.9)^46)

46)
The same representation and alignment requirements are meant to imply
interchangeability as arguments to functions, return values from
functions,
and members of unions.
\end{quote}

It is not clear how it's possible for cv-qualified and non-cv-qualified
type to have different mangled names without violating the above
requirements, but anyway - MSVC can do it :-)


-------------- next part --------------
A non-text attachment was scrubbed...
Name: _ex0.patch
Type: text/x-patch
Size: 1757 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100914/be09a151/attachment.bin>

From git at ginac.de  Wed Sep 15 09:38:08 2010
From: git at ginac.de (Richard B. Kreckel)
Date: Wed, 15 Sep 2010 09:38:08 +0200 (CEST)
Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic
	computations branch, ginac_1-5, updated. release_1-4-0-249-g90ad10b
Message-ID: <20100915073809.31619F001EC@cebix.net>

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GiNaC -- a C++ library for symbolic computations".

The branch, ginac_1-5 has been updated
       via  90ad10b58d02365a407b2d84d8b93e50030feaa5 (commit)
      from  db47e259edabbed2b8eb2fa1e4ed93588c26e304 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 90ad10b58d02365a407b2d84d8b93e50030feaa5
Author: Richard Kreckel <kreckel at ginac.de>
Date:   Wed Sep 15 09:11:57 2010 +0200

    Be more careful about final top-level substitution.
    
    Substituting x==log(x) in exp(x) erroneously returned log(x) because of a
    final subst(x==log(x)) after having eval'ed exp(log(x)) -> x. This final
    substitution is wrong in the general case. On the other hand, the intent
    is to syntactically substitute functions of a given kind etc. This patch
    suppresses the final top-level substitution unless the intermediate result
    is a container.
    
    Thanks to Burcin Erocal for reporting this bug (originally described by
    Kees van Schaik on sage-support at googlegroops.com).

-----------------------------------------------------------------------

Summary of changes:
 check/exam_misc.cpp     |    9 +++++++++
 doc/tutorial/ginac.texi |    2 +-
 ginac/container.h       |   24 ++++++++++++++++++++----
 3 files changed, 30 insertions(+), 5 deletions(-)


hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations


From git at ginac.de  Wed Sep 15 09:38:09 2010
From: git at ginac.de (Richard B. Kreckel)
Date: Wed, 15 Sep 2010 09:38:09 +0200 (CEST)
Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic
	computations branch, master, updated. release_1-4-0-229-g9506030
Message-ID: <20100915073809.603B7F00079@cebix.net>

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GiNaC -- a C++ library for symbolic computations".

The branch, master has been updated
       via  9506030d2059ef868d5da8dcbe714c9c5b50ff50 (commit)
      from  8cce492692eb74d636a50f420fd79877e5d4981a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 9506030d2059ef868d5da8dcbe714c9c5b50ff50
Author: Richard Kreckel <kreckel at ginac.de>
Date:   Wed Sep 15 09:11:57 2010 +0200

    Be more careful about final top-level substitution.
    
    Substituting x==log(x) in exp(x) erroneously returned log(x) because of a
    final subst(x==log(x)) after having eval'ed exp(log(x)) -> x. This final
    substitution is wrong in the general case. On the other hand, the intent
    is to syntactically substitute functions of a given kind etc. This patch
    suppresses the final top-level substitution unless the intermediate result
    is a container.
    
    Thanks to Burcin Erocal for reporting this bug (originally described by
    Kees van Schaik on sage-support at googlegroops.com).

-----------------------------------------------------------------------

Summary of changes:
 check/exam_misc.cpp     |    9 +++++++++
 doc/tutorial/ginac.texi |    2 +-
 ginac/container.h       |   24 ++++++++++++++++++++----
 3 files changed, 30 insertions(+), 5 deletions(-)


hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations


From git at ginac.de  Thu Sep 23 00:57:15 2010
From: git at ginac.de (Richard B. Kreckel)
Date: Thu, 23 Sep 2010 00:57:15 +0200 (CEST)
Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic
	computations branch, ginac_1-5, updated. release_1-4-0-250-g89d5356
Message-ID: <20100922225716.3D819F001CB@cebix.net>

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GiNaC -- a C++ library for symbolic computations".

The branch, ginac_1-5 has been updated
       via  89d5356b4aa33cb4481575f9453f36c3404b015b (commit)
      from  90ad10b58d02365a407b2d84d8b93e50030feaa5 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 89d5356b4aa33cb4481575f9453f36c3404b015b
Author: Richard Kreckel <kreckel at ginac.de>
Date:   Thu Sep 23 00:40:38 2010 +0200

    Make sure add::eval() collects all numeric terms.
    
    Apparently, add::eval() assumed that none of the elements of its epvector
    has a numeric rest. However, nothing guarantees that -- in particular
    evalchildren() doesn't (and actually cannot) do so. Since there are many
    places where a new add is constructed directly from an epvector, enforcing
    this doesn't make sense either. One example where it did fail was found by
    Burgin Erocal: real_part(1+2*(sqrt(2)+1)*(sqrt(2)-1)) returned 1+2*1, not 3.
    
    Thanks to Burcin Erocal for reporting this bug.
    (cherry picked from commit e08cda1854bdb82f6706ec269233577690ae00e4)

-----------------------------------------------------------------------

Summary of changes:
 check/exam_paranoia.cpp |   13 +++++++++++++
 ginac/add.cpp           |   31 ++++++++++++++++++++++++++++---
 2 files changed, 41 insertions(+), 3 deletions(-)


hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations


From git at ginac.de  Thu Sep 23 00:57:16 2010
From: git at ginac.de (Richard B. Kreckel)
Date: Thu, 23 Sep 2010 00:57:16 +0200 (CEST)
Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic
	computations branch, master, updated. release_1-4-0-230-ge08cda1
Message-ID: <20100922225716.54785F0007D@cebix.net>

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GiNaC -- a C++ library for symbolic computations".

The branch, master has been updated
       via  e08cda1854bdb82f6706ec269233577690ae00e4 (commit)
      from  9506030d2059ef868d5da8dcbe714c9c5b50ff50 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit e08cda1854bdb82f6706ec269233577690ae00e4
Author: Richard Kreckel <kreckel at ginac.de>
Date:   Thu Sep 23 00:40:38 2010 +0200

    Make sure add::eval() collects all numeric terms.
    
    Apparently, add::eval() assumed that none of the elements of its epvector
    has a numeric rest. However, nothing guarantees that -- in particular
    evalchildren() doesn't (and actually cannot) do so. Since there are many
    places where a new add is constructed directly from an epvector, enforcing
    this doesn't make sense either. One example where it did fail was found by
    Burgin Erocal: real_part(1+2*(sqrt(2)+1)*(sqrt(2)-1)) returned 1+2*1, not 3.
    
    Thanks to Burcin Erocal for reporting this bug.

-----------------------------------------------------------------------

Summary of changes:
 check/exam_paranoia.cpp |   13 +++++++++++++
 ginac/add.cpp           |   31 ++++++++++++++++++++++++++++---
 2 files changed, 41 insertions(+), 3 deletions(-)


hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations


From jrheinlaender at gmx.de  Fri Sep 24 09:57:23 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Fri, 24 Sep 2010 12:27:23 +0430
Subject: [GiNaC-devel] GiNaC msvc support patches
In-Reply-To: <AANLkTim=BTKbPco8+mtd0LvP7qS1Fd7r1XSNXQsrav43@mail.gmail.com>
References: <AANLkTim=BTKbPco8+mtd0LvP7qS1Fd7r1XSNXQsrav43@mail.gmail.com>
Message-ID: <1285315043.2609.12.camel@localhost.localdomain>

Hello Alexei,

> I've applied your patches and created the master.msvc.support branch.
thanks for the effort.

1. I used the download button on the web page you sent and got
a .tar.gz. It didn't have a configure executable, so I was a bit at a
loss on how to start
2. autoreconf complained about missing files in config/, so I copied
these from ginac-1.5.8
3. After that, libtool gave a version mismatch so I copied aclocal.m4
and m4/* from ginac-1.5.8
4. The attached patch seems to somehow have slipped through the cracks
Problem: MSVC chokes on the "struct"
Solution: Removed it
5. After this, compilation went fine. There are still issues with the
build environment (getting the right libraries for linking), but I am
not motivated right now to fix those. I guess they have nothing to do
with GiNaC, anyway.
6. make check compiles, but several of the executables crash. For
example, in exam_matrices.cpp, in exam_evalm(), doing the matrix
multiplication S*S crashes the program
7. I looked through a diff of ginac-1.5.8 and the new branch, but
couldn't find anything obvious yet. Still looking.

Best regards,
	Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: collect_vargs.cpp.patch
Type: text/x-patch
Size: 357 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100924/943f32b7/attachment.bin>

From jrheinlaender at gmx.de  Tue Sep 28 09:31:24 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Tue, 28 Sep 2010 12:01:24 +0430
Subject: [GiNaC-devel] Print function for user-defined function
Message-ID: <1285659084.21849.33.camel@localhost.localdomain>

Hello,

I did this (code shortened to what is interesting):

class imathprint : public print_dflt {
  GINAC_DECLARE_PRINT_CONTEXT(imathprint, print_dflt)
public:
  optstack* poptions; // imathprint-specific print options
  imathprint(std::ostream & os, optstack* popt, unsigned opt = 0) : 
    print_dflt(os, opt), poptions(popt) {};
  static void init();
};

DECLARE_FUNCTION_3P(partialdiff)
static void partialdiff_print_imath(..., const imathprint &c) {}
static void partialdiff_print_ltx(..., const print_context &c) {}

REGISTER_FUNCTION(partialdiff, ...
  print_func<print_latex>(&partialdiff_print_ltx).
  print_func<imathprint>(&partialdiff_print_imath).
  ...);

This gives me an error

func.cpp:1310: error: no matching function for call to
?GiNaC::function_options::print_func(void (*)(const GiNaC::ex&, const
GiNaC::ex&, const GiNaC::ex&, const imathprint&))

But doing the same kind of thing in
GINAC_IMPLEMENT_REGISTERED_CLASS_OPT
works!

What I am trying to do is to create an extended print context imathprint
which has more options and also options of non-integer type.

Any better ideas?

Thank you,
	Jan




From jrheinlaender at gmx.de  Thu Sep 30 16:30:36 2010
From: jrheinlaender at gmx.de (Jan private)
Date: Thu, 30 Sep 2010 19:00:36 +0430
Subject: [GiNaC-devel] GiNaC msvc support patches
In-Reply-To: <20100926181144.GA21433@mmo>
References: <AANLkTim=BTKbPco8+mtd0LvP7qS1Fd7r1XSNXQsrav43@mail.gmail.com>
	<1285315043.2609.12.camel@localhost.localdomain>
	<20100926181144.GA21433@mmo>
Message-ID: <1285857036.11070.67.camel@localhost.localdomain>

Hello Alexei,

> > 6. make check compiles, but several of the executables crash.
> 
> This is a bit strange. The only difference between master and 1.5
> is how parser handles functions (objects of type GiNaC::function).

see attached patch. I _MSV_VER'ed it because it is pretty pointless. If
something like this turns up every time there is a totally unrelated
change, then I will get grey hairs pretty quickly :-(

Anyway, with this patch all 58 tests pass successfully.

> Could you please post the backtrace?
How would I have done that (I guess it is unnecessary now)?

Have you made any progress on the CLN patches?

Best regards,
	Jan


-------------- next part --------------
A non-text attachment was scrubbed...
Name: ncmul.cpp.patch
Type: text/x-patch
Size: 609 bytes
Desc: not available
URL: <http://www.ginac.de/pipermail/ginac-devel/attachments/20100930/d0482f45/attachment.bin>

From alexei.sheplyakov at gmail.com  Thu Sep 30 18:38:02 2010
From: alexei.sheplyakov at gmail.com (Alexei Sheplyakov)
Date: Thu, 30 Sep 2010 16:38:02 +0000
Subject: [GiNaC-devel] Please apply patch 7a2ac488 to the master branch too
Message-ID: <20100930163802.GA26675@mmo>

Hello!

Richard, Jens, could you please apply the patch 7a2ac488
('ncmul::eval(): don't write beyond the end of vector') to the master
branch? That patch fixes invalid code (which does work with GCC, but
not with other compilers).

Best regards,
	Alexei



From git at ginac.de  Thu Sep 30 22:36:09 2010
From: git at ginac.de (Richard B. Kreckel)
Date: Thu, 30 Sep 2010 22:36:09 +0200 (CEST)
Subject: [GiNaC-devel] [SCM] GiNaC -- a C++ library for symbolic
	computations branch, master, updated. release_1-4-0-231-g8fa654f
Message-ID: <20100930203609.58D80F0007D@cebix.net>

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GiNaC -- a C++ library for symbolic computations".

The branch, master has been updated
       via  8fa654f2637fa755e890499ece1a7bc498779ea3 (commit)
      from  e08cda1854bdb82f6706ec269233577690ae00e4 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit 8fa654f2637fa755e890499ece1a7bc498779ea3
Author: Alexei Sheplyakov <varg at metalica.kh.ua>
Date:   Sat Aug 8 13:03:38 2009 +0300

    ncmul::eval(): don't write beyond the end of the vector.

-----------------------------------------------------------------------

Summary of changes:
 ginac/ncmul.cpp |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)


hooks/post-receive
--
GiNaC -- a C++ library for symbolic computations