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
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
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 
 JavaScript, Lua and e.g. C#.
Except for C# to some extent, only because they are now investing 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
prev 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
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
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
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
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 "computers" - hence sidestepping the #1 roadblock in learning how to use 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
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
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
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
prev sibling next sibling parent 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, Lua and e.g. C#.
 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
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
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
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
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
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
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
prev 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
parent 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