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
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.
> 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
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
> > 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
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:
> 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.
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 :
> 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:
>> 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.
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.
> 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?
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.
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.
