Re: how to detect ctfe
__ctfe can be used for this purpose: The __ctfe boolean pseudo-variable, which evaluates to true at compile time, but false at run time, can be used to provide an alternative execution path to avoid operations which are forbidden at compile time. Every usage of __ctfe is evaluated before code generation and therefore has no run-time cost, even if no optimizer is used. ( http://dlang.org/function.html )
Re: how to detect ctfe
Vlad Levenfeld: Is there any way that I can detect whether or not a function is being evaluated at compile time? Specifically I want to switch between to use/not to use memoize!func without having to figure out when its CTFE-able and calling it with different syntax. Calling it with a different syntax seems not easy to do. But there is a run-time variable __ctfe that can be used to disable/enable the memoization. Bye, bearophile
Re: enums
On Sat, May 31, 2014 at 10:14 PM, bearophile via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: In contrast to those two examples where immutable can be used at compile time, what are some other cases where it is necessary to use enum instead of immutable? By default use enum if you define a compile-time-known value (...) Now that we have immutable's that can be used inside templates, why use an enum? Because it's 'inlined' in the code? (I know the reason not to use it for an array or associative array, I experimented that fully in my own code. Ouch!)
Re: how to detect ctfe
But let's keep in mind it's a *runtime* value. You cannot use it at
compile-time as a boolean for a 'static if'.
So:
if (__ctfe) // yes
{
// compile-time path
}
else
{
// runtime path
}
But not:
static if (__ctfe) // no
{
// compile-time path, including new global declarations
}
else
{
// runtime path
}
Why would you want to do that? I needed an associative array for my
code. AA don't work that well at compile-time. So I wanted to replace
them with my own Associative struct, maybe less efficient/generic, but
that works at CT. The idea was:
static if (__ctfe)
alias Type = Associative!(string, string);
else
alias Type = string[string];
// then, use Type, whatever the path.
Re: Casting Structs
On Sun, Jun 1, 2014 at 12:34 AM, Timon Gehr via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: This behaviour is independent of templates. Struct values of the same size can be reinterpret-cast to each other this way even if their types are completely unrelated. Do you know if this is by design?
Re: enums
On Saturday, 31 May 2014 at 22:45:32 UTC, bearophile wrote: Chris Nicholson-Sauls: Good... I was starting to fear I was the only one. In general you can't fix the names in a language because you always find someone that likes the ones present :) I think enum is a bad name for the purpose of defining manifest constants, but I don't think this will change. Bye, bearophile In a perfect world, sure, we'd have a different name for it; I'm not saying I love it, just that it makes sense in my head. I've sometimes thought 'alias' could have worked as well, especially now with the a=b syntax. alias DEFAULT_PORT = 11020; But, then we exchange one set of brow raisers for another set. In the absence of #define, there probably is no achievable ideal. :)
Interfacing to const T or const T* C++ code
So I was mucking about with calling C++ from D yesterday and was
pleasantly surprised that this worked:
D:
struct Foo { int i; int j; }
extern(C++) void useFoo(ref const(Foo) foo);
C++:
struct Foo { int i; int j; };
void useFoo(const Foo foo) { ... }
In fact, omitting const on either side causes a link error, and
the same for using a pointer instead of a reference on one of the
sides. All good. But this doesn't work:
D:
extern(C++) interface DClass { int getIndex() const; }
extern(C++) void useObj(in DClass dclass); //I also tried
const(DClass)
C++:
struct DClass { virtual int getIndex() const = 0; }
void useObj(const DClass* dclass); //DClass* works though!
I can make `DClass` `const` or `in` in D as much as I want, but
it fails to link if I add const on the C++ side. Is there a
reason why it works for structs (as it should) but not classes?
It'd be nice to be able to pass classes in by const T. Or even
const T*!
Atila
Re: Interfacing to const T or const T* C++ code
Atila Neves:
D:
struct Foo { int i; int j; }
extern(C++) void useFoo(ref const(Foo) foo);
C++:
struct Foo { int i; int j; };
void useFoo(const Foo foo) { ... }
This doesn't look very safe because D const is transitive, unlike
the C++ const. So in the C++ code you can mutate inner data
inside foo and the D code will assume such data is not changed.
Bye,
bearophile
text() vs. format() for formatting assert/exception messages
Hello all, What's the current state of preference (if any) for using std.conv.text vs. std.string.format (or others?) when formatting error messages for assert/enforce/exceptions? I seem to recall a deprecation message pushing the use of std.string.format at some point in the past, but text() now seems to pass without comment. Thanks best wishes, -- Joe
Re: Different random shuffles generated when compiled with gdc than with dmd
On Saturday, 31 May 2014 at 21:22:48 UTC, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: On 31/05/14 22:37, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: On 30/05/14 22:45, monarch_dodra via Digitalmars-d-learn wrote: Didn't you make changes to how and when the global PRNG is popped and accessed in randomShuffle? I figured it *could* be an explanation. I think it's more likely that the culprit is either your set of patches to the Mersenne Twister, or the patches made to uniform() (which is called by partialShuffle). I'll look more deeply into this. It's due to the the updated uniform() provided in this pull request: https://github.com/D-Programming-Language/phobos/commit/fc48d56284f19bf171780554b63b4ae83808b894 I second the thought that reproducibility across different versions is an important feature of any random generation library. Sadly, I didn't use a language yet which supported such a flavor of reproducibility for a significant period of time in its default random library, so I have to use my own randomness routines when it matters. I've reported my concern [1] at the moment of breakage, but apparently it didn't convince people. Perhaps I should make a more significant effort next time (like a pull request) for the things that matter to me. Well, now I know it does matter for others, at least. In short, if uniform() has to be tweaked, the sooner it happens, the better. Alternatively, the library design could allow different uniform() implementations to be plugged in, and provide legacy implementations along with the current (default) one. In that case, all one has to do to reproduce the old behavior is to plug the appropriate one in. [1] http://forum.dlang.org/thread/vgmdoyyqhcqurpmob...@forum.dlang.org#post-gjuprkxzmcbdixtbucea:40forum.dlang.org
floating point conversion
import std.conv;
void main()
{
float a = 1.23f;
double b = to!float(1.23);
assert (a == b); // ???
}
Should the assert fail or not ? (Please reply without trying first).
If your reply is yes, should
assert (a == to!float(1.23))
fail or not ?
I'm bringing this up, because dmd and gdc (x86) don't agree on this.
--
mk
Re: Casting Structs
On 06/01/2014 09:59 AM, Philippe Sigaud via Digitalmars-d-learn wrote: On Sun, Jun 1, 2014 at 12:34 AM, Timon Gehr via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: This behaviour is independent of templates. Struct values of the same size can be reinterpret-cast to each other this way even if their types are completely unrelated. Do you know if this is by design? Well, it had to be explicitly implemented. The behaviour contradicts the documentation at http://dlang.org/expression#CastExpression though.
Re: floating point conversion
Martin Krejcirik: float a = 1.23f; double b = to!float(1.23); assert (a == b); // ??? } Should the assert fail or not ? (Please reply without trying first). It's a bad question. Generally to compare floating point values for equality use std.math.feqrel. Bye, bearophile
Re: floating point conversion
On 1.6.2014 14:45, bearophile wrote: It's a bad question. Generally to compare floating point values for equality use std.math.feqrel. So it's just a coincidence, that GDC, LDC x86 and also DMD x86_64 doesn't fail ? And this bug https://issues.dlang.org/show_bug.cgi?id=12831 should be marked invalid ? -- mk
Re: floating point conversion
So it's just a coincidence, that GDC, LDC x86 and also DMD x86_64 doesn't fail ? (Equality) Compareision of float/float or float/double are machine dependent (depends even on x86 on the generated code (SSE/SSE2/AVX/AVX2), rounding settings, maybe event the cpu vendor etc.). On other platforms (ARM, etc) it could be even more weird. The General rule is not to compare floats for equality, (is 0.0==-0.0, etc.). Use a epsilon based comparision scheme instead or a wrapper around it.
Re: Different random shuffles generated when compiled with gdc than with dmd
Thank you for hunting down the difference, in my case it's not a deal breaking problem. I can just specify the compiler and language version, then the results become reproducible. And I'm sure I'll appreciate the performance boost! On Sunday, 1 June 2014 at 12:11:22 UTC, Ivan Kazmenko wrote: On Saturday, 31 May 2014 at 21:22:48 UTC, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: On 31/05/14 22:37, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: On 30/05/14 22:45, monarch_dodra via Digitalmars-d-learn wrote: Didn't you make changes to how and when the global PRNG is popped and accessed in randomShuffle? I figured it *could* be an explanation. I think it's more likely that the culprit is either your set of patches to the Mersenne Twister, or the patches made to uniform() (which is called by partialShuffle). I'll look more deeply into this. It's due to the the updated uniform() provided in this pull request: https://github.com/D-Programming-Language/phobos/commit/fc48d56284f19bf171780554b63b4ae83808b894 I second the thought that reproducibility across different versions is an important feature of any random generation library. Sadly, I didn't use a language yet which supported such a flavor of reproducibility for a significant period of time in its default random library, so I have to use my own randomness routines when it matters. I've reported my concern [1] at the moment of breakage, but apparently it didn't convince people. Perhaps I should make a more significant effort next time (like a pull request) for the things that matter to me. Well, now I know it does matter for others, at least. In short, if uniform() has to be tweaked, the sooner it happens, the better. Alternatively, the library design could allow different uniform() implementations to be plugged in, and provide legacy implementations along with the current (default) one. In that case, all one has to do to reproduce the old behavior is to plug the appropriate one in. [1] http://forum.dlang.org/thread/vgmdoyyqhcqurpmob...@forum.dlang.org#post-gjuprkxzmcbdixtbucea:40forum.dlang.org
How to convert int type to string int ?
Hi,
All is in the title.
I need this to do a tupleof enhanced, that mean:
- .tupleof need an instance me i want to do this on type
diretcly
- .tupleof do not bind to member name i need this
for this i strat to this code:
import std.stdio;
import std.typecons;
import std.conv;
struct Coord
{
int x;
int y;
int z;
}
template toTuple(T){
static string maker(){
string statement = alias Tuple!(;
foreach(const memberName; __traits(allMembers, T)){
statement ~= to!string(typeof(__traits(getMember, T,
memberName))) ~ ,\ ~ memberName ~ \, ;
}
statement = statement[O..$-1] ~ ) t; ; // $-1 to remove
extra comma
return statement;
}
enum toTuple = mixin( maker() );
}
but that fail on typeof(__traits(getMember, T, memberName) becase
that return a type and not a string.
Thaks for your help
Re: How to convert int type to string int ?
On Sunday, 1 June 2014 at 13:34:20 UTC, bioinfornatics wrote:
Hi,
All is in the title.
I need this to do a tupleof enhanced, that mean:
- .tupleof need an instance me i want to do this on type
diretcly
- .tupleof do not bind to member name i need this
for this i strat to this code:
import std.stdio;
import std.typecons;
import std.conv;
struct Coord
{
int x;
int y;
int z;
}
template toTuple(T){
static string maker(){
string statement = alias Tuple!(;
foreach(const memberName; __traits(allMembers, T)){
statement ~= to!string(typeof(__traits(getMember,
T,
memberName))) ~ ,\ ~ memberName ~ \, ;
}
statement = statement[O..$-1] ~ ) t; ; // $-1 to
remove
extra comma
return statement;
}
enum toTuple = mixin( maker() );
}
but that fail on typeof(__traits(getMember, T, memberName)
becase
that return a type and not a string.
Thaks for your help
I find this: typeid(typeof(__traits(getMember, T,
memberName))).toString
but that do not works at compile time.
Error: static variable typeid(int) cannot be read at compile time
Re: How to convert int type to string int ?
Maybe http://dlang.org/property.html#stringof helps.
Re: How to convert int type to string int ?
On Sunday, 1 June 2014 at 13:52:27 UTC, Tobias Pankrath wrote: Maybe http://dlang.org/property.html#stringof helps. yes that help a lot thanks
Re: How to convert int type to string int ?
I bam close to be done
import std.stdio;
import std.typecons;
import std.conv;
struct Coord
{
int x;
int y;
int z;
}
template toTuple(T){
static string maker(){
string statement = alias Tuple!(;
foreach(const memberName; __traits(allMembers, T)){
statement ~= typeof(__traits(getMember, T,
memberName)).stringof ~ ,\ ~ memberName ~ \, ;
}
statement = statement[0..$-2] ~ ) toTuple; ; // $-1 to
remove extra comma
return statement;
}
pragma( msg, maker() );
mixin( maker() );
}
void main()
{
//auto a = c.tupleof;
auto a = toTuple!Coord;
}
$ ldc2 -w -oftestTupleof testTupleof.d
alias Tuple!(int,x, int,y, int,z) toTuple;
testTupleof.d(29): Error: type Tuple!(int, x, int, y, int,
z) has no value
Re: How to convert int type to string int ?
On Sunday, 1 June 2014 at 13:58:03 UTC, bioinfornatics wrote:
On Sunday, 1 June 2014 at 13:52:27 UTC, Tobias Pankrath wrote:
Maybe http://dlang.org/property.html#stringof helps.
yes that help a lot thanks
End of spam ( joke ^^)
I found it :-)
import std.stdio;
import std.typecons;
import std.conv;
struct Coord
{
int x;
int y;
int z;
}
template toTuple(T){
static string maker(){
string statement = alias toTuple = Tuple!(;
foreach(const memberName; __traits(allMembers, T)){
statement ~= typeof(__traits(getMember, T,
memberName)).stringof ~ ,\ ~ memberName ~ \, ;
}
statement = statement[0..$-2] ~ ) ; ; // $-1 to remove
extra comma
return statement;
}
pragma( msg, maker() );
mixin( maker() );
}
void main()
{
Coord c;
alias A = toTuple!Coord;
A a;
a[0] = 1;
a.x = 1;
}
Re: Different random shuffles generated when compiled with gdc than with dmd
On 01/06/14 14:11, Ivan Kazmenko via Digitalmars-d-learn wrote: I second the thought that reproducibility across different versions is an important feature of any random generation library. Sadly, I didn't use a language yet which supported such a flavor of reproducibility for a significant period of time in its default random library, so I have to use my own randomness routines when it matters. I've reported my concern [1] at the moment of breakage, but apparently it didn't convince people. Perhaps I should make a more significant effort next time (like a pull request) for the things that matter to me. Well, now I know it does matter for others, at least. Yes, there probably should be a high bar for changes that break reproducibility in this way (although there certainly shouldn't be a ban: we shouldn't artificially constrain ourselves to avoid significant improvements to the module). I missed the debate at the time, but actually, I'm slightly more concerned over the remark in that discussion that the new uniform was ported from java.util.Random. Isn't OpenJDK GPL-licensed ... ?
Re: Is there any way to differentiate between a type and an alias?
On Tuesday, 27 May 2014 at 18:05:24 UTC, Steven Schveighoffer wrote: I get it. I don't necessarily agree with that, but it's not my library :) I think it would be difficult to achieve without changing the actual function definition. Perhaps you could wrap the functions with your own, and use your own enum type. The enum as I defined it above, should implicitly cast to uint. -Steve Apologies for the late reply. Manually wrapping seems a bit too heavy handed. On the other hand I have similar issues with the other Derelict libraries. For example, the GLFW_KEY_XXX enums. I'd much rather store stringified key bindings in a configuration file than raw key codes. With a bit of effort I should be able to build something that translates all these C like libraries to something more D like...
Re: floating point conversion
On Sunday, 1 June 2014 at 12:45:26 UTC, bearophile wrote: It's a bad question. Actually, Martin's question is a good one. Initializing a variable of type float via a literal or as conversion from string should be the same, exacly, always. Casting a float to double should be deterministic as well. Famous
Re: floating point conversion
float a = 1.234f; float b = to!float(1.234); assert (a == b); assert (a == to!float(1.234)); // is allowed to fail due to constant folding
Re: floating point conversion
On 1.6.2014 16:42, Famous wrote:
from string should be the same, exacly, always. Casting a float to
double should be deterministic as well.
void main()
{
float a = 1.234f;
double b = 1.234;
assert (a == cast(float) b); // fails in DMD x86, works in GDC, LDC
}
Maybe enhancement request ?
--
mk
Re: floating point conversion
On Sunday, 1 June 2014 at 15:31:53 UTC, Martin Krejcirik wrote:
On 1.6.2014 16:42, Famous wrote:
from string should be the same, exacly, always. Casting a
float to
double should be deterministic as well.
void main()
{
float a = 1.234f;
double b = 1.234;
assert (a == cast(float) b); // fails in DMD x86, works in
GDC, LDC
}
Maybe enhancement request ?
This is different. The decimal 1.234 cannot be exacly represented
as radix-2 floating-point number. In your example above, a and b
are not equal. They are both approximations to 1.234 but the
value of b is closer. Then casting b to float might or might not
result in the same value as that of a. This is what bearophile
and Qox referred to.
Since every float can be exacly converted to double the following
situation is different:
float a = 1.234f;
double b = a;
assert(a == b); // always succeeds in a sane environment
When taking into account constant folding, well, decide on your
own, whether the following behaviour is sane:
void main()
{
const float a = 1.234f;
float b = 1.234f;
assert(a == 1.234); // ok
assert(b == 1.234); // fails
}
DMD fail when using both reflection and UDA
DMD (dmdfe 2.066) fail when i use UDA which store a delegate
code below works if i remove @section UDA otheswise it give this
error:
dmd: statement.c:714: ErrorStatement::ErrorStatement(): Assertion
`global.gaggedErrors || global.errors' failed.
is a bug ?
--- CODE also on dpaste http://dpaste.dzfl.pl/3a3d660bd3bc
import std.stdio;
import std.typecons : Tuple;
import std.typetuple : Filter;
struct attribute{}
@attribute
struct section( alias start, alias end)
{
alias checkStart = start;
alias checkEnd = end;
}
template hasSection(T)
{
static bool helper()
{
foreach(memberName; __traits(allMembers, T))
{
foreach(attr; __traits(getAttributes,
__traits(getMember, T, memberName)))
{
static if(is(attr == Section))
return true;
}
}
return false;
}
enum hasSection = helper();
}
struct Data{
@section!( ( words ) = words[0] == '@' , (
words ) = words[0] == '\n' )
string a;
@section!( ( words ) = words[0] 63 words[0] 115 , (
words ) = words[0] == '\n' )
string b;
@section!( ( words ) = words[0] == '+' , (
words ) = words[0] == '\n' )
string c;
}
template toTuple(T){
static string maker(){
string statement = alias toTuple = Tuple!(;
foreach(const memberName; __traits(allMembers, T)){
//~ mixin(`alias f = Filter!(hasSection,
__traits(getAttributes, T.` ~ memberName ~ `));`);
statement ~= typeof(__traits(getMember, T,
memberName)).stringof ~ ,\ ~ memberName ~ \, ;
}
statement = statement[0..$-2] ~ ) ; ; // $-2 to remove
extra comma
return statement;
}
mixin( maker() );
}
void main()
{
alias A = toTuple!Data;
A a;
a[0] = 1;
a.x = 1;
}
Re: DMD fail when using both reflection and UDA
On Sunday, 1 June 2014 at 16:02:47 UTC, bioinfornatics wrote:
DMD (dmdfe 2.066) fail when i use UDA which store a delegate
code below works if i remove @section UDA otheswise it give this
error:
dmd: statement.c:714: ErrorStatement::ErrorStatement():
Assertion
`global.gaggedErrors || global.errors' failed.
is a bug ?
--- CODE also on dpaste http://dpaste.dzfl.pl/3a3d660bd3bc
import std.stdio;
import std.typecons : Tuple;
import std.typetuple : Filter;
struct attribute{}
@attribute
struct section( alias start, alias end)
{
alias checkStart = start;
alias checkEnd = end;
}
template hasSection(T)
{
static bool helper()
{
foreach(memberName; __traits(allMembers, T))
{
foreach(attr; __traits(getAttributes,
__traits(getMember, T, memberName)))
{
static if(is(attr == Section))
return true;
}
}
return false;
}
enum hasSection = helper();
}
struct Data{
@section!( ( words ) = words[0] == '@' ,
(
words ) = words[0] == '\n' )
string a;
@section!( ( words ) = words[0] 63 words[0] 115 ,
(
words ) = words[0] == '\n' )
string b;
@section!( ( words ) = words[0] == '+' ,
(
words ) = words[0] == '\n' )
string c;
}
template toTuple(T){
static string maker(){
string statement = alias toTuple = Tuple!(;
foreach(const memberName; __traits(allMembers, T)){
//~ mixin(`alias f = Filter!(hasSection,
__traits(getAttributes, T.` ~ memberName ~ `));`);
statement ~= typeof(__traits(getMember, T,
memberName)).stringof ~ ,\ ~ memberName ~ \, ;
}
statement = statement[0..$-2] ~ ) ; ; // $-2 to
remove
extra comma
return statement;
}
mixin( maker() );
}
void main()
{
alias A = toTuple!Data;
A a;
a[0] = 1;
a.x = 1;
}
ok it seem problem from my code a type string i need to
understand why
Re: DMD fail when using both reflection and UDA
stupid me bug was at the end a[0] = 1; become a[0] = 1; but error error was so stnange to me i though that was a bug
Re: DMD fail when using both reflection and UDA
In any case, it's an internal compiler error, so it's a bug. Users should never see ICEs. Could you please report it, with the entire error message?
Re: floating point conversion
The General rule is not to compare floats for equality, (is 0.0==-0.0, etc.). Use a epsilon based comparision scheme instead or a wrapper around it. That's not exactly true. You cannot (and should not) compare floating points for equality, and use epsilon-based comparison instead, only in one certain case: when one of the arguments if the result of computation, during which a computational error might accumulate. If you have two exact or constant values, comparing them directly is perfectly fine. :-) Nowadays floating-point hardware support is not that buggy.
rawRead linker error
Hello all, I'm trying to read from /dev/random using File.rawRead as follows: auto f = File(/dev/urandom, r); ulong b; f.rawRead((b)[0 .. 1]); writeln(b); This generates a linker error: rawread.o: In function `_D3std5stdio4File14__T7rawReadTmZ7rawReadMFAmZAm': rawread.d:(.text._D3std5stdio4File14__T7rawReadTmZ7rawReadMFAmZAm+0xba): undefined reference to `_D3std9exception88__T12errnoEnforceTbVAyaa27_2f6f70742f646d642f696d706f72742f7374642f737464696f2e64Vmi715Z12errnoEnforceFNfbLAyaZb' collect2: error: ld returned 1 exit status --- errorlevel 1 Can anyone advise what's the problem here? Passing a regular array as the buffer doesn't cause any issues, but I can't see what's wrong with passing a slice based around pointer-to-ulong as in the above example. This certainly _used_ to work, so I take it it's down to a recent change to rawRead ... ? Thanks and best wishes, -- Joe
Re: rawRead linker error
On 01/06/14 19:04, Joseph Rushton Wakeling via Digitalmars-d-learn wrote: Passing a regular array as the buffer doesn't cause any issues In fact it seems to be a problem to pass any array other than a ubyte array; for example a ulong[] array is problematic. The problem vanishes if the -inline option is not used.
Re: floating point conversion
I have compiled some cases at http://dpaste.dzfl.pl/5611b8bce8e3 This implies that floating-point constants do not have fixed but minimum precision. Particularly, the literal 1.23 describes a floating-point value with either double or real precision depending on what it is compared to. This seems to comply with http://dlang.org/float.html
Test if member is static variable
Hi ! http://dpaste.dzfl.pl/e21082716396 Is there a way to optimize static if(is(typeof(__traits(getMember, T, name).offsetof)) == false is(FunctionTypeOf!(__traits(getMember, T, name)) == function) == false __traits(compiles, __traits(getMember, T, name))) ? I think there shoult be __traits(isStaticVariable), but there's not. Thanks !
Re: floating point conversion
On 1.6.2014 18:02, Famous wrote: This is different. The decimal 1.234 cannot be exacly represented as radix-2 floating-point number. In your example above, a and b are not equal. They are both approximations to 1.234 but the value of b is Still feels iffy to me. If you add: printf(%.70f\n%.70f\n, a, cast(float) b); you can see that gcc in C and gdc in D both convert value of b to float resulting in equality. Dmd doesn't, it just ignore the cast. -- mk
support for unicode in identifiers
I was pretty happy to find that I could use mu and sigma when writing statistical routines, but I've found that for more obscure non-ascii characters the support is hit or miss. For example, none of the subscripts are valid characters, but I can use superscript n as well as dot-notation for derivatives. I'm using dmd 2.065. What's the story behind the scenes? Is there a rationale behind the supported/unsupported or is it happenstance? Is there anywhere I can find a list of supported characters?
How to detect a lambda expression get it is signature
Hi i am looking how to perform this action with traits. Below
some code to show what it fail
Regards
CODE
import std.traits : isDelegate, isSomeFunction,
MemberFunctionsTuple, ParameterIdentifierTuple;
struct section( alias start, alias end )
{
alias checkStart = start;
alias checkEnd = end;
}
void main()
{
alias tmp = bool delegate( string ); // what i would like to
get
alias s = section!( (word) = word ==a , (word) = word ==
b );
pragma( msg, isSomeFunction!(s.checkStart) ); //
false
pragma( msg, isDelegate!(s.checkStart) ); //
false
pragma( msg, __traits(identifier, s.checkStart) ); //
__lambda1
pragma( msg, ParameterIdentifierTuple!(s.checkStart) ); //
error
pragma( msg, MemberFunctionsTuple!( s.checkStart ) ); //
error
}
Re: DMD fail when using both reflection and UDA
On Sunday, 1 June 2014 at 16:18:45 UTC, Philippe Sigaud via Digitalmars-d-learn wrote: In any case, it's an internal compiler error, so it's a bug. Users should never see ICEs. Could you please report it, with the entire error message? Ok thanks is don at https://issues.dlang.org/show_bug.cgi?id=12838
Re: support for unicode in identifiers
On Sunday, 1 June 2014 at 22:26:42 UTC, Vlad Levenfeld wrote: I was pretty happy to find that I could use mu and sigma when writing statistical routines, but I've found that for more obscure non-ascii characters the support is hit or miss. For example, none of the subscripts are valid characters, but I can use superscript n as well as dot-notation for derivatives. I'm using dmd 2.065. What's the story behind the scenes? Is there a rationale behind the supported/unsupported or is it happenstance? Is there anywhere I can find a list of supported characters? The allowed characters are those defined as universal in ISO/IEC 9899 (the C standard). It's a pretty long list, but almost only alphas; I'm actually surprised you got superscripts and some other things to work. As I understand it, the intention was a) be like C99, and b) allow things like using stærð rather than staerdh. I'm not sure usage like yours was even thought about, although I'd concede that it seems reasonable.
Re: support for unicode in identifiers
With unicode support (especially with UCFS) I can really code more in the way I think. I never gave it much thought until I worked with D, but now that I have I feel it is a bit weird to work with epsilons and deltas on paper and eps and del or something on the screen. And what's a more descriptive variable name than the symbol used for it in the canonical representations? So, this may be a very naive question but I wonder, since dmd is open source, is there somewhere that the list of supported symbols can be extended? (hopefully something trivial to change, like a big array literal tucked away somewhere) I'm looking through the files labeled 'lexer' and 'utf' and things like that on github currently, but nothing's jumped out at me yet.
Re: support for unicode in identifiers
Ah!, found it in utf.h as ALPHA_TABLE
Multi-file project problem with Visual D
I've created a small Windows based program using a win32 library
I found online. That part is working just fine.
I've also created a second file (called util.d) and within it
defined a class called MyData (with a member function called
Read()).
Within my main program I instantiate and try to call the Read()
method. No errors are generated but nothing gets called. Right
now the Read() method just does a throw so I know something is
going on.
What am I missing here? I would think the compiler would
generate an error if something was missing.
winmain.d:
-
extern(Windows)
LRESULT WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM
lParam)
{
switch (message)
{
case WM_CREATE:
f.Read() ;
return 0 ;
/* ... */
} // WndProc
util.d:
--
class MyData {
public:
void Read() {
throw new Exception(No!, __FILE__, __LINE__) ;
} // void Read()
} // class Data
Re: Multi-file project problem with Visual D
On Monday, 2 June 2014 at 01:01:22 UTC, Mike wrote:
I've created a small Windows based program using a win32
library I found online. That part is working just fine.
I've also created a second file (called util.d) and within it
defined a class called MyData (with a member function called
Read()).
Within my main program I instantiate and try to call the Read()
method. No errors are generated but nothing gets called.
Right now the Read() method just does a throw so I know
something is going on.
What am I missing here? I would think the compiler would
generate an error if something was missing.
winmain.d:
-
extern(Windows)
LRESULT WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM
lParam)
{
switch (message)
{
case WM_CREATE:
f.Read() ;
return 0 ;
/* ... */
} // WndProc
util.d:
--
class MyData {
public:
void Read() {
throw new Exception(No!, __FILE__, __LINE__) ;
} // void Read()
} // class Data
Doing more testing and debugging found that the value of the
instance is 0, which leads me to believe something is happening
with the instantiation. Back to the books I suppose.
Re: Indicating incompatible modules
On Sat, 31 May 2014 18:26:53 +0200 Joseph Rushton Wakeling via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: Hello all, Is there a straightforward way to indicate that two modules should not be used together in the same program? Preferably one that does not require editing both of the modules? The application I have in mind is when one is making available an experimental module which is planned to replace one that already exists; it's useful for the experimental module to be able to say, Hey, use me _or_ the standard module, but not both of us. Any thoughts ... ? I wouldn't really worry about it. I'd just document the new module as a replacement for the other and that they're not intended to work together. I don't see much point in trying to get the compiler to complain about code that uses both. - Jonathan M Davis
Re: Forward reference to nested function not allowed?
On Sat, 31 May 2014 16:18:33 +
DLearner via Digitalmars-d-learn digitalmars-d-learn@puremagic.com
wrote:
Hi,
import std.stdio;
void main() {
writefln(Entered);
sub1();
sub1();
sub1();
writefln(Returning);
void sub1() {
static int i2 = 6;
i2 = i2 + 1;
writefln(%s,i2);
};
}
does not compile, but
import std.stdio;
void main() {
void sub1() {
static int i2 = 6;
i2 = i2 + 1;
writefln(%s,i2);
};
writefln(Entered);
sub1();
sub1();
sub1();
writefln(Returning);
}
compiles and runs as expected.
Is this intended?
Currently, you cannot forward reference a nested function. Kenji was looking
into it recently, so maybe we'll be able to at some point in the future, but
right now, we definitely can't. But even if we can in the future, I'd expect
that you'd have to declare a prototype for the function to be able to use it
before it's declared. In general though, I think that the only reason that it
would really be useful would be to have two nested functions refer to each
other, since otherwise, you just declare the nested function earlier in the
function.
- Jonathan M Davis
Re: Are tests interruptible/concurrent? Is use of a (thread local) global safe in tests?
On Fri, 30 May 2014 20:13:19 + Mark Isaacson via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: I'm having fun running some unittests. I set up a simple homemade mock of std.net.curl's functions that essentially just consists of a global queue that I can add strings to and get back in a predictable order when calling std.net.curl.get/post/etc. I use this mock in a couple of different modules for unit testing, namely the module I have the mock in and one other one. When I run my unit tests, it seems to enqueue all of the responses from both of my unit tests (from different modules) before finishing those tests and removing things from the global queue. This is problematic in that I cannot anticipate the state of the global queue for my tests. Does this sound more like a bug or a feature. My understanding is that, at least for now, tests are not run concurrently on the latest official dmd release; since my queue is not qualified with shared, things should be thread local anyway. TLDR: Executation of tests A and B is as follows: A pushes to global queue B pushes to global queue B pops on global queue -- program crashes Expected order: A pushes to global queue A pops from global queue B pushes to global queue B pops from global queue Or switch the order in which A and B execute, doesn't really matter. Well, the behavior you're seeing would make sense if you're using static destructors for the popping part, since they aren't going to be run until the program is shut down, but if you're using the unittest blocks to do the popping, that's definitely a bit odd. I would have expected each module's unit tests to be run sequentially. Certainly, within a module, the tests are currently run sequentially. However, there has been recent discussion of changing it so that unittest blocks will be run in parallel (at lest by default), so in the future, they may very well run in parallel (probably requiring an attribute of some kind to make them run sequentially). It's generally considered good practice to make it so that your unittest blocks don't rely on each other and that they don't change the global state, in which case, it doesn't matter what order they're in (though that still allows for setting stuff up in static constructors and shutting it down in static destructors so long as that state doesn't change after a unittest block is run). - Jonathan M Davis
Re: floating point conversion
On Sun, 01 Jun 2014 14:42:34 + Famous via Digitalmars-d-learn digitalmars-d-learn@puremagic.com wrote: On Sunday, 1 June 2014 at 12:45:26 UTC, bearophile wrote: It's a bad question. Actually, Martin's question is a good one. Initializing a variable of type float via a literal or as conversion from string should be the same, exacly, always. Casting a float to double should be deterministic as well. Not necessarily, particularly because any floating point operations done at compile time are generally done at much higher precision than those done at runtime. So, it's pretty trivial for very similar floating point operations to end up with slightly different results. In general, expecting any kind of exactness from floating point values is asking for trouble. Sure, they follow the rules that they have consistently, but there are so many numbers that aren't actually representable by a floating point value, the precisions vary just enough, and slightly different code paths can result in slightly different results that depending on floating point operations resulting in any kind of specific values except under very controlled circumstances just isn't going to work. - Jonathan M Davis
