Re: Note from a donor

[codephantom via Digitalmars-d]

On Thursday, 26 October 2017 at 20:44:49 UTC, Adam Wilson wrote:
The XCode installer DMG is 5GB, before unpacking. And unlike 
VS17, I can't pick and choose. :)



here is an update...( objective: Write some code in D, and build 
a 64bit .exe)


started downloading offline install of vs2017 buildtools at: 
12:04pm


finished downloading them at: 3:25pm (actual time it finished, 
not the time I came back to it).


so...3 hours and 20 min later... I have an offline installation 
of build tools


6.83GB
3791 files
1919 folders

let's try installing those buildtools . 3.55pm (when I got back 
to the pc)


vs_BuildTools.exe
(setup window pops upsays "Give us a minute..we'll be done 
soon."... but then disappears a few seconds later)


what's going on...try again..same thing..try again..nope...

turns out I had disabled my internet connection, and setup needs 
to use it for some reason, or the setup windows just disappears 
without telling the user anything).


(I expect setup need the internet to verify certificates or 
something - I think you can install them manually too, in offline 
mode)...but gee...I wish setup had told me something..anything!!


ok...so enabled internet connection, and try vs_BuildTools.exe


vs_BuildTools.exe  (ok...were off..installing 379MB)


..so what is the other 6.5GB needed for then?

4:03pm - build tools installed. pc needs to restart

booted up..ready to go..lets try installing dmd again..

error: For 64-bit support MSVC and Windows SDK are needed but no 
compatible version were found.Do you want to install VS2013?


No. I do not!

Let's continue installing DMD anywayoh another message pops 
up...Could not detect Visual Studio (2008-2017 are supported). No 
64-bit support.


That's it!

I've had enough!

4 hours wasted!

Re: Note from a donor

[rikki cattermole via Digitalmars-d]

On 26/10/2017 10:38 PM, MrSmith wrote:

On Thursday, 26 October 2017 at 17:02:40 UTC, Mike Parker wrote:
That's exactly the kind of developer background I'm thinking of. 
Getting permission to redistribute from MS would be the ideal 
solution. If not, I'm sure someone will find a way to make it work 
with the LLVM or MinGW tools eventually.


Would it be possible to create import libs that for all winapi/crt libs, 
and redistribute them? Will such libs be legal to redist?
We have the tools (DMD/LLD), but the dependency on winsdk and VS libs is 
still there, unfortunatelly.


Those files should be included with the request to Microsoft.

The website dlang.org load slowly in China

[netmou (come from china) via Digitalmars-d-learn]

Great wall prevent browser to load resource from some  IP 
(eg:google.com)

So the best way is remove CDN resource

Re: D for microservices

[Jonathan M Davis via Digitalmars-d]

On Thursday, October 26, 2017 19:19:57 Adam Wilson via Digitalmars-d wrote:
> On 10/26/17 17:51, Jonathan M Davis wrote:
> > On Thursday, October 26, 2017 03:25:24 Adam Wilson via Digitalmars-d 
wrote:
> >> On 10/25/17 23:57, Jacob Carlborg wrote:
> >>> I'm more concerned that I don't think we'll manage to implement a
> >>> complete API and 100% bug free at the first try.
> >>
> >> Depends on how one defines first try. Phobos as a pretty solid process
> >> for making sure these things are reasonably bug free. And near as I can
> >> tell, Phobos is pretty good about accepting bug fixes.
> >
> > The bigger problem is API bugs. The review process is rigorous enough to
> > weed out a lot of stuff, but the end result is typically an API that we
> > _think_ looks good but usually hasn't seen much real world use (much as
> > its design may be based on real world experience). And if it turns out
> > that the API has problems, it can be very difficult to fix that in a
> > way that doesn't break code. Sometimes, we're able to reasonably do
> > something about it and sometimes not. In theory, std.experimental would
> > mitigate that, and that's where anything that was accepted would go
> > first, but the process for getting new modules into Phobos is very much
> > geared towards getting an API right up front rather than getting
> > something that's close and iterating towards where it ultimately should
> > be.
> >
> > What would probably be better in general would be to be writing stuff
> > that ends up on code.dlang.org first and gets some real world use there
> > and then look at getting it into Phobos later rather than aiming
> > directly for Phobos. Not only would that likely help lead towards
> > better code being in Phobos, but we'd still get useful stuff even if it
> > didn't make it into Phobos.
> >
> > - Jonathan M Davis
>
> I understand the concern, however, I can see potential mitigations. For
> one, steal an API concept from somewhere else. I've had reasonable
> success so far stealing ADO.NET and the refactoring it into something
> more idiomatic. Using that as a starting point gave me a pretty good
> understanding of what was needed and it gave me a prototype API that has
> been battle-tested.
>
> Has anything from code.dlang.org been pulled into Phobos yet? I'm not
> aware of anything. code.dlang.org is where Phobos projects go to quietly
> die in obscurity.

Nothing has been pulled into Phobos from anywhere in a while. The last thing
was probably checkedint, and before that it was std.allocator - both of
which came from Andrei. ndslice was in std.experimental for a little while
but Ilya removed it, because he decided that it wasn't working to have it in
Phobos, because he couldn't continue to improve on it there. Beyond that, I
think that the last thing was the logger, which has just languished in
std.experimental. It's my understanding that it needs some more work, but
basically, once we added std.experimental, nothing has made it into Phobos
proper. And over the last few years, there haven't been many attempts to get
anything into Phobos, so not much has even made it into std.experimental.

There was the GSoC project for a new XML parser, but that project seems to
have died after the student got too busy with school after GSoC, and Sonke's
std.json replacement didn't finish making its way through the review
process, and I think that Sonke has given up on getting it in (if I
understand correctly, there was just too much disagreement over what the
std.json replacement should look like). Overall, people have just stopped
trying to get major stuff into Phobos. New functions get added to existing
modules, but pretty much no one seems to want to go through the Phobos
review process to get anything into Phobos.

code.dlang.org is where folks put anything that they're doing that they want
to make available, and IIRC, the only item from there that's even attempted
to make it into Phobos was Sonke's JSON parser. Much as some folks continue
to talk about getting some piece of functionality into Phobos, no one is
trying if it's anything major.

So, it's not like Phobos projects are going to code.dlang.org to die. In
general, they simply aren't even being attempted, and any serious projects
that do exist are on code.dlang.org. Some do sit there unfinished (e.g.
std_experimental_xml), but largely, the authors just don't want to go to the
effort of getting the code into Phobos.

And honestly, in general, at this point, I don't think that I'd want to
bother either. It's quite a lot of work to get something through the Phobos
review process, and once it's in Phobos, you lose control over it. If I work
on something major, I can just put it up on code.dlang.org, and anyone who
wants to use it can, and I have full control over what I do with the code
base without having to get approval from Andrei or anyone else as to what I
do with it. So, unless we're talking about something that practically needs
to be in the 

Re: Note from a donor

[Brad Roberts via Digitalmars-d]

On 10/26/17 5:23 AM, Steven Schveighoffer via Digitalmars-d wrote:

On 10/26/17 7:09 AM, Mike Parker wrote:
I also didn't like that I had to install the Xcode tools on my Mac, but that's needed for any 
development on Mac from what I can see.


Want to hear something scary? The autotester does not use xcode tools :)

In fact, I've been meaning to bug Brad about checking to see if things have improved (xcode's 
compiler used to generate a dmd that would fail some of the tests). I've never used gnu gcc, only 
ever Xcode's compiler (which is llvm).


-Steve


Actually, one of the 3 macos boxes is using stock xcode tooling these days.  I specifically went 
that direction when setting up a new system that replaced one that died on me (well, it boots but if 
I actually _use_ it it crashes, sigh).


So, but on the older osx releases (not positive the exact versions off the top of my head) there 
were issues that forced us back to an old gcc version rather than the default clang compiler.

Re: Note from a donor

[Jonathan M Davis via Digitalmars-d]

On Friday, October 27, 2017 02:00:53 evilrat via Digitalmars-d wrote:
> On Friday, 27 October 2017 at 01:40:07 UTC, Jonathan M Davis
>
> wrote:
> > On Friday, October 27, 2017 01:12:53 codephantom via
> >
> > Digitalmars-d wrote:
> >> VS is the most bloated piece of crap that's ever come out of
> >> Microsoft!
> >> Why encourage/force D developers to use it?
> >
> > The problem is that to reasonably interact with the rest of the
> > Windows C/C++ ecosystem, you're pretty much stuck using
> > Microsoft's linker. If we can get that without pulling in all
> > of VS, all the better, but without the linker, we can't link
> > with most existing C/C++ code, which is a big problem. Before
> > we could use MS' linker, we had complaints for years about not
> > being compatible with other C/C++ stuff on Windows.
> >
> > MS simply has not set things up in a way that makes it
> > reasonable to avoid VS if you want to link with C/C++ libraries
> > - especially since VS is all most C/C++ projects on Windows
> > target at this point.
> >
> > - Jonathan M Davis
>
> I'm not sure about WinSDK 10, but previous versions has all the
> libs and tools necessary(linker!) and is much smaller
> download(500 MB or so)
>
> IIRC the problem is that DMD installer won't pick up SDK install
> path, and most newcomers neither has the knowledge of sc.ini nor
> the desire to mess with it.

Well, if it's possible to use an SDK instead of VS, then ideally, we'd
support with the installer that rather than requiring that VS be there, but
obviously, someone will have to do the work to improve the installer.

Personally, I'm really not a Windows dev, though I've had to use Visual
Studio for work often enough, so my understanding of what other SDKs might
exist from Microsoft is quite poor. I've only ever used Windows for
development when I've had to.

- Jonathan M Davis

Re: D for microservices

[Adam Wilson via Digitalmars-d]

On 10/26/17 17:51, Jonathan M Davis wrote:

On Thursday, October 26, 2017 03:25:24 Adam Wilson via Digitalmars-d wrote:

On 10/25/17 23:57, Jacob Carlborg wrote:

I'm more concerned that I don't think we'll manage to implement a
complete API and 100% bug free at the first try.


Depends on how one defines first try. Phobos as a pretty solid process
for making sure these things are reasonably bug free. And near as I can
tell, Phobos is pretty good about accepting bug fixes.


The bigger problem is API bugs. The review process is rigorous enough to
weed out a lot of stuff, but the end result is typically an API that we
_think_ looks good but usually hasn't seen much real world use (much as its
design may be based on real world experience). And if it turns out that the
API has problems, it can be very difficult to fix that in a way that doesn't
break code. Sometimes, we're able to reasonably do something about it and
sometimes not. In theory, std.experimental would mitigate that, and that's
where anything that was accepted would go first, but the process for getting
new modules into Phobos is very much geared towards getting an API right up
front rather than getting something that's close and iterating towards where
it ultimately should be.

What would probably be better in general would be to be writing stuff that
ends up on code.dlang.org first and gets some real world use there and then
look at getting it into Phobos later rather than aiming directly for Phobos.
Not only would that likely help lead towards better code being in Phobos,
but we'd still get useful stuff even if it didn't make it into Phobos.

- Jonathan M Davis



I understand the concern, however, I can see potential mitigations. For 
one, steal an API concept from somewhere else. I've had reasonable 
success so far stealing ADO.NET and the refactoring it into something 
more idiomatic. Using that as a starting point gave me a pretty good 
understanding of what was needed and it gave me a prototype API that has 
been battle-tested.


Has anything from code.dlang.org been pulled into Phobos yet? I'm not 
aware of anything. code.dlang.org is where Phobos projects go to quietly 
die in obscurity.


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

Re: Note from a donor

[codephantom via Digitalmars-d]

On Thursday, 26 October 2017 at 20:44:49 UTC, Adam Wilson wrote:
The XCode installer DMG is 5GB, before unpacking. And unlike 
VS17, I can't pick and choose. :)


1 hour, 7 minutes later...

1:11pm
layout progres..45.43%

(2.55GB downloaded...so far)

I'll got get some lunch and come back to it...

Re: Note from a donor

[evilrat via Digitalmars-d]

On Friday, 27 October 2017 at 01:40:07 UTC, Jonathan M Davis 
wrote:
On Friday, October 27, 2017 01:12:53 codephantom via 
Digitalmars-d wrote:

VS is the most bloated piece of crap that's ever come out of
Microsoft!
Why encourage/force D developers to use it?


The problem is that to reasonably interact with the rest of the 
Windows C/C++ ecosystem, you're pretty much stuck using 
Microsoft's linker. If we can get that without pulling in all 
of VS, all the better, but without the linker, we can't link 
with most existing C/C++ code, which is a big problem. Before 
we could use MS' linker, we had complaints for years about not 
being compatible with other C/C++ stuff on Windows.


MS simply has not set things up in a way that makes it 
reasonable to avoid VS if you want to link with C/C++ libraries 
- especially since VS is all most C/C++ projects on Windows 
target at this point.


- Jonathan M Davis


I'm not sure about WinSDK 10, but previous versions has all the 
libs and tools necessary(linker!) and is much smaller 
download(500 MB or so)


IIRC the problem is that DMD installer won't pick up SDK install 
path, and most newcomers neither has the knowledge of sc.ini nor 
the desire to mess with it.

Re: Note from a donor

[codephantom via Digitalmars-d]

On Thursday, 26 October 2017 at 20:44:49 UTC, Adam Wilson wrote:
The XCode installer DMG is 5GB, before unpacking. And unlike 
VS17, I can't pick and choose. :)


45 minutes later...

12:49pm
layout progres..29%

Re: Note from a donor

[Jonathan M Davis via Digitalmars-d]

On Friday, October 27, 2017 01:12:53 codephantom via Digitalmars-d wrote:
> VS is the most bloated piece of crap that's ever come out of
> Microsoft!
> Why encourage/force D developers to use it?

The problem is that to reasonably interact with the rest of the Windows
C/C++ ecosystem, you're pretty much stuck using Microsoft's linker. If we
can get that without pulling in all of VS, all the better, but without the
linker, we can't link with most existing C/C++ code, which is a big problem.
Before we could use MS' linker, we had complaints for years about not being
compatible with other C/C++ stuff on Windows.

If we can make it work by using another linker and have it be compatible
with stuff generated by MS' compiler (e.g. if LLVM's linker could be used in
that case), then for many of us, that would definitely be superior to having
to deal with VS, but for the moment at least, using VS seems to be the only
real option if you want to interact with any existing C/C++ libraries or
build for 64-bit (since OPTLINK has never been updated for 64-bit).

Now, if you're just using your own code and/or loading dlls at runtime
and/or can reasonably build all C/C++ stuff you need with dmc _and_ you
don't need 64-bit on Windows, then there's no reason to pull in VS, and it's
nice that you don't need to. But for serious Windows projects, there's a
good chance that you're going to need MS' linker, much as that sucks, and MS
seems to want you to pull in VS to get it.

MS simply has not set things up in a way that makes it reasonable to avoid
VS if you want to link with C/C++ libraries - especially since VS is all
most C/C++ projects on Windows target at this point.

- Jonathan M Davis

Re: Note from a donor

[codephantom via Digitalmars-d]

On Thursday, 26 October 2017 at 20:44:49 UTC, Adam Wilson wrote:
The XCode installer DMG is 5GB, before unpacking. And unlike 
VS17, I can't pick and choose. :)


14 minutes later...

12:18pm
layout progres..8.16%

Re: Note from a donor

[codephantom via Digitalmars-d]

On Thursday, 26 October 2017 at 20:44:49 UTC, Adam Wilson wrote:
The XCode installer DMG is 5GB, before unpacking. And unlike 
VS17, I can't pick and choose. :)


(trying to install vs2017 build tools on Win7 sp1 .. )

vs_BuildTools.exe --layout c:\btoffline
(error: requires .NET framework 4.6 of higher!!)

(ok, download web installed for .NET 4.6...50MB or so, about 5 
minutes later)

(done...and installed)

(lets try again)
start: 12:04pm

vs_BuildTools.exe --layout c:\btoffline
..Give us a minute..we'll be done soon.. (yeah right!!)

total packages to download...1897

what the f##TG$!

12:08pm
layout progres..0.19%

forget it!

I'll go use FreeBSD instead.


pkg install ldc


done..ready.to.go..start coding!

VS is the most bloated piece of crap that's ever come out of 
Microsoft!

Why encourage/force D developers to use it?

You also need to update your certificates just to install the 
components, and a through other hoops you have to jump through as 
well

Re: D for microservices

[Jonathan M Davis via Digitalmars-d]

On Monday, October 23, 2017 12:13:12 Laeeth Isharc via Digitalmars-d wrote:
> How can we generate a static binary ?  I asked about this before,
> and the response was that it's a bad idea because of security
> vulns and so on.  True if you are running on a conventional Linux
> host.  But on the other hand, it's not that great if when the
> system phobos is upgraded all the D binaries break.  You can
> write a script using rdmd or dub scripting feature, but that
> doesn't work for more complex programs.

I believe that it works just fine if you do the linking step yourself, but
dmd doesn't properly handle it with -L-static:

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

I have no idea how easy it would be to the linking manually with dub.

Alternatively, I believe that you can statically link against any 3rd party
libraries that you're using by linking to the .a file rather than by the
library name. That won't work for glibc, but much as I'd love to statically
link that, it's my understanding that doing so is generally a bad idea. I
don't recall the reasons though - and with the increased stability in
linux's ABI, I would have thought that it would be far less of an issue than
it would have been in the past. Certainly, the concept of being able to
statically link a program and then just run it on most any recent linux
distro without recompiling it sounds very appealing. Yes, you'll have to
recompile it for any security updates to any of your dependencies, whereas
that can be avoided with dynamic linking, but depending on what you're
doing, that often isn't really an issue, and it can be managed if it is
(heck, you're doing basically the same thing when maintaining something like
a docker image).

- Jonathan M Davis

[Issue 2447] There's no disconnectall for std.signals

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

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/f0d2655d7535ae16fd681679d75b4c42014348c9
Fix issue 2447 - add disconnectAll for std.signals

https://github.com/dlang/phobos/commit/b5e6365a9bb9e0ca3af194d7add212c092ad1b13
Merge pull request #5812 from edi33416/signals_disconnectall

Fix issue 2447 - add disconnectAll for std.signals
merged-on-behalf-of: Andrei Alexandrescu 

--

[Issue 2447] There's no disconnectall for std.signals

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

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: D for microservices

[Jonathan M Davis via Digitalmars-d]

On Thursday, October 26, 2017 03:25:24 Adam Wilson via Digitalmars-d wrote:
> On 10/25/17 23:57, Jacob Carlborg wrote:
> > I'm more concerned that I don't think we'll manage to implement a
> > complete API and 100% bug free at the first try.
>
> Depends on how one defines first try. Phobos as a pretty solid process
> for making sure these things are reasonably bug free. And near as I can
> tell, Phobos is pretty good about accepting bug fixes.

The bigger problem is API bugs. The review process is rigorous enough to
weed out a lot of stuff, but the end result is typically an API that we
_think_ looks good but usually hasn't seen much real world use (much as its
design may be based on real world experience). And if it turns out that the
API has problems, it can be very difficult to fix that in a way that doesn't
break code. Sometimes, we're able to reasonably do something about it and
sometimes not. In theory, std.experimental would mitigate that, and that's
where anything that was accepted would go first, but the process for getting
new modules into Phobos is very much geared towards getting an API right up
front rather than getting something that's close and iterating towards where
it ultimately should be.

What would probably be better in general would be to be writing stuff that
ends up on code.dlang.org first and gets some real world use there and then
look at getting it into Phobos later rather than aiming directly for Phobos.
Not only would that likely help lead towards better code being in Phobos,
but we'd still get useful stuff even if it didn't make it into Phobos.

- Jonathan M Davis

Re: Required Reading: "How Non-Member Functions Improve Encapsulation"

[Jonathan M Davis via Digitalmars-d]

On Thursday, October 26, 2017 16:29:24 Walter Bright via Digitalmars-d 
wrote:
> On 10/26/2017 3:05 PM, Jonathan M Davis wrote:
> > As has been pointed out elsewhere in this thread, the encapsulation
> > benefits don't exist in the same way in D unless you put the free
> > functions in separate modules, and then you have to import other stuff
> > to use them, whereas in C++, you can just put the free functions next
> > to the type and still get the encapsulation benefits. So, the benefit
> > of splitting the functions out within a module is fairly minimal in D.
> > Rather, the main reason I see for splitting functions out is in order
> > to make them more generic, and I think that the push to do that in D
> > has a tendency to make a lot of functions free functions that might
> > have been member functions in most other languages.
>
> The point is that functions that do not need access to private fields
> should NOT be part of the class. Most of the discussion here is based on
> the idea that those functions should still be semantically part of the
> class, even if not physically. That idea should be revisited. Why should
> they be semantically part of the class?
>
>
> You can also do things like:
>
> --- s.d ---
> struct S { int x; ref int X() { return x; } }
>
> --- splus.d 
> public import s;
> int increment(S s) { s.X() += 1; } // note no access to S.x
>
> --- user.d 
> import splus;
> void foo(ref S s) { s.increment(); }

I agree that it's a good rule of thumb to aim for member functions to be the
set of functions that require access to private members, but I've never felt
that it's useful to be pedantic about it (particularly in D, where you don't
even get encapsulation if they're in the same module). When I write a struct
or class, it's generally designed with a set of operations that conceptually
go with it, and I don't see whether they need to access to private members
as being all that relevant to that. Functions which aren't really
conceptually part of the class or struct certainly should be separate, but
for me at least, it's about the API and what it's conceptually trying to do,
and what the type is trying to be and represent - what its abstraction is.
And in some cases, separating a function from a type just because it doesn't
happen to use any private members then feels like an artificial separation.

On some level, I think that it comes down to a question of what operations
are part of the abstraction and what operations are just using the
abstraction, if it's part of the abstraction, IMHO, it just makes more sense
for it to be a member function regardless of whether it accesses private
members.

Obviously, that's subjective, and there's then disagreement at least some of
the time on what should and shouldn't be a member function, but I don't
think that it's necessarily the case that having everything that doesn't
need access to private members as free functions leads to the abstraction
that a struct or class presents being very clean.

And once you get into classes and inheritance, breaking things up based on
what needs access to private members definitely falls apart in a number of
circumstances, because then you're very clearly abstracting behaviors (which
can then be overidden) as opposed to simply encapsulating data and operating
on it like some structs do. I just tend to think of types in general that
way, not just those involving interfaces and inheritance.

If you're coming at the type from the standpoint that everything that is
conceptually part of the type is actually part of the type, and everything
else is separate, then on some level, that will follow the idea that
functions that access private members are member functions and those that
don't aren't, but at least some of the time, it won't. And in that case, I'm
generally going to make it a member function.

I think that the problem is when folks just add functions to a type when
they don't need to be member functions to do what they do and really aren't
conceptually part of the type. They're just put on there because it's easy
or because that's what folks are used to having to do in languages like Java
or because it works better with auto-completion (which honestly, I think is
one area where IDEs make things worse; having auto-completion is fine, but
writing code in a certain way because of auto-completion is an anti-pattern
IMHO). Every time that a programmer is adding a function, they really should
be considering whether it really should be a member function or whether it
makes more sense for it to be a free function.

So, I think that the advice that member functions should generally be the
set of functions that need access to private members is good think to about
and something that programmers should keep in mind, but I also don't think
that that's really the best dividing line in general as to what should and
shouldn't be a member function. And thanks to how access levels work in D,
it's even less useful as 

[Issue 5332] Undefined reference to zero length array

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

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

--- Comment #12 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/239c35233e62f289e6e868b7d4eafdcd63c72ea4
fix Issue 5332 - Undefined reference to zero length array

https://github.com/dlang/dmd/commit/ff4bdb660e6ed2ab1eb6c8725bd673417ef21a41
Merge pull request #7249 from WalterBright/fix5332

fix Issue 5332 - Undefined reference to zero length array

--

Re: Required Reading: "How Non-Member Functions Improve Encapsulation"

[Walter Bright via Digitalmars-d]

On 10/26/2017 3:05 PM, Jonathan M Davis wrote:

As has been pointed out elsewhere in this thread, the encapsulation benefits
don't exist in the same way in D unless you put the free functions in
separate modules, and then you have to import other stuff to use them,
whereas in C++, you can just put the free functions next to the type and
still get the encapsulation benefits. So, the benefit of splitting the
functions out within a module is fairly minimal in D. Rather, the main
reason I see for splitting functions out is in order to make them more
generic, and I think that the push to do that in D has a tendency to make a
lot of functions free functions that might have been member functions in
most other languages.


The point is that functions that do not need access to private fields should NOT 
be part of the class. Most of the discussion here is based on the idea that 
those functions should still be semantically part of the class, even if not 
physically. That idea should be revisited. Why should they be semantically part 
of the class?



You can also do things like:

--- s.d ---
struct S { int x; ref int X() { return x; } }

--- splus.d 
public import s;
int increment(S s) { s.X() += 1; } // note no access to S.x

--- user.d 
import splus;
void foo(ref S s) { s.increment(); }

Re: Adding syntacti sugar for simple "readonly" attribute ?

[bauss via Digitalmars-d]

On Thursday, 26 October 2017 at 21:19:28 UTC, LunaticWare wrote:
Hello everyone i am new to the D community and i really enjoy 
programming in D,
i haven't done anything significant so far. but being a very 
lazy person,
when writing a bit of code i noticed that maybe for such a 
simple

thing we could have a shorter syntax.
i don't know if this is the correct way to suggest enhancement 
to D,

and i am sorry if this is already in the language.
so maybe we could add syntactic sugar for "readonly" attributes.
here is simple example, where the following code

---

class Foo
{
@readonly int bar = 12; // or maybe "@directread" ?

this(string baz)
{
this.bar = baz;
}
}

---

would be the same as

---

class Foo
{
private string bar_;

this(string baz)
{
this.bar_ = baz;
}

@property string bar()
{
return this.bar_;
}
}


The first example would not equal the second, because you could 
set bar from anywhere within the module.


Immutable will already do your behavior.

class Foo
{
immutable string bar;

this(string baz)
{
bar = baz;
}
}

...
auto foo = new Foo("hello");

foo.bar ~= " World!"; // Error.

string bar = foo.bar; // Okay.

bar ~= " World!"; // Okay, because "bar" is not immutable, nor is 
it referring to foo.bar.

Re: Empty UDA for classes not allowed?

[bauss via Digitalmars-d-learn]

On Thursday, 26 October 2017 at 21:24:43 UTC, Jonathan M Davis 
wrote:
On Thursday, October 26, 2017 15:09:48 bauss via 
Digitalmars-d-learn wrote:

[...]


It worked just fine when I just tried it on my machine - both 
with dmd master and with 2.076.1. Are you using an older 
version of the compiler than 2.076.1? It's possible that there 
was a bug that was fixed.


- Jonathan M Davis


Yeah I can't reproduce it right now, so I'm not even sure.

Re: Adding syntacti sugar for simple "readonly" attribute ?

[Ali Çehreli via Digitalmars-d]

On 10/26/2017 02:19 PM, LunaticWare wrote:

> i don't know if this is the correct way to suggest enhancement to D,

Improvement proposals are handled through DIPs here:

  https://github.com/dlang/DIPs

> so maybe we could add syntactic sugar for "readonly" attributes.

There is the following project that comes close:

  http://forum.dlang.org/thread/zdcrkrktfsmvghmid...@forum.dlang.org

class WithAccessors
{
@Read @Write
private int num_;

mixin(GenerateFieldAccessors);
}

Ali

Re: Adding syntacti sugar for simple "readonly" attribute ?

[jmh530 via Digitalmars-d]

On Thursday, 26 October 2017 at 21:19:28 UTC, LunaticWare wrote:

[snip]


You can use string mixins.

template GenGetterSetter(string Type, string Name)
{
const char[] GenGetterSetter = "private " ~ Type ~ " " ~ 
Name ~ "_;\n" ~

   "this(" ~ Type ~ " x)\n" ~
   "{\n" ~
   "" ~ Name ~ "_ = x;\n" 
~

   "}\n" ~
   "@property " ~ Type ~ " " 
~ Name ~ "()\n" ~

   "{\n" ~
   "return " ~ Name ~ 
"_;\n" ~

   "}";
}

class Foo
{
mixin(GenGetterSetter!("string", "bar"));
}

void main()
{
import std.stdio : writeln;
Foo foo = new Foo("bar");
writeln(foo.bar);
}

Re: Required Reading: "How Non-Member Functions Improve Encapsulation"

[Jonathan M Davis via Digitalmars-d]

On Thursday, October 26, 2017 12:53:38 JN via Digitalmars-d wrote:
> On Wednesday, 25 October 2017 at 22:19:23 UTC, Walter Bright
>
> wrote:
> > for core D devs.
> >
> > "How Non-Member Functions Improve Encapsulation" by Scott Meyers
> >
> > http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/1844
> > 01197
> >
> > Note that I'm as guilty as anyone for not understanding or
> > following these guidelines. I expect we can do much better.
>
> As a counterpoint. I guess UFCS makes it less of a problem, but
> it's nice when using an IDE to just type foo. , press ctrl-space
> and see a nice list of methods that can be used with the class.
> When having free functions, you don't get to enjoy that :)

At a previous job, we had our own string class which wrapped std::string
just because some of the developers wanted our extra string functions on the
type where they would be easy to find (even just for documentation
purposes). They were of the opinion that once you separate the functions
from the class, your project will ultimately end up with multiple header
files of functions doing similar things, because at least some of the time,
developers wouldn't know about the existing functions and would add their
own own. And with sufficiently large projects, that does seem to happen all
too often. I still don't agree with the idea that putting stuff on the class
is better just because it makes stuff easier to find, but I can see why
someone would think that.

As has been pointed out elsewhere in this thread, the encapsulation benefits
don't exist in the same way in D unless you put the free functions in
separate modules, and then you have to import other stuff to use them,
whereas in C++, you can just put the free functions next to the type and
still get the encapsulation benefits. So, the benefit of splitting the
functions out within a module is fairly minimal in D. Rather, the main
reason I see for splitting functions out is in order to make them more
generic, and I think that the push to do that in D has a tendency to make a
lot of functions free functions that might have been member functions in
most other languages.

And in D, there's the issue that declaring a function to be used with UFCS
instead of as a member function can be a bit of a pain when the type is
templated. You have to repeat a bunch of stuff that's just part of the
templated struct or class. You end up with additional templates and template
constraints (much of which is duplicated) just to separate the functions
from the type.

That being said, the time that I'm most likely to turn a member function
into a free function when the function isn't going to be made generic is
when the type is templated simply because then I can put the unittest block
right next to the function without having it be part of the template (since
that's almost always the wrong thing to do if you don't do some boilerplate
with static ifs to make it so that they're only compiled into a single
instantiation that's intended just for testing).

Overall, I think that the idea that functions should be free functions where
reasonable is good advice, but it needs to be taken with a grain of salt.

- Jonathan M Davis

Re: Note from a donor

[jmh530 via Digitalmars-d]

On Thursday, 26 October 2017 at 17:10:55 UTC, Mike Parker wrote:



The Visual C++ install is all that it's needed. I'll update the 
wiki tomorrow after I verify the options on my desktop.




You know that wiki is pretty informative, but I don't see a 
reference or link to it anywhere here

https://dlang.org/download.html
When you click on more information, it takes you to more 
information about the compilers and then you have to click on DMD 
and then there's a link to Installing DMD. Might make sense (by 
that I mean, fewer clicks) to be able to have a single 
Installation instructions page for each and have a link to them 
near the downloads.

Re: Note from a donor

[jmh530 via Digitalmars-d]

On Thursday, 26 October 2017 at 20:24:53 UTC, Patrick Schluter 
wrote:
[snip] That installer doesn't work  with the proxy installation 
we have on our work PC.


This is usually the bane of my corporate existence. I have to 
manually install so much stuff. Anaconda and RStudio's package 
managers don't work. Dub fetch doesn't work on my work machine. 
But for whatever reason, I've never had a problem with the Visual 
Studio installer.


The other difficulty, installing Visual Studio when the system 
partition is small is also nearly impossible.


My old home setup was a very small SSD to install Windows and 
then a bigger 3.5" data drive. I had to get a bigger operating 
system drive (NVME is pretty cool) when I started using Visual 
Studio more.

[Issue 17942] Enums are evaluated differently in global scope

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

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
Reduced:


alias AliasSeq(TList...) = TList;
enum B = AliasSeq!(); // fails
void main()
{
enum A = AliasSeq!(); //works
}


--

[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings

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

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

--- Comment #6 from Steven Schveighoffer  ---
(In reply to briancschott from comment #5)
> That's not entirely accurate. I found this because the range implementation
> for a complex multi-dimensional tree structure was implemented as a
> std.concurrency.Generator.

Right, the issue here is not so much that you need a certain number of
concurrent fibers, it's that the limited resource (64K items per process) is
tied to memory management (essentially infinite number of items per process,
and no requirement to release).

It's the same argument as to why File is ref-counted with malloc and not a
class.

So toy examples may fail, large concurrent webservers may fail (but arguably,
those can be tuned to work), OR reasonable innocuous code may fail if it falls
into the right trap using GC-managed data.

Worth noting that simply turning off GC collections can trigger this error.

A heavy-handed solution might be that if there is a limit on Fiber creation,
then you should have an object to manage them. But that would be a drastic
design change.

Another possibility is that we make a type-change to track the "good" behavior
and the "bad" behavior separately. For example, SafeFiber, which does the guard
page. Then at least it's opt-in.

(In reply to Martin Nowak from comment #4)
> Why isn't the number of guard pages a problem on Windows? That kernel also
> needs to keep track of lots of memory regions.

The limit is 64k *per process*, so obviously, the kernel can handle quite a bit
more.

Worth noting that Windows has a much different memory layout than Unix.

> If we really need a comprise here, I'd definitely increase the stack size
> further, e.g. to 64KiB (vibe.d's default).

That's also a possible option. We could do that along with the reversal of the
guard page.

--

Re: Note from a donor

[MrSmith via Digitalmars-d]

On Thursday, 26 October 2017 at 17:02:40 UTC, Mike Parker wrote:
That's exactly the kind of developer background I'm thinking 
of. Getting permission to redistribute from MS would be the 
ideal solution. If not, I'm sure someone will find a way to 
make it work with the LLVM or MinGW tools eventually.


Would it be possible to create import libs that for all 
winapi/crt libs, and redistribute them? Will such libs be legal 
to redist?
We have the tools (DMD/LLD), but the dependency on winsdk and VS 
libs is still there, unfortunatelly.

Re: Empty UDA for classes not allowed?

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, October 26, 2017 15:09:48 bauss via Digitalmars-d-learn wrote:
> Why is it not allowed to have empty UDAs for classes?
>
> Let's say we have an UDA like this:
> struct Exclude { }
>
> Then we want to put it on a class like:
>
> @Exclude class Foo
> {
>  ...
> }
>
> This will fail with the following error:
> Error: type Exclude has no value
>
> But on everything else we can place an empty UDA like that ex. on
> a function:
>
> This is okay:
>
> @Exclude void foo()
> {
>  ...
> }
>
> Can someone explain to me why it's not possible with classes?

It worked just fine when I just tried it on my machine - both with dmd
master and with 2.076.1. Are you using an older version of the compiler than
2.076.1? It's possible that there was a bug that was fixed.

- Jonathan M Davis

Adding syntacti sugar for simple "readonly" attribute ?

[LunaticWare via Digitalmars-d]

Hello everyone i am new to the D community and i really enjoy 
programming in D,
i haven't done anything significant so far. but being a very lazy 
person,

when writing a bit of code i noticed that maybe for such a simple
thing we could have a shorter syntax.
i don't know if this is the correct way to suggest enhancement to 
D,

and i am sorry if this is already in the language.
so maybe we could add syntactic sugar for "readonly" attributes.
here is simple example, where the following code

---

class Foo
{
@readonly int bar = 12; // or maybe "@directread" ?

this(string baz)
{
this.bar = baz;
}
}

---

would be the same as

---

class Foo
{
private string bar_;

this(string baz)
{
this.bar_ = baz;
}

@property string bar()
{
return this.bar_;
}
}

Re: DateTime trying to do it at compile time.

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, October 26, 2017 17:55:05 Mr. Jonse via Digitalmars-d-learn 
wrote:
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\concurrency.d(2395):
> Error: variable lock cannot be modified at compile time
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\concurrency.d(2422):
>   called from here: initOnceLock()
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\concurrency.d(2422):
>   called from here: initOnce(delegate shared(bool)() =>
> init(), initOnceLock())
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\datetime\timezone.d(1128):
>   called from here: initOnce(delegate shared(bool)() => (*function () =>
> true)())
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\datetime\timezone.d(583):
>   called from here: (*& singleton)()
> C:\D\dmd2\windows\bin\..\..\src\phobos\std\datetime\systime.d(64):
> called from here: opCall()
>
> when calling Clock.currTime() in a this() in a class. I have no
> idea why it is trying to do it at compile time and failing. I
> thought if ctfe couldn't compile it would do it at run time
> anyways? Seems like a bug.

It's very black and white with CTFE. The compiler never does CTFE unless it
has to (e.g. you're initializing a enum, or you're directly initializing a
static variable or member variable). So, it's not going to do CTFE as an
optimization anywhere (though a number of folks mistakenly think that it
will). And if it does CTFE, then CTFE must succeed. The compiler is never
going to decide that something failed at CTFE, so it will just do it at
runtime instead. It's doing CTFE, because it requires a result that must be
known at compile time.

So, clearly, the class that calls Clock.currTime in its constructor is being
constructed at compile time, which isn't going to work, because
Clock.currTime accesses the system's C API to get the time (and you almost
certainly wouldn't want the time the code was compiled anyway). I'd guess
that Rene's suggestion is correct and that you're directly initializing a
member variable somewhere that's of this class type. It's either that or
you're directly initializing a module-level variable, a static variable, or
an enum of that class type - _or_ you're doing something else at CTFE that
ultimately calls a function that is constructing an instance of one of these
classes.

Ultimately, you either need to not be constructing an instance of this class
at compile time, or you need to make it so that it will work at compile time
without getting the current time (or doing anything else that can't be done
at compile time).

if(__ctfe)
{}

can be used to create branches that do something different during CTFE so
that they can function during CTFE even though they would normally do
something that wouldn't work during CTFE (e.g. if you have an algorithm that
uses pointer arithmetic for performance, you could provide an alternate
implementation for compile time that was slower, because it didn't use
pointer arithmetic, but at least it would then work at compile time).

I'd guess though that in this case, you're simply directly initializing a
variable whose value must be known at compile time, in which case, the
solution would likely be to not directly initialize it.

- Jonathan M Davis

[Issue 17541] Function attribute deduction depends on compile invocation

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

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

johanenge...@weka.io changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from johanenge...@weka.io ---
reopening, because it is not fixed for safe/trusted, nor for impure/pure,
throw/nothrow.

--

Re: Note from a donor

[Adam Wilson via Digitalmars-d]

On 10/26/17 08:51, Bo wrote:

On Thursday, 26 October 2017 at 12:36:40 UTC, jmh530 wrote:

However, if you need Visual Studio installed, then that takes like a
half an hour.


And a gig of space, just because D needs a small part of it. That is why
people do not want to install VS. Why install a competing language
studio, when you are installing D.


The XCode installer DMG is 5GB, before unpacking. And unlike VS17, I 
can't pick and choose. :)


--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;

[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings

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

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

--- Comment #5 from briancsch...@gmail.com ---
> The problem is, this either break toy code that just
> creates lots of useless Fibers or heavy production code
> that actually needs 30K Fibers.

That's not entirely accurate. I found this because the range implementation for
a complex multi-dimensional tree structure was implemented as a
std.concurrency.Generator. The problem is caused by doing many tree traversals
in a loop on a machine that has 512GB of memory. We don't actually need 30k
fibers. We need one fiber at a time 30k times in a row. By the time we start
using the second fiber we don't need the first one anymore.

It's possible to re-implement the range in question, but the amount of code
required to do so is much greater than the current implementation using
recursion and fibers.

--

Re: Note from a donor

[Patrick Schluter via Digitalmars-d]

On Thursday, 26 October 2017 at 12:36:40 UTC, jmh530 wrote:
On Thursday, 26 October 2017 at 11:32:26 UTC, Andrei 
Alexandrescu wrote:


A wizard-style installation with links to things and a good 
flow might help a lot here. Is that possible? -- Andrei


The DMD installer is already a Wizard on Windows.

First it checks if you have a current version of D and will 
uninstall that, then it checks if you want to install D2 along 
with some extras (Visual D, DMC, D1), and it goes through 
additional steps to install the extras if you select them.


However, if you need Visual Studio installed, then that takes 
like a half an hour. My recollection is that it's a little 
tricky if you upgrade to a new version of VS. I usually just 
uninstall D and reinstall it rather than deal with that.


There are other issues with the Visual Studio install that D is 
not responsible for but is annoying as hell. It's Microsofts 
fault but the result is that D installation is made difficult. To 
install VS, it downloads first the installer which will then 
download and install the software. That installer doesn't work  
with the proxy installation we have on our work PC. The only way 
is to find the offline install package. I know they exist but 
finding them on the mess that is Microsoft's website is nearly 
impossible.
The other difficulty, installing Visual Studio when the system 
partition is small is also nearly impossible.

As I said, not the fault of D but annoying in any case.
This said, building apps purely 32 bit on Windows has the 
advantage of allowing  compatibility with legacy systems still 
running on XP. There are still some of them still around.

[Issue 11847] sub-pkg not available as qualified name

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

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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #13 from Martin Nowak  ---
https://github.com/dlang/dmd/pull/7218

--

Re: Adding pure to a function type

[jmh530 via Digitalmars-d]

On Thursday, 26 October 2017 at 19:08:56 UTC, Andrei Alexandrescu 
wrote:


One additional thing I noted is that I wanted to add 
attributes, not set them. I'd like some simpler primitives like 
AddPure, RemovePure etc. BTW the PR is 
https://github.com/dlang/phobos/pull/5470. -- Andrei


My above code could be easily adapted for adding attributes in 
the general case. The doc unittest for SetFunctionAttributes has 
an assumePure that shows how to add an attribute (though I'm not 
sure on removing).


While I think that it makes sense to add an 
AddFunctionAttributes/RemoveFunctionAttributes that match the 
functionality of SetFunctionAttributes, it's probably more 
convenient to also add an overload with a string template 
parameter, so AddPure!T would just be AddFunctionAttributes!(T, 
"pure") instead of AddFunctionAttributes!(T, 
FunctionAttribute.pure_).

[Issue 5332] Undefined reference to zero length array

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

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

--- Comment #11 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7249

--

[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings

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

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

--- Comment #4 from Martin Nowak  ---
(In reply to Steven Schveighoffer from comment #3)
> > I'd err on the side of memory safety. Stack overflows are an actual problem
> > with Fibers and hard to debug.
> 
> Except this breaks existing code that may not have a stack overflow problem.
> I hate to say it, but unfortunately, we are stuck with the status quo for
> now.

The problem is, this either break toy code that just creates lots of useless
Fibers or heavy production code that actually needs 30K Fibers.

For the latter it's reasonable to ask for manual tuning of either the kernel or
the Fiber stack size.
For the former it's fairly hard to justify that the default has such a severe
memory and safety hole.

Why isn't the number of guard pages a problem on Windows? That kernel also
needs to keep track of lots of memory regions.

If we really need a comprise here, I'd definitely increase the stack size
further, e.g. to 64KiB (vibe.d's default).

--

Re: Adding pure to a function type

[Andrei Alexandrescu via Digitalmars-d]

On 10/26/2017 12:14 PM, jmh530 wrote:

On Thursday, 26 October 2017 at 16:06:28 UTC, jmh530 wrote:

On Thursday, 26 October 2017 at 15:47:03 UTC, Andrei Alexandrescu wrote:


s/less hideous/even more awesome/

No need to be testy :o).

I noticed there's no way to say "just leave linkage as is". I tried 
SetFunctionAttributes!(typeof(), null, FunctionAttribute.pure_) 
and SetFunctionAttributes!(typeof(), "", 
FunctionAttribute.pure_) but neither worked. Should I file a bug?



Andrei


How about:

SetFunctionAttributes!(typeof(), functionLinkage!(), 
FunctionAttribute.pure_)


Or we can just add in additional overloads like:

template SetFunctionAttributes(T, uint attrs)
     if (isFunctionPointer!T || isDelegate!T)
{
     alias SetFunctionAttributes = 
FunctionTypeOf!(SetFunctionAttributes!(T, functionLinkage!T, attrs));

}

template SetFunctionAttributes(T, uint attrs)
     if (is(T == function))
{
     alias SetFunctionAttributes = 
FunctionTypeOf!(SetFunctionAttributes!(T*, attrs));

}

template SetFunctionAttributes(T, string linkage)
     if (isFunctionPointer!T || isDelegate!T)
{
     alias SetFunctionAttributes = 
FunctionTypeOf!(SetFunctionAttributes!(T, linkage, functionAttributes!T));

}

template SetFunctionAttributes(T, string linkage)
     if (is(T == function))
{
     alias SetFunctionAttributes = 
FunctionTypeOf!(SetFunctionAttributes!(T*, linkage));

}


One additional thing I noted is that I wanted to add attributes, not set 
them. I'd like some simpler primitives like AddPure, RemovePure etc. BTW 
the PR is https://github.com/dlang/phobos/pull/5470. -- Andrei

Re: DateTime trying to do it at compile time.

[Rene Zwanenburg via Digitalmars-d-learn]

On Thursday, 26 October 2017 at 17:55:05 UTC, Mr. Jonse wrote:
when calling Clock.currTime() in a this() in a class. I have no 
idea why it is trying to do it at compile time and failing. I 
thought if ctfe couldn't compile it would do it at run time 
anyways? Seems like a bug.


I suspect you're trying to instantiate your class in a static 
context, which causes it to be constructed at compile time. For 
example:



class A
{
  this() {
// Do sth. with datetime
  }
}

class B
{
  // This will construct A at compile time. This also
  // means a single A instance is shared between all
  // B instances. This is different from most langs!
  A a = new A;
}

// This will also construct at compile time.
A moduleScopedA = new A;


The solution is to new A in your class or module constructor.

Re: DMD, Windows and C

[Rainer Schuetze via Digitalmars-d-announce]

On 25.10.2017 18:57, kinke wrote:

On Wednesday, 25 October 2017 at 16:05:48 UTC, Mike Parker wrote:
In preparation for an upcoming blog series, and partly as a reaction 
to the "Windows is a second-class citizen" criticisms that have been 
cropping up lately, I've put together a primer on getting set up to 
use C and D together on Windows. It includes some background on why we 
need to install the MS toolchain to produce 64-bit binaries.


The blog:
https://dlang.org/blog/2017/10/25/dmd-windows-and-c/

Reddit:
https://www.reddit.com/r/programming/comments/78olka/dmd_windows_and_c_getting_set_up_to_use_d_and_c/ 



LLVM's LLD is another option for linking on Windows (and cross-linking 
to Windows from other platforms); they used not to support debuginfos 
(.pdb), not sure what the current state is. `lld-link.exe` and 
`llvm-lib.exe` work as drop-in replacements,
I tried lld-link just yesterday on a small DMD generated test file. 
Apart from not supporting the /MAP option it worked without debug 
information, but choked on debug symbols.

Re: DMD, Windows and C

[Rainer Schuetze via Digitalmars-d-announce]

On 25.10.2017 18:05, Mike Parker wrote:
In preparation for an upcoming blog series, and partly as a reaction to 
the "Windows is a second-class citizen" criticisms that have been 
cropping up lately, I've put together a primer on getting set up to use 
C and D together on Windows. It includes some background on why we need 
to install the MS toolchain to produce 64-bit binaries.


The blog:
https://dlang.org/blog/2017/10/25/dmd-windows-and-c/

Reddit:
https://www.reddit.com/r/programming/comments/78olka/dmd_windows_and_c_getting_set_up_to_use_d_and_c/ 



Thanks for the nice article. Two minor remarks:

- the D installer already creates batch files dmd2vars32.bat and 
dmd2vars64.bat that modify the PATH environment variable (but don't 
include the DMC path)


- DMD doesn't need lib.exe to build static libraries, that's built into DMD.

DateTime trying to do it at compile time.

[Mr. Jonse via Digitalmars-d-learn]

C:\D\dmd2\windows\bin\..\..\src\phobos\std\concurrency.d(2395): 
Error: variable lock cannot be modified at compile time
C:\D\dmd2\windows\bin\..\..\src\phobos\std\concurrency.d(2422):   
 called from here: initOnceLock()
C:\D\dmd2\windows\bin\..\..\src\phobos\std\concurrency.d(2422):   
 called from here: initOnce(delegate shared(bool)() => 
init(), initOnceLock())

C:\D\dmd2\windows\bin\..\..\src\phobos\std\datetime\timezone.d(1128):called 
from here: initOnce(delegate shared(bool)() => (*function () => true)())
C:\D\dmd2\windows\bin\..\..\src\phobos\std\datetime\timezone.d(583):called 
from here: (*& singleton)()
C:\D\dmd2\windows\bin\..\..\src\phobos\std\datetime\systime.d(64):
called from here: opCall()

when calling Clock.currTime() in a this() in a class. I have no 
idea why it is trying to do it at compile time and failing. I 
thought if ctfe couldn't compile it would do it at run time 
anyways? Seems like a bug.

[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #3 from Steven Schveighoffer  ---
(In reply to Martin Nowak from comment #2)
> What's actually causing the limit is the fact that the kernel can no longer
> merge the mappings, hence the limit gets reached much quicker.

This would explain why the limit wasn't being reached before the change!

> I'd err on the side of memory safety. Stack overflows are an actual problem
> with Fibers and hard to debug.

Except this breaks existing code that may not have a stack overflow problem. I
hate to say it, but unfortunately, we are stuck with the status quo for now.

> Any better idea to detect/prevent stack overflows?

A possible idea is putting a pattern in the guard data (leave it read/write),
and check the guard data on fiber deallocation, and optionally on every yield
(could be a performance issue, but maybe only used in debug mode?)

You can also check the current SP on yield to make sure it's in-bounds (cheap
but doesn't cover everything).

Another option is to put a read-only guard page on only some of the fibers. If
you are allocating a lot of similar fibers, you are bound to hit one
eventually.

Still another option is to allocate the guard page on as many fibers as you
can, and then back off when you can't. This could be difficult, however, as the
relationship between mmap'd regions and the number of fibers may not be linear.

None of this prevents 100% of corruption, but they are better than nothing.

--

[Issue 17914] [Reg 2.075] Fibers guard page uses a lot more memory mappings

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

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu
Summary|Accidental per-process  |[Reg 2.075] Fibers guard
   |limit of fiber uses |page uses a lot more memory
   ||mappings

--- Comment #2 from Martin Nowak  ---
Here is what I'm seeing, calling mprotect splits the mapped range into 2, a 16K
rw--- and a 4K - mapping.
Calling GC.collect finalizes all unreachable Fibers and unmaps *both* regions
with a single `munmap(p, 20K)` call, so we don't really leak anything here.

What's actually causing the limit is the fact that the kernel can no longer
merge the mappings, hence the limit gets reached much quicker.


foreach (i; 0 .. 32 * 1_024) { new Fiber(function{}, 4 * 4096, 0); }

7f63304e9000 123184K rw---   [ anon ]

vs.

foreach (i; 0 .. 32 * 1_024) { new Fiber(function{}, 3 * 4096, 4096); }

7f2819cbf000 12K rw---   [ anon ]
7f2819cc2000  4K -   [ anon ]
7f2819cc3000 12K rw---   [ anon ]
7f2819cc6000  4K -   [ anon ]
7f2819cc7000 12K rw---   [ anon ]
7f2819cca000  4K -   [ anon ]
7f2819ccb000 12K rw---   [ anon ]
7f2819cce000  4K -   [ anon ]
7f2819ccf000 12K rw---   [ anon ]
7f2819cd2000  4K -   [ anon ]
7f2819cd3000 12K rw---   [ anon ]
7f2819cd6000  4K -   [ anon ]

I'd err on the side of memory safety. Stack overflows are an actual problem
with Fibers and hard to debug.
For using 32K+ Fibers it doesn't seem too reasonable to use custom stack and
guard sizes, e.g. a fairly big default stack size without guard page would
prevent most issues.

Any better idea to detect/prevent stack overflows?

--

Re: Note from a donor

[Mike Parker via Digitalmars-d]

On Thursday, 26 October 2017 at 16:34:54 UTC, jmh530 wrote:


One little trick in the wiki is that it says that you can 
uncheck boxes to reduce the size/time of the download. It might 
be helpful to know the minimum required to get D working and 
the minimum required to get Visual D working.


The Visual C++ install is all that it's needed. I'll update the 
wiki tomorrow after I verify the options on my desktop.




It also lists an alternative to install the Microsoft build 
tools and an appropriate version of the Windows SDK. LDC also 
refers to the Visual C++ build tools, but does not reference 
the SDK. I think the VS build tools replace the Visual C++ 
tools. The VS build tools look like they have an option to 
install the SDK and other stuff too.


I have the 2015 tools via the VS 2017 installer (it's an option), 
but I can't recall ever running the build tools installer 
directly. If anyone can verify and update the wiki, that would be 
great.

Re: Note from a donor

[Mike Parker via Digitalmars-d]

On Thursday, 26 October 2017 at 16:27:13 UTC, Andre Pany wrote:
On Thursday, 26 October 2017 at 15:50:07 UTC, Andrei 
Alexandrescu wrote:

On 10/26/2017 08:36 AM, jmh530 wrote:

[...]


I am preparing a request for Microsoft to allow us to 
redistribute some of their binaries. Of course we want to do 
that only if deemed necessary (they are not available easily 
from their site etc). Any help building an exact list of 
requisites would be great. Thanks! -- Andrei


Thanks a lot Andrei. At my working environment I advertise the 
use of DLang. Major competitors are python, nodejs, java and 
go. Everything which makes the installation and use of DLang 
more easy makes it easier to advertise D.


That's exactly the kind of developer background I'm thinking of. 
Getting permission to redistribute from MS would be the ideal 
solution. If not, I'm sure someone will find a way to make it 
work with the LLVM or MinGW tools eventually.

Re: Note from a donor

[Mike Parker via Digitalmars-d]

On Thursday, 26 October 2017 at 11:32:26 UTC, Andrei Alexandrescu 
wrote:


A wizard-style installation with links to things and a good 
flow might help a lot here. Is that possible? -- Andrei


The installer currently offers to install VS 2013. A more recent 
version might be better for some people, but I don't think it 
would have done anything for me. Just the idea that it's 
necessary would be a turn off. These days especially I'm less 
inclined to try new things if the slightest hurdle is presented 
simply because I put a higher premium on my time than I used to.


More broadly, I think in 2017 it's still true that serious 
Windows developers/shops will have VS installed, but there's no 
guarantee that anyone developing on Windows is a "Windows 
developer". With the myriad languages and VMs to choose from, 
they're don't even have to be aware that VS exists. Anything that 
hides the dependency from them in a way the minimizes the install 
would be a win.

Re: Note from a donor

[jmh530 via Digitalmars-d]

On Thursday, 26 October 2017 at 15:50:07 UTC, Andrei Alexandrescu 
wrote:


I am preparing a request for Microsoft to allow us to 
redistribute some of their binaries. Of course we want to do 
that only if deemed necessary (they are not available easily 
from their site etc). Any help building an exact list of 
requisites would be great. Thanks! -- Andrei


Cool.

From the Installing DMD wiki 
(https://wiki.dlang.org/Installing_DMD), it recommends the VS 
2015 Community for Windows 7/8 or VS 2017 Community for Windows 
10 users. I have Visual Studio Community 2017 installed, 
available from one of the links here:

https://www.visualstudio.com/downloads/

One little trick in the wiki is that it says that you can uncheck 
boxes to reduce the size/time of the download. It might be 
helpful to know the minimum required to get D working and the 
minimum required to get Visual D working.


It also lists an alternative to install the Microsoft build tools 
and an appropriate version of the Windows SDK. LDC also refers to 
the Visual C++ build tools, but does not reference the SDK. I 
think the VS build tools replace the Visual C++ tools. The VS 
build tools look like they have an option to install the SDK and 
other stuff too.

[Issue 17942] New: Enums are evaluated differently in global scope

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

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

  Issue ID: 17942
   Summary: Enums are evaluated differently in global scope
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: temta...@gmail.com

import std.meta;


enum B = aliasSeqOf!(gen()); // fails

void main()
{
enum A = aliasSeqOf!(gen()); //works
}

string[] gen()
{
return null; // change to [ `` ] makes error go away
}

--

Re: Note from a donor

[Andre Pany via Digitalmars-d]

On Thursday, 26 October 2017 at 15:50:07 UTC, Andrei Alexandrescu 
wrote:

On 10/26/2017 08:36 AM, jmh530 wrote:

[...]


I am preparing a request for Microsoft to allow us to 
redistribute some of their binaries. Of course we want to do 
that only if deemed necessary (they are not available easily 
from their site etc). Any help building an exact list of 
requisites would be great. Thanks! -- Andrei


Thanks a lot Andrei. At my working environment I advertise the 
use of DLang. Major competitors are python, nodejs, java and go. 
Everything which makes the installation and use of DLang more 
easy makes it easier to advertise D.


Kind regards
Andre

[Issue 17941] New: arity (and probably others) only consider the first lexically present function

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

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

  Issue ID: 17941
   Summary: arity (and probably others) only consider the first
lexically present function
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

Consider:

import std.traits;

void fun(int);
void fun(int, int);

void gun(int, int);
void gun(int);

static assert(arity!fun == 1);
static assert(arity!gun == 2);

This code passes, indicating that only the first name in lexical order of an
overload set is considered by arity. This is definitely surprising. Worst case
the behavior should be documented, but a real solution would allow people to
indicate which overload they're interested in.

--

Re: Adding pure to a function type

[jmh530 via Digitalmars-d]

On Thursday, 26 October 2017 at 15:47:03 UTC, Andrei Alexandrescu 
wrote:


s/less hideous/even more awesome/

No need to be testy :o).

I noticed there's no way to say "just leave linkage as is". I 
tried SetFunctionAttributes!(typeof(), null, 
FunctionAttribute.pure_) and 
SetFunctionAttributes!(typeof(), "", 
FunctionAttribute.pure_) but neither worked. Should I file a 
bug?



Andrei


How about:

SetFunctionAttributes!(typeof(), functionLinkage!(), 
FunctionAttribute.pure_)

Re: Adding pure to a function type

[jmh530 via Digitalmars-d]

On Thursday, 26 October 2017 at 16:06:28 UTC, jmh530 wrote:
On Thursday, 26 October 2017 at 15:47:03 UTC, Andrei 
Alexandrescu wrote:


s/less hideous/even more awesome/

No need to be testy :o).

I noticed there's no way to say "just leave linkage as is". I 
tried SetFunctionAttributes!(typeof(), null, 
FunctionAttribute.pure_) and 
SetFunctionAttributes!(typeof(), "", 
FunctionAttribute.pure_) but neither worked. Should I file a 
bug?



Andrei


How about:

SetFunctionAttributes!(typeof(), functionLinkage!(), 
FunctionAttribute.pure_)


Or we can just add in additional overloads like:

template SetFunctionAttributes(T, uint attrs)
if (isFunctionPointer!T || isDelegate!T)
{
alias SetFunctionAttributes = 
FunctionTypeOf!(SetFunctionAttributes!(T, functionLinkage!T, 
attrs));

}

template SetFunctionAttributes(T, uint attrs)
if (is(T == function))
{
alias SetFunctionAttributes = 
FunctionTypeOf!(SetFunctionAttributes!(T*, attrs));

}

template SetFunctionAttributes(T, string linkage)
if (isFunctionPointer!T || isDelegate!T)
{
alias SetFunctionAttributes = 
FunctionTypeOf!(SetFunctionAttributes!(T, linkage, 
functionAttributes!T));

}

template SetFunctionAttributes(T, string linkage)
if (is(T == function))
{
alias SetFunctionAttributes = 
FunctionTypeOf!(SetFunctionAttributes!(T*, linkage));

}

[Issue 17940] bool function parameters loaded from struct sometimes miscompiled with -O

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

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

--- Comment #2 from FeepingCreature  ---
Hah! It tries to reload the cse into ESI, but since that's a 1-byte operation
(since bool), it actually becomes a move to DH. ESI is not even reachable with
1-byte ops, because those register values were used to address high regs. So
for reg8 opcodes like 0x8A, code->setReg should assert on reg & 4.

How to actually fix this though, no idea.

--

Re: Note from a donor

[Andrei Alexandrescu via Digitalmars-d]

On 10/26/2017 08:36 AM, jmh530 wrote:

On Thursday, 26 October 2017 at 11:32:26 UTC, Andrei Alexandrescu wrote:


A wizard-style installation with links to things and a good flow might 
help a lot here. Is that possible? -- Andrei


The DMD installer is already a Wizard on Windows.

First it checks if you have a current version of D and will uninstall 
that, then it checks if you want to install D2 along with some extras 
(Visual D, DMC, D1), and it goes through additional steps to install the 
extras if you select them.


However, if you need Visual Studio installed, then that takes like a 
half an hour. My recollection is that it's a little tricky if you 
upgrade to a new version of VS. I usually just uninstall D and reinstall 
it rather than deal with that.


I would have to uninstall MSVC to figure out how annoying it would be to 
install without one (and that's a bit of a hassle). I can't remember at 
what point it checks for MSVC, maybe before installing Visual D?


One thing that might slightly simplify things is if the smallest free 
MSVC you can install is provided as optional if no MSVC installation is 
found. Some note can be added like "Required for 64bit binaries".


I am preparing a request for Microsoft to allow us to redistribute some 
of their binaries. Of course we want to do that only if deemed necessary 
(they are not available easily from their site etc). Any help building 
an exact list of requisites would be great. Thanks! -- Andrei

[Issue 17741] std.range.transposed does not work with Map

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

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

Alexandru Razvan Caciulescu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #4 from Alexandru Razvan Caciulescu  
---
Decided to close this issue. The simple workaround is to use:
auto result = ror.array.transposed;

--

Re: Note from a donor

[Bo via Digitalmars-d]

On Thursday, 26 October 2017 at 12:36:40 UTC, jmh530 wrote:
However, if you need Visual Studio installed, then that takes 
like a half an hour.


And a gig of space, just because D needs a small part of it. That 
is why people do not want to install VS. Why install a competing 
language studio, when you are installing D.

Re: Adding pure to a function type

[Andrei Alexandrescu via Digitalmars-d]

On 10/26/2017 11:10 AM, Adam D. Ruppe wrote:

On Thursday, 26 October 2017 at 15:04:52 UTC, Andrei Alexandrescu wrote:
So I went with the hammer that will fix anything - a string mixin. 
Ideas for a nicer solution?


The stdlib has: SetFunctionAttributes in std.traits

http://dpldocs.info/experimental-docs/std.traits.SetFunctionAttributes.1.html 




Its implementation is string mixin, but at least on the user side it 
looks less hideous.


s/less hideous/even more awesome/

No need to be testy :o).

I noticed there's no way to say "just leave linkage as is". I tried 
SetFunctionAttributes!(typeof(), null, FunctionAttribute.pure_) and 
SetFunctionAttributes!(typeof(), "", FunctionAttribute.pure_) but 
neither worked. Should I file a bug?



Andrei

Re: Adding pure to a function type

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 26 October 2017 at 15:04:52 UTC, Andrei Alexandrescu 
wrote:
So I went with the hammer that will fix anything - a string 
mixin. Ideas for a nicer solution?


The stdlib has: SetFunctionAttributes in std.traits

http://dpldocs.info/experimental-docs/std.traits.SetFunctionAttributes.1.html


Its implementation is string mixin, but at least on the user side 
it looks less hideous.

[Issue 17918] [Reg 2.072] ICE with unknown symbol in base class

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

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

Martin Nowak  changed:

   What|Removed |Added

   Keywords||ice, ice-on-invalid-code
   Priority|P3  |P2
 CC||c...@dawg.eu
Summary|Segmentation fault dmd  |[Reg 2.072] ICE with
   |failed with exit code 139.  |unknown symbol in base
   ||class
   Severity|regression  |critical

--- Comment #5 from Martin Nowak  ---
cat > a.d << CODE
class Base
{
auto byNode()
{
return _listMap;
}
}
CODE
cat > b.d << CODE
import a;

class Derived : Base
{
}
CODE
dmd -c b.d

a.d(5): Error: undefined identifier _listMap
Segmentation fault

#0  0x007280f5 in totym(Type*) ()
#1  0x007231c8 in ToCtypeVisitor::visit(Type*) ()
#2  0x007018ea in Visitor::visit(TypeError*) ()
#3  0x00698949 in TypeError::accept(Visitor*) ()
#4  0x0072df3a in toSymbol::ToSymbol::visit(FuncDeclaration*) ()
#5  0x0062b5b9 in FuncDeclaration::accept(Visitor*) ()
#6  0x0072d46f in toSymbol(Dsymbol*) ()
#7  0x00736cd2 in toObjFile::ToObjFile::visit(ClassDeclaration*) ()
#8  0x0056c30d in ClassDeclaration::accept(Visitor*) ()
#9  0x00735e23 in toObjFile(Dsymbol*, bool) ()
#10 0x0072527f in genObjFile(Module*, bool) ()
#11 0x0068c371 in ddmd.mars.tryMain(ulong, const(char)**) ()
#12 0x0068cdaf in D main ()


Changed severity from regression to major as this was always an ICE.
The difference between version in the example from comment 4, comes from map no
longer being importable from std.algorithm.

--

Empty UDA for classes not allowed?

[bauss via Digitalmars-d-learn]

Why is it not allowed to have empty UDAs for classes?

Let's say we have an UDA like this:
struct Exclude { }

Then we want to put it on a class like:

@Exclude class Foo
{
...
}

This will fail with the following error:
Error: type Exclude has no value

But on everything else we can place an empty UDA like that ex. on 
a function:


This is okay:

@Exclude void foo()
{
...
}

Can someone explain to me why it's not possible with classes?

Adding pure to a function type

[Andrei Alexandrescu via Digitalmars-d]

So I'm trying to add "pure" to a function of which type is otherwise 
deduced by the compiler:


package @property pure
T lazilyInitializedConstant(T, alias outOfBandValue, alias initializer)()
if (is(Unqual!T : T))
{
static T impl()
{
...
}
mixin("alias Fun = " ~ typeof().stringof ~ " pure;");
return (cast(Fun) )();
}

The type of impl depends on T, and when converted to string is something 
like e.g. "immutable(ulong) function() nothrow @nogc @system".


I tried "alias Fun = pure typeof();" which compiled (!), but didn't 
work - Fun is not actually a pure type.


So I went with the hammer that will fix anything - a string mixin. Ideas 
for a nicer solution?



Andrei

Re: Required Reading: "How Non-Member Functions Improve Encapsulation"

[Jacob Carlborg via Digitalmars-d]

On 2017-10-26 08:56, who cares wrote:

I tend to agree. When a member function can be written with only the 
public declarations (aka the "public API") it can be set as a free 
function. However during my youth i've written lots of huge 
classes...now that i don't write much anymore it's too late to apply the 
rule :/


In D, protection attributes applies to the module. So if the free 
functions are defined in the same module, it's easy to accidentally 
access private data.


--
/Jacob Carlborg

[Issue 17940] bool function parameters loaded from struct sometimes miscompiled with -O

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

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

FeepingCreature  changed:

   What|Removed |Added

 CC||default_357-l...@yahoo.de

--- Comment #1 from FeepingCreature  ---
Simplified a bit:

struct Array
{
long length, ptr;
}

struct Struct
{
bool b = true;
}

void fun1(int) { }

void fun2(Array arr, int, int)
{
assert(!arr.length);
}

void fn(Struct* str)
{
Array arr;
if (!str) return;
if (str)
{
fun1(str.b);
}
if (str.b)
{
fun2(arr, str.b, 0);
}
}

void main()
{
Struct s;
fn();
}

--

[Issue 17940] New: bool function parameters loaded from struct sometimes miscompiled with -O

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

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

  Issue ID: 17940
   Summary: bool function parameters loaded from struct sometimes
miscompiled with -O
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: be...@caraus.de

Code (test.d):

struct Array
{
long length, ptr;
}

struct Struct
{
bool b1 = true, b2;
}

void fun(Array arr, int, int)
{
if (arr.length != 0) asm { int 3; }
}

void fn(Struct* str)
{
Array arr;
if (!str) return;
if (str.b1)
{
fun(arr, str.b2, 0);
}
if (str.b1)
{
fun(arr, str.b1, 0);
}
}

void main()
{
Struct s;
fn();
}

Then:

dmd -O test.d  && ./test

causes "Trace/breakpoint trap"

--

[Issue 2447] There's no disconnectall for std.signals

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

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

Eduard Staniloiu  changed:

   What|Removed |Added

 CC||edi33...@gmail.com
   Assignee|nob...@puremagic.com|edi33...@gmail.com

--

[Issue 17897] Incorrect number of destructor calls in example

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

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

--- Comment #11 from Steven Schveighoffer  ---
(In reply to Temtaime from comment #10)
> After fixing https://issues.dlang.org/show_bug.cgi?id=17246 this outputs:
> 
> Bar.this(int): 14FB84
> fun: 14FB20
> Bar.~this(): 14FB20
> 
> Object gets moved without notification.
> This should not behave this way

This is perfectly valid. You are allowed to move a struct without calling the
postblit. See the spec here: https://dlang.org/spec/struct.html

"A struct is defined to not have an identity; that is, the implementation is
free to make bit copies of the struct as convenient."

In fact, I think we can close this as a duplicate, as it now works properly.

However, I'm kind of surprised there is a move here, should be unnecessary if
implemented properly.

--

[Issue 17897] Incorrect number of destructor calls in example

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

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

Temtaime  changed:

   What|Removed |Added

 CC||temta...@gmail.com

--- Comment #10 from Temtaime  ---
After fixing https://issues.dlang.org/show_bug.cgi?id=17246 this outputs:

Bar.this(int): 14FB84
fun: 14FB20
Bar.~this(): 14FB20

Object gets moved without notification.
This should not behave this way

--

[Issue 17897] Incorrect number of destructor calls in example

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

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

--- Comment #9 from Jack Applegame  ---
Seems this bug related to https://issues.dlang.org/show_bug.cgi?id=17246

--

[Issue 17741] std.range.transposed does not work with Map

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

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

Alexandru Razvan Caciulescu  changed:

   What|Removed |Added

 CC||alexandru.razva...@gmail.co
   ||m

--- Comment #2 from Alexandru Razvan Caciulescu  
---
Created a PR for this. I had to change a test for issue #8764
https://issues.dlang.org/show_bug.cgi?id=8764
However I checked and it's not introducing any regression.

--

[Issue 17741] std.range.transposed does not work with Map

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

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

--- Comment #3 from Alexandru Razvan Caciulescu  
---
https://github.com/dlang/phobos/pull/5810

--

Re: Required Reading: "How Non-Member Functions Improve Encapsulation"

[JN via Digitalmars-d]

On Wednesday, 25 October 2017 at 22:19:23 UTC, Walter Bright 
wrote:

for core D devs.

"How Non-Member Functions Improve Encapsulation" by Scott Meyers

http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197

Note that I'm as guilty as anyone for not understanding or 
following these guidelines. I expect we can do much better.


As a counterpoint. I guess UFCS makes it less of a problem, but 
it's nice when using an IDE to just type foo. , press ctrl-space 
and see a nice list of methods that can be used with the class. 
When having free functions, you don't get to enjoy that :)

[Issue 17939] extern(C) function support with non-C attributes/types should be documented

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

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #1 from Martin Nowak  ---
On one hand it's definitely a requirement to attribute C functions, so that
root primitives have correct attributes and people can actually write attribute
correct code using those.

--

Re: Note from a donor

[jmh530 via Digitalmars-d]

On Thursday, 26 October 2017 at 11:32:26 UTC, Andrei Alexandrescu 
wrote:


A wizard-style installation with links to things and a good 
flow might help a lot here. Is that possible? -- Andrei


The DMD installer is already a Wizard on Windows.

First it checks if you have a current version of D and will 
uninstall that, then it checks if you want to install D2 along 
with some extras (Visual D, DMC, D1), and it goes through 
additional steps to install the extras if you select them.


However, if you need Visual Studio installed, then that takes 
like a half an hour. My recollection is that it's a little tricky 
if you upgrade to a new version of VS. I usually just uninstall D 
and reinstall it rather than deal with that.


I would have to uninstall MSVC to figure out how annoying it 
would be to install without one (and that's a bit of a hassle). I 
can't remember at what point it checks for MSVC, maybe before 
installing Visual D?


One thing that might slightly simplify things is if the smallest 
free MSVC you can install is provided as optional if no MSVC 
installation is found. Some note can be added like "Required for 
64bit binaries".

[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

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

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--

Re: Note from a donor

[jmh530 via Digitalmars-d]

On Thursday, 26 October 2017 at 10:19:23 UTC, Kagamin wrote:


LLD was integrated in ldc 1.3.0 
https://github.com/ldc-developers/ldc/pull/2142 but currently 
has conflicting command line options. I suppose you can still 
run it separately, for me even ld works.


Interesting.

[Issue 15831] IFTI voldemort type exploding bloat

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17379

--

[Issue 17379] Mangle voldemort types as if they are defined in the outer scope to avoid exponential symbol name length with templates

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=15831
 Resolution|--- |WONTFIX

--- Comment #6 from Steven Schveighoffer  ---
I think actually, we can close this, as Rainer's fix for issue (in the latest
version of the compiler) mitigates the need for this.

There are also ambiguity problems when there are function overloads.

--

Re: Note from a donor

[Steven Schveighoffer via Digitalmars-d]

On 10/26/17 7:09 AM, Mike Parker wrote:
I also didn't like that I had to install the Xcode tools on my Mac, but 
that's needed for any development on Mac from what I can see.


Want to hear something scary? The autotester does not use xcode tools :)

In fact, I've been meaning to bug Brad about checking to see if things 
have improved (xcode's compiler used to generate a dmd that would fail 
some of the tests). I've never used gnu gcc, only ever Xcode's compiler 
(which is llvm).


-Steve

[Issue 17541] Function attribute deduction depends on compile invocation

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

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 17541] Function attribute deduction depends on compile invocation

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

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

--- Comment #6 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/df847ccb60a37f4dbc349e8cee4a2ee6081e0c3c
fix Issue 17541 - Function attribute deduction depends on compile invocation

https://github.com/dlang/dmd/commit/aabeeb0a550a0d4ba066209290c799c5cf812e87
Merge pull request #6995 from WalterBright/fix17541

fix Issue 17541 - Function attribute deduction depends on compile inv…

--

Re: Required Reading: "How Non-Member Functions Improve Encapsulation"

[Steven Schveighoffer via Digitalmars-d]

On 10/25/17 6:19 PM, Walter Bright wrote:

for core D devs.

"How Non-Member Functions Improve Encapsulation" by Scott Meyers

http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197 



Note that I'm as guilty as anyone for not understanding or following 
these guidelines. I expect we can do much better.


I'm pretty sure I read that before.

However, D's lookup rules fail miserably when it comes to templates:

mod1.d:

auto callFoo(T)(T t)
{
  return t.foo;
}

mod2.d:

struct S
{
   int x;
}

int foo(S s) { return s.x * 5; }

void main()
{
   auto s = S(1);
   assert(s.foo == 5);
   assert(s.callFoo == 5); // can't compile
}

Would be nice to have a way around this. Not sure what it would look like.

Also in D, it's harder to make this help for encapsulation since the 
non-member functions would have to be in another module.


-Steve

[Issue 17842] [scope] array append allows for escaping references

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

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

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/a3859d9529f2505e2736e37c0ee0d8123080c90a
fix Issue 17842 - [scope] array append allows for escaping references

https://github.com/dlang/dmd/commit/7815bdab2df7569edfc27721fde99e82f7d0fe91
Merge pull request #7236 from WalterBright/fix17842

fix Issue 17842 - [scope] array append allows for escaping references

--

[Issue 17927] [scope] `scope inout` parameter value can be escaped via return

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

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

--- Comment #8 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/3f7544f355eacc0ad390a89b1bc07ca2dbcf835e
fix Issue 17927 - [scope]  parameter value can be escaped via return

https://github.com/dlang/dmd/commit/b46ac59c637723877b52b98ed50167e0f68aca5d
Merge pull request #7235 from WalterBright/fix17927

fix Issue 17927 - [scope]  'scope inout' parameter value can be escaped via
return

--

[Issue 7854] Non-C attributes allowed on extern(C) function parameters

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

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

Steven Schveighoffer  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=17939

--

[Issue 17246] [REG2.053] Extra destructor call.

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

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

--- Comment #3 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/6eccdeee1d4c41abb0a6e8733e13a85b63765266
fix Issue 17246 - [REG2.053] Extra destructor call.

https://github.com/dlang/dmd/commit/614da7260f173ae5dc0ec87e8fa85d3edfb031ce
Merge pull request #7238 from WalterBright/fix17246

fix Issue 17246 - [REG2.053] Extra destructor call.

--

[Issue 17939] New: extern(C) function support with non-C attributes/types should be documented

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

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

  Issue ID: 17939
   Summary: extern(C) function support with non-C attributes/types
should be documented
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: spec
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

In issue 7854, Walter says that allowing non-C attributes in extern(C) function
parameters is a "feature":

https://issues.dlang.org/show_bug.cgi?id=7854#c15

Therefore, I'm opening this enhancement request for making the spec reflect
definitively how this feature works. I think a clear explanation will help
compiler developers, and will help users understand what actually happens.

See also Walter's PR that uses this feature:
https://github.com/dlang/druntime/pull/1917

--

[Issue 7997] Optlink issues 'Index Range' error with static zero length array

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

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

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

[Issue 7997] Optlink issues 'Index Range' error with static zero length array

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

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

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/d4883f2a95a3e7ffe9feb09c688b7a1ef38e45f2
fix Issue 7997 - Optlink issues 'Index Range' error with static zero length
array

https://github.com/dlang/dmd/commit/4a62e8479c64b371878f23f0e77c154893613aea
Merge pull request #7243 from WalterBright/fix7997

fix Issue 7997 - Optlink issues 'Index Range' error with static zero …

--

[Issue 17908] Can't alias an overload set with disabled function

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

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #1 from RazvanN  ---
PR : https://github.com/dlang/dmd/pull/7244

--

Re: Note from a donor

[Andrei Alexandrescu via Digitalmars-d]

On 10/26/17 7:09 AM, Mike Parker wrote:

On Thursday, 26 October 2017 at 10:16:27 UTC, Adam Wilson wrote:

On 10/26/17 00:32, Jacob Carlborg wrote:




IIRC, there have been people on these forums that have been asking why
they need to download additional software when they already have the
compiler.

Same on macOS.



How many though? Also, we have to do it for macOS, why is Windows 
special? The macOS setup was just as hard. Download two large packages 
(XCode+Cmd tools), install, and done.


There definitely has been an uptick in that sort of complaint. The 
question should be, how many aren't coming here to complain?


My initial internal reaction has always been, "just download and install 
-- how hard is it?". But one day I stopped and asked myself, what if I 
were coming to D today? I got by just fine for years without having VS 
installed. Once the 6.0 days were behind me, I neither needed nor wanted 
VS. I was content with mingw for my C stuff. When I first came to D, I 
came with the full knowledge that there was no ecosystem, things were 
rough, and I'd have to do a lot by hand. I stuck around because the 
language was worth it. If I came in today and saw that I needed to 
install VS just to get 64-bit binaries, I doubt I'd stick around long 
enough to discover how great the language is.


I also didn't like that I had to install the Xcode tools on my Mac, but 
that's needed for any development on Mac from what I can see.


A wizard-style installation with links to things and a good flow might 
help a lot here. Is that possible? -- Andrei

Re: Note from a donor

[Mike Parker via Digitalmars-d]

On Thursday, 26 October 2017 at 10:16:27 UTC, Adam Wilson wrote:

On 10/26/17 00:32, Jacob Carlborg wrote:




IIRC, there have been people on these forums that have been 
asking why
they need to download additional software when they already 
have the

compiler.

Same on macOS.



How many though? Also, we have to do it for macOS, why is 
Windows special? The macOS setup was just as hard. Download two 
large packages (XCode+Cmd tools), install, and done.


There definitely has been an uptick in that sort of complaint. 
The question should be, how many aren't coming here to complain?


My initial internal reaction has always been, "just download and 
install -- how hard is it?". But one day I stopped and asked 
myself, what if I were coming to D today? I got by just fine for 
years without having VS installed. Once the 6.0 days were behind 
me, I neither needed nor wanted VS. I was content with mingw for 
my C stuff. When I first came to D, I came with the full 
knowledge that there was no ecosystem, things were rough, and I'd 
have to do a lot by hand. I stuck around because the language was 
worth it. If I came in today and saw that I needed to install VS 
just to get 64-bit binaries, I doubt I'd stick around long enough 
to discover how great the language is.


I also didn't like that I had to install the Xcode tools on my 
Mac, but that's needed for any development on Mac from what I can 
see.

Re: D could catch this wave: web assembly

[Suliman via Digitalmars-d]

On Tuesday, 24 October 2017 at 02:08:42 UTC, codephantom wrote:
On Monday, 23 October 2017 at 22:32:55 UTC, bioinfornatics 
wrote:
To remember it will be the next  open standard by a W3C 
Community Group to create portable and efficient application 
across major web browser. A such feature can offer to D a 
chance to have a killer app in 3D web application instead to 
develop complex C++ code.


Consensus is irrelevant.

Google will lead, others will simply follow.

The web stack is like rubbish...a heterogeneous mixture of 
discardable material!


https://github.com/arcanosam/imgui_wasm_demo

Re: D for microservices

[rikki cattermole via Digitalmars-d]

On 26/10/2017 11:25 AM, Adam Wilson wrote:

On 10/25/17 23:57, Jacob Carlborg wrote:

On 2017-10-26 00:53, Adam Wilson wrote:


This of course makes the assumption that we clean-room our own
protocol implementations which I am entirely against. Better to use
what already exists.


I'm entirely against anything that is not compatible with vibe.d ;)



My apologies, something rather the other direction. Instead of forcing 
compat with vibe.d, going to vibe.d and say: "here is our standard 
event-loop, it has everything you need, you'll need to use it for all 
the other goodness to work". I know others can make good arguments about 
why the vibe event-loop is insufficient, and I'll let them make them. 
(Something about not supporting GUI loops, paging Mr. Cattermole). If 
that is really the case I don't see how being entirely vibe.d compatible 
and meeting the universal standard requirements of Phobos is possible.


There would need to be a requirements gathering phase so that the 
community as a whole can bring their use-cases before we dove into code.


The problem isn't the event loop design.
Its a fairly solved problem.

The way vibe.d's works is very specific to their use case (which isn't 
wrong if you only consider them). You can't 'hook' into it. Which makes 
it very undesirable for Phobos. Since it won't cover most use cases. 
Even if the source they are using is compatible with an external GUI 
event loop (which it should be for Windows from what I've read).


So I wouldn't be starting with vibe.d's event loop model. Quite to the 
contrary, kill it. Build something that will last throughout the ages 
for everyone and put this problem to rest.

Re: Assertions getting corrupted

[Jonathan M Davis via Digitalmars-d]

On Thursday, October 26, 2017 10:05:11 bauss via Digitalmars-d wrote:
> If D really wants to succeed with such things, then we cannot
> assume the program is in an invalid state. It must be up to the
> developer themselves to figure out if it's in an invalid state or
> not.

We've been over this before plenty of times in this newsgroup. If an Error
is thrown, then by definition the program is in an invalid state, because
Errors are thrown when bugs are encountered in the program or when the
program encounters an unrecoverable condition. As such, it makes no sense
whatsoever to recover an Error. Would you try to recover from a segfault? I
should hope not, and an Error is pretty much the same thing except that it's
done by the language and involves a stack trace rather being done by the
hardware and resulting in a core dump.

If you don't want your web application going down because of an Error, then
write it in a way that you avoid Errors (e.g. check indices before indexing
an array rather than relying on RangeError if you can't guarantee that the
index is valid). No program should be encountering Errors, and there's
nothing special about web servers that makes it okay for them to be hitting
them. If your program encounters an Error, then it's buggy, and it needs to
be fixed. Making it continue to run after an Error was thrown might work
under some circumstances, but in the general case, you're at serious risk of
making things worse.

As with any program, avoiding the case where your web server terminates due
to Errors is a combination of testing it to make sure that the code is
correct and making sure that you test any conditions coming from user input
or the environment which would ever result in an Error if they weren't
checked. I really don't see what the problem with that is or why anyone
would then think that it's magically okay to treat Errors differently just
because your application is a web server.

And if you're really that concerned about your code being so bad that you're
going to hit Errors with any regularity, then just make it so that your
server restarts if it goes down and load balance across multiple instances.
Any service that's looking to be truly robust is going to need multiple
instances running anyway.

By definition, Errors are _fatal_ error conditions. It's _Exceptions_ which
are used for recoverable error conditions, not Errors, and in the long run,
you're just shooting yourself in the foot if you try to get your program to
recover from an Error instead of terminating.

- Jonathan M Davis

Re: Required Reading: "How Non-Member Functions Improve Encapsulation"

[Kagamin via Digitalmars-d]

On Wednesday, 25 October 2017 at 22:19:23 UTC, Walter Bright 
wrote:

for core D devs.

"How Non-Member Functions Improve Encapsulation" by Scott Meyers

http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197


You mean non-member functions are preferred? I encountered this 
more from performance point: especially in case of small 
structures like Point it would be more beneficial to pass them by 
value than by reference, which can be achieved by extension 
methods, but then you need to import the respective module to 
have those extension methods available. It would work more 
palatable if extension methods from the structure's module were 
available without requiring import. It may rely on static 
declarations inside the struct like C# does it:


struct Size
{
  int width,height;
  alias add=.add; //?
}

Size add(Size s1, Size s2)
{
  return Size(s1.width+s2.width, s1.height+s2.height);
}

or just work without it. Such alias would allow to provide 
extension methods from other modules, though this would mean 
circular dependency between modules.