Re: The Expressive C++17 Coding Challenge in D

[Seb via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 06:42:23 UTC, Arun 
Chandrasekaran wrote:
It takes a lot of time and effort to write such quality 
content. Thanks for detailed explanations.


Thanks :)
Now if we had a magic automaton that makes more of these ...

// import std.algorithm, std.exception, std.format, std.range, 
std.stdio;
Do you think it is worth mentioning about 
std.experimental.scripting in section 2?


Well, it hasn't been released yet, but maybe I get around writing 
another article ;-)
Also looking at the C++ "competitor", I think we aren't too bad 
off with a few modules for now:


---
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

using namespace std;
namespace fs = std::experimental::filesystem;
---


Syntax highlighting is missing in some snippets.


Thanks for the pointer. Fixed!

Re: The Expressive C++17 Coding Challenge in D

[Seb via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 07:11:08 UTC, Nicholas Wilson 
wrote:

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Cool! The contrast of the code is very low (very on light 
brown?),


Thanks for the feedback. Fixed!

[Issue 9978] Can override interface function

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

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #4 from Martin Nowak  ---
Also makes more sense to use override in case we support default methods in
interfaces (Java 8) at some point.

--

Re: The Expressive C++17 Coding Challenge in D

[Nicholas Wilson via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Cool! The contrast of the code is very low (very on light brown?),

Re: The Expressive C++17 Coding Challenge in D

[Arun Chandrasekaran via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


It takes a lot of time and effort to write such quality content. 
Thanks for detailed explanations.


// import std.algorithm, std.exception, std.format, std.range, 
std.stdio;
Do you think it is worth mentioning about 
std.experimental.scripting in section 2?


Syntax highlighting is missing in some snippets.

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #24 from Jonathan Marler  ---
> I have not thought about this thoroughly, but I suspect the core of a fix can 
> be along the lines of detecting that an explicit import of bar.d is done 
> using two different names in the same module.

After having a bit of a think I realized this still doesn't solve the problem. 
I can change the example to show that module order also changes
compilation...observe:

--- main.d
import ibar, ibaz;
void main()
{
ibarfunc();
ibazfunc();
}

--- ibar.d
import bar, std.stdio;
void ibarfunc()
{
writeln(thing);
}

--- ibaz.d
import baz, std.stdio;
void ibazfunc()
{
writeln(thing);
}

--- bar.d
module baz;
enum thing = "this is baz from bar.d";

--- baz.d
module bar;
enum thing = "this is bar from baz.d";


dmd ibar.d ibaz.d -run main.d
OUTPUT:
this is baz from bar.d
this is baz from bar.d

dmd ibaz.d ibar.d -run main.d
OUTPUT:
this is bar from baz.d
this is bar from baz.d


Note that in the case the same module is not imported with different names in
the same file.  So fixing that won't fix this issue.

--

Re: OT: Photo of a single atom by David Nadlinger wins top prize

[rikki cattermole via Digitalmars-d]

On 14/02/2018 1:11 AM, David Nadlinger wrote:

On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote:

David (aka klickverbot) is a longtime D contributor […]


… who is slightly surprised at the amount of media interest this has 
attracted. ;)


  — David



Congrats and well done!

Re: Vulkan

[rikki cattermole via Digitalmars-d]

On 13/02/2018 10:54 PM, Danni Coy wrote:


On Wed, Feb 14, 2018 at 8:20 AM, Ivan Trombley via Digitalmars-d 
> wrote:


I wanted to do some experimentation with Vulkan using D. None of the
projects that I found (derelict-vulkan, d-vulkan and erupted) work.

Are there D bindings to Vulkan that actually work?


strictly speaking you don't need a binding, you can access C code 
directly as long as you write compatible header definitions for the 
parts of vulkan you are actually using in your code.


Which is then called a binding ;)

Re: The Expressive C++17 Coding Challenge in D

[Seb via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 02:57:28 UTC, ketmar wrote:

Seb wrote:

Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


a typo:

writefln!"%d"(foo");

it should be `"foo"`, i guess. ;-)


Fixed. Thanks!

great article. now i want to learn D again, it looks so 
beautiful and powerful! ;-)


Thanks!
Well, you could upstream your fork and go back to "pure" D again 
;-)

Re: "Why Black Boxes are so Hard to Reuse?", a lecture by Gregor Kiczales

[Joakim via Digitalmars-d]

On Wednesday, 14 February 2018 at 01:20:24 UTC, Mark wrote:
I came across this one hour lecture [1] on Youtube. It's from 
1994, but I think it's still very relevant today, both to 
developers in general and to the D language in particular.


[...]


I have mentioned some related thoughts by a designer of Common 
Lisp here before:


https://forum.dlang.org/thread/jqbwxtdiyqqyzdthl...@forum.dlang.org

Re: The Expressive C++17 Coding Challenge in D

[Seb via Digitalmars-d-announce]

On Wednesday, 14 February 2018 at 03:40:41 UTC, jmh530 wrote:

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Typo with "(~200 LoC)" and "> 300 LoCs"?


Fixed. Thanks!

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #23 from Jonathan Marler  ---
> I have not thought about this thoroughly, but I suspect the core of a fix can 
> be along the lines of detecting that an explicit import of bar.d is done 
> using two different names in the same module.

I think you'll find that this is "easier said than done".  The name that was
used to import a module is no longer available once the import is processed. 
The compiler just adds the module to the proper location in thy symbol table
and moves on.

Essentially, you need a way to reverse a symbol lookup.  You need to be able to
take a Module object and lookup the name that was used to import it.  This will
require either a new list field for all imports, or a new list field for all
"importees", or you will need to walk the entire symbol table tree every time
you want to check if there is a conflict.

The place in the code where you would perform this check is in `dimport.d` in
the load function.  Near the top of the funciton there is a branch `if
(s.isModule()), and you can insert the check right there.

However, I don't know why we would go through all the trouble to support this.
You'd be adding a fair amount of runtime overhead for every import statement or
more memory to cache the reverse lookups.  Not to mention the extra complexity
this is going to introduce.  And the use case where this actually works is so
narrow, it only works if the module are not compiled in the same compiler
invocation...

--

Re: The Expressive C++17 Coding Challenge in D

[jmh530 via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


Typo with "(~200 LoC)" and "> 300 LoCs"?

[Issue 18436] New: broken opCast fails silently when used with std.conv.to

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

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

  Issue ID: 18436
   Summary: broken opCast fails silently when used with
std.conv.to
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: elpenguin...@gmail.com

Invalid code like the following will (correctly) fail to compile, but the error
preventing it from compiling will not be shown to the user.

struct X {
T opCast(T)() {
nonexistent();
return T.init;
} 
}

assert(X().to!bool == bool.init);

The compiler ought to complain about nonexistent being undefined instead of
simply failing to match toImpl's template declaration.

--

Re: The Expressive C++17 Coding Challenge in D

[ketmar via Digitalmars-d-announce]

Seb wrote:

Someone revived the Expressive C++17 Coding Challenge thread today and I 
thought this is an excellent opportunity to revive my blog and finally 
write an article showing why I like D so much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D features, but 
maybe it's helpful for beginners looking into D.


a typo:

writefln!"%d"(foo");

it should be `"foo"`, i guess. ;-)

great article. now i want to learn D again, it looks so beautiful and 
powerful! ;-)

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #22 from Timothee Cour  ---
I don't understand why the current behavior is desired.

Is there any single use case that can't be achieved without existing option
such as -mv?

-mv==  use  as source file for


--

Re: Vulkan

[Mike Parker via Digitalmars-d]

On Wednesday, 14 February 2018 at 02:40:18 UTC, Mike Parker wrote:



What doesn't it mean


Eh, what *does* it mean.

Re: Vulkan

[Mike Parker via Digitalmars-d]

On Tuesday, 13 February 2018 at 22:20:15 UTC, Ivan Trombley wrote:
I wanted to do some experimentation with Vulkan using D. None 
of the projects that I found (derelict-vulkan, d-vulkan and 
erupted) work.


Are there D bindings to Vulkan that actually work?


What doesn't it mean to say they don't work? Have you reported 
any issues? I don't see any in the DerelictVulkan repo. If 
something's broken, please report it so it can  be fixed.

Re: The Expressive C++17 Coding Challenge in D

[psychoticRabbit via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 23:35:36 UTC, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive 
my blog and finally write an article showing why I like D so 
much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.


What a great article!

I love the depth of explanation too, that really makes it 
worthwhile reading.

Re: OT: Photo of a single atom by David Nadlinger wins top prize

[Ali Çehreli via Digitalmars-d]

On 02/13/2018 05:11 PM, David Nadlinger wrote:

On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote:

David (aka klickverbot) is a longtime D contributor […]


… who is slightly surprised at the amount of media interest this has 
attracted. ;)


  — David


Yeah... Especially when it's all about a missing pixel. :p

Ali

"Why Black Boxes are so Hard to Reuse?", a lecture by Gregor Kiczales

[Mark via Digitalmars-d]

I came across this one hour lecture [1] on Youtube. It's from 
1994, but I think it's still very relevant today, both to 
developers in general and to the D language in particular.


A TL;DR summary of the lecture:
Abstraction is a central theme in software engineering, since it 
allows us to control complexity. However, most abstractions in 
software development do not (and cannot) completely hide their 
implementation; the implementation leaks via the performance 
characteristics of the abstraction. This is because the designer 
of the abstraction chose to implement its interface in some 
specific way, making design decisions that may be different than 
those that some clients would have wanted. The lecturer then 
suggests the following remedy:
In addition to providing the client with a suitable interface, we 
should also allow him to make changes to the implementation 
through a separate "meta interface", i.e. we should allow him to 
change some (or all) of our design decisions. The lecturer 
suggests making such a meta interface using reflection and OO 
techniques but doesn't go deep into that.


This reminds me a lot of D's Design by Introspection, and also of 
a previous paradigm that Andrei introduced to C++ (Policy Based 
Design [2]). C++ and Rust throw the phrase "zero cost 
abstractions" around but without good compile-time introspection 
support, you can't really get there - as soon as you make a 
non-trivial design decision you've limited the user of the 
abstraction in some way. For instance, the interfaces of Rust's 
HashMap [3] and C++'s unordered_map [4] do not allow for a custom 
collision handling policy. The Rust implementation uses Round 
Robin hashing while for C++ it isn't specified (as far as I can 
see). That said, Phobos doesn't have a hash table implementation 
at all so maybe this isn't the best example :=) Still, I think 
that D looks much better than them as far as "zero cost 
abstractions" go.



[1] https://www.youtube.com/watch?v=5l2wMgm7ZOk
[2] https://en.wikipedia.org/wiki/Policy-based_design
[3] https://doc.rust-lang.org/std/collections/struct.HashMap.html
[4] 
http://www.cplusplus.com/reference/unordered_map/unordered_map/

Re: OT: Photo of a single atom by David Nadlinger wins top prize

[Walter Bright via Digitalmars-d]

On 2/13/2018 5:11 PM, David Nadlinger wrote:

On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote:

David (aka klickverbot) is a longtime D contributor […]


… who is slightly surprised at the amount of media interest this has attracted. 
;)

  — David


You shouldn't be surprised. I'm amazed that such a photo is even possible!

You have done the impossible. Mad props to you!

-Walter

Re: Being Positive

[psychoticRabbit via Digitalmars-d]

On Tuesday, 13 February 2018 at 16:04:11 UTC, Abdulhaq wrote:


Psychotic rabbit disturbed by programming related video.
In other news


don't poke the rabbit.

Re: Multiple Alis

[Walter Bright via Digitalmars-d]

On 2/12/2018 8:33 PM, Nick Sabalausky (Abscissa) wrote:
I know another Ali I've tried to turn onto D, but he's pretty happy with Python. 
Oh, well.


I don't think he deserves the name Ali :-)

Re: OT: Photo of a single atom by David Nadlinger wins top prize

[David Nadlinger via Digitalmars-d]

On Tuesday, 13 February 2018 at 23:09:07 UTC, Ali Çehreli wrote:

David (aka klickverbot) is a longtime D contributor […]


… who is slightly surprised at the amount of media interest this 
has attracted. ;)


 — David

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #21 from Walter Bright  ---
(In reply to ag0aep6g from comment #19)

Thank you for providing a simple and clear test case to illustrate the issue.
It is indeed a problem that the order of imports is mattering, as this breaks a
fundamental tenet of D's import system.

I have not thought about this thoroughly, but I suspect the core of a fix can
be along the lines of detecting that an explicit import of bar.d is done using
two different names in the same module.

This is a lot more focused in effect than the PR.

--

Re: OT: Photo of a single atom by David Nadlinger wins top prize

[Manu via Digitalmars-d]

On 13 February 2018 at 15:09, Ali Çehreli via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> David (aka klickverbot) is a longtime D contributor.
>
>
> https://www.epsrc.ac.uk/newsevents/news/single-trapped-atom-
> captures-science-photography-competitions-top-prize/


I was just about to post that here :P

Re: The Expressive C++17 Coding Challenge in D

[Ali Çehreli via Digitalmars-d-announce]

On 02/13/2018 03:35 PM, Seb wrote:
Someone revived the Expressive C++17 Coding Challenge thread today and I 
thought this is an excellent opportunity to revive my blog and finally 
write an article showing why I like D so much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D features, 
but maybe it's helpful for beginners looking into D.


This topic appeared on Learn a few months ago:

  https://forum.dlang.org/post/or0o85$tvc$1...@digitalmars.com

Ali

Re: Vulkan

[flamencofantasy via Digitalmars-d]

On Tuesday, 13 February 2018 at 22:20:15 UTC, Ivan Trombley wrote:
I wanted to do some experimentation with Vulkan using D. None 
of the projects that I found (derelict-vulkan, d-vulkan and 
erupted) work.


Are there D bindings to Vulkan that actually work?


Maybe these work, not sure;

https://github.com/Rikarin/VulkanizeD

Re: rmdirRecurse - on NFS file system

[Vino via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 17:01:06 UTC, Seb wrote:

On Tuesday, 13 February 2018 at 16:58:09 UTC, Vino wrote:

On Monday, 12 February 2018 at 06:52:25 UTC, Vino wrote:

[...]


Hi All,

Was able to resolve this issue.


That's great!

BTW I think it would be helpful for future reader who find this 
thread to know how you resolved your problem.


Hi All,

I just modified the below lines of the code,

if (Step == "run" && !dFiles.empty) { dFiles.each!(f => 
rmdirRecurse(f[0])); } return dFiles;



From,
Vino.B

Re: dxml 0.2.0 released

[Jonathan M Davis via Digitalmars-d-announce]

On Tuesday, February 13, 2018 14:29:27 H. S. Teoh via Digitalmars-d-announce 
wrote:
> Given the insane complexities of DTD that I'm only slowly beginning to
> grasp from actually reading the spec, I'm quickly adopting the opinion
> that dxml should remain as-is, and any DTD implementation should be
> layered on top.  The only potential changes that might be needed is:
>
> - provide a way to parse XML snippets that don't have a 
>   declaration, so that a DTD implementation could, for example, hand an
>   entity body over to dxml to extract any tags that may be nested in
>   there (and if my reading of section 4.3.2 is correct, all such tags
>   must always be closed inside the entity body, so there should be no
>   errors produced).

XML 1.0 does not require the  section - which is the main reason
why dxml implements XML 1.0 and not 1.1. When working on one of my projects
with std_experimental_xml, I had to keep adding the  declaration
to the start of XML snippets in all of my tests which had to deal with
sections of an XML document, and it was _really_ annoying.

dxml does require that what it's given be a valid XML 1.0 document, which
means that you have to have exactly one root element in what it's passed,
which does limit which kind of XML snippets you pass it, but it will work
for a lot of XML snippets as-is.

> - provide some way of hooking into non-default entities so that
>   DTD-defined entities can be expanded by the DTD implementation.  This
>   could be as simple as leaving such entities untouched in the returned
>   range, or invent a special EntityType representing such entities (with
>   a slice of the input containing the entity name) so that the DTD
>   implementation can insert the replacement text.

After having actually implemented full parsing for the entire DTD section
before figuring out that references could be inserted in it just about
anywhere and that the grammar in the spec is only the grammar _after_ all of
the replacements were made (when I figured that out was when I gave up on
DTD support), I would strongly argue in favor of simply passing along entity
references as-is and leaving any and all such processing to a DTD-enabled
parser. Originally, the Config had options like SkipDTD and SkipProlog, and
I even provided a way to get at the information in the 
declaration if you wanted it, all that just wasn't worth the extra
complexity.

- Jonathan M Davis

Re: dxml 0.2.0 released

[Jonathan M Davis via Digitalmars-d-announce]

On Tuesday, February 13, 2018 14:13:36 H. S. Teoh via Digitalmars-d-announce 
wrote:
> Great, just
> great.   Now I know why I've always had this gut feeling that
> *something* is off about the whole XML mania.)

Well, there are plenty of folks who talk like XML is a pile of steaming muck
that should never be used (and then usually talk about how great JSON is). I
think that basic XML is actually pretty okay - basically the subset that
dxml supports, though if I were designing XML I'd take it a bit further.

Personally, I'd make XML documents completely recursive - meaning that the
top level is the same as any deeper level, so you could have as many element
tags at the top level as you want and as much text as you want, whereas XML
requires a root element and only allows stuff like processing instructions,
comments, and the DOCTYPE stuff outside of the root element.

I'd get rid of the  and  declarations as well as
processing instructions, and I'd probably get rid of the CDATA section in
favor of escaping characters with backslashes like you typically do in
strings (or in JSON), and related to that, I'd get rid of the predefined
entity references, making stuff like & legal. I also might get rid of empty
element tags becase they're annoying to deal with when parsing, but they do
reduce the verbosity of the document such that they might be worth keeping.
It's also tempting to get rid of the tag name on end tags, which would
actually make parsing much easier, but having them helps the legibility of
XML documents, and it's a bit like semicolons in D in the sense that they
can help ensure that error messages refer to the right thing rather than
something later in the document, so I don't know. I'd also allow all Unicode
characters instead of disallowing a number of them, since it won't really
matter for most documents, and then the parser doesn't need to care about
them when validating.

So, basically, you end up with start tags, end tags, and comments, with
start tags optionally having attributes. backslashes would then be used for
escaping stuff, and you end up with something pretty dead simple.

However, as you're finding out when reading through the XML spec, the folks
who created XML didn't think like that at all, and were clearly coming from
a _very_ different point of view as to what an XML document was for and
should contain. But as you might imagine, given my take on what XML should
have been, finding out in detail what XML actually _is_ was pretty
horrifying.

I started dxml with the intention of fully implementing all aspects of the
spec but ultimately decided that it simply wasn't worth it.

- Jonathan M Davis

The Expressive C++17 Coding Challenge in D

[Seb via Digitalmars-d-announce]

Someone revived the Expressive C++17 Coding Challenge thread 
today and I thought this is an excellent opportunity to revive my 
blog and finally write an article showing why I like D so much:


https://seb.wilzba.ch/b/2018/02/the-expressive-c17-coding-challenge-in-d

It's mostly targeted at beginners as I explain many basic D 
features, but maybe it's helpful for beginners looking into D.

OT: Photo of a single atom by David Nadlinger wins top prize

[Ali Çehreli via Digitalmars-d]

David (aka klickverbot) is a longtime D contributor.


https://www.epsrc.ac.uk/newsevents/news/single-trapped-atom-captures-science-photography-competitions-top-prize/

Ali

Re: Vulkan

[Danni Coy via Digitalmars-d]

On Wed, Feb 14, 2018 at 8:20 AM, Ivan Trombley via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:

> I wanted to do some experimentation with Vulkan using D. None of the
> projects that I found (derelict-vulkan, d-vulkan and erupted) work.
>
> Are there D bindings to Vulkan that actually work?
>

strictly speaking you don't need a binding, you can access C code directly
as long as you write compatible header definitions for the parts of vulkan
you are actually using in your code.

eg
extern(C) int someExternalCLibraryFunction ();

auto a = someExternalCLibraryFunction();

Just make sure that you link to that C Library when you build.

If you do this on an as needed basis It's not too painful.

[Issue 18435] New: Use StatsCollector in shared environment

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

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

  Issue ID: 18435
   Summary: Use StatsCollector in shared environment
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: edi33...@gmail.com

std.experimental.allocator.building_blocks.StatsCollector should be usable in
shared environments.

--

Vulkan

[Ivan Trombley via Digitalmars-d]

I wanted to do some experimentation with Vulkan using D. None of 
the projects that I found (derelict-vulkan, d-vulkan and erupted) 
work.


Are there D bindings to Vulkan that actually work?

Re: dmd-2.078.2 problems with Ubuntu 17.10 32Bit

[Martin Tschierschke via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 21:25:44 UTC, Jordi Sayol wrote:
El 13/02/18 a les 08:03, Martin Tschierschke via 
Digitalmars-d-learn ha escrit:

On Monday, 12 February 2018 at 21:18:01 UTC, Jordi Sayol wrote:
El 12/02/18 a les 21:56, Martin Tschierschke via 
Digitalmars-d-learn ha escrit:
I just started to play around with D again on my notebook at 
home and realized,

that I have a broken installation.
Even the minimal D "hello world" throws an error at 
execution.
Speicherzugriffsfehler (Speicherabzug geschrieben) aka. core 
dump


Compiling with ldc2 still works.
Any hint?





d-apt 


After setting ulimit -c unlimited to get the core dumped, I 
took a look with gdb, to find a hint, now realizing, that it 
is probably the same problem as here: 
https://forum.dlang.org/thread/jjaynewwdsyntyehv...@forum.dlang.org?page=1




A fresh install from d-apt on Ubuntu 16.04 32-bit, and 
everything worked fine.




I tried a lot, there is special bug new on ubuntu 17.10 in
/etc/apt/sources.list.d/d-apt.list

!!! I had to change http://... to https://


Before that I imported the key with
sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 
EBCF975E5BA24D5E


I am not sure if this was necessary, probably not.

Than I was able to call

sudo apt-get update && sudo apt-get -y --allow-unauthenticated 
install --reinstall d-apt-keyring && sudo apt-get update


and install with

sudo apt-get install dmd-compiler dub

But unfortunately still the same core dump.

Is there anyone using Ubuntu 17.10 32 Bit?

I will downgrade to 16.04., the dist-upgrade to 17.10 was a 
mistake, resulting in problems with startx and newer kernels so I 
have to use 4.10.

Re: dxml 0.2.0 released

[Jonathan M Davis via Digitalmars-d-announce]

On Tuesday, February 13, 2018 21:18:12 Patrick Schluter via Digitalmars-d-
announce wrote:
> There's also the issue that entity references open a whole can of
> worms concerning security. It quite possible to have an
> exponential growing entity replacement that can take down any
> parser.

Well, if dxml just passes the entity references along unparsed beyond
validating that the entity reference itself contains valid characters (e.g.
it's not something like &.; or & by itself), then dxml would still not be
replacing the entity references with anything. Any security or performance
problems associated with entity references would be left up to whatever
parser parsed the DTD section and then used dxml to parse the rest of the
XML and replaced the entity references in dxml's parsing results with
whatever they were.

The big problem is how the entity references affect the parsing. If start
tags can be dropped in and affect the parsing (and it's still not clear to
me from the spec whether that's legal - there is a section talking about
being nested properly which might indicate that that's not legal, but it's
not very specific or clear), and if it's legal to do something like use an
entity reference for a tag name - e.g. <>, then that's a serious
problem. And problems like that are the main reason why I completely dropped
any attempt to do anything with the DTD section.

If entity references are only legal in the text between start and end tags
and between the quotes of attribute values, and whatever they're replaced
with cannot actually affect anything else in the XML document (i.e. it can't
just be a start or end tag or anything like that - it has to be fulling
parseable on its own and not affect the parsing of the document itself),
then passing them along should be fine.

Basically, if I can change dxml so that in the places where it currently
allows one of the standard entity references to be, it then also allows
other entity references but passes them along without replacing them instead
of throwing an XMLParsingException, and that works without having documents
be screwed up due to missing start tags or something, then passing them
along should be fine. But if entity references allow arbitrary enough chunks
of XML, that doesn't work. It also doesn't work if entity references are
allowed in places other than the text between start and end tags or within
attribute values. And it's not clear to me at all what is legal in an entity
reference or where exactly they're legal. The spec talks about the grammar
being the grammar _after_ all of the references have been replaced, which
makes the grammar rather untrustworthy, and I find the spec very hard to
understand in general.

Regardless, there's no risk of dxml's parser ever being changed to actually
replace entity references. That doesn't work with returning slices of the
original input, and it really doesn't work with a parser that's just
supposed to take a range of characters and parse it. To fully handle all of
the DTD stuff means actually reading files from disk or from the internet -
which of course is where the security problems come in, but it also means
that you're not just dealing with a parser anymore. In principle, dxml's
parser should be pure (though some implementation make it so that it isn't
right now), whereas an XML parser that fully handles the DTD section could
never be pure.

- Jonathan M Davis

Re: unable to fork: Cannot allocate memory / core.checkedint / gtkd

[Stefan Koch via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 14:10:44 UTC, number wrote:
Ok, thanks for the info. I guess I'll just use printf then for 
larger enums.


To get the same convince you can use.
the enumToString from:

https://forum.dlang.org/post/pnggoabnnkojdonyz...@forum.dlang.org

and writeln the result oft that.
however it'll cause an error if there are two enum memebrs with 
the same value.

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #20 from Jonathan Marler  ---
Confirmed ag0aep6g's example.  Also confirmed the proposed PR treats the
example as an error.

version=A

foo.d(3): Deprecation: module `bar` from file baz.d must be imported with
'import bar;'

version=B

foo.d(8): Deprecation: module `baz` from file bar.d must be imported with
'import baz;'

--

Re: dmd-2.078.2 problems with Ubuntu 17.10 32Bit

[Jordi Sayol via Digitalmars-d-learn]

El 13/02/18 a les 08:03, Martin Tschierschke via Digitalmars-d-learn ha escrit:
> On Monday, 12 February 2018 at 21:18:01 UTC, Jordi Sayol wrote:
>> El 12/02/18 a les 21:56, Martin Tschierschke via Digitalmars-d-learn ha 
>> escrit:
>>> I just started to play around with D again on my notebook at home and 
>>> realized,
>>> that I have a broken installation.
>>> Even the minimal D "hello world" throws an error at execution.
>>> Speicherzugriffsfehler (Speicherabzug geschrieben) aka. core dump
>>>
>>> Compiling with ldc2 still works.
>>> Any hint?
>>>
>>>
>>>
>>
>> d-apt 
> 
> After setting ulimit -c unlimited to get the core dumped, I took a look with 
> gdb,
> to find a hint, now realizing, that it is probably the same problem as here:
> https://forum.dlang.org/thread/jjaynewwdsyntyehv...@forum.dlang.org?page=1
> 

A fresh install from d-apt on Ubuntu 16.04 32-bit, and everything worked fine.

test.d

import std.stdio;

void main()
{
writeln("Hello world!");
}


$ rdmd test.d 
Hello world!

$ dmd -run test.d 
Hello world!

Re: dxml 0.2.0 released

[Patrick Schluter via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 20:10:59 UTC, Jonathan M Davis 
wrote:
On Tuesday, February 13, 2018 15:22:32 Kagamin via 
Digitalmars-d-announce wrote:

On Monday, 12 February 2018 at 16:50:16 UTC, Jonathan M Davis

wrote:
> The core problem is that entity references get replaced with 
> more XML that needs to be parsed. So, they can't simply be 
> passed on for post-processing. As I understand it, they have 
> to be replaced while the parsing is going on. And that means 
> that you can't do something like return slices of the 
> original input that don't bother with the entity references 
> and then have a separate parser take that and process it 
> further to deal with the entity references. The first parser 
> has to deal with them, and that means not returning slices 
> of the original input unless you're dealing purely with 
> strings and are willing to allocate new strings in the cases 
> where the data needs to be mutated because of an entity 
> reference.


Standard entities like  have the same problem, so the 
same solution should work too.


That depends on what exactly an entity reference can contain. 
If it can do something like put a start tag in there, and then 
it has to be terminated by the document putting an end tag in 
there or another entity reference containing an end tag, then 
it can't be handled after the fact like  can be, since 
 is just replaced by text. If an entity reference can't 
contain a start tag without a matching end tag, then sure. But 
I find the XML spec to be surprisingly hard to understand with 
regards to entity references. It's not clear to me where it's 
even legal to put them or not, let alone what you're allowed to 
put in them exactly. And I can't even really trust the XML 
gramamr as long as entity references are involved, because the 
gramamr in the spec is the grammar _after_ entity references 
have all been replaced, which I was quite dismayed to figure 
out.


If it's 100% sure that entity references can be treated as just 
text and that you can't end up with stuff like start tags or 
end tags being inserted and messing with the parsing such that 
they all have to be replaced for the XML to be correctly 
parsed, then I have no problem passing entity references along, 
and a higher level parser could try to do something with them, 
but it's not clear to me at all that an XML document with 
entity references is correct enough to be parsed while not 
replacing the entity references with whatever XML markup they 
contain. I had originally passed them along with the idea that 
a higher level parser could do something with them, but I 
decided that I couldn't do that if you could do something like 
drop a start tag in there and change the meaning of the stuff 
that needs to be parsed that isn't directly in the entity 
reference.




There's also the issue that entity references open a whole can of 
worms concerning security. It quite possible to have an 
exponential growing entity replacement that can take down any 
parser.



 
 "">
 "">
 "">
 "">
 "">
 "">
 "">
 "">
 "">

]>


Hope you have enough memory (this expands to a 3 000 000 000 
LOL's)

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #19 from ag0ae...@gmail.com ---
(In reply to Andrei Alexandrescu from comment #16)
> The example in which the order of imports makes or breaks the build is
> compelling. Even better would be a bug whereby the project builds both ways
> but does different things. That would be the smoking gun.

My take on it:

foo.d:

version (A)
{
static import baz;
static import bar;
}
version (B)
{
static import bar;
static import baz;
}
void main()
{
import std.stdio;
writeln(bar.thing);
writeln(baz.thing);
}


bar.d:

module baz;
enum thing = "this is baz from bar.d";


baz.d:

module bar;
enum thing = "this is bar from baz.d";


`dmd foo.d -version=A && ./foo`:

this is bar from baz.d
this is bar from baz.d


`dmd foo.d -version=B && ./foo`:

this is baz from bar.d
this is baz from bar.d


--

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #18 from Timothee Cour  ---
> Even better would be a bug whereby the project builds both ways but does 
> different things. That would be the smoking gun.

could shorten but this shows it:

./asdf/wrong.d
pragma(msg, __FILE__," ",__MODULE__);

extern(C) int baz(){
  return 42;
}
./main.d
static if(__traits(compiles, {import foo.bar6;})) {
  import foo.bar6;
}

extern(C) int baz();
void main(){
  import std.stdio;
  writeln("baz:", baz);
}
./foo/bar6.d
module foo.bar6;

version(A){
import foo.bar4;
import foo.bar3;
}
else version(B){
import foo.bar3;
import foo.bar4;
}
./foo/bar2.d
module foo.bar2;
pragma(msg, __FILE__," ",__MODULE__);
./foo/bar5.d
module foo.bar5;
pragma(msg, __FILE__," ",__MODULE__);
import asdf.wrong;
./foo/bar4.d
module foo.bar4;
pragma(msg, __FILE__," ",__MODULE__);
import asdf.wrong;
./foo/bar.d
pragma(msg, __FILE__," ",__MODULE__);
./foo/bar3.d
module asdf.wrong;
pragma(msg, __FILE__," ",__MODULE__);

extern(C) int baz(){
  return 41;
}



dmd -i -version=A -run main.d
foo/bar4.d foo.bar4
asdf/wrong.d wrong
baz:42
dmd -i -version=B -run main.d
foo/bar3.d asdf.wrong
foo/bar4.d foo.bar4
baz:41

--

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #17 from Jonathan Marler  ---
I was able to reproduce Timothee's example.  The error only occurs if the
modules are specified in a particular order.

I also tested this using PR
(https://github.com/dlang/dmd/pull/7878#issuecomment-365364824) and confirmed
that it will assert an error in both cases regardless of the order the imports
appear in.

--

Re: opCast cannot implicitly convert a.opCast of type X to Y

[aliak via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 12:12:30 UTC, Nathan S. wrote:

On Monday, 12 February 2018 at 02:05:16 UTC, aliak wrote:

struct B(T) {
T t;
}

struct A(T) {
T t;
auto opCast(U)() {
return B!U(cast(U)t);
}
}

void main() {
auto a = A!int(3);
auto b = cast(float)a; // error
}


Having the result of "cast(float) a" not be a float would be 
evil.


Ya :p dunno what I was thinking.

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #16 from Andrei Alexandrescu  ---
The example in which the order of imports makes or breaks the build is
compelling. Even better would be a bug whereby the project builds both ways but
does different things. That would be the smoking gun.

OK to leave this open. At the minimum we must fix the order dependency and make
the spec clearer. Thanks!

--

Re: Being Positive

[Ola Fosheim Grøstad via Digitalmars-d]

On Tuesday, 13 February 2018 at 18:25:25 UTC, 9il wrote:
Do we follow main initial promise to be better / to replace 
C/C++?


The last one question is the most important. Instead of 
targeting a real market for as, which is C/C++, we are building 
a "trendy" language to compete with Python/Java/Go/Rust. Trends 
are changing but C/C++ market are waiting us!


That is probably true. Also in the convenience department any 
small language will have problems reaching a high valuation...


Rust seems to be able to pick up some of the C market though.

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #15 from Timothee Cour  ---
the example I just posted breaks this spec:

> The order in which ImportDeclarations occur has no significance.

--

Re: Being Positive

[Andrei Alexandrescu via Digitalmars-d]

On 2/12/18 10:46 PM, jmh530 wrote:

On Tuesday, 13 February 2018 at 03:15:44 UTC, bachmeier wrote:


I don't see a negative trend. [snip]


I don't know if there's a negative trend or not, but every 2 or 3 months 
there's inevitably a thread about things D needs to add or improve that 
tends to devolve into complaints about the language.


One thing that has happened visibly starting around December 2017 is 
that most activity has moved onto github. I can barely keep up with the 
action going on in there. This is good on many levels, among which 
obviously there's progress being made. Also, on github it's much easier 
to keep things on track because the implicit goal is to reach a binary 
conclusion pull/not, whereas in idle forum discussion the implicit 
incentive is to keep discussion going. -- Andrei

[Issue 15086] import doesn't verify module declaration

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

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #14 from ag0ae...@gmail.com ---
Reopening. INVALID is not an acceptable resolution for this.

Per the spec, a module must be imported by its module name [1]. And the module
name is set by the module declaration, if there is one [2]. Importing a module
by its file name is not in the spec. Of course, I may be missing how the spec
allows DMD's current behavior. If so, someone please point it out.

If I'm not missing anything in the spec, this issue (like all compiler bugs)
can be resolved by changing the compiler to match the spec, or by changing the
spec to match the compiler. It could also be closed as WONTFIX, I guess. But
that would be disappointing. DMD and the spec should agree on the rules.


[1] https://dlang.org/spec/module.html#import-declaration
[2] https://dlang.org/spec/module.html#module_declaration

--

[Issue 18434] BigInt gcd asserts when one argument is zero.

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

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

Summary|Failing case of BigInt gcd  |BigInt gcd asserts when one
   ||argument is zero.

--

[Issue 18434] Failing case of BigInt gcd

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

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

hst...@quickfur.ath.cx changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from hst...@quickfur.ath.cx ---
https://github.com/dlang/phobos/pull/6170

--

Re: Being Positive

[Wyatt via Digitalmars-d]

On Tuesday, 13 February 2018 at 07:35:19 UTC, Dukc wrote:
On Monday, 12 February 2018 at 23:54:29 UTC, Arun 
Chandrasekaran wrote:
Sorry if I'm hurting someone's sentiment, but is it just me 
who is seeing so much negative trend in the D forum about D 
itself?


Well, programmers are engineers, and engineers tend to focus on 
things that need improvement.


We aren't constantly effusive and positive because we care.  We 
care and we see the cracks in the plaster and know that we, all 
of us, can do better; can BE better.


Often all in different ways that others don't agree with.

And that's fine.

That said, there's a difference between constructive and 
destructive negativity. It pays to recognise the difference and 
not indulge the latter.


-Wyatt

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #13 from Timothee Cour  ---
I don't see what's controversial about the fact that this is broken and breaks
the module system.

Hopefully this other example will convince you, where all I do is change the
order of imports and goes from CT error to compiling.


./main.d
pragma(msg, __FILE__," ",__MODULE__);
import foo.bar;
import foo.bar2;

version(A){
import foo.bar4;
import foo.bar3;
}
else version(B){
import foo.bar3;
import foo.bar4;
}


void main(){}
./foo/bar2.d
module foo.bar2;
pragma(msg, __FILE__," ",__MODULE__);
./foo/bar4.d
module foo.bar4;
pragma(msg, __FILE__," ",__MODULE__);

import asdf.wrong;

./foo/bar.d
pragma(msg, __FILE__," ",__MODULE__);
./foo/bar3.d
module asdf.wrong;
pragma(msg, __FILE__," ",__MODULE__);

./asdf/wrong.d
pragma(msg, __FILE__," ",__MODULE__);

```
dmd -version=A -run main.d
main.d(7): Error: module `asdf.wrong` from file foo/bar3.d conflicts with
another module wrong from file asdf/wrong.d

dmd -version=B -run main.d
main.d main
foo/bar.d bar
foo/bar2.d foo.bar2
foo/bar3.d asdf.wrong
foo/bar4.d foo.bar4
```


This causes many other weirdnesses:
* seperate compilation vs all-at-once compilation is broken
* this makes `./foo/bar.d` and `foo/bar.d` appear as different paths:

```
dmd foo/bar.d -run main.d
main.d(2): Error: module `bar` from file foo/bar.d must be imported with
'import bar;'
dmd ./foo/bar.d -run main.d
main.d(2): Error: module `bar` from file foo/bar.d conflicts with another
module bar from file ./foo/bar.d
```

--

[Issue 18434] New: Failing case of BigInt gcd

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

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

  Issue ID: 18434
   Summary: Failing case of BigInt gcd
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: hst...@quickfur.ath.cx

Code:
--
import std.bigint;
import std.numeric;
void main() {
auto g1 = gcd(0, 1); // OK
auto g2 = gcd(BigInt(0), BigInt(1)); // NG
}
--

Output:
--
core.exception.AssertError@/usr/src/d/phobos/std/numeric.d(2699): Assertion
failure

??:? _d_assertp [0xc9cf7171]
??:? pure nothrow std.bigint.BigInt
std.numeric.gcd!(std.bigint.BigInt).gcd(std.bigint.BigInt, std.bigint.BigInt)
[0xc9cf5770]
??:? _Dmain [0xc9cf5079]
--

The offending line in std.numeric is in the `static if (canUseBinaryGcd)`
block, in the do-loop:

-
assert((a & 1) != 0);
-

--

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #12 from Andrei Alexandrescu  ---
Also enclosing the file name in double quotes might be nice.

--

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #11 from Andrei Alexandrescu  ---
(In reply to Jonathan Marler from comment #10)
> > I think at the least we can do a vastly better job at issuing error 
> > messages.
> 
> I'm limiting focus to this issue alone. Do you have an idea on a way to
> improve the error message for this case?
> 
> CURRENT BEHAVIOR
> 
> dmd -c foo.d bar.d
> Error: module baz from file bar.d must be imported with 'import baz;'
> 
> PROPOSED BEHAVIOR
> 
> dmd -c foo.d bar.d
> Error: module baz from file bar.d must be imported with 'import baz;' or
> must be compiled separately

To make clear what the use case is, I'll paste the files again:

foo.d:

import bar;


bar.d:

module baz; /* not bar */


In this case, attempting to compile them together would be mistaken. I suggest:

Error: file bar.d masquerades as module `baz`, so it must be compiled
separately or imported with `import baz;`

This way we clarify where the discrepancy is and even mildly disapprove of it.
It's also clear that if no mismatch, this problem would disappear.

--

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #10 from Jonathan Marler  ---
> I think at the least we can do a vastly better job at issuing error messages.

I'm limiting focus to this issue alone. Do you have an idea on a way to improve
the error message for this case?

CURRENT BEHAVIOR

dmd -c foo.d bar.d
Error: module baz from file bar.d must be imported with 'import baz;'

PROPOSED BEHAVIOR

dmd -c foo.d bar.d
Error: module baz from file bar.d must be imported with 'import baz;' or must
be compiled separately

--

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #9 from Andrei Alexandrescu  ---
Meant to write:

Per the discussion in https://github.com/dlang/dmd/pull/7778

--

[Issue 15086] import doesn't verify module declaration

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

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

--- Comment #8 from Andrei Alexandrescu  ---
I think at the least we can do a vastly better job at issuing error messages.
Per the discussion in :

===
This error occurs becase the module foo/bar.d is being loaded twice with 2
different names. The first time it is loaded because it is given on the command
line, and since it has no module declaration, the compiler gives it the name
bar. But then the module gets imported with the name foo.bar, however, the
compiler cannot change the name of the module and all existing reference to it
so an error must be asserted. 
[...]
[this bug is allowing] weird abuses which in my opinion have no utility and
only serve to add confusion to the module system.
===

I do agree matters can be confusing especially during project organization and
reorganization. I've done my share of head scratching. I think we'd go a long
way with better error messages (e.g. explaining the matter with two access
paths above), and better online documentation for the module directive.

--

Re: Being Positive

[9il via Digitalmars-d]

On Monday, 12 February 2018 at 23:54:29 UTC, Arun Chandrasekaran 
wrote:
Sorry if I'm hurting someone's sentiment, but is it just me who 
is seeing so much negative trend in the D forum about D itself?


The reason is (as I see it) is very simple. People have/had a lot 
of expectations about the language, its future and 
invest/invested a lot of their time/money to the language. But D 
is a community driven language and sometime we can have question 
like that:


- - - - -
Do we have strong business driven goals? (Go)
Do we have strong theory driven goals? (Rust)
Do we follow main initial promise to be better / to replace C/C++?

The last one question is the most important. Instead of targeting 
a real market for as, which is C/C++, we are building a "trendy" 
language to compete with Python/Java/Go/Rust. Trends are changing 
but C/C++ market are waiting us!

- - - - -

Community is moving. I see it during 8-9 years. The problem is 
direction and speed.


So, if you see next time a negative emotions from someone just 
remember that possibly this person likes the language and wants 
it to be better then it is.


Best,
Ilya

[Issue 15086] import doesn't verify module declaration

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

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

Jonathan Marler  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Jonathan Marler  ---
Andrei and Waltered have rules this as not a bug:

https://github.com/dlang/dmd/pull/7878#issuecomment-365354972
> The case for this PR rests on the notion there should be some invariance of 
> build results with changing build conditions. E.g. "Either both cases should 
> fail or both should pass" (and let me add: "... and create the same binary"). 
> That actually doesn't seem to be a strong argument...

--

Re: D compiler daily downloads at an all-time high

[Dmitry Olshansky via Digitalmars-d-announce]

On Monday, 12 February 2018 at 15:20:29 UTC, Martin Tschierschke 
wrote:

On Monday, 16 November 2015 at 15:20:51 UTC, Andrei

Congratulations to everybody who co

Andrei

Old post but new numbers!

http://erdani.com/d/downloads.daily.png

Would be nice to know what caused the recent spike to >8000?
Are there any other usage stats available? For dlang.org or 
code.dlang.org ?


Regards mt.


When I see spikes like that out of nowhere that it’s usually some 
automation kicking in. Could it be a new CI that we didn’t 
account for yet?


Secretly hope it’s a fresh wave of D users though ;)

Re: Multiple Alis

[Ali Çehreli via Digitalmars-d]

On 02/13/2018 03:05 AM, Andrea Fontana wrote:

> I read this thread just because it was so strange that Ali was calling
> "Multiple Alias This" in this way.

I like it! :) Actually, I tried to make a code joke for this thread with 
"alias this" and discovered a compiler bug:


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

That bug has promptly been fixed by one of the multiple awesome Razvans:

  https://forum.dlang.org/post/nu5rap$m5a$1...@digitalmars.com

Ali

Re: dpq2: spurious error message

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 17:17:41 UTC, Nicholas Wilson 
wrote:
On Tuesday, 13 February 2018 at 17:08:24 UTC, Nicholas Wilson 
wrote:
Is this a problem with the library or me? Can I work around 
it? How?


Thanks
Nic


So digging around in the library code, commenting it out seems 
to work for now as I don't use UUIDs. Error didn't originate 
from my code because it wasn't a template. I'm still surprised 
that it built and then errored in my code.


Ahh it requires vibe.d 0.8.2

Re: Being Positive

[Arun Chandrasekaran via Digitalmars-d]

On Tuesday, 13 February 2018 at 17:03:26 UTC, flamencofantasy 
wrote:

On Tuesday, 13 February 2018 at 02:29:46 UTC, Seb wrote:
On Monday, 12 February 2018 at 23:54:29 UTC, Arun 
Chandrasekaran wrote:

[...]


Yeah, I think it's a different community.
I'm not sure why this is the case, maybe because Rust doesn't 
promise to be a great language and people suffer enough from 
fighting their compiler all day, that they have no energy left 
for trolling?


[...]


Never heard of Steve Klabnik but browsing through his blog I 
came across this;

http://words.steveklabnik.com/the-expressive-c-17-coding-challenge-in-rust
and here is the original C++ challenge;
https://www.fluentcpp.com/2017/10/23/results-expressive-cpp17-coding-challenge/

I wonder what the some code would like like in D.


Previous discussions on this: 
https://forum.dlang.org/post/or0o85$tvc$1...@digitalmars.com

Re: dpq2: spurious error message

[Nicholas Wilson via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 17:08:24 UTC, Nicholas Wilson 
wrote:
Is this a problem with the library or me? Can I work around it? 
How?


Thanks
Nic


So digging around in the library code, commenting it out seems to 
work for now as I don't use UUIDs. Error didn't originate from my 
code because it wasn't a template. I'm still surprised that it 
built and then errored in my code.

dpq2: spurious error message

[Nicholas Wilson via Digitalmars-d-learn]

import vibe.vibe;
import vibe.db.postgresql;

QueryParams p;
p.sqlCommand = "select 
title,url,url_title,messagebody,generationtime from items order 
by generationtime;";

auto _items = conn.execParams(p);

struct Range
{
 immutable Answer a;
  size_t i;
  immutable(Row) front() { return a[i]; }
  @property void popFront() { i++; }
  bool empty() { return i == a.length; }
}
auto items = Range(_items,0);
res.render!("items.dt", items); // usual vibe.d function

//items.dt
- import std.datetime.date;
- import dpq2.conv.time;
- import dpq2.conv.to_d_types;
- foreach(i; items)
item
title= i["title"].as!string
link= i["url"].as!string
description= i["messagebody"].as!string
pubDate= 
DateTimeToRfc822String(i["generationTime"].as!DateTime)


I get the following _two_ lots of the following error (between 
the ):

Compiling Diet HTML template rss.dt...
-
dpq2-1.0.0-alpha.7/dpq2/src/dpq2/conv/to_bson.d(143,23): Error: 
none of the overloads of '__ctor' are callable using argument 
types (UUID), candidates are:
vibe-d-0.7.32/vibe-d/source/vibe/data/bson.d(148,2):
vibe.data.bson.Bson.this(Type type, immutable(ubyte)[] data)
vibe-d-0.7.32/vibe-d/source/vibe/data/bson.d(185,2):
vibe.data.bson.Bson.this(double value)
vibe-d-0.7.32/vibe-d/source/vibe/data/bson.d(187,2):
vibe.data.bson.Bson.this(string value, Type type = 
cast(Type)cast(ubyte)2u)
vibe-d-0.7.32/vibe-d/source/vibe/data/bson.d(194,2):
vibe.data.bson.Bson.this(const(Bson[string]) value)
vibe-d-0.7.32/vibe-d/source/vibe/data/bson.d(196,2):
vibe.data.bson.Bson.this(const(Bson[]) value)
dpq2-1.0.0-alpha.7/dpq2/src/dpq2/conv/to_bson.d(143,23):
... (10 more, -v to show) ...

-
const(ubyte[]) Is not tested in integration tests!
UUID Is not tested in integration tests!
TTimeStamp!false Is not tested in integration tests!
Json Is not tested in integration tests!


Is this a problem with the library or me? Can I work around it? 
How?


Thanks
Nic

Re: rmdirRecurse - on NFS file system

[Seb via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 16:58:09 UTC, Vino wrote:

On Monday, 12 February 2018 at 06:52:25 UTC, Vino wrote:

[...]


Hi All,

Was able to resolve this issue.


That's great!

BTW I think it would be helpful for future reader who find this 
thread to know how you resolved your problem.

Re: Being Positive

[flamencofantasy via Digitalmars-d]

On Tuesday, 13 February 2018 at 02:29:46 UTC, Seb wrote:
On Monday, 12 February 2018 at 23:54:29 UTC, Arun 
Chandrasekaran wrote:

[...]


Yeah, I think it's a different community.
I'm not sure why this is the case, maybe because Rust doesn't 
promise to be a great language and people suffer enough from 
fighting their compiler all day, that they have no energy left 
for trolling?


[...]


Never heard of Steve Klabnik but browsing through his blog I came 
across this;

http://words.steveklabnik.com/the-expressive-c-17-coding-challenge-in-rust
and here is the original C++ challenge;
https://www.fluentcpp.com/2017/10/23/results-expressive-cpp17-coding-challenge/

I wonder what the some code would like like in D.

Re: rmdirRecurse - on NFS file system

[Vino via Digitalmars-d-learn]

On Monday, 12 February 2018 at 06:52:25 UTC, Vino wrote:

Hi All,

   Request your help, the below code works find on normal File 
system, bu if the file system is a NFS file system the below 
code, is not working


if Step = dryrun( Display Only) : Works for both NFS and normal 
file system.
if Step = run (Delete folder) : Does not work on NFS file 
system but works on normal file system.

No error message.

auto coAgedDirClean (string FFs, string Step, int AgeSize) {
auto cAges = AgeSize
auto dFiles = Array!(Tuple!(string, SysTime))(dirEntries(FFs, 
SpanMode.shallow).filter!(a => a.isDir && 
!globMatch(a.baseName, "*DND*") && a.timeCreated < 
cAges).map!(a => tuple(a.name, a.timeCreated)));
if (Step == "run") { dFiles.each!(f => f[0].rmdirRecurse); } 
return dFiles;

}

From,
Vino.B


Hi All,

Was able to resolve this issue.

Re: import strangeness with std.stdio.write

[Seb via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 16:55:10 UTC, ixid wrote:
On Tuesday, 13 February 2018 at 13:52:37 UTC, rikki cattermole 
wrote:

write exists in both, writeln exists only in std.stdio.

Use named imports to pick which write you want.


It does seem a little silly to have a name clash with such a 
commonly used function. Would it not be better to rename 
std.file.write to something like writeFile and deprecate the 
current name?


Yes, I think it would be worthwhile.
Especially that we will allow importing all of Phobos at once in 
2.079:



https://dlang.org/changelog/pending.html#std-experimental-scripting

Re: import strangeness with std.stdio.write

[ixid via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 13:52:37 UTC, rikki cattermole 
wrote:

write exists in both, writeln exists only in std.stdio.

Use named imports to pick which write you want.


It does seem a little silly to have a name clash with such a 
commonly used function. Would it not be better to rename 
std.file.write to something like writeFile and deprecate the 
current name?

Re: flycheck-dmd-dub v0.12 - Emacs on-the-fly syntax checking for D

[Nordlöw via Digitalmars-d-announce]

On Thursday, 8 February 2018 at 17:05:32 UTC, Atila Neves wrote:
This new release fixes bugs and speeds up opening files by 
using `--nodeps --skip-registry=all` if the dependent packages 
have already been downloaded.


Thanks!

[Issue 18433] New: rdmd ignores DFLAGS

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

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

  Issue ID: 18433
   Summary: rdmd ignores DFLAGS
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: tools
  Assignee: nob...@puremagic.com
  Reporter: johnnymar...@gmail.com

rdmd currently ignores DFLAGS.  These flags should be treated like all the
other compiler flags.

--

[Issue 18433] rdmd ignores DFLAGS

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

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

Jonathan Marler  changed:

   What|Removed |Added

   Hardware|x86 |All
 OS|Windows |All

--

Re: inout question

[Steven Schveighoffer via Digitalmars-d-learn]

On 2/12/18 12:33 AM, Norm wrote:

Hi,

I'm new to D so can someone explain to me what is happening here?


void func(const char* s, char** e) {
     import core.stdc.stdlib;
     auto result = strtod(s, e);
}

Error: function core.stdc.stdlib.strtod (scope inout(char)* nptr, scope 
inout(char)** endptr) is not callable using argument types 
(const(char*), char**)


I've found I have to use the following:

void func(inout (char)* s, inout(char)** e)


I thought inout was supposed to take const or non-const variants, so 
expected the original const char* s to work.




A way to think about inout, when you don't understand why you can't call 
it, is to think what inout *should* resolve to, and then see if you can 
assign the existing data to the parameter type.


For example, in this case, you are calling:

strtod(inout(char)* nptr, inout(char)** endptr) with const char *, and 
char **.


Since const char * and char ** vary on mutability, the compiler is going 
to try const in place of inout.


So try it out:

// replace inout with const
const(char)* nptr = s; // ok
const(char)** endptr = e; // Error

I wish the error message was more specific, it would have made things 
obvious. But due to overloading, it's really hard to create errors that 
are good explanations, but not too verbose.


-Steve

Re: Being Positive

[Guillaume Piolat via Digitalmars-d]

On Monday, 12 February 2018 at 23:54:29 UTC, Arun Chandrasekaran 
wrote:
Sorry if I'm hurting someone's sentiment, but is it just me who 
is seeing so much negative trend in the D forum about D itself? 
I don't remember seeing so much negative about Rust on rust 
forum and so on. Do you think it will help in reminding people 
not to post any negative things? It shouldn't become strict 
moderation, but at the same time, I really don't like seeing so 
much negative trend. I would even go to the extent and suggest 
to email Walter/Andrei in person (even if they don't agree) to 
vent your frustration with D, but please don't post it on the 
forum.


Several structural reasons for negativity (I'll be negative 
myself saying all that):


- It's an internet forum - and an addictive one - so each message 
has a bit of social standing at stake. Strong talk is thus 
mechanically encouraged, makes you appear strong and 
knowledgeable, like a big meeting room. It's common for internet 
forums to devolve into negativity.


- Because we don't ban people from the forums, some individuals 
that don't use D and have zero skin in the game come here to 
spread negativity at every occasion.


If you delve into the smaller D communitites they aren't 
especially negative, on the contrary. The forums are not the D 
community at large, it's an addictive subset of it. If the forums 
were _worse_ to use, we wouldn't have this problem.

Re: Being Positive

[Abdulhaq via Digitalmars-d]

On Tuesday, 13 February 2018 at 11:36:35 UTC, psychoticRabbit 
wrote:

On Tuesday, 13 February 2018 at 08:08:28 UTC, bauss wrote:
On Tuesday, 13 February 2018 at 01:32:29 UTC, psychoticRabbit 
wrote:


Personally, I found that youtube video (Life is better with 
Rust's community automation - YouTube) rather disturbing.


Psychotic rabbit disturbed by programming related video. In other 
news

Re: missing HexString documentation

[Steven Schveighoffer via Digitalmars-d]

On 2/11/18 4:48 PM, Walter Bright wrote:
I also notice that hex strings are not simply equivalent to strings 
with \x in them -- the latter is more constrained, as it must be a 
pair of hex digits per \x. hex strings allow spaces between them.


The idea was to be able to cut text from things like hex dumps, 
which include whitespace formatting.


I've never seen a hex dump where the individual nibbles were separated 
by spaces in odd ways.


In other words, what I was saying is that:

"\x12\x34"

could be written as:

x"1 23 4"

which is... odd. What it does is make it so you can't reuse the parsing 
code inside the string escape processor to handle the hex string, 
necessitating an extra 80-line function.



I wouldn't call invoking CTFE "no overhead"


It is no overhead in the generated code.


It's overhead that adds up, memory and time-wise. Really, the memory 
concerns of using CTFE are a bigger problem than the extra tenths of a 
second of compile time.




I tested it out, and generating a hex string of about 600 bytes took 
3x as long as using builtin hex strings.


That's only a potential issue if you've got a very, very large number of 
hex strings. And if you do, those strings can be put in a separate 
module and compiled separately.


Or a very large hex string (very feasible). But very true that there are 
mitigating methods that can be used.


Well, nobody asked :) Besides, it's still not "fixed", as it has the 
same poor performance as the previous version. And the new version has 
broken existing code.


It didn't break code that used x"deadbeef", it broke code that used the 
broken hexString.


In the past, we have not broken code, even when it depends on known 
bugs, if we can help it. But maybe if we can fix the bug I filed above, 
it won't matter.


What the update shows is that you have to jump through incredible 
hoops to get the compiler not to include your compile-time only 
generation code in the resulting binary.


With a language that supports both templates and separate compilation, 
this will always be an issue.


Essentially, you have instantiated the template eagerly, which kind of, 
sort of, defeats the purpose of a template. Though, you still do get the 
benefit of code generation, it's just not an "open-ended" template that 
you can instantiate with any type. Perhaps we should be using this 
pattern all throughout phobos where strings are involved, since there 
are ever only 3 types you instantiate with.



The solution here is not "incredible", it is just not obvious.


The solution isn't incredible, but the fact that this solution is the 
only way to get the CTFE-only code not to creep into your object file is 
a bit dissatisfying. You would think the linker/compiler would not 
inject the unused function into the object file without having to do this.


And nothing has changed here, it's still a library function, as it was 
before.


What's changed is it works now with -betterC, and it doesn't produce 
bloat in the executable.


I think this is due to functions-that-aren't-used being included.

In other words, there was nothing inherent in the old library code that 
created a requirement for druntime to be included.


The bloat is also a deficiency of the compiler, not the code itself.

But if you already have the compiler feature, I don't see why we 
should remove it because a slower library version exists.


It was not an arbitrary and capricious decision, and the rationale 
behind it was presented here multiple times. If you are not convinced, 
that's cool, but the "why" should be pretty clear.


I missed the discussion (there are times where I can't pay attention to 
D for a month or so due to being busy). But in any case, sure I 
understand the "why", but the cost/benefit for me was not high enough, 
and in some aspects, it is all cost, no benefit.


In any case, it isn't a decision that needs to be reversed, as there is 
a workable solution in the library, even if it's sub-optimal. I just 
think it's not as beneficial as has been reported.


-Steve

Re: Being Positive

[John Gabriele via Digitalmars-d]

On Tuesday, 13 February 2018 at 03:40:52 UTC, Jonathan M Davis 
wrote:
{snip} I suspect that part of it is that a lot of folks seem to 
come to D looking for the perfect language after having be 
frustrated by another language like C++, and while D is a lot 
closer to that for many folks than other languages are, it 
still has plenty of flaws, and we want those flaws fixed so 
that it can become the perfect language. Obviously, that's not 
going to happen. No language is perfect, but the vocal portion 
of the D community does have a tendency to want to push for 
everything that's arguably wrong with D to be fixed, and that 
can result in a lot of negativity, but it can also result in 
things getting fixed (though that requires actually doing 
something about it rather than just complaining).


I think what would help here is a D wiki page (maybe 
 could be expanded) that 
lists perceived flaws in the language, together with an 
explanation whether or not it's really considered a flaw, and if 
it is, why it's not being fixed. Those not-being-fixed reasons 
are the real crux of the issue, I think:


  * If the reason is lack of manpower or expertise in the area, 
then complaints about the flaw can be responded with, "see [that 
wiki page], can you pitch in?".


  * If the reason is that by fixing the issue it would cause 
problems {x}, {y}, and {z}, then the person raising the complaint 
learns something about language design.


  * If the reason is the language design team's personal 
preference on the matter, and the tradeoffs are listed, then 
users learn what the tradeoffs are and have to live with it.


  * If the reason for not fixing the issue is hesitation to break 
backward compatibility, then this may be an issue that D 
leadership wants to hear feedback on.


But I think pointing people to that wiki page and laying it out 
like that may diffuse a lot of arguments.

Re: Multiple Alis

[Martin Tschierschke via Digitalmars-d]

On Tuesday, 13 February 2018 at 11:05:03 UTC, Andrea Fontana 
wrote:

On Tuesday, 13 February 2018 at 00:47:42 UTC, Ali Çehreli wrote:
Nothing serious but in case you are confused, there are at 
least three separate and awesome Alis frequenting these 
newsgroups. :)


From: Ali Çehreli
Email: acehr...@yahoo.com
Almost always ends posts simply with "Ali"

From: Ali
Email: fakeem...@example.com
Usually does not use any signature

From: aliak
Email: someth...@something.com
Usually ends with "Cheers", occasionally with an added "- Ali"

Ali
"me"


I read this thread just because it was so strange that Ali was 
calling "Multiple Alias This" in this way.
LOL +1,  + @ Ali Çehreli (trying to use a Gravatar picture would 
be cool, you may use a picture of your wonderful book, if you are 
to shy :-)

Re: dxml 0.2.0 released

[Kagamin via Digitalmars-d-announce]

On Tuesday, 13 February 2018 at 02:53:21 UTC, Nick Sabalausky 
(Abscissa) wrote:

On 02/12/2018 11:15 AM, rikki cattermole wrote:


dxml 7.5k LOC
std.xml 3k LOC

dxml would make the situation a lot worse.


4.5k LOC == "a lot worse"?

Uuuuhhh...WAT?


And it's like 2k LOC of code and 5.5k LOC of tests and docs.

Re: dxml 0.2.0 released

[Kagamin via Digitalmars-d-announce]

On Monday, 12 February 2018 at 16:50:16 UTC, Jonathan M Davis 
wrote:
The core problem is that entity references get replaced with 
more XML that needs to be parsed. So, they can't simply be 
passed on for post-processing. As I understand it, they have to 
be replaced while the parsing is going on. And that means that 
you can't do something like return slices of the original input 
that don't bother with the entity references and then have a 
separate parser take that and process it further to deal with 
the entity references. The first parser has to deal with them, 
and that means not returning slices of the original input 
unless you're dealing purely with strings and are willing to 
allocate new strings in the cases where the data needs to be 
mutated because of an entity reference.


Standard entities like  have the same problem, so the same 
solution should work too.

[Issue 18384] std.net.isemail is slow to import due to regex

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

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

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

https://github.com/dlang/phobos/commit/06e40304b21a29420b40c3f2b8d4edeeaf96aa1f
Fix Issue 18384 - std.net.isemail is slow to import due to regex

Solution is to remove regex from std.net.isemail. May be worth revisiting
if std.regex compile times improve.

https://github.com/dlang/phobos/commit/cbd6cf154c13bb54000ab685be85176122d5dc43
Merge pull request #6129 from n8sh/isemail-noregex

Fix Issue 18384 - std.net.isemail is slow to import due to regex
merged-on-behalf-of: Steven Schveighoffer 

--

[Issue 18384] std.net.isemail is slow to import due to regex

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

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

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

   What|Removed |Added

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

--

Re: GSOC 2018 - no slots for D

[Craig Dillabaugh via Digitalmars-d]

On Tuesday, 13 February 2018 at 13:33:00 UTC, Andrei Alexandrescu 
wrote:

On 02/12/2018 08:20 PM, Jakub Łabaj wrote:

https://summerofcode.withgoogle.com/organizations/
Seems like we didn't make it this year :(

Is there any feedback from Google when they don't accept an 
organisation? Do you think that maybe they don't perceive D as 
a viable option or just the projects could have been defined 
better?


Google does not provide feedback to rejected organizations. Far 
as I can imagine approval depends on a number of imponderables 
such as the person who does the review etc.


GSoC 2018 was not a considerable part of our plans so we are 
not affected negatively.


I'd like to take this opportunity to thank Seb who worked on 
the application. It was stronger than in past years (including 
those when we've been accepted).



Andrei


I also want to thank Seb for the excellent work he did on this 
year's application. It looked really solid, so I am a bit 
disappointed it didn't get accepted, but I am sure D will carry 
on without Google's money just fine.  Being a big fan of 
conspiracy theories I personally think it was blocked by the Go 
folks :o)

Re: import strangeness with std.stdio.write

[psychoticRabbit via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 14:21:31 UTC, bauss wrote:


What you can do is use aliases to use both functions.

import io = std.stdio;

void main()
{
import file = std.file;

file.write("hello");
io.writeln("hello again");
}


that's a nice simple solution.

thanks.

Re: Being Positive

[Mike Franklin via Digitalmars-d]

On Tuesday, 13 February 2018 at 14:17:00 UTC, Steven 
Schveighoffer wrote:

On 2/12/18 11:29 PM, Nick Sabalausky (Abscissa) wrote:

A bunch of stuff I 100% agree with.


Me too.  So refreshing to read.

Mike

Re: import strangeness with std.stdio.write

[bauss via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 13:56:17 UTC, psychoticRabbit 
wrote:
On Tuesday, 13 February 2018 at 13:52:37 UTC, rikki cattermole 
wrote:

On 13/02/2018 1:46 PM, psychoticRabbit wrote:

So, strange problem below.

The commented-out line will not compile (if I un-comment it), 
unless I either move std.stdio into main, or, move std.file 
out of main.


Whereas writeln works just fine as is.

-
module test;

import std.stdio;

void main()
{
     import std.file;

     //write("hello");
     writeln("hello again");
}
---


write exists in both, writeln exists only in std.stdio.

Use named imports to pick which write you want.


oh..you must have posted as I why posting ;-)

That makes sense then. Thanks for clearing that up.

And I should have read the compiler message more clearly..cause 
the answer was in that error message (more or less)


What you can do is use aliases to use both functions.

import io = std.stdio;

void main()
{
import file = std.file;

file.write("hello");
io.writeln("hello again");
}

Re: import strangeness with std.stdio.write

[psychoticRabbit via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 14:18:05 UTC, ketmar wrote:

psychoticRabbit wrote:

Also, if I do this below, how does the compiler choose the 
correct write function?


import std.stdio;
import std.file;

void main()
{
 write("hello");
 writeln("hello again");
}


it's easy: just take a look at `std.file.write()`. first, it 
require two arguments. this is enough to rule 
`stf.file.write()` out in your case.


oh..function overloading..makes sense.

thanks again.

Re: import strangeness with std.stdio.write

[ketmar via Digitalmars-d-learn]

psychoticRabbit wrote:

Also, if I do this below, how does the compiler choose the correct write 
function?


import std.stdio;
import std.file;

void main()
{
 write("hello");
 writeln("hello again");
}


it's easy: just take a look at `std.file.write()`. first, it require two 
arguments. this is enough to rule `stf.file.write()` out in your case.

Re: Being Positive

[Steven Schveighoffer via Digitalmars-d]

On 2/12/18 11:29 PM, Nick Sabalausky (Abscissa) wrote:

A bunch of stuff I 100% agree with.

Thanks. Let's keep the negativity coming, and we'll all be better for it 
;) Problems don't get fixed if you ignore them or pretend they don't 
exist. It's part of a healthy debate. If you don't like the negativity, 
or you feel it's just trolling, ignore it.


-Steve

Re: import strangeness with std.stdio.write

[psychoticRabbit via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 13:57:38 UTC, ketmar wrote:
`std.file` has function named `write()` too. and local import 
completely shadows global imports (i.e. it removes global 
imports from overload set for the given scope), hence 
`std.stdio.write()` is not available there.


"..local import completely shadows global imports"

oh... I didn't realised imports are subject to scope rules in 
that way.


This new knowledge will certainly prevent some ongoing confusion 
;-)


thanks.

Also, if I do this below, how does the compiler choose the 
correct write function?


import std.stdio;
import std.file;

void main()
{
write("hello");
writeln("hello again");
}

Re: unable to fork: Cannot allocate memory / core.checkedint / gtkd

[number via Digitalmars-d-learn]

On Tuesday, 13 February 2018 at 12:32:58 UTC, Stefan Koch wrote:

On Tuesday, 13 February 2018 at 12:17:31 UTC, number wrote:



I just tried again.
compiling the following code eats up my 4GB of RAM and fails. 
Please copy the enumeration
from: 
https://github.com/gtkd-developers/GtkD/blob/master/generated/gtkd/gdk/Keysyms.d

into the code.


import std.stdio;

void main()
{
writeln(GdkKeysyms.GDK_Escape);
}

public enum GdkKeysyms
{
...
}


Reducing the number of enum entries step by step finally will 
make the compilation succeed. Is it normal that it needs so 
much memory?


Yes unfortunately std.conv approaches the problem of printing 
enums with recursive templates  , which eat a ton of memory.


Ok, thanks for the info. I guess I'll just use printf then for 
larger enums.

[Issue 18429] alias this enum causes segmentation fault

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

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

RazvanN  changed:

   What|Removed |Added

 CC||razvan.nitu1...@gmail.com

--- Comment #1 from RazvanN  ---
(In reply to Ali Cehreli from comment #0)
> struct S {
> alias a this;
> enum a = 1;
> }
> 
> $ dmd deneme.d -c
> Segmentation fault
> 
> Interestingly, when the lines inside struct S are swapped then it compiles
> fine.
> 
> Ali

This happens with declarations for which the type must be deduced. Note that
replacing enum with auto results in segmentation fault (or assert error on my
machine - you probably do not have the latest version of dmd). That is due to
the fact that when semantic is performed an the alias this AST node, the type
of the enum variable is not known. Calling semantic on the symbol fixes the
issue.

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

--

[Issue 18430] isSame is wrong for non global lambdas

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

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

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

   What|Removed |Added

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

--

[Issue 18430] isSame is wrong for non global lambdas

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

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

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

https://github.com/dlang/dmd/commit/1701bf9f7ff68538ca4ae279078233e74bc3b617
Fix Issue 18430 - isSame is wrong for non global lambdas

https://github.com/dlang/dmd/commit/01fb3ca67d15571a374c2efb821f82c0d9d39c9f
Merge pull request #7885 from RazvanN7/Issue_18430

Fix Issue 18430 - isSame is wrong for non global lambdas

--