On 13 April 2024 02:38:34 CEST, Hill Strong <[email protected]> wrote:
>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.
But that's what ECL is doing, compiling to C and then calling a C compiler?
Would it be more useful to figure out why the resulting FriCAS runs
considerably slower than the one built using SBCL ?
Dima
>
>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/AA56A632-E864-49D0-BA9C-31AE14C76F91%40gmail.com.
