Re: A few notes on choosing between Go and D for a quick project
On Thu, 2015-03-12 at 17:20 -0700, Andrei Alexandrescu via Digitalmars-d wrote: […] > - no good IDE Not entirely true, there are Emacs, VIM, LiteIDE, and others for Go development. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: A few notes on choosing between Go and D for a quick project
On Thu, 2015-03-12 at 20:24 -0700, Walter Bright via Digitalmars-d wrote: […] > > There's no doubt about it, people like simple languages. We should very much > keep that in mind when evaluating proposals for new features. How about lining up some features for removal. C++, Fortran, and Java are big, complicated languages, that keep getting bigger and more complicated because of the obsession with backward compatibility. D is already a big, complicated language. If people like straighforward (not necessarily simple) languages, then the inference is quite easy. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 04:49:38 UTC, Walter Bright wrote: On 3/12/2015 8:40 PM, Joakim wrote: As for "will it be around?," presumably he thinks Go will stick around because of Google. That cuts both ways, because if Google stops funding, maybe Pike and the other main devs abandon it, while D seemingly has never had anyone sponsoring Walter, so there's nobody holding the funding spigot here. Google does abandon significant projects now and then, such as this one: http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html "Google Graveyard" is awesome http://www.slate.com/articles/technology/map_of_the_week/2013/03/google_reader_joins_graveyard_of_dead_google_products.html :)
Re: A few notes on choosing between Go and D for a quick project
On 3/12/2015 8:40 PM, Joakim wrote: As for "will it be around?," presumably he thinks Go will stick around because of Google. That cuts both ways, because if Google stops funding, maybe Pike and the other main devs abandon it, while D seemingly has never had anyone sponsoring Walter, so there's nobody holding the funding spigot here. Google does abandon significant projects now and then, such as this one: http://google-opensource.blogspot.com/2015/03/farewell-to-google-code.html
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu wrote: A friend of mine needed to complete a small project and thought of using a language he didn't know for it. He already knew I work on D so he considered it alongside Go. He ended up choosing the latter, and documented his decision making process in a few notes that he subsequently shared with me. I'll paste below a sort of transcript of his handwritten notes. I think this is valuable information from a relatively unbiased potential user, and good ideas and action items on how we can improve our curb appeal. Even mistaken perceptions are good signal - it means our materials weren't explicit enough to dispel them. * Golang: simple! + very small language, very concise & simple + playground/tutorial + easy to start using it, no-nonsense + vast libraries + no inheritance + one binary to distribute + good for servers + feels like a better C (mostly) - can't write generic code involving arrays/slices - no good IDE + Google! + clear feeling it's here to stay + visible, many projects + enforced style (indentation, exports) * Dlang: big! # big language # IDE? # small subset? # libraries? # will it be around? # Perception matters ## how stable is it? ## not great for servers or UIs; what then? ## new house in unpopulated neighborhood; there's an "Enter, it's open" sign but sits emtpy; by comparison Go -> condo in hip, trendy area When you said "curb appeal," I was prepared to read how a cursory look at both websites turned him off on D and on to Go. But none of these qualities can be determined so easily, you have to look around for a while to know that D is bigger and Go is considered "hip, trendy" compared to a supposedly "unpopulated" D. Comparing the front pages of the respective language websites, dlang.org does a good job of actually introducing the language, while golang.org simply says "Go is an open source programming language that makes it easy to build simple, reliable, and efficient software." That's it. You have to click a couple times to actually get to the Go tour or manual and find out what Go is: there's no pitch to sell you the language first. The recent dlang.org redesign seems to have done a good job of simplifying the front page, including the addition of the previously unavailable "Getting Started" option. Of course, the front page of dlang.org is not as spare and pretty as golang.org, will still take a designer to spiff it up a bit. As to his actual points, it seems to come down to D replaces C++, while Go replaces C. If you're looking for a better C, the more advanced, C++-esque features of D might distract and confuse you, even though you can ignore those and use it that way. As for "will it be around?," presumably he thinks Go will stick around because of Google. That cuts both ways, because if Google stops funding, maybe Pike and the other main devs abandon it, while D seemingly has never had anyone sponsoring Walter, so there's nobody holding the funding spigot here. Not sure why he thinks D isn't good for servers, as that's what its key corporate backers all use it for. I don't deny that some of these perceptions exist, not sure how being considered "hip, trendy" is combated other than by having more success. * Ideas for D # what C++ should be but cannot ## too late for C++, but not for D ## some or all of @safe, immutable, pure should be the default # libraries, projects should be prominently listed and nurtured Good suggestion for the front page, perhaps a library of the month? # single-idea advantage; D seems to embody too many ideas at once ## concurrency? ## networking? Where is D advertised as being special or different with its ideas on networking? I don't see it. ## generics? ## interoperability with C and C++? ## focus on one! That's not D's approach, for better or worse. It's offering a buffet of features, not just a great steak. # must attract/hook casual users I agree that D's use in small programs and scripting could be better emphasized. In trying to attract the C++ crowd, this orthogonal audience is sometimes ignored. # unclear what's a good IDE - JetBrains? is there Vim support? The D Wiki lists supported IDEs, maybe the "Getting Started" page should directly link there. # what's D's equivalent to frameworks such as react.js? # language designers think of features, users think of purpose ## react, go, rust, java -> purpose React is a UI framework, easy to state its purpose. Go has essentially nothing on their front page, while Rust just has a feature list. Java is the only one that talks about rationale and purpose: https://www.java.com/en/about/ ## D, C++ -> "Ivy league candidates" having a response for every programming language design challenge there is, but less focused on purpose (Andrei's note: I assume D more at fault than C++ on this) I agree that dlang.org could
Re: A few notes on choosing between Go and D for a quick project
On 3/12/2015 5:20 PM, Andrei Alexandrescu wrote: * Golang: simple! D1 was the simple version of D. People wanted more. Java was originally sold as, and got a great of adoption because, it was a C++ like language with all that annoying complexity removed. There's no doubt about it, people like simple languages. We should very much keep that in mind when evaluating proposals for new features.
Re: dmd 2.066.1 cannot build phobos 2.066.1
"Vladimir Panteleev" wrote in message news:tlocllgihbddloqla...@forum.dlang.org... What Git version are you using? "git clone --branch" learned to work with tags in Git v1.7.10. Yeah, it was 1.7.1.
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 02:17:31 UTC, bearophile wrote: A "strict D" mode? That sounds like an amazing idea.
Re: A few notes on choosing between Go and D for a quick project
I made a choice between Go and D in 2013. I started with Go and was very happy when I switched to D. The languages appeal to different users. This is how I interpreted some of the "advantages" of Go: + very small language, very concise & simple A limited, inflexible language + feels like a better C (mostly) Feels like C + enforced style (indentation, exports) Ridiculously restricted for no reason other than developer arrogance. # big language An intuitive language that actually does things. General feeling: "I don't feel smart enough for D and am looking for a quick way to accomplish a goal. If you want to be Rob Pike Jr., Go is great. If you want to program your way, not so much. For someone coming from a Lisp background but wanting a better C, Go had very little appeal. Bottom line: Emphasize the different philosophies of Go and D.
Re: A few notes on choosing between Go and D for a quick project
Andrei Alexandrescu: ## some or all of @safe, immutable, pure should be the default +1 I have a ER on @safe by default and Walter seems to agree. But I'd like more. A "strict D" mode? :-) # libraries, projects should be prominently listed and nurtured # single-idea advantage; D seems to embody too many ideas at once ## concurrency? ## networking? ## generics? ## interoperability with C and C++? ## focus on one! D can't be a single-purpose language. And it has more moving parts compared to Go. Bye, bearophile
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 02:17:31 UTC, bearophile wrote: D can't be a single-purpose language. Yeah. The other side of the coin is that, from a D user's perspective, Go and Rust are one-trick ponies.
Re: dmd 2.066.1 cannot build phobos 2.066.1
On Friday, 13 March 2015 at 00:15:32 UTC, Daniel Murphy wrote: "Andrei Alexandrescu" wrote in message news:mdt2mj$8gc$1...@digitalmars.com... I wonder how this could have happened. Here's what I did: git clone --quiet -b v2.066.1 --depth=1 git://github.com/D-Programming-Language/dmd.git dmd-2.066.1 None of these clone commands work for me, I get: "warning: Remote branch v2.066.1 not found in upstream origin, using HEAD instead" What Git version are you using? "git clone --branch" learned to work with tags in Git v1.7.10.
Re: A few notes on choosing between Go and D for a quick project
On Friday, 13 March 2015 at 00:20:40 UTC, Andrei Alexandrescu wrote: I'd love us to derive a few action items from this and other feedback. I think the front page focuses too much on the language itself at the moment. Perhaps we should continue with the direction with forum integration, and devote a good piece of real estate for the ecosystem (e.g. latest code.dlang.org updates) and maybe an IDE screenshot carousel, OSLT. Making it up-front that we have three compilers, a built-in profiler, and tight GDB integration might also be worthwhile.
Re: dmd 2.066.1 cannot build phobos 2.066.1
"Andrei Alexandrescu" wrote in message news:mdteff$hdf$2...@digitalmars.com... More info: this is a fresh VM with Ubuntu 14.04. I've installed a number of tools with apt-get including gdc. There is no dmd installation. git is version 1.9.1. -- Andrei Hmm. What are the commit hashes for dmd, druntime and phobos?
Re: dmd 2.066.1 cannot build phobos 2.066.1
More info: this is a fresh VM with Ubuntu 14.04. I've installed a number of tools with apt-get including gdc. There is no dmd installation. git is version 1.9.1. -- Andrei
Re: dmd 2.066.1 cannot build phobos 2.066.1
On 3/12/15 5:44 PM, Daniel Murphy wrote: "Andrei Alexandrescu" wrote in message news:mdtb6c$f2f$1...@digitalmars.com... Could that be because our default remotes are different (e.g. yours is your own fork)? -- Andrei I don't think so, but it could be because I've got an older version of git. I took a quick look at the 2.066.1 tag on github, and it doesn't look like there's any mention of -conf in phobos' posix.mak (https://github.com/D-Programming-Language/phobos/blob/c8fccac8c20a3bdd6300128f610267a24d42473f/posix.mak) Do you maybe have it in an environment variable or dmd.conf that's getting picked up? Wait, so aren't we discussing a git-specific thing? (Anyhow I don't have an active dmd.conf. It's a fresh VM.) -- Andrei
Re: dmd 2.066.1 cannot build phobos 2.066.1
"Andrei Alexandrescu" wrote in message news:mdtb6c$f2f$1...@digitalmars.com... Could that be because our default remotes are different (e.g. yours is your own fork)? -- Andrei I don't think so, but it could be because I've got an older version of git. I took a quick look at the 2.066.1 tag on github, and it doesn't look like there's any mention of -conf in phobos' posix.mak (https://github.com/D-Programming-Language/phobos/blob/c8fccac8c20a3bdd6300128f610267a24d42473f/posix.mak) Do you maybe have it in an environment variable or dmd.conf that's getting picked up?
Re: dmd 2.066.1 cannot build phobos 2.066.1
On 3/12/15 5:15 PM, Daniel Murphy wrote: "Andrei Alexandrescu" wrote in message news:mdt2mj$8gc$1...@digitalmars.com... I wonder how this could have happened. Here's what I did: git clone --quiet -b v2.066.1 --depth=1 git://github.com/D-Programming-Language/dmd.git dmd-2.066.1 None of these clone commands work for me, I get: "warning: Remote branch v2.066.1 not found in upstream origin, using HEAD instead" Could that be because our default remotes are different (e.g. yours is your own fork)? -- Andrei
A few notes on choosing between Go and D for a quick project
A friend of mine needed to complete a small project and thought of using a language he didn't know for it. He already knew I work on D so he considered it alongside Go. He ended up choosing the latter, and documented his decision making process in a few notes that he subsequently shared with me. I'll paste below a sort of transcript of his handwritten notes. I think this is valuable information from a relatively unbiased potential user, and good ideas and action items on how we can improve our curb appeal. Even mistaken perceptions are good signal - it means our materials weren't explicit enough to dispel them. * Golang: simple! + very small language, very concise & simple + playground/tutorial + easy to start using it, no-nonsense + vast libraries + no inheritance + one binary to distribute + good for servers + feels like a better C (mostly) - can't write generic code involving arrays/slices - no good IDE + Google! + clear feeling it's here to stay + visible, many projects + enforced style (indentation, exports) * Dlang: big! # big language # IDE? # small subset? # libraries? # will it be around? # Perception matters ## how stable is it? ## not great for servers or UIs; what then? ## new house in unpopulated neighborhood; there's an "Enter, it's open" sign but sits emtpy; by comparison Go -> condo in hip, trendy area * Ideas for D # what C++ should be but cannot ## too late for C++, but not for D ## some or all of @safe, immutable, pure should be the default # libraries, projects should be prominently listed and nurtured # single-idea advantage; D seems to embody too many ideas at once ## concurrency? ## networking? ## generics? ## interoperability with C and C++? ## focus on one! # must attract/hook casual users # unclear what's a good IDE - JetBrains? is there Vim support? # what's D's equivalent to frameworks such as react.js? # language designers think of features, users think of purpose ## react, go, rust, java -> purpose ## D, C++ -> "Ivy league candidates" having a response for every programming language design challenge there is, but less focused on purpose (Andrei's note: I assume D more at fault than C++ on this) General feeling: "I don't feel smart enough for D and am looking for a quick way to accomplish a goal. I've read the Wikipedia article on D and didn't understand a few things. The examples seem to show off the language but that made them confusing. I wanted to get more into it, but by that time Go had already won - I looked at the tutorials, changed the sample code a bit right in the browser to see how it'd work for me, it was easy, I was in already. Some of my comments therefore illustrate my shortcomings than the language's, but that's true one way or another for all programmers (that's why technical superiority of a language doesn't guarantee its success)." === I'd love us to derive a few action items from this and other feedback. Andrei
Re: dmd 2.066.1 cannot build phobos 2.066.1
"Andrei Alexandrescu" wrote in message news:mdt2mj$8gc$1...@digitalmars.com... I wonder how this could have happened. Here's what I did: git clone --quiet -b v2.066.1 --depth=1 git://github.com/D-Programming-Language/dmd.git dmd-2.066.1 None of these clone commands work for me, I get: "warning: Remote branch v2.066.1 not found in upstream origin, using HEAD instead"
Re: Standard GUI framework inspired by Qt
I'm unsure of the "gamma" space, Adobe should be enough to cover things (the curve is practically identical). Still, they are different at 0xA7 and 0xBE, so maybe useful for some files. GPUs and every non-specialized monitor only do sRGB<->linear. So, all's good with that pull request, just "gamma" might be useless and confusing.
dmd 2.066.1 cannot build phobos 2.066.1
I wonder how this could have happened. Here's what I did: git clone --quiet -b v2.066.1 --depth=1 git://github.com/D-Programming-Language/dmd.git dmd-2.066.1 git clone --quiet -b v2.066.1 --depth=1 git://github.com/D-Programming-Language/druntime.git druntime-2.066.1 git clone --quiet -b v2.066.1 --depth=1 git://github.com/D-Programming-Language/phobos.git phobos-2.066.1 After this I had three nice directories. Then I built dmd, it worked. Then I built druntime making sure I pass DMD=../dmd-2.066.1/src/dmd in make's command line. That worked, too. When I built phobos I got: Error: unrecognized switch '-conf=' How did it happen that the -conf= flag is required by phobos 2.066.1 yet was not implemented in the same version of dmd? Thanks, Andrei
Re: Standard GUI framework inspired by Qt
On Tuesday, 10 March 2015 at 01:25:05 UTC, karl wrote: Please don't use SDL2 and such as basis, or OpenGL with glBegin+glReadPixels without FBOs and PBOs (not Pbuffers). I'm a GL driver dev (userspace) for a smaller company, and I see too much gore in popular software like that (gnome3 is the most-horrific). A fully-featured GUI with GL needs only a thin wrapper for glXGetProcAddress, GL context creation, BitBlt-like things and font-glyph cache (or better yet, signed-distance-field text rendering). Something like this: Base (sans clipping, I haven't ported it from asm yet): https://github.com/idinev/pub_toys/tree/master/Blitters/oDraw SDF text: https://www.mapbox.com/blog/text-signed-distance-fields/ Also, GL should be optional, just like with Qt; it introduces noticeable lag of 16 to 48ms while being a resource hog unnecessary for most apps. I could help with implementing the abstraction layer and create a software blitter (I was professionally doing such stuff before, for GUI toolkits and stuff; but then again this stuff is trivial). A 32-bit backing-store is always vital (DDB+GDI dibsection, GL texture and such). Qt has it (and implemented really-well) and that's the first pixel-related thing we should implement. BGRA8 will be the best format (blue in LSB). A 9-cell blit will also be vital functionality. @karl Can you check the proposal of the new color module by Manu? https://github.com/D-Programming-Language/phobos/pull/2845 Do you see any issues there? Piotrek
Re: YOW 2014 talk on D now online
Great talk. This is what i found most interesting: Andrei @ 12:52: "It doesn't have a large corporate sponsor at the moment, but that's due to change." Oooo. Any more information on this?
Re: YOW 2014 talk on D now online
On 3/12/15 1:03 PM, CraigDillabaugh wrote: On Thursday, 12 March 2015 at 17:08:08 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/2yt1ek/andrei_alexandrescu_on_d_at_yow2014_local_imports/ https://twitter.com/D_Programming/status/576066527155367936 https://www.facebook.com/dlang.org/posts/1031487990198215 Andrei Gary beat you to it by 1 hour! http://forum.dlang.org/thread/ionjnsvqcplgxuoip...@forum.dlang.org Not to mention he posted in the right forum. -- Andrei
Re: YOW 2014 talk on D now online
On Thursday, 12 March 2015 at 17:08:08 UTC, Andrei Alexandrescu wrote: http://www.reddit.com/r/programming/comments/2yt1ek/andrei_alexandrescu_on_d_at_yow2014_local_imports/ https://twitter.com/D_Programming/status/576066527155367936 https://www.facebook.com/dlang.org/posts/1031487990198215 Andrei Gary beat you to it by 1 hour! http://forum.dlang.org/thread/ionjnsvqcplgxuoip...@forum.dlang.org
YOW 2014 talk on D now online
http://www.reddit.com/r/programming/comments/2yt1ek/andrei_alexandrescu_on_d_at_yow2014_local_imports/ https://twitter.com/D_Programming/status/576066527155367936 https://www.facebook.com/dlang.org/posts/1031487990198215 Andrei
Re: Targeting Vulkan and SPIR-V
On 12 March 2015 at 15:57, John Colvin via Digitalmars-d wrote: > On Saturday, 7 March 2015 at 02:18:22 UTC, Iain Buclaw wrote: >> >> On 6 Mar 2015 23:30, "Joakim via Digitalmars-d" >> >> wrote: >>> >>> >>> The ground-up redesign of OpenGL, now called Vulkan, has been announced >> >> at GDC: >>> >>> >>> http://www.phoronix.com/scan.php?page=article&item=khronos-vulcan-spirv >>> >>> Both graphics shaders and the latest verson of OpenCL, which enables >> >> computation on the GPU, will target a new IR called SPIR-V: >>> >>> >>> >> >> http://www.anandtech.com/show/9039/khronos-announces-opencl-21-c-comes-to-opencl >>> >>> >>> Rather than being forced to use C-like languages like GLSL or OpenCL in >> >> the past, this new IR will allow writing graphics shaders and OpenCL code >> using any language, including a subset of C++14 stripped of exceptions, >> function pointers, and virtual functions. >>> >>> >>> This would be a good opportunity for D, if ldc or gdc could be made to >> >> target SPIR-V. Ldc would seem to have a leg up, since SPIR was originally >> based on LLVM IR before diverging with SPIR-V. >> >> Unlike LDC, GDC doesn't need to be *made* to target anything. It's IR is >> high level enough that you don't need to think (nor care) about your >> backend target. >> >> GCC itself will need a backend to support it though. ;) >> >> Iain > > > Relevant: https://gcc.gnu.org/ml/gcc/2015-03/msg00020.html David is an awesome guy. Would be great if he picks up the baton on this. I reckon most things would be hashed out via GCC builtins, in which someone writes a library for.
Re: Post increment and decrement
On 12/03/2015 10:14, monarch_dodra wrote: On Wednesday, 11 March 2015 at 17:23:15 UTC, welkam wrote: Observation Nr. 1 People prefer to write var++ instead of ++var. The root of your reasoning stems from this "observation", which I argue is wrong. The recommendation has always been to chose ++var, unless you have a reason to chose var++. Where the result is not needed, var++ is probably more common. I'd rather read post-increments. Grep -c phobos for simple for loops: ; word++): etc/c/zlib/crc32.c:9 etc/c/zlib/deflate.c:1 etc/c/zlib/gzwrite.c:2 etc/c/zlib/inftrees.c:6 etc/c/zlib/trees.c:25 etc/c/zlib/zutil.c:2 std/algorithm.d:2 std/bitmanip.d:5 std/concurrency.d:1 std/container/rbtree.d:2 std/digest/md.d:1 std/digest/ripemd.d:1 std/digest/sha.d:2 std/math.d:3 std/parallelism.d:1 std/path.d:2 std/random.d:1 std/regex/internal/backtracking.d:3 std/regex/internal/ir.d:1 std/regex/internal/kickstart.d:5 std/regex/internal/parser.d:2 std/regex/internal/tests.d:1 std/regex/package.d:1 std/socket.d:8 std/stream.d:1 std/string.d:2 std/uni.d:18 std/uri.d:11 std/utf.d:3 std/uuid.d:2 std/windows/charset.d:1 std/zip.d:2 std/zlib.d:3 unittest.d:1 ; ++word): std/algorithm.d:8 std/bitmanip.d:1 std/encoding.d:7 std/format.d:4 std/internal/math/biguintcore.d:9 std/internal/math/biguintnoasm.d:17 std/internal/math/biguintx86.d:14 std/internal/math/gammafunction.d:2 std/math.d:1 std/numeric.d:2 std/process.d:3 std/random.d:3 std/stream.d:2 std/utf.d:1 std/windows/registry.d:4 std/xml.d:1
Re: DIP75 - Release Process
On Thursday, 12 March 2015 at 07:44:01 UTC, Jacob Carlborg wrote: On 2015-03-11 17:27, Anon wrote: Ignoring that for a moment, where does it stop? Do we include an editor? [sarcasm] Why not? Every D developer needs to edit their code! Let's go ahead and call Eclipse+DDT the "standard" D editor, and bundle that with dmd. [/sarcasm] I don't see why not. Both Microsoft and Apple ship an IDE with their SDK's. The SDKs ship with Visual Studio, not the other way around. Both the Windows SDK and .NET Framework/SDK are separate products. The .NET Framework itself includes the .NET compiler, which Visual Studio uses, and the Windows SDK includes cl.exe which is the C/C++ compiler. Neither require Visual Studio. It's good to have a single installer that includes everything you need to get started (dmd, dub, IDE / IDE plugin) like Visual Studio is (cl/csc, Nuget, VS), but the compiler itself should definitely not ship with an IDE.
Re: Targeting Vulkan and SPIR-V
On Saturday, 7 March 2015 at 02:18:22 UTC, Iain Buclaw wrote: On 6 Mar 2015 23:30, "Joakim via Digitalmars-d" wrote: The ground-up redesign of OpenGL, now called Vulkan, has been announced at GDC: http://www.phoronix.com/scan.php?page=article&item=khronos-vulcan-spirv Both graphics shaders and the latest verson of OpenCL, which enables computation on the GPU, will target a new IR called SPIR-V: http://www.anandtech.com/show/9039/khronos-announces-opencl-21-c-comes-to-opencl Rather than being forced to use C-like languages like GLSL or OpenCL in the past, this new IR will allow writing graphics shaders and OpenCL code using any language, including a subset of C++14 stripped of exceptions, function pointers, and virtual functions. This would be a good opportunity for D, if ldc or gdc could be made to target SPIR-V. Ldc would seem to have a leg up, since SPIR was originally based on LLVM IR before diverging with SPIR-V. Unlike LDC, GDC doesn't need to be *made* to target anything. It's IR is high level enough that you don't need to think (nor care) about your backend target. GCC itself will need a backend to support it though. ;) Iain Relevant: https://gcc.gnu.org/ml/gcc/2015-03/msg00020.html
Re: DIP75 - Release Process
On Thursday, 12 March 2015 at 07:44:01 UTC, Jacob Carlborg wrote: On 2015-03-11 17:27, Anon wrote: Ignoring that for a moment, where does it stop? Do we include an editor? [sarcasm] Why not? Every D developer needs to edit their code! Let's go ahead and call Eclipse+DDT the "standard" D editor, and bundle that with dmd. [/sarcasm] I don't see why not. Both Microsoft and Apple ship an IDE with their SDK's. That's an IDE that includes a compiler, not a compiler that includes an IDE. You aren't downloading cl, you're downloading VisualStudio. That you also get cl is an implementation detail. If Bruno wanted to release a build of Eclipse+DDT that came with a compiler, I'd have no problem with that.
Re: Smart references
On Wednesday, 11 March 2015 at 20:33:07 UTC, Andrei Alexandrescu wrote: #70: Attempting to copy a reference fails on account of the disabled postblit. There should be a way to tell the compiler to automatically invoke alias this and create a copy of that guy. #81: Moving from a reference works by moving the Ref object. There should be a way to tell the compiler that moving should really move the payload around. I suspect this will work automatically if #70 does.
Re: Post increment and decrement
On Wednesday, 11 March 2015 at 17:23:15 UTC, welkam wrote:
Because of all this why not make only one increment/decrement
operator and have post increment/decrement to be called by
template name, because it is a template?
template post_inc(T) {
auto tmp = T;
T++;
return tmp;
}
That's how it works
http://dlang.org/operatoroverloading.html#unary
But I see more optimization opportunity here: the result of ++a
may be not used too, but it still returns the value, which can be
still suboptimal.
Re: Post increment and decrement
On Wednesday, 11 March 2015 at 17:23:15 UTC, welkam wrote: Observation Nr. 1 People prefer to write var++ instead of ++var. The root of your reasoning stems from this "observation", which I argue is wrong. The recommendation has always been to chose ++var, unless you have a reason to chose var++. Because of all this why not make only one increment/decrement operator and have post increment/decrement to be called by template name, because it is a template? Or, instead of creating a new semantic, simply use the existing one. It really isn't that complicated.
Re: [WORK] [IMPORTANT] [URGENT] ddox generation
On 3/10/2015 10:27 PM, Walter Bright wrote: While we're at it: http://dlang.org/ Note that there are no navigation links to the "how to use dmd" pages, like: http://dlang.org/dmd-windows.html These used to be there, but have vanished at some point in the last couple months. This is embarrassingly awful. https://issues.dlang.org/show_bug.cgi?id=14280 Who wants to take this on?
Re: DIP75 - Release Process
On Wednesday, 11 March 2015 at 07:19:57 UTC, Vladimir Panteleev wrote: What is indubitably, actually, very important, and something I'm surprised you haven't pushed for since long ago, is making it EASY to get more things. Dub absolutely must be a part of D, and not today but one or more years ago. There is now a rift in this community, between people who use code.dlang.org and its packages, and those who do not. And those of us who don't use dub are *not* going to magically start using dub just because it is bundled with dmd. I don't use dub because it doesn't benefit me in any way, and really only gets in my way. Coming from a language with a package manager, and then trying to build a project with a dozen dependencies by manually cloning the repositories and making sure they are the correct version, is madness. A package manager encourages people to build many small reusable components, because the overhead of managing each component becomes very small, and this is something we really want. And any package manager that only operates in source, demands a central repository (that effectively just redirects to the actual Git repos), and only works for one language is utterly worthless for real world projects. Not to mention, putting extra tools like dustmite and dub in dmd will only ever benefit dmd users, not those of us who use ldc or gdc. Ignoring that for a moment, where does it stop? Do we include an editor? [sarcasm] Why not? Every D developer needs to edit their code! Let's go ahead and call Eclipse+DDT the "standard" D editor, and bundle that with dmd. [/sarcasm]
Link in the changelog broken
Hey, when clicking "Change Log" on the dlang.org it already says "Version D 2.067 Mar 1, 2015" even tho big number on the left menu says "2.066.1. Regardless if this is desired (even if confusing) the link embedded at this header is broken.
Re: Post increment and decrement
On 12/03/2015 9:12 p.m., Don wrote:
On Thursday, 12 March 2015 at 04:06:14 UTC, Rikki Cattermole wrote:
On 12/03/2015 1:50 p.m., Andrei Alexandrescu wrote:
On 3/11/15 10:23 AM, welkam wrote:
Observation Nr. 1
People prefer to write var++ instead of ++var.
Observation Nr. 2
Because of observation Nr. 1 and other reasons compilers became good at
removing code that is not needed making var++ and ++var to produce the
same code if returned value is not used.
Observation Nr. 3
Because of observation Nr. 2 more people use var++ in place where they
really only need ++var.
Observation Nr. 4
Because of observation Nr. 3 people learning to program may mistakenly
learn that var++ is just incrementing. (I am included in that list)
Observation Nr. 5
Because of observation Nr. 4 people can write slower than necessary
code
for classes with overloaded operator or even get bugs.
Because of all this why not make only one increment/decrement operator
and have post increment/decrement to be called by template name,
because
it is a template?
template post_inc(T) {
auto tmp = T;
T++;
return tmp;
}
Observation Nr. 6
Somebody didn't Read The Fine Manual. Page 369:
=
If the result of a++ is not needed, the rewrite is ++a, which is
subsequently rewritten to a.opUnary!"++"().
=
Andrei
+1
Compiler should work for you. This is one of those things it can
rewrite to preference. During optimization.
It doesn't even rely on the optimizer. This happens in the front-end, in
the semantic pass.
In our implementation yes. But I'm emphasizing it doesn't have to.
Re: DIP75 - Release Process
On Wednesday, 11 March 2015 at 08:57:14 UTC, Rikki Cattermole wrote: On 11/03/2015 9:00 p.m., Vladimir Panteleev wrote: On Wednesday, 11 March 2015 at 07:32:48 UTC, Andrei Alexandrescu wrote: It doesn't seem so to me. You find easy weaknesses in my vision and pump on them instead of working on making it stronger. That's the easy "but that business won't work, and here are the reasons why" approach. The harder part is finding ways to make it work by overcoming its weaknesses. Here is a counter-proposal: 1. Add Dub to D. 2. Add a "web development" link in the sidebar, which simply links to vibed.org. 3. Add an example on the front page on how to create a simple web server. It needs to list only main.d and package.json, and the dub command line to build it. A package.json will be needed for non-trivial things anyway, so might as well get that out of the way anyway. 4. Unite the Vibe.d forum with forum.dlang.org. I should be able to do this by making forum.dlang.org connect to it via NNTP. I think this will achieve much of your goal without the drawbacks. I would like to add putting focus on getting libasync[0] phobos ready instead of the vibe.d direction. It might be a lot younger, but it is also have a lot smaller scope. Perhaps even a rewrite of std.socket to use it? It is a lot of work, but its probably a more manageable unit of work in the short term. [0] https://github.com/etcimon/libasync +10!!! and yes, we are using vibe.d in production, but libasync also. --- Paolo
Re: Post increment and decrement
On Thursday, 12 March 2015 at 04:06:14 UTC, Rikki Cattermole
wrote:
On 12/03/2015 1:50 p.m., Andrei Alexandrescu wrote:
On 3/11/15 10:23 AM, welkam wrote:
Observation Nr. 1
People prefer to write var++ instead of ++var.
Observation Nr. 2
Because of observation Nr. 1 and other reasons compilers
became good at
removing code that is not needed making var++ and ++var to
produce the
same code if returned value is not used.
Observation Nr. 3
Because of observation Nr. 2 more people use var++ in place
where they
really only need ++var.
Observation Nr. 4
Because of observation Nr. 3 people learning to program may
mistakenly
learn that var++ is just incrementing. (I am included in that
list)
Observation Nr. 5
Because of observation Nr. 4 people can write slower than
necessary code
for classes with overloaded operator or even get bugs.
Because of all this why not make only one increment/decrement
operator
and have post increment/decrement to be called by template
name, because
it is a template?
template post_inc(T) {
auto tmp = T;
T++;
return tmp;
}
Observation Nr. 6
Somebody didn't Read The Fine Manual. Page 369:
=
If the result of a++ is not needed, the rewrite is ++a, which
is
subsequently rewritten to a.opUnary!"++"().
=
Andrei
+1
Compiler should work for you. This is one of those things it
can rewrite to preference. During optimization.
It doesn't even rely on the optimizer. This happens in the
front-end, in the semantic pass.
Re: DIP75 - Release Process
On 2015-03-11 17:27, Anon wrote: Ignoring that for a moment, where does it stop? Do we include an editor? [sarcasm] Why not? Every D developer needs to edit their code! Let's go ahead and call Eclipse+DDT the "standard" D editor, and bundle that with dmd. [/sarcasm] I don't see why not. Both Microsoft and Apple ship an IDE with their SDK's. -- /Jacob Carlborg
