Re: the viability of translators, and Guile itself

[Valentin Kamyshenko <val@kamysh.materials.kiev.ua>]

>>>>> "Greg" == Greg Badros <gjb@cs.washington.edu> writes:


Greg> Incidentally, I don't think just reducing the amount of code to
Greg> load initially will help Scwm's startup time... we, like other
Greg> applications that choose to use Guile, have lots of
Greg> application-specific guile code that needs to be loaded at
Greg> startup.  I think faster reading of the code, or alternative
Greg> means of loading standard modules (dumping, or pre-compiling
Greg> code and linking in .so files) is a more useful way to attack
Greg> this specific problem of slow startup time.

Probably, this is a stupid proposal, but could not the "start up time
problem" solved to some extent in the same way as (X)Emacs does? I
mean, to have in guile analogs of gnuserver (which is started by
(X)Emacs once - so, it does not matter, how much time does it take),
and gnuclient, which allows to open a new frame prctically
instantly. I, personally, always start XEmacs in startup script, and
use gnuclient every time my friends call vi or joe or other "fast"  
editors :). In fact, smth. like this already exists in scwm: scwmexec
allows to use running scwm as a "guile server" for arbitrary 
calculations. Would not it worth to include such possibility in guile
itself?  

--
Best regards,
	Valentin.