Ralf Hemmecke wrote:
>
> > Probably 'checkDecorate' in 'c-doc.boot'. Apparently it knows
> > about '\spad' but not about '\spadfun'.
>
> Thank you.
>
> I've not yet checked in detail, but the existence of
> "checkDecorateForHt" makes me believe that there would be one routine
> for TeX and another for HyperDoc, i.e. generating the .ht stuff from the
> docstrings.
>
> But on the other hand that must be wrong, since in my first mail I
> showed that I got the wrong string from GETDATABASE (so it is stored
> there). But that might mean that docstring --> .ht does not go via
> GETDATABASE.
>
> That confuses me a bit.
>
> Waldek, I'm not saying that you should look up the call graph, but maybe
> you already know from the top of your head how the flow of information is.
Well, scanner ('scan.boot') puts documentation on global list
'$COMBLOCKLIST'. Parser ('s-parser.boot') annotates parse
tree with references to documentation. At the end of compilation
functions from 'c-doc.boot' massage documentation and put
it in 'index.KAF' file in appropriate .NRLIB. During
database build 'index.KAF'-s are read and collected into
database.
IIRC HyperDoc gets documentation from values in memory, which
typically come from databases, but also may come from recent
compilation. In both cases effect is supposed to be equvalent,
simply you should get most recent documentation. In partucular
'compDefineLisplib' loads information from freshly compiled
.NRLIB as if it came from database. Main documentation
processing is done in 'finalizeDocumentation' called from
'finalizeLisplib'.
> I actually would like that from GETDATABASE I get exatly the docstring
> (even with its line breaks). I'd like to do all the transformations
> myself (in other words lift the related code from .boot to .spad).
AFAICS the idea is to perform several checks of documentation
at end of compilation. So you get diagnostics about problems
with documentation. Transformations are done simulanously with
checking -- this makes sense because otherwise transformation
code and checking code could easily get out of sync.
Concerning Spad versus Boot: as I wrote long term plan is
to have compiler writen is Spad. ATM some parts have versions
in Spad (I have Spad version of the parser and Krystian's
typechecker is in Spad). My estimates about developement
time freqently are wrong, but I hope that in say one year
horizon compiler will switch to beeing mostly Spad.
Let me add that that to include Spad parts in repository
we need to work out bootstrap problem. It will take
some work but I think I know what to do. However,
before working on bootstrap I want to have several
components in Spad. Such components can be tested
by loading them into already build FriCAS.
--
Waldek Hebisch
[email protected]
--
You received this message because you are subscribed to the Google Groups
"FriCAS - computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
