guile-debugging: how to access source properties from trap context

guile-debugging: how to access source properties from trap context

[Holger Blasum]

[-- Attachment #1.1: Type: text/plain, Size: 2174 bytes --]

Hello guile-user,

in the "Guile Debugging Enhancements" tutorial 
(http://download.gna.org/guile-debugging/guile-debugging.html)
there is encouragement to play with the source trap context
parameters. 

What I want to look at are the source file names and 
line numbers like eg in any gdb stepping session of a C program
say for matrix multiplication like: 

gdb -f a.out
(gdb) br main
Breakpoint 1 at 0x8048417: file matrix.c, line 11.
(gdb) run
Starting program: /home/blasum/a/comp/sema/sample/c/samples/a.out 
/home/blasum/a/comp/sema/sample/c/samples/matrix.c:12
(gdb) step
/home/blasum/a/comp/sema/sample/c/samples/matrix.c:13
(gdb) step
/home/blasum/a/comp/sema/sample/c/samples/matrix.c:14
(gdb) step
...

How can one access file name and line number of the source
properties in guile-debugging?

My first shot was at 

$ guile
guile> (use-modules (ice-9 debugger) (ossau 
	ice-9-debugger-extensions) (ossau traps) (ossau trace))
guile> (load "matrix.scm")
guile> (define (report-exp trap-context)
    (display "Expression: ")
    (display (tc:expression trap-context))
    (newline))
guile> (install-trap (make <procedure-trap> #:procedure mkmatrix
#:behaviour (list report-exp)))
guile> (do-main 4)
Expression: #f
Expression: #f
guile>

However expression (#f might be ok, because we are dealing 
with vectors, and it *is* called twice) is the wrong 
attribute what I'm really looking for is not the evaluated 
expression (nor its uninterpreted source text) but its
source text's file name and line number ;) 

Any hints (even if they involve twiddling with traps.scm) very 
welcome ... (Credits for the matrix multiplication sample 
are to Peter Williams, matrix multiplication is not really 
what I am interested in but is perhaps a good example for 
testing a stepper.)

Happy 2006,

-- 
Holger Blasum +49-174-7313590 (gsm) GnuPG 1024D/ACDFC3B769DC1ED66B47
"It has turned out that the networking of many small computers, at many 
places, is more efficient than the one supercomputer - the success of 
the internet is based on this principle." - Angela Merkel, government
declaration, 30 Nov 2005

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-debugging: how to access source properties from trap context

[Neil Jerram]

Holger Blasum <holgerlists@blasum.net> writes:

> Hello guile-user,

Hi Holger,

> in the "Guile Debugging Enhancements" tutorial 
> (http://download.gna.org/guile-debugging/guile-debugging.html)
> there is encouragement to play with the source trap context
> parameters. 

It's not important for the rest of my reply, but can you indicate
exactly where in the doc you are referring to, so I can review whether
this encouragement is worded as well as it could be?

> What I want to look at are the source file names and 
> line numbers like eg in any gdb stepping session of a C program
> say for matrix multiplication like: 
>
> gdb -f a.out
> (gdb) br main
> Breakpoint 1 at 0x8048417: file matrix.c, line 11.
> (gdb) run
> Starting program: /home/blasum/a/comp/sema/sample/c/samples/a.out 
> /home/blasum/a/comp/sema/sample/c/samples/matrix.c:12
> (gdb) step
> /home/blasum/a/comp/sema/sample/c/samples/matrix.c:13
> (gdb) step
> /home/blasum/a/comp/sema/sample/c/samples/matrix.c:14
> (gdb) step
> ...
>
> How can one access file name and line number of the source
> properties in guile-debugging?

In theory, the trace/source procedure exported from (ossau trace)
should give you this.

Here's an example which works up to a point for me:

  (use-modules (ice-9 debugger) (ossau 
  	ice-9-debugger-extensions) (ossau traps) (ossau trace))
  (load "matrix.scm")
  (define (report-exp trap-context)
      (display "Expression: ")
      (display (trace/source trap-context))
      (newline))
  (install-trap (make <procedure-trap> #:procedure mkmatrix
  #:behaviour (list report-exp)))

  (do-main 4)

which prints:

  Expression: matrix.scm:6:2

Note, though, that my dummy matrix.scm looks like this ...

(define (mkmatrix)
  (let ((x 1))
    'this-is-a-matric))

(define (do-main n)
  (mkmatrix))

... so 6:2 is the location of the call to mkmatrix, not of mkmatrix's
own code.  Is that what you wanted?

I suspect not, because it doesn't map onto the GDB example that you
gave.  It sounds like what you might in fact want is a report of the
evaluation of each subexpression within mkmatrix.  In that case, the
correct incantation would be something like this:

  (use-modules (ice-9 debugger) (ossau 
  	ice-9-debugger-extensions) (ossau traps) (ossau trace) (ossau steps))
  (load "matrix.scm")

  (define (report-exp trap-context)
      (display "Expression: ")
      (display (trace/source trap-context))
      (newline))

  (define (report-subexps trap-context)
    (let ((step-trap (make <step-trap>
  		   #:file-name (frame-file-name (tc:frame trap-context))
  		   #:behaviour report-exp)))
      (install-trap step-trap)
      (at-exit (tc:depth trap-context)
  	     (lambda (trap-context)
  	       (uninstall-trap step-trap)))))

  (install-trap (make <procedure-trap> #:procedure mkmatrix
  #:behaviour (list report-subexps)))

For my dummy matrix.scm, this prints:

  Expression: matrix.scm:2:2
  Expression: matrix.scm:3:20
  Expression: matrix.scm:3:20

Does this help at all?  (I suspect not completely, so please write
more!)

        Neil




_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-debugging: how to access source properties from trap context

[Neil Jerram]

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

> It sounds like what you might in fact want is a report of the
> evaluation of each subexpression within mkmatrix.  In that case, the
> correct incantation would be something like this:

[complex incantations suppressed]

It occurred to me later that I should also point out a much simpler
option.  If you are just looking for something analogous to the GDB
example that you gave, you can get this much more easily as the
following session trace shows.

neil@laruns:~$ /usr/bin/guile -q
guile> (use-modules (ice-9 debugger) (ossau ice-9-debugger-extensions) (ossau breakpoints))
guile> (load "matrix.scm")
guile> (break-in 'mkmatrix #:behaviour debug-trap)
#<<break-in> 808cb70>
guile> (do-main 4)
This is the Guile debugger -- for help, type `help'.
There are 3 frames on the stack.

Frame 2:    [mkmatrix]
debug> next
Frame 3:    (let ((x 1)) (quote this-is-a-matric))
debug> info frame
Stack frame: 3
This frame is an evaluation.
The expression being evaluated is:
matrix.scm:3:3:
  (let ((x 1)) (quote this-is-a-matric))
debug> next
Frame 3:    (quote this-is-a-matric)
debug> bt
In unknown file:
   ?: 0* [primitive-eval (do-main 4)]
In standard input:
   5: 1* [do-main 4]
In matrix.scm:
   7: 2  [mkmatrix]
   ...
   4: 3  (quote this-is-a-matric)
debug> 

Or you can use the Emacs interface (GDS), by using (ossau gds-client)
instead of (ice-9 debugger) and (ossau ice-9-debugger-extensions), and
changing debug-trap to gds-debug-trap.

Hope this helps,

     Neil





_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-debugging: how to access source properties from trap context

[Holger Blasum]

[-- Attachment #1.1: Type: text/plain, Size: 2674 bytes --]

Hello Neil,

On 01-02 and 02-02, Neil Jerram wrote:
> Neil Jerram <neil@ossau.uklinux.net> writes:
... 
> debug> step
...
> debug> info frame
(iterate ad nauseam)

Thanks that was I was looking for! Hadn't thought of using
"info frame" to spit out the source properties (argh even gdb
does this).

FWIW, maybe I should explain (didnt want to bloat the first posting 
with that) that I am trying to study the inner workings of a theorem prover 
(minlog) so I'm tracing -crudely put- "where the action is". In addition, 
one (admittedly brute force) way of profiling anything in any system 
is just to pipe a long list of "step" + "info frame" into the guile 
[or whatever] stepper and parse the output 
for position information. (Moreover unlike a gprof-approach
I prefer not to loose the sequential order of what 
is called.)

What in that context of stepping would interest me is: is there 
also a trap not only for evaluations and applications but also for 
definitions (I mean performance-wise definitions dont come for free 
either). 

> It's not important for the rest of my reply, but can you indicate
> exactly where in the doc you are referring to, so I can review
> whether this encouragement is worded as well as it could be?

2.4.4 Trap Context: "This information can be accessed through
the procedures beginning tc: that are exported by the (ossau
traps) modules", this had insinuated to me that any
public method would have appeared as 'tc:'-prefixed one (defined 
in the <trap-context> class in the beginning of that source 
file) as opposed to the non 'tc:'-prefixed extra goodies 
you have now mentioned '(trace/source trap-context)'.

While we are at it, to give feedback, for the imperative-language-
impaired like me "2.10 Step Traps" maybe could be renamed to sth 
like "2.10 Step Traps and gdb-like stepping" including the small 
sample you had sent. And a note on profiling (perhaps 2.15?) 
could be sweet. (Disclaimer: these are just ramblings.)

At last, some words on "[FIXME: should we include examples of traditional
debuggers and explain why they can't be used to debug interpreted
Scheme or Lisp?]" 
http://www.gnu.org/software/guile/docs/guile-ref/Debugging-Features.html#Debugging%20Features
might be of interest to anyone still following this thread ;)

Thanks again!

-- 
Holger Blasum +49-174-7313590 (gsm) GnuPG 1024D/ACDFC3B769DC1ED66B47
"It has turned out that the networking of many small computers, at many 
places, is more efficient than the one supercomputer - the success of 
the internet is based on this principle." - Angela Merkel, government
declaration, 30 Nov 2005

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-debugging: how to access source properties from trap context

[Neil Jerram]

Holger Blasum <holgerlists@blasum.net> writes:

> Hello Neil,
>
> On 01-02 and 02-02, Neil Jerram wrote:
>> Neil Jerram <neil@ossau.uklinux.net> writes:
> ... 
>> debug> step
> ...
>> debug> info frame
> (iterate ad nauseam)
>
> Thanks that was I was looking for! Hadn't thought of using
> "info frame" to spit out the source properties (argh even gdb
> does this).

Perhaps it would make sense for the debugger to show the source
position automatically on each step?  What do you think?

>
> FWIW, maybe I should explain (didnt want to bloat the first posting 
> with that) that I am trying to study the inner workings of a theorem prover 
> (minlog) so I'm tracing -crudely put- "where the action is". In addition, 
> one (admittedly brute force) way of profiling anything in any system 
> is just to pipe a long list of "step" + "info frame" into the guile 
> [or whatever] stepper and parse the output 
> for position information. (Moreover unlike a gprof-approach
> I prefer not to loose the sequential order of what 
> is called.)

So are you really looking for a _non_-interactive solution then?

In that case I recommend the trace-trap and trace-until-exit
behaviours provided by (ossau trace), and `set-trace-layout' to
configure exactly what trace output you want at each trap point.
Here's an example:

guile> (use-modules (ossau breakpoints) (ossau trace))
guile> (load "matrix.scm")
guile> (break-in 'mkmatrix #:behaviour (list trace-trap trace-until-exit))
#<<break-in> 808b450>
guile> (do-main 4)
|  2: [mkmatrix]
|  3: [let (let # #) (# #)]
|  3: [let (let # #) (# #)]
|  3: (#@let* (x 1) #@let (quote this-is-a-matric))
|  2: (let ((x 1)) (quote this-is-a-matric))
|  3: [quote (quote this-is-a-matric) (# # #)]
|  3: [quote (quote this-is-a-matric) (# # #)]
|  3: (#@quote this-is-a-matric)
|  2: (quote this-is-a-matric)
|  2: this-is-a-matric
this-is-a-matric
guile> (set-trace-layout "~20@a: ~a\n" trace/source trace/info)          
guile> (do-main 4)
      matrix.scm:6:2: [mkmatrix]
      matrix.scm:2:2: (let ((x 1)) (quote this-is-a-matric))
     matrix.scm:3:20: (quote this-is-a-matric)
     matrix.scm:3:20: this-is-a-matric
this-is-a-matric
guile> 

(There are fewer trace lines for the second invocation of (do-main 4)
because of the effects of memoization, not because of the
set-trace-layout change.)

>
> What in that context of stepping would interest me is: is there 
> also a trap not only for evaluations and applications but also for 
> definitions (I mean performance-wise definitions dont come for free 
> either). 

Definitions are no different in principle, but it is harder to set up
a breakpoint to cover them, and they're not actually that interesting.

To set a breakpoint on a top level definition, you have to use
`break-at' with the file name, line number and column number of the
definition's opening parenthesis.  This kind of works ...

guile> (use-modules (ossau breakpoints) (ossau trace))
guile> (break-at "matrix.scm" 1 0 #:behaviour (list trace-trap trace-until-exit))
#<<break-at> 808b490>
guile> (set-trace-layout "~20@a: ~a\n" trace/source trace/info)
guile> (load "matrix.scm")
      matrix.scm:1:0: (define (mkmatrix) (define yy 23) (let ((x 1)) (quote this-is-a-matric)))
                    : [define (define # # #) (#)]
                    : [define (define # # #) (#)]
                    : (lambda () (define yy 23) (let ((x 1)) (quote this-is-a-matric)))
                    : [lambda (lambda () (define yy 23) ...) (#<eval-closure 4028db30>)]
                    : [lambda (lambda () (define yy 23) ...) (#<eval-closure 4028db30>)]
                    : (#@lambda () #@lambda (define yy 23) (let ((x 1)) (quote this-is-a-matric)))
                    : [module-make-local-var! #<directory (guile-user) 8085240> mkmatrix]
                    : [module-make-local-var! #<directory (guile-user) 8085240> mkmatrix]
                    : (or (let ((b (module-obarray-ref (module-obarray m) v))) (and (variable? b) (begin (module-modified m) b))) (and (module-binder m) ((module-binder m) m v #t)) (begin (let ((answer (make-undefined-variable))) (variable-set-name-hint! answer v) (module-obarray-set! (module-obarray m) v answer) (module-modified m) answer)))
                    : (let ((b (module-obarray-ref (module-obarray m) v))) (and (variable? b) (begin (module-modified m) b)))
                    : (module-obarray-ref (module-obarray m) v)
                    : (module-obarray m)
         ...

but (i) it's not very illuminating, because none of the body of the
definition is actually evaluated at this time, and (ii) once the
implicit lambda has been evaluated, the evaluator then goes into a
whole load of guff to do with the module system (which continues for
much longer than shown here).

(Internal definitions are a bit easier and clearer, because they don't
involve the module system.  For example, if I add an internal define
to my definition of mkmatrix:

guile> (use-modules (ossau breakpoints) (ossau trace))
guile> (load "matrix.scm")
guile> (break-in 'mkmatrix #:behaviour (list trace-trap trace-until-exit))
#<<break-in> 808b440>
guile> (set-trace-layout "~20@a: ~a\n" trace/source trace/info)
guile> (do-main 4)
      matrix.scm:7:2: [mkmatrix]
                    : [define (define yy 23) ((()) #<eval-closure 4028db30>)]
                    : [define (define yy 23) ((()) #<eval-closure 4028db30>)]
                    : (#@define yy 23)
                    : [let (let # #) (# #)]
                    : [let (let # #) (# #)]
                    : (#@let* (x 1) #@let (quote this-is-a-matric))
                    : (letrec ((yy 23)) (let ((x 1)) (quote this-is-a-matric)))
                    : [let (let # #) (# # #)]
                    : [let (let # #) (# # #)]
                    : (#@let* (x 1) #@let (quote this-is-a-matric))
      matrix.scm:3:2: (let ((x 1)) (quote this-is-a-matric))
                    : [quote (quote this-is-a-matric) ((x . 1) ((yy) 23) (()) ...)]
                    : [quote (quote this-is-a-matric) ((x . 1) ((yy) 23) (()) ...)]
                    : (#@quote this-is-a-matric)
     matrix.scm:4:20: (quote this-is-a-matric)
     matrix.scm:4:20: this-is-a-matric
this-is-a-matric
guile> (do-main 4)
      matrix.scm:7:2: [mkmatrix]
                    : (letrec ((yy 23)) (let ((x 1)) (quote this-is-a-matric)))
      matrix.scm:3:2: (let ((x 1)) (quote this-is-a-matric))
     matrix.scm:4:20: (quote this-is-a-matric)
     matrix.scm:4:20: this-is-a-matric
this-is-a-matric
guile> 

but I don't think you were talking about internal definitions.)

>> It's not important for the rest of my reply, but can you indicate
>> exactly where in the doc you are referring to, so I can review
>> whether this encouragement is worded as well as it could be?
>
> 2.4.4 Trap Context: "This information can be accessed through
> the procedures beginning tc: that are exported by the (ossau
> traps) modules", this had insinuated to me that any
> public method would have appeared as 'tc:'-prefixed one (defined 
> in the <trap-context> class in the beginning of that source 
> file) as opposed to the non 'tc:'-prefixed extra goodies 
> you have now mentioned '(trace/source trap-context)'.

Thanks.  Can you suggest some wording that would make it clear that
these are not the _only_ available procedures for getting information
out of a trap context?  (Perhaps something including a reference back
to 2.4.2?)

>
> While we are at it, to give feedback, for the imperative-language-
> impaired like me "2.10 Step Traps" maybe could be renamed to sth 
> like "2.10 Step Traps and gdb-like stepping" including the small 
> sample you had sent. And a note on profiling (perhaps 2.15?) 
> could be sweet. (Disclaimer: these are just ramblings.)

What about instead adding a whole new "Examples" chapter before the
current "Traps" one, containing the examples that we've discussed in
this thread, and other useful ones as they arise in future?  I think
that would be easier for a reader to find than an example buried
inside 2.10, and would allow 2.10 and its neighbours to keep their
existing more reference-style flavour.

Also, I'm still not quite clear what you mean by profiling.  Which of
the examples that we've discussed best fits what you have in mind?

>
> At last, some words on "[FIXME: should we include examples of traditional
> debuggers and explain why they can't be used to debug interpreted
> Scheme or Lisp?]" 
> http://www.gnu.org/software/guile/docs/guile-ref/Debugging-Features.html#Debugging%20Features
> might be of interest to anyone still following this thread ;)

I'm afraid I have no idea what the author of those words had in mind!
But in any case these words are no longer present in the CVS HEAD
version of the reference manual, so they will not be there when the
next major version of Guile (1.8) is released.

Regards,
        Neil



_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user

Re: guile-debugging: how to access source properties from trap context

[Holger Blasum]

[-- Attachment #1.1: Type: text/plain, Size: 5070 bytes --]

Hello Neil,

On 01-03, Neil Jerram wrote:
> Holger Blasum <holgerlists@blasum.net> writes:
> Perhaps it would make sense for the debugger to show the source
> position automatically on each step?  What do you think?

At least gdb, pydb (python) and ocamldebug (ocd) do this. But any
verbosity trade-offs are better left to your consideration ...
For reference here are the current ocamldebug and pydb default styles:
(ocd) s
Time : 2 - pc : 4164 - module Pervasives
112   float_of_bits 0x7F_F0_00_00_00_00_00_00L<|a|>
(pydb) step
?() at server.py:1
1    from SocketServer import StreamRequestHandler, ThreadingTCPServer

> So are you really looking for a _non_-interactive solution then?
> In that case I recommend the trace-trap and trace-until-exit
> behaviours provided by (ossau trace), and `set-trace-layout' to
> configure exactly what trace output you want at each trap point.

Wonderful, works great ;) 

> Thanks.  Can you suggest some wording that would make it clear that
> these are not the _only_ available procedures for getting information
> out of a trap context?  (Perhaps something including a reference back
> to 2.4.2?)

Perhaps: 
"In addition to the trap low-level context functions given in section 2.4.2, 
high-level trap context access is offered by the trap context
object. It is an object that ..." 
Perhaps merge 2.4.1 with 2.4.3 and 2.4.2 with 2.4.4? 

> What about instead adding a whole new "Examples" chapter before the
> current "Traps" one, containing the examples that we've discussed in
> this thread, and other useful ones as they arise in future?  I think
> that would be easier for a reader to find than an example buried
> inside 2.10, and would allow 2.10 and its neighbours to keep their
> existing more reference-style flavour.

Yes! For more feedback, I've also been asked whether instead of 
the number of applications I could give the number of time. (Like 
in petite scheme "(time (some-evaluation))").

> Also, I'm still not quite clear what you mean by profiling.  Which of
> the examples that we've discussed best fits what you have in mind?

The trace-trap example you gave last might fit closest. 

Just as a last addendum, I've run into a garbage-collection segfault 
with the combination minlog 4.0/guile-core.unstable-20060105/
guile-debugging-0.12/i686 GNU/Linux 2.6.14 #4.

(gdb) file /usr/local/bin/guile
(gdb) run
guile>  (use-modules (ossau breakpoints) (ossau trace))
guile> (debug-set! stack 0)
guile> (debug-set! depth 0)
guile> (debug-set! maxdepth 0)
guile> (debug-set! indent 0)
guile> (debug-set! width 0)
guile> (set-trace-layout "~20@a: ~a\n" trace/source trace/info)
guile> (break-in 'set-goal #:behaviour (list trace-trap
trace-until-exit))
guile> (load "examples/analysis/extraction.scm.guile")
Program <guile> received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211029280 (LWP 24947)]
0xb7f424d5 in scm_gc_mark (ptr=0xb6fb8490) at gc-mark.c:160
160     {
0xb7f36538 in scm_gc_mark (ptr=Variable "ptr" is not available.
) at gc-mark.c:168
168       scm_gc_mark_dependencies (ptr);
#0  0xb7f36538 in scm_gc_mark (ptr=Variable "ptr" is not available.
) at gc-mark.c:168
#1  0xb7f363e9 in scm_gc_mark_dependencies (p=0xb6085db0) at
gc-mark.c:270
#2  0xb7f3653d in scm_gc_mark (ptr=Variable "ptr" is not available.
) at gc-mark.c:168
...

Remarkably, one then can segfault gdb too by asking it via "bc -10" 
to spit out the ten outer 10 stack frames.

#149734 0xb7f70a19 in scm_shell (argc=1, argv=0xbfbd7cd4) at
script.c:737
#149735 0xb7f51515 in invoke_main_func (body_data=0xbfbd7c04) at
init.c:367
#149736 0xb7f25040 in c_body (d=0xbfbd7b78) at continuations.c:359
#149737 0xb7f91106 in scm_internal_catch (tag=0x104, body=0xb7f25030
<c_body>,
    body_data=0xbfbd7b78, handler=0xb7f25050 <c_handler>,
    handler_data=0xbfbd7b78) at throw.c:173
#149738 0xb7f2500d in scm_i_with_continuation_barrier (
    body=0xb7f25030 <c_body>, body_data=0xbfbd7b78,
    handler=0xb7f25050 <c_handler>, handler_data=0xbfbd7b78)
    at continuations.c:336
Program <gdb> received signal SIGSEGV, Segmentation fault.
0x08152319 in dwarf2_frame_cache (next_frame=0xfcf0698,
this_cache=0xfcf0ae8) at dwarf2-frame.c:637
(Info of last line of course comes from running "minlog from guile
from gdb from gdb".)

I then tried to find an easier test case to reproduce this (without
the theorem prover context), but (define (rec n) (case n ((1) 1) 
(else (rec (- n 1))))) does *not* break guile even on things 
like (rec 1000000) where presumably a million of frames is 
on the stack(?, if not how does one turn off tail recursion optimizations 
and the like) ... :(

Cheers,

-- 
Holger Blasum +49-174-7313590 (gsm) GnuPG 1024D/ACDFC3B769DC1ED66B47
"It has turned out that the networking of many small computers, at many 
places, is more efficient than the one supercomputer - the success of 
the internet is based on this principle." - Angela Merkel, government
declaration, 30 Nov 2005

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user