Re: Phobos Unittest

2021-09-03 Thread Paul Backus via Digitalmars-d-learn

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: Phobos Unittest

2021-09-03 Thread Paul Backus via Digitalmars-d-learn

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

2021-09-03 Thread H. S. Teoh via Digitalmars-d-learn
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"...


Phobos Unittest

2021-09-03 Thread Per Nordlöw via Digitalmars-d-learn
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: Documentation generator is not working

2021-09-03 Thread Ali Çehreli via Digitalmars-d-learn

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




Re: Dustmite and linking error

2021-09-03 Thread JG via Digitalmars-d-learn
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: Dustmite and linking error

2021-09-03 Thread JG via Digitalmars-d-learn

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: template parameters :: fix

2021-09-03 Thread Charles Hixson via Digitalmars-d-learn

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: Run-time setting of immutable variable?

2021-09-03 Thread DLearner via Digitalmars-d-learn
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?