Re: Passing shared delegates
On Monday, 14 January 2013 at 07:20:17 UTC, Martin DraĊĦar wrote:
Dne 11.1.2013 23:26, mist napsal(a):
Do not have time to test code right now but first guess it is
related to
parsing differences for delegates and usual functions.
Delegates can
have shared/const applied to both delegate type itself and
context of
underlying function. Those are different beasts and no wonder
type
system complains.
You may need to try something like void delegate() shared f
if you
want delegate type to match method one.
Hi mist,
that was the first thing I tried, but it resulted in a
completely different error:
class B
{
void bar(void delegate() shared f) {}
}
Error: const/immutable/shared/inout attributes are only valid
for non-static member functions
Martin
Which compiler version do you use? It compiles on 2.061.
In case of applying attributes to functions, mostly it is
irrelevant whether it stands first or last. So,
void foo() shared {}
and
shared void foo() {}
in A class are equivalent. However in case of bar parameter you
are qualifying not a function, but object, so shared before
return type of delegate applies to object, like (shared (int i)).
Shared after delegate applies to delegate type, not object itself.
Re: Mixin Template: cannot mixin scope(exit)?
On 01/14/2013 07:26 AM, 1100110 wrote:
On 01/13/2013 11:35 PM, 1100110 wrote:
Ok, I wish to create a standard timing system so that I can measure ~how
long each function takes to execute.
I wish to be able to place at the start of a function
version(Time) mixin TimeExecution(funcName);
mixin template TimeExecution(T) if(isSomeString!T) {
import std.stdio, std.datetime, std.conv;
auto sw = StopWatch(AutoStart.yes);
// Error: Declaration expected, not '('
scope(exit) writeln(T, : , to!Duration(sw.peek));
}
Why do I receive the Error when the scope statement is included?
Is this an error, or what is the rationale behind the decision?
Thank you.
It appears that you cannot mixin *any* statement with
scope([exit,success,etc]) in it.
I have been rereading my copy of TDPL, and it states that mixin
statements must be valid D code, and there can be multiple 'scope()'
statements.
Since scope(exit) writeln(); is valid D code, and refuses to compile
in a mixin, I assume that this is a bug.
I've been digging through the bug tracker and I cannot find a duplicate
bug, so if someone can confirm that this is a bug, I'll create a report.
It is not a bug. Use a string mixin.
Trouble with DLL address
I have a DLL which exports a function GetFunction. GetFunction
returns a pointer to RealFunction. Now I want to run RealFunction
from my D program, but for some reason I get the wrong address.
Here is the code.
dll64.c -
#define WIN32_LEAN_AND_MEAN
#include windows.h
int __stdcall RealFunction(int a)
{
return a + 1;
}
typedef int (__stdcall *FuncPtr)(int);
FuncPtr __stdcall GetFunction()
{
return RealFunction;
}
mydll64.def
LIBRARY mydll64.dll
EXPORTS
GetFunction
-
build with MSVC64:
cl -c dll64.c -Fomydll64.obj
link /DLL /OUT:mydll64.dll mydll64.obj /DEF:mydll64.def
And this is the D program.
testdll64d.d
// dmd -m64 -c testdll64d.d -oftestdll64d.obj
// link /OUT:testdll64d.exe testdll64d.obj
import core.runtime;
import std.c.windows.windows;
import std.stdio;
alias extern(Windows) int function(int) FuncPtr;
int main(string[] args)
{
HMODULE dll = LoadLibraryA(mydll64.DLL);
FARPROC getFunction = GetProcAddress(dll, GetFunction);
FuncPtr realFunction = cast(FuncPtr) getFunction();
writefln(dll address: %08x, dll);
writefln(GetFunction address: %08x, getFunction);
writefln(RealFunction address: %08x, realFunction);
writefln(RealFunction result: %d, realFunction(7));//--
CRASH
return 0;
}
--
Output:
dll address: 18000
GetFunction address: 180001020
RealFunction address: 80001000
CRASH
BTW, this works:
FuncPtr realFunction = cast(FuncPtr) (getFunction()
0x | cast(size_t) dll);
Re: Trouble with DLL address
Just ignore my post - too early in the morning :(
Am 14.01.2013 10:19, schrieb dennis luehring:
http://dlang.org/type.html
int = signed 32 bits
but don't you need long in D
Am 14.01.2013 10:13, schrieb dnewbie:
I have a DLL which exports a function GetFunction. GetFunction
returns a pointer to RealFunction. Now I want to run RealFunction
from my D program, but for some reason I get the wrong address.
Here is the code.
dll64.c -
#define WIN32_LEAN_AND_MEAN
#include windows.h
int __stdcall RealFunction(int a)
{
return a + 1;
}
typedef int (__stdcall *FuncPtr)(int);
FuncPtr __stdcall GetFunction()
{
return RealFunction;
}
mydll64.def
LIBRARY mydll64.dll
EXPORTS
GetFunction
-
build with MSVC64:
cl -c dll64.c -Fomydll64.obj
link /DLL /OUT:mydll64.dll mydll64.obj /DEF:mydll64.def
And this is the D program.
testdll64d.d
// dmd -m64 -c testdll64d.d -oftestdll64d.obj
// link /OUT:testdll64d.exe testdll64d.obj
import core.runtime;
import std.c.windows.windows;
import std.stdio;
alias extern(Windows) int function(int) FuncPtr;
int main(string[] args)
{
HMODULE dll = LoadLibraryA(mydll64.DLL);
FARPROC getFunction = GetProcAddress(dll, GetFunction);
FuncPtr realFunction = cast(FuncPtr) getFunction();
writefln(dll address: %08x, dll);
writefln(GetFunction address: %08x, getFunction);
writefln(RealFunction address: %08x, realFunction);
writefln(RealFunction result: %d, realFunction(7));//--
CRASH
return 0;
}
--
Output:
dll address: 18000
GetFunction address: 180001020
RealFunction address: 80001000
CRASH
BTW, this works:
FuncPtr realFunction = cast(FuncPtr) (getFunction()
0x | cast(size_t) dll);
Re: Trouble with DLL address
http://dlang.org/type.html
int = signed 32 bits
but don't you need long in D
Am 14.01.2013 10:13, schrieb dnewbie:
I have a DLL which exports a function GetFunction. GetFunction
returns a pointer to RealFunction. Now I want to run RealFunction
from my D program, but for some reason I get the wrong address.
Here is the code.
dll64.c -
#define WIN32_LEAN_AND_MEAN
#include windows.h
int __stdcall RealFunction(int a)
{
return a + 1;
}
typedef int (__stdcall *FuncPtr)(int);
FuncPtr __stdcall GetFunction()
{
return RealFunction;
}
mydll64.def
LIBRARY mydll64.dll
EXPORTS
GetFunction
-
build with MSVC64:
cl -c dll64.c -Fomydll64.obj
link /DLL /OUT:mydll64.dll mydll64.obj /DEF:mydll64.def
And this is the D program.
testdll64d.d
// dmd -m64 -c testdll64d.d -oftestdll64d.obj
// link /OUT:testdll64d.exe testdll64d.obj
import core.runtime;
import std.c.windows.windows;
import std.stdio;
alias extern(Windows) int function(int) FuncPtr;
int main(string[] args)
{
HMODULE dll = LoadLibraryA(mydll64.DLL);
FARPROC getFunction = GetProcAddress(dll, GetFunction);
FuncPtr realFunction = cast(FuncPtr) getFunction();
writefln(dll address: %08x, dll);
writefln(GetFunction address: %08x, getFunction);
writefln(RealFunction address: %08x, realFunction);
writefln(RealFunction result: %d, realFunction(7));//--
CRASH
return 0;
}
--
Output:
dll address: 18000
GetFunction address: 180001020
RealFunction address: 80001000
CRASH
BTW, this works:
FuncPtr realFunction = cast(FuncPtr) (getFunction()
0x | cast(size_t) dll);
Re: Mixin Template: cannot mixin scope(exit)?
On 01/14/2013 02:03 AM, Timon Gehr wrote:
On 01/14/2013 07:26 AM, 1100110 wrote:
On 01/13/2013 11:35 PM, 1100110 wrote:
Ok, I wish to create a standard timing system so that I can measure ~how
long each function takes to execute.
I wish to be able to place at the start of a function
version(Time) mixin TimeExecution(funcName);
mixin template TimeExecution(T) if(isSomeString!T) {
import std.stdio, std.datetime, std.conv;
auto sw = StopWatch(AutoStart.yes);
// Error: Declaration expected, not '('
scope(exit) writeln(T, : , to!Duration(sw.peek));
}
Why do I receive the Error when the scope statement is included?
Is this an error, or what is the rationale behind the decision?
Thank you.
It appears that you cannot mixin *any* statement with
scope([exit,success,etc]) in it.
I have been rereading my copy of TDPL, and it states that mixin
statements must be valid D code, and there can be multiple 'scope()'
statements.
Since scope(exit) writeln(); is valid D code, and refuses to compile
in a mixin, I assume that this is a bug.
I've been digging through the bug tracker and I cannot find a duplicate
bug, so if someone can confirm that this is a bug, I'll create a report.
It is not a bug. Use a string mixin.
Well, dangit. Thanks!
Re: MS ODBC encoding issue
I'm more than happy to upload the database file here,but I can't find how to.May I have your mail address?Appreciated for all the help! My email address in the from is valid: regan at netmail dot co dot nz -- Using Opera's revolutionary email client: http://www.opera.com/mail/
Re: Passing shared delegates
On 14.1.2013 8:56, Maxim Fomin wrote:
Which compiler version do you use? It compiles on 2.061.
It was 2.060. It compiles now on 2.061. Great!
In case of applying attributes to functions, mostly it is irrelevant
whether it stands first or last. So,
void foo() shared {}
and
shared void foo() {}
in A class are equivalent. However in case of bar parameter you are
qualifying not a function, but object, so shared before return type of
delegate applies to object, like (shared (int i)). Shared after delegate
applies to delegate type, not object itself.
Thanks for clarification.
Martin
Re: Passing shared delegates
On Monday, 14 January 2013 at 10:13:16 UTC, Martin Drasar wrote: On 14.1.2013 8:56, Maxim Fomin wrote: Which compiler version do you use? It compiles on 2.061. It was 2.060. It compiles now on 2.061. Great! Yes, it was a known bug in pre-2.061 Big relief to have it working :)
Re: Mixin Template: cannot mixin scope(exit)?
It appears that you cannot mixin *any* statement with scope([exit,success,etc]) in it. I have been rereading my copy of TDPL, and it states that mixin statements must be valid D code, and there can be multiple 'scope()' statements. Since scope(exit) writeln(); is valid D code, and refuses to compile in a mixin, I assume that this is a bug. I've been digging through the bug tracker and I cannot find a duplicate bug, so if someone can confirm that this is a bug, I'll create a report. It is not a bug. Use a string mixin. What is the rationale behind this limitation?
Need help with storage class definition
While working on https://github.com/D-Programming-Language/phobos/pull/863 I have noticed that inout breaks ParameterStorageClassTuple and family. I have started working on a fix but quick comparison of http://dlang.org/declaration.html#StorageClass vs http://dlang.org/phobos/std_traits.html#.ParameterStorageClassTuple have left me in confusion without clear understanding what parameter storage classes are supposed to be defined to. There is also InOutX entry in grammar which lists some of storage classes and seems more relevant to parameter storage classes (i.e. includes ref). Can someone give a more structured explanation: what is supposed to be a storage class, what is supposed to be a type storage class and what - a type qualifier? I'd like to update std.traits demanglers to the latest state of things, but grammar description does not seem clear enough.
Re: does alias this work correctly?
On Sunday, 13 January 2013 at 22:36:03 UTC, Jonathan M Davis wrote: On Sunday, January 13, 2013 20:41:48 Zhenya wrote: On Sunday, 13 January 2013 at 19:35:08 UTC, Maxim Fomin wrote: According to spec http://dlang.org/class.html#AliasThis undefined lookups are forwarded to AliasThis member. But in your case Foo struct has bar member, so no further resolution is performed. Rename the member and the code compiles. Note, this seems to come from neighbor thread http://forum.dlang.org/thread/uelmpwwckcveimpbd...@forum.dlang.org. I think it is simpler to rename functions than create bunch of structs just to be able to have eponymous non-static and static functions. I just want very much avoid renaming function,it's principle for me. So I would like to know is my sample right or no. It functions exactly like it's supposed to. As Maxim said, undefined lookups go to the alias this member. If Foo already has a bar and you try and call it, it doesn't matter what Foo is aliased to, it's Foo's bar that's going to be used. - Jonathan M Davis Now it's clear for me,thank you.
Re: does alias this work correctly?
On Sunday, 13 January 2013 at 23:21:20 UTC, Andrey wrote:
I just want very much avoid renaming function,it's principle
for me.
So I would like to know is my sample right or no.
I think that the main overall principle here is that is it
impossible to have two functions which differ only by static
attribute. I even do not imagine the use case of this.
Well, here is the most natural way to achieve similar effect, I
suppose:
struct MyStruct {
struct Static {
static void myfun() {
writeln(static myfun);
}
}
void myfun() {
writeln(myfun);
}
static Static opCall() {
return Static();
}
}
MyStruct obj;
obj.myfun(); //dynamic;
MyStruct().myfun(); //static;
I do not agree with you, static attribute is not a small detail.
this reference is the same argument, like all the others. And
despite the fact that
function signatures are the same, the actual list of arguments
are different.
Re: Need help with storage class definition
Meh, while I was looking for this info in docs kind Kenji simply came out and fixed it, leaving no chance to learn :(
Re: Need help with storage class definition
On Monday, 14 January 2013 at 14:16:32 UTC, mist wrote: While working on https://github.com/D-Programming-Language/phobos/pull/863 I have noticed that inout breaks ParameterStorageClassTuple and family. I have started working on a fix but quick comparison of http://dlang.org/declaration.html#StorageClass vs http://dlang.org/phobos/std_traits.html#.ParameterStorageClassTuple have left me in confusion without clear understanding what parameter storage classes are supposed to be defined to. There is also InOutX entry in grammar which lists some of storage classes and seems more relevant to parameter storage classes (i.e. includes ref). Can someone give a more structured explanation: what is supposed to be a storage class, what is supposed to be a type storage class and what - a type qualifier? I'd like to update std.traits demanglers to the latest state of things, but grammar description does not seem clear enough. http://dlang.org/declaration.html#StorageClass InOutX is the list of 'syntactically allowed' keywords. Among them, these four are supported as actual 'parameter storage classes'. scope out ref lazy In current, 'in' is directly replaced to 'const', and it is treated as a part of parameter type. 'inout' is also treated as a type qualifier, and then is the same. Kenji Hara
Re: does alias this work correctly?
On Sunday, 13 January 2013 at 22:36:03 UTC, Jonathan M Davis
wrote:
On Sunday, January 13, 2013 20:41:48 Zhenya wrote:
On Sunday, 13 January 2013 at 19:35:08 UTC, Maxim Fomin wrote:
According to spec http://dlang.org/class.html#AliasThis
undefined lookups are forwarded to AliasThis member. But in
your case Foo struct has bar member, so no further resolution
is performed. Rename the member and the code compiles.
Note, this seems to come from neighbor thread
http://forum.dlang.org/thread/uelmpwwckcveimpbd...@forum.dlang.org.
I think it is simpler to rename functions than create bunch
of
structs just to be able to have eponymous non-static and
static
functions.
I just want very much avoid renaming function,it's principle
for
me.
So I would like to know is my sample right or no.
It functions exactly like it's supposed to. As Maxim said,
undefined lookups go
to the alias this member. If Foo already has a bar and you try
and call it, it
doesn't matter what Foo is aliased to, it's Foo's bar that's
going to be used.
- Jonathan M Davis
import std.stdio;
struct Bar
{
void opDispatch(string op)()
if(op == bar)
{
if(this !is m_init)
writeln(non-static);
else
writeln(maybe static);
}
static @property Bar m_init()
{
return Bar.init;
}
alias m_init this;
}
void main()
{
Bar b;
Bar.bar();
readln;
}
If I understood you correctly, it must be compiled since there
isn't some 'bar' that is going to be used, right?
But it doesn't compile.
Re: Good tutorials
SaltySugar wrote: Where i can find some good tutorials and books? :) http://ddili.org/ders/d.en/ http://www.amazon.com/exec/obidos/ASIN/0321635361/classicempire Peter
Re: Good tutorials
On 01/14/2013 12:25 PM, SaltySugar wrote: Where i can find some good tutorials and books? :) https://github.com/PhilippeSigaud/D-templates-tutorial https://github.com/PhilippeSigaud/D-templates-tutorial/blob/master/D-templates-tutorial.pdf?raw=true The second link is a direct pdf download of the tutorial. I find it's quite nice.
parallel() and random number generation
Hello all,
One of the claims made for pseudo-random number generation in D is that rndGen
(default RNG) is thread-safe, that is, each instance is unique to its thread and
is seeded with unpredictableSeed, which should strongly limit the chances of two
threads having correlated sequences of pseudo-random numbers.
Now consider the following code:
import std.random, std.range, std.stdio;
void main()
{
rndGen.seed(1001);
foreach(i; iota(12))
writeln(uniform(0.0, 1.0));
}
Obviously, because we seed rndGen, this produces exactly the same sequence every
time. But now suppose we use a parallel foreach:
import std.parallelism, std.random, std.range, std.stdio;
void main()
{
rndGen.seed(1001);
foreach(i; iota(12).parallel())
writeln(uniform(0.0, 1.0));
}
Now, I'd expect that suddenly a number of the random variates would suddenly
become unpredictable with each run, and that the number thereof would be
proportional to the number of threads -- so with 2 threads, we'd expect half the
numbers to suddenly be unpredictable with each run -- because only one thread
would be using the seeded pseudo-random sequence, and the others would be using
a separate rndGen with unpredictable seed.
But actually, in my experience, the number of random variates that differ from
the predictable sequence is not in proportion to the number of threads and often
corresponds only to the last 3-4 variates.
This is a bit worrying, because it raises the question of whether the same
rndGen is being used in the different threads, and thus whether in fact threads
might generate correlated random sequences.
Advice/thoughts/explanations?
Thanks best wishes,
-- Joe
Re: Trouble with DLL address
On 1/14/13, dnewbie r...@myopera.com wrote: FuncPtr realFunction = cast(FuncPtr) getFunction(); Make that: FuncPtr realFunction = cast(FuncPtr) getFunction; Don't call the FARPROC, just cast it.
Re: Trouble with DLL address
The problem is FARPROC. Thank you everybody.
Solution:
import core.runtime;
import std.c.windows.windows;
import std.stdio;
alias extern(Windows) int function(int) FuncPtr;
alias extern(Windows) FuncPtr function() GetFuncPtr;
int main(string[] args)
{
HMODULE dll= LoadLibraryA(mydll64.DLL);
GetFuncPtr getFunction = cast(GetFuncPtr) GetProcAddress(dll,
GetFunction);
FuncPtr realFunction = cast(FuncPtr) getFunction();
writefln(dll address: %08x, dll);
writefln(GetFunction address: %08x, getFunction);
writefln(RealFunction address: %08x, realFunction);
writefln(RealFunction result: %d, realFunction(7));
return 0;
}
Re: does alias this work correctly?
On Monday, January 14, 2013 17:57:03 Zhenya wrote:
import std.stdio;
struct Bar
{
void opDispatch(string op)()
if(op == bar)
{
if(this !is m_init)
writeln(non-static);
else
writeln(maybe static);
}
static @property Bar m_init()
{
return Bar.init;
}
alias m_init this;
}
void main()
{
Bar b;
Bar.bar();
readln;
}
If I understood you correctly, it must be compiled since there
isn't some 'bar' that is going to be used, right?
But it doesn't compile.
I honestly have no idea how opDispatch and alias this are supposed to
interact. They're both used as fallbacks when the type doesn't directly define
a function. That being said The reason that your code doesn't work here is the
fact that you'r ecalling bar is if it were a static function, but your
opDispatch isn't static. opDispatch would have to be static for it to be used
as a static function (it can't be both static and non-static), and in that
case, the if condition that you have in it wouldn't compile.
- Jonathan M Davis
Re: does alias this work correctly?
On Tuesday, 15 January 2013 at 00:04:15 UTC, Jonathan M Davis
wrote:
On Monday, January 14, 2013 17:57:03 Zhenya wrote:
import std.stdio;
struct Bar
{
void opDispatch(string op)()
if(op == bar)
{
if(this !is m_init)
writeln(non-static);
else
writeln(maybe static);
}
static @property Bar m_init()
{
return Bar.init;
}
alias m_init this;
}
void main()
{
Bar b;
Bar.bar();
readln;
}
If I understood you correctly, it must be compiled since there
isn't some 'bar' that is going to be used, right?
But it doesn't compile.
I honestly have no idea how opDispatch and alias this are
supposed to
interact. They're both used as fallbacks when the type doesn't
directly define
a function. That being said The reason that your code doesn't
work here is the
fact that you'r ecalling bar is if it were a static function,
but your
opDispatch isn't static. opDispatch would have to be static for
it to be used
as a static function (it can't be both static and non-static),
and in that
case, the if condition that you have in it wouldn't compile.
- Jonathan M Davis
:( If compiler tried alias this before opDispatch all would be OK.
Maybe I'm going to give up.
Thank you for comprehensive explanation.
Re: Mixin Template: cannot mixin scope(exit)?
On 2013-01-14 11:44, mist wrote: What is the rationale behind this limitation? I'm not sure but it might have something to do with template mixins introduce a new scope or similar. -- /Jacob Carlborg
