There is nothing to stop anyone from breaking the requirement of using any Lisp as the destination for Boot code. I translated one section of Boot code directly into Icon. Of course there is much in Boot than assumes Lisp lists. But that is not an impossible task to change.
You could then use the iconc compiler to transform the icon code to C and compile to machine code. I have not continued that development as I am much more interested in changing the Spad language to be a more consistent block structured language, including adding in static environmental structures ala ALGOL and it's descendents. On Sat, 13 Apr 2024, 6:05 am Ralf Hemmecke, <[email protected]> wrote: > > > 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 > . > -- 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/CAEnaMTGnWqG%3D28Oyedvk57sPRjDnfXng0_yqCc0gf3YNf8PG4g%40mail.gmail.com.
