A note about git usage: actually we just used git like we used svn. That was totally wrong. We should have created a branch and figured the feature out in there. Then either merge it or even create one patch from the branch and apply that to master.
Cheers, Sebastian On 03/16/2011 03:43 PM, Vishesh Handa wrote: > > > On Wed, Mar 16, 2011 at 8:01 PM, Sebastian Trüg <tr...@kde.org > <mailto:tr...@kde.org>> wrote: > > On 03/16/2011 03:20 PM, Vishesh Handa wrote: > > > > > > On Wed, Mar 16, 2011 at 7:37 PM, Sebastian Trüg <tr...@kde.org > <mailto:tr...@kde.org> > > <mailto:tr...@kde.org <mailto:tr...@kde.org>>> wrote: > > > > OK, so we only need a stopQuery() in the setQuery method, > right? IMHO > > that is much cleaner and easier to understand than setting > current query > > to 0. > > > > > > That too won't work. Here is why - > > > > You run a query A, it finishes executing itself and then deletes > itself. > > You then run query B, it will try to stop query A by deleting it. But > > since it has already been deleted - Crash. > > i dont think so. The query deletes itself async and before that emits > the finished signal which results in m_currentQuery being set to 0.... > aha, that is what is missing! > > > I tried that. The problem is that I still gets 1 result from the old query. > Try it out - > run - select ?r where { ?r nie:url ?url . } > and then - > select ?url where { ?r nie:url ?url . } LIMIT 10 > while the first query is still running. > > > > The only way I could think of solving this was by checking if the > query > > we were getting results for was the m_currentQuery, and otherwise > > deleting it. That code was removed in the patch provided. > > > > > > On 03/16/2011 02:58 PM, Vishesh Handa wrote: > > > This patch ( now committed ) is not that useful. > > > > > > The only thing it does is sets the time elapsed when you > click the > > "Stop > > > Query" button. And it removes the old code which allowed you to > > > automatically stop the old query if you ran a new one. > > > > > > When a query finishes execution, or is closed, it automatically > > deletes > > > itself and therefore disconnects itself from all signals and > slots. > > > > > > I know the setting of 'd->m_currentQuery = 0' was not completely > > > obvious. But it did what it was supposed to. The query if it > was still > > > being executed would have been deleted when more results > were received > > > in slotNextResultReady() > > > > > > I'll either revert this patch or fix it. > > > > > > On Wed, Mar 16, 2011 at 4:37 PM, Who Knows <who...@gmail.com > <mailto:who...@gmail.com> > > <mailto:who...@gmail.com <mailto:who...@gmail.com>> > > > <mailto:who...@gmail.com <mailto:who...@gmail.com> > <mailto:who...@gmail.com <mailto:who...@gmail.com>>>> wrote: > > > > > > The previous patch affected the copyright somehow so i am > > sending a > > > new one. > > > > > > > > > - Smit Shah (My real name) > > > > > > _______________________________________________ > > > Nepomuk mailing list > > > Nepomuk@kde.org <mailto:Nepomuk@kde.org> > <mailto:Nepomuk@kde.org <mailto:Nepomuk@kde.org>> > > <mailto:Nepomuk@kde.org <mailto:Nepomuk@kde.org> > <mailto:Nepomuk@kde.org <mailto:Nepomuk@kde.org>>> > > > https://mail.kde.org/mailman/listinfo/nepomuk > > > > > > > > > > > > > > > -- > > > Vishesh Handa > > > > > > > > > > > > _______________________________________________ > > > Nepomuk mailing list > > > Nepomuk@kde.org <mailto:Nepomuk@kde.org> > <mailto:Nepomuk@kde.org <mailto:Nepomuk@kde.org>> > > > https://mail.kde.org/mailman/listinfo/nepomuk > > _______________________________________________ > > Nepomuk mailing list > > Nepomuk@kde.org <mailto:Nepomuk@kde.org> > <mailto:Nepomuk@kde.org <mailto:Nepomuk@kde.org>> > > https://mail.kde.org/mailman/listinfo/nepomuk > > > > > > > > > > -- > > Vishesh Handa > > > > > -- > Vishesh Handa _______________________________________________ Nepomuk mailing list Nepomuk@kde.org https://mail.kde.org/mailman/listinfo/nepomuk
