>From mailnull Mon Mar 25 10:42:58 2013
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of math.utexas.edu designates 146.6.25.6 as permitted sender) client-ip=146.6.25.6; envelope-from=maxima-bounces at math.utexas.edu; helo=irongate.mail.utexas.edu;
From: Rupert Swarbrick <rswarbrick at gmail.com>
Date: Mon, 25 Mar 2013 10:41:35 +0000
CC: <maxima at math.utexas.edu>
Content-Type: multipart/mixed;
boundary="===============2895714127666894247=="
--===============2895714127666894247==
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1;
protocol="application/pgp-signature"
--=-=-=
Content-Type: text/plain
<nb0yjxtr at ma.sdf.org> writes:
> Rupert, I did some work on this a while ago; the work is in my github
> repo. I had the code to a point where it worked correctly for the
> languages in the info directories and all the lisps I had access to
> (sbcl, cmucl, ecl, gcl, clisp). The speed-up was great--even clisp was
> faster than the perl script by a noticeable amount. Also, I used an eq
> hash so you could pull in multiple docs that covered the same subject.
The eq hash is a neat idea - I'll have a look. The speed-up is already
pretty good: on my branch we're talking 0.7 seconds on the crappiest
implementation as opposed to 10 seconds with Perl.
> I would suggest a few things:
>
> 1. make it an option to build maxima-index.lisp at build time, the
> cost is minimal when doing it in lisp, and it is pretty painless to
> write a function to dump the info hash;
I *really* don't want to do this. Basically, the offsets we store would
be bogus when using multiple implementations in the presence of
unicode. It was wrong with the perl script and I'd rather not have it
wrong here. I agree that it's easy - in fact the first patch on the
branch does this!
What I would suggest is to dump the info hash for each lisp you are
building with and use read-time conditionals to load the right one
into a Maxima session. Even with 4-5 lisps, this will still be faster
than the perl script, and you will get the right offsets for each lisp.
Although you may think everyone is running fast hardware, Maxima is
being ported to run on low-spec hardware like phones where it may not
be so nice to wait while Maxima regenerates an info hash that could
have been done once at build time.
> 2. make a user-level function available to pull in more info files
> than just those supplied in the installation;
That seems like a sensible thing to do. Maybe something like this?
register_info_file (path);
Tries to read in the info file at PATH and add it to the documentation
system. On success, returns the number of topics added.
With the work Robert did on multiple locations, that'd probably be a
sub-50-line patch.
> 3. make it optional to use the perl script during the build process.
Bleurgh. We should have one way to do it. Otherwise we'll have weird
bugs with one build system and not with the other.
Well, I think you are being over-literal. Once you build the info hash
inside a lisp, you have N different ways of building the hash, etc.
You create all sorts of weird bugs moving from one lisp to another, etc.
Leo