[Issue 18022] DDoc: reduce ddoc has UT between documentation
https://issues.dlang.org/show_bug.cgi?id=18022 RazvanNchanged: What|Removed |Added Status|NEW |RESOLVED CC||razvan.nitu1...@gmail.com Resolution|--- |INVALID --- Comment #1 from RazvanN --- This is not a bug, but a documented unittest. Closing as invalid. --
[Issue 18028] Allow Unnecessary Template Instantiation To Be Dropped
https://issues.dlang.org/show_bug.cgi?id=18028 Ketmar Darkchanged: What|Removed |Added CC||ket...@ketmar.no-ip.org --
[Issue 18029] extra dtor call with typed variadic argument (or missing postblit)
https://issues.dlang.org/show_bug.cgi?id=18029 Ketmar Darkchanged: What|Removed |Added CC||ket...@ketmar.no-ip.org --
[Issue 18029] New: extra dtor call with typed variadic argument (or missing postblit)
https://issues.dlang.org/show_bug.cgi?id=18029 Issue ID: 18029 Summary: extra dtor call with typed variadic argument (or missing postblit) Product: D Version: D2 Hardware: x86 OS: All Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: ket...@ketmar.no-ip.org the following code failing the assertion: === int rc = 0; struct S { int n; this (int na) { ++rc; n = na; import core.stdc.stdio; printf("ctor for (n=%d)\n", n); } this (this) { if (n) ++rc; import core.stdc.stdio; printf("postblit for (n=%d)\n", n); } ~this () { if (n) --rc; import core.stdc.stdio; printf("dtor for (n=%d)\n", n); n = 0; } } void test0 (S[] vals...) { vals[0] = S.init; //(1) this causes the bug } void test1 () { auto a0 = S(1); test0(a0); } void main () { test1(); assert(rc == 0); } === `dtor for (n=1)` is called twice, but only if (1) is not commented. comment out (1), and the bug is gone. *technically* calling dtor on already destructed struct is not a bug. but IRL it will ruin any reference counting scheme. tbh, i don't know how to fix this... let's say "corner case" without loosing performance. also, i dont' know why `a0` isn't cleared by `vals[0] = S.init;`. i thought that typed vararg just creates a slice of program stack, and assigning `.init` to `vals` member should clear `a0`. either that, or compiler should call postblit for each typed vararg member (please, no! ;-). so, this can be "missing postblit call" case too. i put both in subj until we'll decide what should be done in this case. please note that i'm clearing `n` in dtor, so calling dtor on already "destroyed" struct should not be disasterous. but somehow `a0` is not cleared. --
Re: Thoughts about D
On 12/3/17 21:28, Walter Bright wrote: On 12/3/2017 8:59 PM, Adam Wilson wrote: I have to agree with this. I make my living on server side software, and we aren't allowed (by legal) to connect to the server to run debuggers. The *only* thing I have is logging. If the program crashes with no option to trap an exception or otherwise log the crash this could cost me weeks-to-months of debugging time. As I said, the halt behavior will be an option. Nobody is taking away anything. Awesome. :) -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: Thoughts about D
On 12/3/2017 8:59 PM, Adam Wilson wrote: I have to agree with this. I make my living on server side software, and we aren't allowed (by legal) to connect to the server to run debuggers. The *only* thing I have is logging. If the program crashes with no option to trap an exception or otherwise log the crash this could cost me weeks-to-months of debugging time. As I said, the halt behavior will be an option. Nobody is taking away anything.
Re: Thoughts about D
On 12/3/17 00:09, Dmitry Olshansky wrote: On Saturday, 2 December 2017 at 23:44:39 UTC, Walter Bright wrote: On 12/2/2017 4:38 AM, Iain Buclaw wrote: But then you need to bloat your program with debug info in order to understand what, why, and how things went wrong. Most of the time (for me) that isn't necessary, because the debugger still shows where it failed and that's enough. Besides, you can always rerun the test case with a debug build. Ehm, if it’s a simple reproducable tool. Good luck debugging servers like that. I have to agree with this. I make my living on server side software, and we aren't allowed (by legal) to connect to the server to run debuggers. The *only* thing I have is logging. If the program crashes with no option to trap an exception or otherwise log the crash this could cost me weeks-to-months of debugging time. -- Adam Wilson IRC: LightBender import quiet.dlang.dev;
Re: git workflow for D
On Monday, 4 December 2017 at 01:54:57 UTC, ketmar wrote: Basile B. wrote: On Sunday, 3 December 2017 at 22:22:47 UTC, Arun Chandrasekaran wrote: Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake). Who hasn't ;) me. Happened to me last time because i tried a command supposed to remove untracked files in submodules...but used "reset" in a wrong way... ouch. "git reflog". nothing commited is *ever* lost until you do "git gc". This needs to be repeated: nothing in git is ever lost if it had been commited. You can lose untracked files, but commits do not disappear. If you're unsure before an operation and have difficulties to use git reflog. Before doing the operation, do a simple git branch life-draft (or whatever you want). After the operation if it failed, you still have the commit your HEAD was on referenced by the life-draft branch. branches and tags are just pointers in the directed graph a git repositery is. The interface only does not display the branches that have no entry pointer. git sometimes does GC on its own, so you can turn it off with: git config --global gc.auto 0 don't forget to manually GC your repo then with "git gc", or it may grow quite huge.
Re: git workflow for D
Basile B. wrote: On Sunday, 3 December 2017 at 22:22:47 UTC, Arun Chandrasekaran wrote: Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake). Who hasn't ;) me. Happened to me last time because i tried a command supposed to remove untracked files in submodules...but used "reset" in a wrong way... ouch. "git reflog". nothing commited is *ever* lost until you do "git gc". git sometimes does GC on its own, so you can turn it off with: git config --global gc.auto 0 don't forget to manually GC your repo then with "git gc", or it may grow quite huge.
Re: Thoughts about D
On 12/3/2017 5:12 PM, Michael V. Franklin wrote: Ok, well perhaps that makes sense compiling with -fPIC, but the "relocation R_X86_64_32 against `.rodata.str1.1'" seems unnecessary. Why certain relocations are there is not at all a simple subject. And changing them tends to produce all sorts of frustrating bugs :-(
Re: Thoughts about D
On 12/3/2017 5:01 PM, Michael V. Franklin wrote: Would it help for me to file bugzilla issues for things like this? No, because "why does the compiler do xxx" isn't really a bug report. You could ask on the learn n.g., or use obj2asm to examine the generated code. You can also grep the druntime source for what _d_dso_registry does. The reason I haven't thus far, is that this is just a symptom of a larger issue. It needs a development strategy to be solved holistically. Having a new process isn't going to do much, because at some point someone has to put in work. It's the doing work that produces results.
Re: git workflow for D
On Sunday, 3 December 2017 at 23:39:49 UTC, Basile B. wrote: On Sunday, 3 December 2017 at 22:22:47 UTC, Arun Chandrasekaran wrote: Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake). Who hasn't ;) Happened to me last time because i tried a command supposed to remove untracked files in submodules...but used "reset" in a wrong way... ouch. If you still lose changes, you could try using Mercurial with hggit. It can be a bit slow, but not destructive as git itself. ;) I really wish Mercurial won instead of git. Now that hg evolve and hg topic are stable, that actually alleviates the need for git. But the world talks git now. So everyone else is forced to talk in git :( I guess, without StackOverflow and GitHub, no one would be using git. Facebook uses Mercurial and their team is working on a Mercurial server in Rust. https://github.com/facebookexperimental/mononoke I thought Facebook uses DLang as well. No one's motivated to write one in DLang?
Re: Thoughts about D
On 12/3/2017 4:25 PM, Michael V. Franklin wrote: It would be great for the compiler devs to run through this exercise themselves and make changes to the compiler/runtime interface to remove the irrelevant requirements the compiler is imposing. I don't agree that creating a stub druntime is better, for reasons mentioned before. As for changing the way the compiler generates code so it is more pay-only-for-what-you-use, I'm all for it. I mentioned already work being done in this direction, PRs for more are welcome.
Re: Thoughts about D
On Monday, 4 December 2017 at 01:01:47 UTC, Michael V. Franklin wrote: .$> dmd -defaultlib= -debuglib= -conf= main.d -of=main /usr/bin/ld: main.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output I didn't compile with -shared. What's going on here? .$> dmd -defaultlib= -debuglib= -conf= main.d -of=main -fPIC main.o:(.text.d_dso_init[.data.d_dso_rec]+0x22): undefined reference to `_d_dso_registry' Again, not sure why the compiler's generated code for that? Ok, well perhaps that makes sense compiling with -fPIC, but the "relocation R_X86_64_32 against `.rodata.str1.1'" seems unnecessary. Mike
Re: Thoughts about D
On Monday, 4 December 2017 at 00:25:53 UTC, Michael V. Franklin wrote: A better solution would be to do what Iain said: Try compiling a simple "hello world" with an empty object.d file. Then inspect what the compiler does. Does it error and exit, or does it ICE? What can be done to prevent that from happening? When you reach the point that there's no way but to declare a symbol or function, add that to object.d and then move onto the next error or ICE. Repeat until you can compile and link your program. Next, try something a little more complex, such as define a struct and use it. Then again address all problems that you encounter with that. Here's an illustration: object.d module object; alias immutable(char)[] string; struct ModuleInfo { } main.d - module main; long sys_write(long arg1, in void* arg2, long arg3) { long result; asm { mov RAX, 1; mov RDI, arg1; mov RSI, arg2; mov RDX, arg3; syscall; } return result; } void write(in string text) { sys_write(2, text.ptr, text.length); } extern(C) void main() { write("Hello\n"); } .$> dmd -defaultlib= -debuglib= -conf= main.d -of=main /usr/bin/ld: main.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Nonrepresentable section on output I didn't compile with -shared. What's going on here? .$> dmd -defaultlib= -debuglib= -conf= main.d -of=main -fPIC main.o:(.text.d_dso_init[.data.d_dso_rec]+0x22): undefined reference to `_d_dso_registry' Again, not sure why the compiler's generated code for that? Would it help for me to file bugzilla issues for things like this? The reason I haven't thus far, is that this is just a symptom of a larger issue. It needs a development strategy to be solved holistically. Mike
Re: Thoughts about D
On Sunday, 3 December 2017 at 23:34:13 UTC, Walter Bright wrote: If -betterC motivates people to come up with better solutions, I'm all for it. A better solution would be to do what Iain said: Try compiling a simple "hello world" with an empty object.d file. Then inspect what the compiler does. Does it error and exit, or does it ICE? What can be done to prevent that from happening? When you reach the point that there's no way but to declare a symbol or function, add that to object.d and then move onto the next error or ICE. Repeat until you can compile and link your program. Next, try something a little more complex, such as define a struct and use it. Then again address all problems that you encounter with that. It would be great for the compiler devs to run through this exercise themselves and make changes to the compiler/runtime interface to remove the irrelevant requirements the compiler is imposing. Mike
Re: git workflow for D
On Sunday, 3 December 2017 at 22:22:47 UTC, Arun Chandrasekaran wrote: Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake). Who hasn't ;) Happened to me last time because i tried a command supposed to remove untracked files in submodules...but used "reset" in a wrong way... ouch. Since then I always access git via mercurial. In comparison Mercurial is far better a VCS tool. I use git gui (i find other GUIs slower even if nicer) but even...there are few commands to know: - checkout /*select a branch or a commit in the history*/ - commit /*validate changes*/ - pull /*get upstream changes*/ - push /*send upstream changes*/ - rebase /*squash - fixup*/ - stash /*backup before pull in case of...*/ you can live with that.
Re: Thoughts about D
On 12/3/2017 11:22 AM, Michael V. Franklin wrote: On Sunday, 3 December 2017 at 12:20:14 UTC, Walter Bright wrote: Meanwhile, we've got -betterC today, and it's simple and it works. IMO -betterC is papering over the problem rather than dealing with it. If -betterC motivates people to come up with better solutions, I'm all for it.
Re: How to declare immutable struct outside of try catch and reference it later
On Sunday, 3 December 2017 at 22:33:40 UTC, kdevel wrote: On Sunday, 3 December 2017 at 14:58:03 UTC, Basile B. wrote: In this case i'd go for a typed pointer, e.g --- immutable struct Configuration { this(string){/*load some file...*/} int value; } Configuration* config; void main() { try config = new Configuration("config.sdl"); catch(Exception){} // config.value = 42; // ok, read only } --- When config is null, e.g. in case "load some file..." threw, you get a segfault. No error handling at all! I don't follow you...the file thing happens in the __ctor. Exceptions are well handled. Maybe you've missed the try (w/o braces) ? --- immutable struct Configuration { this(string){/*parse_config...*/} } Configuration* config; int main() { try { config = new Configuration("config.sdl"); // instead of "conf = parse_config("config.sdl");" } catch(Exception e){ std.stdio.stderr.writeln("Error reading configuration file: ", e.msg); return 1; } } ---
Re: Windows Share Path
On Sun, 03 Dec 2017 16:42:46 +, vino wrote: > Question: > Is there a way to map network drive in windows using D code, similar to > the windows command such as "net use" or "pushd" or powershell command > New-PSDrive.? > > From, > Vino.B There's WNetAddConnection2[1] and WNetAddConnection3[2] in the Windows API. The API header module is core.sys.windows.winnetwk[3]. I've not used either function, but based on the documentation, it looks straightforward. --Ryan [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa385413 (v=vs.85).aspx [2]: https://msdn.microsoft.com/en-us/library/windows/desktop/aa385418 (v=vs.85).aspx [3]: https://github.com/dlang/druntime/ blob/2db828bd4f21807254b770b3ec304f14596a9805/src/core/sys/windows/ winnetwk.d
Re: How to declare immutable struct outside of try catch and reference it later
On Sunday, 3 December 2017 at 14:58:03 UTC, Basile B. wrote: In this case i'd go for a typed pointer, e.g --- immutable struct Configuration { this(string){/*load some file...*/} int value; } Configuration* config; void main() { try config = new Configuration("config.sdl"); catch(Exception){} // config.value = 42; // ok, read only } --- When config is null, e.g. in case "load some file..." threw, you get a segfault. No error handling at all!
Re: git workflow for D
Git CLI is arcane and esoteric. I've lost my commits before (yeah, my mistake). Since then I always access git via mercurial. In comparison Mercurial is far better a VCS tool.
Re: git workflow for D
On Sunday, 3 December 2017 at 20:05:47 UTC, bitwise wrote: I've finally started learning git, due to our team expanding beyond one person - awesome, right? Anyways, I've got things more or less figured out, which is nice, because being clueless about git is a big blocker for me trying to do any real work on dmd/phobos/druntime. As far as working on a single master branch works, I can commit, rebase, merge, squash, push, reset, etc, like the best of em. What I'm confused about is how all this stuff will interact when working on a forked repo and trying to maintain pull requests while everyone else's commits flood in. How does one keep their fork up to date? For example, if I fork dmd, and wait a month, do I just fetch using dmd's master as a remote, and then rebase? Will that actually work, or is that impossible across separate forks/branches? What if I have committed and pushed to my remote fork and still want to merge in the latest changes from dlang's master branch? you can fork it, set dmd/master as upstream and then git fetch upstream. you can then rebase. And how does a pull request actually work? Is it a request to merge my entire branch, or just some specific files? and do I need a separate branch for each pull request, or is the pull request itself somehow isolated from my changes? commits can be cherrypick-ed or you can request your entire branch to be merged. it doesn't always have to be the master branch. for example, if there's std.experimental.logger branch, you can ask for your branch to be merged with that. having a seperate branch for each feature is most of the time the way to go. makes it cleaner for yourself. later on you can delete those merged branches. Anyways, I'd just be rambling if I kept asking questions. If anyone can offer any kind of advice, or an article that explains these things concisely and effectively, that would be helpful. Thanks
[Issue 18028] New: Allow Unnecessary Template Instantiation To Be Dropped
https://issues.dlang.org/show_bug.cgi?id=18028 Issue ID: 18028 Summary: Allow Unnecessary Template Instantiation To Be Dropped Product: D Version: D2 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: j...@jackstouffer.com With function templates, if the template argument(s) have default parameters, the template parentheses doesn't have to be specified: ``` void func(T = float)() { } void main() { func(); } ``` However, this is not the case for structs: ``` struct Test(T = float) { T a; } void main() { auto b = Test(); // Error: struct Test cannot deduce function from argument types !()() auto c = Test!()(); // Compiles } ``` There's no reason to force the user to use explicit template parentheses. Please allow these to be dropped just like functions. --
Re: git workflow for D
On Sunday, 3 December 2017 at 20:05:47 UTC, bitwise wrote: I've finally started learning git, due to our team expanding beyond one person - awesome, right? Anyways, I've got things more or less figured out, which is nice, because being clueless about git is a big blocker for me trying to do any real work on dmd/phobos/druntime. As far as working on a single master branch works, I can commit, rebase, merge, squash, push, reset, etc, like the best of em. What I'm confused about is how all this stuff will interact when working on a forked repo and trying to maintain pull requests while everyone else's commits flood in. How does one keep their fork up to date? Just push to your fork/master after pulling from the (shared) origin/master. For example, if I fork dmd, and wait a month, do I just fetch using dmd's master as a remote, and then rebase? Will that actually work, or is that impossible across separate forks/branches? What if I have committed and pushed to my remote fork and still want to merge in the latest changes from dlang's master branch? In a non personal project you NEVER commit to master. You make each single fucking change in a specific branch (sorry for the language, it's intentionally gross). the master branch is only updated when you pull from the origin. And how does a pull request actually work? Is it a request to merge my entire branch, Yes it's a merge. Optionally all the commits can be squashed. or just some specific files? and do I need a separate branch for each pull request, Yes, yes yes, again. ~master is sacrosanct. or is the pull request itself somehow isolated from my changes? Anyways, I'd just be rambling if I kept asking questions. If anyone can offer any kind of advice, or an article that explains these things concisely and effectively, that would be helpful. Thanks The only article i've ever read about git was when the first time i needed to squash (actually i rather do "fixup" 99% of the time...) so i have nothing else to add.
[Issue 18027] New: CRLF terminators in release tarball files
https://issues.dlang.org/show_bug.cgi?id=18027 Issue ID: 18027 Summary: CRLF terminators in release tarball files Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: matth...@tenstral.net Hi! This issue has been reported first to LDC as https://github.com/ldc-developers/ldc/issues/2402 but affects DMD as well, apparently. Some files in DMDs testsuite use windows line terminators, which confuses Git unless it is configured to accept these. This messes with Linux distribution packaging workflow in Debian, so it would be neat if that could be fixed. A list of affected files can be found in the LDC issue report linked above. Thanks! --
git workflow for D
I've finally started learning git, due to our team expanding beyond one person - awesome, right? Anyways, I've got things more or less figured out, which is nice, because being clueless about git is a big blocker for me trying to do any real work on dmd/phobos/druntime. As far as working on a single master branch works, I can commit, rebase, merge, squash, push, reset, etc, like the best of em. What I'm confused about is how all this stuff will interact when working on a forked repo and trying to maintain pull requests while everyone else's commits flood in. How does one keep their fork up to date? For example, if I fork dmd, and wait a month, do I just fetch using dmd's master as a remote, and then rebase? Will that actually work, or is that impossible across separate forks/branches? What if I have committed and pushed to my remote fork and still want to merge in the latest changes from dlang's master branch? And how does a pull request actually work? Is it a request to merge my entire branch, or just some specific files? and do I need a separate branch for each pull request, or is the pull request itself somehow isolated from my changes? Anyways, I'd just be rambling if I kept asking questions. If anyone can offer any kind of advice, or an article that explains these things concisely and effectively, that would be helpful. Thanks
Re: Thoughts about D
On Sunday, 3 December 2017 at 12:20:14 UTC, Walter Bright wrote: It may indeed work to use a special druntime. My expectation, however, is that it's a lot more work trying to develop and support another runtime library, and a lot more work for the user trying to get that library worked into his build system. This will drastically cut down on the number of users willing to give it a try. I don't think it's necessary for you or anyone else to create a special officially supported runtime. What I need is a way to create a very minimal runtime that supports just the features of D that I'm opting in to, without having to write phony stubs and boiler plate that, in the end, is just going to be discarded by the linker. Currently the compiler expects things to exist in the runtime that have no hope of ever being used, just to get a build. In fact, one can compile against the stock object.d to satisfy the compiler, but then omit linking to druntime, and still get a proper binary. I had to stop pursuing it because I couldn't suggest it professionally and expect to be taken seriously. Meanwhile, we've got -betterC today, and it's simple and it works. IMO -betterC is papering over the problem rather than dealing with it. Mike
Re: Thoughts about D
On Sunday, 3 December 2017 at 12:20:14 UTC, Walter Bright wrote: It may indeed work to use a special druntime. My expectation, however, is that it's a lot more work trying to develop and support another runtime library, and a lot more work for the user trying to get that library worked into his build system. It's pretty easy, actually, and you can then selectively opt into features by copying function implementations as you need them. That said, I like the idea of betterC just working... as long as it doesn't break the opt-in option. Meanwhile, we've got -betterC today, and it's simple and it works. It is a bit simpler than the old way, but not that much... like other people have copy/pasted my minimal object.d into new projects and gotten it to work pretty easily. Downloading a file and compiling isn't much different than compiling with -betterC. (And actually, my minimal one gives you classes and exceptions if you want them too via -version! And is bare-metal compatible as well, which -betterC still needs a few little stubs to work on right now.) So it is one thing to say "this is a bit more convenient", but don't say "this enables something D couldn't do before". The latter is patently false in all contexts, and in some of those contexts, further spreads FUD about druntime.
Re: Implicit nothrow with -betterC
On Sunday, 3 December 2017 at 15:24:27 UTC, Manuel Maier wrote: I've been experimenting with the -betterC switch and stumbled upon something that didn't quite make sense to me. betterC doesn't change the language, it just doesn't compile in all the features automatically. So rules about nothrow etc. decorations are still in place, even if the feature isn't actually available at this time. The same code you build with -betterC can almost always be built without the switch too, and continue to work the same way. According to the docs, exceptions "won't work": That may be a temporary restriction. It is already possible to do exceptions with -betterC code if you link in the functions yourself (notably, betterC modules are permitted to be used in a regular druntime based application), and in the future, such may be done automatically on demand too.
Re: Windows Share Path
On Sunday, 3 December 2017 at 01:27:40 UTC, codephantom wrote: On Saturday, 2 December 2017 at 14:23:48 UTC, Vino wrote: Hi, Even tried the Option "Run with Highest Privilege" but no luck. and also tried with option "Configure for : Windows Vista , Windows Server 2008" From, Vino.B You haven't accidently ticked the 'Do not store password' option? That is a common mistake. (i.e. make sure it's *not* ticked, and reinsert credentials). In my 'sysadmin' days, I *refused* to use the windows scheduler. I didn't want something that kept changing depending on which version of windows you were using. I wanted consistency. From memory, i think I installed 'system scheduler' on all my MS servers. https://www.splinterware.com/tour/scheduler.html Hi All, Finally was able to resolve the issue, the issue was, the windows share was mapped using domain user so when the .bat program is scheduled via task manager with the option "Run whether the user is logged in or not" the .bat script run the task in session 0, where as the windows share was mapped in user session (domain user , session 23), so the the D program was not able to find the windows share path, so add the windows command "net use \\server\share" as the first line in the .bat and then added line calling the D program which resolved the issue. Option : Do not store password was unchecked" Solution: D Program(TestDir.exe) import std.stdio; import std.file; import std.path; void main() { auto p = "N:BACKUP"; if (!p.isValidPath && !p.strip.isValidFilename || !p.exists ) { writeln("Invalid File Path (", p, ") or Path do not Exist"); } else { writeln("File Exist":, p); } } } Bat Program(Run.bat) @echo off net use N: \\shareserver\sharename /Persistence: No start /D D:\DScript /B /WAIT D:\DScript\TestDir.exe exit Question: Is there a way to map network drive in windows using D code, similar to the windows command such as "net use" or "pushd" or powershell command New-PSDrive.? From, Vino.B
[Issue 12842] More support for ranges of ranges
https://issues.dlang.org/show_bug.cgi?id=12842 Neia Neutuladhchanged: What|Removed |Added CC||dhase...@gmail.com --- Comment #2 from Neia Neutuladh --- This bit me today with cartesianProduct. I'd naively expect to be able to do something like: iota(3).map!(x => iota(1, 7)).cartesianProduct to get all possible results for rolling three six-sided dice. Unfortunately, I had to write my own implementation of cartesianProduct to make it work. --
template specialization and Rebindable
Why is template param T != B but T == Rebindable!(const(B)) when specialization is T : const(A)? abstract class A{} class B : A{} string foo(T : const(A))(T x){ return T.stringof; } void main(){ import std.typecons : Rebindable; import std.stdio : writeln; Rebindable!(const B) b = new B; auto bar = foo(b); assert(bar == "Rebindable!(const(B))"); }
Re: LDC 1.6.0-beta1
On 2017-12-03 12:52, kinke wrote: Working on that. It's not that simple though; we use a custom LLVM, which Travis doesn't manage to build alone in a dedicated job (only ~66% before timing out). Hmm, I would need to do that as well for DStep :(. That's disappointing. Would caching help [1]? I've also though about using Docker, which could contain a pre-built, perhaps that's more complicated. Luckily, there's AppVeyor and CircleCI which manage. So I need to finish automating the LLVM release before automating the LDC release. I see. [1] https://docs.travis-ci.com/user/caching/ -- /Jacob Carlborg
Re: Struct inside a class: How to get outer?
On 2017-12-03 10:57, Nick Sabalausky (Abscissa) wrote: On 12/03/2017 03:46 AM, bauss wrote: It wouldn't make much sense either, if a struct was able to do it. Why is that? It would get an extra field, making the size of the struct larger and not compatible with a C struct. But I guess you wouldn't use a nested struct for that anyway. -- /Jacob Carlborg
[Issue 18026] New: Stack overflow in ddmd/dtemplate.d:6241, TemplateInstance::needsCodegen()
https://issues.dlang.org/show_bug.cgi?id=18026 Issue ID: 18026 Summary: Stack overflow in ddmd/dtemplate.d:6241, TemplateInstance::needsCodegen() Product: D Version: D2 Hardware: x86_64 OS: Linux Status: NEW Severity: normal Priority: P1 Component: dmd Assignee: nob...@puremagic.com Reporter: zor...@gmail.com Arch/Manjaro 64-bit, dmd v2.077.0 and ldc 1.6.0 (2.076.1) from official repositories. Tested on two machines with similar setups. Could not reproduce in Windows (32-bit), and I didn't seem to have the libraries for 32-bit linux builds so could not test that. I've run into this on more than once now. In cases that are difficult to isolate and reason about, dmd and ldc will both fail to compile with dub -b plain and dub -b release, exiting with code -11. -b debug and -b unittest work fine. Things like in what order files are specified when compiling matters. I've even managed to get it to a point where it builds sometimes (!) and other times errors out. > zorael@xps ~/src/kameloso [overflow] $ dub build -b plain --force > Performing "plain" build using dmd for x86_64. > kameloso ~overflow: building configuration "application"... > Linking... > > zorael@xps ~/src/kameloso [overflow] $ dub build -b plain --force > Performing "plain" build using dmd for x86_64. > kameloso ~overflow: building configuration "application"... > dmd failed with exit code -11. In https://forum.dlang.org/post/peaywtdvlrohnohjx...@forum.dlang.org I managed to find one line to change that fixed one issue (replaced size_t with uint). I now ran into a different case where it breaks if I remove a particular function call line in a function. I wanted to move it to a different module, so what I end up having to do is renaming the original function and keeping it with just that one critical line in it. > void removeMeWhenPossible() > { > import kameloso.debugging : formatEventAssertBlock; > import std.array : Appender; > > Appender!(char[]) sink; > sink.formatEventAssertBlock(IRCEvent.init); // <-- stack overflow > without this line > assert(0); > } As mentioned on the forum page with the issue there, gdb on a debug dmd showed a stack overflow in TemplateInstance::needsCodegen(). > 6233| // Determine necessity of tinst before tnext. > 6234| if (tinst && tinst.needsCodegen()) > 6235| { > 6236| minst = tinst.minst; // cache result > 6237| assert(minst); > 6238| assert(minst.isRoot() || minst.rootImports()); > 6239| return true; > 6240| } > 6241|--> if (tnext && (tnext.needsCodegen() || tnext.minst)) > 6242| { > 6243| minst = tnext.minst; // cache result > 6244| assert(minst); > 6245| return minst.isRoot() || minst.rootImports(); 6246 The ldc output seems to agree; > /usr/lib/libLLVM-5.0.so(_ZN4llvm3sys15PrintStackTraceERNS_11raw_ostreamE+0x2b)[0x7fd8b08329bb] > /usr/lib/libLLVM-5.0.so(_ZN4llvm3sys17RunSignalHandlersEv+0x56)[0x7fd8b0830806] > /usr/lib/libLLVM-5.0.so(+0x808953)[0x7fd8b0830953] > /usr/lib/libpthread.so.0(+0x11da0)[0x7fd8afe1bda0] > ldc(_ZN16TemplateInstance12needsCodegenEv+0xfe)[0x56173bcef2c2] > ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x56173bcef2c7] > ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x56173bcef2c7] > ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x56173bcef2c7] > ldc(_ZN16TemplateInstance12needsCodegenEv+0x103)[0x56173bcef2c7] > [...] I managed to produce a smaller test case by just gutting my project and seeing how small I could get a broken sample. There were a lot of places where commenting something out fixed it. It still weighs in at just less than 1k sloc (ignoring arsd modules) and it's full of stubs and noops, but it's easy to compile. > $ git clone -b overflow https://github.com/zorael/kameloso.git The latest commit in that overflow branch (00f375) builds *sometimes*, while the commit previous to it (546cea or HEAD~) reliably fails every time. I stopped trying to reduce there. I'm not sure if any of this helps, but Petar Kirov [ZombineDev] suggested I report it in either case. --
Re: Thoughts about D
On 3 December 2017 at 13:20, Walter Bright via Digitalmars-dwrote: > On 12/3/2017 2:32 AM, Iain Buclaw wrote: >> >> People have been making alternative druntime libraries for a while >> now, either as stubs inside their own project, or by using minilibd. >> There's nothing stopping you from simply swapping out druntime for >> another implementation. > > > It may indeed work to use a special druntime. My expectation, however, is > that it's a lot more work trying to develop and support another runtime > library, and a lot more work for the user trying to get that library worked > into his build system. This will drastically cut down on the number of users > willing to give it a try. > > (Consider the ENDLESS problems Win64 users have trying to link in the VC C > runtime library, something that should be trivial. And these are experienced > VC developers.) > > Meanwhile, we've got -betterC today, and it's simple and it works. I prefer the approach of, try compiling a simple "hello world" with an empty object.d file. Then inspect what the compiler does. Does it error and exit, or does it ICE? What can be done to prevent that from happening? When you reach the point that there's no way but to declare a symbol or function, add that to object.d and then move onto the next error or ICE. Repeat until you can compile and link your program. Next, try something a little more complex, such as define a struct and use it. Then again address all problems that you encounter with that. What you end up with, should be a compiler that is less coupled to the existence of object.d and all its definitions than what it was before. Doing things this way in a bottom-up fashion has allowed people to use gdc to target STM micro controllers.
Implicit nothrow with -betterC
I've been experimenting with the -betterC switch and stumbled upon something that didn't quite make sense to me. I've put together a small example [1] of Win32 code with a window callback that has to be nothrow as per the definition of WNDPROC somewhere in core.sys.windows. However, calling anything from within the window callback not marked as nothrow will result in a compile error. This behavior is expected for regular D code and there are many ways to fix the code so the compiler no longer emits the error. What bugs me is the following. According to the docs, exceptions "won't work": From https://dlang.org/spec/betterc.html#consequences As no Druntime is available, many D features won't work. For example: [...] 7. Exceptions [...] To me, this means it should be impossible to write -betterC code that throws exceptions. So shouldn't -betterC imply nothrow on all functions by default? Is this a compiler bug? If not, in what way is the explicit nothrow attribute still useful for -betterC? [1] https://gist.github.com/Manuzor/81cc01d57543202d68eab5a84d944027
Re: How to declare immutable struct outside of try catch and reference it later
On Sunday, 3 December 2017 at 05:49:54 UTC, Fra Mecca wrote: I have this code: Configuration conf = void ; try { conf = parse_config("config.sdl"); } catch (Exception e) { std.stdio.stderr.writeln("Error reading configuration file: ", e.msg); exit(1); } // other code function(value, conf); // end I get: source/app.d(18,3): Error: cannot modify struct conf Configuration with immutable members Is there a way to declare conf outside of the try catch block and use it later? I thought void explicitly avoid inizialization. In this case i'd go for a typed pointer, e.g --- immutable struct Configuration { this(string){/*load some file...*/} int value; } Configuration* config; void main() { try config = new Configuration("config.sdl"); catch(Exception){} // config.value = 42; // ok, read only } ---
Re: How to declare immutable struct outside of try catch and reference it later
On Sunday, 3 December 2017 at 14:16:42 UTC, kdevel wrote: int main () { try { real_main (); } catch (Exception e) { std.stdio.stderr.writeln(e.msg); return 1; } return 0; } ``` This is better: int main () { try { return real_main (); } catch (Exception e) { std.stdio.stderr.writeln(e.msg); return 1; } }
Re: Building is slow!
On Saturday, 2 December 2017 at 23:26:20 UTC, Ivan Trombley wrote: On Saturday, 2 December 2017 at 14:34:58 UTC, Arek wrote: You can try `dub build --build-mode=single-file --parallel`. It will execute separate instance of compiler for each source file. If --parallel is given, dub will launch several instances of dmd in parallel. I get the error: Error processing arguments: BuildMode does not have a member named 'single-file' Sorry, my mistake. `--build-mode=singleFile` On Saturday, 2 December 2017 at 22:54:56 UTC, Indigo wrote: I haven't tried gtkd in a while but when I did it built in seconds... I was not using dub though but the build script that comes with it. My project has "dependencies": { "gtk-d": "3.7.2" } To build release, it takes more than three minutes to build gtk-d on Linux (Ryzen 7 1700 processor). The only reason for really long builds I know, was a lack of memory and swapping.
Re: How to declare immutable struct outside of try catch and reference it later
On Sunday, 3 December 2017 at 05:49:54 UTC, Fra Mecca wrote: I have this code: Configuration conf = void ; try { conf = parse_config("config.sdl"); } catch (Exception e) { std.stdio.stderr.writeln("Error reading configuration file: ", e.msg); exit(1); } Since most programs have more than place where execution must be terminated, you end up dupliating that try-catch-code all over the program making it unreadable. When you try to avoid calling exit this problem will not arise. You can simply write ``` auto conf = parse_config("config.sdl"); ``` The exception unwinds the stack and terminates the program. If a stacktrace on the command line does not suffice I would wrap the main-code in a try-catch block. Your function parse_config should support this coding style by putting a whole sentence into the Exception instead of the mere filename, then the try-catch wrapper in main may look like this: ``` int main () { try { real_main (); } catch (Exception e) { std.stdio.stderr.writeln(e.msg); return 1; } return 0; } ```
[Issue 17723] Replace Facebook on the front page with Weka.io
https://issues.dlang.org/show_bug.cgi?id=17723 --- Comment #3 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/dlang.org https://github.com/dlang/dlang.org/commit/d77bf4c58bf8d659b764631e4954edc9647d8feb Fix Issue 17723 - Replace Facebook on the front page with Weka.io https://github.com/dlang/dlang.org/commit/6dc97ac454b185f00222fc8079d9f23d62af65a7 Merge pull request #1937 from wilzbach/fix-17723 Fix Issue 17723 - Replace Facebook on the front page with Weka.io merged-on-behalf-of: Petar Kirov--
LDC 1.6.0
Hi everyone, on behalf of the LDC team, I'm glad to announce LDC 1.6. The highlights of this version in a nutshell: * Based on D 2.076.1. * Experimental support for dynamic codegen at runtime ('manual JIT'). * Many std.math functions are now CTFE-able. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.6.0 Thanks to all contributors! [LDC master is at v2.077.1.]
Re: First Impressions!
On Saturday, 2 December 2017 at 22:16:09 UTC, Joakim wrote: On Friday, 1 December 2017 at 23:16:45 UTC, H. S. Teoh wrote: On Fri, Dec 01, 2017 at 03:04:44PM -0800, Walter Bright via Digitalmars-d wrote: On 11/30/2017 9:23 AM, Kagamin wrote: > On Tuesday, 28 November 2017 at 03:37:26 UTC, rikki > cattermole wrote: > > Be aware Microsoft is alone in thinking that UTF-16 was > > awesome. Everybody else standardized on UTF-8 for Unicode. > > UCS2 was awesome. UTF-16 is used by Java, JavaScript, > Objective-C, Swift, Dart and ms tech, which is 28% of tiobe > index. "was" :-) Those are pretty much pre-surrogate pair designs, or based on them (Dart compiles to JavaScript, for example). UCS2 has serious problems: 1. Most strings are in ascii, meaning UCS2 doubles memory consumption. Strings in the executable file are twice the size. This is not true in Asia, esp. where the CJK block is extensively used. A CJK block character is 3 bytes in UTF-8, meaning that string sizes are 150% of the UCS2 encoding. If your code contains a lot of CJK text, that's a lot of bloat. Yep, that's why five years back many of the major Chinese sites were still not using UTF-8: http://xahlee.info/w/what_encoding_do_chinese_websites_use.html Summary Taiwan sites almost all use UTF-8. Very old ones still use BIG5. Mainland China sites mostly still use GBK or GB2312, but a few newer ones use UTF-8. Many top Japan, Korea, sites also use UTF-8, but some uses EUC (Extended Unix Code) variants. This probably means that UTF-8 might dominate in the future. mmmh That led that Chinese guy to also rant against UTF-8 a couple years ago: http://xahlee.info/comp/unicode_utf8_encoding_propaganda.html A rant from someone reproaching a video it doesn't provide reasons why utf-8 is good by not providing any reasons why utf-8 is bad. I'm not denying the issues with utf-8, only that the ranter doesn't provide any useful info on what the issues the "Asian" encounter with it, besides legacy reasons (which are important but do not enter in judging the technical quality of an encoding). Add to that that he advocates for GB18030 which is quite inferior to utf-8 except in the legacy support area (here some of the advantages of utf-8 that GB-18030 does not possess: auto-synchronization, algorithmic mapping of codepoints, error detection). If his only beef with utf-8 is the size for CJK text then he shouldn't argue for UTF-32 as he seems to do at the end.
Re: Thoughts about D
On 12/3/2017 2:32 AM, Iain Buclaw wrote: People have been making alternative druntime libraries for a while now, either as stubs inside their own project, or by using minilibd. There's nothing stopping you from simply swapping out druntime for another implementation. It may indeed work to use a special druntime. My expectation, however, is that it's a lot more work trying to develop and support another runtime library, and a lot more work for the user trying to get that library worked into his build system. This will drastically cut down on the number of users willing to give it a try. (Consider the ENDLESS problems Win64 users have trying to link in the VC C runtime library, something that should be trivial. And these are experienced VC developers.) Meanwhile, we've got -betterC today, and it's simple and it works.
Re: LDC 1.6.0-beta1
On Saturday, 2 December 2017 at 23:08:50 UTC, David Nadlinger wrote: On Saturday, 2 December 2017 at 15:47:23 UTC, Jacob Carlborg wrote: On 2017-12-02 13:41, kinke wrote: Nope, unfortunately still waiting for one of my compadres to create and upload the OSX package. Have you thought of automatically build and upload packages using Travis CI? Working on that. It's not that simple though; we use a custom LLVM, which Travis doesn't manage to build alone in a dedicated job (only ~66% before timing out). Luckily, there's AppVeyor and CircleCI which manage. So I need to finish automating the LLVM release before automating the LDC release. That would be a good idea. Also, I uploaded the OS X package just now. (Didn't realise it wasn't built yet…). —David Thx.
Re: Thoughts about D
On 3 December 2017 at 00:56, Walter Bright via Digitalmars-dwrote: > On 12/2/2017 4:13 AM, Iain Buclaw wrote: >> >> On 29 November 2017 at 03:18, Walter Bright via Digitalmars-d >> wrote: >>> >>> On 11/28/2017 9:27 AM, Jacob Carlborg wrote: Why would druntime be a barrier for you for those projects? >>> >>> >>> >>> When the C version is 90K and the translated D version is 1200K, it is a >>> barrier. It's a barrier for others, as well. >>> >> >> Did you add an extra 0 here for the D version? > > > No. I used the sizes for MicroEmacs in C vs MicroEmacs in D. (I translated > the former into the latter.) > > With BetterC, I've been able to create virtually identical binaries for C > and D. > > Ah, you're referring to binary sizes. Well you have two central components which do well to bolster that, core.thread and the GC. I guess if your project is to port something from C to D. You'd start out with `extern(C) int main() @nogc` and go from there. That then leaves moduleinfo, to which there already exists the machinery in the compiler for determining whether it needs to be generated, dmd could start using it again instead of defaulting to always generating moduleinfo symbols that pull in druntime. That would mean a switch that gives fine control over generation (-moduleinfo=[on|asneeded|off]), still better than a betterC feature gate. >>> Another barrier for me has turned out to be the way assert() works in D. >>> It >>> just is not lightweight, and it visibly slows down dmd to have assert's >>> turned on internally. The amount of machinery involved with it in >>> druntime >>> is way overblown. Hence, asserts in dmd are turned off, and that wound up >>> causing me a lot of problems recently. There are even initiatives to add >>> writefln like formatting to asserts. With betterC, asserts became >>> lightweight and simple again. >> >> I find this assertion hard to believe (pun not intended). Unless you >> are omitting some extra check (invariant calls?), whether you are >> using D's assert or C's assert, both have the same runtime cost. > > > asserts are significantly larger in D. One reason is the filename string is > passed as a D string, which is 2 pushes. A C string is one push. > D strings require one extra push, true. But what's that, one extra clock cycle? Not even the cost of half a crown. > Consider that D asserts throw an exception. Where's the catch going to be, > if you're linking the D code into a C program? And the D personality > function, needed for D exception unwinding, is in druntime. > If there is no catch, what happens is that unwind raise exception returns end of stack, and you abort in the throw() function. > >>> BetterC is a door-opener for an awful lot of areas D has been excluded >>> from, >>> and requiring druntime is a barrier for that. >> >> It's not a door opener, and druntime is not a barrier. > > > If you have a C program, and want to add a D function to it, you really > don't want to add druntime as well. BetterC enables people to provide D > addon libraries for people who have C main programs. > > There's a point to making incremental use of D as low cost as possible. > People have been making alternative druntime libraries for a while now, either as stubs inside their own project, or by using minilibd. There's nothing stopping you from simply swapping out druntime for another implementation.
Re: Struct inside a class: How to get outer?
On 12/03/2017 03:46 AM, bauss wrote: On Sunday, 3 December 2017 at 07:38:47 UTC, Jonathan M Davis wrote: As I understand it, there is no outer for nested structs, only nested classes. So, you'll either have to use a nested class or explicitly pass a reference to the outer class to the nested struct. It wouldn't make much sense either, if a struct was able to do it. Why is that?
Re: Thoughts about D
On 3 December 2017 at 08:29, Richard Delorme via Digitalmars-dwrote: > On Saturday, 2 December 2017 at 23:44:39 UTC, Walter Bright wrote: >> >> On 12/2/2017 4:38 AM, Iain Buclaw wrote: >>> >>> But then you need to bloat your program with debug info in order to >>> understand what, why, and how things went wrong. >> >> >> Most of the time (for me) that isn't necessary, because the debugger still >> shows where it failed and that's enough. >> >> Besides, you can always rerun the test case with a debug build. > > > +1 > To me, the current D assert is useless, and I prefer to use a C-like > equivalent, that "crash" the program without unwinding the stack. Then I can > inspect the cause of the crash on a debugger, with access to the current > context (variable contents, etc.), is it from a (core file) or by running > the program on the debugger. That way I do find the bug(s) much faster. > More generally treating errors (ie bugs) as unrecoverable exceptions is a > mistake in IMHO. I prefer a call to the C function abort() that leaves the > context intact. > Core dumps are of no use if there's no debug info. ;-)
Re: Thoughts about D
On 11/30/2017 7:43 PM, Adam D. Ruppe wrote: int 3, on the other hand, is explicitly for debugging - which is what we want asserts to be. https://github.com/dlang/dmd/pull/7391
Re: Struct inside a class: How to get outer?
On Sunday, 3 December 2017 at 07:38:47 UTC, Jonathan M Davis wrote: On Sunday, December 03, 2017 01:05:00 Nick Sabalausky via Digitalmars-d- learn wrote: Is this even possible? My attempts: class Outer { struct Inner { void foo() { // Error: no property 'outer' for type 'Inner' Outer o = this.outer; // Error: cannot implicitly convert expression // this of type Inner to testNested.Outer Outer o = this; } } } As I understand it, there is no outer for nested structs, only nested classes. So, you'll either have to use a nested class or explicitly pass a reference to the outer class to the nested struct. - Jonathan M Davis It wouldn't make much sense either, if a struct was able to do it.
Re: Thoughts about D
On 2017-12-03 08:29, Richard Delorme wrote: +1 To me, the current D assert is useless, and I prefer to use a C-like equivalent, that "crash" the program without unwinding the stack. Then I can inspect the cause of the crash on a debugger, with access to the current context (variable contents, etc.), is it from a (core file) or by running the program on the debugger. Ideally druntime should identify if it's running inside a debugger and adapt accordingly. -- /Jacob Carlborg
Re: LDC 1.6.0-beta1
On 2017-12-03 00:08, David Nadlinger wrote: That would be a good idea. Also, I uploaded the OS X package just now. (Didn't realise it wasn't built yet…). —David Here's the Travis CI script for one of my projects [1] that uploads to a GitHub release, both for Linux and macOS. [1] https://github.com/jacob-carlborg/remarkify/blob/master/.travis.yml -- /Jacob Carlborg
Re: Thoughts about D
On Saturday, 2 December 2017 at 23:44:39 UTC, Walter Bright wrote: On 12/2/2017 4:38 AM, Iain Buclaw wrote: But then you need to bloat your program with debug info in order to understand what, why, and how things went wrong. Most of the time (for me) that isn't necessary, because the debugger still shows where it failed and that's enough. Besides, you can always rerun the test case with a debug build. Ehm, if it’s a simple reproducable tool. Good luck debugging servers like that.