Close Issues -> Close Fricas Issues
Martin Rubey
since FriCAS is progressing quite rapidly what concerns closing issues, how
shall we proceed on issuetracker?
I see two possibilities:
1) Since MathAction runs FriCAS, and FriCAS applies patches from open-axiom and
axiom relatively quickly, we close those issues that are fixed in FriCAS.
2) By magic, or Bill Page, we introduce the possibility of closing issues for
any subset of {axiom, open-axiom, fricas}. I have no idea how that could
work, however. In particular, if one selects "open issues", what subset of
issues does he get then?
(I see, you are experimenting with running all axioms on MathAction?)
Martin
Bill Page
>
> since FriCAS is progressing quite rapidly what concerns closing
> issues, how shall we proceed on issuetracker?
http://axiom-wiki.newsynthesis.org/IssueTracker
>
> I see two possibilities:
>
> 1) Since MathAction runs FriCAS, and FriCAS applies patches
> from open-axiom and axiom relatively quickly, we close those
> issues that are fixed in FriCAS.
>
No, I do not think that is a good idea. I would like the new
axiom-wiki to continue to serve the needs of all of the Axiom-related
projects.
> 2) By magic, or Bill Page, we introduce the possibility of closing
> issues for any subset of {axiom, open-axiom, fricas}. I have
> no idea how that could work, however. In particular, if one
> selects "open issues", what subset of issues does he get then?
>
No, I think that is too complicated. What I would like to do is to
have bug reports that are specific to each version/fork. Right now
this is not the case. But what I think we should do as issues are
reviews and/or closed in a particular system, and if the issue is
still outstanding in one or more of the other systems, I think we
should clone the bug reports (make copies for each system) and then
close the ones where the bug is fixed. I know that this might seem
like extra work, but copying these reports is really pretty easy just
using cut-and-paste in edit mode.
> (I see, you are experimenting with running all axioms on
> MathAction?)
>
Yes, I have a preliminary version of the axiom-wiki installed at
newsynthesis.org (aka. sage.math) that does support all three
versions/forks of axiom. This is easily expanded and configured
if/when more versions become available. Right now only the FriCAS
version supports Aldor.
The way I choose to do this in the end was to make it possible to
specify which version/fork of Axiom is to be used on a particular web
page. More than one version/fork of Axiom *cannot* be mixed on the
same page. Although this may not be quite as flexible as we might have
wished, I think it will help to keep things simple.
You can select the version/fork of Axiom that you want to use for the
computation on a page in the 'edit' window and on the IssueTracker bug
report form.
You might also notice that I have made some significant changes to the
navigation on the axiom-wiki website. There is a topics list on the
lefthand side and there are hierachy/ontology navigation arrows
available at the top of the page. I would be quite interested to hear
opinions about these new features at:
http://axiom-wiki.newsynthesis.org
As usual, there remains a lot of work to do to update the axiom-wiki.
I would like to encourage anyone who has some motivations to improve
this site to "jump in" and make a contribution!
Regards,
Bill Page.
Martin Rubey
> > I see two possibilities:
> >
> > 1) Since MathAction runs FriCAS, and FriCAS applies patches
> > from open-axiom and axiom relatively quickly, we close those
> > issues that are fixed in FriCAS.
> >
>
> No, I do not think that is a good idea. I would like the new
> axiom-wiki to continue to serve the needs of all of the Axiom-related
> projects.
OK
> > 2) By magic, or Bill Page, we introduce the possibility of closing
> > issues for any subset of {axiom, open-axiom, fricas}. I have
> > no idea how that could work, however. In particular, if one
> > selects "open issues", what subset of issues does he get then?
> >
>
> No, I think that is too complicated. What I would like to do is to have bug
> reports that are specific to each version/fork. Right now this is not the
> case. But what I think we should do as issues are reviews and/or closed in a
> particular system, and if the issue is still outstanding in one or more of
> the other systems, I think we should clone the bug reports (make copies for
> each system) and then close the ones where the bug is fixed. I know that this
> might seem like extra work, but copying these reports is really pretty easy
> just using cut-and-paste in edit mode.
I disagree. Most bug reports will relate to the algebra, and thus affect all
versions of axiom. Cloning all these reports means duplicate effort.
I guess the simplest solution is to replace the "status" categories as follows:
open ... open in all versions
closed ... closed in all versions
closed in FriCAS
closed in OpenAxiom
closed in Axiom
open in FriCAS --- closed in Axiom and OpenAxiom
open in OpenAxiom
open in Axiom
many of the others are not needed or could be merged:
assigned, revised, postponed -> not needed
pending, planned, testing -> merge with fix proposed
not reproducible, need more info -> merge
I think that would be much better organized.
Martin
Bill Page
On 13 Dec 2007 08:08:05 +0100, Martin Rubey wrote:
> ...
> > > 2) By magic, or Bill Page, we introduce the possibility of closing
> > > issues for any subset of {axiom, open-axiom, fricas}. I have
> > > no idea how that could work, however. In particular, if one
> > > selects "open issues", what subset of issues does he get then?
> > >
> >
> > No, I think that is too complicated. What I would like to do is to have
> > bug reports that are specific to each version/fork. Right now this is
> > not the case. But what I think we should do as issues are reviews
> > and/or closed in a particular system, and if the issue is still outstanding
> > in one or more of the other systems, I think we should clone the bug
> > reports (make copies for each system) and then close the ones where
> > the bug is fixed. I know that this might seem like extra work, but
> > copying these reports is really pretty easy just using cut-and-paste
> > in edit mode.
>
> I disagree. Most bug reports will relate to the algebra, and thus affect
> all versions of axiom. Cloning all these reports means duplicate effort.
>
I do not think there is any significant duplication of effort. In each
case it is necessary to check that the bug is fixed in a given
version/fork of Axiom. Making a copy of the issue report and changing
the "Axiom Version" to point to that version, then refreshing the page
should make the bug disappear. Really only then it makes sense to
close that report - for that version/fork of Axiom.
> I guess the simplest solution is to replace the "status" categories
> as follows:
>
> open ... open in all versions
> closed ... closed in all versions
>
> closed in FriCAS
> closed in OpenAxiom
> closed in Axiom
>
> open in FriCAS --- closed in Axiom and OpenAxiom
> open in OpenAxiom
> open in Axiom
>
> many of the others are not needed or could be merged:
>
> assigned, revised, postponed -> not needed
>
> pending, planned, testing -> merge with fix proposed
>
> not reproducible, need more info -> merge
>
> I think that would be much better organized.
>
I am not against revising the status categories so they are more
specific and better organized but I do think it is essential that we
treat all versions/forks of Axiom on an equal footing on the
NewSynthesis Axiom Wiki. Doing things the way you suggest does not
seem sufficiently equitable to me.
Regards,
Bill Page.
Gabriel Dos Reis
| I am not against revising the status categories so they are more
| specific and better organized but I do think it is essential that we
| treat all versions/forks of Axiom on an equal footing on the
| NewSynthesis Axiom Wiki. Doing things the way you suggest does not
| seem sufficiently equitable to me.
It is normal for people to preach for the religion they like the best.
Bill, it is your project; so, I'll let you decide -- I appreciate your
effort at being equitable.
-- Gaby
Bill Page
On 12/13/07, you wrote:
>
> On Thu, 13 Dec 2007, Bill Page wrote:
>
> | I am not against revising the status categories so they are
> | more specific and better organized but I do think it is essential
> | that we treat all versions/forks of Axiom on an equal footing on
> | the NewSynthesis Axiom Wiki. Doing things the way you
> | suggest does not seem sufficiently equitable to me.
>
> It is normal for people to preach for the religion they like the
> best.
Yes. I am glad for comments, questions or suggestions from anyone. But
actual material contributions are the best of all... :-)
>
> Bill, it is your project; so, I'll let you decide -- I appreciate your
> effort at being equitable.
>
The phrase "your project" might often be interpreted as a euphemism
for "don't expect any help from me" ;-) especially when something is
intended as a "community" effort.
Anyway now that we can support OpenAxiom on the Axiom Wiki I would
like to create some pages specifically to show off some of what is
different about OpenAxiom compared to the others. I have a little
start at that here:
http://axiom-wiki.newsynthesis.org/SandBoxOpenAxiom
I would like to expand this, add some useful documentation or
references to documentation and then make it a full-fledged "article"
page rather than just a "sandbox" page. If you or anyone in your group
would like to contribute to this, it would be a great help to me. So
far all that I have is what I can follow from your patches and posts
to the open-axiom list.
Regards,
Bill Page.
Martin Rubey
> > I guess the simplest solution is to replace the "status" categories
> > as follows:
> >
> > open ... open in all versions
> > closed ... closed in all versions
> >
> > closed in FriCAS
> > closed in OpenAxiom
> > closed in Axiom
> >
> > open in FriCAS --- closed in Axiom and OpenAxiom
> > open in OpenAxiom
> > open in Axiom
> >
> > many of the others are not needed or could be merged:
> >
> > assigned, revised, postponed -> not needed
> >
> > pending, planned, testing -> merge with fix proposed
> >
> > not reproducible, need more info -> merge
> >
> > I think that would be much better organized.
> >
>
> I am not against revising the status categories so they are more
> specific and better organized but I do think it is essential that we
> treat all versions/forks of Axiom on an equal footing on the
> NewSynthesis Axiom Wiki. Doing things the way you suggest does not
> seem sufficiently equitable to me.
Sorry, I can't see: which version of axiom would be preferred by the proposal
above?
Martin
Bill Page
> ...
> the proposal above?
>
The version of axiom that no longer exhibits the problem.
Regards,
Bill Page.
Martin Rubey
But I'd guess that would vary from issue to issue. And, apart of that, what's
wrong with preferring a version that has an issue closed?
I'd expect that it would rather be an impetus for the others to close the issue
themselves, too. In fact, that's the reason why I propose the scheme: as you
know, the only stuff I really can deal with are the algebra issues. Thus,
given that my proposal is implemented, one rainy day I'd click on
"closed in XXX"
and I'd immediately see which patches have not yet been transferred to YYY and
ZZZ. Since patching the algebra is mostly very easy (once the problem is
solved), it is very little effort to fix YYY and ZZZ and thus have the algebra
synchronized.
Or, if I hit a bug in the version I use, say "ZZZ", I can look at IssueTracker
and see *immediately* whether it has been solved in another version yet.
I'd expect that cloning the issues will imply significant overhead.
Martin
Martin Rubey
> > (I see, you are experimenting with running all axioms on
> > MathAction?)
> >
>
> Yes, I have a preliminary version of the axiom-wiki installed at
> newsynthesis.org (aka. sage.math) that does support all three
> versions/forks of axiom. This is easily expanded and configured
> if/when more versions become available. Right now only the FriCAS
> version supports Aldor.
>
> The way I choose to do this in the end was to make it possible to
> specify which version/fork of Axiom is to be used on a particular web
> page. More than one version/fork of Axiom *cannot* be mixed on the
> same page. Although this may not be quite as flexible as we might have
> wished, I think it will help to keep things simple.
Great!
One minor thing: would it be possible to automatically display the version
which is used on the page, if it differs from the default version?
(Minor, since where it *really* matters, i.e., on IssueTracker, it's visible)
Martin
Martin Rubey
> I am not against revising the status categories so they are more specific and
> better organized but I do think it is essential that we treat all
> versions/forks of Axiom on an equal footing on the NewSynthesis Axiom
> Wiki. Doing things the way you suggest does not seem sufficiently equitable
> to me.
As some of you may have noticed, I spent some effort in getting IssueTracker up
to date, at least with respect to FriCAS. I would now like to further pursue
this by revising the possible statuses and categories.
My intention is to simplify as much as possible the classification process for
bug submitters. For developers (for example, myself) it is also important to
have well classified issues, because I am sometimes in bug squashing mood, and
then I go through the bugs and look which one I think I'm able to close given
the amount of time I can spend. Currently it takes already half an hour to
reclassify ill-classified bugs...
Thus, I ask you to comment. I'll wait a week or so (unless I get only
encouraging comments), if I do not get any comments until then, I'll just go
ahead. Meanwhile I'll only reclassify.
Happy new year,
Martin
Here comes the proposal:
statuses:
I suggest to reduce the possible statuses to:
open
closed
fix proposed
rejected
duplicate
not reproducible
need more info
I.e., the statuses
assigned [1], revised [0], postponed [1], planned [1], pending [6], testing [1]
should be deleted. The issues currently listed with this status (in square
brackets the number of such issues) can all be easily reclassified.
categories:
I suggest to reduce/change the possible categories to:
Axiom Compiler (rename to SPAD compiler)
Axiom Library
Axiom Interpreter
Axiom Documentation
Axiom User Interface
Axiom-Aldor Interaction
MathAction
lisp system
I'm not so sure what to do with:
Axiom on Windows
Axiom on Linux
Axiom on MacOSX
building Axiom from source [23]
There are indeed problems particular to MS Windows or Linux or MacOSX, but
often these are related to the build process. On the other hand, build
troubles are often common to all platforms... The problem I have is that
sometimes submitters put bugs into Axiom on Windows even though it's really a
problem with the Algebra code. I guess, the best thing is to keep it for now.
Doyen CD
this could possibly be merged with Axiom User Interface
All other categories should be deleted. Reasons:
Aldor Library Compiler [6]
Aldor Standalone Compiler [2]
Aldor has its own bug-tracking system, and as long as Aldor is non-free, we
cannot merge the bug databases.
Axiom Mathematics [28]
most of the issues in this category should be moved to Axiom Library, some to
the Axiom Interpreter. I guess the original intention was to provide a place
to discuss problems of design, rather than programming (like, for example,
semantics of 'Fraction Fraction R' or 'Complex PF 5'). I propose to delete
this category, since it seems to confuse many users.
general [4]
Quite superfluous. Such issues can be sent to the mailing list, with a higher
chance of being resolved.
Axiom Programming [1]
Axiom Foundation [0]
Donations [0]
Bounties [0]
New feature request [3]
easily reclassified.
Comments welcome,
Martin
Bill Page
> Dear Bill, *
>
> > I am not against revising the status categories so they are more specific
> > and better organized but I do think it is essential that we treat all
> > versions/forks of Axiom on an equal footing on the NewSynthesis Axiom
> > Wiki. Doing things the way you suggest does not seem sufficiently
> > equitable to me.
>
> As some of you may have noticed, I spent some effort in getting IssueTracker
> up to date, at least with respect to FriCAS. I would now like to further pursue
> this by revising the possible statuses and categories.
Thanks, Martin. I really appreciate your work on this!
>
> My intention is to simplify as much as possible the classification process
> for bug submitters. For developers (for example, myself) it is also important
> to have well classified issues, because I am sometimes in bug squashing
> mood, and then I go through the bugs and look which one I think I'm able to
> close given the amount of time I can spend. Currently it takes already half
> an hour to reclassify ill-classified bugs...
>
I agree.
>
> Thus, I ask you to comment. I'll wait a week or so (unless I get only
> encouraging comments), if I do not get any comments until then, I'll
> just go ahead.
If you need any technical help changing the list of categories just
let me know. (You will find the list of categories under the
properties tab in the mathaction folder in the Zope management
interface.)
> Meanwhile I'll only reclassify.
>
Ok.
>
> Here comes the proposal:
>
> statuses:
>
> I suggest to reduce the possible statuses to:
>
> open
> closed
> fix proposed
> rejected
> duplicate
> not reproducible
> need more info
>
> I.e., the statuses
>
> assigned [1], revised [0], postponed [1], planned [1], pending [6],
> testing [1]
>
> should be deleted. The issues currently listed with this status
> (in square brackets the number of such issues) can all be easily
> reclassified.
>
I agree.
> categories:
>
> I suggest to reduce/change the possible categories to:
>
> Axiom Compiler (rename to SPAD compiler)
> Axiom Library
> Axiom Interpreter
> Axiom Documentation
> Axiom User Interface
> Axiom-Aldor Interaction
> MathAction
> lisp system
>
Ok.
> I'm not so sure what to do with:
>
> Axiom on Windows
> Axiom on Linux
> Axiom on MacOSX
These also would seem to interact with the new "Axiom Version" field.
Right now that field also affects work version of Axiom is run to
create the output on the page (if any). Maybe that was not a good idea
since I think it would be convenient to be able to enter "Windows and
MacOSX" here but right now there is no way to run these versions on
the mathaction (sage.math) server which is a linux system. In
principle this should be possible through a remote or virtual machine
but it might be a bit challenging.
> building Axiom from source [23]
I believe that we should keep this one. It's use seems clear to me.
>
> There are indeed problems particular to MS Windows or Linux or MacOSX,
> but often these are related to the build process. On the other hand, build
> troubles are often common to all platforms... The problem I have is that
> sometimes submitters put bugs into Axiom on Windows even though it's
> really a problem with the Algebra code.
I agree that as "categories" they do not make much sense.
> I guess, the best thing is to keep it for now.
>
I am not sure. But Having two fields in the issue report such as 1)
"affects what Axiom Version ..." and 2) "execute examples using Axiom
Version ..." seems confusing to me. Any other ideas?
> Doyen CD
>
> this could possibly be merged with Axiom User Interface
>
I think it should remain separate.
>
>
> All other categories should be deleted. Reasons:
>
> Aldor Library Compiler [6]
> Aldor Standalone Compiler [2]
>
> Aldor has its own bug-tracking system, and as long as Aldor
> is non-free, we cannot merge the bug databases.
>
I do not see th license status as a problem with respect to reporting
bugs. Having duplicate bug reporting systems is a problem that we have
to live with. As a library compiler for Axiom I think it is necessary
that we categorize Axiom-related Aldor bugs here.
> Axiom Mathematics [28]
>
> most of the issues in this category should be moved to Axiom Library,
> some to the Axiom Interpreter. I guess the original intention was to
> provide a place to discuss problems of design, rather than programming
> (like, for example, semantics of 'Fraction Fraction R' or 'Complex PF 5').
> I propose to delete this category, since it seems to confuse many users.
>
You are right. There are other pages on the wiki where more general
issues like this can be discussed.
> general [4]
>
> Quite superfluous.
Agreed.
> Such issues can be sent to the mailing list, with a higher chance of
> being resolved.
>
> Axiom Programming [1]
> Axiom Foundation [0]
> Donations [0]
> Bounties [0]
I think these can be deleted.
> New feature request [3]
>
> easily reclassified.
>
I can imagine some good reasons why we should continue to classify
some reports as "feature requests".
Regards,
Bill Page.
Martin Rubey
thanks for your detailed answer. Here a summary of the points where action is
still unclear:
"Bill Page" <bill...@newsynthesis.org> writes:
> > I'm not so sure what to do with:
> >
> > Axiom on Windows
> > Axiom on Linux
> > Axiom on MacOSX
>
> These also would seem to interact with the new "Axiom Version" field. Right
> now that field also affects work version of Axiom is run to create the output
> on the page (if any). Maybe that was not a good idea since I think it would
> be convenient to be able to enter "Windows and MacOSX" here but right now
> there is no way to run these versions on the mathaction (sage.math) server
> which is a linux system.
I don't think this is necessary. In any case, there are more important things
to do...
> In principle this should be possible through a remote or virtual machine but
> it might be a bit challenging.
> > There are indeed problems particular to MS Windows or Linux or MacOSX, but
> > often these are related to the build process. On the other hand, build
> > troubles are often common to all platforms... The problem I have is that
> > sometimes submitters put bugs into Axiom on Windows even though it's really
> > a problem with the Algebra code.
>
> I agree that as "categories" they do not make much sense.
>
> > I guess, the best thing is to keep it for now.
>
> I am not sure. But Having two fields in the issue report such as 1)
> "affects what Axiom Version ..." and 2) "execute examples using Axiom
> Version ..." seems confusing to me. Any other ideas?
Encourage submitters to state what version they use. I'm not expecting too
many bug reports from anonymous users this year, and I'm (almost) in the
position now to check bugs also on MS Windows, so I can do it unless it is a
bug within the build process. The latter is simply too much of an effort for
me.
Maybe we should rename: "building axiom from source" to "building and
installing axiom" and delete "Axiom on Windows" and "Axiom on Linux"?
> > Doyen CD
> >
> > this could possibly be merged with Axiom User Interface
> >
>
> I think it should remain separate.
OK.
> > All other categories should be deleted. Reasons:
> >
> > Aldor Library Compiler [6]
> > Aldor Standalone Compiler [2]
> >
> > Aldor has its own bug-tracking system, and as long as Aldor
> > is non-free, we cannot merge the bug databases.
> >
>
> I do not see the license status as a problem with respect to reporting
> bugs. Having duplicate bug reporting systems is a problem that we have to
> live with. As a library compiler for Axiom I think it is necessary that we
> categorize Axiom-related Aldor bugs here.
Well, that is what the new category 'Axiom-Aldor Interaction' is intended for.
Can you suggest a better name?
> > New feature request [3]
> >
> > easily reclassified.
> >
>
> I can imagine some good reasons why we should continue to classify some
> reports as "feature requests".
I do not understand that? For every category we have a status "WishList". If
there is a feature request that does not fit into any of the categories, I
guess we should revise them.
Martin
Martin Rubey
Martin Rubey <martin...@univie.ac.at> writes:
> Thus, I ask you to comment. I'll wait a week or so (unless I get only
> encouraging comments), if I do not get any comments until then, I'll just go
> ahead. Meanwhile I'll only reclassify.
In a wave of madness I did all the changes, no longer waiting for comments.
I'll try to handle complaints as well as I can, please bear with me.
Find below a list of issues where I have no idea of the proper status. Often
the main problem is that I do not understand what the bug is.
I'm going to sleep now...
> Happy new year,
>
> Martin
110, 226, 378, 107, 112, 136, 302, 39, 17, 187, 228
Waldek, Gaby: is 370 fixed in FriCAS, open-axiom? (I do not even know what the
bug is.
Waldek Hebisch
> Martin Rubey <martin...@univie.ac.at> writes:
>
> > Thus, I ask you to comment. I'll wait a week or so (unless I get only
> > encouraging comments), if I do not get any comments until then, I'll just go
> > ahead. Meanwhile I'll only reclassify.
>
> In a wave of madness I did all the changes, no longer waiting for comments.
> I'll try to handle complaints as well as I can, please bear with me.
>
> Find below a list of issues where I have no idea of the proper status. Often
> the main problem is that I do not understand what the bug is.
>
> I'm going to sleep now...
>
> > Happy new year,
> >
> > Martin
>
>
> 110, 226, 378, 107, 112, 136, 302, 39, 17, 187, 228
>
I took a look at 110 and I think that this is not a bug report -- in
this case IssueTracker is just used as a discussion forum. I would
just remove such pages from IssueTracker (and put them somewhere
else in the wiki).
> Waldek, Gaby: is 370 fixed in FriCAS, open-axiom? (I do not even know what the
> bug is.
>
Bug is that in:
select_!(keeprec?(i.halfinf.endpoint, #1), l)
Axiom used to treat 'halfpoint' and 'endpoint' as variable names.
FriCAS contains a patch by Steve Wilson to correct this problem.
--
Waldek Hebisch
heb...@math.uni.wroc.pl
Martin Rubey
> Martin Rubey wrote:
> > Find below a list of issues where I have no idea of the proper status. Often
> > the main problem is that I do not understand what the bug is.
> > 110, 226, 378, 107, 112, 136, 302, 39, 17, 187, 228
here is another one: 51
>
> I took a look at 110 and I think that this is not a bug report -- in
> this case IssueTracker is just used as a discussion forum. I would
> just remove such pages from IssueTracker (and put them somewhere
> else in the wiki).
Thanks. I closed the Issue and moved the contents to a new page,
SymbolsAndVariables.
> > Waldek, Gaby: is 370 fixed in FriCAS, open-axiom? (I do not even know what the
> > bug is.
> FriCAS contains a patch by Steve Wilson to correct this problem.
OK, I added an appropriate message.
There remain 182 open bugs.
Axiom Aldor Interface: 2
Axiom Compiler: 12
Axiom Library: 66
Axiom Interpreter: 31
Axiom User Interface: 20
Axiom Documentation: 8
Axiom on Linux: 10, I think these are all non-problems in FriCAS
and Open-Axiom
Axiom on Windows: 7, ditto
building Axiom from Source: 13, ditto
DoyenCD: 3, ditto
MathAction: 7, ditto
lisp system: 2, ditto
IMPORTANT NOTE: I did not put "fix proposed" statuses on bugs where the report
indicates - possibly implicitly - that only a certain version of axiom is
affected.
For me personally, the bad bugs are mostly in "Axiom Library". Some recurrent
topics are, I believe:
* integration (346, 318, 360)
(a workaround for the ones about special functions could be to implement gfun
as proposed on the WishList)
* problems with the EXPR domain resulting from the fact that we do not have
assumptions (or provisos, if you like).
* possibly related to the above two: problems with branch cuts of atan, asin,
etc. (141, 138)
* factorisation problems (354, 269, 290, 254, 253)
* problems with limit computations. This could be fixed by implementing
Gruntz.
* problems with solve, which is really not very clever...
The other very bad bugs (for me, again), are with respect to aldor and the spad
language:
* I still do not have an aldor interface with fricas
* Axiom still doesn't understand dependent types
* Axiom still doesn't understand aldor extend
* SPAD cannot deal with conditional exports dependending on functions (354)
I'm very very curious to see what 2008 will bring! All the best,
Martin
Waldek Hebisch
>
> > > Find below a list of issues where I have no idea of the proper status. Often
> > > the main problem is that I do not understand what the bug is.
>
> > > 110, 226, 378, 107, 112, 136, 302, 39, 17, 187, 228
>
> here is another one: 51
I belive that I have eliminated all duplicate definitions at Spad
level. Currently we still get duplicate functions in Lisp output
in RPOLCAT-. I consider this a bug in Spad compiler. Since
redefinition is identical to the first copy impact is minor
so I prefer to keep .spad file as-is an wait for compiler fix.
--
Waldek Hebisch
heb...@math.uni.wroc.pl