[Issue 16243] wrong C++ argument passing with empty struct when interfacing with Clang

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

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

--- Comment #21 from Walter Bright  ---
https://github.com/dlang/dmd/pull/7963

--

Re: forcing tabs in regex

[Dmitry Olshansky via Digitalmars-d-learn]

On Wednesday, 28 February 2018 at 05:09:03 UTC, psychoticRabbit 
wrote:

On Wednesday, 28 February 2018 at 01:06:30 UTC, dark777 wrote:

Regex validates years bisexto and not bisextos in format:
const std::regex 
pattern(R"(^(?:(?:(0?[1-9]|1\d|2[0-8])([-/.])(0?[1-9]|1[0-2]|[Jj](?:an|u[nl])|[Mm]a[ry]|[Aa](?:pr|ug)|[Ss]ep|[Oo]ct|[Nn]ov|[Dd]ec|[Ff]eb)|(29|30)([-/.])(0?[13-9]|1[0-2]|[Jj](?:an|u[nl])|[Mm]a[ry]|[Aa](?:pr|ug)|[Ss]ep|[Oo]ct|[Nn]ov|[Dd]ec)|(31)([-/.])(0?[13578]|1[02]|[Jj]an|[Mm]a[ry]|[Jj]ul|[Aa]ug|[Oo]ct|[Dd]ec))(?:\2|\5|\8)(0{2,3}[1-9]|0{1,2}[1-9]\d|0?[1-9]\d{2}|[1-9]\d{3})|(29)([-/.])(0?2|[Ff]eb)\12(\d{1,2}(?:0[48]|[2468][048]|[13579][26])|(?:0?[48]|[13579][26]|[2468][048])00))$)");


this regex above validates the formats through backreferences.



what is this evil dark magic?


Something that is horribly slow and might be incorrect, there are 
very few reasons to write large regexes like that and they 
usually boil down to “it only accepts regex” otherwise parser 
combinators are much better fit.

Re: forcing tabs in regex

[psychoticRabbit via Digitalmars-d-learn]

On Wednesday, 28 February 2018 at 01:06:30 UTC, dark777 wrote:

Regex validates years bisexto and not bisextos in format:
const std::regex 
pattern(R"(^(?:(?:(0?[1-9]|1\d|2[0-8])([-/.])(0?[1-9]|1[0-2]|[Jj](?:an|u[nl])|[Mm]a[ry]|[Aa](?:pr|ug)|[Ss]ep|[Oo]ct|[Nn]ov|[Dd]ec|[Ff]eb)|(29|30)([-/.])(0?[13-9]|1[0-2]|[Jj](?:an|u[nl])|[Mm]a[ry]|[Aa](?:pr|ug)|[Ss]ep|[Oo]ct|[Nn]ov|[Dd]ec)|(31)([-/.])(0?[13578]|1[02]|[Jj]an|[Mm]a[ry]|[Jj]ul|[Aa]ug|[Oo]ct|[Dd]ec))(?:\2|\5|\8)(0{2,3}[1-9]|0{1,2}[1-9]\d|0?[1-9]\d{2}|[1-9]\d{3})|(29)([-/.])(0?2|[Ff]eb)\12(\d{1,2}(?:0[48]|[2468][048]|[13579][26])|(?:0?[48]|[13579][26]|[2468][048])00))$)");


this regex above validates the formats through backreferences.



what is this evil dark magic?

Re: Deprecation: Symbol std.traits.EnumMembers(E) if (is(E == enum)) is not visible from module enumeration because it is privately imported in module range

[Basile B. via Digitalmars-d-debugger]

On Tuesday, 27 February 2018 at 16:08:02 UTC, Marc wrote:

On Tuesday, 27 February 2018 at 16:07:06 UTC, Marc wrote:
How do I remove this warning? I got this after the update to 
v2.079.0-beta.2


this is the line of warning


import std.range : EnumMembers;
enum countOfMembers(E) = EnumMembers!E.length;


you imported the wrong module. EnumMembers in the std.traits.

import std.traits : EnumMembers
enum countOfMembers(E) = EnumMembers!E.length;

Re: program compiled with -g flag give no debugging symbols found on gdb.

[Basile B. via Digitalmars-d-debugger]

On Tuesday, 27 February 2018 at 18:20:33 UTC, Marc wrote:
What am I missing? I compiled na application with -g flag but 
when I do:



gdb --args myapp.exe foo


I get:

Reading symbols from myapp.exe...(no debugging symbols 
found)...done.


What am I missing?


because for Windows no DWARF2 debug infos are generated, which 
are the ones GDB recognize.


By default they are to the CodeView (CV) format for win32, so 
only cdb can be used.
For win64 and mscoff32 it's yet another format (PDB). People use 
https://github.com/rainers/mago and 
https://github.com/rainers/cv2pdb to convert infos in DlangIDE 
and Visual D.

Re: What's the latest news for calling D from python 3 using ctypes?

[chuoiit18 via Digitalmars-d-learn]

On Wednesday, 28 February 2018 at 02:40:59 UTC, Nicholas Wilson 
wrote:
On Wednesday, 28 February 2018 at 01:19:25 UTC, Enjoys Math 
wrote:

[...]


For some reason, idk why, PyD is a dub source dependency (as 
opposed to a library). If you add \path\to\pyd to the include 
directory(?) dub variable (or -I\path\to\pyd to dmd/ldc/gdc) it 
should hopefully work.


, This is a great article. It gave me a lot of useful 
information. thank you very much. Link profile: 
http://phongkhamdakhoathegioi.vn/me-day-ve-noi-va-cach-chua-tri-hieu-qua.html

Re: C++ launched its community survey, too

[Walter Bright via Digitalmars-d]

On 2/27/2018 9:41 AM, H. S. Teoh wrote:

And just about every new dmd release, people fume on this forum about
regressions and gratuitous code breakages.


On Tuesday, sure.

Then on Wednesday the same people propose breaking changes :-)

Everybody wants it both ways, including me.

Re: What's the latest news for calling D from python 3 using ctypes?

[Nicholas Wilson via Digitalmars-d-learn]

On Wednesday, 28 February 2018 at 01:19:25 UTC, Enjoys Math wrote:

Can't build now:


-- Build started: Project: categorytheorybackend, 
Configuration: debug Win32 --
Building 
C:\MyProjects\___ENJOYS_MATH\CategoryTheoryFrontend\CategoryTheoryBackend\categorytheorybackend.exe...
Error: Error writing file 
'obj\debug\dummy\dummy\dummy\dummy\dummy\categorytheorybackend\..\..\..\..\..\Users\FruitfulApproach\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\abstract_.obj'
Building 
C:\MyProjects\___ENJOYS_MATH\CategoryTheoryFrontend\CategoryTheoryBackend\categorytheorybackend.exe failed!
Details saved as 
"file://C:\MyProjects\___ENJOYS_MATH\CategoryTheoryFrontend\CategoryTheoryBackend\.dub\obj\debug\dummy\dummy\dummy\dummy\dummy\categorytheorybackend\categorytheorybackend.buildlog.html"
== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 
skipped ==


For some reason, idk why, PyD is a dub source dependency (as 
opposed to a library). If you add \path\to\pyd to the include 
directory(?) dub variable (or -I\path\to\pyd to dmd/ldc/gdc) it 
should hopefully work.

Re: can we un-deprecate .ptr on arrays in @safe code? cf issue 18529

[Walter Bright via Digitalmars-d]

On 2/27/2018 4:39 AM, Jonathan M Davis wrote:

Except that that's really not how @trusted is supposed to be used. The
programmer needs to verify that the caller is using a.ptr in a manner that
is actually @safe, because the compiler is not smart enough to determine
that for you. Wrapping it in an @trusted function means that the caller
won't get an error and that the programmer won't necessarily know that they
need to verify the calling code. It's the code that's using ptr that needs
to be verified, not the actual accessing of ptr.

Hiding the access to ptr within an @trusted function goes against that
entire idea of @trusted and makes it easy to use ptr without realizing that
you need to be checking the code that's using it, since you just called a
wrapper function to silence the compiler instead of listening the compiler
and studying the code using ptr to verify its @safety.


Yes, this bears repeating.

Re: What's the latest news for calling D from python 3 using ctypes?

[Enjoys Math via Digitalmars-d-learn]

On Wednesday, 28 February 2018 at 00:18:17 UTC, Nicholas Wilson 
wrote:

On Tuesday, 27 February 2018 at 23:59:10 UTC, Enjoys Math wrote:
I am making a library that will run very speedily in D (or, 
failing that, C++) and do the backend work of a PyQt5 gui.  
Was wondering the simplest route to accomplish this, 
preferably in ctypes calls.


Thanks.


http://code.dlang.org/packages/pyd

With PyD you can wrap the D functions for python instead of 
calling them through types in python.


How would you get VisualD + PyD to work nicely together?  See my 
failed build post above.

Re: What's the latest news for calling D from python 3 using ctypes?

[Enjoys Math via Digitalmars-d-learn]

Can't build now:


-- Build started: Project: categorytheorybackend, 
Configuration: debug Win32 --
Building 
C:\MyProjects\___ENJOYS_MATH\CategoryTheoryFrontend\CategoryTheoryBackend\categorytheorybackend.exe...
Error: Error writing file 
'obj\debug\dummy\dummy\dummy\dummy\dummy\categorytheorybackend\..\..\..\..\..\Users\FruitfulApproach\AppData\Roaming\dub\packages\pyd-0.9.9\pyd\infrastructure\deimos\python\abstract_.obj'
Building 
C:\MyProjects\___ENJOYS_MATH\CategoryTheoryFrontend\CategoryTheoryBackend\categorytheorybackend.exe failed!
Details saved as 
"file://C:\MyProjects\___ENJOYS_MATH\CategoryTheoryFrontend\CategoryTheoryBackend\.dub\obj\debug\dummy\dummy\dummy\dummy\dummy\categorytheorybackend\categorytheorybackend.buildlog.html"
== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped 
==

Re: What's the latest news for calling D from python 3 using ctypes?

[Enjoys Math via Digitalmars-d-learn]

On Wednesday, 28 February 2018 at 01:10:36 UTC, Enjoys Math wrote:

Got it.

dub init myproject

from within my python frontend source dir will create a 
subdirectory.


Then you do

dub generate visuald

from within the subdir myproject.

Re: What's the latest news for calling D from python 3 using ctypes?

[Enjoys Math via Digitalmars-d-learn]

Got it.

dub init myproject

from within my python frontend source dir will create a 
subdirectory.

forcing tabs in regex

[dark777 via Digitalmars-d-learn]

Regex validates years bisexto and not bisextos in format:
const std::regex 
pattern(R"(^(?:(?:(0?[1-9]|1\d|2[0-8])([-/.])(0?[1-9]|1[0-2]|[Jj](?:an|u[nl])|[Mm]a[ry]|[Aa](?:pr|ug)|[Ss]ep|[Oo]ct|[Nn]ov|[Dd]ec|[Ff]eb)|(29|30)([-/.])(0?[13-9]|1[0-2]|[Jj](?:an|u[nl])|[Mm]a[ry]|[Aa](?:pr|ug)|[Ss]ep|[Oo]ct|[Nn]ov|[Dd]ec)|(31)([-/.])(0?[13578]|1[02]|[Jj]an|[Mm]a[ry]|[Jj]ul|[Aa]ug|[Oo]ct|[Dd]ec))(?:\2|\5|\8)(0{2,3}[1-9]|0{1,2}[1-9]\d|0?[1-9]\d{2}|[1-9]\d{3})|(29)([-/.])(0?2|[Ff]eb)\12(\d{1,2}(?:0[48]|[2468][048]|[13579][26])|(?:0?[48]|[13579][26]|[2468][048])00))$)");


this regex above validates the formats through backreferences.

dd-mm- ou dd-str- ou dd-Str-
dd/mm/ ou dd/str/ ou dd/Str/
dd.mm. ou dd.str. ou dd.Str.



Regex validates years bisexto and not bisextos in format:
const std::regex 
pattern(R"(^(?:\d{4}([-/.])(?:(?:(?:(?:0?[13578]|1[02]|[Jj](?:an|ul)|[Mm]a[ry]|[Aa]ug|[Oo]ct|[Dd]ec)([-/.])(?:0?[1-9]|[1-2][0-9]|3[01]))|(?:(?:0?[469]|11|[Aa]pr|[Jj]un|[Ss]ep|[Nn]ov)([-/.])(?:0?[1-9]|[1-2][0-9]|30))|(?:(0?2|[Ff]eb)([-/.])(?:0?[1-9]|1[0-9]|2[0-8]|(?:(?:\d{2}(?:0[48]|[2468][048]|[13579][26]))|(?:(?:[02468][048])|[13579][26])00)([-/.])(0?2|[Ff]eb)([-/.])29)$)");


this regex above had to validate the formats through 
backreferences.


but it is validating in the following formats
-mm/dd ou -str/dd ou -Str/dd
/mm.dd ou /str.dd ou /Str.dd
.mm-dd ou .str-dd ou .Str-dd


when it had to validate only in the following formats
-mm-dd ou -str-dd ou -Str-dd
/mm/dd ou /str/dd ou /Str/dd
.mm.dd ou .str.dd ou .Str.dd

how do I do it validate only with some of the tabs?

Re: C++ launched its community survey, too

[Mike Franklin via Digitalmars-d]

On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu 
wrote:

https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

Andrei


"If you could wave a magic wand and change one thing about any 
part of C++, what would it be, and how would that change help 
your daily work?"


Deprecate C++, endorse D, and allocate all existing resources to 
either improving D, or implementing a fork of D.


"Do you have any additional feedback for C++ standardization?"

It's time for C++ to retire, and make room for better, emerging 
languages.  I hate having to use it.

Re: What's the latest news for calling D from python 3 using ctypes?

[Enjoys Math via Digitalmars-d-learn]

On Wednesday, 28 February 2018 at 00:18:17 UTC, Nicholas Wilson 
wrote:

On Tuesday, 27 February 2018 at 23:59:10 UTC, Enjoys Math wrote:
I am making a library that will run very speedily in D (or, 
failing that, C++) and do the backend work of a PyQt5 gui.  
Was wondering the simplest route to accomplish this, 
preferably in ctypes calls.


Thanks.


http://code.dlang.org/packages/pyd

With PyD you can wrap the D functions for python instead of 
calling them through types in python.


Thank you!  That looks like what I need.  How do you install pyd 
with dub so that I can import ?


dub fetch pyd
dub run pyd

doesn't work.  Will try other params and get back to this thread.

Re: C++ launched its community survey, too

[psychoticRabbit via Digitalmars-d]

On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu 
wrote:

https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

Andrei


really, online surveys are dodgy at best.

btw. Bjarne Stroustrup recently received the 2018 Charles Stark 
Draper Prize for Engineering - 
https://www.nae.edu/Activities/Projects/Awards/DraperPrize/DraperWinners/2018Draper.aspx


I think that is dodgy too. Why give someone a prize for creating 
C++. I just don't get it.


It should have gone to the Java developers - cause they deserved 
it.


C++ is the worst thing to have ever come out of computer science!

The only reason it's still with us, is because corporations are 
stuck with it, and force it on us all, cause it's too expensive 
for them to replace.


I want no part of it.

The answer to Q:15 => I'd go back in history and make Stroustrup 
a fluffy dog, or a fluffy cat or something.

[Issue 18486] std.format cannot format const objects

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

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

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

https://github.com/dlang/phobos/commit/93dc74be78de197d8c1daa52d9bd1920d07d7f47
Merge pull request #6207 from JackStouffer/issue18486

Fix Issue 7879 - format of const class with non const toString()

--

[Issue 7879] format of class with not const toString()

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

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

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

   What|Removed |Added

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

--

[Issue 7879] format of class with not const toString()

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

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

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

https://github.com/dlang/phobos/commit/502aed8cc34ee5a5c229bc12571365ab1f04e175
Fix Issue 7879 - format of const/immutable/shared class with no toString()

--

Re: What's the latest news for calling D from python 3 using ctypes?

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 27 February 2018 at 23:59:10 UTC, Enjoys Math wrote:
I am making a library that will run very speedily in D (or, 
failing that, C++) and do the backend work of a PyQt5 gui.  Was 
wondering the simplest route to accomplish this, preferably in 
ctypes calls.


Thanks.


http://code.dlang.org/packages/pyd

With PyD you can wrap the D functions for python instead of 
calling them through types in python.

Re: Equivalent to Python with Statement

[Seb via Digitalmars-d-learn]

On Tuesday, 27 February 2018 at 16:18:43 UTC, Stefan Koch wrote:

On Tuesday, 27 February 2018 at 16:17:20 UTC, Jonathan wrote:
I know Python's `with` statement can be used to have an 
automatic close action:

```
with open("x.txt") as file:
#do something with file
#`file.close()` called automatically
```

I know D's `with` statement does something different but is 
there some sort of equivalent?


In this case with(File("bla"))
will do the same.


FWIW std.stdio.File is refcounted and will be automatically 
closed at the end of the scope. So typically you don't even need 
`with` ;-)
@Jonathan: have a look at these two examples to see what DMD does 
under the hood:



https://run.dlang.io/is/89NBxI
https://run.dlang.io/is/eXC7ZV

What's the latest news for calling D from python 3 using ctypes?

[Enjoys Math via Digitalmars-d-learn]

I am making a library that will run very speedily in D (or, 
failing that, C++) and do the backend work of a PyQt5 gui.  Was 
wondering the simplest route to accomplish this, preferably in 
ctypes calls.


Thanks.

Re: Making mir.random.ndvariable.multivariateNormalVar create bigger data sets than 2

[jmh530 via Digitalmars-d-learn]

On Tuesday, 27 February 2018 at 21:54:34 UTC, Nathan S. wrote:
Cross-posting from the github issue 
(https://github.com/libmir/mir-random/issues/77) with a 
workaround (execute it at https://run.dlang.io/is/Swr1xU):


[snip]



Step in the right direction at least.

Re: C++ launched its community survey, too

[Jonathan M Davis via Digitalmars-d]

On Tuesday, February 27, 2018 15:28:21 H. S. Teoh via Digitalmars-d wrote:
> On Tue, Feb 27, 2018 at 09:44:45PM +, bachmeier via Digitalmars-d 
wrote:
> > On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote:
> > > Granted, though, this is a lot easier than having to write JNI
> > > wrappers or (carefully!) translate C headers into D.  It would be
> > > nice if you could actually just copy-n-paste a C header into an
> > > extern(C) block in D and have it Just Work(tm), but practically all
> > > C headers are dependent on macros one way or another that it would
> > > require including an entire C processor inside the D compiler, which
> > > is not exactly an inviting proposition.
> >
> > Walter has said that he has considered doing that now that DMC is
> > Boost licensed:
> > https://forum.dlang.org/post/p58q2l$1d35$1...@digitalmars.com
>
> Wouldn't that cause compatibility issues with gdc/ldc?

It wouldn't if the idea were to move parts of dmc into the frontend, and
_something_ would have to be put in the frontend for such a thing, even if
it meant accessing the C/C++ compiler via library rather than adding the
C/C++ stuff into the frontend itself. But I don't know what Walter is
thinking exactly.

- Jonathan M Davis

Re: C++ launched its community survey, too

[H. S. Teoh via Digitalmars-d]

On Tue, Feb 27, 2018 at 09:44:45PM +, bachmeier via Digitalmars-d wrote:
> On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote:
> 
> > Granted, though, this is a lot easier than having to write JNI
> > wrappers or (carefully!) translate C headers into D.  It would be
> > nice if you could actually just copy-n-paste a C header into an
> > extern(C) block in D and have it Just Work(tm), but practically all
> > C headers are dependent on macros one way or another that it would
> > require including an entire C processor inside the D compiler, which
> > is not exactly an inviting proposition.
> 
> Walter has said that he has considered doing that now that DMC is
> Boost licensed:
> https://forum.dlang.org/post/p58q2l$1d35$1...@digitalmars.com

Wouldn't that cause compatibility issues with gdc/ldc?


T

-- 
Give me some fresh salted fish, please.

2.079.0-rc.1 [Re: Beta 2.079.0]

[Martin Nowak via Digitalmars-d-announce]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Release candidate available now.

http://dlang.org/changelog/2.079.0.html
http://dlang.org/download.html#dmd_beta

- -Martin
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlqV4EgACgkQsnOBFhK7
GTmxyQ/9HSNmHvegTkIwheEcoHOMyn5s2QvK/8O1k07zfzLa6Bzhu55zEXlQGj1V
GDEl6YwGmzOcEF19XJnh/QOFMeNQJfwErfCjE2pJecN5aSeN87NapARzp1IZLXZw
avGJtlIPALpImYc7sg02syCRkg7399Bei5eAmgxsnbf0p5hx645brkL5v8Ko0stp
+PkGFM3ycAcxXq5iWcyxoIm1zgRKxzlP1xpJi1FIm9vMvT30nFmcF6vNz/IItMhv
bCSDaMU7GVsoRqD6SM9vnzCusbUJZpI6TkH0r+nlAMaU5UI8v9jG9+xQldxKiGhi
ScJY8kxMs4Bl2OS8ZTKqjgzJecejOuiRiseXgrQxRFWjyRVEOhZhh67q9HdgztCy
pc4OwRbwQEI3OR2jyNgbGqyc6eEQenvI4viQEjEONxAYR61hqDCUsWH7/K17z1Uu
4EmybgSiKowqvxF8Q6R7ZfsisAPzs3miSVjZ7pNSldQnrddUsisbfDYfHdexH9Aw
wPWp6OHsLjPRxihxCo8ThVSOjFgXh2+pu9Bzrj+QOa5pmha/hUfsRg6SfoRBsNnm
FopQXDDG4EuaTt64hvw5Phtm9AuUxzuD/49B98EN/YoosfmPFpuecXUX1FDHw33E
Vi467utwlLk5mbG5OBaBrpkpnFExyUn5vb1Ts6S+cCVVSbp58Po=
=nY5p
-END PGP SIGNATURE-

[Issue 18510] [Beta 2.079] lld-link.exe fails to open obj file in subpath

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

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

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

   What|Removed |Added

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

--

[Issue 18296] [Reg2.078.1] invalid code with coverage and copy construction

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

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

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

   What|Removed |Added

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

--

[Issue 18480] [Reg 2.079] dmd hangs with self-alias declaration

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

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

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

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED

--

[Issue 18510] [Beta 2.079] lld-link.exe fails to open obj file in subpath

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

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

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

https://github.com/dlang/dmd/commit/c75ca864f10a1513780172aca5472e8f885f8a87
fix issue 18510 - lld-link.exe fails to open obj file in subpath

LLD doesn't assume .obj automatically for files with '\' in the name, but there
is no good reason to strip the extension to begin with

https://github.com/dlang/dmd/commit/22aeea76549cb6f5dbf0460981f3e0661e754a68
Merge pull request #7946 from rainers/issue18510

fix issue 18510 - lld-link.exe fails to open obj file in subpath

--

Re: Documentation for any* dub package, any version

[Nick Sabalausky via Digitalmars-d-announce]

On Tuesday, 27 February 2018 at 15:49:37 UTC, Basile B. wrote:


At first glance i can say that this will work perfectly for DUB 
packages. Once DCD gives a file, the IDE just have to look the 
parent folders to get the SemVer tag.
If the file is in a git repository things might be more 
complicated.


In most cases its pretty easy from a git repo too, just run 'git 
describe'. That'll give you the latest (annotated) tag (which 
SHOULD be the semver number, and generally is for dub projects) 
and no other output. Nothing to parse or scrape.


If theres been extra commits since the last tag, then there's a 
little extra suffix appended to git describe's output, but its 
trivial enough to parse/remove if you need to.

[Issue 18296] [Reg2.078.1] invalid code with coverage and copy construction

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

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

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

https://github.com/dlang/dmd/commit/0146d2be4298f15416a4f0bee08876934ed2200c
fix Issue 18296 - make __coverage a hidden symbol

- external linkage only for current DSO, but not across DSOs
- avoids GOT indirection on every access
- thus avoids codegen bugs related to those
- uses SCstatic with SFLhidden flag as the access is the same as for
  static symbols, even though linkage is between SCglobal and SCstatic
  In the long-run (and with more usage) a separate SChidden might be cleaner.
- no changes to OMF code as LPUBDEF isn't used

https://github.com/dlang/dmd/commit/eb2bf7713cd46d49a9ea75999188d84b410b45d5
Merge pull request #7772 from MartinNowak/fix18296

fix Issue 18296 - make __coverage a hidden symbol

--

[Issue 18480] [Reg 2.079] dmd hangs with self-alias declaration

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

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

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

https://github.com/dlang/dmd/commit/1092c107880953c8d663ac67f287d87608d4f17e
fix Issue 18480 - dmd 2.079 hangs

https://github.com/dlang/dmd/commit/a551a360f1078efbbfff46f67ee3faccf93c96a5
Merge pull request #7930 from timotheecour/pr_fix_18480

fix Issue 18480  - dmd 2.079 hangs

https://github.com/dlang/dmd/commit/414ae9924ede83a5e5bebc7be0a063a22a3ec6d1
fix Issue 18480 - dmd hangs with self-alias declaration

- fixed by detecting `alias sym = sym;` during semantic
- small adoption of assertion in mostVisibleOverload to deal with
  alias error expression (type = Type.terror) in overload

https://github.com/dlang/dmd/commit/2ab13f54cd8c8da2ee4025319e1baf5a3366f4cc
Merge pull request #7954 from MartinNowak/fix18480

cleaner fix for Issue 18480 - dmd hangs with self-alias declaration

--

[Issue 18519] freebsd 11 + phobos + curl, timing out

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #2 from Seb  ---
See also https://github.com/dlang/phobos/pull/6232 (a PR to temporarily disable
the curl tests).

--

Re: Cast a 2d static array to a 1d static array. T[s][r] -> T[s*r]

[TheFlyingFiddle via Digitalmars-d-learn]

On Tuesday, 27 February 2018 at 22:17:25 UTC, Jonathan wrote:

On Tuesday, 27 February 2018 at 22:13:05 UTC, Jonathan wrote:
Is it possible to cast a 2d static length array to a 1d static 
length array?


E.g.
int[2][2] a = [[1,2],[3,4]];
int[4]b = cast(int[4])a;

Is not the byte data in memory exactly the same?


*( [pos,size].ptr .cst!(void*) .cst!(int[4]*) )
(using dub `cst` library) or
*( cast(int[4]*)(cast(void*)([pos,size].ptr)) )

Okay, this works but is this the best way?!


This should work
int[4] b = *(cast(int[4]*)a.ptr);

Re: Documentation for any* dub package, any version

[David Gileadi via Digitalmars-d-announce]

On 2/27/18 2:59 PM, Adam D. Ruppe wrote:

On Tuesday, 27 February 2018 at 16:39:08 UTC, David Gileadi wrote:
Markdown actually supports two kinds of links: inline links (which you 
describe above and I'm very happy you support) and reference links [1].


Oh, I have something similar to that too.

http://dpldocs.info/experimental-docs/adrdox.syntax.html#footnotes

I actually didn't realize markdown had such... mine is probably not 
quite compatible... but [text][text] is an uncommon enough pattern it 
might just be workable. I doubt I'd ever write [link][link] without a 
space in between...


What I want to do is automatically include references for symbols in 
the current scope, to support links to symbols via [symbol] and [alt 
text][symbol].


Yeah, that might work on both generators.


I hope so. I'm happy that D documentation is nicer to use. Thanks for 
working on it!

Re: C++ launched its community survey, too

[12345swordy via Digitalmars-d]

On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis 
wrote:
On Tuesday, February 27, 2018 17:33:52 12345swordy via 
Digitalmars-d wrote:
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei 
Alexandrescu


wrote:
> https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite 
-2018-02
>
> Andrei

I have submitted, already. My major complaints boils down to 
the fact that they refuse to deprecated features due to 
religious like devotions to backwards compatibility support.


The main problem with that is that the fact that as soon as 
you're willing to break backwards compatability in C++, then 
you lose one of the major benefits of C++ (that the same code 
compiles pretty much forever) and that if you're willing to 
give up on that, you might as well be using another language 
like D or Rust. I'm sure that there's a crowd who would love to 
break some aspects of backwards compatability with C++ and 
stick with it rather than switching to another language, but if 
someone actually really tried to fix C++, you wouldn't end up 
with C++ anymore. You might not end up with D or Rust, but it 
would definitely be a new language, and if you're willing to do 
that, why stick with C++?


The other problem is that many of C++'s problems come from 
being a superset of C, which is also a huge strength, and it 
would be a pretty huge blow to C++ if it couldn't just #include 
C code and use it as if it were C++. To truly fix C++ while 
retaining many of its strengths would require fixing C as well, 
and that's not happening.


- Jonathan M Davis


Yes I know that backwards compatibility comes with benefits, but 
gosh darn it, it doesn't stop me from complaining about it. Even 
more so it's very popular language to develop video games on it.

Re: Documentation for any* dub package, any version

[David Gileadi via Digitalmars-d-announce]

On 2/27/18 3:18 PM, David Gileadi wrote:

On 2/27/18 2:59 PM, Adam D. Ruppe wrote:

On Tuesday, 27 February 2018 at 16:39:08 UTC, David Gileadi wrote:
Markdown actually supports two kinds of links: inline links (which 
you describe above and I'm very happy you support) and reference 
links [1].


Oh, I have something similar to that too.

http://dpldocs.info/experimental-docs/adrdox.syntax.html#footnotes

I actually didn't realize markdown had such... mine is probably not 
quite compatible... but [text][text] is an uncommon enough pattern it 
might just be workable. I doubt I'd ever write [link][link] without a 
space in between...


What I want to do is automatically include references for symbols in 
the current scope, to support links to symbols via [symbol] and [alt 
text][symbol].


Yeah, that might work on both generators.


I hope so. I'm happy that D documentation is nicer to use. Thanks for 
working on it!


Whoops, should have been "...D documentation is *getting* nicer to use."

Re: Cast a 2d static array to a 1d static array. T[s][r] -> T[s*r]

[Jonathan via Digitalmars-d-learn]

On Tuesday, 27 February 2018 at 22:13:05 UTC, Jonathan wrote:
Is it possible to cast a 2d static length array to a 1d static 
length array?


E.g.
int[2][2] a = [[1,2],[3,4]];
int[4]b = cast(int[4])a;

Is not the byte data in memory exactly the same?


*( [pos,size].ptr .cst!(void*) .cst!(int[4]*) )
(using dub `cst` library) or
*( cast(int[4]*)(cast(void*)([pos,size].ptr)) )

Okay, this works but is this the best way?!

Cast a 2d static array to a 1d static array. T[s][r] -> T[s*r]

[Jonathan via Digitalmars-d-learn]

Is it possible to cast a 2d static length array to a 1d static 
length array?


E.g.
int[2][2] a = [[1,2],[3,4]];
int[4]b = cast(int[4])a;

Is not the byte data in memory exactly the same?

[Issue 16519] toHexString always returns stack allocated string

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

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #3 from Seb  ---
FWIW -dip1000 warns about this problem:

foo.d(8): Deprecation: slice of static array temporary returned by
toHexString(hash) assigned to longer lived variable a

but I still think we should do something about the API.

--

Re: Documentation for any* dub package, any version

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

On Tuesday, 27 February 2018 at 16:39:08 UTC, David Gileadi wrote:
Markdown actually supports two kinds of links: inline links 
(which you describe above and I'm very happy you support) and 
reference links [1].


Oh, I have something similar to that too.

http://dpldocs.info/experimental-docs/adrdox.syntax.html#footnotes

I actually didn't realize markdown had such... mine is probably 
not quite compatible... but [text][text] is an uncommon enough 
pattern it might just be workable. I doubt I'd ever write 
[link][link] without a space in between...


What I want to do is automatically include references for 
symbols in the current scope, to support links to symbols via 
[symbol] and [alt text][symbol].


Yeah, that might work on both generators.

[Issue 14241] phobos unittests not run on Windows

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

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com

--- Comment #2 from Timothee Cour  ---
is it related to https://issues.dlang.org/show_bug.cgi?id=18535 ?

--

[Issue 18535] auto-tester fails on Win_32_64 : `The system cannot find the path specified.`

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

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com

--- Comment #1 from Timothee Cour  ---
not sure if related to https://issues.dlang.org/show_bug.cgi?id=14241

--

[Issue 18535] New: auto-tester fails on Win_32_64 : `The system cannot find the path specified.`

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

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

  Issue ID: 18535
   Summary: auto-tester fails on Win_32_64  : `The system cannot
find the path specified.`
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: critical
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

https://auto-tester.puremagic.com/show-run.ghtml?projectid=14=3051857=true



Run ID  3051857
Pulldlang/phobos/6222
SHA 1c63a329cedeb3bf8a37148bffada3d213962da4
Reporterwin-farm-2 (174.24.231.191)
PlatformWin_32_64
Start Time  2018-02-27 21:40:51
End Time2018-02-27 21:52:02
Duration00:11:11
Result Code 1
Deleted 0
Past ResultsPull Test History


```
HOST_DC=/home/braddr/sandbox/at-client/release-build/install/windows/bin/dmd.exe
HOST_DC=D:\sandbox\at-client\release-build\install\windows\bin\dmd.exe
cd test
gmake -j4
Creating output directory: test_results
Building d_do_test tool
Building sanitize_json tool
OS: 'win64'
OS: 'win64'
MODEL: '64'
MODEL: '64'
PIC: ''
../generated/windows/release/32/dmd.exe -conf= -m64  -g -unittest -run
d_do_test.d -unittest
PIC: ''
../generated/windows/release/32/dmd.exe -conf= -m64  -g -odtest_results
-oftest_results\\sanitize_json.exe -i sanitize_json.d
../generated/windows/release/32/dmd.exe -conf= -m64  -g -odtest_results
-oftest_results\\d_do_test.exe d_do_test.d
Running runnable tests
Running compilable tests
Running fail compilation tests

...


The system cannot find the path specified.
failed to execute '\"Program Files (x86)"\"Microsoft Visual Studio
10.0"\VC\bin\amd64\cl.exe /c /nologo runnable\extra-files\cpp_abi_tests.cpp
/Fotest_results\runnable\cpp_abi_tests.cpp.obj'
Makefile:220: recipe for target 'test_results/runnable/cpp_abi_tests.d.out'
failed
gmake[1]: *** [test_results/runnable/cpp_abi_tests.d.out] Error 1
gmake[1]: *** Waiting for unfinished jobs
 ... runnable\xdtor.d ()
 ... runnable\s2ir.d  (-inline -release -g -O)
Makefile:259: recipe for target 'start_runnable_tests' failed
gmake: *** [start_runnable_tests] Error 2
gmake: INTERNAL: Exiting with 3 jobserver tokens available; should be 4!
```

occurred in https://github.com/dlang/phobos/pull/6222

--

Re: Making mir.random.ndvariable.multivariateNormalVar create bigger data sets than 2

[Nathan S. via Digitalmars-d-learn]

Cross-posting from the github issue 
(https://github.com/libmir/mir-random/issues/77) with a 
workaround (execute it at https://run.dlang.io/is/Swr1xU):



I am not sure what the correct interface should be for this in 
the long run, but for now you can use a wrapper function to 
convert an ndvariable to a variable:


```d
/++
Converts an N-dimensional variable to a fixed-dimensional 
variable.

+/
auto specifyDimension(ReturnType, NDVariable)(NDVariable vr)
if (__traits(isStaticArray, ReturnType) && __traits(compiles, 
{static assert(NDVariable.isRandomVariable);}))

{
import mir.random : isSaturatedRandomEngine;
import mir.random.variable : isRandomVariable;
static struct V
{
enum bool isRandomVariable = true;
NDVariable vr;
ReturnType opCall(G)(scope ref G gen) if 
(isSaturatedRandomEngine!G)

{
ReturnType ret;
vr(gen, ret[]);
return ret;
}

ReturnType opCall(G)(scope G* gen) if 
(isSaturatedRandomEngine!G)

{
return opCall!(G)(*gen);
}
}
static assert(isRandomVariable!V);
V v = { vr };
return v;
}
```

So `main` from your above example becomes:

```d
void main()
{
import std.stdio;
import mir.random : Random, threadLocalPtr;
import mir.random.ndvariable : multivariateNormalVar;
import mir.random.algorithm : range;
import mir.ndslice.slice : sliced;
import std.range : take;

auto mu = [10.0, 0.0].sliced;
auto sigma = [2.0, -1.5, -1.5, 2.0].sliced(2,2);

Random* rng = threadLocalPtr!Random;
auto sample = rng
.range(multivariateNormalVar(mu, 
sigma).specifyDimension!(double[2]))

.take(10);
writeln(sample);
}
```

Re: C++ launched its community survey, too

[bachmeier via Digitalmars-d]

On Tuesday, 27 February 2018 at 21:07:03 UTC, H. S. Teoh wrote:

Granted, though, this is a lot easier than having to write JNI 
wrappers or (carefully!) translate C headers into D.  It would 
be nice if you could actually just copy-n-paste a C header into 
an extern(C) block in D and have it Just Work(tm), but 
practically all C headers are dependent on macros one way or 
another that it would require including an entire C processor 
inside the D compiler, which is not exactly an inviting 
proposition.


Walter has said that he has considered doing that now that DMC is 
Boost licensed:

https://forum.dlang.org/post/p58q2l$1d35$1...@digitalmars.com

Re: implicit construction operator

[Rubn via Digitalmars-d]

On Monday, 26 February 2018 at 19:32:44 UTC, ketmar wrote:

WebFreak001 wrote:


Now before you would have only been able to do this:

---
Nullable!Foo a;
foo(a, Nullable!int(5));
---

but now you should also be able to do:

---
Nullable!Foo x = null;
Nullable!Foo y = 5;

foo(null, 5);


please no. such unobvious type conversions goes out of control 
really fast. there is a reason why D doesn't have such thing, 
this is not an oversight, but a design decision.


The bigger mistake is D allowing implicit conversion when a type 
is declared, with no way to disable it when it wasn't asked for.


struct SomeStruct
{
this(int)
{
}
}

SomeStruct value = 10; // I didn't want this

int oops();
SomeStruct value2 = oops(); // Didn't want this either.

SomeStruct ok() { return SomeStruct(10); }
SomeStruct value2 = ok(); // this is what I wanted

On the other hand I want to create a "null" like value for my own 
types. This currently isn't possible in D, because there is no 
implicit conversion allowed for structs. You can be explicit and 
declare every type, but "null" wouldn't be as convenient if you 
had to specify the type it has to convert to every time you 
wanted to use it. I can only imagine the hell hole DMD's source 
code would be if that was the case, with its excessive use of 
null.


You can make the same argument about mixin's, it's possible to 
create some really nasty code with it. That is unreadable and 
unmaintainable, it's especially a pain in the ass when you have 
to debug such code. Yet, there it is in D. Most useful features 
have the capability of being misused, that doesn't mean we 
shouldn't use them.

Re: Struct ctor called with cast

[Radu via Digitalmars-d-learn]

On Tuesday, 27 February 2018 at 21:04:59 UTC, ag0aep6g wrote:

On 02/27/2018 09:59 PM, Radu wrote:

On Tuesday, 27 February 2018 at 20:51:25 UTC, ag0aep6g wrote:

On 02/27/2018 09:30 PM, Radu wrote:

[...]

[...]

[...]
So the bug is that somehow the templated version makes it so 
there is an implicit void* ctor.


In your original code (quoted above), you've got a templated 
constructor. The `Type` in `this(Type)(Type t)` is not the 
enum. It's a template parameter of the constructor.


To get a non-templated constructor that takes a `Type` (the 
enum), you have to write:



this(Type t) /* NOTE: Only one set of parentheses. */
{
/* ... */
}



Understood, make sense now, thanks!

Re: Struct ctor called with cast

[Steven Schveighoffer via Digitalmars-d-learn]

On 2/27/18 3:59 PM, Radu wrote:

On Tuesday, 27 February 2018 at 20:51:25 UTC, ag0aep6g wrote:

On 02/27/2018 09:30 PM, Radu wrote:



enum Type { a };
struct S(Type t = Type.a)
{
 this(Type)(Type t)
 {
 import std.stdio;
 writeln("ctor called.");
 }
}
void main()
{
    auto x = S!(Type.a)(Type.a);
    void* y = 
    auto z = (cast(S!(Type.a)) y);
}


[snip]

So the bug is that somehow the templated version makes it so there is an 
implicit void* ctor.


Look at your constructor. You actually have a TEMPLATED constructor 
inside a TEMPLATED type.


In other words, inside your constructor, `Type` is not an enum Type, 
it's actually a void *.


It becomes clearer if you change the name of the second template parameter:

struct S(Type t = Type.a)
{
   this(T)(T t)
   {
   import std.stdio;
   writeln("ctor called.");
   }
}

-Steve

Re: C++ launched its community survey, too

[H. S. Teoh via Digitalmars-d]

On Tue, Feb 27, 2018 at 01:33:18PM -0700, Jonathan M Davis via Digitalmars-d 
wrote:
[...]
> The main problem with that is that the fact that as soon as you're
> willing to break backwards compatability in C++, then you lose one of
> the major benefits of C++ (that the same code compiles pretty much
> forever)

Not strictly true.  My old C++98 project no longer compiled with the
latest g++, because it contained things allowed in C++98 that are no
longer allowed in C++17.  Some things were relatively simple to fix, but
others were quite painful to fix, so I ended up using --std=c++11 as a
workaround instead.  In the frustrating process of trying to fix things
C++17 complains about, I threw in the towel and decided to rewrite it in
D instead.


[...]
> The other problem is that many of C++'s problems come from being a
> superset of C, which is also a huge strength, and it would be a pretty
> huge blow to C++ if it couldn't just #include C code and use it as if
> it were C++.

Not strictly true either.  Most modern C header files come wrapped with:

#ifdef __cplusplus
extern "C" {
#endif

...

#ifdef __cplusplus
}
#endif __cplusplus

because without that, a lot of C headers actually would *not* compile.

Granted, though, this is a lot easier than having to write JNI wrappers
or (carefully!) translate C headers into D.  It would be nice if you
could actually just copy-n-paste a C header into an extern(C) block in D
and have it Just Work(tm), but practically all C headers are dependent
on macros one way or another that it would require including an entire C
processor inside the D compiler, which is not exactly an inviting
proposition.


> To truly fix C++ while retaining many of its strengths would require
> fixing C as well, and that's not happening.
[...]

Actually, C and C++ have already somewhat diverged. The C subset of C++
is an actually older dialect of C, and no longer 100% compatible with
modern C.  Though it's true that it's still 95% compatible, which is
Good Enough(tm) for most purposes.


T

-- 
A program should be written to model the concepts of the task it performs 
rather than the physical world or a process because this maximizes the 
potential for it to be applied to tasks that are conceptually similar and, more 
important, to tasks that have not yet been conceived. -- Michael B. Allen

Re: Struct ctor called with cast

[ag0aep6g via Digitalmars-d-learn]

On 02/27/2018 09:59 PM, Radu wrote:

On Tuesday, 27 February 2018 at 20:51:25 UTC, ag0aep6g wrote:

On 02/27/2018 09:30 PM, Radu wrote:

[...]

enum Type { a };
struct S(Type t = Type.a)
{
 this(Type)(Type t)
 {
 import std.stdio;
 writeln("ctor called.");
 }
}

[...]
So the bug is that somehow the templated version makes it so there is an 
implicit void* ctor.


In your original code (quoted above), you've got a templated 
constructor. The `Type` in `this(Type)(Type t)` is not the enum. It's a 
template parameter of the constructor.


To get a non-templated constructor that takes a `Type` (the enum), you 
have to write:



this(Type t) /* NOTE: Only one set of parentheses. */
{
/* ... */
}

[Issue 13918] lldb fails to decode DWARF DW_TAG_base_type

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

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

--- Comment #3 from Timothee Cour  ---
full error:

error: need to add support for DW_TAG_base_type 'immutable(char)' encoded with
DW_ATE = 0x10, bit_size = 8
error: need to add support for DW_TAG_base_type 'char' encoded with DW_ATE =
0x10, bit_size = 8

--

[Issue 8172] OSX: symbols mangled on gdb,ggdb,cgdb,lldb but not on ubuntu; no line numbers on stacktraces

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

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com

--- Comment #14 from Timothee Cour  ---
I have a working patch:

see instructions here:
https://github.com/timotheecour/dtools/blob/master/dtools/lldbdplugin.d
it involves dlopen'ing a D shared library + applying this patch build lldb with
https://github.com/llvm-mirror/lldb/pull/3

example results of resulting backtrace shown here:
https://github.com/llvm-mirror/lldb/pull/3

--

Re: Struct ctor called with cast

[Radu via Digitalmars-d-learn]

On Tuesday, 27 February 2018 at 20:51:25 UTC, ag0aep6g wrote:

On 02/27/2018 09:30 PM, Radu wrote:



enum Type { a };
struct S(Type t = Type.a)
{
     this(Type)(Type t)
     {
     import std.stdio;
     writeln("ctor called.");
     }
}
void main()
{
    auto x = S!(Type.a)(Type.a);
    void* y = 
    auto z = (cast(S!(Type.a)) y);
}




Surprisingly the cast will actually call the ctor. Is this to 
be expected? Sure looks like a bug to me, as a non templated S 
will complain about the cast.


Not a bug. The spec says [1]: "Casting a value v to a struct S, 
when value is not a struct of the same type, is equivalent to: 
S(v)"


Templates have nothing to do with it. Your code boils down to 
this:



struct S
{
this(void* t)
{
import std.stdio;
writeln("ctor called.");
}
}
void main()
{
   void* y;
   auto z = cast(S) y;
}



[1] https://dlang.org/spec/expression.html#cast_expressions


OK, got it - thanks.

But this:




struct S
{
this(int t)
{
import std.stdio;
writeln("ctor called.");
}
}
void main()
{
   auto x = S(1);
   void* y = 
   auto z = (cast(S) y);
}




Produces:
Error: cannot cast expression y of type void* to S

Which is kinda correct as I don't have any ctor in S taking a 
void*.


Adding





this(void* t)
{
import std.stdio;
writeln("ctor called.");
}




Will make the error go away.


So the bug is that somehow the templated version makes it so 
there is an implicit void* ctor.

[Issue 13918] lldb fails to decode DWARF DW_TAG_base_type

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

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

Timothee Cour  changed:

   What|Removed |Added

 OS|Linux   |All

--

[Issue 13918] lldb fails to decode DWARF DW_TAG_base_type

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

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

Timothee Cour  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||timothee.co...@gmail.com
 Resolution|WORKSFORME  |---

--- Comment #2 from Timothee Cour  ---
it's still happening in lldb 

error: need to add support for DW_TAG_base_type 'immutable(char)' encoded with
DW_ATE = 0x10, bit_size = 8

this msg appears at the start of a lldb session (eg when using fr v for 1st
time)

--

Re: Struct ctor called with cast

[ag0aep6g via Digitalmars-d-learn]

On 02/27/2018 09:30 PM, Radu wrote:



enum Type { a };
struct S(Type t = Type.a)
{
     this(Type)(Type t)
     {
     import std.stdio;
     writeln("ctor called.");
     }
}
void main()
{
    auto x = S!(Type.a)(Type.a);
    void* y = 
    auto z = (cast(S!(Type.a)) y);
}




Surprisingly the cast will actually call the ctor. Is this to be 
expected? Sure looks like a bug to me, as a non templated S will 
complain about the cast.


Not a bug. The spec says [1]: "Casting a value v to a struct S, when 
value is not a struct of the same type, is equivalent to: S(v)"


Templates have nothing to do with it. Your code boils down to this:


struct S
{
this(void* t)
{
import std.stdio;
writeln("ctor called.");
}
}
void main()
{
   void* y;
   auto z = cast(S) y;
}



[1] https://dlang.org/spec/expression.html#cast_expressions

Re: can we un-deprecate .ptr on arrays in @safe code? cf issue 18529

[Seb via Digitalmars-d]

On Tuesday, 27 February 2018 at 11:33:04 UTC, Simen Kjærås wrote:
That only checks if the first element is the same. For a full 
'is slice' check you'd need something like this:


assert(a.ptr <= b.ptr && b.ptr + b.length <= a.ptr + 
a.length);


// Or:

auto c = b.ptr - a.ptr;
assert(c >= 0 && c + b.length <= a.length);

And trust me, the compiler complains about both of these. 
Possibly rightfully in the first example, but the latter never 
does anything scary with the given pointers.


--
  Simen


aka isSliceOf -> https://github.com/dlang/phobos/pull/6147

Re: C++ launched its community survey, too

[Seb via Digitalmars-d]

On Tuesday, 27 February 2018 at 20:25:32 UTC, JN wrote:
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei 
Alexandrescu wrote:

https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

Andrei


D community survey is coming soon? :)


Yes. Stay tuned.

Re: C++ launched its community survey, too

[bachmeier via Digitalmars-d]

On Tuesday, 27 February 2018 at 20:33:18 UTC, Jonathan M Davis 
wrote:


The other problem is that many of C++'s problems come from 
being a superset of C, which is also a huge strength, and it 
would be a pretty huge blow to C++ if it couldn't just #include 
C code and use it as if it were C++. To truly fix C++ while 
retaining many of its strengths would require fixing C as well, 
and that's not happening.


That's why it would be a big deal to be able to directly include 
C header files in D projects (as was discussed around here not 
that long ago).

Re: How do I trace that memory error?

[Marc via Digitalmars-d-learn]

On Tuesday, 27 February 2018 at 16:55:27 UTC, Marc wrote:

[...]


So deep down the error is in that method which I call from 
deserializeLine() function:




		void setValue(T, V)(auto ref T aggregate, string field, V 
value) {

writeln("setting {", field, "} to {", value, "}");
import std.traits : FieldNameTuple;
import std.meta : Alias;
switch (field) {
foreach (fieldName; FieldNameTuple!T) {
case fieldName:
		static if (is(typeof(__traits(getMember, 
aggregate, fieldName) = value))) {
		__traits(getMember, aggregate, fieldName) 
= value;

return;
} else {
			assert(false, T.stringof ~ "."~field~" cannot 
be assigned from a "~V.stringof~".");

}
}
default:
		assert(false, T.stringof ~ " has no field named 
"~field~".");

}
}



the function is used like this:


Field field = new Field();
foreach(CSVLinkedIndex linkedIndex; linkedIndexes) {
string value = 
values[linkedIndex.csv_column_index];
setValue(field, linkedIndex.field_member, 
value);
}


which eventually (in about 8 calls) return the error:

core.exception.OutOfMemoryError@src\core\exception.d(702): 
Memory allocation failed


it uses about 4MB in a 8GB machine then crashs. It's return by 
the top function using yield:



yield(field);


But I can't find out why gc fails to allocate at some point. In 
fact, I've forced the gc to do so in my top loop:



foreach(Field field; deserializeFile()) {
scope(exit) {
import core.memory : GC;
   GC.collect();
}
}


Which didn't solve the issue.

[Issue 18529] .ptr on arrays can no longer be used in @safe code prevents valid code

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

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

--- Comment #11 from Timothee Cour  ---
https://github.com/dlang/phobos/pull/6231

--

[Issue 18534] Wrong code for ?: operator when compiling with -O

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

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

--- Comment #2 from hst...@quickfur.ath.cx ---
Reduced code without Phobos/template dependency:
-
auto blah(char ch) { return ch; }
auto foo(int i)
{
return blah(i ? 'A' : 'A');
}
void main()
{
auto c = foo(0);
assert(c == 'A');
}
-

--

Re: can we un-deprecate .ptr on arrays in @safe code? cf issue 18529

[Timothee Cour via Digitalmars-d]

> Hm... borrowing from Timothee's suggestion:
> This would be fine and @safe, but may not be useful for all purposes. 
> However, it would fix your issue.


how about this: https://github.com/dlang/phobos/pull/6231

On Tue, Feb 27, 2018 at 12:09 PM, Steven Schveighoffer via
Digitalmars-d  wrote:
> On 2/27/18 3:00 PM, Steven Schveighoffer wrote:
>>
>> On 2/27/18 12:32 PM, Atila Neves wrote:
>>
>>> There's a common case where it's not equivalent - when the pointer is
>>> null. Imagine I have a C function I want to call:
>>>
>>> extern(C) void fun(int* things);
>>>
>>> Imagine also that it's ok to call with null. Well, now I can't use a
>>> slice to call this and have it be 1) @safe and 2) not throw RangeError. I
>>> ran into this the other way.
>>
>>
>> fun(x.length ? [0] : null);
>
>
> Hm... borrowing from Timothee's suggestion:
>
> @trusted @nogc pure nothrow
> T* pointer(T)(T[] a){
>return a.length > 0 ? a.ptr : null;
> }
>
> This would be fine and @safe, but may not be useful for all purposes.
> However, it would fix your issue.
>
> -Steve

Re: C++ launched its community survey, too

[Jonathan M Davis via Digitalmars-d]

On Tuesday, February 27, 2018 17:33:52 12345swordy via Digitalmars-d wrote:
> On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu
>
> wrote:
> > https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite
> > -2018-02
> >
> > Andrei
>
> I have submitted, already. My major complaints boils down to the
> fact that they refuse to deprecated features due to religious
> like devotions to backwards compatibility support.

The main problem with that is that the fact that as soon as you're willing
to break backwards compatability in C++, then you lose one of the major
benefits of C++ (that the same code compiles pretty much forever) and that
if you're willing to give up on that, you might as well be using another
language like D or Rust. I'm sure that there's a crowd who would love to
break some aspects of backwards compatability with C++ and stick with it
rather than switching to another language, but if someone actually really
tried to fix C++, you wouldn't end up with C++ anymore. You might not end up
with D or Rust, but it would definitely be a new language, and if you're
willing to do that, why stick with C++?

The other problem is that many of C++'s problems come from being a superset
of C, which is also a huge strength, and it would be a pretty huge blow to
C++ if it couldn't just #include C code and use it as if it were C++. To
truly fix C++ while retaining many of its strengths would require fixing C
as well, and that's not happening.

- Jonathan M Davis

Struct ctor called with cast

[Radu via Digitalmars-d-learn]

I have this:




enum Type { a };
struct S(Type t = Type.a)
{
this(Type)(Type t)
{
import std.stdio;
writeln("ctor called.");
}
}
void main()
{
   auto x = S!(Type.a)(Type.a);
   void* y = 
   auto z = (cast(S!(Type.a)) y);
}




Surprisingly the cast will actually call the ctor. Is this to be 
expected? Sure looks like a bug to me, as a non templated S will 
complain about the cast.

Re: C++ launched its community survey, too

[JN via Digitalmars-d]

On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu 
wrote:

https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

Andrei


D community survey is coming soon? :)

Re: Equivalent to Python with Statement

[Daniel Kozak via Digitalmars-d-learn]

yes, for classes you can use scoped:

import std.stdio;
import std.typecons : scoped;
class A
{
void saySomething()
{
writeln("Hi from A");
}
~this()
{
writeln("Destruct A");
}
}

void main()
{
with(scoped!A())
{
saySomething();
writeln("something");
}
writeln("Hello D");
}

On Tue, Feb 27, 2018 at 5:25 PM, Jonathan via Digitalmars-d-learn <
digitalmars-d-learn@puremagic.com> wrote:

> On Tuesday, 27 February 2018 at 16:18:43 UTC, Stefan Koch wrote:
>
>> On Tuesday, 27 February 2018 at 16:17:20 UTC, Jonathan wrote:
>>
>>> I know Python's `with` statement can be used to have an automatic close
>>> action:
>>> ```
>>> with open("x.txt") as file:
>>> #do something with file
>>> #`file.close()` called automatically
>>> ```
>>>
>>> I know D's `with` statement does something different but is there some
>>> sort of equivalent?
>>>
>>
>> In this case with(File("bla"))
>> will do the same.
>>
>
> Oh really, cool.
>
> Is this just because the scope of the file variable will end and thus its
> `~this`?
>
>

Re: Validity of cast(void*)size_t.max

[Ali Çehreli via Digitalmars-d-learn]

On 02/27/2018 11:56 AM, Steven Schveighoffer wrote:

On 2/27/18 11:37 AM, Nordlöw wrote:

On Tuesday, 27 February 2018 at 16:31:51 UTC, Steven Schveighoffer wrote:

Why not use null?



It's already used to indicate that a slot is free. :)


cast(void*)1 is likely to be unused.

-Steve


And to be sure, one can have an actual object that represents nullness 
and use its pointer. (Similar to "the null object pattern".)


Ali

[Issue 18534] Wrong code for ?: operator when compiling with -O

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

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

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


void f(char x) {}
void foo(int invert)
{
char c = invert ? 'A' : 'A';
f(c);
assert(c == 'A'); // assertion fails
}
void main()
{
foo(0);
}


--

Re: How do you get comfortable with Dlang.org's Forum?

[Patrick Schluter via Digitalmars-d]

On Tuesday, 27 February 2018 at 07:33:05 UTC, Basile B. wrote:
On Saturday, 24 February 2018 at 19:30:52 UTC, Patrick Schluter 
wrote:
On Saturday, 24 February 2018 at 18:46:50 UTC, Steven 
Schveighoffer wrote:

On 2/24/18 7:00 AM, Patrick Schluter wrote:

[...]


Wow, that's insane. I would be interested in seeing it.

It's in the history of my work PC, may be I will find it on 
monday.


I'm french, i'm interested to know what the hell you talked 
about. Google search gave nothing. Do you referred to the 
journalist who was harassed by people on a gamer forum ?


No, it was not the Nadia Daam thing, she is probably too 
incompetent to pull that trick off.
As for the link, I checked but haven't found it. It was part of a 
longer youtube video but I don't remember which. Sorry.

Re: can we un-deprecate .ptr on arrays in @safe code? cf issue 18529

[Steven Schveighoffer via Digitalmars-d]

On 2/27/18 3:00 PM, Steven Schveighoffer wrote:

On 2/27/18 12:32 PM, Atila Neves wrote:

There's a common case where it's not equivalent - when the pointer is 
null. Imagine I have a C function I want to call:


extern(C) void fun(int* things);

Imagine also that it's ok to call with null. Well, now I can't use a 
slice to call this and have it be 1) @safe and 2) not throw 
RangeError. I ran into this the other way.


fun(x.length ? [0] : null);


Hm... borrowing from Timothee's suggestion:

@trusted @nogc pure nothrow
T* pointer(T)(T[] a){
   return a.length > 0 ? a.ptr : null;
}

This would be fine and @safe, but may not be useful for all purposes. 
However, it would fix your issue.


-Steve

Re: can we un-deprecate .ptr on arrays in @safe code? cf issue 18529

[Steven Schveighoffer via Digitalmars-d]

On 2/27/18 12:32 PM, Atila Neves wrote:

There's a common case where it's not equivalent - when the pointer is 
null. Imagine I have a C function I want to call:


extern(C) void fun(int* things);

Imagine also that it's ok to call with null. Well, now I can't use a 
slice to call this and have it be 1) @safe and 2) not throw RangeError. 
I ran into this the other way.


fun(x.length ? [0] : null);

I think even the compiler could elide the bounds check since you already 
did it, but I'm not sure that actually happens.


-Steve

Re: Validity of cast(void*)size_t.max

[Steven Schveighoffer via Digitalmars-d-learn]

On 2/27/18 11:37 AM, Nordlöw wrote:

On Tuesday, 27 February 2018 at 16:31:51 UTC, Steven Schveighoffer wrote:

Why not use null?



It's already used to indicate that a slot is free. :)


cast(void*)1 is likely to be unused.

-Steve

[Issue 18534] Wrong code for ?: operator when compiling with -O

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

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   Keywords||wrong-code

--

[Issue 18534] New: Wrong code for ?: operator when compiling with -O

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

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

  Issue ID: 18534
   Summary: Wrong code for ?: operator when compiling with -O
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Code:
---
auto foo(int invert)
{
import std.format : format;
return format("%c", invert ? 'A' : 'A');
}
void main()
{
auto s = foo(0);
assert(s == "A"); // assertion fails
}
---

Compile command:
---
dmd -O -run test.d
---

Inspecting the contents of s reveals that instead of containing the character
'A', it contains 0xFF instead.

Compiling without -O fixes the problem.  Replacing the conditional with just
'A' also makes the problem go away.  Seems like -O generates wrong code for the
?: operator.

--

[Issue 18533] inline

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

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

Nathan S.  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--

[Issue 18533] New: inline

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

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

  Issue ID: 18533
   Summary: inline
   Product: D
   Version: D2
  Hardware: All
   URL: http://dlang.org/
OS: All
Status: NEW
  Severity: enhancement
  Priority: P3
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: n8sh.second...@hotmail.com

--

Re: Go 2017 Survey Results

[bachmeier via Digitalmars-d]

On Tuesday, 27 February 2018 at 15:30:44 UTC, JN wrote:

I'm no expert on programming language design, but I think there 
is a difference between templates and generics. At the basic 
level they are used for similar things - specializing container 
types, etc. But templates usually allow much more, so they end 
up being layers of layers of compile time code, e.g. D and 
Boost, which while nifty has it's compilation time cost.


I agree. But I don't know of any way to add generics without 
slowing compilation or making the language harder to use, even if 
it's something other than templates.

Re: C++ launched its community survey, too

[Paolo Invernizzi via Digitalmars-d]

On Tuesday, 27 February 2018 at 17:46:58 UTC, Adam D. Ruppe wrote:

On Tuesday, 27 February 2018 at 17:41:07 UTC, H. S. Teoh wrote:
And just about every new dmd release, people fume on this 
forum about regressions and gratuitous code breakages.


Not all deprecations/code breakages are *regressions* and 
*gratuitous*.


You just need to do a cost/benefit look at it. For C++ though, 
supporting decades of very widespread use is doing to adjust 
the cost calculus of a change relative to D, of course.


+1

Re: C++ launched its community survey, too

[jmh530 via Digitalmars-d]

On Tuesday, 27 February 2018 at 18:42:20 UTC, H. S. Teoh wrote:

[snip]
Well, OK, there *have* been backward-incompatible changes in 
the C++ standard (I experienced some myself just these past 2 
weeks while updating an old C++98 project of mine... which was 
also motivation for ditching C++ completely and migrating the 
whole codebase to D).  But you're not going to see the sort of 
fundamental change that will fix some of the longstanding 
inherent design problems with C++, because that would mean 
alienating the majority of existing C++ projects out there. 
Even if the C++ committee went ahead with such a revision, it 
will surely not fly: nobody will want to implement it.


The economic way of thinking is to consider whether the marginal 
benefit of a breaking change on all future code and whether that 
would exceed the marginal cost of a breaking change requiring old 
projects to be re-written. As most of us recognize, if the amount 
of old code that needs to be re-written is large and the cost of 
re-writing it is high, then it would overwhelm any changes of 
little benefit. Thus, I'm not sure this resistance to 
backward-incompatible changes is something all that specific to 
C++. I would guess that if D were as popular as C++, then the 
rational thing to do would be to be slow moving and be very 
careful about making costly breaking changes.

Re: C++ launched its community survey, too

[Mark via Digitalmars-d]

On Tuesday, 27 February 2018 at 17:33:52 UTC, 12345swordy wrote:
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei 
Alexandrescu wrote:

https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

Andrei


I have submitted, already. My major complaints boils down to 
the fact that they refuse to deprecated features due to 
religious like devotions to backwards compatibility support.


You're not the only one who thinks so -

https://www.youtube.com/watch?v=ND-TuW0KIgg

;)

Re: C++ launched its community survey, too

[jmh530 via Digitalmars-d]

On Tuesday, 27 February 2018 at 19:01:57 UTC, jmh530 wrote:



The economic way of thinking is to consider whether the 
marginal benefit of a breaking change on all future code and 
whether that would exceed the marginal cost of a breaking 
change requiring old projects to be re-written. As most of us 
recognize, if the amount of old code that needs to be 
re-written is large and the cost of re-writing it is high, then 
it would overwhelm any changes of little benefit. Thus, I'm not 
sure this resistance to backward-incompatible changes is 
something all that specific to C++. I would guess that if D 
were as popular as C++, then the rational thing to do would be 
to be slow moving and be very careful about making costly 
breaking changes.


"The economic way of thinking is to consider whether the marginal 
benefit of a breaking change on all future code would exceed the 
marginal cost of a breaking change requiring old projects to be 
re-written."

Re: C++ launched its community survey, too

[H. S. Teoh via Digitalmars-d]

On Tue, Feb 27, 2018 at 05:46:58PM +, Adam D. Ruppe via Digitalmars-d wrote:
> On Tuesday, 27 February 2018 at 17:41:07 UTC, H. S. Teoh wrote:
> > And just about every new dmd release, people fume on this forum
> > about regressions and gratuitous code breakages.
> 
> Not all deprecations/code breakages are *regressions* and
> *gratuitous*.
> 
> You just need to do a cost/benefit look at it. For C++ though,
> supporting decades of very widespread use is doing to adjust the cost
> calculus of a change relative to D, of course.

Of course.  The amount of code breakage caused by a new release of dmd
is surely less than the amount of code breakage that would be caused by
an implementation of a new backward-incompatible C++ standard.  That's
why it's not going to happen.

Well, OK, there *have* been backward-incompatible changes in the C++
standard (I experienced some myself just these past 2 weeks while
updating an old C++98 project of mine... which was also motivation for
ditching C++ completely and migrating the whole codebase to D).  But
you're not going to see the sort of fundamental change that will fix
some of the longstanding inherent design problems with C++, because that
would mean alienating the majority of existing C++ projects out there.
Even if the C++ committee went ahead with such a revision, it will
surely not fly: nobody will want to implement it.

We saw a similar situation, though on a smaller scale, with the whole
D1/D2 Tango vs. Phobos fiasco. Even today that scar still persists in
outsiders' perception of D, despite all our efforts to bury that ugly
past.


T

-- 
Winners never quit, quitters never win. But those who never quit AND never win 
are idiots.

Re: can we un-deprecate .ptr on arrays in @safe code? cf issue 18529

[ag0aep6g via Digitalmars-d]

On 02/27/2018 06:32 PM, Atila Neves wrote:

On Tuesday, 27 February 2018 at 12:39:04 UTC, Jonathan M Davis wrote:

[...]
In almost all cases, [0] is equivalent to a.ptr except that it does 
bounds checking, so it's actually @safe and thus doesn't need to be 
manually verified by the programmer, unlike your pointer function 
suggestion.


There's a common case where it's not equivalent - when the pointer is 
null. Imagine I have a C function I want to call:


extern(C) void fun(int* things);

Imagine also that it's ok to call with null. Well, now I can't use a 
slice to call this and have it be 1) @safe and 2) not throw RangeError. 
I ran into this the other way.


As Jonathan says, you have to manually verify that it's safe, because it 
generally isn't. `arr.ptr` can be invalid but not null, even in @safe code.


Consider:


void fun(int* things) @safe
{
int x = things is null ? 0 : *things;
import std.stdio;
writeln(x);
}

void main()
{
int[] arr;
fun(arr.ptr); /* Ok, prints "0". */

arr = [1, 2, 3];
fun(arr.ptr); /* Ok, prints "1".*/

arr = arr[$ .. $]; /* This is @safe. */
fun(arr.ptr); /* Not ok, prints garbage. */
}


The first two calls are actually safe and can be @trusted. The third 
call is invalid and must not be possible in @safe code.


Maybe it would be possible require `arr.ptr` to be valid or null in 
@safe code. This would outlaw `arr[$ .. $]` and bounds checking would 
have to catch it. I don't know if that would be any practical than 
banning `arr.ptr`.

program compiled with -g flag give no debugging symbols found on gdb.

[Marc via Digitalmars-d-debugger]

What am I missing? I compiled na application with -g flag but 
when I do:



gdb --args myapp.exe foo


I get:

Reading symbols from myapp.exe...(no debugging symbols 
found)...done.


What am I missing?

Re: C++ launched its community survey, too

[12345swordy via Digitalmars-d]

On Tuesday, 27 February 2018 at 17:41:07 UTC, H. S. Teoh wrote:
On Tue, Feb 27, 2018 at 05:33:52PM +, 12345swordy via 
Digitalmars-d wrote:
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei 
Alexandrescu wrote:

> 
https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02
> 
> Andrei


I have submitted, already. My major complaints boils down to 
the fact that they refuse to deprecated features due to 
religious like devotions to backwards compatibility support.


And just about every new dmd release, people fume on this forum 
about regressions and gratuitous code breakages.



T


Which doesn't bother me at the slightest as there are reasonable 
trade offs for this.

Re: Making mir.random.ndvariable.multivariateNormalVar create bigger data sets than 2

[jmh530 via Digitalmars-d-learn]

On Tuesday, 27 February 2018 at 17:24:22 UTC, Nathan S. wrote:

On Tuesday, 27 February 2018 at 16:42:00 UTC, Nathan S. wrote:

On Tuesday, 27 February 2018 at 15:08:42 UTC, jmh530 wrote:
Nevertheless, it probably can't hurt to file an issue if you 
can't get something like the first one to work. I would think 
it should just work.


The problem is that `mir.random.ndvariable` doesn't satisfy 
`mir.random.variable.isRandomVariable!T`. ndvariables have a 
slightly different interface from variables: instead of of  
`rv(gen)` returning a result, `rv(gen, dst)` writes to dst. I 
agree that the various methods for working with variables 
should be enhanced to work with ndvariables.


So, I see that the interface will have to be slightly different 
for ndvariable than for variable. With the exception of 
MultivariateNormalVariable, the same ndvariable instance can be 
called to fill output of any length "n", so one can't 
meaningfully create a range based on just the ndvariable 
without further specification. What would "front" return? For 
MultivariateNormalVariable "n" is constrained but it is a 
runtime parameter rather than a compile-time parameter.


You'll want to ping @9il / Ilya Yaroshenko to discuss what the 
API should be like for this.


Honestly, I think the post above was my first use of mir.random, 
so I'm nowhere near familiar enough at this point to add much 
useful feedback. I'm definitely glad that it is getting worked on 
and plan on using it in the future.


The only thing I would note is that there are not just 
N-dimensional random variables, there are also NXN dimensional 
random variables (not sure what else there could be, but it would 
be significantly less popular). A Wishart distribution (used for 
the distribution of covariance matrices) can be simulated by 
multiplying the transpose of a multivariate random normal by 
itself. This produces an NXN matrix. Ideally, the API could 
handle this type of distribution as well.


Another type of distribution I sometimes see is from Bayesian 
statistics (less common than typical distributions and could 
probably be built on top of what is already in mir.random, but I 
figured it couldn't hurt to bring it to your attention). A 
normal-inverse-gamma distribution is one example of these types 
of distributions. Simulating from this distribution would produce 
a pair of the mean and variance, not just one value. This would 
contrast with multivariate normal in that you would know it has 
two dimensions at compile-time.

Re: C++ launched its community survey, too

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 27 February 2018 at 17:41:07 UTC, H. S. Teoh wrote:
And just about every new dmd release, people fume on this forum 
about regressions and gratuitous code breakages.


Not all deprecations/code breakages are *regressions* and 
*gratuitous*.


You just need to do a cost/benefit look at it. For C++ though, 
supporting decades of very widespread use is doing to adjust the 
cost calculus of a change relative to D, of course.

Re: C++ launched its community survey, too

[H. S. Teoh via Digitalmars-d]

On Tue, Feb 27, 2018 at 05:33:52PM +, 12345swordy via Digitalmars-d wrote:
> On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote:
> > https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02
> > 
> > Andrei
> 
> I have submitted, already. My major complaints boils down to the fact
> that they refuse to deprecated features due to religious like
> devotions to backwards compatibility support.

And just about every new dmd release, people fume on this forum about
regressions and gratuitous code breakages.


T

-- 
It only takes one twig to burn down a forest.

Re: C++ launched its community survey, too

[12345swordy via Digitalmars-d]

On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu 
wrote:

https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02

Andrei


I have submitted, already. My major complaints boils down to the 
fact that they refuse to deprecated features due to religious 
like devotions to backwards compatibility support.

Re: can we un-deprecate .ptr on arrays in @safe code? cf issue 18529

[Atila Neves via Digitalmars-d]

On Tuesday, 27 February 2018 at 12:39:04 UTC, Jonathan M Davis 
wrote:
On Tuesday, February 27, 2018 04:20:38 Timothee Cour via 
Digitalmars-d wrote:

[...]


Except that that's really not how @trusted is supposed to be 
used. The programmer needs to verify that the caller is using 
a.ptr in a manner that is actually @safe, because the compiler 
is not smart enough to determine that for you. Wrapping it in 
an @trusted function means that the caller won't get an error 
and that the programmer won't necessarily know that they need 
to verify the calling code. It's the code that's using ptr that 
needs to be verified, not the actual accessing of ptr.


Hiding the access to ptr within an @trusted function goes 
against that entire idea of @trusted and makes it easy to use 
ptr without realizing that you need to be checking the code 
that's using it, since you just called a wrapper function to 
silence the compiler instead of listening the compiler and 
studying the code using ptr to verify its @safety.



[...]


In almost all cases, [0] is equivalent to a.ptr except that 
it does bounds checking, so it's actually @safe and thus 
doesn't need to be manually verified by the programmer, unlike 
your pointer function suggestion.


There's a common case where it's not equivalent - when the 
pointer is null. Imagine I have a C function I want to call:


extern(C) void fun(int* things);

Imagine also that it's ok to call with null. Well, now I can't 
use a slice to call this and have it be 1) @safe and 2) not throw 
RangeError. I ran into this the other way.


Atila

Re: implicit construction operator

[TheFlyingFiddle via Digitalmars-d]

On Monday, 26 February 2018 at 23:33:48 UTC, H. S. Teoh wrote:
Not really a big deal (and auto kind of ruins it) but it would 
make stuff consistent between user types and built in ones.


Not sure what you mean here.  In a user type, if opBinary!"/" 
returns an int, then you still have the same problem.


Yes, your right, did not really think that through. Also if you 
overload opAssign you get implicit conversions in assign 
expressions...

Re: Making mir.random.ndvariable.multivariateNormalVar create bigger data sets than 2

[Nathan S. via Digitalmars-d-learn]

On Tuesday, 27 February 2018 at 16:42:00 UTC, Nathan S. wrote:

On Tuesday, 27 February 2018 at 15:08:42 UTC, jmh530 wrote:
Nevertheless, it probably can't hurt to file an issue if you 
can't get something like the first one to work. I would think 
it should just work.


The problem is that `mir.random.ndvariable` doesn't satisfy 
`mir.random.variable.isRandomVariable!T`. ndvariables have a 
slightly different interface from variables: instead of of  
`rv(gen)` returning a result, `rv(gen, dst)` writes to dst. I 
agree that the various methods for working with variables 
should be enhanced to work with ndvariables.


So, I see that the interface will have to be slightly different 
for ndvariable than for variable. With the exception of 
MultivariateNormalVariable, the same ndvariable instance can be 
called to fill output of any length "n", so one can't 
meaningfully create a range based on just the ndvariable without 
further specification. What would "front" return? For 
MultivariateNormalVariable "n" is constrained but it is a runtime 
parameter rather than a compile-time parameter.


You'll want to ping @9il / Ilya Yaroshenko to discuss what the 
API should be like for this.

[Issue 13855] Allow multiple selective imports from different modules in a single import statement

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

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

Martin Nowak  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |WONTFIX

--

[Issue 18532] Hex literals produce invalid strings

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

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

--- Comment #3 from FeepingCreature  ---
It has to, because it returns string and string is defined to be UTF-8.

If it wants to return something that is not UTF-8, it should return ubyte[],
and you should have to cast it to string explicitly.

--

Re: How do I trace that memory error?

[Marc via Digitalmars-d-learn]

On Tuesday, 27 February 2018 at 15:08:23 UTC, Stefan Koch wrote:

On Monday, 26 February 2018 at 18:01:07 UTC, Marc wrote:
I've tried both gdb and windbg debugger both it either get a 
"received signal ?" from gdb or crash the GUI application 
(windbg).

The error is:

core.exception.OutOfMemoryError@src\core\exception.d(696): 
Memory allocation failed


How do I find out the source of the error?


I'd say allocating in a loop is a bad idea :)

perhaps you should start with posting the code that leads to 
this.


I've also tried to create only one instance: create a local 
variable inside the method then reuse it. I get same error. No 
debugg tool has helped so far.

Re: How do I trace that memory error?

[Marc via Digitalmars-d-learn]

On Tuesday, 27 February 2018 at 15:08:23 UTC, Stefan Koch wrote:

On Monday, 26 February 2018 at 18:01:07 UTC, Marc wrote:
I've tried both gdb and windbg debugger both it either get a 
"received signal ?" from gdb or crash the GUI application 
(windbg).

The error is:

core.exception.OutOfMemoryError@src\core\exception.d(696): 
Memory allocation failed


How do I find out the source of the error?


I'd say allocating in a loop is a bad idea :)

perhaps you should start with posting the code that leads to 
this.


The code is that one on my second post. The deserializeLine() 
create allocate instance of Field then return. So yeah, I'm 
allocating on loop but I don't doing too much. I was watching the 
memory usage of the application (with win10 taskbar memory usage 
feature) and I saw it uses only about 4mb on 8gb machine. I've 
tried build a 64bit executable but I got same error.