Re: Having trouble porting basic GLFW C++ example to D
On Saturday, 7 October 2017 at 04:24:07 UTC, Matt Jones wrote: On Saturday, 7 October 2017 at 03:47:27 UTC, Joakim wrote: On Saturday, 7 October 2017 at 03:12:09 UTC, Matt Jones wrote: [...] Heh, that's the problem. [...] I ran into this myself, took me awhile to track it down. I too took the size of dynamic arrays this way: [...] Ah. I should have remembered that problem. Thanks. I'll see if that fixes it. Nice! That worked. Thanks.
Re: Having trouble porting basic GLFW C++ example to D
On Saturday, 7 October 2017 at 03:47:27 UTC, Joakim wrote: On Saturday, 7 October 2017 at 03:12:09 UTC, Matt Jones wrote: [...] Heh, that's the problem. [...] I ran into this myself, took me awhile to track it down. I too took the size of dynamic arrays this way: [...] Ah. I should have remembered that problem. Thanks. I'll see if that fixes it.
Re: Having trouble porting basic GLFW C++ example to D
On Saturday, 7 October 2017 at 03:12:09 UTC, Matt Jones wrote: I've been trying to port a basic GLFW C++ example to D. The C++ version shows the textures correctly. But the D version shows nothing. The code is almost identical. Heh, that's the problem. Does anyone know why the D version does not work? https://github.com/workhorsy/d_glfw I ran into this myself, took me awhile to track it down. I too took the size of dynamic arrays this way: https://github.com/workhorsy/d_glfw/blob/master/dlang/source/main.d#L158 https://github.com/workhorsy/d_glfw/blob/master/dlang/source/main.d#L161 That will give you 2 words for a slice or dynamic array, the length and pointer. What you want is the length of the array https://github.com/joakim-noah/android/blob/master/samples/Teapot/jni/TeapotRenderer.d#L192 multiplied by the size of the element https://github.com/joakim-noah/android/blob/master/samples/Teapot/jni/TeapotRenderer.d#L195 Sizeof works for static arrays, but is different for slices: that's likely your problem.
Having trouble porting basic GLFW C++ example to D
I've been trying to port a basic GLFW C++ example to D. The C++ version shows the textures correctly. But the D version shows nothing. The code is almost identical. Does anyone know why the D version does not work? https://github.com/workhorsy/d_glfw
Re: Infuriating DUB/DMD build bug.
On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote: I've got a github project and using DUB with DMD and I keep running into this problem. I've tried deleting the entire ...\AppData\Roaming\dub\packages folder, but the problem repeats the very next build attempt. [...] See my post in learn on dmd path. The dmd path code was written in 1987 and could do with an update to process longer windows paths properly. We are working on this and I guess a chance a pull request on Monday but it depends on what else comes up. In any case it's a trivial fix. Presuming I am right about it being a path length problem.
Re: Need importing dcompute.lib into my project
On Friday, 6 October 2017 at 18:12:43 UTC, kerdemdemir wrote: Hi, I have a cuda kernel already working in my cpp project(https://github.com/kerdemdemir/CUDABeamformer/blob/master/CudaBeamformer/kernel.cu) I am trying to convert this to D with using DCompute. I already compiled the DCompute source code and have dcompute.lib. But I am really not good with using libraries and don't know how to use DCompute in my D project(https://github.com/kerdemdemir/DSharpEar/tree/master/DSharpEar). I am not using DUB and compiling with VisualD. Can you guys please help with importing DCompute into my project? Regards Erdem You should add DCompute as a DUB dependancy.
Re: template auto deduction
On Friday, 6 October 2017 at 21:42:40 UTC, Steven Schveighoffer
wrote:
What you need is IFTI or "Implicit Function Template
Instantiation"
Note the "Function" part of it, in that it's only valid for
functions.
So you need a factory function:
auto m(T)(T x)
{
return M!(T)(x);
}
...
auto b = m(fs); // ok
There is an enhancement request to make constructors have the
same mechanism. Not sure if or when it would be implemented.
-Steve
Ha! Yes :)
Thanks a lot :)
That's what is meant by convenience methods inside the library,
sometimes...
Re: template auto deduction
On 10/6/17 5:08 PM, Alex wrote:
Hey, template gurus :)
given this:
struct M(alias I : S!E, alias S, E...)
{
R!E r;
this(S)(S initStruct) // line 4
{
r = R!E(initStruct);
}
}
struct R(E...)
{
this(S)(S initStruct) // line 12
{
// do some cool stuff
}
}
void main()
{
FS!(Etype1) fs;
auto m = M!(typeof(fs))(fs); // line 21.
auto a = M!(fs); // does not work
auto b = M(fs); // does not work
}
struct FS(T...){}
struct Etype1{}
Everything works as expected, especially line 21. The question is about
syntactic sugar: What I have to change, to use auto deduction and to
create the M struct like in line 22 or 23?
By the way, I'm aware, that the type matching in lines 4 and 12 is lost,
in the way it is written here. However, it is meant to exist, if this
helps in some way...
Thanks a lot in advance
Alex
What you need is IFTI or "Implicit Function Template Instantiation"
Note the "Function" part of it, in that it's only valid for functions.
So you need a factory function:
auto m(T)(T x)
{
return M!(T)(x);
}
...
auto b = m(fs); // ok
There is an enhancement request to make constructors have the same
mechanism. Not sure if or when it would be implemented.
-Steve
Re: Iterating over functions in module in order?
On Thursday, 5 October 2017 at 00:24:12 UTC, Jerry wrote:
Any ideas on how someone could iterate over functions in a
module as they appear, rather than any random order, without
having to manually label them?
Do you mean something like this?
/// --- code ---
module test165;
import std.stdio;
import std.traits : isFunction;
void main()
{
immutable b = [ __traits(allMembers, mixin(__MODULE__)) ];
static foreach(i, _; b)
static if(isFunction!(__traits(getMember, mixin(__MODULE__),
b[i])))
writeln(b[i]);
}
auto fun1(){}
struct S;
int i;
double[] arr;
auto fun3(int val){}
auto fun2(T)(T notAfun) {}
/// --- code ---
I saw a similar problem here:
http://forum.dlang.org/post/xratcdpxfepxowghj...@forum.dlang.org
template auto deduction
Hey, template gurus :)
given this:
struct M(alias I : S!E, alias S, E...)
{
R!E r;
this(S)(S initStruct)// line 4
{
r = R!E(initStruct);
}
}
struct R(E...)
{
this(S)(S initStruct)// line 12
{
// do some cool stuff
}
}
void main()
{
FS!(Etype1) fs;
auto m = M!(typeof(fs))(fs);// line 21.
auto a = M!(fs); // does not work
auto b = M(fs); // does not work
}
struct FS(T...){}
struct Etype1{}
Everything works as expected, especially line 21. The question is
about syntactic sugar: What I have to change, to use auto
deduction and to create the M struct like in line 22 or 23?
By the way, I'm aware, that the type matching in lines 4 and 12
is lost, in the way it is written here. However, it is meant to
exist, if this helps in some way...
Thanks a lot in advance
Alex
Re: dmd path handling is a bit dated
On Friday, October 06, 2017 20:11:25 Laeeth Isharc via Digitalmars-d-learn wrote: > And I'm posting here because we can submit a pull request, but I > didn't know whether to call Phobos or copy/paste as I haven't > submitted more than trivial doc changes to compiler. I've > written all of this up but on an internal gitlab. dmd is not currently allowed to use Phobos, because they don't want that dependency. But it shouldn't be a problem to copy over Phobos' implementation of something where appropriate. - Jonathan M Davis
Re: dmd path handling is a bit dated
On Friday, 6 October 2017 at 20:11:25 UTC, Laeeth Isharc wrote: DMD path handling is a bit dated, and it's causing build I mean I imagine getcwd and tk/filespec.c might not be the only places that need updating, but I was going to start with those and see what happened.
dmd path handling is a bit dated
DMD path handling is a bit dated, and it's causing build problems for us because on Windows it's easy to end up breaking DMD's limit - particularly given how dub likes to turn everything into a relative path. Windows has so many beautiful example of the costs of legacy compat. I just wrote down 5 ways it handles paths, and then realised there's another. There's a 260 char limit (less a bit, depending) in the old Windows API, but looking at the ddmd code there's a more restrictive limit of 131 chars + null for windows when it builds paths for the base directory. I think if you use Windows 32 file namespaces (eg \?\C:\D\foo\bar, and note the difference from \?C\D\foo\bar ) and the unicode library calls then you get up to 32,767 chars. We already have much better code in Phobos (for Windows it's hard-coded at 4K) getcwd, and I think either we should call Phobos or copy/paste the Phobos function into ddmd. And I'm posting here because we can submit a pull request, but I didn't know whether to call Phobos or copy/paste as I haven't submitted more than trivial doc changes to compiler. I've written all of this up but on an internal gitlab. https://github.com/dlang/dmd/blob/2bf9a9d731e88ebd8a175bd0a990a3b651e8df82/src/ddmd/tk/filespec.c (c) 1986-1987 by NorthWest Software. It could do with an update! " So there's an obvious set of related problems. Line 119 - current working dir is 131 chars + null. and on linux it's restricted to 255+null (not sure if that limit applies anymore to linux, but who cares for now). getcwd prototype is defined here: https://github.com/dlang/dmd/blob/ebd6606840afea0034ce599815ed950fd558981c/src/ddmd/dmodule.d and this is the prototype: extern (C) char* getcwd(char* buffer, size_t maxlen); it's deprecated and replaced by the ISO function: https://docs.microsoft.com/en-gb/cpp/c-runtime-library/reference/getcwd-wgetcwd okay - so: it's wrong to use that limit on linux and OSX. Linux PATH_MAX is 4096. OpenBSD is 1024. Linux paths are unlimited, apparently (OSX can have several k chars at least). And the Windows one should at least be PATH_MAX less a bit even without using long paths. (But then if you are going to use old winapi need to check its less than PATH_MAX if you extend). https://insanecoding.blogspot.co.uk/2007/11/pathmax-simply-isnt.html on Windows and indeed other operating systems we already have the correct code to get current working directory. so we just need to update dmd to use this. https://github.com/dlang/phobos/blob/v2.076.0/std/file.d#L2681 "
Re: For fun: Expressive C++ 17 Coding Challenge in D
I am a total beginner but I want to post that a lot.
auto autoCorrelation(R)(R range)
if (isRandomAccessRange!R)
{
import std.numeric : fft, inverseFft;
import std.range : chain, repeat, zip, dropBack;
import std.algorithm : map;
import std.complex;
auto residual = residualPowerOf2(range.length);
auto fftResult = range.chain(repeat(0, residual)).fft();
auto autoCorrResult = fftResult.zip(fftResult.map!(a =>
a.conj())).
map!( a=> a[0] * a[1] ).
inverseFft().
dropBack(residual).
map!( a => a.re );
return autoCorrResult;
}
I implemented auto correlation in C++ before which is I believe
2~3 time bigger(also I needed to compile fftw, lapack etc.. ) :
https://forum.kde.org/viewtopic.php?f=74=118619 .
That was the moment I feel in love with D.
Need importing dcompute.lib into my project
Hi, I have a cuda kernel already working in my cpp project(https://github.com/kerdemdemir/CUDABeamformer/blob/master/CudaBeamformer/kernel.cu) I am trying to convert this to D with using DCompute. I already compiled the DCompute source code and have dcompute.lib. But I am really not good with using libraries and don't know how to use DCompute in my D project(https://github.com/kerdemdemir/DSharpEar/tree/master/DSharpEar). I am not using DUB and compiling with VisualD. Can you guys please help with importing DCompute into my project? Regards Erdem
Re: Infuriating DUB/DMD build bug.
On Friday, 6 October 2017 at 09:12:09 UTC, Mike Parker wrote: On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote: AppData/Roaming/dub/packages, create a new directory off C: (say, C:\dub, manually fetch the packages you need into that directory and use `dub add-local` on them (see an example in the derelict docs [1]), then try to build your project again and see what happens. [1] http://derelictorg.github.io/building/without-dub/#fetching-packages-with-dub
Re: Infuriating DUB/DMD build bug.
On Thursday, 5 October 2017 at 21:48:20 UTC, WhatMeWorry wrote: With writing files, that's usually a permissions thing? But all the other 8 packages build fine? Note: I had a similar problem with derelict-assimp3 package, so I went to an entirely different system and cloned my project. But now it fails with the same error, but with a different package. Looks like it may be a system error as a result of the path being too long. I've encountered that a couple times over the years when building projects with dub. What I suggest you try is to remove the offending package(s) from AppData/Roaming/dub/packages, create a new directory off C: (say, C:\dub, manually fetch the packages you need into that directory and use `dub add-local` on them (see an example in the derelict docs [1]), then try to build your project again and see what happens.
