udp socket bug on daily build 2883 and later

Solar2D Network
#21

Yes, it is practical for you but not for us. 

We usually found bugs in a middle of our projects, so it is not simple or direct to simply create a test case.

A very simple example is this thread.  I stated very clear the problem “When I start the project for 1st time I can listen broadcast packets (sent by another non-corona device) normally, but if I restart the simulator it stops seeing the packets.”. 

That one line description is more than sufficient for anyone with minimum development skills to recreate the scenario.  I got to know Corona engineers and I know they are top class. I have not doubt that anyone there can read that sentence and recreate that situation without any question.

Now for me, I cannot simply get my whole app+server project to send to you. Also, I don’t want to stop my work for ~1 hour to create the test project, fill out the form, submit and pray for one day Corona see it and fix it. So, for me it is not worthy at all.  If all bugs report were fixed in a short time, it would be different. I would think: “Ok, I am okay spending 1 hour  here to have the bug fix in 2 weeks”. But usually that is not the case. You spend your time and it takes months or even years.

About your 2nd point, I don’t think a software limitation should be a reason to simply make the life of clients worse. I am pretty sure you can add the forum post URL attached to the bug description. So whoever is taking care of the bug can just click on the forum link and paste there any request or update about it.

And about “Finally forums don’t allow assigning tasks to people.”.  Of course I am not saying that you shouldn’t use a bug tracker, you should use.  I am just saying that ignore bugs reports that are posted in the forum just because no one created a bug report is not something that I think it should be done.  That position is like a company employee that sees a problem with the company product and simply don’t report to its superior because it is not their primary job.

To finalize, that is just my opinion. I don’t want to enter here in a discussion about that because I am sure that you will get back with other problems. But for me, it alls sum up to the mantra “A man who wants something will find a way; a man who doesn’t will find an excuse.”.

 I just wanted to share it because I believe that other developers see that as the same as I and are simply not filling bug reports anymore because they don’t see value on it. In the end, it is Corona that loses the opportunity to get know the problem on its product and improved it.

#22

Hi Renato,

You need to make some checks now before using the socket lib. Luckily It has been already worked on by Corona team for the old Autolan project so I took this snippet from there. Simply replace your socketlib calls with the respective socketUDP or socketTCP methods below. I think this should have been posted as a thread somewhere along with that build that changed the socket library version.

-- Check if this is socket 2 or later local isSocket2 = (string.match( socketlib.\_VERSION, "LuaSocket 2" ) ~= nil ) local forceIPV4 = true local socketUDP = (isSocket2) and socketlib.udp or(socketlib.udp6 or socketlib.udp4 or socketlib.udp) local socketTCP = (isSocket2) and socketlib.tcp or(socketlib.tcp6 or socketlib.tcp4 or socketlib.tcp) if( forceIPV4 and isSocket2 == false ) then socketUDP = socketlib.udp4 or socketlib.udp socketTCP = socketlib.tcp4 or socketlib.tcp end --
#23

A very simple example is this thread.  I stated very clear the problem “When I start the project for 1st time I can listen broadcast packets (sent by another non-corona device) normally, but if I restart the simulator it stops seeing the packets.”. 

 

That one line description is more than sufficient for anyone with minimum development skills to recreate the scenario.  I got to know Corona engineers and I know they are top class. I have not doubt that anyone there can read that sentence and recreate that situation without any question.

 

The reason we ask for bug reports is that a lot of the time when we get a problem report the issue just doesn’t appear when someone else tries to reproduce it from the description.  This is a case in point.  You can run the attached app I made to reproduce the problem and see that it works fine (as I expected it would given the testing we did before shipping the new version).

 

Note that I am not saying there isn’t a problem, just that the person experiencing it is the one in the position to reproduce it.  And, a surprising amount of the time, when someone goes to create a simple, reproducible case they realize where the error is in their own code (not that I’m saying that’s the case here).

 

All of this goes double for network code which is hard to do and prone to seeming to work despite minor errors which become issues when software versions change.