Re: the future of Guile

"Marco Maggi": 4. If a garbage collector allows to remove the need for "scm_remember_upto_here" it must be adopted even if it makes Guile slower and it raises memory usage a bit (or more than a bit). Who cares? I have written thousands and thousands of lines of guile ext

Re: the future of Guile

"Andy Wingo" wrote: >> 3b. Death to structs! > >Record types are the hip disjoint type in Schemeland, and >you certainly need a way to deal with them from >Guile. Structs might not be it, but you will need something >smarter than SMOBs... Suggestions? I dunno what you mean by "s

Re: the future of Guile

2007/12/4, Marco Maggi <[EMAIL PROTECTED]>: > I think that it is time for a chat on the future of Guile. Some pieces of input to the discussion: * There is (or should be) a module called "workbook" in the repository. It contains policy documents setting out the direction for Guile development.

Re: the future of Guile

"Marco Maggi": 3b. Death to structs! IMO they were "an attempt", but the resulting code is awful (sorry, but can you disagree?). Err.. but aren't structs the main part of how GOOPS is implemented? IMO Guile's structs do nothing that cannot be done better with a good old C str

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

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

@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: 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

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

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: 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

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 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

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

Re: the future of Guile

"Marco Maggi" <[EMAIL PROTECTED]> writes: > 3. For Guile 2.0 backwards compatibility at the C level can >be broken. Freely. No shame. No blame. Disagree, in general. Why should we be arbitrarily awkward? If there are specific motivations, we should consider those case by case. > 2. GOOPS

Re: the future of Guile

On Tue, 4 Dec 2007, Roland Orre wrote: On Tue, 2007-12-04 at 19:34 +0100, Kjetil S. Matheussen wrote: ... Oh, and another thing. My tests (available in the guile-devel archives) also showed that the HBGC version usually use a bit less memory than Guile's old garbage collector. (Yet another "s

Re: the future of Guile

Hi, Roland Orre <[EMAIL PROTECTED]> writes: > If the GC should be replaced I would consider it wise to > replace it with an algorithm than can be run in a thread. HBGC can be configured with `--enable-parallel-mark'. The `GC_MARKERS' environment variable then sets the number of marker threads.

Re: the future of Guile

On Tue, 2007-12-04 at 19:34 +0100, Kjetil S. Matheussen wrote: ... > Oh, and another thing. My tests (available in the guile-devel archives) > also showed that the HBGC version usually use a bit less memory > than Guile's old garbage collector. (Yet another "should" > for replacing. :-) ) I don't

Re: the future of guile

On 4 Dec, 2007, at 18:01, [EMAIL PROTECTED] wrote: 1a. Why functions like SIN have a Scheme implementation for complex numbers when standard C has "csin"? In Scheme, any real is also complex. That's not the case in C. I hope you're not proposing to separate the numeric types in Scheme.

Re: the future of Guile

On Tue, 4 Dec 2007, Kjetil S. Matheussen wrote: > > "Marco Maggi": > > > > 4. If a garbage collector allows to remove the need for > > "scm_remember_upto_here" it must be adopted even if it > > makes Guile slower and it raises memory usage a bit (or > > more than a bit). > > If w

Re: the future of Guile

"Marco Maggi": 4. If a garbage collector allows to remove the need for "scm_remember_upto_here" it must be adopted even if it makes Guile slower and it raises memory usage a bit (or more than a bit). If we replace "should" with "must", I agree. Regarding the HBGC, a few nonsc

Re: the future of guile

On 4 Dec, 2007, at 15:50, [EMAIL PROTECTED] wrote: 1a. Why functions like SIN have a Scheme implementation for complex numbers when standard C has "csin"? In Scheme, any real is also complex. That's not the case in C. I hope you're not proposing to separate the numeric types in Scheme.

Re: the future of Guile

Hi, "Bill Schottstaedt" <[EMAIL PROTECTED]> writes: > There are several reasons to have different base and extension > languages. The worst is that Guile/Scheme is 10 to 30 times > slower than the equivalent C code, and in DSP work, that matters. Of course it matters, but another solution would

Re: the future of Guile

> Right, although I question the "language for extensions" paradigm: why > would you choose language Y for "extensions" and language X for the > rest, given that (i) X sucks, (ii) Y rocks, and (iii) nothing inherently > makes programs in language Y "slower". :-) There are several reasons to h

Re: the future of Guile

Hi, "Marco Maggi" <[EMAIL PROTECTED]> writes: > But it does not have to because, like it or not, Guile is a > language for extensions. With this in mind... Right, although I question the "language for extensions" paradigm: why would you choose language Y for "extensions" and language X for the

Re: the future of Guile

On Tue, 2007-12-04 at 07:50 +0100, Marco Maggi wrote: > 3. For Guile 2.0 backwards compatibility at the C level can >be broken. Freely. No shame. No blame. This message references another message that I can't find: http://lists.gnu.org/archive/html/guile-devel/2003-04/msg00076.html > 4. If