Re: Serialization/deserialization of templated class

[Dmitry Solomennikov via Digitalmars-d]

On Wednesday, 28 June 2017 at 05:01:17 UTC, Eugene Wissner wrote:
On Wednesday, 28 June 2017 at 04:41:25 UTC, Dmitry Solomennikov 
wrote:



Probably if you have serialized data, you convert strings to 
other types, so it may be possible to perfom if-checks:

if (myDataIsStringAndDouble(data))
{
  auto var = new Some!(Pair!(string, double))(new Pair!(string, 
double)("df", 5.0));

}
else if (myDataIsStringAndInt(data))
{
  auto var = new Some!(Pair!(string, int))(new Pair!(string, 
int)("df", 5));

}


It is possible, but it is not a general solution. I've posted 
couple of sample classes, but there are more complicated cases, 
of course, and it well be combinatorial explosion here.


I got the Variant idea, I'll give it a try.
From other point of view, is there a reflection, say

auto i = newInstance("Pair!(int, string)(10, \"asdf\")"),

something like in Java?

[Issue 14256] Poor IO performance on 64-bit dmd 2.066 (OS X)

[via Digitalmars-d-bugs]

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

Jon Degenhardt  changed:

   What|Removed |Added

 CC||jrdemail2000-dl...@yahoo.co
   ||m

--- Comment #14 from Jon Degenhardt  ---
I've benchmarked File.byLine on OS X and Linux and they are quite fast on these
platforms. I have not tested Windows, but have seen reports indicating it is
quite slow there. I know also that performance on OS X poor prior to 2.068,
when it was dramatically improved.

The improvement in 2.068 was via PR #3089
(https://github.com/dlang/phobos/pull/3089). This changed File.byLine to use
getdelim() on platforms supporting it, including OS X and most Linux versions.
It's not clear if a similar change was made for Windows.

This can be seen in part in the source file
(https://github.com/dlang/phobos/blob/master/std/stdio.d) by searching for
HAS_GETDELIM and NO_GETDELIM. Most platforms are listed as one or the other,
Windows does not appear to be included and may still use a slow implementation.

--

Re: Serialization/deserialization of templated class

[Eugene Wissner via Digitalmars-d]

On Wednesday, 28 June 2017 at 04:41:25 UTC, Dmitry Solomennikov 
wrote:

Hi, guys!

I have templated classes like this:

class Some(T1) {
  T1 value;
  this(T1 _value){
value = _value;
  }
}
class Pair(T1, T2) {
  T1 first;
  T2 second;
  this(T1 _first, T2 _second){
first = _first;
second = _second;
  }
}

and a lot of serialised data, which I have to read and 
instantiate into given classes.
Serialized data looks like this: 'Some(Pair("df", 5.0))' or 
'Pair(Some(true), 11)', i.e. order of structs, its types and 
inclusion order are unknown at compile time.


I know there are several serialisation libraries, but I found 
they work only with non-templated classes, like:


class Foo {
  int a;
}

I can read input data and parse it, but have no idea how to 
construct object of templated class in this situation. Please 
give a hint.


Templates are a compile time feature. You won't be able to 
initialize the classes if you don't know the type at compile time.


You can use some data structure like Variant that can save values 
of different types.
You could use union for data storage in you class and list all 
possible types as union members.
Probably if you have serialized data, you convert strings to 
other types, so it may be possible to perfom if-checks:

if (myDataIsStringAndDouble(data))
{
  auto var = new Some!(Pair!(string, double))(new Pair!(string, 
double)("df", 5.0));

}
else if (myDataIsStringAndInt(data))
{
  auto var = new Some!(Pair!(string, int))(new Pair!(string, 
int)("df", 5));

}

Serialization/deserialization of templated class

[Dmitry Solomennikov via Digitalmars-d]

Hi, guys!

I have templated classes like this:

class Some(T1) {
  T1 value;
  this(T1 _value){
value = _value;
  }
}
class Pair(T1, T2) {
  T1 first;
  T2 second;
  this(T1 _first, T2 _second){
first = _first;
second = _second;
  }
}

and a lot of serialised data, which I have to read and 
instantiate into given classes.
Serialized data looks like this: 'Some(Pair("df", 5.0))' or 
'Pair(Some(true), 11)', i.e. order of structs, its types and 
inclusion order are unknown at compile time.


I know there are several serialisation libraries, but I found 
they work only with non-templated classes, like:


class Foo {
  int a;
}

I can read input data and parse it, but have no idea how to 
construct object of templated class in this situation. Please 
give a hint.

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

[Moritz Maxeiner via Digitalmars-d-learn]

On Wednesday, 28 June 2017 at 02:13:10 UTC, Jonathan M Davis 
wrote:
On Wednesday, June 28, 2017 01:11:35 Moritz Maxeiner via 
Digitalmars-d-learn wrote:
Not every class can't be finalized, so it might make sense for 
finalization to remain an available option.


There are definitely cases where finalizers make sense. Case in 
point: if you have a socket class, it makes perfect sense for 
it to have a finalizer. Yes, it's better to close it manually, 
but it will work just fine for the GC to close it when 
finalizing the class object so long as you don't use so many 
sockets that you run out before the GC collects them. So, 
having a finalizer is a good backup to ensure that the socket 
resource doesn't leak.


Yes, I think that's like the File class I presented (at least on 
Posix).
But on the other hand, since there are also cases in which 
finalization of an alive (==undestroyed) object are unacceptable 
(e.g. when it requires other GC managed objects to be alive), 
splitting them off into two separate methods and allowing to 
forbid finalization seems sensible to me.

Re: Checked vs unchecked exceptions

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 28 June 2017 at 02:09:40 UTC, Moritz Maxeiner wrote:


---
static assert (throwsExactly!(foo, AException, BException));
void foo() { ... }
---


One could even go a bit farther and implement a mixin template 
using `typeof(this)` and do:


---
void foo()
{
mixin ThrowsExactly!(AException, BException);
}
---

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, June 28, 2017 01:11:35 Moritz Maxeiner via Digitalmars-d-learn 
wrote:
> On Wednesday, 28 June 2017 at 00:05:20 UTC, Guillaume Piolat
>
> wrote:
> > On Tuesday, 27 June 2017 at 23:54:50 UTC, Moritz Maxeiner wrote:
> >> - Replace calls by the GC to `~this` with calls to `finalize`
> >> (or invent some cool other shortened name for the latter)
> >
> > My point is that in such a "finalize()" function the only sane
> > things to do is to crash if the resource wasn't freed already.
> > Why so?
> >
> > [...]
>
> Not every class can't be finalized, so it might make sense for
> finalization to remain an available option.

There are definitely cases where finalizers make sense. Case in point: if
you have a socket class, it makes perfect sense for it to have a finalizer.
Yes, it's better to close it manually, but it will work just fine for the GC
to close it when finalizing the class object so long as you don't use so
many sockets that you run out before the GC collects them. So, having a
finalizer is a good backup to ensure that the socket resource doesn't leak.

- Jonathan M Davis

Re: Checked vs unchecked exceptions

[Moritz Maxeiner via Digitalmars-d]

On Wednesday, 28 June 2017 at 01:35:32 UTC, mckoder wrote:

On Tuesday, 27 June 2017 at 22:56:47 UTC, Moritz Maxeiner wrote:


You mean the very first time you want to call it and you don't 
know the exception set yourself by looking at its signature?
Put the call in a nothrow scope and compile the module (which 
is fast in D), the compiler will then complain which 
exceptions you didn't catch (requires improvement of nothrow 
analysis [1]).




So to know what exceptions are possible you have to compile the 
code?


That, or do the even faster thing and use what's written in the 
documentation (which a sensible person might generate 
automatically, embedding the generated exception set for each 
function).

There are only two outcomes (sans compiler bugs):
- What's written there is correct -> It will compile and you're 
fine
- What's written there is incorrect -> It won't compile and tell 
you what's missing
In the 2nd case you have discovered a bug in whatever codebase 
you are using. Report it.


I consider that inferior to other solutions such as callee 
explicitly stating what exceptions it may throw, because then 
all you have to do is glance at the callee.


On the one hand you have a small one-time cost (I would go as far 
as calling it tiny, since I consider it a reasonable assumption 
for you to have the documentation open), on the other hand you 
have a one-time cost with its size depending on the call 
hierarchy level and small constant maintenance costs on every 
change.
If you consider the first inferior to the second, that's your 
call, but I disagree strongly.
That being said, nothing prevents you from putting it there 
anyway:


---
static assert (throwsExactly!(foo, AException, BException));
void foo() { ... }
---

Also, I think  explicitly stating your intent in this manner 
(by the callee not just the caller) is a good idea, to make 
sure you are not throwing some exception you didn't mean to 
throw.


Add a static assert as shown above and you're done.

Re: Checked vs unchecked exceptions

[mckoder via Digitalmars-d]

On Tuesday, 27 June 2017 at 22:56:47 UTC, Moritz Maxeiner wrote:


You mean the very first time you want to call it and you don't 
know the exception set yourself by looking at its signature?
Put the call in a nothrow scope and compile the module (which 
is fast in D), the compiler will then complain which exceptions 
you didn't catch (requires improvement of nothrow analysis [1]).




So to know what exceptions are possible you have to compile the 
code? I consider that inferior to other solutions such as callee 
explicitly stating what exceptions it may throw, because then all 
you have to do is glance at the callee. Also, I think explicitly 
stating your intent in this manner (by the callee not just the 
caller) is a good idea, to make sure you are not throwing some 
exception you didn't mean to throw.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[MysticZach via Digitalmars-d]

On Wednesday, 28 June 2017 at 01:23:18 UTC, MysticZach wrote:

On Tuesday, 27 June 2017 at 09:18:11 UTC, Olivier FAURE wrote:
A bit late to the party, but I would recommend the following 
syntax:


out (void; myTest)

for argument-less tests. A casual reader would be less likely 
to see this in code and think it's some sort of typo; it would 
be easier to google; and it would make some semantic sense 
(functions that don't return anything return void).


It's a creative suggestion, and not a bad one. But it's 
verbose, and I'd like to be able to omit the identifier 
altogether. Currently, only `for` loops allow this, as when 
people write:


for( ; ; )

Theoretically, `foreach

foreach( ; a) ...
out( ; ...)

Currently `foreach` does not allow omitting


Sorry, clicked the `send` button too soon.

Anyway, currently `foreach` does not allow omitting the initial 
identifier, but in theory it _could_ be enhanced to do so. If 
`out` expressions also allow this, then we get the desired 
symmetry between `for`,`foreach`, and `out` expressions, with 
minimal verbosity. That's the solution I promote. It's better 
than requiring something to be there when nothing really has to 
be. I don't know why `foreach` isn't already this way.

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[MysticZach via Digitalmars-d]

On Tuesday, 27 June 2017 at 09:18:11 UTC, Olivier FAURE wrote:
A bit late to the party, but I would recommend the following 
syntax:


out (void; myTest)

for argument-less tests. A casual reader would be less likely 
to see this in code and think it's some sort of typo; it would 
be easier to google; and it would make some semantic sense 
(functions that don't return anything return void).


It's a creative suggestion, and not a bad one. But it's verbose, 
and I'd like to be able to omit the identifier altogether. 
Currently, only `for` loops allow this, as when people write:


for( ; ; )

Theoretically, `foreach

foreach( ; a) ...
out( ; ...)

Currently `foreach` does not allow omitting

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

[Moritz Maxeiner via Digitalmars-d-learn]

On Wednesday, 28 June 2017 at 00:05:20 UTC, Guillaume Piolat 
wrote:

On Tuesday, 27 June 2017 at 23:54:50 UTC, Moritz Maxeiner wrote:
- Replace calls by the GC to `~this` with calls to `finalize` 
(or invent some cool other shortened name for the latter)


My point is that in such a "finalize()" function the only sane 
things to do is to crash if the resource wasn't freed already. 
Why so?


[...]


Not every class can't be finalized, so it might make sense for 
finalization to remain an available option.
What I think reasonable is treating destruction and finalization 
as two distinct things. This could look like the following:


---
// Does not refer to other GC memory, can be finalized
class File
{
private:
int fd;
public:
this() { fd = open(...); }
~this() { close(fd); }

// If the GC collects a File object that hasn't been 
destroyed yet, it will call this finalizer,
// which *manually* calls the destructor (because it's safe 
to do so in this case)
// A File object can still be manually `destroy`ed 
beforehand, in which case this particular finalizer is still 
safe, since an object won't be destroyed twice

finalize() { destroy(this); }
// Or maybe prettier: alias finalize = ~this;
}

class Foo
{
private:
File f;
public:
this() { f = new File(); }

// Make the process crash on finalization of an undestroyed 
Foo object

@disable finalize();
}
---


- Reserve `~this` for being called by deterministic lifetime 
management (std.experimental.allocator.dispose, 
object.destroy, RefCounted, Unique, etc.)


That's precisely what the GC-proof-resource-class allows, by 
preventing defective, non-composable usages of ~this.


The GC proof resource class idiom is a necessary hack, but it 
*is* a hack with its own limitations (e.g. depending on Error 
being catchable).

Re: C++ Metaclasses proposal

[Nicholas Wilson via Digitalmars-d]

On Tuesday, 27 June 2017 at 15:57:01 UTC, Enamex wrote:
PDF: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf
Reddit: 
https://www.reddit.com/r/programming/comments/6js4uv/metaclasses_in_c/


I thought a bit on possible patterns in D to accomplish the 
same without string mixins.


For example, defining the prototype `Foo_` then mixing in 
`mixin MyMetaclass!Foo_ Foo`.


Got stuck trying to 'forward' (or copy the implementation of) 
functions in `Foo_` into `Foo` after modifying them, though.


Besides trying to do it in D (please try still!), what do you 
think of the idea? In general and say versus a robust macro 
system with some level of access to CTFE? Or even just a good 
macro system (someone began discussing this on the reddit 
thread; talking about Racket macros).


Quite a lot of it seems doable with mixin templates and UDA 
reflection.

Ethan Watson's dconf talk is a good point of comparison.

Re: Let's paint those bikesheds^Werror messages!

[Walter Bright via Digitalmars-d]

On 6/27/2017 7:32 AM, Vladimir Panteleev wrote:

As has been announced, DMD now has colorized syntax highlighting in error 
messages:

http://forum.dlang.org/post/of9oao$230j$1...@digitalmars.com

With 2.075's release near, now would be a good time to decide on a nice color 
palette that looks fine on most terminals. So, please vote:


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


In the spirit of this, a lot of (rather tedious) work needs to be done on the 
error messages themselves to enable color syntax highlighting. Specifically, 
replacing ' ' with ` `, and adding ` ` around %s formats when code is being 
emitted to the %s.


It's tedious because of all the messages in test/fail_compilation/* that need 
updating.


It would also be helpful to pull things like:

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

Re: Relative lflag paths in dub on Windows

[Mike Parker via Digitalmars-d-learn]

On Wednesday, 28 June 2017 at 00:16:23 UTC, Mike Parker wrote:

On Tuesday, 27 June 2017 at 19:07:49 UTC,

You have to specify the appropriate linker option, e.g. 
-L-option. For gcc, that happens to -L, so you get -L-L. For 
optlink it's +something and for the MS linker it's /something. 
I'm on my phone else I'd look it up.


Optlink instructions at [1]: -L+path\
MS linker [2]: -L/LIBPATH:path

[1] 
https://wiki.dlang.org/Compiling_and_linking_with_DMD_on_Windows


[2] 
https://docs.microsoft.com/en-us/cpp/build/reference/libpath-additional-libpath

Re: Relative lflag paths in dub on Windows

[Mike Parker via Digitalmars-d-learn]

On Tuesday, 27 June 2017 at 19:07:49 UTC, jmh530 wrote:
Is it possible to set relative -L paths on dub for Windows? 
Absolute paths work fine, just can't get relative paths working.


I was looking at the thread here
https://forum.dlang.org/post/dkwqrwzwqbrnaamlv...@forum.dlang.org
and came up with something like
{
...
"lflags": ["-L-L..\\libs\\"],
}

where the file structure contains folders dubproject\libs and 
dubproject\source.


It didn't work though.


You have to specify the appropriate linker option, e.g. 
-L-option. For gcc, that happens to -L, so you get -L-L. For 
optlink it's +something and for the MS linker it's /something. 
I'm on my phone else I'd look it up.

Re: Phobos PR in need of review/merge

[Walter Bright via Digitalmars-d]

On 6/27/2017 10:21 AM, Mike Wey wrote:

On 27-06-17 08:49, Walter Bright wrote:

You can also specifically request a review from one of Team Phobos:

https://github.com/orgs/dlang/teams/team-phobos/members

Just click on the [Reviwers] link.


Is that page private? I get an 404 error, and i can't find the page on github.


Here's the list:

burner
repeatedly
klickverbot
braddr
alexrp
jakobovrum
cybershadow
kyllingstad
dmitryolschansky
martinnowak
ibuclaw
quickfur
andralex
walterbright
jmdavis
yebblies
schveiguy
jackstouffer
rainers
9il
hackerpilot
uplinkcoder
zombiedev
wilzbach
andrewedwards
andrejmitrovic

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

[Guillaume Piolat via Digitalmars-d-learn]

On Tuesday, 27 June 2017 at 23:54:50 UTC, Moritz Maxeiner wrote:


Do you mean destructors?


Yes.


- Replace calls by the GC to `~this` with calls to `finalize` 
(or invent some cool other shortened name for the latter)


My point is that in such a "finalize()" function the only sane 
things to do is to crash if the resource wasn't freed already. 
Why so?


See my texture example in: 
https://forum.dlang.org/post/kliasvljzwjhzuzib...@forum.dlang.org


More simply:
If A needs an alive B to be destroyed, then neither A-owns-B or 
B-owns-A can guarantee the ordering under GC destruction.


Furthermore, this is viral. Whoever owns A needs an alive B to be 
destroyed.




- Reserve `~this` for being called by deterministic lifetime 
management (std.experimental.allocator.dispose, object.destroy, 
RefCounted, Unique, etc.)


That's precisely what the GC-proof-resource-class allows, by 
preventing defective, non-composable usages of ~this.

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

[Moritz Maxeiner via Digitalmars-d-learn]

On Tuesday, 27 June 2017 at 23:42:38 UTC, Guillaume Piolat wrote:

On Tuesday, 27 June 2017 at 18:04:36 UTC, Moritz Maxeiner wrote:


Well, technically speaking the `~this` for D classes *is* a 
finalizer that you may optionally manually call (e.g. via 
destroy).
It would be nice, though, to change class `~this` into a 
destructor and move the finalization into an extra method like 
`finalize`. Write a DIP?


The only sane way out is to prevent the GC from calling 
constructors.


Do you mean destructors?
If so, that's what I meant with the "technically". If the may GC 
call it (automatically), it's a finalizer, not a destructor (in 
the usual sense, anyway).
- Replace calls by the GC to `~this` with calls to `finalize` (or 
invent some cool other shortened name for the latter)
- Reserve `~this` for being called by deterministic lifetime 
management (std.experimental.allocator.dispose, object.destroy, 
RefCounted, Unique, etc.)

[Issue 17563] gc_inFinalizer should be public

[via Digitalmars-d-bugs]

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

ponce  changed:

   What|Removed |Added

 CC||alil...@gmail.com

--- Comment #1 from ponce  ---
Note: This "crude and horrible way" helped me find plenty of bugs where I would
rely on the GC to release a resource, and I only do this in debug clauses so it
hardly really matter how ugly it is. It's a programming error, so I make it
crash right away.

--

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

[Guillaume Piolat via Digitalmars-d-learn]

On Tuesday, 27 June 2017 at 18:04:36 UTC, Moritz Maxeiner wrote:


Well, technically speaking the `~this` for D classes *is* a 
finalizer that you may optionally manually call (e.g. via 
destroy).
It would be nice, though, to change class `~this` into a 
destructor and move the finalization into an extra method like 
`finalize`. Write a DIP?


The only sane way out is to prevent the GC from calling 
constructors.

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

[Guillaume Piolat via Digitalmars-d-learn]

On Tuesday, 27 June 2017 at 15:24:00 UTC, Steven Schveighoffer 
wrote:
The GC still needs to call something to clean up non-memory 
resources,


Well, I'd much prefer if the GC would simply not call 
destructors. Yes, destructor can work for _some_ resources, but 
because of ordering it also create accidental correctness, or 
just doesn't work with other resources.


but having a call to use when cleaning up deterministically can 
make resource management more efficient (even memory resource 
management).


Yes. My point is that the destructor is uniquely positionned to 
be that call.
(This would also enables back failing destructors through the use 
of exceptions.)


In current D the problem with allowing the GC to close resources 
is that there is no ordering of destructors. A sub-tree of the 
ownership graph is freed by the GC together, but sometime an 
order is required for releasing.


Typically: you want to release a SDL_Texture but the Derelict 
SharedLib object has been freed already, so you can't call 
sdl_releaseTexture. It doesn't matter that the texture object 
held a reference to the ShareLib object since the sub-tree is 
destroyed together. close() methods don't help with that, the 
problem is with the GC calling destructors.



And if _some_ resource needs an ordering, then this property leak 
on their owners, so little by little the whole ownership graph 
need determinism.

Re: Let's paint those bikesheds^Werror messages!

[Sönke Ludwig via Digitalmars-d]

Am 28.06.2017 um 01:24 schrieb Vladimir Panteleev:

On Tuesday, 27 June 2017 at 23:18:18 UTC, Sönke Ludwig wrote:

I mean if, by switching to more colors, we rule out few people, but
are able to provide a much better value for the (presumed) majority of
people with differently colored, but 256-color capable terminals, then
it may still be worth the trade-off (as long as those other terminals
don't get blown apart at least).


And Windows?


Good point, I forgot about that and it can definitely not be ignored. A 
separate 16-color theme just on Windows, however, could still be an option.


I've posted a proposal with a very minimal use syntax coloring: 
https://github.com/dlang/dmd/pull/6943#issuecomment-311514309


Given the 16 color constraint, there were actually only a handful of 
other permutations that made sense and that I could think of, as long as 
readability was the goal.

[Issue 14758] TypeInfo causes excessive binary bloat

[via Digitalmars-d-bugs]

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

--- Comment #17 from Mike  ---
GDC appears to have solved this problem by wrapping `TypeInfo.name` in a static
variable.  See
https://github.com/D-Programming-GDC/GDC/pull/505#event-1141470083

I tested it on ARM Cortex-M and it works as expected.  Perhaps there's
something there that the other compilers can leverage.

--

Re: Let's paint those bikesheds^Werror messages!

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 27 June 2017 at 23:24:42 UTC, Vladimir Panteleev 
wrote:

On Tuesday, 27 June 2017 at 23:18:18 UTC, Sönke Ludwig wrote:
I mean if, by switching to more colors, we rule out few 
people, but are able to provide a much better value for the 
(presumed) majority of people with differently colored, but 
256-color capable terminals, then it may still be worth the 
trade-off (as long as those other terminals don't get blown 
apart at least).


And Windows?


All these can even do true colors on Windows:
- 
https://blogs.msdn.microsoft.com/commandline/2016/09/22/24-bit-color-in-the-windows-console/

- https://mintty.github.io/
- https://github.com/Maximus5/ConEmu

Re: Let's paint those bikesheds^Werror messages!

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 27 June 2017 at 23:18:18 UTC, Sönke Ludwig wrote:
I mean if, by switching to more colors, we rule out few people, 
but are able to provide a much better value for the (presumed) 
majority of people with differently colored, but 256-color 
capable terminals, then it may still be worth the trade-off (as 
long as those other terminals don't get blown apart at least).


I suggest going a step further to true colors. It's supported by 
at least [1]
- nearly all terminal emulators for Linux that can do 256 colors 
(all libvte-based ones, e.g.)

- iterm2 and macterm for macOS
- mintty and Windows 10 bash console for Windows (10)


[1] 
https://gist.github.com/XVilka/8346728#now-supporting-truecolour

Re: Let's paint those bikesheds^Werror messages!

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 27 June 2017 at 23:18:18 UTC, Sönke Ludwig wrote:
I mean if, by switching to more colors, we rule out few people, 
but are able to provide a much better value for the (presumed) 
majority of people with differently colored, but 256-color 
capable terminals, then it may still be worth the trade-off (as 
long as those other terminals don't get blown apart at least).


And Windows?

Re: Let's paint those bikesheds^Werror messages!

[deadalnix via Digitalmars-d]

On Tuesday, 27 June 2017 at 19:43:03 UTC, Vladimir Panteleev 
wrote:

On Tuesday, 27 June 2017 at 19:39:25 UTC, deadalnix wrote:

Please, please, please, just do the same as clang.


I don't think clang has this feature, so doing the same as 
clang would be a regression. We're in uncharted waters!


Ho, sorry, this is syntax highlighting for the core itself, not 
the error messages. Well not sure, I'm no designer so I trust you 
guys to come up with something good.

Re: Let's paint those bikesheds^Werror messages!

[Sönke Ludwig via Digitalmars-d]

Am 28.06.2017 um 00:44 schrieb Vladimir Panteleev:

On Tuesday, 27 June 2017 at 22:34:39 UTC, Sönke Ludwig wrote:

I was specifically trying to steer away from a random
propose-and-comment approach, because I think we can do a lot better
if we first reduce the size of the design space using objective
measures. If we can agree to some extent that this makes sense, I can
give it a go and propose something concrete, too.


Please do. I think your rules make sense, but it's difficult to judge
them without trying the task and finding out how well each can be
satisfied without making the task impossible.


If the default goes from well readable but not highlighted to barely
readable in parts, then that would IMO be a pretty big failure. The
minimum goal should be to not make things worse overall on any of the
most common setups.


That's a good point. Unfortunately, that leaves very few options. If we
are to stick to the tenets, we would need to remove nearly all use of
color, even from the "Error" and especially "Warning" labels, as those
are close to unreadable there.


If they are only and consistently used for "Error" and "Warning", then 
that's acceptable, because it's the color already unambiguously defines 
the text. But in general I think that the possibilities are indeed very 
limited if only the 16 base colors are allowed.





Um, I don't think that's possible.
http://forum.dlang.org/post/dtlzlemqzfyozleks...@forum.dlang.org


The question is how many users are actually ruled out by this.
Benefiting a large number of people at the expense of a few is a
reasonable approach in this case.


Sorry, I don't understand what you mean by this.


I mean if, by switching to more colors, we rule out few people, but are 
able to provide a much better value for the (presumed) majority of 
people with differently colored, but 256-color capable terminals, then 
it may still be worth the trade-off (as long as those other terminals 
don't get blown apart at least).

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 27 June 2017 at 22:45:17 UTC, Mark wrote:

On Tuesday, 20 June 2017 at 11:57:55 UTC, Mike Parker wrote:

DIP 1009 is titled "Improve Contract Usability".

[...]


Veering a bit off topic,the compiler doesn't treat contracts 
any different from other code, does it? For instance, consider:


[...]

I would have liked to get a *compile-time* error [...]


Compile time contract violation checking?
While an interesting, I'm not sure the benefits would outweigh 
the implementation costs.


If the contract system amounts to placing assertions at the 
beginning and/or end of a function, it doesn't seem so useful 
except for documentation and readability.


Considering that code is read a lot more than written those two 
are *critically* important.
What more do you expect? It could eventually be optimized to 
inject the in contract check at the caller's side (before 
entering the function), but the point of contracts is that they 
*aren't* violated. If they are, well, your program[1] is broken 
and needs to die.


[1] abstract: computational task; implementation barring safe 
thread/fiber killing: process

Re: Checked vs unchecked exceptions

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 27 June 2017 at 21:47:49 UTC, jag wrote:

On Tuesday, 27 June 2017 at 19:37:24 UTC, Moritz Maxeiner wrote:


As I have pointed out, your example occurs on the *caller* 
side, not the *callee* side. The proper solution is not for 
the callee to specify which exceptions it may throw, but for 
the caller to specify which exceptions it allows the callee to 
throw (using compile time introspection on the exception set).


Can I as a programmer who wants to call a function written by 
someone else inspect the declaration of that function and know 
what exceptions are possible?


* Can I as a programmer who wants to call a function written by 
someone else inspect that function's exception set?


Yes, as explained fully here [1], shown as an idiomatic D trait 
here [2], and a template based abstraction around that trait here 
[3]. It would need to be implemented, of course, but it's not 
conceptually hard.



If no how is this supposed to work?


It was explained multiple times in this thread.

I am supposed to specify that exceptions I want to allow the 
called function to throw?


You aren't supposed to do anything, but you can do that, yes.

The called function is not going to dynamically adapt itself 
and change the list of exceptions it throws, right?


What? A function's exception set is determined by its body and 
can be aggregated by the compiler in a single recursive pass in 
the static analysis phase.


So how can I know, before running the code, what exceptions are 
possible?


You mean the very first time you want to call it and you don't 
know the exception set yourself by looking at its signature?
Put the call in a nothrow scope and compile the module (which is 
fast in D), the compiler will then complain which exceptions you 
didn't catch (requires improvement of nothrow analysis [1]).


[1] 
http://forum.dlang.org/post/uovtkvpdagzagzhya...@forum.dlang.org
[2] 
http://forum.dlang.org/post/lxejskhonjtiifvvg...@forum.dlang.org
[3] 
http://forum.dlang.org/post/fjjkqbxiznlxfstqn...@forum.dlang.org

Re: Checked vs unchecked exceptions

[Jesse Phillips via Digitalmars-d]

On Tuesday, 27 June 2017 at 06:10:52 UTC, Tobias Müller wrote:
I honestly don't understand how people that care a great deal 
about expressive type systems can be so opposed to checked 
exceptions. After all they wouldn't use 'object' for everything 
either.


Tobi


I think there is a threshold. For example, personally I am 
against the compiler refusing to compile because of an unused 
variable, or import clause. Why, because they get in the way of 
making changes. I don't want to pacify the compiler as I progress 
through the development process. Generally when the compiler 
complains about a type mismatch I actually forgot to make 
additional changes to make the new thing work.


Checked exceptions do the same thing. Call a new function, 
propagate the exception just to determine if it is a desired 
change. This very much can lead to attempting to pacify without 
properly handling.


This discussion seems to emphasize the ability to handle every 
exception type. There are certainly times I've utilized the 
ability to handle different types of exception in different ways, 
but it isn't the norm. This is likely because generally I find 
Exception to crop up because of programming logic bugs rather 
than true exceptions and in the other cases I'm not using the 
type of exception to change how I deal with a problem; if my Json 
parsing throws a Conversion exception I'm not going to handle it 
differently than when it throws an Invalid Token exception.


I however don't have much experience managing checked Exceptions. 
I remember back in the day trying to fix the long list of 
exceptions my functions could throw. I'd commonly use throws 
Exception, pondered on wrapping exceptions into my own exception 
that would then be thrown. Neither of these would be helpful to 
the original points, adding exceptions should break the contract 
and you should be able to catch specific exceptions. How is the 
ever expanding exception list of static void Main managed by 
others?

Re: DIP 1009--Improve Contract Usability--Preliminary Review Round 1

[Mark via Digitalmars-d]

On Tuesday, 20 June 2017 at 11:57:55 UTC, Mike Parker wrote:

DIP 1009 is titled "Improve Contract Usability".

[...]


Veering a bit off topic,the compiler doesn't treat contracts any 
different from other code, does it? For instance, consider:


int foo()
out(result; result>0)
{
// whatever
}

int bar(int x)
in (x<0)
{
// whatever
}

int main() {
return bar(foo());
}

I would have liked to get a *compile-time* error in case of such 
a trivial contract violation. Of course, I don't expect the 
compilier to try and prove that a contract holds (seems 
unrealitic and not so useful) but it would be nice if it could at 
least spot simple errors, like in the example above.


In a similar vein, the information conveyed in a contract can 
potentially be used to apply simple optimizations, at least in 
trivial cases.


If the contract system amounts to placing assertions at the 
beginning and/or end of a function, it doesn't seem so useful 
except for documentation and readability.

Re: Let's paint those bikesheds^Werror messages!

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 27 June 2017 at 22:34:39 UTC, Sönke Ludwig wrote:
I was specifically trying to steer away from a random 
propose-and-comment approach, because I think we can do a lot 
better if we first reduce the size of the design space using 
objective measures. If we can agree to some extent that this 
makes sense, I can give it a go and propose something concrete, 
too.


Please do. I think your rules make sense, but it's difficult to 
judge them without trying the task and finding out how well each 
can be satisfied without making the task impossible.


If the default goes from well readable but not highlighted to 
barely readable in parts, then that would IMO be a pretty big 
failure. The minimum goal should be to not make things worse 
overall on any of the most common setups.


That's a good point. Unfortunately, that leaves very few options. 
If we are to stick to the tenets, we would need to remove nearly 
all use of color, even from the "Error" and especially "Warning" 
labels, as those are close to unreadable there.



Um, I don't think that's possible.
http://forum.dlang.org/post/dtlzlemqzfyozleks...@forum.dlang.org


The question is how many users are actually ruled out by this. 
Benefiting a large number of people at the expense of a few is 
a reasonable approach in this case.


Sorry, I don't understand what you mean by this.

Re: Let's paint those bikesheds^Werror messages!

[Sönke Ludwig via Digitalmars-d]

Am 28.06.2017 um 00:19 schrieb Vladimir Panteleev:

On Tuesday, 27 June 2017 at 22:12:42 UTC, Sönke Ludwig wrote:

[...]


(snip - as it boils down to needing a concrete proposal)


I was specifically trying to steer away from a random 
propose-and-comment approach, because I think we can do a lot better if 
we first reduce the size of the design space using objective measures. 
If we can agree to some extent that this makes sense, I can give it a go 
and propose something concrete, too.





But it seems like the solution for that is to use saturated colors for
everything. There are also some examples that clearly don't work on a
white background, such as using cyan. Or examples in a black
background, such as using saturated blue.


As I've already mentioned, even the "dark" colors look very bright on
Terminal.app. I think the program's defaults are simply bad. Within
these constraints, I think it should be at least not unusable.


If the default goes from well readable but not highlighted to barely 
readable in parts, then that would IMO be a pretty big failure. The 
minimum goal should be to not make things worse overall on any of the 
most common setups.



If we really want to reduce this to a pure question of favorite color
themes, I'd propose to just take either Monokai or the Material UI
theme. In various places those seem to come up as the two most popular
themes, so using those is likely to be quite representative:
https://atom.io/themes/list?direction=desc=stars


Um, I don't think that's possible.
http://forum.dlang.org/post/dtlzlemqzfyozleks...@forum.dlang.org


The question is how many users are actually ruled out by this. 
Benefiting a large number of people at the expense of a few is a 
reasonable approach in this case.

Re: Go 1.9

[bachmeier via Digitalmars-d]

On Tuesday, 27 June 2017 at 02:40:37 UTC, jmh530 wrote:

On Tuesday, 27 June 2017 at 02:38:31 UTC, bachmeier wrote:


I'll post here after updating and testing the embedr package.


Great. I'll give it a go again when it's ready.


You can try this:
https://bitbucket.org/bachmeil/embedrwin

It's not in any sense a release. This is for early testing and 
everything will be added to embedr in the future. It works for 
me, so hopefully it will work for you.

[Issue 17322] Add Magikcraft to organizations using D

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dlang.org/commit/994de8bf4535b9e61fa12ac20e65617db6d20083
Fix Issue 17322 - Add Magikcraft to organizations using D

https://github.com/dlang/dlang.org/commit/d47df2c302b4a710bf285a86fc8e3417827dd7b8
Merge pull request #1696 from wilzbach/fix-17322

Fix Issue 17322 - Add Magikcraft to organizations using D
merged-on-behalf-of: Steven Schveighoffer 

--

Re: Let's paint those bikesheds^Werror messages!

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 27 June 2017 at 22:12:42 UTC, Sönke Ludwig wrote:

[...]


(snip - as it boils down to needing a concrete proposal)

But it seems like the solution for that is to use saturated 
colors for everything. There are also some examples that 
clearly don't work on a white background, such as using cyan. 
Or examples in a black background, such as using saturated blue.


As I've already mentioned, even the "dark" colors look very 
bright on Terminal.app. I think the program's defaults are simply 
bad. Within these constraints, I think it should be at least not 
unusable.


If we really want to reduce this to a pure question of favorite 
color themes, I'd propose to just take either Monokai or the 
Material UI theme. In various places those seem to come up as 
the two most popular themes, so using those is likely to be 
quite representative: 
https://atom.io/themes/list?direction=desc=stars


Um, I don't think that's possible. 
http://forum.dlang.org/post/dtlzlemqzfyozleks...@forum.dlang.org

Re: Let's paint those bikesheds^Werror messages!

[Sönke Ludwig via Digitalmars-d]

Am 27.06.2017 um 23:45 schrieb Vladimir Panteleev:

On Tuesday, 27 June 2017 at 21:10:37 UTC, Sönke Ludwig wrote:

Intended to be more of the latter, especially as a consequence of the
readability concern. The typical colorful syntax highlighting that is
often used (lets say like the Monokai theme), starts to break down
when it isn't used within its own context. Instead it starts to fight
for attention with the error message and with the other colored text
parts. The result can then be a net loss in visual structure.


Hmm, that may be true, but I'm not sure if it can be quantified. Our
only numbers are individuals' preferences, and so far this change seems
to be in the favor of many.


I don't know, it probably could indeed be quantified in some way, but 
maybe we don't have to go there. What we should at least do, however, is 
to set up some rules that define the space in which the possible color 
themes can be set up.


For example, not using the same or a similar color as one that is 
already used to mark errors, warnings or deprecations would be such a 
rule. Having normal text visually distinct would be another (i.e. not 
using the terminal's default color within highlighted code). And of 
course the usual rules, such as ensuring sufficient contrast between 
background and foreground, and possibly not using colors that people 
with a red/green blindness can't distinguish.


Interestingly, all of the examples in the PR fail at least one of those 
rules (with the last one excluded).



Apart from color, there are other possible means to fix this, for
example adding vertical spacing or delimiters between separate error
messages.


That will certainly be worth considering should we make more error
messages span multiple lines as clang does.


True, and IMO, the former is what should be our primary goal. When
that is reached, aesthetics can be optimized. But if we don't improve
readability with this, what's the point of this feature?


I don't think readability isn't improved (unless you refer to the
original choice of colors, in which case I agree) :)


For example, With the suggestions that I made in the first post, I'd 
argue that readability *is* improved. With a very colorful theme and no 
background color that sets it apart from normal text, not sure if that 
can still be the case. But there may be something in-between that works 
(which I tried to generalize as "toned down").


Another idea would be using a single hue and different variations in 
font weight and brightness, but that can quickly get difficult w.r.t 
contrast for slightly tinted background colors, too.



But surely better than a light gray or white on white. Otherwise the
whole text needs to have some kind of highly saturated color to avoid
such situations by default. Just ruling out a white background would
be a bad idea. I think on macOS that's the default, for example.


I don't know where the repeated false impression that we're ruling out
white backgrounds is coming from in this thread, when it can be
dispelled with one click. I specifically test the default color scheme
of the default terminal application on macOS.


But it seems like the solution for that is to use saturated colors for 
everything. There are also some examples that clearly don't work on a 
white background, such as using cyan. Or examples in a black background, 
such as using saturated blue.


If we really want to reduce this to a pure question of favorite color 
themes, I'd propose to just take either Monokai or the Material UI 
theme. In various places those seem to come up as the two most popular 
themes, so using those is likely to be quite representative: 
https://atom.io/themes/list?direction=desc=stars

[Issue 6227] Comparison of different enums

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/dlang.org/commit/a89e677820f4ce16d4645a153884b824870e4820
Deprecation: Issue 6227 - Comparison of different enums

https://github.com/dlang/dlang.org/commit/d91842970a436d714b425a97e835e899d69ffd97
Merge pull request #1673 from wilzbach/deprecate-enum-comparison

Deprecation: Issue 6227 - Comparison of different enums
merged-on-behalf-of: Vladimir Panteleev 

--

Re: Using templates with interfaces

[Andrew Chapman via Digitalmars-d-learn]

On Sunday, 25 June 2017 at 17:30:58 UTC, Petar Kirov [ZombineDev] 
wrote:

On Sunday, 25 June 2017 at 13:32:57 UTC, Andrew Chapman wrote:
I think you've answered the question with "You cannot have 
unimplemented templates in interfaces".  Thanks for the answer.

 I'll rethink the way I'm doing this.

Cheers.


In your case you can probably use something along the lines of:

interface RelationalDBInterface
{
// You can even make this protected
Varaint loadUntypedRow(string sql, Variant[] params);

final T loadRow(T)(string sql, Variant[] params)
{
auto row = loadUntypedRow(sql, params);

enforce(row.hasValue,
this.classID ~ "::loadRow - Query returned an empty 
row");


return row.toStruct!T;
}
}


Amazing, thank you!

[Issue 17560] Enhancement: view and copy full code example for offline compile/play

[via Digitalmars-d-bugs]

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

greensunn...@gmail.com changed:

   What|Removed |Added

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

--- Comment #4 from greensunn...@gmail.com ---
> Duplicate so will close.

Of what issue? (reopening)

> Sorry, but no, not always. I mean problems on live site like described here: 

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

I did reply on the thread.
tl:dr: not much we can do because the execution is an external service (DPaste)
Though there's a PR in the queue to switch over to the tour (more powerful,
uses docker with ~1GB max. per container):

https://github.com/dlang/dlang.org/pull/1647

[1] https://forum.dlang.org/post/kibvzokcytcegvtjq...@forum.dlang.org

> I did the search before posting issue, but miss this one. Thanks!

You are very welcome. Please raise your voice on this PR if you want it to be
merged ;-)

--

Re: Checked vs unchecked exceptions

[jag via Digitalmars-d]

On Tuesday, 27 June 2017 at 19:37:24 UTC, Moritz Maxeiner wrote:


As I have pointed out, your example occurs on the *caller* 
side, not the *callee* side. The proper solution is not for the 
callee to specify which exceptions it may throw, but for the 
caller to specify which exceptions it allows the callee to 
throw (using compile time introspection on the exception set).


Can I as a programmer who wants to call a function written by 
someone else inspect the declaration of that function and know 
what exceptions are possible? If no how is this supposed to work? 
I am supposed to specify that exceptions I want to allow the 
called function to throw? The called function is not going to 
dynamically adapt itself and change the list of exceptions it 
throws, right? So how can I know, before running the code, what 
exceptions are possible?

Re: Let's paint those bikesheds^Werror messages!

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 27 June 2017 at 21:10:37 UTC, Sönke Ludwig wrote:
Intended to be more of the latter, especially as a consequence 
of the readability concern. The typical colorful syntax 
highlighting that is often used (lets say like the Monokai 
theme), starts to break down when it isn't used within its own 
context. Instead it starts to fight for attention with the 
error message and with the other colored text parts. The result 
can then be a net loss in visual structure.


Hmm, that may be true, but I'm not sure if it can be quantified. 
Our only numbers are individuals' preferences, and so far this 
change seems to be in the favor of many.


Apart from color, there are other possible means to fix this, 
for example adding vertical spacing or delimiters between 
separate error messages.


That will certainly be worth considering should we make more 
error messages span multiple lines as clang does.


True, and IMO, the former is what should be our primary goal. 
When that is reached, aesthetics can be optimized. But if we 
don't improve readability with this, what's the point of this 
feature?


I don't think readability isn't improved (unless you refer to the 
original choice of colors, in which case I agree) :)


But surely better than a light gray or white on white. 
Otherwise the whole text needs to have some kind of highly 
saturated color to avoid such situations by default. Just 
ruling out a white background would be a bad idea. I think on 
macOS that's the default, for example.


I don't know where the repeated false impression that we're 
ruling out white backgrounds is coming from in this thread, when 
it can be dispelled with one click. I specifically test the 
default color scheme of the default terminal application on macOS.

Re: Phobos PR in need of review/merge

[Dukc via Digitalmars-d]

On Tuesday, 27 June 2017 at 19:40:52 UTC, Brad Roberts wrote:
There's a very good reason to leave requests open:  a closed 
request is gone, never to be seen again.


Well explained. So I quess that next time I should just leave a 
post there that I'm abandoning it. After many pings and a 
notification at forum of course.

[Issue 17562] Tangent function returns NaN for abs(input) >= 2^63

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/0fb66f092b897b55318509c6582008b3f912311a
Fix issue 17562 - tan returning -nan for inputs where abs(x) >= 2^63

The fptan instruction pushes a 1.0 onto the FPU register stack after a
successful operation, but when abs(input) >= 2^63 the C2 flag is set to
indicate that the input was out of bounds, and it doesn't push the 1.0.

Prior to this PR, the top value of the FPU stack was popped irrespective
of whether C2 was set, which in the case of an out-of-bounds input
caused the input to be removed from the stack and ultimately resulted in
an incorrect return value of -nan. This PR changes this behavior, only
popping after fptan when C2 was not set.

See: http://x86.renejeschke.de/html/file_module_x86_id_109.html

* Added unit tests for handling out-of-range inputs of fptan

--

Re: Let's paint those bikesheds^Werror messages!

[Sönke Ludwig via Digitalmars-d]

Am 27.06.2017 um 22:35 schrieb Vladimir Panteleev:

On Tuesday, 27 June 2017 at 20:19:14 UTC, Sönke Ludwig wrote:

I would argue pretty strongly that this should be toned down as much
as possible.


From the perspective of a personal preference, or an objective analysis?
It sounds like the former but isn't worded as one.


Intended to be more of the latter, especially as a consequence of the 
readability concern. The typical colorful syntax highlighting that is 
often used (lets say like the Monokai theme), starts to break down when 
it isn't used within its own context. Instead it starts to fight for 
attention with the error message and with the other colored text parts. 
The result can then be a net loss in visual structure.


Apart from color, there are other possible means to fix this, for 
example adding vertical spacing or delimiters between separate error 
messages.



All example schemes in the PR so far don't seem to add any real
readability value overall.


Readability and aesthetics are distinct goals!


True, and IMO, the former is what should be our primary goal. When that 
is reached, aesthetics can be optimized. But if we don't improve 
readability with this, what's the point of this feature?





Using a uniform dark gray background color for code could then solve
two issues: visually separating text from code and avoiding the
problem with differently configured default colors in the terminal.


Fairly sure painting parts of a line with a dark gray background is not
going to look great on an otherwise dark-on-light terminal. The terminal
excerpt blocks on dlang.org look kind of jarring already:
http://dlang.org/dmd-windows.html#library



But surely better than a light gray or white on white. Otherwise the 
whole text needs to have some kind of highly saturated color to avoid 
such situations by default. Just ruling out a white background would be 
a bad idea. I think on macOS that's the default, for example.

Re: Let's paint those bikesheds^Werror messages!

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 27 June 2017 at 20:19:14 UTC, Sönke Ludwig wrote:
I would argue pretty strongly that this should be toned down as 
much as possible.


From the perspective of a personal preference, or an objective 
analysis? It sounds like the former but isn't worded as one.


All example schemes in the PR so far don't seem to add any real 
readability value overall.


Readability and aesthetics are distinct goals!

Using a uniform dark gray background color for code could then 
solve two issues: visually separating text from code and 
avoiding the problem with differently configured default colors 
in the terminal.


Fairly sure painting parts of a line with a dark gray background 
is not going to look great on an otherwise dark-on-light 
terminal. The terminal excerpt blocks on dlang.org look kind of 
jarring already: http://dlang.org/dmd-windows.html#library

Re: Deprecated std.c.*.socket and missing replacement

[Sebastiaan Koppe via Digitalmars-d-learn]

On Tuesday, 27 June 2017 at 19:22:02 UTC, Steven Schveighoffer 
wrote:
Just delete the duplicate symbol, and add public imports of the 
other module symbols.


e.g.:

public import core.sys.posix.netinet.in_: IP_ADD_MEMBERSHIP;

-Steve


Great. Will do.

Re: Phobos PR in need of review/merge

[Steven Schveighoffer via Digitalmars-d]

On 6/27/17 3:54 PM, Seb wrote:

On Tuesday, 27 June 2017 at 19:15:46 UTC, Steven Schveighoffer wrote:
It's actually hard to figure out how github looks from a non-member 
account when you are a member, because you need a separate github login.


Private/In-cognito tab?


github doesn't always work or have all the UI available unless you are 
logged in. I don't have a non-dlang login to github, so I can't see what 
it looks like for others.


-Steve

Re: Let's paint those bikesheds^Werror messages!

[Sönke Ludwig via Digitalmars-d]

Am 27.06.2017 um 16:32 schrieb Vladimir Panteleev:

As has been announced, DMD now has colorized syntax highlighting in
error messages:

http://forum.dlang.org/post/of9oao$230j$1...@digitalmars.com

With 2.075's release near, now would be a good time to decide on a nice
color palette that looks fine on most terminals. So, please vote:

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

Obligatory:
- Yes, not everyone likes colors. You can turn all colors off with a
command-line switch.
- Yes, everyone agrees that having all colors be configurable would be
good. We still need defaults that are going to look OK on most terminals.
- Yes, no matter what colors we choose, they're going to look bad on
some terminal somewhere. Let's worry about the major platforms' most
common terminals for now.



I would argue pretty strongly that this should be toned down as much as 
possible. All example schemes in the PR so far don't seem to add any 
real readability value overall.


Spontaneously I'd suggest something like highlighting just keywords and 
punctuation with a single different color and making the keywords also 
bold. That would give the code snippets some structure, without letting 
them fight for attention with error/warning colors or other code snippets.


Using a uniform dark gray background color for code could then solve two 
issues: visually separating text from code and avoiding the problem with 
differently configured default colors in the terminal.

Re: Let's paint those bikesheds^Werror messages!

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 27 June 2017 at 17:11:32 UTC, H. S. Teoh wrote:
The cardinal rule of color selection: NEVER only set the 
foreground color or the background color alone.


Fun fact: this is why terminal.d's api is `color(fg, bg)` instead 
of foregroundColor and backgroundColor independently.


But, I actually hate it in terminals when individual lines have 
different background colors, it doesn't really help legibility 
since the surrounding clashing color continues to bleed the 
contrast. That's why terminal.d now has Color.DEFAULT values and 
I use that for the bg basically every time.


(Instead, as I've said a few times, I changed my terminal 
*emulator*, yes the display side of it, to adjust the palette 
based on what background is there. If you tell it to output color 
0 on 0, it will actually do gray on black, despite 0 on 7 being 
black on white. I figured the exact meaning of the palette 
entries were less important than consistent legibility, and I'm 
very happy with that. Now *any* program using *any* settings is 
usable for me, including in sunlight, without excessive eye 
strain. Big win.)

Re: Let's paint those bikesheds^Werror messages!

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 27 June 2017 at 17:41:35 UTC, qznc wrote:
I'm one of the rare people who use a light background in my 
terminal (like 99% of websites). It seems only dark backgrounds 
are considered, which is understandable.


I also use light backgrounds... so I'm advocating for the light 
bg people, but it is hard to actually win.


I think y'all should just use a better terminal emulator with a 
sane palette. The OS X terminal does a better job than xterm at 
least (and Cybershadow is testing on the osx terminal for the 
light bg in the pictures on github), but the best solution is to 
use a decent palette and adjust your greens and yellows and cyans 
to be legible on white.


Still, the dmd default are trying to be usable on white as well.

Re: Phobos PR in need of review/merge

[Seb via Digitalmars-d]

On Tuesday, 27 June 2017 at 19:15:46 UTC, Steven Schveighoffer 
wrote:

On 6/27/17 1:21 PM, Mike Wey wrote:

On 27-06-17 08:49, Walter Bright wrote:
You can also specifically request a review from one of Team 
Phobos:


https://github.com/orgs/dlang/teams/team-phobos/members

Just click on the [Reviwers] link.


Is that page private? I get an 404 error, and i can't find the 
page on github.




Yes, it's private.


However, the member list of an organization is public:

https://github.com/orgs/dlang/people
https://api.github.com/orgs/dlang/public_members?per_page=100

Note that:
- people need to actively set their name to public (so that 
everyone is part of this list)

- there is no association to repos and

It's actually hard to figure out how github looks from a 
non-member account when you are a member, because you need a 
separate github login.


Private/In-cognito tab?

I think you can request a review though pretty easily on a PR 
by clicking on the "Reviewers" link (has a little gear next to 
it) on the upper right.


Unfortunately only GH members can do this - though we should 
increase the team size here (and thus have more people who can 
help out).


Btw in case you didn't know this, you can ping _everyone_ of Team 
Phobos easily with @dlang/team-phobos (though I think only GH 
members can do this).

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

[bauss via Digitalmars-d-learn]

On Tuesday, 27 June 2017 at 10:14:16 UTC, Jonathan M Davis wrote:
On Tuesday, June 27, 2017 09:54:19 John Burton via 
Digitalmars-d-learn wrote:

[...]


Arguably, std.socket should have used structs instead of 
classes for sockets for precisely this reason (though there are 
some advantages in using inheritance with sockets). But yes, 
calling close manually is the correct thing to do. Relying on 
the GC to call a destructor/finalizer is error-prone. There is 
no guarantee that the memory will ever be freed (e.g. the 
runtime could choose to not bother doing cleanup on shutdown), 
and even if the GC does collect it, there are no guarantees 
about how soon it will do so. However, if you keep allocating 
memory with the GC, then over time, the GC will collect 
GC-allocated memory that isn't currently being used so that it 
can reuse the memory. So, you really don't need to worry about 
the memory unless it becomes a bottleneck. It will be collected 
and reused, not leaked.


[...]


I agree with that it should have been structs. The inheritance 
issue could be fixed by having a private member of the struct in 
a class, that way there could still be a class wrapper around it.

Re: What are the unused but useful feature you know in D?

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 27 June 2017 at 19:06:19 UTC, Random D user wrote:

On Monday, 26 June 2017 at 22:17:00 UTC, Moritz Maxeiner wrote:


Except Rust is in exactly the same boat as D, because the same 
issues that apply to `@trusted` apply to `unsafe`, as well.


Hmmm, I guess that's true. I don't really know a lot about 
Rust. Their safety story just sounds way more convincing and 
believable than D's. It would probably be the first language 
I'd look into if I was interested in low level safety critical 
code.


The power of having plenty of money to pay for (viral) marketing. 
Or in short: Propaganda.
Rust is a good PL, but in practice it isn't significantly safer 
than @safe D in my experience.
And you pay for that small difference dearly with productivity 
decrease (even after becoming comfortable with the borrow checker 
system).

Re: Let's paint those bikesheds^Werror messages!

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 27 June 2017 at 19:39:25 UTC, deadalnix wrote:

Please, please, please, just do the same as clang.


I don't think clang has this feature, so doing the same as clang 
would be a regression. We're in uncharted waters!

Re: Phobos PR in need of review/merge

[Brad Roberts via Digitalmars-d]

On 6/27/17 11:09 AM, Dukc via Digitalmars-d wrote:

But there is just no reason I see to keep a request in 
"alive" state if I don't check it actively anymore. The closed pr can be 
opened later if I or someone else wishes to push for it again.


There's a very good reason to leave requests open:  a closed request is 
gone, never to be seen again (yes, it's technically still findable if 
you search closed but not merged requests, but it's super unlikely to 
ever happen).  An open request, though one among many, is still 
discoverable.  It's in the list and eventually someone will ping it or 
stumble on it, or maybe one dream day there will be sufficient activity 
to chip away at the massive (350ish right now) queue of pulls and it'll 
be taken care of.

Re: Let's paint those bikesheds^Werror messages!

[deadalnix via Digitalmars-d]

On Tuesday, 27 June 2017 at 14:32:28 UTC, Vladimir Panteleev 
wrote:
As has been announced, DMD now has colorized syntax 
highlighting in error messages:


http://forum.dlang.org/post/of9oao$230j$1...@digitalmars.com

With 2.075's release near, now would be a good time to decide 
on a nice color palette that looks fine on most terminals. So, 
please vote:


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

Obligatory:
- Yes, not everyone likes colors. You can turn all colors off 
with a command-line switch.
- Yes, everyone agrees that having all colors be configurable 
would be good. We still need defaults that are going to look OK 
on most terminals.
- Yes, no matter what colors we choose, they're going to look 
bad on some terminal somewhere. Let's worry about the major 
platforms' most common terminals for now.


Please, please, please, just do the same as clang.

Re: Checked vs unchecked exceptions

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 27 June 2017 at 18:14:47 UTC, jag wrote:
As Tobias mentioned, there are safety implications to "auto" 
behavior. In the example below I am using C# and its "var" 
feature:


[...]


Your example uses variable type inference, which happens on the 
*caller* side, *not* the *callee* side, the latter of which being 
where both checked exceptions and return type inference happen.
The correct analogue to your example in the exception domain is 
thus *not* checked exceptions, but verifying the exception set 
*at the call site* (the same way you fix the variable type *at 
the call site* to `Employee`), which is exactly what you can do 
by exposing the function exception set via a trait.


Now the compiler is able to catch your mistake. This is the 
reason your code becomes safer when you express your intent 
clearly. You should have the option to state your intent 
clearly by listing the exceptions that can be thrown by a 
method.


As I have pointed out, your example occurs on the *caller* side, 
not the *callee* side. The proper solution is not for the callee 
to specify which exceptions it may throw, but for the caller to 
specify which exceptions it allows the callee to throw (using 
compile time introspection on the exception set).



In dynamic languages like Python [...]


None of this justifies putting the burden on the callee side 
(i.e. checked exceptions), instead of on the caller side (the 
latter being implementable in an idiomatic way using a trait as 
John has proposed).

Re: Let's paint those bikesheds^Werror messages!

[Random D user via Digitalmars-d]

On Tuesday, 27 June 2017 at 18:42:45 UTC, Vladimir Panteleev 
wrote:

On Tuesday, 27 June 2017 at 18:41:00 UTC, Random D user wrote:
What ever you do, please don't use extreme high intensity 
colors like red(255,0,0), green (0,255,0) or blue (0,0,255).


That's up to the terminal (or your configuration of it). 
Without making many assumptions, console applications are 
limited to 16 symbolic colors, with their exact values 
depending on the OS/terminal/configuration.


Right. I should've known that.
I guess I don't really use cmd prompt or bash much these days.
I'm pretty much always on windows and using Visual Studio for D, 
C/C++ and others with custom color plugin for errors. And GUI 
everywhere :).

Re: Deprecated std.c.*.socket and missing replacement

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/27/17 2:12 PM, Sebastiaan Koppe wrote:

On Tuesday, 27 June 2017 at 17:58:29 UTC, Jonathan M Davis wrote:
Why would you need to remove anything from Phobos? The enum in 
question is in a deprecated module. All that should need to happen is 
that the enum be added to the appropriate module in druntime, and then 
any code that uses it can import it from there.


- Jonathan M Davis


Except that the deprecated module (std.c.posix.socket) imports the 
module where I would like to add them (core.sys.posix.netinet.in_), 
resulting in duplicated symbols. Therefor they need to be removed.


Just delete the duplicate symbol, and add public imports of the other 
module symbols.


e.g.:

public import core.sys.posix.netinet.in_: IP_ADD_MEMBERSHIP;

-Steve

Re: Phobos PR in need of review/merge

[Steven Schveighoffer via Digitalmars-d]

On 6/27/17 1:21 PM, Mike Wey wrote:

On 27-06-17 08:49, Walter Bright wrote:

You can also specifically request a review from one of Team Phobos:

https://github.com/orgs/dlang/teams/team-phobos/members

Just click on the [Reviwers] link.


Is that page private? I get an 404 error, and i can't find the page on 
github.




Yes, it's private. It's actually hard to figure out how github looks 
from a non-member account when you are a member, because you need a 
separate github login.


I think you can request a review though pretty easily on a PR by 
clicking on the "Reviewers" link (has a little gear next to it) on the 
upper right.


-Steve

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/27/17 2:04 PM, Moritz Maxeiner wrote:

On Tuesday, 27 June 2017 at 15:24:00 UTC, Steven Schveighoffer wrote:

On 6/27/17 9:25 AM, Guillaume Piolat wrote:

On Tuesday, 27 June 2017 at 13:11:10 UTC, Steven Schveighoffer wrote:
But I would use a close method, and not destroy(obj). The reason is 
because often times, you have wrapper types around your socket type, 
and just one extra level of indirection means the destructor cannot 
be used to clean up the socket (you are not allowed to access 
GC-allocated resources in a destructor).


All destructor restrictions do not apply when it's not called by the GC.

There really are two categories of destructors: called by the GC and 
called deterministically. Their usage should not overlap.


Yes, Tango solved this by having a separate "finalize()" method. I 
wish we had something like this.


Well, technically speaking the `~this` for D classes *is* a finalizer 
that you may optionally manually call (e.g. via destroy).
It would be nice, though, to change class `~this` into a destructor and 
move the finalization into an extra method like `finalize`. Write a DIP?


I don't have enough motivation to do this. But if we do anything, we 
should look at what Tango has done. It may not work exactly for druntime 
because of existing code, but it obviously didn't need compiler changes 
to work.


-Steve

Re: Phobos PR in need of review/merge

[Meta via Digitalmars-d]

On Tuesday, 27 June 2017 at 18:09:01 UTC, Dukc wrote:
I think the issue here is that I don't remind often enough that 
I'm still waiting, or I do it at wrong place. What is the 
convention here?


The convention is to spend a lot of time waiting and pinging 
people until it finally gets merged. I think we can all agree 
that this approach really doesn't scale.

Re: What are the unused but useful feature you know in D?

[Random D user via Digitalmars-d]

On Monday, 26 June 2017 at 22:17:00 UTC, Moritz Maxeiner wrote:

On Monday, 26 June 2017 at 18:47:18 UTC, Random D user wrote:
Anyway, I think we could just have a compile time switch for 
defaults.


Imagine having n libraries with pairwise different required 
defaults used in your application. Say goodbye to combined 
compilation, hello n separate required compiler invocations.




Yeah, that's true. I didn't really think of full source 
compilation of libs in your project. I though .lib would've been 
compiled with some settings and you'd just link with that and 
work with its api.


Also in reality I wouldn't want to be able to cancel @nogc in a 
function, because then the attribute would just lose power and 
you couldn't trust it. I just used it as a simple example for the 
@ and @! syntax that I'd like to have in general. Which would 
allow a nice way of working with sections of code like this:

class
{
@nogc:or @!gc:
... some code ..
@gc:or @gc:
... more code ..
@nogc:or @!gc:
... even more code ..
}



Also I think @safe is a little bit broken (because of @trusted 
and even the very pros (d-devs) seem to get @trusted wrong on 
a regular basis (at least that's my perception)). Just bite 
the bullet and use Rust if you want to be actually safe.


Except Rust is in exactly the same boat as D, because the same 
issues that apply to `@trusted` apply to `unsafe`, as well.


Hmmm, I guess that's true. I don't really know a lot about Rust. 
Their safety story just sounds way more convincing and believable 
than D's. It would probably be the first language I'd look into 
if I was interested in low level safety critical code.

Relative lflag paths in dub on Windows

[jmh530 via Digitalmars-d-learn]

Is it possible to set relative -L paths on dub for Windows? 
Absolute paths work fine, just can't get relative paths working.


I was looking at the thread here
https://forum.dlang.org/post/dkwqrwzwqbrnaamlv...@forum.dlang.org
and came up with something like
{
...
"lflags": ["-L-L..\\libs\\"],
}

where the file structure contains folders dubproject\libs and 
dubproject\source.


It didn't work though.

Re: Let's paint those bikesheds^Werror messages!

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 27 June 2017 at 18:41:00 UTC, Random D user wrote:
What ever you do, please don't use extreme high intensity 
colors like red(255,0,0), green (0,255,0) or blue (0,0,255).


That's up to the terminal (or your configuration of it). Without 
making many assumptions, console applications are limited to 16 
symbolic colors, with their exact values depending on the 
OS/terminal/configuration.

Re: Let's paint those bikesheds^Werror messages!

[Random D user via Digitalmars-d]

On Tuesday, 27 June 2017 at 14:32:28 UTC, Vladimir Panteleev 
wrote:
With 2.075's release near, now would be a good time to decide 
on a nice color palette that looks fine on most terminals. So, 
please vote:


What ever you do, please don't use extreme high intensity colors 
like red(255,0,0), green (0,255,0) or blue (0,0,255). They'll 
burn through your eyes and look bad on either white or black.
If you replace 0s with 32 and 255s with 192 you'll get colors 
that are more easy on the eyes and will work better on both black 
and white backgrounds.


Another strategy is to use HSV.
Set saturation and value something decent like 80 and 75.
Then loop through hue with 360 / num_colors step + good offset.
Now you should get enough colors that are as far from each other 
as they can be and give good contrast.
You can quickly preview this in some photo editor, or maybe even 
faster by writing some d code :)


I guess the next level would be actual color design instead of 
nerdy math.

Re: Checked vs unchecked exceptions

[jag via Digitalmars-d]

As Tobias mentioned, there are safety implications to "auto" 
behavior. In the example below I am using C# and its "var" 
feature:


class A {
   public static Employee getFoo() {
  return getPoorPerformingEmployee();
   }
}

This is your code, in which you are calling A which was written 
by someone else:


class B {
   var foo = A.getFoo();
   foo.fire();
}

Now another programmer changes class A as follows:

class A {
   public static Missile getFoo() {
  return new Missile();
   }
}

Guess what happens now? You intended to fire an employee, but 
instead you have fired a missile. The compiler did not catch this 
grave mistake because you did not clearly state your intent. Your 
class B compiles fine because both Employee and Missile have a 
method named fire(). You could have expressed your intent more 
clearly like this:


class B {
   Employee foo = A.getFoo();
   foo.fire();
}

Now the compiler is able to catch your mistake. This is the 
reason your code becomes safer when you express your intent 
clearly. You should have the option to state your intent clearly 
by listing the exceptions that can be thrown by a method.


In dynamic languages like Python there is less ability to state 
intent clearly. As a result in such languages fewer bugs can be 
caught at compile time. More bugs show up at run time. This may 
be acceptable if the program is intended for internal use in a 
company, because when the program crashes they can call you to 
come and fix it because you are in the next office. But when 
reliability is important then the more opportunity there is to 
express intent and have the compiler verify your code against 
your intent, the better.

Re: Phobos PR in need of review/merge

[Dukc via Digitalmars-d]

On Tuesday, 27 June 2017 at 07:07:02 UTC, Seb wrote:
Recently [1] I deployed the first iteration of a daily cronjob 
for the Dlang-Bot


Good idea, definitely worth trying.

Re: Deprecated std.c.*.socket and missing replacement

[Sebastiaan Koppe via Digitalmars-d-learn]

On Tuesday, 27 June 2017 at 17:58:29 UTC, Jonathan M Davis wrote:
Why would you need to remove anything from Phobos? The enum in 
question is in a deprecated module. All that should need to 
happen is that the enum be added to the appropriate module in 
druntime, and then any code that uses it can import it from 
there.


- Jonathan M Davis


Except that the deprecated module (std.c.posix.socket) imports 
the module where I would like to add them 
(core.sys.posix.netinet.in_), resulting in duplicated symbols. 
Therefor they need to be removed.

[Issue 6880] Heisenbug: deferred crash when writing to stdout on Windows without console.

[via Digitalmars-d-bugs]

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

--- Comment #8 from Vladimir Panteleev  ---
As I understand, what happens here is:

1. The program starts, and writes data to stdout / stderr
2. The data goes into the C FILE* buffer
3. When the buffer fills up, the C runtime attempts to flush it
4. Upon flushing, it discovers that the output handle in non-writable

Perhaps the runtime could detect an unwritable stdout/stderr and close (or
otherwise make invalid) the respective std.stdio handles.

Though, even if writeln was changed to check if the output handle is writable
on first or every write, the steps to reproduce would still apply - a forgotten
writeln inside some rarely-executed code, such as an error handler, can still
go through initial testing and end up crashing the application on the
end-user's site.

--

Re: Phobos PR in need of review/merge

[Dukc via Digitalmars-d]

On Tuesday, 27 June 2017 at 01:35:31 UTC, Meta wrote:
Recently, a pull request was closed out of frustration by the 
submitter: https://github.com/dlang/phobos/pull/5309


Topic reporting for duty :)

I have no hard feelings about this... I just want to collect my 
garbage when my requests stall. I understand good coders are 
often too busy to go trough all waiting requests thoughtfully, 
and it's ok if something slips past. But there is just no reason 
I see to keep a request in "alive" state if I don't check it 
actively anymore. The closed pr can be opened later if I or 
someone else wishes to push for it again.


I think the issue here is that I don't remind often enough that 
I'm still waiting, or I do it at wrong place. What is the 
convention here?

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

[Moritz Maxeiner via Digitalmars-d-learn]

On Tuesday, 27 June 2017 at 15:24:00 UTC, Steven Schveighoffer 
wrote:

On 6/27/17 9:25 AM, Guillaume Piolat wrote:
On Tuesday, 27 June 2017 at 13:11:10 UTC, Steven Schveighoffer 
wrote:
But I would use a close method, and not destroy(obj). The 
reason is because often times, you have wrapper types around 
your socket type, and just one extra level of indirection 
means the destructor cannot be used to clean up the socket 
(you are not allowed to access GC-allocated resources in a 
destructor).


All destructor restrictions do not apply when it's not called 
by the GC.


There really are two categories of destructors: called by the 
GC and called deterministically. Their usage should not 
overlap.


Yes, Tango solved this by having a separate "finalize()" 
method. I wish we had something like this.


Well, technically speaking the `~this` for D classes *is* a 
finalizer that you may optionally manually call (e.g. via 
destroy).
It would be nice, though, to change class `~this` into a 
destructor and move the finalization into an extra method like 
`finalize`. Write a DIP?

Re: Deprecated std.c.*.socket and missing replacement

[Jonathan M Davis via Digitalmars-d-learn]

On Tuesday, June 27, 2017 3:46:39 PM MDT Sebastiaan Koppe via Digitalmars-d-
learn wrote:
> On Tuesday, 27 June 2017 at 11:16:17 UTC, Jonathan M Davis wrote:
> > Create a PR to add it to druntime and/or define it in your own
> > code.
> >
> > - Jonathan M Davis
>
> Creating a PR sounds reasonable. But I would have to create one
> PR to remove them from phobos and one PR to add them to druntime,
> right? (I need to remove them since the phobos socket modules
> import the druntime ones, create duplicates if not removed)
>
> I see that std.c.windows.winsock simply publicly imports
> core.sys.windows.winsock2, that looks like a good approach.

Why would you need to remove anything from Phobos? The enum in question is
in a deprecated module. All that should need to happen is that the enum be
added to the appropriate module in druntime, and then any code that uses it
can import it from there.

- Jonathan M Davis

Re: Let's paint those bikesheds^Werror messages!

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 27 June 2017 at 17:41:35 UTC, qznc wrote:
Is there a way to do this globally? For example, a config file 
or an environment variable?


I believe you can add -color=off to DFLAGS in sc.ini / dmd.conf.

It seems only dark backgrounds are considered, which is 
understandable.


Not true. If you follow the link, you can see that one of the 
tested terminals has a dark-on-light color scheme (macOS 
Terminal.app). Unfortunately, even the "dark" colors look very 
bright on Terminal.app. It's likely they will look better in your 
terminal.

Re: Let's paint those bikesheds^Werror messages!

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 27 June 2017 at 17:28:42 UTC, H. S. Teoh wrote:
I've seen complaints from people who have black-on-white 
terminals (or vice versa) finding some programs producing 
unreadable text because the program set the foreground color to 
black without also setting the background.  Of course, it's 
rare that programs would explicitly set black or white 
foreground, but I happen to use a light green background for my 
terminals and so a green foreground, for example, would be 
pretty unreadable for me.


Unless the program is a full-screen application, setting the 
background color is the wrong solution. It will just make the 
terminal look like a zebra, alternating contrast every time the 
program's output starts and ends. I.e.: awful, which is why 
nobody does this.


The point is that you can't predict what the default background 
color is set to, so unless you set both, there will always be 
some case where it looks bad or is outright unreadable.


This is why the screenshots I generated include both 
dark-on-light and light-on-dark terminals. It is not impossible 
to choose a color set that will look okay on both.

Re: Let's paint those bikesheds^Werror messages!

[qznc via Digitalmars-d]

On Tuesday, 27 June 2017 at 14:32:28 UTC, Vladimir Panteleev 
wrote:
- Yes, not everyone likes colors. You can turn all colors off 
with a command-line switch.


Is there a way to do this globally? For example, a config file or 
an environment variable?


I'm one of the rare people who use a light background in my 
terminal (like 99% of websites). It seems only dark backgrounds 
are considered, which is understandable.

Re: Let's paint those bikesheds^Werror messages!

[H. S. Teoh via Digitalmars-d]

On Tue, Jun 27, 2017 at 05:24:46PM +, Vladimir Panteleev via Digitalmars-d 
wrote:
> On Tuesday, 27 June 2017 at 17:11:32 UTC, H. S. Teoh wrote:
> > The cardinal rule of color selection: NEVER only set the foreground
> > color or the background color alone. ALWAYS set both, otherwise you
> > will get invisible text (or barely-visible text, like yellow on
> > white) on somebody's terminal, and they will be very, very angry.
> 
> Nothing actually does that... so I don't think that's true. Maybe on
> the web, but not in terminals.

I've seen complaints from people who have black-on-white terminals (or
vice versa) finding some programs producing unreadable text because the
program set the foreground color to black without also setting the
background.  Of course, it's rare that programs would explicitly set
black or white foreground, but I happen to use a light green background
for my terminals and so a green foreground, for example, would be pretty
unreadable for me.

The point is that you can't predict what the default background color is
set to, so unless you set both, there will always be some case where it
looks bad or is outright unreadable.


T

-- 
What are you when you run out of Monet? Baroque.

Re: Let's paint those bikesheds^Werror messages!

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 27 June 2017 at 17:32:23 UTC, FoxyBrown wrote:
This will be a nightmare if you do not allow it to be 
configurable! Hard coding anything is very bad when others are 
will use it.


Make a default color scheme that works for the majority as you 
are, but then allow it to be easily changed. E.g., it can read 
a config file or passed through the command line(possibly 
different color schemes can be selected). Do it right or suffer 
the consequences!


If you feel so strongly about this, please submit a PR!

Either way, -color=off has been there for a while.

Re: Let's paint those bikesheds^Werror messages!

[FoxyBrown via Digitalmars-d]

On Tuesday, 27 June 2017 at 14:32:28 UTC, Vladimir Panteleev 
wrote:
As has been announced, DMD now has colorized syntax 
highlighting in error messages:


http://forum.dlang.org/post/of9oao$230j$1...@digitalmars.com

With 2.075's release near, now would be a good time to decide 
on a nice color palette that looks fine on most terminals. So, 
please vote:


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

Obligatory:
- Yes, not everyone likes colors. You can turn all colors off 
with a command-line switch.
- Yes, everyone agrees that having all colors be configurable 
would be good. We still need defaults that are going to look OK 
on most terminals.
- Yes, no matter what colors we choose, they're going to look 
bad on some terminal somewhere. Let's worry about the major 
platforms' most common terminals for now.



This will be a nightmare if you do not allow it to be 
configurable! Hard coding anything is very bad when others are 
will use it.


Make a default color scheme that works for the majority as you 
are, but then allow it to be easily changed. E.g., it can read a 
config file or passed through the command line(possibly different 
color schemes can be selected). Do it right or suffer the 
consequences!

Re: Let's paint those bikesheds^Werror messages!

[Vladimir Panteleev via Digitalmars-d]

On Tuesday, 27 June 2017 at 17:11:32 UTC, H. S. Teoh wrote:
The cardinal rule of color selection: NEVER only set the 
foreground color or the background color alone. ALWAYS set 
both, otherwise you will get invisible text (or barely-visible 
text, like yellow on white) on somebody's terminal, and they 
will be very, very angry.


Nothing actually does that... so I don't think that's true. Maybe 
on the web, but not in terminals.

Re: Phobos PR in need of review/merge

[Mike Wey via Digitalmars-d]

On 27-06-17 08:49, Walter Bright wrote:

You can also specifically request a review from one of Team Phobos:

https://github.com/orgs/dlang/teams/team-phobos/members

Just click on the [Reviwers] link.


Is that page private? I get an 404 error, and i can't find the page on 
github.


--
Mike Wey

Re: Checked vs unchecked exceptions

[Moritz Maxeiner via Digitalmars-d]

On Tuesday, 27 June 2017 at 16:01:37 UTC, mckoder wrote:

On Tuesday, 27 June 2017 at 11:40:02 UTC, Moritz Maxeiner wrote:


It's not at all bad code to write things down that the 
compiler could infer, quite the opposite.


Of course it is bad, because the compiler can do it better (no 
chance for a wrong exception set sans compiler bugs) and 
faster than you.


Writing it down signals _intent_ and the compiler can check 
if the implementation is matching the specification


Verifying that a function meets its specification is what 
unittests are for (asserts for runtime behaviour, static 
asserts for types).


You might as well argue that you shouldn't have to declare the 
return type of functions because the compiler can determine 
that automatically based on the types of values you are 
actually returning.


Of *course* you shouldn't have to (-> auto functions [1]).
The difference being, of course, that specifying the return type 
is always only a single type, whereas specifying the exception 
set blows up in verbosity with each additional level of call 
hierarchy.


Then write unit tests to make sure that the return type as 
determined by the compiler matches what you intended.


If you don't trust the compiler's return type inference you can 
do that, of course.
Though in contrast to the exception set there's a lot less reason 
to do so in the return type case, because it's only a single type 
not an arbitrarily large set of types.


[1] https://dlang.org/spec/function.html#auto-functions

Re: Let's paint those bikesheds^Werror messages!

[H. S. Teoh via Digitalmars-d]

On Tue, Jun 27, 2017 at 02:32:28PM +, Vladimir Panteleev via Digitalmars-d 
wrote:
> As has been announced, DMD now has colorized syntax highlighting in
> error messages:
> 
> http://forum.dlang.org/post/of9oao$230j$1...@digitalmars.com
> 
> With 2.075's release near, now would be a good time to decide on a
> nice color palette that looks fine on most terminals. So, please vote:
> 
> https://github.com/dlang/dmd/pull/6943
> 
> Obligatory:
> - Yes, not everyone likes colors. You can turn all colors off with a
> command-line switch.
> - Yes, everyone agrees that having all colors be configurable would be
> good.  We still need defaults that are going to look OK on most
> terminals.
> - Yes, no matter what colors we choose, they're going to look bad on
> some terminal somewhere. Let's worry about the major platforms' most
> common terminals for now.

The cardinal rule of color selection: NEVER only set the foreground
color or the background color alone. ALWAYS set both, otherwise you will
get invisible text (or barely-visible text, like yellow on white) on
somebody's terminal, and they will be very, very angry.


T

-- 
Marketing: the art of convincing people to pay for what they didn't need before 
which you fail to deliver after.

Re: Checked vs unchecked exceptions

[Sebastien Alaiwan via Digitalmars-d]

On Tuesday, 27 June 2017 at 10:18:04 UTC, mckoder wrote:
"I think that the belief that everything needs strong static 
(compile-time) checking is an illusion; it seems like it will 
buy you more than it actually does. But this is a hard thing to 
see if you are coming from a statically-typed language."


Source: 
https://groups.google.com/forum/#!original/comp.lang.java.advocacy/r8VPk4deYDI/qqhL8g1uvf8J


If you like dynamic languages such as Python you probably agree 
with Bruce Eckel. If you are a fan of static checking then I 
don't see how you can like that.


A quote from Uncle Bob about too much static typing and checked 
exceptions:


http://blog.cleancoder.com/uncle-bob/2017/01/11/TheDarkPath.html

"My problem is that [Kotlin and Swift] have doubled down on 
strong static typing. Both seem to be intent on closing every 
single type hole in their parent languages."


"I would not call Java a strongly opinionated language when it 
comes to static typing. You can create structures in Java that 
follow the type rules nicely; but you can also violate many of 
the type rules whenever you want or need to. The language 
complains a bit when you do; and throws up a few roadblocks; but 
not so many as to be obstructionist.


Swift and Kotlin, on the other hand, are completely inflexible 
when it comes to their type rules. For example, in Swift, if you 
declare a function to throw an exception, then by God every call 
to that function, all the way up the stack, must be adorned with 
a do-try block, or a try!, or a try?. There is no way, in this 
language, to silently throw an exception all the way to the top 
level; without paving a super-hiway for it up through the entire 
calling tree."

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

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #6 from Vladimir Panteleev  ---
No reply in over a year, attempts to reproduce failed. Closing.

--

[Issue 17562] Tangent function returns NaN for abs(input) >= 2^63

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

   Keywords||pull
 CC||dlang-bugzilla@thecybershad
   ||ow.net

--

[Issue 15982] std.array.array treats dynamic arrays as input ranges and allocates new memory

[via Digitalmars-d-bugs]

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

Vladimir Panteleev  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dlang-bugzilla@thecybershad
   ||ow.net
 Resolution|--- |WONTFIX

--- Comment #11 from Vladimir Panteleev  ---
As discussed above, std.array.array currently guarantees that the data it
returns is unique. This guarantee in turn allows some assumptions, such as that
writing to the result will not have side effects, that it is safe to pass to
other parts of the program, or even delete it. I suppose that if the array were
to point to immutable elements, avoiding reallocation might be worth
considering; though, currently, even .idup will duplicate an immutable array.

As it is, this issue is missing a use case, and it will probably need to be a
compelling one to warrant changing the function's contract and risking code
breakage. Other than that... well, if you don't want your array reallocated,
then just don't call array()?

Please reopen if you have a good argument why this should be changed despite
the above.

--

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/27/17 12:16 PM, Steven Schveighoffer wrote:

On 6/27/17 11:24 AM, Steven Schveighoffer wrote:

On 6/27/17 9:25 AM, Guillaume Piolat wrote:


That's how the GC-proof resource class came to existence, after many 
destruction bugs, and it let's you use the GC as a detector for 
non-deterministic destruction. I miss it in @nogc :)


https://p0nce.github.io/d-idioms/#GC-proof-resource-class


There are definitely better ways to do this than trying to allocate 
and catching an error. The GC knows the GC is running, use that 
mechanism instead :)


https://github.com/dlang/druntime/blob/master/src/gc/gcinterface.d#L189
https://github.com/dlang/druntime/blob/master/src/core/memory.d#L150

Apparently that info is limited to the core.memory package. But it's 
extern(C), so declaring the prototype should work. Should be much more 
efficient than allocating a byte (which I see you don't delete if it 
works), and catching an error.


Just added this enhancement to publicize this function: 
https://issues.dlang.org/show_bug.cgi?id=17563


-Steve

[Issue 17563] New: gc_inFinalizer should be public

[via Digitalmars-d-bugs]

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

  Issue ID: 17563
   Summary: gc_inFinalizer should be public
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: schvei...@yahoo.com

Currently there's a function gc_inFinalizer here:
https://github.com/dlang/druntime/blob/master/src/core/memory.d#L150

This function allows one to tell inside a destructor whether the GC finalizer
is running or not. This is currently the only way a destructor can tell whether
it's in the GC finalizer stage or not (you should only access GC members if not
inside the finalizer).

A crude and horrible way to check for this is to try allocating inside the
destructor, and catching the Error (an Error is thrown if inFinalizer is true).
There's no reason we shouldn't just allow others to call this (they technically
can already since it's extern(C)). It should be made part of the core.memory
interface.

--

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/27/17 11:24 AM, Steven Schveighoffer wrote:

On 6/27/17 9:25 AM, Guillaume Piolat wrote:


That's how the GC-proof resource class came to existence, after many 
destruction bugs, and it let's you use the GC as a detector for 
non-deterministic destruction. I miss it in @nogc :)


https://p0nce.github.io/d-idioms/#GC-proof-resource-class


There are definitely better ways to do this than trying to allocate and 
catching an error. The GC knows the GC is running, use that mechanism 
instead :)


https://github.com/dlang/druntime/blob/master/src/gc/gcinterface.d#L189
https://github.com/dlang/druntime/blob/master/src/core/memory.d#L150

Apparently that info is limited to the core.memory package. But it's 
extern(C), so declaring the prototype should work. Should be much more 
efficient than allocating a byte (which I see you don't delete if it 
works), and catching an error.


-Steve

Re: Checked vs unchecked exceptions

[mckoder via Digitalmars-d]

On Tuesday, 27 June 2017 at 11:40:02 UTC, Moritz Maxeiner wrote:


It's not at all bad code to write things down that the 
compiler could infer, quite the opposite.


Of course it is bad, because the compiler can do it better (no 
chance for a wrong exception set sans compiler bugs) and faster 
than you.


Writing it down signals _intent_ and the compiler can check if 
the implementation is matching the specification


Verifying that a function meets its specification is what 
unittests are for (asserts for runtime behaviour, static 
asserts for types).


You might as well argue that you shouldn't have to declare the 
return type of functions because the compiler can determine that 
automatically based on the types of values you are actually 
returning. Then write unit tests to make sure that the return 
type as determined by the compiler matches what you intended.

C++ Metaclasses proposal

[Enamex via Digitalmars-d]

PDF: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r0.pdf
Reddit: 
https://www.reddit.com/r/programming/comments/6js4uv/metaclasses_in_c/


I thought a bit on possible patterns in D to accomplish the same 
without string mixins.


For example, defining the prototype `Foo_` then mixing in `mixin 
MyMetaclass!Foo_ Foo`.


Got stuck trying to 'forward' (or copy the implementation of) 
functions in `Foo_` into `Foo` after modifying them, though.


Besides trying to do it in D (please try still!), what do you 
think of the idea? In general and say versus a robust macro 
system with some level of access to CTFE? Or even just a good 
macro system (someone began discussing this on the reddit thread; 
talking about Racket macros).

Re: D error messages for function call mismatches

[FoxyBrown via Digitalmars-d]

On Tuesday, 27 June 2017 at 15:01:41 UTC, Adam D. Ruppe wrote:

On Tuesday, 27 June 2017 at 14:29:05 UTC, FoxyBrown wrote:
D's error messaging is terrible in some ways. I am trying to 
get some code to work and this is the error:


I agree, that error message is terrible, and that's why I have 
a PR open to change it.


But this specific case is weird to me too. stb_truetype.d is a 
port from C code, and I use it without any compile errors. Did 
you modify the code?



Find the bug!


Even worse, I don't even see an error in that error message. 
The arguments it lists look acceptable.


Hi Adam,

Yeah, I don't know, I think I had it working before but now it 
seems a lot of your code is not working. I did not change the 
std_truetype.d file. Just to make sure I copied and pasted the 
git source in to the original.


alias STBTT_sort = core.stdc.stdlib.qsort;

Is it possible that core.stdc.stdlib.qsort changed?

voidqsort(scope void* base, size_t nmemb, size_t size, 
_compare_fp_t

compar);


arsd\stb_truetype.d(1251): Error: function core.stdc.stdlib.qsort 
(scope void* base, uint nmemb, uint size, extern (C) int 
function(scope const(void*), scope const(void*)) @system compar) 
is not callable using argument types (void*, uint, uint, extern 
(C) int function(const(void*) p, const(void*) q))


I changed your variables to size_t and they obviously match. The 
things that don't match are the scope's.


qsort(scope void* base, uint nmemb, uint size, extern (C) int 
function(scope const(void*), scope const(void*)) @system compar)


   (void*,  uint,   uint,  extern (C) int 
function(const(void*) p, const(void*) q))




I am also getting a run time error with your png loading module.


void popFront () {
bufpos = 0;
while (plpos != plpos.max && bufpos < 
chunkSize) {
// do we have some bytes in zstream?
if (zs.avail_in > 0) {
// just unpack
zs.next_out = 
cast(typeof(zs.next_out))(buffer.ptr+bufpos);
int rd = chunkSize-bufpos;
zs.avail_out = rd;
auto err = inflate(, 
Z_SYNC_FLUSH);
		if (err != Z_STREAM_END && err != Z_OK) throw new 
Exception("PNG unpack error");


Errors out with unpack error. This code used to work so it is 
probably on my system.

Re: Deprecated std.c.*.socket and missing replacement

[Sebastiaan Koppe via Digitalmars-d-learn]

On Tuesday, 27 June 2017 at 11:16:17 UTC, Jonathan M Davis wrote:
Create a PR to add it to druntime and/or define it in your own 
code.


- Jonathan M Davis


Creating a PR sounds reasonable. But I would have to create one 
PR to remove them from phobos and one PR to add them to druntime, 
right? (I need to remove them since the phobos socket modules 
import the druntime ones, create duplicates if not removed)


I see that std.c.windows.winsock simply publicly imports 
core.sys.windows.winsock2, that looks like a good approach.

Re: Advice wanted on garbage collection of sockets for c++ programmer using D

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/27/17 9:25 AM, Guillaume Piolat wrote:

On Tuesday, 27 June 2017 at 13:11:10 UTC, Steven Schveighoffer wrote:
But I would use a close method, and not destroy(obj). The reason is 
because often times, you have wrapper types around your socket type, 
and just one extra level of indirection means the destructor cannot be 
used to clean up the socket (you are not allowed to access 
GC-allocated resources in a destructor).


All destructor restrictions do not apply when it's not called by the GC.

There really are two categories of destructors: called by the GC and 
called deterministically. Their usage should not overlap.


Yes, Tango solved this by having a separate "finalize()" method. I wish 
we had something like this.




My reasoning went with the following:

1 - "I should have close() methods so that I don't rely on the GC, and 
the GC is calling ~this from the wrong thread etc, not everything can be 
released in this context (eg: OpenGL objects should be released from one 
thread only). Close methods will call close methods of "owned" objects."


I hadn't realized this, that is a good point. However, not all resources 
are restricted this much.


That's how the GC-proof resource class came to existence, after many 
destruction bugs, and it let's you use the GC as a detector for 
non-deterministic destruction. I miss it in @nogc :)


https://p0nce.github.io/d-idioms/#GC-proof-resource-class


There are definitely better ways to do this than trying to allocate and 
catching an error. The GC knows the GC is running, use that mechanism 
instead :)


Remember years ago when Alexandrescu suggested the GC shouldn't call 
heap destructors? That's what we get for having said no at the time.


No, the issue is that there isn't a separate call for destruction and 
GC. I think we should add this.


The GC still needs to call something to clean up non-memory resources, 
but having a call to use when cleaning up deterministically can make 
resource management more efficient (even memory resource management).


-Steve

-Steve

Re: Clean Executable

[bauss via Digitalmars-d-learn]

On Tuesday, 27 June 2017 at 14:21:50 UTC, FoxyBrown wrote:
How can we clean an exe from the junk library functions that 
are not actually used by an app. e.g., a hello world program 
shouldn't be 500+kb. I release there are necessary extras like 
the GC, but hell, in a hello world program is it even 
necessary? Does Writeln even use the GC to display a single 
string?


Seems like D just does not optimize the binaries size. I know 
it's only 500kb, but still.


If you want optimizations don't use DMD.

Re: Clean Executable

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

On Tuesday, 27 June 2017 at 14:21:50 UTC, FoxyBrown wrote:

Does Writeln even use the GC to display a single string?


Not if all goes well, but a good chunk of the library is loaded 
to handle various situations. It might call a GC function if 
there's no stdout.


Take a look at this:

http://thecybershadow.net/d/mapview/data/5952742b0b88b.html

There's a lot of functions loaded from the library for cases that 
are very rare... like error writing out hello world is actually 
detected and thrown as an exception. There's also things in for 
module initializers and class factories that you don't use, but 
it is intertwined enough that the linker isn't able to optimize 
it out.



In a larger program, you'd probably actually use this stuff so 
the cost would diminish, but for a small program it is a bit 
tangled at this level.