Re: std.algorithm.canFind behavior difference between arrays and elements
On Friday, 7 December 2018 at 20:28:37 UTC, Seb wrote: On Friday, 7 December 2018 at 19:38:29 UTC, Arun Chandrasekaran wrote: On Friday, 7 December 2018 at 19:12:31 UTC, Seb wrote: On Friday, 7 December 2018 at 18:51:27 UTC, Arun Chandrasekaran wrote: [...] Alternatively to the answers above you can also use a custom lambda for canFind: https://run.dlang.io/is/QOXYbe Just curious, how do we find multiple needles? This throws compilation error assert(hay.canFind!(e => (e.canFind(["111", "222"]; An example in the doc would be helpful. It's variadic: https://run.dlang.io/is/AKkKA9 Please feel free to add an example to the docs. Sure, here it is https://github.com/dlang/phobos/pull/6796
Re: Working with ranges
On Saturday, 8 December 2018 at 04:16:25 UTC, Adam D. Ruppe wrote: On Saturday, 8 December 2018 at 04:11:03 UTC, Murilo wrote: What is the difference between declaring "int[3] a = [1,2,3];" and declaring "int[] a = [1,2,3];"? Is the first an array and the second a range? They are both arrays, just the former one has a fixed size and the latter does not. Ranges require a way to iterate and consume elements, meaning they cannot be fixed size. I always thought that leaving the square brackets empty would create an array of flexible size, it never occurred to me that it was creating something else. That's what it is, just a flexible array also happens to be an array, whereas a fixed-size array is not one. But a slice of a fixed size one yields a flexible one.. which is why the ps[] thing works to create a range out of it. Thank you guys so much for the explanation, it is all making more sense now.
Re: Working with ranges
On Saturday, 8 December 2018 at 04:11:03 UTC, Murilo wrote: What is the difference between declaring "int[3] a = [1,2,3];" and declaring "int[] a = [1,2,3];"? Is the first an array and the second a range? They are both arrays, just the former one has a fixed size and the latter does not. Ranges require a way to iterate and consume elements, meaning they cannot be fixed size. I always thought that leaving the square brackets empty would create an array of flexible size, it never occurred to me that it was creating something else. That's what it is, just a flexible array also happens to be an array, whereas a fixed-size array is not one. But a slice of a fixed size one yields a flexible one.. which is why the ps[] thing works to create a range out of it.
Re: Working with ranges
On Saturday, 8 December 2018 at 03:51:02 UTC, Adam D. Ruppe wrote: On Saturday, 8 December 2018 at 03:48:10 UTC, Murilo wrote: Try passing `ps[]` to the function instead of plain `ps` and see what happens. How do I transform an array into a range? With the slicing operator, []. Thank you very much, it worked now. What is the difference between declaring "int[3] a = [1,2,3];" and declaring "int[] a = [1,2,3];"? Is the first an array and the second a range? I always thought that leaving the square brackets empty would create an array of flexible size, it never occurred to me that it was creating something else.
Re: Working with ranges
On Friday, December 7, 2018 8:46:11 PM MST Adam D. Ruppe via Digitalmars-d- learn wrote: > On Saturday, 8 December 2018 at 03:37:56 UTC, Murilo wrote: > > Hi guys, I have created an array of strings with "string[12] ps > > string[12] isn't a range, but string[] is. > > Try passing `ps[]` to the function instead of plain `ps` and see > what happens. Specifically, the problem is that static arrays have a fixed length, which means that you can't pop elements off as is required for ranges. Dynamic arrays on the other hand are ranges (at least as long as you import std.range.primitives to get the range functions for dynamic arrays). Slicing a static array gives you a dynamic array which is a slice of the static array. So, mutating the elements of the dynamic array will mutate the elements of the static array, but the dynamic array can have elements popped off as is required for ranges, whereas the static array can't. - Jonathan M Davis
Re: Working with ranges
On Saturday, 8 December 2018 at 03:48:10 UTC, Murilo wrote: Try passing `ps[]` to the function instead of plain `ps` and see what happens. How do I transform an array into a range? With the slicing operator, [].
Re: Working with ranges
On Saturday, 8 December 2018 at 03:37:56 UTC, Murilo wrote: Hi guys, I have created an array of strings with "string[12] ps string[12] isn't a range, but string[] is. Try passing `ps[]` to the function instead of plain `ps` and see what happens.
Re: Working with ranges
On Saturday, 8 December 2018 at 03:46:11 UTC, Adam D. Ruppe wrote: On Saturday, 8 December 2018 at 03:37:56 UTC, Murilo wrote: Hi guys, I have created an array of strings with "string[12] ps string[12] isn't a range, but string[] is. Try passing `ps[]` to the function instead of plain `ps` and see what happens. How do I transform an array into a range?
Working with ranges
Hi guys, I have created an array of strings with "string[12] ps = ["cat", "dog", "lion", "wolf", "coin", "chest", "money", "gold", "A", "B", "C", "D"];". I want to use the array as a range and I want to randomize it, like I want to transform that into several other ranges with the same elements but in different orders, how do I do that? I tried using the function choice() from std.random but it gives an error message for some reason.
Re: Writing Program Without main Function
On Friday, December 7, 2018 2:42:33 PM MST Samir via Digitalmars-d-learn wrote: > Ok. Upon further investigation, I think I see what is going on. > Most of the repos I am skimming are for this year's Advent of > Code. They structure their repo with an `app.d` file which does > contain a `main` function but this program is structured such > that it imports the files I was looking at earlier (which do not > have a `main` function). > > Looks like I have to get smarter on how modules, mixins and > imports work. There's one main per program, not per module. Where main lives depends on how the program was written, but dub encourages putting it in app.d, because that's what it generates when you create a new dub project. imports then provide access to other modules so that the code doing the importing can use it. You can think of it like the module with main being the start of the import tree, though it's a bit more complicated than that in practice, since modules can be compiled separately, and main only has to be there when the program is finally linked. But in concept, you have main and the module its in importing other modules, which then import other modules, etc. until you get all of the code in the program. - Jonathan M Davis
Re: Writing Program Without main Function
Ok. Upon further investigation, I think I see what is going on. Most of the repos I am skimming are for this year's Advent of Code. They structure their repo with an `app.d` file which does contain a `main` function but this program is structured such that it imports the files I was looking at earlier (which do not have a `main` function). Looks like I have to get smarter on how modules, mixins and imports work.
Re: Writing Program Without main Function
On Friday, December 7, 2018 2:02:59 PM MST Samir via Digitalmars-d-learn
wrote:
> Is it possible to write and execute a D program without a main
> function?
>
> Most of my programs will start with some `import` statements,
> followed by any functions and then ending with the `main`
> function (e.g. `void main() {`).
>
> As I am just a beginner to programming and still new to D, I have
> been browsing some repositories that people have posted here to
> learn more about the language and how more experienced
> programmers write their code. In many of these examples, they
> start with the `module` statement followed by their `import`
> statements and then will have sections defining various classes,
> structs, unit tests and other bits but I never see a `main`
> function.
>
> How do you compile and execute these programs?
The short answer is that every program must have a main function.
The long answer:
main is the entry point into the program. You can't do much without it, and
the linker will require that it exists. static constructors do get run
before main, and static destructors get run after it, so it is possible to
run code before and after main, but they're only intended for more complex
initialization and destruction of module-level and static variables. Really,
when it comes down to it, main _is_ your program, and there must be a main
function one way or another. That's true of pretty much any programming
language. Some may present main in a different way, but ultimately, every
programming language has some form of main, because every program needs an
entry point.
dmd provides the -main flag which will insert an empty main, so you could
use that, but it's really only of any use for unit testing (since in D,
unittest blocks are run before main). For an actual program, you basically
don't have anything without main. Essentially what you get in D is
1. Run static constructors.
2. If -unittest was used, run the unittest blocks (though since that's only
intended for testing, it really shouldn't be in a production program).
3. Run main.
4. Run static destructors.
And for simpler programs, you basically have
1. Run main.
None of your stray functions or classes are going to be used just because
you declared them. It's main that decides what's going to be run, even if
it's just to call another function. All of those other functions and classes
are just a way to organize your program, make pieces reusable, etc.
Ultimately, the main function is your program, so it really doesn't make
sense to try to not have one.
The closest thing that exists to a program with no main is a library, and
libraries are just collections of functions and user-defined types which are
packaged together so that programs can use them. They aren't programs on
their own, just pieces of reusable code. Ultimately, you need an actual
program with a main to use them.
When you see code snippets that don't use main, it's because they're usually
just that - code snippets. They're showing a piece of code, not an entire
program. It's just assumed that anyone who wants to actually run them is
going to deal with declaring main themselves, because everyone knows that
you need a main function. As such, including main is often just extraneous
information.
- Jonathan M Davis
Re: Writing Program Without main Function
There is always a main function. It doesn't matter in which module its in or language. It just has to exist.
Writing Program Without main Function
Is it possible to write and execute a D program without a main
function?
Most of my programs will start with some `import` statements,
followed by any functions and then ending with the `main`
function (e.g. `void main() {`).
As I am just a beginner to programming and still new to D, I have
been browsing some repositories that people have posted here to
learn more about the language and how more experienced
programmers write their code. In many of these examples, they
start with the `module` statement followed by their `import`
statements and then will have sections defining various classes,
structs, unit tests and other bits but I never see a `main`
function.
How do you compile and execute these programs?
Thanks
Samir
Re: Imports and Subfolders and Links (Oh, My!)
So, the upshot of it all seems to be that the -i's have it.
Re: std.algorithm.canFind behavior difference between arrays and elements
On Friday, 7 December 2018 at 19:38:29 UTC, Arun Chandrasekaran wrote: On Friday, 7 December 2018 at 19:12:31 UTC, Seb wrote: On Friday, 7 December 2018 at 18:51:27 UTC, Arun Chandrasekaran wrote: [...] Alternatively to the answers above you can also use a custom lambda for canFind: https://run.dlang.io/is/QOXYbe Just curious, how do we find multiple needles? This throws compilation error assert(hay.canFind!(e => (e.canFind(["111", "222"]; An example in the doc would be helpful. It's variadic: https://run.dlang.io/is/AKkKA9 Please feel free to add an example to the docs.
Re: std.algorithm.canFind behavior difference between arrays and elements
On 12/7/18 2:38 PM, Arun Chandrasekaran wrote:
On Friday, 7 December 2018 at 19:12:31 UTC, Seb wrote:
On Friday, 7 December 2018 at 18:51:27 UTC, Arun Chandrasekaran wrote:
I'm trying to find the needle in the hay that's an array of strings.
So the second assert fails for some reason. Is this expected?
https://run.dlang.io/is/7OrZTA
```
#!/usr/bin/rdmd
void main()
{
import std.experimental.all;
string s1 = "aaa111aaa";
string s2 = "aaa222aaa";
string s3 = "aaa333aaa";
string s4 = "aaa444aaa";
const hay = [s1, s2, s3, s4];
assert(canFind(s1, "111"));
assert(canFind(hay, "111"));
}
```
Why is there a difference in the behavior?
Alternatively to the answers above you can also use a custom lambda
for canFind:
https://run.dlang.io/is/QOXYbe
Just curious, how do we find multiple needles? This throws compilation
error
assert(hay.canFind!(e => (e.canFind(["111", "222"];
Almost, you have extra braces:
assert(hay.canFind!(e => (e.canFind( "111", "222" ;
In other words, when searching for extra needles, each needle is a new
parameter to find/canFind.
-Steve
Re: Imports and Subfolders and Links (Oh, My!)
On Fri, Dec 07, 2018 at 07:01:18PM +, Adam D. Ruppe via Digitalmars-d-learn wrote: > On Friday, 7 December 2018 at 17:41:47 UTC, Ron Tarrant wrote: [...] > > when I compile rather than compiling modules over and over > > needlessly. > > Oh, lots of us compile everything at once. It works quite well and is > fast for many applications that you don't need to do anything more. Yes, the D compiler is fast enough that for a small project, recompiling everything vs. compile a single source file doesn't make a noticeable difference in compilation time. For larger projects, the general recommendation is to use the package as your unit of recompilation, i.e., if you have your source tree structure like this: package1/ package1/mod1.d package1/mod2.d package2/ package2/mod1.d package2/mod2.d then when you recompile, if package1/* hasn't been touched, but package2/mod2.d was changed, then recompile package2/* into a static library, and relink your application. The above example is greatly simplified, of course; generally, your package subdirs would have 10+ source files or so before this sort of per-package recompilation actually benefits compilation times. In some of my projects, where package subdirs are relatively small, I just lump the source files inside together with everything else and just recompile the whole thing at once. IME, separately recompiling individual .d files generally slows down compilation rather than speed it up -- the linker has more work to do to resolve cross-references that the compiler would have statically resolved had you passed all source files at once instead. > > Does D have the concept of makefiles? I haven't run across any > > reference to such things so far. > > Yes, you can use a makefile with D basically the same as with C. But > you may find it actually builds slower than just dmd -i main.d This is true for most small to medium-sized projects. For larger projects, it does help to compile different packages separately (perhaps in parallel if your build system supports that). In my own projects, I actually use my build system more to resolve other complex tasks than to individually compile D source files; I'd just specify what amounts to `dmd *.d` in a single build rule, and most of the rest of the build script is to handle other tasks, like generating code from input data, preprocessing resource files, building/signing packages, compiling code in other languages (Java, C, etc.), installation to the staging area for testing, etc.. So ironically, most of my build rules concern stuff other than compilation. :-D T -- Stop staring at me like that! It's offens... no, you'll hurt your eyes!
Re: std.algorithm.canFind behavior difference between arrays and elements
On Friday, 7 December 2018 at 19:12:31 UTC, Seb wrote:
On Friday, 7 December 2018 at 18:51:27 UTC, Arun Chandrasekaran
wrote:
I'm trying to find the needle in the hay that's an array of
strings. So the second assert fails for some reason. Is this
expected? https://run.dlang.io/is/7OrZTA
```
#!/usr/bin/rdmd
void main()
{
import std.experimental.all;
string s1 = "aaa111aaa";
string s2 = "aaa222aaa";
string s3 = "aaa333aaa";
string s4 = "aaa444aaa";
const hay = [s1, s2, s3, s4];
assert(canFind(s1, "111"));
assert(canFind(hay, "111"));
}
```
Why is there a difference in the behavior?
Alternatively to the answers above you can also use a custom
lambda for canFind:
https://run.dlang.io/is/QOXYbe
Just curious, how do we find multiple needles? This throws
compilation error
assert(hay.canFind!(e => (e.canFind(["111", "222"];
An example in the doc would be helpful.
Re: std.algorithm.canFind behavior difference between arrays and elements
On Friday, 7 December 2018 at 19:12:31 UTC, Seb wrote:
On Friday, 7 December 2018 at 18:51:27 UTC, Arun Chandrasekaran
wrote:
I'm trying to find the needle in the hay that's an array of
strings. So the second assert fails for some reason. Is this
expected? https://run.dlang.io/is/7OrZTA
```
#!/usr/bin/rdmd
void main()
{
import std.experimental.all;
string s1 = "aaa111aaa";
string s2 = "aaa222aaa";
string s3 = "aaa333aaa";
string s4 = "aaa444aaa";
const hay = [s1, s2, s3, s4];
assert(canFind(s1, "111"));
assert(canFind(hay, "111"));
}
```
Why is there a difference in the behavior?
Alternatively to the answers above you can also use a custom
lambda for canFind:
https://run.dlang.io/is/QOXYbe
That's elegant!
Re: std.algorithm.canFind behavior difference between arrays and elements
On Friday, 7 December 2018 at 18:51:27 UTC, Arun Chandrasekaran
wrote:
I'm trying to find the needle in the hay that's an array of
strings. So the second assert fails for some reason. Is this
expected? https://run.dlang.io/is/7OrZTA
```
#!/usr/bin/rdmd
void main()
{
import std.experimental.all;
string s1 = "aaa111aaa";
string s2 = "aaa222aaa";
string s3 = "aaa333aaa";
string s4 = "aaa444aaa";
const hay = [s1, s2, s3, s4];
assert(canFind(s1, "111"));
assert(canFind(hay, "111"));
}
```
Why is there a difference in the behavior?
Alternatively to the answers above you can also use a custom
lambda for canFind:
https://run.dlang.io/is/QOXYbe
Re: std.algorithm.canFind behavior difference between arrays and elements
On Friday, 7 December 2018 at 19:08:05 UTC, Arun Chandrasekaran wrote: On Friday, 7 December 2018 at 18:57:48 UTC, Dennis wrote: On Friday, 7 December 2018 at 18:51:27 UTC, Arun Chandrasekaran wrote: Why is there a difference in the behavior? Your first assert expression is looking for a string in a larger string, your second expression looks for hay which is not a string but a string[]. To flatten the array, use: assert(canFind(hay.join, "111")); This succeeds. assert(canFind(hay, "aaa222aaa")); So the difference in the behaviour is caused by canFind checking for equality when string[] is passed. Is this the expected behaviour? I wouldn't want to join the array, for the array could be really big. Actually, canFind documentation is perfect. https://dlang.org/phobos/std_algorithm_searching.html#.canFind assert( canFind!((string a, string b) => a.startsWith(b))(words, "bees")); Thanks for the help anyways!
Re: std.algorithm.canFind behavior difference between arrays and elements
On Friday, 7 December 2018 at 18:57:48 UTC, Dennis wrote: On Friday, 7 December 2018 at 18:51:27 UTC, Arun Chandrasekaran wrote: Why is there a difference in the behavior? Your first assert expression is looking for a string in a larger string, your second expression looks for hay which is not a string but a string[]. To flatten the array, use: assert(canFind(hay.join, "111")); This succeeds. assert(canFind(hay, "aaa222aaa")); So the difference in the behaviour is caused by canFind checking for equality when string[] is passed. Is this the expected behaviour? I wouldn't want to join the array, for the array could be really big.
Re: std.algorithm.canFind behavior difference between arrays and elements
On 12/7/18 1:57 PM, Dennis wrote:
On Friday, 7 December 2018 at 18:51:27 UTC, Arun Chandrasekaran wrote:
Why is there a difference in the behavior?
Your first assert expression is looking for a string in a larger string,
your second expression looks for hay which is not a string but a
string[]. To flatten the array, use:
assert(canFind(hay.join, "111"));
1. Use joiner, not join, as this creates a temporary array and
immediately throws it away (wasteful)
2. It's not exactly as simple as that, because it will find "111" that
spans 2 elements (unless that's what you want).
You'd probably want to use some kind of delimiter, like:
assert(canFind(hay.joiner("\0"), "111"));
-Steve
Re: Imports and Subfolders and Links (Oh, My!)
On Friday, 7 December 2018 at 17:41:47 UTC, Ron Tarrant wrote: Are you talking about a list of import statements here or is there another way/place I would list them? On the dmd command line. So say your program has a.d and b.d, you would compile with `dmd a.d b.d`. Or as you had some success with, the newer compilers let you just do `dmd -i a.d` and it finds the rest based on the import statements. I'm not sure what you mean by 'library' in this statement. For example, since you are using gtkd.lib, you don't have to include all of gtkd's source files. (The compiler needs to be able to FIND them, but you don't have to list them.) If you were using a makefile, you may only list one file at a time to compile each separately, then link together all the generate .obj files as a separate step. Just still trying to understand when it would be necessary to use a prefix and dot separator in an import statement. The most practical answer is "always". There's some exceptions that work for simple cases, but even then you put yourself at potential conflicts if some library author decided to pick the same name. So you are really better off just always using some prefix and always listing the full name. module myprojectname.mymodulename; at the top of every file in your source tree. (Or you can use more dots if you want to further subdivide it, like "myprojectname.helper.whatever.mymodulename"). And when importing it, always list the full name, exactly the same as you listed it in the module definition. import myprojectname.mymodulename; import myprojectname.helper.whatever.mymodulename; Every time you use it, from any location. Then it will work in all cases, whether compiling all at once (which I recommend btw), or using a makefile, or any other build system, even if you decide to bring in more libraries or your program grows beyond the super simple cases. You can organize the subfolders based on those dot names (or do the dot names based on the subfolders if that is existing) and that will ease the process a bit more. But regardless of the folder layout and file locations, always use the full names and be sure they match in module and import statements. when I compile rather than compiling modules over and over needlessly. Oh, lots of us compile everything at once. It works quite well and is fast for many applications that you don't need to do anything more. Does D have the concept of makefiles? I haven't run across any reference to such things so far. Yes, you can use a makefile with D basically the same as with C. But you may find it actually builds slower than just dmd -i main.d
Re: std.algorithm.canFind behavior difference between arrays and elements
On Friday, 7 December 2018 at 18:51:27 UTC, Arun Chandrasekaran wrote: Why is there a difference in the behavior? Your first assert expression is looking for a string in a larger string, your second expression looks for hay which is not a string but a string[]. To flatten the array, use: assert(canFind(hay.join, "111"));
std.algorithm.canFind behavior difference between arrays and elements
I'm trying to find the needle in the hay that's an array of
strings. So the second assert fails for some reason. Is this
expected? https://run.dlang.io/is/7OrZTA
```
#!/usr/bin/rdmd
void main()
{
import std.experimental.all;
string s1 = "aaa111aaa";
string s2 = "aaa222aaa";
string s3 = "aaa333aaa";
string s4 = "aaa444aaa";
const hay = [s1, s2, s3, s4];
assert(canFind(s1, "111"));
assert(canFind(hay, "111"));
}
```
Why is there a difference in the behavior?
Re: Imports and Subfolders and Links (Oh, My!)
On Sat, Dec 08, 2018 at 06:48:46AM +1300, rikki cattermole via Digitalmars-d-learn wrote: > On 08/12/2018 6:41 AM, Ron Tarrant wrote: > > Does D have the concept of makefiles? I haven't run across any > > reference to such things so far. > > Make isn't a D specification application (it doesn't really specialize > in any language) dmd, druntime and Phobos are all built using it. > > Though for user code, dub is the package+build manager that is more > commonly used. You can surely use Makefiles to compile your D code. DMD, druntime, and Phobos use Makefiles. :-D Though due to limitations with makefiles, I prefer to use SCons. I'd use dub as a package manager, but I find its limitations as a build manager too frustrating and a total deal-breaker for the kind of builds I need to do, so I generally avoid using it as such. T -- Prosperity breeds contempt, and poverty breeds consent. -- Suck.com
Code review - disjoint sets
Hello. Is code-review requests welcome in this forum? If so I
would like some criticisms and feedback for my disjoint sets
implementation. The code is as follows:
module dsets;
/// dsets is an implementation of disjoint sets. It is implemented
/// with a simple class. To construct it, you provide the maximum
node
/// number.
/// Limitation: CANNOT DISCONNECT TWO NODES
/// If the array is big enough, opt for parallel operations if
possible
immutable ulong minimumParallelArrayLength = 10_000;
public class DSets
{
private:
ulong[] ids, heights;
bool isRoot(const ulong n) const
{
return ids[n] == n;
}
public:
/// A `DSets(10)` would create a disjoint set of 0 to 10
/// inclusive.
this(in ulong maxN)
{
ids.reserve(maxN + 1);
heights.reserve(maxN + 1);
foreach (n; 0 .. maxN + 1)
{
ids ~= n;
heights ~= 0;
}
}
/// Returns the root id of a given node
ulong getRoot(in ulong n) const
{
ulong result = n;
while (ids[result] != result)
result = ids[ids[result]]; // path compression
return result;
}
/// Connect two nodes. Does not check membership so may throw
/// errors
void connect(in ulong n, in ulong m)
{
auto nRoot = getRoot(n), mRoot = getRoot(m);
if (nRoot != mRoot)
{
if (heights[nRoot] >= heights[mRoot])
{
ids[mRoot] = ids[nRoot];
heights[nRoot] += heights[mRoot];
}
else
{
ids[nRoot] = ids[mRoot];
heights[mRoot] += heights[nRoot];
}
}
}
/// Check if two given nodes are connected.
bool connected(in ulong n, in ulong m) const
{
return getRoot(n) == getRoot(m);
}
/// Returns the number of nodes in the set
ulong length() const @safe
{
return ids.length;
}
/// Add a node
void grow(in ulong nodes = 0)
{
auto toAdd = ids[$ - 1];
foreach (_; 0 .. nodes + 1)
{
ids ~= toAdd++;
heights ~= 0;
}
}
/// Get an array of roots
ulong[] getRoots() const
{
if (ids.length == 0)
return [];
// D does not have a standard hash-set. The
// workaround is to use a hash-table
bool[ulong] roots;
// premature optimization, if the array is not huge,
// do not opt for multithreaded operation
if (ids.length < 10_000)
{
foreach (i, id; ids)
if (ids[i] == i)
if (!(i in roots))
roots[i] = true;
}
else
{
import std.parallelism : parallel;
foreach (i, id; ids.parallel())
if (ids[i] == i)
if (!(i in roots))
roots[i] = true;
}
return roots.keys;
}
/// Returns all the nodes connected to the given node
ulong[] getLinkedNodes(in ulong node) const
{
// premature optimization, if the array is not huge,
// do not opt for multithreaded operation
ulong[] nodes;
if (ids.length < 10_000)
{
foreach (i, _; ids)
if (this.connected(node, i))
nodes ~= i;
}
else
{
import std.parallelism : parallel;
foreach (i, _; ids.parallel())
if (this.connected(node, i))
nodes ~= i;
}
return nodes;
}
}
unittest
{
import std.stdio;
writefln("Testing %s...", __FILE__);
scope (success)
writeln("Success");
auto forrest = new DSets(9);
forrest.connect(9, 3);
forrest.connect(1, 3);
forrest.connect(9, 0);
forrest.connect(7, 5);
forrest.connect(6, 4);
assert(forrest.connected(1, 0));
assert(forrest.connected(3, 0));
assert(!forrest.connected(5, 4));
foreach (root; forrest.getRoots())
writeln(root, " ==> ", forrest.getLinkedNodes(root));
}
outupt:
$ dub test -q
Testing source/dsets.d...
6 ==> [4, 6]
7 ==> [5, 7]
2 ==> [2]
1 ==> [0, 1, 3, 9]
8 ==> [8]
Success
Re: Imports and Subfolders and Links (Oh, My!)
On 08/12/2018 6:41 AM, Ron Tarrant wrote: Does D have the concept of makefiles? I haven't run across any reference to such things so far. Make isn't a D specification application (it doesn't really specialize in any language) dmd, druntime and Phobos are all built using it. Though for user code, dub is the package+build manager that is more commonly used.
Re: Imports and Subfolders and Links (Oh, My!)
On Friday, 7 December 2018 at 16:43:02 UTC, Adam D. Ruppe wrote: That's wrong: the import name and the module name should always match, in full, including all the dot parts. So if you "import app.modulename;", the other file must have "module app.modulename;" Okay. I guess the instructions I saw were for an earlier version of D... or I misunderstood. (either is likely?) Moreover, you should either 1) list all modules in your application Are you talking about a list of import statements here or is there another way/place I would list them? not in a library on the command line, I'm not sure what you mean by 'library' in this statement. or 2) if using the newest compiler versions, pass the -i flag so the compiler will automatically include them for you. I tried this and it worked. Just still trying to understand when it would be necessary to use a prefix and dot separator in an import statement. The bottom line here is, I have an application (Corkboard) I wrote in PHPGtk years ago and I'm learning D by transposing it. I'd like to maintain the code organization I had in the original — subfolders, etc. At the same time, I'd like to put my big-boy pants on and make it look like I know what I'm doing when I compile rather than compiling modules over and over needlessly. Does D have the concept of makefiles? I haven't run across any reference to such things so far.
Re: Imports and Subfolders and Links (Oh, My!)
On Friday, 7 December 2018 at 16:39:34 UTC, Ron Tarrant wrote: import subfolder.ModuleName; And in the module files, the first statement is: module ModuleName; That's wrong: the import name and the module name should always match, in full, including all the dot parts. So if you "import app.modulename;", the other file must have "module app.modulename;" dmd -m64 -Lgtkd.lib main.d Moreover, you should either 1) list all modules in your application not in a library on the command line, or 2) if using the newest compiler versions, pass the -i flag so the compiler will automatically include them for you.
Imports and Subfolders and Links (Oh, My!)
Trying to wrap my brain around imports, etc. In various places around the Internet, I've read that if I have modules in a subfolder/subdirectory, my import statement would look like this: import subfolder.ModuleName; And in the module files, the first statement is: module ModuleName; However, I'm having trouble getting past the compile errors. Scenario: current folder contains - main.d In main.d, the import statements: import app.CountryTreeView import app.CountryListStore In the subfolder (named: app) I have two module files: - CountryTreeView.d (module CountryTreeView) - CountryListStore.d (module CountryListStore) When I compile using: dmd -m64 -Lgtkd.lib main.d I get a bunch of unresolved external symbol errors for classes and modules. The import statements in main.d don't import anything from the subfolder. Removing 'app.' from the import statements and compiling with: dmd -m64 -Lgktd.lib main.d -Iapp CountryListStore CountryTreeView it works. Two questions: 1) Under what circumstances would I prefix the folder/directory name in a statement importing modules I've built myself? 2) What would the dmd compile command look like?
Re: Trying to get current function name results in compiler error with __traits
On Friday, 7 December 2018 at 02:37:34 UTC, Arun Chandrasekaran
wrote:
I'm trying to get the current function name and apparently the
commented line errors out.
What am I doing wrong?
https://run.dlang.io/is/EGsRU2
```
#!/usr/bin/rdmd
void main()
{
import std.experimental.all;
void foo() {
// __traits(identifier, mixin(__FUNCTION__)).writeln;
// compilation error
__FUNCTION__.split('.')[$-1].writeln;
}
__traits(identifier, mixin(__FUNCTION__)).writeln;
__FUNCTION__.split('.')[$-1].writeln;
foo();
}
```
Looks like this will do the trick https://run.dlang.io/is/cX3S37
Re: could someone test support for Asian languages in nanogui port?
On Sunday, 6 May 2018 at 11:18:17 UTC, drug wrote: On 06.05.2018 06:10, Binghoo Dang wrote: hi, I'm a Chinese, and I just have done the test. I also copied some Japanese text from Dlang twitter channel and added some Chinese wide punctuation Char. And It's all seems displayed correctly. The resulting screenshot is here: https://pasteboard.co/HjRmOYg.png The only problem is that the font style simply looks strange. You can see the 'normal' text display in Win10 by default like this: https://pasteboard.co/HjRrigh.png Can it fixed by other font or there are some other problems? yeah, the bad font display can be resolved after setting a CJK font(I just replaced with msyh.ttf). the result is like this: https://pasteboard.co/HQBdP14.png thanks!
