[Maxima] Function returning the version number
wilhelm.haager at htlstp.ac.at
Mon Jan 30 09:55:15 CST 2012
On Sat, 28 Jan 2012 13:05:01 -0700, Robert Dodier
<robert.dodier at gmail.com> wrote:
> I think that making a program dependent on the Maxima version
> number generally indicates that something has gone wrong;
> I would avoid it if possible.
> That said, I have a patch laying around to rework build_info
> so that it returns a Maxima structure (as defined by defstruct)
> which makes it easy to extract the bits of the build info.
> With this patch I get:
> (%i2) x : build_info ();
> Maxima version: 5.26.0_16_gb72c64c_dirty
> Maxima build date: 2012-01-11 00:01:25
> Host type: i686-pc-linux-gnu
> Lisp implementation type: CMU Common Lisp
> Lisp implementation version: CVS release-19a 19a-release-20040728 +
> minimal debian patches
> (%i3) x at version;
> (%o3) 5.26.0_16_gb72c64c_dirty
> (%i4) x at timestamp;
> (%o4) 2012-01-11 00:01:25
> (%i5) x at host;
> (%o5) i686-pc-linux-gnu
> (%i6) x at lisp_name;
> (%o6) CMU Common Lisp
> (%i7) x at lisp_version;
> (%o7) CVS release-19a 19a-release-20040728 + minimal debian patches
> Note that the patch includes a display function so that the
> return value of build_info is displayed just as build_info now
> displays the build info.
> I'll commit this unless someone thinks it's a bad idea.
> Robert Dodier
Thank you very much for your answer.
On principle, it is favourable to avoid version-dependencies in
But some optional parameters of the package "draw" have changed
recently (I think from the
Maxima version 5.22 to 5.23), eg. the options "pic_width" and
"pic_height" have changed to "dimensions".
When a package makes use of those options (as the control engineering
package COMA does),
the version dependent treatment seems useful.
The actual Maxima version included in Ubuntu is still version 5.20, in
Windows we have 5.25;
it's convenient to maintain only one package for all versions.
More information about the Maxima