Re: Mobile is the new PC and AArch64 is the new x64
On 9/10/2018 9:43 AM, Joakim wrote: > Yes, I know, these devices won't replace your quad-core Xeon workstation > with 32-64 GBs of RAM anytime soon, but most people don't need anywhere > near that level of compute. That's why PC sales keep dropping while > mobile sales are now 6-7X that per year: I'm all for supporting modern open CPU architectures. At the same time, I fear that the specific trend you're describing here (people ditching PCs for cellphones/tablets) is effectively a reversal of the PC revolution. For the last 30+ years people benefited from "trickle down computing". They had access to PCs that were equivalent to cutting edge servers of 6-7 years prior. They had ability to choose their operating system, expand and upgrade their hardware and install any software they wanted. All of this is breaking down right now. Intel got lazy without competition and high-end CPU architectures stagnated. All the cutting-edge computing is done on NVidia cards today. It requires hundreds of gigabytes of RAM, tens of terabytes of data and usage of specialized computing libraries. I very much doubt this will "trickle down" to mobile in foreseeable future. Heck, most developer laptops today have no CUDA capabilities to speak of. Moreover, mobile devices are locked down by default and it's no trivial task to break out of those walled gardens. IIRC, Apple has an official policy of not allowing programming tools in their app store. Alan Kay had to personally petition Steve Jobs to allow Scratch to be distributed, so kids could learn programming. I believe the general policy is still in place. Android is better, but it's still a horror to do real work on, compared to any PC OS. Fine, you rooted it, installed some compilers and so on. How will you share your software with fellow Android users? In essence, we are seeing the rapid widening of two digital divides. The first one is between users and average developers. The second one is between average developers and researchers at companies like Google. I very much doubt that we will see an equivalent of today's high-end machine learning server on user's desk, let alone in anyone's pocket, within 7 years. My only hope is that newer AMD processors and popularity of VR rigs may help narrow these divides.
Re: extern(C++, ns) is wrong
On Tuesday, September 11, 2018 9:59:30 PM MDT Danni Coy via Digitalmars-d
wrote:
> So my understanding is that the main issue with extern(C++,"ns") is
> functions that have different C++ name-spaces overriding each other in
> unexpected ways.
> How feasible is to simply disallow functions/variables/objects/... with
> the same name but a different "ns" being in the same module?
If we had extern(C++, "NS"), then all it would affect would be mangling and
all of the normal rules for conflicting symbols would be in force. So, if
you tried to put two symbols with the same name but from different
namespaces in the same module, you'd get an error just like if they were D
functions that conflicted. Disallowing it wouldn't be the problem. The
problem would be if you were trying to match the C++ header file and thus
have the two namespaces in the same file without a conflict, and that
wouldn't work unless you could do something like put the symbol inside a
struct or template to effectively namespace it - or if the current
extern(C++, NS) mechanism were left in place in addition to adding
extern(C++, "NS").
But for the most part, this is a non-issue, because the sane thing to do
would be to just put different namespaces in different modules even if they
were in the same header file in C++ - maybe pkg.headerfile.namespace instead
of pkg.headerfile like you might do if everything in the header file were in
the same namespace. It might be more of a problem with something that
generated the bindings automatically, but mostly, the issue seems to be that
Walter wants to be able to completely follow the C++ header scheme when you
create the bindings, whereas most of the rest of us don't really care about
being that exact about it if the header file did something like have
multiple namespaces with symbols that would conflict if they were in the
same namespace. Since the current scheme effectively creates namespaces
inside of the module instead of just affecting the name mangling, you can
stick as many namespaces in the module as you want without worrying about
conflicts, but you then get other fun problems like having to declare
everything in the namespace sequentially and having to refer everything in
the namespace with the namespace unless you alias it all.
So really, the most flexible solution would probably to have
extern(C++, "NS") which only affects the mangling and then make sure that it
works to do something like
struct Namespace
{
extern(C++, "Namespace") static void foo(int bar);
}
thereby allowing you to have symbols from multiple namespaces in the same
module even if they have conflicting names. In most cases, people would then
just do
extern(C++, "Namespace") void foo(int bar);
and it's nice and simple, whereas if they really wanted to put conflicting
symbols in the same module instead of just putting them in separate module
like you would with D symbols, they could then explicitly namespace them.
But given what we already have in the language, the simplest alternative
would be to just add
extern(C++, "Namespace")
and leave
extern(C++, Namespace)
so that most code could use extern(C++, "Namespace"), and those rare cases
where you really don't want to put conflicting symbols in separate modules,
you use the current scheme of extern(C++, Namespace). The main downside is
that having both constructs risks being confusing. Really though, there
isn't much of a downside to the extern(C++, "Namespace") solution even if it
were the only one.
- Jonathan M Davis
Re: extern(C++, ns) is wrong
On Wednesday, 12 September 2018 at 03:59:30 UTC, Danni Coy wrote: So my understanding is that the main issue with extern(C++,"ns") is functions that have different C++ name-spaces overriding each other in unexpected ways. How feasible is to simply disallow functions/variables/objects/... with the same name but a different "ns" being in the same module? Very. The compiler would do it automatically because they would cause name collisions.
Re: extern(C++, ns) is wrong
So my understanding is that the main issue with extern(C++,"ns") is functions that have different C++ name-spaces overriding each other in unexpected ways. How feasible is to simply disallow functions/variables/objects/... with the same name but a different "ns" being in the same module?
Re: rund users welcome
On Tuesday, 11 September 2018 at 19:55:33 UTC, Andre Pany wrote: On Saturday, 8 September 2018 at 04:24:20 UTC, Jonathan Marler wrote: I've rewritten rdmd into a new tool called "rund" and have been using it for about 4 months. It runs about twice as fast making my workflow much "snappier". It also introduces a new feature called "source directives" where you can add special comments to the beginning of your D code to set various compiler options like import paths, versions, environment variable etc. Feel free to use it, test it, provide feedback, contribute. https://github.com/marler8997/rund It would be great if you could create a pull request for rdmd to add the missing -i enhancement. Kind regards Andre I did :) https://github.com/dlang/tools/pull/292 I spent quite a bit of time on it but in the end the bulk of my time was spent on what seemed to be endless debate rather than writing good code. After I decided to try forking rdmd my life got much better :) Now I spend my time writing great code, making good tests and having nice tools. I'm much happier working than I am arguing with people. What took me months to do with rdmd took me less than a day with my rund. So...if you have requests for rund features or issues by all means let me know, but I don't control rdmd and I've learned that time contributing to it is mostly time wasted.
Canadian companies using D?
Hi All, I wonder if you guys are aware of any Canadian companies using D, I want to do some research about what they're using D for and eventually follow some of them. I was browsing https://dlang.org/orgs-using-d.html but I didn't find any there yet. Cheers.
Re: Mobile is the new PC and AArch64 is the new x64
On Tuesday, 11 September 2018 at 07:23:53 UTC, Joakim wrote: I agree with a lot of what you say here, but I'm not sure what you mean by "first class support for mobile." What exactly do you believe D needs to reach that level? Natural-feeling bindings to platform libraries that are not incredibly slow and that are well-maintained. What does it matter that you can run a webserver from your phone if you can't write a "hello world" GUI program, set an alarm, or enqueue a download?
Fwd: Copy Constructor DIP and implementation
This should probably have been posted here. -- Andrei Forwarded Message Subject: Copy Constructor DIP and implementation Date: Tue, 11 Sep 2018 15:08:33 + From: RazvanN Organization: Digital Mars Newsgroups: digitalmars.D.announce Hello everyone, I have finished writing the last details of the copy constructor DIP[1] and also I have published the first implementation [2]. As I wrongfully made a PR for the DIP queue in the early stages of the development of the DIP, I want to announce this way that the DIP is ready for the draft review now. Those who are familiar with the compiler, please take a look at the implementation and help me improve it! Thanks, RazvanN [1] https://github.com/dlang/DIPs/pull/129 [2] https://github.com/dlang/dmd/pull/8688
Re: rund users welcome
On Saturday, 8 September 2018 at 04:24:20 UTC, Jonathan Marler wrote: I've rewritten rdmd into a new tool called "rund" and have been using it for about 4 months. It runs about twice as fast making my workflow much "snappier". It also introduces a new feature called "source directives" where you can add special comments to the beginning of your D code to set various compiler options like import paths, versions, environment variable etc. Feel free to use it, test it, provide feedback, contribute. https://github.com/marler8997/rund It would be great if you could create a pull request for rdmd to add the missing -i enhancement. Kind regards Andre
Re: @safe pointer value modification
On Saturday, September 8, 2018 11:06:20 AM MDT Neia Neutuladh via
Digitalmars-d wrote:
> On Saturday, 8 September 2018 at 17:01:33 UTC, Jacob Shtokolov
>
> wrote:
> > So, modification of pointer values is prohibited (if I
> > understand this sentence correctly).
>
> @safe code can't manipulate the pointer itself, in order to avoid
> memory corruption.
>
> So this is forbidden:
>
> void main() @safe
> {
>int* p = malloc(512);
>p++;
> }
>
> But in @safe code, the compiler assumes that all pointers you
> receive are valid. And the null pointer is also valid --
> dereferencing it results in a segmentation fault rather than
> memory corruption.
Also, mutating the data that a pointer points to is not mutating the
pointer. So,
*foo = 42;
is not mutating a pointer, whereas
++foo;
would be. So, the first is allowed in @safe code, whereas the second is not.
BTW, if you have questions about D, please ask them in D.Learn. This
newsgroup / mailing list / forum is intended for general discussion on D,
not for answering questions about how the language works.
- Jonathan M Davis
Re: rund users welcome
On Tuesday, 11 September 2018 at 17:36:09 UTC, Kagamin wrote: On Tuesday, 11 September 2018 at 15:20:51 UTC, Jonathan Marler wrote: The Posix/Windows 10 cases seem fine, but Windows <10 is not great. MSDN says symbolic links are supported since Vista. Yeah but I think you need Admin privileges to make them.
Re: rund users welcome
On Tuesday, 11 September 2018 at 15:20:51 UTC, Jonathan Marler wrote: The Posix/Windows 10 cases seem fine, but Windows <10 is not great. MSDN says symbolic links are supported since Vista.
Re: Mobile is the new PC and AArch64 is the new x64
On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote: LDC recently added a linux/AArch64 CI for both its main branches and 64-bit ARM, ie AArch64, builds have been put out for both linux and Android. It does not seem that many are paying attention to this sea change that is going on with computing though, so let me lay out some evidence. ... I mostly agree with you, Joakim. I own a very nice (but now old) ODROID U2 (check the ODROID XU4 or C2!) so ARM support is important for me... Also, check this: https://www.hardkernel.com/main/products/prdt_info.php?g_code=G152875062626 HOWEVER, I think Iain is right - PPC64 and RISC-V are becoming more and more popular nowadays and may become more popular than ARM in the future but that future is unclear.
Re: rund users welcome
On Tuesday, 11 September 2018 at 08:53:46 UTC, Kagamin wrote: On Saturday, 8 September 2018 at 04:24:20 UTC, Jonathan Marler wrote: https://github.com/marler8997/rund I have an idea how to push shebang to userland and make it crossplatform: if, say, `rund -install prog.d` would copy/link itself into current folder under name "prog" and when run would work with file args[0]~".d", this will work the same on all platforms without shebang. So your idea is that you could run `rund -install prog.d` which would create some sort of file that allows you to run `./prog` (on POSIX) or `prog` (on WINDOWS). So something like this: /path/prog.d Posix: /path/prog -> /usr/bin/rund Windows 10 (It supports symbolic links) /path/prog.exe -> C:\Programs\rund.exe Windows <10 /path/prog.exe (a copy of rund.exe) Then this would allow you to run "/path/prog" and which would invoke rund and like you said we could take "argv[0]" and assume that's the main source file. The Posix/Windows 10 cases seem fine, but Windows <10 is not great. In this case it has to keep an entire copy of rund around (currently 1.8M). I think we can do better. Instead, `rund -install prog.d` could generate a little "wrapper program" that forwards any calls to rund. You could make this wrapper program with a small D program, or with this BATCH script: --- /path/prog.bat @rund %~dp0prog.d %* You get the same result. When you run "\path\prog" it will invoke rund with the given args for prog.d. Thoughts?
Re: More fun with autodecoding
On Tuesday, 11 September 2018 at 02:00:29 UTC, Nicholas Wilson wrote: [snip] https://github.com/dlang/DIPs/pull/131 will help narrow down the cause. I like it, but I worry people would find multiple ifs confusing. The first line of the comment is about using static asserts and in contracts, but it looks like static asserts are allowed in in contracts for functions [1]. You can do the same thing in structs/classes with invariant blocks (but in contracts are not allowed). So basically, the same behavior for if can be reduced to in contracts with static asserts already. Multiple ifs would just be a slightly less verbose way to accomplish the same thing. I suppose one issue might be that contracts are not compiled in during release mode, but I think release only impacts normal asserts, not static asserts. Is there any reason why this is not sufficient? [1] https://run.dlang.io/is/lu6nQ0
Re: This is why I don't use D.
On Tuesday, 11 September 2018 at 13:48:36 UTC, 0xEAB wrote: By the way, thanks for all your explanations :) No problem! If it's inscrutable, it's not very useful.
Re: This is why I don't use D.
On Monday, 10 September 2018 at 20:36:44 UTC, Neia Neutuladh wrote: On Monday, 10 September 2018 at 19:19:56 UTC, 0xEAB wrote: Moreover, a future feature could be build logs, so one could check why something failed to build. I'm hesitant to do much in this regard because I don't want people to treat this as a CI system. It would certainly be useful for finding bugs in the tester, though. A possible solution to this problem could be not testing updated packages for a compiler version they have already been tested with. This comes with some downsides, though - but it prevents abusing your service as CI. By the way, thanks for all your explanations :)
Re: More fun with autodecoding
On Tuesday, 11 September 2018 at 13:08:46 UTC, Steven Schveighoffer wrote: On 9/10/18 7:00 PM, Nicholas Wilson wrote: On Monday, 10 September 2018 at 20:44:46 UTC, Andrei Alexandrescu wrote: On 9/10/18 12:46 PM, Steven Schveighoffer wrote: On 9/10/18 8:58 AM, Steven Schveighoffer wrote: I'll have to figure out why my specialized range doesn't allow splitting based on " ". And the answer is: I'm an idiot. Forgot to define empty :) Also my slicing operator accepted ints and not size_t. I guess a better error message would be in order. https://github.com/dlang/DIPs/pull/131 will help narrow down the cause. While this would help eventually, I'd prefer something that just transforms all the existing code into useful error messages. See my response to Andrei. -Steve Please tell me where to get one of those! But yeah, that DIP will tell you that has slicing is you problem straight away. Extracting useful information to present to the user on why hasSlicing!R is false is much trickier for the same reason that providing useful information in the current template constraint format is hard: it is a bunch of potentially unstructured logic that has already been const-folded in order to evaluate it in the first place, so you can't re-evaluate it without flushing the template cache. That's not to say that the situation can't be improved beyond what the DIP specifies, but I haven't had any brilliant ideas (and the Idea for that DIP was stolen from someone else anyway).
Re: Small @nogc experience report
On Monday, 10 September 2018 at 09:11:38 UTC, Kagamin wrote: On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat wrote: There is no other choice when the runtime is disabled but to have @nogc. It's a fantastic peace of mind for high-performance to be able to _enforce_ something will not allocate. You can't have a working GC allocation with disabled runtime, can you? Indeed and that's why you must ensure at compile-time that you have no `new` else you have a runtime crash, and one that might be difficult to test unless you have perfect coverage.
Re: More fun with autodecoding
On 9/10/18 7:00 PM, Nicholas Wilson wrote: On Monday, 10 September 2018 at 20:44:46 UTC, Andrei Alexandrescu wrote: On 9/10/18 12:46 PM, Steven Schveighoffer wrote: On 9/10/18 8:58 AM, Steven Schveighoffer wrote: I'll have to figure out why my specialized range doesn't allow splitting based on " ". And the answer is: I'm an idiot. Forgot to define empty :) Also my slicing operator accepted ints and not size_t. I guess a better error message would be in order. https://github.com/dlang/DIPs/pull/131 will help narrow down the cause. While this would help eventually, I'd prefer something that just transforms all the existing code into useful error messages. See my response to Andrei. -Steve
Re: More fun with autodecoding
On 9/10/18 1:44 PM, Andrei Alexandrescu wrote:
On 9/10/18 12:46 PM, Steven Schveighoffer wrote:
On 9/10/18 8:58 AM, Steven Schveighoffer wrote:
I'll have to figure out why my specialized range doesn't allow
splitting based on " ".
And the answer is: I'm an idiot. Forgot to define empty :) Also my
slicing operator accepted ints and not size_t.
I guess a better error message would be in order.
A better error message would help prevent the painful diagnosis that I
had to do to actually find the issue.
So the error I got was this:
source/bufref.d(346,36): Error: template
std.algorithm.iteration.splitter cannot deduce function from argument
types !()(Result, string), candidates are:
/Users/steves/.dvm/compilers/dmd-2.081.0/osx/bin/../../src/phobos/std/algorithm/iteration.d(3792,6):
std.algorithm.iteration.splitter(alias pred = "a == b", Range,
Separator)(Range r, Separator s) if (is(typeof(binaryFun!pred(r.front,
s)) : bool) && (hasSlicing!Range && hasLength!Range ||
isNarrowString!Range))
/Users/steves/.dvm/compilers/dmd-2.081.0/osx/bin/../../src/phobos/std/algorithm/iteration.d(4163,6):
std.algorithm.iteration.splitter(alias pred = "a == b", Range,
Separator)(Range r, Separator s) if (is(typeof(binaryFun!pred(r.front,
s.front)) : bool) && (hasSlicing!Range || isNarrowString!Range) &&
isForwardRange!Separator && (hasLength!Separator ||
isNarrowString!Separator))
/Users/steves/.dvm/compilers/dmd-2.081.0/osx/bin/../../src/phobos/std/algorithm/iteration.d(4350,6):
std.algorithm.iteration.splitter(alias isTerminator,
Range)(Range r) if (isForwardRange!Range &&
is(typeof(unaryFun!isTerminator(r.front
/Users/steves/.dvm/compilers/dmd-2.081.0/osx/bin/../../src/phobos/std/algorithm/iteration.d(4573,6):
std.algorithm.iteration.splitter(C)(C[] s) if (isSomeChar!C)
This means I had to look at each line, figure out which overload I'm
calling, and then copy all the constraints locally, seeing which ones
were true and which ones false.
But it didn't stop there. The problem was hasSlicing!Range. If you look
at hasSlicing, it looks like this:
enum bool hasSlicing(R) = isForwardRange!R
&& !isNarrowString!R
&& is(ReturnType!((R r) => r[1 .. 1].length) == size_t)
&& (is(typeof(lvalueOf!R[1 .. 1]) == R) || isInfinite!R)
&& (!is(typeof(lvalueOf!R[0 .. $])) || is(typeof(lvalueOf!R[0 ..
$]) == R))
&& (!is(typeof(lvalueOf!R[0 .. $])) || isInfinite!R
|| is(typeof(lvalueOf!R[0 .. $ - 1]) == R))
&& is(typeof((ref R r)
{
static assert(isForwardRange!(typeof(r[1 .. 2])));
}));
Now I had to instrument a whole slew of items. I pasted this whole thing
this into my code, added an alias to my range type for R, and then
changed the big boolean expression to a bunch of static asserts.
Then I found the true culprit was isForwardRange!R. This led me to
requestion my sanity, and finally realized I forgot the empty function.
A fabulous fantastic mechanism that would have saved me some time is
simply coloring the clauses of the template constraint that failed red,
the ones that passed green, and the ones that weren't evaluated grey.
Furthermore, it would be good to either recursively continue this for
red clauses like `hasSlicing` which have so much underneath. Either that
or a way to trigger the colored evaluation on demand.
If I were a dmd guru, I'd look at doing this myself. I may still try and
hack it in just to see if I can do it.
--
Finally, there is a possible bug in the definition of hasSlicing: it
doesn't require the slice parameters be size_t, but there are places
(e.g. inside std.algorithm.searching.find) that pass in range.length ..
range.length for slicing the range. In my implementation I had used ints
as the parameters for opSlice. So I started seeing errors deep inside
std.algorithm saying there was no overload for slicing. Again the sanity
was questioned, and I figured out the error and now it's actually working.
-Steve
Re: rund users welcome
On Saturday, 8 September 2018 at 04:24:20 UTC, Jonathan Marler wrote: https://github.com/marler8997/rund I have an idea how to push shebang to userland and make it crossplatform: if, say, `rund -install prog.d` would copy/link itself into current folder under name "prog" and when run would work with file args[0]~".d", this will work the same on all platforms without shebang.
Re: Mobile is the new PC and AArch64 is the new x64
On Tuesday, 11 September 2018 at 07:23:53 UTC, Joakim wrote: I agree with a lot of what you say here, but I'm not sure what you mean by "first class support for mobile." What exactly do you believe D needs to reach that level? Basically the things you describe. I was thinking of a stable and easy build system, e.g. $ dub init android [iOS] $ dub --arch=arm64 And and of course check which language features work (or don't work!) on ARM and write a documentation. Cf. https://kotlinlang.org/docs/reference/native-overview.html The thing is that D already has a lot of useful stuff like C/C++ and Objective-C interop. It would be a pity if we didn't use it. I think most of the heavy lifting with core language and stdlib support is done. What remains is polish and integration for the build process and possibly IDEs and of course, making sure there are D libraries to make mobile dev easier. I will be sporadically polishing the build process over the coming months, by getting much more building through dub. I won't be doing anything with IDEs, as I don't use them. As for libraries, that all depends on what you're doing and how much others in the D community want that too. It might be a good idea to set up a funding target to get the iOS port back up to speed again. I don't use Apple products so it won't be me picking up that porting work, but maybe Dan could be enticed to finish it as a paid project, since he did most of the voluntary work so far. I'm purely speculating, no idea if money changes the equation for him, just know that he's been too busy to work on it for the last couple years. That'd be part of the first class support. That a dedicated team works on it. Volunteers are not enough. Once it's polished it will still need loads of maintenance.
Re: Mobile is the new PC and AArch64 is the new x64
On Tuesday, 11 September 2018 at 07:42:38 UTC, passenger wrote: On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote: [...] Is it possible to develop versus a NVidia Jetson, CUDA included? I think so, but I doubt anyone has ever actually tried it: https://www.nvidia.com/en-us/autonomous-machines/embedded-systems-dev-kits-modules/ As for CUDA, Nicholas Wilson said recently that he could do something with it for his DCompute project with ldc, but no idea what the current status is: https://forum.dlang.org/post/slijjptlxdrfgvoya...@forum.dlang.org
Re: Mobile is the new PC and AArch64 is the new x64
On Monday, 10 September 2018 at 13:43:46 UTC, Joakim wrote: LDC recently added a linux/AArch64 CI for both its main branches and 64-bit ARM, ie AArch64, builds have been put out for both linux and Android. It does not seem that many are paying attention to this sea change that is going on with computing though, so let me lay out some evidence. At my workplace six years ago, the developers were all allocated a core i5 ultrabook- likely with 4 GBs of RAM and a 128 GB SSD, though I don't remember those specs- and a 27" 2560X1440 display with which to get our work done. I was pretty happy with the display, the best I'd ever used to that point. I'm guessing the setup cost my employer a couple thousand dollars per developer. I picked up an Android/AArch64 smartphone earlier this year, with 6 GBs of RAM, 128 GBs of flash, a Snapdragon 835 octa-core CPU, and a 5.5" 2560X1440 display. This is the fastest computer I've ever owned, and it fits in 6 cubic inches and weighs a little more than a third of a pound. It cost me approximately $700. That is a stunning change in mobile capabilities in just six years, where what used to be a mobile developer workstation now comes packed into a smartphone at a fraction of the cost. If you think the phone doesn't actually perform, I borrowed a 2015-model Macbook Air with a core i5 and 4 GBs of RAM and built the last pure C++ version of ldc, 0.17, using both cores with `-ninja -j5`. It took two minutes with clang from Homebrew, the same amount of time it takes me to build the same source on my smartphone with clang by running `ninja -j9`. This phone has been my development hardware since early this year, by pairing it with a $30 bluetooth keyboard and a $5 stand to hold it up. I'm typing this long forum post up on it now. Tech companies are starting to realize this and going after the desktop/laptop PC markets with various 64-bit ARM products: https://www.engadget.com/2018/08/09/samsung-galaxy-note-9-dex/ https://arstechnica.com/gadgets/2018/08/samsungs-tab-s4-is-both-an-android-tablet-and-a-desktop-computer/ https://youtube.com/watch?v=uLvIAskVSUM https://www.anandtech.com/show/13309/lenovo-yoga-c630-snapdragon-850-windows That last link notes 25 hours of battery life with a Windows/AArch64 laptop, one of the key benefits of ARM, which is why even Microsoft has come around. Yes, I know, these devices won't replace your quad-core Xeon workstation with 32-64 GBs of RAM anytime soon, but most people don't need anywhere near that level of compute. That's why PC sales keep dropping while mobile sales are now 6-7X that per year: https://www.businessinsider.com/PC-sales-are-continuing-to-slump-fewer-are-sold-now-than-when-the-iPhone-launched/articleshow/62547330.cms https://www.androidauthority.com/smartphone-sales-idc-2018-871363/ Most of those mobile devices running iOS have AArch64 CPUs, and google said last December that "over 40% of Android devices coming online have 64-bit support," which is why they're requiring apps with native libraries to support it by next fall: https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html D now has mostly working AArch64 support, with the ldc 1.11 release last month: https://github.com/ldc-developers/ldc/releases/tag/v1.11.0 That is the result of years of intermittent AArch64 patches added by the core teams of ldc and gdc- David, Iain, Kai, Johannes, Dan, and others- to which I recently added some Android patches. You too can pitch in with the few remaining issues or try out the AArch64 support with your own D code. This company provides a free linux/AArch64 CI for OSS projects, LDC uses it: http://blog.shippable.com/shippable-arm-packet-deliver-native-ci-cd-for-arm-architecture Despite all this, D may never do very well on mobile or AArch64, even though I think it's well-suited for that market. But at the very least, you should be looking at mobile and AArch64, as they're taking over the computing market. Is it possible to develop versus a NVidia Jetson, CUDA included?
Re: dlang download stat should be updated
On Sunday, 9 September 2018 at 09:05:33 UTC, Suliman wrote: Last update was long time ago http://erdani.com/d/downloads.daily.png UP
Re: Mobile is the new PC and AArch64 is the new x64
On Tuesday, 11 September 2018 at 06:42:26 UTC, Chris wrote:
On Monday, 10 September 2018 at 19:28:01 UTC, aberba wrote:
On Monday, 10 September 2018 at 16:09:41 UTC, rjframe wrote:
That's exactly whats happening in Africa. The continent is
leapfrogging from nothing to a smart phone thanks to China.
Many don'[t know how to even use a PC. Especially the young
and upcoming generation.
The smart phone market is really significant.
That's why I'm trying to draw attention to first class ARM
support by the D Foundation (not just some voluntary efforts,
much as they are appreciated). ARM in dmd wouldn't be a bad
idea perhaps, as Manu suggested. It's become more than obvious
over the last couple of years that mobile devices have become
very important and that people often use them instead of PCs or
laptops. Fewer and fewer developers can "escape" development
for mobile ("we want an app too"), and if a language doesn't
offer first class support for mobile, then devs won't bother
with it. A lot of other (new) languages are directing their
efforts towards mobile for a reason.
I agree with a lot of what you say here, but I'm not sure what
you mean by "first class support for mobile." What exactly do you
believe D needs to reach that level?
I think most of the heavy lifting with core language and stdlib
support is done. What remains is polish and integration for the
build process and possibly IDEs and of course, making sure there
are D libraries to make mobile dev easier.
I will be sporadically polishing the build process over the
coming months, by getting much more building through dub. I won't
be doing anything with IDEs, as I don't use them.
As for libraries, that all depends on what you're doing and how
much others in the D community want that too.
It might be a good idea to set up a funding target to get the iOS
port back up to speed again. I don't use Apple products so it
won't be me picking up that porting work, but maybe Dan could be
enticed to finish it as a paid project, since he did most of the
voluntary work so far. I'm purely speculating, no idea if money
changes the equation for him, just know that he's been too busy
to work on it for the last couple years.
Re: Small @nogc experience report
On Saturday, 8 September 2018 at 08:32:58 UTC, Guillaume Piolat wrote: Not Weka but we are happy with @nogc and without @nogc our job would be impossible. There is one way to code without garbage collector somewhat practically without annotating @nogc, the way I use: Compile manually only those parts of runtime you need and have linker to link in only needed symbols (so there is no need to go stubbing the whole runtime). If you accidently allocate, you get linker errors. Still, @nogc helps because it will tell right away where I called something I should not. I wonder if having an option to compile DRuntime without support for thearding would simplify portability. I once read the implementation and got the impression that theards are by far the most platform-dependant part of it.
