> 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. 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 :)
