Re: Dub project with .lib/.dlls for static binding
On Wednesday, 13 September 2017 at 22:50:54 UTC, Seb wrote: No you are not, it's just currently a bit painful to do manually due to e.g. missing support for git submodules. However, some projects already do this: Windows: https://github.com/ariovistus/pyd/blob/master/dub.json I was not aware that pyd does that, but it is very similar to what I'm saying. The difference would be to put the .lib files in a separate dub project. Instead of having the dub.json pointing to the location of the lib files within the pyd project, there would be a dependency on the lib project and a link to the files within that. I suppose there is no real reason why there needs to be a wrapper. This behavior can get added to D bindings. Regardless, I suppose the main motivation of not putting it in the bindings is that if someone is using the library on Linux, then they don't need to download any of the Windows lib files. The only change would be a small change to the dub.json to account for the different Windows behavior. And for Linux it's even possible to compile small dependencies on the fly: https://github.com/dlang-community/drepl/pull/63 I'm specifically interested in good support for Windows. Imho if the library is small, compiling it (or using prebuilt for Windows), should be the default behavior because it's a very pleasant user experience I'm 100% pro-"very pleasant user experience." The problem is that it usually isn't on Windows in this case. You often have to go find the library yourself and existing pre-built ones may not be in the right format (How were they compiled? MinGW or MSVC? What linker? Etc) so you have to go build it yourself. Deimos projects, for instance, are just C headers and D bindings. No .lib files.
Re: Inout table
On 9/13/17 3:04 PM, nkm1 wrote: Thank you. Now it is clear to me. The source of my confusion was that, say, given a function: inout(int*) foo(inout(int*) p) as per table, combining (mutable) argument int* m with parameter inout(int*) p would produce parameter type const(int*). But now I see that the table deduces the common type of all parameters, not the common type of a parameter and its argument (the documentation is kind of hard to parse: "If such a match occurs, the inout is considered the common qualifier of the matched qualifiers..."). Yeah, I should update that table and inout explanation... -Steve
Re: Is there any threadsafe queue?
On Wednesday, 13 September 2017 at 07:51:19 UTC, John Burton wrote: Is there any threadsafe queue in the standard library? I've not been able to find anything but thought I'd check before making my own. I want to be able to assemble messages (Which are just streams of bytes) in one thread into a struct and push them to the queue, and then have a another thread be able to read and process the messages. Single producer and consumer. Not sure what you are looking for, but a really cool topic are lock-free data structures. They are inherently thread-safe. One popular lib in D: https://code.dlang.org/packages/lock-free
Re: Dub project with .lib/.dlls for static binding
On Wednesday, 13 September 2017 at 19:55:03 UTC, jmh530 wrote: I'm not sure this makes much sense, but it's something that's been rolling around in my head the past 2-3 days. One of the great things about Python's Anaconda is that you just download one file, install and it just works. In D, dub offers comparable functionality as conda, which is very helpful. Usually it doesn't take much to get up and running with dub. This is especially true with projects that only use D code. However, things can get a little more complicated when a dub project in turn depends on some C library or something. I think this particularly applies to static binding. In my experience, it's usually far easier to deal with these sorts of issues with Linux than Windows. This additional difficulty likely would make it less likely that some Windows user would switch from Python to D. To reduce this difficulty, given some C library that already has D bindings available, I would start a separate dub project that just includes the .lib or .dlls necessary for Windows. Then, a wrapper (or more generally, any library that uses the bindings) could then have a dub sub-configuration such that Windows requires the previous dub project and uses it for dll/libs (also including a switch that would allow the user to put the path to them manually). This way the user could download the D binding themselves and do things manually, or they could use the wrapper and have a "just works" experience on Windows (with the option for manual customization). Am I making sense here? Anything I haven't thought of? No you are not, it's just currently a bit painful to do manually due to e.g. missing support for git submodules. However, some projects already do this: Windows: https://github.com/ariovistus/pyd/blob/master/dub.json And for Linux it's even possible to compile small dependencies on the fly: https://github.com/dlang-community/drepl/pull/63 Imho if the library is small, compiling it (or using prebuilt for Windows), should be the default behavior because it's a very pleasant user experience
Re: failed loading freetype 2.6 via derelict-ft
On Wednesday, 13 September 2017 at 20:16:23 UTC, Igor wrote: Make sure dll is also 32bit if you are building 32bit app and your Visual Studio should have dumpbin utility which you can use to make sure the required symbols are properly exported: dumpbin /EXPORTS your.dll In that case, he'd have seen a SharedLibLoadException rather than a SymbolLoadException, and the error message would be something like "foo.dll is not a valid Windows DLL" or some such.
Re: failed loading freetype 2.6 via derelict-ft
On Wednesday, 13 September 2017 at 19:01:52 UTC, Spacen wrote: Hello, I am trying to resurect an old project, but can't get the freetype library loaded. I can't figgure out what to do it's been a while. I have just built the freetype 2.6 library with visual studio 2015. Any tips would be appreciated. dub build Performing "debug" build using dmd for x86. derelict-util 2.0.6: target for configuration "library" is up to date. derelict-ft 1.1.3: building configuration "library"... derelict-gl3 1.0.23: target for configuration "library" is up to date. derelict-sdl2 1.9.7: target for configuration "library" is up to date. gltest ~master: building configuration "application"... Linking... To force a rebuild of up-to-date targets, run again with --force. C:\>gltest.exe Exception: Failed to load symbol FT_Stream_OpenBzip2 from shared library Missing symbols usually mean a version mismatch. The latest DerelictFT requires FreeType 2.6 or later. It could also mean your shared library was compiled without bzip2 support. I'm on my phone right now else I'd check it myself, but if your library os up to date you can use derelict's selective loading mechanism to ignore missing symbols you don't need. http://derelictorg.github.io/loading/failure/
Re: failed loading freetype 2.6 via derelict-ft
On Wednesday, 13 September 2017 at 19:01:52 UTC, Spacen wrote: Hello, I am trying to resurect an old project, but can't get the freetype library loaded. I can't figgure out what to do it's been a while. I have just built the freetype 2.6 library with visual studio 2015. Any tips would be appreciated. dub build Performing "debug" build using dmd for x86. derelict-util 2.0.6: target for configuration "library" is up to date. derelict-ft 1.1.3: building configuration "library"... derelict-gl3 1.0.23: target for configuration "library" is up to date. derelict-sdl2 1.9.7: target for configuration "library" is up to date. gltest ~master: building configuration "application"... Linking... To force a rebuild of up-to-date targets, run again with --force. C:\>gltest.exe Exception: Failed to load symbol FT_Stream_OpenBzip2 from shared library freetype.dll Make sure dll is also 32bit if you are building 32bit app and your Visual Studio should have dumpbin utility which you can use to make sure the required symbols are properly exported: dumpbin /EXPORTS your.dll
Dub project with .lib/.dlls for static binding
I'm not sure this makes much sense, but it's something that's been rolling around in my head the past 2-3 days. One of the great things about Python's Anaconda is that you just download one file, install and it just works. In D, dub offers comparable functionality as conda, which is very helpful. Usually it doesn't take much to get up and running with dub. This is especially true with projects that only use D code. However, things can get a little more complicated when a dub project in turn depends on some C library or something. I think this particularly applies to static binding. In my experience, it's usually far easier to deal with these sorts of issues with Linux than Windows. This additional difficulty likely would make it less likely that some Windows user would switch from Python to D. To reduce this difficulty, given some C library that already has D bindings available, I would start a separate dub project that just includes the .lib or .dlls necessary for Windows. Then, a wrapper (or more generally, any library that uses the bindings) could then have a dub sub-configuration such that Windows requires the previous dub project and uses it for dll/libs (also including a switch that would allow the user to put the path to them manually). This way the user could download the D binding themselves and do things manually, or they could use the wrapper and have a "just works" experience on Windows (with the option for manual customization). Am I making sense here? Anything I haven't thought of?
Re: Inout table
On Wednesday, 13 September 2017 at 17:39:29 UTC, Steven Schveighoffer wrote: Correct. So given a function: inout(int*) foo(inout(int*)p1, inout(int*)p2) The table shows what inout is resolved as when calling the function. If you consider the column the mutability of p1, and the row the mutability of p2, then the value in the table represents the mutability of the return value. So for instance: int *m; const int *c; immutable int *i; inout int *w; auto v1 = foo(m, m); // typeof(v1) is int* auto v2 = foo(m, c); // typeof(v2) is const(int*) auto v3 = foo(i, m); // typeof(v3) is const(int*) auto v4 = foo(w, w); // typeof(v4) is inout(int*) auto v5 = foo(w, i); // typeof(v5) is inout(const(int *)) etc. Thank you. Now it is clear to me. The source of my confusion was that, say, given a function: inout(int*) foo(inout(int*) p) as per table, combining (mutable) argument int* m with parameter inout(int*) p would produce parameter type const(int*). But now I see that the table deduces the common type of all parameters, not the common type of a parameter and its argument (the documentation is kind of hard to parse: "If such a match occurs, the inout is considered the common qualifier of the matched qualifiers...").
failed loading freetype 2.6 via derelict-ft
Hello, I am trying to resurect an old project, but can't get the freetype library loaded. I can't figgure out what to do it's been a while. I have just built the freetype 2.6 library with visual studio 2015. Any tips would be appreciated. dub build Performing "debug" build using dmd for x86. derelict-util 2.0.6: target for configuration "library" is up to date. derelict-ft 1.1.3: building configuration "library"... derelict-gl3 1.0.23: target for configuration "library" is up to date. derelict-sdl2 1.9.7: target for configuration "library" is up to date. gltest ~master: building configuration "application"... Linking... To force a rebuild of up-to-date targets, run again with --force. C:\>gltest.exe Exception: Failed to load symbol FT_Stream_OpenBzip2 from shared library freetype.dll
Re: Inout table
On 9/8/17 10:00 PM, nkm1 wrote:
There is this little table in
https://dlang.org/spec/function.html#inout-functions:
Common qualifier of the two type qualifiers
mutable const immutable inout inout const
mutable (= m) m c c c c
const (= c) c c c c c
immutable (= i) c c i wc wc
inout (= w) c c wc w wc
inout const (= wc) c c wc wc wc
I don't understand what it is trying to say. What is it that is
calculated here? The qualifier for the return value?
Correct. So given a function:
inout(int*) foo(inout(int*)p1, inout(int*)p2)
The table shows what inout is resolved as when calling the function.
If you consider the column the mutability of p1, and the row the
mutability of p2, then the value in the table represents the mutability
of the return value.
So for instance:
int *m;
const int *c;
immutable int *i;
inout int *w;
auto v1 = foo(m, m); // typeof(v1) is int*
auto v2 = foo(m, c); // typeof(v2) is const(int*)
auto v3 = foo(i, m); // typeof(v3) is const(int*)
auto v4 = foo(w, w); // typeof(v4) is inout(int*)
auto v5 = foo(w, i); // typeof(v5) is inout(const(int *))
etc.
And what's an "inout const"?
inout(const(T)) resolves to either immutable or const, depending on what
inout ultimately resolves to.
In other words, if inout is:
mutable -> /*mutable*/(const(T)) // note no keyword for mutable, so it's
just const(T)
const -> const(const(T)) -> const(T)
immutable -> immutable(const(T)) -> immutable(T)
It was discovered that this extra mechanism has benefits (namely you can
combine immutable data with inout data), so it now has it's own special
place while using inout.
A use case might be returning a sentinel value from a function:
class Foo {}
immutable sentinel = new Foo;
inout(const(Foo)) foo(inout(Foo) f) { return someCond? sentinel : f; }
Whenever an immutable Foo is passed in as f, then the result will be
immutable. Otherwise, it's const.
-Steve
Re: DerelictGL3 slow compilation speed with contexts
On Wednesday, 13 September 2017 at 13:25:01 UTC, Mike Parker wrote: On Wednesday, 13 September 2017 at 10:28:26 UTC, Igor wrote: Well since minimal example is a window app that opens a window, sets everything up and calls opengl stuff I will just push it to my github project this evening and you will can try with that. I will let you know when its done. In the meantime I can tell you that it seems that the main culprit for long compile time is "-inline" compiler option. In that case, I should be able to reproduce it. I've not compiled the context stuff with -inline before. Once I do reproduce it, I'll open an issue over github for future discussion. I'll let you know if I need more info. I tested it again with my entire project and it seems it is not inline thing but -O (optimized build). You can checkout the project here: https://github.com/igor84/dngin if you try to build it with "dub build -ax86_64 -b release" you will experience very long compilation.
Re: Assertion Error
On Wednesday, 13 September 2017 at 15:12:57 UTC, Vino.B wrote:
On Wednesday, 13 September 2017 at 11:03:38 UTC, Moritz
Maxeiner wrote:
On Wednesday, 13 September 2017 at 07:39:46 UTC, Vino.B wrote:
Hi Max,
[...]
Program Code:
[...]
foreach (string Fs; parallel(SizeDirlst[0 .. $], 1))
{
auto FFs = Fs.strip;
auto MSizeDirList = task(&coSizeDirList, FFs, SizeDir);
MSizeDirList.executeInNewThread();
auto MSizeDirListData = MSizeDirList.workForce;
MSresult.get ~= MSizeDirListData;
}
[...]
---
foreach (string Fs; parallel(SizeDirlst[0 .. $], 1))
{
MSresult.get ~= coSizeDirList(Fs.strip, SizeDir);
}
---
Hi Max,
It's Moritz, not Max. ;)
Below is the explanation of the above code.
[...]
AFAICT that's a reason why you want parallelization of
coSizeDirList, but not why you need to spawn another thread
inside of an *already parallelelized" task. Try my shortened
parallel foreach loop vs your longer one and monitor system load
(threads, memory, etc).
Re: Assertion Error
On Wednesday, 13 September 2017 at 11:03:38 UTC, Moritz Maxeiner
wrote:
On Wednesday, 13 September 2017 at 07:39:46 UTC, Vino.B wrote:
On Tuesday, 12 September 2017 at 21:01:26 UTC, Moritz Maxeiner
wrote:
On Tuesday, 12 September 2017 at 19:44:19 UTC, vino wrote:
Hi All,
I have a small piece of code which executes perfectly 8 out
of 10 times, very rarely it throws an assertion error, so is
there a way to find which line of code is causing this error.
You should be getting the line number as part of the crash,
like here:
--- test.d ---
void main(string[] args)
{
assert(args.length > 1);
}
--
-
$ dmd -run test.d
core.exception.AssertError@test.d(3): Assertion failure
[Stack trace]
-
If you don't what are the steps to reproduce?
Hi Max,
I tried to run the code for at least 80+ time the code ran
without any issue, will let you know in case if I hit the same
issue in feature, Below is the piece of code, plese do let me
know if you find any issue with the below code.
Program Code:
[...]
foreach (string Fs; parallel(SizeDirlst[0 .. $], 1))
{
auto FFs = Fs.strip;
auto MSizeDirList = task(&coSizeDirList, FFs, SizeDir);
MSizeDirList.executeInNewThread();
auto MSizeDirListData = MSizeDirList.workForce;
MSresult.get ~= MSizeDirListData;
}
From reading I don't see anything that I would expect to
assert, but I am wondering why you first parallelize your work
with a thread pool (`parallel(...)`) and then inside each
(implicitly created) task (that is already being serviced by a
thread in the thread pool) you create another task, have it
executed in a new thread, and make the thread pool thread wait
for that thread to complete servicing that new task.
This should yield the same result, but without the overhead of
spawning additional threads:
---
foreach (string Fs; parallel(SizeDirlst[0 .. $], 1))
{
MSresult.get ~= coSizeDirList(Fs.strip, SizeDir);
}
---
Hi Max,
Below is the explanation of the above code.
The Fs that is passed to the function ptSizeDirList is any array
of 10 -15 file system (NetApp Filers)from 15 different servers
mounted on a single server (Network share).
The function ptSizeDirList pass each of the FS to the function
coSizeDirList in parallel thread to find the folder size under
each of these Fs,
Each of this FS has around 1000+ folders. so the requirement is
that we need the size of each of the folders under each of these
15 Fs along with the folder name in less than an hour or two as
this script is about to be schedule to run once every 3 hours,
and at present we are able to achieve the same in 10 mins / fs
Each Fs is of about 10-15 TB's
Hence this code was written.
Is there further documentation of core.atomic.MemoryOrder?
Is there a formal description of "hoist-load", "hoist-store", "sink-load", and "sink-store" as used in core.atomic.MemoryOrder (https://dlang.org/library/core/atomic/memory_order.html)?
Re: DerelictGL3 slow compilation speed with contexts
On Wednesday, 13 September 2017 at 10:28:26 UTC, Igor wrote: Well since minimal example is a window app that opens a window, sets everything up and calls opengl stuff I will just push it to my github project this evening and you will can try with that. I will let you know when its done. In the meantime I can tell you that it seems that the main culprit for long compile time is "-inline" compiler option. In that case, I should be able to reproduce it. I've not compiled the context stuff with -inline before. Once I do reproduce it, I'll open an issue over github for future discussion. I'll let you know if I need more info.
Re: Assertion Error
On Wednesday, 13 September 2017 at 07:39:46 UTC, Vino.B wrote:
On Tuesday, 12 September 2017 at 21:01:26 UTC, Moritz Maxeiner
wrote:
On Tuesday, 12 September 2017 at 19:44:19 UTC, vino wrote:
Hi All,
I have a small piece of code which executes perfectly 8 out
of 10 times, very rarely it throws an assertion error, so is
there a way to find which line of code is causing this error.
You should be getting the line number as part of the crash,
like here:
--- test.d ---
void main(string[] args)
{
assert(args.length > 1);
}
--
-
$ dmd -run test.d
core.exception.AssertError@test.d(3): Assertion failure
[Stack trace]
-
If you don't what are the steps to reproduce?
Hi Max,
I tried to run the code for at least 80+ time the code ran
without any issue, will let you know in case if I hit the same
issue in feature, Below is the piece of code, plese do let me
know if you find any issue with the below code.
Program Code:
[...]
foreach (string Fs; parallel(SizeDirlst[0 .. $], 1))
{
auto FFs = Fs.strip;
auto MSizeDirList = task(&coSizeDirList, FFs, SizeDir);
MSizeDirList.executeInNewThread();
auto MSizeDirListData = MSizeDirList.workForce;
MSresult.get ~= MSizeDirListData;
}
From reading I don't see anything that I would expect to assert,
but I am wondering why you first parallelize your work with a
thread pool (`parallel(...)`) and then inside each (implicitly
created) task (that is already being serviced by a thread in the
thread pool) you create another task, have it executed in a new
thread, and make the thread pool thread wait for that thread to
complete servicing that new task.
This should yield the same result, but without the overhead of
spawning additional threads:
---
foreach (string Fs; parallel(SizeDirlst[0 .. $], 1))
{
MSresult.get ~= coSizeDirList(Fs.strip, SizeDir);
}
---
Re: DerelictGL3 slow compilation speed with contexts
On Wednesday, 13 September 2017 at 01:30:10 UTC, Mike Parker wrote: On Tuesday, 12 September 2017 at 21:55:23 UTC, Igor wrote: Hi All, I switched from using free functions in DerelictGL3 to DerelictGL3_Contexts and compilation speed in optimized build using DMD went from 2 seconds to 7 minutes and using LDC from 2 seconds to 10 seconds. Is this a known problem? Are there any workarounds? The support for contexts is still relatively new and I've received no feedback specific to it since I first released it in the 2.0 alpha. Given the heavy use of string & template mixins, it's possible I'm hitting a corner case somewhere. In my simple tests, I haven't seen it. So the only way I'm going to be able to narrow it down is with a minimal example that I can compile and test with. Is there anything you can give me? Well since minimal example is a window app that opens a window, sets everything up and calls opengl stuff I will just push it to my github project this evening and you will can try with that. I will let you know when its done. In the meantime I can tell you that it seems that the main culprit for long compile time is "-inline" compiler option.
Re: Is there any threadsafe queue?
On Wednesday, 13 September 2017 at 09:49:46 UTC, Jonathan M Davis wrote: On Wednesday, September 13, 2017 07:51:19 John Burton via Digitalmars-d- learn wrote: [...] You could probably do what you want with std.concurrency, since most of what it does is deal with sending and receiving data across threads, and that should be queuing up messages as part of what it does. But if you're looking for a data structure that you can mark as shared and have it handle all of the locking for you so that it will work safely across threads, then no, the standard library does not currently have anything like that. It's rather lacking in containers in general at this point, let alone ones designed with concurrency in mind. There may be something on code.dlang.org, but I don't know. Regardless, I'd suggest that you first try and see if you can get std.concurrency to work for your use case rather than jumping into implementing any containers yourself. Thanks, I took a better look. I was wanting to port some c++ code which is why I was looking for this. Actually it looks like "send" and "receive" functions from this package do exactly what I need (and are in fact exactly a thread safe queue...) :)
Re: Is there any threadsafe queue?
On Wednesday, September 13, 2017 07:51:19 John Burton via Digitalmars-d- learn wrote: > Is there any threadsafe queue in the standard library? > I've not been able to find anything but thought I'd check before > making my own. > > I want to be able to assemble messages (Which are just streams of > bytes) in one thread into a struct and push them to the queue, > and then have a another thread be able to read and process the > messages. Single producer and consumer. You could probably do what you want with std.concurrency, since most of what it does is deal with sending and receiving data across threads, and that should be queuing up messages as part of what it does. But if you're looking for a data structure that you can mark as shared and have it handle all of the locking for you so that it will work safely across threads, then no, the standard library does not currently have anything like that. It's rather lacking in containers in general at this point, let alone ones designed with concurrency in mind. There may be something on code.dlang.org, but I don't know. Regardless, I'd suggest that you first try and see if you can get std.concurrency to work for your use case rather than jumping into implementing any containers yourself. - Jonathan M Davis
Re: Adding empty static this() causes exception
On Tuesday, 12 September 2017 at 19:59:52 UTC, Joseph wrote: The compiler shouldn't arbitrarily force one to make arbitrary decisions that waste time and money. Like having a type system? Having to do *cast(int*)&s to interpret a string as an int isn't strictly necessary, and wastes dev time when they have to type extra letters. Throwing an exception when there are import cycles that may cause problems is absolutely the correct thing to do. It's a choice between hard-to-figure-out errors that may depend on the order in which files were passed to the linker, and getting an exception before you've even started running your tests. If we could get this message at compile-time, that would of course be better, but that cannot be done in the general case due to separate compilation. If you want such a message in the cases where it is possible, feel free to create a pull request. It would be possible to add a way to say 'ignore cycles for this module ctor', but as has been pointed out, cycles are generally a symptom of poor architecture, are brittle, and can almost always be avoided (and when they can't, there's a way around that too). -- Biotronic
Is there any threadsafe queue?
Is there any threadsafe queue in the standard library? I've not been able to find anything but thought I'd check before making my own. I want to be able to assemble messages (Which are just streams of bytes) in one thread into a struct and push them to the queue, and then have a another thread be able to read and process the messages. Single producer and consumer.
Re: Assertion Error
On Tuesday, 12 September 2017 at 21:01:26 UTC, Moritz Maxeiner
wrote:
On Tuesday, 12 September 2017 at 19:44:19 UTC, vino wrote:
Hi All,
I have a small piece of code which executes perfectly 8 out of
10 times, very rarely it throws an assertion error, so is
there a way to find which line of code is causing this error.
You should be getting the line number as part of the crash,
like here:
--- test.d ---
void main(string[] args)
{
assert(args.length > 1);
}
--
-
$ dmd -run test.d
core.exception.AssertError@test.d(3): Assertion failure
[Stack trace]
-
If you don't what are the steps to reproduce?
Hi Max,
I tried to run the code for at least 80+ time the code ran
without any issue, will let you know in case if I hit the same
issue in feature, Below is the piece of code, plese do let me
know if you find any issue with the below code.
Program Code:
import core.stdc.stdlib: exit;
import std.algorithm: all, among, filter, map, setDifference,
sort, uniq, each, joiner;
import std.array: appender, join;
import std.container.array;
import std.conv: to;
import std.datetime.systime: Clock, days, SysTime;
import std.file: SpanMode, dirEntries, exists, isFile, mkdir,
remove, rmdirRecurse;
import std.getopt;
import std.parallelism: parallel, task, taskPool;
import std.path: absolutePath, baseName, dirName,
isValidFilename, isValidPath, globMatch;
import std.range: empty, zip, chain, chunks;
import std.stdio: File, writefln, writeln;
import std.string: chomp, chop, isNumeric, split, strip;
import std.typecons: tuple, Tuple;
import std.uni: isAlpha, toLower, isWhite;
import std.conv;
auto coSizeDirList (string FFs, int SizeDir) {
int subdirTotal;
int subdirTotalGB;
Array!string Subdir;
Array!string Subsize;
Array!string Result;
auto dFiles = Array!string ((dirEntries(FFs,
SpanMode.shallow).filter!(a => a.isDir))[].map!(a => a.name));
foreach (d; dFiles[]) {
auto SdFiles = Array!ulong(dirEntries(d,
SpanMode.depth).map!(a => a.size));
foreach(f; SdFiles[]) { subdirTotal += f; }
subdirTotalGB = (subdirTotal/1024/1024);
if (subdirTotalGB > SizeDir) { Result ~= d; Result ~=
to!string(subdirTotalGB); }
subdirTotal = 0;
}
return Result;
}
void ptSizeDirList (Array!string SizeDirlst, int SizeDir) {
alias DirSizeList = typeof(coSizeDirList(string.init, int.init));
auto MSresult = taskPool.workerLocalStorage!DirSizeList();
foreach (string Fs; parallel(SizeDirlst[0 .. $], 1)) {
auto FFs = Fs.strip;
auto MSizeDirList = task(&coSizeDirList, FFs, SizeDir);
MSizeDirList.executeInNewThread();
auto MSizeDirListData = MSizeDirList.workForce;
MSresult.get ~= MSizeDirListData;
}
foreach(i; MSresult.toRange)
chain(i[]).chunks(2).each!(e => writefln!"%-60s %s"(e[0],
e[1]));
}
void main () {
auto SizeDirlst = Array!string( "C:\\Temp\\TEST2\\BACKUP",
"C:\\Temp\\TEST2\\EXPORT", "C:\\Temp\\TEST2\\PROD_TEAM",
"C:\\Temp\\TEST2\\TEAM", "C:\\Temp\\TEST3\\BACKUP",
"C:\\Temp\\TEST3\\EXPORT" );
int SizeDir = 10;
ptSizeDirList(SizeDirlst, SizeDir);
}
From,
Vino.B
