My code simply stops executing (as if waiting for the next entry but
it never gets it) when I run out of entries to fetch, really strange
and a traceAll confirms this, the last output is a call to rd1>.
I know for a fact that 2 results should be returned but then when I
try to fetch the third and think I should get NIL something goes
really wrong, some race condition or a never ending wait for something
that refuses to happen.
This is my rd1>:
(dm rd1> (Sock)
(or
(in Sock (rd))
(nil
(close Sock))))
And on the remote:
(de getArticles (W)
(for Wc (sortBy> '+Gh (collect 'word '+WordCount W) 'picoStamp)
(pr (cons (; Wc article) (; Wc picoStamp)))
(unless (flush) (bye))))
And the go of the remote:
(de go ()
..
(rollback)
(task (port (+ *IdxNum 4040))
(let? Sock (accept @)
(unless (fork)
(in Sock
(while (rd)
(sync)
(out Sock
(eval @))))
(bye))
(close Sock)))
(forked))
On Mon, May 10, 2010 at 9:50 AM, Alexander Burger <a...@software-lab.de> wro=
te:
> On Mon, May 10, 2010 at 09:04:48AM +0200, Henrik Sarvell wrote:
>> Ah I see, so the issue is on the remote side then, what did your code
>> look like there, did you use (prove)?
>
> There were several scenarios. In cases where only a few hits are to be
> expected, I used 'collect':
>
> =A0 (for Obj (collect 'var '+Cls (...))
> =A0 =A0 =A0(pr Obj)
> =A0 =A0 =A0(unless (flush) (bye)) )
>
> The 'flush' is there for two purposes: (1) to get the data sent
> immediately (without holding in a local buffer), and (2) to have an
> immediate feedback. When the receiving side should close the connection
> (i.e. the GUI is not interested in more results, or the client has
> quit), 'flush' returns NIL and the local query can be terminated.
>
>
> In other cases, where there were potentially many hits (so that I didn't
> want to use 'collect'), I used the low-level tree iteration function
> 'iter' (which is also internally by 'collect'):
>
> =A0 (iter (tree 'var '+Cls)
> =A0 =A0 =A0'((Obj)
> =A0 =A0 =A0 =A0 (pr Obj)
> =A0 =A0 =A0 =A0 (unless (flush) (bye)) )
> =A0 =A0 =A0(cons From)
> =A0 =A0 =A0(cons Till T) )
> =A0 (bye) )
>
> So 'iter' is quite efficient, as it avoids the overhead of Pilog, but
> still can deliver an unlimited number of hits.
>
> Note, however, that you have to pass the proper 'from' and 'till'
> arguments. They must have the right structure of the index tree's key.
> For a '+Key' index this would be simply 'From' and 'Till'. For a '+Ref'
> (like in the shown case) it must be '(From . NIL)' and '(Till . T)'.
> 'db', 'collect' and the Pilog functions take care of such details
> automatically.
>
>
> For complexer queries, involving more than one index, yes, I used Pilog
> and 'prove'. Each call to 'prove' returns (and sends) a single object.
>
>
> For plain Pilog queries, i.e. without any special requirements like a
> defined sorting order, you can get along even without any custom
> functions/methods on the remote side. The 'remote/2' predicate can
> handle this transparently by executing its clauses on all remote
> machines. I have examples for that, but they are probably beyond the
> scope of this mail.
>
> Cheers,
> - Alex
> --
> UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=3dunsubscribe
>
--
UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe
