Re: May be a simple dub answer if my question even makes sense?
On 24/09/2016 2:33 PM, WhatMeWorry wrote: I have D opengl/glfw3 program that I wrote which compiles and runs fine, but I always felt it was a bit of a Visual Studio hack. So I thought I'd start anew but this time use dub from the get go. So I did dub int...etc. And put my existing code into the app.d file. But when I try to build the project with dub build, I get dub build --arch=x86_64 --force Performing "$DFLAGS" build using dmd for x86_64. derelict-util 2.1.0: building configuration "library"... derelict-al 1.0.1: building configuration "library"... derelict-fi 2.0.2: building configuration "library"... derelict-ft 1.1.2: building configuration "library"... derelict-gl3 1.0.19: building configuration "library"... derelict-glfw3 3.1.0: building configuration "derelict-glfw3-dynamic"... 01_01_hello_window ~master: building configuration "application"... source\app.d(154,5): Error: undefined identifier 'glViewport' source\app.d(157,13): Error: undefined identifier 'glfwWindowShouldClose' source\app.d(160,9): Error: undefined identifier 'glfwPollEvents' source\app.d(166,9): Error: undefined identifier 'glClearColor' source\app.d(167,9): Error: undefined identifier 'glClear' source\app.d(170,9): Error: undefined identifier 'glfwSwapBuffers' source\app.d(174,5): Error: undefined identifier 'glfwTerminate' dmd failed with exit code 1. myapp exited with code 2 I see that dub has all the .d import files already placed in C:\Users\Me\AppData\Roaming\dub\packages\derelict-gl3-1.0.19\derelict-gl3\source\derelict\opengl3 and C:\Users\Me\AppData\Roaming\dub\packages\derelict-glfw3-3.1.0\derelict-glfw3\source\derelict\glfw3 which should have all the definitions. Is their an elegant way that I can tell dub to where these definitions? Or do I just have to brute force all the -I paths? I assume there is a slick way of specifying this because what happens when say glfw3-3.1.0 gets bumped up to 3.1.1? Can you please post the dub file? Along with your source file. I have no idea what dub is even trying to do otherwise.
May be a simple dub answer if my question even makes sense?
I have D opengl/glfw3 program that I wrote which compiles and runs fine, but I always felt it was a bit of a Visual Studio hack. So I thought I'd start anew but this time use dub from the get go. So I did dub int...etc. And put my existing code into the app.d file. But when I try to build the project with dub build, I get dub build --arch=x86_64 --force Performing "$DFLAGS" build using dmd for x86_64. derelict-util 2.1.0: building configuration "library"... derelict-al 1.0.1: building configuration "library"... derelict-fi 2.0.2: building configuration "library"... derelict-ft 1.1.2: building configuration "library"... derelict-gl3 1.0.19: building configuration "library"... derelict-glfw3 3.1.0: building configuration "derelict-glfw3-dynamic"... 01_01_hello_window ~master: building configuration "application"... source\app.d(154,5): Error: undefined identifier 'glViewport' source\app.d(157,13): Error: undefined identifier 'glfwWindowShouldClose' source\app.d(160,9): Error: undefined identifier 'glfwPollEvents' source\app.d(166,9): Error: undefined identifier 'glClearColor' source\app.d(167,9): Error: undefined identifier 'glClear' source\app.d(170,9): Error: undefined identifier 'glfwSwapBuffers' source\app.d(174,5): Error: undefined identifier 'glfwTerminate' dmd failed with exit code 1. myapp exited with code 2 I see that dub has all the .d import files already placed in C:\Users\Me\AppData\Roaming\dub\packages\derelict-gl3-1.0.19\derelict-gl3\source\derelict\opengl3 and C:\Users\Me\AppData\Roaming\dub\packages\derelict-glfw3-3.1.0\derelict-glfw3\source\derelict\glfw3 which should have all the definitions. Is their an elegant way that I can tell dub to where these definitions? Or do I just have to brute force all the -I paths? I assume there is a slick way of specifying this because what happens when say glfw3-3.1.0 gets bumped up to 3.1.1?
Re: Vibe.d help
On Thursday, 22 September 2016 at 09:14:46 UTC, Martin Tschierschke wrote: On Thursday, 22 September 2016 at 01:38:12 UTC, Gestalt Theory wrote: 3. How to serve static files properly? sendFile(req, res, Path(req.path)); Does the trick inside the handler. @5. There is a solution, hopefully I can find the link and post it later. Any news on this?
Re: Member not accessible in delegate body
On Friday, 23 September 2016 at 15:29:43 UTC, Rene Zwanenburg
wrote:
On Friday, 23 September 2016 at 07:54:15 UTC, John C wrote:
How is it possible that "onTextChanged" isn't accessible but
the private method "changeSize" *is*?
Smells like an oversight. I guess the compiler doesn't see the
delegate as a member of a Control subclass, so it can't access
protected members. Private works because private in D means
module private.
Please file an issue. As a workaround you can try to take the
address of the method in the closure (untested):
void delegate() foo()
{
auto func =
return () => func(); // I think this will work
}
Quoting the document: "protected only applies inside classes (and
templates as they can be mixed in) and means that a symbol can
only be seen by members of the same module, or by a derived
class."
So protected also means module visibility.
Re: Member not accessible in delegate body
On Friday, 23 September 2016 at 18:20:24 UTC, Martin Nowak wrote: Please file a bug report issues.dlang.org, shouldn't be difficult to fix. Done: https://issues.dlang.org/show_bug.cgi?id=16531
Re: Member not accessible in delegate body
On Friday, 23 September 2016 at 07:54:15 UTC, John C wrote:
If I try to call the protected method of a superclass from
inside the body of a delegate, the compiler won't allow it.
void layoutTransaction(Control c, void delegate() action) {
// do stuff
action();
// do more stuff
}
class Control {
protected void onTextChanged() {}
}
class Label : Control {
protected override void onTextChanged() {
layoutTransaction(this, {
super.onTextChanged(); // <--- Error here
changeSize();
});
}
private void changeSize() {}
}
Output: class Control member onTextChanged is not accessible.
How is it possible that "onTextChanged" isn't accessible but
the private method "changeSize" *is*?
Please file a bug report issues.dlang.org, shouldn't be difficult
to fix.
Re: Member not accessible in delegate body
On Friday, 23 September 2016 at 07:54:15 UTC, John C wrote:
How is it possible that "onTextChanged" isn't accessible but
the private method "changeSize" *is*?
Smells like an oversight. I guess the compiler doesn't see the
delegate as a member of a Control subclass, so it can't access
protected members. Private works because private in D means
module private.
Please file an issue. As a workaround you can try to take the
address of the method in the closure (untested):
void delegate() foo()
{
auto func =
return () => func(); // I think this will work
}
Re: Vibe.d compilation error: backend/cgelem.c 5018 dmd failed with exit code 1.
On Friday, 23 September 2016 at 08:39:44 UTC, llaine wrote: Okay I tried yesterday, after 4hours of process, I never went through the end of minification. At the beginning I enter YES should I enter NO instead? Hmm that's strange. I don't get any yes or no questions. What is the exact message you get? I've been looking into using dustmite with dub a bit, and running dub dustmite "../DustmiteResult" --compiler-regex=".*backend/cgelem\.c 501.*" --build=release in your project directory should just work..
Re: Meta-programming: iterating over a container with different types
On Friday, 23 September 2016 at 09:21:56 UTC, Claude wrote:
...
// Maybe you can try using std.variant?
import std.variant;
alias Component = Variant;
class Entity
{
void register (Component v) { components ~= v; }
void unregister (T) () {
foreach (i, c; components) if (c.type == typeid(T))
components = components[0..i] ~ components[i+1 .. $];
}
Component getComponent (T) () {
foreach (i, c; components) if (c.type == typeid(T))
return components[i];
}
Component[] components;
// iterating over the components
alias components this;
// or you can provide an inputRange interface by implementing
//
// bool empty () {}
// Component front () {}
// void popFront () {}
//
// to support whatever type of backing data structure you
have.
// (see http://ddili.org/ders/d.en/ranges.html)
}
unittest
{
import std.stdio;
Entity e = new Entity();
e.register(Component(42));
e.register(Component("loire"));
e.register(Component(3.14));
foreach (c; e) write(c, " "); writeln; // Prints 42 "loire"
3.14
e.unregister!string;
foreach (c; e) write(c, " "); writeln; // Prints 42 3.14
e.unregister!double;
foreach (c; e) write(c, " "); writeln; // Prints 42
e.unregister!int;
assert(e.components.length == 0);
}
Meta-programming: iterating over a container with different types
It's more a general meta-programming question than a specific D
stuff.
For an entity-component engine, I am trying to do some run-time
composition: registering a certain type (component) to a
structure (entity).
I would like to know how I can iterate an entity and get the
different type instances registered to it.
Here is a simple example to clarify:
class Entity
{
void register!Component(Component val);
void unregister!Component();
Component getComponent!Component();
//iterating over the components (?!??)
void opApply(blabla);
}
unittest
{
// registering
auto e = new Entity;
e.register!int(42);
e.register!string("loire");
e.register!float(3.14);
assert(e.getComponent!float() == 3.14); // that is OK
// the code below is wrong, but how can I make that work??
foreach (c; e)
{
writeln(c); // it would display magically 42, "loire" and 3.14
// and c would have the correct type at each step
}
}
Re: Vibe.d compilation error: backend/cgelem.c 5018 dmd failed with exit code 1.
On Thursday, 22 September 2016 at 14:40:10 UTC, Saurabh Das wrote: On Thursday, 22 September 2016 at 10:44:29 UTC, llaine wrote: dub dustmite ./dustmite_output/ --compiler-regex="Internal Error" -b release Okay I tried yesterday, after 4hours of process, I never went through the end of minification. At the beginning I enter YES should I enter NO instead?
Member not accessible in delegate body
If I try to call the protected method of a superclass from inside
the body of a delegate, the compiler won't allow it.
void layoutTransaction(Control c, void delegate() action) {
// do stuff
action();
// do more stuff
}
class Control {
protected void onTextChanged() {}
}
class Label : Control {
protected override void onTextChanged() {
layoutTransaction(this, {
super.onTextChanged(); // <--- Error here
changeSize();
});
}
private void changeSize() {}
}
Output: class Control member onTextChanged is not accessible.
How is it possible that "onTextChanged" isn't accessible but the
private method "changeSize" *is*?
