Replacing HyperDoc

[Waldek Hebisch]

I am looking at replacing HyperDoc code in Boot by Spad code.
You can ask why bother? Do not Ralf API code cover all? Well,
HyperDoc provides _much_ more functionality. Namely,
HyperDoc provides several views, with possibility of filtering.
Basic view, that is constructors allows selecting categories,
domains or packages (or all). One gets list of operations
in one of several forms:
- names
- signatures
- descriptions
- parameters
- conditions
- origins
- implementations
One can look at exports, ancestors, etc.

Having API on the web is very good, but trying API it I must say
that for me it is much less usable than current HyperDoc.
Simply current API lacks many features. Any single feature
of HyperDoc may look not very important, but there are several
features and together they make a difference. So, we should
look at adding new features, not at removing them.

Technically, HyperDoc functionality requires code to compute
relevant info (signature lists, constructor lists) and presentation
code. Of course presentation code must take into accout medium.
So we need different presentation code for Html (API and potential
use via browser), current HyperDoc and text (system commands).
But most complicated part of work is computation of relevant
information. Currently system commands reuse part of HyperDoc
code but do part of work in their own way. HyperDoc computes
info in several different ways, it is not clear to me if all
this variation is needed. API has its own way to compute
constructor info. api2.spad that I did reuses computation
of info from API, but has different presentation layer.

As I wrote I have part of HyperDoc code in Spad. HyperDoc
page has the following representation:

Rep := Record(name : Symbol, domain_conditions : LSE,
variable_alist : ALS, pattern_vars : List(PSR),
radio_buttons : ALS, input_areas : ALS,
property_list : ALS, page_description : LSE,
work_area : List(String))

where ALS is List(Record(key : Symbol, entry : SExpression)),\
LSE is just list of S-expressions and PSR is list of
Record(var : Symbol, pvar : Symbol).

This representation actually is representation used by Boot code,
so that Spad code can cooperate reasonably well with Boot code.

Each HyperDoc page has an associated symbol, and content of the
page is stored in value slot of the symbol. When C code sends
request to FRICASsys, this request is in form of S-expression
that is evaluated by FRICASsys. One of arguments is name of
symbol associated to the page, so evaluation gets value of
the symbol and in this way HyperDoc functions know which page
to handle. The record above is in a way unbalenced, general
info is stored in property list and page description, while
other fields have more special use. But this way, that is
symbol per page and page data in a record is reasonable
(alternatively, we can store pages in a hash table, currently
use of symbols avoids use of hash table).

Currently page description is a mixture of higher level symbolic
data (which in principle could be presented in any sufficiently
expressive format) and literal HyperDoc data. Of course literal
data means that just now this is good only for HyperDoc.

My code handles just HyperDoc page data and communiation to C
code. Next stage is to generate content of pages, in particular
to generate needed info. I would like to reuse Ralf code for
this, but I am not sure if this will be possible: Ralf uses
data structures (in particular XHashTable) which are problematic
to access from Boot. I would like to do things in incremental
way, so just now I need data structures that allow easy cooperation
with Boot code.

Extra remarks: my goal is to allow dynamic interface either using
current C code or a web browser (depending on user choice).
Command line interface can not support hyperlinks, but I think
that most info should be also available via command line.
At logical level most HyperDoc constructs can be
represented in Html. HyperDoc uses just a handful of rendering
constructs, AFAICS this is small subset of what Html can do.
HyperDoc has allows control if new page replaces existing one,
or if it is open in a new window. I am not sure if this can
be represented in pure Html, but certainly can be done using
some extra Javascript. C side of HyperDoc sends explicit commands
to destroy pages, we can not expect web browser to do this,
but I do not think this is a big problem.

--
Waldek Hebisch

[Ralf Hemmecke]

Hi Waldek,

as you know, I would like to let HyperDoc die.
But, maybe that sound too extreme for what I actually mean.
And I agree to some extend to your plan for a new hyperdoc.

Let me explain my wishes.

FriCAS should have an interface (in LISP or SPAD) that let's
SPAD or external programs get information about
categories/domains/packages/documentation.
From such an interface it should be easy to generate any output format
be it html, rst or pdf.

I think this can be started without changing any code for hyperdoc.
Such an interface should already contain code to compute a datastructure
representing the data for a page (not actually rendered in any format),
in particular, conditional exports should be computed and the
datastructure should have enough information to produce links to other data.

Yes, that is good for a getting a "static" view of a constructor similar
to what is presented at fricas.io/api, but computable on-the-fly.

You also want such a view in a "dynamic" form, i.e. (similar to what
current hyperdoc provides) getting information about
- usage of domains
- fuction implementation (in which package/domain)
- etc.

Shouldn't it be possible to create an API that let's query such
information by just sending strings to specify the arguments?

Why would that need Boot code if there is a function that translates the
string "Polynomial Integer" into the respective domain and uses that in
querying the various places where the wanted information is stored in
FriCAS?

Whether you then program in interface to present such information, is
another business. I wouldn't do that but rather rely on ordinary
webbrowsers to display such information. One can probably extent jfricas
to start queries and have examples executed in a notebook interface.

Yes, I like to be able to get more information out of FriCAS than just a
static API page (although I think that having them static on the web is
still a good idea). What I am not in favour of is the current HyperDoc
window. That looks old and not very attractive. That should die. Not the
information it shows, of course.

At the same time, I would like to put the HyperTeX format to sleep.
This format was interesting 30 years ago, but now there are better
formats like rst of markdown or ... Why should we keep our specific
HyperTeX-Format that nobody outside FriCAS cares about?

I do not know whether my code is good to be adapted, because initially,
I only had the presentation into an .rst page in my mind. I think one
should carefully separate code that "provides" information from code
that translates that into a certain format.

Can we create a new branch and work (as a first step) at an interface
that provides all the necessary information in form of SExpression?

> As I wrote I have part of HyperDoc code in Spad. HyperDoc
> page has the following representation:
>
> Rep := Record(name : Symbol, domain_conditions : LSE,
> variable_alist : ALS, pattern_vars : List(PSR),
> radio_buttons : ALS, input_areas : ALS,
> property_list : ALS, page_description : LSE,
> work_area : List(String))

That is seemingly taylored for a hyperdoc page. Why should one have
radio_buttons in an information record? I would rather have several data
structures like

FUN ==> Record(
name: Symbol,
source: SEX,
target: SEX,
doc: String,
condition: SEX)

CAT ==> Record(
name: Symbol,
args: List SEX,
cats: List Record(cat: CAT, condition: SEX)
funs: List FUN)

etc. (Don't take that too serious. It's just a draft.)

Anyhow, we should come up with a good datastructure that provide
easy access to the information.

If you want a datastructure that is just representing the current
hyperdoc structure, I am not interested. That is too much presentation
oriented already.

> this, but I am not sure if this will be possible: Ralf uses
> data structures (in particular XHashTable) which are problematic
> to access from Boot.

There is nothing specific about XHashTable. Any hash structure will do.
Use an association list, if you like.

> Extra remarks: my goal is to allow dynamic interface either using
> current C code or a web browser (depending on user choice).

As I said, I would rather like a generic interface to all the
information, separated from code that does the presentation.

Just my two cents...
Ralf

[Peter Broadbery]

Hi,

I started on something similar to replacing Hyperdoc a while ago - in
the context of an unfinished Aldor/Fricas IDE. The main idea is that
Spad types held in daase files should be representable as Aldor
objects, and from those one can do all the querying needed to generate
HTML. Overall, it worked reasonably well.
The next hard part would be integrating with a web service..

Code is here: https://github.com/pbroadbery/fricas-aldor-types - It
won't work in Fricas at the moment (due to non-essential java
dependencies), but might contain some ideas.

I will see if it can be tweaked into something that additionally works
with the Fricas runtime.

Peter

> --
> 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 fricas-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/1483f2d5-22a4-45a9-8f08-d9e182b8cf5c%40hemmecke.org.

[Tim Daly]

The function showdatabase might be useful. -- Tim

[Tim Daly]

There was prior work with Dick Jenks, Jim Griesmer, etc but the Scratchpad

effort was later. James Davenport or Barry Trager might have the required historical 

knowledge.

 

Given the early time frame this could possibly support the Fortran rumor.

My understanding is that the initial Scratchpad syntax effort was in Meta.

Tim

[Grégory Vanuxem]

Hello,


Le mer. 11 juin 2025 à 20:59, 'Ralf Hemmecke' via FriCAS - computer
algebra system <fricas...@googlegroups.com> a écrit :

>
> Hi Waldek,
>
> as you know, I would like to let HyperDoc die.
> But, maybe that sound too extreme for what I actually mean.
> And I agree to some extend to your plan for a new hyperdoc.
>
> Let me explain my wishes.
>
> FriCAS should have an interface (in LISP or SPAD) that let's
> SPAD or external programs get information about
> categories/domains/packages/documentation.
> From such an interface it should be easy to generate any output format
> be it html, rst or pdf.

+1

For what I am interested in right now, is displaying '++'
documentation in text form, and. readable directly in the interpreter
console.
From what I have read in api.spad and api2.spad the implementations
are tightly related the reST and HTML formats and I would like
plain/text format also. I do not want to use a Regex style replacement
method as it requires Julia or cl-ppcre and/or, for my concern,
cl-ppcre-unicode. Looking at api2 for example there is code to return
TexTree as a SEX expression. There is a TeXTree to HTML converter
which outputs the conversion in a file, no routine from what I have
seen that converts it to a String. I will eventually code something in
this regard. Maybe Waldek, you have already done this privately?
Having a generic parser would be a very good idea, I think. Gathering
the two parser implementations.


jlDocumentation(op) ==
ops := getDatabase("o")$OperationsQuery
docs := elt(ops,equation('name, op)$QueryEquation)
elts : DataList(String) := elt(docs,'doc)
for i in 1 .. #elts repeat
output((elts.i)::OutputForm)$OutputPackage
-- PPRINT(jlEvalString(concat(["replace(raw_"",

"\spad{svd(m)} computes the singular value decomposition \spad{SVD} of \spad{
m} such that \spad{SVD}.\spad{U} * diagonalMatrix(\spad{sv}) * \spad{SVD}.\sp
ad{Vt} = \spad{m}."
"\spad{svd(m)} computes the singular value decomposition \spad{SVD} of \spad{
m} such that \spad{SVD}.\spad{U} * diagonalMatrix(\spad{sv}) * \spad{SVD}.\sp
ad{Vt} = \spad{m}."
"\spad{svd(m)} computes the singular value decomposition \spad{SVD} of \spad{
m} such that \spad{SVD}.\spad{U} * diagonalMatrix(\spad{sv}) * \spad{SVD}.\sp
ad{Vt} = \spad{m}."
"\spad{svd(m)} computes the singular value decomposition \spad{SVD} of \spad{
m} such that \spad{SVD}.\spad{U} * diagonalMatrix(\spad{sv}) * \spad{SVD}.\sp
ad{Vt} = \spad{m}."
"\spad{svd(m)} computes the singular value decomposition of the matrix \spad{
m}."
Type: Void

And regexing/replacing, completely irrelevant for me, some Tex-like
construct I would like to obtain something like:
(25) -> jlDocumentation "svd"

"svd(m) computes the singular value decomposition SVD of m such that
SVD.U * diagonalMatrix(sv) * SVD.Vt = m."
"svd(m) computes the singular value decomposition SVD of m such that
SVD.U * diagonalMatrix(sv) * SVD.Vt = m."
"svd(m) computes the singular value decomposition SVD of m such that
SVD.U * diagonalMatrix(sv) * SVD.Vt = m."
"svd(m) computes the singular value decomposition SVD of m such that
SVD.U * diagonalMatrix(sv) * SVD.Vt = m."
"svd(m) computes the singular value decomposition of the matrix m."
Type:
Void

or:

(26) -> jlDocumentation "string"

"string(f) gives string corresponding to f. Valid only when string?(f) is true"
"string(i) returns the decimal representation of i as a string."
"string(s) returns s as an element of Str. Error: if s is not an atom
that also belongs to Str."
"string(jt) returns the string representation of jt."
"string(x) stringifies x."
"string(s) converts the symbol s to a string. Error: if the symbol is
subscripted."

(27) -> jlDocumentation "str"
Type: Void

But with more information (conditional exports, origins etc.) and
more options. Probably as a system command?
)display doc string as an example.

Just my two cents.

- Greg

[Tim Daly]

Within algebra documentation for a function there are ++ and -- comments

The ++ comments are intended as documentation.

I have extended the meaning of ++ comments by appending a single letter.

For example in the 'map' function from 'StreamFunction3' you'll see

    map : ((A,B) -> C,ST A,ST B) -> ST C
      ++ map(f,st1,st2) returns the stream whose elements are the
      ++ function f applied to the corresponding elements of st1 and st2.
      ++ \spad{map(f,[x0,x1,x2,..],[y0,y1,y2,..]) = [f(x0,y0),f(x1,y1),..]}.
      ++
      ++S
      ++X m:=[i for i in 1..]::Stream(Integer)
      ++X n:=[i for i in 1..]::Stream(Integer)
      ++X f(i:Integer,j:Integer):Integer == i+j
      ++X map(f,m,n)

The ++X comments are part of the output shown during display functions, e.g.

)d op map

will show the ++X comments as "examples" of how to use the function.

There is also the 'ApplicationProgramInterface' which allows user-level access

to various data structures:

)abbrev package API ApplicationProgramInterface
++ Author: Timothy Daly, Martin Rubey
++ Date Created: 3 March 2009
++ Date Last Updated: 24 March 2012
++ Description:
++ This package contains useful functions that expose Axiom system internals

ApplicationProgramInterface() : SIG == CODE where

  SIG ==> with

    getDomains : Symbol -> Set Symbol
      ++ getDomains(s) takes a category and returns the list of domains
      ++ that have that category
      ++
      ++X getDomains 'IndexedAggregate

    getAncestors : Symbol -> Set Symbol
      ++ getAncestors(s) takes a category and returns the list of domains
      ++ that have that category as ancestors
      ++
      ++X getAncestors 'IndexedAggregate

    credits : () -> Void
      ++ credits() prints a list of people who contributed to Axiom
      ++
      ++X credits()

    summary : () -> Void
      ++ summary() prints a short list of useful console commands
      ++
      ++X summary()

    reportInstantiations : Boolean -> Void
      ++ reportInstantiations(bool) is a debugging tool to show
      ++ instantiation information
      ++
      ++X reportInstantiations(true)
      ++X 1
      ++X reportInstantiations(false)

  CODE ==> add

    getDomains(cat:Symbol):Set(Symbol) ==
      set [symbol car first destruct a _
        for a in (destruct domainsOf(cat,NIL$Lisp)$Lisp)::List(SExpression)]

    getAncestors(cat:Symbol):Set(Symbol) ==
      set [symbol car first destruct a _
        for a in (destruct ancestorsOf(cat,NIL$Lisp)$Lisp)::List(SExpression)]

    credits() == ( credits()$Lisp ; void() )

    summary() == ( summary()$Lisp ; void() )

    reportInstantiations(b:Boolean): Void ==
      REPORTINSTANTIATIONS(b)$Lisp
      void

--
You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/mb_O0196RMQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dY5SH52A0U56a8kSqSBO%2BFX0Lzsq%3Dw6hzBCfcuBd20m8Q%40mail.gmail.com.

[Tim Daly]

Taking the idea from Ralf it seems that there could be a "hyperdoc" domain

that implements all of the functions necessary to create user documentation

with both text output and HTML output forms. From that domain it should

be possible to re-create Hyperdoc in a browser.

[Grégory Vanuxem]

I have deleted my mails, sorry. But something like:

7) -> jlDocumentation mod <TAB> <TAB>
modTree modifyPointData modularFactor
modularLambda moduleSum
mod_exp modpeval modularGcdPrimitive
modular_compose moduloP
modifyPoint modpreduction modularInvariantJ module
modulus

(7) -> jlDocumentation moduleSum

moduleSum(m1, m2) returns the sum of two modules in the framed
algebra F. Each module mi is represented as fol
lows: F is a framed algebra with R-module basis w1, w2, ..., wn and
mi is a record [basis, basisDen, basisInv]
. If basis is the matrix (aij, i = 1..n, j = 1..n), then a basis v1,
..., vn for mi is given by vi = (1/basisD
en) * sum(aij * wj, j = 1..n), i.e. the ith row of 'basis' contains
the coordinates of the ith basis vector. S
imilarly, the ith row of the matrix basisInv contains the
coordinates of wi with respect to the basis v1, ...,
vn: if basisInv is the matrix (bij, i = 1..n, j = 1..n), then wi =
sum(bij * vj, j = 1..n). From: IntegralBas
isTools



Type: Void
(7) -> jlDocumentation mod <TAB><TAB>
modTree modifyPointData modularFactor
modularLambda moduleSum
mod_exp modpeval modularGcdPrimitive
modular_compose moduloP
modifyPoint modpreduction modularInvariantJ module
modulus
(7) -> jlDocumentation modpreduction


modpreduction(r, p) reduces a rational function r modulo prime p.
From: PolynomialEvaluationUtilities


modpreduction(p, q) reduces all coefficients of p modulo q. From:
ModularEvaluationCategory


modpreduction(pol, p) reduces polynomial pol modulo prime p. From:
PolynomialEvaluationUtilities



Type: Void

That uses a regular expressions system, sorry, strings are very bad
handled in panAxiom. But just that's would be very handy.

BTW: Timothy, your 'X' is already implemented in HyperTex with:

++ For example, using JLMatrix(JLObjFloat64):
++ \example{M:=nrand(4,4);}
++ \example{jlApply("svd", M::JLMatrix(JLObjFloat64)).S}
++ should be "equivalent" to svdvals(M)

Maybe I do not understand your 'X'.

BTW2: All my reconnaissance, of course, Tim.

Cheers,

Greg

> 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 fricas-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/d2b4d3a4-ce9e-4483-9d10-83f4add78e06n%40googlegroups.com.

[Tim Daly]

Greg,

I used the ++(letter) and --(letter) form for various things.

++X is used for algebra examples as shown above

These lines are output from )d op foo showing the user how to construct valid

input to the function foo. This is useful because it is hard to guess how to

contruct input of the required type. Since there are many functions with the same

name there will be many examples, each associated with one function.

In input files (src/input) they are decorated with

--S n of m       which gives the number of the test, e.g. 5 of 23 indicating starting a new test

--R                  which gives the expected result (usually many --R lines)

--I                    which tells the test comparison to ignore that line (e.g. when gensyms occur)

--E n                which ends the test n

This allows the test to run ignoring the --(number) decoration and output the result. 

Then a program runs over the output (which includes the -- comments) and

does a text comparison of the expected result --R with the actual result.  For example

-- factorization of polynomials over finite fields
--S 5 of 21
u:UP(x,PF(19)) :=3*x^4+2*x^2+15*x+18
--R
--R
--R          4     2
--R   (5)  3x  + 2x  + 15x + 18
--R                                 Type: UnivariatePolynomial(x,PrimeField(19))
--E 5

--S 6 of 21
factor u
--R
--R
--R                   3    2
--R   (6)  3(x + 18)(x  + x  + 8x + 13)
--R                       Type: Factored(UnivariatePolynomial(x,PrimeField(19)))
--E 6

Creating new tests amounts to running an expression then decorating the output with --R lines 

surrounded by the --S and --E boundaries. Creating tests is a simple text edit. Failing tests are

indentified by file and test number showing both the computed and expected results.

--U is an external URL marker used to link to a paper that contains the algorithm.

For example, about Groebner Basis:

--U https://www.amazon.com/Computational-Algebraic-Geometry-Groebner-Basis/dp/3659435856

--P was intended to jump to the PDF output in the literate program so a user could directly

access the function sources in the correct domain along with the literate explanation.

In general since ++ and -- comments are ignored the ++(letter) and --(letter) make it easy

to add information that does not need compiler support.

Tim

++

To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dYuiju2PAUO3GyADN1TXYBsaYE-MYKrUsCA-ZL9_g_4kg%40mail.gmail.com.

[Waldek Hebisch]

ATM FriCAS does not support regular expressions. But, AFAICS main
functionality of the above can be done like:

)boot grepConstruct("mod*", "o", [])

This returns documentation lines from libdb.text or comdb.text.

Currently 'grepConstruct' calls external 'grep', that is one of
things that I would like to change. Information in libdb.text
and comdb.text can be generated from other sources, and it is
not clear to me if we need libdb.text and comdb.text in longer
term.

Concerning regular expressions, they are sometimes handy. OTOH
using regular expression search pattern above would be "mod.*"
which is more complicated than wildcards that we use now. So
regular expressions may be an extra (optional) interface, but
probaly not the main one.

There is trouble that thare are several syntaxes for regular
expressions and actually several different things called
"regular expressions". Namely, classic regular expressions
are equvalent to finite automata. There are restricted
classes of regular expressions where equvalent automaton is
easier to build. OTOH there are extentions, for example
Perl regular expression can do more than finite automata,
but sometimes execution time is enormous. But implementing
something is not a big trouble, simply other things
looked more useful.

--
Waldek Hebisch

[Tim Daly]

The various DAASE files exist because the original version of the system

was too large to contain that information in memory. The DAASE file

structure is a copy of the VMLISP file structure. The compress file

was added later because I needed to put Axiom on a tiny laptop (16k).

The idea was to keep long filenames in a compressed form.

Note also that the DAASE files are designed for random access hardware.

The first lookup is essentially a cylinder-track-sector for hard drives.

There is no point doing this on fully electronic hardware.

So the DAASE files are legacy and ought to be redesigned out of the work.

It might make sense to provide a graph structure with hash pointers

or to just use a standard database with a SQL lookup as those have been

optimized quite a bit over the years. It all depends on measuring the kind

of lookups.

Given my background I'd make the databases into a lisp data structure

which gives all kinds of access as well as dynamics addition / deletion, etc.,

sits in memory, and can be used by all kinds of tools. It would also be

"in-line" accessible by SPAD code and Hyperdoc-replacement tools.

Languages like Python have sexpression reader libraries.

Tim

[Waldek Hebisch]

Thank to all for comment. Ralf raised most important points,
so I will answer this first.

On Wed, Jun 11, 2025 at 08:59:14PM +0200, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
>
> as you know, I would like to let HyperDoc die.
> But, maybe that sound too extreme for what I actually mean.
> And I agree to some extend to your plan for a new hyperdoc.
>
> Let me explain my wishes.
>
> FriCAS should have an interface (in LISP or SPAD) that let's
> SPAD or external programs get information about
> categories/domains/packages/documentation.
> From such an interface it should be easy to generate any output format
> be it html, rst or pdf.
>
> I think this can be started without changing any code for hyperdoc.
> Such an interface should already contain code to compute a datastructure
> representing the data for a page (not actually rendered in any format), in
> particular, conditional exports should be computed and the datastructure
> should have enough information to produce links to other data.
>
> Yes, that is good for a getting a "static" view of a constructor similar to
> what is presented at fricas.io/api, but computable on-the-fly.
>
> You also want such a view in a "dynamic" form, i.e. (similar to what current
> hyperdoc provides) getting information about
> - usage of domains
> - fuction implementation (in which package/domain)
> - etc.
>
> Shouldn't it be possible to create an API that let's query such information
> by just sending strings to specify the arguments?

Yes, that is part of my plan, with possibly not so important
difference that I want Symbol-s in many places.

> Why would that need Boot code if there is a function that translates the
> string "Polynomial Integer" into the respective domain and uses that in
> querying the various places where the wanted information is stored in
> FriCAS?

My point is about doing change in incremental way. There is about
6000 lines of Boot code doing things related to HyperDoc, ')show'
and similar. Replacement preserving functionality may be smaller,
but also may be bigger. There are redundancies in existing code
so we may be able to delete some code. But Spad needs declarations,
type differences may force some duplication, so there is good
chance that Spad version may be bigger.

Doing change of this scale at "one shot" is likely to be a failure.
Keeping parallel "old" and "new" versions is a pain. That is
why I want new code to work smootly with old, in particular
using the same data structures in both.

> Whether you then program in interface to present such information, is
> another business. I wouldn't do that but rather rely on ordinary webbrowsers
> to display such information. One can probably extent jfricas to start
> queries and have examples executed in a notebook interface.
>
> Yes, I like to be able to get more information out of FriCAS than just a
> static API page (although I think that having them static on the web is
> still a good idea). What I am not in favour of is the current HyperDoc
> window. That looks old and not very attractive. That should die. Not the
> information it shows, of course.

Well, current HyperDoc window has its problems. But I hear "old
and not very attractive", but did not see mention of what I consider
to be main problem. So most of HyperDoc critique looks shallow
to me. I like fact that HyperDoc executable is quite lightweight
by modern criteria.

> At the same time, I would like to put the HyperTeX format to sleep.
> This format was interesting 30 years ago, but now there are better formats
> like rst of markdown or ... Why should we keep our specific HyperTeX-Format
> that nobody outside FriCAS cares about?

There are rather strong reasons to have format that "nobody outside
FriCAS cares about", that is format that _we_ control. Namely, in
opposite case we have to deal with changes, regardless if like
them or not. If we need extra features we can add them, we can
implement extra features. HyperTeX is a subset of TeX, which
puts some limitations, but TeX format is quite extensible so
that is not a big problem and we get advantage of reusing
existing machinery.

> I do not know whether my code is good to be adapted, because initially, I
> only had the presentation into an .rst page in my mind. I think one should
> carefully separate code that "provides" information from code that
> translates that into a certain format.
>
> Can we create a new branch and work (as a first step) at an interface
> that provides all the necessary information in form of SExpression?

Well, branch implies extra effort and I would prefer to avoid it
if possible. I started from different point, that is communitation
with HyperDoc window and now I moving towards core part, that is
search functionality. So, the interface should appear, but there
is more code than this.

> > As I wrote I have part of HyperDoc code in Spad. HyperDoc
> > page has the following representation:
> >
> > Rep := Record(name : Symbol, domain_conditions : LSE,
> > variable_alist : ALS, pattern_vars : List(PSR),
> > radio_buttons : ALS, input_areas : ALS,
> > property_list : ALS, page_description : LSE,
> > work_area : List(String))
>
> That is seemingly taylored for a hyperdoc page. Why should one have
> radio_buttons in an information record?

This record describes single page of interface. Such pages are
supposed to be interactive, so may contain buttons. For example
"Detailed search" page contains buttons for various options
affecting search. Also, HyperDoc handles example pages and
those pages also contain buttons.

As I wrote, this is rather unbalanced, most features are crammed
into 'property_list' and 'page_description' and most pages have
empty list as 'domain_conditions, 'variable_alist', 'pattern_vars',
'radio_buttons' and 'input_areas' but ATM this is needed for
compatibility with Boot code. 'work_area' is new thing, I
need it to avoid global variables used in old Boot code.

> I would rather have several data
> structures like
>
> FUN ==> Record(
> name: Symbol,
> source: SEX,
> target: SEX,
> doc: String,
> condition: SEX)
>
> CAT ==> Record(
> name: Symbol,
> args: List SEX,
> cats: List Record(cat: CAT, condition: SEX)
> funs: List FUN)
>
> etc. (Don't take that too serious. It's just a draft.)
>
> Anyhow, we should come up with a good datastructure that provide
> easy access to the information.

Well, it is not clear to me what types will be best for quering
(searching). The type I showed has quite different purpose,
it represents basic unit (that is page) of user interface.

> If you want a datastructure that is just representing the current hyperdoc
> structure, I am not interested. That is too much presentation oriented
> already.

Yes, it is presentation oriented. I would like to make it more
logical, but I do not know how far one can go in this direction
without excessive effort. However, presentation part is
necessary. Simply I want to decouple search and gathering of
information from presentation part. Currently search and
gathering of information is partly intertwined with presentation.
In better structured code presentation part should call
search and information gathering routines. Technically,
calling Boot from Spad is easier than calling Spad from
boot, that is why I prefer to start at presentation layer
and work toward more fundamental layers (and not in
opposite direction).

> > this, but I am not sure if this will be possible: Ralf uses
> > data structures (in particular XHashTable) which are problematic
> > to access from Boot.
>
> There is nothing specific about XHashTable. Any hash structure will do. Use
> an association list, if you like.
>
> > Extra remarks: my goal is to allow dynamic interface either using
> > current C code or a web browser (depending on user choice).
>
> As I said, I would rather like a generic interface to all the information,
> separated from code that does the presentation.

Yes, I want such an interface too. Simply I want woring code
in intermediate stages and staring from presentation looks
easier. Also, having working presentation gives me assurance
that I did not forget something important for presentation.

--
Waldek Hebisch

[James Cloos]

btw, speaking of hyperdoc,

have the default fonts ever been updated to ones available in recent
distributions?

the original probably were fine on an ibm box, but were never okon an
xfree or xorg box.

i currently have:

FriCAS.hyperdoc.RmFont: -bitstream-charter-medium-r-normal--*-120-*-*-p-*-iso8859-1
FriCAS.hyperdoc.TtFont: -b&h-lucidatypewriter-medium-r-normal-sans-*-120-*-*-m-*-iso8859-1
FriCAS.hyperdoc.ActiveFont: -bitstream-charter-bold-r-normal--*-120-*-*-p-*-iso8859-1
FriCAS.hyperdoc.FriCASFont: -bitstream-charter-bold-i-normal--*-120-*-*-p-*-iso8859-1
FriCAS.hyperdoc.EmphasizeFont: -bitstream-charter-medium-i-normal--*-120-*-*-p-*-iso8859-1
FriCAS.hyperdoc.BoldFont: -bitstream-charter-bold-r-normal--*-120-*-*-p-*-iso8859-1

on this laptop. and used this on my workstation before it died:

! FriCAS.hyperdoc.RmFont: -b&h-lucidabright-medium-r-normal--20-*-*-*-p-*-iso8859-1
! FriCAS.hyperdoc.TtFont: -b&h-lucidatypewriter-medium-r-normal-sans-20-*-*-*-m-*-iso8859-1
! FriCAS.hyperdoc.ActiveFont: -b&h-lucidatypewriter-bold-r-normal-sans-20-*-*-*-m-*-iso8859-1
! FriCAS.hyperdoc.FriCASFont: -b&h-lucidatypewriter-bold-r-normal-sans-[20 0 2 20]-*-*-*-m-*-iso8859-1
! FriCAS.hyperdoc.EmphasizeFont: -b&h-lucidatypewriter-medium-r-normal-sans-[20 0 2 20]-*-*-*-m-*-iso8859-1
! FriCAS.hyperdoc.BoldFont: -b&h-lucidatypewriter-bold-r-normal-sans-20-*-*-*-m-*-iso8859-1

not as good as client-side fonts would look, of course,
but at least readable.

(I don't recall why i used [20 0 2 20] rather than 20.
that bit of slant must have had some meaning....)

In any case, using faces which are directly available as bfd or pcf and
thus do not require scaling by the X server is vital to readability.

client-side font support would be better, but using unscaled server-side
fonts gets the job done. defaulting to widely installed faces is therefore
important.

-JimC
--
James Cloos <cl...@jhcloos.com>
OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc

[Waldek Hebisch]

On Thu, Jun 19, 2025 at 01:23:55AM -0400, James Cloos wrote:
> btw, speaking of hyperdoc,
>
> have the default fonts ever been updated to ones available in recent
> distributions?
>
> the original probably were fine on an ibm box, but were never okon an
> xfree or xorg box.

I do not think that we changed anything in font setting. In the past
I have looked at available fonts and they seem to differ quite a lot
between systems. AFAICS the best thing that we can do in general
(as opposed to customised user settings) is to pick default system
font. And IIUC current configuration is more or less doing this.
It is possible that we could do better to respect default system
choices, but we should make fonts less (and no more) specific.

> i currently have:
>
> FriCAS.hyperdoc.RmFont: -bitstream-charter-medium-r-normal--*-120-*-*-p-*-iso8859-1
> FriCAS.hyperdoc.TtFont: -b&h-lucidatypewriter-medium-r-normal-sans-*-120-*-*-m-*-iso8859-1
> FriCAS.hyperdoc.ActiveFont: -bitstream-charter-bold-r-normal--*-120-*-*-p-*-iso8859-1
> FriCAS.hyperdoc.FriCASFont: -bitstream-charter-bold-i-normal--*-120-*-*-p-*-iso8859-1
> FriCAS.hyperdoc.EmphasizeFont: -bitstream-charter-medium-i-normal--*-120-*-*-p-*-iso8859-1
> FriCAS.hyperdoc.BoldFont: -bitstream-charter-bold-r-normal--*-120-*-*-p-*-iso8859-1
>
> on this laptop. and used this on my workstation before it died:
>
> ! FriCAS.hyperdoc.RmFont: -b&h-lucidabright-medium-r-normal--20-*-*-*-p-*-iso8859-1
> ! FriCAS.hyperdoc.TtFont: -b&h-lucidatypewriter-medium-r-normal-sans-20-*-*-*-m-*-iso8859-1
> ! FriCAS.hyperdoc.ActiveFont: -b&h-lucidatypewriter-bold-r-normal-sans-20-*-*-*-m-*-iso8859-1
> ! FriCAS.hyperdoc.FriCASFont: -b&h-lucidatypewriter-bold-r-normal-sans-[20 0 2 20]-*-*-*-m-*-iso8859-1
> ! FriCAS.hyperdoc.EmphasizeFont: -b&h-lucidatypewriter-medium-r-normal-sans-[20 0 2 20]-*-*-*-m-*-iso8859-1
> ! FriCAS.hyperdoc.BoldFont: -b&h-lucidatypewriter-bold-r-normal-sans-20-*-*-*-m-*-iso8859-1
>
> not as good as client-side fonts would look, of course,
> but at least readable.
>
> (I don't recall why i used [20 0 2 20] rather than 20.
> that bit of slant must have had some meaning....)
>
> In any case, using faces which are directly available as bfd or pcf and
> thus do not require scaling by the X server is vital to readability.

AFAIK current X font are mostly scalable, so scaling should be non-critical.

> client-side font support would be better, but using unscaled server-side
> fonts gets the job done. defaulting to widely installed faces is therefore
> important.

I understand that some applications want custom fonts. But simple
application like HyperDoc should be able to work with system
fonts, we are not in font business.

--
Waldek Hebisch

[Hill Strong]

I know that many projects don't want to consider that fonts should be included, however, when you include a specific set of fonts and install them as a part of the build/installation process, you are giving a bit of polish to your application.

Likewise, making it easy for the user to specify specific fonts applicable to them also shows polish on your part.

If you leave it up to some possible set of standard fonts that you expect to already exist then people who may have been interested can and do walk away as they can often think that your application is not worth the effort.

Something to consider.

--
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 fricas-devel...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/aFQnED_pH5oqBgDI%40fricas.org.

[James Cloos]

>>>>> "WH" == Waldek Hebisch <de...@fricas.org> writes:

WH> I understand that some applications want custom fonts. But simple
WH> application like HyperDoc should be able to work with system
WH> fonts, we are not in font business.

i cettainly never suggested custom fonts.

axiom from its initial floss release defaulted to fonts ibm x servers
supported due to ibm licensing adobe's t1 fonts.

floss distributions only eber had a small, fixed number of bitmap
strikes of those fonts. and the sizes axiom specified were not amoung
those available to users of xfree86 (and later xorg) servers.

thus hyperdoc was entirely unreadable.

one had to come up with values for each of:

Axiom.hyperdoc.RmFont
Axiom.hyperdoc.TtFont
Axiom.hyperdoc.ActiveFont
Axiom.hyperdoc.AxiomFont
Axiom.hyperdoc.EmphasizeFont
Axiom.hyperdoc.BoldFont

which were listed in the output of xlsfonts(1) on one's server to be able
to read any of the hyperdoc output.

when the xserver has to scale bitmap strikes the output is crap.

as i recall, xorg dropped support for type1 and ttf fonts some time ago.

they certainly do not show up in xlsfonts(1)'s output on this xserver.

so if fricas still defaults to the faces ibm used to specify, hyperdoc
will be unreadable without local customization until it switches to
client-side fonts.

so until that occurs (not demanding that or anything!) the default fonts
should be chosen from what xlsfonts(1) reports, which means not only the
face's name but also the pointsize.

[Tim Daly]

Correction:

JimC> axiom from its initial floss release defaulted to fonts ibm x servers
JimC> supported due to ibm licensing adobe's t1 fonts.

Scratchpad development started on X10 and the fonts were a carry-over.

There was some discussion in 2005 or so related to the Adobe SVG viewer.

There is a reference to adobe-courier-{medium,bold}...iso8859-1

Font choice is painful as not all fonts contain the mathematical symbols.

It might be worthwhile testing on Wayland as I understand it is supposed to

replace X11.

Tim

--
You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/mb_O0196RMQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/m3sejuzj24.fsf%40lugabout.jhcloos.org.

[James Cloos]

>>>>> "TD" == Tim Daly <axio...@gmail.com> writes:

TD> Correction:

TD> Scratchpad development started on X10 and the fonts were a carry-over.
TD> There was some discussion in 2005 or so related to the Adobe SVG viewer.
TD> There is a reference to adobe-courier-{medium,bold}...iso8859-1

thanks for the correction.

i thought i also recalled use of times and/or helvetica.

but always at a point size not coverred by the bfd/pcf bitmap fonts
included in xfree and later xorg.

[Tim Daly]

Hyperdoc, as Ralf points out, is outdated and needs to be replaced.

Browser-based Hyperdoc is clearly the last-years-technology way to go.

That would solve the font problem but is still "old school".

Actually, LLMs are clearly the way to go but I don't think most people

are up-to-speed on creating LLM apps yet. The LLM approach could

not only explain the available integration functions and choose the

right signature, it could explain why a Sylvester matrix is used to

compute the resultant used in the algorithm.

The Model-Context Protocol (MCP) is clearly the best way to replace Hyperdoc

as MCP allows LLMs to interact and access external data sources. A computer

algebra MCP adapter is clearly the best choice going forward. It gives access to

all of the existing LLMs in a uniform and universal way.

With such an adapter you could just ask for the integration and/or ask a lot of

questions about the integral. In fact, as a research tool such an MCP interface

would help answer questions the LLM knows about limits, alternate approaches, 

etc. which allows "discussing" the integral with the LLM. The LLM could suggest

and summarize available relevant papers in real time.

If I were still active I'd choose that path forward.

https://www.anthropic.com/news/model-context-protocol

Tim

 

[Grégory Vanuxem]

Hello Tim, *,

Thanks for your response, but frankly speaking, I do not know how to
find your code. I tried to download Axiom, it is not easy.
I just found axiom_20210105dp1.tar.gz but apparently, right now, Camm
has done some improvements to find better/recent source code.

I have to try it.

- Greg

PS/ sorry for the delay

> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAJn5L%3DKecxUfnoxp1sLEQOnY06s3RSrWejf2C%3DrzPCnZ%2BbdP7A%40mail.gmail.com.

[Grégory Vanuxem]

Yes of couse. But you're looking very forward a lot I think. I follow that since a lot of time.

I have asked, personally, to Brent, Nocedal etc. in 2007, for using their code sources, https://metacpan.org/pod/PDL::Opt::NonLinear

they were very moneyable at that time. They agreed. I agree with Linus Torvalds, AI, 95% of marketing.

But I think you see to a lot forward. Fonts, is another matter, it is a real problem BTW, just this week because of a dist-upgrading I had to wait for an update. To small to read without glasses. An unknown reason.

I think your idea Tim can be very good. But a lot of things in the numerical world need to be done/added.

https://x.com/search?q=mcp&t=6s8XTuxpWGBbWodV53xBQA&s=09

- Greg

[Waldek Hebisch]

On Fri, Jun 20, 2025 at 08:36:19AM -0400, James Cloos wrote:
> >>>>> "WH" == Waldek Hebisch <de...@fricas.org> writes:
>
> WH> I understand that some applications want custom fonts. But simple
> WH> application like HyperDoc should be able to work with system
> WH> fonts, we are not in font business.
>
> i cettainly never suggested custom fonts.
>
> axiom from its initial floss release defaulted to fonts ibm x servers
> supported due to ibm licensing adobe's t1 fonts.
>
> floss distributions only eber had a small, fixed number of bitmap
> strikes of those fonts. and the sizes axiom specified were not amoung
> those available to users of xfree86 (and later xorg) servers.

FriCAS specifies the following fonts:

-adobe-courier-medium-r-normal--18-*-*-*-m-*-iso8859-1
-adobe-courier-medium-o-normal--18-*-*-*-m-*-iso8859-1
-adobe-courier-bold-r-normal--18-*-*-*-m-*-iso8859-1
-adobe-courier-bold-o-normal--18-*-*-*-m-*-iso8859-1

Fonts matching that appear in output of xlsfonts on my machine,
which IIUC means that they are available.

> thus hyperdoc was entirely unreadable.
>
> one had to come up with values for each of:
>
> Axiom.hyperdoc.RmFont
> Axiom.hyperdoc.TtFont
> Axiom.hyperdoc.ActiveFont
> Axiom.hyperdoc.AxiomFont
> Axiom.hyperdoc.EmphasizeFont
> Axiom.hyperdoc.BoldFont
>
> which were listed in the output of xlsfonts(1) on one's server to be able
> to read any of the hyperdoc output.
>
> when the xserver has to scale bitmap strikes the output is crap.
>
> as i recall, xorg dropped support for type1 and ttf fonts some time ago.

AFAIK scalable fonts are supported. You may be thinking about old
news that FreeType dropped support for hints in fonts. This
was after a patent dispute, but FreeType folks claimed that
they get better results without hints.

> they certainly do not show up in xlsfonts(1)'s output on this xserver.
>
> so if fricas still defaults to the faces ibm used to specify, hyperdoc
> will be unreadable without local customization until it switches to
> client-side fonts.
>
> so until that occurs (not demanding that or anything!) the default fonts
> should be chosen from what xlsfonts(1) reports, which means not only the
> face's name but also the pointsize.

IIRC we had some discussion about fonts several years ago.
My understanding was that available fonts differ widely between
systems, in particular there are silly renamings due to trandmark
reasons and essentially identical fonts with widely different
names. Anyway, the discussing did not found better default
than the one we have now.

--
Waldek Hebisch

[Tim Daly]

git clone https://github.com/axiom/daly

should give you the last known public version.

Camm has a public copy at

https://www.nongnu.org/axiom/axiom-website/faq.html

If you look at axiom/src/input you will find *.pamphlet test files.

They are really just *.tex (as are all .pamphlet files)

You can also find various tests against other published collections

which I call the "Computer Algebra Test Suite" (CATS), with the

intention of collecting and testing against other public collections

https://www.nongnu.org/axiom/axiom-website/CATS/index.html

(see chapter 5 of bookvol8.1 related to pasta for fun examples)

https://www.nongnu.org/axiom/axiom-website/bookvol8.1.pdf

To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2datEvCjyDs2qb%3D-PTxfHkOfPvmPF9NJpVDYVwt-gCMtXw%40mail.gmail.com.

[Tim Daly]

Wow. I really love that PDL:: site!

On the numeric front I have created a lisp version of BLAS and LAPACK

https://www.nongnu.org/axiom/axiom-website/bookvol10.5.pdf

as part of the distribution. There needs to be a test suite created as well

as SPAD "cover functions" and further detailed documentation.

On the ambitious front there should be CUDA code versions included.

Tim

To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dZcOdhgXR6wHJ99Pgf9oEjCAos1OpWsf4mthFB2qmUxnw%40mail.gmail.com.

[James Cloos]

>>>>> "WH" == Waldek Hebisch <de...@fricas.org> writes:

WH> FriCAS specifies the following fonts:

WH> -adobe-courier-medium-r-normal--18-*-*-*-m-*-iso8859-1
WH> -adobe-courier-medium-o-normal--18-*-*-*-m-*-iso8859-1
WH> -adobe-courier-bold-r-normal--18-*-*-*-m-*-iso8859-1
WH> -adobe-courier-bold-o-normal--18-*-*-*-m-*-iso8859-1

WH> Fonts matching that appear in output of xlsfonts on my machine,
WH> which IIUC means that they are available.

Ah. xorg only ships 11, 14 and 17 point versions of those.

not 18 pt.

from the fonts.dir file:

courB12-ISO8859-1.pcf.gz -adobe-courier-bold-r-normal--17-120-100-100-m-100-iso8859-1
courBO12-ISO8859-1.pcf.gz -adobe-courier-bold-o-normal--17-120-100-100-m-100-iso8859-1
courO12-ISO8859-1.pcf.gz -adobe-courier-medium-o-normal--17-120-100-100-m-100-iso8859-1
courR12-ISO8859-1.pcf.gz -adobe-courier-medium-r-normal--17-120-100-100-m-100-iso8859-1


so the xserver has to scale the 17 to 18. which looks ugly.

s/18/17/ would at least solve that visual annoyance.

[James Cloos]

so, obviouly my recall is not as good as it used to be...

(and it has been a couple of decades since i did much with the server-
side fonts.....)

so some corrections to my statements:

after further review, i see that the 18pt adobe-courier strikes are in
the 75dpi/fonts.dir which (obviously) was not in this box's font path.

and Type1/fonts.scale (also was not in my fp) has:

cour.pfa -ibm-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1
courb.pfa -ibm-courier-bold-r-normal--0-0-0-0-m-0-iso8859-1
courbi.pfa -ibm-courier-bold-i-normal--0-0-0-0-m-0-iso8859-1
couri.pfa -ibm-courier-medium-i-normal--0-0-0-0-m-0-iso8859-1

which can fully scale.

so perhaps the best change would be s/adobe/*/ so that the ibm-courier
pfb file get chosen when Type1 is in the fp, but the adobe-courier still
can get used when only bfd or pcf fonts are in the fp.

i thought i recalled that xorg removed the type1 server-side renderer.
but perhaps that was only proposed and rejected? or reversed?

too many decades. and two many strokes.

[Tim Daly]

It seems that it might take a day of hacking to connect to Claude AI

or other AI systems. The clearest example with code is at

https://www.youtube.com/watch?v=N3vHJcHBS-w&ab_channel=ShawTalebi

So if you want to try to connect to an AI to answer integration questions

this should provide sufficient background to get it running quickly.

An MCP server could even be customized to read and format database

information to answer questions about available domains, functions,

and documentation. It could even be formatted similar to Hyperdoc output.

Suddenly all of the AIs know how to do computer algebra.

Tim

[Nasser M. Abbasi]

" Suddenly all of the AIs know how to do computer algebra."

When chaptGPT 3.5 came out in 2022, I run one integration test file (MIT integration problems) using

chaptgpt 3.5. At the time just to try it. 

Had to type each problem by hand one by one into the command and copy 

the result. May be these days this can be automated with the new API's.

But at the time chaptGPT did not do well. It scored lowest in percentage solved.  I am sure it has improved by now.

Here is the HTML (there is also PDF file) 

This was the result (percentage solved)

Mathematica  99.38
Fricas  96.57
Maple 95.33
Rubi 94.08
Maxima 92.52
Giac 91.59
Mupad 90.03
Sympy 82.24
ChatGPT 14.33

--Nasser

[Tim Daly]

The AI isn't doing the problem solving. It is using the computer algebra system

as a problem solver. This is similar to the way William Stein's Sagemath

connects to other systems to supply answers. The key difference is that

MCP is an open standard that can be used by anything, including LLMs.

The MCP idea is to set up a server that advertises the ability to answer

mathematical questions and provide a client that provides the actual

answers. The various computer algebra systems provide their own client.

All of the LLMs can use MCP. They can know the services provided by

the server (e.g. computer algebra) and will ask the server for answers.

This is different than asking ChatGPT to provide answers.

This is standards based and much more general than having a system

like Hyperdoc. A new Hyperdoc would communicate with an MCP

server to provide a "hyperdoc-like" page. This is the same argument

used for HTML, JSON, and other general standards behind a browser.

Tim

--

You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/mb_O0196RMQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/0fafdeb1-f723-4f4b-8f80-f1f7758d8b05n%40googlegroups.com.

[Grégory Vanuxem]

This is already available, here, using a very experimental FriCAS extension to VSCode and Gemini. The question is: how to integrate sin(x):

Hoping, the pictures are only downloaded if necessary.

- Greg

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 fricas-devel...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAJn5L%3DKEHpmcJHqkz_SyHaGwyhwDghzbV_SDKA_0R7MExu8nRA%40mail.gmail.com.

[Tim Daly]

That's a beautiful piece of work!

I might suggest including external links to related information,

e.g. a youtube video discussing the algorithm or a technical

paper / book that contains the algorithm such as Trager's PhD thesis:

Raab,Clemens G., Singer, Michael F.

-"Integration In Finite Terms: Fundamental Sources"

Springer, 2022, ISBN 978-3-030-97866-4

https://www.amazon.com/Integration-Finite-Terms-Fundamental-Computation/dp/3030987663/

Tim

To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAHnU2dbxAmXFbvUO42y8ivvcDn1DKhGcdOESb56qF3BgLoPgUw%40mail.gmail.com.

[Waldek Hebisch]

On Sat, Jun 21, 2025 at 12:45:10AM -0400, James Cloos wrote:
> so, obviouly my recall is not as good as it used to be...
>
> (and it has been a couple of decades since i did much with the server-
> side fonts.....)
>
> so some corrections to my statements:
>
> after further review, i see that the 18pt adobe-courier strikes are in
> the 75dpi/fonts.dir which (obviously) was not in this box's font path.
>
> and Type1/fonts.scale (also was not in my fp) has:
>
> cour.pfa -ibm-courier-medium-r-normal--0-0-0-0-m-0-iso8859-1
> courb.pfa -ibm-courier-bold-r-normal--0-0-0-0-m-0-iso8859-1
> courbi.pfa -ibm-courier-bold-i-normal--0-0-0-0-m-0-iso8859-1
> couri.pfa -ibm-courier-medium-i-normal--0-0-0-0-m-0-iso8859-1
>
> which can fully scale.
>
> so perhaps the best change would be s/adobe/*/ so that the ibm-courier
> pfb file get chosen when Type1 is in the fp, but the adobe-courier still
> can get used when only bfd or pcf fonts are in the fp.

We could drop 'adobe' part of the font. On my machine there is
no ibm courier font. I have probably fake adobe "scalable" font
(it appears as a scalable font in font list, but AFAICS there
is no correspondingh real scalable font). There are also
'courier 10 pitch' fonts which seem to be true scalable
fonts.

AFAICS Reduce ships a few fonts.

--
Waldek Hebisch

[Grégory Vanuxem]

This is a plugin in VSCode: https://marketplace.visualstudio.com/items?itemName=Google.geminicodeassist&ssr=false#overview

You open axiom or fricas source code directory in VSCode and the Gemini AI will help you for coding or using panAxiom. Copilot is also available. The advantage of Gemini is that is not as restricted as Copilot for example.

- Greg

To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/CAJn5L%3DKQWGM5d%3D0R-m1XyvbkwNP4repBR8Xk-PqGab_DigEvaQ%40mail.gmail.com.

[James Cloos]

and one last thought.

i was reading thru fricas-book. it notes:

FriCAS.hyperdoc.RmFont: Rom14
FriCAS.hyperdoc.ActiveFont: Bld14
FriCAS.hyperdoc.FriCASFont: Bld14
FriCAS.hyperdoc.BoldFont: Bld14
FriCAS.hyperdoc.TtFont: Rom14
FriCAS.hyperdoc.EmphasizeFont: Itl14

so the answer to my original q is: yes, you did change from axiom's
original hyperdoc font defaults to ones at least shipped by xfree and
now xorg.

the scalable ibm-courier is, on gentoo, in the package font-ibm-type1,
with homepages:

https://www.x.org/wiki/
https://gitlab.freedesktop.org/xorg/font/ibm-type1

so shipped by xorg; but i've no idea which packages to suggest for other
distributions. i should have looked deeper before suggesting that....

[Grégory Vanuxem]

Hello James, *,

On Debian like system:

└─$ apt-cache search ibm |grep font
console-cyrillic - Cyrillic fonts and keyboard layouts for Linux console
fonts-3270 - monospaced font based on IBM 3270 terminals
fonts-pc - TrueType conversions of PC ROM fonts
fonts-pc-extra - TrueType conversions of PC ROM fonts (less popular variants)
fonts-texgyre - OpenType fonts based on URW Fonts
fonts-yusei-magic - handwritten letters written with permanent marker
golang-github-pbnjay-pixfont-dev - pixel font package for Go (library)
librust-ab-glyph-dev - API for loading, scaling, positioning and
rasterizing OpenType font glyphs - Rust source code
texlive-fonts-extra - TeX Live: Additional fonts
xfonts-scalable - scalable fonts for X
xfonts-x3270-misc - Font files for the x3270(1) IBM 3270 emulator
fonts-ibm-plex - extensive typeface family designed by IBM
t1-xfree86-nonfree - non-free Postscript Type 1 fonts from XFree86

There is also:

└─$ apt-cache show fonts-ibm-plex
Package: fonts-ibm-plex
Version: 6.1.1-1
Installed-Size: 41800
Maintainer: Debian Fonts Task Force <debian...@lists.debian.org>
Architecture: all
Size: 26024764
SHA256: 682528a0832d8c5c3a92c64434c99fcceb1d2836ce7cf3cced902dcd86a188b2
SHA1: e4200c0e48bae0a7a34948927fc024c9791794e6
MD5sum: c047e907d3f395e2de6b70881327877b
Description: extensive typeface family designed by IBM
IBM Plex is an extensive font family developed by IBM. It comes in four
subfamilies (Sans, Sans Condensed, Mono and Serif) and 8 weights (Thin,
Extralight, Light, Regular, Text, Medium, Semibold, Bold), with true italics
to complement them. A variable-weight counterpart of IBM Plex Sans is also
available.
.
The four basic subfamilies support most of the languages using the Latin
alphabet (including Vietnamese), the Cyrillic writing system and monotonic
Greek. Hebrew (including cantillation marks), Thai (both looped and loopless),
Devanagari and Arabic are supported as separate typefaces.
.
There is also support for common mathematical and currency symbols as well as
ligatures and stylistic alternates.
.
This package contains the TrueType (CFF) flavored OpenType fonts and
the WOFF/WOFF2 web fonts.
Description-md5:
Multi-Arch: foreign
Homepage: https://www.ibm.com/plex/
Section: contrib/fonts
Priority: optional
Filename: pool/contrib/f/fonts-ibm-plex/fonts-ibm-plex_6.1.1-1_all.deb

But I think they are more recent fonts.

- Greg

> --
> 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 fricas-devel...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/m3ldpbw3em.fsf%40lugabout.jhcloos.org.

[Waldek Hebisch]

A little update, I think that I am making progress. You may be
disappointed as most work is related to presentation and not
strictly data structures. By presentation affects data
structures.

At top level HyperDoc offers 10 searches. First 4 searches
serch for name of category, domain, package or operation
respectively, choosing ones that match pattern. There is
documentation search which searches doctrings which match
pattern. There is difference here, whole name must match
so "oral" matches nothing in first 4 searches, while
in documentation search it is enough to have substring match,
so the same pattern matches one entry (that is
TopLevelDrawFunctionsForAlgebraicCurves). Pattern may
contain literal characters or stars representing arbitrary
sequence of characters, so '*oral*" gives match in
package search. One can use boolean combination of
patterns. For example "*anal* or *oral*" gives 2 matches
for packages.

3 other searches are combiantion of above searches. There
are two searches under "Selectable", which allow specifying
number of arguments and pattern for signature.

All of the above searches work on libdb.text and comdb.text.
Patterns are converted to grep regular expressions and
grep is called to find matching lines. AFAICS split into
libdb.text and comdb.text simplifies resulting patterns.

Anyway, for those searches we need representation for
patterns and representation for result. Currently
result is essentially list of strings. Logically
there are 8 pieces of information in the strings:
- kind of line (catgory, domain. package, operation,
encoded in first character)
- name
- number of arguments
- info about exposure (single character)
- signature
- origin of operations, list of parameters for constructors
- condition for operation, abbreviation for constructors
- documentation (number giving file offset in libdb.text)

For constructors exposure means that constructor is exposed or
not. For operations exposure is really about constructors,
usualy origin. Exposure info in libdb.text is mostly
redundant and HyperDoc in most cases uses exposure info
computed at runtime.

For operations, list of strings is grouped according to operation
name and later expanded into list form. More precisely, for
each operation we have list of lists, where inner list contains
signature, condition, origin, exposure info and documentation
in this order.

There is alternative path for almost exact matches: if name up to
case matches constructor name, then constructor info is collected
via get_database calls and put into a line. For operations,
if name matches exactly operation name list of matching modemaps
is fetched for database (essentially via get_database(op, 'OPERATION)).
Modemaps contain signature and conditions on origin, target and arguments.
This allows computing origin (theoretically this may be quite hairy,
in practice simple code seem to work well). This data misses
documentation and later, when needed there is rather complex
code to find documentation. I think that this part may be
simplified, as once we know origin we can look at documentation
part of origin (stored in database) and find operation there.

The above means that logically we do not need libdb.text and
comdb.text: documentation search can go trough all constructors
and for each constructor trough all its documentation strings.
Other searches can go trough names of construtors or operations,
fetching data for matched entries from database.

libdb.text and comdb.text allow using grep for searches, which
have some advantages. But currenlty we get info from strings
by parsing and interpreter parser is rather slow. So not
using libdb.text and comdb.text may be better.

Concerning libdb.text strings representing constructors, later
most info form the string is discarded and only name is used
(given name we can find the rest in database).

Now, how presentation affects this? Due to overloading we may
have multiple operations corresponding to single name (on average
there are about 2 operations per name) and several views group
operations according to names. So there is need to display
varying info "by name". There are 7 main views of operations:
names, parameters, signatures, full descriptions, grouped via origin,
grouped via condition and grouped via implementing domain. So in fact
in 3 views we have hierarchical grouping. But display logic
is related: we have title (heading) and (possibly nested)
groups with clickable entries. In nested cases groups have
changing labels. Title can change depending on how we entered
the page. There is possiblity to show all operations or only
exposed ones and that also affects title. HyperDoc tries to
disable "useless" links and there is special code to do
this.

There is possiblity of filtering (that is keeping
only names matching pattern).

So, while there are 7 principial views of operations users can
see tens of variations depending on what was done before.

For lists of constructors there are 6 principal views: abbreviations,
names, with parameters, descriptions, grouped by conditions,
grouped by kinds. "General", "Documentation" and "Complete"
search also group info. From constructor description page
one can reach additional pages: ancestors, children, dependents,
descendants, domains, exports, operations, parents, search path,
users and uses. There is also provision for examples (but
probably ATM this is broken). Logically, some of the above
are just list of constructor names (for example domains),
some list of names with conditions (ancestors), exports
essentially combines parents with operations defined in the
constructor.

Let me add that a lot of information is computed on the fly,
due to multiple views it is not practical to keep all needed
information in explicit form as a single data structure.

One can ask if all those pages are needed. Well, some taken
alone are of limited use, but availability of multiple views
adds power.

Extra thing: I think that search similar to constructor and
operation search in HyperDoc could be provided by appropriate
table of data and relativly simple Javascript code. IMO such
thing would be more useful than current Sphinx generated search.
OTOH, providing multiple views probably would require implementing
in Javascript something of complexity comparable to current
browse code.

--
Waldek Hebisch

[Martin Baker]

I use openSUSE and run FriCAS from there. I have found openSUSE to be
stable over the years and so I'm keen to continue to use it.
In October they are releasing Leap 16.0, Their website says it is
"Expected to be Wayland-only (some Xorg remnants remain for now)"
I don't know what this means but I assume it will continue to allow
programs that require X.11 to use it or have some sort of X.11 emulator?
So I am hoping that this won't affect how I use FriCAS but these low
level issues do have a nasty way of throwing up unexpected problems and
its potentially more cross platform issues.
I don't actually require x.11 in that I do not start HyperDoc from my
startup script:
./fricas1 -noht
and I do not use 2D or 3D plotting functions.
So it would be good if a startup script could be distributed with FriCAS
that does not require X.11 at all and just uses the interface to the
Terminal Console.

I understand that Waldek is combining HyperDoc and fricas io into a
separate program. In your last message you said "I think that search

similar to constructor and operation search in HyperDoc could be
provided by appropriate table of data and relativly simple Javascript

code". This raises my hope that FriCAS could be made completely
independent of these low-level and cross-platform issues. Is this correct?

Martin

[Hill Strong]

Good evening Martin,

From the discussions going on elsewhere, the move towards Wayland is intended to completely remove X11.

If you require the use of X11, it would probably be beneficial to find another Linux system as there are a number that are not moving forward with Wayland but are staying with X11.

The subject is radioactive hot at the moment so be careful and avoid the politics involved.

--
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 fricas-devel...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/6c2a5bfb-05c9-4f23-9d5b-be4528c1273c%40martinb.com.

[Waldek Hebisch]

On Thu, Jul 17, 2025 at 09:41:57AM +0100, Martin Baker wrote:
> I use openSUSE and run FriCAS from there. I have found openSUSE to be stable
> over the years and so I'm keen to continue to use it.
> In October they are releasing Leap 16.0, Their website says it is "Expected
> to be Wayland-only (some Xorg remnants remain for now)"
> I don't know what this means but I assume it will continue to allow programs
> that require X.11 to use it or have some sort of X.11 emulator?

I do not know what the above means. I use LXDE as my desktop and
IIUC like most Linux desktops it is X11 only.

> So I am hoping that this won't affect how I use FriCAS but these low level
> issues do have a nasty way of throwing up unexpected problems and its
> potentially more cross platform issues.
> I don't actually require x.11 in that I do not start HyperDoc from my
> startup script:
> ./fricas1 -noht
> and I do not use 2D or 3D plotting functions.
> So it would be good if a startup script could be distributed with FriCAS
> that does not require X.11 at all and just uses the interface to the
> Terminal Console.

Startup script works fine on machine without X11, you just get an error
message that HyperDoc can not start. And with '-nox' option there is
no error message.

> I understand that Waldek is combining HyperDoc and fricas io into a separate
> program.

No. My work is on code included in FRICASsys. That should lead
to replacing most of code in 'br-*.boot' files by Spad code.
I would like to merge the new code with API generating code.
New code supports interactive use via current HyperDoc window,
that is Spad code is able to use current HyperDoc protocol.
Ideally new code should be able to generate HTML (api2.spad
can do part of work, but needs to be merged and expanded).

> In your last message you said "I think that search similar to
> constructor and operation search in HyperDoc could be provided by
> appropriate table of data and relativly simple Javascript code". This raises
> my hope that FriCAS could be made completely independent of these low-level
> and cross-platform issues. Is this correct?

That is slightly different thing. Currently API code written
by Ralf generates .rst files from which Sphinx generate
content of API site. This process provides a search box,
but IIUC this search basically works as "full text" search
on content of API site. I would prefer more targeted search
and think that relativly simple Javascript code could provide
such search. But this concerns API site, where interaction
is only due to Javascript (which limits what can be done).
For local use I would prefer to have a Web server inside
FRICASsys and dynamicaly generate HTML pages with content
corresponding to current HyperDoc.

Note: there are many ways to provide Web server functionality.
Currently JFriCAS uses Hunchentoot, but is is likely that
much simpler things would be enough.

--
Waldek Hebisch

[Tim Daly]

Note that there is a regular expression library for Lisp, useful for search:

https://lispcookbook.github.io/cl-cookbook/regexp.html

--
You received this message because you are subscribed to a topic in the Google Groups "FriCAS - computer algebra system" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/fricas-devel/mb_O0196RMQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to fricas-devel...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/aHkHXOszicJk-EVK%40fricas.org.

[Martin Baker]

OK, thanks, its good to know the existing functionality (the parts that
I use) will still work on platforms that will be moving to Wayland.

Just for my own curiosity, can I just check I understood what you are
saying. This boot code that is being is being translated to SPAD does
the following:

library ---> database ----> Local HTML API (simple searches)
source tables
code +----------> FRICASsys ---> on-line HTML API
(complex searches)

Does the new SPAD code run on the local server or does it run in the server?

When finished, will any of this still require graphics acceleration
(X11/Wayland) on the local computer?

I don't totally understand how much of this is moving to FRICASsys,
which presumably is a university server currently running the Wiki.
Does the top set of arrows run on my local computer at compile time?

Please don't interpret my curiosity as a criticism, I think its great
that you are moving boot code to SPAD. I would just be concerned if, at
least for simple searches, too much source code and processing is hidden
in a server.

Martin

[Waldek Hebisch]

On Thu, Jul 17, 2025 at 10:48:48AM -0400, Tim Daly wrote:
> Note that there is a regular expression library for Lisp, useful for search:
> https://lispcookbook.github.io/cl-cookbook/regexp.html

Yes, I know about PCRE. PCRE is used by Hunchentoot and is included
in distributed FriCAS image.

--
Waldek Hebisch

[Qian Yun]

On 7/17/25 4:41 PM, Martin Baker wrote:
> I use openSUSE and run FriCAS from there. I have found openSUSE to be
> stable over the years and so I'm keen to continue to use it.
> In October they are releasing Leap 16.0, Their website says it is
> "Expected to be Wayland-only (some Xorg remnants remain for now)"
> I don't know what this means but I assume it will continue to allow
> programs that require X.11 to use it or have some sort of X.11 emulator?

Pretty sure it means the removal of Xorg (X11 server), but Xwayland
is remained to support X11 client programs. So HyperDoc will still
be usable.

- Best,
- Qian

[Waldek Hebisch]

On Thu, Jul 17, 2025 at 04:55:53PM +0100, Martin Baker wrote:
> OK, thanks, its good to know the existing functionality (the parts that I
> use) will still work on platforms that will be moving to Wayland.
>
> Just for my own curiosity, can I just check I understood what you are
> saying. This boot code that is being is being translated to SPAD does the
> following:
>
> library ---> database ----> Local HTML API (simple searches)
> source tables
> code +----------> FRICASsys ---> on-line HTML API
> (complex searches)
>
> Does the new SPAD code run on the local server or does it run in the server?
>
> When finished, will any of this still require graphics acceleration
> (X11/Wayland) on the local computer?
>
> I don't totally understand how much of this is moving to FRICASsys, which
> presumably is a university server currently running the Wiki.
> Does the top set of arrows run on my local computer at compile time?
>
> Please don't interpret my curiosity as a criticism, I think its great that
> you are moving boot code to SPAD. I would just be concerned if, at least for
> simple searches, too much source code and processing is hidden in a server.

You are confused. FRICASsys is main FriCAS process, it runs when you
run FriCAS. API pages are generated when you do 'make doc' or
'make localdoc', that is they are generated as part of build process,
and then used as fit, either put on a web site or accessed
locally. Anyway, API pages are generated by FRICASsys, but intent
is to do this once. HyperDoc generates pages on the fly allowing
more complex interaction. At least now my intent is to support
only local use: current HyperDoc protocol allows triggering
arbitrary computations from a request. Before allowing access
from the net it would have to be reworked quite a lot to limit
it only to allowed actions.

--
Waldek Hebisch

[Dima Pasechnik]

On Thu, Jul 17, 2025 at 10:55 AM Martin Baker <ax8...@martinb.com> wrote:
>
> OK, thanks, its good to know the existing functionality (the parts that
> I use) will still work on platforms that will be moving to Wayland.

I have a laptop running Wayland on Gentoo, and FriCAS with HyperDoc
works for me (with a Wayland compositor called Sway, but
that's probably not crucial).
A slight problem is though the graphics and fonts quality - they are
very pixelated.
In this sense FriCAS is not the only application with this issue, and
different applications require different worakrounds/tweaks to get
graphics in good quality. E.g. I have to start Firefox setting
MOZ_ENABLE_WAYLAND=1

Just in case,
Dima

> --
> 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 fricas-devel...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/aea4492e-95b9-44a0-817e-55623b0858d5%40martinb.com.

[Martin Baker]

On 18/07/2025 16:52, Waldek Hebisch wrote:
> You are confused. FRICASsys is main FriCAS process, it runs when you
> run FriCAS. API pages are generated when you do 'make doc' or
> 'make localdoc', that is they are generated as part of build process,
> and then used as fit, either put on a web site or accessed
> locally. Anyway, API pages are generated by FRICASsys, but intent
> is to do this once. HyperDoc generates pages on the fly allowing
> more complex interaction. At least now my intent is to support
> only local use: current HyperDoc protocol allows triggering
> arbitrary computations from a request. Before allowing access
> from the net it would have to be reworked quite a lot to limit
> it only to allowed actions.

Thank you, that makes it clearer, I find it hard to understand the top
level information flow without a diagram so this is my attempt:

Existing Code
-------------
build process such as make doc
library ---> database ----> .rst ---> Sphinx ---> HTML
source tables files (static web pages)
code |
v
HyperDoc -----boot
started by code
C code ^
|
.ht
file

Planned Code
-------------
build process such as make doc
library ---> database
source tables
code | |
SPAD +----------<-----------+ can javascript
code | call SPAD code?
v |
browser -----HTML ---- > Javascript --> SPAD
started by files code
user |
server for
more complex
requests

[Waldek Hebisch]

That is reasonably good approximation. Note however that HyperDoc
directly accesses .ht files, Boot code just provides links. Also,
beside .ht file there are .pht files (basicaly results of example commands)
and viewport (example graphic).

Depending on need you may wish to add extra info. For example,
HTML above references Javascript which provides search (Sphinx generates
largish Javascript table (index) which is searched by general Javascript
search routine). .rst files do not appear by magic, there is Spad code
(api.spad in doc subdirectory) which generates them.

> Planned Code
> -------------
> build process such as make doc
> library ---> database
> source tables
> code | |
> SPAD +----------<-----------+ can javascript
> code | call SPAD code?

In fact, for this part diagram should be very similar to diagram for
current code, only Sphinx stage is missing, and Spad code instead of
generating .rst goes directly to HTML. The difference is that Spad
code should differ and Javascript should differ (current Javascript
is generic one provided by Sphinx, I plan custom one tailored to our
needs).

> v |
> browser -----HTML ---- > Javascript --> SPAD
> started by files code
> user |
> server for
> more complex
> requests

If you want to write it like diagram for current code it
would be better to draw this part like:

> v
> Web browser -----Spad
> code
> ^
> |
> maybe .ht
> file

I wrote 'maybe' as translating general .ht files to HTML is a
separate effort. Note that HyperDoc can directly read .ht
files, if we want to present them in web browser we need a
translation stage.

--
Waldek Hebisch

[Waldek Hebisch]

A little progress report: I arrived at one milestone, that is
searches are mostly working without comdb.text and libdb.text.
More precisely, currently in my working version "Detailed search"
is not working and there are some broken things in other searches.
But all that works works without comdb.text and libdb.text.
There are 4324 lines of new Spad code. Spad code makes a lot of
calls to Boot code, but part of Boot code is removed. br-*.boot
files in my working version total 2357 lines. So approximately
55% of br-*boot files is replaced by Spad code. Note: currently
Boot code contains all comdb.text and libdb.text support,
partially to allow comparisons with new code, partially to
support IndexCard. If comdb.text and libdb.text support is
removed few hundreds lines more of Boot code will be gone.

Currently for operation info I use type like:

SE ==> SExpression
SY ==> Symbol
Sig_doc ==> Record(signature : SE, condition : SE, origin : SE,
documentation : String)
Op_rec ==> Record(name : SY, sdl : List(Sig_doc))
Op_lst ==> List(Op_rec)
Err_ind ==> SE
Op_res ==> Union(Op_lst, Err_ind)

Signature is like in Boot code, it is a list of types, target type
first followed by argument types. Err_ind encodes error message
in cases which may fail. I have functions like:

search_operations : String -> Op_res
operations : (Con_form, Boolean) -> Op_lst

where Con_form is just S-expression representing constructor,
boolean when true is supposed to mean that argument to constructor
are real (not just formal symbols), but ATM there is something wrong
here.

Some operation views group operations by some criteria. To
represent such grouping I have

Grp_rec ==> Record(grp_tag : SE, ops : Op_lst)
Grp_lst ==> List(Grp_rec)

where tag represets criteria, like condition, implementation or
origin. There are functions like:

group_by_origin : Op_lst -> Grp_lst
group_by_condition : Op_lst -> Grp_lst
group_by_implementation : (List(SE), Con_form, Op_lst) -> Grp_lst

There is similar set of functions for constructior, but I represent
constructors just by name (symbol) or possibly as form plus condition,
so I have

Cond_rec ==> Record(form : SE, condition : SE)
Cond_con_lst ==> List(Cond_rec)

There is a bit more, I think that types that I have are enough to
cover what in needed by HyperDoc. And I think that types and
functions are enough to provide innformation to generate API
pages.

The rest is mostly me thinking loudly.

Sig_doc above is similar to documentation in database. But
documentation does not have condition part and origin is
implicit (constructor that contains documentation is the
origin). Also, documentation misses undocumented signatures.
So to create Sig_doc-s for a constructor I merge info from
exports (derived from CONSTRUCTORCATEGORY) and documentation.

Documentation contains extra info, namely few docstings for
categores that formerly were attributes and docstings for
operations appearing in constructior signature. Docstings
for _uses_ of categores are redundant (docsting is in
definition of category), so we should probably remove
them. To explain the second issue consider:

DiscreteLogarithmPackage(M) : public == private where
M : Join(Monoid, Finite) with
"^": (%,Integer) -> %
++ x ^ n returns x raised to the integer power n
public ==> with
...

Type of M contains anonymous category and operations from this
category may have docstrings. Trouble is that those docstrings
are mixed with docstrings for normal operations. It seems that
we should either do not store them at all or store them
separately from other docstring. Also, several such
docstrings just say "undocumented", so add no info.

Currently docstring for constructor is provided as
documentation for fictional operation called 'constructor'.
More sensible probably would be record like:

Record(con_doc : String, extra_docs : List(Sig_doc),
op_docs : List(Sig_doc))

and having empty string for cases where there is no documentation.

Currently creating operation list from database info takes about
0.5 second on a slow machine, most of which is reading database
info. Once operation list is created it can be used for many
searches. Also, once database info is in core creating operation
list is much faster. For comparison, creating operation list
in the same format from comdb.text and libdb.text takes about
3 seconds on the same machine. Significant part of this goes
into parsing various expressions using interpreter parser
(which is slower than Lisp parser used to read database info).
Old code avoided this cost for most searches keeping database
info in string form and converting only search results (which
usually are much smaller than whole list of operations).

For searching I currently use 'superMatch?' from match.boot,
it seem to work correctly and speed seem to be OK for most
searches. But documentation searches seem to be slow,
so we probably need faster search engine.

Currently the only user of comdb.text and libdb.tex is
IndexCard and related database in 'alql.spad'. I am
not sure what to do with this. In principle we could
create strings on the fly form other info, but that
means keeping code which is not needed for other purpose.
We could modify IndexCard to internally use representaion
like used for searches. But exposing S-expression in
user interface is not exactly nice, an having convertion
to strings means keeping extra code. We could entirely
remove IndexCard. I am not sure if anybody uses it,
but it is mentioned in FriCAS book, so removal of
IndexCard would mean removing or rewritning corresponding
part.

Another thing is size of code. Spad code is clearly bigger
than Boot code which is replaced. Part of it is due to
type declarations which take some space. Part is because
Boot uses pattern matching and I work with SExpression,
so I use lower level operations nad need more code.
Part is forced near duplication of code: Boot takes
advantage of lack ot type checking and uses the same
routine for various kinds of data. New routines are
typed and type discipline forces using different functions
for different types, even if work to do is quite similar.

Currently I work on browser functionality, that is replacement
for most of br-*.boot files. There are also "demo" files:
bc-matrix.boot, bc-misc.boot, bc-solve.boot; and interface
to view and set system variables, which is in htsetvar.boot.
I would like to preserve demos, OTOH code there in large
part is content of pages encoded as S-expression. This
encoding have some advantages, but currentlty do not
translate in reasonable way to Spad. To a smaller
degree similar issue affects htsetvar.boot.

--
Waldek Hebisch