Re: Configuring DerelictGL3
Thanks for the help (and sorry for the slow reply, it took longer to get everything tested and configured than I would have liked... sorry if this is frowned upon on this forum...) I do have an odd bug, however, and I'm not sure how to go any further with it. So I'm using the standard process: DerelictGL3.load(); glContext = SDL_GL_CreateContext(sdlWindow); GLVersion glVersion = DerelictGL3.reload(); About 1/3 of the time, the program hangs on the 3rd line and never gets past it. Currently tracking whether admittedly odd things I'm doing with threads might be the culprit. I have a growing suspicion they might be. Looking forward to the BindBC release. I assume it's more or less intended to be a drop-in replacement for Derelict, with normal allowances for version-to-version updating, but more stable.
Re: crash when using in struct constructor
On Wednesday, 18 July 2018 at 12:10:18 UTC, baz wrote:
Specs are clear : it's a global so it's evaluated at compile
time
(https://dlang.org/spec/declaration.html#global_static_init)
Example code should not compile.
Indeed. Inside a function it does actually work.
And ofcourse for
class Test {
List ls = 1;
}
it's going to make a static initializer which is then copied
during construction of Test, so that's never going to work with
the
Re: HMAC and toHexString
On Wednesday, 18 July 2018 at 11:29:42 UTC, baz@dlang-community wrote: On Wednesday, 18 July 2018 at 11:22:36 UTC, Nicholas Wilson wrote: On Wednesday, 18 July 2018 at 05:54:48 UTC, Nicholas Wilson wrote: [...] Ahh, the joys of memory corruption. You've reached https://issues.dlang.org/show_bug.cgi?id=16519 maybe ? Not sure if it was that or some of the other memory corruption I was experiencing.
Re: Is it feasible to slowly rewrite a C++ codebase in D?
On Tuesday, 17 July 2018 at 22:10:52 UTC, jmh530 wrote: On Tuesday, 17 July 2018 at 16:39:48 UTC, bachmeier wrote: On Tuesday, 17 July 2018 at 15:55:03 UTC, bachmeier wrote: On Tuesday, 17 July 2018 at 06:57:37 UTC, drug wrote: [...] I'm going to create an issue on Github. This is the output I get: [...] I solved that problem but now I have others. dpp is a good thing on paper but maybe not yet in practice. Echoing what Andrei and Walter say all the time, it's not going to get fixed without bug reports... I plan to report this...eventually.
Re: crash when using in struct constructor
On Wednesday, 18 July 2018 at 11:35:40 UTC, baz wrote: On Wednesday, 18 July 2018 at 11:27:33 UTC, baz@dlang-community wrote: On Monday, 16 July 2018 at 22:21:12 UTC, H. S. Teoh wrote: On Mon, Jul 16, 2018 at 10:08:34PM +, Eric via Digitalmars-d-learn wrote: [...] It's not illegal per se, but a very, very bad idea in general, because in D, structs are expected to be int-like POD values that can be freely copied/moved around by the compiler. More specifically, when structs are passed into functions or returned from functions, they may be moved around. Which means internal pointers will wind up being wrong. [...] Moving doesn't seem to be the issue here. Despite of the ICE, this code shouldn't compile, unless "" is allowed at compile-time. still with .init() trick this works, so im' not super sure... NVM the .init() trick. Specs are clear : it's a global so it's evaluated at compile time (https://dlang.org/spec/declaration.html#global_static_init) Example code should not compile.
Re: crash when using in struct constructor
On Wednesday, 18 July 2018 at 11:27:33 UTC, baz@dlang-community wrote: On Monday, 16 July 2018 at 22:21:12 UTC, H. S. Teoh wrote: On Mon, Jul 16, 2018 at 10:08:34PM +, Eric via Digitalmars-d-learn wrote: [...] It's not illegal per se, but a very, very bad idea in general, because in D, structs are expected to be int-like POD values that can be freely copied/moved around by the compiler. More specifically, when structs are passed into functions or returned from functions, they may be moved around. Which means internal pointers will wind up being wrong. [...] Moving doesn't seem to be the issue here. Despite of the ICE, this code shouldn't compile, unless "" is allowed at compile-time. still with .init() trick this works, so im' not super sure...
Re: HMAC and toHexString
On Wednesday, 18 July 2018 at 11:22:36 UTC, Nicholas Wilson wrote: On Wednesday, 18 July 2018 at 05:54:48 UTC, Nicholas Wilson wrote: [...] Ahh, the joys of memory corruption. Yep, actually this one is a very common one. However, -dip1000 would warn you here ...
Re: Why does templated interface function return something different than final function?
On Wednesday, 18 July 2018 at 11:09:12 UTC, Timoses wrote:
Why is the interface templated function not also returning the
class C toString return value "in C"??
interface iface
{
void toString(scope void delegate(const(char)[]) sink) const;
final string convert() inout
{
import std.conv;
// assert(std.conv.to!string(this) == "in C"); // fails!
return std.conv.to!string(this);
}
final string convert2() const
{
import std.conv;
assert(std.conv.to!string(this) == "in C");
return std.conv.to!string(this);
}
}
class C : iface
{
void toString(scope void delegate(const(char)[]) sink) const
{
sink("in C");
}
}
void main ()
{
iface i = new C();
import std.stdio;
writeln(i.convert); // "app.C"
writeln(i.convert2()); // "in C"
}
It seems like `inout` triggers some odd behaviour??
Sorry, I experimented a bit and forgot to change the topic to
something more fitting, e.g.
"Why does inout struct function return different results?"
Re: crash when using in struct constructor
On Monday, 16 July 2018 at 22:21:12 UTC, H. S. Teoh wrote: On Mon, Jul 16, 2018 at 10:08:34PM +, Eric via Digitalmars-d-learn wrote: [...] It's not illegal per se, but a very, very bad idea in general, because in D, structs are expected to be int-like POD values that can be freely copied/moved around by the compiler. More specifically, when structs are passed into functions or returned from functions, they may be moved around. Which means internal pointers will wind up being wrong. [...] Moving doesn't seem to be the issue here. Despite of the ICE, this code shouldn't compile, unless "" is allowed at compile-time.
Re: Implicit conversion of struct with methods to immutable in pure function fails
On Tuesday, 17 July 2018 at 06:24:12 UTC, Simen Kjærås wrote:
That makes sense. The problem is F has a context pointer to the
main() block, since it's a non-static struct with methods
inside a block. It doesn't actually use the context pointer for
anything, so it possibly shouldn't have one, but it does, so we
have to work around it.
The fix is to mark F as static, or move it outside the main()
block.
--
Simen
Thanks for the explanation.
But why is a context pointer a problem? Is it problematic because
the context pointer to the main scope can not guarantee
`immutable`? E.g. if I happened to use data from main in a
function of the immutable struct then... well then what?
The struct would still be immutable, but what would prevent a
function from using non-immutable data?
E.g. I could do this
int gnumber = 3;
struct F
{
int i;
void fun() immutable
{
gnumber = 5;
}
}
void main ()
{
immutable F f = F();
f.fun;
}
I declared `fun()` to be an immutable function. So calling the
immutable struct function `F.fun()` changes a module scope int.
The same could be applied to local data of the main scope,
however the following fails:
void main ()
{
int mnumber = 3;
struct F
{
int i;
void fun() immutable
{
// Error: immutable function onlineapp.main.F.fun
cannot access mutable data mnumber
mnumber = 5;
}
}
immutable F f = F();
f.fun;
}
Is this connected why I can't implicitly convert a local struct
with a context pointer to immutable? What's the reason behind it?
Re: HMAC and toHexString
On Wednesday, 18 July 2018 at 11:22:36 UTC, Nicholas Wilson wrote: On Wednesday, 18 July 2018 at 05:54:48 UTC, Nicholas Wilson wrote: [...] Ahh, the joys of memory corruption. You've reached https://issues.dlang.org/show_bug.cgi?id=16519 maybe ?
Re: HMAC and toHexString
On Wednesday, 18 July 2018 at 05:54:48 UTC, Nicholas Wilson wrote: ... string key = "blahblahblah"; auto mac = hmac!SHA256(key.representation); string s = ...,t=...u=...,v=...; foreach(w;AliasSeq!(s,t,u,v)) mac.put(w.representation); ubyte[32] s = mac.finish; string sig = toHexString!(LetterCase.lower)(s); writeln(sig); // From what I understand Should print something like 41771e2d0d6c1cf7f442aa8547783ea5b126bfc15a4b354e94d0eaea2ab0fa1a // Actually prints something like x"31 36 39 33 39 32 38 31 62 38 31 62 36 36 62 63 63 34 63 36 36 61 62 32 34 37 64 32 64 34 61 00 78 2A 55 5B FF 7F 00 00 78 2A 55 5B FF 7F 00 00 E0 2A 55 5B FF 7F 00 00 08 2C 55 5B FF 7F 00 00"c Note the nuls and things like FF What am I doing wrong here? Ahh, the joys of memory corruption.
Why does templated interface function return something different than final function?
Why is the interface templated function not also returning the
class C toString return value "in C"??
interface iface
{
void toString(scope void delegate(const(char)[]) sink) const;
final string convert() inout
{
import std.conv;
// assert(std.conv.to!string(this) == "in C"); // fails!
return std.conv.to!string(this);
}
final string convert2() const
{
import std.conv;
assert(std.conv.to!string(this) == "in C");
return std.conv.to!string(this);
}
}
class C : iface
{
void toString(scope void delegate(const(char)[]) sink) const
{
sink("in C");
}
}
void main ()
{
iface i = new C();
import std.stdio;
writeln(i.convert); // "app.C"
writeln(i.convert2()); // "in C"
}
It seems like `inout` triggers some odd behaviour??
Re: HMAC and toHexString
On Wednesday, 18 July 2018 at 05:54:48 UTC, Nicholas Wilson wrote:
...
string key = "blahblahblah";
auto mac = hmac!SHA256(key.representation);
string s = ...,t=...u=...,v=...;
foreach(w;AliasSeq!(s,t,u,v))
mac.put(w.representation);
ubyte[32] s = mac.finish;
string sig = toHexString!(LetterCase.lower)(s);
writeln(sig);
// From what I understand Should print something like
41771e2d0d6c1cf7f442aa8547783ea5b126bfc15a4b354e94d0eaea2ab0fa1a
// Actually prints something like x"31 36 39 33 39 32 38 31 62
38 31 62 36 36 62 63 63 34 63 36 36 61 62 32 34 37 64 32 64 34
61 00 78 2A 55 5B FF 7F 00 00 78 2A 55 5B FF 7F 00 00 E0 2A 55
5B FF 7F 00 00 08 2C 55 5B FF 7F 00 00"c
Note the nuls and things like FF
What am I doing wrong here?
Don't know, what you mean. Works for me:
´´´
import std.stdio;
import std.digest.hmac;
import std.digest.sha;
import std.string;
import std.meta;
void main()
{
string key = "blahblahblah";
auto mac = hmac!SHA256(key.representation);
string s = "...",t="...", u="...",v="...";
foreach(w;AliasSeq!(s,t,u,v))
mac.put(w.representation);
ubyte[32] r = mac.finish;
r.toHexString!(LetterCase.lower).writeln;
}
´´´
output:
dc84632fc9b5d1f4b879d9aa021ae0d089e7f66a2fd2e824829cfceedbece729
