Re: What are we going to do about mobile?
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=10 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.
Re: What are we going to do about mobile?
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/ubheswgdpafyeyboh...@forum.dlang.org -- /Jacob Carlborg
Re: What are we going to do about mobile?
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-dipagain/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 sh
Re: What are we going to do about mobile?
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 ).
Re: What are we going to do about mobile?
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
Re: What are we going to do about mobile?
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 ;)
Re: What are we going to do about mobile?
On Tue, May 09, 2017 at 09:08:17AM +, 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
Re: What are we going to do about mobile?
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.
Re: What are we going to do about mobile?
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.
Re: What are we going to do about mobile?
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
Re: What are we going to do about mobile?
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/
Re: What are we going to do about mobile?
On 1 May 2017 at 18:18, Iain Buclaw wrote: > On 1 May 2017 at 17:47, Johannes Pfau via Digitalmars-d > wrote: >> Am Mon, 1 May 2017 14:44:35 +0200 >> schrieb Iain Buclaw via Digitalmars-d : >> >>> On 1 May 2017 at 14:40, Iain Buclaw 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 :-)
Re: What are we going to do about mobile?
On 1 May 2017 at 17:47, Johannes Pfau via Digitalmars-d wrote: > Am Mon, 1 May 2017 14:44:35 +0200 > schrieb Iain Buclaw via Digitalmars-d : > >> On 1 May 2017 at 14:40, Iain Buclaw 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.
Re: What are we going to do about mobile?
Am Mon, 1 May 2017 14:44:35 +0200 schrieb Iain Buclaw via Digitalmars-d : > On 1 May 2017 at 14:40, Iain Buclaw 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
Re: What are we going to do about mobile?
On 1 May 2017 at 14:40, Iain Buclaw 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).
Re: What are we going to do about mobile?
On 16 April 2017 at 11:54, Iain Buclaw wrote: > On 16 April 2017 at 11:20, Johannes Pfau via Digitalmars-d > wrote: >> Am Sun, 16 Apr 2017 10:13:50 +0200 >> schrieb Iain Buclaw via Digitalmars-d : >> >>> >>> 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. ;-)
Re: What are we going to do about mobile? [OT]
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.
Re: What are we going to do about mobile?
On 16 April 2017 at 11:20, Johannes Pfau via Digitalmars-d 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?
Re: What are we going to do about mobile?
On 16 April 2017 at 11:20, Johannes Pfau via Digitalmars-d wrote: > Am Sun, 16 Apr 2017 10:13:50 +0200 > schrieb Iain Buclaw via Digitalmars-d : > >> >> 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/
Re: What are we going to do about mobile?
Am Sun, 16 Apr 2017 10:13:50 +0200 schrieb Iain Buclaw via Digitalmars-d : > > 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
Re: What are we going to do about mobile?
On 16 April 2017 at 09:41, Johannes Pfau via Digitalmars-d wrote: > Am Sat, 15 Apr 2017 15:11:08 + > schrieb Laeeth Isharc : >> 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
Re: What are we going to do about mobile?
Am Sat, 15 Apr 2017 09:52:49 + schrieb Johan Engelen : > I'd be happy to use the Pi3 as permanent tester, if the risks of > a hacker intruding my home network are manageable ;-) > If you want to be sure use a cheap DMZ setup. VLAN based: 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€ (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
Re: What are we going to do about mobile?
Am Sat, 15 Apr 2017 15:11:08 + schrieb Laeeth Isharc : > > 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
Re: What are we going to do about mobile?
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
Re: What are we going to do about mobile?
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
Re: What are we going to do about mobile?
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
Re: What are we going to do about mobile? [OT]
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/rionbqmtrwyenmhmm...@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.
[OT] Re: What are we going to do about mobile?
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
Re: What are we going to do about mobile?
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 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.
Re: What are we going to do about mobile?
On 13 April 2017 at 10:12, Russel Winder via Digitalmars-d 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.
Re: What are we going to do about mobile?
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. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: What are we going to do about mobile? [OT]
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/rionbqmtrwyenmhmm...@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.
Re: What are we going to do about mobile? [OT]
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.
Re: What are we going to do about mobile?
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!
Re: What are we going to do about mobile?
On Wed, 2017-04-12 at 10:43 +0100, rikki cattermole via Digitalmars-d wrote: > […] > > JNI itself isn't hard to work with, its mapping classes for D easily > to > it which is hard. Especially when inheritance comes into play. JNI is on notice for being retired, but clearly this is Java so sometime next century. The replacement won't be here for a while, but it will be here. http://openjdk.java.net/jeps/191 -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: What are we going to do about mobile?
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.
Re: What are we going to do about mobile?
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 + schrieb Joakim : D is currently built and optimized for that dying PC platform. As long as the world still needs headless machines running web sites, simulations, cloud services, ...; as long as we still need to edit office documents, run multimedia software to edit photos and video, play AAA video games the "PC master race" way; I'm confident that we have a way to go until all the notebooks, PCs and Macs disappear. :) As I've noted many times on this forum, no tech ever completely disappears: there's still somebody out there running COBOL and mainframes. But they do _effectively_ disappear, as you almost never see them. That is what is happening to the PC. When is the last time you saw someone running a UNIX workstation? Back when I was in college decades ago, that's all I used to use, except for writing papers. In my household, we had two Windows laptops and two Android smartphones four years ago; today we have two Android tablets and two Android smartphones, ie no PCs anymore. There are increasingly people worldwide using smartphones and tablets who have never and will never touch a PC! This move to add multiwindow docked functionality to smartphones makes that more prevalent. As for your examples, my first link above notes that Microsoft and Adobe have made software available to do just that on your S8. Yes, there are compute-heavy workloads that you will always need servers for, but ARM is going after that market too (https://arstechnica.com/information-technology/2017/03/microsoft-latest-open-source-servers-shown-off-with-intel-amd-and-even-arm-chips/), and because the number and capability of mobile devices is exploding, that compute-heavy share is going down. I'd say we just have /more/ fully capable computers around us nowadays. I'd probably roughly split it into - web/cloud server machines, often running VMs - scientific computation clusters - desktops (including notebooks) - smart phones - embedded devices running Linux/Android (TVs, receivers, refrigerators, photo boxes, etc...) My point is that mobile, ie smartphones and tablets, is so dominant that it is subsuming many of those other categories. I've already mentioned desktop/laptop sales going down since mobile took off, another is embedded devices that you'd have mentioned before getting subsumed into mobile, ie mp3 players, ereaders, standalone cameras, and GPS devices' sales have all been devastated. People don't buy TVs, receivers, and photo boxes as much as before because their mobile device suffices. Unfortunately, you cannot use your smartphone for refrigeration yet. ;) When targeting smart phones you have to comply to every manufacturer's frameworks and security measures. On the other hand you can directly sell
Re: What are we going to do about mobile?
Am Sun, 09 Apr 2017 12:44:15 + schrieb Nick B : > > 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
Re: What are we going to do about mobile?
On Friday, 7 April 2017 at 14:47:03 UTC, Marco Leise wrote: Am Thu, 06 Apr 2017 05:24:07 + schrieb Joakim : 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 ?
Re: What are we going to do about mobile?
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/rionbqmtrwyenmhmm...@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.
Re: What are we going to do about mobile?
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/rionbqmtrwyenmhmm...@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.
Re: What are we going to do about mobile?
On Friday, 7 April 2017 at 14:47:03 UTC, Marco Leise wrote: Am Thu, 06 Apr 2017 05:24:07 + schrieb Joakim : [...] 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 [...]
Re: What are we going to do about mobile?
Am Thu, 06 Apr 2017 05:24:07 + schrieb Joakim : > D is currently built and optimized for that dying PC platform. As long as the world still needs headless machines running web sites, simulations, cloud services, ...; as long as we still need to edit office documents, run multimedia software to edit photos and video, play AAA video games the "PC master race" way; I'm confident that we have a way to go until all the notebooks, PCs and Macs disappear. :) I'd say we just have /more/ fully capable computers around us nowadays. I'd probably roughly split it into - web/cloud server machines, often running VMs - scientific computation clusters - desktops (including notebooks) - smart phones - embedded devices running Linux/Android (TVs, receivers, refrigerators, photo boxes, etc...) When targeting smart phones you have to comply to every manufacturer's frameworks and security measures. On the other hand you can directly sell software and services. The embedded device I know best is my TV receiver, which boots into Linux and then starts a statically compiled executable that handles GUI rendering, remote control input and communication with the hardware. If you knew the protocols you could replace it with something written in Dlang. These devices are not as prominent as phones, but the barrier of entry is relatively low for many applications once you have bindings to a couple of frequently needed C libraries such as freetype, ffmpeg or opencv. > What needs to be done? Same as anything else, we need people to > try it out and pitch in, like this guy who's now trying ldc out > on an embedded device with an old ARMv5 core: > >[…] > > I realize D is never going to have a polished devkit for mobile > unless a company steps up and charges for that work. But we can > do a lot better than the complacency from the community we have > now. As you can use mostly the same compiler targets for embedded as for phones, your best bet to stabilize the ldc targets are probably the embedded developers, because they can see the immediate benefit for their projects and their knowledge about the underlying hardware can help track down bugs. -- Marco
Re: What are we going to do about mobile?
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.
Re: What are we going to do about mobile?
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
Re: What are we going to do about mobile?
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/rionbqmtrwyenmhmm...@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/cdekkumjynhqoxvmg...@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
Re: What are we going to do about mobile?
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).
Re: What are we going to do about mobile?
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?
Re: What are we going to do about mobile?
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/rionbqmtrwyenmhmm...@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/cdekkumjynhqoxvmg...@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.
Re: What are we going to do about mobile?
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
Re: What are we going to do about mobile?
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*
Re: What are we going to do about mobile?
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.
Re: What are we going to do about mobile?
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).
