Re: Guile 64-bit Windows support, redux

[Thompson, David]

On Sat, Mar 23, 2024 at 11:09 AM Jonas Hahnfeld  wrote:
>
> On Wed, 2024-03-20 at 16:40 -0400, Thompson, David wrote:
> > On Wed, Mar 20, 2024 at 4:29 PM Jonas Hahnfeld  wrote:
> > > So I can confirm that JIT indeed doesn't work right now on 64-bit
> > > MinGW, but it's relatively easy to fix (first patch). In essence
> > > lightening was getting the calling convention wrong.
> >
> > Wow! Have you seen the JIT do its thing (via GUILE_JIT_LOG) or just
> > verified that compilation succeeds when JIT is enabled? Either way, a
> > big step forward. The patch is very simple, too.
>
> I had only verified that the produced LilyPond executable still worked,
> but I can now confirm that setting GUILE_JIT_LOG shows that something
> is happening. I don't have performance data on this yet, I asked the
> community to test the version on larger inputs.
>
> > > Compilation just works --with-threads, as long as bdwgc was built with
> > > --enable-threads=posix to override the automatic detection of win32
> > > threading. I haven't tested if it actually works, but there might be a
> > > good chance.
> >
> > This is also encouraging! Anyone out there want to run a test using
> > call-with-new-thread?
>
> So for the fun, I tried compiling --with-threads again and (call-with-
> new-thread) seems to return new threads.

Your patches look *very very* promising, then! I'm excited. :)

- Dave

Re: Guile 64-bit Windows support, redux

[Thompson, David]

On Wed, Mar 20, 2024 at 4:29 PM Jonas Hahnfeld  wrote:
>
> So I can confirm that JIT indeed doesn't work right now on 64-bit
> MinGW, but it's relatively easy to fix (first patch). In essence
> lightening was getting the calling convention wrong.

Wow! Have you seen the JIT do its thing (via GUILE_JIT_LOG) or just
verified that compilation succeeds when JIT is enabled? Either way, a
big step forward. The patch is very simple, too.

> Compilation just works --with-threads, as long as bdwgc was built with
> --enable-threads=posix to override the automatic detection of win32
> threading. I haven't tested if it actually works, but there might be a
> good chance.

This is also encouraging! Anyone out there want to run a test using
call-with-new-thread?

> For the one known issue I mentioned above, the fix is also not too
> difficult, just being a bit more careful with mixing scm_t_inum and
> long (see second patch).

The patch makes sense to me!

> I'm also explicitly CC'ing Andy and Ludo - we really need a statement
> by a maintainer whether this can land. From my point of view, it's a
> clear improvement in terms of supported platforms, plus tested by
> LilyPond since some time now which is probably one of the bigger
> "customers".

+1 on hearing from Andy and/or Ludo about this. Jonas' patches are
small and should be relatively quick to review. :)

If this stuff lands I will have to find a Windows machine to try it
out sometime.

Thanks Jonas!

- Dave

Re: Guile 64-bit Windows support, redux

[Thompson, David]

On Wed, Feb 7, 2024 at 3:19 PM Jonas Hahnfeld  wrote:
>
> On Wed, 2024-02-07 at 09:19 -0500, Thompson, David wrote:
> > On Thu, Jan 4, 2024 at 5:40 AM Jonas Hahnfeld via Developers list for
> > Guile, the GNU extensibility library  wrote:
> > >
> > > On Tue, 2023-11-28 at 22:04 +0100, Jonas Hahnfeld wrote:
> > > >
> > > > Ping, any comments on this approach? I built binaries for LilyPond
> > > > 2.25.10 using these patches applied on top of Guile 3.0.9 and the
> > > > result seems to work fine on Windows.
> > >
> > > Another ping; meanwhile we switched to building the official binaries
> > > of LilyPond with Guile 3.0 starting from version 2.25.11, but it would
> > > be really great to get rid of our downstream patches...
> >
> > Just chiming in to say this is a very exciting development that I had
> > missed when the patch set was first sent!
> >
> > Does this allow a fully featured Guile build or are some things still
> > disabled? Does JIT work?
>
> It's functional enough to run LilyPond (which uses quite a bit of
> Guile) and well enough so that there is only one complaint (that I know
> of so far) about multiplication with negative numbers not working
> right. If I remember correctly from quickly having a look, that's
> related to scm_integer_mul_ii using long_magnitude which doesn't quite
> work on Windows 64-bit. For LilyPond, we disable some features (JIT,
> threading, networking; you can look at the full build recipe here:
> https://gitlab.com/lilypond/lilypond/-/blob/master/release/binaries/lib/dependencies.py#L628
> ) and I don't know which of these would work or how much it would take
> to support them.

Ah, bummer. That's a lot of disabled features.  JIT and threads are
must-haves for my use-cases.  I guess I'll continue waiting for
someone to figure out how to build a fully featured Guile on Windows.
Any takers? ;)

- Dave

Re: Guile 64-bit Windows support, redux

[Thompson, David]

On Thu, Jan 4, 2024 at 5:40 AM Jonas Hahnfeld via Developers list for
Guile, the GNU extensibility library  wrote:
>
> On Tue, 2023-11-28 at 22:04 +0100, Jonas Hahnfeld wrote:
> >
> > Ping, any comments on this approach? I built binaries for LilyPond
> > 2.25.10 using these patches applied on top of Guile 3.0.9 and the
> > result seems to work fine on Windows.
>
> Another ping; meanwhile we switched to building the official binaries
> of LilyPond with Guile 3.0 starting from version 2.25.11, but it would
> be really great to get rid of our downstream patches...

Just chiming in to say this is a very exciting development that I had
missed when the patch set was first sent!

Does this allow a fully featured Guile build or are some things still
disabled? Does JIT work?

Hopefully Ludo or Andy can spare some time to review soon!

- Dave

Re: The message chain with an happy ending

[Thompson, David]

On Wed, Jul 5, 2023 at 6:43 AM Blake Shaw via Developers list for
Guile, the GNU extensibility library  wrote:
>
> I think the guile mailing list has come to suffer seriously from a policing 
> of what is appropriate for discussion. When I first started getting into 
> guile at the beginning of 2021, the list was more open, active and enjoyable. 
> Since then it has become a ghost town where tumbleweeds blow by in the time 
> that remains between intermittent duals. But strangely there are still lots 
> of people living in the town (ie guile users), they just seldom visit main 
> street these days.

In general, I agree. Maybe this one would have been better for
guile-user, though. :)

This particular email came across kinda spammy given the huge number
of CCs, so I initially ignored it. Stefan, I think people would be
more likely to read your emails if you didn't do that.

- Dave

Re: Functional datatypes in Guile

[Thompson, David]

Hi pukkamustard,

On Tue, Feb 28, 2023 at 3:34 AM pukkamustard  wrote:
>
>
> I've been using SRFI-146
> (https://srfi.schemers.org/srfi-146/srfi-146.html) for functional
> mappings. There's a Guile port:
> https://inqlab.net/git/guile-srfi-146.git/ (also in Guix -
> guile-srfi-146).

Your Guile port of (srfi srfi-146 hash) looks really nice!  A
functional hash is the most important data structure for our needs at
Spritely. Do you know if it's thread-safe (unlike vhashes)?  Andy's
fash implementation uses atomic boxes, for example.

Also, what are your thoughts on read syntax?  I find myself using
alists more often than I probably should because the syntax is
pleasant.  (hashmap comparator 'foo 1 'bar 2) is... okay, but terse
syntax for the common case of a hash with literal keys would be nice.
For example, #hq((foo 1) (bar 2)) for a hash with keys compared with
eq?  Scheme is kind of odd for not having hash literal syntax.

> I've previously used pfds (as mentioned by Maxime), but I've encountered
> some nasty issues that are keeping me from using it again
> (https://github.com/ijp/pfds/issues/5).

Good to know about this issue, thanks!

- Dave

Re: GNU Guile 3.0.9rc1 available for testing!

[Thompson, David]

Hi Ludo,

On Fri, Jan 20, 2023 at 10:58 AM Ludovic Courtès  wrote:
>
> Please report any issues you may find.  I’m particularly interested in
> portability regressions (NetBSD and other BSDs, macOS, MinGW, as well as
> architectures other than x86_64).

I was curious about the MinGW build, so I used a Guix command you
shared to build it:

guix build guile-next --with-git-url=guile-next=$HOME/Code/guile
--with-branch=guile-next=main --target=x86_64-w64-mingw32

I then copied the resulting /gnu/store directory somewhere writable,
copied over all the DLLs (libgc, libunistring, etc.) it needed from
/gnu/store into the 'bin' directory, and tried running with wine64 but
it failed:

```
$ guix shell wine64 -- wine64 guile.exe
MESA-INTEL: warning: Performance support disabled, consider sysctl
dev.i915.perf_stream_paranoid=0

0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 0005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 0005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 0005
0084:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 0005
Mingw-w64 runtime failure:
32 bit pseudo relocation at 000140001568 out of range, targeting
000319370E80, yielding the value 0001D936F914.

abnormal program termination
```

Maybe someone else would like to give it a shot? Or even try running
it on Windows?  I hadn't tried in years, but my last experience with a
Guile MinGW build required either disabling threads and JIT or trying
to apply various patches people had floating around. So, to see a
build complete with just the upstream source and without disabling
anything is very promising!

Thanks for all the hard work on the release!

- Dave

Re: [EXT] Re: [PATCH] Add 'bytevector-slice'.

[Thompson, David]

On Wed, Jan 11, 2023 at 12:34 PM Ludovic Courtès  wrote:
>
> What could be convenient though is ‘bytevector-copy’ (no bang), which
> would combine ‘make-bytevector’ + ‘bytevector-copy!’.

'bytevector-copy' already exists, or do you mean some different
implementation of it?

- Dave

Re: [PATCH] Add 'bytevector-slice'.

[Thompson, David]

Hi Ludovic,

On Wed, Jan 11, 2023 at 10:00 AM Ludovic Courtès  wrote:
>
> +@node Bytevector Slices
> +@subsubsection Bytevector Slices
> +
> +@cindex subset, of a bytevector
> +@cindex slice, of a bytevector
> +@cindex slice, of a uniform vector
> +As an extension to the R6RS specification, the @code{(rnrs bytevectors
> +gnu)} module provides the @code{bytevector-slice} procedure, which
> +returns a bytevector aliasing part of an existing bytevector.
> +
> +@deffn {Scheme Procedure} bytevector-slice @var{bv} @var{offset} [@var{size}]
> +@deffnx {C Function} scm_bytevector_slice (@var{bv}, @var{offset}, 
> @var{size})
> +Return the slice of @var{bv} starting at @var{offset} and counting
> +@var{size} bytes.  When @var{size} is omitted, the slice covers all
> +of @var{bv} starting from @var{offset}.  The returned slice shares
> +storage with @var{bv}: changes to the slice are visible in @var{bv}
> +and vice-versa.

Just wanted to chime in to say that this is a really great new
feature! Bytevector slices will be very useful for performance
sensitive code that could benefit from using a pre-allocated memory
arena.

Really really great stuff! Thank you!

- Dave

Re: Relaxing the copyright assignment policy

[Thompson, David]

Hi Ludovic and Andy,

Great news!  Thanks for lowering the barrier to entry for new contributors!

- Dave

Re: [EXT] (ice-9 base64)?

[Thompson, David]

+1 to that. I do the same thing in my own projects. Guix does it, too.

- Dave

On Tue, Aug 16, 2022 at 12:11 PM Aleix Conchillo Flaqué <
aconchi...@gmail.com> wrote:

> Hi,
>
> In many projects I've been copying Göran Weinholt's base64 implementation
> and I've also seen it in other projects, would it make sense to include it
> in Guile's standard library?
>
> I guess it's hard to know where to draw a line and different languages do
> different things. I actually like Golang's approach where they provide a
> bunch of base libraries (web, crypto, etc.) and it seems that's where Guile
> was going by including a web library.You could always use a different
> implementation if it existed.
>
> Anyways, I think (ice-9 base64) would be a nice addition.
>
> Just a thought.
>
> Aleix
>
>

Re: guile 3 update, halloween edition

[Thompson, David]

On Wed, Oct 30, 2019 at 4:55 PM Andy Wingo  wrote:
>
> Thoughts welcome!  Also: should these structured error objects be named
> exceptions or conditions?  SRFI-35, R6RS, and R7RS say "conditions", but
> racket and my heart say "exceptions"; wdyt?

I think "exceptions" is a better name for the reasons others have
already stated.

Excited for 3.0!

- Dave

Re: conflicts in the gnu project now affect guile

[Thompson, David]

On Fri, Oct 18, 2019 at 9:33 AM Christopher Lemmer Webber
 wrote:
>
> Mark H Weaver writes:
>
> > [resending with fixed headers, for proper threading]
> >
> > Hi Christopher,
> >
> > Christopher Lemmer Webber  wrote:
> >> I think *RMS's* action of unilaterally re-appointing Mark without
> >> notifying or asking the other maintainers
> >
> > Did you not see my recent correction about this?  I CC'd you,
> > but maybe something went wrong.  Please see:
> >
> >   https://lists.gnu.org/archive/html/guile-devel/2019-10/msg00031.html
> >
> > I'll respond to the rest of your post in a future message.
>
> Oh, I didn't see it... my mistake.  (I am in extreme email backlog mode,
> but that's no excuse: I should have read the rest of the thread before
> posting.)
>
> I appreciate you clarifying this and do find that dramatically less
> jarring than if there was a unilateral appointment.

Yes, this is less worrisome.  All I wish is that the maintainer team
be built on mutual respect and cooperation rather than the divine
appointments of a dictator.  I hope everyone can come to an agreement.

- Dave

Re: conflicts in the gnu project now affect guile

[Thompson, David]

On Wed, Oct 16, 2019 at 9:14 AM Andy Wingo  wrote:
>
> Perhaps this moment is an opportunity, to see where the Guile community
> stands.  In that spirit I invite Guile community members to weigh in on
> the issue.  What do you think about Guile's continued relationship with
> GNU?  What about its relationship with RMS?  Finally, what would you
> like to see happen regarding the future of Guile?

A bit of context about myself and what has shaped my feelings on the
matter: In 2014 I was hired at the FSF as a web developer. In 2015 I
quit because the work environment that RMS is ultimately responsible
for was demotivating and sad.  All of my former FSF coworkers, some of
whom sincerely tried (and failed) to make positive change, have since
moved on due to similar frustrations.  In 2018 I disassociated myself
with GNU (as in I no longer identify as a GNU hacker, as there is no
formal association) after witnessing RMS rudely interrupt and derail
Bradley Kuhn's LibrePlanet session and insist that conference rules do
not apply to him.  That was the last straw for me, personally, but
this pressure had been building for years.

However, I have felt, and continue to feel, that Guile is an oasis in
the GNU desert and a large part of that is because it has maintainers
that truly care about creating a welcoming environment and not
tolerating bigotry in the name of "free speech."  Andy, Ludovic, and
Mark, I owe each of you much gratitude for all the help and positive
messages I've received since 2012 or so when I discovered Guile.  I
love free software, and I especially love Guile. Thank you, thank you,
thank you.

Now, onto the present.  Seeing Mark step down from as a Guile
co-maintainer was an indicator that something was amiss internally
with Guile.  I have a great respect for Mark, but I must admit that
I've been extremely disappointed to see him, on internal GNU lists,
steadfastly defending what I consider indefensible behavior by RMS.
Upon seeing the mail to this list that Mark was stepping back into his
co-maintainer role, I had assumed that Andy and Mark had worked
through their differences and disagreements and was glad.  But now
that I know that the truth is that RMS, as chief nuisance, put Mark
back into this role without the consent of either active Guile
co-maintainer, and without even telling them, I am extremely
disappointed and I do not approve.  RMS, once again, has abused his
leadership role to make unilateral decisions to the detriment of a GNU
project.  Yet another data point that reinforces my belief that when
RMS "leads" the results are negative.  This is not the behavior of a
leader that I support, and I certainly don't personally recognize him
as the leader of GNU.  He truly is a broken stair, a stick in the mud,
a roadblock.  What happens if we pay no mind to him?  Does the GNU
brand mean anything at this point?  If anything, it's probably
negative.

As for the future, I would like to see Guile continue to be the
welcoming, inclusive, productive place it has been since I've known
it, even though it may require some socially difficult decisions.
Andy and Ludovic, you have my support.  You've responded to recent
events admirably even though it meant being personally attacked by
others within GNU and outside.  Mark, I urge you to reconsider where
you stand with RMS.  I know that you have a lot of history, but times
have changed.

Regards,

- Dave

Re: [ANN] Guile-SDL2 0.4.0 released

[Thompson, David]

Apologies! Meant to send to guile-user. :(

[ANN] Guile-SDL2 0.4.0 released

[Thompson, David]

I'm happy to announce that Guile-SDL2 0.4.0 has been released!
Guile-SDL2 provides bindings for the SDL2 game programming
library. The bindings are written in pure Scheme using Guile's foreign
function interface.

This release features several new bindings:

* SDL_BlitScaled
* SDL_BlitSurface
* SDL_DestroyTexture
* SDL_FillRect
* SDL_RenderCopyEx
* SDL_RenderDrawLine
* SDL_RenderDrawLines
* SDL_RenderDrawPoint
* SDL_RenderDrawPoints

Thanks to Pierre-Antoine Rouby for contributing many of these new
bindings!

tarball: 

signature: 

See  for more information.

- Dave

unboxing floats in libguile procedures that always return floats?

[Thompson, David]

Hello all,

Guile's current floating point unboxing optimizations are great and
have helped me immensely, but they still leave something to be
desired. I often find myself often calling libguile procedures such as
sin, cos, and random:uniform.  These procedures always return floats,
yet Guile always boxes them, leaving me stuck with procedures that
make lots of garbage despite my best efforts to generate efficient
bytecode.  Would it be possible for the compiler to know that it can
safely unbox functions like sin and cos?  It would really help reduce
GC for realtime graphics rendering applications, for example.

Thanks,

- Dave

Re: Guile 3 update, August edition

[Thompson, David]

On Mon, Aug 20, 2018 at 10:27 AM, Andy Wingo  wrote:
> In this particular example, the JITted code runs about 3x faster than
> the interpreted code.  The JIT doesn't do register allocation; not sure
> precisely how to do that.  A future topic.  For the moment I want to
> consolidate what we have and once it's all just magically working and
> everybody's programs are faster, we release Guile 3.

Echoing everyone else: This is very exciting! I can't wait to take it
for a spin.  Thank you!

- Dave

Re: Simple picture language

[Thompson, David]

On Mon, Mar 26, 2018 at 5:51 PM, Ricardo Wurmus  wrote:
> Hi Guilers,
>
> I wrote a simple SVG-based picture language.

Wow! I never would have thought to use sxml to generate svg files. I
always thought we would have to use cairo or some custom renderer in
order to have a picture language. This is a great hack!

- Dave

Re: Website translations with Haunt

[Thompson, David]

Hey everyone!

On Thu, Dec 14, 2017 at 4:16 AM, Ludovic Courtès  wrote:
> Hi!
>
> "pelzflorian (Florian Pelz)"  skribis:
>
>> I want to ask for your thoughts on my new solution since translations
>> are probably important to many Haunt users.  In particular, I believe
>> there was some discussion on Website translation on the Guile or Guix
>> lists as well.
>
> I’d love those sites to support translation!  If we could integrate your
> solution as a Haunt extension or something, that’d be great.

I agree! Thanks to everyone that is working on this. I would love to
include translation support in Haunt but I'm completely clueless about
the right way to do things, so I'd be happy to receive some patches
that implement it nicely. :)

Thanks again!

- Dave

Re: What's required to include sxml->html?

[Thompson, David]

>From what I can tell, this is more-or-less my (haunt html) module [0]
with the import/export syntax changed and a hack to special-case

Re: [PATCH] Add unboxed floating point comparison instructions.

[Thompson, David]

Hi Andy,

On Mon, Jan 9, 2017 at 4:23 PM, Andy Wingo <wi...@pobox.com> wrote:
> On Mon 09 Jan 2017 02:09, "Thompson, David" <dthomps...@worcester.edu> writes:
>
>> +  /* br-if-f64= a:12 b:12 invert:1 _:7 offset:24
>
> Missing - before the =.
>
>> +  /* br-if-f64< a:12 b:12 invert:1 _:7 offset:24
>
> Here too.
>
> Please fix these nits and then LGTM; please push directly.  Thanks!

Pushed.  Thanks for all of your help!

- Dave

Re: [PATCH] Add unboxed floating point comparison instructions.

[Thompson, David]

Hi Andy,

On Mon, Jan 9, 2017 at 4:23 PM, Andy Wingo <wi...@pobox.com> wrote:
> On Mon 09 Jan 2017 02:09, "Thompson, David" <dthomps...@worcester.edu> writes:
>
>> +  /* br-if-f64= a:12 b:12 invert:1 _:7 offset:24
>
> Missing - before the =.
>
>> +  /* br-if-f64< a:12 b:12 invert:1 _:7 offset:24
>
> Here too.

Oops! Good eye.  Fixed.

> Please fix these nits and then LGTM; please push directly.  Thanks!

I would push directly but I do not have commit access.  Could you
please apply the attached patch when you have a chance?

Thanks,

- Dave
From 160f240acd3378bcf5360157aa19e229d2b2f3a4 Mon Sep 17 00:00:00 2001
From: David Thompson <dthomps...@worcester.edu>
Date: Mon, 12 Dec 2016 22:46:08 -0500
Subject: [PATCH] Add unboxed floating point comparison instructions.

* libguile/vm-engine.c (BR_F64_ARITHMETIC): New preprocessor macro.
(br_if_f64_ee, br_if_f64_lt, br_if_f64_le, br_if_f64_gt, br_if_f64_ge):
New VM instructions.
* doc/ref/vm.texi ("Unboxed Floating-Point Arithmetic"): Document them.
* module/language/cps/compile-bytecode.scm (compile-function): Emit f64
comparison instructions.
* module/language/cps/effects-analysis.scm: Define effects for f64
primcalls.
* module/language/cps/primitives.scm (*branching-primcall-arities*): Add
arities for f64 primcalls.
* module/language/cps/specialize-numbers.scm (specialize-f64-comparison):
New procedure.
(specialize-operations): Specialize f64 comparisons.
* module/system/vm/assembler.scm (emit-br-if-f64-=, emit-br-if-f64-<)
(emit-br-if-f64-<=, emit-br-if-f64->, emit-br-if-f64->=): Export.
* module/system/vm/disassembler.scm (code-annotation): Add annotations
for f64 comparison instructions.
---
 doc/ref/vm.texi| 10 
 libguile/vm-engine.c   | 73 --
 module/language/cps/compile-bytecode.scm   |  7 ++-
 module/language/cps/effects-analysis.scm   |  5 ++
 module/language/cps/primitives.scm |  7 ++-
 module/language/cps/specialize-numbers.scm | 52 +++--
 module/language/cps/type-fold.scm  |  5 ++
 module/system/vm/assembler.scm |  5 ++
 module/system/vm/disassembler.scm  |  2 +
 9 files changed, 145 insertions(+), 21 deletions(-)

diff --git a/doc/ref/vm.texi b/doc/ref/vm.texi
index 1abbbce..4e42bb9 100644
--- a/doc/ref/vm.texi
+++ b/doc/ref/vm.texi
@@ -1674,3 +1674,13 @@ the operands as unboxed IEEE double floating-point numbers, and producing
 the same.
 @end deftypefn
 
+@deftypefn Instruction {} br-if-f64-= s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+@deftypefnx Instruction {} br-if-f64-< s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+@deftypefnx Instruction {} br-if-f64-<= s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+@deftypefnx Instruction {} br-if-f64-> s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+@deftypefnx Instruction {} br-if-f64->= s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+If the unboxed IEEE double value in @var{a} is @code{=}, @code{<},
+@code{<=}, @code{>}, or @code{>=} to the unboxed IEEE double value in
+@var{b}, respectively, add @var{offset} to the current instruction
+pointer.
+@end deftypefn
diff --git a/libguile/vm-engine.c b/libguile/vm-engine.c
index 195237a..6848406 100644
--- a/libguile/vm-engine.c
+++ b/libguile/vm-engine.c
@@ -358,6 +358,24 @@
 NEXT (3);   \
   }
 
+#define BR_F64_ARITHMETIC(crel) \
+  { \
+scm_t_uint32 a, b;  \
+scm_t_uint64 x, y;  \
+UNPACK_24 (op, a);  \
+UNPACK_24 (ip[1], b);   \
+x = SP_REF_F64 (a); \
+y = SP_REF_F64 (b); \
+if ((ip[2] & 0x1) ? !(x crel y) : (x crel y))   \
+  { \
+scm_t_int32 offset = ip[2]; \
+offset >>= 8; /* Sign-extending shift. */   \
+NEXT (offset);  \
+  } \
+NEXT (3);   \
+  }
+
+
 #define ARGS1(a1)   \
   scm_t_uint16 dst, src;\
   SCM a1;   \
@@ -3935,11 +3953,56

Re: [PATCH] Add unboxed floating point comparison instructions.

[Thompson, David]

Hi Andy,

Thanks for the feedback. I believe this new patch addresses everything
you asked me to fix. Am I in time for 2.1.6? ;)

- Dave
From bfd7b4f343c5f5cc8761c8d1fed1f61ba564a5dd Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 12 Dec 2016 22:46:08 -0500
Subject: [PATCH] Add unboxed floating point comparison instructions.

* libguile/vm-engine.c (BR_F64_ARITHMETIC): New preprocessor macro.
(br_if_f64_ee, br_if_f64_lt, br_if_f64_le, br_if_f64_gt, br_if_f64_ge):
New VM instructions.
* doc/ref/vm.texi ("Unboxed Floating-Point Arithmetic"): Document them.
* module/language/cps/compile-bytecode.scm (compile-function): Emit f64
comparison instructions.
* module/language/cps/effects-analysis.scm: Define effects for f64
primcalls.
* module/language/cps/primitives.scm (*branching-primcall-arities*): Add
arities for f64 primcalls.
* module/language/cps/specialize-numbers.scm (specialize-f64-comparison):
New procedure.
(specialize-operations): Specialize f64 comparisons.
* module/system/vm/assembler.scm (emit-br-if-f64-=, emit-br-if-f64-<)
(emit-br-if-f64-<=, emit-br-if-f64->, emit-br-if-f64->=): Export.
* module/system/vm/disassembler.scm (code-annotation): Add annotations
for f64 comparison instructions.
---
 doc/ref/vm.texi| 10 
 libguile/vm-engine.c   | 73 --
 module/language/cps/compile-bytecode.scm   |  7 ++-
 module/language/cps/effects-analysis.scm   |  5 ++
 module/language/cps/primitives.scm |  7 ++-
 module/language/cps/specialize-numbers.scm | 52 +++--
 module/language/cps/type-fold.scm  |  5 ++
 module/system/vm/assembler.scm |  5 ++
 module/system/vm/disassembler.scm  |  2 +
 9 files changed, 145 insertions(+), 21 deletions(-)

diff --git a/doc/ref/vm.texi b/doc/ref/vm.texi
index 1abbbce..4e42bb9 100644
--- a/doc/ref/vm.texi
+++ b/doc/ref/vm.texi
@@ -1674,3 +1674,13 @@ the operands as unboxed IEEE double floating-point numbers, and producing
 the same.
 @end deftypefn
 
+@deftypefn Instruction {} br-if-f64-= s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+@deftypefnx Instruction {} br-if-f64-< s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+@deftypefnx Instruction {} br-if-f64-<= s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+@deftypefnx Instruction {} br-if-f64-> s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+@deftypefnx Instruction {} br-if-f64->= s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+If the unboxed IEEE double value in @var{a} is @code{=}, @code{<},
+@code{<=}, @code{>}, or @code{>=} to the unboxed IEEE double value in
+@var{b}, respectively, add @var{offset} to the current instruction
+pointer.
+@end deftypefn
diff --git a/libguile/vm-engine.c b/libguile/vm-engine.c
index 195237a..e9ec648 100644
--- a/libguile/vm-engine.c
+++ b/libguile/vm-engine.c
@@ -358,6 +358,24 @@
 NEXT (3);   \
   }
 
+#define BR_F64_ARITHMETIC(crel) \
+  { \
+scm_t_uint32 a, b;  \
+scm_t_uint64 x, y;  \
+UNPACK_24 (op, a);  \
+UNPACK_24 (ip[1], b);   \
+x = SP_REF_F64 (a); \
+y = SP_REF_F64 (b); \
+if ((ip[2] & 0x1) ? !(x crel y) : (x crel y))   \
+  { \
+scm_t_int32 offset = ip[2]; \
+offset >>= 8; /* Sign-extending shift. */   \
+NEXT (offset);  \
+  } \
+NEXT (3);   \
+  }
+
+
 #define ARGS1(a1)   \
   scm_t_uint16 dst, src;\
   SCM a1;   \
@@ -3935,11 +3953,56 @@ VM_NAME (scm_i_thread *thread, struct scm_vm *vp,
   NEXT (1);
 }
 
-  VM_DEFINE_OP (187, unused_187, NULL, NOP)
-  VM_DEFINE_OP (188, unused_188, NULL, NOP)
-  VM_DEFINE_OP (189, unused_189, NULL, NOP)
-  VM_DEFINE_OP (190, unused_190, NULL, NOP)
-  VM_DEFINE_OP (191, unused_191, NULL, NOP)
+  /* br-if-f64= a:12 b:12 invert:1 _:7 offset:24
+   *
+   * If the F64 value in A is = to the F64 value in B, add OFFSET, a
+   * signed 24-bit number, to the current instruction pointer.
+   */
+  VM_DEFINE_OP (187, br_if_f64_ee, 

Re: [PATCH] Add unboxed floating point comparison instructions.

[Thompson, David]

Hello Andy and Mark,

Thanks for taking the time to review this patch and bearing with me as
a I stumble around the compiler.  I've attached a new patch and have
some additionally commentary below:

On Wed, Dec 21, 2016 at 4:12 PM, Mark H Weaver  wrote:
> Andy Wingo  writes:
>
>> I think /0 should be replaced by (/f64).  Probably also you need
>> a good +nan.0 story here; does this do the right thing?  e.g.
>>
>>   (let ((a +nan.0))
>> (if (< a 100.0)
>> (< a 200.0)
>> (> a 50.0)))
>>
>> Does this fold to #t?  I think for +nan.0 it should not,
>
> Right, any numerical comparison involving a NaN must return false.
>
>> but AFAIU with
>> your patch it does fold.  (Guile has some optimizer problems related to
>> flonums, I think; this patch doesn't have to fix them all, but it
>> shouldn't make them worse, or if it does, we need a nice story.)

This returns false with my patch applied, but I noticed that the
compiler has optimized everything away.  Is this what you expected,
Andy?


Disassembly of #:13:3 ()> at #x1a7919c:

   0(assert-nargs-ee/locals 1 1);; 2 slots (0 args)   at
(unknown file):13:3
   1(make-short-immediate 0 4)  ;; #f at
(unknown file):17:6
   2(handle-interrupts)
   3(return-values 2)   ;; 1 value


>>> +(define-simple-type-checker (f64-<  ))
>>> +(define-f64-comparison-inferrer (f64-< < >=))
>>
>> Likewise we need an understanding that the inverse of < is in fact >=.
>> Maybe it is indeed :)
>
> No, it is not, because of NaNs.  What we can say is that (< x y) is
> equivalent to (> y x) and (<= x y) is equivalent to (>= y x).
>
> Also, inexact numerical operations are not associative.  There's a lot
> more that could be said about this topic, but in general please be aware
> that the usual mathematical intuitions are a poor guide, and it is easy
> for a naive compiler to destroy the properties of carefully written
> numerical codes.

I was more ignorant of floating point arithmetic than I realized, so
thanks for the education here.   The good news is that I was able to
just remove all changes to types.scm to resolve these issues (I
think).

How does this new patch look?

Thanks!

- Dave
From 53cfdb4d86efaa88ff3b952347fa5a1c202c2359 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 12 Dec 2016 22:46:08 -0500
Subject: [PATCH] Add unboxed floating point comparison instructions.

* libguile/vm-engine.c (BR_F64_ARITHMETIC): New preprocessor macro.
(br_if_f64_ee, br_if_f64_lt, br_if_f64_le, br_if_f64_gt, br_if_f64_ge):
New VM instructions.
* module/language/cps/compile-bytecode.scm (compile-function): Emit f64
comparison instructions.
* module/language/cps/effects-analysis.scm: Define effects for f64
primcalls.
* module/language/cps/primitives.scm (*branching-primcall-arities*): Add
arities for f64 primcalls.
* module/language/cps/specialize-numbers.scm (specialize-f64-comparison):
New procedure.
(specialize-operations): Specialize f64 comparisons.
* module/language/cps/type-fold.scm: Define branch folder aliases for
f64 primcalls.
* module/system/vm/assembler.scm (emit-br-if-f64-=, emit-br-if-f64-<)
(emit-br-if-f64-<=, emit-br-if-f64->, emit-br-if-f64->=): Export.
* module/system/vm/disassembler.scm (code-annotation): Add annotations
for f64 comparison instructions.
---
 libguile/vm-engine.c   | 68 +++---
 module/language/cps/compile-bytecode.scm   |  7 ++-
 module/language/cps/effects-analysis.scm   |  5 +++
 module/language/cps/primitives.scm |  7 ++-
 module/language/cps/specialize-numbers.scm | 49 +++--
 module/language/cps/type-fold.scm  |  5 +++
 module/system/vm/assembler.scm |  5 +++
 module/system/vm/disassembler.scm  |  2 +
 8 files changed, 127 insertions(+), 21 deletions(-)

diff --git a/libguile/vm-engine.c b/libguile/vm-engine.c
index 4406845..6a7ba51 100644
--- a/libguile/vm-engine.c
+++ b/libguile/vm-engine.c
@@ -358,6 +358,24 @@
 NEXT (3);   \
   }
 
+#define BR_F64_ARITHMETIC(crel) \
+  { \
+scm_t_uint32 a, b;  \
+scm_t_uint64 x, y;  \
+UNPACK_24 (op, a);  \
+UNPACK_24 (ip[1], b);   \
+x = SP_REF_F64 (a); \
+y = SP_REF_F64 (b); \
+if ((ip[2] & 0x1) ? !(x crel y) : (x crel y))   \
+  { \
+scm_t_int32 offset = ip[2]; \
+offset >>= 8; /* 

Re: [PATCH] Add unboxed floating point comparison instructions.

[Thompson, David]

Here is an updated patch.  All of the code is the same but I added
docs in doc/ref/vm.texi.

- Dave
From 7d8017812a77489f362c2b9b97ee0988e5d3d7bc Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Mon, 12 Dec 2016 22:46:08 -0500
Subject: [PATCH] Add unboxed floating point comparison instructions.

* libguile/vm-engine.c (BR_F64_ARITHMETIC): New preprocessor macro.
(br_if_f64_ee, br_if_f64_lt, br_if_f64_le, br_if_f64_gt, br_if_f64_ge):
New VM instructions.
* module/language/cps/compile-bytecode.scm (compile-function): Emit f64
comparison instructions.
* module/language/cps/effects-analysis.scm: Define effects for f64
primcalls.
* module/language/cps/primitives.scm (*branching-primcall-arities*): Add
arities for f64 primcalls.
* module/language/cps/specialize-numbers.scm (specialize-f64-comparison):
New procedure.
(specialize-operations): Specialize f64 comparisons.
* module/language/cps/type-fold.scm: Define branch folder aliases for
f64 primcalls.
* module/language/cps/types.scm: Define type checkers and comparison
inferrers for f64 primcalls.
(/f64, define-f64-comparison-inferrer): New syntax.
(infer-f64-comparison-ranges): New procedure.
* module/system/vm/assembler.scm (emit-br-if-f64-=, emit-br-if-f64-<)
(emit-br-if-f64-<=, emit-br-if-f64->, emit-br-if-f64->=): Export.
* module/system/vm/disassembler.scm (code-annotation): Add annotations
for f64 comparison instructions.
* doc/ref/vm.texi ("Unboxed Floating-Point Arithmetic"): Document new
instructions.
---
 doc/ref/vm.texi| 11 +
 libguile/vm-engine.c   | 68 +++---
 module/language/cps/compile-bytecode.scm   |  7 ++-
 module/language/cps/effects-analysis.scm   |  5 +++
 module/language/cps/primitives.scm |  7 ++-
 module/language/cps/specialize-numbers.scm | 49 +++--
 module/language/cps/type-fold.scm  |  5 +++
 module/language/cps/types.scm  | 30 +
 module/system/vm/assembler.scm |  5 +++
 module/system/vm/disassembler.scm  |  2 +
 10 files changed, 168 insertions(+), 21 deletions(-)

diff --git a/doc/ref/vm.texi b/doc/ref/vm.texi
index 1abbbce..b61d05f 100644
--- a/doc/ref/vm.texi
+++ b/doc/ref/vm.texi
@@ -1665,6 +1665,17 @@ Load a 64-bit value formed by joining @var{high-bits} and
 @var{low-bits}, and write it to @var{dst}.
 @end deftypefn
 
+@deftypefn Instruction {} br-if-f64-= s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+@deftypefnx Instruction {} br-if-f64-< s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+@deftypefnx Instruction {} br-if-f64-<= s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+@deftypefnx Instruction {} br-if-f64-> s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+@deftypefnx Instruction {} br-if-f64->= s24:@var{a} x8:@var{_} s24:@var{b} b1:@var{invert} x7:@var{_} l24:@var{offset}
+If the unboxed IEEE double value in @var{a} is @code{=}, @code{<},
+@code{<=}, @code{>}, or @code{>=} to the unboxed IEEE double value in
+@var{b}, respectively, add @var{offset} to the current instruction
+pointer.
+@end deftypefn
+
 @deftypefn Instruction {} fadd s8:@var{dst} s8:@var{a} s8:@var{b}
 @deftypefnx Instruction {} fsub s8:@var{dst} s8:@var{a} s8:@var{b}
 @deftypefnx Instruction {} fmul s8:@var{dst} s8:@var{a} s8:@var{b}
diff --git a/libguile/vm-engine.c b/libguile/vm-engine.c
index 4406845..6a7ba51 100644
--- a/libguile/vm-engine.c
+++ b/libguile/vm-engine.c
@@ -358,6 +358,24 @@
 NEXT (3);   \
   }
 
+#define BR_F64_ARITHMETIC(crel) \
+  { \
+scm_t_uint32 a, b;  \
+scm_t_uint64 x, y;  \
+UNPACK_24 (op, a);  \
+UNPACK_24 (ip[1], b);   \
+x = SP_REF_F64 (a); \
+y = SP_REF_F64 (b); \
+if ((ip[2] & 0x1) ? !(x crel y) : (x crel y))   \
+  { \
+scm_t_int32 offset = ip[2]; \
+offset >>= 8; /* Sign-extending shift. */   \
+NEXT (offset);  \
+  } \
+NEXT (3);   \
+  }
+
+
 #define ARGS1(a1)   \
   scm_t_uint16 dst, src;\
   SCM a1;   \
@@ -3950,11 

Re: Slow compilation of guile-2.1.x

[Thompson, David]

On Mon, Nov 28, 2016 at 3:47 AM, Jan Synáček  wrote:
> On Fri, Nov 25, 2016 at 9:36 AM,   wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On Fri, Nov 25, 2016 at 08:31:23AM +0100, Jan Synáček wrote:
>>> Hello,
>>>
>>> while building guile-2.1.4 for Fedora, I noticed that the compilation
>>> got *really* slow. I didn't measure it precisely, but as can be seen
>>> from [1] (about 20 minutes) and [2] (about 100 minutes with make check
>>> disabled), the time difference between the builds is roughly 80
>>> minutes... Release notes mention that the VM has been rewritten and
>>> the source is now compiled into ELF, but is it supposed to be this
>>> slow?
>>
>> Are you building from scratch? Because then yes, 2.1.x is expected
>> to bootstrap slowly [1]. The solution offered ATM is delivering a
>> half-bootstrapped system [2].
>
> Yes, but even a small (about 3 modules and a few 100s LoC) project of
> mine compiles about 3 times slower.

The compiler now performs many more optimizations.  If you want faster
compile time, turn off optimizations with 'guild compile -O0'.  Read
the output of 'guild compile -Ohelp' for more information.

- Dave

Re: Setting up CI for Guile

[Thompson, David]

On Thu, Oct 6, 2016 at 12:26 AM, Wilfred Hughes  wrote:
> Hi folks
>
> I'm a big fan of CI (automated testing), and maybe you are too. I'd
> love to have CI for reviewing patches of Guile.

This is a good idea.

> So, I decided to set it up! This isn't something that's available on
> GNU Savannah, so I've used GitLab (which is still FSF-approved Free
> Software).

gitlab.com runs the proprietary version of the GitLab server, but IIRC
all of the JavaScript is still free, so it's OK, but not ideal.

> You can see my different branches being tested here:
> https://gitlab.com/wilfred/guile/pipelines?scope=branches
>
> Guile compilation is slow: 3 hours 15 minutes on my feeble laptop.
> GitLab's CI only gives you an hour.

That's unfortunate.  It's important to build from scratch, which means
bootstrapping the compiler, which indeed takes awhile, but patches
generally take days or longer to be reviewed and merged so a few hours
is no big deal, IMO.  The GNU Guix project is working on a replacement
for its current CI system at hydra.gnu.org that runs Hydra from the
Nix project, named Cuirass, so I think we should try to use that
instead of GitLab.

> I solved this by creating a Docker image:
> https://gitlab.com/wilfred/guile-build-image that contains a recent
> checkout of Guile that has been built. This allows me to do an
> incremental build in GitLab, which is much faster (5-10 minutes,
> including tests).

Docker is a dealbreaker for me.  Don't have time to get into it here
but it would be much better to use Guix, which has the additional
benefit of being written in Guile.

> What do you think? I'd love this to become the standard way to
> contribute: it's easy to see what patches are in need of review, and
> whether tests pass after a given patch is applied.

I think this is a wonderful idea that could use a new implementation.
Thanks for getting the ball rolling with the proof-of-concept!

- Dave

Re: fork pipe dup2 exec

[Thompson, David]

On Wed, Aug 17, 2016 at 9:35 AM, Tobias Reithmaier  wrote:
> Hello,
>
> is there a way to program a Inter Process Communication (IPC) in guile like
> you do it with the Linux-Libc-API with the combo fork, pipe, dup2 and exec?
> If you use the popen-module it's not the same because you have to wait until
> the program has finished.
> But there are use-cases in that the program doesn't finish. e.g. a server
> which outputs data every minute.
>
> So can i use the popen-module to control such a server with pipes?
> Or is there another way?

Check out the "POSIX" section of the manual. Fork, dup, and exec are
all available.

- Dave

Re: Attempting to unbox struct fields

[Thompson, David]

On Mon, Feb 29, 2016 at 12:43 PM, Mark H Weaver <m...@netris.org> wrote:
> "Thompson, David" <dthomps...@worcester.edu> writes:
>
>>> The first thing I noticed is that the patch assumes that doubles are the
>>> same size as pointers.  Obviously this is not the case on 32-bit
>>> systems.  What's the plan for those systems?
>>
>> Yeah, I just hacked this together on my x86_64 system and paid no mind
>> to portability.  I was hoping that you or Andy or Ludovic would have
>> an idea for how to address portability issues. :)
>
> I think the approach we need to take is that for 32-bit systems, doubles
> will need to use two consecutive slots.  Furthermore, those slots will
> either need to be aligned (i.e. the first slot must have an even index)
> or else the code that accesses 'double' struct fields will need to
> perform the access carefully, perhaps by copying each half separately
> into a local 'union' and then copying the double from there.

After talking with Andy on #guile for a bit, it has become apparent
that unboxing these fields will only be of limited utility.  For
example, it would be nice to eventually handle arrays of unboxed data
like in C with an array of structs, but unboxing struct fields doesn't
get us any closer to such a goal.  Thus, I am going to drop this work
and find another optimization to focus on.

Thanks anyway.  It's been an educational experience.

- Dave

Re: Attempting to unbox struct fields

[Thompson, David]

Hi Mark,

On Sun, Feb 28, 2016 at 10:56 PM, Mark H Weaver <m...@netris.org> wrote:
> Hi David,
>
> "Thompson, David" <dthomps...@worcester.edu> writes:
>> Here's a patch I came up with to enable (and fix where necessary) the
>> support for signed integer and double struct fields.
>
> Great, thanks for working on it!  This is not a proper review, just a
> couple of questions and comments.

I'm not very knowledgeable in the finer points of writing portable C
code or the Guile C API, so this feedback is very valuable.  Thanks!

>> Am I on the right track here?
>
> The first thing I noticed is that the patch assumes that doubles are the
> same size as pointers.  Obviously this is not the case on 32-bit
> systems.  What's the plan for those systems?

Yeah, I just hacked this together on my x86_64 system and paid no mind
to portability.  I was hoping that you or Andy or Ludovic would have
an idea for how to address portability issues. :)

> The patch also currently assumes that longs and pointers are the same
> size, and this turns out to be false on LLP64 systems such as 64-bit
> Windows.  See <https://debbugs.gnu.org/22406>.  However, it should be
> straightforward to fix this issue.
>
>> +   if ((prot != 'r' && prot != 'w') || inits_idx == n_inits)
>> + *mem = 0.0;
>
> Note that 'mem' is of type scm_t_bits*, so the 0.0 will be converted to
> the integer 0 and then stored as an integer, which I guess is not what
> you meant.  Note that in practice this works on IEEE 754 systems, where
> 0.0 is represented as all zero bits, but the code is somewhat misleading
> and less portable than it could be.

D'oh!  I forgot to cast here.  Thanks for the explanation.  It
explains why I didn't notice the issue when testing.

My current plan is to keep pressing onward and produce a
proof-of-concept, hacky patch set that allows unboxed struct fields on
x86_64.  Then, with some help and guidance, I can sort out the
portability issues, code style issues, unit tests, and documentation
after confirmation that the prototype is on the right track.

Thanks,

- Dave

Re: Attempting to unbox struct fields

[Thompson, David]

Here's a patch I came up with to enable (and fix where necessary) the
support for signed integer and double struct fields.  Am I on the
right track here?

Thanks,

- Dave
From 8bde5c7018fde91cc7140777107bacfb3febb170 Mon Sep 17 00:00:00 2001
From: David Thompson 
Date: Sun, 28 Feb 2016 16:11:35 -0500
Subject: [PATCH] struct: Add support for unboxed signed integers and doubles.

* libguile/struct.c (scm_make_struct_layout): Enable 'i' and 'd' cases.
(scm_is_valid_vtable_layout): Add 'i' and 'd' cases.
(scm_struct_init): Initialize signed integer and double fields.
(scm_struct_ref): Enable 'i' and 'd' cases.  Update 'd' case to use
scm_from_double instead of obsolete scm_make_real.
(scm_struct_set_x): Enable 'i' and 'd' cases.  Update 'd' case to use
SCM_NUM2DOUBLE instead of obsolete scm_num2dbl.
---
 libguile/struct.c | 32 
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/libguile/struct.c b/libguile/struct.c
index 8bfbcf4..c50019c 100644
--- a/libguile/struct.c
+++ b/libguile/struct.c
@@ -100,10 +100,8 @@ SCM_DEFINE (scm_make_struct_layout, "make-struct-layout", 1, 0, 0,
 	  {
 	  case 'u':
 	  case 'p':
-#if 0
 	  case 'i':
 	  case 'd':
-#endif
 	  case 's':
 	break;
 	  default:
@@ -219,6 +217,8 @@ scm_is_valid_vtable_layout (SCM layout)
 switch (c_layout[n])
   {
   case 'u':
+  case 'i':
+  case 'd':
   case 'p':
   case 's':
 switch (c_layout[n+1])
@@ -360,6 +360,26 @@ scm_struct_init (SCM handle, SCM layout, size_t n_tail,
 		}
 	  break;
 
+case 'i':
+	  if ((prot != 'r' && prot != 'w') || inits_idx == n_inits)
+		*mem = 0;
+	  else
+		{
+		  *mem = scm_to_long (SCM_PACK (inits[inits_idx]));
+		  inits_idx++;
+		}
+	  break;
+
+case 'd':
+	  if ((prot != 'r' && prot != 'w') || inits_idx == n_inits)
+		*mem = 0.0;
+	  else
+		{
+		  *((double *) mem) = scm_to_double (SCM_PACK (inits[inits_idx]));
+		  inits_idx++;
+		}
+	  break;
+
 	case 'p':
 	  if ((prot != 'r' && prot != 'w') || inits_idx == n_inits)
 		*mem = SCM_UNPACK (SCM_BOOL_F);
@@ -761,15 +781,13 @@ SCM_DEFINE (scm_struct_ref, "struct-ref", 2, 0, 0,
 	  answer = scm_from_ulong (data[p]);
 	  break;
 
-#if 0
 	case 'i':
 	  answer = scm_from_long (data[p]);
 	  break;
 
 	case 'd':
-	  answer = scm_make_real (*((double *)&(data[p])));
+	  answer = scm_from_double (*((double *)&(data[p])));
 	  break;
-#endif
 
 	case 's':
 	case 'p':
@@ -844,15 +862,13 @@ SCM_DEFINE (scm_struct_set_x, "struct-set!", 3, 0, 0,
 	  data[p] = SCM_NUM2ULONG (3, val);
 	  break;
 
-#if 0
 	case 'i':
 	  data[p] = SCM_NUM2LONG (3, val);
 	  break;
 
 	case 'd':
-	  *((double *)&(data[p])) = scm_num2dbl (val, (char *)SCM_ARG3);
+	  *((double *)&(data[p])) = SCM_NUM2DOUBLE (3, val);
 	  break;
-#endif
 
 	case 'p':
 	  data[p] = SCM_UNPACK (val);
-- 
2.6.3

Re: random is not random

[Thompson, David]

On Sat, Feb 13, 2016 at 4:30 PM, Matt Wette  wrote:
> Every time I execute
> $ guile -c '(simple-format #t "~S\n" (random 100))’
> I get the same result.
>
> Is this a bug?

No.  You need to initialize the random number generator with a
different seed if you want different results.  See 6.6.2.14 Random
Number Generation in the manual for details.

- Dave

Re: Contributions to Guile

[Thompson, David]

On Mon, Feb 8, 2016 at 4:28 PM, Chad Albers  wrote:
> On Mon, Feb 8, 2016 at 2:05 PM, Christopher Allan Webber
>  wrote:
>> Ludovic Courtès writes:
>>
>>> Christopher Allan Webber  skribis:
>>>
 Chad Albers writes:
>>>
>>> [...]
>>>
> b. More robust documentation system - texinfo is not the greatest. And
> it's non-trivial to generate any documentation (including texinfo) for
> modules.

 Texinfo is pretty nice to use if you're an emacs user... in fact, if
 you're an emacs user, it's the best documentation reading system in the
 world.  But not everyone's an emacs user.
>>>
>>> I think Texinfo is OK even if you’re not an Emacs user, no?  Especially
>>> with the just-release 6.1 where menus can (finally!) be automatically
>>> generated.
>>>
 If the html export was nicely themed
>
> IMHO, HTML has clearly won the documentation game.  I believe it goes
> without saying that most developers have a web browser installed,
> rather than a textinfo reader.  The more the guile project publishes
> easily searchable (without google) documentation in the most
> accessible media format the better for guile.

We can clearly have both.  Nice looking HTML docs on the Guile website
are possible with a little CSS magic and some nice fonts.  Thanks to
Texinfo, we also get Info and PDF versions!  Having the Guile
documentation nicely integrated with my editor (Emacs) is a *huge*
productivity booster.  Having HTML-only documentation would be a major
setback for Guile.

- Dave

Re: Guix as a Guile package manager

[Thompson, David]

On Sat, Jan 9, 2016 at 5:35 AM, Fabio Pesari  wrote:
> Package managers have been immensely successful in increasing the
> popularity of programming languages - think about Perl's CPAN or Ruby's
> Gem. But Guile doesn't a package manager, and that in my opinion slows
> down its adoption.

Many of us in the Guile community, including myself, are not very
interested in language-specific package managers because they are
problematic:

- They put burden on the user to make sure the right toolchain is
  available to build/install things (GCC and co.)

- They cannot describe the full dependency graph for things that
  aren't completely written in that language or use a foreign-function
  interface (for example, a Guile library that talks to a C library
  via the dynamic FFI, or one that uses the Guile C API)

- They encourage new users to conflate the build system with the
  package manager, leading to software that cannot be built without a
  network connection and a specific package manager.  Java software is
  notorious for this, as are Ruby and Python to a lesser degree.

That said, I see the desire to have a tool for easily sharing pure
Guile modules.

> The Guix repos distribute a lot of useful Guile libraries (like
> guile-json or guile-opengl) which can't be found on most distro
> repositories and it already provides Guile APIs and package management
> capabilities...my question is, can Guix be forked into a full-blown
> Guile package manager like gem from Ruby?

You can install Guix right now and use it to help you develop with
Guile, or any other language.  I use it for all of my Guile projects
and it works great.

> I know that an argument could be made that Guix can already be used in
> this way, but there are many Scheme coders who don't need a system-wide
> package manager and would rather use a program that can manage Guile
> packages under a user root like ~/.guile and allow them to easily
> distribute their packages (something like Python's virtualenvs would
> also be useful).

This is what the Guildhall[0] is for, but it needs some love.  I
really do not encourage the use of language-specific package managers
for the above-mentioned problems, but if you *really* want that,
contributing to the Guildhall seems to be the best thing to do.
People ask about it somewhat frequently, but so far no one has seemed
willing to roll up their sleeves and make it work for them.

> Perhaps some of the Guix code can be moved to a library, so that both
> the Guix and the Guile package manager binaries can reuse the same code.
> Moving Guix' core to a library would also facilitate its inclusion in
> things like PackageKit, as well as make it easier to create front-ends.

This would be a bad idea, because it creates a divide between the Guix
core and the rest of Guix, which would force us to make currently
internal APIs into external, public APIs and worry about backwards
compatibility and other issues.  Our development of Guix models that
of Linux.  In Linux, the kernel is maintained in conjuction with the
kernel modules, in the same source tree.  In Guix, the core modules
are maintained in conjunction with the user interfaces and package
recipes, in the same source tree.  Thus, if we change the packaging
API, or something else, we can update the relevant code in the source
tree and be done with it.  We don't have to worry about breaking
compatibility with an older version of libguix or something.  This was
a deliberate decision made to deal with problems that the Nix
community have when their version of Nix doesn't work with their
version of nixpkgs.

On the topic of PackageKit, it's been discussed in the past, but
PackageKit is incompatible with functional package managers because it
does not support important features like unprivileged package
management. [1]

> I'm not a package management expert so I'm not sure this idea is
> feasible but I would really like Guile to become more
> popular, and this I think would be a step in the right direction.

I don't think Guix is a good fit here, because there's simply no way
around the fact that Guix packages *must* contain the full dependency
graph for build-time and runtime dependencies.  There's no way that
you could use, say, the Guile or GCC from your host system because
doing so invalidates the entire purpose and design of Guix.  Thus, a
Debian user that tried to use a Guile-specific package manager based
on Guix would be surprised when it starts compiling its own glibc,
GCC, Guile, etc.  So, I don't see anything worth extracting from Guix
to use to build a Guile-specific package manager.

I encourage you to hack on Guildhall to make it more usable for your
needs.

Happy hacking,

- Dave

[0] https://github.com/ijp/guildhall
[1] https://lists.gnu.org/archive/html/bug-guix/2014-03/msg00018.html

Re: Reading data from a file descriptor

[Thompson, David]

On Sun, Nov 15, 2015 at 6:09 AM, Jan Synáček <jan.syna...@gmail.com> wrote:
> On Fri, Nov 13, 2015 at 9:45 PM, Thompson, David
> <dthomps...@worcester.edu> wrote:
>> On Fri, Nov 13, 2015 at 3:41 PM, Jan Synáček <jan.syna...@gmail.com> wrote:
>>>
>>> I have an open fd to a unix socket and I want to read data from it. I
>>> know that the data is going to be only strings, but I don't know the
>>> length in advance. The good thing about using read-string!/partial is,
>>> that I don't have to specify how many bytes I want to read and it does
>>> the right thing. If you point me to a better direction, I'll be
>>> grateful. I came up with:
>>>
>>> (for-each (lambda (fd)
>>> (let* ((buf (make-string 4096)))
>>>   (read-string!/partial buf (fdes->inport fd))
>>>   (format #t "fd[~a]: ~a" fd buf) (newline)))
>>>   fds)
>>>
>>
>> Maybe 'read-string' in (ice-9 rdelim) is what you're after.
>>
>> - Dave
>
> For some reason, 'read-string' blocks when I don't specify a small enough 
> limit.

That's how I/O operations work.  'read-string' blocks until the end of
file.  Guess I misunderstood what you're after.

- Dave

Re: Reading data from a file descriptor

[Thompson, David]

On Fri, Nov 13, 2015 at 3:41 PM, Jan Synáček  wrote:
>
> I have an open fd to a unix socket and I want to read data from it. I
> know that the data is going to be only strings, but I don't know the
> length in advance. The good thing about using read-string!/partial is,
> that I don't have to specify how many bytes I want to read and it does
> the right thing. If you point me to a better direction, I'll be
> grateful. I came up with:
>
> (for-each (lambda (fd)
> (let* ((buf (make-string 4096)))
>   (read-string!/partial buf (fdes->inport fd))
>   (format #t "fd[~a]: ~a" fd buf) (newline)))
>   fds)
>

Maybe 'read-string' in (ice-9 rdelim) is what you're after.

- Dave

Re: [PATCH] Added Artanis info to new main page

[Thompson, David]

On Wed, Nov 4, 2015 at 4:27 PM, Mathieu Lirzin  wrote:

> On a more general topic, IIUC Artanis is not an “application” but a
> library so maybe it is not a good idea to include it in (index-page)
> since it uses the term “applications using Guile“ (The same problem will
> apply to Sly I guess).  WDYT?

Yes, I think it would be best to move Sly out of there and into the
libraries page.  It really isn't ready for the spotlight it has now
because I haven't made a single official release.

What should we put in its place?

- Dave

Re: New logo and website design proposal

[Thompson, David]

On Fri, Oct 9, 2015 at 6:24 PM, Luis Felipe López Acevedo
 wrote:
> On 2015-09-23 11:18, Luis Felipe López Acevedo wrote:
>>
>>
>> With the feedback so far, I'm planning to make a revision of the
>> mockup this weekend to include the suggested changes.
>>
>
> Hi,
>
> I just finished an implementation of the new website. You can grab a copy of
> the built site from here:
>
>   https://bitbucket.org/sirgazil/dnd/downloads/guile-website-20151009.tar.gz
>
> To try it out:
>
>$ cd path/to/guile-website-mmdd
>$ python3 -m http.server# couldn't find a equivalent in Guile

Not nearly so convenient, but Haunt (my static site generator) comes
with such a simple web server:

   guile -c "((@ (haunt serve web-server) serve) (getcwd))" # run
static web server on port 8080

Maybe Guile core could use a basic static file web server?  I used to
use the above Python snippet a lot.

> Then visit the website at .

It looks great!  Thanks for sharing!  Now, who can help you make the
final edits and get it live?

- Dave

Re: New logo and website design proposal

[Thompson, David]

On Thu, Sep 17, 2015 at 10:59 AM, Luis Felipe López Acevedo
 wrote:
> On 2015-09-16 03:19, Alex Sassmannshausen wrote:
>>
>> Beautiful!
>>
>> Like Chris, I love the demographically agnostic, yet incredibly inviting
>> drawings.  I also love the overall crisp and modern feel to the whole
>> site including the proposed new logos.
>>
>> Fantastic :-)
>>
>> Alex
>>
>
> Great! Thank you for the feedback, Alex.
>
> I also read on IRC that someone said the drawings were childish. I
> understand. But I hope that the "Applications using guile" section will
> erase any wrong impressions that some people may get after seeing the
> illustrations.

I'd classify the drawings as "cute", which I think is just fine!  The
important thing is that the illustrations clearly demonstrate an idea,
and I think they do.  I think the little robot going into a bigger
robot is a good visualization of extension.

Really great stuff.  I'm not in love with the proposed logo, but
overall this is fantastic and I'm very excited for Guile to have such
a clean and informative home page.

Thanks!

- Dave

Re: [PATCH] web: http: Accept blank Content-Type headers.

[Thompson, David]

Apologies for the previous email.  I seriously botched some keystrokes.

On Mon, Jul 27, 2015 at 5:05 PM, Mark H Weaver m...@netris.org wrote:
 David Thompson da...@gnu.org writes:

 I encountered a bug in the HTTP header parsing bug when trying to
 download a file via Guix.  The response had a Content-Type header, but
 with no value, like so:

 Content-Type:

 From reading the W3C spec[0], an unknown Content-Type header can be
 treated as if it were an application/octet-stream type.

 An empty string is not merely an unknown Content-Type header.  It is
 blatantly invalid syntax.  It would be good to contact the web site
 owner and ask them to fix it.

Yes, I have done so.  I haven't heard back yet.  I hope they take this
seriously.

 Since web clients seem to accept just about anything these days, and web
 servers have adapted to this by producing garbage, it may be that we
 need to add a permissive mode that sifts through the garbage and uses
 heuristics to try to make some sense of it.

 However, I'm not sure it makes sense to handle this particular case of
 an empty Content-Type header specially, at that this place in the code.
 Do we have any other examples of this particular error?

No, just this one.  I think getting rubygems.org to fix the issue will
be better than adding a special case to the HTTP header parser.

 I realize that it's more work, but I would prefer to retain a mode that
 reports errors (possibly making a few compromises for very widespread
 errors), and then to somehow implement another mode that accepts
 *anything* and does its best to make sense of it.

 What do you think?

Yes, that makes sense.  I don't have the drive to attempt that right
now, but thanks for sharing your thoughts about this.

Thanks!

- Dave

Re: [PATCH] web: http: Accept blank Content-Type headers.

[Thompson, David]

On Mon, Jul 27, 2015 at 5:05 PM, Mark H Weaver m...@netris.org wrote:
 David Thompson da...@gnu.org writes:

 I encountered a bug in the HTTP header parsing bug when trying to
 download a file via Guix.  The response had a Content-Type header, but
 with no value, like so:

 Content-Type:

 From reading the W3C spec[0], an unknown Content-Type header can be
 treated as if it were an application/octet-stream type.

 An empty string is not merely an unknown Content-Type header.  It is
 blatantly invalid syntax.  It would be good to contact the web site
 owner and ask them to fix it.

 Since web clients seem to accept just about anything these days, and web
 servers have adapted to this by producing garbage, it may be that we
 need to add a permissive mode that sifts through the garbage and uses
 heuristics to try to make some sense of it.

 However, I'm not sure it makes sense to handle this particular case of
 an empty Content-Type header specially, at that this place in the code.
 Do we have any other examples of this particular error?

 I realize that it's more work, but I would prefer to retain a mode that
 reports errors (possibly making a few compromises for very widespread
 errors), and then to somehow implement another mode that accepts
 *anything* and does its best to make sense of it.

 What do you think?

 Thanks for working on it,

   Mark

Re: Add support for record types in GOOPS methods?

[Thompson, David]

On Tue, Oct 21, 2014 at 11:37 AM, Panicz Maciej Godek
godek.mac...@gmail.com wrote:

 Hi!
 As I managed to find out, the (define-record-type t ...) also introduces a
 GOOPS class named t. Following your example, you'd need to define your
 method in the following way:

 (define-method (foobar (foo foo))
 (foo-bar foo))

 I don't think any further changes are needed (perhaps a section in the
 documentation would be nice)

I had no idea that magic was happening.  Thanks!  That solves my
immediate need, though I think defining something that I didn't
explicitly ask for is strange.

I thought that I could make this technique fail by defining the record
type before importing (oop goops), but it still worked.  Why?

- Dave

Simple hash table macro

[Thompson, David]

Hello Guile hackers,

In the last release, a procedure called 'alist-hash-table' was
introduced to provide a convenient way to convert an alist into a hash
table.

  (use-modules (ice-9 hash-table))

  (define myhash
(alist-hash-table
 '((parrots . nuts)
   (monkeys . bananas)
   (cats . fish

I think that it would be even more convenient to build a macro on top
of this to provide a declarative hash table constructor.  A simplistic
example:

  (define-syntax-rule (hash-table (key value) ...)
(alist-hash-table `((key . ,value) ...)))

  (define myhash
(hash-table
 (parrots nuts)
 (monkeys bananas)
 (cats fish)))

IIRC, hash table macros are a bit of a controversial topic, but I
think that previous discussions were about a reader macro.

Thoughts?

- Dave

Re: Use GNU standard for displaying backtraces?

[Thompson, David]

On Fri, Aug 8, 2014 at 2:22 PM, Jan Nieuwenhuizen jann...@gnu.org wrote:
 Trying to get Emacs's compilation-mode to support stepping down Guile
 backtraces, I wrote some elisp code to determine the absolute file
 name for incomplete relative files that come from Guile's load path,
 e.g., ice/boot-9.scm.


[snip]

 however, I like to step down all lines of a backtrace with
 next-error/previous-error, so haven't done that.

+1 to using the GNU standard.

I can't speak to the quality of the patch, but I have also noticed
that next-error/previous-error didn't work with guile backtraces.  It
would be really useful if it worked.

- Dave

Re: [PATCH] Test for weak pairs in hash-for-each

[Thompson, David]

On Wed, Mar 12, 2014 at 2:45 AM, Mark H Weaver m...@netris.org wrote:
 David Thompson dthomps...@worcester.edu writes:

 * libguile/hashtab.c (hash-for-each): Test for deleted weak pairs.

 Instead of (hash-for-each), it should be
 (scm_internal_hash_for_each_handle).

 I went ahead and pushed it, with that change.

Thanks!
  Mark

Ah, sorry.  I always mess up something like that.

Thanks for taking care of it.

- Dave

Fwd: PATCH - Add cooperative REPL server module

[Thompson, David]

Forgot to CC the list about my updated patch. Forwarding instead. My apologies.

- Dave


-- Forwarded message --
From: David Thompson dthomps...@worcester.edu
Date: Mon, Jan 20, 2014 at 6:31 PM
Subject: Re: PATCH - Add cooperative REPL server module
To: Mark H Weaver m...@netris.org


Mark H Weaver m...@netris.org writes:

 That means that they'll all run in the same thread.  A great benefit of
 the cooperative REPL is being able to safely access and mutate data
 structures belonging to a particular thread.  A program may have more
 than one thread, and may want REPLs for each.

 Also, remember that Guile is a library, and may be used by multiple
 libraries within a larger program.  Each of those libguile-using
 libraries may want to provide their own coop REPL server, each run at
 their own chosen safe-points.

 As a general rule, in _any_ library, it's generally a bad idea to have
 global settings.  For example, the GMP library that Guile uses for big
 integers offers global settings to specify custom memory allocation
 functions, and Guile needs to set these.  However, this can lead to
 conflicts when other libraries linked with libguile (or the main
 program) also use GMP and want to install their own custom allocators.

Good points. Thanks for the explanation.

 Okay.  I wouldn't expect it to work without modifications.

I have wrapped the body of 'start-coop-repl' with 'false-if-exception'
to prevent the program from crashing with 'stop-server-and-clients!' is
called from a REPL.  I did not have to do the same for 'close-socket!'
in 'start-repl-client' because trying to close an a port that has
already been closed is a no-op.

However, something unexpected happened when I tried to call
'stop-server-and-clients!' from my test program's main loop: There was a
segfault once I pressed the enter key in my telnet REPL session.  I
tested this again with the regular REPL server and got the same bad
results.  Thoughts?

In any case, attached is an updated patch for review.  Multiple
cooperative REPL servers are now supported and the global evaluation
mvar has been removed.

- Dave
From 7e183c5316ab997041cf6ec83192e7a32e49e0fa Mon Sep 17 00:00:00 2001
From: David Thompson dthomps...@worcester.edu
Date: Sun, 19 Jan 2014 13:16:02 -0500
Subject: [PATCH] Add cooperative REPL server module.

* module/system/repl/coop-server.scm: New module.

* module/system/repl/repl.scm (start-repl): Extract body to start-repl*.
(start-repl*): New procedure.

* module/system/repl/server.scm (run-server): Extract body to
  run-server*.
  (run-server*): New procedure.

* doc/ref/api-evaluation.texi: Add docs.
---
 doc/ref/api-evaluation.texi|  47 +++
 module/Makefile.am |   3 +-
 module/system/repl/coop-server.scm | 163 +
 module/system/repl/repl.scm|  11 ++-
 module/system/repl/server.scm  |   5 +-
 5 files changed, 223 insertions(+), 6 deletions(-)
 create mode 100644 module/system/repl/coop-server.scm

diff --git a/doc/ref/api-evaluation.texi b/doc/ref/api-evaluation.texi
index 63b1d60..d366aa1 100644
--- a/doc/ref/api-evaluation.texi
+++ b/doc/ref/api-evaluation.texi
@@ -23,6 +23,7 @@ loading, evaluating, and compiling Scheme code at run time.
 * Local Evaluation::Evaluation in a local lexical environment.
 * Local Inclusion:: Compile-time inclusion of one file in another.
 * REPL Servers::Serving a REPL over a socket.
+* Cooperative REPL Servers::REPL server for single-threaded applications.
 @end menu
 
 
@@ -1275,6 +1276,52 @@ with no arguments.
 Closes the connection on all running server sockets.
 @end deffn
 
+@node Cooperative REPL Servers
+@subsection Cooperative REPL Servers
+
+@cindex Cooperative REPL server
+
+The procedures in this section are provided by
+@lisp
+(use-modules (system repl coop-server))
+@end lisp
+
+Whereas REPL servers run in their own threads, sometimes it is more
+convenient to provide REPLs that run at specified times within an
+existing thread, for example in programs utilizing an event loop or in
+single-threaded programs.  This allows for safe access and mutation of a
+program's data structures from the REPL, without concern for thread
+synchronization.  The server must be polled periodically to evaluate any
+pending expressions.
+
+@deffn {Scheme Procedure} make-coop-repl-server
+Return a newly allocated cooperative REPL server.
+@end deffn
+
+@deffn {Scheme Procedure} coop-repl-server? obj
+Return @code{#t} if @var{obj} is a cooperative REPL server, otherwise
+return @code{#f}.
+@end deffn
+
+@deffn {Scheme Procedure} run-coop-repl-server coop-server [server-socket]
+Run the given cooperative REPL server @var{coop-server} in the current
+thread, making it available over the given @var{server-socket}.  If
+@var{server-socket} is not provided, it defaults to the socket created
+by calling @code{make-tcp-server-socket} with no arguments.
+@end deffn
+

Re: Guile talks at the GNU Hackers Meeting?

[Thompson, David]

I don't think using Skype would go over so well at a GNU hackers meeting.


On Mon, Jun 24, 2013 at 2:16 PM, Shane Celis shane.ce...@gmail.com wrote:

 Hi Luca,

 I'd be happy to give a talk regarding the Emacsy[1] GSoC project (video
 here[2]).  The travel costs, however, are a bit prohibitive for me (I'm a
 Ph.D. student).  I could do a talk over Skype though.

 -Shane

 [1]:
 https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/shanecelis/1
 [2]:
 http://www.kickstarter.com/projects/568774734/emacsy-an-embeddable-emacs


 On Jun 23, 2013, at 11:00 AM, guile-devel-requ...@gnu.org wrote:
 
  Hello people.
 
  We're organizing the next GNU Hackers Meeting which will take place next
  August in Paris, France; see http://www.gnu.org/ghm/2013/paris .  We
  still have free slots, so I'm starting to contact people a little
  more pro-actively.
 
  Personally I would really like a talk about the new Guile VM, which
  sounds exciting -- Andy...? :-)
 
  And there are two GSoC projects about the integration of Guile and
  Emacs, which sound just as interesting.
 
  Would you like to give a talk?
 
  If you simply want to attend without speaking, you can register as well.
  We're trying to do a little outreach so the talks will be open to
  everybody, but of course we particularly welcome GNU contributors.
 
  Regards,
 
  --
  Luca Saiu
  Home page:   http://ageinghacker.net
  GNU epsilon: http://www.gnu.org/software/epsilon
  Marionnet:   http://marionnet.org