date:20160729

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

  Issue ID: 16337
   Summary: Posix get empty environment value returns null
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: pull
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

If one saves an environment variable that is a blank string, and then retrieves
that value, the returned value is the null string.

While this normally would be fine (null is a valid blank string), the get
function uses null as a sentinel to signify that the environment variable isn't
present. This means one cannot distinguish between getting an environment
variable that is blank, and one that is missing.

PR: https://github.com/dlang/phobos/pull/4627

--

[Issue 15906] [REG2.068.1] GIT HEAD undefined references

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||bugzi...@digitalmars.com
 Resolution|--- |WORKSFORME

--- Comment #3 from Walter Bright  ---
With HEAD,

The test case in the first comment compiles, links and runs successfully. The
second test case compiles and links, and asserts when fails.

Since the report is a link failure, marking this as working.

--

Re: C's void func() vs. void func(void).

2016-07-29 Thread Mike Parker via Digitalmars-d-learn


On Friday, 29 July 2016 at 18:24:52 UTC, ag0aep6g wrote:

On 07/29/2016 02:15 PM, Mike Parker wrote:
And if it is a cross-platform library that is stdcall on 
Windows and

cdecl elsewhere:

extern(C) void fun();


extern(System), no?


Yeah, that's what I had intended.

Re: Why D isn't the next "big thing" already

2016-07-29 Thread Karabuta via Digitalmars-d-learn


On Tuesday, 26 July 2016 at 15:11:00 UTC, llaine wrote:

Hi guys,

I'm using D since a few month now and I was wondering why 
people don't jump onto it that much and why it isn't the "big 
thing" already.


Everybody is into javascript nowadays, but IMO even for doing 
web I found Vibe.d more interesting and efficient than node.js 
for example.


I agree that you have to be pragmatic and choose the right 
tools for the right jobs but I would be interested to have 
other opinion on thoses questions.


I think we need more frameworks like vibe.d to build things with 
them. Currently there is not much so only a class of programmers 
will find the language useful.


Another thing is that the language is not marketed well enough. 
Someone need to handle marketing of the language, like real 
marketing. Most people are still unaware of D.

[Issue 16316] [REG 2.071] (Import deprecation) fully qualified name of imports in mixin template not accessible

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

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

   What|Removed |Added

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

--

[Issue 16316] [REG 2.071] (Import deprecation) fully qualified name of imports in mixin template not accessible

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

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

https://github.com/dlang/dmd/commit/b517d86ed55cccb7b33608ec3e22f0036462f445
fix Issue 16316 - FQN of imports in mixin template not accessible

- this is also fixed by searching the importedScopes for accessible packages

--

[Issue 15900] [REG 2.071] (Import deprecation) Public import ignored when using fully qualified name

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

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

   What|Removed |Added

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

--

[Issue 15900] [REG 2.071] (Import deprecation) Public import ignored when using fully qualified name

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

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

https://github.com/dlang/dmd/commit/0a20f1d407281f61da5b6386fdbe762bab410200
fix Issue 15900 - public imports not accessible using FQN

- public imports in imported modules were not accessbile using their
  FQN, this was an oversight when adding the package tree masking to fix
  Bugzilla 313 (see #5426)
- fixed by recursively checking imported scopes for accessible packages
- reuse Module.insearch to not follow import cycles
- Uses the same reduced visibility distinction (only private vs. rest) as the
  unqualified symbol search, b/c extending importedScopes to track rich
  visibility (e.g. package(a.b)) was out of scope for a regression fix.
  This should be implemented when combining the search/import w/
  the symbol visibility mechanism.

https://github.com/dlang/dmd/commit/4caed5518c492341a23f1da890c2931e73e0296a
Merge pull request #5967 from MartinNowak/fix15900

fix Issue 15900 - public imports not accessible using FQN

--

Re: Overflows in Phobos

2016-07-29 Thread Charles Hixson via Digitalmars-d


On 07/26/2016 07:36 AM, ketmar via Digitalmars-d wrote:

On Tuesday, 26 July 2016 at 14:28:48 UTC, Timon Gehr wrote:
"The expression assert(0) is a special case; it signifies that it is 
unreachable code. [...] The optimization and code generation phases 
of compilation may assume that it is unreachable code."


so specs should be fixed. i bet everyone is using `assert(0);` to mark 
some "immediate error exit" cases.



FWIW, in that case I always use
assert (false, "...");
I try to never use integers for booleans.  But this may well be a common 
usage.

Re: D for competitive programming

2016-07-29 Thread sarn via Digitalmars-d

To add to the list, here are a couple of other online judges that 
explicitly support D:


http://www.spoj.com/
http://judge.u-aizu.ac.jp/onlinejudge/

Of course, if you use a language-agnostic platform like Code Jam, 
you can do what you like.  Project Euler (maths-oriented) and the 
Matasano Challenges (crypto-oriented) are two of my favourite 
problem sets.

Re: [OT] Music to Program Compilers To


On 7/29/2016 3:45 PM, Cauterite wrote:

On Friday, 29 July 2016 at 22:44:04 UTC, Walter Bright wrote:

http://70sdisconights.com/

Yes, I listen to it while I work.


that webpage design though >_<


I'm spared that because I listen via a Grace Digital tuner, recently bought to 
replace the ancient but much loved Turtlebeach Audiotron.


I do wish for a return of Jeff Gilbert's "Brain Pain" on KCMU which aired in the 
late 80's. He's the only DJ I could ever stand to listen to. His banter was as 
entertaining as his selections. Gilbert would sometimes appear as a guest star 
on "Almost Live". I'm surprised he wasn't more successful in showbiz.

Re: [OT] Music to Program Compilers To

2016-07-29 Thread Cauterite via Digitalmars-d


On Friday, 29 July 2016 at 22:44:04 UTC, Walter Bright wrote:

http://70sdisconights.com/

Yes, I listen to it while I work.


that webpage design though >_<

[OT] Music to Program Compilers To

2016-07-29 Thread Stefan Koch via Digitalmars-d-announce


http://70sdisconights.com/

Yes, I listen to it while I work.

Re: Battle-plan for CTFE


On Friday, 29 July 2016 at 14:28:03 UTC, Stefan Koch wrote:


if ((a && b) || (a && c)) {//bla}


This is now solved although quite naively at the cost of 
inserting twice the number of instructions for thoose cases.

Then agian we are still much faster then the old interpreter.
And I can still optimize this if it should turn out to be a 
bottleneck.


Tomorrow I will fix the regressed string handling.

Re: Does D have object wrappers for primitives?

2016-07-29 Thread Ali Çehreli via Digitalmars-d-learn

On 07/29/2016 01:40 PM, Cauterite wrote:
> On Friday, 29 July 2016 at 20:26:47 UTC, Ali Çehreli wrote:
>>
>> I was going to suggest Algebraic because it allows arrays of mixed
>> primitive types (wrapped in Algebraic):
>>
>>   https://dlang.org/phobos/std_variant.html#.Algebraic
>>
>> Ali
>
> It could work, but keep in mind Algebraic is a structure, not an object.

Also, I've later noticed that your Box was a class, so it would allow 
"arrays of mixed primitive types" as well.

Yes, Algebraic is not a struct but Java not having structs doesn't mean 
that the original code really needed classes either. :)

Ali

Re: Does D have object wrappers for primitives?

2016-07-29 Thread Cauterite via Digitalmars-d-learn


On Friday, 29 July 2016 at 20:26:47 UTC, Ali Çehreli wrote:


I was going to suggest Algebraic because it allows arrays of 
mixed primitive types (wrapped in Algebraic):


  https://dlang.org/phobos/std_variant.html#.Algebraic

Ali


It could work, but keep in mind Algebraic is a structure, not an 
object.

Re: D for competitive programming

2016-07-29 Thread urxvt1 via Digitalmars-d

On Thursday, 28 July 2016 at 22:07:44 UTC, Seb wrote:

On Thursday, 28 July 2016 at 21:20:29 UTC, urxvt1 wrote:

I wanted to try topcoder problems (never used this site before)
and I found out that it doesn't support dlang.
They only have c++, java, c#, vb.net, python languages.
It would be great to see D on this list.
I found this thread
https://apps.topcoder.com/forums/?module=Thread=703674 and it seems that it's not that easy to add new langauge and they are not very interested.
And I think that one of the keys to make D more popular and
attract more people
to try it would be to promote D as a language for learning
algorithms and competitive programming. This niche is mostly
occupied by c++ and java.
I think that D might be a very good candidate to push these
languages in CP.

I've also checked google code jam statistics and unfortunately
D isn't very popular here compared to say golang or scala.

https://www.go-hero.net/jam/16/languages
https://www.go-hero.net/jam/15/languages
https://www.go-hero.net/jam/14/languages
https://www.go-hero.net/jam/13/languages

For what it's worth - HackerRank (a similar platform) supports
D (2.071.1!). Sometimes writing the customer support &
complaining about outdated versions does help :)

https://www.hackerrank.com/environment

I'm using open.kattis.com but unfortunately they don't have D
support. They have
Go and haskell though. Yeah, maybe it's a good idea to write but
D isn't popular and tech news sites are writing about rust, go or
scala, so I doubt they are gonna add D. On the other hand they
have prolog which isn't very popular either.

Re: Does D have object wrappers for primitives?

2016-07-29 Thread Ali Çehreli via Digitalmars-d-learn


On 07/29/2016 01:25 PM, Cauterite wrote:

On Friday, 29 July 2016 at 20:13:34 UTC, stunaep wrote:

I have some java code I need to convert and at one point it uses an
Object[] array to store various ints, longs, and strings. Java has
built in Integer and Long classes that wrap the primitives in an
object and strings are already objects.


No, but with a template you could easily make your own:

class Boxed(T) {
T _v;
alias _v this;
this(in T v) immutable {_v = v;};
};

auto i = new Boxed!int(6);


I was going to suggest Algebraic because it allows arrays of mixed 
primitive types (wrapped in Algebraic):


  https://dlang.org/phobos/std_variant.html#.Algebraic

Ali

Re: Does D have object wrappers for primitives?

2016-07-29 Thread Cauterite via Digitalmars-d-learn


On Friday, 29 July 2016 at 20:13:34 UTC, stunaep wrote:
I have some java code I need to convert and at one point it 
uses an Object[] array to store various ints, longs, and 
strings. Java has built in Integer and Long classes that wrap 
the primitives in an object and strings are already objects.


No, but with a template you could easily make your own:

class Boxed(T) {
T _v;
alias _v this;
this(in T v) immutable {_v = v;};
};

auto i = new Boxed!int(6);

Does D have object wrappers for primitives?

2016-07-29 Thread stunaep via Digitalmars-d-learn

I have some java code I need to convert and at one point it uses 
an Object[] array to store various ints, longs, and strings. Java 
has built in Integer and Long classes that wrap the primitives in 
an object and strings are already objects.

Re: string mixin and alias

2016-07-29 Thread Andre via Digitalmars-d-learn


On Friday, 29 July 2016 at 18:39:23 UTC, Jesse Phillips wrote:

On Friday, 29 July 2016 at 18:34:56 UTC, Jesse Phillips wrote:
Here the generateCode() is mixed in to the context of foo(), 
which is fine if your code is performing actions but is no 
good if you're creating declarations that you want to use in 
the context of main().


Here is a fully functioning example:

---
string generateCode(string s){return s;}

void main()
{
int a, b;
enum s = "a = 2 + 3; b = 4 + a;";
foo!(s)(a, b);
assert(a == 5);
assert(b == 9);
}

void foo(alias s)(ref int a, ref int b) {
mixin(generateCode(s));
}
---


Thanks for all the answers.

Kind regards
Andre

Re: Use dup on Containers with const Elements

2016-07-29 Thread Steven Schveighoffer via Digitalmars-d-learn


On 7/29/16 3:00 PM, Q. Schroll wrote:

Cases to consider: Arrays and AAs with const(T) Elements, where T is a
value or a reference type respectively.


[snip]

Questions:
(1) Why do I have to specify the type here? Why does inference fail?
(2) Why not just S[S]?
The copy of a const S is a S so why is the copy of a (const S, const
S)-pair not just (S, S)?



array.dup has the meaning to copy the original but make the elements 
mutable. At least, that's what it was when it was handled by the 
compiler/runtime.


So the reason for 1 is that you can't convert const(C) to just C without 
a cast, so you must specify the type.


I'm not certain about AA, as I don't remember how dup was defined on them.

-Steve

Re: New Diet template engine almost complete, ready for comments

2016-07-29 Thread Sönke Ludwig via Digitalmars-d-announce


Am 29.07.2016 um 13:28 schrieb Chris:

Talking about diets, will reShop[1] be available for Android an iOS too?
You could extend it by adding "health tips" (add fruit & veg
automatically), a calorie counter (for single items and the whole list) ;)

http://rejectedsoftware.com/products/reshop


Yeah, diet/health tips are always a hot topic, I think we even talked 
about something like that at some point ;)


Porting it to those platforms was the initial idea. But since both BB10 
and WP are more or less dead now, the main feature of providing full 
cross-platform synchronization of the lists became a moot point (there 
are plenty of solutions for Android/iOS already). And then it also 
really was just a little test project anyway.

Use dup on Containers with const Elements

2016-07-29 Thread Q. Schroll via Digitalmars-d-learn

Cases to consider: Arrays and AAs with const(T) Elements, where T 
is a value or a reference type respectively.


class C { }
struct S { }

const(S)[]  varr;
const(C)[]  carr;
const(S)[S] vaav;
const(C)[S] caav;
const(S)[C] vaac;
const(C)[C] caac;

pragma(msg, typeof(varr.dup));
pragma(msg, typeof(carr.dup!(const C))); // (1)
pragma(msg, typeof(vaav.dup));
pragma(msg, typeof(caav.dup));
pragma(msg, typeof(vaac.dup));
pragma(msg, typeof(caac.dup));

yields

S[] // ok
const(C)[]  // ok
const(S)[S] // (2)
const(C)[S] // ok
const(S)[C] // ok
const(C)[C] // ok

Questions:
(1) Why do I have to specify the type here? Why does inference 
fail?

(2) Why not just S[S]?
The copy of a const S is a S so why is the copy of a (const S, 
const S)-pair not just (S, S)?

[Issue 13983] RefCounted needs to be pure, @safe, nothrow

2016-07-29 Thread Jesse Phillips via Digitalmars-d-learn

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #5 from Steven Schveighoffer  ---
FYI: https://github.com/dlang/phobos/pull/4692

--

Re: string mixin and alias


On Friday, 29 July 2016 at 18:34:56 UTC, Jesse Phillips wrote:
Here the generateCode() is mixed in to the context of foo(), 
which is fine if your code is performing actions but is no good 
if you're creating declarations that you want to use in the 
context of main().


Here is a fully functioning example:

---
string generateCode(string s){return s;}

void main()
{
int a, b;
enum s = "a = 2 + 3; b = 4 + a;";
foo!(s)(a, b);
assert(a == 5);
assert(b == 9);
}

void foo(alias s)(ref int a, ref int b) {
mixin(generateCode(s));
}
---

Re: Old COM with D Slides/Presentation?

2016-07-29 Thread ZombineDev via Digitalmars-d


On Friday, 29 July 2016 at 17:57:04 UTC, Adam D. Ruppe wrote:

On Friday, 29 July 2016 at 17:53:35 UTC, ZombineDev wrote:

Is this what you are looking for:
http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf

?


that link isn't working for me but i think this is the same 
content


http://www.slideserve.com/geneva/modern-com-programming-in-d


That's strange... it works for me. The slideshare link should be 
more stable though.

Re: string mixin and alias

2016-07-29 Thread Jesse Phillips via Digitalmars-d-learn

D won't let you hide the mixin, the keyword is there specifically 
to indicate code is being injected in that location.


This isn't what you are looking for, but you can do something 
like this:


-
string generateCode(string s){return "";}

void main()
{
enum s = "a = 2 + 3; b = 4 + a;";
foo!(s);
}

void foo(alias s)() {
mixin(generateCode(s));
}
-

Here the generateCode() is mixed in to the context of foo(), 
which is fine if your code is performing actions but is no good 
if you're creating declarations that you want to use in the 
context of main().

Re: Old COM with D Slides/Presentation?

2016-07-29 Thread ZombineDev via Digitalmars-d


On Friday, 29 July 2016 at 18:26:18 UTC, Nick Sabalausky wrote:

On 07/29/2016 01:53 PM, ZombineDev wrote:


Is this what you are looking for:
http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf

?


Ah, yes, that's it, thanks.


Glad I could help :)

Re: Old COM with D Slides/Presentation?

2016-07-29 Thread Nick Sabalausky via Digitalmars-d


On 07/29/2016 01:53 PM, ZombineDev wrote:


Is this what you are looking for:
http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf

?


Ah, yes, that's it, thanks.

Re: C's void func() vs. void func(void).

2016-07-29 Thread ag0aep6g via Digitalmars-d-learn


On 07/29/2016 02:15 PM, Mike Parker wrote:

And if it is a cross-platform library that is stdcall on Windows and
cdecl elsewhere:

extern(C) void fun();


extern(System), no?

Re: Old COM with D Slides/Presentation?

2016-07-29 Thread Adam D. Ruppe via Digitalmars-d


On Friday, 29 July 2016 at 17:53:35 UTC, ZombineDev wrote:

Is this what you are looking for:
http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf

?


that link isn't working for me but i think this is the same 
content


http://www.slideserve.com/geneva/modern-com-programming-in-d

Re: Old COM with D Slides/Presentation?

2016-07-29 Thread ZombineDev via Digitalmars-d


On Friday, 29 July 2016 at 17:45:58 UTC, Nick Sabalausky wrote:
A few years ago there was a presentation, or maybe only slides 
were posted (I don't recall), that demonstrated D putting C++ 
and even C# to absolute shame for interfacing with COM using 
some closed in-house D library.


I'm trying to search for the slides or any links or anything 
relating to that but can't quite find it. Anyone have anything 
offhand?


Is this what you are looking for:
http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf

?

Old COM with D Slides/Presentation?

2016-07-29 Thread Nick Sabalausky via Digitalmars-d

A few years ago there was a presentation, or maybe only slides were 
posted (I don't recall), that demonstrated D putting C++ and even C# to 
absolute shame for interfacing with COM using some closed in-house D 
library.


I'm trying to search for the slides or any links or anything relating to 
that but can't quite find it. Anyone have anything offhand?

Re: D-Man culture

2016-07-29 Thread David Nadlinger via Digitalmars-d-announce


On Thursday, 28 July 2016 at 16:10:58 UTC, Seb wrote:
we could generate revenue with the (real) D-Man? I
don't know, if it existed independently of DLang, or if it's 
in some way related to DLang. In the latter case we might use 
it to make some money for the D Foundation.


@Chris you should get in touch with the nice guys from 
Sociomantic (e.g.
Dylan Cromwell (https://github.com/dylan-cromwell-sociomantic) 
and Leandro Lucarella 
(https://github.com/leandro-lucarella-sociomantic)). They are 
working on helping the D Foundation to setup a D Store with 
swag ;-)


Will they sell D-shirts as well (couldn't resist the pun!).

Re: Terminix Stable 1.2.0 Released


On Saturday, 23 July 2016 at 14:24:08 UTC, Matthias Klumpp wrote:
4) Resolving weird LDC bugs like this one: 
https://github.com/ldc-developers/ldc/issues/1618 - might 
actually be an LLVM issue, but I don't know enough to pin down 
the issue.


Turns out that this is not actually a LDC/LLVM bug, but an 
artefact of Ubuntu 16.10 patching GCC to generate 
position-independent executables by default.


Is DMD also affected by this? Does anybody know how other 
languages are dealing with the change?


 — David

[Issue 16336] New: Inconsistent flag handling of std.format.FormatSpec

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

  Issue ID: 16336
   Summary: Inconsistent flag handling of std.format.FormatSpec
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: minor
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: r.97...@gmail.com

import std.format;

struct FormatSpecPrinter
{
void toString(scope void delegate(const(char)[]) sink, FormatSpec!char fmt)
{
sink.formattedWrite("%s", fmt);
}
}

void main()
{
import std.stdio;
"%(%(%s%)%)".writefln(FormatSpecPrinter()); // just fine.
"%-(%-(%s%)%)".writefln(FormatSpecPrinter()); // dash is nicely handled.
"%+(%(%s%)%)".writefln(FormatSpecPrinter()); // OK: plus flag for outer
%(..%).
"%(%+(%s%)%)".writefln(FormatSpecPrinter()); // inner plus flag crashes:
first "%)" matches "%(" and the second "%)" left orphan.
}


Like in the example in the wiki article, I'd like to use '+' flag for another
meaning, in a nested way.
https://wiki.dlang.org/Defining_custom_print_format_specifiers

So, I'd like '+' flags to be allowed both for outermost and nested '('
specifier.
However, current implementation considers only "%-(" when looking for the
matching "%)" of outer "%(".
https://github.com/dlang/phobos/blob/f75eeb596d44544e98a23ee1fd0b60f9ae8b0956/std/format.d#L918

--

Re: simple sax-style xml parser

2016-07-29 Thread ketmar via Digitalmars-d-announce


On Friday, 29 July 2016 at 14:47:08 UTC, Chris wrote:
Thanks. I might actually use it. I need an XML parser and wrote 
a very basic and incomplete one for my needs.


great. don't forget to get lastest versions from that links. and 
feel free to report any bugs here, i'll try to fix them asap. ;-)

Re: simple sax-style xml parser

2016-07-29 Thread Stefan Koch via Digitalmars-d-announce


On Wednesday, 20 July 2016 at 01:49:37 UTC, ketmar wrote:
i wrote a simple sax-style xml parser[1][2] for my own needs, 
and decided to share it. it has two interfaces: `xmparse()` 
function which simply calls callbacks without any validation or 
encoding conversion, and `SaxyEx` class, which does some 
validation, converts content to utf-8 (from anything 
std.encoding supports), and calls callbacks when the given path 
is triggered.


it can parse any `char` input range, or std.stdio.File. parsing 
files is probably slightly faster than parsing ranges.


internally it is extensively reusing memory buffers it 
allocated, so it should not create a big pressure on GC.


you are expected to copy any data you need in callbacks (not 
just slice, but .dup!).


so far i'm using it to parse fb2 files, and it parsing 8.5 
megabyte utf-8 file (and creating internal reader structures, 
including splitting text to words and some other housekeeping) 
in one second on my i3 (with dmd -O, even without -inline and 
-release).


it is not really documented, but i think it is "intuitive". 
there are also some comments in source code; please, read 
those! ;-)


p.s. it decodes standard xml entities (

Re: Battle-plan for CTFE

On Friday, 29 July 2016 at 12:47:55 UTC, Robert burner Schadek 
wrote:

On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote:

please share your thoughts.


When is this moving into dmd master?


As soon as it passes the test-suite.
And can execute diet-ng on the fast-path.

Currently I have issues with chained binary expressions.
such as

if ((a && b) || (a && c)) {//bla}

Re: Battle-plan for CTFE

2016-07-29 Thread Stefan Koch via Digitalmars-d-announce


On Friday, 29 July 2016 at 13:07:12 UTC, Edwin van Leeuwen wrote:

On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote:

I have fresh performance statistics:


Is there any improvement in memory usage?


Yes!
There memory usage is the same as run-time execution.
plus about 16k for the interpreter state.

[Issue 15306] Delegates with shared context can have unshared aliasing

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

Sobirari Muhomori  changed:

   What|Removed |Added

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

--

[Issue 16335] Thread constructor accepts a delegate with nonshared context

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

Sobirari Muhomori  changed:

   What|Removed |Added

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

--

Re: New __FILE_DIR__ trait?

2016-07-29 Thread Jonathan Marler via Digitalmars-d

On Thursday, 28 July 2016 at 17:21:52 UTC, Sebastien Alaiwan 
wrote:
On Thursday, 28 July 2016 at 06:21:06 UTC, Jonathan Marler 
wrote:

auto __DIR__(string fileFullPath = __FILE_FULL_PATH__) pure
{
return fileFullPath.dirName;
}


Doesn't work, I don't think you can wrap such things ( __FILE__ 
and such ):


import std.stdio;

int main()
{
  printNormal();
  printWrapped();
  return 0;
}

void printNormal(int line = __LINE__)
{
  writefln("%s", line);
}

void printWrapped(int line = __MY_LINE__)
{
  writefln("%s", line);
}

// wrapped version
int __MY_LINE__(int line = __LINE__)
{
  return line;
}

$ rdmd demo.d
5
15  (should be 6!)

Thus, the suggested implementation of __DIR__ would behave very 
differently from a builtin one. I'm not saying we need a 
builtin one, however, it might not be a good idea to name it 
this way.


Huh, interesting case, didn't think of that one.

[Issue 16335] New: Thread constructor accepts a delegate with nonshared context

2016-07-29 Thread Jonathan M Davis via Digitalmars-d-learn

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

  Issue ID: 16335
   Summary: Thread constructor accepts a delegate with nonshared
context
   Product: D
   Version: D2
  Hardware: All
   URL: https://dlang.org/phobos/core_thread.html#.Thread.this
.2
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: dfj1es...@sneakemail.com

This allows implicit data sharing. Also looks like Semaphore tests rely on this
behavior: https://forum.dlang.org/post/aswqyosonizpnpysn...@forum.dlang.org

--

Re: When I should to call destroy?

On Friday, July 29, 2016 13:18:00 Suliman via Digitalmars-d-learn wrote:
> Use the `destroy` function to finalize an object by calling its
> destructor. The memory of the object is not immediately
> deallocated, instead the GC will collect the memory of the object
> at an undetermined point after finalization:
>
> class Foo { int x; this() { x = 1; } }
> Foo foo = new Foo;
> destroy(foo);
> assert(foo.x == int.init);  // object is still accessible
>
>
> But I can't understand if D have GC it should remove objects when
> their life is finished. When I should to call `destroy`? What
> would be if I will not call it?

destroy is for when you need to explicitly call the destructor on an object.
It destroys it without freeing the memory. There are some rare cases where
that is extremely useful, but odds are, you'll never need it.

- Jonathan M Davis

FunctionTypeOf behaves unexpectedly for function pointers?

2016-07-29 Thread pineapple via Digitalmars-d-learn

This failure seems curious and I haven't been able to understand 
why it occurs, or whether it might be intentional. For all other 
callable types, including functions and delegates and types 
implementing opCall, the assertion passes.


import std.traits : FunctionTypeOf;
void function() func;
// Error: static assert  (is(void() == void function())) is 
false

static assert(is(FunctionTypeOf!func == typeof(func)));

Re: When I should to call destroy?

2016-07-29 Thread Lodovico Giaretta via Digitalmars-d-learn


On Friday, 29 July 2016 at 13:18:00 UTC, Suliman wrote:
Use the `destroy` function to finalize an object by calling its 
destructor. The memory of the object is not immediately 
deallocated, instead the GC will collect the memory of the 
object at an undetermined point after finalization:


class Foo { int x; this() { x = 1; } }
Foo foo = new Foo;
destroy(foo);
assert(foo.x == int.init);  // object is still accessible


But I can't understand if D have GC it should remove objects 
when their life is finished. When I should to call `destroy`? 
What would be if I will not call it?


Destroy will call the destructors, but memory will not actually 
be deallocated before the next GC cycle. It is used because the 
GC cycle does not guarantee to run the destructors, so using 
destroy the destructor is ran immediately (guaranteed). Then, on 
next GC iteration, the memory will be freed. Until then, 
referencing it will not cause segfault, but will cause undefined 
behaviour, as after a destructor the state of the object is 
undefined (I think).

Re: Documented unittests & code coverage

2016-07-29 Thread Jack Stouffer via Digitalmars-d


On Friday, 29 July 2016 at 07:01:35 UTC, Walter Bright wrote:
The pilot reads the indicated value, interprets it in the 
context of what the other instruments say, APPLIES GOOD 
JUDGMENT, and flies the airplane.


Continuing with this metaphor, in this situation you're not the 
pilot making the judgement, you're the aerospace engineer 
deciding that the speedometer in the plane can be off by several 
hundred m/s and it's no big deal.


Yes, every measurement in the real world has a margin of error. 
But, since we're dealing with computers this is one of the rare 
situations where a perfect number can actually be obtained and 
presented to the user.



There is no right or wrong airspeed.


The right one is the actual speed of the plane and the wrong one 
is every other number.

[Issue 16182] std.traits.fullyQualifiedName Bug

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

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

https://github.com/dlang/phobos/commit/59df244abb8296089285c14935c498d624bc5890
Fix for issue 16182

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

It is beyond my comprension as to why this irrelevant change helps
fixes #16182. I believe there is something amiss becuase expression
fqnSym!(__traits(parent, T)) ~ '.' is returning a char[] while
fqnSym!(__traits(parent, T)) ~ "." returns a string. This while
expression fqnSym!(__traits(parent, T)) returns a string.

https://github.com/dlang/phobos/commit/f75eeb596d44544e98a23ee1fd0b60f9ae8b0956
Merge pull request #4437 from puneet/master

Fix for for issue 16182 - std.traits.fullyQualifiedName Bug

--

Re: When I should to call destroy?

2016-07-29 Thread Kagamin via Digitalmars-d-learn


On Friday, 29 July 2016 at 13:18:00 UTC, Suliman wrote:
But I can't understand if D have GC it should remove objects 
when their life is finished. When I should to call `destroy`? 
What would be if I will not call it?


You should call destroy when you want to call the destructor 
deterministically, see 
https://en.wikipedia.org/wiki/Resource_management_%28computing%29 
- compare with automatic resource management.

Re: When I should to call destroy?

2016-07-29 Thread Cauterite via Digitalmars-d-learn


On Friday, 29 July 2016 at 13:18:00 UTC, Suliman wrote:
But I can't understand if D have GC it should remove objects 
when their life is finished. When I should to call `destroy`? 
What would be if I will not call it?


`destroy` is mainly about running destructors deterministically. 
From the source comments:


"It's used to destroy an object so that any cleanup which its 
destructor or finalizer does is done and so that it no longer 
references any other objects."


For example, your object might allocate a large amount of 
manually-managed memory, and you don't want that allocation 
laying around until the next GC cycle, so you can use `destroy` 
to finalise your object as early as possible to release that 
manually-managed allocation.


If you really want to deallocate the object's own memory, you can 
check out core.memory.GC.query() / core.memory.GC.free().

When I should to call destroy?

2016-07-29 Thread Suliman via Digitalmars-d-learn

Use the `destroy` function to finalize an object by calling its 
destructor. The memory of the object is not immediately 
deallocated, instead the GC will collect the memory of the object 
at an undetermined point after finalization:


class Foo { int x; this() { x = 1; } }
Foo foo = new Foo;
destroy(foo);
assert(foo.x == int.init);  // object is still accessible


But I can't understand if D have GC it should remove objects when 
their life is finished. When I should to call `destroy`? What 
would be if I will not call it?

Re: Things that make writing a clean binding system more difficult

2016-07-29 Thread Dicebot via Digitalmars-d

On 07/29/2016 03:55 PM, Jonathan M Davis via Digitalmars-d wrote:
> On Friday, July 29, 2016 14:14:49 Dicebot via Digitalmars-d wrote:
>> What you want it contradictory to the concept of "storage class".
> 
> Why? I thought the the whole idea of "storage class" was that it was an
> attribute that was applied to a type that wasn't actually part of the type.
> Certainly, based on past discussions on the topic, it seems to be that the
> term is used for pretty much anything that gets applied to a type that isn't
> actually part of the type. And that's definitely what happens with ref.
> 
> - Jonathan M Davis

Storage class has to attach to some symbol to modify its semantics
without affecting the type, it doesn't apply to type at all. Usually it
is a variable and that comes naturally but in case of function return
value / parameters the only available symbol is function itself -
contrary to variables, parameters are not available as independent
symbols AFAIK.

That said, `ref` isn't a 100% storage class, otherwise `alias Foo = ref
int function ( )` wouldn't work. Judging by only observable semantics
I'd say it is more akin to type qualifier contrary to what spec says -
but qualifier of function type.

[Issue 16334] dmd producing invalid OMF file

2016-07-29 Thread Edwin van Leeuwen via Digitalmars-d-announce

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

Ketmar Dark  changed:

   What|Removed |Added

 CC||ket...@ketmar.no-ip.org

--- Comment #1 from Ketmar Dark  ---
it is major, 'cause it prevents some of my dynamic bindings from working on
windows, and overall it is perfectly valid code (working on GNU/Linux) which is
not working on windows. so i believe that it is major in terms of
cross-platform support.

--

Re: Battle-plan for CTFE


On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote:

I have fresh performance statistics:


Is there any improvement in memory usage?

Re: Things that make writing a clean binding system more difficult

2016-07-29 Thread Jonathan M Davis via Digitalmars-d

On Friday, July 29, 2016 14:14:49 Dicebot via Digitalmars-d wrote:
> On 07/29/2016 02:05 PM, Jonathan M Davis via Digitalmars-d wrote:
> > On Friday, July 29, 2016 02:55:14 Walter Bright via Digitalmars-d wrote:
> >> On 7/29/2016 1:34 AM, Jonathan M Davis via Digitalmars-d wrote:
> >>> I've always looked at D's ref as being essentially the same as C++'s &
> >>> except that it's not considered to be part of the type, just attached to
> >>> it
> >>> in a way that doesn't propagate. The same with with in or out. I just
> >>> don't
> >>> see how it even makes conceptual sense for ref to be an attribute of the
> >>> function itself.
> >>
> >> C++'s & is a bizarre type constructor in that it has completely wacky and
> >> special cased behavior in just about everything involving types,
> >> including
> >> type deduction, type inference, overloading, etc. For example, you can't
> >> have a pointer to a ref. Or a ref of a ref. Sometimes the ref is
> >> considered
> >> part of the type, sometimes not. Etc.
> >>
> >> With D, making it a sort of storage class completely sidesteps that mess.
> >
> > I understand that part. It's treating it like a function attribute that
> > makes no sense to me. Even if it's not treated as part of the return type
> > exactly, it's still the return type that it's affecting, not the function.
> > ref, in, and out are all in this kind of weird place where they affect a
> > type without being part of the type, and I'm guessing that because of how
> > oddball they are, there really wasn't a good way to deal with ref on the
> > return type, since it wasn't actually part of the type, so in the
> > implementation, it got tied to the function instead rather than trying to
> > add a new concept to the compiler. So, I guess that from an implementation
> > perspective, it makes some sense, but it's still downright weird given
> > that
> > ref really has to do with the return type and not the function itself,
> > even
> > if ref is a storage class rather than actually being part of the type.
>
> What you want it contradictory to the concept of "storage class".

Why? I thought the the whole idea of "storage class" was that it was an
attribute that was applied to a type that wasn't actually part of the type.
Certainly, based on past discussions on the topic, it seems to be that the
term is used for pretty much anything that gets applied to a type that isn't
actually part of the type. And that's definitely what happens with ref.

- Jonathan M Davis

Re: Battle-plan for CTFE

2016-07-29 Thread Robert burner Schadek via Digitalmars-d-announce


On Friday, 29 July 2016 at 11:30:20 UTC, Stefan Koch wrote:

please share your thoughts.


When is this moving into dmd master?

Re: C's void func() vs. void func(void).

2016-07-29 Thread ciechowoj via Digitalmars-d-learn


On Friday, 29 July 2016 at 12:20:17 UTC, Mike Parker wrote:


Though, I should add the caveat that you need to ensure the 
definition of the C function does not specify any parameters. 
AFAIK, this is legal:


// foo.h
void func();

// foo.c
void func(int a, int b) { ... }

In which case you would want to include the parameters in your 
binding.


Thanks, good to know.

Re: string mixin and alias

2016-07-29 Thread pineapple via Digitalmars-d-learn


On Friday, 29 July 2016 at 12:22:54 UTC, Andre Pany wrote:

It is more or less syntax sugar. In the main function instead
of writing "mixin(generateCode(s));" I want to write "foo(s);".
So, the mixin statement is hidden while the functionality of 
mixin stays.


Kind regards
André



As far as I know, there's no way to hide away the `mixin` 
statement in a template or alias. You could do something like 
this, if you really wanted to, but really the only difference is 
that it uses fewer parentheses.


string generateCode(string s){return "";}
enum foo(string s) = generateCode(s);

void main(){
enum s = "int a = 2 + 3; int b = 4 + a;";
mixin foo!s;
}

Re: Things that make writing a clean binding system more difficult

2016-07-29 Thread Kagamin via Digitalmars-d


On Thursday, 28 July 2016 at 20:16:11 UTC, Jonathan M Davis wrote:
Well, if we decided to make parens with ref legal, then we 
could make it work. e.g.


ref(int) function(int, int) functionPointer;

Now, I don't know of any other case where you'd actually use 
parens with ref if it were legal, but it would solve this 
particular case if we wanted to provide a way around the 
ambiguity.


I had an idea of putting function attributes between return type 
and function name:

int ref function(int, int)

Re: string mixin and alias

2016-07-29 Thread Steven Schveighoffer via Digitalmars-d-learn


On 7/29/16 2:38 AM, Andre Pany wrote:

Hi,

is there a way to alias a string mixin?
Neither foo nor foo2 compiles.

import std.meta : Alias;
alias foo = (s) => Alias!(mixin(generateCode(s)));


s is a runtime parameter. You can't mixin stuff that is only available 
at runtime.



alias foo2(string s) = Alias!(mixin(generateCode(s)));


This would work if the string is "main", let's say.


string generateCode(string s){return "";}

void main()
{
  enum s = "a = 2 + 3; b = 4 + a;";


This does not result in a symbol, an alias needs a symbol.

-Steve

Re: Things that make writing a clean binding system more difficult

2016-07-29 Thread Steven Schveighoffer via Digitalmars-d


On 7/29/16 12:44 AM, Timon Gehr wrote:


My parser accepts the following:

int function(int,int)ref functionPointer;

I wasn't really aware that this was illegal in DMD. (Other function
attributes, such as pure, are accepted.)

In fact, even the following is disallowed:
int foo(int)ref{}


Should I file an enhancement request?


Yes. Worst that happens is it doesn't get accepted :)

-Steve

Re: Documented unittests & code coverage

2016-07-29 Thread Steven Schveighoffer via Digitalmars-d


On 7/29/16 3:01 AM, Walter Bright wrote:

On 7/28/2016 11:07 PM, Jack Stouffer wrote:

you're making a decision on the user's behalf that coverage % is
unimportant without knowing their circumstances.


Think of it like the airspeed indicator on an airplane. There is no
right or wrong airspeed. The pilot reads the indicated value, interprets
it in the context of what the other instruments say, APPLIES GOOD
JUDGMENT, and flies the airplane.

You won't find many pilots willing to fly without one.



What if the guage was air-speed added to fuel level, and you didn't get 
a guage for each individually?


-Steve

Re: C's void func() vs. void func(void).

2016-07-29 Thread Mike Parker via Digitalmars-d-learn


On Friday, 29 July 2016 at 12:15:22 UTC, Mike Parker wrote:



Yes, this is correct as long as the calling convention is not 
stdcall or something else:


Though, I should add the caveat that you need to ensure the 
definition of the C function does not specify any parameters. 
AFAIK, this is legal:


// foo.h
void func();

// foo.c
void func(int a, int b) { ... }

In which case you would want to include the parameters in your 
binding.

Re: string mixin and alias

2016-07-29 Thread Andre Pany via Digitalmars-d-learn


On Friday, 29 July 2016 at 12:11:44 UTC, pineapple wrote:

On Friday, 29 July 2016 at 06:38:17 UTC, Andre Pany wrote:

Hi,

is there a way to alias a string mixin?
Neither foo nor foo2 compiles.

import std.meta : Alias;
alias foo = (s) => Alias!(mixin(generateCode(s)));
alias foo2(string s) = Alias!(mixin(generateCode(s)));

string generateCode(string s){return "";}

void main()
{
  enum s = "a = 2 + 3; b = 4 + a;";
  foo(s);
  foo2(s);
}

Kind regards
André


It's not clear what you're trying to accomplish. What would you 
expect this code to do?


It is more or less syntax sugar. In the main function instead
of writing "mixin(generateCode(s));" I want to write "foo(s);".
So, the mixin statement is hidden while the functionality of 
mixin stays.


Kind regards
André

[Issue 16334] New: dmd producing invalid OMF file

2016-07-29 Thread Mike Parker via Digitalmars-d-announce

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

  Issue ID: 16334
   Summary: dmd producing invalid OMF file
   Product: D
   Version: D2
  Hardware: x86
OS: Windows
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: ket...@ketmar.no-ip.org

the following file fails to link:

alias afunc = void function ();
afunc func = () { func = cast(afunc)null; };
void main () {}


the error is:

OPTLINK (R) for Win32  Release 8.00.17
Copyright (C) Digital Mars 1989-2013  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
xreader.obj(xreader)  Offset 002B5H Record Type 009D
 Error 16: Index Range

--

Re: C's void func() vs. void func(void).

2016-07-29 Thread Mike Parker via Digitalmars-d-learn


On Friday, 29 July 2016 at 10:57:37 UTC, ciechowoj wrote:
In C, a function `void func()` doesn't declare a function 
without arguments, instead it declares a function that takes 
unspecified number of arguments. The correct way to declare a 
function that takes no arguments is to use the `void` keyword: 
`void func(void)`.


What is the correct way to refer to such a function (`void 
func()`) from D bindings?


If I assume that the unspecified number of arguments (for some 
particular function) is equal to zero, is `extern (C) void 
func()` a correct D binding to the both functions `void func()` 
and `void func(void)` declared in C?


Specifically, I'm concerned about calling convention issues.


Yes, this is correct as long as the calling convention is not 
stdcall or something else:


extern(C) void func();

If you're dealing with stdcall:

extern(Windows) void func();

And if it is a cross-platform library that is stdcall on Windows 
and cdecl elsewhere:


extern(C) void fun();

Re: string mixin and alias

2016-07-29 Thread pineapple via Digitalmars-d-learn


On Friday, 29 July 2016 at 06:38:17 UTC, Andre Pany wrote:

Hi,

is there a way to alias a string mixin?
Neither foo nor foo2 compiles.

import std.meta : Alias;
alias foo = (s) => Alias!(mixin(generateCode(s)));
alias foo2(string s) = Alias!(mixin(generateCode(s)));

string generateCode(string s){return "";}

void main()
{
  enum s = "a = 2 + 3; b = 4 + a;";
  foo(s);
  foo2(s);
}

Kind regards
André


It's not clear what you're trying to accomplish. What would you 
expect this code to do?

From the D Blog: Martin Nowak on the DMD release process

It was time for another Core Team Update on the D Blog. This time 
around, Martin Nowak shares how he got involved with the DMD 
release process and where you can learn more about it. The post 
is at [1] and the reddit thread at [2].


Now that Vladimir and Martin have gotten their updates out of the 
way, I foresee some prodding, cajoling and arm twisting in my 
future for the next couple :)


[1] 
https://dlang.org/blog/2016/07/29/core-team-update-martin-nowak/
[2] 
https://www.reddit.com/r/programming/comments/4v68ty/from_the_d_blog_martin_nowak_on_the_dmd_release/

Re: Question about destructor of database and multiple use access

2016-07-29 Thread Suliman via Digitalmars-d-learn


So my last variant is right?

How can I inspect code, to better understand how GC works? Also 
where I can find idiomatic code with comments? Just to read for 
better understand design solutions.

Re: Battle-plan for CTFE

2016-07-29 Thread Stefan Koch via Digitalmars-d-announce


Hi,

I have fresh performance statistics:
The test[1] involved running an empty while loop.

Machine 1 Linux :
DMD release : Interpreted : 3400 ms || Pseudo-Jited 230 || 50ms 
Native
DMD Debug : Interpreted 4560 || Pseudo-Jited 260ms || Native 230 
ms


LDC release : Interpreted 2400 ms || Pseudo-Jited 0 ms || Native 
0 ms
LDC debug : Interpreted 8700 ms || Pseudo-Jited 330 ms || Native 
250 ms


Machine 2 Windows :

DMD release : Interpreted : 5500 ms || Pseudo-Jited 180ms || 40ms 
Native
DMD Debug : Interpreted 5500 || Pseudo-Jited 320ms || Native 180 
ms



Pay attention to the ratio (~4.5) between (pseudo)jit[2] and 
native.

This slowdown inherent in the VM design I choose.

please share your thoughts.

[1] https://github.com/UplinkCoder/dmd/blob/newCTFE/bcPerf.d
[2] 
https://github.com/UplinkCoder/dmd/blob/newCTFE/src/bc_c_backend.d

Re: [OT] Re: Make D language as Apache foundation project

2016-07-29 Thread ksdflikdsjus via Digitalmars-d


On Thursday, 28 July 2016 at 09:23:09 UTC, jdfgjdf wrote:

On Thursday, 28 July 2016 at 09:19:03 UTC, Jack Applegame wrote:

On Wednesday, 27 July 2016 at 15:44:21 UTC, Seb wrote:


http://dlang.org/foundation.html

Wow. This page details Andrei's full name: Tudor Andrei 
Cristian Alexandrescu. (o_O)


It's probably to avoid any confusion with the other Andrei 
Alexandrescu. (warning big LOL)


http://adevarul.ro/locale/targoviste/performanTA-targovisteanul-andrei-alexandrescu-campion-national-culturism-1_50abbb487c42d5a6637f642b/index.html


Maybe they are the same...so "Alexandresc-Hulk", he blows the 
skirt when he's angry.

Re: New Diet template engine almost complete, ready for comments

Talking about diets, will reShop[1] be available for Android an 
iOS too? You could extend it by adding "health tips" (add fruit & 
veg automatically), a calorie counter (for single items and the 
whole list) ;)


http://rejectedsoftware.com/products/reshop

Re: Things that make writing a clean binding system more difficult

2016-07-29 Thread Dicebot via Digitalmars-d

On 07/29/2016 02:05 PM, Jonathan M Davis via Digitalmars-d wrote:
> On Friday, July 29, 2016 02:55:14 Walter Bright via Digitalmars-d wrote:
>> On 7/29/2016 1:34 AM, Jonathan M Davis via Digitalmars-d wrote:
>>> I've always looked at D's ref as being essentially the same as C++'s &
>>> except that it's not considered to be part of the type, just attached to
>>> it
>>> in a way that doesn't propagate. The same with with in or out. I just
>>> don't
>>> see how it even makes conceptual sense for ref to be an attribute of the
>>> function itself.
>>
>> C++'s & is a bizarre type constructor in that it has completely wacky and
>> special cased behavior in just about everything involving types, including
>> type deduction, type inference, overloading, etc. For example, you can't
>> have a pointer to a ref. Or a ref of a ref. Sometimes the ref is considered
>> part of the type, sometimes not. Etc.
>>
>> With D, making it a sort of storage class completely sidesteps that mess.
> 
> I understand that part. It's treating it like a function attribute that
> makes no sense to me. Even if it's not treated as part of the return type
> exactly, it's still the return type that it's affecting, not the function.
> ref, in, and out are all in this kind of weird place where they affect a
> type without being part of the type, and I'm guessing that because of how
> oddball they are, there really wasn't a good way to deal with ref on the
> return type, since it wasn't actually part of the type, so in the
> implementation, it got tied to the function instead rather than trying to
> add a new concept to the compiler. So, I guess that from an implementation
> perspective, it makes some sense, but it's still downright weird given that
> ref really has to do with the return type and not the function itself, even
> if ref is a storage class rather than actually being part of the type.

What you want it contradictory to the concept of "storage class".

Re: Things that make writing a clean binding system more difficult

2016-07-29 Thread Jonathan M Davis via Digitalmars-d

On Friday, July 29, 2016 02:55:14 Walter Bright via Digitalmars-d wrote:
> On 7/29/2016 1:34 AM, Jonathan M Davis via Digitalmars-d wrote:
> > I've always looked at D's ref as being essentially the same as C++'s &
> > except that it's not considered to be part of the type, just attached to
> > it
> > in a way that doesn't propagate. The same with with in or out. I just
> > don't
> > see how it even makes conceptual sense for ref to be an attribute of the
> > function itself.
>
> C++'s & is a bizarre type constructor in that it has completely wacky and
> special cased behavior in just about everything involving types, including
> type deduction, type inference, overloading, etc. For example, you can't
> have a pointer to a ref. Or a ref of a ref. Sometimes the ref is considered
> part of the type, sometimes not. Etc.
>
> With D, making it a sort of storage class completely sidesteps that mess.

I understand that part. It's treating it like a function attribute that
makes no sense to me. Even if it's not treated as part of the return type
exactly, it's still the return type that it's affecting, not the function.
ref, in, and out are all in this kind of weird place where they affect a
type without being part of the type, and I'm guessing that because of how
oddball they are, there really wasn't a good way to deal with ref on the
return type, since it wasn't actually part of the type, so in the
implementation, it got tied to the function instead rather than trying to
add a new concept to the compiler. So, I guess that from an implementation
perspective, it makes some sense, but it's still downright weird given that
ref really has to do with the return type and not the function itself, even
if ref is a storage class rather than actually being part of the type.

- Jonathan M Davis

Re: Documented unittests & code coverage

2016-07-29 Thread Chris via Digitalmars-d


On Friday, 29 July 2016 at 07:01:35 UTC, Walter Bright wrote:

On 7/28/2016 11:07 PM, Jack Stouffer wrote:
you're making a decision on the user's behalf that coverage % 
is

unimportant without knowing their circumstances.


Think of it like the airspeed indicator on an airplane. There 
is no right or wrong airspeed. The pilot reads the indicated 
value, interprets it in the context of what the other 
instruments say, APPLIES GOOD JUDGMENT, and flies the airplane.


You won't find many pilots willing to fly without one.


Maybe it would help to give more than one value, e.g. the actual 
code coverage, i.e. functions and branches executed in the actual 
program, and commands executed in the unit test. So you would have


100% code coverage
95% total commands executed (but don't worry!)

C's void func() vs. void func(void).

2016-07-29 Thread ciechowoj via Digitalmars-d-learn

In C, a function `void func()` doesn't declare a function without 
arguments, instead it declares a function that takes unspecified 
number of arguments. The correct way to declare a function that 
takes no arguments is to use the `void` keyword: `void 
func(void)`.


What is the correct way to refer to such a function (`void 
func()`) from D bindings?


If I assume that the unspecified number of arguments (for some 
particular function) is equal to zero, is `extern (C) void 
func()` a correct D binding to the both functions `void func()` 
and `void func(void)` declared in C?


Specifically, I'm concerned about calling convention issues.

Re: The D Language Foundation has filed for non-profit status

On Thursday, 21 July 2016 at 02:16:55 UTC, Andrei Alexandrescu 
wrote:

Hello everyone,


Effective today the IRS has received the application of The D 
Language Foundation for tax-exempt (non-profit) status. An 
attorney and an accountant have helped me with the application. 
Going forward, they will work with us on a need basis.


Following the next few months we have an odd "limbo" status. 
After that (most likely before the end of this year) we will 
get a decision (or more questions) from the IRS.


This is an important milestone for the Foundation and for the D 
language development. The tax-exempt status will allow the 
Foundation to receive tax-advantageous donations from other 
organizations, and to fully use funds for the development of 
the language.


By the Foundation bylaws we defined, the officers of the 
Foundation (Walter, Ali, and myself) are not allowed to receive 
payment for their work on the Foundation.


Many thanks to our wonderful grass-roots and corporate 
community that has been ever so constructive and supportive in 
this endeavor.



Andrei


o   o
|\
 \ ___   /
  |,-oo\\
  ||||
  ||||
  ||   //
  ||__//
  '---
   \  \
   /  /
   ^  ^

Re: Things that make writing a clean binding system more difficult

2016-07-29 Thread Jean-Yves Vion-Dury via Digitalmars-d-learn


On 7/29/2016 1:34 AM, Jonathan M Davis via Digitalmars-d wrote:

I've always looked at D's ref as being essentially the same as C++'s &
except that it's not considered to be part of the type, just attached to it
in a way that doesn't propagate. The same with with in or out. I just don't
see how it even makes conceptual sense for ref to be an attribute of the
function itself.


C++'s & is a bizarre type constructor in that it has completely wacky and 
special cased behavior in just about everything involving types, including type 
deduction, type inference, overloading, etc. For example, you can't have a 
pointer to a ref. Or a ref of a ref. Sometimes the ref is considered part of the 
type, sometimes not. Etc.


With D, making it a sort of storage class completely sidesteps that mess.

Re: Why D isn't the next "big thing" already

2016-07-29 Thread llaine via Digitalmars-d-learn


On Thursday, 28 July 2016 at 15:16:20 UTC, Gorge Jingale wrote:

On Wednesday, 27 July 2016 at 10:41:54 UTC, ketmar wrote:

On Wednesday, 27 July 2016 at 10:39:52 UTC, NX wrote:

Lack of production quality tools


like? no, "refactoring" and other crap is not "production 
quality tools", they are only useful to pretend that you are 
doing something useful, so you will look busy for your boss.



Guys please, I'm just trying to do something constructive here.

Re: Things that make writing a clean binding system more difficult

2016-07-29 Thread Jonathan M Davis via Digitalmars-d

On Friday, July 29, 2016 09:03:18 Timon Gehr via Digitalmars-d wrote:
> 'ref' has nothing to do with the type. This is not C++.
>
> The only thing that is inconsistent here is that 'ref' is not accepted
> on the right for function declarations.

ref may not be part of the type, but it just seems totally wrong for it to
be applying to anything else. I mean, how does it make any sense for a
_function_ to be ref or not? It may return by ref, but the function itself
is a function. It's what's going on with the return value that changes based
or ref or not.

Maybe I'm just looking at this wrong, but it seems completely bizarre to
consider the _function_ to be ref or not. It sounds like it's just a weird
biproduct of trying to make it so that ref doesn't propagate beyond the
return type or the parameter so that you can't have ref variables in
general.

I've always looked at D's ref as being essentially the same as C++'s &
except that it's not considered to be part of the type, just attached to it
in a way that doesn't propagate. The same with with in or out. I just don't
see how it even makes conceptual sense for ref to be an attribute of the
function itself.

- Jonathan M Davis

Re: Can't Compile Global Semaphores?


On Monday, 21 March 2016 at 13:19:34 UTC, denizzzka wrote:

On Monday, 27 July 2015 at 20:12:10 UTC, John Colvin wrote:


Yes, but then core.sync.semaphore doesn't support being 
shared, so...


I don't really understand how 
https://github.com/D-Programming-Language/druntime/blob/master/src/core/sync/semaphore.d#L356 is managing to avoid this


Since that time is something cleared up? Faced with the same 
problem


And same for me also; I really need shared semaphores, for 
implementing complex synchronization queues (they have to be 
nested inside shared classes). That's rather disappointing to 
offer semaphores without thread sharing mechanisms beyond 
__gshared. Is there anything we could do to solve this?

best
NB
thanks to all D contributors

Re: Things that make writing a clean binding system more difficult

2016-07-29 Thread Timon Gehr via Digitalmars-d


On 29.07.2016 08:51, Jonathan M Davis via Digitalmars-d wrote:

On Friday, July 29, 2016 08:29:19 Timon Gehr via Digitalmars-d wrote:

On 29.07.2016 06:52, Jonathan M Davis via Digitalmars-d wrote:

On Friday, July 29, 2016 06:44:16 Timon Gehr via Digitalmars-d wrote:

My parser accepts the following:

int function(int,int)ref functionPointer;

I wasn't really aware that this was illegal in DMD. (Other function
attributes, such as pure, are accepted.)

In fact, even the following is disallowed:
int foo(int)ref{}


Should I file an enhancement request?


Except that ref isn't a function attribute.


Yes it is.

int x;
ref{
 int foo(){ return x;}
}
pragma(msg, typeof(()));


That's downright bizzarre given that ref applies to the return type and not
to the this pointer (and that function doesn't even have a this pointer,
since it's not a member function).
...


It does not apply to the return type. There is actually no way to tell 
whether a function returns ref or not by just examining the return type. 
It's the function which is ref.



It's an attribute on the return type.


There is no such thing. Types cannot have attributes.


Sure they can. e.g.

auto func(ref int param) {...}

The same with in and out. They apply to the type of the parameter without
actually being part of it.
...


No, typeof(param) is int. The type is not changed at all. The attribute 
applies to the parameter declaration.



So, it doesn't make sense for it to be on the right. That would be
like having the const on the right-hand side of a member function apply to
the return type rather than the function itself.
...


You have it backwards.


It looks to me like the compiler is treating ref in a schizophrenic manner
given that when it's used on a parameter, it treats it as part of the
parameter, whereas with the return type, it's treating it as a function
attribute instead of associating it with the return type. I'd guess that
that stems from the fact that while ref is really supposed to be associated
with the type, it's not actually part of the type.

- Jonathan M Davis



'ref' has nothing to do with the type. This is not C++.

The only thing that is inconsistent here is that 'ref' is not accepted 
on the right for function declarations.

Re: Documented unittests & code coverage


On 7/28/2016 11:07 PM, Jack Stouffer wrote:

you're making a decision on the user's behalf that coverage % is
unimportant without knowing their circumstances.


Think of it like the airspeed indicator on an airplane. There is no right or 
wrong airspeed. The pilot reads the indicated value, interprets it in the 
context of what the other instruments say, APPLIES GOOD JUDGMENT, and flies the 
airplane.


You won't find many pilots willing to fly without one.

Re: Documented unittests & code coverage