unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Jean Abou Samra <jean@abou-samra.fr>
To: Guile User <guile-user@gnu.org>
Subject: Re: Source location behavior differs in REPL and script?
Date: Sun, 24 Jul 2022 14:54:06 +0200	[thread overview]
Message-ID: <0e4ee011-93d2-3719-51db-f2e8f4ea9f15@abou-samra.fr> (raw)
In-Reply-To: <8929ae87-e67f-e538-8c42-ee537fac8a55@abou-samra.fr>



Le 24/07/2022 à 14:26, Jean Abou Samra a écrit :
> Hi,
>
> For context, I'm trying to fix issues with source locations
> from embedded Scheme code in LilyPond. Essentially, with
> Guile 2.2, errors are displayed without any source location
> info because the evaluator doesn't provide them. The compiler
> does, so I'm investigating whether we can use it.
>
> So far, I've been experimenting in the REPL, and tearing my
> hair because I couldn't get locations to work. My test started
> to become inconvenient to modify in the REPL at some point,
> so I switched to putting that code in a .scm file. To my
> great surprise, that made locations suddenly work.
>
> Example:
>
> (use-modules (system base compile))
>
> (define code-str
>   "
> (begin
>   (debug-disable 'backtrace)
>   (define (func1 x)
>     (func2 x)
>     (func2 x)
>     (func2 x))
>
>   (define (func2 x)
>     (display (func3 x))
>     (write (func3 x))
>     (map write (func3 x)))
>
>   (define (func3 x)
>     (error \"Oops\"))
>
>   (func1 #f))
>   ")
>
> (define code-synt
>   (call-with-input-string
>    code-str
>    (lambda (port)
>      (set-port-filename! port "fake.scm")
>      (read-syntax port))))
>
> (compile code-synt)
>
>
> When I paste this in the REPL, the given error is
>
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Oops
>
>
> When I put it in tests.scm and run "guile3.0 tests.scm",
> the error is
>
> fake.scm:15:4: In procedure func1:
> Oops
>
>
> When I put it in a LilyPond file, the result is
>
> Oops
>
> (without any location info at all).
>
> Does anyone have a clue about what causes these differences?
> Is it expected? Should I report it as a bug? Also, is there a
> workaround?


Well, 10 minutes later, I have my answer. Both the REPL and LilyPond
use catch to be robust against errors, printing the backtraces but
not exiting themselves. I need to investigate if there is a way
to get the location when catching an exception.

Sorry for the noise,
Jean





      reply	other threads:[~2022-07-24 12:54 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-24 12:26 Source location behavior differs in REPL and script? Jean Abou Samra
2022-07-24 12:54 ` Jean Abou Samra [this message]

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=0e4ee011-93d2-3719-51db-f2e8f4ea9f15@abou-samra.fr \
    --to=jean@abou-samra.fr \
    --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).