Guys,
While that Gambit makes platform-independent C code is great, isn't something related we could give attention to more about Gambit, that it has no required dependencies, or how is it?
Thinking about it and browsing through ./configure's code I can't see any.
I think I noticed it's quite common among Scheme implementations to require quite many dependencies, sometimes even for as central stuff as garbage collection, and obviously there needs to be architectural and performance benefits of making these things customized in one piece, as well as saving some resources and making deployment in any kind of unusual environment exponentially easier, thus giving weight to the identification of the software as 'system software'.
There are indeed many times when users quite strongly intuitively prefer slimmer internal software designs that have no effect on how UI:s actually look. Things like load time, UI latency, the direct and indirect effects of CPU and RAM consumption such as RAM fragmentation, and grade of leaky abstractions causing arbitrary small and big errors during installation and runtime would be typical such things, in my understanding. This kind of contrast ought also to be reflected in the very strong enthusiasm found regarding certain computer manufacturers.
The only thing even close to a dep I could think of as being relevant for Gambit would be optional bindings for libgmp even though it has a somewhat weird license, now that Brad has been clear that there's so much differentiated algorithms and architecture-specific custom-written assembly in there that it not is feasible to maintain top-notch bignum functionality on a per-language-implementation basis today. Libgmp's interface in it's present state is averse to deep integration though, in the respect that all of its small memory allocations are immovable, so working through its sourcecode and resolving that would be of big benefit for actually taking it in use. In all cases Gambit's built-in bignum library will always be of use as it's neat in all ways.
Now, which are the deps - C compiler is optional, and file/process/OS thread/time/network handling is OS-internal so those are not deps. Are there any deps at all?
Any thoughts?
Brgds, Mikael
Afficher les réponses par date
On 2012-11-20, at 11:49 AM, Mikael mikael.rcv@gmail.com wrote:
Guys,
While that Gambit makes platform-independent C code is great, isn't something related we could give attention to more about Gambit, that it has no required dependencies, or how is it?
Thinking about it and browsing through ./configure's code I can't see any.
I think I noticed it's quite common among Scheme implementations to require quite many dependencies, sometimes even for as central stuff as garbage collection, and obviously there needs to be architectural and performance benefits of making these things customized in one piece, as well as saving some resources and making deployment in any kind of unusual environment exponentially easier, thus giving weight to the identification of the software as 'system software'.
There are indeed many times when users quite strongly intuitively prefer slimmer internal software designs that have no effect on how UI:s actually look. Things like load time, UI latency, the direct and indirect effects of CPU and RAM consumption such as RAM fragmentation, and grade of leaky abstractions causing arbitrary small and big errors during installation and runtime would be typical such things, in my understanding. This kind of contrast ought also to be reflected in the very strong enthusiasm found regarding certain computer manufacturers.
The only thing even close to a dep I could think of as being relevant for Gambit would be optional bindings for libgmp even though it has a somewhat weird license, now that Brad has been clear that there's so much differentiated algorithms and architecture-specific custom-written assembly in there that it not is feasible to maintain top-notch bignum functionality on a per-language-implementation basis today. Libgmp's interface in it's present state is averse to deep integration though, in the respect that all of its small memory allocations are immovable, so working through its sourcecode and resolving that would be of big benefit for actually taking it in use. In all cases Gambit's built-in bignum library will always be of use as it's neat in all ways.
Now, which are the deps - C compiler is optional, and file/process/OS thread/time/network handling is OS-internal so those are not deps. Are there any deps at all?
Any thoughts?
Gambit has been designed to have as few dependencies as possible. It only needs a few basic things from the C library (such as malloc and setjmp) to get a working system. If the operating system isn't Posix or Windows, it will resort to stdio to do I/O. Obviously, in such a situation, many of the fancier features (TCP ports, process ports, etc) will not be available.
The lack of dependencies it what allows Gambit to build easily on embedded systems (Nintendo DS, Xilinx FPGA, etc).
Marc
This is just great and a huge reason to use Gambit in itself really.
Thank you - with wishes of a
Happy New Year to all the Gambit community! :-)
Mikael
2013/1/2 Marc Feeley feeley@iro.umontreal.ca
On 2012-11-20, at 11:49 AM, Mikael mikael.rcv@gmail.com wrote:
Guys,
While that Gambit makes platform-independent C code is great, isn't
something related we could give attention to more about Gambit, that it has no required dependencies, or how is it?
Thinking about it and browsing through ./configure's code I can't see
any.
I think I noticed it's quite common among Scheme implementations to
require quite many dependencies, sometimes even for as central stuff as garbage collection, and obviously there needs to be architectural and performance benefits of making these things customized in one piece, as well as saving some resources and making deployment in any kind of unusual environment exponentially easier, thus giving weight to the identification of the software as 'system software'.
There are indeed many times when users quite strongly intuitively prefer
slimmer internal software designs that have no effect on how UI:s actually look. Things like load time, UI latency, the direct and indirect effects of CPU and RAM consumption such as RAM fragmentation, and grade of leaky abstractions causing arbitrary small and big errors during installation and runtime would be typical such things, in my understanding. This kind of contrast ought also to be reflected in the very strong enthusiasm found regarding certain computer manufacturers.
The only thing even close to a dep I could think of as being relevant
for Gambit would be optional bindings for libgmp even though it has a somewhat weird license, now that Brad has been clear that there's so much differentiated algorithms and architecture-specific custom-written assembly in there that it not is feasible to maintain top-notch bignum functionality on a per-language-implementation basis today. Libgmp's interface in it's present state is averse to deep integration though, in the respect that all of its small memory allocations are immovable, so working through its sourcecode and resolving that would be of big benefit for actually taking it in use. In all cases Gambit's built-in bignum library will always be of use as it's neat in all ways.
Now, which are the deps - C compiler is optional, and file/process/OS
thread/time/network handling is OS-internal so those are not deps. Are there any deps at all?
Any thoughts?
Gambit has been designed to have as few dependencies as possible. It only needs a few basic things from the C library (such as malloc and setjmp) to get a working system. If the operating system isn't Posix or Windows, it will resort to stdio to do I/O. Obviously, in such a situation, many of the fancier features (TCP ports, process ports, etc) will not be available.
The lack of dependencies it what allows Gambit to build easily on embedded systems (Nintendo DS, Xilinx FPGA, etc).
Marc
-
Marc Feeley -
Mikael