Re: Dlang 2016 roadmap is over? Look rust roadmap.
On Monday, 31 October 2016 at 03:34:47 UTC, Brian wrote: dlang: http://wiki.dlang.org/Vision/2016H1 rust: https://github.com/aturon/rfcs/blob/roadmap-2017/text/-roadmap-2017.md Or this: http://wiki.dlang.org/Vision/2016H2
Dlang 2016 roadmap is over? Look rust roadmap.
dlang: http://wiki.dlang.org/Vision/2016H1 rust: https://github.com/aturon/rfcs/blob/roadmap-2017/text/-roadmap-2017.md
Re: Fun: Shooting yourself in the foot in D
On 10/30/2016 04:41 PM, captaindet wrote: > ulong toe0 = 2; > shared ulong toe1 = 2; > shared ulong toe2 = 2; > shared ulong toe3 = 2; Those toes are toolong and one is already missing. Make sure that the -boundscheck compiler flag is set. :o) Ali
Re: Fun: Shooting yourself in the foot in D
as i just happened to have me mutilated, i couldn't resist (even though
the example 'works' only with DMD-m64 bullets):
being forced to share your foot among parallel universes, it will surely
find a stray bullet in one of them.
can you guess which toe is going to be blown off?
'''
version(DigitalMars)version(D_LP64){
import std.stdio: writeln;
import core.atomic : atomicOp;
ulong toe0 = 2;
shared ulong toe1 = 2;
shared ulong toe2 = 2;
shared ulong toe3 = 2;
uint bullet1 = 1;
int bullet2 = 1;
ulong bullet3 = 1;
toe0 -= 1;
writeln( "toe0: ", toe0 );
atomicOp!"-="( toe1, bullet1 );
writeln( "toe1: ", toe1 );
atomicOp!"-="( toe2, bullet2 );
writeln( "toe2: ", toe2 );
atomicOp!"-="( toe3, bullet3 );
writeln( "toe3: ", toe3 );
}
( https://issues.dlang.org/show_bug.cgi?id=16651 )
Re: What is the right level of abstractions for D?
Those categories - I am not sure how well they fit. When I learnt to program, C was considered a high level language, and now Swift is considered low level. The world has changed a little, but that isn't my main point. To grow in a healthy way, D doesn't need to think in terms of dominating the world in its totality in a single bound. All that is necessary is to appeal to people around the world in different lines of work who are unhappy with what they have now and are searching for something better, or who know about D but where there is some kind of barrier to adopting it (barriers are not impossible to overcome). It's a big world, and the work of Polanyi and Hayek should remind us that its very difficult to know where users will come from, because that requires a knowledge of time and place that we don't have. But at this size in relation to the total pool of programmers to grow, and Walter's point about listening to your current customers who wish to become bigger ones is a good one. Implicitly in what you wrote is the idea that low level programmers are the ones with real ability, and people who write in Python might be productive, but are of a different level of overall ability. Once that kind of high level / low level mapping to ability might have made sense, but if it's still useful, I think it's much less applicable now. There are plenty of mediocre embedded device programmers, and plenty of people who used to write in C and now write in Python. (I am sure ESR still writes in C, but he write about his love for python some time back). And to call python a scripting language is misleading terminology - conventionally so, but still true - for example, AHL, the large quant money management firm, wrote their risk management systems entirely in Python. You may be an enthusiast of Fisher Black's Noise paper and think that people in money management are fooling themselves, and I am sympathetic to some of that, but my impression is that technically this firm is decent. And everything gets more mixed up when you can compile a Ruby dialect and have it appear at the top of the performance tables. It was a scripting language before, and now it's not? (it's control and level of abstraction rather than performance that distinguishes level of a language, but in the past these things went together). It seems to me you are reifying your class structure of languages when I am not sure it is a good representation of how things are. The reason scripting applications don't use D if it's not already used for other things is libraries and polish. D has great python interoperability and also a nice package manager. Well, try compiling a program as a python library depending on vibed using dub. It won't go very well because the fPIC isn't propagated and you might need to compile in a little C code got the constructors. And what needs to be done isn't completely documented anywhere. So at this point, it's a less appealing proposition because for the people that currently use D, these things don't bother them as much and because it's still a small community with a lot of work to do. John Colvin is working on it, and maybe it will be fixed soon - because it did bother me. But this isn't a consequence of the Platonic essence of D as a language. It's merely contingent on the particular stage of development and it couldn't have been otherwise because you have to get the foundation right before putting sugar on top. The experience of social learning is that every person that follows a course somewhat mysteriously makes it easier for those that follow. It's not only mysterious, because the signposts and guides get better too. D is not an easy language to learn, but even today it's far from exceptionally difficult, and it will get easier with time. If you want a C and C++ ABI, want to have control over memory and to go down to a low level if you need it, but are someone in a position where you need to get stuff done, and don't think modern C++ is the answer, what choices do you have? Not all that many. And I have thought for a while that people were recklessly squandering performance and memory usage. That's not good craftsmanship - it might be necessary to make compromises in a practical situation, but it's hardly something to be proud of, as people almost seem to be. What Knuth said in his paper and speech is not what people take his words out of context to mean, and on the other hand look at the everyday experience of using applications written by people who follow this philosophy to see that there must be something wrong with it. A language really takes off not because of something it started doing that it didn't before, and all of a sudden everything is a success. It takes off when you have the seeds of something, and external conditions change to the point that sudde
Re: State of issues.dlang.org
Am Sat, 29 Oct 2016 17:12:54 + schrieb Jacob : > That doesn't make the point any less valid. If something is broke > you fix it or replace it. I agree with Vladimir and cannot really understand your urge to completely replace it. As long as people don't abuse their editing abilities it can be fine to make a title more specific, add a tag and so on. And the custom views help in getting the desired information out of it. It is extremely flexible in that aspect; more than I would expect from a much more modern and younger project. -- Marco
Re: Linus' idea of "good taste" code
On Sunday, 30 October 2016 at 05:30:04 UTC, Dicebot wrote: On Saturday, 29 October 2016 at 21:46:37 UTC, Laeeth Isharc wrote: Any thoughts on how much work is involved to port the runtime? And what other changes might be involved? The chap that used the C backend for LLVM wrote a little mini runtime but I guess didn't have to worry about the version blocks in the compiler front end as much. (don't recall what architecture he pretended to be compiling to). Glibc has obviously already been ported to run in browser by emscripten. I have actually meant something quite different - implementing new backend for DMD which emits wasm directly (possibly by embedding binaryen). That is more work than simply using LLVM stack as-is but would result in unique marketing advantage - existing pipeline of C -> Emscripten -> asm.js -> asm2wasm is rather annoying. And native wasm backend for LLVM is in development for quite a while now with no clear ETA. At the same time intended wasm spec (https://github.com/WebAssembly/design) is much more simple than machine code for something like x86_64. If Walter gets interested, that may be a feasible path :) Existing pipeline is string together with gaffer tape and string, so it's hardly there yet - and add up that, last I looked, when you turned on O2 with emscripten it didn't always go well. But what I meant was LLVM will have a wasm backend. So on basis of my limited understanding, it would be some work to make LDC produce wasm code, and then runtime and phobos would need work. Adam Ruppe of course had something like this working with plain javascript and dmd about four years back, including basic D wrapping of DOM etc and extern(js). But compiler has diverged a bit from that version used, and I guess at time there wasn't the interest or manpower to turn that experiment /prototype into something one could depend on. But maybe someone would pick it up now more people start to be involved, given that Walter has higher priority things to do. And wouldn't the changes to runtime and phobos be quite similar for both dmd and ldc? I don't see how the work flow would be any different as a language user whether you used an LDC with wasm back end, or dmd with similar. Joakim - native on mobile is so much better (setting aside having to deal with Apple or Google) but I guess the browser isn't going away on the desktop for a while yet.
Re: Having trouble compiling D on Ubuntu 16.10
On Sunday, 30 October 2016 at 11:40:01 UTC, Mike Parker wrote: On Sunday, 30 October 2016 at 11:25:30 UTC, Dechcaudron wrote: Anybody has any idea why this is happening? Is the only solution to downgrade to Ubuntu 16.04 to be able to work in the meantime? Thanks beforehand :) Try adding `-fPIC -defaultlib=libphobos2.so` to your dmd.conf. And see the following links: http://forum.dlang.org/thread/tppsgztsbsdrtkpcb...@forum.dlang.org https://issues.dlang.org/show_bug.cgi?id=5278 Thanks Mike, changing dmd.config did the trick. I'll learn the details from the discussion you linked.
Re: Having trouble compiling D on Ubuntu 16.10
On Sunday, 30 October 2016 at 11:25:30 UTC, Dechcaudron wrote: Anybody has any idea why this is happening? Is the only solution to downgrade to Ubuntu 16.04 to be able to work in the meantime? Thanks beforehand :) Try adding `-fPIC -defaultlib=libphobos2.so` to your dmd.conf. And see the following links: http://forum.dlang.org/thread/tppsgztsbsdrtkpcb...@forum.dlang.org https://issues.dlang.org/show_bug.cgi?id=5278
Having trouble compiling D on Ubuntu 16.10
Hey there community, some weeks ago I upgraded from 16.04 to 16.10, but it wasn't until now that I realized I can't develop with D anymore due to an error in the linking stage of the compilation process. dmd seems to be doing its job just fine, compiling with the -c flag does not produce any warnings or errors that should not be there. But when I move on to the linking stage with the instruction that dmd uses itself: cc app.o -o app -m64 -L/usr/lib/x86_64-linux-gnu -Xlinker --export-dynamic -Xlinker -Bstatic -lphobos2 -Xlinker -Bdynamic -lpthread -lm -lrt -ldl I get a neverending ocean of errors that look pretty much all like these: /usr/bin/ld: app.o: relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(exception_24b_55a.o): relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(exception_24c_3b4.o): relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: /usr/lib/x86_64-linux-gnu/libphobos2.a(exception_24f_4a2.o): relocation R_X86_64_32 against symbol `__dmd_personality_v0' can not be used when making a shared object; recompile with -fPIC Anybody has any idea why this is happening? Is the only solution to downgrade to Ubuntu 16.04 to be able to work in the meantime? Thanks beforehand :)
Re: Linus' idea of "good taste" code
On Sunday, 30 October 2016 at 06:39:42 UTC, Joakim wrote: It is not worth it, the web is dying. I was stunned to see this chart of mobile web usage in the US: https://mobile.twitter.com/asymco/status/777915894659964928 This isn't some third-world country with mostly 2G usage, the web numbers in those places are much worse. Combined with mobile passing even TV for time spent, there is no point in wasting time porting D to a dying platform. Yes, because outside of web on mobile nothing else exists... bwahahahah
