-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jonathon Jongsma a écrit : > > Yeah, it could be worth doing some profiling again, but I think it's > inevitable that some parsing operations may take a long time, especially > for very large C++ programs.
Yes, of course. But still, many seconds, on current beefed up machines, to parse the list of files seems too much to me. Unless the gdb output represents some gigabytes of ram. And I doubt that. When I have time I'll try to profile that and see what I can do. > So I think it would be nice to have a > reasonable solution for this issue, even if we manage to get specific > cases optimized. Yeah, I was not arguing against that :) > > So, my first reaction to this idea is that it will basically get the job > done and it's not too ugly. However, there are a couple issues / > questions I have with it. > > First, it really only works for parsing operations. For instance, > consider the file list operation (the case that caused me to think about > this issue in the first place). The file list operation has two > distinct parts: the first part where gdb actually gathers the list of > files and spits it out to the io channel, and the second part where we > parse the output of gdb and build it up into a list that we pass back to > the application. Imagine (i'm using arbitrary numbers just for > illustration here) that the first part where gdb gathers the list of > files takes 5 seconds, and the second part where we parse and build the > list also takes 5 seconds. So for the first 5 seconds of the operation, > we will not be blocking, but we won't be emitting any progress pulses > (since we're not doing anything -- we're just waiting for output). Sure, I am aware of that. Idealy, I think gdb should notify us about its progress. That would let us adress this issue in a direct and consistent way with what I was proposing. > For the second 5 seconds we'd be parsing output and emitting progress pulses > periodically. So we've solved the problem of blocking the UI, but the > application user experience is a little bit inconsistent. Because if we > want a progress bar to pulse for the entire 10 seconds (instead of just > the last 5 seconds), we have to find a slightly different approach. Well, We have IDebugger::command_done_signal() that is emitted right after IDebugger sends the command GDB, if GDB acknowledges the command. So I *think* we could just start pulsing when we receive the IDebugger::command_done_signal. I think that would work, but would be hackish until GDB can really notify us about its progress. > The other question I have about the above API is how to associate a > certain progress event with a particular operation. Perhaps all > debugger operations that can notify about progress can return a progress > notifier object or something, e.g.: > > virtual ISomeNotifierSafePtr list_files (const UString &); > > And then if you want to be notified of progress you can connect to its > signals. I'm not sure how the internal implementation of this would > work, but it seems like a reasonably clean API to me. what do you think? The way i see it is to have some possible long operations be invoked through an API that ressembles: void IDebugger::do_long_operation (sigc::slot<void, void> &a_notification_slot); a_notification_slot would be the slot invoked to notify the progress. For the sake of simplicity, I choosed sigc::slot<void, void> in this exemple, but it could be a slot that has got a more useful signature, I guess. I am currently playing with the support of variable object, and I have introduced that kind of API to easy the code of the client side (not for notification purposes though), and it looks interesting. You can have a feeling of how to use it by looking at the code of the function on_variable_created_signal2 at http://git.gnome.org/cgit/nemiver/tree/tests/test-vars.cc?h=varobjs-support. More on that later. I need to thinker with the code a little more before being fully sure :) Thanks. Dodji. - -- Tant que l'on n'a pas la tête coupée, on peut espérer mettre un chapeau. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Remi - http://enigmail.mozdev.org iEYEARECAAYFAknYt+kACgkQPejI7lrem2H40ACfftOxSE/ysGUGF2uVYqoKyFXs NRcAnjBo39h96maYEccEwnvdX8Or6G33 =DEhe -----END PGP SIGNATURE----- _______________________________________________ nemiver-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/nemiver-list
