[PATCH] RunnerManager

[Ryan P. Bitanga]

2008/4/22 Jordi Polo <mumismo at gmail.com>:
>
> On Tue, Apr 22, 2008 at 10:16 PM, Ryan P. Bitanga <ryan.bitanga at gmail.com>
> wrote:
> > 2008/4/21 Aaron J. Seigo <aseigo at kde.org>:
> >
> > > On Monday 21 April 2008, Jordi Polo wrote:
> In fact what I thought was 2 lists:
>
> - priority list
> - black list
>
> As proposed by Aseigo, two constructors can be made, one of them with a
> kconfiggroup object.
>  If the object is used, the application can have its own configuration and
> hence its own priority or black listing.
> Else the application uses global priority set by the user.
> Any runner not in the priority list just no user priority boost
>
> I prefer black list over white list because:
>
> - With a lot of runners (We all hope for this) it will be easier to explicit
> what you don't want and, ok, main reason is because is funnier destroy
> saying what you don't want and see how your not wanted results die :P
>
> - When a new runner is installed by an third party app, it doesn't need to
> touch every configuration file's white list to add itself. It will not in
> the priority list, so no priority boost but at least will display its
> results with no extra configuration.
>
> Yes, you are not either in interface or abstractrunner classes (where I
> stole the code from) . I've already added you.

Great! Thanks :)

> Threadweaver has a queue of jobs. AFAIK, if no dependences are given between
> the jobs are given, it will process the jobs in a FIFO fashion.
> Thinking about it, it appears to me as a more difficult problem as it may
> seem.

You are correct.

>  If runners is ordered and add them to the job queue as they appear in the
> list, . results of faster runners will appear first. Setting dependencies is
> tricky also, as we will have several concurrent threads but the user will
> likely provide a ordered list, comply with that and having concurrent
> processing is difficult ... Priority won't help when one runner is order of
> times slower than other ...

I don't see why a user would expect results to come in a defined order
all the time. The way launchers work is that the matches are
incrementally added. Of course quicker runners will provide matches
first. I don't see this as a problem. In fact, the speed of the runner
may vary from query to query and the only way to have results appear
in a defined order all the time would be to process them sequentially.

On second thought we could add dependencies. Shouldn't be that
difficult. It isn't as tricky as you might think it is.

> So, why not worry very little about runners (just have the list ordered and
> launch them in FIFO) and worry about ordering the results?
>
> That's my ugly double foreach loop in the matches() method that orders only
> when the app request the matches. If the loop is ugly (aseigo already didn't
> like it) it can be change that to inserting the result in the correct
> position each time a match is added to the context.
>  I wait for your comments before doing that.
> Expect a remade patch later today.

I'm not exactly a fan of nested for loops but I'm currently not in a
position to give detailed comments. But again, is precise order that
important? Again it could be possible to sort the results instead.
You'd need a custom operator<. I'll try to provide decent feedback
within the week.

>
> As a side note, I guess I will pretty much cut much of my krunner
> development time in the short future. I applied to GSoC but failed. Meaning
> I should look for a job ASAP and living in Japan, a job means 10-14
> hours/day 6days/week. No much free time left.
>

Ouch, well I haven't had much free time due to my job at a
"multinational consumer consumer goods giant" but at least our
timezones match somewhat. You're an hour ahead of me. :) Also off
topic, what's it like in Japan? I was invited to study in Osaka
University for a year but I'm not to keen on accepting it.

Cheers,
Ryan