guile-debbugs-0.0.3 released [stable]
We are pleased to announce the release of Guile Debbugs 0.0.3. This package provides a Guile library to communicate with a Debbugs bug tracker's SOAP service. Here are the compressed sources and a GPG detached signature[*]: https://ftpmirror.gnu.org/guile-debbugs/guile-debbugs-0.0.3.tar.gz https://ftpmirror.gnu.org/guile-debbugs/guile-debbugs-0.0.3.tar.gz.sig Use a mirror for higher download bandwidth: https://www.gnu.org/order/ftp.html [*] 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 guile-debbugs-0.0.3.tar.gz.sig 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 BCA689B636553801C3C62150197A5888235FACAC and rerun the 'gpg --verify' command. This release was bootstrapped with the following tools: Autoconf 2.69 Automake 1.16.1 Gnulib v0.1-3269-g03d7a6b1f NEWS * Changes in 0.0.3 (since 0.0.2) The =search-est= operation now supports attribute filtering. The operation =get-bug-message-numbers= has been added. The procedure =fetch-mbox= has been added to =(debbugs operations)=. The procedure =soap-invoke*= has been added, which calls =soap-invoke= and caches the results. The =(debbugs soap)= module overrides Guile’s default handler for Content-Type headers to avoid errors when processing multipart messages with boundary strings containing “=”. The =soap-invoke= procedure now accepts a procedure returning the usable Debbugs endpoint URLs in addition to a plain service URL string as previously. The =(debbugs)= module provides the =%debian= and =%gnu= variables for the two major Debbugs instances out there. They can be used as the first argument to =soap-invoke=. The module also re-exports all public definitions of the =bug=, =operations=, and =soap= modules. Use Arun Isaac’s guile-email instead of poorly parsing emails on our own. signature.asc Description: PGP signature
Re: Guile Studio's goals (and home)
> From: Ricardo Wurmus > Cc: sirga...@zoho.com, guile-user@gnu.org > Date: Tue, 25 Feb 2020 13:47:36 +0100 > > > As an Emacs co-maintainer, I was quite surprised to read the above, > > since AFAIK none of these issues were ever communicated to the Emacs > > developers. If they were reported (using the Emacs built-in > > bug-reporting command), I'm quite sure we would be very attentive to > > such reports and amenable to adding/tweaking features so as to make > > Emacs a better basis for Guile use and development. After all, GNU > > projects should help each other. > > > > So I urge you to report the problems on which you hint above, and > > suggest changes or improvements that would remove at least some of the > > need to tweak Emacs for being a "Guile Studio". > > These are not necessarily problems with Emacs. They are just annoyances > that result from a mismatch of expectations. [...] > > I don’t feel strongly enough about these things that I would push to > change the defaults in Emacs. But as an experienced Emacs user I feel > confident enough to judge what Emacs features contribute to confusion, > and to configure them in a way that mitigates or avoids the confusion. > > The goal here is to point new Guilers to an IDE they can use without > further configuration instead of telling them to install Emacs, install > Geiser, install Company mode, install Flycheck and configure a Guile > syntax checker, etc. Guile Studio accomplishes this goal by configuring > Emacs — not by forking Emacs. > > I don’t think Emacs should have its defaults changed to be the best > Guile editor out of the box. It’s already the best editor (and more), > in my opinion, but it may need extensive configuration to get reach its > potential in different domains. A "problem" doesn't necessarily have to be a bug or a deficiency, it could also be a missing feature. In this case, a missing feature could perhaps be described as a lack of guile-ide.el package in Emacs, which users of the Guile Studio could simply load, and magically have their confusion taken care of. Or maybe Emacs could have a simple-ide.el package which would target more than just Guile users (assuming at least part of the customizations you think are needed are not specific to Guile). Or it could be something else; or a combination of several features separately selectable by users. My point is that a need for extensive customizations might mean that some more general issue exists that the Emacs developers may need to address, either by default or as customizable options that aggregate several related options (thus freeing the users from the need to customize each one separately). Describing those issues could therefore be beneficial both for Emacs and for Guile. So I still think a detailed bug report could be a good idea, if only to have the issues recorded in the Emacs issue tracker. TIA
resolving anonymous procedures in statprof
Hi, Guile's statprof utility is very helpful, but a lot of my output lines point to anonymous procedures like "anon #x1db7d38". Is there a way to figure out which specific lambdas those are referring to? In principle it seems like I should be able to figure that out by running the dissembler (,x) on the code I am profiling with statprof, but the addresses given by the dissassembler do not match the ones given by statprof. -- Christopher Howard p: +1 (907) 374-0257 w: https://librehacker.com social: https://gnusocial.club/librehacker gpg: ADDEAADE5D607C8D (keys.gnupg.net)
Re: Guile Studio's goals (and home)
On Tue, 25 Feb 2020 04:12:31 -0500 Ricardo Wurmus wrote > > Hi! > > > • What are Guile Studio's goals? > > The pretentiously named “Guile Studio” arose from the observation that > we often tell new Guile users to learn how to use Emacs first in order > to get a comfortable Guile development experience. Since Emacs has > really quirky defaults that don’t mesh with the expectations of people > who learn a new programming language, this can be so discouraging > that the person abandons the initial goal of learning Guile. > > Many people in the past had the idea to “fix” Emacs. “Guile Studio” is > not intended to be yet another Emacs starter kit like Prelude, Doom, or > Spacemacs. Instead it tries to focus on just Guile, going as far as to > remove “Emacs” from the window title and the menus. > > My goal was to provide a friendly editor that does not require any > configuration to use and play with Guile. You install Guile Studio and > get started right away. It tries to be what Dr Racket is for Racket and > what RStudio is for R. > > This is why Guile Studio comes with the picture language and immediately > spawns a Geiser session where it can be used. It hides Emacs clutter > from the menus and adds menu items that are relevant to new Guile users, > such as a link to the Guile manual. It aims to handle documentation > buffers specially to avoid the confusion that comes with Emacs-typical > “buffer clutter”. It uses CUA key bindings to avoid annoying surprises. > > Everything that serves to avoid confusion is welcome in Guile Studio. > > > • What is its relationship with the GNU Guile project? > > There is none. I’m just a Guile enthusiast who thought that Guile > Studio would be a good thing to build. > > > • The homepage field in the Guix package points to GNU Guile's > > website. Should I send future questions and issues to Guile's lists > > and issue tracker? > > I don’t know. Whether to use the Guile bug tracker is up for the Guile > maintainers to decide. I think it’s fine to use the guile-user list, > though. I’m subscribed to guile-user. > > > • Current Guile Studio version is 0.0.2. Any plans for a future version? > > Once Emacs 27 is released I’ll probably have to adjust a few things. > Perhaps I’ll also configure the use of tabs then. > > There are many more things that could be done to improve the experience > (buffer handling is still a big pain point; documentation needs to be > better integrated, etc), but I don’t think I can spend as much time on > this as I used to. I’ll gladly discuss and merge patches, though. > > Thank you for your interest in Guile Studio! No, thank you for the detailed information.
Re: Guile Studio's goals (and home)
On Fri, 28 Feb 2020 08:33:50 -0500 Eli Zaretskii wrote > > From: Ricardo Wurmus > > Cc: sirga...@zoho.com, guile-user@gnu.org > > Date: Tue, 25 Feb 2020 13:47:36 +0100 > > > > > As an Emacs co-maintainer, I was quite surprised to read the above, > > > since AFAIK none of these issues were ever communicated to the Emacs > > > developers. If they were reported (using the Emacs built-in > > > bug-reporting command), I'm quite sure we would be very attentive to > > > such reports and amenable to adding/tweaking features so as to make > > > Emacs a better basis for Guile use and development. After all, GNU > > > projects should help each other. > > > > > > So I urge you to report the problems on which you hint above, and > > > suggest changes or improvements that would remove at least some of the > > > need to tweak Emacs for being a "Guile Studio". > > > > These are not necessarily problems with Emacs. They are just annoyances > > that result from a mismatch of expectations. [...] > > > > I don’t feel strongly enough about these things that I would push to > > change the defaults in Emacs. But as an experienced Emacs user I feel > > confident enough to judge what Emacs features contribute to confusion, > > and to configure them in a way that mitigates or avoids the confusion. > > > > The goal here is to point new Guilers to an IDE they can use without > > further configuration instead of telling them to install Emacs, install > > Geiser, install Company mode, install Flycheck and configure a Guile > > syntax checker, etc. Guile Studio accomplishes this goal by configuring > > Emacs — not by forking Emacs. > > > > I don’t think Emacs should have its defaults changed to be the best > > Guile editor out of the box. It’s already the best editor (and more), > > in my opinion, but it may need extensive configuration to get reach its > > potential in different domains. > > A "problem" doesn't necessarily have to be a bug or a deficiency, it > could also be a missing feature. In this case, a missing feature > could perhaps be described as a lack of guile-ide.el package in Emacs, > which users of the Guile Studio could simply load, and magically have > their confusion taken care of. Or maybe Emacs could have a > simple-ide.el package which would target more than just Guile users > (assuming at least part of the customizations you think are needed are > not specific to Guile). Or it could be something else; or a > combination of several features separately selectable by users. > > My point is that a need for extensive customizations might mean that > some more general issue exists that the Emacs developers may need to > address, either by default or as customizable options that aggregate > several related options (thus freeing the users from the need to > customize each one separately). Describing those issues could > therefore be beneficial both for Emacs and for Guile. So I still > think a detailed bug report could be a good idea, if only to have the > issues recorded in the Emacs issue tracker. Personally, I avoid sending these kinds of issue reports to Emacs because I think to myself, "Emacs is GNU, Guile is GNU; the IDE functionality I want is common across IDEs; Emacs is very old; if this functionality is not in Emacs it's because they don't use it, or don't want it." But I guess it wouldn't hurt to try. If something good comes out of it (e.g. a default guile-ide), maybe Guile Studio could also benefit from it (if there is still a need for a Guile Studio). Maybe I'll send something...
Re: Guile Studio's goals (and home)
> Date: Fri, 28 Feb 2020 11:02:00 -0500 > From: sirgazil > Cc: "Ricardo Wurmus" , "guile-user" > > > My point is that a need for extensive customizations might mean that > > some more general issue exists that the Emacs developers may need to > > address, either by default or as customizable options that aggregate > > several related options (thus freeing the users from the need to > > customize each one separately). Describing those issues could > > therefore be beneficial both for Emacs and for Guile. So I still > > think a detailed bug report could be a good idea, if only to have the > > issues recorded in the Emacs issue tracker. > > Personally, I avoid sending these kinds of issue reports to Emacs because I > think to myself, "Emacs is GNU, Guile is GNU; the IDE functionality I want is > common across IDEs; Emacs is very old; if this functionality is not in Emacs > it's because they don't use it, or don't want it." Emacs is very old, but new packages and features are being added to it all the time. Just look at the NEWS file of any Emacs release, and you will see that clearly. > Maybe I'll send something... Please do, and TIA.
Python on guile
Hi all, there is an ever stream of tickets to fix in the python clone made in guile. Usually I spend time testing some python submodule and in the process realizes issues with the current code base. I'm certain that there is quite a lot of bus still remaining. My latest addition was the subprocess module, which exersisced the select code, the os module and a popen like implementation. In the process glitches in the name spacing was found and fixed for classes. (the name bounding in clasdefs are a let construct but the decorators can refer to the variable bindings (methods and assignments). I fixed the try exception mechanism when one issues a simple (raise). If in a contexts of a error handler, then the catched exception is resent. previously a simple Exception with no data was resent. Now most warnings that was spamming the python session have been quited. quite a lot of bugs have been found in the os module and fixed. With this I'm happy with the python on guile repo and just released a version 1.1 Repo: https://gitlab.com/python-on-guile/python-on-guile/tree/master Happy hacking
