On 07/04/2017 10:34 AM, Joakim wrote:
> On Thursday, 6 April 2017 at 05:32:41 UTC, rikki cattermole wrote:
>> IMO there is two things that need to be done to get D for mobile:
>>
>> 1: ldc needs to natively target and distribute binaries for Android
>> (MIPS, ARM, at least).
>
> I'm not sure what you mean by "natively target."  Do you mean that the
> shipping ldc compiler should come with Android/ARM target support built
> in?  That can be done, but it's useless without a stdlib cross-compiled
> for the target and ldc doesn't provide the cross-compiler
> scripts/toolchain with its releases that would allow you to easily start
> cross-compiling, even though the compiler itself is capable.  Instead, I
> provide a cross-compiler for linux/x64 that comes with a cross-compiled
> stdlib for Android/ARM, and link to instructions on how to use it with
> the Android NDK toolchain.

So basically druntime, Phobos all good to go basically be able to do ldc2 test.d and get a valid (yet to be apk'd) executable. But the point was to have it all officially supported and ready to go with clear instructions on how to use it.

> If you mean a native ldc compiler, that's already been done and provided
> in the link above, ie a native ldc that you can run _on_ your Android
> device.  That's what I use, since my development hardware is an
> Android/ARM tablet (I have not used an x86 or x64 device in more than a
> year, instead renting out an x64 vps recently to build the cross-compiler).
>
> As for Android/MIPS, nobody uses it, just like Android/x86 now that
> Intel has pulled out of the mobile market.  No point.

Ok, my knowledge is more out of date then ;)

>> 2: extern(JNI) seriously, its a pain to work with Java over JNI
>> otherwise. It would be worse then not having extern(Obj-C).
>
> I don't think it's that bad, but sure, we could always make it easier.

After working on djvm, there is no way I'd want to not have it. It's just too hard to do it library only.

Am Thu, 06 Apr 2017 05:24:07 +0000
schrieb Joakim <dlang@joakim.fea.st>:

> D is currently built and optimized for that dying PC platform.

As long as the world still needs headless machines running
web sites, simulations, cloud services, ...;
as long as we still need to edit office documents, run
multimedia software to edit photos and video, play AAA video
games the "PC master race" way;
I'm confident that we have a way to go until all the
notebooks, PCs and Macs disappear. :)

I'd say we just have /more/ fully capable computers around us
nowadays. I'd probably roughly split it into
- web/cloud server machines, often running VMs
- scientific computation clusters
- desktops (including notebooks)
- smart phones
- embedded devices running Linux/Android (TVs, receivers,
  refrigerators, photo boxes, etc...)

When targeting smart phones you have to comply to every manufacturer's frameworks and security measures. On the other hand you can directly sell software and services.

The embedded device I know best is my TV receiver, which boots into Linux and then starts a statically compiled executable that handles GUI rendering, remote control input and communication with the hardware. If you knew the protocols you could replace it with something written in Dlang.

These devices are not as prominent as phones, but the
barrier of entry is relatively low for many applications once
you have bindings to a couple of frequently needed C libraries
such as freetype, ffmpeg or opencv.

> What needs to be done?  Same as anything else, we need people to try it out and pitch in, like this guy who's now trying ldc out on an embedded device with an old ARMv5 core:
>
>[…]
>
> I realize D is never going to have a polished devkit for mobile unless a company steps up and charges for that work.  But we can do a lot better than the complacency from the community we have now.

As you can use mostly the same compiler targets for embedded as for phones, your best bet to stabilize the ldc targets are probably the embedded developers, because they can see the immediate benefit for their projects and their knowledge about the underlying hardware can help track down bugs.

-- 
Marco

On Friday, 7 April 2017 at 14:47:03 UTC, Marco Leise wrote:
> Am Thu, 06 Apr 2017 05:24:07 +0000
> schrieb Joakim <dlang@joakim.fea.st>:
>
> [...]
That's what I meant by embedded programming. Not those 1mb RAM boards. Smart devices/IoT (home automation, smart cards, industrial machines, etc.) using more capable boards. What remains is hardware interface part in form of reusable libs. We're already there.
>
> [...]
+1
>
> [...]

On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote:
> I have been saying for some time now that mobile is going to go after the desktop next (http://forum.dlang.org/thread/rionbqmtrwyenmhmmggx@forum.dlang.org), Samsung just announced it, for a flagship device that will ship tens of millions:
>
> [...]

The D community should start a D based operation system for the android and possibly iphone devices. Since D can compile in to many different languages, the OS could be platform agnostic.

All someone would have to do is create some example code that D can come to a binary and be used to boot in to some android device and someone will start working developing something bigger and better.

On Saturday, 8 April 2017 at 05:37:24 UTC, Jethro wrote:
> On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote:
>> I have been saying for some time now that mobile is going to go after the desktop next (http://forum.dlang.org/thread/rionbqmtrwyenmhmmggx@forum.dlang.org), Samsung just announced it, for a flagship device that will ship tens of millions:
>>
>> [...]
>
> The D community should start a D based operation system for the android and possibly iphone devices. Since D can compile in to many different languages, the OS could be platform agnostic.
>
for industrial usage, how about QNX o/s on ARM processors.  This is a big market.

On Friday, 7 April 2017 at 14:47:03 UTC, Marco Leise wrote:
> Am Thu, 06 Apr 2017 05:24:07 +0000
> schrieb Joakim <dlang@joakim.fea.st>:
>
>> D is currently built and optimized for that dying PC platform.
>
> As long as the world still needs headless machines running
> web sites, simulations, cloud services, ...;
> as long as we still need to edit office documents, run
> multimedia software to edit photos and video, play AAA video
> games the "PC master race" way;
> I'm confident that we have a way to go until all the
> notebooks, PCs and Macs disappear. :)
>
> I'd say we just have /more/ fully capable computers around us
> nowadays. I'd probably roughly split it into
> - web/cloud server machines, often running VMs
> - scientific computation clusters
> - desktops (including notebooks)
> - smart phones
> - embedded devices running Linux/Android (TVs, receivers,
>   refrigerators, photo boxes, etc...)

perhaps we need need real data as to what markets are really growing ?

Am Sun, 09 Apr 2017 12:44:15 +0000
schrieb Nick B <nick.barbalich@gmail.com>:

> > I'd say we just have /more/ fully capable computers around us
> > nowadays. I'd probably roughly split it into
> > - web/cloud server machines, often running VMs
> > - scientific computation clusters
> > - desktops (including notebooks)
> > - smart phones
> > - embedded devices running Linux/Android (TVs, receivers,
> >   refrigerators, photo boxes, etc...)
> 
> perhaps we need need real data as to what markets are really growing ?

Maybe. It begs the question if growing markets are naturally
better than markets of a stable size that can be expected to
exist for the next 25 years or so.
Otherwise my point was that embedded developers often
don't need much of an "eco system" to get started.

-- 
Marco

On Friday, 7 April 2017 at 09:40:26 UTC, rikki cattermole wrote:
> On 07/04/2017 10:34 AM, Joakim wrote:
>> On Thursday, 6 April 2017 at 05:32:41 UTC, rikki cattermole wrote:
>>> IMO there is two things that need to be done to get D for mobile:
>>>
>>> 1: ldc needs to natively target and distribute binaries for Android
>>> (MIPS, ARM, at least).
>>
>> I'm not sure what you mean by "natively target."  Do you mean that the
>> shipping ldc compiler should come with Android/ARM target support built
>> in?  That can be done, but it's useless without a stdlib cross-compiled
>> for the target and ldc doesn't provide the cross-compiler
>> scripts/toolchain with its releases that would allow you to easily start
>> cross-compiling, even though the compiler itself is capable.  Instead, I
>> provide a cross-compiler for linux/x64 that comes with a cross-compiled
>> stdlib for Android/ARM, and link to instructions on how to use it with
>> the Android NDK toolchain.
>
> So basically druntime, Phobos all good to go basically be able to do ldc2 test.d and get a valid (yet to be apk'd) executable. But the point was to have it all officially supported and ready to go with clear instructions on how to use it.

That's all available from my Android releases: the only part you could say is missing is "official support," since they're not put out on ldc's official github release page.

There are a couple issues that block that, one of which I mentioned above: ldc has never released a cross-compiler with a cross-compiled stdlib, or at least scripts that make it easy to cross-compile the stdlib yourself, and instructions on integrating with some cross-compilation toolchain.  Another is that my cross-compiler currently requires a lightly tweaked llvm.

>>> 2: extern(JNI) seriously, its a pain to work with Java over JNI
>>> otherwise. It would be worse then not having extern(Obj-C).
>>
>> I don't think it's that bad, but sure, we could always make it easier.
>
> After working on djvm, there is no way I'd want to not have it. It's just too hard to do it library only.

I have not tried djvm yet, perhaps we could work together on this.

On Friday, 7 April 2017 at 14:47:03 UTC, Marco Leise wrote:
> Am Thu, 06 Apr 2017 05:24:07 +0000
> schrieb Joakim <dlang@joakim.fea.st>:
>
>> D is currently built and optimized for that dying PC platform.
>
> As long as the world still needs headless machines running
> web sites, simulations, cloud services, ...;
> as long as we still need to edit office documents, run
> multimedia software to edit photos and video, play AAA video
> games the "PC master race" way;
> I'm confident that we have a way to go until all the
> notebooks, PCs and Macs disappear. :)

As I've noted many times on this forum, no tech ever completely disappears:
there's still somebody out there running COBOL and mainframes.  But they do _effectively_ disappear, as you almost never see them.

That is what is happening to the PC.  When is the last time you saw someone running a UNIX workstation?  Back when I was in college decades ago, that's all I used to use, except for writing papers.

In my household, we had two Windows laptops and two Android smartphones four years ago; today we have two Android tablets and two Android smartphones, ie no PCs anymore.  There are increasingly people worldwide using smartphones and tablets who have never and will never touch a PC!  This move to add multiwindow docked functionality to smartphones makes that more prevalent.

As for your examples, my first link above notes that Microsoft and Adobe have made software available to do just that on your S8.  Yes, there are compute-heavy workloads that you will always need servers for, but ARM is going after that market too (https://arstechnica.com/information-technology/2017/03/microsoft-latest-open-source-servers-shown-off-with-intel-amd-and-even-arm-chips/), and because the number and capability of mobile devices is exploding, that compute-heavy share is going down.

> I'd say we just have /more/ fully capable computers around us
> nowadays. I'd probably roughly split it into
> - web/cloud server machines, often running VMs
> - scientific computation clusters
> - desktops (including notebooks)
> - smart phones
> - embedded devices running Linux/Android (TVs, receivers,
>   refrigerators, photo boxes, etc...)

My point is that mobile, ie smartphones and tablets, is so dominant that it is subsuming many of those other categories.  I've already mentioned desktop/laptop sales going down since mobile took off, another is embedded devices that you'd have mentioned before getting subsumed into mobile, ie mp3 players, ereaders, standalone cameras, and GPS devices' sales have all been devastated.  People don't buy TVs, receivers, and photo boxes as much as before because their mobile device suffices.  Unfortunately, you cannot use your smartphone for refrigeration yet. ;)

> When targeting smart phones you have to comply to every manufacturer's frameworks and security measures. On the other hand you can directly sell software and services.

I'm not sure what you're referring to here: Samsung has different security measures than Huawei, which require app modifications?  And mobile sales are usually less direct, as you have to go through an app store, which you didn't have to with PCs.

> The embedded device I know best is my TV receiver, which boots into Linux and then starts a statically compiled executable that handles GUI rendering, remote control input and communication with the hardware. If you knew the protocols you could replace it with something written in Dlang.
>
> These devices are not as prominent as phones, but the
> barrier of entry is relatively low for many applications once
> you have bindings to a couple of frequently needed C libraries
> such as freetype, ffmpeg or opencv.

I don't know much about the software stack for receivers, but it's not as important as mobile and likely has higher barriers given the greater fragmentation.  It is likely that some mobile-based platform, like Android TV, will end up being much more important in this market.

>> I realize D is never going to have a polished devkit for mobile unless a company steps up and charges for that work.  But we can do a lot better than the complacency from the community we have now.
>
> As you can use mostly the same compiler targets for embedded as for phones, your best bet to stabilize the ldc targets are probably the embedded developers, because they can see the immediate benefit for their projects and their knowledge about the underlying hardware can help track down bugs.

My understanding is that embedded both has many more hardware targets and software stacks, so mobile is actually much easier.  I'd like to see D on more capable embedded hardware that can handle it, and the runtime stripped down eventually for less capable embedded hardware.

However, it's not a market I deal with, so either way, I'm not going to do anything with it.

On 12/04/2017 10:37 AM, Joakim wrote:
> On Friday, 7 April 2017 at 09:40:26 UTC, rikki cattermole wrote:
>> On 07/04/2017 10:34 AM, Joakim wrote:
>>> On Thursday, 6 April 2017 at 05:32:41 UTC, rikki cattermole wrote:
>>>> IMO there is two things that need to be done to get D for mobile:
>>>>
>>>> 1: ldc needs to natively target and distribute binaries for Android
>>>> (MIPS, ARM, at least).
>>>
>>> I'm not sure what you mean by "natively target."  Do you mean that the
>>> shipping ldc compiler should come with Android/ARM target support built
>>> in?  That can be done, but it's useless without a stdlib cross-compiled
>>> for the target and ldc doesn't provide the cross-compiler
>>> scripts/toolchain with its releases that would allow you to easily start
>>> cross-compiling, even though the compiler itself is capable.  Instead, I
>>> provide a cross-compiler for linux/x64 that comes with a cross-compiled
>>> stdlib for Android/ARM, and link to instructions on how to use it with
>>> the Android NDK toolchain.
>>
>> So basically druntime, Phobos all good to go basically be able to do
>> ldc2 test.d and get a valid (yet to be apk'd) executable. But the
>> point was to have it all officially supported and ready to go with
>> clear instructions on how to use it.
>
> That's all available from my Android releases: the only part you could
> say is missing is "official support," since they're not put out on ldc's
> official github release page.
>
> There are a couple issues that block that, one of which I mentioned
> above: ldc has never released a cross-compiler with a cross-compiled
> stdlib, or at least scripts that make it easy to cross-compile the
> stdlib yourself, and instructions on integrating with some
> cross-compilation toolchain.  Another is that my cross-compiler
> currently requires a lightly tweaked llvm.
>
>>>> 2: extern(JNI) seriously, its a pain to work with Java over JNI
>>>> otherwise. It would be worse then not having extern(Obj-C).
>>>
>>> I don't think it's that bad, but sure, we could always make it easier.
>>
>> After working on djvm, there is no way I'd want to not have it. It's
>> just too hard to do it library only.
>
> I have not tried djvm yet, perhaps we could work together on this.

I don't have the time nor knowledge of dmd-fe internals to do this. It really needs to be a priority of the D Foundation to accomplish this or a very highly motivated individual with time to burn.

JNI itself isn't hard to work with, its mapping classes for D easily to it which is hard. Especially when inheritance comes into play.

On Wed, 2017-04-12 at 10:43 +0100, rikki cattermole via Digitalmars-d wrote:
> […]
> 
> JNI itself isn't hard to work with, its mapping classes for D easily
> to
> it which is hard. Especially when inheritance comes into play.

JNI is on notice for being retired, but clearly this is Java so sometime next century. The replacement won't be here for a while, but it will be here.

http://openjdk.java.net/jeps/191

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder