Re: Homebrew dmd betas
On Tuesday, 10 April 2018 at 08:46:55 UTC, John Colvin wrote: Available now on homebrew :) Thanks I try to keep homebrew up to date with the latest betas, but the stats show that almost no-one ever downloads them, despite reasonable numbers getting the stable version. See for example https://github.com/Homebrew/homebrew-core/pull/24348#issuecomment-367021918 . I will continue to keep adding the betas for my own use anyway, but please, PLEASE, install the betas and test them, it's so simple, just `brew upgrade dmd --devel`. You can then switch freely between the beta and the stable versions with `brew switch dmd 2.079.0`, `brew switch dmd 2.079.1-beta.1`. And for all other supported platforms but Windows, just use curl -fsS https://dlang.org/install.sh | bash -s dmd-beta to unpack the beta to ~/dlang, and source ~/dlang/dmd-2.079.1-beta.1/activate to use the beta compiler.
Re: #include C headers in D code
On Monday, 9 April 2018 at 11:03:48 UTC, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/ How do you deal with macros containing invalid D code, i.e. `#define foo(T) sizeof(T)`? -- /Jacob Carlborg
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 23:44:46 UTC, Atila Neves wrote: The beauty of using libclang is that name mangling issues don't exist. :) How is that not going to be an issue? Are you adding `pragma(mangle)` everywhere? -- /Jacob Carlborg
Re: #include C headers in D code
On 09/04/2018 11:03 PM, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/ The summary is that, modulo bugs, things like this work: #include void main() { printf("Hello world\n".ptr); } So far it's successfully compiled whilst #including pthread, libcurl, openssl and others. The blog and the github README have more information, and feel free to reply to this with questions. dub: http://code.dlang.org/packages/dpp reddit: https://www.reddit.com/r/programming/comments/8axj53/include_c_headers_in_d_code/ hacker news: It's in there somewhere, search around. Atila * Technically, "D + #include directives + C macros" Any chance objectice-c as well?
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Wednesday, April 11, 2018 05:23:58 really? via Digitalmars-d-announce wrote: > On Friday, 6 April 2018 at 17:36:20 UTC, H. S. Teoh wrote: > > Yeah, I think having expression syntax will make contracts more > > readable. We'll just have to see. > > Sorry, but I fail to see how (1) is more readable than (2) > > (1) > in(s.length > 0, "s must not be empty") > > (2) > in { assert(s.length > 0, "s must not be empty"); } > > > In (1) The assert .. is removed. > In (1) The scope indicators {} .. are removed. > In (1) The semicolon..is removed. > > Removing all these things equates to being more readable?? > > Sure, it makes it more concise, but more readable?? > > I assert that it does not. But now..do I use the assert keyword.. > or not? Do I end with semicolon..or not?? > > This just removes things that are still needed elsewhere in your > code, but now... you have to remember that sometimes you need > those things, and sometimes you don't. > > Better to have consistency over conciseness > > so glad to hear that existing syntax will remain. > (well, till someone decides that needs to go too) Many have considered the verboseness of contracts to be a major reason to avoid them. The newer syntax will help with that in the cases where all you need is a series of assertions. However, regardless of how anyone feels about the new syntax, there are cases where you need more than just a series of assertions (e.g. you need to declare one or more variables to use in the assertions). The older syntax is required for such cases, and it would make no sense to remove it even if we didn't care about avoiding code breakage. So, if you prefer the older syntax, then feel free to use it, even if the newer syntax will work. You'll be stuck reading the newer syntax in the code of anyone who prefers the newer syntax, so you can't necessarily avoid dealing with it, but you're not going to be forced to switch to the newer syntax if you don't want to. Personally, I think that new syntax is very straightforward. It may take some getting used to, but it's basically the same syntax as an assertion except that it has a different keyword, and because it's not a statement, it doesn't need a semicolon. It makes sense in its context, and ultimately, I don't think that it's really going to be readability problem. That being said, I'm probably still not going to bother with contracts simply because I don't see any real benefit over just putting assertions inside the function except in the cases where inheritance is involved. I find it a lot more tolerable than the old syntax, but I still find it to be pointless so long as contracts are the same thing as putting assertions inside the function (except when inheritance is involved). IMHO, for contracts to be worth much outside of the inheritance case, we'd need to do something like make it so that contracts are compiled in based on whether the caller used -release or not rather than whether the callee did. If that were done, then there would be real value in using contracts, and I'd be a lot more excited about the new syntax. As it is, it seems like a nice improvement that's ultimately pointless. - Jonathan M Davis
Re: DIP 1009 (Add Expression-Based Contract Syntax) Accepted
On Friday, 6 April 2018 at 17:36:20 UTC, H. S. Teoh wrote: Yeah, I think having expression syntax will make contracts more readable. We'll just have to see. Sorry, but I fail to see how (1) is more readable than (2) (1) in(s.length > 0, "s must not be empty") (2) in { assert(s.length > 0, "s must not be empty"); } In (1) The assert .. is removed. In (1) The scope indicators {} .. are removed. In (1) The semicolon..is removed. Removing all these things equates to being more readable?? Sure, it makes it more concise, but more readable?? I assert that it does not. But now..do I use the assert keyword.. or not? Do I end with semicolon..or not?? This just removes things that are still needed elsewhere in your code, but now... you have to remember that sometimes you need those things, and sometimes you don't. Better to have consistency over conciseness so glad to hear that existing syntax will remain. (well, till someone decides that needs to go too)
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 20:32:05 UTC, Seb wrote: On Tuesday, 10 April 2018 at 16:51:57 UTC, Atila Neves wrote: If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) Atila FYI people have been fighting with this for a long time: https://github.com/dlang/druntime/pull/1316 The beauty of using libclang is that name mangling issues don't exist. :) It's still not going to be easy, but that's one worry I won't have to bother with. Atila
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 20:32:05 UTC, Seb wrote: On Tuesday, 10 April 2018 at 16:51:57 UTC, Atila Neves wrote: If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) Atila FYI people have been fighting with this for a long time: https://github.com/dlang/druntime/pull/1316 FYI this appears to work just fine in Calypso: https://github.com/Syniurge/Calypso/blob/master/tests/calypso/libstdc%2B%2B/vector.d — David
Re: code-d 0.17.0 + serve-d 0.1.2
On Tuesday, 10 April 2018 at 03:37:59 UTC, evilrat wrote: On Monday, 9 April 2018 at 19:10:46 UTC, Samson wrote: [...] Disable "normal" code-d, close VS, remove %appdata%/code-d, launch VS & enable code-d beta serve-d, enjoy. [...] Thanks, your suggestion work for me. Many thanks to you
Re: code-d 0.17.0 + serve-d 0.1.2
On Tuesday, 10 April 2018 at 03:37:59 UTC, evilrat wrote: On Monday, 9 April 2018 at 19:10:46 UTC, Samson wrote: [...] Disable "normal" code-d, close VS, remove %appdata%/code-d, launch VS & enable code-d beta serve-d, enjoy. [...] Thanks your suggestion work for me. many thanks to you
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 16:51:57 UTC, Atila Neves wrote: If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) Atila FYI people have been fighting with this for a long time: https://github.com/dlang/druntime/pull/1316
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 19:28:09 UTC, Steven Schveighoffer wrote: On 4/10/18 2:36 PM, Atila Neves wrote: Haha, I remember. I do plan on dealing with emplace_back, but I have no idea how just yet and I was hoping nobody was going to call me on it until then. Busted! :P I think we all agree you aren't going to instantiate C++ templates in D (and who would want to). Do we? Do I? :P (I've actually seriously considered it) But since you are using a wrapper to call the compiler, and invoking clang anyway, generating a file to compile which calls the template to generate the object file for the method, and then using the symbol generated to bind to the method might be possible. Of course, you first have to compile your D code to see what templates to generate! So this is another extra step. That's one of my ideas. It could be as easy as generating a mock C++ template for vector, that then has a symbol that d++ recognizes and both replaces with a real call AND helps you figure out what C++ template to generate. -vcg-ast may help here. The details elude me right now, but that seems to make sense. Whatever this is going to be, it ain't going to be fast... Compiling C++ isn't known to be fast. ;) It might be possible to limit the damage by confining the C++ #includes to one D package or module so it doesn't get rebuilt every time. Atila
Re: #include C headers in D code
On 4/10/18 2:36 PM, Atila Neves wrote: Haha, I remember. I do plan on dealing with emplace_back, but I have no idea how just yet and I was hoping nobody was going to call me on it until then. Busted! :P I think we all agree you aren't going to instantiate C++ templates in D (and who would want to). But since you are using a wrapper to call the compiler, and invoking clang anyway, generating a file to compile which calls the template to generate the object file for the method, and then using the symbol generated to bind to the method might be possible. Of course, you first have to compile your D code to see what templates to generate! So this is another extra step. It could be as easy as generating a mock C++ template for vector, that then has a symbol that d++ recognizes and both replaces with a real call AND helps you figure out what C++ template to generate. -vcg-ast may help here. Whatever this is going to be, it ain't going to be fast... -Steve
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 18:01:37 UTC, Steven Schveighoffer wrote: On 4/10/18 12:51 PM, Atila Neves wrote: On Tuesday, 10 April 2018 at 13:53:34 UTC, Steven Schveighoffer wrote: If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) I hope you are right, but I remain skeptical :) If I may throw a curveball back at you, I recall a question at last year's dconf during the talk about interfacing with C++ STL about using emplace_back instead of push_back. And the questioner who happened to be sitting next to me said "meh, push_back isn't very useful, nobody uses push_back any more" :P -Steve Haha, I remember. I do plan on dealing with emplace_back, but I have no idea how just yet and I was hoping nobody was going to call me on it until then. Busted! :P Atila
Re: #include C headers in D code
On 4/10/18 12:51 PM, Atila Neves wrote: On Tuesday, 10 April 2018 at 13:53:34 UTC, Steven Schveighoffer wrote: If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) I hope you are right, but I remain skeptical :) If I may throw a curveball back at you, I recall a question at last year's dconf during the talk about interfacing with C++ STL about using emplace_back instead of push_back. And the questioner who happened to be sitting next to me said "meh, push_back isn't very useful, nobody uses push_back any more" :P -Steve
Re: code-d 0.17.0 + serve-d 0.1.2
Am 10.04.2018 um 14:27 schrieb WebFreak001: > On Monday, 9 April 2018 at 21:45:57 UTC, Johannes Loher wrote: >> Am 04.04.2018 um 20:34 schrieb greatsam4sure: >>> [...] >> I just tried to get this to work, too, but I was not able to get it to >> work correctly. It seems that running dub fails somehow: >> >> [...] > > hm before it would have completely crashed workspace-d/serve-d to a > point where nothing would work, now you basically only get stdlib and a > guess of further import paths. Can you make a minimal test case where > this happens? It is probably due to some dub.json settings. But as I use > dub as a library it should work the same as just calling `dub build` You are right, it indeed seems to be a dub problem. Running `dub build` gives me "Could not resolv configuration for package vibe-d". The strange thing is, it workls correctly on Linux / OS X with the same dub/dmd versions... I tried it with another project with a more simple dub.json and it works fine out of the box. Very nice job!
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 13:53:34 UTC, Steven Schveighoffer wrote: On 4/9/18 7:03 AM, Atila Neves wrote: [...] Awesome. Can't say I will use it, as I don't use C much, but I understand how difficult a task this is. Thanks! If you get to the point where you can #include , it will be doubly impressive! Not *if*, *when*. ;) Atila
Re: Homebrew dmd betas
On 4/10/18 1:46 AM, John Colvin wrote: On Saturday, 7 April 2018 at 18:39:12 UTC, Martin Nowak wrote: First beta for the 2.079.1 patch release. Comes with a handful of fixes. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.079.1.html Please report any bugs at https://issues.dlang.org - -Martin Available now on homebrew :) [snip] I haven't tried the betas yet, but many thanks for keeping homebrew up to date with the regular releases!
Re: code-d 0.17.0 + serve-d 0.1.2
On Tuesday, 10 April 2018 at 13:11:16 UTC, evilrat wrote: On Tuesday, 10 April 2018 at 11:54:47 UTC, WebFreak001 wrote: fyi "deprecated" code-d beta and normal code-d is exactly the same plugin right now using exactly the same serve-d versions, except for the deprecation message. I wouldn't be complaining if it's not the case. With normal code-d it does remove everything in %appdata%/code-d on start, re-setting config paths(even though for exapmle dub is in PATH), downloading git repo, fails to build, and repeat, while with beta there is no such issues. I would also suggest you to add explicit --compiler=dmd switch to build invocation since for example in my case dmd was in PATH env after ldc and so ldc used by default, which of course doesn't have x86_mscoff arch. I also think it is probably better to add --build=release too, since users usually don't do debug on that binaries. No dmd has an optimization issue that it removes code making the program completely broken and freeze on IO if compiled with -O, which is implied by --build=release. I will never use build=release with dmd. What about workspaces? Let for exapmle have main project (really just a dub project with single app.d for testing library) and library project in one workspace. I don't get any autocompletion from both projects. It also doesn't seems to work with dependency that has path property set, at least not when it's relative. Is this ok? Everything dub dependency related should work, I literally use dub as a library for this. Multi workspaces in vscode aren't implemented yet though.
Re: #include C headers in D code
On 4/9/18 7:03 AM, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* https://atilanevesoncode.wordpress.com/2018/04/09/include-c-headers-in-d-code/ The summary is that, modulo bugs, things like this work: #include void main() { printf("Hello world\n".ptr); } So far it's successfully compiled whilst #including pthread, libcurl, openssl and others. The blog and the github README have more information, and feel free to reply to this with questions. dub: http://code.dlang.org/packages/dpp reddit: https://www.reddit.com/r/programming/comments/8axj53/include_c_headers_in_d_code/ hacker news: It's in there somewhere, search around. Atila * Technically, "D + #include directives + C macros" Awesome. Can't say I will use it, as I don't use C much, but I understand how difficult a task this is. If you get to the point where you can #include , it will be doubly impressive! -Steve
Re: code-d 0.17.0 + serve-d 0.1.2
On Tuesday, 10 April 2018 at 11:54:47 UTC, WebFreak001 wrote: fyi "deprecated" code-d beta and normal code-d is exactly the same plugin right now using exactly the same serve-d versions, except for the deprecation message. I wouldn't be complaining if it's not the case. With normal code-d it does remove everything in %appdata%/code-d on start, re-setting config paths(even though for exapmle dub is in PATH), downloading git repo, fails to build, and repeat, while with beta there is no such issues. I would also suggest you to add explicit --compiler=dmd switch to build invocation since for example in my case dmd was in PATH env after ldc and so ldc used by default, which of course doesn't have x86_mscoff arch. I also think it is probably better to add --build=release too, since users usually don't do debug on that binaries. What about workspaces? Let for exapmle have main project (really just a dub project with single app.d for testing library) and library project in one workspace. I don't get any autocompletion from both projects. It also doesn't seems to work with dependency that has path property set, at least not when it's relative. Is this ok?
Re: code-d 0.17.0 + serve-d 0.1.2
On Monday, 9 April 2018 at 21:45:57 UTC, Johannes Loher wrote: Am 04.04.2018 um 20:34 schrieb greatsam4sure: [...] I just tried to get this to work, too, but I was not able to get it to work correctly. It seems that running dub fails somehow: [...] hm before it would have completely crashed workspace-d/serve-d to a point where nothing would work, now you basically only get stdlib and a guess of further import paths. Can you make a minimal test case where this happens? It is probably due to some dub.json settings. But as I use dub as a library it should work the same as just calling `dub build`
Re: code-d 0.17.0 + serve-d 0.1.2
On Tuesday, 10 April 2018 at 03:37:59 UTC, evilrat wrote: On Monday, 9 April 2018 at 19:10:46 UTC, Samson wrote: Today I update code-d serve-d and vsc. After which I got the notification that WebFreak001 has deprecate code-d serve-d beta and auto completion stop working. I saw code-d extension with the same icon as code-d serve-d beta so I install it. After which code hinting and auto completion don't still. What is the solution to this problem? Disable "normal" code-d, close VS, remove %appdata%/code-d, launch VS & enable code-d beta serve-d, enjoy. We're in the same boat dude. I just did clean install of whole D ecosystem from 6 months old setup where everything was more or less working, and followed this treacherous deprecation message, got code-d 0.17.1 with betastream option instead of my trusty beta 0.17.9... OMG it is broken in so many ways... it overwrites dub/serve-d paths settings, it messes with permissions, it removes already existing dub, dcd and serve-d executables!!! well, don't store them in the code-d folder, it won't remove or mess up anything outside its own folder and it won't change the user settings if they point to valid executables either. Reverted back to "deprecated" beta, at least it somewhat working, it is still incredibly slow on showing meaningful completions, doesn't seem to recognize half of the project, and seems to be completely not working with workspaces, but it is better than nothing. Overall I've got an awful experience from code-d. Now, unfortunattely, there is even no adequate editor with decent performance & usability on Windows, I mean yeah there is still visual-d but it takes about 3 seconds to actually show completions, and code-d is completely broken right now. fyi "deprecated" code-d beta and normal code-d is exactly the same plugin right now using exactly the same serve-d versions, except for the deprecation message.
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 09:36:39 UTC, Atila Neves wrote: On Monday, 9 April 2018 at 20:19:35 UTC, Seb wrote: On Monday, 9 April 2018 at 19:36:23 UTC, Atila Neves wrote: On Monday, 9 April 2018 at 18:15:33 UTC, kinke wrote: [...] This whole idea came about because a couple of years ago I was in a team that was responsible for legacy code written in C which had no tests. To write tests, we needed both to write the tests themselves and some fakes/mocks/doubles for the code that we depended on - essentially a whole operating system. I wasn't going to write that in C, since life is too short for that. [...] Speaking of dstep - it has greatly improved over the last years. I'm interested what stop you from using it or improving it (instead of rolling your own tool)? I tried using dstep as the translation engine to avoid reinventing the wheel. I'm lazy, I don't want to write code that doesn't neeed to be written! Nice work. I prefer the DStep approach of translating the headers to D, but obviously it's not going to be as easy for the user as this, so this approach has its uses too. Regarding "reinventing the wheel," I liked this recent blog post giving reasons why it can be a viable approach: https://blog.cerebralab.com/#!/blog/11
Re: #include C headers in D code
On Tuesday, 10 April 2018 at 08:45:06 UTC, Walter Bright wrote: On 4/9/2018 4:03 AM, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* Very nice work, and great article! Thanks!
Re: #include C headers in D code
On Monday, 9 April 2018 at 20:19:35 UTC, Seb wrote: On Monday, 9 April 2018 at 19:36:23 UTC, Atila Neves wrote: On Monday, 9 April 2018 at 18:15:33 UTC, kinke wrote: [...] This whole idea came about because a couple of years ago I was in a team that was responsible for legacy code written in C which had no tests. To write tests, we needed both to write the tests themselves and some fakes/mocks/doubles for the code that we depended on - essentially a whole operating system. I wasn't going to write that in C, since life is too short for that. [...] Speaking of dstep - it has greatly improved over the last years. I'm interested what stop you from using it or improving it (instead of rolling your own tool)? I tried using dstep as the translation engine to avoid reinventing the wheel. I'm lazy, I don't want to write code that doesn't neeed to be written! Unfortunately, dstep makes assumptions that are valid for it's trying to do that aren't for what I am, and ultimately made it very hard. The refactoring that would be needed would have been more work than doing it from scratch, so I sighed, cracked my knuckles, and wrote a bunch of code I didn't really want to. I did copy the part of its test suite that was applicable though.
Homebrew dmd betas
On Saturday, 7 April 2018 at 18:39:12 UTC, Martin Nowak wrote: First beta for the 2.079.1 patch release. Comes with a handful of fixes. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.079.1.html Please report any bugs at https://issues.dlang.org - -Martin Available now on homebrew :) I try to keep homebrew up to date with the latest betas, but the stats show that almost no-one ever downloads them, despite reasonable numbers getting the stable version. See for example https://github.com/Homebrew/homebrew-core/pull/24348#issuecomment-367021918 . I will continue to keep adding the betas for my own use anyway, but please, PLEASE, install the betas and test them, it's so simple, just `brew upgrade dmd --devel`. You can then switch freely between the beta and the stable versions with `brew switch dmd 2.079.0`, `brew switch dmd 2.079.1-beta.1`. To inspect what versions you have installed, `brew info dmd`. To uninstall specific versions, `brew switch` to the relevant version then run `brew uninstall dmd`. The same steps apply for any other betas on homebrew. I try to keep dmd, dub, ldc, dfix, dfmt and dcd up to date. If I'm late updating something, you can try nagging me or you can DIY, take a look at https://github.com/Homebrew/homebrew-core/pulls?utf8=%E2%9C%93&q=is%3Apr+dmd for examples of how to submit the update yourself.
Re: #include C headers in D code
On 4/9/2018 4:03 AM, Atila Neves wrote: Here's my blog post about my project that allows directly #including C headers in D* Very nice work, and great article!