Presenting ViewController

omz

Hmm. What kind of device do you have? Could be that it doesn't work on 32 bit...

filippocld

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

omz

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.

filippocld

Ok, will try to solve it by me :-/
If you find something that could cause crashes tell me

filippocld

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 blocks

Hope this helps solving the bug,
Filippo

omz

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.

filippocld

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

ywangd

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. The replaykit was not created successfully. The bundleWithPath_ method returned a None for me.

filippocld

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

filippocld

Ok, @omz in the meantime can you show me how to do with delegates, please? :-)
Would be much appreciated

omz

@filippocld said:

Ok, @omz in the meantime can you show me how to do with delegates, please? :-)
Would be much appreciated

Turns 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.

filippocld

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.

omz

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.

filippocld

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

omz

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)

filippocld

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 :-/

omz

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 the on_main_thread stuff should be pretty standard, and uses documented APIs...

omz

What exactly is the problem with the crash reports btw?

filippocld

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

omz

@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...