The function showdatabase might be useful. -- Tim
On Wednesday, June 11, 2025 at 5:18:59 PM UTC-4 p.broadb...@googlemail.com wrote: > 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 > > On Wed, 11 Jun 2025 at 19:59, 'Ralf Hemmecke' via FriCAS - computer > algebra system <fricas...@googlegroups.com> wrote: > > > > 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 > > > > -- > > 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 > . > -- 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+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/de85c5c2-8dcb-4368-890b-397595769f5dn%40googlegroups.com.
