Welcome!
This is the community forum for my apps Pythonista and Editorial.
For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.
Presenting ViewController
-
Ipad air 2, it is 64 bit. I noticed removing on main thread crashes the app after the recording and before the presentation, leaving it crashes when start_recording() is called
-
Okay, no idea what might be causing the crash then, sorry. :/
It doesn't crash here at all, but I've noticed that the resulting videos contain strange artifacts (looks like tearing), not sure if that's related somehow.
-
Ok, will try to solve it by me :-/
If you find something that could cause crashes tell me -
I'm near to the solution.
I removed @on_main_thread (that crashes many scripts i already worked on and worked with previous beta) and i tried to experiment with ObjCBlocks, always with a crash. So downloaded the example in the docs about the blocks. Guess what? It Crashes! The crash definitely has to do with blocksHope this helps solving the bug,
Filippo -
I'll do some more testing. It might have to do with different build settings in the TestFlight version vs. my local development build – after all, the code I posted definitely works here, and I don't think hardware differences are responsible for this (iPad Air 1 vs. 2 aren't that different).
I think this particular use case is possible to do without blocks (using a delegate instead), but it would still be nice if I could get those to work reliably.
-
Thanks :-)
Did some (more and more) testing with the example file and found that maybe the line 14 (where the handler is called) is responsible for the crash -
I can run the example block code (sorting function) from the documentation. My device is also a iPad Air 2.
The
RPScreenRecorder
did NOT run but it was due to a different error. Thereplaykit
was not created successfully. ThebundleWithPath_
method returned aNone
for me. -
Your error is there because you have iOS 8. ReplayKit is a framework of iOS 9.
Dunno about the example, maybe is some iOS 9 bug
@omz I was wrong, the line that crashes the app is line 14, where you call the handler. Anyway @on_main_thread crashes too for me. Remember i am on iPad Air 2 WiFi iOS 9 beta 5
-
Ok, @omz in the meantime can you show me how to do with delegates, please? :-)
Would be much appreciated -
@filippocld said:
Ok, @omz in the meantime can you show me how to do with delegates, please? :-)
Would be much appreciatedTurns out that I was wrong about that. It's not possible to do this without blocks.
I don't really have any idea why this doesn't work for you, to be honest. I installed the latest beta directly from TestFlight (the exact same build you have) on an iPad Air 1 that has iOS 9 beta 5 installed, and it works just fine. I just can't think of a reason why it wouldn't work on an iPad Air 2 right now.
-
Do you have a way to see my crash logs and maybe understand the problem?
I mean, it happens everytime i call an handler in every function, it shouldn't be so difficult. -
I only get aggregate crash reports, and they're delayed, so if you could send me one of yours, that might be helpful (Settings app → privacy → diagnostics & usage → diagnostics & usage data). I can't really promise that I can fix this though – as I've mentioned in the docs, the whole
ObjCBlock
feature is extremely experimental and relies on stuff that isn't really documented anywhere. -
I am currently having problems sith crash logs in iOS 9 beta 5, will send them later this week when beta 6 comes out.
Anyway i have a question.
Can you show me the simplest example of : "For blocks that don’t have a return value and no arguments, you can pass a Python function, and it’ll be converted to an ObjCBlock automatically."
? Still doing some testing and slowly understanding the mechanics -
Shortest example I can think of, though I don't really think it'll work for you if other blocks crash...
from objc_util import * NSOperationQueue = ObjCClass('NSOperationQueue') NSBlockOperation = ObjCClass('NSBlockOperation') def foobar(): print 'test' q = NSOperationQueue.mainQueue() op = NSBlockOperation.blockOperationWithBlock_(foobar) q.addOperation_(op)
-
I"m becoming crazy 😱. It crashed -.-
Until i can send you the logs i can only say you that block.invoke() crashes the app and that @on_main_thread does it too :-/ -
Could anyone else with an iPad Air 2 test this?
Unfortunately I don't have such a device here. As the OS I'm testing on is the same, I can't think of anything else that could be different, apart from the actual hardware... I don't suppose your device is jailbroken? (don't think that's possible on iOS 9, but I don't really follow this closely).
The crashes with
on_main_thread
surprise/worry me more than those with blocks, to be honest. With the blocks, I know that what I'm doing is a total hack, but theon_main_thread
stuff should be pretty standard, and uses documented APIs... -
What exactly is the problem with the crash reports btw?
-
Device is not jailbroken, True statement( if it changes something)is off.
For the logs i cant find a Pythonista-date.log but i find LatestCrash-Pythonista and LatestCrash-Pythonista2, but they're both empty Screenshot -
@filippocld said:
True statement( if it changes something)is off.
What do you mean by this?
To be honest, I'm not sure the crash reports would help me very much anyway. It's very difficult to fix something that I can't reproduce at all myself. Usually, a crash report helps with reproducing issues, and then fixing them, but from what I've seen so far, I think the problem may be hardware-specific and just not reproducible on what I have here. I might need to get an iPad Air 2 myself, though I'm a bit reluctant to buy one now, given that there will probably be new iPads in less than 2 months...
-
In Pythonista Settings there is an option called True statement, which i don't know what does, so i left it to No
For the @on_main_thread thing i remember that in the beta before the introduction of the blocks(160022) @on_main_thread was working fine.Then in beta 160023 you changed something in on_main_thead that caused the crash
From the Beta Release notes of 160023: "on_main_thread()` should be reentrant now (which means that it's possible to nest calls that are executed to the main thread -- while this mostly worked before, there were cases in which it would result in corrupted return values)."