Re: May be a simple dub answer if my question even makes sense?
On Saturday, 24 September 2016 at 02:33:22 UTC, WhatMeWorry wrote: 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? You don't have to specify the paths of dependencies. dub knows where they are and will make sure the compiler knows, too. 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? Then you execute 'dub upgrade' in the directory where your dub configuration resides. As long as you have the version of each dependency specified properly, it will do the right thing (TIP: use ~>x.x.x for versions, rather than >=x.x.x -- the former will restrict you to patch-level upgrades, e.g. 3.1.0 -> 3.1.1 and never 3.2, while the latter would happily go from 3.x -> 4.0 if it's available, often a breaking change). Did you import the derelict modules you're using in your app.d?
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 = &super.someProtectedFunc;
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 = &super.someProtectedFunc;
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*?
