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
-
@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)."
-
That's very interesting information, thanks!
I think you mean the "True Divisison" setting – that shouldn't make a difference at all, it's just for the interactive console, and determines whether something like
5/2
evaluates to2
or2.5
. -
Oh, then that's useful :-) thanks
-
I just ordered an iPad Air 2 that I'll pick up later today. I'm curious if the issue is reproducible, though I'm really not sure if I can fix it, even if it is – it might be too low-level... In any case, it'll be useful to test the new split-screen stuff in iOS 9 as well...
-
Good! Hope will fix both the crashes or at least one of them.
I am kinda angry when i make a iOS 9 api scripts(Replaykit,Search Apis,Touch id etc.) and cant use it because blocks crash and on main thread crashes too -
Okay, I have the new iPad set up for development, and it really seems like this is a hardware-specific issue. I can at least reproduce your crashes now... haven't really investigated this much further yet, just wanted to let you know that I don't really need crash reports anymore.
-
Oh, thanks! Finally im not only the one with theese problems.
Looking forward for more infos.
Thanks in advance
Filippo -
I think I've made some progress! :)
It seems that some compiler optimizations were responsible for the crashes. I have no idea why this only happens on the A8X (or why it happens at all, to be honest), but after I've recompiled libffi (the library ctypes is based on) with a lower optimization level, everything seems to work fine on the iPad Air 2.
I'll need to do a little more testing to make sure that this doesn't somehow break things on other devices, but I'm pretty optimistic that I can fix the crashes you've seen with the next build.
-
This is Fantastic!
Thanks, if all goes well i will seriously enjoy using objcutil!
Waiing for the next build
Thanks in advance,
Filippo -
Knowing a fair bit about processor architectures - S/360 from 1964 application code running unchanged on z13 in 2015 :-) - I'm surprised a NEW processor should have problems with instructions that worked before. Maybe the optimisations were timing-dependent and the compiler authors got that wrong.
So I'd expect A8X issues to be more pervasive.
But we live and learn.