Re: colour lib needs reviewers

[Andrei Alexandrescu via Digitalmars-d]

On 9/14/16 9:28 PM, Manu via Digitalmars-d wrote:

Like, I really just don't care enough to try and understand ddoc
sufficiently to have a bag of tricks like those you demonstrated above
to workaround these issues. It's not a skill I *want* to possess,
rather, in this case, it's a skill I'm being forced into.
You're welcome to call me lazy, I'd suggest I'm being realistic.
Perhaps a phobos contributor will be required to work it out (as seems
to be a requirement for me right now), but normal programmers
wouldn't. In 7 years, I've never been motivated to find workarounds to
ddoc shortcomings before now, and now, it's only because people are
hassling me. There's no intrinsic motivation here... one reason I use
D is because I hate the C preprocessor ;)


I don't see those workarounds to ddoc shortcomings. m4 and all macro 
systems I know of have similar idioms. It's the nature of macro 
processing. Are you simply saying you're familiar with other 
documentation tools and are not motivated to get into another one? 
That's entirely fair.



If I had to suggest, I'd introduce doxygen style \tags alongside the
macros, then when people try and type docs in the way they've been
doing for decades, it'll just work, and they can get on with their
code. Nobody likes writing documentation, it needs to have the minimum
possible friction or people just won't.


I have difficulty understanding this. I haven't looked at Doxygen in a 
long time and never really used it, but from what I see at 
https://www.stack.nl/~dimitri/doxygen/manual/commands.html it seems the 
\tags you refer to are just a form of macros. The syntax is different, 
i.e. you'd write \a hello whereas in html you'd write hello, in 
latex \textit{hello}, in ddoc $(I hello). It's a matter of syntax and 
though I agree syntax matters (and it would be nice to make ddoc's more 
configurable), is it right to assume you simply want a syntax you're 
more familiar with?


How do you mean people "type docs in the way they've been doing for 
decades"? Are you implying doxygen not only has been around for decades, 
but it's been some sort of ubiquitous standard? Honest question, I'm 
definitely not getting that.


Does this boil down to - if we replace the macro syntax with one closer 
to doxygen things will just click? (That may as well be the case.)



Andrei

Re: Getting a String Literal From an Aliased Template Mixin Parameter

[jsako via Digitalmars-d-learn]

On Thursday, 15 September 2016 at 01:40:50 UTC, Anonymouse wrote:

You mean, the literal string name of the original symbol you 
passed as an alias? If so then you want the .stringof property.


void main () {
int first;
bool second;
string third;

mixin Foo!(first, second, third);
}

mixin template Foo(alias abc, alias def, alias ghi)
{
static assert(abc.stringof == "first");
static assert(def.stringof == "second");
static assert(ghi.stringof == "third");
}


Aha! Yes, that's exactly what I was looking for! Thanks!

[Issue 16193] opApply() doesn't heap allocate closure

[via Digitalmars-d-bugs]

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

--- Comment #6 from Walter Bright  ---
Not a fix for this bug, but Phobos should be fixed:

https://github.com/dlang/phobos/pull/4787

--

Re: Using OpenGL

[Mike Parker via Digitalmars-d-learn]

On Wednesday, 14 September 2016 at 16:49:51 UTC, Darren wrote:



While googling, the idea seemed to be to create and 
SDL_Surface* and pass that (or surface.pixels) as the last 
argument for glTexImage2D.  Didn't work for me, however.


Does anyone have any tips?


I'm driving blind here without any of your code to see, but 
here's some general advice.


The last three arguments to glTexImage2D [1] are what you use to 
describe the image data you are sending to it (aside from 'width' 
& 'height', which also set the size of the texture being created).


`format` needs to match the format of your image. For most simple 
things you do with OpenGL, that's going to be GL_RGB or GL_RGBA. 
If you don't know the format of your image, you can get it from 
the SDL_PixelFormatEnum value [2] in surface.format.format. Then 
you'll just need to send the corresponding GL enum to 
glTexImage2D. Though, be aware that the way SDL and OGL treat 
color formats may not always correspond in the way you think they 
should [3].


`type` is almost always going to be GL_UNSIGNED_BYTE. I don't 
know that SDL_image supports anything else, like floating point 
formats, anyway.


`data` needs to be a pointer to the pixel data and nothing else 
(never SDL_Surface!), so in this case surface.pixels is correct.


If you are getting a crash, check the return of any of the image 
loading functions you call to make sure the load was successful. 
That's the first place I'd check.


[1] https://www.opengl.org/sdk/docs/man/html/glTexImage2D.xhtml
[2] https://wiki.libsdl.org/SDL_PixelFormatEnum
[3] https://bugzilla.libsdl.org/show_bug.cgi?id=2111

Re: Getting a String Literal From an Aliased Template Mixin Parameter

[Anonymouse via Digitalmars-d-learn]

On Thursday, 15 September 2016 at 00:15:42 UTC, jsako wrote:
I was making a quick mocking infrastructure for internal mocks 
so I wouldn't have to pass in objects to constructors all the 
time and came up with this:


[...]

This works great as long as there is only one mock object. I 
thought about using string mixins to generate the properties on 
a per-variable basis, but the problem is that I can't figure 
out how to get the string of the variable name from the aliased 
template mixin parameter. Is there a way to do this?


If not, I'll have to pass in the strings of the variables 
seperately (as in: mixin internalMockRig!(thing, "thing", 
testThing, "testThing", testThingMock, "testThingMock"); ), but 
that seems inelegant (and a bit error prone).


You mean, the literal string name of the original symbol you 
passed as an alias? If so then you want the .stringof property.


void main () {
int first;
bool second;
string third;

mixin Foo!(first, second, third);
}

mixin template Foo(alias abc, alias def, alias ghi)
{
static assert(abc.stringof == "first");
static assert(def.stringof == "second");
static assert(ghi.stringof == "third");
}

Re: colour lib needs reviewers

[Manu via Digitalmars-d]

On 15 September 2016 at 07:31, Andrei Alexandrescu via Digitalmars-d
 wrote:
> On 09/14/2016 09:28 AM, Manu via Digitalmars-d wrote:
>>
>> ... I'm just gonna go on the record and say that I am really, really
>> not enjoying ddoc ;)
>
>
> I was using ddoc today for the Greeks in DIP1000 and was musing about what
> makes it annoying. I think a major part is the macro invocation syntax:
> $(MACRO a1, a2, a3). After writing it for a few dozen times today, I figured
> it's objectively awkward to type (at least on the US keyboard): the dollar
> sign followed by the left paren is just unpleasant for mechanical reasons.
>
> The resulting look is alien too, as opposed to the more familiar $MACRO(a1,
> a2, a3) or the CPP-style MACRO(a1, a2, a3).
>
> There are a couple of un(der)documented tricks without which life is very
> difficult. For example, people commonly believe that in order to embed a
> literal comma they need to go like this:
>
> COMMA = ,
>
> and then $(MACRO Hello$(COMMA) world, a2). That scales poorly with the size
> of the argument. In fact, there's a much better solution:
>
> ARGS = $0
>
> and then $(MACRO $(ARGS Hello, world), a2) allows any amount of text with
> commas. Sadly no similar solution for unpaired parens.
>
> Also, the fact that the doc opens with the text and then has an obscure
> "Macros:" line at a point is unpleasant. The macro definitions should come
> first, followed by a separator and then the content. That would make for a
> much nicer flow.
>
> There are a few other macros I never leave home without:
>
> ARGS = $0
> COMMA = ,
> DOLLAR = $
> LPAREN = (
> RPAREN = )
> TAIL = $+
> COLON = :
> LF = $(LF)
> $(LF)
> COMMENT =
> SP = $(COMMENT space coming) $(COMMENT that was a space)
>
> TAIL sadly doesn't work properly.
>
> Overall: I'm trying to build a list of ddoc grievances that can be fixed.
> It's the de jure and de facto standard for D documentation (with the ddoc
> processor or ddox), so we'd do good to improve it.
>
> Please add your own ideas.

I haven't had enough experience for meaningful input. I have
experienced the comma and parens things myself, and I generally just
hate that everything is a macro, like you said yourself above.
It didn't occur to me to attempt the sort of workarounds you
illustrated here, I rather just factored the commas and parens out of
my docs and moved on ;)

Like, I really just don't care enough to try and understand ddoc
sufficiently to have a bag of tricks like those you demonstrated above
to workaround these issues. It's not a skill I *want* to possess,
rather, in this case, it's a skill I'm being forced into.
You're welcome to call me lazy, I'd suggest I'm being realistic.
Perhaps a phobos contributor will be required to work it out (as seems
to be a requirement for me right now), but normal programmers
wouldn't. In 7 years, I've never been motivated to find workarounds to
ddoc shortcomings before now, and now, it's only because people are
hassling me. There's no intrinsic motivation here... one reason I use
D is because I hate the C preprocessor ;)

If I had to suggest, I'd introduce doxygen style \tags alongside the
macros, then when people try and type docs in the way they've been
doing for decades, it'll just work, and they can get on with their
code. Nobody likes writing documentation, it needs to have the minimum
possible friction or people just won't.

Added bonus; when you cut C code to adapt bindings, the existing
docs on the C code would remain valid documentation without additional
amendment.
I bind C code regularly, and my goto 'solution' is to just remove the
doxygen doco comments from the translated code and point them to the
C/C++ docs instead.
Again, call me what you like, I think my behaviour is probably typical
though. I'm just being honest.

Re: The worst Phobos template (in binderoo)

[Atila Neves via Digitalmars-d]

On Wednesday, 14 September 2016 at 20:28:13 UTC, Stefan Koch 
wrote:
On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch 
wrote:


I would like to see users of fullyQualifiedName because apart 
from binderoo code which seems to work, I have none.


That was supposed to say : I would like to see [test cases 
from] users of fullyQulifiedName.


I use it in unit_threaded, which now explains why the 
compile-time reflection is a bit slow. I need to figure out how 
to measure it though.


Atila

Re: colour lib needs reviewers

[Andrei Alexandrescu via Digitalmars-d]

On 9/14/16 7:04 PM, bachmeier wrote:

On Wednesday, 14 September 2016 at 21:31:51 UTC, Andrei Alexandrescu wrote:


Please add your own ideas.


Andrei


One thing that I didn't like when I used DDOC was that I couldn't find a
way to add a block of text directly to the output file. I know that can
be done with html, but it's not the same. When I am programming I want
to make notes (the way I make comments) but not get bogged down with all
the macros/html stuff. Unformatted text is way better than unwritten
text. Blocks of markdown would be better, but blocks of text would have
helped.

[Maybe this is possible but I was a new D user at that time and haven't
had a reason to look into it.]


Do you mean like a macro $(VERBATIM ... text with balanced parens ...)? 
-- Andrei

Getting a String Literal From an Aliased Template Mixin Parameter

[jsako via Digitalmars-d-learn]

I was making a quick mocking infrastructure for internal mocks so 
I wouldn't have to pass in objects to constructors all the time 
and came up with this:


[code]
mixin template internalMockRig(alias _var, string _varName, alias 
_varStandard, alias _varMock) {


version(unittest) {

@property bool internalMockSetting() {
return _useInternalMocks;
}
@property useInternalMocks(bool uim) {

// Are we changing the mock type?
if (uim != _useInternalMocks) {

_useInternalMocks = uim;

if(_useInternalMocks) {
_var = new _varMock;
}
else {
_var = new _varStandard;
}
}
}

private: bool _useInternalMocks = false;
}
}
[/code]

Then in the object:

[code]
class usingTestThing {

testThing thing;

mixin internalMockRig!(thing, testThing, testThingMock);

this() {

thing = new testThing;
}

}
[/code]

This works great as long as there is only one mock object. I 
thought about using string mixins to generate the properties on a 
per-variable basis, but the problem is that I can't figure out 
how to get the string of the variable name from the aliased 
template mixin parameter. Is there a way to do this?


If not, I'll have to pass in the strings of the variables 
seperately (as in: mixin internalMockRig!(thing, "thing", 
testThing, "testThing", testThingMock, "testThingMock"); ), but 
that seems inelegant (and a bit error prone).

Re: The worst Phobos template (in binderoo)

[David Nadlinger via Digitalmars-d]

On Wednesday, 14 September 2016 at 22:48:29 UTC, Pierre Krafft 
wrote:

I've had to use fullyQualifiedName in some string mixins.


Unless there is more to the example than what meets the eye, "had 
to" isn't quite true, and even with the `import moduleName!…` 
hack, your code is still unnecessarily restrictive. Just use ` ~ 
"fromJSON!(typeof(t." ~ name ~ "))…"` instead.


I'd really like to know where the notion that stringifying 
symbols for mixin code generation is a viable choice comes from. 
People seem to try with an irritating regularity, only to 
inevitably discover that it doesn't actually work some time 
later. That one can get dangerously close now that we have 
`moduleName` doesn't exactly help either.


 — David

Re: colour lib needs reviewers

[bachmeier via Digitalmars-d]

On Wednesday, 14 September 2016 at 21:31:51 UTC, Andrei 
Alexandrescu wrote:



Please add your own ideas.


Andrei


One thing that I didn't like when I used DDOC was that I couldn't 
find a way to add a block of text directly to the output file. I 
know that can be done with html, but it's not the same. When I am 
programming I want to make notes (the way I make comments) but 
not get bogged down with all the macros/html stuff. Unformatted 
text is way better than unwritten text. Blocks of markdown would 
be better, but blocks of text would have helped.


[Maybe this is possible but I was a new D user at that time and 
haven't had a reason to look into it.]

Re: The worst Phobos template (in binderoo)

[Pierre Krafft via Digitalmars-d]

On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch 
wrote:
I would like to see users of fullyQualifiedName because apart 
from binderoo code which seems to work, I have none.


I've had to use fullyQualifiedName in some string mixins. Take a 
look at 
https://github.com/BlackEdder/painlessjson/blob/9f9b94b3a47ada4ffdea16ef5dc5476c74cb9a06/source/painlessjson/painlessjson.d#L415. I also recommend using GitHub search to find other examples.

[Issue 15857] incorrect checkimports mismatch for overload sets

[via Digitalmars-d-bugs]

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

--- Comment #12 from Martin Nowak  ---
Looks like the caching fails for imports because of this
https://github.com/dlang/dmd/blob/82c5682edbd876767d3853bd6fdd2cc70ebfa73b/src/dsymbol.d#L1283
condition.

--

[Issue 15413] Foreach over range with @disable this(this) doesn't work

[via Digitalmars-d-bugs]

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

Ali Cehreli  changed:

   What|Removed |Added

 CC||acehr...@yahoo.com
Summary|Foreach over range with |Foreach over range with
   |@disable this doesn't work  |@disable this(this) doesn't
   ||work

--

Re: DIP1000

[Timon Gehr via Digitalmars-d]

On 14.09.2016 21:49, Andrei Alexandrescu wrote:

Some progress with the DIP1000 semantics. So I made a few changes to the
grammar of the mini-language (call it MiniD1000), which is at
http://erdani.com/d/DIP1000-grammar.html. Notable aspects:

* Programs are a sequence of function definitions, struct definitions,
and global variable definitions. A pass is supposed to go through all
and create the initial typing environment.
...


There probably should be typing rules for that.



* Functions now only have one parameter. This is to reduce the size of
the language (two parameters increase the numbers of typing and
evaluation rules). Aliasing can be studied with globals. I'm unclear
whether we need the second parameter for investigating things like
cross-parameter aliasing; if so, I'll add it back.
...


I would support an arbitrary number of parameters. Leaving that out does 
not buy much in terms of simplicity, and it makes miniD quite a lot less 
relevant for arguing about the soundness of the full language.




* All functions are required to end with a return statement. This avoids
any need for flow control.
...


How so? You still allow return statements at arbitrary places in the 
function.



* There are no rvalues in MinbiD1000,


Yes there are. Function calls might be rvalues because 'ref' is optional 
on them.



which I thought is quite clever.
That means `null` and integral literals are not expressions; they are
explicitly present in assignment statements. This simplifies MiniD1000 a
great deal, but again will require us to be careful when we "port"
whatever conclusions we draw back to D.
...


That should be fine. I think a better way is to special-case only the 
lhs though. I.e. x=e, *e₁=e₂, f(e₁,…,eₙ)=eₙ₊₁.




* The `if` statement has no `else` clause. It only increases the size of
the language without an increase in expressiveness.

Next, I defined a baseline set of typing rules at
http://erdani.com/d/DIP1000-typing-baseline.html for "bad" MiniD1000:
all ref, scope and return attributes are ignored, so there's no special
protection against bad escapes. Based on these rules we'll later define
better rules that enforce safety. A few notes:



Looking good, except:

- struct types are not checked for existence.

E.g. the following program type checks:

void main(){
Undefined x;
Undefined* y=
}

- 'fields' is not defined. (And how is it supposed to know what the 
fields of some syntactic type are?) Probably struct declarations should 
be part of the environment, then 'fields' can take the environment as an 
additional argument. I think it would make sense if your grammar 
enforced that all struct declarations come before all global variables 
which come before all function declarations.


- Functions cannot call each other, because they cannot look up each 
other's names.




* For a general understanding on how to read these rules, see the
Featherweight Java (FJ) paper or see e.g.
http://www.hedonisticlearning.com/posts/understanding-typing-judgments.html.


* Like in FJ, sequences of zero or more things are shown with an overbar.

* In order to identify the current function being compiled, I introduce
the symbol f_{crt}. For example, in rule S-VarDeclaration, a
prerequisite of the judgment is that f_{crt} exists, i.e. the rule
S-VarDeclaration only applies inside a function, not outside. For the
outside rule see D-GlobalVarDeclaration.

* S-VarDeclaration introduces a new name visible to the statements that
follow. This is done by typing not only the variable declaration, but
also all following statements in its scope. The typing environment for
the statements is the union of the preexisting typing environment and
the new variable.

* In fact the typing rules of all statements carry the appendix "and
here are the following statements in the scope" which is workable but
possibly a bit goofy. Any cleverer idea?
...


I think it is fine.



* For that matter I need the rule S-NoStmts: "a sequence of zero
statements types just fine".

* In D-Struct, I vaguely state that a struct shall not be a transitive
field of itself.


Well, the notation does not really make a lot of sense.


Is there a better way to enforce that succintly?
...


Typing rules for structs need to state that all struct declarations 
together are fine if each struct is fine individually given all other 
structs present in the environment.


Then define something like

transitiveFieldTypes(Γ,S) :=
μX. {T | ∃x. T x; ∈ (fields(Γ,S) ∪ ⋃{ fields(Γ,T') | T'∈X }) }

(In English: transitiveFieldTypes(Γ,S) is the smallest set such that all 
field types of S and field types of other types in the set are also in 
the set.)


You can then require that S∉transitiveFieldTypes(Γ,S)


Please let me know of anything I missed or got wrong. Once the baseline
typing is in place, the hard part starts: defining the enhanced typing
that enforces safe scoping rules.
...


Maybe we should define the semantics first (it is easier and it is 

[Issue 16494] cannot find source code for runtime library after brew install in custom directory

[via Digitalmars-d-bugs]

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

Timothee Cour  changed:

   What|Removed |Added

 CC||timothee.co...@gmail.com

--- Comment #1 from Timothee Cour  ---
was caused by installing linuxbrew on a mounted directory, except that the
$HOME variable was ran on another machine when installed the first time, and
had a different value from the $HOME on the machine where it was run a 2nd
time.

What's weird is that the dmd.conf file existed at the correct location but
DFLAGS defined there were wrong (pointing to old home); not sure why dmd
-v|grep Config would return Config file: (null) in that case

cat $HOMEBREW_PREFIX/etc/dmd.conf
[Environment]
DFLAGS=-I/home/old_name/.linuxbrew/Cellar/dmd/2.071.1/include/dlang/dmd
-L-L/home/old_name/.linuxbrew/Cellar/dmd/2.07
1.1/lib

--

Re: The worst Phobos template (in binderoo)

[Stefan Koch via Digitalmars-d]

On Wednesday, 14 September 2016 at 21:06:10 UTC, Andrei 
Alexandrescu wrote:

On 09/14/2016 04:52 PM, Stefan Koch wrote:

[...]


(Disclaimer: I didn't run any speed tests.) By looking at the 
definition of fullyQualifiedName it seems to me we can go a 
long way with traditional optimization techniques. For example 
consider:


[...]


staticMap is number 3 in the top-slow-templates list.
And the code inside it really does not matter so much.
What matters is recursive instanciation.

the evaluation of the function is fast in comparison to the time 
the template-subsystem takes.


I believe this cannot be fixed by changing a library solution.

Re: Compiling vibe.d application for Amazon ec2 instance

[David Nadlinger via Digitalmars-d-learn]

On Wednesday, 14 September 2016 at 12:13:58 UTC, Seb wrote:

You should try -static in ldc, it's works like a dream for me :)


Yep, LDC supports fully static linking on Linux (and is currently 
the only compiler to do so).


 — David

[Issue 16494] New: cannot find source code for runtime library after brew install in custom directory

[via Digitalmars-d-bugs]

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

  Issue ID: 16494
   Summary: cannot find source code for runtime library after brew
install in custom directory
   Product: D
   Version: D2
  Hardware: x86
OS: Linux
Status: NEW
  Severity: major
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: timothee.co...@gmail.com

When installing brew (via linuxbrew) in a nonstandard directory, dmd can't find
it's config file.

Would be nice if error message pointed out the algorithm to search for
dmd.conf, and the best way to fix this

install_dmd_custom.sh:
```
HOME_temp=/tmp/somedir/
HOME_old=$HOME
mkdir -p $HOME_temp

install_linuxbrew(){
  HOME=$HOME_temp
  ruby -e "$(curl -fsSL
https://raw.githubusercontent.com/Linuxbrew/install/master/install)"
  HOME=$HOME_old
}

export HOMEBREW_PREFIX=$HOME_temp/.linuxbrew/
PATH="$HOMEBREW_PREFIX/bin:$PATH"

ls $HOMEBREW_PREFIX/bin/brew || install_linuxbrew
brew install dmd

rdmd some_file.d
#cannot find source code for runtime library after brew install in custom
directory
```

dmd -v|grep Config: Config file: (null)

--

Re: colour lib needs reviewers

[Andrei Alexandrescu via Digitalmars-d]

On 09/14/2016 05:31 PM, Andrei Alexandrescu wrote:

After writing it for a few dozen times today, I figured it's objectively
awkward to type (at least on the US keyboard): the dollar sign followed
by the left paren is just unpleasant for mechanical reasons.

The resulting look is alien too, as opposed to the more familiar
$MACRO(a1, a2, a3) or the CPP-style MACRO(a1, a2, a3).


I meant to add here: we can improve this in a backward-compatible way by 
allowing users to choose syntax by means of some notation, e.g. this 
thing as the first macro:


DD0C_SYNTAX = $(X)

for the existing syntax, vs.

DD0C_SYNTAX = $X()

for the $MACRO(a1, a2) syntax. We may also allow users to define the 
argument separator, also on a per-document basis. By default:


DDOC_ARGUMENT_SEPARATOR = ,

We may also allow custom parens and so on.


Andrei

Re: colour lib needs reviewers

[Andrei Alexandrescu via Digitalmars-d]

On 09/14/2016 09:28 AM, Manu via Digitalmars-d wrote:

... I'm just gonna go on the record and say that I am really, really
not enjoying ddoc ;)


I was using ddoc today for the Greeks in DIP1000 and was musing about 
what makes it annoying. I think a major part is the macro invocation 
syntax: $(MACRO a1, a2, a3). After writing it for a few dozen times 
today, I figured it's objectively awkward to type (at least on the US 
keyboard): the dollar sign followed by the left paren is just unpleasant 
for mechanical reasons.


The resulting look is alien too, as opposed to the more familiar 
$MACRO(a1, a2, a3) or the CPP-style MACRO(a1, a2, a3).


There are a couple of un(der)documented tricks without which life is 
very difficult. For example, people commonly believe that in order to 
embed a literal comma they need to go like this:


COMMA = ,

and then $(MACRO Hello$(COMMA) world, a2). That scales poorly with the 
size of the argument. In fact, there's a much better solution:


ARGS = $0

and then $(MACRO $(ARGS Hello, world), a2) allows any amount of text 
with commas. Sadly no similar solution for unpaired parens.


Also, the fact that the doc opens with the text and then has an obscure 
"Macros:" line at a point is unpleasant. The macro definitions should 
come first, followed by a separator and then the content. That would 
make for a much nicer flow.


There are a few other macros I never leave home without:

ARGS = $0
COMMA = ,
DOLLAR = $
LPAREN = (
RPAREN = )
TAIL = $+
COLON = :
LF = $(LF)
$(LF)
COMMENT =
SP = $(COMMENT space coming) $(COMMENT that was a space)

TAIL sadly doesn't work properly.

Overall: I'm trying to build a list of ddoc grievances that can be 
fixed. It's the de jure and de facto standard for D documentation (with 
the ddoc processor or ddox), so we'd do good to improve it.


Please add your own ideas.


Andrei

Re: colour lib needs reviewers

[Walter Bright via Digitalmars-d]

On 9/14/2016 5:47 AM, Meta wrote:

DDOC sections such as Returns, Args, etc.


s/Args/Params/

Re: The worst Phobos template (in binderoo)

[Andrei Alexandrescu via Digitalmars-d]

On 09/14/2016 04:52 PM, Stefan Koch wrote:

On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote:

It takes a whooping 500 milliseconds

Ahm... I misread my performance graph
it's 138ms for the first instanciation.
and around 5ms for every following one.
the total time spent on it was 500ms


(Disclaimer: I didn't run any speed tests.) By looking at the definition 
of fullyQualifiedName it seems to me we can go a long way with 
traditional optimization techniques. For example consider:


string result = join(
  map!(a => format("%s%s", a[0], a[1]))(
zip([staticMap!(storageClassesString, parameterStC)],
  [staticMap!(fullyQualifiedName, parameters)])),

This is neat, and it's neat squared because it works during compilation, 
but at some point if the resulting code runs slowly, there's no shame in 
applying old school optimization. Instead of join/map a simple loop 
should suffice; no need to use format with "%s%s" over simple 
concatenation; array zipping may be done with simple loops too.


Same a few lines below - just replace return format("%s%s%s%s%s%s%s%s", 
...) with simple concatenation. Same goes with format("shared(%s)", 
...), format("%s(%s)", ...) etc. In casual runtime code such code is 
totally fine, but in library code we'd do good to eliminate the use of 
format (which is a mini-interpreter) if speed considerations tell us to.


The unittests seem excessive too. Yes, there is such a thing as too much 
of a good thing. And use a lot of format during compilation as well :o). 
In unittests, a bunch of static asserts may be replaced with regular 
asserts.



Andrei

Re: The worst Phobos template (in binderoo)

[Stefan Koch via Digitalmars-d]

On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch 
wrote:

It takes a whooping 500 milliseconds

Ahm... I misread my performance graph
it's 138ms for the first instanciation.
and around 5ms for every following one.
the total time spent on it was 500ms

Re: The worst Phobos template (in binderoo)

[Stefan Koch via Digitalmars-d]

On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch 
wrote:


I would like to see users of fullyQualifiedName because apart 
from binderoo code which seems to work, I have none.


That was supposed to say : I would like to see [test cases from] 
users of fullyQulifiedName.

Re: vibe.d maxRequestSize

[Steven Schveighoffer via Digitalmars-d-learn]

On 9/14/16 9:58 AM, Chris wrote:

The vibe.d server rejects `XMLHttpRequest`s that are too long (in the
eyes of the server). In the docs it says

"maxRequestSize   ulong

Maximum number of transferred bytes per request after which the
connection is closed with [sic!]"

However, when you go to

http://vibed.org/api/vibe.http.server/HTTPServerSettings.maxRequestSize

it says

"Maximum number of transferred bytes per request after which the
connection is closed with an error; not supported yet"

"not supported yet" and I think it is not supported yet. Can I still
change the server settings so that it accepts longer query strings? Atm,
the server rejects strings that are > ~2,500 characters, which is not much.



Hm.. I have adjusted this in my project, and it works (set to 50M). 
Needed it for uploading large images.


Using version 0.7.29

-Steve

The worst Phobos template (in binderoo)

[Stefan Koch via Digitalmars-d]

Hi Guys,

I recently had a closer look at the templates that cost the most 
time to instantiate in the frontend.


and there is one clear winner.

FullyQualified name from std.traits.
It takes a whooping 500 milliseconds(on my test-case) for it's 
semantic phase.
this is because this template is recursive and because it 
instantiates std.format.format which is on fourth place for slow 
templates.


The functionality can be implemented with a __trait and that 
implementation would be 500 times faster.


I am going to submit a PR soon.

However I cannot guarantee that the newly introduces trait work 
the same in all cases.

As templates can behave surprisingly sometimes.

I would like to see users of fullyQualifiedName because apart 
from binderoo code which seems to work, I have none.

Re: colour lib needs reviewers

[Andrei Alexandrescu via Digitalmars-d]

On 09/14/2016 09:47 AM, Meta wrote:

On Wednesday, 14 September 2016 at 13:28:23 UTC, Manu wrote:

Cheers.
Yeah, I need to do better with ddoc.

... I'm just gonna go on the record and say that I am really, really
not enjoying ddoc ;)


I can't say I'm a fan either.


Why? -- Andrei

Re: ddoc latex/formulas?

[Andrei Alexandrescu via Digitalmars-d]

On 09/14/2016 09:38 AM, Manu via Digitalmars-d wrote:

On 14 September 2016 at 21:36, Andrei Alexandrescu via Digitalmars-d
 wrote:

On 9/14/16 1:50 AM, Manu via Digitalmars-d wrote:


Can we produce formulas, or latex in ddoc? Are there any examples in
phobos I can refer to?



https://github.com/dlang/dlang.org/blob/master/latex.ddoc

That's the macros file for generating the language spec in LaTeX format.


Ah, wow, yeah I actually saw this when I googled for it before posting here.

I'm just gonna come out and say that I really don't feel like taking
the few hours it might take me to try and understand what's going on
here. I really have better things to do...
Considering I don't really know latex either, I just have to wing
that, this is like 721 lines of tedious double-indirection, with no
examples in sight ;) (yet I'm being hassled about lack of examples!)


Generally speaking it's difficult to produce good latex documents 
without knowing latex, so it may be the case a latex crash course is 
needed or the task is ill-defined.


That said, the stuff I published at 
http://erdani.com/d/DIP1000-grammar.html and 
http://erdani.com/d/DIP1000-typing-baseline.html use MathJAX, you may 
want to take a look. Truth be told that's generated code (using a much 
smaller ddoc source).



I'm kinda feeling ddoc is fairy serious problem. Doxygen is like... a
lot better :/
I'm struggling to produce docs I'm happy with. Formatting is hard,
macros for everything really sucks!


Why?


Andrei

[Issue 14125] @trusted nested helper functions in std.file

[via Digitalmars-d-bugs]

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

--- Comment #79 from Walter Bright  ---
This pull request:

https://github.com/dlang/phobos/pull/4786

will help simplify things in std.file by making some of the machinations to
work with both arrays and ranges unnecessary.

--

Re: DIP1000

[Andrei Alexandrescu via Digitalmars-d]

Some progress with the DIP1000 semantics. So I made a few changes to the 
grammar of the mini-language (call it MiniD1000), which is at 
http://erdani.com/d/DIP1000-grammar.html. Notable aspects:


* Programs are a sequence of function definitions, struct definitions, 
and global variable definitions. A pass is supposed to go through all 
and create the initial typing environment.


* Functions now only have one parameter. This is to reduce the size of 
the language (two parameters increase the numbers of typing and 
evaluation rules). Aliasing can be studied with globals. I'm unclear 
whether we need the second parameter for investigating things like 
cross-parameter aliasing; if so, I'll add it back.


* All functions are required to end with a return statement. This avoids 
any need for flow control.


* There are no rvalues in MinbiD1000, which I thought is quite clever. 
That means `null` and integral literals are not expressions; they are 
explicitly present in assignment statements. This simplifies MiniD1000 a 
great deal, but again will require us to be careful when we "port" 
whatever conclusions we draw back to D.


* The `if` statement has no `else` clause. It only increases the size of 
the language without an increase in expressiveness.


Next, I defined a baseline set of typing rules at 
http://erdani.com/d/DIP1000-typing-baseline.html for "bad" MiniD1000: 
all ref, scope and return attributes are ignored, so there's no special 
protection against bad escapes. Based on these rules we'll later define 
better rules that enforce safety. A few notes:


* For a general understanding on how to read these rules, see the 
Featherweight Java (FJ) paper or see e.g. 
http://www.hedonisticlearning.com/posts/understanding-typing-judgments.html.


* Like in FJ, sequences of zero or more things are shown with an overbar.

* In order to identify the current function being compiled, I introduce 
the symbol f_{crt}. For example, in rule S-VarDeclaration, a 
prerequisite of the judgment is that f_{crt} exists, i.e. the rule 
S-VarDeclaration only applies inside a function, not outside. For the 
outside rule see D-GlobalVarDeclaration.


* S-VarDeclaration introduces a new name visible to the statements that 
follow. This is done by typing not only the variable declaration, but 
also all following statements in its scope. The typing environment for 
the statements is the union of the preexisting typing environment and 
the new variable.


* In fact the typing rules of all statements carry the appendix "and 
here are the following statements in the scope" which is workable but 
possibly a bit goofy. Any cleverer idea?


* For that matter I need the rule S-NoStmts: "a sequence of zero 
statements types just fine".


* In D-Struct, I vaguely state that a struct shall not be a transitive 
field of itself. Is there a better way to enforce that succintly?


Please let me know of anything I missed or got wrong. Once the baseline 
typing is in place, the hard part starts: defining the enhanced typing 
that enforces safe scoping rules.



Thanks,

Andrei

Re: iPhone vs Android

[deadalnix via Digitalmars-d]

On Wednesday, 14 September 2016 at 13:28:45 UTC, finalpatch wrote:

On Tuesday, 13 September 2016 at 18:24:26 UTC, deadalnix wrote:
No you don't, as how often the GC kicks in depend of the rate 
at which you produce garbage, which is going to be very low 
with an hybrid approach.


This is simply not true.

Assume in a pure GC program the GC heap can grow up to X Mb 
before a collection cycle happens, which has to scan X Mb of 
memory.




No it has to scan the live set. If we assume we are ready to 
accept a 2X overhead in the GC heap in that program, the 
collection cycle needs to scan X/2 Mb of memory. We are for a bad 
start here.


Now let's say we have a hybrid program that uses 0.5X Mb of 
RCed memory and 0.5X Mb of GC memory so the total memory 
consumption is still X Mb. When the GC heap reaches 0.5X Mb, it 
has to scan both RC and GC memory.




Your assumption that there are 2 heap is bogus, your 2 programs 
have different live sets (A has 500kb and B 750ko of live sets). 
In addition, why the fuck is your RC system only able to reclaim 
50% of the garbage emitted ? Even with such stupids humber, you 
end up with program A able to manage 500kb with 100% overhead, 
and program B able to manage 750ko with 33% overhead, which 
completely proves my point: the hybrid approach is far superior.


Now let's get an appropriate model of how thing work in the real 
world. Let's assume we have a program that emit 1Mb of garbage 
per second, has a live set of 1Mb and we assume we can accept a 
2X memory overhead for the GC.


With the pure GC approach, we emit 1Mb of garbage per second on 
top of our live set of 1Mb, so we need one collection cycle per 
second. This collection cycle has to scan the living set, namely 
1Mb of data.


With the hybrid approach, we still emit 1Mb of garbage per 
second, but the RC system can reclaim 90% of it. We end up with a 
rate of garbage for the GC to collect of 100ko per second. If we 
allow the same memory overhead, we end up with a collection cycle 
every 10s. The live set still has the same size, so the GC still 
has to scan 1Mb of data. Therefore, we effectively divided by 10 
the resource we needed to allocate to the GC.


It's quite obvious that the time(t) it takes for program 1 to 
produce X Mb of garbage is the same as program 2 to produce 
0.5X Mb of garbage, and after time t, both program have to scan 
X Mb of memory.  However program 2 also has to pay the cost of 
reference counting on top of that.




Rule of thumb, when someone start by "it's obvious that" you can 
be sure that 99% of the time, what follows is confirmation bias 
rather than anything cogent. I think we've established this is 
the case here.

Re: Null references and access violation

[pineapple via Digitalmars-d]

On Wednesday, 14 September 2016 at 18:36:46 UTC, Jonathan M Davis 
wrote:
If you don't want to have problems with dereferencing null 
pointers or references, then check for null in the cases where 
a pointer or reference might be null.


- Jonathan M Davis


Writing your functions that disallow null inputs like `fn(int* 
arg) in{assert(arg !is null);} body{ ... }` is readable, concise, 
and in my opinion a generally elegant solution to the problem.

Re: iPhone vs Android

[deadalnix via Digitalmars-d]

On Wednesday, 14 September 2016 at 07:55:24 UTC, John Colvin 
wrote:

On Tuesday, 13 September 2016 at 22:28:09 UTC, deadalnix wrote:
On Tuesday, 13 September 2016 at 22:19:54 UTC, Jonathan M 
Davis wrote:
The big problem with exceptions being allocated by the GC 
isn't really the GC but @nogc.


No the problem IS @nogc . Allocating with the GC is absolutely 
not a problem is you deallocate properly. What is a problem is 
when you leak (ie, when the ownership is transferred to the 
GC). If you don't leak, GC do not kicks in.


Can you explain a bit more here? Do you mean in practice (I.e. 
in current implementation) or in theory?


My point is that if you have lifetime information for some data 
(and it looks like this is where we want to go with things like 
DIP25 and DIP1000, but let's not get lost in the specific of 
these proposal now) you know they are going to end up being freed 
without the GC having to do a collection cycle.


Therefore, you know you'll not end up having to rely on the GC as 
long as you can track lifetime, even if you allocate with it.


Now that this is established it follows that disallowing GC 
allocation in @nogc code is needlessly restrictive and promote 
unsafe patterns (like allocating using malloc + giving the range 
to the GC, which is both slower than allocating on the GC 
directly and more error prone).


A more sensible approach is to allow GC allocation in @nogc code 
but disallow cases where GC's alloc lifetime cannot be tracked. 
Note that this isn't the case for most exceptions.


For instance, when you do
throw new Exception("tagada");

The compiler can deduce that the ownership of the exception is 
transferred to the runtime, which will transfers back to the 
catch block that gets it. Depending of what this catch block is 
doing, it may or may not be @nogc, but there is no reason that 
for throw to not be allowed in @nogc code.


However, if you have something like
throw e;

With e a reference to an Exception who's lifetime cannot be 
tracked, then it makes sense to disallow it in @nogc code.


TL;DR : The problem is not new, the problem is the rhs of 
assignment operations.

Re: Critque of Rust's collection types

[Klmp via Digitalmars-d]

On Wednesday, 14 September 2016 at 03:49:35 UTC, Basile B. wrote:
On Wednesday, 14 September 2016 at 00:36:39 UTC, Walter Bright 
wrote:

On 9/13/2016 4:47 PM, Walter Bright wrote:

http://ticki.github.io/blog/horrible/

Some worthwhile insights into what makes a good collection 
type.


https://news.ycombinator.com/item?id=12488233

Of particular interest is the advocacy of collision attack 
resistance. Is anyone interested in exploring this w.r.t. D's 
builtin hashes?


https://www.reddit.com/r/rust/comments/52grcl/rusts_stdcollections_is_absolutely_horrible/

Of interest are the comments by the implementer of the hash.


There's a benchmark of languages builtin hashmaps here:

http://vaskir.blogspot.fr/2016/05/hash-maps-rust-vs-f.html

It includes D and Rust. The author found that D wins for the 
lookups but was a bit behind for the insertions (due to GC 
maybe ?).


Rust results didn't seem that bad, despite of the cryptographic 
hash function it uses.


just ignore...get on ignoring.
tea vs coffee...cough

Re: Null references and access violation

[Jonathan M Davis via Digitalmars-d]

On Wednesday, September 14, 2016 16:52:19 Bauss via Digitalmars-d wrote:
> Can someone riddle me this, why D gives an access violation
> instead of ex. a null reference exception?
>
> Like let's say you have a field that's a class and you forget to
> give it a value. Now that will cause an access violation, but
> generally access violations are an indication that you're program
> has reached a nasty state and can't be recovered. Hence why you
> cannot catch it by doing a normal catch block for "Exception",
> but has to do on "Throwable" (Idk if "Error" works for?) Now
> that's a problem, because in that particular case the program may
> still work without being in an unrecoverable state.
>
> Of course it can be resolved by catching it, but what about
> actual unrecoverable access violations? You will be shadowing
> those too then.
>
> This is especially a problem when you work with 3rd party
> libraries where you basically have no control over what happens.
>
> Is there a way around this, to make thins like not assigning an
> instance to a class cause some null reference exception or is
> there a specific reason why it exactly throws an access violation
> error.

Dereferencing null is generally considered to be a program bug and thus
should be treated as unrecoverable - just like failed assertions are
considered to be unrecoverable, which is why they throw AssertErrors and not
AssertExceptions. So, if we were going to have null-checks built-in, then
we'd throw something like NullDereferencingError and not NullException.
However, Walter's stance on this is that the CPU already does the null
checks for you - that's why you get a segfault on *nix or an access
violation on Windows. The CPU checked. Any additional checks would therefore
just be unnecessary overhead.

If you don't want to have problems with dereferencing null pointers or
references, then check for null in the cases where a pointer or reference
might be null.

- Jonathan M Davis

Re: Can vibe d leverage existing web technologies?

[Intersteller via Digitalmars-d-learn]

On Wednesday, 14 September 2016 at 04:22:02 UTC, Brad Anderson 
wrote:
On Tuesday, 13 September 2016 at 23:45:18 UTC, Intersteller 
wrote:
vibe.d does not have much lateral support as the most commons 
web technologies do.  Can vibe.d leverage pre-existing techs 
such as php, ruby/rails, etc? Starting from scratch and having 
to build a robust and secure framework is really not the way 
to go.


Sure. Just use res.write(executeShell(["php", "-f", 
"somephpscript.php"]).output); or something like that.


But seriously, you probably don't want to do that. It's like 
asking if ruby on rails can leverage php. Sure, they can 
communicate over HTTP or whatever else they support but trying 
to execute PHP from within Rails or vice versa just isn't 
really all that beneficial.


It is if you want to use pre-existing technologies. There are 
tons of php frameworks for doing things. Virtually nothing exists 
for vibe.d. e.g., any e-commerce stuff for vibe.d? I turned up 
one outdated, unfinished, and unmaintained package for d. There 
are hundreds, if not thousands for php. So are you suggesting I 
do not use vibe.d?


It's not like ruby/rails because ruby/rails also has a larger set 
of technologies. You are comparing apples to oranges. vibe.d has 
nearly 0 while the others have nearly an infinite. If vibe.d had 
nearly an infinite I would be asking this question.


Hopefully your solution works. Thanks.

Re: colour lib needs reviewers

[Marco Leise via Digitalmars-d]

Am Wed, 14 Sep 2016 13:47:43 +
schrieb Meta :

> On Wednesday, 14 September 2016 at 13:28:23 UTC, Manu wrote:
> > Cheers.
> > Yeah, I need to do better with ddoc.
> >
> > ... I'm just gonna go on the record and say that I am really, 
> > really not enjoying ddoc ;)  
> 
> I can't say I'm a fan either.

You can replace $(D …) with `…` nowadays. It made me a bit more
of a fan. :)

-- 
Marco

Re: Null references and access violation

[Marco Leise via Digitalmars-d]

Am Wed, 14 Sep 2016 16:52:19 +
schrieb Bauss :

> Can someone riddle me this, why D gives an access violation 
> instead of ex. a null reference exception?

Access violations cost exactly 0. Noone needs to do anything
extra for this check that isn't done by the CPU already. The
next step is an assertion (which I think is done in debug mode
when you call a method on a null object). That's still not
recoverable, just like out of memory situations in D.
Compare for example in-contracts, where you assert for
not-null. Those throw unrecoverable errors as well unless you
turn them from

  assert(obj !is null);

into 

  if (obj is null) throw new NullPointerException();

(And that's what the compiler in its current state would
probably insert for you on every access to the object.)

D is somewhat consistent in making null pointers and other
contracts/assertions fatal errors that end program execution.
In other words: Everything that's a fault in the program logic
gives you a rather harsh exit, while unforseeable situations
like network errors or incorrect user input are handled by
exceptions. Walter mentioned that when a program is run inside
a debugger, access violations are the easiest problem for the
debugger, while D exceptions on Linux are not as easy to
break on.

I understand the sentiment though. I've seen a Karaoke
software throw exceptions because no item was selected in a
list box. If that was an access violation you could not
have acknowledged the OutOfBounds/NullPointer message, selected
an item and continued. Depending on how and where the software
is used, one or the other is a better default.

We have had some interesting proposals on not-null references
(as NullPointerExceptions are seen as a mistake in retrospect
by language designers [citation needed]) and "remembering"
what line of code has safe access to the object. E.g.
everything in "if (obj) { ... }" can safely access the object.

-- 
Marco

Re: Critque of Rust's collection types

[cym13 via Digitalmars-d]

On Wednesday, 14 September 2016 at 11:59:13 UTC, Kagamin wrote:
On Wednesday, 14 September 2016 at 00:36:39 UTC, Walter Bright 
wrote:
Of particular interest is the advocacy of collision attack 
resistance. Is anyone interested in exploring this w.r.t. D's 
builtin hashes?


Perl's approach is probably good enough 
https://issues.dlang.org/show_bug.cgi?id=14414

Reversibility of the hash looks irrelevant for dos attack.


What do you mean by that? It's the basis of DoS attack against 
hashtables: being able to find many inputs with the same hash. 
What perl does isn't good IMHO because their solution is not the 
default behaviour and the security effect of changing the seed 
isn't made obvious to the programmer.


While I can understand prefering speed over security as default 
(although history shows that if it's not the default it's not 
used) I would rather have a security flag to change the algorithm 
at compile-time for a more secure one. Most programmers won't see 
the point of changing seed and we can definitely take advantage 
of templates here.


Also I'm not sure in our use-case fastest necessarily means less 
secure, there should be some benchmarking at work.

Null references and access violation

[Bauss via Digitalmars-d]

Can someone riddle me this, why D gives an access violation 
instead of ex. a null reference exception?


Like let's say you have a field that's a class and you forget to 
give it a value. Now that will cause an access violation, but 
generally access violations are an indication that you're program 
has reached a nasty state and can't be recovered. Hence why you 
cannot catch it by doing a normal catch block for "Exception", 
but has to do on "Throwable" (Idk if "Error" works for?) Now 
that's a problem, because in that particular case the program may 
still work without being in an unrecoverable state.


Of course it can be resolved by catching it, but what about 
actual unrecoverable access violations? You will be shadowing 
those too then.


This is especially a problem when you work with 3rd party 
libraries where you basically have no control over what happens.


Is there a way around this, to make thins like not assigning an 
instance to a class cause some null reference exception or is 
there a specific reason why it exactly throws an access violation 
error.

Re: Using OpenGL

[Darren via Digitalmars-d-learn]

Kind of resurrecting this thread; hope that's okay.

I'm working through this tutorial: 
http://www.learnopengl.com/#!Getting-started/Textures


It uses SOIL to load images, but I haven't seen any SOIL bindings 
in dub.  I tried using SDL and SDL_Image but when the program ran 
it just crashed.  I guess I was doing something wrong.


While googling, the idea seemed to be to create and SDL_Surface* 
and pass that (or surface.pixels) as the last argument for 
glTexImage2D.  Didn't work for me, however.


Does anyone have any tips?

Re: Usability of "allMembers and derivedMembers traits now only return visible symbols"

[earthfront via Digitalmars-d]

On Saturday, 3 September 2016 at 16:52:50 UTC, Martin Nowak wrote:

On Tuesday, 30 August 2016 at 22:24:12 UTC, Ali Çehreli wrote:

I don't agree with the current solution:


Well let's come up with a better solution then.
Let's start by finding some proper use-cases that require 
introspection on private members w/o having access to them.


Use case that I think is pretty durn important: using 
Allocator.make and forwarding a call to the private constructor 
on a class.


This does not work now:
---
class A
{ int b; private this(int a){b=a;} }

  auto ptr = make!A(Mallocator.instance, 42); // Compile Error!
---

Allocators are second class in this respect compared to GC.

Mixins aren't a good solution to this.

[Issue 16493] New: Request for an OS-independent interface to access cryptographically secure pseudo random number generators

[via Digitalmars-d-bugs]

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

  Issue ID: 16493
   Summary: Request for an OS-independent interface to access
cryptographically secure pseudo random number
generators
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: ajid...@gmail.com

Currently, phobos provides no way to gain platform-independent access to the
operating system's cryptographically secure random number generator.

Such generators are fed with entropy stemming from random hardware events such
as interrupt timing that only the kernel has access to, so most operating
systems implement an API to get random numbers from it.

The current lack of easy CSPRNG access means that developers may make poor
security choices out of either laziness or portability concerns.[1]

CSPRNGs are needed in any function where there is a need for sufficiently
random data in the face of an attacker willing to invest time and effort into
predicting RNG states. This includes uses such as generating password reset
tokens, or generating cryptographic keys. If one does not use a CSPRNG for
password reset tokens, a malicious third party could predict a password reset
token it triggered by sending itself a couple and thus figuring out what the
PRNG state is using off-the-shelf tools.

The implementation varies from platform to platform.

On Linux:
-

For kernel versions below Linux 3.17, random data can be read from
/dev/urandom. However, /dev/urandom is not guaranteed to be initialised with
sufficient entropy early during the boot process. While many distributions
restore the previous RNG state into it and architectures such as x86 usually
provide enough entropy during boot for this to not be a big problem, embedded
platforms might not do so.

However, with kernel 3.17, a new syscall getrandom[2] was added. It allows to
block until at least 128 bits of entropy have been collected. It also does not
require to use a file descriptor, so random data can be acquired even if the
system is running out of fds (such as if an application doing encryption is on
a system that is under attack to try and starve it of fds).

The use of /dev/random on Linux is not needed (I'd link the talk about it if I
could find it at the moment). Essentially, /dev/random's wacky entropy-counting
and blocking is not what most (if not all) applications want, and does not add
any security unless you're talking about early boot (in which case it would do
the same as getentropy if getentropy was to block for initial seeding).

On Windows:
---

Windows offers an API to request CSPRNG data with CryptGenRandom[3]. First, a
CSP needs to be acquired, and the CSP needs to be destroyed after we're done
with it.

On OpenBSD:
---

OpenBSD has a syscall called getentropy[4], which inspired the Linux getrandom
syscall. getentropy does not allow requests for more than 256 bytes of data at
a time. However, it might also be sensible to use arc4random[5], it seems.
Python has a os.urandom module, maybe check what they do.

On other POSIX:
---

Reading from /dev/random is probably a good fallback for systems such as OS X.
I'm not sure what FreeBSD provides, but apparently it also has a /dev/urandom.
Someone please investigate.

Other OSes:
---

Fail loud and proud.

[1] https://github.com/brendanmckenzie/scrypt/issues/1
[2] https://lwn.net/Articles/605828/
[3]
https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx
[4] http://man.openbsd.org/getentropy.2
[5] http://man.openbsd.org/arc4random.3

--

Re: vibe.d PaaS

[wobbles via Digitalmars-d-learn]

On Wednesday, 14 September 2016 at 16:03:50 UTC, Guillaume Piolat 
wrote:

On Wednesday, 14 September 2016 at 10:56:57 UTC, llaine wrote:
No PaaS service, but you can pretty simply use Heroku to 
deploy any vibe.d application.


Check the tour.dlang.io 
http://tour.dlang.io/tour/en/vibed/deploy-on-heroku where 
everything is explained :)


Thanks!


I've had success connecting vibe-d and heroku hosted postgresql 
dbs too :)

Re: vibe.d PaaS

[Guillaume Piolat via Digitalmars-d-learn]

On Wednesday, 14 September 2016 at 10:56:57 UTC, llaine wrote:
No PaaS service, but you can pretty simply use Heroku to deploy 
any vibe.d application.


Check the tour.dlang.io 
http://tour.dlang.io/tour/en/vibed/deploy-on-heroku where 
everything is explained :)


Thanks!

Re: refRange and @disable this(this);

[Mathias Lang via Digitalmars-d]

You should be able to work around this by using `for` loop instead of
`foreach`.
IMO that's a design bug in `foreach`:
https://issues.dlang.org/show_bug.cgi?id=15413

2016-09-14 14:39 GMT+02:00 Jerry via Digitalmars-d <
digitalmars-d@puremagic.com>:

> I got a range which disables copy construction and I want to loop the
> range within another loop using the same range.
> So I thought I can mark the struct range with @disable this(this) and then
> use refRange to initialize the loop.
>
> So with something like this:
>
> void main()
> {
> auto valueRange = FooRange("123");
> foreach(ch; refRange())
> writeln(ch);
> }
>
>
> struct FooRange {
> @disable this();
> @disable this(this);
> this(string str) {
> this.str = str;
> }
>
> @property bool empty() { return str.empty; }
> @property dchar front() { return str.front; }
> void popFront() { str.popFront; }
>
> private:
> string str;
> }
>
>
> But I get compile time errors messages saying:
> std/range/package.d(8155,23): Error: struct app.FooRange is not copyable
> because it is annotated with @disable
>
> It feels strange that refRange ever want to copy.
> Bug or feature?
>
>

Re: ddoc latex/formulas?

[bachmeier via Digitalmars-d]

On Wednesday, 14 September 2016 at 13:38:21 UTC, Manu wrote:
On 14 September 2016 at 21:36, Andrei Alexandrescu via 
Digitalmars-d  wrote:

On 9/14/16 1:50 AM, Manu via Digitalmars-d wrote:


Can we produce formulas, or latex in ddoc? Are there any 
examples in phobos I can refer to?



https://github.com/dlang/dlang.org/blob/master/latex.ddoc

That's the macros file for generating the language spec in 
LaTeX format.


Ah, wow, yeah I actually saw this when I googled for it before 
posting here.


I'm just gonna come out and say that I really don't feel like 
taking
the few hours it might take me to try and understand what's 
going on

here. I really have better things to do...
Considering I don't really know latex either, I just have to 
wing
that, this is like 721 lines of tedious double-indirection, 
with no
examples in sight ;) (yet I'm being hassled about lack of 
examples!)


I'm kinda feeling ddoc is fairy serious problem. Doxygen is 
like... a

lot better :/
I'm struggling to produce docs I'm happy with. Formatting is 
hard,

macros for everything really sucks!


I agree. That's why I quickly gave up on ddoc. The macro system 
needs to be better designed and documented if that's the route 
you're going to choose.


That said, if all you want to do is insert equations in the 
finished documentation, can't you do a simple text substitution 
on the ddoc output file? I needed equations so I did that when I 
started. It was a D script with only a few lines of code.

Re: iPhone vs Android

[Jonathan M Davis via Digitalmars-d]

On Wednesday, September 14, 2016 07:43:29 H. S. Teoh via Digitalmars-d wrote:
> > But the fact that the workarounds either require that you don't have
> > unique, independent exceptions or that you know that you need to
> > manually free the exception after catching it is a serious problem.
> > And that's without even taking the exception chaining into account.
>
> [...]
>
> Using a preinitialized region allocator, we no longer have such
> limitations.

And how would you deal with the fact that the catching code is generally
going to assume that it has a GC-allocated exception? It's not going to do
anything to free the exception when it's done with it, and it could keep the
exception around for an indeterminate amount of time. So, having the code
that manages the allocator later assume that the exception was freed would
be unsafe. I don't see how it's going to work in the general case to have a
an exception class which is anything other than GC allocated - not as long
as it can't be wrapped in a struct that knows how to deal with freeing its
memory when it's done. Because you either end up with an exception that gets
leaked, because the catching code doesn't know that it needs to do something
to free it, or you run the risk of it being freed prematurely when the code
that manages its memory assumes that the code that caught it didn't keep it.

Obviously, if you're talking about a smaller application that isn't sharing
code with anything, you have more control over what's going on, and you can
afford to make assumptions about what is happening with exceptions and are
thus more likely to get away with stuff that won't work in the general case.
But libraries definitely have to care, and larger applications are going to
tend to have to care, because if there's enough code, it simply isn't going
to work to assume that it all behaves in a way that differs from how
exceptions normally work. Someone else is going to come onto the project and
write perfectly normal D code that then has nasty bugs when an exception
gets thrown, because other code within that large application was doing
something with exceptions that didn't work with normal D code (like
allocating them with a different allocator that won't allow you to hold onto
the exception for an arbitrary amount of time without it being mutated out
from under you or even outright freed).

- Jonathan M Davis

Re: refRange and @disable this(this);

[Jonathan M Davis via Digitalmars-d]

On Wednesday, September 14, 2016 12:39:16 Jerry via Digitalmars-d wrote:
> I got a range which disables copy construction and I want to loop
> the range within another loop using the same range.
> So I thought I can mark the struct range with @disable this(this)
> and then use refRange to initialize the loop.
>
> So with something like this:
>
> void main()
> {
>   auto valueRange = FooRange("123");
>   foreach(ch; refRange())
>   writeln(ch);
> }
>
>
> struct FooRange {
>   @disable this();
>   @disable this(this);
>   this(string str) {
>   this.str = str;
>   }
>
>   @property bool empty() { return str.empty; }
>   @property dchar front() { return str.front; }
>   void popFront() { str.popFront; }
>
> private:
>   string str;
> }
>
>
> But I get compile time errors messages saying:
> std/range/package.d(8155,23): Error: struct app.FooRange is not
> copyable because it is annotated with @disable
>
> It feels strange that refRange ever want to copy.
> Bug or feature?

It's opAssign does a copy. The rationale is given in its documentation:

http://dlang.org/phobos/std_range.html#.RefRange.opAssign

The result of that is that the range you give it needs to be copyable. But
the reality of the matter is that ranges in general expect to be copyable,
and range-based code is going to have a tendency to fall flat on its face if
you try to define a range that's non-copyable. I'm actually kind of
surprised that such a range passes isInputRange given that it tests this
line:

R r = R.init;

But I guess that it works, because you didn't explicitly disable opAssign
(though at least sometimes, disabling the postblit constructor seems to
disable opAssign from what I recall).

If want to guarantee that a range's state is never copied, and you're
creating a range specifically for this, you might as well just make it a
class and force it to have reference semantics. RefRange was intended for
cases where you have a range that works normally, but you need to pass it to
some code and have the the state of the range be updated rather than having
a copy updated. It wasn't intended that it be used for a range that you
wanted to always be a reference type, since if you want that, you can just
declare a range that's a reference type.

- Jonathan M Davis

Re: iPhone vs Android

[H. S. Teoh via Digitalmars-d]

On Wed, Sep 14, 2016 at 05:19:45AM -0700, Jonathan M Davis via Digitalmars-d 
wrote:
> On Tuesday, September 13, 2016 16:13:05 H. S. Teoh via Digitalmars-d wrote:
> > On Tue, Sep 13, 2016 at 03:19:54PM -0700, Jonathan M Davis via Digitalmars-d
> > wrote: [...]
> >
> > > But none of the code that's marked @nogc can throw an exception
> > > unless you're either dealing with pre-allocated exceptions (in
> > > which case, they're less informative),
> >
> > I don't see why pre-allocated exceptions would be less informative.
> > You can always modify the exception object before throwing it, after
> > all.  In fact, I've always wondered about the feasibility of a @nogc
> > exception handling system where the exception is emplaced onto a
> > fixed static buffer, so that no allocation (except at the start of
> > the program) is actually necessary. Of course, chained exceptions
> > throw(!) a monkey wrench into the works, but assuming we forego
> > chained exceptions, wouldn't this work around the problem of being
> > unable to allocate exceptions in @nogc code? (Albeit with its own
> > limitations, obviously.  But it would be better than being unable to
> > use exceptions at all in @nogc code.)
> 
> As Walter points out, it's a problem if exceptions are ever saved
> (which some code does need to do). The fact that you lose chaining as
> you pointed out is also a problem.

Honestly, I've never actually run across a real-life case where chained
exceptions matter. Most of the code (that I work with, anyway) involve
simply throwing an exception when some problem occurs, and the catch
block simply prints the error message and aborts the current operation.
I agree that chained exceptions are theoretically cool and everything,
but I haven't actually found myself needing them.


> You also have problems because the file, line, and message of the
> exception either aren't going to be specific to when that exception is
> thrown, or you have to set them all before throwing, in which case you
> have issues with if/when the exception is reused.

Clearly, if a static buffer is to be used for emplacing the exception,
you'll have to sacrifice some things.  But I'm just saying that the
limitations aren't as onerous as it may seem at first, and in fact
covers a lot of common use cases.


> And regardless of all of that, the fact that string is used for the
> message throws a wrench in things for @nogc, since that's going to
> require GC allocation unless you cast something to string, and then
> you have serious problems if you need to mutate it later, since you'll
> end up violating the compiler guarantees for immutable.

Most uses of exceptions in code that I've seen involve setting a static
string as the message. This does not require GC allocation.

Granted, it's also relatively common to make the exception message more
verbose / informative, e.g. using format() to embed specific details
about the problem besides the static message string. My own code uses
this idiom quite often. This would have to be sacrificed, or some other
workaround found, of course.


[...]
> > There's nothing about the 'throw' keyword that requires GC
> > allocation.  It's just that `throw new Exception(...)` has become a
> > standard incantation. The exception object itself can, for example,
> > be emplaced onto a static buffer as I propose above.
> 
> Yes, there are ways to work around allocating an exception with new
> right before throwing it, but that's really how things are designed to
> work, and there are serious problems with any attempt to work around
> it.  At minimum, it makes throwing exceptions to be a lot more of a
> pain then it is when using the GC [...]

I disagree. There is nothing about 'throw' that requires the use of
'new'.  A further development of the emplacement idea is to
pre-initialize a region allocator specifically for throwing exceptions,
then you can write:

throw makeException("Error occurred", ...);

where makeException is a global function that allocates the exception
using the region allocator (which is initialized at startup). The catch
block then deallocates the region and re-initializes it.  This is not
that much more painful than writing:

throw new Exception("Error occurred", ...);

This is just a quick-n-dirty example, of course. In an actual
implementation you'd templatize makeException() so that you can create
different exception types, e.g.:

throw make!UserDefinedException("...", ...);

Filename, line numbers, etc., can be easily accomodated the same way
they're currently handled in exception ctors.


> But the fact that the workarounds either require that you don't have
> unique, independent exceptions or that you know that you need to
> manually free the exception after catching it is a serious problem.
> And that's without even taking the exception chaining into account.
[...]

Using a preinitialized region allocator, we no longer have such
limitations.


T

-- 
GEEK = Gatherer of 

Re: Beta D 2.071.2-b5

[Rory McGuire via Digitalmars-d-announce]

On Wed, Sep 14, 2016 at 4:04 PM, Ali Çehreli via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On 09/14/2016 05:58 AM, Johan Engelen wrote:
>
>> On Wednesday, 14 September 2016 at 12:16:51 UTC, Martin Nowak wrote:
>>
>>> Fifth and hopefully last beta for the 2.071.2 release.
>>>
>>> This comes with two more fixes for Issue 16031 and 16460.
>>>
>>
>> LDC master is up-to-date with 2.071.2-b5!
>>
>
> Wow! LDC is just 42 minutes behind dmd. I wonder when it will pass it. :p
>
> Ali
>
>
:D, this does make me wonder why the ddmd frontend is inside the compiler
repos.

vibe.d maxRequestSize

[Chris via Digitalmars-d-learn]

The vibe.d server rejects `XMLHttpRequest`s that are too long (in 
the eyes of the server). In the docs it says


"maxRequestSize   ulong

Maximum number of transferred bytes per request after which the 
connection is closed with [sic!]"


However, when you go to

http://vibed.org/api/vibe.http.server/HTTPServerSettings.maxRequestSize

it says

"Maximum number of transferred bytes per request after which the 
connection is closed with an error; not supported yet"


"not supported yet" and I think it is not supported yet. Can I 
still change the server settings so that it accepts longer query 
strings? Atm, the server rejects strings that are > ~2,500 
characters, which is not much.

Re: Beta D 2.071.2-b5

[Ali Çehreli via Digitalmars-d-announce]

On 09/14/2016 05:58 AM, Johan Engelen wrote:

On Wednesday, 14 September 2016 at 12:16:51 UTC, Martin Nowak wrote:

Fifth and hopefully last beta for the 2.071.2 release.

This comes with two more fixes for Issue 16031 and 16460.


LDC master is up-to-date with 2.071.2-b5!


Wow! LDC is just 42 minutes behind dmd. I wonder when it will pass it. :p

Ali

Re: ddoc latex/formulas?

[jmh530 via Digitalmars-d]

On Wednesday, 14 September 2016 at 13:38:21 UTC, Manu wrote:


I'm just gonna come out and say that I really don't feel like 
taking
the few hours it might take me to try and understand what's 
going on

here. I really have better things to do...
Considering I don't really know latex either, I just have to 
wing
that, this is like 721 lines of tedious double-indirection, 
with no
examples in sight ;) (yet I'm being hassled about lack of 
examples!)




I learned Latex by playing with LyX. You can get things looking 
how you want pretty easily. When you copy some code from LyX and 
paste it somewhere else, the output is the Latex code you need. I 
do this somewhat frequently because the only Latex I remember is 
things like subscripts and superscripts.

Re: DlangUI 0.9.0: Console backend added

[ketmar via Digitalmars-d-announce]

On Wednesday, 14 September 2016 at 13:04:40 UTC, ketmar wrote:
in my editor i'm simply using rgb in [0..255] range, and 
mapping that to what terminal has. yet it is probably not the 
best way to make something nice looking when only 16 colors are 
available. heh, i should try and see how it will look like! ;-)


actually, it's not that bad, i expected much worser results.

original 256 color mode: 
http://ketmar.no-ip.org/img/tui/tui_c256.png
and this is restricted to basic 16 colors: 
http://ketmar.no-ip.org/img/tui/tui_c16a.png
still readable. my terminal has somewhat non-standard first 16 
colors (some colors are brighter than default xterm, some are 
not), that's probably why background becomes so bright. but it is 
still readable.


and this is 16 colors with "weighted translation" 
(0.30*r+0.59*g+0.11*b). looks surprisingly clean: 
http://ketmar.no-ip.org/img/tui/tui_c16b.png

Re: iPhone vs Android

[Laeeth Isharc via Digitalmars-d]

On Wednesday, 14 September 2016 at 06:33:59 UTC, Shachar Shemesh 
wrote:

On 14/09/16 09:05, Walter Bright wrote:

On 9/13/2016 10:38 PM, Shachar Shemesh wrote:
But if you do want to allow it, then my original problem 
comes back.

You have to
scan the malloced memory because you are not sure where that 
memory might

contain pointers to GC managed memory.


If mallocing for types that are statically known at compile 
time, it

should be knowable if they need scanning or not.



I believe you are under the assumption that structs will not be 
GC allocated. I don't think it is a good assumption to make. 
Even if it is, however:


struct SomeStruct {
  string something;
}

Please let me know if scanning this struct for GC pointers is 
necessary or not. Also, even if this is knowable, I'm not sure 
how you are suggesting we mange it.


The only practical approach I see is that if any RC managed 
memory might contain pointers to GC managed memory, then all RC 
managed memory needs to be scanned (unless you think the 
compiler can help out with that).


Shachar


In D code that I have read where people use RC types they have 
different names making it quite clear - eg RCString.but


If you're worrying about GC presumably you have a decent size 
problem anyway (and I admire the ambition of weka in this 
respect).  So then seems to me that yes,  there is a tax in 
writing code that uses the language in a way that a minority of D 
users are using it in.   The generation after the pioneers, if 
they avoid the arrows of the prior generation, at least have a 
lot more hard work than subsequent generations.   But on the 
other hand it is a package deal, and initial costs amortise.


How would you end up with a GC allocated struct by mistake 
(presuming you think it through first) at the size you are at? 
200k lines and 30 people is a lot,  but it's also not Windows 
scale.   And if you did,  and it mattered,  wouldn't you pick it 
up quickly with GC profiling?

Re: colour lib needs reviewers

[Meta via Digitalmars-d]

On Wednesday, 14 September 2016 at 13:28:23 UTC, Manu wrote:

Cheers.
Yeah, I need to do better with ddoc.

... I'm just gonna go on the record and say that I am really, 
really not enjoying ddoc ;)


I can't say I'm a fan either.

Re: iPhone vs Android

[Laeeth Isharc via Digitalmars-d]

On Wednesday, 14 September 2016 at 13:28:45 UTC, finalpatch wrote:

On Tuesday, 13 September 2016 at 18:24:26 UTC, deadalnix wrote:
No you don't, as how often the GC kicks in depend of the rate 
at which you produce garbage, which is going to be very low 
with an hybrid approach.


This is simply not true.

Assume in a pure GC program the GC heap can grow up to X Mb 
before a collection cycle happens, which has to scan X Mb of 
memory.


Now let's say we have a hybrid program that uses 0.5X Mb of 
RCed memory and 0.5X Mb of GC memory so the total memory 
consumption is still X Mb. When the GC heap reaches 0.5X Mb, it 
has to scan both RC and GC memory.


Could you elaborate? I thought based on both personal experience 
and the papers referred to that it's uncontroversial a GC program 
to run efficiently will need a multiple of actually used memory 
as available memory.   Thus the hybrid program should require 
less total memory than the pure GC program,  meaning at the same 
total memory consumption there is less GC pressure,  which I 
understood to be part of deadalnix  point.

Re: ddoc latex/formulas?

[Manu via Digitalmars-d]

On 14 September 2016 at 21:36, Andrei Alexandrescu via Digitalmars-d
 wrote:
> On 9/14/16 1:50 AM, Manu via Digitalmars-d wrote:
>>
>> Can we produce formulas, or latex in ddoc? Are there any examples in
>> phobos I can refer to?
>
>
> https://github.com/dlang/dlang.org/blob/master/latex.ddoc
>
> That's the macros file for generating the language spec in LaTeX format.

Ah, wow, yeah I actually saw this when I googled for it before posting here.

I'm just gonna come out and say that I really don't feel like taking
the few hours it might take me to try and understand what's going on
here. I really have better things to do...
Considering I don't really know latex either, I just have to wing
that, this is like 721 lines of tedious double-indirection, with no
examples in sight ;) (yet I'm being hassled about lack of examples!)

I'm kinda feeling ddoc is fairy serious problem. Doxygen is like... a
lot better :/
I'm struggling to produce docs I'm happy with. Formatting is hard,
macros for everything really sucks!

Re: What is the most stable D compiler

[Klmp via Digitalmars-d]

On Wednesday, 14 September 2016 at 11:52:00 UTC, Klmp wrote:

On Wednesday, 14 September 2016 at 11:34:22 UTC, eugene wrote:

What is the most reliable D compiler: dmd, ldc, gdc?


because it's slightly before DMD the answer is: LDC.


I meant slightly "behind", "before" is not appropriated. i 
understand the misunderstanding in the following comments. I 
meant that for LDC being just one step behind is an asset because 
there's always a risk of regression in DMD.



GDC is too far behind
DMD is at the front
LDC has most of the DMD fixes but sometimes without the 
regressions coming from the front.

Re: iPhone vs Android

[finalpatch via Digitalmars-d]

On Tuesday, 13 September 2016 at 18:24:26 UTC, deadalnix wrote:
No you don't, as how often the GC kicks in depend of the rate 
at which you produce garbage, which is going to be very low 
with an hybrid approach.


This is simply not true.

Assume in a pure GC program the GC heap can grow up to X Mb 
before a collection cycle happens, which has to scan X Mb of 
memory.


Now let's say we have a hybrid program that uses 0.5X Mb of RCed 
memory and 0.5X Mb of GC memory so the total memory consumption 
is still X Mb. When the GC heap reaches 0.5X Mb, it has to scan 
both RC and GC memory.


It's quite obvious that the time(t) it takes for program 1 to 
produce X Mb of garbage is the same as program 2 to produce 0.5X 
Mb of garbage, and after time t, both program have to scan X Mb 
of memory.  However program 2 also has to pay the cost of 
reference counting on top of that.


When you say hybrid program should trigger GC at a lower rate, 
you are actually assuming the hybrid program also has X Mb of GC 
heap, which makes total memory consumption 1.5X Mb, therefore it 
is not a fair comparison anymore.

Re: colour lib needs reviewers

[Manu via Digitalmars-d]

On 14 September 2016 at 22:47, Meta via Digitalmars-d
 wrote:
> On Monday, 12 September 2016 at 04:14:27 UTC, Manu wrote:
>>
>> I think I'm about as happy with my colour lib as I'm going to be. It
>> really needs reviews.
>>
>> I added packed-RGB support, including weird micro-float and
>> shared-exponent formats.
>> They're important for interacting with any real-time rendering libraries.
>> There is only one texture format I'm aware of that isn't supported,
>> and that is u7e3 floats, only available on Xbox360 ;)
>>
>> Chromatic adaptation functions are in.
>> I've done a tidy/reorg pass.
>>
>> I'm not sure what else should be in the scope of this lib.
>>
>> PR: https://github.com/dlang/phobos/pull/2845
>> dub: https://code.dlang.org/packages/color
>> docs:
>> http://dtest.thecybershadow.net/artifact/website-04a64e024cf75be39700bebd3a50d26f6c7bd163-7185c8ec7b15c9e785880cab6d512e6f/web/library-prerelease/std/experimental/color.html
>>
>> - Manu
>
>
> Looks like a nice and simple module. My only complaint is that DDOC sections
> such as Returns, Args, etc. don't seem to be used at all. Also maybe a bit
> more detailed of an overview in package.d, which I assume is the entry point
> for the documentation.

Cheers.
Yeah, I need to do better with ddoc.

... I'm just gonna go on the record and say that I am really, really
not enjoying ddoc ;)

If I could get people starting to review the code, I'll polish up the
docs over the next few days.

Re: DlangUI 0.9.0: Console backend added

[Rory McGuire via Digitalmars-d-announce]

On Wed, Sep 14, 2016 at 3:11 PM, ketmar via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 14 September 2016 at 13:08:18 UTC, Rory McGuire wrote:
>
>> Screenshots here are what can be done with terminal/ascii:
>> http://caca.zoy.org/wiki/libcaca
>>
>
> still, you can't use shading charaters to color text, so 16 colors for
> text output won't look that impressive. ;-)
>

:) true

Re: What is the most stable D compiler

[Guillaume Piolat via Digitalmars-d]

On Wednesday, 14 September 2016 at 12:13:33 UTC, eugene wrote:

On Wednesday, 14 September 2016 at 11:52:00 UTC, Klmp wrote:

On Wednesday, 14 September 2016 at 11:34:22 UTC, eugene wrote:

What is the most reliable D compiler: dmd, ldc, gdc?


because it's slightly before DMD the answer is: LDC.
GDC is too far behind
DMD is at the front
LDC has most of the DMD fixes but sometimes without the 
regressions coming from the front.


did you use ldc in production?
do you use ldc in production?


Yes. I only ever send builds made with LDC to customers, both for 
freelance work and products. Why?
I've found that with DMD there is a bigger chance of backend 
regressions. Using LDC you get to rely on a pretty rock-solid 
code generator.

I do use DMD for all dev builds.

Re: DlangUI 0.9.0: Console backend added

[ketmar via Digitalmars-d-announce]

On Wednesday, 14 September 2016 at 13:08:18 UTC, Rory McGuire 
wrote:
Screenshots here are what can be done with terminal/ascii: 
http://caca.zoy.org/wiki/libcaca


still, you can't use shading charaters to color text, so 16 
colors for text output won't look that impressive. ;-)

Re: DlangUI 0.9.0: Console backend added

[ketmar via Digitalmars-d-announce]

p.p.s. yep, VT-100 had only 4 functional keys, so we still 
enjoying having 'em encoded separately from the others.

Re: DlangUI 0.9.0: Console backend added

[ketmar via Digitalmars-d-announce]

On Wednesday, 14 September 2016 at 13:04:40 UTC, ketmar wrote:
On Wednesday, 14 September 2016 at 05:58:51 UTC, Vadim Lopatin 
CSI-with-modifier codes: \e[1;
this is common format for keys with modifiers, actually. let me 
quote my rawtty2:


  bool xtermMods (uint mci) @nogc {
switch (mci) {
  case 2: key.shift = true; return true;
  case 3: key.alt = true; return true;
  case 4: key.alt = true; key.shift = true; return true;
  case 5: key.ctrl = true; return true;
  case 6: key.ctrl = true; key.shift = true; return true;
  case 7: key.alt = true; key.ctrl = true; return true;
  case 8: key.alt = true; key.ctrl = true; key.shift = true; 
return true;

  default:
}
return false;
  }

  void xtermSpecial (char ch) @nogc {
switch (ch) {
  case 'A': key.key = TtyKey.Key.Up; break;
  case 'B': key.key = TtyKey.Key.Down; break;
  case 'C': key.key = TtyKey.Key.Right; break;
  case 'D': key.key = TtyKey.Key.Left; break;
  case 'E': key.key = TtyKey.Key.Pad5; break;
  case 'H': key.key = TtyKey.Key.Home; break;
  case 'F': key.key = TtyKey.Key.End; break;
  case 'P': key.key = TtyKey.Key.F1; break;
  case 'Q': key.key = TtyKey.Key.F2; break;
  case 'R': key.key = TtyKey.Key.F3; break;
  case 'S': key.key = TtyKey.Key.F4; break;
  case 'Z': key.key = TtyKey.Key.Tab; key.ch = 9; if 
(!key.shift && !key.alt && !key.ctrl) key.shift = true; break;

  default: badCSI(); break;
}
  }

Re: What is the most stable D compiler

[Johan Engelen via Digitalmars-d]

On Wednesday, 14 September 2016 at 12:13:33 UTC, eugene wrote:

On Wednesday, 14 September 2016 at 11:52:00 UTC, Klmp wrote:

On Wednesday, 14 September 2016 at 11:34:22 UTC, eugene wrote:

What is the most reliable D compiler: dmd, ldc, gdc?


because it's slightly before DMD the answer is: LDC.
GDC is too far behind
DMD is at the front
LDC has most of the DMD fixes but sometimes without the 
regressions coming from the front.


did you use ldc in production?
do you use ldc in production?


LDC (exclusively afaik) is used by Weka.io (http://www.weka.io).
Pretty serious "production use".

-Johan

Re: DlangUI 0.9.0: Console backend added

[Rory McGuire via Digitalmars-d-announce]

On Wed, Sep 14, 2016 at 3:04 PM, ketmar via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:

> On Wednesday, 14 September 2016 at 05:58:51 UTC, Vadim Lopatin wrote:
>
>> Thank you!
>> Now dlangui terminal mode supports only 16 colors.
>> Some refactoring is required to support RGB colors.
>>
>
> in my editor i'm simply using rgb in [0..255] range, and mapping that to
> what terminal has. yet it is probably not the best way to make something
> nice looking when only 16 colors are available. heh, i should try and see
> how it will look like! ;-)
>

Screenshots here are what can be done with terminal/ascii:
http://caca.zoy.org/wiki/libcaca

Re: DlangUI 0.9.0: Console backend added

[ketmar via Digitalmars-d-announce]

On Wednesday, 14 September 2016 at 05:58:51 UTC, Vadim Lopatin 
wrote:

Thank you!
Now dlangui terminal mode supports only 16 colors.
Some refactoring is required to support RGB colors.


in my editor i'm simply using rgb in [0..255] range, and mapping 
that to what terminal has. yet it is probably not the best way to 
make something nice looking when only 16 colors are available. 
heh, i should try and see how it will look like! ;-)


On Wednesday, 14 September 2016 at 06:06:51 UTC, Vadim Lopatin 
wrote:



at least in Gnome terminal.


maybe gnome terminal took those keys for it's own needs -- like 
tab switching or something. in xterm, those are usual 
CSI-with-modifier codes: \e[1;, where  is 6 for 
ctrl+shift, and  is A/B/C/D for Up/Down/Right/Left 
respectively.


it is better to check everything in xterm -- this is still the 
most used terminal emulator out there. just switch it to send 
 for alt-key instead of setting high bit. ;-)

Re: Beta D 2.071.2-b5

[Johan Engelen via Digitalmars-d-announce]

On Wednesday, 14 September 2016 at 12:16:51 UTC, Martin Nowak 
wrote:

Fifth and hopefully last beta for the 2.071.2 release.

This comes with two more fixes for Issue 16031 and 16460.


LDC master is up-to-date with 2.071.2-b5!

Re: colour lib needs reviewers

[Meta via Digitalmars-d]

On Monday, 12 September 2016 at 04:14:27 UTC, Manu wrote:
I think I'm about as happy with my colour lib as I'm going to 
be. It really needs reviews.


I added packed-RGB support, including weird micro-float and
shared-exponent formats.
They're important for interacting with any real-time rendering 
libraries.
There is only one texture format I'm aware of that isn't 
supported,

and that is u7e3 floats, only available on Xbox360 ;)

Chromatic adaptation functions are in.
I've done a tidy/reorg pass.

I'm not sure what else should be in the scope of this lib.

PR: https://github.com/dlang/phobos/pull/2845
dub: https://code.dlang.org/packages/color
docs: 
http://dtest.thecybershadow.net/artifact/website-04a64e024cf75be39700bebd3a50d26f6c7bd163-7185c8ec7b15c9e785880cab6d512e6f/web/library-prerelease/std/experimental/color.html


- Manu


Looks like a nice and simple module. My only complaint is that 
DDOC sections such as Returns, Args, etc. don't seem to be used 
at all. Also maybe a bit more detailed of an overview in 
package.d, which I assume is the entry point for the 
documentation.

Re: refRange and @disable this(this);

[Jerry via Digitalmars-d]

On Wednesday, 14 September 2016 at 12:39:16 UTC, Jerry wrote:

It feels strange that refRange ever want to copy.
Bug or feature?


Or more specificly, shouldn't save only be defined if the range 
defines it instead of using copy? Which is presume is the problem.

refRange and @disable this(this);

[Jerry via Digitalmars-d]

I got a range which disables copy construction and I want to loop 
the range within another loop using the same range.
So I thought I can mark the struct range with @disable this(this) 
and then use refRange to initialize the loop.


So with something like this:

void main()
{   
auto valueRange = FooRange("123");
foreach(ch; refRange())
writeln(ch);
}


struct FooRange {
@disable this();
@disable this(this);
this(string str) {
this.str = str;
}

@property bool empty() { return str.empty; }
@property dchar front() { return str.front; }
void popFront() { str.popFront; }

private:
string str;
}


But I get compile time errors messages saying:
std/range/package.d(8155,23): Error: struct app.FooRange is not 
copyable because it is annotated with @disable


It feels strange that refRange ever want to copy.
Bug or feature?

Re: Binary heap: obtain a _reference_ to the front of the heap

[Johan Engelen via Digitalmars-d-learn]

On Tuesday, 13 September 2016 at 08:55:15 UTC, Nicholas Wilson 
wrote:
On Tuesday, 13 September 2016 at 08:19:04 UTC, Johan Engelen 
wrote:
In the binary heap documentation, I read that 
`BinaryHeap.front()` "Returns a copy of the front of the 
heap". [1]
Is there no function to access the front of the heap without a 
copy?  (micro-optimization)


Thanks,
  Johan

[1] 
https://dlang.org/phobos/std_container_binaryheap.html#.BinaryHeap.front


What does
foreach(ref e; bh)
{
 //...
}
do?


It copies the front of the heap on every iteration.

Beta D 2.071.2-b5

[Martin Nowak via Digitalmars-d-announce]

Fifth and hopefully last beta for the 2.071.2 release.

This comes with two more fixes for Issue 16031 and 16460.

http://dlang.org/changelog/2.071.2.html
http://dlang.org/download.html#dmd_beta

Please report any bugs at https://issues.dlang.org

-Martin

Re: iPhone vs Android

[Jonathan M Davis via Digitalmars-d]

On Tuesday, September 13, 2016 16:13:05 H. S. Teoh via Digitalmars-d wrote:
> On Tue, Sep 13, 2016 at 03:19:54PM -0700, Jonathan M Davis via Digitalmars-d
> wrote: [...]
>
> > But none of the code that's marked @nogc can throw an exception unless
> > you're either dealing with pre-allocated exceptions (in which case,
> > they're less informative),
>
> I don't see why pre-allocated exceptions would be less informative. You
> can always modify the exception object before throwing it, after all.
> In fact, I've always wondered about the feasibility of a @nogc exception
> handling system where the exception is emplaced onto a fixed static
> buffer, so that no allocation (except at the start of the program) is
> actually necessary. Of course, chained exceptions throw(!) a monkey
> wrench into the works, but assuming we forego chained exceptions,
> wouldn't this work around the problem of being unable to allocate
> exceptions in @nogc code? (Albeit with its own limitations, obviously.
> But it would be better than being unable to use exceptions at all in
> @nogc code.)

As Walter points out, it's a problem if exceptions are ever saved (which
some code does need to do). The fact that you lose chaining as you pointed
out is also a problem. You also have problems because the file, line, and
message of the exception either aren't going to be specific to when that
exception is thrown, or you have to set them all before throwing, in which
case you have issues with if/when the exception is reused. And regardless of
all of that, the fact that string is used for the message throws a wrench in
things for @nogc, since that's going to require GC allocation unless you
cast something to string, and then you have serious problems if you need to
mutate it later, since you'll end up violating the compiler guarantees for
immutable.

>
> [...]
>
> > So, I really think that we need to find a way to make it so that
> > exceptions aren't GC allocated normally anymore - or at least have a
> > way to reasonably and easily not be GC allocated - but the problem is
> > @nogc, not the actual memory management or its cost.
>
> [...]
>
> There's nothing about the 'throw' keyword that requires GC allocation.
> It's just that `throw new Exception(...)` has become a standard
> incantation. The exception object itself can, for example, be emplaced
> onto a static buffer as I propose above.

Yes, there are ways to work around allocating an exception with new right
before throwing it, but that's really how things are designed to work, and
there are serious problems with any attempt to work around it. At minimum,
it makes throwing exceptions to be a lot more of a pain then it is when
using the GC (meaning that plenty of folks will just happily use the GC when
they wouldn't need it aside from the exception, which then renders their
code unable to be @nogc), and really, that's enough to be a serious problem.
But the fact that the workarounds either require that you don't have unique,
independent exceptions or that you know that you need to manually free the
exception after catching it is a serious problem. And that's without even
taking the exception chaining into account.

At this point, I'd say that exceptions can be used in @nogc in rare
circumstances where you're very careful about what you're doing, but in the
general case, it's really not an option. Realistically, if we want folks to
be using exceptions in @nogc in general, I think that it needs to be about
as simple as throw new Exception(message); is, and we're not even close to
that. Without that, we're likely to end up with a divide between code that
uses the GC and code that uses exceptions.

- Jonathan M Davis

Re: What is the most stable D compiler

[eugene via Digitalmars-d]

On Wednesday, 14 September 2016 at 11:52:00 UTC, Klmp wrote:

On Wednesday, 14 September 2016 at 11:34:22 UTC, eugene wrote:

What is the most reliable D compiler: dmd, ldc, gdc?


because it's slightly before DMD the answer is: LDC.
GDC is too far behind
DMD is at the front
LDC has most of the DMD fixes but sometimes without the 
regressions coming from the front.


did you use ldc in production?
do you use ldc in production?

Re: Compiling vibe.d application for Amazon ec2 instance

[Seb via Digitalmars-d-learn]

On Monday, 12 September 2016 at 02:14:08 UTC, Jonathan M Davis 
wrote:
On Sunday, September 11, 2016 23:12:15 crimaniak via 
Digitalmars-d-learn wrote:

[...]


I've never used EC2, so I don't know what it would take to be 
able to build in the same environment locally (though I would 
certainly think that there would be a way do to so, and I would 
assume that Amazon's documentation talks about it somewhere). 
However, you can try just grabbing the .zip file for dmd and 
putting that on your EC2 instance and using that to build your 
program there - especially if you're in a hurry.


[...]


You should try -static in ldc, it's works like a dream for me :)

[Issue 14414] allow to set hash seed

[via Digitalmars-d-bugs]

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

--- Comment #1 from Sobirari Muhomori  ---
Another possibility is to change the hash algorithm adaptively by counting
collisions.

--

Re: Critque of Rust's collection types

[Kagamin via Digitalmars-d]

On Wednesday, 14 September 2016 at 00:36:39 UTC, Walter Bright 
wrote:
Of particular interest is the advocacy of collision attack 
resistance. Is anyone interested in exploring this w.r.t. D's 
builtin hashes?


Perl's approach is probably good enough 
https://issues.dlang.org/show_bug.cgi?id=14414

Reversibility of the hash looks irrelevant for dos attack.

Re: I hate new DUB config format

[Suliman via Digitalmars-d]

Sönke Ludwig, really sorry. It's look my big mistake. I looked at 
SDL more detail, and this format is much better than JSON.


I hope a lot of people is changed their position too.

Re: What is the most stable D compiler

[Klmp via Digitalmars-d]

On Wednesday, 14 September 2016 at 11:34:22 UTC, eugene wrote:

What is the most reliable D compiler: dmd, ldc, gdc?


because it's slightly before DMD the answer is: LDC.
GDC is too far behind
DMD is at the front
LDC has most of the DMD fixes but sometimes without the 
regressions coming from the front.

Re: What is the most stable D compiler

[eugene via Digitalmars-d]

yes, speed is a second matter, so the first matter is 
reliability, i.e.: the less bugs compiler has, the more it is 
stable, which of them is the most stable one?

Re: What is the most stable D compiler

[rikki cattermole via Digitalmars-d]

On 14/09/2016 11:37 PM, eugene wrote:

On Wednesday, 14 September 2016 at 11:35:46 UTC, rikki cattermole wrote:

On 14/09/2016 11:34 PM, eugene wrote:

What is the most reliable D compiler: dmd, ldc, gdc?
Which can be used in production?
Why there are 3(maybe more) compilers and not just one?


What exactly do you define as stable?


i mean without bugs in compiler


Okay well all three compilers share a frontend with all new work being 
done in dmd.


GDC is the slowest to update currently so that can be ignored for now.
LDC has fairly fast updates in terms of the frontend and can target more 
platforms.


So the question is simply, do you care about performance or platform 
availability over faster bug fixes and new features?


Most people develop using dmd because of the fast turn around times, but 
utilize ldc IF they need performance in the end program.
But in most cases you don't need to worry about performance or platform 
support so dmd wins out.

Re: ddoc latex/formulas?

[Andrei Alexandrescu via Digitalmars-d]

On 9/14/16 1:50 AM, Manu via Digitalmars-d wrote:

Can we produce formulas, or latex in ddoc? Are there any examples in
phobos I can refer to?


https://github.com/dlang/dlang.org/blob/master/latex.ddoc

That's the macros file for generating the language spec in LaTeX format.


Andrei

Re: What is the most stable D compiler

[eugene via Digitalmars-d]

On Wednesday, 14 September 2016 at 11:35:46 UTC, rikki cattermole 
wrote:

On 14/09/2016 11:34 PM, eugene wrote:

What is the most reliable D compiler: dmd, ldc, gdc?
Which can be used in production?
Why there are 3(maybe more) compilers and not just one?


What exactly do you define as stable?


i mean without bugs in compiler

Re: What is the most stable D compiler

[rikki cattermole via Digitalmars-d]

On 14/09/2016 11:34 PM, eugene wrote:

What is the most reliable D compiler: dmd, ldc, gdc?
Which can be used in production?
Why there are 3(maybe more) compilers and not just one?


What exactly do you define as stable?

What is the most stable D compiler

[eugene via Digitalmars-d]

What is the most reliable D compiler: dmd, ldc, gdc?
Which can be used in production?
Why there are 3(maybe more) compilers and not just one?

Re: Virtual Methods hurting performance in the DMD frontend

[Johan Engelen via Digitalmars-d]

On Tuesday, 13 September 2016 at 21:01:34 UTC, Stefan Koch wrote:

On Monday, 12 September 2016 at 08:03:45 UTC, Stefan Koch wrote:
On Sunday, 11 September 2016 at 21:48:56 UTC, Stefan Koch 
wrote:

Those are indirect class

I meant indirect calls!

@Jacob

Yes that is my indented solution.
Having a type-field in root-object.


A Small update on this.
When dmd is complied with ldc this problem seems to lessen.


Try PGO with LDC 1.1.0-beta.
https://johanengelen.github.io/ldc/2016/04/13/PGO-in-LDC-virtual-calls.html

Re: vibe.d PaaS

[Guillaume Piolat via Digitalmars-d-learn]

On Wednesday, 14 September 2016 at 09:40:47 UTC, wobbles wrote:
On Wednesday, 14 September 2016 at 09:01:11 UTC, Guillaume 
Piolat wrote:

Is there vibe.d hosting sold anywhere?


Not that I know, but any VPS you rent would be capable of 
hosting it.


I guess you don't want to deal with all of the other services 
you'd need? (nginx / security / dbs etc etc ?)


That's what I do currently, but I'm no sysadmin and something 
that would bundle postgres, vibe.d and SSL for the lazy would be 
nice. Though the market for it is probably small.

Re: colour lib needs reviewers

[Marco Leise via Digitalmars-d]

Am Wed, 14 Sep 2016 11:36:12 +1000
schrieb Manu via Digitalmars-d :

> On 14 September 2016 at 04:34, Marco Leise via Digitalmars-d
>  wrote:
> > JavaScript's canvas works that way for
> > example. I.e. the only pixel format is RGBA for simplicity's
> > sake and I'm not surprised it actually draws something if I
> > load it with a 24-bit graphic. ;)  
> 
> Given this example, isn't it the job of the image loader to populate
> the image with data?2
> […]

I admit is was a constructed example. You can't load an image
directly into a HTML5 canvas. Shame on me.

> You'll notice I didn't add arithmetic operators to the HSx type ;)
> If you have HSx colors,  and want to do arithmetic, cast it to RGB first.

Now that you say it, yes I was wondering how the arithmetics
work since I couldn't find any opBinary.
 
> I went through a brief phase where I thought about adding an angle
> type (beside normint), but I felt it was overkill.
> I still wonder if it's the right thing to do though... some type that
> understands a circle, and making angle arithmetic work as expected.

I see. I'm also wondering what equality means for a color with
floating point hue 10° and another with hue 730°. I guess it
is ok the way it is now, because wrapping the values doesn't
guarantee they map to the same value either. Floating point
equality is flawed either way.

-- 
Marco

Re: vibe.d PaaS

[llaine via Digitalmars-d-learn]

On Wednesday, 14 September 2016 at 09:40:47 UTC, wobbles wrote:
On Wednesday, 14 September 2016 at 09:01:11 UTC, Guillaume 
Piolat wrote:

Is there vibe.d hosting sold anywhere?


Not that I know, but any VPS you rent would be capable of 
hosting it.


I guess you don't want to deal with all of the other services 
you'd need? (nginx / security / dbs etc etc ?)


No PaaS service, but you can pretty simply use Heroku to deploy 
any vibe.d application.


Check the tour.dlang.io 
http://tour.dlang.io/tour/en/vibed/deploy-on-heroku where 
everything is explained :)

[Issue 16492] support @nogc in debug{} blocks

[via Digitalmars-d-bugs]

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

--- Comment #2 from Manu  ---
It already does that... no?

--

[Issue 13615] stable sort not usable in @safe code

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

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

--- Comment #4 from Walter Bright  ---
This is working in the latest master.

--

[Issue 15907] Unjustified "is not visible from module" deprecation warning when using getMember trait

[via Digitalmars-d-bugs]

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

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

https://github.com/dlang/phobos/commit/b2d0226d4845d69b60ea26f54c1edec36ad08b11
supplemental change for Issue 15907 fix

https://github.com/dlang/phobos/commit/d10780f19544f73907540e98aeee0039807e4578
Merge pull request #4747 from MartinNowak/fix15907

--

Re: iPhone vs Android

[Jacob Carlborg via Digitalmars-d]

On 2016-09-13 20:40, Steven Schveighoffer wrote:


Swift doesn't support exceptions AFAIK. It supports weird error handling
that looks similar to exceptions, but is really just a standard return.

i.e. this:

do
{
   try someFunctionThatErrors(arg)
}
catch(Exception ex)
{
   // handle ex
}

really compiles like this:

var _err : Error?
someFunctionThatErrors(arg, &_err)
if(_err != nil)
{
   let ex = _err!.exception
}


Exactly and you're not supposed to catch exceptions in Objective-C. It's 
more like Errors in D.


--
/Jacob Carlborg

Re: vibe.d PaaS

[wobbles via Digitalmars-d-learn]

On Wednesday, 14 September 2016 at 09:01:11 UTC, Guillaume Piolat 
wrote:

Is there vibe.d hosting sold anywhere?


Not that I know, but any VPS you rent would be capable of hosting 
it.


I guess you don't want to deal with all of the other services 
you'd need? (nginx / security / dbs etc etc ?)

Re: Virtual Methods hurting performance in the DMD frontend

[Jacob Carlborg via Digitalmars-d]

On 2016-09-13 23:01, Stefan Koch wrote:


However much of dmd's code especially in dtemplate could be simpified if
it could just switch on a value. instead of doing method calls and null
checks.


At least to me, it would be very useful for debugging purpose as well.

--
/Jacob Carlborg