Problems building Qtd on Windows
I'm trying to compile Qtd trunk on QT 4.7 using dmd 2.054, but I'm
getting a strange error:
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe -- broken
The C++ compiler "c:/Qt/2010.05/mingw/bin/g++.exe" is not able to
compile a
simple test program.
But I'm able to compile a small program, t.c:
int main() { return 0; }
g++ t.c
a.exe // works
Here's the full output:
c:\d\ext\qtd\dmd-2.054>cmake -G"MinGW Makefiles" ../
-DCMAKE_CXX_FLAGS="-m32"
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe -- broken
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeTes
tCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler "c:/Qt/2010.05/mingw/bin/g++.exe" is not able to
compile a
simple test program.
It fails with the following output:
Change Dir: C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp
Run Build Command:c:/Qt/2010.05/mingw/bin/mingw32-make.exe
"cmTryCompileExec/fast"
c:/Qt/2010.05/mingw/bin/mingw32-make.exe -f
CMakeFiles\cmTryCompileExec.dir\build.make
CMakeFiles/cmTryCompileExec.dir/build
mingw32-make.exe[1]: Entering directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_progress_report
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\CMakeFiles 1
Building CXX object
CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.obj
c:\Qt\2010.05\mingw\bin\g++.exe -m32 -o
CMakeFiles\cmTryCompileExec.dir\testCXXCompiler.cxx.obj -c
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\testCXXCompiler.cxx
Linking CXX executable cmTryCompileExec.exe
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_link_script
CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
Error opening link script "CMakeFiles\cmTryCompileExec.dir\link.txt"
mingw32-make.exe[1]: *** [cmTryCompileExec.exe] Error 1
mingw32-make.exe[1]: Leaving directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (PROJECT)
-- Configuring incomplete, errors occurred!
Re: Problems building Qtd on Windows
On 19.07.2011 10:23, simendsjo wrote:
I'm trying to compile Qtd trunk on QT 4.7 using dmd 2.054, but I'm
getting a strange error:
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
The C++ compiler "c:/Qt/2010.05/mingw/bin/g++.exe" is not able to compile a
simple test program.
But I'm able to compile a small program, t.c:
int main() { return 0; }
g++ t.c
a.exe // works
Here's the full output:
c:\d\ext\qtd\dmd-2.054>cmake -G"MinGW Makefiles" ../
-DCMAKE_CXX_FLAGS="-m32"
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeTes
tCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler "c:/Qt/2010.05/mingw/bin/g++.exe" is not able to compile a
simple test program.
It fails with the following output:
Change Dir: C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp
Run Build Command:c:/Qt/2010.05/mingw/bin/mingw32-make.exe
"cmTryCompileExec/fast"
c:/Qt/2010.05/mingw/bin/mingw32-make.exe -f
CMakeFiles\cmTryCompileExec.dir\build.make
CMakeFiles/cmTryCompileExec.dir/build
mingw32-make.exe[1]: Entering directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_progress_report
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\CMakeFiles 1
Building CXX object
CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.obj
c:\Qt\2010.05\mingw\bin\g++.exe -m32 -o
CMakeFiles\cmTryCompileExec.dir\testCXXCompiler.cxx.obj -c
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\testCXXCompiler.cxx
Linking CXX executable cmTryCompileExec.exe
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_link_script
CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
Error opening link script "CMakeFiles\cmTryCompileExec.dir\link.txt"
mingw32-make.exe[1]: *** [cmTryCompileExec.exe] Error 1
mingw32-make.exe[1]: Leaving directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (PROJECT)
-- Configuring incomplete, errors occurred!
The steps works while running manually:
> mingw32-make.exe[1]: Entering directory
> `C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
(...)
> "C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_link_script
> CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
>
> Error opening link script "CMakeFiles\cmTryCompileExec.dir\link.txt"
But if I do this manually:
cd CMakeFiles\CMakeTmp
cmake -E cmake_link_script CMakeFiles\cmTryCompileExec.dir\link.txt
--verbose=1
It works and I get a cmTryCompileExec.exe.
Does it have some problems with the relative path? Any workaround for this?
This is using cmake 2.8.5
Re: Problems building Qtd on Windows
On 19.07.2011 11:20, simendsjo wrote:
On 19.07.2011 10:23, simendsjo wrote:
I'm trying to compile Qtd trunk on QT 4.7 using dmd 2.054, but I'm
getting a strange error:
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
The C++ compiler "c:/Qt/2010.05/mingw/bin/g++.exe" is not able to
compile a
simple test program.
But I'm able to compile a small program, t.c:
int main() { return 0; }
g++ t.c
a.exe // works
Here's the full output:
c:\d\ext\qtd\dmd-2.054>cmake -G"MinGW Makefiles" ../
-DCMAKE_CXX_FLAGS="-m32"
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeTes
tCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler "c:/Qt/2010.05/mingw/bin/g++.exe" is not able to
compile a
simple test program.
It fails with the following output:
Change Dir: C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp
Run Build Command:c:/Qt/2010.05/mingw/bin/mingw32-make.exe
"cmTryCompileExec/fast"
c:/Qt/2010.05/mingw/bin/mingw32-make.exe -f
CMakeFiles\cmTryCompileExec.dir\build.make
CMakeFiles/cmTryCompileExec.dir/build
mingw32-make.exe[1]: Entering directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_progress_report
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\CMakeFiles 1
Building CXX object
CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.obj
c:\Qt\2010.05\mingw\bin\g++.exe -m32 -o
CMakeFiles\cmTryCompileExec.dir\testCXXCompiler.cxx.obj -c
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\testCXXCompiler.cxx
Linking CXX executable cmTryCompileExec.exe
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_link_script
CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
Error opening link script "CMakeFiles\cmTryCompileExec.dir\link.txt"
mingw32-make.exe[1]: *** [cmTryCompileExec.exe] Error 1
mingw32-make.exe[1]: Leaving directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (PROJECT)
-- Configuring incomplete, errors occurred!
The steps works while running manually:
> mingw32-make.exe[1]: Entering directory
> `C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
(...)
> "C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_link_script
> CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
>
> Error opening link script "CMakeFiles\cmTryCompileExec.dir\link.txt"
But if I do this manually:
cd CMakeFiles\CMakeTmp
cmake -E cmake_link_script CMakeFiles\cmTryCompileExec.dir\link.txt
--verbose=1
It works and I get a cmTryCompileExec.exe.
Does it have some problems with the relative path? Any workaround for this?
This is using cmake 2.8.5
I've also tried cmake 2.6 without any luck.
I forced the "try compile" stuff to report as succeeded by modifying
CMakeTestCXXCompiler.cmake and CMakeTestCCompiler.cmake.
This allowed me to begin compilation, but the underlying problem is not
gone, and linking fails during compilation:
Linking CXX shared library lib\libcpp_core.dll
Error opening link script "CMakeFiles\cpp_core.dir\link.txt"
mingw32-make[5]: *** [lib/libcpp_core.dll] Error 1
mingw32-make[4]: *** [CMakeFiles/cpp_core.dir/all] Error 2
mingw32-make[3]: *** [all] Error 2
mingw32-make[2]: *** [main] Error 2
mingw32-make[1]: *** [CMakeFiles/main.dir/all] Error 2
mingw32-make: *** [all] Error 2
Re: Calling D from C++
On 2011-07-19 05:46, Johann MacDonagh wrote:
What is the best method to accomplish this, and are there any
limitations with this method (do I have to allocate the class with
malloc instead etc.)?
Your C++ class "Base" is not compatible with your D "Foo" class. The
v-tables are not guaranteed to be identical. I'm not even sure if D's
thiscall is the same as C++'s thiscall. It's just not going to work.
Most languages don't support this. This is why we use C bindings.
Everyone supports C ;)
Now, you can do something like this:
struct Foo
{
int x;
float y;
}
extern(C) void* GetNewFoo()
{
// Note: Don't use new here otherwise the GC may clean it up
return cast(void*) core.memory.GC.malloc(Foo.sizeof);
}
extern(C) float Foo_DoSomething(Foo* foo)
{
return foo.x + foo.y;
}
extern(C) void FreeFoo(Foo* foo)
{
core.memory.GC.free(foo);
}
I haven't tried this, but something like this should work. Structs are
inherently compatible between languages. Of course, you won't be able to
do any kind of polymorphism.
Does this help?
Very interesting!
This might help depends; are you able to have structures with functions?
Are they still analogous if you implement them?
Also, how come the class-interface inheritance didn't work to
communicate with C++. Is the "Interface to C++" doc's outdated?
"Calling D Virtual Functions From C++"
http://www.digitalmars.com/d/2.0/cpp_interface.html
Re: Problems building Qtd on Windows
On 19.07.2011 11:56, simendsjo wrote:
On 19.07.2011 11:20, simendsjo wrote:
On 19.07.2011 10:23, simendsjo wrote:
I'm trying to compile Qtd trunk on QT 4.7 using dmd 2.054, but I'm
getting a strange error:
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
The C++ compiler "c:/Qt/2010.05/mingw/bin/g++.exe" is not able to
compile a
simple test program.
But I'm able to compile a small program, t.c:
int main() { return 0; }
g++ t.c
a.exe // works
Here's the full output:
c:\d\ext\qtd\dmd-2.054>cmake -G"MinGW Makefiles" ../
-DCMAKE_CXX_FLAGS="-m32"
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeTes
tCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler "c:/Qt/2010.05/mingw/bin/g++.exe" is not able to
compile a
simple test program.
It fails with the following output:
Change Dir: C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp
Run Build Command:c:/Qt/2010.05/mingw/bin/mingw32-make.exe
"cmTryCompileExec/fast"
c:/Qt/2010.05/mingw/bin/mingw32-make.exe -f
CMakeFiles\cmTryCompileExec.dir\build.make
CMakeFiles/cmTryCompileExec.dir/build
mingw32-make.exe[1]: Entering directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E
cmake_progress_report
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\CMakeFiles 1
Building CXX object
CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.obj
c:\Qt\2010.05\mingw\bin\g++.exe -m32 -o
CMakeFiles\cmTryCompileExec.dir\testCXXCompiler.cxx.obj -c
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\testCXXCompiler.cxx
Linking CXX executable cmTryCompileExec.exe
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_link_script
CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
Error opening link script "CMakeFiles\cmTryCompileExec.dir\link.txt"
mingw32-make.exe[1]: *** [cmTryCompileExec.exe] Error 1
mingw32-make.exe[1]: Leaving directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (PROJECT)
-- Configuring incomplete, errors occurred!
The steps works while running manually:
> mingw32-make.exe[1]: Entering directory
> `C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
(...)
> "C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_link_script
> CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
>
> Error opening link script "CMakeFiles\cmTryCompileExec.dir\link.txt"
But if I do this manually:
cd CMakeFiles\CMakeTmp
cmake -E cmake_link_script CMakeFiles\cmTryCompileExec.dir\link.txt
--verbose=1
It works and I get a cmTryCompileExec.exe.
Does it have some problems with the relative path? Any workaround for
this?
This is using cmake 2.8.5
I've also tried cmake 2.6 without any luck.
I forced the "try compile" stuff to report as succeeded by modifying
CMakeTestCXXCompiler.cmake and CMakeTestCCompiler.cmake.
This allowed me to begin compilation, but the underlying problem is not
gone, and linking fails during compilation:
Linking CXX shared library lib\libcpp_core.dll
Error opening link script "CMakeFiles\cpp_core.dir\link.txt"
mingw32-make[5]: *** [lib/libcpp_core.dll] Error 1
mingw32-make[4]: *** [CMakeFiles/cpp_core.dir/all] Error 2
mingw32-make[3]: *** [all] Error 2
mingw32-make[2]: *** [main] Error 2
mingw32-make[1]: *** [CMakeFiles/main.dir/all] Error 2
mingw32-make: *** [all] Error 2
Trying SO:
http://stackoverflow.com/questions/6745911/cmake-error-opening-link-script-cannot-change-directory
Re: Calling D from C++
On 2011-07-19 12:39, Loopback wrote:
On 2011-07-19 05:46, Johann MacDonagh wrote:
What is the best method to accomplish this, and are there any
limitations with this method (do I have to allocate the class with
malloc instead etc.)?
Your C++ class "Base" is not compatible with your D "Foo" class. The
v-tables are not guaranteed to be identical. I'm not even sure if D's
thiscall is the same as C++'s thiscall. It's just not going to work.
Most languages don't support this. This is why we use C bindings.
Everyone supports C ;)
Now, you can do something like this:
struct Foo
{
int x;
float y;
}
extern(C) void* GetNewFoo()
{
// Note: Don't use new here otherwise the GC may clean it up
return cast(void*) core.memory.GC.malloc(Foo.sizeof);
}
extern(C) float Foo_DoSomething(Foo* foo)
{
return foo.x + foo.y;
}
extern(C) void FreeFoo(Foo* foo)
{
core.memory.GC.free(foo);
}
I haven't tried this, but something like this should work. Structs are
inherently compatible between languages. Of course, you won't be able to
do any kind of polymorphism.
Does this help?
Very interesting!
This might help depends; are you able to have structures with functions?
Are they still analogous if you implement them?
Also, how come the class-interface inheritance didn't work to
communicate with C++. Is the "Interface to C++" doc's outdated?
"Calling D Virtual Functions From C++"
http://www.digitalmars.com/d/2.0/cpp_interface.html
I noticed that function seems to work functions with structures.
Are there any restrictions worth knowing or is it just like any other
structure when D and C++ communicate?
Can I have private variables, public, properties etc?
And just not to forget, why the C++ and interface class didn't work?
Re: Problems building Qtd on Windows
On 19.07.2011 12:45, simendsjo wrote:
On 19.07.2011 11:56, simendsjo wrote:
On 19.07.2011 11:20, simendsjo wrote:
On 19.07.2011 10:23, simendsjo wrote:
I'm trying to compile Qtd trunk on QT 4.7 using dmd 2.054, but I'm
getting a strange error:
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
The C++ compiler "c:/Qt/2010.05/mingw/bin/g++.exe" is not able to
compile a
simple test program.
But I'm able to compile a small program, t.c:
int main() { return 0; }
g++ t.c
a.exe // works
Here's the full output:
c:\d\ext\qtd\dmd-2.054>cmake -G"MinGW Makefiles" ../
-DCMAKE_CXX_FLAGS="-m32"
-- The CXX compiler identification is GNU
-- The C compiler identification is GNU
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe
-- Check for working CXX compiler: c:/Qt/2010.05/mingw/bin/g++.exe --
broken
CMake Error at C:/Program Files (x86)/CMake
2.8/share/cmake-2.8/Modules/CMakeTes
tCXXCompiler.cmake:45 (MESSAGE):
The C++ compiler "c:/Qt/2010.05/mingw/bin/g++.exe" is not able to
compile a
simple test program.
It fails with the following output:
Change Dir: C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp
Run Build Command:c:/Qt/2010.05/mingw/bin/mingw32-make.exe
"cmTryCompileExec/fast"
c:/Qt/2010.05/mingw/bin/mingw32-make.exe -f
CMakeFiles\cmTryCompileExec.dir\build.make
CMakeFiles/cmTryCompileExec.dir/build
mingw32-make.exe[1]: Entering directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E
cmake_progress_report
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\CMakeFiles 1
Building CXX object
CMakeFiles/cmTryCompileExec.dir/testCXXCompiler.cxx.obj
c:\Qt\2010.05\mingw\bin\g++.exe -m32 -o
CMakeFiles\cmTryCompileExec.dir\testCXXCompiler.cxx.obj -c
C:\d\ext\qtd\dmd-2.054\CMakeFiles\CMakeTmp\testCXXCompiler.cxx
Linking CXX executable cmTryCompileExec.exe
"C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_link_script
CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
Error opening link script "CMakeFiles\cmTryCompileExec.dir\link.txt"
mingw32-make.exe[1]: *** [cmTryCompileExec.exe] Error 1
mingw32-make.exe[1]: Leaving directory
`C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [cmTryCompileExec/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:2 (PROJECT)
-- Configuring incomplete, errors occurred!
The steps works while running manually:
> mingw32-make.exe[1]: Entering directory
> `C:/d/ext/qtd/dmd-2.054/CMakeFiles/CMakeTmp'
(...)
> "C:\Program Files (x86)\CMake 2.8\bin\cmake.exe" -E cmake_link_script
> CMakeFiles\cmTryCompileExec.dir\link.txt --verbose=1
>
> Error opening link script "CMakeFiles\cmTryCompileExec.dir\link.txt"
But if I do this manually:
cd CMakeFiles\CMakeTmp
cmake -E cmake_link_script CMakeFiles\cmTryCompileExec.dir\link.txt
--verbose=1
It works and I get a cmTryCompileExec.exe.
Does it have some problems with the relative path? Any workaround for
this?
This is using cmake 2.8.5
I've also tried cmake 2.6 without any luck.
I forced the "try compile" stuff to report as succeeded by modifying
CMakeTestCXXCompiler.cmake and CMakeTestCCompiler.cmake.
This allowed me to begin compilation, but the underlying problem is not
gone, and linking fails during compilation:
Linking CXX shared library lib\libcpp_core.dll
Error opening link script "CMakeFiles\cpp_core.dir\link.txt"
mingw32-make[5]: *** [lib/libcpp_core.dll] Error 1
mingw32-make[4]: *** [CMakeFiles/cpp_core.dir/all] Error 2
mingw32-make[3]: *** [all] Error 2
mingw32-make[2]: *** [main] Error 2
mingw32-make[1]: *** [CMakeFiles/main.dir/all] Error 2
mingw32-make: *** [all] Error 2
Trying SO:
http://stackoverflow.com/questions/6745911/cmake-error-opening-link-script-cannot-change-directory
Giving up... Tried 3 versions of qt + 2 of cmake + 2 of qtd.
Is windows not supported anymore?
Re: std.concurrency.spawn does not accept delegates
On Mon, 18 Jul 2011 18:39:01 -0400, Jonathan M Davis wrote: On 2011-07-18 15:15, teo wrote: On Mon, 18 Jul 2011 18:14:45 +, Jonathan M Davis wrote: > On 2011-07-18 10:54, Simen Kjaeraas wrote: >> On Mon, 18 Jul 2011 18:06:46 +0200, Jonathan M Davis >> >> >> wrote: >> > On Monday 18 July 2011 15:55:52 teo wrote: >> >> On Mon, 18 Jul 2011 10:26:27 -0400, Steven Schveighoffer wrote: >> >> > On Sun, 17 Jul 2011 15:29:02 -0400, teo >> >> > >> >> > wrote: >> >> >> It looks like std.concurrency.spawn does not accept delegates. Is >> >> >> there >> >> >> any reason for that? >> >> > >> >> > There is no type attached to the hidden 'this' pointer. So spawn >> >> >> >> cannot >> >> >> >> > guarantee it doesn't point to unshared data. >> >> > >> >> > -Steve >> >> >> >> Bad. I tried to pass as an argument a pointer to an instance of a >> >> class - >> >> a this pointer. That didn't work. >> > >> > Only stuff that's immutable or implicitly convertible immutable can >> > be passed >> > across threads using spawn and send. Otherwise, there's a risk of it >> > ending up >> > getting altered by both threads (or altered by one when the other one >> > is using >> > at it). Sometimes, that can be a bit restrictive (particularly when >> > you _know_ >> > that something isn't going to be altered by the thread sending it >> > after its >> > sent but the compiler doesn't), but it avoids all kinds of problems. >> > If you >> > want to send a class object across, then it needs to be immutable >> > (which tends >> > to be a bit of a pain to do for classes, since they need to have an >> > immutable >> > constructor, which is often a pain to do). >> >> It could be that assumeUnique should handle this, by transforming the >> delegate into something spawn() and friends could handle. >> >> Might be worth an enhancement request. > > There have been discussions about how to do it in the past. Whether > assumeUnique will work depends on whether casting to immutable(C) will > work (where C is the class' type), and I don't know whether that cast > will work or not. If it does, then assumeUnique will do it, since all it > does is cast to immutable, but it's the sort of thing that requires > language support. There _might_ be a way to solve the problem with some > sort of Unique template that spawn and send knew about, but nothing of > the sort has been done yet. But until a number of the issues with const > and immutable in the compiler have been sorted out, that sort of thing > would probably be problematic anyway. > > - Jonathan M Davis This is a bit too restrictive in my opinion. Only the shared data between two threads should be immutable. But the threads can access all sorts of mutable data as well. And in this case we are actually talking about the control function (or start routine) of a thread. As long as it's address is fixed within the memory of a process its usage for that purpose should be fine. Nobody is going to pass that address around. Am I missing anything here? When passing data between threads, it must be immutable. I have to jump in and correct you, nobody else has. You can also pass data marked as shared. A solution could be to cast the class as shared, pass it, then cast it back to unshared (ensuring you don't access the class from the originator anymore). This is not a compiler-enforced solution, but it gets the job done. But there is risk of concurrency errors if you don't do it right. My recommendation is to isolate the parts that create and pass the shared data. -Steve
Re: Problems building Qtd on Windows
Giving up... Tried 3 versions of qt + 2 of cmake + 2 of qtd. Is windows not supported anymore? Was it ever? I always hit that: http://dsource.org/projects/qtd/ticket/54
gtkD doesn't compile on windows
Giving up on qtD, I tried gtkD. Not much luck there either. As I've spent most of my day trying to compile qt, I'm not really in the mood to spend many hours trying to get gtk working. Is anybody actually using D for GUI development on Windows at all..? c:\d\ext\gtkd>\d\dsss-0.78-x86-windows\bin\dsss.exe build undemofy Creating imports for DD-atk Creating imports for DD-cairo Creating imports for DD-gdk Creating imports for DD-gdkpixbuf Creating imports for DD-gio Creating imports for DD-glade Creating imports for DD-glib Creating imports for DD-gobject Creating imports for DD-gthread Creating imports for DD-gtk Creating imports for DD-gtkc Creating imports for DD-pango atk => DD-atk DD-atk_static.rf: No such file or directory Command c:\d\dsss-0.78-x86-windows\bin\rebuild.exe returned with code 1, aborting. Error: Command failed, aborting.
Re: Problems building Qtd on Windows
On 19.07.2011 14:46, Trass3r wrote: Giving up... Tried 3 versions of qt + 2 of cmake + 2 of qtd. Is windows not supported anymore? Was it ever? I always hit that: http://dsource.org/projects/qtd/ticket/54 I made it "work" (read: compile and crash on application start) on Win7x86 a while ago. My problem was some programs build on Qt on the path before the SDK, so the wrong DLL was picked up.
Re: gtkD doesn't compile on windows
atk => DD-atk DD-atk_static.rf: No such file or directory Command c:\d\dsss-0.78-x86-windows\bin\rebuild.exe returned with code 1, aborting. Error: Command failed, aborting. Doesn't dsss have some kind of verbose mode? Did you try with another build tool?
Re: gtkD doesn't compile on windows
On 19.07.2011 15:12, Trass3r wrote: atk => DD-atk DD-atk_static.rf: No such file or directory Command c:\d\dsss-0.78-x86-windows\bin\rebuild.exe returned with code 1, aborting. Error: Command failed, aborting. Doesn't dsss have some kind of verbose mode? Did you try with another build tool? No verbose flag. What other build tool? rdmd still doesn't understand subfolders on windows, and it doesn't give good error messages: c:\d\ext\gtkd\demos\gtk>rdmd -v HelloWorld.d Failed: dmd -v -v -o- "HelloWorld.d" -I"." >HelloWorld.d.deps The dmd command works, so it's rdmd that fails.
Re: gtkD doesn't compile on windows
I built the fourth example (http://dsource.org/projects/gtkd/wiki/CodeExamples) using rdmd and it worked fine (regarding gtkD). (svn version of gtkD) There's a rdmd bug though. 'rdmd --build-only --chatty -I~/coding/gtkD/src/ -L-ldl test.d' doesn't directly work cause the .rsp file contains 'dmd'. But if you execute the command inside the .rsp it builds without problems.
Re: gtkD doesn't compile on windows
On 19.07.2011 15:29, Trass3r wrote: I built the fourth example (http://dsource.org/projects/gtkd/wiki/CodeExamples) using rdmd and it worked fine (regarding gtkD). (svn version of gtkD) There's a rdmd bug though. 'rdmd --build-only --chatty -I~/coding/gtkD/src/ -L-ldl test.d' doesn't directly work cause the .rsp file contains 'dmd'. But if you execute the command inside the .rsp it builds without problems. What is the command line? rdmd segfaults on me using this: c:\temp>rdmd --build-only --chatty -I\d\ext\gtkd\src t.d dmd -I\d\ext\gtkd\src -v -o- "t.d" -I"." >t.d.deps
Re: gtkD doesn't compile on windows
What is the command line? rdmd segfaults on me using this: c:\temp>rdmd --build-only --chatty -I\d\ext\gtkd\src t.d dmd -I\d\ext\gtkd\src -v -o- "t.d" -I"." >t.d.deps dmd -I~/coding/gtkD/src/ -L-ldl -v -o- 'test.d' -I'.' >test.d.deps dmd '@/tmp/.rdmd/rdmd.6FC1F920EA8D2136FC5ECC4E5ED4404A.rsp' with rsp containing: dmd -I~/coding/gtkD/src/ -L-ldl -of/tmp/.rdmd/tmp/test.d.6FC1F920EA8D2136FC5ECC4E5ED4404A -od/tmp/.rdmd/rdmd-test.d-6FC1F920EA8D2136FC5ECC4E5ED4404A -I. test.d ~/coding/gtkD/src/gdk/Cursor.d ~/coding/gtkD/src/gtk/Widget.d ~/coding/gtkD/src/gtk/Label.d ~/coding/gtkD/src/atk/StateSet.d ~/coding/gtkD/src/pango/PgEngineShape.d ~/coding/gtkD/src/gdk/Drawable.d ~/coding/gtkD/src/gtkc/gobjecttypes.d ~/coding/gtkD/src/pango/PgAttributeIterator.d ~/coding/gtkD/src/pango/PgContext.d ~/coding/gtkD/src/gtk/TextBuffer.d ~/coding/gtkD/src/gtk/VBox.d ~/coding/gtkD/src/gtk/TextTag.d ~/coding/gtkD/src/gtk/Main.d ~/coding/gtkD/src/gtk/ActivatableT.d ~/coding/gtkD/src/gtk/Builder.d ~/coding/gtkD/src/gtk/Clipboard.d ~/coding/gtkD/src/gtk/Tooltips.d ~/coding/gtkD/src/glib/Module.d ~/coding/gtkD/src/glib/Quark.d ~/coding/gtkD/src/gtk/RcStyle.d ~/coding/gtkD/src/gtkc/pango.d ~/coding/gtkD/src/pango/PgFontMap.d ~/coding/gtkD/src/gobject/Type.d ~/coding/gtkD/src/gdk/Rectangle.d ~/coding/gtkD/src/gdk/Font.d ~/coding/gtkD/src/gtk/ButtonBox.d ~/coding/gtkD/src/gtkc/gio.d ~/coding/gtkD/src/gtk/BuildableT.d ~/coding/gtkD/src/pango/PgFontFace.d ~/coding/gtkD/src/atk/ObjectAtk.d ~/coding/gtkD/src/pango/PgCoverage.d ~/coding/gtkD/src/pango/PgTabArray.d ~/coding/gtkD/src/atk/Relation.d ~/coding/gtkD/src/gtkc/gdkpixbuf.d ~/coding/gtkD/src/glib/GException.d ~/coding/gtkD/src/pango/PgFontMetrics.d ~/coding/gtkD/src/pango/PgLanguage.d ~/coding/gtkD/src/gtk/BuildableIF.d ~/coding/gtkD/src/gobject/ObjectG.d ~/coding/gtkD/src/gdk/Pixmap.d ~/coding/gtkD/src/pango/PgEngine.d ~/coding/gtkD/src/gdkpixbuf/PixbufAnimationIter.d ~/coding/gtkD/src/gtk/Box.d ~/coding/gtkD/src/gtkc/gthread.d ~/coding/gtkD/src/pango/PgFontset.d ~/coding/gtkD/src/gobject/Signals.d ~/coding/gtkD/src/gdk/Region.d ~/coding/gtkD/src/pango/PgLayoutLine.d ~/coding/gtkD/src/gtkc/atktypes.d ~/coding/gtkD/src/gtk/AboutDialog.d ~/coding/gtkD/src/gdk/Window.d ~/coding/gtkD/src/gtk/IconSource.d ~/coding/gtkD/src/gobject/Closure.d ~/coding/gtkD/src/glib/ListG.d ~/coding/gtkD/src/gtk/Container.d ~/coding/gtkD/src/gtkc/gobject.d ~/coding/gtkD/src/gdk/Visual.d ~/coding/gtkD/src/gtk/Window.d ~/coding/gtkD/src/gobject/TypeModule.d ~/coding/gtkD/src/glib/ListSG.d ~/coding/gtkD/src/gdk/Color.d ~/coding/gtkD/src/gdk/Display.d ~/coding/gtkD/src/gobject/Value.d ~/coding/gtkD/src/gdk/Bitmap.d ~/coding/gtkD/src/gobject/TypePlugin.d ~/coding/gtkD/src/gtkc/gtktypes.d ~/coding/gtkD/src/pango/PgFontFamily.d ~/coding/gtkD/src/gdk/Event.d ~/coding/gtkD/src/gtkc/giotypes.d ~/coding/gtkD/src/gdk/ImageGdk.d ~/coding/gtkD/src/gtk/IconSet.d ~/coding/gtkD/src/gtkc/glibtypes.d ~/coding/gtkD/src/gdk/Colormap.d ~/coding/gtkD/src/gtkc/pangotypes.d ~/coding/gtkD/src/gdk/GC.d ~/coding/gtkD/src/glib/ScannerG.d ~/coding/gtkD/src/gtk/WindowGroup.d ~/coding/gtkD/src/pango/PgLayoutIter.d ~/coding/gtkD/src/gtkc/gtk.d ~/coding/gtkD/src/gdk/Pixbuf.d ~/coding/gtkD/src/gtkc/gthreadtypes.d ~/coding/gtkD/src/pango/PgMatrix.d ~/coding/gtkD/src/gthread/Mutex.d ~/coding/gtkD/src/gtkc/cairotypes.d ~/coding/gtkD/src/gobject/ParamSpec.d ~/coding/gtkD/src/gio/IconT.d ~/coding/gtkD/src/gtkc/paths.d ~/coding/gtkD/src/glib/PtrArray.d ~/coding/gtkD/src/pango/PgAttributeList.d ~/coding/gtkD/src/gtk/Bin.d ~/coding/gtkD/src/gtk/TextAttributes.d ~/coding/gtkD/src/glib/ErrorG.d ~/coding/gtkD/src/gthread/Thread.d ~/coding/gtkD/src/gtk/ObjectGtk.d ~/coding/gtkD/src/gdk/Threads.d ~/coding/gtkD/src/gtk/TextIter.d ~/coding/gtkD/src/gtk/TargetList.d ~/coding/gtkD/src/pango/PgAttribute.d ~/coding/gtkD/src/pango/PgGlyphString.d ~/coding/gtkD/src/gtk/ActivatableIF.d ~/coding/gtkD/src/cairo/FontOption.d ~/coding/gtkD/src/gtk/Style.d ~/coding/gtkD/src/pango/PgFontDescription.d ~/coding/gtkD/src/gio/Cancellable.d ~/coding/gtkD/src/gdkpixbuf/PixbufFormat.d ~/coding/gtkD/src/glib/ConstructionException.d ~/coding/gtkD/src/gtkc/Loader.d ~/coding/gtkD/src/gtkc/cairo.d ~/coding/gtkD/src/gtkc/atk.d ~/coding/gtkD/src/gtkc/gdktypes.d ~/coding/gtkD/src/gobject/Flags.d ~/coding/gtkD/src/gio/AsyncResultIF.d ~/coding/gtkD/src/gtk/AccelGroup.d ~/coding/gtkD/src/gtk/Image.d ~/coding/gtkD/src/gtk/Action.d ~/coding/gtkD/src/gtk/Dialog.d ~/coding/gtkD/src/gtk/TextChildAnchor.d ~/coding/gtkD/src/gtk/VButtonBox.d ~/coding/gtkD/src/gtkc/gdk.d ~/coding/gtkD/src/gtkc/glib.d ~/coding/gtkD/src/gtk/TextTagTable.d ~/coding/gtkD/src/glib/MainContext.d ~/coding/gtkD/src/gio/Icon.d ~/coding/gtkD/src/pango/PgFont.d ~/coding/gtkD/src/glib/Str.d ~/coding/gtkD/src/gtkc/gdkpixbuftypes.d ~/coding/gtkD/src/gtk/OrientableT.d ~/coding/gtkD/
Re: gtkD doesn't compile on windows
On 19.07.2011 15:53, Trass3r wrote: What is the command line? rdmd segfaults on me using this: c:\temp>rdmd --build-only --chatty -I\d\ext\gtkd\src t.d dmd -I\d\ext\gtkd\src -v -o- "t.d" -I"." >t.d.deps dmd -I~/coding/gtkD/src/ -L-ldl -v -o- 'test.d' -I'.' >test.d.deps dmd '@/tmp/.rdmd/rdmd.6FC1F920EA8D2136FC5ECC4E5ED4404A.rsp' with rsp containing: (...) So your command line is simply "rdmd --build-only --chatty -I\d\ext\gtkd\src -L-ldl t.d"? rdmd calls "dmd -I\d\ext\gtkd\src -L-ldl -v -o- "t.d" -I"." >t.d.deps", and then segfaults (win7x64).
Re: gtkD doesn't compile on windows
simendsjo Wrote: > Giving up on qtD, I tried gtkD. Not much luck there either. As I've > spent most of my day trying to compile qt, I'm not really in the mood to > spend many hours trying to get gtk working. > > Is anybody actually using D for GUI development on Windows at all..? I use DFL, but that was mostly because I didn't want to depend on QT or GTK. But even DFL needs updates for the latest compiler and I haven't forked and pushed those I've made.
Re: gtkD doesn't compile on windows
So your command line is simply "rdmd --build-only --chatty -I\d\ext\gtkd\src -L-ldl t.d"? Yes, and in theory that would be enough. (if it didn't put 'dmd' in the .rsp) rdmd calls "dmd -I\d\ext\gtkd\src -L-ldl -v -o- "t.d" -I"." >t.d.deps", and then segfaults (win7x64). Doesn't segfault on Linux x64. You should compile a debug version of rdmd and see if you get a stacktrace. github.com/D-Programming-Language/tools
Up to date win32 bindings / d wrappers
There are several bindings for win32, but some seems quite dead. Juno - last updated 2009 http://dsource.org/projects/juno Bindings - last updated 2011 http://dsource.org/projects/bindings/wiki/WindowsApi Core32 - last updated 2009 http://dsource.org/projects/core32 Seems limited and outdated DWindowsProgramming - last updated 2011 https://github.com/AndrejMitrovic/DWindowsProgramming/tree/master/win32 Druntime https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/windows/windows.d Am I missing some projects? Does anyone know how complete/usable these bindings are? Compiles with newer dmd versions?
Re: gtkD doesn't compile on windows
On 19.07.2011 16:19, Trass3r wrote: So your command line is simply "rdmd --build-only --chatty -I\d\ext\gtkd\src -L-ldl t.d"? Yes, and in theory that would be enough. (if it didn't put 'dmd' in the .rsp) rdmd calls "dmd -I\d\ext\gtkd\src -L-ldl -v -o- "t.d" -I"." >t.d.deps", and then segfaults (win7x64). Doesn't segfault on Linux x64. You should compile a debug version of rdmd and see if you get a stacktrace. github.com/D-Programming-Language/tools I haven't found the bug, but compiling without optimizing doesn't crash it: c:\temp>rdmd --chatty -I\d\ext\gtkd\src t.d dmd -I\d\ext\gtkd\src -v -o- "t.d" -I"." >t.d.deps dmd "@C:\Users\simen\AppData\Local\Temp\.rdmd\rdmd.0B610F9A43C84525CA4F687638D0E F2B.rsp" Error: cannot read file dmd.d dmd.d...?
Re: gtkD doesn't compile on windows
dmd.d...? That's what I was talking about. it calls dmd @...rsp and rsp contains dmd again. So it in fact calls dmd dmd ... We should really get rid of the response file crap and call dmd directly. This would also clean up rdmd --dry-run
Re: gtkD doesn't compile on windows
On 19.07.2011 17:04, Trass3r wrote: dmd.d...? That's what I was talking about. it calls dmd @...rsp and rsp contains dmd again. So it in fact calls dmd dmd ... We should really get rid of the response file crap and call dmd directly. This would also clean up rdmd --dry-run I removed "compiler" from "todo = compiler ~ ... " (two places) in rebuild() and added the compiler name to the later run() instead. Solves the problem. Sorry I haven't made a pull request for rdmd; I have never used git before. The -L-ldl isn't recognized by optlink. OPTLINK : Warning 9: Unknown Option : LDL What's the equivalent? It tries to pick up zlib1.dll from my Intel WiFi program folder, and I cannot find it in the gtk or dmd folders.
Re: gtkD doesn't compile on windows
On 19.07.2011 17:23, simendsjo wrote: I removed "compiler" from "todo = compiler ~ ... " (two places) in rebuild() and added the compiler name to the later run() instead. Solves the problem. Sorry I haven't made a pull request for rdmd; I have never used git before. Seems I could use github direcly: https://github.com/D-Programming-Language/tools/pull/3
Re: gtkD doesn't compile on windows
The -L-ldl isn't recognized by optlink. OPTLINK : Warning 9: Unknown Option : LDL What's the equivalent? I think you don't need it on Windows. But according to the demo dsss.conf files you might need -lladvapi32 Might also be -L-Ladvapi32. It tries to pick up zlib1.dll from my Intel WiFi program folder, and I cannot find it in the gtk or dmd folders. Yep, it's installed system-wide on Linux.
Re: gtkD doesn't compile on windows
Seems I could use github direcly: https://github.com/D-Programming-Language/tools/pull/3 Thanks! But we should really also try to track down why rdmd crashes on Windows.
Re: gtkD doesn't compile on windows
On 19.07.2011 17:30, Trass3r wrote: The -L-ldl isn't recognized by optlink. OPTLINK : Warning 9: Unknown Option : LDL What's the equivalent? I think you don't need it on Windows. But according to the demo dsss.conf files you might need -lladvapi32 Might also be -L-Ladvapi32. It tries to pick up zlib1.dll from my Intel WiFi program folder, and I cannot find it in the gtk or dmd folders. Yep, it's installed system-wide on Linux. Downloaded from zlib.net, and the sample works now. Thanks! There is something wrong with either dmd or rdmd though.. If I compile rdmd (with my patch, haven't tried the original) without -g, it crashes when trying to compile anything...
Re: gtkD doesn't compile on windows
There is something wrong with either dmd or rdmd though.. If I compile rdmd (with my patch, haven't tried the original) without -g, it crashes when trying to compile anything... Does this also happen if you compile it with -g and then run cv2pdb on it?
Re: gtkD doesn't compile on windows
On 19.07.2011 17:53, Trass3r wrote: There is something wrong with either dmd or rdmd though.. If I compile rdmd (with my patch, haven't tried the original) without -g, it crashes when trying to compile anything... Does this also happen if you compile it with -g and then run cv2pdb on it? I cannot compile anything without first compiling rdmd with -g. Compiling rdmd with -g and running cv2pdb on it works.
Re: gtkD doesn't compile on windows
On 07/19/2011 03:21 PM, simendsjo wrote: On 19.07.2011 15:12, Trass3r wrote: atk => DD-atk DD-atk_static.rf: No such file or directory dsss should generate this file. Command c:\d\dsss-0.78-x86-windows\bin\rebuild.exe returned with code 1, aborting. Error: Command failed, aborting. Doesn't dsss have some kind of verbose mode? Did you try with another build tool? No verbose flag. What other build tool? dsss uses -v for verbose output. rdmd still doesn't understand subfolders on windows, and it doesn't give good error messages: c:\d\ext\gtkd\demos\gtk>rdmd -v HelloWorld.d Failed: dmd -v -v -o- "HelloWorld.d" -I"." >HelloWorld.d.deps The dmd command works, so it's rdmd that fails. -- Mike Wey
D and MySQL
I do quite a bit of work with MySQL. I can't seem to find any information on how to use D with MySQL. Is there a tutorial or example around that someone can point me to?
Re: std.concurrency.spawn does not accept delegates
On 2011-07-19 05:40, Steven Schveighoffer wrote: > On Mon, 18 Jul 2011 18:39:01 -0400, Jonathan M Davis > > wrote: > > On 2011-07-18 15:15, teo wrote: > >> On Mon, 18 Jul 2011 18:14:45 +, Jonathan M Davis wrote: > >> > On 2011-07-18 10:54, Simen Kjaeraas wrote: > >> >> On Mon, 18 Jul 2011 18:06:46 +0200, Jonathan M Davis > >> >> > >> >> > >> >> wrote: > >> >> > On Monday 18 July 2011 15:55:52 teo wrote: > >> >> >> On Mon, 18 Jul 2011 10:26:27 -0400, Steven Schveighoffer wrote: > >> >> >> > On Sun, 17 Jul 2011 15:29:02 -0400, teo > >> >> >> > > >> >> >> > wrote: > >> >> >> >> It looks like std.concurrency.spawn does not accept delegates. > >> > >> Is > >> > >> >> >> >> there > >> >> >> >> any reason for that? > >> >> >> > > >> >> >> > There is no type attached to the hidden 'this' pointer. So spawn > >> >> >> > >> >> >> cannot > >> >> >> > >> >> >> > guarantee it doesn't point to unshared data. > >> >> >> > > >> >> >> > -Steve > >> >> >> > >> >> >> Bad. I tried to pass as an argument a pointer to an instance of a > >> >> >> class - > >> >> >> a this pointer. That didn't work. > >> >> > > >> >> > Only stuff that's immutable or implicitly convertible immutable can > >> >> > be passed > >> >> > across threads using spawn and send. Otherwise, there's a risk of > >> > >> it > >> > >> >> > ending up > >> >> > getting altered by both threads (or altered by one when the other > >> > >> one > >> > >> >> > is using > >> >> > at it). Sometimes, that can be a bit restrictive (particularly when > >> >> > you _know_ > >> >> > that something isn't going to be altered by the thread sending it > >> >> > after its > >> >> > sent but the compiler doesn't), but it avoids all kinds of > >> > >> problems. > >> > >> >> > If you > >> >> > want to send a class object across, then it needs to be immutable > >> >> > (which tends > >> >> > to be a bit of a pain to do for classes, since they need to have an > >> >> > immutable > >> >> > constructor, which is often a pain to do). > >> >> > >> >> It could be that assumeUnique should handle this, by transforming the > >> >> delegate into something spawn() and friends could handle. > >> >> > >> >> Might be worth an enhancement request. > >> > > >> > There have been discussions about how to do it in the past. Whether > >> > assumeUnique will work depends on whether casting to immutable(C) will > >> > work (where C is the class' type), and I don't know whether that cast > >> > will work or not. If it does, then assumeUnique will do it, since all > >> > >> it > >> > >> > does is cast to immutable, but it's the sort of thing that requires > >> > language support. There _might_ be a way to solve the problem with > >> > >> some > >> > >> > sort of Unique template that spawn and send knew about, but nothing of > >> > the sort has been done yet. But until a number of the issues with > >> > >> const > >> > >> > and immutable in the compiler have been sorted out, that sort of thing > >> > would probably be problematic anyway. > >> > > >> > - Jonathan M Davis > >> > >> This is a bit too restrictive in my opinion. Only the shared data > >> between > >> two threads should be immutable. But the threads can access all sorts of > >> mutable data as well. And in this case we are actually talking about the > >> control function (or start routine) of a thread. As long as it's address > >> is fixed within the memory of a process its usage for that purpose > >> should > >> be fine. Nobody is going to pass that address around. Am I missing > >> anything here? > > > > When passing data between threads, it must be immutable. > > I have to jump in and correct you, nobody else has. > > You can also pass data marked as shared. > > A solution could be to cast the class as shared, pass it, then cast it > back to unshared (ensuring you don't access the class from the originator > anymore). > > This is not a compiler-enforced solution, but it gets the job done. But > there is risk of concurrency errors if you don't do it right. My > recommendation is to isolate the parts that create and pass the shared > data. I thought that spawn and send disallowed shared and that you had to deal with shared separately, but if that's not the case, then that's not the case. Regardless, you can't just pass anything with spawn or send (as the OP seems to be trying to do). They have restrictions to avoid concurrency bugs. - Jonathan M Davis
Re: D and MySQL
http://prowiki.org/wiki4d/wiki.cgi?DatabaseBindings There is some information, but it's probably outdated. Please update that wiki once you know more :) Apart from that I only know of this binding: http://dsource.org/projects/ddbi
Re: D and MySQL
I wrapped the libmysql C library in D and use it in a lot
of my apps.
https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff
Grab database.d and mysql.d from there.
To use it:
===
import arsd.mysql;
void main() {
auto mysql = new MySql("localhost", "username", "password", "database name");
// ? based placeholders do conversion and escaping for you
foreach(line; mysql.query("select id, name from users where id > ?", 5)) {
// access to columns by name
writefln("%s: %s", line["id"], line["name"]);
// alternatively, you can write:
writefln("%s: %s", line[0], line[1]);
}
}
===
There's a lot of other stuff in there too, which I'll
write up in the next week or so... but this is the basics of it.
Re: gtkD doesn't compile on windows
I cannot compile anything without first compiling rdmd with -g. Compiling rdmd with -g and running cv2pdb on it works. Really strange. If we just had a stack trace.
Re: D and MySQL
Am 19.07.2011, 20:49 Uhr, schrieb Adam Ruppe :
foreach(line; mysql.query("select id, name from users where id > ?",
5)) {
// access to columns by name
writefln("%s: %s", line["id"], line["name"]);
// alternatively, you can write:
writefln("%s: %s", line[0], line[1]);
}
I guess access via opDispatch would also be nice to have?!
Re: std.concurrency.spawn does not accept delegates
On Tue, 19 Jul 2011 14:31:19 -0400, Jonathan M Davis wrote: On 2011-07-19 05:40, Steven Schveighoffer wrote: On Mon, 18 Jul 2011 18:39:01 -0400, Jonathan M Davis I have to jump in and correct you, nobody else has. You can also pass data marked as shared. A solution could be to cast the class as shared, pass it, then cast it back to unshared (ensuring you don't access the class from the originator anymore). This is not a compiler-enforced solution, but it gets the job done. But there is risk of concurrency errors if you don't do it right. My recommendation is to isolate the parts that create and pass the shared data. I thought that spawn and send disallowed shared and that you had to deal with shared separately, but if that's not the case, then that's not the case. Regardless, you can't just pass anything with spawn or send (as the OP seems to be trying to do). They have restrictions to avoid concurrency bugs. send requires the data pass this test: !hasLocalAliasing!(T) which maps to: http://www.digitalmars.com/d/2.0/phobos/std_traits.html#hasUnsharedAliasing So yes, you can pass shared data. However, there is still no sanctioned way to "pass and forget" mutable unique thread-local data. That is, you pass data to another thread, and it becomes local to that other thread instead of to the thread passed from. You are correct that you can't just pass anything (i.e. thread-local mutable data), but in some cases, you have to force the issue. Just because the compiler can't prove it's valid doesn't mean it isn't. But it's definitely opening up a possibility for concurrency bugs. -Steve
Re: D and MySQL
Trass3r wrote:
> I guess access via opDispatch would also be nice to have?!
Use mysql.queryDataObject() for that.
foreach(line; mysql.queryDataObject(...rest is the same...) {
writeln(line.id, line.name);
//line["id"]
//line["name"]
}
all work. But with the DataObject, you don't have integer indexes.
You can also foreach(name, value; line) to go over the returned fields, just
like
with an associative array.
What you gain though is write support:
line.name = "something else";
line.commitChanges(); // does an update
You can also create new DataObjects:
auto obj = new DataObject(mysql, "users");
obj.id = 10;
obj.name = "My Name";
obj.commitChanges(); // does a select. if empty, inserts. if not, updates.
The DataObject is found in database.d - it is meant to work generically with any
database backend.
Re: gtkD doesn't compile on windows
On 19.07.2011 20:01, Mike Wey wrote: On 07/19/2011 03:21 PM, simendsjo wrote: On 19.07.2011 15:12, Trass3r wrote: atk => DD-atk DD-atk_static.rf: No such file or directory dsss should generate this file. But it doesn't. Command c:\d\dsss-0.78-x86-windows\bin\rebuild.exe returned with code 1, aborting. Error: Command failed, aborting. Doesn't dsss have some kind of verbose mode? Did you try with another build tool? No verbose flag. What other build tool? dsss uses -v for verbose output. Unrecognized argument: -v rdmd still doesn't understand subfolders on windows, and it doesn't give good error messages: c:\d\ext\gtkd\demos\gtk>rdmd -v HelloWorld.d Failed: dmd -v -v -o- "HelloWorld.d" -I"." >HelloWorld.d.deps The dmd command works, so it's rdmd that fails.
Re: gtkD doesn't compile on windows
On 19.07.2011 20:46, Trass3r wrote: I cannot compile anything without first compiling rdmd with -g. Compiling rdmd with -g and running cv2pdb on it works. Really strange. If we just had a stack trace. Whats the best way to debug this? Sprinkle printf's around?
Re: gtkD doesn't compile on windows
Whats the best way to debug this? Sprinkle printf's around? Probably. Should happen in that getDependencies function, shouldn't it?
Re: gtkD doesn't compile on windows
On 19.07.2011 21:58, Trass3r wrote:
Whats the best way to debug this? Sprinkle printf's around?
Probably. Should happen in that getDependencies function, shouldn't it?
It fails on the return statement in getDependencies.
It never gets to the line after getDependencies in main.
Someone want to look at the assembly? The .exe is to large for the
newsgroup, so only the code is attached. I've only tried compiling with
dmd 2.054
// Written in the D programming language.
import std.algorithm, std.array, std.c.stdlib, std.datetime,
std.exception, std.file, std.getopt,
std.md5, std.path, std.process, std.regexp,
std.stdio, std.string, std.typetuple;
version (Posix)
{
enum objExt = ".o";
enum binExt = "";
}
else version (Windows)
{
import std.c.windows.windows;
extern(Windows) HINSTANCE ShellExecuteA(HWND, LPCSTR, LPCSTR, LPCSTR,
LPCSTR, INT);
enum objExt = ".obj";
enum binExt = ".exe";
}
else
{
static assert(0, "Unsupported operating system.");
}
private bool chatty, buildOnly, dryRun, force;
private string exe, compiler = "dmd";
int main(string[] args)
{
//writeln("Invoked with: ", map!(q{a ~ ", "})(args));
if (args.length > 1 && std.algorithm.startsWith(args[1],
"--shebang ", "--shebang="))
{
// multiple options wrapped in one
auto a = args[1]["--shebang ".length .. $];
args = args[0 .. 1] ~ std.string.split(a) ~ args[2 .. $];
}
// Continue parsing the command line; now get rdmd's own arguments
// parse the -o option
void dashOh(string key, string value)
{
if (value[0] == 'f')
{
// -ofmyfile passed
exe = value[1 .. $];
}
else if (value[0] == 'd')
{
// -odmydir passed
if(!exe) // Don't let -od override -of
{
// add a trailing path separator to clarify it's a dir
exe = value[1 .. $];
if (!std.algorithm.endsWith(exe, std.path.sep[]))
{
exe ~= std.path.sep[];
}
assert(std.algorithm.endsWith(exe, std.path.sep[]));
}
}
else if (value[0] == '-')
{
// -o- passed
enforce(false, "Option -o- currently not supported by rdmd");
}
else
{
enforce(false, "Unrecognized option: "~key~value);
}
}
// start the web browser on documentation page
void man()
{
version(Windows)
{
// invoke browser that is associated with the http protocol
ShellExecuteA(null, "open",
"http://www.digitalmars.com/d/2.0/rdmd.html";, null, null, SW_SHOWNORMAL);
}
else
{
foreach (b; [ std.process.getenv("BROWSER"), "firefox",
"sensible-browser", "x-www-browser" ]) {
if (!b.length) continue;
if (!system(b~" http://www.digitalmars.com/d/2.0/rdmd.html";))
return;
}
}
}
auto programPos = indexOfProgram(args);
// Insert "--" to tell getopts when to stop
args = args[0..programPos] ~ "--" ~ args[programPos .. $];
bool bailout;// bailout set by functions called in getopt if
// program should exit
string[] loop; // set by --loop
bool addStubMain;// set by --main
string[] eval; // set by --eval
bool makeDepend;
getopt(args,
std.getopt.config.caseSensitive,
std.getopt.config.passThrough,
std.getopt.config.stopOnFirstNonOption,
"build-only", &buildOnly,
"chatty", &chatty,
"compiler", &compiler,
"dry-run", &dryRun,
"eval", &eval,
"loop", &loop,
"force", &force,
"help", (string) { writeln(helpString); bailout = true; },
"main", &addStubMain,
"makedepend", &makeDepend,
"man", (string) { man; bailout = true; },
"o", &dashOh);
if (bailout) return 0;
if (dryRun) chatty = true; // dry-run implies chatty
// Just evaluate this program!
if (loop)
{
return .eval(importWorld ~ "void main(char[][] args) { "
~ "foreach (line; stdin.byLine()) {\n"
~ std.string.join(loop, "\n")
~ ";\n} }");
}
if (eval)
{
return .eval(importWorld ~ "void main(char[][] args) {\n"
~ std.string.join(eval, "\n") ~ ";\n}");
}
// Parse the program line - first find the program to run
programPos = indexOfProgram(args);
if (programPos == args.length)
{
write(helpString);
return 1;
}
auto
root = /*rel2abs*/(chomp(args[programPos], ".d") ~ ".d"),
exeBasename = basename(root, ".d"),
exeDirname = dirname(root),
programArg
Re: Scope of lambdas and closures
== Quote from Daniel Murphy (yebbl...@nospamgmail.com)'s article
> That would be http://d.puremagic.com/issues/show_bug.cgi?id=2634
Thanks,
Is there a related/same reason why this don't compile?
unittest {
static void stuff(){}
static void function()[string] functions = [ "stuff":&stuff ];
}
Cheers,
-r-
Re: gtkD doesn't compile on windows
Someone want to look at the assembly? The .exe is to large for the newsgroup, so only the code is attached. I've only tried compiling with dmd 2.054 Maybe you could post only rdmd.obj?
Re: std.concurrency.spawn does not accept delegates
On Tue, 19 Jul 2011 18:31:19 +, Jonathan M Davis wrote: > On 2011-07-19 05:40, Steven Schveighoffer wrote: >> On Mon, 18 Jul 2011 18:39:01 -0400, Jonathan M Davis >> >> >> wrote: >> > On 2011-07-18 15:15, teo wrote: >> >> On Mon, 18 Jul 2011 18:14:45 +, Jonathan M Davis wrote: >> >> > On 2011-07-18 10:54, Simen Kjaeraas wrote: >> >> >> On Mon, 18 Jul 2011 18:06:46 +0200, Jonathan M Davis >> >> >> >> >> >> >> >> >> wrote: >> >> >> > On Monday 18 July 2011 15:55:52 teo wrote: >> >> >> >> On Mon, 18 Jul 2011 10:26:27 -0400, Steven Schveighoffer >> >> >> >> wrote: >> >> >> >> > On Sun, 17 Jul 2011 15:29:02 -0400, teo >> >> >> >> > >> >> >> >> > >> >> >> >> > wrote: >> >> >> >> >> It looks like std.concurrency.spawn does not accept >> >> >> >> >> delegates. >> >> >> >> Is >> >> >> >> >> >> >> there >> >> >> >> >> any reason for that? >> >> >> >> > >> >> >> >> > There is no type attached to the hidden 'this' pointer. So >> >> >> >> > spawn >> >> >> >> >> >> >> >> cannot >> >> >> >> >> >> >> >> > guarantee it doesn't point to unshared data. >> >> >> >> > >> >> >> >> > -Steve >> >> >> >> >> >> >> >> Bad. I tried to pass as an argument a pointer to an instance >> >> >> >> of a class - >> >> >> >> a this pointer. That didn't work. >> >> >> > >> >> >> > Only stuff that's immutable or implicitly convertible immutable >> >> >> > can be passed >> >> >> > across threads using spawn and send. Otherwise, there's a risk >> >> >> > of >> >> >> >> it >> >> >> >> >> > ending up >> >> >> > getting altered by both threads (or altered by one when the >> >> >> > other >> >> >> >> one >> >> >> >> >> > is using >> >> >> > at it). Sometimes, that can be a bit restrictive (particularly >> >> >> > when you _know_ >> >> >> > that something isn't going to be altered by the thread sending >> >> >> > it after its >> >> >> > sent but the compiler doesn't), but it avoids all kinds of >> >> >> >> problems. >> >> >> >> >> > If you >> >> >> > want to send a class object across, then it needs to be >> >> >> > immutable (which tends >> >> >> > to be a bit of a pain to do for classes, since they need to >> >> >> > have an immutable >> >> >> > constructor, which is often a pain to do). >> >> >> >> >> >> It could be that assumeUnique should handle this, by transforming >> >> >> the delegate into something spawn() and friends could handle. >> >> >> >> >> >> Might be worth an enhancement request. >> >> > >> >> > There have been discussions about how to do it in the past. >> >> > Whether assumeUnique will work depends on whether casting to >> >> > immutable(C) will work (where C is the class' type), and I don't >> >> > know whether that cast will work or not. If it does, then >> >> > assumeUnique will do it, since all >> >> >> >> it >> >> >> >> > does is cast to immutable, but it's the sort of thing that >> >> > requires language support. There _might_ be a way to solve the >> >> > problem with >> >> >> >> some >> >> >> >> > sort of Unique template that spawn and send knew about, but >> >> > nothing of the sort has been done yet. But until a number of the >> >> > issues with >> >> >> >> const >> >> >> >> > and immutable in the compiler have been sorted out, that sort of >> >> > thing would probably be problematic anyway. >> >> > >> >> > - Jonathan M Davis >> >> >> >> This is a bit too restrictive in my opinion. Only the shared data >> >> between >> >> two threads should be immutable. But the threads can access all >> >> sorts of mutable data as well. And in this case we are actually >> >> talking about the control function (or start routine) of a thread. >> >> As long as it's address is fixed within the memory of a process its >> >> usage for that purpose should >> >> be fine. Nobody is going to pass that address around. Am I missing >> >> anything here? >> > >> > When passing data between threads, it must be immutable. >> >> I have to jump in and correct you, nobody else has. >> >> You can also pass data marked as shared. >> >> A solution could be to cast the class as shared, pass it, then cast it >> back to unshared (ensuring you don't access the class from the >> originator anymore). >> >> This is not a compiler-enforced solution, but it gets the job done. But >> there is risk of concurrency errors if you don't do it right. My >> recommendation is to isolate the parts that create and pass the shared >> data. > > I thought that spawn and send disallowed shared and that you had to deal > with shared separately, but if that's not the case, then that's not the > case. Regardless, you can't just pass anything with spawn or send (as > the OP seems to be trying to do). They have restrictions to avoid > concurrency bugs. > > - Jonathan M Davis Well, I tried to pass a this pointer, because I wasn't able to use a delegate as a control function of the thread. All I need is access to the data within a class instance. That isn't static data. Basically I have an object which encapsulates the access to some reso
Re: gtkD doesn't compile on windows
On 07/19/2011 09:17 PM, simendsjo wrote: On 19.07.2011 20:01, Mike Wey wrote: On 07/19/2011 03:21 PM, simendsjo wrote: On 19.07.2011 15:12, Trass3r wrote: Command c:\d\dsss-0.78-x86-windows\bin\rebuild.exe returned with code 1, aborting. Error: Command failed, aborting. Doesn't dsss have some kind of verbose mode? Did you try with another build tool? No verbose flag. What other build tool? dsss uses -v for verbose output. Unrecognized argument: -v Odd "dsss build -v" works just fine here. -- Mike Wey
Re: D and MySQL
The DataObject is found in database.d - it is meant to work generically with any database backend. Damn, we should really have a common project for database stuff.
Re: Up to date win32 bindings / d wrappers
http://dsource.org/projects/bindings/wiki/WindowsApi are the bindings, they're not mine though. DWindowsProgramming is about the Programming Windows book by Charles Petzold and has many examples of using GDI/Windows API with D. I'm distributing WindowsApi with it. WindowsApi should be the most up-to-date bindings.
Re: Problems building Qtd on Windows
I had a bunch of runtime crashes when I last used QtD, and I've reported this. But QtD seems to be staling again, there's hardly anyone working on it. And how can anyone work on it when the porting process is not documented..
calling D2 routines from C routines on linux
Actually, the C routines are there purely as a link to Python, but ... To me the problem appears to be that I don't know how to initialize the D system when it's not a main program, and I don't know what needs to be linked. To me it seems like this should be written up in the documentation, but there are problems because different systems would use different commands for the linking, (And for the compilation of the non-D classes.) There's a short writeup on how to call D from C++, but it's not enough to actually DO it. It doesn't tell how to initialize the D environment, e.g., or what libraries need to be linked. (phobos, yes, but it that all? And would you need it even if you didn't use phobos?) That said, I got this working a few years ago with D1, but is D2 the same? It seems quite different in many ways.
Re: calling D2 routines from C routines on linux
See if this works for you:
import core.runtime;
void myMainFunc()
{
}
extern (C)
int initializeDee()
{
int result;
void exceptionHandler(Throwable e) { throw e; }
try
{
Runtime.initialize(&exceptionHandler);
result = myMainFunc();
Runtime.terminate(&exceptionHandler);
}
catch (Throwable o)
{
result = 0;
}
return result;
}
This is similar to how it's done for Windows GUI applications, where
we have to manually run the initialize function in druntime (unless
it's hidden by some GUI framework).
skip(N) range
Is there a skip() function for ranges? I need to skip N elements of a range and then take M elements. Something like writeln(take(range, 10), ": ", take(skip(range, 10), 10)); Thanks
Re: calling D2 routines from C routines on linux
On 07/19/2011 04:48 PM, Andrej Mitrovic wrote:
See if this works for you:
import core.runtime;
void myMainFunc()
{
}
extern (C)
int initializeDee()
{
int result;
void exceptionHandler(Throwable e) { throw e; }
try
{
Runtime.initialize(&exceptionHandler);
result = myMainFunc();
Runtime.terminate(&exceptionHandler);
}
catch (Throwable o)
{
result = 0;
}
return result;
}
This is similar to how it's done for Windows GUI applications, where
we have to manually run the initialize function in druntime (unless
it's hidden by some GUI framework).
Thank you. It looks good, and I *will* be trying it. But my main point
was that it needs to be in the documentation. (And notice that you
still didn't say what libraries need to be linked, or that none do.)
I understand that most of the documentation is not specific to operating
systems. And that's good. But where you *need* information about the
operating system, the information needs to be there, just like the
compiler options which differ between Linux and MSWind are documented
differently.
And yes, what you displayed (i.e., the code) should be identical between
OSes. But that's only the majority of the information needed. I think
I could figure it out by checking what worked the last time I did it,
even though that was with D1, but it really should be in the
documentation. So, for that matter, should the code. If I knew where
to post the request, I'd post it there, but as it is I'm just hoping
that an appropriate person will read this and act on it.
Re: calling D2 routines from C routines on linux
I notice I've skipped the main reason.
What I'd like to do is build libraries in D that I can call from
multiple languages. C, Python, C++, Ada, Fortran, Lisp, whatever. Just
about every language has a C interface. So if I can call the library
from C, then I can call it from anywhere. (Possibly except D. Not sure
about that, but I think the runtime functions might clash.)
On 07/19/2011 04:48 PM, Andrej Mitrovic wrote:
See if this works for you:
import core.runtime;
void myMainFunc()
{
}
extern (C)
int initializeDee()
{
int result;
void exceptionHandler(Throwable e) { throw e; }
try
{
Runtime.initialize(&exceptionHandler);
result = myMainFunc();
Runtime.terminate(&exceptionHandler);
}
catch (Throwable o)
{
result = 0;
}
return result;
}
This is similar to how it's done for Windows GUI applications, where
we have to manually run the initialize function in druntime (unless
it's hidden by some GUI framework).
Re: skip(N) range
On 2011-07-19 17:29, Adam Wey wrote: > Is there a skip() function for ranges? I need to skip N elements of a range > and then take M elements. Something like > > writeln(take(range, 10), ": ", take(skip(range, 10), 10)); No, but this pull request https://github.com/D-Programming-Language/phobos/pull/147 will introduce the drop function which does that. It hasn't been merged in yet though. The closest that there is right now is to call popFrontN, but you can't do that in the middle of an expression like that. - Jonathan M Davis
Re: skip(N) range
Adam Wey Wrote: > Is there a skip() function for ranges? I need to skip N elements of a range > and then take M elements. Something like > > writeln(take(range, 10), ": ", take(skip(range, 10), 10)); > > Thanks There is popFrontN http://d-programming-language.org/phobos/std_range.html#popFrontN
Re: Scope of lambdas and closures
"Rolv Seehuus" wrote in message
news:j04qff$i4s$1...@digitalmars.com...
> Is there a related/same reason why this don't compile?
>
> unittest {
> static void stuff(){}
> static void function()[string] functions = [ "stuff":&stuff ];
> }
That compiles for me.
Re: calling D2 routines from C routines on linux
On Tue, Jul 19, 2011 at 6:48 PM, Andrej Mitrovic wrote: > > This is similar to how it's done for Windows GUI applications, where > we have to manually run the initialize function in druntime (unless > it's hidden by some GUI framework). > What? I've never needed to do that when compiling programs with -L/exet:nt/su:windows:4.0 on Windows.
Re: calling D2 routines from C routines on linux
On 7/20/11, Jimmy Cao wrote:
> What? I've never needed to do that when compiling programs with
> -L/exet:nt/su:windows:4.0
> on Windows.
>
If you use a main() function, DMD will add the runtime stuff for you.
But if you use WinMain as your main function, you have to initialize
manually.
For example, if you try to compile and run this app:
module win;
import core.runtime;
import std.c.windows.windows;
extern (Windows)
int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int iCmdShow)
{
int[] a;
a.length = 5000;
auto b = a[];
return 1;
}
> dmd win.d -L/exet:nt/su:windows:4.0 && win.exe
You'll see that it crashes:
---
win.exe - Application Error
---
The instruction at "0x00407cf6" referenced memory at "0x". The
memory could not be "read".
Click on OK to terminate the program
Click on CANCEL to debug the program
---
OK Cancel
---
Re: calling D2 routines from C routines on linux
Oh, I see.
That's very convenient.
On Wed, Jul 20, 2011 at 12:04 AM, Andrej Mitrovic <
andrej.mitrov...@gmail.com> wrote:
> On 7/20/11, Jimmy Cao wrote:
> > What? I've never needed to do that when compiling programs with
> > -L/exet:nt/su:windows:4.0
> > on Windows.
> >
>
> If you use a main() function, DMD will add the runtime stuff for you.
> But if you use WinMain as your main function, you have to initialize
> manually.
>
> For example, if you try to compile and run this app:
>
> module win;
>
> import core.runtime;
> import std.c.windows.windows;
>
> extern (Windows)
> int WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
> lpCmdLine, int iCmdShow)
> {
>int[] a;
>
>a.length = 5000;
>auto b = a[];
>
>return 1;
> }
>
> > dmd win.d -L/exet:nt/su:windows:4.0 && win.exe
>
> You'll see that it crashes:
> ---
> win.exe - Application Error
> ---
> The instruction at "0x00407cf6" referenced memory at "0x". The
> memory could not be "read".
>
>
> Click on OK to terminate the program
> Click on CANCEL to debug the program
> ---
> OK Cancel
> ---
>
Function template type parameter inference
I noticed in the D spec it states that
"Function template type parameters that are to be implicitly deduced may not
have
specializations"
However, the following code works:
void Foo(T : double)(T t) { writefln("%f",t+2); }
...
Foo(5.5);
I was wondering if this is behavior that can be relied upon, or if it may change
in the future? Or am I misreading things?
