> On 29 May 2015, at 18:23, Henrik Johansen <henrik.s.johan...@veloxit.no> > wrote: > >> >> On 19 May 2015, at 11:01 , Sven Van Caekenberghe <s...@stfx.eu> wrote: >> >> >>> On 19 May 2015, at 10:53, Udo Schneider <udo.schnei...@homeaddress.de> >>> wrote: >>> >>>> Did you look in all your package caches ? >>> I did. Must have been a victim of cleaning ... but maybe TimeMachine has >>> something ... thanks for the reminder. >>> >>>> If it is just a small example, like one class, maybe it could be >>>> added to the image, in which case it should indeed be a slice. >>> The package was pretty simple. Basically only adding a few convenience >>> methods around Socket>>#setOption:value: . Still I think a usage example in >>> form of a class comment and test case might be appropriate. So unless >>> Multicast should be part of the base image I'll start with a separate >>> package first. >> >> Since Socket is a fundamental part, and multicast is a key feature, I think >> it would logical to move it to the image itself, with a test case. > > It's not just multicast... > As a Socket newbie I recently spent longer than I care to admit learning you > need to set SO_BROADCAST to true to not get a primitive failure when sending > to a broadcast address. > At least the comments in sqUnixSocket were entertaining! > > Though I realize which options are actually supported depends on the VM, > moving the list of potentially available cross-platform options (and a > description of what they're used for) to a comment in the image (setOption: > value: being the obvious location) might be a nice first step.
Please help in the documentation effort. > Cheers, > Henry > > P.S. On the plus side, I'm now able to turn my PC into a better remote for > multi-cam GoPro setups than the GoPro remote itself is :) I am sure you will blog about this !
