guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: request: libguile to wrap getsid(2)


From: Thien-Thi Nguyen
Subject: Re: request: libguile to wrap getsid(2)
Date: Sun, 27 Dec 2009 23:58:05 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

() Neil Jerram <address@hidden>
() 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]