GNU bug report logs -
#59501
[PATCH] rcirc: Issue with printing messages in the wrong place
Previous Next
Reported by: Thuna <thuna.cing <at> gmail.com>
Date: Wed, 23 Nov 2022 03:38:01 UTC
Severity: normal
Tags: patch
Done: Philip Kaludercic <philipk <at> posteo.net>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 59501 in the body.
You can then email your comments to 59501 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#59501
; Package
emacs
.
(Wed, 23 Nov 2022 03:38:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Thuna <thuna.cing <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Wed, 23 Nov 2022 03:38:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[0001-rcirc-Fix-messages-printing-in-the-wrong-place.patch (text/x-patch, attachment)]
[Message part 2 (text/plain, inline)]
I have occasionally had replies show before my messages, so I
decided to look into it. It looks like rcirc looks at the time
of the message, compares it to the `rcirc-time' text property of
other messages, and places it so that the property is properly
ordered.
> ============================= Disregard this, the patch does not
> fix it. I decided to keep it in because the problem is still
> possible, but not it's not what's responsible for this specific
> issue.
The issue with this is, because the recieved messages' precision
can be less than the sent messages' precision (`current-time'
returns the time down to milliseconds but servers may choose to
only keep it down to seconds), this causes some issues when a
message is recieved after a message was sent but still within the
same second.
> =============================
An example of this, with the value of the text property
`rcirc-time' at the left of the message itself, is:
> (25469 29640 874652 270000) > 02:13 <thuna`> ,ping
> (25469 29641) > 02:13 <fsbot> ␕
> (25469 29642 502966 649000) > 02:13 <thuna`> ,ping
> (25469 29643) > 02:13 <fsbot> ␕
> (25469 29643 755653 540000) > 02:13 <thuna`> ,ping
> (25469 29644) > 02:13 <fsbot> ␕
> (25469 29645) > 02:13 <fsbot> ␕
> (25469 29645 103860 988000) > 02:13 <thuna`> ,ping
As you can see, the response to the last ping arrived after the ping
itself, but because of the precision difference, rcirc sorted the
messages wrong.
The issue was with `parse-time-string'. It (and by proxy
`parse-iso8601-time-string'), uses `iso8601-parse' with nil FORM,
resulting in the subsecond precision being thrown out. To fix this, I
added FORM arguments to those two functions as well.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#59501
; Package
emacs
.
(Mon, 01 May 2023 12:00:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 59501 <at> debbugs.gnu.org (full text, mbox):
Thuna <thuna.cing <at> gmail.com> writes:
> I have occasionally had replies show before my messages, so I decided
> to look into it. It looks like rcirc looks at the time of the
> message, compares it to the `rcirc-time' text property of other
> messages, and places it so that the property is properly ordered. >
> ============================= Disregard this, the patch does not > fix
> it. I decided to keep it in because the problem is still > possible,
> but not it's not what's responsible for this specific > issue. The
> issue with this is, because the recieved messages' precision can be
> less than the sent messages' precision (`current-time' returns the
> time down to milliseconds but servers may choose to only keep it down
> to seconds), this causes some issues when a message is recieved after
> a message was sent but still within the same second. >
> ============================= An example of this, with the value of
> the text property `rcirc-time' at the left of the message itself, is:
>> (25469 29640 874652 270000) > 02:13 <thuna`> ,ping
>> (25469 29641) > 02:13 <fsbot> ␕
>> (25469 29642 502966 649000) > 02:13 <thuna`> ,ping
>> (25469 29643) > 02:13 <fsbot> ␕
>> (25469 29643 755653 540000) > 02:13 <thuna`> ,ping
>> (25469 29644) > 02:13 <fsbot> ␕
>> (25469 29645) > 02:13 <fsbot> ␕
>> (25469 29645 103860 988000) > 02:13 <thuna`> ,ping
>
> As you can see, the response to the last ping arrived after the ping
> itself, but because of the precision difference, rcirc sorted the
> messages wrong.
>
> The issue was with `parse-time-string'. It (and by proxy
> `parse-iso8601-time-string'), uses `iso8601-parse' with nil FORM,
> resulting in the subsecond precision being thrown out. To fix this, I
> added FORM arguments to those two functions as well.
Sorry for missing this message, this patch looks like the right fix. I
have recently been noticing issues related to this myself.
Would it be OK to apply this to emacs-29?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#59501
; Package
emacs
.
(Mon, 01 May 2023 12:11:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 59501 <at> debbugs.gnu.org (full text, mbox):
> From: Philip Kaludercic <philipk <at> posteo.net>
> Cc: 59501 <at> debbugs.gnu.org, "'Eli Zaretskii'" <eliz <at> gnu.org>
> Date: Mon, 01 May 2023 11:59:57 +0000
>
> Thuna <thuna.cing <at> gmail.com> writes:
>
> > I have occasionally had replies show before my messages, so I decided
> > to look into it. It looks like rcirc looks at the time of the
> > message, compares it to the `rcirc-time' text property of other
> > messages, and places it so that the property is properly ordered. >
> > ============================= Disregard this, the patch does not > fix
> > it. I decided to keep it in because the problem is still > possible,
> > but not it's not what's responsible for this specific > issue. The
> > issue with this is, because the recieved messages' precision can be
> > less than the sent messages' precision (`current-time' returns the
> > time down to milliseconds but servers may choose to only keep it down
> > to seconds), this causes some issues when a message is recieved after
> > a message was sent but still within the same second. >
> > ============================= An example of this, with the value of
> > the text property `rcirc-time' at the left of the message itself, is:
> >> (25469 29640 874652 270000) > 02:13 <thuna`> ,ping
> >> (25469 29641) > 02:13 <fsbot> ␕
> >> (25469 29642 502966 649000) > 02:13 <thuna`> ,ping
> >> (25469 29643) > 02:13 <fsbot> ␕
> >> (25469 29643 755653 540000) > 02:13 <thuna`> ,ping
> >> (25469 29644) > 02:13 <fsbot> ␕
> >> (25469 29645) > 02:13 <fsbot> ␕
> >> (25469 29645 103860 988000) > 02:13 <thuna`> ,ping
> >
> > As you can see, the response to the last ping arrived after the ping
> > itself, but because of the precision difference, rcirc sorted the
> > messages wrong.
> >
> > The issue was with `parse-time-string'. It (and by proxy
> > `parse-iso8601-time-string'), uses `iso8601-parse' with nil FORM,
> > resulting in the subsecond precision being thrown out. To fix this, I
> > added FORM arguments to those two functions as well.
>
> Sorry for missing this message, this patch looks like the right fix. I
> have recently been noticing issues related to this myself.
>
> Would it be OK to apply this to emacs-29?
Yes, but please fix the doc string to not use non-ASCII quotes.
Also, don't forget the Copyright-paperwork-exempt thingy when you
install.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#59501
; Package
emacs
.
(Mon, 01 May 2023 12:17:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 59501 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: 59501 <at> debbugs.gnu.org, "'Eli Zaretskii'" <eliz <at> gnu.org>
>> Date: Mon, 01 May 2023 11:59:57 +0000
>>
>> Thuna <thuna.cing <at> gmail.com> writes:
>>
>> > I have occasionally had replies show before my messages, so I decided
>> > to look into it. It looks like rcirc looks at the time of the
>> > message, compares it to the `rcirc-time' text property of other
>> > messages, and places it so that the property is properly ordered. >
>> > ============================= Disregard this, the patch does not > fix
>> > it. I decided to keep it in because the problem is still > possible,
>> > but not it's not what's responsible for this specific > issue. The
>> > issue with this is, because the recieved messages' precision can be
>> > less than the sent messages' precision (`current-time' returns the
>> > time down to milliseconds but servers may choose to only keep it down
>> > to seconds), this causes some issues when a message is recieved after
>> > a message was sent but still within the same second. >
>> > ============================= An example of this, with the value of
>> > the text property `rcirc-time' at the left of the message itself, is:
>> >> (25469 29640 874652 270000) > 02:13 <thuna`> ,ping
>> >> (25469 29641) > 02:13 <fsbot> ␕
>> >> (25469 29642 502966 649000) > 02:13 <thuna`> ,ping
>> >> (25469 29643) > 02:13 <fsbot> ␕
>> >> (25469 29643 755653 540000) > 02:13 <thuna`> ,ping
>> >> (25469 29644) > 02:13 <fsbot> ␕
>> >> (25469 29645) > 02:13 <fsbot> ␕
>> >> (25469 29645 103860 988000) > 02:13 <thuna`> ,ping
>> >
>> > As you can see, the response to the last ping arrived after the ping
>> > itself, but because of the precision difference, rcirc sorted the
>> > messages wrong.
>> >
>> > The issue was with `parse-time-string'. It (and by proxy
>> > `parse-iso8601-time-string'), uses `iso8601-parse' with nil FORM,
>> > resulting in the subsecond precision being thrown out. To fix this, I
>> > added FORM arguments to those two functions as well.
>>
>> Sorry for missing this message, this patch looks like the right fix. I
>> have recently been noticing issues related to this myself.
>>
>> Would it be OK to apply this to emacs-29?
>
> Yes, but please fix the doc string to not use non-ASCII quotes.
Done,
> Also, don't forget the Copyright-paperwork-exempt thingy when you
> install.
Will do. Thuna: since you have a few other patches as well, would you
be interested in signing the CA so that there are no issues in the
future?
> Thanks.
--
Philip Kaludercic
Reply sent
to
Philip Kaludercic <philipk <at> posteo.net>
:
You have taken responsibility.
(Thu, 04 May 2023 08:08:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Thuna <thuna.cing <at> gmail.com>
:
bug acknowledged by developer.
(Thu, 04 May 2023 08:08:03 GMT)
Full text and
rfc822 format available.
Message #19 received at 59501-done <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Philip Kaludercic <philipk <at> posteo.net>
>> Cc: 59501 <at> debbugs.gnu.org, "'Eli Zaretskii'" <eliz <at> gnu.org>
>> Date: Mon, 01 May 2023 11:59:57 +0000
>>
>> Thuna <thuna.cing <at> gmail.com> writes:
>>
>> > I have occasionally had replies show before my messages, so I decided
>> > to look into it. It looks like rcirc looks at the time of the
>> > message, compares it to the `rcirc-time' text property of other
>> > messages, and places it so that the property is properly ordered. >
>> > ============================= Disregard this, the patch does not > fix
>> > it. I decided to keep it in because the problem is still > possible,
>> > but not it's not what's responsible for this specific > issue. The
>> > issue with this is, because the recieved messages' precision can be
>> > less than the sent messages' precision (`current-time' returns the
>> > time down to milliseconds but servers may choose to only keep it down
>> > to seconds), this causes some issues when a message is recieved after
>> > a message was sent but still within the same second. >
>> > ============================= An example of this, with the value of
>> > the text property `rcirc-time' at the left of the message itself, is:
>> >> (25469 29640 874652 270000) > 02:13 <thuna`> ,ping
>> >> (25469 29641) > 02:13 <fsbot> ␕
>> >> (25469 29642 502966 649000) > 02:13 <thuna`> ,ping
>> >> (25469 29643) > 02:13 <fsbot> ␕
>> >> (25469 29643 755653 540000) > 02:13 <thuna`> ,ping
>> >> (25469 29644) > 02:13 <fsbot> ␕
>> >> (25469 29645) > 02:13 <fsbot> ␕
>> >> (25469 29645 103860 988000) > 02:13 <thuna`> ,ping
>> >
>> > As you can see, the response to the last ping arrived after the ping
>> > itself, but because of the precision difference, rcirc sorted the
>> > messages wrong.
>> >
>> > The issue was with `parse-time-string'. It (and by proxy
>> > `parse-iso8601-time-string'), uses `iso8601-parse' with nil FORM,
>> > resulting in the subsecond precision being thrown out. To fix this, I
>> > added FORM arguments to those two functions as well.
>>
>> Sorry for missing this message, this patch looks like the right fix. I
>> have recently been noticing issues related to this myself.
>>
>> Would it be OK to apply this to emacs-29?
>
> Yes, but please fix the doc string to not use non-ASCII quotes.
>
> Also, don't forget the Copyright-paperwork-exempt thingy when you
> install.
I've pushed the change, closing this report.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 01 Jun 2023 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 322 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.