On Monday, 6 July 2020 at 21:09:57 UTC, kinke wrote:
Similar case here; the 'varargs' end up in a GC-allocated
array. I've recently changed `scope` slice params, so that
array literal arguments are allocated on the caller's stack
instead; so adding `scope` for these variadics *should*
On Monday, 6 July 2020 at 20:25:11 UTC, Kayomn wrote:
example is forgetting to supply an arrange length when
array length*
On Monday, 6 July 2020 at 20:20:44 UTC, Stanislav Blinov wrote:
I'd say the original error should be reported on bugzilla, if
it isn't already; if only for the error message which is
ridiculously obscure.
Yeah, you're tellin' me lol. I spent the better part of the day
tracking this one down,
Something discovered in the D Language Code Club Discord server
with the help of Wild is that the following code:
struct Test { ~this() {} }
void tester(Test test, Test[] tests...) { }
extern(C) void main() {
tester(Test(), Test());
}
Raises the "TypeInfo cannot be used with ~betterC"
On Friday, 6 April 2018 at 14:15:08 UTC, Kayomn wrote:
On Friday, 6 April 2018 at 13:55:55 UTC, nkm1 wrote:
[...]
Figured I had a handle on how it worked doing but guess not.
One final question, however.
[...]
Nevermind, I'm blind. I missed the post-increment in newID().
On Friday, 6 April 2018 at 13:55:55 UTC, nkm1 wrote:
On Friday, 6 April 2018 at 13:10:23 UTC, Kayomn wrote:
ID tags are unique and spsecific to the class type. There
shouldn't be more than one type ID assigned to one class type.
The idea behind what it is I am doing is I am implementing a
Besides this, I tried something with types used as user defined
attributes.
https://dlang.org/spec/attribute.html#uda
Automatic compile time tagging is not my speciality, however, I
think is also achievable with mixins somehow?
But I don't know how to workaround the bug
On Friday, 6 April 2018 at 02:18:28 UTC, Kayomn wrote:
On Friday, 6 April 2018 at 01:22:42 UTC, Kayomn wrote:
On Friday, 6 April 2018 at 01:14:37 UTC, ketmar wrote:
Kayomn wrote:
[...]
it is already done for you, free of charge.
class Node {}
class RootNode : Node {}
On Friday, 6 April 2018 at 01:22:42 UTC, Kayomn wrote:
On Friday, 6 April 2018 at 01:14:37 UTC, ketmar wrote:
Kayomn wrote:
[...]
it is already done for you, free of charge.
class Node {}
class RootNode : Node {}
class SpriteNode : Node {}
void main () {
On Friday, 6 April 2018 at 01:14:37 UTC, ketmar wrote:
Kayomn wrote:
[...]
it is already done for you, free of charge.
class Node {}
class RootNode : Node {}
class SpriteNode : Node {}
void main () {
auto nodeId1 = typeid(Node);
I'll give a better example of what it is I'm trying to do.
These are node types. Their contents are not important in this
explanation, only that they operate as a tree structure.
class Node;
class RootNode : Node;
class SpriteNode : Node;
The result of getNodeID on a specific type is
On Friday, 6 April 2018 at 00:21:54 UTC, H. S. Teoh wrote:
On Thu, Apr 05, 2018 at 11:53:00PM +, Kayomn via
Digitalmars-d-learn wrote: [...]
[...]
[...]
[...]
`lastID`, as declared above, are runtime variables. The
'static' in this case just means it's thread-local, rather than
Hi,
I've got a scene graph which contains multiple inheriting types.
As such, I've been tagging them with a type enum for whenever I
need to do things such as loading a structure from binary.
Up until now I've been using an enum that looks like this:
On Wednesday, 28 February 2018 at 16:58:38 UTC, Mike Parker wrote:
On Wednesday, 28 February 2018 at 16:47:49 UTC, Kayomn wrote:
Yeah, I knew they were deprecated, just weren't aware Derelict
doesn't load them. Thanks though, I'd been up and down the
Derelict docs page and I didn't see
On Wednesday, 28 February 2018 at 14:02:48 UTC, Mike Parker wrote:
On Wednesday, 28 February 2018 at 12:02:27 UTC, Kayomn wrote:
import derelict.opengl3.gl3;
Whoa. Just noticed this. That's an older version of DerelictGL3
you're using there. You should really be using the latest
version
On Wednesday, 28 February 2018 at 12:36:37 UTC, bauss wrote:
On Wednesday, 28 February 2018 at 12:02:27 UTC, Kayomn wrote:
[...]
Most likely a library issue. Are you sure that you link to the
libraries correctly etc.?
I'm using DUB for package management and linking and any library
Maybe I'm missing something, but whenever I attempt to call
glBegin() with anything my program immediately encounters an
access violation.
I've got a very simple setup, with this being my main:
import base.application;
import derelict.opengl3.gl3;
import derelict.glfw3.glfw3;
int
On Tuesday, 27 February 2018 at 13:14:38 UTC, Mike Parker wrote:
On Tuesday, 27 February 2018 at 12:00:20 UTC, Kayomn wrote:
[...]
It *is* a version problem. The exception is a
SymbolLoadException, which means the loader found the library
just fine (you can see it in the file name,
Hi, I've been working on something using Windows and now I'm
attempting to build it on Linux with Dub, however I appear to be
having an issue.
import base.application;
import derelict.opengl3.gl3;
import derelict.glfw3.glfw3;
int main(string[] args) {
DerelictGL3.load();
On Monday, 26 February 2018 at 21:04:51 UTC, TheFlyingFiddle
wrote:
On Monday, 26 February 2018 at 20:50:35 UTC, Kayomn wrote:
[...]
Don't think you can alias member variables directly.
You could do this though:
struct Player {
Entity entity;
ref auto pos() inout { return
I've been experimenting with D's Better C mode, and I have a
question regarding something that I started thinking about after
watching one of Jonathon Blow's talks on data-oriented
programming - more specifically the aspect of fake "inheritance"
I have the following code. My question is if
21 matches
Mail list logo
