Re: String Switch Lowering
On 1/25/2018 10:21 AM, Benjamin Thaut wrote: 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. 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? This clearly should be in bugzilla.
Re: The Eve programming language project is winding down
On Fri, Jan 26, 2018 at 10:26:02PM +, Jesse Phillips via Digitalmars-d wrote: > On Thursday, 25 January 2018 at 04:13:29 UTC, Andrei Alexandrescu wrote: > > https://news.ycombinator.com/item?id=16227130 > > http://eve-lang.com/ > > Not quite the point of the language, but it is funny that it uses D's > old "compilable HTML" > > And from what I saw in their introduction page, the language wasn't > really that simple either. I like declarative programing, but I just > wasn't feeling the connection between the declarations. > > Maybe it is because I know what a browser has to do, but I don't see > how binding a DIV to a browser makes anything happen. I also don't > know what I'm suppose to expect to happen. > > And they still didn't eliminate the need to understand working with a > browser, DIV, what is that, why am I using it in my programming > language. As Walter once said: I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem. In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright T -- "The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."
functions allowed to overload on const int vs int vs immutable int? + spec is not accurate
this compiles, but equivalent in C++ (const int vs int) would give a
compile error (error: redefinition of 'fun'); what's the rationale for
allowing these overloads?
```
void fun(int src){ writeln2(); }
void fun(immutable int src){ writeln2(); }
void fun(const int src){ writeln2(); }
void main(){
{int src=0; fun(src);} // matches fun(int)
{immutable int src=0; fun(src);} // matches fun(immutable int)
{const int src=0; fun(src);} // matches fun(const int)
}
```
The spec does mention `match with conversion to const` taking
precedence over `exact match` however this isn't precise: the
following would be more precise instead (at least according to snippet
above):
`match with conversion to/from const/immutable/mutable`
https://dlang.org/spec/function.html#function-overloading
Functions are overloaded based on how well the arguments to a function
can match up with the parameters. The function with the best match is
selected. The levels of matching are:
no match
match with implicit conversions
match with conversion to const
exact match
Re: gRPC in D good idea for GSOC 2018?
for grpc, we should add to dproto (which is pretty good protobuf library for D but lacks grpc) instead of starting from scratch, see https://github.com/msoucy/dproto/issues/113 [your advice/opinions on integrating with grpc?] On Mon, Jan 22, 2018 at 12:24 PM, Adrian Matoga via Digitalmars-d wrote: > On Monday, 15 January 2018 at 19:28:08 UTC, Ali Çehreli wrote: >> >> I know a project where D could benefit from gRPC in D, which is not among >> the supported languages: >> >> https://grpc.io/docs/ >> >> Do you think gRPC support is worth adding to GSOC 2018 ideas? >> >> https://wiki.dlang.org/GSOC_2018_Ideas >> >> Ali > > > I can share a fresh experience from mentoring a student in a similar (also > RPC) project last summer. We built native D-Bus bindings in D based on > libasync. The student had had no previous experience with D or RPC, and > within ~2.5 months of focused work she implemented the following: > > 1. (de)serialization of all D-Bus data types, including the use of > compile-time reflection to recursively marshall structs, arrays, and > variants. Except Variant, for which we decided to make our own > D-Bus-specific tagged union type, all other D-Bus types are mapped to > built-in D types. > 2. A class to connect to the bus via libasync sockets, read the incoming > messages and dispatch them to the registered handlers, and send messages to > the bus. > 3. Proxy (client) and server class templates that generate all the code > necessary to make the remote calls look almost like local ones (the return > value/out arguments are passed to a delegate that handles the output instead > of being returned synchronously). > > So, more or less an equivalent of vibe.d's REST interface generator, only > with fewer customization points. > > There were still some opportunities for refactorings and optimizations, so I > wouldn't consider it production ready. Also, some planned features weren't > implemented, such as a more convenient way for handling signals or allowing > transports other than unix sockets on libasync. On the other hand, what we > have is almost 100% covered with unit tests. This not only made adding > successive layers quite pleasant, as little (if any) debugging of previously > written stuff was ever necessary, but also helps to keep the stuff working > as we modify it. > > Based on my experience, I'd say that implementing gRPC may be of a right > size for a GSoC project, as long as you split it into smaller > components/layers, prioritize them, and focus on having at least the basic > stuff usable and tested, instead of expecting it to cover all usage cases > and be heavily optimized. >
Re: DMD as a library package can now run through all semantic phases
On 26/01/2018 6:40 PM, Seb wrote:
In case someone wants to play with DMD as a library, it got a lot easier
as of today.
Here's an example:
```
#!/usr/bin/env dub
/+dub.sdl:
dependency "dmd" version="~master"
+/
void main()
{
import dmd.frontend;
import std.algorithm : each;
import std.stdio;
// Sets DMD's global variables. Only required to be called once
// In the future this might be done automatically (e.g. module
constructor or initOnce)
initDMD;
// Search for the predefined import paths of your host compiler
(DMD and LDC are supported)
findImportPaths.each!addImport;
// Load a module
// (if no second argument is given, the file will be opened and read)
auto m = parseModule("test.d", q{
void foo()
{
foreach (i; 0..10) {}
}
});
// Run through all semantic phases
m.fullSemantic;
m.prettyPrint.writeln;
}
```
Want to know what it prints? Run the file!
Spoiler: it's similar to new the AST feature at run.dlang.io:
https://run.dlang.io/is/mwU67O
__Warning__: the DMD DUB package is still experimental and at the moment
should only be used by alpha warriors.
See also:
https://dlang.org/phobos-prerelease/dmd_frontend.html (will work soon)
https://dlang.org/library-prerelease/dmd/frontend.html (Ddox
documentation, works already)
Huge thanks and credits goes to Jacob Carlborg and Razvan Nitu as well.
Is it possible to reset the compiler to the point of uninitialized/newly
initialized?
For reuse in a single process.
Re: Shouldn't invalid references like this fail at compile time?
On Fri, Jan 26, 2018 at 04:36:18AM -0700, Jonathan M Davis via Digitalmars-d wrote: > On Thursday, January 25, 2018 17:20:21 H. S. Teoh via Digitalmars-d wrote: > > 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 > > Well at least you don't have to program in Java. :) > > Unless something has changed in one of the recent versions, you can't > even write a swap function in Java. :| I haven't touched Java in a long while, but the last time I looked, it wasn't too horrible of a language. Needlessly verbose, yes. Breaks DRY, yes. Shoehorns everything into an OO model, even where it doesn't fit, yes. But in terms of the language itself, it's kinda pretty in its own way, even if it's in an idealistic, detached-from-the-real-world kind of way. At least you're not worried about buffer overruns, memory leaks, and inscrutible pointer bugs that could literally be *anywhere* in the entire 20,000-file codebase. Overall, I'd say Java is an OK language, not horrible, but not that great either. The only thing that makes it shine is really the wealth of libraries out there that you can draw from. I'd rate it as a "meh", whereas C is pretty horrible in spite of being extremely powerful, and C++ is just masochistic (though I confess I haven't looked into its latest incarnations -- the C++ code I have to work with dates back to C++98 and probably isn't going to change anytime in the foreseeable future). > It's definitely painful to have to program in C++ after programming in > D, but I still find C++ to be more pleasant than the alternatives > other than D. [...] I'm torn between whether C or C++ is worse. In some ways, I actually prefer C because the language is smaller, the semantics are more straightforward, and the potential dangers are well-known and well-studied. It doesn't lessen the pain, but at least you have well-established maps with which to navigate through the minefield. C++, OTOH... perhaps my opinion is biased by having had the misfortune of working with an overengineered, overdesigned C++ codebase that exemplified all the flaws of C++ and none of its advantages (thankfully, said codebase has been replaced... good riddance *shudder*). But when you're dealing with code where useful work is done inside dtors and where making a conceptual function call involves 6 layers of abstraction, one step of which involves fwrite()'ing parameters into a temporary file and fread()'ing from the other end, the only thing that can possibly come to mind is "where's my 10-foot pole and why am I not using it", and "is it even humanly possible to understand what this code actually does?!". C++ is just far too big, far too complex for any mortal to fully comprehend, and that's not even beginning to touch the semantics of a convoluted codebase that abuses the language in every possible way. No thanks, if I had the choice, I'm staying away from C++ as far as I possibly can. T -- MAS = Mana Ada Sistem?
Re: reduce mangled name sizes via link-time symbol renaming
On Fri, Jan 26, 2018 at 08:34:50AM +0100, Johannes Pfau via Digitalmars-d wrote: [...] > 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. I think this is something worthwhile to implement, or at least try out. Huge symbols have been an ongoing source of trouble in D code, esp. when there's heavy template usage. Even after Rainer's symbol backref PR was merged, which largely alleviated the recursive symbol bloat problem, we still have cases like object.__switch that need to be addressed. > 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. [...] I dunno, I'm skeptical that a 10,000-character symbol is of any use to anyone, even for debugging. I mean, what are you going to do with it? Visually scan 10,000 characters to see if it's the same symbol as another 10,000-character symbol in the program? If the only way to make practical use of it is to use a program to compare it, then substituting it with a hash is not any different. It seems to me that the most useful parts of a long symbol are basically its initial segment, which is usually the module name, useful for narrowing down where the symbol came from, and the ending segment, usually the last symbol(s) of a UFCS chain, or some argument types, useful for determining the function name, or which overload is being called. Given a long enough symbol, the middle portion is pretty much never looked at; it might as well be random characters. Which suggests the following scheme: if a symbol S exceeds N characters, for a suitably-chosen N (I'd say somewhere around 500 or 1000, as a rough initial stab), then replace it with: S[0 .. 80] ~ hashOf(s) ~ S[$-80 .. $] This gives you 160 human-readable characters of the most useful parts of the symbol, with the largely-useless middle part replaced with a fixed-length hash, so in the worst case, the symbol will be around 2-3 lines long and no more. I chose 80 arbitrarily, it can be longer or shorter, but it's approximately the length of 1 line of code, which presumably should be enough to uniquely identify the source module of the symbol as well as the last function name / parameter types. Perhaps it can be increased to about 200 or so, give or take, so that compressed symbols are approximately N characters long. Or N can be reduced to match the 160 + the ASCII-encoded size of the hash. T -- In a world without fences, who needs Windows and Gates? -- Christian Surchi
Re: DMD as a library package can now run through all semantic phases
On Friday, 26 January 2018 at 18:40:23 UTC, Seb wrote:
Want to know what it prints? Run the file!
Spoiler: it's similar to new the AST feature at run.dlang.io:
prettyPrint produces valid D code except for template
instantiations:
```
writeln!int
{
@safe void writeln(int _param_0)
{
import std.traits : isAggregateType;
((File __tmpfordtor37 = trustedStdout();) ,
__tmpfordtor37).write(_param_0, '\x0a');
}
}
```
why not write something like:
```
template writeln(T:int)
{
...
}
```
or template writeln(T) if(is(T==int))
Re: DMD as a library package can now run through all semantic phases
On Saturday, 27 January 2018 at 01:10:35 UTC, timotheecour wrote: On Saturday, 27 January 2018 at 00:47:01 UTC, timotheecour the bug is that homebrew dmd installs dmd.conf in /Users/timothee/homebrew/etc/dmd.conf; findDMDConfig should instead look for dmd.conf by calling `dmd -v|grep 'Config file'` (and caching result for each file+time_last_modified) which would be more robust workaround: hardcode /Users/timothee/homebrew/etc/dmd.conf in findDMDConfig in dmd:src/dmd/frontend.d Actually an even more robust way to get the conf file: call dmd -Xf=tempfile and get it from json output doable once https://github.com/dlang/dmd/pull/7757 is accepted
Re: DMD as a library package can now run through all semantic phases
On Saturday, 27 January 2018 at 00:47:01 UTC, timotheecour wrote: on OSX: chmod u+x main.d ./main.d WARNING: A deprecated branch based version specification is used for the dependency dmd. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. Invalid source/import path: /Users/timothee/.dub/packages/dmd-master/dmd/generated/dub core.exception.AssertError@../../../../../.dub/packages/dmd-master/dmd/src/dmd/frontend.d(208): No valid config found. the bug is that homebrew dmd installs dmd.conf in /Users/timothee/homebrew/etc/dmd.conf; findDMDConfig should instead look for dmd.conf by calling `dmd -v|grep 'Config file'` (and caching result for each file+time_last_modified) which would be more robust workaround: hardcode /Users/timothee/homebrew/etc/dmd.conf in findDMDConfig in dmd:src/dmd/frontend.d
Re: DMD as a library package can now run through all semantic phases
On Saturday, 27 January 2018 at 01:25:18 UTC, timotheecour wrote:
On Friday, 26 January 2018 at 18:40:23 UTC, Seb wrote:
Want to know what it prints? Run the file!
Spoiler: it's similar to new the AST feature at run.dlang.io:
prettyPrint produces valid D code except for template
instantiations:
```
writeln!int
{
@safe void writeln(int _param_0)
{
import std.traits : isAggregateType;
((File __tmpfordtor37 = trustedStdout();) ,
__tmpfordtor37).write(_param_0, '\x0a');
}
}
```
why not write something like:
```
template writeln(T:int)
{
...
}
```
or template writeln(T) if(is(T==int))
Agreed, but prettyPrint:
https://github.com/dlang/dmd/blob/master/src/dmd/frontend.d#L275
is just a nice wrapper around the existing PrettyPrintVisitor:
https://github.com/dlang/dmd/blob/master/src/dmd/hdrgen.d#L84
Re: DMD as a library package can now run through all semantic phases
On Saturday, 27 January 2018 at 01:36:17 UTC, Seb wrote: On Saturday, 27 January 2018 at 01:25:18 UTC, timotheecour Agreed, but prettyPrint: https://github.com/dlang/dmd/blob/master/src/dmd/frontend.d#L275 is just a nice wrapper around the existing PrettyPrintVisitor: https://github.com/dlang/dmd/blob/master/src/dmd/hdrgen.d#L84 filed https://issues.dlang.org/show_bug.cgi?id=18311
Re: DMD as a library package can now run through all semantic phases
On Saturday, 27 January 2018 at 00:47:01 UTC, timotheecour wrote: on OSX: chmod u+x main.d ./main.d WARNING: A deprecated branch based version specification is used for the dependency dmd. Please use numbered versions instead. Also note that you can still use the dub.selections.json file to override a certain dependency to use a branch instead. That's expected, but well DMD doesn't use semantic versioning yet, so ~master is the only valid version out there. Invalid source/import path: /Users/timothee/.dub/packages/dmd-master/dmd/generated/dub core.exception.AssertError@../../../../../.dub/packages/dmd-master/dmd/src/dmd/frontend.d(208): No valid config found. That's not expected (and before OSX went crazy on Travis there where tests for this). What's your default compiler? How did you install it? If it's dmd, then DMD's default detection is called: https://github.com/dlang/dmd/blob/master/src/dmd/frontend.d#L82
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Saturday, 27 January 2018 at 00:13:51 UTC, Benny wrote: On Saturday, 27 January 2018 at 00:08:17 UTC, Benny wrote: * Rust: Jetbrain IntelliJ + Rust plugin. It looks like it has become a official supported plugin by Jetbrain. Works perfectly out of the box. Impressive results and issue hinting. https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/ Yep, i was right. Its now a official support plugin by Jetbrain. And no offense but i doubt it has anything to do with Mozilla officially backing Rust but more a sign of popularity. Just as how Go got its own Editor by Jetbrain. My impression so far is that most of the D users love to program in a tiny editor without the features which modern IDE's gives you. That's impressive, but outdated and even a bit silly if the project is bigger. In any company I've been so far we've used IDE's, because their feature-set and tools take so much work away from you - I don't want to miss them anymore. Nowadays, the majority of programmers who are willing to try new/others programming languages, think so too. I'm somewhat sure that this unneccessary hurdle is one of D's biggest mistakes.
Re: How programmers transition between languages
On Friday, 26 January 2018 at 17:24:54 UTC, Benny wrote: What i found interesting is the comparison between the "newer" languages and D ( see the reddit thread ). 9 Go 4.1022 15 Kotlin 1.2798 18 Rust0.7317 35 Julia 0.0900 46 Vala0.0665 50 Crystal 0.0498 53 D 0.047% While i can understand Rust ( Mozilla ), Kotlin ( Jetbrain ), Go ( Google ). Even Vala and Crystal are ranked higher then D. Yes, those stats are interesting too, but Go seems to do much better than Rust. And if the trend is that people move from Rust to Go and from Go to Python it might mean that people might start out trying out new languages with performance goals in mind, but eventually go for productivity when they realize that they pay a fairly high price for those performance gains? Anyway, with Python 3.6 you get fairly good type annotation capabilities which allows static type checking that is closing on what you get with statically typed languages. Maybe that is a factor too.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Saturday, 27 January 2018 at 00:08:17 UTC, Benny wrote: * Rust: Jetbrain IntelliJ + Rust plugin. It looks like it has become a official supported plugin by Jetbrain. Works perfectly out of the box. Impressive results and issue hinting. https://blog.jetbrains.com/blog/2017/08/04/official-support-for-open-source-rust-plugin-for-intellij-idea-clion-and-other-jetbrains-ides/ Yep, i was right. Its now a official support plugin by Jetbrain. And no offense but i doubt it has anything to do with Mozilla officially backing Rust but more a sign of popularity. Just as how Go got its own Editor by Jetbrain.
Re: How programmers transition between languages
On Friday, 26 January 2018 at 20:31:30 UTC, John Gabriele wrote: With Rust's extra complexity (over D) of ownership/borrowing, lifetimes, and no GC, although we may currently see a push for more Rust in Gnome for system-level code, I think D may beat it for writing *applications*. Adding to that, it was comments like this on the Rust reddit group that really reinforce my decision to stay far away from Rust for desktop app development: https://www.reddit.com/r/rust/comments/7gg7lm/what_is_currently_the_best_options_for_gui/dqjo1c4/
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 15:37:15 UTC, Benny wrote: On Friday, 26 January 2018 at 03:40:26 UTC, Rubn wrote: You seem to be short tempered You think after two days trying to get a series of plugins to work? 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. Visual Studio Code: Code-D, Serve-D, D-Language Jetbrain: D-Language That is 4 plugins as described in the original post. Two of the same author, 2 from other authors. So that makes 3 different people there plugins. One may think a person can be salty after so many hours. Well one is an older version, which is why it's the same author. The Jetbrains plugin wasn't developed for a long time, I don't know the current state of it. Did you bother at all the create an issue on the respective github repos stating your issue? Did you look at the source at all for the plugins? They aren't terribly complicated, you could diagnose some issues yourself. - 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 Well, if that actually worked, i will not be complaining here. Well, if it didn't work, that gif wouldn't exist.
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). 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. You are not alone. The existing D-Tools are either really bad or do not work propely/not out of the box. And I have more important things to do than trying to setup the tools. Maybe someone likes that, but not me. But I have to say that I've used more or less successfully Visual-D and Mono-D a few years ago. But neither of the tools can keep up in any way with Tools for Rust/C++/C#/Java/PHP. The existence of a good IDE which works out of the box without annoying setup procedures is crucial for the success of a language nowadays. That's one of the reason why I've moved on. I went back to C++ and nowadays to Rust. C++ is not that clean as D but the Tool support is crucial for anyone who wants to use the language for other than some hobby stuff.
Re: reduce mangled name sizes via link-time symbol renaming
On Friday, 26 January 2018 at 08:44:26 UTC, Seb wrote: 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. -- Johannes I thought LDC is already doing this with -hashtres? https://github.com/ldc-developers/ldc/pull/1445 * What i suggested doesn't require any hashing, so it can produce minimal symbol size with 0 risk of collision, in fact optimally minimum symbol size if we wanted to (using an incremented counter i to remap the i'th symbol) * -hashtres is still experimental, and doesn't work with phobos, and has a lower bound on symbol size since it's using a hash; it has other limitations as you can see in https://github.com/ldc-developers/ldc/pull/1445#issue-149189001 * a potential extension of this proposal is to do it not at link time but at compile time, where we'd maintain (in memory) the mapping long_mangle=>short_mangle and serialize it to a file in case we'd like to support separate compilation.
Re: The Eve programming language project is winding down
On Thursday, 25 January 2018 at 04:13:29 UTC, Andrei Alexandrescu wrote: https://news.ycombinator.com/item?id=16227130 http://eve-lang.com/ Not quite the point of the language, but it is funny that it uses D's old "compilable HTML" And from what I saw in their introduction page, the language wasn't really that simple either. I like declarative programing, but I just wasn't feeling the connection between the declarations. Maybe it is because I know what a browser has to do, but I don't see how binding a DIV to a browser makes anything happen. I also don't know what I'm suppose to expect to happen. And they still didn't eliminate the need to understand working with a browser, DIV, what is that, why am I using it in my programming language.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 21:59:51 UTC, Dgame wrote: You are not alone. The existing D-Tools are either really bad or do not work propely/not out of the box. And I have more important things to do than trying to setup the tools. Maybe someone likes that, but not me. But I have to say that I've used more or less successfully Visual-D and Mono-D a few years ago. But neither of the tools can keep up in any way with Tools for Rust/C++/C#/Java/PHP. The existence of a good IDE which works out of the box without annoying setup procedures is crucial for the success of a language nowadays. That's one of the reason why I've moved on. I went back to C++ and nowadays to Rust. C++ is not that clean as D but the Tool support is crucial for anyone who wants to use the language for other than some hobby stuff. I have been comparing a bunch of languages and there IDEs this afternoon to see how fast and efficient there latest version work ( mostly inspired by the other topics of popular languages ). Wanted to avoid the whole "grass is greener on the other side" as a way to be fair. * Rust: Jetbrain IntelliJ + Rust plugin. It looks like it has become a official supported plugin by Jetbrain. Works perfectly out of the box. Impressive results and issue hinting. * Crystal: Visual Studio Code + OmniPascal plugin Color syntax but nothing else. No surprise, Crystal has no Windows compiler so no way to link any meaningful out output on Windows. * Pascal: Yes, freaking pascal! Visual Studio Code + OmniPascal plugin Impressive! Impressive features, type hinting and more. * C#: Visual Studio Code + C# ( OmniSharp ). No surprise there. Lots of functionality. * Go: Visual Studio Code + Go Plugin. Again, no surprise. Lots of functionality. Did not try the Jetbrain Gogland IDE because that is a official product so of course Go will work great in that one. * Julia: Visual Studio Code + Julia Plugin. Took a bit more configuring but again more functionality then i ever got from any D plugin. * Swift: Visual Studio Code + Swift Plugin. Like Crystal, no Windows version and limited to Color Syntax. ... got kind of fed up testing because everything that you expect to works on Windows, worked out of the box ( at best with oa Julia one needed to add the compiler path ). If nobody has figured out the trend by now, every language that has a windows compiler in any form has no major issues to offer extended functionality ( or even basic ). Those that do not have windows compiler, fall flat as expected. The exception being D that despite having multiple windows compilers offer ( in my case ) no functionality beyond color syntax. I do not count the VSC ability to list every keyword in your document. Another trend that i noticed from the other thread is that all the above mentioned languages all outperform D in github user activity ranking ( inc the very young one's ). D has always struck me more as a corporate language ( one that is less focused upon open source ). Maybe there is a more open community focus on the other platforms and this drives more interaction and pushes better plugin support? In other words, at best it take me half a hour to get proper editor support in the above mentioned languages ( that offer it in Windows ). Where as D ... well, its been a long topic and anybody who read the first post knows the results. Lets see: * 8+ hours: Struggling with 4 plugins and no results. And still waiting on one of the plugin authors his feedback as he also has a life. * 5 hours: Seven languages with 5 working perfectly and 2 POSIX languages with the expected no result. Yes, that includes the time to download all the compilers, get examples and other stuff. Guess the 8+ hour language ;)
Re: DMD as a library package can now run through all semantic phases
On Friday, 26 January 2018 at 18:40:23 UTC, Seb wrote:
In case someone wants to play with DMD as a library, it got a
lot easier as of today.
Here's an example:
```
#!/usr/bin/env dub
/+dub.sdl:
dependency "dmd" version="~master"
+/
void main()
{
import dmd.frontend;
import std.algorithm : each;
import std.stdio;
// Sets DMD's global variables. Only required to be called
once
// In the future this might be done automatically (e.g.
module constructor or initOnce)
initDMD;
// Search for the predefined import paths of your host
compiler (DMD and LDC are supported)
findImportPaths.each!addImport;
// Load a module
// (if no second argument is given, the file will be opened
and read)
auto m = parseModule("test.d", q{
void foo()
{
foreach (i; 0..10) {}
}
});
// Run through all semantic phases
m.fullSemantic;
m.prettyPrint.writeln;
}
```
Want to know what it prints? Run the file!
Spoiler: it's similar to new the AST feature at run.dlang.io:
https://run.dlang.io/is/mwU67O
__Warning__: the DMD DUB package is still experimental and at
the moment should only be used by alpha warriors.
See also:
https://dlang.org/phobos-prerelease/dmd_frontend.html (will
work soon)
https://dlang.org/library-prerelease/dmd/frontend.html (Ddox
documentation, works already)
Huge thanks and credits goes to Jacob Carlborg and Razvan Nitu
as well.
on OSX:
chmod u+x main.d
./main.d
WARNING: A deprecated branch based version specification is used
for the dependency dmd. Please use numbered versions instead.
Also note that you can still use the dub.selections.json file to
override a certain dependency to use a branch instead.
Invalid source/import path:
/Users/timothee/.dub/packages/dmd-master/dmd/generated/dub
core.exception.AssertError@../../../../../.dub/packages/dmd-master/dmd/src/dmd/frontend.d(208):
No valid config found.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 03:40:26 UTC, Rubn wrote: You seem to be short tempered You think after two days trying to get a series of plugins to work? 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. Visual Studio Code: Code-D, Serve-D, D-Language Jetbrain: D-Language That is 4 plugins as described in the original post. Two of the same author, 2 from other authors. So that makes 3 different people there plugins. One may think a person can be salty after so many hours. - 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 Well, if that actually worked, i will not be complaining here.
Re: How programmers transition between languages
On Friday, 26 January 2018 at 20:08:15 UTC, Paulo Pinto wrote: On Friday, 26 January 2018 at 18:46:12 UTC, John Gabriele wrote: One niche I could see D establishing some popularity is in GNU/Linux GTK desktop apps. Especially now that GDC will be part of GCC. With GNOME in the process of adopting Rust, I don't have big hopes for it. https://wiki.gnome.org/Hackfests/Rust2017 https://wiki.gnome.org/Hackfests/Rust2017-2 With Rust's extra complexity (over D) of ownership/borrowing, lifetimes, and no GC, although we may currently see a push for more Rust in Gnome for system-level code, I think D may beat it for writing *applications*. I'm planning on learning more D, then trying out GtkD to see how it compares with Python + PyGObject for some little apps.
Re: How programmers transition between languages
On Friday, 26 January 2018 at 09:02:03 UTC, Ola Fosheim Grøstad wrote: While this analysis of language popularity on Github is enlightening: http://www.benfrederickson.com/ranking-programming-languages-by-github-users/ What i found interesting is the comparison between the "newer" languages and D ( see the reddit thread ). 9 Go 4.1022 15 Kotlin 1.2798 18 Rust0.7317 35 Julia 0.0900 46 Vala0.0665 50 Crystal 0.0498 53 D 0.047% While i can understand Rust ( Mozilla ), Kotlin ( Jetbrain ), Go ( Google ). Even Vala and Crystal are ranked higher then D.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 16:30:19 UTC, Benny wrote: On Friday, 26 January 2018 at 07:08:50 UTC, Johannes Loher wrote: 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. In general a lot of plugins tend to work better in POSIX systems then Windows. I think its more a issue about Windows platform testing. Just want to pipe in that I run linux and yeah, I can't relate to any of the OP's grievances, using Visual Studio Code. I installed serve-d and the D tools on the side from repositories, then a few clicks for the code-d beta in vscode, and it just works. Arch/Manjaro. No real complaints about the features offered either. Autocomplete can be a bit too eager at times maybe, suggesting equals_t and various enum members when typing else, recently unitTest (from ModuleInfo) instead of unittest, etc. Syntax highlighting points out unbalanced parens, braces and quotes. Mouseover for documentation works, looking up/peeking at definitions does too. If I could magically wish for one thing it would be UFCS support.
Re: How programmers transition between languages
On Friday, 26 January 2018 at 17:24:54 UTC, Benny wrote: What i found interesting is the comparison between the "newer" languages and D ( see the reddit thread ). 9 Go 4.1022 15 Kotlin 1.2798 18 Rust0.7317 35 Julia 0.0900 46 Vala0.0665 50 Crystal 0.0498 53 D 0.047% While i can understand Rust ( Mozilla ), Kotlin ( Jetbrain ), Go ( Google ). Even Vala and Crystal are ranked higher then D. One niche I could see D establishing some popularity is in GNU/Linux GTK desktop apps. Especially now that GDC will be part of GCC.
Re: How programmers transition between languages
Very cool stuff, thanks for sharing.
DMD as a library package can now run through all semantic phases
In case someone wants to play with DMD as a library, it got a lot
easier as of today.
Here's an example:
```
#!/usr/bin/env dub
/+dub.sdl:
dependency "dmd" version="~master"
+/
void main()
{
import dmd.frontend;
import std.algorithm : each;
import std.stdio;
// Sets DMD's global variables. Only required to be called
once
// In the future this might be done automatically (e.g.
module constructor or initOnce)
initDMD;
// Search for the predefined import paths of your host
compiler (DMD and LDC are supported)
findImportPaths.each!addImport;
// Load a module
// (if no second argument is given, the file will be opened
and read)
auto m = parseModule("test.d", q{
void foo()
{
foreach (i; 0..10) {}
}
});
// Run through all semantic phases
m.fullSemantic;
m.prettyPrint.writeln;
}
```
Want to know what it prints? Run the file!
Spoiler: it's similar to new the AST feature at run.dlang.io:
https://run.dlang.io/is/mwU67O
__Warning__: the DMD DUB package is still experimental and at the
moment should only be used by alpha warriors.
See also:
https://dlang.org/phobos-prerelease/dmd_frontend.html (will work
soon)
https://dlang.org/library-prerelease/dmd/frontend.html (Ddox
documentation, works already)
Huge thanks and credits goes to Jacob Carlborg and Razvan Nitu as
well.
ExpressionTuple is referenced in the specs, but doesn't seem to be defined
See, for instance, definition https://dlang.org/spec/class.html#class_properties. If it is defined anywhere, I cannot seem to find it.
functions allowed to overload on const int vs int vs immutable int? + spec is not accurate
this compiles, but equivalent in C++ (const int vs int) would
give a
compile error (error: redefinition of 'fun'); what's the
rationale for
allowing these overloads?
```
void fun(int src){ writeln2(); }
void fun(immutable int src){ writeln2(); }
void fun(const int src){ writeln2(); }
void main(){
{int src=0; fun(src);} // matches fun(int)
{immutable int src=0; fun(src);} // matches fun(immutable int)
{const int src=0; fun(src);} // matches fun(const int)
}
```
The spec does mention `match with conversion to const` taking
precedence over `exact match` however this isn't precise: the
following would be more precise instead (at least according to
snippet
above):
`match with conversion to/from const/immutable/mutable`
https://dlang.org/spec/function.html#function-overloading
Functions are overloaded based on how well the arguments to a
function
can match up with the parameters. The function with the best
match is
selected. The levels of matching are:
no match
match with implicit conversions
match with conversion to const
exact match
NOTE: this was one of the root causes of the bug I just fixed in
https://github.com/msoucy/dproto/pull/131: "For sint32/sint64,
this was related to an overload never being called because of dmd
overload resolution rules regarding const vs mutable"
NOTE: somehow this msg didn't appear on forum after I had sent it
via gmail 1 hour ago; this usually works, not sure why it didn't
work this time; apologies if msg appears twice because of that
but seems like a forum bug.
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 07:08:50 UTC, Johannes Loher wrote: 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. In general a lot of plugins tend to work better in POSIX systems then Windows. I think its more a issue about Windows platform testing. 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. It probably is not as bad but its clearly a issue anyway. But one guy complaining after trying 6 or 7 times over a year+ ( with constant reporting the issues ), probably means there are more people out there who tried and simply gave up without reporting the issues. 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. And that is the same issue with a lot of FOSS languages. But at one moment one needs to say stop. I donated a lot ( for me anyway ) of money to different FOSS projects but that money, what happened to it? In general there is zero accountability where money gets spend on most projects. Just in the last month over 500$ on different projects. But i am not a infinity money machine. And in this case: Does one donate money to the Code-D/Serve-D developer. But its not really his issue. To the D-Language developer? But its not really his issue. Who do you even donate too to have specific problems that are hard to trace fixed. Its not like one asks: "Please add x functionality". Just recently i donated 100$ to a other language project to implement socket support. So far i see nothing happening, while this functionality is more important to me now ( as it blocks my progress on that project ). So even when donating the results can be "i feel ripped off". Do it yourself = Time is money. If i had that much time to learn the base code of a language, i will not be donating money to specific language projects ( also i'am not a good core / system programmer ). I feel its too many times: Complain about issue => Get responds there are no people to do it => Please do it yourself or pay. By that logic i am bankrupt tomorrow with the issues i face in different languages :) Let me not bother you too much with my rants. Like i said, its better ( for me ) to focus on a language that has things better worked out and it does not feel like screaming at the walls. I feel sorry for projects like this that have no big corporate backers because its not a envy position without the money and focus.
Re: How programmers transition between languages
On Friday, 26 January 2018 at 18:46:12 UTC, John Gabriele wrote: On Friday, 26 January 2018 at 17:24:54 UTC, Benny wrote: What i found interesting is the comparison between the "newer" languages and D ( see the reddit thread ). 9 Go 4.1022 15 Kotlin 1.2798 18 Rust0.7317 35 Julia 0.0900 46 Vala0.0665 50 Crystal 0.0498 53 D 0.047% While i can understand Rust ( Mozilla ), Kotlin ( Jetbrain ), Go ( Google ). Even Vala and Crystal are ranked higher then D. One niche I could see D establishing some popularity is in GNU/Linux GTK desktop apps. Especially now that GDC will be part of GCC. With GNOME in the process of adopting Rust, I don't have big hopes for it. https://wiki.gnome.org/Hackfests/Rust2017 https://wiki.gnome.org/Hackfests/Rust2017-2
Re: Dscanner - DCD - Dfix ... Editor support or the lack of it.
On Friday, 26 January 2018 at 17:27:17 UTC, Anonymouse wrote: If I could magically wish for one thing it would be UFCS support. Just an FYI: implementing the universal language server protocol with DMD as a library is the number 1 priority for this year's GSoC: https://wiki.dlang.org/GSOC_2018_Ideas#Language_Server_Protocol_for_D (if the D Language Foundation gets accepted, of course)
Re: Shouldn't invalid references like this fail at compile time?
On Thursday, January 25, 2018 17:20:21 H. S. Teoh via Digitalmars-d wrote: > 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 Well at least you don't have to program in Java. :) Unless something has changed in one of the recent versions, you can't even write a swap function in Java. :| It's definitely painful to have to program in C++ after programming in D, but I still find C++ to be more pleasant than the alternatives other than D. - Jonathan M Davis
How programmers transition between languages
While this analysis of language popularity on Github is enlightening: http://www.benfrederickson.com/ranking-programming-languages-by-github-users/ I found the older analysis of how programmers transition (or adopt new languages) more interesting: https://blog.sourced.tech/post/language_migrations/ Like how people move from Rust to Go. And from Go to Python: https://blog.sourced.tech/post/language_migrations/sum_matrix_22lang_eig.svg Also the growth of Java is larger than I would anticipate: https://blog.sourced.tech/post/language_migrations/eigenvect_stack_22lang.png Granted, Java has gotten quite a few convenience features over the years.
Re: reduce mangled name sizes via link-time symbol renaming
On Friday, 26 January 2018 at 07:34:50 UTC, Johannes Pfau wrote: Am Thu, 25 Jan 2018 14:24:12 -0800 schrieb Timothee Cour : [...] 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 I thought LDC is already doing this with -hashtres? https://github.com/ldc-developers/ldc/pull/1445
