Ralf Hemmecke wrote:
>
> On 02/21/2016 11:31 PM, Waldek Hebisch wrote:
> >> Is there any chance that fricas will be able to pass commandline
> >> arguments to AXIOMsys?
> >
> > From one point of view this is relatively small change.
> > But there are drawbacks: each Lisp has its own command
> > line arguments, so it non-portable between Lisps. Also,
> > FriCAS depends on some specific settings, when users try
> > to change such setting it willl either be ignored or
> > interfere with FriCAS work.
>
> I probably don't have a clear view on what must be changed, but I see
> AXIOMsys called from the fricas shell script. Would it be too hard to
> move the (currently) hardcoded parameters into that script? Maybe that
> shell script would have to be generated so that for different underlying
> lisps we have different fricas scripts. Similar for other places that
> call AXIOMsys.
Maybe I should say differently what I wrote above: in general
I prefer to povide general mechanizm. However, in case of
command line there are only few things that can be useful
and it is better to _not provide_ the other. Specifically,
ability to make other changes is on the cost side.
Now, there are few parameters that can only be set via
option mechanizm. In particular, dynamic space size
in sbcl. As I wrote, we have the following possibilities:
- hardcode options in AXIOMsys, this allows specifying
options at build time but means that it is impossible
to change tham at runtime
- respect runtime argument to AXIOMsys
In the second case in principle we could put default value
in fricas script at build time so that we would have a sane
defult and ability to override it at runtime. Now come
question of effort: at first glance it is relatively small:
- undo Martin's change from 2009-10-28
- modify sman to pass appropriate option to AXIOMsys
- modify fricas script to recoginze and pass appropriate
option to sman
- modify makefile to hardcode default in fricas script
Now, the main cost is that scripts and makefiles are error
prone: "obvious" change can backfire on different system
(like recent problem with Windows paths). And unfourtunately,
testing build system is time-consuming: a single build is
a single test, while thorough testing need a lot of tests.
So I last few years I tried to be consevative with build
system. Of course, this should not stop us from making
improvements. However, in case of sbcl dynamic space size
cost-benefts ratio is unclear:
- IME building sbcl (using already installed sbcl) was
easy. Basically you follow simple instruction and
it works.
- For useres who do not want to build anything we provide
FriCAS binary. IIRC this binary has dynamic space size
at old default, that is 8GB on x86_64.
- it is currently possible to specify dynamic space size
at FriCAS build time.
--
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 post to this group, send email to fricas-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/fricas-devel.
For more options, visit https://groups.google.com/d/optout.
