unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Re: the future of Guile
@ 2007-12-05 15:40 Mike Gran
  2007-12-05 16:05 ` Julian Graham
                   ` (2 more replies)
  0 siblings, 3 replies; 28+ messages in thread
From: Mike Gran @ 2007-12-05 15:40 UTC (permalink / raw)
  To: guile-user



> 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  if no
> > choice is made Guile will be wiped out by other Schemes.

As far as being an LFE, 1.8.x has been a big improvement over 1.6.
The API is much cleaner when wrapping stuff by hand. 

> From: Roland Orre <roland.orre@neurologic.se>

> Today, however, I find that there are nearly no extension
> libraries available for guile. As a shell scripting language
> I prefer python because it has a very simple and clean
> shell interface. To extend my applications beyond real number
> crunching with e.g. graphical interphases (currently working
> with xlib...) I feel a limitation and have more and more often
> looked upon python where a lot of libraries are available for
> GUI, database and you name it.

One problem here is that there does need to be a richer library
that is official and downloadable right from
www.gnu.org/software/guile.  Unit test, documentation, 
cgi, http, sql, md5, utf8, xml, and perhaps pickle.

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. 

This goes back to the packaging problem.  After I've written a program, 
I'd like to give it away for others to use.  Giving code away in a scripting 
language should be easy.  It isn't easy here. 

First, dependencies on the many libraries are
difficult to coordinate.

Second, most non-trivial scripts require the whole of the configure, 
make, make install, LD_LIBRARY_PATH, %load-path overhead.

Where is the analog of a Java jar file?

Apologies if my rant has drifted off topic.

Thanks,

Mike Gran






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


^ permalink raw reply	[flat|nested] 28+ messages in thread
[parent not found: <cmu-lmtpd-4316-1197047238-3@mail-imap2.uio.no>]
* Re: the future of Guile
@ 2007-12-07  6:28 Marco Maggi
  0 siblings, 0 replies; 28+ messages in thread
From: Marco Maggi @ 2007-12-07  6:28 UTC (permalink / raw)
  To: guile-user

"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 "smarter", anyway my original plan
was to  put records  in a module  and structs could  go with
them.  My  understanding of records is that:  the only thing
that  structs do that  a vector  cannot do  (without special
handling),  is to  have a  print closure  used by  WRITE and
DISPLAY.

There is  a comment in "boot-9.scm" that  lets us understand
about   a  plan   to   make  GOOPS   wrap  records   (maybe)
automatically,   but   if   it   was   implemented   it   is
undocumented. It  goes along with  other undocumented things
that maybe are  there but nobody (still here)  knows if they
were finished and working.   And Guile maintainers keep them
in for future releases (if they exist), because they are not
going to break backwards compatibility...

>> 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  extensions  in C.  I  have  not  yet had  to  use
>this. Perhaps it's just dumb luck or something.

While coding GEE I had  crashes that I fixed by remembering.
I  am probably  using  it also  in  places where  it is  not
required. But I  am not able to recognise  those places, can
you guess why?

>> 5. Guile  must be loadable/unloadable  as a  shared library.
>>    Use case: once I have read a configuration file or a sexp
>>    data file, I do not need it anymore.
>
>If you aren't running your app with Guile extensions / code,
>you  don't   need  a   whole  scheme  interpreter   to  read
>s-expressions...

This  depends upon  the type  and number  of transformations
that  I  want  to  apply  before converting  data  into  the
application's internal representation.

>> 6. More modularity.
>
>Sure,  but  any  breaking  of  Guile  into  modules  without
>thinking about  syncase is half-baked. This is  one bit that
>r6rs definitely got right IMO.

Sorry, I  am not competent enough to  understand and comment
on this, can you elaborate?

>> 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).
>
>Oh, I don't know. Standards are definitely relevant, whether
>it's ERR5RS or R6RS  or whatever. The guile hacker community
>is a  small part of  the scheme hacker community,  we should
>cooperate if at all possible.

Well, I am  not going to do work for  R6RS compliance, and I
am not going  to ask Ludovic and Neil to do  it. In truth, I
hope that  they will not dive  into this because  in 2009 it
might turn out to have been a full waste of their time.  But
I am  noone, and their motivations are  their business only,
so they will do what they want.

Will Guile  gain active users  if it goes R6RS?   Will Guile
loose active users if it does not go R6RS?

>Unfortunately for you Guile is widely deployed and coded to;

I do not see where is my misfortune in this.

>those users also define "what guile is".

They define what Guile 1.8 has been.

>Radical  changes to  the C  interface  are not  going to  be
>forthcoming.

This is probably true if Neil and Ludovic stop hacking it.

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


^ permalink raw reply	[flat|nested] 28+ messages in thread
[parent not found: <cmu-lmtpd-27643-1196871540-1@mail-imap2.uio.no>]
* Re: the future of Guile
@ 2007-12-05 22:32 Marco Maggi
  2007-12-05 22:56 ` Ludovic Courtès
  0 siblings, 1 reply; 28+ messages in thread
From: Marco Maggi @ 2007-12-05 22:32 UTC (permalink / raw)
  To: guile-user

@Julian Graham
>I've  been  frustrated with  the  situation,  too.  Might  I
>direct    your    attention    to    the    Snow    project?
>(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  as being  an LFE, 1.8.x  has been a  big improvement
>over 1.6.   The API is  much cleaner when wrapping  stuff by
>hand.

From what I have seen of 1.6, I agree.

>One  problem here is  that there  does need  to be  a richer
>library  that  is   official  and  downloadable  right  from
>www.gnu.org/software/guile.

This is  impossible.  Too  much coordination work.   TCL has
something like this, but only because ActiveState is backing
it (and they make money with consultancy).

It  would be  an  enormous success  if  every Guile  related
package maintainer  opens a project  at the same  site, like
GNA!, so that all the source code can be found with a search
for the string Guile at that site.

>Much has been done  (GEE, Guile-lib, guile-gtk, all of TTN),
>but,  each  has  its  own  packaging  scheme,  documentation
>scheme.

I feel guilty here because I do not digest GNU Automake, and
I  have built my  own (shock!  horror!) GNU  Make automation
using  its  functions.  And  I  am the  only  one  that  can
understand it... :-/

>None of them  are released in a coordinated  manner with the
>Guile releases themselves.

This is true for different reasons. I, for example, am still
moving  stuff  around  in  GEE.  If  a  roadmap  comes  with
milestones for Guile  1.9, I can try to  make alpha releases
that build with them.

>First, dependencies  on the many libraries  are difficult to
>coordinate.

Ugh! And I am making it worse with GEE 0.4 ...

This is linked with the application deployment problem. With
a  self  executing  archive  we could  distribute  a  single
executable with everything  in it. It is not  a tool that we
can build in an afternoon, though.


@Ludovic Courts
>It took me some time, but  I now think there's no such sharp
>distinction between "LFE" and "SI".

Yep. Probably I am giving too much importance on the size of
the core library.

>> As a SI my opinion is  that some sort of compiler is a must,
>
>An interpreter *can* be much faster than what we have now

Really? Fine!

>>an interface  to bind the class to a symbol in a module.
>
>[...] is  easily addressed, by  defining said class  in your
>module to `(@ (oop goops) <SMOB-NAME>)'

Woah! I had not noticed  that the binding is created in (oop
goops).

>> Anyway,   remembering  "scm_remember_upto_here"   is  really
>> annoying.  And it  is needed almost every time  I access the
>> client data of a custom SMOB.
>
>This is strange.  I rarely had  to use it, and I can't think
>of a common programming pattern where it's useful.

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"
      anymore. With compiler optimisations the reference
      to the SMOB can disappear.

      If here I call scm_* functions, GC collects the
      SMOB removing the carpet from under my feet and
      if I access "data": crash.

      So:
   */
   scm_remember_upto_here_1(arg);
}

>> If  structs  are  moved  into an  external  shared  library,
>> records can go there, too.
>
>Records are too  common to be removed from  the core: almost
>everyone would end up loading that module.

This surprises  me. I thought  that they were a  rarely used
feature because  they are unschemey  :-) and because  of the
existence of GOOPS.

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


^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: the future of Guile
@ 2007-12-05 21:02 Marco Maggi
  0 siblings, 0 replies; 28+ messages in thread
From: Marco Maggi @ 2007-12-05 21:02 UTC (permalink / raw)
  To: guile-user

"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 <http://jottit.com/>, they have a
screencast
with a tutorial from the about page.

I am not sure that voting on topics can work though. This is
the Net not a polite society...

One thing that would be useful is to have a page with a roadmap
like this one <http://wiki.tcl.tk/12753> for Tcl.

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


^ permalink raw reply	[flat|nested] 28+ messages in thread
* Re: the future of Guile
@ 2007-12-05  9:01 Marco Maggi
  2007-12-05 14:19 ` Roland Orre
  2007-12-05 20:28 ` Ludovic Courtès
  0 siblings, 2 replies; 28+ messages in thread
From: Marco Maggi @ 2007-12-05  9:01 UTC (permalink / raw)
  To: guile-user

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.

Call me stupid if you want, but I picked Guile because the G
stands for GNU  and the E stands for  Extensions.  I look at
the E as a promise: There will always be special interest in
making it easy to interface with C.  Now I am not sure if it
was a good choice.

I  tried to  attract users  interested in  math  software by
coding extensions to special numbers  and the GSL.  I did it
for my own  interest, not "for Guile". But  I failed. I will
never know why (maybe it was  just a bad idea), but maybe it
is because Guile  is too slow and the fact  that Scheme is a
beautiful and  featureful language (compared  to Octave, for
example) is not enough.

It is all FUD, yes, but in  the last 7 years a lot of people
said that "TCL is dead".  Lately on comp.lang.tcl they had a
discussion on  a unified interface for  database access; and
they are going  to do it. This is not  being dead. For Guile
we cannot even  talk about such a thing; correct  me if I am
wrong, but on the Net there are mostly orphaned projects for
Guile...

Ludovic,  you are doing  an incredible  amount of  work. But
everybody's life moves on.  How many active Guile developers
are there? Or at least developers that are "still here"? How
many active ones understand the evaluator?

So, how much work is needed to make Guile a good choice "for
something"? As  a LFE I think  that the work  needed is less
than what is required for a SI.

As a SI my opinion is  that some sort of compiler is a must,
but  it is  a lot  of work  (I took  a look  at Lightning...
there are  soooo many  opcodes...).  You can  try to  do any
algorithmic stunt  to make Guile faster  without a compiler,
but will it be enough for someone?

@Stephen Compall:
>> 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
[stuff about inclusion of deprecated code]

@Neil Jerram:
>Disagree, in general.  Why should we be arbitrarily awkward?
>If there are specific  motivations, we should consider those
>case by case.

How much does it cost never  to discard a thing?  With a LFE
a huge shared library is not "lightweight". Can something be
discarded at least in the 1.x -> 2.x transition?

With "everything is a SMOB" and "death to structs" something
in the  interface changes.  I am not  talking about changing
"scm_to_int" and  the like, but, for example,  if a function
to bind  a <smob-name> symbol  to the class  of a SMOB  in a
selected module  is added:  the SMOB definition  protocol is
changed  a  bit.  The  same  with  a  function that  selects
superclasses.

More on this later about the limit on SMOB number.

@Ludovic Courts
>> 2. GOOPS always there.
>
>GOOPS is  nice at times,  but it's also very  "unschemey" in
>spirit, [...]

I am not  sure what you mean here. The ugly  thing for me is
that the  DEFINE-* must be at  top level; I  dunno why. This
prevented me  from trying  some automation (I  cannot recall
which ones now).

Generic functions  must be mutable  and they must  be "entry
points"  in a big  graph-like data  structure.  That  is the
only way to  do it.  I think that there  is consensus on the
idea  that  generic  functions  are  one of  the  points  of
strength of Lisps.

The thing  I know  is that coding  a math  extension without
them would be  a nightmare (there is a reason  if I have not
written my stuff for TCL).


@Ludovic Courts
>> 2a.   It  is  fine  to  have  both  procedures  and  generic
>>     functions,   but  the  default   for  Guile's   C  coded
>>     procedures  must  be  primitive generic.
>
>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.

READ is a nice short  symbol and everybody knows its meaning
in real life. It should  be available for everyone to use as
function name.  I do not  care if MAKE-PROCEDURE-WITH-SETTER
is not a generic function because it is unlikely that I need
such a name for a method, but READ...


@Ludovic Courts
>> 3a. The limit on SMOB type number must be destroyed.
>
>It's  gonna be  hard since  we  have only  8 bits  available
>currently[...]

A possible solution is to use the first level SMOBs only for
Guile-defined  ones, and  change the  implementation  of the
public API  for SMOB  definition to use  an evolution  of my
subordinate SMOB thing.


@Neil Jerram
> 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 struct  wrapped by a SMOB.  The thing I am
sure of is that structs are preventing me from understanding
what  goes on  in  "goops.c":  too much  work  is needed  to
understand the data structures layout.


@Ludovic Courts
>> 3c. Every  SMOB must  have a class  and an optional  list of
>>     superclasses, to allow  for 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?

An optional  list of superclasses  and an interface  to bind
the class to a symbol in a module. At present I have to do:

  if (scm_smob_class)
    scm_c_define("<" SMOB_DESCRIPTION ">",
      scm_smob_class[SCM_TC2SMOBNUM(gvector_smob_driver)]);

but I think  that at the public API level  I am not required
to    know    what    "scm_smob_class"   is,    let    alone
"SCM_TC2SMOBNUM".

Anyway, that  feature is undocumented;  so now I have  to go
back to change all my  GOOPS interfaces that wrap SMOBs. But
first I have to understand  how to register a method that is
directly implemented with  a compiled procedure: ADD-METHOD!
wants Scheme level procedures...  If only I could understand
where methods are stored...


@Stephen Compall
>> 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[...]

@Ludovic Courts
>Well, `scm_remember_upto_here ()' is rarely need anyway.

This  is Guideline #2  for a  LFE.  I  wrote this  because I
recall  to have read  a discussion  about an  alternative GC
that does not require it.  I think that it is the one Kjetil
is referring  to, but I am  not able to find  the message in
which someone stated that.

Anyway,   remembering  "scm_remember_upto_here"   is  really
annoying.  And it  is needed almost every time  I access the
client data of a custom SMOB.


@Ludovic Courts
>> 6. More modularity.
>
>I think we  could almost have one module  per C source file,
>e.g., `socket', `posix', `filesys', etc.

Fine.

>(however, we  definitely don't  want one shared  library per
>module, because of the overhead).

Ugh! The only reason I see to split up is to reduce the size
of the core shared library.


@Stephen Compall
>> 6c. GMP  support should  go into a  loadable module  (do not
>>     nuke my mailbox, please).
>
>Er, what would happen if you overflow fixnums?

The  same very  bad things  that happen  with all  the other
languages  that do  not support  bignums. A  LFE  should not
depend upon another big thing  like GMP (and should not come
with  bignums embedded),  but there  are no  problems  for a
SI. What  is the probability  of overflowing a  fixnum while
reading a config file like the one of Serveez?


@Ludovic Courts
>> 6d. Floating point math procedures should go into a loadable
>>     module.
>
>Likewise.

I am  talking about  the SIN, COS,  TAN, ...  functions, the
ones  in the  Scientific Info  node.  It  is another  way of
reducing a bit the size of the core shared library.

@Ludovic Courts
>> 6e. Records should go into a loadable module.
>
>SRFI-9 records? They are already in a "loadable" module. :-)

If  structs  are  moved  into an  external  shared  library,
records can go there, too.


@Neil Jerram
>> 8. Hackability of the core. If nobody understands it...
>
>Is it really that difficult?

How many can say: I  understand the evaluator? And GOOPS, as
it  is now,  is beyond  what an  occasional  contributor can
understand in a few hours.


@Neil Jerram
>> 8c. This is for my own ego: yeah, yeah, yeah! Define:
>>
>> 	typedef SCM scm_t;
>>
>
>Surely there's an elisp  incantation that would make it kiss
>SCM for you?

Of course! :-)


"Marco Maggi" wrote:
> 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").

@Neil Jerram
>I don't  think that a  programming language should  have its
>own packaging  system.

I am  not talking about  a packaging system like  .deb, .rpm,
etc.  Tclkit is  a  solution to  the application  deployment
problem. It seems that among Tclers it had a lot of success.


@Neil Jerram
>> 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.

IMHO Serveez and a WM for X are perfect usage examples for a
LFE. I use  Fvwm, and its configuration file  is yet another
pseudo-language  that I  have to  remember. A  design choice
that makes sense for them, makes sense for Guile as a LFE.

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


^ permalink raw reply	[flat|nested] 28+ messages in thread
[parent not found: <34.F3.20110.D6985574@avas19>]
[parent not found: <cmu-lmtpd-7104-1196779864-1@mail-imap2.uio.no>]
[parent not found: <F8.1B.18780.B4965574@avas11>]
* the future of Guile
@ 2007-12-04  6:50 Marco Maggi
  2007-12-04  8:48 ` Stephen Compall
                   ` (4 more replies)
  0 siblings, 5 replies; 28+ messages in thread
From: Marco Maggi @ 2007-12-04  6:50 UTC (permalink / raw)
  To: guile-user

Ciao,

I think that  it is time for a chat on  the future of Guile.
It is  a difficult topic,  but: the sooner, the  better. The
plan I  outline below requires  a lot of  work and a  lot of
discussion, and I can volunteer only for some of it.  But of
what use is the silence?

It seems clear  to me that Guile cannot  compete in terms of
speed with  projects like  PLT Scheme, Ikarus  and YouNameIt
Scheme with a native/JIT/VM/TheNext compiler.

But it does not have to  because, like it or not, Guile is a
language for extensions. With this in mind...


Guidelines
----------

1. Guile as a lightweight choice.

2. Simplicity of the C interface.

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


Concrete goals
--------------

1. ISO C99, can we look forward?

1a. Why functions like  SIN have a Scheme implementation for
    complex numbers when standard C has "csin"?

2. GOOPS always there.

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

3. Everything  must  be  a  SMOB:  ports,  values,  classes,
   instances. We can fight over procedures.

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

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

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.

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

5. Guile  must be loadable/unloadable  as a  shared library.
   Use case: once I have read a configuration file or a sexp
   data file, I do not need it anymore.

5a. A lighter  feature would be useful, too:  to collect all
    the  allocated SMOBs  (running GC  twice,  guardians can
    release async resources). It would be optional, so it is
    all right to have situations in which this is forbidden.

6. More modularity.

6a.   All the  non-string ports  should go  into  a loadable
    module.

6b. The networking stuff should go into a loadable module.

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

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.

6e. Records should go into a loadable module.

7. Every feature can be added as 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).

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

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.

8b. There  are struct  types in the  core whose name  is not
    prefixed with "scm_t_" (example: scm_metaclass_standard)
    this  should be  fixed. (Yes,  I  am a  nazi with  other
    people's code and I allow mine to become wastesource.)

8c. This is for my own ego: yeah, yeah, yeah! Define:

	typedef SCM scm_t;

    Emacs font locking kisses "scm_t" automatically.


Tough ones
----------

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

2. Resurrect Serveez.

3. Resurrect SCWM (Scheme Constraints Window Manager).

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


^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2007-12-07 17:42 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-12-05 15:40 the future of Guile Mike Gran
2007-12-05 16:05 ` Julian Graham
2007-12-05 16:18 ` Daniel Ridge
2007-12-05 20:41 ` Ludovic Courtès
     [not found] <cmu-lmtpd-4316-1197047238-3@mail-imap2.uio.no>
2007-12-07 17:42 ` Kjetil S. Matheussen
  -- strict thread matches above, loose matches on Subject: below --
2007-12-07  6:28 Marco Maggi
     [not found] <cmu-lmtpd-27643-1196871540-1@mail-imap2.uio.no>
2007-12-06 14:52 ` Kjetil S. Matheussen
2007-12-05 22:32 Marco Maggi
2007-12-05 22:56 ` Ludovic Courtès
2007-12-05 21:02 Marco Maggi
2007-12-05  9:01 Marco Maggi
2007-12-05 14:19 ` Roland Orre
2007-12-05 20:28 ` Ludovic Courtès
     [not found] <34.F3.20110.D6985574@avas19>
2007-12-04 19:54 ` the future of guile Daniel Llorens del Río
     [not found] <cmu-lmtpd-7104-1196779864-1@mail-imap2.uio.no>
2007-12-04 18:08 ` the future of Guile Kjetil S. Matheussen
2007-12-04 18:34   ` Kjetil S. Matheussen
2007-12-04 20:06     ` Roland Orre
2007-12-04 20:42       ` Ludovic Courtès
2007-12-04 22:30       ` Kjetil S. Matheussen
     [not found] <F8.1B.18780.B4965574@avas11>
2007-12-04 15:55 ` the future of guile Daniel Llorens del Río
2007-12-04  6:50 the future of Guile Marco Maggi
2007-12-04  8:48 ` Stephen Compall
2007-12-04 12:41 ` Ludovic Courtès
2007-12-04 14:50   ` Bill Schottstaedt
2007-12-04 15:30     ` Ludovic Courtès
2007-12-04 23:00 ` Neil Jerram
2007-12-05 23:11 ` Andy Wingo
2007-12-06 19:48 ` Mikael Djurfeldt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).