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)
      (in Sock (rd))
         (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 ()
   (task (port (+ *IdxNum 4040))
      (let? Sock (accept @)
         (unless (fork)
            (in Sock
               (while (rd)
                  (out Sock
                     (eval @))))
         (close Sock)))

On Mon, May 10, 2010 at 9:50 AM, Alexander Burger <> wro=
> 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
> --

Reply via email to