all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#37168: debbugs: Make bug list update asynchronous
@ 2019-08-23 21:59 Stefan Kangas
  2019-08-24  7:19 ` Michael Albinus
  0 siblings, 1 reply; 9+ messages in thread
From: Stefan Kangas @ 2019-08-23 21:59 UTC (permalink / raw)
  To: 37168

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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#37168: debbugs: Make bug list update asynchronous
  2019-08-23 21:59 bug#37168: debbugs: Make bug list update asynchronous Stefan Kangas
@ 2019-08-24  7:19 ` Michael Albinus
  2019-08-24 12:47   ` Stefan Kangas
  2022-05-25 19:02   ` Stefan Kangas
  0 siblings, 2 replies; 9+ messages in thread
From: Michael Albinus @ 2019-08-24  7:19 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 37168

Stefan Kangas <stefan@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.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#37168: debbugs: Make bug list update asynchronous
  2019-08-24  7:19 ` Michael Albinus
@ 2019-08-24 12:47   ` Stefan Kangas
  2019-08-24 14:40     ` Michael Albinus
  2022-05-25 19:02   ` Stefan Kangas
  1 sibling, 1 reply; 9+ messages in thread
From: Stefan Kangas @ 2019-08-24 12:47 UTC (permalink / raw)
  To: Michael Albinus; +Cc: 37168

Michael Albinus <michael.albinus@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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#37168: debbugs: Make bug list update asynchronous
  2019-08-24 12:47   ` Stefan Kangas
@ 2019-08-24 14:40     ` Michael Albinus
  2019-08-24 14:47       ` Stefan Kangas
  0 siblings, 1 reply; 9+ messages in thread
From: Michael Albinus @ 2019-08-24 14:40 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 37168

Stefan Kangas <stefan@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.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#37168: debbugs: Make bug list update asynchronous
  2019-08-24 14:40     ` Michael Albinus
@ 2019-08-24 14:47       ` Stefan Kangas
  2019-08-24 18:28         ` Michael Albinus
  0 siblings, 1 reply; 9+ messages in thread
From: Stefan Kangas @ 2019-08-24 14:47 UTC (permalink / raw)
  To: Michael Albinus; +Cc: 37168

Michael Albinus <michael.albinus@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





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#37168: debbugs: Make bug list update asynchronous
  2019-08-24 14:47       ` Stefan Kangas
@ 2019-08-24 18:28         ` Michael Albinus
  0 siblings, 0 replies; 9+ messages in thread
From: Michael Albinus @ 2019-08-24 18:28 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 37168

Stefan Kangas <stefan@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.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#37168: debbugs: Make bug list update asynchronous
  2019-08-24  7:19 ` Michael Albinus
  2019-08-24 12:47   ` Stefan Kangas
@ 2022-05-25 19:02   ` Stefan Kangas
  2022-05-25 19:10     ` Michael Albinus
  2024-09-20 10:09     ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 2 replies; 9+ messages in thread
From: Stefan Kangas @ 2022-05-25 19:02 UTC (permalink / raw)
  To: Michael Albinus; +Cc: 37168

Michael Albinus <michael.albinus@gmx.de> writes:

> Stefan Kangas <stefan@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?





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#37168: debbugs: Make bug list update asynchronous
  2022-05-25 19:02   ` Stefan Kangas
@ 2022-05-25 19:10     ` Michael Albinus
  2024-09-20 10:09     ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 0 replies; 9+ messages in thread
From: Michael Albinus @ 2022-05-25 19:10 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 37168-done

Stefan Kangas <stefan@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.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#37168: debbugs: Make bug list update asynchronous
  2022-05-25 19:02   ` Stefan Kangas
  2022-05-25 19:10     ` Michael Albinus
@ 2024-09-20 10:09     ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 0 replies; 9+ messages in thread
From: Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-09-20 10:09 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: 37168

Stefan Kangas <stefan@marxist.se> writes:

Hi Stefan,

>>> 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?

FTR, I've released debbugs 0.41, which uses threads.

Best regards, Michael.





^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2024-09-20 10:09 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2019-08-23 21:59 bug#37168: debbugs: Make bug list update asynchronous Stefan Kangas
2019-08-24  7:19 ` Michael Albinus
2019-08-24 12:47   ` Stefan Kangas
2019-08-24 14:40     ` Michael Albinus
2019-08-24 14:47       ` Stefan Kangas
2019-08-24 18:28         ` Michael Albinus
2022-05-25 19:02   ` Stefan Kangas
2022-05-25 19:10     ` Michael Albinus
2024-09-20 10:09     ` Michael Albinus via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.