GNU bug report logs -
#37168
debbugs: Make bug list update asynchronous
Previous Next
Reported by: Stefan Kangas <stefan <at> marxist.se>
Date: Fri, 23 Aug 2019 22:00:02 UTC
Severity: wishlist
Done: Michael Albinus <michael.albinus <at> gmx.de>
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 37168 in the body.
You can then email your comments to 37168 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#37168
; Package
emacs
.
(Fri, 23 Aug 2019 22:00:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stefan Kangas <stefan <at> marxist.se>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 23 Aug 2019 22:00:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Severity: wishlist
When I type:
M-x debbugs-gnu RET ,minor,wishlist RET
It takes a long time to load on my machine, and it freezes my entire
Emacs session while I wait. It would be very nice if this operation
could be made to work asynchronously.
Thanks,
Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37168
; Package
emacs
.
(Sat, 24 Aug 2019 07:20:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 37168 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> marxist.se> writes:
> When I type:
>
> M-x debbugs-gnu RET ,minor,wishlist RET
>
> It takes a long time to load on my machine, and it freezes my entire
> Emacs session while I wait. It would be very nice if this operation
> could be made to work asynchronously.
Bug retrieving happens in two phases. The first phase, getting the bug
numbers in question, cannot be performed asynchronously, because it is
just one request to the debbugs server.
The second phase, getting information per bug number, happens already
asynchronously. The debbugs server is requested to return maximum
debbugs-max-hits-per-request per request; several requests are sent in
parallel to the server. Furthermore, debbugs caches the results, so the
next time information for an already known bug number is taken from the
cache.
However, debbugs waits until all parallel requests have been served by
the debbugs server, before it begins to show the tabulated list. This
might be done asynchronously as well. Will check, what's possible.
> Thanks,
> Stefan Kangas
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37168
; Package
emacs
.
(Sat, 24 Aug 2019 12:48:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 37168 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Bug retrieving happens in two phases. The first phase, getting the bug
> numbers in question, cannot be performed asynchronously, because it is
> just one request to the debbugs server.
Would url-retrieve work for this?
(url-retrieve URL CALLBACK &optional CBARGS SILENT INHIBIT-COOKIES)
"Retrieve URL asynchronously and call CALLBACK with CBARGS when finished."
> However, debbugs waits until all parallel requests have been served by
> the debbugs server, before it begins to show the tabulated list. This
> might be done asynchronously as well. Will check, what's possible.
Sounds good, thanks.
Best regards,
Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37168
; Package
emacs
.
(Sat, 24 Aug 2019 14:41:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 37168 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> marxist.se> writes:
Hi Stefan,
>> Bug retrieving happens in two phases. The first phase, getting the bug
>> numbers in question, cannot be performed asynchronously, because it is
>> just one request to the debbugs server.
>
> Would url-retrieve work for this?
Nope. debbugs.el uses the SOAP interface of the debbugs server.
> Best regards,
> Stefan Kangas
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37168
; Package
emacs
.
(Sat, 24 Aug 2019 14:48:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 37168 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> >> Bug retrieving happens in two phases. The first phase, getting the bug
> >> numbers in question, cannot be performed asynchronously, because it is
> >> just one request to the debbugs server.
> >
> > Would url-retrieve work for this?
>
> Nope. debbugs.el uses the SOAP interface of the debbugs server.
Thanks. I'm not sure if I'm missing something obvious here, but...
What about soap-invoke-async?
Best regards,
Stefan Kangas
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37168
; Package
emacs
.
(Sat, 24 Aug 2019 18:29:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 37168 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> marxist.se> writes:
Hi Stefan,
>> >> Bug retrieving happens in two phases. The first phase, getting the bug
>> >> numbers in question, cannot be performed asynchronously, because it is
>> >> just one request to the debbugs server.
>> >
>> > Would url-retrieve work for this?
>>
>> Nope. debbugs.el uses the SOAP interface of the debbugs server.
>
> Thanks. I'm not sure if I'm missing something obvious here, but...
> What about soap-invoke-async?
This is performed already. As I wrote, the second request, retrieving
information about (severeal hundred of) bugs, is applied asynchronously,
using `soap-invoke-async'. See `debbugs-get-status'.
> Best regards,
> Stefan Kangas
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#37168
; Package
emacs
.
(Wed, 25 May 2022 19:03:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 37168 <at> debbugs.gnu.org (full text, mbox):
Michael Albinus <michael.albinus <at> gmx.de> writes:
> Stefan Kangas <stefan <at> marxist.se> writes:
>
>> When I type:
>>
>> M-x debbugs-gnu RET ,minor,wishlist RET
>>
>> It takes a long time to load on my machine, and it freezes my entire
>> Emacs session while I wait. It would be very nice if this operation
>> could be made to work asynchronously.
>
> Bug retrieving happens in two phases. The first phase, getting the bug
> numbers in question, cannot be performed asynchronously, because it is
> just one request to the debbugs server.
>
> The second phase, getting information per bug number, happens already
> asynchronously. The debbugs server is requested to return maximum
> debbugs-max-hits-per-request per request; several requests are sent in
> parallel to the server. Furthermore, debbugs caches the results, so the
> next time information for an already known bug number is taken from the
> cache.
>
> However, debbugs waits until all parallel requests have been served by
> the debbugs server, before it begins to show the tabulated list. This
> might be done asynchronously as well. Will check, what's possible.
Any news regarding this? If no progress is possible here, perhaps the
bug should be closed. WDYT?
Reply sent
to
Michael Albinus <michael.albinus <at> gmx.de>
:
You have taken responsibility.
(Wed, 25 May 2022 19:11:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Stefan Kangas <stefan <at> marxist.se>
:
bug acknowledged by developer.
(Wed, 25 May 2022 19:11:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 37168-done <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefan <at> marxist.se> writes:
Hi Stefan,
>> Bug retrieving happens in two phases. The first phase, getting the bug
>> numbers in question, cannot be performed asynchronously, because it is
>> just one request to the debbugs server.
>>
>> The second phase, getting information per bug number, happens already
>> asynchronously. The debbugs server is requested to return maximum
>> debbugs-max-hits-per-request per request; several requests are sent in
>> parallel to the server. Furthermore, debbugs caches the results, so the
>> next time information for an already known bug number is taken from the
>> cache.
>>
>> However, debbugs waits until all parallel requests have been served by
>> the debbugs server, before it begins to show the tabulated list. This
>> might be done asynchronously as well. Will check, what's possible.
>
> Any news regarding this? If no progress is possible here, perhaps the
> bug should be closed. WDYT?
No, nothing happened. And since there aren't no further complaints from
other users, I believe we could leave it as it is. Closing the bug.
Best regards, Michael.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 23 Jun 2022 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 279 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.