On Sun, Dec 22, 2024 at 08:02:17PM +0700, Ignat Insarov wrote:
>
> > 'jfricas' currently is not packaged, so this is not an issue.
>
> I installed `jfricas` using `pip`. Does `pip` count as a package manager?
Right, I forgot about this. I was thinking about package containing
FriCAS and 'jfricas'. FriCAS is unlikely to be packaged as a pip
package in reasonable future, so what remains are various distributions.
AFAIK none currently provides FriCAS + jfricas, but hopefully this
will change.
> > > How FriCAS and jFriCAS should be configured is of course an
> > > architectural decision that requires deep understanding of the code
> > > and the use cases that need to be handled, so I cannot be of much help
> > > here. If I may suggest something, I should say there should be one
> > > place where everything may be configured. Right now there are at least
> > > four places — build configuration, command line flags, Python source
> > > code and the start-up profile file. This complexity seems needless to
> > > me.
> >
> > Part of this is thechnical neccesity (or maybe technical simplicity):
> > build configuration specifies info needed to compile FriCAS and some
> > hardcoded defaults. It is not possible to do this later: without
> > proper info build may fail and hardcoded things can not be changed
> > later. Command line flags are easily changable things which users
> > may wish to change. For technical reasons FriCAS user init file can
> > not be run very early, so it can not change some things which are
> > changable on command line.
> >
> > You skipped enviroment variables: they affect what FriCAS is
> > doing. Build configuration, command line options, enviroment
> > variables and init file are normal mechanisms used by many
> > other programs. In FriCAS some small important parts are source
> > code, so changing them allows users to do changes that would
> > be hard otherwise. Certainly, we aim that commonly requested
> > changes of behaviour could be done by one of earlier mechanisms.
> > But modifying source fragments is useful way to do unexpected
> > modifications.
>
> What I meant to say is this:
>
> * If there are many ways I can configure a program, this is good.
> * If there are many ways I am forced to use all at once in order to
> configure a program, this is bad.
>
> In my Jupyter FriCAS setup quest, I had to use a few different ways of
> configuration, from command line flags to patching source code. This
> was not great experience — in truth, this is the first time I had to
> be so creative setting up a program _for a standard use case_ since
> the times I had Slackware on my Pentium Pro.
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.
And AFAUI need for patching was because you choose non-standard
way to buid FriCAS (due to confusion over hsbcl-1.3.9.tar) and
due to your dislike for 'xterm' and HyperDoc (which is standard
way of use).
Comparing with other programs, if you want non-standard build,
you need to run configure before build, that is simple casuality
principle (you can not change past from the future). I normally
use command line options, so I noticed a bunch of programs where
I had to use environment variables or a config file. I think
it is quite common that you can do some things only via command
line options.
I guess that we may differ here in 'what configure program' means.
I consider options to FriCAS program as changing what FriCAS
is doing, in similar way to say 'ls' program.
> > For technical reasons FriCAS user init file can
> > not be run very early, so it can not change some things which are
> > changable on command line.
>
> This is odd. Would you be willing to summarize in a few words why this
> is a hard problem? As I understand, FriCAS currently reads
> `~/.fricas.input` and I guess it needs to first start its Lisp
> interpreter up.
'.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'.
> 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.
> 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.
--
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 fricas-devel+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/fricas-devel/Z2haF8_WPZT_lspM%40fricas.org.
