On Sun, Apr 07, 2024 at 08:28:20PM +0800, Qian Yun wrote:
>
>
> On 4/7/24 08:21, Waldek Hebisch wrote:
> >
> > I admit that my long term plan is somewhat different: to do
> > substantial developements at Spad level. That means for example
>
> I agree with this long term goal.
<snip>
> On this subject, I find that you can call Spad function from Boot.
> I wonder if i-output.boot is a good target to port to Spad first.
It is reasonably good target. The problem as of today is that
code in 'i-output.boot' is our most robust formatter and
ideally replacement would more robust. Ralf have written
a few formatters and Format2D in most cases works fine.
But robustness is about remaining cases. Also, Ralf uses
different way to control formatters. ATM it is not clear
to me how to hook his formatter so that it presents control
interface like earlier formatters _and_ works like Ralf want
it to work...
There are other possible targets. I mentioned 'sfsfun.boot'.
It is code that really should have been written in Spad and
at first glance convertion would be quite easy. Except for
fact that code in 'sfsfun.boot' refuses to work for some
reasonable arguments and for some arguments has significant
errors. I do not want just to convert troubles to Spad,
so this waits for resolution of numeric problems (I wrote
more about this in another mail). Now I have good replacement
for about 75% of functionality in 'sfsfun.boot', but remaining
part is harder...
Just now I am looking at HyperDoc. There are aspect which
may cause serious trouble, OTOH logically this code is
independent from the rest of interpreter. And in principle
significant part of HyperDoc support could be common with
other front ends.
> > Some sharing is undesirable, but IMO to avoid massive code
> > duplication we should have significant code sharing between
> > subsystems. Which IMO means that trying to divide this between
> > directories is mostly futile
>
> I'm not talking adding new sub-directories. What I meant is to
> extract commonly used functionality into new files.
I see. For me it is convenient to keep origial code exactly
where it was in NAG sources, that way it is easy to compare
and know if bugs were in original code or are due to our
modificatinos. Of course, once code is substantially changed
or rewritten, this no longer applies. Another thing is that
I am trying to keep number of files at mangable level. So
one or few new files are fine, but I would like to avoid
having many tiny files.
> >
> > Coming back to your specific question, we can add new file
> > for utility type routines, but I do not expect such file to
> > get big and I prefer to keep 'src/interp' as a flat directory.
> >
>
> I'll modify "dbReadLines" in-place then. And I'll come up with
> a list of functions that should exist in this new file "util.boot".
Probably 'n_util.boot'. 'util.boot' would lead to 'util.fasl' which
conflicts with 'util.fasl' from 'util.boot'.
--
Waldek Hebisch
--
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/ZhRSXAA-rvVFceh4%40fricas.org.
