Re: D for the Win
On Wednesday, 20 August 2014 at 21:43:26 UTC, Walter Bright wrote: On 8/20/2014 2:33 PM, anonymous wrote: Dlang Dlang Über Alles as a German, O_O I'm not surprised that the German programming community has taken to D. After all, German cars all have those D stickers on them :-) French must be such great fans of functional programming, on the other hand. F# anyone?
Re: D 2.066 is out. Enjoy!
On Thursday, 21 August 2014 at 01:30:52 UTC, ketmar via Digitalmars-d-announce wrote: On Wed, 20 Aug 2014 10:18:09 -0700 Andrei Alexandrescu via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: What is it that we could help with? -- Andrei he's drama queen, he doesn't need any help, only attention. Just let's try to be less harsher. Even if that's true, being harsh would be of no good for that person and for us neither.
Re: D for the Win
On Wednesday, 20 August 2014 at 22:02:31 UTC, anonymous wrote: On Wednesday, 20 August 2014 at 21:43:26 UTC, Walter Bright wrote: On 8/20/2014 2:33 PM, anonymous wrote: Dlang Dlang Über Alles as a German, O_O I'm not surprised that the German programming community has taken to D. After all, German cars all have those D stickers on them :-) No, no, Dlang Dlang Über Alles is a take on Deutschland Deutschland über alles (Germany Germany over everything), the first verse of the national anthem as sung in Nazi times. While I agree with the historical significance, there are some things to be straighten: 1) the song was used even before: it was the national anthem of the Weimar republic, the one that Nazi toppled 2) today, it's third stanza (the first one begins with DDuA) is still the official anthem of Deutschland 3) there is no official interdiction of the first two stanzas, except that they are not really protected by the German law punishing offenses to the national symbols of Germany
Re: D 2.066 is out. Enjoy!
On 20/08/14 18:57, Brad Anderson wrote: Anything specific you have problems with? Syntax changes aren't all that common these days Support for C++ namespaces where just released and support for C++ templates will most likely end up in master soon. -- /Jacob Carlborg
Re: D for the Win
On 8/20/2014 5:39 PM, Peter Alexander wrote: Ha, that opDollar thing in the HTML generator is the nastiest D hack I've seen :-P Yea, this *statement* really made me go o_O link[$.rel = foobar, $.type = text/css]; That's a lot of syntax abuse there! Still, if it works for him, great, who am I to complain? At the end of the day, it's just a tool.
Re: D for the Win
On 8/20/2014 6:57 PM, Paulo Pinto wrote: Am 21.08.2014 00:02, schrieb anonymous: No, no, Dlang Dlang Über Alles is a take on Deutschland Deutschland über alles (Germany Germany over everything), the first verse of the national anthem as sung in Nazi times. I was actually worried if the author is German. He's not, thankfully. He's from Israel. From a German author that would be an embracement of fascism. Coming from an Israeli, I don't really know where to put it, probably completely benign. As a Portuguese living in Germany, I would say not everyone knows that outside Germany. Specially the younger generations, they just use it because it sounds cool. Über Alles always just makes me think of Hanzel und Gretyl: http://en.wikipedia.org/wiki/%C3%9Cber_Alles_%28album%29 Gotta love tongue-in-cheek psuedo-German metal ;)
Re: D for the Win
On Thu, 21 Aug 2014 04:31:31 -0400 Nick Sabalausky via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Yea, this *statement* really made me go o_O link[$.rel = foobar, $.type = text/css]; That's a lot of syntax abuse there! but it's fun! we all used to think that $ should mean 'length' and he has no such mind frames. i like it. ;-) signature.asc Description: PGP signature
Re: D for the Win
On Thursday, 21 August 2014 at 08:31:49 UTC, Nick Sabalausky wrote: link[$.rel = foobar, $.type = text/css]; That's a lot of syntax abuse there! Still, if it works for him, great, who am I to complain? At the end of the day, it's just a tool. Now the comma-operator has to stay because removing it is a severe breaking change.
Re: D for the Win
On Thu, 21 Aug 2014 08:37:30 + Ola Fosheim Gr via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Now the comma-operator has to stay because removing it is a severe breaking change. but we can abuse opIndex and/or opSlice too! ;-) signature.asc Description: PGP signature
Re: D for the Win
On 21/08/14 10:37, Ola Fosheim Gr wrote: Now the comma-operator has to stay because removing it is a severe breaking change. Isn't that multiple arguments to opIndex? -- /Jacob Carlborg
Re: D for the Win
What is really awesome about this is that his code actually worked, the mixing of operator overloads, opDispatch and rarely used features(e.g. comma op). D has come a long way in the last decade. On Thu, Aug 21, 2014 at 10:40 AM, ketmar via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thu, 21 Aug 2014 08:37:30 + Ola Fosheim Gr via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Now the comma-operator has to stay because removing it is a severe breaking change. but we can abuse opIndex and/or opSlice too! ;-)
Re: D for the Win
On Thu, Aug 21, 2014 at 10:47 AM, Jacob Carlborg via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On 21/08/14 10:37, Ola Fosheim Gr wrote:Isn't that multiple arguments to opIndex? -- /Jacob Carlborg mm, yes I believe you are right. http://dlang.org/operatoroverloading.html#ArrayOps
Re: Dutyl - a Vim plugin for running D tools
On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote: I'm open for suggestions for other tools and features to add to Dutyl(write them here, or preferably open GitHub issues with them) Any idea if this plugin works in conjunction with YouCompleteMe?
Re: D for the Win
On Thursday, 21 August 2014 at 08:47:50 UTC, Jacob Carlborg wrote: Isn't that multiple arguments to opIndex? Probably, I was just trying to be funny :P There should be a tutorial D for perl programmers of the 90s...
Re: Dutyl - a Vim plugin for running D tools
When I try to use this it just says that complete is not able to work at and suggests that DCD might not be running. Ubuntu 14.04. dcd-server and client are in path, even tried adding explicitly. How does one debug this plugin? On Thu, Aug 21, 2014 at 10:50 AM, BlackEdder via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote: I'm open for suggestions for other tools and features to add to Dutyl(write them here, or preferably open GitHub issues with them) Any idea if this plugin works in conjunction with YouCompleteMe?
Re: D 2.066 is out. Enjoy!
Jacob Carlborg wrote in message news:lt43pj$ral$1...@digitalmars.com... Support for C++ namespaces where just released and support for C++ templates will most likely end up in master soon. Support for C++ templates was in the last release, and the new pull request is only for special mangling of some stl declarations.
Re: Dutyl - a Vim plugin for running D tools
On Thursday, 21 August 2014 at 08:50:50 UTC, BlackEdder wrote: On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote: I'm open for suggestions for other tools and features to add to Dutyl(write them here, or preferably open GitHub issues with them) Any idea if this plugin works in conjunction with YouCompleteMe? YouCompleteMe will use the available omnifunc as a fallback if no semantic completer for the filetype is provided. So, yes, it should work.
Re: D for the Win
On Thursday, 21 August 2014 at 01:51:11 UTC, ketmar via Digitalmars-d-announce wrote: i always wonder how good people at finding various offences I'm not offended. and fascims everywhere. It's pretty much the Nazi anthem. It doesn't get much more fascist than that. Of course, someone can play with fascist phrases without being a fascist or promoting fascism. As I said, coming from an Israeli, it's probably benign. If the author was German, I'd feel uneasy about it. And don't tell me that Germans carelessly throwing around Nazi slogans isn't something to feel uneasy about. The NPD (Nazi party) is in two Landtagen (state parliaments). i bet that such people are glad to censor I'm not trying to censor anything. Neither am I convinced that banning Nazi symbols, songs, etc (as we do in Germany) is the right way to go. I think I'd rather have the Nazis wear Hakenkreuz armbands than other, obscure symbols that I can't identify. It's not like they stop existing when we ban their uniforms.
Re: D for the Win
On Wednesday, 20 August 2014 at 22:57:21 UTC, Paulo Pinto wrote: As a Portuguese living in Germany, I would say not everyone knows that outside Germany. Certainly. As I said, from an Israeli it's probably benign. I guess if aynthing, it's meant to be jokingly provoking towards Germans. I don't mind that at all.
Re: D for the Win
On Thu, 21 Aug 2014 11:48:32 + anonymous via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: It's pretty much the Nazi anthem. oh, really? let's see. current German anthem: Einigkeit und Recht und Freiheit für das deutsche Vaterland! Danach lasst uns alle streben brüderlich mit Herz und Hand! and so on. pretty innocent, right? ok, but this is only the 3rd verse of the song which begins with... oh, Deutschland, Deutschland über alles. may i assume that all Germans are well-disgiused Nazis then? here is the full song, for your pleasure: Deutschland, Deutschland über alles, über alles in der Welt, wenn es stets zu Schutz und Trutze brüderlich zusammenhält. Von der Maas bis an die Memel, von der Etsch bis an den Belt, Deutschland, Deutschland über alles, über alles in der Welt! Deutsche Frauen, deutsche Treue, deutscher Wein und deutscher Sang sollen in der Welt behalten ihren alten schönen Klang, uns zu edler Tat begeistern unser ganzes Leben lang. — Deutsche Frauen, deutsche Treue, deutscher Wein und deutscher Sang! and now, German anthem! and the 3rd verse: Einigkeit und Recht und Freiheit für das deutsche Vaterland! Danach lasst uns alle streben brüderlich mit Herz und Hand! Einigkeit und Recht und Freiheit sind des Glückes Unterpfand; blüh im Glanze dieses Glückes, blühe, deutsches Vaterland. And don't tell me that Germans carelessly throwing around Nazi slogans isn't something to feel uneasy about. they not only throwing, they still using part of that song as their anthem. besides, aren't your words racist? signature.asc Description: PGP signature
Re: D for the Win
On Thursday, 21 August 2014 at 12:05:40 UTC, ketmar via Digitalmars-d-announce wrote: ... Please, this is not important enough to argue here.
Re: D for the Win
On Thu, 21 Aug 2014 12:08:05 + Dicebot via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: Please, this is not important enough to argue here. ah, excuse me. it's so easy to drag me into such talks... mea culpa. signature.asc Description: PGP signature
Re: D for the Win
http://en.wikipedia.org/wiki/Godwin's_law
Re: D 2.066 is out. Enjoy!
On Wednesday, 20 August 2014 at 16:25:04 UTC, disapointed user wrote: too bad that i wasted my time for such a long time. i post a link to that thread with your answer to everywhere i can, so that others won't waste their time too. anyway good luck in the future for you linux guys. Well, people have different perspectives :) see http://forum.dlang.org/post/lrsnjovurigezboqx...@forum.dlang.org
Re: D 2.066 is out. Enjoy!
On 21/08/14 12:10, Daniel Murphy wrote: Support for C++ templates was in the last release, and the new pull request is only for special mangling of some stl declarations. You see, I get confused of all the syntax changes ;) -- /Jacob Carlborg
The No Explicit Save UI paradigm
On 07/08/2014 15:45, David Gileadi wrote: On 8/7/14, 4:18 AM, Bruno Medeiros wrote: This is an interesting behavior I've come across, even before watching this talk: Recently I tried IntelliJ IDEA, and it also goes away with any explicit UI notion of saving a file. It just saves files automatically, as you type. This is interesting, and might well be a marked improvement in UI behavior... This is a UI direction that Mac OSX is going in, presumably as part of their push to bring iOS behavior to the desktop. Apps that use it save as they go, and they have a standard UI to browse through previous versions of your document if you want to go back to (or crib from) something earlier. Interesting. Indeed the only potential issue I saw with this approach was, how does the application mark each local history version of a document? With explicit save it's easy, just create a new version in the local history each time the document is saved. Without explicit save... A smart algorithm/heuristic would have to be put in place. Something like saving a new version after a user stops typing after a while (5min or so?), or after a significant number of changes occurred. (if the local history is smart enough and saves changes incrementally, it can actually store every single change actually) In any case that's workable, and overall it seems like an improvement in UI design. It even reminds me of the talk Inventing on Principle talk Bret Victor gave ( http://vimeo.com/36579366 ), in particular the aspect about reducing (if not removing entirely) the save/compile/run cycle. -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Dutyl - a Vim plugin for running D tools
On Thursday, 21 August 2014 at 08:57:55 UTC, Rory McGuire via Digitalmars-d-announce wrote: When I try to use this it just says that complete is not able to work at and suggests that DCD might not be running. Ubuntu 14.04. dcd-server and client are in path, even tried adding explicitly. How does one debug this plugin? On Thu, Aug 21, 2014 at 10:50 AM, BlackEdder via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote: I'm open for suggestions for other tools and features to add to Dutyl(write them here, or preferably open GitHub issues with them) Any idea if this plugin works in conjunction with YouCompleteMe? Is the DCD server running? It needs to be running for Dutyl to use it. You can either run it manually or use the Dutyl's `:DUDCDstartServer` command. You can check if the server is currently running by opening a shell and typing `dcd-client --query`.
Re: Dutyl - a Vim plugin for running D tools
Yip I tried running it manually in another terminal. Is there an error log or something somewhere? On 21 Aug 2014 19:00, Idan Arye via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 21 August 2014 at 08:57:55 UTC, Rory McGuire via Digitalmars-d-announce wrote: When I try to use this it just says that complete is not able to work at and suggests that DCD might not be running. Ubuntu 14.04. dcd-server and client are in path, even tried adding explicitly. How does one debug this plugin? On Thu, Aug 21, 2014 at 10:50 AM, BlackEdder via Digitalmars-d-announce digitalmars-d-announce@puremagic.com wrote: On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote: I'm open for suggestions for other tools and features to add to Dutyl(write them here, or preferably open GitHub issues with them) Any idea if this plugin works in conjunction with YouCompleteMe? Is the DCD server running? It needs to be running for Dutyl to use it. You can either run it manually or use the Dutyl's `:DUDCDstartServer` command. You can check if the server is currently running by opening a shell and typing `dcd-client --query`.
Re: Dutyl - a Vim plugin for running D tools
On Thursday, 21 August 2014 at 10:20:24 UTC, Weaseldog wrote: On Thursday, 21 August 2014 at 08:50:50 UTC, BlackEdder wrote: On Thursday, 14 August 2014 at 22:20:52 UTC, Idan Arye wrote: I'm open for suggestions for other tools and features to add to Dutyl(write them here, or preferably open GitHub issues with them) Any idea if this plugin works in conjunction with YouCompleteMe? YouCompleteMe will use the available omnifunc as a fallback if no semantic completer for the filetype is provided. So, yes, it should work. I looked a bit into YouCompleteMe to see if I can add a proper semantic completer. It appears that semantic completers run on the YCMD server rather then inside the Vim instance - which makes writing a semantic completer infeasible. The semantic completer will need to be able to read the import paths and to invoke DCD. These two functionalities are implemented in Dutyl with VimScript - but to access these implementations it'll need to some interface to call these functions. I don't know if the YCDM-Vim interaction supports the server calling the client, or if Vim's own server-client mechanism can be used for it(which will require extra configuration), but at any rate it doesn't make much sense to use the completion server when the work is done in the Vim instance. Another option is to reimplement that functionality in Python - but if the the import paths gathering, the DCD invokation, and the glue code that connects them are all reimplemented there is no point in making this part of Dutyl... Also note that Dutyl sends the content of the current buffer to DCD, not the file saved on disc. This diffidently requires access to the Vim instance, and changing it is not an option unless you want to have to save before you autocomplete.
Re: D 2.066 is out. Enjoy!
On Thursday, 21 August 2014 at 15:20:49 UTC, Daniel Murphy wrote: Jacob Carlborg wrote in message news:lt50m0$20f0$1...@digitalmars.com... Support for C++ templates was in the last release, and the new pull request is only for special mangling of some stl declarations. You see, I get confused of all the syntax changes ;) Don't worry, so did Walter. LOL. Yeah, well, it would be ni going to support C+ce if we could get an actual list of the C++ features that D currently supports somewhere (and how to use them if it's not obvious). You've been doing so much great work on that that I have no clue what the current state of things is. For instance, this is the first I've heard of anything about template support; I'd thought that we were never going to support templates. Is it just for name mangling or for actually compiling them? - Jonathan M Davis
Re: D 2.066 is out. Enjoy!
On Tuesday, 19 August 2014 at 08:14:41 UTC, novice2 wrote: http://dlang.org/changelog.html Version D 2.066 August 18, 2014 ... Phobos enhancements 1.Bugzilla 3780: getopt improvements by Igor Lesik Sorry, i can't find this improvements nor in getopt.d nor in http://dlang.org/phobos/std_getopt.html. Is this announce prematurely, and that this changes will be seen in 2.067 ? I suspect that the changelog was done by dates rather than based on what was actually merged. Someone else was commenting that some stuff was in there that's going to be in 2.067 and not 2.066, and 2.066 took long enough after it was branched, that it would be easy to accidentally list 2.067 stuff for 2.066 if you were looking at merge dates rather than what actually went on the 2.066 branch. - Jonathan M Davis
Re: D 2.066 is out. Enjoy!
On 8/21/2014 11:54 AM, Jonathan M Davis wrote: LOL. Yeah, well, it would be ni going to support C+ce if we could get an actual list of the C++ features that D currently supports somewhere (and how to use them if it's not obvious). You've been doing so much great work on that that I have no clue what the current state of things is. For instance, this is the first I've heard of anything about template support; I'd thought that we were never going to support templates. Is it just for name mangling or for actually compiling them? The thing is, while the code was there, there wasn't a single test case for it in the test suite. Furthermore, at least for Elf, there was no support for the special mangling done for ::std:: stuff. The thing is, modern C++ practice makes heavy use of std types. Having an interface to C++ code is fairly unusable unless D can also interface to std::string, std::vector, and a few others. The first step is to support the mangling of them. Then, try to construct a workalike on the D side that follows D rules, and yet is able to seamlessly interact with the corresponding C++ code. We'll see how far we can get with that, and then evaluate what to do next. There are no plans for actually compiling C++ code with a D compiler. The plan is for support like we do for C - have a .d header file for it.
Re: D 2.066 is out. Enjoy!
On Thursday, 21 August 2014 at 20:33:56 UTC, Walter Bright wrote: On 8/21/2014 11:54 AM, Jonathan M Davis wrote: LOL. Yeah, well, it would be ni going to support C+ce if we could get an actual list of the C++ features that D currently supports somewhere (and how to use them if it's not obvious). You've been doing so much great work on that that I have no clue what the current state of things is. For instance, this is the first I've heard of anything about template support; I'd thought that we were never going to support templates. Is it just for name mangling or for actually compiling them? The thing is, while the code was there, there wasn't a single test case for it in the test suite. Furthermore, at least for Elf, there was no support for the special mangling done for ::std:: stuff. The thing is, modern C++ practice makes heavy use of std types. Having an interface to C++ code is fairly unusable unless D can also interface to std::string, std::vector, and a few others. The first step is to support the mangling of them. Then, try to construct a workalike on the D side that follows D rules, and yet is able to seamlessly interact with the corresponding C++ code. We'll see how far we can get with that, and then evaluate what to do next. There are no plans for actually compiling C++ code with a D compiler. The plan is for support like we do for C - have a .d header file for it. Well, I wouldn't have expected us to be compiling C++ per se, but previously, it seemed like the party line was that we wouldn't be supporting C++ templates at all because of how hard they were and because we don't want a C++ compiler in the D compiler. I'm certainly all for anything we can do for C++ compatability without going off the deep end. I just don't hear much about what we're actually doing right now. So, I really have no idea what the current status of that is. With what was said at dconf and comments like these, it seems like we're making huge progress in comparison to where we were, and as far as I can tell, about the only way to hear about it is to either pay a lot of attention to dmd pulls or to see an occasonal comment from Daniel talking about it or from someone who's paying close attention to what he's up to. So, at some point in the near future, it would be nice if there were somewhere that actually said what D can actually do with C++ now, even if that doesn't include everything that's going to be coming or if much of it is marked as experimental and relatively untested. - Jonathan M Davis
Re: D 2.066 is out. Enjoy!
On Thursday, 21 August 2014 at 20:43:53 UTC, Jonathan M Davis wrote: On Thursday, 21 August 2014 at 20:33:56 UTC, Walter Bright wrote: On 8/21/2014 11:54 AM, Jonathan M Davis wrote: LOL. Yeah, well, it would be ni going to support C+ce if we could get an actual list of the C++ features that D currently supports somewhere (and how to use them if it's not obvious). You've been doing so much great work on that that I have no clue what the current state of things is. For instance, this is the first I've heard of anything about template support; I'd thought that we were never going to support templates. Is it just for name mangling or for actually compiling them? The thing is, while the code was there, there wasn't a single test case for it in the test suite. Furthermore, at least for Elf, there was no support for the special mangling done for ::std:: stuff. The thing is, modern C++ practice makes heavy use of std types. Having an interface to C++ code is fairly unusable unless D can also interface to std::string, std::vector, and a few others. The first step is to support the mangling of them. Then, try to construct a workalike on the D side that follows D rules, and yet is able to seamlessly interact with the corresponding C++ code. We'll see how far we can get with that, and then evaluate what to do next. There are no plans for actually compiling C++ code with a D compiler. The plan is for support like we do for C - have a .d header file for it. Well, I wouldn't have expected us to be compiling C++ per se, but previously, it seemed like the party line was that we wouldn't be supporting C++ templates at all because of how hard they were and because we don't want a C++ compiler in the D compiler. I'm certainly all for anything we can do for C++ compatability without going off the deep end. I just don't hear much about what we're actually doing right now. So, I really have no idea what the current status of that is. With what was said at dconf and comments like these, it seems like we're making huge progress in comparison to where we were, and as far as I can tell, about the only way to hear about it is to either pay a lot of attention to dmd pulls or to see an occasonal comment from Daniel talking about it or from someone who's paying close attention to what he's up to. So, at some point in the near future, it would be nice if there were somewhere that actually said what D can actually do with C++ now, even if that doesn't include everything that's going to be coming or if much of it is marked as experimental and relatively untested. - Jonathan M Davis It would be nice to have a page to link to when questions come up on Reddit about compatibility with C++. That page should also have information about avoiding the garbage collector and the status of GC removal from the standard library.
D 2.066 new behavior
In all previous versions through 2.066 beta 5, the following code
compiled and ran correctly:
import std.stdio;
T add(T)(in T x, in T y)
{
T z;
z = x + y;
return z;
}
void main()
{
const double a = 1.0;
const double b = 2.0;
double c;
c = add(a,b);
writefln(c = %s, c);// 3.0
c = 1.0;
writefln(c = %s, c);// 1.0
}
From beta 6 onward it no longer compiles. The problem seems to be
const qualifiers being carried into the template type. Since a
and b are const double, the function template parameter T is
const double. So x and y are const, no problem, but z is now
const also. The following error message is given.
T add(T)(in T x, in T y)
{
T z;
z = x + y; // Error: Can't modify const expression z
return z;
}
The same problem shows up elsewhere as 'cannot implicitly convert
const x to x'
and 'none of the overloads are callable using argument types (x)
const'.
Is this expected behavior that has never been enforced before, or
is it something new?
And is anyone else having the same problem?
Paul
Re: D 2.066 new behavior
On Friday, 22 August 2014 at 01:54:55 UTC, Paul D Anderson wrote: Is this expected behavior that has never been enforced before, or is it something new? And is anyone else having the same problem? Paul Looks like a regression, I've filed it here: https://issues.dlang.org/show_bug.cgi?id=13351
Re: D for the Win
On 8/20/2014 3:02 PM, anonymous wrote: [...] I agree with Dicebot. Let's not go there.
Automated source translation of C++ to D
C++ support keeps coming up these days, with Andrei continually stressing it as something to work on. How hard would it to be to write a C++-D translator, to allow people to translate C++ libraries to D? I've been using tools like DStep and looking at libdparse, which seem to work very well. I just translated a C sample app from the Android NDK to D, fairly simple stuff like turning - into ., adding a default in a switch statement, rewriting casts from C-style to D-style casts, removing the struct label, nothing that couldn't be automated. I'm sure there's stuff that'd need to be done by hand, but if you can automate 97%, that's good enough. Could this be a viable option for many cases?
Re: Simplified signatures in generated documentation
On 20/08/14 18:34, H. S. Teoh via Digitalmars-d wrote: Sorry, I didn't make myself clear. What I meant was that ddoc will generate the above structure, so that user ddoc templates can customize the appearance of each element in the declaration. You don't actually write any of these macros (except where you wish to customize the appearance of that part of the declaration); you write the function declaration as usual, and ddoc will internally expand them using the above structure. If one or more elements aren't defined, they default to just passing the text through verbatim. So essentially, it's about being able to target a specific part of the declaration to customize its formatting. Ok, I see. Sounds like a good idea. -- /Jacob Carlborg
Re: Automated source translation of C++ to D
On Thu, 21 Aug 2014 06:35:53 + Joakim via Digitalmars-d digitalmars-d@puremagic.com wrote: i believe that all code that using STL/Boost will not be translated (and this is the majority of C++ code, i think). and only very-very primitive templates can be translated automatically. so maybe i'm not right, but i think that automatic translation can do something about 3% of existing code. ;-) signature.asc Description: PGP signature
Re: Automated source translation of C++ to D
On 21/08/14 08:35, Joakim wrote: C++ support keeps coming up these days, with Andrei continually stressing it as something to work on. How hard would it to be to write a C++-D translator, to allow people to translate C++ libraries to D? I've been using tools like DStep and looking at libdparse, which seem to work very well. I just translated a C sample app from the Android NDK to D, fairly simple stuff like turning - into ., adding a default in a switch statement, rewriting casts from C-style to D-style casts, removing the struct label, nothing that couldn't be automated. I'm sure there's stuff that'd need to be done by hand, but if you can automate 97%, that's good enough. Could this be a viable option for many cases? I think it will be quite difficult. There are probably many cases of C++ code where there is no direct translation in D. libclang, which DStep uses, is probably not enough to do a complete source translation of C++. That means using the C++ Clang API's which are unstable in written in C++. C is completely different. D was basically designed to allow to easy translate C to D. If a C syntax compiles in D it's supposed to have the same semantics as in C. It might be possible. As a start you could help out with DStep. Starting to add support for C++ for example. -- /Jacob Carlborg
Re: [OT] Re: Redesign of dlang.org
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote: https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png My emphasis has been on creating a friendly first impression; a lightweight page to introduce newcomers to D and get them started quickly. +1 Cool look! The paragraphs need to be black on light background to get high contrast for all user groups, though. (You will also meet resistance on changing the logo...) I've not yet begun any work on the views for the documentation and similar pages with a larger amount of copy. The documentation could have black on white (white paper meme), but same visual elements to get a sense of subsite areas.
Re: Setting array length to 0 discards reserved allocation?
On Thursday, 21 August 2014 at 03:53:42 UTC, ketmar via Digitalmars-d wrote: On Thu, 21 Aug 2014 03:24:35 + Andrew Godfrey via Digitalmars-d digitalmars-d@puremagic.com wrote: maybe just call that slice views? ;-) really, uncommon term will (at least it should ;-) make user to read about that slice views, and reference is something like ah, i know what references is, let's start coding now! Yeah, you have a point. slice view sounds odd, and I suppose all this is the background to why some parts of the docs use the term slice for this. Maybe I should have another look at that - maybe introducing slice first and the slice operator later, can avoid confusion sufficiently.
Re: BitC, Rust, dog food and more
On Sunday, 25 March 2012 at 17:31:45 UTC, bearophile wrote: I think that one of the most important things to underscore is that we would have never found these things so early unless we had written the Rust compiler in Rust itself. It forces us to use the language constantly, and we quickly find pain points. I highly encourage all languages to do the same; it's a great way to find and shake out design issues early. Eating your own dog food is quite important for a language, especially if it's a low-level language. D has chosen the pragmatic approach of using almost-C++ as its implementation language, but this has caused (and it is causing) some disadvantages too. Time to ask this again?
Re: Setting array length to 0 discards reserved allocation?
On Thu, 21 Aug 2014 07:23:34 + Andrew Godfrey via Digitalmars-d digitalmars-d@puremagic.com wrote: slice view sounds odd i agree, i just took the first words that came into my head. ;-) Maybe I should have another look at that - maybe introducing slice first and the slice operator later, can avoid confusion sufficiently. sound reasonable for me. signature.asc Description: PGP signature
Re: BitC, Rust, dog food and more
On 08/21/2014 09:39 AM, eles wrote: On Sunday, 25 March 2012 at 17:31:45 UTC, bearophile wrote: I think that one of the most important things to underscore is that we would have never found these things so early unless we had written the Rust compiler in Rust itself. It forces us to use the language constantly, and we quickly find pain points. I highly encourage all languages to do the same; it's a great way to find and shake out design issues early. Eating your own dog food is quite important for a language, especially if it's a low-level language. D has chosen the pragmatic approach of using almost-C++ as its implementation language, but this has caused (and it is causing) some disadvantages too. Time to ask this again? AFAIK, ddmd is well underway and is pretty much in an alpha-state now. Here's an announcement from July: http://forum.dlang.org/thread/cmeqwpzglxjksmiek...@forum.dlang.org#post-lqlsp1:246f:241:40digitalmars.com
Re: BitC, Rust, dog food and more
On Thursday, 21 August 2014 at 07:53:40 UTC, simendsjo wrote: On 08/21/2014 09:39 AM, eles wrote: On Sunday, 25 March 2012 at 17:31:45 UTC, bearophile wrote: Time to ask this again? AFAIK, ddmd is well underway and is pretty much in an alpha-state now. More precisely, I was asking this: http://forum.dlang.org/post/jko1cn$1s5v$1...@digitalmars.com
Re: Automated source translation of C++ to D
On 8/20/14, 11:35 PM, Joakim wrote: C++ support keeps coming up these days, with Andrei continually stressing it as something to work on. How hard would it to be to write a C++-D translator, to allow people to translate C++ libraries to D? I've been using tools like DStep and looking at libdparse, which seem to work very well. I just translated a C sample app from the Android NDK to D, fairly simple stuff like turning - into ., adding a default in a switch statement, rewriting casts from C-style to D-style casts, removing the struct label, nothing that couldn't be automated. I'm sure there's stuff that'd need to be done by hand, but if you can automate 97%, that's good enough. Could this be a viable option for many cases? I think the key here involves clang with hooks + a config file per C++ file to translate that instructs the translator how to proceed about corner cases (e.g. expand this macro but not this other etc). -- Andrei
Re: [OT] Re: Redesign of dlang.org
On 21/08/14 06:59, Hubert wrote: https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png I kind of like the structure of the page, but not the colors. -- /Jacob Carlborg
Re: BitC, Rust, dog food and more
On Sunday, 25 March 2012 at 19:21:12 UTC, Walter Bright wrote: I don't see a reason for programmers to spend 10 years suffering in the wilderness to learn to avoid making certain kinds of mistakes. I couldn't agree more.
Re: auto ref deduction and common type deduction inconsistency
On Thursday, 21 August 2014 at 05:24:13 UTC, Artur Skawina via
Digitalmars-d wrote:
While D's `ref` is a hack, it's /already/ part of the function
type/signature.
The return type of a function is /already/ (ie in the D
dialects supported
by recent frontend releases) determined from *all* returned
expression.
What would be the advantage of propagating/inferring only the
type, but not
the lvalueness?...
I think I understand the issue better now.
D doesn't always deduce a common return type, e.g.
class A {}
class B {}
auto foo() {
return new A();
return new B();
}
This fails to compile with mismatched function return type,
even though it could easily return Object. However, it seems to
do some deduction of sorts with integral types, e.g. this deduces
to return double.
auto foo() {
return 0;
return 0.0;
return 0UL;
}
I'm not sure what logic it is using to do common type deductions.
I haven't investigated fully.
The problem comes with recursion, which we don't handle at the
moment for auto or auto ref functions, but handling that becomes
much easier when you just assume the return type is the return
type from the first return statement, so I see the value in the
described approach.
Re: BitC, Rust, dog food and more
eles wrote in message news:hojvezprzeaqqceml...@forum.dlang.org... AFAIK, ddmd is well underway and is pretty much in an alpha-state now. More precisely, I was asking this: http://forum.dlang.org/post/jko1cn$1s5v$1...@digitalmars.com The old DDMD project is no longer relevant. https://github.com/D-Programming-Language/dmd/pull/3410
Re: Automated source translation of C++ to D
Joakim wrote in message news:ysntkmioyndreuiiy...@forum.dlang.org... C++ support keeps coming up these days, with Andrei continually stressing it as something to work on. How hard would it to be to write a C++-D translator, to allow people to translate C++ libraries to D? You might want to look at DDMD, which is automatically converted.
Re: Brighton [was Using D]
On 12 Jul 2014 16:03, Iain Buclaw ibuc...@gdcproject.org wrote: On 12 July 2014 15:53, Russel Winder via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sat, 2014-07-12 at 15:37 +0100, Iain Buclaw via Digitalmars-d wrote: […] I live literally 400 yards away from the burnt down west pier. Its a beautiful sight in the morning, come sun, rain, or fog. I hear they are building a 100 metre high elevator-to-nowhere in its place. Sad times... We lived for a while in Little Western Street. Even then the West Pier was crumbling and was closed a short while after we wandered up and down it one afternoon in glorious (very un-English) sun. […] I can give you my details, and can see where things go from there. Is evening meetings in London something you might be up for? Depending on who is involved and what constitutes the centre of mass, there is always the option of meeting in a pub in Clapham Junction – saves the extra haul across Central London. That sounds like at least the beginnings of a plan to me. My only way of getting around would be train due to lack of a car, or license. Hey Russel, Have you got anywhere with planning this? I'd be happy to help out with anything. Iain.
Re: BitC, Rust, dog food and more
On Thursday, 21 August 2014 at 10:02:44 UTC, Daniel Murphy wrote: eles wrote in message news:hojvezprzeaqqceml...@forum.dlang.org... AFAIK, ddmd is well underway and is pretty much in an alpha-state now. More precisely, I was asking this: http://forum.dlang.org/post/jko1cn$1s5v$1...@digitalmars.com The old DDMD project is no longer relevant. https://github.com/D-Programming-Language/dmd/pull/3410 On quick read I can't find the reason. Why is no longer relevant?
Re: BitC, Rust, dog food and more
On Thursday, 21 August 2014 at 11:29:57 UTC, AsmMan wrote: On Thursday, 21 August 2014 at 10:02:44 UTC, Daniel Murphy wrote: eles wrote in message news:hojvezprzeaqqceml...@forum.dlang.org... AFAIK, ddmd is well underway and is pretty much in an alpha-state now. More precisely, I was asking this: http://forum.dlang.org/post/jko1cn$1s5v$1...@digitalmars.com The old DDMD project is no longer relevant. https://github.com/D-Programming-Language/dmd/pull/3410 On quick read I can't find the reason. Why is no longer relevant? Because it is planned to be the official D frontend. -- Paulo
Re: [OT] Re: Redesign of dlang.org
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote: First I wanna say that I've become a huge fan of D, and I hope one day I can replace all my creative projects with a D codebase. With that said, I do agree that D could use a redesign. I've not been monitoring this thread very closely, but the design suggestions I've seen so far has dissapointed me. Don't misunderstand me; the proposals look good, but they are in my opinion too conservative. Now I've given it a shot and created a first draft on how I imagine a future Dlang.org could/should look like, keep in mind that nothing is final yet: https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png My emphasis has been on creating a friendly first impression; a lightweight page to introduce newcomers to D and get them started quickly. I think this is a sane design approach when it comes to D's current position in the market. I've not yet begun any work on the views for the documentation and similar pages with a larger amount of copy. (I hope I haven't missed any earlier design proposal that already looks like this.) It probably looks good as a landing page for a newcomers but I will annoyed with extra forced navigation very quick through daily usage of the web site. It sacrifices productivity in favor of good looks.
Re: const after initialization / pointers, references and values
On Wednesday, 20 August 2014 at 21:26:55 UTC, Philippe Sigaud via Digitalmars-d wrote: If you want reference semantics but do not want to have pointers in your code, yes classes are your best choice. Alternatively, isn't this a good place to use ref parameters? Or is there some semantic I'm missing here? http://dlang.org/function.html#parameters BTW, Vicente, the D.learn section is a great place to get help. :) -Wyatt
Re: [OT] Re: Redesign of dlang.org
On Thu, 21 Aug 2014 12:09:37 + Dicebot via Digitalmars-d digitalmars-d@puremagic.com wrote: It probably looks good as a landing page for a newcomers but I will annoyed with extra forced navigation very quick through daily usage of the web site. It sacrifices productivity in favor of good looks. exactly what i wanted to say, but cannot find the appropriate words! signature.asc Description: PGP signature
Re: User data of epoll event is reported abnormally by epoll_wait.
On 2014-08-20 6:01 AM, blake kim wrote:
extern(C) align(1) struct epoll_event {
align(1):
uint events;
epoll_data_t data;
}
Wow, that fixes my issue! I couldn't use more than 1 event in my array
because of misalignment, thanks!
Re: BitC, Rust, dog food and more
AsmMan wrote in message news:vhlbrdptvpygtyyhp...@forum.dlang.org... On quick read I can't find the reason. Why is no longer relevant? Because it is dead, and we're automatically converting the C++ frontend to D. It will soon replace the C++ frontend in dmd.
Re: const after initialization / pointers, references and values
On Wed, Aug 20, 2014 at 11:49 PM, Jakob Ovrum via Digitalmars-d digitalmars-d@puremagic.com wrote: Certainly the easiest, but I don't think it's always the best. If light-weightedness is desired, make the struct contain the reference, effectively making the struct a reference type Well, yes. But the OP explicitly asked not to have to deal with pointers. So...
Communication with other languages via wrappers
I am starting this thread to quench my thirst for knowledge. I notice, that the existing wrappers to other languages are: C: D can natively interface to C C++ : Some interfacing possible Lua : There is LuaD and DLua Objective C : This : https://michelf.ca/projects/d-objc-bridge/ Would someone like to add some more?
Re: [OT] Re: Redesign of dlang.org
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote: https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png That does look quite nice. It may be a bit *too* minimalist, and the colours aren't right, but the design is solid.
Re: [OT] Re: Redesign of dlang.org
On Thu, Aug 21, 2014 at 04:59:18AM +, Hubert via Digitalmars-d wrote: [...] https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png My emphasis has been on creating a friendly first impression; a lightweight page to introduce newcomers to D and get them started quickly. I think this is a sane design approach when it comes to D's current position in the market. I've not yet begun any work on the views for the documentation and similar pages with a larger amount of copy. (I hope I haven't missed any earlier design proposal that already looks like this.) [...] Please don't take this personally, but frankly, I don't like this design. It's too minimalistic, the choice of color is too garish, and the logo looks amateurish. There is too much space in the center of the page, while squeezing the real information to the sides. I very much dislike the current splash page + get started / learn more trend, an anachronism from the 90's. It requires too much effort to get to the meat of the site, and serves little purpose except to fill up space. More navigation can be put on the front page without requiring inordinate amounts of clicks to reach (properly laid out, of course, to avoid clutter). Having said that, though, I like the concept of putting the convenience, power, efficiency slogans in a prominent place, side by side. That's something far superior to the current layout we have, where most people won't even see everything until they scroll down. T -- Unix is my IDE. -- Justin Whear
Re: [OT] Re: Redesign of dlang.org
On Thursday, 21 August 2014 at 12:09:38 UTC, Dicebot wrote: It probably looks good as a landing page for a newcomers but I will annoyed with extra forced navigation very quick through daily usage of the web site. It sacrifices productivity in favor of good looks. Hmm... I don't remember, when I last visited the front page, I don't even know, what it looks like. What one would need there and what productivity you plan to get there?
Re: [OT] Re: Redesign of dlang.org
On Thursday, 21 August 2014 at 15:14:05 UTC, Kagamin wrote: On Thursday, 21 August 2014 at 12:09:38 UTC, Dicebot wrote: It probably looks good as a landing page for a newcomers but I will annoyed with extra forced navigation very quick through daily usage of the web site. It sacrifices productivity in favor of good looks. Hmm... I don't remember, when I last visited the front page, I don't even know, what it looks like. What one would need there and what productivity you plan to get there? I check various parts of documentation (not DDOC-generates Phobos part but manually written articles) on a regular basis. It is often faster to find via navigating then search query because term usage is spread all across.
Re: Communication with other languages via wrappers
On Thu, 21 Aug 2014 13:20:02 +, seany wrote: I am starting this thread to quench my thirst for knowledge. I notice, that the existing wrappers to other languages are: C: D can natively interface to C C++ : Some interfacing possible Lua : There is LuaD and DLua Objective C : This : https://michelf.ca/projects/d-objc-bridge/ Would someone like to add some more? PyD: https://bitbucket.org/ariovistus/pyd/wiki/Home
Shouldn't have IsAlpha() from std.uni has a different name to avoid confusing from std.ascii?
I'm trying to write in D rather than C++ an application where I do need to write a small parsing library. These two modules part of D standard library (no idea if it's D term to call a library/module part of the language itself) has the same name. Depeding if imported is either std.uni or std.ascii it does have exactly the opposite behavior. Not sure of it is only for me, but as part of the standard library I see this as a negative point and I think it would be better if one(the one from IsAlpha(), my suggestion) of is ranamed. Any thoughts? I don't know if I'm missing something but two functions (and not methods) with same name is very bad.
Re: Shouldn't have IsAlpha() from std.uni has a different name to avoid confusing from std.ascii?
On Thu, 21 Aug 2014 15:27:46 +
MacAsm via Digitalmars-d digitalmars-d@puremagic.com wrote:
Any thoughts? I don't know if I'm missing something but two
functions (and not methods) with same name is very bad.
they doing much the same, but for different character sets. two
different names will just confuse users.
you can use fully qualified names and/or local imports to use exactly
what you want. something like:
void myFunc (char ch) {
import std.ascii;
if (std.ascii.isAlpha(ch)) ...
}
local imports rocks! ;-)
signature.asc
Description: PGP signature
Re: Shouldn't have IsAlpha() from std.uni has a different name to avoid confusing from std.ascii?
On Thu, 21 Aug 2014 18:36:30 +0300 ketmar via Digitalmars-d digitalmars-d@puremagic.com wrote: On Thu, 21 Aug 2014 15:27:46 + MacAsm via Digitalmars-d digitalmars-d@puremagic.com wrote: Any thoughts? I don't know if I'm missing something but two functions (and not methods) with same name is very bad. they doing much the same, but for different character sets. two different names will just confuse users. you can use fully qualified names and/or local imports to use exactly what you want. Exactly. They're doing the same thing but for different character sets, so they have the same name. You then use the module system to distinguish them. So, the module system is doing its job. The alternative is to do something like prefix functions with the module name (e.g. isUniAlpha and isASCIIAlpha), in which case, we're ignoring the module system, and making the names unnecessarily long. The module system was designed to deal with conflicts like this. So, if two functions do different things, we give them different names, but if they're doing the same thing (as in this case), we give them the same name. - Jonathan M Davis
Linker `undefined reference` errors when using scoped imports
For now I can't an example of code. But sometimes I get Linker errors on Ubuntu Linux when using *scoped imports*. May be this issue happens on another platforms too. Does anybody experience the same problem when compiling programmes? I'll try to invent some example of code that illustrates this. Of course project where I got this is to long to post there in forum. I saw that in new release 2.066 there was some improvements about names mangling. But seems that these changes are not connected with this problem. May be it's just linker problem and compiler have nothing to do with it? So it's interesting to see any comments.
Re: [OT] Re: Redesign of dlang.org
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote: https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png This is a brilliant idea, except for the logo. We have one, and with it an identity, and we should not loose it. On Thursday, 21 August 2014 at 12:09:38 UTC, Dicebot wrote: It probably looks good as a landing page for a newcomers but I will annoyed with extra forced navigation very quick through daily usage of the web site. It sacrifices productivity in favor of good looks. There is too much links in our actual homepage, newcomers are simply lost, we absolutely need to light it, to make it more friendly. The question is : is it more important to maintain your old habits or to be welcoming and attractive for the new users ? Don't forget that programmers are hipsters, and we need to take care of our image.
Re: [OT] Re: Redesign of dlang.org
On Thursday, 21 August 2014 at 17:12:38 UTC, Théo Bueno wrote: On Thursday, 21 August 2014 at 12:09:38 UTC, Dicebot wrote: It probably looks good as a landing page for a newcomers but I will annoyed with extra forced navigation very quick through daily usage of the web site. It sacrifices productivity in favor of good looks. There is too much links in our actual homepage, newcomers are simply lost, we absolutely need to light it, to make it more friendly. The question is : is it more important to maintain your old habits or to be welcoming and attractive for the new users ? Don't forget that programmers are hipsters, and we need to take care of our image. I prefer to have my cake and eat it at the same time. There is no reason why it can't have better navigation while making important information highlighted and visually eye-catching. Also please avoid personal insults :P
Re: [OT] Re: Redesign of dlang.org
On Thursday, 21 August 2014 at 17:15:30 UTC, Dicebot wrote: I prefer to have my cake and eat it at the same time. There is no reason why it can't have better navigation while making important information highlighted and visually eye-catching. Of course :) Also please avoid personal insults :P I wasn't insulting, my intention was to mention the fact that this argument is not entirely a matter of productivity, but a fear of change.
Re: [OT] Re: Redesign of dlang.org
On Thursday, 21 August 2014 at 17:24:28 UTC, Théo Bueno wrote: Also please avoid personal insults :P I wasn't insulting, my intention was to mention the fact that this argument is not entirely a matter of productivity, but a fear of change. I was referring to Don't forget that programmers are hipsters statement ;)
Re: [OT] Re: Redesign of dlang.org
On Thursday, 21 August 2014 at 17:12:38 UTC, Théo Bueno wrote: There is too much links in our actual homepage, newcomers are simply lost, we absolutely need to light it, to make it more friendly. Also, please see this message : http://forum.dlang.org/thread/euxbskjjoetrwrqtk...@forum.dlang.org It explains why we need a big red get started button to help the newcomers. This person was not able to find relevant informations on IDEs, despite our big stack of links on the homepage. This is also a lack of productivity.
Re: [OT] Re: Redesign of dlang.org
On Thursday, 21 August 2014 at 17:31:45 UTC, Dicebot wrote: On Thursday, 21 August 2014 at 17:24:28 UTC, Théo Bueno wrote: Also please avoid personal insults :P I wasn't insulting, my intention was to mention the fact that this argument is not entirely a matter of productivity, but a fear of change. I was referring to Don't forget that programmers are hipsters statement ;) Oh. Let me rephrase : Don't forget that programmers are undeclared hipsters :D
scope classes mentioned in tutorials, but deprecated
http://dlang.org/cpptod.html#raii mentions scope class and scope variables, which seem deprecated (http://dlang.org/deprecate.html)
Re: Automated source translation of C++ to D
On Thursday, 21 August 2014 at 10:00:43 UTC, Daniel Murphy wrote: Joakim wrote in message news:ysntkmioyndreuiiy...@forum.dlang.org... C++ support keeps coming up these days, with Andrei continually stressing it as something to work on. How hard would it to be to write a C++-D translator, to allow people to translate C++ libraries to D? You might want to look at DDMD, which is automatically converted. Yes, I'm aware of ddmd. You've mentioned many times that it only works because dmd is written using a very unC++-like style, to the point where github's source analyzer claims that dmd is written in 66.7% C, 28.4% D (presumably the tests right now), 4.4% C++, and 0.5% other. :) Given tools like libclang, how hard do you think it'd be to translate most of actual C++ to D? If writing such a tool would mean that C++-D translation is the path of least effort for D users who want to integrate with C++, maybe that's the approach that should be taken instead. I should note that I have no interest in any C++ libraries: I'm just throwing out this idea as an alternative to all the C++ interfacing that's being considered for D right now.
Re: [OT] Re: Redesign of dlang.org
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote: First I wanna say that I've become a huge fan of D, and I hope one day I can replace all my creative projects with a D codebase. With that said, I do agree that D could use a redesign. I've not been monitoring this thread very closely, but the design suggestions I've seen so far has dissapointed me. Don't misunderstand me; the proposals look good, but they are in my opinion too conservative. Now I've given it a shot and created a first draft on how I imagine a future Dlang.org could/should look like, keep in mind that nothing is final yet: https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png My emphasis has been on creating a friendly first impression; a lightweight page to introduce newcomers to D and get them started quickly. I think this is a sane design approach when it comes to D's current position in the market. I've not yet begun any work on the views for the documentation and similar pages with a larger amount of copy. (I hope I haven't missed any earlier design proposal that already looks like this.) I'm not a fan of the colours and the general way it looks, but I do really like the three columns of text for the three big points. I'm not sure how to put that on a home page and keep some consistent navigation in place, so that would require some playing around with. You could maybe sacrifice sidebar navigation on the home page to allow enough space to fit in the text columns at 1024px width, I'm not sure. A few other people have mentioned fluid container widths. I actually know exactly what to do with that, I just haven't gotten around to doing it yet. I think I make some progress, but then life gets in the way a little bit. I'll come back to it soon and work a little more on the site.
Re: scope classes mentioned in tutorials, but deprecated
On Thursday, 21 August 2014 at 17:55:19 UTC, Timothee Cour via Digitalmars-d wrote: http://dlang.org/cpptod.html#raii mentions scope class and scope variables, which seem deprecated (http://dlang.org/deprecate.html) https://github.com/D-Programming-Language/dlang.org/pull/637
Re: Automated source translation of C++ to D
Might be pretty hard, C++ has some features D doesn't, not sure how you would emulate them. C++ has these, I don't think D does: move only types r-value references SFINAE ADL Multiple inheritance
Re: Automated source translation of C++ to D
On Thursday, 21 August 2014 at 17:57:13 UTC, Joakim wrote: Yes, I'm aware of ddmd. You've mentioned many times that it only works because dmd is written using a very unC++-like style, to the point where github's source analyzer claims that dmd is written in 66.7% C, 28.4% D (presumably the tests right now), 4.4% C++, and 0.5% other. :) That's just because the C++ DMD files have a .c extension. The joke about it being written in C+ is fitting but the source code is pretty easily identified as C++ (if only because it makes frequent use of classes).
Re: Linker `undefined reference` errors when using scoped imports
On Thursday, 21 August 2014 at 17:09:33 UTC, Uranuz wrote: For now I can't an example of code. But sometimes I get Linker errors on Ubuntu Linux when using *scoped imports*. May be this issue happens on another platforms too. Does anybody experience the same problem when compiling programmes? I'll try to invent some example of code that illustrates this. Of course project where I got this is to long to post there in forum. I saw that in new release 2.066 there was some improvements about names mangling. But seems that these changes are not connected with this problem. May be it's just linker problem and compiler have nothing to do with it? So it's interesting to see any comments. Can it be that you are using incremental rebuilds?
Re: Linker `undefined reference` errors when using scoped imports
On Thursday, 21 August 2014 at 18:27:30 UTC, Dicebot wrote: On Thursday, 21 August 2014 at 17:09:33 UTC, Uranuz wrote: For now I can't an example of code. But sometimes I get Linker errors on Ubuntu Linux when using *scoped imports*. May be this issue happens on another platforms too. Does anybody experience the same problem when compiling programmes? I'll try to invent some example of code that illustrates this. Of course project where I got this is to long to post there in forum. I saw that in new release 2.066 there was some improvements about names mangling. But seems that these changes are not connected with this problem. May be it's just linker problem and compiler have nothing to do with it? So it's interesting to see any comments. Can it be that you are using incremental rebuilds? No there is an issue. I'm launching a dustmite, but considering it is a linking problem, it is gonna take ages.
Re: [OT] Re: Redesign of dlang.org
On Sunday, 27 July 2014 at 06:10:09 UTC, Andrei Alexandrescu wrote: On 7/26/14, 8:47 PM, H. S. Teoh via Digitalmars-d wrote: On Sat, Jul 26, 2014 at 07:39:50PM -0700, Andrei Alexandrescu via Digitalmars-d wrote: On 7/26/14, 6:30 PM, w0rp wrote: The std.algortihm documentation doesn't look good, and I don't have any good ideas for it. I find std.algorithm among the best documented libraries out there! I must be in denial... -- Andrei No, I'm not in denial! It can't be!!! Well correction: I think it's among the better documented modules in std. -- Andrei Still, all the documentation do not looks good.
Re: [OT] Re: Redesign of dlang.org
On Thursday, 21 August 2014 at 15:16:52 UTC, Dicebot wrote: I check various parts of documentation (not DDOC-generates Phobos part but manually written articles) on a regular basis. It is often faster to find via navigating then search query because term usage is spread all across. But you will get all that from the documentation subsection? I do think the frontpage should indicate that D is a systems programming language, though. I also think code samples that highlight main language features constructs belong on the front page. It should try to quickly give an enticing answer to questions like these: What is this D thing google sent me to? What does it look like? Is this project abandoned or active? Where can I get a trouble free install? What is the license? Where is the newbie tutorial? How active is the community/where are the forums? The second level would be answers to questions like: Where are the specs? Benchmarks? Academic papers? Bugfix responsiveness? Etc..
Re: Automated source translation of C++ to D
On 8/21/2014 10:57 AM, Joakim wrote: Given tools like libclang, how hard do you think it'd be to translate most of actual C++ to D? I'd say the possibility of that is about zero. Heck, we can't even do it 100% for C. The trouble is, D is not a perfect superset of C++, not even close: 1. multiple inheritance 2. SFINAE 3. Koenig lookup 4. tail mutability 5. overloading rules 6. operator overloading rules 7. fwd reference issues 8. macros (it's depressing how much modern C++ practice still heavily depends on the preprocessor) Does that really matter? In my not-so-humble experience, C++ programmers often, far too often, find some odd corner case in the language and build an entire store on it. I personally find this baffling, but it happens with depressing regularity. (In contrast, the C++ style used in DMD is very conservative and tends to run right down the middle of the road of C++, avoiding anything clever and corners and weird emergent behavior. This is the only reason why DDMD has even a prayer of working.)
Re: Automated source translation of C++ to D
On Thursday, 21 August 2014 at 21:06:09 UTC, Walter Bright wrote: On 8/21/2014 10:57 AM, Joakim wrote: Given tools like libclang, how hard do you think it'd be to translate most of actual C++ to D? I'd say the possibility of that is about zero. Heck, we can't even do it 100% for C. The trouble is, D is not a perfect superset of C++, not even close: 1. multiple inheritance 2. SFINAE 3. Koenig lookup 4. tail mutability 5. overloading rules 6. operator overloading rules 7. fwd reference issues 8. macros (it's depressing how much modern C++ practice still heavily depends on the preprocessor) Does that really matter? In my not-so-humble experience, C++ programmers often, far too often, find some odd corner case in the language and build an entire store on it. I personally find this baffling, but it happens with depressing regularity. (In contrast, the C++ style used in DMD is very conservative and tends to run right down the middle of the road of C++, avoiding anything clever and corners and weird emergent behavior. This is the only reason why DDMD has even a prayer of working.) OK, you would know better than anyone, thanks for the considered answer.
RFC: std.json sucessor
Following up on the recent std.jgrandson thread [1], I've picked up the work (a lot earlier than anticipated) and finished a first version of a loose blend of said std.jgrandson, vibe.data.json and some changes that I had planned for vibe.data.json for a while. I'm quite pleased by the results so far, although without a serialization framework it still misses a very important building block. Code: https://github.com/s-ludwig/std_data_json Docs: http://s-ludwig.github.io/std_data_json/ DUB: http://code.dlang.org/packages/std_data_json The new code contains: - Lazy lexer in the form of a token input range (using slices of the input if possible) - Lazy streaming parser (StAX style) in the form of a node input range - Eager DOM style parser returning a JSONValue - Range based JSON string generator taking either a token range, a node range, or a JSONValue - Opt-out location tracking (line/column) for tokens, nodes and values - No opDispatch() for JSONValue - this has shown to do more harm than good in vibe.data.json The DOM style JSONValue type is based on std.variant.Algebraic. This currently has a few usability issues that can be solved by upgrading/fixing Algebraic: - Operator overloading only works sporadically - No tag enum is supported, so that switch()ing on the type of a value doesn't work and an if-else cascade is required - Operations and conversions between different Algebraic types is not conveniently supported, which gets important when other similar formats get supported (e.g. BSON) Assuming that those points are solved, I'd like to get some early feedback before going for an official review. One open issue is how to handle unescaping of string literals. Currently it always unescapes immediately, which is more efficient for general input ranges when the unescaped result is needed, but less efficient for string inputs when the unescaped result is not needed. Maybe a flag could be used to conditionally switch behavior depending on the input range type. Destroy away! ;) [1]: http://forum.dlang.org/thread/lrknjl$co7$1...@digitalmars.com
Re: RFC: std.json sucessor
On Thursday, 21 August 2014 at 22:35:18 UTC, Sönke Ludwig wrote: Destroy away! ;) source/stdx/data/json/lexer.d(263:8)[warn]: 'JSONToken' has method 'opEquals', but not 'toHash'. source/stdx/data/json/lexer.d(499:65)[warn]: Use parenthesis to clarify this expression. source/stdx/data/json/parser.d(516:8)[warn]: 'JSONParserNode' has method 'opEquals', but not 'toHash'. source/stdx/data/json/value.d(95:10)[warn]: Variable c is never used. source/stdx/data/json/value.d(99:10)[warn]: Variable d is never used. source/stdx/data/json/package.d(942:14)[warn]: Variable val is never used. It's likely that you can ignore these, but I thought I'd post them anyways. (The last three are in unittest blocks, for example.)
Re: RFC: std.json sucessor
Someone needs to make a showbrianmycode bot: mention a D github repo and it runs static analysis for you.
Re: RFC: std.json sucessor
On Thursday, 21 August 2014 at 23:27:28 UTC, Justin Whear wrote: Someone needs to make a showbrianmycode bot: mention a D github repo and it runs static analysis for you. Why bother with mentioning a GitHub repo? Just make the bot periodically scan the DUB registry.
Re: [OT] Re: Redesign of dlang.org
On Thursday, 21 August 2014 at 04:59:20 UTC, Hubert wrote: https://www.dropbox.com/s/oicmwoboku136jq/dlang_test_redesign.png My emphasis has been on creating a friendly first impression; a lightweight page to introduce newcomers to D and get them started quickly. I think this is a sane design approach when it comes to D's current position in the market. I've not yet begun any work on the views for the documentation and similar pages with a larger amount of copy. (I hope I haven't missed any earlier design proposal that already looks like this.) Sort of reminds me of Ocaml's webpage, but more minimalistic. I think a lot of good ideas could come from looking at other language's webpages, Haskell's new webpage is similar to Ocaml's but has less content(it's also not finished yet)
Re: RFC: std.json sucessor
On Thursday, 21 August 2014 at 23:33:35 UTC, Idan Arye wrote: Why bother with mentioning a GitHub repo? Just make the bot periodically scan the DUB registry. It's kind of picky. http://i.imgur.com/SHNAWnH.png
Re: RFC: std.json sucessor
On 8/21/14, 7:35 PM, Sönke Ludwig wrote:
Following up on the recent std.jgrandson thread [1], I've picked up
the work (a lot earlier than anticipated) and finished a first version
of a loose blend of said std.jgrandson, vibe.data.json and some changes
that I had planned for vibe.data.json for a while. I'm quite pleased by
the results so far, although without a serialization framework it still
misses a very important building block.
Code: https://github.com/s-ludwig/std_data_json
Docs: http://s-ludwig.github.io/std_data_json/
DUB: http://code.dlang.org/packages/std_data_json
Say I have a class Person with name (string) and age (int) with a
constructor that receives both. How would I create an instance of a
Person from a json with the json stream?
Suppose the json is this:
{age: 10, name: John}
And the class is this:
class Person {
this(string name, int age) {
// ...
}
}
Re: RFC: std.json sucessor
I notice in the docs there are several references to a `parseJSON` and `parseJson`, but I can't seem to find where either of these are defined. Is this just a typo? Hope this helps: https://github.com/s-ludwig/std_data_json/search?q=parseJsontype=Code
Re: $100 bounty for help with Windows Service code
On Monday, 18 August 2014 at 21:23:38 UTC, Vladimir Panteleev wrote: On Monday, 18 August 2014 at 21:12:15 UTC, Tyler Jensen wrote: On Monday, 18 August 2014 at 18:24:15 UTC, Etienne wrote: http://www.dsource.org/projects/bindings/wiki/WindowsApi Browse the source of the latter link and you'll find Vladimir's fix. That's because I've just added it :) Here's the result of refactoring it. https://github.com/duovia/WindowsServiceInD
Re: [OT] Re: Redesign of dlang.org
On Thu, 21 Aug 2014 17:12:37 + via Digitalmars-d digitalmars-d@puremagic.com wrote: Don't forget that programmers are hipsters, and we need to take care of our image. i'm glad that i'm not a programmer then. signature.asc Description: PGP signature
