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 <dl...@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.
