www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Better watch out! D runs on watchOS!

reply Dan Olson <gorox comcast.net> writes:
A little progress report. More to come later when I get something pushed
to github.

I bought a returned Apple Watch yesterday at discount for $223.99 US and
tried to see how much of D would work on it using my iOS fork of LDC.
There were a few bumps, like dealing with embedded bitcode (a watchOS
requirement). After 4-hours of baby steps, little D programs with
incremental druntime support, I was able to download a huge watch app
extension with all druntime and phobos unittests and run most of them
alphabetically. Everything zipped along fine, only a std.math error,
then mysteriously a exit after running std.parallelism test a long time.
It was late for me so decided that was enough progress.

This means all of druntime worked and probably most of phobos.

The Apple Watch uses a new chip with armv7k, a different ABI, and
different exception handling than iOS, so kinda surprised it worked as
well as it did.  Of course much thanks goes to LLVM with recently added
watchOS, tvOS support, and all the LDC contributors that have kept
master building with the latest 3.8 LLVM.
-- 
Dan
Dec 27 2015
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 28 December 2015 at 01:17:15 UTC, Dan Olson wrote:
 A little progress report. More to come later when I get 
 something pushed to github.

 I bought a returned Apple Watch yesterday at discount for 
 $223.99 US and tried to see how much of D would work on it 
 using my iOS fork of LDC. There were a few bumps, like dealing 
 with embedded bitcode (a watchOS requirement). After 4-hours of 
 baby steps, little D programs with incremental druntime 
 support, I was able to download a huge watch app extension with 
 all druntime and phobos unittests and run most of them 
 alphabetically. Everything zipped along fine, only a std.math 
 error, then mysteriously a exit after running std.parallelism 
 test a long time. It was late for me so decided that was enough 
 progress.

 This means all of druntime worked and probably most of phobos.

 The Apple Watch uses a new chip with armv7k, a different ABI, 
 and different exception handling than iOS, so kinda surprised 
 it worked as well as it did.  Of course much thanks goes to 
 LLVM with recently added watchOS, tvOS support, and all the LDC 
 contributors that have kept master building with the latest 3.8 
 LLVM.
Heh, nice, thanks for keeping us up to date. I don't understand how the bitcode requirement works on your own device: I thought that was for an Apple-submitted app that they then compiled to binary themselves? Do you have to go through the same process even for test apps, ie no sideloading? Or does the device itself take bitcode? btw, Dan's iOS/tvOS/watchOS work will require these dmd/druntime github pulls to be reviewed and merged: https://github.com/D-Programming-Language/dmd/pull/5231 https://github.com/D-Programming-Language/druntime/pull/1448
Dec 27 2015
parent reply Dan Olson <gorox comcast.net> writes:
Joakim <dlang joakim.fea.st> writes:
 I don't understand how the bitcode requirement works on your own
 device: I thought that was for an Apple-submitted app that they then
 compiled to binary themselves?  Do you have to go through the same
 process even for test apps, ie no sideloading?  Or does the device
 itself take bitcode?
This is all based on my experience and I don't know the full bitcode story. I may state erroneous info below. The device takes normal executables but there is a check to make sure that each object file has the appropriate bitcode sections. I think the linker does this, but did not check which tool in build chain spit out the error. The bitcode is actually two new sections in every object file: .section __LLVM,__bitcode .section __LLVM,__cmdline The __bitcode section seems to just be the LLVM IR for the object file in the .bc binary format. Some sources say it is a xar archive but in my investigation I used Apple's clang with -fembed-bitcode and inspected the IR or ARM assembly to see these two sections. Extracting and using llvm-dis on the __bitcode section gave back the containing module's IR in human readable format. It exactly matches the LLVM IR for its object file sans Apple's clang -fembed-bitcode. So not sure when xar is used yet. The __cmdline section appears to be some of the clang options used to compile the bitcode. The compile process becomes something like this: 1. Create IR for module as usual. 2. Generate the IR bitcode representation. 3. Add the two new sections, using bitcode from (2) as contents of __bitcode section and __cmdline options to compile it 4. Generate object from IR. But not wanting to figure all that out now, I tried simpler things and discovered that at least for testing, these sections only need to be present and the contents don't seem to matter. So for now I skip 2 and just put a zero in each. On implication of Apple requiring bitcode: if Apple is compiling the bitcode with their clang or llc, then it means using a modifed LLVM like I do to support thread-locals on watchOS, tvOS, or iOS is only good for side loading. Probably going to have to work on plan B for thread-locals. -- Dan
Dec 28 2015
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 28 December 2015 at 08:45:46 UTC, Dan Olson wrote:
 Joakim <dlang joakim.fea.st> writes:
 I don't understand how the bitcode requirement works on your 
 own device: I thought that was for an Apple-submitted app that 
 they then compiled to binary themselves?  Do you have to go 
 through the same process even for test apps, ie no 
 sideloading?  Or does the device itself take bitcode?
This is all based on my experience and I don't know the full bitcode story. I may state erroneous info below. The device takes normal executables but there is a check to make sure that each object file has the appropriate bitcode sections. I think the linker does this, but did not check which tool in build chain spit out the error. The bitcode is actually two new sections in every object file: .section __LLVM,__bitcode .section __LLVM,__cmdline The __bitcode section seems to just be the LLVM IR for the object file in the .bc binary format. Some sources say it is a xar archive but in my investigation I used Apple's clang with -fembed-bitcode and inspected the IR or ARM assembly to see these two sections. Extracting and using llvm-dis on the __bitcode section gave back the containing module's IR in human readable format. It exactly matches the LLVM IR for its object file sans Apple's clang -fembed-bitcode. So not sure when xar is used yet. The __cmdline section appears to be some of the clang options used to compile the bitcode. The compile process becomes something like this: 1. Create IR for module as usual. 2. Generate the IR bitcode representation. 3. Add the two new sections, using bitcode from (2) as contents of __bitcode section and __cmdline options to compile it 4. Generate object from IR. But not wanting to figure all that out now, I tried simpler things and discovered that at least for testing, these sections only need to be present and the contents don't seem to matter. So for now I skip 2 and just put a zero in each.
Thanks for the detailed answer; I'm sure this will now become the definitive answer online. I've gone googling for technical info only to sometimes be directed back to a post in these D forums. :)
 On implication of Apple requiring bitcode: if Apple is 
 compiling the bitcode with their clang or llc, then it means 
 using a modifed LLVM like I do to support thread-locals on 
 watchOS, tvOS, or iOS is only good for side loading.  Probably 
 going to have to work on plan B for thread-locals.
Time to get emulated TLS for Mach-O into llvm, as one google engineer did with ELF for Android, which will be released in the upcoming llvm 3.8: https://code.google.com/p/android/issues/detail?id=78122
Dec 28 2015
parent Dan Olson <gorox comcast.net> writes:
Joakim <dlang joakim.fea.st> writes:
 Thanks for the detailed answer; I'm sure this will now become the
 definitive answer online.  I've gone googling for technical info only
 to sometimes be directed back to a post in these D forums. :)
Me too! Its very funny when that happens.
 Time to get emulated TLS for Mach-O into llvm, as one google engineer
 did with ELF for Android, which will be released in the upcoming llvm
 3.8:

 https://code.google.com/p/android/issues/detail?id=78122
That is Plan B.1
Dec 28 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-28 09:45, Dan Olson wrote:

 On implication of Apple requiring bitcode: if Apple is compiling the
 bitcode with their clang or llc, then it means using a modifed LLVM like
 I do to support thread-locals on watchOS, tvOS, or iOS is only good for
 side loading.  Probably going to have to work on plan B for
 thread-locals.
Would it be possible to bypass LLVM and do the thread local specific parts in LDC? -- /Jacob Carlborg
Dec 28 2015
parent reply Dan Olson <gorox comcast.net> writes:
Jacob Carlborg <doob me.com> writes:
 Would it be possible to bypass LLVM and do the thread local specific
 parts in LDC?
That is Plan B.2
Dec 28 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-28 20:02, Dan Olson wrote:

 That is Plan B.2
I'm working on implementing native TLS for OS X in DMD. I think I've figured out how everything works. Unless you already know how it works, I could tell you what I have figured out. -- /Jacob Carlborg
Dec 29 2015
parent reply Dan Olson <gorox comcast.net> writes:
Jacob Carlborg <doob me.com> writes:

 On 2015-12-28 20:02, Dan Olson wrote:

 That is Plan B.2
I'm working on implementing native TLS for OS X in DMD. I think I've figured out how everything works. Unless you already know how it works, I could tell you what I have figured out.
I know some of it from hacking dyld for iOS, but not all. How does this fit in with "Plan B.2"?
Dec 29 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-12-30 08:02, Dan Olson wrote:

 I know some of it from hacking dyld for iOS, but not all.  How does this
 fit in with "Plan B.2"?
If you need to figure out how TLS works, I can give you some help, that's all I'm saying :) -- /Jacob Carlborg
Dec 30 2015
parent reply Dan Olson <gorox comcast.net> writes:
Jacob Carlborg <doob me.com> writes:

 On 2015-12-30 08:02, Dan Olson wrote:

 I know some of it from hacking dyld for iOS, but not all.  How does this
 fit in with "Plan B.2"?
If you need to figure out how TLS works, I can give you some help, that's all I'm saying :)
Oh, good. Always like help. I'm going to start with Plan B.1 though because LLVM does nice optimizations for TLS.
Dec 30 2015
parent reply Jacob Carlborg <doob me.com> writes:
On Wednesday, 30 December 2015 at 20:55:44 UTC, Dan Olson wrote:

 I'm going to start with Plan B.1 though because LLVM does nice 
 optimizations for TLS.
What is Plan B.1? -- /Jacob Carlborg
Dec 31 2015
parent Joakim <dlang joakim.fea.st> writes:
On Thursday, 31 December 2015 at 10:10:20 UTC, Jacob Carlborg 
wrote:
 On Wednesday, 30 December 2015 at 20:55:44 UTC, Dan Olson wrote:

 I'm going to start with Plan B.1 though because LLVM does nice 
 optimizations for TLS.
What is Plan B.1? -- /Jacob Carlborg
Getting it into llvm: http://forum.dlang.org/post/m237um75x7.fsf comcast.net
Dec 31 2015
prev sibling next sibling parent reply Dan Olson <gorox comcast.net> writes:
Dan Olson <gorox comcast.net> writes:

 A little progress report. More to come later when I get something pushed
 to github.

 I bought a returned Apple Watch yesterday at discount for $223.99 US and
 tried to see how much of D would work on it using my iOS fork of LDC.
 There were a few bumps, like dealing with embedded bitcode (a watchOS
 requirement). After 4-hours of baby steps, little D programs with
 incremental druntime support, I was able to download a huge watch app
 extension with all druntime and phobos unittests and run most of them
 alphabetically. Everything zipped along fine, only a std.math error,
 then mysteriously a exit after running std.parallelism test a long time.
 It was late for me so decided that was enough progress.

 This means all of druntime worked and probably most of phobos.
Played with this a little more and learned a bit about watchOS memory. A little test that allocated memory in 5 MB chucks was terminated at 30 MB data RAM. The combined unittests in phobos suck up much more than that, std.uri itself uses over 50 MB. By tailoring memory usage and running phobos unittests in smaller block, they all work. The std.math failure was my own coding error missing a version block for WatchOS. In end, good news: druntime and phobos fully work on watchOS with LLVM optimizations disabled. With optimzations on, there are alignment problems. For example, compact unwind data generated by LLVM isn't aligned but some of our eh unwinding code casts these to uint. Not so good when the optimizer selects instructions requiring special alignment. I'll track these down gradually. -- Dan
Dec 30 2015
parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 30 December 2015 at 21:56:46 UTC, Dan Olson wrote:
 Dan Olson <gorox comcast.net> writes:

 A little progress report. More to come later when I get 
 something pushed to github.

 I bought a returned Apple Watch yesterday at discount for 
 $223.99 US and tried to see how much of D would work on it 
 using my iOS fork of LDC. There were a few bumps, like dealing 
 with embedded bitcode (a watchOS requirement). After 4-hours 
 of baby steps, little D programs with incremental druntime 
 support, I was able to download a huge watch app extension 
 with all druntime and phobos unittests and run most of them 
 alphabetically. Everything zipped along fine, only a std.math 
 error, then mysteriously a exit after running std.parallelism 
 test a long time. It was late for me so decided that was 
 enough progress.

 This means all of druntime worked and probably most of phobos.
Played with this a little more and learned a bit about watchOS memory. A little test that allocated memory in 5 MB chucks was terminated at 30 MB data RAM. The combined unittests in phobos suck up much more than that, std.uri itself uses over 50 MB. By tailoring memory usage and running phobos unittests in smaller block, they all work. The std.math failure was my own coding error missing a version block for WatchOS. In end, good news: druntime and phobos fully work on watchOS with LLVM optimizations disabled. With optimzations on, there are alignment problems. For example, compact unwind data generated by LLVM isn't aligned but some of our eh unwinding code casts these to uint. Not so good when the optimizer selects instructions requiring special alignment. I'll track these down gradually.
That sounds like this issue I ran into with ARM EH: https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075 I was able to work around it by disabling the mentioned llvm optimization pass: https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a#file-android_tls-L42 https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3133
Dec 30 2015
parent reply Dan Olson <gorox concast.net> writes:
On Wednesday, 30 December 2015 at 23:11:06 UTC, Joakim wrote:
 That sounds like this issue I ran into with ARM EH:

 https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075

 I was able to work around it by disabling the mentioned llvm 
 optimization pass:

 https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a#file-android_tls-L42

 https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3133
Yup, that's exactly it! The approach I took was to leave optimization on, removed the casts, and byte load the data into the uint vars. If the dwarf data is not guaranteed to be aligned to the data type, then I think this is the approach to take.
Dec 30 2015
parent reply Joakim <dlang joakim.fea.st> writes:
On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote:
 On Wednesday, 30 December 2015 at 23:11:06 UTC, Joakim wrote:
 That sounds like this issue I ran into with ARM EH:

 https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075

 I was able to work around it by disabling the mentioned llvm 
 optimization pass:

 https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a#file-android_tls-L42

 https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3133
Yup, that's exactly it! The approach I took was to leave optimization on, removed the casts, and byte load the data into the uint vars. If the dwarf data is not guaranteed to be aligned to the data type, then I think this is the approach to take.
Sounds good, submit a PR and let's get it in.
Dec 30 2015
next sibling parent reply Dan Olson <gorox comcast.net> writes:
Joakim <dlang joakim.fea.st> writes:

 On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote:
 On Wednesday, 30 December 2015 at 23:11:06 UTC, Joakim wrote:
 That sounds like this issue I ran into with ARM EH:

 https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075

 I was able to work around it by disabling the mentioned llvm
 optimization pass:

 https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a#file-android_tls-L42

 https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3133
Yup, that's exactly it! The approach I took was to leave optimization on, removed the casts, and byte load the data into the uint vars. If the dwarf data is not guaranteed to be aligned to the data type, then I think this is the approach to take.
Sounds good, submit a PR and let's get it in.
Was planning to get that PR going then got side tracked by a more difficult ARM exeption unwinding bug. It happens in std.random unittest at LDC -O2 or higher. Does this sound familiar Joakim? The bug is a bad stack pointer which blows up when the last unittest returns. This unittest has all the right conditions to generate stack adjustments around some of the function calls that throw exceptions. The exception landing pad does not fixup the stack adjustment, thus a stack leak on each caught exception. The unittest function epilog restores the stack by adding a fixed offset to match the prolog, so the stack pointer stays wrong when the saved registers and return address are popped. Really looks like LLVM is not doing the right thing with landing pads. In the meantime I patched LLVM to generate epilog that always uses frame pointer to restore the stack pointer. WatchOS requires a frame pointer, so this isn't too bad. Now all unittests pass at -O3 for watchOS. I am guessing iOS is not effected since it uses SjLj to restore the stack after an exception is thrown. I'll have to pursue this later. My mind is freed up for the original PR. -- Dan
Jan 04
parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 4 January 2016 at 09:26:39 UTC, Dan Olson wrote:
 Joakim <dlang joakim.fea.st> writes:

 On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote:
 [...]
Sounds good, submit a PR and let's get it in.
Was planning to get that PR going then got side tracked by a more difficult ARM exeption unwinding bug. It happens in std.random unittest at LDC -O2 or higher. Does this sound familiar Joakim?
Yep, except tests were failing in three unittest blocks with -O1 too, but I never looked into exactly why: https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3139
 The bug is a bad stack pointer which blows up when the last 
 unittest returns.  This unittest has all the right conditions 
 to generate stack adjustments around some of the function calls 
 that throw exceptions. The exception landing pad does not fixup 
 the stack adjustment, thus a stack leak on each caught 
 exception.  The unittest function epilog restores the stack by 
 adding a fixed offset to match the prolog, so the stack pointer 
 stays wrong when the saved registers and return address are 
 popped.

 Really looks like LLVM is not doing the right thing with 
 landing pads. In the meantime I patched LLVM to generate epilog 
 that always uses frame pointer to restore the stack pointer.  
 WatchOS requires a frame pointer, so this isn't too bad.  Now 
 all unittests pass at -O3 for watchOS.
Could be the same issue for me, not sure. If you put your fix online, I can try it and see.
 I am guessing iOS is not effected since it uses SjLj to restore 
 the stack after an exception is thrown.  I'll have to pursue 
 this later.  My mind is freed up for the original PR.
That one is much simpler, let's get it in.
Jan 04
next sibling parent Dan Olson <gorox comcast.net> writes:
Joakim <dlang joakim.fea.st> writes:

 On Monday, 4 January 2016 at 09:26:39 UTC, Dan Olson wrote:
 Joakim <dlang joakim.fea.st> writes:
 The bug is a bad stack pointer which blows up when the last unittest
 returns.  This unittest has all the right conditions to generate
 stack adjustments around some of the function calls that throw
 exceptions. The exception landing pad does not fixup the stack
 adjustment, thus a stack leak on each caught exception.  The
 unittest function epilog restores the stack by adding a fixed offset
 to match the prolog, so the stack pointer stays wrong when the saved
 registers and return address are popped.

 Really looks like LLVM is not doing the right thing with landing
 pads. In the meantime I patched LLVM to generate epilog that always
 uses frame pointer to restore the stack pointer.  WatchOS requires a
 frame pointer, so this isn't too bad.  Now all unittests pass at -O3
 for watchOS.
Could be the same issue for me, not sure. If you put your fix online, I can try it and see.
It is this commit based on a 2 week old LLVM 3.8 trunk: https://github.com/smolt/llvm/commit/91a4420615c6ec83b227b63d36054f12ccffb00f A small change but took me a long time in debugger on an Apple Watch to figure out. Something the x86 simulator can't show. It is tailored to watchOS which uses thumb2 instructions. watchOS always has a frame, hasFP() is always true. You will want to add Android to the hasFP() or disable frame pointer elimination some other way. I noticed that -disable-fp-elim for LDC with LLVM 3.7 and above is broken so can't use that. The pattern to look for if you have a suspect is this: A function that throws an exception is codegened with stack adjustment surrounding the call: sub sp, #16 str r1, [sp] mov r1, r2 movs r0, #66 movw r2, #2424 blx __D3std9exception25__T7bailOutHTC9ExceptionZ7bailOutFNaNfAyakxAaZv add sp, #16 <--- This adjustment is missed on exception Epilog without hack (llvm 3.8 git 0838b1f Add iOS TLS support for WatchOS) itttt ne addne.w sp, sp, #9984 <-- stack adjust matches prolog, but stack is off by 16 bytes if above throws addne sp, #48 popne.w {r8, r10, r11} popne {r4, r5, r6, r7, pc} Epilog with hack (commit 91a4420) itttt ne subne.w r4, r7, #24 <-- stack set from frame pointer (r7) movne sp, r4 popne.w {r8, r10, r11} popne {r4, r5, r6, r7, pc} -- Dan
Jan 04
prev sibling parent Dan Olson <gorox comcast.net> writes:
Joakim <dlang joakim.fea.st> writes:

 On Monday, 4 January 2016 at 09:26:39 UTC, Dan Olson wrote:
 Joakim <dlang joakim.fea.st> writes:

 On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote:
 [...]
Sounds good, submit a PR and let's get it in.
Was planning to get that PR going then got side tracked by a more difficult ARM exeption unwinding bug. It happens in std.random unittest at LDC -O2 or higher. Does this sound familiar Joakim?
Yep, except tests were failing in three unittest blocks with -O1 too, but I never looked into exactly why: https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3139
I must add, I don't think the optimizer or inliner are the cause of this unwinding bug. They are just good at making big functions. I think I could create the same bug at -O0.
Jan 04
prev sibling parent Dan Olson <gorox comcast.net> writes:
Joakim <dlang joakim.fea.st> writes:

 On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote:
 On Wednesday, 30 December 2015 at 23:11:06 UTC, Joakim wrote:
 That sounds like this issue I ran into with ARM EH:

 https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075

 I was able to work around it by disabling the mentioned llvm
 optimization pass:

 https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a#file-android_tls-L42

 https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3133
Yup, that's exactly it! The approach I took was to leave optimization on, removed the casts, and byte load the data into the uint vars. If the dwarf data is not guaranteed to be aligned to the data type, then I think this is the approach to take.
Sounds good, submit a PR and let's get it in.
https://github.com/ldc-developers/druntime/pull/51
Jan 06
prev sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Monday, 28 December 2015 at 01:17:15 UTC, Dan Olson wrote:
 A little progress report. More to come later when I get 
 something pushed to github.

 I bought a returned Apple Watch yesterday at discount for 
 $223.99 US and tried to see how much of D would work on it 
 using my iOS fork of LDC. There were a few bumps, like dealing 
 with embedded bitcode (a watchOS requirement). After 4-hours of 
 baby steps, little D programs with incremental druntime 
 support, I was able to download a huge watch app extension with 
 all druntime and phobos unittests and run most of them 
 alphabetically. Everything zipped along fine, only a std.math 
 error, then mysteriously a exit after running std.parallelism 
 test a long time. It was late for me so decided that was enough 
 progress.

 This means all of druntime worked and probably most of phobos.

 The Apple Watch uses a new chip with armv7k, a different ABI, 
 and different exception handling than iOS, so kinda surprised 
 it worked as well as it did.  Of course much thanks goes to 
 LLVM with recently added watchOS, tvOS support, and all the LDC 
 contributors that have kept master building with the latest 3.8 
 LLVM.
Fantastic news, Dan. I can confirm that D also runs on Android Wear (Huawei watch) and passes all unit tests. Forgive the slight hijack, but I mention this here as people might see this thread and not the obscure one where I reported this previously. Somebody should do a blog post about this (and how to get it to work step by step - it's easy when you know how, but the set of people that don't and would like to but will get stuck is quite large). I might have a commercial use for this in coming months (both on Android and watchOS). Since it's an internal application the rough edges are of less concern to me than if one expects 100,000+ users. Wrappers for everything would help a lot (and then some tutorials) - I guess the Apple stuff is under way. Joakim has a binding for JNI, but would be nice to wrap so easier to use (and then build Android SDK wrappers on top of that. I saw this project here, but haven't yet tried: https://github.com/Monnoroch/DJni I guess the spirit of what Xamarin do with their stuff might be a model. Could this be a useful Google Summer of Code Project? Or is it too dull for the kinds of people that might be interested.
Jan 05
next sibling parent Joakim <dlang joakim.fea.st> writes:
On Tuesday, 5 January 2016 at 20:39:02 UTC, Laeeth Isharc wrote:
 On Monday, 28 December 2015 at 01:17:15 UTC, Dan Olson wrote:
 [...]
Fantastic news, Dan. I can confirm that D also runs on Android Wear (Huawei watch) and passes all unit tests. Forgive the slight hijack, but I mention this here as people might see this thread and not the obscure one where I reported this previously. [...]
You two might have to write that post together, since you're the only two reporting running D on watches so far! :)
 I might have a commercial use for this in coming months (both 
 on Android and watchOS).  Since it's an internal application 
 the rough edges are of less concern to me than if one expects 
 100,000+ users.

 [...]
This should be pretty easy, it won't qualify as a GSoC project on its own. btw, sent you an email, let me know if you didn't get it.
Jan 05
prev sibling parent reply Dan Olson <gorox comcast.net> writes:
Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:

 I can confirm that D also runs on Android Wear (Huawei watch) and
 passes all unit tests.  Forgive the slight hijack, but I mention this
 here as people might see this thread and not the obscure one where I
 reported this previously.
I think it is a good hijack!
 Somebody should do a blog post about this (and how to get it to work
 step by step - it's easy when you know how, but the set of people that
 don't and would like to but will get stuck is quite large).
For watchOS, soon there will be a binary release of cross compiler with phobos and will have instructions like I have for the iOS release. What is holding me up is I still am trying to decide how to manage multiple releases (iOS, tvOS, and watchOS) since the libraries are all different but the compiler is the same. It doesn't fit the mold but I'd like to have a single bin with multiple libs.
 I might have a commercial use for this in coming months (both on
 Android and watchOS).  Since it's an internal application the rough
 edges are of less concern to me than if one expects 100,000+ users.
Laeeth, note that app store approval may be a ways off since they want to use their own LLVM to compile bitcode and I have patches not in official LLVM. If you only need to side load watchOS, then you will soon be good to go.
 Wrappers for everything would help a lot (and then some tutorials) - I
 guess the Apple stuff is under way.
The D Objective-C interface is not in LDC yet and I think what is in dmd so far only supports a subset (instance method calls I think). There are other ways, depending on what you need to do, but right know it seems best to do all the UI stuff in Swift or Objective-C and use D for everything else. -- Dan
Jan 06
parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Wednesday, 6 January 2016 at 17:35:07 UTC, Dan Olson wrote:
 Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:

 I think it is a good hijack!
Thanks..
 Somebody should do a blog post about this (and how to get it 
 to work step by step - it's easy when you know how, but the 
 set of people that don't and would like to but will get stuck 
 is quite large).
For watchOS, soon there will be a binary release of cross compiler with phobos and will have instructions like I have for the iOS release. What is holding me up is I still am trying to decide how to manage multiple releases (iOS, tvOS, and watchOS) since the libraries are all different but the compiler is the same. It doesn't fit the mold but I'd like to have a single bin with multiple libs.
Yes can imagine it gets messy quickly yet is a lot of work to integrate.
 I might have a commercial use for this in coming months (both 
 on Android and watchOS).  Since it's an internal application 
 the rough edges are of less concern to me than if one expects 
 100,000+ users.
Laeeth, note that app store approval may be a ways off since they want to use their own LLVM to compile bitcode and I have patches not in official LLVM. If you only need to side load watchOS, then you will soon be good to go.
Appreciate the colour. Side loading fine for now, and actual use is realistically some way off as I have a lot of other things to do as well. I am in a funny business where the fewer the users I have the better (for x>=1) so my concerns are different from someone making a consumer app.
 Wrappers for everything would help a lot (and then some 
 tutorials) - I guess the Apple stuff is under way.
The D Objective-C interface is not in LDC yet and I think what is in dmd so far only supports a subset (instance method calls I think). There are other ways, depending on what you need to do, but right know it seems best to do all the UI stuff in Swift or Objective-C and use D for everything else.
Yes - I haven't looked at Apple at all as I have too many computers already as it is and don't have a Mac. I wonder if it is possible to implement something like what I understand Corona have done for C# in D: make a common layer for what can be shared so work involved in customisation for each platform is minimised. I guess we are at a point now that the heavy lifting is done where some small success stories can inspire others to have a try and the ecosystem can grow.
Jan 06
parent Rory McGuire via Digitalmars-d-announce writes:
I'm thinking something like https://www.polymer-project.org/1.0/ written as
http://jade-lang.org which compiles to "target" being either android, ios,
Web, or native. There is dlangui which already mimics the android ui
library to some extent.

What do you think?
On 07 Jan 2016 07:15, "Laeeth Isharc via Digitalmars-d-announce" <
digitalmars-d-announce puremagic.com> wrote:

 On Wednesday, 6 January 2016 at 17:35:07 UTC, Dan Olson wrote:

 Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:

 I think it is a good hijack!
Thanks..
 Somebody should do a blog post about this (and how to get it to work step
 by step - it's easy when you know how, but the set of people that don't and
 would like to but will get stuck is quite large).
For watchOS, soon there will be a binary release of cross compiler with phobos and will have instructions like I have for the iOS release. What is holding me up is I still am trying to decide how to manage multiple releases (iOS, tvOS, and watchOS) since the libraries are all different but the compiler is the same. It doesn't fit the mold but I'd like to have a single bin with multiple libs.
Yes can imagine it gets messy quickly yet is a lot of work to integrate.
 I might have a commercial use for this in coming months (both on Android
 and watchOS).  Since it's an internal application the rough edges are of
 less concern to me than if one expects 100,000+ users.
Laeeth, note that app store approval may be a ways off since they want to use their own LLVM to compile bitcode and I have patches not in official LLVM. If you only need to side load watchOS, then you will soon be good to go.
Appreciate the colour. Side loading fine for now, and actual use is realistically some way off as I have a lot of other things to do as well. I am in a funny business where the fewer the users I have the better (for x>=1) so my concerns are different from someone making a consumer app. Wrappers for everything would help a lot (and then some tutorials) - I
 guess the Apple stuff is under way.
The D Objective-C interface is not in LDC yet and I think what is in dmd so far only supports a subset (instance method calls I think). There are other ways, depending on what you need to do, but right know it seems best to do all the UI stuff in Swift or Objective-C and use D for everything else.
Yes - I haven't looked at Apple at all as I have too many computers already as it is and don't have a Mac. I wonder if it is possible to implement something like what I understand Corona have done for C# in D: make a common layer for what can be shared so work involved in customisation for each platform is minimised. I guess we are at a point now that the heavy lifting is done where some small success stories can inspire others to have a try and the ecosystem can grow.
Jan 07