Re: Structure of platform specific vs non platform specific code

[rikki cattermole via Digitalmars-d-learn]

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

[Andrew Edwards via Digitalmars-d-learn]

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(""~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"

[9il via Digitalmars-d-learn]

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

[Moritz Maxeiner via Digitalmars-d-learn]

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

[Jonathan M Davis via Digitalmars-d-learn]

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"

[notna via Digitalmars-d-learn]

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

[Nordlöw via Digitalmars-d-learn]

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

[Igor via Digitalmars-d-learn]

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

[Stefan Koch via Digitalmars-d-learn]

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

[WhatMeWorry via Digitalmars-d-learn]

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

[bachmeier via Digitalmars-d-learn]

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

[rikki cattermole via Digitalmars-d-learn]

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

[Jacob Carlborg via Digitalmars-d-learn]

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

[Nordlöw via Digitalmars-d-learn]

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

[Stanislav Blinov via Digitalmars-d-learn]

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

[Nordlöw via Digitalmars-d-learn]

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

[Nordlöw via Digitalmars-d-learn]

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

[k-five via Digitalmars-d-learn]

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**

[David Zhang via Digitalmars-d-learn]

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**

[Stanislav Blinov via Digitalmars-d-learn]

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**

[David Zhang via Digitalmars-d-learn]

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.

Re: Error writing file a *.obj

[I Lindström via Digitalmars-d-learn]

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 :/


No need to be sorry. Questions are what this section is for. I've 
often ran into problems with over-zealous antivirus software in 
different things, so it's good to know it is also a possibility 
in this case. If you hadn't asked, I wouldn't have known that.


So thanks for the question. :)