> I probably was not clear enough in what I wrote: my intent is to
> handle output via Spad code. For compatibility, want program logic
> to be close to current 'i-output.boot'. In particular whan I wrote
> "records" I meant Spad Record (doing records in Boot is ugly). I
> want to keep ')set output ...' but Boot code implementing this should
> call Spad code for real work.
OK, that makes it a bit clearer, but let me dream a bit.
I would not do it the way you describe. Rather, there should be a couple
of boot functions that can be called from Spad code.
The "formatter register domain" for the "record" you mentioned above,
would be a good idea.
This registry is filled at fricas start or even filled by hardcoding
with the existing formatters that are in the FriCAS code repository.
At runtime other formatters can be added.
Switching session output on/off or redirecting to a file is done via
)set output ...
and maybe other SPAD means.
So we need a BOOT function, that does the stuff that one currently has
to hardcode into servart.boot, setvars.boot and i-output.boot, i.e.,
(1) creation of a lisp stream
(2) creation of the setOutputXXX function
(3) creation of the describtOuputXXX function
(4) registering it in the "Table $setOptions".
Oh, but that would have the "record" in Lisp $setOptions and still all
the logic of handling ")set output ...".
Why not giving up ")set output"? Then from the Lisp/Boot side there
would be needed a function
(1) to create a lisp stream, open and close it or redirect it to a file.
That stream would be stored in a SPAD "FormatterRegistry" domain. And
all the rest would be done in SPAD. At registry time the Formatter
learns about where to actually send his output. Quite a couple of Boot
lines can be replaced by SPAD logic.
Only relying on the creation of a stream might also bring us closer to a
output logic similar to what TextWriter in Aldor does.
What do you think?
>> My first intention was to improve the TexFormat domain to be able
>> to compile book.pdf, but it ended in a compleltely different
>> approach of handling the OutputForm structure which in turn made it
>> relatively easy to come up with FormatMathJax, Format1D, and
>> Format2D. Maybe some day I spend some time to also put Texmacs and
>> MathML formats into my scheme. However, since I do not use those
>> much, it may need some users to push me.
>
> I admit that I do not see why you felt need for different structure.
> AFAICS old structure can handle what you are doing and code size seem
> to be comparable.
Well. Of course, there was no "need", but it happened that way for the
LaTeX formatter, because I wanted to give the user flexibility over what
latex commands are output (therefore this (changable) hashtable for each
OutputForm toplevel operator). It proved wonderfully easy to do the
other formatters in the same way.
Furthermore now it is also easy to modify OutputFormat and adapt the
formatters.
Additionally, my formatters do not know about output. They just
translate OuputForm into a String.
> No big problem. But getting code to work means that one has to work
> out various little problems. More specifically, I would like to have
> single output manager. I want this manager to be compatible with
> current use and support ')set' commands. Note: I am not against
> having alternative setup interface, but alternative should integrate
> cleanly with ')set' commands.
OK, we can have ")set output ..." and ONE manager.
I would also have to goal to get rid of some Boot code. If this means
abandoning ")set output", would not bother me too much.
You probably will program such a manager. But please do it at a branch
so that I can see the code while you work and we can discuss where I see
problems integrating my formatters.
Actually, we should also discuss for what such a manager should actually
work. We have
FortranFormat
HTMLFormat
MathMLFormat
TexFormat
TexmacsFormat
(OpenMath?)
TexFormat and HTMLFormat can be removed. They are buggy.
TexmacsFormat and MathML format can probably easily done in my framework.
So it remains FortranFormat and the 2D Algebra format from i-output.boot.
> Clearly, output manager should support what is needed by JFriCAS.
Thanks. If we coordinate, it is also possible to adjust jFriCAS to work
nicely together with what FriCAS provides. At the time it was released,
I had to take what was there. Convergence would be good.
> I admit that you surprised me by use of multiple formats -- I assumed
> that JFriCAS will just use single format.
No. As you probably noticed, when MathJax renders the output, it costs
usually quite some time. So people might want to switch to ordinary
ASCII-2D format. And maybe some day this slowness of MathJax might bring
me program FormatMathML.
> Concerning use of single stream versus multiple streams: at low level
> we want single stream. HyperDoc shows that with multiple low level
> streams one get various synchronization problems. Such problems do
> not appear when using single low level stream. At higer level you
> clearly want multiple streams: the purpose of markers that you emit
> is to allow demultiplexing single low level stream into multiple
> logical streams.
> Now, textual markers are simple but rather poor method of
> demultiplexing.
OK. But I must admit, that usage of markers for demultiplexing appeared
only in the last moment when I realised the problem with the order of
output for multi-command input.
> For HyperDoc I plan to use simple binary scheme, using messages.
Actually, I do not understand why you stick to HyperDoc. I cannot use
it, because on my 4K-display its contents is unreadably small.
Tutorials can be done with jFriCAS and published over the web or
provided with a FriCAS release.
The only thing that is not yet available otherwise is to find out by
which domain/package a certain function is implemented. I'm sure that
HyperDoc functionality can be brought into a package such that
implementedBy("func $ SomeDomain(X, Y)")
returns the actual constructor where the source code for "func" can be
found. I just don't know where exactly I find this HyperDoc
functionality in order to write such an "implementedBy" function.
Anyway, wouldn't it make sense to work towards removing HyperDoc,
replacing the graphics framework by something more modern and eventually
even remove sman and only have a single lisp image FRICASsys?
That would look like a goal.
> Anyway, concerning JFriCASSupport: for current use it may be
> included. However, I expect that it will need substantial changes
> (or possibly vanish) in near future.
OK. Thanks. I will first try to use it in action. I already realized
that it is not exposed so instead of
setFormat! FormatMathJax
I must call
setFormat!(FormatMathJax)$JFriCASSupport
still OK, but a bit cumbersome.
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/6ba8da0d-91e3-4180-8f4b-1cf83dc3296a%40hemmecke.org.
