The number does not matter, you are both right and wrong. You are correct indeed the string inside the array creates an error by itself and also contributes to the primitive error of the UDP socket. You are wrong for thinking this is the only issue here. What we have here is a problematic primitive UDP. When the string in the array is passed asByteArray , the ByteArray class complains with an error as it should. However when it is passed to the UDP sendData:host:port it does not trigger the ByteArray error as it should instead it triggers a socket primitive error which obviously is not a good behaviour, so its Pharo bug. Since the asByteArray fails the correct error should be displayed and the udp socket primitive should never trigger. You may think that with Primitive error of the UDP socket the data is never sent and you will be once again wrong. Most of the times the data is indeed not sent but other times it does . When this happens ? its completely random. I know this because the SC server gives me a log output with every message received together with host address and port. Finally you are correct to think that if the array is passed as it should then everything works fine. In the end, I decided that the OSCMessage was more than enough for my needs and seems to handle byteArrays fine and is easier to use. Conclusion: Problems, Pharo bug remains. As always thanks for the help. On Mon, Oct 31, 2016 at 6:58 PM Nicolai Hess <nicolaihess@gmail.com> wrote:

Am 31.10.2016 5:14 nachm. schrieb "Nicolai Hess" <nicolaihess@gmail.com>:

...

Hi,

2016-10-31 12:46 GMT+01:00 Dimitris Chloupis <kilon.alios@gmail.com>:

...

Hey guys I try to use Pharo to use Supercollider via OSC. OSC library

...

...

So SC informs that it receives the messages sent, but in Pharo I am

getting annoying Primitive errors that I paste bellow. Anyone knows if this a bug or something missing here ?

...

Also SC sometimes it informs me that the message was received in a

different port than it was sent.

...

Here the code I am using

(OSCMessage for:{'/mixer.volume'. 1 . 0.2})sendTo: '127.0.0.1' port:

is maintained by Stef in STHub. 57120.

...

is the 0.2 a float or should this be read as 0 . 2 . (as two integral

numbers?).

...

{'/mixer.volume'. 1 . 0.2} asByteArray will try to convert every item in this array to a byte, so it will create a byte array with four items, but it can not convert the string to a single byte.

Of course, you can convert a string to a byte array

'/mixer.volume' asByteArray "#[47 109 105 120 101 114 46 118 111 108 117 109 101]"

OK, I just saw your call is similar to the other examples, so I think OSC knows what to do with strings in arrays, so maybe it is indeed the 0.2 that can not be converted?

...

...

Any help greatly appreciated.

Supercollider is an application which is basically a server written in

C++ that does music composition and audio synthesis live , its extremely powerful and the top professional audio tool for audio synthesis and music live coding.

...

...

http://supercollider.github.io

Socket(Object)>>primitiveFailed: Socket>>errorSending:startingAt:count:toHost:port: Socket>>primSocket:sendUDPData:toHost:port:startIndex:count: Socket>>sendUDPData:toHost:port: OSCMessage(OSCPacket)>>sendTo:port: UndefinedObject>>DoIt OpalCompiler>>evaluate RubSmalltalkEditor>>evaluate:andDo: RubSmalltalkEditor>>highlightEvaluateAndDo: [ textMorph textArea editor highlightEvaluateAndDo: ann action. textMorph shoutStyler style: textMorph text ] in [ textMorph textArea handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann

action.

...

textMorph shoutStyler style: textMorph text ] ] in GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: in Block: [ textMorph textArea editor highlightEvaluateAndDo...etc... RubEditingArea(RubAbstractTextArea)>>handleEdit: [ textMorph textArea handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action. textMorph shoutStyler style: textMorph text ] ] in GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: in Block: [ textMorph textArea... WorldState>>runStepMethodsIn: WorldMorph>>runStepMethods WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle [ [ World doOneCycle. Processor yield. false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess in Block: [ [ World doOneCycle.... [ self value. Processor terminateActive ] in BlockClosure>>newProcess in Block: [ self value....

UDP works pretty well in Pharo. UDP is also quite simple (being connectionless). It is quite likely that the high level Pharo code does something wrong.

On 31 Oct 2016, at 18:15, Dimitris Chloupis <kilon.alios@gmail.com> wrote:

*Conclusion: Problem solved, Pharo bug remains

I was also informed in Slack that this may be a Mac only problem.

On Mon, Oct 31, 2016 at 7:13 PM Dimitris Chloupis <kilon.alios@gmail.com> wrote: The number does not matter, you are both right and wrong.

You are correct indeed the string inside the array creates an error by itself and also contributes to the primitive error of the UDP socket.

You are wrong for thinking this is the only issue here. What we have here is a problematic primitive UDP.

When the string in the array is passed asByteArray , the ByteArray class complains with an error as it should.

However when it is passed to the UDP sendData:host:port it does not trigger the ByteArray error as it should instead it triggers a socket primitive error which obviously is not a good behaviour, so its Pharo bug. Since the asByteArray fails the correct error should be displayed and the udp socket primitive should never trigger.

You may think that with Primitive error of the UDP socket the data is never sent and you will be once again wrong. Most of the times the data is indeed not sent but other times it does . When this happens ? its completely random. I know this because the SC server gives me a log output with every message received together with host address and port.

Finally you are correct to think that if the array is passed as it should then everything works fine.

In the end, I decided that the OSCMessage was more than enough for my needs and seems to handle byteArrays fine and is easier to use.

Conclusion: Problems, Pharo bug remains.

As always thanks for the help.

On Mon, Oct 31, 2016 at 6:58 PM Nicolai Hess <nicolaihess@gmail.com> wrote:

Am 31.10.2016 5:14 nachm. schrieb "Nicolai Hess" <nicolaihess@gmail.com>:

...

Hi,

2016-10-31 12:46 GMT+01:00 Dimitris Chloupis <kilon.alios@gmail.com>:

...

Hey guys I try to use Pharo to use Supercollider via OSC. OSC library is maintained by Stef in STHub.

So SC informs that it receives the messages sent, but in Pharo I am getting annoying Primitive errors that I paste bellow. Anyone knows if this a bug or something missing here ?

Also SC sometimes it informs me that the message was received in a different port than it was sent.

Here the code I am using

(OSCMessage for:{'/mixer.volume'. 1 . 0.2})sendTo: '127.0.0.1' port: 57120.

is the 0.2 a float or should this be read as 0 . 2 . (as two integral numbers?). {'/mixer.volume'. 1 . 0.2} asByteArray will try to convert every item in this array to a byte, so it will create a byte array with four items, but it can not convert the string to a single byte.

Of course, you can convert a string to a byte array

'/mixer.volume' asByteArray "#[47 109 105 120 101 114 46 118 111 108 117 109 101]"

OK, I just saw your call is similar to the other examples, so I think OSC knows what to do with strings in arrays, so maybe it is indeed the 0.2 that can not be converted?

...

...

Any help greatly appreciated.

Supercollider is an application which is basically a server written in C++ that does music composition and audio synthesis live , its extremely powerful and the top professional audio tool for audio synthesis and music live coding.

http://supercollider.github.io

Socket(Object)>>primitiveFailed: Socket>>errorSending:startingAt:count:toHost:port: Socket>>primSocket:sendUDPData:toHost:port:startIndex:count: Socket>>sendUDPData:toHost:port: OSCMessage(OSCPacket)>>sendTo:port: UndefinedObject>>DoIt OpalCompiler>>evaluate RubSmalltalkEditor>>evaluate:andDo: RubSmalltalkEditor>>highlightEvaluateAndDo: [ textMorph textArea editor highlightEvaluateAndDo: ann action. textMorph shoutStyler style: textMorph text ] in [ textMorph textArea handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action. textMorph shoutStyler style: textMorph text ] ] in GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: in Block: [ textMorph textArea editor highlightEvaluateAndDo...etc... RubEditingArea(RubAbstractTextArea)>>handleEdit: [ textMorph textArea handleEdit: [ textMorph textArea editor highlightEvaluateAndDo: ann action. textMorph shoutStyler style: textMorph text ] ] in GLMMorphicPharoScriptRenderer(GLMMorphicPharoCodeRenderer)>>actOnHighlightAndEvaluate: in Block: [ textMorph textArea... WorldState>>runStepMethodsIn: WorldMorph>>runStepMethods WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: WorldMorph>>doOneCycle [ [ World doOneCycle. Processor yield. false ] whileFalse: [ ] ] in MorphicUIManager>>spawnNewProcess in Block: [ [ World doOneCycle.... [ self value. Processor terminateActive ] in BlockClosure>>newProcess in Block: [ self value....

good catch , now we know why it does what it does. The reason why I did this is that there is an example method in OSCMessage that use this bad syntax in the comment. So it seems the Socket does send the message because Pharo does not perform a check on the argument, the Socket fails obviously but it may send the message to an unknown address. I think Supercollider watches for any kind of messages on various addresses and ports. At least that is only explanation I can think of. Or maybe I used the address string method and I forgot to mention it. Anyway thanks will keep this in mind. On Wed, Nov 2, 2016 at 9:07 PM Henrik Sperre Johansen < henrik.s.johansen@veloxit.no> wrote:

I'm amazed that ever works, as (in general, maybe mac is special,) you need to specify the ipv4 address as a ByteArray, not a string.

(OSCMessage for:{'/mixer.volume'. 1 . 0.2})sendTo: #[127 0 0 1] port: 57120

Cheers, Henry

-- View this message in context: http://forum.world.st/UDP-Socket-primitive-failure-tp4920870p4921195.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.