unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Nikolaos Chatzikonstantinou <nchatz314@gmail.com>
To: guile-user@gnu.org
Subject: Some issues with guile
Date: Fri, 26 Apr 2024 03:05:51 -0400	[thread overview]
Message-ID: <CAAQmekcHf-JQm4hV+WyecBFCAYatZVDKcTKbtRO=Yt-ObzmDRQ@mail.gmail.com> (raw)

Hello list,

I want to talk about some issues I've encountered with Guile. I'll
quickly summarize the points and I'll expand below.

1. Can't connect geiser from emacs to a remote REPL server unless
versions match.
2. Documentation extraction sucks.
3. Programs/libraries that use Guile as an extension language are
incompatible with one another.

If anyone can help with these points I would appreciate it. Keep in
mind that I am not a seasoned schemer nor intimately familiar with the
GNU Guile manual and it is possible that I've misunderstood something.

1. The easiest OS to hack on Guile is Guix. I don't run Guix so I
spinned a VM with it, where I installed guile-next for the
bleeding-edge guile. I attempted to run `guile --listen` in the VM and
`connect-to-guile` in the (Debian) host, but I'm getting errors, it's
not working. I don't quite understand why. The errors seem to be
related to version incompatibility, but I don't understand what if
anything my host guile package has to do with the guest VM guile
package.

2. There's an issue with documentating source code. The best system
I've seen is Rust's, but sphinx and Doxygen work fine too. At the very
least, a documentation system should have the following features:
  i. document all language constructs
  ii. markup (i.e. code blocks, links to other items)
  iii. exportable
Of course there can be more features, such as unit tests in
documentation, but I don't consider them essential. I don't know what
Guile does. I know there's `guild doc-snarf` and
`(ice-9 documentation)` with docstrings, as well as the package
documentá (<https://luis-felipe.gitlab.io/guile-documenta/>.) These don't work:
  - `guild doc-snarf` does something clumsily ONLY with
    double-semicolon comments. Triple-semicolon file headers that
    explain the purpose of a module are ignored, for example. It's not
    clear what the utility of the output of this tool is.
  - `object-documentation` from `(ice-9 documentation)` only seems to
    work with docstrings of functions, although it claims to work with
    macros too, suggesting that the `documentation` property should be
    set. But how? It's not explained. The info page on "Object
    Properties" makes it seem like this suffices: (set! (documentation
    my-function) "the docstring.")  but I can't get it to work like
    that. Docstrings cannot document files. Maybe they can document
    macros, variables, and modules at least? But the docstring format
    is raw, there is no markup!
  - documentá in its page does not include an example of how it works!
    Not a line of code to explain to the user which documentation is
    extracted. I could not understand how to use it.

3. I use GNU GDB for debugging. Sometimes there's a desire to be able
to interpret byte values in memory. GNU poke allows for this sort of
thing. Both programs are very similar in how they behave, and in
theory it should be possible to run poke commands from gdb, especially
since there's libpoke for this exact purpose. However, this is not
possible as far as I've been told, and the reason is that both libpoke
and gdb load guile, and therefore, gdb cannot load libpoke in memory
because of some issue with the Guile garbage collector! This is
terribly disappointing. Can anyone clarify what is going on with this
sort of thing? Workarounds so far include compiling gdb without guile
support (everyone uses python for scripting in gdb anyway) or dumping
byte ranges from gdb and examining them from the poke process
separately.



             reply	other threads:[~2024-04-26  7:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-26  7:05 Nikolaos Chatzikonstantinou [this message]
2024-04-26 15:21 ` Some issues with guile Luis Felipe
2024-04-27  7:28   ` Nikolaos Chatzikonstantinou
2024-04-27 20:32     ` Luis Felipe
2024-04-26 16:23 ` Dr. Arne Babenhauserheide
2024-04-26 20:39 ` Tomas Volf
2024-04-27  7:46   ` Nikolaos Chatzikonstantinou
2024-04-27 14:09     ` Dr. Arne Babenhauserheide
2024-04-27 17:35     ` Linas Vepstas
2024-04-27 20:24       ` Luis Felipe
2024-04-28  5:06       ` Nikolaos Chatzikonstantinou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAQmekcHf-JQm4hV+WyecBFCAYatZVDKcTKbtRO=Yt-ObzmDRQ@mail.gmail.com' \
    --to=nchatz314@gmail.com \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).