From kreckel at thep.physik.uni-mainz.de  Sun May  2 22:43:31 2004
From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel)
Date: Sun, 2 May 2004 22:43:31 +0200 (CEST)
Subject: CLN 1.1.7 released
Message-ID: <Pine.LNX.4.33.0405022226230.26948-100000@higgs.physik.uni-mainz.de>

Hi!

This is to announce the availability of CLN version 1.1.7.  It is source
and binary compatible to version 1.1.6.  Noticeable features are fixes for
a couple of corner case bugs and the inclusion of a workaroud for a
miscompilation issue with GCC 3.1.0 - 3.3.4-prerelease.

Cebix: Is my handling of the spec file finally okay?

Qalculate-hackers: Oh, yes, that miscompilation issue is responsible for
crashes you may see when typing into the number base conversion dialog.
It was reported via the Debian BTS.

Enjoy
     -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>



From kreckel at thep.physik.uni-mainz.de  Sat May  8 14:11:34 2004
From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel)
Date: Sat, 8 May 2004 14:11:34 +0200 (CEST)
Subject: C++ module ordering (was: segmentation fault on GiNaC-1.2.0
 using MinGW on Win XP)
In-Reply-To: <m3k6zp6moi.fsf@gossamer.airs.com>
Message-ID: <Pine.LNX.4.33.0405081346220.21192-100000@higgs.physik.uni-mainz.de>

On 6 May 2004, Ian Lance Taylor wrote:
> > Please see <http://www.ginac.de/lists/ginac-devel/msg00623.html>.
>
> Those bits are the end of my message weren't actually written by me.
> They were written by some of the C++ compiler hackers at Cygnus.

So it remains a mystery what was meant by "full runtime dependency
analysis [...] with no linker mods"?  Sad.

> Are you familiar with the init_priority attribute supported by g++?
> It seems to me that it handles most of the problems associated with
> static object initialization order.
>     http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/C---Attributes.html#C++%20Attributes

Sure, but that is only pampering about the real problem: Who establishes
the PRIORITY variables?  The programmer would have to do it manually.
Any programmer is likely to get it wrong if confronted with several
hundreds or even thousands of modules.  Working with an automated
mechanism is much less prone to errors.  Hence init_priority is not at all
an acceptable solution, IMNSHO.

A while ago, I've been debugging an industrial application where the
linker line was basically rearranged automatically based on a self-made
scheme: a script was extracting dependency ordering information scattered
by the programmer.  That solution is equivalant to GCC's init_priority.
The lesson learned from that experience are:

1) Most professional C++ programmers are not aware of there being a
   problem.  Really.  :-(

2) Even if they are, they are unlikely to get it right.  #-(

3) If they don't get it right, debugging code which hasn't even started
   running yet is intersting.  :-/

Best wishes
        -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>



From ian at wasabisystems.com  Sat May  8 16:36:50 2004
From: ian at wasabisystems.com (Ian Lance Taylor)
Date: 08 May 2004 10:36:50 -0400
Subject: C++ module ordering (was: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP)
In-Reply-To: <Pine.LNX.4.33.0405081346220.21192-100000@higgs.physik.uni-mainz.de>
References: <Pine.LNX.4.33.0405081346220.21192-100000@higgs.physik.uni-mainz.de>
Message-ID: <m365b7t27x.fsf@gossamer.airs.com>

"Richard B. Kreckel" <kreckel at ginac.de> writes:

> So it remains a mystery what was meant by "full runtime dependency
> analysis [...] with no linker mods"?  Sad.

Oh, no, I know what that means.  It means that the compiler itself
looks at the constructor and determines what other objects it
references.  The compiler itself then ensures that any constructor for
those other objects are run first.  The compiler should be able to do
a more reliable job than the linker.

One way to do that would for the compiler to generate entries in a
special section for each global constructor.  Each entry in the
section would simply be the name of the global constructor and the
name of another object upon which it depends.  The linker could then
gather that information together and build a topographical map, and
use that map to construct a constructor ordering, much as is done in
Bruno's existing patch.  Circular dependencies would be detected at
link time.

> > Are you familiar with the init_priority attribute supported by g++?
> > It seems to me that it handles most of the problems associated with
> > static object initialization order.
> >     http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/C---Attributes.html#C++%20Attributes
> 
> Sure, but that is only pampering about the real problem: Who establishes
> the PRIORITY variables?  The programmer would have to do it manually.
> Any programmer is likely to get it wrong if confronted with several
> hundreds or even thousands of modules.  Working with an automated
> mechanism is much less prone to errors.  Hence init_priority is not at all
> an acceptable solution, IMNSHO.

Well, even with many modules, you can divide and conquer the problem.
Normally modules come in groups, and you can determine a topographical
sort of the group.  Then you can assign number ranges to the groups.
Then within each group, you can do the right thing.  If there are
circles in the group graph, then you have a problem, but in that case
I suspect that you have a deeper design problem as well.

The other simple approach is to not use global constructors, or at
least not global constructors in which there are cross-module
dependencies.  You instead pay a cost to check that the objects are
initialized before they are used.  In practice I suspect this cost
would be quite small.

Ian


From gdr at integrable-solutions.net  Sun May  9 16:38:42 2004
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 09 May 2004 16:38:42 +0200
Subject: C++ module ordering (was: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP)
In-Reply-To: <Pine.LNX.4.33.0405081346220.21192-100000@higgs.physik.uni-mainz.de>
References: <Pine.LNX.4.33.0405081346220.21192-100000@higgs.physik.uni-mainz.de>
Message-ID: <m31xltis25.fsf@uniton.integrable-solutions.net>

"Richard B. Kreckel" <kreckel at ginac.de> writes:

| On 6 May 2004, Ian Lance Taylor wrote:
| > > Please see <http://www.ginac.de/lists/ginac-devel/msg00623.html>.
| >
| > Those bits are the end of my message weren't actually written by me.
| > They were written by some of the C++ compiler hackers at Cygnus.
| 
| So it remains a mystery what was meant by "full runtime dependency
| analysis [...] with no linker mods"?  Sad.
| 
| > Are you familiar with the init_priority attribute supported by g++?
| > It seems to me that it handles most of the problems associated with
| > static object initialization order.
| >     http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/C---Attributes.html#C++%20Attributes
| 
| Sure, but that is only pampering about the real problem: Who establishes
| the PRIORITY variables?  The programmer would have to do it manually.
| Any programmer is likely to get it wrong if confronted with several
| hundreds or even thousands of modules.  Working with an automated
| mechanism is much less prone to errors.  Hence init_priority is not at all
| an acceptable solution, IMNSHO.

I agree.

| A while ago, I've been debugging an industrial application where the
| linker line was basically rearranged automatically based on a self-made
| scheme: a script was extracting dependency ordering information scattered
| by the programmer.  That solution is equivalant to GCC's init_priority.
| The lesson learned from that experience are:
| 
| 1) Most professional C++ programmers are not aware of there being a
|    problem.  Really.  :-(

I think that is far too excessive.

| 2) Even if they are, they are unlikely to get it right.  #-(
| 
| 3) If they don't get it right, debugging code which hasn't even started
|    running yet is intersting.  :-/

agreed too.

-- Gaby


From gdr at integrable-solutions.net  Sun May  9 16:56:21 2004
From: gdr at integrable-solutions.net (Gabriel Dos Reis)
Date: 09 May 2004 16:56:21 +0200
Subject: C++ module ordering (was: segmentation fault on GiNaC-1.2.0 using MinGW on Win XP)
In-Reply-To: <m365b7t27x.fsf@gossamer.airs.com>
References: <Pine.LNX.4.33.0405081346220.21192-100000@higgs.physik.uni-mainz.de>
	<m365b7t27x.fsf@gossamer.airs.com>
Message-ID: <m3vfj5hcoa.fsf@uniton.integrable-solutions.net>

Ian Lance Taylor <ian at wasabisystems.com> writes:

| "Richard B. Kreckel" <kreckel at ginac.de> writes:
| 
| > So it remains a mystery what was meant by "full runtime dependency
| > analysis [...] with no linker mods"?  Sad.
| 
| Oh, no, I know what that means.  It means that the compiler itself
| looks at the constructor and determines what other objects it
| references.  The compiler itself then ensures that any constructor for
| those other objects are run first.  The compiler should be able to do
| a more reliable job than the linker.
| 
| One way to do that would for the compiler to generate entries in a
| special section for each global constructor.  Each entry in the
| section would simply be the name of the global constructor and the
| name of another object upon which it depends.  The linker could then
| gather that information together and build a topographical map, and
| use that map to construct a constructor ordering, much as is done in
| Bruno's existing patch.  Circular dependencies would be detected at
| link time.
| 
| > > Are you familiar with the init_priority attribute supported by g++?
| > > It seems to me that it handles most of the problems associated with
| > > static object initialization order.
| > >     http://gcc.gnu.org/onlinedocs/gcc-3.4.0/gcc/C---Attributes.html#C++%20Attributes
| > 
| > Sure, but that is only pampering about the real problem: Who establishes
| > the PRIORITY variables?  The programmer would have to do it manually.
| > Any programmer is likely to get it wrong if confronted with several
| > hundreds or even thousands of modules.  Working with an automated
| > mechanism is much less prone to errors.  Hence init_priority is not at all
| > an acceptable solution, IMNSHO.
| 
| Well, even with many modules, you can divide and conquer the problem.
| Normally modules come in groups, and you can determine a topographical
| sort of the group.  Then you can assign number ranges to the groups.
| Then within each group, you can do the right thing.

I suspect Ricky's point is preceily that if that sektch of algorithm
is workable, then it should be tajen care of by the compiler -- those
are simply too much of low level details and the compiler/linker has
more information that it could pass around.  

|  If there are
| circles in the group graph, then you have a problem, but in that case
| I suspect that you have a deeper design problem as well.

yep, but then it would be helpful if such circles are reported by the
compiler/linker as it is processing the translation/instantiation
units.  In presence of templates and "deferred" instantiations, that
even makes more sense where one gets all sorts of headaches.  See

    http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#362
    http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#270

| The other simple approach is to not use global constructors, or at
| least not global constructors in which there are cross-module
| dependencies.  You instead pay a cost to check that the objects are
| initialized before they are used.  In practice I suspect this cost
| would be quite small.

Well, I'm not sure :-)

-- Gaby


From kreckel at thep.physik.uni-mainz.de  Mon May 10 00:26:14 2004
From: kreckel at thep.physik.uni-mainz.de (Richard B. Kreckel)
Date: Mon, 10 May 2004 00:26:14 +0200 (CEST)
Subject: C++ module ordering (was: segmentation fault on GiNaC-1.2.0
 using MinGW on Win XP)
In-Reply-To: <m31xltis25.fsf@uniton.integrable-solutions.net>
Message-ID: <Pine.LNX.4.33.0405100000400.29266-100000@higgs.physik.uni-mainz.de>

On 9 May 2004, Gabriel Dos Reis wrote:
[...]
> | 1) Most professional C++ programmers are not aware of there being a
> |    problem.  Really.  :-(
>
> I think that is far too excessive.

Well, I suppose we can reach agreement by putting that attribute in
quotes.  ;-)

> | 2) Even if they are, they are unlikely to get it right.  #-(
> |
> | 3) If they don't get it right, debugging code which hasn't even started
> |    running yet is intersting.  :-/
>
> agreed too.

Of course such programs can be debugged the way Ian has described.  In
fact, you normally are able to obtain a stack backtrace which makes the
problem apparent.  (That is, unless you are completely clueless and the
debugging version is built differently and doesn't core as opposed to
the release version.  (Oops, we've just had this case in GiNaC the other
way round, haven't we?))

Let me mention that the dependency problem may be somewhat aggravated in
the situation where a stack of libraries sit on top of each other and
where static objects from the higher libs depend on properly initialized
static objects from the lower levels.  I suppose this could be done, too,
by the compiler?

<offtopic>
Anyway, that whole static domain is IMO somewhat uncared for in C++.
Which is unfortunate.  It does give other environments a real competitive
advantage.  Without claiming actual experience, I've frequently pondered
whether a class static section (of Java fame) wouldn't be quite useful.
Useful for things less mundane than establishing initialization orders, of
course.  But that is another story.
</offtopic>

Luck
   -richy.
-- 
Richard B. Kreckel
<http://www.ginac.de/~kreckel/>



From chrisd at sci.kun.nl  Tue May 18 12:25:11 2004
From: chrisd at sci.kun.nl (Chris Dams)
Date: Tue, 18 May 2004 10:25:11 +0000 (UTC)
Subject: series and expansion.
Message-ID: <Pine.LNX.4.44.0405180942050.6539-100000@gamow.sci.kun.nl>


Dear developers,

Some time ago I sent a patch to prevent .series() to revert to .expand()
internally. This was because in the case that one has
polynomial^some_large_integer the expansion will be hopeless. However, I
keep running into this kind of problems. To determine the real_ldegree in
mul::pseries, still expansion is used with potentially the same problems.

I think there are two possible solutions to this problem.
(1) Tell your users (me included) that they should not be substituting
polynomials into each others when they should have used power series from
the start.
(2) Create (or ask me to create) a patch that solves this particular case
and hope that there will not be ten other instances where .series() is
going to crash a program.
(3) Forbid any occurance of .expand() in any method or function that may
be called from .series(). Create a new method to determine the leading
behaviour of any expression. Let .series() use this and let .series() work
by calculating power series of subexpressions and combining these into the
power series for the entire expression.

I am in favour of (3). The only reason not to use (3) would be if someone
in this mailing list could come up with an example where (3) clearly is
horribly inefficient.

What do other people think?

Best,
Chris Dams