[gambit-list] Re: How to create small standalone executable with Gambit-C?

peter lo peter19852001 at yahoo.com.hk
Mon Aug 17 23:32:28 EDT 2009


I agree that on modern systems size is not that important anymore, but it is unpleasant to have an executable of serveral MBs when you know that the same program written in another language will be only a few hundred KBs. 


> On the other hand, it would be welcome to have a flavor of Gambit
> which is less expressive. I do not know how burdensome it would be to
> be able to prune whole parts of gambit to create "non
> development-ready" applications (that is, once the final product is to
> be delivered, compile it with a version of gambit which does not embed
> the whole runtime, does not allow debugging, etc).
> Or, maybe, allow the user to explicitely tell what he needs to import

I support this idea. As I have suggested in a previous mail, we should aim at making Gambit-C as modular as possible.
For example, the system may be a bunch of modules:
    -- basic runtime
    -- numbers
    -- full numeric tower support
    -- characters and strings
    -- various data structures like hash table, vectors,...
    -- networking
    -- SRF1
    -- SRF2
   and so on

The above partition of the modules is only a random suggestion, but you get the idea. With such a system, only the relevant parts get into the final program, so we pay for only when we need.

Regards,
Peter



----- 郵件原件 ----
寄件人﹕ Adrien Piérard <pierarda at iro.umontreal.ca>
收件人 peter lo <peter19852001 at yahoo.com.hk>
副本(CC) Bradley Lucier <lucier at math.purdue.edu>; Gambit Mailing List <gambit-list at iro.umontreal.ca>
傳送日期﹕ 2009 年 8月 18 日 星期二 上午 11:01:24
主題: Re: [gambit-list] Re: Re: How to create small standalone executable with Gambit-C?

2009/8/18 peter lo <peter19852001 at yahoo.com.hk>:
> and honestly when we intend to distribute executables, we do not want to leave out users using Windows.)?

It hurts me to say that, but size really isn't important anymore,
*especially* when targetting desktop OS's like Windows, is it?r

On the other hand, it would be welcome to have a flavor of Gambit
which is less expressive. I do not know how burdensome it would be to
be able to prune whole parts of gambit to create "non
development-ready" applications (that is, once the final product is to
be delivered, compile it with a version of gambit which does not embed
the whole runtime, does not allow debugging, etc).
Or, maybe, allow the user to explicitely tell what he needs to import

(declare
(with-great-power-comes-great-responsability
    ;; EVAL's environment should only know those, should it be used
    read current-input-port current-output-port char=? list + - /*))

(define (arithmetic-evaluator)
  ...)

(eval '(car '(1 2))) ;; segfault. You should've added CAR too. Don't
complain to us.


Even though this is far from complete, this may be a compromise. (And
this is in favor of giving a seconde parameter to EVAL, if the user
has the capacity to create environments).


So, forgiving the fact that I am not an expert language implementer,
how realistic are those ideas for Gambit-C?


P!

-- 
Français, English, 日本語, 한국어



      Yahoo!香港提供網上安全攻略,教你如何防範黑客! 請前往 http://hk.promo.yahoo.com/security/ 了解更多!



More information about the Gambit-list mailing list