Re: Named arguments via struct initialization in functions

[Chris Wright via Digitalmars-d]

On Thu, 10 Mar 2016 19:01:53 +, ZombineDev wrote:

> On Monday, 7 March 2016 at 19:06:54 UTC, Chris Wright wrote:
>> On Mon, 07 Mar 2016 11:06:13 +, ZombineDev wrote:
>>> The compiler should detect that this call is ambiguous and would not
>>> allow it.
>>
>> It's a potentially significant amount of work to determine that the
>> expression is ambiguous, or to disambiguate.
> 
> I don't think so. At least not much more than what currently the
> compiler does for overload resolution (comparing the void(A) overloard
> to the void(B)).

Currently, overload resolution deals with a similar problem with numeric 
literals. But there's a big difference between supporting it for one 
class of related types that's all known at compile time, and supporting 
it for an open-ended set of types that are entirely unrelated.

If I were implement this, the first pass would require struct literal 
expressions to include the struct type. I might later consider whether to 
change that.

> Tuples literals / struct initializer literals /
> delegates should be classified before the end of the parsing phase

That is, you can determine whether something is a delegate literal or a 
struct literal (even without marking struct literals with their type) 
during parsing. For a moment, I misunderstood and thought you were 
talking about assigning types to them.

> (which is actually at least an order of magnitude faster than the
> semantic phase).

It wouldn't be parseable with an LL(k) parser, which is a minor thing. 
More to the point, depending on how DMD's parser is designed, it might be 
pretty awkward to parse something that might be a labeled statement or a 
struct variable initializer.

If we can get something that's approximately as good (arguably better 
because it's less ambiguous, arguably worse because it's more to type) 
with far less work, then, given the small number of people who contribute 
to DMD, it would behoove us to choose the easier option.

Re: Use of GUID constants

[thedeemon via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 15:48:14 UTC, Mike Parker wrote:
Personally I would just declare one immutable value in module 
scope and be done with it. It really just doesn't matter. 
Unless you're following some sort of style guide, personal 
preference rules the day. I don't know if Rainers has a special 
reason for what he did with the Visual D code or if it was 
personal preference.


There is one good reason for doing it VisualD way.
It defines and uses smart pointers ComPtr(ISomething) where you 
can just write


auto x = ComPtr!ISomeInterface(someObject);

and if someObject has a different COM type this constructor will 
QueryInterface() for the proper interface, and to do this it 
needs to know its IID, so a common way to get IID knowing just an 
interface type is really helpful.

Re: Suggested Change to Contract Syntax

[Jonathan M Davis via Digitalmars-d]

On Friday, 11 March 2016 at 04:17:51 UTC, jmh530 wrote:
On Friday, 11 March 2016 at 01:45:36 UTC, Jonathan M Davis 
wrote:


Sure, but if you're not using in/out contracts with a class, 
you're not going to see how they interact with inheritance. To 
mimic what they do, you'd have to duplicate the base class 
contracts in the derived class and make sure that you ||ed the 
in contracts correctly and & the out contracts correctly, 
which isn't very maintainable.


- Jonathan M Davis


If I'm understanding you correctly, you could still get the 
same behavior with something like below (though it isn't 
exactly right since Base.foo's in block would technically have 
a funky rule applied to it).


Yeah, you can do something like that and get it to work, but it 
gets increasingly tricky, the more complicated the contracts are, 
and it's pretty easy to screw it up. Certainly, it's far cleaner 
and less error-prone to have it built into the language like we 
do.


After playing around with your example, I'm finding in/out 
blocks on derived classes to be tricky. I think I'm going to 
try to avoid putting myself in a situation where I would screw 
something up.


Yeah. Having complicated contracts is probably a bad idea in 
general, but it gets far worse when inheritance is involved. And 
you can give yourself some weird problems even with the built-in 
help that D gives you. For instance, in my example, the derived 
class' in contract was a looser version of the base class' in 
contract, which is usually what you'd be looking to do, but the 
way it works is that the bass class' in contract and the derived 
class' in contract are ||ed. So, technically, you could make it 
so that the two contracts are completely distinct or so that the 
derived class' in contract is tighter, but what you ultimately 
end up with is the two in contracts ||ed, whereas what most folks 
will probably expect at a glance is that the derived class' 
contract will be met. So, doing something like


base class: assert(i < 50);
derived class: assert(i < 10);

or

bass class: assert(i < 50);
derived class: assert(i > 50);

will quickly make it so that you could have a derived class 
function which expects the derived class' in contract to be pass 
when it doesn't, because what's tested is the ||ing or the 
contracts not just the derived class contract.


So, ultimately, you still have to be familiar with how the in and 
out contracts are supposed to work with inheritance to avoid 
shooting yourself in the foot, but having it built in makes it so 
that it's harder to screw it up. It just doesn't fix the whole 
problem for you.


Regardless, I'd be _very_ careful with contracts and inheritance, 
and having complicated contracts with inheritance seems a bit 
suicidal.


- Jonathan M Davis

Re: Suggested Change to Contract Syntax

[jmh530 via Digitalmars-d]

On Friday, 11 March 2016 at 01:45:36 UTC, Jonathan M Davis wrote:


Sure, but if you're not using in/out contracts with a class, 
you're not going to see how they interact with inheritance. To 
mimic what they do, you'd have to duplicate the base class 
contracts in the derived class and make sure that you ||ed the 
in contracts correctly and & the out contracts correctly, 
which isn't very maintainable.


- Jonathan M Davis


If I'm understanding you correctly, you could still get the same 
behavior with something like below (though it isn't exactly right 
since Base.foo's in block would technically have a funky rule 
applied to it).


After playing around with your example, I'm finding in/out blocks 
on derived classes to be tricky. I think I'm going to try to 
avoid putting myself in a situation where I would screw something 
up.


import core.exception;
import std.exception;

class Base
{
void baseCheck(int i)
{
assert(i % 2 == 0, "base out failed");
}

int foo(int i)
{
assert(i > 0 && i < 10, "base in failed");
scope(exit) baseCheck(i);

return i;
}
}

class Derived : Base
{
override int foo(int i)
{
scope(exit) baseCheck(i);

assert(i < 50, "derived in failed");
scope(exit) assert(i % 3 == 0, "derived out failed");

return i;
}
}

Re: is module ( std.experimental.logger) thread-safe.

[Dsby via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 23:56:14 UTC, ZombineDev wrote:

On Sunday, 6 March 2016 at 09:54:49 UTC, Dsby wrote:

I want to use the filelogger to my application.
is the  sharedLog()  global and  thread-safe.


Yes, `FileLogger` internally uses `lockingTextWriter`, so it 
should be safe to call from multiple threads. Furthermore, the 
`sharedLog` property uses atomic load and store instructions, 
so it should be OK to concurrently change the shared logger.


Thanks.
I was test and used in my mutil-threads application.
It works fine.

[Issue 15664] [REG2.064] incorrect initialisation of member of an immutable struct

[via Digitalmars-d-bugs]

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

Martin Krejcirik  changed:

   What|Removed |Added

   Severity|normal  |regression

--

Re: Suggested Change to Contract Syntax

[Jonathan M Davis via Digitalmars-d]

On Friday, 11 March 2016 at 01:04:05 UTC, jmh530 wrote:
On Friday, 11 March 2016 at 00:07:45 UTC, Jonathan M Davis 
wrote:


You're not using in or out contracts here at all, so so of 
course, you're not going to see how in/out contracts work with 
inheritance in this example. To quote 
http://dlang.org/spec/contracts.html:




Sigh...my point was that I was replacing the in/out contracts 
with what you were saying about asserts and scope(exit). Not 
that I have no idea what in/out contracts are.


Sure, but if you're not using in/out contracts with a class, 
you're not going to see how they interact with inheritance. To 
mimic what they do, you'd have to duplicate the base class 
contracts in the derived class and make sure that you ||ed the in 
contracts correctly and & the out contracts correctly, which 
isn't very maintainable.


- Jonathan M Davis

Re: Suggested Change to Contract Syntax

[jmh530 via Digitalmars-d]

On Friday, 11 March 2016 at 00:07:45 UTC, Jonathan M Davis wrote:


You're not using in or out contracts here at all, so so of 
course, you're not going to see how in/out contracts work with 
inheritance in this example. To quote 
http://dlang.org/spec/contracts.html:




Sigh...my point was that I was replacing the in/out contracts 
with what you were saying about asserts and scope(exit). Not that 
I have no idea what in/out contracts are.


I will review what you wrote.

Re: Suggested Change to Contract Syntax

[Jonathan M Davis via Digitalmars-d]

On Thursday, 10 March 2016 at 23:31:22 UTC, FatalCatharsis wrote:
On Thursday, 10 March 2016 at 22:57:41 UTC, Jonathan M Davis 
wrote:
If/Once we get more features in the compiler which take 
advantage of contracts, then I'll likely change my tune on 
that one, but for now, IMHO, they're really only of value in 
classes.


I'm curious, what kind of features might come out of contracts 
in the future? They seem somewhat helpful in terms of QA and 
organization, but what kind of compiler or performance gains 
could you gain from this system?


Well, if you had something like

auto foo(int i)
in
{
assert(i > 10 && i < short.max + 5);
}
body
{
...
}

and the the code called it with a value that's known at compile 
time - e.g. foo(2) - and that value clearly fails the contract, 
then the compiler could treat that as an error. Similarly, it 
would know the valid range of i within the function body, which 
might help with optimizations or with VRP (value range 
propagation - i.e. how it can know that an integral value can fit 
in a smaller integral type and use an implicit cast rather than 
requiring an explicit cast).


Or if you do something with out contracts, e.g.

int foo(int i)
out(result)
{
assert(result => 0 && result < 100);
}
body
{
...
}

then in theory, the compiler could assume that the result passed 
the out contract and optimize based on that. For instance, with 
the code above, maybe it would then treat the result of foo as 
fitting it a ubyte without a cast, because it would know that as 
long as the contract passed, it would fit. e.g.


ubyte bar = foo(9);

Now, I suspect that stuff like that tends to be restricted to 
basic examples, particularly since you usually pass variables to 
functions, not literals, and at the moment, I can't think of much 
useful other than VRP for what could be done with out contracts, 
but in theory, the compiler would know more about what the 
function parameters and return value, and in at least some cases, 
it could optimize based on that or allow certain operations that 
might not be done implicitly in the general case.


So, at this point, I think that it's pretty much all theoretical, 
but we might benefit from it at some point. And given that we 
don't know when such improvements might be made or exactly what 
code they'd benefit, it's arguably better to just use in and out 
contracts now just in case we get those improvements later, and 
the code then benefits without you having to change it, but 
personally, I don't think that that's worth the extra syntactic 
mess, particularly since while such improvements have been 
discussed upon occasion, it's not at all clear that we're ever 
going to get anything like them.


- Jonathan M Davis

Re: Suggested Change to Contract Syntax

[Jonathan M Davis via Digitalmars-d]

On Thursday, 10 March 2016 at 23:31:14 UTC, jmh530 wrote:
On Thursday, 10 March 2016 at 22:57:41 UTC, Jonathan M Davis 
wrote:
IMHO, at this point, inheritance is the only reason they're 
worth

having in the language. [snip]



I created a simple example to understand your point about 
contracts only really mattering for inheritance, but my example 
is giving assertion errors for the inherited class the same way 
as the base class. What would I need to do for this issue to 
become apparent?


class A
{
int a;

this(int x)
{
a = x;
}

int foo(int x)
{
assert(x != 0);
scope(exit) assert((this.a - x) != 0);

return this.a - x;
}
}

class B : A
{
this()
{
super(4);
}

}

void main()
{
import std.stdio : writeln;

auto a = new A(2);
//writeln(a.foo(0)); //causes assertion failure
//writeln(a.foo(2)); //causes assertion failure

auto b = new B();
//writeln(b.foo(0)); //causes assertion failure
//writeln(b.foo(4)); //causes assertion failure
}


You're not using in or out contracts here at all, so so of 
course, you're not going to see how in/out contracts work with 
inheritance in this example. To quote 
http://dlang.org/spec/contracts.html:



If a function in a derived class overrides a function in its 
super class, then only one of the in contracts of the function 
and its base functions must be satisfied. Overriding functions 
then becomes a process of loosening the in contracts.


A function without an in contract means that any values of the 
function parameters are allowed. This implies that if any 
function in an inheritance hierarchy has no in contract, then in 
contracts on functions overriding it have no useful effect.


Conversely, all of the out contracts need to be satisfied, so 
overriding functions becomes a processes of tightening the out 
contracts.



So, it's essentially

assert(baseInContract || derivedInContract);

and

assert(baseOutContract && derivedOutContract);

And here is a totally contrived example:


import core.exception;
import std.exception;

class Base
{
int foo(int i)
in
{
assert(i > 0 && i < 10, "base in failed");
}
out(result)
{
assert(result % 2 == 0, "base out failed");
}
body
{
return i;
}
}

class Derived : Base
{
override int foo(int i)
in
{
assert(i < 50, "derived in failed");
}
out(result)
{
// Combined with the Base.foo out contract, this ends up
// being equivalent to assert(result % 6).
assert(result % 3 == 0, "derived out failed");
}
body
{
return i;
}
}

void main()
{
Base base = new Base;
Base derived = new Derived;

assertNotThrown!AssertError(base.foo(4));
assertNotThrown!AssertError(base.foo(6));
assert(collectExceptionMsg!AssertError(base.foo(0)) == "base 
in failed");
assert(collectExceptionMsg!AssertError(base.foo(12)) == "base 
in failed");
assert(collectExceptionMsg!AssertError(base.foo(100)) == 
"base in failed");
assert(collectExceptionMsg!AssertError(base.foo(5)) == "base 
out failed");
assert(collectExceptionMsg!AssertError(base.foo(9)) == "base 
out failed");


// Combining the out contracts of the Base and Derived make 
this fail for

// Derived when it succeeded for Base alone.
assert(collectExceptionMsg!AssertError(derived.foo(4)) == 
"derived out failed");


assertNotThrown!AssertError(derived.foo(6)); // same as with 
Base
assertNotThrown!AssertError(derived.foo(0)); // Derived 
allows <= 0
assertNotThrown!AssertError(derived.foo(12)); // Derived 
alows >= 10 && < 50


// Whether it's the Base or Derived that fails here is 
implementation defined,

// since it fails for both.
assert(collectExceptionMsg!AssertError(base.foo(100)) == 
"base in failed");


// This fails the contracts of both Base and Derived
assert(collectExceptionMsg!AssertError(derived.foo(5)) == 
"base out failed");


// This passes Derived's contract, but it still doesn't pass 
Base's contract.
assert(collectExceptionMsg!AssertError(derived.foo(9)) == 
"base out failed");

}


In order to get this same behavior without it being built into 
the language, all of the in contracts and out contracts from base 
classes would have to be repeated in the derived classes and be 
||ed or & appropriately. It's feasible, but it's error-prone 
and not particularly maintainable. And considering how easily 
this subject tends to confuse folks and how hard it can be to get 
it right - especially with more complicated contracts - I 
seriously question that it's going to be done right except rarely 
if the programmer doesn't have help like we do by having the 
contracts 

Re: Pitching D to academia

[Thiez via Digitalmars-d]

On Thursday, 10 March 2016 at 23:47:55 UTC, Andrew wrote:
One of awful things about programming in many languages is that 
there's a gazillion tools you need to tack-on before you can do 
any engineering.  In C++ that includes Doxygen for 
documentation, C++Unit for unit tests, gprof, gcov, valgrind, 
and so on.  One of the nice things about D is that so much of 
this is part of the language or build into DMD.


So yes, sure, you can add what ever you like the Java and claim 
its just as good (or better). The difference is that in D its 
all right there already.


Does D have static checking of contracts, either built-in or 
through a tool? Because that is a really nice feature for 
design-by-contract situations.

Re: is module ( std.experimental.logger) thread-safe.

[ZombineDev via Digitalmars-d-learn]

On Sunday, 6 March 2016 at 09:54:49 UTC, Dsby wrote:

I want to use the filelogger to my application.
is the  sharedLog()  global and  thread-safe.


Yes, `FileLogger` internally uses `lockingTextWriter`, so it 
should be safe to call from multiple threads. Furthermore, the 
`sharedLog` property uses atomic load and store instructions, so 
it should be OK to concurrently change the shared logger.

Re: Pitching D to academia

[Jay Norwood via Digitalmars-d]

On Sunday, 6 March 2016 at 07:38:01 UTC, Ali Çehreli wrote:
What are the points that you would stress? I am thinking that 
they would be interested more in whether D is better as a 
teaching tool. Do you agree?


Ali


I think the D std.parallelism library would be a nicer starting 
point than using openMP if the examples are targeted toward demo 
on smaller multi-core systems.


Also, someone posted here on an app named vlang.  That sounded 
like it could make an interesting combo with a system-C course.

Re: Pitching D to academia

[Andrew via Digitalmars-d]

Surely a language such as Java is much better for things like 
design by contract through JML? It may not be built-in such as 
D's `in` and `out` blocks, but there is tool-support for both 
runtime and static checking, and JML can also describe things 
such as class invariants.


One of awful things about programming in many languages is that 
there's a gazillion tools you need to tack-on before you can do 
any engineering.  In C++ that includes Doxygen for documentation, 
C++Unit for unit tests, gprof, gcov, valgrind, and so on.  One of 
the nice things about D is that so much of this is part of the 
language or build into DMD.


So yes, sure, you can add what ever you like the Java and claim 
its just as good (or better). The difference is that in D its all 
right there already.

Re: Suggested Change to Contract Syntax

[FatalCatharsis via Digitalmars-d]

On Thursday, 10 March 2016 at 22:57:41 UTC, Jonathan M Davis 
wrote:
I don't think that out contracts are worth much anyway, since 
in almost all cases, unit tests do that job already, and it's 
usually much easier to write test that specific input gives 
specific output than it is to have a general test at the end of 
the function.


This is a very good point. I was already using unittests and I 
guess they make 'out' contracts redundant considering that you 
are ensuring the result of a function is correct anyway.


If/Once we get more features in the compiler which take 
advantage of contracts, then I'll likely change my tune on that 
one, but for now, IMHO, they're really only of value in classes.


I'm curious, what kind of features might come out of contracts in 
the future? They seem somewhat helpful in terms of QA and 
organization, but what kind of compiler or performance gains 
could you gain from this system?


I'm going to take your advice and just stick to assertions at the 
beginning of the function and unittests to verify correctness of 
output. I'm already overjoyed with the easiness and integration 
of the unittest system as it is :) .

Re: Suggested Change to Contract Syntax

[jmh530 via Digitalmars-d]

On Thursday, 10 March 2016 at 22:57:41 UTC, Jonathan M Davis 
wrote:
IMHO, at this point, inheritance is the only reason they're 
worth

having in the language. [snip]



I created a simple example to understand your point about 
contracts only really mattering for inheritance, but my example 
is giving assertion errors for the inherited class the same way 
as the base class. What would I need to do for this issue to 
become apparent?


class A
{
int a;

this(int x)
{
a = x;
}

int foo(int x)
{
assert(x != 0);
scope(exit) assert((this.a - x) != 0);

return this.a - x;
}
}

class B : A
{
this()
{
super(4);
}

}

void main()
{
import std.stdio : writeln;

auto a = new A(2);
//writeln(a.foo(0)); //causes assertion failure
//writeln(a.foo(2)); //causes assertion failure

auto b = new B();
//writeln(b.foo(0)); //causes assertion failure
//writeln(b.foo(4)); //causes assertion failure
}

[Issue 15785] New: [DMD HEAD] Spurious warning when calling protected super

[via Digitalmars-d-bugs]

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

  Issue ID: 15785
   Summary: [DMD HEAD] Spurious warning when calling protected
super
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: regression
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: thecybersha...@gmail.com

// a.d //
class A
{
protected void f() {}
}
// b.d //
import a;

class B : A
{
override void f()
{
super.f();
}
}
/

DMD now complains:

b.d(7): Deprecation: a.A.f is not visible from module b

Of course this makes no sense - you can override a symbol but not call it?

Introduced in https://github.com/D-Programming-Language/dmd/pull/5472

--

Re: Pitching D to academia

[Thiez via Digitalmars-d]

On Thursday, 10 March 2016 at 21:54:33 UTC, Andrew wrote:
Don't forget to mention all the "software engineering" 
principles that can be taught using D too including:


Design by Contract
Literate programming (embedded documentation)

and to tool that come "standard" in the language such as

Coverage
Profiling


Surely a language such as Java is much better for things like 
design by contract through JML? It may not be built-in such as 
D's `in` and `out` blocks, but there is tool-support for both 
runtime and static checking, and JML can also describe things 
such as class invariants. That it took over two years for a bug 
such as https://issues.dlang.org/show_bug.cgi?id=7910 to get 
fixed indicates to me that nobody is really using design by 
contract in D, and makes me wonder how many more bugs are hiding 
there. Java and JML have been used in both academia and the 
industry for almost two decades (although it's not as popular as 
it could be...) so I expect most of the easy-to-encounter bugs 
have been solved by now.

Re: Suggested Change to Contract Syntax

[Jonathan M Davis via Digitalmars-d]

On Thursday, 10 March 2016 at 22:39:54 UTC, Adam D. Ruppe wrote:
Contracts are most interesting in the case of inheritance and 
keeping variables between them isn't going to be easy.


IMHO, at this point, inheritance is the only reason they're worth 
having in the language. Without inheritance, in contracts could 
just as easily be assertions at the top of the function, and 
while out contracts are certainly easier as they are now rather 
than having to put a contract at each return statement or use a 
scope(exit) statement to do the out contracts, you can still do 
out contracts that way, and honestly, I don't think that out 
contracts are worth much anyway, since in almost all cases, unit 
tests do that job already, and it's usually much easier to write 
test that specific input gives specific output than it is to have 
a general test at the end of the function.


But while in most cases, in and out contracts are trivially done 
in the function itself, inheritance is a whole other kettle of 
fish, and having them built into the language solves that problem 
whereas doing it yourself is actually fairly hard and 
error-prone. So, for that reason, and that reason alone, I think 
that having them built into the language is a good thing.


There has been some discussion of getting the compiler to catch 
some stuff based on in contracts, in which case, in contracts 
would be worth a bit more, but as it stands, I pretty much never 
use out contracts (because I think that they're useless), and if 
inheritance isn't involved (which it usually isn't), then I don't 
even bother with an in contract and just put the assertions in 
the body and avoid the extra syntax. If/Once we get more features 
in the compiler which take advantage of contracts, then I'll 
likely change my tune on that one, but for now, IMHO, they're 
really only of value in classes.


- Jonathan M Davis

[Issue 314] [module] Static, renamed, and selective imports are always public

[via Digitalmars-d-bugs]

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

--- Comment #54 from Jonathan M Davis  ---
(In reply to Leandro Lucarella from comment #53)
> Is this time for real? I think I'm gonna cry.

It is, but the new import semantics that came with fixing various import bugs
for the next release are surprising to a number of us. The number of resulting
deprecation messages in Phobos was quite large, and it's quite likely that
there's a lot of code out there that's going to at minimum get a lot of
deprecation messages and probably end up with broken code due to imports that
don't work as expected anymore. We may be better off in the long run (and
certainly, finally getting bugs like this fixed is fantastic), but I can't say
that I'm particularly enthused with the resulting semantics, and it's going to
take some getting used to.

--

Re: Suggested Change to Contract Syntax

[Adam D. Ruppe via Digitalmars-d]

On Thursday, 10 March 2016 at 22:04:24 UTC, Xinok wrote:
I'm not sure how the compilers translate the contracts into 
code, but it's definitely feasible. Code of the form:


auto foo()
in{ ... }
out(result){ ... }
body{ ... }

Could simply be rewritten as:




Not quite because contracts are inherited. For a child class, 
either the child OR the parent's in contract needs to pass, but 
both the child AND parent's out contracts need to pass.


The result is that the child in contract might run without the 
parent in... but then the parent's out will still be run.


Will it see uninitialized variables? Or partially run stuff as 
the in contract throws a swallowed exception half way through?



Contracts are most interesting in the case of inheritance and 
keeping variables between them isn't going to be easy.

Re: How to import for mixin contents only.

[Taylor Hillegeist via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 22:07:23 UTC, Andrea Fontana wrote:
On Thursday, 10 March 2016 at 17:43:08 UTC, Taylor Hillegeist 
wrote:
I suppose the linker optimized the functions away since they 
are now in their own section. But it seems a hacky way to do 
this.


AFAIK assert(0) and other falsey assert have a special meaning 
for compiler.
So probably it's not so hacky but just a way to say that case 
can't happen.


It is used also for:


auto myfunc(int i)
{

   if (i == 0) return 10;
   else if (i == 1) return 3;

   assert(0);
}

And also with non final switch using

switch(var)
{
   case ...
...
   default: assert(0);
}


I'm good with the assert(0), I'm not so happy with the linker not 
being able to create a binary without the -ffunction-sections 
option.


I think there needs to be a ctimport keyword or something. I 
should not have to deal with the imports only used during compile 
time. it is not a good thing.

Re: Is it safe to use 'is' to compare types?

[Yuxuan Shui via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 02:14:19 UTC, H. S. Teoh wrote:
On Thu, Mar 10, 2016 at 01:33:41AM +, Yuxuan Shui via 
Digitalmars-d-learn wrote:

[...]


You can't rely on invoking the compiler to link these objects, 
because if you're using shared libraries, it will be the OS's 
dynamic linker that will get invoked to resolve the references, 
and different versions of shared libraries may have a different 
set of TypeInfo's, and the compiler may not be able to generate 
the required TypeInfo's.


A better way is to use the OS linker's "weak symbol" feature, 
where a symbol is allowed to be defined multiple times (with 
identical content), and the linker (both dynamic and static) 
will choose the first definition that it finds.


However weak symbol overriding is deprecated on Linux (see 
ld.so(8)).


If we want to go all out to solve this problem, there are clearly 
solutions. But for now there doesn't seem to be enough benefit to 
justify the amount of work needed.





T

Re: How to import for mixin contents only.

[Andrea Fontana via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 17:43:08 UTC, Taylor Hillegeist 
wrote:
I suppose the linker optimized the functions away since they 
are now in their own section. But it seems a hacky way to do 
this.


AFAIK assert(0) and other falsey assert have a special meaning 
for compiler.
So probably it's not so hacky but just a way to say that case 
can't happen.


It is used also for:


auto myfunc(int i)
{

   if (i == 0) return 10;
   else if (i == 1) return 3;

   assert(0);
}

And also with non final switch using

switch(var)
{
   case ...
...
   default: assert(0);
}

Re: Suggested Change to Contract Syntax

[Xinok via Digitalmars-d]

On Thursday, 10 March 2016 at 21:07:09 UTC, FatalCatharsis wrote:
I am very new to D so I apologize if I'm very uninformed. I'm 
learning D by porting a big (awful) c++ project to D so that I 
may take advantage of all the lovely testing and QA features. I 
am currently moving a class over that I have which represents a 
2 float vector and I've run into a problem with contracts. Here 
is a short excerpt:

...


The most "elegant" solution I can think of is to move the 
contracts into the body of the function itself and wrap them in 
version(unittest) or version(assert). The pre-contract would be 
placed at the very start of the function and the post-contract 
would be wrapped in a scope(exit) or scope(success).


Regarding your proposal, I don't think it's necessary to 
introduce new syntax; a simple change in semantics would suffice. 
If we simply preserved the body of the pre-contract and made it 
accessible in the post-contract, then your example would work as 
is.


I'm not sure how the compilers translate the contracts into code, 
but it's definitely feasible. Code of the form:


auto foo()
in{ ... }
out(result){ ... }
body{ ... }

Could simply be rewritten as:

auto foo()
{
// paste pre-contract here

auto bodyOfFoo()
{
// paste body here
}

auto result = bodyOfFoo();

// paste post-contract here

return result;
}

std.demangle.demangle()

[Andrew via Digitalmars-d]

Hi,

I tried posting this to the Phobos list but it failed!

I've been writing a tool that requires me to demangle D mangled 
names.  To check it I've been running the tool on its self 
including its mangled names (that I get from the profiler).  I've 
discovered that std.demangle.demangle() cannot demangle these 
mangled names:


_Dmain

_D3std5array18__T8AppenderTAAyaZ8Appender12__T3putTAyaZ3putMFAyaZ9__lambda2MFNaNbNiNeZAAya
   
_D4hash115__T4hashTAaTS17indexing_postings56__T17indexing_postingsVE17indexing_postings9attributei7Z17indexing_postingsVii24Z4hash6__ctorMFNbNiC9allocator9allocatorZC4hash115__T4hashTAaTS17indexing_postings56__T17indexing_postingsVE17indexing_postings9attributei7Z17indexing_postingsVii24Z4hash


_D4hash115__T4hashTAaTS17indexing_postings56__T17indexing_postingsVE17indexing_postings9attributei7Z17indexing_postingsVii24Z4hash7opIndexMFNcKxAaZS17indexing_postings56__T17indexing_postingsVE17indexing_postings9attributei7Z17indexing_postings

The first one is obvious (_Dmain is not mangled).

To verify these were correctly mangled I wrote a name demangler 
based on the grammar on the D web site (that grammar appears to 
be incorrect for structs, and does not include cent and ucent).


Based on my new-found knowledge of how name mangling and 
demangling works I'm about to try and debug 
std.demangle.demangle().


If someone can tell me that this bug has been fixed it'll save me 
a day of work.  If not then I'll post a patch once (if?) I've 
found the bug.


Andrew.

Re: Pitching D to academia

[Andrew via Digitalmars-d]

Don't forget to mention all the "software engineering" principles 
that can be taught using D too including:


Design by Contract
Literate programming (embedded documentation)

and to tool that come "standard" in the language such as

Coverage
Profiling

Re: New Article: My Experience Porting Python Dateutil's Date Parser to D

[Jack Stouffer via Digitalmars-d-announce]

On Wednesday, 9 March 2016 at 22:12:42 UTC, Walter Bright wrote:
I haven't read the article yet, but you'll get more interest by 
putting a summary as the first comment on reddit.


Thanks for the advice, I think it caused more people to read it.

Also, I forgot to mention in the article that the unit tests with 
coverage reports enabled run in 110ms. I love fast tests :)

[Issue 15038] Associative Array .get property const vs immutable

[via Digitalmars-d-bugs]

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

--- Comment #3 from ZombineDev  ---
BTW, http://dlang.org/phobos/std_exception#.assumeUnique can help in the mean
time.

--

[Issue 15038] Associative Array .get property const vs immutable

[via Digitalmars-d-bugs]

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

ZombineDev  changed:

   What|Removed |Added

 CC||petar.p.ki...@gmail.com

--- Comment #2 from ZombineDev  ---
While I agree that const should be as good as immutable in this case, sometimes
it is not so clear. For example, if the key type is immutable(char[])[], should
those be accepted:
1) immutable(char)[][]  (a.k.a. string[])
2) const(char)[][]
3) const(char[])[]

--

Suggested Change to Contract Syntax

[FatalCatharsis via Digitalmars-d]

I am very new to D so I apologize if I'm very uninformed. I'm 
learning D by porting a big (awful) c++ project to D so that I 
may take advantage of all the lovely testing and QA features. I 
am currently moving a class over that I have which represents a 2 
float vector and I've run into a problem with contracts. Here is 
a short excerpt:


struct Vector2(T) {
T x = 0;
T y = 0;

Vector2!T opBinary(string op)(const ref Vector2!T rhs)
if(op == "+" || op == "-" || op == "*" || op == "/")
in {
T prevx = this.x;
T prevy = this.y;
}
out {
static if(isFloatingPoint!T) {
assert(mixin("approxEqual(this.x, 
prevx"~op~"rhs.x)"));
assert(mixin("approxEqual(this.y, 
prevy"~op~"rhs.y)"));

} else {
assert(mixin("this.x == (prevx"~op~"rhs.x)"));
assert(mixin("this.y == (prevy"~op~"rhs.y)"));
}
}
body {
Vector2!T ret;
mixin("ret.x = this.x"~op~"rhs.x;");
mixin("ret.y = this.y"~op~"rhs.y;");
return ret;
}
}

this example obviously does not compile. What I am attempting to 
do is store the initial value of the x and y before the body is 
run, so that I can use those values in the post condition. I've 
read around and asked a question on stackoverflow, and it seems 
that there is no facility for this.


I am NOT very knowledgable in compilation, but I do get the gist 
of it. I was hoping to suggest a syntax change and get some 
opinions on it. What if contracts were done like this:


struct Vector2(T) {
T x = 0;
T y = 0;

Vector2!T opBinary(string op)(const ref Vector2!T rhs)
if(op == "+" || op == "-" || op == "*" || op == "/")
contract {
T prevx;
T prevy;

in {
prevx = this.x;
prevy = this.y;
}
out {
static if(isFloatingPoint!T) {
assert(mixin("approxEqual(this.x, 
prevx"~op~"rhs.x)"));
assert(mixin("approxEqual(this.y, 
prevy"~op~"rhs.y)"));

} else {
assert(mixin("this.x == (prevx"~op~"rhs.x)"));
assert(mixin("this.y == (prevy"~op~"rhs.y)"));
}
}
}
body {
Vector2!T ret;
mixin("ret.x = this.x"~op~"rhs.x;");
mixin("ret.y = this.y"~op~"rhs.y;");
return ret;
}
}

In this example, the contract would represent a function that is 
invoked on each invocation of the function. in and out would 
enclose the values prevx and prevy. in would be invoked 
immediately after, followed by the body, and then followed by out.


Syntactically I think this is clear, but I don't know much about 
the technical implementation. Is this feasible?

Re: Potential GSoC project - GC improvements

[ZombineDev via Digitalmars-d]

On Thursday, 10 March 2016 at 18:49:28 UTC, Daniel Kozak wrote:



Dne 10.3.2016 v 19:39 ZombineDev via Digitalmars-d napsal(a):

On Thursday, 10 March 2016 at 17:46:15 UTC, Daniel Kozak wrote:



Dne 10.3.2016 v 18:15 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan 
wrote:
On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei 
Alexandrescu wrote:

On 3/9/16 10:40 PM, NX wrote:
I think the best possible improvement for GC is making it 
lock-free.
Currently, GC lock cause some serious performance 
penalties for

multithreaded code when frequent allocations take place.


I agree. A first step would be easy to do with 
std.allocator's thread-local freelists. -- Andrei


I was looking into this, but I am slightly hesitant. Should 
the gc use something in std.experimental? Or should we 
think that's ok?


I also know that there are some people that think we should 
avoid using Phobos in druntime.


There's no problem in using std.experimental.* internally, 
because if the API changes, the one who changes the API will 
also need to change all internal usages, otherwise his pull 
request won't compile.


About using Phobos in Druntime - you can't directly import 
Phobos, since it's files are not present when Druntime is 
built.
But we allready need existing D compiler to build D frontend, 
so maybe we can use this full D compiler for building 
druntime in the future?


The build process looks something like this currently:
(a bit simplified)
1. Download old dmd.
2. Build new dmd with 1.
3. Build druntime with 2.
4. Build phobos with 2 and link it with 3.
5. Package 2, 3 and 4 into a release zip

You can't use 1 for building 3 (or 4), because 3 (or 4) may 
depend on a new feature only present in 2. Also you can't rely 
on 5 for building 3 (or 4) because you'll get a cyclic 
dependency.


I know how it works now :). But if D is stable enought  1 
should be good enought to do 3 and 4 (yes you can't rely on 
features and fixes from 2). I think we should avoid to use 
latest features when developing dmd, druntime and phobos (maybe 
we should use only some subset or make some rules like new 
version must be compilable by 3 previous version of dmd)


Well for 4. maybe, but after a couple of years... Most of the 
time Phobos can't be compiled with an older version of DMD not 
because it relies on new features, but because there are bugs in 
the older version of DMD.
As for 3. - druntime is very tightly coupled with the compiler. 
Quite often changes in the compiler rely on changes in druntime - 
e.g. the new DWARF exceptions, C++ and Objective-C support, 
better code coverage and GC profiling, things in object.d, 
built-in AAs and arrays, linking with MSVC 2015 libc, shared 
libraries, TLS, etc.
On the other hand, I think that using Phobos in DMDFE is a good 
idea and is far more likely to happen.

Re: D and devkitARM

[TheGag96 via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 14:36:26 UTC, Nicholas Wilson wrote:


Hmm.

I apologise that this post is not in any logical order.

dmd can only compile for x86 so you will have to use ldc or gdc

makefiles are generally not used in d. you should be able to use
the dub project settings file (dub.json or dub.sdl) to do most 
of
the standard linking, as for some of the deeper magic I'm not 
sure.


versioning: i'm not sure that d has a 3ds target version but it 
has

an arm one. includes should not be an issue.

If you cannot find bindings for ctru see if dstep can do it for 
you.


I don't know what .v.pica or .shlist files are but you can use
string imports to reference the data looks like the same idea
can be used for the shader rule. However you may need to use a 
prehook

script to call whatever "picassso" does first.


Thanks for the suggestions. I know I need to use gdc, 
specifically the one found at 
ftp://ftp.gdcproject.org/binaries/devkitARM/ (or build it myself 
if this doesn't work for whatever reason).


I'm starting to think a bigger problem aside from the Makefiles 
is just getting any D to compile with that gdc version at all. 
I'm pretty sure I need some sort of bare metal runtime. Would 
this be something that could work, or should I look elsewhere? 
https://bitbucket.org/timosi/minlibd


...This probably really is above my knowledge level, but I 
suppose I'll never learn if I don't give it a shot. Like I said, 
if anyone has any sort of advice on how I should approach this, 
I'd be happy to hear it.

Re: New Article: My Experience Porting Python Dateutil's Date Parser to D

[Ola Fosheim Grøstad via Digitalmars-d-announce]

On Thursday, 10 March 2016 at 17:59:21 UTC, Chris Wright wrote:
It's a little easier to write iterators in the Python style: 
you don't have to cache the current value, and you don't have 
to have a separate check for end-of-iteration. It's a little 
easier to use them in the D style: you get more flexibility, 
can check for emptiness without popping an item, and can grab 
the first item several times.


I don't have any firm opinions on this, but escaping out of the 
loop with an exception means you don't have to check for 
emptiness. So I am not sure why D range-iterators should be 
considered  easier.


You can convert one to the other, so there's no theoretical 
difference in what you can accomplish with them. It's mainly 
annoying. A small efficiency concern, because throwing 
exceptions is a little slow.


Efficiency of exceptions in Python is an implementation issue, 
though. But I agree that the difference isn't all that 
interesting.


The largest practical difference comes when multiple functions 
are interested in viewing the first item in the same range. 
LL(1) parsers need to do this.


Iterators and generators in Python are mostly for for-loops and 
comprehensions. In the rare case where you want lookahead you can 
just write your own or use an adapter.


Of course, that's just looking at input ranges versus 
iterators. If you look at other types of ranges, there's a lot 
there that Python is missing.


Is there any work done on range-iterators and streams?

Re: Hotfix release vibe.d 0.7.28

[Eugene Wissner via Digitalmars-d-announce]

On Monday, 29 February 2016 at 07:54:09 UTC, Sönke Ludwig wrote:

Am 29.02.2016 um 00:47 schrieb sigod:
On Saturday, 27 February 2016 at 16:21:05 UTC, Sönke Ludwig 
wrote:

This is a small bugfix release that mainly fixes two critical
regressions:

 - FreeListRef!T, which is used heavily in the HTTP server 
code, stored
   its reference count in an unallocated memory region, 
leading to

   possible memory leaks or memory corruption

 - A TCP connection with a non-empty write buffer that got 
closed by
   the remote peer and locally at the same time could result 
in the
   calling task to starve (i.e. it got never resumed after 
yielding
   execution). In particular, this could happen when 
accessing HTTPS
   servers with the HTTP client in conjunction with 
"Connection: close".


http://vibed.org/blog/posts/vibe-release-0.7.28


You forgot to update site header.


Thanks, also forgot the documentation (even if nothing has 
changed).




Is there any plans on when big split will happen?


It will be a step-by-step process. I'm currently working on a 
new version of the `vibe.core` package that contains some large 
changes under the hood. Once that is in a functional state, 
I'll look into how to enable optional replacement of the 
existing vibe:core package by this new, separately hosted 
vibe-core package. vibe:core, at that point, will only receive 
bug fixes and continues to live for a while (let's say a year 
or one and a half).


The same procedure will then happen for vibe:http (the new 
package will include HTTP/2 support) and the other sub packages.


All of the new packages will get a version number of 1.0.0, 
once they can be considered reasonably stable.


One unfortunate aspect of my current work on vibe-core is that 
I'm building on a new event loop abstraction that I built as a 
prototype to see where the performance bottlenecks of the 
current system are. libasync was too slow and it had a too 
complicated structure to make quick tests for improving 
performance. Now I'm leaning towards finalizing the new 
prototype library and proposing it for Phobos inclusion at some 
point.


Sönke, is your current work on core available somewhere?
Since my vibe.d related work isn't stable it wouldn't a problem 
to use unstable core-component. It is better than rewriting later 
if a lot of things change.

Re: Named arguments via struct initialization in functions

[ZombineDev via Digitalmars-d]

On Monday, 7 March 2016 at 18:21:24 UTC, Meta wrote:

On Monday, 7 March 2016 at 10:40:15 UTC, ZombineDev wrote:

Which I don't think will cause ambiguity with delegates:
auto tuple3 = { getInt() }; tuple
auto tuple3 = { getInt(); }; lambda


Unfortunately this will not work. There was a tuple proposal 
sometime back in 2012 or 2013. I can't remember the exact 
reason, but somebody came up with a case where it can be 
ambiguous as to whether it's a tuple or a delegate.


Can you find the exact case? I'm really interested in getting 
proper tuple syntax support and I think that's important to cover 
all the possible cases before can agree on something and move 
towards implementing it.

Re: unit-threaded v0.6.5 - Type-parametrized tests

[Atila Neves via Digitalmars-d-announce]

On Thursday, 10 March 2016 at 16:06:38 UTC, Meta wrote:

On Wednesday, 9 March 2016 at 18:01:49 UTC, Atila Neves wrote:

The forum must be sick of hearing from me... :P


I'm always excited for a new release of unit-threaded


Thanks for the kind words!

Atila

Re: Named arguments via struct initialization in functions

[ZombineDev via Digitalmars-d]

On Monday, 7 March 2016 at 19:06:54 UTC, Chris Wright wrote:

On Mon, 07 Mar 2016 11:06:13 +, ZombineDev wrote:
The compiler should detect that this call is ambiguous and 
would not allow it.


It's a potentially significant amount of work to determine that 
the expression is ambiguous, or to disambiguate.


I don't think so. At least not much more than what currently the 
compiler does for overload resolution (comparing the void(A) 
overloard to the void(B)). Tuples literals / struct initializer 
literals / delegates should be classified before the end of the 
parsing phase (which is actually at least an order of magnitude 
faster than the semantic phase).



To resolve the ambiguity, the user can write:
foo(A{ x: 1 });


That's why I suggested it.

And you only need explicit type marking at the top level; 
it's unambiguous after that.


I'm not sure what you mean by "explicit type marking at the 
top level".


It always is unambiguous to write things like:
  auto a = A{x: {y: 1}};


Ah ok, agreed.

Re: Named arguments via struct initialization in functions

[Marc Schütz via Digitalmars-d]

On Tuesday, 8 March 2016 at 20:32:02 UTC, Idan Arye wrote:
Declaring the named arguments variadically will be done by 
adding `...` after a struct argument:


struct Options{int x; int y=1; int z=2;}
auto fun(Options options ...)

We'll need a syntax for specifying the arguments - but that's 
more of a matter of taste than an actual technical problem, and 
it's going to be bikeshedded over and over, so for the purpose 
of describing my idea let's pick a Ruby-style `:`(because `=` 
will break the rule of 
if-it-compiles-as-C-it-should-work-like-C):


fun(x: 4, z: 3);

I've promised you to solve ambiguity, right?


--snip--

I'm not sure, but I think the problem Walter has lies with 
_detecting_ ambiguity in the first place, because that would make 
overload resolution more complicated. I personally don't think 
it's that big a problem, because selecting the candidates could 
be a step before actual (= as it is now) overload resolution.

Re: Potential GSoC project - GC improvements

[Daniel Kozak via Digitalmars-d]

Dne 10.3.2016 v 19:39 ZombineDev via Digitalmars-d napsal(a):

On Thursday, 10 March 2016 at 17:46:15 UTC, Daniel Kozak wrote:



Dne 10.3.2016 v 18:15 ZombineDev via Digitalmars-d napsal(a):

On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan wrote:

On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei Alexandrescu wrote:

On 3/9/16 10:40 PM, NX wrote:

I think the best possible improvement for GC is making it lock-free.
Currently, GC lock cause some serious performance penalties for
multithreaded code when frequent allocations take place.


I agree. A first step would be easy to do with std.allocator's 
thread-local freelists. -- Andrei


I was looking into this, but I am slightly hesitant. Should the gc 
use something in std.experimental? Or should we think that's ok?


I also know that there are some people that think we should avoid 
using Phobos in druntime.


There's no problem in using std.experimental.* internally, because 
if the API changes, the one who changes the API will also need to 
change all internal usages, otherwise his pull request won't compile.


About using Phobos in Druntime - you can't directly import Phobos, 
since it's files are not present when Druntime is built.
But we allready need existing D compiler to build D frontend, so 
maybe we can use this full D compiler for building druntime in the 
future?


The build process looks something like this currently:
(a bit simplified)
1. Download old dmd.
2. Build new dmd with 1.
3. Build druntime with 2.
4. Build phobos with 2 and link it with 3.
5. Package 2, 3 and 4 into a release zip

You can't use 1 for building 3 (or 4), because 3 (or 4) may depend on 
a new feature only present in 2. Also you can't rely on 5 for building 
3 (or 4) because you'll get a cyclic dependency.


I know how it works now :). But if D is stable enought  1 should be good 
enought to do 3 and 4 (yes you can't rely on features and fixes from 2). 
I think we should avoid to use latest features when developing dmd, 
druntime and phobos (maybe we should use only some subset or make some 
rules like new version must be compilable by 3 previous version of dmd)

Re: Potential GSoC project - GC improvements

[ZombineDev via Digitalmars-d]

On Thursday, 10 March 2016 at 17:46:15 UTC, Daniel Kozak wrote:



Dne 10.3.2016 v 18:15 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan 
wrote:
On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei 
Alexandrescu wrote:

On 3/9/16 10:40 PM, NX wrote:
I think the best possible improvement for GC is making it 
lock-free.
Currently, GC lock cause some serious performance penalties 
for

multithreaded code when frequent allocations take place.


I agree. A first step would be easy to do with 
std.allocator's thread-local freelists. -- Andrei


I was looking into this, but I am slightly hesitant. Should 
the gc use something in std.experimental? Or should we think 
that's ok?


I also know that there are some people that think we should 
avoid using Phobos in druntime.


There's no problem in using std.experimental.* internally, 
because if the API changes, the one who changes the API will 
also need to change all internal usages, otherwise his pull 
request won't compile.


About using Phobos in Druntime - you can't directly import 
Phobos, since it's files are not present when Druntime is 
built.
But we allready need existing D compiler to build D frontend, 
so maybe we can use this full D compiler for building druntime 
in the future?


The build process looks something like this currently:
(a bit simplified)
1. Download old dmd.
2. Build new dmd with 1.
3. Build druntime with 2.
4. Build phobos with 2 and link it with 3.
5. Package 2, 3 and 4 into a release zip

You can't use 1 for building 3 (or 4), because 3 (or 4) may 
depend on a new feature only present in 2. Also you can't rely on 
5 for building 3 (or 4) because you'll get a cyclic dependency.

Re: Event Dispatcher

[Eugene Wissner via Digitalmars-d-announce]

On Thursday, 10 March 2016 at 18:15:21 UTC, Adam D. Ruppe wrote:
On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner 
wrote:



I haven't used vibe.d myself but I did write CGI and SCGI (and 
fastcgi with the help of a C lib, and an embedded http server) 
in my cgi.d file:


https://github.com/adamdruppe/arsd/blob/master/cgi.d

some dox:
http://dpldocs.info/experimental-docs/arsd.cgi.html


It is written in a traditional manner - no vibe, no fibers, no 
async. This makes a lot of things easier but it isn't as sexy.


Yes, I'm aware of your code, Adam. I'm using it for reference and 
looking if I don't how to implement something better. Thank you 
for this work!

Re: std.database

[Erik Smith via Digitalmars-d]

I've made a few updates based on some of the feedback in this 
thread.


- execute() renamed to query()
- query with input binds directly from connection
- query() returns result for chaining

The design is still early stage.  I've got a growing list of 
design options which I'll bring into discussion once the 
interface becomes more stable.


Other updates:

- postgres reference implementation added (synchronous only at 
moment)

- DUB package now available as dstddb
- DMD "cyclic structs" bug fix may land soon (PR appeared) with 
design improvements to follow.


erik

Re: Event Dispatcher

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

On Thursday, 10 March 2016 at 18:08:15 UTC, Eugene Wissner wrote:
In the last week I looked a lot into the vibe.d and I moved to 
its core for handling the requests instead of my own 
CGI-handling. I'm currently working on implementing SCGI based 
on vibe.d IO



I haven't used vibe.d myself but I did write CGI and SCGI (and 
fastcgi with the help of a C lib, and an embedded http server) in 
my cgi.d file:


https://github.com/adamdruppe/arsd/blob/master/cgi.d

some dox:
http://dpldocs.info/experimental-docs/arsd.cgi.html


It is written in a traditional manner - no vibe, no fibers, no 
async. This makes a lot of things easier but it isn't as sexy.

Event Dispatcher

[Eugene Wissner via Digitalmars-d-announce]

Hey,

I wrote some time ago I'm working on the rewriting some parts of 
Symfony web framework from PHP to D. One component is pretty 
small and is already ready. It is an Event Dispatcher:
https://github.com/caraus-ecms/caraus (submodule 
caraus:eventdispatcher).


Event dispatchers make it possible to write extensible 
applications. You can register events in different places of your 
application and attach callbacks to them. It is similar to 
signals, but you have a central instance aware of all events and 
callbacks (Mediator pattern: 
https://en.wikipedia.org/wiki/Mediator_pattern).


It isn't very useful on its own, since the event dispatcher 
should be passed everywhere but it can be used, for example,  
with a DI container like poodinis. Since frameworks like 
https://github.com/Skadi-d/Skadi.d had "Event Dispatcher" in its 
TODO, I decided to write this Announce if something finds it 
useful.


In the following lines I will only describe how it works and what 
is for. You can find the example I describe here: 
https://github.com/caraus-ecms/caraus/blob/master/examples/eventdispatcher/source/app.d


We want to extend a hello world program:


import std.stdio;

class HelloWorld
{
void hello()
{
writeln("Hello world!");
}
}

void main()
{
auto helloWorld = new HelloWorld;
helloWorld.hello();
}


We want that people can attach their own messages before "Hello 
world!" or after it. We initialize the EventDispatcher in the 
class using it:

dispatcher = new EventDispatcher;

and then attach events like this: 
dispatcher.dispatch("postHello");


The last step is to register callbacks to this event:
dispatcher.addListener("postHello", delegate(Event e, string 
eventName, EventDispatcher dispatcher) {

writeln("Bye!");
});


Everything together:

import caraus.eventdispatcher.dispatcher;
import caraus.eventdispatcher.event;
import std.functional;
import std.stdio;

class HelloWorld
{
EventDispatcher dispatcher;

this()
{
dispatcher = new EventDispatcher;
}

void hello()
{
writeln("Hello world!");
dispatcher.dispatch("postHello");
}
}

void main()
{
auto helloWorld = new HelloWorld;

	helloWorld.dispatcher.addListener("postHello", delegate(Event e, 
string eventName, EventDispatcher dispatcher) {

writeln("Bye!");
});

helloWorld.hello();
}


Now you should get:
Hello world!
Bye!


Why not just extend the HelloWorld class and override the 
hello()? Imagine you write an apllication that should support 
plugins. And two independent plugins extend the HelloWorld. One 
plugin would conflict with the another. EventDispatcher make it 
possible to register the events that can be used by application 
plugins.


Note: If someone wonder about the whole web framework I 
mentioned. In the last week I looked a lot into the vibe.d and I 
moved to its core for handling the requests instead of my own 
CGI-handling. I'm currently working on implementing SCGI based on 
vibe.d IO. And I already have a simple web page of a customer 
running on it (ok, it is a single page website, but it is already 
something :))


Enjoy. Or like people say on this forum: Destroy.

Re: Trying to build a Scheme interpreter in D

[John via Digitalmars-d-learn]

On Wednesday, 9 March 2016 at 20:30:44 UTC, Guillaume Piolat 
wrote:

On Tuesday, 8 March 2016 at 18:11:24 UTC, John wrote:




You can go with Algebraic. I used to do that in scheme-d. Then 
I switched to a tagged union by hand to avoid a compiler 
regression. Algebraic was OK.



2x speed difference between DMD and LDC is common.


You can build with -g and use Instruments.


Thank you for your advice.

Re: New Article: My Experience Porting Python Dateutil's Date Parser to D

[Chris Wright via Digitalmars-d-announce]

On Thu, 10 Mar 2016 08:22:58 +, Ola Fosheim Grøstad wrote:

> On Thursday, 10 March 2016 at 00:29:46 UTC, Jack Stouffer wrote:
>>> It's a pretty straight forward standard iterator design and quite
>>> different from the table pointers C++ uses.
>>
>> I explain my grievances in the article.
> 
> They didn't make all that much sense to me, so I wondered what Theo's
> issues were. As in: real issues that have empirical significance.

It's a little easier to write iterators in the Python style: you don't 
have to cache the current value, and you don't have to have a separate 
check for end-of-iteration. It's a little easier to use them in the D 
style: you get more flexibility, can check for emptiness without popping 
an item, and can grab the first item several times.

You can convert one to the other, so there's no theoretical difference in 
what you can accomplish with them. It's mainly annoying. A small 
efficiency concern, because throwing exceptions is a little slow.

The largest practical difference comes when multiple functions are 
interested in viewing the first item in the same range. LL(1) parsers 
need to do this.

Of course, that's just looking at input ranges versus iterators. If you 
look at other types of ranges, there's a lot there that Python is missing.

Re: Potential GSoC project - GC improvements

[Daniel Kozak via Digitalmars-d]

Dne 10.3.2016 v 18:15 ZombineDev via Digitalmars-d napsal(a):

On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan wrote:

On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei Alexandrescu wrote:

On 3/9/16 10:40 PM, NX wrote:

I think the best possible improvement for GC is making it lock-free.
Currently, GC lock cause some serious performance penalties for
multithreaded code when frequent allocations take place.


I agree. A first step would be easy to do with std.allocator's 
thread-local freelists. -- Andrei


I was looking into this, but I am slightly hesitant. Should the gc 
use something in std.experimental? Or should we think that's ok?


I also know that there are some people that think we should avoid 
using Phobos in druntime.


There's no problem in using std.experimental.* internally, because if 
the API changes, the one who changes the API will also need to change 
all internal usages, otherwise his pull request won't compile.


About using Phobos in Druntime - you can't directly import Phobos, 
since it's files are not present when Druntime is built.
But we allready need existing D compiler to build D frontend, so maybe 
we can use this full D compiler for building druntime in the future?

Re: How to import for mixin contents only.

[Taylor Hillegeist via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 17:24:51 UTC, Taylor Hillegeist 
wrote:
On Thursday, 10 March 2016 at 17:22:58 UTC, Taylor Hillegeist 
wrote:
On Thursday, 10 March 2016 at 17:05:26 UTC, Taylor Hillegeist 
wrote:
On Thursday, 10 March 2016 at 16:51:32 UTC, Andrea Fontana 
wrote:
On Thursday, 10 March 2016 at 16:20:42 UTC, Taylor 
Hillegeist wrote:

[...]


I wonder if compiler is smart enaugh to undestand that 
dependency is not needed at runtime in this case:


http://dpaste.dzfl.pl/fd3bc2a839a3


well the latest gdc isnt smart enough.


So interestingly this will work if i add -ffunction-sections  
to my compiler options? no idea why?


However my binary goes from 4kb with static text to 11kb with 
the above change.


I suppose the linker optimized the functions away since they are 
now in their own section. But it seems a hacky way to do this.

Re: How to import for mixin contents only.

[Taylor Hillegeist via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 17:22:58 UTC, Taylor Hillegeist 
wrote:
On Thursday, 10 March 2016 at 17:05:26 UTC, Taylor Hillegeist 
wrote:
On Thursday, 10 March 2016 at 16:51:32 UTC, Andrea Fontana 
wrote:
On Thursday, 10 March 2016 at 16:20:42 UTC, Taylor Hillegeist 
wrote:

[...]


I wonder if compiler is smart enaugh to undestand that 
dependency is not needed at runtime in this case:


http://dpaste.dzfl.pl/fd3bc2a839a3


well the latest gdc isnt smart enough.


So interestingly this will work if i add -ffunction-sections  
to my compiler options? no idea why?


However my binary goes from 4kb with static text to 11kb with the 
above change.

Re: How to import for mixin contents only.

[Taylor Hillegeist via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 17:05:26 UTC, Taylor Hillegeist 
wrote:
On Thursday, 10 March 2016 at 16:51:32 UTC, Andrea Fontana 
wrote:
On Thursday, 10 March 2016 at 16:20:42 UTC, Taylor Hillegeist 
wrote:

[...]


I wonder if compiler is smart enaugh to undestand that 
dependency is not needed at runtime in this case:


http://dpaste.dzfl.pl/fd3bc2a839a3


well the latest gdc isnt smart enough.


So interestingly this will work if i add -ffunction-sections  to 
my compiler options? no idea why?

[Issue 314] [module] Static, renamed, and selective imports are always public

[via Digitalmars-d-bugs]

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

--- Comment #53 from Leandro Lucarella  ---
Is this time for real? I think I'm gonna cry.

--

Re: Potential GSoC project - GC improvements

[ZombineDev via Digitalmars-d]

On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan wrote:
On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei Alexandrescu 
wrote:

On 3/9/16 10:40 PM, NX wrote:
I think the best possible improvement for GC is making it 
lock-free.
Currently, GC lock cause some serious performance penalties 
for

multithreaded code when frequent allocations take place.


I agree. A first step would be easy to do with std.allocator's 
thread-local freelists. -- Andrei


I was looking into this, but I am slightly hesitant. Should the 
gc use something in std.experimental? Or should we think that's 
ok?


I also know that there are some people that think we should 
avoid using Phobos in druntime.


There's no problem in using std.experimental.* internally, 
because if the API changes, the one who changes the API will also 
need to change all internal usages, otherwise his pull request 
won't compile.


About using Phobos in Druntime - you can't directly import 
Phobos, since it's files are not present when Druntime is built. 
The solution is to copy the stuff you need to 
https://github.com/D-Programming-Language/druntime/tree/master/src/rt/util or some place like this.

Re: How to import for mixin contents only.

[Taylor Hillegeist via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 16:51:32 UTC, Andrea Fontana wrote:
On Thursday, 10 March 2016 at 16:20:42 UTC, Taylor Hillegeist 
wrote:

I feel like this should do what i want it too. but it doesn't.

struct Color_t {
static if(1==1){
import std.bitmanip:bitfields;
immutable string item = bitfields!( 
uint, "R",8,
uint, "G",   8,
uint, "B",8,
uint, "A", 8);
}
mixin(item);
}


I wonder if compiler is smart enaugh to undestand that 
dependency is not needed at runtime in this case:


http://dpaste.dzfl.pl/fd3bc2a839a3


well the latest gdc isnt smart enough.

immutable(string) BF(){
if(!__ctfe)
assert(0);
import std.bitmanip:bitfields;
return bitfields!(  
uint, "R", 8,
uint, "G", 8,
uint, "B", 8,
uint, "A", 8);
}

struct Color_t {
mixin(BF());
}

is a fair try as well. but neither work.

[Issue 15654] SysTime.toISOString formats the time zones incorrectly

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/phobos/commit/7ded5fcf686c988c4d26869ac0e16a1fd0e5a446
Rename SimpleTimeZone.to/fromISOString to to/fromISOExtString.

This is per issue# 15654.

https://github.com/D-Programming-Language/phobos/commit/2567a2493a168343be6be3050cd4bef90b320f58
Fix issue# 15654: SysTime.toISOString formats time zones incorrectly.

Previously, it formatted the time zone the same as toISOExtString and
put a colon between the hours and minutes - which is correct for the ISO
extended format, but not the non-extended format. Now, it formats it
correctly per the ISO 9601 standard.

fromISOString temporarily accepts both the extended and non-extended
formats to avoid breaking any programs that have been writing out ISO
strings to read back in later, but eventually, we'll make it so that it
only accepts the non-extended format like it's supposed to.

--

[Issue 15654] SysTime.toISOString formats the time zones incorrectly

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 15655] SysTime.from*String incorrectly accept single digit time zones and minutes > 59

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/phobos/commit/0faa191fc80dc3d0e67de5f5e83bd805c2eab794
Fix issue# 15655.

SysTime.from*String accepted single digit time zones and minutes > 59,
which is against the ISO standard. This commit fixes that.

--

Re: How to import for mixin contents only.

[Andrea Fontana via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 16:20:42 UTC, Taylor Hillegeist 
wrote:

I feel like this should do what i want it too. but it doesn't.

struct Color_t {
static if(1==1){
import std.bitmanip:bitfields;
immutable string item = bitfields!( 
uint, "R",8,
uint, "G",   8,
uint, "B",8,
uint, "A", 8);
}
mixin(item);
}


I wonder if compiler is smart enaugh to undestand that dependency 
is not needed at runtime in this case:


http://dpaste.dzfl.pl/fd3bc2a839a3

[Issue 15733] [REG2.066] Forward reference issue involving inheritance

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull, rejects-valid

--- Comment #3 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5516

--

Re: Potential GSoC project - GC improvements

[Jeremy DeHaan via Digitalmars-d]

On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei Alexandrescu 
wrote:

On 3/9/16 10:40 PM, NX wrote:
I think the best possible improvement for GC is making it 
lock-free.

Currently, GC lock cause some serious performance penalties for
multithreaded code when frequent allocations take place.


I agree. A first step would be easy to do with std.allocator's 
thread-local freelists. -- Andrei


I was looking into this, but I am slightly hesitant. Should the 
gc use something in std.experimental? Or should we think that's 
ok?


I also know that there are some people that think we should avoid 
using Phobos in druntime.

Re: How to import for mixin contents only.

[Taylor Hillegeist via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 04:56:52 UTC, Mike Parker wrote:
On Thursday, 10 March 2016 at 04:07:54 UTC, Taylor Hillegeist 
wrote:
So i want bitfields for just a little bit. but i dont want its 
dependencies. How is it done. I have tried this. but it doesnt 
seem to work on gdc. :(


struct Color_t {
static if(__ctfe){
import std.bitmanip:bitfields;
}
mixin(bitfields!(
uint, "R",8,
uint, "G",   8,
uint, "B",8,
uint, "A", 8));
}


__ctfe is a runtime construct, not compile-time. It cannot be 
used with static if. More over, it's only available *inside* a 
function that is currently being executed in a compile-time 
context. It has no role outside of that.


What problem are you trying to solve here? I mean, what is the 
problem with whatever dependencies std.bitmanip:bitfields has 
that makes you only want to import it during compilation?


I feel like this should do what i want it too. but it doesn't.

struct Color_t {
static if(1==1){
import std.bitmanip:bitfields;
immutable string item = bitfields!( 
uint, "R",8,
uint, "G",   8,
uint, "B",8,
uint, "A", 8);
}
mixin(item);
}

[Issue 15733] [REG2.066] Forward reference issue involving inheritance

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

Summary|Forward reference issue |[REG2.066] Forward
   |involving inheritance   |reference issue involving
   ||inheritance

--- Comment #2 from Kenji Hara  ---
Regression has been introduced in 2.066.

--

Re: unit-threaded v0.6.5 - Type-parametrized tests

[Meta via Digitalmars-d-announce]

On Wednesday, 9 March 2016 at 18:01:49 UTC, Atila Neves wrote:

The forum must be sick of hearing from me... :P


I'm always excited for a new release of unit-threaded

Re: Use of GUID constants

[Mike Parker via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 14:52:16 UTC, KlausO wrote:
For GUIDs you often have to take the address (e.g. for calls to 
QueryInterface), so I think phobos does not correctly implement 
this.


Yes, that was my meaning.


Is the above pair (const GUID and static member) the right way 
to declare this idiom or would the following be better ?
Both compile and seem to be equivalent (in terms of achieving 
the same goal):


enum IID IID_IServiceProvider = { 0x6d5140c1, 0x7436, 0x11ce, [ 
0x80, 0x34, 0x00, 0xaa, 0x00, 0x60, 0x09, 0xfa ] };


interface IServiceProvider : IUnknown
{
static immutable GUID iid = IID_IServiceProvider;
public:
/* [local] */ HRESULT QueryService(
/* [in] */ in GUID* guidService,
/* [in] */ in IID* riid,
/* [out] */ void **ppvObject);
}



Personally I would just declare one immutable value in module 
scope and be done with it. It really just doesn't matter. Unless 
you're following some sort of style guide, personal preference 
rules the day. I don't know if Rainers has a special reason for 
what he did with the Visual D code or if it was personal 
preference.


As for Phobos, the Win32 API in Phobos as it stands now was a 
recent addition. Though it existed as a third-party package for 
several years, it may still have some kinks to work out and may 
not follow the Phobos style guide in some places.

Re: My whereabouts

[Jack Stouffer via Digitalmars-d]

On Thursday, 10 March 2016 at 15:25:54 UTC, Andrei Alexandrescu 
wrote:
It's done and with a nice accompanying article too, I just need 
to allocate the time to push it into Phobos. -- Andrei


You could just push it to dub in the meantime so people can play 
with it.

Re: code-debug 0.6.0 released (GDB & LLDB for vscode)

[WebFreak001 via Digitalmars-d-announce]

On Tuesday, 8 March 2016 at 00:23:55 UTC, Manu wrote:
I've tried out code-d, but it only seems to do anything useful 
with dub.
None of my projects use dub. Every project I have combines 
C/C++/D,

and dub is an insufficient build system.
I can configure vscode projects to invoke my builds, but code-d
doesn't have any project metadata to work with in that context.
Can you work code-d to get its necessary working state from 
explicit

variables in the vscode project file?


If you use some other common build system you can include it into 
workspace-d as alternative backend and code-d will be able to use 
it by just changing a few lines


Otherwise just do what the others said and add 
pre/postLaunchScripts


Might aswell add a custom format just for the IDE containing just 
the file informations or implement visualD, monoD and all those 
other IDE formats

Re: Argon: an alternative parser for command-line arguments

[karabuta via Digitalmars-d-announce]

On Wednesday, 9 March 2016 at 18:56:10 UTC, Markus Laker wrote:

On Saturday, 5 March 2016 at 16:28:25 UTC, karabuta wrote:
I think he meant: [git status --help], where you have three 
attributes with the last one being the flag. So in addition 
to: [status --help] by default, you also have: [git status 
--help] to get help on status only.




Argon doesn't directly support subcommands.  That probably 
stems from a bias of mine: that subcommands make it harder for 
the author to parse the command and to generate good error 
messages, and also that they make it harder for users to use 
unfamiliar commands, because users must read a man page that 
documents eleven things they have no interest in doing just to 
get to the one thing that they need to do in order to get on 
with their day.
 At work, where I have written and I still maintain many 
hundreds of commands, I've moved away from subcommands 
completely: every operation gets a command of its own.  But I 
know that not everyone agrees with me, and that's OK.  If we 
want to debate this topic further, we should probably move the 
discussion from Announce to General.



..
It shouldn't be hard to write some reusable code to do this, if 
it were a common requirement.


I don't like subcommands myself. That's why Linux is such as mess 
with so much inconsistencies.

Re: My whereabouts

[Andrei Alexandrescu via Digitalmars-d]

On 3/9/16 7:40 PM, Jack Stouffer wrote:

On Wednesday, 9 March 2016 at 12:58:24 UTC, Andrei Alexandrescu wrote:

Folks, I've been a tad scarce in the past month or so. This is because
I've been working on a paper submission, which turned out to be a
major and extremely captivating effort. Can't share yet - double blind
review system. That in addition to getting DConf on the runway etc.

I'll be traveling a bit next and meet with Walter. The DConf committee
(Walter, Ali, Dicebot, and myself) will review all submissions and put
together the conference program.

Next on my coding agenda is rcstring.


Andrei


What ever happened to that Big O library you were writing?


It's done and with a nice accompanying article too, I just need to 
allocate the time to push it into Phobos. -- Andrei

Re: Potential GSoC project - GC improvements

[Andrei Alexandrescu via Digitalmars-d]

On 3/9/16 10:40 PM, NX wrote:

I think the best possible improvement for GC is making it lock-free.
Currently, GC lock cause some serious performance penalties for
multithreaded code when frequent allocations take place.


I agree. A first step would be easy to do with std.allocator's 
thread-local freelists. -- Andrei

[Issue 15744] [REG2.067] (SIGABRT) Error: overloadset t.Bar.__ctor is aliased to a function

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #5 from Kenji Hara  ---
https://github.com/D-Programming-Language/dmd/pull/5515

--

Re: Classes and CTFE

[Andrea Fontana via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 14:36:18 UTC, Adam D. Ruppe wrote:
On Thursday, 10 March 2016 at 13:56:18 UTC, Andrea Fontana 
wrote:

I used to think that classes can't be used with CTFE.


Classes have worked normally with CTFE for several years now. 
You don't need to do anything special with them.



Ex: http://dpaste.dzfl.pl/5879511dff02


This just doesn't do what you think it does:

if (__ctfe) pragma(msg, "compile-time");

That will ALWAYS print the thing because if(__ctfe) is a *run 
time* branch, and pragma(msg) is a compile time thing. The code 
gets compiled, even if __ctfe == false, so it will print anyway.


Yes but in one case it will print only that message, if instanced 
at runtime it will print the other too. I was just verifing if 
ctor was called correctly (in a more complex code)




enum forceCTFE(alias expr)=expr;


That's only one way to do CTFE.


I just wanted to be sure it is ctfe.


Notice the error message:

variable p.forceCTFE!(willnot).forceCTFE : Unable to initialize 
enum with class or pointer to struct. Use static const variable 
instead.




enums don't work in references, so you do a static variable 
instead. Static variables are still CTFE'd.


So problem is actually enum, not ctfe. Nice. Thank you :)

Re: Use of GUID constants

[KlausO via Digitalmars-d-learn]

For GUIDs you often have to take the address (e.g. for calls to 
QueryInterface), so I think phobos does not correctly implement this.


In the meantime I took a look at the VisualD project which accesses the 
COM interfaces of visual studio. They solve the problem by using the 
following idiom (see 
https://github.com/D-Programming-Language/visuald/blob/master/sdk/port/servprov.d 
for an example):


const GUID IID_IServiceProvider = IServiceProvider.iid;

interface IServiceProvider : IUnknown
{
	static const GUID iid = { 0x6d5140c1, 0x7436, 0x11ce, [ 0x80, 0x34, 
0x00, 0xaa, 0x00, 0x60, 0x09, 0xfa ] };

public:
/* [local] */ HRESULT QueryService(
/* [in] */ in GUID* guidService,
/* [in] */ in IID* riid,
/* [out] */ void **ppvObject);
}

If every interface declaration contains the static iid member this 
enables you to provide something similar to the the __uuidof operator in 
VisualC (see https://msdn.microsoft.com/de-de/library/zaah6a61.aspx).


In VisualD something along that line is implemented in the qi_cast 
template (see 
https://github.com/D-Programming-Language/visuald/blob/master/stdext/com.d).



Is the above pair (const GUID and static member) the right way to 
declare this idiom or would the following be better ?
Both compile and seem to be equivalent (in terms of achieving the same 
goal):


enum IID IID_IServiceProvider = { 0x6d5140c1, 0x7436, 0x11ce, [ 0x80, 
0x34, 0x00, 0xaa, 0x00, 0x60, 0x09, 0xfa ] };


interface IServiceProvider : IUnknown
{
static immutable GUID iid = IID_IServiceProvider;
public:
/* [local] */ HRESULT QueryService(
/* [in] */ in GUID* guidService,
/* [in] */ in IID* riid,
/* [out] */ void **ppvObject);
}

Thanks for your insights

-- KlausO


Am 10.03.2016 um 14:49 schrieb Mike Parker:

On Thursday, 10 March 2016 at 10:16:30 UTC, KlausO wrote:

Ok, but what's the intention behind defining GUIDs as enums in the
first place ?


Probably just an implementation error, i.e. someone not fully
appreciating how GUIDs are intended to be used.


Is there a recommended way to declare/define constants (e.g. as enums
or consts) ?


Generally, you should use a manifest constant, e.g.

enum myConst = 10;

Unless you need to take the address, then you should use immutable:

immutable myConst = 10;

The value of a manifest constant is substituted for the symbol at the
point of use and is not stored in the data segment (so has no memory
address), but an immutable (or const) variable is stored in the data
segment.

[Issue 15744] [REG2.067] (SIGABRT) Error: overloadset t.Bar.__ctor is aliased to a function

[via Digitalmars-d-bugs]

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

--- Comment #4 from Kenji Hara  ---
I think the test case should be accepted properly. For the rejects-valid bug, I
opened issue 15784.

--

[Issue 15744] [REG2.067] (SIGABRT) Error: overloadset t.Bar.__ctor is aliased to a function

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

 Blocks||15784

--

[Issue 15784] Overload set constructor call should be supported from inside a constructor

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

 Depends on||15744

--

[Issue 15784] New: Overload set constructor call should be supported from inside a constructor

[via Digitalmars-d-bugs]

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

  Issue ID: 15784
   Summary: Overload set constructor call should be supported from
inside a constructor
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: k.hara...@gmail.com

>From issue 15744 test case:

template AddField(T) {
T b;
this(Args...)(T b, auto ref Args args)
{
   this.b = b;
   //this(args);// not OK (segfaults, issue 15744)
}
}

template construcotrs() {
int a;
this(int a) {
this.a = a;
}
}

struct Bar {

mixin construcotrs;
mixin AddField!(string);
}

void main() {
auto bar1 = Bar(5);  // OK
auto bar2 = Bar("bar", 15);  // also OK
}

In main, outside of construction functions, the Bar's overload set constructor
(declared in AddField and constructors mixin template) called is accepted.
But from inside the constructor AddField.this(Args...)(T b, auto ref Args
args), a constructor call this(args); cannot work.

it's merely inconsistent behavior, and should be treated as a rejects-valid
bug.

--

Re: Classes and CTFE

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

On Thursday, 10 March 2016 at 13:56:18 UTC, Andrea Fontana wrote:

I used to think that classes can't be used with CTFE.


Classes have worked normally with CTFE for several years now. You 
don't need to do anything special with them.



Ex: http://dpaste.dzfl.pl/5879511dff02


This just doesn't do what you think it does:

if (__ctfe) pragma(msg, "compile-time");

That will ALWAYS print the thing because if(__ctfe) is a *run 
time* branch, and pragma(msg) is a compile time thing. The code 
gets compiled, even if __ctfe == false, so it will print anyway.


enum forceCTFE(alias expr)=expr;


That's only one way to do CTFE. Notice the error message:

variable p.forceCTFE!(willnot).forceCTFE : Unable to initialize 
enum with class or pointer to struct. Use static const variable 
instead.




enums don't work in references, so you do a static variable 
instead. Static variables are still CTFE'd.

Re: D and devkitARM

[Nicholas Wilson via Digitalmars-d-learn]

On Wednesday, 9 March 2016 at 00:34:44 UTC, TheGag96 wrote:
Hi guys, for a possibly-in-over-my-head project I'd like to get 
working a simple "Hello World" type program in which I call a D 
function from C in a 3DS homebrew app (or maybe even have it 
all in plain D with bindings to libctru). The thing is, I'm not 
skilled with Makefiles so I don't have a clue on how to 
correctly set up the toolchain for linking everything. I can 
compile some D-calling C code just fine with dmd and gcc on 
Linux (though I can't get anything working with gdc for 
whatever reason). Would anyone be able to point me in the right 
direction?


This is the example Makefile for a 3DS homebrew app: 
http://pastebin.com/fcJrrMg9 It seems like there would be 
issues differentiating the .d build definition files from D 
source files...


Thanks!


Hmm.

I apologise that this post is not in any logical order.

dmd can only compile for x86 so you will have to use ldc or gdc

makefiles are generally not used in d. you should be able to use
the dub project settings file (dub.json or dub.sdl) to do most of
the standard linking, as for some of the deeper magic I'm not 
sure.


versioning: i'm not sure that d has a 3ds target version but it 
has

an arm one. includes should not be an issue.

If you cannot find bindings for ctru see if dstep can do it for 
you.


I don't know what .v.pica or .shlist files are but you can use
string imports to reference the data looks like the same idea
can be used for the shader rule. However you may need to use a 
prehook

script to call whatever "picassso" does first.

[Issue 15744] [REG2.067] (SIGABRT) Error: overloadset t.Bar.__ctor is aliased to a function

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

Summary|(SIGABRT) Error:|[REG2.067] (SIGABRT) Error:
   |overloadset t.Bar.__ctor is |overloadset t.Bar.__ctor is
   |aliased to a function   |aliased to a function

--

[Issue 15744] (SIGABRT) Error: overloadset t.Bar.__ctor is aliased to a function

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

   Keywords||ice
   Hardware|x86_64  |All
 OS|Linux   |All

--- Comment #3 from Kenji Hara  ---
Introduced in:
https://github.com/D-Programming-Language/dmd/pull/4309

--

[Issue 15744] (SIGABRT) Error: overloadset t.Bar.__ctor is aliased to a function

[via Digitalmars-d-bugs]

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

Temtaime  changed:

   What|Removed |Added

   Severity|normal  |regression

--- Comment #2 from Temtaime  ---
I'm sorry bugzilla redirects in a strange way
Restored status to regression

--

[Issue 15778] [REG2.064] polysemous string type doesn't work in array operation

[via Digitalmars-d-bugs]

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

Temtaime  changed:

   What|Removed |Added

   Severity|normal  |regression

--- Comment #6 from Temtaime  ---
I'm sorry bugzilla redirects in a strange way
Restored status to regression

--

[Issue 15734] Need this for map

[via Digitalmars-d-bugs]

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

Temtaime  changed:

   What|Removed |Added

   Severity|regression  |normal

--

[Issue 15778] [REG2.064] polysemous string type doesn't work in array operation

[via Digitalmars-d-bugs]

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

Temtaime  changed:

   What|Removed |Added

 CC||temta...@gmail.com
   Severity|regression  |normal

--

[Issue 15734] Need this for map

[via Digitalmars-d-bugs]

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

--- Comment #2 from Temtaime  ---
Hmmm, i though it was combpilable some time ago
OK, not a regression then

--

[Issue 15744] (SIGABRT) Error: overloadset t.Bar.__ctor is aliased to a function

[via Digitalmars-d-bugs]

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

Temtaime  changed:

   What|Removed |Added

 CC||temta...@gmail.com
   Severity|regression  |normal

--

[Issue 15777] Premature expansion of overload set in tuples

[via Digitalmars-d-bugs]

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

--- Comment #1 from Vladimir Panteleev  ---
Discussion:

https://github.com/D-Programming-Language/phobos/pull/3969#issuecomment-183743021

--

Classes and CTFE

[Andrea Fontana via Digitalmars-d-learn]

I used to think that classes can't be used with CTFE.

Instead it appears to work, if they're not directly returned but, 
for example, they're wrapped inside a struct as on example [1]. 
Ctor is called *only* at compile time, and instance works fine.


So, I can't understand: why wrapping a class inside a struct make 
it works?



Ex: http://dpaste.dzfl.pl/5879511dff02

Re: Use of GUID constants

[Mike Parker via Digitalmars-d-learn]

On Thursday, 10 March 2016 at 10:16:30 UTC, KlausO wrote:
Ok, but what's the intention behind defining GUIDs as enums in 
the first place ?


Probably just an implementation error, i.e. someone not fully 
appreciating how GUIDs are intended to be used.


Is there a recommended way to declare/define constants (e.g. as 
enums or consts) ?


Generally, you should use a manifest constant, e.g.

enum myConst = 10;

Unless you need to take the address, then you should use 
immutable:


immutable myConst = 10;

The value of a manifest constant is substituted for the symbol at 
the point of use and is not stored in the data segment (so has no 
memory address), but an immutable (or const) variable is stored 
in the data segment.

Re: Memory Efficient HashSet

[Steven Schveighoffer via Digitalmars-d-learn]

On 3/8/16 3:12 AM, Nordlöw wrote:

Has anybody put together a memory-efficient D-implementation of a HashSet

Something like

sparse_hash_set<> contained in

https://github.com/sparsehash/sparsehash

but in D.


D needs a way to use allocators for hash nodes.

In Dcollections, both the performance and memory usage I was able to 
optimize by using a specialized allocator that allocates in pages and 
then divides up the pages.


-Steve

[Issue 15734] Need this for map

[via Digitalmars-d-bugs]

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

--- Comment #1 from Kenji Hara  ---
Since 2.030 to 2.070, all versions fail to compile the code.

Which version has succeed to compile with?

--

Re: A comparison between C++ and D

[Steven Schveighoffer via Digitalmars-d]

On 3/8/16 10:04 PM, Jack Stouffer wrote:

On Wednesday, 9 March 2016 at 01:18:26 UTC, maik klein wrote:

Direct link: https://maikklein.github.io/post/CppAndD/
Reddit link:
https://www.reddit.com/r/programming/comments/49lna6/a_comparison_between_c_and_d/


If you spot any mistakes, please let me know.



D moves objects with a bitwise copy, this means you should not have
internal pointers.


Unless you define this(this) right?


No. It's perfectly legal to move a struct without calling the postblit 
AFAIK.


-Steve

Re: Potential GSoC project - GC improvements

[Joakim via Digitalmars-d]

On Thursday, 10 March 2016 at 11:12:47 UTC, thedeemon wrote:

On Thursday, 10 March 2016 at 05:01:37 UTC, Joakim wrote:
Perhaps someone could build off of Sociomantic's concurrent GC 
(https://www.sociomantic.com/blog/2013/06/porting-cdgc-to-d2/), which I assume has been ported to D2, porting it to Windows or whatever else remains to be done and then adding to it.


Do you think Windows version of this cdgc is feasible at all?
It relies on fork, something that gets emulated on Windows but 
too slowly, as I understand.


I don't know enough about GCs and Windows to say.  I'm assuming 
it can be done with some effort, but I don't know how much.


Even if it's too much work, it'd be worth it just for POSIX 
systems, which make up almost 70% of all general-purpose 
computers running apps these days. :)


If it's good enough, it could eventually become the default on 
there, while leaving the legacy GC for Windows.

Re: GSoC 2016 - std.xml rewrite

[Marc Schütz via Digitalmars-d]

On Tuesday, 8 March 2016 at 18:01:25 UTC, Lodovico Giaretta wrote:
- one accepting InputRanges, that can work with almost any data 
source and does not require the entire input to be available at 
the same time; it's cons are that it must allocate lots of 
small strings (one for each token) and grow them one char at a 
time, so it's not so fast;


It could reuse its buffer though, and deal in `const(char)[]` 
instead of `string`. The consumer is responsible for copying if 
they need it. But I guess this will only be useful for the pull 
parser, or for one-pass filters/lookups.



This is just an early sketch, but I'd love to get some feedback.
Thank you for your time.


You might also check out Steven Schveighoffer's experimental IO 
module for stream parsing:


https://forum.dlang.org/thread/na14ul$30uo$1...@digitalmars.com

Re: Potential GSoC project - GC improvements

[thedeemon via Digitalmars-d]

On Thursday, 10 March 2016 at 05:01:37 UTC, Joakim wrote:
Perhaps someone could build off of Sociomantic's concurrent GC 
(https://www.sociomantic.com/blog/2013/06/porting-cdgc-to-d2/), 
which I assume has been ported to D2, porting it to Windows or 
whatever else remains to be done and then adding to it.


Do you think Windows version of this cdgc is feasible at all?
It relies on fork, something that gets emulated on Windows but 
too slowly, as I understand.

Re: unit-threaded v0.6.5 - Type-parametrized tests

[Atila Neves via Digitalmars-d-announce]

On Thursday, 10 March 2016 at 08:09:40 UTC, Jacob Carlborg wrote:

On 2016-03-09 19:01, Atila Neves wrote:
The forum must be sick of hearing from me... :P For those not 
in the

know, unit-threaded is an advanced unit testing library for D:

http://code.dlang.org/packages/unit-threaded

The v0.6.3 release had tests parametrized by value; this 
v0.6.5 release
brings with it the possibility of parametrizing tests by type, 
like so:


@Types!(int, byte)
void testInit(T)() {
 assert(T.init == 0);
}

This will run the testInit code twice, once for each type, and 
report

them as separate tests:

tests.pass.attributes.testInit.int:
tests.pass.attributes.testInit.byte:


I've literally only written that silly testInit example yet. 
But imagine

how easy it'd be to test, say, different input ranges.

I'm thinking of ways of getting the parametrized tests to work 
with the
built-in unittest blocks. I assume it'll be hacky. Right now 
it's the
only thing that requires non-standard test functions and I'm 
trying to
augment the existing unit testing features of D instead of 
replacing them.


Do you have a slightly more extended example that shows how 
this is used?


No, sorry. I haven't needed it yet. Something like this?

@Types!(int, string)
void testArray(T)() {
import std.container;

auto arr = Array!T();
arr.empty.shouldBeTrue;

arr.insertBack(T.init);
arr.empty.shouldBeFalse;
auto l = arr.length;
l.shouldEqual(1);
}


Atila

[Issue 15783] New: Junk is written into environment variable after assigning null to it

[via Digitalmars-d-bugs]

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

  Issue ID: 15783
   Summary: Junk is written into environment variable after
assigning null to it
   Product: D
   Version: D2
  Hardware: All
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: freeslav...@gmail.com

import std.stdio;
import std.process;
import std.path;

void test(string envvar)
{   
environment[envvar] = "myvalue";
writefln("check env: %s=%s (%s)", envvar, environment.get(envvar),
environment.get(envvar).length);
environment[envvar] = null;
writefln("check env: %s=%s (%s)", envvar, environment.get(envvar),
environment.get(envvar).length);
}

void main(string[] args)
{
test("TEST_VAR1");
test("TEST_VAR2");
}

This seems to be random. Sometimes it writes junk only to the second variable.

--

Re: GC scan for pointers

[thedeemon via Digitalmars-d-learn]

On Wednesday, 9 March 2016 at 15:14:02 UTC, Gerald Jansen wrote:
I've studied [1] and [2] but don't understand everything there. 
Hence these dumb questions:


Given

  enum n = 100_000_000; // some big number
  auto a = new ulong[](n);
  auto b = new char[8][](n);
  struct S { ulong x; char[8] y; }
  auto c = new S[](n);

will the large memory blocks allocated for a, b and/or c 
actually be scanned for pointers to GC-allocated memory during 
a garbage collection? If so, why?


I've just tested it with my GC tracker ( 
https://bitbucket.org/infognition/dstuff ), all 3 allocations go 
with flags APPENDABLE | NO_SCAN which means these blocks will not 
be scanned.


But if you define S as
struct S { ulong x; char[] y; }
so there is some pointer inside, then it gets allocated with just 
APPENDABLE flag, i.e. it will be scanned then.

[Issue 15778] [REG2.064] polysemous string type doesn't work in array operation

[via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commits pushed to stable at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/f3849978badaf2e07966c2f6c5c8af50486a1b0a
fix Issue 15778 - polysemous string type doesn't work in array operation

https://github.com/D-Programming-Language/dmd/commit/f1ee0d010a0cdcb7af096f157a18228a9eca0e2f
Merge pull request #5511 from 9rnsr/fix15778

[REG2.064] Issue 15778 - polysemous string type doesn't work in array operation

--

Re: unit-threaded v0.6.5 - Type-parametrized tests

[Atila Neves via Digitalmars-d-announce]

On Thursday, 10 March 2016 at 09:33:39 UTC, Iakh wrote:

On Wednesday, 9 March 2016 at 18:01:49 UTC, Atila Neves wrote:

@Types!(int, byte)
void testInit(T)() {
assert(T.init == 0);
}

Atila


It is not clear that this UDA is about unittesting


Even when attached to a test function?

Atila