interfaces/maple subdir in 1.1.4 tarball?

[jjm]

Hi,

I've had trouble installing linbox-1.1.4 because the configure process
fails just before the end with

config.status: error: cannot find input file: interfaces/maple/
Makefile.in

Now I've checked and there is no maple directory in interfaces/, at
least not in the version of the tarball I get from

http://www.linalg.org/linbox-1.1.4.tar.gz

I can't see that this interfaces/maple could or should be created
along the way, so I think it is missing.

I have repeated the download/configure from CentOS and Fedora Core
linuxes on different days and with more than one browser. Same results
every time.

I have done some (a lot really) of googling and eventually found a
listing of what should be in that directory. I grabbed all the files
(really don't like doing this, but as a test) from

http://sage.math.washington.edu/home/pernet/Logiciels/linbox/interfaces/maple/

and now the package seems to have compiled fully and cleanly. But I
don't want to use this cobbled together version.

Where or how should I be getting the interfaces/maple/ stuff? Am I
missing something obvious?

Thanks in advance,
John.

[Clement Pernet]

Hi,

The interface/maple directory is indeed missing in linbox-1.1.4, due to a mistake that I probably did.
You can use the current svn version of the library. To get it, simply type

svn co svn://linalg.org/linalg/trunk/linbox/


However, if you don't need to run the maple interface, just don't specify the --with-maple argument to the configure script and the library should compile.
I'll try to fix it asap, although I don't have an easy internet access until january.

Sorry for the inconvenience.

Clément

2007/11/30, jjm < j...@mcs.st-and.ac.uk>:

[jjm]

On Dec 3, 3:49 pm, "Clement Pernet" <clement.per...@gmail.com> wrote:
> Hi,
>
> The interface/maple directory is indeed missing in linbox-1.1.4, due to a
> mistake that I probably did.
> You can use the current svn version of the library. To get it, simply type
>
> svn co svn://linalg.org/linalg/trunk/linbox/
>
> However, if you don't need to run the maple interface, just don't specify
> the --with-maple argument to the configure script and the library should
> compile.

Thanks. Indeed I don't need the maple interface. But whether with the
option '--with-maple=no' or with no '--with-maple' option, I still
get

config.status: error: cannot find input file: interfaces/maple/
Makefile.in

(I'm simply running configure with '--with-blas=/usr/lib/libblas.so.
3')

John.

> I'll try to fix it asap, although I don't have an easy internet access until
> january.
>
> Sorry for the inconvenience.
>
> Clément
>
> 2007/11/30, jjm <j...@mcs.st-and.ac.uk>:
>
>
>
> > Hi,
>
> > I've had trouble installing linbox-1.1.4 because the configure process
> > fails just before the end with
>
> > config.status: error: cannot find input file: interfaces/maple/
> > Makefile.in
>
> > Now I've checked and there is no maple directory in interfaces/, at
> > least not in the version of the tarball I get from
>
> >http://www.linalg.org/linbox-1.1.4.tar.gz
>
> > I can't see that this interfaces/maple could or should be created
> > along the way, so I think it is missing.
>
> > I have repeated the download/configure from CentOS and Fedora Core
> > linuxes on different days and with more than one browser. Same results
> > every time.
>
> > I have done some (a lot really) of googling and eventually found a
> > listing of what should be in that directory. I grabbed all the files
> > (really don't like doing this, but as a test) from
>

> >http://sage.math.washington.edu/home/pernet/Logiciels/linbox/interfac...

[pas1001]

Clément,

Will you have a chance to fix the broken 1.1.4 tarball some time soon?
Or, even better, is there a 1.1.5 due out?

I've been working on a GAP-LinBox interface package which is ready to
roll out for people to try out, but I don't want to tell the GAP users
about it until LinBox itself is straightforward for a naive user to
build, and with a broken tarball, it isn't!

Cheers

Paul


On Dec 3 2007, 3:49 pm, "Clement Pernet" <clement.per...@gmail.com>
wrote:

[Clement Pernet]

Hello Pascal,

Thanks for the reminder.

It is definitely urgent to release a new tarball without this maple
directory bug.
Although there has been very few changes since 1.1.4, I don't want to
release the uptodate svn rep with the same version number (it also
includes a few bug fixes).

So I propose to release 1.1.5 very shortly (before the end the current
week).

* Does any LinBoxer object to this idea?
* Does any one has some code that *has to be* in 1.1.5, and would be
reasonably easy (ie within a few days) to check in and debug?

For this last point, I have a suggestion:
make currently builds the drivers by default, which takes a while.
Although it is important since it test the compilation of a big range of
the code, I would prefer to have this compilation optional, (eg make
driver).
Would you object to that ?
Pascal (Giorgi), I was unable to find a clean way to add this *driver*
target, can you help me with that?

Cheers
Clément

fixing including the mapleThe few
pas1001 a écrit :

[pas1001]

Clément,

The news that a 1.1.5 is planned for this week is great. There's two
things that would really be very useful to me if you could include.
They are:

(1) Fixing the exception handling - the way it's current written, this
_always_ crashes if you try to catch and display an exception. I
submitted a patch a while back, but it's not been incorporated into
the svn version yet. It's only a small change and since no-one else
(clearly!) catches exceptions, it shouldn't break anything to put it
in. The patch file is copied below, and I would class fixing this as
urgent.

(2) Would anyone complain if building shared libraries was turned on
by default in LinBox? I need the shared LinBox library to interface
with my GAP package, and it would be easier if it was built by default
rather than telling every user to configure LinBox with --enable-
shared.

Cheers

Paul

---------------------------------------------------------------------------
Exceptions patch file - snip between the lines
---------------------------------------------------------------------------
--- linbox/util/error.h 2007-11-09 10:49:37.000000000 +0000
+++ linbox/util/error.h.fixed 2007-11-09 10:49:22.000000000 +0000
@@ -34,9 +34,10 @@
\ingroup util
*/
class LinboxError {
+ const static size_t max_error_string = 256;
public:
LinboxError (const char* msg = 0)
- : strg (msg) {};
+ {strncpy(strg, msg, max_error_string); strg[max_error_string-1] =
0;};

// -- virtual print of the error message
virtual std::ostream &print (std::ostream &o) const
@@ -49,10 +50,10 @@
static void throw_error (const LinboxError &err)
{ throw err; }

- virtual ~LinboxError() { delete strg; }
+ virtual ~LinboxError() {}

protected:
- const char* strg;
+ char strg[max_error_string];
};

class LinboxMathError : public LinboxError {
---------------------------------------------------------------------------

[Clement Pernet]

On Jan 29, 2:22 am, pas1001 <pas1...@gmail.com> wrote:
> Clément,
>
> The news that a 1.1.5 is planned for this week is great. There's two
> things that would really be very useful to me if you could include.
> They are:
>
> (1) Fixing the exception handling - the way it's current written, this
> _always_ crashes if you try to catch and display an exception. I
> submitted a patch a while back, but it's not been incorporated into
> the svn version yet. It's only a small change and since no-one else
> (clearly!) catches exceptions, it shouldn't break anything to put it
> in. The patch file is copied below, and I would class fixing this as
> urgent.

Ok, I have applied your patch to util/error.h.

>
> (2) Would anyone complain if building shared libraries was turned on
> by default in LinBox? I need the shared LinBox library to interface
> with my GAP package, and it would be easier if it was built by default
> rather than telling every user to configure LinBox with --enable-
> shared.

I wouldn't.
LinBoxers, do you have any objections to compile the shared libs by
default?
Of course, if anyone still wants to disable it, he can use the --
disable-shared option.

A thought about releasing 1.1.5: I will be at Sage Days 7 next week,
and it is very likely that I will have to fix bugs in linbox during
the coding sprints.
It would make more sense to release 1.1.5 right after SD7 then. Paul,
I hope you can wait one more week ! I can still provide you with a
release candidate 1.1.5rc1, if you need.

Clément

[David Saunders]

Clement Pernet wrote:
> On Jan 29, 2:22 am, pas1001 <pas1...@gmail.com> wrote:
>> Clément,
>>
>> The news that a 1.1.5 is planned for this week is great. There's two
>> things that would really be very useful to me if you could include.
>> They are:
>>
>> (1) Fixing the exception handling - the way it's current written, this
>> _always_ crashes if you try to catch and display an exception. I
>> submitted a patch a while back, but it's not been incorporated into
>> the svn version yet. It's only a small change and since no-one else
>> (clearly!) catches exceptions, it shouldn't break anything to put it
>> in. The patch file is copied below, and I would class fixing this as
>> urgent.
>
> Ok, I have applied your patch to util/error.h.
>
>> (2) Would anyone complain if building shared libraries was turned on
>> by default in LinBox? I need the shared LinBox library to interface
>> with my GAP package, and it would be easier if it was built by default
>> rather than telling every user to configure LinBox with --enable-
>> shared.
>
> I wouldn't.
> LinBoxers, do you have any objections to compile the shared libs by
> default?
> Of course, if anyone still wants to disable it, he can use the --
> disable-shared option.

I am in support of shared libraries. That said, what exactly are we
proposing to compile and put in the libs? The question is only
meaningful vis a vis support for interfaces, stuff in the driver, or so,
right? The only other non-template code is a few odd bits in the util
directory (and that is not, by itself, worth the trouble to create libs,
dynamic or static - hence the widespread use of LinBoxSrcOnly flag.)
Still, I think more compiling is in our future and we should consider,
for instance, compiling the solutions functions for, say, integer dense
and sparse matrices. But if we do that we also compile the chosen dense
(BlasBlackbox) and sparse (?) classes against the integers. Anything else?

I have a student here working on a web service. For that we are
creating a suite of "pipe" functions. They take two arguments, an input
stream and an output stream. They read a matrix off the input stream
(in some supported serialized format) and write the solution (eg. det)
to the ostream. I suppose providing these in the dynamic lib could
become worthwhile.

>
> A thought about releasing 1.1.5: I will be at Sage Days 7 next week,
> and it is very likely that I will have to fix bugs in linbox during
> the coding sprints.
> It would make more sense to release 1.1.5 right after SD7 then. Paul,
> I hope you can wait one more week ! I can still provide you with a
> release candidate 1.1.5rc1, if you need.

I would like to make some fixes to the matrix stream reader and the
smith form. I think I can get that done this week. Please check with
me before building 1.1.5.

Cheers, -dave

>
> Clément
>
>
>
> >

[Clement Pernet]

I bring this discussion up, to announce that a release candidate for
LinBox 1.1.5 is already available as a "developer release"

http://linalg.org/download.html

I am still waiting to work more on making it work in Sage, so that we
could benefit from an extensive compilation check.

Clement