search

sugarlabs / sugar

Sugar GTK shell
GNU General Public License v3.0
253 stars 241 forks source link

Port to Python 3 #844

Closed Aniket21mathur closed 4 years ago

Aniket21mathur commented 5 years ago

Replaces #805

Aniket21mathur commented 5 years ago

I am not able to test the changes. What I did-

When I start sugar, it fails. When I check .sugar for logs, the logs directory is not build, hence not able to proceed further.

Aniket21mathur commented 5 years ago

I am getting this as a traceback on starting activities from Ubuntu terminal using sugar-activity3 .

dbus.exceptions.DBusException: org.freedesktop.DBus.Python.TypeError: Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/dbus/service.py", line 707, in _message_cb
    retval = candidate_method(self, *args, **keywords)
  File "/usr/local/lib/python3.6/dist-packages/carquinyol/datastore.py", line 308, in create
    self._metadata_store.store(uid, props)
  File "/usr/local/lib/python3.6/dist-packages/carquinyol/metadatastore.py", line 24, in store
    self._set_property(uid, key, value, md_path=metadata_path)
  File "/usr/local/lib/python3.6/dist-packages/carquinyol/metadatastore.py", line 51, in _set_property
    f.write(value)
TypeError: write() argument must be str, not dbus.Int32

1562144740.799171 WARNING root: DSObject was deleted without cleaning up first. Call DSObject.destroy() before disposing it.
quozl commented 5 years ago

That traceback is in sugar-datastore module, and from the paths it is ported to Python 3. You should have found it in datastore.log, is that right? You had best validate the arguments sent in the API call. Try dbus-monitor and look for the message that triggered it.

Aniket21mathur commented 5 years ago

You should have found it in datastore.log, is that right?

No, I got it when I tried to run the Chat activity from Ubuntu terminal, using sugar-activity3 . in the root directory. Surprising, but happens occasionally, I don't know what causes it, I am still working on it.

Thanks!

quozl commented 5 years ago

Thanks. That's not a common usage. No child is expected to do that. Only if activities fail to run in Sugar Terminal or from Sugar home view, list view, or sharing, would it be considered blocking. So I'll move back to your previous comment; Sugar does not start, and there are no logs. The cause must be uncovered. Any progress?

Aniket21mathur commented 5 years ago

Thanks. That's not a common usage. No child is expected to do that. Only if activities fail to run in Sugar Terminal or from Sugar home view, list view, or sharing, would it be considered blocking

Thanks, noted.

Any progress?

I have decided to first work on sugar-datastore Python 3 port, as sugar depends on it. We will not able to test the changes in sugar fairly until and unless we have all the dependencies working fine. What do you suggest?

quozl commented 5 years ago

I have decided to first work on sugar-datastore Python 3 port, as sugar depends on it. We will not able to test the changes in sugar fairly until and unless we have all the dependencies working fine. What do you suggest?

I don't think I need to prioritise Sugar vs Datastore. It's up to you. They are considerably different; the former is a GTK application, the latter is a D-Bus service. We have no other D-Bus services in our sources.

However, Datastore could be run in Python 3 and tested against either a Python 2 or Python 3 Sugar, and vice versa. I don't think there should be any problem mixing Python versions across the D-Bus barrier.

Aniket21mathur commented 5 years ago

I am still not able to test these changes, Sugar does not start, .sugar builds but only with debug file, logs is not built. I am not able to proceed further, as I don't get anything in the form of logs.

Thanks!

quozl commented 5 years ago

When you say Sugar does not start, what have you observed to conclude that?

How are you starting Sugar?

I suggest using strace. Read about the command in man strace. Then try something like this;

#!/bin/sh
strace -o /tmp/sugar.strace -f /usr/bin/sugar.real > /tmp/sugar.out 2> /tmp/sugar.err
Aniket21mathur commented 5 years ago

How are you starting Sugar?

I am trying to log in into the Sugar Desktop from Ubuntu login, when I press enter after typing the password, the cursor appears with a black screen, and nothing happens further.

I suggest using strace

Thanks, I will try that :-)

quozl commented 5 years ago

Re: d501d7f. Heh. :grin: Now, is there something we can do to make it clearer that this has gone wrong?

Aniket21mathur commented 5 years ago
  • temporarily move /usr/bin/sugar to /usr/bin/sugar.real,

Your suggestion made me realise that actually sugar is being called from /usr/bin instead of /usr/local/bin, the other one is the Python 3 one.

I have removed dependencies for Python 2 version for testing, that was the reason for the failure of sugar.

Now I am able to start sugar.

Observations:-

Re: d501d7f. Heh. Now, is there something we can do to make it clearer that this has gone wrong?

I got a traceback in the logs, regarding that :sweat_smile:

@quozl this was the traceback

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/jarabe/journal/volumestoolbar.py", line 205, in _set_up_volumes
    self._add_button(mount)
  File "/usr/local/lib/python3.6/dist-packages/jarabe/journal/volumestoolbar.py", line 235, in _add_button
    button = VolumeButton(mount)
  File "/usr/local/lib/python3.6/dist-packages/jarabe/journal/volumestoolbar.py", line 324, in __init__
    self.props.xo_color = get_mount_color(self._mount)
  File "/usr/local/lib/python3.6/dist-packages/jarabe/journal/misc.py", line 424, in get_mount_color
    sha_hash.update(mount_name)
TypeError: Unicode-objects must be encoded before hashing
quozl commented 5 years ago

Thanks. Should you ever need to, rather than remove Sugar for Python 2, whatever calls /usr/bin/sugar can be changed to call /usr/local/bin/sugar. It is the /usr/share/xsessions/sugar.desktop file added to the system by the sugar-session binary package. This originally came from data/sugar.desktop in the Sugar repository, where it has no path, but the path was added by the Debian developers in the debian/sugar.desktop file in the sugar source package. This makes it harder to use both a packaged Sugar and a /usr/local Sugar at the same time.

But it's still odd that you got a black screen and nothing in logs for trying to start a Python 2 build of Sugar on the same system that contained a /usr/local Python 3 build of Sugar. I think there's something more to that than meets the eye.

Do keep diagnosing why Journal, Neighbourhood and Group views are not working.

Aniket21mathur commented 5 years ago

Thanks.

Do keep diagnosing why Journal, Neighbourhood and Group views are not working.

Yes, I am working on it, @pro-panda your suggestions will be valuable here, as you instantiated these changes :grin:

quozl commented 5 years ago

It could easily be something in the toolkit that isn't used by activities. I suggest instrumenting the Sugar code with logging and use an attached debugger to determine state of relevant objects.

Aniket21mathur commented 5 years ago

It could easily be something in the toolkit that isn't used by activities. I suggest instrumenting the Sugar code with logging and use an attached debugger to determine state of relevant objects.

Thanks, currently I am looking at /sugar/src/jarabe/view/keyhandler.py .

ghost commented 5 years ago

On Wed, Jul 10, 2019 at 09:44:18PM -0700, James Cameron wrote:

I suggest using strace. Read about the command in man strace. Then try something like this;

• temporarily move /usr/bin/sugar to /usr/bin/sugar.real, • add a shell script /usr/bin/sugar containing;

!/bin/sh

strace -o /tmp/sugar.strace -f /usr/bin/sugar.real > /tmp/sugar.out 2> /tmp/sugar.err

• start Sugar once more; the results will be in those three files in /tmp

Optionally, and especially if you find yourself doing anything interactive at the shell, you can create a log of everything displayed in the terminal by wrapping your session with an instance of the script(1) command:

http://manpages.ubuntu.com/manpages/disco/en/man1/script.1.html

Directing specific output to specific files as above is the cleanest way to do it. You know which output came from STDOU (>), which from STDERR (2>), and which from strace (-o).

It does require more files, though, which can compound the difficulty of tracking what output corresponds with what iteration. Committing such ephemeral output files to version control isn't really appropriate, but one needs some way of distinguishing, for instance, output from before a change was made versus output after a change was made. I often will indicate the before/after origins of the output by changing the filenames.

When there are multiple filenames like this, I all too often neglect to change one of them to match the others, instead overwriting a file from a previous run. So, the output is more muddled, but I find it more tractable to have just one file per run, recorded with the 'script' command. One thing to be very careful of, though: If you interactively start recording with script, be sure to 'exit' out of the subshell to close out the logfile, or it will grow huge!

Another approach to normalizing your filenames across trials for ephemeral output like this is to datestamp the filenames.

For instance, here I append the number of seconds since the epoch to each filename:

strace -o /tmp/sugar.strace-$(date +%s) -f /usr/bin/sugar.real > /tmp/sugar.out-$(date +%s) 2> /tmp/sugar.err-$(date +%s)

Finally, another approach to keep the output from multiple runs separate is to put the results from each run in its own directory. This has a similar drawback as using multiple files per run, though, in that you have to be particularly mindful of your working directory all the time lest you inadvertently overwrite results from a previous iteration.

Another way to look at this might be: If you have reproducible behavior that you would like to document and communicate to others, use redirects. For internal, interactive use, where you're not yet sure what's happening, where, or why, it's better to have some log than a perfect log, and so you might find 'script' handy.

Hope that helps,

-- D. Joe

quozl commented 5 years ago

Thanks Joe!

Another way to get logs from early failure of /usr/bin/sugar is to change the sugar.desktop file to start /usr/bin/xterm or another terminal instead, and then when you log in you'll get an terminal instance, and you can then type sugar.

Aniket21mathur commented 5 years ago

I did some work around I think that the Python 3 port of toolkit needs some more work. Please see https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/419

Aniket21mathur commented 5 years ago

Getting this as a traceback when opening the thinclient_drive palatte window.

Traceback (most recent call last):
  File "/usr/local/lib/python3.6/dist-packages/jarabe/view/palettes.py", line 327, in __popup_cb
    fraction = (total_space - free_space) / float(total_space)
ZeroDivisionError: float division by zero
Aniket21mathur commented 5 years ago

Testing configuration~

Observations~

Issue~

Note~ Changes at https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/419 need to be incorporated for proper working.

Thanks!

quozl commented 5 years ago

Thanks, good progress.

Aniket21mathur commented 5 years ago
  • Timestamp in the journal is coming in years.

@quozl @pro-panda I am not able to figure out how to fix it, as a work around I looked into the files of sugar and datastore having the keyword timestamp but not able to figure out what's wrong. Need help.

quozl commented 5 years ago

Timestamp in the journal is coming in years.

Please describe the symptom? Of particular interest will be (a) the user operations that lead up to the event, (b) the value shown in the second last column of the Journal, and (c) the value shown in the "Date" field of the detailed view of the journal object.

For instance; (a) open Write activity, stop, open Journal, show detailed view, (b) "Seconds ago", and (c) "Date: 17/07/19".

Aniket21mathur commented 5 years ago

(a) the user operations that lead up to the event,

Open and close any activity, creating an instance in journal.

(b) the value shown in the second last column of the Journal

"0 years ago"

he value shown in the "Date" field of the detailed view of the journal object.

By this did you mean detail view of an activity instance in journal? Sorry it's not clear to me.

Thanks.

quozl commented 5 years ago

It's a fault in the toolkit. Watch me test by hand;

% python3
Python 3.7.3 (default, Apr  3 2019, 05:39:12) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from sugar3.util import timestamp_to_elapsed_string
>>> import time
>>> x = time.time() - 300  # five minutes ago
>>> timestamp_to_elapsed_string(x)
'0 years ago'
>>>

vs

% python2
Python 2.7.16 (default, Apr  6 2019, 01:42:57) 
[GCC 8.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from sugar3.util import timestamp_to_elapsed_string
>>> import time
>>> x = time.time() - 300  # five minutes ago
>>> timestamp_to_elapsed_string(x)
'5 minutes ago'
quozl commented 5 years ago

By this did you mean detail view of an activity instance in journal?

Yes. You'll probably find no issue with the date shown there.

Aniket21mathur commented 5 years ago

Thanks. Made a fix in https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/420, please test.

quozl commented 5 years ago

Tested and merged.

Has this pull request now reached full functionality?

Aniket21mathur commented 5 years ago

Tested and merged.

Thanks.

Has this pull request now reached full functionality?

Yes. I tested the changes from my side, It will be really good if you test again. :grin:

Aniket21mathur commented 5 years ago

@pro-panda it will be great if you also review and test it. :-)

quozl commented 5 years ago

Can't test, because can't resolve dependencies, because there's no package python3-gwebsockets yet.

Aniket21mathur commented 5 years ago

an't test, because can't resolve dependencies, because there's no package python3-gwebsockets yet.

Yes agreed, I am still working on it. Thanks.

Aniket21mathur commented 4 years ago

@pro-panda @quozl May you please test this pr now? Thanks!

quozl commented 4 years ago

Given the complexity of native install, and the difficulty others have had in reproducing the work so far, we really should try for packages. How is progress on toolkit packages for Python 3?

quozl commented 4 years ago

Although testing is incomplete, there's other pull requests coming into Sugar that need to be based off this work.