Re: Structure of platform specific vs non platform specific code
On 09/05/2017 7:08 PM, Igor wrote: On Tuesday, 9 May 2017 at 15:37:44 UTC, Stefan Koch wrote: On Tuesday, 9 May 2017 at 15:28:20 UTC, WhatMeWorry wrote: On Monday, 8 May 2017 at 21:16:53 UTC, Igor wrote: Hi, I am following Casey Muratori's Handmade Hero and writing it in DLang. This sounds very interesting. Maybe make it a public github project? It can only accessible for those who bought the game. That is right. If I manage to keep it up at least a bit more I will put it at https://github.com/HandmadeHero but that is only accessible for those who buy the game. Also thanks for the suggestions. I will definitely use it for platformServices part. In case you are interested in the reasoning for having platform code that imports game code Casey explains that in case where you structure all platform specific code in functions that other code should call you are making a needlessly big interface polluting the API space. For example you would need CreateWindow function in such library which games would only need to call once at startup; they won't need to create and close additional windows during their execution and they don't even need to know "Window" is a thing. Also some of that code is so different on some platforms that no API can cover it clearly. For example what should one expect CreateWindow to do on Android platform. A render point[0] versus window: [0] https://github.com/Devisualization/spew/blob/master/src/base/cf/spew/ui/rendering.d [1] https://github.com/Devisualization/spew/blob/master/src/base/cf/spew/ui/window/defs.d#L17
Access specifiers and visibility
Attempting to update a git repo to current D, I encounter the following deprecation messages: src/glwtf/signals.d-mixin-256(256,2): Deprecation: glwtf.input.BaseGLFWEventHandler._on_key_down is not visible from module glwtf.signals src/glwtf/signals.d-mixin-256(256,2): Deprecation: glwtf.input.BaseGLFWEventHandler._on_key_up is not visible from module glwtf.signals src/glwtf/signals.d-mixin-256(256,2): Deprecation: glwtf.input.BaseGLFWEventHandler._on_mouse_button_down is not visible from module glwtf.signals src/glwtf/signals.d-mixin-256(256,2): Deprecation: glwtf.input.BaseGLFWEventHandler._on_mouse_button_up is not visible from module glwtf.signals The offending line of code in signal.d for all four messages is: _impl.addSlot(obj, cast(void delegate())mixin("&obj."~method)); these methods are implemented in the following default constructor: class BaseGLFWEventHandler : AEventHandler { // [...] this() { on_key_down.connect!"_on_key_down"(this); on_key_up.connect!"_on_key_up"(this); on_mouse_button_down.connect!"_on_mouse_button_down"(this); on_mouse_button_up.connect!"_on_mouse_button_up"(this); } // [...] } Which are implemented in the following abstract class: abstract class AEventHandler { // input Signal!(int, int, int) on_key_down; Signal!(int, int, int) on_key_up; Signal!(int, int) on_mouse_button_down; Signal!(int, int) on_mouse_button_up; } I'm not sure how to address this issue so am seeking guidance on how to update this code such that it complies with current D. Thanks, Andrew
Re: "Rolling Hash computation" or "Content Defined Chunking"
On Tuesday, 9 May 2017 at 18:17:45 UTC, notna wrote: I hoped there may already be something in Mir or Weka.io or somewhere else... Will read the Golang, C and C++ source and see if my Dlang is good enough for ranges and the like magic... Hello notha, You may want to open a PR to mir-algorithm. I will help to make code idiomatic. https://github.com/libmir/mir-algorithm Thanks, Ilya
Re: Looking for an equivalent to C++ std::getline in D
On Tuesday, 9 May 2017 at 19:11:08 UTC, Jonathan M Davis wrote: LOL. I get the impression that it's often the tendancy of D folks is to get excited when D shows up as high in a list like Tiobe and to argue that the list doesn't mean much if D isn't high in the list. AKA confirmation bias. Not unique to D folks :)
Re: Looking for an equivalent to C++ std::getline in D
On Monday, May 08, 2017 11:41:02 Daniel N via Digitalmars-d-learn wrote: > On Monday, 8 May 2017 at 10:51:52 UTC, Ola Fosheim Grøstad wrote: > > On Sunday, 7 May 2017 at 20:50:10 UTC, Patrick Schluter wrote: > >> If you look on TIOBE [1] newest stats, D does not look so bad > >> after all. It's ranked 23 with a 1.38% share. The so > > > > Tiobe is a "hoax". > > > > Stack overflow counts for alternative languages: > > > > "swift": 146,374 > > "scala": 65,594 > > "go": 22,212 > > "rust": 6,596 > > "d": 2,211 > > "nim": 167 > > Stack-Overflow usage is clearly not representative of language > usage. > 1) Our forum is flourishing, why would any D developer use SO? > 2) The number of questions is directly proportional with the > difficulty of the language.(D is quite easy to learn, especially > compared to rust). There are a lot of different metrics that can be used to measure how popular a language is. Tiobe and SO are just two of them. And with each metric, you have to keep in mind how they get those numbers in order to figure out what they indicate. It's easy to tell that D is not as big as languages like C/C++, but it can be much harder to tell how its usage compares to languages like Rust. LOL. I get the impression that it's often the tendancy of D folks is to get excited when D shows up as high in a list like Tiobe and to argue that the list doesn't mean much if D isn't high in the list. - Jonathan M Davis
Re: "Rolling Hash computation" or "Content Defined Chunking"
On Saturday, 6 May 2017 at 07:21:51 UTC, Johannes Pfau wrote: Am Mon, 01 May 2017 21:01:43 + schrieb notna : Hi Dlander's. Found some interesting reads ([1] [2] [3]) about the $SUBJECT and wonder if there is anything available in the Dland?! If yes, pls. share. If not, how could it be done (D'ish) [1] - https://moinakg.wordpress.com/2013/06/22/high-performance-content-defined-chunking/ - https://github.com/moinakg/pcompress/blob/master/rabin/rabin_dedup.c [2] - https://restic.github.io/blog/2015-09-12/restic-foundation1-cdc [3] - http://www.infoarena.ro/blog/rolling-hash Thanks & regards Interesting concept. I'm not aware of any D implementation but it shouldn't be difficult to implement this in D: https://en.wikipedia.org/wiki/Rolling_hash#Cyclic_polynomial There's a BSD licensed haskell implementation, so a BSD licensed port would be very easy to implement: https://hackage.haskell.org/package/optimal-blocks-0.1.0 https://hackage.haskell.org/package/optimal-blocks-0.1.0/docs/src/Algorithm-OptimalBlocks-BuzzHash.html To make an implementation D'ish it could integrate with either std.digest or process input ranges. If you want to use it exclusively for chunking your code can be more efficient (process InputRange until a boundary condition is met). When using input ranges, prefer some kind of buffered approach, Range!ubyte[] instead of Range!ubyte for better performance. If you really want the rolling hash value for each byte in a sequence this will be less efficient as you'll have to enter data byte-by-byte. In this case it's extremely important for performance that your function can be inlined, so use templates: ubyte[] data; foreach(b; data) { // This needs to be inlined for performance reasons rollinghash.put(b); } -- Johannes Thanks for the feedback, Johannes. I hoped there may already be something in Mir or Weka.io or somewhere else... Will read the Golang, C and C++ source and see if my Dlang is good enough for ranges and the like magic...
Re: Scope checking on static array struct doesn't kick in
On Tuesday, 9 May 2017 at 13:30:49 UTC, Nordlöw wrote: I'll write a Bugzilla issue later today. https://issues.dlang.org/show_bug.cgi?id=17388
Re: Structure of platform specific vs non platform specific code
On Tuesday, 9 May 2017 at 15:37:44 UTC, Stefan Koch wrote: On Tuesday, 9 May 2017 at 15:28:20 UTC, WhatMeWorry wrote: On Monday, 8 May 2017 at 21:16:53 UTC, Igor wrote: Hi, I am following Casey Muratori's Handmade Hero and writing it in DLang. This sounds very interesting. Maybe make it a public github project? It can only accessible for those who bought the game. That is right. If I manage to keep it up at least a bit more I will put it at https://github.com/HandmadeHero but that is only accessible for those who buy the game. Also thanks for the suggestions. I will definitely use it for platformServices part. In case you are interested in the reasoning for having platform code that imports game code Casey explains that in case where you structure all platform specific code in functions that other code should call you are making a needlessly big interface polluting the API space. For example you would need CreateWindow function in such library which games would only need to call once at startup; they won't need to create and close additional windows during their execution and they don't even need to know "Window" is a thing. Also some of that code is so different on some platforms that no API can cover it clearly. For example what should one expect CreateWindow to do on Android platform.
Re: Structure of platform specific vs non platform specific code
On Tuesday, 9 May 2017 at 15:28:20 UTC, WhatMeWorry wrote: On Monday, 8 May 2017 at 21:16:53 UTC, Igor wrote: Hi, I am following Casey Muratori's Handmade Hero and writing it in DLang. This sounds very interesting. Maybe make it a public github project? It can only accessible for those who bought the game.
Re: Structure of platform specific vs non platform specific code
On Monday, 8 May 2017 at 21:16:53 UTC, Igor wrote: Hi, I am following Casey Muratori's Handmade Hero and writing it in DLang. This sounds very interesting. Maybe make it a public github project?
Re: Error writing file a *.obj
On Tuesday, 9 May 2017 at 02:33:06 UTC, dummy wrote: On Monday, 8 May 2017 at 12:29:27 UTC, bachmeier wrote: On Monday, 8 May 2017 at 11:56:10 UTC, dummy wrote: When i build some application with dub, i got this error: I'm not a Dub user, but it has its own forum, so you might want to try there: http://forum.rejectedsoftware.com/ Oh, i solve this problem my self... because, the 'Ransomeware Protection' feature of Bitdefender InternetSecurity 2017. dub and dmd working pretty when i turn off this feature. Very sorry for noob question :/ This is not really a noob question. Since it affects new users trying to run a Hello World program, I wonder if it would be worthwhile to add that information to the error message. Most of the people trying out D will simply give up and blame the language.
Re: Structure of platform specific vs non platform specific code
On 09/05/2017 2:53 PM, Jacob Carlborg wrote: On 2017-05-08 23:16, Igor wrote: Hi, I am following Casey Muratori's Handmade Hero and writing it in DLang. I got to Day 011: The Basics of Platform API Design where Casey explains the best way to structure platform specific vs non-platform specific code but his method cannot work in DLang since it uses modules and I am wondering what would be the best way to achieve the same in DLang. His way is to have these files: - platform.cpp (includes game.cpp directly, not game.h) - game.h (declares non-platform specific data types for communicating with platform layer and both game functions that platform layer needs to call and platform functions that game needs to call) - game.cpp (includes game.h and defines declared game functions) This scheme makes preprocessor actually merge all files into one but logically game.* files see nothing that is platform specific. The best idea for DLang I have is to separate platform into two modules: - platform.d (contains only code that needs to call into game code so it imports game.d) - platformServices.d (contains only code that game needs to call but wrapped in a common abstraction layer so game.d imports it) When it comes to platform specific code, one way to do it is to use one module per platform and then one common module that publicly imports the platform specific modules: module linux; module windows; module osx; module platform; version (linux) public import linux; else version (Windows) public import windows; else version (OSX) public import osx; else static assert("unsupported platform"); Without having looked at the above mentioned guide (or whatever it is), I would say that it would make more sense that if the game module imports that platform module than the other way around. Homemade hero is a video series by an experienced game dev on how to make a game from 0 to finish (still active!). But yes this technique makes more sense for D then the original one.
Re: Structure of platform specific vs non platform specific code
On 2017-05-08 23:16, Igor wrote: Hi, I am following Casey Muratori's Handmade Hero and writing it in DLang. I got to Day 011: The Basics of Platform API Design where Casey explains the best way to structure platform specific vs non-platform specific code but his method cannot work in DLang since it uses modules and I am wondering what would be the best way to achieve the same in DLang. His way is to have these files: - platform.cpp (includes game.cpp directly, not game.h) - game.h (declares non-platform specific data types for communicating with platform layer and both game functions that platform layer needs to call and platform functions that game needs to call) - game.cpp (includes game.h and defines declared game functions) This scheme makes preprocessor actually merge all files into one but logically game.* files see nothing that is platform specific. The best idea for DLang I have is to separate platform into two modules: - platform.d (contains only code that needs to call into game code so it imports game.d) - platformServices.d (contains only code that game needs to call but wrapped in a common abstraction layer so game.d imports it) When it comes to platform specific code, one way to do it is to use one module per platform and then one common module that publicly imports the platform specific modules: module linux; module windows; module osx; module platform; version (linux) public import linux; else version (Windows) public import windows; else version (OSX) public import osx; else static assert("unsupported platform"); Without having looked at the above mentioned guide (or whatever it is), I would say that it would make more sense that if the game module imports that platform module than the other way around. -- /Jacob Carlborg
Re: Scope checking on static array struct doesn't kick in
On Tuesday, 9 May 2017 at 12:25:29 UTC, Nordlöw wrote: On Tuesday, 9 May 2017 at 11:52:35 UTC, Nordlöw wrote: I've tagged the ref-returning functions (in this case `opSlice`) with `return scope` for my statically allocated array struct at Here's a simpler example https://github.com/nordlow/phobos-next/blob/cf85f449d24981fbe6269f8096db23282e2fbb65/tests/test_scope.d If I change the return value of `S.opSlice` to `int[]` correct `scope`-error handling kicks in. Tha is, scope checking via -dip1000 works for struct S { @safe pure nothrow @nogc int[] opSlice() return scope { return x[]; } int[4] x; } but not for struct S { @safe pure nothrow @nogc auto opSlice() return scope { return x[]; } int[4] x; } . I'll write a Bugzilla issue later today.
Re: Scope checking on static array struct doesn't kick in
On Tuesday, 9 May 2017 at 12:25:29 UTC, Nordlöw wrote: On Tuesday, 9 May 2017 at 11:52:35 UTC, Nordlöw wrote: I've tagged the ref-returning functions (in this case `opSlice`) with `return scope` for my statically allocated array struct at Here's a simpler example https://github.com/nordlow/phobos-next/blob/cf85f449d24981fbe6269f8096db23282e2fbb65/tests/test_scope.d Looks like a bug, if you change "auto" to "int[]" it starts complaining in f(). I have a question though, why is the syntax like this: auto opSlice() return scope; ? I don't see such in the DIP, proposed there is simply "scope" to the left of the declaration, i.e. scope auto opSlice(); Although with that syntax dmd complains about escaping 'this', as if it was scope { auto opSlice(); }. Is 'return scope' the syntax that is supposed to be used and it's just not reflected in the DIP, or?..
Re: Scope checking on static array struct doesn't kick in
On Tuesday, 9 May 2017 at 11:52:35 UTC, Nordlöw wrote: I've tagged the ref-returning functions (in this case `opSlice`) with `return scope` for my statically allocated array struct at Here's a simpler example https://github.com/nordlow/phobos-next/blob/cf85f449d24981fbe6269f8096db23282e2fbb65/tests/test_scope.d
Scope checking on static array struct doesn't kick in
I've tagged the ref-returning functions (in this case `opSlice`) with `return scope` for my statically allocated array struct at https://github.com/nordlow/phobos-next/blob/master/src/arrayn.d but for some reason the scope-checking (via -dip1000) allows both https://github.com/nordlow/phobos-next/blob/bde41f92b5373dd1365ad19ef9d0ecee4eb2d2cd/src/arrayn.d#L350 and https://github.com/nordlow/phobos-next/blob/bde41f92b5373dd1365ad19ef9d0ecee4eb2d2cd/src/arrayn.d#L390 to compile eventhough the life-time of the slices clearly outlives (is defined prior to) the lifetime of the fixed-length (stack-allocated) array/string struct instance. Have I missed something or is this simply not yet supported?
Re: Looking for an equivalent to C++ std::getline in D
On Monday, 8 May 2017 at 21:37:17 UTC, Ali Çehreli wrote: On 05/06/2017 02:24 AM, Stanislav Blinov wrote: It may D has this philosophy as Perl has: There's more than one way to do it I found more than 5 ways. another way: string[] input = [ "", "", "", "", "" ]; // reserve for 5 elements args[ 1 ].split( '/' ).remvoe!( element => element.empty ).copy( input ); Thanks anyway
Re: Converting a string[] to char**
On Tuesday, 9 May 2017 at 07:59:19 UTC, Stanislav Blinov wrote: On Tuesday, 9 May 2017 at 07:50:33 UTC, David Zhang wrote: If indeed there is no way to avoid allocation, do the allocations have to remain 'alive' for the duration of the instance? Or can I deallocate immediately afterwards? I can't seem to find it in the Vulkan spec. 2.3.1. Object Lifetime: Application-owned memory is immediately consumed by any Vulkan command it is passed into. The application can alter or free this memory as soon as the commands that consume it have returned. I see, thanks.
Re: Converting a string[] to char**
On Tuesday, 9 May 2017 at 07:50:33 UTC, David Zhang wrote: If indeed there is no way to avoid allocation, do the allocations have to remain 'alive' for the duration of the instance? Or can I deallocate immediately afterwards? I can't seem to find it in the Vulkan spec. 2.3.1. Object Lifetime: Application-owned memory is immediately consumed by any Vulkan command it is passed into. The application can alter or free this memory as soon as the commands that consume it have returned.
Re: Converting a string[] to char**
On Tuesday, 9 May 2017 at 05:52:28 UTC, Mike Parker wrote: On Tuesday, 9 May 2017 at 05:38:24 UTC, ag0aep6g wrote: You have to create a new array of pointers. As rikki cattermole has pointed out, you also have to null-terminate the individual strings, and pass the amount of pointers in a separate parameter. import std.algorithm.iteration: map; import std.array: array; import std.conv: to; import std.string: toStringz; string[] strs = ["foo", "bar", "baz"]; /* convert string[] to char*[]: */ immutable(char)*[] chptrs = strs.map!toStringz.array; immutable(char)** ppEnabledLayerNames = chptrs.ptr; uint enabledLayerCount = chptrs.length.to!uint; Although, if it's known that the array was populated with literals, toStringz isn't needed. String literals are automatically nul terminated. Thanks for all your answers. The strings are all predefined statically for the moment, with a '\0' character at the end. I take from this that there's no way to avoid allocating then? I had hoped... :( If indeed there is no way to avoid allocation, do the allocations have to remain 'alive' for the duration of the instance? Or can I deallocate immediately afterwards? I can't seem to find it in the Vulkan spec.