Re: How can I override the defeat compiler select by Dub?
On Sunday, 23 June 2019 at 23:10:48 UTC, Mike Brockus wrote: If you never seen Meson before then pick up a camera and take a picture: 樂 https://mesonbuild.com/ Nope. Wasn't working on Windows last time I checked. Hometown Meson user here simply just wondering how can I tell Dub to use dmd to compile my dependence in Meson? Isn't there anything in meson recipe to tell dub use --compiler=ldc2 switch? Or you can also try moving LDC/GDC in your %PATH% so that they come before DMD (works on Windows).
How can I override the defeat compiler select by Dub?
If you never seen Meson before then pick up a camera and take a picture: 樂 https://mesonbuild.com/ Hometown Meson user here simply just wondering how can I tell Dub to use dmd to compile my dependence in Meson? It’s one of the last things blocking me from having healthy D Meson projects that integrate nicely with Dub based projects.
Re: Casting to interface not allowed in @safe code?
On Tuesday, 21 May 2019 at 07:59:13 UTC, Jim wrote: On Tuesday, 21 May 2019 at 07:33:17 UTC, rumbu wrote: On Tuesday, 21 May 2019 at 07:16:49 UTC, Jim wrote: On Tuesday, 21 May 2019 at 07:04:27 UTC, rumbu wrote: On Tuesday, 21 May 2019 at 05:51:30 UTC, Jim wrote: That's because foo is of type Base, not implementing FeatureX. Right, Base isn't implementing FeatureX, but foo is really a Foo That's your knowledge, for the compiler foo is really a Base, as written in your own code. Yes, thinking about it again it makes sense. It doesn't even slightly make sense. I just ran into this today myself. Unlike Java and C#, casting from Foo to FeatureX is not an assertion that the Foo implements FeatureX. Instead it's how you test at runtime if the class of a specific object derived from Foo implements FeatureX: if it doesn't then the result of the cast is null. I've opened a bug report at https://issues.dlang.org/show_bug.cgi?id=2.
Re: gtkDcoding Facelift
On Sunday, 23 June 2019 at 10:55:52 UTC, Ron Tarrant wrote: Stage 1 is now complete. Blog entries are color-associated in an effort to make things more visual. Each topic also has its own avatar. Points to anyone who can figure out why each avatar is associated with its topic. https://gtkdcoding.com/ Thanks a lot.it is very cool!
shifted lowerBound with ranges
Hi, I am trying to convert some pointer based C++ code to ranges.
Given a sorted list of numbers w and a value v, I want to extract
a sublist containing
exactly s numbers <=v and all numbers >v.
The following code "works", but it is ugly:
-the result of shiftedLowerBound is not a slice of the original
array and it has a different type
-if the operation is repeated with increasing v the search
algorithm cannot use the result of the previous computation.
I looked at the code of std.range and it seems that the result
can be achieved by using the function getTransitionIndex of
SortedRange, but it is private. Am I overlooking something that
makes it possible to achieve my goal using the range interface?
-
import std.stdio;
import std.range;
import std.algorithm;
auto shiftedLowerBound(W,V)(W w, V v, long s )
{
auto ws=assumeSorted(w);
auto pps=ws.trisect(v);
long k=pps[1].length-s;
return chain( (pps[0])[$+min(k,0)..$], (pps[1])[max(k,0)..$],
pps[2] );
}
void main()
{
long[]
w=[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,15,15,15,16,17,18,19,20,21];
long[] vs=[10,15];
int s=6;
foreach(v;vs)
{
writeln(w.shiftedLowerBound(v,s));
}
}
Re: Meson build system user learning D.
On Monday, 27 May 2019 at 16:49:45 UTC, Russel Winder wrote: On Mon, 2019-05-27 at 16:13 +, Mike Brockus via Digitalmars-d-learn wrote: […] I tried that custom command voodoo then I tried to use 'dub' as a method for hunting down dependencies. Basically got something like this. Apologies but I am not sure what you have tried. Installing unit- threaded as a shared library is so as to build a D project without dub at all. What I didn't say in the previous email is that if you are installing libraries not to the standard place you have to set some environment variables. In my case, consistent with the build instructions I gave for my case: PKG_CONFIG_PATH=.:/home/users/russel/Built/share/pkgconfig:/home/users/russel/Built/lib/pkgconfig LD_LIBRARY_PATH=.:/home/users/russel/Built/lib Having . in the paths is not something everyone does though. ''' Found DUB: /usr/local/bin/dub (DUB version 1.15.0, built on May 4 2019) Dependency unit-threaded found: NO meson.build:71:0: ERROR: Dependency "unit-threaded" not found ''' This seems like you are using Dub from within the Meson/Ninja build, this is not something I do. I know you can use Dub from Meson to deal with dependencies, but this is not something I do. I build all the dependencies and then build the application without Dub. If using Dub from Meson to handle dependencies becomes the de facto standard I'll give it a whirl. I finally got D unit testing working without having to include main, it was only a compiler flag away and with the help of other D programmers. https://github.com/squidfarts/d-porject However that doesn’t mean I gave up on unit-threaded it’s just that I should start with using what is already provided by the language and if I happen to grow out of the basic tools then I will try again.
Re: Using std.algorithm.iteration to Calculate Hamming Distance
On Sunday, 23 June 2019 at 13:29:25 UTC, KnightMare wrote: zip( "hello world", "Hello World" ).map!"a[0] != a[1]".sum Excellent! Thank you!
Re: Using std.algorithm.iteration to Calculate Hamming Distance
On Sunday, 23 June 2019 at 13:10:51 UTC, Samir wrote:
D already has a function to calculate the Levenshtein
distance[1]. I am trying to come up with a function to
calculate the Hamming distance[2] between two strings, `a` and
`b`. So far, this seems to work:
foreach (i, j; zip(a, b)) {
if (i != j)
++hammingDistance;
}
zip( "hello world", "Hello World" ).map!"a[0] != a[1]".sum
Using std.algorithm.iteration to Calculate Hamming Distance
D already has a function to calculate the Levenshtein
distance[1]. I am trying to come up with a function to calculate
the Hamming distance[2] between two strings, `a` and `b`. So
far, this seems to work:
foreach (i, j; zip(a, b)) {
if (i != j)
++hammingDistance;
}
Is there a way to use any of the std.algorithm.iteration[3]
algorithms such as `filter` or `map` to do this as well?
[1]
https://dlang.org/phobos/std_algorithm_comparison.html#levenshteinDistance
[2] https://en.wikipedia.org/wiki/Hamming_distance
[3] https://dlang.org/phobos/std_algorithm_iteration.html
Re: gtkDcoding Facelift
On Sunday, 23 June 2019 at 10:55:52 UTC, Ron Tarrant wrote: Stage 1 is now complete. Blog entries are color-associated in an effort to make things more visual. Each topic also has its own avatar. Points to anyone who can figure out why each avatar is associated with its topic. https://gtkdcoding.com/ Great work, thank you !
gtkDcoding Facelift
Stage 1 is now complete. Blog entries are color-associated in an effort to make things more visual. Each topic also has its own avatar. Points to anyone who can figure out why each avatar is associated with its topic. https://gtkdcoding.com/
Re: Options for unit testing in D?
On Sunday, 23 June 2019 at 01:26:29 UTC, Mike Brockus wrote: I think we made a lot of progress, suddenly it's working and I don't need to include main. Is there a way to indicate based on console output that one executable is the tester and the other is the application? unittest blocks are skipped completely by the compiler when the -unittest command line option is not passed. So you can leave unittest code embedded in between the rest (specially for proper unit tests of functions and classes) and there is no need to worry about file separation. Even when you write a separate file with tests, all its code inside unittest blocks can be skipped for the compiler. In the case of dub, it has a dedicated option, "dub test" instead of "dub build" or "dub run" https://dub.pm/commandline.html#test
