Re: why is it a class property cannot be used like a.b ~= c; ?
On Saturday, 4 September 2021 at 23:57:09 UTC, jfondren wrote: You're returning a copy of a slice, so if this compiled nothing useful would happen anyway. This works if `whatever()` returns `ref dstring` instead, with no other changes. Search https://dlang.org/spec/function.html for 'lvalue' and this pops right up. At first glance it seems a bit counter-intuitive but yes, you are right, thanks for the link jfronden :)
Re: Why can't the DMD compiler accept files or directories with white spaces even delimited by quotes?
On Sunday, 5 September 2021 at 00:00:33 UTC, jfondren wrote:
On Saturday, 4 September 2021 at 23:50:33 UTC, Marcone wrote:
Example:
dmd "hello world.d"
```
$ cat hello\ world.d
module helloworld;
void main() {
import std.stdio : writeln;
writeln("without the explicit 'module', this file would");
writeln("be inferred to have an invalid module name.");
}
$ dmd 'hello world.d'
$ ./hello\ world
without the explicit 'module', this file would
be inferred to have an invalid module name.
$ sed -i 1d hello\ world.d
$ dmd 'hello world.d'
hello world.d: Error: module `hello world` has non-identifier
characters in filename, use module declaration instead
```
Very Good! Now work fine.
Re: Why can't the DMD compiler accept files or directories with white spaces even delimited by quotes?
On Saturday, 4 September 2021 at 23:50:33 UTC, Marcone wrote:
Example:
dmd "hello world.d"
```
$ cat hello\ world.d
module helloworld;
void main() {
import std.stdio : writeln;
writeln("without the explicit 'module', this file would");
writeln("be inferred to have an invalid module name.");
}
$ dmd 'hello world.d'
$ ./hello\ world
without the explicit 'module', this file would
be inferred to have an invalid module name.
$ sed -i 1d hello\ world.d
$ dmd 'hello world.d'
hello world.d: Error: module `hello world` has non-identifier
characters in filename, use module declaration instead
```
Re: why is it a class property cannot be used like a.b ~= c; ?
On Saturday, 4 September 2021 at 23:33:39 UTC, someone wrote:
```d
public class cSomething {
private:
dstring pstrWhatever = null;
public:
@safe dstring whatever() { return pstrWhatever; }
@safe void whatever(const dstring lstrWhatever) {
pstrWhatever = lstrWhatever; }
}
void main() {
cSomething lobjSomething = new cSomething();
lobjSomething.whatever = r"abc"d;
lobjSomething.whatever ~= r"def"d; /// Error:
`lobjSomething.whatever()` is not an lvalue and cannot be
modified
}
```
You're returning a copy of a slice, so if this compiled nothing
useful would happen anyway. This works if `whatever()` returns
`ref dstring` instead, with no other changes. Search
https://dlang.org/spec/function.html for 'lvalue' and this pops
right up.
Why can't the DMD compiler accept files or directories with white spaces even delimited by quotes?
Example: dmd "hello world.d"
Re: Phobos Unittest
On Saturday, 4 September 2021 at 20:06:27 UTC, Per Nordlöw wrote: On Saturday, 4 September 2021 at 20:05:17 UTC, Per Nordlöw wrote: ```sh time dmd import_std.d -o- ``` should be ```sh time dmd -unittest import_std.d -o- ``` When you generate the object files, I get 13K vs. 75K from a file containing just `import std;`. More than parsing is happening differently. ``` $ objdump -dwr --no-show-raw-insn importstd.o |ddemangle | grep -oP 'std[\w.]+'|sort|uniq -c|sort -n|awk '$1 > 1' 28 std.uni.InversionList 28 std.uni.MultiArray 30 std.encoding.BOM 31 std.array.Appender 35 std.concurrency.List 35 std.concurrency.Message 38 std.uni.CowArray 44 std.variant.VariantN 56 std.typecons.Tuple 56 std.uni.BitPacked 66 std.uni.GcPolicy ```
why is it a class property cannot be used like a.b ~= c; ?
```d
public class cSomething {
private:
dstring pstrWhatever = null;
public:
@safe dstring whatever() { return pstrWhatever; }
@safe void whatever(const dstring lstrWhatever) { pstrWhatever
= lstrWhatever; }
}
void main() {
cSomething lobjSomething = new cSomething();
lobjSomething.whatever = r"abc"d;
lobjSomething.whatever ~= r"def"d; /// Error:
`lobjSomething.whatever()` is not an lvalue and cannot be modified
}
```
Re: Phobos Unittest
On Saturday, 4 September 2021 at 20:05:17 UTC, Per Nordlöw wrote: ```sh time dmd import_std.d -o- ``` should be ```sh time dmd -unittest import_std.d -o- ```
Re: Phobos Unittest
On Saturday, 4 September 2021 at 13:12:49 UTC, Steven Schveighoffer wrote: Note that lexing and parsing is extremely quick, and I wouldn't focus on trying to trim this out, you won't get much performance out of that. -Steve For the record, a D file containing only `import std;` type checks via ```sh time dmd import_std.d -o- ``` in 0.20s whereas ```sh time dmd import_std.d -o- ``` in 0.45s on my ThreadRipper.
Absence of isAllocator trait
Is there a reason for the absence of an `isAllocator` trait under `std.experimental.allocator`?
Re: Piping from terminal into D program
On Saturday, 4 September 2021 at 18:20:51 UTC, WebFreak001 wrote: On Saturday, 4 September 2021 at 15:41:51 UTC, eXodiquas wrote: [...] to extend on Brian Tiffin's reply, you can read from the standard input stream (the data piped to your program) using std.stdio's `stdin` [...] Brian Tiffin's and your reply really cleared things up for me. Thank you very much for the detailed answer and your time. Have a nice day. :)
Re: Piping from terminal into D program
On Saturday, 4 September 2021 at 15:41:51 UTC, eXodiquas wrote:
Hello everyone,
I created a small little D program that reads in a string from
the command line and shuffles the letters of the nouns a bit
around. This is pretty straight forward, but what I see now
happening is a bit strange, at least for me.
I am reading the args out of the main function arguments.
```d
void main(string[] args) {
args.writeln();
}
```
this works fine whenever I call the program like
`./nounscramble "Hello, my name is Earl!"` the string shows up
in `args[1]`. But when I call `echo "Hello, my name is Earl!" |
./nounscramble` it does not show up in the args array, the only
thing showing up is the name of the executable (which is
expected).
My question is now, can someone explain what I am doing wrong?
Maybe I misunderstood the pipe in Linux systems and it is
obvious for someone who knows how this works exactly, or maybe
D works differently with pipes and I havn't found the correct
documentation.
Thanks in advance. :)
eXodiquas
to extend on Brian Tiffin's reply, you can read from the standard
input stream (the data piped to your program) using std.stdio's
`stdin`
Example:
```d
import std.stdio;
foreach (line; stdin.byLine)
writeln("got input line: ", line);
// IMPORTANT: the line buffer is reused (it's a char[], not a
string), so if you want to store it in a variable outside the
foreach, use .idup to make it a string (that is not changed when
leaving the loop)
```
or
```d
import std.stdio;
foreach (chunk; stdin.byChunk(1024))
writeln("got input chunk: ", cast(char[])chunk);
// same warning as above, don't case to string (that's unsafe and
wouldn't be allowed in @safe code, but casting to char[] is safe,
as it explicitly says it can be changed)
```
or
```d
import std.stdio;
ubyte[1024] buffer;
auto part = cast(char[])stdin.rawRead(buffer[]);
writeln("got part: ", part);
// this is the lower level equivalent of the byChunk above, it's
just doing a single step instead of multiple chunks, so you
control when it is changed.
// a slice of this buffer (which is what the return value is)
needs to be .idup'd to be persisted outside the lifetime of the
`buffer` variable
```
Re: Piping from terminal into D program
On Saturday, 4 September 2021 at 15:41:51 UTC, eXodiquas wrote:
Hello everyone,
I created a small little D program that reads in a string from
the command line and shuffles the letters of the nouns a bit
around. This is pretty straight forward, but what I see now
happening is a bit strange, at least for me.
I am reading the args out of the main function arguments.
```d
void main(string[] args) {
args.writeln();
}
```
this works fine whenever I call the program like
`./nounscramble "Hello, my name is Earl!"` the string shows up
in `args[1]`. But when I call `echo "Hello, my name is Earl!" |
./nounscramble` it does not show up in the args array, the only
thing showing up is the name of the executable (which is
expected).
My question is now, can someone explain what I am doing wrong?
Maybe I misunderstood the pipe in Linux systems and it is
obvious for someone who knows how this works exactly, or maybe
D works differently with pipes and I havn't found the correct
documentation.
Thanks in advance. :)
eXodiquas
There are two things happening here. Command line arguments and
stdin, standard in.
When part of an actual command line, parameters are expanded as
command line arguments, passed to the `main` function. When
`echo`ed, the arguments are passed to the `echo` command, which
then displays those arguments on stdout, standard out. A pipe is
connecting the stdout of the left hand side, and streaming that
data to the stdin of the right hand side, after the pipe symbol.
These are not command line arguments, but data on the
stdin/stdout channels (file descriptors to be more exact with the
jargon).
You could write is as `echo thing | ./nounscramble commandarg`.
`echo` will display *thing*. Your program with get `commandarg`
in the array passed to `main`, but the stdout data displayed by
`echo` is never read, and just ends up in a pipeline bitbucket at
the end of processing.
Most shells, like `bash` allow a different kind of parameter
replacement, command arg expansion. Use like `./nounstatement
$(echo this that)`, and the shell will manipulate things to
replace the stdout from the `echo` into word expanded arguments
placed in the atring array used by `main`.
Cheers
Piping from terminal into D program
Hello everyone,
I created a small little D program that reads in a string from
the command line and shuffles the letters of the nouns a bit
around. This is pretty straight forward, but what I see now
happening is a bit strange, at least for me.
I am reading the args out of the main function arguments.
```d
void main(string[] args) {
args.writeln();
}
```
this works fine whenever I call the program like `./nounscramble
"Hello, my name is Earl!"` the string shows up in `args[1]`. But
when I call `echo "Hello, my name is Earl!" | ./nounscramble` it
does not show up in the args array, the only thing showing up is
the name of the executable (which is expected).
My question is now, can someone explain what I am doing wrong?
Maybe I misunderstood the pipe in Linux systems and it is obvious
for someone who knows how this works exactly, or maybe D works
differently with pipes and I havn't found the correct
documentation.
Thanks in advance. :)
eXodiquas
Re: Phobos Unittest
On 9/4/21 7:43 AM, Johan wrote: On Saturday, 4 September 2021 at 03:18:01 UTC, Paul Backus wrote: On Saturday, 4 September 2021 at 00:09:37 UTC, H. S. Teoh wrote: This is related to the bogonity of the current behaviour of -unittest, which compiles *all* unittests of *all* imported modules, even when you're compiling user code that has no interest in Phobos unittests. Well, no; it compiles all unittests of all *compiled* modules, not all *imported* modules. So it does not actually include Phobos unittests. [...] As Steven Schveighoffer [pointed out][1], Phobos unittests are never included in user code, regardless of whether `StdUnittest` is used. The "never" is false, https://d.godbolt.org/z/c4oeYM7rG Unittests inside template code will be added to user code, unless the compiler has determined that the template is already instantiated in Phobos code (the "template culling" that the frontend does, whose behavior is not easily influenced by the programmer). It's always included (or at least it was when I last looked at it), as -unittest implies some form of -allinst. There was some effort to fix this, but I can't remember if the outcome was that it was merged or not. -Steve
Re: Phobos Unittest
On 9/4/21 5:42 AM, Per Nordlöw wrote: On Saturday, 4 September 2021 at 03:18:01 UTC, Paul Backus wrote: As Steven Schveighoffer [pointed out][1], Phobos unittests are never included in user code, regardless of whether `StdUnittest` is used. Yes, but they are lexed and parsed, right? Yes, and I think this is trivially so for any versioned code in the file. Note that lexing and parsing is extremely quick, and I wouldn't focus on trying to trim this out, you won't get much performance out of that. -Steve
Re: Phobos Unittest
On Saturday, 4 September 2021 at 12:40:02 UTC, Per Nordlöw wrote: Omg. It really seems like it's motivated to do a benchmark with phobos unittests prefixed with Should have been a reply to The "never" is false, https://d.godbolt.org/z/c4oeYM7rG
Re: Phobos Unittest
On Saturday, 4 September 2021 at 12:40:02 UTC, Per Nordlöw wrote: then. I can make that refactoring in my favorite choice of editor and see the result differ. In terms of binary size, and speed and memory usage of check, build and link time. Automated that is. If we want this, shall we format as ```d version (StdUnittest) [QUALIFIER...] unittest ``` instead of current ```d version (StdUnittest) [QUALIFIER...] unittest ``` ?
Re: Phobos Unittest
On Saturday, 4 September 2021 at 12:31:33 UTC, Dennis wrote: On Saturday, 4 September 2021 at 09:42:46 UTC, Per Nordlöw wrote: Yes, but they are lexed and parsed, right? Right, but that's the case regardless of `version(StdUnittest)`. Omg. It really seems like it's motivated to do a benchmark with phobos unittests prefixed with version(StdUnittest) then. I can make that refactoring in my favorite choice of editor and see the result differ. In terms of binary size, and speed and memory usage of check, build and link time.
Re: Phobos Unittest
On Saturday, 4 September 2021 at 12:31:33 UTC, Dennis wrote: Right, but that's the case regardless of `version(StdUnittest)`. I don't think so. My guess is that `version(StdUnittest)` does maximum parsing, maybe only lexing. How can one easily determine if this is the fact? Behaviour of `pragma(msg)`?
Re: Phobos Unittest
On Saturday, 4 September 2021 at 09:42:46 UTC, Per Nordlöw wrote: Yes, but they are lexed and parsed, right? Right, but that's the case regardless of `version(StdUnittest)`.
Re: Phobos Unittest
On Saturday, 4 September 2021 at 03:18:01 UTC, Paul Backus wrote: On Saturday, 4 September 2021 at 00:09:37 UTC, H. S. Teoh wrote: This is related to the bogonity of the current behaviour of -unittest, which compiles *all* unittests of *all* imported modules, even when you're compiling user code that has no interest in Phobos unittests. Well, no; it compiles all unittests of all *compiled* modules, not all *imported* modules. So it does not actually include Phobos unittests. [...] As Steven Schveighoffer [pointed out][1], Phobos unittests are never included in user code, regardless of whether `StdUnittest` is used. The "never" is false, https://d.godbolt.org/z/c4oeYM7rG Unittests inside template code will be added to user code, unless the compiler has determined that the template is already instantiated in Phobos code (the "template culling" that the frontend does, whose behavior is not easily influenced by the programmer). -Johan
Re: Dustmite and linking error
On Saturday, 4 September 2021 at 08:54:31 UTC, Mike Parker wrote: On Saturday, 4 September 2021 at 08:19:53 UTC, JG wrote: [...] You should be able to do that now with "sourceFiles" and "sourcePaths". Just avoid the default "source" or "src" directories and specify the paths and/or files you want for each configuration. I didn't know about this. Thanks you for letting me know.
Re: Phobos Unittest
On Saturday, 4 September 2021 at 03:18:01 UTC, Paul Backus wrote: As Steven Schveighoffer [pointed out][1], Phobos unittests are never included in user code, regardless of whether `StdUnittest` is used. Yes, but they are lexed and parsed, right?
Re: Dustmite and linking error
On Saturday, 4 September 2021 at 08:19:53 UTC, JG wrote: As a small comment regarding dub. I can't help wondering if it really the best idea for each configuration to include everything by default and then have to exclude things? This means that when you add another configuration and source files for it you very often have to modify all other existing ones. If instead you choose what to include this wouldn't happen. Wild cards support could be added for included files to make projects with a single configuration just as simple as now. Just some thoughts. (I feel the same way regarding gitignore, I would rather have the opposite.) You should be able to do that now with "sourceFiles" and "sourcePaths". Just avoid the default "source" or "src" directories and specify the paths and/or files you want for each configuration.
Re: Dustmite and linking error
On Saturday, 4 September 2021 at 08:05:16 UTC, JG wrote: On Saturday, 4 September 2021 at 07:40:07 UTC, Vladimir Panteleev wrote: On Saturday, 4 September 2021 at 07:38:34 UTC, Andre Pany wrote: The Dustmite condition you are using seems very generic, therefore this error message can be triggered by various code constellations. This might be the reasons why Dustmite is running so long. Overly generic test conditions would be more likely to cause DustMite to finish very quickly (and produce the wrong result), rather than the other way around. In the end I did the reduction by hand and discovered that the problem is that the behaviour of dub changed. It seems to now exclude the mainSourceFile of other configurations in the build (which I guess shouldn't matter) except we had an old configuration which after some renaming had a wrong mainSourceFile which was needed for the build of the configuration in question. Thanks for the suggestions. As a small comment regarding dub. I can't help wondering if it really the best idea for each configuration to include everything by default and then have to exclude things? This means that when you add another configuration and source files for it you very often have to modify all other existing ones. If instead you choose what to include this wouldn't happen. Wild cards support could be added for included files to make projects with a single configuration just as simple as now. Just some thoughts. (I feel the same way regarding gitignore, I would rather have the opposite.)
Re: Dustmite and linking error
On Saturday, 4 September 2021 at 07:40:07 UTC, Vladimir Panteleev wrote: On Saturday, 4 September 2021 at 07:38:34 UTC, Andre Pany wrote: The Dustmite condition you are using seems very generic, therefore this error message can be triggered by various code constellations. This might be the reasons why Dustmite is running so long. Overly generic test conditions would be more likely to cause DustMite to finish very quickly (and produce the wrong result), rather than the other way around. In the end I did the reduction by hand and discovered that the problem is that the behaviour of dub changed. It seems to now exclude the mainSourceFile of other configurations in the build (which I guess shouldn't matter) except we had an old configuration which after some renaming had a wrong mainSourceFile which was needed for the build of the configuration in question. Thanks for the suggestions.
Re: Dustmite and linking error
On Saturday, 4 September 2021 at 07:38:34 UTC, Andre Pany wrote: The Dustmite condition you are using seems very generic, therefore this error message can be triggered by various code constellations. This might be the reasons why Dustmite is running so long. Overly generic test conditions would be more likely to cause DustMite to finish very quickly (and produce the wrong result), rather than the other way around.
Re: Dustmite and linking error
On Thursday, 2 September 2021 at 11:04:12 UTC, JG wrote: Hi, We hit a linking error (after upgrading to dub 1.26.0). I thought I would try to use dustmite to create a reduced error test case. One week later it is still running (depth 22). I don't suppose there is anyway of determining when it will finish? Hi, The Dustmite condition you are using seems very generic, therefore this error message can be triggered by various code constellations. This might be the reasons why Dustmite is running so long. You might delete all fetched dub packages in your home directory and also delete .dub in your project directory. Hopefully this already solves the issue. Kind regards Andre
Re: Dustmite and linking error
On Saturday, 4 September 2021 at 06:18:52 UTC, JG wrote: I tried again. What am I doing wrong? cp source ~/tmp/source cd ~/tmp/source dub build --config prog1 2>&1 | grep "collect2: error: ld returned 1 exit status" echo $? #produces 0 find . -name *.o -delete ~/d/DustMite/dustmite -j ./ 'dub build --config prog1 2>&1 | grep "collect2: error: ld returned 1 exit status"' cd ../source.reduced dub build --config prog1 2>&1 | grep "collect2: error: ld returned 1 exit status" echo $? #produces 1 One potential source of trouble is using Dub. Dub doesn't play well with tools such as DustMite, because it keeps state outside of the current directory. In some cases, it even writes to that state, which works very poorly especially with `-j`. Dub has a built-in "dustmite" command, though it is a bit limited - you could use `dub -v` to get the compiler and linker commands that Dub runs, and run them directly from your test command. Some bugs do not reproduce 100% of the time, and are random in nature, due to depending on memory layout or thread timing. Try running the test command a number of times and see if that affects the result. Regardless, your workflow looks OK from a high level - the source.reduced directory should indeed contain the contents of a directory for which the test command did return 0, for one reason or another.
Re: Dustmite and linking error
On Saturday, 4 September 2021 at 06:18:52 UTC, JG wrote: On Friday, 3 September 2021 at 19:56:30 UTC, JG wrote: [...] I tried again. What am I doing wrong? cp source ~/tmp/source cd ~/tmp/source dub build --config prog1 2>&1 | grep "collect2: error: ld returned 1 exit status" echo $? #produces 0 find . -name *.o -delete ~/d/DustMite/dustmite -j ./ 'dub build --config prog1 2>&1 | grep "collect2: error: ld returned 1 exit status"' cd ../source.reduced dub build --config prog1 2>&1 | grep "collect2: error: ld returned 1 exit status" echo $? #produces 1 First line should be: cp -R source ~/tmp/source
Re: Dustmite and linking error
On Friday, 3 September 2021 at 19:56:30 UTC, JG wrote: On Thursday, 2 September 2021 at 17:56:54 UTC, Vladimir Panteleev wrote: On Thursday, 2 September 2021 at 11:20:18 UTC, Vladimir Panteleev wrote: One way to get a very rough estimate is to take the square of the current reduction (.reduced directory), and divide it by the square of the original source. I meant the square of the size of the respective directory. (bytes / LOC / SLOC...) One week later it is still running (depth 22). If you are still on the first iteration, you may also try switching to the "careful" strategy. Thanks for the information. I stopped dustMite and realized I must have done something wrong since the reduced test case doesn't reproduce the problem. I would really like to try and produce a reduced test case of this problem. However having spent three or four hours trying to figure out what I am doing wrong I think I will have to stop at this point. I tried again. What am I doing wrong? cp source ~/tmp/source cd ~/tmp/source dub build --config prog1 2>&1 | grep "collect2: error: ld returned 1 exit status" echo $? #produces 0 find . -name *.o -delete ~/d/DustMite/dustmite -j ./ 'dub build --config prog1 2>&1 | grep "collect2: error: ld returned 1 exit status"' cd ../source.reduced dub build --config prog1 2>&1 | grep "collect2: error: ld returned 1 exit status" echo $? #produces 1
