www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Apple is officially moving away from Intel to a custom Arm chip

reply aberba <karabutaworld gmail.com> writes:
https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-intel-chips-11592862690

This means there's genuine interest in Arm. Note there's similar 
move by Microsoft to get their system to work on Arm chips.


PC was the only compelling target for Intel/Amd targets but now 
its changing.
Jun 24 2020
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/24/20 7:21 AM, aberba wrote:
 https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-int
l-chips-11592862690 
 
 
 This means there's genuine interest in Arm. Note there's similar move by 
 Microsoft to get their system to work on Arm chips.
 
 
 PC was the only compelling target for Intel/Amd targets but now its 
 changing.
I was wondering about this. DMD I think only supports Intel, right? Are there any plans to support ARM, or will ldc/gdc be the only compilers that support Mac in the future? I've used a mac since 2011, and I'm probably going to buy an Intel macbook this year before they are discontinued (my current one is from 2014), just to give myself more time to deal with it. I'm curious to see how this will affect the Mac ecosystem. -Steve
Jun 24 2020
next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 24 June 2020 at 12:56:26 UTC, Steven Schveighoffer 
wrote:
 On 6/24/20 7:21 AM, aberba wrote:
 https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-intel-chips-11592862690
 
 
 This means there's genuine interest in Arm. Note there's 
 similar move by Microsoft to get their system to work on Arm 
 chips.
 
 
 PC was the only compelling target for Intel/Amd targets but 
 now its changing.
I was wondering about this. DMD I think only supports Intel, right? Are there any plans to support ARM, or will ldc/gdc be the only compilers that support Mac in the future?
They're saying the transition will take two yrs. Seems they're really serious about the move to Arm. Two yrs to get DMD to work on Arm. By then, there'll be dozens of other Windows PC's doing that.
 I've used a mac since 2011, and I'm probably going to buy an 
 Intel macbook this year before they are discontinued (my 
 current one is from 2014), just to give myself more time to 
 deal with it.

 I'm curious to see how this will affect the Mac ecosystem.

 -Steve
I think others will join Apple in this move. Performance + power efficiency. Power efficiency more importantly as stated by Apple 🍎.
Jun 24 2020
parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 24 June 2020 at 14:54:16 UTC, aberba wrote:
 On Wednesday, 24 June 2020 at 12:56:26 UTC, Steven 
 Schveighoffer wrote:
 On 6/24/20 7:21 AM, aberba wrote:
 https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-intel-chips-11592862690
 
 
 This means there's genuine interest in Arm. Note there's 
 similar move by Microsoft to get their system to work on Arm 
 chips.
 
 
 PC was the only compelling target for Intel/Amd targets but 
 now its changing.
I was wondering about this. DMD I think only supports Intel, right? Are there any plans to support ARM, or will ldc/gdc be the only compilers that support Mac in the future?
There are _zero_ plans to make DMD work on ARM architectures. There are so many other actually impactful things to do ;-)
 They're saying the transition will take two yrs. Seems they're 
 really serious about the move to Arm. Two yrs to get DMD to 
 work on Arm.
To clarify and avoid confusion I see absolutely no reason anyone would waste this huge effort of time into getting DMD to work on ARM as there are two superior and working compiler backends and thus this won't be happening. So yes you'll have to move away from DMD to LDC or GDC, but that shouldn't be a concern to anyone as even today with the amazing LDC team there's absolutely no reason to use DMD either. In fact I personally believe using DMD for production is irresponsible and at the very least should be strongly discouraged as mwe can't seem to convince the DFL/Walter to drop the DMD backend for obvious reasons. Tl;Dr: it's just yet another nail in the coffin against DMD ...
Jun 24 2020
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jun 24, 2020 at 04:27:27PM +0000, Seb via Digitalmars-d wrote:
 On Wednesday, 24 June 2020 at 14:54:16 UTC, aberba wrote:
[...]
 They're saying the transition will take two yrs. Seems they're
 really serious about the move to Arm. Two yrs to get DMD to work on
 Arm.
Why even bother, when LDC/GDC already support ARM (and have been for a while now)?
 To clarify and avoid confusion I see absolutely no reason anyone would
 waste this huge effort of time into getting DMD to work on ARM as
 there are two superior and working compiler backends and thus this
 won't be happening.
Exactly.
 So yes you'll have to move away from DMD to LDC or GDC, but that
 shouldn't be a concern to anyone as even today with the amazing LDC
 team there's absolutely no reason to use DMD either. In fact I
 personally believe using DMD for production is irresponsible and at
 the very least should be strongly discouraged as mwe can't seem to
 convince the DFL/Walter to drop the DMD backend for obvious reasons.
 
 Tl;Dr: it's just yet another nail in the coffin against DMD ...
To be fair, DMD does have amazingly fast compile times, which is very useful during development -- a fast turnaround *really* helps boost productivity during the code-compile-debug cycle. I still use DMD for development of isolated modules / subsets of dependent modules because of this. However, for production code, yeah, LDC is my first choice. I'd still use DMD for non-critical code (if only due to pure laziness), like script-like programs and small utilities where program startup time dominates execution time. But for anything that's even remotely performance-sensitive, I'd reach straight for LDC and not cast another glance at DMD. T -- Obviously, some things aren't very obvious.
Jun 24 2020
prev sibling next sibling parent Meta <jared771 gmail.com> writes:
On Wednesday, 24 June 2020 at 16:27:27 UTC, Seb wrote:
 There are _zero_ plans to make DMD work on ARM architectures. 
 There are so many other actually impactful things to do ;-)

 They're saying the transition will take two yrs. Seems they're 
 really serious about the move to Arm. Two yrs to get DMD to 
 work on Arm.
To clarify and avoid confusion I see absolutely no reason anyone would waste this huge effort of time into getting DMD to work on ARM as there are two superior and working compiler backends and thus this won't be happening. So yes you'll have to move away from DMD to LDC or GDC, but that shouldn't be a concern to anyone as even today with the amazing LDC team there's absolutely no reason to use DMD either. In fact I personally believe using DMD for production is irresponsible and at the very least should be strongly discouraged as mwe can't seem to convince the DFL/Walter to drop the DMD backend for obvious reasons. Tl;Dr: it's just yet another nail in the coffin against DMD ...
I somewhat agree, but if we look at the lengths that the Rust project has gone to to optimize compile times (and people still complain often about them), we should not completely discount the advantage that dmd offers.
Jun 24 2020
prev sibling next sibling parent reply Chris <wendlec tcd.ie> writes:
On Wednesday, 24 June 2020 at 16:27:27 UTC, Seb wrote:

 To clarify and avoid confusion I see absolutely no reason 
 anyone would waste this huge effort of time into getting DMD to 
 work on ARM as there are two superior and working compiler 
 backends and thus this won't be happening.

 So yes you'll have to move away from DMD to LDC or GDC, but 
 that shouldn't be a concern to anyone as even today with the 
 amazing LDC team there's absolutely no reason to use DMD 
 either. In fact I personally believe using DMD for production 
 is irresponsible and at the very least should be strongly 
 discouraged as mwe can't seem to convince the DFL/Walter to 
 drop the DMD backend for obvious reasons.

 Tl;Dr: it's just yet another nail in the coffin against DMD ...
However, this will seriously interrupt the tool chain / development workflow I'd imagine. You'd better start working on the toolchain so that basic D development remains as simple as downloading DMD and typing "$ dmd ..." in the CLI. I don't know how dvm is now, but it used to only support dmd, and dvm is a valuable tool. Sorry lads, but it was foreseeable that neglecting ARM support for so long would come back to bite you one day.
Jun 25 2020
parent Jacob Carlborg <doob me.com> writes:
On Thursday, 25 June 2020 at 09:45:40 UTC, Chris wrote:

 I don't know how dvm is now, but it used to only support dmd, 
 and dvm is a valuable tool.
I guess now is the time to start that full rewrite and start adding support for LDC, which I've postponed waaayy too long. -- /Jacob Carlborg
Jun 25 2020
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Wednesday, 24 June 2020 at 16:27:27 UTC, Seb wrote:

 So yes you'll have to move away from DMD to LDC or GDC, but 
 that shouldn't be a concern to anyone as even today with the 
 amazing LDC team there's absolutely no reason to use DMD 
 either. In fact I personally believe using DMD for production 
 is irresponsible and at the very least should be strongly 
 discouraged as mwe can't seem to convince the DFL/Walter to 
 drop the DMD backend for obvious reasons.
Every time I've tried to move to LDC, I've ended up using DMD again. It just gets annoying using a slow compiler with my workflow, which is heavy on recompilation. Every so often LDC can be a fair amount slower than DMD. I'm rarely able to get better than a 20% improvement using LDC. Production and development are both important. Until LDC can match DMD's compilation speed, there's a very good argument in favor of having DMD around. (That doesn't mean it's worthwhile to have an ARM DMD compiler, but you're making the stronger statement that DMD doesn't provide any value in any circumstances.)
Jun 25 2020
parent aberba <karabutaworld gmail.com> writes:
On Thursday, 25 June 2020 at 10:10:43 UTC, bachmeier wrote:
 On Wednesday, 24 June 2020 at 16:27:27 UTC, Seb wrote:

 So yes you'll have to move away from DMD to LDC or GDC, but 
 that shouldn't be a concern to anyone as even today with the 
 amazing LDC team there's absolutely no reason to use DMD 
 either. In fact I personally believe using DMD for production 
 is irresponsible and at the very least should be strongly 
 discouraged as mwe can't seem to convince the DFL/Walter to 
 drop the DMD backend for obvious reasons.
Every time I've tried to move to LDC, I've ended up using DMD again. It just gets annoying using a slow compiler with my workflow, which is heavy on recompilation. Every so often LDC can be a fair amount slower than DMD. I'm rarely able to get better than a 20% improvement using LDC. Production and development are both important. Until LDC can match DMD's compilation speed, there's a very good argument in favor of having DMD around. (That doesn't mean it's worthwhile to have an ARM DMD compiler, but you're making the stronger statement that DMD doesn't provide any value in any circumstances.)
I actually don't get why he'll consider the ARM thing confusion. You might not like that its happening but as we stand now, almost every new user starts with DMD and almost everyone uses DMD for fast prototyping. It's frustrating without it. So DMD plays a key role than you may think. And it should be ready for ARM. This doesn't just affect DMD but most currently software stack and OSes need to start thinking about Arm. But eventually, say 3-5yrs from now, it can't ignore ARM and still stay the default compiler.
Jun 25 2020
prev sibling parent solidstate1991 <laszloszeremi outlook.com> writes:
On Wednesday, 24 June 2020 at 16:27:27 UTC, Seb wrote:
 There are _zero_ plans to make DMD work on ARM architectures. 
 There are so many other actually impactful things to do ;-)
I personally had, but I quickly gave up due to the massive amount of work it would have taken, alongside with having less experience with coding. Supposedly it wouldn't be too hard to modify the backend, and now that it's also in D it would be much easier. I personally don't have any will to do as such, and I would like to work on my own projects instead, like the BASIC interpreter I started to design.
Jul 01 2020
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Wednesday, 24 June 2020 at 12:56:26 UTC, Steven Schveighoffer 
wrote:
 On 6/24/20 7:21 AM, aberba wrote:
 https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-intel-chips-11592862690
 
 
 This means there's genuine interest in Arm. Note there's 
 similar move by Microsoft to get their system to work on Arm 
 chips.
 
 
 PC was the only compelling target for Intel/Amd targets but 
 now its changing.
I was wondering about this. DMD I think only supports Intel, right? Are there any plans to support ARM, or will ldc/gdc be the only compilers that support Mac in the future?
GCC still only supports powerpc, i386, or x86_64 darwin. I imagine there'll be a little nudge in the direction of getting ARM support soon, but not during the current development cycle for 11.0
Jun 24 2020
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/24/20 12:40 PM, Iain Buclaw wrote:
 On Wednesday, 24 June 2020 at 12:56:26 UTC, Steven Schveighoffer wrote:
 On 6/24/20 7:21 AM, aberba wrote:
 https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-int
l-chips-11592862690 



 This means there's genuine interest in Arm. Note there's similar move 
 by Microsoft to get their system to work on Arm chips.


 PC was the only compelling target for Intel/Amd targets but now its 
 changing.
I was wondering about this. DMD I think only supports Intel, right? Are there any plans to support ARM, or will ldc/gdc be the only compilers that support Mac in the future?
GCC still only supports powerpc, i386, or x86_64 darwin.  I imagine there'll be a little nudge in the direction of getting ARM support soon, but not during the current development cycle for 11.0
Surely you mean GDC, not GCC? -Steve
Jun 24 2020
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Wednesday, 24 June 2020 at 17:19:00 UTC, Steven Schveighoffer 
wrote:
 On 6/24/20 12:40 PM, Iain Buclaw wrote:
 On Wednesday, 24 June 2020 at 12:56:26 UTC, Steven 
 Schveighoffer wrote:
 On 6/24/20 7:21 AM, aberba wrote:
 https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-intel-chips-11592862690



 This means there's genuine interest in Arm. Note there's 
 similar move by Microsoft to get their system to work on Arm 
 chips.


 PC was the only compelling target for Intel/Amd targets but 
 now its changing.
I was wondering about this. DMD I think only supports Intel, right? Are there any plans to support ARM, or will ldc/gdc be the only compilers that support Mac in the future?
GCC still only supports powerpc, i386, or x86_64 darwin.  I imagine there'll be a little nudge in the direction of getting ARM support soon, but not during the current development cycle for 11.0
Surely you mean GDC, not GCC?
GDC only enforces that language semantics are adhered to. It's GCC (back-end) that takes care of the target support. I imagine library support in druntime should mostly be there, as LDC already has LLVM support for arm-darwin.
Jun 24 2020
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 6/24/20 4:16 PM, Iain Buclaw wrote:
 On Wednesday, 24 June 2020 at 17:19:00 UTC, Steven Schveighoffer wrote:
 On 6/24/20 12:40 PM, Iain Buclaw wrote:
 GCC still only supports powerpc, i386, or x86_64 darwin.  I imagine 
 there'll be a little nudge in the direction of getting ARM support 
 soon, but not during the current development cycle for 11.0
Surely you mean GDC, not GCC?
GDC only enforces that language semantics are adhered to.  It's GCC (back-end) that takes care of the target support.  I imagine library support in druntime should mostly be there, as LDC already has LLVM support for arm-darwin.
Sorry, I think I was confused, I thought you meant that GCC cannot target ARM, but I think now you mean ARM on darwin? -Steve
Jun 24 2020
prev sibling next sibling parent reply kinke <noone nowhere.com> writes:
On Wednesday, 24 June 2020 at 11:21:51 UTC, aberba wrote:
 Note there's similar move by Microsoft to get their system to
 work on Arm chips.
Windows ARM laptops have been around for some time, with such enormous success that many people haven't even heard or already forgotten about it. E.g., https://www.techspot.com/review/1599-windows-on-arm-performance/. Providing (software) x86 emulation (32-bit only IIRC) on an already slow CPU wasn't a great idea. Apple will probably just hope/try to enforce that the publishers port and recompile all their packages (incl. any x86-specific optimizations), so that the code is at least native. They'll probably have to put a lot of work into single-thread performance though if they want to seriously compete with x86 in the laptop/desktop segment and according TDP budget + use cases. I'm pretty sure a high number of relatively slow cores won't cut it against the likes of Zen 2 and its successors.
Jun 24 2020
next sibling parent Guillaume Piolat <first.name gmail.com> writes:
On Wednesday, 24 June 2020 at 21:24:04 UTC, kinke wrote:
 They'll probably have to put a lot of work into single-thread 
 performance though if they want to seriously compete with x86 
 in the laptop/desktop segment and according TDP budget + use 
 cases. I'm pretty sure a high number of relatively slow cores 
 won't cut it against the likes of Zen 2 and its successors.
For the D users targetting macOS: A future plan for package "intel-intrinsics" is to translate the intrinsics to Neon so that stuff is at least a bit optimized on ARM also.
Jun 24 2020
prev sibling next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Wednesday, 24 June 2020 at 21:24:04 UTC, kinke wrote:
 On Wednesday, 24 June 2020 at 11:21:51 UTC, aberba wrote:
 Note there's similar move by Microsoft to get their system to
 work on Arm chips.
Windows ARM laptops have been around for some time, with such enormous success that many people haven't even heard or already forgotten about it. E.g., https://www.techspot.com/review/1599-windows-on-arm-performance/. Providing (software) x86 emulation (32-bit only IIRC) on an already slow CPU wasn't a great idea. Apple will probably just hope/try to enforce that the publishers port and recompile all their packages (incl. any x86-specific optimizations), so that the code is at least native. They'll probably have to put a lot of work into single-thread performance though if they want to seriously compete with x86 in the laptop/desktop segment and according TDP budget + use cases. I'm pretty sure a high number of relatively slow cores won't cut it against the likes of Zen 2 and its successors.
Yet, this came out just yesterday, "Announcing OpenJDK for Windows 10 on ARM" https://devblogs.microsoft.com/java/announcing-openjdk-windows-arm/ When companies have deep pockets, things eventually happen as long as there is internal political support to keep going at it.
Jun 24 2020
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Thursday, 25 June 2020 at 05:53:18 UTC, Paulo Pinto wrote:

 When companies have deep pockets, things eventually happen as 
 long as there is internal political support to keep going at it.
+1000
Jun 25 2020
prev sibling next sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 24 June 2020 at 21:24:04 UTC, kinke wrote:
 Windows ARM laptops have been around for some time, with such 
 enormous success that many people haven't even heard or already 
 forgotten about it. E.g., 
 https://www.techspot.com/review/1599-windows-on-arm-performance/
Last I checked windows on arm was completely locked down like ios. Microsoft like Apple wants to be alone in its ecosystem.
 They'll probably have to put a lot of work into single-thread 
 performance though if they want to seriously compete with x86 
 in the laptop/desktop segment and according TDP budget + use 
 cases. I'm pretty sure a high number of relatively slow cores 
 won't cut it against the likes of Zen 2 and its successors.
The reviewer conveniently forgot to add that only Celeron can realistically fit in a notebook, anything more powerful will simply melt under your fingers, because Intel games TDP numbers to death for the sake of competition.
Jun 25 2020
prev sibling parent Kagamin <spam here.lot> writes:
On Wednesday, 24 June 2020 at 21:24:04 UTC, kinke wrote:
 https://www.techspot.com/review/1599-windows-on-arm-performance/
Also it's another nonintuitive benchmark: Celeron is twice as fast as emulation - dire result for emulation, i7 is twice as fast as Celeron - Celeron is fine.
Jun 25 2020
prev sibling next sibling parent Uknown <sireeshkodali1 gmail.com> writes:
On Wednesday, 24 June 2020 at 11:21:51 UTC, aberba wrote:
 [...]
 PC was the only compelling target for Intel/Amd targets but now 
 its changing.
This is more than just PC though. ARM chips cover virtually everything, from small SBCs like the Raspberry Pi, to high end servers like the Graviton. Also, with things like postmarketOS[1] becoming more prominent, I think D's support for ARM and other non-x86 architectures will become more and more important in the coming years. Also an interesting anecdote: Many people often think ARM cores are small and slow compared to x86, but this simply hasn't been true for a very long time in *many* use cases. Consider for e.g. compiling a large C/C++ codebase. Compiling mesa on my i5 4258u (28W part) takes more than 30minutes. I have 8GB of ram and a fast SSD too. Compare that with my phone which comes with a low end 8xA53 cores, and compiles mesa in 10 minutes! And its no longer just areas which can be heavily parallelised, like code compiling. Apple's latest cores are as fast or faster than x86 chips in a lot of tasks[2]. [1]: https://postmarketos.org/ based on Alpine linux, which just recently added official D support [2]: https://www.anandtech.com/show/14892/the-apple-iphone-11-pro-and-max-review/2
Jun 25 2020
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2020 4:21 AM, aberba wrote:
 PC was the only compelling target for Intel/Amd targets but now its changing.
Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
Jun 25 2020
next sibling parent Nils Lankila <NilsLankila gmx.us> writes:
On Friday, 26 June 2020 at 01:25:36 UTC, Walter Bright wrote:
 On 6/24/2020 4:21 AM, aberba wrote:
 PC was the only compelling target for Intel/Amd targets but 
 now its changing.
Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
⥀.⥀ yeah but at the same time this shop sells lighters in the "stop smoking aids" section: https://www.newegg.com/p/0JX-0038-000K0
Jun 25 2020
prev sibling next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Friday, 26 June 2020 at 01:25:36 UTC, Walter Bright wrote:
 On 6/24/2020 4:21 AM, aberba wrote:
 PC was the only compelling target for Intel/Amd targets but 
 now its changing.
Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
Just did. Don't get your point.
Jun 26 2020
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 26 June 2020 at 09:18:04 UTC, aberba wrote:
 On Friday, 26 June 2020 at 01:25:36 UTC, Walter Bright wrote:
 On 6/24/2020 4:21 AM, aberba wrote:
 PC was the only compelling target for Intel/Amd targets but 
 now its changing.
Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
Just did. Don't get your point.
ARM is both a threat and a _chance_ for D. Ignore it and D will finally disappear, development will become a chore or just impossible. Embrace it and it will open a new world for D. But do it properly with tooling (no complicated scripts as in "yeah it can be done somehow"). And do it now with a dedicated developer team that works only on this. Maybe use the funds you had allocated for DConf? std.fancy.allocator can wait. If you start again with "Anyone can step up and become a champion of ARM", then you're doomed and D will be history in 2-5 years. Seriously, this is not about CS theory and experimentation. This is serious, especially for all the companies that use D. There's no software without hardware. If you don't act now, this thread will be the one that announced the end of D.
Jun 26 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 26 June 2020 at 13:17:10 UTC, Chris wrote:
 But do it properly with tooling (no complicated scripts as in 
 "yeah it can be done somehow").
D just works on plenty of arm devices, including compilers in the upstream package manager (e.g. gdc on raspberry pi) or plain pre-packaged downloads that work out of the box (e.g. ldc on android). I'm a dmd die-hard on pc but it doesn't really need to be the only compiler used.
Jun 26 2020
parent reply JN <666total wp.pl> writes:
On Friday, 26 June 2020 at 13:37:19 UTC, Adam D. Ruppe wrote:
 On Friday, 26 June 2020 at 13:17:10 UTC, Chris wrote:
 But do it properly with tooling (no complicated scripts as in 
 "yeah it can be done somehow").
D just works on plenty of arm devices, including compilers in the upstream package manager (e.g. gdc on raspberry pi) or plain pre-packaged downloads that work out of the box (e.g. ldc on android). I'm a dmd die-hard on pc but it doesn't really need to be the only compiler used.
Is there a guide for how to create a binary working on Raspberry Pi from Windows? I guess LDC will work, but I don't know how to configure it to build for ARM. I needed something like that few months ago but decided to just write a Python script instead.
Jun 26 2020
next sibling parent reply Chris <wendlec tcd.ie> writes:
On Friday, 26 June 2020 at 13:48:34 UTC, JN wrote:
 On Friday, 26 June 2020 at 13:37:19 UTC, Adam D. Ruppe wrote:
 On Friday, 26 June 2020 at 13:17:10 UTC, Chris wrote:
 But do it properly with tooling (no complicated scripts as in 
 "yeah it can be done somehow").
D just works on plenty of arm devices, including compilers in the upstream package manager (e.g. gdc on raspberry pi) or plain pre-packaged downloads that work out of the box (e.g. ldc on android). I'm a dmd die-hard on pc but it doesn't really need to be the only compiler used.
Is there a guide for how to create a binary working on Raspberry Pi from Windows? I guess LDC will work, but I don't know how to configure it to build for ARM. I needed something like that few months ago but decided to just write a Python script instead.
There you go. That was exactly my point. There's a difference between "can be done" and just press enter and compile it. This is very important. You shouldn't have to think about things like that (it's 2020). If you need hot water for your tea you use an electric kettle or a cooker. You shouldn't have to go and collect fire wood, go to the well to fetch water, light the fire and so on.
Jun 26 2020
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 26 June 2020 at 14:01:58 UTC, Chris wrote:
 There you go. That was exactly my point. There's a difference 
 between "can be done" and just press enter and compile it. This 
 is very important.
Well, cross-compiling takes a few extra steps (one of which (the config file) could be eliminated and one (the lib download) could be automated). But if building on the device itself it really is "just press enter". Even this is a lot nicer than it was just one year ago btw.
Jun 26 2020
parent Mike James <foo bar.com> writes:
On Friday, 26 June 2020 at 15:04:11 UTC, Adam D. Ruppe wrote:
 On Friday, 26 June 2020 at 14:01:58 UTC, Chris wrote:
 There you go. That was exactly my point. There's a difference 
 between "can be done" and just press enter and compile it. 
 This is very important.
Well, cross-compiling takes a few extra steps (one of which (the config file) could be eliminated and one (the lib download) could be automated). But if building on the device itself it really is "just press enter". Even this is a lot nicer than it was just one year ago btw.
Or maybe we need something like this... https://wiki.lazarus.freepascal.org/fpcupdeluxe -=mike=-
Jun 26 2020
prev sibling parent John Colvin <john.loughran.colvin gmail.com> writes:
On Friday, 26 June 2020 at 14:01:58 UTC, Chris wrote:
 On Friday, 26 June 2020 at 13:48:34 UTC, JN wrote:
 On Friday, 26 June 2020 at 13:37:19 UTC, Adam D. Ruppe wrote:
 On Friday, 26 June 2020 at 13:17:10 UTC, Chris wrote:
 But do it properly with tooling (no complicated scripts as 
 in "yeah it can be done somehow").
D just works on plenty of arm devices, including compilers in the upstream package manager (e.g. gdc on raspberry pi) or plain pre-packaged downloads that work out of the box (e.g. ldc on android). I'm a dmd die-hard on pc but it doesn't really need to be the only compiler used.
Is there a guide for how to create a binary working on Raspberry Pi from Windows? I guess LDC will work, but I don't know how to configure it to build for ARM. I needed something like that few months ago but decided to just write a Python script instead.
There you go. That was exactly my point. There's a difference between "can be done" and just press enter and compile it. This is very important. You shouldn't have to think about things like that (it's 2020). If you need hot water for your tea you use an electric kettle or a cooker. You shouldn't have to go and collect fire wood, go to the well to fetch water, light the fire and so on.
ARM that you need to cross-compile to is old news (and D hasn't done a great job making that super-easy, for sure). Today/tomorrow's shift is about ARM that you develop *on*. So I'm not sure the current state of affairs (download the compiler on the target platform and it just works) is a disaster. Cross-compilation should be easier though, of course. Maybe you could help the LDC guys out there?
Jun 26 2020
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 26 June 2020 at 13:48:34 UTC, JN wrote:
 Is there a guide for how to create a binary working on 
 Raspberry Pi from Windows?
I have never actually tried it, but a process similar to how the android cross compiles work should do this as well. 1) get your Windows ldc set up 2) grab the arm-linux ldc package as well. 3) change your ldc.conf to use the libraries from the arm-linux package when targeting arm-linux 4) Compile with the argument to ldc `-mtriple arm-unknown-linux-gnueabi` or `-mtriple aarch64-unknown-linux-gnu` (32 vs 64 bit target) and you should be all set. (note you just use your normal Windows ldc, all that changes is this -mtriple argument to change the target. Or if compiling with dub, it is `dub -a platform_specifier_here`.) Step 3 is the relatively painful one, for android, i made a program to do it automatically https://github.com/adamdruppe/d_android/blob/master/android-setup.d#L232 But we should lobby the ldc upstream to just include all the configs out of the box on all systems. Maybe the libraries are a separate download, but no reason not to put the config in so it just works out of the box for cross compile too.
Jun 26 2020
next sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 26 June 2020 at 14:02:05 UTC, Adam D. Ruppe wrote:
 On Friday, 26 June 2020 at 13:48:34 UTC, JN wrote:
 Is there a guide for how to create a binary working on 
 Raspberry Pi from Windows?
I have never actually tried it, but a process similar to how the android cross compiles work should do this as well. 1) get your Windows ldc set up 2) grab the arm-linux ldc package as well. 3) change your ldc.conf to use the libraries from the arm-linux package when targeting arm-linux 4) Compile with the argument to ldc `-mtriple arm-unknown-linux-gnueabi` or `-mtriple aarch64-unknown-linux-gnu` (32 vs 64 bit target) and you should be all set. (note you just use your normal Windows ldc, all that changes is this -mtriple argument to change the target. Or if compiling with dub, it is `dub -a platform_specifier_here`.) Step 3 is the relatively painful one, for android, i made a program to do it automatically https://github.com/adamdruppe/d_android/blob/master/android-setup.d#L232 But we should lobby the ldc upstream to just include all the configs out of the box on all systems. Maybe the libraries are a separate download, but no reason not to put the config in so it just works out of the box for cross compile too.
Sounds like fun! An it's been like this for years. Well, water, firewood, stick, stones, sparks...The D community should think outside the hacker box. Also, the point that has been raised remains. DMD is a good dev tool. LDC would be fatal for your average debug-run cycles. But DMD for ARM will probably not happen, realistically seen. Apart from that it's important that ARM becomes a first-class citizen in the D world. It is important and you won't be able to put it on the long finger for ever.
Jun 26 2020
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jun 26, 2020 at 02:02:05PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
[...]
 3) change your ldc.conf to use the libraries from the arm-linux
 package when targeting arm-linux
[...]
 Step 3 is the relatively painful one, for android, i made a program to do it
 automatically
 https://github.com/adamdruppe/d_android/blob/master/android-setup.d#L232
 
 But we should lobby the ldc upstream to just include all the configs
 out of the box on all systems. Maybe the libraries are a separate
 download, but no reason not to put the config in so it just works out
 of the box for cross compile too.
+1. It would be nice to have a default config that assumes some default paths so that it will Just Work(tm) once you download the requisite optional libraries. Finding the information on what exactly to write in the config file was not an easy experience for me -- there's conflicting information online, and no clear instructions on what will work for my case. If nothing else, even a bunch of commented-out sample sections for common target platforms in the shipped config file would have helped a lot. T -- The computer is only a tool. Unfortunately, so is the user. -- Armaphine, K5
Jun 26 2020
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 26 June 2020 at 16:03:32 UTC, H. S. Teoh wrote:
 On Fri, Jun 26, 2020 at 02:02:05PM +0000, Adam D. Ruppe via 
 Digitalmars-d wrote: [...]
 [...]
[...]
 [...]
+1. It would be nice to have a default config that assumes some default paths so that it will Just Work(tm) once you download the requisite optional libraries. Finding the information on what exactly to write in the config file was not an easy experience for me -- there's conflicting information online, and no clear instructions on what will work for my case. If nothing else, even a bunch of commented-out sample sections for common target platforms in the shipped config file would have helped a lot. T
+1 also for me ... ... and if someone has a "big zip" (tm) with everything included and in the right position .. for a macOS host ... wow ...
Jun 26 2020
parent reply Jacob Carlborg <doob me.com> writes:
On 2020-06-26 18:12, Paolo Invernizzi wrote:
 On Friday, 26 June 2020 at 16:03:32 UTC, H. S. Teoh wrote:
 On Fri, Jun 26, 2020 at 02:02:05PM +0000, Adam D. Ruppe via 
 Digitalmars-d wrote: [...]
 [...]
[...]
 [...]
+1.  It would be nice to have a default config that assumes some default paths so that it will Just Work(tm) once you download the requisite optional libraries.  Finding the information on what exactly to write in the config file was not an easy experience for me -- there's conflicting information online, and no clear instructions on what will work for my case.  If nothing else, even a bunch of commented-out sample sections for common target platforms in the shipped config file would have helped a lot. T
+1 also for me ... ... and if someone has a "big zip" (tm) with everything included and in the right position .. for a macOS host ... wow ...
I've been thinking about writing such a tool for some time now. Just too much other things to do. -- /Jacob Carlborg
Jun 26 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
 On 2020-06-26 18:12, Paolo Invernizzi wrote:
[...]
 ... and if someone has a "big zip" (tm) with everything included and
 in the right position .. for a macOS host ... wow ...
[...] Y'know what would be a total killer combo? An all-in-one LDC package that contains everything you need to cross compile from any platform to any other platform. Including full linkers and/or system libraries necessary to generate fully-runnable executables (this point is important, because e.g. I can't cross-compile from Linux to MacOS without separately installing a MacOS dev environment, because LDC doesn't come with a linker for that, unlike LDC-windows). Think about it. Install a single package on any OS, and you can instantly cross-compile to all supported LDC targets just by specifying the right -m triple without needing to install/configure anything else. Build your code for all targeted platforms all in one go, without needing to fuss and muss with low-level config file tweaking and manually installing stuff. *That* would be a total killer combo for D. T -- People walk. Computers run.
Jun 26 2020
parent reply kinke <noone nowhere.com> writes:
On Friday, 26 June 2020 at 17:54:08 UTC, H. S. Teoh wrote:
 On 2020-06-26 18:12, Paolo Invernizzi wrote:
[...]
 ... and if someone has a "big zip" (tm) with everything 
 included and in the right position .. for a macOS host ... 
 wow ...
[...] Y'know what would be a total killer combo? An all-in-one LDC package that contains everything you need to cross compile from any platform to any other platform. Including full linkers and/or system libraries necessary to generate fully-runnable executables (this point is important, because e.g. I can't cross-compile from Linux to MacOS without separately installing a MacOS dev environment, because LDC doesn't come with a linker for that, unlike LDC-windows).
The linker would be the simple part; LLD isn't ready for macOS yet though, most likely because Apple prefers a totally closed ecosystem with everything under their control. But it's being worked on. Redistributing their libraries is probably much harder, I doubt they'll allow that, just like Microsoft doesn't allow that. The MinGW-based libs shipped with DMD and LDC, to provide the out-of-the-box experience for Windows targets, have been *a lot* of work from Rainer's and my side (we're talking unpaid man-weeks). Some years ago, I've posted an unfinished Dockerfile going into this direction, merging the available prebuilt LDC packages to a fat Docker image. No feedback at all IIRC. Wrt. automating the last mile (actually, the last few inches), setting up ldc2.conf, I've repeatedly stated that generalizing Adam's little Android tool would clearly be my choice. Sebastian Koppe promised to do that, but he's probably quite busy at the moment. Anyone can do that though, it's absolutely no rocket science, and if help is needed, don't hesitate to ask us LDC people. But as long as people prefer to hang out in the forum instead of getting actual stuff done in form of contributing code, nothing will improve.
Jun 26 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 26 June 2020 at 18:28:48 UTC, kinke wrote:
 Wrt. automating the last mile (actually, the last few inches), 
 setting up ldc2.conf, I've repeatedly stated that generalizing 
 Adam's little Android tool would clearly be my choice. 
 Sebastian Koppe promised to do that, but he's probably quite 
 busy at the moment.
Yeah, it shouldn't be too hard to do. Maybe I'll look at doing it myself, imagine dub run xc-setup could do a setup wizard kind of thing that does the rest. Then I think all we'd want from you is prolly just a backlink on the readme or whatever.
Jun 26 2020
parent reply kinke <noone nowhere.com> writes:
On Friday, 26 June 2020 at 19:18:44 UTC, Adam D. Ruppe wrote:
 On Friday, 26 June 2020 at 18:28:48 UTC, kinke wrote:
 Wrt. automating the last mile (actually, the last few inches), 
 setting up ldc2.conf, I've repeatedly stated that generalizing 
 Adam's little Android tool would clearly be my choice. 
 Sebastian Koppe promised to do that, but he's probably quite 
 busy at the moment.
Yeah, it shouldn't be too hard to do. Maybe I'll look at doing it myself
That'd be awesome. I have a pretty concrete idea of how this should look like, and would definitely prefer a little tool directly inside the LDC repo, analogous to ldc-build-runtime. The main reason being that it's tightly coupled to the prebuilt packages, and they are controlled by the CI scripts in the LDC repo. See https://forum.dlang.org/post/pujpcnubepoknwbircob forum.dlang.org for how I imagine this to be used.
Jun 26 2020
parent IGotD- <nise nise.com> writes:
On Friday, 26 June 2020 at 19:33:03 UTC, kinke wrote:
 That'd be awesome. I have a pretty concrete idea of how this 
 should look like, and would definitely prefer a little tool 
 directly inside the LDC repo, analogous to ldc-build-runtime. 
 The main reason being that it's tightly coupled to the prebuilt 
 packages, and they are controlled by the CI scripts in the LDC 
 repo.

 See 
 https://forum.dlang.org/post/pujpcnubepoknwbircob forum.dlang.org for how I
imagine this to be used.
That would be very useful. Keep in mind that many would like to have several targets installed at the same time so that you don't have to have a separate ldc directory for each target. As mentioned using ldc -mtriple=x-y-z will just take another target than the default one and automatically choose the right libraries and import paths. BTW, why is LDC using -mtriple when clang is using --target?
Jun 26 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/26/2020 2:18 AM, aberba wrote:
 On Friday, 26 June 2020 at 01:25:36 UTC, Walter Bright wrote:
 On 6/24/2020 4:21 AM, aberba wrote:
 PC was the only compelling target for Intel/Amd targets but now its changing.
Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
Just did. Don't get your point.
Not a single computer powered by an ARM CPU shows up. Amazon doesn't have any, either. Neither even have ARM in their CPU category.
Jun 26 2020
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 26 June 2020 at 20:43:06 UTC, Walter Bright wrote:
 Not a single computer powered by an ARM CPU shows up.
Maybe that's just a bad search term cuz there's plenty of arm devices on the market, they are just often called other things like "ipads" and "chromebooks" and other brand names instead of being generically called "computers".
Jun 26 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/26/2020 1:48 PM, Adam D. Ruppe wrote:
 On Friday, 26 June 2020 at 20:43:06 UTC, Walter Bright wrote:
 Not a single computer powered by an ARM CPU shows up.
Maybe that's just a bad search term cuz there's plenty of arm devices on the market, they are just often called other things like "ipads" and "chromebooks" and other brand names instead of being generically called "computers".
Search on "desktop computer". On the left, you'll find a CPU menu. No ARM processors in it. Neither for Amazon. I find it curious that nobody makes one.
Jun 26 2020
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 26 June 2020 at 20:58:19 UTC, Walter Bright wrote:
 Search on "desktop computer". On the left, you'll find a CPU 
 menu. No ARM processors in it. Neither for Amazon.
Yeah, ARM's primary competitive advantage over x86 is lower power consumption, which means they are biased toward the portable market. There are still various wall-outlet arm devices, especially single-board computers (SBC for short) like the raspberry pi and pine64, but they are still a different form-factor than the traditional desktop... probably just because there's no actual need for them to be larger, and while many new x86 devices don't need much space either, arm devices don't have the same traditional history to push it out of habit either. They also tend to be sold in those single board forms rather than individual components for DIYers who don't like the big brands, so instead of getting a CPU on newegg, you'd just order an all-in-one board and a case for it. Anyway, whether wall-power SBC, or one of the portable options like a laptop or phone, you can connect them to all the same accessories to give a desktop experience: keyboard, mouse, speakers, monitor, and not know the difference unless you look under the cover for a great many tasks.
Jun 26 2020
parent norm <norm.rowtree gmail.com> writes:
On Friday, 26 June 2020 at 22:46:53 UTC, Adam D. Ruppe wrote:
 On Friday, 26 June 2020 at 20:58:19 UTC, Walter Bright wrote:
 Search on "desktop computer". On the left, you'll find a CPU 
 menu. No ARM processors in it. Neither for Amazon.
Yeah, ARM's primary competitive advantage over x86 is lower power consumption, which means they are biased toward the portable market. There are still various wall-outlet arm devices, especially single-board computers (SBC for short) like the raspberry pi and pine64, but they are still a different form-factor than the traditional desktop... probably just because there's no actual need for them to be larger, and while many new x86 devices don't need much space either, arm devices don't have the same traditional history to push it out of habit either. They also tend to be sold in those single board forms rather than individual components for DIYers who don't like the big brands, so instead of getting a CPU on newegg, you'd just order an all-in-one board and a case for it. Anyway, whether wall-power SBC, or one of the portable options like a laptop or phone, you can connect them to all the same accessories to give a desktop experience: keyboard, mouse, speakers, monitor, and not know the difference unless you look under the cover for a great many tasks.
ARM is everywhere, the entire computer industry and internet hangs off devices with ARM cores. This is not true for Intel. For the last 5 yrs the entire embedded industry has moved towards ARM. Apple are just jumping on the bandwagon :-) Any device running software that was manufactured in the last 5 yrs will likely have an ARM core in there somewhere. Even in a desktop in the PSU or motherboard. More recent AMD x86 CPUs have an ARM core in the silicon. All those ARM cores are running software and that production software is currently C or C++11 (or higher). The current trend for embedded is C++14 with GCC or IAR compilers. Prior to C++11 the industry was stuck in its ways with C, but C++11 and the committee direction has really changed all that. There are teams that still insist on C only but they are becoming less and less. Rust is starting to gain a lot of traction in embedded as the alternative language for production code. Most people I talk with at trade shows and conferences like that the compiler shouts loudly a them if they do something considered unsafe by the language. When I ask about the friction Rust introduces most say they get used to it and then begin to like it because they see all the noise is actually for good reasons. Frequent I hear comments like "once the code compiles I have a lot more confidence my program is memory safe and correct". This is not true for C++, even C++20 because there are so many corners in the language rules. Sadly D isn't even on the radar, mostly because Rust marketing is so strong but also for those that do look at it there is no official ARM support. D could compete and do well in the embedded space with its feature set, low-friction like Python yet familiar C-like syntax. Norm
Jul 01 2020
prev sibling next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
I think NVIDIA Jetson series might be the only big name boards you can 
get. But they are dev kits meant for machine learning (high end boards 
are quad core, 8gb ram).
Jun 26 2020
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 26 June 2020 at 20:50:13 UTC, rikki cattermole wrote:
 I think NVIDIA Jetson series might be the only big name boards 
 you can get. But they are dev kits meant for machine learning 
 (high end boards are quad core, 8gb ram).
D code is alive and kicking inside a Jetson TX2 for quite a long time now, built by us for a really big medical customer... Next step, Nvidia Xavier NX ...
Jun 26 2020
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 27/06/2020 8:58 AM, Paolo Invernizzi wrote:
 On Friday, 26 June 2020 at 20:50:13 UTC, rikki cattermole wrote:
 I think NVIDIA Jetson series might be the only big name boards you can 
 get. But they are dev kits meant for machine learning (high end boards 
 are quad core, 8gb ram).
D code is alive and kicking inside a Jetson TX2 for quite a long time now, built by us for a really big medical customer... Next step, Nvidia Xavier NX ...
Neat! Could you do a D blog article on what you do with it? It would be a good show of application of D.
Jun 26 2020
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 26 June 2020 at 21:00:53 UTC, rikki cattermole wrote:
 On 27/06/2020 8:58 AM, Paolo Invernizzi wrote:
 On Friday, 26 June 2020 at 20:50:13 UTC, rikki cattermole 
 wrote:
 I think NVIDIA Jetson series might be the only big name 
 boards you can get. But they are dev kits meant for machine 
 learning (high end boards are quad core, 8gb ram).
D code is alive and kicking inside a Jetson TX2 for quite a long time now, built by us for a really big medical customer... Next step, Nvidia Xavier NX ...
Neat! Could you do a D blog article on what you do with it? It would be a good show of application of D.
The bad things around big medical companies is that they tend to tie your hands with a pletora of NDA agreements ... I've literally lost the count around how many I've signed! What I can tell is that it's driving a depth camera, and mixing data in realtime received by an eye-tracker device.
Jun 26 2020
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 27/06/2020 9:05 AM, Paolo Invernizzi wrote:
 The bad things around big medical companies is that they tend to tie 
 your hands with a pletora of NDA agreements ... I've literally lost the 
 count around how many I've signed!
 
 What I can tell is that it's driving a depth camera, and mixing data in 
 realtime received by an eye-tracker device.
Strip out all the medical bits and with just that, could you make a demo of D being used in it? It could be a good time to try out some new hardware to throw people off the trail ;) Tech is cool, regardless of how its being used in practice.
Jun 26 2020
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 26 June 2020 at 22:23:21 UTC, rikki cattermole wrote:
 On 27/06/2020 9:05 AM, Paolo Invernizzi wrote:
 The bad things around big medical companies is that they tend 
 to tie your hands with a pletora of NDA agreements ... I've 
 literally lost the count around how many I've signed!
 
 What I can tell is that it's driving a depth camera, and 
 mixing data in realtime received by an eye-tracker device.
Strip out all the medical bits and with just that, could you make a demo of D being used in it? It could be a good time to try out some new hardware to throw people off the trail ;) Tech is cool, regardless of how its being used in practice.
Oh, but there's really nothing special about it: D "just works". Looking at the gitlab CI script, the project started with ldc-1.13.0, so it's not really a 'new thing' ... curl, source activate, ldmd2 -I, et voilà!
Jun 26 2020
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 27/06/2020 6:53 PM, Paolo Invernizzi wrote:
 It could be a good time to try out some new hardware to throw people 
 off the trail ;)

 Tech is cool, regardless of how its being used in practice.
Oh, but there's really nothing special about it: D "just works". Looking at the gitlab CI script, the project started with ldc-1.13.0, so it's not really a 'new thing' ... curl, source activate, ldmd2 -I, et voilà!
I have never done anything like this, so to me this is really cool to see D being used like this!
Jun 27 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/26/2020 2:00 PM, rikki cattermole wrote:
 Could you do a D blog article on what you do with it?
 
 It would be a good show of application of D.
Yes, please. The D Foundation will also pay for articles accepted for publication on the blog!
Jun 27 2020
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Saturday, 27 June 2020 at 08:45:25 UTC, Walter Bright wrote:
 On 6/26/2020 2:00 PM, rikki cattermole wrote:
 Could you do a D blog article on what you do with it?
 
 It would be a good show of application of D.
Yes, please. The D Foundation will also pay for articles accepted for publication on the blog!
Thanks for the encouragement Walter, but I'm a bad and boring writer ... and short of time in this period!
Jun 29 2020
prev sibling next sibling parent Chris <wendlec tcd.ie> writes:
On Friday, 26 June 2020 at 20:43:06 UTC, Walter Bright wrote:
 On 6/26/2020 2:18 AM, aberba wrote:
 On Friday, 26 June 2020 at 01:25:36 UTC, Walter Bright wrote:
 On 6/24/2020 4:21 AM, aberba wrote:
 PC was the only compelling target for Intel/Amd targets but 
 now its changing.
Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
Just did. Don't get your point.
Not a single computer powered by an ARM CPU shows up. Amazon doesn't have any, either. Neither even have ARM in their CPU category.
Sorry, but this is a D typical way of answering to such issues. Put your blinders on and say that it's not an issue, all is good. ARM has been an issue for quite a while and it was obvious years ago that there would be more and more ARM in the future. Things are going in this direction (small devices etc.) Adam gave you a good answer. He's right. And things may change quite fast. Look at Steve, he wants to buy an "old" MacBook in order to have time to transition to ARM. It is urgent and you have to act now. I hope you don't think that if people have enough skin in the game (i.e. their livelihood), then somebody will step up and tackle it. No, this is the job of the DLF. You should be glad that the LDC crowd has done a fantastic job already. Do you understand that their work might actually save D one day? I strongly advise you to make ARM a top priority, maybe not with DMD, but with a package (LDC / GDC) that makes for a smooth development experience and is future proof - not as a community project (as people might just leave for various reasons) but as a LTS project managed directly by the DLF (like DMD).
Jun 27 2020
prev sibling parent reply Seiji Emery <seijiemery gmail.com> writes:
On Friday, 26 June 2020 at 20:43:06 UTC, Walter Bright wrote:
 On 6/26/2020 2:18 AM, aberba wrote:
 On Friday, 26 June 2020 at 01:25:36 UTC, Walter Bright wrote:
 On 6/24/2020 4:21 AM, aberba wrote:
 PC was the only compelling target for Intel/Amd targets but 
 now its changing.
Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
Just did. Don't get your point.
Not a single computer powered by an ARM CPU shows up. Amazon doesn't have any, either. Neither even have ARM in their CPU category.
apple is / will be shipping $500 dev kits w/ an A10z; might be seriously worth looking into if anyone wanted to try doing compiler and/or toolchain work on arm https://developer.apple.com/programs/universal/
Jun 30 2020
parent reply Seiji Emery <seijiemery gmail.com> writes:
addendum:

yes, this means you'd be stuck w/ an apple dev kit (and need to 
be a registered apple developer so the full cost of getting this 
is ~$600)

but this is probably your best bet, by far, for getting a full, 
working developer environment on an arm chipset atm, outside of 
running an old surface tablet w/ windows RT, or running a linux 
distro off a phone, or something.

Apple's implementation of this is running full mac os, with 
probably one of the fastest arm chipsets out atm

And it can run x86_64 code using an emulation layer (which I'm 
guessing is mostly just binary recompilation to arm, or 
something), which... obviously neither of the other two options 
can do afaik

Geekbench, supposedly, is running on it (and w/ the x64 version), 
and it benchmarks pretty darn close to a 4-5 year old i5 / i7 
laptop (source: have a 5 year old laptop w/ an i7 4980hq, and the 
dev kit's benchmarks are shockingly close to that)

it'd be pretty interesting to see if dmd can run on this out of 
the box, and what problems (if any) there might be with that. 
(intrinsics? threading? runtime code modification??)

For porting bits of dmd and/or druntime and/or toolchain stuff to 
arm, I'm not sure you could do better than working on a pretty 
powerful arm chip that can run both arm *and* x86_64 code

You'd be stuck w/ macos ofc, but I'm pretty sure you could do 
quite a bit worse on that front in terms of having a real, 
working desktop development environment, that can run real dev 
tools and w/ performance that will probably not suck. no visual 
studio, but eh, vscode should work (hopefully), and there's 
intellij stuff. and there's xcode, which... if nothing else has 
pretty good debugging and profiling tools, and can be run on d 
binaries if you're sufficiently motivated and/or desperate
Jun 30 2020
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 1 July 2020 at 03:10:41 UTC, Seiji Emery wrote:
 addendum:

 yes, this means you'd be stuck w/ an apple dev kit (and need to 
 be a registered apple developer so the full cost of getting 
 this is ~$600)

 but this is probably your best bet, by far, for getting a full, 
 working developer environment on an arm chipset atm, outside of 
 running an old surface tablet w/ windows RT, or running a linux 
 distro off a phone, or something.
Nvidia is selling pretty popular solutions based on ARM and Nvidia GPU, all linux powered. You really don't need to rely on a Phone or (ugh) old surface tablets ...
 it'd be pretty interesting to see if dmd can run on this out of 
 the box, and what problems (if any) there might be with that. 
 (intrinsics? threading? runtime code modification??)
 For porting bits of dmd and/or druntime and/or toolchain stuff 
 to arm, I'm not sure you could do better than working on a 
 pretty powerful arm chip that can run both arm *and* x86_64 code
Again, LDC runs out of the box on ARM since a long time now ... just check on the release page for the available tarred distributions
 You'd be stuck w/ macos ofc, but I'm pretty sure you could do 
 quite a bit worse on that front in terms of having a real, 
 working desktop development environment, that can run real dev 
 tools and w/ performance that will probably not suck. no visual 
 studio, but eh, vscode should work (hopefully), and there's 
 intellij stuff. and there's xcode, which... if nothing else has 
 pretty good debugging and profiling tools, and can be run on d 
 binaries if you're sufficiently motivated and/or desperate
A 35$ Raspberry PI supports 2x 4K display, and comes with a Debian based linux complete with GUI. You can attach a keyboard, mouse and have a little ARM machine to toy with (but no precompiled LDC, its 32bit ...) There are plenty of solutions, without having to rely on Apple! (Disclaimer, message written on my 2019 iMac, eheh) /P
Jul 01 2020
next sibling parent reply Yatheendra <indra yath.io> writes:
Hardware: if IO speeds matter, ASUS has Tinkerboards with 
dual-channel RAM - I think those are rare in ARM land.

Form factor: realizing the market for SBC's, there are amd64 
SBC's now like the lattepanda (soldered RAM, like most SBC's).

dmd: does its backend play a big role in compilation speed? Would 
maintaining a fork of a backend from somewhere else (SBCL?) 
provide wider platform support without harming dmd performance? 
RISC-V is behind ARM on the horizon.

ARM may be urgent, if say, the Pinebook, takes off among 
developers.
Jul 01 2020
next sibling parent Yatheendra <indra yath.io> writes:
On Wednesday, 1 July 2020 at 13:39:57 UTC, Yatheendra wrote:
 Hardware: if IO speeds matter, ASUS has Tinkerboards with 
 dual-channel RAM - I think those are rare in ARM land.

 Form factor: realizing the market for SBC's, there are amd64 
 SBC's now like the lattepanda (soldered RAM, like most SBC's).

 dmd: does its backend play a big role in compilation speed? 
 Would maintaining a fork of a backend from somewhere else 
 (SBCL?) provide wider platform support without harming dmd 
 performance? RISC-V is behind ARM on the horizon.

 ARM may be urgent, if say, the Pinebook, takes off among 
 developers.
Also, if developing for the host processor on FPGA's could be of enough interest, most FPGA's only have ARM (or Synopsys ARC, or MIPS) host processors - even the Intel-owned Altera FPGA's, I guess.
Jul 01 2020
prev sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 02/07/2020 1:39 AM, Yatheendra wrote:
 ARM may be urgent, if say, the Pinebook, takes off among developers.
ldc and gdc are a thing. We are ok.
Jul 01 2020
parent reply bachmeier <no spam.net> writes:
On Wednesday, 1 July 2020 at 14:11:18 UTC, rikki cattermole wrote:
 On 02/07/2020 1:39 AM, Yatheendra wrote:
 ARM may be urgent, if say, the Pinebook, takes off among 
 developers.
ldc and gdc are a thing. We are ok.
One might not think so if reading this forum. There are enough real problems to worry about without adding pretend ones on top.
Jul 01 2020
parent reply Yatheendra <indra yath.io> writes:
On Wednesday, 1 July 2020 at 14:27:21 UTC, bachmeier wrote:
 On Wednesday, 1 July 2020 at 14:11:18 UTC, rikki cattermole 
 wrote:
 On 02/07/2020 1:39 AM, Yatheendra wrote:
 ARM may be urgent, if say, the Pinebook, takes off among 
 developers.
ldc and gdc are a thing. We are ok.
One might not think so if reading this forum. There are enough real problems to worry about without adding pretend ones on top.
If dmd and its scripting-like development cycle speed stops being the primary entry point for newbies, it is a "pretend one". Until then, it doesn't seem to be a dismissible problem. Again, until a Pinebook or an ARM Macbook/Mini becomes a developer preference, there is no urgency for the "dmd experience on ARM".
Jul 01 2020
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/1/20 12:27 PM, Yatheendra wrote:
 On Wednesday, 1 July 2020 at 14:27:21 UTC, bachmeier wrote:
 On Wednesday, 1 July 2020 at 14:11:18 UTC, rikki cattermole wrote:
 On 02/07/2020 1:39 AM, Yatheendra wrote:
 ARM may be urgent, if say, the Pinebook, takes off among developers.
ldc and gdc are a thing. We are ok.
One might not think so if reading this forum. There are enough real problems to worry about without adding pretend ones on top.
If dmd and its scripting-like development cycle speed stops being the primary entry point for newbies, it is a "pretend one". Until then, it doesn't seem to be a dismissible problem. Again, until a Pinebook or an ARM Macbook/Mini becomes a developer preference, there is no urgency for the "dmd experience on ARM".
It may not be a dismissable problem, but it's also not someone anyone but Walter can fix. So the question from a community standpoint is (allowing that we have really no control over this), is it worth having Walter create an entirely new backend instead of doing other work? I'd say no. Unless someone else knows how to make this happen? Another approach may be to figure out a way to make a non-optimized build with ldc run as fast as or close to dmd. -Steve
Jul 01 2020
next sibling parent reply IGotD- <nise nise.com> writes:
On Wednesday, 1 July 2020 at 17:00:27 UTC, Steven Schveighoffer 
wrote:
 It may not be a dismissable problem, but it's also not someone 
 anyone but Walter can fix. So the question from a community 
 standpoint is (allowing that we have really no control over 
 this), is it worth having Walter create an entirely new backend 
 instead of doing other work? I'd say no.
It's inevitable that backends using LLVM or GCC will take over. Already today the DMD backend falls short when it comes to code generation compared to LDC and GDC. DMD has its benefits but as LDC and GDC progresses those benefits become less and it will not be worth using DMD at all. Walter may work all he wants on the DMD backend but the question is how well spent time that is as not many people will use it. If I would be Walter I would retire the DMD code generator and completely migrate to LLVM and GCC. This is a project with limited resources and that's one way to streamline the project. About all new language projects use an external backends like GCC or LLVM. Mention one project that has its own in the last 10 years. Now this was not the case during 90s where D was being formed. LDC is my default compiler and it was that from the very beginning. I just tried out DMD a bit but never ever used for something serious.
Jul 01 2020
parent Yatheendra <indra yath.io> writes:
Yes, ideally a compiler shouldn't need to worry about a backend 
nowadays. Yet, SBCL and OCaml have comfortably maintained their 
own non-GCC non-LLVM backends. They are fairly imperative 
languages, so the choice of dmd backend may hypothetically be 
among 4, not 2. If it comes to evolving dmd backend, maybe it 
should shift, but maintaining script-like development seems 
useful. It doesn't help that ARM is a fragmented land, compiling 
dmd from source may be commonly required and I haven't had 
success compiling gdc on amd64 with less than 4GB of RAM. It 
sounds bad to need a separate big machine just for compilation, 
when ARM isn't an embedded targer.
Jul 01 2020
prev sibling next sibling parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 1 July 2020 at 17:00:27 UTC, Steven Schveighoffer 
wrote:
 On 7/1/20 12:27 PM, Yatheendra wrote:
 On Wednesday, 1 July 2020 at 14:27:21 UTC, bachmeier wrote:
 Another approach may be to figure out a way to make a 
 non-optimized build with ldc run as fast as or close to dmd.
Can this be done. Is so, then there wouldn't be much need for DMD to still remain the default. You know DMD has the best get-go developer experience. All you need is a simple .deb Back when I was using even Windows XP (early D2), DMD had the best get-go experience that got me stuck with it. Just like python in Windows. Can't say that about LDC.
Jul 01 2020
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 02/07/2020 1:45 PM, aberba wrote:
 On Wednesday, 1 July 2020 at 17:00:27 UTC, Steven Schveighoffer wrote:
 On 7/1/20 12:27 PM, Yatheendra wrote:
 On Wednesday, 1 July 2020 at 14:27:21 UTC, bachmeier wrote:
 Another approach may be to figure out a way to make a non-optimized 
 build with ldc run as fast as or close to dmd.
Can this be done. Is so, then there wouldn't be much need for DMD to still remain the default. You know DMD has the best get-go developer experience. All you need is a simple .deb Back when I was using even Windows XP (early D2), DMD had the best get-go experience that got me stuck with it. Just like python in Windows. Can't say that about LDC.
On Windows LDC and DMD should have the same out of the box experience thanks to LLD today. LDC is packaged in linux repositories like debian. https://packages.debian.org/buster/ldc Not the latest, but it is simpler than dmd as no looking for a deb file. $ apt install ldc ;)
Jul 01 2020
parent aberba <karabutaworld gmail.com> writes:
On Thursday, 2 July 2020 at 01:56:34 UTC, rikki cattermole wrote:
 On 02/07/2020 1:45 PM, aberba wrote:
 On Wednesday, 1 July 2020 at 17:00:27 UTC, Steven 
 Schveighoffer wrote:
 On 7/1/20 12:27 PM, Yatheendra wrote:
 On Wednesday, 1 July 2020 at 14:27:21 UTC, bachmeier wrote:
 Another approach may be to figure out a way to make a 
 non-optimized build with ldc run as fast as or close to dmd.
Can this be done. Is so, then there wouldn't be much need for DMD to still remain the default. You know DMD has the best get-go developer experience. All you need is a simple .deb Back when I was using even Windows XP (early D2), DMD had the best get-go experience that got me stuck with it. Just like python in Windows. Can't say that about LDC.
On Windows LDC and DMD should have the same out of the box experience thanks to LLD today. LDC is packaged in linux repositories like debian. https://packages.debian.org/buster/ldc Not the latest, but it is simpler than dmd as no looking for a deb file. $ apt install ldc ;)
For your information, using a deb is actually more simple. It all depends on how you're conditioned. Also where you're coming from. There's a reason why dmd installer downloads keep ticking.
Jul 02 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/1/2020 10:00 AM, Steven Schveighoffer wrote:
 It may not be a dismissable problem, but it's also not someone anyone but
Walter 
 can fix. So the question from a community standpoint is (allowing that we have 
 really no control over this), is it worth having Walter create an entirely new 
 backend instead of doing other work? I'd say no.
I'm pretty sure that 3/4 of the backend can be used pretty much as-is. The optimizer, for example, is independent. The 16 bit stuff can be omitted, so can the floating point emulator and x87 code. The rest of the structure can be kept, just replacing the tinsel on the christmas tree. The exception handling support, symbolic debug support, and object file support should be the same.
Jul 02 2020
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 7/2/20 6:31 AM, Walter Bright wrote:
 On 7/1/2020 10:00 AM, Steven Schveighoffer wrote:
 It may not be a dismissable problem, but it's also not someone anyone 
 but Walter can fix. So the question from a community standpoint is 
 (allowing that we have really no control over this), is it worth 
 having Walter create an entirely new backend instead of doing other 
 work? I'd say no.
I'm pretty sure that 3/4 of the backend can be used pretty much as-is. The optimizer, for example, is independent. The 16 bit stuff can be omitted, so can the floating point emulator and x87 code. The rest of the structure can be kept, just replacing the tinsel on the christmas tree. The exception handling support, symbolic debug support, and object file support should be the same.
Well, as I said, it's you who probably has to do it, so if you want to do it, then I would love to keep using DMD on my (future) macbook ;) -Steve
Jul 02 2020
prev sibling parent bachmeier <no spam.net> writes:
On Wednesday, 1 July 2020 at 16:27:27 UTC, Yatheendra wrote:

 If dmd and its scripting-like development cycle speed stops 
 being the primary entry point for newbies, it is a "pretend 
 one". Until then, it doesn't seem to be a dismissible problem. 
 Again, until a Pinebook or an ARM Macbook/Mini becomes a 
 developer preference, there is no urgency for the "dmd 
 experience on ARM".
DMD brings a lot of value with its fast compilation speed. I don't see D losing all of its value without fast compilation, though, and I don't see ARM taking over the developer world any time soon. There's no reason you can't compile on a "normal" computer in the early stages and then move over to ARM for the final stages using LDC. I have trouble believing there will be a lot of exclusively ARM development going on anytime soon. Just today there was a story posted where Linus said "Over the last 10 years or so I've been complaining about the fact that it's really hard to find Arm hardware that is usable for a developer," Torvalds responded. Everything about this being the end of the D programming language is speculative if the Linux kernel doesn't even support ARM as a first class citizen. https://www.theregister.com/2020/06/30/hard_to_find_linux_maintainers_says_torvalds/
Jul 01 2020
prev sibling next sibling parent reply Martin Tschierschke <mt smartdolphin.de> writes:
On Wednesday, 1 July 2020 at 08:22:25 UTC, Paolo Invernizzi wrote:

 A 35$ Raspberry PI supports 2x 4K display, and comes with a 
 Debian based linux complete with GUI. You can attach a 
 keyboard, mouse and have a little ARM machine to toy with (but 
 no precompiled LDC, its 32bit ...)
What do you mean by "no precompiled LDC?" Just `sudo apt install ldc` and you go.... ldc2 --version LDC - the LLVM D compiler (1.12.0): based on DMD v2.082.1 and LLVM 6.0.1 built with LDC - the LLVM D compiler (1.12.0) Default target: armv6-unknown-linux-gnueabihf Host CPU: cortex-a72 http://dlang.org - http://wiki.dlang.org/LDC
Jul 01 2020
next sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Wednesday, 1 July 2020 at 15:48:59 UTC, Martin Tschierschke 
wrote:
 On Wednesday, 1 July 2020 at 08:22:25 UTC, Paolo Invernizzi 
 wrote:

 A 35$ Raspberry PI supports 2x 4K display, and comes with a 
 Debian based linux complete with GUI. You can attach a 
 keyboard, mouse and have a little ARM machine to toy with (but 
 no precompiled LDC, its 32bit ...)
What do you mean by "no precompiled LDC?" Just `sudo apt install ldc` and you go.... ldc2 --version LDC - the LLVM D compiler (1.12.0): based on DMD v2.082.1 and LLVM 6.0.1 built with LDC - the LLVM D compiler (1.12.0) Default target: armv6-unknown-linux-gnueabihf Host CPU: cortex-a72 http://dlang.org - http://wiki.dlang.org/LDC
Cool, (a little outdated) but cool! Usually we use the tar from the release page of the LDC GitHub page, but good to know LDC it's available also on that platform! Thank you Martin for the info!
Jul 01 2020
parent aberba <karabutaworld gmail.com> writes:
On Wednesday, 1 July 2020 at 15:55:34 UTC, Paolo Invernizzi wrote:
 On Wednesday, 1 July 2020 at 15:48:59 UTC, Martin Tschierschke 
 wrote:
 On Wednesday, 1 July 2020 at 08:22:25 UTC, Paolo Invernizzi 
 wrote:

 A 35$ Raspberry PI supports 2x 4K display, and comes with a 
 Debian based linux complete with GUI. You can attach a 
 keyboard, mouse and have a little ARM machine to toy with 
 (but no precompiled LDC, its 32bit ...)
What do you mean by "no precompiled LDC?" Just `sudo apt install ldc` and you go.... ldc2 --version LDC - the LLVM D compiler (1.12.0): based on DMD v2.082.1 and LLVM 6.0.1 built with LDC - the LLVM D compiler (1.12.0) Default target: armv6-unknown-linux-gnueabihf Host CPU: cortex-a72 http://dlang.org - http://wiki.dlang.org/LDC
Cool, (a little outdated) but cool! Usually we use the tar from the release page of the LDC GitHub page, but good to know LDC it's available also on that platform! Thank you Martin for the info!
There's not enough awareness of some of these things. If you don't get why DMD is so important in this ARM talk is unless you're a seasoned D developer of LLVM guy, you'll most likely start with DMD. Cus it's the default compiler and it's quite easy to use with a simple .deb file download.
Jul 01 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/1/2020 8:48 AM, Martin Tschierschke wrote:
 On Wednesday, 1 July 2020 at 08:22:25 UTC, Paolo Invernizzi wrote:
 
 A 35$ Raspberry PI supports 2x 4K display, and comes with a Debian based linux 
 complete with GUI. You can attach a keyboard, mouse and have a little ARM 
 machine to toy with (but no precompiled LDC, its 32bit ...)
What do you mean by "no precompiled LDC?" Just `sudo apt install ldc` and you go.... ldc2 --version LDC - the LLVM D compiler (1.12.0):   based on DMD v2.082.1 and LLVM 6.0.1   built with LDC - the LLVM D compiler (1.12.0)   Default target: armv6-unknown-linux-gnueabihf   Host CPU: cortex-a72   http://dlang.org - http://wiki.dlang.org/LDC
Clearly, someone needs to write a D blog article explaining how to get a simple D program compiled and running on the Raspberry Pi. Note that the D Foundation pays for articles that are published on the D Blog. What are you waiting for? :-)
Jul 02 2020
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 2 July 2020 at 20:42:25 UTC, Walter Bright wrote:
 Clearly, someone needs to write a D blog article explaining how 
 to get a simple D program compiled and running on the Raspberry 
 Pi.
apt install gdc gdc program.d where's my cash? :P It really is that simple, with the one caveat that the gdc in the package manager is a bit old, so not all libraries will just work. Getting gdc into gcc is a real victory - it is this simple on various Linux systems now. I recently did a gpio module too and made a little D program to do audio and trigger leds on a raspberry pi http://dpldocs.info/this-week-in-d/Blog.Posted_2020_05_11.html#gpio.d
Jul 02 2020
next sibling parent reply JN <666total wp.pl> writes:
On Thursday, 2 July 2020 at 20:46:52 UTC, Adam D. Ruppe wrote:
 On Thursday, 2 July 2020 at 20:42:25 UTC, Walter Bright wrote:
 Clearly, someone needs to write a D blog article explaining 
 how to get a simple D program compiled and running on the 
 Raspberry Pi.
apt install gdc gdc program.d where's my cash? :P
How about on Windows? I guess that might be tricky.
Jul 02 2020
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 2 July 2020 at 21:40:24 UTC, JN wrote:
 How about on Windows? I guess that might be tricky.
So that is developing for the pi on the pi itself. Cross compiling is easiest on ldc: you get ldc for your host system, grab ldc for the target, then merge the library directories and configuration files. It still isn't hard, but it is a bit more work. I'm gonna be working with the ldc people some time later this month to make it very simple too (I did it for android already, just gonna generalize that to other targets as well), so you just do like "ldc setup" and check off the targets you want and then it sets it all up for you.
Jul 02 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/2/2020 1:46 PM, Adam D. Ruppe wrote:
 On Thursday, 2 July 2020 at 20:42:25 UTC, Walter Bright wrote:
 Clearly, someone needs to write a D blog article explaining how to get a 
 simple D program compiled and running on the Raspberry Pi.
apt install gdc gdc program.d where's my cash? :P It really is that simple, with the one caveat that the gdc in the package manager is a bit old, so not all libraries will just work. Getting gdc into gcc is a real victory - it is this simple on various Linux systems now. I recently did a gpio module too and made a little D program to do audio and trigger leds on a raspberry pi http://dpldocs.info/this-week-in-d/Blog.Posted_2020_05_11.html#gpio.d
Posting in the n.g. only reaches people already using D. The point of the D Blog is outreach.
Jul 02 2020
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/2/2020 1:42 PM, Walter Bright wrote:
 Clearly, someone needs to write a D blog article explaining how to get a
simple 
 D program compiled and running on the Raspberry Pi. Note that the D Foundation 
 pays for articles that are published on the D Blog.
 
 What are you waiting for? :-)
If that's not incentive enough, consider that I know programmers with in excess of $1m in annual compensation. What do they have in common? They write blogs and articles about what they do. It's great marketing for yourself. You might be every bit good a programmer as they are, but nobody knows that because you don't write any articles, do any presentations at conferences, etc. When nobody knows you're good, you aren't going to be highly compensated. BTW, something I'm very proud about, many people who presented at DConf have gotten very well paying jobs as a direct result.
Jul 02 2020
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Thursday, 2 July 2020 at 20:42:25 UTC, Walter Bright wrote:
 On 7/1/2020 8:48 AM, Martin Tschierschke wrote:
 Clearly, someone needs to write a D blog article explaining how 
 to get a simple D program compiled and running on the Raspberry 
 Pi. Note that the D Foundation pays for articles that are 
 published on the D Blog.

 What are you waiting for? :-)
Its very tricky when dealing with the D folks. 😂 Sometimes its hard to know if it'll be any interesting. But yeah, I've got stuff in the pipeline to do something about it...not just on the D blog.
Jul 02 2020
prev sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
On Thursday, 2 July 2020 at 20:42:25 UTC, Walter Bright wrote:
 On 7/1/2020 8:48 AM, Martin Tschierschke wrote:
 On Wednesday, 1 July 2020 at 08:22:25 UTC, Paolo Invernizzi 
 wrote:
 
 A 35$ Raspberry PI supports 2x 4K display, and comes with a 
 Debian based linux complete with GUI. You can attach a 
 keyboard, mouse and have a little ARM machine to toy with 
 (but no precompiled LDC, its 32bit ...)
What do you mean by "no precompiled LDC?" Just `sudo apt install ldc` and you go.... ldc2 --version LDC - the LLVM D compiler (1.12.0):   based on DMD v2.082.1 and LLVM 6.0.1   built with LDC - the LLVM D compiler (1.12.0)   Default target: armv6-unknown-linux-gnueabihf   Host CPU: cortex-a72   http://dlang.org - http://wiki.dlang.org/LDC
Clearly, someone needs to write a D blog article explaining how to get a simple D program compiled and running on the Raspberry Pi. Note that the D Foundation pays for articles that are published on the D Blog. What are you waiting for? :-)
Beside having two raspberry pi (3B+ and 4) one at home and one at work under my control, I just tried if LDC is available - and compiled a "Hello World". There seams to be a repository to control the GPIO-pins for doing some maker stuff, (https://github.com/fgheorghe/D-Lang-Raspbian-GPIO-Module) I only use the Pis as MediaCenter and backup target (just cron + rsync). But there are several posts about D on Raspberry pi in the forum, so someone might bring up interesting use cases. (Vibe.d webserver) The very low power consumption compared to desktops make the pi a cheap always-run solution. The latest PI generation (4) is available with up to 8 GB Ram and a new 64 bit OS is available as beta software. The PI Foundation just renamed Raspbian to Raspberry Pi OS. (Which still, as I understand, is based on the Debian Linux distribution ) With 4 or 8GB memory, it can replace a desktop pc for most simple office use cases. The latest version has USB 3.0, so access to bigger storage is much faster than with the older generations (3,2 and 1).
Jul 03 2020
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2020-07-01 10:22, Paolo Invernizzi wrote:

 There are plenty of solutions, without having to rely on Apple!
If we're talking specifically about supporting the new Apple Silicon (as they call their ARM chip) any old ARM won't do. Apple uses a slightly different ABI then regular ARM. It might get you close, but not all the way. Alternatively, one can work with an iPhone or an iPad. iPhone and iPad apps run unmodified on Macs with Apple Silicon. It happens so, that this dev kit is running exactly the same CPU as the latest iPad Pro. Also, one probably need to be able to cross-compile, which DMD doesn't support. Or using an old version from when DMD was written in C++ to bootstrap. -- /Jacob Carlborg
Jul 01 2020
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2020-07-01 05:10, Seiji Emery wrote:
 addendum:
 
 yes, this means you'd be stuck w/ an apple dev kit (and need to be a 
 registered apple developer so the full cost of getting this is ~$600)
No you won't. You need to return it. -- /Jacob Carlborg
Jul 01 2020
prev sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
On Friday, 26 June 2020 at 01:25:36 UTC, Walter Bright wrote:
 On 6/24/2020 4:21 AM, aberba wrote:
 PC was the only compelling target for Intel/Amd targets but 
 now its changing.
Search for "arm computer" on newegg.com: https://www.newegg.com/p/pl?d=arm+computer :-)
:-) But there is more with ARM: ARM-based Japanese supercomputer is now the fastest in the world https://www.theverge.com/2020/6/23/21300097/fugaku-supercomputer-worlds-fastest-top500-riken-fujitsu-arm Question: How complicated would it be to replace the compilation result of DMD (X86 code) with the code an X86 emulator on ARM would use. By this "trick" you might get the fast DMD compilation times for development and use LDC for production? Best regards mt.
Jun 26 2020
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/24/2020 4:21 AM, aberba wrote:
 This means there's genuine interest in Arm. Note there's similar move by 
 Microsoft to get their system to work on Arm chips.
 
 
 PC was the only compelling target for Intel/Amd targets but now its changing.
There goes my weekend.
Jun 25 2020
prev sibling parent reply solidstate1991 <laszloszeremi outlook.com> writes:
On Wednesday, 24 June 2020 at 11:21:51 UTC, aberba wrote:
 https://www.google.com/amp/s/www.wsj.com/amp/articles/apples-new-macs-how-theyll-work-after-ditching-intel-chips-11592862690

 This means there's genuine interest in Arm. Note there's 
 similar move by Microsoft to get their system to work on Arm 
 chips.


 PC was the only compelling target for Intel/Amd targets but now 
 its changing.
I'm quite skeptical about how big of an impact it'll have. Apple's main customers are rich business people wanting to do regular office-work on a luxury machine. Machined aluminium is the new beige. Yes, other people still use them, but seeing how long Apple have neglected it's professional users, I wouldn't be surprised if they either ditched them completely, or just force them into their restrictive ecosystem. There's a lot of productivity apps ported to ARM processors already, but some people will suffer as a consequence of Apple's move. Even if Apple will fail massively with their ARM chips, we still need to get into ARM more than currently. I personally would have gotten a Raspberry Pi, unfortunately my country has a quite infamous used market, where people are trying to sell outdated hardware barely below their original price. Money is still a concern for me, although I have a few plans to remedy it.
Jul 01 2020
parent Guillaume Piolat <first.name gmail.com> writes:
On Thursday, 2 July 2020 at 00:12:03 UTC, solidstate1991 wrote:
 Money is still a concern for me, although I have a few plans to 
 remedy it.
Hello, I don't know your current status and plans, but we have a Bug Bounty program in Dplug that a D freelancer could use: https://github.com/AuburnSounds/Dplug/wiki/Bug-Bounty-Program Those are are well defined and known tasks with hopefully reduced scopes. enter the conversation)
Jul 02 2020