Re: Failure in test-suite/standalone/test-ffi test

[Ludovic Courtès]

Eli Zaretskii  skribis:

> This test fails on MS-Windows in the MinGW build as follows:
>
>  Backtrace:
>  In ice-9/boot-9.scm:
>   157: 11 [catch #t # ...]
>  In unknown file:
>   ?: 10 [apply-smob/1 #]
>  In ice-9/boot-9.scm:
>63: 9 [call-with-prompt prompt0 ...]
>  In ice-9/eval.scm:
>   432: 8 [eval # #]
>  In ice-9/boot-9.scm:
>  2401: 7 [save-module-excursion # ice-9/boot-9.scm:4045:3 ()>]
>  4050: 6 [#]
>  1724: 5 [%start-stack load-stack # ice-9/boot-9.scm:4041:10 ()>]
>  1729: 4 [#]
>  In unknown file:
>   ?: 3 [primitive-load 
> "d:/gnu/guile-2.0.11/test-suite/standalone/test-ffi"]
>  In ice-9/eval.scm:
>   453: 2 [eval # ()]
>   387: 1 [eval # ()]
>  In unknown file:
>   ?: 0 [dynamic-func "strerror" #]
>ERROR: In procedure dynamic-func:
>  ERROR: In procedure dynamic-pointer: Symbol not found: strerror
>  FAIL: test-ffi
>
> Does this test make some unportable assumptions about the 'strerror'
> symbol?

Yes.

Since the test just tries to use a global symbol exported from libc, we
could use something else.

Would ‘gethostname’ work on Windows?  That is, does:

  (dynamic-func "gethostname" (dynamic-link))

return a valid pointer?

If the answer is yes, I’ll adapt this test to use this symbol instead.

Thanks,
Ludo’.

Re: [PATCH] Add SRFI-25 implementation

[Ludovic Courtès]

Andreas Rottmann  skribis:

> Adds an implementation of SRFI 25 on top of Guile's native arrays. The
> implementation does not introduce a disjoint type; Guile arrays and
> SRFI-25 arrays can be used interchangably, though with different, partly
> conflicting APIs.
>
> * NEWS: Add preliminary, incomplete section on 2.0.12, noting the
>   addition of SRFI-25.
> * doc/ref/srfi-modules.texi (SRFI-25): New node.
> * module/srfi/srfi-25.scm: New file.
> * test-suite/tests/srfi-25.test: New file.
> * module/Makefile.am:
> * test-suite/Makefile.am: Add new files.
> ---
>  NEWS  |  15 +-
>  doc/ref/srfi-modules.texi | 240 +-
>  module/Makefile.am|   1 +
>  module/srfi/srfi-25.scm   | 159 +++
>  test-suite/Makefile.am|   3 +-
>  test-suite/tests/srfi-25.test | 461 
> ++
>  6 files changed, 876 insertions(+), 3 deletions(-)
>  create mode 100644 module/srfi/srfi-25.scm
>  create mode 100644 test-suite/tests/srfi-25.test

If there are no objections, you can push this patch within a day or two
to ‘stable-2.0’ (or I’ll do it if you happen to be unavailable.)

Thanks, Andreas!

Ludo’.

Re: Link failure on systems lacking mkstemp

[Eli Zaretskii]

> From: l...@gnu.org (Ludovic Courtès)
> Cc: guile-devel 
> Date: Fri, 30 Oct 2015 15:53:27 +0100
> 
> Eli Zaretskii  skribis:
> 
> > Guile 2.0.11 has mkstemp.c in lib/, from Gnulib, and it also has its
> > own private version in libguile/.  This causes link failures on
> > systems, such as MinGW, that lack mkstemp in their system libraries:
> >
> >CCLD libguile-2.0.la
> >  ../lib/.libs/libgnu.a(mkstemp.o): In function `mkstemp':
> >  d:\gnu\guile-2.0.11\lib/mkstemp.c:48: multiple definition of `mkstemp'
> >  
> > .libs/libguile_2.0_la-mkstemp.o:d:\gnu\guile-2.0.11\libguile/mkstemp.c:68: 
> > first defined here
> >  collect2.exe: error: ld returned 1 exit status
> >  Makefile:2242: recipe for target `libguile-2.0.la' failed
> >  make[3]: *** [libguile-2.0.la] Error 1
> >  make[3]: Leaving directory `/d/gnu/guile-2.0.11/libguile'
> >  Makefile:2162: recipe for target `all' failed
> >
> > I think the solution is simply remove mkstemp.c from libguile/, and
> > all its traces from the configury that causes its dependency to be
> > added to libguile/Makefile.  Not sure how to do the latter, though.
> 
> I’m ashamed of the delay but hey, better late than never.
> 
> This bug was reported independently at  and a
> fix was committed just yesterday, along the lines of what you suggested
> (see commit efd8a43.)  Let me know what you think.

Thanks, looks good.

Re: Link failure on systems lacking mkstemp

[Ludovic Courtès]

Hello, Eli,

Eli Zaretskii  skribis:

> Guile 2.0.11 has mkstemp.c in lib/, from Gnulib, and it also has its
> own private version in libguile/.  This causes link failures on
> systems, such as MinGW, that lack mkstemp in their system libraries:
>
>CCLD libguile-2.0.la
>  ../lib/.libs/libgnu.a(mkstemp.o): In function `mkstemp':
>  d:\gnu\guile-2.0.11\lib/mkstemp.c:48: multiple definition of `mkstemp'
>  
> .libs/libguile_2.0_la-mkstemp.o:d:\gnu\guile-2.0.11\libguile/mkstemp.c:68: 
> first defined here
>  collect2.exe: error: ld returned 1 exit status
>  Makefile:2242: recipe for target `libguile-2.0.la' failed
>  make[3]: *** [libguile-2.0.la] Error 1
>  make[3]: Leaving directory `/d/gnu/guile-2.0.11/libguile'
>  Makefile:2162: recipe for target `all' failed
>
> I think the solution is simply remove mkstemp.c from libguile/, and
> all its traces from the configury that causes its dependency to be
> added to libguile/Makefile.  Not sure how to do the latter, though.

I’m ashamed of the delay but hey, better late than never.

This bug was reported independently at  and a
fix was committed just yesterday, along the lines of what you suggested
(see commit efd8a43.)  Let me know what you think.

Apologies for the lack of response!

Thank you,
Ludo’.

Re: [patch] Location header is a URI-reference

[Ludovic Courtès]

Ping!

l...@gnu.org (Ludovic Courtès) skribis:

> Andy Wingo  skribis:
>
>> Following RFC 7231, the HTTP Location: header is a URI-reference, not a
>> URI.  This patch updates Guile's web modules appropriately, fixes a case
>> in which URI fragments were parsed incorrectly, and makes public
>> interfaces for creating URI references.
>>
>> Thoughts?  This is also in wip-uri-reference.
>
> Looks good!
>
> I think this addresses , right?
>
>> commit 81f61a615ff8c5c5d6e270c255c15eb164f3456c
>> Author: Andy Wingo 
>> Date:   Wed Oct 15 11:49:41 2014 +0200
>>
>> web: Location header is URI-reference; better URI-reference support
>> 
>> * module/web/uri.scm (validate-uri): Add reference? keyword argument,
>>   for validating references.
>>   (build-uri): Clarify comments to indicate that the result is an
>>   absolute URI.
>>   (build-uri-reference): New interface, to build URI-references.
>>   (string->uri-reference): Rename from string->uri*.  Fix fragment
>>   parsing to not include the #.
>>   (string->uri): Adapt to string->uri-reference name change.
>> 
>> * module/web/request.scm (request-absolute-uri): Add default-scheme
>>   optional argument.  Use it if the request-uri has no scheme, or
>>   error.
>> 
>> * module/web/http.scm (write-uri): Reflow to use "when".  Fix writing of
>>   URI-reference instances.
>>   (declare-uri-reference-header!): Rename from
>>   declare-relative-uri-header!.  Use string->uri-reference.
>>   ("Location"): Declare as a URI-reference header, as per RFC 7231.
>> 
>> * module/web/client.scm (open-socket-for-uri): Handle the case in which
>>   there is no URI scheme.
>> 
>> * test-suite/tests/web-http.test:
>> * test-suite/tests/web-uri.test: Add tests.
>
> Here the URI type is reused for URI references, which I think is good,
> but could it introduce incompatibilities?  Like code that has expected
> “normal” URI objects suddenly gets objects that are really URI
> references.  (Just thinking out loud.)
>
> Thanks for working on it!
>
> Ludo’.

Re: Failure in test-suite/standalone/test-ffi test

[Eli Zaretskii]

> From: l...@gnu.org (Ludovic Courtès)
> Cc: guile-devel 
> Date: Fri, 30 Oct 2015 15:59:00 +0100
> 
> >  In unknown file:
> > ?: 3 [primitive-load 
> > "d:/gnu/guile-2.0.11/test-suite/standalone/test-ffi"]
> >  In ice-9/eval.scm:
> >   453: 2 [eval # ()]
> >   387: 1 [eval # ()]
> >  In unknown file:
> > ?: 0 [dynamic-func "strerror" #]
> >ERROR: In procedure dynamic-func:
> >  ERROR: In procedure dynamic-pointer: Symbol not found: strerror
> >  FAIL: test-ffi
> >
> > Does this test make some unportable assumptions about the 'strerror'
> > symbol?
> 
> Yes.
> 
> Since the test just tries to use a global symbol exported from libc, we
> could use something else.

The equivalent of libc on Windows is a dynamic library, so these
functions are never statically linked into a program.

> Would ‘gethostname’ work on Windows?  That is, does:
> 
>   (dynamic-func "gethostname" (dynamic-link))
> 
> return a valid pointer?

No, that fails, but this works:

  (dynamic-func "strerror" (dynamic-link "msvcrt"))
=> #

(msvcrt.dll is the Windows equivalent of libc.)

So I think global references will always fail on Windows, so we should
simply skip this part of the test on Windows.

Thanks.

Re: Ideas for a Guile tutorial to go with the new site

[Christopher Allan Webber]

Luis Felipe López Acevedo writes:

> On 2015-10-20 17:45, BCG wrote:
>> On 10/19/2015 12:29 PM, Christopher Allan Webber wrote:
>>> Amirouche Boubekki writes:
>>> 
 To the contrary I think it's not a good idea to start upfront the
 tutorial with which editor should be used is a good way to loose half 
 of
 the readers, because they will feel more uncomfortable and not up to 
 the
 task. To be useful emacs requires one 'Getting Started' tutorial in
 itself. Or anykind of setup for that matter. The tutorial should go 
 as
 quickly as possible to the matter and start with coding.
 
 I started a tutorial at http://hypermove.net/. I don't introduce
 readline until the user knows what the REPL is. Part 1 is all done in
 REPL. I subtly introduce emacs as a good choice for an editor in part 
 2
 which is done in an editor. But doesn't enforce it.
>>> Okay, sorry if I wasn't being clear... my goal in that section would 
>>> be
>>> to encourage everyone who *isn't already an emacs user* to pick up a
>>> simple editor and know how to use that with Guile, but them give them 
>>> a
>>> brief tip that they want to look into Emacs + Geiser once they've 
>>> dived
>>> in a bit more deeply.
>>> 
>>> I don't think this section needs to be too long.  I agree it should 
>>> not
>>> be overwhelming.
>>> 
>> Personally I would appreciate a not-so-brief tip.  Most resources on
>> the web about coding in scheme seem to claim that emacs is the best
>> environment for it, but rarely go into the reasoning about why or
>> provide a focused way to get started with it.  I'd be happy to try out
>> those tools, but it hardly is worth it to me to slog through the emacs
>> tutorial just to see if I like whatever advantages it may have for
>> coding Scheme.
>
> I think a video tutorial to get the user started with Guile + Emacs 
> would be great for that. First video in a "Learn GNU Guile" series 
> hosted in a MediaGoblin instance :)

That would be great, yes!