Re: the future of Guile

Pre-answer to all: the most important thing is to make clear what are the priorities. With a "language for extensions" (LFE) there are certain priorities, with a "Scheme implementation" (SI) there are others. I fear that if no choice is made Guile will be wiped out by other Schemes

On the topic of asyncs and utility as an extension language

Hi, In an earlier message today, I mentioned my use of guile as an extension language. There is one new barrier to use of guile as an extension language that exists in guile 1.8 that did not exist in guile 1.6. The new async mechanism works via a pipe. The natural thing, remanufacturing

Re: the future of Guile

Hi, Mike Gran <[EMAIL PROTECTED]> writes: > Much has been done (GEE, Guile-lib, guile-gtk, all of TTN), > but, each has its own packaging scheme, documentation > scheme. None of them are released in a coordinated manner > with the Guile releases themselves. They don't have to be coordinated.

Re: the future of Guile

Hello, "Marco Maggi" <[EMAIL PROTECTED]> writes: > Pre-answer to all: the most important thing is to make clear > what are the priorities. With a "language for extensions" > (LFE) there are certain priorities, with a "Scheme > implementation" (SI) there are others. I fear that if

more spam on extension language fu

Hi, One of the things I value most about Guile as an extension language is the terrific set of facilities for introspection available. I've always thought the included readline support was vile (mostly due to readline itself) and so I've been using my own pure-guile completion library for

Re: the future of Guile

"Roland Orre" wrote: >How about setting up a voting/wishing site to collect wishes for >our visions and desires about guile, and in what way we can >contribute to this? If there is interest in having such a thing, it is a matter of 5 minutes with Jottit , they have a screencast

Re: the future of Guile

@Julian Graham >I've been frustrated with the situation, too. Might I >directyourattentiontotheSnowproject? >(http://snow.iro.umontreal.ca/) Rules, rules and rules! I don't know... It is not for me because I am using C and GOOPS everywhere. @Mike Gran >As far

Re: how do you time the execution of a form?

Hi, On Fri 30 Nov 2007 09:57, [EMAIL PROTECTED] (Ludovic Courtès) writes: > "Marco Maggi" <[EMAIL PROTECTED]> writes: > >> is there a procedure that prints the execution time of a form? >> Something like: >> >> (time-this (the-form) 1000) >> ;; run (the-form) 1000 times and prints the result > >

Re: the future of Guile

Hi Marco, "Marco Maggi" <[EMAIL PROTECTED]> writes: > Woah! I had not noticed that the binding is created in (oop > goops). He he. ;-) > SCM > my_func (SCM arg) > { >client_data_t data = (client_data_t)SCM_SMOB_DATA(arg); > >/* Do something with "data" but do not access "arg" >

Re: the future of Guile

> On Wed, 2007-12-05 at 10:01 +0100, Marco Maggi wrote: > > Pre-answer to all: the most important thing is to make clear > > what are the priorities. With a "language for extensions" > > (LFE) there are certain priorities, with a "Scheme > > implementation" (SI) there are others.

Re: the future of Guile

On mike's question about the natural analog of the jar file, I find that one of the big binary distribution hurdles for guile code has been static paths baked everywhere. Static, absolute paths get baked into libtool .la files when the underlying platform does not necessarily require it.

Re: [announce] GEE/Streams 0.1

Hi, On Tue 04 Dec 2007 20:34, "Marco Maggi" <[EMAIL PROTECTED]> writes: > Guile already comes with the (ice-9 streams) module, which > allows Scheme level code to iterate over non--list sequences > of values. GEE/Streams is a C language re-implementation of > the same interface that allows b

Re: the future of Guile

I've been frustrated with the situation, too. Might I direct your attention to the Snow project? (http://snow.iro.umontreal.ca/) One of the difficulties with these things is that they kind of require a certain critical mass to establish themselves, and, so far, nothing's really done that. (SLIB

Call for contributions to update the project list

Hi, With all these lengthy debates, I think time has come to update the Guile project page. :-) I started a new project page (almost) from scratch: http://www.gnu.org/software/guile/gnu-guile-projects.html The previous one is still available at: http://www.gnu.org/software/guile/old-gnu-g

Re: the future of Guile

Greets, I have had sufficient wine to respond. On Tue 04 Dec 2007 07:50, "Marco Maggi" <[EMAIL PROTECTED]> writes: > I think that it is time for a chat on the future of Guile. Sure, why not. (Stop justifying your emails, it looks stupid in fixed-width fonts.) > [Guile] does not have to [comp

Re: the future of Guile

On Wed, 2007-12-05 at 10:01 +0100, Marco Maggi wrote: > Pre-answer to all: the most important thing is to make clear > what are the priorities. With a "language for extensions" > (LFE) there are certain priorities, with a "Scheme > implementation" (SI) there are others. I fear that