Re: LINK : fatal error LNK1104: cannot open file '_CMDLINE' --- errorlevel 1104
On Monday, 11 January 2016 at 23:26:51 UTC, Tobi G. wrote: On Monday, 11 January 2016 at 20:19:50 UTC, Jason Jeffory wrote: Sheesh, why is it so hard to do simple stuff? 1) Have you tryed passing --arch=x86_64 to dub? 2) > "versions-x86_64": ["XYZ"] This is like a architecture dependent condition for version definition. So if your project will be compiled for the architecture x86_64 the version XYZ will be defined in your code. togrue Yeah, I realized that after the fact. I saw that in some post and tried it. couldn't find anything in the dub docs that explain how to compile for x64... I want to specify in the json. I don't want to have to remember a command to compile for the same arch every time. In fact, I'd like to have two profiles for dub... one for 32-bit and one for 64-bit.
Re: LINK : fatal error LNK1104: cannot open file '_CMDLINE' --- errorlevel 1104
On Tuesday, 12 January 2016 at 01:26:06 UTC, Mike Parker wrote:
On Monday, 11 January 2016 at 20:19:50 UTC, Jason Jeffory wrote:
On Monday, 11 January 2016 at 20:17:23 UTC, Jason Jeffory
wrote:
Any ideas? Happens when I do a very simple dub project and
try to compile using the MS linker(x86 but set in sc.ini or
64). I'm linking in glfw(using correct arch of course)
{
"name": "Test",
"description": "A minimal D application.",
"copyright": "Copyright © 2016, Jason",
"authors": ["Jason"],
"lflags" : ["+C:\\Dlang\\Libs\\glfw3.lib"],
"dflags-dmd": [""],
"versions-x86_64": ["UseAmd64Impl"],
"dependencies": {
}
}
seems "versions-x86_64": ["UseAmd64Impl"],
doesn't actually make it 64
**
Performing "debug" build using dmd for x86.
midimonitor ~master: building configuration "application"...
Linking...
Microsoft (R) Incremental Linker Version 14.00.23506.0
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : fatal error LNK1104: cannot open file '_CMDLINE'
--- errorlevel 1104
dmd failed with exit code 1104.
Sheesh, why is it so hard to do simple stuff?
There's nothing hard about it. It's just a matter of learning
what's what.
Um, if there was proper documentation, this wouldn't be a problem.
First, don't set 32/64-bit compilation in sc.ini. In fact, you
should generally never touch sc.ini (more on that below). If
you are calling DMD directly, just pass -m64 on the command
line. If you are using DUB, pass -ax86_64 on the command line.
I don't set that in sc.ini, but you have to set the correct
paths. It works fine with VS/VD.
I also don't want to pass a command line to dub. Too much work.
What if I forget? What about the correct libs? What if I forget
to type dub -ax86_64 and it tries to compile in the 64-bit lib in
the lib's path in sc.ini?(yes, it needs to be edited for global
library locations).
Second, you don't need to set your own version flag for 64-bit.
Both x86_64 and Win64 are already predefined [1]. The latter is
only defined on when compiling for 64-bit Windows (Win32 is
only defined when compiling for 32-bit Windows, unlike in the C
world where the #defined _WIN32 means the Win32 API is
available). Should you need to, you can also distinguish
between the two Windows runtimes via the CRuntime_DigitalMars
and CRuntime_Microsoft versions.
This was a mistake, because I got the wrong info from some forum
post that was wrong.
So, how do I set the json to compile for x64?
Error in 'The D Programming Language' (2010)?
I have copied more or less verbatim an example from The D
Programming Language, under 1.4.3 Counting Frequencies. Lambda
Functions
This is the code
import std.stdio,
std.string;
void main()
{
uint[string] freqs;
// Compute counts
foreach (line; stdin.byLine())
{
foreach (word; split(strip(line)))
{
++freqs[word.idup];
}
}
// Print counts
string[] words = freqs.keys;
sort!((a, b) { return freqs[a] > freqs[b]; })(words); // won't
compile
foreach (word; words)
{
writefln("%6u\t%s", freqs[word], words);
}
}
Both DMD and GDC complain, saying
Error: template instance sort!((a, b)
{
return freqs[a] > freqs[b];
}
) template 'sort' is not defined
Have I made a mistake, or has the D syntax perhaps changed since
the book was published?
I don't understand this functional voodoo stuff, so I don't have
the faintest clue how to fix it myself
Anyone know how to fix this?
Re: Error in 'The D Programming Language' (2010)?
On Tuesday, 12 January 2016 at 00:36:15 UTC, Ali Çehreli wrote:
On 01/11/2016 04:28 PM, asdfa wrote:
> Both DMD and GDC complain, saying
> Error: template instance sort!((a, b)
> {
> return freqs[a] > freqs[b];
> }
> ) template 'sort' is not defined
That issue is already in the errata:
http://erdani.com/tdpl/errata/
Add the following line to fix:
import std.algorithm;
Ali
Thank you so much! It works now
well it does after I changed
writefln("%6u\t%s", freqs[word], words);
to
writefln("%6u\t%s", freqs[word], word);
(stupid mistake I made copying)
Re: LINK : fatal error LNK1104: cannot open file '_CMDLINE' --- errorlevel 1104
On Monday, 11 January 2016 at 20:19:50 UTC, Jason Jeffory wrote: Sheesh, why is it so hard to do simple stuff? 1) Have you tryed passing --arch=x86_64 to dub? 2) > "versions-x86_64": ["XYZ"] This is like a architecture dependent condition for version definition. So if your project will be compiled for the architecture x86_64 the version XYZ will be defined in your code. togrue
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Sunday, 10 January 2016 at 05:47:01 UTC, WhatMeWorry wrote: Thanks. Bummer. I really like gl3n, but glm/opengl is used almost exclusively in all the modern opengl code (tutorials) I've seen, so this might be a deal breaker. As the author of Derelict do you have any ideas of how much work is involved with getting glm to work with D? Want to do a DerelictGLM :) AFAIK, glm is a header-only library, so there's nothing to bind to. And if it did have binaries, I don't think the current state of D's C++ support could handle it. Binding to C is easy, binding to C++ is hit or miss.
Re: LINK : fatal error LNK1104: cannot open file '_CMDLINE' --- errorlevel 1104
On Monday, 11 January 2016 at 20:19:50 UTC, Jason Jeffory wrote:
On Monday, 11 January 2016 at 20:17:23 UTC, Jason Jeffory wrote:
Any ideas? Happens when I do a very simple dub project and try
to compile using the MS linker(x86 but set in sc.ini or 64).
I'm linking in glfw(using correct arch of course)
{
"name": "Test",
"description": "A minimal D application.",
"copyright": "Copyright © 2016, Jason",
"authors": ["Jason"],
"lflags" : ["+C:\\Dlang\\Libs\\glfw3.lib"],
"dflags-dmd": [""],
"versions-x86_64": ["UseAmd64Impl"],
"dependencies": {
}
}
seems "versions-x86_64": ["UseAmd64Impl"],
doesn't actually make it 64
**
Performing "debug" build using dmd for x86.
midimonitor ~master: building configuration "application"...
Linking...
Microsoft (R) Incremental Linker Version 14.00.23506.0
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : fatal error LNK1104: cannot open file '_CMDLINE'
--- errorlevel 1104
dmd failed with exit code 1104.
Sheesh, why is it so hard to do simple stuff?
There's nothing hard about it. It's just a matter of learning
what's what.
First, don't set 32/64-bit compilation in sc.ini. In fact, you
should generally never touch sc.ini (more on that below). If you
are calling DMD directly, just pass -m64 on the command line. If
you are using DUB, pass -ax86_64 on the command line.
Second, you don't need to set your own version flag for 64-bit.
Both x86_64 and Win64 are already predefined [1]. The latter is
only defined on when compiling for 64-bit Windows (Win32 is only
defined when compiling for 32-bit Windows, unlike in the C world
where the #defined _WIN32 means the Win32 API is available).
Should you need to, you can also distinguish between the two
Windows runtimes via the CRuntime_DigitalMars and
CRuntime_Microsoft versions.
The only time you should need to configure sc.ini is when you are
setting up DMD manually for 64-bit compilation. If you are using
the installer and already have the Microsoft toolchain installed,
the DMD installer will find it and configure sc.ini
appropriately. And while it may be tempting to add a custom
library path to sc.ini, it's probably easier not to if you only
are using one path. Then you don't have to worry about updating
it every time you install a new copy of DMD and you can use
multple DMD installations (useful for testing and maintaining
backward compatibility) without keeping all of the sc.ini files
up to date. If you don't want to configure the lib path per
project, IIRC you should be able to set the library path as an
environment variable and the linker will pick it up. I've never
tried that, as I tend to store any static libraries I need in the
source tree of each project and configure the path in my dub.sdl,
but I believe it should work.
[1] http://dlang.org/spec/version.html
Re: Error in 'The D Programming Language' (2010)?
On 01/11/2016 04:28 PM, asdfa wrote:
> Both DMD and GDC complain, saying
> Error: template instance sort!((a, b)
> {
> return freqs[a] > freqs[b];
> }
> ) template 'sort' is not defined
That issue is already in the errata:
http://erdani.com/tdpl/errata/
Add the following line to fix:
import std.algorithm;
Ali
Re: cairo(D) / x64 / unresolved externals / don't know why
On Monday, 11 January 2016 at 06:53:51 UTC, Benjamin Thaut wrote: Out of curiosity, why do you pass "-m64" 6 times to dmd? Once would be enough. I saw VisualD (dub generated project file) doing that with the latest version of Visual Studio comunnity, when I change to 64 bit building.
Re: Bug in csv or byLine ?
On Sunday, 10 January 2016 at 19:50:15 UTC, Tobi G. wrote: On Sunday, 10 January 2016 at 19:07:52 UTC, Jesse Phillips wrote: On Sunday, 10 January 2016 at 18:09:23 UTC, Tobi G. wrote: The bug has been fixed... Do you have a link for the fix? Is there a BugZilla entry? Yes sure.. https://issues.dlang.org/show_bug.cgi?id=15545 and the fix at github https://github.com/D-Programming-Language/phobos/pull/3917 togrue Thx for the fix !
Re: Anyone using glad?
On Monday, 11 January 2016 at 00:46:38 UTC, Jason Jeffory wrote: On Sunday, 10 January 2016 at 23:14:33 UTC, Dav1d wrote: [...] OK, I'll give it a try. What about GLUT and WGL? Whats the difference between them all and glfw? Are all these just OS helpers to reduce the boilerplate code? Also, how hard would it be to support cgl? (mac bindings) Thanks! GLUT ist dead and WGL is the windows API which you could use but is relativly low level. glfw is a cross platform toolkit (kinda like GLUT) which takes care of WGL (and other platforms) and gives you a nice API.
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Sunday, 10 January 2016 at 06:35:34 UTC, rsw0x wrote: On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Just translating some simple C++/glm/opengl tutorial code to D/gl3n/opengl and I'm coming across more friction than I expected. I've got a square centered at my window which is rotated by 45 degrees (counter clockwise) and then moved to the lower right quadrant. [...] iirc, gl3n uses row major and glm uses column major ordering just pass GL_TRUE to the transpose argument in glUniformMatrix4fv If you like to check an D lib for vector/matrix/quaterntion operations that uses column major ordering (ie, not need to transpose), see this : https://github.com/Zardoz89/zmath Was just my D2 learning pet project... I never checked if it was math correct, and I don't updated in a lot of time (5 years ago), plus there isn't documentation beyond comments and a few unit-tests, so use at your risk. But at least I know that was working correctly with Derelict2 when I wrote it. Perhaps I should retake this...
Re: Anyone using glad?
On Monday, 11 January 2016 at 01:46:11 UTC, Jason Jeffory wrote:
Ok. So I tried it out and having some issues ;/ got it
basically to compile but 2 problems:
1. I have to get dub to include the lib, not a big deal,
shouldn't be issue if I can get the right lib in. (not sure if
I have to do all that conversion just or not, and glfw has
several libs for different VS versions and such... not sure
what that's all about).
I don't remember what lib you need, there were some linking
issues on windows iirc, if it doesn't work using Derelict for
glfw might be easier (another possible issue: the deimos bindings
are outdated).
alternate thing I tried but gladLoadGL undefined
//(gladLoadGL()); // optionally you can pass a loader to this
function
//writefln("OpenGL Version %d.%d loaded", GLVersion.major,
GLVersion.minor);
gladLoadGLLoader does not exist in the D version, the D thing
would be gladLoadGL(myLoaderHere), this function takes a delegate
not a function as argument!
Using std.conv.to with std.typecons.Typedef
I am trying to create 2 types which contain integral values but
should not be compatible with each other. std.typecons.Typedef
seems perfect for this:
alias QuestionId = Typedef!(long, long.init, "QuestionId");
alias StudentId = Typedef!(long, long.init, "StudentId");
However I'm failing to use using std.conv.to:
QuestionId q = to!QuestionId("34"); <-- gives compile errors
(This is a reduced example, the actual use case is to use std.csv
to read in a structure from file, which in turn calls to!xyz)
How can I get std.conv to understand std.typecons.Typedef? In
general, is there a better solution to orthogonal types than
Typedef?
Thanks,
Saurabh
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Tuesday, 12 January 2016 at 01:00:30 UTC, Mike Parker wrote: On Sunday, 10 January 2016 at 05:47:01 UTC, WhatMeWorry wrote: Thanks. Bummer. I really like gl3n, but glm/opengl is used almost exclusively in all the modern opengl code (tutorials) I've seen, so this might be a deal breaker. As the author of Derelict do you have any ideas of how much work is involved with getting glm to work with D? Want to do a DerelictGLM :) AFAIK, glm is a header-only library, so there's nothing to bind to. And if it did have binaries, I don't think the current state of D's C++ support could handle it. Binding to C is easy, binding to C++ is hit or miss. the performance would also be terrible because AFAIK nothing could be inlined(outside of LTO, maybe)
Re: LINK : fatal error LNK1104: cannot open file '_CMDLINE' --- errorlevel 1104
On Tuesday, 12 January 2016 at 01:44:17 UTC, Jason Jeffory wrote: So, how do I set the json to compile for x64? You don't. You pass -ax86_64 (or --arch=x86_64) on the command line. If you find that inconvenient, just make a batch file to do it for you.
Re: LINK : fatal error LNK1104: cannot open file '_CMDLINE' --- errorlevel 1104
On 12/01/16 4:53 PM, Mike Parker wrote: On Tuesday, 12 January 2016 at 03:52:33 UTC, Mike Parker wrote: Actually, you could add -m64 in a dflags field (see [1]), but then you're in a situation where DUB thinks you're compiling in 32-bit, so configuration fields that are architecture-dependent will be off. [1] http://code.dlang.org/package-format?lang=json If you really must default dub to it, just build a custom dub build. Its not all that hard.
Re: Setting up dmd properly
On Monday, 11 January 2016 at 16:27:54 UTC, Jason Jeffory wrote: Anyway, regarding the static libs. I used this on a Win64 project and it works: "lflags" : [ "D:\\develop\\cairo\\cairo\\src\\release\\cairo-static.lib", "D:\\develop\\cairo\\libpng\\libpng.lib", "gdi32.lib" ], Thanks, that works but lflags is probably not the best way to do it. The "libs" field is better. This will guarantee that the library is passed in a compiler-appropriate manner across platforms. lflags is compiler-specific. 1. *not a valid lib file* (glfw3.lib) ;/ Ok, It's likely a COFF vs OMF issue. 2. What about 64? Does one have to maintain two branches for that? No. You might keep the libraries in separate directories or use a naming convention (like appending -32 or -64 on the library names) to distinguish them. Using DUB, you could then add something like the following: "libs-windows-dmd-x86": ["myWinLib-32"], "libs-windows-dmd-x86_64": ["myWinLib-64"] Drop the "windows" bit for cross-platform stuff. Of course, this is dependent upon you passing -ax86_64 to DUB when you want to compile for 64-bit 1. Trying windows link instead, remember having problems like this in the past with optlink. "LINK : fatal error LNK1104: cannot open file '_CMDLINE'" ;/ tried converting with coffimplib, not an import library. Another rabbit hole to go down ;/ (Why do programmers make programmers life hell?) coffimplib [1] is for converting import libraries, not static libraries. You can also use implib (part of the basic utilities package [2]) to generate an import library if you have a DLL. You should use coff2omf [3] to convert static libraries and object files. You can avoid all of these headaches by using dynamic bindings like those at DerelictOrg [4] if they are available for the libraries you use. Then the compile-time dependency on the C library goes away and all you need is the DLL at runtime. [1] http://www.digitalmars.com/ctg/coffimplib.html [2] http://www.digitalmars.com/download/freecompiler.html [3] http://www.digitalmars.com/ctg/coff2omf.html [4] https://github.com/DerelictOrg
Re: LINK : fatal error LNK1104: cannot open file '_CMDLINE' --- errorlevel 1104
On Tuesday, 12 January 2016 at 03:52:33 UTC, Mike Parker wrote: Actually, you could add -m64 in a dflags field (see [1]), but then you're in a situation where DUB thinks you're compiling in 32-bit, so configuration fields that are architecture-dependent will be off. [1] http://code.dlang.org/package-format?lang=json
Re: LINK : fatal error LNK1104: cannot open file '_CMDLINE' --- errorlevel 1104
On Tuesday, 12 January 2016 at 03:47:35 UTC, Mike Parker wrote: On Tuesday, 12 January 2016 at 01:44:17 UTC, Jason Jeffory wrote: So, how do I set the json to compile for x64? You don't. You pass -ax86_64 (or --arch=x86_64) on the command line. If you find that inconvenient, just make a batch file to do it for you. Actually, you could add -m64 in a dflags field (see [1]), but then you're in a situation where DUB thinks you're compiling in 32-bit, so configuration fields that are architecture-dependent will be off.
LINK : fatal error LNK1104: cannot open file '_CMDLINE' --- errorlevel 1104
Any ideas? Happens when I do a very simple dub project and try to
compile using the MS linker(x86 but set in sc.ini or 64). I'm
linking in glfw(using correct arch of course)
{
"name": "Test",
"description": "A minimal D application.",
"copyright": "Copyright © 2016, Jason",
"authors": ["Jason"],
"lflags" : ["+C:\\Dlang\\Libs\\glfw3.lib"],
"dflags-dmd": [""],
"versions-x86_64": ["UseAmd64Impl"],
"dependencies": {
}
}
Re: LINK : fatal error LNK1104: cannot open file '_CMDLINE' --- errorlevel 1104
On Monday, 11 January 2016 at 20:17:23 UTC, Jason Jeffory wrote:
Any ideas? Happens when I do a very simple dub project and try
to compile using the MS linker(x86 but set in sc.ini or 64).
I'm linking in glfw(using correct arch of course)
{
"name": "Test",
"description": "A minimal D application.",
"copyright": "Copyright © 2016, Jason",
"authors": ["Jason"],
"lflags" : ["+C:\\Dlang\\Libs\\glfw3.lib"],
"dflags-dmd": [""],
"versions-x86_64": ["UseAmd64Impl"],
"dependencies": {
}
}
seems "versions-x86_64": ["UseAmd64Impl"],
doesn't actually make it 64
**
Performing "debug" build using dmd for x86.
midimonitor ~master: building configuration "application"...
Linking...
Microsoft (R) Incremental Linker Version 14.00.23506.0
Copyright (C) Microsoft Corporation. All rights reserved.
LINK : fatal error LNK1104: cannot open file '_CMDLINE'
--- errorlevel 1104
dmd failed with exit code 1104.
Sheesh, why is it so hard to do simple stuff?
Re: Anyone using glad?
On Monday, 11 January 2016 at 16:30:58 UTC, Jason Jeffory wrote: On Monday, 11 January 2016 at 10:01:11 UTC, Dav1d wrote: [...] but as I said, source\app.d(35,3): Error: undefined identifier 'gladLoadGL' source\app.d(36,42): Error: undefined identifier 'GLVersion' source\app.d(36,59): Error: undefined identifier 'GLVersion' dmd failed with exit code 1. I'm using deimos, but is that a glad function or some other function supposedly by deimos? Looks like a minor issue, just import glad.gl.loader.
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Monday, 11 January 2016 at 10:04:29 UTC, Luis wrote: On Sunday, 10 January 2016 at 06:35:34 UTC, rsw0x wrote: On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Just translating some simple C++/glm/opengl tutorial code to D/gl3n/opengl and I'm coming across more friction than I expected. I've got a square centered at my window which is rotated by 45 degrees (counter clockwise) and then moved to the lower right quadrant. [...] iirc, gl3n uses row major and glm uses column major ordering just pass GL_TRUE to the transpose argument in glUniformMatrix4fv If you like to check an D lib for vector/matrix/quaterntion operations that uses column major ordering (ie, not need to transpose), see this : https://github.com/Zardoz89/zmath Was just my D2 learning pet project... I never checked if it was math correct, and I don't updated in a lot of time (5 years ago), plus there isn't documentation beyond comments and a few unit-tests, so use at your risk. But at least I know that was working correctly with Derelict2 when I wrote it. Perhaps I should retake this... I just remember why I never retake this ... Use gl3n, row-major math operations outperforms a lot, if you are doing any matrix multiplication on CPU side ( http://eli.thegreenplace.net/2015/memory-layout-of-multi-dimensional-arrays/ )
Re: Using std.conv.to with std.typecons.Typedef
On Monday, 11 January 2016 at 08:03:19 UTC, Saurabh Das wrote:
How can I get std.conv to understand std.typecons.Typedef?
You can do something like this:
QuestionId q = to!(TypedefType!QuestionId)("43");
In general, is there a better solution to orthogonal types than
Typedef?
Typedef is a reasonably solution, for this in my opinion.
togrue
Re: Using std.conv.to with std.typecons.Typedef
On Monday, 11 January 2016 at 12:15:55 UTC, Saurabh Das wrote: Any ideas? Yes. Because Typedef is introducing new Types, which csvReader doesn't know what they are, you'll need a little workaround and cast the values yourself. import std.csv, std.stdio, std.algorithm, std.range; enum csvTxt = "10, 20 30, 40 50, 50"; myStuff = csvTxt.csvReader!(Tuple!(long, long)) .map!(a => MyStuff(cast(QuestionId)a[0], cast(StudentId) a[1])) .array; The .map does nothing other as getting the information out of the Tuple 'a' and constructing a struct of the type MyStuff. togrue
Re: Using std.conv.to with std.typecons.Typedef
On Monday, 11 January 2016 at 12:01:30 UTC, Tobi G. wrote:
On Monday, 11 January 2016 at 08:03:19 UTC, Saurabh Das wrote:
How can I get std.conv to understand std.typecons.Typedef?
You can do something like this:
QuestionId q = to!(TypedefType!QuestionId)("43");
In general, is there a better solution to orthogonal types
than Typedef?
Typedef is a reasonably solution, for this in my opinion.
togrue
Oh excellent. Yes that works for a standalone conversion. Do you
know how I can use this with std.csv?
import std.typecons;
alias QuestionId = Typedef!(long, long.init, "QuestionId");
alias StudentId = Typedef!(long, long.init, "StudentId");
struct MyStuff
{
QuestionId q;
StudentId s;
}
void main()
{
import std.csv, std.stdio, std.algorithm, std.range;
File("file.csv").byLine.joiner("\n").csvReader!(MyStuff)(null).array;
}
This doesn't work. But if MyStuff is defined as: struct MyStuff {
int q, s; }, then it works.
Any ideas?
Re: Using std.conv.to with std.typecons.Typedef
On Monday, 11 January 2016 at 12:59:05 UTC, Tobi G. wrote: On Monday, 11 January 2016 at 12:15:55 UTC, Saurabh Das wrote: Any ideas? Yes. Because Typedef is introducing new Types, which csvReader doesn't know what they are, you'll need a little workaround and cast the values yourself. import std.csv, std.stdio, std.algorithm, std.range; enum csvTxt = "10, 20 30, 40 50, 50"; myStuff = csvTxt.csvReader!(Tuple!(long, long)) .map!(a => MyStuff(cast(QuestionId)a[0], cast(StudentId) a[1])) .array; The .map does nothing other as getting the information out of the Tuple 'a' and constructing a struct of the type MyStuff. togrue Yes that does make sense. I could read in a POD struct and convert it to a typed one. Though I was hoping for a more elegant solution... This'll have to do I guess. Thanks!
Re: issue porting C++/glm/openGL to D/gl3n/openGL
On Sunday, 10 January 2016 at 05:47:01 UTC, WhatMeWorry wrote: On Sunday, 10 January 2016 at 04:37:43 UTC, Mike Parker wrote: On Sunday, 10 January 2016 at 02:51:57 UTC, WhatMeWorry wrote: Is gl3n not a direct replacement for glm? From the very top of the gl3n github page: "OpenGL Maths for D (not glm for D)." So, no, it is not. You might want to start with the glm documentaion [1]. [1] http://dav1dde.github.io/gl3n/ Thanks. Bummer. I really like gl3n, but glm/opengl is used almost exclusively in all the modern opengl code (tutorials) I've seen, so this might be a deal breaker. As the author of Derelict do you have any ideas of how much work is involved with getting glm to work with D? Want to do a DerelictGLM :) I bought your excellent book as a xmas present for myself so looks like I'll be reading chapter 9. gl3n has most features of GLM just the syntax is different and a few other things. gl3n then operates on row-major matrices only (Extrawurst wanted to work on a column-major version), which isn't a big issue for your usual GL, you just need to tell OpenGL that it is in row-major format when uploading it. iirc GLM is a header only library so you can't simply interface it from D you would need to port every function, that's what I basically did in gl3n only that I started from scratch and made my own API etc. So you can use gl3n as a glm replacement it just has a different syntax and a few semantics are different. --- Regarding some functions not showing up on the website, that's because the ddoc generator doesn't want to go into some static if() or version() blocks. A known bug.
Re: Setting up dmd properly
On Monday, 11 January 2016 at 05:46:11 UTC, Robert M. Münch wrote: On 2016-01-11 01:47:54 +, Jason Jeffory said: and how does one link in compiled static libraries into a dub project? I tried adding stuff like "lflags" : ["+C:\\MyLibs\\"], with the .lib file in it, but that doesn't work. (I'd expect to have to supply the file name somewhere, at least) Thanks. I agree with all your other points. Telling explicit what's going on would help a lot in daily business. Not only for D but all compiler stuff. But it seems to be tradition to not do this. Anyway, regarding the static libs. I used this on a Win64 project and it works: "lflags" : [ "D:\\develop\\cairo\\cairo\\src\\release\\cairo-static.lib", "D:\\develop\\cairo\\libpng\\libpng.lib", "gdi32.lib" ], Thanks, that works but 1. *not a valid lib file* (glfw3.lib) ;/ Ok, 2. What about 64? Does one have to maintain two branches for that? I don't understand why the trend is not to be verbose but to hide details ;/ It's simply the wrong way. 1. Trying windows link instead, remember having problems like this in the past with optlink. "LINK : fatal error LNK1104: cannot open file '_CMDLINE'" ;/ tried converting with coffimplib, not an import library. Another rabbit hole to go down ;/ (Why do programmers make programmers life hell?) After trying other various things that didn't work, I'm done for today... too frustrating. Hopefully I'll come back tomorrow with a nice surprise.
Re: Anyone using glad?
On Monday, 11 January 2016 at 10:01:11 UTC, Dav1d wrote:
On Monday, 11 January 2016 at 01:46:11 UTC, Jason Jeffory wrote:
Ok. So I tried it out and having some issues ;/ got it
basically to compile but 2 problems:
1. I have to get dub to include the lib, not a big deal,
shouldn't be issue if I can get the right lib in. (not sure if
I have to do all that conversion just or not, and glfw has
several libs for different VS versions and such... not sure
what that's all about).
I don't remember what lib you need, there were some linking
issues on windows iirc, if it doesn't work using Derelict for
glfw might be easier (another possible issue: the deimos
bindings are outdated).
alternate thing I tried but gladLoadGL undefined
//(gladLoadGL()); // optionally you can pass a loader to this
function
//writefln("OpenGL Version %d.%d loaded", GLVersion.major,
GLVersion.minor);
gladLoadGLLoader does not exist in the D version, the D thing
would be gladLoadGL(myLoaderHere), this function takes a
delegate not a function as argument!
but as I said,
source\app.d(35,3): Error: undefined identifier 'gladLoadGL'
source\app.d(36,42): Error: undefined identifier 'GLVersion'
source\app.d(36,59): Error: undefined identifier 'GLVersion'
dmd failed with exit code 1.
I'm using deimos, but is that a glad function or some other
function supposedly by deimos?
Re: cairo(D) / x64 / unresolved externals / don't know why
On 2016-01-11 06:53:51 +, Benjamin Thaut said: You should not need to link manually against msvcrt, dmd does this for you. Ok, that was what I expected. You can view the linker commands that are stored inside a object file via microsoft dumpbin tool "dumpbin /DIRECTIVES your.obj". Great, thanks for this. You should check the declarations of the functions that cause a unresolved external error. If they have a "export" in front of them, remove the export. I can not think of any other reason why dmd would otherwise reference a import symbol. Ah, good point. I didn't see the link to the DLL import stuff. I can't / shouldn't remove them because these are coming from It looks like my project is mixing up static and dynamic linked runtime libs. Import symbols are symbols used for dll linking and start with "__imp_" Is this a DMD convention or a general one? Never heard about this. Out of curiosity, why do you pass "-m64" 6 times to dmd? Once would be enough. I don't have a clue where these come from. I just use DUB to compile my D project. For debug builds targeting windows 64 I would also highly recommend using "-gc -op" instead of "-g". This will give a much better debugging experience in Visual Studio. Ok, will see how to get this in. Thanks so far for all the hints. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: cairo(D) / x64 / unresolved externals / don't know why
Am 11.01.2016 um 18:27 schrieb Robert M. Münch: Import symbols are symbols used for dll linking and start with "__imp_" Is this a DMD convention or a general one? Never heard about this. This seems to be a general convetion on windows. All c++ compilers I've seen on windows so far emit so called import symbols using the "__imp_" prefix. Basically its just another level of indirection during a function call to be able to resolve function addresses at runtime, e.g. implement dynamic linking. Its kind of a implementation detail, so in theory you don't have to know about it. But it helps when reading linker errors. In case my talk gets accepted for dconf 2016 I'm going to cover this there in more detail. -- Kind Regards Benjamin Thaut
