> On 20 Jan 2020, at 17:39, HilaireFernandes <[email protected]> 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=5d825763b9cb5579c5e195c0bf4e3b28#p365113
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
