[Issue 18022] DDoc: reduce ddoc has UT between documentation

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18022

RazvanN  changed:

   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

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18028

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 18029] extra dtor call with typed variadic argument (or missing postblit)

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18029

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--

[Issue 18029] New: extra dtor call with typed variadic argument (or missing postblit)

[d-bugmail--- via Digitalmars-d-bugs]

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

[Adam Wilson via Digitalmars-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

[Walter Bright via Digitalmars-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

[Adam Wilson via Digitalmars-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

[Patrick Schluter via Digitalmars-d-learn]

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

[ketmar via Digitalmars-d-learn]

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

[Walter Bright via Digitalmars-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

[Walter Bright via Digitalmars-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

[Arun Chandrasekaran via Digitalmars-d-learn]

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

[Walter Bright via Digitalmars-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

[Michael V. Franklin via Digitalmars-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

[Michael V. Franklin via Digitalmars-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

[Michael V. Franklin via Digitalmars-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

[Basile B. via Digitalmars-d-learn]

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

[Walter Bright via Digitalmars-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

[Basile B. via Digitalmars-d-learn]

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

[rjframe via Digitalmars-d-learn]

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

[kdevel via Digitalmars-d-learn]

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

[Arun Chandrasekaran via Digitalmars-d-learn]

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

[Mengu via Digitalmars-d-learn]

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

[d-bugmail--- via Digitalmars-d-bugs]

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

[Basile B. via Digitalmars-d-learn]

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

[d-bugmail--- via Digitalmars-d-bugs]

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

[bitwise via Digitalmars-d-learn]

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

[Michael V. Franklin via Digitalmars-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

[Adam D. Ruppe via Digitalmars-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

[Adam D. Ruppe via Digitalmars-d-learn]

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

[vino via Digitalmars-d-learn]

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

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=12842

Neia Neutuladh  changed:

   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

[vit via Digitalmars-d-learn]

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

[Jacob Carlborg via Digitalmars-d-announce]

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?

[Jacob Carlborg via Digitalmars-d-learn]

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()

[d-bugmail--- via Digitalmars-d-bugs]

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

[Iain Buclaw via Digitalmars-d]

On 3 December 2017 at 13:20, Walter Bright via Digitalmars-d
 wrote:
> 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

[Manuel Maier via Digitalmars-d-learn]

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

[Basile B. via Digitalmars-d-learn]

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

[kdevel via Digitalmars-d-learn]

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!

[Arek via Digitalmars-d]

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

[kdevel via Digitalmars-d-learn]

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

[d-bugmail--- via Digitalmars-d-bugs]

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

[kinke via Digitalmars-d-announce]

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!

[Patrick Schluter via Digitalmars-d]

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

[Walter Bright via Digitalmars-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

[kinke via Digitalmars-d-announce]

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

[Iain Buclaw via Digitalmars-d]

On 3 December 2017 at 00:56, Walter Bright via Digitalmars-d
 wrote:
> 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?

[Nick Sabalausky (Abscissa) via Digitalmars-d-learn]

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

[Iain Buclaw via Digitalmars-d]

On 3 December 2017 at 08:29, Richard Delorme via Digitalmars-d
 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.
>
>
> +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

[Walter Bright via Digitalmars-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?

[bauss via Digitalmars-d-learn]

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

[Jacob Carlborg via Digitalmars-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

[Jacob Carlborg via Digitalmars-d-announce]

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

[Dmitry Olshansky via Digitalmars-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.