> Well, actually not so standard use case. jfricas exists for some
> years, but initially it was very experimental with small number
> of users. There are now more users and it will take some time
> to make things easier and smoother.
I see. I think integrating FriCAS with Jupyter by setting up an HTTP
API was a great step forward.
> And AFAUI need for patching was because you choose non-standard
> way to buid FriCAS (due to confusion over hsbcl-1.3.9.tar) …
Can you say someone _«chose»_ something when they had no visible
alternative? There was no link to `hsbcl-1.3.9.tar` in sight and I
could not find it among release assets on GitHub _(because it was not
there for the latest version of FriCAS)_ — I had to do what I did.
> … and
> due to your dislike for 'xterm' and HyperDoc (which is standard
> way of use).
It is not that I do not like `xterm` and HyperDoc. I do not use any of
these tools for the fun of it. I have a goal that I need to accomplish
with the highest possible efficiency.
The way you are describing my inner world — _«choose a non-standard
way»_, _«your dislike»_ — makes it seem that this is a fancy. Making
such assumptions is not the right way to understand your users. One
good way to understand your users is by doing field research. Ask
people what their favourite terminal emulator is, or better even
observe what terminal emulator they use in their daily work. I expect
it will not be `xterm` — but I may be wrong!
> '.fricas.input' is in FriCAS language and is read by main
> FriCAS binary, that is FRICASsys. '.fricas.input' is doing
> things that in principle could be done by user commands at
> FriCAS prompt, so in principle it is just a convenience
> feature. There is some subtlety, as .fricas.input' runs
> at time when user environment is not fully initialized,
> but it is a reasonable.
>
> Things like '-noht' option are handled by other parts of FriCAS,
> that is 'fricas' shell script and 'sman' binary. Basically,
> before FRICASsys starts it is already decided if HyperDoc
> will be used or not.
>
> Similar for graphic and other options like 'nosman'.
I see. I had no idea `fricas` is a shell script, and a non-trivial one.
> > Maybe this is what needs to be changed. Say there was
> > another file `~/.fricasrc` that is not written in Lisp or Spad but
> > rather in some simple configuration language like Ini, Yaml or Toml.
> > This file would hold settings mirroring command line options. Is this
> > a good idea?
>
> There are already _many_ ways to provide changed command line options
> and FriCAS has only a few of options. It is not clear to me if such
> a config file add any value.
This is a vicious circle. If adding new settings is hard, people will
not add new settings so there will always be only a few.
An example of something that should be a setting is the name of the
terminal emulator that HyperDoc should open when it needs one.
> > I do not have much experience maintaining programs with many options
> > and ways of configuration, but my limited experience tells me that
> > usually on start-up a program would read configuration files,
> > environment variables and command line options all into one structure,
> > in this order, overwriting fields as needed. This makes sure that
> > exactly the same set of configurations can be accomplished in whatever
> > way the user is comfortable with.
>
> Well, first such a program must check if the user gave an option
> to use alternative configuration file (the only option for some
> programs). So logic is a bit more complicated. In FriCAS case,
> there are several binaries, with "entry point" being a shell
> script. One attraction of this shell script is that is small and
> easily changeable (we automatically modify it at install time).
> Putting here code to handle config files is rather unattractive.
I agree: if having a command line flag that changes the path to the
settings file is a requirement, then you need a less straightforward
way to handle settings. There is any number of ways in which
configuration logic may need to be complex. Highly configurable
programs, like some compilers and build systems I have been working
with, have hundreds of settings and thousands of lines of code
dedicated to configuration. What I offered is a simple semantics that
I believe would be easy to understand by the users.
One way you can handle the command line flag that changes the path to
the settings file is by splitting configuration into stages.
* Every stage is defined by a record with all fields optional.
* A stage record may have a field that refers to another, later stage.
* An unset field that refers to another stage is equivalent to a field
that refers to that stage with all its fields unset.
This way, earlier stages of execution do not need to be aware of the
complexities of the later stages. For example, the start-up script
does not need to be aware of Lisp and Spad, who are free to have any
number of settings of their own.
Observe also that records with all fields optional canonically have a
monoid structure. It is derived from the trivial _«update»_ semigroup
defined by ∀ x y. x ◇ y = y by adding a formal identity element and
computing pointwise.
The formula for the first stage will now be:
defaults ◇ command line options
— And for a later stage it will be:
defaults ◇ configuration file ◇ command line options
You can make these formulæ as complicated as you wish by adding
environment variables or whatever other sources of information there
may be.
I have seen this approach used in industrial programs of great
complexity — it works great.
I agree also that a shell script is not suitable to implement this
logic. This is where sound architectural decisions need to be made —
by someone wiser than me.
--
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/CAB-2Q0_pQozyrEHq9SX1fBZ-P3qvYgpAEX3YXH7n8ypzci%3DH%2BQ%40mail.gmail.com.
