Thanks henrik
A better API would be so great.
Stef
Le 1/6/15 15:18, Henrik Johansen a écrit :
On 29 May 2015, at 7:24 , Sven Van Caekenberghe wrote:
On 29 May 2015, at 18:23, Henrik Johansen wrote:
On 19 May 2015, at 11:01 , Sven Van Caekenberghe wrote:
On 19 May 2015, at 10:53, Udo
oh yes!
+ 10
Le 19/5/15 10:20, Sven Van Caekenberghe a écrit :
Hi Udo,
It would be good if some of this knowledge could be added inside the image, as
class comment or methods comments. Even better would be an example combined
with a unit test, like UDPSocketEchoTest and TCPSocketEchoT
> On 29 May 2015, at 7:24 , Sven Van Caekenberghe wrote:
>
>
>> On 29 May 2015, at 18:23, Henrik Johansen
>> wrote:
>>
>>>
>>> On 19 May 2015, at 11:01 , Sven Van Caekenberghe wrote:
>>>
>>>
On 19 May 2015, at 10:53, Udo Schneider
wrote:
> Did you look in all your p
On Sat, May 30, 2015 at 12:23 AM, Henrik Johansen
wrote:
> 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 :)
That is cool to hear. Now as much as frameworks are important, I
think cool little end-user apps like
Sven Van Caekenberghe-2 wrote
> I am sure you will blog about this !
Yes, pleeease!!
-
Cheers,
Sean
--
View this message in context:
http://forum.world.st/Issue-with-UDP-Sockets-tp4827014p4829352.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
> On 29 May 2015, at 18:23, Henrik Johansen
> wrote:
>
>>
>> On 19 May 2015, at 11:01 , Sven Van Caekenberghe wrote:
>>
>>
>>> On 19 May 2015, at 10:53, Udo Schneider
>>> wrote:
>>>
Did you look in all your package caches ?
>>> I did. Must have been a victim of cleaning ... but mayb
> On 19 May 2015, at 11:01 , Sven Van Caekenberghe wrote:
>
>
>> On 19 May 2015, at 10:53, Udo Schneider 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 your mDNS code available somewhere? I thought about that some time
ago that it could be a nice way to announce a pharo service to the
network. Or in my case using it as a foundation for orchestrating images.
No it's not in form a ready to go package. I'd have to check whether I
saved the Wo
Hi Udo,
is your mDNS code available somewhere? I thought about that some time ago that
it could be a nice way to announce a pharo service to the network. Or in my
case using it as a foundation for orchestrating images.
Norbert
> Am 19.05.2015 um 10:30 schrieb Udo Schneider :
>
> Hi Sven,
>
>
> On 19 May 2015, at 10:53, Udo Schneider 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
> 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 pac
> On 19 May 2015, at 10:30, Udo Schneider wrote:
>
> Hi Sven,
>
> you got me :-)
>
> I had this as a package sometime ago for my own purposes (mDNS). So I knew it
> does work and how to do it. It's just I can't find that damned package
> anymore...
Did you look in all your package caches ?
Hi Sven,
you got me :-)
I had this as a package sometime ago for my own purposes (mDNS). So I
knew it does work and how to do it. It's just I can't find that damned
package anymore...
> I do think making all this cross platform could be a bit harder,
we'll see.
It's not that hard. The socke
Hi Udo,
It would be good if some of this knowledge could be added inside the image, as
class comment or methods comments. Even better would be an example combined
with a unit test, like UDPSocketEchoTest and TCPSocketEchoTest - the unit test
would then actively ensure this functionality is prot
True - having Wireshark is always a good idea. Just a warning in the
multicast context though:
The fact that Wireshark sees multicast datagrams (when recieving) does
only imply that your NIC is in promiscuous mode or that /a/ process on
the node did subscribe to the multicast group. It does not
Ultimate fallback, use Wireshark to compare packets on the wire between
using node.js and Pharo.
http://en.wikiversity.org/wiki/Wireshark/IPv4_multicast
cheers -ben
On Tue, May 19, 2015 at 6:17 AM, Udo Schneider wrote:
> This should have been 'IP_ADD_MEMBERSHIP' of course:
>
> imrMultiaddr := #[
This should have been 'IP_ADD_MEMBERSHIP' of course:
imrMultiaddr := #[239 255 255 250].
imrInterface := #[0 0 0 0].
ipMreq := imrMultiaddr , imrInterface.
socket setOption: 'IP_ADD_MEMBERSHIP' value: ipMreq.
The "server" could be something like this (execute in first playground).
I used anoth
Hello Udo,
thanks for your detailed reply.
I am going to try your suggestions and report back afterwards.
Not sure though if I get to try it before next weekend.
The address I am sending to is definitely a multi-cast address (as defined
in the SSDP spec).
But what makes me wonder is why the minim
Hi Manfred,
I just stumbled over the IP address you are using (239.255.255.250). If
I remember correctly this is a IPv4 Class D Multicast address.
(224.0.0.0-239.255.255.255).
So if you want to transmit datagrams to this IP address or recieve
datagrams sent to this multicast groups you have
Hupps, was reading the old code, I guess this isn't applicable.
Sorry :/
> On 18 May 2015, at 5:15 , Henrik Johansen
> wrote:
>
>
>> On 18 May 2015, at 4:44 , Sven Van Caekenberghe wrote:
>>
>>
>>> On 18 May 2015, at 16:34, Manfred Kröhnert
>>> wrote:
>>>
>>> Hi Sven,
>>>
>>> On Mon, Ma
> On 18 May 2015, at 4:44 , Sven Van Caekenberghe wrote:
>
>
>> On 18 May 2015, at 16:34, Manfred Kröhnert
>> wrote:
>>
>> Hi Sven,
>>
>> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe wrote:
>>
>>> On 18 May 2015, at 15:47, Manfred Kröhnert
>>> wrote:
>>>
>>> Hi,
>>> apparentl
> On 18 May 2015, at 16:34, Manfred Kröhnert
> wrote:
>
> Hi Sven,
>
> On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe wrote:
>
> > On 18 May 2015, at 15:47, Manfred Kröhnert
> > wrote:
> >
> > Hi,
> > apparently I am missing something else.
> >
> > I can find devices when connected
Hi Sven,
On Mon, May 18, 2015 at 4:14 PM, Sven Van Caekenberghe wrote:
>
> > On 18 May 2015, at 15:47, Manfred Kröhnert
> wrote:
> >
> > Hi,
> > apparently I am missing something else.
> >
> > I can find devices when connected to a 'regular' LAN.
> >
> > However, I have a camera that creates a
> On 18 May 2015, at 15:47, Manfred Kröhnert
> wrote:
>
> Hi,
> apparently I am missing something else.
>
> I can find devices when connected to a 'regular' LAN.
>
> However, I have a camera that creates a Wifi accesspoint and makes itself
> discoverable via SSDP.
> Once I connect to this ac
Hi,
apparently I am missing something else.
I can find devices when connected to a 'regular' LAN.
However, I have a camera that creates a Wifi accesspoint and makes itself
discoverable via SSDP.
Once I connect to this accesspoint my computer gets a valid IP address
assigned and the NodeJS code is
> On 18 May 2015, at 14:31, Ben Coman wrote:
>
>
>
> On Mon, May 18, 2015 at 6:49 PM, Sven Van Caekenberghe wrote:
>
> I meant that writing '\r\n' has no effect in Pharo, this is not processed
> (you could do this manually, of course).
>
> Is this something we should consider implementing
On Mon, May 18, 2015 at 6:49 PM, Sven Van Caekenberghe wrote:
>
>
> I meant that writing '\r\n' has no effect in Pharo, this is not processed
> (you could do this manually, of course).
Is this something we should consider implementing to ease the way for
newcomers? What downsides can you think
Thanks for the explanation.
Best,
Manfred
On Mon, May 18, 2015 at 12:49 PM, Sven Van Caekenberghe
wrote:
>
> > On 18 May 2015, at 12:44, Manfred Kröhnert
> wrote:
> >
> > Hello Sven,
> >
> > thanks for your fast reply.
> >
> > On Mon, May 18, 2015 at 11:41 AM, Sven Van Caekenberghe
> wrote:
> On 18 May 2015, at 12:44, Manfred Kröhnert
> wrote:
>
> Hello Sven,
>
> thanks for your fast reply.
>
> On Mon, May 18, 2015 at 11:41 AM, Sven Van Caekenberghe wrote:
> Hi Manfred,
>
> Did you see/study the example/test UDPSocketEchoTest ?
>
> unfortunately I did not see this class, yet.
Hello Sven,
thanks for your fast reply.
On Mon, May 18, 2015 at 11:41 AM, Sven Van Caekenberghe
wrote:
> Hi Manfred,
>
> Did you see/study the example/test UDPSocketEchoTest ?
>
unfortunately I did not see this class, yet.
But I did look at the Socket class itself and Socket>>timeTestUDP (in
P
Hi Manfred,
Did you see/study the example/test UDPSocketEchoTest ?
Also, UDP is very primitive: it is send and forget, returns no errors, and is
totally asynchronous. Listening should best be done in a separate process.
Here is how I would write your send part:
| message udpSocket |
message
31 matches
Mail list logo
