GNU bug report logs - #61658
30.0.50; server-eval-at might handle unreadable results better

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61658 in the body.
You can then email your comments to 61658 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; server-eval-at might handle unreadable results better
Date: Mon, 20 Feb 2023 09:25:34 -0700

Hello,

I use server-eval-at to call a function, in another daemon, which
returns a buffer.  So, server-eval-at tries (read "#<buffer *foo*>")
which of course fails, and indeed signals an error.

I wonder if server-eval-at should return a special value to indicate
that the remote computation returned something that is not readably
printable?  Or signal a particular error, which the caller might catch?

-- 
Sean Whitton

Message #8 received at 61658 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 61658 <at> debbugs.gnu.org
Subject: Re: bug#61658: 30.0.50;
 server-eval-at might handle unreadable results better
Date: Mon, 20 Feb 2023 19:09:00 +0200

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Date: Mon, 20 Feb 2023 09:25:34 -0700
> 
> I use server-eval-at to call a function, in another daemon, which
> returns a buffer.  So, server-eval-at tries (read "#<buffer *foo*>")
> which of course fails, and indeed signals an error.
> 
> I wonder if server-eval-at should return a special value to indicate
> that the remote computation returned something that is not readably
> printable?  Or signal a particular error, which the caller might catch?

Why can't you make that function return something more sensible?  Or
even just nil?

Message #11 received at 61658 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61658 <at> debbugs.gnu.org
Subject: Re: bug#61658: 30.0.50; server-eval-at might handle unreadable
 results better
Date: Wed, 22 Feb 2023 10:28:05 -0700

Hello,

On Mon 20 Feb 2023 at 07:09PM +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Date: Mon, 20 Feb 2023 09:25:34 -0700
>>
>> I use server-eval-at to call a function, in another daemon, which
>> returns a buffer.  So, server-eval-at tries (read "#<buffer *foo*>")
>> which of course fails, and indeed signals an error.
>>
>> I wonder if server-eval-at should return a special value to indicate
>> that the remote computation returned something that is not readably
>> printable?  Or signal a particular error, which the caller might catch?
>
> Why can't you make that function return something more sensible?  Or
> even just nil?

Yes, that is a way to handle cases like this.  I was thinking it might
be better to have

    (define-error 'server-return-invalid-read-syntax
                  "Remote function returned unreadable form"
                  'invalid-read-syntax)

for a more flexible way to handle the situation.

-- 
Sean Whitton

Message #14 received at 61658 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 61658 <at> debbugs.gnu.org
Subject: Re: bug#61658: 30.0.50; server-eval-at might handle unreadable
 results better
Date: Wed, 22 Feb 2023 22:07:09 +0200

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: 61658 <at> debbugs.gnu.org
> Date: Wed, 22 Feb 2023 10:28:05 -0700
> 
> >> I use server-eval-at to call a function, in another daemon, which
> >> returns a buffer.  So, server-eval-at tries (read "#<buffer *foo*>")
> >> which of course fails, and indeed signals an error.
> >>
> >> I wonder if server-eval-at should return a special value to indicate
> >> that the remote computation returned something that is not readably
> >> printable?  Or signal a particular error, which the caller might catch?
> >
> > Why can't you make that function return something more sensible?  Or
> > even just nil?
> 
> Yes, that is a way to handle cases like this.  I was thinking it might
> be better to have
> 
>     (define-error 'server-return-invalid-read-syntax
>                   "Remote function returned unreadable form"
>                   'invalid-read-syntax)
> 
> for a more flexible way to handle the situation.

But what we have now already gives you almost the same information:

  invalid-read-syntax, "#"

I'm not sure I understand what would the above add to this.  Is
"Remote function returned unreadable form" really that much more
informative, when the user doesn't expect an error?

Message #17 received at 61658 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61658 <at> debbugs.gnu.org
Subject: Re: bug#61658: 30.0.50; server-eval-at might handle unreadable
 results better
Date: Wed, 22 Feb 2023 17:24:26 -0700

Hello,

On Wed 22 Feb 2023 at 10:07PM +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Cc: 61658 <at> debbugs.gnu.org
>> Date: Wed, 22 Feb 2023 10:28:05 -0700
>> [...]
>> Yes, that is a way to handle cases like this.  I was thinking it might
>> be better to have
>>
>>     (define-error 'server-return-invalid-read-syntax
>>                   "Remote function returned unreadable form"
>>                   'invalid-read-syntax)
>>
>> for a more flexible way to handle the situation.
>
> But what we have now already gives you almost the same information:
>
>   invalid-read-syntax, "#"
>
> I'm not sure I understand what would the above add to this.  Is
> "Remote function returned unreadable form" really that much more
> informative, when the user doesn't expect an error?

I'm thinking about the design of calling code, not errors that bubble up
all the way to the user.  If I want to catch this situation in calling
code, I can catch 'invalid-read-syntax'.  But for that to catch only the
errors I intend to catch, I have to assume that the only call to 'read'
in server-eval-at is the one that reads the remote daemon's output.  But
that's an implementation detail of server-eval-at, that could change.

-- 
Sean Whitton

Message #20 received at 61658 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 61658 <at> debbugs.gnu.org
Subject: Re: bug#61658: 30.0.50; server-eval-at might handle unreadable
 results better
Date: Thu, 23 Feb 2023 08:24:42 +0200

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: 61658 <at> debbugs.gnu.org
> Date: Wed, 22 Feb 2023 17:24:26 -0700
> 
> Hello,
> 
> On Wed 22 Feb 2023 at 10:07PM +02, Eli Zaretskii wrote:
> 
> >> From: Sean Whitton <spwhitton <at> spwhitton.name>
> >> Cc: 61658 <at> debbugs.gnu.org
> >> Date: Wed, 22 Feb 2023 10:28:05 -0700
> >> [...]
> >> Yes, that is a way to handle cases like this.  I was thinking it might
> >> be better to have
> >>
> >>     (define-error 'server-return-invalid-read-syntax
> >>                   "Remote function returned unreadable form"
> >>                   'invalid-read-syntax)
> >>
> >> for a more flexible way to handle the situation.
> >
> > But what we have now already gives you almost the same information:
> >
> >   invalid-read-syntax, "#"
> >
> > I'm not sure I understand what would the above add to this.  Is
> > "Remote function returned unreadable form" really that much more
> > informative, when the user doesn't expect an error?
> 
> I'm thinking about the design of calling code, not errors that bubble up
> all the way to the user.  If I want to catch this situation in calling
> code, I can catch 'invalid-read-syntax'.  But for that to catch only the
> errors I intend to catch, I have to assume that the only call to 'read'
> in server-eval-at is the one that reads the remote daemon's output.  But
> that's an implementation detail of server-eval-at, that could change.

So you want server.el to catch the error and re-throw it with a
different signal in this particular case?  Or am I misunderstanding?

Message #23 received at 61658 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61658 <at> debbugs.gnu.org
Subject: Re: bug#61658: 30.0.50; server-eval-at might handle unreadable
 results better
Date: Thu, 23 Feb 2023 10:27:11 -0700

Hello,

On Thu 23 Feb 2023 at 08:24AM +02, Eli Zaretskii wrote:

> So you want server.el to catch the error and re-throw it with a
> different signal in this particular case?  Or am I misunderstanding?

Yes, that's what I'd like to do.

-- 
Sean Whitton

Message #26 received at 61658 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 61658 <at> debbugs.gnu.org
Subject: Re: bug#61658: 30.0.50; server-eval-at might handle unreadable
 results better
Date: Thu, 23 Feb 2023 19:42:07 +0200

> From: Sean Whitton <spwhitton <at> spwhitton.name>
> Cc: 61658 <at> debbugs.gnu.org
> Date: Thu, 23 Feb 2023 10:27:11 -0700
> 
> On Thu 23 Feb 2023 at 08:24AM +02, Eli Zaretskii wrote:
> 
> > So you want server.el to catch the error and re-throw it with a
> > different signal in this particular case?  Or am I misunderstanding?
> 
> Yes, that's what I'd like to do.

But then just define-error isn't enough, is it?

Message #29 received at 61658 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 61658 <at> debbugs.gnu.org
Subject: Re: bug#61658: 30.0.50; server-eval-at might handle unreadable
 results better
Date: Thu, 23 Feb 2023 11:08:10 -0700

Hello,

On Thu 23 Feb 2023 at 07:42PM +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton <at> spwhitton.name>
>> Cc: 61658 <at> debbugs.gnu.org
>> Date: Thu, 23 Feb 2023 10:27:11 -0700
>>
>> On Thu 23 Feb 2023 at 08:24AM +02, Eli Zaretskii wrote:
>>
>> > So you want server.el to catch the error and re-throw it with a
>> > different signal in this particular case?  Or am I misunderstanding?
>>
>> Yes, that's what I'd like to do.
>
> But then just define-error isn't enough, is it?

Right.  I didn't mean to suggest it was -- my apologies.

-- 
Sean Whitton

Message #34 received at 61658-done <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: 61658-done <at> debbugs.gnu.org
Subject: Re: bug#61658: 30.0.50; server-eval-at might handle unreadable
 results better
Date: Wed, 08 Mar 2023 17:10:51 -0700

Hello,

Now implemented.  Doesn't seem to me like a NEWS entry is warranted, but
if anyone strongly disagrees I can write one.

-- 
Sean Whitton

Message #37 received at 61658 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: 61658 <at> debbugs.gnu.org
Cc: spwhitton <at> spwhitton.name
Subject: Re: bug#61658: 30.0.50; server-eval-at might handle unreadable
 results better
Date: Thu, 09 Mar 2023 10:40:30 +0100

>>>>> On Wed, 08 Mar 2023 17:10:51 -0700, Sean Whitton <spwhitton <at> spwhitton.name> said:

    Sean> Hello,
    Sean> Now implemented.  Doesn't seem to me like a NEWS entry is warranted, but
    Sean> if anyone strongly disagrees I can write one.

It changes the possible behaviour of a public function, so I think it
is warranted (and I have some comments on the docstrings, but Iʼll
address those separately).

Robert
-- 

Message #40 received at 61658 <at> debbugs.gnu.org (full text, mbox):

From: Sean Whitton <spwhitton <at> spwhitton.name>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 61658 <at> debbugs.gnu.org
Subject: Re: bug#61658: 30.0.50; server-eval-at might handle unreadable
 results better
Date: Sat, 11 Mar 2023 11:48:42 -0700

Hello,

On Thu 09 Mar 2023 at 10:40AM +01, Robert Pluim wrote:

>>>>>> On Wed, 08 Mar 2023 17:10:51 -0700, Sean Whitton <spwhitton <at> spwhitton.name> said:
>
>     Sean> Hello,
>     Sean> Now implemented.  Doesn't seem to me like a NEWS entry is warranted, but
>     Sean> if anyone strongly disagrees I can write one.
>
> It changes the possible behaviour of a public function, so I think it
> is warranted (and I have some comments on the docstrings, but Iʼll
> address those separately).

But the new condition is a subtype of the old one, so it's a fully
backwards-compatible change to the behaviour.  Indeed, barely a change.
Does anyone else have any intuitions about this?

-- 
Sean Whitton

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.