Pythonista 1.6 Beta #160020
Build #160020 is now available via TestFlight. Please use this thread for feedback.
I've just added a couple of new people to the TestFlight list – if you didn't get an invite, but would like to participate, please fill out this form: → Beta Signup.
Bug: had the ui editor opened and I put Pythonista in the background. Now when I try to open it it just crashes - doesn't open.
Seem the ui.load_view does not like my fairly complicated pyui file. Worked fine but now:
Traceback (most recent call last): File "/var/mobile/Containers/Data/Application/9EC48B68-E4CB-454A-B52E-3E92C934916F/Documents/chordcalc/chordCalc/chordcalc.py", line 3314, in <module> mainView = ui.load_view('chordcalc') File "/private/var/mobile/Containers/Bundle/Application/743EA4AB-23E2-4CB0-BE78-8FAE0E9A2A89/Pythonista.app/pylib/site-packages/ui.py", line 373, in load_view return load_view_str(json_str, bindings, stackframe) File "/private/var/mobile/Containers/Bundle/Application/743EA4AB-23E2-4CB0-BE78-8FAE0E9A2A89/Pythonista.app/pylib/site-packages/ui.py", line 359, in load_view_str return _view_from_dict(root_view_dict, g, l) File "/private/var/mobile/Containers/Bundle/Application/743EA4AB-23E2-4CB0-BE78-8FAE0E9A2A89/Pythonista.app/pylib/site-packages/ui.py", line 342, in _view_from_dict subview = _view_from_dict(d, f_globals, f_locals) File "/private/var/mobile/Containers/Bundle/Application/743EA4AB-23E2-4CB0-BE78-8FAE0E9A2A89/Pythonista.app/pylib/site-packages/ui.py", line 342, in _view_from_dict subview = _view_from_dict(d, f_globals, f_locals) File "/private/var/mobile/Containers/Bundle/Application/743EA4AB-23E2-4CB0-BE78-8FAE0E9A2A89/Pythonista.app/pylib/site-packages/ui.py", line 258, in _view_from_dict v.text = attrs.get('text') TypeError: Expected a string
Interesting, I guess I haven't really tested this on a 32 bit device. Looks like I have to use
objc_msgSend_stretthere (which doesn't even exist in the 64-bit runtime for some reason).
Could you send me the pyui file somehow? It looks like an easy fix, but in the meantime you can use:
import _ui _ui._load_view(...)
to get the old implementation. This will go away, but I left it in there for now, in case there are problems with the new one.
Could you send me the pyui file you had open (that probably caused the crash)? You can transfer it to your Mac/PC via iTunes file sharing. Let me know if you need more details.
@omz email sent
@omz email sent. Works fine with legacy
This isn't specific to the new beta build, but zip archives with multiple files at root level extract into their parent directory, not a new subfolder like most other unzipping programs do. With only a single file at root level that's not a problem, but I had a zip file with a lot of files at root level, which are now all in the main Script Library folder.
Interesting, I guess I haven't really tested this on a 32 bit device. Looks like I have to use objc_msgSend_stret there (which doesn't even exist in the 64-bit runtime for some reason).
that worked. i updated
__call__to check for Structure restype, and called objc_msgSend_stret. i suspect one may actually need to check the size of the struct, but this seems to work for most structs ive encountered.
No idea if this would be of any use, but have you tried to use
CTypesBackend? Might or might not be a more convenient interface than raw
back on clearing globals, thought id share the workaround for stash:
launch_stash.pywhich imports, rather than runs, stash, then create a new instance.
since the module never gets cleared, it survives global clearing.
import stash _stash = stash.StaSh() _stash.run() stash._stash=_stash
also, some may find this useful as an action menu script. instead pressing Play to run a script, run this from the action menu, which executes the current script without clearing globals. thats at least a workaround if the option to not clear globals doesnt come back.
# execute script in editor, in current interpreter session without clearing globals import editor execfile(editor.get_path())
New to the beta. Firstly, everything seems to run very smoothly on my iPad. However at some point the app stopped working completely: I couldn't open it anymore, I tried restarting my iPad but that didn't work. I had to reinstall it to use it again. It might've been caused by something in iOS 9 (beta 3) though. Also, I noticed that the MIDIPlayer doesn't seem to work properly in a UI action (even with ui.in_background, it's immediately stopped when the action function ends), although it can be fixed with an empty while loop looping until the end of the MIDI file is reached. Lastly, while it's not really a bug, it seems I have to open a new tab, tap Documentation and close the tab to open the documentation, which is a little bit unintuitive.
Anyway, nice work on the update, the tabbed editor and appex module are really useful!
When Pythonista won't launch, you can always try and launching the pythonista:// URL in Safari.
Lol, ccc. I was just about to write the same thing after my screw up yesterday ;)
@omz sorry Ollie but newest load_ view does to handle custom view. My fretboard view does not execute did_load(). Fine with legacy version.
Got it and tested it, it's very promising - I really like the enhanced screen resolution and the new features so far.
Well now I have 2 problems:
- I didn't manage to run my current Scene() totally fullscreen, there is still a close button & white bar displayed. BTW auto-rotation with device seems disabled (my app is running in landscape mode)
- The SceneView() addition, in my UI-based app, crashes Pythonista upon running.
Hackingroelz, you probably need the MIDIPlayer to be a global, or at least an instance variable -- otherwise i think it goes out of scope and stops when the function ends. you just need to hang onto a reference. i dont remember if SoundPlayer had that problem.
Few more comments on latest beta.
NSDictionary get/set using python dictionary language doesnt seem to work. at least for dicts found in the wild, the isKindClass seems to not be returning true. i wonder if it would be better to look for whether the object responds to
valueForKey_etc, rather than checking class? similarly for iterables.
with the tabbed editor, the
editorclass needs updates to access tabs, or should have a
reloadcommand which reloads all tabs. when changing a file on disk, it was a good idea to check if it was thr current file in the editor, and reload, but this cant happen in current version, since reopening a file programatically causes a new tab to open, and the
get_pathonly returns current tab.
the editor should probably disallow opening two copies of the same file, unless one is set to read only. this can cause confusion, where one copy is edited, then switching to the other copy effectively undoes the changes! maybe just bring existing file tab to the front if opening an already open file? alternatively, editor should detect if file on disk changed, and reload (or prompt for reload) as is done in many text editors. ... there are use cases for having two tabs open on the same file, say for editing very large files, but keeping edits in sync is necessary.
- NSDictionary get/set using python dictionary language doesnt seem to work. at least for dicts found in the wild
It's likely that dictionaries you find "in the wild" are
NSMutableDictionary, so they're immutable (this is different from Python where all dictionaries are mutable).
- with the tabbed editor, the editor class needs updates to access tabs
Yes, that needs some work.
- the editor should probably disallow opening two copies of the same file, unless one is set to read only. this can cause confusion, where one copy is edited, then switching to the other copy effectively undoes the changes!
The way it's supposed to work is that editing a file in one tab, then switching to a different tab with the same file open would reload the file in the second tab... I just did a quick test, and this mechanism seems to work fine here.
the problem comes when two copies of a file are opened, and then you write to the file programatically, then use
editor.open_file. the new file is now open in one tab, but the old file is in the old tab. i think the problem is because each copy thinks it is "clean", since the changes were made outside of the editor. if you then edit one copy in the editor, then i think it gets reloaded in the other, but in some cases that is exactly the wrong thing, for instance i just want to close the "old" copy, but then it ends up overwriting the new version.
@JonB Thanks for the clarification. Yes, the way external changes to files are handled could definitely be improved...