www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What are we going to do about mobile?

reply Joakim <dlang joakim.fea.st> writes:
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:

http://www.theverge.com/2017/3/29/15104600/samsung-dex-galaxy-s8-dock-announced-price-release-date
https://www.youtube.com/watch?v=QA31CaL_42A

That means this tidal wave of mobile swamping PCs is only going 
to get worse:

https://twitter.com/lukew/status/842397687420923904

D is currently built and optimized for that dying PC platform.  
There are only two devs working on mobile, Dan and me, I don't 
think anybody on the core team has even tried our work.

Even Microsoft has announced that they're taking another shot at 
ARM, ie Windows is coming to ARM again, this time with x86 
emulation for old Win32 apps:

http://www.theverge.com/2016/12/7/13866936/microsoft-windows-10-arm-desktop-apps-support-qualcomm

I would even go so far as to say it may be worthwhile to develop 
an ARM backend for dmd.

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:

https://github.com/ldc-developers/ldc/issues/2058

I provide Android releases of ldc here:

https://github.com/joakim-noah/android/releases

We've been fixing Android/ARM regressions in the latest D 
releases here:

https://github.com/ldc-developers/ldc/issues/2024

More than anything else, we need the community to try building 
mobile libraries and apps, because compiler support is largely 
done.  We need to integrate mobile into our plans, rather than it 
just being a sideline.

There are two main possibilities for D usage on mobile right now:

- D libraries for faster code than the native languages
- full GUI apps written in D, likely cross-platform

The latter may seem far-fetched given D has not done that well in 
desktop GUI apps, but mobile is still a new market and D could do 
well.  D is uniquely well-suited to mobile, because it's nicer 
than Java or Obj-C while more efficient than the former, and it 
could make it easier to go cross-platform.

Vadim has done some nice work building DLangUI on Android, 
including a Tetris app that I spent half an hour playing on my 
phone:

http://forum.dlang.org/thread/cdekkumjynhqoxvmgjze forum.dlang.org

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.
Apr 05 2017
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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).
2: extern(JNI) seriously, its a pain to work with Java over JNI 
otherwise. It would be worse then not having extern(Obj-C).
Apr 05 2017
parent reply Joakim <dlang joakim.fea.st> writes:
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.

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.


 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.

On Thursday, 6 April 2017 at 09:39:05 UTC, kinke wrote:

 More than anything else, we need the community to try building 
 mobile libraries and apps, because compiler support is largely 
 done.


 What LDC would primarily need is a CI platform supporting ARM 
 (and ideally AArch64) in order to make it a true first-class 
 target. We don't know of a free CI platform, so ARM isn't 
 tested automatically, and it's currently mostly up to poor you 
 to check for regressions. ;(


Circle seems to have some Android support, though I don't know if 
it's free, as Petar says:

https://circleci.com/docs/1.0/android/

I haven't been too inclined to look at this, as I've never messed 
with these CI services and it's not a big deal to run the tests 
myself occasionally.  We should add CI for Android at some point 
though, just one of the handful of tasks that it'd be nice if the 
community would chip in with.

On Thursday, 6 April 2017 at 11:59:42 UTC, aberba wrote:

 On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote:


 That means this tidal wave of mobile swamping PCs is only 
 going to get worse:


 That remains to be seen.


Notice the decline in PC sales since mobile took off on its 
hockey stick curve?  Now that they're even offering desktop-style 
multiwindow on mobile, what makes you think it doesn't get worse? 
  I've predicted a collapse.  Even Microsoft is selling the S8, a 
flagship Android device (!), because they want to get their 
office suite on Android:

https://www.thurrott.com/mobile/android/108140/microsoft-offering-customized-samsung-galaxy-s8-preorder


 Even Microsoft has announced that they're taking another shot 
 at ARM, ie Windows is coming to ARM again, this time with x86 
 emulation for old Win32 apps:

 http://www.theverge.com/2016/12/7/13866936/microsoft-windows-10-arm-desktop-apps-support-qualcomm


 ARM is *rising*, that's true. But there is no factual evidence 
 in their decision (that you seem to know) backing your point.


Did you bother to read the article?  The head of Windows, Terry 
Myerson, specifically says, "Customers are asking for devices 
with better battery life, with cellular connectivity. That's why 
we've invested in this, and we're pretty excited to be announcing 
it this week.”  I'm not sure what other "factual evidence" you're 
looking for.


 Microsoft, Apple, Google, ... all invest in projects they end 
 up abandoning.


Are you suggesting that they will abandon Android or the iPhone 
or just their desktop-on-mobile efforts?  It is true that 
multiwindow UIs on mobile is a nascent effort, and like anything 
new may not go anywhere, but I wouldn't bet against it.  In fact, 
this entire thread argues that D should bet on it.


 More than anything else, we need the community to try building 
 mobile libraries and apps, because compiler support is largely 
 done.  We need to integrate mobile into our plans, rather than 
 it just being a sideline.


 IoT, Cloud


IoT has not gone anywhere, while D already supports cloud.


 The latter may seem far-fetched given D has not done that well 
 in desktop GUI apps, but mobile is still a new market and D 
 could do well.  D is uniquely well-suited to mobile, because 
 it's nicer than Java or Obj-C while more efficient than the 
 former, and it could make it easier to go cross-platform.

 Vadim has done some nice work building DLangUI on Android, 
 including a Tetris app that I spent half an hour playing on my 
 phone:


 Any unpolished GUI toolkit (even when polished) will not sell 
 on android-iOS except for Games with custom drawn elements. C++ 
 is in that same position. Google is busy pushing Java, Apple is 
 busy pushing Swift. DlangUI could work but will not land you a 
 big share in usage.


I'm not looking for big share, just a first step.  Small share on 
mobile is a lot bigger than big share on IoT/cloud.


 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.


 With the *rising* market for IoT and Cloud, the effort invested 
 in ARM should be geared towards these areas with much 
 potential. Canonical just gave up their Ubuntu Touch (Mobile 
 OS) and Unity 8 DE to invest their resources in Cloud and IoT. 
 Fighting for mobile apps market (except for WebGL/OpenGL/Vulkan 
 games), which big corporates like Microsoft are also in 
 fighting but losing doesn't seem like a good idea.


Irrelevant, as they were pushing entirely different mobile OS 
platforms, while we're just talking about getting a language on 
the currently dominant mobile platforms.  The latter is much 
easier.


 IoT and Cloud entails ML, AI, NLP, embedded programming, bots, 
 microservices, containerization, robotics... which mir, vibe.d, 
 mqtt, and its projects are implementing some in bits.


The latter fields are mostly orthogonal to the first two 
platforms you list, ie you can run any of those on most any 
platform.


 Thats what you can say has potential cus they are actually 
 *rising*


I am skeptical of IoT taking off anytime soon- witness the recent 
DDoS from IoT devices- while we're already focused on cloud.

I think mobile needs focus because it dwarfs all those other 
platforms in size, so even some small chunk of that moving to D 
could be huge.

On Thursday, 6 April 2017 at 12:52:01 UTC, Adam D. Ruppe wrote:

 On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote:

 There are only two devs working on mobile, Dan and me, I don't 
 think anybody on the core team has even tried our work.


 I don't even own a mobile device and don't see that changing 
 any time soon (they are really expensive, slow, and just 
 generally hard to use*). I do own a raspberry pi, but never 
 actually use anyway so I have no need to develop for it.

 If I actually used one of these things, I'd probably join you 
 in hacking together stuff the way I've done web and desktop 
 libs, but I just don't use the hardware....


You're probably fairly unique in this even in this forum, but 
unfortunately your comment does paint a picture of D devs being 
disconnected from major current tech trends.

On Thursday, 6 April 2017 at 16:06:55 UTC, Radu wrote:

 I think mobile would be nice, but there needs to be a good full 
 stack (game lib, UI lib, maybe both) packaged with the compiler 
 and runtime in order to get people attention.


We could probably put together a mobile devkit with DlangUI and 
our other gamedev libraries.  It's just going to take more than 
just me doing it.


 What I see as something that can be targeted from day one is 
 IoT, industrial controllers, cloud and other embedded/backend 
 platforms (I'm basically agreeing with aberba's post).


Others have tried D on embedded and reported problems with 
stripping the runtiem down to perhaps even more constrained 
hardware:

https://forum.dlang.org/post/ktqntaoewubgtbdgrxxf forum.dlang.org

There is probably a niche of higher-powered embedded hardware 
that D would do well on right now, maybe including your 
situation, and as I noted in that thread, I don't know that it'd 
take that much effort to strip D down more.

Given the many issues in the embedded market generally and how C 
still dominates, I believe mobile is actually an easier sell, 
though I'd like to see both happen some day.


 I'm currently trying the armv5 platform, as you pointed out. 
 The possibilities are far more appealing for me to use the D 
 stack on Linux/Arm(Mips) as everything I know in the industrial 
 space uses this combination.

 Being able to create software with a nicer language using nicer 
 libraries would be the "killer app" for an entire industry.

 I think there is great potential and the proverbial 
 low-hanging-fruit here for getting stuff rolling.


I agree with you about D's potential in industrial use, though 
I'd separate out IoT as not having gone anywhere yet.


 Would be great if we could persuade the D foundation to sponsor 
 some Linux ARM/Mips CI infrastructure, I know I would pitch in 
 my 2 cents for the cause.
 This infrastructure could be used by LDC and GDC and be 
 extended in the future.


As I noted above, there may be free services for open-source 
projects that we're overlooking.

On Thursday, 6 April 2017 at 22:28:20 UTC, Dmitry Olshansky wrote:

 On 4/6/17 7:24 AM, 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:


 [snip]

 The latter may seem far-fetched given D has not done that well 
 in
 desktop GUI apps, but mobile is still a new market and D could 
 do well.
 D is uniquely well-suited to mobile, because it's nicer than 
 Java or
 Obj-C while more efficient than the former, and it could make 
 it easier
 to go cross-platform.


 Let's not forget Kotlin and Swift, things we'd really be 
 competing against - that is the other NEW stuff.


Kotlin runs on the JVM, so it's not going to be as efficient, 
while Swift has not been ported to Android.


 Also let's not forget the _legion_ of tools that let you do 
 cross-platform mobile app development in languages such as 




much more on mobile tooling, I would not call any of those as 
nice to use or as efficient as D.  Mobile is a big market with a 
lot of dev options, but I believe D could make a unique pitch.


 Vadim has done some nice work building DLangUI on Android, 
 including a
 Tetris app that I spent half an hour playing on my phone:

 http://forum.dlang.org/thread/cdekkumjynhqoxvmgjze forum.dlang.org

 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.


 Much as I like D I would admit that even Desktop/Server 
 developer experience is far from stellar. Now switching to 
 mobile the expectations of mobile developers are much higher - 
 they want a ready made development environment, full support of 
 platform APIs, thousands of examples, ready made GUI 
 components, tons of documentation, perfect support for all 
 manner of proprietary tools such as code signing, emulators, 
 you name it. Anything short of completely polished devkit is 
 not going to succeed.


In that case, even Apple and google's efforts have not succeeded, 
as I've heard lots of bitching on all those fronts for the 
official mobile devkits. ;) Take the Android NDK, which has long 
been neglected for everything you list, though that may be 
partially because they want to discourage its use, in favor of 
Java.

D is never going to attract the crowd that wants everything 
"ready made," but we can make a much better effort at attracting 
the mobile niches that want D's advantages.


 Most importantly though we would need to change the perception: 
 trying to be a D mobile app developer is doubly niche - first 
 because of D, second being an alien in mobile development.


Yes, D is niche, but niche efforts have to focus on small markets 
where they're uniquely suited or giant markets where they can 
attract some small share by being different, small share that is 
still worthwhile because it's a much larger market.  I'm 
suggesting mobile is the latter opportunity for D.

As for "being an alien," eh, we can make it fit.  As you yourself 
said, there are many other languages jockeying for position on 
mobile, it's not all just Java and Obj-C.
Apr 07 2017
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Apr 07 2017
parent reply Joakim <dlang joakim.fea.st> writes:
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-a
d-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.
Apr 12 2017
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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.
Apr 12 2017
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2017-04-12 at 10:43 +0100, rikki cattermole via Digitalmars-d
wrote:

 [=E2=80=A6]
=20
 JNI itself isn't hard to work with, its mapping classes for D easily
 to=C2=A0
 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

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Apr 12 2017
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 12/04/2017 10:54 AM, Russel Winder via Digitalmars-d wrote:

 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


Considering it was created in 2014, I think we're safe implementing 
extern(JNI) support either which ways.

Although a little strange since nobody has completed a full JNI 
implementation yet!
Apr 12 2017
next sibling parent Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2017-04-12 at 10:59 +0100, rikki cattermole via Digitalmars-d
wrote:

 [=E2=80=A6]
=20
 Considering it was created in 2014, I think we're safe implementing=C2=A0
 extern(JNI) support either which ways.
=20
 Although a little strange since nobody has completed a full JNI=C2=A0
 implementation yet!


JNI will be around for decades because of the way deprecation works in
Javaland. I suspect though that if Charles gets the support of the JNA
folk to back his JNR basis for this proposal, it can all happen quite
quickly. JDK10 being possible though JDK11 more likely.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
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
Apr 13 2017
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 13 April 2017 at 10:12, Russel Winder via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On Wed, 2017-04-12 at 10:59 +0100, rikki cattermole via Digitalmars-d
 wrote:

 […]

 Considering it was created in 2014, I think we're safe implementing
 extern(JNI) support either which ways.

 Although a little strange since nobody has completed a full JNI
 implementation yet!


 JNI will be around for decades because of the way deprecation works in
 Javaland. I suspect though that if Charles gets the support of the JNA
 folk to back his JNR basis for this proposal, it can all happen quite
 quickly. JDK10 being possible though JDK11 more likely.


It may be of worthy note that gcc has dropped the Java frontend (gcj)
and thus the JNI from C/C++ in the compiler.

If JNI can work as a library, then there's no problem, however.
Apr 13 2017
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 13/04/2017 10:30 AM, Iain Buclaw via Digitalmars-d wrote:

 On 13 April 2017 at 10:12, Russel Winder via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 On Wed, 2017-04-12 at 10:59 +0100, rikki cattermole via Digitalmars-d
 wrote:

 […]

 Considering it was created in 2014, I think we're safe implementing
 extern(JNI) support either which ways.

 Although a little strange since nobody has completed a full JNI
 implementation yet!


 JNI will be around for decades because of the way deprecation works in
 Javaland. I suspect though that if Charles gets the support of the JNA
 folk to back his JNR basis for this proposal, it can all happen quite
 quickly. JDK10 being possible though JDK11 more likely.


 It may be of worthy note that gcc has dropped the Java frontend (gcj)
 and thus the JNI from C/C++ in the compiler.

 If JNI can work as a library, then there's no problem, however.


Tried as a library, not easy to get right, compiler would be a good deal 
better.
Apr 13 2017
prev sibling next sibling parent reply kinke <noone nowhere.com> writes:
On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote:

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


I don't think x86 is dying soon, but I agree that embedded 
architectures get more important every day and should get more 
focus.


 I would even go so far as to say it may be worthwhile to 
 develop an ARM backend for dmd.


Wasted efforts in my view, there are so many other aspects 
regarding D which need to be worked on and polished, and we 
already have (unlike DMD, fully free!) D compilers able to target 
most architectures used on this planet (with varying level of 
support obviously, but at least the back-ends are already there). 
I really don't think DMD for ARM would increase D's popularity on 
embedded platforms in any way.


 More than anything else, we need the community to try building 
 mobile libraries and apps, because compiler support is largely 
 done.


What LDC would primarily need is a CI platform supporting ARM 
(and ideally AArch64) in order to make it a true first-class 
target. We don't know of a free CI platform, so ARM isn't tested 
automatically, and it's currently mostly up to poor you to check 
for regressions. ;(

Instead of working on an ARM backend for DMD, broadening the 
upstream runtime libraries for more architectures would make much 
more sense to me, as it's currently up to LDC and GDC with their 
severely limited manpower (and the even more limited available 
hardware to test on) to extend druntime/Phobos for non-x86 
platforms. E.g., for AArch64, Phobos fully supporting 
quad-precision floating-point math would make things easier for 
us. And full big-endian support in Phobos would be nice for 
PowerPC targets.
Apr 06 2017
next sibling parent Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
On Thursday, 6 April 2017 at 09:39:05 UTC, kinke wrote:

 we already have (unlike DMD, fully free!) D compilers able to 
 ...


DMD is now fully free:

https://forum.dlang.org/post/oc8acc$1ei9$1 digitalmars.com
Apr 13 2017
prev sibling parent reply Johan Engelen <j j.nl> writes:
On Thursday, 6 April 2017 at 09:39:05 UTC, kinke wrote:

 What LDC would primarily need is a CI platform supporting ARM 
 (and ideally AArch64) in order to make it a true first-class 
 target. We don't know of a free CI platform, so ARM isn't 
 tested automatically, and it's currently mostly up to poor you 
 to check for regressions. ;(


I bought a Pi3 and was planning to use it as tester for LDC. But 
so far, I've only spent time to build LDC on it and run the tests 
once.

Kai worked on setting up a buildbot infrastructure that we can 
use for automated testing, but the full integration with Github 
was still a work-in-progress I think. Would have to ask Kai if 
that's the current status.
I'd be happy to use the Pi3 as permanent tester, if the risks of 
a hacker intruding my home network are manageable ;-)

cheers,
   Johan
Apr 15 2017
next sibling parent reply Laeeth Isharc <laeethnospam nospam.laeeth.com> writes:
On Saturday, 15 April 2017 at 09:52:49 UTC, Johan Engelen wrote:

 On Thursday, 6 April 2017 at 09:39:05 UTC, kinke wrote:

 What LDC would primarily need is a CI platform supporting ARM 
 (and ideally AArch64) in order to make it a true first-class 
 target. We don't know of a free CI platform, so ARM isn't 
 tested automatically, and it's currently mostly up to poor you 
 to check for regressions. ;(


 I bought a Pi3 and was planning to use it as tester for LDC. 
 But so far, I've only spent time to build LDC on it and run the 
 tests once.

 Kai worked on setting up a buildbot infrastructure that we can 
 use for automated testing, but the full integration with Github 
 was still a work-in-progress I think. Would have to ask Kai if 
 that's the current status.
 I'd be happy to use the Pi3 as permanent tester, if the risks 
 of a hacker intruding my home network are manageable ;-)

 cheers,
   Johan


Not sure how much memory ldc takes to build.  If it would be 
helpful for ARM I could contribute a couple of servers on 
scaleway or similar.  I get a lot of value from LDC and would 
like to be able to have mature platform for android ARM too, so 
happy to contribute some small thing back.   Android servers also 
interesting longer term, though I couldn't yet find anything 
interesting vs what's available on Intel.  (I rent bare metal 
fairly beefy servers from  OVH). Just let me know if it would be 
helpful.

Gitlab has test runners built in, at least for enterprise version 
(which is not particularly expensive) and we have been happy with 
that.

Laeeth
Apr 15 2017
next sibling parent Johan Engelen <j j.nl> writes:
On Saturday, 15 April 2017 at 15:11:08 UTC, Laeeth Isharc wrote:

 Not sure how much memory ldc takes to build.  If it would be 
 helpful for ARM I could contribute a couple of servers on 
 scaleway or similar.


That'd be great. Can you take initiative and send a mail to Kai 
and ask him about the buildbot setup he made?

Thanks!
   Johan
Apr 15 2017
prev sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 15 Apr 2017 15:11:08 +0000
schrieb Laeeth Isharc <laeethnospam nospam.laeeth.com>:


 
 Not sure how much memory ldc takes to build.  If it would be 
 helpful for ARM I could contribute a couple of servers on 
 scaleway or similar.  


At least for GDC building the compiler on low-end platforms is too
resource demanding (Though the times when std.datetime needed > 2GB ram
to compile are gone for good, IIRC). I think cross-compiler tetsing is
the solution here but that involves some work on the DMD test runner.


 Gitlab has test runners built in, at least for enterprise version 
 (which is not particularly expensive) and we have been happy with 
 that.
 
 Laeeth
 


The free version has test runner as well. What bothers me about gitlab
is the github integration. gitlab-CI only works with a gitlab instance
so you have to mirror the github repository to gitlab. This is usually
not too difficult, but you have to be careful to make pull request
tsting and similar more complex ffeatures work correctly. I also think
they don't have anything ready to push CI status to github.


-- Johannes
Apr 16 2017
parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 16 April 2017 at 09:41, Johannes Pfau via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Am Sat, 15 Apr 2017 15:11:08 +0000
 schrieb Laeeth Isharc <laeethnospam nospam.laeeth.com>:

 Gitlab has test runners built in, at least for enterprise version
 (which is not particularly expensive) and we have been happy with
 that.

 Laeeth


 The free version has test runner as well. What bothers me about gitlab
 is the github integration. gitlab-CI only works with a gitlab instance
 so you have to mirror the github repository to gitlab. This is usually
 not too difficult, but you have to be careful to make pull request
 tsting and similar more complex ffeatures work correctly. I also think
 they don't have anything ready to push CI status to github.


 -- Johannes


I asked at a recent D meetup about what gitlab CI used as their
backing platform, and it seems like it's a front for TravisCI.  YMMV,
but I found the Travis platform to be too slow (it was struggling to
even build GDC in under 40 minutes), and too limiting to be used as a
CI for large projects.

Whereas I don't really have much bad to say about Semaphore, as it's
able to download, build, *and* run testsuite in under 15 minutes at
the best of times [1].

Johannes, what if I get a couple new small boxes, one ARM, one
non-descriptive x86.  The project site and binary downloads could then
be used to the non-descriptive box, meanwhile the ARM box and the
existing server can be turned into a build servers - there's enough
disk space and memory on the current server to have a at least half a
dozen build environments on the current server, testing also i386 and
x32 would be beneficial along with any number cross-compilers
(testsuite can be ran with runnable tests disabled).

[1]: https://semaphoreci.com/d-programming-gdc/gdc/branches/master/builds/330
Apr 16 2017
parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 16 Apr 2017 10:13:50 +0200
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>:


 
 I asked at a recent D meetup about what gitlab CI used as their
 backing platform, and it seems like it's a front for TravisCI.  YMMV,
 but I found the Travis platform to be too slow (it was struggling to
 even build GDC in under 40 minutes), and too limiting to be used as a
 CI for large projects.


That's probably for the hosted gitlab solution though. For self-hosted
gitlab you can set up custom machines as gitlab workers. The biggest
drawback here is missing gitlab integration.


 
 Johannes, what if I get a couple new small boxes, one ARM, one
 non-descriptive x86.  The project site and binary downloads could then
 be used to the non-descriptive box, meanwhile the ARM box and the
 existing server can be turned into a build servers - there's enough
 disk space and memory on the current server to have a at least half a
 dozen build environments on the current server, testing also i386 and
 x32 would be beneficial along with any number cross-compilers
 (testsuite can be ran with runnable tests disabled).


Sounds like a plan. What CI server should we use though?

I tried concourse-ci which seems nice at first, but it's too
opinionated to be useful for us (now worker cache, no way for newer
commits to auto-cancel builds for older commits, ...)


-- Johannes
Apr 16 2017
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 16 April 2017 at 11:20, Johannes Pfau via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Am Sun, 16 Apr 2017 10:13:50 +0200
 schrieb Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>:


 I asked at a recent D meetup about what gitlab CI used as their
 backing platform, and it seems like it's a front for TravisCI.  YMMV,
 but I found the Travis platform to be too slow (it was struggling to
 even build GDC in under 40 minutes), and too limiting to be used as a
 CI for large projects.


 That's probably for the hosted gitlab solution though. For self-hosted
 gitlab you can set up custom machines as gitlab workers. The biggest
 drawback here is missing gitlab integration.


 Johannes, what if I get a couple new small boxes, one ARM, one
 non-descriptive x86.  The project site and binary downloads could then
 be used to the non-descriptive box, meanwhile the ARM box and the
 existing server can be turned into a build servers - there's enough
 disk space and memory on the current server to have a at least half a
 dozen build environments on the current server, testing also i386 and
 x32 would be beneficial along with any number cross-compilers
 (testsuite can be ran with runnable tests disabled).


 Sounds like a plan. What CI server should we use though?


I was thinking of keeping it simple, buildbot maybe?

http://buildbot.net/
Apr 16 2017
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 16 April 2017 at 11:20, Johannes Pfau via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Am Sun, 16 Apr 2017 10:13:50 +0200

 I tried concourse-ci which seems nice at first, but it's too
 opinionated to be useful for us (now worker cache, no way for newer
 commits to auto-cancel builds for older commits, ...)


Perhaps use docker layers as a cache then?
Apr 16 2017
prev sibling next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 16 April 2017 at 11:54, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 On 16 April 2017 at 11:20, Johannes Pfau via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 Am Sun, 16 Apr 2017 10:13:50 +0200
 schrieb Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>:


 I asked at a recent D meetup about what gitlab CI used as their
 backing platform, and it seems like it's a front for TravisCI.  YMMV,
 but I found the Travis platform to be too slow (it was struggling to
 even build GDC in under 40 minutes), and too limiting to be used as a
 CI for large projects.


 That's probably for the hosted gitlab solution though. For self-hosted
 gitlab you can set up custom machines as gitlab workers. The biggest
 drawback here is missing gitlab integration.


 Johannes, what if I get a couple new small boxes, one ARM, one
 non-descriptive x86.  The project site and binary downloads could then
 be used to the non-descriptive box, meanwhile the ARM box and the
 existing server can be turned into a build servers - there's enough
 disk space and memory on the current server to have a at least half a
 dozen build environments on the current server, testing also i386 and
 x32 would be beneficial along with any number cross-compilers
 (testsuite can be ran with runnable tests disabled).


 Sounds like a plan. What CI server should we use though?


 I was thinking of keeping it simple, buildbot maybe?

 http://buildbot.net/



I provisionally got an account with these guys last month, and now
I've just seen this:

https://blog.online.net/2017/04/27/scaleway-disruptive-armv8-cloud-servers/

So that's 3 build servers - 1x ARM7, 1x ARM8, and 1x x86. ;-)
May 01 2017
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 May 2017 at 14:40, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 So that's 3 build servers - 1x ARM7, 1x ARM8, and 1x x86. ;-)


With the latter also testing all crosses we can do (there are 18
different gdc cross-compilers in Ubuntu, for 12 distinct
architectures).
May 01 2017
parent reply Johannes Pfau <nospam example.com> writes:
Am Mon, 1 May 2017 14:44:35 +0200
schrieb Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>:


 On 1 May 2017 at 14:40, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 So that's 3 build servers - 1x ARM7, 1x ARM8, and 1x x86. ;-)  


 
 With the latter also testing all crosses we can do (there are 18
 different gdc cross-compilers in Ubuntu, for 12 distinct
 architectures).


BTW is there some documentation on how to update / rebuild these
debian / ubuntu packages with updated GDC sources? 

-- Johannes
May 01 2017
next sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 May 2017 at 17:47, Johannes Pfau via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 Am Mon, 1 May 2017 14:44:35 +0200
 schrieb Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>:


 On 1 May 2017 at 14:40, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 So that's 3 build servers - 1x ARM7, 1x ARM8, and 1x x86. ;-)


 With the latter also testing all crosses we can do (there are 18
 different gdc cross-compilers in Ubuntu, for 12 distinct
 architectures).


 BTW is there some documentation on how to update / rebuild these
 debian / ubuntu packages with updated GDC sources?

 -- Johannes


Doubt it, the debian source packages are quite complex too - though
there's only a few places that need changing, once you work out
exactly *where*.

As you're just updating GDC sources, it should just be a case of
replacing the gdc tarball with a new copy, and the rest is already
handled.
May 01 2017
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 May 2017 at 18:18, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 On 1 May 2017 at 17:47, Johannes Pfau via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:

 Am Mon, 1 May 2017 14:44:35 +0200
 schrieb Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>:


 On 1 May 2017 at 14:40, Iain Buclaw <ibuclaw gdcproject.org> wrote:

 So that's 3 build servers - 1x ARM7, 1x ARM8, and 1x x86. ;-)


 With the latter also testing all crosses we can do (there are 18
 different gdc cross-compilers in Ubuntu, for 12 distinct
 architectures).


 BTW is there some documentation on how to update / rebuild these
 debian / ubuntu packages with updated GDC sources?

 -- Johannes


 Doubt it, the debian source packages are quite complex too - though
 there's only a few places that need changing, once you work out
 exactly *where*.

 As you're just updating GDC sources, it should just be a case of
 replacing the gdc tarball with a new copy, and the rest is already
 handled.


Though for the purpose of CI, we could either build the toolchain
ourselves - either using https://crosstool-ng.github.io, or re-use the
existing cross toolchains in Ubuntu - in both cases, cache the
finished set-up in a docker image.  Building GDC would be still done
by hand just to keep things simple, which should only be a case of
configuring the correct host and target triplet (or maybe
http://build-gdc.readthedocs.io :-)
May 01 2017
prev sibling parent Johannes Pfau <nospam example.com> writes:
Am Sat, 15 Apr 2017 09:52:49 +0000
schrieb Johan Engelen <j j.nl>:


 I'd be happy to use the Pi3 as permanent tester, if the risks of=20
 a hacker intruding my home network are manageable ;-)
=20


If you want to be sure use a cheap DMZ setup.

VLAN based:=20
Connect your PI to some switch supporting VLAN and use an untagged port
assigned to one VLAN (i.e. the raspberry port only communicates in one
VLAN). Then if you use an OpenWRT/LEDE or similar main router simply set
up a custom firewall zone for that VLAN and disable routing between this
zone and your home LAN zone.

If you don't have a capable main router there's another solution: Buy a
cheap wr841n router for 15=E2=82=AC
(https://wiki.openwrt.org/toh/tp-link/tl-wr841nd)
* install LEDE (lede-project.org)
* connect the router to your home lan and the raspberry pi
  * home network: DHCP client, wan
  * raspberry pi: DHCP Server, lan
* Adjust firewall to drop packets to/from your local home LAN range
  (manually or using bcp38 and luci-app-bcp38 packages)


-- Johannes
Apr 16 2017
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote:


 That means this tidal wave of mobile swamping PCs is only going 
 to get worse:


That remains to be seen.


 Even Microsoft has announced that they're taking another shot 
 at ARM, ie Windows is coming to ARM again, this time with x86 
 emulation for old Win32 apps:

 http://www.theverge.com/2016/12/7/13866936/microsoft-windows-10-arm-desktop-apps-support-qualcomm


ARM is *rising*, that's true. But there is no factual evidence in 
their decision (that you seem to know) backing your point. 
Microsoft, Apple, Google, ... all invest in projects they end up 
abandoning.


 I would even go so far as to say it may be worthwhile to 
 develop an ARM backend for dmd.


LDC, GDC


 More than anything else, we need the community to try building 
 mobile libraries and apps, because compiler support is largely 
 done.  We need to integrate mobile into our plans, rather than 
 it just being a sideline.


IoT, Cloud


 The latter may seem far-fetched given D has not done that well 
 in desktop GUI apps, but mobile is still a new market and D 
 could do well.  D is uniquely well-suited to mobile, because 
 it's nicer than Java or Obj-C while more efficient than the 
 former, and it could make it easier to go cross-platform.

 Vadim has done some nice work building DLangUI on Android, 
 including a Tetris app that I spent half an hour playing on my 
 phone:


Any unpolished GUI toolkit (even when polished) will not sell on 
android-iOS except for Games with custom drawn elements. C++ is 
in that same position. Google is busy pushing Java, Apple is busy 
pushing Swift. DlangUI could work but will not land you a big 
share in usage.



 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.


With the *rising* market for IoT and Cloud, the effort invested 
in ARM should be geared towards these areas with much potential. 
Canonical just gave up their Ubuntu Touch (Mobile OS) and Unity 8 
DE to invest their resources in Cloud and IoT. Fighting for 
mobile apps market (except for WebGL/OpenGL/Vulkan games), which 
big corporates like Microsoft are also in fighting but losing 
doesn't seem like a good idea.

IoT and Cloud entails ML, AI, NLP, embedded programming, bots, 
microservices, containerization, robotics... which mir, vibe.d, 
mqtt, and its projects are implementing some in bits.

Thats what you can say has potential cus they are actually 
*rising*



 Apr 06 2017



prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com>  writes:


On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote:

 There are only two devs working on mobile, Dan and me, I don't 
 think anybody on the core team has even tried our work.


I don't even own a mobile device and don't see that changing any 
time soon (they are really expensive, slow, and just generally 
hard to use*). I do own a raspberry pi, but never actually use 
anyway so I have no need to develop for it.

If I actually used one of these things, I'd probably join you in 
hacking together stuff the way I've done web and desktop libs, 
but I just don't use the hardware....



 Apr 06 2017



  parent  "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com>  writes:


On 04/06/2017 08:52 AM, Adam D. Ruppe wrote:

 I don't even own a mobile device and don't see that changing any time
 soon (they are really expensive, slow, and just generally hard to use*).


That last point is so very true. Bugs me so much that 99.999% of mobile 
users never really understood the difference between "easy to learn" and 
"easy to use".

And frankly, if you ask me, the only real thing that ever made those 
hieroglyph-heavy, non-discoverable-gesture-reliant devices "easy to 
learn" was the fact that Steve Jobs was very insistent on making sure 
everyone called it a "phone" and that they were to NEVER be called 

a computer: epidemic knee-jerk intimidation at the mere mention of the 
work "computer". iPhones (and Android) were NEVER easy to learn (who in 
the world EVER learned how to switch between running applications on an 
iPhone without somebody having to explain it to them first? Nobody. 100% 
non-discoverable.). But unlike computers, people actually bothered to 
try, because they were told they were "phones" and "Oh, I know how to 
use a phone!". "Phone" isn't scary. "Computer" is scary. My PalmOS 
devices were VASTLY easier to get things done on. All they really needed 
was WiFi (which was expensive at the time) and a better camera.

I don't blame you. Only reason I eventually wound up getting a 
"smartphone" is so I could have basic internet connectivity while AFK. 
(And because both my watch and portable music player finally died, so I 
was like, meh, well, I can take care of all that at once.) But for most 
tasks, it's quicker and easier to just wait until I'm back at the PC.



 Apr 12 2017



prev sibling next sibling parent  Radu <void null.pt>  writes:


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:

 http://www.theverge.com/2017/3/29/15104600/samsung-dex-galaxy-s8-dock-announced-price-release-date
 https://www.youtube.com/watch?v=QA31CaL_42A

 That means this tidal wave of mobile swamping PCs is only going 
 to get worse:

 https://twitter.com/lukew/status/842397687420923904

 D is currently built and optimized for that dying PC platform.  
 There are only two devs working on mobile, Dan and me, I don't 
 think anybody on the core team has even tried our work.

 Even Microsoft has announced that they're taking another shot 
 at ARM, ie Windows is coming to ARM again, this time with x86 
 emulation for old Win32 apps:

 http://www.theverge.com/2016/12/7/13866936/microsoft-windows-10-arm-desktop-apps-support-qualcomm

 I would even go so far as to say it may be worthwhile to 
 develop an ARM backend for dmd.

 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:

 https://github.com/ldc-developers/ldc/issues/2058

 I provide Android releases of ldc here:

 https://github.com/joakim-noah/android/releases

 We've been fixing Android/ARM regressions in the latest D 
 releases here:

 https://github.com/ldc-developers/ldc/issues/2024

 More than anything else, we need the community to try building 
 mobile libraries and apps, because compiler support is largely 
 done.  We need to integrate mobile into our plans, rather than 
 it just being a sideline.

 There are two main possibilities for D usage on mobile right 
 now:

 - D libraries for faster code than the native languages
 - full GUI apps written in D, likely cross-platform

 The latter may seem far-fetched given D has not done that well 
 in desktop GUI apps, but mobile is still a new market and D 
 could do well.  D is uniquely well-suited to mobile, because 
 it's nicer than Java or Obj-C while more efficient than the 
 former, and it could make it easier to go cross-platform.

 Vadim has done some nice work building DLangUI on Android, 
 including a Tetris app that I spent half an hour playing on my 
 phone:

 http://forum.dlang.org/thread/cdekkumjynhqoxvmgjze forum.dlang.org

 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.


I think mobile would be nice, but there needs to be a good full 
stack (game lib, UI lib, maybe both) packaged with the compiler 
and runtime in order to get people attention.

What I see as something that can be targeted from day one is IoT, 
industrial controllers, cloud and other embedded/backend 
platforms (I'm basically agreeing with aberba's post).

I'm currently trying the armv5 platform, as you pointed out. The 
possibilities are far more appealing for me to use the D stack on 
Linux/Arm(Mips) as everything I know in the industrial space uses 
this combination.

Being able to create software with a nicer language using nicer 
libraries would be the "killer app" for an entire industry.

I think there is great potential and the proverbial 
low-hanging-fruit here for getting stuff rolling.

Would be great if we could persuade the D foundation to sponsor 
some Linux ARM/Mips CI infrastructure, I know I would pitch in my 
2 cents for the cause.
This infrastructure could be used by LDC and GDC and be extended 
in the future.



 Apr 06 2017



prev sibling next sibling parent reply aberba <karabutaworld gmail.com>  writes:


On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote:

 and pitch in, like this guy who's now trying ldc out on an 
 embedded device with an old ARMv5 core:

 https://github.com/ldc-developers/ldc/issues/2058


What is currently needed for D in IoT?



 Apr 06 2017



  parent  Petar Kirov [ZombineDev] <petar.p.kirov gmail.com>  writes:


On Thursday, 6 April 2017 at 19:02:00 UTC, aberba wrote:

 On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote:

 and pitch in, like this guy who's now trying ldc out on an 
 embedded device with an old ARMv5 core:

 https://github.com/ldc-developers/ldc/issues/2058


 What is currently needed for D in IoT?


The most important catalyst for improving the support for new 
platforms (embedded, IoT, mobile, you name it) is good continuous 
integration (CI). None of the major free CI providers (TravisCI, 
CircleCI, SemaphoreCI, AppVeyor, etc,) provide non-x86 runners. 
The only option (at least AFAIK) is software emulation with QEMU, 
though I haven't looked much into it (yet).



 Apr 06 2017



prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 4/6/17 7:24 AM, 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:


[snip]

 The latter may seem far-fetched given D has not done that well in
 desktop GUI apps, but mobile is still a new market and D could do well.
 D is uniquely well-suited to mobile, because it's nicer than Java or
 Obj-C while more efficient than the former, and it could make it easier
 to go cross-platform.


Let's not forget Kotlin and Swift, things we'd really be competing 
against - that is the other NEW stuff.

Also let's not forget the _legion_ of tools that let you do 
cross-platform mobile app development in languages such as JavaScript, 



 Vadim has done some nice work building DLangUI on Android, including a
 Tetris app that I spent half an hour playing on my phone:

 http://forum.dlang.org/thread/cdekkumjynhqoxvmgjze forum.dlang.org

 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.


Much as I like D I would admit that even Desktop/Server developer 
experience is far from stellar. Now switching to mobile the expectations 
of mobile developers are much higher - they want a ready made 
development environment, full support of platform APIs, thousands of 
examples, ready made GUI components, tons of documentation, perfect 
support for all manner of proprietary tools such as code signing, 
emulators, you name it. Anything short of completely polished devkit is 
not going to succeed.

Most importantly though we would need to change the perception: trying 
to be a D mobile app developer is doubly niche - first because of D, 
second being an alien in mobile development.

---
Dmitry Olshansky



 Apr 06 2017



  parent reply Bienlein <jeti789 web.de>  writes:


 Let's not forget Kotlin and Swift, things we'd really be 
 competing against - that is the other NEW stuff.


Kotlin/Native is now in the making and there is already a preview:

https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-preview-kotlin-without-a-vm/



 May 08 2017



  parent  Dmitry Olshansky <dmitry.olsh gmail.com>  writes:


On 5/8/17 9:26 PM, Bienlein wrote:

 Let's not forget Kotlin and Swift, things we'd really be competing
 against - that is the other NEW stuff.


 Kotlin/Native is now in the making and there is already a preview:

 https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-preview-kotlin-without-a-vm/


All in all Kotlin is a decent language, also since JetBrains has Russian 
roots I kind of sympathize its development :)

---
Dmitry Olshansky



 May 08 2017



prev sibling next sibling parent reply Marco Leise <Marco.Leise gmx.de>  writes:


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=20
 try it out and pitch in, like this guy who's now trying ldc out=20
 on an embedded device with an old ARMv5 core:

[=E2=80=A6]

 I realize D is never going to have a polished devkit for mobile=20
 unless a company steps up and charges for that work.  But we can=20
 do a lot better than the complacency from the community we have=20
 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.

--=20
Marco



 Apr 07 2017



 next sibling parent  aberba <karabutaworld gmail.com>  writes:


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

 [...]





 Apr 07 2017



prev sibling  parent reply Nick B <nick.barbalich gmail.com>  writes:


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 ?



 Apr 09 2017



  parent  Marco Leise <Marco.Leise gmx.de>  writes:


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



 Apr 11 2017



prev sibling next sibling parent reply Jethro <qyzz gr.ff>  writes:


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.



 Apr 07 2017



  parent  Nick B <nick.barbalich gmail.com>  writes:


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.



 Apr 09 2017



prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com>  writes:


I *strongly* agree with the notion that mobile/ARM/iOS/'droid/etc needs 
to be a major part of D's immediate future.

However...

On 04/06/2017 01:24 AM, 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:


If you look into the details and current reality of the S8's docked 
mode, *at best* it's equivalent to Windows 8.0 and will remain so for at 
least a couple years or so: It's connecting a keyboard/mouse/monitor to 
a software ecosystem that is still 90% tailored for handheld formfactor.

Ie, at best, it's going to be awhile before it's docked mode is 
realistically usable as a Win/Lin/OSX replacement (as opposed to a 
mobile projected onto a 20" screen). And by then, they'll be building 
hype for Galaxy S10 or so.

Not saying it won't happen at some point in the near-to-mid future, but 
time has proven that each of these attempts, individually, only each 
have a modest chance of really taking off (and frankly, I've seen other 
attempts that did a better job - namely the abandoned one Ubuntu had 
been working on, which ran the *actual* Ubuntu desktop when you plugged 
in monitor/keyboard/mouse). Even if Samsung does succeed in making the 
Galaxy a genuine desktop option, it's definitely not going to happen 
within the S8's lifetime. This is just the "early adopter tech-preview" 
device.


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


This is just hyperbole. Declining != dying.



 Apr 12 2017



  parent reply Joakim <dlang joakim.fea.st>  writes:


On Wednesday, 12 April 2017 at 19:20:27 UTC, Nick Sabalausky 
(Abscissa) wrote:

 I *strongly* agree with the notion that 
 mobile/ARM/iOS/'droid/etc needs to be a major part of D's 
 immediate future.

 However...

 On 04/06/2017 01:24 AM, 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:


 If you look into the details and current reality of the S8's 
 docked mode, *at best* it's equivalent to Windows 8.0 and will 
 remain so for at least a couple years or so: It's connecting a 
 keyboard/mouse/monitor to a software ecosystem that is still 
 90% tailored for handheld formfactor.


I'm guessing you mean that it's equivalent because most Windows 
apps were never redone for their mobile platform, but the S8 and 
Nougat are ahead in one key area: their docked support actually 
has full multi-window, unlike Microsoft's similar Continuum 
docked mode which only supports using apps in fullscreen (that 
may be changing with the just-released Creators update).


 Ie, at best, it's going to be awhile before it's docked mode is 
 realistically usable as a Win/Lin/OSX replacement (as opposed 
 to a mobile projected onto a 20" screen). And by then, they'll 
 be building hype for Galaxy S10 or so.


No, the mobile apps run in their own smaller windows, so they're 
not projected to the full 20" screen, unlike with Continuum.  
You're right that most mobile apps haven't been redone for this 
docked mode, but you can usually use them just fine with a mouse 
and keyboard.

I'm doing it right now: Chrome for Android has had keyboard 
shortcuts for a long time and Android has long supported mouse 
pointers.  I'm typing this into an Android tablet with a 
bluetooth keyboard, and Alt-tabbing back to the Termux app to 
look at D code:

https://play.google.com/store/apps/details?id=com.termux&hl=en

It's been usable for me since I installed Termux in late 2015, 
which is why I didn't bother buying anything else when my Win7 
ultrabook died then.  With Android 7.0 Nougat, which builds 
native multi-window into every Android device, you'll be able to 
screencast even budget phones like this:

https://arstechnica.com/gadgets/2017/03/moto-g5-plus-review-still-good-and-cheap-but-not-the-bargain-it-once-was/

though it requires an app to enable it:

http://www.androidpolice.com/2016/08/27/taskbar-lets-enable-freeform-mode-android-nougat-without-root-adb/
http://www.androidpolice.com/2016/09/19/taskbar-updated-version-1-2-can-now-completely-replace-home-screen/


 Not saying it won't happen at some point in the near-to-mid 
 future, but time has proven that each of these attempts, 
 individually, only each have a modest chance of really taking 
 off (and frankly, I've seen other attempts that did a better 
 job - namely the abandoned one Ubuntu had been working on, 
 which ran the *actual* Ubuntu desktop when you plugged in 
 monitor/keyboard/mouse). Even if Samsung does succeed in making 
 the Galaxy a genuine desktop option, it's definitely not going 
 to happen within the S8's lifetime. This is just the "early 
 adopter tech-preview" device.


Sure, but we're talking about an attempt now with a software 
platform that sells more than a billion devices per year, and 
with a device, the S8, that will sell tens of millions.  That is 
a first compared to the previous efforts you list, and make this 
more likely to succeed.


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


 This is just hyperbole. Declining != dying.


"Luke, you're going to find that many of the truths we cling to 
depend greatly on our own point of view."

 From a certain point of view, you could say PC sales are only 
down 25% from their peak, that's not dead yet.  But the chart I 
linked shows their share of personal computing devices, including 
mobile, has dropped from 78% to a little less than 14% over the 
last decade.  I'd call that dying.



 Apr 13 2017



  parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com>  writes:


On 04/13/2017 06:16 PM, Joakim wrote:

  From a certain point of view, you could say PC sales are only down 25%
 from their peak, that's not dead yet.  But the chart I linked shows
 their share of personal computing devices, including mobile, has dropped
 from 78% to a little less than 14% over the last decade.  I'd call that
 dying.


In other words: It can only be considered "dying" if you conveniently 
ignore certain facts, and instead look only at a stat that doesn't show 
the full picture.



 Apr 19 2017



  parent reply Joakim <dlang joakim.fea.st>  writes:


On Wednesday, 19 April 2017 at 17:47:50 UTC, Nick Sabalausky 
(Abscissa) wrote:

 On 04/13/2017 06:16 PM, Joakim wrote:

  From a certain point of view, you could say PC sales are only 
 down 25%
 from their peak, that's not dead yet.  But the chart I linked 
 shows
 their share of personal computing devices, including mobile, 
 has dropped
 from 78% to a little less than 14% over the last decade.  I'd 
 call that
 dying.


 In other words: It can only be considered "dying" if you 
 conveniently ignore certain facts, and instead look only at a 
 stat that doesn't show the full picture.


On the contrary, my point is "the full picture" shows sales as a 
share of computing devices dying, whereas only looking at the PC 
market alone is misleading. The mobile tidal wave has taken away 
sales that would have been PCs instead, likely more than 25% if 
we extrapolate out the former PC sales growth rate, rather than 
just compare to the peak.

Just as the underpowered PC once disrupted the market for 
minicomputers and UNIX workstations, mobile is doing the same to 
the PC.  Whereas people used to check their email, browse the 
web, and ogle facebook on their PCs before, they just use a 
mobile device for those former PC-only activities now.

And now that the mobile market is so much bigger than PCs, 
they're finally going after what remains of the PC market: those 
who want to get work done on a bigger screen which supports 
viewing multiple windows at once.  This isn't going to happen 
overnight, as it will take years to roll out Android 7.0 Nougat 
with built-in multi-window, get all the needed productivity 
software ported over (though the S8 announcement notes that 
versions of Office and Photoshop are already done), and keep 
iterating and improving on the mobile multi-window experience.

But just as the PC once disrupted the computing market, mobile 
has already disrupted the PC market.  Mobile taking most of the 
rest of the PC market's sales with these multiwindow moves is 
inevitable.  Sure, there will always be a few who run powerful 
desktops, just as I'm sure there's someone out there running a 
UNIX workstation, but you never run into those people anymore 
because they're such a small niche.

I don't know why you get so worked up about this.  Yes, the new 
entrant won't have features the old computers had.  I was using 
virtual desktops on UNIX workstations regularly decades ago, but 
Microsoft didn't add that to the OS till Windows 10 a couple 
years ago.  So what?  Most people got by just fine.



 Apr 19 2017



  parent  rikki cattermole <rikki cattermole.co.nz>  writes:


On 20/04/2017 5:09 AM, Joakim wrote:

 I don't know why you get so worked up about this.  Yes, the new entrant
 won't have features the old computers had.  I was using virtual desktops
 on UNIX workstations regularly decades ago, but Microsoft didn't add
 that to the OS till Windows 10 a couple years ago.  So what?  Most
 people got by just fine.


The API to support multi-desktops has been in Windows for a very long 
time (Windows 2k[0]), it just wasn't exposed in stock Windows.
But if you knew where to look, they certainly did offer it[1]!

[0] 
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682124(v=vs.85).aspx
[1] https://technet.microsoft.com/en-us/sysinternals/cc817881



 Apr 19 2017



prev sibling next sibling parent reply Jerry <hurricane hereiam.com>  writes:


On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote:

 That means this tidal wave of mobile swamping PCs is only going 
 to get worse:

 https://twitter.com/lukew/status/842397687420923904

 D is currently built and optimized for that dying PC platform.  
 There are only two devs working on mobile, Dan and me, I don't 
 think anybody on the core team has even tried our work.


"dying". Just cause there aren't a lot of new devices being sold 
doesn't mean it is dying. There's the used market to consider, 
and PCs have a long lifespan. I have a 7 year old desktop that 
still runs perfectly fine and does all the tasks and computing I 
need to be done. I'll probably be using it for another few years, 
maybe when zen+ comes out or there's actually a reason to buy a 
new computer. Even then I won't be buying a prebuilt, not sure if 
those sales figures includes sales of PC parts. Even though new 
PC sales are declining, GPU sales are seeing a major increase in 
sales.



 May 08 2017



  parent reply Joakim <dlang joakim.fea.st>  writes:


On Tuesday, 9 May 2017 at 04:39:33 UTC, Jerry wrote:

 On Thursday, 6 April 2017 at 05:24:07 UTC, Joakim wrote:

 That means this tidal wave of mobile swamping PCs is only 
 going to get worse:

 https://twitter.com/lukew/status/842397687420923904

 D is currently built and optimized for that dying PC platform.
  There are only two devs working on mobile, Dan and me, I 
 don't think anybody on the core team has even tried our work.


 "dying". Just cause there aren't a lot of new devices being 
 sold doesn't mean it is dying. There's the used market to 
 consider, and PCs have a long lifespan. I have a 7 year old 
 desktop that still runs perfectly fine and does all the tasks 
 and computing I need to be done. I'll probably be using it for 
 another few years, maybe when zen+ comes out or there's 
 actually a reason to buy a new computer. Even then I won't be 
 buying a prebuilt, not sure if those sales figures includes 
 sales of PC parts. Even though new PC sales are declining, GPU 
 sales are seeing a major increase in sales.


On the other hand, even if sales are doubling, that doesn't mean 
you aren't dying.  Consider Blackberry, whose sales rocketed up 
even after the iPhone was first introduced in 2007:

https://www.recode.net/2017/2/26/14742598/blackberry-sales-market-share-chart

Then, all of a sudden, people realized, "Why are we buying these 
old-fashioned keyboard smartphones?"  From 2006-2010 Blackberry 
sales went up 5X, doing really well but still lagging far behind 
the explosive growth of Android/iPhone, and now it is basically 
dead.  The mobile wave killed Blackberry, the previous smartphone 
leader in the US and many other countries.  Nokia was tops 
worldwide, also now dead.

That is similar to what is happening to PCs: a slow decline 
followed by a precipitious collapse, when people realize, "Why 
are we still buying these old-fashioned PCs when we can do 
_everything_ on our mobile devices now?"  When multi-window is 
practically ubiquituous on mobile, which it will be soon since it 
is baked into Android Nougat, that is what will happen.



 May 09 2017



  parent  "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com>  writes:


On Tue, May 09, 2017 at 09:08:17AM +0000, Joakim via Digitalmars-d wrote:
[...]

 On the other hand, even if sales are doubling, that doesn't mean you
 aren't dying.  Consider Blackberry, whose sales rocketed up even after
 the iPhone was first introduced in 2007:
 
 https://www.recode.net/2017/2/26/14742598/blackberry-sales-market-share-chart
 
 Then, all of a sudden, people realized, "Why are we buying these
 old-fashioned keyboard smartphones?"


FWIW, my wife hated the touchphones and clung on to her Blackberry
keyboard for as long as she could. Now she has an iphone (grudgingly)
and slowly getting the hang of it, but still complains that touch typing
is annoying.

History is a cruel master.


T

-- 
Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich Schubert



 May 09 2017



prev sibling  parent reply James W Hofmann <acubicfox gmail.com>  writes:


I happened across this old thread in a search for "mobile app 
dlang". I got a Chromebook recently and it represents a 
substantial phase shift in devices for me:

* It's an ARM laptop (Asus Chromebook R13, big.LITTLE 2/2 cores, 
4GB memory)
* It's also a tablet convertible
* The main OS is the web browser
* The secondary OS is a Linux desktop(via Crouton)
* The other secondary OS is Android(Play Store support)
* They all run simultaneously. ChromeOS supports this with minor 
end-user configuration(hit some secret shortcut keys for 
developer mode, run a shell script, click some boxes).
* It cost under $300 (refurbished) and it's "high end" for the 
product segment, and feels like it

Which means I have ~three software ecosystems(two if you're 
feeling uncharitable,  since all of them can do some web 
browsing) on the same device, all representing different market 
segments but more-or-less successfully converged. Although some 
things like clipboard compatibility aren't in the offing, I can 
switch between them with shortcut keys and share parts of the 
file system without any virtualization or rebooting. And "high 
end mobile" performance covers so many applications that as an 
individual I can only justify trading up for certain heavy 
workloads(large code-bases, high-end gaming, some media editing 
and encoding). If I were feeling daring I could also try running 
Wine, but that's better left to the x86 Chromebooks.

It's gotten me thinking that what we're looking at now is really 
a fully converged computing environment where monopolistic 
bottlenecks on software platforms are  eroded, leaving us back in 
the position of generic device form factors(type and  quantity of 
I/O, energy efficiency requirements) as the main constraints on 
the  application. So "mobile" may also cease to be a category of 
substance at the same time as "desktop" and "Web". We'll just 
have "front-end"/"client", plus some UI forms to cover different 
devices.

At least, that's where we're going. But it's not "there" yet 
except in this particular product line, since Google is forcing 
the issue in it - and the sales figures do suggest that it's 
carving up the PC category and invading schools everywhere.

That thought is playing in my head against recent advertising of 
BetterC - the USP of "give new life to old code" seems like the 
most straightforward way to address this future, since if we 
change our set of assumptions away from "new platforms" in the 
usual sense of a technology shift provoking boil-the-ocean 
rewrites, but instead to a continual agglomeration of new into 
old and old into new, with most shifts occurring within the 
existing stacks instead of without, then leveraging old code by 
every means possible becomes the most important thing.

Which leads me to a great armchair proposal: D should support 
Excel spreadsheets ;)



 Aug 24 2017



 next sibling parent  Nicholas Wilson <iamthewilsonator hotmail.com>  writes:


On Thursday, 24 August 2017 at 10:47:07 UTC, James W Hofmann 
wrote:

 Which leads me to a great armchair proposal: D should support 
 Excel spreadsheets ;)


You say that somewhat in jest but take a look at 
https://github.com/kaleidicassociates/excel-d



 Aug 24 2017



prev sibling next sibling parent  Ryion <Ryion Ryion.com>  writes:


On Thursday, 24 August 2017 at 10:47:07 UTC, James W Hofmann 
wrote:

 I happened across this old thread in a search for "mobile app 
 dlang". I got a Chromebook recently and it represents a 
 substantial phase shift in devices for me:


Arm has indeed become a more compelling platform, especially with 
all the SBC that exist today. Nothing more fun as compiling code 
on a Pi3 and seeing that little monster working like the big boys 
( of course slower ).

Unfortunately, not everything works great. Like LDC being version 
0.14.0 ( 2014! ) on the Pi3 Debian images. And well, 
"_Unwind_RaiseException failed with reason code: 2128056904", on 
a simply compile. Not exactly hopeful.

C works great. C++ same. GoLang version 1.3.3 and later perfect. 
FreePascal totally useless with "An unhandled exception occurred 
at $00084234". Its interesting to see what languages work and 
those that bum out with default debian installations.

So its a mixed bag on ARM development. But people underestimate 
how fast the ARM platform is evolving regarding speed. The Pi3 
has 4 Armv8 A53 cores but you got now systems like Helion X20 
with 2 * A72, 4 * A53 and another 4 * A35... Getting to being 
only 1/4 then a full blown Intel 7600. All that for a 15W max 
package. And this year we are getting 10nm X30 with more updated 
cores. Good times...

The PC evolution market in regards to CPU technology has been 
frankly very dead for the last few years. Small gains each 
generation but nothing impressive. The only impressing thing has 
been the AMD Ryzon's that finally pushed 8 cores into consumer 
hands for a cheap price ( and the thread ripper for 16 for a 
"reasonable" price, unlike Intel there prices for ages ).



 Aug 24 2017



prev sibling next sibling parent reply Joakim <dlang joakim.fea.st>  writes:


On Thursday, 24 August 2017 at 10:47:07 UTC, James W Hofmann 
wrote:

 I happened across this old thread in a search for "mobile app 
 dlang". I got a Chromebook recently and it represents a 
 substantial phase shift in devices for me:

 * It's an ARM laptop (Asus Chromebook R13, big.LITTLE 2/2 
 cores, 4GB memory)
 * It's also a tablet convertible
 * The main OS is the web browser
 * The secondary OS is a Linux desktop(via Crouton)
 * The other secondary OS is Android(Play Store support)
 * They all run simultaneously. ChromeOS supports this with 
 minor end-user configuration(hit some secret shortcut keys for 
 developer mode, run a shell script, click some boxes).
 * It cost under $300 (refurbished) and it's "high end" for the 
 product segment, and feels like it

 Which means I have ~three software ecosystems(two if you're 
 feeling uncharitable,  since all of them can do some web 
 browsing) on the same device, all representing different market 
 segments but more-or-less successfully converged. Although some 
 things like clipboard compatibility aren't in the offing, I can 
 switch between them with shortcut keys and share parts of the 
 file system without any virtualization or rebooting. And "high 
 end mobile" performance covers so many applications that as an 
 individual I can only justify trading up for certain heavy 
 workloads(large code-bases, high-end gaming, some media editing 
 and encoding). If I were feeling daring I could also try 
 running Wine, but that's better left to the x86 Chromebooks.


I've been using an Android tablet with four ARMv7 cores and 3 GBs 
of RAM as my only development hardware for almost two years now.  
I don't game or edit media, but I've had no problem tweaking and 
building fairly large codebases like llvm and ldc on the tablet, 
by using the Termux Android app.  I never had a monster desktop 
with multiple core i7s and 32 GBs of RAM- my last daily driver 
was a Win7 ultrabook with a core i5 and 4 GBs of RAM- so it's not 
that much of a difference, even less if I got something newer 
like you have.


 It's gotten me thinking that what we're looking at now is 
 really a fully converged computing environment where 
 monopolistic bottlenecks on software platforms are  eroded, 
 leaving us back in the position of generic device form 
 factors(type and  quantity of I/O, energy efficiency 
 requirements) as the main constraints on the  application. So 
 "mobile" may also cease to be a category of substance at the 
 same time as "desktop" and "Web". We'll just have 
 "front-end"/"client", plus some UI forms to cover different 
 devices.


What is actually happening is that mobile is killing off both 
desktop and web (see second graph in first link):

http://www.asymco.com/2016/11/02/wherefore-art-thou-macintosh/
https://www.usatoday.com/story/tech/2017/04/12/pc-shipments-dip----again/100347930/

I don't know what you mean by front-end/client, but yeah, we'll 
probably see even more convergence on a few UI frameworks in the 
coming years.  That won't be the web though.


 At least, that's where we're going. But it's not "there" yet 
 except in this particular product line, since Google is forcing 
 the issue in it - and the sales figures do suggest that it's 
 carving up the PC category and invading schools everywhere.


Another possibility is just using your phone for everything, with 
a laptop shell like this:

https://sentio.com

As I noted initially, this is built into the Galaxy S8, one of 
the top-selling smartphones this year.


 That thought is playing in my head against recent advertising 
 of BetterC - the USP of "give new life to old code" seems like 
 the most straightforward way to address this future, since if 
 we change our set of assumptions away from "new platforms" in 
 the usual sense of a technology shift provoking boil-the-ocean 
 rewrites, but instead to a continual agglomeration of new into 
 old and old into new, with most shifts occurring within the 
 existing stacks instead of without, then leveraging old code by 
 every means possible becomes the most important thing.


As others have pointed out, you could use D with C fairly easily 
for some time now.  You had to be a little careful to initialize 
the runtime, but that's about it.  This betterC effort is to 
placate those who can't or won't use the GC and a few other 
runtime features, even though many of them probably could.

So while it's good that D will make an effort to replace more C 
code, I'll also point out that many of the problems with software 
right now come from precisely this incremental approach.  You 
keep building with mud and straw and eventually it all caves in.  
It would be nice if D gives a new lease on life to some ancient 
codebases, but the real potential with D is to build completely 
new tech that obsoletes the old stuff.

To some extent, that is what happened with the mobile shift, 
where nobody uses Wintel, ie x86 CPUs or Windows, on mobile 
(though Microsoft is trying again with ARM).  Another big shift 
that seems to be ramping up right now is a move towards 
voice-driven interaction instead of mouse/keyboard or touch.  The 
hope is that D's power and flexibility drives new shifts like 
this, many of which are long overdue because of the stagnation of 
the last couple decades.

On Thursday, 24 August 2017 at 12:35:08 UTC, Ryion wrote:

 On Thursday, 24 August 2017 at 10:47:07 UTC, James W Hofmann 
 wrote:

 I happened across this old thread in a search for "mobile app 
 dlang". I got a Chromebook recently and it represents a 
 substantial phase shift in devices for me:


 Arm has indeed become a more compelling platform, especially 
 with all the SBC that exist today. Nothing more fun as 
 compiling code on a Pi3 and seeing that little monster working 
 like the big boys ( of course slower ).

 Unfortunately, not everything works great. Like LDC being 
 version 0.14.0 ( 2014! ) on the Pi3 Debian images. And well, 
 "_Unwind_RaiseException failed with reason code: 2128056904", 
 on a simply compile. Not exactly hopeful.


Have you tried this more recent build of ldc 1.1.0 (third link in 
Downloads section at bottom)?

https://github.com/ldc-developers/ldc/releases/tag/v1.1.0


 C works great. C++ same. GoLang version 1.3.3 and later 
 perfect. FreePascal totally useless with "An unhandled 
 exception occurred at $00084234". Its interesting to see what 
 languages work and those that bum out with default debian 
 installations.

 So its a mixed bag on ARM development. But people underestimate 
 how fast the ARM platform is evolving regarding speed. The Pi3 
 has 4 Armv8 A53 cores but you got now systems like Helion X20 
 with 2 * A72, 4 * A53 and another 4 * A35... Getting to being 
 only 1/4 then a full blown Intel 7600. All that for a 15W max 
 package. And this year we are getting 10nm X30 with more 
 updated cores. Good times...


The ARM chip in the iPad Pro supposedly beats the lower and 
mid-end mobile Mac x86 CPUs in benchmarks.


 The PC evolution market in regards to CPU technology has been 
 frankly very dead for the last few years. Small gains each 
 generation but nothing impressive. The only impressing thing 
 has been the AMD Ryzon's that finally pushed 8 cores into 
 consumer hands for a cheap price ( and the thread ripper for 16 
 for a "reasonable" price, unlike Intel there prices for ages ).


More importantly, that core i5 from five years ago is good 
enough.  You cannot compete on performance improvements anymore, 
for the vast majority of consumers.  That's why the 
desktop/laptop PC market is shrinking to only those who need 
powerful hardware for niches like hardcore gaming, compiling 
large C++ codebases, or editing 4K video, which is a tiny market 
compared to mobile.



 Aug 24 2017



  parent  Ryion <Ryion Ryion.com>  writes:


On Thursday, 24 August 2017 at 14:28:07 UTC, Joakim wrote:

 Unfortunately, not everything works great. Like LDC being 
 version 0.14.0 ( 2014! ) on the Pi3 Debian images. And well, 
 "_Unwind_RaiseException failed with reason code: 2128056904", 
 on a simply compile. Not exactly hopeful.


 Have you tried this more recent build of ldc 1.1.0 (third link 
 in Downloads section at bottom)?

 https://github.com/ldc-developers/ldc/releases/tag/v1.1.0


Thanks. I checked the 1.3.0 but there was no ARM build. Did not 
realize there is one for 1.1.0.

For anybody finding this using google search, simply do the 
following to install:


 wget 
 https://github.com/ldc-developers/ldc/releases/download/v1.1.0/ldc2-1.1.0-linux-armhf.tar.xz
 sudo tar -C /usr/local -xf ldc2-1.1.0-linux-armhf.tar.xz
 export PATH=$PATH:/usr/local/ldc2-1.1.0-linux-armhf/bin


My code now works correctly again. Doing some benchmarks 
Apache+PHP vs Go vs D on the Raspberry Pi 3.

n=100000 c=500

Apache: 1488 seconds
Requests per second: 67.20

Go+Gin: 123 seconds
Requests per second: 812.23

D: 149 seconds
Requests per second: 629.46

D is running a simple socket + limited HTTP 1.0/REST framework 
that i gobbled together. No optimizations. Go is running a 
complete HTTP/REST framework so it has more overhead.
Apache+PHP5.6 simply suffer beyond belief.

Take in account, the D has only been done on a single core! Where 
all the others used all 4 cores.

Impressive even if its not apples to apples comparison.



 Aug 24 2017



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2017-08-24 12:47, James W Hofmann wrote:


 Which leads me to a great armchair proposal: D should support Excel 
 spreadsheets ;)


Not sure what you had in mind but have a look at:

http://forum.dlang.org/post/ubheswgdpafyeybohnyb forum.dlang.org

-- 
/Jacob Carlborg



 Aug 24 2017