Re: the future of Guile

[Stephen Compall]

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

I am not a GC expert, but it is my understanding that as long as SMOBs
can own non-GC-controlled mallocations freed by the SMOB free function,
you need those macros/functions, GCPRO structures, or refcounting to
work with C code that can poke at their contents.  I guess you could
disable GC while executing subrs not marked safe-for-GC

> 6c. GMP  support should  go into a  loadable module  (do not
> nuke my mailbox, please).

Er, what would happen if you overflow fixnums?

> 7a.  It makes no sense to discuss if Guile should go R6RS or
> not.   The  only meaningful  discussion  is about  which
> hooks are needed in  Guile's code to make those features
> available   as   loadable   modules.   (Yes,   this   is
> difficult).

7a1. Inter-module hygiene/implicit exports.

> 1. TCL  has nice  programs that  allow to  distribute single
>file  auto-extracting-and-running  archives  holding  the
>core executable,  shared libraries, pure  TCL modules and
>some data files (search for "tclkit").

I know of SBCL, CLISP, and PLT also doing this, but much more
sophisticated for the former 2.

-- 
Our last-ditch plan is to change the forums into a podcast, then send
RSS feeds into the blogosphere so our users can further debate the
legality of mashups amongst this month's 20 'sexiest' gadgets.
--Richard "Lowtax" Kyanka


signature.asc
Description: This is a digitally signed message part
___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Ludovic Courtès]

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
rest, given that (i) X sucks, (ii) Y rocks, and (iii) nothing inherently
makes programs in language Y "slower".  :-)

(Of course, language X allows you to re-use lots of libraries and tools,
so you definitely don't want to throw it away, but at least you want to
reduce the amount of code written in X.)

> 3. For Guile 2.0 backwards  compatibility at the C level can
>be broken. Freely. No shame. No blame.

As Stephen suggested, we have to be cautious here.

> 2. GOOPS always there. 

GOOPS is nice at times, but it's also very "unschemey" in spirit,
relying on hard-to-follow side-effects for a lot of core operations (see
the `define-method' mess in G-Wrap), and biased towards an imperative
programming style.  I used to be a big fan, but I've become more and
more suspicious.

> 2a.   It  is  fine  to  have  both  procedures  and  generic
> functions,   but  the  default   for  Guile's   C  coded
> procedures  must  be  primitive generic.   Non-primitive
> generics  are allowed  as  exceptions (case:  READ is  a
> primitive procedure, dunno why). 

What would it buy you if `read' were a primitive generic?  `write' is
certainly useful as a generic, but I don't see the benefit of `read' as
a generic.

Besides, if turning primitives into primitive-generics doesn't slow down
Guile startup, then we can go for it.

> 3a. The limit on SMOB type number must be destroyed.

It's gonna be hard since we have only 8 bits available currently (BTW, I
saw your patch that adds support for sub-SMOBs but it looks complex to
me---more on that later).

> 3b. Death to  structs!  IMO they were "an  attempt", but the
> resulting code is awful (sorry, but can you disagree?). 

We may have to keep it, at least for the sake of backward compatibility.

> 3c. Every  SMOB must  have a class  and an optional  list of
> superclasses, to allow  for methods dispatching. This is
> not meant to  be an attempt to "corrupt"  the concept of
> class, but a mean to extend methods dispatching.

As you noted in a recent post, SMOBs types have an associated class when
GOOPS is loaded.  So what else do you want?

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

Well, `scm_remember_upto_here ()' is rarely need anyway.

> 6. More modularity. 

I think we could almost have one module per C source file, e.g.,
`socket', `posix', `filesys', etc. (however, we definitely don't want
one shared library per module, because of the overhead).  We could them
set up a backward-compatible namespace that pulls all of them, while
still leaving the opportunity to execute code in a minimal environment
where only core primitives are available.

> 6c. GMP  support should  go into a  loadable module  (do not
> nuke my mailbox, please).

No way (see Stephen's reply).  :-)

> 6d. Floating point math procedures should go into a loadable
> module. Once they are there, more functions can be added
> (from  the  standard C  library  and  not)  and a  "long
> double" SMOB can be put in, too.

Likewise.

> 6e. Records should go into a loadable module.

SRFI-9 records?  They are already in a "loadable" module.  :-)

> 7a.  It makes no sense to discuss if Guile should go R6RS or
> not.   The  only meaningful  discussion  is about  which
> hooks are needed in  Guile's code to make those features
> available   as   loadable   modules.   (Yes,   this   is
> difficult).

Agreed.

> 8a. Ludovic, do  you still have that patch  that reduces the
> size of  the evaluator? I  do not want to  hurt anyone's
> feelings, but I do not understand why it was rejected.

It did not really make it smaller, it just splitted it into several
parts.  The main arguments against it were that it splitted things badly
and that moving code around precludes auditing through diffs:

  http://lists.gnu.org/archive/html/guile-devel/2007-02/msg00040.html

> 8b. There  are struct  types in the  core whose name  is not
> prefixed with "scm_t_" (example: scm_metaclass_standard)
> this  should be  fixed.

Right.

> 8c. This is for my own ego: yeah, yeah, yeah! Define:
>
>   typedef SCM scm_t;
>
> Emacs font locking kisses "scm_t" automatically.

I'm afraid it's a bit too late, and we don't want two names for one
thing.

Thanks,
Ludovic.


___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Bill Schottstaedt]

> 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 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.
For stuff involving vectors, C is much easier to read than Scheme.
Another is that everyone has his favorite language, and
by separating the basic stuff out, you can provide any number
of extension language choices at reasonably small cost (Snd
can be built with Guile, Gauche, Forth, Ruby, or no extension
language).  I've seen this "There is one Language and its
name is XXX" about 40 times -- at least once for every language
except maybe Pascal.  Of course, it was true in SAIL's case...




___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: "soso" X update; xplay.git available

[Thien-Thi Nguyen]

() [EMAIL PROTECTED] (Ludovic Courtès)
() Fri, 30 Nov 2007 16:44:34 +0100

   Guile-RPC[0] `serve-one-stream-request/asynchronous' [...]
   idea is to pass the RPC handler a continuation that
   it must invoke to actually return the RPC result over the network.

interesting, thanks for the pointer.

   I guess continuation-passing style could also be used to
   implement asynchronous calls on the client-side.

yes.  maybe i'll try that sometime.

   At any rate, this and your framework to handle the
   X protocol look cool!

thanks, i hope it can be fun for others to play with, as well.
the gnuvola wip page now has a (more) proper index for anyone
wishing to monitor progress.

thi


___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Ludovic Courtès]

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 be to have a faster
Scheme implementation.

> Another is that everyone has his favorite language, and
> by separating the basic stuff out, you can provide any number
> of extension language choices at reasonably small cost (Snd
> can be built with Guile, Gauche, Forth, Ruby, or no extension
> language).

Right, but few applications really do this, probably because it's hard
to provide good integration and good maintenance of all these.

Actually, I'm not arguing against "embeddability", rather stating
that it should not serve as an excuse for not going beyond the mere
"language for extension" approach.  Among Schemers, many care about
writing applications in Scheme, rather than in C.  That people develop
Guile bindings for existing C libraries is an illustration.

Thanks,
Ludovic.


___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of guile

[Daniel Llorens del Río]

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.





___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: should accept be protected with fport_wait_for_input?

[Ludovic Courtès]

Hi,

dskr <[EMAIL PROTECTED]> writes:

> the fport fill input code provides a way to avoid some threaded
> deadlocks with fport_wait_for_input. I appreciate this tremendously!
>
> Should this protection be extended to 'accept' in the socket code to
> prevent the entire runtime from blocking if a thread blocks on accept?

You're right, we should leave "guile mode" before blocking in
`accept(2)'.  I committed the attached patch, let me know if it works
for you.

Thanks!

Ludovic.

--- orig/libguile/socket.c
+++ mod/libguile/socket.c
@@ -36,6 +36,8 @@
 #include "libguile/validate.h"
 #include "libguile/socket.h"
 
+#include "libguile/iselect.h"
+
 #ifdef __MINGW32__
 #include "win32-socket.h"
 #endif
@@ -1321,16 +1323,30 @@
 	"connection and will continue to accept new requests.")
 #define FUNC_NAME s_scm_accept
 {
-  int fd;
+  int fd, selected;
   int newfd;
   SCM address;
   SCM newsock;
+  SELECT_TYPE readfds, exceptfds;
   socklen_t addr_size = MAX_ADDR_SIZE;
   scm_t_max_sockaddr addr;
 
   sock = SCM_COERCE_OUTPORT (sock);
   SCM_VALIDATE_OPFPORT (1, sock);
   fd = SCM_FPORT_FDES (sock);
+
+  FD_ZERO (&readfds);
+  FD_ZERO (&exceptfds);
+  FD_SET (fd, &readfds);
+  FD_SET (fd, &exceptfds);
+
+  /* Block until something happens on FD, leaving guile mode while
+ waiting.  */
+  selected = scm_std_select (fd + 1, &readfds, NULL, &exceptfds,
+			 NULL);
+  if (selected < 0)
+SCM_SYSERROR;
+
   newfd = accept (fd, (struct sockaddr *) &addr, &addr_size);
   if (newfd == -1)
 SCM_SYSERROR;


___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Kjetil S. Matheussen]

"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 nonscientific tests earlier this year
showed that HBGC had _much_ lower latency than Guile's garbage
collector.

I am planning to measure the difference in latency properly
quite soon, and if what I suspect is correct, that the HBGC
has significant lower latency, this is another "should"
for replacing the old one, even if the new one is a little
bit slower and use a little bit more memory.



___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Kjetil S. Matheussen]

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 we replace "should" with "must", I agree.
> 
> Regarding the HBGC, a few nonscientific tests earlier this year
> showed that HBGC had _much_ lower latency than Guile's garbage
> collector.
> 
> I am planning to measure the difference in latency properly
> quite soon, and if what I suspect is correct, that the HBGC
> has significant lower latency, this is another "should"
> for replacing the old one, even if the new one is a little
> bit slower and use a little bit more memory.
> 

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



___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

[announce] GEE/Streams 0.1

[Marco Maggi]

GEE/Streams is a C language library extension for Guile, the
GNU's  Ubiquitous Intelligent  Language for  Extensions.  It
implements  a  replacement for  the  (ice-9 streams)  module
distributed with Guile.

If we are not Scheme newbies and we see a form starting with
(fold  ...):  we  know  immediately  the  structure  of  its
code. There is a great advantage if we compare this with the
time  required   to  understand  the  control   flow  of  an
equivalent explicitly coded form.

Streams are an answer to  the questions: ``Is it possible to
apply  a FOLD  like  procedure to  a  non--list sequence  of
values?  And what about MAP and FOR-EACH?''

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 both Scheme  and C  code to
define streams.

The advantages upon the pure Scheme module are:

* speed, especially with long sequences;

* the procedures work with streams, lists and vectors;

* (gee misc  streams-1) loads GOOPS: a class  is defined and
  bound  to  the   symbol;  that  way GOOPS  generic
  functions can dispatch  methods for streams (unfortunately
  there is no way to select a base  class);

streams can be implemented with  both a Scheme or C producer
function.




--
Marco Maggi

"Now feel the funk blast!"
Rage Against the Machine - "Calm like a bomb"




___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of guile

[Daniel Llorens del Río]

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.


Ok, I misunderstood. Now I see what you mean. Sorry :)



___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Roland Orre]

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 have much experience with different GC algorithms, but
as I understand the HBGC is not intended for background GC.

If the GC should be replaced I would consider it wise to
replace it with an algorithm than can be run in a thread.
This I consider strongly motivated by the fact that most new
machines today are multi core. An efficient way to decrease the
latency of the GC is to simply run it in background.

Regarding GC I also think it is could be useful to have a GC that
can compact the memory and of course give allocated memory back to
the OS when no longer needed. OK, a compacting GC may make it
hard to write applications, so don't take this point too
seriously...

/Roland



___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Ludovic Courtès]

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.

> Regarding GC I also think it is could be useful to have a GC that
> can compact the memory and of course give allocated memory back to
> the OS when no longer needed.

HBGC doesn't compact memory and does not either give unused memory back
to the OS (current GC doesn't either).

Thanks,
Ludovic.



___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Kjetil S. Matheussen]

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 "should"
for replacing. :-) )


I don't have much experience with different GC algorithms, but
as I understand the HBGC is not intended for background GC.



Actually, it does:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/scale.html




If the GC should be replaced I would consider it wise to
replace it with an algorithm than can be run in a thread.
This I consider strongly motivated by the fact that most new
machines today are multi core. An efficient way to decrease the
latency of the GC is to simply run it in background.



Sure, that would be great. But I don't think you know how hard
it is to actually do that... But as a matter of fact, the HBGC do
at least support parallell marking though, and I also think the
HBGC patch for guile supports that feature.




Regarding GC I also think it is could be useful to have a GC that
can compact the memory


I think the HB gc does a pretty good job of not fragmenting the memory
at least.




and of course give allocated memory back to
the OS when no longer needed.


Well, Don't think you need that feature very often when using an OS 
supporting virtual memory.



Anyway, there is no third option here. The two choices are Guile's 
own garbage collector and Hans Boehms general garbage collector.
The last one is used in a bunch of other programming languages with great 
success, and except for being a bit slower on uniprocessor machines

when running a garbage collector benchmark, the HBGC seems
to generally work better for Guile than Guile's own GC.

Personally I hope the Guile developers choose to switch to HBGC when 
starting the next development cycle of Guile.




___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: the future of Guile

[Neil Jerram]

"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 always there. 

I think I agree.  I haven't developed Ludovic's suspicions yet.

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

> 6. More modularity. 

Yes, definitely, in general.  Like others I don't agree with trying to
split up the numerical tower though.

> 8. Hackability of the core. If nobody understands it...

Is it really that difficult?

(Actually the array code is pretty nasty, that could do with cleanup
if we can do that without breaking it!)

> 8c. This is for my own ego: yeah, yeah, yeah! Define:
>
>   typedef SCM scm_t;
>
> Emacs font locking kisses "scm_t" automatically.

Surely there's an elisp incantation that would make it kiss SCM for
you?

> 1. TCL  has nice  programs that  allow to  distribute single
>file  auto-extracting-and-running  archives  holding  the
>core executable,  shared libraries, pure  TCL modules and
>some data files (search for "tclkit").

I don't think that a programming language should have its own
packaging system.  Instead, we should provide tools to make it trivial
to package up Guile code into the common kinds of distribution
package.

> 3. Resurrect SCWM (Scheme Constraints Window Manager).

I've settled happily on ion2 now.  I suspect a WM may be one of those
things that doesn't really need much scripting, so I'm not sure what
SCWM would be aiming at.

Regards,
Neil



___
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user