Re: D doesn't read the first character of a file (reads everything but the first chararacter) with either read() or readText()
On Tuesday, 18 July 2017 at 02:21:59 UTC, Enjoys Math wrote: DMD32 D Compiler v2.074.1 import std.file; void main() { string bigInput = readText("input.txt"); } The file is 7 MB of ascii text, don't know if that matters... Should I upgrade versions? Could you please share the first 32-bytes (in hex) of your file? Like: $ hexdump -C input.txt
[Issue 13211] Expand macros in comments within code sections
https://issues.dlang.org/show_bug.cgi?id=13211 Vladimir Panteleevchanged: What|Removed |Added Keywords||ddoc See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=12383 Severity|enhancement |normal --- Comment #3 from Vladimir Panteleev --- Whether or not macros should be expanded in code blocks at all, the current behaviour is at least inconsistent, so there is certainly a bug here. --
[Issue 12383] dlang.org operator overloading text with DDoc macro.
https://issues.dlang.org/show_bug.cgi?id=12383 Vladimir Panteleevchanged: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=13211 --
Re: Is it possible to generate a pool of random D or D inline assembler programs, run them safely?
On Tuesday, 18 July 2017 at 17:35:17 UTC, Enjoys Math wrote: Without them crashing the app running them? Say by wrapping with try / catch? and, most probably a timeout, as you're certainly going to run into infinite loops. Reason is so I don't have to make my own VM. Why not reuse an existing one? Some of them are very simple: https://github.com/munificent/wren It will be a lot easier than trying to generate random *compilable* D programs ; and will avoid requiring a compilation step in your mutation loop (I know the D compiler is fast, but still :-) ).
[Issue 12648] Array operation return type
https://issues.dlang.org/show_bug.cgi?id=12648 Vladimir Panteleevchanged: What|Removed |Added Hardware|x86 |All OS|Windows |All --
[Issue 2347] opIs is missing
https://issues.dlang.org/show_bug.cgi?id=2347 Vladimir Panteleevchanged: What|Removed |Added Status|NEW |RESOLVED Hardware|x86 |All Resolution|--- |WONTFIX OS|Linux |All --- Comment #4 from Vladimir Panteleev --- (In reply to Stewart Gordon from comment #1) > I think that having opIs is philosophically wrong. The whole point of is is > to override any type-defined equality operator by forcing a byte-for-byte > comparison. There are probably plenty of template libraries and the like > that rely on this. Agreed. Currently `is` provides a guarantee that it compares bits and will never invoke any other user-defined comparison mechanisms. This applies to user-defined types (structs, classes) as well as floating-point types (where x==x may not always be true due to NaNs). An opIs operator would break that guarantee. User-defined smart references and slices could instead expose identity comparison via a ".ptr" property, which could then be compared using `==` or `is`. Also, I understand that such language additions would need to be done via a DIP today. @Andrei: I'll close this (also because this issue is close to a decade old), but please reopen if you disagree. --
[Issue 7464] Better Error Message When Using S.tupleof within S
https://issues.dlang.org/show_bug.cgi?id=7464 Vladimir Panteleevchanged: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=7190 --- Comment #2 from Vladimir Panteleev --- FWIW, the code compiled before https://github.com/dlang/dmd/pull/595. --
[Issue 7190] Tuple length incorrect
https://issues.dlang.org/show_bug.cgi?id=7190 Vladimir Panteleevchanged: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=7464 --
[Issue 10540] variable used before set for empty static arrays, with -inline -O
https://issues.dlang.org/show_bug.cgi?id=10540 Vladimir Panteleevchanged: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=7953, ||https://issues.dlang.org/sh ||ow_bug.cgi?id=12212 --- Comment #2 from Vladimir Panteleev --- No longer reproducible after https://github.com/dlang/dmd/pull/3467, closing. Please reopen if you can still provide a reproducible test case. --
[Issue 7953] DMD Error: variable r used before set when compiling with -O
https://issues.dlang.org/show_bug.cgi?id=7953 Vladimir Panteleevchanged: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=10540 --
[Issue 12212] Static array assignment makes slice implicitly
https://issues.dlang.org/show_bug.cgi?id=12212 Vladimir Panteleevchanged: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=10540 --
[Issue 10540] variable used before set for empty static arrays, with -inline -O
https://issues.dlang.org/show_bug.cgi?id=10540 Vladimir Panteleevchanged: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --
[Issue 15537] Private function is not accessible from other module when compiling with -debug flag
https://issues.dlang.org/show_bug.cgi?id=15537 Vladimir Panteleevchanged: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Vladimir Panteleev --- The reason why this doesn't compile with -debug is mentioned briefly in the assumeSorted documentation: > In debug mode, a few random elements of r are checked for sortedness. -- https://dlang.org/library/std/range/assume_sorted.html Thus, std.range is failing to use your private compare function when attempting to perform this sortedness check. Note that even if the code compiled without -debug, the result would still not be useful, as you would not be able to pass the resulting SortedRange e.g. to std.algorithm.searching.find. It would fail with the same problem, being unable to access your private opCmp function. Whether symbols passed by alias parameter should be exempted from visibility checks is a separate matter. You can work around this problem by making the comparison function public, but also wrapping it inside a private struct: private struct Hidden { public static bool myCmp(Data a, Data b) { return a[0] < b[0]; } } auto bar() { return [Data(1, "one"), Data(2, "two")].assumeSorted!(Hidden.myCmp); } --
[Issue 15537] Private function is not accessible from other module when compiling with -debug flag
https://issues.dlang.org/show_bug.cgi?id=15537 Vladimir Panteleevchanged: What|Removed |Added Component|dmd |phobos --
Re: proposed @noreturn attribute
On 7/18/2017 7:14 PM, Nicholas Wilson wrote: It describe the behaviour of the function: I think it is neither necessary nor a good idea to express it as a type. assert(0) is already accepted as a valid return statement of any type. I can't continue this without being repetitive, so we'll just have to disagree. The backends for DMD, LDC and GDC would not be affected at all by the addition of a bottom type to the front end, and it would be trivial for the glue code to add the noreturn attribute for functions that return the bottom type. Said glue would be unnecessary with an attribute *that already exists*. In the glue code, replace: if (function attribute is 'noreturn') set backend attribute to 'noreturn'; with: if (function return type is 'bottom') set backend attribute to 'noreturn'; set backend function return type to 'void'; and it should be ready to rock :-)
[Issue 697] No const folding on asm db,dw, etc
https://issues.dlang.org/show_bug.cgi?id=697 --- Comment #9 from Vladimir Panteleev--- OK, I got the Mercurial server running again, and uploaded a copy of the repository to GitHub. The files are here: https://github.com/CyberShadow/dstress/tree/master/run/a Still, looking at these test cases, it's still questionable whether there is much value in them. For instance, asm_di_02_A.d has: const short x = 0x40404040; This is clearly invalid code. The `db 1+2` part of this issue is a valid enhancement request, but should be filed separately. If you have a need for the feature in your programs, please file a new enhancement request. --
Re: proposed @noreturn attribute
On Wednesday, 19 July 2017 at 01:52:30 UTC, Walter Bright wrote: I know how noreturn attributes work - I implemented them decades ago in DMC and DMC++. They are supported by the DMD optimizer and back end. But they are a hack to the type system, and I suggest an unnecessary one. It describe the behaviour of the function: I think it is neither necessary nor a good idea to express it as a type. assert(0) is already accepted as a valid return statement of any type. The backends for DMD, LDC and GDC would not be affected at all by the addition of a bottom type to the front end, and it would be trivial for the glue code to add the noreturn attribute for functions that return the bottom type. Said glue would be unnecessary with an attribute *that already exists*.
Re: proposed @noreturn attribute
On 7/18/2017 5:54 PM, Nicholas Wilson wrote: There is just something fundamentally wrong with: @noreturn int foo(); I would understand it to mean that if it were to return, foo would return an int but it is undefined behaviour for foo to dynamically return. That's the C++ behavior. I know we are all accustomed to it and hence think it is intuitive, but it isn't. I know I've had a hard time breaking free of this sort of thinking, having been so deeply immersed in C++ for so long. returning a value yet not returning. It smacks of "the language designer(s) are idiots." It winds up complicating things like: auto x = a ? b : foo(); What is the type of x? @noreturn means a special case. A proper bottom type means it is not a special case. int. And if b is of type `T`? It doesn't make sense to have to give a type to something that does not return. (@noreturn functions are usually typed as returning `void` anyway, but that still doesn't make much sense.) I know how noreturn attributes work - I implemented them decades ago in DMC and DMC++. They are supported by the DMD optimizer and back end. But they are a hack to the type system, and I suggest an unnecessary one. The backends for DMD, LDC and GDC would not be affected at all by the addition of a bottom type to the front end, and it would be trivial for the glue code to add the noreturn attribute for functions that return the bottom type.
[Issue 17663] header generation (-H) is broken with public override of private default
https://issues.dlang.org/show_bug.cgi?id=17663 Vladimir Panteleevchanged: What|Removed |Added Severity|enhancement |normal --
[Issue 697] No const folding on asm db,dw, etc
https://issues.dlang.org/show_bug.cgi?id=697 --- Comment #8 from Vladimir Panteleev--- Stewart, "someone" is not enough. For a bug report to be useful, anyone should be able to reproduce the issue. There is very little value in keeping open a bug report where you have to go on an archaeology quest to find crucial details. Since you still have the files, please attach them here (or to a new bug report)? --
Re: proposed @noreturn attribute
On Tuesday, 18 July 2017 at 22:03:27 UTC, Walter Bright wrote: The issue here (for me) is to have a type system that matches type systems used in type theory. D already has strong abilities to do type calculus. Instead of inventing our own whackadoodle scheme, one hack at a time, why not match existing type calculus? Then, attempts to do type calculus in D will work as worked out by type theory. Or, we could go with the C++ approach which historically is to add an ad-hoc solution for an existing problem, and then another ad-hoc solution for the whacky effects that turned out to have, rinse, repeat. (Look at all the different ways to do type deduction, a horrifying consequence. Or function overloading, which started with complex special cases, then changed to partial ordering for special cases.) There is just something fundamentally wrong with: @noreturn int foo(); I would understand it to mean that if it were to return, foo would return an int but it is undefined behaviour for foo to dynamically return. returning a value yet not returning. It smacks of "the language designer(s) are idiots." It winds up complicating things like: auto x = a ? b : foo(); What is the type of x? @noreturn means a special case. A proper bottom type means it is not a special case. int. @noreturn need not pollute the type, given the use cases for @noreturn. Namely to document that the function does not dynamically return and aid the compiler in optimisation (are there any other uses?). `assert(0);` is already accepted in the front end as an acceptable return "value" for any type e.g. in Bar foo(int x) { foreach (e; data[]) if (e.x == x) return e; assert(0); } The language semantics and compiler internals should be simpler and cleaner by using accepted type theory. Not for LDC or GDC. They already have the ability to signal to their backends that a function does not dynamically return. as I have posted before, one can do (in core.attribute), enum __noreturn; version(LDC) { import ldc.attributes : llvmAttr; alias noreturn = AliasSeq!(llvmAttr("noreturn"),__noreturn); } else version(GNU) { import gcc.attribute : llvmAttr; alias noreturn = AliasSeq!(attribute("noreturn"),__noreturn); } else // DMD { alias noreturn = __noreturn; } for a complete implementation for LDC and GDC, and DMD can do whatever it needs to with the presence of __noreturn, including fronted semantic analysis.
Re: proposed @noreturn attribute
On Tuesday, 18 July 2017 at 22:03:27 UTC, Walter Bright wrote: On 7/17/2017 4:26 PM, H. S. Teoh via Digitalmars-d wrote: But the point is that so much time and effort is being spent on discussing and designing a feature that you have admitted yourself to be "rarely used". As a disinterested bystander I find it somewhat amusing (and sad) to see so much over-engineering of an overly-complex system involving a new basic type in the language, which in turn entails all sorts of corner cases in how it will interact with existing types and constructs, not to mention the implementation complexities that will be involved to pull it off -- all for what? Just to be able to say "function F doesn't return". Seems like disproportionate effort for only marginal returns (har har). The issue here (for me) is to have a type system that matches type systems used in type theory. D already has strong abilities to do type calculus. Instead of inventing our own whackadoodle scheme, one hack at a time, why not match existing type calculus? Then, attempts to do type calculus in D will work as worked out by type theory. Or, we could go with the C++ approach which historically is to add an ad-hoc solution for an existing problem, and then another ad-hoc solution for the whacky effects that turned out to have, rinse, repeat. (Look at all the different ways to do type deduction, a horrifying consequence. Or function overloading, which started with complex special cases, then changed to partial ordering for special cases.) [...] Agreed. Discovered vs invented as Philip Wadler classifies the two approaches in his talk: https://www.youtube.com/watch?v=IOiZatlZtGU, which I highly recommend watching.
Re: newCTFE Status July 2017
On Tuesday, 18 July 2017 at 19:23:56 UTC, Stefan Koch wrote: On Tuesday, 18 July 2017 at 19:11:37 UTC, H. S. Teoh wrote: Shouldn't there be a way to reduce the test case so that you don't have to look through 300 temporaries? Yes. However, there is not automated way to reduce it. So to find the source-code which actually leads to the mis-compiled part. I still have to consider an awful lot of code :) Why can't you use DustMite? It's an amazing tool! https://github.com/CyberShadow/DustMite/wiki
Re: Is it possible to generate a pool of random D or D inline assembler programs, run them safely?
On Tuesday, 18 July 2017 at 17:35:17 UTC, Enjoys Math wrote: Without them crashing the app running them? Say by wrapping with try / catch? Run them in a separate process, so it can die independently.
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 22:41:13 UTC, Ali Çehreli wrote: On 07/16/2017 10:24 AM, Jean-Louis Leroy wrote: Hello, TL;DR: see here https://github.com/jll63/methods.d/blob/master/README.md Added D to the Wikipedia entry, which can be expanded. :) https://en.wikipedia.org/wiki/Multiple_dispatch Ali Haha that settles it then, openmethods it is! I'll rename the repo and upload to the registry momentarily.
Re: New library: open multi-methods
On 07/16/2017 10:24 AM, Jean-Louis Leroy wrote: Hello, TL;DR: see here https://github.com/jll63/methods.d/blob/master/README.md Added D to the Wikipedia entry, which can be expanded. :) https://en.wikipedia.org/wiki/Multiple_dispatch Ali
Re: proposed @noreturn attribute
On 18.07.2017 23:35, Moritz Maxeiner wrote: Could you explain why `return foo();` is even legal for a `void foo() {}`? Because the ad-hoc decision to make void a type that is not really a type leads to unnecessary friction, and this exceptional rule removes the friction in one common special case. I wasn't aware of it before and the fact that you can (syntactically) return the non-existent return value of `foo` raises cognitive dissonance flags for me. I imagine there's a type system reason? There should be. foo's return type could be a unit type, with just one value. Then foo does have a return value, but it is always the same and so does not need to be explicitly tracked.
[Issue 16079] memoize should cache objects too
https://issues.dlang.org/show_bug.cgi?id=16079 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/dlang/phobos https://github.com/dlang/phobos/commit/9e58ecab2aa6eb2d800d1e7e0635f7eee1a774aa Fix issue 16079 - memoize should work with arrays and objects https://github.com/dlang/phobos/commit/aefb5892a3ee1dbbb3433db951e261f3a1b5635c Merge pull request #4367 from wilzbach/fix_16079 Fix issue 16079 - memoize should work with arrays and objects --
Re: proposed @noreturn attribute
On Tuesday, 18 July 2017 at 21:45:27 UTC, Adam D. Ruppe wrote: On Tuesday, 18 July 2017 at 21:35:21 UTC, Moritz Maxeiner wrote: Could you explain why `return foo();` is even legal for a `void foo() {}`? Suppose you are writing a template function that forwards: auto forward(alias fun, T...)(T args) { return fun(args); } It just saves you from having to static if(fun returns void). That's a good pragmatic (syntactic sugar) reason, thanks.
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 21:20:04 UTC, jmh530 wrote: On Tuesday, 18 July 2017 at 21:16:11 UTC, jmh530 wrote: I may not have been clear enough. My ideal solution wouldn't make any changes to that densematrix.d file, just the interface. So I don't have any issue with the matrix modules doing the math and the app doing the printing. Well, I suppose the matrix interface would be saying that it can print, so maybe not as split up as you would like. While you could define a separate interface for printing, that would require a change to densematrix. Exactly. Orthogonality is essential for good composition, that is the reason why OOP - well, the OOP that follows the Simula/Smalltalk tradition - failed so badly. CLOS got it right 40 years ago; Simula, Smalltalk, C++, Java, etc they all got it wrong.
Re: An Issue I Wish To Raise Awareness On
Am Tue, 18 Jul 2017 18:10:58 + schrieb Atila Neves: > Now I've read your post properly: there is only one destructor. > With the fix I mentioned, just don't defined the `shared` > version, there's no need to. Postblit is still a problem, however. > > Atila The issue is wider than just `shared` by the way: https://issues.dlang.org/show_bug.cgi?id=13628 Some may jump to say that an immutable struct can't be destructed, but my perspective here is that immutable only applies to what the compiler can introspect. A file descriptor or an opaque struct pointer from a C API are just flat values and escape the compiler. They can be stored in an immutable struct and still need `close()` called on them. Layman's head-const :p -- Marco
Re: proposed @noreturn attribute
On 7/17/2017 4:26 PM, H. S. Teoh via Digitalmars-d wrote: But the point is that so much time and effort is being spent on discussing and designing a feature that you have admitted yourself to be "rarely used". As a disinterested bystander I find it somewhat amusing (and sad) to see so much over-engineering of an overly-complex system involving a new basic type in the language, which in turn entails all sorts of corner cases in how it will interact with existing types and constructs, not to mention the implementation complexities that will be involved to pull it off -- all for what? Just to be able to say "function F doesn't return". Seems like disproportionate effort for only marginal returns (har har). The issue here (for me) is to have a type system that matches type systems used in type theory. D already has strong abilities to do type calculus. Instead of inventing our own whackadoodle scheme, one hack at a time, why not match existing type calculus? Then, attempts to do type calculus in D will work as worked out by type theory. Or, we could go with the C++ approach which historically is to add an ad-hoc solution for an existing problem, and then another ad-hoc solution for the whacky effects that turned out to have, rinse, repeat. (Look at all the different ways to do type deduction, a horrifying consequence. Or function overloading, which started with complex special cases, then changed to partial ordering for special cases.) There is just something fundamentally wrong with: @noreturn int foo(); returning a value yet not returning. It smacks of "the language designer(s) are idiots." It winds up complicating things like: auto x = a ? b : foo(); What is the type of x? @noreturn means a special case. A proper bottom type means it is not a special case. I recall that Rust initially did @noreturn as a special case, and later replaced that with a bottom type and integrated it into the type system. I understand that this had a positive ripple effect, such as reducing special cases in user generic code. Noreturn functions are just a happy fallout of doing this correctly in the first place. The language semantics and compiler internals should be simpler and cleaner by using accepted type theory.
Re: proposed @noreturn attribute
On Tuesday, 18 July 2017 at 21:35:21 UTC, Moritz Maxeiner wrote: Could you explain why `return foo();` is even legal for a `void foo() {}`? Suppose you are writing a template function that forwards: auto forward(alias fun, T...)(T args) { return fun(args); } It just saves you from having to static if(fun returns void).
Re: proposed @noreturn attribute
On Tuesday, 18 July 2017 at 20:49:56 UTC, Timon Gehr wrote: On 18.07.2017 20:46, Yuxuan Shui wrote: On Tuesday, 18 July 2017 at 15:26:59 UTC, Timon Gehr wrote: On 18.07.2017 14:19, Stefan Koch wrote: [...] D has a C-inspired first-order type system, so it is not necessarily crucial to have it in D. (The reason I got involved in this thread is that it was proposed to add Bottom as a type that is not really a type; 'void' is annoying enough as the 'null' of types. We don't really need another one of those.) [...] What about void? You can't have a value of type void, but it is not empty either. For example, this means that the following transformation is not always valid: return foo(); Could you explain why `return foo();` is even legal for a `void foo() {}`? I wasn't aware of it before and the fact that you can (syntactically) return the non-existent return value of `foo` raises cognitive dissonance flags for me. I imagine there's a type system reason?
Re: Appending static arrays
On Tuesday, 18 July 2017 at 12:39:01 UTC, Stefan Koch wrote: whhhahhh template bloat Yes, and also very slow. :)
Re: Mixin function names
On Tuesday, 18 July 2017 at 21:29:05 UTC, Timon Gehr wrote: On 18.07.2017 23:28, Moinak Bhattacharrya wrote: On Tuesday, 18 July 2017 at 21:22:47 UTC, Timon Gehr wrote: On 18.07.2017 22:57, Moinak Bhattacharrya wrote: Is it possible to mixin function names? IE something like this: template strFunc(string s){ int mixin(s)(int a){ return a+1; } } ... No. If not, is something like this being looked at? The suggestion has been made, but there was no extensive discussion so far. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md#mixin-identifiers That's the DIP for static foreach. Is there a separate DIP for mixin identifiers? Not yet. :( I might look into making one, then. This feature would scratch a rather sizable itch.
[Issue 15933] GDC support for core.cpuid
https://issues.dlang.org/show_bug.cgi?id=15933 Marco Leisechanged: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Marco Leise --- This was fixed in 2.072 with commit https://github.com/dlang/druntime/commit/c230cd4d52de1b05d15f61f6fb6d0e74b084f5c9pidgi as far as I understand the tag range given by GitHub. --
Re: Mixin function names
On 18.07.2017 23:28, Moinak Bhattacharrya wrote: On Tuesday, 18 July 2017 at 21:22:47 UTC, Timon Gehr wrote: On 18.07.2017 22:57, Moinak Bhattacharrya wrote: Is it possible to mixin function names? IE something like this: template strFunc(string s){ int mixin(s)(int a){ return a+1; } } ... No. If not, is something like this being looked at? The suggestion has been made, but there was no extensive discussion so far. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md#mixin-identifiers That's the DIP for static foreach. Is there a separate DIP for mixin identifiers? Not yet.
Re: Mixin function names
On Tuesday, 18 July 2017 at 21:22:47 UTC, Timon Gehr wrote: On 18.07.2017 22:57, Moinak Bhattacharrya wrote: Is it possible to mixin function names? IE something like this: template strFunc(string s){ int mixin(s)(int a){ return a+1; } } ... No. If not, is something like this being looked at? The suggestion has been made, but there was no extensive discussion so far. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md#mixin-identifiers That's the DIP for static foreach. Is there a separate DIP for mixin identifiers?
Re: Adding flags to dub build
On Tuesday, 18 July 2017 at 20:12:13 UTC, Jean-Louis Leroy wrote: On Tuesday, 18 July 2017 at 20:00:48 UTC, Guillaume Piolat wrote: On Tuesday, 18 July 2017 at 19:49:35 UTC, Jean-Louis Leroy wrote: Hi, I want to add a few flags while building with dub. I tried: DFLAGS='-d-version=explain' dub test ... ...but DFLAGS does not seem to be honored. In fact I wouldn't mind adding a builtType to my dub.sdl (but then will it be inherited by the subpackages) but I don't see how to specify flags there either...maybe because it tries to hide variations in compiler switches? J-L Use "dflags" or "lflags" (linker) It doesn't work either... It's a build setting [1], not a command line option, you set it in the package file (dub.json/dub.sdl)... https://code.dlang.org/package-format?lang=json#build-settings
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 21:16:11 UTC, jmh530 wrote: I may not have been clear enough. My ideal solution wouldn't make any changes to that densematrix.d file, just the interface. So I don't have any issue with the matrix modules doing the math and the app doing the printing. Well, I suppose the matrix interface would be saying that it can print, so maybe not as split up as you would like. While you could define a separate interface for printing, that would require a change to densematrix.
Re: Mixin function names
On 18.07.2017 22:57, Moinak Bhattacharrya wrote: Is it possible to mixin function names? IE something like this: template strFunc(string s){ int mixin(s)(int a){ return a+1; } } ... No. If not, is something like this being looked at? The suggestion has been made, but there was no extensive discussion so far. https://github.com/dlang/DIPs/blob/master/DIPs/DIP1010.md#mixin-identifiers
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 19:22:38 UTC, Jean-Louis Leroy wrote: Look at https://github.com/jll63/methods.d/blob/master/examples/matrix/source/matrix.d and https://github.com/jll63/methods.d/blob/master/examples/matrix/source/densematrix.d They know nothing about printing. They don't want to. The matrix modules do math, the app does printing. J-L I may not have been clear enough. My ideal solution wouldn't make any changes to that densematrix.d file, just the interface. So I don't have any issue with the matrix modules doing the math and the app doing the printing. For instance, consider the traits in Rust https://doc.rust-lang.org/book/first-edition/traits.html My idea is like making the interfaces in D similar to the traits in Rust (or at least having the option to do something similar with them). Your @method void _print(Matrix m) would be similar to impl print for Matrix in Rust. Nevertheless, I get that it may be a difficult thing to implement.
Re: Mixin function names
On Tuesday, 18 July 2017 at 20:57:51 UTC, Moinak Bhattacharrya wrote: Is it possible to mixin function names? IE something like this: Only if you mixin the entire function. But what I like to do is to write the function with some internal name, then do `mixin("alias "~ new_name ~ " = your_internal_name;");` so it is available as new name but still written normally.
[Issue 17663] New: header generation (-H) is broken with public override of private default
https://issues.dlang.org/show_bug.cgi?id=17663 Issue ID: 17663 Summary: header generation (-H) is broken with public override of private default Product: D Version: D2 Hardware: All URL: http://dlang.org/ OS: All Status: NEW Severity: enhancement Priority: P3 Component: dmd Assignee: nob...@puremagic.com Reporter: e...@weka.io Example breakage: // test_di_gen.d: private: public struct Export {} dmd -H generates the following di file: // D import file generated from 'test_di_gen.d' private public struct Export { } Needless to say "private public" does not compile. background: I use "private:" in beginning of all my modules/structs to reverse the default - I want my exports to be explicit and narrow. --
Re: Building DMD on OpenBSD
On Tuesday, 18 July 2017 at 05:11:30 UTC, Kai Nacke wrote: In master there is already some OpenBSD support. Some time ago I worked on druntime support but I still need to finish this. Mostly there is nothing magic here - just translating the header files. The only non-obvious work is required for the module/shared library stuff (in rt.sections). If there is an OpenBSD expert around who can help here it would be nice. Maybe talk to OpenBSD porters on their mailing list. Ill put my stuff on github as soon as I can.
Re: Mixin function names
On Tuesday, 18 July 2017 at 20:57:51 UTC, Moinak Bhattacharrya wrote: Is it possible to mixin function names? IE something like this: template strFunc(string s){ int mixin(s)(int a){ return a+1; } } If not, is something like this being looked at? Or, just something like this for any variable name.
Mixin function names
Is it possible to mixin function names? IE something like this: template strFunc(string s){ int mixin(s)(int a){ return a+1; } } If not, is something like this being looked at?
Re: Adding flags to dub build
On Tuesday, 18 July 2017 at 20:12:13 UTC, Jean-Louis Leroy wrote: On Tuesday, 18 July 2017 at 20:00:48 UTC, Guillaume Piolat wrote: On Tuesday, 18 July 2017 at 19:49:35 UTC, Jean-Louis Leroy wrote: Hi, I want to add a few flags while building with dub. I tried: DFLAGS='-d-version=explain' dub test ... ...but DFLAGS does not seem to be honored. In fact I wouldn't mind adding a builtType to my dub.sdl (but then will it be inherited by the subpackages) but I don't see how to specify flags there either...maybe because it tries to hide variations in compiler switches? J-L Use "dflags" or "lflags" (linker) It doesn't work either... The Source holds all the answers ;-) DFLAGS='-d-version=explain' dub test openmethods:benchmarks --build '$DFLAGS' ... Performing "$DFLAGS" build using ldc2 for x86_64. ...
Re: proposed @noreturn attribute
On 18.07.2017 20:46, Yuxuan Shui wrote: On Tuesday, 18 July 2017 at 15:26:59 UTC, Timon Gehr wrote: On 18.07.2017 14:19, Stefan Koch wrote: [...] D has a C-inspired first-order type system, so it is not necessarily crucial to have it in D. (The reason I got involved in this thread is that it was proposed to add Bottom as a type that is not really a type; 'void' is annoying enough as the 'null' of types. We don't really need another one of those.) [...] What about void? You can't have a value of type void, but it is not empty either. For example, this means that the following transformation is not always valid: return foo(); <-> auto x = foo(); return x;
[Issue 697] No const folding on asm db,dw, etc
https://issues.dlang.org/show_bug.cgi?id=697 --- Comment #7 from Stewart Gordon--- (In reply to Vladimir Panteleev from comment #6) > The original test case as presented in the issue description now works, as > per comment 3, so I'm going to close this. > > (In reply to Don from comment #5) > > I'm reopening this since there are 7 dstress bugs which depend on it. > > DStress is no longer online, so these are no longer easily available. Doesn't follow - somebody might have a local copy of Dstress from back in the day. Indeed, I've found that I have. Not sure how complete it is, but I've found all of those listed in comment 5 therein. As I try under DMD 2.074, they all give a compile error. --
Re: Adding flags to dub build
On Tuesday, 18 July 2017 at 20:00:48 UTC, Guillaume Piolat wrote: On Tuesday, 18 July 2017 at 19:49:35 UTC, Jean-Louis Leroy wrote: Hi, I want to add a few flags while building with dub. I tried: DFLAGS='-d-version=explain' dub test ... ...but DFLAGS does not seem to be honored. In fact I wouldn't mind adding a builtType to my dub.sdl (but then will it be inherited by the subpackages) but I don't see how to specify flags there either...maybe because it tries to hide variations in compiler switches? J-L Use "dflags" or "lflags" (linker) It doesn't work either... dflags='-d-version=explain' dub --vverbose test openmethods:benchmarks --build release --force Using dub registry url 'http://code.dlang.org/' Refreshing local packages (refresh existing: true)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/jleroy/.dub/packages/local-packages.json Determined package version using GIT: openmethods 0.0.1+commit.5.g94ad5a9 Refreshing local packages (refresh existing: false)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/jleroy/.dub/packages/local-packages.json Collecting dependencies for openmethods Building package openmethods:benchmarks in /home/jleroy/dev/d/methods.d/benchmarks/ Refreshing local packages (refresh existing: false)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/jleroy/.dub/packages/local-packages.json Collecting dependencies for openmethods:benchmarks Adding local /home/jleroy/dev/d/methods.d/ Found dependency openmethods >=0.0.0 @../ Collecting dependencies for openmethods Checking for missing dependencies. Configurations used for dependency resolution: openmethods (0): [invalid, 0.0.1+commit.5.g94ad5a9] Interation (ci=0) openmethods invalid (C) Interation (ci=-1) openmethods 0.0.1+commit.5.g94ad5a9 Refreshing local packages (refresh existing: false)... Looking for local package map at /var/lib/dub/packages/local-packages.json Looking for local package map at /home/jleroy/.dub/packages/local-packages.json Collecting dependencies for openmethods:benchmarks Adding local /home/jleroy/dev/d/methods.d/ Found dependency openmethods >=0.0.0 @../ Collecting dependencies for openmethods Checking for upgrades. Using cached upgrade results... Package methods can be installed with version 0.0.1. Use "dub upgrade" to perform those changes. Add config openmethods library Add config openmethods:benchmarks Including openmethods:benchmarks -> openmethods library openmethods:benchmarks -> openmethods library Using configuration 'library' for openmethods Using configuration '' for openmethods:benchmarks Add config openmethods library Add config openmethods:benchmarks application Including openmethods:benchmarks application -> openmethods library openmethods:benchmarks application -> openmethods library Using configuration 'library' for openmethods Using configuration 'application' for openmethods:benchmarks Creating build generator. Add config openmethods:benchmarks application Add config openmethods library Including openmethods:benchmarks application -> openmethods library openmethods:benchmarks application -> openmethods library Using configuration 'application' for openmethods:benchmarks Using configuration 'library' for openmethods Gathering build settings for openmethods:benchmarks (application) Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ source/benchmarks.d Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ source/ Executable configuration "application" of package openmethods:benchmarks defines no main source file, this may cause certain build modes to fail. Add an explicit "mainSourceFile" to the package description to fix this. Gathering build settings for openmethods (library) Fixing relative path: /home/jleroy/dev/d/methods.d/ ~ source/ Configuration 'application' does not output a library. Falling back to "dub -b unittest -c application". Add config openmethods:benchmarks application Add config openmethods library Including openmethods:benchmarks application -> openmethods library openmethods:benchmarks application -> openmethods library Using configuration 'application' for openmethods:benchmarks Using configuration 'library' for openmethods Fixing relative path: /home/jleroy/dev/d/methods.d/ ~ source/openmethods.d Fixing relative path: /home/jleroy/dev/d/methods.d/ ~ source/ Fixing relative path: /home/jleroy/dev/d/methods.d/ ~ . Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ source/benchmarks.d Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ source/ Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ . Fixing relative path: /home/jleroy/dev/d/methods.d/benchmarks/ ~ source/benchmarks.d Fixing relative path:
Re: New library: open multi-methods
On 07/18/2017 12:22 PM, Jean-Louis Leroy wrote: > Look at > https://github.com/jll63/methods.d/blob/master/examples/matrix/source/matrix.d > and > https://github.com/jll63/methods.d/blob/master/examples/matrix/source/densematrix.d > They know nothing about printing. They don't want to. The matrix modules > do math, the app does printing. Related, our friend Luís Marques was the speaker in January 2016 here at the DLang Silicon Valley meetup. "A defense of so-called anemic domain models": https://www.meetup.com/D-Lang-Silicon-Valley/events/228027468/ I'm totally sold on the idea. Ali
Re: Adding flags to dub build
On Tuesday, 18 July 2017 at 19:49:35 UTC, Jean-Louis Leroy wrote: Hi, I want to add a few flags while building with dub. I tried: DFLAGS='-d-version=explain' dub test ... ...but DFLAGS does not seem to be honored. In fact I wouldn't mind adding a builtType to my dub.sdl (but then will it be inherited by the subpackages) but I don't see how to specify flags there either...maybe because it tries to hide variations in compiler switches? J-L Use "dflags" or "lflags" (linker)
Re: DMD library available as DUB package
On Tuesday, 18 July 2017 at 12:07:27 UTC, Jacob Carlborg wrote: During the dconf hackathon I set out to create a DUB package for DMD to be used as a library. This has finally been merged [1] and is available here [2]. It contains the lexer and the parser. A minimal example: #!/usr/bin/env dub /++ dub.sdl: name "dmd_lexer_example" dependency "dmd" version="~master" +/ void main() { import ddmd.lexer; import ddmd.tokens; import std.stdio; immutable sourceCode = "void test() {} // foobar"; scope lexer = new Lexer("test", sourceCode.ptr, 0, sourceCode.length, 0, 0); while (lexer.nextToken != TOKeof) writeln(lexer.token.value); } [1] https://github.com/dlang/dmd/pull/6771 [2] http://code.dlang.org/packages/dmd Awesome, was waiting for this.
Adding flags to dub build
Hi, I want to add a few flags while building with dub. I tried: DFLAGS='-d-version=explain' dub test ... ...but DFLAGS does not seem to be honored. In fact I wouldn't mind adding a builtType to my dub.sdl (but then will it be inherited by the subpackages) but I don't see how to specify flags there either...maybe because it tries to hide variations in compiler switches? J-L
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 18:03:30 UTC, jmh530 wrote: On Tuesday, 18 July 2017 at 16:57:30 UTC, Ali Çehreli wrote: Perhaps they are all needed but I'm thinking about the need for forward declaration, the need for the underscore prefix, etc. He might be able to at least get rid of the forward declaration (not sure on the underscore). The way it works now is that a class that inherits from an interface is not required in any way to implement the methods. Suppose he adds another attribute to an interface such that any class that inherits from it is required to have methods defined for specific functions. So for instance, the Matrix example might look something like @trait interface Matrix { @property int rows() const; @property int cols() const; @property double at(int i, int j) const; @trait void print(); } I'm not sure this would work because anything that derives from Matrix must implement print. However, if it is possible to use the attribute to allow the derived classes to ignore print, then it might work. Alternately, if there is a way to process the interface and tell the compiler to somehow ignore the @trait member functions. I don't know if it'll work, but it's an idea. Anyway, the mixin(registerMethods); could then be adjusted so that void print(virtual!Matrix m); is mixed in automatically because we now know how to construct it. There are at least problems with this. Firstly it is intrusive - something I strive to avoid (although I could be 100% orthogonal only because I hijack a deprecated pointer in ClassInfo). Also, some methods may want to treat Matrix as a virtual argument, and some not. Look at https://github.com/jll63/methods.d/blob/master/examples/matrix/source/matrix.d and https://github.com/jll63/methods.d/blob/master/examples/matrix/source/densematrix.d They know nothing about printing. They don't want to. The matrix modules do math, the app does printing. J-L
Re: newCTFE Status July 2017
On Tuesday, 18 July 2017 at 19:11:37 UTC, H. S. Teoh wrote: Shouldn't there be a way to reduce the test case so that you don't have to look through 300 temporaries? Yes. However, there is not automated way to reduce it. So to find the source-code which actually leads to the mis-compiled part. I still have to consider an awful lot of code :)
Re: An Issue I Wish To Raise Awareness On
On Tuesday, July 18, 2017 18:06:56 Atila Neves via Digitalmars-d wrote: > On Tuesday, 18 July 2017 at 15:03:07 UTC, Kagamin wrote: > > On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov > > > > [ZombineDev] wrote: > >> I think Atila was talking about this one: > >> struct A > >> { > >> > >>~this() {} > >> > >> } > >> > >> void main() > >> { > >> > >>auto a = A(); > >>shared b = A(); > >> > >> } > > > > This is strange. There's nothing that suggests that struct A > > and its destructor is thread-safe, yet compiler assumes it is. > > Except for a programmer explicitly and manually calling the > destructor (in which case, don't), the destructor is only ever > called by one thread. It could still be a problem if the struct has a member variable that is a reference type, because then something else could refer to that object, and if it's shared, then you would need to protect it, and the operations that shared prevents should still be prevented. For full-on value types, it should be a non-issue though. - Jonathan M Davis
Re: newCTFE Status July 2017
On Tue, Jul 18, 2017 at 07:08:49PM +, Stefan Koch via Digitalmars-d wrote: [...] > The bad news: > It miscompiles it. > > The generated code is bogus :) > > Fixing this could take a while. > Because even with my improved debugging tools it's still over 3k of > instructions to look through. > > It does not help that over 300 temporaries are allocated. [...] Shouldn't there be a way to reduce the test case so that you don't have to look through 300 temporaries? T -- Valentine's Day: an occasion for florists to reach into the wallets of nominal lovers in dire need of being reminded to profess their hypothetical love for their long-forgotten.
Re: static foreach is now in github master
On Tuesday, 18 July 2017 at 10:02:10 UTC, Seb wrote: On Monday, 17 July 2017 at 21:27:40 UTC, Martin Nowak wrote: On Monday, 17 July 2017 at 18:14:35 UTC, Andrei Alexandrescu wrote: For those who want to play with our new static foreach feature and are willing to take the steps to building their own dmd, Or just wait for the next nightly until tomorrow around 5AM UTC. curl -fsS https://dlang.org/install.sh | bash -s dmd-nightly the feature is now merged in master: https://github.com/dlang/dmd/pull/6760 Great news. And thanks to dmd-nightly, also on run.dlang.io: https://run.dlang.io/?compiler=dmd-nightly=void%20main(string%5B%5D%20args)%0A%7B%0A%20%20%20%20static%20foreach%20(i;%20%5B0,1,2,3%5D)%0A%09%7B%0A%20%20%20%20%09pragma(msg,%20i);%0A%09%7D%0A%7D Cool! Thank you!
Re: newCTFE Status July 2017
On Thursday, 13 July 2017 at 12:45:19 UTC, Stefan Koch wrote: [ ... ] Hi Guys, I have good news and bad news. The good news: newCTFE just compiled my own version of std.bitmanip.bitfields dubbed fastFields. which can be seen here: https://gist.github.com/UplinkCoder/b3501425a4fb4992c6cf1c77d6c3638a The bad news: It miscompiles it. The generated code is bogus :) Fixing this could take a while. Because even with my improved debugging tools it's still over 3k of instructions to look through. It does not help that over 300 temporaries are allocated. -- Stefan
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 18:21:21 UTC, Ali Çehreli wrote: That reminds me: Would the following be possible and better? // From void main() { updateMethods(); // ... } // To mixin(constructMethods()); void main() { // ... } constructMethods() could return the following string: string constructMethods() { return q{ shared static this() { updateMethods(); } }; } If I'm not missing something, this is better because nothing needs to be added to main and the methods are available before main starts executing (module initialization order issues still apply.). Ah, I would love to get rid of that call in main(), but think beyond a one module program. The matrix example (https://github.com/jll63/methods.d/tree/master/examples/matrix/source) consists in three separate modules, plus an app, all defining specializations. They need the mixin, but if we put updateMehods() in there, it will be called many times. And it is a costly operation. Guarding the call with a flag will not work, because more methods may be registered afterwards. Unless you can think of a way the last mixin can detect it's the last? Incidentally, in yomm11 that function (it's called initialize()) has to be called before any method is called, after any shared object/DLL is loaded and after a DLL is unloaded. I still have to write the code to de-register the methods and the specializations in that case by the way... J-L J-L
Re: proposed @noreturn attribute
On Tuesday, 18 July 2017 at 15:26:59 UTC, Timon Gehr wrote: On 18.07.2017 14:19, Stefan Koch wrote: [...] D has a C-inspired first-order type system, so it is not necessarily crucial to have it in D. (The reason I got involved in this thread is that it was proposed to add Bottom as a type that is not really a type; 'void' is annoying enough as the 'null' of types. We don't really need another one of those.) [...] What about void?
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 16:57:30 UTC, Ali Çehreli wrote: > As for performance, I have a first result: > https://github.com/jll63/methods.d/blob/master/benchmarks/source/benchmarks.d#L122 > but I still have to implement the "first argument optimization". I am > working on it. I could use some explanation for the results but I can for the blog article. ;) I pit a method-based call against its equivalent using virtual functions. First calling a virtual function via a base class is pitted against a method with one virtual parameter. Then the same but calling via an interface. Lastly, I compare double dispatch with a method with two virtual arguments. I use std.datetime.comparingBenchmark, which reports the result as time(base)/time(target). So open methods are a bit slower than ordinary virtual function calls but not that much. In the meantime I have applied a second optimization for unary methods and this brings them within 33% of an ordinary, compiler implemented vfunc call. Which is OK because the situation is highly artificial. If the function does anything, the difference will be imperceptible. I am more annoyed by double dispatch beating binary methods. I will have to look at the assembler, but it may be that the index pointer is too far from the object. To begin the real work, I need to fetch that pointer form an object. Currently it is stored in ClassInfo.deallocator, so I have to 1/ fetch the vptr 2/ fetch the ClassInfo* 3/ fetch 'deallocator'. What happens next depends on the arity. Any chance of Walter giving me a pointer in the vtable? Aside the ClassInfo*? Or at least a pointer in ClassInfo, or reassign the deallocator when it is eventually retired? It's not surprising that ldc (and gdc) can be much better than dmd in optimization. I would like to try gdc but it conflicts with ldc2 - you know, the "alias __va_list = __va_list_tag;" issue. I found suggestions via google but nothing worked for me so far. By the way, I'm in awe of your D skills in such a short time! Thanks :) I found out that D was much more natural, "predictable" than C++. The most cryptic error messages happened when I forgot the "!", IIRC. I'm sure there are parts of the code that can be cleaned up but it's taking advantage of many powerful features of the language. I still think the usage can be made easier but I'm not sure yet. I hope others will take a look at the code and come up with an easier interface. Perhaps they are all needed but I'm thinking about the need for forward declaration, the need for the underscore prefix, etc. (in reverse order) Regarding the prefix, it is needed to prevent overload resolution from trumping dynamic dispatch - see here: https://github.com/jll63/methods.d/blob/master/examples/whytheunderscore/source/app.d Allowing the same name would necessitate compiler support. As for the the forward declaration - I don't think it is possible to dispense with it. All open methods systems I know of have it (defgeneric in CLOS, defmulti in Clojure, Stroustrup's proposal...). Consider: class A { } class B : A { } class X : B { } class Y : B { } @method void _foo(virtual!X x) { ... } @method void _foo(virtual!Y x) { ... } What is the base method? foo(B)? foo(A)? It may well be the latter. Also don't forget that the complete specialization set is known, at the earliest, at link time. If you (arbitrarily) pick foo(B), another module may introduce a B or an A specialization. As for suggestions and advise, they are very welcome :) already got a couple of PRs. Here are the remaining questions on my mind: - the module/package name: I am pretty much set on openmethods though... - throw an exception if a method is not define for the argument set, or ambiguous: having big doubts about this. We want the possibility of @nothrow methods, don't we? So I will probably call a delegate via a pointer (a la C++) which, by default, will abort(). - the method prefix: hesitating between just _ or maybe m_ ??? - replace version(explain) with debug levels?
Re: New library: open multi-methods
On 07/18/2017 11:03 AM, jmh530 wrote: > the mixin(registerMethods); could then be adjusted so that void > print(virtual!Matrix m); is mixed in automatically because we now know > how to construct it. That reminds me: Would the following be possible and better? // From void main() { updateMethods(); // ... } // To mixin(constructMethods()); void main() { // ... } constructMethods() could return the following string: string constructMethods() { return q{ shared static this() { updateMethods(); } }; } If I'm not missing something, this is better because nothing needs to be added to main and the methods are available before main starts executing (module initialization order issues still apply.). Ali
Re: proposed @noreturn attribute
On Monday, 17 July 2017 at 18:54:37 UTC, H. S. Teoh wrote: On Mon, Jul 17, 2017 at 02:10:27PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...] [...] IMO, the observations "used rarely" and "attention-seeking notation" are better satisfied by an attribute named @noreturn than some strange, convoluted, arcane invocation like `typeof(assert(0))`. Because: [...] object.d: alias noreturn = typeof(assert(0)); Atila
Re: An Issue I Wish To Raise Awareness On
On Monday, 17 July 2017 at 19:30:53 UTC, Jack Stouffer wrote: On Monday, 17 July 2017 at 17:41:58 UTC, Atila Neves wrote: On Monday, 17 July 2017 at 14:26:19 UTC, Jack Stouffer wrote: TL;DR: Issue 17658 [1] makes using shared very annoying/practically impossible. [...] I fixed this already, should be in the next release. Atila Are you sure? Because DMD nightly still errors: https://run.dlang.io?compiler=dmd-nightly=struct%20A%0A%7B%0A%20%20%20%20this(string%20a)%20%7B%7D%0A%20%20%20%20this(string%20a)%20shared%20%7B%7D%0A%0A%20%20%20%20~this()%20%7B%7D%0A%20%20%20%20~this()%20shared%20%7B%7D%0A%0A%20%20%20%20this(this)%20%7B%7D%0A%20%20%20%20this(this)%20shared%20%7B%7D%0A%7D%0A%0Avoid%20main()%0A%7B%0A%20%20%20%20shared%20f%20%3D%20A(%22%22)%3B%0A%7D (maybe we should remove the ban on URL shorteners for our own sites) Now I've read your post properly: there is only one destructor. With the fix I mentioned, just don't defined the `shared` version, there's no need to. Postblit is still a problem, however. Atila
Re: An Issue I Wish To Raise Awareness On
On Tuesday, 18 July 2017 at 15:03:07 UTC, Kagamin wrote: On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov [ZombineDev] wrote: I think Atila was talking about this one: struct A { ~this() {} } void main() { auto a = A(); shared b = A(); } This is strange. There's nothing that suggests that struct A and its destructor is thread-safe, yet compiler assumes it is. Except for a programmer explicitly and manually calling the destructor (in which case, don't), the destructor is only ever called by one thread. Atila
Re: New library: open multi-methods
On Tuesday, 18 July 2017 at 16:57:30 UTC, Ali Çehreli wrote: Perhaps they are all needed but I'm thinking about the need for forward declaration, the need for the underscore prefix, etc. He might be able to at least get rid of the forward declaration (not sure on the underscore). The way it works now is that a class that inherits from an interface is not required in any way to implement the methods. Suppose he adds another attribute to an interface such that any class that inherits from it is required to have methods defined for specific functions. So for instance, the Matrix example might look something like @trait interface Matrix { @property int rows() const; @property int cols() const; @property double at(int i, int j) const; @trait void print(); } I'm not sure this would work because anything that derives from Matrix must implement print. However, if it is possible to use the attribute to allow the derived classes to ignore print, then it might work. Alternately, if there is a way to process the interface and tell the compiler to somehow ignore the @trait member functions. I don't know if it'll work, but it's an idea. Anyway, the mixin(registerMethods); could then be adjusted so that void print(virtual!Matrix m); is mixed in automatically because we now know how to construct it.
Is it possible to generate a pool of random D or D inline assembler programs, run them safely?
Without them crashing the app running them? Say by wrapping with try / catch? You can assume that I've limited the opcode addresses to the program and/or the data section which I'll try to put right next to the code. Reason is so I don't have to make my own VM. I want to mutate computable functions in a genetic-algorithm style, so in order to include the full space of computable functions I need a full programming language, or a VM that includes conditional jump instructions. The purpose of it is to make a real-time, short-lived function predictor.
[Issue 16412] instance variable shadowing with inheritance
https://issues.dlang.org/show_bug.cgi?id=16412 feklushkin.de...@gmail.com changed: What|Removed |Added CC||feklushkin.de...@gmail.com --
[Issue 16160] selective imports in aggregation shadow @property functions
https://issues.dlang.org/show_bug.cgi?id=16160 feklushkin.de...@gmail.com changed: What|Removed |Added CC||feklushkin.de...@gmail.com --
Re: How do I cast to from byte[] <-> double for making a small assembler language VM to work?
Thanks for the replies. I will look at 3-address opcodes and consider unions. *Wonders if it matters that Program is a struct with opSlice / opSliceAssign overloaded*.
Re: regex(q"<[^]>")
On Tuesday, 18 July 2017 at 16:34:39 UTC, unDEFER wrote: On Tuesday, 18 July 2017 at 08:56:12 UTC, Anton Fediushin wrote: Not a bug, but I think that `regex()` should fail with a nice exception, not silently fail. Yes, exception, not assert. The forum is not a bugtracker
Re: New library: open multi-methods
On 07/18/2017 12:06 AM, Jean-Louis Leroy wrote: > Yes I will probably write something. You mean on the D Blog? Not necessarily but why not. :) > As for performance, I have a first result: > https://github.com/jll63/methods.d/blob/master/benchmarks/source/benchmarks.d#L122 > but I still have to implement the "first argument optimization". I am > working on it. I could use some explanation for the results but I can for the blog article. ;) It's not surprising that ldc (and gdc) can be much better than dmd in optimization. By the way, I'm in awe of your D skills in such a short time! I'm sure there are parts of the code that can be cleaned up but it's taking advantage of many powerful features of the language. I still think the usage can be made easier but I'm not sure yet. I hope others will take a look at the code and come up with an easier interface. Perhaps they are all needed but I'm thinking about the need for forward declaration, the need for the underscore prefix, etc. Ali
Re: An Issue I Wish To Raise Awareness On
On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov [ZombineDev] wrote: On Monday, 17 July 2017 at 19:30:53 UTC, Jack Stouffer wrote: [...] I think Atila was talking about this one: struct A { ~this() {} } void main() { auto a = A(); shared b = A(); } https://is.gd/kOYlWY That's what I meant. I was on a train and only skimmed through. Atila
Re: Can't get expected strings
On Tuesday, July 18, 2017 13:49:11 helxi via Digitalmars-d-learn wrote: > import std.stdio, std.datetime, std.conv, std.algorithm; > > void main() > { > immutable DEADLINE = DateTime(2017, 7, 16, 23, 59, > 59).to!SysTime; > immutable NOW = Clock.currTime; > immutable INTERVAL = (DEADLINE - NOW) > .abs > .to!string; > //if I put .until("secs") here, it prints > the full-type > //immutable(Until!("a == b", string, > string))("1 day, 23 hours, 47 minutes, 30 secs, 508 ms, 119 μs, > and 6 hnsecs", "secs", yes, false) > > > writeln(INTERVAL); > > //But I don't want these until("secs") below: > if (NOW > DEADLINE) writeln(INTERVAL.until("secs"), "seconds > ago."); > //1 day, 23 hours, 48 minutes, 55 seconds ago. > else if (NOW < DEADLINE) writeln(INTERVAL.until("secs"), > "seconds ahead."); > else writeln("Now."); > } > > - > > > Why is to!string providing inconsistent string? Because the output of Duration.toString strips any units that are 0. It's intended to be human readable, not machine parseable. If you want a specific format, I'd suggest that you grab the units on your own and create the string that you want rather than trying to parse the result of toString. If you want the entire Duration in seconds, then do something like auto diff = Clock.currTime - deadline; writefln("%s seconds ago", diff.total!"seconds"); whereas if you want to split out the units so that you get the seconds portion beyond the minute, then you'd do something like auto diff = Clock.currTime - deadline; writefln("%s seconds ago", diff.split!("minutes", "seconds").seconds); http://dlang.org/phobos/core_time.html#.Duration.total http://dlang.org/phobos/core_time.html#.Duration.split - Jonathan M Davis
Re: regex(q"<[^]>")
On Tuesday, 18 July 2017 at 08:56:12 UTC, Anton Fediushin wrote: Not a bug, but I think that `regex()` should fail with a nice exception, not silently fail. Yes, exception, not assert.
Re: replacement for squeeze and removechars.
On Tuesday, July 18, 2017 15:55:00 Seb via Digitalmars-d-learn wrote: > On Tuesday, 18 July 2017 at 15:41:44 UTC, Meta wrote: > > As Seb somewhat undiplomatically put, there are replacements > > listed in the changelog. > > Sorry - it wasn't intended to be an offense or aggressive. I > consider(ed) RTFM as common internet slang. It is, but you have to be careful with it. It could be "Read the Friendly Manual," or it could be "Read the F@#%ing Manual," depending on the intent of the person writing it, and it's not always clear which the writer means. And it's used so frequently to indicate that someone should have known to read the manual that I expect that a lot of folks are going to take it the wrong way - especially if that's all you say. So, while it _can_ be used in a friendly manner, it's an acronym that I'd avoid. - Jonathan M Davis
Re: How do I cast to from byte[] <-> double for making a small assembler language VM to work?
Maybe use a union? union U { double d; byte[double.sizeof] bytes; } U u; u.bytes = ...; double d = u.d; ... // do something with d // or: U u; u.d = 3.14159; byte[] b = u.bytes[]; ... // do something with b Casting a pointer may run into alignment issues, if your byte[] isn't aligned to a double. T -- Only boring people get bored. -- JM
Re: replacement for squeeze and removechars.
On Tuesday, 18 July 2017 at 15:55:00 UTC, Seb wrote: On Tuesday, 18 July 2017 at 15:41:44 UTC, Meta wrote: As Seb somewhat undiplomatically put, there are replacements listed in the changelog. Sorry - it wasn't intended to be an offense or aggressive. I consider(ed) RTFM as common internet slang. Dont' worry Seb, I really appreciate very much your help. A. Corbi
Re: replacement for squeeze and removechars.
On Tuesday, 18 July 2017 at 15:41:44 UTC, Meta wrote: As Seb somewhat undiplomatically put, there are replacements listed in the changelog. Sorry - it wasn't intended to be an offense or aggressive. I consider(ed) RTFM as common internet slang.
Re: replacement for squeeze and removechars.
On Tuesday, 18 July 2017 at 15:41:44 UTC, Meta wrote: On Tuesday, 18 July 2017 at 15:28:06 UTC, Antonio Corbi wrote: Hi all, I'm trying dmd-2.075.0-rc1 in one of my projects where I use `squeeze` and `removechars`. Both of them are flagged as obsolete and in the docs we are suggested to use functions from std.regex and/or std.algorithm. Does any one kow a one-liner from std.regex or std.algorithm that can take the role of those deprecated functions? Thank's A. Corbi As Seb somewhat undiplomatically put, there are replacements listed in the changelog. Use std.regex.replaceAll to replace std.string.removechars: import std.string; import std.regex; // old "abc".removechars("a-z"); // new "abc".replaceAll(regex("[a-z]"), ""); Use std.algorithm.iteration.uniq to replace std.string.squeeze: import std.algorithm; import std.string; // old "hello".squeeze; // new "hello".uniq; Though it would be nice to have these alternatives listed right there in the deprecation message. Thanks Meta and Seb! Yes, the replacement is there 8), but as the deprecation message told me "to go to the docs", I only had in mind the library manual pages and not the changelog. I agree with you that, at least, they could also be listed next to `squeeze` and `removechars`. Thanks for your help! A. Corbi
Re: static foreach is now in github master
On Tuesday, 18 July 2017 at 10:06:33 UTC, Vladimir Panteleev wrote: On Tuesday, 18 July 2017 at 10:02:10 UTC, Seb wrote: And thanks to dmd-nightly, also on run.dlang.io: https://run.dlang.io/?compiler=dmd-nightly=void%20main(string%5B%5D%20args)%0A%7B%0A%20%20%20%20static%20foreach%20(i;%20%5B0,1,2,3%5D)%0A%09%7B%0A%20%20%20%20%09pragma(msg,%20i);%0A%09%7D%0A%7D This link doesn't work, looks like it cuts off at the first ; ... Oh - seems like that was due to a different behavior between FF and Chrome :/ (Chrome unescapes the semi-colon by default). This has been fixed now, so the link above or this shortlink should work: https://is.gd/1TCQOh
Re: replacement for squeeze and removechars.
On Tuesday, 18 July 2017 at 15:28:06 UTC, Antonio Corbi wrote: Hi all, I'm trying dmd-2.075.0-rc1 in one of my projects where I use `squeeze` and `removechars`. Both of them are flagged as obsolete and in the docs we are suggested to use functions from std.regex and/or std.algorithm. Does any one kow a one-liner from std.regex or std.algorithm that can take the role of those deprecated functions? Thank's A. Corbi As Seb somewhat undiplomatically put, there are replacements listed in the changelog. Use std.regex.replaceAll to replace std.string.removechars: import std.string; import std.regex; // old "abc".removechars("a-z"); // new "abc".replaceAll(regex("[a-z]"), ""); Use std.algorithm.iteration.uniq to replace std.string.squeeze: import std.algorithm; import std.string; // old "hello".squeeze; // new "hello".uniq; Though it would be nice to have these alternatives listed right there in the deprecation message.
Re: replacement for squeeze and removechars.
On Tuesday, 18 July 2017 at 15:28:06 UTC, Antonio Corbi wrote: Hi all, I'm trying dmd-2.075.0-rc1 in one of my projects where I use `squeeze` and `removechars`. Both of them are flagged as obsolete and in the docs we are suggested to use functions from std.regex and/or std.algorithm. Does any one kow a one-liner from std.regex or std.algorithm that can take the role of those deprecated functions? Thank's A. Corbi RTFM: https://dlang.org/changelog/2.075.0.html#pattern-deprecate
Re: proposed @noreturn attribute
On 18.07.2017 14:19, Stefan Koch wrote: On Tuesday, 18 July 2017 at 12:15:06 UTC, Timon Gehr wrote: On 18.07.2017 12:17, John Colvin wrote: Better to just not define it. That's not an option. Bottom is a subtype of all types. It cannot remove members, even static ones. Timon, how important is it to actually have bottom ? D has a C-inspired first-order type system, so it is not necessarily crucial to have it in D. (The reason I got involved in this thread is that it was proposed to add Bottom as a type that is not really a type; 'void' is annoying enough as the 'null' of types. We don't really need another one of those.) Bottom is the most principled way to encode noreturn (but the D type system does not have a tradition of being very principled, so introducing it has a cost that does not really exist the same way in more orthogonal designs: it falls out of them naturally). If you have a very expressive type system, it is important to have empty types, because there you cannot actually decide algorithmically whether any given type is in fact empty. Another reason why one might want an empty type is that it is the neutral element for disjoint union (up to isomorphism). (But D does not have those built-in.) ... and what does it actually represent ? It's a type that has no instances. If I say int foo(); this means foo returns one of {0,1,-1,2,-2,3,-3,...,int.max,int.min}. If I say Bottom foo(); this means foo returns one of {}. I.e., there is no value which foo might return. Hence it cannot return. It can be argued that it is a bit silly to say: int foo()@noreturn; I.e., this function returns one of {0,1,-1,2,-2,3,-3,...,int.max,int.min}, but actually, it does not return anything. The first piece of information is redundant. The closure of all possible types ? like auto but if auto where not replaced ? Your intuition is correct. In a higher-order type system, you can have: (∀a. a) foo(); This says that foo returns a value that has any type you wish it to have. Of course, there is no single value that has all types (ignoring e.g. full OO languages that have null references), hence we have no way to actually construct a value satisfying the constraints, so (∀a. a) is an empty type. In languages with subtyping, Bottom is often just a subtype of all other types. (The name "Bottom" stems from here: https://en.wikipedia.org/wiki/Lattice_(order)#Bounded_lattice . The bounded lattice in question is the subtyping lattice, where A ≤ B means A is a subtype of B.) One reason why it is nice to have a bounded subtyping lattice is that then, you can express subtyping constraints uniformly: A≤B does not constraint B if A is Bottom, and it does not constrain A if B is Top.
replacement for squeeze and removechars.
Hi all, I'm trying dmd-2.075.0-rc1 in one of my projects where I use `squeeze` and `removechars`. Both of them are flagged as obsolete and in the docs we are suggested to use functions from std.regex and/or std.algorithm. Does any one kow a one-liner from std.regex or std.algorithm that can take the role of those deprecated functions? Thank's A. Corbi
Re: Idiomatic way of writing nested loops?
On Tue, 2017-07-18 at 08:41 +, Anton Fediushin via Digitalmars-d-learn wrote: > On Tuesday, 18 July 2017 at 03:36:04 UTC, Nicholas Wilson wrote: > > With regards to parallel, only use it on the outermost loop. > > Assuming you have more items in the outermost loop than you do > > threads parallelising more than one loop won't net you any > > speed. > > Thank you! Yes, `parallel` runs only 4 threads on my machine, so > there is no reason to use it in nested loops. But how many processors, cache sizes, memory speed, etc, etc, etc. The only way of knowing what the fastest performance is is to try some things and get some performance data. Even then the result only applies to that data on that computer. This is the sort of situation where philosophising about performance often ends up with totally the wrong code. -- Russel. = Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.win...@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder signature.asc Description: This is a digitally signed message part
Re: Idiomatic way of writing nested loops?
On Tue, 2017-07-18 at 03:36 +, Nicholas Wilson via Digitalmars-d-learn wrote: > On Monday, 17 July 2017 at 11:07:35 UTC, Anton Fediushin wrote: > > […] > > > > Also, I have a question about running this in parallel: if I > > want to use nested loops with `parallel` from > > `std.parallelism`, should I add `parallel` to every loop like > > this? > > -- > > foreach(a; ["foo", "bar"].parallel) { > > foreach(b; ["baz", "foz", "bof"].parallel) { > > foreach(c; ["FOO", "BAR"].parallel) { > > // Some operations on a, b and c > > } > > } > > } > > -- > > I am worried about running thousands of threads, because in > > this case first `parallel` runs 2 tasks, every task runs 3 > > tasks and every task runned inside a task runs 2 more tasks. It is important to separate threads and tasks carefully here: as far as I am aware the .parallel creates tasks not threads. The only threads are the ones in the thread pool animatng the tasks. This having the thousands of tasks is not a problem per se, since these are not threads. The question of what the best decomposition for parallelism is has to be determined by benchmarking – guesswork usually gets it wrong. My prejudice here though is that for a loop structure such as this, unless the computation at the centre is a biggy, you probably don't want the .parallel on the inner loop. But I repeat only benchmarking will tell what the best parallelism decomposition is. > > So, how to write this in idiomatic D manner and run it _if > > possible_ in parallel? > > With regards to parallel, only use it on the outermost loop. > Assuming you have more items in the outermost loop than you do > threads parallelising more than one loop won't net you any speed. I am not convinced by this "idiom" of only the outer loop. It may be true for some cases, but certtainly not all. This is task and thread pool based parallelism here, not vector parallelism. Without knowing the actual computational structure of the statements at the centre, there can be no known best parallelism structure. Experimentation on medium sized data sets before moving to the real ones is required to get the likely best performance. -- Russel. = Dr Russel Winder t:+44 20 7585 2200 voip:sip: russel.win...@ekiga.net 41 Buckmaster Road m:+44 7770 465 077 xmpp:rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype:russel_winder signature.asc Description: This is a digitally signed message part
Re: An Issue I Wish To Raise Awareness On
On Tuesday, 18 July 2017 at 11:47:37 UTC, Petar Kirov [ZombineDev] wrote: I think Atila was talking about this one: struct A { ~this() {} } void main() { auto a = A(); shared b = A(); } This is strange. There's nothing that suggests that struct A and its destructor is thread-safe, yet compiler assumes it is.
Re: Slides share: DMesos - Not only a re-implementation of Mesos
On Sunday, 16 July 2017 at 03:45:09 UTC, Dsby wrote: On Saturday, 15 July 2017 at 15:57:18 UTC, 鲜卑拓跋枫 wrote: On Friday, 14 July 2017 at 05:07:11 UTC, Dsby wrote: On Monday, 10 July 2017 at 17:29:01 UTC, 鲜卑拓跋枫 wrote: [...] 我也希望能用D做出来。 我们也在研究过raft, akka这些技术。 raft算法的翻译我同事也有个port到D版本的。只是具体什么样,我没参与也没关心。 我们也在上海,我看链接里介绍,你现在也在上海工作,在EMC? 只是不知道你们开始做没? 做DMesos的目的一是Just for Fun, 二是在实战中提高D语言的功力。 D语言若能有更多一些大项目,则能更好地扩大其影响力并促进进一步的发展:)。 D 的确缺少大点的项目。 那个raft实现具体我没关心。 而且最近我在公司推nogc呢。 嗯 D在内存管理这块相比其他商业化已经成熟的主流语言确实还有一定差距。
Re: Get complete function declaration
On Tuesday, 18 July 2017 at 13:53:11 UTC, Ivan Kazmenko wrote: On Tuesday, 18 July 2017 at 13:35:49 UTC, SrMordred wrote: There is a way to get the full function(or any other structure) declaration with traits? Or I will have to mount it with std.traits functions? eg. void add(int x, int y){} GetFullFunctionDeclaration!add; //return "void add(int x, int y)" There are several function traits in std.traits (see https://dlang.org/phobos/std_traits.html), which can hopefully be combined to reconstruct a function declaration. I don't see a single method which would do what you want out of the box. Perhaps there is none, since different use cases would require different small subsets of features, and all the orthogonal features are already available. Ivan Kazmenko. Thanks! I´ll have to build one so :)
[Issue 12389] Operating system C functions should be marked as 'nothrow'
https://issues.dlang.org/show_bug.cgi?id=12389 Vladimir Panteleevchanged: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Vladimir Panteleev --- (In reply to qznc from comment #1) > Resolved as of https://github.com/dlang/druntime/commit/3c9aee8fcb1d9 ? Seems like it. Closing; please reopen or file a new bug if any specific modules are still missing the annotation. --
[Issue 13039] combinations
https://issues.dlang.org/show_bug.cgi?id=13039 Vladimir Panteleevchanged: What|Removed |Added Keywords||patch --
[Issue 697] No const folding on asm db,dw, etc
https://issues.dlang.org/show_bug.cgi?id=697 Vladimir Panteleevchanged: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Vladimir Panteleev --- The original test case as presented in the issue description now works, as per comment 3, so I'm going to close this. (In reply to Don from comment #5) > I'm reopening this since there are 7 dstress bugs which depend on it. DStress is no longer online, so these are no longer easily available. Please reopen or file a new issue if you can provide a reproducible test case. --
Re: DMD library available as DUB package
On Tuesday, 18 July 2017 at 12:07:27 UTC, Jacob Carlborg wrote: During the dconf hackathon I set out to create a DUB package for DMD to be used as a library. This has finally been merged [1] and is available here [2]. It contains the lexer and the parser. A minimal example: #!/usr/bin/env dub /++ dub.sdl: name "dmd_lexer_example" dependency "dmd" version="~master" +/ void main() { import ddmd.lexer; import ddmd.tokens; import std.stdio; immutable sourceCode = "void test() {} // foobar"; scope lexer = new Lexer("test", sourceCode.ptr, 0, sourceCode.length, 0, 0); while (lexer.nextToken != TOKeof) writeln(lexer.token.value); } [1] https://github.com/dlang/dmd/pull/6771 [2] http://code.dlang.org/packages/dmd Nice, I was not aware that DMD as a library was so close to being a reality.
[Issue 9641] Wrong module init order when a thread is created in a module ctor
https://issues.dlang.org/show_bug.cgi?id=9641 --- Comment #2 from Vladimir Panteleev--- (In reply to Martin Nowak from comment #1) > I think the fix would need a mutex which blocks all created threads until > all shared module constructors are finished. This might easily cause > deadlocks though. Sounds very similar to how Windows blocks threads created in DllMain. The deadlock issue is there as well (threads will remain suspended until initialization completes). --
[Issue 17604] Reject mutable fields initialized with reference types to data segment
https://issues.dlang.org/show_bug.cgi?id=17604 Vladimir Panteleevchanged: What|Removed |Added See Also||https://issues.dlang.org/sh ||ow_bug.cgi?id=13646 --