Re: HTOD
On Friday, 25 August 2017 at 00:43:56 UTC, Walter Bright wrote:
On 8/24/2017 12:08 PM, Jacob Carlborg wrote:
D can already link with C++, but not all features are
supported. Like lambdas, for example, are not supported.
I have no idea how that would even work. Since lambdas are
nested functions, how would one write one in D and have it
nested inside C++ code?
Like this:
// C++
void foo(std::function fn) {
printf("%s", fn(3));
}
// D
extern(C++)
void foo(char* delegate(int) fn);
--
Biotronic
Re: Compile Imported Modules
On Thursday, 24 August 2017 at 17:37:12 UTC, Jonathan Marler wrote: On Thursday, 24 August 2017 at 16:49:08 UTC, Seb wrote: On Thursday, 24 August 2017 at 16:32:32 UTC, Jonathan Marler wrote: On Thursday, 24 August 2017 at 15:56:32 UTC, H. S. Teoh wrote: On Thu, Aug 24, 2017 at 03:53:05PM +, Jonathan Marler via Digitalmars-d wrote: Wanted to get peoples thoughts on this. The idea is to have a way to tell the compiler (probably with a command line option) that you'd like to "compile imported modules". [...] Isn't this what rdmd already does? T That is one thing that rdmd does (as I mentioned in the original post). I just looked through the rdmd code (https://github.com/dlang/tools/blob/master/rdmd.d) and it looks like it invokes the compiler using "dmd -v" to get the list of modules and then invokes the compiler again with the modules it found to perform the full compile. So my original thought that the logic to find modules is duplicated was incorrect. Instead we just pay a performance hit to get the correct list of imports since running "dmd -v" seems to take almost as long as the actual compile itself. So this method comes close to doubling the time it takes to compile than if the feature was implemented in the compiler itself. In any case, the idea is to allow the compiler to resolve this on it's own without help from rdmd. This would remove the need to invoke the compiler twice, once to find the imports and once to compile. It would also allow some projects/applications that don't use rdmd to take advantage of this feature, this may or may not include dub (not sure on that one). rdmd is really bad in terms of performance. If you call a single D file with rdmd, it will always compile it twice. There was an attempt to fix this (https://github.com/dlang/tools/pull/194), but this has been reverted as it introduced a regression and no one had time to look at the regression. Moving rdmd into DMD has been on the TODO list for quite a while and there is a consensus that the performance overhead if rdmd isn't nice. However, IIRC there was no clear consensus on how the integration should happen. I recall that the plan was to do try this with "dmd as a library", but I'm not sure whether that's really feasible ATM. Well this should solve the rdmd performance problem as well as make other user cases easier that don't necessarilly use rdmd. I had another thought that instead of making this an "opt-in" feature, it would probably make more sense to be an "opt-out" feature. So by default the compiler would compile missing imported modules unless you indicate otherwise, maybe a command line switch like "-dont-compile-imports". And I don't see how this would break anything. Everything should work the same as it did before, it's just now you can omit imported module files from the command line and it should just work. I've looked through the DMD code to see how this could be implemented and I've run into a problem. The solution I came up with was to go through all the imported modules and then determine which ones need to be compiled that haven't been given on the command line. The problem is, I don't know how to determine whether a module was already compiled and given in an obj/lib file. For example, dmd something.obj anotherthing.lib prog.d As far as I know, the compiler has no idea which modules are contained in "something.obj" and "anotherthing.lib". It just compiles the source given on then command line, then passes all the object files and libraries to the linker, at which point the concept of modules is lost. Am I correct in saying that the compiler has no idea which modules an obj/lib file contains?
Re: newCTFE Status August 2017
On Monday, 14 August 2017 at 11:25:14 UTC, Stefan Koch wrote: Release is coming closer! Nice, keep up the good work.
Re: HTOD
On 8/24/2017 12:08 PM, Jacob Carlborg wrote: D can already link with C++, but not all features are supported. Like lambdas, for example, are not supported. I have no idea how that would even work. Since lambdas are nested functions, how would one write one in D and have it nested inside C++ code?
Re: HTOD
On 8/24/2017 12:53 AM, lobo wrote: D had 1 ICE that was a known issue with core team member comments on the bug report. What's the bugzilla issue number?
Re: Compile Imported Modules
On Thursday, 24 August 2017 at 18:12:03 UTC, H. S. Teoh wrote: On Thu, Aug 24, 2017 at 06:00:15PM +, Jonathan Marler via Digitalmars-d wrote: On Thursday, 24 August 2017 at 17:49:27 UTC, H. S. Teoh wrote: > Uh, no. This will definitely break separate compilation, > and some people will be very unhappy about that. I couldn't think of a case that it would break. Can you share the cases you thought of? Suppose you have main.d and module.d, and you want to compile them separately: dmd -c main.d dmd -c module.d dmd -ofmyprogram main.o module.o If dmd defaulted to auto-importing, then `dmd -c main.d` would also compile module.d (assuming main.d imports `module`), contrary to what was intended in a separate compilation scenario, and the last command will produce a linker error from duplicated symbols. This is just a simple case, of course. But in general, changing the meaning of `dmd -c source.d` will break existing build scripts. Sure, you could ask people to update their build scripts to include `-no-auto-imports`, but that requires effort from users, who will be unhappy that upgrading dmd broke their build scripts. For large projects, such a change may not be trivial as in the above example. T Actually this feature is mutually exclusive with the "-c" case. It doesn't make sense to compile imported modules unless you are also linking an executable. So your example would work as expected. Do you have any other cases you thought of that would not work? Like I said I couldn't think of any. I'm not saying that that's enough reason to make it an "opt-out" feature, it's just something to think about. The feature could also be an "opt-in" feature at first and eventually made "opt-out" if it makes sense. But I'd still like to know people's thoughts/concerns either way.
Re: HTOD
On 2017-08-24 17:02, 12345swordy wrote: They have plans to add c++ support? D can already link with C++, but not all features are supported. Like lambdas, for example, are not supported. -- /Jacob Carlborg
Re: Compile Imported Modules
On Thu, Aug 24, 2017 at 06:00:15PM +, Jonathan Marler via Digitalmars-d wrote: > On Thursday, 24 August 2017 at 17:49:27 UTC, H. S. Teoh wrote: > > Uh, no. This will definitely break separate compilation, and some > > people will be very unhappy about that. > > I couldn't think of a case that it would break. Can you share the > cases you thought of? Suppose you have main.d and module.d, and you want to compile them separately: dmd -c main.d dmd -c module.d dmd -ofmyprogram main.o module.o If dmd defaulted to auto-importing, then `dmd -c main.d` would also compile module.d (assuming main.d imports `module`), contrary to what was intended in a separate compilation scenario, and the last command will produce a linker error from duplicated symbols. This is just a simple case, of course. But in general, changing the meaning of `dmd -c source.d` will break existing build scripts. Sure, you could ask people to update their build scripts to include `-no-auto-imports`, but that requires effort from users, who will be unhappy that upgrading dmd broke their build scripts. For large projects, such a change may not be trivial as in the above example. T -- Life is too short to run proprietary software. -- Bdale Garbee
Re: Compile Imported Modules
On Thursday, 24 August 2017 at 17:49:27 UTC, H. S. Teoh wrote: Uh, no. This will definitely break separate compilation, and some people will be very unhappy about that. I couldn't think of a case that it would break. Can you share the cases you thought of?
Re: Another reason to use BetterC
On 23 August 2017 at 03:22, Walter Bright via Digitalmars-d wrote: > https://news.ycombinator.com/item?id=15075242 You mean D?
Re: Compile Imported Modules
On Thu, Aug 24, 2017 at 05:37:12PM +, Jonathan Marler via Digitalmars-d wrote: [...] > I had another thought that instead of making this an "opt-in" feature, > it would probably make more sense to be an "opt-out" feature. So by > default the compiler would compile missing imported modules unless you > indicate otherwise, maybe a command line switch like > "-dont-compile-imports". And I don't see how this would break > anything. Everything should work the same as it did before, it's just > now you can omit imported module files from the command line and it > should just work. Uh, no. This will definitely break separate compilation, and some people will be very unhappy about that. I think it's good enough to leave it as an opt-in feature. T -- Today's society is one of specialization: as you grow, you learn more and more about less and less. Eventually, you know everything about nothing.
Re: Compile Imported Modules
On Thursday, 24 August 2017 at 16:49:08 UTC, Seb wrote: On Thursday, 24 August 2017 at 16:32:32 UTC, Jonathan Marler wrote: On Thursday, 24 August 2017 at 15:56:32 UTC, H. S. Teoh wrote: On Thu, Aug 24, 2017 at 03:53:05PM +, Jonathan Marler via Digitalmars-d wrote: Wanted to get peoples thoughts on this. The idea is to have a way to tell the compiler (probably with a command line option) that you'd like to "compile imported modules". [...] Isn't this what rdmd already does? T That is one thing that rdmd does (as I mentioned in the original post). I just looked through the rdmd code (https://github.com/dlang/tools/blob/master/rdmd.d) and it looks like it invokes the compiler using "dmd -v" to get the list of modules and then invokes the compiler again with the modules it found to perform the full compile. So my original thought that the logic to find modules is duplicated was incorrect. Instead we just pay a performance hit to get the correct list of imports since running "dmd -v" seems to take almost as long as the actual compile itself. So this method comes close to doubling the time it takes to compile than if the feature was implemented in the compiler itself. In any case, the idea is to allow the compiler to resolve this on it's own without help from rdmd. This would remove the need to invoke the compiler twice, once to find the imports and once to compile. It would also allow some projects/applications that don't use rdmd to take advantage of this feature, this may or may not include dub (not sure on that one). rdmd is really bad in terms of performance. If you call a single D file with rdmd, it will always compile it twice. There was an attempt to fix this (https://github.com/dlang/tools/pull/194), but this has been reverted as it introduced a regression and no one had time to look at the regression. Moving rdmd into DMD has been on the TODO list for quite a while and there is a consensus that the performance overhead if rdmd isn't nice. However, IIRC there was no clear consensus on how the integration should happen. I recall that the plan was to do try this with "dmd as a library", but I'm not sure whether that's really feasible ATM. Well this should solve the rdmd performance problem as well as make other user cases easier that don't necessarilly use rdmd. I had another thought that instead of making this an "opt-in" feature, it would probably make more sense to be an "opt-out" feature. So by default the compiler would compile missing imported modules unless you indicate otherwise, maybe a command line switch like "-dont-compile-imports". And I don't see how this would break anything. Everything should work the same as it did before, it's just now you can omit imported module files from the command line and it should just work.
Re: Compile Imported Modules
On Thu, Aug 24, 2017 at 04:49:08PM +, Seb via Digitalmars-d wrote: [...] > rdmd is really bad in terms of performance. If you call a single D > file with rdmd, it will always compile it twice. There was an attempt > to fix this (https://github.com/dlang/tools/pull/194), but this has > been reverted as it introduced a regression and no one had time to > look at the regression. Moving rdmd into DMD has been on the TODO > list for quite a while and there is a consensus that the performance > overhead if rdmd isn't nice. However, IIRC there was no clear > consensus on how the integration should happen. I recall that the plan > was to do try this with "dmd as a library", but I'm not sure whether > that's really feasible ATM. Hmm. An interesting thought occurred to me: dmd already has a -run option, so perhaps it wouldn't be too hard to add an auto-import option like Jonathan proposes, then dmd would essentially have the functionality of rdmd? Well, other than caching the executable, that is. But once auto-import is in, redundant compilation will become a thing of the past, as rdmd could just invoke dmd, and the only thing extra it would do is the executable caching. T -- What doesn't kill me makes me stranger.
Re: Compile Imported Modules
On Thursday, 24 August 2017 at 16:32:32 UTC, Jonathan Marler wrote: On Thursday, 24 August 2017 at 15:56:32 UTC, H. S. Teoh wrote: On Thu, Aug 24, 2017 at 03:53:05PM +, Jonathan Marler via Digitalmars-d wrote: Wanted to get peoples thoughts on this. The idea is to have a way to tell the compiler (probably with a command line option) that you'd like to "compile imported modules". [...] Isn't this what rdmd already does? T That is one thing that rdmd does (as I mentioned in the original post). I just looked through the rdmd code (https://github.com/dlang/tools/blob/master/rdmd.d) and it looks like it invokes the compiler using "dmd -v" to get the list of modules and then invokes the compiler again with the modules it found to perform the full compile. So my original thought that the logic to find modules is duplicated was incorrect. Instead we just pay a performance hit to get the correct list of imports since running "dmd -v" seems to take almost as long as the actual compile itself. So this method comes close to doubling the time it takes to compile than if the feature was implemented in the compiler itself. In any case, the idea is to allow the compiler to resolve this on it's own without help from rdmd. This would remove the need to invoke the compiler twice, once to find the imports and once to compile. It would also allow some projects/applications that don't use rdmd to take advantage of this feature, this may or may not include dub (not sure on that one). rdmd is really bad in terms of performance. If you call a single D file with rdmd, it will always compile it twice. There was an attempt to fix this (https://github.com/dlang/tools/pull/194), but this has been reverted as it introduced a regression and no one had time to look at the regression. Moving rdmd into DMD has been on the TODO list for quite a while and there is a consensus that the performance overhead if rdmd isn't nice. However, IIRC there was no clear consensus on how the integration should happen. I recall that the plan was to do try this with "dmd as a library", but I'm not sure whether that's really feasible ATM.
Re: Compile Imported Modules
On Thursday, 24 August 2017 at 15:56:32 UTC, H. S. Teoh wrote: On Thu, Aug 24, 2017 at 03:53:05PM +, Jonathan Marler via Digitalmars-d wrote: Wanted to get peoples thoughts on this. The idea is to have a way to tell the compiler (probably with a command line option) that you'd like to "compile imported modules". [...] Isn't this what rdmd already does? T That is one thing that rdmd does (as I mentioned in the original post). I just looked through the rdmd code (https://github.com/dlang/tools/blob/master/rdmd.d) and it looks like it invokes the compiler using "dmd -v" to get the list of modules and then invokes the compiler again with the modules it found to perform the full compile. So my original thought that the logic to find modules is duplicated was incorrect. Instead we just pay a performance hit to get the correct list of imports since running "dmd -v" seems to take almost as long as the actual compile itself. So this method comes close to doubling the time it takes to compile than if the feature was implemented in the compiler itself. In any case, the idea is to allow the compiler to resolve this on it's own without help from rdmd. This would remove the need to invoke the compiler twice, once to find the imports and once to compile. It would also allow some projects/applications that don't use rdmd to take advantage of this feature, this may or may not include dub (not sure on that one).
Re: Compile Imported Modules
On Thu, Aug 24, 2017 at 03:53:05PM +, Jonathan Marler via Digitalmars-d wrote: > Wanted to get peoples thoughts on this. The idea is to have a way to > tell the compiler (probably with a command line option) that you'd > like to "compile imported modules". [...] Isn't this what rdmd already does? T -- Do not reason with the unreasonable; you lose by definition.
Compile Imported Modules
Wanted to get peoples thoughts on this. The idea is to have a way to tell the compiler (probably with a command line option) that you'd like to "compile imported modules". Say you have a program "prog" that depends on modules "foo" and "bar". import foo; import bar; Compilation could look like: dmd prog.d foo.d bar.d Or it could look like dmd -c foo.d dmd -c bar.d dmd prog.d foo.obj bar.obj With this command line option, let's call it "-compile-imports" for now, you could do something like: dmd -compile-imports prog.d This tells the compiler that after it has processed all the input files (source code/object files/library files), if it is missing modules, it should go back and look for those modules in it's list of imported modules, then compile them from there. It's important that it only checks this after processing all the input files so that precompiled modules take precedence. So you could still do something like this: dmd -c foo.d dmd -compile-imports prog.d foo.obj In this example we use the precompiled foo module and then the compiler notices that the bar module is missing. So it looks for the source in it's list of imports, then includes that in it's list of files to compile essentialy behaving as if that file was passed on the command line. This is a simple example with only 2 modules, but for projects that use alot of libraries it could turn into something like this: dmd prog.d -Isomelib somelib\foo\module1.d somelib\foo\module2.d somelib\foo\module3.d somelib\foo\module4.d somelib\foo\module5.d somelib\foo\module6.d -Ianotherlib anotherlib\bar\module1.d anotherlib\bar\module2.d anotherlib\bar\module3.d anotherlib\bar\module4.d anotherlib\bar\module5.d into this: dmd -compile-imports prog.d -Isomelib -Ianotherlib This would also simplify rdmd and make it "less brittle" because it will not need to duplicate the logic inside the compiler that locates and selects which module files to compile. Instead, it can simply use the -compile-imports switch leave that logic completely in the compiler.
Re: What are we going to do about mobile?
On Thursday, 24 August 2017 at 14:28:07 UTC, Joakim wrote: Unfortunately, not everything works great. Like LDC being version 0.14.0 ( 2014! ) on the Pi3 Debian images. And well, "_Unwind_RaiseException failed with reason code: 2128056904", on a simply compile. Not exactly hopeful. Have you tried this more recent build of ldc 1.1.0 (third link in Downloads section at bottom)? https://github.com/ldc-developers/ldc/releases/tag/v1.1.0 Thanks. I checked the 1.3.0 but there was no ARM build. Did not realize there is one for 1.1.0. For anybody finding this using google search, simply do the following to install: wget https://github.com/ldc-developers/ldc/releases/download/v1.1.0/ldc2-1.1.0-linux-armhf.tar.xz sudo tar -C /usr/local -xf ldc2-1.1.0-linux-armhf.tar.xz export PATH=$PATH:/usr/local/ldc2-1.1.0-linux-armhf/bin My code now works correctly again. Doing some benchmarks Apache+PHP vs Go vs D on the Raspberry Pi 3. n=10 c=500 Apache: 1488 seconds Requests per second: 67.20 Go+Gin: 123 seconds Requests per second: 812.23 D: 149 seconds Requests per second: 629.46 D is running a simple socket + limited HTTP 1.0/REST framework that i gobbled together. No optimizations. Go is running a complete HTTP/REST framework so it has more overhead. Apache+PHP5.6 simply suffer beyond belief. Take in account, the D has only been done on a single core! Where all the others used all 4 cores. Impressive even if its not apples to apples comparison.
Re: HTOD
On Thursday, 24 August 2017 at 08:11:52 UTC, Jacob Carlborg wrote: On 2017-08-23 15:25, 12345swordy wrote: "Doesn't translate C++ at all" That's very disappointing. IMO, it should at least aim for the c++ 11 feature via using clang. Pull requests are welcome :). BTW, to my knowledge D doesn't support any features added after C++98/03. They have plans to add c++ support?
Re: @safe(bool)
On Thursday, 24 August 2017 at 01:38:50 UTC, bitwise wrote: On Wednesday, 23 August 2017 at 13:28:37 UTC, 12345swordy wrote: On Wednesday, 23 August 2017 at 02:24:51 UTC, bitwise wrote: [...] Platitudes cause poor language design, not the completely reasonable expectation of good tools. And who is "Platitude" here specifically? http://lmgtfy.com/?q=platitude ;) How about actually answering the question instead of assuming that I can't look up the definition of any words?
Re: What are we going to do about mobile?
On 2017-08-24 12:47, James W Hofmann wrote: Which leads me to a great armchair proposal: D should support Excel spreadsheets ;) Not sure what you had in mind but have a look at: http://forum.dlang.org/post/ubheswgdpafyeyboh...@forum.dlang.org -- /Jacob Carlborg
Re: What are we going to do about mobile?
On Thursday, 24 August 2017 at 10:47:07 UTC, James W Hofmann wrote: I happened across this old thread in a search for "mobile app dlang". I got a Chromebook recently and it represents a substantial phase shift in devices for me: * It's an ARM laptop (Asus Chromebook R13, big.LITTLE 2/2 cores, 4GB memory) * It's also a tablet convertible * The main OS is the web browser * The secondary OS is a Linux desktop(via Crouton) * The other secondary OS is Android(Play Store support) * They all run simultaneously. ChromeOS supports this with minor end-user configuration(hit some secret shortcut keys for developer mode, run a shell script, click some boxes). * It cost under $300 (refurbished) and it's "high end" for the product segment, and feels like it Which means I have ~three software ecosystems(two if you're feeling uncharitable, since all of them can do some web browsing) on the same device, all representing different market segments but more-or-less successfully converged. Although some things like clipboard compatibility aren't in the offing, I can switch between them with shortcut keys and share parts of the file system without any virtualization or rebooting. And "high end mobile" performance covers so many applications that as an individual I can only justify trading up for certain heavy workloads(large code-bases, high-end gaming, some media editing and encoding). If I were feeling daring I could also try running Wine, but that's better left to the x86 Chromebooks. I've been using an Android tablet with four ARMv7 cores and 3 GBs of RAM as my only development hardware for almost two years now. I don't game or edit media, but I've had no problem tweaking and building fairly large codebases like llvm and ldc on the tablet, by using the Termux Android app. I never had a monster desktop with multiple core i7s and 32 GBs of RAM- my last daily driver was a Win7 ultrabook with a core i5 and 4 GBs of RAM- so it's not that much of a difference, even less if I got something newer like you have. It's gotten me thinking that what we're looking at now is really a fully converged computing environment where monopolistic bottlenecks on software platforms are eroded, leaving us back in the position of generic device form factors(type and quantity of I/O, energy efficiency requirements) as the main constraints on the application. So "mobile" may also cease to be a category of substance at the same time as "desktop" and "Web". We'll just have "front-end"/"client", plus some UI forms to cover different devices. What is actually happening is that mobile is killing off both desktop and web (see second graph in first link): http://www.asymco.com/2016/11/02/wherefore-art-thou-macintosh/ https://www.usatoday.com/story/tech/2017/04/12/pc-shipments-dipagain/100347930/ I don't know what you mean by front-end/client, but yeah, we'll probably see even more convergence on a few UI frameworks in the coming years. That won't be the web though. At least, that's where we're going. But it's not "there" yet except in this particular product line, since Google is forcing the issue in it - and the sales figures do suggest that it's carving up the PC category and invading schools everywhere. Another possibility is just using your phone for everything, with a laptop shell like this: https://sentio.com As I noted initially, this is built into the Galaxy S8, one of the top-selling smartphones this year. That thought is playing in my head against recent advertising of BetterC - the USP of "give new life to old code" seems like the most straightforward way to address this future, since if we change our set of assumptions away from "new platforms" in the usual sense of a technology shift provoking boil-the-ocean rewrites, but instead to a continual agglomeration of new into old and old into new, with most shifts occurring within the existing stacks instead of without, then leveraging old code by every means possible becomes the most important thing. As others have pointed out, you could use D with C fairly easily for some time now. You had to be a little careful to initialize the runtime, but that's about it. This betterC effort is to placate those who can't or won't use the GC and a few other runtime features, even though many of them probably could. So while it's good that D will make an effort to replace more C code, I'll also point out that many of the problems with software right now come from precisely this incremental approach. You keep building with mud and straw and eventually it all caves in. It would be nice if D gives a new lease on life to some ancient codebases, but the real potential with D is to build completely new tech that obsoletes the old stuff. To some extent, that is what happened with the mobile shift, where nobody uses Wintel, ie x86 CPUs or Windows, on mobile (though Microsoft is trying again with ARM). Another big sh
Re: Interpolated strings
On Thursday, 24 August 2017 at 11:07:16 UTC, Suliman wrote:
All modern languages like Dart and C# have string
interpolation. Sharp example:
Console.WriteLine($"Hello {args[0]}!");
Who can summary is there any objective reasons why it's not
realized in D?
As Raymond Chen once said[1], because no one implemented it.
That certainly is part of the answer. If you want other
"objective" reasons, there basically are none. It's technically
possible to implement, but D devs haven't found it necessary or
to their liking.
Plenty of reasons for not implementing it have been given in this
thread. You may disagree, in which case I encourage you to write
a DIP and implement it.
--
Biotronic
[1]
https://blogs.technet.microsoft.com/seanearp/2007/04/12/why-doesnt-this-feature-exist/
Re: What are we going to do about mobile?
On Thursday, 24 August 2017 at 10:47:07 UTC, James W Hofmann wrote: I happened across this old thread in a search for "mobile app dlang". I got a Chromebook recently and it represents a substantial phase shift in devices for me: Arm has indeed become a more compelling platform, especially with all the SBC that exist today. Nothing more fun as compiling code on a Pi3 and seeing that little monster working like the big boys ( of course slower ). Unfortunately, not everything works great. Like LDC being version 0.14.0 ( 2014! ) on the Pi3 Debian images. And well, "_Unwind_RaiseException failed with reason code: 2128056904", on a simply compile. Not exactly hopeful. C works great. C++ same. GoLang version 1.3.3 and later perfect. FreePascal totally useless with "An unhandled exception occurred at $00084234". Its interesting to see what languages work and those that bum out with default debian installations. So its a mixed bag on ARM development. But people underestimate how fast the ARM platform is evolving regarding speed. The Pi3 has 4 Armv8 A53 cores but you got now systems like Helion X20 with 2 * A72, 4 * A53 and another 4 * A35... Getting to being only 1/4 then a full blown Intel 7600. All that for a 15W max package. And this year we are getting 10nm X30 with more updated cores. Good times... The PC evolution market in regards to CPU technology has been frankly very dead for the last few years. Small gains each generation but nothing impressive. The only impressing thing has been the AMD Ryzon's that finally pushed 8 cores into consumer hands for a cheap price ( and the thread ripper for 16 for a "reasonable" price, unlike Intel there prices for ages ).
Re: What are we going to do about mobile?
On Thursday, 24 August 2017 at 10:47:07 UTC, James W Hofmann wrote: Which leads me to a great armchair proposal: D should support Excel spreadsheets ;) You say that somewhat in jest but take a look at https://github.com/kaleidicassociates/excel-d
Re: Community Rant
On Wednesday, 23 August 2017 at 23:27:22 UTC, Brad Roberts wrote: On 8/23/2017 3:58 PM, Mark via Digitalmars-d wrote: This kind of criticism comes up fairly often in the forums, maybe once every few weeks. I can link to the recent threads on the matter, but I'm sure you can make an educated guess about the responses therein. The gist of it, in my view, is that: "[Making] D more approachable and attractive to people thinking of picking up the language." just isn't a high priority right now. That's one way to look at it. Another, slightly more accurate and nuanced version is that there are many areas for improvement, and those that are doing work to improve things are doing them in areas they believe are important and useful for their work. That there's not more in the area , that you (and others) believe is important, merely shows that the number that believe is important enough to work on right now is close to zero. That doesn't mean that isn't also important, just that it's not at the top of the priority list for those getting things done. Convince someone that is higher priority than the things they're working on then you might see some movement on those fronts. Or convince yourself that it's important enough to engage in yourself. This isn't really a community level issue so much as a very personal level issue. It's not sufficient for something to be declared a community level priority if no one at the personal level is interested enough to contribute their time. That's the longer version of what I meant to say. I don't think the concept of a community level priority has any meaning in this context- there is no centralized decision making mechanism in the D community. The "priority" I was referring to in my previous post is just a simple average of the personal priorities of language contributors.
Re: Interpolated strings
On Thursday, 24 August 2017 at 11:07:16 UTC, Suliman wrote:
All modern languages like Dart and C# have string
interpolation. Sharp example:
Console.WriteLine($"Hello {args[0]}!");
Who can summary is there any objective reasons why it's not
realized in D?
No one has submitted a DIP for that feature and no one has tried
to implement it. You could be the first one :P
Re: Interpolated strings
All modern languages like Dart and C# have string interpolation.
Sharp example:
Console.WriteLine($"Hello {args[0]}!");
Who can summary is there any objective reasons why it's not
realized in D?
Re: Community Rant
On Wednesday, 23 August 2017 at 18:20:19 UTC, Ali Çehreli wrote: Weka uses D after their CTO Liran's evaluation of a number of programming languages. Liran explains why he chose D and why he still thinks D was the right choice in his a couple of DConf talks. I worked at Weka for a while where I met many wonderful people like Jonathan. Although they were being "forced" to use D, nobody was seriously complaining. :) Now I work with an ex-Weka employee as an ex-Weka employee myself. That other person insisted that he should use D in his piece of the product. Sanity exists... ;) It's great news that such a company with such technology is building it on top of D :) Too bad D doesn't get the free publicity from being in the "technology providers" listing :p only big sexy industry names there...
Re: What are we going to do about mobile?
I happened across this old thread in a search for "mobile app dlang". I got a Chromebook recently and it represents a substantial phase shift in devices for me: * It's an ARM laptop (Asus Chromebook R13, big.LITTLE 2/2 cores, 4GB memory) * It's also a tablet convertible * The main OS is the web browser * The secondary OS is a Linux desktop(via Crouton) * The other secondary OS is Android(Play Store support) * They all run simultaneously. ChromeOS supports this with minor end-user configuration(hit some secret shortcut keys for developer mode, run a shell script, click some boxes). * It cost under $300 (refurbished) and it's "high end" for the product segment, and feels like it Which means I have ~three software ecosystems(two if you're feeling uncharitable, since all of them can do some web browsing) on the same device, all representing different market segments but more-or-less successfully converged. Although some things like clipboard compatibility aren't in the offing, I can switch between them with shortcut keys and share parts of the file system without any virtualization or rebooting. And "high end mobile" performance covers so many applications that as an individual I can only justify trading up for certain heavy workloads(large code-bases, high-end gaming, some media editing and encoding). If I were feeling daring I could also try running Wine, but that's better left to the x86 Chromebooks. It's gotten me thinking that what we're looking at now is really a fully converged computing environment where monopolistic bottlenecks on software platforms are eroded, leaving us back in the position of generic device form factors(type and quantity of I/O, energy efficiency requirements) as the main constraints on the application. So "mobile" may also cease to be a category of substance at the same time as "desktop" and "Web". We'll just have "front-end"/"client", plus some UI forms to cover different devices. At least, that's where we're going. But it's not "there" yet except in this particular product line, since Google is forcing the issue in it - and the sales figures do suggest that it's carving up the PC category and invading schools everywhere. That thought is playing in my head against recent advertising of BetterC - the USP of "give new life to old code" seems like the most straightforward way to address this future, since if we change our set of assumptions away from "new platforms" in the usual sense of a technology shift provoking boil-the-ocean rewrites, but instead to a continual agglomeration of new into old and old into new, with most shifts occurring within the existing stacks instead of without, then leveraging old code by every means possible becomes the most important thing. Which leads me to a great armchair proposal: D should support Excel spreadsheets ;)
Re: Community Rant
On Wednesday, August 23, 2017 16:27:22 Brad Roberts via Digitalmars-d wrote: > On 8/23/2017 3:58 PM, Mark via Digitalmars-d wrote: > > On Tuesday, 22 August 2017 at 15:14:33 UTC, Jonathan Shamir wrote: > >> [...] > >> > >> But lets be honest. If I was just interested to learn about this > >> "modern system programming language" that is C++ done right, I would > >> dismiss D very quickly. We need to get together as a community and > >> rethink your priorities, because with problems like this we're making > >> it very hard for newcomers to trust in this very poorly adapted > >> language. > >> > >> Programming tools used by day to day programmers should be a priority. > >> Because everyone expects valgrind to work. > >> > >> [...] > > > > This kind of criticism comes up fairly often in the forums, maybe once > > every few weeks. I can link to the recent threads on the matter, but I'm > > sure you can make an educated guess about the responses therein. The > > gist of it, in my view, is that: > > > > "[Making] D more approachable and attractive to people thinking of > > picking up the language." > > > > just isn't a high priority right now. > > That's one way to look at it. > > Another, slightly more accurate and nuanced version is that there are > many areas for improvement, and those that are doing work to improve > things are doing them in areas they believe are important and useful for > their work. That there's not more in the area , that you (and > others) believe is important, merely shows that the number that believe > is important enough to work on right now is close to zero. That > doesn't mean that isn't also important, just that it's not at the > top of the priority list for those getting things done. > > Convince someone that is higher priority than the things they're > working on then you might see some movement on those fronts. Or > convince yourself that it's important enough to engage in yourself. > This isn't really a community level issue so much as a very personal > level issue. It's not sufficient for something to be declared a > community level priority if no one at the personal level is interested > enough to contribute their time. Well said. - Jonathan M Davis
Re: HTOD
On 2017-08-23 15:25, 12345swordy wrote: "Doesn't translate C++ at all" That's very disappointing. IMO, it should at least aim for the c++ 11 feature via using clang. Pull requests are welcome :). BTW, to my knowledge D doesn't support any features added after C++98/03. -- /Jacob Carlborg
Re: HTOD
On Thursday, 24 August 2017 at 05:56:02 UTC, Timothee Cour wrote: On Wed, Aug 23, 2017 at 10:38 PM, lobo via Digitalmars-d wrote: On Thursday, 24 August 2017 at 01:51:25 UTC, Timothee Cour wrote: [...] nim: it supports both targetting C++ (as well as C or javascript) and also calling C++ via foreign function interface, eg here are some links: https://github.com/nim-lang/Nim/wiki/Playing-with-CPP--VTABLE-from-Nim https://stackoverflow.com/questions/29526958/wrapping-nested-templated-types-in-nim https://forum.nim-lang.org/t/1056 for D, there's a project to support full C++ natively using clang library is calypso, unfortunalty I haven't been able to use it, either from OSX or ubuntu: it's blocked by https://github.com/Syniurge/Calypso/issues/41, hoping someone can help here! On Wed, Aug 23, 2017 at 3:57 PM, lobo via Digitalmars-d wrote: [...] Thanks, I'll revisit Nim. As a team we're testing new languages as a larger plan to switch from C++. Nim we struck off 6 months ago because we found it not quite production ready. bye, lobo Would love to hear more about your reasoning as I'm also occasionally re-visiting it, do you have any writeup? No write up I can release at this stage because there are some business confidential aspects in the final report. We're ~30 Python, Java and C++ programmers. Our testing involved 1 developer month in each language implementing scripts to parse into data, a basic library read and interpolate data on a 3D regular grid, a small GUI application to display regular grids and tool chain testing where we produced a metric tonne of autogenerated code to see how well we could integrate into our existing build infrastructure and what build times would be like. From memory Nim had four main issues: a) 4 compiler ICEs. Our metric was >2 during testing and it was out, so this alone blew Nim away; we were deliberately harsh. D had 1 ICE that was a known issue with core team member comments on the bug report. b) Nim compilation was slower than other languages (we count the C compilation as part of the same package) c) Our Python devs found Nim was not Pythonic enough compared to other languages for hack n' slash quick scripts while keeping it maintainable and clean. d) Our developers (Python, Java and C++ people) preferred other language syntax bye, lobo
