On 4/12/24 16:20, Martin Baker wrote:
On 12/04/2024 09:23, Ralf Hemmecke wrote:
I do not understand why you think that not both graphics systems
can live besides each other (as they do now)?
Well, I think that the interactive graphics should work seamlessly
with the things that scene.spad can do such as outputting to various
file formats and having much more control over the output. For all
this to work together without duplication it all needs to be written
in SPAD.
So, yes. If I were you, I would simply ignore the existing graphics
system and provide all the features that *you* think would be great and
help you in your work. That would inclulde connecting (or writing from
scratch) an interactive graphics system in SPAD. Why would you care what
Waldek or anybody else who has write access to the FriCAS repo says? You
can put everything into your own repo and try to promote it to users.
If your system is superior, it will at some point be seen and more users
will ask to properly include it into FriCAS.
Clearly, nobody can assume that his/her code will be included into the
"official" code base. But with open source it is terribly easy to create
your own fork and show that your stuff is better. Yes, with forking
comes maintenance and other costs, so one must decide whether to fork,
fight with the maintainers for inclusion or simply abandon the project.
It's not an easy taskt to make the world a better place.
The problem is interactive graphics require multi-threading and I
can't see anyone agreeing to a limitation that SPAD can only work on
top of some specialised lisp with multi-threading. I suspect that is
the reason for the C code to allow multi-threading.
Hmmm... strangely enough we have jFriCAS, it was easier if FriCAS is
compiled with a lisp that has a webserver built-in. And, in fact,
jFriCAS is only properly working with SBCL (at least I haven't tested
with other lisps).
What I want to say is that your interactive graphics system can work on
a certain type of lisp. It just means that by default FriCAS provides
the old graphics system and your features would require the users to
compile with a specific lisp. Why should that be a problem. Your
graphics system would be optional and whether to compile it or not is
only a configure option away. That would reduce maintenance cost for
anybody else except you. You then must show that you are interested and
prove it by maintaining your code and fixing bugs.
Maybe Waldek would still be against, but having a better interactive
graphics system would get support from me for its includion as an
(optional) add-on.
People usually suggest using their favorite 3rd party graphical
front end but I can't see Waldek making FriCAS totally reliant on
some 3rd party software.
Yes, that is dangerous. But allowing users to decide, is another.
Another problem is that graphic interfaces, hardware, file formats
change rapidly and these interfaces need more maintainable code.
Yes, of course, some people like old code more since they are used to it
and know how it works, the younger generation probably want newer system
and newer code. And surely, knowing all the newer graphics systems I
would be unwilling to support any weird old stuff and fight for
inclusion of newer technology. That's not a bad thing.
For example will FriCAS support X11 to wayland transition?
Well, there are only two options. 1) It will. 2) FriCAS will lose it's
graphics capabilities. Which one would you choose if you were a
maintainer of FriCAS?
Ralf
--
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/4df02ef4-1b24-42f1-a68c-3cb122a162f8%40hemmecke.org.
