<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.lisp.guile.devel">
    <title>gmane.lisp.guile.devel</title>
    <link>http://blog.gmane.org/gmane.lisp.guile.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14519"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14505"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14492"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14480"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14474"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14424"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14423"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14421"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14398"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14395"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14394"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14393"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14392"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14388"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14386"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14385"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14382"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14364"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14347"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.lisp.guile.devel/14343"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14519">
    <title>assembler in scheme</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14519</link>
    <description>&lt;pre&gt;I got an idea,

why not design a portable assembler that have a unifying simple core and try
to model a VM on that e.g. simple things will be naitive and complex
instructions
can be dispatched via a named goto.

The solution would fix a few registers like the bp and then have enough
instructions
to be able to dispatch and move objects in memory and implement correct
function call
semantics.

I would use two fixed hardware - registers.
1. bp: to track the function stack
2. vm: to track vm local data.

It would be cool if we could say to gcc to not clobber those registers and
compile the vm as before without
changing especially much but with some assembler to do the needed jump
correctly and also reach the register
associated data.


One idea was to use sassy, but it does only support x86.

Another idea is to port the sbcl assembler to scheme. This means that we
will get
assemblers for a larger set of targets but still not enough to be portable.

The final idea I got was to use the information in gcc or gas so&lt;/pre&gt;</description>
    <dc:creator>Stefan Israelsson Tampe</dc:creator>
    <dc:date>2012-05-26T18:34:12</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14505">
    <title>Error in wip-rtl</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14505</link>
    <description>&lt;pre&gt;Hello,

I tried to build the latest wip-rtl today, and hit an error that I
don't know how to debug. First, when the build gets to "GEN
guile-procedures.texi", I get a segmentation fault.

I tried to debug it by doing meta/gdb-uninstalled-guile. When I did
that, Guile made it to a command prompt, but when I try to evaluate
any sort of expression, even #t, I got "ERROR: unbound variable:
compile".

What might make that happen?

Thanks,
Noah


&lt;/pre&gt;</description>
    <dc:creator>Noah Lavine</dc:creator>
    <dc:date>2012-05-23T02:04:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14492">
    <title>a few proposed patches</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14492</link>
    <description>&lt;pre&gt;After reading the "dynamic ffi and C struct" thread this weekend, I started thinking, "I wonder if that's really done so as to handle X and Y and Z, and if we're actually testing it well enough", and got the urge to do another Mac build, which I hadn't done in a while.  After installing libgc 7.2 to get around flaky failures, and fighting with the build system a bit (I have gmp installed via Macports, and that tree also has libgc 7.1…), and waiting hours for builds to finish and looking into why, I have a few patches to propose.  I've uploaded them to the branch wip-raeburn-misc for review, since I'm not sure you'll want to address the issues the same way.

* Eliminate use of GC_PTR.  Looks like it's a holdover from earlier versions of libgc.  Some versions don't define it, so we do.  Apparently the 7.2 release defines it, too, which resulted in bug #11500.  It turns out, too, that some of the casts weren't quite right (casting to GC_PTR when GC_PTR* was needed), and only worked because GC_PTR is void* and&lt;/pre&gt;</description>
    <dc:creator>Ken Raeburn</dc:creator>
    <dc:date>2012-05-21T05:45:50</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14480">
    <title>problems evaluating code depending on version</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14480</link>
    <description>&lt;pre&gt;hi,

I'm trying to use this as a way to defined different versions of the code
depending on the
guile-version. So here it is,



(eval-when (compile load eval)
  (define (ver)
    (let ((v (version)))
      (cond
       ((string-match "^2.0" v)
        'v2.0)
       ((string-match "^2.1" v)
        'v2.1)
       (else #f)))))

(define-syntax guile-stuff
  (lambda (x)
    (syntax-case x ()
      (_
       (let ((q (ver)))
         (cond
          ((eq? q 'v2.0)
           #'(begin 1))
          ((eq? q 'v2.1)
           #'(begin
               (define-syntax-rule (fluid-let-syntax . l)
                 (syntax-parametrize . l))
               (export fluid-let-syntax)))
          (else (error "not supported version"))))))))

(guile-stuff)

This does not work in master (v2.1) why?
/Stefan
&lt;/pre&gt;</description>
    <dc:creator>Stefan Israelsson Tampe</dc:creator>
    <dc:date>2012-05-16T21:32:15</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14474">
    <title>bug in syntax-case in master</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14474</link>
    <description>&lt;pre&gt;I'm trying to port syntax-parse to master. And get into the following
trubble


(syntax-case x (integrate) ((integrate a b) ...))
fails, but

(syntax-case x (integrate) ((_ a b) ...))
does not fail


looking at the code for syntax-case I would expect that the datum integrate
is
match against and not using syntax any syntactic information.

In psyntax.scm around 2419 we have,
((bound-id-member? p keys)
 (values (vector 'free-id p) ids))

keys are the fixed datums, and

(define bound-id-member?
      (lambda (x list)
        (and (not (null? list))
             (or (bound-id=? x (car list))
                 (bound-id-member? x (cdr list))))))

e.g. no comparisons of the datum.

Is this correct! I do understand that this can be a feature but is this
expected?
In syntax parse both options are possible.

/Regards
Stefan
&lt;/pre&gt;</description>
    <dc:creator>Stefan Israelsson Tampe</dc:creator>
    <dc:date>2012-05-16T18:57:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14424">
    <title>terribly complex syntax objects in syntax parse</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14424</link>
    <description>&lt;pre&gt;Hi,

syntax-parse is kind of heavy right now. The parser function produced are
huge and the main reason
is that the stored syntax objects are enormous. I know that Mark Weaver had
done something to make
these creatures less fatty. The question is if there is anything a guile
user can do?

Regards
Stefan
&lt;/pre&gt;</description>
    <dc:creator>Stefan Israelsson Tampe</dc:creator>
    <dc:date>2012-05-14T19:54:25</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14423">
    <title>how to implement mutual recursive parsers in syntax-parse</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14423</link>
    <description>&lt;pre&gt;I do have a cludgy fix for this but are in search for a better solution.

consider the problem:

(define-syntax-class a (pattern (1 x:b)) (pattern ()))
(define-syntax-class b (pattern (2 x:a)) (pattern ()))

the syntax class definitions above would expand to something like

(begin
   (define parser-a code-a ...)
   (define-syntax a spec-a))

(begin
   (define parser-b code-b ...)
   (define-syntax b spec-b))

In racket they manage to evaluate the define-syntax forms before the
define-forms cause in the expansion
of code-a amd code-b they need the spec's spec-a and spec-b.

Do you have any ideas how solve this. I do have a fix for problem but it is
not easy to use.

/Stefan
&lt;/pre&gt;</description>
    <dc:creator>Stefan Israelsson Tampe</dc:creator>
    <dc:date>2012-05-14T19:13:11</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14421">
    <title>Making every goops object applicable</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14421</link>
    <description>&lt;pre&gt;In our work to look into how Python 3 could be implemented for Guile we
have figured out that the only way to make a goops object applicable is to
have it inherit &amp;lt;applicable-struct&amp;gt;. This does not always work the way it
could be expected, for example when inheriting from several classes.
Apparently this works by some flag being set by &amp;lt;applicable-strukt&amp;gt; in
libguile for the object and that flag is checked during application,
calling the 'procedure slot if it's set with some optimization assuming
that 'procedure is the first slot.
Is this correct and if so, is there any particular reasoning behind this
rather than just having all classes that has the slot 'procedure be
applicable?

Yours,
Krister Svanlund
&lt;/pre&gt;</description>
    <dc:creator>Krister Svanlund</dc:creator>
    <dc:date>2012-05-14T17:24:41</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14398">
    <title>[Proposal] Why not add a "shell" procedure?</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14398</link>
    <description>&lt;pre&gt;hi folks!
Sometimes we need to run shell script and get the result as string type.
Say, in Ruby:
irb: `ls`
==&amp;gt; "ice-9\nlanguage\nMakefile.am\nMakefile.am~\nMakefile.in\noop\nrnrs\nrnrs.scm\nscripts\nsrfi\nstatprof.scm\nsxml\nsystem\ntexinfo\ntexinfo.scm\nweb\n"

* Note: "system" lib function is useless for this, because "system"
can't return the result as string, but just the retval.

This feature is very easy to implement in Guile, but I recommend to
add a global env-var %current-shell to point any shell-interpreter,
like csh/bash/sh/..., or modify it as user wish.
The "shell" implementation maybe like this:
-------------code----------------
(define %current-shell (getenv "SHELL"))
(use-modules (ice-9 popen) (rnrs io ports))
(define shell
   (lambda (cmd)
       (let ((str (string-append %current-shell " -c " cmd)))
          (get-string-all (open-pipe str OPEN_READ)))))
-------------end----------------

and use it like regular shell:
(shell "sed -i \"s:guile/Guile/g" somefile")

Moreover, we can implement &lt;/pre&gt;</description>
    <dc:creator>Nala Ginrut</dc:creator>
    <dc:date>2012-05-12T12:30:21</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14395">
    <title>Wish List</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14395</link>
    <description>&lt;pre&gt;Hi all,

As I have been playing around with the sources of Guile, I looked at
the bug section on Savannah. I couldn't see much bugs and even less
bugs which are not pending already. Can anyone hint to some things
that are easy enough to pick up so I can start contributing something
sensible?

Regards,
Sjoerd


&lt;/pre&gt;</description>
    <dc:creator>Sjoerd van Leent</dc:creator>
    <dc:date>2012-05-11T19:16:08</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14394">
    <title>Register VM WIP</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14394</link>
    <description>&lt;pre&gt;Hi all,

This mail announces some very early work on a register VM.  The code is
in wip-rtl ("work in progress, register transfer language".  The latter
bit is something of a misnomer.).  There is not much there yet:
basically just the VM, an assembler, and a disassembler.  Still, it's
interesting, and I thought people might want to hear more about it.

So, the deal: why is it interesting to switch from a stack VM, which is
what we have, to a register VM?  There are three overriding
disadvantages to the current VM.

  1) With our stack VM, instructions are smaller.  They do less, so you
     need more of them.  This increases dispatch cost, which is the
     largest cost of a VM.

  2) On a stack VM, there is a penalty to naming values.  Since the only
     values that are accessible to an instruction are the ones on the
     top of the stack, whenever you want to use more names, you end up
     doing a lot of local-ref / local-set operations.  In contrast an
     instruction for a register VM can address ma&lt;/pre&gt;</description>
    <dc:creator>Andy Wingo</dc:creator>
    <dc:date>2012-05-11T16:19:35</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14393">
    <title>GOOPs, MOP and slots</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14393</link>
    <description>&lt;pre&gt;Hi!

In the CLOS-like language Closette presented in AMOP (The Art of the
Metaobject Protocol) there is a generic method named
`slot-value-using-class' which is used to access the slots of specific
instances. For example this method is used by `slot-value' (`slot-ref'
in GOOPs). In AMOP this generic method is used to implement classes
where every access and modification of slots is logged. It is also used
to implement a class with a kind of dynamic allocation of slots.

In GOOPs however the corresponding function `slot-ref-using-class' is
not generic. My question is if someone know why this is the case? Or
maybe someone can point me to some documentation which may contain
information about this?

My usecase if anyone wanted to know is to implement python-like
attributes as slots for instances. I.e. slots which is not class
specific but instead is only related to the current instance. These
slots should be accessible by using the standard `slot-ref' and
`slot-set! functions in GOOPs.

My guess is that by maki&lt;/pre&gt;</description>
    <dc:creator>David Spångberg</dc:creator>
    <dc:date>2012-05-11T12:19:20</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14392">
    <title>SRFI 64 and SRFI 78</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14392</link>
    <description>&lt;pre&gt;I'd posted a message in yesterday but it did not be posted; I think the
message subject made a problem. So, I re-post it.

---------- Forwarded message ----------
From: Sunjoong Lee &amp;lt;sunjoong&amp;lt; at &amp;gt;gmail.com&amp;gt;
Date: 2012/5/10
Subject: Re: SRFI-64 module and SRFI-78 module -- archive file attached
To: Noah Lavine &amp;lt;noah.b.lavine&amp;lt; at &amp;gt;gmail.com&amp;gt;
Cc: guile-devel&amp;lt; at &amp;gt;gnu.org


Hi, Noah;

I'd felt afraid of guile-devel&amp;lt; at &amp;gt;gnu.org because I'm just a newbie and a
poor enghlish reader/writer; especially of language problem.

Noah Lavine &amp;lt;noah.b.lavine&amp;lt; at &amp;gt;gmail.com&amp;gt; writes:


My goal? Hum... Like other people, I'd googled when I'd needed a test
suite. I'd heard the SRFI 64 and SRFI 78 but not been able to use it
then. So, I'd tried with unit-test in guile-lib.

unit-test is good but my concern was abnormal case, i.e., error or
exception. unit-test supports assert-exception macro but I feel
insufficient when unexpected exception occur. So, I was back to SRFI 64
and made it work on Guile.

I think there are people googling for test suite lik&lt;/pre&gt;</description>
    <dc:creator>Sunjoong Lee</dc:creator>
    <dc:date>2012-05-10T18:30:59</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14388">
    <title>patch to guile to allow c-code closure interaction for logicprogramming</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14388</link>
    <description>&lt;pre&gt;Hi all,

I post here a directory of patches and code that can be used to enhance
guile to interact nicely
with logic programming code written in C. I can reach very good performance
using this tool
please have a look and comment on it.

To note.

It does interact with the vm code, but it will not have any impact at all
with the respect to performance
or I believe crashing any other code then those using this tool.

Regards
Stefan
&lt;/pre&gt;</description>
    <dc:creator>Stefan Israelsson Tampe</dc:creator>
    <dc:date>2012-05-09T16:07:07</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14386">
    <title>stack closures for guile-log</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14386</link>
    <description>&lt;pre&gt;hi all,

I have now implemented stack closures that can be pushed out to the heap
if we want to store a state. This is how it works.

I have three stacks
1. a control stack that stores undo information scheme hooks aka
dynamic-wind and stack references to the other stacks.

2. stack from which data is allocated from like the bulk of a closure
and special pairs

3. a cons stack, e.g. an array of allocated conses

So to allocate a closure we allocate a cons c and a sequence of bytes
transformed
to a vector let the vector be located at the cdr and store a identifying
SCM object
that identifies that the cons represents a closure. and the cons is
returned as
the closure object with the vector filled with the closure data like C
function pointer
and associated closure data. Now If we mark a state as stored we simple
mark
the stacks for storage and when unwinding and seeing this mark the closure
data is copied
over to a heap allocated vector and then modify the same cons cell cdr
position with it
and then remove th&lt;/pre&gt;</description>
    <dc:creator>Stefan Israelsson Tampe</dc:creator>
    <dc:date>2012-05-08T19:16:19</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14385">
    <title>syntax parse link</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14385</link>
    <description>&lt;pre&gt;Hi,

I would like to add a link to the syntax-parse repo from guile's home page.
I was told to try get
the rights to do this myself. If that doesn't work I will need help from
any of the maintainers
to make the linkage.

NEWS: for syntax parse

I have written a fresh module using syntax parse to do racket's for,
for/list, etc. interface.
And have also started to work with an implementation of racket's match. It
has indeed been
a pleasure to work with the syntax parse framework and these two examples
can be studied
to see syntax-parse in action. It has also been a test-bed and I found that
racket's syntax parse
is lacking with respect to mutual recursive syntax-classes. Hence I added a
sane support for
this feature. E.g.

First prepend the code by declarations e.g.

(define-syntax-class ...)
Here the declaration has to be rich enough to contain all of the interface
that is later used for the syntax-class.

(syntax-class-set! ...) (New)
Has the same format as define-syntax-class but modifies the old
syntax-cla&lt;/pre&gt;</description>
    <dc:creator>Stefan Israelsson Tampe</dc:creator>
    <dc:date>2012-05-08T15:46:24</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14382">
    <title>Empty entries in $GUILE_LOAD_PATH</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14382</link>
    <description>&lt;pre&gt;Hello!

Try something like:

  $ GUILE_LOAD_PATH=/foo/bar: make check

… and see the LALR tests fail with:

  ERROR: In procedure primitive-load-path: Unable to find file "home/ludo/src/guile/test-suite/lalr/common-test.scm" in load path

(These tests use ‘load’.)

Is that expected?  What’s the meaning of empty entries in the load path?

Should ‘meta/uninstalled-env’ &amp;amp; co. clear $GUILE_LOAD_PATH?

Thanks,
Ludo’.



&lt;/pre&gt;</description>
    <dc:creator>Ludovic Courtès</dc:creator>
    <dc:date>2012-05-08T14:24:01</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14364">
    <title>Psyntax security hole prevents secure sandboxing in Guile</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14364</link>
    <description>&lt;pre&gt;Hello all,

Every once in a while someone asks about secure sandboxing with Guile,
and generally the response is that it should be fairly easy, by creating
a module with carefully selected bindings, but there's nothing ready
"out of the box".

I just realized that psyntax has a security hole that prevents secure
sandboxing, and wanted to post this fact before it was forgotten.

The problem is that psyntax accepts syntax-objects in the input, and
syntax-objects are simply vectors (or sexps containing vectors).
Therefore, it is always possible to _forge_ syntax-objects that refer to
arbitrary bindings in arbitrary modules, even if the usual bindings of
'&amp;lt; at &amp;gt;' and '&amp;lt; at &amp;gt;&amp;lt; at &amp;gt;' are not available.

In particular (although this is an internal implementation detail that
you cannot rely upon!) in Guile 2.0 the following two expressions are
treated equivalently:

  (&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; (ice-9 popen) open-pipe*)

  #(syntax-object open-pipe* ((top)) (hygiene ice-9 popen))

I don't think we can plug this hole until 2.2.

     Mark


&lt;/pre&gt;</description>
    <dc:creator>Mark H Weaver</dc:creator>
    <dc:date>2012-05-06T18:17:09</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14347">
    <title>Performance tracking</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14347</link>
    <description>&lt;pre&gt;Hello!

I was looking at the “history chart” at
&amp;lt;http://hydra.nixos.org/build/2517280#tabs-history&amp;gt;, which shows graphs
of the build time and installed Guile size vs. commits.  Timings must be
taken with a grain of salt, because of variability on the build machines.

Still, a couple of worthwhile observations:

  • commit 1af6d2a (“Minimize size of embedded syntax objects in
    psyntax-pp.scm”) reduced the installed size from ~14.6 MiB to
    ~13.3 MiB;

  • CSE led to a build time increase from 28m at
    &amp;lt;http://hydra.nixos.org/build/2413477&amp;gt; to 43m
    &amp;lt;http://hydra.nixos.org/build/2478518&amp;gt;.

Thanks,
Ludo’.



&lt;/pre&gt;</description>
    <dc:creator>Ludovic Courtès</dc:creator>
    <dc:date>2012-05-04T23:30:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14343">
    <title>Our temporary guildhall package repository down?</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14343</link>
    <description>&lt;pre&gt;http://rotty.yi.org/doro/experimental is unavailable for me. And ijp
said it's the same for him.
But Rottmann's site is OK.
Well, if there's some trouble with his site to put guildhall package
repository, I can provide a temporary repository from my web host.
I think this may let us test guildhall till it really works for Guile at least.
Or we may have one more alternative repository.

Could anyone give me all the things of 'experimental' directory? I can
upload them at once.
And my web host is available at least 2 years.


&lt;/pre&gt;</description>
    <dc:creator>Nala Ginrut</dc:creator>
    <dc:date>2012-05-04T08:25:10</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.lisp.guile.devel/14337">
    <title>[PATCH] Turn on more documentation</title>
    <link>http://comments.gmane.org/gmane.lisp.guile.devel/14337</link>
    <description>&lt;pre&gt;Hello all,

As part of my investigation into modules that don't have
documentation, I discovered that several modules in ice-9/ actually
have usable documentation that we are just not using in our build
process. (For reference, everything in the "Standard Library" section
of the manual is snarfed from .scm source files.) This patch makes
Guile build documentation for (ice-9 binary-ports), (ice-9
common-list), (ice-9 documentation), (ice-9 gap-buffer), (ice-9 runq),
(ice-9 serialize), and (ice-9 time). It gets incorporated into the
manual as part of the "Standard Library" section.

This seems like an easy way to get documentation for a few more
modules. What do you think?

(You may have to do "rm doc/ref/standard-library.texi &amp;amp;&amp;amp; rm
doc/ref/guile.info*" in order to build with the change. The makefile
doesn't know about all of the dependencies that it should.)

I also discovered while working on this that several modules have
in-line commentary and also hand-written texinfo pages. The list is
expect.scm, ftw.sc&lt;/pre&gt;</description>
    <dc:creator>Noah Lavine</dc:creator>
    <dc:date>2012-05-03T03:20:53</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.lisp.guile.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.lisp.guile.devel</link>
  </textinput>
</rdf:RDF>

