Pure Maps - Page 16 - maemo.org

pichlo | # 151 | 2018-09-06, 19:26 | Report

On the positive side of things, I have swapped mimic in favour of picotts and noticed a big improvement

Except one thing: there is a short (like half a second or less) fade-in on every spoken instruction, meaning you can miss the beginning if you don't expect it. Is it deliberate or just an artifact of how picotts works?

I will try the command line thing tomorrow morning, thanks rinigus.

The Following 5 Users Say Thank You to pichlo For This Useful Post:
Amboss, imaginaryenemy, juiceme, peterleinchen, rinigus

rinigus | # 152 | 2018-09-06, 19:33 | Report

Version with chattier exit is available at https://drive.google.com/file/d/1QAU...ew?usp=sharing

Please start it with sailfish-qml from terminal.

I have not included the hammer yet. Would need to confirm that the issue is reproducible in terminal (sometimes terminal seems to be acting better).

@otsaloma, its also not clear where to invoke the hammer. At the end of quit? Then the stack was almost absent. Somewhere else? Or is it mainly to ensure that we do quit?

Edit Re picotts - keep it then with pico for now, we'll look into it a bit later. Probably you just need to replace a voice in mimic (for example female voice in mimic should use significantly less resources)

The Following 4 Users Say Thank You to rinigus For This Useful Post:
Amboss, juiceme, peterleinchen, pichlo

otsaloma | # 153 | 2018-09-06, 20:54 | Report

Originally Posted by rinigus View Post

@otsaloma, its also not clear where to invoke the hammer. At the end of quit?

Yes, I figured if all the function calls under Application.quit pass, but maybe a subprocess or thread is misbehaving, a "raise SystemExit(0)" at the end might force a quit – and if sailfish-qml/qmlscene/qml is waiting for Python, then the whole app process tree might quit, maybe.

For what it's worth, I did test http.pool.terminate with online providers in different connection states and it seemed to work fine, but it's possible I missed something or OSM Scout behaves differently. Also, if there's a problem in the http module, one solution would be to just swap it for requests (plus its dependencies). I was reluctant to bundle stuff, but I also think I underestimated the difficulty of writing a custom HTTP connection pool, there's been various corner case issues.

The Following 7 Users Say Thank You to otsaloma For This Useful Post:
Amboss, carlosgonz, Fellfrosch, juiceme, peterleinchen, pichlo, rinigus

rinigus | # 154 | 2018-09-07, 05:14 | Report

Originally Posted by otsaloma View Post

Yes, I figured if all the function calls under Application.quit pass, but maybe a subprocess or thread is misbehaving, a "raise SystemExit(0)" at the end might force a quit – and if sailfish-qml/qmlscene/qml is waiting for Python, then the whole app process tree might quit, maybe.

For what it's worth, I did test http.pool.terminate with online providers in different connection states and it seemed to work fine, but it's possible I missed something or OSM Scout behaves differently. Also, if there's a problem in the http module, one solution would be to just swap it for requests (plus its dependencies). I was reluctant to bundle stuff, but I also think I underestimated the difficulty of writing a custom HTTP connection pool, there's been various corner case issues.

When searching for solution, I looked into requests as well. But it had the same issue as HTTPConnection - its using blocking calls and would require the same threaded approach as used in http.py now. There was an issue filed in requests repo with the similar problem as we have (cannot find it now). One way would be to go for something async, but I think we will be able to stick to the threading approach and resolve it around it.

Let's see what @pichlo's testing will bring. There is one candidate for blocking - closing connections that I considered idle. That should come out in testing messages. If it is, its simple to "fix" by making Pure Maps bad netizen and just forgetting the connections.

As for OSM Scout Server differences: it mainly allows you to suspend the server process while keeping network stack of the device intact. So, it allows to test for some weird conditions that is harder to do with the online services.

The Following 5 Users Say Thank You to rinigus For This Useful Post:
Amboss, Fellfrosch, juiceme, peterleinchen, pichlo

pichlo | # 155 | 2018-09-07, 10:39 | Report

I made the log this morning. I navigated from home to Place A, then changed the route to Place B. I was looking for parking around Place B, which Pure Maps interpreted as I overshot the destination and was trying to reroute me.

In the end, I closed the GUI but the CLI kept going, continually printing the same two lines over and over, until I closed that too. I can PM you the whole log (I do not want to share it here in full for privacy reasons as it contains my entire route), but the tail looks like this:

Code:

[W] unknown:0 - QMetaMethod::invoke: Unable to handle unregistered datatype 'QGeoPositionInfo'
[D] unknown:0 - Geoclue client path: "/org/freedesktop/Geoclue/Master/client52"
[W] unknown:0 - QMetaMethod::invoke: Unable to handle unregistered datatype 'QGeoPositionInfo'
[D] unknown:0 - Geoclue client path: "/org/freedesktop/Geoclue/Master/client53"
[W] unknown:0 - QMetaMethod::invoke: Unable to handle unregistered datatype 'QGeoPositionInfo'
[D] unknown:0 - Geoclue client path: "/org/freedesktop/Geoclue/Master/client54"
[W] unknown:0 - QMetaMethod::invoke: Unable to handle unregistered datatype 'QGeoPositionInfo'
[D] unknown:0 - Geoclue client path: "/org/freedesktop/Geoclue/Master/client55"
[W] unknown:0 - QMetaMethod::invoke: Unable to handle unregistered datatype 'QGeoPositionInfo'
[D] unknown:0 - Geoclue client path: "/org/freedesktop/Geoclue/Master/client56"
[W] unknown:0 - QMetaMethod::invoke: Unable to handle unregistered datatype 'QGeoPositionInfo'
[D] unknown:0 - Geoclue client path: "/org/freedesktop/Geoclue/Master/client57"
[W] unknown:0 - QMetaMethod::invoke: Unable to handle unregistered datatype 'QGeoPositionInfo'

The Following 6 Users Say Thank You to pichlo For This Useful Post:
Amboss, Fellfrosch, imaginaryenemy, juiceme, peterleinchen, rinigus

rinigus | # 156 | 2018-09-07, 10:42 | Report

Please send by PM. These error messages seem to come from SFOS backend, as far as I can see. I presume that the interesting part is before the tail

.

So, you could look up where this tail starts and send some lines before that. In particular, starting from line with "Quitting".

Edit: And thank you very much!

The Following 7 Users Say Thank You to rinigus For This Useful Post:
Amboss, Fellfrosch, imaginaryenemy, juiceme, lal, peterleinchen, pichlo

pichlo | # 157 | 2018-09-07, 10:57 | Report

No, I thank you!

PM sent. Sadly, the whole log did not fit due to the message length limit. I can email it to you if you PM me your address.

Sadly, there was no "Quitting" in the log

The Following 5 Users Say Thank You to pichlo For This Useful Post:
Amboss, juiceme, lal, peterleinchen, rinigus

rinigus | # 158 | 2018-09-08, 12:58 | Report

@pichlo has been doing lots of driving with the hope that we can fix the shutdown bug. So far, no luck. But there are things we learned about Pure Maps.

The debug version had each Python call wrapped, so we could see entry and exit of each call to ensure that all calls returned. There were messages added to several Component.onDestruction signal handlers to see whether destructors are called.

@pichlo got some runs that were fine, some hanged on exit. This did not depend on whether voice prompts were used - same behavior was observed in the presence and absence of voice. Outcome of the tests:

* In all runs, successful or hanging exit, python calls always returned.

* In unsuccessful runs, no destructors were called

While not, many destructors were marked by printouts and it looks like, for some reason, closing the app did not start destructors.

Has anyone observed something like it? I am going to summarize it at sailfish-devel list as well.

Would like to thank @pichlo for the work!

The Following 10 Users Say Thank You to rinigus For This Useful Post:
Amboss, carlosgonz, Feathers McGraw, imaginaryenemy, juiceme, klinglerware, lal, olf, peterleinchen, pichlo

otsaloma | # 159 | 2018-09-08, 14:40 | Report

Originally Posted by rinigus View Post

While not, many destructors were marked by printouts and it looks like, for some reason, closing the app did not start destructors

Interesting. Sounds like the problem is on the QML side, I don't really know much about how it handles these things. It might help to check which top-level signals do get fired: there's onApplicationActiveChanged, which is apparently deprecated in favor of Qt.application.active; then there's at least onActiveChanged and Window.onClosing in QML Window, which Silica ApplicationWindow inherits.

The Following 7 Users Say Thank You to otsaloma For This Useful Post:
Amboss, carlosgonz, Feathers McGraw, juiceme, klinglerware, peterleinchen, rinigus

rinigus | # 160 | 2018-09-08, 16:22 | Report

Originally Posted by otsaloma View Post

Interesting. Sounds like the problem is on the QML side, I don't really know much about how it handles these things. It might help to check which top-level signals do get fired: there's onApplicationActiveChanged, which is apparently deprecated in favor of Qt.application.active; then there's at least onActiveChanged and Window.onClosing in QML Window, which Silica ApplicationWindow inherits.

Strange, I cannot attach any of these:

Code:

onClosing:
Window.onClosing:
onActiveChanged

with "cannot assign to non-existent property" (after adding import QtQuick 2.1 and import QtQuick.Window 2.1 as QtQuick)

Any idea how to attach them? As for onApplicationActiveChanged, I am quite sure that one was
called before hanging on @pichlo - corresponding keep_alive update was in the logs.

The Following 5 Users Say Thank You to rinigus For This Useful Post:
Amboss, carlosgonz, Feathers McGraw, juiceme, peterleinchen