Re: std.socket replacement
On Sunday, 29 November 2015 at 18:00:34 UTC, tired_eyes wrote:
On Sunday, 29 November 2015 at 16:10:22 UTC, Alex Parrill wrote:
std.stream, and the stream interface in general, is deprecated
in favor of ranges, which are more generic and flexible.
Could you please give a small example?
Consider this minimal app:
import std.stdio;
import std.socket;
import std.socketstream;
void main() {
auto socket = new TcpSocket(new
InternetAddress("dlang.org", 80));
scope(exit) socket.close();
auto ss = new SocketStream(socket);
ss.writeString("GET http://dlang.org HTTP/1.1\r\n"
"Host: dlang.org\r\n"
"Connection: close\r\n"
"\r\n");
while (! ss.eof) {
writeln(ss.readLine());
}
}
How should it look with ranges instead of socketstream? I
thought I understand ranges in general, but I can't figure out
how they can be applied to this case.
In case someone is still looking for the answer, just like me. It
will be something like that:
import std.stdio;
import std.socket;
enum receiveBufferLength = 1024;
void main() {
auto socket = new TcpSocket(new InternetAddress("dlang.org",
80));
scope(exit) socket.close();
socket.send("GET http://dlang.org HTTP/1.1\r\nHost:
dlang.org\r\nConnection: close\r\n\r\n");
string response;
char[receiveBufferLength] receiveBuffer;
while (true) {
auto received = socket.receive(receiveBuffer[0 ..
receiveBufferLength]);
response ~= receiveBuffer[0 .. received];
if (received == 0) break;
}
write(response);
}
dependency analysis for makefile construction
Are there any FOSS tools for doing dependency analysis of (e.g.)
all the d files in a directory, to let you know when a .o file
needs to be regenerated?
This presumably would depend mostly on the import statements
(including import of any file to be used in string construction,
as in 'auto my_string = import("my_file");').
My guess is there must be, because one of the big deals about d
is the more regular syntax it offers to make compiler building
more reliable.
(I'm using gdc, and building with gnumake.)
TIA for any info!
dan
Re: Using OpenGL
On Saturday, 3 September 2016 at 16:07:52 UTC, Mike Parker wrote: On Saturday, 3 September 2016 at 16:01:34 UTC, Mike Parker wrote: The following compiles, runs, and shows the triangle. It's the code you posted above with the corrected call to glBufferData along with more D style (as I would write it anyway) and less C. The dynamic array! Thank you so much, I changed that on another file and it finally drew the triangle. And I ran your code and it works brilliantly. I should now be in a comfortable position to digest all this information now. Can't thank you enough. One thing I overlooked. In lines where a variable is both declared and initialized, like this one: GLFWwindow* window = glfwCreateWindow(...); I normally let the compiler use type inference as I did in the manifest constant declarations: auto window = glfwCreateWindow(...); IMO, when you're dealing with long or ugly type names, it makes the code look cleaner. Yeah, it is nicer to read. Now I wonder if I can load shaders from separate files (à la http://www.opengl-tutorial.org/beginners-tutorials/tutorial-2-the-first-triangle/).
Re: Using OpenGL
On Saturday, 3 September 2016 at 16:01:34 UTC, Mike Parker wrote: The following compiles, runs, and shows the triangle. It's the code you posted above with the corrected call to glBufferData along with more D style (as I would write it anyway) and less C. One thing I overlooked. In lines where a variable is both declared and initialized, like this one: GLFWwindow* window = glfwCreateWindow(...); I normally let the compiler use type inference as I did in the manifest constant declarations: auto window = glfwCreateWindow(...); IMO, when you're dealing with long or ugly type names, it makes the code look cleaner.
Re: Using OpenGL
On Saturday, 3 September 2016 at 12:40:58 UTC, Darren wrote:
I went through another tutorial. Changed the source code and
left out the shaders. I get another coloured background but
still no triangle. I have a feeling that
glBufferData(GL_ARRAY_BUFFER,
cast(int)g_vertex_buffer_data.sizeof,
cast(void*)g_vertex_buffer_data,
GL_STATIC_DRAW);
Your vertices array is declared as a dynamic array. That means
vertices.sizeof gives you the size of the *array reference*, not
the data it contains. For a static array, you get the cumulative
size of the data. See my changes in the code below.
(In the first line, glBufferData wants an int, and .sizeof
returns a uint, apparently.)
That's irrelevant in this case. But sizeof is size_t, which is
uint on 32-bit systems and long on 64-bit systems.
I'm sure there's something simple I'm missing but I just don't
have the experience to recognise it.
The following compiles, runs, and shows the triangle. It's the
code you posted above with the corrected call to glBufferData
along with more D style (as I would write it anyway) and less C.
Comments are inline. Probably best if you copy and paste it into
an editor.
```
import std.stdio,
std.format;
import derelict.glfw3.glfw3;
import derelict.opengl3.gl3;
// Match the Derelict decleration of GLFW callbacks
//
https://github.com/DerelictOrg/DerelictGLFW3/blob/master/source/derelict/glfw3/types.d#L319
extern(C) nothrow {
// Setting an error handler will let you get better error
messages from GLFW
// when something fails.
//
http://www.glfw.org/docs/latest/intro_guide.html#error_handling
void onError(int error, const(char)* msg) {
import std.conv : to;
try {
// The callback is nothrow, but format is not, so the
// try...catch
errMsg = format("GLFW Error #%s: %s", error,
to!string(msg));
}
catch(Exception e) {}
}
void key_callback(GLFWwindow* window, int key, int scancode,
int action, int mode) {
if (key == GLFW_KEY_ESCAPE && action == GLFW_PRESS)
glfwSetWindowShouldClose(window, GL_TRUE);
}
}
// This will save the error message from the callback
private auto errMsg = "No Error";
// Use manifest constants rather than const
// https://dlang.org/spec/enum.html#manifest_constants
enum WIDTH = 800;
enum HEIGHT = 600;
// Rather than using multiple string literals with manual
newlines, use
// WYSIWYG strings as manifest constants. Looks cleaner (but
requires an
// extra step when calling glShaderSource).
enum vertexShaderSource =
`#version 330 core
layout (location = 0) in vec3 position;
void main()
{
gl_Position = vec4(position.x, position.y, position.z, 1.0);
}`;
enum fragmentShaderSource =
`#version 330 core
out vec4 color;
void main()
{
color = vec4(1.0f, 0.5f, 0.2f, 1.0f);
}`;
void main()
{
DerelictGLFW3.load();
DerelictGL3.load();
// Set the error callback before calling glfwInit so that a
useful message
// can be reported on failure
glfwSetErrorCallback(&onError);
// Always check for failure
if(!glfwInit()) throw new Exception("Failed to init GLFW: " ~
errMsg);
// Ensure that glfwTerminate is called even when an exception
is thrown
scope(exit) glfwTerminate();
glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3);
glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE);
// Optonal: Remove deprecated functionality
glfwWindowHint(GLFW_OPENGL_FORWARD_COMPAT, 1);
glfwWindowHint(GLFW_RESIZABLE, GL_FALSE);
// Always check for failure
GLFWwindow* window = glfwCreateWindow(WIDTH, HEIGHT,
"LearnOpenGL", null, null);
if(!window) throw new Exception("Failed to create window");
glfwMakeContextCurrent(window);
DerelictGL3.reload();
glfwSetKeyCallback(window, &key_callback);
int width, height;
glfwGetFramebufferSize(window, &width, &height);
glViewport(0, 0, width, height);
GLuint vertexShader = glCreateShader(GL_VERTEX_SHADER);
// Because I switched the shader source to D strings, a
slight adjustment
// is needed here:
const(char)* srcPtr = vertexShaderSource.ptr;
glShaderSource(vertexShader, 1, &srcPtr, null);
glCompileShader(vertexShader);
GLint result;
// Use dynamic arrays for the info logs so that you can always
// ensure you have enough room. And throw exceptions on
failure.
glGetShaderiv(vertexShader, GL_COMPILE_STATUS, &result);
if (!result) {
glGetShaderiv(vertexShader, GL_INFO_LOG_LENGTH, &result);
auto infoLog = new char[](result);
glGetShaderInfoLog(vertexShader, 512, null, infoLog.ptr);
throw new Exception(format("Failed to compile vertex
shader:\n\t%s", infoLog));
}
GLuint fragmentShader = glCreateShader(GL_FRAGMENT_SHADER);
srcPtr = fragmentShaderSource.ptr;
glShaderSource(fragmentShad
Re: How compiler detects forward reference errors
On Saturday, 3 September 2016 at 14:06:06 UTC, Igor wrote:
Can anyone explain in plain English how does compiler process
and detect a "test.d(6) Error: forward reference of variable a"
in following code:
import std.stdio;
enum a = 1 + b;
enum d = 5 + a; // No error here
enum b = 12 + c;
enum c = 10 + a; // error here
void main()
{
writeln("Hello World!", b);
}
This is an recursive expression.
c = 10 + 1 + 12 + c ...
and therefore cannot be compiled.
Re: How compiler detects forward reference errors
On Saturday, 3 September 2016 at 14:06:06 UTC, Igor wrote: Can anyone explain in plain English how does compiler process and detect a "test.d(6) Error: forward reference of variable a" in following code: Via bugs, it does if(would_be_annoying_to_user) trigger_error(); else let_it_work(); If a user complains they say "report to bugzilla" but bugzilla is conveniently redirected to "wait forever; fix not coming". It is all random bugs
Re: How compiler detects forward reference errors
On Saturday, 3 September 2016 at 14:06:06 UTC, Igor wrote:
Can anyone explain in plain English how does compiler process
and detect a "test.d(6) Error: forward reference of variable a"
in following code:
import std.stdio;
enum a = 1 + b;
enum d = 5 + a; // No error here
enum b = 12 + c;
enum c = 10 + a; // error here
void main()
{
writeln("Hello World!", b);
}
a needs b to be initialized. So b must be initialized before a.
Let's write this b->a. Now b needs c. So c->b. c needs a, so
a->c. If we sum everything, we have that a->c->b->a. This mean
that to initialize a we need b, to initialize b we need c, but to
initialize c we need a. So to initialize a we need a, which is
not possible. We need a before having initialized it.
On the other hand, a->d is not a problem, as d can be initialized
after a.
Re: Hash table element existence check
On Saturday, 3 September 2016 at 12:33:26 UTC, Illuminati wrote:
On Saturday, 3 September 2016 at 07:44:28 UTC, Cauterite wrote:
On Friday, 2 September 2016 at 19:38:34 UTC, Illuminati wrote:
I am trying to create a hash table and would like an
efficient way to be able to know if an element exists to test
for collisions.
Just do a regular lookup on the hash? It's an O(1) operation,
like 4 instructions.
Huh? One can look up fine, but how does one know if the result
is valid or not?
Okay I think I misinterpreted the question. I believe when I did
this my solution was to have an additional template parameter
specifying null key values, so the template was like this:
struct HashTbl(
K, /* key type */
V, /* value type */
K NullKey, /* key placeholder value */
alias hash_key, /* hash function */
alias keys_eq /* equality function */
) {...
I guess this doesn't really solve the problem, but makes it the
user's problem.
I could keep a bitarray, but wasting around 12% space.
That assumes your (K,V) tuples are 1 byte total, right?
How compiler detects forward reference errors
Can anyone explain in plain English how does compiler process and
detect a "test.d(6) Error: forward reference of variable a" in
following code:
import std.stdio;
enum a = 1 + b;
enum d = 5 + a; // No error here
enum b = 12 + c;
enum c = 10 + a; // error here
void main()
{
writeln("Hello World!", b);
}
Re: Using OpenGL
On Saturday, 3 September 2016 at 11:33:10 UTC, Mike Parker wrote: On Saturday, 3 September 2016 at 11:02:11 UTC, Lodovico Giaretta wrote: glGetShaderInfoLog(vertexShader, 512, null, &infoLog[0]); I prefer: glGetShaderInfoLog(vertexShader, 512, null, infoLog.ptr); That is a good tip to know. I went through another tutorial. Changed the source code and left out the shaders. I get another coloured background but still no triangle. I have a feeling that glBufferData(GL_ARRAY_BUFFER, cast(int)g_vertex_buffer_data.sizeof, cast(void*)g_vertex_buffer_data, GL_STATIC_DRAW); in one example, or glBufferData(GL_ARRAY_BUFFER, vertices.sizeof, cast(void*)vertices, GL_STATIC_DRAW); glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3 * GLfloat.sizeof, cast(GLvoid*)0); in the other might be responsible, since they seem to be related to drawing the triangle and I'm casting arguments in order to get the program to compile. (In the first line, glBufferData wants an int, and .sizeof returns a uint, apparently.) I'm sure there's something simple I'm missing but I just don't have the experience to recognise it.
Re: Hash table element existence check
On Saturday, 3 September 2016 at 09:43:04 UTC, Basile B. wrote: On Friday, 2 September 2016 at 19:38:34 UTC, Illuminati wrote: I am trying to create a hash table and would like an efficient way to be able to know if an element exists to test for collisions. I could keep a bitarray, but wasting around 12% space. I could use pointers(null check) to elements but this creates fragmentation. It is not terrible, just curious if anyone has a better way? fragmentation is a consequence of the hash function. You should set the hasher as a template parameter so that, according to the value type, the best hash fun (the one that creates less clustering) can be supplied. I mean memory fragmentation. If the key and value are structs, The memory is an array of tuple(key, value). Any scanning and returning are quite efficiency since all the tuples are next to each other. If they are pointers to the key/value then they could point to any location in memory. Scanning and such are far more likely to create cache misses. Maybe not a big deal for simple one-time access but in other cases it could be extremely slow(such as iterating over the table). But otherwise the buckets is almost always an array of ReturnType!hashFun with the max value wrapped around the next power of two value following entry count. My hash table is simply a fixed array of type X = tuple(key, value). X is at location key.hashOf % length(more or less). When the table becomes too small, it is enlarged and everything is rehashed. But keys and values can be values or references and this changes the behavior. references can be checked for null, but values can't.
Re: Hash table element existence check
On Saturday, 3 September 2016 at 07:44:28 UTC, Cauterite wrote: On Friday, 2 September 2016 at 19:38:34 UTC, Illuminati wrote: I am trying to create a hash table and would like an efficient way to be able to know if an element exists to test for collisions. Just do a regular lookup on the hash? It's an O(1) operation, like 4 instructions. Huh? One can look up fine, but how does one know if the result is valid or not?
Re: Hash table element existence check
On Friday, 2 September 2016 at 19:48:30 UTC, Steven Schveighoffer wrote: On 9/2/16 3:38 PM, Illuminati wrote: I am trying to create a hash table and would like an efficient way to be able to know if an element exists to test for collisions. You mean you are writing your own hash table, or you want to use a D hash table (associative array)? First. I could keep a bitarray, but wasting around 12% space. I could use pointers(null check) to elements but this creates fragmentation. It is not terrible, just curious if anyone has a better way? I'm not sure I understand the question. Hash tables have many many many different ways to implement. Obviously, marking empty buckets somehow is necessary. -Steve Yes, one must have a way to mark empty "buckets"(I hate that term! Seems so banal for some reason ;/) If using pointers, which is what I use, then null means empty, but one can't use inline structs and which then can create data fragmentation. If the structs are inline, there is no way to know if the element is a valid struct or empty. One could test against the .init, say, but I don't think any of that is safe. Hence a bitmap could be used in that case, but wastes a lot of space. I don't see any other way though. Pointers, also, waste memory rather than structs inline and effectively is a bitmap but does save space for sparse maps.
Re: Using OpenGL
On Saturday, 3 September 2016 at 11:02:11 UTC, Lodovico Giaretta wrote: glGetShaderInfoLog(vertexShader, 512, null, &infoLog[0]); I prefer: glGetShaderInfoLog(vertexShader, 512, null, infoLog.ptr);
Re: Using OpenGL
On Saturday, 3 September 2016 at 11:27:09 UTC, Mike Parker wrote:
On Saturday, 3 September 2016 at 11:13:30 UTC, Lodovico
Giaretta wrote:
Ah! Well, providing error messages is always useful. Now I see
your issue: your callback has D linkage, but OpenGL expects a
function with C linkage. So you have to put `extern(C)` on
your callback declaration.
Well, it's GLFW, not OpenGL, but yes they do need to be extern
(C) and also nothrow, as that is how the callback types are
declared in Derrlict:
```
extern(C) nothrow
void key_callback(GLFWwindow* window, int key, int scancode,
int action, int mode) {
if (key == GLFW_KEY_ESCAPE && action == GLFW_PRESS)
glfwSetWindowShouldClose(window, GL_TRUE);
}
```
Hey, it worked! Thanks a lot, I know what to do in the future
now. Just need to figure out why this triangle isn't showing up
and I should be well on my way.
Re: Using OpenGL
On Saturday, 3 September 2016 at 11:13:30 UTC, Lodovico Giaretta
wrote:
Ah! Well, providing error messages is always useful. Now I see
your issue: your callback has D linkage, but OpenGL expects a
function with C linkage. So you have to put `extern(C)` on your
callback declaration.
Well, it's GLFW, not OpenGL, but yes they do need to be extern
(C) and also nothrow, as that is how the callback types are
declared in Derrlict:
```
extern(C) nothrow
void key_callback(GLFWwindow* window, int key, int scancode, int
action, int mode) {
if (key == GLFW_KEY_ESCAPE && action == GLFW_PRESS)
glfwSetWindowShouldClose(window, GL_TRUE);
}
```
Re: Using OpenGL
On Saturday, 3 September 2016 at 11:10:00 UTC, Darren wrote: On Saturday, 3 September 2016 at 11:02:11 UTC, Lodovico Giaretta wrote: //glfwSetKeyCallback(window, key_callback); glfwSetKeyCallback(window, &key_callback); I actually tried this before but it doesn't work. I get the following error: Error: function pointer glfwSetKeyCallback (GLFWwindow*, extern (C) void function(GLFWwindow*, int, int, int, int) nothrow) is not callable using argument types (GLFWwindow*, void function(GLFWwindow* window, int key, int scancode, int action, int mode)) Ah! Well, providing error messages is always useful. Now I see your issue: your callback has D linkage, but OpenGL expects a function with C linkage. So you have to put `extern(C)` on your callback declaration.
Re: Using OpenGL
On Saturday, 3 September 2016 at 11:02:11 UTC, Lodovico Giaretta wrote: //glGetShaderInfoLog(vertexShader, 512, null, infoLog); glGetShaderInfoLog(vertexShader, 512, null, &infoLog[0]); Thank you, I knew I had to do something like this! //glfwSetKeyCallback(window, key_callback); glfwSetKeyCallback(window, &key_callback); I actually tried this before but it doesn't work. I get the following error: Error: function pointer glfwSetKeyCallback (GLFWwindow*, extern (C) void function(GLFWwindow*, int, int, int, int) nothrow) is not callable using argument types (GLFWwindow*, void function(GLFWwindow* window, int key, int scancode, int action, int mode))
Re: Using OpenGL
On Saturday, 3 September 2016 at 10:30:13 UTC, Darren wrote: [...] I never used OpenGL in D, but from a quick glance at your code, I'll suggest trying the following changes: //glGetShaderInfoLog(vertexShader, 512, null, infoLog); glGetShaderInfoLog(vertexShader, 512, null, &infoLog[0]); //glfwSetKeyCallback(window, key_callback); glfwSetKeyCallback(window, &key_callback);
Re: Using OpenGL
It's not quite in a practically-usable state yet, but the SDL2
& OpenGL wrapper I'm working on may interest you as an example
implementation if nothing else.
https://github.com/pineapplemachine/mach.d/tree/master/mach/sdl
I'm going to take a look at this, once I get my bearings, on the
merits of the name alone!
I'm sure there are a few tutorials that make use of SDL2 that I
can use. My hope is that once I know how to set up, learning
OpenGL will be more a matter of D-ifying the C-code.
I'll post the modified code I'm trying to get work in full below.
Some code is commented out because I couldn't make it work. Also
any tips for making the code nicer would be welcome (e.g. would I
change the const GLunit into enums?).
#
import derelict.glfw3.glfw3;
import derelict.opengl3.gl3;
import std.stdio;
void key_callback(GLFWwindow* window, int key, int scancode, int
action, int mode) {
if (key == GLFW_KEY_ESCAPE && action == GLFW_PRESS)
glfwSetWindowShouldClose(window, GL_TRUE);
}
const GLuint WIDTH = 800, HEIGHT = 600;
const GLchar* vertexShaderSource = "#version 330 core\n"
"layout (location = 0) in vec3 position;\n"
"void main()\n"
"{\n"
"gl_Position = vec4(position.x, position.y, position.z,
1.0);\n"
"}\0";
const GLchar* fragmentShaderSource = "#version 330 core\n"
"out vec4 color;\n"
"void main()\n"
"{\n"
"color = vec4(1.0f, 0.5f, 0.2f, 1.0f);\n"
"}\n\0";
void main()
{
DerelictGLFW3.load();
DerelictGL3.load();
glfwInit();
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);
GLFWwindow* window = glfwCreateWindow(WIDTH, HEIGHT,
"LearnOpenGL", null, null);
glfwMakeContextCurrent(window);
DerelictGL3.reload();
//glfwSetKeyCallback(window, key_callback);
int width, height;
glfwGetFramebufferSize(window, &width, &height);
glViewport(0, 0, width, height);
GLuint vertexShader = glCreateShader(GL_VERTEX_SHADER);
glShaderSource(vertexShader, 1, &vertexShaderSource, null);
glCompileShader(vertexShader);
GLint success;
GLchar[512] infoLog;
glGetShaderiv(vertexShader, GL_COMPILE_STATUS, &success);
if (!success) {
//glGetShaderInfoLog(vertexShader, 512, null, infoLog);
writeln("ERROR::SHADER::VERTEX::COMPILATION_FAILED\n",
infoLog);
}
GLuint fragmentShader = glCreateShader(GL_FRAGMENT_SHADER);
glShaderSource(fragmentShader, 1, &fragmentShaderSource,
null);
glCompileShader(fragmentShader);
glGetShaderiv(fragmentShader, GL_COMPILE_STATUS, &success);
if (!success) {
//glGetShaderInfoLog(fragmentShader, 512, null, infoLog);
writeln("ERROR::SHADER::FRAGMENT::COMPILATION_FAILED\n",
infoLog);
}
GLuint shaderProgram = glCreateProgram();
glAttachShader(shaderProgram, vertexShader);
glAttachShader(shaderProgram, fragmentShader);
glLinkProgram(shaderProgram);
glGetProgramiv(shaderProgram, GL_LINK_STATUS, &success);
if (!success) {
//glGetProgramInfoLog(shaderProgram, 512, null, infoLog);
writeln("ERROR::SHADER::PROGRAM::LINKING_FAILED\n",
infoLog);
}
glDeleteShader(vertexShader);
glDeleteShader(fragmentShader);
GLfloat[] vertices = [
-0.5f, -0.5f, 0.0f,
0.5f, -0.5f, 0.0f,
0.0f, 0.5f, 0.0f
];
GLuint VBO, VAO;
glGenVertexArrays(1, &VAO);
glGenBuffers(1, &VBO);
glBindVertexArray(VAO);
glBindBuffer(GL_ARRAY_BUFFER, VBO);
glBufferData(GL_ARRAY_BUFFER, vertices.sizeof,
cast(void*)vertices, GL_STATIC_DRAW);
glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3 *
GLfloat.sizeof, cast(GLvoid*)0);
glEnableVertexAttribArray(0);
glBindBuffer(GL_ARRAY_BUFFER, 0);
glBindVertexArray(0);
while (!glfwWindowShouldClose(window)) {
glfwPollEvents();
glClearColor(0.2f, 0.3f, 0.3f, 1.0f);
glClear(GL_COLOR_BUFFER_BIT);
glUseProgram(shaderProgram);
glBindVertexArray(VAO);
glDrawArrays(GL_TRIANGLES, 0, 3);
glBindVertexArray(0);
glfwSwapBuffers(window);
}
glDeleteVertexArrays(1, &VAO);
glDeleteBuffers(1, &VBO);
glfwTerminate();
}
Re: Using OpenGL
On Saturday, 3 September 2016 at 09:30:58 UTC, Darren wrote:
Thanks for the information. The errors for the tutorial I
_was_ trying to make work are as follows:
source\app.d(9,5): Error: undefined identifier 'Window', did
you mean variable 'window'?
source\app.d(98,12): Error: undefined identifier 'Window', did
you mean variable 'window'?
source\app.d(101,14): Error: undefined identifier 'GLBuffer'
source\app.d(104,14): Error: undefined identifier 'Shader'
source\app.d(107,13): Error: undefined identifier 'Program',
did you mean variable 'program'?
source\app.d(110,15): Error: undefined identifier 'Attribute'
I thought I might have needed another package for these, and
gfm seemed to contain what I need in the form of the opengl
sub-package. But even after importing that, it only gets rid
of the GLBuffer error.
I tried to follow another tutorial. Link to source code:
http://www.learnopengl.com/code_viewer.php?code=getting-started/hellotriangle
I'm having more success with this one. I pretty much hacked
away at this and did my best to convert from C-style code to D.
The window gets made and it has the green-ish background, but
it's not drawing any triangles. Should I copy/paste the code
I'm using in case I made a mistake?
It's not quite in a practically-usable state yet, but the SDL2 &
OpenGL wrapper I'm working on may interest you as an example
implementation if nothing else.
https://github.com/pineapplemachine/mach.d/tree/master/mach/sdl
Here's an example of a functioning program using the package. At
the moment I'm working on exposing SDL2's event and other input
systems.
import std.datetime;
import mach.math.vector2;
import mach.sdl.window;
import mach.sdl.texture;
import mach.sdl.color;
import mach.sdl.primitives;
void main(){
// Create a window
auto win = new Window(300, 300);
win.position = Vector2!int(200, 200);
// Load a texture
auto tex = Texture("pineapple.png");
// Loop for 5 seconds
StopWatch sw;
sw.start();
auto maxms = 5000f;
while(true){
auto ms = sw.peek().msecs;
if(ms >= maxms) break;
// Fill with green
win.clear(0, ms / maxms / 2, 0);
// Draw centered image
tex.draw((win.size - tex.size) / 2);
// Draw red lines at top and bottom
lines(Color!ubyte.Red,
Vector2!int(8, 8), Vector2!int(292, 8),
Vector2!int(292, 292), Vector2!int(8, 292)
);
// Display changes
win.swap();
}
}
Re: Hash table element existence check
On Friday, 2 September 2016 at 19:38:34 UTC, Illuminati wrote: I am trying to create a hash table and would like an efficient way to be able to know if an element exists to test for collisions. I could keep a bitarray, but wasting around 12% space. I could use pointers(null check) to elements but this creates fragmentation. It is not terrible, just curious if anyone has a better way? fragmentation is a consequence of the hash function. You should set the hasher as a template parameter so that, according to the value type, the best hash fun (the one that creates less clustering) can be supplied. But otherwise the buckets is almost always an array of ReturnType!hashFun with the max value wrapped around the next power of two value following entry count.
Re: Using OpenGL
Thanks for the information. The errors for the tutorial I _was_ trying to make work are as follows: source\app.d(9,5): Error: undefined identifier 'Window', did you mean variable 'window'? source\app.d(98,12): Error: undefined identifier 'Window', did you mean variable 'window'? source\app.d(101,14): Error: undefined identifier 'GLBuffer' source\app.d(104,14): Error: undefined identifier 'Shader' source\app.d(107,13): Error: undefined identifier 'Program', did you mean variable 'program'? source\app.d(110,15): Error: undefined identifier 'Attribute' I thought I might have needed another package for these, and gfm seemed to contain what I need in the form of the opengl sub-package. But even after importing that, it only gets rid of the GLBuffer error. I tried to follow another tutorial. Link to source code: http://www.learnopengl.com/code_viewer.php?code=getting-started/hellotriangle I'm having more success with this one. I pretty much hacked away at this and did my best to convert from C-style code to D. The window gets made and it has the green-ish background, but it's not drawing any triangles. Should I copy/paste the code I'm using in case I made a mistake?
Re: Hash table element existence check
On Friday, 2 September 2016 at 19:38:34 UTC, Illuminati wrote: I am trying to create a hash table and would like an efficient way to be able to know if an element exists to test for collisions. Just do a regular lookup on the hash? It's an O(1) operation, like 4 instructions.
