Thank you for your detailed answer, Waldek! > > As a first step, I can offer a general suggestion. Surely you have a > > family member or a friend who is digitally literate but not familiar > > with Common Lisp and FriCAS. Ask them to set up a FriCAS Jupyter > > notebook and watch. Will they even be able to find the installation > > guide? It is not linked to from the table of contents! This method is > > called «usability testing» and you can find more details, for example, > > in the book _About Face 3_, chapter 4. > > Well, for me this is not a workable proposal: FriCAS is really > for people interested in/needing mathematics, and my family have > no such interest.
They have interest in you! Ask them to set up a FriCAS Jupyter notebook as a favour. Purchase their interest with an offering of their favourite snack. Do not give up so easily! > > Whence do I get this `hsbcl-1.3.9.tar`? > > In FriCAS distribution area: … > > It may be confusing that this tarball is in subdriectory for > release 1.3.9, but this code did not change between FriCAS > releases. I believe this is indeed confusing. But you do not need to trust me — you can do usability testing and reveal the truth. What is important here is the mindset of reducing friction to the minimum. Ideally you want to provide a guide detailed enough that no other documents need to be consulted. If you want to make the case that the documentation already available is enough to solve the problem — I agree, the totality of information already available on the Internet was enough for me to solve the problem. The question is — how long it takes. Every recourse to other documents takes time, and open-ended search takes unbounded time. > > … I think this is a situation that calls for a configuration file. … > > … Linux distributions have > various policies with respect to such files, so I am not > sure what we (that is FriCAS project) should do. … I am not an expert on this, but my experience tells me people tend to follow this standard: https://specifications.freedesktop.org/basedir-spec/latest/ If you want to offer a _«retro»_, _«classic»_, _«old school»_ feel, you can put configuration in `~/.jfricasrc` or something like that. Anything would be better than editing source files. > Using FriCAS is essentially writing source code in FriCAS > language (maybe line by line, but still). I hope that > people are not intimidated by this. I believe the experiences of typing commands to an interpreter and of editing source files you have no understanding of are very different. You do not need to believe me — you can do some ethnographic research. Ask your friends: * how often they use a command line interpreter of one kind or another * how often they edit configuration files * how often they configure their tools by hacking on the source code > 'jfricas' currently is not packaged, so this is not an issue. I installed `jfricas` using `pip`. Does `pip` count as a package manager? > > 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. > 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. 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? 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. -- 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 visit https://groups.google.com/d/msgid/fricas-devel/CAB-2Q0_K%2BCe04myQ5phX%2BZ2fLgzxPS3T38ZN3VA4sv9u6Tp%3Ddg%40mail.gmail.com.
