selective import
Hi all. How to use use selective imports more effectively? I have two modules foo and bar: module foo; class Foo {} module bar; import foo: Foo; class Bar { private Foo foo_; this(Foo foo) { foo_ = foo; } } Now I add module baz that use both modules above. How to import foo and bar - everything or only 'the topmost' one, bar? module baz; import bar: Bar; import foo: Foo; or import bar: Bar, Foo; // also in bar import of foo.Foo should be public of course I don't see difference, but it doesn't mean it doesn't exist. What do you think about it?
Re: selective import
On Thursday, 5 December 2013 at 11:17:18 UTC, Alexandr Druzhinin wrote: I don't see difference, but it doesn't mean it doesn't exist. What do you think about it? It depends on how bar uses foo. You should do public import of symbols from foo if they are required to interact with bar public API. If foo is only used as part of internal implementation, it should be kept private and both modules imported explicitly.
Re: selective import
05.12.2013 20:34, Dicebot пишет: On Thursday, 5 December 2013 at 11:17:18 UTC, Alexandr Druzhinin wrote: I don't see difference, but it doesn't mean it doesn't exist. What do you think about it? It depends on how bar uses foo. You should do public import of symbols from foo if they are required to interact with bar public API. If foo is only used as part of internal implementation, it should be kept private and both modules imported explicitly. Third module uses both Bar and Foo. So I should either import every module individually, or import Bar only but Bar should publicly import Foo - that's the question.
Re: selective import
On Thursday, 5 December 2013 at 13:39:09 UTC, Alexandr Druzhinin wrote: 05.12.2013 20:34, Dicebot пишет: On Thursday, 5 December 2013 at 11:17:18 UTC, Alexandr Druzhinin wrote: I don't see difference, but it doesn't mean it doesn't exist. What do you think about it? It depends on how bar uses foo. You should do public import of symbols from foo if they are required to interact with bar public API. If foo is only used as part of internal implementation, it should be kept private and both modules imported explicitly. Third module uses both Bar and Foo. So I should either import every module individually, or import Bar only but Bar should publicly import Foo - that's the question. It does not matter what third module uses, it is purely about relation between foo and bar. If foo symbols are not necessary part of public bar API, third module will import both. If they are, bar will import foo publicly. Pretty simple.
Re: About compiler memory consumption
On Thursday, 5 December 2013 at 04:02:58 UTC, Puming wrote: There maybe another traditional approach, by converting the .dt diet templates directly into D source code BEFORE the actuall compilation. That is the way many other HTML template systems use, and the performance is fairly good. It is somewhat complicated by the very tight integration between D handler host and Diet - you can expose D symbols for rendering context to template. It is still possible to do it that way but is likely to require more efforts and effectively will just to the same thing as good JIT-ed CTFE should. I don't like it because it is too effort-demanding for a quick hack and not suitable in the long term by design (one of D goals was to remove reliance on external build steps as much as possible)
Re: selective import
05.12.2013 20:43, Dicebot пишет: It does not matter what third module uses, it is purely about relation between foo and bar. If foo symbols are not necessary part of public bar API, third module will import both. If they are, bar will import foo publicly. Pretty simple. I realized.
Re: Remove function?
On Wednesday, 4 December 2013 at 23:03:10 UTC, Chris Cain wrote: Here's a version that does what (I think) you want: -- string stripPar(string S) { while(S[0] == '(' && S[S.length-1] == ')') { S = S[1 .. $ - 1]; } return S; } -- So, what this does is just changes the view of S, not the data of S. A subtle but important distinction. First thank you s much for clarification of the operation. however, i tried your solution too. this failed with the same errors as mentioned in the first post of the thread..
Re: Remove function?
On Thursday, 5 December 2013 at 15:46:41 UTC, seany wrote: First thank you s much for clarification of the operation. You're welcome. however, i tried your solution too. this failed with the same errors as mentioned in the first post of the thread.. You sure that you don't have some other problem? file stripParTest.d: --- import std.algorithm; string stripPar(string S) { while(S[0] == '(' && S[S.length-1] == ')') { S = S[1 .. $ - 1]; } return S; } unittest { string testData = "((a)"; string result = stripPar(testData); assert(equal(result, "(a")); } --- run with: rdmd -unittest -main stripParTest.d Works fine for me.
Re: Remove function?
On Thursday, 5 December 2013 at 16:38:11 UTC, Chris Cain wrote: On Thursday, 5 December 2013 at 15:46:41 UTC, seany wrote: First thank you s much for clarification of the operation. You're welcome. however, i tried your solution too. this failed with the same errors as mentioned in the first post of the thread.. You sure that you don't have some other problem? file stripParTest.d: --- import std.algorithm; string stripPar(string S) { while(S[0] == '(' && S[S.length-1] == ')') { S = S[1 .. $ - 1]; } return S; } unittest { string testData = "((a)"; string result = stripPar(testData); assert(equal(result, "(a")); } --- run with: rdmd -unittest -main stripParTest.d Works fine for me. I dont think i have other problems other than perhaps a bug in 2.061 dmd? By the way does your solution edit the physical memory in place, or just change the way it is pointed to? in case of the second, is there an appropriate garbage collector?
Is this reasonable?
Here I feel like a beginner, but it seems very unfriendly: import std.stdio; struct ABC { double a; int b; bool c; } ABC[20] aabc; void foo(int n) { writefln("n: %d, aabc.length: %d", n, aabc.length); if (n < aabc.length) writeln("A"); else writeln("B"); } void main(string[] args) { int n = -1; foo(n); } This comes back with "B". If I change the test to (n < cast(int) aabc.length), then all is well. Is this unavoidable, or could the compiler safely make the conversion implicitly?
Re: Is this reasonable?
On Thu, Dec 05, 2013 at 06:15:37PM +0100, Steve Teale wrote: > Here I feel like a beginner, but it seems very unfriendly: > > import std.stdio; > > struct ABC > { >double a; >int b; >bool c; > } > > ABC[20] aabc; > > void foo(int n) > { >writefln("n: %d, aabc.length: %d", n, aabc.length); >if (n < aabc.length) > writeln("A"); >else > writeln("B"); > } > > void main(string[] args) > { >int n = -1; >foo(n); > } > > This comes back with "B". > > If I change the test to (n < cast(int) aabc.length), then all is > well. > > Is this unavoidable, or could the compiler safely make the > conversion implicitly? Comparing a signed value to an unsigned value is a risky operation. You should always compare values of like signedness, otherwise you'll run into problems like this. You can't compare -1 to an unsigned value because if that unsigned value happens to be uint.max, then there is no machine instruction that will give the correct result (the compiler would have to substitute the code with something like: uint y; if (x < 0 || cast(uint)x < y) { ... } which will probably introduce undesirable overhead. The compiler also can't automatically convert aabc.length to int, because if the length is greater than int.max (which is half of uint.max), the conversion would produce a wrong negative value instead, and the comparison will fail. So, comparing a signed value to an unsigned value is a dangerous, error-prone operation. Sadly, dmd doesn't warn about such risky operations; it just silently casts the values. Bearophile has often complained about this, and I'm starting to agree. This is one of the places in D where subtle mistakes can creep in and the compiler fails to warn the programmer of it. T -- Real Programmers use "cat > a.out".
Re: Remove function?
On Thursday, 5 December 2013 at 16:59:50 UTC, seany wrote: I dont think i have other problems other than perhaps a bug in 2.061 dmd? I'd definitely recommend upgrading to the latest release (2.064.2) since it has lots of bug fixes since 2.061. But if your code is still saying this (your original post): /home/apua/Software/dmd/dmd/src/phobos/std/algorithm.d(6992): Error: template std.algorithm.move does not match any function template declaration. Candidates are: ... Then you're probably using your old code somewhere. The stripPars I've suggested does not use std.algorithm.move at all. By the way does your solution edit the physical memory in place, or just change the way it is pointed to? It's just changing the view of the data. Ali's book covers this stuff in more detail: http://ddili.org/ders/d.en/index.html specifically: http://ddili.org/ders/d.en/slices.html in case of the second, is there an appropriate garbage collector? D uses garbage collection by default and it's aware of and fine with this type of thing.
how to build doc from source?
The instructions in http://wiki.dlang.org/Building_DMD are full of bugs (noone bothered to run those apparently), and running make -f posix.mak from dlang.org has issues, eg dependency on kindlegen. Furthermore, dlang.org's posix.mak requires a git clone, and clones an entire copy of phobos under phobos.2.064.2 (currently), alongside the already cloned phobos clone. How to I simply build docs that correspond to the currently checked out phobos repo ? (no additional clone, and no external dependency on kindlegen or other tool)
Re: Is this reasonable?
On Thursday, 5 December 2013 at 17:15:39 UTC, Steve Teale wrote: Is this unavoidable, or could the compiler safely make the conversion implicitly? It is example of notorious phenomemena called "integer promotions" and "usual arithmetic conversions". It is unavoidable given Walter's decision to keep this C stuff in D.
Re: Is this reasonable?
On Thursday, December 05, 2013 19:16:29 Maxim Fomin wrote: > On Thursday, 5 December 2013 at 17:15:39 UTC, Steve Teale wrote: > > Is this unavoidable, or could the compiler safely make the > > conversion implicitly? > > It is example of notorious phenomemena called "integer > promotions" and "usual arithmetic conversions". It is unavoidable > given Walter's decision to keep this C stuff in D. To be fair, you can't solve the problem automatically. It's fundamentally wrong to compare signed and unsigned values, and doing either the conversion to unsigned or to signed could be wrong (or both could be wrong), depending on the values. The best that could be done would be to warn about the comparison or to make it an error. http://d.puremagic.com/issues/show_bug.cgi?id=259 - Jonathan M Davis
Re: Checking Compiler version in code?
On Thursday, 5 December 2013 at 18:40:53 UTC, Jeremy DeHaan wrote: Hey all, I was wondering if there was a way to check the compiler version when running code. My project uses 2.064 and other people that go to use it will get errors if they haven't upgraded yet, and I'd like to make a check before hand so that if need be I can have a "Please upgrade to the most recent compiler" message show up or something. Thanks! http://dlang.org/phobos/std_compiler.html
Checking Compiler version in code?
Hey all, I was wondering if there was a way to check the compiler version when running code. My project uses 2.064 and other people that go to use it will get errors if they haven't upgraded yet, and I'd like to make a check before hand so that if need be I can have a "Please upgrade to the most recent compiler" message show up or something. Thanks!
Re: Is this reasonable?
On 12/5/13 2:15 PM, Steve Teale wrote: Here I feel like a beginner, but it seems very unfriendly: import std.stdio; struct ABC { double a; int b; bool c; } ABC[20] aabc; void foo(int n) { writefln("n: %d, aabc.length: %d", n, aabc.length); if (n < aabc.length) writeln("A"); else writeln("B"); } void main(string[] args) { int n = -1; foo(n); } This comes back with "B". If I change the test to (n < cast(int) aabc.length), then all is well. Is this unavoidable, or could the compiler safely make the conversion implicitly? Cough, cough, make array length be an int. Do you really need arrays that big? :-S (I'm talking to Mr. D Compiler here)
Re: scoped chdir and similar patterns
On Thursday, 5 December 2013 at 06:24:52 UTC, qznc wrote: = struct chdir_scoped { string olddir; this(string newdir) { olddir = "bar"; writeln("chdir to "~newdir); } ~this() { writeln("chdir back to "~olddir); } } int main() { auto x = chdir_scoped("foo"); writeln("doing work in foo"); return 0; } = Output: chdir to foo doing work in foo chdir back to bar = Feels hacky to me, since "x" is not used anywhere. with(chdir_scoped("foo")) writeln("doing work in foo"); Alas: https://d.puremagic.com/issues/show_bug.cgi?id=8269
Unresolvable references to dlopen, dlclose etc
I am on fresh install of Linux Mint 16 64bit and I tried to compile some D code I have writen and I have problems ("Hello World" works btw). I uses Derelict (v2) and I have successfully compiled/linked/rurn my program on Windows 7 64bit. But on Linux I get errors about unresolved references to dlopen, dlclose etc. although I am linking against libdl (ld finds the so; I checked the verbose output). Interestingly libdl.so is empty by nm. I found the symbols in libc. I am compiling everything from scratch with the newest dmd (2.064.2 that is) with -m64 in my dmd.conf (doesn't work without either). I have posted on the Derelict forums (http://dblog.aldacron.net/forum/index.php?topic=864.0) but I don't think it is a Derelict specific problem. Pleas help me!
Re: Is this reasonable?
On Thu, Dec 05, 2013 at 03:47:27PM -0300, Ary Borenszweig wrote: [...] > Cough, cough, make array length be an int. > > Do you really need arrays that big? :-S > > (I'm talking to Mr. D Compiler here) A negative length array makes no sense. Plus, being a systems language, D should be able to represent an entire 64-bit address space as an array of ubytes (even if this is rarely done!). If one were to write a kernel in D, it would be laughable to use signed array lengths. T -- Stop staring at me like that! It's offens... no, you'll hurt your eyes!
Re: how to build doc from source?
On Thu, Dec 05, 2013 at 10:09:59AM -0800, Timothee Cour wrote: > The instructions in http://wiki.dlang.org/Building_DMD are full of bugs > (noone bothered to run those apparently), and running make -f posix.mak > from dlang.org has issues, eg dependency on kindlegen. The original instructions on that page were only intended for dmd, druntime, and phobos, and they were tested and worked. The "building the docs" section was added later, and looks like they forgot to mention build dependencies. > Furthermore, dlang.org's posix.mak requires a git clone, and clones an > entire copy of phobos under phobos.2.064.2 (currently), alongside the > already cloned phobos clone. > > How to I simply build docs that correspond to the currently checked > out phobos repo ? (no additional clone, and no external dependency on > kindlegen or other tool) I find this an utter annoyance too. Somebody needs to document how to build the docs for *html only*, not all of the other jazz like git cloning release tarballs, running kindlegen, etc.. (Well, somebody needs to make it possible to do just this, in the first place.) I stopped working on docs after dlang.org started pulling in all kinds of dependencies that I don't have the time to figure out how to install / disable (I'm not exactly interested in generating the docs in kindle format, just so I can test my ddoc changes to Phobos!). T -- Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry
Re: Checking Compiler version in code?
On Thu, Dec 05, 2013 at 07:40:51PM +0100, Jeremy DeHaan wrote: > Hey all, > > I was wondering if there was a way to check the compiler version > when running code. My project uses 2.064 and other people that go to > use it will get errors if they haven't upgraded yet, and I'd like to > make a check before hand so that if need be I can have a "Please > upgrade to the most recent compiler" message show up or something. [...] static if (__VERSION__ < 2064L) static assert(0, "Please upgrade to version 2.064 or later"); T -- ASCII stupid question, getty stupid ANSI.
Re: how to build doc from source?
On Thu, Dec 5, 2013 at 11:40 AM, H. S. Teoh wrote: > On Thu, Dec 05, 2013 at 10:09:59AM -0800, Timothee Cour wrote: > > The instructions in http://wiki.dlang.org/Building_DMD are full of bugs > > (noone bothered to run those apparently), and running make -f posix.mak > > from dlang.org has issues, eg dependency on kindlegen. > > The original instructions on that page were only intended for dmd, > druntime, and phobos, and they were tested and worked. The "building the > docs" section was added later, and looks like they forgot to mention > build dependencies. > that's the one that's full of bugs. eg: git cline instead of clone make instead of make -f ... etc. > > > > Furthermore, dlang.org's posix.mak requires a git clone, and clones an > > entire copy of phobos under phobos.2.064.2 (currently), alongside the > > already cloned phobos clone. > > > > How to I simply build docs that correspond to the currently checked > > out phobos repo ? (no additional clone, and no external dependency on > > kindlegen or other tool) > > I find this an utter annoyance too. Somebody needs to document how to > build the docs for *html only*, not all of the other jazz like git > cloning release tarballs, running kindlegen, etc.. (Well, somebody needs > to make it possible to do just this, in the first place.) > > I stopped working on docs after dlang.org started pulling in all kinds > of dependencies that I don't have the time to figure out how to install > / disable (I'm not exactly interested in generating the docs in kindle > format, just so I can test my ddoc changes to Phobos!). > > > T > > -- > Let's not fight disease by killing the patient. -- Sean 'Shaleh' Perry >
Re: Is this reasonable?
On 12/5/13 4:35 PM, H. S. Teoh wrote: On Thu, Dec 05, 2013 at 03:47:27PM -0300, Ary Borenszweig wrote: [...] Cough, cough, make array length be an int. Do you really need arrays that big? :-S (I'm talking to Mr. D Compiler here) A negative length array makes no sense. Of course not. And it will never be negative. But make it signed and all the problems everyone is having several times every month will be gone forever. Plus, being a systems language, D should be able to represent an entire 64-bit address space as an array of ubytes (even if this is rarely done!). If one were to write a kernel in D, it would be laughable to use signed array lengths. You can use raw pointers for that if you are going to write a kernel in D. Or you can make a struct that wraps a pointer and length, make it uint and that's it. But to make array.length uint by default and have these surprises all of the time just because "a negative length doesn't make sense"... I don't know, I feel it's not the right way to do it.
Re: Is this reasonable?
On Thursday, 5 December 2013 at 19:51:52 UTC, Ary Borenszweig wrote: But to make array.length uint by default and have these surprises all of the time just because "a negative length doesn't make sense"... I don't know, I feel it's not the right way to do it. Length of array type is not uint by default. This is second issue in array.length.
Re: Is this reasonable?
On Thursday, 5 December 2013 at 18:26:48 UTC, Jonathan M Davis wrote: On Thursday, December 05, 2013 19:16:29 Maxim Fomin wrote: On Thursday, 5 December 2013 at 17:15:39 UTC, Steve Teale wrote: > Is this unavoidable, or could the compiler safely make the > conversion implicitly? It is example of notorious phenomemena called "integer promotions" and "usual arithmetic conversions". It is unavoidable given Walter's decision to keep this C stuff in D. To be fair, you can't solve the problem automatically. It's fundamentally wrong to compare signed and unsigned values, and doing either the conversion to unsigned or to signed could be wrong (or both could be wrong), depending on the values. The best that could be done would be to warn about the comparison or to make it an error. http://d.puremagic.com/issues/show_bug.cgi?id=259 - Jonathan M Davis Warning would be an option, but AFAIK Walter does not like warnings, so it is unlikely to be implemented.
Detecting value parameter of template instance in "is" expression
I'm trying to detect values that were instantiated from std.typecons.Nullable (and NullableRef). And I will net to get base types of these Nullable values. For simplicity I write the following code to test for Nullable. //--- import std.stdio, std.typecons; template isStdNullable(N) { static if( is( N == Nullable!(T), T ) || is( N == NullableRef!(T), T ) || is( N == Nullable!(T, nV), T, T nV ) //There is an error ) enum bool isNullable = true; else enum bool isNullable = false; } void main() { writeln(isStdNullable!(Nullable!(int, 10))); } //- Compilation output: /d966/f969.d(8): Error: undefined identifier T, did you mean alias N? /d966/f969.d(19): Error: template instance f969.isStdNullable!(Nullable!(int, 10)) error instantiating How should I define value parameters inside "is" expression to make code like this working?
Re: Detecting value parameter of template instance in "is" expression
On Thursday, 5 December 2013 at 20:07:51 UTC, Uranuz wrote: //--- import std.stdio, std.typecons; template isStdNullable(N) { static if( is( N == Nullable!(T), T ) || is( N == NullableRef!(T), T ) || is( N == Nullable!(T, nV), T, T nV ) //There is an error ) enum bool isNullable = true; else enum bool isNullable = false; } void main() { writeln(isStdNullable!(Nullable!(int, 10))); } //- Compilation output: /d966/f969.d(8): Error: undefined identifier T, did you mean alias N? /d966/f969.d(19): Error: template instance f969.isStdNullable!(Nullable!(int, 10)) error instantiating How should I define value parameters inside "is" expression to make code like this working? is( N == Nullable!(T), T ... )
Re: Is this reasonable?
On 12/5/13 4:59 PM, Maxim Fomin wrote: t and have these surprises all of the time just because "a negative length doesn't make sense"... I don't know, I feel it's not the right way to do it. ulong, it's the same thing.
Re: Detecting value parameter of template instance in "is" expression
On Thu, Dec 5, 2013 at 9:17 PM, anonymous wrote: > On Thursday, 5 December 2013 at 20:07:51 UTC, Uranuz wrote: >> How should I define value parameters inside "is" expression to make code >> like this working? > > > is( N == Nullable!(T), T ... ) Or is( N == Nullable!(T, nV), T, alias nV ) Since nV is most probably an alias template parameter.
Re: Is this reasonable?
On 12/05/2013 07:26 PM, Jonathan M Davis wrote: The best that could be done would be to warn about the comparison or to make it an error. http://d.puremagic.com/issues/show_bug.cgi?id=259 ... The best that could be done would arguably be to simply do the comparison the 'right' way. E.g. static assert(-1 < 0u).
Re: Is this reasonable?
On Thursday, 5 December 2013 at 18:26:48 UTC, Jonathan M Davis wrote: On Thursday, December 05, 2013 19:16:29 Maxim Fomin wrote: On Thursday, 5 December 2013 at 17:15:39 UTC, Steve Teale wrote: the values. The best that could be done would be to warn about the comparison or to make it an error. http://d.puremagic.com/issues/show_bug.cgi?id=259 If Walter agrees...
Re: Is this reasonable?
On Thursday, 5 December 2013 at 17:44:18 UTC, H. S. Teoh wrote: On Thu, Dec 05, 2013 at 06:15:37PM +0100, Steve Teale wrote: Here I feel like a beginner, but it seems very unfriendly: import std.stdio; struct ABC { double a; int b; bool c; } ABC[20] aabc; void foo(int n) { writefln("n: %d, aabc.length: %d", n, aabc.length); if (n < aabc.length) writeln("A"); else writeln("B"); } void main(string[] args) { int n = -1; foo(n); } This comes back with "B". If I change the test to (n < cast(int) aabc.length), then all is well. Is this unavoidable, or could the compiler safely make the conversion implicitly? Comparing a signed value to an unsigned value is a risky operation. You should always compare values of like signedness, otherwise you'll run into problems like this. You can't compare -1 to an unsigned value because if that unsigned value happens to be uint.max, then there is no machine instruction that will give the correct result (the compiler would have to substitute the code with something like: uint y; if (x < 0 || cast(uint)x < y) { ... } which will probably introduce undesirable overhead. The compiler also can't automatically convert aabc.length to int, because if the length is greater than int.max (which is half of uint.max), the conversion would produce a wrong negative value instead, and the comparison will fail. So, comparing a signed value to an unsigned value is a dangerous, error-prone operation. Sadly, dmd doesn't warn about such risky operations; it just silently casts the values. Bearophile has often complained about this, and I'm starting to agree. This is one me too, me too, me too
Re: Is this reasonable?
On Thursday, 5 December 2013 at 19:51:52 UTC, Ary Borenszweig wrote: On 12/5/13 4:35 PM, H. S. Teoh wrote: On Thu, Dec 05, 2013 at 03:47:27PM -0300, Ary Borenszweig wrote: [...] Cough, cough, make array length be an int. Do you really need arrays that big? :-S (I'm talking to Mr. D Compiler here) A negative length array makes no sense. Of course not. And it will never be negative. But make it signed and all the problems everyone is having several times every month will be gone forever. I defended once the approach took by FreePascal: they declared a signed integer that covered the larges available range on a machine (now it occurred to me that the compiler could even cover *twice* that range with a simple trick) and then, all other integer types, signed or unsigned/positive were sub-ranges of the first. Comparisons were made at this largest level. I dunno how complicated and how much overhead for this.
Re: Is this reasonable?
On Thursday, 5 December 2013 at 19:36:46 UTC, H. S. Teoh wrote: On Thu, Dec 05, 2013 at 03:47:27PM -0300, Ary Borenszweig wrote: [...] Cough, cough, make array length be an int. Do you really need arrays that big? :-S (I'm talking to Mr. D Compiler here) A negative length array makes no sense. Does really "unsigned" means "positive"? Or only "a value without sign"? I remember Walter defending the latter point of view and not accepting "unsigned" == "positive".
Re: Detecting value parameter of template instance in "is" expression
On 12/05/2013 01:00 PM, Philippe Sigaud wrote: > On Thu, Dec 5, 2013 at 9:17 PM, anonymous wrote: >> On Thursday, 5 December 2013 at 20:07:51 UTC, Uranuz wrote: > >>> How should I define value parameters inside "is" expression to make code >>> like this working? >> >> >> is( N == Nullable!(T), T ... ) > > Or > > is( N == Nullable!(T, nV), T, alias nV ) > > Since nV is most probably an alias template parameter. > But none of those answer what I think the OP is asking: T must be a type AND nV must be a value of that type. I had thought the following to be true (especially the last quoted sentence) [1]: is (T : Specifier, TemplateParamList) is (T == Specifier, TemplateParamList) is (T identifier : Specifier, TemplateParamList) is (T identifier == Specifier, TemplateParamList) These syntaxes allow for more complex cases. identifier may be omitted. identifier, Specifier, :, and == all have the same meanings as described above. TemplateParamList is both a part of the condition that needs to be satisfied and a facility to define additional aliases if the condition is indeed satisfied. It works in the same way as template type deduction. If my the last sentence of mine is correct, then this is an implementation problem as Uranuz's syntax should work. Although, I don't see why my sentence would not be true. It definitely to be so in many other uses. Ali [1] http://ddili.org/ders/d.en/is_expr.html
Re: Checking Compiler version in code?
On Thursday, 5 December 2013 at 18:45:08 UTC, Dicebot wrote: On Thursday, 5 December 2013 at 18:40:53 UTC, Jeremy DeHaan wrote: Hey all, I was wondering if there was a way to check the compiler version when running code. My project uses 2.064 and other people that go to use it will get errors if they haven't upgraded yet, and I'd like to make a check before hand so that if need be I can have a "Please upgrade to the most recent compiler" message show up or something. Thanks! http://dlang.org/phobos/std_compiler.html How did I miss this? :P Thanks very much!
Re: Checking Compiler version in code?
On Thursday, 5 December 2013 at 19:43:09 UTC, H. S. Teoh wrote: On Thu, Dec 05, 2013 at 07:40:51PM +0100, Jeremy DeHaan wrote: Hey all, I was wondering if there was a way to check the compiler version when running code. My project uses 2.064 and other people that go to use it will get errors if they haven't upgraded yet, and I'd like to make a check before hand so that if need be I can have a "Please upgrade to the most recent compiler" message show up or something. [...] static if (__VERSION__ < 2064L) static assert(0, "Please upgrade to version 2.064 or later"); T That's very interesting as well. Seeing things like this makes me realize how much more I have to learn about this language.
Re: Is this reasonable?
On Thursday, 5 December 2013 at 19:36:46 UTC, H. S. Teoh wrote: On Thu, Dec 05, 2013 at 03:47:27PM -0300, Ary Borenszweig wrote: [...] Cough, cough, make array length be an int. Do you really need arrays that big? :-S (I'm talking to Mr. D Compiler here) A negative length array makes no sense. Plus, being a systems language, D should be able to represent an entire 64-bit address space as an array of ubytes (even if this is rarely done!). If one were to write a kernel in D, it would be laughable to use signed array lengths. T Chandler Carruth of LLVM fame (also on the C++ ISO Committee) said during Going Native (it was either his talk or the panel, I can't remember which unfortunately) that C++'s decision to make size_t unsigned was a big mistake and you should almost always use signed integers unless you need two's complement arithmetic for some weird reason. I can't remember the entire rationale for this though. http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons http://channel9.msdn.com/Events/GoingNative/2013/Interactive-Panel-Ask-Us-Anything
Re: scoped chdir and similar patterns
On Thursday, December 05, 2013 07:24:50 qznc wrote: > On Thursday, 5 December 2013 at 01:07:19 UTC, Timothee Cour wrote: > > A1. > > > > Is there a (clever?) way to achieve the following using a > > single function > > call? > > You could (mis)use destructors. > > = > struct chdir_scoped { > string olddir; > this(string newdir) { > olddir = "bar"; > writeln("chdir to "~newdir); > } > ~this() { > writeln("chdir back to "~olddir); > } > } > > int main() { > auto x = chdir_scoped("foo"); > writeln("doing work in foo"); > return 0; > } > = > Output: > chdir to foo > doing work in foo > chdir back to bar > = > > Feels hacky to me, since "x" is not used anywhere. That technique is called RAII - Resource Acquisition Is Initialization - and it's a standard technique in C++ which D's structs also purposefully support. In C++, without it, having exception-safe C++ is very, very difficult, if not impossible. Prime examples of it are smart pointers and mutex autolocks/guards. Unlike C++, D has finally and scope statements (as well as the GC), which help, but still, RAII is vital for a number of paradigms. I can understand that it seems a bit weird to have a variable that you declare and don't do anything else with, but there's nothing hacky about it. It's an extremely useful and heavily-used paradigm. https://en.wikipedia.org/wiki/RAII - Jonathan M Davis
regading detection of stdin
Hi, I was trying to do something like this (using dmd.2.064.2 both from Windows and Linux), but if nothing is passed from stdin and no parameter is provided, the application freezes: import std.stdio, std.file: readText; int main(string[] args) { string s; switch (args.length) { case 1: if ((s = stdin.readln()) is null) writeln("No argument passed as parameter or from stdin."); else writeln("Argument passed from stdin succesfully stored in variable s."); scope (failure) { writeln("Error reading from stdin."); return -1; } break; case 2: s = readText(args[1]); scope (failure) { writeln("Error reading from file passed as parameter."); return -2; } writeln("Argument passed as parameter succesfully stored in variable s."); break; default: writeln("Incorrect number of parameters. Maximum is one."); return -3; } return 0; } Where is the problem? Regards, Hugo
Re: regading detection of stdin
On Friday, 6 December 2013 at 00:24:22 UTC, Hugo Florentino wrote: if nothing is passed from stdin and no parameter is provided, the application freezes: Does it freeze or just wait for you to press enter on the keyboard?
Output Sound to Multiple Devices?
So I'm looking at creating a virtual soundboard, but the whole point of making it would be moot if I can't get it to write to two output streams (a virtual cable and my headphones). Is it possible to hook into two audio output devices and send sound streams to both simultaneously?
Re: Output Sound to Multiple Devices?
What sound library/OS setup are you using?
Re: Output Sound to Multiple Devices?
On Friday, 6 December 2013 at 00:33:07 UTC, Adam D. Ruppe wrote: What sound library/OS setup are you using? This will, initially, be Windows, as I'm only making it for myself, but if I can get it working well enough, I may want to have it cross-platform. I am currently working with the D bindings of SFML, but I can use another thing for sound loading if I have to.
Re: About compiler memory consumption
On Thursday, 5 December 2013 at 13:49:51 UTC, Dicebot wrote: On Thursday, 5 December 2013 at 04:02:58 UTC, Puming wrote: There maybe another traditional approach, by converting the .dt diet templates directly into D source code BEFORE the actuall compilation. That is the way many other HTML template systems use, and the performance is fairly good. It is somewhat complicated by the very tight integration between D handler host and Diet - you can expose D symbols for rendering context to template. It is still possible to do it that way but is likely to require more efforts and effectively will just to the same thing as good JIT-ed CTFE should. I don't like it because it is too effort-demanding for a quick hack and not suitable in the long term by design (one of D goals was to remove reliance on external build steps as much as possible) Yes, I agree that for dev mode a pure runtime version would fit more and its implementation could take advantage of many functions in the CTFE version (or is that already possible?)
Re: Is this reasonable?
On Thu, Dec 05, 2013 at 10:06:55PM +0100, Timon Gehr wrote: > On 12/05/2013 07:26 PM, Jonathan M Davis wrote: > >The best that could be done would be to warn about the comparison > >or to make it an error. > > > >http://d.puremagic.com/issues/show_bug.cgi?id=259 > >... > > The best that could be done would arguably be to simply do the > comparison the 'right' way. E.g. static assert(-1 < 0u). What's the 'right' way? assert(-1 < uint.max) will always fail because no matter whether you convert to int or uint, the comparison simply cannot be carried out at the machine code level. The only way you can get a sane answer out of this is if the compiler translates it into: if (intVar < 0 || cast(uint)intVar < uintVar) { ... } T -- BREAKFAST.COM halted...Cereal Port Not Responding. -- YHL
Re: Output Sound to Multiple Devices?
Hmm, I don't really know. But what I'd do (if nobody else here knows) is to search for/ask the library help list how to do it with SFML in C, then translate that to D.
Re: Measuring ticks (or time) per threads
On Thursday, 5 December 2013 at 06:22:35 UTC, Rob T wrote: Also please post a bug or enhancement issue for anything that you think ought to be included in the standard libs that isn't. https://d.puremagic.com/issues/ --rt Done
Re: Is this reasonable?
On Thursday, December 05, 2013 23:44:33 Brad Anderson wrote: > On Thursday, 5 December 2013 at 19:36:46 UTC, H. S. Teoh wrote: > > On Thu, Dec 05, 2013 at 03:47:27PM -0300, Ary Borenszweig wrote: > > [...] > > > >> Cough, cough, make array length be an int. > >> > >> Do you really need arrays that big? :-S > >> > >> (I'm talking to Mr. D Compiler here) > > > > A negative length array makes no sense. > > > > Plus, being a systems language, D should be able to represent > > an entire > > 64-bit address space as an array of ubytes (even if this is > > rarely > > done!). If one were to write a kernel in D, it would be > > laughable to use > > signed array lengths. > > > > > > T > > Chandler Carruth of LLVM fame (also on the C++ ISO Committee) > said during Going Native (it was either his talk or the panel, I > can't remember which unfortunately) that C++'s decision to make > size_t unsigned was a big mistake and you should almost always > use signed integers unless you need two's complement arithmetic > for some weird reason. I can't remember the entire rationale for > this though. > > http://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s > -Dragons > http://channel9.msdn.com/Events/GoingNative/2013/Interactive-Panel-Ask-Us-A > nything Don loves to argue the same thing. If all we had to deal with was 64-bit and larger, then it would probably be fine, but it's much more debatable with 32- bit and smaller, as with those architectures, you actually can need the full address range for large data sets. 64-bit is large enough that that's not going to be an issue - you couldn't even have that much memory to address at this point. Maybe someday it could matter but probably not except with something like mmap on systems with a ton of hard drives mapped as a single drive or somesuch. So, if we only supported 64-bit and larger, then I might support the idea of size_t being signed, but as long as we have to worry about 32-bit, I don't think that that's really an option. Regardless, we're pretty much stuck at this point. Changing it would silently break lots of code. Making the signed/unsigned comparison an error is probably our only real option at this point, and that would have the advantage of fixing it in all cases where you're mixing signed and unsigned numbers, not just in cases where you're dealing with length. - Jonathan M Davis
Re: regading detection of stdin
On Fri, 06 Dec 2013 01:26:28 +0100, Adam D. Ruppe wrote: On Friday, 6 December 2013 at 00:24:22 UTC, Hugo Florentino wrote: if nothing is passed from stdin and no parameter is provided, the application freezes: Does it freeze or just wait for you to press enter on the keyboard? I see... so the "problem" simply was that function readln was expecting user input. In that case, this is not what I intended. I want the application to receive the stdout of another command as stdin, and to detect if nothing is sent. How coud I accomplish this?
how to compose delegate type
how do I construct F!(T) to yield void delegate() immutable when T is void delegate() ? [its been a long day]
Re: Detecting value parameter of template instance in "is" expression
As far as I understand TemplateParamList in *is* expr should work just like it works in usual template. So this problem is just lack of implementation. I'll try to find workaround with * is( N == Nullable!(T), T ... ) * syntax. Thank you for response.
I/O related question, and ini parsing
So, it's my first time implementing something like logging and ini parsing/creating, and it appears to work perfectly, but I'm not neccessarily a master of D yet.. So, I wanted some advice from my seniors if there's anything I should improve on such, I might be missing out on some D-only features, so I'd appreciate it. The important stuff is in /src/breaker/utility: https://github.com/ICGCC/Breaker-3D-Game-Engine I'm a bit curious if my shader loading model is appropriate too, that's in /src/breaker/utility/render.d, but you don't have to worry about that if you're not interested. Anyways, thank you for you time and advice!
Re: I/O related question, and ini parsing
On 12/05/2013 08:43 PM, Mineko wrote: > I might be missing out on some D-only features The first thing I've noticed is that you are not using UFCS, perhaps because you don't like it (yet ;) ) but look how natural the syntax becomes: existing code (my indentation): temp = findSplitAfter(findSplitBefore(find(source, var~" = "), ";")[0], " = ")[1]; code taking advantage of D's UFCS (I hope I got it right; I have not compiled it): temp = source .find(var~" = ") .findSplitBefore(";")[0] .findSplitAfter(" = ")[1]; Ali
Re: how to compose delegate type
On Friday, 6 December 2013 at 02:42:44 UTC, Ellery Newcomer wrote: how do I construct F!(T) to yield void delegate() immutable when T is void delegate() ? [its been a long day] I don't think I understand what you mean: void main() { F!(void delegate()); } immutable(T) F(T)() { return () {}; } Initially I thought you meant T was a void delegate but passing delegates as compile time parameters isn't really an option.
Re: I/O related question, and ini parsing
On Friday, 6 December 2013 at 05:22:07 UTC, Ali Çehreli wrote: On 12/05/2013 08:43 PM, Mineko wrote: > I might be missing out on some D-only features The first thing I've noticed is that you are not using UFCS, perhaps because you don't like it (yet ;) ) but look how natural the syntax becomes: existing code (my indentation): temp = findSplitAfter(findSplitBefore(find(source, var~" = "), ";")[0], " = ")[1]; code taking advantage of D's UFCS (I hope I got it right; I have not compiled it): temp = source .find(var~" = ") .findSplitBefore(";")[0] .findSplitAfter(" = ")[1]; Ali I didn't even know that existed, I'll jump on that right now.
Re: regading detection of stdin
On Friday, 6 December 2013 at 02:41:28 UTC, Hugo Florentino wrote: I see... so the "problem" simply was that function readln was expecting user input. In that case, this is not what I intended. I want the application to receive the stdout of another command as stdin, and to detect if nothing is sent. How coud I accomplish this? Then you'll want std.process[1]. This provides functions for "piping" output[2]. As for detecting output, that can only be verified once the other process has finished; to handle that it should be reasonable to execute[3] and check the complete output. 1. http://dlang.org/phobos/std_process.html 2. http://dlang.org/phobos/std_process.html#.pipeProcess 3. http://dlang.org/phobos/std_process.html#.execute
Re: Detecting value parameter of template instance in "is" expression
On Fri, Dec 6, 2013 at 5:31 AM, Uranuz wrote: > As far as I understand TemplateParamList in *is* expr should work just like > it works in usual template. So this problem is just lack of implementation. > I'll try to find workaround with * is( N == Nullable!(T), T ... ) * syntax. > > Thank you for response. Once you are 'inside' a static if guarded by an is() expression, the symbols you introduced inside the is() are visible, so you can test T... further if you want. In my proposal, nV is visible right after the is(), so here is a more correct expression: import std.stdio, std.typecons; template isStdNullable(N) { static if( is( N == Nullable!(T), T ) || is( N == NullableRef!(T), T ) || is( N == Nullable!(T, nV), T, alias nV ) && is(typeof(nV) == T) // <-- There ) enum bool isStdNullable = true; else enum bool isStdNullable = false; } void main() { writeln(isStdNullable!(Nullable!(int, 10))); }