@mikael

it worked thank you!

Hi Gents

Well its still an ongoing saga.. I seem to have got something wrong. The app worked well until I archived it and then when I pushed up to apple it came back with a bunch of errors. So started to look through the code and tried to build it again and then it started giving the following error and failing the build.

ld: warning: ignoring file /Users/schilds/Desktop/PythonistaAppTemplate- Master/PythonistaAppTemplate/PythonistaKit.framework/PythonistaKit, missing required architecture x86_64 in file /Users/schilds/Desktop/PythonistaAppTemplate- Master/PythonistaAppTemplate/PythonistaKit.framework/PythonistaKit (2 slices)
Undefined symbols for architecture x86_64:
"OBJC_CLASS$_PAConsoleImageView", referenced from:
objc-class-ref in libpythonista_appui.a(PAStandaloneOutputView.o)
"_CanvasGetImage", referenced from:
-[PAStandaloneOutputView canvasFlushed:] in libpythonista_appui.a(PAStandaloneOutputView.o)
"_IsWaiting", referenced from:
-[PAStandaloneOutputView textFieldShouldReturn:] in libpythonista_appui.a(PAStandaloneOutputView.o)
"_LineRead", referenced from:
-[PAStandaloneOutputView textFieldShouldReturn:] in libpythonista_appui.a(PAStandaloneOutputView.o)
"OBJC_CLASS$_PythonInterpreter", referenced from:
objc-class-ref in PAAppDelegate.o
objc-class-ref in libpythonista_appui.a(PAStandaloneOutputView.o)
"OBJC_CLASS$_PAEExtensionContext", referenced from:
objc-class-ref in PAAppDelegate.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

I don't think its the template but any suggestions please...

@shinya.ta Thé script here-under will allow you to test the Apple standard speech module, and this code supports, I hope, all emojis. Thus, I suppose that my other scripts has a bug for combined emojis. I'll try to correct it in a close future.

see here

Thnx!! :-D

I would use the Google Sheets Python API. They have a QuickStart example. I haven't done a script for Sheets in Pythonista, but I have done one for Gmail and it worked fine.

if you add

print('X:{:.2f} Y:{:.2f} Z:{:0.2f}'.format(*g))

after the g = gravity() line in update, this will print the gravity direction (it will show up at the very bottom line, or will show up in console later when you stop the script)

The gravity vector is the direction if gravity, relative to your phone's physical coordinate system: Z points out of the screen, Y points from home button to camera, and X points right in normal portrait mode.

When you hold your phone up to a wall, so you are looking at the screen in front of you with the home button on the bottom edge like you would normally hold it to make a phone call, gravity should read near -1 in Y, but 0 for the other axes.

If you then rotate it 90 degrees counter clockwise, so the home button is on the right side, but screen still vertical, X should read -1.

if you lay it flat on the table, screen up, Z should be near -1 and the other two are near zero.
If you hold it screen

If you confirm that is the case, i think one of two things happened.

Make sure you are not running in any sort of split screen mode. im not sure how scene behaves when you run split screen.

Also, make sure you have this line

run(Game(), PORTRAIT, show_fps=True)

if you had changed to LANDSCAPE, or nothing at all, then things would be as you described, since the game logic assumes that g.x is left/right. if you are in landscape, g.y increases when you tip left/right, while g.x would change by tipping forward/back.

in case you editing something by accident, the motion logic looks like

if abs(g.x) > 0.05: x = self.player.position.x # The components of the gravity vector are in the range 0.0 to 1.0, so we have to multiply it with some factor to move the player more quickly. 40 works pretty well, but feel free to experiment. max_speed = 40 # We simply add the x component of the gravity vector to the current position, and clamp the value between 0 and the scene's width, so the alien doesn't move outside of the screen boundaries. x = max(0, min(self.size.w, x + g.x * max_speed)) self.player.position = (x, 32)

Awesome, thank you!

@cvp that‘s exactly what I was looking for! Thank you very much for your help!
I‘ll read about it.

@omz (read previous message before reading this) also, I have done the google form if your going to say that.

@mikael WOW with that package the speed increase a lot, thanks, now I know the real power of async programming

If I remember correctly, the enable_faulthandler.py can't be used as a pythonista_startup.py directly (by default the faulthandler script is meant to be importable, so it doesn't run when loaded). This gist contains the faulthandler script as a working pythonista_startup.py. (The faulthandler prints a message in the console when it runs, so you can tell when it's working correctly.)

@mikael Yeah. I'll try. The ui module in pythonista is still not kind of friendly towards me.

If @omz decides to support silent notifications we could have this kind of feature, with a server sending a remote silent notification received by Pythonista app even in background, without any user intervention.

Note that Pythonista doc also speaks about silent notifications but meaning local notifications without sound. That's really completely different.

So, writing 30 bytes to an open file in a tight loop takes maybe 70 microseconds on my crappy iPad3. (I timed by running 100000 writes). Even flushing between writes, very little difference. I doubt you'd improve much by trying to manually buffer-- since python files handle buffering for you, it shouldn't be an issue.

Opening the file each time, takes about 1 msec per write. I suspect as you get to GB files, the seek time might take some extra time. So don't do that. Open the file and hang onto the handle, and only close it in an error handler or script end.

I still think there cb module could be problematic. Are the sensortags recording data on their own internal timer, then you ask for data based on a python timer? Or, do you poll for data which triggers a sample?

If the sensor tags are sampling based on their own internal timer, things could drift because the clocks are different. To check for that, you would as a counter in the sensortags payload that is incremented only when it sends a response (not when it samples)

@shinyformica try this, it is the way omz wrote dialog: using wait_modal and resetting the view just after.

import ui from objc_util import * class Popover(ui.View): def __init__(self, *args, **kws): ui.View.__init__(self, *args, **kws) self.width = 200 self.height = 50 self.label = ui.Label() self.label.text = "test" self.add_subview(self.label) self.label.x = 0 self.label.y = 0 self.label.width = self.width self.label.height = self.height def will_close(self): print("popover closing") class MyView(ui.View): def __init__(self, *args, **kws): ui.View.__init__(self, *args, **kws) self.popover = None self.button = ui.ButtonItem() self.button.title = "Show Popover" self.button.action = self.showPopover self.right_button_items = (self.button,) def showPopover(self, sender): print("show popover") if self.popover is None: self.popover = Popover() self.popover.present(style="popover", popover_location=(self.width-100,50), hide_title_bar=True) self.popover.wait_modal() self.popover = None def run(): v = MyView() v.present('full_screen') if __name__ == '__main__': run()```

@shinyformica, thanks. I will include the weakref version.

I was also wondering if you had some globals-clearing code somewhere. Remembering some previous threads where the goal was to make Pythonista act like a fresh interpreter starting every time you run a script.

Or, to look at it in another way, you are resizing the contained Stepper, but not the containing View.

By the way, there is a pure-Python ftplib module in the standard library, that's probably easier to read than a C version. (ftplib is only an FTP client though, not a server.)