Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

On Wednesday, 13 January 2016 at 18:40:39 UTC, Dav1d wrote:
On Wednesday, 13 January 2016 at 17:43:54 UTC, Jason Jeffory 
wrote:

On Wednesday, 13 January 2016 at 16:04:32 UTC, Dav1d wrote:
On Wednesday, 13 January 2016 at 06:30:44 UTC, Jason Jeffory 
wrote:

[...]


That's not correct.
Build a debug build and check the stacktrace which should be 
printed, if not open gdb or any other debugger and set a 
breakpoint on the exception. Iirc you can break on _d_throw 
and check the stacktrace, then you know where it actually is 
coming from.


Either I don't get what you are talking about, or VS doesn't 
do what you think it does.


When I run the program, this is the stack trace. VS pops up 
with an "Exception has been thrown" window and it highlights 
the "import derelict.glfw3.glfw3;" line. I can't get any 
further than that. It is a debug build. But the except is not 
coming directly from the test.d code.


user32.dll!74d94790 
user32.dll!74d94527 
opengl32.dll!5946caa3   
user32.dll!74db4923 
user32.dll!74d94790 
user32.dll!74d94091 
user32.dll!74d93e50 
glfw3.dll!59525797  
glfw3.dll!5952792c  
 
	test.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv() + 0x1b bytes	D
 	test.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv() 
+ 0x23 bytes	D

test.exe!__d_run_main() + 0x20c bytes   D

test.exe!__entrypoint.main() Line 7 + 0x11 bytesD

test.exe!_mainCRTStartup() + 0xa9 bytes D


I'm not sure what you are expecting to happen. I can't step in 
to anything to see more detail and the lines that VS is 
showing where the problem is, is not steppable. It maybe a 
weird issue with VisualD. I will try gbd for windows, but have 
to install it and learn how to use it.


Yup that trace looks like a glfw issue not sure what causes 
it... that stacktrace on the other hand isn't really that 
helpful, it doesn't show what function call caused it only that 
it happens somewhere in glfw then possibly the driver.


I never used the VS debugger .. so no idea if you're doing it 
wrong or VS is simply not capable of debugging it.


Psudeo gdb session:


r

/* crashes here */

bt full


Or if an exception is thrown


b _d_throw
r
bt full



I don't know ;/ The SIGSEGV happens when I hit a key to exit the 
program.




This binary was built by Equation Solution 
...
Reading symbols from test.exe...(no debugging symbols 
found)...done.

(gdb) r
Starting program: B:\Software\test\test.exe
[New Thread 8660.0x1310]
warning: `C:\Windows\SYSTEM32\ntdll.dll': Shared library 
architecture i386:x86-64 is not compatible with target 
architecture i386.
warning: `C:\Windows\system32\wow64.dll': Shared library 
architecture i386:x86-64 is not compatible with target 
architecture i386.
warning: `C:\Windows\system32\wow64win.dll': Shared library 
architecture i386:x86-64 is not compatible with target 
architecture i386.
warning: Could not load shared library symbols for 
WOW64_IMAGE_SECTION.

Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for 
WOW64_IMAGE_SECTION.

Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: Could not load shared library symbols for NOT_AN_IMAGE.
Do you need "set solib-search-path" or "set sysroot"?
warning: `C:\Windows\system32\wow64cpu.dll': Shared library 
architecture i386:x86-64 is not compatible with target 
architecture i386.

[New Thread 8660.0x1160]
[New Thread 8660.0xe00]
[New Thread 8660.0x2068]
[New Thread 8660.0xb58]
[New Thread 8660.0x231c]
[New Thread 8660.0x1b3c]
[New Thread 8660.0x21bc]
[Thread 8660.0xb58 exited with code 0]
[New Thread 8660.0x2488]
[Thread 8660.0x1b3c exited with code 0]
[New Thread 8660.0x27cc]
[New Thread 8660.0x237c]
[Thread 8660.0x237c exited with code 0]
[Thread 8660.0x27cc exited with code 0]
[New Thread 8660.0x2088]
[New Thread 8660.0x241c]
OpenGL Version 3.3 loaded
Key Pressed = 32 <-- I hit a key to exit and the 
SIGSEGV happens


Program received signal SIGSEGV, Segmentation fault.
0x002b in ?? ()
(gdb) bt full
#0  0x002b in ?? ()
No symbol table info available.
Cannot access memory at address 0x44
(gdb) b _d_throw
Function "_d_throw" not defined.
Make breakpoint pending on future shared library load? (y or [n]) 
y

Breakpoint 1 (_d_throw) pending.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: B:\Software\test\test.exe
[New Thread 8408.0x1a5c]
warning: `C:\Windows\SYSTEM32\ntdll.dll': Shared library 
architecture i386:x86-64 is not compatible with target 
architecture i386.
warning: `C:\Windows\system32\wow64.dll': Shared library 
architecture i386:x86-64 is not compatible with target 
architecture i386.
warning: 

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

What I can't seem to figure out why

try { loop }
catch
{

}

catches the exception but

try { loop }
catch (Throwable t) // Only diff
{

}

doesn't ;/ Probably my ignorance about D, but I was hoping to get 
some info about the exception this way(line number, etc...)

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

On Wednesday, 13 January 2016 at 20:13:49 UTC, Dav1d wrote:
On Wednesday, 13 January 2016 at 19:20:40 UTC, Jason Jeffory 
wrote:

What I can't seem to figure out why

try { loop }
catch
{

}

catches the exception but

try { loop }
catch (Throwable t) // Only diff
{

}

doesn't ;/ Probably my ignorance about D, but I was hoping to 
get some info about the exception this way(line number, etc...)


This is not an exception you should catch at all. Also pretty 
sure this wont work with 64bit binaries.
D does realize a segmentation fault, access to invalid memory, 
that's nothing a program should simply catch and then silently 
ignore, the issue causing it needs to be addressed.




It was for testing purposes and to try and figure out what is 
going on.


Also why doesn't your key_callback not to be extern(C), I 
thought that was required.


The app never exits with extern(C), it doesn't crash though.

'Reading symbols from test.exe...(no debugging symbols 
found)...done.', you arent gonna get any useful information 
without debug symbols. Also additionally use a glfw debug build.


Why aren't the debug symbols added in a debug build? Makes no 
sense!


I don't have a debug build of glfw.

...

After an few hours of fucking with cmake, turns out it had a bug. 
Updated it and worked. Pretty much through with this crap. I'm 
not going to waste any more time screwing with the dysfunctional 
approach that software design is taking. I appreciate your help. 
See you on the flip side! Have fun crawling through the sewers of 
"modern" programming!

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

On Wednesday, 13 January 2016 at 16:04:32 UTC, Dav1d wrote:
On Wednesday, 13 January 2016 at 06:30:44 UTC, Jason Jeffory 
wrote:

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:

[...]


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).



[...]


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?


That's not correct.
Build a debug build and check the stacktrace which should be 
printed, if not open gdb or any other debugger and set a 
breakpoint on the exception. Iirc you can break on _d_throw and 
check the stacktrace, then you know where it actually is coming 
from.


Either I don't get what you are talking about, or VS doesn't do 
what you think it does.


When I run the program, this is the stack trace. VS pops up with 
an "Exception has been thrown" window and it highlights the 
"import derelict.glfw3.glfw3;" line. I can't get any further than 
that. It is a debug build. But the except is not coming directly 
from the test.d code.


user32.dll!74d94790 
user32.dll!74d94527 
opengl32.dll!5946caa3   
user32.dll!74db4923 
user32.dll!74d94790 
user32.dll!74d94091 
user32.dll!74d93e50 
glfw3.dll!59525797  
glfw3.dll!5952792c  
 
	test.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv() + 0x1b bytes	D
 	test.exe!_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZv() + 
0x23 bytes	D

test.exe!__d_run_main() + 0x20c bytes   D

test.exe!__entrypoint.main() Line 7 + 0x11 bytesD

test.exe!_mainCRTStartup() + 0xa9 bytes D


I'm not sure what you are expecting to happen. I can't step in to 
anything to see more detail and the lines that VS is showing 
where the problem is, is not steppable. It maybe a weird issue 
with VisualD. I will try gbd for windows, but have to install it 
and learn how to use it.

Re: Setting up dmd properly

[Jason Jeffory via Digitalmars-d-learn]

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?

[Jason Jeffory via Digitalmars-d-learn]

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?

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

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)_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, );
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, );
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, , null);
glCompileShader(vsh);
glAttachShader(program, vsh);
// Fragment Shader
auto fsh = glCreateShader(GL_FRAGMENT_SHADER);
auto fshSrc = minimalFragmentShader.toStringz;
glShaderSource(fsh, 1, , 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 && action == GLFW_PRESS)
  

Re: Setting up dmd properly

[Jason Jeffory via Digitalmars-d-learn]

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

[Jason Jeffory via Digitalmars-d-learn]

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, 

Re: Setting up dmd properly

[Jason Jeffory via Digitalmars-d-learn]

(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: LINK : fatal error LNK1104: cannot open file '_CMDLINE' --- errorlevel 1104

[Jason Jeffory via Digitalmars-d-learn]

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

[Jason Jeffory via Digitalmars-d-learn]

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?

LINK : fatal error LNK1104: cannot open file '_CMDLINE' --- errorlevel 1104

[Jason Jeffory via Digitalmars-d-learn]

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

[Jason Jeffory via Digitalmars-d-learn]

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: Setting up dmd properly

[Jason Jeffory via Digitalmars-d-learn]

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?

[Jason Jeffory via Digitalmars-d-learn]

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: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

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).


2. I had to commend out the following code dealing with the 
keyboard callback:


// Set the required callback functions
//glfwSetKeyCallback(window, _callback);

gives the error

function app.key_callback (GLFWwindow* window, int key, int 
scancode, int action, int mode) is not callable using argument 
types ()


I tried with and without address passing. I can cast though

glfwSetKeyCallback(window, cast(GLFWkeyfun)_callback);

works(no errors, at least), and if that's correct, leaves only 
the lib issue.




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);






import std.stdio;

import glad.gl.all;
import deimos.glfw.glfw3;



// Window dimensions
const GLuint WIDTH = 800, HEIGHT = 600;

void main()
{

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, _callback);

	//(gladLoadGL()); // optionally you can pass a loader to this 
function
	//writefln("OpenGL Version %d.%d loaded", GLVersion.major, 
GLVersion.minor);


/*
if (!gladLoadGLLoader(cast(GLADloadproc) glfwGetProcAddress))
{
writeln("Failed to initialize OpenGL context");
return;
}*/

// Define the viewport dimensions
glViewport(0, 0, WIDTH, HEIGHT);

// 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(0.2f, 0.3f, 0.3f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT);

// 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)

{
writeln(key);
if (key == GLFW_KEY_ESCAPE && action == GLFW_PRESS)
glfwSetWindowShouldClose(window, GL_TRUE);
}

Re: Setting up dmd properly

[Jason Jeffory via Digitalmars-d-learn]

On Monday, 11 January 2016 at 01:24:44 UTC, Jason Jeffory wrote:

On Monday, 11 January 2016 at 01:22:28 UTC, 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...

This way, issues between 64 and 32 paths can easily be seen... 
figuring out exactly what sc.ini is doing is easier, etc...


We know it is accurate because it would come from the compiler 
itself. No guessing.


Probably a dmd app could be created that does this instead? 
Basically I've ran into issues before setting up D because of 
path issues(again, the sc.ini file is pretty crappy... 
littered with duplicate symbols and different paths with 
"hacks" for different compilers and all that(it's just not 
sain)). It tends to make me hesitant dealing with dmd in some 
cases. Something that should take a min to do can take hours 
trying to track down some weird issue simply because of a 
typo... and there's no way to know exactly what the compiler 
is "seeing"... I really hope something like this already 
exists.


Also, any linked in libraries could report there format and 
such. I've had problems figuring out certain coeff libs issues 
and all that. Knowing exactly what's going on is a good thing, 
right?!?!?


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.

Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

Seems like it is a very nice way to get into openGL from D.

http://glad.dav1d.de/

I generated the bindings for all the latest versions of the 
various specifications.

Does anyone have any tutorials that use this library effectively?

There's this

https://github.com/Dav1dde/glamour

But not sure what it is(diff between it and glad). Says it's a 
wrapper to OpenGL... but does it use the glad generated bindings?


It looks like I'd prefer this to derelict because it seems like 
it is a automatically generated binding... which means future 
extensibility and no "extra" stuff.


Would be nice if it works with dub. How could I use it easily 
with dub as a local library? (create a dependency from a local 
file location)


Thanks.

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

On Sunday, 10 January 2016 at 21:53:45 UTC, Dav1d wrote:

On Sunday, 10 January 2016 at 21:30:32 UTC, Jason Jeffory wrote:

Seems like it is a very nice way to get into openGL from D.

http://glad.dav1d.de/

I generated the bindings for all the latest versions of the 
various specifications.
Does anyone have any tutorials that use this library 
effectively?


There's this

https://github.com/Dav1dde/glamour

But not sure what it is(diff between it and glad). Says it's a 
wrapper to OpenGL... but does it use the glad generated 
bindings?


It looks like I'd prefer this to derelict because it seems 
like it is a automatically generated binding... which means 
future extensibility and no "extra" stuff.


Would be nice if it works with dub. How could I use it easily 
with dub as a local library? (create a dependency from a local 
file location)


Thanks.


Hey,

I am the guy behind glad, you are most likely looking for: 
https://github.com/Dav1dde/glad#d
Instead of downloading the glad sources and installing Python 
you can use the website http://glad.dav1d.de/
(If I have time I will write more documentation and also have 
it on the website)


glad is just another way to load your OpenGL functions (kinda 
like Derelict does it), the main difference is, it exactly 
allows you to generate the feature set you need, if you're in 
doubt, you can also just generate everything.


Another difference is, it uses the official XML-Specification 
files, so it is always up to date and doesn't need to be 
maintained. This also means it can can generate files for 
EGL/GLES/WGL and GLX.


Glad itself is a library which happens to include a D generator 
'backend', that allows you to extend it and make a more 
advanced loader (e.g. introduce another layer and automatically 
check glGetError, see C/C++ Debug), but for your normal use the 
included generator is good enough.


Usage:

Basically you download the zip, add the source files to your 
project and build system and call gladLoadGL() (check the 
return value, `enforce(gladLoadGL())`) after creating a 
context. This will use the internal loader, if you use glfw you 
can pass glfwGetProcAddress to gladLoadGL(), if you use SDL you 
can use SDL_GL_GetProcAddress: `gladLoadGL(x => 
glfwGetProcAddress(x))`.


Then you can just go ahead and call the imported gl functions.

Why no dub?:

Well why would you want to use dub? Just generate the files and 
copy them into your source.




I also wrote glamour, glamour is just a library which abstracts 
the the OpenGL API and has some glue code for gl3n (maths), SDL 
(texture loading), glad/Derelict (for gl).



Cool, it looks really well done. I spend several hours 
researching and looking at various approaches. It was basically 
Derelict stuff or a lot of things that didn't look well done. I 
was wishing there was something that would automatically do 
it(looked into htod, swift, etc)... then I stumbled across your 
work!!! Was exactly what I wanted!


glfw is separate or have you done something with it(is it wgl?)?

I'm basically trying to get a minimal setup running on winx64. I 
don't want a lot of hassle that other "solutions" seem to have(no 
derelict, sdl, etc...). I know there has to be some windows 
stuff(glfw) haven't yet found a solution for it(haven't really 
looked yet).

Re: Anyone using glad?

[Jason Jeffory via Digitalmars-d-learn]

On Sunday, 10 January 2016 at 23:14:33 UTC, Dav1d wrote:

On Sunday, 10 January 2016 at 22:37:28 UTC, Jason Jeffory wrote:

[...]


I would recommend using glfw for a context/window, there is a 
binding in Deimos https://github.com/D-Programming-Deimos/glfw 
- You need to either compile it yourself or just download the 
pre compiled package from the website and get the .lib file 
(http://www.glfw.org/).


There is also an abstraction I wrote once: 
https://github.com/Dav1dde/glwtf not sure if it still works, it 
*should*.
But even without the abstraction, getting a window and context 
up with glfw is really easy (documentation is really good! 
http://www.glfw.org/documentation.html). There is also a C++ 
example using glad: 
https://github.com/Dav1dde/glad/blob/master/example/c%2B%2B/hellowindow2.cpp which can easily be ported to D.


Basically all you need is glfw and glad to get started!


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!

Setting up dmd properly

[Jason Jeffory via Digitalmars-d-learn]

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...

This way, issues between 64 and 32 paths can easily be seen... 
figuring out exactly what sc.ini is doing is easier, etc...


We know it is accurate because it would come from the compiler 
itself. No guessing.


Probably a dmd app could be created that does this instead? 
Basically I've ran into issues before setting up D because of 
path issues(again, the sc.ini file is pretty crappy... littered 
with duplicate symbols and different paths with "hacks" for 
different compilers and all that(it's just not sain)). It tends 
to make me hesitant dealing with dmd in some cases. Something 
that should take a min to do can take hours trying to track down 
some weird issue simply because of a typo... and there's no way 
to know exactly what the compiler is "seeing"... I really hope 
something like this already exists.

Re: Setting up dmd properly

[Jason Jeffory via Digitalmars-d-learn]

On Monday, 11 January 2016 at 01:22:28 UTC, 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...

This way, issues between 64 and 32 paths can easily be seen... 
figuring out exactly what sc.ini is doing is easier, etc...


We know it is accurate because it would come from the compiler 
itself. No guessing.


Probably a dmd app could be created that does this instead? 
Basically I've ran into issues before setting up D because of 
path issues(again, the sc.ini file is pretty crappy... littered 
with duplicate symbols and different paths with "hacks" for 
different compilers and all that(it's just not sain)). It tends 
to make me hesitant dealing with dmd in some cases. Something 
that should take a min to do can take hours trying to track 
down some weird issue simply because of a typo... and there's 
no way to know exactly what the compiler is "seeing"... I 
really hope something like this already exists.


Also, any linked in libraries could report there format and such. 
I've had problems figuring out certain coeff libs issues and all 
that. Knowing exactly what's going on is a good thing, right?!?!?

Re: Are there any D scripting engines for use with D?

[Jason Jeffory via Digitalmars-d-learn]

On Tuesday, 5 January 2016 at 17:37:00 UTC, Chris Wright wrote:

On Mon, 04 Jan 2016 20:04:48 +0100, Max Klyga wrote:
Croc (previously miniD, a scripting language implemented in D) 
-

http://jfbillingsley.com/croc/


Croc is written in C++. Jarrett got annoyed with D around the 
D2 switch.


MiniD is written for D1 and Tango. It would be nontrivial to 
port it to D2.


Oh ;/ It was looking interesting ;/ I guess one would just need 
bindings?

Are there any D scripting engines for use with D?

[Jason Jeffory via Digitalmars-d-learn]

We have many scripting engines available for use in D more or 
less(lua, python, etc...).


Is there a D scripting engine that can be easily integrated into 
a D project? A sort of "exec()". Something that works at 
compile time and run time possibly? If  is a static string 
then it should be able to compile it at compile time, else, run 
time. Also, it would be nice if one could set up a unique state 
for the code to run in(so it can't be hacked by harmful coding), 
e.g., "exec(, state)", where state is the state used for 
the exec(passed along to the  to use) for external 
function access and variable passing.


Something that is fast as possible would be nice too! I know 
there this is quite a request, but hopefully there will be work 
on it. I'd love to see scripting capabilities included with most 
programs! This would be a start, at least, for my programs.

Re: Are there any D scripting engines for use with D?

[Jason Jeffory via Digitalmars-d-learn]

On Monday, 4 January 2016 at 19:25:18 UTC, yawniek wrote:

On Monday, 4 January 2016 at 19:04:48 UTC, Max Klyga wrote:

On 2016-01-04 18:40:03 +, Jason Jeffory said:
The fastest one would probably be Lua - 
http://code.dlang.org/search?q=lua

But there are other options:
Python - http://code.dlang.org/packages/pyd
Javascript - http://code.dlang.org/search?q=javascript and 
http://pointersgonewild.com/higgs/
Croc (previously miniD, a scripting language implemented in D) 
- http://jfbillingsley.com/croc/


there is also
http://code.dlang.org/packages/d_mruby
mruby is really nice.

but i agree,
a more native language that would not need to push data via a 
stack
but instead had direct access to strings or defined objects 
would be something

really helpful.


All these are ok, luaD being the preferred choice(croc looks nice 
but haven't spent much time with it).


I'd prefer a D based scripting engine.

I suppose one could simply compile the code for each change, but 
seems like it would be a mess. The ability to debug and provide 
real time changes would be great.

Re: Deit Editor

[Jason Jeffory via Digitalmars-d-learn]

On Sunday, 3 January 2016 at 18:53:10 UTC, Martin Tschierschke 
wrote:

On Friday, 1 January 2016 at 00:14:08 UTC, Jason Jeffory wrote:
Vibe.d uses deit files for html generation. Seems nice but 
haven't dived into it(just removes a but of nonsense and 
allows code integration for dynamic generation... sounds 
great!!).


But what about visual editing? It's nice to be ale to see the 
layout of the page directly without all the hassle of toggling 
back and forth between a browser and code editor. Also, there 
is the issue of syntax highlighting, code validation, etc...


I came across this

http://stackoverflow.com/questions/16080350/using-jade-with-wysiwyg-markdown-to-allow-users-to-edit-content

Any ideas to make life easier? (isn't that what it's all 
about?)


There was an answer pointing to 
https://www.npmjs.org/package/html2jade
and this to http://html2jade.aaron-powell.com/, which  allows 
you to convert online HTML to JADE.
So you can make your HTML layout on an traditional way and get 
the jade code.


Doesn't help much because it is not maintainable?

But one could modify the tool to add additional functionality 
with a custom tag?


Use any standard html editor that won't crap out on a custom tag 
and then insert D code into it?


e.g.






Hello

Deit variable referencing

[Jason Jeffory via Digitalmars-d-learn]

Ok, So Deit allows D code inside html... looks great.

But how do external variables work? If I create a variable in the 
server(such as a class), can an html file access it easily? (not 
having to jump through hoops)



doctype html
html
head
title D string interpolations test
body
- import std.algorithm : min;
p Four items ahead:
- foreach( i; 0 .. 4 )
- auto num = i+1;
p Item #{ num + extvar }
//- Unescaped output
p Prints 8: !{ min(10, 2*6, 8) }


here, extvar is a int located somewhere else(other deit html file 
that has ran(hopefully) or vibe.d project that created it.


(Obviously there has to be a way to get extvar)

E.g., If deit can have a special variable called context that 
each html file can access and along with the vibe.d project, then 
we can easily pass the variable.



doctype html
html
head
title D string interpolations test
body
- import std.algorithm : min;
p Four items ahead:
- foreach( i; 0 .. 4 )
- auto num = i+1;
p Item #{ num + (int)context["extvar"] }
//- Unescaped output
p Prints 8: !{ min(10, 2*6, 8) }

or whatever

Deit Editor

[Jason Jeffory via Digitalmars-d-learn]

Vibe.d uses deit files for html generation. Seems nice but 
haven't dived into it(just removes a but of nonsense and allows 
code integration for dynamic generation... sounds great!!).


But what about visual editing? It's nice to be ale to see the 
layout of the page directly without all the hassle of toggling 
back and forth between a browser and code editor. Also, there is 
the issue of syntax highlighting, code validation, etc...


I came across this

http://stackoverflow.com/questions/16080350/using-jade-with-wysiwyg-markdown-to-allow-users-to-edit-content

Any ideas to make life easier? (isn't that what it's all about?)