Re: GNU G-Golf 0.8.0-rc-2 available for testing

[Aleix Conchillo Flaqué]

With Gtk debug symbols, from this version:

https://gitlab.gnome.org/GNOME/gtk/-/tree/4.12.4

On Thu, Dec 21, 2023 at 11:01 PM Aleix Conchillo Flaqué <
aconchi...@gmail.com> wrote:

>
> This is from: lldb -- guile -e main drawing-widget.scm
>
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=2, address=0x63466480)
> frame #0: 0x63466480
> ->  0x63466480: .long  0x02f6c000; unknown opcode
> 0x63466484: udf#0x6000
> 0x63466488: .long  0x4c8098b0; unknown opcode
> 0x6346648c: udf#0x1
> Target 0: (guile) stopped.
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=2, address=0x6081a100)
>   * frame #0: 0x6081a100
> frame #1: 0x0001050b3f58 libgtk-4.1.dylib`gtk_widget_do_snapshot +
> 568
> frame #2: 0x0001050b4780
> libgtk-4.1.dylib`gtk_widget_snapshot_child + 132
> frame #3: 0x0001050b6d90 libgtk-4.1.dylib`gtk_widget_real_snapshot
> + 52
> frame #4: 0x0001050b3ef4 libgtk-4.1.dylib`gtk_widget_do_snapshot +
> 468
> frame #5: 0x0001050b3cfc libgtk-4.1.dylib`gtk_widget_snapshot + 44
> frame #6: 0x0001050b40c4 libgtk-4.1.dylib`gtk_widget_render + 168
> frame #7: 0x0001050c1ce0 libgtk-4.1.dylib`surface_render + 28
>

frame #1: 0x0001033abf58 libgtk-4.1.dylib`gtk_widget_do_snapshot
[inlined] gtk_widget_create_render_node(widget=0x000139e1f110,
snapshot=0x00013a093200) at gtkwidget.c:11862:7 [opt]
frame #2: 0x0001033abf48
libgtk-4.1.dylib`gtk_widget_do_snapshot(widget=0x000139e1f110,
snapshot=0x00013a093200) at gtkwidget.c:11897:17 [opt]
frame #3: 0x0001033ac780
libgtk-4.1.dylib`gtk_widget_snapshot_child(widget=0x000139e1df70,
child=0x000139e1f110, snapshot=0x00013a093200) at
gtkwidget.c:12318:3 [opt]
frame #4: 0x0001033aed90
libgtk-4.1.dylib`gtk_widget_real_snapshot(widget=0x000139e1df70,
snapshot=0x00013a093200) at gtkwidget.c:756:5 [opt]
frame #5: 0x0001033abef4 libgtk-4.1.dylib`gtk_widget_do_snapshot
[inlined] gtk_widget_create_render_node(widget=0x000139e1df70,
snapshot=0x00013a093200) at gtkwidget.c:11857:7 [opt]
frame #6: 0x0001033abde4
libgtk-4.1.dylib`gtk_widget_do_snapshot(widget=0x000139e1df70,
snapshot=0x00013a093200) at gtkwidget.c:11897:17 [opt]
frame #7: 0x0001033abcfc
libgtk-4.1.dylib`gtk_widget_snapshot(widget=,
snapshot=0x00013a093200) at gtkwidget.c:11919:3 [opt]
frame #8: 0x0001033ac0c4
libgtk-4.1.dylib`gtk_widget_render(widget=0x000139e1df70,
surface=0x000139e1f280, region=0x63a78820) at
gtkwidget.c:11951:3 [opt]
frame #9: 0x0001033b9ce0
libgtk-4.1.dylib`surface_render(surface=,
region=, widget=) at gtkwindow.c:4804:3 [opt]

Fails here:

https://gitlab.gnome.org/GNOME/gtk/-/blob/4.12.4/gtk/gtkwidget.c#L11860-11863



> And this one from: lldb -- guile -e main simple-paintable.scm
>
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=2, address=0x632e7340)
> frame #0: 0x632e7340
> ->  0x632e7340: .long  0x029e0180; unknown opcode
> 0x632e7344: udf#0x6000
> 0x632e7348: .long  0x41809eb0; unknown opcode
> 0x632e734c: udf#0x1
> Target 0: (guile) stopped.
> (lldb) bt
> * thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
> (code=2, address=0x632e7340)
>   * frame #0: 0x632e7340
> frame #1: 0x000103c62ed8
> libgtk-4.1.dylib`gtk_image_set_from_paintable + 144
>


frame #1: 0x000102cfaed8
libgtk-4.1.dylib`gtk_image_set_from_paintable(image=0x00012e72c3c0,
paintable=0x631d33a0) at gtkimage.c:843:27 [opt]

This one fails here:

https://gitlab.gnome.org/GNOME/gtk/-/blob/4.12.4/gtk/gtkimage.c#L843

Re: GNU G-Golf 0.8.0-rc-2 available for testing

[Aleix Conchillo Flaqué]

On Thu, Dec 21, 2023 at 8:53 PM David Pirotte  wrote:

> Hi Aleix,
>
> ...
> > Anyways, guile-cairo is fine going back to stable 3.0.9.
>
> Ok, so just to make sure, now both the gtk4/simple-paintable.scm and
> gtk4/animated-paintable.scm examples work fine on 'your' platform as
> well?
>
>
Nope, they don't. Sorry, I should have been much more explicit and provide
more info.

> > - drawing-widget.scm, peg-solitaire.scm.
> > > ...
>
> > The issue seems to be here:
>
> > (define-vfunc (snapshot-vfunc (self ) snapshot)
> >   #t)
>
> a-
>
> And does that works? It should, but/and obviously not drawing
> anything, but no bug/no crash?
>
>
It doesn't, it segfaults.

b-
>
> Can you try, in a repl:
>
>   ,use (g-golf)
>   (gi-import-by-name "Gtk" "Widget")
>   $5 = #<  7fe9c1681d20>
>
>   (gi-import-by-name "Gtk" "init")
>   $6 = #< 7fe9c1555360>
>
>   (gtk-init)
>
>   (graphene-rect-alloc)
>   $7 = #
>
> ;; below you'd substitute the $7 appropriately if for some
> ;; reason you happen to have a diff repl var $ flow,
> ;; you need the result of (graphene-rect-alloc)
>
>   (graphene-rect-init $7 0 0 50 50)
>   $8 = #
>
>
That worked:

scheme@(guile-user)> ,use (g-golf)
scheme@(guile-user)>   (gi-import-by-name "Gtk" "Widget")
$1 = #<  107091b40>
scheme@(guile-user)>   (gi-import-by-name "Gtk" "init")
$2 = #< 107809360>
scheme@(guile-user)>   (gtk-init)
scheme@(guile-user)>   (graphene-rect-alloc)
$3 = #
scheme@(guile-user)>   (graphene-rect-init $3 0 0 50 50)
$4 = #

c-
>
> Let's see, but if all the above work, can you poste the error you get
> with no modification of the upstream version of the example, or does it
> segfault?
>
> If no segfault, in a repl:
>
>   (load "/examples/gtk-4/drawing-widget.scm")
>   (main '())
>   => error
>
>   ,bt #:width 1000 #:full? #t
>
> If it segfault, we'd need to get a gdb backtrace - would that be
> possible?
>
>
I need to build with debug symbols, but in case it gives you some idea
now...

This is from: lldb -- guile -e main drawing-widget.scm

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=2, address=0x63466480)
frame #0: 0x63466480
->  0x63466480: .long  0x02f6c000; unknown opcode
0x63466484: udf#0x6000
0x63466488: .long  0x4c8098b0; unknown opcode
0x6346648c: udf#0x1
Target 0: (guile) stopped.
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=2, address=0x6081a100)
  * frame #0: 0x6081a100
frame #1: 0x0001050b3f58 libgtk-4.1.dylib`gtk_widget_do_snapshot +
568
frame #2: 0x0001050b4780 libgtk-4.1.dylib`gtk_widget_snapshot_child
+ 132
frame #3: 0x0001050b6d90 libgtk-4.1.dylib`gtk_widget_real_snapshot
+ 52
frame #4: 0x0001050b3ef4 libgtk-4.1.dylib`gtk_widget_do_snapshot +
468
frame #5: 0x0001050b3cfc libgtk-4.1.dylib`gtk_widget_snapshot + 44
frame #6: 0x0001050b40c4 libgtk-4.1.dylib`gtk_widget_render + 168
frame #7: 0x0001050c1ce0 libgtk-4.1.dylib`surface_render + 28
frame #8: 0x0001051fa708
libgtk-4.1.dylib`_gdk_marshal_BOOLEAN__BOXEDv + 124
frame #9: 0x000101c122f0
libgobject-2.0.0.dylib`_g_closure_invoke_va + 212
frame #10: 0x000101c2705c
libgobject-2.0.0.dylib`signal_emit_valist_unlocked + 860
frame #11: 0x000101c26cd4
libgobject-2.0.0.dylib`g_signal_emit_valist + 64
frame #12: 0x000101c27884 libgobject-2.0.0.dylib`g_signal_emit + 28
frame #13: 0x000105239238
libgtk-4.1.dylib`gdk_surface_paint_on_clock + 216
frame #14: 0x000101c122f0
libgobject-2.0.0.dylib`_g_closure_invoke_va + 212
frame #15: 0x000101c274fc
libgobject-2.0.0.dylib`signal_emit_valist_unlocked + 2044
frame #16: 0x000101c26cd4
libgobject-2.0.0.dylib`g_signal_emit_valist + 64
frame #17: 0x000101c27884 libgobject-2.0.0.dylib`g_signal_emit + 28
frame #18: 0x000105227654
libgtk-4.1.dylib`gdk_frame_clock_paint_idle + 732
frame #19: 0x000101ce2244 libglib-2.0.0.dylib`g_timeout_dispatch +
92
frame #20: 0x000101ce5bb8
libglib-2.0.0.dylib`g_main_context_dispatch_unlocked + 236
frame #21: 0x000101ce5eac
libglib-2.0.0.dylib`g_main_context_iterate_unlocked + 400
frame #22: 0x000101ce5f0c
libglib-2.0.0.dylib`g_main_context_iteration + 60
frame #23: 0x00010202b374 libgio-2.0.0.dylib`g_application_run + 548
frame #24: 0x00019d18a050 libffi.dylib`ffi_call_SYSV + 80
frame #25: 0x00019d192adc libffi.dylib`ffi_call_int + 1208
frame #26: 0x000101b4d8f0
libgirepository-1.0.1.dylib`g_callable_info_invoke + 860
frame #27: 0x000101b4ec14
libgirepository-1.0.1.dylib`g_function_info_invoke + 252
frame #28: 0x00019d18a050 libffi.dylib`ffi_call_SYSV + 80
frame #29: 0x00019d192adc libffi.dylib`ffi_call_int + 1208
frame #30: 0x0001005b4220 libguile-3.0.1.dylib`scm_i_foreign_call +
432
frame #31: 0x000100636a94 libg

Re: GNU G-Golf 0.8.0-rc-2 available for testing

[Aleix Conchillo Flaqué]

On Mon, Dec 4, 2023 at 8:14 PM David Pirotte  wrote:

>
> you must clone the guile-cairo upstream repo, git checkout devel, then
> run the make danse ... let me know if this solve you problem.
>
>
Yes, I had that already. In the previous package I had to add individual
patches, but now I can just point to a commit:

https://github.com/aconchillo/homebrew-guile/blob/master/Formula/guile-cairo.rb#L4

However, guile-cairo was not working because I was using guile from commit
(d8df317bafcdd9fcfebb636433c4871f2fab28b2) and that's causing a segfault
during scm_init_cairo (when defining all the procedures).

Anyways, guile-cairo is fine going back to stable 3.0.9.

> - drawing-widget.scm, peg-solitaire.scm.
>
> i don't know, but they have in common that  they both use snapshots
> (the gtk-4 drawing 'tool' ...)
>
> I would try to first get the drawing-widget.scm to work, it is a very
> simple example, then see how to fix the peg-solitaire.scm
>
>
The issue seems to be here:

(define-vfunc (snapshot-vfunc (self ) snapshot)
  #t)

I just removed the whole body and replaced it for #t, just to test. All the
other ones that are failing also have a define-vfunc.

I haven't investigated what that is so I can't tell much more.

Aleix

Re: GNU G-Golf 0.8.0-rc-2 available for testing

[Aleix Conchillo Flaqué]

On Mon, Dec 4, 2023 at 8:14 PM David Pirotte  wrote:

> Hello Aleix,
>
>
Hi!

> - animated-paintable.scm, simple-paintable.scm: it might be something
> > cairo related. I have guile-cairo 1.11.2
>
> you must clone the guile-cairo upstream repo, git checkout devel, then
> run the make danse ... let me know if this solve you problem.
>
>
Yeah, I have a guile-cairo formula but it crashes right now. I guess I have
to figure out that first.

> - drawing-widget.scm, peg-solitaire.scm.
>
> i don't know, but they have in common that  they both use snapshots
> (the gtk-4 drawing 'tool' ...)
>
> I would try to first get the drawing-widget.scm to work, it is a very
> simple example, then see how to fix the peg-solitaire.scm
>
>
OK. I'll take a look at that after the cairo issue.

Aleix

Re: GNU G-Golf 0.8.0-rc-2 available for testing

[Aleix Conchillo Flaqué]

This is now available on macOS via Guile Homebrew:

brew install g-golf



On Wed, Nov 1, 2023 at 8:51 PM David Pirotte  wrote:

> Hello Guilers,
>
> The second release candidate of the upcoming GNU G-Golf 0.8.0 release is
> now available for testing:
>
> * Tarball and a GPG detached signature [*]:
>
> http://ftp.gnu.org/gnu/g-golf/g-golf-0.8.0-rc-2.tar.gz
> http://ftp.gnu.org/gnu/g-golf/g-golf-0.8.0-rc-2.tar.gz.sig
>
> * Install
>
> Dependencies and complete installation instructions are given in the
> distributed INSTALL file, or here:
>
> https://www.gnu.org/software/g-golf/install.html
>
> * Noteworthy changes in 0.8.0-rc-2
>
> Here is a summary of the noteworthy changes in this release, also
> available in NEWS file and on the G-Golf website.
>
> ** Examples
>
> Adwaita Demo
>
> The 'Dialogs' page has been added to the demo.
>
> ** Bug fixing
>
> emit
> signal-emit
>
> Fixed to properly handle 'object extra arg(s) type. Prior to this fix, a
> call such (emit window 'add-toast toast), with window and toast being
> goops proxy instances, would raise an exception, as the extra args
> handler missed a proper dispatch clause and treatment for the 'object
> arg type,
>
> * You can help
>
> 1. Testing by installing from the tarball, or from the source if you
>prefer, on the distro of your choice.
>
> 2. By running the distributed examples.
>
> Ultimately, one of the best way to test, and participate, is to select
> G-Golf to develop the next application of your dream! Here is an
> overview of the GNOME platform libraries [1], accessible using G-Golf.
> In particular, libadwaita [2] provides a number of widgets that change
> their layout based on the available space. This can be used to make
> applications adapt their UI between desktop and mobile devices (as shown
> in the G-Golf port of the "Adwaita demo").
>
> * Contact
>
> Consider joining us on irc [3], where you may ask for help or report a
> problem [4].
>
> However, if you prefer:
>
> G-Golf uses the guile-u...@gnu.org mailing list
> Report bugs to bug-g-g...@gnu.org
>
>
> Thanks!
> David
>
>
> [*] Use a .sig file to verify that the corresponding file (without the
> .sig suffix) is intact.  First, be sure to download both the .sig
> file and the corresponding tarball.  Then, run a command like this:
>
> gpg --verify g-golf-0.8.0-rc-2.tar.gz
>
> If that command fails because you don't have the required public
> key, then run this command to import it:
>
> gpg --keyserver keys.gnupg.net --recv-keys A3057AD7
>
> and rerun the 'gpg --verify' command
>
>
> [1]
> https://developer.gnome.org/documentation/introduction/overview/libraries.html
> [2] https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/
> [3] https://www.gnu.org/software/g-golf/contact.html
>
> [4] When reporting a problem, or if you think you found a bug, it is
> very important that you prepare a minimal reproducible example (MRE),
> sometimes also referred to as a short self-contained correct example
> (SSCCE)
>
> http://www.sscce.org/
> https://en.wikipedia.org/wiki/Minimal_reproducible_example
>
> Also, on irc, we chat :), so please do not write code snipsets directly
> in the channel, unless 2 or 3 lines of code, nor error messages of
> course - for more then 2 or 3 lines of code, or error messages, always
> use a tor-friendly paste service (avoid those that track its visitors
> and require javascript, thanks!).
>

Re: GNU G-Golf 0.8.0-a.4 available for testing

[Aleix Conchillo Flaqué]

On Mon, May 1, 2023 at 10:35 AM David Pirotte  wrote:

> Hi Aleix,
>
>
Hi there!

> > Making install in libg-golf
> >
> >   CC   libg_golf_la-gg-ffi.lo
> >   CC   libg_golf_la-gg-utils.lo
> >   CC   libg_golf_la-gg-glib.lo
> >   CC   libg_golf_la-gg-gobject.lo
> >   CC   libg_golf_la-gg-callback.lo
> >   CC   libg_golf_la-gg-test-suite.lo
> >   CC   libg_golf_la-g-golf.lo
> >   CCLD libg-golf.la
> > Undefined symbols for architecture arm64:
> >   "_ffi_prep_cif", referenced from:
> >   _gg_ffi_prep_cif in libg_golf_la-gg-ffi.o
> >  (maybe you meant: _gg_ffi_prep_cif)
> > ld: symbol(s) not found for architecture arm64
> > clang: error: linker command failed with exit code 1 (use -v to see
> > invocation)
>
> The gg-ffi.c[h] files were changed after 0.8.0-a.2, introducing those
> new functions, see commit 15e689d3446632d4a78e4b02c20495b4b0a4ba22
> Jan the 16th 2023.
>
> I would recommend to uninstall g-golf, clear your cache(s), clear the
> build repo and try again.
>
>
I cleaned everything up and had the same issue. This time I investigated a
bit.

The Makefile.am refers to FFI_CFLAGS and FFI_LIBS, but I don't see any
reference to them and there's no PKG_CHECK_MODULES or anything that could
define those in configure.ac or any m4 macro.

Adding PKG_CHECK_MODULES line solved the issue:

PKG_CHECK_MODULES(FFI, libffi >= 3.3.0)

In 0.8.0-a.2 I guess libffi was really not used yet and as long as you had
the header file you were fine.

Let me know if this makes sense or if I'm missing something.

Thank you!

Aliex

Re: GNU G-Golf 0.8.0-a.4 available for testing

[Aleix Conchillo Flaqué]

On Sun, Apr 16, 2023 at 7:51 PM David Pirotte  wrote:

> Hello Guilers,
>
>
Hi David,

> The fourth alpha release of the upcoming GNU G-Golf 0.8.0 release is
> now available for testing:
>
> -]  Tarball and a GPG detached signature [*]:
>
> http://ftp.gnu.org/gnu/g-golf/g-golf-0.8.0-a.4.tar.gz
> http://ftp.gnu.org/gnu/g-golf/g-golf-0.8.0-a.4.tar.gz.sig
>
> -]  Dependencies and complete installation instructions are given
> in the distributed INSTALL file, or here:
>
> https://www.gnu.org/software/g-golf/install.html
>
> -]  The list of noteworthy changes since version 0.8.0-a.3 are
> given in the distributed NEWS file, or here:
>
> https://www.gnu.org/software/g-golf/news.html
>
> You can help by:
>
>   1. Testing by installing from the tarball, or from the source if you
>   prefer, on the distro of your choice.
>
>
I haven't had time to check what's going on but in case it sounds familiar
I just ran into the following (it was not happening with 0.8-a.2). This is
on macOS 13.3.1, glib 2.76.2:

Making install in libg-golf

  CC   libg_golf_la-gg-ffi.lo
  CC   libg_golf_la-gg-utils.lo
  CC   libg_golf_la-gg-glib.lo
  CC   libg_golf_la-gg-gobject.lo
  CC   libg_golf_la-gg-callback.lo
  CC   libg_golf_la-gg-test-suite.lo
  CC   libg_golf_la-g-golf.lo
  CCLD libg-golf.la
Undefined symbols for architecture arm64:
  "_ffi_prep_cif", referenced from:
  _gg_ffi_prep_cif in libg_golf_la-gg-ffi.o
 (maybe you meant: _gg_ffi_prep_cif)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)


>

Re: GNU G-Golf 0.8.0-a.1 available for testing!

[Aleix Conchillo Flaqué]

On Fri, Mar 24, 2023 at 9:18 PM David Pirotte  wrote:

> Hello Aleix,
>
>
Hi!

> I am sorry it took me so long to answer.
>
>
Not at all! :-)

> > ...
> > I was able to add g-golf to Guile Homebrew. So it now runs on macOS
> > ...
>
> > The changes are:
> >
> > - We need the full path of glib, gobject, etc.
>
> Certainly not, never ever :) - This is a distro thing, Upstream gnu
> tool chained pkg(s) should never ever do that.
>
> > - The configure.ac patch fixes SITEDIR and SITECACHEDIR when
> > --with-guile-site=no ...
>
> No,
> Exactly the opposite, that is, their setting is correct, both in
> g-golf, guile-lib and guile-cv fwiw
>
> when a user does not configure passing the --with-guile-site=yes
> then _nothing_, nor the pkg scm modules, nor the .go files, nor
> any lib should be installed in the 'guile installed dirs'
>
>
I have checked again and you are absolutely right. My issue was something
that only applies to Homebrew.


> - The Makefile.am patch places libg-golf in the Guile extensions
> > directory $(libdir)/guile/$(GUILE_EFFECTIVE_VERSION)/extensions,
> > which I believe is the right thing to do.
>
> you mean the libg-golf/Makefile.am i guess
>
> [ and you probably don't mean
> [ $(libdir)/guile/$(GUILE_EFFECTIVE_VERSION)/extensions
> [ but GUILE_EXTENSION (provided by guile.m4
>
> I agree with you that when a g-golf user calls configure passing the
> --with-guile-site=yes, then libg-golf could be installed in
> GUILE_EXTENSION dir.
>
> If not, then the current- g-golf setting is correct
>


Yes, not a big deal.

Thanks for getting back to me.

Best,

Aleix

Re: [PATCH v1 1/6] docs/match: add pattern matching examples

[Aleix Conchillo Flaqué]

On Mon, Jan 30, 2023 at 6:53 PM Maxime Devos  wrote:

> On 30-01-2023 20:56, Aleix Conchillo Flaqué wrote:
> > [...] Maxime found the time to review a quite big PR and added a
> > bunch of useful comments. Reviewing that PR took a lot of effort and I
> > just felt better after fixing all the comments made. I was even
> > surprised he (I'm assuming this pronoun) did.
>
> Unfortunately you are assuming incorrectly; s/he/she/. (*)
> For future reference, 'they' is usually a safe ‘default’ (except when
> they hate that, eergh).  At least, for some values of 'usual' that might
> not be representative.
>
>
Oh, well. I confess I did a quick Google search but I clearly assumed
incorrectly based on the results, my bad. I don't hate using they at all.

> [...] And my feeling is she just wants things to
> > be as correct as possible, which is quite important, especially in a
> > programming language.
>
> That's it, yes.
>
> > Exchanging messages in a written form has its own challenges (your mood
> > on that day, maybe you phrase things in a way that can be misunderstood,
> > ...). So I will stop writing and just leave you all with a smiley face.
> :-)
> >
> > Best,
>
> Something I would like to add here, is that these kind of emotional
> challenges often appear self-inflicted to me.  I mean, the mailing list
> is a rather technical medium for technical talk about technical things.
> There is no emotional stuff there unless you add it or you assume it.
>
> Instead of analysing technical messages on the ML for whether there's
> some emotional hidden message behind it, can't we just assume that any
> technical messages are just technical, meaning literally what's written
> in them?
>
>
That's how I see it too and that would be ideal.


> I'm not saying that the emotional stuff should be completely forbidden,
> but like, with a little care you can separate the technical from the
> emotional, e.g.:
>
> ‘[Oh, I wanted that feature for a long time!]
>
>  This won't work at all because it assumes frobs are never barzed,
>  yet they are when [...].  I'm thinking you'll need a completely
>  different approach, though I don't have a clue what this approach
>  would be.
>
>  [Keep up the good work!]’
>
> (The [...] lines are nice, but optional.  Also the brackets are
> optional.).  Like, the second paragraph just says it won't work at all
> because $reasons.  While very unfortunate, there is no malice anywhere;
> it's just technical stuff.  Likewise, the first [...] and last [...],
> while emotionally positive, are irrelevant for the evaluation of the
> technical middle part.
>
>
Again, that's how I try to approach it as well. And actually I believe I
tend to be emotional by adding positive messages as the ones you just
mentioned. Even though they are irrelevant I like to think people like to
read nice things after all (at least, I do).


> > Aleix
> >
>
> (*) There are people who apologise after making such mistaken
> assumptions, which I suppose is a quite reasonable course of action to
> take in general, but please don't in this case?  It just seems
> embarrassing to me.
>

Since you made it optional with ?... I apologize. I don't mind
embarrassing myself (and I hope I don't embarrass you).

Best and keep up the good work!

Aleix

Re: [PATCH v1 1/6] docs/match: add pattern matching examples

[Aleix Conchillo Flaqué]

On Mon, Jan 30, 2023 at 11:56 AM Aleix Conchillo Flaqué <
aconchi...@gmail.com> wrote:

> Hi!
>
> On Sun, Jan 29, 2023 at 4:50 PM Blake Shaw  wrote:
>
>>
>> And there's more, its a pattern; I dont know if you troll everyone like
>> this or if I represent something you feel opposed to, but I do know that it
>> was enough for me to become allergic to Guile/Guix community until I
>> started hanging out on Mastodon and discovered many guix have retreated
>> there.
>>
>>>
>>>
> First, I apologize for not having gone through all the comments and
> reviews or mailing lists messages you guys are discussing. I just wanted to
> give my cent (not even two) about the paragraph above.
>
> My interactions with Maxime (mainly through code reviews) have been great.
> The biggest review was the one done to merge libevent support into Fibers.
> Maxime found the time to review a quite big PR and added a bunch of useful
> comments. Reviewing that PR took a lot of effort and I just felt better
> after fixing all the comments made. I was even surprised he (I'm assuming
> this pronoun) did.
>
> I've always taken code reviews as an opportunity to learn (not suggesting
> that you are not, far from that), and whether it's true that Maxime had a
> lot of comments (all of them made sense as far as I remember), it's also
> true that he is one of the few ones to make code reviews (specially in
> Guile). And my feeling is he just wants things to be as correct as
> possible, which is quite important, especially in a programming language.
>
> Exchanging messages in a written form has its own challenges (your mood on
> that day, maybe you phrase things in a way that can be misunderstood, ...).
> So I will stop writing and just leave you all with a smiley face. :-)
>
>

Linking the libevent PR on Fibers in case anyone is curious:
https://github.com/wingo/fibers/pull/53

Re: [PATCH v1 1/6] docs/match: add pattern matching examples

[Aleix Conchillo Flaqué]

Hi!

On Sun, Jan 29, 2023 at 4:50 PM Blake Shaw  wrote:

>
> And there's more, its a pattern; I dont know if you troll everyone like
> this or if I represent something you feel opposed to, but I do know that it
> was enough for me to become allergic to Guile/Guix community until I
> started hanging out on Mastodon and discovered many guix have retreated
> there.
>
>>
>>
First, I apologize for not having gone through all the comments and reviews
or mailing lists messages you guys are discussing. I just wanted to give my
cent (not even two) about the paragraph above.

My interactions with Maxime (mainly through code reviews) have been great.
The biggest review was the one done to merge libevent support into Fibers.
Maxime found the time to review a quite big PR and added a bunch of useful
comments. Reviewing that PR took a lot of effort and I just felt better
after fixing all the comments made. I was even surprised he (I'm assuming
this pronoun) did.

I've always taken code reviews as an opportunity to learn (not suggesting
that you are not, far from that), and whether it's true that Maxime had a
lot of comments (all of them made sense as far as I remember), it's also
true that he is one of the few ones to make code reviews (specially in
Guile). And my feeling is he just wants things to be as correct as
possible, which is quite important, especially in a programming language.

Exchanging messages in a written form has its own challenges (your mood on
that day, maybe you phrase things in a way that can be misunderstood, ...).
So I will stop writing and just leave you all with a smiley face. :-)

Best,

Aleix

Re: GNU Guile 3.0.9rc1 available for testing!

[Aleix Conchillo Flaqué]

On Mon, Jan 23, 2023 at 2:48 AM Ludovic Courtès  wrote:

> Hi,
>
> Greg Troxel  skribis:
>
> > lloda  writes:
> >
> >> This looks like https://debbugs.gnu.org/60971 <
> https://debbugs.gnu.org/60971> on mac os.
> >
> > Yes, it does.
> >
> > My quick reaction is that if the POSIX-required macros operation on
> > system types that might be struct, then faking up ints for testing is
> > unsound.
> >
> > Maybe only do verify if guile has to define macros, and don't try to
> > test the OS?
>
> So something like the patch below?
>

Oh, I missed the other report. Yes, this works on macOS as just reported by
Daniel. No other issues.

Aleix

Re: GNU Guile 3.0.9rc1 available for testing!

[Aleix Conchillo Flaqué]

On Mon, Jan 23, 2023 at 2:45 AM Ludovic Courtès  wrote:

> Hola!
>
>
Hola!

> Aleix Conchillo Flaqué  skribis:
>
> > Not because I worked on it :-), but missing JIT support on Apple Silicon
> > chips in the NEWS, which makes Guile *fast* on that hardware.
> >
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44505
>
> Oops, my bad; added to NEWS!
>
>
Mmm still don't see it.


> You confirm that building from the tarball still works, right?
>
>
Actually, it doesn't. Just tried it. I'll see if I have time tonight to fix
it. Hang tight!

  CC   libguile_3.0_la-posix.lo
posix.c:109:9: error: cannot take the address of an rvalue of type 'int'
verify (WEXITSTATUS (W_EXITCODE (127, 0)) == 127);
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/wait.h:144:27:
note: expanded from macro 'WEXITSTATUS'
#define WEXITSTATUS(x)  ((_W_INT(x) >> 8) & 0x00ff)
  ^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/wait.h:131:34:
note: expanded from macro '_W_INT'
#define _W_INT(w)   (*(int *)&(w))  /* convert union wait to int */
 ^
../lib/verify.h:305:32: note: expanded from macro 'verify'
# define verify(R) _GL_VERIFY (R, "verify (" #R ")", -)
   ^~~~

Re: GNU Guile 3.0.9rc1 available for testing!

[Aleix Conchillo Flaqué]

On Fri, Jan 20, 2023 at 7:58 AM Ludovic Courtès  wrote:

> Hello Guilers!
>
> (Cc’ing packagers I know; feel free to ping other packagers!)
>
> I pushed the ‘v3.0.9rc1’ tag on the ‘main’ branch and uploaded the
> tarballs produced by “make distcheck” from that tag:
>
>
Awesome! Thank you!

Not because I worked on it :-), but missing JIT support on Apple Silicon
chips in the NEWS, which makes Guile *fast* on that hardware.

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44505

Best,

Aleix

Re: compilation error on Apple M1

[Aleix Conchillo Flaqué]

Hi Damien,

This looks like a linking issue probably related to how things are
installed in your system, not with Guile itself. And the issue seems to be
with libiconv. Usually that comes with macOS itself and is located in
/usr/lib/libiconv.2.dylib.

Building Guile on M1 is definitely possible and works. I would suggest
using Homebrew which already has all Guile dependencies figured out.
Actually, I just recently added the Apple Silicon chip fix that Colin
mentions to Homebrew as well (
https://github.com/Homebrew/homebrew-core/pull/118698), because even if you
solve the issue you are currently getting you are going to run into the
next one (which is that you need to disable JIT which makes Guile very slow
unless you apply that fix).

Also, if you use Guile from Homebrew you will benefit from Guile Homebrew
which has all these packages ready to be used:
https://github.com/aconchillo/homebrew-guile/tree/master/Formula

Some people dislike Homebrew very much and refuse to install it, so I
totally understand if that's the case.

Best,

Aleix

On Sun, Dec 25, 2022 at 3:33 PM Damien Mattei 
wrote:

> hello,
>
> on Apple M1 i have this error:
>
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:215:48:
> note: expanded from macro '__deprecated_msg'
> #define __deprecated_msg(_msg)
> __attribute__((__deprecated__(_msg)))
>   ^
> 1 warning generated.
>   CC   libguile_3.0_la-net_db.lo
>   CC   libguile_3.0_la-socket.lo
>   CC   libguile_3.0_la-regex-posix.lo
>   CCLD libguile-3.0.la
> Undefined symbols for architecture arm64:
>   "_iconv", referenced from:
>   _mem_cd_iconveh_internal in libgnu.a(striconveh.o)
>  (maybe you meant: _str_iconveh, _mem_iconveh ,
> _scm_port_acquire_iconv_descriptors , _iconveh_open , _iconveh_close ,
> _mem_cd_iconveh , _str_cd_iconveh , _scm_port_release_iconv_descriptors )
>   "_iconv_close", referenced from:
>   _iconveh_open in libgnu.a(striconveh.o)
>   _iconveh_close in libgnu.a(striconveh.o)
>   "_iconv_open", referenced from:
>   _iconveh_open in libgnu.a(striconveh.o)
> ld: symbol(s) not found for architecture arm64
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> make[3]: *** [libguile-3.0.la] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
> any idea about this arm64?
>
> regards,
> Damien
>

Re: [PATCH] fix Apple Silicon JIT compilation

[Aleix Conchillo Flaqué]

Ping. This one is important to run Guile with JIT on new Apple hardware.

On Thu, Nov 17, 2022 at 5:36 PM Aleix Conchillo Flaqué 
wrote:

> * configure.ac: check for pthread_jit_write_protect_np.
>
> * libguile/jit.c: add support for Apple Silicon JIT compilation.
>
> Fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44505
> ---
>  configure.ac   |  3 +++
>  libguile/jit.c | 25 -
>  2 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index b3879df1f..f8c12f0d7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1187,6 +1187,9 @@ case "$with_threads" in
>pthread_get_stackaddr_np pthread_attr_get_np pthread_sigmask \
>pthread_cancel])
>
> +# Apple Silicon JIT code arena needs to be unprotected before writing.
> +AC_CHECK_FUNCS([pthread_jit_write_protect_np])
> +
>  # On past versions of Solaris, believe 8 through 10 at least, you
>  # had to write "pthread_once_t foo = { PTHREAD_ONCE_INIT };".
>  # This is contrary to POSIX:
> diff --git a/libguile/jit.c b/libguile/jit.c
> index 8420829b4..5cef8fae3 100644
> --- a/libguile/jit.c
> +++ b/libguile/jit.c
> @@ -47,6 +47,10 @@
>  #include 
>  #endif
>
> +#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
> +#include 
> +#endif
> +
>  #include "jit.h"
>
>
> @@ -1349,9 +1353,13 @@ allocate_code_arena (size_t size, struct code_arena
> *prev)
>ret->size = size;
>ret->prev = prev;
>  #ifndef __MINGW32__
> +  int flags = MAP_PRIVATE | MAP_ANONYMOUS;
> +#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
> +  flags |= MAP_JIT;
> +#endif
>ret->base = mmap (NULL, ret->size,
>  PROT_EXEC | PROT_READ | PROT_WRITE,
> -MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> +flags, -1, 0);
>if (ret->base == MAP_FAILED)
>  {
>perror ("allocating JIT code buffer failed");
> @@ -1406,11 +1414,21 @@ emit_code (scm_jit_state *j, void (*emit)
> (scm_jit_state *))
>
>uint8_t *ret = jit_address (j->jit);
>
> +#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
> +  pthread_jit_write_protect_np(0);
> +#endif
> +
>emit (j);
>
>size_t size;
>if (!jit_has_overflow (j->jit) && jit_end (j->jit, &size))
>  {
> +#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
> +  /* protect previous code arena. leave unprotected after emit()
> + since jit_end() also writes to code arena. */
> +  pthread_jit_write_protect_np(1);
> +  sys_icache_invalidate(arena->base, arena->size);
> +#endif
>ASSERT (size <= (arena->size - arena->used));
>DEBUG ("mcode: %p,+%zu\n", ret, size);
>arena->used += size;
> @@ -1424,6 +1442,11 @@ emit_code (scm_jit_state *j, void (*emit)
> (scm_jit_state *))
>  }
>else
>  {
> +#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
> +  /* protect previous code arena */
> +  pthread_jit_write_protect_np(1);
> +  sys_icache_invalidate(arena->base, arena->size);
> +#endif
>jit_reset (j->jit);
>if (arena->used == 0)
>  {
> --
> 2.37.1 (Apple Git-137.1)
>
>

Re: GNU G-Golf 0.8.0-a.1 available for testing!

[Aleix Conchillo Flaqué]

Great! Thank you David!

I was able to add g-golf to Guile Homebrew. So it now runs on macOS (see
images here [1]). I had to do a couple of changes, see line 33, 34, 35 and
also two simple patches at the end of:

https://github.com/aconchillo/homebrew-guile/blob/master/Formula/g-golf.rb

The changes are:

- We need the full path of glib, gobject, etc. They are not always in
/usr/lib. For example, guile-gcrypt solves this by specifying
--with-libgcrypt-prefix and we can point to /opt/homebrew/ for example.
That's what those inreplace lines do.

- The configure.ac patch fixes SITEDIR and SITECACHEDIR when
--with-guile-site=no. Btw, this is also the case for guile-lib (has the
same code). I believe the right paths should be:

SITEDIR="$datadir/guile/site/$GUILE_EFFECTIVE_VERSION";
SITECCACHEDIR="$libdir/guile/$GUILE_EFFECTIVE_VERSION/site-ccache";

- The Makefile.am patch places libg-golf in the Guile extensions directory
$(libdir)/guile/$(GUILE_EFFECTIVE_VERSION)/extensions, which I believe is
the right thing to do.

I hope this helps. If all this makes sense I can send patches.

Best,

Aleix

[1] https://emacs.ch/@aconchillo/109519735429741042

On Tue, Dec 13, 2022 at 12:37 PM David Pirotte  wrote:

> Hello Guilers,
>
> The first alpha release of the upcoming 0.8.0 release is now available
> for testing:
>
> Tarball and a GPG detached signature [*]:
>
> http://ftp.gnu.org/gnu/g-golf/g-golf-0.8.0-a.1.tar.gz
> http://ftp.gnu.org/gnu/g-golf/g-golf-0.8.0-a.1.tar.gz.sig
>
> Dependencies and complete installation instructions are given
> in the distributed INSTALL file, or here:
>
> https://www.gnu.org/software/g-golf/install.html
>
> You can help by:
>
>   1. Testing by installing from the tarball, or from the source if you
>   prefer, on the distro of your choice.
>
>   2. By running the distributed examples.
>
> Ultimately, one of the best way to test, and participate, is to select
> G-Golf to develop the next application of your dream! Here is an
> overview of the GNOME platform libraries [1], accessible using G-Golf.
> In particular, libadwaita [2] provides a number of widgets that change
> their layout based on the available space. This can be used to make
> applications adapt their UI between desktop and mobile devices.
>
> Contact [3]
>
> Before you email, or bug report, you could join us on irc, and ping
> me there: be patient, I also need to eat, sleep, rest ... but I always
> answer, and this my preferred way to quickly interact and fix potential
> G-Golf problem(s).
>
> On irc, we chat :), so please do not write code snipsets there unless 2
> or 3 lines of code, nor error messages of course - for more then 2 or 3
> lines of code, or error messages, always use a tor-friendly paste
> service (avoid those that tracks us an require javascript, thanks!)
>
> However, if you prefer:
>
> G-Golf uses Guile's mailing lists
> Report bugs to bug-g-g...@gnu.org
>
> Thanks!
> David
>
> [*] Use a .sig file to verify that the corresponding file (without the
> .sig suffix) is intact.  First, be sure to download both the .sig
> file and the corresponding tarball.  Then, run a command like this:
>
> gpg --verify g-golf-0.8.0-a.1.tar.gz
>
> If that command fails because you don't have the required public
> key, then run this command to import it:
>
> gpg --keyserver keys.gnupg.net --recv-keys A3057AD7
>
> and rerun the 'gpg --verify' command
>
>
> [1]
> https://developer.gnome.org/documentation/introduction/overview/libraries.html
> [2] https://gnome.pages.gitlab.gnome.org/libadwaita/doc/main/
> [3] https://www.gnu.org/software/g-golf/contact.html
>

Re: doc: fix documented keyword argument default to match code

[Aleix Conchillo Flaqué]

On Thu, Dec 15, 2022 at 9:46 AM Vijay Marupudi 
wrote:

> Hello guile-devel,
>
> Bumping this simple documentation bug fix to (ice-9 getopt-long).
>

LGTM.

Procedure is:

(define* (getopt-long program-arguments option-desc-list
  #:key stop-at-first-non-option)

And by default this means #f. So, it looks good.

Re: [PATCH] Fix minor typos

[Aleix Conchillo Flaqué]

On Thu, Dec 1, 2022 at 10:10 PM Colin Woodbury  wrote:

> `make html` should do it. The output is in doc/ref/guile.html/index.html
>
> Yup, that does it. For my future doc improvements I'll make sure to check
> both sides.
>
> So it seems that both the extra period and the superfluous "see" are
> perhaps bugs in Info itself. At least when you open the Guile Guide in
> Emacs, are you able to visually confirm what I'm seeing?
>
Yes, confirmed. I just tried your fix and it looks good both in info and
html.

LGTM if someone can commit this.

Aleix

Re: [PATCH] Fix minor typos

[Aleix Conchillo Flaqué]

On Wed, Nov 30, 2022 at 5:04 PM Colin Woodbury  wrote:

> Hi!
>
>
> On the website this looks OK:
>
> https://www.gnu.org/software/guile/manual/html_node/Vectors.html
>
> Did you try to generate the manual in HTML?
>
> Aleix
>
>
> I didn't (does `make info` do that?); I mainly consume the Guide within
> Emacs itself. Interesting also that the "see" bug doesn't appear in the web
> version either.
>

`make html` should do it. The output is in doc/ref/guile.html/index.html

Aleix

Re: [PATCH] Fix minor typos

[Aleix Conchillo Flaqué]

Hi!

On Wed, Nov 30, 2022 at 5:48 AM Colin Woodbury 
wrote:

> Hi all, this is my first patch to Guile. I have a few more planned, but
> figured I'd throw this in first to get my feet wet with the development
> process here.
>
> Detailed comments regarding the typo fixes are included in the patch's
> commit message.
>
> Cheers!
>


On the website this looks OK:

https://www.gnu.org/software/guile/manual/html_node/Vectors.html

Did you try to generate the manual in HTML?

Aleix

Re: [PATCH] fix Apple Silicon JIT compilation

[Aleix Conchillo Flaqué]

Apologies for re-sending this. Just realized this should be called Apple
Silicon and not just Apple M1.

On Thu, Nov 17, 2022 at 5:36 PM Aleix Conchillo Flaqué 
wrote:

> * configure.ac: check for pthread_jit_write_protect_np.
>
> * libguile/jit.c: add support for Apple Silicon JIT compilation.
>
> Fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44505
> ---
>  configure.ac   |  3 +++
>  libguile/jit.c | 25 -
>  2 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index b3879df1f..f8c12f0d7 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1187,6 +1187,9 @@ case "$with_threads" in
>pthread_get_stackaddr_np pthread_attr_get_np pthread_sigmask \
>pthread_cancel])
>
> +# Apple Silicon JIT code arena needs to be unprotected before writing.
> +AC_CHECK_FUNCS([pthread_jit_write_protect_np])
> +
>  # On past versions of Solaris, believe 8 through 10 at least, you
>  # had to write "pthread_once_t foo = { PTHREAD_ONCE_INIT };".
>  # This is contrary to POSIX:
> diff --git a/libguile/jit.c b/libguile/jit.c
> index 8420829b4..5cef8fae3 100644
> --- a/libguile/jit.c
> +++ b/libguile/jit.c
> @@ -47,6 +47,10 @@
>  #include 
>  #endif
>
> +#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
> +#include 
> +#endif
> +
>  #include "jit.h"
>
>
> @@ -1349,9 +1353,13 @@ allocate_code_arena (size_t size, struct code_arena
> *prev)
>ret->size = size;
>ret->prev = prev;
>  #ifndef __MINGW32__
> +  int flags = MAP_PRIVATE | MAP_ANONYMOUS;
> +#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
> +  flags |= MAP_JIT;
> +#endif
>ret->base = mmap (NULL, ret->size,
>  PROT_EXEC | PROT_READ | PROT_WRITE,
> -MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> +flags, -1, 0);
>if (ret->base == MAP_FAILED)
>  {
>perror ("allocating JIT code buffer failed");
> @@ -1406,11 +1414,21 @@ emit_code (scm_jit_state *j, void (*emit)
> (scm_jit_state *))
>
>uint8_t *ret = jit_address (j->jit);
>
> +#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
> +  pthread_jit_write_protect_np(0);
> +#endif
> +
>emit (j);
>
>size_t size;
>if (!jit_has_overflow (j->jit) && jit_end (j->jit, &size))
>  {
> +#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
> +  /* protect previous code arena. leave unprotected after emit()
> + since jit_end() also writes to code arena. */
> +  pthread_jit_write_protect_np(1);
> +  sys_icache_invalidate(arena->base, arena->size);
> +#endif
>ASSERT (size <= (arena->size - arena->used));
>DEBUG ("mcode: %p,+%zu\n", ret, size);
>arena->used += size;
> @@ -1424,6 +1442,11 @@ emit_code (scm_jit_state *j, void (*emit)
> (scm_jit_state *))
>  }
>else
>  {
> +#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
> +  /* protect previous code arena */
> +  pthread_jit_write_protect_np(1);
> +  sys_icache_invalidate(arena->base, arena->size);
> +#endif
>jit_reset (j->jit);
>if (arena->used == 0)
>  {
> --
> 2.37.1 (Apple Git-137.1)
>
>

[PATCH] fix Apple Silicon JIT compilation

[Aleix Conchillo Flaqué]

* configure.ac: check for pthread_jit_write_protect_np.

* libguile/jit.c: add support for Apple Silicon JIT compilation.

Fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44505
---
 configure.ac   |  3 +++
 libguile/jit.c | 25 -
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index b3879df1f..f8c12f0d7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1187,6 +1187,9 @@ case "$with_threads" in
   pthread_get_stackaddr_np pthread_attr_get_np pthread_sigmask \
   pthread_cancel])
 
+# Apple Silicon JIT code arena needs to be unprotected before writing.
+AC_CHECK_FUNCS([pthread_jit_write_protect_np])
+
 # On past versions of Solaris, believe 8 through 10 at least, you
 # had to write "pthread_once_t foo = { PTHREAD_ONCE_INIT };".
 # This is contrary to POSIX:
diff --git a/libguile/jit.c b/libguile/jit.c
index 8420829b4..5cef8fae3 100644
--- a/libguile/jit.c
+++ b/libguile/jit.c
@@ -47,6 +47,10 @@
 #include 
 #endif
 
+#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
+#include 
+#endif
+
 #include "jit.h"
 
 
@@ -1349,9 +1353,13 @@ allocate_code_arena (size_t size, struct code_arena 
*prev)
   ret->size = size;
   ret->prev = prev;
 #ifndef __MINGW32__
+  int flags = MAP_PRIVATE | MAP_ANONYMOUS;
+#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
+  flags |= MAP_JIT;
+#endif
   ret->base = mmap (NULL, ret->size,
 PROT_EXEC | PROT_READ | PROT_WRITE,
-MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+flags, -1, 0);
   if (ret->base == MAP_FAILED)
 {
   perror ("allocating JIT code buffer failed");
@@ -1406,11 +1414,21 @@ emit_code (scm_jit_state *j, void (*emit) 
(scm_jit_state *))
 
   uint8_t *ret = jit_address (j->jit);
 
+#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
+  pthread_jit_write_protect_np(0);
+#endif
+
   emit (j);
 
   size_t size;
   if (!jit_has_overflow (j->jit) && jit_end (j->jit, &size))
 {
+#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
+  /* protect previous code arena. leave unprotected after emit()
+ since jit_end() also writes to code arena. */
+  pthread_jit_write_protect_np(1);
+  sys_icache_invalidate(arena->base, arena->size);
+#endif
   ASSERT (size <= (arena->size - arena->used));
   DEBUG ("mcode: %p,+%zu\n", ret, size);
   arena->used += size;
@@ -1424,6 +1442,11 @@ emit_code (scm_jit_state *j, void (*emit) (scm_jit_state 
*))
 }
   else
 {
+#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
+  /* protect previous code arena */
+  pthread_jit_write_protect_np(1);
+  sys_icache_invalidate(arena->base, arena->size);
+#endif
   jit_reset (j->jit);
   if (arena->used == 0)
 {
-- 
2.37.1 (Apple Git-137.1)

Re: [PATCH] fix Apple's M1 JIT compilation

[Aleix Conchillo Flaqué]

Sorry, ignore first patch, did a minor update on the second one.



On Tue, Nov 15, 2022 at 4:01 PM Aleix Conchillo Flaqué 
wrote:

> * configure.ac: check for pthread_jit_write_protect_np.
>
> * libguile/jit.c: add support for Apple's M1 JIT compilation.
>
> Fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44505
> ---
>  configure.ac   |  3 +++
>  libguile/jit.c | 25 -
>  2 files changed, 27 insertions(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index b3879df1f..200e4682d 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1187,6 +1187,9 @@ case "$with_threads" in
>pthread_get_stackaddr_np pthread_attr_get_np pthread_sigmask \
>pthread_cancel])
>
> +# Apple's M1 JIT code arena needs to be unprotected before writing.
> +AC_CHECK_FUNCS([pthread_jit_write_protect_np])
> +
>  # On past versions of Solaris, believe 8 through 10 at least, you
>  # had to write "pthread_once_t foo = { PTHREAD_ONCE_INIT };".
>  # This is contrary to POSIX:
> diff --git a/libguile/jit.c b/libguile/jit.c
> index 8420829b4..b17460401 100644
> --- a/libguile/jit.c
> +++ b/libguile/jit.c
> @@ -47,6 +47,10 @@
>  #include 
>  #endif
>
> +#if defined __APPLE__
> +#include 
> +#endif
> +
>  #include "jit.h"
>
>
> @@ -1349,9 +1353,13 @@ allocate_code_arena (size_t size, struct code_arena
> *prev)
>ret->size = size;
>ret->prev = prev;
>  #ifndef __MINGW32__
> +  int flags = MAP_PRIVATE | MAP_ANONYMOUS;
> +#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
> +  flags |= MAP_JIT;
> +#endif
>ret->base = mmap (NULL, ret->size,
>  PROT_EXEC | PROT_READ | PROT_WRITE,
> -MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> +flags, -1, 0);
>if (ret->base == MAP_FAILED)
>  {
>perror ("allocating JIT code buffer failed");
> @@ -1406,11 +1414,21 @@ emit_code (scm_jit_state *j, void (*emit)
> (scm_jit_state *))
>
>uint8_t *ret = jit_address (j->jit);
>
> +#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
> +  pthread_jit_write_protect_np(0);
> +#endif
> +
>emit (j);
>
>size_t size;
>if (!jit_has_overflow (j->jit) && jit_end (j->jit, &size))
>  {
> +#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
> +  /* protect previous code arena. leave unprotected after emit()
> + since jit_end() also writes to code arena. */
> +  pthread_jit_write_protect_np(1);
> +  sys_icache_invalidate(arena->base, arena->size);
> +#endif
>ASSERT (size <= (arena->size - arena->used));
>DEBUG ("mcode: %p,+%zu\n", ret, size);
>arena->used += size;
> @@ -1424,6 +1442,11 @@ emit_code (scm_jit_state *j, void (*emit)
> (scm_jit_state *))
>  }
>else
>  {
> +#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
> +  /* protect previous code arena */
> +  pthread_jit_write_protect_np(1);
> +  sys_icache_invalidate(arena->base, arena->size);
> +#endif
>jit_reset (j->jit);
>if (arena->used == 0)
>  {
> --
> 2.37.1 (Apple Git-137.1)
>
>

[PATCH] fix Apple's M1 JIT compilation

[Aleix Conchillo Flaqué]

* configure.ac: check for pthread_jit_write_protect_np.

* libguile/jit.c: add support for Apple's M1 JIT compilation.

Fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44505
---
 configure.ac   |  3 +++
 libguile/jit.c | 25 -
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index b3879df1f..200e4682d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1187,6 +1187,9 @@ case "$with_threads" in
   pthread_get_stackaddr_np pthread_attr_get_np pthread_sigmask \
   pthread_cancel])
 
+# Apple's M1 JIT code arena needs to be unprotected before writing.
+AC_CHECK_FUNCS([pthread_jit_write_protect_np])
+
 # On past versions of Solaris, believe 8 through 10 at least, you
 # had to write "pthread_once_t foo = { PTHREAD_ONCE_INIT };".
 # This is contrary to POSIX:
diff --git a/libguile/jit.c b/libguile/jit.c
index 8420829b4..5cef8fae3 100644
--- a/libguile/jit.c
+++ b/libguile/jit.c
@@ -47,6 +47,10 @@
 #include 
 #endif
 
+#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
+#include 
+#endif
+
 #include "jit.h"
 
 
@@ -1349,9 +1353,13 @@ allocate_code_arena (size_t size, struct code_arena 
*prev)
   ret->size = size;
   ret->prev = prev;
 #ifndef __MINGW32__
+  int flags = MAP_PRIVATE | MAP_ANONYMOUS;
+#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
+  flags |= MAP_JIT;
+#endif
   ret->base = mmap (NULL, ret->size,
 PROT_EXEC | PROT_READ | PROT_WRITE,
-MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+flags, -1, 0);
   if (ret->base == MAP_FAILED)
 {
   perror ("allocating JIT code buffer failed");
@@ -1406,11 +1414,21 @@ emit_code (scm_jit_state *j, void (*emit) 
(scm_jit_state *))
 
   uint8_t *ret = jit_address (j->jit);
 
+#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
+  pthread_jit_write_protect_np(0);
+#endif
+
   emit (j);
 
   size_t size;
   if (!jit_has_overflow (j->jit) && jit_end (j->jit, &size))
 {
+#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
+  /* protect previous code arena. leave unprotected after emit()
+ since jit_end() also writes to code arena. */
+  pthread_jit_write_protect_np(1);
+  sys_icache_invalidate(arena->base, arena->size);
+#endif
   ASSERT (size <= (arena->size - arena->used));
   DEBUG ("mcode: %p,+%zu\n", ret, size);
   arena->used += size;
@@ -1424,6 +1442,11 @@ emit_code (scm_jit_state *j, void (*emit) (scm_jit_state 
*))
 }
   else
 {
+#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
+  /* protect previous code arena */
+  pthread_jit_write_protect_np(1);
+  sys_icache_invalidate(arena->base, arena->size);
+#endif
   jit_reset (j->jit);
   if (arena->used == 0)
 {
-- 
2.37.1 (Apple Git-137.1)

[PATCH] fix Apple's M1 JIT compilation

[Aleix Conchillo Flaqué]

* configure.ac: check for pthread_jit_write_protect_np.

* libguile/jit.c: add support for Apple's M1 JIT compilation.

Fixes https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44505
---
 configure.ac   |  3 +++
 libguile/jit.c | 25 -
 2 files changed, 27 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index b3879df1f..200e4682d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1187,6 +1187,9 @@ case "$with_threads" in
   pthread_get_stackaddr_np pthread_attr_get_np pthread_sigmask \
   pthread_cancel])
 
+# Apple's M1 JIT code arena needs to be unprotected before writing.
+AC_CHECK_FUNCS([pthread_jit_write_protect_np])
+
 # On past versions of Solaris, believe 8 through 10 at least, you
 # had to write "pthread_once_t foo = { PTHREAD_ONCE_INIT };".
 # This is contrary to POSIX:
diff --git a/libguile/jit.c b/libguile/jit.c
index 8420829b4..b17460401 100644
--- a/libguile/jit.c
+++ b/libguile/jit.c
@@ -47,6 +47,10 @@
 #include 
 #endif
 
+#if defined __APPLE__
+#include 
+#endif
+
 #include "jit.h"
 
 
@@ -1349,9 +1353,13 @@ allocate_code_arena (size_t size, struct code_arena 
*prev)
   ret->size = size;
   ret->prev = prev;
 #ifndef __MINGW32__
+  int flags = MAP_PRIVATE | MAP_ANONYMOUS;
+#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
+  flags |= MAP_JIT;
+#endif
   ret->base = mmap (NULL, ret->size,
 PROT_EXEC | PROT_READ | PROT_WRITE,
-MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+flags, -1, 0);
   if (ret->base == MAP_FAILED)
 {
   perror ("allocating JIT code buffer failed");
@@ -1406,11 +1414,21 @@ emit_code (scm_jit_state *j, void (*emit) 
(scm_jit_state *))
 
   uint8_t *ret = jit_address (j->jit);
 
+#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
+  pthread_jit_write_protect_np(0);
+#endif
+
   emit (j);
 
   size_t size;
   if (!jit_has_overflow (j->jit) && jit_end (j->jit, &size))
 {
+#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
+  /* protect previous code arena. leave unprotected after emit()
+ since jit_end() also writes to code arena. */
+  pthread_jit_write_protect_np(1);
+  sys_icache_invalidate(arena->base, arena->size);
+#endif
   ASSERT (size <= (arena->size - arena->used));
   DEBUG ("mcode: %p,+%zu\n", ret, size);
   arena->used += size;
@@ -1424,6 +1442,11 @@ emit_code (scm_jit_state *j, void (*emit) (scm_jit_state 
*))
 }
   else
 {
+#if defined __APPLE__ && HAVE_PTHREAD_JIT_WRITE_PROTECT_NP
+  /* protect previous code arena */
+  pthread_jit_write_protect_np(1);
+  sys_icache_invalidate(arena->base, arena->size);
+#endif
   jit_reset (j->jit);
   if (arena->used == 0)
 {
-- 
2.37.1 (Apple Git-137.1)

Re: expression and definition context in Scheme

[Aleix Conchillo Flaqué]

Just came here to say: Congratulations Linus! That was definitely the most
important part of your message :-).

Aleix

On Tue, Aug 30, 2022 at 3:48 AM Linus Björnstam <
linus.bjorns...@veryfast.biz> wrote:

> I am working on a patch to guile to add definitions to just about every
> body except for (begin ...) outside definition context.
>
> The patch is trivial, but I have to document it and a patch to r6rs that
> makes the r6rs cons work according to spec.
>
> I had a kid recently so it might take some time before I have any computer
> time, so if anyone has some time this is a really simple thing. You can
> find the first patch somewhere in this mailing list, it only changes the
> (begin ...)s in the derived forms in (ice-9 boot-9) to (let () ...). Then i
> was going to copy the cond and case from the r6rs appendix and add some
> error reporting.
>
> The most difficult part is documenting it :)
>
> Andy have the idea hos blessing, and will mean guile gets define in
> expression context in when, unless, cond, case, while, and do as well as in
> derived forms.
>
> --
>   Linus Björnstam
>
> On Sat, 27 Aug 2022, at 18:48, Damien Mattei wrote:
> > Hello,
> >
> > i'm facing sometimes recursively the problem to have definitions in
> > expression context, which i manage every time by adding an upper empty
> > (let () my definitions goes here )
> > the last case i was facing this probleme is defining a 'for macro:
> >
> > ;; scheme@(guile-user)> (for ({i <+ 0} {i < 5} {i <- {i + 1}}) (display
> > i) (newline))
> > ;; 0
> > ;; 1
> > ;; 2
> > ;; 3
> > ;; 4
> >
> >
> > (define-syntax for
> >
> >   (syntax-rules ()
> >
> > ((_ (init test incrmt) b1 ...)
> >
> >(let ()
> >init
> >(let loop ()
> >   (when test
> > b1 ...
> > incrmt
> > (loop)))
> >
> > this one fails in my Scheme+ code below:
> > (define (compute-carries n)
> >
> >   (for ( {k <+ 0}  {k <= n}  {k <- {k + 1}} )
> >
> >{ Ckp1 <+ (compute-Ck-plus1 k) }
> >(display-nl Ckp1)))
> >
> > because { Ckp1 <+ (compute-Ck-plus1 k) } expands in :
> > (define Ckp1 (compute-Ck-plus1 k))
> > and i get a compilation error:
> > ;;; Syntax error:
> > ;;; logic-syracuse+.scm:15:7: definition in expression context, where
> > definitions are not allowed, in form (define Ckp1 (compute-Ck-plus1 k))
> >
> > so i replace my 'for macro definition with:
> >
> > (define-syntax for
> >
> >   (syntax-rules ()
> >
> > ((_ (init test incrmt) b1 ...)
> >
> >(let ()
> >init
> >(let loop ()
> >   (when test
> > (let ()
> > b1 ...
> > incrmt
> > (loop
> >
> > and it works, but you will notice an abusive use of empty (let () ...)
> > in the code to avoid the restrictions of definitions not allowed in
> > expression context.
> >
> > My ideas is as it is so easy to cheat the compiler from seeing the
> > expressio context why does the compiler restrict this? expression and
> > defintion context, i'm not sure they are in scheme standarts, are they
> > really usefull?
> > why not remove this from Scheme at all?
> >
> > Regards,
> >
> > Damien
>
>

Re: avoid character encoding/escaping in sxml->xml or htmlprag's sxml->html

[Aleix Conchillo Flaqué]

Thank you Maxime,

On Sun, Aug 21, 2022 at 3:16 AM Maxime Devos  wrote:

> On 21-08-2022 02:05, Aleix Conchillo Flaqué wrote:
>
> According to the spec, embedding inline content in the  tag should
> conform to the language defined by the "type" attribute (defaults to
> javascript). So, I would expect you could put any string that conforms to
> JS.
>
> """
> When used to include dynamic scripts, the scripts may either be embedded
> inline or may be imported from an external file using the src attribute. If
> the language is not that described by "text/javascript", then the type
> attribute must be present, as described below. Whatever language is used,
> the contents of the script element must conform with the requirements of
> that language's specification
>
> I am proposing to use XHTML (which is XML), not HTML. HTML's special
> parsing quirks are irrelevant here.
>
> It does, browsers (at least Chrome) don't interpret that correctly, since
> it's not valid JavaScript.
>
> As <script> ...  is XML, the XML parser  (not the HTML parser,
> this is XHTML!) will decode the < inside the ..., the
> result _after decoding_ is valid JavaScript.  In XML, 

Re: avoid character encoding/escaping in sxml->xml or htmlprag's sxml->html

[Aleix Conchillo Flaqué]

Hi Maxime,

On Sat, Aug 20, 2022 at 2:48 PM Maxime Devos  wrote:
>
> The GuileScript looks nice, for interested readers, see <
https://github.com/aconchillo/guilescript>
>
> On 20-08-2022 21:59, Aleix Conchillo Flaqué wrote:
>
> However, I'm not able to find a way to avoid character encoding/escaping
and the generated code inside  will always have "&lt;", etc. And
<script> is a place where encodings can be avoided. This is true for both
Guile and guile-lib's (htmlprag), even though htmlprag's escapes less
characters (e.g. double quotes).
>
> One way I found to solve this was to have <script src="fib.js"> and then
have a handler for fib.js that would just return the transpiled string. But
it's not as nice, it's extra work and it's also an additional roundtrip to
the server.
>
> Has anyone ran into this issue? Would is make sense to add a keyword
argument to (sxml->xml)? For example, (sxml->xml SXML PORT #:escape #f).
>
> > Having unescaped < in <script>... does not seem valid XML to
me.
>

According to the spec, embedding inline content in the 

avoid character encoding/escaping in sxml->xml or htmlprag's sxml->html

[Aleix Conchillo Flaqué]

Hi there,

I have a GuileScript example that it's basically a web server written in
Guile that returns a basic HTML and also a 

Re: Maintenance and future of Guile

[Aleix Conchillo Flaqué]

I'm not sure how all this ended up.

But, I would encourage and love for Maxime Devos to be a Guile maintainer.
Always great feedback in Guile and other projects (like Fibers) and I
really feel Guile would benefit a lot from their contributions.

Just a thought.

Aleix

On Tue, Dec 21, 2021 at 6:27 AM Ludovic Courtès  wrote:

> Hi,
>
> Olivier Dion  skribis:
>
> > On Fri, 17 Dec 2021, Ludovic Courtès  wrote:
> >> Hi,
> >>
> >> Olivier Dion  skribis:
> >>
> >>> I would also like to contribute in some meaningful way.  In what way
> >>> someone with none wizard knowledge of Scheme can contribute the most
> to the
> >>> project?
> >>
> >> Triage of bugs and patches is always welcome I guess, and communicating
> >> what needs to be applied/addressed first to whoever can actually commit
> >> it.  That’s one possible way to help.
> >
> > Where can this be done?  I know that Guix is using debbugs, but do Guile
> > does the same or is it all tracked on Savannah?
>
> It’s happening on debbugs.gnu.org as well.  Debbugs this is easier to
> work with via Emacs debbugs.el, which is nice if you already use Emacs
> but otherwise unfortunate.
>
> > Also, any way to help on the C side?
>
> There isn’t much happening on the C side.  Maxime Devos submitted
> patches adding bindings for openat(2) and friends that are unfortunately
> still pending review.
>
> Patches that add POSIX bindings and similar to libguile should in
> general be relatively easy to review (though the openat(2) one may be
> trickier because it’s a central functionality and we’d rather get the
> interface right.)
>
> Thanks,
> Ludo’.
>
>

Re: (ice-9 base64)?

[Aleix Conchillo Flaqué]

On Thu, Aug 18, 2022 at 12:56 AM Maxime Devos 
wrote:

> Then, if I understood correctly, IMO I would say Guile should not really
> care about Guix's bundling/unbundling. That is, adding (ice-9 base64) (or
> however we want to call it... maybe (encoding base64) following Golang and
> Guile's (web ) module) should be totally independent of Guix. So, if we
> add (ice-9 base64) to Guile then Guix should figure out what to do with it,
> but it's Guix's concern not Guile's.
>
> It's not some Guix-specific quirk. It's the same for at least Debian. It
> benefits not only Guix itself but all users of the software:
>
Thanks, I understand the benefit now.

> [...] allows [...] to make transverse changes
> such as applying security updates for a given software package in a
> single place and have them affect the whole system—something that
> bundled copies prevent.
>
> ... that was written with Guix in mind, but it applies to every
> distribution and everyone.
>
> Besides, your goal appears to be to unbundle the base64 into a single
> location (as a module of Guile), if we do that I think we should go all the
> way -- just adding it to Guile increases bundling instead of decreasing
> bundling, only if the various upstreams are modified to unbundle and use
> the new location then the unbundling is completed.
>
I see... In my mind, initially, I was thinking the opposite. By adding it
to Guile, new projects will use the new base64 module and existing projects
will update whenever they want.

On 18-08-2022 02:09, Aleix Conchillo Flaqué wrote:
>
> About Guix's unbundling (maybe that's something that should go on Guix's
> mailing list),
>
> I don't see why, there's nothing to write about except "oops some packages
> are bundling base64, let's unbundle those", and for unbundling those, it
> seems more practical to write about that here on guile-devel. Also I
> noticed I sent some messages to guix-devel instead of guile-devel,
> correcting now.
>
> I don't think currently there's any unbundling for base64 modules or at
> least not in a package I maintain guile-jwt (guile-jwt bundles base64). And
> probably there's no unbundling because there's no canonical implementation?
> Even if there was a canonical implementation, how would that look like in
> Guix's guile-jwt package? What would the snippet actually do?
>
> Currently, it's not done yet, presumably for that reason and maybe also
> due to nobody having noticed it yet?
>
> How it would look like, for upstreams that refuse to unbundle or are
> unresponsive:
>
> #~(begin
> (delete-file "local/copy/of/base64.scm")
> [also remove it from the Makefile.am]
> (substitute* (find-files "." "\\.scm$")
>   (("(\\local base64 module\\)") "(gcrypt base64)")))
>
OK, I was imagining something like that. In this case do we assume (gcrypt
base64) is installed? Because some projects don't have a dependency on
guile-gcrypt.

> For responsive upstreams that do not mind these kind of improvements,
> there is a preference for submitting a patch upstream -- that way, everyone
> benefits, not only Guix.
>
So, what do you think would be the way to proceed in order to include a
base64 implementation in Guile itself?

For example:

1. Add (ice-9 base64) (or (encoding base64)) to Guile and let new projects
and existing projects to update with conditional module loading to support
old versions of Guile.
2. Do unbundling in Guix packages both for projects that have not updated
upstream and for projects in (1). The unbundling would be done by pointing
to Guix's (or guile-gcrypt) base64 implementation, or is there a way they
could point to Guile's implementation?

Does that make sense or am I still missing something (I'm about to catch a
cold so my brain is not working quite well this week)? Originally, I was
thinking only in (1).

Thanks!

Aleix

Re: (ice-9 base64)?

[Aleix Conchillo Flaqué]

On Tue, Aug 16, 2022 at 9:59 AM Maxime Devos  wrote:

>
> On 16-08-2022 18:10, Aleix Conchillo Flaqué 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? [...]
>
> If we do this, we should contact the various other projects to make them
> use (ice-9 base64).
>
>
I think they could switch whenever they want (i.e. whenever this was added
to Guile) or even not switch at all.


> I think it would be simpler though to consider the base64 in guile-gcrypt
> to be 'canonical', it would avoid problems with old versions of Guile not
> having the base64 module and newer version having it, which would prevent
> using the proposed (ice-9 base64) in Guile because it would break
> build-aux/build-self.scm when pulling or time-machining from old Guix that
> have an old Guile.
>
>
I've been waiting on a guile-gcrypt release for a while now (Ludo,
Chrisitine... any help here? :-) ).  I ported guile-jwt to use guile-gcrypt
but I need a release to have latest base64 changes:

https://notabug.org/cwebber/guile-gcrypt/commit/f8934ec94df5868ee8baf1fb0f8ed0f24e7e91eb

But you are right that this would cause a backward compatible problem, but
I guess that would depend on each project. Can we do conditional module
loading? I've done this in the past with Python... if we are in Python 2
load this module, otherwise load this other one. So projects could do that.

> Whether we simply replace (guix base64) by (gcrypt base64) depends on how
> old (gcrypt base64) is compared to the earliest 'supported' Guix for
> pull/time-travel, but even if it is not present in the old gcrypt, we can
> work-around that (we have a 'fake-gcrypt-hash' in build-aux/build-self.scm,
> so we can easily have a (define gcrypt-base64 [some copy])).  Or simply
> update the local guile-gcrypt in buid-aux/build-self.scm.
>
> guile-gcrypt base64 is pretty new with the patch above (but no release
after that), I have no idea if Guix has added anything else.


> OTOH a similar replacement can be done for (ice-9 base64), but
> transitioning to (ice-9 base64) would take much longer, at least until the
> various distributions are updated to a Guile that has (ice-9 base64),
> whereas (gcrypt base64) could be switched to immediately.
>
>
> Maybe this could be handled by each project independently.

Best,

Aleix

(ice-9 base64)?

[Aleix Conchillo Flaqué]

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: [PATCH] web: default to INADDR_ANY instead of INADDR_LOOPBACK

[Aleix Conchillo Flaqué]

On Fri, Jul 22, 2022 at 4:45 AM Greg Troxel  wrote:

>
> Aleix Conchillo Flaqué  writes:
>
> >> Using INADDR_ANY instead of INADDR_LOOPBACK makes it convenient when
> >> starting the web server inside containers without the need to having to
> >> specify INADDR_ANY all the time. This is the default in most libraries
> >> and languages.
>
> I may be an outlier, but I don't think we should optimize for
> containers.  I think that by default, most things that can reasonably
> just listen on localhost should and those that want wider scope can
> configure them (which should be easy and apparently is).
>
> It seems this was an earlier conscious choice, from reading the patched
> docs.
>
>
Agree about the container comment. As I said on the other email, I have no
idea why I wrote container there since I never run Guile in a container.

>> This doesn't break backwards compatibility since INADDR_LOOPBACK is also
> >> included in INADDR_ANY.
>
> It does break compat because the previous way had a security property
> that this one doesn't.  This is fundamentally a disagreement about what
> "works" means.  Some people think works primarily means "when I click X
> I see Y" and others thinks works primarily means "security properties
> (that nothing bad happens" are upheld".
>

Makes sense as well. Thank you for your input!

Best,

Aleix

Re: [PATCH] web: default to INADDR_ANY instead of INADDR_LOOPBACK

[Aleix Conchillo Flaqué]

Thank you Maxime,

On Fri, Jul 22, 2022 at 2:44 AM Maxime Devos  wrote:

> On 22-07-2022 02:44, Aleix Conchillo Flaqué wrote:
>
> ping. easy one but might be more controversial.
>
> On Wed, Feb 2, 2022 at 4:26 PM Aleix Conchillo Flaqué <
> aconchi...@gmail.com> wrote:
>
>> Using INADDR_ANY instead of INADDR_LOOPBACK makes it convenient when
>> starting the web server inside containers
>
> I don't see what containers have to do with anything? If you want it to
> access the Internet, just don't do a network container (don't create a new
> network namespace).  Or to reduce access, do create a new network namespace
> but set up port forwarding (which I would expect to work with loopback).
>

Now that I read it again, I have no clue what containers have to do with
this either, especially because I never run Guile in a container... So,
forget about the container reference.



> without the need to having to
>> specify INADDR_ANY all the time.
>>
> I don't recommend this as a default, as it opens up potential security
> problems (some programs open a web server for local communication on the
> computer). INADDR_LOOPBACK is a safe default, anyone needing something else
> and knowing their use is safe can easily override to INADDR_ANY.
>
> This is the default in most libraries and languages.
>
> Is ad populum. Plenty of bad choices have been made in the past, see e.g.
> all the CVEs, so I don't think this is a good argument.  (It is an argument
> if you are switching to INADDR_ANY for _consistency_, but the patch appears
> to be for other purposes.)
>
>
Makes sense. Thank you for the reply!

Best,

Aleix

Re: [PATCH] web: default to INADDR_ANY instead of INADDR_LOOPBACK

[Aleix Conchillo Flaqué]

ping. easy one but might be more controversial.

On Wed, Feb 2, 2022 at 4:26 PM Aleix Conchillo Flaqué 
wrote:

> Using INADDR_ANY instead of INADDR_LOOPBACK makes it convenient when
> starting the web server inside containers without the need to having to
> specify INADDR_ANY all the time. This is the default in most libraries
> and languages.
>
> This doesn't break backwards compatibility since INADDR_LOOPBACK is also
> included in INADDR_ANY.
>
> * doc/ref/web.texi (Web Server): update INADDR_LOOPBACK to INADDR_ANY
> and related text.
>
> * module/web/server/http.scm (http-open): default to INADDR_ANY for the
> web server.
> ---
>  doc/ref/web.texi   | 10 +-
>  module/web/server/http.scm |  4 ++--
>  2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/doc/ref/web.texi b/doc/ref/web.texi
> index 93cd0214f..6b42b8ff6 100644
> --- a/doc/ref/web.texi
> +++ b/doc/ref/web.texi
> @@ -1807,7 +1807,7 @@ socket, listening for request on that port.
>
>  @deffn {HTTP Implementation} http [#:host=#f] @
>   [#:family=AF_INET] @
> - [#:addr=INADDR_LOOPBACK] @
> + [#:addr=INADDR_ANY] @
>   [#:port 8080] [#:socket]
>  The default HTTP implementation.  We document it as a function with
>  keyword arguments, because that is precisely the way that it is -- all
> @@ -1815,7 +1815,7 @@ of the @var{open-params} to @code{run-server} get
> passed to the
>  implementation's open function.
>
>  @example
> -;; The defaults: localhost:8080
> +;; The defaults: any local IP on port 8080
>  (run-server handler)
>  ;; Same thing
>  (run-server handler 'http '())
> @@ -1866,9 +1866,9 @@ handler:
>  (run-server hello-world-handler)
>  @end example
>
> -By default, the web server listens for requests on
> -@code{localhost:8080}.  Visit that address in your web browser to
> -test.  If you see the string, @code{Hello World!}, sweet!
> +By default, the web server listens for requests on port @code{8080}.
> +Visit @code{http://localhost:8080} in your web browser to test.  If you
> +see the string, @code{Hello World!}, sweet!
>
>  @subsubsection Inspecting the Request
>
> diff --git a/module/web/server/http.scm b/module/web/server/http.scm
> index 05bf46bf0..91354021c 100644
> --- a/module/web/server/http.scm
> +++ b/module/web/server/http.scm
> @@ -1,6 +1,6 @@
>  ;;; Web I/O: HTTP
>
> -;; Copyright (C)  2010, 2011, 2012, 2015 Free Software Foundation, Inc.
> +;; Copyright (C)  2010, 2011, 2012, 2015, 2022 Free Software Foundation,
> Inc.
>
>  ;; This library is free software; you can redistribute it and/or
>  ;; modify it under the terms of the GNU Lesser General Public
> @@ -61,7 +61,7 @@
>  (family AF_INET)
>  (addr (if host
>(inet-pton family host)
> -  INADDR_LOOPBACK))
> +  INADDR_ANY))
>  (port 8080)
>  (socket (make-default-socket family addr port)))
>(listen socket 128)
> --
> 2.35.1
>
>

Re: [PATCH] doc: fix web (run-server) examples

[Aleix Conchillo Flaqué]

ping. this is an easy one :-).

On Wed, Feb 2, 2022 at 3:25 PM Aleix Conchillo Flaqué 
wrote:

> * doc/ref/web.texi (Web Server): need quasiquote to in order to evaluate
> AF_INET6.
> ---
>  doc/ref/web.texi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/doc/ref/web.texi b/doc/ref/web.texi
> index 93cd0214f..49a09d0ca 100644
> --- a/doc/ref/web.texi
> +++ b/doc/ref/web.texi
> @@ -1,6 +1,6 @@
>  @c -*-texinfo-*-
>  @c This is part of the GNU Guile Reference Manual.
> -@c Copyright (C) 2010, 2011, 2012, 2013, 2015, 2018, 2019, 2020 Free
> Software Foundation, Inc.
> +@c Copyright (C) 2010, 2011, 2012, 2013, 2015, 2018, 2019, 2020, 2022
> Free Software Foundation, Inc.
>  @c See the file guile.texi for copying conditions.
>
>  @node Web
> @@ -1822,7 +1822,7 @@ implementation's open function.
>  ;; On a different port
>  (run-server handler 'http '(#:port 8081))
>  ;; IPv6
> -(run-server handler 'http '(#:family AF_INET6 #:port 8081))
> +(run-server handler 'http `(#:family ,AF_INET6 #:port 8081))
>  ;; Custom socket
>  (run-server handler 'http `(#:socket ,(sudo-make-me-a-socket)))
>  @end example
> --
> 2.35.1
>
>

Re: [PATCH] web: send capitalized authorization header scheme

[Aleix Conchillo Flaqué]

On Fri, Jun 24, 2022 at 9:28 AM Maxime Devos  wrote:

> Aleix Conchillo Flaqué schreef op vr 24-06-2022 om 09:05 [-0700]:
> > * module/web/http.scm (write-credentials): capitalize authorization
> > header scheme. The standard allows the scheme to be case-insensitive,
> > however most libraries out there expect the scheme to be capitalized,
> > which is what it is actually used in RFC
> > docs (e.g. https://datatracker.ietf.org/doc/html/rfc7617#section-2).
> Some
> > libraries even reject lowercase scheme making Guile incompatible.
>
> This comment looks more useful to me to put in the source code, to help
> future readers of the source code, otherwise they would have to dig
> through the git history.  As mentioned previously, this could be
> something like:
>
>;; While according to RFC 7617 Schemes are case-insensitive:
>;;
>;; ‘Note that both scheme and parameter names are matched
>;; case-insensitive’
>;;
>;; some software (*) incorrectly assumes title case for scheme
>;; names, so use the more titlecase.
>;;
>;; (*): See, e.g.,
>;; <https://[bug report 1]/>
>;; <https://[bug report 2]/>
>
> which would also address the issue of not forgetting that Guile's old
> behaviour is correct, it's the other party that's not following the
> specification.
>
>
This makes sense. I left the comment in the commit log as well. Sent again.

Thank you!

Aleix

[PATCH] web: send capitalized authorization header scheme

[Aleix Conchillo Flaqué]

* module/web/http.scm (write-credentials): capitalize authorization
header scheme. The standard allows the scheme to be case-insensitive,
however most libraries out there expect the scheme to be capitalized,
which is what it is actually used in RFC
docs (e.g. https://datatracker.ietf.org/doc/html/rfc7617#section-2). Some
libraries even reject lowercase scheme making Guile incompatible.
---
 module/web/http.scm| 14 --
 test-suite/tests/web-http.test | 11 ---
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/module/web/http.scm b/module/web/http.scm
index 4276e1744..6af790384 100644
--- a/module/web/http.scm
+++ b/module/web/http.scm
@@ -962,13 +962,23 @@ as an ordered alist."
 (((? symbol?) . (? key-value-list?)) #t)
 (_ #f)))
 
+;; While according to RFC 7617 Schemes are case-insensitive:
+;;
+;; 'Note that both scheme and parameter names are matched
+;; case-insensitive'
+;;
+;; some software (*) incorrectly assumes title case for scheme
+;; names, so use the more titlecase.
+;;
+;; (*): See, e.g.,
+;; 
https://community.spotify.com/t5/Spotify-for-Developers/API-Authorization-header-doesn-t-follow-HTTP-spec/m-p/5397381#M4917
 (define (write-credentials val port)
   (match val
 (('basic . cred)
- (put-string port "basic ")
+ (put-string port "Basic ")
  (put-string port cred))
 ((scheme . params)
- (put-symbol port scheme)
+ (put-string port (string-titlecase (symbol->string scheme)))
  (put-char port #\space)
  (write-key-value-list params port
 
diff --git a/test-suite/tests/web-http.test b/test-suite/tests/web-http.test
index 63377349c..5c6a954b9 100644
--- a/test-suite/tests/web-http.test
+++ b/test-suite/tests/web-http.test
@@ -336,9 +336,14 @@
   (pass-if-parse authorization "Digest f" '(digest f))
   (pass-if-parse authorization "Digest foo=bar,baz=qux"
  '(digest (foo . "bar") (baz . "qux")))
-  (pass-if-round-trip "Authorization: basic f\r\n")
-  (pass-if-round-trip "Authorization: digest f\r\n")
-  (pass-if-round-trip "Authorization: digest foo=bar, baz=qux\r\n")
+  (pass-if-parse authorization "basic f" '(basic . "f"))
+  (pass-if-parse authorization "digest f" '(digest f))
+  (pass-if-parse authorization "digest foo=bar,baz=qux"
+ '(digest (foo . "bar") (baz . "qux")))
+  (pass-if-round-trip "Authorization: Basic f\r\n")
+  (pass-if-round-trip "Authorization: Bearer token\r\n")
+  (pass-if-round-trip "Authorization: Digest f\r\n")
+  (pass-if-round-trip "Authorization: Digest foo=bar, baz=qux\r\n")
   (pass-if-parse expect "100-continue, foo" '((100-continue) (foo)))
   (pass-if-parse from "foo@bar" "foo@bar")
   (pass-if-parse host "qux" '("qux" . #f))
-- 
2.34.1

[PATCH] web: send capitalized authorization header scheme

[Aleix Conchillo Flaqué]

* module/web/http.scm (write-credentials): capitalize authorization
header scheme. The standard allows the scheme to be case-insensitive,
however most libraries out there expect the scheme to be capitalized,
which is what it is actually used in RFC
docs (e.g. https://datatracker.ietf.org/doc/html/rfc7617#section-2). Some
libraries even reject lowercase scheme making Guile incompatible.
---
 module/web/http.scm|  4 ++--
 test-suite/tests/web-http.test | 11 ---
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/module/web/http.scm b/module/web/http.scm
index 4276e1744..312c28934 100644
--- a/module/web/http.scm
+++ b/module/web/http.scm
@@ -965,10 +965,10 @@ as an ordered alist."
 (define (write-credentials val port)
   (match val
 (('basic . cred)
- (put-string port "basic ")
+ (put-string port "Basic ")
  (put-string port cred))
 ((scheme . params)
- (put-symbol port scheme)
+ (put-string port (string-titlecase (symbol->string scheme)))
  (put-char port #\space)
  (write-key-value-list params port
 
diff --git a/test-suite/tests/web-http.test b/test-suite/tests/web-http.test
index 63377349c..5c6a954b9 100644
--- a/test-suite/tests/web-http.test
+++ b/test-suite/tests/web-http.test
@@ -336,9 +336,14 @@
   (pass-if-parse authorization "Digest f" '(digest f))
   (pass-if-parse authorization "Digest foo=bar,baz=qux"
  '(digest (foo . "bar") (baz . "qux")))
-  (pass-if-round-trip "Authorization: basic f\r\n")
-  (pass-if-round-trip "Authorization: digest f\r\n")
-  (pass-if-round-trip "Authorization: digest foo=bar, baz=qux\r\n")
+  (pass-if-parse authorization "basic f" '(basic . "f"))
+  (pass-if-parse authorization "digest f" '(digest f))
+  (pass-if-parse authorization "digest foo=bar,baz=qux"
+ '(digest (foo . "bar") (baz . "qux")))
+  (pass-if-round-trip "Authorization: Basic f\r\n")
+  (pass-if-round-trip "Authorization: Bearer token\r\n")
+  (pass-if-round-trip "Authorization: Digest f\r\n")
+  (pass-if-round-trip "Authorization: Digest foo=bar, baz=qux\r\n")
   (pass-if-parse expect "100-continue, foo" '((100-continue) (foo)))
   (pass-if-parse from "foo@bar" "foo@bar")
   (pass-if-parse host "qux" '("qux" . #f))
-- 
2.34.1

Re: [PATCH] web: authorization header scheme should be capitalized

[Aleix Conchillo Flaqué]

On Fri, Jun 24, 2022 at 1:35 AM Maxime Devos  wrote:

> Aleix Conchillo Flaqué schreef op do 23-06-2022 om 18:46 [-0700]:
> > Ah, got it. Yes, that would make sense.
> >
> > I was thinking about it again. I know that Guile complies with the
> > standard but since, I would say, capitalized schemes is what most
> > libraries use, would it make sense to switch to that? I don't really
> > expect big companies to fix this kind of stuff fast and in the
> > meantime we can't use Guile for certain things. I have to say I've
> > never seen lowercase Authorization header schemes.
>
> As long as we remember to _also_ report the bug in the buggy
> ‘consumers’ of the header (in this case, those big companies) and
> remember that lower-case isn't buggy, switching to the more
> conventional title-case seems sensible to me.
>
>
Great. I'll re-word the patch then and add your suggested additional tests.

Thank you!

Aleix

Re: [PATCH] web: authorization header scheme should be capitalized

[Aleix Conchillo Flaqué]

On Thu, Jun 23, 2022 at 3:20 PM Maxime Devos  wrote:

> Aleix Conchillo Flaqué schreef op do 23-06-2022 om 14:13 [-0700]:
> >
> https://community.spotify.com/t5/Spotify-for-Developers/API-Authorization-header-doesn-t-follow-HTTP-spec/m-p/5397381#M4917
> > > Also, there's still a potential patch to be had, e.g. you could add
> > > a test checking that Guile properly supports schemes in other cases
> > > (if not done already).
> >
> > What do you mean?
>
> Even if there is nothing that _has_ to be done in Guile, there's still
> thing that _can_ be done in Guile to improve Guile's test suite -- in
> this case, a test in the test suite that the Guile's web code
> understands both lowercase and uppercase and titlecase authorisation
> schemes.
>
>
Ah, got it. Yes, that would make sense.

I was thinking about it again. I know that Guile complies with the standard
but since, I would say, capitalized schemes is what most libraries use,
would it make sense to switch to that? I don't really expect big companies
to fix this kind of stuff fast and in the meantime we can't use Guile for
certain things. I have to say I've never seen lowercase Authorization
header schemes.

Best,

Aleix

Re: [PATCH] web: authorization header scheme should be capitalized

[Aleix Conchillo Flaqué]

On Thu, Jun 23, 2022 at 1:45 PM Maxime Devos  wrote:

> Aleix Conchillo Flaqué schreef op do 23-06-2022 om 13:42 [-0700]:
> >
> > [...]
> > I think you are right. The spec says clearly that it should be case
> > insensitive.
> >
> > So, disregard this patch.
>
> TBC, did you encounter problems in the wild that made you write the
> patch?
>
>
Yes, and I just posted it here:

https://community.spotify.com/t5/Spotify-for-Developers/API-Authorization-header-doesn-t-follow-HTTP-spec/m-p/5397381#M4917

> Also, there's still a potential patch to be had, e.g. you could add a
> test checking that Guile properly supports schemes in other cases (if
> not done already).
>
>
What do you mean?

Aleix

Re: [PATCH] web: authorization header scheme should be capitalized

[Aleix Conchillo Flaqué]

On Thu, Jun 23, 2022 at 1:40 PM Maxime Devos  wrote:

> Aleix Conchillo Flaqué schreef op do 23-06-2022 om 13:27 [-0700]:
> > + (put-string port (string-titlecase (symbol->string scheme)))
>
> I'd add a little explanation in a comment (e.g.:
>
>;; While according to RFC 7617 Schemes are case-insensitive:
>;;
>;; ‘Note that both scheme and parameter names are matched
>;; case-insensitive’
>;;
>;; some software (*) incorrectly assumes title case for scheme
>;; names, so use the more titlecase.
>;;
>;; (*): See, e.g.,
>;; <https://[bug report 1]/>
>;; <https://[bug report 2]/>
>
> I think it's reasonable to do some changes in Guile to work-around
> potential bugs in other software that Guile has no control over or even
> knows about, at the same time Guile seems to be just following the
> spec, the compatibility bug seems to be in the other software, so to
> help the other software a bit, I think it would be best to report
> things in the buggy software too.
>
>
>
I think you are right. The spec says clearly that it should be case
insensitive.

So, disregard this patch.

Aleix

Re: [PATCH] web: authorization header scheme should be capitalized

[Aleix Conchillo Flaqué]

Sorry, forgot to fix tests in my original email.

This is actually an important bug fix since some servers won't accept
lowercase Authorization header schemes and there's no way around this in
Guile, AFAIK.

Here are a few RFC where they explicitly mention capitalized strings:

"Basic" scheme: https://datatracker.ietf.org/doc/html/rfc7617#section-2
"Bearer" scheme: https://datatracker.ietf.org/doc/html/rfc6750#section-2.1

Aleix

On Thu, Jun 23, 2022 at 1:28 PM Aleix Conchillo Flaqué 
wrote:

> * module/web/http.scm (write-credentials): capitalize authorization
> header scheme. See, for example,
> https://datatracker.ietf.org/doc/html/rfc7617#section-2
> ---
>  module/web/http.scm| 4 ++--
>  test-suite/tests/web-http.test | 7 ---
>  2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/module/web/http.scm b/module/web/http.scm
> index 4276e1744..312c28934 100644
> --- a/module/web/http.scm
> +++ b/module/web/http.scm
> @@ -965,10 +965,10 @@ as an ordered alist."
>  (define (write-credentials val port)
>(match val
>  (('basic . cred)
> - (put-string port "basic ")
> + (put-string port "Basic ")
>   (put-string port cred))
>  ((scheme . params)
> - (put-symbol port scheme)
> + (put-string port (string-titlecase (symbol->string scheme)))
>   (put-char port #\space)
>   (write-key-value-list params port
>
> diff --git a/test-suite/tests/web-http.test
> b/test-suite/tests/web-http.test
> index 63377349c..df25030de 100644
> --- a/test-suite/tests/web-http.test
> +++ b/test-suite/tests/web-http.test
> @@ -336,9 +336,10 @@
>(pass-if-parse authorization "Digest f" '(digest f))
>(pass-if-parse authorization "Digest foo=bar,baz=qux"
>   '(digest (foo . "bar") (baz . "qux")))
> -  (pass-if-round-trip "Authorization: basic f\r\n")
> -  (pass-if-round-trip "Authorization: digest f\r\n")
> -  (pass-if-round-trip "Authorization: digest foo=bar, baz=qux\r\n")
> +  (pass-if-round-trip "Authorization: Basic f\r\n")
> +  (pass-if-round-trip "Authorization: Bearer token\r\n")
> +  (pass-if-round-trip "Authorization: Digest f\r\n")
> +  (pass-if-round-trip "Authorization: Digest foo=bar, baz=qux\r\n")
>(pass-if-parse expect "100-continue, foo" '((100-continue) (foo)))
>(pass-if-parse from "foo@bar" "foo@bar")
>(pass-if-parse host "qux" '("qux" . #f))
> --
> 2.34.1
>
>

[PATCH] web: authorization header scheme should be capitalized

[Aleix Conchillo Flaqué]

* module/web/http.scm (write-credentials): capitalize authorization
header scheme. See, for example,
https://datatracker.ietf.org/doc/html/rfc7617#section-2
---
 module/web/http.scm| 4 ++--
 test-suite/tests/web-http.test | 7 ---
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/module/web/http.scm b/module/web/http.scm
index 4276e1744..312c28934 100644
--- a/module/web/http.scm
+++ b/module/web/http.scm
@@ -965,10 +965,10 @@ as an ordered alist."
 (define (write-credentials val port)
   (match val
 (('basic . cred)
- (put-string port "basic ")
+ (put-string port "Basic ")
  (put-string port cred))
 ((scheme . params)
- (put-symbol port scheme)
+ (put-string port (string-titlecase (symbol->string scheme)))
  (put-char port #\space)
  (write-key-value-list params port
 
diff --git a/test-suite/tests/web-http.test b/test-suite/tests/web-http.test
index 63377349c..df25030de 100644
--- a/test-suite/tests/web-http.test
+++ b/test-suite/tests/web-http.test
@@ -336,9 +336,10 @@
   (pass-if-parse authorization "Digest f" '(digest f))
   (pass-if-parse authorization "Digest foo=bar,baz=qux"
  '(digest (foo . "bar") (baz . "qux")))
-  (pass-if-round-trip "Authorization: basic f\r\n")
-  (pass-if-round-trip "Authorization: digest f\r\n")
-  (pass-if-round-trip "Authorization: digest foo=bar, baz=qux\r\n")
+  (pass-if-round-trip "Authorization: Basic f\r\n")
+  (pass-if-round-trip "Authorization: Bearer token\r\n")
+  (pass-if-round-trip "Authorization: Digest f\r\n")
+  (pass-if-round-trip "Authorization: Digest foo=bar, baz=qux\r\n")
   (pass-if-parse expect "100-continue, foo" '((100-continue) (foo)))
   (pass-if-parse from "foo@bar" "foo@bar")
   (pass-if-parse host "qux" '("qux" . #f))
-- 
2.34.1

[PATCH] web: authorization header scheme should be capitalized

[Aleix Conchillo Flaqué]

* module/web/http.scm (write-credentials): capitalize authorization
header scheme. See, for example,
https://datatracker.ietf.org/doc/html/rfc7617#section-2
---
 module/web/http.scm | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/module/web/http.scm b/module/web/http.scm
index 4276e1744..312c28934 100644
--- a/module/web/http.scm
+++ b/module/web/http.scm
@@ -965,10 +965,10 @@ as an ordered alist."
 (define (write-credentials val port)
   (match val
 (('basic . cred)
- (put-string port "basic ")
+ (put-string port "Basic ")
  (put-string port cred))
 ((scheme . params)
- (put-symbol port scheme)
+ (put-string port (string-titlecase (symbol->string scheme)))
  (put-char port #\space)
  (write-key-value-list params port
 
-- 
2.34.1

Fibers 1.1.1 released

[Aleix Conchillo Flaqué]

Hi,

On behalf of the Fibers team, I am excited to announce Fibers 1.1.1.

Fibers is a lightweight concurrency facility for Guile that supports
non-blocking
input and output, millions of concurrent threads, and Concurrent
ML-inspired communication primitives. For more information, see the web
version of the manual at:

  https://github.com/wingo/fibers/wiki/Manual

This is a bug fix release that fixes an important bug that was causing
tasks waiting on a file descriptor to not be executed in certain cases.
Thank you Ludo for the fix!

The 1.1.1 tarball can be found here:


https://github.com/wingo/fibers/releases/download/v1.1.1/fibers-1.1.1.tar.gz

Its SHA256 sum is:

  597daf696260b5df1ec3ba771d66f4b8858112c1136250b07aaa8099c0c8b351  fibers
-1.1.1.tar.gz

* Changes since 1.1.0

- Always add file descriptors finalizer in (schedule-task-when-fd-active).
- Do not load 'epoll.so' during cross-compilation.
- Pass '--target' and '-L' to 'guild compile' when cross-compiling.
- Do not refer to 'epoll.so'-provided variables at expansion time.
- Install .go files to …/site-ccache, not …/ccache.

Happy Hacking!

Aleix

Re: [PATCH] Documentation typo fix

[Aleix Conchillo Flaqué]

On Wed, Feb 23, 2022 at 11:27 PM Arun Isaac 
wrote:

>
> Hi Vijay,
>
> Could you send this patch to bug-gu...@gnu.org? That way it gets
> registered in the bug tracker, and a maintainer can apply it when they
> are able to.
>
>
Does this apply to bug fixes or also changes?

Best,

Aleix

Re: GNU Guile 3.0.8 released

[Aleix Conchillo Flaqué]

On Fri, Feb 11, 2022 at 5:28 PM Greg Troxel  wrote:

>
> Aleix Conchillo Flaqué  writes:
>
> > On Fri, Feb 11, 2022 at 3:05 AM Maxime Devos 
> wrote:
> >
> >> Andy Wingo schreef op vr 11-02-2022 om 08:47 [+0100]:
> >> > We are delighted to announce GNU Guile release 3.0.8, the latest in
> the
> >> [...]
> >> > The Guile 3.0.8 release mixes maintenance and optimizations [...]
> >>
> >>
> > Am I the only one who has not received the announcement?
>
> I got the announcement but it was filed to spam because of a rule
> KAM_MAILSPLOIT (KAM ruleset for spamassassin), because there were two
> From: headers.  I have reported this ruleset false positive.
>
>
It didn't even get into GMail spam... Oh well.

> Andy: Perhaps resend, with only one From: header.
>

I'll ping him.

Thanks!

Aleix

Re: GNU Guile 3.0.8 released

[Aleix Conchillo Flaqué]

On Fri, Feb 11, 2022 at 3:05 AM Maxime Devos  wrote:

> Andy Wingo schreef op vr 11-02-2022 om 08:47 [+0100]:
> > We are delighted to announce GNU Guile release 3.0.8, the latest in the
> [...]
> > The Guile 3.0.8 release mixes maintenance and optimizations [...]
>
>
Am I the only one who has not received the announcement?

Aleix

[PATCH] web: default to INADDR_ANY instead of INADDR_LOOPBACK

[Aleix Conchillo Flaqué]

Using INADDR_ANY instead of INADDR_LOOPBACK makes it convenient when
starting the web server inside containers without the need to having to
specify INADDR_ANY all the time. This is the default in most libraries
and languages.

This doesn't break backwards compatibility since INADDR_LOOPBACK is also
included in INADDR_ANY.

* doc/ref/web.texi (Web Server): update INADDR_LOOPBACK to INADDR_ANY
and related text.

* module/web/server/http.scm (http-open): default to INADDR_ANY for the
web server.
---
 doc/ref/web.texi   | 10 +-
 module/web/server/http.scm |  4 ++--
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/doc/ref/web.texi b/doc/ref/web.texi
index 93cd0214f..6b42b8ff6 100644
--- a/doc/ref/web.texi
+++ b/doc/ref/web.texi
@@ -1807,7 +1807,7 @@ socket, listening for request on that port.
 
 @deffn {HTTP Implementation} http [#:host=#f] @
  [#:family=AF_INET] @
- [#:addr=INADDR_LOOPBACK] @
+ [#:addr=INADDR_ANY] @
  [#:port 8080] [#:socket]
 The default HTTP implementation.  We document it as a function with
 keyword arguments, because that is precisely the way that it is -- all
@@ -1815,7 +1815,7 @@ of the @var{open-params} to @code{run-server} get passed 
to the
 implementation's open function.
 
 @example
-;; The defaults: localhost:8080
+;; The defaults: any local IP on port 8080
 (run-server handler)
 ;; Same thing
 (run-server handler 'http '())
@@ -1866,9 +1866,9 @@ handler:
 (run-server hello-world-handler)
 @end example
 
-By default, the web server listens for requests on
-@code{localhost:8080}.  Visit that address in your web browser to
-test.  If you see the string, @code{Hello World!}, sweet!
+By default, the web server listens for requests on port @code{8080}.
+Visit @code{http://localhost:8080} in your web browser to test.  If you
+see the string, @code{Hello World!}, sweet!
 
 @subsubsection Inspecting the Request
 
diff --git a/module/web/server/http.scm b/module/web/server/http.scm
index 05bf46bf0..91354021c 100644
--- a/module/web/server/http.scm
+++ b/module/web/server/http.scm
@@ -1,6 +1,6 @@
 ;;; Web I/O: HTTP
 
-;; Copyright (C)  2010, 2011, 2012, 2015 Free Software Foundation, Inc.
+;; Copyright (C)  2010, 2011, 2012, 2015, 2022 Free Software Foundation, Inc.
 
 ;; This library is free software; you can redistribute it and/or
 ;; modify it under the terms of the GNU Lesser General Public
@@ -61,7 +61,7 @@
 (family AF_INET)
 (addr (if host
   (inet-pton family host)
-  INADDR_LOOPBACK))
+  INADDR_ANY))
 (port 8080)
 (socket (make-default-socket family addr port)))
   (listen socket 128)
-- 
2.35.1

[PATCH] doc: fix web (run-server) examples

[Aleix Conchillo Flaqué]

* doc/ref/web.texi (Web Server): need quasiquote to in order to evaluate
AF_INET6.
---
 doc/ref/web.texi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/ref/web.texi b/doc/ref/web.texi
index 93cd0214f..49a09d0ca 100644
--- a/doc/ref/web.texi
+++ b/doc/ref/web.texi
@@ -1,6 +1,6 @@
 @c -*-texinfo-*-
 @c This is part of the GNU Guile Reference Manual.
-@c Copyright (C) 2010, 2011, 2012, 2013, 2015, 2018, 2019, 2020 Free Software 
Foundation, Inc.
+@c Copyright (C) 2010, 2011, 2012, 2013, 2015, 2018, 2019, 2020, 2022 Free 
Software Foundation, Inc.
 @c See the file guile.texi for copying conditions.
 
 @node Web
@@ -1822,7 +1822,7 @@ implementation's open function.
 ;; On a different port
 (run-server handler 'http '(#:port 8081))
 ;; IPv6
-(run-server handler 'http '(#:family AF_INET6 #:port 8081))
+(run-server handler 'http `(#:family ,AF_INET6 #:port 8081))
 ;; Custom socket
 (run-server handler 'http `(#:socket ,(sudo-make-me-a-socket)))
 @end example
-- 
2.35.1

Re: crash on macOS with dlsym RTLD_LOCAL

[Aleix Conchillo Flaqué]

Alright. Problem found and fixed. The issue was the way libgcrypt was
linked in macOS 11.x.

See: https://dev.gnupg.org/T5610

A libgcrypt's libtool.m4 patch has been applied upstream. The patch
already existed in Homebrew's libtool, so I just provided it and they
have applied it to libgcrypt (and libgpg-error). In the meantime I
have sent patches to Homebrew's libgcrypt so macOS users can enjoy
guile-gcrypt :-).

Aleix

On Tue, Sep 14, 2021 at 10:06 AM Aleix Conchillo Flaqué
 wrote:
>
> I have posted a message to Apple's forums to see if there's any luck:
>
> https://developer.apple.com/forums/thread/689991
>
> Aleix
>
> On Sat, Sep 11, 2021 at 10:14 PM Aleix Conchillo Flaqué
>  wrote:
> >
> > I did a little bit more research. The combination that actually fails
> > is RTLD_LAZY | RTLD_GLOBAL (what guile uses). So, you can actually
> > use:
> >
> > - RTLD_LAZY | RTLD_GLOBAL
> > - RTLD_NOW | RTLD_GLOBAL
> > - RTLD_NOW | RTLD_LOCAL
> >
> > I found the source code of dyld
> >
> >https://opensource.apple.com/source/dyld/dyld-852.2/
> >
> > But I have no clue how to build this, I tried it but failed with
> > missing dependencies. In any case, I provided a patch so at least we
> > can use Guile on macOS.
> >
> > Best,
> >
> > Aleix
> >
> > On Sat, Sep 4, 2021 at 10:48 PM Aleix Conchillo Flaqué
> >  wrote:
> > >
> > > Hi,
> > >
> > > I'm trying to load guile-grcypt with guile 3.0.7 and after my previous
> > > fix 
> > > (https://git.savannah.gnu.org/cgit/guile.git/commit/?id=1f100a4f20c3a6e57922fb26fce212997e2a03cb)
> > > guile-gcrypt still does not load properly.
> > >
> > > TLDR; Using RTLD_LOCAL instead of RTLD_GLOBAL (default) causes issues on 
> > > macOS.
> > >
> > > https://git.savannah.gnu.org/cgit/guile.git/tree/module/system/foreign-library.scm#n181
> > >
> > > In the case of guile-gcrypt this is what I'm getting:
> > >
> > > -
> > > scheme@(guile-user)> (use-modules (gcrypt hmac))
> > > dyld: lazy symbol binding failed: Symbol not found: __gcry_check_version
> > >   Referenced from: /usr/local/lib/libgcrypt.dylib
> > >   Expected in: flat namespace
> > >
> > > dyld: Symbol not found: __gcry_check_version
> > >   Referenced from: /usr/local/lib/libgcrypt.dylib
> > >   Expected in: flat namespace
> > > -
> > >
> > > Looking at gcrypt symbols I can see:
> > >
> > > ❯ nm -gU /usr/local/lib/libgcrypt.dylib | grep gcry_check_version
> > > 5954 T __gcry_check_version
> > > 2aa7 T _gcry_check_version
> > >
> > > Actually in libgcrypt the public functions are: gcry_check_version and
> > > _gcry_check_version (no extra underscore). I think extra underscores
> > > are automatically added when building the library but I'm not sure why
> > > and when and what systems. And when you call dlsym() you don't need to
> > > add those extra underscores.
> > >
> > > The following code (which uses RTLD_GLOBAL) works fine:
> > >
> > > ./a.out gcry_check_version
> > >
> > > -
> > > #include 
> > > #include 
> > >
> > > int
> > > main(int argc, char *argv[])
> > > {
> > >   char* (*fptr)(char *);
> > >   void *handle = dlopen("/usr/local/lib/libgcrypt.dylib", RTLD_LAZY |
> > > RTLD_GLOBAL);
> > >   if (handle == NULL) {
> > > printf("OOOPS: %s\n", dlerror());
> > >   } else {
> > > *(void **)(&fptr) = dlsym(handle, argv[1]);
> > > if (fptr == NULL) {
> > >printf("NOT FOUND: %s : %s\n", argv[1], dlerror());
> > > } else {
> > >printf("FOUND: %s %s\n", argv[1], (*fptr)(NULL));
> > > }
> > >   }
> > >   return 0;
> > > }
> > > -
> > >
> > > But if we change to RTLD_LOCAL we get a crash like in guile's case.
> > >
> > > Sorry for being too vague but I'm not familiar with how all this
> > > works. All I know is that using RTLD_GLOBAL fixes the issue.
> > >
> > > Also, from dlopen man page I read:
> > >
> > > -
> > > RTLD_GLOBAL  Symbols exported from this image (dynamic library or
> > > bundle) will be available to any images build with -flat_namespace
> > > option to
> > >   ld(1) or to calls to dlsym() when using a special 
> > > handle.
> > >
> > >  RTLD_LOCAL   Symbols exported from this image (dynamic library or
> > > bundle) are generally hidden and only availble to dlsym() when
> > > directly using
> > >   the handle returned by this call to dlopen().
> > > -
> > >
> > > But I don't fully get what this means.
> > >
> > > Any help would be really appreciated.
> > >
> > > Thank you,
> > >
> > > Aleix

Re: [PATCH] foreign-library: fix RTLD_LAZY | RTLD_LOCAL crash on macOS

[Aleix Conchillo Flaqué]

Ignore. The issue was the way libgcrypt was linked in macOS.

See: https://dev.gnupg.org/T5610

A libgcrypt's libtool.m4 patch has been applied upstream.

On Sat, Sep 11, 2021 at 10:10 PM Aleix Conchillo Flaqué
 wrote:
>
> * module/system/foreign-library.scm (load-foreign-library): On macOS
> calling `dlopen` with RTLD_LAZY | RTLD_LOCAL causes a crash when calling
> `dlsym`. There are a three working combinations:
>
> - Using RTLD_NOW | RTLD_LOCAL
> - Using RTLD_NOW | RTLD_GLOBAL
> - Using RTLD_LAZY | RTLD_GLOBAL
>
> For efficiency purposes we choose RTLD_LAZY | RTLD_GLOBAL.
>
> See https://lists.gnu.org/archive/html/guile-devel/2021-09/msg8.html
> ---
>  module/system/foreign-library.scm | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/module/system/foreign-library.scm 
> b/module/system/foreign-library.scm
> index dc426385f..63889277c 100644
> --- a/module/system/foreign-library.scm
> +++ b/module/system/foreign-library.scm
> @@ -172,6 +172,11 @@ name."
>   (else
>name)
>
> +;; In macOS using dlopen with RTLD_LAZY | RTLD_LOCAL produces a crash.
> +;; https://lists.gnu.org/archive/html/guile-devel/2021-09/msg8.html
> +(define system-needs-global?
> +  (string-contains %host-type "-darwin"))
> +
>  (define* (load-foreign-library #:optional filename #:key
> (extensions system-library-extensions)
> (search-ltdl-library-path? #t)
> @@ -186,7 +191,7 @@ name."
> #f))
>(define flags
>  (logior (if lazy? RTLD_LAZY RTLD_NOW)
> -(if global? RTLD_GLOBAL RTLD_LOCAL)))
> +(if (or global? system-needs-global?) RTLD_GLOBAL RTLD_LOCAL)))
>(define (dlopen* name) (dlopen name flags))
>(if (and rename-on-cygwin? (string-contains %host-type "cygwin"))
>(set! filename (lib->cyg filename)))
> --
> 2.33.0
>

Re: crash on macOS with dlsym RTLD_LOCAL

[Aleix Conchillo Flaqué]

I have posted a message to Apple's forums to see if there's any luck:

https://developer.apple.com/forums/thread/689991

Aleix

On Sat, Sep 11, 2021 at 10:14 PM Aleix Conchillo Flaqué
 wrote:
>
> I did a little bit more research. The combination that actually fails
> is RTLD_LAZY | RTLD_GLOBAL (what guile uses). So, you can actually
> use:
>
> - RTLD_LAZY | RTLD_GLOBAL
> - RTLD_NOW | RTLD_GLOBAL
> - RTLD_NOW | RTLD_LOCAL
>
> I found the source code of dyld
>
>https://opensource.apple.com/source/dyld/dyld-852.2/
>
> But I have no clue how to build this, I tried it but failed with
> missing dependencies. In any case, I provided a patch so at least we
> can use Guile on macOS.
>
> Best,
>
> Aleix
>
> On Sat, Sep 4, 2021 at 10:48 PM Aleix Conchillo Flaqué
>  wrote:
> >
> > Hi,
> >
> > I'm trying to load guile-grcypt with guile 3.0.7 and after my previous
> > fix 
> > (https://git.savannah.gnu.org/cgit/guile.git/commit/?id=1f100a4f20c3a6e57922fb26fce212997e2a03cb)
> > guile-gcrypt still does not load properly.
> >
> > TLDR; Using RTLD_LOCAL instead of RTLD_GLOBAL (default) causes issues on 
> > macOS.
> >
> > https://git.savannah.gnu.org/cgit/guile.git/tree/module/system/foreign-library.scm#n181
> >
> > In the case of guile-gcrypt this is what I'm getting:
> >
> > -
> > scheme@(guile-user)> (use-modules (gcrypt hmac))
> > dyld: lazy symbol binding failed: Symbol not found: __gcry_check_version
> >   Referenced from: /usr/local/lib/libgcrypt.dylib
> >   Expected in: flat namespace
> >
> > dyld: Symbol not found: __gcry_check_version
> >   Referenced from: /usr/local/lib/libgcrypt.dylib
> >   Expected in: flat namespace
> > -
> >
> > Looking at gcrypt symbols I can see:
> >
> > ❯ nm -gU /usr/local/lib/libgcrypt.dylib | grep gcry_check_version
> > 5954 T __gcry_check_version
> > 2aa7 T _gcry_check_version
> >
> > Actually in libgcrypt the public functions are: gcry_check_version and
> > _gcry_check_version (no extra underscore). I think extra underscores
> > are automatically added when building the library but I'm not sure why
> > and when and what systems. And when you call dlsym() you don't need to
> > add those extra underscores.
> >
> > The following code (which uses RTLD_GLOBAL) works fine:
> >
> > ./a.out gcry_check_version
> >
> > -
> > #include 
> > #include 
> >
> > int
> > main(int argc, char *argv[])
> > {
> >   char* (*fptr)(char *);
> >   void *handle = dlopen("/usr/local/lib/libgcrypt.dylib", RTLD_LAZY |
> > RTLD_GLOBAL);
> >   if (handle == NULL) {
> > printf("OOOPS: %s\n", dlerror());
> >   } else {
> > *(void **)(&fptr) = dlsym(handle, argv[1]);
> > if (fptr == NULL) {
> >printf("NOT FOUND: %s : %s\n", argv[1], dlerror());
> > } else {
> >printf("FOUND: %s %s\n", argv[1], (*fptr)(NULL));
> > }
> >   }
> >   return 0;
> > }
> > -
> >
> > But if we change to RTLD_LOCAL we get a crash like in guile's case.
> >
> > Sorry for being too vague but I'm not familiar with how all this
> > works. All I know is that using RTLD_GLOBAL fixes the issue.
> >
> > Also, from dlopen man page I read:
> >
> > -
> > RTLD_GLOBAL  Symbols exported from this image (dynamic library or
> > bundle) will be available to any images build with -flat_namespace
> > option to
> >   ld(1) or to calls to dlsym() when using a special handle.
> >
> >  RTLD_LOCAL   Symbols exported from this image (dynamic library or
> > bundle) are generally hidden and only availble to dlsym() when
> > directly using
> >   the handle returned by this call to dlopen().
> > -
> >
> > But I don't fully get what this means.
> >
> > Any help would be really appreciated.
> >
> > Thank you,
> >
> > Aleix

Re: crash on macOS with dlsym RTLD_LOCAL

[Aleix Conchillo Flaqué]

I did a little bit more research. The combination that actually fails
is RTLD_LAZY | RTLD_GLOBAL (what guile uses). So, you can actually
use:

- RTLD_LAZY | RTLD_GLOBAL
- RTLD_NOW | RTLD_GLOBAL
- RTLD_NOW | RTLD_LOCAL

I found the source code of dyld

   https://opensource.apple.com/source/dyld/dyld-852.2/

But I have no clue how to build this, I tried it but failed with
missing dependencies. In any case, I provided a patch so at least we
can use Guile on macOS.

Best,

Aleix

On Sat, Sep 4, 2021 at 10:48 PM Aleix Conchillo Flaqué
 wrote:
>
> Hi,
>
> I'm trying to load guile-grcypt with guile 3.0.7 and after my previous
> fix 
> (https://git.savannah.gnu.org/cgit/guile.git/commit/?id=1f100a4f20c3a6e57922fb26fce212997e2a03cb)
> guile-gcrypt still does not load properly.
>
> TLDR; Using RTLD_LOCAL instead of RTLD_GLOBAL (default) causes issues on 
> macOS.
>
> https://git.savannah.gnu.org/cgit/guile.git/tree/module/system/foreign-library.scm#n181
>
> In the case of guile-gcrypt this is what I'm getting:
>
> -
> scheme@(guile-user)> (use-modules (gcrypt hmac))
> dyld: lazy symbol binding failed: Symbol not found: __gcry_check_version
>   Referenced from: /usr/local/lib/libgcrypt.dylib
>   Expected in: flat namespace
>
> dyld: Symbol not found: __gcry_check_version
>   Referenced from: /usr/local/lib/libgcrypt.dylib
>   Expected in: flat namespace
> -
>
> Looking at gcrypt symbols I can see:
>
> ❯ nm -gU /usr/local/lib/libgcrypt.dylib | grep gcry_check_version
> 5954 T __gcry_check_version
> 2aa7 T _gcry_check_version
>
> Actually in libgcrypt the public functions are: gcry_check_version and
> _gcry_check_version (no extra underscore). I think extra underscores
> are automatically added when building the library but I'm not sure why
> and when and what systems. And when you call dlsym() you don't need to
> add those extra underscores.
>
> The following code (which uses RTLD_GLOBAL) works fine:
>
> ./a.out gcry_check_version
>
> -
> #include 
> #include 
>
> int
> main(int argc, char *argv[])
> {
>   char* (*fptr)(char *);
>   void *handle = dlopen("/usr/local/lib/libgcrypt.dylib", RTLD_LAZY |
> RTLD_GLOBAL);
>   if (handle == NULL) {
> printf("OOOPS: %s\n", dlerror());
>   } else {
> *(void **)(&fptr) = dlsym(handle, argv[1]);
> if (fptr == NULL) {
>printf("NOT FOUND: %s : %s\n", argv[1], dlerror());
> } else {
>printf("FOUND: %s %s\n", argv[1], (*fptr)(NULL));
> }
>   }
>   return 0;
> }
> -
>
> But if we change to RTLD_LOCAL we get a crash like in guile's case.
>
> Sorry for being too vague but I'm not familiar with how all this
> works. All I know is that using RTLD_GLOBAL fixes the issue.
>
> Also, from dlopen man page I read:
>
> -
> RTLD_GLOBAL  Symbols exported from this image (dynamic library or
> bundle) will be available to any images build with -flat_namespace
> option to
>   ld(1) or to calls to dlsym() when using a special handle.
>
>  RTLD_LOCAL   Symbols exported from this image (dynamic library or
> bundle) are generally hidden and only availble to dlsym() when
> directly using
>   the handle returned by this call to dlopen().
> -
>
> But I don't fully get what this means.
>
> Any help would be really appreciated.
>
> Thank you,
>
> Aleix

[PATCH] foreign-library: fix RTLD_LAZY | RTLD_LOCAL crash on macOS

[Aleix Conchillo Flaqué]

* module/system/foreign-library.scm (load-foreign-library): On macOS
calling `dlopen` with RTLD_LAZY | RTLD_LOCAL causes a crash when calling
`dlsym`. There are a three working combinations:

- Using RTLD_NOW | RTLD_LOCAL
- Using RTLD_NOW | RTLD_GLOBAL
- Using RTLD_LAZY | RTLD_GLOBAL

For efficiency purposes we choose RTLD_LAZY | RTLD_GLOBAL.

See https://lists.gnu.org/archive/html/guile-devel/2021-09/msg8.html
---
 module/system/foreign-library.scm | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/module/system/foreign-library.scm 
b/module/system/foreign-library.scm
index dc426385f..63889277c 100644
--- a/module/system/foreign-library.scm
+++ b/module/system/foreign-library.scm
@@ -172,6 +172,11 @@ name."
  (else
   name)
 
+;; In macOS using dlopen with RTLD_LAZY | RTLD_LOCAL produces a crash.
+;; https://lists.gnu.org/archive/html/guile-devel/2021-09/msg8.html
+(define system-needs-global?
+  (string-contains %host-type "-darwin"))
+
 (define* (load-foreign-library #:optional filename #:key
(extensions system-library-extensions)
(search-ltdl-library-path? #t)
@@ -186,7 +191,7 @@ name."
#f))
   (define flags
 (logior (if lazy? RTLD_LAZY RTLD_NOW)
-(if global? RTLD_GLOBAL RTLD_LOCAL)))
+(if (or global? system-needs-global?) RTLD_GLOBAL RTLD_LOCAL)))
   (define (dlopen* name) (dlopen name flags))
   (if (and rename-on-cygwin? (string-contains %host-type "cygwin"))
   (set! filename (lib->cyg filename)))
-- 
2.33.0

crash on macOS with dlsym RTLD_LOCAL

[Aleix Conchillo Flaqué]

Hi,

I'm trying to load guile-grcypt with guile 3.0.7 and after my previous
fix 
(https://git.savannah.gnu.org/cgit/guile.git/commit/?id=1f100a4f20c3a6e57922fb26fce212997e2a03cb)
guile-gcrypt still does not load properly.

TLDR; Using RTLD_LOCAL instead of RTLD_GLOBAL (default) causes issues on macOS.

https://git.savannah.gnu.org/cgit/guile.git/tree/module/system/foreign-library.scm#n181

In the case of guile-gcrypt this is what I'm getting:

-
scheme@(guile-user)> (use-modules (gcrypt hmac))
dyld: lazy symbol binding failed: Symbol not found: __gcry_check_version
  Referenced from: /usr/local/lib/libgcrypt.dylib
  Expected in: flat namespace

dyld: Symbol not found: __gcry_check_version
  Referenced from: /usr/local/lib/libgcrypt.dylib
  Expected in: flat namespace
-

Looking at gcrypt symbols I can see:

❯ nm -gU /usr/local/lib/libgcrypt.dylib | grep gcry_check_version
5954 T __gcry_check_version
2aa7 T _gcry_check_version

Actually in libgcrypt the public functions are: gcry_check_version and
_gcry_check_version (no extra underscore). I think extra underscores
are automatically added when building the library but I'm not sure why
and when and what systems. And when you call dlsym() you don't need to
add those extra underscores.

The following code (which uses RTLD_GLOBAL) works fine:

./a.out gcry_check_version

-
#include 
#include 

int
main(int argc, char *argv[])
{
  char* (*fptr)(char *);
  void *handle = dlopen("/usr/local/lib/libgcrypt.dylib", RTLD_LAZY |
RTLD_GLOBAL);
  if (handle == NULL) {
printf("OOOPS: %s\n", dlerror());
  } else {
*(void **)(&fptr) = dlsym(handle, argv[1]);
if (fptr == NULL) {
   printf("NOT FOUND: %s : %s\n", argv[1], dlerror());
} else {
   printf("FOUND: %s %s\n", argv[1], (*fptr)(NULL));
}
  }
  return 0;
}
-

But if we change to RTLD_LOCAL we get a crash like in guile's case.

Sorry for being too vague but I'm not familiar with how all this
works. All I know is that using RTLD_GLOBAL fixes the issue.

Also, from dlopen man page I read:

-
RTLD_GLOBAL  Symbols exported from this image (dynamic library or
bundle) will be available to any images build with -flat_namespace
option to
  ld(1) or to calls to dlsym() when using a special handle.

 RTLD_LOCAL   Symbols exported from this image (dynamic library or
bundle) are generally hidden and only availble to dlsym() when
directly using
  the handle returned by this call to dlopen().
-

But I don't fully get what this means.

Any help would be really appreciated.

Thank you,

Aleix

Re: [PATCH] foreign-library: fix darwin detection

[Aleix Conchillo Flaqué]

And there are also more errors, for example in guile-gcrypt:

dyld: lazy symbol binding failed: Symbol not found: __gcry_check_version
  Referenced from: /usr/local/lib/libgcrypt.dylib
  Expected in: flat namespace

dyld: Symbol not found: __gcry_check_version
  Referenced from: /usr/local/lib/libgcrypt.dylib
  Expected in: flat namespace

This is because it's trying to find the symbol __gcry_check_version
but it doesn't take into account that in gcrypt symbols are prefixed
with an underscore.

I'm trying to understand why this is and how to fix it.

Aleix

On Wed, Sep 1, 2021 at 10:38 PM Aleix Conchillo Flaqué
 wrote:
>
> Without this change dynamic libraries in macOS are not loaded
> properly. This has happened since 3.0.6.
>
> scheme@(guile-user)> %host-type
> $1 = "x86_64-apple-darwin20.5.0"
>
> 
>
> scheme@(guile-user)> (use-modules (git))
> While compiling expression:
> In procedure git_libgit2_init: Function not implemented
>
> 
>
> scheme@(guile-user)> (use-modules (system foreign))
> scheme@(guile-user)> (dynamic-link "/usr/local/lib/libgit2")
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> In procedure load-foreign-library: file: "/usr/local/lib/libgit2",
> message: "file not found"
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> scheme@(guile-user) [1]>
>
> 
>
> After this fix:
>
> scheme@(guile-user)> (use-modules (system foreign))
> scheme@(guile-user)> (dynamic-link "/usr/local/lib/libgit2")
> $2 = #< filename: "/usr/local/lib/libgit2" handle:
> #>
>
> On Wed, Sep 1, 2021 at 10:28 PM Aleix Conchillo Flaqué
>  wrote:
> >
> > * module/system/foreign-library.scm (system-library-extensions): fix
> > darwin host detection. darwin host types have "-darwin" but not
> > "-darwin-".
> > ---
> >  module/system/foreign-library.scm | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/module/system/foreign-library.scm 
> > b/module/system/foreign-library.scm
> > index d53e293ef..dc426385f 100644
> > --- a/module/system/foreign-library.scm
> > +++ b/module/system/foreign-library.scm
> > @@ -48,7 +48,7 @@
> >
> >  (define system-library-extensions
> >(cond
> > -   ((string-contains %host-type "-darwin-")
> > +   ((string-contains %host-type "-darwin")
> >  '(".bundle" ".so" ".dylib"))
> > ((or (string-contains %host-type "cygwin")
> >  (string-contains %host-type "mingw")
> > --
> > 2.33.0
> >

Re: [PATCH] foreign-library: fix darwin detection

[Aleix Conchillo Flaqué]

Without this change dynamic libraries in macOS are not loaded
properly. This has happened since 3.0.6.

scheme@(guile-user)> %host-type
$1 = "x86_64-apple-darwin20.5.0"



scheme@(guile-user)> (use-modules (git))
While compiling expression:
In procedure git_libgit2_init: Function not implemented



scheme@(guile-user)> (use-modules (system foreign))
scheme@(guile-user)> (dynamic-link "/usr/local/lib/libgit2")
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure load-foreign-library: file: "/usr/local/lib/libgit2",
message: "file not found"

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]>



After this fix:

scheme@(guile-user)> (use-modules (system foreign))
scheme@(guile-user)> (dynamic-link "/usr/local/lib/libgit2")
$2 = #< filename: "/usr/local/lib/libgit2" handle:
#>

On Wed, Sep 1, 2021 at 10:28 PM Aleix Conchillo Flaqué
 wrote:
>
> * module/system/foreign-library.scm (system-library-extensions): fix
> darwin host detection. darwin host types have "-darwin" but not
> "-darwin-".
> ---
>  module/system/foreign-library.scm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/module/system/foreign-library.scm 
> b/module/system/foreign-library.scm
> index d53e293ef..dc426385f 100644
> --- a/module/system/foreign-library.scm
> +++ b/module/system/foreign-library.scm
> @@ -48,7 +48,7 @@
>
>  (define system-library-extensions
>(cond
> -   ((string-contains %host-type "-darwin-")
> +   ((string-contains %host-type "-darwin")
>  '(".bundle" ".so" ".dylib"))
> ((or (string-contains %host-type "cygwin")
>  (string-contains %host-type "mingw")
> --
> 2.33.0
>

[PATCH] foreign-library: fix darwin detection

[Aleix Conchillo Flaqué]

* module/system/foreign-library.scm (system-library-extensions): fix
darwin host detection. darwin host types have "-darwin" but not
"-darwin-".
---
 module/system/foreign-library.scm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/module/system/foreign-library.scm 
b/module/system/foreign-library.scm
index d53e293ef..dc426385f 100644
--- a/module/system/foreign-library.scm
+++ b/module/system/foreign-library.scm
@@ -48,7 +48,7 @@
 
 (define system-library-extensions
   (cond
-   ((string-contains %host-type "-darwin-")
+   ((string-contains %host-type "-darwin")
 '(".bundle" ".so" ".dylib"))
((or (string-contains %host-type "cygwin")
 (string-contains %host-type "mingw")
-- 
2.33.0

Re: [PATCH] srfi-64: fix double evaluation of test-name

[Aleix Conchillo Flaqué]

Thanks, I'll check it out!

On Sat, May 29, 2021, 1:55 PM  wrote:

> For srfi-64 you should really post your patches to srfi's mailing list
> since Guile uses the reference implementation. There was some discussion
> about switching to another one but it didn't happen. (Yet?)
>
> Some relevant links to upstream:
> https://github.com/scheme-requests-for-implementation/srfi-64/
> https://srfi.schemers.org/srfi-64/
>
>
>

Re: [PATCH] srfi-64: fix double evaluation of test-name

[Aleix Conchillo Flaqué]

ping!

On Fri, Apr 2, 2021, 12:21 AM Aleix Conchillo Flaqué 
wrote:

> * module/srfi/srfi-64/testing.scm: fix double test-name evaluation which
> also fix unused variable warnings as a bonus.
>
> Signed-off-by: Aleix Conchillo Flaqué 
> ---
>  module/srfi/srfi-64/testing.scm | 36 -
>  1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/module/srfi/srfi-64/testing.scm
> b/module/srfi/srfi-64/testing.scm
> index 37792cd0f..4237a5614 100644
> --- a/module/srfi/srfi-64/testing.scm
> +++ b/module/srfi/srfi-64/testing.scm
> @@ -707,9 +707,9 @@
>(syntax-case (list x (list (syntax quote) (%test-source-line2 x)))
> ()
> (((mac tname expr) line)
>  (syntax
> - (let* ((r (test-runner-get))
> -(name tname))
> -   (test-result-alist! r (cons (cons 'test-name tname) line))
> + (let* ((name tname)
> +(r (test-runner-get)))
> +   (test-result-alist! r (cons (cons 'test-name name) line))
> (%test-comp1body r expr
> (((mac expr) line)
>  (syntax
> @@ -720,9 +720,9 @@
>  (syntax-case (list x (list (syntax quote) (%test-source-line2 x))
> comp) ()
>(((mac tname expected expr) line comp)
> (syntax
> -   (let* ((r (test-runner-get))
> -  (name tname))
> - (test-result-alist! r (cons (cons 'test-name tname) line))
> +   (let* ((name tname)
> +  (r (test-runner-get)))
> + (test-result-alist! r (cons (cons 'test-name name) line))
>   (%test-comp2body r comp expected expr
>(((mac expected expr) line comp)
> (syntax
> @@ -740,9 +740,9 @@
>(syntax-case (list x (list (syntax quote) (%test-source-line2 x)))
> ()
>(((mac tname expected expr error) line)
> (syntax
> -   (let* ((r (test-runner-get))
> -  (name tname))
> - (test-result-alist! r (cons (cons 'test-name tname) line))
> +   (let* ((name tname)
> +  (r (test-runner-get)))
> + (test-result-alist! r (cons (cons 'test-name name) line))
>   (%test-comp2body r (%test-approximate= error) expected expr
>(((mac expected expr error) line)
> (syntax
> @@ -759,9 +759,9 @@
>(define-syntax test-assert
>  (syntax-rules ()
>((test-assert tname test-expression)
> -   (let* ((r (test-runner-get))
> - (name tname))
> -(test-result-alist! r '((test-name . tname)))
> +   (let* ((name tname)
> + (r (test-runner-get)))
> +(test-result-alist! r '((test-name . name)))
>  (%test-comp1body r test-expression)))
>((test-assert test-expression)
> (let* ((r (test-runner-get)))
> @@ -770,9 +770,9 @@
>(define-syntax %test-comp2
>  (syntax-rules ()
>((%test-comp2 comp tname expected expr)
> -   (let* ((r (test-runner-get))
> - (name tname))
> -(test-result-alist! r (list (cons 'test-name tname)))
> +   (let* ((name tname)
> + (r (test-runner-get)))
> +(test-result-alist! r (list (cons 'test-name name)))
>  (%test-comp2body r comp expected expr)))
>((%test-comp2 comp expected expr)
> (let* ((r (test-runner-get)))
> @@ -895,9 +895,9 @@
>(syntax-case (list x (list (syntax quote) (%test-source-line2 x)))
> ()
> (((mac tname etype expr) line)
>  (syntax
> - (let* ((r (test-runner-get))
> -(name tname))
> -   (test-result-alist! r (cons (cons 'test-name tname) line))
> + (let* ((name tname)
> +(r (test-runner-get)))
> +   (test-result-alist! r (cons (cons 'test-name name) line))
> (%test-error r etype expr
> (((mac etype expr) line)
>  (syntax
> --
> 2.31.1
>
>

Re: [PATCH] vectors: add (vector-last) support

[Aleix Conchillo Flaqué]

ping!

On Fri, Feb 12, 2021, 12:03 PM Aleix Conchillo Flaqué 
wrote:

> * libguile/vectors.c: add (vector-last) support.
>
> * libguile/vectors.h: define scm_vector_last and scm_c_vector_last.
>
> * doc/ref/api-data.texi (Vector Accessors): add documentation for
> (vector-last).
>
> Signed-off-by: Aleix Conchillo Flaqué 
> ---
>  doc/ref/api-data.texi | 10 ++
>  libguile/vectors.c| 30 +-
>  libguile/vectors.h|  6 --
>  test-suite/tests/srfi-43.test | 12 +++-
>  4 files changed, 54 insertions(+), 4 deletions(-)
>
> diff --git a/doc/ref/api-data.texi b/doc/ref/api-data.texi
> index 2ad13f5a5..0878c1173 100644
> --- a/doc/ref/api-data.texi
> +++ b/doc/ref/api-data.texi
> @@ -6354,6 +6354,16 @@ Return the contents of position @var{k} (a
> @code{size_t}) of
>  @var{vec}.
>  @end deftypefn
>
> +@rnindex vector-last
> +@deffn {Scheme Procedure} vector-last vec
> +@deffnx {C Function} scm_vector_last (vec)
> +Return the contents of the last element of @var{vec}.
> +@end deffn
> +
> +@deftypefn {C Function} SCM scm_c_vector_last (SCM vec)
> +Return the contents of the last element of @var{vec}.
> +@end deftypefn
> +
>  A vector created by one of the dynamic vector constructor procedures
>  (@pxref{Vector Creation}) can be modified using the following
>  procedures.
> diff --git a/libguile/vectors.c b/libguile/vectors.c
> index 0f1e6085e..f079f1f53 100644
> --- a/libguile/vectors.c
> +++ b/libguile/vectors.c
> @@ -193,7 +193,35 @@ scm_c_vector_ref (SCM v, size_t k)
>  }
>  #undef FUNC_NAME
>
> -SCM_DEFINE (scm_vector_set_x, "vector-set!", 3, 0, 0,
> +SCM_DEFINE (scm_vector_last, "vector-last", 1, 0, 0,
> +   (SCM vector),
> +"@samp{Vector-ref} returns the contents of the last element
> of\n"
> +"@var{vector}.\n\n"
> +"@lisp\n"
> +"(vector-ref '#(3 1 27 5)) @result{} 5\n"
> +"@end lisp")
> +#define FUNC_NAME s_scm_vector_last
> +{
> +  return scm_c_vector_last (vector);
> +}
> +#undef FUNC_NAME
> +
> +SCM
> +scm_c_vector_last (SCM v)
> +#define FUNC_NAME s_scm_vector_last
> +{
> +  SCM_VALIDATE_VECTOR (1, v);
> +
> +  size_t len = SCM_I_VECTOR_LENGTH (v);
> +
> +  if (len == 0)
> +scm_out_of_range (NULL, 0);
> +
> +  return scm_c_vector_ref (v, len - 1);
> +}
> +#undef FUNC_NAME
> +
> +SCM_DEFINE (scm_vector_set_x, "vector-set!", 3, 0, 0,
> (SCM vector, SCM k, SCM obj),
>  "@var{k} must be a valid index of @var{vector}.\n"
>  "@code{Vector-set!} stores @var{obj} in element @var{k} of
> @var{vector}.\n"
> diff --git a/libguile/vectors.h b/libguile/vectors.h
> index 41e2c8909..08fe19f49 100644
> --- a/libguile/vectors.h
> +++ b/libguile/vectors.h
> @@ -1,7 +1,7 @@
>  #ifndef SCM_VECTORS_H
>  #define SCM_VECTORS_H
>
> -/* Copyright 1995-1996,1998,2000-2002,2004-2006,2008-2009,2011,2014,2018
> +/* Copyright
> 1995-1996,1998,2000-2002,2004-2006,2008-2009,2011,2014,2018,2020
>   Free Software Foundation, Inc.
>
> This file is part of Guile.
> @@ -32,13 +32,14 @@ SCM_API SCM scm_vector_p (SCM x);
>  SCM_API SCM scm_vector_length (SCM v);
>  SCM_API SCM scm_vector (SCM l);
>  SCM_API SCM scm_vector_ref (SCM v, SCM k);
> +SCM_API SCM scm_vector_last (SCM v);
>  SCM_API SCM scm_vector_set_x (SCM v, SCM k, SCM obj);
>  SCM_API SCM scm_make_vector (SCM k, SCM fill);
>  SCM_API SCM scm_vector_to_list (SCM v);
>  SCM_API SCM scm_vector_fill_x (SCM v, SCM fill_x);
>  SCM_API SCM scm_vector_move_left_x (SCM vec1, SCM start1, SCM end1,
> SCM vec2, SCM start2);
> -SCM_API SCM scm_vector_move_right_x (SCM vec1, SCM start1, SCM end1,
> +SCM_API SCM scm_vector_move_right_x (SCM vec1, SCM start1, SCM end1,
>  SCM vec2, SCM start2);
>  SCM_API SCM scm_vector_copy (SCM vec);
>
> @@ -47,6 +48,7 @@ SCM_API int scm_is_simple_vector (SCM obj);
>  SCM_API SCM scm_c_make_vector (size_t len, SCM fill);
>  SCM_API size_t scm_c_vector_length (SCM vec);
>  SCM_API SCM scm_c_vector_ref (SCM vec, size_t k);
> +SCM_API SCM scm_c_vector_last (SCM vec);
>  SCM_API void scm_c_vector_set_x (SCM vec, size_t k, SCM obj);
>  SCM_API const SCM *scm_vector_elements (SCM vec,
> scm_t_array_handle *h,
> diff --git a/test-suite/tests/srfi-43.test b/test-suite/tests/srfi-43.test
> index 554843e75..4d0093974 100644
> --- a/test-suite/tests/srfi-43.test
> +++ b/test-suite/tests/srfi-43.test
> @@ -

Re: Unable to build Guile on macOS

[Aleix Conchillo Flaqué]

On Thu, Apr 8, 2021 at 1:10 PM lloda  wrote:
>
>
>
> > On 8 Apr 2021, at 06:43, Aleix Conchillo Flaqué  
> > wrote:
> >
> > The following recent Gnulib commit fixes the issue:
> >
> > https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=fc6d7d850bdebfed81e9212910f44edf99dd7743
> >
> > If someone could update Gnulib to a more recent version I'd really
> > appreciate it.
> >
> > Thanks!
> >
> > Aleix
>
> I pushed an update to branch wip-gnulib-update. Could you give that a try? I 
> tested on macos 10.15.7 and I had two test failures, in async.test and 
> filesys.test, but I'm not sure those didn't happen before.  (Everything was 
> fine on Debian).
>

It builds fine now on macOS 11.2.3. I'm getting 2 errors as well (I
don't see async.test though):

FAIL: 00-socket.test: setsockopt AF_INET: IPPROTO_TCP TCP_NODELAY
FAIL: filesys.test: mkdtemp: invalid template


Totals for this test run:
passes: 44240
failures:   2
unexpected passes:  0
expected failures:  24
unresolved test cases:  70
untested test cases:1
unsupported test cases: 1
errors: 0

FAIL: check-guile
==
1 of 1 test failed
Please report to bug-gu...@gnu.org
==

Re: Unable to build Guile on macOS

[Aleix Conchillo Flaqué]

The following recent Gnulib commit fixes the issue:

https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=fc6d7d850bdebfed81e9212910f44edf99dd7743

If someone could update Gnulib to a more recent version I'd really
appreciate it.

Thanks!

Aleix

On Wed, Mar 31, 2021 at 11:25 PM Aleix Conchillo Flaqué
 wrote:
>
> Hi there,
>
> After this Gnlib update, I am no longer able to build Guile on macOS:
>
> commit a91b95cca2d397c84f8b9bbd602d40209a7092ce
>
> There are other softwares with the same issue:
> https://www.mail-archive.com/bug-wget@gnu.org/msg09941.html
>
> I haven't had time to see if the issue is fixed already or not.
>
> This is the error I'm getting:
>
>   CC   time_rz.lo
>   CC   timegm.lo
>   CC   malloc/dynarray_at_failure.lo
> In file included from regex.c:74:
> In file included from ./regexec.c:1362:
> ./malloc/dynarray-skeleton.c:195:13: error: expected identifier or '('
> __nonnull ((1))
> ^
> ./malloc/dynarray-skeleton.c:195:13: error: expected ')'
> ./malloc/dynarray-skeleton.c:195:12: note: to match this '('
> __nonnull ((1))
>^
> ./malloc/dynarray-skeleton.c:205:40: error: expected identifier or '('
> __attribute_maybe_unused__ __nonnull ((1))
>^
> ./malloc/dynarray-skeleton.c:205:40: error: expected ')'
> ./malloc/dynarray-skeleton.c:205:39: note: to match this '('
> __attribute_maybe_unused__ __nonnull ((1))
>   ^

[PATCH] srfi-64: fix double evaluation of test-name

[Aleix Conchillo Flaqué]

* module/srfi/srfi-64/testing.scm: fix double test-name evaluation which
also fix unused variable warnings as a bonus.

Signed-off-by: Aleix Conchillo Flaqué 
---
 module/srfi/srfi-64/testing.scm | 36 -
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/module/srfi/srfi-64/testing.scm b/module/srfi/srfi-64/testing.scm
index 37792cd0f..4237a5614 100644
--- a/module/srfi/srfi-64/testing.scm
+++ b/module/srfi/srfi-64/testing.scm
@@ -707,9 +707,9 @@
   (syntax-case (list x (list (syntax quote) (%test-source-line2 x))) ()
(((mac tname expr) line)
 (syntax
- (let* ((r (test-runner-get))
-(name tname))
-   (test-result-alist! r (cons (cons 'test-name tname) line))
+ (let* ((name tname)
+(r (test-runner-get)))
+   (test-result-alist! r (cons (cons 'test-name name) line))
(%test-comp1body r expr
(((mac expr) line)
 (syntax
@@ -720,9 +720,9 @@
 (syntax-case (list x (list (syntax quote) (%test-source-line2 x)) comp) ()
   (((mac tname expected expr) line comp)
(syntax
-   (let* ((r (test-runner-get))
-  (name tname))
- (test-result-alist! r (cons (cons 'test-name tname) line))
+   (let* ((name tname)
+  (r (test-runner-get)))
+ (test-result-alist! r (cons (cons 'test-name name) line))
  (%test-comp2body r comp expected expr
   (((mac expected expr) line comp)
(syntax
@@ -740,9 +740,9 @@
   (syntax-case (list x (list (syntax quote) (%test-source-line2 x))) ()
   (((mac tname expected expr error) line)
(syntax
-   (let* ((r (test-runner-get))
-  (name tname))
- (test-result-alist! r (cons (cons 'test-name tname) line))
+   (let* ((name tname)
+  (r (test-runner-get)))
+ (test-result-alist! r (cons (cons 'test-name name) line))
  (%test-comp2body r (%test-approximate= error) expected expr
   (((mac expected expr error) line)
(syntax
@@ -759,9 +759,9 @@
   (define-syntax test-assert
 (syntax-rules ()
   ((test-assert tname test-expression)
-   (let* ((r (test-runner-get))
- (name tname))
-(test-result-alist! r '((test-name . tname)))
+   (let* ((name tname)
+ (r (test-runner-get)))
+(test-result-alist! r '((test-name . name)))
 (%test-comp1body r test-expression)))
   ((test-assert test-expression)
(let* ((r (test-runner-get)))
@@ -770,9 +770,9 @@
   (define-syntax %test-comp2
 (syntax-rules ()
   ((%test-comp2 comp tname expected expr)
-   (let* ((r (test-runner-get))
- (name tname))
-(test-result-alist! r (list (cons 'test-name tname)))
+   (let* ((name tname)
+ (r (test-runner-get)))
+(test-result-alist! r (list (cons 'test-name name)))
 (%test-comp2body r comp expected expr)))
   ((%test-comp2 comp expected expr)
(let* ((r (test-runner-get)))
@@ -895,9 +895,9 @@
   (syntax-case (list x (list (syntax quote) (%test-source-line2 x))) ()
(((mac tname etype expr) line)
 (syntax
- (let* ((r (test-runner-get))
-(name tname))
-   (test-result-alist! r (cons (cons 'test-name tname) line))
+ (let* ((name tname)
+(r (test-runner-get)))
+   (test-result-alist! r (cons (cons 'test-name name) line))
(%test-error r etype expr
(((mac etype expr) line)
 (syntax
-- 
2.31.1

[PATCH] srfi-64: fix double evaluation of test-name

[Aleix Conchillo Flaqué]

Sorry about the extra noise. The original patch used spaces on the new
lines while testing.scm uses tabs.

Best,

Aleix

Re: [PATCH] srfi-64: fix unused variable warnings

[Aleix Conchillo Flaqué]

Hi Maxime,

Thank you for your comments!

On Thu, Apr 1, 2021 at 4:37 AM Maxime Devos  wrote:

> For example, in:
>
> >  (define (%test-comp2 comp x)
> >  (syntax-case (list x (list (syntax quote) (%test-source-line2 x)) 
> > comp) ()
> >(((mac tname expected expr) line comp)
> > (syntax
> > - (let* ((r (test-runner-get))
> > -(name tname))
> > + (let ((r (test-runner-get)))
> > (test-result-alist! r (cons (cons 'test-name tname) line))
> > (%test-comp2body r comp expected expr
>
> I would keep the let* (but reverse the binding order), but change 'tname'
> with 'name' in the call to 'test-result-alist!', such that 'test-X' macros
> behave somewhat more like procedure calls (except for installing exeption
> handlers and having access to the s-expression of the code that will be run,
> of course).  It's largely a matter of taste, though.
>

I've done this change. One thing I don't understand is the "reverse
the binding order", I've done it as suggested but is this change the
one you refer to as "matter of taste"?

> In any case, it is good that 'tname' is now evaluated only once, as per
> SRFI-64 (notice ***It is evaluated only once.*** (markup mine)):
>
>  (test-assert [test-name] expression)
>
>  This evaluates the expression. The test passes if the result is true;
>  if the result is false, a test failure is reported. The test also fails
>  if an exception is raised, assuming the implementation has a way to catch
>  exceptions. How the failure is reported depends on the test runner 
> environment.
>  The test-name is a string that names the test case. (Though the test-name is
>  a string literal in the examples, it is an expression. ***It is evaluated 
> only once.***)
>  It is used when reporting errors, and also when skipping tests, as described 
> below.
>  It is an error to invoke test-assert if there is no current test runner.
>
> (My suggestion would be to also evaluate 'test-name' at least once, even if 
> there
> is no test runner, which seems a bit stricter than SRFI-64 demands, but seems 
> like
> a nice property to have and easy to achieve.)
>

Yes, this makes sense. Thanks again for pointing that out.

> As this patch does not ‘merely’ fix a warnings, but fixes a bug, could you 
> change
> the patch message accordingly?  Something like
>
>   srfi-64: fix double evaluation of test-name.
>
> perhaps?
>

Sounds good to me.

Best,

Aleix

[PATCH] srfi-64: fix double evaluation of test-name

[Aleix Conchillo Flaqué]

* module/srfi/srfi-64/testing.scm: fix double test-name evaluation which
also fix unused variable warnings as a bonus.

Signed-off-by: Aleix Conchillo Flaqué 
---
 module/srfi/srfi-64/testing.scm | 36 -
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/module/srfi/srfi-64/testing.scm b/module/srfi/srfi-64/testing.scm
index 37792cd0f..6a257323d 100644
--- a/module/srfi/srfi-64/testing.scm
+++ b/module/srfi/srfi-64/testing.scm
@@ -707,9 +707,9 @@
   (syntax-case (list x (list (syntax quote) (%test-source-line2 x))) ()
(((mac tname expr) line)
 (syntax
- (let* ((r (test-runner-get))
-(name tname))
-   (test-result-alist! r (cons (cons 'test-name tname) line))
+ (let* ((name tname)
+ (r (test-runner-get)))
+   (test-result-alist! r (cons (cons 'test-name name) line))
(%test-comp1body r expr
(((mac expr) line)
 (syntax
@@ -720,9 +720,9 @@
 (syntax-case (list x (list (syntax quote) (%test-source-line2 x)) comp) ()
   (((mac tname expected expr) line comp)
(syntax
-   (let* ((r (test-runner-get))
-  (name tname))
- (test-result-alist! r (cons (cons 'test-name tname) line))
+   (let* ((name tname)
+   (r (test-runner-get)))
+ (test-result-alist! r (cons (cons 'test-name name) line))
  (%test-comp2body r comp expected expr
   (((mac expected expr) line comp)
(syntax
@@ -740,9 +740,9 @@
   (syntax-case (list x (list (syntax quote) (%test-source-line2 x))) ()
   (((mac tname expected expr error) line)
(syntax
-   (let* ((r (test-runner-get))
-  (name tname))
- (test-result-alist! r (cons (cons 'test-name tname) line))
+   (let* ((name tname)
+   (r (test-runner-get)))
+ (test-result-alist! r (cons (cons 'test-name name) line))
  (%test-comp2body r (%test-approximate= error) expected expr
   (((mac expected expr error) line)
(syntax
@@ -759,9 +759,9 @@
   (define-syntax test-assert
 (syntax-rules ()
   ((test-assert tname test-expression)
-   (let* ((r (test-runner-get))
- (name tname))
-(test-result-alist! r '((test-name . tname)))
+   (let* ((name tname)
+  (r (test-runner-get)))
+(test-result-alist! r '((test-name . name)))
 (%test-comp1body r test-expression)))
   ((test-assert test-expression)
(let* ((r (test-runner-get)))
@@ -770,9 +770,9 @@
   (define-syntax %test-comp2
 (syntax-rules ()
   ((%test-comp2 comp tname expected expr)
-   (let* ((r (test-runner-get))
- (name tname))
-(test-result-alist! r (list (cons 'test-name tname)))
+   (let* ((name tname)
+  (r (test-runner-get)))
+(test-result-alist! r (list (cons 'test-name name)))
 (%test-comp2body r comp expected expr)))
   ((%test-comp2 comp expected expr)
(let* ((r (test-runner-get)))
@@ -895,9 +895,9 @@
   (syntax-case (list x (list (syntax quote) (%test-source-line2 x))) ()
(((mac tname etype expr) line)
 (syntax
- (let* ((r (test-runner-get))
-(name tname))
-   (test-result-alist! r (cons (cons 'test-name tname) line))
+ (let* ((name tname)
+ (r (test-runner-get)))
+   (test-result-alist! r (cons (cons 'test-name name) line))
(%test-error r etype expr
(((mac etype expr) line)
 (syntax
-- 
2.31.1

Unable to build Guile on macOS

[Aleix Conchillo Flaqué]

Hi there,

After this Gnlib update, I am no longer able to build Guile on macOS:

commit a91b95cca2d397c84f8b9bbd602d40209a7092ce

There are other softwares with the same issue:
https://www.mail-archive.com/bug-wget@gnu.org/msg09941.html

I haven't had time to see if the issue is fixed already or not.

This is the error I'm getting:

  CC   time_rz.lo
  CC   timegm.lo
  CC   malloc/dynarray_at_failure.lo
In file included from regex.c:74:
In file included from ./regexec.c:1362:
./malloc/dynarray-skeleton.c:195:13: error: expected identifier or '('
__nonnull ((1))
^
./malloc/dynarray-skeleton.c:195:13: error: expected ')'
./malloc/dynarray-skeleton.c:195:12: note: to match this '('
__nonnull ((1))
   ^
./malloc/dynarray-skeleton.c:205:40: error: expected identifier or '('
__attribute_maybe_unused__ __nonnull ((1))
   ^
./malloc/dynarray-skeleton.c:205:40: error: expected ')'
./malloc/dynarray-skeleton.c:205:39: note: to match this '('
__attribute_maybe_unused__ __nonnull ((1))
  ^

[PATCH] srfi-64: fix unused variable warnings

[Aleix Conchillo Flaqué]

* module/srfi/srfi-64/testing.scm: remove unused name variable and use
let instead of let*.

Signed-off-by: Aleix Conchillo Flaqué 
---
 module/srfi/srfi-64/testing.scm | 32 +---
 1 file changed, 13 insertions(+), 19 deletions(-)

diff --git a/module/srfi/srfi-64/testing.scm b/module/srfi/srfi-64/testing.scm
index 37792cd0f..d97797786 100644
--- a/module/srfi/srfi-64/testing.scm
+++ b/module/srfi/srfi-64/testing.scm
@@ -707,26 +707,24 @@
   (syntax-case (list x (list (syntax quote) (%test-source-line2 x))) ()
(((mac tname expr) line)
 (syntax
- (let* ((r (test-runner-get))
-(name tname))
+ (let ((r (test-runner-get)))
(test-result-alist! r (cons (cons 'test-name tname) line))
(%test-comp1body r expr
(((mac expr) line)
 (syntax
- (let* ((r (test-runner-get)))
+ (let ((r (test-runner-get)))
(test-result-alist! r line)
(%test-comp1body r expr)))
   (define (%test-comp2 comp x)
 (syntax-case (list x (list (syntax quote) (%test-source-line2 x)) comp) ()
   (((mac tname expected expr) line comp)
(syntax
-   (let* ((r (test-runner-get))
-  (name tname))
+   (let ((r (test-runner-get)))
  (test-result-alist! r (cons (cons 'test-name tname) line))
  (%test-comp2body r comp expected expr
   (((mac expected expr) line comp)
(syntax
-   (let* ((r (test-runner-get)))
+   (let ((r (test-runner-get)))
  (test-result-alist! r line)
  (%test-comp2body r comp expected expr))
   (define-syntax test-eqv
@@ -740,13 +738,12 @@
   (syntax-case (list x (list (syntax quote) (%test-source-line2 x))) ()
   (((mac tname expected expr error) line)
(syntax
-   (let* ((r (test-runner-get))
-  (name tname))
+   (let ((r (test-runner-get)))
  (test-result-alist! r (cons (cons 'test-name tname) line))
  (%test-comp2body r (%test-approximate= error) expected expr
   (((mac expected expr error) line)
(syntax
-   (let* ((r (test-runner-get)))
+   (let ((r (test-runner-get)))
  (test-result-alist! r line)
  (%test-comp2body r (%test-approximate= error) expected expr
  (else
@@ -759,23 +756,21 @@
   (define-syntax test-assert
 (syntax-rules ()
   ((test-assert tname test-expression)
-   (let* ((r (test-runner-get))
- (name tname))
+   (let ((r (test-runner-get)))
 (test-result-alist! r '((test-name . tname)))
 (%test-comp1body r test-expression)))
   ((test-assert test-expression)
-   (let* ((r (test-runner-get)))
+   (let ((r (test-runner-get)))
 (test-result-alist! r '())
 (%test-comp1body r test-expression)
   (define-syntax %test-comp2
 (syntax-rules ()
   ((%test-comp2 comp tname expected expr)
-   (let* ((r (test-runner-get))
- (name tname))
+   (let ((r (test-runner-get)))
 (test-result-alist! r (list (cons 'test-name tname)))
 (%test-comp2body r comp expected expr)))
   ((%test-comp2 comp expected expr)
-   (let* ((r (test-runner-get)))
+   (let ((r (test-runner-get)))
 (test-result-alist! r '())
 (%test-comp2body r comp expected expr)
   (define-syntax test-equal
@@ -895,18 +890,17 @@
   (syntax-case (list x (list (syntax quote) (%test-source-line2 x))) ()
(((mac tname etype expr) line)
 (syntax
- (let* ((r (test-runner-get))
-(name tname))
+ (let ((r (test-runner-get)))
(test-result-alist! r (cons (cons 'test-name tname) line))
(%test-error r etype expr
(((mac etype expr) line)
 (syntax
- (let* ((r (test-runner-get)))
+ (let ((r (test-runner-get)))
(test-result-alist! r line)
(%test-error r etype expr
(((mac expr) line)
 (syntax
- (let* ((r (test-runner-get)))
+ (let ((r (test-runner-get)))
(test-result-alist! r line)
(%test-error r #t expr
  (else
-- 
2.31.1

Re: Guile Potluck 2021

[Aleix Conchillo Flaqué]

On Mon, Mar 1, 2021 at 1:15 PM Linus Björnstam
 wrote:
>
> Hi Guilers!
>
> I found some code I wrote while drunk. I had completely forgotten about it, 
> but found it a fun little exercise. I would argue that falls under the 
> "neglected library" category.
>
> Anyway: It implements python-style generators, with yield and, more 
> importantly, yield-from:
>
> https://git.sr.ht/~bjoli/awesome-coroutine-generators
>
> I tried to extend it while sober. It didn't work, so be warned  I guess.

You know what to do then :-D.

> The code is somewhat a mess, but short enough to be understandable.
>

Aleix

Re: Guile Potluck 2021

[Aleix Conchillo Flaqué]

In case it was not clear:

guile-oauth 1.0.0 with OAuth2 support: https://github.com/aconchillo/guile-oauth
guile-redis 2.1.0 with Redis 6.2.0 commands:
https://github.com/aconchillo/guile-redis

Aleix

On Sun, Feb 21, 2021 at 9:59 PM Aleix Conchillo Flaqué
 wrote:
>
> Thank you Mike!
>
> I should have waited to release guile-oauth with the OAuth2 support :-). But 
> if that counts...
>
> Also planning to release guile-redis with redis 6.2 support when they make a 
> release (they are in RC3), but I might do it sooner.
>
> Best,
>
> Aleix
>
> On Thu, Feb 18, 2021, 9:43 AM Mike Gran  wrote:
>>
>> Hello All-
>>
>> In celebration of the (slightly belated) 10-year anniversary of Guile
>> v2.0, we're having another Guile Potluck!  The Guile Potluck is a
>> randomly annual event to give people a chance to show off their Guile
>> projects and skills.  Think of it as a game jam, but, not constrained
>> to games.
>>
>> To participate, on or before Mar 6, send an email to guile-u...@gnu.org
>> with instructions on how to find your entry, which could be anything
>> you like.  For example,
>>
>>- a script showing off some feature of Guile or your favorite Guile
>>library
>>- a blog post describing something interesting about Guile
>>- an updated release of a neglected library
>>- a mini-game
>>- a graphical or audio demoscene-type demo
>>
>> There probably won't be any prizes.  But there will definitely be an e-
>> mail and blog post about the entries.
>>
>> If you think you might attempt to participate, please reply to this e-
>> mail so I can gauge the feasibility of some sort of participation swag.
>>
>> Regards,
>> Mike Gran, on behalf of the Guile team
>>
>>
>>

Re: Guile Potluck 2021

[Aleix Conchillo Flaqué]

Thank you Mike!

I should have waited to release guile-oauth with the OAuth2 support :-).
But if that counts...

Also planning to release guile-redis with redis 6.2 support when they make
a release (they are in RC3), but I might do it sooner.

Best,

Aleix

On Thu, Feb 18, 2021, 9:43 AM Mike Gran  wrote:

> Hello All-
>
> In celebration of the (slightly belated) 10-year anniversary of Guile
> v2.0, we're having another Guile Potluck!  The Guile Potluck is a
> randomly annual event to give people a chance to show off their Guile
> projects and skills.  Think of it as a game jam, but, not constrained
> to games.
>
> To participate, on or before Mar 6, send an email to guile-u...@gnu.org
> with instructions on how to find your entry, which could be anything
> you like.  For example,
>
>- a script showing off some feature of Guile or your favorite Guile
>library
>- a blog post describing something interesting about Guile
>- an updated release of a neglected library
>- a mini-game
>- a graphical or audio demoscene-type demo
>
> There probably won't be any prizes.  But there will definitely be an e-
> mail and blog post about the entries.
>
> If you think you might attempt to participate, please reply to this e-
> mail so I can gauge the feasibility of some sort of participation swag.
>
> Regards,
> Mike Gran, on behalf of the Guile team
>
>
>
>

Re: [PATCH] vectors: add (vector-last) support

[Aleix Conchillo Flaqué]

Any interest on this one?

On Mon, Dec 21, 2020 at 1:44 AM Aleix Conchillo Flaqué 
wrote:

> Hi,
>
> Attached is a patch to add support for a new function (vector-last)
> that will retrieve the last element of a vector.
>
> This avoids having to do (vector-ref v (- (vector-length v) 1)).
>
> Let me know what you think.
>
> Thanks,
>
> Aleix
>

[PATCH] vectors: add (vector-last) support

[Aleix Conchillo Flaqué]

* libguile/vectors.c: add (vector-last) support.

* libguile/vectors.h: define scm_vector_last and scm_c_vector_last.

* doc/ref/api-data.texi (Vector Accessors): add documentation for
(vector-last).

Signed-off-by: Aleix Conchillo Flaqué 
---
 doc/ref/api-data.texi | 10 ++
 libguile/vectors.c| 30 +-
 libguile/vectors.h|  6 --
 test-suite/tests/srfi-43.test | 12 +++-
 4 files changed, 54 insertions(+), 4 deletions(-)

diff --git a/doc/ref/api-data.texi b/doc/ref/api-data.texi
index 2ad13f5a5..0878c1173 100644
--- a/doc/ref/api-data.texi
+++ b/doc/ref/api-data.texi
@@ -6354,6 +6354,16 @@ Return the contents of position @var{k} (a 
@code{size_t}) of
 @var{vec}.
 @end deftypefn
 
+@rnindex vector-last
+@deffn {Scheme Procedure} vector-last vec
+@deffnx {C Function} scm_vector_last (vec)
+Return the contents of the last element of @var{vec}.
+@end deffn
+
+@deftypefn {C Function} SCM scm_c_vector_last (SCM vec)
+Return the contents of the last element of @var{vec}.
+@end deftypefn
+
 A vector created by one of the dynamic vector constructor procedures
 (@pxref{Vector Creation}) can be modified using the following
 procedures.
diff --git a/libguile/vectors.c b/libguile/vectors.c
index 0f1e6085e..f079f1f53 100644
--- a/libguile/vectors.c
+++ b/libguile/vectors.c
@@ -193,7 +193,35 @@ scm_c_vector_ref (SCM v, size_t k)
 }
 #undef FUNC_NAME
 
-SCM_DEFINE (scm_vector_set_x, "vector-set!", 3, 0, 0, 
+SCM_DEFINE (scm_vector_last, "vector-last", 1, 0, 0,
+   (SCM vector),
+"@samp{Vector-ref} returns the contents of the last element of\n"
+"@var{vector}.\n\n"
+"@lisp\n"
+"(vector-ref '#(3 1 27 5)) @result{} 5\n"
+"@end lisp")
+#define FUNC_NAME s_scm_vector_last
+{
+  return scm_c_vector_last (vector);
+}
+#undef FUNC_NAME
+
+SCM
+scm_c_vector_last (SCM v)
+#define FUNC_NAME s_scm_vector_last
+{
+  SCM_VALIDATE_VECTOR (1, v);
+
+  size_t len = SCM_I_VECTOR_LENGTH (v);
+
+  if (len == 0)
+scm_out_of_range (NULL, 0);
+
+  return scm_c_vector_ref (v, len - 1);
+}
+#undef FUNC_NAME
+
+SCM_DEFINE (scm_vector_set_x, "vector-set!", 3, 0, 0,
(SCM vector, SCM k, SCM obj),
 "@var{k} must be a valid index of @var{vector}.\n"
 "@code{Vector-set!} stores @var{obj} in element @var{k} of 
@var{vector}.\n"
diff --git a/libguile/vectors.h b/libguile/vectors.h
index 41e2c8909..08fe19f49 100644
--- a/libguile/vectors.h
+++ b/libguile/vectors.h
@@ -1,7 +1,7 @@
 #ifndef SCM_VECTORS_H
 #define SCM_VECTORS_H
 
-/* Copyright 1995-1996,1998,2000-2002,2004-2006,2008-2009,2011,2014,2018
+/* Copyright 1995-1996,1998,2000-2002,2004-2006,2008-2009,2011,2014,2018,2020
  Free Software Foundation, Inc.
 
This file is part of Guile.
@@ -32,13 +32,14 @@ SCM_API SCM scm_vector_p (SCM x);
 SCM_API SCM scm_vector_length (SCM v);
 SCM_API SCM scm_vector (SCM l);
 SCM_API SCM scm_vector_ref (SCM v, SCM k);
+SCM_API SCM scm_vector_last (SCM v);
 SCM_API SCM scm_vector_set_x (SCM v, SCM k, SCM obj);
 SCM_API SCM scm_make_vector (SCM k, SCM fill);
 SCM_API SCM scm_vector_to_list (SCM v);
 SCM_API SCM scm_vector_fill_x (SCM v, SCM fill_x);
 SCM_API SCM scm_vector_move_left_x (SCM vec1, SCM start1, SCM end1,
SCM vec2, SCM start2);
-SCM_API SCM scm_vector_move_right_x (SCM vec1, SCM start1, SCM end1, 
+SCM_API SCM scm_vector_move_right_x (SCM vec1, SCM start1, SCM end1,
 SCM vec2, SCM start2);
 SCM_API SCM scm_vector_copy (SCM vec);
 
@@ -47,6 +48,7 @@ SCM_API int scm_is_simple_vector (SCM obj);
 SCM_API SCM scm_c_make_vector (size_t len, SCM fill);
 SCM_API size_t scm_c_vector_length (SCM vec);
 SCM_API SCM scm_c_vector_ref (SCM vec, size_t k);
+SCM_API SCM scm_c_vector_last (SCM vec);
 SCM_API void scm_c_vector_set_x (SCM vec, size_t k, SCM obj);
 SCM_API const SCM *scm_vector_elements (SCM vec,
scm_t_array_handle *h,
diff --git a/test-suite/tests/srfi-43.test b/test-suite/tests/srfi-43.test
index 554843e75..4d0093974 100644
--- a/test-suite/tests/srfi-43.test
+++ b/test-suite/tests/srfi-43.test
@@ -1,6 +1,6 @@
  srfi-43.test --- test suite for SRFI-43 Vector library -*- scheme -*-
 
- Copyright (C) 2014 Free Software Foundation, Inc.
+ Copyright (C) 2014, 2020 Free Software Foundation, Inc.
 
  This library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
@@ -390,6 +390,16 @@
   (pass-if-error "non-vector" (vector-ref '(a b c) 0))
   (pass-if-error "inexact index" (vector-ref '#(a b c) 1.0)))
 
+;;
+;; vector-last
+;;
+
+(with-test-prefix "vector-last"
+  (pass-if-equal "single element" 'a (vector-last '#(a)

[PATCH] vectors: add (vector-last) support

[Aleix Conchillo Flaqué]

Hi,

Attached is a patch to add support for a new function (vector-last)
that will retrieve the last element of a vector.

This avoids having to do (vector-ref v (- (vector-length v) 1)).

Let me know what you think.

Thanks,

Aleix


0001-vectors-add-vector-last-support.patch
Description: Binary data

Re: [PATCH] accept4: add support for SOCK_NONBLOCK when using accept()

[Aleix Conchillo Flaqué]

Fibers work on macOS is being done here.
https://github.com/wingo/fibers/pull/42

This is now working with both web servers.

On Wed, Jul 29, 2020 at 5:06 PM Aleix Conchillo Flaqué 
wrote:

> SOCK_NONBLOCK was not implemented when accept4() is not available (e.g.
> macOS).
>
> I'm currently testing all this with the two new web server implementations
> provided with Fibers.
>
> Aleix
>

[PATCH] accept4: add support for SOCK_NONBLOCK when using accept()

[Aleix Conchillo Flaqué]

SOCK_NONBLOCK was not implemented when accept4() is not available (e.g.
macOS).

I'm currently testing all this with the two new web server implementations
provided with Fibers.

Aleix


0001-accept4-add-support-for-SOCK_NONBLOCK-when-using-acc.patch
Description: Binary data

Re: [PATCH] socket: define SOCK_[CLOEXEC,NONBLOCK] on Darwin

[Aleix Conchillo Flaqué]

I believe this needs extra work, since (accept) is not happy now. I'll keep
you updated.

Aleix

On Wed, Jul 29, 2020, 11:06 AM Aleix Conchillo Flaqué 
wrote:

> Hi,
>
> I'm not 100% sure this is correct even though I have found it to be the
> solution in other patches on other projects.
>
> Hope this helps,
>
> Aleix
>
>

Re: Guile extensions path (includes PATCH)

[Aleix Conchillo Flaqué]

Any thoughts on this one?

Thanks,

Aleix

On Mon, Jun 29, 2020 at 7:54 PM Aleix Conchillo Flaqué 
wrote:

> Hi,
>
> I was adding guile-ncurses to homebrew-guile and realized there might be
> an issue in the documentation.
>
> According to this:
>
>
> https://www.gnu.org/software/guile/manual/html_node/Modules-and-Extensions.html
>
> the extensions directory is /usr/lib/guile/3.0/ (or
> /usr/local/lib/guile/3.0/m depending on your libdir). This is the
> directory where guile-ncurses installs libguile-ncurses library.
>
> However, I then saw that guile-readline was installed in
> /usr/local/lib/guile/3.0/extensions. I initially thought this was a
> Homebrew specific location. I looked at the Formula but there's nothing
> specific to Homebrew there.
>
> Then, I looked at guile and found this:
>
> http://git.savannah.gnu.org/cgit/guile.git/tree/libguile/Makefile.am#n772
>
> which indicates the extensions path is really /usr/lib/guile/3.0/
> extensions.
>
> I patched guile-ncurses with this and it works fine now on macOS.
>
> In case this is correct, I'm including a patch to fix the manual.
>
> Best,
>
> Aleix
>
>

[PATCH] socket: define SOCK_[CLOEXEC,NONBLOCK] on Darwin

[Aleix Conchillo Flaqué]

Hi,

I'm not 100% sure this is correct even though I have found it to be the
solution in other patches on other projects.

Hope this helps,

Aleix


0001-socket-define-SOCK_-CLOEXEC-NONBLOCK-on-Darwin.patch
Description: Binary data

Guile extensions path (includes PATCH)

[Aleix Conchillo Flaqué]

Hi,

I was adding guile-ncurses to homebrew-guile and realized there might be an
issue in the documentation.

According to this:

https://www.gnu.org/software/guile/manual/html_node/Modules-and-Extensions.html

the extensions directory is /usr/lib/guile/3.0/ (or
/usr/local/lib/guile/3.0/m depending on your libdir). This is the directory
where guile-ncurses installs libguile-ncurses library.

However, I then saw that guile-readline was installed in
/usr/local/lib/guile/3.0/extensions. I initially thought this was a
Homebrew specific location. I looked at the Formula but there's nothing
specific to Homebrew there.

Then, I looked at guile and found this:

http://git.savannah.gnu.org/cgit/guile.git/tree/libguile/Makefile.am#n772

which indicates the extensions path is really /usr/lib/guile/3.0/extensions.

I patched guile-ncurses with this and it works fine now on macOS.

In case this is correct, I'm including a patch to fix the manual.

Best,

Aleix


0001-doc-update-guile-extensions-path.patch
Description: Binary data

Re: Guile's time execution issues

[Aleix Conchillo Flaqué]

On Sat, May 2, 2020 at 7:11 AM Ludovic Courtès  wrote:

> Hola!
>
>
Hola!

So weird I'm getting different numbers on 2.2.7. Not sure how I'm getting
those initial ~20s and you are getting consistent ~ 45s. It shouldn't have
nothing to do with it, but could it be I'm running it on macOS?

Now, it would be good to profile ‘json->scm’ to see if there’s anything
> that could be improved on the Guile side, or if it’s just a normal
> profile for GC-intensive code.
>
>
Good news is that I have been working on performance improvements and
json->scm is going down from my ~19 seconds to ~3 seconds on the same
sample file. Linus Björnstam was the one to bring up performance issues so
we've been back and forth trying to make it fast.

One thing I found is that `match` is slow. The code looked nicer but had to
change it back to lets and conds as the performance increase was ~2 seconds.

Thanks for looking into this,

Aleix

Re: Guile's time execution issues

[Aleix Conchillo Flaqué]

On Sun, Apr 26, 2020 at 10:16 AM Ludovic Courtès  wrote:

> Bon dia!
>
>
Bon dia! And bon jour! :-D

> Aleix Conchillo Flaqué  skribis:
>
> > I was trying to get some guile-json performance times loading large JSON
> > file. However, I'm getting increasing numbers at each run, so I'm
> wondering
> > if I'm doing something wrong. Below you can see how the first run took
> > 19.95s and then running the same command kept increasing.
> >
> > I'm running Guile 2.2.7 on macOS Catalina 10.15.3.
> >
> > scheme@(guile-user)> (use-modules (json))
> > scheme@(guile-user)> ,t (define a (call-with-input-file
> > "/Users/aleix/Downloads/large-file.json" (lambda (port) (json->scm
> port
> > ;; 19.956429s real time, 87.100982s run time.  75.270202s spent in GC.
> > ;; 26.173179s real time, 143.645265s run time.  131.022631s spent in GC.
> > ;; 28.193926s real time, 154.758375s run time.  141.697236s spent in GC.
> > ;; 29.044218s real time, 160.745984s run time.  147.449073s spent in GC.
> > ;; 30.480873s real time, 170.855527s run time.  157.332793s spent in GC.
> > ;; 30.555700s real time, 172.938278s run time.  159.468737s spent in GC.
> > ;; 32.190478s real time, 172.807551s run time.  158.905645s spent in GC.
>
> Could this have to do with <https://issues.guix.gnu.org/issue/40194>?
>
>
Honestly, I have no idea... :-(

Could you check if that happens with 3.0.2?  (Or suggest a
> ‘large-file.json’ to use.  :-))
>
>
Sure! I suggested a JSON, it was hidden at the end of my first message ;-).
This is the one:

   https://github.com/json-iterator/test-data/blob/master/large-file.json

So, bad and good news for Guile 3.0.2. I'm trying it inside Docker using
this image https://hub.docker.com/r/schemers/guile.

On guile-json 3.5.0 (still using (string-append)) the first execution time
goes from 19 seconds to 42 seconds. Then, the times keep increasing as in
version 2.2.7 but numbers are much bigger:

# ./env guile
GNU Guile 3.0.2
Copyright (C) 1995-2020 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (use-modules (json))
scheme@(guile-user)> ,t (define a (call-with-input-file "large-file.json"
(lambda (port) (json->scm port
;; 42.015887s real time, 42.059462s run time.  32.838460s spent in GC.
scheme@(guile-user)> ,t (define a (call-with-input-file "large-file.json"
(lambda (port) (json->scm port
;; 56.228837s real time, 56.176989s run time.  46.112349s spent in GC.
scheme@(guile-user)> ,t (define a (call-with-input-file "large-file.json"
(lambda (port) (json->scm port
;; 63.472869s real time, 63.383118s run time.  52.642226s spent in GC.

The good news is that on master branch I don't use (string-append) anymore
and it goes from 19 seconds (in 2.2.7) to ~6 seconds (both in 2.2.7 and
3.0.2).

❯ ./env guile
GNU Guile 2.2.7
Copyright (C) 1995-2019 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> (use-modules (json))
scheme@(guile-user)> ,t (define a (call-with-input-file "large-file.json"
(lambda (port) (json->scm port
;; 6.635275s real time, 11.126605s run time.  5.119203s spent in GC.
scheme@(guile-user)> ,t (define a (call-with-input-file "large-file.json"
(lambda (port) (json->scm port
;; 6.856995s real time, 12.605237s run time.  6.476064s spent in GC.
scheme@(guile-user)> ,t (define a (call-with-input-file "large-file.json"
(lambda (port) (json->scm port
;; 6.556502s real time, 10.542702s run time.  4.550531s spent in GC.
scheme@(guile-user)> ,t (define a (call-with-input-file "large-file.json"
(lambda (port) (json->scm port
;; 6.396581s real time, 9.638931s run time.  3.707881s spent in GC.
scheme@(guile-user)> ,t (define a (call-with-input-file "large-file.json"
(lambda (port) (json->scm port
;; 6.293497s real time, 8.944718s run time.  3.055733s spent in GC.
scheme@(guile-user)> ,t (define a (call-with-input-file "large-file.json"
(lambda (port) (json->scm port
;; 6.249073s real time, 8.938264s run time.  3.099037s spent in GC.
scheme@(guile-user)> ,t (define a (call-with-input-file "large-file.json"
(lambda (port) (json->scm port
;; 6.168000s real time, 8.557252s run time.  2.772902s spent in GC.
scheme@(guile-user)> ,t (define a (call-with-input-

Guile's time execution issues

[Aleix Conchillo Flaqué]

Hi,

I was trying to get some guile-json performance times loading large JSON
file. However, I'm getting increasing numbers at each run, so I'm wondering
if I'm doing something wrong. Below you can see how the first run took
19.95s and then running the same command kept increasing.

I'm running Guile 2.2.7 on macOS Catalina 10.15.3.

scheme@(guile-user)> (use-modules (json))
scheme@(guile-user)> ,t (define a (call-with-input-file
"/Users/aleix/Downloads/large-file.json" (lambda (port) (json->scm port
;; 19.956429s real time, 87.100982s run time.  75.270202s spent in GC.
;; 26.173179s real time, 143.645265s run time.  131.022631s spent in GC.
;; 28.193926s real time, 154.758375s run time.  141.697236s spent in GC.
;; 29.044218s real time, 160.745984s run time.  147.449073s spent in GC.
;; 30.480873s real time, 170.855527s run time.  157.332793s spent in GC.
;; 30.555700s real time, 172.938278s run time.  159.468737s spent in GC.
;; 32.190478s real time, 172.807551s run time.  158.905645s spent in GC.

The good news is that I have applied a suggestion from Linus Björnstam that
reduces times by half (considering the first run above). The suggestion was
to use string ports instead of string-append. And interestingly this time,
time executions remain around the same value:

scheme@(guile-user)> ,t (define a (call-with-input-file
"/Users/aleix/Downloads/large-file.json" (lambda (port) (json->scm port
;; 9.099597s real time, 17.239176s run time.  9.309819s spent in GC.
;; 9.927868s real time, 20.855859s run time.  12.528727s spent in GC.
;; 8.981248s real time, 15.043991s run time.  7.050269s spent in GC.
;; 9.055893s real time, 15.400981s run time.  7.383187s spent in GC.
;; 9.055850s real time, 15.261824s run time.  7.239188s spent in GC.
;; 9.315239s real time, 15.231889s run time.  7.005570s spent in GC.
;; 9.106168s real time, 14.987678s run time.  6.915028s spent in GC.
;; 9.175142s real time, 14.471324s run time.  6.302749s spent in GC.
;; 8.966537s real time, 14.400318s run time.  6.412858s spent in GC.

JSON test data obtained from:

https://github.com/json-iterator/test-data/blob/master/large-file.json

Best,

Aleix

unable to build guile 2.9.7 on OS X 10.14.6

[Aleix Conchillo Flaqué]

Hi there!

Trying to build 2.9.7 on OS X and getting the error below.

I'd be happy to try more things if you want.

Aleix

-
wrote `system/vm/elf.go'
  BOOTSTRAP GUILEC system/vm/frame.go
wrote `system/vm/dwarf.go'
  BOOTSTRAP GUILEC system/vm/linker.go
/bin/sh: line 1: 69110 Abort trap: 6   GUILE_AUTO_COMPILE=0
../meta/build-env guild compile --target="x86_64-apple-darwin18.7.0" -O1
-Oresolve-primitives -L "/Users/aleix/guile-2.9.7/module" -L
"/Users/aleix/guile-2.9.7/guile-readline" -o "system/vm/linker.go"
"../module/system/vm/linker.scm"
make[2]: *** [system/vm/linker.go] Error 134
make[2]: *** Waiting for unfinished jobs
wrote `system/vm/frame.go'
wrote `system/vm/assembler.go'
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2


with V=1

GUILE_AUTO_COMPILE=0\
../meta/build-env   \
guild compile --target="x86_64-apple-darwin18.7.0"\
   -O1 -Oresolve-primitives  \
  -L "/Users/aleix/guile-2.9.7/module" \
  -L "/Users/aleix/guile-2.9.7/guile-readline"  \
  -o "system/vm/linker.go" "../module/system/vm/linker.scm"

Re: moving to gitlab?

[Aleix Conchillo Flaqué]

On Tue, Jan 22, 2019 at 5:30 PM Greg Troxel  wrote:
>
> Aleix Conchillo Flaqué  writes:
>
> > Any chance or interest in moving to gitlab? My apologies if this has
> > been discussed already. Not that I ever contribute anything directly
> > to Guile (2 patches in 6 years?), but it feels like it would be an
> > improvement in terms of communication, sending patches, etc. May be it
> > would even encourage more developers to contribute? Sending patches
> > over a mailing list shouldn't be a thing anymore. Again, my apologies.
>
> I can't speak for the coalition, but generally there is a notion that
> FSF projects are hosted on infrastructure operated by a charitable
> non-profit that has the advancement of Free Software as the goal.
>
> Also, history shows that the place people move to because of concerns
> about $PREVIOSU_PLACE will follow suit eventually...
>
> If your point is that the self-hosted infrastructure should have some
> way for random poeple to provide in-tool changes, that sounds sensible.

I realize I might have opened a can of worms, but yes, mainly that
would be the main motivation. Making it more easy for people to
contribute. Nowadays people are used to these kind of tools and, in my
experience, they are really useful.

Thanks,

Aleix

moving to gitlab? (was: Re: ping: Fixes for guile.m4)

[Aleix Conchillo Flaqué]

On Mon, Jan 21, 2019 at 6:59 AM Mike Gran  wrote:

> It isn't so easy to get one-off patches noticed right now, as far
> as I can tell.  Sometimes, you have better luck by putting them
> in the bug-tracker, and then Mark might notice them.
>

Any chance or interest in moving to gitlab? My apologies if this has
been discussed already. Not that I ever contribute anything directly
to Guile (2 patches in 6 years?), but it feels like it would be an
improvement in terms of communication, sending patches, etc. May be it
would even encourage more developers to contribute? Sending patches
over a mailing list shouldn't be a thing anymore. Again, my apologies.

Aleix

Re: [PATCH] Fixes for guile.m4

[Aleix Conchillo Flaqué]

On Sun, Dec 2, 2018 at 3:22 AM Mike Gran  wrote:
>
> On Sat, Dec 01, 2018 at 10:39:08PM -0800, Aleix Conchillo Flaqu� wrote:
> > Hi,
> >
> > while fixing https://github.com/aconchillo/guile-json/issues/20 I made
> > sure it also worked in Ubuntu 16.04. There you have guile-2.2 but no
> > guild-2.2 as they provide guild instead. If AC_PROGS finds guile-2.2
> > then it uses the suffix to find guild-2.2, however this does not work
> > in 16.04.
> >
> > This patch adds one more candidate (guild, guile-config or
> > guile-tools) in case it can't found the one without the suffix.
> >
>
> As an aside, patches to m4 files should increment the serial number
> so that calls to autoreconf --install will install the new one if
> the old one already present.
>
> https://www.gnu.org/software/automake/manual/html_node/Serials.html
>

I was not aware of that. Thanks! Let's try again the, patch attached.

Aleix


0001-Fix-guile.m4-GUILD-GUILE_CONFIG-and-GUILE_TOOLS.patch
Description: Binary data

[PATCH] Fixes for guile.m4

[Aleix Conchillo Flaqué]

Hi,

while fixing https://github.com/aconchillo/guile-json/issues/20 I made
sure it also worked in Ubuntu 16.04. There you have guile-2.2 but no
guild-2.2 as they provide guild instead. If AC_PROGS finds guile-2.2
then it uses the suffix to find guild-2.2, however this does not work
in 16.04.

This patch adds one more candidate (guild, guile-config or
guile-tools) in case it can't found the one without the suffix.

Totally unrelated and hopefully not opening a can of worms... Has it
been considered to move the repo to gitlab like some other projects
are doing? This would probably improve visibility and also would be
much easier to send patches, reviews, etc. It doesn't affect me much
since this might be the second patch I send in 8 years, I was just
wondering.

Best,

Aleix


0001-Fix-guile.m4-GUILD-GUILE_CONFIG-and-GUILE_TOOLS.patch
Description: Binary data

Re: guile-json: simple alist to json

[Aleix Conchillo Flaqué]

On Tue, Feb 23, 2016 at 12:09 PM, Jan Nieuwenhuizen  wrote:
>
> Ouch.  Yes, I get that too...
>
> I have been running this for quite some time but aparrently I prepared
> patches and sent untested, "cleaned-up" code.  Sorry.
>
> Please find a new patch set attached.
>

Applied patches and released 0.5.0.

Thanks!

Aleix

Re: guile-json: simple alist to json

[Aleix Conchillo Flaqué]

On Thu, Feb 18, 2016 at 2:21 PM, Jan Nieuwenhuizen  wrote:

> Hi Aleix,
>
> Attached are two patches to allow converting simple alists
> to json, this removes the need for strings or hash-tables
>
> scheme@(json)> (scm->json-string '((a . 1) (b . 2)))
> $2 = "{\"a\" : 1,\"b\" : 2}"
>
>
​
Hi Jan,

thanks for the patch! I have tried with guile 2.0.11 and it's giving me th
​e error at the end. I had zero time to fix it, but I believe it's
complaining because of this:

scheme@(guile-user)> (symbol 'a)
ERROR: In procedure string:
ERROR: In procedure string: Wrong type (expecting character): a

​"a" is already a symbol.

Best,​

​Aleix
​

scheme@(guile-user)> (use-modules (json))
scheme@(guile-user)> (scm->json-string '((a . 1) (b . 2)))
ERROR: In procedure string:
ERROR: In procedure string: Wrong type (expecting character): a

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> ,bt
   4 (call-with-output-string #)
In json/builder.scm:
173:4  3 (json-build ((a . 1) (b . 2)) # #f #f
0)
   118:34  2 (json-alist? ((a . 1) (b . 2)))
In ice-9/boot-9.scm:
  1423:18  1 (symbol a)
In unknown file:
   0 (string a)

Re: New logo and website design proposal

[Aleix Conchillo Flaqué]

On Fri, Oct 9, 2015 at 3:24 PM, Luis Felipe López Acevedo <
felipe.lo...@openmailbox.org> wrote:

> 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
>
> Then visit the website at .
>
>
​This looks beautiful!

I have a suggestion: would it be possible to show only one code sample in
the Code examples section? The code sample would periodically switch to a
new one smoothly and also the user should be able to jump from sample to
sample by clicking some arrows. Something like racket-lang (but much nicer
with your design!). Also, it would save some space. The code could be on
the left and the explanation on the right side with the title on top of the
explanation.

I have no idea how to do this or how hard it is. So, please disregard if it
doesn't make sense.

Congrats!

Aleix

Re: [PATCH] allow specifying a required version in GUILE_PROGS

[Aleix Conchillo Flaqué]

On Sat, Dec 21, 2013 at 1:05 PM, Ludovic Courtès  wrote:
>
> Pushed, thanks!
>
> As you noticed it took an unusually lng time to process your
> copyright paperwork at the FSF.  They are now aware of the problem and
> are working on improving the situation.
>
> So now there might still be bottlenecks to process your patches, but you
> know who they are.  ;-)
>
> Apologies, and thanks again!
>

Thanks to you! And no worries, no process is flawless.

Best,

Aleix

Re: [PATCH] allow specifying a required version in GUILE_PROGS

[Aleix Conchillo Flaqué]

On Fri, Oct 18, 2013 at 2:50 PM, Ludovic Courtès  wrote:
>
> The new version looks good to me.
>
> I forgot, but while waiting for the assignment to be on file ;-), could
> you update the manual entry for ‘GUILE_PROGS’?
>

I already did a minor update, may be it's not enough... From looking
into the doc/ref/Makefile.am, I understood the documentation is
obtained from the guile.m4 itself, right?

I am attaching a new patch with some more documentation. Let me know
if it works.

Thanks!

Aleix


guile-progs.patch
Description: Binary data

Re: [PATCH] allow specifying a required version in GUILE_PROGS

[Aleix Conchillo Flaqué]

Hi!

On Mon, Oct 14, 2013 at 2:05 PM, Ludovic Courtès  wrote:
> Hi Aleix,
>
> (Second try.)
>
> The patch looks good to me.
>
> Perhaps error messages should show
> $_guile_major_version.$_guile_minor_version.$_guile_micro_version since
> that could differ from $_guile_prog_version (for instance in Debian
> $_guile_prog_version is something like 2.0.9-deb42.)
>

Yes, I saw that and thought it was OK as the check was successfully
anyway. But probably it looks better as you suggested. In the attached
patch I don't get the version from (version) and I build
_guile_prog_version with macro.minor.micro.

> For code contributed to Guile, we ask for a copyright assignment to the
> FSF.  Would that be OK with you?  If yes, I can send you the form
> off-list, and then we can proceed (you might even be able to avoid snail
> mail entirely.)
>

Yes, sure.

Aleix


guile-progs.patch
Description: Binary data