Changelog
On 08/05/2015 01:57 AM, Martin Nowak wrote: Release Candidate for 2.068.0 To make this a successful release we need to work on the changelog, so that the rest of the world can know what we actually did. Right now it only contains a few entries and the ugly bug list. http://dlang.org/changelog.html Here are lists of PRs that still need a changelog entry. https://github.com/D-Programming-Language/dmd/pulls?q=label%3Achangelog_v2.068+is%3Aclosed https://github.com/D-Programming-Language/druntime/pulls?q=label%3Achangelog_v2.068+is%3Aclosed https://github.com/D-Programming-Language/phobos/pulls?q=label%3Achangelog_v2.068+is%3Aclosed Please add the 'pending changelog' tag once you're working on an entry to avoid double efforts. Changes need to go into the stable branch of dlang.org. https://github.com/D-Programming-Language/dlang.org/blob/stable/changelog.dd Also we need to go through the list of PRs and tag them with changelog_v2.068 if anything noticeable was merged. If everbody does it for his own PRs we're done very fast. https://github.com/D-Programming-Language/dmd/pulls?q=merged%3A%3E%3D2015-03-24 https://github.com/D-Programming-Language/druntime/pulls?q=merged%3A%3E%3D2015-03-24 https://github.com/D-Programming-Language/phobos/pulls?q=merged%3A%3E%3D2015-03-24 To get a list of only your PRs merged into phobos, select the author. https://github.com/D-Programming-Language/phobos/pulls?q=merged%3A%3E%3D2015-03-24+author%3AMartinNowak https://trello.com/c/iY3PYSeQ/37-changelog-changelog-changelog -Martin
line numbers for linux exception traces
If you just download this little file: http://arsdnet.net/dcode/linetrace.d and add it to your build, when compiling in debug mode, it will translate the addresses into line numbers (by simply piping out to addr2line on the command line) No modification to your program is required. before: dmd yourapp.d -g object.Exception@x.d(4): test ./x(_Dmain+0xb) [0x808276b] ./x(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x12) [0x809215a] ./x(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x18) [0x80920d0] ./x(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x27) [0x809211f] ./x(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x18) [0x80920d0] ./x(_d_run_main+0x166) [0x8092066] ./x(main+0x14) [0x8085b9c] /lib/libc.so.6(__libc_start_main+0xf3) [0xf7321773] after: dmd yourapp.d linetrace.d -g object.Exception@x.d(4): test ./x(void x.t()+0x3e) [/home/me/test/x.d:5] ./x(_Dmain+0xb) [/home/me/test/x.d:11] ./x(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x12) [0x80b993a] ./x(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x18) [0x80b98b0] ./x(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x27) [0x80b98ff] ./x(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x18) [0x80b98b0] ./x(_d_run_main+0x166) [0x80b9846] ./x(main+0x14) [0x80ac71c] /lib/libc.so.6(__libc_start_main+0xf3) [0xf7318773] Notice the line numbers on the first two lines. I also added a -version=hide_names that will cut out the function names (and the druntime lines) with the logic being that the line number in your own code is probably the most relevant part to you anyway and you don't need any distractiions: dmd yourapp.d linetrace.d -g -version=hide_names object.Exception@x.d(4): test /home/me/test/x.d:5 /home/me/test/x.d:11 My code isn't too complex: it wraps the default handler then manipulates the string using plain phobos techniques. Inefficient surely, but since the program is probably dying anyway when this is called, I don't mind it. addr2line does need to be available on the system for this to work though. If it isn't, the old address behavior should still work. I suspect this will also work on other posix systems but I haven't tried. But the simple code there ought to be easy enough for you to customize to your liking too.
Re: line numbers for linux exception traces
Oh also a note about addr2line's output on my computer at least: it prints the line of the *next* instruction after the function call, which can be a few lines away sometimes. But still, close enough: go to the line it references then look immediately before it and you should see the function call referred to in the stack trace.
Re: line numbers for linux exception traces
On Wednesday, 5 August 2015 at 15:57:46 UTC, Adam D. Ruppe wrote: If you just download this little file: http://arsdnet.net/dcode/linetrace.d and add it to your build, when compiling in debug mode, it will translate the addresses into line numbers (by simply piping out to addr2line on the command line) No modification to your program is required. There already is http://code.dlang.org/packages/backtrace-d. And there exists even an ELF based backtrace, but I'm still waiting for someone to polish it for druntime. https://issues.dlang.org/show_bug.cgi?id=11870
Re: Changelog
On Wednesday, 5 August 2015 at 06:45:56 UTC, Martin Nowak wrote: On 08/05/2015 01:57 AM, Martin Nowak wrote: Release Candidate for 2.068.0 To make this a successful release we need to work on the changelog, so that the rest of the world can know what we actually did. Right now it only contains a few entries and the ugly bug list. Where does that changelog come from? I made some pull requests against a file that I thought was the changelog to document some Phobos changes that got merged, but now I don't see it on dlang.org. https://github.com/D-Programming-Language/dlang.org/pull/1028/files https://github.com/D-Programming-Language/dlang.org/pull/1027/files
Re: Changelog
On Wednesday, 5 August 2015 at 19:04:29 UTC, Brian Schott wrote: Where does that changelog come from? I made some pull requests against a file that I thought was the changelog to document some Phobos changes that got merged, but now I don't see it on dlang.org. https://github.com/D-Programming-Language/dlang.org/pull/1028/files https://github.com/D-Programming-Language/dlang.org/pull/1027/files Your stuff has been moved to the 2.069 section: https://github.com/D-Programming-Language/dlang.org/blob/8bb4b6ea3699f4061d86dcb26459149d45a2958e/changelog.dd#L5-L16 hasUDA seems to be in 2.068, so that should be moved back to the 2.068 section. getUDAs and getSymbolsByUDA don't seem to have made it, so they're correctly commented out for now.
Visual D 0.3.42 released
Hi, there is a new version of Visual D available at http://rainers.github.io/visuald/visuald/StartPage.html Major new features in version 0.3.42: * DustMite integration, see http://rainers.github.io/visuald/visuald/DustMite.html * integration with the Visual Studio Performance Wizard * cv2pdb: improved DWARF support, integration with Visual Studio 2015 * mago: support for associative arrays in dmd 2.068. * demangling D/C++ symbols in disassembly See http://rainers.github.io/visuald/visuald/VersionHistory.html for the full version history. Visual D is a Visual Studio extension that adds D language support to VS2005-2015. It is written in D, its source code can be found on github: https://github.com/D-Programming-Language/visuald, pull requests are welcome. Rainer
Re: Rant after trying Rust a bit
On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote: ... One thing I didn't see mentioned at all is Rust's plugin system. Rust plugin to embed C++ directly in Rust: https://github.com/mystor/rust-cpp Rust plugin to use Rust with whitespace instead of braces: https://github.com/mystor/slag Syntax extensions, lint plugins, etc are all possible via the plugin interface. https://doc.rust-lang.org/book/compiler-plugins.html Honestly, this is pretty cool :/ This thread is really long so I didn't read all the posts. Sorry if this has been mentioned.
Re: Rant after trying Rust a bit
On Wednesday, 5 August 2015 at 04:10:22 UTC, Jonathan M Davis wrote: To get code coverage in C++, I'd have to go track down a tool to do it. There is none which is used as part of our normal build process at work. As it is, we only have unit tests because I went and added what was needed to write them and have been writing them. I also tend to use the features that can be directly used from the compiler switches more than external programs. I tend to look at --help first. Maybe one should also list programs that are distributed with the compiler in the compiler --help listing.
Re: Rant after trying Rust a bit
On Wednesday, 5 August 2015 at 06:03:14 UTC, rsw0x wrote: Syntax extensions, lint plugins, etc are all possible via the plugin interface. https://doc.rust-lang.org/book/compiler-plugins.html Honestly, this is pretty cool :/ Yes, it looks very cool. It lowers the threshold for experimentation and testing new ideas.
Re: assert(0) behavior
On 8/4/2015 8:26 PM, deadalnix wrote: On Tuesday, 4 August 2015 at 20:40:47 UTC, deadalnix wrote: Would you be of the opinion that assert should be a statement rather than an expression ? unreadability in the middle of expressions, especially when evaluation order is not well defined, is close to impossible to get right. Ping ? Walter ? If you want it as its own statement, write it that way. I don't see a need to change the language, nor would the breakage it would cause be justified.
Re: assert(0) behavior
On Wednesday, 5 August 2015 at 05:51:32 UTC, Ola Fosheim Grøstad wrote: specification to the code for validation/documentation purposes. Err... Verification, usually not validation.
Re: assert(0) behavior
On Monday, 3 August 2015 at 23:57:36 UTC, Steven Schveighoffer wrote: At the very least, assert(0, message) should be a compiler error, the message is unused information. Only if you compile in -release mode. Without wanting to get into a bikeshedding debate, I think that flag name may be mislead: it's not about release vs. development, it's about the tradeoff you are making between speed and safety.
Re: assert(0) behavior
On Wednesday, 5 August 2015 at 08:09:49 UTC, Joseph Rushton Wakeling wrote: On Monday, 3 August 2015 at 23:57:36 UTC, Steven Schveighoffer wrote: At the very least, assert(0, message) should be a compiler error, the message is unused information. Only if you compile in -release mode. Without wanting to get into a bikeshedding debate, I think that flag name may be mislead: it's not about release vs. development, it's about the tradeoff you are making between speed and safety. That's arguably true, but historically, release builds are where you turn off assertions and turn on optimizations. So, it does pretty much what most folks would expect from a release build (though some folks might assume that it turns on optimizations as well, which it doesn't). Now, there are good reasons to leave assertions in in release builds, but then you're arguably just using your debug builds in production (probably because you don't need the efficiency gain and are too paranoid to risk turning the assertions off). So, you have a good point, but really, -release does with assertions what's normally expected of release builds, so I don't think that it's actually misleading at all. - Jonathan M Davis
Re: D for Game Development
On Thursday, 30 July 2015 at 13:44:41 UTC, deadalnix wrote: On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote: D is really cool and makes a good candidate for developing a game. Are there any guys out there using D for indie games? For some time I have been seeing some cool game engine being developed in the DUB repo. What more is happening? I don't see derelictSDl and derelictSFML activities much. Whatup? GC's up. Regarding D's GC and Games written in D you can also take a look at a old project of mine and the results that came out of it. http://3d.benjamin-thaut.de/?p=20 Kind Regards Benjamin Thaut
Re: D for Game Development
On Tuesday, 4 August 2015 at 19:14:51 UTC, Rick wrote: Unfortunately I'm regrettably having to reconsider my decision to start a game project (or any project requiring significant time investment) in D. Not because of the language or compiler, but rather because of the lack maturity in the supporting tools; specifically, a debugger. I should say upfront that this seems to be more gravely affecting OSX than other platforms, but scouring forums and wikis has made it apparent that no platform is completely devoid of obstacles when it comes to functionally debugging D programs. To a certain extent, one can alternatively diagnose and fix bugs with verbose logging, assertions, and exceptions; but memory related bugs become exponentially more difficult to work through without being able to properly breakpoint, step through execution, and observe all variables in the current scope. gdb works fine on OS X and has D support.
Re: assert(0) behavior
On Wednesday, 5 August 2015 at 06:37:21 UTC, Walter Bright wrote: On 8/4/2015 8:26 PM, deadalnix wrote: On Tuesday, 4 August 2015 at 20:40:47 UTC, deadalnix wrote: Would you be of the opinion that assert should be a statement rather than an expression ? unreadability in the middle of expressions, especially when evaluation order is not well defined, is close to impossible to get right. Ping ? Walter ? If you want it as its own statement, write it that way. I don't see a need to change the language, nor would the breakage it would cause be justified. I suppose he's asking as maintainer of SDC.
Re: assert(0) behavior
On 4 August 2015 at 00:54, Walter Bright via Digitalmars-d digitalmars-d@puremagic.com wrote: On 8/3/2015 8:50 AM, Steven Schveighoffer wrote: 1. They aren't removed, they are replaced with a nearly useless segfault. Not useless at all: 1. The program does not continue running after it has failed. (Please, let's not restart that debate. 2. Running it under a debugger, the location of the fault will be identified. 2. If we are going to put something in there instead of assert, why not just throw an error? Because they are expensive. To keep asserts in all their glory in released code, do not use the -release switch. I think as a guideline, there are really only be two places where using an assert makes sense in druntime/phobos. 1. Internal modules, such as rt and core.internal. 2. Inside contracts (in, out, invariant) or unittests. Everywhere else - *especially* if it's part of a public API like core.time - you should throw an Exception or Error based on what you see fit. Because of this view, I'm not really in agreement with the addition of a core.abort module. Regards Iain
Re: Wiki article: Starting as a Contributor
On Tuesday, 4 August 2015 at 19:56:42 UTC, Jacob Carlborg wrote: On 03/08/15 23:25, Andrei Alexandrescu wrote: I had to set up dmd and friends on a fresh Ubuntu box, so I thought I'd document the step-by-step process: http://wiki.dlang.org/Starting_as_a_Contributor Along the way I also hit a small snag and fixed it at https://github.com/D-Programming-Language/dlang.org/pull/1049 Further improvements are welcome. I recommend turning this wiki page into a new page, Contribute, at dlang.org. Put it as a top level menu item (or possibly under Community). This page could also contain information how to make a pull request. Ther are already articles covering this: http://wiki.dlang.org/Building_DMD http://wiki.dlang.org/Pull_Requests
Re: Rant after trying Rust a bit
On Wednesday, 5 August 2015 at 06:03:14 UTC, rsw0x wrote: This thread is really long so I didn't read all the posts. Sorry if this has been mentioned. Don't worry, I don't recall anybody talking about it. Nevertheless, plugins aren't unique to Rust: GCC and Clang allow plugins. Nevertheless, I think that the Rust C++ plugin you posted was cool. Reminds me of Rcpp.
Re: D for Game Development
On Wednesday, 5 August 2015 at 09:03:47 UTC, John Colvin wrote: On Tuesday, 4 August 2015 at 19:14:51 UTC, Rick wrote: Unfortunately I'm regrettably having to reconsider my decision to start a game project (or any project requiring significant time investment) in D. Not because of the language or compiler, but rather because of the lack maturity in the supporting tools; specifically, a debugger. I should say upfront that this seems to be more gravely affecting OSX than other platforms, but scouring forums and wikis has made it apparent that no platform is completely devoid of obstacles when it comes to functionally debugging D programs. To a certain extent, one can alternatively diagnose and fix bugs with verbose logging, assertions, and exceptions; but memory related bugs become exponentially more difficult to work through without being able to properly breakpoint, step through execution, and observe all variables in the current scope. gdb works fine on OS X and has D support. Can you enlighten me as to what configuration you've confirmed this on? I'm on OSX: 10.9.5 (Mavericks) GDB: GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (building newer from source tends to fail to compile) DMD: DMD64 D Compiler v2.067 GCC: Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) At best, I can _sometimes_ hit breakpoints when using Mono-D, it's inconsistent. Even when a breakpoint is hit however, GDB only recognizes the current 'this' value; it doesn't recognize any frame / local variables other than 'this', global variables, etc., though it does recognize the call-stack at least. When using GDB directly from a terminal, the only D source file it recognizes for the purpose of setting breakpoints or listing source code is app.d (which contains the main() entry-point). Also have tried compiling with all combinations of -g, -gc, -debug, -gs, and -cov. None seem to improve the situation.
Re: DUB RC 0.9.24-rc.1 ready for testing
On 04/08/2015 16:52, Bruno Medeiros wrote: BTW --bare is indeed welcome as I have to do some juggling to run several tests with code that integrates with DUB. But --bare is still very limited: you cant run `dub describe` on a directory of a DUB package. You have to run on the parent directory, which means you need to figure out the actual name of the DUB package (merely specifying the directory doesn't work). A bit of an annoyance. Why not simply have an option to specify the directory of the DUB local registry (the one with the local-packages.json file)? Such an option might have other uses as well, even beyond `dub describe`. This registry singleton shouldn't be hardcoded to just a default location. Opened https://github.com/D-Programming-Language/dub/issues/641 -- Bruno Medeiros https://twitter.com/brunodomedeiros
Re: Rant after trying Rust a bit
On 08/03/2015 11:19 AM, Max Samukha wrote: On Monday, 3 August 2015 at 06:52:41 UTC, Timon Gehr wrote: On 08/02/2015 09:02 PM, Max Samukha wrote: On Sunday, 26 July 2015 at 23:29:18 UTC, Walter Bright wrote: For example, the '+' operator. Rust traits sez gee, there's a + operator, it's good to go. Ship it! Meanwhile, you thought the function was summing some data, when it actually is creating a giant string, or whatever idiot thing someone decided to use '+' for. Number addition and string concatenation are monoid operations. In this light, '+' for both makes perfect sense. '+' is usually used to denote the operation of an abelian group. The point is that '+' for string concatenation is no more of an 'idiot thing' than '~'. My point is that it is. String concatenation is not commutative.
Re: D for Game Development
On Wednesday, 5 August 2015 at 08:53:39 UTC, Benjamin Thaut wrote: Regarding D's GC and Games written in D you can also take a look at a old project of mine and the results that came out of it. http://3d.benjamin-thaut.de/?p=20 Towards the end you list some performance and memory leaking issues in D. Have you seen improvement in these areas?
Re: assert(0) behavior
On Wednesday, 5 August 2015 at 10:31:40 UTC, Iain Buclaw wrote: I think as a guideline, there are really only be two places where using an assert makes sense in druntime/phobos. 1. Internal modules, such as rt and core.internal. 2. Inside contracts (in, out, invariant) or unittests. Everywhere else - *especially* if it's part of a public API like core.time - you should throw an Exception or Error based on what you see fit. I think that it makes perfect sense to use assertions inside of druntime or Phobos functions when testing the correctness of their internal state, but it obviously can't be expected that they run normally (at least in non-templated code), and it can't be expected that much beyond the unit tests run them (at least in non-templated code), since almost no one is going to be using a debug version of druntime/Phobos. Certainly, I don't see anything special about druntime or Phobos with regards to assertions except for the fact that not much beyond the unit tests is going to be using druntime/Phobos in debug mode, so assertions in non-templated code simply aren't going to be doing anything outside of the unit test builds. As for assert(0) specifically, it makes sense in cases where the code should never ever hit that point, and there's a serious problem if it does (e.g. the default branch of a switch statement where it should be impossible for that branch to be hit), but it was a mistake to use it in core.time, since that was failing based on a system call returning a failure (which should basically never happen in this case, but it still depends on the environment and thus could conceivably fail as opposed to only ever failing if druntime's code is definitely broken). Because of this view, I'm not really in agreement with the addition of a core.abort module. Well, then please comment on the PR: https://github.com/D-Programming-Language/druntime/pull/1337 It seems to me that the whole point of abort is to work around the fact that Walter doesn't want assert(0) to print messages before the HLT instruction in release mode. Certainly, I can't see any other reason for it. - Jonathan M Davis
Re: assert(0) behavior
On 8/5/15 12:46 PM, Jonathan M Davis wrote: Well, then please comment on the PR: https://github.com/D-Programming-Language/druntime/pull/1337 It seems to me that the whole point of abort is to work around the fact that Walter doesn't want assert(0) to print messages before the HLT instruction in release mode. Certainly, I can't see any other reason for it. No, the reason is, if you want to print something before halting, and you don't want to use any subsystems that you suspect are corrupt (e.g. stdio), it's not a simple task. This makes it as simple as calling assert. I thought it would be a useful utility. Surely, we can improve core.time to throw in this case instead, since the case where the ticksPerSecond is zero only happens when the OS did not provide it. A slight possibility is that the memory was corrupted. But I think the abort function still has use in other cases. -Steve
Re: Rant after trying Rust a bit
On Wednesday, 5 August 2015 at 15:58:28 UTC, Timon Gehr wrote: The point is that '+' for string concatenation is no more of an 'idiot thing' than '~'. My point is that it is. String concatenation is not commutative. Ok, good point. Except that '+' in a programming language is not the mathematical '+'. Why define '+' as strictly commutative operation and not more generally as an abstract binary operation, considering the middle dot is unavailable? Or, if we want to stick to the math notation, then '*' would be more appropriate than the idiot thing '~'.
Re: D for Game Development
On Wednesday, 5 August 2015 at 15:08:46 UTC, Rick wrote: GCC: Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) I'm afraid apple is fucking with you...
Re: Wiki article: Starting as a Contributor
On 05/08/15 13:28, Gary Willoughby wrote: Ther are already articles covering this: http://wiki.dlang.org/Building_DMD http://wiki.dlang.org/Pull_Requests My point was that I think it should not be on the wiki, instead it should be on dlang.org, clearly visible. -- /Jacob Carlborg
Re: Rant after trying Rust a bit
On Wednesday, 5 August 2015 at 17:12:29 UTC, Max Samukha wrote: On Wednesday, 5 August 2015 at 15:58:28 UTC, Timon Gehr wrote: The point is that '+' for string concatenation is no more of an 'idiot thing' than '~'. My point is that it is. String concatenation is not commutative. Ok, good point. Except that '+' in a programming language is not the mathematical '+'. Why define '+' as strictly commutative operation and not more generally as an abstract binary operation, considering the middle dot is unavailable? Or, if we want to stick to the math notation, then '*' would be more appropriate than the idiot thing '~'. Nobody want to stay in the math world. Not that math are worthless, but it has this tendency to make simple things absurdly complex by requiring you to learn a whole area of math to understand the introduction. This is commonly referred as the monad curse: once you understand what a monad is, you loose all capacity to explain it. In fact, Most developers have used some sort of monad, but only a very small portion know they were using one or can explain you what it is. Mathematical language is geared toward generality and correctness, not practicality. That makes sens in the context of math, that do not in the context of every day programming.
Re: Wiki article: Starting as a Contributor
On Wednesday, 5 August 2015 at 17:27:40 UTC, Jacob Carlborg wrote: On 05/08/15 13:28, Gary Willoughby wrote: Ther are already articles covering this: http://wiki.dlang.org/Building_DMD http://wiki.dlang.org/Pull_Requests My point was that I think it should not be on the wiki, instead it should be on dlang.org, clearly visible. Let it be in the wiki. Once dust settle down, it can be moved to the website. Changing the wiki is easier than changing dlang.org, so the wiki seems like a better incubator.
Re: D for project in computational chemistry
Dear all, Thank you for your replies. I am now really convinced that D is a decent choice for my project (also I am really happy to see that the forum is really active and apparently many of you use D for your scientific projects). I am just looking forward to writing the code. I had a very quick look at lecture given at DConf 2015 - good talk, and I believe D has a big promise in Science. Perhaps the only problem being is the mathematical library, like numpy. Until now I usually wrote the prototype algorithms in Python and then translated the code onto C for speed. It would be just dream to use only one language. The dominant languages in science now for production codes are Fortran or C/C++, may be D could become another option? With kind regards, Yury
Re: D for Game Development
On Wednesday, 5 August 2015 at 15:08:46 UTC, Rick wrote: On Wednesday, 5 August 2015 at 09:03:47 UTC, John Colvin wrote: On Tuesday, 4 August 2015 at 19:14:51 UTC, Rick wrote: Unfortunately I'm regrettably having to reconsider my decision to start a game project (or any project requiring significant time investment) in D. Not because of the language or compiler, but rather because of the lack maturity in the supporting tools; specifically, a debugger. I should say upfront that this seems to be more gravely affecting OSX than other platforms, but scouring forums and wikis has made it apparent that no platform is completely devoid of obstacles when it comes to functionally debugging D programs. To a certain extent, one can alternatively diagnose and fix bugs with verbose logging, assertions, and exceptions; but memory related bugs become exponentially more difficult to work through without being able to properly breakpoint, step through execution, and observe all variables in the current scope. gdb works fine on OS X and has D support. Can you enlighten me as to what configuration you've confirmed this on? I'm on OSX: 10.9.5 (Mavericks) GDB: GNU gdb 6.3.50-20050815 (Apple version gdb-1824) (building newer from source tends to fail to compile) DMD: DMD64 D Compiler v2.067 GCC: Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) At best, I can _sometimes_ hit breakpoints when using Mono-D, it's inconsistent. Even when a breakpoint is hit however, GDB only recognizes the current 'this' value; it doesn't recognize any frame / local variables other than 'this', global variables, etc., though it does recognize the call-stack at least. When using GDB directly from a terminal, the only D source file it recognizes for the purpose of setting breakpoints or listing source code is app.d (which contains the main() entry-point). Also have tried compiling with all combinations of -g, -gc, -debug, -gs, and -cov. None seem to improve the situation. Yeah that's apple messing with you, that gdb is old. See http://ntraft.com/installing-gdb-on-os-x-mavericks/ for proper installation instructions. P.s. I help maintain homebrew packages for a bunch of D stuff, its generally more up to date than macports and even has the current betas/rcs as well as support for building from master.
Re: D for project in computational chemistry
On Wednesday, 5 August 2015 at 17:47:49 UTC, Yura wrote: Dear all, Thank you for your replies. I am now really convinced that D is a decent choice for my project (also I am really happy to see that the forum is really active and apparently many of you use D for your scientific projects). I am just looking forward to writing the code. I had a very quick look at lecture given at DConf 2015 - good talk, and I believe D has a big promise in Science. Perhaps the only problem being is the mathematical library, like numpy. Until now I usually wrote the prototype algorithms in Python and then translated the code onto C for speed. It would be just dream to use only one language. The dominant languages in science now for production codes are Fortran or C/C++, may be D could become another option? With kind regards, Yury I think NumPy was written in C(++) and is imported as a Python module. So if you can get your hands on the original underlying C(++) library, you can call NumPy directly from D, can't you? In case you do this, let me know how you fared with it. NumPy is usually the deadbeat argument when people have to choose between Python or other languages.
Re: D for project in computational chemistry
On Wednesday, 5 August 2015 at 17:47:49 UTC, Yura wrote: The dominant languages in science now for production codes are Fortran or C/C++, may be D could become another option? With kind regards, Yury Yes. The question is whether we can put together a group of developers to build the infrastructure, which is a lot more than just code. That means, in particular, good documentation and using it for our own projects. Everyone these days talks about how Python is a powerhouse scientific programming language. A decade ago it was crap. I know, because I watched it for years wishing I could use it. There were some poorly documented, domain-specific, hacked-together libraries, but Python was not for the most part a suitable choice. There is no reason we can't do the same for D. The main question is whether we are sufficiently committed to that goal. Others may consider Python, Julia, and Matlab to be good enough alternatives (I don't, but not everyone necessarily agrees with me).
Re: Rant after trying Rust a bit
On 08/05/2015 07:12 PM, Max Samukha wrote: On Wednesday, 5 August 2015 at 15:58:28 UTC, Timon Gehr wrote: The point is that '+' for string concatenation is no more of an 'idiot thing' than '~'. My point is that it is. String concatenation is not commutative. Ok, good point. Except that '+' in a programming language is not the mathematical '+'. It's obvious where the notation has been borrowed from. Why define '+' as strictly commutative operation and not more generally as an abstract binary operation, Descriptive names do have some value. considering the middle dot is unavailable? (It isn't.) Or, if we want to stick to the math notation, then '*' would be more appropriate than the idiot thing '~'. That's a different discussion. '*' is certainly more appropriate than '+'. Anyway, I think it is sensible to use distinct names for distinct operations when they are used in the same system.
Re: Rant after trying Rust a bit
On 08/05/2015 07:32 PM, deadalnix wrote: On Wednesday, 5 August 2015 at 17:12:29 UTC, Max Samukha wrote: On Wednesday, 5 August 2015 at 15:58:28 UTC, Timon Gehr wrote: The point is that '+' for string concatenation is no more of an 'idiot thing' than '~'. My point is that it is. String concatenation is not commutative. Ok, good point. Except that '+' in a programming language is not the mathematical '+'. Why define '+' as strictly commutative operation and not more generally as an abstract binary operation, considering the middle dot is unavailable? Or, if we want to stick to the math notation, then '*' would be more appropriate than the idiot thing '~'. Nobody want to stay in the math world. Not that math are worthless, but it has this tendency to make simple things absurdly complex by requiring you to learn a whole area of math to understand the introduction. I assume the set of examples you are generalizing this from has cardinality close to one? Anyway, it seems like an exaggeration. This is commonly referred as the monad curse: once you understand what a monad is, you loose all capacity to explain it. I'm not buying it. In fact, Most developers have used some sort of monad, but only a very small portion know they were using one or can explain you what it is. ... Which isn't surprising. This isn't a very useful name in their (quite specific) use cases. Mathematical language is geared toward generality and correctness, not practicality. That makes sens in the context of math, that do not in the context of every day programming. I don't see what you are trying to get at here, but I guess it is almost entirely unrelated to choosing a notation for string concatenation.
Re: Creating a Priority Queue: An Adventure
On Wednesday, 5 August 2015 at 01:02:56 UTC, DarthCthulhu wrote: I must be doing something really stupid here, but I have no clue what it is. Anyone know? For functional behaviour I prefer a postblit that duplicates the underlying BinaryHeap. https://github.com/nordlow/justd/blob/master/priority_queue.d Now the foreach won't consume the queue. This will however duplicate the underlying array aswell, which is probably not what we want. How do we avoid this?
Re: Creating a Priority Queue: An Adventure
On Wednesday, 5 August 2015 at 02:26:48 UTC, Meta wrote: It looks like there was a breaking change made to BinaryHeap somewhere between 2.065 and the present. The code compiles fine on 2.065. http://dpaste.dzfl.pl/65ba735d69e7 It was this PR that changed the behaviour: https://github.com/D-Programming-Language/phobos/pull/1989
Re: Creating a Priority Queue: An Adventure
On Wednesday, 5 August 2015 at 09:04:54 UTC, Nordlöw wrote:
For functional behaviour I prefer a postblit that duplicates
the underlying BinaryHeap.
The postblit is the
this(this) { ... }
Re: Creating a Priority Queue: An Adventure
On Wednesday, 5 August 2015 at 09:04:54 UTC, Nordlöw wrote: This will however duplicate the underlying array aswell, which is probably not what we want. How do we avoid this? Correction: the underlying storage array *must* be duplicated whenever we want to iterate over it without side effects in the original instance. That's just the way binary heaps work.
Re: Thread communication
On Tuesday, 4 August 2015 at 15:19:51 UTC, Chris wrote: I want to stop (and abort) the worker as soon as new input arrives. However, while executing the function that contains the foreach-loop the worker thread doesn't listen, because it's busy, of course. I think this is a matter of architecture. If you want to use message-passing and you want the worker to react quickly to new events, this means it needs to check for new messages (via receiveTimeout) often enough, there's no way around it.
Re: Thread communication
On Tuesday, 4 August 2015 at 18:15:08 UTC, Ali Çehreli wrote:
On 08/04/2015 09:19 AM, Dicebot wrote:
receiveTimeout
I think the problem here is that the worker is busy, not even
able to call that.
This sounds like sending a signal to the specific thread (with
pthread_kill()) but I don't know the details of it nor whether
Phobos supports it.
Ali
The problem is that it works up to a certain extent with
receiveTimeout. However, if the input arrives in very short
intervals, all the solutions I've come up with so far (including
data sharing) fail sooner or later. New threads are spawned
faster than old ones can be given the abort signal. There are
ways to wait, till a given thread dies, say with a shared
variable isAlive `while (isAlive) {}`, but even here I've come
across problems when the input comes very fast.
I don't know how to solve this problem, because message passing
follows a linear protocol (as far as I understand it) and shared
variables give rise to data races. Something like pthread_kill()
would indeed be useful, to terminate a thread at random. I wonder
if fibers would be an option.
D-threads seem to be based on the assumption that there is no
need to abort threads at random, any time. Or am I mistaken?
Re: Creating a Priority Queue: An Adventure
On 8/5/15 7:09 AM, Per =?UTF-8?B?Tm9yZGzDtnci?= per.nord...@gmail.com wrote: On Wednesday, 5 August 2015 at 09:04:54 UTC, Nordlöw wrote: This will however duplicate the underlying array aswell, which is probably not what we want. How do we avoid this? Correction: the underlying storage array *must* be duplicated whenever we want to iterate over it without side effects in the original instance. That's just the way binary heaps work. Yeah, I think there is no way to traverse a binary heap in order without manipulating it. However, you can print the underlying storage. -Steve
What is the order of resolution for super() calls?
Hi, I just read https://rhettinger.wordpress.com/2011/05/26/super-considered-super/ which describes how super works in python (tl;dr: it's completely different from C++, java or D's super but super cool to deal with multiple inheritance). For example, for the following inheritance tree: Object /\ AdamEve | \/ | | X | \ / \ / Abel Cain \ / David A call in David making use of super would in python go through classes in that order: Abel, Cain, Adam, Eve, Object. This is somewhat peculiar as we don't expect the call of super() in Abel to go to Cain just because the initiator was David but that's what happens and it is deterministic (I recommend the article to see why it is so). What would be the order in D? Would it be something like: Abel Adam Object Eve Cain (Adam?) (Eve?) (Object?)
Re: What is the order of resolution for super() calls?
Forget it, I just remembered that we only do single inheritance, and I don't think the same problem occurs with interfaces. For reference, as the diagram was unreadable, I'll describe it here: class Adam ; class Eve ; class Abel:Adam,Eve ; class Cain:Adam,Eve ; class David:Abel,Cain ;
Re: Creating a Priority Queue: An Adventure
On Wednesday, 5 August 2015 at 11:09:29 UTC, Per Nordlöw wrote: On Wednesday, 5 August 2015 at 09:04:54 UTC, Nordlöw wrote: This will however duplicate the underlying array aswell, which is probably not what we want. How do we avoid this? Correction: the underlying storage array *must* be duplicated whenever we want to iterate over it without side effects in the original instance. That's just the way binary heaps work. Crazy idea: what about a range that lazily copies as it needs to? I.e. copy-on-write
Re: Thread communication
On Wednesday, 5 August 2015 at 14:31:20 UTC, Marc Schütz wrote: Maybe we can lift this restriction if we know that the thread's main function is pure and takes no references to mutable data, because then it can by definition never mess up the program's state. That'd be a pretty useless thread; how would it communicate results back to the main thread (or wherever it should go)?
Re: Thread communication
On Wednesday, 5 August 2015 at 11:23:28 UTC, Chris wrote:
The problem is that it works up to a certain extent with
receiveTimeout. However, if the input arrives in very short
intervals, all the solutions I've come up with so far
(including data sharing) fail sooner or later. New threads are
spawned faster than old ones can be given the abort signal.
There are ways to wait, till a given thread dies, say with a
shared variable isAlive `while (isAlive) {}`, but even here
I've come across problems when the input comes very fast.
You could use a thread pool, thereby limiting the number of
threads that can run at any one time. But I guess you want the
processing of new data to start as soon as possible, in which
case that wouldn't help you.
I don't know how to solve this problem, because message passing
follows a linear protocol (as far as I understand it) and
shared variables give rise to data races. Something like
pthread_kill() would indeed be useful, to terminate a thread at
random. I wonder if fibers would be an option.
D-threads seem to be based on the assumption that there is no
need to abort threads at random, any time. Or am I mistaken?
It was a conscious decision not to provide a kill method for
threads, because it is impossible to guarantee that your program
is still consistent afterwards. Maybe we can lift this
restriction if we know that the thread's main function is pure
and takes no references to mutable data, because then it can by
definition never mess up the program's state. OTOH, the GC might
be running at the time the thread is killed, which could again
lead to inconsistencies...
Re: Thread communication
On Wednesday, 5 August 2015 at 14:34:42 UTC, Alex Parrill wrote: On Wednesday, 5 August 2015 at 14:31:20 UTC, Marc Schütz wrote: Maybe we can lift this restriction if we know that the thread's main function is pure and takes no references to mutable data, because then it can by definition never mess up the program's state. That'd be a pretty useless thread; how would it communicate results back to the main thread (or wherever it should go)? It could return something. `std.concurrency.Tid` would have to be extended with a `join()` method that returns its result. Or we could somehow allow sending and receiving data.
Re: Creating a Priority Queue: An Adventure
On Wednesday, 5 August 2015 at 13:37:19 UTC, John Colvin wrote: On Wednesday, 5 August 2015 at 11:09:29 UTC, Per Nordlöw wrote: On Wednesday, 5 August 2015 at 09:04:54 UTC, Nordlöw wrote: This will however duplicate the underlying array aswell, which is probably not what we want. How do we avoid this? Correction: the underlying storage array *must* be duplicated whenever we want to iterate over it without side effects in the original instance. That's just the way binary heaps work. Crazy idea: what about a range that lazily copies as it needs to? I.e. copy-on-write I guess you mean that popFront should copy on demand then. We then an extra bool to keep track of whether the copying has been done then. One problem though: auto x = PQ; x.insert(...); // one element auto y = x; // no copying of underlying storage x.popFront; // modified both x and y! y.popFront; // copied on demands, but underlying storage is already empty. oops! I don't think this is a desired behaviour.
Re: Creating a Priority Queue: An Adventure
On Wednesday, 5 August 2015 at 15:29:39 UTC, Nordlöw wrote: On Wednesday, 5 August 2015 at 13:37:19 UTC, John Colvin wrote: On Wednesday, 5 August 2015 at 11:09:29 UTC, Per Nordlöw wrote: On Wednesday, 5 August 2015 at 09:04:54 UTC, Nordlöw wrote: This will however duplicate the underlying array aswell, which is probably not what we want. How do we avoid this? Correction: the underlying storage array *must* be duplicated whenever we want to iterate over it without side effects in the original instance. That's just the way binary heaps work. Crazy idea: what about a range that lazily copies as it needs to? I.e. copy-on-write I guess you mean that popFront should copy on demand then. We then an extra bool to keep track of whether the copying has been done then. One problem though: auto x = PQ; x.insert(...); // one element auto y = x; // no copying of underlying storage x.popFront; // modified both x and y! y.popFront; // copied on demands, but underlying storage is already empty. oops! I don't think this is a desired behaviour. in my vision, either x.popFront would also create a copy or you would have to go auto y = x.nonModifyingView or similar. What I don't want is something that copies 1 elements just to use x.take(6)
Re: What is the order of resolution for super() calls?
On Wednesday, 5 August 2015 at 12:32:48 UTC, cym13 wrote: For reference, as the diagram was unreadable, I'll describe it here: class Adam ; class Eve ; class Abel:Adam,Eve ; class Cain:Adam,Eve ; class David:Abel,Cain ; This is illegal D. You must use interfaces to simulate multiple inheritance: D classes support the single inheritance paradigm, extended by adding support for interfaces. see more here: http://dlang.org/class.html
Re: Creating a Priority Queue: An Adventure
On Wednesday, 5 August 2015 at 09:04:54 UTC, Nordlöw wrote:
On Wednesday, 5 August 2015 at 01:02:56 UTC, DarthCthulhu wrote:
I must be doing something really stupid here, but I have no
clue what it is. Anyone know?
For functional behaviour I prefer a postblit that duplicates
the underlying BinaryHeap.
https://github.com/nordlow/justd/blob/master/priority_queue.d
Now the foreach won't consume the queue.
Oh, neat! I stumbled on the same thing (making a .dup of the
BinaryHeap), but didn't know about the postblit. That makes
things simplier.
This will however duplicate the underlying array aswell, which
is probably not what we want. How do we avoid this?
I was wondering that, myself, when I stumbled on the .dup
solution. My first thought was to instantiate a templated Array!
first, then use BinaryHeap.assume or .acquire to make it a
BinaryHeap while also keeping a reference to the underlining
array. Then one could just return the array reference in a
separate function rather than destructively iterating through the
BinaryHeap.
My experiments didn't bear this out, however. Maybe I'm
misunderstanding what the .assume and .acquire functions do?
Incidentally, I also discovered the wonderful opDot function
which allows the PriorityQueue to shunt most of the work down to
the BinaryHeap directly.
// Forward most function calls to the underlying queue.
BinaryHeap!(Array!(PV), predicate)* opDot() {
return _q;
}
Yeah, I think there is no way to traverse a binary heap in
order without manipulating it. However, you can print the
underlying storage.
There's a way to get at the underlining store? I couldn't find
any means to do so in the BinaryHeap documentation.
in my vision, either x.popFront would also create a copy or you
would have to go auto y = x.nonModifyingView or similar. What
I don't want is something that copies 1 elements just to use
x.take(6)
Yeah, that's it exactly!
D Wiki: Windows programming examples are missing
Hi everyone, I'm fairly new to D and am really excited about it. I would like to see more examples of Windows programming in D, but the repository indicated on the D wiki seems to be moved or deleted. More info is here: http://wiki.dlang.org/talk:D_for_Win32 Thanks! -- With best regards from Ukraine, Andre Skype: Francophile Twitter: @m_elensule; Facebook: menelion My blog: http://menelion.oire.org/
Re: D Wiki: Windows programming examples are missing
On Wednesday, 5 August 2015 at 21:02:49 UTC, Andre Polykanine wrote: Hi everyone, I'm fairly new to D and am really excited about it. I would like to see more examples of Windows programming in D, but the repository indicated on the D wiki seems to be moved or deleted. More info is here: http://wiki.dlang.org/talk:D_for_Win32 Thanks! I've recently bookmarked this one: https://github.com/etcimon/windows-headers However it's not usable out of the box. See repository readme.
Re: Using rdmd to create shared object files
On Sunday, 2 August 2015 at 19:04:15 UTC, Malte Kießling wrote:
Hello,
I am trying to use rdmd to create shared object files.
The command that I am using is
rdmd --build-only -shared -fPIC -defaultlib= foo.d
This creates a file called foo - wich is not exactly what I
expectd.
However
dmd -shared -fPIC -defaultlib= foo.d
creates a file called foo.so - that is what i expect and need.
The command ill be actually using will be similar to this:
find ../script -name *.d -exec dmd -I../../deps/
-I../../source/ -fPIC -shared -debug -g -defaultlib= {} \;
The amount of files that will be compiled by this are really
likely going to increase over time, so using rdmd here would be
nice in terms of compile time.
The issues i have is that rdmd dosnt create .so files but (at
least on my linux) creates them without a file exenstion. I
could rename them with -of but that would increase this ugly
find-command even more. The second thing (wich isnt such a big
issue): I have to use --build-only for rdmd because it will
try to run the newly created shared object.
Also, not so on-topic to be asked here: Is there a nicer
solution for the all .d files in this directory and the ones
below?
I remeber its possible to do something like
dmd ./**/*.d
but I cant get that to work...
Thanks
Malte
I'm not quite sure why you're trying to use rdmd to build shared
object files... rdmd is designed to run programs, not to build
libraries. That's why it won't put a .so extension, it just
(AFAIK) isn't designed for shared libraries. So why are you
trying to use it instead of dmd?
Besides, extensive glob (the ./**/* thing) is shell dependant,
I'm not sure it is possible on bash, it may be zsh-only. You
could however do (assuming you're on an UNIX system) “ find .
-name *.d | xargs dmd your_options ” where “find” finds .d
files and xargs passes them as argument to dmd.
[Issue 14871] New: Linker errors with 2.068.0-rc1
https://issues.dlang.org/show_bug.cgi?id=14871 Issue ID: 14871 Summary: Linker errors with 2.068.0-rc1 Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Keywords: industry, link-failure Severity: regression Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: briancsch...@gmail.com While testing 2.068.0-rc1 against some EMSI internal code as well as a development version of DCD I ran into some linking issues. It seems that the linker is trying to resolve some symbols whose names end with __arrayZ and __assertFiZv. These symbol names seem to always be at module scope. Example error messages: /path_partially_redacted/ext/containers/src/containers/unrolledlist.d:445: undefined reference to `_D10containers12unrolledlist8__assertFiZv' bin/dcd-server.o: In function `_D3std12experimental9allocator15building_blocks15stats_collector232__T14StatsCollectorTS3std12experimental9allocator15building_blocks6region137__T6RegionTS3std12experimental9allocator10mallocator10MallocatorVki16VE3std8typecons43__T4FlagVAyaa13_67726f77446f776e7761726473Z4Flagi0Z6RegionVmi1024Vmi0Z14StatsCollector6defineFAyaAAyaXAya': msgpack-d/src/msgpack.d:(.text._D3std12experimental9allocator15building_blocks15stats_collector232__T14StatsCollectorTS3std12experimental9allocator15building_blocks6region137__T6RegionTS3std12experimental9allocator10mallocator10MallocatorVki16VE3std8typecons43__T4FlagVAyaa13_67726f77446f776e7761726473Z4Flagi0Z6RegionVmi1024Vmi0Z14StatsCollector6defineFAyaAAyaXAya+0x83): undefined reference to `_D3std12experimental9allocator15building_blocks15stats_collector7__arrayZ' It should be possible to reproduce part of the error with a checkout of DCD at this version: https://github.com/Hackerpilot/DCD/tree/7724ab9dc63221d383dfcfdf78429c570eeba60c (Remember to run `git submodule update --init --recursive after checking out) --
[Issue 14871] Linker errors with 2.068.0-rc1
https://issues.dlang.org/show_bug.cgi?id=14871 --- Comment #1 from Kenji Hara k.hara...@gmail.com --- Due to fix issue 14828 and related, 2.068.0-rc1 has introduced a change to the generation of internal symbols __array, __assert, and __unittest_fail. I have opposite stance for the change, but it's rejected. The PR that contains the discussion: https://github.com/D-Programming-Language/dmd/pull/4851 If you want to get more detailed information, please wait the reply from Walter or Martin. --
[Issue 14871] Linker errors with 2.068.0-rc1
https://issues.dlang.org/show_bug.cgi?id=14871 --- Comment #2 from Kenji Hara k.hara...@gmail.com --- Essentially the change was unnecessary to fix regressions, but just added to make compiler implementation 'simple'. I think it was not good decision. --
[Issue 14864] windows uninstall during installation pops up spurious warning
https://issues.dlang.org/show_bug.cgi?id=14864 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/installer https://github.com/D-Programming-Language/installer/commit/526f35495cdc615b26b65d73fa7b4aa0477b1d12 fix Issue 14864 - windows uninstall during installation pops up spurious warning https://github.com/D-Programming-Language/installer/commit/a3afa9223b65c0594bae536cd57bbacee95374a0 Merge pull request #130 from MartinNowak/fix14864 --
[Issue 14801] OS X installer not compatible with OS X 10.11
https://issues.dlang.org/show_bug.cgi?id=14801 --- Comment #14 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/installer https://github.com/D-Programming-Language/installer/commit/ff2eac28c6ca6ea483ebf3dd8f8ffd8e4d03921e Merge pull request #128 from jacob-carlborg/issue_14801 --
[Issue 14871] Linker errors with 2.068.0-rc1
https://issues.dlang.org/show_bug.cgi?id=14871 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #3 from Martin Nowak c...@dawg.eu --- The issues is that you're not compiling the std.experimental.allocator.building_blocks modules. The fix is straightforward. - containers/src/std/experimental/allocator/mallocator.d\ - containers/src/std/experimental/allocator/package.d\ - containers/src/std/experimental/allocator/common.d\ - containers/src/std/experimental/allocator/gc_allocator.d\ - containers/src/std/experimental/allocator/building_blocks/allocator_list.d\ - containers/src/std/experimental/allocator/typed.d\ + $(shell find containers/src/std/experimental/allocator -name *.d)\ We fixed 2 regressions by using a simpler mechanism to emit helper functions. Now this requires you to link against all modules you use, where previously you could sometimes get away without linking. https://github.com/D-Programming-Language/dmd/pull/4851 --
[Issue 14872] New: [2.068.0-rc1] Label address in asm [x86-64]
https://issues.dlang.org/show_bug.cgi?id=14872
Issue ID: 14872
Summary: [2.068.0-rc1] Label address in asm [x86-64]
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: major
Priority: P1
Component: dmd
Assignee: nob...@puremagic.com
Reporter: wyr...@gmx.net
32bit x86 asm works fine, but I can't get 64bit working.
import std.stdio;
void main()
{
size_t addr1=123;
size_t addr2=456;
version(D_InlineAsm_X86_64)
asm
{
lea RAX, lbl1;
mov addr1, RAX;
lea RAX, lbl2;
mov addr2, RAX;
}
else version(D_InlineAsm_X86)
asm
{
lea EAX, lbl1;
mov addr1, EAX;
lea EAX, lbl2;
mov addr2, EAX;
}
lbl1:
writeln(addr1); // equals 1 for X86-64
lbl2:
writeln(addr2); // equals 1 for X86-64
}
--
[Issue 14871] Linker errors with 2.068.0-rc1
https://issues.dlang.org/show_bug.cgi?id=14871 --- Comment #4 from briancsch...@gmail.com --- I was able to get all of my code to build and link. There really needs to be something in the changelog that warns people about this. --
[Issue 14564] [REG2.067] dmd -property -unittest combination causes compiler error
https://issues.dlang.org/show_bug.cgi?id=14564 --- Comment #14 from ag0ae...@gmail.com --- (In reply to ag0aep6g from comment #13) https://github.com/D-Programming-Language/dmd/pull/4850 Superseded by https://github.com/D-Programming-Language/dmd/pull/4862 --
[Issue 14868] MmFile destructor seems to corrupt memory
https://issues.dlang.org/show_bug.cgi?id=14868 --- Comment #3 from Sergei Degtiarev sdegtia...@yahoo.com --- The MmFile destructor is called after main() termination and throws exception while trying to clean up the memory. --
[Issue 14866] Unable to find universal runtime static libraries on windows 10 and VS 2015
https://issues.dlang.org/show_bug.cgi?id=14866 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de --- If you add c:\Program Files (x86)\Windows Kits\10\Lib\10.0.10150.0\ucrt\x64 to the global library search paths, the lib is found, but druntime/phobos do not work with the changed MS runtime. See also https://issues.dlang.org/show_bug.cgi?id=14849#c7 --
[Issue 14868] MmFile destructor seems to corrupt memory
https://issues.dlang.org/show_bug.cgi?id=14868 --- Comment #4 from Maxim Fomin mxfo...@gmail.com --- (In reply to Sergei Degtiarev from comment #3) The MmFile destructor is called after main() termination and throws exception while trying to clean up the memory. Sounds like class dtor invokes gc. Because current GC implementation is not reenterant, such code in not supported. --
[Issue 14614] PDB File Not Generated when building in VS2015
https://issues.dlang.org/show_bug.cgi?id=14614 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Rainer Schuetze r.sagita...@gmx.de --- fix released in https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.42 --
[Issue 14706] Release configuration doesn't enable -O by default.
https://issues.dlang.org/show_bug.cgi?id=14706 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Rainer Schuetze r.sagita...@gmx.de --- fix released in https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.42 --
[Issue 12750] VS2010 profiler doesn't seem to work
https://issues.dlang.org/show_bug.cgi?id=12750 --- Comment #3 from Rainer Schuetze r.sagita...@gmx.de --- VS2010 I was rather hoping you upgraded in the meantime ;-) I recently tried getting profiling to work in VS2010 (installed in a VM), but that didn't even work for C++ projects. I'll probably won't be able to investigate that further for a VS version that's now superseded by 3 major releases. --
[Issue 14577] Add dustmite tool to VisualD
https://issues.dlang.org/show_bug.cgi?id=14577 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Rainer Schuetze r.sagita...@gmx.de --- released in https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.42 If it doesn't work for you, please file bug reports. --
[Issue 14698] Un-mangle symbols in disassembly?
https://issues.dlang.org/show_bug.cgi?id=14698 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Rainer Schuetze r.sagita...@gmx.de --- released in https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.42 --
[Issue 14698] Un-mangle symbols in disassembly?
https://issues.dlang.org/show_bug.cgi?id=14698 --- Comment #13 from Rainer Schuetze r.sagita...@gmx.de --- The next version of binutils/gdb will have pretty much near complete 2.068 support. In my local tests, it managed to demangle all symbols in Phobos and druntime (core.demangle barely got 20% - and even then some were massively incorrect). I could use the D demangler from binutils in my tool, too. Also, the mago debug engine might need an update to its demangler. Do you plan to submit those fixes to core.demangle, too? --
[Issue 14873] New: Build fails with message 'cannot create PDB file'
https://issues.dlang.org/show_bug.cgi?id=14873 Issue ID: 14873 Summary: Build fails with message 'cannot create PDB file' Product: D Version: D2 Hardware: x86_64 OS: Windows Status: NEW Severity: critical Priority: P1 Component: visuald Assignee: nob...@puremagic.com Reporter: de...@palacino.net This does not appear to be a duplicate of 13641. I've tried the solution provided there and it does not work for me. I am using Visual D in VS2015 on Windows 10. Happy to provide logs and cmd files at request. Here the simple output: -- Build started: Project: Library, Configuration: Debug Win32 -- Building Debug\Library.dll... Converting debug information... C:\Users\Derik\Projects\TagIO\Projects\Library\Debug\Library.pdb: cannot create PDB file Building Debug\Library.dll failed! Details saved as file://C:\Users\Derik\Projects\TagIO\Projects\Library\Debug\Library.buildlog.html -- Build started: Project: Server, Configuration: Debug Win32 -- Building Debug\Server.exe... Converting debug information... C:\Users\Derik\Projects\TagIO\Projects\Server\Debug\Server.pdb: cannot create PDB file Building Debug\Server.exe failed! Details saved as file://C:\Users\Derik\Projects\TagIO\Projects\Server\Debug\Server.buildlog.html == Build: 0 succeeded, 2 failed, 0 up-to-date, 0 skipped == --
[Issue 14873] Build fails with message 'cannot create PDB file'
https://issues.dlang.org/show_bug.cgi?id=14873 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de --- Could be a duplicate of issue 14164. Is this happening with the latest release, too? Please try https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.42 --
Re: Rant after trying Rust a bit
On Wednesday, 5 August 2015 at 22:24:34 UTC, Enamex wrote: Oh, it _is_ talked about a lot. Just normally called 'syntax extensions' (the most used aspect of the plugin system), so it _is_ used. Though because it relies on compiler internals everything released as a plugin is only usable on Nightly. I had been talking about this thread. You're right that there are a bunch of mentions on the forums (which I found after searching the term you list), but only two in the past day (including yours) on this thread.
Re: D for Game Development
On Thursday, 6 August 2015 at 00:05:34 UTC, Tofu Ninja wrote: One thing I would really like for D would be an opengl binding in phobos, there was some momentum a while ago to try to get graphics into phobos with Aurora, but literally nothing came of that. As I recall it wasn't for lack of trying. Binding D to the existing C++ was just too difficult, and those issues were what spurred the greater push for improving C++ compatibility.
Re: D for Game Development
On Thursday, 6 August 2015 at 01:13:04 UTC, Meta wrote: On Thursday, 6 August 2015 at 00:05:34 UTC, Tofu Ninja wrote: One thing I would really like for D would be an opengl binding in phobos, there was some momentum a while ago to try to get graphics into phobos with Aurora, but literally nothing came of that. As I recall it wasn't for lack of trying. Binding D to the existing C++ was just too difficult, and those issues were what spurred the greater push for improving C++ compatibility. What existing c++? Wasn't Aurora supposed to be an all D solution.
Re: Thread communication
On Wednesday, 5 August 2015 at 14:31:20 UTC, Marc Schütz wrote: It was a conscious decision not to provide a kill method for threads, because it is impossible to guarantee that your program is still consistent afterwards. What about the situation where we want to kill worker threads off when closing a program? For example, I have a program with a thread that does some heavy computation in the background. When the application is closed, I want it to abort that computation, however I can't just slap a receiveTimeout in the worker thread because it is doing its work in a parallel foreach loop.
Re: Rant after trying Rust a bit
On Wednesday, 5 August 2015 at 19:56:37 UTC, Timon Gehr wrote: On 08/05/2015 07:32 PM, deadalnix wrote: Mathematical language is geared toward generality and correctness, not practicality. That makes sens in the context of math, that do not in the context of every day programming. I don't see what you are trying to get at here, but I guess it is almost entirely unrelated to choosing a notation for string concatenation. Well, I don't think practicality is the main issue, but the mnemonic aspect of syntax is important. It is not unreasonable to make the identity of operators/functions consist of both name and parameter types like in C++ and D. So you don't have + as the operator name, you have +(int,int) and +(string,string). If one makes mathematical properties intrinsic to untyped part of the name then a lot of overloading scenarios break down e.g. for non-euclidean types. It has been argued that functional languages would benefit from teaching functional programming in a less mathematical manner (e.g. talk about callbacks rather than monads etc): https://youtu.be/oYk8CKH7OhE
Re: Visual D 0.3.42 released
On Wednesday, 5 August 2015 at 21:03:51 UTC, Rainer Schuetze wrote: Hi, there is a new version of Visual D available at http://rainers.github.io/visuald/visuald/StartPage.html [snip] Thanks a lot. I've been using VisualD almost as long as I've been using D and it's always been great.
Re: Rant after trying Rust a bit
On Friday, 24 July 2015 at 21:44:42 UTC, Tofu Ninja wrote:
But the part that I don't think makes sense for
auto a = {return 4;};
to type a to a function pointer. I would expect {return 4;}
to be treated as a function(not a function pointer). With it
being treated as a function, I would expect it to be called
with optional parens and type a to an int. I would expect auto
a = {return 4;};
to type a to a function pointer, which makes much more sense
to me. But that's not how function literals work right now.
Treating {return 4;} as a function(not a function pointer)
makes a lot more sense and allows
alias a = {return 4;};
to work as well, which is simply a function declaration.
Not crazy about your last point, TBH. Personally I really dislike
function literals being _just_ `{ ... }` and as a matter of
principle only write `(){...}` when I need one. `{}` to me can
only mean blocks that are part of the current scope, but they're
sometimes that and sometimes lambdas, depending on whether they
had any `return`s and are in a place to be assigned a name or
immediately called :/
A related thing is having _some way_ to quickly return a value
from inside an invoked function literal without `return`. Somme
stuff can't be done in a one-liner and need _two_(ish) lines and
have to write, say, `{ Type myval, myres; res_by_ref(myval,
myres); return myres; }()` instead of `{ Type myval, myres;
res_by_ref(myval, myres); myres }` (expression-oriented) or `(){
...; = myres; }()`(hypothetically). Point is, writing `return`
in the middle of a function and having it return _only_ from a
lambda breaks the flow, I believe, same as in C++.
Re: D for project in computational chemistry
On Wednesday, 5 August 2015 at 23:37:37 UTC, Laeeth Isharc wrote: Dataframes aren't intellectually very exciting, but they are very useful for iterative data exploration and quick prototyping since all of that starts with getting the data in from somewhere in a standard format. May not be intellectually exciting, but look at how popular pandas is for python.
[Issue 14874] New: std.traits.functionAttributes does not support the new `return` attribute
https://issues.dlang.org/show_bug.cgi?id=14874
Issue ID: 14874
Summary: std.traits.functionAttributes does not support the new
`return` attribute
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P1
Component: phobos
Assignee: nob...@puremagic.com
Reporter: monkeywork...@hotmail.com
import std.traits;
struct Test
{
int n;
ref int getN() return
{
return n;
}
}
void main()
{
//fails
assert(functionAttributes!(Test.getN) FunctionAttribute.return_);
}
--
[Issue 14862] Constructor of overlapped struct does not initialize correctly global variables
https://issues.dlang.org/show_bug.cgi?id=14862 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||CTFE, pull Hardware|x86 |All OS|Windows |All --- Comment #1 from Kenji Hara k.hara...@gmail.com --- https://github.com/D-Programming-Language/dmd/pull/4863 --
Re: D for project in computational chemistry
On Wednesday, 5 August 2015 at 18:20:20 UTC, Chris wrote: On Wednesday, 5 August 2015 at 17:47:49 UTC, Yura wrote: Dear all, Thank you for your replies. I am now really convinced that D is a decent choice for my project (also I am really happy to see that the forum is really active and apparently many of you use D for your scientific projects). I am just looking forward to writing the code. I had a very quick look at lecture given at DConf 2015 - good talk, and I believe D has a big promise in Science. Perhaps the only problem being is the mathematical library, like numpy. Until now I usually wrote the prototype algorithms in Python and then translated the code onto C for speed. It would be just dream to use only one language. The dominant languages in science now for production codes are Fortran or C/C++, may be D could become another option? With kind regards, Yury I think NumPy was written in C(++) and is imported as a Python module. So if you can get your hands on the original underlying C(++) library, you can call NumPy directly from D, can't you? In case you do this, let me know how you fared with it. NumPy is usually the deadbeat argument when people have to choose between Python or other languages. Isn't the useful bit of NumPy more like a set of wrappers around other C/C++/Fortran libraries? And the whole point of NumPy is that you can call it easily from python, which doesn't make for a nice calling convention from D (although you can call from PyD if you want). Anyway, I agree that it's a big project, but not an infeasible one to implement similar functionality in D.
Re: Changelog
On Wednesday, 5 August 2015 at 20:57:49 UTC, anonymous wrote: getUDAs and getSymbolsByUDA don't seem to have made it, so they're correctly commented out for now. That's annoying. Those three were meant to go together.
Re: D for project in computational chemistry
On Wednesday, 5 August 2015 at 18:49:21 UTC, bachmeier wrote: On Wednesday, 5 August 2015 at 17:47:49 UTC, Yura wrote: The dominant languages in science now for production codes are Fortran or C/C++, may be D could become another option? With kind regards, Yury Yes. The question is whether we can put together a group of developers to build the infrastructure, which is a lot more than just code. That means, in particular, good documentation and using it for our own projects. Everyone these days talks about how Python is a powerhouse scientific programming language. A decade ago it was crap. I know, because I watched it for years wishing I could use it. There were some poorly documented, domain-specific, hacked-together libraries, but Python was not for the most part a suitable choice. There is no reason we can't do the same for D. The main question is whether we are sufficiently committed to that goal. Others may consider Python, Julia, and Matlab to be good enough alternatives (I don't, but not everyone necessarily agrees with me). Yes - I fully agree with everything you say here. John Colvin has done great work in putting together a scientific computing portal for D, and writing a wrapper so you can write D within an ipython notebook (and call it transparently from python code). Great for rapid iteration and exploration of data, and it means you don't need to write the whole stack from scratch in D. One place I started in a small way was implementing a limited subset of dataframe functionality. There's not much to it, but it's something very handy to be able to slurp in data from csv or hdf5 that might not fit in a more rigid format and do spreadsheet type stuff with it. So instead of an array of variants, you define a type for the column (every entry in the column is the same type, but different columns may be of different types). In addition each column has a name and you can add and remove columns easily. I've implemented a just about usable version of that, but it's not pretty, rigorous, or especially efficient. The next stage is creating indexing by columns a la pandas. Dataframes aren't intellectually very exciting, but they are very useful for iterative data exploration and quick prototyping since all of that starts with getting the data in from somewhere in a standard format. The problem I have is that I have an ambitious project and too few resources for now. So I can't at this stage put much time into making anything someone else could use. But maybe we could work together on parts of this, if that would be interesting. I am speaking to Vlad Lefenfeld about this a bit too. On the pure numerical stuff, speak to John Colvin. If you want you can email me laeeth laeeth dot com. Laeeth.
Re: Changelog
On 08/05/2015 09:04 PM, Brian Schott wrote: Where does that changelog come from? I made some pull requests against a file that I thought was the changelog to document some Phobos changes that got merged, but now I don't see it on dlang.org. https://github.com/D-Programming-Language/dlang.org/pull/1028/files https://github.com/D-Programming-Language/dlang.org/pull/1027/files I picked the hasUDA part into stable [¹] and updated master [²] and the website [³] [¹]: https://github.com/D-Programming-Language/dlang.org/commit/867733ebc390bef969342ee7f4dcf3e6a7218da8 [²]: https://github.com/D-Programming-Language/dlang.org/commit/c56a592cf804999e9edf7f43b6318351b94aed0d [³]: http://dlang.org/changelog.html
Re: Rant after trying Rust a bit
On Wednesday, 5 August 2015 at 14:21:13 UTC, jmh530 wrote: On Wednesday, 5 August 2015 at 06:03:14 UTC, rsw0x wrote: This thread is really long so I didn't read all the posts. Sorry if this has been mentioned. Don't worry, I don't recall anybody talking about it. Nevertheless, plugins aren't unique to Rust: GCC and Clang allow plugins. Nevertheless, I think that the Rust C++ plugin you posted was cool. Reminds me of Rcpp. Oh, it _is_ talked about a lot. Just normally called 'syntax extensions' (the most used aspect of the plugin system), so it _is_ used. Though because it relies on compiler internals everything released as a plugin is only usable on Nightly.
Re: D for Game Development
On Thursday, 30 July 2015 at 13:43:35 UTC, karabuta wrote: D is really cool and makes a good candidate for developing a game. Are there any guys out there using D for indie games? For some time I have been seeing some cool game engine being developed in the DUB repo. What more is happening? I don't see derelictSDl and derelictSFML activities much. Whatup? One thing I would really like for D would be an opengl binding in phobos, there was some momentum a while ago to try to get graphics into phobos with Aurora, but literally nothing came of that. People want an all D gui, and graphics support but literally nothing will ever happen until we at least get some basic graphics interfaces like a simple windowing library and some opengl. We are already getting color and images, full on hw supported graphics is the next step. Also a thing I would really like is if all the new graphics related things went into a std.graphics, it would be nice if it was std.graphics.color, std.graphics.image, std.graphics.opengl, std.graphics.window, std.graphics.gui, ect... That and some simple linear alg into phobos, gl3n pls? We literally have most of the needed parts already just laying around on dub and in other places.
