One of the reasons that started me looking at a non-Lisp base was the
fundamental use of lists in the Boot implementation. Within Icon (or in my
case using the Unicon system), lists are implemented in such a way that
accessing any element was much faster than via a cons cell. You could treat
a
On 13 April 2024 02:38:34 CEST, Hill Strong 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
On Sat, Apr 13, 2024 at 10:38:34AM +1000, Hill Strong 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.
On Fri, Apr 12, 2024 at 08:41:18AM +0100, Martin Baker wrote:
> I don't mind, I have given up with this software now.
>
> When I wrote the code I was hoping that this approach would replace old
> boot and C code with something much more maintainable and flexible. Also
> the scenegraph
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
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
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
Unfortunately, I have not much experience with graphics code and not yet
much need of using some, however, I would really like to be able to
create nice looking graphics easily with FriCAS, be it via SPAD code or
via external libraries. In particular in connection with jFriCAS, the
old graphics
I don't mind, I have given up with this software now.
When I wrote the code I was hoping that this approach would replace old
boot and C code with something much more maintainable and flexible. Also
the scenegraph architecture makes it much easier to export to 2D and 3D
graphics files like SVG
scene.spad contains several operators marked as deprecated. In
about 8 years there were no siginficant changes to scene.spad.
I think that there is time to either remove the depreciated
operations or decide that thay should stay indefinitely and
remove depreciacation notice.
--
10 matches
Mail list logo
