Re: FormatSpec struct
* Paul D. Anderson paul.d.removethis.ander...@comcast.andthis.net [2012-04-13 07:50:31 +0200]: I'm trying to add formatted output to my decimal arithmetic module. Decimals should format like floating point, using 'E', 'F' and 'G', etc. I would expect a format string like %9.6e to parse as width = 9, precision = 6, using exponential notation. In std.format there is a FormatSpec struct that looks as if it will do the parsing for me. As far as I can tell the usage is: auto spec = std.format.FormatSpec!char(9.6e); writeln(fmtspec = , fmtspec); But it doesn't do what I think it should do. The output of the method is: fmtspec = address = 1637116 width = 0 precision = 2147483646 spec = s indexStart = 0 indexEnd = 0 flDash = false flZero = false flSpace = false flPlus = false flHash = false nested = trailing = 9.6e The width field should be 9, the precision field should be 6, and the spec field should be 'e'. Instead it seems to disregard the input string and return a default FormatSpec, with only the 'trailing' field populated, containing the input. What am I missing here? I've tried variations -- %9.6e, s, %s, etc, but the input is always relegated to the trailing field. Paul Hey Paul, so some investigation has led me to believe that FormatSpec is really just for internal usage. The documentation is a bit misleading (to the point of being possibly completely false). FormatSpec, AFAICT, is essentially just a parser for the standard format specifier, but its not very clear as to proper usage. I'm going to try to improve it and submit a pull request, until then looking at the source code for std.format should give you some idea of how to best use it. -- James Miller
Re: Sampling algorithms for D
On 13.04.2012 1:48, Joseph Rushton Wakeling wrote:
On 12/04/12 21:54, bearophile wrote:
for( t=recordsRemaining-1; t=limit; --t)
y2 *= top--/bottom--;
Generally packing mutation of variables inside expressions is quite
bad style. It makes code less easy to understand and translate, and
currently it's not defined, just as in C (it will be defined, but it
will keep being bad style).
OK. There's one other that should be a point of concern, where I have
return currentRecord++;
... in one function; I've added a selectedRecord variable to get round
this.
I believe it's something that reasonable people may disagree on. To me
it's perfectly easy to see what return x++; does. So is arr[i++] = ...,
so is arr1[i++] = arr2[j++]. But the downward loops look hairy all the
time ;)
Also in D there is (I hope it will not be deprecated)
foreach_reverse(), maybe to replace this for().
or use some std.range primitives ( I think iota does a [begin, end) range)
foreach( x ; iota(recordRemaining-1, limit+1, -1)){
y2 *= top--/bottom--;
}
[snip]
--
Dmitry Olshansky
Re: Sampling algorithms for D
On 13.04.2012 2:50, Joseph Rushton Wakeling wrote: On 12/04/12 23:34, Dmitry Olshansky wrote: Aye, and in general community does appreciate any enhancements via pull requests on github: https://github.com/D-Programming-Language OK, I'll see what I can do. I'd like to discuss and refine the design a bit further before making any pull request -- should I take things over to the Phobos mailing list for this ... ? I'm no authority but there is this d.D newsgroup which is perfectly fine for this kind of thing. A lot of nice people just don't (have time to) mess with unwashed masses in D.learn :) -- Dmitry Olshansky
Re: FormatSpec struct
* James Miller ja...@aatch.net [2012-04-13 19:16:48 +1200]: * Paul D. Anderson paul.d.removethis.ander...@comcast.andthis.net [2012-04-13 07:50:31 +0200]: I'm trying to add formatted output to my decimal arithmetic module. Decimals should format like floating point, using 'E', 'F' and 'G', etc. I would expect a format string like %9.6e to parse as width = 9, precision = 6, using exponential notation. Hey Paul, so some investigation has led me to believe that FormatSpec is really just for internal usage. The documentation is a bit misleading (to the point of being possibly completely false). FormatSpec, AFAICT, is essentially just a parser for the standard format specifier, but its not very clear as to proper usage. I'm going to try to improve it and submit a pull request, until then looking at the source code for std.format should give you some idea of how to best use it. -- James Miller So I made the pull request, the documentation you need to read is here: https://github.com/Aatch/phobos/commit/cda3c079ee32d98a017f88949c10097840baa075 Hopefully it helps. -- James Miller
Re: Sampling algorithms for D
On 13/04/12 01:44, bearophile wrote:
final size_t select(ref UniformRNG urng)
in {
assert(_recordsRemaining 0);
assert(_sampleRemaining 0);
} body {
...
}
OK. I'm confused by these asserts, because if I go beyond what is acceptable by
calling select() even after I've collected a complete sample, no error is
thrown. e.g. if I put in place a function:
void sampling_test_simple(SamplerType, UniformRNG)
(size_t records, size_t samples, ref UniformRNG urng)
{
auto s = new SamplerType(records,samples,urng);
while(s.sampleRemaining 0) {
write(\trecord selected: , s.select(urng), .);
write(\trecords remaining: , s.recordsRemaining, .);
writeln(\tstill to sample: , s.sampleRemaining, .);
}
// Let's see if we can bust this ...
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
writeln(Selecting 1 more just for luck: , s.select(urng), , records
remaining: , s.recordsRemaining, , still to sample: , s.sampleRemaining);
}
(... see current GitHub code: https://github.com/WebDrake/SampleD )
It doesn't make any difference if I compile with -debug enabled:
gdmd -debug -oftest sampled.d
Re: Sampling algorithms for D
Dmitry Olshansky:
I believe it's something that reasonable people may disagree on.
To me it's perfectly easy to see what return x++; does.
I agree that return x++; is not too bad for a human reader, but code with
mutation inside expressions (mostly written by other people) has caused me tons
of troubles (and the semantics of ++ and -- are as much undefined in D as in C,
still). So I usually kit it with fire as soon as I see it.
I'd like to modify the -- and ++ to make them return void. I think Go is
designed like that.
or use some std.range primitives ( I think iota does a [begin, end) range)
foreach( x ; iota(recordRemaining-1, limit+1, -1)){
y2 *= top--/bottom--;
}
Only if you don't care a lot for the performance of that specific loop. (DMD is
sometimes not even able to optimize foreach() loops as well as for() loops. Go
figure what it does on iota()).
Bye,
bearophile
Re: Sampling algorithms for D
Joseph Rushton Wakeling:
final size_t select(ref UniformRNG urng)
in {
assert(_recordsRemaining 0);
assert(_sampleRemaining 0);
} body {
...
}
OK. I'm confused by these asserts,
What's confusing? I don't understand. It's contract-based programming, the code
is essentially the same as before:
http://dlang.org/dbc.html
Bye,
bearophile
Re: Library search path on Windows?
On 13-04-2012 05:25, Jesse Phillips wrote: On Friday, 13 April 2012 at 01:10:40 UTC, Alex Rønne Petersen wrote: How do I pass a library search path to DMD on Windows? I would love to know too! Only place I found was to edit sc.ini sorry. It seems that -L+path does the trick... I only found that after scavenging the wiki. -- - Alex
Re: Sampling algorithms for D
On 13/04/12 13:10, bearophile wrote: What's confusing? I don't understand. It's contract-based programming, the code is essentially the same as before: http://dlang.org/dbc.html No, I understand the principle; I just don't understand why the code is running without errors being displayed when I violate the bounds of those asserts.
Re: GUI library
On Sunday, 25 March 2012 at 15:59:21 UTC, Jacob Carlborg wrote: On 2012-03-25 17:22, Kevin Cox wrote: I would reccomend Qt as well. You will get native cross-platform widgets with great performance. I am not sure how far QtD is but I know it once had a lot of development on it. I don't think Qt is uses the native drawing operations on Mac OS X. Qt does support native drawing operations on Mac OS X since 4.5.0, when it switched from Carbon to Cocoa as its backend. More info here[1] and here[2]. [1]: http://labs.qt.nokia.com/2007/06/21/wwdc-qt-carbon-64-bit-and-other-buzzwords/ [2]: http://labs.qt.nokia.com/2008/03/03/qtmac-cocoa-port-alpha-released/ - Rizo
Re: GUI library
On Sunday, 25 March 2012 at 15:14:04 UTC, Jacob Carlborg wrote: It would also be possible to use Cocoa, as you do with Objective-C, but that wouldn't be very practically. There's also a DMD fork that directly supports interfacing with Objective-C: http://michelf.com/projects/d-objc/ Why do you say that the usage of Cocoa through the D-ObjC bridge would not be very practical? What are the possible limitations? - Rizo
Avoid compile time evaluation
If I have something like: static int var = myFunction(); dmd will evaluate myFunction() at compile time. If it can't, it gives me a compile error, doesn't it? If I'm not wrong, static force this. If i don't use static, dmd will try to evaluate myfunction() at compile time, and if it can't, myfunction() will be executed at runtime, right? So I have a code like this: ... // Here some code to debug/fix... // Here some code to debug/fix... // Here some code to debug/fix... // Here some code to debug/fix... ... static int var = myVeryVeryComplexFunction(); If i have to work to some code before my complex function, every time I have to re-compile code, it takes a lot because dmd evalute at compile time myVeryVeryComplexFunction() also if i don't use static. Does a keyword to force runtime evaluation exists? I can't find any documentation (neither on static used in this way, any link?)... My dirty way to do this is to edit myVeryVeryComplexFunction() adding a writeln() (or something similar) to function body.
Re: Avoid compile time evaluation
On Fri, 13 Apr 2012 14:52:05 +0200, Andrea Fontana nos...@example.com wrote: If I have something like: static int var = myFunction(); dmd will evaluate myFunction() at compile time. If it can't, it gives me a compile error, doesn't it? If I'm not wrong, static force this. Indeed. If i don't use static, dmd will try to evaluate myfunction() at compile time, and if it can't, myfunction() will be executed at runtime, right? No. static or enum forces evaluation at compiletime, otherwise it's runtime. Conceivably, the compiler could try running every function at compile-time as an optimization, but that would completely destroy the nice compilation times we like to brag about, and likely also break a lot of code. So I have a code like this: ... // Here some code to debug/fix... // Here some code to debug/fix... // Here some code to debug/fix... // Here some code to debug/fix... ... static int var = myVeryVeryComplexFunction(); If i have to work to some code before my complex function, every time I have to re-compile code, it takes a lot because dmd evalute at compile time myVeryVeryComplexFunction() also if i don't use static. Does a keyword to force runtime evaluation exists? I can't find any documentation (neither on static used in this way, any link?)... See above. Runtime evaluation is the default, and compile-time needs to be forced.
Re: GUI library
Kevin Cox wrote: I would reccomend Qt as well. You will get native cross-platform widgets with great performance. I am not sure how far QtD is but I know it once had a lot of development on it. AFAIR, QtD is at the alpha stage. It's based on QtJambi, but there is another SMOKE generator, which might be worth giving a try.
D-Cocoa Port
Hi, I am planning to use D for creating native applications on Mac OS X. For that, of course, D must interact with the Cocoa API. I have no knowledge of how this bindings could be done. I've already looked at Cocado[1] and do know the Michel Fortin's D-ObjC bridge[2], and would like to be enlightened about some details: * What is their (or any other possible) approach of porting Cocoa to D? -- here I essentially ask for technical reading sources (books/articles/references, etc); * Is it possible to establish an ABI compatibility with ObjC directly or through the C ABI? -- There's a question on _stackoverflow_[3] where the answers describe what could be achieved with Objective-C's Runtime Reference[4]; * Is it feasible to make this kind of stuff work nicely and get the level of performance and stability like, e.g., with Qt framework on Mac OS X? I have no experience at all in this field so forgive me any technical faults. Any help would be appreciable. Thanks in advance for your responses. [1]: http://sourceforge.net/projects/cocodao/ [2]: http://michelf.com/projects/d-objc/ [3]: http://stackoverflow.com/questions/5901508/calling-cocoa-apis-from-c [4]: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html - Rizo
Re: GUI library
On 2012-04-13 14:47, Rizo Isrof wrote: On Sunday, 25 March 2012 at 15:59:21 UTC, Jacob Carlborg wrote: On 2012-03-25 17:22, Kevin Cox wrote: I would reccomend Qt as well. You will get native cross-platform widgets with great performance. I am not sure how far QtD is but I know it once had a lot of development on it. I don't think Qt is uses the native drawing operations on Mac OS X. Qt does support native drawing operations on Mac OS X since 4.5.0, when it switched from Carbon to Cocoa as its backend. More info here[1] and here[2]. [1]: http://labs.qt.nokia.com/2007/06/21/wwdc-qt-carbon-64-bit-and-other-buzzwords/ [2]: http://labs.qt.nokia.com/2008/03/03/qtmac-cocoa-port-alpha-released/ - Rizo If I recall correctly I read somewhere that they went back to non-native due to some problems with flicker, but that sounds very strange. -- /Jacob Carlborg
Re: GUI library
On 2012-04-13 14:51, Rizo Isrof wrote: On Sunday, 25 March 2012 at 15:14:04 UTC, Jacob Carlborg wrote: It would also be possible to use Cocoa, as you do with Objective-C, but that wouldn't be very practically. There's also a DMD fork that directly supports interfacing with Objective-C: http://michelf.com/projects/d-objc/ Why do you say that the usage of Cocoa through the D-ObjC bridge would not be very practical? What are the possible limitations? What I was referring to above was to interface with Objective-C without using a bridge. That is just very verbose and tedious. There's a lot of code to write just to create a new class, call a method and so on. The problem with the D/Objective-C bridge is bloat. A Hello World application written using the bridge takes around 60MB. It also slows down compilation time. -- /Jacob Carlborg
Re: Avoid compile time evaluation
That's strange, so why writeln make it compile faster? :) I can't post the code, i'll try to reproduce it... On Friday, 13 April 2012 at 13:01:03 UTC, Simen Kjaeraas wrote: On Fri, 13 Apr 2012 14:52:05 +0200, Andrea Fontana nos...@example.com wrote: If I have something like: static int var = myFunction(); dmd will evaluate myFunction() at compile time. If it can't, it gives me a compile error, doesn't it? If I'm not wrong, static force this. Indeed. If i don't use static, dmd will try to evaluate myfunction() at compile time, and if it can't, myfunction() will be executed at runtime, right? No. static or enum forces evaluation at compiletime, otherwise it's runtime. Conceivably, the compiler could try running every function at compile-time as an optimization, but that would completely destroy the nice compilation times we like to brag about, and likely also break a lot of code. So I have a code like this: ... // Here some code to debug/fix... // Here some code to debug/fix... // Here some code to debug/fix... // Here some code to debug/fix... ... static int var = myVeryVeryComplexFunction(); If i have to work to some code before my complex function, every time I have to re-compile code, it takes a lot because dmd evalute at compile time myVeryVeryComplexFunction() also if i don't use static. Does a keyword to force runtime evaluation exists? I can't find any documentation (neither on static used in this way, any link?)... See above. Runtime evaluation is the default, and compile-time needs to be forced.
Re: D-Cocoa Port
On 2012-04-13 15:34, Rizo Isrof wrote: Hi, I am planning to use D for creating native applications on Mac OS X. For that, of course, D must interact with the Cocoa API. I have no knowledge of how this bindings could be done. I've already looked at Cocado[1] and do know the Michel Fortin's D-ObjC bridge[2], and would like to be enlightened about some details: * What is their (or any other possible) approach of porting Cocoa to D? -- here I essentially ask for technical reading sources (books/articles/references, etc); There are three ways (two deepening on how you look at it). 1. Use the Objective-C runtime manually, which is implement with regular C functions. https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html 2. Use a bridge that handles everything nicely. The bridge uses the same implementation as in the first way. The bridge also performs type conversions automatically and other things to ease the development. http://www.dsource.org/projects/dstep http://michelf.com/projects/d-objc-bridge/ 3. Implement direct support in the language to be compatible with Objective-C. This is what Michel Fortin did here: http://michelf.com/projects/d-objc/ (Note, this is not a bridge) He forked DMD and added support for extern(Objective-C) which will output code similar to what GCC/Clang would do. This is a more direct way to interface with Objective-C and won't add any more overhead than using Objective-C directly would. I guess this would mean the ABI's are compatible. * Is it possible to establish an ABI compatibility with ObjC directly or through the C ABI? -- There's a question on _stackoverflow_[3] where the answers describe what could be achieved with Objective-C's Runtime Reference[4]; Both are possible, see above. * Is it feasible to make this kind of stuff work nicely and get the level of performance and stability like, e.g., with Qt framework on Mac OS X? I think so if you use Michel's fork of DMD. I have no experience at all in this field so forgive me any technical faults. Any help would be appreciable. Thanks in advance for your responses. I think the best way is to use the third one mentioned in the list above. Note that this is based on an older version of DMD. The project is not finished yet and is currently on old. Although an alpha version has been released. The problem with a bridge is the it cause way to much bloat. A Hello World application written using a bridge generated a 60MB executable. Using the Objective-C runtime manually is just too verbose and tedious. If you are interested in this you can have a look at my documentation of how my Objective-c/D bridge works and is implemented: http://www.dsource.org/projects/dstep/wiki/ObjcBridge/BridgeInternals [1]: http://sourceforge.net/projects/cocodao/ [2]: http://michelf.com/projects/d-objc/ Note, this is not a bridge. This is third one mentioned in the list above. [3]: http://stackoverflow.com/questions/5901508/calling-cocoa-apis-from-c [4]: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html - Rizo -- /Jacob Carlborg
Re: FormatSpec struct
On Friday, 13 April 2012 at 09:10:37 UTC, James Miller wrote: snip/ So I made the pull request, the documentation you need to read is here: https://github.com/Aatch/phobos/commit/cda3c079ee32d98a017f88949c10097840baa075 Hopefully it helps. -- James Miller Thanks. That did the trick. Paul
Creating a file in ~/.config (ubuntu)
I am trying to create a file in ~/.config
My code is:
[code]
import std.stdio;
void main()
{
auto f = File(~/.config/minas.txt, w);
}
[/code]
However, an exception is thrown.
std.exception.ErrnoException@std/stdio.d(288): Cannot open file
`~/.config/minas.txt' in mode `w' (No such file or directory)
./test(std.stdio.File std.stdio.File.__ctor(immutable(char)[],
const(char[]))+0x5c) [0x41a5ac]
./test(_Dmain+0x32) [0x41892a]
./test(extern (C) int rt.dmain2.main(int, char**).void
runMain()+0x17) [0x419597]
./test(extern (C) int rt.dmain2.main(int, char**).void
tryExec(scope void delegate())+0x2a) [0x418f0e]
./test(extern (C) int rt.dmain2.main(int, char**).void
runAll()+0x42) [0x4195ea]
./test(extern (C) int rt.dmain2.main(int, char**).void
tryExec(scope void delegate())+0x2a) [0x418f0e]
./test(main+0xd3) [0x418e9f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed)
[0x7ff3dcb4830d]
When trying to create it in the current directory(~/Deskto) it
works fine. I guess it has something to do with access rights.
Is there something I can do to run it with higher access
priviliges?
(I know that this might not have to do with D but I thought this
would be a good place to ask)
Thanks in advance.
Re: Creating a file in ~/.config (ubuntu)
Try using the $HOME environment variable.
Re: Creating a file in ~/.config (ubuntu)
Use std.path.expandTilde() -
http://dlang.org/phobos/std_path.html#expandTilde
On 13.4.2012 18:02, Minas wrote:
I am trying to create a file in ~/.config
My code is:
[code]
import std.stdio;
void main()
{
auto f = File(~/.config/minas.txt, w);
}
[/code]
However, an exception is thrown.
std.exception.ErrnoException@std/stdio.d(288): Cannot open file
`~/.config/minas.txt' in mode `w' (No such file or directory)
./test(std.stdio.File std.stdio.File.__ctor(immutable(char)[],
const(char[]))+0x5c) [0x41a5ac]
./test(_Dmain+0x32) [0x41892a]
./test(extern (C) int rt.dmain2.main(int, char**).void runMain()+0x17)
[0x419597]
./test(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope
void delegate())+0x2a) [0x418f0e]
./test(extern (C) int rt.dmain2.main(int, char**).void runAll()+0x42)
[0x4195ea]
./test(extern (C) int rt.dmain2.main(int, char**).void tryExec(scope
void delegate())+0x2a) [0x418f0e]
./test(main+0xd3) [0x418e9f]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xed) [0x7ff3dcb4830d]
When trying to create it in the current directory(~/Deskto) it works
fine. I guess it has something to do with access rights.
Is there something I can do to run it with higher access priviliges?
(I know that this might not have to do with D but I thought this would
be a good place to ask)
Thanks in advance.
Re: Sampling algorithms for D
On 04/13/2012 02:41 AM, Joseph Rushton Wakeling wrote:
On 13/04/12 01:44, bearophile wrote:
final size_t select(ref UniformRNG urng)
in {
assert(_recordsRemaining 0);
assert(_sampleRemaining 0);
} body {
...
}
OK. I'm confused by these asserts, because if I go beyond what is
acceptable by calling select() even after I've collected a complete
sample, no error is thrown.
This is a complicated issue that touches how in contracts are not
inherited. I think your issue is because the interface does not define
any in contracts, effectively allowing every call to select(). Please
start reading here: :)
http://d.puremagic.com/issues/show_bug.cgi?id=6856
As a general reminder, there is also the invariant() blocks, and
sometimes enforce() is more appropriate than assert.
Ali
Re: Name of files causes error. Why?
On Friday, 13 April 2012 at 04:16:52 UTC, Jesse Phillips wrote: On Wednesday, 11 April 2012 at 19:33:58 UTC, Xan wrote: Hi, With helloworld program named with score or underscore, I receive the following __annoying__ error: $ gdmd-4.6 hola-temp.d hola-temp.d: Error: module hola-temp has non-identifier characters in filename, use module declaration instead Why? Can someone fix it. It's really annoying Thanks in advance, Xan. Module names are used for import statements: import mymodule; As this is D code, it must have a valid identifier so that it parses import my-module; This could probably be special cased, but you can use these names in code auto a = my-module.foo(); Are you subtracting 'my' from 'module.foo()?' You can name you files whatever you want. Just include your module name at the top (recommended anyway) module my_module; In this case, if you module file is named my-module, then rdmd and other build tools that use your import information will be unable to locate my_module.d because that file does not exist. Thanks, Jesse, for your deep explanation. Now I understant: it's for not confusing with minus Thanks, Xan.
T : T*
I'd just like to verify that my understanding of T : T* in this template is
correct:
struct S(T : T*)
{
T t;
}
It's my understanding that it's requiring that the template argument be
implicitly convertible to a pointer to that type. However, as this
stackoverflow question shows:
http://stackoverflow.com/questions/10145779/why-this-template-parameters-
constraint-doesnt-work
it appears that the compiler is instead taking this to mean that the pointer
part of the type should be stripped from the template argument's type. Given
some of the bizarre stuff that happens with is expressions and the like, it's
not out of the question that I'm just misunderstanding what the compiler is
supposed to do with T : T* in this case (though I don't think so), so I'd like
to verify it.
- Jonathan M Davis
Re: T : T*
On Friday, April 13, 2012 14:47:45 Jonathan M Davis wrote:
I'd just like to verify that my understanding of T : T* in this template is
correct:
struct S(T : T*)
{
T t;
}
It's my understanding that it's requiring that the template argument be
implicitly convertible to a pointer to that type. However, as this
stackoverflow question shows:
http://stackoverflow.com/questions/10145779/why-this-template-parameters-
constraint-doesnt-work
it appears that the compiler is instead taking this to mean that the pointer
part of the type should be stripped from the template argument's type.
Given some of the bizarre stuff that happens with is expressions and the
like, it's not out of the question that I'm just misunderstanding what the
compiler is supposed to do with T : T* in this case (though I don't think
so), so I'd like to verify it.
Okay. Clearly, I'm misunderstanding this, because std.traits.pointerTarget
uses this idiom:
template pointerTarget(T : T*)
{
alias T pointerTarget;
}
Anyone know _why_ it works this way?
- Jonathan M Davis
Re: T : T*
On Friday, 13 April 2012 at 18:47:55 UTC, Jonathan M Davis wrote:
I'd just like to verify that my understanding of T : T* in this
template is
correct:
struct S(T : T*)
{
T t;
}
It's my understanding that it's requiring that the template
argument be
implicitly convertible to a pointer to that type. However, as
this
stackoverflow question shows:
http://stackoverflow.com/questions/10145779/why-this-template-parameters-
constraint-doesnt-work
it appears that the compiler is instead taking this to mean
that the pointer
part of the type should be stripped from the template
argument's type. Given
some of the bizarre stuff that happens with is expressions and
the like, it's
not out of the question that I'm just misunderstanding what the
compiler is
supposed to do with T : T* in this case (though I don't think
so), so I'd like
to verify it.
- Jonathan M Davis
First, the argument type must match the form T*. The T can be any
type; there is only one constraint here, the pointer head. So
obviously, the argument type must be a pointer to anything to
match T*, e.g. void*, shared(int)**, immutable(int)* etc. If it
doesn't match, the template is dropped from the overload set.
If it does match, the newly created symbol T refers to the role
of T in the parameter specialization. For arguments void*,
shared(int)** and immutable(int)*, that would be void,
shared(int)* and immutable(int) respectively.
Most forms of the `is` primary expression (IsExpression) are
dedicated to allowing the same type inspection abilities (and
some more) outside of template parameter lists, hence reading the
documentation of IsExpression is a good idea [1]. In particular,
it reveals that when the type specialization is dependent on the
symbol identifier (e.g. there's a T in the T specialization) the
resulting symbol refers to the deduced type; otherwise it is an
alias of the type specialization, which explains the two uses you
mention.
[1] http://dlang.org/expression.html#IsExpression
Re: T : T*
On Friday, April 13, 2012 21:04:07 Jakob Ovrum wrote: First, the argument type must match the form T*. The T can be any type; there is only one constraint here, the pointer head. So obviously, the argument type must be a pointer to anything to match T*, e.g. void*, shared(int)**, immutable(int)* etc. If it doesn't match, the template is dropped from the overload set. If it does match, the newly created symbol T refers to the role of T in the parameter specialization. For arguments void*, shared(int)** and immutable(int)*, that would be void, shared(int)* and immutable(int) respectively. Most forms of the `is` primary expression (IsExpression) are dedicated to allowing the same type inspection abilities (and some more) outside of template parameter lists, hence reading the documentation of IsExpression is a good idea [1]. In particular, it reveals that when the type specialization is dependent on the symbol identifier (e.g. there's a T in the T specialization) the resulting symbol refers to the deduced type; otherwise it is an alias of the type specialization, which explains the two uses you mention. [1] http://dlang.org/expression.html#IsExpression Thanks for the info. Clearly, : does not mean quite the same thing in all cases (in particular, when the same template parameter is on both sides of it). - Jonathan M Davis
Re: Creating a file in ~/.config (ubuntu)
On Friday, 13 April 2012 at 16:41:01 UTC, Bystroushaak wrote: Use std.path.expandTilde() - http://dlang.org/phobos/std_path.html#expandTilde Thank you very much! That did the trick! auto f = File(expandTilde(~/.config/test.txt,w));
Re: Sampling algorithms for D
On 13/04/12 19:49, Ali Çehreli wrote: This is a complicated issue that touches how in contracts are not inherited. I think your issue is because the interface does not define any in contracts, effectively allowing every call to select(). Please start reading here: :) You're absolutely right. I think I will kill the interface; it's not really clear that it adds anything to the whole setup. Thanks very much!
Contracts inheritance
Hai, After watching Walter's video at Lang.NEXT, I have wanted to know how contracts inheritance works. In the following code, I don't understand why foo.bar(2) works...but with the sames contracts in the foo function it doesn't work. http://paste.pocoo.org/show/3Ab5IiQk6hTiJ0jAFZWv/ Thanks
Re: Contracts inheritance
On 04/13/2012 03:07 PM, Eyyub wrote:
Hai,
After watching Walter's video at Lang.NEXT, I have wanted to know how
contracts inheritance works.
In the following code, I don't understand why foo.bar(2) works...but
with the sames contracts in the foo function it doesn't work.
http://paste.pocoo.org/show/3Ab5IiQk6hTiJ0jAFZWv/
Thanks
Here is the for convenience:
import std.stdio;
interface IFoo
{
void bar(int a)
in
{
assert(a != 1);
}
}
class Foo : IFoo
{
this()
{}
override void bar(int a)
in
{
assert(a != 2);
}
body
{
writeln(a); // 2
}
}
void foo(int a)
in
{
assert(a == 2);
assert(a 2);
}
body
{
writeln(a);
}
void main()
{
foo(2); // don't pass
Foo foo2 = new Foo;
foo2.bar(2); // pass
}
foo(2) cannot work because of the second assert in the 'in' contract.
foo2.bar(2) passes because passing a single 'in' contract is sufficient.
The 'in' contract of IFoo.bar() requires that a != 1 and it is satisfied
for 2 so bar() can be called with argument 2.
Ali
Re: Installing Modules
On Friday, 30 March 2012 at 00:20:16 UTC, TJB wrote: On Thursday, 29 March 2012 at 15:15:35 UTC, Jesse Phillips wrote: On Thursday, 29 March 2012 at 08:55:41 UTC, Johannes Pfau wrote: The command Jesse posted is missing a -L-lscid and you'll probably also need -L-L/usr/local/lib So the complete command should be: Ah, you are right, though I selected /usr/local/lib as it is already part of LD's search path. but asking for the lib is still required (-L-lscid). Brilliant. Works perfectly. Thanks for your help. You guys are awesome! TJB OK. I now can compile a simple program that imports a module from the SciD library. How do I do something a little more interesting like initialize a vector or matrix and do some linear algebra with it? Thanks so much for your help. This forum is awesome! TJB
Re: Installing Modules
On Friday, 13 April 2012 at 23:06:38 UTC, TJB wrote:
OK. I now can compile a simple program that imports a module
from the SciD library. How do I do something a little more
interesting like initialize a vector or matrix and do some
linear algebra with it?
Thanks so much for your help. This forum is awesome!
TJB
I'm not familiar with this library, you'll have to take a look
through the documentation:
https://github.com/kyllingstad/scid/wiki
I see there is a matrix module
http://www.kyllingen.net/code/scid/doc/scid_matrix.html
import scid.matrix;
void main() {
auto m = matrix(5, 10);
}
Then go modify its values, and use some linalg functions with it:
http://www.kyllingen.net/code/scid/doc/scid_linalg.html
floats default to NaN... why?
From the FaQ:
NaNs have the interesting property in that whenever a NaN is
used as an operand in a computation, the result is a NaN.
Therefore, NaNs will propagate and appear in the output
whenever a computation made use of one. This implies that a NaN
appearing in the output is an unambiguous indication of the use
of an uninitialized variable.
If 0.0 was used as the default initializer for floating point
values, its effect could easily be unnoticed in the output, and
so if the default initializer was unintended, the bug may go
unrecognized.
So basically, it's for debugging? Is that it's only reason? If so
I'm at loss as to why default is NaN. The priority should always
be in the ease-of-use IMO. Especially when it breaks a standard:
struct Foo {
int x, y;// ready for use.
float z, w; // messes things up.
float r = 0; // almost always...
}
I'm putting this in .Learn because I'm not really suggesting a
change as much as trying to learn the reasoning behind it. The
break in consistency doesn't outweigh any cost of debugging
benefit I can see. I'm not convinced there is any. Having core
numerical types always and unanimously default to zero is
understandable and consistent (and what I'm use too with C#). The
above could be written as:
struct Foo {
float z = float.nan, ...
}
if you wanted to guarantee the values are set uniquely at
construction. Which seems like a job better suited for unittests
to me anyways.
musing...
Re: Library search path on Windows?
On 4/13/2012 8:12 PM, Alex Rønne Petersen wrote: On 13-04-2012 05:25, Jesse Phillips wrote: On Friday, 13 April 2012 at 01:10:40 UTC, Alex Rønne Petersen wrote: How do I pass a library search path to DMD on Windows? I would love to know too! Only place I found was to edit sc.ini sorry. It seems that -L+path does the trick... I only found that after scavenging the wiki. Thank you, thank you, thank you.
Re: floats default to NaN... why?
On Saturday, April 14, 2012 06:00:35 F i L wrote:
From the FaQ:
NaNs have the interesting property in that whenever a NaN is
used as an operand in a computation, the result is a NaN.
Therefore, NaNs will propagate and appear in the output
whenever a computation made use of one. This implies that a NaN
appearing in the output is an unambiguous indication of the use
of an uninitialized variable.
If 0.0 was used as the default initializer for floating point
values, its effect could easily be unnoticed in the output, and
so if the default initializer was unintended, the bug may go
unrecognized.
So basically, it's for debugging? Is that it's only reason? If so
I'm at loss as to why default is NaN. The priority should always
be in the ease-of-use IMO. Especially when it breaks a standard:
struct Foo {
int x, y;// ready for use.
float z, w; // messes things up.
float r = 0; // almost always...
}
I'm putting this in .Learn because I'm not really suggesting a
change as much as trying to learn the reasoning behind it. The
break in consistency doesn't outweigh any cost of debugging
benefit I can see. I'm not convinced there is any. Having core
numerical types always and unanimously default to zero is
understandable and consistent (and what I'm use too with C#). The
above could be written as:
struct Foo {
float z = float.nan, ...
}
if you wanted to guarantee the values are set uniquely at
construction. Which seems like a job better suited for unittests
to me anyways.
musing...
Types default to the closest thing that they have to an invalid value so that
code blows up as soon as possible if you fail to initialize a variable to a
proper value and so that it fails deterministically (unlike when variables
aren't initialized and therefore have garbage values).
NaN is the invalid value for floating point types and works fantastically at
indicating that you screwed up and failed to initialize or assign your
variable a proper value. null for pointers and references works similarily
well.
If anything, the integral types and bool fail, because they don't _have_
invalid values. The closest that they have is 0 and false respectively, so
that's what they get. It's the integral types that are inconsistent, not the
floating point types.
It was never really intended that variables would be default initialized with
values that you would use. You're supposed to initialize them or assign them
to appropriate values before using them. Now, since the default values are
well-known and well-defined, you can rely on them if you actually _want_ those
values, but the whole purpose of default initialization is to make code fail
deterministically when variables aren't properly initialized - and to fail as
quickly as possible.
- Jonathan M Davis
Re: floats default to NaN... why?
Am 14.04.2012 06:00, schrieb F i L:
struct Foo {
int x, y;// ready for use.
float z, w; // messes things up.
float r = 0; // almost always...
}
how often in your code is 0 or 0.0 the real starting point?
i can't think of any situation except counters or something
where 0 is a proper start - and float 0.0 is in very very few cases a
normal start - so whats your point?
Re: floats default to NaN... why?
So it's what I thought, the only reason is based on a faulty premise, IMO. Jonathan M Davis wrote: Types default to the closest thing that they have to an invalid value so that code blows up as soon as possible if you fail to initialize a variable to a proper value and so that it fails deterministically This seems like exactly opposite behavior I'd expect from the compiler. Modern convenience means more bang per character, and initializing values to garbage is the corner case, not the usual case. (unlike when variables aren't initialized and therefore have garbage values). This is the faulty premise I see. Garbage values are a C/C++ thing. They must be forced in D, eg, float x = void. I would argue that because values *should* have implicit, non-garbage, default values that those default values should be the most commonly used/expected lowest value. Especially since ints _must_ be 0 (though I hear this is changing in Arm64). NaN is the invalid value for floating point types and works fantastically at indicating that you screwed up and failed to initialize or assign your variable a proper value. null for pointers and references works similarily well. Not exactly. NaNs don't cause Segfaults or Undefined behavior, they just make the math go haywire. It's like it was designed to be inconvenient. The argument looks like this to me: We default values so there's no garbage-value bugs.. but the default is something that will cause a bug.. because values should be explicitly defaulted so they're not unexpected values (garbage).. even though we could default them to an expected value since we're doing it to begin with It sounds like circular reasoning. It was never really intended that variables would be default initialized with values that you would use. why exactly? again, this is a faulty premise IMO. You're supposed to initialize them or assign them to appropriate values before using them. sure, but if they always default to _usable_ constants no expectations are lost and no bugs are created. Now, since the default values are well-known and well-defined, you can rely on them if you actually _want_ those values, yes, and how often do you _want_ a NaN in the mix? You can rely on usable values just as much. Even more so since Ints and Floats would be consistent. but the whole purpose of default initialization is to make code fail deterministically when variables aren't properly initialized - and to fail as quickly as possible. that only makes sense in C/C++ where value are implicitly garbage and mess things up. Again, this is only my perspective. I would love to hear convincing arguments to how great D currently defaulting to NaN is, and how much headache (I never knew I had) it will save me... but I just don't see it. In fact I'm now more convinced of the opposite. Never in C# have I ran into issues with unexpected values from default initializers. Most important values are set at runtime through object constructors; not at declaration.
Re: floats default to NaN... why?
On Saturday, 14 April 2012 at 05:19:38 UTC, dennis luehring wrote:
Am 14.04.2012 06:00, schrieb F i L:
struct Foo {
int x, y;// ready for use.
float z, w; // messes things up.
float r = 0; // almost always...
}
how often in your code is 0 or 0.0 the real starting point?
i can't think of any situation except counters or something
where 0 is a proper start - and float 0.0 is in very very few
cases a normal start - so whats your point?
Every place that a structure property is designed to be mutated
externally. Almost all Math structures, for instance.
Defaults are to combat garbage values, but debugging cases where
values where accidentally unset (most likely missed during
construction) seems like a better job for a unittest.
Re: floats default to NaN... why?
On Saturday, April 14, 2012 07:41:33 F i L wrote: You're supposed to initialize them or assign them to appropriate values before using them. sure, but if they always default to _usable_ constants no expectations are lost and no bugs are created. No. You always have a bug if you don't initialize a variable to the value that it's supposed to be. It doesn't matter whether it's 0, NaN, 527.1209823, or whatever. All having a default value that you're more likely to use means is that you're less likely to have to explicitly initialize the variable. It has to be initialized to the correct value regardless. And if you're in the habit of always initializing variables and never relying on the defaults if you can help it, then the cases where variables weren't initialized to what they were supposed to be stand out more. but the whole purpose of default initialization is to make code fail deterministically when variables aren't properly initialized - and to fail as quickly as possible. that only makes sense in C/C++ where value are implicitly garbage and mess things up. ??? D was designed with an eye to improve on C/C++. In C/C++, variables aren't guaranteed to be initialized, so if you forget to initialize them, you get garbage, which is not only buggy, it results in non-deterministic behavior. It's always a bug to not initialize a variable. D's approach is to say that it's _still_ a bug to not initialize a variable, since you almost always need to initialize a variable to something _other_ than a default. But rather than leaving them as garbage, D makes it so that variables are default-initialized, making the buggy behavior deterministic. And since not initializing a variable is almost always a bug, default values which were the closest to error values for each type were chosen. You can disagree with the logic, but there it is. I don't see how it's an issue, since you almost always need to initialize variables to something other than the default, and so leaving them as the default is almost always a bug. The only point of dispute that I see in general is whether it's better to rely on the default or to still explicitly initialize it when you actually want the default. Relying on the default works, but by always explicitly initializing variables, those which are supposed to be initialized to something other than the defaults but aren't are then much more obvious. Regardless, the _entire_ reason for default-initialization in D revolves around making buggy initializations deterministic and more detectable. - Jonathan M Davis
