Re: Run-time setting of immutable variable?
On Thursday, 2 September 2021 at 23:12:28 UTC, Steven
Schveighoffer wrote:
[...]
immutable means "I can never change and *everything I point at*
can never change".
[...]
If that is how the language defines the keyword 'immutable' when
used in the definition of a pointer variable, then so be it.
I would, however, suggest that the additional
'action-at-a-distance' implication (freezing not just the
variable itself, but also it's target) is inconsistent with the
definition of 'immutable' with other variable types.
Surely it would be better to reserve 'immutable' on a pointer to
mean simply set-once on the pointer itself (with no implications
for whatever the pointer is pointing to), and another keyword
('blocked'?) for the current definition?
Re: template parameters :: fix
change:
{ rl.remove(i);
to:
{ rl = rl.remove(i);
--
Javascript is what you use to allow third party programs you don't know
anything about and doing you know not what to run on your computer.
Re: Dustmite and linking error
On Thursday, 2 September 2021 at 11:19:55 UTC, jfondren wrote: 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? Possibly it's not a compiler error at all but a name-mangling change combined with some stale objects in your build. Thanks for the suggestion. I thought I was doing this. What I did was run: dub clean --all-packages dub build --force Then I am getting twelve linking errors. Of the form: .. error: undefined reference to .
Re: Dustmite and linking error
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.
Re: Documentation generator is not working
On 9/2/21 10:38 AM, Vinod K Chandran wrote: On Thursday, 2 September 2021 at 17:34:59 UTC, Adam D Ruppe wrote: Anything after -run goes to your program not the compiler. Args to the compiler must be before -run. Thanks for the reply. Got the point now. :) So, change your program to respond to -D and generate the documentation potentially by spawning a dmd instance. :o) Ali
Phobos Unittest
When is a phobos unittest supposed to be qualified with version `(StdUnittest)`? Ideally, always? I don't see that their current use is consistenly following a rule. If so, is the purpose of its presence to reduce the burden of the compiler when the application using phobos is compiled with -unittest? (edited). If we were to put a `version (StdUnittest)` in front of every `unittest` in phobos (via an automated refactoring of course) would that speed building large applications or tests-suites with the `-unittest` flag provide they import many/all phobos libraries via, for instance, import `std`? When compiling non-phobos modules with `-unittest` flag, how are the `unittest`-blocks in imported phobos modules processed by the compiler? Are they only lexed (and parsed) but nothing else?
Re: Phobos Unittest
On Fri, Sep 03, 2021 at 11:39:44PM +, Per Nordlöw via Digitalmars-d-learn wrote: > When is a phobos unittest supposed to be qualified with version > `(StdUnittest)`? Ideally, always? I don't see that their current use > is consistenly following a rule. If so, is the purpose of its presence > to reduce the burden of the compiler when the application using phobos > is compiled with -unittest? (edited). [...] 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. StdUnittest is a hack introduced to suppress Phobos unittests in user programs. Theoretically it's supposed to apply to all unittests, but obviously whoever did it failed to cover every case. It's still up in the air whether or not this should even be fixed. Ideally, we should be fixing the behaviour of -unittest instead of living with this hack. T -- I'm still trying to find a pun for "punishment"...
Re: Phobos Unittest
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. StdUnittest is a hack introduced to suppress Phobos unittests in user programs. The point of `StdUnittest` is to suppress * `version (unittest)` blocks in Phobos * Phobos unittests in the bodies of templates that are instantiated by user code As Steven Schveighoffer [pointed out][1], Phobos unittests are never included in user code, regardless of whether `StdUnittest` is used. [1]: https://forum.dlang.org/post/sglmk0$33m$1...@digitalmars.com
Re: Phobos Unittest
On Friday, 3 September 2021 at 23:39:44 UTC, Per Nordlöw wrote: When is a phobos unittest supposed to be qualified with version `(StdUnittest)`? Almost never. `version (StdUnittest)` should be used in Phobos wherever you would normally use a `version (unittest)` block. It is not for the tests themselves, but for test fixtures and support code.
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
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 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.
