Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port to Python3|TelepathyGlib #21

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

Saumya-Mishra9129
Copy link
Member

@quozl I have tested the activity it is working properly . The shell.log contains Normal Successfull completion, pid 1026 activity_id 7d2d4f14a8afe2e95921ba35e602ec40c6bfc7a2`. Kindly review it.

Copy link
Contributor

@quozl quozl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks.

How did you test collaboration?

Can you work toward making sprites.py consistent with sprites.py in other activities that have been ported? There's no reason to make this one different, and some good reasons to make it the same.

SearchActivity.py Outdated Show resolved Hide resolved
SearchActivity.py Outdated Show resolved Hide resolved
game.py Outdated Show resolved Hide resolved
game.py Outdated Show resolved Hide resolved
@ayushnawal
Copy link

Thanks @Saumya-Mishra9129

You can have a look at deducto and review the changes made by @chimosky in sprites.py.

As @quozl pointed out, you have used old_div, in spite of this you could have simply used //.
Although both give the same result // is what we used while porting an activity from python 2 to 3.

You can test collaboration by setting up two sugar environments and confirm that you can collaborate

Also, there is already a pull request #20 with the title Port to Python 3, I have not reviewed that completely but some changes were similar, I hope there will be no conflict when @quozl merges.

@quozl
Copy link
Contributor

quozl commented Mar 23, 2020

Thanks for comments.

As @quozl pointed out, you have used old_div, in spite of this you could have simply used //.
Although both give the same result // is what we used while porting an activity from python 2 to 3.

old_div is for writing code compatible with both Python 2 and Python 3. Only the Sugar Toolkit is required to do that. Activities are mostly either Python 2 or Python 3.

It is best to test to find the type of the arguments given to the division. Use / if one or more of the arguments were floating point when tested on Python 2. Use // if there's a need to avoid a floating point result on Python 3. Reminds us again why you must be able to test the activity on Python 2 before porting.

Also, there is already a pull request #20 with the title Port to Python 3, I have not reviewed that completely but some changes were similar, I hope there will be no conflict when @quozl merges.

It is nice to have more than one person working on a problem, but I do expect more cooperation and sharing of the patches. Unless patches are shared between the pull requests, then whichever pull request is ready to merge will merge first, then the other pull request will be considered as additional and may need to rebase. That's why it is very helpful for the two developers who began the two pull requests to review and merge each other's work into their own branches, rather than try to work apart.

@Saumya-Mishra9129
Copy link
Member Author

I will take care of cooperation next time. Is there any other activity rather than Sugar Toolkit which needs compatibility with both python 2 and 3? I was using old_div so that division operator work fine with python3 as with python2. I was using futurize as a tool for conversion from python 2 to python 3. I guess I should use 2to3 tool only.

@ayushnawal
Copy link

Is there any other activity rather than Sugar Toolkit which needs compatibility with both python 2 and 3?

In my opinion, No. Sugar Toolkit needs compatibility with both python 2 and 3 because some activities are running on python3 and some are still on python2( like this activity). So in order to support both the type of activities, the sugar toolkit is made compatible for both 2 and 3.

I was using futurize as a tool for conversion from python 2 to python 3

I don't know much about futurize and it's advantages over 2to3 tool but the porting guide suggests to use 2to3.

Have a look at Porting Guide (in case you haven't 😁 )

Thanks

@quozl
Copy link
Contributor

quozl commented Mar 24, 2020

I will take care of cooperation next time. Is there any other activity rather than Sugar Toolkit which needs compatibility with both python 2 and 3?

No, not that I know of.

I did consider it when planning the port for all of Sugar, because I'm to maintain Python 2 branches for use on the OLPC XO laptops which are stuck on Python 2 (not your problem). But the amount of change in activities has not been sufficient to justify the effort. Instead I backport patches as needed from master to python2 branch.

@Saumya-Mishra9129 Saumya-Mishra9129 changed the title Port to Pyrhon3|TelepathyGlib Port to Python3|TelepathyGlib Mar 24, 2020
@quozl
Copy link
Contributor

quozl commented Mar 24, 2020 via email

@Saumya-Mishra9129
Copy link
Member Author

@quozl @sanjay237 thanks for suggestions.

@JuiP
Copy link
Member

JuiP commented Mar 27, 2020

I was using futurize as a tool for conversion from python 2 to python 3. I guess I should use 2to3 tool only.

Almost every output of 2to3 will need modification to provide backward compatibility with Python 2. On the other hand, the python-future project provides a script called futurize that will produce code that is compatible with both Python 2 and Python 3. I hope I cleared your confusion why you should use 2to3.

@Saumya-Mishra9129
Copy link
Member Author

I have tried to fix Collaboration of activity as I am trying to port the activity to Collabwrapper , the port is still under process but yet I have made some changes. A review is requested here to proceed further as I am still getting some D-Bus connection related errors.

@quozl
Copy link
Contributor

quozl commented Apr 24, 2020

In general it looks kinda right, but you need to get it working before it is worth doing a detailed review. If you face an error you cannot resolve, do ask about it.

SearchActivity.py Outdated Show resolved Hide resolved
SearchActivity.py Outdated Show resolved Hide resolved
SearchActivity.py Outdated Show resolved Hide resolved
SearchActivity.py Show resolved Hide resolved
@chimosky
Copy link
Member

I agree with @quozl above, I took a look and made some comments.

@Saumya-Mishra9129

This comment has been minimized.

@Saumya-Mishra9129
Copy link
Member Author

I am making new commits here as previous commits and port was based on futurize tool , and It makes difficult in reviewing as well as it creates a lot of confusion. I am done with Port to Python3 and TelepathyGLib , and will work on fixing collaboration now.

write method here used to take unicode in python2
use encoded bytes in place of unicode in python3
@Saumya-Mishra9129
Copy link
Member Author

Tested Collaboration, working i.e. game state is shared. However when a player wins and goes to new level, until second player doesn't reach to same level as first, game state is not shared.
It is shared with both on same levels. I don't know what way the collaboration is desired here .
@quozl @chimosky @pro-panda Please review.

@quozl
Copy link
Contributor

quozl commented Jun 29, 2020

So to paraphrase, you're not sure how to implement shared game state after the first round? I think the game state should be the same; perhaps the new level should only occur once both players have won it once. If a wider discussion is needed, use the issue #18.

@Saumya-Mishra9129
Copy link
Member Author

you're not sure how to implement shared game state after the first round?

No that is not the case. The way I have implemented collaboration , works only when both players plays on same levels. If one player wins first, collaboration stops and resumes when second player comes on same level as first. however as you said level upgradation should only be possible when both players win. I was saying about perhaps it can be the case that author who have designed the activity , wanted collaboration this way. I am not sure, but it can be possible.

@JuiP
Copy link
Member

JuiP commented Jun 29, 2020

I haven't tested collaboration, but is it possible to start a new game when either player wins? This way you can ensure that the game state will always be shared.


self._collab = CollabWrapper(self)
self._collab.connect('message', self._message_cb)
self._collab.connect('joined', self._joined_cb)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'll be better to have the joined signal connected from one API to one callback, not having one from two different APIs to same callback.

SearchActivity.py Outdated Show resolved Hide resolved
SearchActivity.py Outdated Show resolved Hide resolved
SearchActivity.py Outdated Show resolved Hide resolved
self._game.remote_button_press(dot, color)

def send_event(self, entry):
def send_event(self, command, payload):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can also get rid of this method and simply have collab.post calls where you need them.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@chimosky
Copy link
Member

@Saumya-Mishra9129 said

No that is not the case. The way I have implemented collaboration , works only when both players plays on same levels. If one player wins first, collaboration stops and resumes when second player comes on same level as first. however as you said level upgradation should only be possible when both players win. I was saying about perhaps it can be the case that author who have designed the activity , wanted collaboration this way. I am not sure, but it can be possible.

Collaboration should work when players are on the same level and when one wins, the other player's game state should be automatically updated and the player should be on the same level as the previous winner.

@quozl
Copy link
Contributor

quozl commented Jun 29, 2020

Collaboration should work when players are on the same level and when one wins, the other player's game state should be automatically updated and the player should be on the same level as the previous winner.

I agree. Thanks for expressing it this way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants