2010/1/4 Doriano Blengino <doriano.bleng...@fastwebnet.it>:

> the normal syntax implies that the value you read is
> available just after; in this case, one should "declare" that he wants
> to read a line,

YES! YES! YES!

Pardon my excitement.

> The timeout, as seen in this discussion, could be settable for error
> raising purposes, and the blocking mode is handy to write simple
> programs without event management.

Yes, again.

> Just now I am writing a program which interfaces with gdb using pipes -
> this can be a good test to explore my idea; in fact I tried at first
> with blocking mode; then, not happy, tried non blocking mode with
> events; but trying to read whole lines of text does not work the way I
> want because still I find myself writing cycles, so I will try with this
> tecnique (an event raised when the operation requested has completed).

I had a similar problem implementing RFC 3977 in gb3; funny enough,
IIRC, it worked perfectly in gb2, I should install gb2 and test it. I
send a request to the remote server for certain data and in return I
expect a single line from the remote server telling me that the data I
requested follows. That line tells me that a) the server has the data
I want, and b) to get ready to receive it. In all cases, the data
would crash into the response line so that I lost data on the next
read. That is, when the response line was read, it contained the
response and data after the response. I gave up.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Gambas-user mailing list
Gambas-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gambas-user

Reply via email to