unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Neil Jerram <neiljerram@googlemail.com>
To: linasvepstas@gmail.com
Cc: Guile User <guile-user@gnu.org>, guile-devel <guile-devel@gnu.org>
Subject: Re: Killing off scm_init_guile for Guile 2.0 ?
Date: Fri, 23 Jan 2009 01:49:51 +0000	[thread overview]
Message-ID: <49dd78620901221749v6c043580wd1d9cacf0d0df660@mail.gmail.com> (raw)
In-Reply-To: <3ae3aa420901151959r472fe441k2437dc0d45639dec@mail.gmail.com>

2009/1/16 Linas Vepstas <linasvepstas@gmail.com>:
> I feel obligated to respond, having made all sorts of noise.
>
> 2009/1/15 Neil Jerram <neiljerram@googlemail.com>:
>
>> whether people think that scm_init_guile is really needed.
>
> kill it. there seem to be perfectly adequate ways of
> living without it.  Unfortunately, the current documentation
> describing how to use guile with threads is confusing.
> It is certainly the case that, for naive, new users,
> scm_init_guile seems to be the easiest way to
> get guile going in a thread. This makes it a popular
> choice.  Its not until you dig in deeply, and discover
> how guile actually works (and then think about it a bit),
> that you discover that perhaps scm_init_guile wasn't
> the right choice. And then you have to refactor your
> code ... possibly in large ways ...
>
> So, the real question is -- how many existing guile
> apps call scm_init_guile()?

A good handful, apparently.

> On the other hand, breaking them by removing
> scm_init_guile is possibly a good thing ... it will
> probably cause them to fix bugs that were lurking
> and waiting to bite.

I'm not sure... if the bugs aren't apparent in any way, they're not a
problem.  If the bugs are apparent, then I agree that moving away from
scm_init_guile could be part of the solution.

Assuming that we move to using BDW-GC, we can easily keep
scm_init_guile, and so I think we should.  We should also look at the
manual, though, to try to promote other ways in new projects.

Regards,
        Neil




  parent reply	other threads:[~2009-01-23  1:49 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-15 23:30 Killing off scm_init_guile for Guile 2.0 ? Neil Jerram
2009-01-15 23:48 ` Neil Jerram
2009-01-16 14:57   ` Ludovic Courtès
2009-01-16  3:59 ` Linas Vepstas
2009-01-16 15:00   ` Ludovic Courtès
2009-01-16 15:41     ` Bill Schottstaedt
2009-01-23  1:49   ` Neil Jerram [this message]
2009-01-16 21:32 ` dsmich
2009-01-17  1:36   ` Linas Vepstas
2009-01-21 21:52     ` Zeeshan Ali (Khattak)
2009-01-23  2:02     ` Neil Jerram
2009-01-23  6:13       ` Clinton Ebadi
2009-01-23 16:23         ` Ludovic Courtès
2009-01-23 16:21       ` Ludovic Courtès
     [not found] <cmu-lmtpd-4567-1232125596-3@mail-imap1.uio.no>
2009-01-16 17:20 ` Kjetil S. Matheussen
2009-01-23  1:44   ` Neil Jerram
2009-01-23  9:12     ` Kjetil S. Matheussen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49dd78620901221749v6c043580wd1d9cacf0d0df660@mail.gmail.com \
    --to=neiljerram@googlemail.com \
    --cc=guile-devel@gnu.org \
    --cc=guile-user@gnu.org \
    --cc=linasvepstas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).