Searching for a string in a text buffer with a regular expression
While porting a simple Python script to D, I found the following problem. I need to read in some thousand of little text files and search every one for a match with a given regular expression. Obviously, the program can't (and it should not) be certain about the encoding of each input file. I initially used read() casting it with a cast(char[]), but, at some point, the regex engine crashed with an exception: it encountered an UTF-8 character it couldn't automatically decode. This is right, since char[] is not byte[]. Now I'm casting with a Latin1String, since I know this is the right encoding for the input buffers: and it works fine, at last... but what about if I'd need to treat a RAW (binary? unknown encoding?) buffer? Is there a simple and elegant solution in D for such case? Python didn't gave such problems!
Any netowork library, or libraries that support promiscuous mode?
Just wondering if any library that supports putting network adapter in promiscuous mode. As I new to D and heard something about importing C libraries in to D, but I don't know how smooth that will be so just was wondering if any D libraries that support promiscuous mode. Thanks to anyone that reply.
Re: Searching for a string in a text buffer with a regular expression
maxpat78: Is there a simple and elegant solution in D for such case? Python didn't gave such problems! Do you mean Python3? Bye, bearophile
Re: Unresolvable references to dlopen, dlclose etc
On Thursday, 5 December 2013 at 19:20:16 UTC, Mafi wrote: I am on fresh install of Linux Mint 16 64bit and I tried to compile some D code I have writen and I have problems (Hello World works btw). I uses Derelict (v2) and I have successfully compiled/linked/rurn my program on Windows 7 64bit. But on Linux I get errors about unresolved references to dlopen, dlclose etc. although I am linking against libdl (ld finds the so; I checked the verbose output). Interestingly libdl.so is empty by nm. I found the symbols in libc. I am compiling everything from scratch with the newest dmd (2.064.2 that is) with -m64 in my dmd.conf (doesn't work without either). I have posted on the Derelict forums (http://dblog.aldacron.net/forum/index.php?topic=864.0) but I don't think it is a Derelict specific problem. Pleas help me! Could at least somebody approve they have read it? Maybe I did the installation wrong. I don't the slightest idea what to do. I am already trying for days.
Re: Is this reasonable?
On Friday, 6 December 2013 at 02:11:20 UTC, Jonathan M Davis wrote: Regardless, we're pretty much stuck at this point. Changing it would silently break lots of code. I still wonder what was the reasoning behind C's warning about comparison between signed and unsigned integers instead of giving an error. And as much as I do understand the no warnings policy, I really think that if you keep features from C, you should also keep C warnings. (BTW: I was quite sure dmd warned the user, maybe it was GDC or LDC instead?)
Re: Searching for a string in a text buffer with a regular expression
On 2013-12-06 08:53:04 +, maxpat78 said: While porting a simple Python script to D, I found the following problem. I need to read in some thousand of little text files and search every one for a match with a given regular expression. Obviously, the program can't (and it should not) be certain about the encoding of each input file. I initially used read() casting it with a cast(char[]), but, at some point, the regex engine crashed with an exception: it encountered an UTF-8 character it couldn't automatically decode. This is right, since char[] is not byte[]. Now I'm casting with a Latin1String, since I know this is the right encoding for the input buffers: and it works fine, at last... but what about if I'd need to treat a RAW (binary? unknown encoding?) buffer? Is there a simple and elegant solution in D for such case? Python didn't gave such problems! Why don't you follow one of the file reading examples? readText is what you're looking for. http://dlang.org/phobos/std_file.html#.readText
Re: Is this reasonable?
On Friday, December 06, 2013 12:02:29 Fra wrote: On Friday, 6 December 2013 at 02:11:20 UTC, Jonathan M Davis wrote: Regardless, we're pretty much stuck at this point. Changing it would silently break lots of code. I still wonder what was the reasoning behind C's warning about comparison between signed and unsigned integers instead of giving an error. And as much as I do understand the no warnings policy, I really think that if you keep features from C, you should also keep C warnings. (BTW: I was quite sure dmd warned the user, maybe it was GDC or LDC instead?) An error is something defined by the language, whereas warnings are completely compiler-specific. As warning about comparing signed and unsigned integers is a warning, it's not standard, and the decision to warn about it or not is a matter of what the devs of a particular compiler decided to do. There's no such thing as standard warnins in C. What gets warned about depends entirely on the compiler and what it's settings are. For instance, gcc doesn't warn about comparing signed and unsigned values (at least not by default), whereas Visual Studio does. So, trying to follow what C does with regards to warnings doesn't make sense, because it varies from compiler to compiler. Each case should be decided on its own merits and not because of what a particular C compiler happens to do. - Jonathan M Davis
Re: Is this reasonable?
The best that could be done would arguably be to simply do the comparison the 'right' way. E.g. static assert(-1 0u). What's the 'right' way? assert(-1 uint.max) will always fail because no matter whether you convert to int or uint, the comparison simply cannot be carried out at the machine code level. But the compiler should be able to do such things at compile time. If you compare an unsigned variable with a negative literal, -1 x or x -1: the whole expression can be rewritten to true, -1 == x or -1 x or -1 = x etc. can be rewritten to false. This is not only no performance problem but instead extremely efficient!
Re: Is this reasonable?
On Friday, 6 December 2013 at 11:56:35 UTC, Jonathan M Davis wrote: There's no such thing as standard warnins in C. What gets warned about depends entirely on the compiler and what it's settings are. You are 100% right, I was speaking out of my mind. Anyway, I still don't understand the rationale behind allowing those comparisons in C in the first place, but I guess I will never know :P
Re: Any netowork library, or libraries that support promiscuous mode?
On Friday, 6 December 2013 at 10:32:52 UTC, Cabe wrote: Just wondering if any library that supports putting network adapter in promiscuous mode. As I new to D and heard something about importing C libraries in to D, but I don't know how smooth that will be so just was wondering if any D libraries that support promiscuous mode. Thanks to anyone that reply. as smooth as using original lib in C directly. or you can make ur own OOP wrapper.
Re: Unresolvable references to dlopen, dlclose etc
On 2013-12-05 20:20, Mafi wrote: I am on fresh install of Linux Mint 16 64bit and I tried to compile some D code I have writen and I have problems (Hello World works btw). I uses Derelict (v2) and I have successfully compiled/linked/rurn my program on Windows 7 64bit. But on Linux I get errors about unresolved references to dlopen, dlclose etc. although I am linking against libdl (ld finds the so; I checked the verbose output). Interestingly libdl.so is empty by nm. I found the symbols in libc. I am compiling everything from scratch with the newest dmd (2.064.2 that is) with -m64 in my dmd.conf (doesn't work without either). I have posted on the Derelict forums (http://dblog.aldacron.net/forum/index.php?topic=864.0) but I don't think it is a Derelict specific problem. Pleas help me! You can compile with the verbose flag, -v, to make sure it links as you expect it to. The linking command will be at the bottom of the output. -- /Jacob Carlborg
Re: Is this reasonable?
On 12/06/2013 02:06 AM, H. S. Teoh wrote:
On Thu, Dec 05, 2013 at 10:06:55PM +0100, Timon Gehr wrote:
On 12/05/2013 07:26 PM, Jonathan M Davis wrote:
The best that could be done would be to warn about the comparison
or to make it an error.
http://d.puremagic.com/issues/show_bug.cgi?id=259
...
The best that could be done would arguably be to simply do the
comparison the 'right' way. E.g. static assert(-1 0u).
What's the 'right' way? assert(-1 uint.max) will always fail because
no matter whether you convert to int or uint, the comparison simply
cannot be carried out at the machine code level. The only way you can
get a sane answer out of this is if the compiler translates it into:
if (intVar 0 || cast(uint)intVar uintVar) { ... }
T
Yup, that's the 'right' way.
Re: Unresolvable references to dlopen, dlclose etc
You can compile with the verbose flag, -v, to make sure it links as you expect it to. The linking command will be at the bottom of the output. Thank you! This has helped and I linked my program. As it turned out dmd invoked gcc to link and it supplied my -ldl argument first! I copy-pasted that command into a shell and moved the -ldl to the very end and it worked. How do instruct dmd to do the same? As far as I understand the problem is that I specified the full path to the Derelict lib files by hand for each lib instead of using -L and -l. Libraries specifed like that are put after the gilen linker flags and before the buitlin ones (-lphobos etc). Is this a bug or is there any reason for dmd's behavior? It seems very wrong to me.
Binary Data Serialization Libraries
Are there any Binary Data Serialization Libraries available written in D2? I'm looking for something like a BSON read/write library. (Although can be any other binary language really)
Equality == comparisons with floating point numbers
A dangerous topic for everyone :-) I've been working with some unittests involving comparing the output of different but theoretically equivalent versions of the same calculation. To my surprise, calculations which I assumed would produce identical output, were failing equality tests. It seemed unlikely this would be due to any kind of different rounding error, but I decided to check by writing out the whole floating-point numbers formatted with %.80f. This confirmed my suspicion that the numbers were indeed identical. You can read the detailed story here: https://github.com/D-Programming-Language/phobos/pull/1740 It seems like I can probably use isIdentical for the unittests, but I am more concerned about the equality operator. I completely understand that equality comparisons between FP are dangerous in general as tiny rounding errors may induce a difference, but == in D seems to see difference in circumstances where (so far as I can see) it really shouldn't happen. Can anybody offer an explanation, a prognosis for improving things, and possible coping strategies in the meantime (other than the ones I already know, isIdentical and approxEqual)?
Re: Equality == comparisons with floating point numbers
On 12/06/2013 05:47 AM, Joseph Rushton Wakeling wrote: I decided to check by writing out the whole floating-point numbers formatted with %.80f. This confirmed my suspicion that the numbers were indeed identical. Are they identical when printed with %a? Ali
Re: Equality == comparisons with floating point numbers
On 06/12/13 15:02, Ali Çehreli wrote: Are they identical when printed with %a? On my 64-bit Linux system, yes. I'll push an updated patch to test and see if the various 32-bit systems report similar results (I was getting failures on 32-bit Darwin, BSD and Linux). Thanks very much for the suggestion, as that's a print formatting option I wasn't familiar with.
Re: Binary Data Serialization Libraries
On Friday, 6 December 2013 at 13:33:45 UTC, Jeroen Bollen wrote: Are there any Binary Data Serialization Libraries available written in D2? I'm looking for something like a BSON read/write library. (Although can be any other binary language really) vibe.d BSON : https://github.com/rejectedsoftware/vibe.d/blob/master/source/vibe/data/bson.d generic binary serialization library : https://github.com/atilaneves/cerealed There are certainly more out there but those two came to my mind immediately.
Re: Binary Data Serialization Libraries
On 2013-12-06 13:33:44 +, Jeroen Bollen said: Are there any Binary Data Serialization Libraries available written in D2? I'm looking for something like a BSON read/write library. (Although can be any other binary language really) MessagePack - format very similar to BSON - https://github.com/msgpack/msgpack-d
Re: Equality == comparisons with floating point numbers
On 06/12/13 15:02, Ali Çehreli wrote: Are they identical when printed with %a? Yes. You can see some of the results here (for the 32-bit systems where I was getting failures): https://d.puremagic.com/test-results/pull.ghtml?projectid=1runid=811923logid=6 https://d.puremagic.com/test-results/pull.ghtml?projectid=1runid=811924logid=6 https://d.puremagic.com/test-results/pull.ghtml?projectid=1runid=811927logid=6 https://d.puremagic.com/test-results/pull.ghtml?projectid=1runid=811930logid=6 So, as I said, it's baffling why the equality operator is not returning true.
Re: I/O related question, and ini parsing
On Friday, 6 December 2013 at 05:32:56 UTC, Mineko wrote: On Friday, 6 December 2013 at 05:22:07 UTC, Ali Çehreli wrote: On 12/05/2013 08:43 PM, Mineko wrote: I might be missing out on some D-only features The first thing I've noticed is that you are not using UFCS, perhaps because you don't like it (yet ;) ) but look how natural the syntax becomes: existing code (my indentation): temp = findSplitAfter(findSplitBefore(find(source, var~ = ), ;)[0], = )[1]; code taking advantage of D's UFCS (I hope I got it right; I have not compiled it): temp = source .find(var~ = ) .findSplitBefore(;)[0] .findSplitAfter( = )[1]; Ali I didn't even know that existed, I'll jump on that right now. I went through 8 hours of hell for that.. But it was worth it, things do look nicer with UFCS stuffs. (No wonder why they say you don't need a scripting language with D..) It's on my fork if you wanna check it out: https://github.com/MinekoRox/Breaker-3D-Game-Engine Anyways, back to the main subject, anyone know anything that I could be missing D-only wise as far as file loading, parsing, creating, etc the stuff in /utility/io.d is doing?
Re: Unresolvable references to dlopen, dlclose etc
On 2013-12-06 14:25, Mafi wrote: Thank you! This has helped and I linked my program. As it turned out dmd invoked gcc to link and it supplied my -ldl argument first! I copy-pasted that command into a shell and moved the -ldl to the very end and it worked. How do instruct dmd to do the same? As far as I understand the problem is that I specified the full path to the Derelict lib files by hand for each lib instead of using -L and -l. Libraries specifed like that are put after the gilen linker flags and before the buitlin ones (-lphobos etc). Is this a bug or is there any reason for dmd's behavior? It seems very wrong to me. I would say that linking order shouldn't matter. But for some reason it does. This not really my area of expertise but I know that others have had the same problem. You can try and search the newsgroups for linking order related problems. -- /Jacob Carlborg
Re: I/O related question, and ini parsing
Mineko: https://github.com/MinekoRox/Breaker-3D-Game-Engine Notes: - Usually in D imports are at the top (after module name and module ddoc). - Perhaps io.getDir is better written an a switch on strings. - I suggest to add the immutable/cost to every variable that doesn't need to mutate, including foreach loop variables. I also suggest to add pure/nothrow annotations where you can, and add pre/post conditions to functions and invariants to structs/classes where convenient (and unittests). Bye, bearophile
Re: Is this reasonable?
On Thursday, 5 December 2013 at 17:15:39 UTC, Steve Teale wrote:
Here I feel like a beginner, but it seems very unfriendly:
import std.stdio;
struct ABC
{
double a;
int b;
bool c;
}
ABC[20] aabc;
void foo(int n)
{
writefln(n: %d, aabc.length: %d, n, aabc.length);
if (n aabc.length)
writeln(A);
else
writeln(B);
}
void main(string[] args)
{
int n = -1;
foo(n);
}
Oh my, what a hornet's nest!
I'd settle for an error that said that it's not permissible to
compare a negative integer with a size_t. But almost any way you
go is ugly.
Thank you all. I feel less like a beginner now ;=)
Re: Is this reasonable?
On Thursday, 5 December 2013 at 18:26:48 UTC, Jonathan M Davis
wrote:
To be fair, you can't solve the problem automatically. It's
fundamentally
wrong to compare signed and unsigned values, and doing either
the conversion
to unsigned or to signed could be wrong (or both could be
wrong), depending on
the values.
*Actually*... that's not exactly true.
std.algorithm.max and std.algorithm.min actually do it perfectly
well.
It is completely feaseable to imagine having an:
std.functional.less(T, U)(T t, U u){}
Which could work for *any* (compatible) type, including those
with mixed signed-ness.
The only issue is that if the signs *are* mixed, the comparison
is a *bit* more costly. It involved *two* comparisons, and a
boolean condition:
https://github.com/D-Programming-Language/phobos/blob/ab34fb92addca61755474df04a0d0d6e0f1148a2/std/algorithm.d#L6698
Truth be told, a b could work correctly 100% of the time, no
question asked, if the *language* wanted to. The (2) problems
would be:
1) Breaks backward compatibility with C and C++.
2) Higher (and hidden) comparison costs.
Try to convince Walter that these are worth it XD !
Re: I/O related question, and ini parsing
On Friday, 6 December 2013 at 16:56:29 UTC, bearophile wrote: Mineko: https://github.com/MinekoRox/Breaker-3D-Game-Engine Notes: - Usually in D imports are at the top (after module name and module ddoc). I think it is a bad practice that should be discouraged. Moving as much imports as possible into local scope has lot of practical benefits, primarily maintenance and compilation times. OP still has them global though, just in weird place, that is unusual for sure :)
Re: I/O related question, and ini parsing
Dicebot: I think it is a bad practice that should be discouraged. Moving as much imports as possible into local scope has lot of practical benefits, primarily maintenance and compilation times. Right. I was referring to the global ones. Bye, bearophile
Re: Is this reasonable?
On Friday, December 06, 2013 18:28:09 monarch_dodra wrote:
On Thursday, 5 December 2013 at 18:26:48 UTC, Jonathan M Davis
wrote:
To be fair, you can't solve the problem automatically. It's
fundamentally
wrong to compare signed and unsigned values, and doing either
the conversion
to unsigned or to signed could be wrong (or both could be
wrong), depending on
the values.
*Actually*... that's not exactly true.
std.algorithm.max and std.algorithm.min actually do it perfectly
well.
It is completely feaseable to imagine having an:
std.functional.less(T, U)(T t, U u){}
Which could work for *any* (compatible) type, including those
with mixed signed-ness.
The only issue is that if the signs *are* mixed, the comparison
is a *bit* more costly. It involved *two* comparisons, and a
boolean condition:
https://github.com/D-Programming-Language/phobos/blob/ab34fb92addca61755474d
f04a0d0d6e0f1148a2/std/algorithm.d#L6698
Truth be told, a b could work correctly 100% of the time, no
question asked, if the *language* wanted to. The (2) problems
would be:
1) Breaks backward compatibility with C and C++.
2) Higher (and hidden) comparison costs.
Try to convince Walter that these are worth it XD !
Ah, good point. I was assuming that you would just doing a straight up
comparison, in which case, you have to pick either signed or unsigned, whereas
if you can convert both ways and do both comparisons, that does change things
a bit. But still, I wouldn't expect Walter to ever agree to something like
that, and honestly, I think that making it an error and requiring the
programmer to deal with it is still a better option anyway. They can then use
a function to do the comparison that you're describing when they actually want
that and thus only incur the cost when that's what they really want. The key
is just to make sure that you don't silently do the single conversion and
comparison and end up with a bug. How to best do the comparison depends on
what you're trying to do.
- Jonathan M Davis
How to load a derelict program in D?
I am using the derelict-sfml2 package in my code. My code:
import std.stdio;
import derelict.sfml2.window;
void main()
{
DerelictSFML2Window.load();
sfVideoMode videoMode = sfVideoMode(1280, 720);
sfWindow* window = sfWindow_create(videoMode, Animation,
sfNone, null);
}
For some reason this always crashes inside a void load( string
libNames ) function. The crash seems to happen inside the
'DerelictSFML2Window.load();'.
Why is that? I am using Visual Studio 2013, with the VisualD
add-on. I have created the solution using dub generate visuald;
this is my project.json:
{
name: testing,
description: testing,
authors: [Jeroen Bollen],
dependencies: {
derelict-sfml2 : ~master,
}
}
how to find the type of a supplied variable
I have the following
void functionName(T)(T argumentVar)
{
/+
now i want that based on type of argumentVar, things will be
done
eg :
if there is a function gettype; then :
+/
switch(argumentVar.gettype)
{
case string array:
//do something
case string:
//treat srting as a file...
//then do some other things
}
}
How do I incorporrate this?
Re: how to find the type of a supplied variable
On Fri, Dec 06, 2013 at 09:18:51PM +0100, seany wrote:
I have the following
void functionName(T)(T argumentVar)
{
/+
now i want that based on type of argumentVar, things will be
done
eg :
if there is a function gettype; then :
+/
switch(argumentVar.gettype)
{
case string array:
//do something
case string:
//treat srting as a file...
//then do some other things
}
}
[...]
Use static if and an is-expression:
static if (is(T == string[]))
// handle string arrays
else static if (is(T == string))
// handle strings
else static assert(0); // this is a good idea to catch bugs,
// if somebody passes in a type that
// isn't supported
Depending on your application, you may want to use the more permissive
is(X : Y) syntax instead. The ':' means if X can implicitly convert to
Y, whereas the is(X == Y) syntax means if X is exactly the same type
as Y. So if you want to accept both string and char[], you'd write:
static if (is(T : const(char)[]))
// handles string, char[], and const(char)[]
since both unqualified and immutable can implicitly convert to const.
T
--
Unix is my IDE. -- Justin Whear
Re: stdout - autoflushing
Benji wrote: Hello, in order to have correctly displayed output (before reading something from stdin), I must call stdout.flush(). Sometimes, it's really annoying, especially when it is necessarry to call it 10 times. For example: write(Enter some string: ); stdout.flush(); string a = readln(); write(And again please: ); stdout.flush(); string b = readln(); ... Is there any way to prevent this? I doubt. Your IDE is buffering application's streams. -- Dejan Lekic dejan.lekic (a) gmail.com http://dejan.lekic.org
Re: how to find the type of a supplied variable
why do i need the static? (is that not supposed to prevent insertations of new scopes inside the braces? is it really needed?)
Re: how to find the type of a supplied variable
On Friday, 6 December 2013 at 20:58:15 UTC, seany wrote: why do i need the static? (is that not supposed to prevent insertations of new scopes inside the braces? is it really needed?) You can possibly use normal if but most likely you will get compilation errors from other conditional branches as they will use parameter type in semantically incorrect way. `static if` avoids compilation of not matching blocks and does not have this issue. You can explicitly define new scope using one extra pair of braces if you want it.
Re: stdout - autoflushing
On Friday, 6 December 2013 at 20:39:22 UTC, Dejan Lekic wrote: Benji wrote: Is there any way to prevent this? I doubt. Your IDE is buffering application's streams. You know though, this happens often enough that maybe we should just throw in a stdout.flush to the global readln function. I wouldn't put it on File.readln since that's likely wrong anyway, but on the global one it is probably what people want/expect anyway.
Re: how to find the type of a supplied variable
On Friday, 6 December 2013 at 20:58:15 UTC, seany wrote: why do i need the static? (is that not supposed to prevent insertations of new scopes inside the braces? is it really needed?) 'static if' means check this at compile time, which happens to not introduce a new scope, because otherwise it wouldn't be very useful.
Re: How to load a derelict program in D?
On Friday, 6 December 2013 at 19:50:52 UTC, Jeroen Bollen wrote:
I am using the derelict-sfml2 package in my code. My code:
import std.stdio;
import derelict.sfml2.window;
void main()
{
DerelictSFML2Window.load();
sfVideoMode videoMode = sfVideoMode(1280, 720);
sfWindow* window = sfWindow_create(videoMode, Animation,
sfNone, null);
}
For some reason this always crashes inside a void load( string
libNames ) function. The crash seems to happen inside the
'DerelictSFML2Window.load();'.
Why is that? I am using Visual Studio 2013, with the VisualD
add-on. I have created the solution using dub generate
visuald; this is my project.json:
{
name: testing,
description: testing,
authors: [Jeroen Bollen],
dependencies: {
derelict-sfml2 : ~master,
}
}
Hello. I've used your package.json and source code in an attempt
to replicate the problem, but could not. In this case, I'll still
offer some brute force advice:
1. Ensure that CSFML =2.0 dynamic libraries are in your PATH.
Version 2.1 is working for me.
2. Make sure that the CSFML dynamic libraries are for the right
architecture. I'm using the 32-bit Visual C++/GCC binaries
(http://www.sfml-dev.org/download/csfml/CSFML-2.1-windows-32bits.zip).
3. Remove %APPDATA%\dub to get rid of possibly old packages and
make sure your Dub is the latest version.
4. Try running it via dub rather than VisualD. i.e., dub run or
dub run --compiler=ldc2, etc.
Re: how to compose delegate type
On 12/05/2013 09:33 PM, Jesse Phillips wrote:
I don't think I understand what you mean:
this code illustrates it:
class Z {
string a() immutable {
return 1;
}
string b() {
return 2;
}
}
template F(t) {
alias immutable(t) F;
}
alias typeof(Z.init.a) Texpected;
alias typeof(Z.init.a) T;
static assert(is(F!(T) == Texpected));
void main() {}
above F doesn't work; immutable(void delegate()) and void delegate()
immutable are different types (I think the latter means 'this' is
immutable).
If t were a function pointer, you would apply the immutable to the
pointer target like so:
alias immutable(pointerTarget!t)* F
Re: I/O related question, and ini parsing
Alright cool, I'll get on that real soon, I'm not too used to D's importing system anyway, so I appreciate it. I suppose I'll have to do some research on pure and nothrow too, I've never really bothered with those.
Re: How to load a derelict program in D?
On Friday, 6 December 2013 at 19:50:52 UTC, Jeroen Bollen wrote:
I am using the derelict-sfml2 package in my code. My code:
import std.stdio;
import derelict.sfml2.window;
void main()
{
DerelictSFML2Window.load();
sfVideoMode videoMode = sfVideoMode(1280, 720);
sfWindow* window = sfWindow_create(videoMode, Animation,
sfNone, null);
}
For some reason this always crashes inside a void load( string
libNames ) function. The crash seems to happen inside the
'DerelictSFML2Window.load();'.
Is it crashing or are you getting an exception? If the CSFML DLLs
are not on your system path, then you'll get exceptions when
trying to load them. Make sure the DLLs are in the app's working
directory when you run it.
Also, for Derelict-specific issues, it's probably better to post
to the Derelict forums[1] rather than here.
[1] http://dblog.aldacron.net/forum/index.php
