[usocket-devel] Questions about exported symbols...

[Chun Tian (binghe)]

Hi Patrick

Thanks for your suggestion.  I'll try to fix GET-HOST-BY-NAME for ECL to support non-Windows platforms soon.

I think it's reasonable to export more interfaces for WAIT-FOR-INPUT to make it more efficiency for advanced users, but some of exist symbols (i.e. STATE) may be too simple that it could be conflict with other packages or user application, therefore I'm thinking a prefix WFI- or just WAIT- for all these potential new exports. Do you have any suggestion?

Regards,

Chun Tian (binghe)

On 2013-04-05, at 3:20, Patrick Stein <pat at nklein.com> wrote:

> 
> I keep hoping that #'GET-HOST-BY-NAME will be exported from USocket.  In poking around trying to see how hard that would be, it looks to me like the only backend that doesn't currently support it is ECL.  And, that backend only supports ECL under Windows as it is.
> 
> If I spend some time getting GET-HOSTS-BY-NAME working for ECL on Windows (and other systems), can we make GET-HOSTS-BY-NAME a non-optional feature of the backends and export GET-HOST-BY-NAME and some of its friends?
> 
> 
> Also, I just looked through WAIT-FOR-INPUT trying to see the most efficient way that I can employ that function.  It looks like if I used MAKE-WAIT-LIST, ADD-WAITER, and REMOVE-WAITER in my code, then I could pass the wait-list into WAIT-FOR-INPUT so it doesn't have to construct one itself.  That'd be nice.  All of those functions are exported, but WAIT-LIST-WAITERS is not.  So, I would still need to either maintain a separate copy of the WAITERS for myself or use the :READY-ONLY option.  Can we export WAIT-LIST-WAITERS?
> 
> On a similar note, even given the whole list of WAITERS, I still need to use the unexpected STATE function to get the waiting state of each socket.  I'd propose adding a predicate that checks whether the state is :READ or :READ-WRITE.  Or, we export STATE?  Or some reader for that state?  Or some predicate that returns true if the state is :READ?
> 
> 
> I'll gladly work on the above and submit patches if there's consensus….
> 
> Thanks,
> Patrick
> 
> 
> _______________________________________________
> usocket-devel mailing list
> usocket-devel at common-lisp.net
> http://lists.common-lisp.net/cgi-bin/mailman/listinfo/usocket-devel