request: libguile to wrap getsid(2)

request: libguile to wrap getsid(2)

[Thien-Thi Nguyen]

I've just about finished porting ratpoison (a CVS snapshot prior to its
author's abandoning it in favor of stumpwm) to Guile (1.4.x) scheme.
This means no more Xlib (et al)!

However, the last bit of C glue (outside of ttn-do) it needs is getsid(2).
Here is the Guile 1.4.x-flavored wrapping:

  GH_DEFPROC
  (rpx_getsid, "getsid", 1, 0, 0,
   (SCM pid),
   doc: /***********
  Return the session id associated with @var{pid}.  */)
  {
    return gh_int2scm (getsid (gh_scm2int (pid)));
  }

I'm sure it would be no trouble to adapt this to other Guile versions.
This function will go into Guile 1.4.1.119, so i'm hereby requesting
that a future Guile 1.9.x include it, as well.  This way, i can release
rpx (working name of the port -- kind of like "ratpoison exhumed") with
only ttn-do as its dependency, and no C bits whatsoever.

"But ttn, why do you care about any Guile other than 1.4.x?"

Well, why not?

thi

Re: request: libguile to wrap getsid(2)

[Neil Jerram]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> I've just about finished porting ratpoison (a CVS snapshot prior to its
> author's abandoning it in favor of stumpwm) to Guile (1.4.x) scheme.
> This means no more Xlib (et al)!

Cool.  (I like ratpoison, and I wasn't aware it had been abandoned.  A
Guile-enabled ratpoison would be great.)

> However, the last bit of C glue (outside of ttn-do) it needs is getsid(2).
> Here is the Guile 1.4.x-flavored wrapping:
>
>   GH_DEFPROC
>   (rpx_getsid, "getsid", 1, 0, 0,
>    (SCM pid),
>    doc: /***********
>   Return the session id associated with @var{pid}.  */)
>   {
>     return gh_int2scm (getsid (gh_scm2int (pid)));
>   }
>
> I'm sure it would be no trouble to adapt this to other Guile versions.
> This function will go into Guile 1.4.1.119, so i'm hereby requesting
> that a future Guile 1.9.x include it, as well.  This way, i can release
> rpx (working name of the port -- kind of like "ratpoison exhumed") with
> only ttn-do as its dependency, and no C bits whatsoever.

No problem, I'll add this.  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?

> "But ttn, why do you care about any Guile other than 1.4.x?"
>
> Well, why not?

Well, indeed.  Let's make 2010 the year of repairing our divisions...

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.
Plus, as far as possible, I hope we can find ways of making everything
work with older versions of Guile too.

> thi

Regards,
      Neil

Re: request: libguile to wrap getsid(2)

[Neil Jerram]

Neil Jerram <neil@ossau.uklinux.net> writes:

> Thien-Thi Nguyen <ttn@gnuvola.org> writes:
>
>> However, the last bit of C glue (outside of ttn-do) it needs is getsid(2).
>
> No problem, I'll add this.

It's in our Git repo now.

Regards,
        Neil

Re: request: libguile to wrap getsid(2)

[Thien-Thi Nguyen]

() Neil Jerram <neil@ossau.uklinux.net>
() Sun, 27 Dec 2009 18:21:12 +0000

   It's in our Git repo now.

Wow, fast!

thi

Re: request: libguile to wrap getsid(2)

[Thien-Thi Nguyen]

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

Re: request: libguile to wrap getsid(2)

[Linas Vepstas]

2009/12/27 Thien-Thi Nguyen <ttn@gnuvola.org>:

> As years go by, i have come to venerate old code per se less and
> less.

Heh. As the years go by, I have come to venerate any code,
old or new, less and less.  It's always broken, and never actually
does what you want, anyways.

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

Well, taking away two lessons from the recent past:
-- "optimizing" compilers try to "grok" some small portion of the
code, and re-arrange it in such a way that its more efficient.
The challange is to "grok" ever-larger pieces.

-- There are companies that specialize in taking :"legacy" code,
written in strange old language dialects, and automatically
modernizing/re-writing them to run on modern h/w.  I don't really
understand what the "old code" is, or exactly how much of the
re-write process is automated, but its apparently a big business
(i.e. big businesses that have lots of old code buy these things)
 I have a friend who works in this area, Jeff Wilkinson, perhaps
he can comment.

--linas

Re: request: libguile to wrap getsid(2)

[Jeff Wilkinson]

[-- Attachment #1: Type: text/plain, Size: 3199 bytes --]

Hey, good to hear from you.

Yes, this is my bailiwick. For the past few years I've been writing code
transformation tools. The semantic "essence" you mention is usually in what
the industry calls an AST (abstract syntax tree), and in other data (symbol
tables, at a minimum). This is very analogous to what optimizing compilers
do.

And in our case we're often dealing with larger patterns. Like isolating
presentation layer, business rules, and data access layer stuff, and
translating them differently.

The OMG's "Patterns Group" is even trying to standardize this AST data.
(Although that effort sounds only marginally useful to me.) There is also
the Eclipse Metadata Framework, which I haven't had much chance to look at,
but sounds promising from what I've read.

For us, the "old code" comes in a wide variety of forms. It seems the
industry has phases where there are more and then less programming languages
to choose from. (It looks to me like we're transitioning into a "more
languages" phase right now.) Most of our clients want to modernize code from
the previous "more languages" phase (prior to the popularity of C).

My own work is entirely in the automation, but overall, the percent that is
automated varies wildly from project to project. Sometimes the automation is
only used to obtain statistics or spot problematic patterns, but our large
projects are all about creating maintainable and modern versions of large
legacy systems.

So, uh, that's my answer. What was the question?

  -Jeff

On Sun, Dec 27, 2009 at 5:33 PM, Linas Vepstas <linasvepstas@gmail.com>wrote:

> 2009/12/27 Thien-Thi Nguyen <ttn@gnuvola.org>:
>
> > As years go by, i have come to venerate old code per se less and
> > less.
>
> Heh. As the years go by, I have come to venerate any code,
> old or new, less and less.  It's always broken, and never actually
> does what you want, anyways.
>
> >  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.
>
> Well, taking away two lessons from the recent past:
> -- "optimizing" compilers try to "grok" some small portion of the
> code, and re-arrange it in such a way that its more efficient.
> The challange is to "grok" ever-larger pieces.
>
> -- There are companies that specialize in taking :"legacy" code,
> written in strange old language dialects, and automatically
> modernizing/re-writing them to run on modern h/w.  I don't really
> understand what the "old code" is, or exactly how much of the
> re-write process is automated, but its apparently a big business
> (i.e. big businesses that have lots of old code buy these things)
>  I have a friend who works in this area, Jeff Wilkinson, perhaps
> he can comment.
>
> --linas
>

[-- Attachment #2: Type: text/html, Size: 3950 bytes --]

Re: request: libguile to wrap getsid(2)

[Ken Raeburn]

On Dec 27, 2009, at 17:58, Thien-Thi Nguyen wrote:
>   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.

And what about Windows?

Ken

Re: request: libguile to wrap getsid(2)

[Thien-Thi Nguyen]

() Ken Raeburn <raeburn@raeburn.org>
() Mon, 28 Dec 2009 01:34:27 -0500

   And what about Windows?

Guile 1.4.x is probably not even compilable there, dunno (never
tried, never intend to boot windows to try).  However, no worries:
it looks like Neil Jerram DTRT for official Guile.

thi

Re: request: libguile to wrap getsid(2)

[Neil Jerram]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

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

If the new compiler/translator framework in Guile 1.9.x is capable of
handling ECMAScript and elisp, it should certainly (in principle) be
able to handle slightly different variants of Guile Scheme.  So that
might be a good way of handling any recasting at runtime.  I believe it
also supports writing out recast code - although perhaps at the cost of
losing some formatting and comments.

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

Can you give an example of what grok-db might say?

Also note that grok-db is in a sense already present, in the source code
of the compiler.

Regards,
      Neil

Re: request: libguile to wrap getsid(2)

[Thien-Thi Nguyen]

() Neil Jerram <neil@ossau.uklinux.net>
() Mon, 28 Dec 2009 11:11:03 +0000

   recasting at runtime [...]  also supports writing out recast
   code - although perhaps at the cost of losing some formatting
   and comments.

A good start!  In my mind, the formatting and comments are part
of the essence.

   Can you give an example of what grok-db might say?

I envision grok-db not as program, but a data structure (database).
As such, the compiler (and other tools) would add/update/zonk bits of
knowledge in the form of:

 (ID GIVEN RESULT...)

tuples, where GIVEN may be one of:

 ID          ; reference
 LOCATION
 (LOCATION CONTEXT)

where LOCATION is some (FILENAME FORM-NODE-ID ETC...) form;
CONTEXT is (STATIC [DYNAMIC...]); and RESULT is something that
the compiler can use in its transforms.

   Also note that grok-db is in a sense already present, in the
   source code of the compiler.

Exactly.  We want to teach the compiler to share its thoughts,
and perhaps learn from the thoughts of others.  If the programmer
(or other tool) has insight that the compiler lacks, there is no
reason to deny it access.  Obviously, it goes the other way, too!

thi