Re: It's alive! D building D building D, all on Android

[Dan Olson via Digitalmars-d-announce]

Quite nice!

Re: Live streaming of DConf 2016: confirmed

[Dan Olson via Digitalmars-d-announce]

Joakim  writes:
>>> Sound doesn't work in the official Ustream Android app either for
>>> the Dconf stream, as I noted.  My guess would be that the HTML5
>>> player and the Android app try to use whatever audio codecs are
>>> built into Android, instead of the app using its own codecs, and
>>> the codec chosen by the Dconf livestream is not normally supported
>>> on Android for whatever reason.
>>
>> Also, no audo with iPhone or OS X.  Even downloaded Ustream app.
>> Must be an upstream problem.  Looks like Kai is giving a nice talk
>> though.
>
> Doeme on the irc channel #D found an archived Ustream link that works
> on VLC and MX Player on Android, I extracted the other three.  Use
> those video players' dialogs to open a network stream and paste in
> these URLs to watch the talks from yesterday.

Yup, listening to yesterday's keynote now with VLC.  Still no audio for
the live stream.

Does anybody have audio working live?  What are you using to listen
with?

Re: Live streaming of DConf 2016: confirmed

[Dan Olson via Digitalmars-d-announce]

Joakim  writes:

> On Wednesday, 4 May 2016 at 09:13:12 UTC, Dženis Kiderič wrote:
>> On Wednesday, 4 May 2016 at 09:04:38 UTC, Dicebot wrote:
>>> On Wednesday, 4 May 2016 at 08:33:47 UTC, Joakim wrote:
 There appears to be a problem with the sound on Ustream with
 Android, at least for me: there is none.  I've tried it on a Sony
 phone and a Samsung tablet, both with the HTML5 player in the
 browser and the Android app.  All other streams work, which
 suggests it's a problem with the Dconf stream.

 My guess is that the Dconf stream is using an audio codec that
 Ustream doesn't support on Android, and it's silently failing, in
 more ways than one.  If anyone else can reproduce this and maybe
 try to fix it by changing the audio codec, if possible, that'd be
 great.
>>>
>>> Have reported it to A/V team, will see if they can fix it timely.
>>
>> Can it be html5 ?
>>
>> https://support.ustream.tv/hc/en-us/articles/208999037-New-Ustream-Player-Overview
>
> Sound doesn't work in the official Ustream Android app either for the
> Dconf stream, as I noted.  My guess would be that the HTML5 player and
> the Android app try to use whatever audio codecs are built into
> Android, instead of the app using its own codecs, and the codec chosen
> by the Dconf livestream is not normally supported on Android for
> whatever reason.

Also, no audo with iPhone or OS X.  Even downloaded Ustream app.  Must
be an upstream problem.  Looks like Kai is giving a nice talk though.

Re: LDC 1.0.0-beta1 has been released! Please help testing!

[Dan Olson via Digitalmars-d-announce]

Kai Nacke  writes:

> Hi everyone,
>
> LDC 1.0.0-beta1, the LLVM-based D compiler, is available for download!
> This BETA release is based on the 2.070.2 frontend and standard
> library and supports LLVM 3.5-3.8.
>
> The 1.0 release will be a major milestone. Please help testing to make
> it the best release ever!
> We provide binaries for Linux, OX X, Win32 & Win64, Linux/ARM
> (armv7hf). :-)
>
> As usual, you can find links to the changelog and the binary packages
> over at digitalmars.D.ldc:
> http://forum.dlang.org/post/bwrnvztwkzhhwhzsk...@forum.dlang.org
>
> Regards,
> Kai

Just a note for Pi 2 and 3 owners running Raspian.  Even though Raspian
defaults to armv6, the LDC 1.0.0-beta1 binary for armv7 can be used with
a little symlinking:

$ cd /usr/lib/arm-linux-gnueabihf/
$ ln -s libedit.so libedit.so.0

LDC works great for Pi 1 too, but being armv6, Pi 1 owners will need to
bootstrap by downloading and building ldc ltsmaster branch (C++
version).  I suppose at some point, Raspian will have this version of
LDC available with apt-get.
--
Dan

Re: TECO - Inspiration for the D programming language

[Dan Olson via Digitalmars-d-announce]

Walter Bright  writes:
>
> https://www.reddit.com/r/programming/comments/4e07lo/last_night_in_a_fit_of_boredom_far_away_from_my/d1x5rl7

I am tempted to try it on my TOPS-10 (PDP-10) account at LCM. I believe
TECO is installed.
-- 
Dan

Re: LDC 0.17.0-beta1 has been released!

[Dan Olson via Digitalmars-d-announce]

Adrian Matoga  writes:

> On Thursday, 14 January 2016 at 20:33:30 UTC, Kai Nacke wrote:
>> LDC 0.17.0-beta1, the LLVM-based D compiler, is available for
>> download!
>> This release is based on the 2.068.2 frontend and standard library
>> and supports LLVM 3.5-3.7.
>
> Excellent! Works great so far (Linux x86_64).
> Any chance of having pre-built binaries for cross-compiling to
> arm-linux-gnueabihf, like in GDC distributions?

Yes, though not sure when.  I have a Raspberry Pi (armv6) and will begin
working with LDC on it soon.  I don't know how compatible
arm-linux-gnueabihf builds are between various ARM systems, but this
could be stepping stone toward a pre-built binary for LDC.
-- 
Dan

Re: LDC 0.17.0-beta1 has been released!

[Dan Olson via Digitalmars-d-announce]

Manu via Digitalmars-d-announce  writes:
>
> Love your work guys! Thanks for keeping at it.
>
> One question though, what's the plan for moving to DMD latest? Both
> LDC and GDC seem to be quite behind at the moment.
> My current project is depending on bug-fixes patched in by Walter in
> the last few days, so I'm stuck with DMD for the moment.

Process of merging 2.069 with D frontend into LDC has been started by
Johan.

I imagine LDC will always be a 1 or 2 releases behind DMD with current
number of contributers.  I notice much work goes into supporting other
targets, platforms besides what DMD supports.  With more help, it could
be kept up to a release behind.  David and Kai make LDC an easy, fun
project to contribute to.

For your specific patch, sometimes LDC will cherry-pick important
commits.
-- 
Dan

Re: D runs on watchOS! and on Android Wear too!

[Dan Olson via Digitalmars-d-announce]

Laeeth Isharc  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

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

Joakim  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

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

Joakim  writes:

> On Monday, 4 January 2016 at 09:26:39 UTC, Dan Olson wrote:
>> Joakim  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.

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

Joakim  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

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

Joakim  writes:

> On Monday, 4 January 2016 at 09:26:39 UTC, Dan Olson wrote:
>> Joakim  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
movsr0, #66
movwr2, #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)
i   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)
i   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

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

Jacob Carlborg  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.

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

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.

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

Jacob Carlborg  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"?

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

Joakim  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

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

Jacob Carlborg  writes:
>
> Would it be possible to bypass LLVM and do the thread local specific
> parts in LDC?

That is Plan B.2

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

Joakim  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

Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

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

Re: LDC 0.17.0-alpha1 has been released!

[Dan Olson via Digitalmars-d-announce]

Kai Nacke  writes:

> Hi everyone,
>
> LDC 0.17.0-alpha1, the LLVM-based D compiler, is available for
> download!
> This release is based on the 2.068.2 frontend and standard library and
> supports LLVM 3.5-3.7.
>
> Don't miss to check if your preferred system is supported by this
> release. We also have a Win64 compiler available!
>
> As usual, you can find links to the changelog and the binary packages
> over at digitalmars.D.ldc:
> http://forum.dlang.org/thread/zwoixfjuagmwvlyat...@forum.dlang.org
>
> Regards,
> Kai

The ldc cross-compiler for iOS (iphoneos-ldc2) has been updated to match
0.17.0-alpha1.

https://github.com/smolt/ldc-iphone-dev/releases/tag/ios-0.17.0-151221

Somebody have fun,
-- 
Dan

Re: iOS LDC 0.16.1 (2.067.1) binaries available

[Dan Olson via Digitalmars-d-announce]

Joakim  writes:

> On Saturday, 7 November 2015 at 19:20:02 UTC, Dan Olson wrote:
>> Dan Olson  writes:
>>
>>> Joakim  writes:
 btw, std.internal.math.gammafunction hasn't given me a problem
 since 2.067.1, the Win64 guys fixed it.  2.068 added a function
 that needs a CTFE-able 64-bit log2, but other than that, it just
 works now.  You may want to revert your patch for that module and
 try it.
>>>
>>> Thanks for the tip, I'll check it out.  It is the one remaining bad
>>> boy.
>>
>> Still bad :-(
>
> Hmm, that's strange, this commit didn't fix the 64-bit issues for you?
> I believe it fixed them for me on Android/ARM:
>
> https://github.com/ldc-developers/phobos/commit/9d1b49578ffa4b2e848159cfe5afe80b5e4c26eb

Yes, but there is still one case not working for both iOS armv7 and
arm64 in 0.16.1.  It is only off by one ulp so I'll make a PR for that.

https://github.com/ldc-developers/phobos/blob/ldc/std/internal/math/gammafunction.d#L540

And then this new stuff in 2.068 is failing in various places.

https://github.com/ldc-developers/phobos/commit/9b86eebed53c800a58dfa7e065dcb9e11cdae5c5

Re: iOS LDC 0.16.1 (2.067.1) binaries available

[Dan Olson via Digitalmars-d-announce]

Dan Olson  writes:

> Joakim  writes:
>> btw, std.internal.math.gammafunction hasn't given me a problem since
>> 2.067.1, the Win64 guys fixed it.  2.068 added a function that needs a
>> CTFE-able 64-bit log2, but other than that, it just works now.  You
>> may want to revert your patch for that module and try it.
>
> Thanks for the tip, I'll check it out.  It is the one remaining bad boy.

Still bad :-(

Re: iOS LDC 0.16.1 (2.067.1) binaries available

[Dan Olson via Digitalmars-d-announce]

Joakim  writes:

> On Saturday, 7 November 2015 at 20:34:06 UTC, Dan Olson wrote:
>> Joakim  writes:
>>> Hmm, that's strange, this commit didn't fix the 64-bit issues for
>>> you? I believe it fixed them for me on Android/ARM:
>>>
>>> https://github.com/ldc-developers/phobos/commit/9d1b49578ffa4b2e848159cfe5afe80b5e4c26eb
>>
>> Yes, but there is still one case not working for both iOS armv7 and
>> arm64 in 0.16.1.  It is only off by one ulp so I'll make a PR for
>> that.
>>
>> https://github.com/ldc-developers/phobos/blob/ldc/std/internal/math/gammafunction.d#L540
>
> OK, somehow doesn't assert for me on Android/ARMv7.

Different math libs I suspect is the cause.

>> And then this new stuff in 2.068 is failing in various places.
>>
>> https://github.com/ldc-developers/phobos/commit/9b86eebed53c800a58dfa7e065dcb9e11cdae5c5
>
> Yeah, that's the new function I mentioned earlier.  Initializing the
> constant maxY ends up calling log2 through CTFE, the intrinsic for
> which doesn't exist in Kai's longdouble2 branch.  I was going to look
> at writing one, feel free to beat me to it. ;)
>
> Or if you added that log2 to your branch already, could be other
> issues too, haven't gotten that far.

I don't use longdouble2 branch currently, but only because I had another
simpler 64-bit specific solution.  Yes, I had to add log() to it for
CTFE.

longdouble2 does need to get into LDC to make general support of
cross-compilers easier.  Kai's main concern was about CTFE accuracy for
functions like sin().  Someone or us should start on that.

I traced through the new gammafunction errors and several are due to
subnormals getting fed to log(). Many iOS math functions treat
subnormals as zero, producing different results.  I just have to find
them and revise the unitttests.

Re: iOS LDC 0.16.1 (2.067.1) binaries available

[Dan Olson via Digitalmars-d-announce]

Joakim  writes:
> btw, std.internal.math.gammafunction hasn't given me a problem since
> 2.067.1, the Win64 guys fixed it.  2.068 added a function that needs a
> CTFE-able 64-bit log2, but other than that, it just works now.  You
> may want to revert your patch for that module and try it.

Thanks for the tip, I'll check it out.  It is the one remaining bad boy.

Re: LDC 0.17.0 alpha cross-compiler for Android/ARM, D 2.068.2

[Dan Olson via Digitalmars-d-announce]

Go mobile!

Re: iOS LDC 0.16.1 (2.067.1) binaries available

[Dan Olson via Digitalmars-d-announce]

Just a few more notes:

Dan Olson  writes:
> Feedback appreciated, especially since iOS support may get into official
> LDC sometime soon.  This is a good time to voice an opinion on the
> approach.

Just noticed that tvOS and watchOS are now present in LLVM, so I think
support for these could be added to LDC soon too.

> Xcode is not D aware and a working plugin is needed.  In the meantime,
> xc-iphoneos-dc in the bin dir can be used as a custom *.d build script.
> Or you can compile D source externally and add your libraries/object
> files to an Xcode project.

An Xcode plugin for D is badly needed.  I think someone could get this
one functioning: https://github.com/michelf/d-for-xcode

Re: iOS LDC 0.16.1 (2.067.1) binaries available

[Dan Olson via Digitalmars-d-announce]

Joakim  writes:

> Great, your last announcement was linked in reddit comments about the
> 2.069 release, when asked about iOS support.
>
> On Thursday, 5 November 2015 at 08:05:39 UTC, Dan Olson wrote:
>> Just noticed that tvOS and watchOS are now present in LLVM, so I
>> think support for these could be added to LDC soon too.
>
> WatchOS and tvOS are bitcode-only, right?  Have they specified their
> bitcode format yet or is it just whatever clang spits out?  I thought
> there were problems with that because of bitcode format changes over
> time and other platform issues, that the PNaCl guys had to work on
> solving.  I wonder if you'll have similar issues with the bitcode ldc
> spits out.

tvOS is essentially iOS and doesn't require bitcode (yet) like watchOS.
I am looking at adding it soon because Xcode 7 enables it by default.

I don't totally appreciate all the possible bitcode problems, but one of
the suggestions that apps can be updated for new CPUs without rebuilding
doesn't make sense.  The IR/bitcode from clang for arm64 and armv7 is
different.  They would have to make all the ABIs identical first or have
LLVM backend do more of the ABI work.
-- 
Dan

iOS LDC 0.16.1 (2.067.1) binaries available

[Dan Olson via Digitalmars-d-announce]

This is another set of binaries and universal libs for the experimental
LDC iOS cross-compiler.  It is now based on LDC 0.16.1 (2.067.1) and
LLVM 3.6.2.

https://github.com/smolt/ldc-iphone-dev/releases/tag/ios-0.16.1-151104

Feedback appreciated, especially since iOS support may get into official
LDC sometime soon.  This is a good time to voice an opinion on the
approach.

The release download ldc2-ios-0.16.1-151104-osx.tar.xz should have
everything needed to run on an OS X build host in the same fashion as an
LDC release.

Binary is named iphoneos-ldc2 so you can have both it and a native ldc2
in your PATH.  Usage of iphoneos-ldc2 is the same as ldc2 with the
addition of clang style -arch option to select the iOS architecture to
compile code for.  Valid -arch options are armv6, armv7, armv7s, arm64,
X86_64, or i386 (armv6 is not included in the druntime/phobos universal
libs however).

Xcode or similar is needed to link and bundle an iOS app.

Xcode is not D aware and a working plugin is needed.  In the meantime,
xc-iphoneos-dc in the bin dir can be used as a custom *.d build script.
Or you can compile D source externally and add your libraries/object
files to an Xcode project.

If you want to build LDC and the libs yourself, instructions are at:

https://github.com/smolt/ldc-iphone-dev

It is not a quick build because druntime and phobos have to be compiled
for five architectures (armv7, armv7s, arm64, i386, and x86_64).
-- 
Dan

Re: LDC iOS cross-compiler with arm64

[Dan Olson via Digitalmars-d-announce]

Jacob Carlborg  writes:

> On 2015-10-24 12:01, Suliman wrote:
>
>> Would it be hard to add Windows/Linux host available? Would it be hard
>> to develop iOS apps on Windows in comparison of using MacOSX?
>
> It depends on what you mean. Microsoft already supports developing iOS
> apps on Windows, but the building is actually performed on OS X.

In addition, the LDC cross-compiler could be built with a few tweaks for
any build host that LDC already supports.  If someone already has a
Windows/Linux dev environment for iOS, then LDC could be used with it.

Re: LDC iOS cross-compiler with arm64

[Dan Olson via Digitalmars-d-announce]

extrawurst  writes:

> On Saturday, 24 October 2015 at 07:07:18 UTC, Dan Olson wrote:
>> This is another set of binaries and universal libs for the
>> experimental LDC iOS cross-compiler.  It is now based on LDC 0.15.2
>> (2.066.1) and LLVM 3.6.1.
>>
>> [...]
>
> Cool work!
>
> Can this be merged with official LDC eventually ?
>
> --Stephan

Yes, that is the plan.

LDC iOS cross-compiler with arm64

[Dan Olson via Digitalmars-d-announce]

This is another set of binaries and universal libs for the experimental
LDC iOS cross-compiler.  It is now based on LDC 0.15.2 (2.066.1) and
LLVM 3.6.1.

https://github.com/smolt/ldc-iphone-dev/releases/tag/ios-0.15.2-151023

What's new?
- arm64 for iOS 64-bit devices
- C ABI compatibility improvements
- supports Xcode 7
- includes libcurl

The release download ldc2-ios-0.15.2-151023-osx.tar.xz should have
everything needed to run on an OS X build host in the same fashion as an
LDC release.  But I may have missed something.

Binary is named iphoneos-ldc2 so you can have both it and a native ldc2
in your PATH.  Usage of iphoneos-ldc2 is the same as ldc2 with the
addition of clang style -arch option to select the iOS architecture to
compile code for.  Valid -arch options are armv6, armv7, armv7s, arm64,
X86_64, or i386 (armv6 is not included in the druntime/phobos universal
libs however).

Xcode or similar is needed to link and bundle an iOS app.

Xcode is not D aware and I am unaware of a working plugin.  In the
meantime, xc-iphoneos-dc in the bin dir can be used as a custom *.d
build script.  Or you can compile D source externally and add your
libraries/object files to an Xcode project.

If you want to build LDC and the libs yourself, instructions are at:

https://github.com/smolt/ldc-iphone-dev

It is not a quick build because druntime and phobos have to be compiled
for five architectures (armv7, armv7s, arm64, i386, and x86_64).

Feedback is really appreciated.
-- 
Dan

Re: Seattle D meetup

[Dan Olson via Digitalmars-d-announce]

Colden Cullen coldencul...@gmail.com writes:

 On Sunday, 2 August 2015 at 22:53:00 UTC, Walter Bright wrote:
 Seeing the threads on London, Silicon Valley and Berlin meetups, is
 there any interest for a Seattle one?

 Yes please! Myself and a good portion of the Dash[1] team are in
 Seattle now, and we'd love to get to know other D users.

 [1] http://dash.circularstudios.com/

I too would be interested.

BTW - for Seattle/PNW folks, Living Computer Museum is hosting a fun
event on Aug 15.

http://www.livingcomputermuseum.org/FreePlay

-- 
Dan

Re: Firs step of D/Objective-C merged

[Dan Olson via Digitalmars-d-announce]

Very good news!

Re: LDC for iOS prebuilt binaries

[Dan Olson via Digitalmars-d-announce]

Jack Stouffer j...@jackstouffer.com writes:

 Does this have any way to call the iOS Obj-C libraries for UI
 rendering and the like? Or is that a separate project?

It is a separate project and is gradually getting pulled into DMD:

http://forum.dlang.org/post/mnm1sf$kp8$1...@digitalmars.com

For now, you can write UI part in Objective-C and rest as D.  From D you
could call any of the C-based graphics APIs (e.g. CGContextFillRect) but
you'd have to write declarations - or try out Dstep:

https://github.com/jacob-carlborg/dstep

Another approach is using a framework with D bindings like Allegro5.

http://forum.dlang.org/post/m2sicg48ff@comcast.net

This looked promising but I have not pursed beyond that post.
-- 
Dan

Re: LDC for iOS prebuilt binaries

[Dan Olson via Digitalmars-d-announce]

Manu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com writes:

 Possible to make cross compilers for other hosts?
 Who uses a mac? ;)

Hi Manu - I wish I knew the answer.  I assume you are thinking Windows.
I just looked at some stackoverflow answers, specifically at Xamarin.iOS
for Windows, and all seem to require a Mac at somepoint in the iOS dev
process.

Just thinking now as I type:
- druntime, and phobos as built should be fine, since they are already
   cross compiled for iOS/arm
- ldc could be built as an iOS cross compiler on Windows with a little
   work
- that leaves: cross linker (I think Apple open sources it), and app
   tools to create, sign, and download apps.  Maybe someone in the
   field knows a solution.

http://developer.xamarin.com/guides/ios/getting_started/installation/windows/

http://stackoverflow.com/questions/22358/how-can-i-develop-for-iphone-using-a-windows-development-machine

-- 
Dan

LDC for iOS prebuilt binaries

[Dan Olson via Digitalmars-d-announce]

I've made a set of binaries and universal libs for the LDC iOS
cross-compiler.  It is based on LDC 0.15.1 (2.066) and LLVM 3.5.1.

https://github.com/smolt/ldc-iphone-dev/releases/tag/ios-0.15.1-150708

Only 32-bit devices currently; arm64 work starts next month when I
acquire an iPhone 6.

The download should have everything needed to run on an OS X build host
in the same fashion as LDC downloads.  But I may have missed something.
Feedback appreciated.
-- 
Dan

Re: DConf 2015 has ended. See you in Berlin at DConf 2016!

[Dan Olson via Digitalmars-d-announce]

Steven Schveighoffer schvei...@yahoo.com writes:

 On 6/1/15 11:40 AM, Dan Olson wrote:
 Dicebot pub...@dicebot.lv writes:

 - Moving fibers between threads (though there is some hope that Liran
 managed to convince Walter it is a bad idea)

 I am interesting in this one.  What was the decision, that Fibers should
 or should not be allowed to migrate between threads?  Is the discussion
 in one of the recorded talks?


 Walter said that fibers must be movable between threads, it was part
 of the AMA I think (day 1 final talk).

Just listened to it.  I would be interested to know applications
where migrating Fibers across threads is a good thing.  I can imagine
server load balancing over cores.  What else?

The issue I've been tripped up by with migrating Fibers is that compiler
backends like LLVM and GCC do some nice optimizations with thread-locals
on some targets that lead to incorrect code when a Fiber yields and
comes back on a different thread.  To get it right, the compiler would
have to assume that any function call could return on a different
thread.

The solutions I can think of today are to: not optimize (not a good
solution), or have a special compiler switch to not optimize TLS (not
available in backend), or ensure Fibers don't access TLS vars (not sure
how that could be done except by being careful), or don't migrate.
Inlining makes being careful difficult because a function call before
and after a yield may access the same TLS var, and compiler then decides
to cache the TLS address in a register.

I have been prototyping a Fiber check that throws an exception on
targets with this issue, and the developer can override it by setting a
Fiber property, after promising to be careful.

http://forum.dlang.org/thread/onkyxucuuthaqxxbk...@forum.dlang.org#post-m2d223wqa0.fsf:40comcast.net

Re: DConf 2015 has ended. See you in Berlin at DConf 2016!

[Dan Olson via Digitalmars-d-announce]

Dicebot pub...@dicebot.lv writes:

 - Moving fibers between threads (though there is some hope that Liran
 managed to convince Walter it is a bad idea)

I am interesting in this one.  What was the decision, that Fibers should
or should not be allowed to migrate between threads?  Is the discussion
in one of the recorded talks?

Re: [Hackathon] ARM Cortex-M LCD Demo

[Dan Olson via Digitalmars-d-announce]

Jeremiah DeHaan dehaan.jerem...@gmail.com writes:

 On Friday, 1 May 2015 at 15:37:09 UTC, ketmar wrote:
 On Fri, 01 May 2015 15:30:21 +, Mike wrote:

 I know, random rectangles on a screen is not all that remarkable,

 they ARE remarkable!

 I agree. This is fantastic work! I am so excited to see this.

Me too! True embedded work should be a sweet spot for D. Too bad we
can't grab 2-3 developers and give them 3-months budget and time to hack
out all the necessary parts for an embedded toolchain,libs,and
methodolgy based entirely on D. Anybody thought of porting relavant
parts of say newlib to D?
--
Dan Olson

Re: EMSI is hiring a D developer

[Dan Olson via Digitalmars-d-announce]

Abdulhaq alynch4...@gmail.com writes:

 On Tuesday, 14 April 2015 at 16:17:37 UTC, Justin Whear wrote:
 EMSI is hiring for an Engineer II to work on D codebases: https://
 emsi.bamboohr.com/jobs/view.php?id=30

 When it said Moscow I was thinking mmmh lots of traffic, a bit
 difficult to live in then I saw it was Moscow, Idaho.

Wow, right next door in the Pacific Northwest.  Moscow used to be a
popular destination for Wash State Univ students when the drinking age
was lower in Idaho State.  And now a haven for D.

Re: DTanks Alpha

[Dan Olson via Digitalmars-d-announce]

Kingsley kingsley.hendric...@gmail.com writes:

 In preparation for the London D meetup I have got the DTanks robot
 battle framework into the first alpha release state - good enough to
 use at the meetup anyway.

 https://github.com/masterthought/dtanks

 --K

DTanks looks cool!  I am going to have to try it.  Brings back
memories.

I got hooked on the Apple ][ version (http://corewar.co.uk/robotwar/)
back in the 80's and started a version for the Amiga called Tonks but
it never got off the drawing board.  I've always loved this game
concept.  Even did a version to run each tank on a node of an Intel
Hypercube as a school project.
-- 
Dan

Re: LLVM 3.6 released - LDC master branch/0.15.1 is ready to use it!

[Dan Olson via Digitalmars-d-announce]

Dan Olson zans.is.for.c...@yahoo.com writes:

 Kai Nacke k...@redstar.de writes:

 On Sunday, 1 March 2015 at 03:26:16 UTC, Dan Olson wrote:
 Dan Olson zans.is.for.c...@yahoo.com writes:

 I got LLVM 3.6 to work but I couldn't compile with LDC 0.15.1 (looks
 like more 3.6 fixes came in after it) and ldc master HEAD
 compilation
 ended up with an LLVM assertion failure on OS X. I backed up to ldc
 commit 136fe8d and that worked for both OS X and iOS.

 Which assertion do you get on OS X?

 Regards,
 Kai

 I didn't save the error message.  I'll have to rebuild with ldc master
 later today then I'll let you know.  I was using an LLVM 3.6 (github
 mirror release_36 branch) Debug+Asserts build.

False alarm Kai. I updated ldc to master but not runtime. Once I updated
druntime to ldc branch HEAD, it builds ok. Probably the varargs change.
BTW, this was the assertion I got in a bunch of modules:

Assertion failed: (getOperand(0)-getType() == 
castPointerType(getOperand(1)-getType())-getElementType()  Ptr must be a 
pointer to Val type!), function AssertOK, file 
/Users/dan/projects/ldc/llvm-git/lib/IR/Instructions.cpp, line 1083.

Re: LLVM 3.6 released - LDC master branch/0.15.1 is ready to use it!

[Dan Olson via Digitalmars-d-announce]

Kai Nacke k...@redstar.de writes:

 On Sunday, 1 March 2015 at 03:26:16 UTC, Dan Olson wrote:
 Dan Olson zans.is.for.c...@yahoo.com writes:

 I got LLVM 3.6 to work but I couldn't compile with LDC 0.15.1 (looks
 like more 3.6 fixes came in after it) and ldc master HEAD
 compilation
 ended up with an LLVM assertion failure on OS X. I backed up to ldc
 commit 136fe8d and that worked for both OS X and iOS.

 Which assertion do you get on OS X?

 Regards,
 Kai

I didn't save the error message.  I'll have to rebuild with ldc master
later today then I'll let you know.  I was using an LLVM 3.6 (github
mirror release_36 branch) Debug+Asserts build.

Re: LLVM 3.6 released - LDC master branch/0.15.1 is ready to use it!

[Dan Olson via Digitalmars-d-announce]

Kai Nacke k...@redstar.de writes:

 Also note that LDC is mentioned in the release notes as one of the
 projects who are already supporting LLVM 3.6. Just recompile LDC using
 master branch from GitHub or from the 0.15.1 source.

 This is the 6th time that LDC and D are mentioned in the LLVM release
 notes!

That is pretty nice recognition in the release notes for both D and LDC.
I going to start testing LLVM 3.6 with iOS today.  If it looks good,
I'll move my forked ios branch from 3.5.1 to 3.6.

Re: LLVM 3.6 released - LDC master branch/0.15.1 is ready to use it!

[Dan Olson via Digitalmars-d-announce]

Dan Olson zans.is.for.c...@yahoo.com writes:

 Kai Nacke k...@redstar.de writes:

 Also note that LDC is mentioned in the release notes as one of the
 projects who are already supporting LLVM 3.6. Just recompile LDC using
 master branch from GitHub or from the 0.15.1 source.

 This is the 6th time that LDC and D are mentioned in the LLVM release
 notes!

 That is pretty nice recognition in the release notes for both D and LDC.
 I going to start testing LLVM 3.6 with iOS today.  If it looks good,
 I'll move my forked ios branch from 3.5.1 to 3.6.

I got LLVM 3.6 to work but I couldn't compile with LDC 0.15.1 (looks
like more 3.6 fixes came in after it) and ldc master HEAD compilation
ended up with an LLVM assertion failure on OS X. I backed up to ldc
commit 136fe8d and that worked for both OS X and iOS.

Re: LDC for iOS

[Dan Olson via Digitalmars-d-announce]

On Thursday, 26 February 2015 at 19:26:07 UTC, Jacob Carlborg 
wrote:
I could successfully compile the compiler and compile Hello 
World without any problems. I did not try running it on an a 
device.


Thanks Jacob!

LDC for iOS

[Dan Olson via Digitalmars-d-announce]

I think this all is in good enough shape that someone else should give
it a try.

https://github.com/smolt/ldc-iphone-dev

This is an LDC development sandbox for iPhone iOS.

It glues together various pieces needed to build an LDC cross compiler
targeting iPhoneOS.  It also includes a few samples to show how to get
started. The compiler and libraries are in good enough shape to pass the
druntime/phobos unittests with a few minor test failures (see project
README.md).  This means someone could, if so inclined, build their D
library and use it in an iOS App.

Currently based on LDC 0.15.1 (DMD v2.066.1) and LLVM 3.5.1.

There are no prebuild binaries, so you have to do it yourself.  Nobody
has reported yet on trying to build beside me, so there may be potholes.

Enjoy,
Dan