Re: Bug or intended?
On Saturday, 6 February 2016 at 14:15:04 UTC, rsw0x wrote: I was playing around with alias templates and came across this, I reduced it to: --- struct A(alias C c){ auto foo(){ return c.i; } } struct B{ C c; A!c a; } struct C{ int i; } --- It gives me a "need 'this' for 'i' of type 'int'" error. I think the "alias C c" you pass actually must be a value "c" of some sort. A!c would have to produce a different A struct, for every c value. (as opposed to A!C which works fine.) So, if you made B with a C with an i = 23, then you'd have an A!(23) and if you made another one with i = 42, you'd have an A!(42). That doesn't seem very useful, for general integers. Maybe if it was an enum of finite, limited size it'd make sense.
How to warn of unused imports?
When I factor out code from my modules, it really, really often leaves import statements that just sit there doing nothing, making it look like my program is more complex than it is. How do I get warned for leaving those, and a list of which ones I can safely remove?
Re: is increment on shared ulong atomic operation?
On Sunday, 7 February 2016 at 20:25:44 UTC, Minas Mina wrote: Just noticed that there's no example. It's used like shared(ulong) a; atomicOp!"+="(a, 1); Wow, that syntax sucks a lot. a.atomicOp!"+="(1); sounds better. You can alias it too.
Re: How to warn of unused imports?
V Mon, 08 Feb 2016 08:25:09 + cy via Digitalmars-d-learn napsáno: > When I factor out code from my modules, it really, really often > leaves import statements that just sit there doing nothing, > making it look like my program is more complex than it is. How do > I get warned for leaving those, and a list of which ones I can > safely remove? I dont think there is a way right now. But in a future dscanner. https://github.com/Hackerpilot/Dscanner/issues/134
Re: Dynamic Ctors ?
On Monday, 8 February 2016 at 07:08:58 UTC, Voitech wrote: On Saturday, 6 February 2016 at 23:35:17 UTC, Ali Çehreli wrote: On 02/06/2016 10:05 AM, Voitech wrote: > [...] You can use string mixins (makeCtor and makeCtors): string makeCtor(T)() { import std.string : format; [...] Thank you very much for answering. Cheers Unfortunately this doesn't work as I'am trying to assign value from ctor to member something like: this(%s value){ this.value=value; } it gives me Error: memcpy cannot be interpreted at compile time, because it has no available source code. Probably this is caused by declaration of member which is also parametrized with T... Member is: Algebraic!(T) value; So declaration of this mixin constructors are done before variable value is declared (compilation)? Is there any field in class that would contain ctors ? Something like __ctors ? i could try to init this(T... value) constructors in static constructor using delegates/functions. Something like: template Outer(T...){ class Inner{ Algebraic!(T) value; alias ctor(Type) =Inner delegate (Type value); static this(){ foreach(Type;T){ ctor!(Type) c={ this.value=value; }; __ctors~=c; // ? } } }
Re: Things that keep D from evolving?
On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote: What language semantics prevent precise & fast GC implementations? Unions and easy type casting prevent precise GC. Lack of write barriers for reference-type fields prevent fast (generational and/or concurrent) GC. Some more detailed explanations here: http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html
Re: How is D doing?
On Tuesday, 22 December 2015 at 11:42:42 UTC, bachmeier wrote: 1. Downloads of the DMD compiler have been fluctuating between 1000 and 1600 per day: http://erdani.com/d/downloads.daily.png To this you can add 75dl per day for ldc: http://www.somsubhra.com/github-release-stats/?username=ldc-developers&repository=ldc They'll reach 60K (overlall) this week.
Re: Things that keep D from evolving?
On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote: http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html Well, the latest Intel CPUs have a theoretical throughput of 30GB/s... so that makes for up to 30MB/ms. But language changes are needed, I think. I also don't quite understand how RC can solve the issue with pointers to internal fields in classes.
Re: How to warn of unused imports?
On Monday, 8 February 2016 at 08:25:09 UTC, cy wrote: How do I get warned for leaving those, and a list of which ones I can safely remove? Remove one, recompile. If it passes, leave it. If not, undo and move on to the next one.
Re: Dynamic Ctors ?
http://dpaste.dzfl.pl/1f25ac34c1ee You need Tuple, not Algebraic. Algebraic stores only one value of one type from a set, like Variant.
Re: Dynamic Ctors ?
On Monday, 8 February 2016 at 15:09:30 UTC, Kagamin wrote: http://dpaste.dzfl.pl/1f25ac34c1ee You need Tuple, not Algebraic. Algebraic stores only one value of one type from a set, like Variant. Thank you for answering. You right if i would want to store all types of T.. in an Inner instance. But my conception was bad from the beginning. I want to store only one type of value in Inner instance. I just wanted to create generic constructor for each of Type which is invalid, cause instance holds value of single type that's why it is not parametrized by itself.
Re: Things that keep D from evolving?
On Monday, 8 February 2016 at 11:22:45 UTC, thedeemon wrote: On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote: What language semantics prevent precise & fast GC implementations? Unions and easy type casting prevent precise GC. Lack of write barriers for reference-type fields prevent fast (generational and/or concurrent) GC. Some more detailed explanations here: http://www.infognition.com/blog/2014/the_real_problem_with_gc_in_d.html I see... By any chance, can we solve this issue with GC managed pointers? AFAIK, this is what C++/CLR does: There are 2 different pointer types, (*) and (^). (*) is the famous raw pointer, second one is GC managed pointer. A GC pointer has write barrier (unlike raw pointer) so we can have both raw C performance (if we want) and fast generational GC or concurrent GC (which are a magnitude better than a mark and sweep GC). As you realized, there is a major problem with this: classes. The desicion of making classes reference-type is actually fine (+simplicity), but it doesn't really help with the current situation, I expect D to be pragmatic and let me decide. Maybe in future... Who knows...
Re: Things that keep D from evolving?
On Mon, 08 Feb 2016 11:22:45 +, thedeemon wrote: > On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote: >> What language semantics prevent precise & fast GC implementations? > > easy type casting prevent precise GC. To expand on this point: A GC makes a tradeoff between allocating efficiently and deallocating efficiently. (And a compiler+runtime makes a tradeoff between generating larger binaries that take more time to deal with and being able to produce precise garbage collection.) You can write a GC that allocates each type in its own region of memory. Every block has a pointer map associated with it. But this means the minimum allocation for each type is one page -- typically 4KB. This is bad for applications that have very few instances of each type and many types of object allocated. A simpler thing you can do is write a GC that has two regions of memory, one with pointers that might point to GC memory and one without. This gets rid of the overhead problem but doesn't allow precise collection. Alternatively, a language might prevent all casting, even upcasting, for any type that might contain pointers. Specifically: class Foo {} class Bar : Foo {} Foo foo = new Bar(); // type error! This means that the GC doesn't ever need to store the type of an allocated object anywhere. It can get the information it needs from a stack map ("pointer to Foo is stored in this stack frame at offset 8") and a similarly formatted map for allocated types. It would work, but it's sufficiently constraining that I don't think anyone has this in a real programming language.
Re: Things that keep D from evolving?
On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote: On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote: I see... By any chance, can we solve this issue with GC managed pointers? Maybe we could. But it's never going to happen. Even if Walter weren't fundamentally opposed to multiple pointer types in D, it wouldn't happen. You asked about things that prevent improvement, right? Here's the big one, and a major point of friction in the community: Walter and Andrei refuse to break existing code in pursuit of changes that substantially improve the language. (Never mind that code tends to break anyway.) -Wyatt Pretty much this. We can't go a version without code breakage, but also can't introduce features that would drastically help the language because it would introduce breakage. i.e, all the great ownership/scope/what-have-you proposals and shit like DIP25 gets pushed through instead, then 2 days later it gets proven to be worthless anyways. Woops.
Re: Things that keep D from evolving?
On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote: I see... By any chance, can we solve this issue with GC managed pointers? Maybe we could. But it's never going to happen. Even if Walter weren't fundamentally opposed to multiple pointer types in D, it wouldn't happen. You asked about things that prevent improvement, right? Here's the big one, and a major point of friction in the community: Walter and Andrei refuse to break existing code in pursuit of changes that substantially improve the language. (Never mind that code tends to break anyway.) -Wyatt
Re: Things that keep D from evolving?
On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote: Maybe we could. But it's never going to happen. Even if Walter weren't fundamentally opposed to multiple pointer types in D, it wouldn't happen. You asked about things that prevent improvement, right? Here's the big one, and a major point of friction in the community: Walter and Andrei refuse to break existing code in pursuit of changes that substantially improve the language. (Never mind that code tends to break anyway.) You are of course right, but it isn't an absolute. Nothing prevents someone to restrict a D compiler in such a way that you can get faster GC. C++ compilers have lots of optional warnings/errors, so it is quite possible. But I suppose those that want it would rather use Go, C# or some other GC language than can do ahead of time compilation.
Re: How to warn of unused imports?
On 02/08/2016 06:35 AM, Adam D. Ruppe wrote: On Monday, 8 February 2016 at 08:25:09 UTC, cy wrote: How do I get warned for leaving those, and a list of which ones I can safely remove? Remove one, recompile. If it passes, leave it. If not, undo and move on to the next one. Similarly, I comment out all; then uncomment one by one according to compilation errors. Ali
Re: Can D interface with Free Pascal?
On Thursday, 28 January 2016 at 04:26:26 UTC, Taylor Hillegeist wrote: Just curious... I had a thought that perhaps since Objective C was a replacement for Pascal on the mac. that they might have the same interface. but I'm not savvy enough with fpc to figure out how to try it. As said in the other posts you can link dlls or even object files produced by a D compiler. There is the D runtime to initialize and finalize, a particular attention must be put on te calling conventions, also some stuff like strings must be passed using toStringz() or received with fromStringz() (and Pchar() in pascal)... One thing that's interesting is to develop let's say the GUI with Lazarus and use a core made in D. When you'll debug your application in Lazarus, and if an exception is raised within the object or the dll made in D, the integrated debugger will break and display the D source directly in Lazarus. The first time it happend to me, I was **totally mesmerized**... (I even made a post here: https://forum.dlang.org/thread/aeiwsnmsrchgmkbll...@forum.dlang.org "//debugger breaks here": it was the Lazarus debugger who displayed a D source). But actually it's totally logical, it's just the DWARF debug info that indicates the source name...
Re: How to warn of unused imports?
On Monday, 8 February 2016 at 08:50:17 UTC, Daniel Kozak wrote: V Mon, 08 Feb 2016 08:25:09 + cy via Digitalmars-d-learn napsáno: When I factor out code from my modules, it really, really often leaves import statements that just sit there doing nothing, making it look like my program is more complex than it is. How do I get warned for leaving those, and a list of which ones I can safely remove? I dont think there is a way right now. But in a future dscanner. https://github.com/Hackerpilot/Dscanner/issues/134 I don't think that Dscanner will be able to do this soon. Its scope is limited to a single module, it's not like DCD, which works with the imports and which is able to look-up elsewhere. For example you'll see this if you try to make an analyzer that produces warnings for signed & unsigned comparison. It impossible without a bit of semantic (ref: https://github.com/Hackerpilot/Dscanner/issues/204). Otherwise, it sounds like a decent enhancement request for DMD. I know other compilers who do this warning.
Re: How to warn of unused imports?
On Monday, 8 February 2016 at 18:57:52 UTC, Basile B. wrote: Otherwise, it sounds like a decent enhancement request for DMD. I know other compilers who do this warning. It definitely does sound like a decent enhancement request. I didn't know it wasn't implemented yet, but it should be pretty straightforward, since within DMD you can access the AST. Alternatively, implementing DIP50 might let you do it outside the compiler. http://wiki.dlang.org/DIP50
in a template argument, specify which object member to access?
object.member lets me access the member of the object, but what if I want to access those members in a generic way, but in a different arrangement depending on context? Like if I wanted to first follow a tree down, and second priority would be going left to right, but then I wanted to first go right, and second priority would be going down to up. struct A { string up; string down; string left; string right; } template goPlaces(D1,D2,D3) { string go(A a) { return "go " ~ a.D1 ~ " then go " ~ a.D2 ~ " then go " ~ a.D3; } } import std.stdio; void main() { A a = {"north","south","east","west"}; writeln(goPlaces!(up,down,left)(a)); } Do I just have to use a mixin? Or implement those members as indexes in an array, if I want to use them differently? enum Way { UP, DOWN, LEFT, RIGHT }; struct A { string[Way.max+1] ways; } ...
Re: Things that keep D from evolving?
On Monday, 8 February 2016 at 17:15:11 UTC, Wyatt wrote: On Monday, 8 February 2016 at 16:33:09 UTC, NX wrote: I see... By any chance, can we solve this issue with GC managed pointers? Maybe we could. But it's never going to happen. Even if Walter weren't fundamentally opposed to multiple pointer types in D, it wouldn't happen. You asked about things that prevent improvement, right? Here's the big one, and a major point of friction in the community: Walter and Andrei refuse to break existing code in pursuit of changes that substantially improve the language. (Never mind that code tends to break anyway.) -Wyatt I have no special knowledge but strikes this observer that they are serious about working on solutions (whether that's a better GC or alternatives or both). But some patience required as its not such a straightforward problem and its better to take time than rush and make a mistake. It wasn't all that long ago that Andrei quit and I guess he moved across country and it certainly takes time to sort out one's home office and find a new working pattern. The discussions in the mailing list are quite interesting although beyond my technical knowledge for now. The GC itself may still be far from perfect but its much better than it was, and there are more options now. I have found emsi containers (built on top of Andrei's allocator) pretty nice myself for my own use.
Re: in a template argument, specify which object member to access?
On Monday, 8 February 2016 at 21:09:47 UTC, cy wrote: object.member lets me access the member of the object, but what if I want to access those members in a generic way, but in a different arrangement depending on context? Like if I wanted to first follow a tree down, and second priority would be going left to right, but then I wanted to first go right, and second priority would be going down to up. [...] i believe you can use __traits(getMember) there.
Re: in a template argument, specify which object member to access?
This is what I have so far. Using mixin(rawstring~templatearg) for every time I access the member is kind of cludgy though. struct A { string up; string down; string left; string right; } template goPlaces(string D1, string D2, string D3) { string goPlaces(ref A a) { mixin("a."~D2) = "deetoo"; return "go " ~ mixin("a."~D1) ~ " then go " ~ mixin("a."~D2) ~ " then go " ~ mixin("a."~D3); } } void main() { import std.stdio; A a = {"north","south","east","west"}; writeln(goPlaces!("up","left","down")(a)); writeln(a.left); } top postinglol On Monday, 8 February 2016 at 21:09:47 UTC, cy wrote: object.member lets me access the member of the object, but what if I want to access those members in a generic way, but in a different arrangement depending on context? Like if I wanted to first follow a tree down, and second priority would be going left to right, but then I wanted to first go right, and second priority would be going down to up. struct A { string up; string down; string left; string right; } template goPlaces(D1,D2,D3) { string go(A a) { return "go " ~ a.D1 ~ " then go " ~ a.D2 ~ " then go " ~ a.D3; } } import std.stdio; void main() { A a = {"north","south","east","west"}; writeln(goPlaces!(up,down,left)(a)); } Do I just have to use a mixin? Or implement those members as indexes in an array, if I want to use them differently? enum Way { UP, DOWN, LEFT, RIGHT }; struct A { string[Way.max+1] ways; } ...
Re: in a template argument, specify which object member to access?
On Monday, 8 February 2016 at 22:38:45 UTC, Mengu wrote: i believe you can use __traits(getMember) there. Great! Should have refreshed before sending that reply... I wonder if mixin("a."~member) is better or worse than __traits(getMember,a,member)...
Re: in a template argument, specify which object member to access?
On Monday, 8 February 2016 at 22:46:06 UTC, cy wrote: On Monday, 8 February 2016 at 22:38:45 UTC, Mengu wrote: i believe you can use __traits(getMember) there. Great! Should have refreshed before sending that reply... I wonder if mixin("a."~member) is better or worse than __traits(getMember,a,member)... I think I prefer the mixin version because it doesn't rely on compiler internals and is easier to read IMHO but this is very questionable.
Re: in a template argument, specify which object member to access?
On Monday, 8 February 2016 at 22:46:06 UTC, cy wrote: On Monday, 8 February 2016 at 22:38:45 UTC, Mengu wrote: i believe you can use __traits(getMember) there. Great! Should have refreshed before sending that reply... I wonder if mixin("a."~member) is better or worse than __traits(getMember,a,member)... i think it's a matter of taste and here's how i would do it: import std.stdio; import std.array; struct A { string up; string down; string left; string right; } string goPlaces(args...)(A a) { string[] result; foreach (arg; args) { result ~= __traits(getMember, a, arg); } return "go " ~ result.join(" then go "); } void main() { A a = {"north", "south", "east", "west"}; writeln(goPlaces!("up", "down", "left")(a)); writeln(goPlaces!("down", "right", "left", "up")(a)); } // outputs // go north then go south then go east // go south then go west then go east then go north
Re: Odd Destructor Behavior
On Monday, 8 February 2016 at 07:31:07 UTC, Daniel Kozak wrote: Seems to me too, please report it on issues.dlang.org Reported: https://issues.dlang.org/show_bug.cgi?id=15661
Re: Is this a bug in std.typecons.Tuple.slice?
On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote: What I like most about your proposal is that it doesn't break any existing code that wasn't broken before. That can't be emphasized enough. Although I wish more than 3 people had voted in my poll, two of them did claim to need the `ref`-ness of `Tuple.slice`, so I don't think we can just ditch it. (I did not vote.) If you guys want to add a return-by-value version, it should be treated as an enhancement, not a bug fix in my opinion.
How do you reference variables in an AA of Variants?
This: double b = 1.0; Variant[string] aa = ["b": &b]; writeln(aa["b"]); fails with: Error: cannot implicitly convert expression(["b":&b]) of type double*[string] to VariantN!20u[string] Helps please!
Problem with release build.
In the following sample program (which tries to set terminal to raw mode and check for key presses), compiling as usual (dmd t.d), the program works, but compiling in release mode (dmd -release t.d) and the raw mode doesn't seem to work. Where do I start looking to figure this out or if it is obvious, what am I doing wrong? (In the release mode output, notice the character getting echo-ed before the "Got"). MacBook-Pro:$ dmd --version DMD64 D Compiler v2.069.2 Copyright (c) 1999-2015 by Digital Mars written by Walter Bright MacBook-Pro:$ dmd t.d MacBook-Pro:$ ./t Got: a Got: b Got: c Got: d Got: q MacBook-Pro:$ dmd -release t.d MacBook-Pro:$ ./t aGot: a bGot: b cGot: c dGot: d eGot: e qGot: q MacBook-Pro:$ cat t.d import core.thread; import core.stdc.stdio; import core.sys.posix.fcntl; import core.sys.posix.termios; import std.stdio : writeln; int oldf; termios oldt; void makeraw() { termios newt; assert(tcgetattr(0, &oldt) == 0); newt = oldt; newt.c_lflag &= ~(ICANON | ECHO | ECHONL | ISIG | IEXTEN); newt.c_iflag &= ~(IGNBRK | BRKINT | ISTRIP | INLCR | ICRNL | IGNCR | IXON | IXOFF); newt.c_cc[VMIN] = 1; assert(tcsetattr(0, TCSANOW, &newt) == 0); oldf = fcntl(0, F_GETFL, 0); fcntl(0, F_SETFL, oldf | O_NONBLOCK); } void makecooked() { fcntl(0, F_SETFL, oldf); assert(tcsetattr(0, TCSANOW, &oldt) == 0); } void main(string[] args) { int ch; makeraw(); scope(exit) makecooked(); do { while ((ch = fgetc(stdin)) == EOF) { Thread.sleep(dur!("seconds")(1)); } writeln("Got: ", cast(dchar)ch); } while (ch != 'q'); }
Re: Problem with release build.
Ignore this -- this is probably due to how I am doing the assert(). In the release build, it is getting compiled out and in the process compiling out the tcgetattr and the tcsetattr. On Tuesday, 9 February 2016 at 05:08:20 UTC, sanjayss wrote: In the following sample program (which tries to set terminal to raw mode and check for key presses), compiling as usual (dmd t.d), the program works, but compiling in release mode (dmd -release t.d) and the raw mode doesn't seem to work. Where do I start looking to figure this out or if it is obvious, what am I doing wrong? (In the release mode output, notice the character getting echo-ed before the "Got"). MacBook-Pro:$ dmd --version DMD64 D Compiler v2.069.2 Copyright (c) 1999-2015 by Digital Mars written by Walter Bright MacBook-Pro:$ dmd t.d MacBook-Pro:$ ./t Got: a Got: b Got: c Got: d Got: q MacBook-Pro:$ dmd -release t.d MacBook-Pro:$ ./t aGot: a bGot: b cGot: c dGot: d eGot: e qGot: q MacBook-Pro:$ cat t.d import core.thread; import core.stdc.stdio; import core.sys.posix.fcntl; import core.sys.posix.termios; import std.stdio : writeln; int oldf; termios oldt; void makeraw() { termios newt; assert(tcgetattr(0, &oldt) == 0); newt = oldt; newt.c_lflag &= ~(ICANON | ECHO | ECHONL | ISIG | IEXTEN); newt.c_iflag &= ~(IGNBRK | BRKINT | ISTRIP | INLCR | ICRNL | IGNCR | IXON | IXOFF); newt.c_cc[VMIN] = 1; assert(tcsetattr(0, TCSANOW, &newt) == 0); oldf = fcntl(0, F_GETFL, 0); fcntl(0, F_SETFL, oldf | O_NONBLOCK); } void makecooked() { fcntl(0, F_SETFL, oldf); assert(tcsetattr(0, TCSANOW, &oldt) == 0); } void main(string[] args) { int ch; makeraw(); scope(exit) makecooked(); do { while ((ch = fgetc(stdin)) == EOF) { Thread.sleep(dur!("seconds")(1)); } writeln("Got: ", cast(dchar)ch); } while (ch != 'q'); }
Re: Is this a bug in std.typecons.Tuple.slice?
Am Tue, 09 Feb 2016 00:38:10 + schrieb tsbockman : > On Sunday, 7 February 2016 at 02:11:15 UTC, Marco Leise wrote: > > What I like most about your proposal is that it doesn't break > > any existing code that wasn't broken before. That can't be > > emphasized enough. > > Although I wish more than 3 people had voted in my poll, two of > them did claim to need the `ref`-ness of `Tuple.slice`, so I > don't think we can just ditch it. (I did not vote.) > > If you guys want to add a return-by-value version, it should be > treated as an enhancement, not a bug fix in my opinion. As mentioned I never used the feature myself and wont vote for one or the other. Three people with no source code to exemplify current use of .slice! is indeed not much to base decisions on and both fixes yield unexpected results in different contexts that warrant bug reports. -- Marco
Re: How do you reference variables in an AA of Variants?
On Tuesday, 9 February 2016 at 03:49:11 UTC, Enjoys Math wrote: This: double b = 1.0; Variant[string] aa = ["b": &b]; writeln(aa["b"]); fails with: Error: cannot implicitly convert expression(["b":&b]) of type double*[string] to VariantN!20u[string] Helps please! Use an intermediate to carry the result of &: double b = 1.0; Variant vb = &b; Variant[string] aa = ["b": vb]; writeln(aa["b"]); &b is a rvalue. vb is a lvalue.
Re: How do you reference variables in an AA of Variants?
On 02/08/2016 07:49 PM, Enjoys Math wrote: This: double b = 1.0; Variant[string] aa = ["b": &b]; writeln(aa["b"]); fails with: Error: cannot implicitly convert expression(["b":&b]) of type double*[string] to VariantN!20u[string] Helps please! When initializing the array, you have to use Variant(&b): import std.stdio; import std.variant; void main() { double b = 1.5; Variant[string] aa = ["b": Variant(&b)]; writeln(aa); writeln(aa["b"]); writeln(*aa["b"].get!(double*)); } Prints something like the following: ["b":7FFD0104B100] 7FFD0104B100 1.5 Ali