Re: Setting up dmd properly
On 2016-01-12 04:15:36 +, Mike Parker said: 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. I have seen countless problems because apps are using dynamic linking and whole IT environements getting into DLL hell. IMO one of the worst ideas these days. How simple would it be to just have one self-contained executable? And all the Docker hype is doing / simulating this with a sledgehammer. I prefer to link everything static, and it saved us and our clients hours of headache. Drivespace is no limiting factor anymore, but time and customer satisfaction is always. -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Setting up dmd properly
On 2016-01-11 02:22, Jason Jeffory wrote: Dmd's setup construction is a bit weird and has some difficult issue tracking. How about if dmd supported, if it already doesn't, some ways to help the user check the configuration of dmd. It would be quick and easy to implement. e.g., dmd -showinfo Target Arch: x86 Libraries: C:\Mylib;C:\Another\Lib\Somewhere Modules: C:\MyModules; Version: 2.062 etc... You can get some more information by compiling with the "-v" flag. In the top it will print the config used, i.e. the path to sc.ini the compiler found. At the bottom it will print the command it uses for linking. -- /Jacob Carlborg
Re: Setting up dmd properly
On Tuesday, 12 January 2016 at 08:42:19 UTC, Robert M. Münch wrote: I have seen countless problems because apps are using dynamic linking and whole IT environements getting into DLL hell. IMO one of the worst ideas these days. I'm not talking about dynamic linking, but dynamic loading. This allows more control over which versions of a dynamic library are supported and helps to avoid DLL hell.
Re: Setting up dmd properly
On Tuesday, 12 January 2016 at 12:32:11 UTC, Mike Parker wrote: On Tuesday, 12 January 2016 at 08:42:19 UTC, Robert M. Münch wrote: I have seen countless problems because apps are using dynamic linking and whole IT environements getting into DLL hell. IMO one of the worst ideas these days. I'm not talking about dynamic linking, but dynamic loading. This allows more control over which versions of a dynamic library are supported and helps to avoid DLL hell. To clarify, static bindings can be used when linking both statically and dynamically. Dynamic bindings have no link-time dependency at all and are used to load a dynamic library manually at runtime.
is expression with template parameter list
The following example compiles work as expected:
import std.stdio;
import std.typecons;
void main()
{
Nullable!(int) a;
static if(is(typeof(a) == Nullable!(U), U))
writeln("true");
else
writeln("false");
}
But if I use the fully qualified name in the condition, i.e.
"std.typecons.Nullable!(U)", then I get this compile error:
main.d(8): Error: undefined identifier 'U'
Shouldn't this work? I have tried with the latest beta an a bunch of
older versions of DMD.
--
/Jacob Carlborg
Re: is expression with template parameter list
On 1/12/16 8:03 AM, Jacob Carlborg wrote:
The following example compiles work as expected:
import std.stdio;
import std.typecons;
void main()
{
Nullable!(int) a;
static if(is(typeof(a) == Nullable!(U), U))
writeln("true");
else
writeln("false");
}
But if I use the fully qualified name in the condition, i.e.
"std.typecons.Nullable!(U)", then I get this compile error:
main.d(8): Error: undefined identifier 'U'
Shouldn't this work? I have tried with the latest beta an a bunch of
older versions of DMD.
Looks like a bug to me.
-Steve
Re: Anyone using glad?
On Monday, 11 January 2016 at 00:46:38 UTC, Jason Jeffory 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? These kind of questions are best clarified on the OpenGL wiki. https://www.opengl.org/wiki/Main_Page Especially these (Glad is explained there as well): https://www.opengl.org/wiki/Getting_Started https://www.opengl.org/wiki/OpenGL_Loading_Library https://www.opengl.org/wiki/Related_toolkits_and_APIs
How to declare an alias to a function literal type
I have a function type and variable and assign a function to it:
void function( int i ) myFunc;
myFunc = void function( int i ) { myCode; }
How would I declare an alias for void function( int i ) such that
the case above would work like this:
// alias MF = void function( int i ); // not working
// alias void function( int i ) MF; // not working
MF myFunc;
myFunc = MF { myCode };
Please, if possible, also show me where I should have found the
answer (D Reference, Alis book, etc. )
Re: How to declare an alias to a function literal type
On Tuesday, 12 January 2016 at 15:41:02 UTC, ParticlePeter wrote:
I have a function type and variable and assign a function to it:
void function( int i ) myFunc;
myFunc = void function( int i ) { myCode; }
How would I declare an alias for void function( int i ) such
that the case above would work like this:
// alias MF = void function( int i ); // not working
// alias void function( int i ) MF; // not working
MF myFunc;
myFunc = MF { myCode };
Please, if possible, also show me where I should have found the
answer (D Reference, Alis book, etc. )
This works for me:
alias MF = void function(int i); // works fine - what was your
error?
void main() {
import std.stdio;
MF myFunc;
// you can also use the full `function(int i) { ... }` in the
next line
myFunc = (i) { writeln("i = ", i); };
myFunc(42);
}
Re: How to declare an alias to a function literal type
V Tue, 12 Jan 2016 15:41:02 +
ParticlePeter via Digitalmars-d-learn
napsáno:
> I have a function type and variable and assign a function to it:
>
> void function( int i ) myFunc;
> myFunc = void function( int i ) { myCode; }
>
> How would I declare an alias for void function( int i ) such that
> the case above would work like this:
>
> // alias MF = void function( int i ); // not working
> // alias void function( int i ) MF; // not working
>
> MF myFunc;
> myFunc = MF { myCode };
>
> Please, if possible, also show me where I should have found the
> answer (D Reference, Alis book, etc. )
alias void MF(int i);
Re: How to declare an alias to a function literal type
On 12.01.2016 16:41, ParticlePeter wrote:
// alias MF = void function( int i ); // not working
// alias void function( int i ) MF; // not working
These are both fine. The first one is the preferred style.
MF myFunc;
myFunc = MF { myCode };
This line doesn't work. Function literals don't take a type before the
curly braces. They have their own syntax. See
http://dlang.org/spec/expression.html (search for "Function Literals").
Since most of the stuff in function literals can be inferred from the
context, something as simple as this works:
myFunc = (i) { myCode };
Re: How to declare an alias to a function literal type
On Tuesday, 12 January 2016 at 15:57:03 UTC, Marc Schütz wrote:
On Tuesday, 12 January 2016 at 15:41:02 UTC, ParticlePeter
wrote:
I have a function type and variable and assign a function to
it:
void function( int i ) myFunc;
myFunc = void function( int i ) { myCode; }
How would I declare an alias for void function( int i ) such
that the case above would work like this:
// alias MF = void function( int i ); // not working
// alias void function( int i ) MF; // not working
MF myFunc;
myFunc = MF { myCode };
Please, if possible, also show me where I should have found
the answer (D Reference, Alis book, etc. )
This works for me:
alias MF = void function(int i); // works fine - what was your
error?
void main() {
import std.stdio;
MF myFunc;
// you can also use the full `function(int i) { ... }` in
the next line
myFunc = (i) { writeln("i = ", i); };
myFunc(42);
}
Not what I wanted, I wanted the parameter to be part of the alias:
myFunc = MF { ... }
I want to pass such a function to another function:
alias MF = void function(int i);
void otherFunc( void function( int ) mf );
otherFunc( MF { ... } ); // Getting Error: found '{' when
expecting ','
Actually, I do use only one param, and not int as well, hence I
would like the parameter list to be part of the alias.
Your example works though.
Reserved Identifiers (just making sure)
Hello, I already know the answer to my question, but I would like someone to reassure me that I'm not mistaken before I rename literally hundreds of identifiers in my code (and refactor at least two large templates). TL;DR: Am I understanding correctly that "_Foo" is NOT reserved as an identifier in the sense that "__foo" IS reserved, since they both are reserved in C? I have been using D for about two years. Before that, I wrote everything in strict ANSI C. In C, not only are identifies beginning with two underscores reserved (e.g. __foo), but identifiers beginning with a single underscore followed by a capital letter are also reserved (e.g. _Foo)†. I would like to verify that this is not the case in D. To be absolutely clear, I already know that such identifiers compile; I want to know if they are reserved for future use by the D language. The following quote is from: https://dlang.org/spec/lex.html#Identifier Quote: "Identifiers start with a letter, _, or universal alpha, and are followed by any number of letters, _, digits, or universal alphas. Universal alphas are as defined in ISO/IEC 9899:1999(E) Appendix D. (This is the C99 Standard.) Identifiers can be arbitrarily long, and are case sensitive. Identifiers starting with __ (two underscores) are reserved." The above quote makes it perfectly clear that identifiers beginning with an underscore followed by an uppercase letter are not reserved, but I could not find an example of such in object.d, DRuntime, nor in Phobos2 source (my usual method of verification). Could someone who knows for sure please verify that "_Foo" is not reserved in D? Thank you for your patience, and in advance for any assistance! †(, as well as some other obscure restrictions e.g. all-uppercase identifiers beginning with 'E' are reserved in C.)
Re: How to declare an alias to a function literal type
On 01/12/2016 08:22 AM, ParticlePeter wrote:
> On Tuesday, 12 January 2016 at 15:57:03 UTC, Marc Schütz wrote:
> Not what I wanted, I wanted the parameter to be part of the alias:
> myFunc = MF { ... }
>
> I want to pass such a function to another function:
>
> alias MF = void function(int i);
> void otherFunc( void function( int ) mf );
> otherFunc( MF { ... } ); // Getting Error: found '{' when expecting
I've added otherFunc(MF) to Marc Schütz's program:
alias MF = void function(int i);
void otherFunc(MF func) {
func(42);
}
void main() {
import std.stdio;
MF myFunc;
// you can also use the full `function(int i) { ... }` in the next line
myFunc = (i) { writeln("i = ", i); };
myFunc(42);
otherFunc((i) { writefln("otherFunc called me with %s", i); });
}
Ali
Re: How to declare an alias to a function literal type
On Tuesday, 12 January 2016 at 16:00:37 UTC, Daniel Kozak wrote:
V Tue, 12 Jan 2016 15:41:02 +
ParticlePeter via Digitalmars-d-learn
napsáno:
I have a function type and variable and assign a function to
it:
void function( int i ) myFunc;
myFunc = void function( int i ) { myCode; }
How would I declare an alias for void function( int i ) such
that the case above would work like this:
// alias MF = void function( int i ); // not working
// alias void function( int i ) MF; // not working
MF myFunc;
myFunc = MF { myCode };
Please, if possible, also show me where I should have found
the answer (D Reference, Alis book, etc. )
alias void MF(int i);
That does not work:
alias void MF(int i);
MF mf; // Error: variable mf cannot be declared to be a
function
Re: How to declare an alias to a function literal type
On 01/12/2016 07:41 AM, ParticlePeter wrote: > Please, if possible, also show me where I should have found the answer > (D Reference, Alis book It is not used with a function literal but searching for 'alias' below yields something close: :) http://ddili.org/ders/d.en/lambda.html Function pointer syntax is relatively harder to read; it is common to make code more readable by an alias: alias CalculationFunc = int function(char, double); That alias makes the code easier to read: CalculationFunc ptr = &myFunction; As with any type, auto can be used as well: auto ptr = &myFunction; As others have already said, &myFunction can be replaced with a lambda. Shamefully without compiling: auto ptr = (char, double) => 42; Ali
Re: How to declare an alias to a function literal type
On Tuesday, 12 January 2016 at 16:22:48 UTC, ParticlePeter wrote:
Actually, I do use only one param, and not int as well, hence I
would like the parameter list to be part of the alias.
Your example works though.
This was confusing, lets start fresh:
I have a function "otherFunc" which takes a function with lots of
parameters as argument:
void otherFunc( void function( ref int p1, float p2, ubyte p3,
... ) mf );
Side-note, I use the keyword function to signal that it is a
function and not a delegate, thought it is a delegate when not
specified.
When I pass a parameter to otherFunc I use this syntax for an
anonymous function parameter:
otherFunc( void function( ref int p1, float p2, ubyte p3 ) {
myCode; } );
I would like to alias the function signature above:
alias MF = void function( ref int p1, float p2, ubyte p3 );
I can rewrite the definition of otherFunc like this:
void otherFunc( MF mf );
But I cannot pass an anonymous function to otherFunc like this:
otherFunc( MF { myCode; } );
Thats what I want. Any working example?
Ali, I do not pass an existing named function as a pointer. I am
also not sure about the lambdas, as I do not return anything, I
just want to process data, would that work?
Re: How to declare an alias to a function literal type
On 01/12/2016 08:55 AM, ParticlePeter wrote:
> I have a function "otherFunc" which takes a function with lots of
> parameters as argument:
>
> void otherFunc( void function( ref int p1, float p2, ubyte p3, ... )
mf );
Ok.
> otherFunc( void function( ref int p1, float p2, ubyte p3 ) { myCode; } );
Ok.
> alias MF = void function( ref int p1, float p2, ubyte p3 );
Ok.
> I can rewrite the definition of otherFunc like this:
> void otherFunc( MF mf );
That has the same problem of trying to do this for int:
void foo(int i) {
}
void main() {
foo(int 42); // <-- ERROR
}
But you can do this:
foo(int(42));// (Relatively new syntax in D.)
> But I cannot pass an anonymous function to otherFunc like this:
> otherFunc( MF { myCode; } );
It works with the parentheses as it does for int:
alias MF = void function( ref int p1, float p2, ubyte p3 );
void otherFunc( MF mf ) {
}
void main() {
otherFunc(MF((ref int, float, ubyte){ }));// <-- Parens
}
> not sure about the lambdas, as I do not return anything, I just want to
> process data, would that work?
Yes, some lambdas do not return anything.
Ali
Re: How to declare an alias to a function literal type
On Tuesday, 12 January 2016 at 16:55:48 UTC, ParticlePeter wrote:
I can rewrite the definition of otherFunc like this:
void otherFunc( MF mf );
But I cannot pass an anonymous function to otherFunc like this:
otherFunc( MF { myCode; } );
Thats what I want. Any working example?
If I understand you correctly (not sure), you would like to write
`MF` so that you don't need to specify the parameters in the
lambda? That's not possible, because the code inside the lambda
needs names for them if it wants to access them, but parameter
names are _not_ part of the function type, and therefore the
alias doesn't know about them.
However, you don't need to specify the full parameter list in the
lambda, the names and `ref` are enough:
otherFunc( (ref a, ref b, ref c) { /* use a, b, c */ } );
Re: How to declare an alias to a function literal type
On 12.01.2016 17:55, ParticlePeter wrote:
When I pass a parameter to otherFunc I use this syntax for an anonymous
function parameter:
otherFunc( void function( ref int p1, float p2, ubyte p3 ) { myCode; } );
You don't. That's not valid code. You can be using this:
otherFunc( function void ( ref int p1, float p2, ubyte p3 ) { myCode; } );
Note the different position of the `function` keyword.
Re: How to declare an alias to a function literal type
On Tuesday, 12 January 2016 at 17:28:35 UTC, Marc Schütz wrote:
On Tuesday, 12 January 2016 at 16:55:48 UTC, ParticlePeter
wrote:
[...]
If I understand you correctly (not sure), you would like to
write `MF` so that you don't need to specify the parameters in
the lambda? That's not possible, because the code inside the
lambda needs names for them if it wants to access them, but
parameter names are _not_ part of the function type, and
therefore the alias doesn't know about them.
However, you don't need to specify the full parameter list in
the lambda, the names and `ref` are enough:
otherFunc( (ref a, ref b, ref c) { /* use a, b, c */ } );
This is already quite useful, thanks.
Re: How to declare an alias to a function literal type
On Tuesday, 12 January 2016 at 17:03:49 UTC, Ali Çehreli wrote:
On 01/12/2016 08:55 AM, ParticlePeter wrote:
> I have a function "otherFunc" which takes a function with
lots of
> parameters as argument:
>
> void otherFunc( void function( ref int p1, float p2, ubyte
p3, ... ) mf );
Ok.
> otherFunc( void function( ref int p1, float p2, ubyte p3 ) {
myCode; } );
Ok.
> alias MF = void function( ref int p1, float p2, ubyte p3 );
Ok.
> I can rewrite the definition of otherFunc like this:
> void otherFunc( MF mf );
That has the same problem of trying to do this for int:
void foo(int i) {
}
void main() {
foo(int 42); // <-- ERROR
}
But you can do this:
foo(int(42));// (Relatively new syntax in D.)
> But I cannot pass an anonymous function to otherFunc like
this:
> otherFunc( MF { myCode; } );
It works with the parentheses as it does for int:
alias MF = void function( ref int p1, float p2, ubyte p3 );
void otherFunc( MF mf ) {
}
void main() {
otherFunc(MF((ref int, float, ubyte){ }));// <-- Parens
}
O.K. so I conclude that writing:
void main() {
otherFunc(MF { });
}
is not possible. At least not with alias, maybe with templates or
mixins?
In essence something like C #define as in:
#define MF function( ref int p1, float p2, ubyte p3 )
Is there some such way?
Re: Reserved Identifiers (just making sure)
On Tuesday, 12 January 2016 at 16:20:10 UTC, naptime wrote: Hello, I already know the answer to my question, but I would like someone to reassure me that I'm not mistaken before I rename literally hundreds of identifiers in my code (and refactor at least two large templates). TL;DR: Am I understanding correctly that "_Foo" is NOT reserved as an identifier in the sense that "__foo" IS reserved, since they both are reserved in C? I have been using D for about two years. Before that, I wrote everything in strict ANSI C. In C, not only are identifies beginning with two underscores reserved (e.g. __foo), but identifiers beginning with a single underscore followed by a capital letter are also reserved (e.g. _Foo)†. I would like to verify that this is not the case in D. To be absolutely clear, I already know that such identifiers compile; I want to know if they are reserved for future use by the D language. The following quote is from: https://dlang.org/spec/lex.html#Identifier Quote: "Identifiers start with a letter, _, or universal alpha, and are followed by any number of letters, _, digits, or universal alphas. Universal alphas are as defined in ISO/IEC 9899:1999(E) Appendix D. (This is the C99 Standard.) Identifiers can be arbitrarily long, and are case sensitive. Identifiers starting with __ (two underscores) are reserved." The above quote makes it perfectly clear that identifiers beginning with an underscore followed by an uppercase letter are not reserved, but I could not find an example of such in object.d, DRuntime, nor in Phobos2 source (my usual method of verification). Could someone who knows for sure please verify that "_Foo" is not reserved in D? Thank you for your patience, and in advance for any assistance! †(, as well as some other obscure restrictions e.g. all-uppercase identifiers beginning with 'E' are reserved in C.) Yes, symbols in the form of `_Foo` are not reserved in D. Only symbols beginning with two underscores, such as __traits or __gshared. Technically the different `op*` names such as opCat, opBinary, etc. are reserved as well, int he sense that the compiler will recognize them and do special things, such as writing a + b as a.opBinary!"+"(b).
Re: Reserved Identifiers (just making sure)
On Tuesday, 12 January 2016 at 17:50:45 UTC, Meta wrote: On Tuesday, 12 January 2016 at 16:20:10 UTC, naptime wrote: [...] Yes, symbols in the form of `_Foo` are not reserved in D. Only symbols beginning with two underscores, such as __traits or __gshared. Technically the different `op*` names such as opCat, opBinary, etc. are reserved as well, int he sense that the compiler will recognize them and do special things, such as writing a + b as a.opBinary!"+"(b). Oh, wonderful. Thank you so much!
cast fails for classes from windows dll
Hi,
I am not sure, whether this is a current limitation of the
windows dll functionality of D
or I am doing s.th. which will not work.
I have developed in D a windows DLL which creates class instances
by passing the name (using object.factory method).
In another D application I am using this DLL. My issue is, that
the cast fails, although
typeid(bar).name shows the correct name .
module main;
// these classes are in a seperate module
// used for the dll & for this application
export class Foo {}
export class Bar : Foo {}
class Baz : Bar {}
void main()
{
// this method calls the dll and returns Foo
Foo c = dllCreateClass("main.Baz");
// no failure
assert( typeid(c).name == "main.Baz");
// > fails
if (auto myBar = cast(Bar) c){}
}
Kind regards
André
Re: Anyone using glad?
So, I finally got it to work by abandoning demios and static
linking. Derelict + dynamic linking worked with only about a min
of problems(copying the proper dll to the correct place). I'd
prefer static linking but I can deal with that later.
My current problem is: 1. The code doesn't work as expected: It
should show a type of triangle on the display, instead the whole
display is colored, probably user error as I cobbled together
some tutorial code. 2*. I get an access violation when exiting
the program. I have no idea how, why, or where this is
happening(except, obviously towards the end of the program...
probably a cleanup issue).
Any ideas? Thanks.
Here is the full code:
import std.stdio;
import std.string;
import std.conv;
import glad.gl.all;
import glad.gl.loader;
import derelict.glfw3.glfw3;
import std.exception;
immutable string minimalVertexShader = `
#version 120
attribute vec2 position;
void main(void)
{
gl_Position = vec4(position, 0, 1);
}
`;
immutable string minimalFragmentShader = `
#version 120
void main(void)
{
gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
}
`;
// Window dimensions
const GLuint WIDTH = 800, HEIGHT = 600;
void main()
{
DerelictGLFW3.load();
glfwInit();
// Set all the required options for GLFW
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
glfwWindowHint(GLFW_RESIZABLE, GL_FALSE);
// Create a GLFWwindow object that we can use for GLFW's
functions
GLFWwindow* window = glfwCreateWindow(WIDTH, HEIGHT,
"LearnOpenGL", null, null);
glfwMakeContextCurrent(window);
if (window == null)
{
writeln("Failed to create GLFW window");
glfwTerminate();
return;
}
// Set the required callback functions
glfwSetKeyCallback(window, cast(GLFWkeyfun)&key_callback);
enforce(gladLoadGL()); // optionally you can pass a loader to
this function
writefln("OpenGL Version %d.%d loaded", GLVersion.major,
GLVersion.minor);
// Define the viewport dimensions
glViewport(0, 0, WIDTH, HEIGHT);
float[] vertices = [ -0.1, -0.1, 0.1, -0.1, -1, 1, 1, -0.1];
ushort[] indices = [0, 1, 2, 3];
uint vbo, ibo;
// Create VBO
glGenBuffers(1, &vbo);
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glBufferData(GL_ARRAY_BUFFER, vertices.length * float.sizeof,
vertices.ptr, GL_STATIC_DRAW);
glBindBuffer(GL_ARRAY_BUFFER, 0);
// Create IBO
glGenBuffers(1, &ibo);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ibo);
glBufferData(GL_ELEMENT_ARRAY_BUFFER, indices.sizeof,
indices.ptr, GL_STATIC_DRAW);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);
// Program
auto program = glCreateProgram();
// Vertex Shader
auto vsh = glCreateShader(GL_VERTEX_SHADER);
auto vshSrc = minimalVertexShader.toStringz;
glShaderSource(vsh, 1, &vshSrc, null);
glCompileShader(vsh);
glAttachShader(program, vsh);
// Fragment Shader
auto fsh = glCreateShader(GL_FRAGMENT_SHADER);
auto fshSrc = minimalFragmentShader.toStringz;
glShaderSource(fsh, 1, &fshSrc, null);
glCompileShader(fsh);
glAttachShader(program, fsh);
glLinkProgram(program);
glUseProgram(program);
auto position = glGetAttribLocation(program, "position");
// Game loop
while (!glfwWindowShouldClose(window))
{
// Check if any events have been activated (key pressed, mouse
moved etc.) and call corresponding response functions
glfwPollEvents();
// Render
// Clear the colorbuffer
glClearColor(0f, 0f, 0f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT);
glClearColor(1, 0.9, 0.8, 1);
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glBindBuffer(GL_ARRAY_BUFFER, vbo);
glEnableVertexAttribArray(position);
glVertexAttribPointer(position, 2, GL_FLOAT, GL_FALSE, 2 *
float.sizeof, null);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ibo);
glDrawElements(GL_TRIANGLE_STRIP, 4, GL_UNSIGNED_SHORT, null);
glDisableVertexAttribArray(position);
// Swap the screen buffers
glfwSwapBuffers(window);
}
// Terminates GLFW, clearing any resources allocated by GLFW.
glfwTerminate();
return;
}
// Is called whenever a key is pressed/released via GLFW
void key_callback(GLFWwindow* window, int key, int scancode, int
action, int mode)
{
write("Key Pressed = ");
writeln(key);
if (key == GLFW_KEY_ESCAPE && ac
Re: Setting up dmd properly
On Tuesday, 12 January 2016 at 08:42:19 UTC, Robert M. Münch wrote: On 2016-01-12 04:15:36 +, Mike Parker said: 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. I have seen countless problems because apps are using dynamic linking and whole IT environements getting into DLL hell. IMO one of the worst ideas these days. How simple would it be to just have one self-contained executable? And all the Docker hype is doing / simulating this with a sledgehammer. I prefer to link everything static, and it saved us and our clients hours of headache. Drivespace is no limiting factor anymore, but time and customer satisfaction is always. It seems the whole state of affairs in programming is "Lets do the most minimal work to get X to work in environment Y. To hell with everything else!". The programmers tend to do the most minimal work to code stuff that they can get away with. This isn't 1984 but coding quality has no increased much since then. No programmer, in this day and age, should have to spend more than a few minutes getting anything to the point of actual programming. Programmers can code smarter, faster, and better, yet when it comes to the tooling, they tend to suck balls. Visual studio style is about the minimum one should except. I've virtually had no problems with it. MS did good job of modernizing the toolchain... Most people that code on linux think that it should be "hard" and gui's suck, that programming is suppose to be a hazing ritual. They setup their system to work for them, and it works... anyone with problems must be ignorant and not "pro programmers". It's kinda this elitist attitude. They spend more time solving 1%'er problems than creating tools that *just* work for 99% of the people. When problems occur it is never their fault but the fault of the ignorant cave man trying to become an godly programmer. Just search "openGL dmd"(28k) and about 80% of the results are people having problems with getting openGL working with D. "openGL dmd error" has 1M results, thats nearly 30 times the results. Of course, these don't mean much, but does give the trend. That's just for openGL. D has a long way to go to make it competitive... as long as the tooling sucks and there are problems with stupid issues such as coff vs omf, installation issues, ide issues, etc... it won't get off the ground. The D "core" seems to be mainly interested in fixing and enhancing very niche issues in D instead of working on making it a viable and usable candidate for the masses. They think by taking a Ferrari and doing all the pin stripes and detail work and add a specialized turbo charger is going to make it more appealing... yet they never put gas in it so that the customer can actually test drive it. There is a benefit of having D work well... the benefit is that there is a larger user database = more man-hours to help D evolve. The reason why MS and VS is better is because a noob like myself can install it and hit the gas pedal and go. It looks good, it's fast, it's not the Ferrari... it's like a Mazda. But it runs! No frustration figuring out why the damn thing won't start. I want to drive! Not fucking around for days trying to figure out why the thing won't start. It's not my job to fill it up with gas, that's the dealers responsibility. Anyways, sorry for the rant... not like things will change. D does fill a niche, and it shows ;/ Just wish I could drive the Ferrari! I know it's awesome! but the Mazda is more affordable(Man hours wise) and gets me to where I want to go without hassle. (I should have said dragster instead of Ferrari... something that is super fast but my blow up and kill you... anyways, you get the point!)
Re: Setting up dmd properly
On Tuesday, 12 January 2016 at 19:38:32 UTC, Jason Jeffory wrote: It seems the whole state of affairs in programming is "Lets do the most minimal work to get X to work in environment Y. To hell with everything else!". The programmers tend to do the most minimal work to code stuff that they can get away with. Since people aren't being paid to do this, and it's not enjoyable for many to make things universally easy across different environments once someone has solved their own problem, you can hardly object to the behaviour - particularly because different people are good at different things, and the guy who creates a project may not be the same guy needed to make it easy to use. Then it's more a question of treating it as a challenge to be solved. It's quite amazing how much a relatively small number of people has accomplished, and it's something of a hazard of open-source that instead of gratitude people receive far more criticism and complaint. (They say a 2:1 balance of positive:negative comments is needed for a healthy relationship). So it's an engineering or institutional challenge - how does one achieve this as a community? This isn't 1984 but coding quality has no increased much since then. A little hyperbolic? ;) We do seem to have higher quality problems today, but do you recall what code from the 80s was like? I've virtually had no problems with it. MS did good job of modernizing the toolchain... Most people that code on linux think that it should be "hard" and gui's suck, that programming is suppose to be a hazing ritual. They setup their system to work for them, and it works... anyone with problems must be ignorant and not "pro programmers". It's kinda this elitist attitude. They spend more time solving 1%'er problems than creating tools that *just* work for 99% of the people. When problems occur it is never their fault but the fault of the ignorant cave man trying to become an godly programmer. Do you think that's actually representative of the attitudes of people here? I haven't seen that. But work won't get done without a plan and without someone to actually do it and one can't force people to do things they don't want to do. A big problem is people don't know what to work on, and maybe some kind of systematic approach to identify problem needs would help. Just search "openGL dmd"(28k) and about 80% of the results are people having problems with getting openGL working with D. "openGL dmd error" has 1M results, thats nearly 30 times the results. It would be a good idea to systematize this and produce a web report so one can see in a more structured way where the biggest difficulties are. I have been talking to Adam a bit about ways we could do this using forum history. I agree with your observation that there is much friction in the way of a new user learning D and that many simply won't persevere long enough. That's nonetheless a better problem to have than having an intrinsically inferior product - one just needs to establish a process, and to have some way of organizing efforts to address these difficulties (which may include funding to a certain extent). I think it's a necessary part of the way D has developed that people have focused on the language and core library first - it's not so long that it has been stable and ready to use and over time better tooling will unfold. (Constructive criticism and ideas may help this process). D has a long way to go to make it competitive... as long as the tooling sucks and there are problems with stupid issues such as coff vs omf, installation issues, ide issues, etc... it won't get off the ground. Depends what the competition is ;) Coff vs OMF will disappear in time as people move to 64 bit. Installation questions seem to be improving. IDE support keeps getting better. For many uses, these things are a one-off price for adopting D. Whether it's feasible to pay that depends on what you are doing and the people you are working with. The D "core" seems to be mainly interested in fixing and enhancing very niche issues in D instead of working on making it a viable and usable candidate for the masses. But it is in the nature of things that disruptive technologies start off as inferior in certain respects and it's only with time that they can be a superior competitor across the board to the dominant technologies. See Clayton Christensen's work "The Innovator's Dilemma". It is what it is, and one can't wave a magic wand to force people to work for free on shiny tools to make it easy. If that's what one wants, then one can do one's small part to encourage this to happen - work on that oneself and contribute it, file bugzilla issues, fund the D foundation (once it is ready). But simply complaining won't change anything. BTW I hardly think that memory allocation, containers, documentation, and web site (recent areas of focus by leadership) are ni
Re: Anyone using glad?
On Tuesday, 12 January 2016 at 19:16:51 UTC, Jason Jeffory wrote: So, I finally got it to work by abandoning demios and static linking. Derelict + dynamic linking worked with only about a min of problems(copying the proper dll to the correct place). I'd prefer static linking but I can deal with that later. Yup, that's a little bit annoying on Windows (also as mentioned before the deimos bindings weren't updated in a while, might contribute to your issue). My current problem is: 1. The code doesn't work as expected: It should show a type of triangle on the display, instead the whole display is colored, probably user error as I cobbled together some tutorial code. 2*. I get an access violation when exiting the program. I have no idea how, why, or where this is happening(except, obviously towards the end of the program... probably a cleanup issue). What does a debugger say? Where is it coming from?
Re: Setting up dmd properly
(I should mention that I am exaggerating a bit, and some of the complaints about D are actually more directed to the programming community in general. D has the same fundamental issues though and it is just a matter of scale. Programming is way more fun when you are actually programming and getting the job done rather than fighting things that should work but don't. As programmers, we get used to that crap.. specially those that programmed in the 70's and 80's... but it doesn't mean it's ok. Specially when we know how to fix it. I really like the D language but the D tool chain should be more user friendly to work with on every level.)
Re: Setting up dmd properly
On Tuesday, 12 January 2016 at 20:38:50 UTC, Laeeth Isharc wrote: On Tuesday, 12 January 2016 at 19:38:32 UTC, Jason Jeffory wrote: It seems the whole state of affairs in programming is "Lets do the most minimal work to get X to work in environment Y. To hell with everything else!". The programmers tend to do the most minimal work to code stuff that they can get away with. Since people aren't being paid to do this, and it's not enjoyable for many to make things universally easy across different environments once someone has solved their own problem, you can hardly object to the behaviour - particularly because different people are good at different things, and the guy who creates a project may not be the same guy needed to make it easy to use. Then it's more a question of treating it as a challenge to be solved. It's quite amazing how much a relatively small number of people has accomplished, and it's something of a hazard of open-source that instead of gratitude people receive far more criticism and complaint. (They say a 2:1 balance of positive:negative comments is needed for a healthy relationship). So it's an engineering or institutional challenge - how does one achieve this as a community? This isn't 1984 but coding quality has no increased much since then. A little hyperbolic? ;) We do seem to have higher quality problems today, but do you recall what code from the 80s was like? I've virtually had no problems with it. MS did good job of modernizing the toolchain... Most people that code on linux think that it should be "hard" and gui's suck, that programming is suppose to be a hazing ritual. They setup their system to work for them, and it works... anyone with problems must be ignorant and not "pro programmers". It's kinda this elitist attitude. They spend more time solving 1%'er problems than creating tools that *just* work for 99% of the people. When problems occur it is never their fault but the fault of the ignorant cave man trying to become an godly programmer. Do you think that's actually representative of the attitudes of people here? I haven't seen that. But work won't get done without a plan and without someone to actually do it and one can't force people to do things they don't want to do. A big problem is people don't know what to work on, and maybe some kind of systematic approach to identify problem needs would help. Just search "openGL dmd"(28k) and about 80% of the results are people having problems with getting openGL working with D. "openGL dmd error" has 1M results, thats nearly 30 times the results. It would be a good idea to systematize this and produce a web report so one can see in a more structured way where the biggest difficulties are. I have been talking to Adam a bit about ways we could do this using forum history. I agree with your observation that there is much friction in the way of a new user learning D and that many simply won't persevere long enough. That's nonetheless a better problem to have than having an intrinsically inferior product - one just needs to establish a process, and to have some way of organizing efforts to address these difficulties (which may include funding to a certain extent). I think it's a necessary part of the way D has developed that people have focused on the language and core library first - it's not so long that it has been stable and ready to use and over time better tooling will unfold. (Constructive criticism and ideas may help this process). D has a long way to go to make it competitive... as long as the tooling sucks and there are problems with stupid issues such as coff vs omf, installation issues, ide issues, etc... it won't get off the ground. Depends what the competition is ;) Coff vs OMF will disappear in time as people move to 64 bit. Installation questions seem to be improving. IDE support keeps getting better. For many uses, these things are a one-off price for adopting D. Whether it's feasible to pay that depends on what you are doing and the people you are working with. The D "core" seems to be mainly interested in fixing and enhancing very niche issues in D instead of working on making it a viable and usable candidate for the masses. But it is in the nature of things that disruptive technologies start off as inferior in certain respects and it's only with time that they can be a superior competitor across the board to the dominant technologies. See Clayton Christensen's work "The Innovator's Dilemma". It is what it is, and one can't wave a magic wand to force people to work for free on shiny tools to make it easy. If that's what one wants, then one can do one's small part to encourage this to happen - work on that oneself and contribute it, file bugzilla issues, fund the D foundation (once it is ready). But simply complaining won't change anything. BTW I hardly think that memory allocation, containers, do
Declaring extern(C) declarations with template mixins
Is this supposed to work:
template Foo()
{
extern(C) int printf(in char*, ...);
}
mixin Foo;
void main()
{
printf("foo\n");
}
It fails with a linker error, undefined symbol, due to not applying C
mangling:
Undefined symbols for architecture x86_64:
"__D4main8__mixin76printfUxPaYi", referenced from:
__Dmain in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
--
/Jacob Carlborg
Re: Declaring extern(C) declarations with template mixins
On Tuesday, 12 January 2016 at 21:22:46 UTC, Jacob Carlborg wrote:
Is this supposed to work:
template Foo()
{
extern(C) int printf(in char*, ...);
}
mixin Foo;
void main()
{
printf("foo\n");
}
It fails with a linker error, undefined symbol, due to not
applying C mangling:
Undefined symbols for architecture x86_64:
"__D4main8__mixin76printfUxPaYi", referenced from:
__Dmain in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to
see invocation)
https://issues.dlang.org/show_bug.cgi?id=12575
Scale-Hierarchy on ndslice
Have anybody been thinking about adding a scale-hierarchy structure on top of ndslice? I need this to implementing some cool signal/image processing algorithms in D. When processing an image this structure is called a Mipmap.
Re: Anyone using glad?
On Tuesday, 12 January 2016 at 19:16:51 UTC, Jason Jeffory wrote:
So, I finally got it to work by abandoning demios and static
linking. Derelict + dynamic linking worked with only about a
min of problems(copying the proper dll to the correct place).
Every operating system has a well-defined search path for dynamic
libraries. On Windows, the first location searched is the
directory in which the executable resides. That's usually the
simplest place to put it. When working with dub, I usually set a
targetPath directive to "bin" in the configuration, so my project
tree looks something like this:
- project
--bin
--source
--dub.sdl
Then I dump all of the DLLs I need in the bin directory. On other
platforms, it's customary for libraries to be installed in
standard system paths, but on windows all but "system" libraries
(such as the Win32 libs and OpenGL) are usually shipped with the
app.
Derelict allows you to specify the path to the libraries you need
to load. So you can, for example, put your glfw3.dll in a
subdirectory off of the bin directory, or change the name. Then
you would load it, for example, like so:
DerelictGLFW3.load("dlls/glfw3_32.dll");
In this case, it doesn't matter which compiler or linker was used
to build the DLL. It could have been built with GCC, VC, or DMC.
The COFF/OMF issue disappears here.
Re: Setting up dmd properly
On Tuesday, 12 January 2016 at 21:08:30 UTC, Jason Jeffory wrote: (I should mention that I am exaggerating a bit, and some of the complaints about D are actually more directed to the programming community in general. D has the same fundamental issues though and it is just a matter of scale. Programming is way more fun when you are actually programming and getting the job done rather than fighting things that should work but don't. As programmers, we get used to that crap.. specially those that programmed in the 70's and 80's... but it doesn't mean it's ok. Specially when we know how to fix it. I really like the D language but the D tool chain should be more user friendly to work with on every level.) I think there's another side of this in that what is an issue for one person isn't necessarily an issue for another. For example, your difficulties with static linking... you aren't the first person to have this problem, but I personally never have. It all seems quite straight forward to me. I was annoyed by the COFF/OMF issue when I first started using D, sure, and that's what prompted me to start Derelict), but it's never been a problem that prevented me from building my D projects. The way to solve this particular sort of problem is to have more documentation, or tutorials, but that requires someone with the time and motivation to write it. People who aren't having that problem are going to be motivated to direct their time and energy elsewhere. So I don't see this as an issue of "getting used to" a bad situation, just one of varying opinions about what part of the situation is bad. I'm going to make an effort toward improving the situation with my learningd.org site. Linking with C libraries would be a good topic for a tutorial to go there. There is also some movement behind the scenes right now to create a comprehensive web site for teaching all things D, but it's going to be after the next DConf before any concrete effort is made in that direction. As for the toolchain... Until there is a dedicated team with a clear goal-oriented task list and the management necessary to keep development focused on those tasks, then development will go in the direction that the core contributors feel they need to direct their efforts. Anyone can champion a new cause in D's development, and several have over the years. That's what has driven the project forward. There have been many, many, many discussions over the years about how unfriendly D is to new users, or how difficult it is to get up and running with this or that aspect of the toolchain. Most of them have resulted in improvements. As a long time D user, I can tell you that you kids have it much better than we did back in the day. So things will get easier with time. Pre-D experience is what determines the degree of difficulty in getting started with D right now. For example, programmers who are comfortable with the command line, particularly when using C or C++, tend to have few difficulties with the toolchain. I'm hoping that the recent creation of the D Foundation will create opportunities to make it easier for /anyone/ to hit the ground running with D.
Re: [Dlang] Delegate Syntax Question
On Sunday, 10 January 2016 at 14:32:02 UTC, Jack wrote:
Hello. So I was trying to pass a delegate as an argument in a
function and was wondering if I'm writing the correct code for
it.
You see my code is :
//
class Foo()
{
void bar()
{
writeln("Hello World");
}
}
class Bar()
{
void delegate() action;
void setAction(void delegate() dele)
{
action = dele;
}
}
void main()
{
Foo foo = new Foo();
Bar bar = new Bar();
bar.setAction(&foo.bar);
bar.action();
}
/
Is this correct? Because I've been having trouble calling the
delegate when passing the method and I read many documentation
concerning function and delegates. I'm just confused.
(Disclaimer: My code's pattern is the same as above but it's
not really my exact code)
Replying to my self because I don't know how I can reply to two
posts at once.
Thank you for helping. I've had a problem on handling delegates
in my code so I was not sure if it was working. I'll post here if
I can't find the solution.
mixed-in ctor not on par with explicit one?
Hello. Compiling the following code:
mixin template intCtor() { this(int i) {} }
struct Test { mixin intCtor; this(string s) {} }
void main()
{
auto a = Test("hello");
auto b = Test(1);
}
...gives the error:
(6): Error: constructor .Test.this (string s) is not callable
using argument types (int)
What is the problem in calling the mixed-in ctor?
--
Shriramana Sharma, Penguin #395953
CAS and atomicOp!"" memory ordering?
Why is there no way to specify the desired memory order with these? What memory order am I supposed to assume? The documentation is sparse.
Re: Setting up dmd properly
On Wednesday, 13 January 2016 at 01:40:59 UTC, Mike Parker wrote: On Tuesday, 12 January 2016 at 21:08:30 UTC, Jason Jeffory wrote: (I should mention that I am exaggerating a bit, and some of the complaints about D are actually more directed to the programming community in general. D has the same fundamental issues though and it is just a matter of scale. Programming is way more fun when you are actually programming and getting the job done rather than fighting things that should work but don't. As programmers, we get used to that crap.. specially those that programmed in the 70's and 80's... but it doesn't mean it's ok. Specially when we know how to fix it. I really like the D language but the D tool chain should be more user friendly to work with on every level.) I think there's another side of this in that what is an issue for one person isn't necessarily an issue for another. For example, your difficulties with static linking... you aren't the first person to have this problem, but I personally never have. It all seems quite straight forward to me. I was annoyed by the COFF/OMF issue when I first started using D, sure, and that's what prompted me to start Derelict), but it's never been a problem that prevented me from building my D projects. The way to solve this particular sort of problem is to have more documentation, or tutorials, but that requires someone with the time and motivation to write it. People who aren't having that problem are going to be motivated to direct their time and energy elsewhere. So I don't see this as an issue of "getting used to" a bad situation, just one of varying opinions about what part of the situation is bad. I'm going to make an effort toward improving the situation with my learningd.org site. Linking with C libraries would be a good topic for a tutorial to go there. There is also some movement behind the scenes right now to create a comprehensive web site for teaching all things D, but it's going to be after the next DConf before any concrete effort is made in that direction. As for the toolchain... Until there is a dedicated team with a clear goal-oriented task list and the management necessary to keep development focused on those tasks, then development will go in the direction that the core contributors feel they need to direct their efforts. Anyone can champion a new cause in D's development, and several have over the years. That's what has driven the project forward. There have been many, many, many discussions over the years about how unfriendly D is to new users, or how difficult it is to get up and running with this or that aspect of the toolchain. Most of them have resulted in improvements. As a long time D user, I can tell you that you kids have it much better than we did back in the day. So things will get easier with time. Pre-D experience is what determines the degree of difficulty in getting started with D right now. For example, programmers who are comfortable with the command line, particularly when using C or C++, tend to have few difficulties with the toolchain. I'm hoping that the recent creation of the D Foundation will create opportunities to make it easier for /anyone/ to hit the ground running with D. Yes, but the world consists of many differnet programmers, and due the the interaction of different things, which is exponential, it is too complex to solve each persons problems on a one by one basis. What works for you works for you because you are you... not because you are me(not trying to make a Beatles song here). e.g., if write your total system configuration in a list, and I write mine, then just about every element in the list interacts with every other element and creates new dependency problems. The amount of potential issues it the powerset of all the items. e.g., ubuntu 14.3, dmd 2.062, glad opengl, etc... windows, dmd 2.061, derelict opengl, etc... Each item in your list has to interact with each other, and in each case it may or may not work well for you. But my list is totally different and you can't say "It works for me"... because it doesn't help me in any way. dmd 2.061 may have a bug in the windows version and the derelict version that is not exhibited by the linux case. Because the problem is so complex, the only way to make it work is that the elements themselves have to work well individually(basically because we can't code for every combination). This is why we have to break complex systems down into simple well understood parts. But information is the here. One has to have some way to "measure" progress(ask Andrei, he said that in his performance lecture). If a tool doesn't give results that can be compared, we can't see how we are solve the problem and it usually requires guess, looking up stuff online for similar problems/solutions, and usually a lot of wasted time. So, the solution to all this is not solving the problems after
Re: Anyone using glad?
On Tuesday, 12 January 2016 at 20:48:37 UTC, Dav1d wrote: On Tuesday, 12 January 2016 at 19:16:51 UTC, Jason Jeffory wrote: So, I finally got it to work by abandoning demios and static linking. Derelict + dynamic linking worked with only about a min of problems(copying the proper dll to the correct place). I'd prefer static linking but I can deal with that later. Yup, that's a little bit annoying on Windows (also as mentioned before the deimos bindings weren't updated in a while, might contribute to your issue). My current problem is: 1. The code doesn't work as expected: It should show a type of triangle on the display, instead the whole display is colored, probably user error as I cobbled together some tutorial code. 2*. I get an access violation when exiting the program. I have no idea how, why, or where this is happening(except, obviously towards the end of the program... probably a cleanup issue). What does a debugger say? Where is it coming from? It doesn't I put a break point on the glfwTerminate() and what visual studio/d shows is something in the "import derelict.glfw3.glfw3;" statement. Well, a BP on on glfwTerminate is never reached. Hence it must be before that. The loop should work fine because it works already. One would think it is the while (!glfwWindowShouldClose(window)), but using just a global variable still causes the exception. Hence the logical place the except should be occurring is glfwPollEvents(); If I remove it and just use a counter and exit after while, then there is no exception. Hence, it must be glfwPollEvents(); But what can I do about that? Must be an issue with Derelict or glfw! Since Derelict is just bindings, it suggests glfw. But what possibly could be wrong?
