#7377: Symbolic Ring to Maxima via EclObject
-----------------------------------------------------------------------+----
Reporter: nbruin |
Owner: nbruin
Type: enhancement |
Status: needs_review
Priority: major |
Milestone: sage-feature
Component: symbolics |
Keywords:
Author: Nils Bruin, Jean-Pierre Flori |
Upstream: N/A
Reviewer: Jean-Pierre Flori, François Bissey, Karl-Dieter Crisman |
Merged:
Work_issues: |
-----------------------------------------------------------------------+----
Changes (by kcrisman):
* status: needs_work => needs_review
Old description:
> With maxima-as-an-ecl-library and ecl accessible as a library, we can
> start interfacing with maxima via a binary library interface. This should
> be more efficient and more robust, because expressions can be transmitted
> in a much richer format than text and parsing does not have to recognise
> error messages and questions (since communication does not go via
> STDIN/STDOUT anymore).
>
> Applies cleanly to 4.6.2.
>
> This ticket is dependent on #10766, #10773, #10743. Ticket #10818 is
> desirable but not essential. Apply:
>
> {{{
> trac_7377-abstract-maxima_p2.patch
> trac_7377-maximalib_p2.patch
> trac_7377-fastcalculus_p2.patch
> trac_7377-better-ask-error_p2.patch
> trac_7377-split_and_refactor-p2.patch
> trac_7377-lazy-maxlib.p2.patch
> trac_7377-floatcast.patch
> trac_7377-unicode_to_ecl-p1.patch
> trac_7377-assumptions-p1.patch
> trac_7377-doctests.patch
> }}}
> * attachment:trac_7377-abstract-maxima_p2.patch
> * attachment:trac_7377-maximalib_p2.patch
> * attachment:trac_7377-fastcalculus_p2.patch
> * attachment:trac_7377-better-ask-error_p2.patch
> * attachment:trac_7377-split_and_refactor-p2.patch
> * attachment:trac_7377-lazy-maxlib.p2.patch
> * attachment:trac_7377-floatcast.patch
> * attachment:trac_7377-unicode_to_ecl-p1.patch
> * attachment:trac_7377-assumptions-p1.patch
> * attachment:trac_7377-doctests.patch
New description:
With maxima-as-an-ecl-library and ecl accessible as a library, we can
start interfacing with maxima via a binary library interface. This should
be more efficient and more robust, because expressions can be transmitted
in a much richer format than text and parsing does not have to recognise
error messages and questions (since communication does not go via
STDIN/STDOUT anymore).
Applies cleanly to 4.6.2.
This ticket is dependent on #10766, #10773, #10743. Ticket #10818 is
desirable but not essential. Apply:
{{{
trac_7377-abstract-maxima_p2.patch
trac_7377-maximalib_p2.patch
trac_7377-fastcalculus_p2.patch
trac_7377-better-ask-error_p2.patch
trac_7377-split_and_refactor-p2.patch
trac_7377-lazy-maxlib.p2.patch
trac_7377-floatcast.patch
trac_7377-unicode_to_ecl-p1.patch
trac_7377-assumptions-p2.patch
trac_7377-doctests.patch
}}}
* attachment:trac_7377-abstract-maxima_p2.patch
* attachment:trac_7377-maximalib_p2.patch
* attachment:trac_7377-fastcalculus_p2.patch
* attachment:trac_7377-better-ask-error_p2.patch
* attachment:trac_7377-split_and_refactor-p2.patch
* attachment:trac_7377-lazy-maxlib.p2.patch
* attachment:trac_7377-floatcast.patch
* attachment:trac_7377-unicode_to_ecl-p1.patch
* attachment:trac_7377-assumptions-p2.patch
* attachment:trac_7377-doctests.patch
--
Comment:
Sorry I do not have time to check this properly today. Do you get the
{{{
ERROR: An unexpected error occurred while tokenizing input
The following traceback may be corrupted or invalid
}}}
problem with these patches? I hope not :)
A couple very small points about the doctests patch, which by the way is
nontrivial and nice all by itself.
* You should have a `loads(dumps(foo))==foo` test if possible for class
definitions. I think there are eight of these?
* You probably don't need to put `INPUT` and/or `OUTPUT` blocks if there
isn't one or it's essentially stated in the first line of the
documentation - I'm thinking of `_false_symbol` or `version`. Up to you,
of course, since you already did it.
* In a few places where you have more than 'really basic and stupid'
documentation (you sell yourself short! it's not bad at all) you have some
lines that aren't going to work. Ones like
{{{
- ``use_disk_cache`` - boolean (default: True); if set to True, try to
read cached result from disk
}}}
are too long, and should be made into two lines like you did for
{{{
- ``eqns`` - a list of m strings; each representing a linear
question in m = n variables
}}}
However, these will cause a problem in Sphinx, I think, unless you
reformat them like so
{{{
- ``eqns`` - a list of m strings; each representing a linear
question in m = n variables
}}}
This won't show up well on Trac, but notice that the 'q' in 'question' is
lined up with the first '`' in '``eqns``'. This was correctly done for
'pts_list', for example.
It looks like the `zunderflow zz` was fixed as well, and assuming that fix
passes tests as well, I think it can be 'needs review'.
In fact, as long as everyone involved is not reviewing their own patch,
this can even be 'positive review'. For instance, I will assume that JP
slightly changing my reviewer patch indicates no problems with it.
Can anyone say what would still need to be done for positive review, other
than passing all long doctests, which I can't check right now, and taking
care of the things above which will lead to Sphinx errors?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/7377#comment:116>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
