Nested sub packages in dub
How to do that?
Re: Nested sub packages in dub
On Sunday, 2 December 2018 at 09:17:59 UTC, Domain wrote: How to do that? As far as I know dub does not support nested sub packages. You could create a second dub package B with sub package B1 and reference it from your sub package A1. Kind regards Andre
compile time sequence through dub config or commandline.
I would like to do something like
`
dmd --buildversion=fooCollection{"a", "b", "c"} -run app.d
...
void bar()
{
static foreach(i; fooCollection)
{
...
}
}
`
The idea being that bar can be packed in a library and the
program that includes this library can decide what parameters
will be added to foo whitout any runtime overhead and ugly
looking syntax.
Is something simular possible?
If not, could I achieve thesame result by including a file
`programsettings.d` with some compile time constants in there
whitout my library depending on it?
Re: compile time sequence through dub config or commandline.
On Sunday, 2 December 2018 at 14:50:05 UTC, Sjoerd Nijboer wrote: The idea being that bar can be packed in a library and the program that includes this library can decide what parameters will be added to foo whitout any runtime overhead and ugly looking syntax. The normal way to do this would be to make bar a template and have the program that uses it pass these parameters to it as template arguments.
Re: compile time sequence through dub config or commandline.
On Sunday, 2 December 2018 at 17:59:56 UTC, Paul Backus wrote: The normal way to do this would be to make bar a template and have the program that uses it pass these parameters to it as template arguments. Why didn't I think of that? It's just initializing a library, of course! Thank you for your help and happy coding.
Re: Why does nobody seem to think that `null` is a serious problem in D?
On Saturday, 1 December 2018 at 19:02:54 UTC, H. S. Teoh wrote: In the above contrived example, Artin's conjecture is implied by the Riemann hypothesis, so the second if statement would only run if p is initialized. But there is no way the compiler is going to be able to deduce this, especially not during compile time. So it is not possible to correctly flag p as being initialized or not when it is dereferenced. Therefore, leaving it up to the compiler to detect uninitialized variables is unreliable, and therefore any code that depends on this cannot be trusted. Code like the above could be exploited by a sufficiently sophisticated hack to make the uninitialized value of p coincide with something that will open a security hole, and the compiler would not be able to reliably warn the programmer of this problem. Uninitialized variables are *not* a good thing, contrary to what the author of the article might wish to believe. T If a compiler were to issue warnings/error for uninitialized variables. Then that example would be a compiler error. The logic would just be that not all code paths lead to an initialized variable, therefor *p++ is not guaranteed to be initialized - i.e. error. Swift takes this approach. Cheers, - Ali
Re: Why does nobody seem to think that `null` is a serious problem in D?
On Saturday, 1 December 2018 at 19:02:54 UTC, H. S. Teoh wrote: But that's precisely the problem. It's not always possible to tell whether a variable has been initialized. E.g.: To me, the possibility of a "false positive" doesn't preclude the use of a warning unless that possibility is large. Besides using a compiler option or pragma to get rid of it, the warning also goes away if you assign NULL or (X *) 0. Surprisingly, clang (gcc 6.3 does not give the warning) is not smart enough to then issue a "possibly dereferencing null pointer" warning. Therefore, leaving it up to the compiler to detect uninitialized variables is unreliable, and therefore any code that depends on this cannot be trusted. Code like the above could be exploited by a sufficiently sophisticated hack to make the uninitialized value of p coincide with something that will open a security hole, and the compiler would not be able to reliably warn the programmer of this problem. I don't know that "leaving it up to the compiler" is a correct characterization. I don't see the programmer doing anything different with the warning capability in the compiler than if it wasn't there. In either case, the programmer will attempt to supply values to all the variables they have declared and are intending to use, and in the correct order.
File .. byLine
I can't seem to get this to work!
```
foreach(line; File("help.txt").byLine) {
writeln(line.stripLeft);
```
With the code above, I get this compile error:
source/app.d(360,36): Error: template
std.algorithm.mutation.stripLeft cannot deduce function from
argument types !()(char[]), candidates are:
/usr/local/opt/dmd/include/dlang/dmd/std/algorithm/mutation.d(2602,7):
std.algorithm.mutation.stripLeft(Range, E)(Range range, E element) if
(isInputRange!Range && is(typeof(range.front == element) : bool))
/usr/local/opt/dmd/include/dlang/dmd/std/algorithm/mutation.d(2610,7):
std.algorithm.mutation.stripLeft(alias pred, Range)(Range range) if (isInputRange!Range
&& is(typeof(pred(range.front)) : bool))
I just want to use each 'line' variable as a string?! I've tried
'byLineCopy', and 'line.to!string'. I've looked at documentation.
Re: File .. byLine
On Monday, 3 December 2018 at 06:09:21 UTC, Joel wrote:
I can't seem to get this to work!
```
foreach(line; File("help.txt").byLine) {
writeln(line.stripLeft);
```
With the code above, I get this compile error:
source/app.d(360,36): Error: template
std.algorithm.mutation.stripLeft cannot deduce function from
argument types !()(char[]), candidates are:
/usr/local/opt/dmd/include/dlang/dmd/std/algorithm/mutation.d(2602,7):
std.algorithm.mutation.stripLeft(Range, E)(Range range, E element) if
(isInputRange!Range && is(typeof(range.front == element) : bool))
/usr/local/opt/dmd/include/dlang/dmd/std/algorithm/mutation.d(2610,7):
std.algorithm.mutation.stripLeft(alias pred, Range)(Range range) if (isInputRange!Range
&& is(typeof(pred(range.front)) : bool))
I just want to use each 'line' variable as a string?! I've
tried 'byLineCopy', and 'line.to!string'. I've looked at
documentation.
https://run.dlang.io/is/h0ArAB
works for me. If you want it as a string not char[] then
byLineCopy should work, if not just `.idup` `line`.
Re: File .. byLine
On Monday, 3 December 2018 at 06:55:50 UTC, Nicholas Wilson wrote: On Monday, 3 December 2018 at 06:09:21 UTC, Joel wrote: [...] https://run.dlang.io/is/h0ArAB works for me. If you want it as a string not char[] then byLineCopy should work, if not just `.idup` `line`. Oh, I was using std.algorithm's 'stripLeft' instead of std.string's 'stripLeft'.
