Re: understanding Auto-Test

[Seb via Digitalmars-d]

On Thursday, 22 March 2018 at 05:00:07 UTC, John Belmonte wrote:

On Thursday, 22 March 2018 at 04:25:00 UTC, Seb wrote:
- Every time a PR is merged at dmd, druntime or phobos ALL 
auto-tester results get invalidated


If a change on the destination branch causes a PR to require an 
automatic merge, certainly build and tests should be rerun.  
But if the two changes are unrelated do the results of all 
pending PR's need to be invalidated?


Well, auto-tester is in place for a few years already. Its git 
history [1] goes back to 2010, but I assume the auto-tester to be 
even older.
Back in these old, dark ages, a commit in another PR (even if 
it's a different repo), was a bit more likely to break the 
current PR.
Nowadays, that's a lot less common, but still happens from time 
to time (e.g. you make a PR to deprecate sth., but in the 
meanwhile a new usage got added to Phobos or a new @safe-ty 
violation got added).


Anyhow, the idea is to guarantee that `master` is always 
buildable and passes all tests no matter what and this constant 
invalidation is the only way to deal with this as there's no way 
to automatically determine whether the new changes in master are 
really unrelated.


Note that what the auto-tester does for you automatically, is 
very similar to GitHub's "Require branches to be up to date 
before merging" branch setting, except that instead of manually 
needing to rebase the branch all the time, auto-tester does the 
rebases automatically and is "cross-repository aware".


[1] https://github.com/braddr/at-client

Re: understanding Auto-Test

[John Belmonte via Digitalmars-d]

On Thursday, 22 March 2018 at 04:25:00 UTC, Seb wrote:
- Every time a PR is merged at dmd, druntime or phobos ALL 
auto-tester results get invalidated


If a change on the destination branch causes a PR to require an 
automatic merge, certainly build and tests should be rerun.  But 
if the two changes are unrelated do the results of all pending 
PR's need to be invalidated?



Did this clarify things for you?


Yes, thank you for taking the time to explain the system.

Re: Manipulate slice or specific element of range and return range

[Seb via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 11:30:28 UTC, Timoses wrote:

Hey,

I'm struggling to find a way to achieve this. I've looked 
through std.algorithm but didn't find anything.. Maybe I'm 
blind.


What I would like to do is filter out all spaces in a string 
and change the front letter to lower case:


string m = "My Capital String";
string lower = m
.filter!(c => c != ' ')
.!(0, c => c.toLower) // executeAt does not 
exist

.array.to!string;
assert(lower == "myCapitalString");

or sth like

m.filter!(...)
.map!((element, int index) {
if (index == 0)
return element.toLower;
else
break; // stop since we are done manipulating 
range

});

Anyway to do this?


No need for regular expressions. D is powerful enough without 
them:


```
alias lowercased = (m, n) => 
m.take(n).asLowerCase.chain(m.drop(n));

```

https://run.dlang.io/is/cSL0si

Re: understanding Auto-Test

[Seb via Digitalmars-d]

On Thursday, 22 March 2018 at 04:17:52 UTC, Mike Franklin wrote:

On Thursday, 22 March 2018 at 04:12:00 UTC, John Belmonte wrote:

I'm still rather puzzled.  My pull request remains with 8 
tests pending after several hours.  I can't find any 
confirmation on the pulls display 
https://auto-tester.puremagic.com/pulls.ghtml?projectid=1 that 
it intends to run the tests.   Surely being listed in the "Old 
results" table doesn't imply pending runs against a new SHA, 
otherwise why would there be entries there dated 2017?


I see.  It appears GitHub didn't pick of the latest status (or 
the auto-tester didn't notify GitHub;


Everything is working as expected. Every time a PR gets merged, 
ALL pull requests get invalidated and are moved to "Old results" 
as their results have been calculated against an old head.
Then auto-tester starts to reduce the "Old results" list by 
building them again.

It's a constant fight.


I'm not which way the  data flows).


GitHub -> CIs (via hooks)

(though especially auto-tester queries back a lot)

Let's see what happens after the auto-tester starts testing it 
again.  I'll keep an eye on it.


No need to keep an eye on this. auto-tester will constantly 
rebuild the PR and invalidate it.

The only way interaction is possible is via:

- manually invalidating builds (called "delete" at the 
auto-tester) - not really useful as builds are automatically 
invalidated
- "auto-merge" priority builds. The PR has super-priority in the 
build queue.


That's happening currently with the four builds at the top:

https://imgur.com/a/29Ohn

Re: understanding Auto-Test

[Seb via Digitalmars-d]

On Thursday, 22 March 2018 at 04:12:00 UTC, John Belmonte wrote:

On Thursday, 22 March 2018 at 01:51:49 UTC, Mike Franklin wrote:
I believe what happened is a different PR was merged.  When a 
PR is merged, all tests are invalidated, and the autotester 
begins testing them again.


There is also a priority affecting which PRs get tested first.
 Those that are labeled with "AutoMerge" are given a higher 
priority.


I'm still rather puzzled.  My pull request remains with 8 tests 
pending after several hours.  I can't find any confirmation on 
the pulls display 
https://auto-tester.puremagic.com/pulls.ghtml?projectid=1 that 
it intends to run the tests.   Surely being listed in the "Old 
results" table doesn't imply pending runs against a new SHA, 
otherwise why would there be entries there dated 2017?


I give it a shot:

- Every time a PR is merged at dmd, druntime or phobos ALL 
auto-tester results get invalidated
- The auto-tester constantly tries to build PRs which have now 
results based on his queue (it's sorted after merge priority + 
last pushed timestamp)


The traffic is usually so high that your PR will always be at 
pending. That's really not a big deal. On the contrary, once your 
PR has been approved and gets on the merge queue, it will receive 
higher priority and usually will be merged within 1-3 hours.


Also all reviewers are familiar with auto-tester and pending 
tests have zero effect on the reviewers. All the other CIs 
already give a good feedback and if they want to, they can check 
the history of auto-tester for permanent failures


I can't find any confirmation on the pulls display that it 
intends to run the tests.


There's none. It _constantly_ reruns your PR.

 Surely being listed in the "Old results" table doesn't imply 
pending runs against a new SHA, otherwise why would there be 
entries there dated 2017?


The timestamp you see on pulls.ghtml?projectid=1 is GitHub's last 
modified timestamp which essentially is timestamp of the last 
push to the respective branch.


And yep there are a few old PRs, but the auto-tester newer tests 
them as its working queue order is sorted by the "Last Commited" 
timestamp.


Did this clarify things for you?

Re: understanding Auto-Test

[Mike Franklin via Digitalmars-d]

On Thursday, 22 March 2018 at 04:12:00 UTC, John Belmonte wrote:

I'm still rather puzzled.  My pull request remains with 8 tests 
pending after several hours.  I can't find any confirmation on 
the pulls display 
https://auto-tester.puremagic.com/pulls.ghtml?projectid=1 that 
it intends to run the tests.   Surely being listed in the "Old 
results" table doesn't imply pending runs against a new SHA, 
otherwise why would there be entries there dated 2017?


I see.  It appears GitHub didn't pick of the latest status (or 
the auto-tester didn't notify GitHub; I'm not which way the data 
flows).


Let's see what happens after the auto-tester starts testing it 
again.  I'll keep an eye on it.


Mike

Re: understanding Auto-Test

[Mike Franklin via Digitalmars-d]

On Thursday, 22 March 2018 at 04:17:52 UTC, Mike Franklin wrote:

Let's see what happens after the auto-tester starts testing it 
again.


Note that it could be a while, as there are PRs that will be 
getting merged in the next 24 hours that will restart the test 
queue.


Mike

Re: Understanding slide

[Seb via Digitalmars-d-learn]

On Thursday, 22 March 2018 at 03:58:35 UTC, Seb wrote:

On Thursday, 22 March 2018 at 03:39:38 UTC, Jordan Wilson wrote:

auto a = iota(5).slide!(Yes.withPartial)(3);
auto b = iota(5).slide!(No.withPartial)(3);
assert (a.equal(b));

The assert passes, but I would expect it to fail? They both 
are:

[[0,1,2],[1,2,3],[2,3,4]]

Thanks,

Jordan


See:
https://forum.dlang.org/post/asocdlqaihkskiilr...@forum.dlang.org


PR to improve the docs: https://github.com/dlang/phobos/pull/6322

Re: understanding Auto-Test

[John Belmonte via Digitalmars-d]

On Thursday, 22 March 2018 at 01:51:49 UTC, Mike Franklin wrote:
I believe what happened is a different PR was merged.  When a 
PR is merged, all tests are invalidated, and the autotester 
begins testing them again.


There is also a priority affecting which PRs get tested first.  
Those that are labeled with "AutoMerge" are given a higher 
priority.


I'm still rather puzzled.  My pull request remains with 8 tests 
pending after several hours.  I can't find any confirmation on 
the pulls display 
https://auto-tester.puremagic.com/pulls.ghtml?projectid=1 that it 
intends to run the tests.   Surely being listed in the "Old 
results" table doesn't imply pending runs against a new SHA, 
otherwise why would there be entries there dated 2017?

Re: Understanding slide

[Seb via Digitalmars-d-learn]

On Thursday, 22 March 2018 at 03:39:38 UTC, Jordan Wilson wrote:

auto a = iota(5).slide!(Yes.withPartial)(3);
auto b = iota(5).slide!(No.withPartial)(3);
assert (a.equal(b));

The assert passes, but I would expect it to fail? They both are:
[[0,1,2],[1,2,3],[2,3,4]]

Thanks,

Jordan


See:
https://forum.dlang.org/post/asocdlqaihkskiilr...@forum.dlang.org

Understanding slide

[Jordan Wilson via Digitalmars-d-learn]

auto a = iota(5).slide!(Yes.withPartial)(3);
auto b = iota(5).slide!(No.withPartial)(3);
assert (a.equal(b));

The assert passes, but I would expect it to fail? They both are:
[[0,1,2],[1,2,3],[2,3,4]]

Thanks,

Jordan

Re: #dbugfix 17592

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 22 March 2018 at 01:55:48 UTC, 12345swordy wrote:
Are you suggesting that we need runtime version of system/user 
attributes?


We already have that in a sense - InvalidMemoryOperationError is 
thrown if you try to GC allocate from inside a GC destructor. The 
attributes are supposed to render such runtime errors impossible, 
catching them at compile time instead.



All classes are dynamic types


I do not see it anywhere in the dlang specification that 
supports your claim.

https://dlang.org/spec/class.html


This is the reason why all D classes have a vtable attached (with 
attached runtime type info). *All* class-specific features are 
centered around this - casts use rtti, inheritance and interfaces 
use the vtable. It is the reason why D classes are reference 
types - otherwise, when you substitute it, you'd risk slicing the 
object.


If you took the dynamic aspect out of classes, you'd have an 
entirely different animal... the thing D calls a "struct".


Why can't it produce a warning message regarding implied 
classes conversion if it detects mismatch attributes?


The entire purpose of OOP inheritance existing is the 
substitution principle, that subclasses can take the place of 
base classes transparently. This is an either-or situation: if we 
want to keep the current definition of classes, bug 17592 MUST be 
closed as "wontfix" as it is by design to maintain 
substitutiability.


If we want to fix #17592, we MUST redefine the language's 
definition of class destructors to follow inheritance-style rules 
on matching attribute (even if they are actually implemented as a 
chain), again to guarantee substitutability is not broken.


There's no middle ground possible.

Re: #dbugfix 17592

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 22 March 2018 at 02:16:56 UTC, SimonN wrote:

Does the compiler infer nogc-ness of `emplace` at instantiation?


Yes, it does with all templates, actually. Since their nogcness 
(and other attributes like nothrow, pure, etc) frequently depend 
on what arguments they are passed, the compiler will infer it at 
instantiation.


Putting the explicit attribute on a template forces it to be such 
- then it will reject non-matching arguments (e.g. @nogc emplace 
would be a compile error if passed a gc constructor, regardless 
of if it is used in a gc or nogc context. without the explicit 
attribute, the compiler infers it and thus only throws the error 
if used in an actual nogc context).


My first hunch was that B's yes-gc-destructor should be illegal 
when A's descructor is `@nogc`, but it can be legal because 
destructors in a hierarchy are chained, not overridden. Seems 
like there is no way to ensure at child-class-compile-time that 
all child classes of A must be designed `@nogc`.


Right. That's the key problem to @nogc destroy and why we can't 
fix it in the library - it would require a language chance to 
force subclass dtors to have the same attribute set as the base 
class, as if they were overridden virtual inherited members.

Re: #dbugfix 17592

[SimonN via Digitalmars-d]

On Wednesday, 21 March 2018 at 13:55:16 UTC, Adam D. Ruppe wrote:
`emplace` is ALREADY `@nogc`

Interesting -- I checked the phobos source, and none of the 
`emplace` or `emplaceRef` are declared `@nogc`, yet the unittests 
marked as `@nogc` pass.


Does the compiler infer nogc-ness of `emplace` at instantiation?


class A { @nogc ~this() {} }
class B : A { ~this() {} }


My first hunch was that B's yes-gc-destructor should be illegal 
when A's descructor is `@nogc`, but it can be legal because 
destructors in a hierarchy are chained, not overridden. Seems 
like there is no way to ensure at child-class-compile-time that 
all child classes of A must be designed `@nogc`.


-- Simon

Re: #dbugfix 17592

[12345swordy via Digitalmars-d]

On Thursday, 22 March 2018 at 01:09:56 UTC, Adam D. Ruppe wrote:


But @nogc is a compile time thing, meaning it cannot work here.


Are you suggesting that we need runtime version of system/user 
attributes?



All classes are dynamic types


I do not see it anywhere in the dlang specification that supports 
your claim.

https://dlang.org/spec/class.html

Why can't it produce a warning message regarding implied classes 
conversion if it detects mismatch attributes? The risk of 
information exist when making certain dynamic type conversion. I 
do not see for any reason why they can't be warning messages 
regarding the possibility of losing information when making 
implied type conversions. There even a DIP pull request consist 
of deprecating a certain type conversion, because of certain bugs 
detected.

Re: understanding Auto-Test

[Mike Franklin via Digitalmars-d]

On Thursday, 22 March 2018 at 01:46:08 UTC, John Belmonte wrote:
I'm trying to understand why my pull request was queued in D2 
Auto-Test for only 2 of 8 tests, with the remaining left in 
pending state.


  
https://auto-tester.puremagic.com/pull-history.ghtml?projectid=1=1=8051


Since there are pending tests, I'd expect it to appear in the 
standard priority pull queue under "Has passes".


  https://auto-tester.puremagic.com/pulls.ghtml?projectid=1

What I'm I overlooking?

Kindly,
--John


I believe what happened is a different PR was merged.  When a PR 
is merged, all tests are invalidated, and the autotester begins 
testing them again.


There is also a priority affecting which PRs get tested first.  
Those that are labeled with "AutoMerge" are given a higher 
priority.


Mike

understanding Auto-Test

[John Belmonte via Digitalmars-d]

I'm trying to understand why my pull request was queued in D2 
Auto-Test for only 2 of 8 tests, with the remaining left in 
pending state.


  
https://auto-tester.puremagic.com/pull-history.ghtml?projectid=1=1=8051


Since there are pending tests, I'd expect it to appear in the 
standard priority pull queue under "Has passes".


  https://auto-tester.puremagic.com/pulls.ghtml?projectid=1

What I'm I overlooking?

Kindly,
--John

[Issue 18600] Regex performance enhancement for repeated matchFirst calls

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18600

--- Comment #1 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/4318073f40ae3e82ac1847da5e037ab2f091d6fc
Fix issue 18600 Revamp std.regex caching for matchFirst case

--

[Issue 18600] Regex performance enhancement for repeated matchFirst calls

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18600

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: #dbugfix 17592

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 21 March 2018 at 19:21:15 UTC, 12345swordy wrote:
That seems to be it's own separate problem, as it involves 
generating dynamic types at run-time, which it needs run-time 
equivalent of attribute checking.


But @nogc is a compile time thing, meaning it cannot work here.

My example assumes that the classes created are static types 
not dynamic types. Besides I do not like implied conversions 
when it comes classes, as I believe it is a horrible idea.


All classes are dynamic types, this is their reason for existing!

Re: -betterC is amazing, make (/keep making) it more sophisticated!

[Seb via Digitalmars-d]

On Wednesday, 21 March 2018 at 23:46:19 UTC, jmh530 wrote:

On Wednesday, 21 March 2018 at 22:48:36 UTC, Seb wrote:


I heard that Walter recently ported his DMC++ to D and I heard 
that someone was working on this, so chances aren't too bad 
that this might happen ;-)




You might check out Atila's github page (I don't think it's 
ready for release yet).


For reference, I think jmh530 was referring to this: 
https://github.com/atilaneves/include

Re: -betterC is amazing, make (/keep making) it more sophisticated!

[Walter Bright via Digitalmars-d]

On 3/21/2018 3:48 PM, Seb wrote:

I heard that Walter recently ported his DMC++ to D


Yes, indeed: https://github.com/DigitalMars/Compiler

I want to convert the back end to D, too, but am blocked by 
https://github.com/dlang/dmd/pull/7714


Seb, can you help with that?

[Issue 18644] [dip1000] escape of outer local not detected

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18644

--- Comment #4 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/dmd

https://github.com/dlang/dmd/commit/51565f362fd318ceb0cf94519819c3232b1adb22
fix Issue 18644 - [dip1000] escape of outer local not detected

https://github.com/dlang/dmd/commit/0e0df72c1d3b70cb2f1a7fb2f6b26ac7bb8dcc39
Merge pull request #8062 from WalterBright/fix18644

fix Issue 18644 - [dip1000] escape of outer local not detected

--

[Issue 18644] [dip1000] escape of outer local not detected

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18644

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: -betterC is amazing, make (/keep making) it more sophisticated!

[jmh530 via Digitalmars-d]

On Wednesday, 21 March 2018 at 22:48:36 UTC, Seb wrote:


I heard that Walter recently ported his DMC++ to D and I heard 
that someone was working on this, so chances aren't too bad 
that this might happen ;-)




You might check out Atila's github page (I don't think it's ready 
for release yet).

Re: recursive template expansion: Why does this not compile?

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, March 21, 2018 22:50:32 Ontonator via Digitalmars-d-learn 
wrote:
> On Wednesday, 21 March 2018 at 06:39:22 UTC, ag0aep6g wrote:
> > On 03/21/2018 01:47 AM, Ontonator wrote:
> >> The following code does not compile:
> >>> [...]
> >>
> >> It gives the error:
> >>> [...]
> >>
> >> The aliases do not have to be aliases, as long as there is
> >> some reference to the class (e.g. method and variable
> >> declarations also work). What exactly is the reason for this
> >> error?
> >
> > Compiler bug. It works when you move the declaration of `B`
> > before the one of `A`. Order shouldn't matter there.
>
> Is this a known bug, or should I report it?

If you can't find it searching on bugzilla, report it.

- Jonathan M Davis

Re: D's type declarations seem to read right to left.

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, March 21, 2018 20:07:09 tipdbmp via Digitalmars-d-learn wrote:
> D's type declarations seem to read right to left.
>
>
> int an_integer;
>
> int[10] an_array_of_10_integers;
> int[10]* a_pointer_to_an_array_of_10_integers =
> _array_of_10_integers;
>
> int*[10] an_array_of_10_pointers_to_integers;
> int*[10]* a_pointer_to_an_array_of_10_pointers_to_integers =
> _array_of_10_pointers_to_integers;
>
> int[3][2] an_array_of_2_arrays_of_3_integers;
> int[string] a_hashtable_with_string_keys_and_integer_values;
>
> int[3][string][2]
> an_array_of_2_hashtables_with_string_keys_and_array_of_3_integers_values;
>
> int function(float)
> a_pointer_to_a_function_that_takes_a_float_and_returns_an_integer;
> int function(float)[10]
> an_array_of_10_functions_that_take_floats_and_return_integers;
>
>
> I think this is a big improvement over C's "spiral" way of
> reading types: http://www.unixwiz.net/techtips/reading-cdecl.html
> I guess it could've been left to right, but... it's okay.

In principle, D types read in more or less the same way as C types. The main
differences are that we simplifed how function pointers are declared (making
them more like function prototypes) and got rid of the types on the
right-hand side of the name. e.g.

int[10] arr;

instead of

int arr[10];

Both read outward from the type, but the D way is then right-to-left in this
case, whereas the C way is left-to-right even though they're both reading
outward from the type. So, this makes it look like D reads right-to-left,
but it'st still reading outward from the type. e.g. if you look at how
dynamic arrays are declared, it's still outward from the type, not
right-to-left. e.g.

auto foo = new int[][](10, 14);
assert(foo.length == 10);
assert(foo[0].length == 14);

vs

int[10][14] foo;
assert(foo.length == 14);
assert(foo[0].length == 10);

The fact that parens are used for const does muck with things a bit though.
In C/C++, you have

const int* p;

which is equivalent to

int const* p;

but for whatever reason, both are allowed. The second one reads outward from
the type, whereas the first one essentially breaks those rules a bit. And D
essentially went with the first one, because the equivalent would be

const(int)* p;

and there's no way to put the const on the right. So, while the pointer
portion of the type does read outward from the type, const doesn't really.

So, overall, D cleaned things up, but it didn't actually make them fully
consistent either.

- Jonathan M Davis

[Issue 18634] std.container.rbtree does not work with delegate comparators

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18634

--- Comment #2 from github-bugzi...@puremagic.com ---
Commits pushed to master at https://github.com/dlang/phobos

https://github.com/dlang/phobos/commit/a3f8992766b1baf4d4dd2d57043a734db29c221b
Fix issue 18634 - support for delegate comparators in rbtree

RedBlackTree.opEquals() was preventing the use of delegates by
explicitly forcing the equal() check to go through a function.

https://github.com/dlang/phobos/commit/63397e57a95c33dd3f8207822cff34bbabbbcfd4
Merge pull request #6304 from chvor/rbtree-delegate

Fix issue 18634 - support for delegate comparators in rbtree
merged-on-behalf-of: Sebastian Wilzbach 

--

Re: recursive template expansion: Why does this not compile?

[Ontonator via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 06:39:22 UTC, ag0aep6g wrote:

On 03/21/2018 01:47 AM, Ontonator wrote:

The following code does not compile:

[...]


It gives the error:

[...]


The aliases do not have to be aliases, as long as there is 
some reference to the class (e.g. method and variable 
declarations also work). What exactly is the reason for this 
error?


Compiler bug. It works when you move the declaration of `B` 
before the one of `A`. Order shouldn't matter there.


Is this a known bug, or should I report it?

[Issue 18634] std.container.rbtree does not work with delegate comparators

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18634

github-bugzi...@puremagic.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--

Re: -betterC is amazing, make (/keep making) it more sophisticated!

[Seb via Digitalmars-d]

On Wednesday, 21 March 2018 at 22:33:37 UTC, Aedt wrote:
I've been playing with D for a while. I usually 
write/maintain/contribute to C and C++ applications for *nix. D 
is low key amazing, it has

- C standard library in the standard
- continually improving betterC idioms
- built in version blocks, unit test and debug blocks
- painless doc gen
- modules and painless dependency handling
- linter, formatting tool and suggestion tool independent of 
editors


Thanks a lot for these kind words!

Now if D manages all of the following it's going to be even 
better:
- complete porting the C99 compliant C compiler fornt end to 
the D compiler so you can seamlessly just import C headers 
(like C++)


I heard that Walter recently ported his DMC++ to D and I heard 
that someone was working on this, so chances aren't too bad that 
this might happen ;-)



- Improve shared library support


What do you miss / are referring to?

Don't know about other C programmers but if D grants me to 
write C with modules, doc gen and dep handling, I can switch 
any day! But I need to be able to use tons of C libraries 
without having to writing wrappers for them.


Not sure whether you are aware of these two projects?

https://github.com/jacob-carlborg/dstep (converts C headers to D 
headers auto-magically)


https://github.com/Syniurge/Calypso (LDC fork which allows direct 
interfacing with C/C++ code)


For my use cases dstep works nicely.

[Issue 17906] Use of delete should be allowed without a deprecation in a deprecated scope

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17906

Seb  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #5 from Seb  ---
> I guess this bug report is about Mathias Lang's problem now.

PR https://github.com/dlang/dmd/pull/8066

(and changed the title accordingly)

--

[Issue 17906] Use of delete should be allowed without a deprecation in a deprecated scope

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17906

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com
Summary|Deprecated functions should |Use of delete should be
   |not cause deprecated|allowed without a
   |warnings for using  |deprecation in a deprecated
   |deprecated features |scope

--

-betterC is amazing, make (/keep making) it more sophisticated!

[Aedt via Digitalmars-d]

I've been playing with D for a while. I usually 
write/maintain/contribute to C and C++ applications for *nix. D 
is low key amazing, it has

- C standard library in the standard
- continually improving betterC idioms
- built in version blocks, unit test and debug blocks
- painless doc gen
- modules and painless dependency handling
- linter, formatting tool and suggestion tool independent of 
editors
Now if D manages all of the following it's going to be even 
better:
- complete porting the C99 compliant C compiler fornt end to the 
D compiler so you can seamlessly just import C headers (like C++)

- Improve shared library support

Don't know about other C programmers but if D grants me to write 
C with modules, doc gen and dep handling, I can switch any day! 
But I need to be able to use tons of C libraries without having 
to writing wrappers for them.


Thank you.

Re: Slow start up time of runtime (correction: Windows real-time protection)

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 13:26:48 UTC, HeiHon wrote:
In Windows Security Center Settings (where you can disable 
realtime scan) there is also an entry "Exclusions" (in german 
windows "Ausschlüsse").
I added exclusions for the folder, where I installed dmd and 
ldc and I added an exclusion for the folder, where I compile my 
D programs. Now startup of dmd and freshly compiled programs is 
fast again.


Awesome tip!

Re: Need example of usage DerelictPQ

[number via Digitalmars-d-learn]

On Wednesday, 24 December 2014 at 11:56:40 UTC, Suliman wrote:
Could anybody provide any simple examples of usage DerelictPQ. 
I do not have experience of C, and I can't understand how to 
use this driver.


I need just basics like connect, select and insert.

http://code.dlang.org/packages/derelict-pq

thanks!



A bit late, but maybe useful for others, and googling 'dlang 
derelict postgres example' brings you here..


The default ubuntu (16.04) postgres version caused runtime errors 
for me (DerelictPQ.load()), what worked was installation from 
here:

https://www.postgresql.org/download/linux/ubuntu/

the example expects a postgres user/role 'sammy' with password 
'sammypw' and a database 'sammy' with a table as shown in 
comments and set up as here:

https://www.digitalocean.com/community/tutorials/how-to-install-and-use-postgresql-on-ubuntu-16-04

if you don't specify a host at PQconnectdb() then you might get 
an error

'Peer authentication failed for user "sammy"'
when you run the binary as a OS user different from 'sammy', or 
you would have to run the program as the postgres user like

sudo -iu sammy /path/to/prog

 dub.json
{
"name": "prog",
"targetType": "executable",
"sourceFiles": [ "prog.d" ],
"dependencies": {
"derelict-pq": "~>2.2.0"
}
}

 prog.d
import core.stdc.stdlib;
import std.stdio;
import std.conv;
import derelict.pq.pq;

/*
CREATE TABLE playground (
equip_id serial PRIMARY KEY,
type varchar (50) NOT NULL,
color varchar (25) NOT NULL,
	location varchar(25) check (location in ('north', 'south', 
'west', 'east', 'northeast', 'southeast', 'southwest', 
'northwest')),

install_date date
);

	INSERT INTO playground (type, color, location, install_date) 
VALUES ('slide', 'blue', 'south', '2014-04-28');
	INSERT INTO playground (type, color, location, install_date) 
VALUES ('swing', 'yellow', 'northwest', '2010-08-16');


 */

int main(string[] args)
{
int retval = EXIT_SUCCESS;

DerelictPQ.load();

	PGconn* conn = PQconnectdb("user = 'sammy' password = 'sammypw' 
dbname = 'sammy' host = '127.0.0.1'");

if (PQstatus(conn) != CONNECTION_OK)
{
		writefln("ERROR (connection): %s", 
to!string(PQerrorMessage(conn)));

retval = EXIT_FAILURE;
}
else
{
writeln("OK (connection)");

PGresult* result = PQexec(conn, "select * from playground");
if (PQresultStatus(result) != PGRES_TUPLES_OK)
{
			writefln("ERROR (result): %s", 
to!string(PQerrorMessage(conn)));

retval = EXIT_FAILURE;

}
else
{
writeln("OK (result)");

int nbFields = PQnfields(result);
writeln("nbFields: ", nbFields);

int nbRows = PQntuples(result);
writeln("nbRows: ", nbRows);

for (int f; f < nbFields; f++)
{
writef("%16s", to!string(PQfname(result, f)));
}
writeln("");

for (int r; r < nbRows; r++)
{
for (int f; f < nbFields; f++)
{
ubyte* ub = 
cast(ubyte*)(PQgetvalue(result, r, f));
int len = PQgetlength(result, r, f);
char[] c = cast(char[])ub[0..len];
string s = to!string(c);
writef("%16s", s);
}
writeln("");
}
}
PQclear(result);
}
PQfinish(conn);

return retval;
}



If someone has a better way to convert the PQgetvalue() to 
string, i'm interested :)

The functions are as follows:
alias da_PQgetvalue = const(ubyte)* 
function(const(PGresult)*,int,int);

alias da_PQgetlength = int function(const(PGresult)*,int,int);

have a nice day

Re: Slow start up time of runtime (correction: Windows real-time protection)

[Dennis via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 13:26:48 UTC, HeiHon wrote:
I added exclusions for the folder, where I installed dmd and 
ldc and I added an exclusion for the folder, where I compile my 
D programs. Now startup of dmd and freshly compiled programs is 
fast again.


I've done this too now, thanks for the tip!

Re: Flaw in DIP1000? Returning a Result Struct in DIP1000

[jmh530 via Digitalmars-d]

On Wednesday, 21 March 2018 at 17:13:40 UTC, Jack Stouffer wrote:

[snip]

How can we return non-scoped result variables constructed from 
scope variables without copies?


If you re-wrote this so that it just had pointers, would it be 
simpler?


Below is my attempt, not sure it's the same...

struct Foo
{
int b;
}

struct Bar
{
Foo* a;
}

Bar bar(scope int* a) @safe
{
Bar res;
Foo x = Foo(*a);
res.a = 
return res;
}

void main() @safe
{
int x = 1;
bar();
}

[Issue 18461] codegen bug - OPbt expressions and assignments to ambiguous symbols

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18461

--- Comment #11 from Walter Bright  ---
https://github.com/dlang/dmd/pull/8065

--

[Issue 18461] codegen bug - OPbt expressions and assignments to ambiguous symbols

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18461

Walter Bright  changed:

   What|Removed |Added

Summary|codegen bug in dmd -|codegen bug - OPbt
   |assignments to ambiguous|expressions and assignments
   |symbols |to ambiguous symbols

--

Re: does it scale to have 1 person approve of all phobos additions?

[Andrei Alexandrescu via Digitalmars-d]

On 03/20/2018 06:56 PM, Meta wrote:
Does it make sense? In my opinion, no, but according to Andrei be has 
tried being less hands-on before and it resulted in measurably worse 
quality code in Phobos; thus, he re-established himself as the 
gatekeeper. I agree that it doesn't scale and think that at this point, 
it's probably actively hurting Phobos because a lot of good work sits 
for so long and eventually becomes abandoned.


On the other hand, it could become much worse for Phobos if he was 
entirely hands off and delegated its shepherding to a larger group of 
core contributors. A balance has to be struck somewhere... Maybe a 
hypothetical group like this needs to be trained by Andrei such that he 
can trust them to properly guide Phobos' development, and will only come 
to him with the really big, important stuff.


Thanks for this comment (which is eerily accurate), and thanks Timothee 
for raising the matter.


It is an ongoing burden to be the decider on new API additions to 
Phobos; indeed I have taken this responsibility because I have attempted 
to relinquish it in the past, with negative results. It is definitely 
not something that I prefer or enjoy, and am permanently on the lookout 
for people with similar design sensibilities to share the burden with. 
The door is open, if not kicked off its hinges. Please take note!


That said, the question of scalability is a bit misplaced. API additions 
to Phobos are rare and long-lasting; it is entirely appropriate to let 
them ripe a little. In contrast, various improvements to Phobos - over 
100 of them - only need good reviews, and are obviously bottlenecked by 
our general lack of reviewers. That's our real bottleneck. It seems 
appropriate to ask the question why we'd ask for acceleration of API 
additions without improving response for other work.


I just reviewed https://github.com/dlang/phobos/pull/6178. As I'd 
expected, it's good work - which is exactly the matter. Good work in a 
submission means most review work. It's not bad work, which can be 
easily rejected. And it's not brilliant work, which can be easily 
accepted. The PR has bugs and quality issues that any reviewer could 
find and provide feedback on. It's not in the state where it's 
bottlenecked by just a stamp of approval.


Naming is a matter I wanted to defer having a debate on. We should call 
the facility staticArray to prevent an imaginary conversation like this:


Q: "So I have a range here, how do I get an array from it?"

A: "Easy, just append .array to it and you're done."

Q. "Cool! Now I need a static array. Wait! Don't tell me, don't tell 
me... staticArray is what I should look for!"


A: "Um, no, sorry. That's called asStatic."

Besides, [1,2].asStatic may be guessed right by a reader, but 
myrange.asStatic!2 most likely not.



Thanks,

Andrei

Re: OK, I'm stumped on this one: dstep, struct, mixin, bitfields

[Jacob Carlborg via Digitalmars-d-learn]

On 2018-03-21 20:30, Russel Winder wrote:


Thanks to Adam and Ali, it was clear and obvious.


Please report and issue so it's not forgotten.

--
/Jacob Carlborg

Re: Packages and module import

[Jacob Carlborg via Digitalmars-d-learn]

On 2018-03-21 17:06, Russel Winder wrote:


No I wasn't. And it works a treat.


Cool :). I recommend having a look at the changelog and the usage 
information (--help).


--
/Jacob Carlborg

Re: D's type declarations seem to read right to left.

[Nick Sabalausky via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 20:07:09 UTC, tipdbmp wrote:

D's type declarations seem to read right to left.


int an_integer;

int[10] an_array_of_10_integers;
int[10]* a_pointer_to_an_array_of_10_integers = 
_array_of_10_integers;


int*[10] an_array_of_10_pointers_to_integers;
int*[10]* a_pointer_to_an_array_of_10_pointers_to_integers = 
_array_of_10_pointers_to_integers;


int[3][2] an_array_of_2_arrays_of_3_integers;
int[string] a_hashtable_with_string_keys_and_integer_values;

int[3][string][2] 
an_array_of_2_hashtables_with_string_keys_and_array_of_3_integers_values;


int function(float) 
a_pointer_to_a_function_that_takes_a_float_and_returns_an_integer;
int function(float)[10] 
an_array_of_10_functions_that_take_floats_and_return_integers;



I think this is a big improvement over C's "spiral" way of 
reading types: 
http://www.unixwiz.net/techtips/reading-cdecl.html

I guess it could've been left to right, but... it's okay.


The way I see it, English "of" flips its operands backwards 
compared to English's [adjective][noun] syntax:


int an_integer;
int* an_integer_pointer;
int[] an_integer_array;
int[3]* an_integer_array(length 3)_pointer;

But granted, in English, "of" is more scalable than 
[adjective][noun].

Re: D's type declarations seem to read right to left.

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 20:07:09 UTC, tipdbmp wrote:
I think this is a big improvement over C's "spiral" way of 
reading types:


Yes, D is perfect and has achieved sanity where before there was 
none.


You can read basically anything with little knowledge.

void function()[] array_of_funtions;
int[]*[]*[string] assoctiavive array of pointers to arrays of 
pointers to arrays of ints.

D's type declarations seem to read right to left.

[tipdbmp via Digitalmars-d-learn]

D's type declarations seem to read right to left.


int an_integer;

int[10] an_array_of_10_integers;
int[10]* a_pointer_to_an_array_of_10_integers = 
_array_of_10_integers;


int*[10] an_array_of_10_pointers_to_integers;
int*[10]* a_pointer_to_an_array_of_10_pointers_to_integers = 
_array_of_10_pointers_to_integers;


int[3][2] an_array_of_2_arrays_of_3_integers;
int[string] a_hashtable_with_string_keys_and_integer_values;

int[3][string][2] 
an_array_of_2_hashtables_with_string_keys_and_array_of_3_integers_values;


int function(float) 
a_pointer_to_a_function_that_takes_a_float_and_returns_an_integer;
int function(float)[10] 
an_array_of_10_functions_that_take_floats_and_return_integers;



I think this is a big improvement over C's "spiral" way of 
reading types: http://www.unixwiz.net/techtips/reading-cdecl.html

I guess it could've been left to right, but... it's okay.

Re: Flaw in DIP1000? Returning a Result Struct in DIP1000

[Jack Stouffer via Digitalmars-d]

On Wednesday, 21 March 2018 at 18:50:59 UTC, Jonathan M Davis 
wrote:
The struct being returned would need to be marked with scope 
(or its members marked with scope) such that the compiler 
treated the result as containing values from the function 
arguments. I don't know whether that's possible with DIP 1000 
as-is


Not as far as I can tell. Marking it as scope in the function 
body means it can't be returned, and marking the array in 
GetoptResult as scope results in a syntax error.


In this particular case, it may make more sense to just let 
getopt be @safe on its own and just let the caller mark all of 
the uses of & as @trusted.


This is thankfully the case currently.

If it's possible to mark GetoptResult with scope such that we 
can use scope without copying, then great, but if it's not, 
then I'm inclined to argue that we should just make sure that 
getopt itself is @safe and not worry about whether the caller 
is doing anything @system to call getopt or not.


Regardless, this does raise a potential issue with scope and 
user-defined return types, and we should explore how possible 
it is for DIP 1000 to solve that problem without forcing copies 
that wouldn't be necessary in @system code.


My cause for alarm with this limitation is this is one of the 
issues (taking address of locals safely) that DIP1000 was 
designed to solve. If, in practice, DIP1000 code can't be used 
for this case when the code become sufficiently complex, then we 
have a real problem on our hands.

Re: Cumulative code coverage?

[H. S. Teoh via Digitalmars-d]

On Wed, Mar 21, 2018 at 12:35:08PM -0700, H. S. Teoh via Digitalmars-d wrote:
[...]
> Cool, passing --DRT-covopt="merge:1" did the trick.
[...]

Speaking of which, are the --DRT-* options documented anywhere?? I
don't even know where to begin to look, besides in the druntime code
itself.


T

-- 
Unix was not designed to stop people from doing stupid things, because that 
would also stop them from doing clever things. -- Doug Gwyn

Re: OK, I'm stumped on this one: dstep, struct, mixin, bitfields

[H. S. Teoh via Digitalmars-d-learn]

On Wed, Mar 21, 2018 at 07:30:28PM +, Russel Winder via Digitalmars-d-learn 
wrote:
[...]
> But :-(
> 
> Why does version have to be a keyword?
[...]

version(all) { ... }
version(none) { ... }
version(Posix) { ... }
version(Windows) { ... }

But yeah, using "version" for this purpose makes the very common
identifier "version" unavailable for use.  I've been bitten by this
multiple times.

auto version = getVersion();// NG
auto ver = getVersion();// OK

struct PacketHeader {
ushort version; // NG
ushort ver; // OK
}

:-(


T

-- 
Маленькие детки - маленькие бедки.

Re: Flaw in DIP1000? Returning a Result Struct in DIP1000

[Jack Stouffer via Digitalmars-d]

On Wednesday, 21 March 2018 at 19:15:41 UTC, Meta wrote:
But the compiler doesn't like that. However, I _did_ get it 
working by doing this:


GetoptResult getopt(T...)(scope T opts) @safe
{
return GetoptResult([Option(opts[0], opts[1])]);
}

Which is not ideal, obviously, but the notion that some code 
has to be rewritten to accomodate ownership semantics is not a 
new one; one of the major complaints I've seen about Rust is 
that it requires you to adjust your coding style to satisfy the 
borrow checker.


The problem here is that it's impossible to apply this to the 
actual getopt code :/

Re: Cumulative code coverage?

[H. S. Teoh via Digitalmars-d]

On Wed, Mar 21, 2018 at 05:34:58PM +, Seb via Digitalmars-d wrote:
> On Wednesday, 21 March 2018 at 16:39:48 UTC, H. S. Teoh wrote:
> > Is it possible to get cumulative code coverage using dmd? I.e.,
> > accumulate code coverage stats over a series of runs from an
> > external test suite.
[...]
> Yes, either set dmd_coverSetMerge(true) or pass --DRT-covopt "merge:1"
> to your program.
[...]

Cool, passing --DRT-covopt="merge:1" did the trick.

Thanks!


T

-- 
Bare foot: (n.) A device for locating thumb tacks on the floor.

Re: OK, I'm stumped on this one: dstep, struct, mixin, bitfields

[Russel Winder via Digitalmars-d-learn]

On Wed, 2018-03-21 at 18:11 +, Adam D. Ruppe via Digitalmars-d-
learn wrote:
> On Wednesday, 21 March 2018 at 18:00:38 UTC, Russel Winder wrote:
> > ubyte, "version", 5,
> 
> 
> version is a D keyword, so I would suggest trying "version_" 
> there instead and see if it works. (I'm guessing btw, the error 
> message was way to long and illegible, but this is an easy first 
> guess anyway)

On Wed, 2018-03-21 at 11:14 -0700, Ali Çehreli via Digitalmars-d-learn
wrote:
[…]
> 
> I think it's because 'version' is a D keyword. :)
> 
> Ali
> 

Thanks to Adam and Ali, it was clear and obvious. 

But :-(

Why does version have to be a keyword?

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

Re: strip() and formattedRead()

[realhet via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 18:50:18 UTC, Adam D. Ruppe wrote:

On Wednesday, 21 March 2018 at 18:44:12 UTC, realhet wrote:
Compiling this I get an error: "formattedRead: cannot deduce 
arguments from (string, string, float, float, float)"


What compiler version are you using? The newest versions allow 
this code, though the old ones require an intermediate variable 
to satisfy the `ref` requirement on formattedRead (it will want 
to update that variable to advance it past the characters it 
read).


so either update your version, or just give an and use an 
intermediate:


string s = "".strip;
formattedRead(s, )


Thank both of You! You guys are super helpful. (I'm learning from 
Ali's book and after these instant answers I was like: "I'm not 
worthy" :D)


So I had v2077.1 previously, now I've installed 2079.0 and it all 
works great.

[Issue 17906] Deprecated functions should not cause deprecated warnings for using deprecated features

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17906

--- Comment #4 from FeepingCreature  ---
Huh, seems like you're right. Not sure if this was fixed or it always worked
that way. Either way, good to know!

I guess this bug report is about Mathias Lang's problem now.

--

Re: #dbugfix 17592

[12345swordy via Digitalmars-d]

On Wednesday, 21 March 2018 at 14:04:58 UTC, Adam D. Ruppe wrote:

On Wednesday, 21 March 2018 at 13:39:28 UTC, 12345swordy wrote:
You can simply check the .dtor symbols at compile time to see 
if every .dtor symbol from child to root have a .dtor that 
have the @nogc attribute


In Simen's example, the child information is not available at 
compile time. This line here:


A a = new B();

discards the static type. The compiler could probably cheat and 
figure it out anyway in this example, but suppose:


---
class A {
 @nogc ~this() {}
 }

class B : A {
~this() {}
}

class C : A {
@nogc ~this() {}
}


A build(string name) {
   if(name == "B") return new B();
   else return new C();
}

void main() {
A a = build(readln());
destroy(a);
}
---


This is very clearly a runtime decision: whether it is B or C 
is determined by user input. But B's dtor is not @nogc... and 
there's thus no way to tell for sure if destroy(a) is or not, 
since it will call the child class based on the runtime 
decision.


so it is impossible for the compiler to know which child class 
is actually called until runtime... too late for a compile-time 
nogc check.


That seems to be it's own separate problem, as it involves 
generating dynamic types at run-time, which it needs run-time 
equivalent of attribute checking. My example assumes that the 
classes created are static types not dynamic types. Besides I do 
not like implied conversions when it comes classes, as I believe 
it is a horrible idea.

Re: Flaw in DIP1000? Returning a Result Struct in DIP1000

[Meta via Digitalmars-d]

On Wednesday, 21 March 2018 at 17:13:40 UTC, Jack Stouffer wrote:
Consider this example simplified from this PR 
https://github.com/dlang/phobos/pull/6281


--
struct GetoptResult
{
Option[] options;
}

struct Option
{
string optShort;
string help;
}

GetoptResult getopt(T...)(scope T opts) @safe
{
GetoptResult res;
auto o = Option(opts[0], opts[1]);
res.options ~= o;
return res;
}

void main() @safe
{
bool arg;
getopt("arg", "info", );
}
--

$ dmd -dip1000 -run main.d

--
main.d(16): Error: scope variable o assigned to non-scope res
main.d(23): Error: template instance `onlineapp.getopt!(string, 
string, bool*)` error instantiating

--

The only way I've found to make the code compile and retain the 
pre-dip1000 behavior is to change the Option construction to


--
auto o = Option(opts[0].idup, opts[1].idup);
--

How can we return non-scoped result variables constructed from 
scope variables without copies?


I thought that maybe adding a function to Option and marking it 
as `scope` would work:


struct GetoptResult
{
Option[] options;
void addOptions(scope Option opt) @safe scope
{
//Error: scope variable opt assigned to non-scope this
options ~= opt;
}
}

But the compiler doesn't like that. However, I _did_ get it 
working by doing this:


GetoptResult getopt(T...)(scope T opts) @safe
{
return GetoptResult([Option(opts[0], opts[1])]);
}

Which is not ideal, obviously, but the notion that some code has 
to be rewritten to accomodate ownership semantics is not a new 
one; one of the major complaints I've seen about Rust is that it 
requires you to adjust your coding style to satisfy the borrow 
checker.

[Issue 17906] Deprecated functions should not cause deprecated warnings for using deprecated features

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17906

--- Comment #3 from Mathias Lang  ---
Could you paste the message generated ? In your example, I would expect a
deprecation to be generated for the import, but not on the actual function
declaration.

--

[Issue 17906] Deprecated functions should not cause deprecated warnings for using deprecated features

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17906

--- Comment #2 from FeepingCreature  ---
That's also true, but my example refers specifically to deprecated functions
using deprecated types. However, I labelled the bug report wrong, and your
example actually fits it better. :)

--

Re: why does this compile fine, but dies when you run it.

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 18:53:39 UTC, steven kladitis 
wrote:

int[] array3;
array3[0]=4;


array3 is empty. You are trying to set a value that doesn't 
exist..

[Issue 18645] New: DMD segmentation fault

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=18645

  Issue ID: 18645
   Summary: DMD segmentation fault
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: mihails.strasuns.contrac...@sociomantic.com

DMD 2.079 (but also happens with earlier versions). Happens in large private
codebase, will try to dustmite later this week. For now full stack trace: 

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00593a1c in BinExp::setNoderefOperands() (this=0x7f14983db410)
at dmd/expression.d:5036
5036if (e1.op == TOK.dotIdentifier)
(gdb) bt
#0  0x00593a1c in BinExp::setNoderefOperands() (this=0x7f14983db410)
at dmd/expression.d:5036
#1  0x005b2dbb in ExpressionSemanticVisitor::visit(CmpExp*)
(this=0x7ffdec919508, 
exp=0x7f14983db410) at dmd/expressionsem.d:8714
#2  0x00597172 in CmpExp::accept(Visitor*) (this=0x7f14983db410,
v=0x7ffdec919508)
at dmd/expression.d:6841
#3  0x005b4e5b in expressionSemantic(Expression*, Scope*)
(e=0x7f14983db410, 
sc=0x7f149837b840) at dmd/expressionsem.d:9437
#4  0x00535e9e in EnumDeclaration::getMaxMinValue(Loc const&,
Identifier*) (
this=0x7f149b4489d0, loc=..., id=0x7f14a04ab3a0) at dmd/denum.d:235
#5  0x00607854 in TypeEnum::getProperty(Loc const&, Identifier*, int)
(this=0x2365700, 
loc=..., ident=0x7f14a04ab3a0, flag=0) at dmd/mtype.d:7874
#6  0x005675d2 in DsymbolSemanticVisitor::visit(EnumMember*)
(this=0x7ffdec919930, 
em=0x7f149b448d10) at dmd/dsymbolsem.d:2044
#7  0x0053649a in EnumMember::accept(Visitor*) (this=0x7f149b448d10,
v=0x7ffdec919930)
at dmd/denum.d:382
#8  0x00561459 in dsymbolSemantic(Dsymbol*, Scope*)
(dsym=0x7f149b448d10, sc=0x7f149837b840)
at dmd/dsymbolsem.d:103
#9  0x00566bf2 in DsymbolSemanticVisitor::visit(EnumDeclaration*)
(this=0x7ffdec919ab0, 
ed=0x7f149b4489d0) at dmd/dsymbolsem.d:1868
#10 0x00536242 in EnumDeclaration::accept(Visitor*)
(this=0x7f149b4489d0, v=0x7ffdec919ab0)
at dmd/denum.d:324
#11 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*)
(dsym=0x7f149b4489d0, sc=0x7f149836fcc0)
at dmd/dsymbolsem.d:103
#12 0x00565193 in
DsymbolSemanticVisitor::attribSemantic(AttribDeclaration*) (
this=0x7ffdec919bb0, ad=0x7f149b4492f0) at dmd/dsymbolsem.d:1290
#13 0x005651f5 in DsymbolSemanticVisitor::visit(AttribDeclaration*)
(this=0x7ffdec919bb0, 
atd=0x7f149b4492f0) at dmd/dsymbolsem.d:1302
#14 0x0063b757 in ParseTimeVisitor::visit(ProtDeclaration*)
(
this=0x7ffdec919bb0, s=0x7f149b4492f0) at dmd/parsetimevisitor.d:71
#15 0x00507676 in ProtDeclaration::accept(Visitor*)
(this=0x7f149b4492f0, v=0x7ffdec919bb0)
at dmd/attrib.d:605
#16 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*)
(dsym=0x7f149b4492f0, sc=0x7f149b449560)
at dmd/dsymbolsem.d:103
#17 0x0056652e in DsymbolSemanticVisitor::visit(Module*)
(this=0x7ffdec919c60, 
m=0x7f149b447f30) at dmd/dsymbolsem.d:1677
#18 0x005521aa in Module::accept(Visitor*) (this=0x7f149b447f30,
v=0x7ffdec919c60)
at dmd/dmodule.d:1322
#19 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*)
(dsym=0x7f149b447f30, sc=0x0)
at dmd/dsymbolsem.d:103
#20 0x00564779 in DsymbolSemanticVisitor::visit(Import*)
(this=0x7ffdec919f80, 
imp=0x7f149b623a30) at dmd/dsymbolsem.d:1146
#21 0x0053703b in Import::accept(Visitor*) (this=0x7f149b623a30,
v=0x7ffdec919f80)
at dmd/dimport.d:309
#22 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*)
(dsym=0x7f149b623a30, sc=0x7f149b63ef10)
at dmd/dsymbolsem.d:103
#23 0x0056652e in DsymbolSemanticVisitor::visit(Module*)
(this=0x7ffdec91a030, 
m=0x7f149b623170) at dmd/dsymbolsem.d:1677
#24 0x005521aa in Module::accept(Visitor*) (this=0x7f149b623170,
v=0x7ffdec91a030)
at dmd/dmodule.d:1322
#25 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*)
(dsym=0x7f149b623170, sc=0x0)
at dmd/dsymbolsem.d:103
#26 0x00564779 in DsymbolSemanticVisitor::visit(Import*)
(this=0x7ffdec91a350, 
imp=0x7f149b61d130) at dmd/dsymbolsem.d:1146
#27 0x0053703b in Import::accept(Visitor*) (this=0x7f149b61d130,
v=0x7ffdec91a350)
at dmd/dimport.d:309
#28 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*)
(dsym=0x7f149b61d130, sc=0x7f149b622e10)
at dmd/dsymbolsem.d:103
#29 0x0056652e in DsymbolSemanticVisitor::visit(Module*)
(this=0x7ffdec91a400, 
m=0x7f149b61cdd0) at dmd/dsymbolsem.d:1677
#30 0x005521aa in Module::accept(Visitor*) (this=0x7f149b61cdd0,
v=0x7ffdec91a400)
at dmd/dmodule.d:1322
#31 0x00561459 in dsymbolSemantic(Dsymbol*, Scope*)
(dsym=0x7f149b61cdd0, sc=0x0)
at dmd/dsymbolsem.d:103
#32 0x00564779 in 

Calling Windows Command

[Vino via Digitalmars-d-learn]

Hi All,

 Request your help in calling the windows command to delete all 
file and folders recursively as the D function rmdirRecurse does 
not delete file in the permission of the file is readonly in 
windows 2008 R2


import std.process: execute;
import std.array: empty;
auto RemoveDir () (
auto dFiles = "C:\\Temp\Test1";
auto Step = "run";
if (Step == "run" && !dFiles.empty) {
version(Windows)
 {
  foreach(d; dFiles) {
  execute(["rmdir.exe","-command", "/S /Q", `~d~`]); } } } 
return dFiles;

)

void main () {
writeln(RemoveDir);
}

From,
Vino.N

why does this compile fine, but dies when you run it.

[steven kladitis via Digitalmars-d-learn]

import std.stdio;

void main(){
int[3] array1 = [ 10, 20, 30 ];
auto array2 = array1; // array2's elements are different
// from array1's
array2[0] = 11;
int[] array3;
//array4[0]=3;
array3[0]=4;
auto array4 = array3;

writeln(array1,'\n',array2,'\n',array3,'\n',array4);
}


-- windows 7 64 bit ( os ) dmd 2.079.0
-- thanks
-- Steven

Re: strip() and formattedRead()

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 18:44:12 UTC, realhet wrote:
Compiling this I get an error: "formattedRead: cannot deduce 
arguments from (string, string, float, float, float)"


What compiler version are you using? The newest versions allow 
this code, though the old ones require an intermediate variable 
to satisfy the `ref` requirement on formattedRead (it will want 
to update that variable to advance it past the characters it 
read).


so either update your version, or just give an and use an 
intermediate:


string s = "".strip;
formattedRead(s, )

[Issue 17906] Deprecated functions should not cause deprecated warnings for using deprecated features

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=17906

Mathias Lang  changed:

   What|Removed |Added

 CC||mathias.l...@sociomantic.co
   ||m

--- Comment #1 from Mathias Lang  ---
Yeah, put simply, the following code:
```
deprecated void main ()
{
Object o = new Object;
delete o;
}
```

should compile with `dmd -de test.d` (DMD v2.079)

Currently this is done for other deprecated symbols: deprecated functions can
call other deprecated functions, use deprecated types, and a deprecated
aggregate can have fields of deprecated types... So it should be done for
language deprecations as well.

--

Re: Flaw in DIP1000? Returning a Result Struct in DIP1000

[Jonathan M Davis via Digitalmars-d]

On Wednesday, March 21, 2018 17:13:40 Jack Stouffer via Digitalmars-d wrote:
> Consider this example simplified from this PR
> https://github.com/dlang/phobos/pull/6281
>
> --
> struct GetoptResult
> {
>  Option[] options;
> }
>
> struct Option
> {
>  string optShort;
>  string help;
> }
>
> GetoptResult getopt(T...)(scope T opts) @safe
> {
>  GetoptResult res;
>  auto o = Option(opts[0], opts[1]);
>  res.options ~= o;
>  return res;
> }
>
> void main() @safe
> {
>  bool arg;
>  getopt("arg", "info", );
> }
> --
>
> $ dmd -dip1000 -run main.d
>
> --
> main.d(16): Error: scope variable o assigned to non-scope res
> main.d(23): Error: template instance `onlineapp.getopt!(string,
> string, bool*)` error instantiating
> --
>
> The only way I've found to make the code compile and retain the
> pre-dip1000 behavior is to change the Option construction to
>
> --
> auto o = Option(opts[0].idup, opts[1].idup);
> --
>
> How can we return non-scoped result variables constructed from
> scope variables without copies?

The struct being returned would need to be marked with scope (or its members
marked with scope) such that the compiler treated the result as containing
values from the function arguments. I don't know whether that's possible
with DIP 1000 as-is, and that could have some pretty nasty consquences when
you consider how that then limits what can be done with the return value.
Even if we _can_ mark GetoptResult as scope in some manner so that the
copying isn't necessary, you're then just pushing the problem a level up. In
this case, that's probably not a big deal, since this is stuff that's just
going to be used in main and thrown away, but in the general case, having a
struct that won't let you escape any of its members means that you're going
to either need a struct with the same layout but without scope that you can
copy the scope on to, or you're going to need to pull out each of the
members individually to copy them or do whatever you need to do to work
around scope.

My gut reaction is that issues along these lines will either prevent the use
of scope when returning user-defined types as opposed to pointers or dynamic
arrays, and/or they'll force the kind of copying that you're complaining
about. But I don't think that I understand DIP 1000 well enough to know what
it's limitations really are in cases like this. Hopefully, Walter has an
answer.

However, I suspect that we're going to find cases where scope is a blunt
enough instrument that we're going to be forced to either drop it or use
@trusted in places (though in this case, using @trusted would be completely
unreasonable, because you can't guarantee that it _isn't_ a problem for
something from the caller to escape - not without examining the caller code,
which would translate to marking the caller as @trusted, not the function
being called). Actually, I'd be very surprised if we _didn't_ have cases
like that. The question is how frequent those cases are and whether issues
like this are going to pop up enough that it's going to usually make more
sense to simply use pure and manually examine code to mark it as @trusted
rather than use scope so that the compiler can mark a bunch of stuff as
@safe for us. As long as the function doesn't return scope, we're probably
fine, but once it starts returning scope, things start getting interesting.

In this particular case, it may make more sense to just let getopt be @safe
on its own and just let the caller mark all of the uses of & as @trusted. I
know that the bug report that sparked this is trying to make using getopt
completely @safe without requiring the use of @trusted at all, but I don't
think that being forced to allocate memory is worth that, and I don't think
that mucking around with getopt to make it work with ref is worth that.
There are advantages to getopt taking pointers, and I'd rather not see
getopt's API change in a way that breaks code. If getopt itself is @safe,
then it's trivial for the caller to determine that their code is @safe in
spite of the use of & and thus either use @trusted appropriately or just not
bother, since it's in main, which usually isn't doing much fancy. So, I
_really_ don't think that making calling getopt inherently @safe is worth
code breakage if it comes to that, and I don't think that it's worth
allocating memory that we otherwise wouldn't have to allocate.

If it's possible to mark GetoptResult with scope such that we can use scope
without copying, then great, but if it's not, then I'm inclined to argue
that we should just make sure that getopt itself is @safe and not worry
about whether the caller is doing anything @system to call getopt or not.

Regardless, this does raise a potential issue with scope and user-defined
return types, and we should explore how possible it is for DIP 1000 to solve
that problem without forcing copies that wouldn't be necessary in @system
code.

- Jonathan M Davis

Re: strip() and formattedRead()

[Ali Çehreli via Digitalmars-d-learn]

On 03/21/2018 11:44 AM, realhet wrote:

   float x,y,z;
   if(formattedRead("    vertex -5.1 2.4 3.666".strip, "vertex %f %f 
%f", x, y, z)){

     writefln("v(%f, %f, %f)", x, y, z);
   }


formattedRead wants to modify the source, so it takes it by reference, 
which rvalues cannot be passed for. Make the source an lvalue (i.e. a 
proper variable):


  auto source = "vertex -5.1 2.4 3.666".strip;
  if(formattedRead(source, "vertex %f %f %f", x, y, z)){

Ali

Re: How to use an associative array with array values.

[Jesse Phillips via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 18:31:29 UTC, tipdbmp wrote:

I see. I guess the other would be:

{
int[8192] bar;
int[8192][string] foo;
foo["a"] = bar;
foo["a"][8191] = -1;
}


https://run.dlang.io/is/AK2X2t

Are you looking to use static arrays or dynamic? You can't use 
the new keyword if it static.

strip() and formattedRead()

[realhet via Digitalmars-d-learn]

Hi,

I just got this problem and since an hour can't find answer to it.

  float x,y,z;
  if(formattedRead("vertex -5.1 2.4 3.666".strip, "vertex %f 
%f %f", x, y, z)){

writefln("v(%f, %f, %f)", x, y, z);
  }

Compiling this I get an error: "formattedRead: cannot deduce 
arguments from (string, string, float, float, float)"


When I don't use .strip(), just a string literal or a string 
variable it works good.


(It fails also when I'm using UFCS)

What did I do wrong?

Re: #import mapi.h

[nkm1 via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 16:22:45 UTC, Martin Tschierschke 
wrote:
Is there an step by step introduction how to convert a C header 
of an external lib into the right extern(C){} block?


A blog post or tutorial, or chapter in a D book? (I have those 
from Packt Publishing)


(Especially I am trying to get this used with D:
Montetdb C-API 
https://www.monetdb.org/Documentation/Manuals/SQLreference/Programming/MAPI
With: 
https://github.com/snaga/monetdb/blob/master/clients/mapilib/mapi.h)


The page: https://dlang.org/spec/interfaceToC.html is known, 
but not detailed enough for me.


The easiest thing to do is to write a wrapper in C. The wrapper 
will include all necessary headers and provide some easy to use 
functions that you can call from D. Of course, you'll need to use 
a C compiler to compile it.
Anyway, this header looks very straightforwar, no particular 
tricks with the preprocessor. It should be something like this 
(untested, obviously):


import core.stdc.stdio : FILE;

enum
{
MAPI_AUTO  = 0,  /* automatic type detection */
MAPI_TINY  = 1,
MAPI_UTINY = 2,
MAPI_SHORT = 3,
MAPI_USHORT= 4,
MAPI_INT   = 5,
MAPI_UINT  = 6,
MAPI_LONG  = 7,
MAPI_ULONG = 8,
MAPI_LONGLONG  = 9,
MAPI_ULONGLONG = 10,
MAPI_CHAR  = 11,
MAPI_VARCHAR   = 12,
MAPI_FLOAT = 13,
MAPI_DOUBLE= 14,
MAPI_DATE  = 15,
MAPI_TIME  = 16,
MAPI_DATETIME  = 17,
MAPI_NUMERIC   = 18,
}

enum int PLACEHOLDER = '?';

enum
{
MAPI_SEEK_SET = 0,
MAPI_SEEK_CUR = 1,
MAPI_SEEK_END = 2,
}

enum
{
MAPI_TRACE  = 1,
MAPI_TRACE_LANG = 2,
}

alias MapiMsg = int;

enum
{
MOK =  0,
MERROR  = -1,
MTIMEOUT= -2,
MMORE   = -3,
MSERVER = -4,
}

enum
{
LANG_MAL= 0,
LANG_SQL= 2,
LANG_JAQL   = 3,
}

/* prompts for MAPI protocol */
enum int PROMPTBEG = '\001'; /* start prompt bracket */

 /* prompt: ready for new query */
const(char)* PROMPT1 = "\001\001\n".ptr;

/* prompt: more data needed */
const(char)* PROMTP2 = "\001\002\n".ptr;

/*
 * The table field information is extracted from the table headers
 * obtained from the server. This list may be extended in the 
future.

 * The type of both the 'param' and 'binding'
 * variables refer to their underlying C-type. They are used for
 * automatic type coercion between back-end and application.
 */
struct MapiStruct;
alias Mapi = MapiStruct*;

/* this definition is a straight copy from 
sql/include/sql_query.h */

enum
{
Q_PARSE = 0,
Q_TABLE = 1,
Q_UPDATE= 2,
Q_SCHEMA= 3,
Q_TRANS = 4,
Q_PREPARE   = 5,
Q_BLOCK = 6,
}

struct MapiStatement;
alias MapiHdl = MapiStatement*;

alias mapi_uint64 = ulong;
alias mapi_int64 = long;

/* three structures used for communicating date/time information 
*/
/* these structs are deliberately compatible with the ODBC 
versions

   SQL_DATE_STRUCT, SQL_TIME_STRUCT, and SQL_TIMESTAMP_STRUCT */

/* used by MAPI_DATE */
struct MapiDate
{
short year;
ushort month;
ushort day;
}

/* used by MAPI_TIME */
struct MapiTime
{
ushort hour;
ushort minute;
ushort second;
}

/* used by MAPI_DATETIME */
struct MapiDateTime
{
short year;
ushort month;
ushort day;
ushort hour;
ushort minute;
ushort second;
uint fraction;  /* in 1000 millionths of a second (10e-9) */
}

/* connection-oriented functions */
extern (C)
{
Mapi mapi_mapi(const char *host,
   int port,
   const char *username,
   const char *password,
   const char *lang,
   const char *dbname);


// and so on...
}

Re: How to use an associative array with array values.

[tipdbmp via Digitalmars-d-learn]

I see. I guess the other would be:

{
int[8192] bar;
int[8192][string] foo;
foo["a"] = bar;
foo["a"][8191] = -1;
}

[Issue 10933] findSplitBefore/After should have needle-less overloads

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10933

--- Comment #1 from Luís Marques  ---
Yup, I've ran into the same issue multiple times. This last time with the plain
findSplit; I don't recall if also with findSplitBefore/After.

This workaround works:

range.byCodeUnit.findSplit!((a, b) => a.isWhite)(" ");

Interestingly, if you use "" instead of " " it won't work, which arguably is a
bug, since the predicate doesn't even use b.

--

Re: Template condition evaluation (shortcircuit)

[H. S. Teoh via Digitalmars-d-learn]

On Wed, Mar 21, 2018 at 05:42:34PM +, rumbu via Digitalmars-d-learn wrote:
> I tried to define a template:
> 
> enum isFoo(alias T) =
> T.stringof.length >= 3 && T.stringof[0..3] == "abc";
> 
> int i;
> pragma(msg, isFoo!i);
> 
> Error: string slice [0 .. 3] is out of bounds
> Error: template object.__equals cannot deduce function from argument types
> !()(string, string), candidates are:
> [...]
> 
> Is it normal that the condition is not short circuited at first test?
> Of course, I can throw there a bunch of static ifs in an eponymous
> template, but I don't see the point of this verbosity.
[...]

The reason it's not short-circuited is because T.stringof[0..3] is
processed *before* the && is evaluated.  Basically, this:

enum isFoo(alias T) = T.stringof.length >= 3 && T.stringof[0..3] == 
"abc";

is a shorthand for this:

template isFoo(alias T)
{
enum isFoo = T.stringof.length >= 3 && T.stringof[0..3] == 
"abc";
}

T.stringof[0..3] is actually evaluated during AST expansion time,
because it's slicing a template argument list, but && isn't evaluated
until CTFE-time.

See: https://wiki.dlang.org/User:Quickfur/Compile-time_vs._compile-time


Now, arguably, we *could* make it so that && is also shortcircuited at
AST expansion time, i.e., basically lower && in this context into a
series of nested static if's instead of a CTFE expression.  But that
would probably involve some extensive changes in the compiler.


T

-- 
The trouble with TCP jokes is that it's like hearing the same joke over and 
over.

Re: OK, I'm stumped on this one: dstep, struct, mixin, bitfields

[Ali Çehreli via Digitalmars-d-learn]

On 03/21/2018 11:00 AM, Russel Winder wrote:
> The code I am playing with generated by DStep involves lots of lots of
> structs with mixin bitfields. All of them seem to compile file, except
> one. How is it that:
>
>  mixin(bitfields!(
>  ubyte, "current_next", 1,
>  ubyte, "version", 5,
>  ubyte, "one2", 2)); /* TS ID */
>
> can result in the following error. The line for "version" is 141 and
> the one for "one2" is 142.

I think it's because 'version' is a D keyword. :)

Ali

Re: OK, I'm stumped on this one: dstep, struct, mixin, bitfields

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 18:00:38 UTC, Russel Winder wrote:

ubyte, "version", 5,



version is a D keyword, so I would suggest trying "version_" 
there instead and see if it works. (I'm guessing btw, the error 
message was way to long and illegible, but this is an easy first 
guess anyway)

Re: does it scale to have 1 person approve of all phobos additions?

[Jonathan M Davis via Digitalmars-d]

On Wednesday, March 21, 2018 09:45:46 Russel Winder via Digitalmars-d wrote:
> D has the Dub repository, so why is Phobos being "batteries included" even
> an issue now?

Some folks seem to think that something _has_ to be in the standard library,
or the language is sub-standard, and some folks just want things to be in
the standard library. So, it still comes up in conversations from time to
time that X or Y should be in Phobos, but since folks aren't writing such
modules and then attempting to get them into Phobos, it's largely a moot
issue at the moment.

Also, as code.dlang.org has become more prevalent, attempts to get new
modules into Phobos have mostly disappeared.

Once I feel that dxml is ready, I'll probably try and get it into Phobos to
replace std.xml, but the only reason that I intend to do that is because
std.xml is not considered to be up to Phobos standards, and we've wanted to
replace it for years now. If there were no XML module in Phobos, I wouldn't
propose one. It doesn't necessarily hurt to have such a thing in Phobos, but
it's far from necessary.

I suspect that the main reason that we haven't seen more attempts to get
stuff into Phobos is that folks simply don't want to go through the Phobos
review process, and because they can now easily make it available on
code.dlang.org, there's a lot less incentive to try and get it into Phobos
just to make it available to others. I think that at this point, the main
advantage to having something in Phobos relates to vetting.

Any major functionality that has gone into Phobos has been reviewed by some
of the core D developers. How thoroughly it's reviewed varies, and there's
some risk of a new addition winning a vote, because folks want the
functionality, so they vote yes, but they didn't take the time to actually
review the code, but it has gotten _some_ review, which most code on
code.dlang.org has not, and in general, the stuff that goes through the
Phobos review process has been pretty thoroughly reviewed. So, the code
quality has a stamp of approval on it that stuff on code.dlang.org doesn't
have, and by something being the "official" implementation, in principle,
you can rely on it being good for the majority of use cases and generally
being a well-designed, solid solution. If the standard library has a
solution for your problem, then you can just use that and don't have to go
looking elsewhere unless you later find that something about your program
makes it so that Phobos' solution isn't going to work for you, whereas if
there's no solution in Phobos, you'll have to go digging for stuff on
code.dlang.org and spend the time to evaluate each possible solution.

So, from that perspective, there's some value in having something in Phobos
instead of on code.dlang.org. Ultimately, it doesn't scale. Even a
"batteries included" solution doesn't contain everything, and often enough,
there are enough ways to solve a problem that a "one size fits all" solution
isn't going to work, but you can get a lot of functionality in there as long
as we have the manpower and process to maintain it. However, it's
questionable that we have the manpower, and this thread was started
precisely because of concerns about the process.

And ultimately, I agree that there isn't that much stuff that needs to be in
Phobos. code.dlang.org fulfills the role just fine for most stuff, and as
improvements come to code.dlang.org, that will work better and better. What
ultimately gets into Phobos is going to largely depend on what gets proposed
for inclusion, and based on what's been happening, I suspect that the debate
is mostly going to take care of itself in that not much new stuff is going
to be proposed for inclusion in Phobos, meaning that discussions about stuff
that someone thinks should be in D's standard library are mostly going to be
complaints about something not being there that that particular person
thinks should be there and not actual discussions about whether a piece of
functionality that exists should go in there or not.

- Jonathan M Davis

[Issue 10933] findSplitBefore/After should have needle-less overloads

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=10933

Luís Marques  changed:

   What|Removed |Added

 CC||l...@luismarques.eu

--

OK, I'm stumped on this one: dstep, struct, mixin, bitfields

[Russel Winder via Digitalmars-d-learn]

The code I am playing with generated by DStep involves lots of lots of
structs with mixin bitfields. All of them seem to compile file, except
one. How is it that:

mixin(bitfields!(
ubyte, "current_next", 1,
ubyte, "version", 5,
ubyte, "one2", 2)); /* TS ID */

can result in the following error. The line for "version" is 141 and
the one for "one2" is 142.

source/libdvbv5_d/header.d-mixin-139(141): Error: no identifier for declarator 
`ubyte`
source/libdvbv5_d/header.d-mixin-139(141): Error: identifier or integer 
expected inside version(...), not `)`
source/libdvbv5_d/header.d-mixin-139(141): Error: found `@` when expecting `)`
source/libdvbv5_d/header.d-mixin-139(141): Error: no identifier for declarator 
`safe`
source/libdvbv5_d/header.d-mixin-139(141): Error: declaration expected, not 
`return`
source/libdvbv5_d/header.d-mixin-139(142): Error: no identifier for declarator 
`void`
source/libdvbv5_d/header.d-mixin-139(142): Error: identifier or integer 
expected inside version(...), not `ubyte`
source/libdvbv5_d/header.d-mixin-139(142): Error: found `v` when expecting `)`
source/libdvbv5_d/header.d-mixin-139(142): Error: declaration expected, not `)`
source/libdvbv5_d/header.d-mixin-139(142): Error: declaration expected, not 
`assert`
source/libdvbv5_d/header.d-mixin-139(142): Error: no identifier for declarator 
`_current_next_version_one2`
source/libdvbv5_d/header.d-mixin-139(142): Error: declaration expected, not `=`
source/libdvbv5_d/header.d(139): Error: incomplete mixin declaration `"private 
ubyte _current_next_version_one2;@property ubyte current_next() @safe pure 
nothrow @nogc const { auto result = (_current_next_version_one2 & 1U) >>0U; 
return cast(ubyte) result;}\x0a@property void current_next(ubyte v) @safe pure 
nothrow @nogc { assert(v >= current_next_min, \"Value is smaller than the 
minimum value of bitfield 'current_next'\"); assert(v <= current_next_max, 
\"Value is greater than the maximum value of bitfield 'current_next'\"); 
_current_next_version_one2 = cast(typeof(_current_next_version_one2)) 
((_current_next_version_one2 & (-1-cast(typeof(_current_next_version_one2))1U)) 
| ((cast(typeof(_current_next_version_one2)) v << 0U) & 1U));}\x0aenum ubyte 
current_next_min = cast(ubyte)0U;  enum ubyte current_next_max = cast(ubyte)1U; 
@property ubyte version() @safe pure nothrow @nogc const { auto result = 
(_current_next_version_one2 & 62U) >>1U; return cast(ubyte) 
result;}\x0a@property void version(ubyte v) @safe pure nothrow @nogc { assert(v 
>= version_min, \"Value is smaller than the minimum value of bitfield 
'version'\"); assert(v <= version_max, \"Value is greater than the maximum 
value of bitfield 'version'\"); _current_next_version_one2 = 
cast(typeof(_current_next_version_one2)) ((_current_next_version_one2 & 
(-1-cast(typeof(_current_next_version_one2))62U)) | 
((cast(typeof(_current_next_version_one2)) v << 1U) & 62U));}\x0aenum ubyte 
version_min = cast(ubyte)0U;  enum ubyte version_max = cast(ubyte)31U; 
@property ubyte one2() @safe pure nothrow @nogc const { auto result = 
(_current_next_version_one2 & 192U) >>6U; return cast(ubyte) 
result;}\x0a@property void one2(ubyte v) @safe pure nothrow @nogc { assert(v >= 
one2_min, \"Value is smaller than the minimum value of bitfield 'one2'\"); 
assert(v <= one2_max, \"Value is greater than the maximum value of bitfield 
'one2'\"); _current_next_version_one2 = 
cast(typeof(_current_next_version_one2)) ((_current_next_version_one2 & 
(-1-cast(typeof(_current_next_version_one2))192U)) | 
((cast(typeof(_current_next_version_one2)) v << 6U) & 192U));}\x0aenum ubyte 
one2_min = cast(ubyte)0U;  enum ubyte one2_max = cast(ubyte)3U; "`


-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

Template condition evaluation (shortcircuit)

[rumbu via Digitalmars-d-learn]

I tried to define a template:

enum isFoo(alias T) =
T.stringof.length >= 3 && T.stringof[0..3] == "abc";

int i;
pragma(msg, isFoo!i);

Error: string slice [0 .. 3] is out of bounds
Error: template object.__equals cannot deduce function from 
argument types !()(string, string), candidates are:

[...]

Is it normal that the condition is not short circuited at first 
test? Of course, I can throw there a bunch of static ifs in an 
eponymous template, but I don't see the point of this verbosity.

Re: Cumulative code coverage?

[Seb via Digitalmars-d]

On Wednesday, 21 March 2018 at 16:39:48 UTC, H. S. Teoh wrote:
Is it possible to get cumulative code coverage using dmd? I.e., 
accumulate code coverage stats over a series of runs from an 
external test suite.  Currently, it seems that compiling with 
-cov will just overwrite the *.lst files from previous runs.  
Do I have to merge the .lst files externally?


I'm currently writing an external test suite for one of my 
projects, and obviously, each individual test isn't going to 
cover the entire code. So the idea is to write a series of 
tests that cumulatively test all code paths.



T


Yes, either set dmd_coverSetMerge(true) or pass --DRT-covopt 
"merge:1" to your program.
You can also set the environment variable DRT_COVOPT, but I think 
you need to enable this by setting rt_envvars_enabled to true 
before.


https://dlang.org/phobos/core_runtime.html#.dmd_coverSetMerge
https://dlang.org/changelog/2.078.0.html#covopts

Flaw in DIP1000? Returning a Result Struct in DIP1000

[Jack Stouffer via Digitalmars-d]

Consider this example simplified from this PR 
https://github.com/dlang/phobos/pull/6281


--
struct GetoptResult
{
Option[] options;
}

struct Option
{
string optShort;
string help;
}

GetoptResult getopt(T...)(scope T opts) @safe
{
GetoptResult res;
auto o = Option(opts[0], opts[1]);
res.options ~= o;
return res;
}

void main() @safe
{
bool arg;
getopt("arg", "info", );
}
--

$ dmd -dip1000 -run main.d

--
main.d(16): Error: scope variable o assigned to non-scope res
main.d(23): Error: template instance `onlineapp.getopt!(string, 
string, bool*)` error instantiating

--

The only way I've found to make the code compile and retain the 
pre-dip1000 behavior is to change the Option construction to


--
auto o = Option(opts[0].idup, opts[1].idup);
--

How can we return non-scoped result variables constructed from 
scope variables without copies?

Re: #import mapi.h

[Timoses via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 16:22:45 UTC, Martin Tschierschke 
wrote:
Is there an step by step introduction how to convert a C header 
of an external lib into the right extern(C){} block?


A blog post or tutorial, or chapter in a D book? (I have those 
from Packt Publishing)


While googling I found this:
https://dlang.org/blog/2017/12/05/interfacing-d-with-c-getting-started/

Haven't read it yet, but might give you some more insight.

For automatic conversion I stumbled across Dstep which I so far 
like a lot:

https://github.com/jacob-carlborg/dstep

Re: Manipulate slice or specific element of range and return range

[Timoses via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 12:07:49 UTC, Simen Kjærås wrote:

On Wednesday, 21 March 2018 at 11:30:28 UTC, Timoses wrote:
unittest {
assert("my capitalized string".capitalize == 
"myCapitalizedString");

}

auto capitalize(string s) {
import std.regex, std.uni;

return s.replaceAll!(a => a[1].toUpper)(regex(" (.)"));
}


Ty! This definitely put me on the right track regarding strings.

Re: Manipulate slice or specific element of range and return range

[Timoses via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 12:53:56 UTC, Ali Çehreli wrote:


Here is another one that uses ForwardRange.

import std.range; // empty, take, save, chain, popFrontN;
import std.uni; // asLowerCase;
import std.algorithm; // equal, filter;
import std.conv; // text;

auto initialLowerCased(R)(R str, size_t N = 1) {
if (str.empty) {
N = 0;
}
auto frontPart = str.take(N);
auto rest = str.save;
rest.popFrontN(N);

return chain(frontPart.asLowerCase, rest);
}

unittest {
assert(initialLowerCased("My Test String", 4).equal("my 
test String"));

assert(initialLowerCased("").equal(""));
}

auto foo(R)(R str) {
return str.filter!(c => c != ' ').initialLowerCased;
}

void main() {
auto result = foo("My Capital String");
// result above is a range. std.conv.text can make a string:
string lower = result.text;
assert(lower == "myCapitalString");
}

Ali



I like it! I remember having a similar situation another time 
where it was not about strings. I wonder why there is no method 
for this in the standard library that can execute a predicate on 
specific elements of a range..

Re: #import mapi.h

[ketmar via Digitalmars-d-learn]

Martin Tschierschke wrote:


or tutorial


ok, tutorial:

1. learn C.
2. learn D.
3. DO IT!

;-)

Cumulative code coverage?

[H. S. Teoh via Digitalmars-d]

Is it possible to get cumulative code coverage using dmd? I.e.,
accumulate code coverage stats over a series of runs from an external
test suite.  Currently, it seems that compiling with -cov will just
overwrite the *.lst files from previous runs.  Do I have to merge the
.lst files externally?

I'm currently writing an external test suite for one of my projects, and
obviously, each individual test isn't going to cover the entire code.
So the idea is to write a series of tests that cumulatively test all
code paths.


T

-- 
"Holy war is an oxymoron." -- Lazarus Long

Re: Please vote for Dub integration into Sonatype Nexus

[Andre Pany via Digitalmars-d]

On Wednesday, 21 March 2018 at 15:30:57 UTC, Russel Winder wrote:
On Wed, 2018-03-21 at 11:49 +, Andre Pany via Digitalmars-d 
wrote:

[...]

[…]

[...]


JFrog have Artifactory yes, but I do not know if Bintray is 
actually something different or just a public instance of 
Artifactory. In any event Bintray is a public repository of 
stuff, with JCenter being the bit for Maven type artefacts – 
most of the people I know publish to Maven Central via JCenter 
so as to avoid Sonatype's Nexus.


I believe Maven is the wrong model for D, it is all about 
artefacts for
use in JVM-based language builds. Conan (C/C++ repository) is a 
much
better model for D, as is crates.io (Rust/Cargo repository), 
and indeed

Dub :-).


[...]


I don't feel it is a hard one or the other decision but 
possibilities.
In this direction Sönke made a very good proposal how to support 
different repositories using the existing registry attribute.


Kind regards
Andre

Re: pow

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 21 March 2018 at 16:29:26 UTC, aerto wrote:

thanks, a last question in a diffrent function i use


use

BigInt i = 
"105312291668557186697918027683670432318895095400549111254310977536";


and it should work. Note the quotation marks - it reads it as a 
string because a long number literal is limited o 64 bit 
representations.

Re: D, Parasail, Pascal, and Rust vs The Steelman

[Martin Tschierschke via Digitalmars-d]

On Wednesday, 21 March 2018 at 16:19:35 UTC, H. S. Teoh wrote:
[...]
I do not understand the meaning of "subscript ranges"? Isn't 
this slicing?


AFAICT, "subscript" in the spec just means the range of valid 
array indices (it's old terminology from the 70's / 80's).


In which case, it is not true that subscript ranges are not 
accessible in D (I don't know about Rust); all D arrays have 
indices from 0 to .length-1, so the callee can always access 
the range of allowed indices, and the caller never has to pass 
.length explicitly.



T
With this D fulfills, 95% of the "Steelman requirement" partially 
or better :-)

Re: pow

[aerto via Digitalmars-d]

On Wednesday, 21 March 2018 at 16:00:56 UTC, Adam D. Ruppe wrote:

On Wednesday, 21 March 2018 at 15:56:00 UTC, aerto wrote:
why pow(256, 27) gives 0, instead of 
105312291668557186697918027683670432318895095400549111254310977536L


that result is simply too big to fit in the result. Try using a 
bigint instead:


import std.bigint, std.stdio;

void main() {
BigInt i = 256;
i ^^= 27;
writeln(i);
}


thanks, a last question in a diffrent function i use 
writeln(105312291668557186697918027683670432318895095400549111254310977536L); and i get Error: integer overflow any solution >?

#import mapi.h

[Martin Tschierschke via Digitalmars-d-learn]

Is there an step by step introduction how to convert a C header 
of an external lib into the right extern(C){} block?


A blog post or tutorial, or chapter in a D book? (I have those 
from Packt Publishing)


(Especially I am trying to get this used with D:
Montetdb C-API 
https://www.monetdb.org/Documentation/Manuals/SQLreference/Programming/MAPI
With: 
https://github.com/snaga/monetdb/blob/master/clients/mapilib/mapi.h)


The page: https://dlang.org/spec/interfaceToC.html is known, but 
not detailed enough for me.

Re: D, Parasail, Pascal, and Rust vs The Steelman

[H. S. Teoh via Digitalmars-d]

On Wed, Mar 21, 2018 at 04:08:07PM +, Martin Tschierschke via Digitalmars-d 
wrote:
> On Wednesday, 21 March 2018 at 12:52:19 UTC, Paulo Pinto wrote:
[...]
> > [0] - https://en.wikipedia.org/wiki/Steelman_language_requirements
> 
> Interesting!
> 
> Do you understand this:
> 
> > 7H. Formal Array Parameters. The number of dimensions for formal
> > array parameters must be specified in programs and shall be
> > determinable during translation. Determination of the  subscript
> > range for formal array parameters may be delayed until invocation
> > and may vary from  call to call. Subscript ranges shall be
> > accessible within function and procedure bodies without being passed
> > as explicit parameters.
> 
> > Subscript ranges are not accessible in D or Rust.
> 
> I do not understand the meaning of "subscript ranges"? Isn't this
> slicing?

AFAICT, "subscript" in the spec just means the range of valid array
indices (it's old terminology from the 70's / 80's).

In which case, it is not true that subscript ranges are not accessible
in D (I don't know about Rust); all D arrays have indices from 0 to
.length-1, so the callee can always access the range of allowed indices,
and the caller never has to pass .length explicitly.


T

-- 
It only takes one twig to burn down a forest.

[Issue 7930] Static initialization of static-sized array in union fails

[d-bugmail--- via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=7930

bitter.ta...@gmx.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bitter.ta...@gmx.com
 Resolution|--- |FIXED

--- Comment #2 from bitter.ta...@gmx.com ---
Works on master.

--

Re: pow

[H. S. Teoh via Digitalmars-d]

On Wed, Mar 21, 2018 at 03:56:00PM +, aerto via Digitalmars-d wrote:
> why pow(256, 27) gives 0, instead of
> 105312291668557186697918027683670432318895095400549111254310977536L

Because 256, being an int type, can only hold a 32-bit result, the
maximum of which is 2^31 (or 2^32 if you use uint). But 256^27 = 2^216,
far bigger than a 32-bit int can hold.

As Adam said, you probably want to use BigInt instead:

import std.bigint;
auto result = pow(BigInt(256), 27);


T

-- 
Food and laptops don't mix.

Re: Incomprehensible error message

[Russel Winder via Digitalmars-d-learn]

On Tue, 2018-03-20 at 14:18 -0700, H. S. Teoh via Digitalmars-d-learn
wrote:
> […]
> 
> Either way, it will require a lot of effort to pull off.
> 

As Rust has shown appreciating that the quality of the error messages
define the quality of the compiler, the quality of the error message
from rustc are now very good indeed.

On the other hand Rust has a lot of paid staff.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

Re: D, Parasail, Pascal, and Rust vs The Steelman

[Martin Tschierschke via Digitalmars-d]

On Wednesday, 21 March 2018 at 12:52:19 UTC, Paulo Pinto wrote:
An article comparing the above languages as per the DoD 
language requirements [0].


http://jedbarber.id.au/steelman.html

[0] - 
https://en.wikipedia.org/wiki/Steelman_language_requirements


Interesting!

Do you understand this:

7H. Formal Array Parameters. The number of dimensions for formal 
array parameters must be specified in programs and shall be 
determinable during translation. Determination of the  subscript 
range for formal array parameters may be delayed until 
invocation and may vary from  call to call. Subscript ranges 
shall be accessible within function and procedure bodies without 
being passed as explicit parameters.



Subscript ranges are not accessible in D or Rust.


I do not understand the meaning of "subscript ranges"? Isn't this 
slicing?

Re: Packages and module import

[Russel Winder via Digitalmars-d-learn]

On Tue, 2018-03-20 at 22:08 +0100, Jacob Carlborg via Digitalmars-d-
learn wrote:
> 
[…]
> Not sure if this will help, but are you aware that DStep can add a 
> package to the module declaration using "--package"?

No I wasn't. And it works a treat.

-- 
Russel.
===
Dr Russel Winder  t: +44 20 7585 2200
41 Buckmaster Roadm: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk


signature.asc
Description: This is a digitally signed message part

Re: pow

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 21 March 2018 at 15:56:00 UTC, aerto wrote:
why pow(256, 27) gives 0, instead of 
105312291668557186697918027683670432318895095400549111254310977536L


that result is simply too big to fit in the result. Try using a 
bigint instead:


import std.bigint, std.stdio;

void main() {
BigInt i = 256;
i ^^= 27;
writeln(i);
}

pow

[aerto via Digitalmars-d]

why pow(256, 27) gives 0, instead of 
105312291668557186697918027683670432318895095400549111254310977536L

Re: How to use an associative array with array values.

[Adam D. Ruppe via Digitalmars-d-learn]

On Wednesday, 21 March 2018 at 15:53:32 UTC, tipdbmp wrote:

int[10][string] foo;


One option is to initialize like this

---
void main() {
   int[10][string] foo;

   if("a" !in foo)
	foo["a"] = [0,0,0,0,0,0,0,0,0,0]; // set all to zero to create 
the key


   foo["a"][4] = 4;  // now valid to set individual element
}
---

How to use an associative array with array values.

[tipdbmp via Digitalmars-d-learn]

 // foo is an associative array/hashtable with
 // key type: string
 // value type: int[10]
 //
int[10][string] foo;

// foo["a"] = new int[10]; // Range violation at runtime

// foo["a"][0] = 1; // Range violation at runtime