On Jan 21, 2008 2:17 AM, Christiaan Hofman <[EMAIL PROTECTED]> wrote:

>
> On 21 Jan 2008, at 1:28 AM, Adam R. Maxwell wrote:
>
> >
> > On Jan 20, 2008, at 4:14 PM, Christiaan Hofman wrote:
> >
> >>
> >> On 21 Jan 2008, at 1:12 AM, Adam R. Maxwell wrote:
> >>
> >>>
> >>> On Jan 20, 2008, at 4:00 PM, Christiaan Hofman wrote:
> >>>
> >>>>
> >>>> On 21 Jan 2008, at 12:53 AM, Adam R. Maxwell wrote:
> >>>>
> >>>>>
> >>>>> On Jan 20, 2008, at 3:46 PM, Christiaan Hofman wrote:
> >>>>>
> >>>>>>>>> True; the unarchiving can be done on the thread, though,
> >>>>>>>>> after -
> >>>>>>>>> init
> >>>>>>>>> has returned.  It would just cut down on overhead in case of
> >>>>>>>>> multiple
> >>>>>>>>> huge indexes stored on disk, so you wouldn't have to read all
> >>>>>>>>> of
> >>>>>>>>> them
> >>>>>>>>> fully in order to find the right one.
> >>>>>>>>
> >>>>>>>> Of course unarchiving on the thread would mean creating the
> >>>>>>>> index on
> >>>>>>>> the thread. And then we need safeguards in -index. (in the
> >>>>>>>> cancel
> >>>>>>>> method the lock is probably sufficient).
> >>>>>>>
> >>>>>>> I'd say just creating it as a local variable and then assigning
> >>>>>>> to
> >>>>>>> the
> >>>>>>> ivar when it's done is sufficient.  The BDSKSearch now ignores a
> >>>>>>> NULL
> >>>>>>> index (but it won't get any delegate messages until the index is
> >>>>>>> fully
> >>>>>>> created anyway), so -index should be fine as-is.
> >>>>>>
> >>>>>> No that does not work. Apart from a failing OBPOSTCONDITION and a
> >>>>>> log, sometimes it does nothing.
> >>>>>
> >>>>> What does not work?  And what sometimes does nothing?
> >>>>
> >>>>
> >>>> Creating the index in buildIndex... does not work. Sometimes there
> >>>> just happens nothing: no indexing, at least the UI does not show
> >>>> the
> >>>> progress bar and nothing appears in the table. Also if I remove the
> >>>> OBPOSTCONDITION.
> >>>
> >>> I don't understand that.  Is it raising an exception somewhere?  The
> >>> OBPOSTCONDITION is just a harmless log message.
> >>>
> >>> If I move all the index creation stuff from -init to
> >>> buildIndexForItems: and make the document an ivar to get its URL
> >>> (not
> >>> safe, I know), it works fine.  No postcondition log, progress bar
> >>> works, and results show up in the table.
> >>
> >> For me sometimes it does, and sometimes it doesn't.
> >
> > That sounds most peculiar; I've tried several times here and it
> > works.  Have you verified that your indexData and index ivars are non-
> > NULL before if ([signatures count])?  And that buildIndexForItems:
> > gets called every time?
>
> The problem is in BDSKFileSearch. When the index is NULL *which can
> happen when it is created in the thread) the SKSearch is not created,
> and the delegate method does nothing.
>
> Christiaan
>
>
> Moreover [searchIndex isIndexing] returns NO in that case, and the search
will send a didFinishWithResults: delegate method, which hides the progress
bar. So the whole logic of the delegate methods in BDSKFileSearch is wrong
when the index can be NULL.

Christiaan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bibdesk-develop mailing list
Bibdesk-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bibdesk-develop

Reply via email to