Few cents about my commits
DISCLAIMER: its not possible to create watchOS application with RoboVM. This tutorial describes how embed one created in Xcode as companion to RoboVM iOS application.
To package watchOS app RoboVM was adapted to handle packaging, signing and launching (on a simulator).
Code: experimental code was pushed to dkimitsa/watchkit-support branch.
(skip long read and start embedding watchOS app)
It becomes problematic to marshal methods that return NSArray<id<PROTOCOL>> like bellow:
- (void)readerSession:(NFCReaderSession *)session
didDetectTags:(NSArray<__kindof id<NFCTag>> *)tags;
Direct binding will not compile:
There was a rare bug when debug session in Intellij Idea failed and hang. It was not possible to terminate it without reopening the project.
Issue was reproduced while by having broken deployment to simulator step that allowed to investigate and locate the root case.
The root case – Idea hangs on waiting for stdout/stderr to be closed on terminated (due fail to deploy to sim) process.
Root case 1: the way stdout was redirected:
stdout -> FIFO FILE -> input stream
Root case 2: wrapper process class ProcessProxy around launcher process that was never returned stream to Idea but was never closing it (here it hangs).
AbstractLauncherProcess class. Specific implementations just extends it;stdout (as part of FIFO replacement) - required by JUNIT plugin;<target>console</target>.AltPods were update to v1.7.0-SNAPSHOTS to sync with recent releases. Part of list didn’t receive any API update hovewer bindings were re-generated against recent version of frameworks. Update list look as bellow:
v6.24.0v6.12.4v0.33.1v3.5.0v7.0.0v6.24.0v7.7.1v3.1.8v2.31.1v5.2.5v1.5.3These pods were pushed to https://oss.sonatype.org/content/repositories/snapshots maven repo under 1.7.0-SNAPSHOTS version.
Source code @github
Updates are not fullty tested, please open issue if bug found.
NB: AltPods – are robopods kept at my personal standalone repo. This is done to prevent main robopods repo from turning into code graveyard. As these pods have low interest of community and low chances to be updated.
PR475 delivers an amount of fixes related to the debugger:
Root case is changes in previous improvement: debugger reports now only line number where breakpoint can be hit.
Improvement was to re-use breakpoint map structure as lines available for breakpoints. Debugger resolves that map when line map is being requested.
If all lines in the method are available for breakpoints and number of lines is even to eight this results in available for breakpoints map completely filled with zeroes. Linker puts zero filled memory structures to __bss data segment. Debugger was not expecting symbols in this segment and was crashing with unable to resolve symbol exception.
The fix: refactored buffer reader and added ZeroReader to support .bss data segment.
this happens when stepping over code similar to bellow:
inner class Test2()
fun test() {
print(1)
Test2() // stepping over
print(2) // will not stop here first time
}
Root case: is class loaded event from device/simulator that suspends thread. Once thread is suspended all stepping constraints removed. Debugger after receiving class loaded even tells the target to resume. But there is no stepping constraint available anymore.
The fix: restore stepping constraint in device on thread resume if stepping is active.
The issue can be observed in code similar to bellow:
fun test() {
/*7*/ list.forEachIndexed { index, str ->
/*8*/ text = str + index // <-- will not step or stop at this line
/*9*/ }
}
Kotlin injects collections code to user class under extended line number range and uses SMAP to map extended range into class line number range. Example above turned into following pseudo code after SMAP un-mapping:
fun test() {
/*7*/ val l = list as Iterable<String>; var idx = 0;
/*8*/ val it = l.iterator(); while(it.hasNext()) { val str = it.next(); text = str + idx++ }
}
As result there is multiple operation an line 8. but only one breakpoint/stop point will be instrumented before first operation in line. This results in breakpoint/stop point injected before l.iterator() and no one inside the loop.
The fix: inject stop/breakpoint hooks before SMAP line numbers unmapped and code get collapsed in single line.
Binary was not stripped before as strip removes local symbols as result debugger was not able to resolve required symbols.
To support stripping its requires to pre-save symbols debugger depends on. This was done by putting these into exported symbols list.
Having binary stripped results in following (sample data based on empty project, x86_64 simualator):
Code to manipulate memory buffer refactored to provide abstract interface instead of ByteBuffer centric implementation. Code refactored to use interfaces that allows to provide implementation with different data source. For example NullReader to simulate reading from .bss segment.
Also, it allows to have future improvements required for windows builds (workaround for mapped file issues).
Initially it was mistake to make .spfpoffset symbols global as it resulted in many “symbol already defines” error.
Root case of it is LLVM emitter who adds .spfpoffset for all functions (even always inline or private). As result there was many private symbols with same name turned into global.
Situation was fixed (for having binary stip sake) by reworking the way .spfpoffset retrieved:
was:
llvm.used just to survive dead code elimination;.spfpoffset runtime and fetched value;now:
.spfpoffset is being fetched from object file;.spfpoffset is not required anymore and can be eliminated as not used.Debugger module reworked to be independed from LLVM/Compiler module. Now its stand-alone module. Instead following was changed:
compiler module has direct dependency to debugger;idea/eclipse/maven/gradle plugins don’t depend anymore on debugger (as it is part of compiler now);RoboVm compiler is able to detect swift usage in dynamic frameworks and copies all required swift libraries into application bundle.
Same logic (calling otool -L) doesn’t work for static libraries (.a) and static frameworks.
While xcframework and better logic (instead of otool -L) is still in development workaround was introduced to unblock community:
swift libraries have to be manually listed in
robovm.xml:
Example:
<libs>
<lib>libswiftCore.dylib</lib>
<lib>libswiftCore.dylib</lib>
<lib>libswiftCoreFoundation.dylib</lib>
<lib>libswiftCoreGraphics.dylib</lib>
<lib>libswiftCoreImage.dylib</lib>
<lib>libswiftDarwin.dylib</lib>
<lib>libswiftDispatch.dylib</lib>
<lib>libswiftFoundation.dylib</lib>
<lib>libswiftMetal.dylib</lib>
<lib>libswiftObjectiveC.dylib</lib>
<lib>libswiftQuartzCore.dylib</lib>
<lib>libswiftUIKit.dylib</lib>
</libs>
Simplest way to find out list of required swift libraries is to use otool -l libOne.a | grep "\-lswift".
Now compiler detects swift library in dependencies and applies logic similar to dynamic frameworks:
Code was delivered as PR474.
AltPods were update to v1.6.0-SNAPSHOTS to sync with recent releases. Part of list didn’t receive any API update hovewer bindings were re-generated against recent version of frameworks. Update list look as bellow:
v6.18.0v6.11.5v6.2.0v6.18.0v7.7.0v0.34.0v3.4.0v3.1.6v2.11.6v5.2.5v1.5.3These pods were pushed to https://oss.sonatype.org/content/repositories/snapshots maven repo under 1.6.0-SNAPSHOTS version.
Source code @github
Updates are not fullty tested, please open issue if bug found.
NB: AltPods – are robopods kept at my personal standalone repo. This is done to prevent main robopods repo from turning into code graveyard. As these pods have low interest of community and low chances to be updated.
bindings have arrived as PR458.
selectively updated frameworks based on api diff
binding preview based on Xcode11.4 BETA 2, following was updated:
Previous improvement simplified way Framework target was created right out the box without need to write native code. But it didn’t allow creating objects native way and workaround was to use single point singleton and consider objects as protocols. RoboVM creates objects runtime using objc/runtime API so there is no information available during linkage phase. And a try to use it will cause symbol not found exception like this:
Undefined symbols for architecture x8664: “_OBJC_CLASS$_RoboClass”, referenced from: objc-class-ref in ViewController.o
The goal of this Improvement:
In general it should be enough:
let demo = MyFrameworkDemo(text: "demo")!
print(demo.roboVmVersion()!)
// or
MyFrameworkDemo *demo = [[MyFrameworkDemo alloc] initWithText:@"demo"];
NSLog(@"%@", [demo roboVmVersion]);
(skip long read and start creating framework)
Idea run configuration might become invalid if configured items become invalid, like:
In this case compilation failed with runtime exception. But once run configuration editor is opened instead of pointing to invalid items editor was auto picking up first one available. As result user was not able to see a problem and to have configuration overridden changes to it to be done. Otherwise apply button was not active.
To identify signing identity/simulator/provisioning profile its name was saved. For auto value just auto text placeholder was saved and checked against. This is subject for name collisions.
Field that might be auto (Signing identity/Provisioning profile/Simulator) are now have separate parameter in config file that specifies entry type: auto or explicit ID. And auto mode is identified by it and not string constant in entry name.
When explicit entry is used (e.g. not auto) entries id is saved instead of entry name (udid for profile/simulator, footprint for signing identity). No collision anymore.
Simulator field receives two modes auto iPhone and auto iPad. These modes acts similarly to gradle’s one ‘launchIPhoneSimulator’/launchIPadSimulator.
Also in case there is no simulator available in system it will allows to recover broken run configuration.
Problem fields can be quick fixed to auto value with Fix button.
Default thumbv7 was a problem as is not available since ios11 (on most devices today). This caused deployment error at very end of run cycle. Having arm64 default improves user experience.
Similar issue to arm64. It 32bit code doesn’t run on ios11+ simulators.
don't sign optionsdon't sign option was for usage with jailbroken ios devices. While having free provisioning from Apple this option have no more sense. Also ldid binary was removed. If don't sign option is specified from gradle/maven ADHOC signing will be performed.
Created from template gradle projects were broken due:
Now: gradle uses internal JDK, java source level forced to Java8.
Apple Development certificatesThese were not part of regex and were ignored when auto identity was specified.
If simulator process is terminated by Idea strange error message was printed into console log:
Process finished with exit code -559038737
This code is UNKNOWN_CODE constant in Executor. Now it is being recognized and replaced with 0.
Code was delivered as PR456