Re: DIP1000: Scoped Pointers

[Bill Baxter via Digitalmars-d-announce]

This bit seems odd:

T func(T* t) {
  return t; // ok
}

Is there an implicit conversion from T* to T?


On Wed, Aug 10, 2016 at 10:05 PM, rikki cattermole via
Digitalmars-d-announce  wrote:

> On 11/08/2016 8:35 AM, Dicebot wrote:
>
>> The first DIP has just landed into the new queue. It is a proposal from
>> language authors and thus it bypasses usual nitpicking process and
>> proceeds straight to requesting community (your!) feedback.
>>
>> Essentially, it is an attempt to solve reference lifetime problem by
>> extending implementation of `scope` keyword.
>>
>> Proposal text: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md
>>
>> Few notes:
>>
>> - Please submit pull requests to adjust the markdown document if you
>> want to propose any improvements (mentioning @WalterBright and @andralex
>> for confirmation).
>> - The proposal refers to a number of other documents and it is
>> recommended to become familiar at least briefly with all of them.
>> - At this point the question I'd personally suggest to be evaluated is
>> "does this proposal enable enough useful designs?". A good check would
>> be to try taking some of your projects and see if having DIP1000
>> approved and implemented could improve them.
>>
>
> Question:
> I see RefCountedSlice example, does this mean if I alias this say like:
>
> struct FooBar;
>
> struct Foo {
> FooBar* v;
>
> scope FooBar* get() { return v; }
> alias this get;
> }
>
> That it will operate correctly in the below case?
>
> func(myFoo);
> void func(scope FooBar*)
>
> If this does work, this is a major addition that I've been waiting for,
> for my managed memory concept! https://github.com/rikkimax/al
> phaPhobos/blob/master/source/std/experimental/memory/managed.d
> After this I'll only need proper ref counting in the language ;)
>

Re: How to add nogc to delegate

[ag0aep6g via Digitalmars-d-learn]

On 08/11/2016 06:15 AM, Engine Machine wrote:

void foo(@nogc void delegate())

doesn't work.


Put it after the parameter list, like so:

void foo(void delegate() @nogc)

Re: DIP1000: Scoped Pointers

[rikki cattermole via Digitalmars-d-announce]

On 11/08/2016 8:35 AM, Dicebot wrote:

The first DIP has just landed into the new queue. It is a proposal from
language authors and thus it bypasses usual nitpicking process and
proceeds straight to requesting community (your!) feedback.

Essentially, it is an attempt to solve reference lifetime problem by
extending implementation of `scope` keyword.

Proposal text: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md

Few notes:

- Please submit pull requests to adjust the markdown document if you
want to propose any improvements (mentioning @WalterBright and @andralex
for confirmation).
- The proposal refers to a number of other documents and it is
recommended to become familiar at least briefly with all of them.
- At this point the question I'd personally suggest to be evaluated is
"does this proposal enable enough useful designs?". A good check would
be to try taking some of your projects and see if having DIP1000
approved and implemented could improve them.


Question:
I see RefCountedSlice example, does this mean if I alias this say like:

struct FooBar;

struct Foo {
FooBar* v;

scope FooBar* get() { return v; }
alias this get;
}

That it will operate correctly in the below case?

func(myFoo);
void func(scope FooBar*)

If this does work, this is a major addition that I've been waiting for, 
for my managed memory concept! 
https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/memory/managed.d

After this I'll only need proper ref counting in the language ;)

Re: [OT] Live coding sessions

[rikki cattermole via Digitalmars-d]

On 11/08/2016 4:19 AM, Steven Schveighoffer wrote:

On 8/10/16 7:17 AM, Walter Bright wrote:

https://www.livecoding.tv/wild/videos/evGmx-operating-system-development-d-programming-223



Do people really like this? I have so much to do, I have no time to
watch others code. No offense meant to others, I'm just curious about it.

I also have no interest in having others watch me code, it would be
brutal :) For one, I take a lot of breaks and walk around to think...

-Steve


What can I say? I was streaming during closed beta of last year ;)

Re: Unexpected foreach lowering

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, August 10, 2016 21:00:01 Lodovico Giaretta via Digitalmars-d-
learn wrote:
> Wow. Thanks. I didn't know the compiler would try opSlice. I will
> file it.

It does that so that you can use foreach with containers without having to
call something on the container. The idea is that the container will
implement opSlice and make it return a range over the container, and foreach
will then use that range to iterate over the container.

- Jonathan M Davis

How to add nogc to delegate

[Engine Machine via Digitalmars-d-learn]

void foo(@nogc void delegate())

doesn't work.

But declaring an alias does, but too verbose. Surely we should be 
able to add the attribute directly?

Re: minor question of the difference between " and '

[Ali Çehreli via Digitalmars-d-learn]

On 08/10/2016 04:32 PM, WhatMeWorry wrote:



string pwdxCommand = escapeShellCommand("pwdx", to!string(pid));
writeln("pwdxCommand = ", pwdxCommand);

Output:
Current process ID: 7962
pwdxCommand = 'pwdx' '7962'


I'm confused as to why the writeln statement didn't output "pwdx 7962"?
Afterall, isn't that the definition of a string?  So what's up with the
two groupings of single quotes?

BTW, those aren't backticks?  (think that is what the key is called)


No, they are not backticks. This is: ` :)


Thanks in advance.



I haven't used it myself but judging from it's documented purpose, those 
quotes are used to allow spaces so that the shell considers it a single 
command line argument as a whole:


grep 'foo bar' *
git commit -m 'My message'
etc.

Ali

Re: DIP1000: Scoped Pointers

[Walter Bright via Digitalmars-d-announce]

On 8/10/2016 4:56 PM, Nicholas Wilson wrote:

How will the infinite lifetime of ArrayLiteral and ArrayLiteral[constant]
interact with LDC's GC to stack promotion pass?


I don't know about how that works in LDC, but general such a promotion can only 
be done if the compiler can prove there are no escaping pointers to the data.

Re: D Github contributors - enable 2 factor authentification

[Walter Bright via Digitalmars-d]

On 8/10/2016 4:41 PM, Seb wrote:

FYI: You (as org admin) can check whether everyone of the organization has 2FA
enabled:

https://help.github.com/articles/ensuring-that-organization-members-have-enabled-two-factor-authentication/



Thanks! OMG, looks like only about a fifth have 2FA.

Re: DIP1000: Scoped Pointers

[Nicholas Wilson via Digitalmars-d-announce]

On Wednesday, 10 August 2016 at 20:35:23 UTC, Dicebot wrote:
The first DIP has just landed into the new queue. It is a 
proposal from language authors and thus it bypasses usual 
nitpicking process and proceeds straight to requesting 
community (your!) feedback.


[...]


How will the infinite lifetime of ArrayLiteral and 
ArrayLiteral[constant] interact with LDC's GC to stack promotion 
pass?

Re: D Github contributors - enable 2 factor authentification

[Seb via Digitalmars-d]

On Wednesday, 10 August 2016 at 23:22:24 UTC, Walter Bright wrote:

On 8/10/2016 9:15 AM, Steven Schveighoffer wrote:

Done.


Thanks!

In any case, should be 0 impact, since all my github traffic 
goes via ssh key.


Like a castle with its defenses in depth, security should 
always have multiple levels to it to guard against a single 
point of failure.


FYI: You (as org admin) can check whether everyone of the 
organization has 2FA enabled:


https://help.github.com/articles/ensuring-that-organization-members-have-enabled-two-factor-authentication/

minor question of the difference between " and '

[WhatMeWorry via Digitalmars-d-learn]

string pwdxCommand = escapeShellCommand("pwdx", to!string(pid));
writeln("pwdxCommand = ", pwdxCommand);

Output:
Current process ID: 7962
pwdxCommand = 'pwdx' '7962'


I'm confused as to why the writeln statement didn't output "pwdx 
7962"?
Afterall, isn't that the definition of a string?  So what's up 
with the two groupings of single quotes?


BTW, those aren't backticks?  (think that is what the key is 
called)


Thanks in advance.

Re: D Github contributors - enable 2 factor authentification

[Walter Bright via Digitalmars-d]

On 8/10/2016 9:15 AM, Steven Schveighoffer wrote:

Done.


Thanks!


In any case, should be 0 impact, since all my github traffic goes via ssh key.


Like a castle with its defenses in depth, security should always have multiple 
levels to it to guard against a single point of failure.

Re: DMD git HEAD not compilable on gcc 6.1

[ketmar via Digitalmars-d]

On Wednesday, 10 August 2016 at 21:19:14 UTC, H. S. Teoh wrote:
Is there a more reliable way to detect gcc-based compilers 
other than string-matching of --version?  Perhaps a small 
utility program that uses #ifdef __GNUC__ as a far more 
reliable compiler detection method?


it is not more reliable. other compilers may define that if they 
are trying to "mimic" gcc for some reason. i'd say "spam your 
distributive maintainers to fix their bug".

[Issue 16373] gcc 6.1.1 compatibility

[via Digitalmars-d-bugs]

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

--- Comment #1 from hst...@quickfur.ath.cx ---
Turns out the problem is that posix.mak fails to reliably detect gcc.

Propose using a small utility program that uses #ifdef __GNUC__ as a more
reliable detection method:

http://nadeausoftware.com/articles/2012/10/c_c_tip_how_detect_compiler_name_and_version_using_compiler_predefined_macros#Howtodetectthecompilername

--

Re: DMD git HEAD not compilable on gcc 6.1

[H. S. Teoh via Digitalmars-d]

On Wed, Aug 10, 2016 at 11:13:28PM +0200, Jacob Carlborg via Digitalmars-d 
wrote:
> On 10/08/16 23:01, H. S. Teoh via Digitalmars-d wrote:
> > https://issues.dlang.org/show_bug.cgi?id=16373
> > 
> > :-(
> > 
> > Anybody know a quick fix for this?
> 
> Disable the warning printed in the error message.
[...]

Turns out, it's a messy situation related to the makefiles. :-(

The required -Wnarrowing flag is already specified for gcc-based host
compilers; however, the makefile uses an unreliable string matching of
the compiler's --version output to detect gcc-based compilers.
Unfortunately, my distro (Debian) uses a custom gcc build that, for
whatever reason, doesn't include the string "gcc" in the output of
--version, so the makefile fails to detect gcc and doesn't include the
needed flag.

Is there a more reliable way to detect gcc-based compilers other than
string-matching of --version?  Perhaps a small utility program that uses
#ifdef __GNUC__ as a far more reliable compiler detection method?


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: DMD git HEAD not compilable on gcc 6.1

[ketmar via Digitalmars-d]

On Wednesday, 10 August 2016 at 21:23:37 UTC, ketmar wrote:

or don't use unreleased compiler. ;-)


p.s. and i mean gcc here.

Re: DMD git HEAD not compilable on gcc 6.1

[ketmar via Digitalmars-d]

or don't use unreleased compiler. ;-)

[Issue 14619] foreach implicitly slices ranges

[via Digitalmars-d-bugs]

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

Lodovico Giaretta  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16374

--

[Issue 16374] Foreach lowering tries opSlice before range primitives

[via Digitalmars-d-bugs]

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

Lodovico Giaretta  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=14619

--

Re: DMD git HEAD not compilable on gcc 6.1

[Jacob Carlborg via Digitalmars-d]

On 10/08/16 23:01, H. S. Teoh via Digitalmars-d wrote:

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

:-(

Anybody know a quick fix for this?


Disable the warning printed in the error message.

--
/Jacob Carlborg

Re: DIP1000: Scoped Pointers (Discussion)

[Enamex via Digitalmars-d]

On Wednesday, 10 August 2016 at 20:36:38 UTC, Dicebot wrote:

http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org

- Please submit pull requests to adjust the markdown document 
if you want to propose any improvements (mentioning 
@WalterBright and @andralex for confirmation).


Personally I wouldn't recommend directly submitting pull requests 
for improvement suggestions. Keep those in the forum/git 
discussions (maybe open an RFC issue on GitHub?) with the pull 
requests only after enough people have commented on the 
suggestions.


(I just don't want to have to follow several PR threads for every 
single improvement suggestion to every DIP in its final comment 
period.)

Re: move std.{ascii, base64, utf} to a new encoding package

[Seb via Digitalmars-d]

On Tuesday, 9 August 2016 at 00:24:40 UTC, Jonathan M Davis wrote:

On Monday, August 08, 2016 19:42:50 Seb via Digitalmars-d wrote:

[...]


std.encoding needs a complete overhaul. Unfortunately, while I 
think that that's generally agreed upon, no one has stepped up 
to do it. So, who knows when it'll be fixed. However, given 
that std.encoding needs an overhaul, I don't seem much point in 
moving stuff into it. While it may not be ideal, base64 works 
where it is, and we can worry about moving it when std.encoding 
is revamped. If we changed it now and then changed it again 
when std.encoding got overhauled, then we'd end up breaking 
code twice just to move a function around.


- Jonathan M Davis


Thanks @ all for your explanations!
FWIW I have added std.encoding to the wiki's wishlist ;-)

https://wiki.dlang.org/Wish_list#std.encoding

Re: Unexpected foreach lowering

[ag0aep6g via Digitalmars-d-learn]

On 08/10/2016 10:54 PM, Steven Schveighoffer wrote:

The issue is that it tries using [] on the item to see if it defines a
range-like thing. Since you don't define opSlice(), it automatically
goes to the subrange.

This breaks for int[] as well as Array.

If I add opSlice to your code (and return this) it works.

This is definitely a bug, it should try range functions before opSlice.
Please file.


Related:

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

Re: Unexpected foreach lowering

[Lodovico Giaretta via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 21:00:01 UTC, Lodovico Giaretta 
wrote:
On Wednesday, 10 August 2016 at 20:54:15 UTC, Steven 
Schveighoffer wrote:

[...]


Wow. Thanks. I didn't know the compiler would try opSlice. I 
will file it.


Filed on bugzilla:

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

[Issue 16374] New: Foreach lowering tries opSlice before range primitives

[via Digitalmars-d-bugs]

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

  Issue ID: 16374
   Summary: Foreach lowering tries opSlice before range primitives
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: lodov...@giaretart.net
CC: lodov...@giaretart.net

When lowering a foreach, the compiler gives priority to opSlice over
front/popFront/empty, which is counter-intuitive (and also undocumented).

The following code, taken from [1] shows the issue: the overridden front in
RangeWrapper is ignored when the wrapped range also defines opSlice, which is
true for RangeT (the range returned by Array.opSlice). This causes the foreach
output to be different from the expected old-style for loop equivalent.

Example code:
=
import std.stdio, std.container.array;
struct RangeWrapper(Range)
{
Range range;
alias range this;

auto front()
{
return range.front + 1;
}
}
auto rangeWrapper(Range)(auto ref Range range)
{
return RangeWrapper!Range(range);
}
void main()
{
Array!int array;
array.insertBack(3);

foreach (i; rangeWrapper(array[]))
writeln(i);   // prints 3, which is wrong

// isn't the above foreach equivalent to the following loop ?

for (auto r = rangeWrapper(array[]); !r.empty; r.popFront())
writeln(r.front); // correctly prints 4
}
=

[1] http://forum.dlang.org/thread/fzwofczyvkxgmtvnc...@forum.dlang.org

--

Re: Ddoc to HTML tool?

[Jacob Carlborg via Digitalmars-d-learn]

On 10/08/16 16:48, Kagamin wrote:

dmd generates html from dd files; example:
https://github.com/dlang/dlang.org/blob/master/download.dd


Unfortunately it looks like Standard Sections [1] are not handled in the 
same way as when generating documentation from D source files. They're 
handled just as any other text.


[1] https://dlang.org/spec/ddoc.html#standard_srction

--
/Jacob Carlborg

DMD git HEAD not compilable on gcc 6.1

[H. S. Teoh via Digitalmars-d]

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

:-(

Anybody know a quick fix for this?


T

-- 
Just because you survived after you did it, doesn't mean it wasn't stupid!

[Issue 16373] New: gcc 6.1.1 compatibility

[via Digitalmars-d-bugs]

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

  Issue ID: 16373
   Summary: gcc 6.1.1 compatibility
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: blocker
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

DMD does not compile with gcc 6.1.1:

backend/cg87.c:716:46: error: narrowing conversion of ‘232’ from ‘int’ to
‘char’ inside { } [-Wnarrowing]

backend/cod1.c:2508:9: error: narrowing conversion of ‘193’ from ‘int’ to
‘char’ inside { } [-Wnarrowing]

backend/cod3.c:431:13: error: narrowing conversion of ‘144’ from ‘int’ to
‘char’ inside { } [-Wnarrowing]

backend/ptrntab.c:1208:1: error: narrowing conversion of ‘-1006567058’ from
‘int’ to ‘unsigned int’ inside { } [-Wnarrowing]
[... above error repeated on many other lines in the same file ...]


These errors are making it impossible for me to use dmd git HEAD.

--

Re: Unexpected foreach lowering

[Lodovico Giaretta via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 20:54:15 UTC, Steven 
Schveighoffer wrote:

On 8/10/16 2:08 PM, Lodovico Giaretta wrote:

[...]


The issue is that it tries using [] on the item to see if it 
defines a range-like thing. Since you don't define opSlice(), 
it automatically goes to the subrange.


This breaks for int[] as well as Array.

If I add opSlice to your code (and return this) it works.

This is definitely a bug, it should try range functions before 
opSlice. Please file.


-Steve


Wow. Thanks. I didn't know the compiler would try opSlice. I will 
file it.

Re: Unexpected foreach lowering

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/10/16 2:08 PM, Lodovico Giaretta wrote:

I'm probably missing something stupid but...
Why on earth do the two loops in main print a different result?
It looks like the foreach lowering is ignoring my definition of front...

=
import std.stdio, std.container.array;

struct RangeWrapper(Range)
{
Range range;
alias range this;

auto front()
{
return range.front + 1;
}
}
auto rangeWrapper(Range)(auto ref Range range)
{
return RangeWrapper!Range(range);
}

void main()
{
Array!int array;
array.insertBack(3);

foreach (i; rangeWrapper(array[]))
writeln(i);   // prints 3, which is wrong

// isn't the above foreach equivalent to the following loop ?

for (auto r = rangeWrapper(array[]); !r.empty; r.popFront())
writeln(r.front); // correctly prints 4
}
=

Thank you for your help.


The issue is that it tries using [] on the item to see if it defines a 
range-like thing. Since you don't define opSlice(), it automatically 
goes to the subrange.


This breaks for int[] as well as Array.

If I add opSlice to your code (and return this) it works.

This is definitely a bug, it should try range functions before opSlice. 
Please file.


-Steve

DIP1000: Scoped Pointers (Discussion)

[Dicebot via Digitalmars-d]

http://forum.dlang.org/post/pqsiqmkxenrwxoruz...@forum.dlang.org

The first DIP has just landed into the new queue. It is a 
proposal from language authors and thus it bypasses usual 
nitpicking process and proceeds straight to requesting community 
(your!) feedback.


Essentially, it is an attempt to solve reference lifetime problem 
by extending implementation of `scope` keyword.


Proposal text: 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md


Few notes:

- Please submit pull requests to adjust the markdown document if 
you want to propose any improvements (mentioning @WalterBright 
and @andralex for confirmation).
- The proposal refers to a number of other documents and it is 
recommended to become familiar at least briefly with all of them.
- At this point the question I'd personally suggest to be 
evaluated is "does this proposal enable enough useful designs?". 
A good check would be to try taking some of your projects and see 
if having DIP1000 approved and implemented could improve them.

DIP1000: Scoped Pointers

[Dicebot via Digitalmars-d-announce]

The first DIP has just landed into the new queue. It is a 
proposal from language authors and thus it bypasses usual 
nitpicking process and proceeds straight to requesting community 
(your!) feedback.


Essentially, it is an attempt to solve reference lifetime problem 
by extending implementation of `scope` keyword.


Proposal text: 
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md


Few notes:

- Please submit pull requests to adjust the markdown document if 
you want to propose any improvements (mentioning @WalterBright 
and @andralex for confirmation).
- The proposal refers to a number of other documents and it is 
recommended to become familiar at least briefly with all of them.
- At this point the question I'd personally suggest to be 
evaluated is "does this proposal enable enough useful designs?". 
A good check would be to try taking some of your projects and see 
if having DIP1000 approved and implemented could improve them.

Re: Ddoc to HTML tool?

[Jacob Carlborg via Digitalmars-d-learn]

On 10/08/16 19:10, Adam D. Ruppe wrote:


those are in the macro definition file, you can make your own and
simplify/improve.


I replaced the DDOC macro with my own version, that worked fine. Thanks.

--
/Jacob Carlborg

[Issue 16364] getUDAs and hasUDA do not give consistent results

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/29470ebb3c3c1475950e317fa033199d92b48cee
Fix issue# 16364. Make getUDAs and hasUDA consistent.

https://github.com/dlang/phobos/commit/af39effdb467af75c04ccf139a730a6d68c2f9a7
Merge pull request #4721 from jmdavis/issue_16364

Fix issue# 16364. Make getUDAs and hasUDA consistent.

--

[Issue 16364] getUDAs and hasUDA do not give consistent results

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 16362] `foreach (ref v; range)` with non-ref returning `.front()` missing dtors

[via Digitalmars-d-bugs]

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

Ketmar Dark  changed:

   What|Removed |Added

   Attachment #1607|0   |1
is obsolete||

--- Comment #2 from Ketmar Dark  ---
Created attachment 1608
  --> https://issues.dlang.org/attachment.cgi?id=1608=edit
fix and test case, v2

remove `ref` only for types that needs dtor to be called. this *may* give some
speedup when `.front` returns structs without dtors.

--

Re: Let us talk about error messages

[jmh530 via Digitalmars-d]

On Wednesday, 10 August 2016 at 18:28:00 UTC, qznc wrote:

Rust changed their error message format:

https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html

Inspiration for D?


Looks pretty.

I remember some discussion about cleaning up error messages when 
templates don't match. That's probably the most common 
ugly-looking message I get.

Re: Unexpected foreach lowering

[Lodovico Giaretta via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 19:37:39 UTC, Ali Çehreli wrote:
A quick read reveals popFront() is implemented only for bool 
Arrays. That explains the issue.


I don't know whether it's an oversight.

Ali


First of all, thank you for spending your time on this issue. I 
really appreciate that.


I may be reading that code wrong but...
Isn't popFront implemented for every type here?
https://github.com/dlang/phobos/blob/master/std/container/array.d#L128

Re: Let us talk about error messages

[Seb via Digitalmars-d]

On Wednesday, 10 August 2016 at 18:28:00 UTC, qznc wrote:

Rust changed their error message format:

https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html

Inspiration for D?


Yes, please. Hard to understand/confusing error messages were 
ranked among the three top things that people bother with D (the 
other things is still the license of DMD) in this recent slant 
[1].


small rant (from current discussions at Phobos): we should also 
remove all the silent assert(0) in Phobos that come without any 
error message, but the segfault.

That's a very cheap way to improve the UX.

[1] 
https://www.slant.co/topics/5984/~productivity-enhancing-well-designed-and-concise-rather-than-just-popular-or-time-tested-programming-la

Re: Unexpected foreach lowering

[Ali Çehreli via Digitalmars-d-learn]

On 08/10/2016 11:47 AM, Lodovico Giaretta wrote:

On Wednesday, 10 August 2016 at 18:38:00 UTC, Ali Çehreli wrote:

RangeWrapper does not provide the InputRange interface, so the
compiler uses 'alias this' and iterates directly on the member range.

I tried making RangeWrapper an InputRange but failed. It still uses
'range'.

// Still fails with these:
@property bool empty() {
return range.empty;
}

void popFront() {
range.popFront();
}

I don't know how the decision process works there.

Ali


That's strange, as RangeWrapper works correctly if instantiated with any
underlying range EXCEPT std.container.Array.


A quick read reveals popFront() is implemented only for bool Arrays. 
That explains the issue.


I don't know whether it's an oversight.

Ali

Re: Autotesting dub packages with dmd nightly

[Seb via Digitalmars-d-announce]

On Wednesday, 10 August 2016 at 18:35:03 UTC, Sebastiaan Koppe 
wrote:
Yes, but from past experience we know that people don't look 
at results, if you don't make it part of PR acceptance.


So true. Then I will do PR's first.


Thinking about it, you could also opt for integrating it with the 
dmd PR flow - in a similar manner to the autotester or coverage 
bot:
Select a subset (depending on the runtime) of packages and run 
your dub autotester for every commit and thus save for every 
commit a list of passing packages.
Now for a new PR, search for the master commit hash in your DB of 
runs and run the dub autotester with those packages. The workflow 
of the AutoTester [1] is a bit more complicated, because it is 
throwing away results as soon as the master HEAD changes (to 
avoid any inconsistencies) and there are often rebases and 
additional pushes happening, but you could just opt for a simple 
80% solution.
I imagine shouting at Walter with a Github comment "Hey this PR 
will break 10% of all packages [of the subset]" could be quite 
helpful ;-)


[1] https://auto-tester.puremagic.com

Re: I'll be back soon

[Ilya Yaroshenko via Digitalmars-d]

On Wednesday, 10 August 2016 at 18:38:15 UTC, Daniel Kozak wrote:
Dne 10.8.2016 v 14:52 Ilya Yaroshenko via Digitalmars-d 
napsal(a):


On Wednesday, 10 August 2016 at 10:33:11 UTC, Martin Nowak 
wrote:
On Wednesday, 10 August 2016 at 05:49:55 UTC, Ilya Yaroshenko 
wrote:
In addition, most of functions has very different API 
comparing with their prototypes from std.algorithms: 
multiple dimensions, multiple tensors, selection type, plus 
ndFind accepts static array as the first argument.


Overloads from different modules don't conflict when it's not 
possible to one of them. So if all of ndslice.algorithm 
functions only work with ndslices, and none of std.algorithm 
functions work with ndslices, you're fine.
I'd even consider forwarding std.algorithm.searching.find to 
ndslice.algorithm.find a better solution than adding awkward 
prefixes that look like we're using C.


I haven't yet used ndslice much though.


This is true for find, but not true for other algorithms, 
because of two reasons:


1. std.algorithm works with ndslices because ndslices is 
random access ranges composed of n-1-dimensional elements.

2. most of algorithms are super-templates:
 a. template map(fun...)
 b. template ndMap(fun...)
so they would not work with the same namespace if names are 
identical.

But one can still do something like:

import nd = std.experimental.ndslice;
// now I can use nd.map which is not so different from ndMap
// and there could be some special module with aliases for 
those who are unable

// to use one char '.' extra :)
module std.experimental.ndslice.aliases;
alias ndMap = nd.map;
...


So I am against prefixes in func names like ndMap and so.



This approach has two issues:
1. This should be done for std.algorithm to, because its map 
would be broken anyway (import is not static).

2. Static import or nd.??? is not good for UFCS pipeline:


Slice!(3, C*) movingWindowByChannel(alias filter, C)
(Slice!(3, C*) image, size_t nr, size_t nc)
{
return image
.pack!1
.windows(nr, nc)
.unpack
.transposed!(0, 1, 4)
.pack!2
.ndMap!filter
.slice;
}

Re: Let us talk about error messages

[Walter Bright via Digitalmars-d]

On 8/10/2016 11:28 AM, qznc wrote:

Rust changed their error message format:

https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html

Inspiration for D?


There are some good ideas there. One thing I've idly thought about is to include 
a clickable link to the relevant section in the spec.

Re: 101 BASIC Computer Games - In D?

[Walter Bright via Digitalmars-d]

On 8/10/2016 8:34 AM, bachmeier wrote:

It would also give us example code making heavy usage of goto statements. goto
is badly underutilized by our community. For that matter, we don't have enough
spaghetti code examples to make programmers from other languages comfortable.


Nobody sez leave it as goto's.

Re: Unexpected foreach lowering

[Lodovico Giaretta via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 18:38:00 UTC, Ali Çehreli wrote:
RangeWrapper does not provide the InputRange interface, so the 
compiler uses 'alias this' and iterates directly on the member 
range.


I tried making RangeWrapper an InputRange but failed. It still 
uses 'range'.


// Still fails with these:
@property bool empty() {
return range.empty;
}

void popFront() {
range.popFront();
}

I don't know how the decision process works there.

Ali


That's strange, as RangeWrapper works correctly if instantiated 
with any underlying range EXCEPT std.container.Array.
Also, RangeWrapper does provide the InputRange interface, 
partially directly and partially with alias this. RangeWrapper 
should be "opaque", as it should not matter whether the methods 
needed for the InputRange interface are defined directly or 
inherited with alias this.

Re: Autotesting dub packages with dmd nightly

[Sebastiaan Koppe via Digitalmars-d-announce]

On Wednesday, 10 August 2016 at 10:32:24 UTC, Martin Nowak wrote:
We want better ranking of dub packages (mostly by download, but 
for sure also showing CI results [¹]).


I was also thinking about integrating results from CI builds that 
packages do themselves. But there is some 'impedance mismatch': 
those CI build are done on the master branch, not on the latest 
release that is on code.dlang.org.



Is it already usable?


Short answer: No.

I am currently test running it on all packages against the 10 
latest dmd releases (I have done 6k packages on and off since 2 
days ago). But I am running into vibe.d issues/missing features. 
Things like not being able to use gzip with requestHttp (let 
alone with a RestInterfaceClient), invalid internal state with 
the http client pool on interrupting requests, and some other 
things.


Also, I am writing a PR for vibe.d to send http request to unix 
sockets.



How to deploy then?


For the worker it's just a docker container. But until the unix 
sockets PR is done you do have to setup the docker daemon to 
listen on the docker0 interface.



I need to test
https://github.com/dlang/druntime/pull/1602 and otherwise have 
to resetup my project tester for that.


I am using digger to build dmd, so adding in the pull request is 
trivial. I do need to adjust internals to properly handle it 
though.


But alas, family is coming over so don't expect anything anytime 
soon.


Yes, but from past experience we know that people don't look at 
results, if you don't make it part of PR acceptance.


So true. Then I will do PR's first.

Re: Unexpected foreach lowering

[Ali Çehreli via Digitalmars-d-learn]

On 08/10/2016 11:08 AM, Lodovico Giaretta wrote:
> I'm probably missing something stupid but...
> Why on earth do the two loops in main print a different result?
> It looks like the foreach lowering is ignoring my definition of front...
>
> =
> import std.stdio, std.container.array;
>
> struct RangeWrapper(Range)
> {
> Range range;
> alias range this;
>
> auto front()
> {
> return range.front + 1;
> }
> }
> auto rangeWrapper(Range)(auto ref Range range)
> {
> return RangeWrapper!Range(range);
> }
>
> void main()
> {
> Array!int array;
> array.insertBack(3);
>
> foreach (i; rangeWrapper(array[]))
> writeln(i);   // prints 3, which is wrong
>
> // isn't the above foreach equivalent to the following loop ?
>
> for (auto r = rangeWrapper(array[]); !r.empty; r.popFront())
> writeln(r.front); // correctly prints 4
> }
> =
>
> Thank you for your help.

RangeWrapper does not provide the InputRange interface, so the compiler 
uses 'alias this' and iterates directly on the member range.


I tried making RangeWrapper an InputRange but failed. It still uses 'range'.

// Still fails with these:
@property bool empty() {
return range.empty;
}

void popFront() {
range.popFront();
}

I don't know how the decision process works there.

Ali

Re: I'll be back soon

[Daniel Kozak via Digitalmars-d]

Dne 10.8.2016 v 14:52 Ilya Yaroshenko via Digitalmars-d napsal(a):


On Wednesday, 10 August 2016 at 10:33:11 UTC, Martin Nowak wrote:

On Wednesday, 10 August 2016 at 05:49:55 UTC, Ilya Yaroshenko wrote:
In addition, most of functions has very different API comparing with 
their prototypes from std.algorithms: multiple dimensions, multiple 
tensors, selection type, plus ndFind accepts static array as the 
first argument.


Overloads from different modules don't conflict when it's not 
possible to one of them. So if all of ndslice.algorithm functions 
only work with ndslices, and none of std.algorithm functions work 
with ndslices, you're fine.
I'd even consider forwarding std.algorithm.searching.find to 
ndslice.algorithm.find a better solution than adding awkward prefixes 
that look like we're using C.


I haven't yet used ndslice much though.


This is true for find, but not true for other algorithms, because of 
two reasons:


1. std.algorithm works with ndslices because ndslices is random access 
ranges composed of n-1-dimensional elements.

2. most of algorithms are super-templates:
 a. template map(fun...)
 b. template ndMap(fun...)
so they would not work with the same namespace if names are identical.

But one can still do something like:

import nd = std.experimental.ndslice;
// now I can use nd.map which is not so different from ndMap
// and there could be some special module with aliases for those who are 
unable

// to use one char '.' extra :)
module std.experimental.ndslice.aliases;
alias ndMap = nd.map;
...


So I am against prefixes in func names like ndMap and so.

Let us talk about error messages

[qznc via Digitalmars-d]

Rust changed their error message format:

https://blog.rust-lang.org/2016/08/10/Shape-of-errors-to-come.html

Inspiration for D?

Re: Unexpected foreach lowering

[Lodovico Giaretta via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 18:08:02 UTC, Lodovico Giaretta 
wrote:

I'm probably missing something stupid but...
Why on earth do the two loops in main print a different result?
It looks like the foreach lowering is ignoring my definition of 
front...


=
import std.stdio, std.container.array;

struct RangeWrapper(Range)
{
Range range;
alias range this;

auto front()
{
return range.front + 1;
}
}
auto rangeWrapper(Range)(auto ref Range range)
{
return RangeWrapper!Range(range);
}

void main()
{
Array!int array;
array.insertBack(3);

foreach (i; rangeWrapper(array[]))
writeln(i);   // prints 3, which is wrong

// isn't the above foreach equivalent to the following 
loop ?


for (auto r = rangeWrapper(array[]); !r.empty; r.popFront())
writeln(r.front); // correctly prints 4
}
=

Thank you for your help.


This actually only happens with std.container.Array. Other ranges 
are ok. Even stranger...

Unexpected foreach lowering

[Lodovico Giaretta via Digitalmars-d-learn]

I'm probably missing something stupid but...
Why on earth do the two loops in main print a different result?
It looks like the foreach lowering is ignoring my definition of 
front...


=
import std.stdio, std.container.array;

struct RangeWrapper(Range)
{
Range range;
alias range this;

auto front()
{
return range.front + 1;
}
}
auto rangeWrapper(Range)(auto ref Range range)
{
return RangeWrapper!Range(range);
}

void main()
{
Array!int array;
array.insertBack(3);

foreach (i; rangeWrapper(array[]))
writeln(i);   // prints 3, which is wrong

// isn't the above foreach equivalent to the following 
loop ?


for (auto r = rangeWrapper(array[]); !r.empty; r.popFront())
writeln(r.front); // correctly prints 4
}
=

Thank you for your help.

Re: August Boston D users meetup

[Andrei Alexandrescu via Digitalmars-d-announce]

On 08/10/2016 01:12 PM, Steven Schveighoffer wrote:

On 8/1/16 10:11 AM, Steven Schveighoffer wrote:

I posted this a while ago, forgot to announce. Please join us if you are
in the area! Already 5 going.

http://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/232865668/



Another ping. Happening tomorrow!

-Steve


I'll be there! -- Andrei

[Issue 16372] New: Broken links in documentation

[via Digitalmars-d-bugs]

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

  Issue ID: 16372
   Summary: Broken links in documentation
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: trivial
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: vmal...@gmail.com

Errant "" causes broken links (e.g.
https://dlang.org/phobos/std_stdio.html#.readf)

--

[Issue 16369] [REG 2.071] getSymbolsByUDA fails if type inherits private members

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #2 from Martin Nowak  ---
At least the visibility warnings are related to Issue 15907 and should not
appear, if people had correctly used `__traits(getMember, T, name)`.

--

[Issue 12936] Some more @nogc cases for immediately iterated array literal

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dmd/commit/6a48d5bb77be35a3778c7ad67de232b2e9c8
Issue 12936 - Some more @nogc cases for immediately iterated array literal

Support case#2 in bugzilla.

https://github.com/dlang/dmd/commit/46c35125b335354077c11973389c7e82686036ff
Merge pull request #5795 from 9rnsr/fix12936

Issue 12936 - Some more @nogc cases for immediately iterated array literal

--

Re: D Github contributors - enable 2 factor authentification

[Jesse Phillips via Digitalmars-d]

On Wednesday, 10 August 2016 at 04:20:51 UTC, Walter Bright wrote:

https://news.ycombinator.com/item?id=12259176

Apparently github users are increasingly being targeted.


2 Factor Auth is pretty accessible now days. Definitely enable 
for Gmail to if you're using that service.


I'd recommend using Yubikey, but the two places I've been able to 
make use of it is a paid for LastPass account and Github. If you 
do go for a key, choose one with U2F. These keys don't get 
firmware updates so as they develop new technology on the key it 
requires buying a new key.


https://www.yubico.com/

Re: Ddoc to HTML tool?

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

On Wednesday, 10 August 2016 at 17:04:20 UTC, Jacob Carlborg 
wrote:
Thanks, I didn't know that. It's not ideal, it adds some other 
tags that I would like to avoid, i.e. "Page generated by Ddoc", 
but it works.


those are in the macro definition file, you can make your own and 
simplify/improve.

Re: [OT] Live coding sessions

[Wild via Digitalmars-d]

On Wednesday, 10 August 2016 at 16:19:46 UTC, Steven 
Schveighoffer wrote:

On 8/10/16 7:17 AM, Walter Bright wrote:

https://www.livecoding.tv/wild/videos/evGmx-operating-system-development-d-programming-223


Do people really like this? I have so much to do, I have no 
time to watch others code. No offense meant to others, I'm just 
curious about it.


I also have no interest in having others watch me code, it 
would be brutal :) For one, I take a lot of breaks and walk 
around to think...


-Steve


Well it all depends on what I'm streaming, If I stream planning 
basically no one
watches, but if I'm coding and something graphical is happening 
people watch.
If I recall correctly I had a bit peek with ~30-40 viewers when I 
implemented text

and bitmap rendering.

Re: C-binding external array.

[ciechowoj via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 15:07:52 UTC, Ali Çehreli wrote:

On 08/10/2016 02:05 AM, ciechowoj wrote:
Better with some mixin magic:

mixin template CArray(string symbol, T) {
pragma(mangle, symbol) extern extern(C) __gshared
mixin ("T[0] _c" ~ symbol ~ ";");

@property
mixin ("T* " ~ symbol ~ "() { return _c" ~ symbol ~ ".ptr; 
}");

}

mixin CArray!("tab", int);

tab[42] = 42;



This is very tempting to use. The only thing that stops me from 
doing that is I am unsure if the 'property' tab behaves in all 
contexts the same way the standard array behaves.

Re: Ddoc to HTML tool?

[Jacob Carlborg via Digitalmars-d-learn]

On 10/08/16 16:48, Kagamin wrote:

dmd generates html from dd files; example:
https://github.com/dlang/dlang.org/blob/master/download.dd


Thanks, I didn't know that. It's not ideal, it adds some other tags that 
I would like to avoid, i.e. "Page generated by Ddoc", but it works.


--
/Jacob Carlborg

Re: [OT] Live coding sessions

[Meta via Digitalmars-d]

On Wednesday, 10 August 2016 at 16:19:46 UTC, Steven 
Schveighoffer wrote:

On 8/10/16 7:17 AM, Walter Bright wrote:

https://www.livecoding.tv/wild/videos/evGmx-operating-system-development-d-programming-223


Do people really like this? I have so much to do, I have no 
time to watch others code. No offense meant to others, I'm just 
curious about it.


I also have no interest in having others watch me code, it 
would be brutal :) For one, I take a lot of breaks and walk 
around to think...


-Steve


Living vicariously (or not) through other people is becoming 
increasingly popular these days. There are livestreams for 
videogames, eating, graphic editing, drawing, recording music, 
painting, coding, etc.

Re: Template method in interfaces

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/10/16 12:41 PM, Arafel wrote:


I have to say that the fact that this compiles at all seems like a bug
to me according to [1], even more so that the method in A is called:



That is definitely a bug. D ignores many misplaced attributes, but not 
override.


-Steve

Re: [OT] The forum website should have more meta tags to allow other sites to embed it

[Seb via Digitalmars-d]

On Wednesday, 10 August 2016 at 16:09:16 UTC, WebFreak001 wrote:
For example right now if you post a forum link on some social 
media network or in some chat like skype or discord it will 
most of the time don't show any additional info to the link or 
just the meta description tag.


(For example on discord it looks like this right now: 
https://i.webfreak.org/ftDPWs)


It would be much cooler if it would show the post that the URL 
is pointing to with the title, content and author + profile 
picture. Google would probably also rank the forum pages higher 
then and they might even stop with suggesting golang over dlang 
(ok maybe that's a bit too unrealistic)


I don't know which specification discord is following but to 
support multiple providers the forum website should probably 
add a few head¹ tags for SEO and implement a few more formats 
for social networks/modern chat clients².


This would make it much easier to share forum urls without 
getting confused which url was what and it would improve the 
ranking on search engines.


¹: https://github.com/joshbuchea/HEAD lots of head tags, 
especially for SEO
²: https://github.com/joshbuchea/HEAD#social some formats to 
allow getting some information about the url


Very valid point ;-)
Issues/enhancement request for the forum should go to DFeed.
(if you send CyberShadow directly a PR, it should land live a lot 
faster).


https://github.com/CyberShadow/DFeed

BTW I made a similar enhancement request for the D Blog quite 
recently:


https://github.com/dlang/D-Blog-Theme/issues/19

Re: Template method in interfaces

[Arafel via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 15:52:29 UTC, Lodovico Giaretta 
wrote:
On Wednesday, 10 August 2016 at 15:48:10 UTC, Lodovico Giaretta 
wrote:

On Wednesday, 10 August 2016 at 15:39:19 UTC, Arafel wrote:
Would it even make sense to "force" (deprecation warning) a 
"final" keyword in any implicitly-final function (I wasn't 
even aware of those, I have to admit)? It would make things 
much clearer, like with "override"...


I read the spec again, and found out that it says interfaces 
cannot contain templated functions... So either my 
interpretation is the intended one and the spec is outdated, 
or the spec is right and the compiler is bugged.


Anyway what I said about implicit final is true for classes. In 
classes, I don't like the idea of having to put an explicit 
final, but this is debatable. For interfaces, I'm ok with 
forcing an explicit final attribute (but as I said the spec 
does not allow templated functions in interfaces, even if the 
compiler does).


I have to say that the fact that this compiles at all seems like 
a bug to me according to [1], even more so that the method in A 
is called:


---
import std.stdio;

public class A {
public void func(T)(T t) {
writeln("Within A");
}
}

public class B : A {
override public void func(T)(T t) {
writeln("Within B");
}
}

void main() {
A a = new B();
a.func(1);
}
---

https://dpaste.dzfl.pl/f3d5beff2e51

If the function is "final", even if implicitly so, the "override" 
should fail according to the spec as I, and I guess 99% of the 
people[2], understand it.


[1]: https://dlang.org/spec/function.html#virtual-functions
[2]: OK, technically not, since it just says that "Functions 
marked as final may not be overridden in a derived class [...]" 
and this function is not *marked* as final, but implicitly 
final... still...

[Issue 16370] outdated spec: templated functions allowed in interfaces and functions

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

Summary|outdated spec: templated|outdated spec: templated
   |functions allowed in|functions allowed in
   |interfaces  |interfaces and functions

--- Comment #3 from Steven Schveighoffer  ---
The limitation that templates can't be inside functions also is no longer true!

--

[Issue 16371] warn/deprecate implicit final in interfaces

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
I don't think this makes sense. Templates can never add virtual functions or
non-static members, even to classes. Why should it be different for interfaces?

--

[Issue 16370] outdated spec: templated functions allowed in interfaces

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

Summary|spec on templates ambiguous |outdated spec: templated
   |as to not allowing member   |functions allowed in
   |fields in interfaces|interfaces

--

[Issue 16370] spec on templates ambiguous as to not allowing member fields in interfaces

[via Digitalmars-d-bugs]

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

--- Comment #2 from Steven Schveighoffer  ---
Whoops! I misread the docs. I'll update the PR and restore the original
description. I still like my PR change, as to be clearer.

--

[Issue 16371] warn/deprecate implicit final in interfaces

[via Digitalmars-d-bugs]

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

Lodovico Giaretta  changed:

   What|Removed |Added

 CC||lodov...@giaretart.net
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16370

--

[Issue 16370] outdated spec: templated functions allowed in interfaces

[via Digitalmars-d-bugs]

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

Lodovico Giaretta  changed:

   What|Removed |Added

   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=16371

--

Re: Decimal/Currency Type

[Gary Willoughby via Digitalmars-d]

On Tuesday, 9 August 2016 at 10:48:50 UTC, Zane wrote:
There has been a question or two about this before, but I 
really don't feel there has been a reasonable answer (or I have 
missed it).


[...]


There is one in the review queue since forever.

https://wiki.dlang.org/Review_Queue

Maybe take a look at that?

[OT] Live coding sessions

[Steven Schveighoffer via Digitalmars-d]

On 8/10/16 7:17 AM, Walter Bright wrote:

https://www.livecoding.tv/wild/videos/evGmx-operating-system-development-d-programming-223


Do people really like this? I have so much to do, I have no time to 
watch others code. No offense meant to others, I'm just curious about it.


I also have no interest in having others watch me code, it would be 
brutal :) For one, I take a lot of breaks and walk around to think...


-Steve

Re: D Github contributors - enable 2 factor authentification

[Steven Schveighoffer via Digitalmars-d]

On 8/10/16 12:20 AM, Walter Bright wrote:

https://news.ycombinator.com/item?id=12259176

Apparently github users are increasingly being targeted.


Done. Didn't realize about this issue, of course, probably shouldn't use 
a crappy password on your DNS server...


In any case, should be 0 impact, since all my github traffic goes via 
ssh key.


-Steve

Re: This fellow is writing an operating system in D live

[Wild via Digitalmars-d]

On Wednesday, 10 August 2016 at 15:11:52 UTC, Enamex wrote:

On Wednesday, 10 August 2016 at 14:03:22 UTC, Wild wrote:

Thanks for posting a link to my lastest VOD :)
Here is all of my past streams: 
https://www.livecoding.tv/wild/playlists/lpVPZ-powernex-os-development/
You should be able to watch the whole development of PowerNex 
from those videos.


If anybody wants to read the code it is located here: 
https://github.com/Vild/PowerNex


Are they available on Youtube or something similar? I can't 
find a way on livecoding.tv to decrease the resolution and it's 
putting a lot of strain on my connection.


If you're narrating it I could probably follow along at 480p or 
something. And the code is apparently open source so I can see 
that.


I don't know if I can upload the VODs to YouTube because I have 
music in the background of each stream and I don't know if it is 
YouTube safe.


But I guess I could try, hopefully it will work without any 
problems

[Issue 16370] outdated spec: templated functions allowed in interfaces

[via Digitalmars-d-bugs]

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

Lodovico Giaretta  changed:

   What|Removed |Added

 CC||lodov...@giaretart.net

--

[Issue 16370] New: outdated spec: templated functions allowed in interfaces

[via Digitalmars-d-bugs]

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

  Issue ID: 16370
   Summary: outdated spec: templated functions allowed in
interfaces
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: spec
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: lodov...@giaretart.net

The last line of this page [1] says that interfaces cannot contain templated
functions (and suggest the compiler should raise an error).
But DMD allows templated functions in interfaces, making them implicitly final.
>From a thread [2] it looks like this was a conscious addition, so the spec
shall be updated.

[1] https://dlang.org/spec/template.html#limitations
[2] http://forum.dlang.org/post/wmnsqhzrzihgfrahf...@forum.dlang.org

--

[OT] The forum website should have more meta tags to allow other sites to embed it

[WebFreak001 via Digitalmars-d]

For example right now if you post a forum link on some social 
media network or in some chat like skype or discord it will most 
of the time don't show any additional info to the link or just 
the meta description tag.


(For example on discord it looks like this right now: 
https://i.webfreak.org/ftDPWs)


It would be much cooler if it would show the post that the URL is 
pointing to with the title, content and author + profile picture. 
Google would probably also rank the forum pages higher then and 
they might even stop with suggesting golang over dlang (ok maybe 
that's a bit too unrealistic)


I don't know which specification discord is following but to 
support multiple providers the forum website should probably add 
a few head¹ tags for SEO and implement a few more formats for 
social networks/modern chat clients².


This would make it much easier to share forum urls without 
getting confused which url was what and it would improve the 
ranking on search engines.


¹: https://github.com/joshbuchea/HEAD lots of head tags, 
especially for SEO
²: https://github.com/joshbuchea/HEAD#social some formats to 
allow getting some information about the url

Re: Template method in interfaces

[Lodovico Giaretta via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 15:54:42 UTC, Adam D. Ruppe wrote:
On Wednesday, 10 August 2016 at 15:48:10 UTC, Lodovico Giaretta 
wrote:
I read the spec again, and found out that it says interfaces 
cannot contain templated functions... So either my 
interpretation is the intended one and the spec is outdated, 
or the spec is right and the compiler is bugged.


Spec must be out of date, I remember this being a conscious 
decision to add them.


Last line of this page: 
https://dlang.org/spec/template.html#limitations


I'll file a bug report for this and an enhancement request for 
implicit final in interfaces.

Re: Template method in interfaces

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

On Wednesday, 10 August 2016 at 15:48:10 UTC, Lodovico Giaretta 
wrote:
I read the spec again, and found out that it says interfaces 
cannot contain templated functions... So either my 
interpretation is the intended one and the spec is outdated, or 
the spec is right and the compiler is bugged.


Spec must be out of date, I remember this being a conscious 
decision to add them.

Re: Template method in interfaces

[Lodovico Giaretta via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 15:48:10 UTC, Lodovico Giaretta 
wrote:

On Wednesday, 10 August 2016 at 15:39:19 UTC, Arafel wrote:
Would it even make sense to "force" (deprecation warning) a 
"final" keyword in any implicitly-final function (I wasn't 
even aware of those, I have to admit)? It would make things 
much clearer, like with "override"...


I read the spec again, and found out that it says interfaces 
cannot contain templated functions... So either my 
interpretation is the intended one and the spec is outdated, or 
the spec is right and the compiler is bugged.


Anyway what I said about implicit final is true for classes. In 
classes, I don't like the idea of having to put an explicit 
final, but this is debatable. For interfaces, I'm ok with forcing 
an explicit final attribute (but as I said the spec does not 
allow templated functions in interfaces, even if the compiler 
does).

Re: Template method in interfaces

[Lodovico Giaretta via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 15:39:19 UTC, Arafel wrote:
On Wednesday, 10 August 2016 at 15:25:40 UTC, Lodovico Giaretta 
wrote:
Because templated functions cannot be virtual, it follows that 
I.func is final. Having no body, the compiler thinks that its 
body will be found by the linker in another object file, but 
this does not happen, so the linker complains.
Being I.func final, C.func just hides it, so you would not 
incur any problem if you called func explicitly on an object 
of type C.


So what you found is not a bug, but some unintuitive behaviour 
due to templated functions being implicitly final and forward 
declarations. Maybe the compiler should emit a warning about 
implicitly-final functions in interfaces.


Would it even make sense to "force" (deprecation warning) a 
"final" keyword in any implicitly-final function (I wasn't even 
aware of those, I have to admit)? It would make things much 
clearer, like with "override"...


I read the spec again, and found out that it says interfaces 
cannot contain templated functions... So either my interpretation 
is the intended one and the spec is outdated, or the spec is 
right and the compiler is bugged.

Re: Template method in interfaces

[Arafel via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 15:25:40 UTC, Lodovico Giaretta 
wrote:
Because templated functions cannot be virtual, it follows that 
I.func is final. Having no body, the compiler thinks that its 
body will be found by the linker in another object file, but 
this does not happen, so the linker complains.
Being I.func final, C.func just hides it, so you would not 
incur any problem if you called func explicitly on an object of 
type C.


So what you found is not a bug, but some unintuitive behaviour 
due to templated functions being implicitly final and forward 
declarations. Maybe the compiler should emit a warning about 
implicitly-final functions in interfaces.


Would it even make sense to "force" (deprecation warning) a 
"final" keyword in any implicitly-final function (I wasn't even 
aware of those, I have to admit)? It would make things much 
clearer, like with "override"...

Re: 101 BASIC Computer Games - In D?

[bachmeier via Digitalmars-d]

On Wednesday, 10 August 2016 at 11:14:58 UTC, Walter Bright wrote:

This book is the granddaddy of all the computer game books.

https://archive.org/details/bitsavers_decBooks10Mar75_26006648

They are a bunch of simple text mode games. They're a great way 
to learn programming while having some fun.


I've idly thought that it would be a great vehicle for teaching 
D to kids. (That is, if any kids these days would have the 
remotest interest in a text mode game.) It's sometimes 
surprising to me how compact these games are that still do 
something clever.


Note that the listings have been OCR'd (in the downloadable 
PDF), which would make them a lot easier to cut/paste the code 
into an editor then translate away.


It would also give us example code making heavy usage of goto 
statements. goto is badly underutilized by our community. For 
that matter, we don't have enough spaghetti code examples to make 
programmers from other languages comfortable.

Re: Template method in interfaces

[Lodovico Giaretta via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 15:20:37 UTC, Arafel wrote:
I'm not sure if the following is even expected to work, since 
I'm not sure how the vtable for the interface would look like 
(well, that would be applicable to any overriden templated 
method, though):


---
public interface I {
void func(T)(T t);
}

public class C : I {
void func(T)(T t) {
}
}

void main() {
I i = new C();
i.func(1);
}
---

But since the error I get is in the linker, and not in the 
compiler, I guess that's somehow a bug? Or how should it work 
then?


https://dpaste.dzfl.pl/7a14fa074673

/d31/f76.o: In function `_Dmain': 
/d31/f76.d:(.text._Dmain+0x24): undefined reference to 
`_D3f761I11__T4funcTiZ4funcMFiZv' collect2: error: ld returned 
1 exit status --- errorlevel 1


PS: Now I see [1] that it shouldn't, so perhaps the compiler 
should reject templated methods in interfaces from the 
beginning?


[1]: http://forum.dlang.org/post/jg504s$1f7t$1...@digitalmars.com


Because templated functions cannot be virtual, it follows that 
I.func is final. Having no body, the compiler thinks that its 
body will be found by the linker in another object file, but this 
does not happen, so the linker complains.
Being I.func final, C.func just hides it, so you would not incur 
any problem if you called func explicitly on an object of type C.


So what you found is not a bug, but some unintuitive behaviour 
due to templated functions being implicitly final and forward 
declarations. Maybe the compiler should emit a warning about 
implicitly-final functions in interfaces.

Template method in interfaces

[Arafel via Digitalmars-d-learn]

I'm not sure if the following is even expected to work, since I'm 
not sure how the vtable for the interface would look like (well, 
that would be applicable to any overriden templated method, 
though):


---
public interface I {
void func(T)(T t);
}

public class C : I {
void func(T)(T t) {
}
}

void main() {
I i = new C();
i.func(1);
}
---

But since the error I get is in the linker, and not in the 
compiler, I guess that's somehow a bug? Or how should it work 
then?


https://dpaste.dzfl.pl/7a14fa074673

/d31/f76.o: In function `_Dmain': /d31/f76.d:(.text._Dmain+0x24): 
undefined reference to `_D3f761I11__T4funcTiZ4funcMFiZv' 
collect2: error: ld returned 1 exit status --- errorlevel 1


PS: Now I see [1] that it shouldn't, so perhaps the compiler 
should reject templated methods in interfaces from the beginning?


[1]: http://forum.dlang.org/post/jg504s$1f7t$1...@digitalmars.com

Re: This fellow is writing an operating system in D live

[Enamex via Digitalmars-d]

On Wednesday, 10 August 2016 at 14:03:22 UTC, Wild wrote:

Thanks for posting a link to my lastest VOD :)
Here is all of my past streams: 
https://www.livecoding.tv/wild/playlists/lpVPZ-powernex-os-development/
You should be able to watch the whole development of PowerNex 
from those videos.


If anybody wants to read the code it is located here: 
https://github.com/Vild/PowerNex


Are they available on Youtube or something similar? I can't find 
a way on livecoding.tv to decrease the resolution and it's 
putting a lot of strain on my connection.


If you're narrating it I could probably follow along at 480p or 
something. And the code is apparently open source so I can see 
that.

Re: C-binding external array.

[Ali Çehreli via Digitalmars-d-learn]

On 08/10/2016 02:05 AM, ciechowoj wrote:

On Tuesday, 9 August 2016 at 19:16:42 UTC, Steven Schveighoffer wrote:


D has an answer:

pragma(mangle, "tab")
extern extern(C) int[1] _ctab;

@property int* tab() { return _ctab.ptr; }

I still don't recommend doing this, for previously stated reasons.



This is really interesting :).


Better with some mixin magic:

mixin template CArray(string symbol, T) {
pragma(mangle, symbol) extern extern(C) __gshared
mixin ("T[0] _c" ~ symbol ~ ";");

@property
mixin ("T* " ~ symbol ~ "() { return _c" ~ symbol ~ ".ptr; }");
}

mixin CArray!("tab", int);

tab[42] = 42;

Ali

Re: Ddoc to HTML tool?

[Kagamin via Digitalmars-d-learn]

dmd generates html from dd files; example: 
https://github.com/dlang/dlang.org/blob/master/download.dd

[Issue 15335] getSymbolsByUDA fails if type has private members

[via Digitalmars-d-bugs]

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

--- Comment #7 from Johan Engelen  ---
PR is https://github.com/dlang/phobos/pull/3827

--

Ddoc to HTML tool?

[Jacob Carlborg via Digitalmars-d-learn]

What's the best way to generate HTML from a snippet of Ddoc? I've 
extracted the Ddoc from a symbol using DCD and would like to display it 
in a text editor. Ideally it should be a command line tool.


--
/Jacob Carlborg

[Issue 16369] [REG 2.071] getSymbolsByUDA fails if type inherits private members

[via Digitalmars-d-bugs]

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

--- Comment #1 from Sobirari Muhomori  ---
PR was https://github.com/dlang/phobos/pull/3827 (specified in the commit)

--

Re: Best way of checking for a templated function instantiation

[Meta via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 13:57:54 UTC, Arafel wrote:

On Wednesday, 10 August 2016 at 13:40:30 UTC, Meta wrote:

On Wednesday, 10 August 2016 at 13:37:47 UTC, Meta wrote:
static assert(__traits(compiles, auto _ = 
S.init.opBinary!"+"(int.init));


Made a typo, this should be:

static assert(__traits(compiles, { auto _ = 
S.init.opBinary!"+"(int.init); }));


Hi!

Thanks, that would do! Just out of curiosity, would there be 
any way to check just that the function is defined, like what 
"hasMember" would do, without caring about argument number, 
types, etc.? Ideally something like:


__traits(hasMember, S, "opBinary!\"+\"")


Unfortunately you're stuck using __traits(compiles) as 
`opBinary!"+"` is not a symbol.


static assert(__traits(compiles, { alias _ = S.opBinary!"+"; }));

Re: Best way of checking for a templated function instantiation

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, August 10, 2016 13:57:54 Arafel via Digitalmars-d-learn wrote:
> On Wednesday, 10 August 2016 at 13:40:30 UTC, Meta wrote:
> > On Wednesday, 10 August 2016 at 13:37:47 UTC, Meta wrote:
> >> static assert(__traits(compiles, auto _ =
> >> S.init.opBinary!"+"(int.init));
> >
> > Made a typo, this should be:
> >
> > static assert(__traits(compiles, { auto _ =
> > S.init.opBinary!"+"(int.init); }));
>
> Hi!
>
> Thanks, that would do! Just out of curiosity, would there be any
> way to check just that the function is defined, like what
> "hasMember" would do, without caring about argument number,
> types, etc.? Ideally something like:
>
> __traits(hasMember, S, "opBinary!\"+\"")

__traits(allMembers, S) would give "opBinary", so I don't think so. You can
check that the type defined an overloaded binary operator but not which one.

- Jonathan M Davis

Re: This fellow is writing an operating system in D live

[Wild via Digitalmars-d]

On Wednesday, 10 August 2016 at 11:17:58 UTC, Walter Bright wrote:

https://www.livecoding.tv/wild/videos/evGmx-operating-system-development-d-programming-223

!!


Thanks for posting a link to my lastest VOD :)
Here is all of my past streams: 
https://www.livecoding.tv/wild/playlists/lpVPZ-powernex-os-development/
You should be able to watch the whole development of PowerNex 
from those videos.


If anybody wants to read the code it is located here: 
https://github.com/Vild/PowerNex

Re: Best way of checking for a templated function instantiation

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, August 10, 2016 12:36:14 Arafel via Digitalmars-d-learn wrote:
> Hi,
>
> I'm trying to check at compilation time if a given type
> implements some operator (let's assume it's '+' in this case),
> without caring about the type of the parameters it accepts. Since
> operator overloading is expressed in D through templated
> functions, what is the preferred way of checking if a template is
> / can be instantiated with a given parameter list?
>
> So far I've come with a solution using __trait(compiles, ...),
> but perhaps it's not 100% reliable -I'm no expert in template
> wizardry-, or there are better options. I also tried with
> hasMember, but it apparantly only shows that "opBinary" is indeed
> present, but nothing more:
>
> ---
> void main() {
>   struct S {
>   int opBinary(string op)(int i) if (op == "+") {
>   return 0;
>   }
>   }
>
>   static assert(__traits(compiles, S.opBinary!"+"));
>   static assert(!__traits(compiles, S.opBinary!"-"));
> }
> ---

I'd advise against checking for opBinary in general, because it'll only work
with user-defined types, whereas a built-in type may define the operator.
It's usually better to test that the operator works rather than that
opBinary exists.  So, you end up with checks like __traits(compiles, lhs +
rhs) or __traits(compiles, T.init + T.init). If you're picky about the
return type, you can do stuff like __traits(compiles, T t = T.init + T.init)
(that might require braces around the statement along with a semicolon; I
don't remember). If you test for it enough, you can create an eponymous
template that wraps the test so that you just have to do something like
hasAdd!T or hasBinaryOp!("+", T). That's basically what you get with traits
like isInputRange. They're eponymous templates that wrap tests that use
is(typeof(...)) or __traits(compiles, ...) to test that a particular block
of code or expression compiles, but wrapping that in an eponymous template
makes it more idiomatic and makes it so that you don't have to duplicate the
implementation of the check everywhere (which is important if the check
isn't simple).

- Jonathan M Davis

Re: Best way of checking for a templated function instantiation

[Arafel via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 13:40:30 UTC, Meta wrote:

On Wednesday, 10 August 2016 at 13:37:47 UTC, Meta wrote:
static assert(__traits(compiles, auto _ = 
S.init.opBinary!"+"(int.init));


Made a typo, this should be:

static assert(__traits(compiles, { auto _ = 
S.init.opBinary!"+"(int.init); }));


Hi!

Thanks, that would do! Just out of curiosity, would there be any 
way to check just that the function is defined, like what 
"hasMember" would do, without caring about argument number, 
types, etc.? Ideally something like:


__traits(hasMember, S, "opBinary!\"+\"")

Re: Best way of checking for a templated function instantiation

[Meta via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 13:37:47 UTC, Meta wrote:
static assert(__traits(compiles, auto _ = 
S.init.opBinary!"+"(int.init));


Made a typo, this should be:

static assert(__traits(compiles, { auto _ = 
S.init.opBinary!"+"(int.init); }));

Re: Best way of checking for a templated function instantiation

[Meta via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 12:36:14 UTC, Arafel wrote:

Hi,

I'm trying to check at compilation time if a given type 
implements some operator (let's assume it's '+' in this case), 
without caring about the type of the parameters it accepts. 
Since operator overloading is expressed in D through templated 
functions, what is the preferred way of checking if a template 
is / can be instantiated with a given parameter list?


So far I've come with a solution using __trait(compiles, ...), 
but perhaps it's not 100% reliable -I'm no expert in template 
wizardry-, or there are better options. I also tried with 
hasMember, but it apparantly only shows that "opBinary" is 
indeed present, but nothing more:


---
void main() {
struct S {
int opBinary(string op)(int i) if (op == "+") {
return 0;
}
}

static assert(__traits(compiles, S.opBinary!"+"));
static assert(!__traits(compiles, S.opBinary!"-"));
}
---


__traits(compiles) is pretty much the only way to do it. For 
example, if you want to check that S supports opBinary!"+"(int):


static assert(__traits(compiles, auto _ = 
S.init.opBinary!"+"(int.init));


And if you want to check that the return type is int or 
implicitly converts to int, you can change the `auto _ = ...` to 
`int _ = ...`. However, if you want to be more explicit about it, 
you can do the following:


import std.traits;

static assert(is(ReturnType!(S.opBinary!"+") == int)); //Change 
to `... : int` for implicit conversion checking

Re: Best way of checking for a templated function instantiation

[Nicholas Wilson via Digitalmars-d-learn]

On Wednesday, 10 August 2016 at 12:36:14 UTC, Arafel wrote:

Hi,

I'm trying to check at compilation time if a given type 
implements some operator (let's assume it's '+' in this case), 
without caring about the type of the parameters it accepts. 
Since operator overloading is expressed in D through templated 
functions, what is the preferred way of checking if a template 
is / can be instantiated with a given parameter list?


[...]


static assert(is(typeof(S()+42)));
static assert(!is(typeof(S()-42)));