Re: reduce mangled name sizes via link-time symbol renaming

[Johannes Pfau via Digitalmars-d]

Am Thu, 25 Jan 2018 14:24:12 -0800
schrieb Timothee Cour :

> could a solution like proposed below be adapted to automatically
> reduce size of long symbol names?
> 
> It allows final object files to be smaller; eg see the problem this
> causes:
> 
> * String Switch Lowering:
> http://forum.dlang.org/thread/p4d777$1vij$1...@digitalmars.com
> caution: NSFW! contains huge mangled symbol name!
> * http://lists.llvm.org/pipermail/lldb-dev/2018-January/013180.html
> "[lldb-dev] Huge mangled names are causing long delays when loading
> symbol table symbols")
> 
> 
> ```
> main.d:
> void foo_test1(){ }
> void main(){ foo_test1(); }
> 
> dmd -c libmain.a
> 
> ld -r libmain.a -o libmain2.a -alias _D4main9foo_test1FZv _foobar
> -unexported_symbol _D4main9foo_test1FZv
> # or : via `-alias_list filename`
> 
> #NOTE: dummy.d only needed because somehow dmd needs at least one
> object file or source file, a static library is somehow not enough
> (dmd bug?)
> 
> dmd -of=main2 libmain2.a dummy.d
> 
> nm main2 | grep _foobar # ok
> 
> ./main2 # ok
> ```
> 
> NOTE: to automate this process it could find all symbol names >
> threshold and apply a mapping form long mangled names to short aliases
> (eg: object_file_name + incremented_counter), that file with all the
> mappings can be supplied for a demangler (eg for lldb/gdb debugging
> etc)

What is the benefit of using link-time renaming (a linker specific
feature) instead of directly renaming the symbol in the compiler? We
could be quite radical and hash all symbols > a certain threshold. As
long as we have a hash function with strong enough collision resistance
there shouldn't be any problem.

AFAICS we only need the mapping hashed_name ==> full name for
debugging. So maybe we can simply stuff the full, mangled name somehow
into dwarf debug information? We can even keep dwarf debug information
in external files and support for this is just being added to GCCs
libbacktrace, so even stack traces could work fine.

-- Johannes

curl_mime_init: How to get curl handle?

[Andre Pany via Digitalmars-d-learn]

Hi,

I need to send multipart form data using curl. Until now I build 
the message body myself according to the HTML RFC but it is 
getting complex with large files causing Out Of Memory Exceptions.


Low level curl supports multipart form data and I think I copied 
the C headers accordingly. The issue is curl_mime_init needs the 
reference to CURL and it seems I do not get it from std.net.curl: 
HTTP.


curl_mime *curl_mime_init(CURL *easy);

curl_mime* form = null;
auto http = HTTP("");
form = curl_mime_init(http.handle.handle);

Error: struct std.net.curl.Curl member handle is not accessible

Is there a way to get curl_mime_init working?

Kind regards
André

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Johannes Loher via Digitalmars-d]

On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote:
Maybe things work great in a few very specific editor but in my 
personal experience, D its editor support is non stop 
frustrating. And i suspect that this complaint is not new.


Indeed, this complaint is not new. Because the complaint is 
actually so common, I'd like to share my own experience:


I tried several different solutions, including the IntelliJ 
plugin, Mono-D, Sublimetext with a D-plugin, dlangide and vs code 
with code-d. With most of them, I had some problems, but in the 
end, I got all of them working. I had the least problems with 
code-d (the serve-d variant), which works perfectly after setting 
the stdlibPath in the settings (provided you already have 
dscanner and dfmt installed on your system and in your PATH). 
This what also what I've settled for in the end.


In my opinion the features offered by it are actually quite good: 
The autocompletion provided by dcd is more than enough for my 
needs and in addition to that you get static linting, code 
formating, debugging (if you also install the native debug plugin 
from the same author) goto definition and some more features. And 
in my experience this all works without major issues. Sure, you 
don't get autocompletion for ufcs calls, but that is actually 
quite difficult to implement...


Take this all with a grain of salt: I have only tested this on 
Linux and OS X, I have no clue about the situation on Windows.


But at least my experience was really good, so I'd like to use 
this opportunity to thank all the authors of the plugins and the 
underlying tools for doing this (ungrateful) work (and in my 
opinion doing it very well). I know that probably a lot has still 
to be done, but the state of affairs is not as bad as all the 
complaints make it sounds.


The reasons for the problems you describe still being so common 
have already explained thoroughly by others: Its mainly that 
there are no paid developers working on it and therefore not 
enough people working on it. So the solution is actullay quite 
simple and it is the same answer that most complaints about 
problems with D get: Either do it yourself, or pay somebody to do 
it. That is the quickest way to fix things.

[Issue 15613] Parameter type mismatch error message are not very helpful

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

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

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

https://github.com/dlang/dmd/commit/48c6b49605e265e043e9a37fe6064ec603679619
Fix Issue 15613 - Parameter type mismatch error message not very helpful

Show the first argument that fails to match the function parameters.
This is also part of:
Issue 9631 - Error message not using fully qualified name when appropriate

https://github.com/dlang/dmd/commit/fcc69c18c439009508e1e57ea1f91970ffdf9b2b
Merge pull request #7554 from ntrel/qual-arg

Fix Issue 15613, 11529: Show parameter mismatch and rvalue/lvalue ref message
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 15613] Parameter type mismatch error message are not very helpful

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

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

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

   What|Removed |Added

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

--

[Issue 11529] Unclear error message when rvalue is passed as `ref'

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

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

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

   What|Removed |Added

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

--

[Issue 11529] Unclear error message when rvalue is passed as `ref'

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

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

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

https://github.com/dlang/dmd/commit/ff99241a38068e85af6e2625e10ce78b2201de57
Fix Issue 11529 - Unclear error message when rvalue is passed as `ref'

Also hide separate parameter type when already shown.

https://github.com/dlang/dmd/commit/fcc69c18c439009508e1e57ea1f91970ffdf9b2b
Merge pull request #7554 from ntrel/qual-arg

Fix Issue 15613, 11529: Show parameter mismatch and rvalue/lvalue ref message
merged-on-behalf-of: Sebastian Wilzbach 

--

[Issue 15086] import doesn't verify module declaration

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

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com
   Hardware|x86_64  |All
 OS|Linux   |All
   Severity|minor   |critical

--- Comment #2 from Timothee Cour  ---
just ran into this again, this is a serious hole in the D module system.

Here was the example i was gonna report:


```dmd -I. main.d
main
bar // BUG! was imported as foo.bar (inconsistent)
foo.bar2
asdf.wrong // BUG! was imported as foo.bar (inconsistent)
```

```pragma(msg, __MODULE__);
import foo.bar;
import foo.bar2;
import foo.bar3;
void main(){}

cat foo/bar.d
pragma(msg, __MODULE__);
cat foo/bar2.d

cat foo/bar2.d
module foo.bar2;
pragma(msg, __MODULE__);

cat foo/bar3.d
module asdf.wrong;
pragma(msg, __MODULE__);
```



LINKS:
https://github.com/dlang/dmd/pull/7778 Bug fix: dmd allows importing modules
with wrong name #7778

--

[Issue 18299] std.datetime.date.cmpTimeUnits does not throw a DateTimeException

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

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

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

https://github.com/dlang/phobos/commit/f086ab6ce61da95686bc010bfb2b25e2036aae69
Fix Issue 18299: std.datetime.date.cmpTimeUnits does not throw a
DateTimeException

https://github.com/dlang/phobos/commit/af21a266229ed4b83d2bbf5939ad671e8c2ec39c
Merge pull request #6068 from JackStouffer/issue18299

Fix Issue 18299: std.datetime.date.cmpTimeUnits does not throw a Date…
merged-on-behalf-of: Jonathan M Davis 

--

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Rubn via Digitalmars-d]

On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote:
It seems to be that they understand the value of better tooling 
and friendly platform support. Whereas its my impression that a 
lot of resources get focused on making D its compiler / 
language better but the rest seems to be ignored.


Well the entirety of what is used in basically every editor was 
developed by one person. Until recently all those projects were 
solely maintained by that one person. Rust's compiler can be 
integrated with tools if I'm not mistaken, at least I know it was 
being worked on a while back when I looked it up. Comparing to 
Rust isn't exactly fair, it is a lot more financially well off 
with Mozilla back it.


When the tools are community run it is going to be like this. No 
one actually wants to work on it, they would rather be working on 
their own projects. Not working on tools that make working on 
their own projects a tiny bit easier. The tools are at a point 
where they are decent enough to use. You seem to be short 
tempered, you tried 2 plugins rather quickly, without even trying 
to see if there were configurations or other options you could 
use to get features working.


  - Limited name suggestion ( VSC functionality not the plugin 
) only by forcing VSC (ctrl+space).

 - ... and nothing else...


This is just not true...

https://imgur.com/z6CZbjL.gif

Re: Shouldn't invalid references like this fail at compile time?

[H. S. Teoh via Digitalmars-d]

On Fri, Jan 26, 2018 at 01:08:10AM +, Mike Franklin via Digitalmars-d wrote:
> On Wednesday, 24 January 2018 at 09:35:44 UTC, lobo wrote:
> 
> > And I'm broken after using D, going back to C++ is awful and Rust
> > just has too much friction to be enjoyable.
> 
> Yep, I know exactly what you mean.

Me Too (tm).  After having gotten used to D, working with C/C++ (or just
about any other language, really) is just extremely painful.
Unfortunately, I have no choice because my day job requires C/C++.  D
has officially ruined my life. :-D


T

-- 
Notwithstanding the eloquent discontent that you have just respectfully
expressed at length against my verbal capabilities, I am afraid that I
must unfortunately bring it to your attention that I am, in fact, NOT
verbose.

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Basile B. via Digitalmars-d]

On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote:

On Thursday, 25 January 2018 at 19:53:39 UTC, Basile B. wrote:

If you write OOP with few templates like often done in C#, 
Delphi, or more declarative style like Go or C, then DCD works 
fine. Your frustration probably comes from the fact that 
popular techniques in D are not supported by DCD: Template 
Metaprogramming and CTFE.


Maybe there has been a misunderstanding but i am not talking 
about CTFE or Metaprogramming. Basic OOP does not even work. 
And that is after testing D plugins going back a year or more 
with several DMD/Dub releases at the times.


Curious because based on my own experience, a reasonable D 
programming style gives reasonable results with DCD. Maybe you 
missed how to configure things ? For example in CoEdit, everydays 
deps should be registered there: 
http://bbasile.github.io/Coedit/widgets_library_manager#description. In addition the dependencies of a DUB  project are automatically handled at level 1 and if already fetched.


I haven't used Delphi (which you mention in your first message) 
for a while (2012 last time) but even in this big commercial IDE 
there was a dialog where paths for libs had to be registered. And 
at this time this dialog was way less friendly than the one i 
made for CoEdit!

Re: Shouldn't invalid references like this fail at compile time?

[Mike Franklin via Digitalmars-d]

On Wednesday, 24 January 2018 at 09:35:44 UTC, lobo wrote:

And I'm broken after using D, going back to C++ is awful and 
Rust just has too much friction to be enjoyable.


Yep, I know exactly what you mean.

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Basile B. via Digitalmars-d]

On Thursday, 25 January 2018 at 22:21:18 UTC, bachmeier wrote:

On Thursday, 25 January 2018 at 21:56:12 UTC, Benny wrote:
It was my impression that D Foundation has sponsoring from 
different companies. No clue how much but its strange to run a 
Foundation and not being able to pay one or more full time 
employees.


If someone has been hired to work on tooling, I've not heard 
about it. Based on the number of complaints that should be a 
priority. I usually work with nothing more than a text editor 
so it's not an issue for me.


No one has. The work on tools happens here since 8 months: 
https://github.com/dlang-community. I was in the team until 
September and i can say without any doubt that there's no money 
involved.


I someone is paid for making tools then it's a kind of 
"Manhattan-project".

So impossible, it would split people and create tensions.

Re: Class instance memory overhead lower than 3 words?

[kinke via Digitalmars-d-learn]

On Wednesday, 24 January 2018 at 21:48:21 UTC, Nordlöw wrote:
Why is the memory overhead for a class instance as high as 3 
words (24 bytes on 64-bit systems? I find that annoyingly much 
for my knowledge database application. I'm aware of 
extern(C++), having one word overhead, but such 
extern(C++)-classes cannot use all of D; I get compilation 
errors such as


node.d(99,25): Error: Internal Compiler Error: type 
`inout(Edge)[]` can not be mapped to C++


If you don't need C++ interop and only care about getting rid of 
the monitor pointer, you can declare the class as C++ class but 
use the D linkage/ABI for all functions, so that they accept D 
slices:


extern(C++) class Node
{
extern(D):
void foo(Node[] nodes) {}
}

Is a struct not an option?

[Issue 18301] New: `Error: no object files to link` when passing a ".a" instead of a ".o" => should be supported

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

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

  Issue ID: 18301
   Summary: `Error: no object files to link` when passing a ".a"
instead of a ".o" => should be supported
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

seems like an un-necessary restriction:

dmd -c main.d
dmd main.o #ok

dmd -lib main.d
dmd main.a #Error: no object files to link

Can that be supported? 
NOTE: a workaround is to add an empty `dummy.d`:
dmd main.a dummy.d

--

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[bachmeier via Digitalmars-d]

On Thursday, 25 January 2018 at 21:56:12 UTC, Benny wrote:
It was my impression that D Foundation has sponsoring from 
different companies. No clue how much but its strange to run a 
Foundation and not being able to pay one or more full time 
employees.


If someone has been hired to work on tooling, I've not heard 
about it. Based on the number of complaints that should be a 
priority. I usually work with nothing more than a text editor so 
it's not an issue for me.

reduce mangled name sizes via link-time symbol renaming

[Timothee Cour via Digitalmars-d]

could a solution like proposed below be adapted to automatically
reduce size of long symbol names?

It allows final object files to be smaller; eg see the problem this causes:

* String Switch Lowering:
http://forum.dlang.org/thread/p4d777$1vij$1...@digitalmars.com
caution: NSFW! contains huge mangled symbol name!
* http://lists.llvm.org/pipermail/lldb-dev/2018-January/013180.html
"[lldb-dev] Huge mangled names are causing long delays when loading
symbol table symbols")


```
main.d:
void foo_test1(){ }
void main(){ foo_test1(); }

dmd -c libmain.a

ld -r libmain.a -o libmain2.a -alias _D4main9foo_test1FZv _foobar
-unexported_symbol _D4main9foo_test1FZv
# or : via `-alias_list filename`

#NOTE: dummy.d only needed because somehow dmd needs at least one
object file or source file, a static library is somehow not enough
(dmd bug?)

dmd -of=main2 libmain2.a dummy.d

nm main2 | grep _foobar # ok

./main2 # ok
```

NOTE: to automate this process it could find all symbol names >
threshold and apply a mapping form long mangled names to short aliases
(eg: object_file_name + incremented_counter), that file with all the
mappings can be supplied for a demangler (eg for lldb/gdb debugging
etc)

[Issue 17249] Make BigInt data visible (not modifiable!)

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

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

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

   What|Removed |Added

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

--

[Issue 17249] Make BigInt data visible (not modifiable!)

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

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

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

https://github.com/dlang/phobos/commit/dae55d039c8392246514caf6ada93cbb82320511
Fix Issue 17249: Added BigInt.getDigit

https://github.com/dlang/phobos/commit/adee662094e6d4f2976e60267c1a552ba9331781
Merge pull request #5987 from JackStouffer/issue17249

Fix Issue 17249: Added BigInt.getDigit

--

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Benny via Digitalmars-d]

On Thursday, 25 January 2018 at 21:42:33 UTC, bachmeier wrote:
Even one paid developer makes a big difference. You don't need 
hundreds. Making the problem harder is that many current D 
users don't have an interest in those tools. Therefore you're 
drawing from a small pool of part-time volunteer labor.


It's entirely up to the community. This is not something Walter 
or Andrei should be concerned with. I had hoped the D 
Foundation would lead to a better organization of the 
community, but to this point, that doesn't seem to be the case.


It was my impression that D Foundation has sponsoring from 
different companies. No clue how much but its strange to run a 
Foundation and not being able to pay one or more full time 
employees.


I just looked up some community sourced project:

Nim gets on average 1500 to 2000$ per month
Crystal seems to be doing 2000 to 3000$ per month

That is only counting salt.bountrysource and no direct donations.


Just noticed this thread on Reddit and somebody asked about D.

http://www.benfrederickson.com/ranking-programming-languages-by-github-users/

According to the author off the ranking:

18. Rust 0.73%
58. D... 0.047%

No wonder that Rust seems to be more popular and D seems to 
struggle in popularity.

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[bachmeier via Digitalmars-d]

On Thursday, 25 January 2018 at 21:18:23 UTC, Benny wrote:
When a new language like Rust is more tooling friendly and its 
extended platform integrates great with the editor plugins... 
Its not like Mozilla has hundreds of Engineers on Rust. Its 
extreme highly community driven.


Even one paid developer makes a big difference. You don't need 
hundreds. Making the problem harder is that many current D users 
don't have an interest in those tools. Therefore you're drawing 
from a small pool of part-time volunteer labor.


One can only express their hope that there will be a 
revitalization in the D management and the priorities. From my 
point of view it feels like D is falling behind when compared 
to other languages like Rust/C++/Go/... D really needs a 
project leader that knows the language and starts focusing the 
resources beyond just the compiler.


It's entirely up to the community. This is not something Walter 
or Andrei should be concerned with. I had hoped the D Foundation 
would lead to a better organization of the community, but to this 
point, that doesn't seem to be the case.

Re: Implementing tail-const in D

[Simen Kjærås via Digitalmars-d]

On Thursday, 25 January 2018 at 19:54:55 UTC, H. S. Teoh wrote:
I like this idea quite much, actually, in spite of the lack of 
support for implicit conversions, which is a loss (but as you 
said, we can't support that without breaking a lot of existing 
stuff or introducing massive changes that are unlikely to be 
accepted by Walter & Andrei).


Yeah. Arrays and pointers are special, and turn into their 
head-mutable equivalents completely unbidden, when passed to 
functions. No other types in the language does that, and it seems 
a weird semantic to specify for a given type, especially if just 
for making head-mutable work.



Basically, instead of a bunch of convoluted rules with 
poorly-understood corner cases, we delegate the responsibility 
of constructing a head mutable type to the type itself, so the 
user code decides for itself how to construct such a thing. 
It's a clever idea.


Thank you. Given D's template system is very powerful, I think a 
solution where the type couldn't define its own conversion 
wouldn't be anywhere near viable.



In fact, if the standard implementation of opHeadMutable is 
basically the same across all types (or most types), it could 
even be provided as a mixin template in the library, then all 
you have to do is to `mixin headMutable` or something along 
those lines, and off you go.


I believe this should be possible, but 
https://issues.dlang.org/show_bug.cgi?id=11098 causes me 
headaches:


mixin template headMut()
{
auto opHeadMutable(this This)()
{
import std.traits : CopyTypeQualifiers, TemplateArgsOf, 
TemplateOf;

import std.meta : staticMap;

alias Tmpl = TemplateOf!This;
alias Args = TemplateArgsOf!This;

template Apply(T...)
{
static if (is(T[0]))
alias Apply = 
HeadMutable!(CopyTypeQualifiers!(This, T));

else
alias Apply = T; // cannot use local '__lambda1' 
as parameter

}

alias ReturnType = Tmpl!(staticMap!(Apply, Args));

return ReturnType(this);
}
}

Another thought: T.opHeadMutable() and the free function 
headMutable() do basically the same thing, and could be unified 
through UFCS. There'd be a free function headMutable() that works 
for built-in types and UDTs that don't define their own 
T.headMutable(), and then UDTs with T.headMutable() would Just 
Work™. One less moving part.




Questions:
Is a DIP required for this? Should I create a PR implementing 
this for
the range types in Phobos? What other types would benefit from 
this?

[...]

Since this would be introducing new symbols to Phobos, as well 
as, arguably, a new paradigm (or a significant extension to the 
existing paradigms), I think it would be best to get Andrei's 
attention on this issue and persuade him to support this, 
before submitting any PRs, lest the PR gets stuck in the queue 
over nitpicks and rot forever.


My thoughts exactly, and the reason I haven't yet created a PR 
for it.



For one thing, I'm in favor of something in this general 
direction (even if it doesn't end up being this specific 
proposal), so that we can use const more pervasively than right 
now, because currently, the transitivity of const severely 
limits how much code can actually use it. As Jonathan David has 
said, many of us have pretty much given up on const because 
it's just too difficult to work with.  Having standard library 
support for .headMutable is an important first step in making 
const more widely usable, so that more code can benefit from 
its guarantees.


Thanks. I hope it can at least be a stepping stone on the way.

--
  Simen

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Benny via Digitalmars-d]

On Thursday, 25 January 2018 at 19:53:39 UTC, Basile B. wrote:

If you write OOP with few templates like often done in C#, 
Delphi, or more declarative style like Go or C, then DCD works 
fine. Your frustration probably comes from the fact that 
popular techniques in D are not supported by DCD: Template 
Metaprogramming and CTFE.


Maybe there has been a misunderstanding but i am not talking 
about CTFE or Metaprogramming. Basic OOP does not even work. And 
that is after testing D plugins going back a year or more with 
several DMD/Dub releases at the times.


On Thursday, 25 January 2018 at 17:32:24 UTC, Andre Pany wrote:
While the several tools out of the box do not work well 
together, the involved developers
did a great job (without any payment in contrast to Go/C#, 
Delphi...). I also struggled with the problem how to configure 
DCD in the DLang plugin for IntelliJ today.

This might be the reason for the items marked as unknown.
I created an issue here 
https://github.com/intellij-dlanguage/intellij-dlanguage/issues/356




Most of the plugins mentioned here are also made by community or 
individual members. The issue ends up being that its not so much 
the Editor plugins that create the problems but whatever language 
server that is behind it. Please look up several of the plugins 
there originals and you will see a lot are made by individuals? 
For instance OmniPascal...


In my eyes its not the plugin authors there problem because they 
need the official tooling support from D. Compile a set of tools 
and notice how many deprecated calls show up. Or issues when a 
new D compiler version gets released. Or a new Dub version that 
breaks the tooling left or right. This is what i mean by "not 
properly cross platform tested". There seems to be a total lack 
for any tool "chain testing" beyond individual stand alone tests. 
How else does one explain the constant issues i have personally 
faced ( and reported ).



I have been in the position to use D in several projects but in 
my experience its not worth taking the risk ( when issues like 
this keep happening ). This also affect not just the tooling but 
also the whole public dub packages.


When a new language like Rust is more tooling friendly and its 
extended platform integrates great with the editor plugins... Its 
not like Mozilla has hundreds of Engineers on Rust. Its extreme 
highly community driven.


It seems to be that they understand the value of better tooling 
and friendly platform support. Whereas its my impression that a 
lot of resources get focused on making D its compiler / language 
better but the rest seems to be ignored.


I am sorry if this sounds cruel but for now D is on the back 
burner and my next project will probably be in Rust. Its a real 
shame but when even things like editor plugins barely work it 
makes me doubt the rest of the platform. And i do not even like 
Rust as a language but one can not deny it is a better supported 
platform.


One can only express their hope that there will be a 
revitalization in the D management and the priorities. From my 
point of view it feels like D is falling behind when compared to 
other languages like Rust/C++/Go/... D really needs a project 
leader that knows the language and starts focusing the resources 
beyond just the compiler.


Anyway, good luck in the future.

[Issue 17928] [scope] `in` is not treated as `const scope`

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

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

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--- Comment #5 from Carsten Blüggel  ---
My take on that is to describe the current dmd behavior in the spec:
I think it's less confusing to possibly change the spec later again, than
currently being confused about, that dmd behaves different from the spec. I
well remember Scott Meyer's comment at DConf 2017 referring importance of
compiler/spec consistency and absolutely agree.
I submitted PR https://github.com/dlang/dlang.org/pull/2126

--

[Issue 17928] [scope] `in` is not treated as `const scope`

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

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

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

https://github.com/dlang/dlang.org/commit/71ad1b38d5b5d0a25e383c1dce27e90ed6698f71
Parameter storage class in is an equivalent of const currently; see also
discussion in issue #17928; may change later to const scope

--

Re: Release D 2.078.1

[Rainer Schuetze via Digitalmars-d-announce]

On 25.01.2018 14:54, Atila Neves wrote:

On Tuesday, 23 January 2018 at 15:16:02 UTC, Andre Pany wrote:

On Tuesday, 23 January 2018 at 13:08:35 UTC, thedeemon wrote:

On Monday, 22 January 2018 at 20:43:56 UTC, Martin Nowak wrote:

Glad to announce D 2.078.1.



The Windows 7z archive version now has much simpler sc.ini, in fact 
too simple.

With Visual C++ 2015 x64 Native Build Tools now trying to run
dmd -m64 hi.d
I get
LINK : fatal error LNK1104: cannot open file 'libucrt.lib'
Error: linker exited with status 1104

So I needed to edit sc.ini and add back
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64"
to the [Environment64] section.

Then it went just as 2.078.0 - still missing 
legacy_stdio_definitions.lib that I need to add manually in the 
command line.


Did you call vcvarsall in the current dos box/PowerShell? It is a tool 
included with all visual studio variants.


Kind regards
Andre


I just ran into this today. With the dmd 2.077.1 Windows installer 
things just work, and it's never necessary to call vcvarsall.bat to 
build D code for 64-bit.


Since dmd 2.078.0, with Visual Studio 2015, nothing works anymore, and 
sc.ini doesn't seem to reference Visual Studio at all like it used to.


Atila


Visual Studio is supposed to be detected by dmd now, either from the 
environment or from the registry.


What errors do you get? Try running with -v to show the linker command line.

Re: Implementing tail-const in D

[H. S. Teoh via Digitalmars-d]

On Tue, Jan 23, 2018 at 09:36:03AM +, Simen Kjærås via Digitalmars-d wrote:
[...]
> struct R(T) {
> T[] arr;
> auto opHeadMutable(this This)() {
> import std.traits : CopyTypeQualifiers;
> return R!(CopyTypeQualifiers!(This, T))(arr);
> }
> }
> 
> This is the code you will need to write to ensure your types can be
> converted to head-mutable. opHeadMutable provides both a method for
> conversion, and a way for the HeadMutable!T template to extract the
> correct type.

I like this idea quite much, actually, in spite of the lack of support
for implicit conversions, which is a loss (but as you said, we can't
support that without breaking a lot of existing stuff or introducing
massive changes that are unlikely to be accepted by Walter & Andrei).
Basically, instead of a bunch of convoluted rules with poorly-understood
corner cases, we delegate the responsibility of constructing a head
mutable type to the type itself, so the user code decides for itself how
to construct such a thing. It's a clever idea.

In fact, if the standard implementation of opHeadMutable is basically
the same across all types (or most types), it could even be provided as
a mixin template in the library, then all you have to do is to `mixin
headMutable` or something along those lines, and off you go.


> The actual implementation of HeadMutable!T and headMutable is
> available here:
> https://gist.github.com/Biotronic/67bebfe97f17e73cc610d9bcd119adfb
> 
> 
> My current issues with this:
> 1) I don't like the names much. I called them Decay, decay and opDecay
> for a while. Name suggestions are welcome.

I'll leave the bikeshedding to others. :-P


> 2) As mentioned above, implicit conversions would be nice, but that'd
> require an entirely new type of implicit conversion in addition to
> alias this, opDispatch, opDot and interfaces/base classes. This would
> require some pretty darn good reasons, and I don't think a call to
> headMutable() is that much of a problem.

In fact, if done correctly, I think the *lack* of implicit conversion
might actually be a good thing, because the code will be more
self-documenting as to what its intent really is.

const(MyRange!T) r = ...;
...
auto s = r.headMutable; // <-- explicit documentation of intent

as opposed to:

const(MyRange!T) r = ...;
...
MyRange!(const T) s = r; // <-- intent not as clear

While one could argue the latter is more concise and therefore more
readable, the problem is that it hides the fact that user-defined code
is being executed to perform the implicit conversion, and since D allows
you to do all sorts of stuff with compile-time arguments, there's no
guarantee that the implicit call to r.headMutable actually does what you
think it does.  Having to call .headMutable explicitly makes it clear
that user code is being invoked, so that there is no illusion that we're
just "automatically" promoting const(Templ!T) to Templ!(const T).


> Questions:
> Is a DIP required for this? Should I create a PR implementing this for
> the range types in Phobos? What other types would benefit from this?
[...]

Since this would be introducing new symbols to Phobos, as well as,
arguably, a new paradigm (or a significant extension to the existing
paradigms), I think it would be best to get Andrei's attention on this
issue and persuade him to support this, before submitting any PRs, lest
the PR gets stuck in the queue over nitpicks and rot forever.

For one thing, I'm in favor of something in this general direction (even
if it doesn't end up being this specific proposal), so that we can use
const more pervasively than right now, because currently, the
transitivity of const severely limits how much code can actually use it.
As Jonathan David has said, many of us have pretty much given up on
const because it's just too difficult to work with.  Having standard
library support for .headMutable is an important first step in making
const more widely usable, so that more code can benefit from its
guarantees.


T

-- 
Talk is cheap. Whining is actually free. -- Lars Wirzenius

Re: Using std traits

[JN via Digitalmars-d-learn]

On Thursday, 25 January 2018 at 19:49:05 UTC, JN wrote:

if (!hasUDA!(member, "noserialize"))


Nevermind, I get it now, member is only the field name, not a 
'reference', changed it to:


if (!hasUDA!(mixin(T.stringof ~ "." ~ member), "noserialize"))

and works now

Re: Using std traits

[Ali Çehreli via Digitalmars-d-learn]

On 01/25/2018 11:49 AM, JN wrote:


     foreach (i, member; FieldNameTuple!T)
     {
     if (!hasUDA!(member, "noserialize"))
     {
     writeln(member);
     }


'member' is a string local variable, which does not have that UDA. You 
need to get the symbol of the struct:


if (!hasUDA!(__traits(getMember, T, member), "noserialize"))
{
writeln(member);
}

However, note that you're using a compile-time foreach, which expands 
its body for each iteration. Since you used a regular if, you have three 
checks at runtime.


What you really want is use a 'static if':

static if (!hasUDA!(__traits(getMember, T, member), 
"noserialize"))

{
writeln(member);
}

Aaah... Much lighter... :)

Even further, you may want to consider using a 'static foreach':

static foreach (i, member; FieldNameTuple!T)
{
// ...
}

That is more powerful because it can iterate over more ranges. However 
there are some differences from the regular foreach: For example, 
'static foreach' does not introduce a scope per iteration.


Ali

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Basile B. via Digitalmars-d]

On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote:
After months doing a different project, i need a programming 
language for a new client with specific needs. D comes to mind. 
As usual that involves downloading the compiler (dmd and ldc).


[...]

My personal opinion: Too much in the D landscape is so 
individualist and not properly cross platform tested, that it 
results in pure frustration for the end developer.


If you write OOP with few templates like often done in C#, 
Delphi, or more declarative style like Go or C, then DCD works 
fine. Your frustration probably comes from the fact that popular 
techniques in D are not supported by DCD: Template 
Metaprogramming and CTFE. They are not well supported because 
they "just" require to have a compiler built in the completion 
engine. You can also add "auto everywhere" to the problems 
(plenty of std.algorithm, std.typecons, std.range are not 
supported at all)


This problem won't be fixed (ever: i'm honnest since i work a bit 
on dparse dcd etc. i didn't see the "big" thing coming) so the 
best advice i can give you is "do not to use the things that are 
not supported by DCD in the public API". Use them for private 
internal details. And avoid "auto".


Now, let's talk about the bugs. The important things in DCD are 
done by a library called D-Symbol. This library needs more love. 
https://github.com/dlang-community/dsymbol/pulls. There are 5 
valid bug fixes opened since the end of the summer and that 
haven't been handled. A movement had started in July / August but 
apparently has stopped in September for some reasons.


I don't think that complaining about specific editor plugins will 
help. People who write these plugins have adapted DCD to their 
product but they cant just sit and wait that the completion gets 
better. At some point if you work on a IDE you have deal with 
certain low level language stuff. It's not just about piping 
process.
(Note: this paragraph is addressed to editor plugins and IDE 
writers).

Using std traits

[JN via Digitalmars-d-learn]

I decided it's time to learn how std traits work. I still find 
the whole compile time business a bit weird to deal with, so I 
decided to write a simple JSON serializer for struct that loops 
over member fields and outputs them.


import std.stdio;
import std.json;
import std.traits;

struct TestStruct
{
@("noserialize") int x;
int y;
int z;
}

void serialize(T)(T obj)
{
if (is(T == struct))
{
foreach (i, member; FieldNameTuple!T)
{
if (!hasUDA!(member, "noserialize"))
{
writeln(member);
}
}
} else {
assert(0, "Not a struct");
}
}

void main()
{
TestStruct ts;
ts.x = 1;
ts.y = 2;
ts.z = 3;
serialize(ts);
}

here's a runnable version: https://ideone.com/U4ROAT


I expected it to output "y" "z", but "x" is also present. What am 
I doing wrong with hasUDA?

Re: String Switch Lowering

[Steven Schveighoffer via Digitalmars-d]

On 1/25/18 1:41 PM, H. S. Teoh wrote:

On Thu, Jan 25, 2018 at 07:21:29PM +0100, Benjamin Thaut via Digitalmars-d 
wrote:



If we think this is a good idea, should we rewrite this particular
string switch to use a associative array instead to avoid the overly
long symbol name?

[...]

I believe the original idea behind using a template for string switches
was to allow the possibility for the implementation to be smarter about
how to implement the switch (IIRC, string switches used to be
implemented as a runtime function). Supposedly object.__switch could
analyze the list of strings at compile-time and generate a perfect hash
or something, to maximize runtime performance.


I believe that when the number of cases is small enough, the binary 
search of the strings is done recursively to allow full optimization. 
And these symbols should be relatively small.


But I think if the number of strings is large enough, it calls the same 
runtime function as before (essentially). But here we have a problem -- 
the wrapper for this function is essentially this giant symbol that 
generates the string array locally, and then calls the real function. 
It's a huge cost just for a simple inline-able wrapper to another call.


See the code here:
https://github.com/dlang/druntime/blob/master/src/object.d#L3873

The function that does the real work is __switchSearch, which is only 
templated on the char type. It's going to be very very infrequent that 
the exact same switch case list is used in multiple places, meaning you 
are paying a huge cost for essentially memoizing these string lists.


I think we need some way to mark a function as following a different 
mangling, or maybe even just avoid the whole memoization, do everything 
inline.


-Steve

Re: run.dlang.io can now display ASM + AST + IR

[ikod via Digitalmars-d-announce]

On Thursday, 25 January 2018 at 19:22:19 UTC, Seb wrote:

On Monday, 15 January 2018 at 22:50:55 UTC, kinke wrote:

On Sunday, 14 January 2018 at 04:18:41 UTC, Seb wrote:

3) IR (LDC only)

https://run.dlang.io/is/BOTNDf


Thanks Seb. I particularly like this feature. After a quick 
glance, the debuginfos (-g) seem to be needlessly enforced, 
bloating the IR.
A colored output would be a nice improvement; there's a plugin 
for the google-code-prettify JS library [1], which wouldn't 
increase the server load. Maybe there's one for asm too.


[1] https://gist.github.com/ndabas/2850418


Easy enough:

https://github.com/dlang-tour/core-exec/pull/18

I also added syntax coloring for LLVM IR, Assembly and D's AST 
dump:


https://github.com/dlang-tour/core/pull/643

Anything else that would help you?


Is it possible to show demangled names in asm output (or this 
option already available)?

Re: run.dlang.io can now display ASM + AST + IR

[Seb via Digitalmars-d-announce]

On Monday, 15 January 2018 at 22:50:55 UTC, kinke wrote:

On Sunday, 14 January 2018 at 04:18:41 UTC, Seb wrote:

3) IR (LDC only)

https://run.dlang.io/is/BOTNDf


Thanks Seb. I particularly like this feature. After a quick 
glance, the debuginfos (-g) seem to be needlessly enforced, 
bloating the IR.
A colored output would be a nice improvement; there's a plugin 
for the google-code-prettify JS library [1], which wouldn't 
increase the server load. Maybe there's one for asm too.


[1] https://gist.github.com/ndabas/2850418


Easy enough:

https://github.com/dlang-tour/core-exec/pull/18

I also added syntax coloring for LLVM IR, Assembly and D's AST 
dump:


https://github.com/dlang-tour/core/pull/643

Anything else that would help you?

Re: String Switch Lowering

[H. S. Teoh via Digitalmars-d]

On Thu, Jan 25, 2018 at 11:42:03AM -0700, Jonathan M Davis via Digitalmars-d 
wrote:
> On Thursday, January 25, 2018 19:21:29 Benjamin Thaut via Digitalmars-d 
> wrote:
> > If we think this is a good idea, should we rewrite this particular
> > string switch to use a associative array instead to avoid the overly
> > long symbol name?
> 
> That particular switch statement is in a function that's deprecated
> and scheduled to be completely removed in about six months, so I don't
> see much point in worrying about it unless it's causing serious
> problems, and while that symbol name is stupidly long, AFAIK, it's not
> really causing any problems.

I haven't verified this yet, but I suspect that this may be (one of?)
the cause(s) of my recent woes with dmd's memory usage on low-memory
systems. If indeed this is the cause, then yes, it *is* causing problems
for me and anyone else who wants to use dmd on a low-memory system (this
sounds almost like an oxymoron these days!). And since it's deprecated,
perhaps it wouldn't hurt to hack it to use an AA instead so that in the
meantime Phobos doesn't consume inordinate amounts of memory just to
compile.


> I never would have thought that a switch statement would even have a
> symbol associated with it though. Clearly, I have no clue about how
> they're implemented.
[...]

IIRC they used to be a runtime function in druntime, but recently got
changed into a template, ostensibly for more flexibility in how they're
implemented. Apparently the original function was pretty lousy in terms
of performance. The new object.__switch is supposedly better, but the
expense of ridiculously-long symbols in the binary. Some days you just
can't win. :-/


T

-- 
Two wrongs don't make a right; but three rights do make a left...

Re: String Switch Lowering

[H. S. Teoh via Digitalmars-d]

On Thu, Jan 25, 2018 at 07:21:29PM +0100, Benjamin Thaut via Digitalmars-d 
wrote:
> _D6object__T8__switchTyaVxAyaa7_[...snip ridiculously long symbol...]
> 
> The first time I encountered this symbol in phobos I though: WTF? Then
> I tried to demangle it:
> core.exception.RangeError@src\core\demangle.d(230): Range violation

LOL! This reminds me of the days before Rainer's symbol backreferencing
PR was merged, where a UFCS chain of range algorithms causes exponential
growth in symbol length. This one isn't exponential, but it *is* still
ridiculously long.  We need to fix it. :-D


> I was then quickly informed by Rainer Scheutze what the correct
> demangling for this symbols is:
> 
> pure nothrow @nogc @safe int object.__switch!(immutable(char), "CST6CDT",
> "EST5EDT", "Etc/GMT", "MST7MDT", "PST8PDT", "Asia/Aden", "Asia/Baku",
[... snip ridiculously long template argument list ...]
> "America/Argentina/Rio_Gallegos",
> "America/North_Dakota/New_Salem").__switch(scope const(immutable(char)[]))
> 
> So I was thinking to myself: Is it really a good idea to lower string
> switches to a template if it results in such symbols? This symbol
> alone takes 17815 Bytes.

I think this is part of a much larger issue that we need to tackle, that
is, long template argument lists (esp. since D allows you to directly
manipulate these lists aka tuples aka AliasSeq, so user code is liable
to generate large numbers of these things with potentially very long
lengths).

I don't have a clear solution yet, but my initial thought is that in
cases like these, where the list is basically unique, all that's
*really* required of the generated symbol is that it be unique. There is
really no need to go encoding every last detail into the symbol name, as
if the first 1000 bytes or so of the symbol isn't probably already
enough to disambiguate it from every other symbol in the program.  If we
could somehow detect or annotate these cases as merely requiring a
unique symbol, then we could just substitute the whole monstrous thing
with a hash, like an MD5 or SHA checksum, which will be much less than
100 bytes.


> If we think this is a good idea, should we rewrite this particular
> string switch to use a associative array instead to avoid the overly
> long symbol name?
[...]

I believe the original idea behind using a template for string switches
was to allow the possibility for the implementation to be smarter about
how to implement the switch (IIRC, string switches used to be
implemented as a runtime function). Supposedly object.__switch could
analyze the list of strings at compile-time and generate a perfect hash
or something, to maximize runtime performance.

IMO the real fix ought to be to make the compiler somehow recognize
these cases and generate shorter symbols for them, rather than
hard-coding the Phobos code to use AAs, though admittedly, the latter
may probably a necessary stop-gap measure in the meantime.

(On which note, I wonder if you may have inadvertently found the source
of my recent dmd memory usage woes... a symbol like this in a commonly
imported module in Phobos like std.datetime would explain why recently I
suddenly can't compile Phobos anymore on a low-memory system without
invoking the kernel OOM killer, or why even the most trivial of projects
take ridiculous amounts of memory to compile.)


T

-- 
The volume of a pizza of thickness a and radius z can be described by the 
following formula: pi zz a. -- Wouter Verhelst

Re: String Switch Lowering

[Benjamin Thaut via Digitalmars-d]

Am 25.01.2018 um 19:42 schrieb Jonathan M Davis:


That particular switch statement is in a function that's deprecated and
scheduled to be completely removed in about six months, so I don't see much
point in worrying about it unless it's causing serious problems, and while
that symbol name is stupidly long, AFAIK, it's not really causing any
problems.



The main problem is binary size for shared library verisons of phobos. 
The overly long symbols names contribute significantly to binary size as 
for both exports and imports. The full symbol name is stored in the dll 
and the exe that uses the dll.


--
Kind Regards
Benjamin Thaut

Re: String Switch Lowering

[Jonathan M Davis via Digitalmars-d]

On Thursday, January 25, 2018 19:21:29 Benjamin Thaut via Digitalmars-d 
wrote:
> If we think this is a good idea, should we rewrite this particular
> string switch to use a associative array instead to avoid the overly
> long symbol name?

That particular switch statement is in a function that's deprecated and
scheduled to be completely removed in about six months, so I don't see much
point in worrying about it unless it's causing serious problems, and while
that symbol name is stupidly long, AFAIK, it's not really causing any
problems.

I never would have thought that a switch statement would even have a symbol
associated with it though. Clearly, I have no clue about how they're
implemented.

- Jonathan M Davis

String Switch Lowering

[Benjamin Thaut via Digitalmars-d]

[Issue 17437] Incorrect range check when implicitly converting integer literals to float/double

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

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

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

https://github.com/dlang/dmd/commit/ab9e5e2dc67d33552091185910fe98d12ddb312c
Fix issue 17437 - convertibility of integer literals to float/double

After casting the integer value to the floating-point type, make sure to
backcast it to an integer for the equality check, so that the comparison
is performed as integer instead of the fp type with potentially smaller
integer range. This prevents inexact implicit convertibility.

https://github.com/dlang/dmd/commit/5f25f05f538053b1c9e260db3fe237e2a258ada8
Merge pull request #6831 from kinke/int2fp

Fix Issue 17437 - Incorrect range check when implicitly converting integer
literals to float/double
merged-on-behalf-of: Rainer Schuetze 

--

[Issue 17437] Incorrect range check when implicitly converting integer literals to float/double

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

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

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

   What|Removed |Added

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

--

[Issue 18300] core.demangle demangling of really long symbol fails

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

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

uplink.co...@googlemail.com changed:

   What|Removed |Added

 CC||uplink.co...@googlemail.com

--- Comment #1 from uplink.co...@googlemail.com ---
The reason is that instantiating a template with a giant alias list if really
fucked up.

--

[Issue 18300] New: core.demangle demangling of really long symbol fails

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

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

  Issue ID: 18300
   Summary: core.demangle demangling of really long symbol fails
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: c...@benjamin-thaut.de

The following symbol is generated while compiling druntime / phobos:

_D6object__T8__switchTyaVxAyaa7_43535436434454VxQwa7_45535435454454VxQBra7_4574632f474d54VxQCna7_4d5354374d4454VxQDja7_50535438504454VxQEfa9_417369612f4164656eVxQFfa9_417369612f42616b75VxQGfa9_417369612f44696c69VxQHfa9_417369612f486f7664VxQIfa9_417369612f4f6d736bVxQJfa9_417369612f4f72616cVxQKfa9_4574632f474d542b31VxQLfa9_4574632f474d542b32VxQMfa9_4574632f474d542b33VxQNfa9_4574632f474d542b34VxQOfa9_4574632f474d542b35VxQPfa9_4574632f474d542b36VxQQfa9_4574632f474d542b37VxQRfa9_4574632f474d542b38VxQSfa9_4574632f474d542b39VxQTfa9_4574632f474d542d31VxQUfa9_4574632f474d542d32VxQVfa9_4574632f474d542d33VxQWfa9_4574632f474d542d34VxQXfa9_4574632f474d542d35VxQYfa9_4574632f474d542d36VxQZfa9_4574632f474d542d37VxQBAfa9_4574632f474d542d38VxQBBga9_4574632f474d542d39VxQBCha10_417369612f416d6d616eVxQBDla10_417369612f4171746175VxQBEpa10_417369612f4368697461VxQBFta10_417369612f4468616b61VxQBGxa10_417369612f4475626169VxQBIba10_417369612f4b6162756cVxQBJfa10_417369612f4d61636175VxQBKja10_417369612f!
 
5161746172VxQBLna10_417369612f53656f756cVxQBMra10_417369612f546f6b796fVxQBNva10_417369612f546f6d736bVxQBOza10_4574632f474d542b3130VxQBQda10_4574632f474d542b3131VxQBRha10_4574632f474d542b3132VxQBSla10_4574632f474d542d3130VxQBTpa10_4574632f474d542d3131VxQBUta10_4574632f474d542d3132VxQBVxa10_4574632f474d542d3133VxQBXba10_4574632f474d542d3134VxQBYfa11_4166726963612f4a756261VxQBZla11_4166726963612f4c6f6d65VxQCAra11_417369612f416c6d617479VxQCBxa11_417369612f416e61647972VxQCDda11_417369612f4171746f6265VxQCEja11_417369612f426569727574VxQCFpa11_417369612f4272756e6569VxQCGva11_417369612f486562726f6eVxQCIba11_417369612f4b7577616974VxQCJha11_417369612f4d616e696c61VxQCKna11_417369612f4d7573636174VxQCLta11_417369612f526979616468VxQCMza11_417369612f536169676f6eVxQCOfa11_417369612f546169706569VxQCPla11_417369612f54656872616eVxQCQra11_417369612f5572756d7169VxQCRxa11_4575726f70652f4b696576VxQCTda11_4575726f70652f4f736c6fVxQCUja11_4575726f70652f52696761VxQCVpa11_4575726f70652f526f6d65VxQCWva1!
 
1_496e6469616e2f4d616865VxQCYba12_4166726963612f4163637261VxQCZja12_4166726963612f436169726fVxQDAra12_4166726963612f4365757461VxQDBza12_4166726963612f44616b6172VxQDDha12_4166726963612f4c61676f73VxQDEpa12_4166726963612f54756e6973VxQDFxa12_416d65726963612f4164616bVxQDHfa12_416d65726963612f4c696d61VxQDIna12_416d65726963612f4e6f6d65VxQDJva12_417369612f42616768646164VxQDLda12_417369612f4261687261696eVxQDMla12_417369612f42616e676b6f6bVxQDNta12_417369612f4261726e61756cVxQDPba12_417369612f426973686b656bVxQDQja12_417369612f436f6c6f6d626fVxQDRra12_417369612f49726b7574736bVxQDSza12_417369612f4a616b61727461VxQDUha12_417369612f4b617261636869VxQDVpa12_417369612f4b756368696e67VxQDWxa12_417369612f4d61676164616eVxQDYfa12_417369612f4e69636f736961VxQDZna12_417369612f52616e676f6f6eVxQEAva12_417369612f5462696c697369VxQECda12_417369612f5468696d706875VxQEDla12_417369612f59616b7574736bVxQEEta12_417369612f5965726576616eVxQEGba12_4575726f70652f4d616c7461VxQEHja12_4575726f70652f4d696e736bVxQEIra12_4575726f70652f5061726973VxQEJza12_4575726f70652f536f666961VxQELha12_45757!
 
26f70652f566164757aVxQEMpa12_496e6469616e2f436f636f73VxQENxa12_506163696669632f41706961VxQEPfa12_506163696669632f46696a69VxQEQna12_506163696669632f4775616dVxQERva12_506163696669632f4e697565VxQETda12_506163696669632f5472756bVxQEUla12_506163696669632f57616b65VxQEVta13_4166726963612f41736d657261VxQEXda13_4166726963612f42616d616b6fVxQEYna13_4166726963612f42616e677569VxQEZxa13_4166726963612f42616e6a756cVxQFBha13_4166726963612f426973736175VxQFCra13_4166726963612f446f75616c61VxQFEba13_4166726963612f486172617265VxQFFla13_4166726963612f4b6967616c69VxQFGva13_4166726963612f4c75616e6461VxQFIfa13_4166726963612f4c7573616b61VxQFJpa13_4166726963612f4d616c61626fVxQFKza13_4166726963612f4d617075746fVxQFMja13_4166726963612f4d6173657275VxQFNta13_4166726963612f4e69616d6579VxQFPda13_416d65726963612f4172756261VxQFQna13_416d65726963612f4261686961VxQFRxa13_416d65726963612f42656c656dVxQFTha13_416d65726963612f426f697365VxQFUra13_416d65726963612f4a756a7579VxQFWba13_416d65726963612f5369746b61VxQFXla13_4!
 

[Issue 5621] speller.c: implement type inference in speller suggestion

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

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

--- Comment #4 from Iain Buclaw  ---
It would still be a nice-to-have a type inference suggestion, instead of
"undefined identifier 'S'"

--

[Issue 5621] speller.c: implement type inference in speller suggestion

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

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

--- Comment #3 from Iain Buclaw  ---
Maybe this was fixed by https://github.com/dlang/dmd/pull/4143

The compiler no longer offers spelling suggestion for the original test case.

--

[Issue 18299] New: std.datetime.date.cmpTimeUnits does not throw a DateTimeException

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

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

  Issue ID: 18299
   Summary: std.datetime.date.cmpTimeUnits does not throw a
DateTimeException
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

cmpTimeUnits throws an Exception rather than a DateTimeException

--

[Issue 16510] Request: RSA digital signature validation in phobos

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

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

--- Comment #7 from Andre  ---
(In reply to Carsten Blüggel from comment #4)
> I'm replying to this and deliberately not to
> https://issues.dlang.org/show_bug.cgi?id=17958, because this is more
> specific:
> RSA digital signature validation
> 
> This operation is quite easy to implement and there are no security concerns
> I can see here; all it requires are publicly available information: The
> digital signature, the public RSA key, the plain message that was signed,
> some math/en-/decoding operations applied
> [https://tools.ietf.org/html/rfc8017], a base64 decoder and digest functions
> (present in phobos already) and a simplified ASN1-decoder (for DigestInfo;
> no full-fledged one required for this case). If there are plans to
> incorporate some more crypto in phobos, I will gladly contribute/share
> implementations, some is already on https://github.com/carblue, a lot still
> on my ssd.
> 
> All of the discussion in
> https://forum.dlang.org/thread/osnema$d5s$1...@digitalmars.com is pointless
> referring to this one operation "RSA digital signature validation", though
> the discussion is absolutely valid and great care must be applied (leave it
> to experts!) concerning cryptography in general (i.e. when e.g.
> secret/private key material is involved; that's why the general case of 
> https://issues.dlang.org/show_bug.cgi?id=17958 is different and not really a
> duplicate of this).
> 
> My take on aforementioned security discussion is also differing in that I
> would rely on specialized hardware like smart cards or USB tokens only (both
> based on small crypto chips) to store secrets and perform security related
> operations, and use a widely-used, platform-independant API like
> PKCS#11/Cryptoki, now
> http://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/pkcs11-base-v2.40.html,
> thus there would be no need to implement AES (precisely a frame function
> calling e.g. intel's dedicated asm instructions), RSA and alike: An
> affordable USB crypto token (17-50 €; smart cards even less) has all that
> implemented already. The only dependency (for some operations only) would be
> on a library that implements PKCS#11 API, either specific for the hardware
> from it's vendor or the multi-platform one from the OpenSC project, which
> supports a lot of smart cards/USB tokens, itself depending on openssl.
> Thus the Crypto interface in phobos would be a smart D wrapper around the
> PKCS#11 API + some code for cases when there is no secret/private key
> involved and no PKCS#11 library support available or necessary like for "RSA
> digital signature validation".
> For the sake of fairness, it should be mentioned, that even some crypto
> chips aren't abolutely secure, free of vulnerability notes like
> https://www.kb.cert.org/vuls/id/307015. But they are the best choice I can
> think of, far better than file based secrets.
> 
> I assume You are the donor, referred to in
> https://forum.dlang.org/thread/osnema$d5s$1...@digitalmars.com. Then I 
> propose,
> You ask Andrei Alexandrescu about his and Walter's plans concerning more
> crypto in phobos, because what I read from the discussion (not all as it got
> somewhat lost in prevalent dll discussion) was prevalently expressing fear
> to touch crypto at all. It's not justified to be scary here following the
> route I proposed. In principle, even the "RSA digital signature validation"
> can completely be done by the crypto chip, but as this is a slow bottle neck
> for large messages to be hashed, it's usually done by the PKCS#11 library or
> future D code.
> 
> 'Bindings' to the PKCS#11 API are available.
> There is also the expertise of Cryptography in D - Amaury Séchet | DConf2017
> https://www.youtube.com/watch?v=CoibdYFM53U

My gut feeling is, enhancement to Phobos comes from the community. If there is
a champion with a good enhancement and the community agrees than Walter and
Andrei are likely willing to include these enhancement.

As a starting point, the signature validation could be build as independent dub
package (Boost license would be great)

--

[Issue 18298] New: curl high level form wrapper

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

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

  Issue ID: 18298
   Summary: curl high level form wrapper
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: an...@s-e-a-p.de

It would be great if std.net.curl could be enhanced with an high level wrapper
for form posts (multipart/form-data). 

A low level curl example you can see here:
https://curl.haxx.se/libcurl/c/postit2.html

--

Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Andre Pany via Digitalmars-d]

On Thursday, 25 January 2018 at 15:20:15 UTC, Benny wrote:
After months doing a different project, i need a programming 
language for a new client with specific needs. D comes to mind. 
As usual that involves downloading the compiler (dmd and ldc).


[...]


While the several tools out of the box do not work well together, 
the involved developers
did a great job (without any payment in contrast to Go/C#, 
Delphi...). I also struggled with the problem how to configure 
DCD in the DLang plugin for IntelliJ today.

This might be the reason for the items marked as unknown.
I created an issue here 
https://github.com/intellij-dlanguage/intellij-dlanguage/issues/356


The DLang ecosystem is getting better and better and you also can 
help by testing, writing constructive issues or even providing 
fixes.


Kind regards
André

[Issue 18243] selective import + overload = private visibility

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

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

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

   What|Removed |Added

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

--

[Issue 18243] selective import + overload = private visibility

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

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

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

https://github.com/dlang/dmd/commit/a71ede3ac0ab8320cbd191d0c8cac4de402ec585
Fix Issue 18243 - selective import + overload = private visibility

https://github.com/dlang/dmd/commit/ccbaaa14fa65c5066c832e222a14d190389e2470
Merge pull request #7766 from RazvanN7/Issue_18243

Fix Issue 18243 - selective import + overload = private visibility

--

[Issue 18267] Linker errors compiling std_data_json dub package with dmd 2.078.0

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

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

--- Comment #2 from Atila Neves  ---
If it's marked as `@safe` then `pure` is still an issue. At least with the very
reduced example. I think the specifics depend on the code being compiled.

--

Re: Shouldn't invalid references like this fail at compile time?

[Steven Schveighoffer via Digitalmars-d]

On 1/24/18 9:46 PM, Walter Bright wrote:

On 1/23/2018 7:22 PM, Jonathan M Davis wrote:

We need to do that anyway for the overly large
objects (and unfortunately don't last I heard).


I put a limit in at one time for struct/class sizes to prevent this 
issue, but got a lot of pushback on it and it was reverted.


Perhaps we can revisit that - and have large struct/classes be allow 
only in non-@safe code.


In general, though, if you don't have struct/class object sizes larger 
than the protected memory at null, you're safe with null dereferences.


You don't need to ban them from @safe code, what you need to do is 
determine if the field itself is beyond the zero page (which causes a 
segfault), and if so, either read from the first byte of the struct (to 
cause the segfault if it's in there), or verify the struct's address is 
not within the zero page.


We recently removed an assert for null this from all functions. Perhaps 
for structs that are large, in @safe code add that check back.


-Steve

Re: __TIMESTAMP_UNIXEPOCH__ instead of useless __TIMESTAMP__?

[Steven Schveighoffer via Digitalmars-d]

On 1/25/18 4:39 AM, Walter Bright wrote:

On 1/24/2018 11:18 AM, Timothee Cour wrote:

__TIMESTAMP__ is pretty useless:
`string literal of the date and time of compilation "www mmm dd 
hh:mm:ss "`

eg:Wed Jan 24 11:03:56 2018
which is a weird non-standard format not understood by std.datetime.


It's the format emitted by the Standard C library function asctime():

     http://pubs.opengroup.org/onlinepubs/009695399/functions/asctime.html


__DATE__ and __TIME__ are also pretty useless.


These also match the format of the Standard C preprocessor macros 
__DATE__ and __TIME__.


We should support __ISOTIMESTAMP__ which is readable by std.datetime [1].

The compiler is in D after all, we can use it! Or at least, port enough 
of std.datetime to display it :)


-Steve

[1] 
https://dlang.org/phobos/std_datetime_systime.html#.SysTime.toISOExtString

[Issue 10828] datetime toString functions should accept sink

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

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

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

   What|Removed |Added

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

--

[Issue 10828] datetime toString functions should accept sink

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

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

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

https://github.com/dlang/phobos/commit/1eeadc82d39a31db0d780413ded085e1edb1b359
Work On Issue 10828 - datetime toString functions should accept sink

https://github.com/dlang/phobos/commit/23c960177068b7156d8efff7ff08011d24f63e6d
Merge pull request #6060 from JackStouffer/date-tostring

Partially Fix Issue 10828 - Add output range version of toString functions to
std.datetime.Date
merged-on-behalf-of: Jack Stouffer 

--

Re: Explicit template instantiation in super call doesn't compile

[Steven Schveighoffer via Digitalmars-d]

On 1/25/18 8:32 AM, Jacob Carlborg wrote:

The following example will not compile:

class Foo
{
     this(T)(T a) {}
}

class C : Foo
{
     this()
     {
     super!(int)(3);
     }
}

The error is on the line of the super call:

"Error: found `!` when expecting `;` following statement"

Is this intentional or just an limitation in the grammar?


I think maybe both?

I'll note that you can't even instantiate a Foo with an explicit 
constructor call.


-Steve

Dscanner - DCD - Dfix ... Editor support or the lack of it.

[Benny via Digitalmars-d]

After months doing a different project, i need a programming 
language for a new client with specific needs. D comes to mind. 
As usual that involves downloading the compiler (dmd and ldc).


So, lets install Visual Studio Code:

* Code-D Plugin:
  - Syntax highlight *check*
  - After saving: DMD error suggestions in the code. *check*
  - Limited name suggestion ( VSC functionality not the plugin ) 
only by forcing VSC (ctrl+space).

  - ... and nothing else...


So lets try the next plugin:


* Serve-D Plugin:
  - Syntax highlight *check*
  - After saving: DMD error suggestions in the code. *check*
  - Limited name suggestion ( VSC functionality not the plugin ) 
only by forcing VSC (ctrl+space).

  - ... and nothing else...


Frustration level increasing. Lets try the next one:


* D-Language Plugin:
  - Syntax highlight *check*
  - Limited name suggestion ( VSC functionality not the plugin ) 
only by forcing VSC (ctrl+space).

  - ... and nothing else...


Ok ... so Visual Studio Code its Dscanner, DCD, Workspace-d do 
not properly work or some other issue.



Then lets try IntelliJ Community Edition. After a long time 
getting all the dependancies and compiling them... Dscanner - DCD 
( client and server ) - Dfix ...



* D Language Plugin:
  - Syntax highlight *check*
  - Way too many items like writefln, import etc all being marked 
as unknown. Clearly wrong.

  - ... and nothing else...
  - Socket error (std.socket.xxx) on closing IntelliJ


Conclusion is that it feels like the whole D infrastructure is 
very, very poorly supported.


Other issues like delays that some of the D plugins seem to 
introduce:


* Like "loading ..." popups that do nothing but always show up ( 
Visual Studio Code )
* Like pressing "dot" expecting a response, waiting 2 seconds and 
then finally something happening ( IntelliJ plugin ) but simply 
dumping every possible name and variable ( zero intelligent code 
support )


I assume that this is again broken DCD or Dscanner.

And no, no errors in the console of VSC or anything like that.

Let me summarize my personal D editor experience in the last 1+ 
year.


* Attempts at getting D editor support going: 6 or 7.
* Amount of times things worked out of the box. One! And this was 
limited to about a few minutes and after that all suggestions 
broke again.
* Amount of times dscanner or dcd or other plugins broke because 
of DMD newest version broke: 4
* Tested on different machines: 4! They all have one thing in 
common: Windows 10

* Tested on different Windows installations: 3
* Tested on different "version" of Windows 10: 3
* Amount of times complaining to the plugin authors: Too many to 
count.

* Time spend on these tests / issues: Easily 50 hours or more.
* Frustration level: Again, like each time before EXTREME!

Please do not give me the company line that i need to report 
issues. I did so many times. It is tiring playing guinea pig, 
complaining and reporting, waiting for things to get fixed and 
still seeing things break again or simply not working properly.



I can download Go, C#, C, C++, Delphi, Rust and get proper 
working plugins for the above mentioned editors but D is always 
that frustrating problem child. And i can not blame the plugin 
authors because the issues always seem to stem from the D plugins 
( dcd, dscanner, ... ).


Like dscanner changing its binary location between builds from 
folder root to /bin folder, breaking the plugin authors there 
system as it expected it in the folder root.


Maybe things work great in a few very specific editor but in my 
personal experience, D its editor support is non stop 
frustrating. And i suspect that this complaint is not new.


Clearly there is infrastructure in place for automated testing 
the compiler but it feels like there is a total lack of 
infrastructure for everything that surround it. Beyond maybe a 
few editors that the core team uses?


My personal opinion: Too much in the D landscape is so 
individualist and not properly cross platform tested, that it 
results in pure frustration for the end developer.

[Issue 13736] Spellchecker should prefer symbols from inner scopes

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

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

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |FIXED

--

[Issue 11044] Escaping references to lazy argument are allowed

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

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

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--

[Issue 8845] Can't pass immediate or rvalue args to ref function parameters

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

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

Carsten Blüggel  changed:

   What|Removed |Added

 CC||chi...@posteo.net

--

[Issue 17119] Broken URL for compiler switch -dip1000

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

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

Carsten Blüggel  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||chi...@posteo.net
 Resolution|--- |FIXED

--- Comment #1 from Carsten Blüggel  ---
Fixed since v2.078.1

--

Re: static weirdness

[Steven Schveighoffer via Digitalmars-d-learn]

On 1/25/18 8:24 AM, Mike Parker wrote:

On Thursday, 25 January 2018 at 12:58:12 UTC, Jonathan M Davis wrote:

Thinking about it, I do vaguely recall a discussion sometime last year 
about an invariant being invisibly inserted under some set of 
circumstances. Maybe that's what's happening? I believe that it was 
complained about in that discussion, so maybe it was removed after 
that. Certainly, if I try that code locally with master, it runs just 
fine without hitting any assertions.



https://dlang.org/changelog/2.077.0.html#removePreludeAssert


I think that changelog is wrong. The prelude assert was added I think to 
all member calls. And it has been removed.


-Steve

[Issue 12511] static overloaded function is not accessible

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

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

RazvanN  changed:

   What|Removed |Added

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

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

--

Re: Release D 2.078.1

[Atila Neves via Digitalmars-d-announce]

On Tuesday, 23 January 2018 at 15:16:02 UTC, Andre Pany wrote:

On Tuesday, 23 January 2018 at 13:08:35 UTC, thedeemon wrote:

On Monday, 22 January 2018 at 20:43:56 UTC, Martin Nowak wrote:

Glad to announce D 2.078.1.



The Windows 7z archive version now has much simpler sc.ini, in 
fact too simple.

With Visual C++ 2015 x64 Native Build Tools now trying to run
dmd -m64 hi.d
I get
LINK : fatal error LNK1104: cannot open file 'libucrt.lib'
Error: linker exited with status 1104

So I needed to edit sc.ini and add back
LIB=%LIB%;"%UniversalCRTSdkDir%\Lib\%UCRTVersion%\ucrt\x64"
to the [Environment64] section.

Then it went just as 2.078.0 - still missing 
legacy_stdio_definitions.lib that I need to add manually in 
the command line.


Did you call vcvarsall in the current dos box/PowerShell? It is 
a tool included with all visual studio variants.


Kind regards
Andre


I just ran into this today. With the dmd 2.077.1 Windows 
installer things just work, and it's never necessary to call 
vcvarsall.bat to build D code for 64-bit.


Since dmd 2.078.0, with Visual Studio 2015, nothing works 
anymore, and sc.ini doesn't seem to reference Visual Studio at 
all like it used to.


Atila

Re: The Eve programming language project is winding down

[Jacob Carlborg via Digitalmars-d]

On 2018-01-25 05:13, Andrei Alexandrescu wrote:

https://news.ycombinator.com/item?id=16227130


Looks like Swift playgrounds [1]

[1] https://developer.apple.com/swift-playgrounds/

--
/Jacob Carlborg

Explicit template instantiation in super call doesn't compile

[Jacob Carlborg via Digitalmars-d]

The following example will not compile:

class Foo
{
this(T)(T a) {}
}

class C : Foo
{
this()
{
super!(int)(3);
}
}

The error is on the line of the super call:

"Error: found `!` when expecting `;` following statement"

Is this intentional or just an limitation in the grammar?

--
/Jacob Carlborg

Re: static weirdness

[Mike Parker via Digitalmars-d-learn]

On Thursday, 25 January 2018 at 12:58:12 UTC, Jonathan M Davis 
wrote:


Thinking about it, I do vaguely recall a discussion sometime 
last year about an invariant being invisibly inserted under 
some set of circumstances. Maybe that's what's happening? I 
believe that it was complained about in that discussion, so 
maybe it was removed after that. Certainly, if I try that code 
locally with master, it runs just fine without hitting any 
assertions.



https://dlang.org/changelog/2.077.0.html#removePreludeAssert

Re: BitFlags usage

[Alex via Digitalmars-d-learn]

On Thursday, 25 January 2018 at 13:05:07 UTC, Ali Çehreli wrote:

On 01/25/2018 03:50 AM, Alex wrote:

     r |= cast(BitFlags!Rs)val; // line 20 ... from 
asignment


r |= BitFlags!Rs(cast(Rs)val);

Ali


Thanks :)

Re: BitFlags usage

[Ali Çehreli via Digitalmars-d-learn]

On 01/25/2018 03:50 AM, Alex wrote:


     r |= cast(BitFlags!Rs)val; // line 20 ... from asignment


r |= BitFlags!Rs(cast(Rs)val);

Ali

[Issue 18297] New: Prelude assert removed from all methods

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

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

  Issue ID: 18297
   Summary: Prelude assert removed from all methods
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: dfj1es...@sneakemail.com

https://github.com/dlang/dmd/pull/6982 says to remove assert from constructors
and destructors, but actually removes it from all methods. Is it intended?

--

Re: static weirdness

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, January 25, 2018 12:42:57 Kagamin via Digitalmars-d-learn 
wrote:
> See https://ideone.com/VZ97dh

I don't know what's going on there. Such an assertion does not seem in line
with what Walter has typically said on the subject.

Thinking about it, I do vaguely recall a discussion sometime last year about
an invariant being invisibly inserted under some set of circumstances. Maybe
that's what's happening? I believe that it was complained about in that
discussion, so maybe it was removed after that. Certainly, if I try that
code locally with master, it runs just fine without hitting any assertions.

- Jonathan M Davis

Re: static weirdness

[Kagamin via Digitalmars-d-learn]

See https://ideone.com/VZ97dh

Re: static weirdness

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, January 25, 2018 12:38:25 Kagamin via Digitalmars-d-learn 
wrote:
> On Thursday, 25 January 2018 at 12:06:07 UTC, Jonathan M Davis
>
> wrote:
> > Actually, assert on a pointer to a struct or a reference to a
> > class checks for null _and_ calls the invariant, and that
> > hasn't changed. But you have to actually assert the pointer or
> > reference if you want to do that, and the OP didn't do that. He
> > asserted whether it == null.
>
> I mean the compiler implicitly inserted a check like:
> struct S
> {
>  auto fun()
>  {
>   assert(!=null);
>   return 42;
>  }
> }

AFAIK, it has never done that. Walter's stance on null pointers has always
been that that's what segfaults are for, and he's against adding any
additional null checks.

- Jonathan M Davis

Re: static weirdness

[Kagamin via Digitalmars-d-learn]

On Thursday, 25 January 2018 at 12:06:07 UTC, Jonathan M Davis 
wrote:
Actually, assert on a pointer to a struct or a reference to a 
class checks for null _and_ calls the invariant, and that 
hasn't changed. But you have to actually assert the pointer or 
reference if you want to do that, and the OP didn't do that. He 
asserted whether it == null.


I mean the compiler implicitly inserted a check like:
struct S
{
auto fun()
{
assert(!=null);
return 42;
}
}

[Issue 18267] Linker errors compiling std_data_json dub package with dmd 2.078.0

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

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

--- Comment #1 from anonymous4  ---
opEquals changes attributes based on debug switch? What if it's marked as
@safe?

--

[Issue 11766] private renamed import conflicts with external module function call

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

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

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from RazvanN  ---
This has been solved in git HEAD. Closing as fixed

--

Re: static weirdness

[Alex via Digitalmars-d-learn]

On Thursday, 25 January 2018 at 12:06:07 UTC, Jonathan M Davis 
wrote:
On Thursday, January 25, 2018 10:17:34 Kagamin via 
Digitalmars-d-learn wrote:

On Wednesday, 24 January 2018 at 02:01:54 UTC, Jonathan M Davis

wrote:
> (so there's no need to dereference the pointer to call it)

It used to check this pointer with an assert. When did it 
change?


Actually, assert on a pointer to a struct or a reference to a 
class checks for null _and_ calls the invariant, and that 
hasn't changed. But you have to actually assert the pointer or 
reference if you want to do that, and the OP didn't do that. He 
asserted whether it == null.


- Jonathan M Davis


Yeah... the cool thing is, that if the function does not need 
anything from the referenced object, then the pointer 
"degenerates" to a "namespace" implicitly... sorry, for strange 
wording.


It seems that this behavior changed from 2.076.1 to 2.077.

[Issue 16510] Request: RSA digital signature validation in phobos

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

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

--- Comment #6 from Carsten Blüggel  ---
(In reply to anonymous4 from comment #5)
> Signature validation uses only public key

Wikipedia is helpful.

> there's no need for any secret access.

I didn't claim that for Signature validation. Again, consider all of my reply
beginning with "All of the discussion in ... " referring to
https://issues.dlang.org/show_bug.cgi?id=17958. It's hard for me to see what is
capable of being misunderstood in my reply.

--

Re: static weirdness

[Alex via Digitalmars-d-learn]

On Thursday, 25 January 2018 at 10:17:34 UTC, Kagamin wrote:
On Wednesday, 24 January 2018 at 02:01:54 UTC, Jonathan M Davis 
wrote:

(so there's no need to dereference the pointer to call it)


It used to check this pointer with an assert. When did it 
change?


Fortunately, I have some compilers here and just tested it. 
2.076.1 results in a segmentation fault, whereas 2.077.0 does not.

Re: static weirdness

[Jonathan M Davis via Digitalmars-d-learn]

On Thursday, January 25, 2018 10:17:34 Kagamin via Digitalmars-d-learn 
wrote:
> On Wednesday, 24 January 2018 at 02:01:54 UTC, Jonathan M Davis
>
> wrote:
> > (so there's no need to dereference the pointer to call it)
>
> It used to check this pointer with an assert. When did it change?

Actually, assert on a pointer to a struct or a reference to a class checks
for null _and_ calls the invariant, and that hasn't changed. But you have to
actually assert the pointer or reference if you want to do that, and the OP
didn't do that. He asserted whether it == null.

- Jonathan M Davis

[Issue 18281] Compiler rejects safe code in @safe

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

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

--- Comment #3 from anonymous4  ---
(In reply to Nick Treleaven from comment #2)
> dmd can't infer scope
That's what I mean: the code is safe, but the compiler is not smart enough to
figure it out. There's no such requirement that there must be safe code that
must not ever be recognized as safe, and dip1000 is the primary example of
that: language rules can be extended to accept more safe code, effectively it's
prone to "can't say no" problem.

--

BitFlags usage

[Alex via Digitalmars-d-learn]

I have a question on usage of BitFlags, described here:
https://dlang.org/library/std/typecons/bit_flags.html

and/or on bitop
https://dlang.org/phobos/core_bitop.html#.bsf

A similar example to the bit flags example is given here:

[code]
import std.typecons;
enum Rs : ubyte
{
None,
s_f = 1 << 0,
s_s = 1 << 1,
s_p = 1 << 2,
t_f = 1 << 3,
t_s = 1 << 4,
t_p = 1 << 5
}

struct R
{
import core.bitop : popcnt;
invariant {/* some useful asserts here */}
this(ubyte val)
{
assert(popcnt(cast(uint)val) == 2); // separate asserts...
r |= cast(BitFlags!Rs)val; // line 20 ... from asignment
}
BitFlags!Rs r;  
alias r this;
}

void main(){}
[/code]

ok, now: the idea is that if I use the functionality of bit 
flags, then I can take advantage of bit operations. And I'm 
looking for the inverse operation of converting a bit flag to its 
raw value, like the line before last in the example on the bit 
flags documentation site.


How should my line 20 looks like to achieve an assignment of a 
raw value to a BitFlags variable in a single step?

[Issue 11731] private enum behavior

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

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

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |FIXED

--- Comment #2 from RazvanN  ---
The code now errors. Closing as fixed.

--

[Issue 11731] private enum behavior

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

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

--- Comment #3 from RazvanN  ---
Tested on ubunt 16.04 with git HEAD

--

[Issue 16294] import treated as public import

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

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

RazvanN  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||razvan.nitu1...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from RazvanN  ---
This has been fixed by : https://github.com/dlang/dmd/pull/7760 . The code
issues a deprecation now.

Closing as fixed.

--

[Issue 16510] Request: RSA digital signature validation in phobos

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

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

--- Comment #5 from anonymous4  ---
Signature validation uses only public key, there's no need for any secret
access.

--

Re: static weirdness

[Kagamin via Digitalmars-d-learn]

On Wednesday, 24 January 2018 at 02:01:54 UTC, Jonathan M Davis 
wrote:

(so there's no need to dereference the pointer to call it)


It used to check this pointer with an assert. When did it change?

Re: __TIMESTAMP_UNIXEPOCH__ instead of useless __TIMESTAMP__?

[Walter Bright via Digitalmars-d]

On 1/24/2018 11:18 AM, Timothee Cour wrote:

__TIMESTAMP__ is pretty useless:
`string literal of the date and time of compilation "www mmm dd hh:mm:ss "`
eg:Wed Jan 24 11:03:56 2018
which is a weird non-standard format not understood by std.datetime.


It's the format emitted by the Standard C library function asctime():

http://pubs.opengroup.org/onlinepubs/009695399/functions/asctime.html


__DATE__ and __TIME__ are also pretty useless.


These also match the format of the Standard C preprocessor macros __DATE__ and 
__TIME__.

[Issue 13006] Allow inout return type without inout parameters

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

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

Mike Franklin  changed:

   What|Removed |Added

 CC||slavo5...@yahoo.com

--- Comment #2 from Mike Franklin  ---
This feature requires a DIP.  See discussion at
https://github.com/dlang/dmd/pull/3740

--

Trying to program USB device using STM32F

[Amilia via Digitalmars-d]

I'm using STM32F745(can be found in kynix: http://www.kynix.com) 
on my own board, and I am trying to program USB device (I tried 
virtual COM and HID, separately).


But after plugging into PC it is detected (after a while) with 
"Unknown device (device descriptor request failed)" error.


Electrically (PCB):
I think that PCB is not an error here - I just have D+ and D- 
short tracks from the connector to the uC and that's all.
I have a pull-up 1.5k (I tried with and without it), but it is 
not even needed in STM32. I have check connection and a cable and 
I'm certain it connects.


Code:

I'm using HAL and STM32CubeMx generated code merged with my 
project. Generally programs freezes.


1) After executing line (from library code) USBx->GAHBCFG |= 
USB_OTG_GAHBCFG_GINT;. I know that, as I tried printing before 
and after that line and only first printf() prints. I don't 
understand how the program can stuck there.
Anyway, if I disable VBUS sensing then the program doesn't get 
stuck there and the whole MX_USB_DEVICE_Init finishes.


2) But then, program executes few cycles (for example, it will 
print "done" and lit the LED) and after that it freezes. 
Completely. This LED should blink in an infinite loop, but it 
doesn't. I have other LED to be enabled in all error handlers 
(like hard fault etc.) and it seems that the the program doesn't 
go there (as the LED is off), so I don't understand where it get 
stuck.


*After virtual COM, I tried HID but to no avail. It gives me 
the same behavior.
*If I power the board from the charger (not PC) then the 
program doesn't get stuck.

Re: Channeling memory model experts...

[Kagamin via Digitalmars-d]

On Wednesday, 24 January 2018 at 18:37:54 UTC, Andrei 
Alexandrescu wrote:
... to review https://github.com/dlang/druntime/pull/2057/. 
Thanks! -- Andrei


Is there a way to have 2 threads without initialized GC?