From: Thien-Thi Nguyen <ttn@gnuvola.org>
To: guile-user@gnu.org
Subject: Re: request: libguile to wrap getsid(2)
Date: Sun, 27 Dec 2009 23:58:05 +0100 [thread overview]
Message-ID: <877hs8xbwi.fsf@ambire.localdomain> (raw)
In-Reply-To: <87pr601t5c.fsf@ossau.uklinux.net> (Neil Jerram's message of "Sun, 27 Dec 2009 12:46:39 +0000")
() Neil Jerram <neil@ossau.uklinux.net>
() Sun, 27 Dec 2009 12:46:39 +0000
Cool. (I like ratpoison, and I wasn't aware it had been abandoned. A
Guile-enabled ratpoison would be great.)
Perhaps i should have distiguished what was abandoned: the C code,
the body. Its spirit lives in stumpwm (Common Lisp). Anyway, now
it has another body.
No problem, I'll add this.
Cool, thanks.
Can you point to a specific 1.4.x commit, to help with any
extra bits that are needed, e.g. anything in configure.ac?
No 1.4.x commit yet but i plan to do w/o configure checks since
getsid(2) is POSIX.1-2001. FWIW (not really directly useful for
Guile which must *provide* getsid), here is a fragment from rpx
configure.ac:
dnl Some versions of Guile don't provide getsid(2).
AC_CACHE_CHECK([if Guile provides getsid(2)],[guile_cv_getsid],
GUILE_CHECK([guile_cv_getsid],[(exit getsid)])
if test 0 = $guile_cv_getsid
then guile_cv_getsid=yes
else guile_cv_getsid=no
fi)
if test no = $guile_cv_getsid ; then
AC_DEFINE([NEED_RPX_GETSID],[1],
[Define if Guile does not provide Scheme-callable getsid(2).])
fi
Well, indeed. Let's make 2010 the year of repairing our divisions...
That is my hope as well.
With Guile 1.9.x/2.0, we have a fantastic new base system that
I think will serve us well for some years. With that in place,
it would be great to pull together all the Guile apps and
extensions that are out there, and showcase them working
together and doing interesting things.
It does indeed look very promising.
Plus, as far as possible, I hope we can find ways of making
everything work with older versions of Guile too.
As years go by, i have come to venerate old code per se less and
less. I think it would be cool to write tools to distill the
essence of old code, recasting into new code. That is what
compilers do, after all... Dreaming, i'd like to see compilers
that go beyond:
compilation
source ---------------------> "executable" representation
to
grok-db -----+<-------+
v |
compilation |
source ---------------+----> "executable" representation
where grok-db contains the analysis results of (this and other)
source, both present and past.
thi
next prev parent reply other threads:[~2009-12-27 22:58 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-26 18:50 request: libguile to wrap getsid(2) Thien-Thi Nguyen
2009-12-27 12:46 ` Neil Jerram
2009-12-27 18:21 ` Neil Jerram
2009-12-27 23:01 ` Thien-Thi Nguyen
2009-12-27 22:58 ` Thien-Thi Nguyen [this message]
2009-12-27 23:33 ` Linas Vepstas
2009-12-29 1:08 ` Jeff Wilkinson
2009-12-28 6:34 ` Ken Raeburn
2009-12-28 12:25 ` Thien-Thi Nguyen
2009-12-28 11:11 ` Neil Jerram
2009-12-28 12:18 ` Thien-Thi Nguyen
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=877hs8xbwi.fsf@ambire.localdomain \
--to=ttn@gnuvola.org \
--cc=guile-user@gnu.org \
/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).