GSoC 2011

GSoC 2011

[Diogo F. S. Ramos]

Hello everybody,

I've been following some discussions about GSoC here and in the IRC and
I would like to say that I would love to work with you in this winter
;).

For those who are normally in the IRC, I'm didi. :D

As I can see, there are two main ideas:

  1. CPAN for Guile

  2. RoR for Guile

I've chatted a little with wingo at #guile about it but I would like to
know what the project is more interested in to be done.

I have my own ideas, like the Introspection branch that I forked from
zeenix, but I am not sure this is of the best interest for guile right
now.

-- 
Diogo F. S. Ramos

Re: GSoC 2011

[Noah Lavine]

Hello,

I'm no expert on what the project needs done, but I noticed your email
has been sitting for a few days with no reply. Have you been talking
to people on IRC?

Noah

On Mon, Mar 28, 2011 at 12:51 AM, Diogo F. S. Ramos <diogofsr@gmail.com> wrote:
> Hello everybody,
>
> I've been following some discussions about GSoC here and in the IRC and
> I would like to say that I would love to work with you in this winter
> ;).
>
> For those who are normally in the IRC, I'm didi. :D
>
> As I can see, there are two main ideas:
>
>  1. CPAN for Guile
>
>  2. RoR for Guile
>
> I've chatted a little with wingo at #guile about it but I would like to
> know what the project is more interested in to be done.
>
> I have my own ideas, like the Introspection branch that I forked from
> zeenix, but I am not sure this is of the best interest for guile right
> now.
>
> --
> Diogo F. S. Ramos
>
>

Re: GSoC 2011

[Diogo F. S. Ramos]

Noah Lavine <noah.b.lavine@gmail.com> writes:

> Hello,

Hi!

> I'm no expert on what the project needs done, but I noticed your email
> has been sitting for a few days with no reply. Have you been talking
> to people on IRC?

Not since the e-mail. I'm still waiting for feedback.

-- 
Diogo F. S. Ramos

Re: GSoC 2011

[Noah Lavine]

> Not since the e-mail. I'm still waiting for feedback.

I will tell you what I think, then, but keep in mind that many people
on this list know a lot more than I do.

The first idea is something I think Guile people are very interested
in, and you could expect to do significant work, possibly having a
working version done, over a summer. I don't know anything about the
second one.

I will also offer a few more suggestions below simply as things for
you to think about, but it would be best if you worked on a project
that you personally were excited about, because you will have a better
time and you will work better like that.

3. More work on Elisp. There's been a plan for approximately 100 years
(ish) to port Emacs to Guile. At the end of last summer, we had an
Elisp frontend that contained everything we would need except for the
Emacs C code. That's probably changed now, because Emacs is merging a
lexical binding branch, but it shouldn't be terribly hard to add
support for that to Guile as well. A good project would be adding
lexbind support to Guile's Elisp frontend, then getting as much of the
Emacs C code as you can ported before the summer ends.

4. A static analyzer. This project has been purely in my own head so
far. I had been planning to write an email to the list talking about
it at some point, but now this chance has come up, so here's an
incomplete introduction: we should have a static analyzing system. It
should be set up so the user can ask it to check specific things, or
perhaps so that the user can define new analyses easily. For instance,
here are some things a user would want to check that a standard
compiler might not realize needed checking:
   - that a specific mutex is always acquired before a certain data
structure is modified
   - that a given function throws one of a certain set of errors
   - that a given function always returns or throws an error
(impossible in general, but very much doable in specific cases)
   - that a given function returns one of a certain set of Scheme types
Bonus points: the analyzer should support both Scheme and C, and the
initial use of it should be checking that Guile itself will always
work as expected. I have some thoughts on how to implement this
without insane amounts of complexity, which I can mention if you are
interested.

5. A JIT compiler. This has actually been my project for quite a
while, and it has been moving pretty slowly. It would move a lot
faster if someone were working on it full time. You would be coming in
partway through this project, but there would still be plenty of
things to figure out, and of course you could always change some of
the earlier decisions I made if they turn out to be bad.

What do you think? Is there a project that seems interesting to you?

Noah

Re: GSoC 2011

[Diogo F. S. Ramos]

Noah Lavine <noah.b.lavine@gmail.com> writes:

>> Not since the e-mail. I'm still waiting for feedback.
>
> I will tell you what I think, then, but keep in mind that many people
> on this list know a lot more than I do.

I really appreciate it.

> The first idea is something I think Guile people are very interested
> in, and you could expect to do significant work, possibly having a
> working version done, over a summer. I don't know anything about the
> second one.

About the second thing: It's something I read people talking about in
the IRC channel.

> I will also offer a few more suggestions below simply as things for
> you to think about, but it would be best if you worked on a project
> that you personally were excited about, because you will have a better
> time and you will work better like that.

I agree. But sometimes what one is first excited with is not what is
best for the project at the moment. That's why I insist on figuring out
where people think the time is best spent on.

And it is not like there is only one cool thing to work on, like you
demonstrated with all the cool ideas. :)

> 3. More work on Elisp. There's been a plan for approximately 100 years
> (ish) to port Emacs to Guile. At the end of last summer, we had an
> Elisp frontend that contained everything we would need except for the
> Emacs C code. That's probably changed now, because Emacs is merging a
> lexical binding branch, but it shouldn't be terribly hard to add
> support for that to Guile as well. A good project would be adding
> lexbind support to Guile's Elisp frontend, then getting as much of the
> Emacs C code as you can ported before the summer ends.
>
> 4. A static analyzer. This project has been purely in my own head so
> far. I had been planning to write an email to the list talking about
> it at some point, but now this chance has come up, so here's an
> incomplete introduction: we should have a static analyzing system. It
> should be set up so the user can ask it to check specific things, or
> perhaps so that the user can define new analyses easily. For instance,
> here are some things a user would want to check that a standard
> compiler might not realize needed checking:
>    - that a specific mutex is always acquired before a certain data
> structure is modified
>    - that a given function throws one of a certain set of errors
>    - that a given function always returns or throws an error
> (impossible in general, but very much doable in specific cases)
>    - that a given function returns one of a certain set of Scheme types
> Bonus points: the analyzer should support both Scheme and C, and the
> initial use of it should be checking that Guile itself will always
> work as expected. I have some thoughts on how to implement this
> without insane amounts of complexity, which I can mention if you are
> interested.
>
> 5. A JIT compiler. This has actually been my project for quite a
> while, and it has been moving pretty slowly. It would move a lot
> faster if someone were working on it full time. You would be coming in
> partway through this project, but there would still be plenty of
> things to figure out, and of course you could always change some of
> the earlier decisions I made if they turn out to be bad.
>
> What do you think? Is there a project that seems interesting to you?

All of them are interesting to me actually, but I have some reservations
with (4). It seems to me that it requires a deep understanding of scheme
and guile and I think that maybe I'm not up to the task right now. Not
that this gap couldn't be filled, but it's something to consider.

The (3) is the one which hit closest to home. I'm a Emacs user for some
years now and I remember dreaming about the idea of emacs running on
guile, even though I didn't know guile at the time. I would love to help
with that dream, but I suppose it will require some collaboration with
the emacs developers. I'm sometimes at #emacs and AFAICT elisp is still
evolving.

From the list of 5 ideas, I guess I like (1), (3) and (5) the most. I'm
probably more comfortable with (1) and (3) but maybe it's just my
ignorance talking.

-- 
Diogo F. S. Ramos

Re: GSoC 2011

[Andy Wingo]

Hi Diogo,

On Mon 28 Mar 2011 06:51, "Diogo F. S. Ramos" <diogofsr@gmail.com> writes:

> I've been following some discussions about GSoC here and in the IRC and
> I would like to say that I would love to work with you in this winter
> ;).

Cool!  As you see, we can be a bit asynchronous in our communications
;-)

> I have my own ideas, like the Introspection branch that I forked from
> zeenix, but I am not sure this is of the best interest for guile right
> now.

What do you want to do in this area?  There is important work to do with
introspection, but we would need to see your ideas and your code.

Cheers,

Andy
-- 
http://wingolog.org/

Re: GSoC 2011

[Diogo F. S. Ramos]

>> I have my own ideas, like the Introspection branch that I forked from
>> zeenix, but I am not sure this is of the best interest for guile right
>> now.
>
> What do you want to do in this area?  There is important work to do with
> introspection, but we would need to see your ideas and your code.

You can see some of the code here:
http://gitorious.org/~diogofsr/guile-gir/didi-guile-gir

The thing is: I don't know what to do. Maybe some history will clear
things.

I've started trying to port librepository to guile from the ground up,
using just C. While doing so people at #introspection point me to the
great port of zeenix (guile-gir), as yourself.

I contacted zeenix and he was very kind to help me with it, even
commenting on my commits. It was very cool of him.

After some time, and talking to you, it was suggest that an
Introspection implementation should use (gnome gobject) and the pages
from Introspection itself says that it is a good idea to use a previous
gobject binding, as python does it. So I started playing with it.

Some more time, I thought that would be a good idea to go full power
with the dynamic ffi, so there I went.

Some more time and IRC talk, rotty introduced to me his great sbank and
after some more talk at #guile it was pointed that sbank is the
direction that guile should go for an Introspection binding.

So, as you can see, I don't have a clear vision on what has and needs to
be done or how. I would happily give it a shot, but I need some kind of
guidance.

-- 
Diogo F. S. Ramos

Re: GSoC 2011

[Noah Lavine]

Hello,

Your ideas sound neat, but there are a few things I am not familiar with.

On Thu, Mar 31, 2011 at 10:31 AM, Diogo F. S. Ramos <diogofsr@gmail.com> wrote:
>> What do you want to do in this area?  There is important work to do with
>> introspection, but we would need to see your ideas and your code.
>
> You can see some of the code here:
> http://gitorious.org/~diogofsr/guile-gir/didi-guile-gir
>
> The thing is: I don't know what to do. Maybe some history will clear
> things.
>
> I've started trying to port librepository to guile from the ground up,
> using just C. While doing so people at #introspection point me to the
> great port of zeenix (guile-gir), as yourself.

What does librepository do?

> I contacted zeenix and he was very kind to help me with it, even
> commenting on my commits. It was very cool of him.
>
> After some time, and talking to you, it was suggest that an
> Introspection implementation should use (gnome gobject) and the pages
> from Introspection itself says that it is a good idea to use a previous
> gobject binding, as python does it. So I started playing with it.

When you talk about introspection, are you talking about introspecting
on GObjects, or all Guile objects? (Guile has its own object system.
If I understand correctly, all GObjects can be Guile objects, but not
all Guile objects are GObjects.)

> Some more time, I thought that would be a good idea to go full power
> with the dynamic ffi, so there I went.
>
> Some more time and IRC talk, rotty introduced to me his great sbank and
> after some more talk at #guile it was pointed that sbank is the
> direction that guile should go for an Introspection binding.
>
> So, as you can see, I don't have a clear vision on what has and needs to
> be done or how. I would happily give it a shot, but I need some kind of
> guidance.

According to some Gnome webpage Google found, GLib introspection is
intended to make it easy to wrap GObject objects in higher-level
languages. If I understand correctly, you wish to do this for Guile?
That sounds like a good thing to do, if so.

Noah

Re: GSoC 2011

[Diogo F. S. Ramos]

Noah Lavine <noah.b.lavine@gmail.com> writes:

>> I've started trying to port librepository to guile from the ground up,
>> using just C. While doing so people at #introspection point me to the
>> great port of zeenix (guile-gir), as yourself.
>
> What does librepository do?

Sorry, the correct name is 'libgirepository'.

The library reads typelib files, which describes gobjects, and offers an
API to the user, so one doesn't need to create a parser.

There are two file formats to describe a gobject: GIR XML and
typelib. They are interchangeable, but the former is a text file and the
latter is in a binary format.

> When you talk about introspection, are you talking about introspecting
> on GObjects, or all Guile objects? (Guile has its own object system.
> If I understand correctly, all GObjects can be Guile objects, but not
> all Guile objects are GObjects.)

When I'm talking about Introspection, I'm talking about GObjects. As I
understand it, Guile objects already have introspection capabilities,
right?

AFAIU, guile's GObjects are implemented using GOOPS, so you could
introspect them, but just as much information as the binding implementer
put there.

With Introspection, it is possible to explorer a new GObject feature
just after it is implemented by the original author, IIUC.

> According to some Gnome webpage Google found, GLib introspection is
> intended to make it easy to wrap GObject objects in higher-level
> languages. If I understand correctly, you wish to do this for Guile?
> That sounds like a good thing to do, if so.

It is the trend that I'm seeing at the GObject based world with the
Gnome 3.0 release.

Apparently it is possible to drop whole bindings with it [0], leaving
less code to maintain and debug.

[0] http://www.johnstowers.co.nz/blog/index.php/2011/04/03/end-of-an-era-pygtk/

-- 
Diogo F. S. Ramos

Re: GSoC 2011

[Andreas Rottmann]

"Diogo F. S. Ramos" <diogofsr@gmail.com> writes:

> Noah Lavine <noah.b.lavine@gmail.com> writes:
>
>>> I've started trying to port librepository to guile from the ground up,
>>> using just C. While doing so people at #introspection point me to the
>>> great port of zeenix (guile-gir), as yourself.
>>
>> What does librepository do?
>
> Sorry, the correct name is 'libgirepository'.
>
> The library reads typelib files, which describes gobjects, and offers an
> API to the user, so one doesn't need to create a parser.
>
Yep.  This is the recommended (at least by upstream) way to access
.typelib files.  However, for sbank I decided not make use of its
parser.  In the following, I'd like to outline some of the fundamental
design decisions in sbank in the hope that this information is useful
for work on object-introspection bindings for Guile.

- sbank is pure Scheme code.  This means I can use only the
  implementation's dynamic FFI, and can not rely on C glue code.  This
  has the advantage of greatly improving portability between
  implementations.  sbank makes use of a small FFI abstraction in the
  `(spells foreign)' library, and does not contain any
  implementation-specific code at all.  Portability across
  implementations is obviously not a concern for a Guile-specific
  binding, but if it is decided that the binding should make use of the
  dynamic FFI (only), I think the following points are valid for a
  Guile-specific implementation as well.

- Using a dynamic FFI to access libgirepository's parser would have
  entailed replicating its API on the Scheme.  At that point, my
  intuition was that doing the parsing in Scheme would be of similiar
  complexity, and can even be done in a more easily automatable manner
  (see below).  Another upside is that you don't have to use
  (potentially relatively costly) FFI calls to access every single bit
  of information in the typelib; that information is *already* available
  in RAM, you just need to be able to make sense of it.

- To get the information about memory layout of the typelib data, sbank
  employs a script that uses gobject-introspection's tools
  (g-ir-scanner) to get an XML description (in GIR format) of
  gtypelib-internal.h (thus it doesn't need to do any C header parsing
  itself).  That XML is the converted to an S-expression based format
  containing the relevant information (data/typelib.scm).  At
  macro-expansion time, this information is used to generate accessors
  for the typelib data available in memory.  

  The only downside of this approach that I can see is that sbank does
  not rely on libgirepository's ABI, but on the typelib format, and
  needs to be updated (regenerating data/typelib.scm) if that format
  changes.  However, it seems that this format has stabilized pretty
  much; the last change to gitypelib-internal.h has been in October
  2010, and it was backward-compatible.  There's much incentive to only
  make backward-compatible changes as changing the format incompatibly
  requires rebuilding of all typelibs, involving a multitude of source
  packages (GTK+, libsoup, ... -- everything that ships with
  gobject-introspection support).

FWIW, I'm slowly working on porting `(spells foreign)' to Guile, which
should make sbank run out-of-the box.  That will be a good stress test
on Guile's dynamic FFI, besides offering an alternative to guile-gnome.

If there emerges a Guile-specific gobject-introspection binding project,
it would IMHO make sense (if it's a pure Scheme project) to reuse some
of sbank's infrastructure, specifically the typelib accessor stuff.
Additionally, it would be nice to cooperate on offering a compatible
Scheme API; you can find some information on the Scheme<->C mapping used
in sbank in its tutorial [0].  Of course, a Guile-specific project will
also want to offer some compatibility with guile-gnome, but I don't
think these goals do necessarily conflict.

[0] http://rotty.yi.org/software/sbank/tutorial.html

>> According to some Gnome webpage Google found, GLib introspection is
>> intended to make it easy to wrap GObject objects in higher-level
>> languages. If I understand correctly, you wish to do this for Guile?
>> That sounds like a good thing to do, if so.
>
> It is the trend that I'm seeing at the GObject based world with the
> Gnome 3.0 release.
>
> Apparently it is possible to drop whole bindings with it [0], leaving
> less code to maintain and debug.
>
> [0] http://www.johnstowers.co.nz/blog/index.php/2011/04/03/end-of-an-era-pygtk/
>
Indeed, that's the major advantage of gobject-introspection; quoting
from sbank's tutorial:

  To stress that: if a C library provides gobject-introspection
  metadata, you should be able to use it via sbank without further ado.

  However, while the metadata provided in the .typelib file is complete
  enough to yield good and "schemely" bindings, there might still be
  some corners in the API that profit from some glossing over, and sbank
  provides such glossing where and when such cases are identified.

Regards, Rotty
-- 
Andreas Rottmann -- <http://rotty.yi.org/>