Thanks all!
Hey guile-users, I have just made a release of my app [1] which integrates a Guile runtime -- since i received invaluable pointers from this mailing list, i thought folks might be curious as to what i was building. The app is called Spotiqueue, and it's a macOS-native client for listening to the Spotify music streaming service. It's intended to be keyboard-driven and fast, and now i guess it's arbitrarily extensible too! There's still some work to be done on the Guile integration front (e.g., exception handling), but it's already quite usable i think. Feedback welcome! Although i realise that Spotify is an evil walled-garden service and macOS is a non-free platform, my app is GPL and i've learned a lot making it, so i'm happy to take the risk that tomorrow the quicksand on which i've built it might shift and make it unviable. Cheers, p. 1. Spotiqueue on Github, https://github.com/toothbrush/Spotiqueue
Re: Thanks all!
Cl well done ! I love to see Guile projects 😉 Le 18 septembre 2021 08:54:25 GMT+02:00, paul a écrit : >Hey guile-users, > >I have just made a release of my app [1] which integrates a Guile >runtime -- since i received invaluable pointers from this mailing >list, i thought folks might be curious as to what i was building. > >The app is called Spotiqueue, and it's a macOS-native client for >listening to the Spotify music streaming service. It's intended >to be keyboard-driven and fast, and now i guess it's arbitrarily >extensible too! There's still some work to be done on the Guile >integration front (e.g., exception handling), but it's already >quite usable i think. Feedback welcome! Although i realise that >Spotify is an evil walled-garden service and macOS is a non-free >platform, my app is GPL and i've learned a lot making it, so i'm >happy to take the risk that tomorrow the quicksand on which i've >built it might shift and make it unviable. > >Cheers, >p. > >1. Spotiqueue on Github, https://github.com/toothbrush/Spotiqueue > -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: Thanks all!
really cool！ On Sat, Sep 18, 2021, 15:02 paul wrote: > Hey guile-users, > > I have just made a release of my app [1] which integrates a Guile > runtime -- since i received invaluable pointers from this mailing > list, i thought folks might be curious as to what i was building. > > The app is called Spotiqueue, and it's a macOS-native client for > listening to the Spotify music streaming service. It's intended > to be keyboard-driven and fast, and now i guess it's arbitrarily > extensible too! There's still some work to be done on the Guile > integration front (e.g., exception handling), but it's already > quite usable i think. Feedback welcome! Although i realise that > Spotify is an evil walled-garden service and macOS is a non-free > platform, my app is GPL and i've learned a lot making it, so i'm > happy to take the risk that tomorrow the quicksand on which i've > built it might shift and make it unviable. > > Cheers, > p. > > 1. Spotiqueue on Github, https://github.com/toothbrush/Spotiqueue > >
Re: #:printer filed in language specification.
Justin Veilleux schreef op vr 17-09-2021 om 18:50 [-0400]: > It works relatively well. However, I also wanted it to print a human > readable version of the procedures created. (It is hard to tell whether > # is a correct church encoding of the number 3) > With a lot of fiddling, I managed to write a function that turns a > procedure into an S-expression. The #:printer is only used by things like "guild compile -o ..." I think. One option is to create ‘applicable structs’ (unfortunately they aren't documented), setting the procedure to the actual procedure, and the record printer (set-record-type-printer!) to something printing the S-exp of the applicable struct. Greetings, Maxime signature.asc Description: This is a digitally signed message part
Re: #:printer filed in language specification.
Thanks a lot. On September 18, 2021 10:47:56 a.m. EDT, Maxime Devos wrote: >Justin Veilleux schreef op vr 17-09-2021 om 18:50 [-0400]: >> It works relatively well. However, I also wanted it to print a human >> readable version of the procedures created. (It is hard to tell whether >> # is a correct church encoding of the number 3) >> With a lot of fiddling, I managed to write a function that turns a >> procedure into an S-expression. > >The #:printer is only used by things like "guild compile -o ..." I think. > >One option is to create ‘applicable structs’ (unfortunately they aren't >documented), setting the procedure to the actual procedure, and the record >printer (set-record-type-printer!) to something printing the S-exp of the >applicable struct. > >Greetings, >Maxime
Re: foreign objects and the garbage collector
Il giorno sab, 04/09/2021 alle 15.35 +0200, Vivien Kraus via General Guile related discussions ha scritto: > Hello, > > Le samedi 04 septembre 2021 à 07:41 -0500, Tim Meehan a écrit : > > I'd rather not compile anything in C, and just use the tools in > > Guile to > > interact with libgps. Is there a way to get Guile's garbage > > collector to > > call "gps_close" on the opaque structure returned by "gps_open"? > I think it would be best to do it yourself. Maybe the garbage > collector will not run immediately (if at all), and if each creation > uses "precious" resources (such as file descriptors), you might run > into a shortage before the garbage collector is triggered. This is > not considered by people writing the C API of course, because they > assume you would close the thing as soon as possible. (Also, if > calling the close function is mandatory, for instance to run code > that’s not just freeing resources, and the garbage collector does not > have a chance to run, then it’s another problem. However, I > doubt your library does something like that). > > If you want to avoid the problem, you should explicitely bind and > call the gps-close function and not rely on the garbage collector to > do it for you. You can use dynamic-wind to open and close > resources as needed. It'd be so nice to have an example > That being said, make-pointer (from (system foreign-library)) is > probably what you are expecting. It should work with gps_close. Another exmple of what you mean, here, would be so nice :-)
Re: macro syntax-error works in prefix but not curly-infix
Il giorno sab, 04/09/2021 alle 16.41 +0200, Damien Mattei ha scritto:
> hi,
>
> i have this macro:
>
> (define-syntax <+
> (syntax-rules ()
> ((_ var expr) (define var expr))
> ((_ err ...) (syntax-error "Bad <- form")) ;; does not work in
> infix !
> ))
>
> why my syntax-error pattern never reach in infix:
>
> scheme@(guile-user)> {x <+ 7 8}
> While compiling expression:
> Syntax error:
> unknown file:3:3: source expression failed to match any pattern in
> form <+
>
> but ok in prefix:
>
> scheme@(guile-user)> (<+ x 9 10)
> While compiling expression:
> Syntax error:
> unknown location: <+: Bad <- form in form (<+ x 9 10)
>
> why?
> Regards,
> Damien
As far as I understand, infix syntax can't be achieved through macros
You'd need a custom reader for that
I might be wrong, but at least I offered something
Re: Can system modify an environment variable in the current environment?
Il giorno gio, 02/09/2021 alle 22.06 +0200, Roel Janssen ha scritto: > > Or in this particular case, use the "add-to-load-path" procedure: > https://www.gnu.org/software/guile/manual/html_node/Load-Paths.html > An example usage of "add-to-load-path" is avalilable in Haunt, the static blog builder In haunt/ui.scm on line 130 (if my checkout is current) The first thing the "haunt" command does is it adds the current folder (getcwd) to the load path so that the rest of the haunt code base can be found Hope this helps
