Re: reduce mangled name sizes via link-time symbol renaming
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
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
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.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
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?
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.
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?
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.
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: Dscanner - DCD - Dfix ... Editor support or the lack of it.
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
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)
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
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.
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
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.
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.
Re: Implementing tail-const in 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: Dscanner - DCD - Dfix ... Editor support or the lack of it.
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).
Re: String Switch Lowering
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: String Switch Lowering
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
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
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
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
_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_417369612f5161746172VxQBLna10_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_4575726f70652f526f6d65VxQCWva11_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_4575726f70652f566164757aVxQEMpa12_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_416d65726963612f5468756c65VxQFYva13_417369612f4173686761626174VxQGAfa13_417369612f43616c6375747461VxQGBpa13_417369612f44616d6173637573VxQGCza13_417369612f44757368616e6265VxQGEja13_417369612f4a61796170757261VxQGFta13_417369612f4b61746d616e6475VxQGHda13_417369612f4b68616e64796761VxQGIna13_417369612f4d616b6173736172VxQGJxa13_417369612f53616b68616c696eVxQGLha13_417369612f5368616e67686169VxQGMra13_417369612f546173686b656e74VxQGOba13_417369612f5573742d4e657261VxQGPla13_4575726f70652f417468656e73VxQGQva13_4575726f70652f4265726c696eVxQGSfa13_4575726f70652f4475626c696eVxQGTpa13_4575726f70652f4a6572736579VxQGUza13_4575726f70652f4c6973626f6eVxQGWja13_4575726f70652f4c6f6e646f6eVxQGXta13_4575726f70652f4d6164726964VxQGZda13_4575726f70652f4d6f6e61636fVxQHAna13_4575726f70652f4d6f73636f77VxQHBxa13_4575726f70652f507261677565VxQHDha13_4575726f70652f53616d617261VxQHEra13_4575726f70652f536b6f706a65VxQHGba13_4575726f70652f546972616e65VxQHHla13_4575726f70652f5669656e6e61VxQHIva13_4575
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
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é
Re: Shouldn't invalid references like this fail at compile time?
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__?
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
Re: Explicit template instantiation in super call doesn't compile
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.
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.
Re: The Eve programming language project is winding down
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
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: __TIMESTAMP_UNIXEPOCH__ instead of useless __TIMESTAMP__?
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__.
Trying to program USB device using STM32F
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...
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?
