Re: recursive template expansion: Why does this not compile?
On Wednesday, March 21, 2018 00:47:18 Ontonator via Digitalmars-d-learn wrote: > The following code does not compile: > > void main() {} > > > > class SuperClass {} > > > > class TemplatedClass(T : SuperClass) {} > > > > class A : SuperClass { > > > > alias T = TemplatedClass!B; > > > > } > > > > class B : SuperClass { > > > > alias T = TemplatedClass!C; > > > > } > > > > class C : SuperClass {} > > It gives the error: > > test.d(12): Error: class `test.TemplatedClass(T : SuperClass)` > > recursive template expansion > > test.d(12):while looking for match for > > TemplatedClass!(C) > > The aliases do not have to be aliases, as long as there is some > reference to the class (e.g. method and variable declarations > also work). What exactly is the reason for this error? I'm not sure exactly what's happening, since I'm not very familiar with the exactly how template specializations are defined, but the problem clearly relates to the fact that you used a template specialization instead of a template constraint. If you change TemplatedClass to class TemplatedClass(T) if(is(T : SuperClass)) {} then the code compiles. - Jonathan M Davis
recursive template expansion: Why does this not compile?
The following code does not compile: void main() {} class SuperClass {} class TemplatedClass(T : SuperClass) {} class A : SuperClass { alias T = TemplatedClass!B; } class B : SuperClass { alias T = TemplatedClass!C; } class C : SuperClass {} It gives the error: test.d(12): Error: class `test.TemplatedClass(T : SuperClass)` recursive template expansion test.d(12):while looking for match for TemplatedClass!(C) The aliases do not have to be aliases, as long as there is some reference to the class (e.g. method and variable declarations also work). What exactly is the reason for this error?
Re: Incomprehensible error message
On Tuesday, 20 March 2018 at 23:45:20 UTC, H. S. Teoh wrote: The tricky part is, who's going to do the work of going through *all* of dmd's error messages and rewriting them with said metadata. We did it for the stupid syntax highlighting thing... and this has bigger win, though it is also more work than just adding `` around it. It would seem to me that a solution that can be implemented gradually is more likely to be adopted. The beauty of XML is that it is reasonably easy to do gradually since it is a marked up string rather than a whole new format. On the display side, it can even detect if(str[0] == '<') assume it is xml, otherwise assume it is plain text. User-side ides can do it as well as the compiler's top-level presentation layer. Or the existing error() function can add "" and encode the stuff, and a new detailedError function does more detail. xml is also extensible to add more info later when we decide. It really is quite elegant for marking up a text base with more metadata... E.g. if we can somehow work with the existing format of error messages and extract some useful info from them, perhaps reformat substrings that match certain known patterns, then we can gradually migrate all error messages to a particular format that will eventually serve as the intermediate metadata encoding. Well, a lot of info is lost by the toChars not putting out as much info as it could. So working with existing messages still needs changes on the generation side to improve it. But we can add info as we go.
Re: Incomprehensible error message
On Tue, Mar 20, 2018 at 11:05:59PM +, Adam D. Ruppe via Digitalmars-d-learn wrote: > On Tuesday, 20 March 2018 at 21:18:01 UTC, H. S. Teoh wrote: > > Which means error messages would need to be constructed as an > > abstract object that the error message printer can then inspect to > > determine which symbol(s) should be FQNs. > > I've talked before about XML error messages. I'd actually like them to > literally be xml, but even if they aren't the same principle works - > pack the error messages with a lot of metadata when they are > generated, then trim that at a higher level to make it more > presentable (ideally, that higher level may be the ide, but for a > console run the compiler might have to do it). That's not a bad idea, and pretty close to what I have in mind. The tricky part is, who's going to do the work of going through *all* of dmd's error messages and rewriting them with said metadata. It would seem to me that a solution that can be implemented gradually is more likely to be adopted. E.g. if we can somehow work with the existing format of error messages and extract some useful info from them, perhaps reformat substrings that match certain known patterns, then we can gradually migrate all error messages to a particular format that will eventually serve as the intermediate metadata encoding. Any proposed solution that requires a one-off rewriting of every single error message in dmd is unlikely to fly, IMO. T -- There are 10 kinds of people in the world: those who can count in binary, and those who can't.
Re: Incomprehensible error message
On Tuesday, 20 March 2018 at 21:18:01 UTC, H. S. Teoh wrote: Which means error messages would need to be constructed as an abstract object that the error message printer can then inspect to determine which symbol(s) should be FQNs. I've talked before about XML error messages. I'd actually like them to literally be xml, but even if they aren't the same principle works - pack the error messages with a lot of metadata when they are generated, then trim that at a higher level to make it more presentable (ideally, that higher level may be the ide, but for a console run the compiler might have to do it).
Re: Incomprehensible error message
On Tue, Mar 20, 2018 at 10:04:30PM +0100, Jacob Carlborg via Digitalmars-d-learn wrote: > On 2018-03-19 19:03, H. S. Teoh wrote: > > > Yeah, the compiler really ought to be outputting FQNs in error > > messages, since otherwise you get baffling A != A messages. Though > > outputting FQNs everywhere has the tendency of bloating error > > messages to unreadable lengths, esp. when templates are involved. > > :-( (Though fortunately, no templates are involved in this case.) > > The compiler could output the FQN names only when the non qualified > names are the same. Should hopefully reduce the bloated error > messages. [...] Yeah, I thought about that too, but then it wouldn't be easy to implement, since you wouldn't be able to easily predict whether or not to use an FQN name when you've detected an error and just need to print an error and bailout. It needs to be automated in order to be maintainable (nobody wants to go through thousands of compiler errors and insert complex logic to decide which symbol(s) should be FQN). Which means error messages would need to be constructed as an abstract object that the error message printer can then inspect to determine which symbol(s) should be FQNs. Either way, it will require a lot of effort to pull off. T -- For every argument for something, there is always an equal and opposite argument against it. Debates don't give answers, only wounded or inflated egos.
Re: Packages and module import
On 2018-03-19 18:29, Russel Winder wrote: I had assumed that a directory of modules was a package. So for example: A/a.d A/b.d were two modules in package A. Especially given there is a module statement at the beginning of each module: A/a.d has module A.a; A/b.d has module A.b; Now A.b needs to access something from A.a. I had assumed that the import should be fully qualified. So in A.b.d: import A.a: thing; This all works when building the library. ldc2 -of=Build/Release/libdvbv5_d.so -shared -defaultlib=phobos2-ldc Build/Release/source/libdvbv5_d/linux_dmx.o Build/Release/source/libdvbv5_d/dvb_v5_std.o Build/Release/source/libdvbv5_d/dvb_frontend.o Build/Release/source/libdvbv5_d/dvb_log.o Build/Release/source/libdvbv5_d/dvb_demux.o Build/Release/source/libdvbv5_d/dvb_fe.o Build/Release/source/libdvbv5_d/dvb_file.o Build/Release/source/libdvbv5_d/dvb_scan.o Build/Release/source/libdvbv5_d/dvb_sat.o -L-ldruntime-ldc However when trying to build the unit-tests: ldc2 -I=source -unittest --main -of=Build/Test/libdvbv5_d source/libdvbv5_d/linux_dmx.d source/libdvbv5_d/dvb_v5_std.d source/libdvbv5_d/dvb_frontend.d source/libdvbv5_d/dvb_log.d source/libdvbv5_d/dvb_demux.d source/libdvbv5_d/dvb_fe.d source/libdvbv5_d/dvb_file.d source/libdvbv5_d/dvb_scan.d source/libdvbv5_d/dvb_sat.d source/libdvbv5_d/dvb_demux.d(35): Error: module linux_dmx from file source/libdvbv5_d/linux_dmx.d must be imported with 'import linux_dmx;' Am I just missing something simple? Not sure if this will help, but are you aware that DStep can add a package to the module declaration using "--package"? -- /Jacob Carlborg
Re: Incomprehensible error message
On 2018-03-19 19:03, H. S. Teoh wrote: Yeah, the compiler really ought to be outputting FQNs in error messages, since otherwise you get baffling A != A messages. Though outputting FQNs everywhere has the tendency of bloating error messages to unreadable lengths, esp. when templates are involved. :-( (Though fortunately, no templates are involved in this case.) The compiler could output the FQN names only when the non qualified names are the same. Should hopefully reduce the bloated error messages. -- /Jacob Carlborg
Re: Slow start up time of runtime (correction: Windows real-time protection)
On Tuesday, 20 March 2018 at 16:56:59 UTC, Dennis wrote: On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote: On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote: I suspect you are seeing the Windows antivirus hitting you. D runtime starts up in a tiny fraction of a second, you shouldn't be noticing it. You're totally right, disabling real-time protection makes a massive difference. I always found a second exceptionally long for a runtime to initialize, but I couldn't think of any other differences between a simple dmd-compiled program and a simple dmc-compiled program. On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote: I betcha you'll see this delay (and a similar one on dmd itself, your compiles could be running at half-speed with this too) Definitely. I've tested how long tools take to simply print their help text: for the first time with virus scan, second time with virus scan and without any real-time protection. D tools seem to get the longest delay. First Second No protection (miliseconds) dmc 84 52 16 dmd 2400120024 dub 2300110025 ldc 4500180 30 gcc 240 100 18 On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote: I don't know why the antivirus picks on D so much, but on my box it does and it sounds like it is on yours too. BTW that real time check box likes to keep turning itself on... so the slowness will keep coming back. Typical Windows... It keeps turning on the Windows update service too. This now leaves the question what's the best way to mitigate this, because I would gladly get rid of the second of delay any time I invoke dmd, ldc or dub as well as my own applications. I cannot guarantee that this is the cause, but I observed that Bitdefender is very picky with Intel OMF format. I made a lot of complaints about this (it was impossible to debug a intel omf compiled exe with Bitdefender installed and the advice received from Bitdefender was to compile my executables in mscoff format. That's how my problem disappeared. Windows Defender incorporated last year Bitdefender scanning technology, maybe this is an explanation.
Re: Slow start up time of runtime (correction: Windows real-time protection)
On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote: On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote: I suspect you are seeing the Windows antivirus hitting you. D runtime starts up in a tiny fraction of a second, you shouldn't be noticing it. You're totally right, disabling real-time protection makes a massive difference. I always found a second exceptionally long for a runtime to initialize, but I couldn't think of any other differences between a simple dmd-compiled program and a simple dmc-compiled program. On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote: I betcha you'll see this delay (and a similar one on dmd itself, your compiles could be running at half-speed with this too) Definitely. I've tested how long tools take to simply print their help text: for the first time with virus scan, second time with virus scan and without any real-time protection. D tools seem to get the longest delay. First Second No protection (miliseconds) dmc 84 52 16 dmd 2400120024 dub 2300110025 ldc 4500180 30 gcc 240 100 18 On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote: I don't know why the antivirus picks on D so much, but on my box it does and it sounds like it is on yours too. BTW that real time check box likes to keep turning itself on... so the slowness will keep coming back. Typical Windows... It keeps turning on the Windows update service too. This now leaves the question what's the best way to mitigate this, because I would gladly get rid of the second of delay any time I invoke dmd, ldc or dub as well as my own applications.
Re: How to build static linked executable
On Tuesday, 20 March 2018 at 10:37:55 UTC, zunkree wrote: So, how to build static binary for macOS? I don't see a need to do that. I build static binaries on Linux because they work across all distros and all versions. But for macOS, there are no distros. For supporting multiple versions, or rather an older version than you're building on, you can use the "-macosx_version_min" linker flag. See [1] for an example. If you really want a static binary, I think it's possible if you're calling the kernel directly (I think Go can do this). But then most of D would not work, since it builds on the C standard library. [1] https://github.com/jacob-carlborg/dstep/blob/19a5ddb8ad3f44b3445c89840155bb7cd1ee44b7/dub.json#L20 -- /Jacob Carlborg
Re: Slow start up time of runtime
On Tuesday, 20 March 2018 at 12:18:16 UTC, Adam D. Ruppe wrote: Go into the Windows security center and uncheck the real time virus check protection. I betcha you'll see this delay (and a similar one on dmd itself, your compiles could be running at half-speed with this too) disappear and everything will seem a LOT faster. I also noticed slow startup times for freshly compiled D programs. And yes, I can verify that it's the Windows Defender's realtime scan. I switched it off (Windows 10) and dmd itself and the compiled D program started just as fast as they should. It gets better (with realtime scan enabled) when you compile your programs with dmd -O -release -m64 app.d
Re: Is there a way to pipeline program with random-access ranges in C#?
On Tuesday, 20 March 2018 at 15:06:14 UTC, Dukc wrote: Won't quite do it, because that would not iterate backwards. Linq has no chunking, so you would need to write it, maybe similar to SelectMany, but with the opposite meaning. public static IEnumerable> Enumerate(this IEnumerable range) { return range.Zip(Enumerable.Range(0, int.MaxValue), (x, y) => new Sequence (x, y)); } If you want to have index, there's https://msdn.microsoft.com/en-us/library/bb534869(v=vs.110).aspx
Re: Is there a way to pipeline program with random-access ranges in C#?
On Tuesday, 20 March 2018 at 08:05:14 UTC, Kagamin wrote: On Monday, 19 March 2018 at 17:33:31 UTC, Dukc wrote: public static int Foo(int[] input) { int result = 10; for (int i = input.Length / 4; i >= 0; i -= 4) { int sum = 0; for (int j = i; j < i +4 && j < input.Length; j++) sum += input[j]; sum *= i; result = (result + sum) / 2; } return result; } Looks like you need to partition, select, aggregate and another aggregate. Won't quite do it, because that would not iterate backwards. But anyway, I made this extension function today which solves most of my problems, albeit not that one above: public static IEnumerable> Enumerate(this IEnumerable range) { return range.Zip(Enumerable.Range(0, int.MaxValue), (x, y) => new Sequence (x, y)); } (Of course, were I compiling to .net framework instead of JavaScript I would have to use Tuple or ValueTuple instead of Sequence)
Re: Slow start up time of runtime
On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote: I suppose initializing the runtime takes a lot of time. I suspect you are seeing the Windows antivirus hitting you. D runtime starts up in a tiny fraction of a second, you shouldn't be noticing it. Go into the Windows security center and uncheck the real time virus check protection. I betcha you'll see this delay (and a similar one on dmd itself, your compiles could be running at half-speed with this too) disappear and everything will seem a LOT faster. I don't know why the antivirus picks on D so much, but on my box it does and it sounds like it is on yours too. BTW that real time check box likes to keep turning itself on... so the slowness will keep coming back.
Re: Slow start up time of runtime
On Tuesday, 20 March 2018 at 10:46:11 UTC, Dennis wrote: On Tuesday, 20 March 2018 at 10:20:55 UTC, Dennis wrote: On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote: Besides if it was and it took 1 second to startup, then it wouldn't matter in practice with an actual application. This is not concerning for large applications indeed. But say, I want to implement my own `dir` (= `ls` on Unix) in D. Would you want to use it if it took a full second every time you wanted to quickly view a folder's contents? To give some more context, I've been using some of the digital mars utilities and I admire their speed. A `grep -r "goto" *.d` could find and scan 1.7 MB of d-source files in 190ms, way before my D hello-world was even able to enter main. As far I know, these are just C programs. I wonder if I could make such fast utilities in D, or whether (idiomatic) D is not the right tool for this and I should use (better)C instead. Have you tried other applications that doesn't just print and see if that matters? Try to write to a file instead of the standard output and see if that makes any difference between each compilation unit. Also remember that you don't compile with dmd for runtime speed, but compilation speed. For runtime speed you want to use ldc, since it optimizes code way better.
Re: Slow start up time of runtime
On Tuesday, 20 March 2018 at 12:07:12 UTC, bauss wrote: On Tuesday, 20 March 2018 at 10:46:11 UTC, Dennis wrote: On Tuesday, 20 March 2018 at 10:20:55 UTC, Dennis wrote: On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote: Besides if it was and it took 1 second to startup, then it wouldn't matter in practice with an actual application. This is not concerning for large applications indeed. But say, I want to implement my own `dir` (= `ls` on Unix) in D. Would you want to use it if it took a full second every time you wanted to quickly view a folder's contents? To give some more context, I've been using some of the digital mars utilities and I admire their speed. A `grep -r "goto" *.d` could find and scan 1.7 MB of d-source files in 190ms, way before my D hello-world was even able to enter main. As far I know, these are just C programs. I wonder if I could make such fast utilities in D, or whether (idiomatic) D is not the right tool for this and I should use (better)C instead. Have you tried other applications that doesn't just print and see if that matters? Try to write to a file instead of the standard output and see if that makes any difference between each compilation unit. Also remember that you don't compile with dmd for runtime speed, but compilation speed. For runtime speed you want to use ldc, since it optimizes code way better. To add on to this. Typically dmd is better during development, ldc is better during deployment and release.
Re: How to build static linked executable
On Tuesday, 20 March 2018 at 10:37:55 UTC, zunkree wrote: On Sunday, 18 March 2018 at 14:36:04 UTC, Jacob Carlborg wrote: FYI, -static is not support on macOS. So, how to build static binary for macOS? Static binaries aren't really supported by Apple (anymore). What do you need it for? — David
Re: Slow start up time of runtime
On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote: Are there ways to reduce this to below 0.1s, or should I just leave idiomatic D and make a betterC program? The best solution would be to profile the startup process and file a bug accordingly. ;) — David
Re: Slow start up time of runtime
On Tuesday, 20 March 2018 at 10:20:55 UTC, Dennis wrote: On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote: Besides if it was and it took 1 second to startup, then it wouldn't matter in practice with an actual application. This is not concerning for large applications indeed. But say, I want to implement my own `dir` (= `ls` on Unix) in D. Would you want to use it if it took a full second every time you wanted to quickly view a folder's contents? To give some more context, I've been using some of the digital mars utilities and I admire their speed. A `grep -r "goto" *.d` could find and scan 1.7 MB of d-source files in 190ms, way before my D hello-world was even able to enter main. As far I know, these are just C programs. I wonder if I could make such fast utilities in D, or whether (idiomatic) D is not the right tool for this and I should use (better)C instead.
Re: How to build static linked executable
On Sunday, 18 March 2018 at 14:36:04 UTC, Jacob Carlborg wrote: On 2018-03-17 16:42, Seb wrote: Yes, use -static Here's how we build the DTour: https://github.com/dlang-tour/core/blob/master/dub.sdl FYI, -static is not support on macOS. So, how to build static binary for macOS?
Re: How to build static linked executable
On Saturday, 17 March 2018 at 15:42:06 UTC, Seb wrote: On Saturday, 17 March 2018 at 14:44:42 UTC, zunkree wrote: Hi, Is there a way to build static linked executable with dub for vibe-d based app? Regards, zunkree Yes, use -static Here's how we build the DTour: https://github.com/dlang-tour/core/blob/master/dub.sdl Thank you very much.
Re: Slow start up time of runtime
On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote: Besides if it was and it took 1 second to startup, then it wouldn't matter in practice with an actual application. This is not concerning for large applications indeed. But say, I want to implement my own `dir` (= `ls` on Unix) in D. Would you want to use it if it took a full second every time you wanted to quickly view a folder's contents? On Tuesday, 20 March 2018 at 09:51:09 UTC, bauss wrote: Without actual compiler versions, compiler flags and example code then it's pretty much impossible to tell what's slow. ``` import core.stdc.stdio: printf; int main() { return printf("hello world"); } ``` Compiling with `dmd helloworld_printf.d` or `dmd -release -O -inline helloworld_printf.d` doesn't make a difference here: `Measure-Command {./helloworld_printf}` reports ~1.1s in any case. I'm using 2.079 but I doubt this is a regression. betterC version: ``` import core.stdc.stdio: printf; extern(C) int main() { return printf("hello world"); } ``` `dmd helloworld_betterc.d -betterC` `ldc2 helloworld_betterc.d -betterC` I now notice that without the -betterC flag it's also 0.05s. So I suppose defining a `_d_run_main` instead of a `extern(C) main` is causing the slow startup time.
Re: Slow start up time of runtime
On Tuesday, 20 March 2018 at 09:44:41 UTC, Dennis wrote: Simply running a "hello world.exe" takes, on my pc: 1.12s When compiled with dmd 0.62s When compiled with ldc 0.05s When compiled with dmc (C program) or dmd/ldc as a -betterC program I suppose initializing the runtime takes a lot of time. When making a simple command line utility, half a second of delay is highly undesirable. Are there ways to reduce this to below 0.1s, or should I just leave idiomatic D and make a betterC program? It's not necessarily the runtime that's slow. Besides if it was and it took 1 second to startup, then it wouldn't matter in practice with an actual application. Besides there could be a lot other factors. Without actual compiler versions, compiler flags and example code then it's pretty much impossible to tell what's slow. For me it's certainly not that slow with dmd.
Slow start up time of runtime
Simply running a "hello world.exe" takes, on my pc: 1.12s When compiled with dmd 0.62s When compiled with ldc 0.05s When compiled with dmc (C program) or dmd/ldc as a -betterC program I suppose initializing the runtime takes a lot of time. When making a simple command line utility, half a second of delay is highly undesirable. Are there ways to reduce this to below 0.1s, or should I just leave idiomatic D and make a betterC program?
Re: Is there a way to pipeline program with random-access ranges in C#?
On Monday, 19 March 2018 at 17:33:31 UTC, Dukc wrote: public static int Foo(int[] input) { int result = 10; for (int i = input.Length / 4; i >= 0; i -= 4) { int sum = 0; for (int j = i; j < i +4 && j < input.Length; j++) sum += input[j]; sum *= i; result = (result + sum) / 2; } return result; } Looks like you need to partition, select, aggregate and another aggregate.