Hello all,
I've been accepted for GSoC 2011, and I'm excited to continue working
towards Guile-Emacs (: I'll be improving Guile's Emacs Lisp support and
will begin work on Emacs integration. I've included part of my project
proposal below.
Deliverables:
* Complete the Elisp subr library. Most of
Neil Jerram writes:
> The end result is that guile-tools is a lot shorter and (IMO) sweeter.
>
> Here are the titles of the following patches.
>
> [PATCH 1/5] Fix "occurrances" typos in getopt-long code and test
> [PATCH 2/5] Simplify getopt-long handling of option values, esp with
> multiple
Hi Janneke,
On Wed 23 Feb 2011 12:54, Jan Nieuwenhuizen writes:
> This morning I've spend some time to reduce this problem into
> a single scheme file, see attached.
>
> Again, here's what happens when I run it twice, starting from
> a clean cache.
>
> First run
>
> 12:47:07 janneke@vuur
On Wed 02 Feb 2011 15:02, Jan Nieuwenhuizen writes:
> Hi,
>
> See attached code, run using
>
>./run.scm
>
> 1.8 says:
>
> 14:58:59 janneke@vuurvlieg:~/vc/schikkers-list/remove
> $ ./run.scm
> WARNING: (use): `remove!' imported from both (srfi srfi-1) and (remove)
> : remove!
>
On Tue 15 Feb 2011 18:18, Ken Raeburn writes:
> On Feb 10, 2011, at 17:19, Andy Wingo wrote:
>>> procproc.c: There's a mutex to protect overrides, but it looks like
>>> set-procedure-property! doesn't use it correctly; it should look more
>>> like set-object-property! does.
>>
>> I'm going to pu
On Tue 15 Feb 2011 17:00, Ken Raeburn writes:
> On Feb 10, 2011, at 17:19, Andy Wingo wrote:
>>> symbols.c: I don't think 'symbols' is handled safely. But this code
> is
>>> all starting to run together in my mind. :-)
>>
>> I think I fixed this one a month ago or so.
>
> Hmm... maybe. It look
Hello all,
I really like the basic gist behind Noah's proposal, to allow programs
to optionally represent paths (roughly) as sequences of path components.
I haven't worked out all the details, and I'm glad to leave that job to
someone else, but I do have a few comments to add:
First of all, I thi
Hello all,
Andy and I have been discussing how to deal with pathnames on IRC.
The tentative plan is to use normal strings to represent pathnames,
command-line arguments, environmental variable values, and other such
POSIX byte strings.
We'd need to implement alternative conversions between POSIX
