Re: Classes and Structs, Memory management questions

[ikod via Digitalmars-d-learn]

On Friday, 2 September 2016 at 08:43:45 UTC, dom wrote:


Since garbage collection is a very nice feature that I wouldn't 
wanna miss for certain scenarios I think D should give us the 
opportunity to determine how an object is allocated. In the 
example above putting it on the stack is probably a good idea. 
Having a self managed reference to the heap can be good too if 
manual memory management is wanted. Or of course let the GC 
manage it ( i love it for prototyping code and also as a D 
beginner it is beneficial that i just dont need to care about 
memory management).


Could somebody explain to me if this is seen as a problem 
why/whynot and how I should address that kind of issues in my 
code?


You can allocate class instance on stack:

https://dlang.org/phobos/std_typecons.html#.scoped

Re: Fallback 'catch-all' template functions

[Manu via Digitalmars-d]

On 3 September 2016 at 11:38, Andrei Alexandrescu via Digitalmars-d
 wrote:
> On 9/3/16 2:41 AM, Manu via Digitalmars-d wrote:
>>
>> On 3 September 2016 at 00:18, Xinok via Digitalmars-d
>>  wrote:
>>>
>>>
>>> In the past, I have suggested using the "default" keyword to specify a
>>> fallback function of this kind. I think it's a useful pattern for generic
>>> algorithms that have optimized variants on specific types for
>>> performance.
>>>
>>>void f(T)(T t) if(isSomething!T) {}
>>>void f(T)(T t) if(isSomethingElse!T) {}
>>>void f(T)(T t) default {}
>>
>>
>> It's an interesting idea... flesh out a DIP?
>
>
> We're better off without that. -- Andrei

Then we need a decent way to do this.
As I've just expressed in the ADL thread, this whole pattern, which is
alleged as one of D's core offerings; templates + UFCS -> pipeline
programming (or 'component' programming as Walter likes to call it),
is loaded with issues, and other than SFINAE being a pita, and UFCS
coming to C++ 'soon'™, the whole thing is much easier in C++ right
now.

Re: ADL

[Manu via Digitalmars-d]

On 3 September 2016 at 11:25, Walter Bright via Digitalmars-d
 wrote:
> On 9/2/2016 6:12 PM, Stefan Koch wrote:
>>
>> If this feature were supported, it would probably break our module system.
>> Even if we could shoehorn it into the language it would make the compiler
>> slower.
>
>
> Note that C++ needs ADL in part because it cannot do options 2, 3 or 4.

They're not solutions though, they're workarounds. They're all
problematic, and highly unsavoury.
Nobody is gonna go "oh, i really wish i could do those things in
C++!", because the problem is already solved :/

Re: colour lib

[rikki cattermole via Digitalmars-d]

On 03/09/2016 12:17 PM, Manu via Digitalmars-d wrote:
...snip...


I think the presence of all this colour space information as type
arguments should nudge users in the right direction. They'll be all
"I've never seen this parameter before..." and google it... maybe.
I don't think it's the std lib doco's job to give users a lesson in
colour theory...? :/


Something[0] along this line perhaps?

Overview of the choices and scope along with reasoning.

[0] 
https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/graphic/image/specification.dd

phobos unit tests

[Manu via Digitalmars-d]

This document: https://wiki.dlang.org/Contributing_to_Phobos

States: "Avoid unittest in templates (it will generate a new unittest
for each instance) - put your tests outside"

Sounds reasonable, but then I realised that most of my unit tests are
documenting unittests... this recommendation is in conflict with the
documentation standards... who wins?

Re: Fallback 'catch-all' template functions

[Walter Bright via Digitalmars-d]

On 9/1/2016 10:49 AM, Timon Gehr wrote:

The following causes an ICE (DMD segfaults).

import std.stdio;

int f(T)(T t) if(!__traits(compiles,.f!T)) {
return 0;
}
int f(T)(T t) if(!__traits(compiles,.f!T)) {
return 1;
}

void main(){
writeln(f(2));
}


Please post seg faults to bugzilla.

Re: Using OpenGL

[Mike Parker via Digitalmars-d-learn]

On Friday, 2 September 2016 at 20:38:15 UTC, Darren wrote:
I'm trying to teach myself OpenGL but I'm not sure how to set 
it up exactly.
I used "dub init" to create a project, I downloaded glew32.dll 
and glfw.dll and put them in this folder.  I added 
"derelict-gl3": "~>1.0.19" and "derelict-glfw3": "~>3.1.0" to 
dependencies, and imported them in the app.d file.  I add the 
load() and reload() functions where appropriate (I assume).


You don't need GLEW. It's a library for C and C++ that loads all 
of the OpenGL functions and extensions available in the context 
you create. DerelictGL3 does that for you in D. DerelictGl3.load 
loads the OpenGL DLL and the functions up to OGL 1.1, and 
DerelictGL3.reload loads all the functions and extensions 
available in the current context.




I can run a simple window program and it seems to work fine, 
but I notice that's when all the functions begin with "glfw".


Yes, GLFW is a simple windowing toolkit for creating windows & 
OpenGL contexts and managing window & input events in a 
cross-platform manner. Without it, you would need to use the 
system APIs yourself (such as Win32 on Windows) or another 
cross-platform library  like SDL or SFML.



If I try to follow a tutorial for loading a triangle, I get 
errors when trying to build.


Do I need to link an opengl.dll file, too?


No, you do not need to link to OpenGL. By default, Derelict loads 
shared libraries at runtime so you will never have a link-time 
dependency on the C libraries Derelict binds to.


Please post the errors you are seeing.

Re: Fallback 'catch-all' template functions

[Andrei Alexandrescu via Digitalmars-d]

On 9/3/16 2:41 AM, Manu via Digitalmars-d wrote:

On 3 September 2016 at 00:18, Xinok via Digitalmars-d
 wrote:


In the past, I have suggested using the "default" keyword to specify a
fallback function of this kind. I think it's a useful pattern for generic
algorithms that have optimized variants on specific types for performance.

   void f(T)(T t) if(isSomething!T) {}
   void f(T)(T t) if(isSomethingElse!T) {}
   void f(T)(T t) default {}


It's an interesting idea... flesh out a DIP?


We're better off without that. -- Andrei

Re: ADL

[Walter Bright via Digitalmars-d]

On 9/2/2016 6:12 PM, Stefan Koch wrote:

If this feature were supported, it would probably break our module system.
Even if we could shoehorn it into the language it would make the compiler 
slower.


Note that C++ needs ADL in part because it cannot do options 2, 3 or 4.

[Issue 15625] Internal error: backend/elfobj.c 1014

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--- Comment #4 from Walter Bright  ---
Can't do anything without a reproducible example.

--

Re: ADL

[Stefan Koch via Digitalmars-d]

On Saturday, 3 September 2016 at 01:09:18 UTC, Walter Bright 
wrote:


Essentially, ADL has awkward problems when getting beyond the 
simple cases. It isn't right for D.


I could not agree more strongly!

If this feature were supported, it would probably break our 
module system.
Even if we could shoehorn it into the language it would make the 
compiler slower.

Re: ADL

[Walter Bright via Digitalmars-d]

On 9/2/2016 4:51 PM, Manu via Digitalmars-d wrote:

(I should have given the example with test() outside the namespace)


It's always best to provide an example of the actual problem rather than 
something else.



module bob;
struct S {}
void f(S s);

module joe;
struct T {}
void f(T t);

module myalgorithm;
void test(T)(T t)
{
  f(t);
}


module user_code;
import bob, joe;

import myalgorithm;  // needed

void main()
{
  test(S.init);
  test(T.init);
}

This is a better example. I can't be invading test() with any aliases,
or imports. It wouldn't be an algorithm anymore if I did that.
This pattern seems to bite me every direction I turn when trying to
write range or algorithm style code. C++ has ADL, and ADL works. I've
never thought about this problem in C++,



First solution:

   module bob;
   struct S {
   void f();
   }

Second solution:

module user_code;
import bob, joe;
import myalgorithm;

mixin myalgorithm.test!S;
mixin myalgorithm.test!T;

void main()
{
  test(S.init);
  test(T.init);
}

Third solution:

module myalgorithm;
void test(M,T)(T t)
{
M.f(t);
}

module user_code;
import bob, joe;
import myalgorithm;

void main()
{
  test!bob(S.init);
  test!joe(T.init);
}

Fourth solution:

module myalgorithm;

void test(T)(T t)
{
import std.traits;
mixin("import " ~ std.traits.moduleName!T ~ ";");
mixin("alias M = " ~ std.traits.moduleName!T ~ ";");
// The above could be encapsulated into an eponymous template
// that takes T as a parameter and returns the alias

M.f(t);
}

> or had any problems with ADL

https://en.wikipedia.org/wiki/Argument-dependent_name_lookup#Criticism

Essentially, ADL has awkward problems when getting beyond the simple cases. It 
isn't right for D.

Re: Fallback 'catch-all' template functions

[Manu via Digitalmars-d]

On 3 September 2016 at 00:18, Xinok via Digitalmars-d
 wrote:
>
> In the past, I have suggested using the "default" keyword to specify a
> fallback function of this kind. I think it's a useful pattern for generic
> algorithms that have optimized variants on specific types for performance.
>
>void f(T)(T t) if(isSomething!T) {}
>void f(T)(T t) if(isSomethingElse!T) {}
>void f(T)(T t) default {}

It's an interesting idea... flesh out a DIP?

Re: colour lib

[Manu via Digitalmars-d]

On 3 September 2016 at 03:25, Marco Leise via Digitalmars-d
 wrote:
> Am Fri, 2 Sep 2016 15:58:05 +1000
> schrieb Manu via Digitalmars-d :
>
>> I wonder, should NormalizedInt be a module beneath the color package,
>> or should it be a separate module in its own right?
>> I don't know of uses for that type outside packed colours, but it
>> could theoretically be used for anything...
>
> I guess audio sample would be a perfect match for signed and
> unsigned normalized integers.

Perfect! I moved out outside the colour package. Contention resolved :)


>> > Surely adding sRGB(22,22,22) + sRGB(11,11,11) gives sRGB(28, 28, 28),
>> > with a higher precision while performing the addition and then
>> > rounding back.
>>
>> Umm, no. I think operations should be within their own colourspace,
>> otherwise what's the point of selecting your working colourspace?
>> You need to be able to do operations in gamma space too. If you want
>> to do a linear operation, cast to a linear type before doing the
>> operation.
>
> So it is not a library that unifies color spaces into working
> with light intensities

That's a design goal, and it's very easy to cast to a linear type to
do that work.


> but more of a library to perform
> linear blending directly in the color-space.

This is another goal.
A colour implementation in the std library is a little tricky, it
needs to be both correct AND efficient for the different use cases
where the trade-off lines are drawn differently.
The only reasonable way I can think to support this is to do
operations within the typed colourspace, and let the user cast to the
colourspace desired for their operations.
So the meat of the lib is really about convenient colourspace
conversion, and making the colourspaces easy to describe, particularly
for non-experts.

I'm feeling like it's getting pretty close to my intent.

Naturally, image processing libs would tend to do linear conversions
internally. So it shouldn't be a detail that reaches the end-user very
often.
Remember that when doing linear conversions of colours, you tend to
also need to use float colour channels, since floats naturally express
the same non-linear precision curve that the gamma curves exist to
compensate for. Linear RGB8 will severely lose precision and band very
badly.


> That means when I add two HSV colors of the same ubyte hue
> = 200, the result will have hue == 144, right ?

Yes, it would necessarily be that. If it didn't behave that way, you
wouldn't be able to express a lerp in HSV space.
Additive colour blending in HSV doesn't really make sense. It works as
expected if you're adding deltas.

Ideally, hue would be expressed with a circular angle type (rather
than NormalizedInt as I've used for the other channels), which is
something we don't have in phobos, and I'm not motivated to write one
just for this one color channel...


>> > Anything requiring multiple operations on an
>> > image should use a higher precision linear color space from
>> > the start.
>>
>> Right, I think you would typically cast from the storage type to the
>> working type before doing some work. But there are so many cases, and
>> various levels of tradeoff between efficiency and correct-ness, the
>> lib can't make presumptions.
>> The way it is currently, the operations are done in the typed
>> colourspace. Simple as that. If you want to do linear operations, cast
>> to a linear type first.
>
> Ok, might be worth it for people new to color spaces to
> highlight the fact that RGB is not linear and what that means
> for operations like brightness or contrast change. I've seen a
> hobbyist write a 3D engine and after he had deferred
> rendering, flash lights & shadows, scripting and animations,
> he stumbled over an article about screen gamma and why it
> matters. My first attempts at image manipulation show the same
> ignorance.

I understand this pattern very, very well. I've worked in games my
whole career ;)
This is precisely why the std library needs to be batteries-included
with respect to knowledge about colourspaces and conversions, but that
doesn't mean every operation can do it properly behind the scenes.
Colours are a fairly low-level primitive, and appear in
low-level/high-frequency code. The std library offering wouldn't be
very useful if it were so slow from doing linear conversions every
time you do any operation. That's a lot of int<->float conversions,
and pow's!

I think the presence of all this colour space information as type
arguments should nudge users in the right direction. They'll be all
"I've never seen this parameter before..." and google it... maybe.
I don't think it's the std lib doco's job to give users a lesson in
colour theory...? :/

Re: colour lib

[Manu via Digitalmars-d]

On 2 September 2016 at 22:36, Steven Schveighoffer via Digitalmars-d
 wrote:
> On 8/31/16 1:58 AM, Manu via Digitalmars-d wrote:
>>
>> I have this implementation issue, which I'm having trouble applying
>> good judgement, I'd like to survey opinions...
>>
>> So, RGB colours depend on this 'normalised integer' concept, that is:
>>   unsigned: luminance = val / IntType.max
>>   signed: luminance = max(val / IntType.max, -1.0)
>>
>> So I introduce NormalizedInt(T), which does that.
>>
>> The question is, what should happen when someone does:
>>   NormalisedInt!ubyte nub;
>>   NormalizedInt!byte nb;
>
>
> Is it s or z ? :)

Oh piss off! ;)
I have to think *REALLY HARD* to write 'z', and when I type it without
thinking I accidentally write it correctly.
It's SO HARD to constantly spell wrong in this code!

Re: ADL

[Manu via Digitalmars-d]

On 3 September 2016 at 08:38, Walter Bright via Digitalmars-d
 wrote:
> On 9/2/2016 5:15 AM, Manu via Digitalmars-d wrote:
>>
>> In C++, there is this ADL thing (argument dependent lookup).
>
>
> Yeah, I know about Koening lookup. It was a hack added to C++ to make
> operator overloading work.

Naturally you do, and I'm sure that is why it was invented, but you
couldn't write any modern C++ without it. The reason you say it was
invented is not the reason that it's useful.


>> D doesn't seem to have this,
>
>
> That's right, and it's on purpose :-)

And that seems to be a rather big problem.

The situation is this:
In D, it is ***EXTREMELY*** common to have some argument of type T,
like, basically everything in D is a template these days... we're
talking ranges and stuff.
It is also considered un-cool in modern D to aggregate all
functionality into types themselves. We want functionality for T to be
extensible, so we use UFCS all over the place.

Template args combined with UFCS practically demand ADL or something
similar to ADL, otherwise you can't really write algorithms. It's
impossible to import all the appropriate sources into the file that
implements the algorithm. They're unrelataed, except that the
algorithm is expected to 'work' on the T it's given. So if someone
supplies a T to your algorithm, and it's a range for instance (or
something following that pattern), and some part of it's
implementation is UFCS, it all falls apart :/

We can't have the situation "UFCS works quite nicely... in this
particular subset of common situations".


>> and that is proving to be quite problematic. What's the work around?
>
>
> Not a workaround, as D does not need ADL. This is how to do it:
>
> extern (C++, bob) {
>   struct S {}
>   void f(S s);
> }
>
> extern (C++, joe) {
>   struct T {}
>   void f(T t);
>
>   void test()
>   {
> T t;
> f(t); // obviously works, T is in the local namespace
>
> alias f = bob.f;  // bring bob.s into current scope
> bob.S s;
> f(s);  // no problemo
>   }
> }
>
>
> The 'alias' construct gives good control over which symbols are visible in
> which scopes.

Now to put it in the terms I describe above, 'test()' is an algorithm,
implemented in a module unrelated to bob or joe (I should have given
the example with test() outside the namespace)... the algorithm
implementation can't go aliasing or importing anything relating to its
possible arguments T or S; it's meant to be generic.

module bob;
struct S {}
void f(S s);

module joe;
struct T {}
void f(T t);

module myalgorithm;
void test(T)(T t)
{
  f(t);
}


module user_code;
import bob, joe;
void main()
{
  test(S.init);
  test(T.init);
}

This is a better example. I can't be invading test() with any aliases,
or imports. It wouldn't be an algorithm anymore if I did that.
This pattern seems to bite me every direction I turn when trying to
write range or algorithm style code. C++ has ADL, and ADL works. I've
never thought about this problem in C++, or had any problems with ADL.

Re: Quality of errors in DMD

[David Nadlinger via Digitalmars-d]

On Friday, 2 September 2016 at 22:12:20 UTC, Walter Bright wrote:

Compiling with -v will usually show how far the compiler got.


It's curious that this topic should come up now – just a couple 
of days ago, I thought about adding better user reporting for LDC 
ICEs.


What I was planning to do is to keep a global stack of locations 
(and symbols where applicable, to be able to print the name) that 
is updated as the AST is traversed during semantic and glue 
layer. This should be very cheap to do, especially since the 
information does not need to be perfect.


You can then install a custom assert/segfault handler to print 
that information to aid users in reducing a test case or working 
around the problem, even for hard crashes or ICEs. The location 
information needs to be just close enough that the user knows 
where to start looking if the error appears after a compiler 
upgrade or when writing template-heavy code.


 — David

Re: ADL

[Walter Bright via Digitalmars-d]

On 9/2/2016 5:15 AM, Manu via Digitalmars-d wrote:

In C++, there is this ADL thing (argument dependent lookup).


Yeah, I know about Koening lookup. It was a hack added to C++ to make operator 
overloading work.




D doesn't seem to have this,


That's right, and it's on purpose :-)



and that is proving to be quite problematic. What's the work around?


Not a workaround, as D does not need ADL. This is how to do it:

extern (C++, bob) {
  struct S {}
  void f(S s);
}

extern (C++, joe) {
  struct T {}
  void f(T t);

  void test()
  {
T t;
f(t); // obviously works, T is in the local namespace

alias f = bob.f;  // bring bob.s into current scope
bob.S s;
f(s);  // no problemo
  }
}


The 'alias' construct gives good control over which symbols are visible in which 
scopes.

Re: Quality of errors in DMD

[H. S. Teoh via Digitalmars-d]

On Fri, Sep 02, 2016 at 02:52:57PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
> I understand your concern, and that's why we put a priority on fixing
> asserts that are submitted to bugzilla. But without a bug report, we
> are completely dead in the water in fixing it. It is supposed to never
> happen, that is why we cannot fix them in advance.

What *would* help greatly is if, upon encountering an unexpected
problem, the compiler told the user something to the effect of "hey
there, I'm really sorry but apparently I've run into a problem I don't
know how to solve; could you please file a bug report at $URL so that
the compiler authors look into the problem?"  Instead of blurting out
something in encrypted Klingon that nobody understands, like
"backend/gjqzx.c 12345 phlebotinum overload".

OK, I exaggerate, but seriously, to anyone unfamiliar with compiler
internals, dmd asserts might as well be talking about phlebotinum
overloads and they couldn't tell the difference.  If the error message
isn't being helpful, the chances of a bug report being filed are pretty
low, which means the chances of the problem getting fixed is even lower.

I think this PR would go a long way at making dmd friendlier to new D
users, if we can figure out how to make it work for all asserts
including from C code:

https://github.com/dlang/dmd/pull/6103


> Using dustmite is a practical way to reduce the source code to a
> manageable size.

A user wouldn't even know what dustmite is, let alone that it exists and
is applicable to this situation, or where to find it and how to use it,
unless they were told. Preferably by the compiler before it terminates
with an assert error. ;-)


> Having a compiler stack trace or it dumping its internal variables is
> unlikely to help anyone but the compiler devs.
[...]

Stack traces or internal variable dumps are equally unhelpful as the
current phlebotinum overload abort messages.  What we need is for the
compiler to tell the user (1) this is a compiler bug, not some fault in
their own code; (2) where to report this bug so that there's actually a
chance the problem will get fixed; (3) what is dustmite, where to find
it, and how it would help in formulating a bug report. And optionally,
(4) where to go to ask for help if you really need to find some way to
work around a compiler bug and get your code working again (e.g.,
forum.dlang.org).

If I were to run some random program downloaded off the 'net and it came
back to me with:

phlebo/tinum.c 12345 zyxqwqyb error

with no information about (1), (2), or (3), chances are pretty high that
I would just delete the program and move on to something else. I
wouldn't bother spending the effort to find out where to file bug
reports, and the problem will likely go unfixed and it will continue to
turn off yet more would-be users.

We need to get PR 6103 off the ground.


T

-- 
Let's eat some disquits while we format the biskettes.

Re: Quality of errors in DMD

[Walter Bright via Digitalmars-d]

On 9/2/2016 2:54 PM, Chris Wright wrote:

The second and third would be greatly benefitted by the compiler attempting to
tell us where the problem was encountered. For instance, if the assert was
triggered while trying to generate code for function
dmud.eventqueue.EventQueue!(Fiber).scheduleNear, I would know to look first and
foremost at that function.


Compiling with -v will usually show how far the compiler got.

Re: Quality of errors in DMD

[Chris Wright via Digitalmars-d]

On Friday, 2 September 2016 at 21:16:02 UTC, Walter Bright wrote:
assert()s are there to check that impossible situations in the 
compiler don't actually happen. They are not for diagnosing 
errors in user code.


There are three things that will ideally happen when someone sees 
an assert:


* They'll submit a bug report to bugzilla.
* They'll come up with a reasonably simple test case to add to 
the bug report.
* They'll find an immediate workaround for their code so they can 
get on with their life and not have to wait until the next 
compiler release.


The second and third would be greatly benefitted by the compiler 
attempting to tell us where the problem was encountered. For 
instance, if the assert was triggered while trying to generate 
code for function 
dmud.eventqueue.EventQueue!(Fiber).scheduleNear, I would know to 
look first and foremost at that function.


Yes, if I'm rebuilding my code often, I'll be able to narrow 
things down automatically, but I'm not as virtuous as I would 
like. And with templates, things get harder.

Re: Quality of errors in DMD

[Walter Bright via Digitalmars-d]

On 9/2/2016 2:25 PM, Ethan Watson wrote:

On Friday, 2 September 2016 at 21:16:02 UTC, Walter Bright wrote:

assert()s are there to check that impossible situations in the compiler don't
actually happen. They are not for diagnosing errors in user code.

If a user sees an assert, it is a compiler bug and hopefully he'll submit a
bug report for it in bugzilla. There aren't many open assert bugs in bugzilla
because we usually put a priority on fixing them.


You know, I'd love to submit a bug about it. But after actually working out the
problem without the compiler's help, I can't get a minimal enough test case to
submit a bug with. I'll try it with Dustmite. But in this case, there's debug
code there to spit out the information it has. And probably a stack to give it
context.

This is legitimately the kind of stuff that drives an average user away from a
language. I knew that commenting out one template invocation fixed my code, but
not how to fix my template without a bunch of pain-staking removal and
experimentation.


I understand your concern, and that's why we put a priority on fixing asserts 
that are submitted to bugzilla. But without a bug report, we are completely dead 
in the water in fixing it. It is supposed to never happen, that is why we cannot 
fix them in advance.


Using dustmite is a practical way to reduce the source code to a manageable 
size.

Having a compiler stack trace or it dumping its internal variables is unlikely 
to help anyone but the compiler devs.



>  Call it what you want, but that's a bad user experience.

Yes it is, which is why we put a priority on fixing them.

Re: Quality of errors in DMD

[Ethan Watson via Digitalmars-d]

On Friday, 2 September 2016 at 21:16:02 UTC, Walter Bright wrote:
assert()s are there to check that impossible situations in the 
compiler don't actually happen. They are not for diagnosing 
errors in user code.


If a user sees an assert, it is a compiler bug and hopefully 
he'll submit a bug report for it in bugzilla. There aren't many 
open assert bugs in bugzilla because we usually put a priority 
on fixing them.


You know, I'd love to submit a bug about it. But after actually 
working out the problem without the compiler's help, I can't get 
a minimal enough test case to submit a bug with. I'll try it with 
Dustmite. But in this case, there's debug code there to spit out 
the information it has. And probably a stack to give it context.


This is legitimately the kind of stuff that drives an average 
user away from a language. I knew that commenting out one 
template invocation fixed my code, but not how to fix my template 
without a bunch of pain-staking removal and experimentation. Call 
it what you want, but that's a bad user experience.

Re: RFC: Fixing std.typecons.Typedef

[Meta via Digitalmars-d]

On Friday, 2 September 2016 at 19:40:52 UTC, Meta wrote:
I was thinking about how to fix Typedef the other day and came 
up with a way of generating a guaranteed unique ID for each 
instantiation, even if they are on the same line:


alias FixedTypedef(T, T init = T.init, string cookie = new 
class {}.stringof) = Typedef(T, init, cookie);


alias Test1 = FixedTypedef!int, Test2 = FixedTypedef!int;

assert(!is(Test1 == Test2)); //Passes

What I'd like to know is if there might be a better way of 
doing this. For each instantiation of FixedTypedef, there's a 
new class being created and stored in the executable (I think), 
as well as their .stringof. This could cause a lot of bloat if 
Typedef is being used heavily.


Furthermore, would this be considered a code breakage? Looking 
at http://dlang.org/phobos/std_typecons.html#.Typedef, it says:


"Typedef allows the creation of a unique type which is based on 
an existing type. Unlike the alias feature, Typedef ensures the 
two types are not considered as equals."


This implies that the current behaviour of Typedef is a bug, 
and thus fixing it would not be code breakage. However, people 
may have come to depend on this bug and fixing it would break 
code. Thirdly, there is no point in having Typedef behave as it 
currently does by default, which is similar to how aliases 
behave. Example:


alias NewDouble = Typedef!double;
assert(!is(NewDouble == double)); //Okay, not the same type as 
expected


alias NewInt1 = Typedef!int;
alias NewInt2 = Typedef!int;
assert(is(NewInt1 == NewInt2)); //Passes?!

Thoughts? Opinions? I think it'd be nice to have a typedef that 
works correctly by default.


Why did my auto-generated gravatar picture change?

Re: Quality of errors in DMD

[Walter Bright via Digitalmars-d]

On 9/2/2016 7:26 AM, Ethan Watson wrote:

That's 830 possible places where the compiler will give the user virtually no
help to track down what (if anything) they did wrong.


assert()s are there to check that impossible situations in the compiler don't 
actually happen. They are not for diagnosing errors in user code.


If a user sees an assert, it is a compiler bug and hopefully he'll submit a bug 
report for it in bugzilla. There aren't many open assert bugs in bugzilla 
because we usually put a priority on fixing them.

Using OpenGL

[Darren via Digitalmars-d-learn]

I'm trying to teach myself OpenGL but I'm not sure how to set it 
up exactly.
I used "dub init" to create a project, I downloaded glew32.dll 
and glfw.dll and put them in this folder.  I added 
"derelict-gl3": "~>1.0.19" and "derelict-glfw3": "~>3.1.0" to 
dependencies, and imported them in the app.d file.  I add the 
load() and reload() functions where appropriate (I assume).


I can run a simple window program and it seems to work fine, but 
I notice that's when all the functions begin with "glfw".  If I 
try to follow a tutorial for loading a triangle, I get errors 
when trying to build.


Do I need to link an opengl.dll file, too?

Re: Statistics functions

[jmh530 via Digitalmars-d]

On Friday, 2 September 2016 at 17:52:12 UTC, John Colvin wrote:


Short story: it doesn't have any explicit support. Ndslice is 
much newer than dstats.


The ndslice range interface should mean quite a lot of stuff 
will work anyway.


What I figured, thanks.

Re: Low level unit test library in druntime

[Dicebot via Digitalmars-d]

On Friday, 2 September 2016 at 19:26:41 UTC, Jacob Carlborg wrote:

On 2016-09-01 14:02, Dicebot wrote:

What would be different? List of unit test blocks available in 
the program?


How the unit tests are written and collected.

unittest { assert(true); }

class FooTest : Test
{
void testFoo() { assert(true); }
}

describe("foo", {
it("does something", {
assert(true);
});
});


Then we perfectly understand each other and I will vote against 
introducing any other way/syntax for writing _unit_ tests in D 
with all my passion.

Re: Hash table element existence check

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/2/16 3:38 PM, Illuminati wrote:

I am trying to create a hash table and would like an efficient way to be
able to know if an element exists to test for collisions.


You mean you are writing your own hash table, or you want to use a D 
hash table (associative array)?



I could keep a bitarray, but wasting around 12% space. I could use
pointers(null check) to elements but this creates fragmentation. It is
not terrible, just curious if anyone has a better way?


I'm not sure I understand the question. Hash tables have many many many 
different ways to implement. Obviously, marking empty buckets somehow is 
necessary.


-Steve

RFC: Fixing std.typecons.Typedef

[Meta via Digitalmars-d]

I was thinking about how to fix Typedef the other day and came up 
with a way of generating a guaranteed unique ID for each 
instantiation, even if they are on the same line:


alias FixedTypedef(T, T init = T.init, string cookie = new class 
{}.stringof) = Typedef(T, init, cookie);


alias Test1 = FixedTypedef!int, Test2 = FixedTypedef!int;

assert(!is(Test1 == Test2)); //Passes

What I'd like to know is if there might be a better way of doing 
this. For each instantiation of FixedTypedef, there's a new class 
being created and stored in the executable (I think), as well as 
their .stringof. This could cause a lot of bloat if Typedef is 
being used heavily.


Furthermore, would this be considered a code breakage? Looking at 
http://dlang.org/phobos/std_typecons.html#.Typedef, it says:


"Typedef allows the creation of a unique type which is based on 
an existing type. Unlike the alias feature, Typedef ensures the 
two types are not considered as equals."


This implies that the current behaviour of Typedef is a bug, and 
thus fixing it would not be code breakage. However, people may 
have come to depend on this bug and fixing it would break code. 
Thirdly, there is no point in having Typedef behave as it 
currently does by default, which is similar to how aliases 
behave. Example:


alias NewDouble = Typedef!double;
assert(!is(NewDouble == double)); //Okay, not the same type as 
expected


alias NewInt1 = Typedef!int;
alias NewInt2 = Typedef!int;
assert(is(NewInt1 == NewInt2)); //Passes?!

Thoughts? Opinions? I think it'd be nice to have a typedef that 
works correctly by default.

Hash table element existence check

[Illuminati via Digitalmars-d-learn]

I am trying to create a hash table and would like an efficient 
way to be able to know if an element exists to test for 
collisions.


I could keep a bitarray, but wasting around 12% space. I could 
use pointers(null check) to elements but this creates 
fragmentation. It is not terrible, just curious if anyone has a 
better way?

Re: Low level unit test library in druntime

[Jacob Carlborg via Digitalmars-d]

On 2016-09-01 14:02, Dicebot wrote:


What would be different? List of unit test blocks available in the program?


How the unit tests are written and collected.

unittest { assert(true); }

class FooTest : Test
{
void testFoo() { assert(true); }
}

describe("foo", {
it("does something", {
assert(true);
});
});

--
/Jacob Carlborg

OT: Anyone looking for compiler job?

[Dmitry Olshansky via Digitalmars-d]

I've come to appreciate the D NG as a source of wisdom on many topics 
including those outside of the D lang realm. As such I could have easily 
recommended many folks around here. My current employer is in active 
search of good candidates so I thought I'd spread the word.


Anyone interested in challenging job involving compilers, run-times and 
garbage collectors just to name a few - give me a ping at:

dmitry (dot) olsh (at) gmail (dot) com


Dmitry Olshansky

Re: Beta D 2.071.2-b3

[Basile B. via Digitalmars-d-announce]

On Friday, 2 September 2016 at 10:29:41 UTC, David Nadlinger 
wrote:

On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote:

On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
std.traits wrappers should use __traits to build *safe* 
things (declaring that @trusted in the end).


This has nothing to do with memory safety.


Actually it does, albeit somewhat tangentially: Accessing 
private members from the outside must be @system since the 
@trusted implementation of a class might rely on nobody 
meddling with the private state.


 — David


The essence of the problem is that an aggregate cannot fully 
introspect itself using a template located in another module. If 
the @system constraint is only for the private members then it's 
ok.

Re: Quality of errors in DMD

[H. S. Teoh via Digitalmars-d]

On Fri, Sep 02, 2016 at 08:43:30PM +0300, Dicebot via Digitalmars-d wrote:
> On 09/02/2016 06:45 PM, Wyatt wrote:
> > On the other, though, considering he's been using DMD for years and
> > didn't know that, I think there's a cogent argument for improving
> > even ICE messages.  At the least, have them print "Internal Compiler
> > Error".
> 
> Great idea, I hacked a quick implementation to make all asserts to
> direct to bugzilla: https://github.com/dlang/dmd/pull/6103

Very nice. But currently only works with asserts from D code, whereas
most of the ICE's I found on bugzilla come from C code (backend or glue
layer).

I think it should be possible to "hijack" the C assert() by replacing
all instances of #include  with something else that redirects
the call to a custom function, perhaps one that calls the D assert
handler.

(Or, failing that, we can use an IOCCC-style hack of re-#define-ing the
assert macro to something else after the fact. Thankfully the C/C++
assert isn't a keyword, so it's easier to hijack. :-P)

There's also util_assert() in backend/util2.c, which can also be
redirected this way.


T

-- 
WINDOWS = Will Install Needless Data On Whole System -- CompuMan

[Issue 12929] Empty union followed by field causes ICE due to offset of 0.

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #2 from hst...@quickfur.ath.cx ---
Doesn't happen on git HEAD anymore (at least not with the code posted here).
Has recent compiler changes obscured this bug?

--

Re: Quality of errors in DMD

[John Colvin via Digitalmars-d]

On Friday, 2 September 2016 at 14:26:37 UTC, Ethan Watson wrote:
Can we have a serious discussion in here about the quality of 
DMD errors?


I've been alternately a dog chasing its own tail, and a dog 
barking at a fire hydrant, chasing down errors deep in 
templated and mixin code over the last day. This has resulted 
in manually reducing templates and mixins by hand until I get 
to the root of the problem, which then results in submitting a 
bug and devising an ugly workaround.


And then I get this one in some code:

Assertion failure: '0' on line 1492 in file 'glue.c'

The problem ended up being that a symbol tucked away in a 
template that itself was tucked away in a template was 
undefined, but it couldn't tell me that. Rather, it just 
assert(0)'d and terminated. Rather less helpfully, the only 
meaningful information it could give me at the assert point 
(Could it add to it further down the stack? Maybe?) was defined 
out because DMD wasn't in a debug build.


Honestly, I find stuff like this in a compiler unacceptable. 
Using assert(0) as shorthand for an unexpected error is all 
fine and dandy until you put your product in the hands of the 
masses and they expect your program to at least give you some 
idea of what was going wrong rather than just crashing out in 
flames.


So just for fun, I searched DMD for all instances of assert(0) 
in the code base.


830 matches in DMD 2.070.2.

That's 830 possible places where the compiler will give the 
user virtually no help to track down what (if anything) they 
did wrong.


DMD certainly isn't the only compiler guilty of this. The .NET 
compiler gives precisely no useful information if it encounters 
SSE types in C++ headers for example. But compared to MSVC, 
I've found the error reporting of DMD to be severely lacking. 
In most cases with MSVC, I have an error code that I can google 
for which is (sometimes) thoroughly documented. And thanks to 
being a widely used product, Stack Overflow usually gives me 
results that I can use in my sleuthing.


I know I'm also seeing more errors than most because I'm doing 
the kind of code most people don't do. But I'm certainly of the 
opinion that searching for a compiler error code is far easier 
than trying to trick google in to matching the text of my error 
message.


ICEs like that are always, always compiler bugs. It would be good 
if it said that in the message and told you to report it...

[Issue 14537] Declaring an extern(C++) function in a variadic function template results in an ICE.

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #1 from hst...@quickfur.ath.cx ---
Can't reproduce on dmd git HEAD (d4b055cd92a63688a2c3bd9e1cc11ba90a0a9d1a).
Maybe this has been fixed since?

--

Re: Statistics functions

[John Colvin via Digitalmars-d]

On Friday, 2 September 2016 at 14:40:36 UTC, jmh530 wrote:

On Friday, 2 September 2016 at 14:37:55 UTC, jmh530 wrote:
On Thursday, 1 September 2016 at 23:44:15 UTC, John Colvin 
wrote:


Now with actually working API docs: 
https://dlangscience.github.io/dstats/api/


That makes me happy!


It occurs to me that I don't know how much dstats works with 
ndslices?


Short story: it doesn't have any explicit support. Ndslice is 
much newer than dstats.


The ndslice range interface should mean quite a lot of stuff will 
work anyway.

Re: opAssign return type

[Q. Schroll via Digitalmars-d-learn]

On Friday, 2 September 2016 at 17:33:22 UTC, Steven Schveighoffer 
wrote:

On 9/2/16 1:18 PM, Q. Schroll wrote:
When overloading assignment, I've been taught in my C++ course 
to return
a reference to the lvalue being assigned to. This is easily 
possible in
D, but in Phobos it is used rarely and in Ali Çehreli's Book 
it is

neither taught to do so.


Sure, you can do this.

Is there any reason to it? To me it seems very obvious to do 
it like in

C++.


I can imagine a reason is to avoid issues with lifetime. It's 
dangerous to return this as a reference in most cases, because 
this is implicitly passed by reference even for rvalues.


However, for opAssign, you generally are sure you don't have an 
rvalue.


Interestingly the compiler does not allow rvalue = expr but it 
does however allow rvalue.opAssign(expr).


In any case, there's nothing wrong with it technically, it 
should work.


-Steve


There is no possibility to enforce some method is only available 
for lvalue this?

[Issue 16461] Using the fully qualified type of an object within its own scope causes an error

[via Digitalmars-d-bugs]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com

--- Comment #1 from ag0ae...@gmail.com ---
I can't reproduce this with 2.071.1. What version of dmd are you using exactly?
Do you just run `dmd -c thismodule.d` or do you use any additional compiler
switches?

--

Re: Quality of errors in DMD

[Dicebot via Digitalmars-d]

On 09/02/2016 06:45 PM, Wyatt wrote:
> On the other, though, considering he's been using DMD for years and
> didn't know that, I think there's a cogent argument for improving even
> ICE messages.  At the least, have them print "Internal Compiler Error".

Great idea, I hacked a quick implementation to make all asserts to
direct to bugzilla: https://github.com/dlang/dmd/pull/6103



signature.asc
Description: OpenPGP digital signature

Re: colour lib

[Marco Leise via Digitalmars-d]

Am Fri, 2 Sep 2016 15:58:05 +1000
schrieb Manu via Digitalmars-d :

> On 2 September 2016 at 06:09, Marco Leise via Digitalmars-d
>  wrote:
> > I'd suspect #1 to be the best option, too. However, I don't
> > know when users will deal with these calculations.  
> 
> Neither do I, it's just that NormalizedInt is a type, it's a
> dependency, it exists, it needs an api, so it needs to be well defined
> I guess.

*nods*

> I wonder, should NormalizedInt be a module beneath the color package,
> or should it be a separate module in its own right?
> I don't know of uses for that type outside packed colours, but it
> could theoretically be used for anything...

I guess audio sample would be a perfect match for signed and
unsigned normalized integers.
 
> > Surely adding sRGB(22,22,22) + sRGB(11,11,11) gives sRGB(28, 28, 28),
> > with a higher precision while performing the addition and then
> > rounding back.  
> 
> Umm, no. I think operations should be within their own colourspace,
> otherwise what's the point of selecting your working colourspace?
> You need to be able to do operations in gamma space too. If you want
> to do a linear operation, cast to a linear type before doing the
> operation.

So it is not a library that unifies color spaces into working
with light intensities, but more of a library to perform
linear blending directly in the color-space.
That means when I add two HSV colors of the same ubyte hue
= 200, the result will have hue == 144, right ?
 
> > Anything requiring multiple operations on an
> > image should use a higher precision linear color space from
> > the start.  
> 
> Right, I think you would typically cast from the storage type to the
> working type before doing some work. But there are so many cases, and
> various levels of tradeoff between efficiency and correct-ness, the
> lib can't make presumptions.
> The way it is currently, the operations are done in the typed
> colourspace. Simple as that. If you want to do linear operations, cast
> to a linear type first.

Ok, might be worth it for people new to color spaces to
highlight the fact that RGB is not linear and what that means
for operations like brightness or contrast change. I've seen a
hobbyist write a 3D engine and after he had deferred
rendering, flash lights & shadows, scripting and animations,
he stumbled over an article about screen gamma and why it
matters. My first attempts at image manipulation show the same
ignorance.

-- 
Marco

Re: opAssign return type

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/2/16 1:18 PM, Q. Schroll wrote:

When overloading assignment, I've been taught in my C++ course to return
a reference to the lvalue being assigned to. This is easily possible in
D, but in Phobos it is used rarely and in Ali Çehreli's Book it is
neither taught to do so.


Sure, you can do this.



Is there any reason to it? To me it seems very obvious to do it like in
C++.


I can imagine a reason is to avoid issues with lifetime. It's dangerous 
to return this as a reference in most cases, because this is implicitly 
passed by reference even for rvalues.


However, for opAssign, you generally are sure you don't have an rvalue.

In any case, there's nothing wrong with it technically, it should work.

-Steve

[Issue 15875] "d o(int[a]a)(){}" causes DMD segfault

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #2 from hst...@quickfur.ath.cx ---
This is caused by an infinite recursion ddmd.mtype.semanticLength ->
VarExp::semantic -> TypeAArray::semantic -> TypeSArray::semantic ->
ddmd.mtype.semanticLength.  Probably due to the construct `int[a] a` which
depends upon itself.

--

opAssign return type

[Q. Schroll via Digitalmars-d-learn]

When overloading assignment, I've been taught in my C++ course to 
return a reference to the lvalue being assigned to. This is 
easily possible in D, but in Phobos it is used rarely and in Ali 
Çehreli's Book it is neither taught to do so.


Is there any reason to it? To me it seems very obvious to do it 
like in C++.


The question came up in the discussion of a PR:
https://github.com/dlang/dlang.org/pull/1466

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

[via Digitalmars-d-bugs]

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

--- Comment #6 from hst...@quickfur.ath.cx ---
P.S. The faulty call to freenode() comes from codelem() in cgcod.c.

--

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 CC||bugzi...@digitalmars.com

--

Re: Is it a bug in unittest ?

[ZombineDev via Digitalmars-d]

On Thursday, 1 September 2016 at 18:11:55 UTC, angel wrote:
If one creates a unittest block in a templated class (or 
struct), the unittest block will be multiplied per class 
specialization, which might turn out to be quite large number.


E.g.
 struct A(T) {
 ...
 unittest {
 ...
 }
 }

 ...

 auto a = A!int;
 auto b = A!int;
 auto c = A!double;

The unittest block will be instantiated twice (per A!int and 
A!double).
But in some (many ?) cases unittest doesn't even exercise the 
generics, merely using some particular type.


What is it, a bug ?


Not a bug. Everything inside a template get copied for each 
template instantiation. It would strange if there were 
exceptions. That doesn't mean that it is an intentional feature. 
See http://wiki.dlang.org/DIP82.

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

[via Digitalmars-d-bugs]

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

--- Comment #5 from hst...@quickfur.ath.cx ---
I managed to trace the error to freenode() in backend/cgcod.c, for some reason
it gets called with an elem with e->Ecomsub==0, so when it tries to decrement
it, e->Ecomsub rolls over to 255, which eventually triggers this assert.

However, I couldn't figure out enough of the backend code to actually fix this.
I tried changing the if-statement in freenode() to `if (e->Ecomsub==0 ||
e->Ecomsub--) return;`, and it works for this particular test case, but then it
fails to compile the d_do_test tool, so obviously this is the wrong fix. So
this will probably need Walter to look at it. :-P

--

Re: colour lib

[Marco Leise via Digitalmars-d]

> Is it s or z ? :)

It's an alias to forego any language bike shedding.

Re: ADL

[Cauterite via Digitalmars-d]

On Friday, 2 September 2016 at 12:15:25 UTC, Manu wrote:




The only problem I have with this feature is that it would lead 
to implicit-importation, which is a totally foreign concept in D, 
and I would assume a design choice to not support it.


import bob : S;
S s;
// implicit `import bob : f;` for this statement:
f(s);

Is this an acceptable feature? Perhaps; my main concern is that 
it can be very difficult to work out where this `f` symbol is 
coming from. If you see the only import statement is `import bob 
: S;` then you'd naturally assume that the `f` being called here 
is not `bob.f`.


It's nice to learn this term "argument dependent lookup" though. 
I've spent a lot of time thinking about this feature, but never 
realised it had a name (and I never realised any languages 
supported it).

[Issue 16107] [ICE] - Internal error: backend/cgcod.c 2297

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--

[Issue 16237] Some DMD Assertion Failures

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

 CC||hst...@quickfur.ath.cx

--- Comment #1 from hst...@quickfur.ath.cx ---
Can't reproduce on git HEAD. Tested on Linux/64. Perhaps this has been fixed
since?

--

Re: Quality of errors in DMD

[Wyatt via Digitalmars-d]

On Friday, 2 September 2016 at 15:12:48 UTC, Steven Schveighoffer 
wrote:


This is an internal compiler error. It's not a standard way of 
reporting errors in D code. It means the internal state of the 
compiler is messed. Not much the compiler can do except crash.


On one hand, it's encouraging that he's been using DMD for years 
and didn't know that.


On the other, though, considering he's been using DMD for years 
and didn't know that, I think there's a cogent argument for 
improving even ICE messages.  At the least, have them print 
"Internal Compiler Error".


Taking it further, maybe actually point out that we'd appreciate 
this being reported at $URL with an "ice" tag and dustmite'd 
reduction.  Roll more details into a "So You Found an ICE" wiki 
tutorial for the people who have (understandably) never done this 
before (and link it in the error output as well).


-Wyatt

Re: Quality of errors in DMD

[kink via Digitalmars-d]

On Friday, 2 September 2016 at 14:26:37 UTC, Ethan Watson wrote:
But compared to MSVC, I've found the error reporting of DMD to 
be severely lacking. In most cases with MSVC, I have an error 
code that I can google for which is (sometimes) thoroughly 
documented.


You're not really comparing DMD to MSVC, are you? ;) Imagine how 
DMD looked like if there was comparable financial backing...


Anyway, we all know that error reporting can be much improved, 
but complaining about it doesn't really help (at best, it moves 
that item up a bit on the mental agenda of some contributors) - 
getting yourself involved does.

Re: Quality of errors in DMD

[Steven Schveighoffer via Digitalmars-d]

On 9/2/16 10:26 AM, Ethan Watson wrote:

Can we have a serious discussion in here about the quality of DMD errors?

I've been alternately a dog chasing its own tail, and a dog barking at a
fire hydrant, chasing down errors deep in templated and mixin code over
the last day. This has resulted in manually reducing templates and
mixins by hand until I get to the root of the problem, which then
results in submitting a bug and devising an ugly workaround.

And then I get this one in some code:

Assertion failure: '0' on line 1492 in file 'glue.c'


This is an internal compiler error. It's not a standard way of reporting 
errors in D code. It means the internal state of the compiler is messed. 
Not much the compiler can do except crash.




The problem ended up being that a symbol tucked away in a template that
itself was tucked away in a template was undefined, but it couldn't tell
me that. Rather, it just assert(0)'d and terminated. Rather less
helpfully, the only meaningful information it could give me at the
assert point (Could it add to it further down the stack? Maybe?) was
defined out because DMD wasn't in a debug build.


What you need to do is submit a bug report with minimal example and tag 
as ice. It should have a high priority.




Honestly, I find stuff like this in a compiler unacceptable. Using
assert(0) as shorthand for an unexpected error is all fine and dandy
until you put your product in the hands of the masses and they expect
your program to at least give you some idea of what was going wrong
rather than just crashing out in flames.

So just for fun, I searched DMD for all instances of assert(0) in the
code base.

830 matches in DMD 2.070.2.

That's 830 possible places where the compiler will give the user
virtually no help to track down what (if anything) they did wrong.


But these are sanity checks on the compiler internal state. All the 
compiler can do is print that something is wrong and where it detected 
that. It can't diagnose the error because that assert is not supposed to 
happen!


-Steve

Re: [GSoC] Precise GC

[jmh530 via Digitalmars-d-announce]

On Friday, 2 September 2016 at 08:14:33 UTC, Rory McGuire wrote:


Can we rather just make a special tagged union that is 
scanned... rather avoid trying to make something that should be 
minimal more and more complex? The compiler already treats some 
parts of phobos as "special" as far as I know.


I had asked about unions in @safe code in other threads, but I 
don't recall anyone responding.


@safe functions cannot access unions with pointers or references 
overlapping with other types. In effect, there is already a 
special tagged union that can be scanned. I would think that the 
garbage collector already identifies these types of unions and 
doesn't just treat every union with the same conservative 
approach, but I have really no idea how it works and don't recall 
hearing back about my questions.


Anyway, with @safe unions, my thinking is that it would mean that 
the garbage collector can be made precise in @safe code in a way 
that it can't in @system code (assuming unions with pointers 
aren't snuck in through @trusted).

Re: Statistics functions

[jmh530 via Digitalmars-d]

On Friday, 2 September 2016 at 14:37:55 UTC, jmh530 wrote:
On Thursday, 1 September 2016 at 23:44:15 UTC, John Colvin 
wrote:


Now with actually working API docs: 
https://dlangscience.github.io/dstats/api/


That makes me happy!


It occurs to me that I don't know how much dstats works with 
ndslices?

Re: Statistics functions

[jmh530 via Digitalmars-d]

On Thursday, 1 September 2016 at 23:44:15 UTC, John Colvin wrote:


Now with actually working API docs: 
https://dlangscience.github.io/dstats/api/


That makes me happy!

Quality of errors in DMD

[Ethan Watson via Digitalmars-d]

Can we have a serious discussion in here about the quality of DMD 
errors?


I've been alternately a dog chasing its own tail, and a dog 
barking at a fire hydrant, chasing down errors deep in templated 
and mixin code over the last day. This has resulted in manually 
reducing templates and mixins by hand until I get to the root of 
the problem, which then results in submitting a bug and devising 
an ugly workaround.


And then I get this one in some code:

Assertion failure: '0' on line 1492 in file 'glue.c'

The problem ended up being that a symbol tucked away in a 
template that itself was tucked away in a template was undefined, 
but it couldn't tell me that. Rather, it just assert(0)'d and 
terminated. Rather less helpfully, the only meaningful 
information it could give me at the assert point (Could it add to 
it further down the stack? Maybe?) was defined out because DMD 
wasn't in a debug build.


Honestly, I find stuff like this in a compiler unacceptable. 
Using assert(0) as shorthand for an unexpected error is all fine 
and dandy until you put your product in the hands of the masses 
and they expect your program to at least give you some idea of 
what was going wrong rather than just crashing out in flames.


So just for fun, I searched DMD for all instances of assert(0) in 
the code base.


830 matches in DMD 2.070.2.

That's 830 possible places where the compiler will give the user 
virtually no help to track down what (if anything) they did wrong.


DMD certainly isn't the only compiler guilty of this. The .NET 
compiler gives precisely no useful information if it encounters 
SSE types in C++ headers for example. But compared to MSVC, I've 
found the error reporting of DMD to be severely lacking. In most 
cases with MSVC, I have an error code that I can google for which 
is (sometimes) thoroughly documented. And thanks to being a 
widely used product, Stack Overflow usually gives me results that 
I can use in my sleuthing.


I know I'm also seeing more errors than most because I'm doing 
the kind of code most people don't do. But I'm certainly of the 
opinion that searching for a compiler error code is far easier 
than trying to trick google in to matching the text of my error 
message.

Re: Fallback 'catch-all' template functions

[Xinok via Digitalmars-d]

On Thursday, 1 September 2016 at 05:37:50 UTC, Manu wrote:

So, consider a set of overloads:

  void f(T)(T t) if(isSomething!T) {}
  void f(T)(T t) if(isSomethingElse!T) {}
  void f(T)(T t) {}

I have a recurring problem where I need a fallback function 
like the bottom one, which should be used in lieu of a more 
precise match. This is obviously an ambiguous call, but this is 
a pattern that comes up an awful lot. How to do it in D?


I've asked this before, and people say:

  void f(T)(T t) if(!isSomething!T && !isSomethingElse!T) {}

Consider that more overloads are being introduced by users 
spread out across many modules that define their own kind of T; 
this solution is no good.


In the past, I have suggested using the "default" keyword to 
specify a fallback function of this kind. I think it's a useful 
pattern for generic algorithms that have optimized variants on 
specific types for performance.


   void f(T)(T t) if(isSomething!T) {}
   void f(T)(T t) if(isSomethingElse!T) {}
   void f(T)(T t) default {}

[Issue 16464] opCast doco is insufficient

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

   Keywords||pull, spec

--

[Issue 16464] opCast doco is insufficient

[via Digitalmars-d-bugs]

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

--- Comment #4 from Steven Schveighoffer  ---
PR: https://github.com/dlang/dlang.org/pull/1467

--

[Issue 16464] opCast doco is insufficient

[via Digitalmars-d-bugs]

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

--- Comment #3 from Steven Schveighoffer  ---
(In reply to Manu from comment #2)
> Compare that table to the table of binary operators immediately below.

Compare that to the table of slice operators above :)

I think actually, the table is a very obscure way to explain the rewrite, even
when it's consistent with some of the other tables.

I'll submit a strawman PR.

--

Re: Beta D 2.071.2-b3

[Chris Wright via Digitalmars-d-announce]

On Fri, 02 Sep 2016 09:40:56 +, ketmar wrote:

> On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote:
>> On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
>>> std.traits wrappers should use __traits to build *safe* things
>>> (declaring that @trusted in the end).
>>
>> This has nothing to do with memory safety.
> 
> i wonder who told you that @safe code is *only* about "memory safety".

Walter Bright, when @safe was being discussed, before it was implemented.

Re: [GSoC] Precise GC

[Guillaume Piolat via Digitalmars-d-announce]

On Friday, 2 September 2016 at 03:25:33 UTC, Jeremy DeHaan wrote:
Through the work I did and the research of a couple of GC 
topics, I discovered that I really enjoyed working on the 
garbage collector and I plan on continuing that. I was recently 
accepted to the University of Washington's computer science 
program and I am currently working on getting some independent 
study classes set up for future GC work. Once I have some 
better programming chops I'm hoping to help take D's GC to new 
heights.




Hey thanks a lot for working on this!

[Issue 16464] opCast doco is insufficient

[via Digitalmars-d-bugs]

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

--- Comment #2 from Manu  ---
Wow, you're right.
I didn't make any sense of that table at all.

Compare that table to the table of binary operators immediately below.
That inconsistency possibly lead me to overlook that table as noise.

Anyway, I don't think it's well expressed when I couldn't see it right in front
of my face! ;)

--

[Issue 16464] opCast doco is insufficient

[via Digitalmars-d-bugs]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #1 from Steven Schveighoffer  ---
The table does say, cast(T)u is rewritten to u.opCast!(T)()

Probably could be spelled out better to indicate that's the ONLY case where
opCast is used (aside from the boolean for if clauses)

--

Re: ADL

[Steven Schveighoffer via Digitalmars-d]

On 9/2/16 8:15 AM, Manu via Digitalmars-d wrote:

In C++, there is this ADL thing (argument dependent lookup).
What it does is, when searching for overloads, in addition to looking
in the local namespace, it also looks in the namespace of the function
arguments.

D doesn't seem to have this, and that is proving to be quite problematic.
What's the work around?

C++ example:

namespace bob {
  struct S {};
  void f(S s);
}

namespace joe {
  struct T {};
  void f(T t);

  void test()
  {
T t;
f(t); // obviously works, T is in the local namespace

bob::S s;
f(s); // local namespace can't see `void f(S)`, but given the
argument 's', which is typed bob::S, it will search the bob::
namespace for overloads of f(), so this code compiles successfully.
  }
}


I have the same configuration across 2 modules in D.
In one module, I receive the foreign modules type via template arg,
but I haven't imported that type's module, so when I try to call the
function it can't find the overload, because it's not imported, and it
doesn't search the argument type's module (ie, namespace) for
overloads.



This is a limitation, you can only use struct members given a type, you 
can't use UFCS functions or regular calls like the above. You need to 
import the module in the template *definition* file, which is problematic.


I think I remember seeing vibe.d do some funky shit to work around this, 
like getting the fully qualified name, and using string mixins to import 
the module that defines that type.


I think it would be nice to see this fixed, but I'm not sure of the 
implications.


One possibility:

import __traits(moduleOf, T);

Then you could do this import as a local import when you need it. Of 
course, this is not as nice as just having the compiler do this 
automatically.


-Steve

Re: ADL

[Dicebot via Digitalmars-d]

On 09/02/2016 03:15 PM, Manu via Digitalmars-d wrote:
> In C++, there is this ADL thing (argument dependent lookup).
> What it does is, when searching for overloads, in addition to looking
> in the local namespace, it also looks in the namespace of the function
> arguments.

AFAIR it is intentionally not supported to simplify symbol lookup rules.

> I have the same configuration across 2 modules in D.
> In one module, I receive the foreign modules type via template arg,
> but I haven't imported that type's module, so when I try to call the
> function it can't find the overload, because it's not imported, and it
> doesn't search the argument type's module (ie, namespace) for
> overloads.

Don't know about best practice but I tend to simply find the host module
for the argument and mixin the import for it inside the template to make
symbols directly available.



signature.asc
Description: OpenPGP digital signature

Re: colour lib

[Steven Schveighoffer via Digitalmars-d]

On 8/31/16 1:58 AM, Manu via Digitalmars-d wrote:

I have this implementation issue, which I'm having trouble applying
good judgement, I'd like to survey opinions...

So, RGB colours depend on this 'normalised integer' concept, that is:
  unsigned: luminance = val / IntType.max
  signed: luminance = max(val / IntType.max, -1.0)

So I introduce NormalizedInt(T), which does that.

The question is, what should happen when someone does:
  NormalisedInt!ubyte nub;
  NormalizedInt!byte nb;


Is it s or z ? :)


  auto r = nub + nb;

What is typeof(r)?

There are 3 options that stand out, and I have no idea which one is correct.
1. Compile error, mismatching NormalisedInt type arithmetic shouldn't
work; require explicit user intervention.
2. 'Correct' result, ie, lossless; is(typeof(r) ==
NormalisedInt!short). Promote to type that doesn't lose precision,
type conversion loses efficiency, but results always correct.
3. Do what normal int types do; is(typeof(r) == NormalisedInt!int) ie,
apply the normal integer arithmetic type promotion rules. Classic
pain-in-the-arse applies when implicitly promoted result is stored to
a lower-precision value. Probably also slow (even slower) than option
#2.

Are there other options?
I'm tempted by #1, but that will follow right through to the colour
implementation, which will lead to colour type cast's all over the
place.


In the case that you are unsure, #1 is the only one that leaves room to 
make a decision later. I think you should start with that and see what 
happens.


What may turn out to happen is that most people only use one type, and 
then casts aren't going to be a problem.


-Steve

Re: ADL

[David Nadlinger via Digitalmars-d]

On Friday, 2 September 2016 at 12:15:25 UTC, Manu wrote:
D doesn't seem to have this, and that is proving to be quite 
problematic. What's the work around?


Somehow pass in the required information along with the symbol, 
for example as a member function/alias or an UDA. It's hard to 
get more specific than that without a concrete example.


 — David

ADL

[Manu via Digitalmars-d]

In C++, there is this ADL thing (argument dependent lookup).
What it does is, when searching for overloads, in addition to looking
in the local namespace, it also looks in the namespace of the function
arguments.

D doesn't seem to have this, and that is proving to be quite problematic.
What's the work around?

C++ example:

namespace bob {
  struct S {};
  void f(S s);
}

namespace joe {
  struct T {};
  void f(T t);

  void test()
  {
T t;
f(t); // obviously works, T is in the local namespace

bob::S s;
f(s); // local namespace can't see `void f(S)`, but given the
argument 's', which is typed bob::S, it will search the bob::
namespace for overloads of f(), so this code compiles successfully.
  }
}


I have the same configuration across 2 modules in D.
In one module, I receive the foreign modules type via template arg,
but I haven't imported that type's module, so when I try to call the
function it can't find the overload, because it's not imported, and it
doesn't search the argument type's module (ie, namespace) for
overloads.

Re: @safe RCSlice with DIP1000 + runtime checks

[rikki cattermole via Digitalmars-d]

On 02/09/2016 11:18 PM, Nick Treleaven wrote:

Hi,
I've been working on a proof of concept Reference Counted Slice
container, based on the one in DIP1000. That one now has opAssign marked
@system, see:

https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#owning-containers

So I decided to make an RCSlice with a @safe opAssign (and @safe
destroy, std.algorithm.move). opIndex is no longer a direct member,
instead indexing RCSlice causes the compiler to create a RCRef temporary
struct (via alias this), which does have opIndex:

https://github.com/ntrel/stuff/blob/master/typecons/rcref.d

The temporary struct is a private type, returned as an rvalue, so can't
itself be passed by ref, so it should avoid the paired ref argument case
mentioned in the above DIP1000 link.

RCRef increments *RCSlice.count on construction and decrements on
destruction, but first checks that *count is > 1. If this fails, an
AssertError is thrown. When -noboundschecks is passed, the code assumes
no safety checks should be made for RCSlice and compiles out all the
additional counting code.

Of course it would be great to have compile-time checks, so I'm looking
forward to a DIP for that. But in the meantime this appears to show D
can have @safe ref-counting now that DIP1000 is underway.

Thoughts?


I've got a much more advanced memory management solution[0].
I'm waiting on DIP1000 implementation before implementing it into it.

But over all I quite like this type approach.

[0] 
https://github.com/rikkimax/alphaPhobos/blob/master/source/std/experimental/memory/managed.d#L255

Re: vibed.org is down

[Daniel Kozak via Digitalmars-d]

Dne 2.9.2016 v 13:26 Nemanja Boric via Digitalmars-d napsal(a):


On Friday, 2 September 2016 at 11:24:53 UTC, Nemanja Boric wrote:

On Friday, 2 September 2016 at 10:32:07 UTC, Daniel Kozak wrote:

web@WebCN:~ $ ping ipult.cz
PING ipult.cz.eurocloud.cn (14.215.133.119) 56(84) bytes of data.
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=1 ttl=64 
time=0.031 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=2 ttl=64 
time=0.035 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=3 ttl=64 
time=0.028 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=4 ttl=64 
time=0.028 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=5 ttl=64 
time=0.030 ms




Given that there are 6-7000km from China to Czech Republic, your 
internet connection seems to be way faster than speed of light :-).


Ah, this is actually pinging some host in China, not the CZ. Sorry!

This is better :)

web@WebCN:~ $ ping -s 65000 code.dlang.org
PING code.dlang.org (79.140.41.234) 65000(65028) bytes of data.
65008 bytes from rejectedsoftware.com (79.140.41.234): icmp_seq=1 ttl=50 
time=314 ms
65008 bytes from rejectedsoftware.com (79.140.41.234): icmp_seq=2 ttl=50 
time=314 ms
65008 bytes from rejectedsoftware.com (79.140.41.234): icmp_seq=4 ttl=50 
time=314 ms
65008 bytes from rejectedsoftware.com (79.140.41.234): icmp_seq=5 ttl=50 
time=314 ms
65008 bytes from rejectedsoftware.com (79.140.41.234): icmp_seq=6 ttl=50 
time=314 ms
65008 bytes from rejectedsoftware.com (79.140.41.234): icmp_seq=7 ttl=50 
time=314 ms



--- code.dlang.org ping statistics ---
7 packets transmitted, 6 received, 14% packet loss, time 6513ms
rtt min/avg/max/mdev = 314.219/314.405/314.653/0.736 ms
web@WebCN:~ $ ping -s 65000 mail.ipult.cz
PING mail.ipult.cz (37.205.11.135) 65000(65028) bytes of data.
65008 bytes from mail.ipult.cz (37.205.11.135): icmp_seq=1 ttl=47 
time=243 ms
65008 bytes from mail.ipult.cz (37.205.11.135): icmp_seq=2 ttl=47 
time=243 ms
65008 bytes from mail.ipult.cz (37.205.11.135): icmp_seq=3 ttl=47 
time=243 ms
65008 bytes from mail.ipult.cz (37.205.11.135): icmp_seq=4 ttl=47 
time=243 ms
65008 bytes from mail.ipult.cz (37.205.11.135): icmp_seq=5 ttl=47 
time=243 ms
65008 bytes from mail.ipult.cz (37.205.11.135): icmp_seq=6 ttl=47 
time=243 ms
65008 bytes from mail.ipult.cz (37.205.11.135): icmp_seq=7 ttl=47 
time=243 ms

^C
--- mail.ipult.cz ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6694ms
rtt min/avg/max/mdev = 243.269/243.377/243.423/0.591 ms

Re: vibed.org is down

[Daniel Kozak via Digitalmars-d]

Wow :D, you are right


Dne 2.9.2016 v 13:24 Nemanja Boric via Digitalmars-d napsal(a):

On Friday, 2 September 2016 at 10:32:07 UTC, Daniel Kozak wrote:

web@WebCN:~ $ ping ipult.cz
PING ipult.cz.eurocloud.cn (14.215.133.119) 56(84) bytes of data.
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=1 ttl=64 
time=0.031 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=2 ttl=64 
time=0.035 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=3 ttl=64 
time=0.028 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=4 ttl=64 
time=0.028 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=5 ttl=64 
time=0.030 ms




Given that there are 6-7000km from China to Czech Republic, your 
internet connection seems to be way faster than speed of light :-).

Re: vibed.org is down

[Nemanja Boric via Digitalmars-d]

On Friday, 2 September 2016 at 11:24:53 UTC, Nemanja Boric wrote:

On Friday, 2 September 2016 at 10:32:07 UTC, Daniel Kozak wrote:

web@WebCN:~ $ ping ipult.cz
PING ipult.cz.eurocloud.cn (14.215.133.119) 56(84) bytes of 
data.
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=1 
ttl=64 time=0.031 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=2 
ttl=64 time=0.035 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=3 
ttl=64 time=0.028 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=4 
ttl=64 time=0.028 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=5 
ttl=64 time=0.030 ms




Given that there are 6-7000km from China to Czech Republic, 
your internet connection seems to be way faster than speed of 
light :-).


Ah, this is actually pinging some host in China, not the CZ. 
Sorry!

Re: vibed.org is down

[Nemanja Boric via Digitalmars-d]

On Friday, 2 September 2016 at 10:32:07 UTC, Daniel Kozak wrote:

web@WebCN:~ $ ping ipult.cz
PING ipult.cz.eurocloud.cn (14.215.133.119) 56(84) bytes of 
data.
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=1 
ttl=64 time=0.031 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=2 
ttl=64 time=0.035 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=3 
ttl=64 time=0.028 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=4 
ttl=64 time=0.028 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=5 
ttl=64 time=0.030 ms




Given that there are 6-7000km from China to Czech Republic, your 
internet connection seems to be way faster than speed of light 
:-).

@safe RCSlice with DIP1000 + runtime checks

[Nick Treleaven via Digitalmars-d]

Hi,
I've been working on a proof of concept Reference Counted Slice 
container, based on the one in DIP1000. That one now has opAssign 
marked @system, see:


https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#owning-containers

So I decided to make an RCSlice with a @safe opAssign (and @safe 
destroy, std.algorithm.move). opIndex is no longer a direct 
member, instead indexing RCSlice causes the compiler to create a 
RCRef temporary struct (via alias this), which does have opIndex:


https://github.com/ntrel/stuff/blob/master/typecons/rcref.d

The temporary struct is a private type, returned as an rvalue, so 
can't itself be passed by ref, so it should avoid the paired ref 
argument case mentioned in the above DIP1000 link.


RCRef increments *RCSlice.count on construction and decrements on 
destruction, but first checks that *count is > 1. If this fails, 
an AssertError is thrown. When -noboundschecks is passed, the 
code assumes no safety checks should be made for RCSlice and 
compiles out all the additional counting code.


Of course it would be great to have compile-time checks, so I'm 
looking forward to a DIP for that. But in the meantime this 
appears to show D can have @safe ref-counting now that DIP1000 is 
underway.


Thoughts?

[Issue 16464] New: opCast doco is insufficient

[via Digitalmars-d-bugs]

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

  Issue ID: 16464
   Summary: opCast doco is insufficient
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

opCast doco is not very helpful:
http://dlang.org/spec/operatoroverloading.html#cast

This says something about 'bool', but nothing about any other type.
When is the cast operator invoked? What circumstances will it be used?
Is opCast only explicit, or will it be used for implicit casts?
What happens if the src has an opCast, and the target type has a constructor
that receives the src type? In that situation, when will the opCast be used,
and when will the constructor be used?

--

[Issue 16462] mixin template ddoc doesn't appear in docs

[via Digitalmars-d-bugs]

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

Manu  changed:

   What|Removed |Added

   Hardware|x86_64  |All
 OS|Windows |All

--- Comment #1 from Manu  ---
eg:

mixin template Test(T)
{
  /** doco */
  T member;
}

/** My struct */
struct S
{
  mixin Test!int;
}


'member' is not documented.

--

[Issue 16462] New: mixin template ddoc doesn't appear in docs

[via Digitalmars-d-bugs]

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

  Issue ID: 16462
   Summary: mixin template ddoc doesn't appear in docs
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: turkey...@gmail.com

I have a mixin template, which I mixin to various structs. The mixin introduces
a member, and there is ddoc for the member present inside the mixin template.
Sadly, this doesn't seem to do anything.

Expect: ddoc for the member declared inside mixin template should appear in the
documentation of the type that mixes it in. It is after all a member of that
type.

--

Re: vibed.org is down

[Daniel Kozak via Digitalmars-d]

Dne 2.9.2016 v 12:20 Sönke Ludwig via Digitalmars-d napsal(a):


Am 02.09.2016 um 09:48 schrieb Daniel Kozak via Digitalmars-d:

Dne 2.9.2016 v 09:39 wobbles via Digitalmars-d napsal(a):


On Friday, 2 September 2016 at 07:23:51 UTC, Mike Parker wrote:

On Friday, 2 September 2016 at 07:02:20 UTC, finalpatch wrote:



Probably not good for publicity.


meh. It's the internet. Sometimes servers go down.


code.dlang.org is down too :-(

Maybe we should have multiple hostings? For example one in US and one in
Europe ;).


At least for code.dlang.org it would be nice to have a backup server - 
ideally somewhere with a good connection to China. We need to 
implement a mirror mode for that.


Our company has VPS in China and I have VPS in Czech republic, and it 
seems there is a good connection to it from china:


#ping from our china server to mine VPS
web@WebCN:~ $ ping ipult.cz
PING ipult.cz.eurocloud.cn (14.215.133.119) 56(84) bytes of data.
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=1 ttl=64 
time=0.031 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=2 ttl=64 
time=0.035 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=3 ttl=64 
time=0.028 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=4 ttl=64 
time=0.028 ms
64 bytes from mail.eurocloud.cn (14.215.133.119): icmp_seq=5 ttl=64 
time=0.030 ms


#ping from our china server to code.dlang.org
web@WebCN:~ $ ping code.dlang.org
PING code.dlang.org (79.140.41.234) 56(84) bytes of data.
64 bytes from rejectedsoftware.com (79.140.41.234): icmp_seq=1 ttl=50 
time=302 ms
64 bytes from rejectedsoftware.com (79.140.41.234): icmp_seq=2 ttl=50 
time=303 ms
64 bytes from rejectedsoftware.com (79.140.41.234): icmp_seq=3 ttl=50 
time=302 ms
64 bytes from rejectedsoftware.com (79.140.41.234): icmp_seq=4 ttl=50 
time=302 ms
64 bytes from rejectedsoftware.com (79.140.41.234): icmp_seq=5 ttl=50 
time=302 ms

Re: Beta D 2.071.2-b3

[David Nadlinger via Digitalmars-d-announce]

On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote:

On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
std.traits wrappers should use __traits to build *safe* things 
(declaring that @trusted in the end).


This has nothing to do with memory safety.


Actually it does, albeit somewhat tangentially: Accessing private 
members from the outside must be @system since the @trusted 
implementation of a class might rely on nobody meddling with the 
private state.


 — David

Re: Classes and Structs, Memory management questions

[Andrea Fontana via Digitalmars-d-learn]

On Friday, 2 September 2016 at 08:43:45 UTC, dom wrote:
from what i got Classes are always reference types and structs 
are value types in D. i am wondering why that is. for me the 
main difference between classes and structs is not how they are 
allocated, but that one has inhertiance, and the other hasn't.


It depends by language you're using. In C++, for example you can 
inherit both! The only difference AFAIK is that c++ structs has 
public default inheritance vs private for classes.


Andrea

Re: vibed.org is down

[Sönke Ludwig via Digitalmars-d]

Am 02.09.2016 um 09:48 schrieb Daniel Kozak via Digitalmars-d:

Dne 2.9.2016 v 09:39 wobbles via Digitalmars-d napsal(a):


On Friday, 2 September 2016 at 07:23:51 UTC, Mike Parker wrote:

On Friday, 2 September 2016 at 07:02:20 UTC, finalpatch wrote:



Probably not good for publicity.


meh. It's the internet. Sometimes servers go down.


code.dlang.org is down too :-(

Maybe we should have multiple hostings? For example one in US and one in
Europe ;).


At least for code.dlang.org it would be nice to have a backup server - 
ideally somewhere with a good connection to China. We need to implement 
a mirror mode for that.

Re: Equivalent of FirstOrDefault with ranges

[Nicholas Wilson via Digitalmars-d-learn]

On Friday, 2 September 2016 at 06:56:07 UTC, Lutger wrote:
I was looking for something like FirstOrDefault* from .NET in 
phobos. For example, I have this piece of code:


string findBobOrReturnNull(string[] names)
{
auto r = names.find("bob");
if(r.empty) return null;
return r.front;
}

assert(findBobOrReturnNull(["alice", "bob"]) == "bob");
assert(findBobOrReturnNull(["alice"]) is null);

How can I turn that into something like this, or is there 
another idiomatic way to write it as a single expression?


string findBobOrReturnNull(string[] names)
{
return names.find("bob").firstOrDefault;
}

* 
https://msdn.microsoft.com/en-us/library/bb340482%28v=vs.110%29.aspx


ElementType!R firstOrDefault(R)(R r, ElementType!R def = 
(ElementType!R).init)

   if(isInputRange!R)
{
if(r.empty) return def;
return r.front;
}

Re: Beta D 2.071.2-b3

[Rory McGuire via Digitalmars-d-announce]

On Fri, Sep 2, 2016 at 10:15 AM, ketmar via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Friday, 2 September 2016 at 07:46:30 UTC, Rory McGuire wrote:
> actually, from my PoV solution is supereasy: just remove ALL visibility
> restrictions for traits. and i mean all. allMembers should return all
> members, getMember should allow to access *any* existing member without
> annoying messages. it is up to programmer to insert getProtection checks if
> he needs it.
>
> traits is a low-level feature by definition, and doesn't meant to be used
> directly (we have std.traits wrappers for that), so i want D devs to stop
> making our, low-level coders, life harder than it is now. ;-)
>
> D devs just should draw the line between __traits and std.traits. first
> sould be inherently unsafe, allow *everything* and impose as little
> restrictions as it is possible (note: *as* *possible*, not *as* *sane* --
> all kind of insanity should be allowed, if it is possible). then,
> std.traits wrappers should use __traits to build *safe* things (declaring
> that @trusted in the end).
>


May our benevolent dictators agree with you :D (I do).

If a developer is willing to research the language definition and discover
__traits, you should be ready for unprotected intimacy with the hardware of
your choice. And if someone just copy pastes code with __traits in it they
should know that "__" in a symbol is a "WARNING here be dragons"

Re: Classes and Structs, Memory management questions

[Mike Parker via Digitalmars-d-learn]

On Friday, 2 September 2016 at 08:43:45 UTC, dom wrote:
from what i got Classes are always reference types and structs 
are value types in D. i am wondering why that is. for me the 
main difference between classes and structs is not how they are 
allocated, but that one has inhertiance, and the other hasn't. 
Supporting inheritance has some overhead, so at least the split 
between classes and structs makes sense to me.




How instances in an inheritance tree are allocated is actually an 
important consideration, particularly when it comes to object 
slicing. In C++, this can be a problem:


```
class Foo {};
class Bar : public Foo {};

Bar bar;
Foo foo = bar;
```

All of the information about the type Bar is lost in the 
assignment to foo. The same thing is going to happen when passing 
bar to a function that takes a Foo by value as a parameter. The 
only way to avoid the problem is to pass by reference (or 
pointer). In Modern C++, with move semantics being a thing, 
passing by value is much more common than it used to be, but this 
is the sort of thing it's easy either not to know or to forget 
about. In D, you don't have to worry about it.


I read somewhere (in old forum discussions or an old article) 
that object slicing is one of the motivations behind the 
distinction in D.

Re: Beta D 2.071.2-b3

[ketmar via Digitalmars-d-announce]

On Friday, 2 September 2016 at 08:57:14 UTC, Basile B. wrote:

On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
std.traits wrappers should use __traits to build *safe* things 
(declaring that @trusted in the end).


This has nothing to do with memory safety.


i wonder who told you that @safe code is *only* about "memory 
safety".

Re: Classes and Structs, Memory management questions

[dom via Digitalmars-d-learn]

On Friday, 2 September 2016 at 08:59:38 UTC, Andrea Fontana wrote:

On Friday, 2 September 2016 at 08:54:33 UTC, dom wrote:
i haven't read it fully yet, but i think this DIP contains 
some or all of my concerns

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


Check this:
https://dlang.org/phobos/std_experimental_allocator.html


thx that is very interesting. it seems like that can cover very 
complex allocation schemes with a general interface!


i have also found this to allocate a class on the stack
http://dlang.org/phobos/std_typecons.html#.scoped
class A { ... }
auto instance = scoped!A();

that has even quite a nice syntax!

Re: Beta D 2.071.2-b3

[Basile B. via Digitalmars-d-announce]

On Friday, 2 September 2016 at 08:15:53 UTC, ketmar wrote:
std.traits wrappers should use __traits to build *safe* things 
(declaring that @trusted in the end).


This has nothing to do with memory safety. It's just that 
protection attributes were invented for OOP and when applied to 
template meta programming they suck a bit.

Re: Classes and Structs, Memory management questions

[Andrea Fontana via Digitalmars-d-learn]

On Friday, 2 September 2016 at 08:54:33 UTC, dom wrote:
i haven't read it fully yet, but i think this DIP contains some 
or all of my concerns

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


Check this:
https://dlang.org/phobos/std_experimental_allocator.html

Re: Classes and Structs, Memory management questions

[dom via Digitalmars-d-learn]

i haven't read it fully yet, but i think this DIP contains some 
or all of my concerns

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

Re: Equivalent of FirstOrDefault with ranges

[Cauterite via Digitalmars-d-learn]

On Friday, 2 September 2016 at 06:56:07 UTC, Lutger wrote:




You could do:
names.find("bob").chain(only(``)).front;
It's not very expressive though.

Classes and Structs, Memory management questions

[dom via Digitalmars-d-learn]

from what i got Classes are always reference types and structs 
are value types in D. i am wondering why that is. for me the main 
difference between classes and structs is not how they are 
allocated, but that one has inhertiance, and the other hasn't. 
Supporting inheritance has some overhead, so at least the split 
between classes and structs makes sense to me.


I like garbage collection, but in many cases it's just 
unnecessary (like in the example below) or hurts performance on a 
bigger scale.


{
  FileReader reader = new  // Annoy the garbage collector for 
no reason?

  auto blob = reader.read();
  delete reader;
}

Since garbage collection is a very nice feature that I wouldn't 
wanna miss for certain scenarios I think D should give us the 
opportunity to determine how an object is allocated. In the 
example above putting it on the stack is probably a good idea. 
Having a self managed reference to the heap can be good too if 
manual memory management is wanted. Or of course let the GC 
manage it ( i love it for prototyping code and also as a D 
beginner it is beneficial that i just dont need to care about 
memory management).


Could somebody explain to me if this is seen as a problem 
why/whynot and how I should address that kind of issues in my 
code?

Re: DUB, link automatically right object for platform and archi

[Basile B. via Digitalmars-d-learn]

On Friday, 2 September 2016 at 03:24:58 UTC, rikki cattermole 
wrote:

On 02/09/2016 6:01 AM, Basile B. wrote:

[...]

What's wrong in my description ?

For starters


Ouch...

buildSettings is just a name given to a group of properties. It 
doesn't actually go INTO the dub file.


Thx much, this explains why the JSON object was missing.

dflags is valid in top level config, subPackage and of course 
configuration.

[Issue 16461] New: Using the fully qualified type of an object within its own scope causes an error

[via Digitalmars-d-bugs]

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

  Issue ID: 16461
   Summary: Using the fully qualified type of an object within its
own scope causes an error
   Product: D
   Version: D2
  Hardware: x86_64
OS: Windows
Status: NEW
  Severity: critical
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: goober...@gmail.com

This one's quite easy to reproduce, and I can probably work around it with a
small bit of pain. Had to painstakingly reduce code in a mixin/mixin template
combo by hand to get it down to this minimal case, which is another issue
entirely...

Output: Error: undefined identifier 'Test' in package 'thismodule'

Code:

module thismodule;

struct Test
{
  pragma( msg, thismodule.Test.stringof );
}

--

Re: Beta D 2.071.2-b3

[ketmar via Digitalmars-d-announce]

On Friday, 2 September 2016 at 07:46:30 UTC, Rory McGuire wrote:
actually, from my PoV solution is supereasy: just remove ALL 
visibility restrictions for traits. and i mean all. allMembers 
should return all members, getMember should allow to access *any* 
existing member without annoying messages. it is up to programmer 
to insert getProtection checks if he needs it.


traits is a low-level feature by definition, and doesn't meant to 
be used directly (we have std.traits wrappers for that), so i 
want D devs to stop making our, low-level coders, life harder 
than it is now. ;-)


D devs just should draw the line between __traits and std.traits. 
first sould be inherently unsafe, allow *everything* and impose 
as little restrictions as it is possible (note: *as* *possible*, 
not *as* *sane* -- all kind of insanity should be allowed, if it 
is possible). then, std.traits wrappers should use __traits to 
build *safe* things (declaring that @trusted in the end).