Re: Parallelizing factorial computation
On Friday, 24 August 2018 at 20:43:46 UTC, Peter Alexander wrote: On Friday, 24 August 2018 at 13:04:47 UTC, Uknown wrote: I was quite surprised by the fact that parallel ran so much slower than recursive and loop implementations. Does anyone know why? n = 100 is too small to see parallelism gains. Try n = 1 https://run.dlang.io/is/XDZTSd I was using n = 1 originally, I reduced it because that wasn't running on run.dlang. Tried this again on my machine and you were right.
Re: "The D Way" to run a sequence of executables?
On Friday, 24 August 2018 at 17:36:25 UTC, Matthew OConnor wrote:
I'd like to run a sequence of executables with something like
std.process.execute, but I would like the sequence to error out
if one of the executables returns a non-zero return code. What
is the recommended way to do this? A wrapper that throws
exceptions? Checking return values?
Here'd be a neat way if you don't mind it not terminating early.
The first call will need a dummy value for prevStatus where the
status field is 0.
import std.typecons;
alias ExecuteTuple = Tuple!(int,"status",string,"output");
ExecuteTuple call(ExecuteTuple prevStatus, string process)
{
import std.process;
if (prevStatus.status != 0)
return prevStatus;
else
return execute(process);
}
Re: Patterns to avoid GC with capturing closures?
On Friday, 24 August 2018 at 15:18:13 UTC, Peter Alexander wrote:
I can write scaleAll like this:
auto scaleAll(int[] xs, int m) @nogc {
return repeat(m).zip(xs).map!(mx => mx[0] * mx[1]);
}
So that repeat(m) stores m, but it is quite hacky to work like
this.
Here's a spoonful of sugar to help that go down easier:
https://run.dlang.io/is/8lTmZg
Re: "The D Way" to run a sequence of executables?
On Friday, August 24, 2018 11:36:25 AM MDT Matthew OConnor via Digitalmars- d-learn wrote: > I'd like to run a sequence of executables with something like > std.process.execute, but I would like the sequence to error out > if one of the executables returns a non-zero return code. What is > the recommended way to do this? A wrapper that throws exceptions? > Checking return values? AFAIK, you're only two options are to either make consequitive calls to one of the execute family of functions where you check the return code and act accordingly (whether you use exceptions to deal with it is up to you, but either way, you have to check the result of each call to execute, since it doesn't throw), or you use one of the functions which uses the shell (e.g. executeShell) and write it out the way you would on the command-line with ||'s and/or &&'s. Either way, Phobos doesn't provide any functions that are specifically for calling a sequence of executables rather than just one. So, you're going to have to figure out how to put that together in a way that works best for you and what you're doing given what std.process has. - Jonathan M Davis
Re: Cross compile windows programs on linux
On Friday, August 24, 2018 3:28:37 PM MDT Nick Sabalausky (Abscissa) via Digitalmars-d-learn wrote: > On 08/24/2018 12:30 PM, John Burton wrote: > > On Friday, 24 August 2018 at 15:26:30 UTC, kinke wrote: > >> On Friday, 24 August 2018 at 13:10:40 UTC, John Burton wrote: > >>> Is in the subject. Are there any cross compilers that will run on a > >>> linux system but compile D code using Win32 into a windows .exe file, > >>> preferably 64 bit? I can find hints of cross compilers but not really > >>> seen anything packaged up? > >> > >> See https://forum.dlang.org/post/acjcrfvxloapdlapz...@forum.dlang.org. > > > > Oh thank you. > > I did a search but somehow missed that > > You could probably also just run the windows version of the compiler > under wine. I think I remember hearing of people doing that. That will probably work, but actually running the program that you build is another story. I actually originally developed the Windows-specific portion of std.datetime using wine, and I ended up with some bugs in my code, because the way that wine behaved when running it did not actually match what Windows did like it was supposed to. However, what dmd itself does has so little to do with the Win32 API that building code using dmd shouldn't be a problem. - Jonathan M Davis
Re: Cross compile windows programs on linux
On 08/24/2018 12:30 PM, John Burton wrote: On Friday, 24 August 2018 at 15:26:30 UTC, kinke wrote: On Friday, 24 August 2018 at 13:10:40 UTC, John Burton wrote: Is in the subject. Are there any cross compilers that will run on a linux system but compile D code using Win32 into a windows .exe file, preferably 64 bit? I can find hints of cross compilers but not really seen anything packaged up? See https://forum.dlang.org/post/acjcrfvxloapdlapz...@forum.dlang.org. Oh thank you. I did a search but somehow missed that You could probably also just run the windows version of the compiler under wine. I think I remember hearing of people doing that.
Re: Parallelizing factorial computation
On Friday, 24 August 2018 at 13:04:47 UTC, Uknown wrote: I was quite surprised by the fact that parallel ran so much slower than recursive and loop implementations. Does anyone know why? n = 100 is too small to see parallelism gains. Try n = 1 https://run.dlang.io/is/XDZTSd
Re: Cross compile windows programs on linux
On Friday, 24 August 2018 at 16:30:56 UTC, John Burton wrote: On Friday, 24 August 2018 at 15:26:30 UTC, kinke wrote: On Friday, 24 August 2018 at 13:10:40 UTC, John Burton wrote: Is in the subject. Are there any cross compilers that will run on a linux system but compile D code using Win32 into a windows .exe file, preferably 64 bit? I can find hints of cross compilers but not really seen anything packaged up? See https://forum.dlang.org/post/acjcrfvxloapdlapz...@forum.dlang.org. Oh thank you. I did a search but somehow missed that LLD has a nasty bug when using large static data members. https://bugs.llvm.org/show_bug.cgi?id=38645 I got access violations in the resulting binary when using it for linking complex apps. Be aware.
Re: How to best implement a DSL?
On Saturday, 28 July 2018 at 17:01:22 UTC, rikki cattermole wrote: You missed my point here. There is nothing special about parsing at CTFE, you're just restricted as to the language features you can use (e.g. no extern's), that's it. Is there an example of how this could be done?
"The D Way" to run a sequence of executables?
I'd like to run a sequence of executables with something like std.process.execute, but I would like the sequence to error out if one of the executables returns a non-zero return code. What is the recommended way to do this? A wrapper that throws exceptions? Checking return values?
Re: Cross compile windows programs on linux
On Friday, 24 August 2018 at 15:26:30 UTC, kinke wrote: On Friday, 24 August 2018 at 13:10:40 UTC, John Burton wrote: Is in the subject. Are there any cross compilers that will run on a linux system but compile D code using Win32 into a windows .exe file, preferably 64 bit? I can find hints of cross compilers but not really seen anything packaged up? See https://forum.dlang.org/post/acjcrfvxloapdlapz...@forum.dlang.org. Oh thank you. I did a search but somehow missed that
Re: Fast OpenGL-based visualization engine mainly for animated two-dimensional graphs
24.08.2018 17:38, Per Nordlöw пишет: On Friday, 24 August 2018 at 14:34:46 UTC, Per Nordlöw wrote: On Friday, 24 August 2018 at 14:03:08 UTC, drug wrote: imgui, but now I'm replacing it by nuklear. Is nuklear a software project that can be found somewhere? Ahh, I presume you mean - https://github.com/vurtun/nuklear - https://github.com/mogud/nukleard I use dpp to make binding to nuklear, my second attempt https://github.com/drug007/beholder In general I'd like to make an utility that can read some files and draw their content. First of all I'm interested in time series visualization. Also it would be nice to have something like simple form of ParaView https://www.paraview.org
Re: Cross compile windows programs on linux
On Friday, 24 August 2018 at 13:10:40 UTC, John Burton wrote: Is in the subject. Are there any cross compilers that will run on a linux system but compile D code using Win32 into a windows .exe file, preferably 64 bit? I can find hints of cross compilers but not really seen anything packaged up? See https://forum.dlang.org/post/acjcrfvxloapdlapz...@forum.dlang.org.
Re: Patterns to avoid GC with capturing closures?
On 8/24/18 11:18 AM, Peter Alexander wrote:
Consider this code, which is used as an example only:
auto scaleAll(int[] xs, int m) {
return xs.map!(x => m * x);
}
As m is captured, the delegate for map will rightly allocate the closure
in the GC heap.
In C++, you would write the lambda to capture m by value, but this is
not a facility in D.
I can write scaleAll like this:
auto scaleAll(int[] xs, int m) @nogc {
return repeat(m).zip(xs).map!(mx => mx[0] * mx[1]);
}
So that repeat(m) stores m, but it is quite hacky to work like this.
I could write my own range that does this, but this is also not desirable.
Are there any established patterns, libraries, or language features that
can help avoid the GC allocation in a principled way here?
This is somewhat related to a suggestion I had last month:
https://forum.dlang.org/post/pjnue1$olt$1...@digitalmars.com
I also hate to have such a thing allocate. The only scalable solution I
can think of is to write your own range function which has the
appropriate state saved by value. But then you lose all the goodies from
Phobos.
Having a way to capture state and give that state to std.algorithm
ranges would be really cool.
-Steve
Patterns to avoid GC with capturing closures?
Consider this code, which is used as an example only:
auto scaleAll(int[] xs, int m) {
return xs.map!(x => m * x);
}
As m is captured, the delegate for map will rightly allocate the
closure in the GC heap.
In C++, you would write the lambda to capture m by value, but
this is not a facility in D.
I can write scaleAll like this:
auto scaleAll(int[] xs, int m) @nogc {
return repeat(m).zip(xs).map!(mx => mx[0] * mx[1]);
}
So that repeat(m) stores m, but it is quite hacky to work like
this.
I could write my own range that does this, but this is also not
desirable.
Are there any established patterns, libraries, or language
features that can help avoid the GC allocation in a principled
way here?
Re: Fast OpenGL-based visualization engine mainly for animated two-dimensional graphs
On Friday, 24 August 2018 at 14:34:46 UTC, Per Nordlöw wrote: On Friday, 24 August 2018 at 14:03:08 UTC, drug wrote: imgui, but now I'm replacing it by nuklear. Is nuklear a software project that can be found somewhere? Ahh, I presume you mean - https://github.com/vurtun/nuklear - https://github.com/mogud/nukleard
Re: Fast OpenGL-based visualization engine mainly for animated two-dimensional graphs
On Friday, 24 August 2018 at 14:03:08 UTC, drug wrote: imgui, but now I'm replacing it by nuklear. Is nuklear a software project that can be found somewhere?
Re: Fast OpenGL-based visualization engine mainly for animated two-dimensional graphs
24.08.2018 16:32, Per Nordlöw пишет: Is anybody working on a D-based really fast OpenGL-based visualization engine that supports tessellation of 2d primitives on the GPU? For instance, if I want to animate a huge amount of circles (in a 2d-graph) and I would like to only have to send an array of centers and radiuses and optionally colors, and transparencies to the GPU and then have the circles tessellated and rasterized there. I need this for visualizing and animating huge graphs (potentially millions of nodes) using the powers present in modern day GPUs. I'm interested in both pure-D implementations and wrappers over open-source C/C++ based implementations supported by Linux. Does a Vulkan-based implementation in D provide any benefits with regards to CPU-to-GPU-data-transfer and on-GPU-tesselation? I also need an engine to draw 2d (and 3d later) primitives like you've described above. I have a couple of unfinished attempts to make something like it. My specific is ability to inspect the data using some treeview widget. I considered GTK and Qt (both pure Qt and Qml) and they were too complex to make such user interface. The most suitable variant for me was dear imgui, but now I'm replacing it by nuklear. Generally I have no complete solution to the problem, but I'd like to join efforts to create it.
Fast OpenGL-based visualization engine mainly for animated two-dimensional graphs
Is anybody working on a D-based really fast OpenGL-based visualization engine that supports tessellation of 2d primitives on the GPU? For instance, if I want to animate a huge amount of circles (in a 2d-graph) and I would like to only have to send an array of centers and radiuses and optionally colors, and transparencies to the GPU and then have the circles tessellated and rasterized there. I need this for visualizing and animating huge graphs (potentially millions of nodes) using the powers present in modern day GPUs. I'm interested in both pure-D implementations and wrappers over open-source C/C++ based implementations supported by Linux. Does a Vulkan-based implementation in D provide any benefits with regards to CPU-to-GPU-data-transfer and on-GPU-tesselation?
Cross compile windows programs on linux
Is in the subject. Are there any cross compilers that will run on a linux system but compile D code using Win32 into a windows .exe file, preferably 64 bit? I can find hints of cross compilers but not really seen anything packaged up?
Parallelizing factorial computation
I was messing and tried comparing the performance of different ways to compute the factorial of a number. Here's the benchmark results: recursive: 244 ms, 283 μs, and 2 hnsecs loop: 241 ms, 412 μs, and 3 hnsecs parallel: 1 sec, 784 ms, 829 μs, and 5 hnsecs https://run.dlang.io/is/uyVlqu I was quite surprised by the fact that parallel ran so much slower than recursive and loop implementations. Does anyone know why?
Re: Get max elemenr over RegexMatch
On 08/24/2018 01:13 PM, Andrey wrote: This code produces an error: auto matches = content.matchAll(pattern); auto max = matches.maxElement!"a => a.back.to!uint"(); You're mixing two different notations. It's either matches.maxElement!(a => a.back.to!uint)() or matches.maxElement!"a.back.to!uint"()
Get max elemenr over RegexMatch
Hello,
This code produces an error:
auto matches = content.matchAll(pattern);
auto max = matches.maxElement!"a => a.back.to!uint"();
I have a RegexMatch array like:
[["text1234", "1234"], ["zxs432fff", "432"], ["text000_",
"000"]]
Max element here is 1234.
I apply map function "a => a.back.to!uint" to each Capture ->
take last hit, convert it to uint and return for comparison.
But compiler says:
template std.algorithm.searching.extremum cannot deduce function
from argument types !("a => a.back.to!uint", "a >
b")(RegexMatch!(char[])), candidates are:
I can't understand what it wrong here.
This works:
matches.map!(a => a.back.to!uint)().maxElement()
I don't want to use this variant because, as I understand, here
we create a temporary uint array and then search for max element.
I.e. there is an unnecessary allocation of memory.
Re: how to build DSFMLC ?
On Sunday, 19 August 2018 at 08:57:05 UTC, Flaze07 wrote: I keep having the same problem with building DSFMLC https://ibb.co/edRStK for anyone having the same problem, I found the solution in another thread. You have to use MinGW32 bit version if you use mingw, as for visual C++, I think you can use both 32 bit and 64 bit
