Re: GNU G-Golf 0.8.0-rc6 available for testing
David Pirotte writes:
> http://ftp.gnu.org/gnu/g-golf/g-golf-0.8.0-rc6.tar.gz
This is an odd version scheme; I would suggest that you instead use
0.8.0rc7 next time. Packaging systems have code to interpret versions,
and the - is irregular as it usually separates package names and
versions. Bsaically, do it like everybody else please.
I'm building on NetBSD 10 amd64 with
=> Tool dependency glib2-tools-[0-9]*: found glib2-tools-2.80.4
=> Tool dependency mktools-[0-9]*: found mktools-20220614
=> Tool dependency gtexinfo>=6: found gtexinfo-7.1
=> Tool dependency pkgconf-[0-9]*: found pkgconf-2.3.0
=> Tool dependency ccache-[0-9]*: found ccache-4.10.2
=> Tool dependency cwrappers>=20150314: found cwrappers-20220403
=> Tool dependency checkperms>=1.1: found checkperms-1.12
=> Full dependency glib2>=2.76.4nb1: found glib2-2.80.4
=> Full dependency gobject-introspection>=1.76.1nb1: found
gobject-introspection-1.80.1nb3
=> Full dependency guile22>=2.2.7nb6: found guile22-2.2.7nb6
and this blows up:
GEN g-golf/support/color.go
Backtrace:
In system/base/compile.scm:
155:11 19 (_ #)
235:18 18 (read-and-compile # ?)
183:32 17 (compile-fold (#) ?)
In ice-9/boot-9.scm:
2312:4 16 (save-module-excursion #)
In language/scheme/compile-tree-il.scm:
31:15 15 (_)
In ice-9/psyntax.scm:
1262:36 14 (expand-top-sequence ((define-module (g-golf # #) # ?)) ?)
1209:24 13 (parse _ (("placeholder" placeholder)) ((top) #(# # ?)) ?)
285:10 12 (parse _ (("placeholder" placeholder)) (()) _ c&e (# #) #)
In ice-9/eval.scm:
293:34 11 (_ #)
In ice-9/boot-9.scm:
2874:4 10 (define-module* _ #:filename _ #:pure _ #:version _ # _ ?)
2071:24 9 (call-with-deferred-observers #)
2887:24 8 (_)
222:29 7 (map1 (((ice-9 rdelim)) ((ice-9 match)) ((ice-9 #) ?) ?))
222:29 6 (map1 (((ice-9 match)) ((ice-9 string-fun) #:select ?) ?))
222:17 5 (map1 (((ice-9 string-fun) #:select ((# . #))) ((# ?)) ?))
2813:10 4 (resolve-interface (ice-9 string-fun) #:select _ #:hide ?)
260:13 3 (for-each # ?)
2818:38 2 (_ _)
In unknown file:
1 (scm-error misc-error #f "~A" ("no binding `string-re?") ?)
In ice-9/boot-9.scm:
752:25 0 (dispatch-exception _ _ _)
ice-9/boot-9.scm:752:25: In procedure dispatch-exception:
no binding `string-replace-substring' in module (ice-9 string-fun)
*** [g-golf/support/color.go] Error code 1
with guile 3.0.x, it goes much better, with fewer warnings, and the
build completes. It would be fine for me personally if this were fixed
by adjusting the guile requirement to >= 3.0, but I don't know how much
that would bother others. (It is unfortunate how there are backwards
compat issues that cause people to need old guile, or so it seems.)
Re: GNU G-Golf 0.8.0-rc6 available for testing
Hello Guilers, > The sixth release candidate of the upcoming GNU G-Golf 0.8.0 release > is now available for testing: > ... It occurs to me that I forgot to add an examples/gtk-4/Makefile.am (sub)target entry, so the tarball also distributes the newly added demos/*.scm files. Hopefully, i shall build and release 0.8.0-rc7 tonight. Sorry for the inconvinience. David pgpxejjXEm8mL.pgp Description: OpenPGP digital signature
GNU G-Golf 0.8.0-rc7 available for testing
Hello Guilers, The seventh 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-rc7.tar.gz http://ftp.gnu.org/gnu/g-golf/g-golf-0.8.0-rc7.tar.gz.sig * About G-Golf G-Golf is a Guile Object Library for GNOME. Complete description is given in the distributed README file or here: https://www.gnu.org/software/g-golf/ * 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-rc7 Here is a summary of the noteworthy changes in this release, also available in NEWS file and on the G-Golf website. ** Fixing the 0.8.0-rc6 release tarball malformed issue This release merely fixes a missing examples/gtk-4/Makefile.am (sub)target entry, so the tarball also distributes the newly added examples/gtk-4/demos/*.scm files. * 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-user@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-rc7.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 (long/huge) 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!). pgpleEIBwGO2H.pgp Description: OpenPGP digital signature
Re: [critical bug] The set! doesn't work in indirect reference
Thanks for the reply! I've taken a look at https://www.gnu.org/software/guile/manual/html_node/Declarative-Modules.html It's related to #:declarative? Thanks again! Best regards. On Wed, Sep 18, 2024 at 11:50 PM Thompson, David wrote: > On Wed, Sep 18, 2024 at 10:38 AM Nala Ginrut wrote: > > > > The result is: > > ;;; (before #f) > > ;;; (after #f) > > > > The expected result should be: > > ;; (before #f) > > ;; (after 123) > > I don't think this is a bug. Both modules are declarative (the > default). 'global' from module (aaa) is presumably being inlined into > the 'pk' calls in module (bbb). If you mark module (bbb) as > '#:declarative? #f' then you get your expected result. > > Hope this helps, > > - Dave >
global vars and #:declarative? (was [critical bug] The set! doesn't work in indirect reference)
I realized the #:declarative? can only be applied in the downstream modules of the module holding global vars. So the #:declarative? will affect the whole module and I have to put it everywhere that references the global vas. Maybe it'd be better if there's finer granularity control for each, like define-non-dclarative or else. BTW. In my case, I want to implement the global var mutation. For such a case, if users don't want to put #:declarative? to affect the whole downstream modules, maybe the best way is to implement getter and setter inside the global var module. Comments are welcome. Thanks! Best regards.
Re: [critical bug] The set! doesn't work in indirect reference
On Wed, Sep 18, 2024 at 10:38 AM Nala Ginrut wrote: > > The result is: > ;;; (before #f) > ;;; (after #f) > > The expected result should be: > ;; (before #f) > ;; (after 123) I don't think this is a bug. Both modules are declarative (the default). 'global' from module (aaa) is presumably being inlined into the 'pk' calls in module (bbb). If you mark module (bbb) as '#:declarative? #f' then you get your expected result. Hope this helps, - Dave
[critical bug] The set! doesn't work in indirect reference
Hi folks! Recently I was bothered by a strange bug when debugging Artanis, here's how to reproduce. You need three files, say aaa.scm, bbb.scm, and entry -aaa.scm (define-module (aaa) #:export (global)) (define global #f) --aaa.scm end --bbb.scm (define-module (bbb) #:use-module (aaa) #:export (fun)) (define (fun) (pk 'before global) (set! global 123) (pk 'after global)) ---bbb.scm end- --entry- (import (bbb)) (fun) -entry end- Put all files in the same directory, and run: cut guile -L . entry end--- The result is: ;;; (before #f) ;;; (after #f) The expected result should be: ;; (before #f) ;; (after 123) -- This was tested in 3.0.9 and 3.0.10. I also CC guile-user list, in case anyone was troubled by strange bugs, this may be a hint. Best regards.
Re: global vars and #:declarative? (was [critical bug] The set! doesn't work in indirect reference)
Nala Ginrut writes: > I realized the #:declarative? can only be applied in the downstream modules > of the module holding global vars. This easy to hit complexity was the topic of my thread "Making code compatible with different versions of Guile — #:declarative?" How declarative currently works is a very painful gotcha that affects one of the most elegant way of building Guile applications: getting a live REPL and improving your code iteratively. Chickadee uses that beautifully: https://files.dthompson.us/docs/chickadee/latest/Live-Coding.html Here’s an example of that: https://www.draketo.de/software/chickadee-wisp.webm https://www.draketo.de/software/wisp#chickadee-2022-10-08 But once this gets a bit more complex, you must litter your modules with #:declarative? #f otherwise your changes in the REPL have no effect at all. For example entering a module with ,m to fix a bug there won’t be seen by the actual running code. And this is a breaking change in behavior (it actually broke working code for me). So I think that the default for user-modules should be non-declarative. To improve performance nontheless, we could manually mark all modules shipped with Guile as #:declarative? #t but change the default to #f. > So the #:declarative? will affect the whole module and I have to put it > everywhere that references the global vas. > > Maybe it'd be better if there's finer granularity control for each, like > define-non-dclarative or else. In the thread I mentioned, Maxime wrote that (define (foo ...) ...) (set! foo foo) should have the effect of making foo non-declarative. I did not test that yet, though. > BTW. In my case, I want to implement the global var mutation. For such a > case, if users don't want to put #:declarative? to affect the whole > downstream modules, maybe the best way is to implement getter and setter > inside the global var module. I think that when we have to implement getters and setters for this, that’s an indication of a design problem. Best wishes, Arne -- Unpolitisch sein heißt politisch sein, ohne es zu merken. draketo.de signature.asc Description: PGP signature
