On 20 Jan 2020, at 17:39, HilaireFernandes <hilaire@drgeo.eu> wrote:
It is indeed about *receiveDataInto:fromHost:port:* I am talking about.
Its *fromHost* parameter is not of the same nature as the *toHost* parameter in the message *sendUDPData:toHost:port: * In the former it is expected a ByteArray to work, in the later a SocketAdress.
I don't see any indication in the code to prove your statement "Socket>>#sendUDPData:toHost:port: is assuming hostAddress to be a SocketAddress". Like I said, all primitives take host addresses to be a byte array (of which SocketAddress is a subclass).
*About the context. *This school year I am doing basic Pharo programming with Dr.Geo (12 and 13 years old). I wrote a school book[1] for that. But It is a bit tedious to teach and not enough appealing. It may just be my fault or the format of the book. For the next semester, I will explore alternative format, in more independent teaching unit.
For the longer term, I want to explore alternative way of teaching Pharo, more appealing. Something more in the kids interest area.
Do you know Minetest, it is a free implementation of Minecraft? It comes with a server software and client instances communicating with the server with a dedicated UDP protocol. In the past, we use it in an architecture project in connexion with math.
Written with Pharo, I envision a Minetest client using the UPD protocol to interact with a server. This Pharo written client will be used as a programming environment to control the kid avatar in the Minetest 3D world, like a BotsInc of 3D. The Pharo client will not render the view, it will be done by the usual Minetest client.
For example, a kid could code the behaviour of his avatar to build a tower with a Minetest DSL:
../.. 100 timesRepeat: [ avatar goUp 4 timesRepeat: [ 10 timesRepeat: [avatar dropBrick; moveForward]. avatar turnLeft] ]
There are some extensions in Minetest client (Mod in Minetest terminology) to do some basic programming but it is not as interesting as could be Pharo programming with a dedicated DSL[3].
I speculate it could be pretty cool and it should meet a lot of success among kids. Plus provide good teaching interest and more Pharo awareness.
Hilaire
[1] https://launchpad.net/drgeo/trunk/19.09/+download/programmer-avec-drgeo.pdf [2] http://www.minetest.net [3] https://forum.minetest.net/viewtopic.php?f=14&p=365620&sid=5d825763b9cb5579c...
Sounds nice, and indeed a (more) fun way to teach programming. But I still fail to see why you have to filter incoming UDP packets on their origin address. I do agree that using ByteArray and SocketAddress interchanging fails in some cases, even though one is a subclass of the other, because #= fails, due to the class check. I can't see an easy way to fix this (as #= is defined in SequenceableCollection). One solution might be to add #species ByteArray to SocketAddress, but it is hard to see the implications of that. Another option might be to add: SocketAddress>>#= anObject ^ self == anObject or: [ self hasEqualElements: anObject ] This way, #= would work when the SocketAddress is the receiver (but not the other way around which is ugly). If you then put hostAddress first in: Socket>>#receiveDataInto: aStringOrByteArray fromHost: hostAddress port: portNumber "Receive a UDP packet from the given hostAddress/portNumber, storing the data in the given buffer, and return the number of bytes received. Note the given buffer may be only partially filled by the received data." [ | datagram | datagram := self receiveUDPDataInto: aStringOrByteArray. (hostAddress = (datagram at: 2) and: [ (datagram at: 3) = portNumber ]) ifTrue: [ ^ datagram at: 1 ] ifFalse: [ ^0 ] ] repeat it should work. Sven