Hi! Interested in GSoC. Feedback on these ideas?

Hi! Interested in GSoC. Feedback on these ideas?

[Paul Raccuglia]

Hi! I'm interested in working on guile as part of the Google Summer of Code.

I'm Paul Raccuglia, a Math/CS student at Haverford College (and
general freelance hacker). I'm pretty excited by Guile, I think it's a
cool project. I do a lot of Python coding, and I love interpreted
languages; Guile seems like a great way to combine the comfort of
interpreted languages with the general badassery of C.

 I've been talking with a friend who contributes to this project, and
we came up with some exciting ideas for working on Guile over the
summer.

Currently I am thinking about:

- A package manager (in the vein of apt-get)
I know this is one that's come up a bit. I was thinking of writing a
small web interface to browse packages, an aptitude style command-line
method for downloading, verifying the hashes, checking dependencies,
and then install the package(s) and an uninstall function as well. I
saw the proposal of working with dorodango; I might look at it, but
from what I saw of the code base, I thought it would make sense to try
to write a GUILE specific package-manager.


- AOT Compiler: write an interface to GCC
I think this would be really cool. A good plan would be to use GCC,
because it's already pretty sophisticated and handles lots of
architectures. I would start by writing a scheme interface to GCC, and
then writing the compiler in scheme.

I noticed a relevant (but now dead) project to write a GCC scheme
compiler : http://gna.org/projects/gsc  ; they started in '05 and died
by '06, but I think it would help me think through the process to look
at what other people did.


- JIT compiler
I talked with Noah Lavine about this (he's the person who directed me
to Guile in the first place), and I think this is a really exciting
project. My first step would be to clean up the code that he has
written, and then build on that to make it fully functional. Big
issues raised are smoothly integrating this with Guile, and
implementing all of the VM instructions without duplicating ridiculous
quantities of code. A suggestion (of Noah's) was to work on
integrating the JIT with Guile and then adding the VM instructions to
the JIT.


Could y'all give me some guidance on this? I'd really appreciate it.

-- Paul Raccuglia
praccugl@haverford.edu

Re: Hi! Interested in GSoC. Feedback on these ideas?

[nalaginrut]

> Hi! I'm interested in working on guile as part of the Google Summer of Code.
> 
> I'm Paul Raccuglia, a Math/CS student at Haverford College (and
> general freelance hacker). I'm pretty excited by Guile, I think it's a
> cool project. I do a lot of Python coding, and I love interpreted
> languages; Guile seems like a great way to combine the comfort of
> interpreted languages with the general badassery of C.
> 
>  I've been talking with a friend who contributes to this project, and
> we came up with some exciting ideas for working on Guile over the
> summer.
> 
> Currently I am thinking about:
> 
> - A package manager (in the vein of apt-get)
> I know this is one that's come up a bit. I was thinking of writing a
> small web interface to browse packages, an aptitude style command-line
> method for downloading, verifying the hashes, checking dependencies,
> and then install the package(s) and an uninstall function as well. I
> saw the proposal of working with dorodango; I might look at it, but
> from what I saw of the code base, I thought it would make sense to try
> to write a GUILE specific package-manager.
> 

I like this. And I like the idea about GUILE specific package-manager.
Maybe you can learn something interesting from Nix, here is an
introduction from Nix website:
"Nix is a purely functional package manager. This means that it treats
packages like values in purely functional programming languages such as
Haskell — they are built by functions that don’t have side-effects, and
they never change after they have been built."
http://nixos.org/nix/

> 
> - AOT Compiler: write an interface to GCC
> I think this would be really cool. A good plan would be to use GCC,
> because it's already pretty sophisticated and handles lots of
> architectures. I would start by writing a scheme interface to GCC, and
> then writing the compiler in scheme.
> 
> I noticed a relevant (but now dead) project to write a GCC scheme
> compiler : http://gna.org/projects/gsc  ; they started in '05 and died
> by '06, but I think it would help me think through the process to look
> at what other people did.
> 

Well~I like this too~Actually I'm interested in GUILE in the embedded
device.So I'm looking for a good solution which could support nice
efficient for GUILE to run on embedded device.
The VM&bytecode maybe a good solution. But I'd like to see a GUILE
compiler which compile some code to binary directly(if it's possible).
I've tried Gambit-C, it's great. Can we do something alike for GUILE?

-- 
GNU Powered it
GPL Protected it
GOD Blessed it

HFG - NalaGinrut

--hacker key--
v4sw7CUSMhw6ln6pr8OSFck4ma9u8MLSOFw3WDXGm7g/l8Li6e7t4TNGSb8AGORTDLMen6g6RASZOGCHPa28s1MIr4p-x hackerkey.com
---end key---

Re: Hi! Interested in GSoC. Feedback on these ideas?

[Mark H Weaver]

Paul Raccuglia <praccugl@haverford.edu> writes:
> - AOT Compiler: write an interface to GCC
> I think this would be really cool. A good plan would be to use GCC,
> because it's already pretty sophisticated and handles lots of
> architectures. I would start by writing a scheme interface to GCC, and
> then writing the compiler in scheme.

There is one _very_ serious problem with using GCC to compile Scheme, or
at least there was the last time I researched this issue: tail calls.
Although GCC has long been able to do tail call optimization in some
limited situations, standard C calling conventions prevent tail calls
from being done consistently in the general case.

The fundamental problem is that in C, the caller of a function is
responsible for popping the arguments off the stack after the call
returns.  This is required to support normal C varargs behavior, where
the callee does not necessarily know how many parameters were passed to
it, and therefore does not know how many parameters to pop.

In Scheme, which requires tail calls, it is the caller that does not
know how many parameters to pop, because the function which returns will
not necessarily be the same one originally called.  For example:

  (define (main)     (foo 5))
  (define (foo a)    (bar a a))
  (define (bar x y)  y)

If this is implemented with standard C calling conventions, main pushes
one argument (et al) on the stack before calling (foo 5), and then pops
one argument (et al) after it returns.  But it is (bar 5 5) that returns
to main, and so actually two parameters must be popped.

Many people have worked on this issue over the years, but in GCC (and
probably other C compilers) the assumptions about calling conventions
are very deeply ingrained, and last I checked, no one has found any
feasible solutions, short of making procedure calls through a
trampoline, or doing the "Cheney on the MTA" trick that Chicken does.

See http://users.cecs.anu.edu.au/~baueran/thesis/ for a detailed
analysis of possible strategies to properly support tail calls in GCC
circa 2003.  (If anyone has more recent information, please do share!)

> I noticed a relevant (but now dead) project to write a GCC scheme
> compiler : http://gna.org/projects/gsc  ; they started in '05 and died
> by '06, but I think it would help me think through the process to look
> at what other people did.

The first thing I would check is how they deal with tail calls.  Some
so-called Scheme implementations do not implement tail calls
consistently (though they may do this "optimization" in some limited
cases).  I strongly believe that this is not good enough for Guile, nor
any other implementation that rightly calls itself Scheme.

Anyway, thanks for looking into this!

     Best,
      Mark

Re: Hi! Interested in GSoC. Feedback on these ideas?

[Noah Lavine]

Hello,

> There is one _very_ serious problem with using GCC to compile Scheme, or
> at least there was the last time I researched this issue: tail calls.

I might be wrong about this, but I thought that GCC supported multiple
calling conventions, with the user telling GCC which one to use
(cdecl, fastcall, possibly others). If so, it must have some way to
represent that in its intermediate representations. We might be able
to add our own calling convention.

I also know that GCC has an --optimize-sibling-calls argument, which
will make it do something similar to at least some regular C calls.
I'm not sure if it's possible, but maybe we could arrange for whatever
code transformation implements this to be run on every Scheme call.

Noah

Re: Hi! Interested in GSoC. Feedback on these ideas?

[nalaginrut]

> Hello,
> 
> > There is one _very_ serious problem with using GCC to compile Scheme, or
> > at least there was the last time I researched this issue: tail calls.
> 
> I might be wrong about this, but I thought that GCC supported multiple
> calling conventions, with the user telling GCC which one to use
> (cdecl, fastcall, possibly others). If so, it must have some way to
> represent that in its intermediate representations. We might be able
> to add our own calling convention.
> 
> I also know that GCC has an --optimize-sibling-calls argument, which
> will make it do something similar to at least some regular C calls.
> I'm not sure if it's possible, but maybe we could arrange for whatever
> code transformation implements this to be run on every Scheme call.
> 
> Noah
> 

I'm reading the paper given by Mark. Though I confused with this "call
convention" problem, I thought the point maybe that we can hardly get a
optimized result all by GCC. But if we arrange it manually or restrict
it to certain call convention except cdecl, it's not perfect for
GCC?(But I don't think we need perfect) According to the paper, some
scheme compiler provided "tail call" based on a modified standard C
compiler. I think it's similar to arrange/restrict solution.
I'm not sure if my understanding is correct. Anyway, I'll finish reading
this paper. 

-- 
GNU Powered it
GPL Protected it
GOD Blessed it

HFG - NalaGinrut

--hacker key--
v4sw7CUSMhw6ln6pr8OSFck4ma9u8MLSOFw3WDXGm7g/l8Li6e7t4TNGSb8AGORTDLMen6g6RASZOGCHPa28s1MIr4p-x hackerkey.com
---end key---

Problem with GCC as a Scheme compiler: tail calls

[Mark H Weaver]

Noah Lavine <noah.b.lavine@gmail.com> writes:
>> There is one _very_ serious problem with using GCC to compile Scheme, or
>> at least there was the last time I researched this issue: tail calls.
>
> I might be wrong about this, but I thought that GCC supported multiple
> calling conventions, with the user telling GCC which one to use
> (cdecl, fastcall, possibly others). If so, it must have some way to
> represent that in its intermediate representations. We might be able
> to add our own calling convention.
>
> I also know that GCC has an --optimize-sibling-calls argument, which
> will make it do something similar to at least some regular C calls.
> I'm not sure if it's possible, but maybe we could arrange for whatever
> code transformation implements this to be run on every Scheme call.

Please read section 3.3 of the thesis I referenced:

  http://users.cecs.anu.edu.au/~baueran/thesis/

There you will find the list of conditions required for tail calls to be
optimized by GCC circa 2003.  Among other things, it includes:

* The caller's stack frame must be empty (i.e. no stack-allocated local
  variables or temporaries).

* No overlapping arguments (i.e. if it's too difficult to rearrange the
  input arguments on the stack to match what the next function expects,
  gcc will bail on the tail call)

* No position-independent code on several platforms, including x86
  (i.e. no tail calls in shared libraries)

* No indirect calls (i.e. no tail calls to function pointers)

* No setjmp or longjmp

* Sibling call epilogue must be defined (i.e. many targets aren't
  supported)

* Additional machine-independent constraints (i.e. many targets impose
  additional restrictions)

The end result of all of these restrictions is that tail calls can only
be optimized by GCC in extremely simple cases like fibonacci.  Some of
these restrictions may have been lifted since 2003, but I'm reasonably
sure the problem has not been solved satisfactorily.  If it had been, it
would've been very big news in the functional programming language
implementors community, since this has been a long-standing problem.

However, what I find more persuasive than any paper is that fact that
I've never found an implementation of a high-level programming language
based on GCC that manages to support tail calls without doing some nasty
hacks.  Lots of smart people have worked on this, but to my knowledge,
no one has found a good solution.  The solutions I'm aware of are:

* Cheney on the MTA, as is done by Chicken

* Trampoline: instead of calling functions directly, return the address
  of the next function back to the trampoline loop.

* Don't do function calls at all.  Instead use inline asm to jump to the
  inside of the next function, passing arguments via register globals.
  GHC did this at one point.

GCC's problems in this area are almost certainly the main reason so many
functional programming language implementors have resorted to writing
their own native code generators from scratch.

If anyone knows of a recent breakthrough in this area, please speak up.

    Best,
     Mark

Re: Problem with GCC as a Scheme compiler: tail calls

[Noah Lavine]

Ah, I see. The problem is quite significant.

I found this page in the GCC internals documentation:
http://gcc.gnu.org/onlinedocs/gccint/Tail-Calls.html. It seems to
suggest that we would need to make our own calling convention.

So I guess the question is, is it worthwhile for us to fix GCC so it
can handle tail calls, or should we use another code generation
library that already deals with them? I must admit I still really like
the idea of using GCC, because it has a lot of good optimizations, and
I also like the idea of working with other groups rather than making
yet another compiler. However, I guess the next thing to do is to ask
on the GCC mailing list if they're interested in tail call patches,
and how hard those would be to make.

I realize however that the GSoC deadline is tomorrow, and that Paul is
probably wondering whether he should submit a proposal for an AOT
compiler or not. So I suggest that an AOT compiler is a good project,
and the first step should be to figure out if it's possible for us to
use GCC. What do people think of this? (Also note: I know Paul outside
of this mailing list, so my opinion is not objective.)

Noah

On Thu, Apr 7, 2011 at 10:25 AM, Mark H Weaver <mhw@netris.org> wrote:
> Noah Lavine <noah.b.lavine@gmail.com> writes:
>>> There is one _very_ serious problem with using GCC to compile Scheme, or
>>> at least there was the last time I researched this issue: tail calls.
>>
>> I might be wrong about this, but I thought that GCC supported multiple
>> calling conventions, with the user telling GCC which one to use
>> (cdecl, fastcall, possibly others). If so, it must have some way to
>> represent that in its intermediate representations. We might be able
>> to add our own calling convention.
>>
>> I also know that GCC has an --optimize-sibling-calls argument, which
>> will make it do something similar to at least some regular C calls.
>> I'm not sure if it's possible, but maybe we could arrange for whatever
>> code transformation implements this to be run on every Scheme call.
>
> Please read section 3.3 of the thesis I referenced:
>
>  http://users.cecs.anu.edu.au/~baueran/thesis/
>
> There you will find the list of conditions required for tail calls to be
> optimized by GCC circa 2003.  Among other things, it includes:
>
> * The caller's stack frame must be empty (i.e. no stack-allocated local
>  variables or temporaries).
>
> * No overlapping arguments (i.e. if it's too difficult to rearrange the
>  input arguments on the stack to match what the next function expects,
>  gcc will bail on the tail call)
>
> * No position-independent code on several platforms, including x86
>  (i.e. no tail calls in shared libraries)
>
> * No indirect calls (i.e. no tail calls to function pointers)
>
> * No setjmp or longjmp
>
> * Sibling call epilogue must be defined (i.e. many targets aren't
>  supported)
>
> * Additional machine-independent constraints (i.e. many targets impose
>  additional restrictions)
>
> The end result of all of these restrictions is that tail calls can only
> be optimized by GCC in extremely simple cases like fibonacci.  Some of
> these restrictions may have been lifted since 2003, but I'm reasonably
> sure the problem has not been solved satisfactorily.  If it had been, it
> would've been very big news in the functional programming language
> implementors community, since this has been a long-standing problem.
>
> However, what I find more persuasive than any paper is that fact that
> I've never found an implementation of a high-level programming language
> based on GCC that manages to support tail calls without doing some nasty
> hacks.  Lots of smart people have worked on this, but to my knowledge,
> no one has found a good solution.  The solutions I'm aware of are:
>
> * Cheney on the MTA, as is done by Chicken
>
> * Trampoline: instead of calling functions directly, return the address
>  of the next function back to the trampoline loop.
>
> * Don't do function calls at all.  Instead use inline asm to jump to the
>  inside of the next function, passing arguments via register globals.
>  GHC did this at one point.
>
> GCC's problems in this area are almost certainly the main reason so many
> functional programming language implementors have resorted to writing
> their own native code generators from scratch.
>
> If anyone knows of a recent breakthrough in this area, please speak up.
>
>    Best,
>     Mark
>

Re: Problem with GCC as a Scheme compiler: tail calls

[Andy Wingo]

On Thu 07 Apr 2011 16:37, Noah Lavine <noah.b.lavine@gmail.com> writes:

> So I guess the question is, is it worthwhile for us to fix GCC so it
> can handle tail calls, or should we use another code generation
> library that already deals with them? I must admit I still really like
> the idea of using GCC, because it has a lot of good optimizations, and
> I also like the idea of working with other groups rather than making
> yet another compiler. However, I guess the next thing to do is to ask
> on the GCC mailing list if they're interested in tail call patches,
> and how hard those would be to make.

Regarding GCC, I have spoken to GCC folk, and they are not averse to
making GCC into a more modular thing.  There are obvious licensing
concerns, but these are surmountable: Guile and GCC could work together
somehow.  The problem, as I understood it last year, was that GCC
doesn't know exactly what abstractions are necessary.  For that we need
to get our own house in order, write an AOT compiler for one
architecture, then go to GCC and say "it would be nice if we had these
features", or something like that.

People's experiences with LLVM are probably helping here, to define the
problem space, but we need something simple to push to GCC folk, like a
simple less-than-Scheme implementation with only fixnum arithmetic or
something, both AOT and with a REPL.

Dunno.  Thoughts in the ether!

Andy
-- 
http://wingolog.org/

Re: Problem with GCC as a Scheme compiler: tail calls

[Noah Lavine]

Hello,

> Regarding GCC, I have spoken to GCC folk, and they are not averse to
> making GCC into a more modular thing.  There are obvious licensing
> concerns, but these are surmountable: Guile and GCC could work together
> somehow.  The problem, as I understood it last year, was that GCC
> doesn't know exactly what abstractions are necessary.  For that we need
> to get our own house in order, write an AOT compiler for one
> architecture, then go to GCC and say "it would be nice if we had these
> features", or something like that.
>
> People's experiences with LLVM are probably helping here, to define the
> problem space, but we need something simple to push to GCC folk, like a
> simple less-than-Scheme implementation with only fixnum arithmetic or
> something, both AOT and with a REPL.

Neat! I had an idea of how this transition could go that is different,
but I think might turn out to involve a lot of the same steps as
yours.

I was imagining that we would start with a compiler that was almost
all custom code, except that the backend is GCC. In the most extreme
case, maybe GCC would act as a big assembler, but I think we should be
able to use a few more of its features than that. Once we have that, I
imagine that we could integrate our code into GCC over time, either
merging our stuff with existing similar code already in GCC or adding
new things. If I understand correctly, you were thinking that we would
write our compiler with some other backend, figure out what changes we
want GCC to make, then switch to using GCC once they're ready. Right?

I was also imagining that we could start with a batch-compiling AOT
compiler like current GCC, and then make it more dynamic as GCC became
more modular. It seems like you want to start out with something that
could be called in the background by the runtime. Is that right?

I was thinking that if we could teach GCC to compile tail calls, then
we could use quite a bit of its infrastructure without any further
changes, because we could make a Scheme procedure compile to a GCC
procedure, and in fact implement all Scheme control flow stuff as a
bunch of GCC procedures. We would still have to implement Scheme
datatypes ourselves, but that would still give us a decent amount of
integration to begin with. What do you think?

Noah

Re: Hi! Interested in GSoC. Feedback on these ideas?

[Andreas Rottmann]

Paul Raccuglia <praccugl@haverford.edu> writes:

> Hi! I'm interested in working on guile as part of the Google Summer of Code.
>
[...]
> Currently I am thinking about:
>
> - A package manager (in the vein of apt-get)
> I know this is one that's come up a bit. I was thinking of writing a
> small web interface to browse packages, an aptitude style command-line
> method for downloading, verifying the hashes, checking dependencies,
> and then install the package(s) and an uninstall function as well. I
> saw the proposal of working with dorodango; I might look at it, but
> from what I saw of the code base, I thought it would make sense to try
> to write a GUILE specific package-manager.
>
Could you be more specific?  What exactly in the code base did make you
think so?

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

Re: Hi! Interested in GSoC. Feedback on these ideas?

[Paul Raccuglia]

> Could you be more specific?  What exactly in the code base did make you
> think so?
>
> Thanks, Rotty

Hey. Sorry, to be a little clearer:
It looks like Dorodango could provide a great resource to pull from.
From my (very uninformed) cursory glance,I thought it would need some
reworking to get it to work from Guile. Looking at it a bit more, I
realize I probably don't know what I'm talking about. I'll try to look
through the mailing list some more to get a better sense of the issue.



Thanks for the other feedback. Looking into it.

--Paul


On Thu, Apr 7, 2011 at 6:43 AM, Andreas Rottmann <a.rottmann@gmx.at> wrote:
> Paul Raccuglia <praccugl@haverford.edu> writes:
>
>> Hi! I'm interested in working on guile as part of the Google Summer of Code.
>>
> [...]
>> Currently I am thinking about:
>>
>> - A package manager (in the vein of apt-get)
>> I know this is one that's come up a bit. I was thinking of writing a
>> small web interface to browse packages, an aptitude style command-line
>> method for downloading, verifying the hashes, checking dependencies,
>> and then install the package(s) and an uninstall function as well. I
>> saw the proposal of working with dorodango; I might look at it, but
>> from what I saw of the code base, I thought it would make sense to try
>> to write a GUILE specific package-manager.
>>
> Could you be more specific?  What exactly in the code base did make you
> think so?
>
> Thanks, Rotty
> --
> Andreas Rottmann -- <http://rotty.yi.org/>
>

Re: Hi! Interested in GSoC. Feedback on these ideas?

[Paul Raccuglia]

Okay. So I'm settling on the idea of the package manager (not sure
what to call it. A CPAN style thingy.) I'm thinking of looking
primarily at dorodango or maybe Nix as resources,depending on what
makes sense in the context of Guile.


In (http://lists.gnu.org/archive/html/guile-devel/2011-03/msg00297.html)
this I saw a bunch of really useful points you made, Rotty. It seems
like Dorodango would be a great thing to work into this.

Because this is a project that has a lot of social implications for
Guile, I think that getting an idea of how the system would work (in
terms of syntax, specific function, etc.) would need a good deal of
input from the community.

My thought is to do the basic functionality needed (install,
uninstall, dependencies,getting the package, etc.), how to connect it
to Guile, and how the package server would work. Once those are
established, other functionality should be reasonably easy to add in a
modular fashion, if the project is designed well.

I'd really appreciate comments.

Paul

Re: Hi! Interested in GSoC. Feedback on these ideas?

[Paul Raccuglia]

Sorry. I should clarify. When I said "add in a modular fashion", I
meant that once that initial core was set up, it should be
(primitively) functional, and adding functionality to the package
manager would be something anyone could do.

Re: Hi! Interested in GSoC. Feedback on these ideas?

[dsmich]

---- Paul Raccuglia <praccugl@haverford.edu> wrote: 
> Okay. So I'm settling on the idea of the package manager (not sure
> what to call it. A CPAN style thingy.)

Oh, that's the easy part.  ;^)  How about "gear".  Could be something like Guile Extension Archive Repository.

Gears are finely machined components that mesh well together.  Also is the stuff you need to do something.  Like camping gear.

Just a thought anyway.

  -Dale

Re: Hi! Interested in GSoC. Feedback on these ideas?

[Paul Raccuglia]

Here's the raw text of my application. The deadline is in about 11
hours, but I'll try to take into account any feedback.
Thanks,
-Paul


Your name
   Paul Raccuglia
Your email address
   praccugl@haverford.edu
   praccu@gmail.com
The name of the project
Guile – Implementing a user-friendly package manager and repository
Summary
Guile lacks a centralized, easy-to-use system for installing packages.
In the vein of apt-get and CPAN, this project will simplify the
process of distributing and acquiring packages in Guile. There exist a
number of code bases that could be very useful for this implementation
(notably including http://nixos.org/nix/ and
http://home.gna.org/dorodango/ ). I will implement an online
repository and a local client to acquire, install, update and manage
packages and their dependencies.
Benefits
   This project will benefit users of Guile by making it easy for them
to incorporate packages into their software. This is a vital feature
of a number of widely adopted projects, notably PERL, PHP and Python
(http://en.wikipedia.org/wiki/List_of_software_package_management_systems#Application-level_package_managers).
A robust, easy-to-use package manager and repository would help Guile
achieve wider adoption: ideally, easy-to-install packages would
attract a wider audience, and a good distribution mechanism will help
developer’s packages gain wider adoption.
Deliverables
There will be some alterations to existing Guile code, but most of
this project’s code will be new features.  The project will rely on a
set of fundamental sections of code: client code that acquires and
verifies the package and any dependencies (or updates to installed
packages); code that manages the packages locally (installing and
uninstalling, storing, unpacking); and code that merges upgrades into
installed packages intelligently. The client code will likely draw
from other projects.
In addition to the fundamental parts of the project, a web based
repository browser will be needed. The project will establish a set of
conventions for how this repository functions, and provide an
implementation of a repository browser.
Once the core functionality of this project is in place, it should be
structured so that adding features is relatively painless. My goal is
for the code to be easy to improve and maintain in a way that does not
depend on my involvement.
Additionally, this project will need to establish an easy-to-use but
robust set of conventions for packages, which will require clear
documentation. Packages should be acquirable from an official
repository, but unofficial sources should be allowable if the user so
chooses.
Plan
Proposal Timeline:
Before April 25:
-Begin to work with the guile-devel mailing-list and irc to establish
the project's design and conventions
-Do self coding with Guile to explore it more fully
-Discuss the project with friends and professors in addition to the
feedback I get from the guile community

April 25 - May 23: (before coding begins)
-Work to finalize the working design and conventions of the project
with my mentor, based on my conversations with the Guile community
-Continuing to work with the mailing list and irc throughout this period
-Review other projects that have tackled similar problems, make
decisions with the help of my mentor and the Guile community on what
to incorporate into the project
-Revise this plan as needed based on feedback, have a finalized
timeline prepared by May 23



May 24 - June 7: (Step 1: basic functionality)
-Write a client interface to Dorodango that handles acquiring packages
-Work on the basic manager to install / uninstall acquired packages
-Finalize preliminary design documents related to the structure of a repository
-Send a progress report / summary to the guile-devel mailing list once
this stage is finalized
-Acquire feedback from the community

June 8 - 22: (Step 2: distribution)
-Begin work on implementation of a repository
	*Implement a website that handles a browsable list of available
packages and provides details, dependencies, links, etc.
	*Write rudimentary administrator interface to add/edit packages
	*Handle communication of the client with the repository to identify
the appropriate package's location
-Continue work on client to interface with the repository to find packages
-Send a progress report / summary to the guile-devel mailing list once
this stage is finalized
-Acquire feedback from the community

June 23 - July 3: (Step 3: flesh out functionality)
-Flesh out the functionality of the client and the package manager to
include dependencies, handle updating, and sketch other essential
features. Have a list of essential features to be implemented after
the midterm evaluation
-Handle issues that have cropped up in the interim
-Code should be functional by the end of this period


July 4 - July 14: (Step 4: Clean-up for review)
-Clean up code, write documentation, fix any outstanding issues, and
complete evaluation
-Send a progress report to the guile-devel mailing list

July 15 - 17:
-Take a break, compile a list of issues, and write a revised plan for
the rest of the summer

July 18 - August 1: (Step 5: Finish functionality)
-Work on the client and manager, have all essential features working
-Work on the web client for the repository

August 2 - 8: (Step 6: Make sure it is accessible to other developers)
-Modify the client and manager code to facilitate adding nonessential
features easily

Aug 9 - 16: (Step 7: Finish up)
-Resolve outstanding flaws

August 16 - 22: (Step 8: Clean up)
-Test things, write documentation, clean up the code

September onwards:
-Continue to help maintain and support the results of the project


Communication
Communication depends on the time zone of my mentor. Email, IRC, and
phone conversations would be the main channels of communication.
Additionally, I will use git to upload my progress to a personal
(publicly-viewable) repository preferably on a daily basis and at
minimum a weekly basis. I will upload progress to github.com or
gitorious.org to facilitate inline conversations about the code.
I would like to note that I know Noah Lavine, a contributor to Guile.
If I ended up working with him in some fashion, I would be able to
communicate easily with him because he is in the same time zone, and I
am comfortable working with him.
Qualification
I am a CS/Math student at Haverford College, in Pennsylvania. I have
been coding on my own for about 10 years now. My older brother is an
experienced developer who gave me a lot of guidance as I was learning
to code.
This project appeals to me because it is a vital feature that Guile
lacks, a feature which will be important in Guile’s wider adoption. I
think Guile is very exciting, and hope that easing the barrier to
installing packages will help it grow.
This project also appealed to me compared to other projects I looked
at because it is made up of a set of relatively distinct, quantifiable
parts, which gives me confidence that it was a problem I could tackle.
I am suited to this in part because I have a pretty good understanding
of the general issues at hand, am a quick learner, because I am
comfortable working in C or Scheme, and because I have been coding and
learning and reading for long enough (approximately 10 years) in
enough languages (Python, PHP, C, C#, plus some work with Scheme and
Perl) to be acquainted with principals and processes of software
design. Plus, my older brother is an experienced developer who
continues to give me a lot of guidance in both general best practices
and giving me specific feedback on my code.
I already have a lot of the fundamental programming skills. The most
important things for me to improve will be to thoroughly familiarize
myself with the problem (over the course of the summer) and to develop
a strong relationship with the Guile community.
Once the project is “finished”, I hope to be able to steward and help
others to expand it. Ideally, the project will be easy to help
maintain and expand, so that I can focus my efforts on a different
issue (I am interested in working on a JIT compiler for Guile).
I have not worked on any serious Free Software projects before, only
used them; I am excited to start giving back to a project.