[Issue 11269] [REG 2.064beta1] Union initialization on 64-bit plattforms

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

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

--

Re: DMD is slow for matrix maths?

[Iain Buclaw via Digitalmars-d]

On 27 Oct 2015 4:25 am, "Laeeth Isharc via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> 3) what exactly is the opportunity cost of Iain working on gdc ?  It's
hardly a fixed size cake.  And I don't know, but the relationships between
different back end people doesn't from public postings strike me as
strained.
>

Cost?  https://www.openhub.net/p/gdc/estimated_cost. :-)

We get somewhere in the vicinity of there eventually on matters of
implementation detail (to a lesser extent we agree on design when it comes
to platform dependant details).

There's never anything short of healthy debate between us.

Iain.

Re: Lifetime study group

[Guillaume Chatelet via Digitalmars-d]

On Tuesday, 27 October 2015 at 02:56:56 UTC, Rikki Cattermole 
wrote:

Is it possible to have a read only interface/receiving?
Because I'm interested in the content, but not enough knowledge 
to actually talk about it.


+1

Re: Mixin template, "no identifier for declarator"

[Andrea Fontana via Digitalmars-d-learn]

On Tuesday, 27 October 2015 at 07:56:51 UTC, SimonN wrote:

Hi,

I'd like to generate several very similar class methods with a 
mixin template.
The mixin template shall take alias parameters, so that 
different methods can

bind it to different fields. Reduced problem case:


Template mixins can be used only for declaration.
Probably what you need is a (non-template) mixin.

Check this: http://dlang.org/mixin.html

You should generate code you need and then mixin it.

Re: Fixing spurious "statement is not reachable" in template code

[tsbockman via Digitalmars-d]

On Tuesday, 27 October 2015 at 07:50:37 UTC, Daniel Murphy wrote:

Easy to fix:

void reachIf(bool x)()
{
 static if(!x)
 return;
 else
 writeln("reached");
}

The warning is correct, and incredibly annoying.


Yes, it is easy to work around the problem in my simple example 
code. Real world examples are not generally so simple, though - 
often, an equivalent fix would require a `static foreach(...) { 
... } else` construct to avoid adding a redundant (and possibly 
quite complex) predicate.


No, the warning is not correct.

When a "statement is not reachable" warning is generated during 
analysis of a regular function, it means that that statement can 
*never* execute, no matter what parameters are fed in.


This is a very useful warning, because why would the programmer 
deliberately write dead code? Clearly something is wrong (whether 
in the code being compiled, or the compiler itself).


On the other hand, when a "statement is not reachable" warning is 
generated based on a specific combination of compile-time 
parameters, there is likely nothing wrong with the code.


The purpose of templates is code reuse. Forcing the programmer to 
manually prune each possible instantiation by sprinkling `static 
if`s with redundant predicates everywhere hinders this goal.

Re: Lifetime study group

[Robert burner Schadek via Digitalmars-d]

On Tuesday, 27 October 2015 at 02:45:24 UTC, Andrei Alexandrescu 
wrote:


Normally we'd be holding this on the forum, but as we all know, 
forum discussions tend to meander a lot and lose focus. For 
that reason, please write me email about joining a mailing list 
dedicated to discussions on object lifetime - a study group. 
The outcome should be a DIP that moves forward safe lifetime 
management for D.


+1, but creating a dedicated mailing list feels exclusive to me 
again. I would at least like to read what they are talking about 
once a while. Maybe mark the threads "experts only" or something.

[Issue 15082] Output of process is not captured on Win64

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de,
   ||schvei...@yahoo.com

--- Comment #3 from Vladimir Panteleev  ---
I don't have that version installed... Rainer/Steve?

--

Nick coghlan bdfl delegate - 27 languages to improve your Python

[Laeeth Isharc via Digitalmars-d-learn]

http://www.curiousefficiency.org/posts/2015/10/languages-to-improve-your-python.html?utm_content=buffere6909_medium=social_source=twitter.com_campaign=buffer

He says nice things about D, although maybe one might say more 
and slightly different things.


It's good to see another who doesn't believe languages are in a 
death match.

Re: Automatic method overriding in sub-classes

[Jacob Carlborg via Digitalmars-d]

On 2015-10-27 00:25, Tofu Ninja wrote:

I know this has basically no chance of ever actually being added because
that is the way of all "I want feature X" threads, but I thought I would
post this anyways because I seem to want it constantly.

So we have TemplateThisParameters methods which are cool but have some
drawbacks.
They are templates so they are implicitly non-virtual and are called
based on the type of the reference.
It would be very nice to be able to auto generate method overrides based
on the this type with out having to drop a mixin in every sub class.
This would be very useful for CT-reflection.
I will call this new feature auto override methods for the rest of this
post.

An auto override method would take the form of a template method with
only a single type argument that is the type of the class or any of it's
sub classes.
To differentiate it from TemplateThisParameters it could look like:

  returnType functionName(auto override this T)() {...}

When ever a class with an auto override method is sub-classed, the auto
override method template is re-instantiated with the sub-class type and
the method is overridden automatically.
Key point is that the method will still be virtual.


Here is an example contrasting an auto override method with a regular
TemplateThisParameters method.

##
class A
{
  void foo(this T)() { writeln(T.stringof); }
  void bar(auto override this T)() { writeln(T.stringof); }
}

class B : A {}

void main()
{
  A a = new A();
  a.foo(); // prints "A"
  a.bar(); // prints "A"

  B b = new B();
  b.foo(); // prints "B"
  b.bar(); // prints "B"

  A c = new B();
  c.foo(); // prints "A"
  c.bar(); // prints "B" <-- main advantage, method is virtual
}
##


I don't think this is possible. Think of code looking like this:

// Imagine not having access to the source code "createA"
A createA()
{
new B;
}

void inspectA(A a)
{
a.bar();
}

How should the compiler know that when instantiating/calling "bar", T 
should be set to B? The compiler might not even know about B exists at 
all. Even if the compiler does have access to the complete source code 
it would, most likely, need to do a full program analyze to figure out 
the type of T, which is quite complicated.


--
/Jacob Carlborg

Re: Fixing spurious "statement is not reachable" in template code

[Daniel Murphy via Digitalmars-d]

On 25/10/2015 4:25 AM, tsbockman wrote:

///
module main;

import std.stdio;

void reachIf(bool x)()
{
 if(!x)
 return;
 writeln("reached"); // Warning: statement is not reachable
}

void main(string[] args) {
 reachIf!true();  // prints "reached"
 reachIf!false(); // triggers warning
}
///






Thoughts?


Easy to fix:

void reachIf(bool x)()
{
 static if(!x)
 return;
 else
 writeln("reached");
}

The warning is correct, and incredibly annoying.

[Issue 15082] Output of process is not captured on Win64

[via Digitalmars-d-bugs]

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

--- Comment #2 from Temtaime  ---
2015

--

[Issue 14843] Update installer to detect VS2015/SDK10 paths; update sc.ini

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 CC||r.sagita...@gmx.de

--- Comment #1 from Rainer Schuetze  ---
fixed in dmd 2.069

--

[Issue 14843] Update installer to detect VS2015/SDK10 paths; update sc.ini

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

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

--

[Issue 14849] Visual Studio 2015 not detected during installation

[via Digitalmars-d-bugs]

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

Rainer Schuetze  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||r.sagita...@gmx.de
 Resolution|--- |FIXED

--- Comment #11 from Rainer Schuetze  ---
fixed in dmd 2.069

--

Mixin template, "no identifier for declarator"

[SimonN via Digitalmars-d-learn]

Hi,

I'd like to generate several very similar class methods with a 
mixin template.
The mixin template shall take alias parameters, so that different 
methods can

bind it to different fields. Reduced problem case:

class A {
int myField;

mixin template fieldSetter(alias whatField)
{
whatField = newVal;
}

int setMyField(in int newVal)
{
mixin fieldSetter!myField;
}
}

Compiler error message, DMD64 v2.068.2, line 6 is "whatField = 
newVal;":


(6): Error: no identifier for declarator whatField
(6): Error: declaration expected, not '='

I believe I'm following as closely as appropriate what's 
described at
http://dlang.org/template-mixin.html under "Mixins can 
parameterize symbols

using alias parameters".

Why does it error out on whatField, apparently deeming it to be a 
type?


Can I get this done with mixin templates? (I'd like to avoid 
string mixins,

the workaround with them got a little ugly.)

-- Simon

Re: Option types and pattern matching.

[Kagamin via Digitalmars-d]

On Monday, 26 October 2015 at 16:42:27 UTC, TheFlyingFiddle wrote:
If you instead use pattern matching as in your example you have 
much better context information that can actually help you do 
something in the case a value is not there.


Probably possible:

Some!T get(T)(Option!T item) {
Some!T r;
//Static guarantee of handling value not present
item match {
None() => {
throw new Exception("empty!");
}
Some(t) => {
r=t;
}
}

return r;
}

Then:
Option!File file;
Some!File s = file.get();

Re: Automatic method overriding in sub-classes

[Tofu Ninja via Digitalmars-d]

On Tuesday, 27 October 2015 at 07:52:27 UTC, Jacob Carlborg wrote:

[...]
I don't think this is possible. Think of code looking like this:

// Imagine not having access to the source code "createA"
A createA()
{
new B;
}

void inspectA(A a)
{
a.bar();
}

How should the compiler know that when instantiating/calling 
"bar", T should be set to B? The compiler might not even know 
about B exists at all. Even if the compiler does have access to 
the complete source code it would, most likely, need to do a 
full program analyze to figure out the type of T, which is 
quite complicated.


The method is instantiated when the subclass is defined so T 
would obviously be right on hand. Sub-classing a class with an 
auto override method would implicitly instantiate and override 
the method. Calling a.bar() would have no problems because bar 
would be virtual.

Re: Lifetime study group

[Dicebot via Digitalmars-d]

Invite-only mail list with archive being published via 
forum.dlang.org interface (read-only) sounds like a best match to 
be.


I agree that public NG is not very suitable for any serious 
technical case study, this has been the recurring pattern.

[Issue 15225] cannot overload directly aliased function literals

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #1 from Vladimir Panteleev  ---
(In reply to Kenji Hara from comment #0)
> alias foo = (int x) => x;
> alias foo = (string x) => x;

This syntax doesn't work in released DMD versions, but if I replace it with:

alias I(alias X) = X;
alias foo = I!((int x) => x);
alias foo = I!((string x) => x);

then compilation succeeds (though then I get a linker error).

--

[Issue 3479] writef/writefln: positional precision not working

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

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

--

[Issue 15227] std.format undocumented grammar

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com,
   ||rburn...@gmail.com,
   ||thecybersha...@gmail.com
   See Also||https://issues.dlang.org/sh
   ||ow_bug.cgi?id=3479

--- Comment #1 from Vladimir Panteleev  ---
The code seems to have been added by Andrei Alexandrescu himself back in 2011:

https://github.com/D-Programming-Language/phobos/commit/e068168273e4200bbf0c44e5ebba6a697a714b97
https://issues.dlang.org/show_bug.cgi?id=3479

CCing our diligent documentation writers.

--

[Issue 15251] New: std.datetime bug with -inline

[via Digitalmars-d-bugs]

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

  Issue ID: 15251
   Summary: std.datetime bug with -inline
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: tri...@katamail.com

Created attachment 1559
  --> https://issues.dlang.org/attachment.cgi?id=1559=edit
Minimized test case

The attached code doesn't work with 2.069rc1.
It works with beta.

It says:
Error: cannot cast cast(ubyte)20u to void at compile time

--

[Issue 15238] Heisenbug running std.random unittests

[via Digitalmars-d-bugs]

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

--- Comment #3 from Vladimir Panteleev  ---
BTW, I'm not sure how intentional this is, but in a lot of places the
std.random tests pass the RNG object by-value to e.g. randomSample, which means
that it will query the same values over and over without advancing the RNG.

--

[Issue 15251] std.datetime bug with -inline

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #3 from Martin Nowak  ---
cat > a.d << CODE
import std.net.curl;
CODE

cat > b.d << CODE
import std.datetime;

string J(Date L)
{
return L.toISOExtString;
}
CODE
dmd -inline -o- a.d b.d


Error: cannot cast cast(ubyte)20u to void at compile time
/usr/include/dmd/phobos/std/conv.d(1259):called from here:
array(toChars(value + 0LU))
/usr/include/dmd/phobos/std/conv.d(861):called from here: toImpl(value,
10u, cast(LetterCase)false)
/usr/include/dmd/phobos/std/format.d(3490):called from here: to(n)
/usr/include/dmd/phobos/std/format.d(3501):called from here: gencode()
/usr/include/dmd/phobos/std/format.d(3501): Error: argument to mixin must be a
string, not (gencode()) of type string
/usr/include/dmd/phobos/std/format.d(545): Error: template instance
std.format.formatNth!(Appender!string, char, const(short), const(Month),
const(ubyte)) error instantiating


Confirmed, currently reducing.

--

[Issue 15248] Function in current module is not allowed to overload imported function

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #2 from Vladimir Panteleev  ---
You can reintroduce std.math.round to the current module's overload set using
an alias:

alias round = std.math.round;

--

[Issue 15239] ICE (assertion failure) in ctfeInterpret() — opDispatch & inline asm

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #1 from Vladimir Panteleev  ---
2.064 .. 2.065:
test.d(9): Error: Cannot interpret opDispatch!"foo" at compile time
test.d(9): Error: bad type/size of operands '__error'

2.066 .. 2.067: segfault

2.068: Assertion failure: 'e->type' on line 731 in file 'interpret.c'

2.069: segfault

Curiously, the Win32 "Access violation" stack trace I get with 2.069 changes
every time I run the compiler. Probably due to lack of stack frames.

--

Re: s/TypeTuple/AliasSeq/g?

[Dicebot via Digitalmars-d]

On Wednesday, 21 October 2015 at 16:17:46 UTC, Marc Schütz wrote:
For me, a tuple is a finite ordered collection of values of 
arbitrary type, which can be identified and accessed by their 
index.


Which definition of tuple are you using that doesn't apply to 
e.g. `AliasSeq!(42, "foo")`?


For me important property is that tuple itself must be distinct 
entity that can be passed around and is generally full part of 
the type system. Also destructuring is one of established tuple 
features in other languages. Limiting it to values is irrelevant 
(but somewhat necessary to define ABI because of mentioned 
property).


Obviosuly, I am referring to established programming "tuple" 
concept, not math term it originates from.

[Issue 15246] Destructor inheritance doesn't inherit attributes properly

[via Digitalmars-d-bugs]

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

--- Comment #4 from Marco Leise  ---
The destructors do *neither* inherit *nor* call their parent destructors. Not
as a matter of terminology, but because in D they are not called recursively,
but in sequence, starting from the runtime type's dtor and working its way up
the inheritance chain. Take a look at the druntime source I linked above and
you will understand what happens.

To make the bug report valid we would have to introduce destructor inheritance
to the language to begin with. Right now the only functions affected by the
destructor attributes would be the attribute-less external(C) functions
`rt_finalize` and `rt_finalize2`. (In client code we call `rt_finalize` as
`destroy(Object obj)` for deterministic object destruction).

--

Re: Release Candidate D 2.069.0-rc1

[Martin Nowak via Digitalmars-d-announce]

On 10/27/2015 08:53 AM, Rainer Schuetze wrote:
> Sorry for being a little late with these:

Thanks, the fix will be in the final release.
http://dlang.org/changelog/2.069.0.html#link-against-vs2015.

[Issue 15238] Heisenbug running std.random unittests

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||thecybersha...@gmail.com

--- Comment #2 from Vladimir Panteleev  ---
I've seen this a bunch of times. If you read the comment above the failing
assert, essentially that entire check is luck-based. That test should be
changed to use a RNG seeded with a constant value, or removed entirely.

--

[Issue 15249] Floating-point division should multiply by inverse if lossless.

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||performance
 CC||thecybersha...@gmail.com

--

[Issue 14956] C++ Mangling incompatible with C++11

[via Digitalmars-d-bugs]

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

Marco Leise  changed:

   What|Removed |Added

 CC||marco.le...@gmx.de

--- Comment #2 from Marco Leise  ---
The mangling of the mangling changed? I thought that was a typo, but obviously
you are right. They mangled and wrapped the mangling into a __cxx11 wrapper.

I assume the only way out of this is providing a -cxx11 flag for dmd? >.<

--

[Issue 15251] std.datetime bug with -inline

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords|pull|

--- Comment #2 from Vladimir Panteleev  ---
Sorry, wrong window

--

Re: Lifetime study group

[Andrei Alexandrescu via Digitalmars-d]

On 10/26/15 10:56 PM, Rikki Cattermole wrote:

Is it possible to have a read only interface/receiving?
Because I'm interested in the content, but not enough knowledge to
actually talk about it.


Then you may want to join and opt not to post. -- Andrei

Re: Lifetime study group

[Andrei Alexandrescu via Digitalmars-d]

On 10/27/15 5:01 AM, Dicebot wrote:

Invite-only mail list with archive being published via forum.dlang.org
interface (read-only) sounds like a best match to be.


Ah, interesting. Vladimir, do you think you could rig such a list? -- Andrei

Re: Lifetime study group

[Andrei Alexandrescu via Digitalmars-d]

On 10/27/15 4:42 AM, Robert burner Schadek wrote:

On Tuesday, 27 October 2015 at 02:45:24 UTC, Andrei Alexandrescu wrote:


Normally we'd be holding this on the forum, but as we all know, forum
discussions tend to meander a lot and lose focus. For that reason,
please write me email about joining a mailing list dedicated to
discussions on object lifetime - a study group. The outcome should be
a DIP that moves forward safe lifetime management for D.


+1, but creating a dedicated mailing list feels exclusive to me again.


I don't plan to be selective about admission. Whoever wants to join can 
join. All we need is to not make the discussion part of the general 
forum entertainment.



I
would at least like to read what they are talking about once a while.
Maybe mark the threads "experts only" or something.


So I'll add you to the list then.


Andrei

你的中文说的很好了，谢谢你的解答

[guodemone via Digitalmars-d-announce]

非常感谢，希望DLang可以进入中国的大学，那样Dlang会更有前途，我在为这个目标努力着。

[Issue 15251] [REG2.069.0-rc1] std.datetime bug with -inline

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

Summary|std.datetime bug with   |[REG2.069.0-rc1]
   |-inline |std.datetime bug with
   ||-inline
   Severity|enhancement |regression

--- Comment #4 from Vladimir Panteleev  ---
Introduced in https://github.com/D-Programming-Language/dmd/pull/5216

--

[Issue 15238] Heisenbug running std.random unittests

[via Digitalmars-d-bugs]

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

--- Comment #4 from Vladimir Panteleev  ---
https://github.com/D-Programming-Language/phobos/pull/3776

--

Re: Lifetime study group

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 27 October 2015 at 09:49:48 UTC, Andrei Alexandrescu 
wrote:

On 10/27/15 5:01 AM, Dicebot wrote:
Invite-only mail list with archive being published via 
forum.dlang.org

interface (read-only) sounds like a best match to be.


Ah, interesting. Vladimir, do you think you could rig such a 
list? -- Andrei


I can add it to forum.dlang.org after Brad sets up the actual 
mailing list. I don't host any mailing lists myself.


Although I could in theory begin hosting mailing lists, the one 
time I tried it was very unpleasant and non-trivial and seems 
like a disproportionate amount of effort for this project.


What's wrong with a thread on the current MLs? I might be wrong 
but it seems that the amount of discussion on how to discuss the 
matter is already disproportionate to the amount of discussion on 
the matter itself. Besides, we have too many dead MLs already 
(dmd-concurrency? Digitalmars-d-dtl?)

Re: s/TypeTuple/AliasSeq/g?

[Suliman via Digitalmars-d]

On Wednesday, 21 October 2015 at 15:25:34 UTC, Jonathan M Davis 
wrote:
On Wednesday, 21 October 2015 at 15:21:14 UTC, Marc Schütz 
wrote:
The renaming was done in an attempt to fix a particularly bad 
name that has caused a lot of confusion. The result is another 
bad name that's likely to create confusion for different 
reasons. As to whether we're better or worse off, I don't know.

+1

[Issue 13624] Parts of the Overview page is very out of date

[via Digitalmars-d-bugs]

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

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

https://github.com/D-Programming-Language/dlang.org/commit/988af21485d14aaad56a4473973fb65c1e093eb1
Merge pull request #1135 from JackStouffer/issue13624

Fix for issue 13624 (Part 2)

--

Re: 0 in version number?

[Ozan via Digitalmars-d]

On Friday, 16 October 2015 at 22:44:15 UTC, Gary Willoughby wrote:
On Friday, 16 October 2015 at 17:58:27 UTC, Jonathan M Davis 
wrote:

[...]


How? Let me explain.

[...]

[...]


Great words! And today every success is somehow a result of 
marketing.

Re: how use * in D just like C++

[Jakob Ovrum via Digitalmars-d]

On Tuesday, 27 October 2015 at 05:36:58 UTC, liumao wrote:

for example
class A;
{
void doSomething() {}
}

A *a = cast(A *) new A;

then I call a.doSomething(); my program "Segmentation fault"



how could it happened? and how i use it correctly?


3q, please tell me, 3q 3q 3q!


`A` on its own is already a reference type. `A*` is a pointer to 
a class reference, i.e. a pointer to a pointer, like `A**` in C++.


http://wiki.dlang.org/Coming_From/C_Plus_Plus#Slicing_problem

Please use D.learn for questions like this in the future.

[Issue 15238] Heisenbug running std.random unittests

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 15238] Heisenbug running std.random unittests

[via Digitalmars-d-bugs]

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

--- Comment #5 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/19b0be7de493c1c167c7a3114c4950f8bc4e63b5
fix Issue 15238 - Heisenbug running std.random unittests

https://github.com/D-Programming-Language/phobos/commit/900e0dd36a92cb4d65301ccf2e98a5f43e52d93e
Merge pull request #3776 from CyberShadow/pull-20151027-094401

fix Issue 15238 - Heisenbug running std.random unittests

--

Re: Lifetime study group

[Mithun Hunsur via Digitalmars-d]

On Tuesday, 27 October 2015 at 12:56:48 UTC, Guillaume Chatelet 
wrote:
On Tuesday, 27 October 2015 at 09:48:21 UTC, Andrei 
Alexandrescu wrote:

So I'll add you to the list then.


Please add me to the list too. Thx !


Please add me as well; lifetime management is a matter of great 
interest to me, especially with regards to avoiding the GC.

Re: Fixing spurious "statement is not reachable" in template code

[Timon Gehr via Digitalmars-d]

On 10/27/2015 01:35 PM, Steven Schveighoffer wrote:


Easy to fix:

void reachIf(bool x)()
{
  static if(!x)
  return;
  else
  writeln("reached");
}

The warning is correct, and incredibly annoying.



Easy to fix, but the warning is incorrect, the statement is reachable if
you use reachIf!true.

A statement is not a compiled piece of code.

-Steve


Versions of the same statement in different instantiations are 
independent. Templates are just a restricted form of hygienic macros.

Re: Lifetime study group

[Daniel Kozak via Digitalmars-d]

V Tue, 27 Oct 2015 13:00:29 +
Mithun Hunsur via Digitalmars-d  napsáno:

> On Tuesday, 27 October 2015 at 12:56:48 UTC, Guillaume Chatelet 
> wrote:
> > On Tuesday, 27 October 2015 at 09:48:21 UTC, Andrei 
> > Alexandrescu wrote:  
> >> So I'll add you to the list then.  
> >
> > Please add me to the list too. Thx !  
> 
> Please add me as well; lifetime management is a matter of great 
> interest to me, especially with regards to avoiding the GC.

Please add me too. Thanks

Re: Lifetime study group

[Guillaume Chatelet via Digitalmars-d]

On Tuesday, 27 October 2015 at 09:48:21 UTC, Andrei Alexandrescu 
wrote:

So I'll add you to the list then.


Please add me to the list too. Thx !

asm+D build bootloader

[guodemone via Digitalmars-d-learn]

Asm + D with the ability to write on behalf of Clang bootloader, 
and prove that he can completely replace Clang.


This is my wish.

[Issue 15246] Destructor inheritance doesn't inherit attributes properly

[via Digitalmars-d-bugs]

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

--- Comment #5 from Andrei Alexandrescu  ---
(In reply to Marco Leise from comment #4)
> The destructors do *neither* inherit *nor* call their parent destructors.
> Not as a matter of terminology, but because in D they are not called
> recursively, but in sequence, starting from the runtime type's dtor and
> working its way up the inheritance chain. Take a look at the druntime source
> I linked above and you will understand what happens.
> 
> To make the bug report valid we would have to introduce destructor
> inheritance to the language to begin with. Right now the only functions
> affected by the destructor attributes would be the attribute-less
> external(C) functions `rt_finalize` and `rt_finalize2`. (In client code we
> call `rt_finalize` as `destroy(Object obj)` for deterministic object
> destruction).

I understand what happens technically (each dtor is distinct, and code external
to the destructor calls them all).

What happens conceptually is that destructors in derived classes both override
and call destructors in base classes. There is no need to change the language
to make the bug report valid. Destructors must typecheck as if they override
and call the base class destructors.

--

Re: Mixin template, "no identifier for declarator"

[SimonN via Digitalmars-d-learn]

On Tuesday, 27 October 2015 at 08:41:24 UTC, Andrea Fontana wrote:

Template mixins can be used only for declaration.


Thanks for the quick reply! I didn't know that. Now the error 
message makes sense.



Probably what you need is a (non-template) mixin.


Yes, it's gonna be a string mixin, or a private method with lots 
of ref parameters.


-- Simon

asm+D build bootloader

[guodemone via Digitalmars-d-learn]

sorry,My english is poot.

file asm.h

/*
是bootasm.S汇编文件所需要的头文件，主要是一些与X86保护模式的段访问方式相关的宏定义
*/

#ifndef __BOOT_ASM_H__
#define __BOOT_ASM_H__

/* Assembler macros to create x86 segments */

/* Normal segment */
#define SEG_NULLASM 
\
.word 0, 0; 
\
.byte 0, 0, 0, 0

#define SEG_ASM(type,base,lim)  
\
.word (((lim) >> 12) & 0x), ((base) & 0x);  
  \
.byte (((base) >> 16) & 0xff), (0x90 | (type)), 
  \
(0xC0 | (((lim) >> 28) & 0xf)), (((base) >> 24) & 0xff)


/* Application segment type bits */
#define STA_X   0x8 // 可执行
#define STA_E   0x4 // 向下扩展段（非可执行段）
#define STA_C   0x4 // 一致性代码段（只执行）
#define STA_W   0x2 // 段可写（非可执行段）
#define STA_R   0x2 // 段可读 (可执行段）
#define STA_A   0x1 // 可访问

#endif /* !__BOOT_ASM_H__ */

**
file bootasm.S

# 定义并实现了bootloader最先执行的函数start，此函数进行了一定的初始化，完成了
# 从实模式到保护模式的转换，并调用bootmain.c中的bootmain函数

#include 

# Start the CPU: switch to 32-bit protected mode, jump into C.
# The BIOS loads this code from the first sector of the hard disk 
into
# memory at physical address 0x7c00 and starts executing in real 
mode

# with %cs=0 %ip=7c00.

# gdt 全局描述符表内的数组索引
.set PROT_MODE_CSEG,0x8 
# kernel code segment selector
.set PROT_MODE_DSEG,0x10# 
kernel data segment selector
.set CR0_PE_ON, 0x1 
# protected mode enable flag

.globl start
start:
.code16 
# Assemble for 16-bit mode
cli 
# 禁用中断
cld 
# 字符串操作设定为递增 si++ di++ ,cld的作用是将direct flag标志位清零

# Set up the important data segment registers (DS, ES, SS).
xorw %ax, %ax   
# Segment number zero
movw %ax, %ds  
 # -> Data Segment
movw %ax, %es  
 # -> Extra Segment
movw %ax, %ss  
 # -> Stack Segment

# A20地址线控制打开工作
# Enable A20:
# 为了向后兼容早期的PC机，让物理地址线20接低电平
# 如果A20是关闭的，16bit的寻址范围2^20是1M，如果是打开的，那么就是2^21次方，
# 但是寻址还是h:h=0h+h=10FFEFh=1M+64K-16Bytes
seta20.1:
inb $0x64, %al  
# Wait for not busy
testb $0x2, %al
jnz seta20.1  #测试 bit 1 是不是为0，如果不是跳回去继续执行

# 对于键盘的8042控制芯片 0x64是命令端口 0xd1 代表写命令
movb $0xd1, %al
 # 0xd1 -> port 0x64
outb %al, $0x64

seta20.2:
inb $0x64, %al  
# Wait for not busy
testb $0x2, %al
jnz seta20.2

# 设置写命令后 给0x60端口 发送命令数据0xdf就是打开A20地址线，0xdd就是关闭
movb $0xdf, %al
 # 0xdf -> port 0x60
outb %al, $0x60

# 转入保护模式，这里需要指定一个临时的GDT，来翻译逻辑地址。
# 这里使用的GDT通过gdtdesc段定义，它翻译得到的物理地址和虚拟地址相同，
# 所以转换过程中内存映射不会改变
lgdt gdtdesc
# 启动保护模式前建立好的段描述符合段描述符表

# 打开保护模式标志位，相当于按下了保护模式的开关。
# cr0寄存器的第0位就是这个开关，通过CR0_PE_ON或cr0寄存器，将第0位置1
movl %cr0, %eax
orl $CR0_PE_ON, %eax
movl %eax, %cr0

# 由于上面的代码已经打开了保护模式了，所以这里要使用逻辑地址，
# 而不是之前实模式的地址了。这里用到了PROT_MODE_CSEG,
# 他的值是0x8。根据段选择子的格式定义，0x8就翻译成：
　　#　　INDEX TI CPL
　　#　　   1  00  0
# INDEX代表GDT中的索引，TI代表使用GDTR中的GDT， CPL代表处于特权级。
# PROT_MODE_CSEG选择子选择了GDT中的第1个段描述符。
# 这里使用的gdt就是变量gdt，下面可以看到gdt的第1个段描述符的基地址是0x,
	# 所以经过映射后和转换前的内存映射的物理地址一样。:7C00=0x7C00 :protcseg 
都是相对于物理内存基址的

ljmp $PROT_MODE_CSEG, $protcseg

.code32 
# Assemble for 32-bit mode
protcseg:
# 重新初始化各个段寄存器。也就是采用平坦式内存方式，
# 代码段同其它段都采用一个内存空间
movw $PROT_MODE_DSEG, %ax   
# 自定义数据段选择子，因为段选择子是16位的

Re: asm+D build bootloader

[Kagamin via Digitalmars-d-learn]

You chose quite advanced topic. Maybe you want to build common 
skills in system programming first?

Re: DMD is slow for matrix maths?

[burjui via Digitalmars-d]

On Tuesday, 27 October 2015 at 05:27:22 UTC, Jack Stouffer wrote:
My intentions are to call things as they are. If people are 
demoralized after learning that one person working in his spare 
time can't match the productivity of several people working 
full time, then they need a reality check.
Can't agree more. It's unrealistic to expect Walter work on the 
backend full-time just to catch up with GCC and LLVM teams, let 
alone support architectures other than x86 as well.

Re: Playing audio files and related functions?

[Cleverson via Digitalmars-d-learn]

Thanks all for the answers, I'll investigate all.

Re: Safe reference counting cannot be implemented as a library

[Rikki Cattermole via Digitalmars-d]

On 28/10/15 12:41 AM, Andrei Alexandrescu wrote:

(Title is borrowed from Hans Boehm's famous "Threads cannot be
implemented as a library",
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf.)

We want to implement safe reference counting in D, and the sentiment
that it can be done in a library (with no or minimal changes to the
language) is often echoed in the newsgroup. This post explains that
reference counting can be implemented as a library _only_ if safety is
forgone. If safety is desired, reference counting must be built into
language semantics.

The crux of the matter is modular typechecking. Consider the following
example:

// module widget.d
@safe class Widget {
   void fun() {
 g_widget = this;
   }
}
static Widget g_widget;
// end of module widget.d

This is a perfect valid D class, and safe too. The typechecker assumes
infinite lifetime for all Widget objects, and allows escaping the
reference to this from foo() into the global.

Numerous similar examples can be constructed involving more elaborate
escaping patterns than this simple global assignment.

Now, once the typechecker OKs module widget.d, the summary that all
other typechecking "sees" is:

@safe class Widget {
   void fun();
}

A library reference counting wrapper a la RC!Widget needs to allow calls
to fun(). Once that happens, the global will hold an alias to the
respective Widget object indefinitely, which means as soon as the
RC!Widget object is released by the reference counting protocol,
g_widget will become a dangling reference.

It follows that if we want safe reference counting, there must be
language support for it. One possibility is to attach an attribute to
the class definition:

@safe @rc class Widget {
   ...
}

Then the compiler is able to enforce more stringent typechecking on
Widget (for example, address of fields are not allowed to escape) and
also insert the appropriate reference counting logic. This will be a
topic discussed on the lifetime list.


Andrei


Thought: we have RTInfo where we can place anything we want for a type.
Perhaps we could explore this avenue a bit?

A library solution, but perhaps in druntime instead of e.g. Phobos.
Add in compiler hooks and wala. Language support for it.

Other random thoughts, a storage attribute cast(@rc)myRef;
On a class (as you shown) @rc class Widget {}

I think there is no one solution here. But similar behavior with 
slightly different semantics.


Anyway, the only wrong solution involves:

RefCount!T func(IAllocator alloc=theAllocator) {
return RefCount!T(alloc.make!T, alloc);
}

Which I'm already doing.
And now I want to join that group... great.

Re: Lifetime study group

[ponce via Digitalmars-d]

On Tuesday, 27 October 2015 at 02:45:24 UTC, Andrei Alexandrescu 
wrote:

Lifetime study group


Ain't nobody got time for a lifetime of study?

;)

Re: Safe reference counting cannot be implemented as a library

[Andrei Alexandrescu via Digitalmars-d]

On 10/27/2015 07:57 AM, Manu via Digitalmars-d wrote:

On 27 October 2015 at 21:41, Andrei Alexandrescu via Digitalmars-d
 wrote:


It follows that if we want safe reference counting, there must be language
support for it. One possibility is to attach an attribute to the class
definition:

@safe @rc class Widget {
   ...
}


An attribute? Is presence of opInc()/opDec() insufficient? Would the
attribute signal fabrication of some default opInc/opDec operators
applicable for general use?


You're right, opInc/opDec detection would suffice.

Unrelated, and a foreshadowing of the discussion on the lifetime mailing 
list: the compiler has ample opportunity to fuse incs/decs together, so 
the signatures of these functions is:


void opInc(uint delta);
void opDec(uint delta);

For example, consider:

class Widget {
  void fun(Widget, Widget);
}
...
auto w = new Widget;
w.fun(w, w);

In this case the compiler may insert opInc with a value larger than 1 
prior to entering the call.



Andrei

Re: Fixing spurious "statement is not reachable" in template code

[Steven Schveighoffer via Digitalmars-d]

On 10/26/15 1:08 PM, tsbockman wrote:

On Monday, 26 October 2015 at 12:31:37 UTC, Steven Schveighoffer wrote:

Some possible solutions:

1. Defer "not reachable" warnings until compilation has been completed,
and only issue the warning if *all* instantiations of the statement were
unreachable.


This isn't good either. One instantiation of reachIf being able to
compile shouldn't be dependent on whether another one was ever used.


I agree this is not ideal, however it would be much better than what we
have currently, and the compiler implementation should be relatively
simple.


2. For semantic analysis purposes, first instantiate each template using
dummy parameters with the widest possible VRP ranges. Only statements
found to be "not reachable" in this dummy run should actually generate
warnings.


How does the compiler figure this out? This seems like the halting
problem to me.


My solution #2 is the same as the one you proposed - the dummy parameter
stuff is my vague proposal for a way to actual implement this behavior
in the compiler.

The halting problem is no more of an issue than it is for the compiler
today. (That is to say, the halting problem leads to false negatives,
but not false positives.)


OK, as long as the default behavior isn't to reject the code, I suppose 
this is simply an optimization. But the problem I see is that only 
static ifs that reduce to static if(true) would be considered to cause a 
short-circuit (e.g. someint <= int.max). Unless the compiler can VRP 
according to the template constraint, which may be possible in simple 
circumstances, but not in all circumstances.


It just seems like it's an unnecessary layer. I think we should start 
with the simple accept all code that branches based on compile-time 
variables.



The reason solution #2 could end up being a ton of work, is that a dummy
type will have to be created to apply this solution to cases like:

module main;

import std.stdio;

void reachIf(T...)()
{
 if(T.length != 1 || T[0].sizeof != 4)
 return;
 writeln("reached"); // Warning: statement is not reachable
}


Inherent properties of types that can be variable could be considered 
variables just like any other size_t or int. Therefore, branching based 
on that would fall under the same issue.


I think the "ton of work" is avoidable.

-Steve

Re: Lifetime study group

[Andrei Alexandrescu via Digitalmars-d]

On 10/27/2015 08:29 AM, ixid wrote:

On Tuesday, 27 October 2015 at 09:41:30 UTC, Andrei Alexandrescu wrote:

On 10/26/15 10:56 PM, Rikki Cattermole wrote:

Is it possible to have a read only interface/receiving?
Because I'm interested in the content, but not enough knowledge to
actually talk about it.


Then you may want to join and opt not to post. -- Andrei


I understand the desire to keep it focused but it would seem very
unfortunate not to have it at least read-only mirrored on the forum.
That would set a direction for the future that the discussion will
happen out of sight. I would love to see the contents of the discussion
but have nothing to contribute to such a degree that I'm certainly not
signing up for the mailing group.


There is the risk that two parallel discussions develop - the mailing 
list and the bleachers. Then folks on the mailing list start replying to 
the list etc. etc.


What I do want to do is keep the discussion focused and that cannot 
happen in the chaotic, ever-meandering forum environment.



Andrei

Re: Lifetime study group

[Andrei Alexandrescu via Digitalmars-d]

On 10/27/15 5:55 AM, Vladimir Panteleev wrote:

I might be wrong but it seems that the amount of discussion on how to
discuss the matter is already disproportionate to the amount of
discussion on the matter itself.


At least past experience suggests you're very wrong about that :o). -- 
Andrei

Re: DMD is slow for matrix maths?

[ponce via Digitalmars-d]

On Tuesday, 27 October 2015 at 11:23:37 UTC, burjui wrote:
On Tuesday, 27 October 2015 at 05:27:22 UTC, Jack Stouffer 
wrote:
My intentions are to call things as they are. If people are 
demoralized after learning that one person working in his 
spare time can't match the productivity of several people 
working full time, then they need a reality check.
Can't agree more. It's unrealistic to expect Walter work on the 
backend full-time just to catch up with GCC and LLVM teams, let 
alone support architectures other than x86 as well.


Moreover, given the frequent backend regressions it might be 
better not to touch it too much. As of now relying on DMD for 
optimized builds gives constant work.

Re: Safe reference counting cannot be implemented as a library

[Manu via Digitalmars-d]

On 27 October 2015 at 21:41, Andrei Alexandrescu via Digitalmars-d
 wrote:
>
> It follows that if we want safe reference counting, there must be language
> support for it. One possibility is to attach an attribute to the class
> definition:
>
> @safe @rc class Widget {
>   ...
> }

An attribute? Is presence of opInc()/opDec() insufficient? Would the
attribute signal fabrication of some default opInc/opDec operators
applicable for general use?

Re: Lifetime study group

[Robert burner Schadek via Digitalmars-d]

On Tuesday, 27 October 2015 at 09:48:21 UTC, Andrei Alexandrescu 
wrote:


So I'll add you to the list then.



Acknowledged

Re: Fixing spurious "statement is not reachable" in template code

[Steven Schveighoffer via Digitalmars-d]

On 10/27/15 3:50 AM, Daniel Murphy wrote:

On 25/10/2015 4:25 AM, tsbockman wrote:

///
module main;

import std.stdio;

void reachIf(bool x)()
{
 if(!x)
 return;
 writeln("reached"); // Warning: statement is not reachable
}

void main(string[] args) {
 reachIf!true();  // prints "reached"
 reachIf!false(); // triggers warning
}
///






Thoughts?


Easy to fix:

void reachIf(bool x)()
{
  static if(!x)
  return;
  else
  writeln("reached");
}

The warning is correct, and incredibly annoying.



Easy to fix, but the warning is incorrect, the statement is reachable if 
you use reachIf!true.


A statement is not a compiled piece of code.

-Steve

Safe reference counting cannot be implemented as a library

[Andrei Alexandrescu via Digitalmars-d]

(Title is borrowed from Hans Boehm's famous "Threads cannot be 
implemented as a library", 
http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf.)


We want to implement safe reference counting in D, and the sentiment 
that it can be done in a library (with no or minimal changes to the 
language) is often echoed in the newsgroup. This post explains that 
reference counting can be implemented as a library _only_ if safety is 
forgone. If safety is desired, reference counting must be built into 
language semantics.


The crux of the matter is modular typechecking. Consider the following 
example:


// module widget.d
@safe class Widget {
  void fun() {
g_widget = this;
  }
}
static Widget g_widget;
// end of module widget.d

This is a perfect valid D class, and safe too. The typechecker assumes 
infinite lifetime for all Widget objects, and allows escaping the 
reference to this from foo() into the global.


Numerous similar examples can be constructed involving more elaborate 
escaping patterns than this simple global assignment.


Now, once the typechecker OKs module widget.d, the summary that all 
other typechecking "sees" is:


@safe class Widget {
  void fun();
}

A library reference counting wrapper a la RC!Widget needs to allow calls 
to fun(). Once that happens, the global will hold an alias to the 
respective Widget object indefinitely, which means as soon as the 
RC!Widget object is released by the reference counting protocol, 
g_widget will become a dangling reference.


It follows that if we want safe reference counting, there must be 
language support for it. One possibility is to attach an attribute to 
the class definition:


@safe @rc class Widget {
  ...
}

Then the compiler is able to enforce more stringent typechecking on 
Widget (for example, address of fields are not allowed to escape) and 
also insert the appropriate reference counting logic. This will be a 
topic discussed on the lifetime list.



Andrei

Re: Lifetime study group

[ixid via Digitalmars-d]

On Tuesday, 27 October 2015 at 09:41:30 UTC, Andrei Alexandrescu 
wrote:

On 10/26/15 10:56 PM, Rikki Cattermole wrote:

Is it possible to have a read only interface/receiving?
Because I'm interested in the content, but not enough 
knowledge to

actually talk about it.


Then you may want to join and opt not to post. -- Andrei


I understand the desire to keep it focused but it would seem very 
unfortunate not to have it at least read-only mirrored on the 
forum. That would set a direction for the future that the 
discussion will happen out of sight. I would love to see the 
contents of the discussion but have nothing to contribute to such 
a degree that I'm certainly not signing up for the mailing group.

[Issue 15223] Error: don't know how to make 'src\core\sys\linux\unistd.d'

[via Digitalmars-d-bugs]

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

Kenji Hara  changed:

   What|Removed |Added

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

--- Comment #2 from Kenji Hara  ---
The pull request is already merged in:

https://github.com/D-Programming-Language/druntime/commit/5b45269c7f56d6c02cf7c882648132f3af19d51b

--

Re: Safe reference counting cannot be implemented as a library

[Manu via Digitalmars-d]

On 27 October 2015 at 22:27, Andrei Alexandrescu via Digitalmars-d
 wrote:
> On 10/27/2015 07:57 AM, Manu via Digitalmars-d wrote:
>>
>> On 27 October 2015 at 21:41, Andrei Alexandrescu via Digitalmars-d
>>  wrote:
>>>
>>>
>>> It follows that if we want safe reference counting, there must be
>>> language
>>> support for it. One possibility is to attach an attribute to the class
>>> definition:
>>>
>>> @safe @rc class Widget {
>>>...
>>> }
>>
>>
>> An attribute? Is presence of opInc()/opDec() insufficient? Would the
>> attribute signal fabrication of some default opInc/opDec operators
>> applicable for general use?
>
>
> You're right, opInc/opDec detection would suffice.
>
> Unrelated, and a foreshadowing of the discussion on the lifetime mailing
> list: the compiler has ample opportunity to fuse incs/decs together, so the
> signatures of these functions is:
>
> void opInc(uint delta);
> void opDec(uint delta);
>
> For example, consider:
>
> class Widget {
>   void fun(Widget, Widget);
> }
> ...
> auto w = new Widget;
> w.fun(w, w);
>
> In this case the compiler may insert opInc with a value larger than 1 prior
> to entering the call.

Awesome. Hadn't thought of that. Nice catch!
Perhaps add me to the list. I don't think I have anything to add that
I haven't said before, but I have very high interest in this topic.

[Issue 15222] std.experimental omitted from phobos zip file

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #1 from Martin Nowak  ---
https://github.com/D-Programming-Language/phobos/pull/3777

How about changing your workflow instead?

--

[Issue 15168] [REG2.068.0] std.variant.Algebraic interacts badly with string alias this sub-types

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #2 from Martin Nowak  ---
Is this a duplicate of issue 15039?

--

Re: Automatic method overriding in sub-classes

[bitwise via Digitalmars-d]

On Tuesday, 27 October 2015 at 14:21:12 UTC, bitwise wrote:
On Tuesday, 27 October 2015 at 07:52:27 UTC, Jacob Carlborg 
wrote:

On 2015-10-27 00:25, Tofu Ninja wrote:

[...]


I don't think this is possible. Think of code looking like 
this:


// Imagine not having access to the source code "createA"
A createA()
{
new B;
}

void inspectA(A a)
{
a.bar();
}

How should the compiler know that when instantiating/calling 
"bar", T should be set to B? The compiler might not even know 
about B exists at all. Even if the compiler does have access 
to the complete source code it would, most likely, need to do 
a full program analyze to figure out the type of T, which is 
quite complicated.


It's not a template function. The auto override wouldn't be 
instantiated if/when it's called. It would always be 
instantiated automatically when the class was compiled. Then, 
if you were just using the class as an import, the compiler 
would know that the definition should exists somewhere(static 
lib, etc..).


When an auto override function was called, it may or may not 
have the definition..it wouldn't matter, since it's like a 
virtual function. But, if someone tried to subclass a class 
which had even one auto override function with missing it's 
definition, then the effect would be the same as trying to 
subclass a sealed/final class.


Bit


Going a bit further, I think you could override an auto override 
fun too manually as well. This would be helpful both for adding 
additional functionality, and as a fallback if the definition of 
the auto override function was not available. If someone sub 
classed a class in which they had manually overridden an auto 
override function, the compiler would fall back to using the base 
method, if available. Finally(pun intended), a user could 
manually override an auto override function and mark it as final 
to stop the automatic overriding.


   Bit

Re: Calypso progress report (+ updated MingW64 build)

[jmh530 via Digitalmars-d-announce]

On Monday, 26 October 2015 at 23:39:19 UTC, bachmeier wrote:


It's not difficult to embed R inside D. I will finish a 
forecasting project in early November, and will be able to 
finish it up after that. That will bring R's full plotting 
capabilities to D.



This sounds cool. I look forward to it.

Re: Calypso progress report (+ updated MingW64 build)

[bachmeier via Digitalmars-d-announce]

On Tuesday, 27 October 2015 at 15:23:34 UTC, jmh530 wrote:

On Monday, 26 October 2015 at 23:39:19 UTC, bachmeier wrote:


It's not difficult to embed R inside D. I will finish a 
forecasting project in early November, and will be able to 
finish it up after that. That will bring R's full plotting 
capabilities to D.



This sounds cool. I look forward to it.


I've already written dmdinline to go in the other direction. I 
can reuse the underlying code I wrote for that for the 
interoperability, so all I have to do is create a C interface to 
RInside. Actually, that's what I did when I started using D, but 
I'll have to dig up my old code and polish it to the point that 
I'd be willing to share it.

[Issue 15246] Destructor inheritance doesn't inherit attributes properly

[via Digitalmars-d-bugs]

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

--- Comment #9 from Andrei Alexandrescu  ---
That's quite the bummer because rt_finalize in all likelihood doesn't know
anything about attributes.

--

Re: Option types and pattern matching.

[TheFlyingFiddle via Digitalmars-d]

On Tuesday, 27 October 2015 at 07:55:46 UTC, Kagamin wrote:
On Monday, 26 October 2015 at 16:42:27 UTC, TheFlyingFiddle 
wrote:
If you instead use pattern matching as in your example you 
have much better context information that can actually help 
you do something in the case a value is not there.


Probably possible:

Some!T get(T)(Option!T item) {
Some!T r;
//Static guarantee of handling value not present
item match {
None() => {
throw new Exception("empty!");
}
Some(t) => {
r=t;
}
}

return r;
}

Then:
Option!File file;
Some!File s = file.get();


Sure that would work but i don't see that it's different then an 
enfore since you don't have access the context where get is 
invoked so you can't really do anything with it.


Contrived Example:

void foo()
{
   Option!File worldFile = getAFile("world.json");
   auto world  = parseJSON(worldFile.get());
   Option!File mapFile = getAFile(world["map"]);
   auto map= parseJSON(mapFile.get());
   //Other stuff.
}

Let's say we get an NoObjectException, this tells us that either 
the world.json file did not exist or the map file does not exist. 
get does not have access to that context so we wouldn't be able 
to tell. This next example would fix this.


void foo()
{
   Option!File worldFile = getAFile("world.json");
   enforce(worldFile.hasValue, "Error while loading file: 
world.json");

   auto world = parseJSON(worldFile.get());
   Option!File mapFile = getAFile(world["map"]);
   enforce(mapFile.hasValue, "Error while loading file: " ~ 
world["map"]);

   auto map = parseJSON(mapFile.get());
   //Other stuff
}

Now we know which file failed to load. But we bypassed the 
NoObjectException to do it.


I would prefer this style instead.
void foo()
{
  Option!File worldFile = getAFile("world.json");
  match worldFile {
 Some(value) => {
 auto world  = parseJSON(value);
 Option!File mapFile = getAFile(world["map"]);
 match mapFile {
Some(mapf) => {
   auto map = parseJSON(mapf);
   //Do something here.
},
None => enforce(false, "Failed to load: " ~ 
world["map"]);

 }
 },
 None => enforce(false, "Failed to load: world.json");
   }
}

The reason that I prefer that is not that I like the syntax 
really. It's just that if the only way to get a value is to 
pattern match on it then you are forced to consider the case 
where the value was not there.



Guess a D version without language support would look something 
like:

void foo()
{
  auto worldFile = getAFile("world.json");
  worldFile.match!(
 (File worldf) {
auto world = parseJSON(value);
auto mapFile = getAFile(world["map"]);
mapFile.match!(
   (File mapf)
   {
  auto map = parseJSON(mapf);
  //Do stuff;
   },
   (None) => enforce(false, "Failed to load: " ~ 
world["map"]);

 },
 (None) => enforce(false, "Failed to load: world.json")
  );
}

The example here is very contrived. Here we just throw exceptions 
if the file could not load and if that is all we do we should 
just wrap getAFile instead but i hope you get my point.

[Issue 15246] Destructor inheritance doesn't inherit attributes properly

[via Digitalmars-d-bugs]

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

--- Comment #8 from Marco Leise  ---
We "finalize" them through the helper function `rt_finalize` mentioned earlier,
which calls the __dtor's in sequence and is the only place that also handles
destruction of the hidden "monitor" field if it was used. It is wrapped in
object.d as:

void destroy(T)(T obj) if (is(T == class))
{
rt_finalize(cast(void*)obj);
}

destroy() complete object finalization + memory reinitialized to .init
__xdtor   same as __dtor + destroys any RAII members
__dtorthe ~this() function as defined in the source
(That's how I remember it. May be inaccurate.)

--

Re: Option types and pattern matching.

[Kagamin via Digitalmars-d]

On Tuesday, 27 October 2015 at 15:06:07 UTC, TheFlyingFiddle 
wrote:
The reason that I prefer that is not that I like the syntax 
really. It's just that if the only way to get a value is to 
pattern match on it then you are forced to consider the case 
where the value was not there.


If pattern matching is the only way, the get function above will 
still work: it uses only pattern matching, nothing else.

Re: Safe reference counting cannot be implemented as a library

[Andrei Alexandrescu via Digitalmars-d]

On 10/27/15 11:59 AM, Jonathan M Davis wrote:

On Tuesday, 27 October 2015 at 12:27:29 UTC, Andrei Alexandrescu wrote:

Unrelated, and a foreshadowing of the discussion on the lifetime
mailing list:


What's the lifetime mailing list?


To be created. -- Andrei

Re: Sociomantic Labs is looking for Software Developers! (D language)

[Dejan Lekic via Digitalmars-d-announce]

I've created LinkedIn jobs post about this:

https://www.linkedin.com/grp/post/3923820-6064809938163691520?trk=groups-post-b-title

Good luck! :)

[Issue 15168] [REG2.068.0] std.variant.Algebraic interacts badly with string alias this sub-types

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|DUPLICATE   |---

--- Comment #4 from Vladimir Panteleev  ---
Grr, sorry. No it's not. I tested the wrong bug.

--

[Issue 15039] Algebraic cannot store a Typedef along with Typedef'ed type

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 CC||radu.raca...@gmail.com

--- Comment #4 from Vladimir Panteleev  ---
*** Issue 15168 has been marked as a duplicate of this issue. ***

--

Re: Fixing spurious "statement is not reachable" in template code

[tsbockman via Digitalmars-d]

On Tuesday, 27 October 2015 at 13:23:51 UTC, Timon Gehr wrote:

On 10/27/2015 01:35 PM, Steven Schveighoffer wrote:


Easy to fix:

void reachIf(bool x)()
{
  static if(!x)
  return;
  else
  writeln("reached");
}

The warning is correct, and incredibly annoying.



Easy to fix, but the warning is incorrect, the statement is 
reachable if

you use reachIf!true.

A statement is not a compiled piece of code.

-Steve


Versions of the same statement in different instantiations are 
independent. Templates are just a restricted form of hygienic 
macros.


That's how the current implementation works, but that doesn't 
mean the warning is actually *helpful*.

Re: Fixing spurious "statement is not reachable" in template code

[tsbockman via Digitalmars-d]

On Tuesday, 27 October 2015 at 12:28:38 UTC, Steven Schveighoffer 
wrote:

On 10/26/15 1:08 PM, tsbockman wrote:
My solution #2 is the same as the one you proposed - the dummy 
parameter
stuff is my vague proposal for a way to actual implement this 
behavior

in the compiler.

The halting problem is no more of an issue than it is for the 
compiler
today. (That is to say, the halting problem leads to false 
negatives,

but not false positives.)


OK, as long as the default behavior isn't to reject the code, I 
suppose this is simply an optimization.


Right.

But the problem I see is that only static ifs that reduce to 
static if(true) would be considered to cause a short-circuit 
(e.g. someint <= int.max). Unless the compiler can VRP 
according to the template constraint, which may be possible in 
simple circumstances, but not in all circumstances.


I think the next piece of Lionello Lunesu's PR which I am 
updating might actually do that; I'll have to check later. 
Regardless, you are correct solution #1 will substantially reduce 
the opportunities for constant folding.


It just seems like it's an unnecessary layer. I think we should 
start with the simple accept all code that branches based on 
compile-time variables.


Can outline which specific code in the compiler you would modify 
to accomplish this?


Because at the moment, having looked at the relevant front end 
code, I don't see a way that is meaningfully simpler than my 
dummy parameter idea.


The reason solution #2 could end up being a ton of work, is 
that a dummy
type will have to be created to apply this solution to cases 
like:


module main;

import std.stdio;

void reachIf(T...)()
{
 if(T.length != 1 || T[0].sizeof != 4)
 return;
 writeln("reached"); // Warning: statement is not reachable
}


Inherent properties of types that can be variable could be 
considered variables just like any other size_t or int. 
Therefore, branching based on that would fall under the same 
issue.


I think the "ton of work" is avoidable.


I have only a fuzzy understanding of the compiler's code right 
now, but it seems to me that the way it is currently structured 
does not readily allow for simultaneously making information 
available to `static if` and CTFE, while also hiding it from dead 
code detection.


I get what you want, but if it's simple to actually make the 
compiler do it, I don't see how yet. If you do, please give me 
the names of some files or functions to study in the front end.

[Issue 15168] [REG2.068.0] std.variant.Algebraic interacts badly with string alias this sub-types

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Vladimir Panteleev  ---
Yes, confirmed fixed in stable.

*** This issue has been marked as a duplicate of issue 15039 ***

--

Re: Safe reference counting cannot be implemented as a library

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 27 October 2015 at 12:27:29 UTC, Andrei Alexandrescu 
wrote:
Unrelated, and a foreshadowing of the discussion on the 
lifetime mailing list:


What's the lifetime mailing list?

- Jonathan M Davis

Re: Lifetime study group

[deadalnix via Digitalmars-d]

On Tuesday, 27 October 2015 at 12:20:06 UTC, ponce wrote:
On Tuesday, 27 October 2015 at 02:45:24 UTC, Andrei 
Alexandrescu wrote:

Lifetime study group


Ain't nobody got time for a lifetime of study?

;)


You can choose to see it as a lethal dose.

Also, Andrei, sign me in (I sent you a direct email, but in case 
you missed it).

Re: Option types and pattern matching.

[Meta via Digitalmars-d]

On Tuesday, 27 October 2015 at 15:06:07 UTC, TheFlyingFiddle 
wrote:

I would prefer this style instead.
void foo()
{
  Option!File worldFile = getAFile("world.json");
  match worldFile {
 Some(value) => {
 auto world  = parseJSON(value);
 Option!File mapFile = getAFile(world["map"]);
 match mapFile {
Some(mapf) => {
   auto map = parseJSON(mapf);
   //Do something here.
},
None => enforce(false, "Failed to load: " ~ 
world["map"]);

 }
 },
 None => enforce(false, "Failed to load: world.json");
   }
}


This can arguably already be done cleaner in D.

if (auto worldFile = getAFile("world.json"))
{
auto world = parseJSON(worldFile);
if (auto mapFile = getAFile(world["map"))
{
//...
}
else enforce(false, "Failed to load: " ~ world["map"]);
}
else enforce(false, "Failed to load: world.json");

Or even:

auto worldFile = enforce(getAFile("world.json"), "Failed to load: 
world.json");

auto world = parseJSON(worldFile);
auto mapFile = enforce(getAFile(world["map"]), "Failed to load: " 
~ world["map"]);

//...

From what I've seen in the Rust community, they try to avoid 
using match as it's very syntactically heavy. They have all kinds 
of idioms to avoid doing matches on Option, such as the try! 
macro, unwrap_or, unwrap_or_else, etc.


That being said, pattern matching has been one of my most-wanted 
D features for years.

Re: Safe reference counting cannot be implemented as a library

[deadalnix via Digitalmars-d]

I've made the claim that we should implement reference counting 
as a library many time, so I think I should explicit my position. 
Indeed, RC require some level a compiler support to be safe. That 
being said, the support does not need to be specific to RC. On 
fact, my position is that the language should provide some basic 
mechanism on top of which safe RC can be implemented, as a 
library.


The problem at hand here is escape analysis. The compiler must be 
able to ensure that a reference doesn't escape the RC mechanism 
in an uncontrolled manner. I'd like to add such mechanism to the 
language rather than bake in reference counting, as it can be 
used to solve other problem we are facing today (@nogc exception 
for instance).

[Issue 15247] Object's destructor should be pure @safe nothrow @nogc

[via Digitalmars-d-bugs]

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

Marco Leise  changed:

   What|Removed |Added

 CC||marco.le...@gmx.de

--- Comment #3 from Marco Leise  ---
class D
{
~this() @system {}
}

void main()
{
   foo(new D);
}

void foo(Object o) pure @safe nothrow @nogc
{
o.destroy(); // Whatever we call it...
}

What I'm saying here is, if destructors were virtual methods that inherit and
recursively call their base class destructors, and we had pure @safe nothrow
@nogc on Object, we could NOT actually introduce impure destructors, as the
compiler cannot statically verify attributes that may be loosened in a derived
class. Attributes can only be added to overridden methods never removed, the
same way methods can only be added and not removed. This bug report is invalid,
in my humble opinion.

--

[Issue 15233] TypeTuple causes segfault in dmd 2.68.2

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Fixing spurious "statement is not reachable" in template code

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 27 October 2015 at 16:05:31 UTC, tsbockman wrote:

On Tuesday, 27 October 2015 at 13:23:51 UTC, Timon Gehr wrote:
Versions of the same statement in different instantiations are 
independent. Templates are just a restricted form of hygienic 
macros.


That's how the current implementation works, but that doesn't 
mean the warning is actually *helpful*.


Well, arguably that's exactly what templates _are_ regardless of 
the implementation - i.e. a template is just a template to 
generate code, not really actual code in and of itself. Now, that 
being said, I'm not sure that warning about unreachable code in a 
templated function is particularly helpful - particularly if it 
forces you to jump through hoops to make the compiler shut up 
about it. Heck, if anything, I find that warning/error annoying 
in regular code, because it tends to get in the way of debugging 
while developing. It wouldn't really hurt my feelings any if we 
just removed it from the compiler entirely - though I completely 
agree that you don't really want to have unreachable code left in 
your production code.


- Jonathan M Davis

Re: Lifetime study group

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 27 October 2015 at 09:49:48 UTC, Andrei Alexandrescu 
wrote:

On 10/27/15 5:01 AM, Dicebot wrote:
Invite-only mail list with archive being published via 
forum.dlang.org

interface (read-only) sounds like a best match to be.


Ah, interesting. Vladimir, do you think you could rig such a 
list? -- Andrei


Isn't the Beta mailing list essentially that right now? I recall 
folks complaining about it being only a mailing list such that 
they couldn't post to it via nntp or the web forums. And if 
that's the case, then it's probably pretty straightforward to 
treat this new list the same way.


- Jonathan M Davis

[Issue 15246] Destructor inheritance doesn't inherit attributes properly

[via Digitalmars-d-bugs]

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

--- Comment #10 from Marco Leise  ---
Nope, in fact it is an extern(C) function, and I assume part of the druntime
API that people replace when writing bare metal runtimes etc.

Since destructors don't need to inherit attributes for anything based on the
current implementation, this bug report has no basis. If attributes were
inherited, it would not solve any use case or problem. If you meant to
streamline the language semantics with this, it was well meant, but actually
adds to the cognitive load.

Or did you have some specific use case in mind, like being able to
deterministically destroy objects in @safe functions? That's not going to
happen either way. As it stands now, `destroy(obj)` and `rt_finalize`, which is
neither @safe nor @nogc nor nothrow nor pure. And if we did in fact have
virtual destructors like C++, the general rule with inheritance applies: The
derived thing must be usable everywhere the base class is used. That disallows
the removal of attributes on virtual function overrides:

class C {
   ~this() @safe
}

class D {
   override ~this(); // @system
}

void foo(C c) @safe 
{
   // Destroying D is unsafe, but we can't statically check,
   // because for all we know it is at least a C.
   destroy(c);
}

void main()
{
   foo(new D);
}

--

Re: Fixing spurious "statement is not reachable" in template code

[Steven Schveighoffer via Digitalmars-d]

On 10/27/15 9:23 AM, Timon Gehr wrote:

On 10/27/2015 01:35 PM, Steven Schveighoffer wrote:


Easy to fix:

void reachIf(bool x)()
{
  static if(!x)
  return;
  else
  writeln("reached");
}

The warning is correct, and incredibly annoying.



Easy to fix, but the warning is incorrect, the statement is reachable if
you use reachIf!true.

A statement is not a compiled piece of code.



Versions of the same statement in different instantiations are
independent. Templates are just a restricted form of hygienic macros.



I understand how the compiler treats it. But it still doesn't make the 
warning true. In some cases, the statement is reachable, the compiler is 
unhelpfully pointing out cases where it was unreachable.


It would be if the compiler had a function like this:

int foo(bool x)
{
   if(x == 5) return 1;
   return 0;
}

And you compile this function:

void main()
{
   foo(5);
}

with -inline, the compiler complained. It's unhelpful that you are 
telling me that you are not generating code for my statement *in this 
instance*.


If you want to tell me that you would *never* generate code for my 
statement in *any* instance, that is helpful.


-Steve

Re: DMD is slow for matrix maths?

[Etienne Cimon via Digitalmars-d]

On Monday, 26 October 2015 at 20:30:51 UTC, rsw0x wrote:

On Monday, 26 October 2015 at 11:37:17 UTC, Etienne Cimon wrote:

On Monday, 26 October 2015 at 04:48:09 UTC, H. S. Teoh wrote:
On Mon, Oct 26, 2015 at 02:37:16AM +, Etienne Cimon via 
Digitalmars-d wrote:


If you must use DMD, I recommend filing an enhancement 
request and bothering Walter about it.



T


I'd really like the performance benefits to be available to 
DMD users as well. I think I'll have to write it all with 
inline assembler just to be sure...


dmd will never reach gdc/ldc performance, gcc and LLVM have 
entire teams of people that actively contribute to their 
compilers.


LDC couldn't inline it either. My only options at this point is 
to write the assembly or link to a C library.

Re: DMD is slow for matrix maths?

[Etienne Cimon via Digitalmars-d]

On Tuesday, 27 October 2015 at 18:18:36 UTC, Etienne Cimon wrote:

On Monday, 26 October 2015 at 20:30:51 UTC, rsw0x wrote:
On Monday, 26 October 2015 at 11:37:17 UTC, Etienne Cimon 
wrote:

On Monday, 26 October 2015 at 04:48:09 UTC, H. S. Teoh wrote:

[...]


I'd really like the performance benefits to be available to 
DMD users as well. I think I'll have to write it all with 
inline assembler just to be sure...


dmd will never reach gdc/ldc performance, gcc and LLVM have 
entire teams of people that actively contribute to their 
compilers.


LDC couldn't inline it either. My only options at this point is 
to write the assembly or link to a C library.


Btw, DMD and LDC had similar performance.

Re: Slack discussion group?

[Jack Stouffer via Digitalmars-d]

On Tuesday, 27 October 2015 at 17:49:51 UTC, Andrew Benton wrote:
Slack seems like it is becoming more and more popular.  Have we 
considered setting up a Slack chat group?


Slack is designed for small teams, and many programming 
communities that tried to jump on the bandwagon are realizing 
this and switching back: 
http://blog.freecodecamp.com/2015/06/so-yeah-we-tried-slack-and-we-deeply-regretted-it.html


There's an IRC channel, it's good. Use that instead.