Why don't we write configuration files in D instead of JSON?

[Guido via Digitalmars-d-learn]

It would seem that by running the file through mixin, you can 
simply create the vars you want in scope. The drawback being 
random code execution. Is there any way to sanitize mixin code 
from user-configurable file?


Once that's shot down, does anyone know a .json to .sdl converter 
program

Re: Button: A fast, correct, and elegantly simple build system.

[Jason White via Digitalmars-d-announce]

On Wednesday, 15 June 2016 at 12:02:56 UTC, Andrei Alexandrescu 
wrote:
In all likelihood. One issue with build systems is there's no 
clear heir to make. There are so many, including a couple (!) 
by our community, each with its pros and cons. Which one should 
we choose?


You should choose mine, obviously. ;)

In all seriousness, Make will probably live as long as C. There 
are a *ton* of Makefiles out there that no one wants translate to 
a new build system. Part of the reason for that is probably 
because they are so friggin' incomprehensible and its not exactly 
glamorous work. This is why I'm working on that tool to allow 
Button to build existing Makefiles [1]. It may not work 100% of 
the time, but it should help a lot with migrating away from Make.


[1] https://github.com/jasonwhite/button-make

Re: Button: A fast, correct, and elegantly simple build system.

[Jason White via Digitalmars-d-announce]

On Wednesday, 15 June 2016 at 12:00:52 UTC, Andrei Alexandrescu 
wrote:
I'd say the gating factor is -j. If an build system doesn't 
implement the equivalent of make -j, that's a showstopper.


Don't worry, there is a --threads option and it defaults to the 
number of logical cores.


I just did some tests and the reason it is slower than Make is 
because of the automatic dependency detection on every single 
command. I disabled the automatic dependency detection and 
compared it with Make again. Button was then roughly the same 
speed as Make -- sometimes it was faster, sometimes slower. 
Although, I think getting accurate dependencies at the cost of 
slightly slower builds is very much a worthwhile trade-off.

Re: Passing anonymous templated functions as template parameters

[Basile B. via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 23:52:56 UTC, Basile B. wrote:

On Wednesday, 15 June 2016 at 22:27:38 UTC, pineapple wrote:
Here's a simple code example to illustrate what I expected to 
work and didn't - is this a mistake in my syntax or a 
limitation of the language?


template SomeTemplate(alias func){
auto templatefunc(T)(int x){
return func!T(x);
}
}

// Valid
auto somefunc(T)(int x){
return cast(T) x;
}
alias fn1 = SomeTemplate!somefunc;

// Not valid
alias fn2 = SomeTemplate!(
(T)(int x){return cast(T) x;}
);


This syntax passes:

alias fn2(T) = SomeTemplate!((int x){return cast(T) x;});


I didn't try to instanciate previously. It works a bit with a 
lambda to the

extent that the alias has the template parameter list.

import std.stdio;

template A(alias func)
{
auto a(T)(int x)
{
return func!T(x);
}
}

alias spec(T) = A!(x => (cast(T) x));

void main(string[] args)
{
writeln((spec!byte).a!int(257)); // 1
}

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Thursday, 16 June 2016 at 02:53:38 UTC, Andrei Alexandrescu 
wrote:

On 6/15/16 9:34 PM, tsbockman wrote:
Why didn't you make your design requirements known at any 
earlier point
in this process? If you are ultimate gate keeper for Phobos 
(as you seem

to be), you ought to make your requirements known *before* the
implementation is finished.


Apologies about that. I've done a bit of spelunking to see what 
happened. Indeed the first reference to SafeInt is on a forum 
post on 6/7/2015, followed immediately by 
https://github.com/dlang/phobos/pull/3389 which entailed a long 
discussion.


You first posted about checkedint here on 6/30/2015, in a large 
thread.


At that time, I had the std.allocator review going on (started 
on 6/11/2015), a newborn baby, and a move across the continent 
to worry about (which happened at the end of June). It is 
entirely possible I just missed that discussion, or more likely 
saw it and had no meaningful input at the time. There has been 
a gap in forum posts with "checkedint" in the title between 
7/3/2015 and 6/7/2016,


Numerous other mentions were made of this project in various 
contexts on the forums, in GitHub pull requests, and on the bug 
tracker - including discussions in which you participated. 'posts 
with "checkedint" in the title' is too narrow of a search filter.


so it's not like there was a continuing presence I was working 
hard to ignore. I honestly think there's nothing to be offended 
over.


Malicious intent is not required to make the act offensive; 
you're still jumping into a project a year in the making and 
demanding that I choose between investing an additional six 
months (wild guess) of my time working on things I don't care 
about (at best), or canceling the project (which has otherwise 
received generally positive feedback so far).


I am not too upset mostly because I had a variety of reasons for 
pursuing this, not all of which depend on getting it into Phobos.


This underlies a larger issue. There must be a protocol that 
guarantees a proposal is brought to consideration to the D 
leadership. Dicebot is leading such an initiative (which can be 
seen as a revamping of DIPs) and we hope to get it finalized 
soon.



Andrei


That is part of the problem, but this is also a fine example of a 
broader pattern that I have noticed in D's review process:


Pull requests are routinely reviewed in an upside-down fashion:

1) Formatting
2) Typos
3) Names
4) Tests (and names again)
6) Docs (and names)
8) Design (and more about names)
9) Does this even belong in Phobos?

I don't think people are doing it on purpose - it's just easier 
to start with the trivial nit-picks, because you don't need a 
deep understanding of the code and the problem domain (or 
decision-making authority) to complain about a missing ' ' or 
something.


But, that doesn't change the fact that the process still feels 
almost perfectly designed to waste contributors' time.


Unless the PR is a complete mess, (9) and (8) should be debated 
*first*, before worrying about any of the other stuff. Why waste 
people's time fixing trivialities, if it's all going to just be 
deleted or rewritten anyway?

Re: std.experimental.checkedint is ready for comments!

[Andrei Alexandrescu via Digitalmars-d]

On 6/15/16 9:34 PM, tsbockman wrote:

`checkedint` (and @burner's `SafeInt` before it) have been under
development in the open for over a year now. There have been several
discussions in the forums, with feedback being actively solicited.
Significant design changes were made to address various people's needs.
`SafeInt` was an open pull request for many months with 100+ comments
accumulating in that time.

Why didn't you make your design requirements known at any earlier point
in this process? If you are ultimate gate keeper for Phobos (as you seem
to be), you ought to make your requirements known *before* the
implementation is finished.


Apologies about that. I've done a bit of spelunking to see what 
happened. Indeed the first reference to SafeInt is on a forum post on 
6/7/2015, followed immediately by 
https://github.com/dlang/phobos/pull/3389 which entailed a long discussion.


You first posted about checkedint here on 6/30/2015, in a large thread.

At that time, I had the std.allocator review going on (started on 
6/11/2015), a newborn baby, and a move across the continent to worry 
about (which happened at the end of June). It is entirely possible I 
just missed that discussion, or more likely saw it and had no meaningful 
input at the time. There has been a gap in forum posts with "checkedint" 
in the title between 7/3/2015 and 6/7/2016, so it's not like there was a 
continuing presence I was working hard to ignore. I honestly think 
there's nothing to be offended over.


This underlies a larger issue. There must be a protocol that guarantees 
a proposal is brought to consideration to the D leadership. Dicebot is 
leading such an initiative (which can be seen as a revamping of DIPs) 
and we hope to get it finalized soon.



Andrei

Re: Passing anonymous templated functions as template parameters

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/15/16 7:52 PM, Basile B. wrote:

On Wednesday, 15 June 2016 at 22:27:38 UTC, pineapple wrote:

Here's a simple code example to illustrate what I expected to work and
didn't - is this a mistake in my syntax or a limitation of the language?

template SomeTemplate(alias func){
auto templatefunc(T)(int x){
return func!T(x);
}
}

// Valid
auto somefunc(T)(int x){
return cast(T) x;
}
alias fn1 = SomeTemplate!somefunc;

// Not valid
alias fn2 = SomeTemplate!(
(T)(int x){return cast(T) x;}


This isn't valid syntax.

I don't think you can create anonymous templates. I could be wrong.

-Steve

Re: Anybody still using the chm docs

[Jack Stouffer via Digitalmars-d]

On Wednesday, 15 June 2016 at 10:58:04 UTC, Martin Nowak wrote:
So I'm wondering if in 2016 someone really needs an offline 
copy of a website shipped with a binary release?


For offline browsing, Windows and Linux users can use Zeal [1] 
which is FOSS, and macOS users can use Dash[2], which is free as 
in beer. Both of which can use this D docset [3].


So no, there's no reason to maintain the chm docs.

[1] https://zealdocs.org/
[2] https://kapeli.com/dash
[3] 
https://github.com/Kapeli/Dash-User-Contributions/tree/master/docsets/D#readme

Out of order execution

[Joerg Joergonson via Digitalmars-d-learn]

Suppose I have a loop where I execute two functions:

for(...)
{
   if (x) Do1(x);
   if (y) Do2(y);
}

The problem is, I really always want to execute all the Do2's 
first then the Do1's. As is, we could get any order of calls.


Suppose I can't run the loop twice for performance reasons(there 
is other stuff in it) and I don't want to store the state and 
call info then sort them out afterwards.


Is there an efficient lazy way to make this happen?

[Issue 16166] struct constructor and AliasSeq

[via Digitalmars-d-bugs]

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

--- Comment #2 from Danila Letunovskiy  ---
struct Window {
string title;
int x, y;
int w, h;
alias title this;
}

void main(){
Window w = "Foo";
}

--

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Thursday, 16 June 2016 at 00:33:38 UTC, Andrei Alexandrescu 
wrote:

On 06/15/2016 08:07 PM, tsbockman wrote:

But, I would appreciate it if comments distinguished between:

1) My goals and philosophy differ from yours, versus
2) My implementation is bad.

I think a lot of the high-level criticism you brought is 
really rooted

in (1), even though you present it as (2).


My perception is your implementation is professional. -- Andrei


Thank you.

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Thursday, 16 June 2016 at 00:31:38 UTC, Andrei Alexandrescu 
wrote:

On 06/15/2016 02:50 PM, tsbockman wrote:
What you are proposing is *not* "fixing" my design - it is 
basically
scrapping it and replacing it with a ground-up rewrite, with 
perhaps
some bits and pieces and general inspiration taken from my 
work.


I'd say that's a fair assessment on the face of it. But the 
pieces are there and the grit and expertise to assemble them 
are already there. The real question is what's the "right" 
design. Ideally we should optimize for that.


I set out to solve a specific problem with `checkedint`, and I 
believe my design succeeds in the areas that it is intended to, 
to the extent that is reasonably possible with D today.


In order to convince me to rewrite this, you would need to 
convince me that *my* goals can be met significantly better by a 
different library design. So far, I see no evidence of this.


You are of course free to set different goals than I have, but 
from my perspective this is *major* scope creep, and not what I 
volunteered for.


I'm OK with the community rejecting my design if that's what 
people
really want to do, but I will not be implementing your 
proposal myself.
I will simply leave `checkedint` on DUB, and move on with my 
life.


That is sensible, and a course of action I thought would 
transpire. But I suggest you to reconsider. Your PR is a solid 
implementation of the wrong idea. Before anyone gets offended, 
let me add that I think there's a lot of good in that.


There is only one thing about all this that really offends me:

`checkedint` (and @burner's `SafeInt` before it) have been under 
development in the open for over a year now. There have been 
several discussions in the forums, with feedback being actively 
solicited. Significant design changes were made to address 
various people's needs. `SafeInt` was an open pull request for 
many months with 100+ comments accumulating in that time.


Why didn't you make your design requirements known at any earlier 
point in this process? If you are ultimate gate keeper for Phobos 
(as you seem to be), you ought to make your requirements known 
*before* the implementation is finished.


Even so, I'm not particularly upset. I've learned a great deal 
through this project, and `checkedint` will still be available 
for anyone who wants to use it through DUB.


The code is Boost Licensed, so anyone who wants to is free to 
fork it and try to fulfill your vision.


For this kind of work (not algorithm-intensive) ideas are 
cheap; the solid implementation matters a lot more than the 
idea - the same expertise can be put to use on another idea.


I tried to offer a careful review by a competent peer, with an 
eye for taking an okay design toward a great design. The kind 
of review I wish to get now as much as at any point of my 
career. They are difficult to receive but often have a lot of 
potential in them.


I don't mind a scathing review, so long as it has been properly 
researched and thought through. I do object to being criticized 
for not including features that no one asked me for until now, 
and which have little to do with the original purpose of the 
project, though.


So, I'm putting out a general call now for the community to 
download the
DUB package, try actually *using* it for something, and speak 
up as to

whether the design seems good, or not.

If the decision is made to accept the high-level design, then 
we can go
back to bikeshedding about names, fixing typos, 
tweaking/trimming the

API, etc.


I don't think checkedint in a form close to its current one is 
for Phobos. I would argue it's not for D. Starting with the 
problem statement "we want to check integral operations for 
overflow and other surprising behaviors" and ending with 4.5 
KLOC defining a bunch of names in 6 modules makes it highly 
suspicious there is an overgrown underbelly somewhere. The 
language features are not orchestrated properly. Even if it 
were the case that there's no smaller design that conforms with 
the requirements, that means requirements have a problem.



Andrei


I believe a fundamental part of the problem, is that something 
like `SmartInt` should be built in to the language as the default 
integer type, not tacked on as a library. (Stuff like bound types 
would still be implemented in the library.)


However, my understanding is that this approach was reject by 
Walter Bright about two years ago (and obviously actually making 
it default would involve unacceptable breakage at this point). 
So, I tried to work with what we have.

Re: GTKD - Application crashes - or not? [Coedit]

[Basile B. via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 23:41:51 UTC, Basile B. wrote:

On Wednesday, 15 June 2016 at 17:35:32 UTC, TheDGuy wrote:
I'm gonna check on Windows today but in the meantime you can try



I've checked on windows and here is what I can say about the 
problem.


- Symbolic strings won't work on the "CurrentDirectoy" parameter. 
This is not handled at all. (you would get an error 267). I'll 
add the translation code for this parameter but this is for 
version 3 so not soon.


- I had to verify but the cwd should really be set to the path 
where the application is output. I mean that it's written so. I 
don't know what's happening on your system right now. My windows 
is still win 7 and my dev directory is not in ProgramFiles. And 
I've tested using this simple project: 
https://gist.github.com/BBasile/2e110ed48989b53e2a53b57977a81736. 
You can DL it as a zip, open the .ce file as a project and click 
"compile project and run" you should see the right CWD written in 
the messages.


- You can create a launcher in the custom tools, excluding the 
double quote:

- as executable type ""
- as CurrentDirectory type ""
- as alias put something like "Run this project"
This will work if the binary is compiled in the same directory as 
the binary that's produced. Otherwise you can adjust by adding 
directories after the symbol. (e.g  "bin\release").

Re: std.experimental.checkedint is ready for comments!

[Andrei Alexandrescu via Digitalmars-d]

On 06/15/2016 08:07 PM, tsbockman wrote:

On Thursday, 16 June 2016 at 00:03:26 UTC, Andrei Alexandrescu wrote:

On 06/15/2016 07:34 PM, tsbockman wrote:

The whole point of `checkedint` is to be able to write algorithms based
on the simplifying assumption that your variables behave like real,
UNbounded mathematical integers, secure in the knowledge that an error
message will be generated if that assumption is invalidated.


Fair point, though one could make the same claim for integers within
other limits than the machine's. -- Andrei


Sure. I'm just trying to explain my design goals and philosophy - not to
argue that no other approach could be valid.

But, I would appreciate it if comments distinguished between:

1) My goals and philosophy differ from yours, versus
2) My implementation is bad.

I think a lot of the high-level criticism you brought is really rooted
in (1), even though you present it as (2).


My perception is your implementation is professional. -- Andrei

Re: std.experimental.checkedint is ready for comments!

[Andrei Alexandrescu via Digitalmars-d]

On 06/15/2016 02:50 PM, tsbockman wrote:

On Wednesday, 15 June 2016 at 16:40:19 UTC, Andrei Alexandrescu wrote:

I think there are a few considerable issues with the proposal, but
also that all are fixable.


I already sent a much longer message detailing some of the reasons why I
believe my design is sensible. But, before we continue this discussion
much further, I need to stop and make one thing clear:

What you are proposing is *not* "fixing" my design - it is basically
scrapping it and replacing it with a ground-up rewrite, with perhaps
some bits and pieces and general inspiration taken from my work.


I'd say that's a fair assessment on the face of it. But the pieces are 
there and the grit and expertise to assemble them are already there. The 
real question is what's the "right" design. Ideally we should optimize 
for that.



I'm OK with the community rejecting my design if that's what people
really want to do, but I will not be implementing your proposal myself.
I will simply leave `checkedint` on DUB, and move on with my life.


That is sensible, and a course of action I thought would transpire. But 
I suggest you to reconsider. Your PR is a solid implementation of the 
wrong idea. Before anyone gets offended, let me add that I think there's 
a lot of good in that. For this kind of work (not algorithm-intensive) 
ideas are cheap; the solid implementation matters a lot more than the 
idea - the same expertise can be put to use on another idea.


I tried to offer a careful review by a competent peer, with an eye for 
taking an okay design toward a great design. The kind of review I wish 
to get now as much as at any point of my career. They are difficult to 
receive but often have a lot of potential in them.



So, I'm putting out a general call now for the community to download the
DUB package, try actually *using* it for something, and speak up as to
whether the design seems good, or not.

If the decision is made to accept the high-level design, then we can go
back to bikeshedding about names, fixing typos, tweaking/trimming the
API, etc.


I don't think checkedint in a form close to its current one is for 
Phobos. I would argue it's not for D. Starting with the problem 
statement "we want to check integral operations for overflow and other 
surprising behaviors" and ending with 4.5 KLOC defining a bunch of names 
in 6 modules makes it highly suspicious there is an overgrown underbelly 
somewhere. The language features are not orchestrated properly. Even if 
it were the case that there's no smaller design that conforms with the 
requirements, that means requirements have a problem.



Andrei

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Thursday, 16 June 2016 at 00:06:13 UTC, Andrei Alexandrescu 
wrote:

On 06/15/2016 07:13 PM, tsbockman wrote:


Standardizing the error handling methods is also important for 
other interoperability-related reasons:

[...]


I don't agree with this. On the face of it, three built-in 
policies solve the matter of interoperability: if you want 
interop, use one of those. Done. But interop is not a reason to 
preclude any flexibility. -- Andrei


Well, I'm satisfied with my design in this respect, and 
completely lack motivation, time, emotional energy, etc. to 
rewrite `checkedint` again from the ground up to properly account 
for arbitrary pluggable error handling policies.


So, the community will have to decide how important this is, and 
find someone else to take over the project if you all demand a 
rewrite.

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Thursday, 16 June 2016 at 00:03:26 UTC, Andrei Alexandrescu 
wrote:

On 06/15/2016 07:34 PM, tsbockman wrote:
The whole point of `checkedint` is to be able to write 
algorithms based
on the simplifying assumption that your variables behave like 
real,
UNbounded mathematical integers, secure in the knowledge that 
an error

message will be generated if that assumption is invalidated.


Fair point, though one could make the same claim for integers 
within other limits than the machine's. -- Andrei


Sure. I'm just trying to explain my design goals and philosophy - 
not to argue that no other approach could be valid.


But, I would appreciate it if comments distinguished between:

1) My goals and philosophy differ from yours, versus
2) My implementation is bad.

I think a lot of the high-level criticism you brought is really 
rooted in (1), even though you present it as (2).

Re: std.experimental.checkedint is ready for comments!

[Andrei Alexandrescu via Digitalmars-d]

On 06/15/2016 07:13 PM, tsbockman wrote:


Standardizing the error handling methods is also important for other
interoperability-related reasons:

 * If every third-party library designs a different error handling
method,
   people writing applications that depend on many libraries will
have to
   study the `checkedint` error signaling of each one, and make sure
that
   their code which interacts with each library knows how to detect and
   respond to its particular signaling mechanism.

   My design for `checkedint` reduces the number of
`checkedint`-specific
   signaling methods that need to be studied down to one (the sticky
flags
   policy). The other two policies are just using D's standard error-
   handling facilities, and don't require any user intervention anyway,
   unless you want to catch the exception for some reason.

   Even the sticky flags policy is only of concern for `nothrow
@nogc` APIs,
   which I suspect in practice will mostly mean game libraries.

 * The relative simplicity of my policy set has allowed me to
arrange them
   into a strict linear hierarchy, so that the results of mixing
policies
   is predictable and safe.


I don't agree with this. On the face of it, three built-in policies 
solve the matter of interoperability: if you want interop, use one of 
those. Done. But interop is not a reason to preclude any flexibility. -- 
Andrei

Re: std.experimental.checkedint is ready for comments!

[Andrei Alexandrescu via Digitalmars-d]

On 06/15/2016 07:34 PM, tsbockman wrote:

The whole point of `checkedint` is to be able to write algorithms based
on the simplifying assumption that your variables behave like real,
UNbounded mathematical integers, secure in the knowledge that an error
message will be generated if that assumption is invalidated.


Fair point, though one could make the same claim for integers within 
other limits than the machine's. -- Andrei

Re: Passing anonymous templated functions as template parameters

[Basile B. via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 22:27:38 UTC, pineapple wrote:
Here's a simple code example to illustrate what I expected to 
work and didn't - is this a mistake in my syntax or a 
limitation of the language?


template SomeTemplate(alias func){
auto templatefunc(T)(int x){
return func!T(x);
}
}

// Valid
auto somefunc(T)(int x){
return cast(T) x;
}
alias fn1 = SomeTemplate!somefunc;

// Not valid
alias fn2 = SomeTemplate!(
(T)(int x){return cast(T) x;}
);


This syntax passes:

alias fn2(T) = SomeTemplate!((int x){return cast(T) x;});

Re: GTKD - Application crashes - or not? [Coedit]

[Basile B. via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 17:35:32 UTC, TheDGuy wrote:
On Wednesday, 15 June 2016 at 13:15:56 UTC, Rene Zwanenburg 
wrote:
I'm not familiar with Coedit, but the run options seem to 
contain a field for setting it:

https://github.com/BBasile/Coedit/wiki#run-options

You may be able to use the symbolic strings there:
https://github.com/BBasile/Coedit/wiki#symbolic-strings


I changed the working directory in the native project 
configuration in "Pre-build process", "Post-build process" and 
in "Run options" in "default", "debug" and "release" to:


You just need to change "CurrentDirectory" in the "Run options". 
The two others are for the process that's executed before and 
after compiling.


I'm gonna check on Windows today but in the meantime you can try

- sets the output path to to a value that's different from the 
project file location, e.g bin/name.exe and remove completly the 
value you've set in "Run Options"\"CurrentDirectory"
- add a trailing back slash to the value in the "Run 
Options"\"CurrentDirectory"

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Wednesday, 15 June 2016 at 16:40:19 UTC, Andrei Alexandrescu 
wrote:
One of the first things I looked for was establishing bounds 
for numbers, like Smart!(int, 0, 100) for percentage. For all 
its might, this package does not offer this basic facility, and 
from what I can tell does not allow users to enforce it via 
policies.


Another angle on why `checkedint` does not currently include a 
bounded type: although some of the internals might be similar, 
conceptually a `BoundInt` type is actually the *opposite* of the 
ideal which `SmartInt` and `SafeInt` strive toward.


The problem which this package was written to solve, is that when 
programming people frequently want to use "integers" as a data 
type. A real "integer" is, by definition, UNbounded, with an 
infinite range of values available. This makes designing 
algorithms simpler, but of course leads to problems when a value 
strays outside the narrow range in which the behaviour of machine 
integers correctly emulates that of mathematical integers.


The whole point of `checkedint` is to be able to write algorithms 
based on the simplifying assumption that your variables behave 
like real, UNbounded mathematical integers, secure in the 
knowledge that an error message will be generated if that 
assumption is invalidated.


Intentionally limiting values to a specific range is a different 
problem, and never the one that I was trying to solve - although 
I agree that the `checkedint` package would be a good namespace 
in which to park a `BoundInt` type, if someone wants to submit 
one.

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Wednesday, 15 June 2016 at 18:34:15 UTC, tsbockman wrote:
On Wednesday, 15 June 2016 at 16:40:19 UTC, Andrei Alexandrescu 
wrote:
Getting to the design: the root of the problem is a byzantine 
design that is closed to extension.


The design was closed deliberately because of (8). Template 
bloat is a major concern, even with the current finite design.


I want `checkedint` to be usable in public APIs, and that 
requires some standardization of error handling and base types 
to be enforced upon the users. Otherwise, everyone will choose 
something different and all template instantiations involving 
integer types will become practically single-use.


Looking at the IntFlagPolicy, it offers three canned behavior: 
throws, asserts, and noex.


The choice of policies is motivated by the natural 
incompatibility of (2), (4), (6), and (7). I built in enough 
variety to allow people to choose their own priorities among 
those goals, and no more because of (8).


Re-reading what I wrote there, I makes it sound like the closed 
design was motivated solely by template bloat concerns. But, 
that's not true either.


Standardizing the error handling methods is also important for 
other interoperability-related reasons:


* If every third-party library designs a different error 
handling method,
  people writing applications that depend on many libraries 
will have to
  study the `checkedint` error signaling of each one, and 
make sure that
  their code which interacts with each library knows how to 
detect and

  respond to its particular signaling mechanism.

  My design for `checkedint` reduces the number of 
`checkedint`-specific
  signaling methods that need to be studied down to one (the 
sticky flags
  policy). The other two policies are just using D's standard 
error-
  handling facilities, and don't require any user 
intervention anyway,

  unless you want to catch the exception for some reason.

  Even the sticky flags policy is only of concern for 
`nothrow @nogc` APIs,

  which I suspect in practice will mostly mean game libraries.

* The relative simplicity of my policy set has allowed me to 
arrange them
  into a strict linear hierarchy, so that the results of 
mixing policies

  is predictable and safe.

Re: GTKD - overrideBackgroundColor of Button doesn't work

[Gerald via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 21:39:37 UTC, TheDGuy wrote:

On Wednesday, 15 June 2016 at 20:49:02 UTC, Gerald wrote:

On Wednesday, 15 June 2016 at 09:03:45 UTC, TheDGuy wrote:

Hello,
why does this code not work?

RGBA rgb = new RGBA(1,0.5,0.5,1.0);
Button btn_1 = new Button("Start");
btn_1.overrideBackgroundColor(StateFlags.NORMAL, rgb);

The color of btn_1 just doesn't change.


https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-override-background-color




snip...

The text color is green but the button background color is 
still default-gray!


I don't see an obvious issue with your code, I usually use CSS 
classes personally and I know that works fine because I use this 
technique all over terminix. I would suggest using the GTK 
Inspector to debug the CSS issue, it's an awesome tool for 
figuring out GTK CSS issues as it let's you change CSS on the 
fly, see what CSS is being applied to an object, etc. You can see 
how to use it at the link below:


https://wiki.gnome.org/Projects/GTK%2B/Inspector


I am also wondering how it is possible to change the button 
color at runtime? In my opinion i don't think that CSS-based 
style has alot of advantages over the commonly used object 
functions.


Personally I just add and remove classes as needed:

getStyleContext().addClass()
getStyleContext().removeClass()

Passing anonymous templated functions as template parameters

[pineapple via Digitalmars-d-learn]

Here's a simple code example to illustrate what I expected to 
work and didn't - is this a mistake in my syntax or a limitation 
of the language?


template SomeTemplate(alias func){
auto templatefunc(T)(int x){
return func!T(x);
}
}

// Valid
auto somefunc(T)(int x){
return cast(T) x;
}
alias fn1 = SomeTemplate!somefunc;

// Not valid
alias fn2 = SomeTemplate!(
(T)(int x){return cast(T) x;}
);

Re: get number of columns and rows in an ndarray.

[learner via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 21:54:22 UTC, Seb wrote:

On Wednesday, 15 June 2016 at 21:51:25 UTC, learner wrote:

Hi,

How can i get the number of cols and rows in and ndarray that 
has already been created?


learner


how about `shape`?

http://dlang.org/phobos/std_experimental_ndslice_slice.html#.Slice.shape


Thanks

Re: GTKD - overrideBackgroundColor of Button doesn't work

[captaindet via Digitalmars-d-learn]

 string cssPath = "test.css";

 CssProvider provider = new CssProvider();
 provider.loadFromPath(cssPath);


unfortunately i don't know anything about yr specific problem.

but i just wanted to mention (in case you are not aware of it) that the 
CSS can be embedded into the D source. this is what i did to fix GTKs 
terrible design mistake for the background of Notebook:


```
enum myCSS = q{
GtkNotebook {
background-color: #e9e9e9;
}
GtkNotebook tab {
background-color: #d6d6d6;
}
};
...
int main(string[] args){
...
import gtk.CssProvider;
auto styleProvider = new CssProvider;
styleProvider.loadFromData(myCSS);
import gdk.Screen;
import gtk.StyleContext;
StyleContext.addProviderForScreen( Screen.getDefault(), 
styleProvider, 800);

```

Re: Work in Amsterdam

[Andrei Alexandrescu via Digitalmars-d-announce]

On 06/15/2016 04:44 PM, Jack Stouffer wrote:

On Wednesday, 15 June 2016 at 19:48:07 UTC, Dejan Lekic wrote:

LinkedIn has the D Developer Network (DDN) group with 1900 members (at
the moment of writing this post): https://www.linkedin.com/groups/3923820


I didn't know about this either. You should make a separate announce
post about this.


Should be accessible from the website and wiki. -- Andrei

Re: The Problem With DIPs

[Ola Fosheim Grøstad via Digitalmars-d]

On Wednesday, 15 June 2016 at 20:50:25 UTC, deadalnix wrote:
Consider that there are many optimizations that rely on fp not 
being predictable. For instance, fabs(x) can be transformed 
into x | 0x8000 if you don't care about NaN's sign (yes, 
NaN are signed).


I guess that would be "-fabs(x)"? NaNs are signed, 
quiet/signalling and may carry an id. Floating point would truly 
benefit from a more constraint based typing system, but not sure 
how that would work out with D. (E.g. constraining a type to be 
non-Nan, non-Infinity, non-Zero etc subtype)


I am thinking that one should keep strict semantics and sloppy 
semantics separate in the type system. I am not a big fan of 
letting the compiler switches control it, so maybe float/double 
should work more like C/C++ or current D.


Then have other types for the strict semantics and allow direct 
bitmasking operations/simd. The overall solution could be 
restricted to a useful, but reproducible subset of 754-2008 
(avoiding trancendentals). Meaning, you would have to cast to 
double/float to get non-reproducible behaviour.


Then you can have implicit transition from strict->sloppy, but 
require explicit casting the other way.


For the strict type the rounding mode probably should be part of 
the type, enabling interval arithmetics and avoiding the "dynamic 
typing issues" of run-time rounding mode. Interval arithmetics is 
something that is hard to get right with the main C/C++ compilers.

Re: get number of columns and rows in an ndarray.

[Seb via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 21:51:25 UTC, learner wrote:

Hi,

How can i get the number of cols and rows in and ndarray that 
has already been created?


learner


how about `shape`?

http://dlang.org/phobos/std_experimental_ndslice_slice.html#.Slice.shape

get number of columns and rows in an ndarray.

[learner via Digitalmars-d-learn]

Hi,

How can i get the number of cols and rows in and ndarray that has 
already been created?


learner

Re: Garbage Collector

[rikki cattermole via Digitalmars-d]

On 16/06/2016 6:53 AM, Konstantin wrote:

On Wednesday, 15 June 2016 at 17:02:11 UTC, rikki cattermole wrote:


Higher level languages like Java have the benefit of using pools and
optimizing for this usage pattern, D does and will never have this.

Why don't you want the same for D?


Because we don't need them.
Sprinkling of fairy dust is for stories, not reality.


Well if you really insist to have a String class don't be too
surprised for some reason it doesn't have the same performance to say
Java.

Some areas, like compiling, or producing HTML/XML/JSON documents,
manipulate strings a lot.
Other areas, like GUI editors for sufficiently complex documents, or
level editors for videogame, need to efficiently manipulate huge trees
of assorted small objects, not necessarily strings.


You're quite right and that is why we have a GC to begin with.
Its also part of the reason why std.experimental.allocator will allow 
you to create an allocator that is able to handle such work load and 
then free when complete.



Aka don't go around creating/destroying classes a huge amount unless
you have rolled some form of memory management policy such as
reserving memory for the GC to use.

Yeah, that’s what I regularly do in C++ when I need to efficiently
create/destroys many small objects. Sure, this typically leads to the
best performance, e.g. because I can make the memory layout as cache
friendly as humanly possible.
But not all projects need that. And even for very performance demanding
apps, not all components of the app need that.
For such cases, a good GC (that just works well out of the box like
.NET's GC does) can reduce development costs significantly.


So exactly like what our GC does do. Unless you're doing real time 
development in any form (e.g. sound) you won't need to do much to work 
around the GC.

Re: std.experimental.checkedint is ready for comments!

[Andrei Alexandrescu via Digitalmars-d]

On 06/15/2016 05:32 PM, Timon Gehr wrote:

On 15.06.2016 18:40, Andrei Alexandrescu wrote:


The only remaining matter is to implement a few preexisting policies
(Hook implementations) to implement typical choices (such as the ones
present today), and the core algorithms for doing bounded operations.
The most interesting algorithms are for computing the bounds of
operations such as |, &, and ^. The D compiler needs those as well, and
currently implements them incorrectly. I have these in my mind and I can
help with those.


https://github.com/tgehr/d-compiler/blob/master/vrange.d#L338


Nice! On first glance (number of steps :o)) these looks like what I had 
in mind. Any chance you could make PRs for integrating these into the 
compiler? Thanks! -- Andrei

Re: GTKD - overrideBackgroundColor of Button doesn't work

[TheDGuy via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 20:49:02 UTC, Gerald wrote:

On Wednesday, 15 June 2016 at 09:03:45 UTC, TheDGuy wrote:

Hello,
why does this code not work?

RGBA rgb = new RGBA(1,0.5,0.5,1.0);
Button btn_1 = new Button("Start");
btn_1.overrideBackgroundColor(StateFlags.NORMAL, rgb);

The color of btn_1 just doesn't change.


https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-override-background-color


Thanks for your reply, i now tried to use CSS instead:

import std.stdio;
import std.file;
import gtk.Main;
import gtk.MainWindow;
import gtk.CssProvider;
import gtk.Button;
import gdk.Display;
import gdk.Screen;
import gtk.StyleContext;

class Window : MainWindow{
this(int width, int height, string title){
super(title);
setDefaultSize(width, height);
Button btn = new Button("Test");
btn.setName("CssName");

string cssPath = "test.css";

CssProvider provider = new CssProvider();
provider.loadFromPath(cssPath);

Display display = Display.getDefault();
Screen screen = display.getDefaultScreen();
StyleContext.addProviderForScreen(screen, provider, 
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);


add(btn);
showAll();
}
}

void main(string[] args){
writeln(getcwd());
Main.init(args);
auto win = new Window(250,250,"Tutorial");
Main.run();
}

This is my CSS:
GtkWindow{
background-color:blue;
}
#CssName{
-GtkWidget-focus-line-width:0;
background-color:green;
color:green;
}

The text color is green but the button background color is still 
default-gray!
I am also wondering how it is possible to change the button color 
at runtime? In my opinion i don't think that CSS-based style has 
alot of advantages over the commonly used object functions.

Re: std.experimental.checkedint is ready for comments!

[Timon Gehr via Digitalmars-d]

On 15.06.2016 18:40, Andrei Alexandrescu wrote:


The only remaining matter is to implement a few preexisting policies
(Hook implementations) to implement typical choices (such as the ones
present today), and the core algorithms for doing bounded operations.
The most interesting algorithms are for computing the bounds of
operations such as |, &, and ^. The D compiler needs those as well, and
currently implements them incorrectly. I have these in my mind and I can
help with those.


https://github.com/tgehr/d-compiler/blob/master/vrange.d#L338

Re: Accessing COM Objects

[Joerg Joergonson via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 19:21:51 UTC, John wrote:
On Wednesday, 15 June 2016 at 18:32:28 UTC, Joerg Joergonson 
wrote:

  import core.sys.windows.com, core.sys.windows.oaidl;


Thanks. Should these not be added to the generated file?


The problem is that other type libraries will probably require 
other headers to be imported, and there's no way to work out 
which, so I've left that up to the user for now.




Also, could you add to it the following:

const static GUID iid = 
Guid!("5DE90358-4D0B-4FA1-BA3E-C91BBA863F32");


inside the interface (Replace the string with the correct 
guid)?




This allows it to work with ComPtr which looks for the iid 
inside the interface, shouldn't hurt anything.


I could add that as an option.



In any case, I haven't got ComPtr to work so...


GUID Guid(string str)()
{
static assert(str.length==36, "Guid string must be 36 
chars long");
enum GUIDstring = "GUID(0x" ~ str[0..8] ~ ", 0x" ~ 
str[9..13] ~ ", 0x" ~ str[14..18] ~
", [0x" ~ str[19..21] ~ ", 0x" ~ str[21..23] ~ ", 0x" 
~ str[24..26] ~ ", 0x" ~ str[26..28]
~ ", 0x" ~ str[28..30] ~ ", 0x" ~ str[30..32] ~ ", 0x" 
~ str[32..34] ~ ", 0x" ~ str[34..36] ~ "])";

return mixin(GUIDstring);
}




also tried CoCreateInstance and getting error 80040154

Not sure if it works.



Changed the GUID to another one found in the registry(not the 
one at the top of the generated file) and it works. Both load 
photoshop


Oops. The one at the top of the file is the type library's ID, 
not the class ID. I should just omit it if it causes confusion.





int main(string[] argv)
{

//auto ps = ComPtr!_Application(CLSID_PS).require;

	//const auto CLSID_PS = 
Guid!("6DECC242-87EF-11cf-86B4-44455354"); // PS 90.1 
fails because of interface issue
	const auto CLSID_PS = 
Guid!("c09f153e-dff7-4eff-a570-af82c1a5a2a8");   // PS 90.0 
works.





auto hr = CoInitialize(null);
auto iid = IID__Application;


_Application* pUnk;

hr = CoCreateInstance(_PS, null, CLSCTX_ALL, , 
cast(void**));

if (FAILED(hr))
throw new Exception("ASDF");

}

The photoshop.d file
http://www.filedropper.com/photoshop_1


So, I guess it works but how to access the methods? The 
photoshop file looks to have them listed but they are all 
commented out.


They're commented out because Photoshop seems to have only 
provided a late-binding interface and you have to call them by 
name through IDispatch.Invoke. It's possible to wrap all that 
in normal D methods, and I'm working on it, but it won't be 
ready for a while.



Ok, I've tried things like uncommenting

Document Open(BSTR Document, VARIANT As, VARIANT AsSmartObject);
void Load(BSTR Document);

/*[id(0x70537673)]*/ BSTR get_ScriptingVersion();
  /*[id(0x70464D4D)]*/ double get_FreeMemory();
  /*[id(0x76657273)]*/ BSTR get_Version();
and everything crashes with bad reference.



If I try ComPtr, same thing



	const auto CLSID_PS = 
Guid!("c09f153e-dff7-4eff-a570-af82c1a5a2a8");   // PS 90.0 works.





auto hr = CoInitialize(null);
auto iid = IID__Application;

 	auto ps = 
cast(_Application)(ComPtr!_Application(CLSID_PS).require);


_Application pUnk;

hr = CoCreateInstance(_PS, null, CLSCTX_ALL, , 
cast(void**));

if (FAILED(hr))
throw new Exception("ASDF");

auto ptr = cast(wchar*)alloca(wchar.sizeof * 1000);

auto fn = `ps.psd`;
for(auto i = 0; i < fn.length; i++)
{
ptr[i] = fn[i];
}

writeln(ps.get_FreeMemory());

pUnk.Load(ptr);



My thinking is that CoCreateinstance is suppose to give us a 
pointer to the interface so we can use it, if all this stuff is 
crashing does that mean the interface is invalid or not being 
assigned properly or is there far more to it than this?




(

Re: Debugging D in windows

[moe via Digitalmars-d-debugger]

Thanks for the info! I will try it tomorrow, when I have some 
time and give some feedback then.

Re: The Problem With DIPs

[deadalnix via Digitalmars-d]

On Wednesday, 15 June 2016 at 08:24:23 UTC, Ola Fosheim Grøstad 
wrote:

On Monday, 13 June 2016 at 20:15:09 UTC, Walter Bright wrote:

On 6/13/2016 3:33 AM, Ola Fosheim Grøstad wrote:
But would it really have an effect if I wrote a DIP on 
getting predictable
floating point behaviour? If there is a chance that it would, 
then I might

consider it :-).


I encourage you to consider it.


Ok, I am considering it. ;-)

I also don't think there is a problem in having DIPs that are 
in limbo. I prefer that over rejection, as most ideas often 
have something to them for others to build upon.


So it is better to just have some fields that lists how one DIP 
is related to another DIP (e.g. "replaced by", "related to", 
"depends on" etc).


Outright rejection probably just discourage people from 
contributing similar DIPs that would be good for the language.


Better with constructive qualitative comments which point out 
unresolved issues, which can lead to new improved DIPs.


Consider that there are many optimizations that rely on fp not 
being predictable. For instance, fabs(x) can be transformed into 
x | 0x8000 if you don't care about NaN's sign (yes, NaN are 
signed).

Re: GTKD - overrideBackgroundColor of Button doesn't work

[Gerald via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 09:03:45 UTC, TheDGuy wrote:

Hello,
why does this code not work?

RGBA rgb = new RGBA(1,0.5,0.5,1.0);
Button btn_1 = new Button("Start");
btn_1.overrideBackgroundColor(StateFlags.NORMAL, rgb);

The color of btn_1 just doesn't change.


https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-override-background-color

Re: Garbage Collector

[deadalnix via Digitalmars-d]

On Wednesday, 15 June 2016 at 20:22:21 UTC, Jack Stouffer wrote:

On Wednesday, 15 June 2016 at 19:39:59 UTC, Konstantin wrote:
Well I’m not sure about the 5% (MS says their write barrier 
overhead is comparable to the cost of a simple method call, 
namely 6.4ns: 
https://msdn.microsoft.com/en-us/library/ms973852.aspx), but 
yeah, there’s some tradeoff, for having a good GC.


Even 1% overhead is unacceptable. Again, it's not reasonable 
for a systems language to have people pay for things they're 
not using.


Write barriers will come to D over Walter's dead body.



Simple exercise. You have 100 000 servers. Your application 
suddenly become 1% slower. How angry is your CFO when he 
discovers how many new machines he needs to buy ?

Re: Work in Amsterdam

[Jack Stouffer via Digitalmars-d-announce]

On Wednesday, 15 June 2016 at 19:48:07 UTC, Dejan Lekic wrote:
LinkedIn has the D Developer Network (DDN) group with 1900 
members (at the moment of writing this post): 
https://www.linkedin.com/groups/3923820


I didn't know about this either. You should make a separate 
announce post about this.

Re: Areas of D usage

[jmh530 via Digitalmars-d]

On Wednesday, 15 June 2016 at 20:01:09 UTC, Seb wrote:


Thanks a lot for all your help!
The initial version is online now & please feel invited to 
improve upon this document:


http://dlang.org/areas-of-d-usage.html


Looks good to me!

Re: Work in Amsterdam

[Ali Çehreli via Digitalmars-d-announce]

On 06/15/2016 12:48 PM, Dejan Lekic wrote:

On Monday, 13 June 2016 at 22:45:15 UTC, Márcio Martins wrote:

Forgive me if this is not the best place for this sort of posts, but
we are looking for experienced developers willing to learn D to join
our development team in Amsterdam. We are a fast-growing travel
e-commerce startup focused on themed vacation packages.

You'll be part of our small and agile development team, working with
D/vibe.d on a daily basis, with the occasional javascript for the
client-side of things.

Learn more on https://www.linkedin.com/jobs2/view/140710158


LinkedIn has the D Developer Network (DDN) group with 1900 members (at
the moment of writing this post): https://www.linkedin.com/groups/3923820

I've posted a link to this job on the DDN's group job list few minutes ago.


I've just sent a request to join but I wasn't aware of it until I've 
read your message. How does one know about the existence of such groups?


Ali

Re: arr.ptr, @safe and void*

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/15/16 4:08 PM, Nick Treleaven wrote:

On Wednesday, 15 June 2016 at 17:35:49 UTC, Steven Schveighoffer wrote:

On 6/15/16 6:32 AM, Nick Treleaven wrote:


My question is: would returning void* instead really be unsafe, i.e. is
there a way of dereferencing it in safe code? (I'm not thinking about
holes in @safe, but ways by design).


Yes. If the meaning of this expression is different in @safe vs.
@system, then compiler inference can affect code drastically:

auto d = arr1.ptr - arr2.ptr;


I probably wasn't clear - I'm not suggesting .ptr returns void*, I agree
with you. But I don't get why arr.ptrValue can't be safe and return
void* instead of uintptr_t.


It could probably do this. Dereferencing a void * isn't valid, so it 
kind of has the same effect. However, there are many functions which 
take void * and do write to/read from the data pointing at it (e.g. 
memcpy). These aren't @safe, so they should be off-limits.


The original fix proposed by Walter was to return const(void)*. This 
probably would have been fine, Daniel objected to it, but he may have 
been thrown off by the comment in the code which said "Ok because the 
user will never dereference the pointer", hinting the user may have a 
choice to do so. Hard to tell.


But the nice thing about returning a non-pointer is that you can't 
accidentally use it in cases where your code is @system or @trusted. It 
states clearly "I only care about the location of this memory, not 
what's in it". There is some value in that.


-Steve

Re: Garbage Collector

[Jack Stouffer via Digitalmars-d]

On Wednesday, 15 June 2016 at 19:39:59 UTC, Konstantin wrote:
Well I’m not sure about the 5% (MS says their write barrier 
overhead is comparable to the cost of a simple method call, 
namely 6.4ns: 
https://msdn.microsoft.com/en-us/library/ms973852.aspx), but 
yeah, there’s some tradeoff, for having a good GC.


Even 1% overhead is unacceptable. Again, it's not reasonable for 
a systems language to have people pay for things they're not 
using.


Write barriers will come to D over Walter's dead body.

By the way, Go implemented those barriers in version 1.5 a year 
ago: https://blog.golang.org/go15gc


Go has no allocation strategies but the GC, so that point is moot.

Re: Articles/Doc repo on Official dlang github

[Steven Schveighoffer via Digitalmars-d]

On 6/15/16 3:34 PM, dewitt wrote:

On Wednesday, 15 June 2016 at 18:20:19 UTC, Steven Schveighoffer wrote:

On 6/15/16 1:51 PM, dewitt wrote:

I don't know if this has been asked before and I am too lazy to search.
Has anyone brought up the idea of adding a repo to the official dlang
project on github with Articles.  I know the website has a section but
think that a repo with md files might get more collaboration and result
in more useful articles.  I see with dotnet they have the


They are already on github:

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



Are you talking the dd files?  I am saying markdown that you can just
click in github and view.  If it is the dd files then that process,
although not hard if more tedious for collaborating than markdown that
can easily be viewed in my opinion.


The standard on the D website is that they should be in ddoc form. All I 
was saying is that you can use github to propose, comment on, or fix 
articles already. Yes, github isn't going to render it for you, but 
Vladimir's auto-tester will.



 Plus that consists of the entire
dlang site.  a separate repo would serve a specific purpose of holding
articles that people could view easily on github.


Or, we could put the articles in their own directory. The flat structure 
of the web site files is pretty difficult to navigate, I think.


-Steve

Re: Articles/Doc repo on Official dlang github

[Seb via Digitalmars-d]

On Wednesday, 15 June 2016 at 19:34:13 UTC, dewitt wrote:
On Wednesday, 15 June 2016 at 18:20:19 UTC, Steven 
Schveighoffer wrote:

On 6/15/16 1:51 PM, dewitt wrote:
I don't know if this has been asked before and I am too lazy 
to search.
Has anyone brought up the idea of adding a repo to the 
official dlang
project on github with Articles.  I know the website has a 
section but
think that a repo with md files might get more collaboration 
and result

in more useful articles.  I see with dotnet they have the


They are already on github:

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

-Steve


Are you talking the dd files?  I am saying markdown that you 
can just click in github and view.  If it is the dd files then 
that process, although not hard if more tedious for 
collaborating than markdown that can easily be viewed in my 
opinion.  Plus that consists of the entire dlang site.  a 
separate repo would serve a specific purpose of holding 
articles that people could view easily on github.  Plus I 
believe a PR for MD would be easy to view how the file would 
look in the PR itself.  Thats just my opinion.


A couple of points maybe are useful to you:

- We use the same approach for tour.dlang.org and since yesterday 
every chapter is a small markdown file that is just a button 
click away.
We already got people who want to contribute content that you 
could consider as an article, e.g. [2].


- In future D's DIPs will be written in Markdown (WIP at [3]).

- There is also awesome-d [4], which is just a big link 
collection, but also written in Markdown.


[1] http://tour.dlang.org/
[2] https://github.com/stonemaster/dlang-tour/pull/289
[3] https://github.com/Dicebot/DIPs
[4] https://github.com/zhaopuming/awesome-d

Re: arr.ptr, @safe and void*

[Nick Treleaven via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 17:35:49 UTC, Steven Schveighoffer 
wrote:

On 6/15/16 6:32 AM, Nick Treleaven wrote:


My question is: would returning void* instead really be 
unsafe, i.e. is
there a way of dereferencing it in safe code? (I'm not 
thinking about

holes in @safe, but ways by design).


Yes. If the meaning of this expression is different in @safe 
vs. @system, then compiler inference can affect code 
drastically:


auto d = arr1.ptr - arr2.ptr;


I probably wasn't clear - I'm not suggesting .ptr returns void*, 
I agree with you. But I don't get why arr.ptrValue can't be safe 
and return void* instead of uintptr_t.


The PR I think you are referring to is mine: 
https://github.com/dlang/druntime/pull/1592


And this would be able to solve the problem, but I don't know 
if it's ready for prime time (proposed to be in core.internal).


I did see this, it's interesting. I suppose the advantage over 
ptrValue would be type safety.

Re: Garbage Collector

[deadalnix via Digitalmars-d]

On Wednesday, 15 June 2016 at 18:48:28 UTC, jmh530 wrote:
On Wednesday, 15 June 2016 at 18:28:42 UTC, Edwin van Leeuwen 
wrote:


I think he meant that the .NET GC (and most GC designs) rely 
on write barriers, but D does not have write barriers, since D 
is meant to be a proper systems language.


My reading of that LuaJIT GC document is that it requires write 
barriers, but that they are very cheap.


Problem is, in D, many people want to NOT use a GC, and this is 
something we want to support. These people also do NOT want to 
pay for write barrier they do not use.


That being said, we can do write barrier leveraging MMU on 
immutable (it'd be too expensive to do it on mutable data) during 
collection only, so that people that do not want to use the GC do 
not pay for it. The technique is used successfully in the ML 
family of languages for ages now with great results.


Generally, I think the right path forward for D's GC is not to 
emulate managed language's GC as this clearly won't be acceptable 
for many users. On the other hand,

we should:
1/ Leverage D's type system as to get infos about 
mutability/thread locality and segregate the heap accordingly/use 
adapted technique for each.
2/ Make sure the GC can deliver malloc grade performance in an 
alloc/free scenario, as to enable hybrid approach and allow 
people to rely on the GC to the extent they are willing to pay 
for. jemalloc internal datastructures are very amendable to build 
a GC.


I started using this approach in SDC's GC. The only thing 
preventing me to move faster here is simply the time I can 
allocate to solve that problem.

Re: Areas of D usage

[Seb via Digitalmars-d]

On Thursday, 2 June 2016 at 23:57:55 UTC, jmh530 wrote:

On Thursday, 2 June 2016 at 21:47:13 UTC, qznc wrote:

On Thursday, 2 June 2016 at 13:59:13 UTC, Seb wrote:
If I left out an area or you miss an application/usage - 
please let me know!


The Javascript JIT Compiler Higgs: 
https://github.com/higgsjs/Higgs


Vibe.d needs some examples. Looks like their website does not 
have any.


Wasn't too many clicks away to get to the tutorial on building 
a chat service.


Thanks a lot for all your help!
The initial version is online now & please feel invited to 
improve upon this document:


http://dlang.org/areas-of-d-usage.html

Re: Garbage Collector

[cym13 via Digitalmars-d]

On Wednesday, 15 June 2016 at 19:39:59 UTC, Konstantin wrote:

On Wednesday, 15 June 2016 at 18:23:52 UTC, Jack Stouffer wrote:

They're not acceptable for a systems programming language as 
they require you to pay for something that you might not use.


According to our resident GC maintainer (among many other 
things), they would cause a 1%-5% slow down in the language: 
https://github.com/dlang/druntime/pull/1081#issuecomment-69151660


Well I’m not sure about the 5% (MS says their write barrier 
overhead is comparable to the cost of a simple method call, 
namely 6.4ns: 
https://msdn.microsoft.com/en-us/library/ms973852.aspx), but 
yeah, there’s some tradeoff, for having a good GC.


By the way, Go implemented those barriers in version 1.5 a year 
ago: https://blog.golang.org/go15gc


May I point out that you do not seem to have any kind of 
experience
of D's GC? Try it and see for yourself wether it actually stops 
you
or not. It's right that not everyone is pleased with the current 
GC

but those users have specific expectations and I'm not certain at
all that they would find C# or Go's GC acceptable either.

The point is, D doesn't have to have a GC. Not using it is way 
easier

than in most other languages because all the tools to help you
profile it and avoid it are provided by the compiler. Go without a
good GC is a dead language. D without a good GC is just not as 
good

as it could be. And btw we're generally faster than Go ;-)

The point is: while a better GC is a work in progress we'll 
*never*
have a GC that can fit all needs, but it's not as critical as it 
is

in Go or in C# because we provide other ways to manage memory when
limitations arise.

Re: Parsing D Maybe Not Such a Good Idea <_<;

[deadalnix via Digitalmars-d]

On Wednesday, 15 June 2016 at 19:20:51 UTC, Dmitry Olshansky 
wrote:

Scanner can easily be non-regular.



Especially in that case, when the irregularity is as trivial as 
incrementing/decrementing a counter.

Re: Work in Amsterdam

[Dejan Lekic via Digitalmars-d-announce]

On Monday, 13 June 2016 at 22:45:15 UTC, Márcio Martins wrote:
Forgive me if this is not the best place for this sort of 
posts, but we are looking for experienced developers willing to 
learn D to join our development team in Amsterdam. We are a 
fast-growing travel e-commerce startup focused on themed 
vacation packages.


You'll be part of our small and agile development team, working 
with D/vibe.d on a daily basis, with the occasional javascript 
for the client-side of things.


Learn more on https://www.linkedin.com/jobs2/view/140710158


LinkedIn has the D Developer Network (DDN) group with 1900 
members (at the moment of writing this post): 
https://www.linkedin.com/groups/3923820


I've posted a link to this job on the DDN's group job list few 
minutes ago.

Re: Garbage Collector

[Konstantin via Digitalmars-d]

On Wednesday, 15 June 2016 at 18:23:52 UTC, Jack Stouffer wrote:

They're not acceptable for a systems programming language as 
they require you to pay for something that you might not use.


According to our resident GC maintainer (among many other 
things), they would cause a 1%-5% slow down in the language: 
https://github.com/dlang/druntime/pull/1081#issuecomment-69151660


Well I’m not sure about the 5% (MS says their write barrier 
overhead is comparable to the cost of a simple method call, 
namely 6.4ns: 
https://msdn.microsoft.com/en-us/library/ms973852.aspx), but 
yeah, there’s some tradeoff, for having a good GC.


By the way, Go implemented those barriers in version 1.5 a year 
ago: https://blog.golang.org/go15gc

Re: Articles/Doc repo on Official dlang github

[dewitt via Digitalmars-d]

On Wednesday, 15 June 2016 at 18:20:19 UTC, Steven Schveighoffer 
wrote:

On 6/15/16 1:51 PM, dewitt wrote:
I don't know if this has been asked before and I am too lazy 
to search.
Has anyone brought up the idea of adding a repo to the 
official dlang
project on github with Articles.  I know the website has a 
section but
think that a repo with md files might get more collaboration 
and result

in more useful articles.  I see with dotnet they have the


They are already on github:

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

-Steve


Are you talking the dd files?  I am saying markdown that you can 
just click in github and view.  If it is the dd files then that 
process, although not hard if more tedious for collaborating than 
markdown that can easily be viewed in my opinion.  Plus that 
consists of the entire dlang site.  a separate repo would serve a 
specific purpose of holding articles that people could view 
easily on github.  Plus I believe a PR for MD would be easy to 
view how the file would look in the PR itself.  Thats just my 
opinion.

Re: Accessing COM Objects

[John via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 18:35:42 UTC, Joerg Joergonson 
wrote:

On Wednesday, 15 June 2016 at 06:09:33 UTC, thedeemon wrote:

On Monday, 13 June 2016 at 17:38:41 UTC, Incognito wrote:


[...]


There are ready tools idl2d:
https://github.com/dlang/visuald/tree/master/c2d

[...]


I can't seem to get ComPtr to work.


auto ps = ComPtr!_Application(CLSID_PS).require;

Where CLSID_PS is the Guid from the registry that seems to work 
with CoCreate. _Application was generated from tbl2d.



See my other post for a more(not much) complete description of 
the issues files.


Ensure you are calling CoInitialize before anything else.

Re: Accessing COM Objects

[John via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 18:32:28 UTC, Joerg Joergonson 
wrote:

  import core.sys.windows.com, core.sys.windows.oaidl;


Thanks. Should these not be added to the generated file?


The problem is that other type libraries will probably require 
other headers to be imported, and there's no way to work out 
which, so I've left that up to the user for now.




Also, could you add to it the following:

const static GUID iid = 
Guid!("5DE90358-4D0B-4FA1-BA3E-C91BBA863F32");


inside the interface (Replace the string with the correct guid)?



This allows it to work with ComPtr which looks for the iid 
inside the interface, shouldn't hurt anything.


I could add that as an option.



In any case, I haven't got ComPtr to work so...


GUID Guid(string str)()
{
static assert(str.length==36, "Guid string must be 36 chars 
long");
enum GUIDstring = "GUID(0x" ~ str[0..8] ~ ", 0x" ~ 
str[9..13] ~ ", 0x" ~ str[14..18] ~
", [0x" ~ str[19..21] ~ ", 0x" ~ str[21..23] ~ ", 0x" ~ 
str[24..26] ~ ", 0x" ~ str[26..28]
~ ", 0x" ~ str[28..30] ~ ", 0x" ~ str[30..32] ~ ", 0x" 
~ str[32..34] ~ ", 0x" ~ str[34..36] ~ "])";

return mixin(GUIDstring);
}




also tried CoCreateInstance and getting error 80040154

Not sure if it works.



Changed the GUID to another one found in the registry(not the 
one at the top of the generated file) and it works. Both load 
photoshop


Oops. The one at the top of the file is the type library's ID, 
not the class ID. I should just omit it if it causes confusion.





int main(string[] argv)
{

//auto ps = ComPtr!_Application(CLSID_PS).require;

	//const auto CLSID_PS = 
Guid!("6DECC242-87EF-11cf-86B4-44455354"); // PS 90.1 fails 
because of interface issue
	const auto CLSID_PS = 
Guid!("c09f153e-dff7-4eff-a570-af82c1a5a2a8");   // PS 90.0 
works.





auto hr = CoInitialize(null);
auto iid = IID__Application;


_Application* pUnk;

hr = CoCreateInstance(_PS, null, CLSCTX_ALL, , 
cast(void**));

if (FAILED(hr))
throw new Exception("ASDF");

}

The photoshop.d file
http://www.filedropper.com/photoshop_1


So, I guess it works but how to access the methods? The 
photoshop file looks to have them listed but they are all 
commented out.


They're commented out because Photoshop seems to have only 
provided a late-binding interface and you have to call them by 
name through IDispatch.Invoke. It's possible to wrap all that in 
normal D methods, and I'm working on it, but it won't be ready 
for a while.

Re: Parsing D Maybe Not Such a Good Idea <_<;

[Dmitry Olshansky via Digitalmars-d]

On 15-Jun-2016 12:37, Shachar Shemesh wrote:

On 15/06/16 08:27, H. S. Teoh via Digitalmars-d wrote:

IMHO, you're thinking about this at the wrong level of abstraction.


I tend to agree.



The first order of business, before you even think about parsing, should
be to tokenize (or lex) the input. This is the stage where you break up
the input into atomic chunks: keywords, parentheses, commas,
identifiers, etc.. Comments can simply be scanned once and discarded.


No. The lexer is, typically, a regular language. /+ +/ comments are not
parsable using a regular language.



Scanner can easily be non-regular.


Shachar



--
Dmitry Olshansky

Re: Garbage Collector

[ketmar via Digitalmars-d]

On Wednesday, 15 June 2016 at 18:48:28 UTC, jmh530 wrote:
My reading of that LuaJIT GC document is that it requires write 
barriers, but that they are very cheap.


...for language that was originally VM-based. yet they'll have a 
noticable impact on language like D -- especially when programmer 
want to opt-out GC.

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Wednesday, 15 June 2016 at 18:50:32 UTC, tsbockman wrote:
What you are proposing is *not* "fixing" my design - it is 
basically scrapping it and replacing it with a ground-up 
rewrite, with perhaps some bits and pieces and general 
inspiration taken from my work.

[...]
If the decision is made to accept the high-level design, then 
we can go back to bikeshedding about names, fixing typos, 
tweaking/trimming the API, etc.


I should mention that one possible "trimming" would be to remove 
either `SmartInt`/`smartOp` or `SafeInt`/`safeOp`. I don't *want* 
to do this, obviously, but I wouldn't categorize it as "scrapping 
the design", either.

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Wednesday, 15 June 2016 at 16:40:19 UTC, Andrei Alexandrescu 
wrote:
I think there are a few considerable issues with the proposal, 
but also that all are fixable.


I already sent a much longer message detailing some of the 
reasons why I believe my design is sensible. But, before we 
continue this discussion much further, I need to stop and make 
one thing clear:


What you are proposing is *not* "fixing" my design - it is 
basically scrapping it and replacing it with a ground-up rewrite, 
with perhaps some bits and pieces and general inspiration taken 
from my work.


I'm OK with the community rejecting my design if that's what 
people really want to do, but I will not be implementing your 
proposal myself. I will simply leave `checkedint` on DUB, and 
move on with my life.


So, I'm putting out a general call now for the community to 
download the DUB package, try actually *using* it for something, 
and speak up as to whether the design seems good, or not.


If the decision is made to accept the high-level design, then we 
can go back to bikeshedding about names, fixing typos, 
tweaking/trimming the API, etc.

Re: Garbage Collector

[Konstantin via Digitalmars-d]

On Wednesday, 15 June 2016 at 17:02:11 UTC, rikki cattermole 
wrote:


Higher level languages like Java have the benefit of using 
pools and optimizing for this usage pattern, D does and will 
never have this.

Why don't you want the same for D?

Well if you really insist to have a String class don't be too 
surprised for some reason it doesn't have the same performance 
to say Java.
Some areas, like compiling, or producing HTML/XML/JSON documents, 
manipulate strings a lot.
Other areas, like GUI editors for sufficiently complex documents, 
or level editors for videogame, need to efficiently manipulate 
huge trees of assorted small objects, not necessarily strings.


Aka don't go around creating/destroying classes a huge amount 
unless you have rolled some form of memory management policy 
such as reserving memory for the GC to use.
Yeah, that’s what I regularly do in C++ when I need to 
efficiently create/destroys many small objects. Sure, this 
typically leads to the best performance, e.g. because I can make 
the memory layout as cache friendly as humanly possible.
But not all projects need that. And even for very performance 
demanding apps, not all components of the app need that.
For such cases, a good GC (that just works well out of the box 
like .NET's GC does) can reduce development costs significantly.

Re: Garbage Collector

[jmh530 via Digitalmars-d]

On Wednesday, 15 June 2016 at 18:28:42 UTC, Edwin van Leeuwen 
wrote:


I think he meant that the .NET GC (and most GC designs) rely on 
write barriers, but D does not have write barriers, since D is 
meant to be a proper systems language.


My reading of that LuaJIT GC document is that it requires write 
barriers, but that they are very cheap.

Re: std.experimental.checkedint is ready for comments!

[Andrei Alexandrescu via Digitalmars-d]

On 06/15/2016 02:26 PM, Walter Bright wrote:

On 6/15/2016 9:40 AM, Andrei Alexandrescu wrote:

Looking at the IntFlagPolicy, it offers three canned behavior: throws,
asserts,
and noex. Users cannot customize behavior and there is no information
passed
into the policy (e.g. the operands in case of overflow, or the
numerator in case
of division by zero). Passing the appropriate information would make
it possible
to implement various policies, e.g. the policy cannot say "I'm
actually okay
with this" or "here I'll implement a saturation policy".


Just a note to add to these excellent comments. One style of integer
arithmetic is "saturation" arithmetic, whereby if it overflows, instead
of an error it gets "stuck" at T.max. Same for underflow.

   https://en.wikipedia.org/wiki/Saturation_arithmetic

A good test for a policy API design is if saturation behavior could be
done with a user-defined policy, instead of it being a pre-defined one.


Also, the proposed design mentions "hysteresis" and allows Hook to 
introduce state. -- Andrei

Re: ndslice: convert a sliced object to T[]

[Ilya Yaroshenko via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 14:14:23 UTC, Seb wrote:

```
T[] a = slice.ptr[0.. slice.elementsCount];
```


This would work only for slices with continuous memory 
representation and positive strides. -- Ilya

Re: Button: A fast, correct, and elegantly simple build system.

[Atila Neves via Digitalmars-d-announce]

On Wednesday, 15 June 2016 at 15:39:47 UTC, Andrei Alexandrescu 
wrote:

On 06/15/2016 08:05 AM, John Colvin wrote:
On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright 
wrote:

On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote:

How about using reggae?

https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d


I haven't studied either.


If you do study that reggae file, remember that it's a 
deliberate
transliteration of the makefile and therefore is a lot more 
verbose than
it *could* be if done from a clean slate or as a proper 
translation.
IIRC it was done to show that reggae could do literally 
everything the

makefile does, in the same way.


Does it do -j? -- Andrei


Short answer: yes.

Long answer: it has multiple backends. I assume the one that'd be 
used for dmd/druntime/phobos would be the binary (compiled D 
code) one since that one doesn't have dependencies on anything 
else. It does what ninja does, which is to use the number of 
cores on the system. There are also the ninja, make and tup 
backends and those do what they do.


I've been meaning to update my reggae branch for a while but 
haven't been able to gather enough motivation. The part that just 
builds the library is easy (I haven't tried compiling the code 
below):


alias cObjs = objectFiles!(Sources!("etc/c/zlib"),
   Flags("-m64 -fPIC -O3"));
alias dObjs = objectFiles!(Sources!(["std", "etc"]),
   Flags("-conf= -m64 -w -dip25 -O 
-release"),

   ImportPaths("../druntime/import"));
auto static_phobos = 
link("$project/generated/linux/release/64/libphobos",

  cObjs ~ dObjs,
  "-lib");

The problem is all the other targets, and I can't break any of 
them, and they're all annoying in their own special way. The 
auto-tester only covers a fraction and I have no idea if all of 
them are still being used by anyone. Does anyone do MinGW builds 
with posix.mak for instance? I'm half convinced it's broken.


Atila

Re: Accessing COM Objects

[Joerg Joergonson via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 06:09:33 UTC, thedeemon wrote:

On Monday, 13 June 2016 at 17:38:41 UTC, Incognito wrote:


[...]


There are ready tools idl2d:
https://github.com/dlang/visuald/tree/master/c2d

[...]


I can't seem to get ComPtr to work.


auto ps = ComPtr!_Application(CLSID_PS).require;

Where CLSID_PS is the Guid from the registry that seems to work 
with CoCreate. _Application was generated from tbl2d.



See my other post for a more(not much) complete description of 
the issues files.

Re: Accessing COM Objects

[Joerg Joergonson via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 17:20:31 UTC, John wrote:
On Wednesday, 15 June 2016 at 16:45:39 UTC, Joerg Joergonson 
wrote:
Thanks. When I ran it I got a d file! when I tried to use that 
d file I get undefined IID and IDispatch. I imagine these 
interfaces come from somewhere, probably built in?


Any ideas?


Add the following after the module name:

  import core.sys.windows.com, core.sys.windows.oaidl;


Thanks. Should these not be added to the generated file?

Also, could you add to it the following:

const static GUID iid = 
Guid!("5DE90358-4D0B-4FA1-BA3E-C91BBA863F32");


inside the interface (Replace the string with the correct guid)?



This allows it to work with ComPtr which looks for the iid inside 
the interface, shouldn't hurt anything.


In any case, I haven't got ComPtr to work so...


GUID Guid(string str)()
{
static assert(str.length==36, "Guid string must be 36 chars 
long");
enum GUIDstring = "GUID(0x" ~ str[0..8] ~ ", 0x" ~ str[9..13] 
~ ", 0x" ~ str[14..18] ~
", [0x" ~ str[19..21] ~ ", 0x" ~ str[21..23] ~ ", 0x" ~ 
str[24..26] ~ ", 0x" ~ str[26..28]
~ ", 0x" ~ str[28..30] ~ ", 0x" ~ str[30..32] ~ ", 0x" ~ 
str[32..34] ~ ", 0x" ~ str[34..36] ~ "])";

return mixin(GUIDstring);
}




also tried CoCreateInstance and getting error 80040154

Not sure if it works.



Changed the GUID to another one found in the registry(not the one 
at the top of the generated file) and it works. Both load 
photoshop



int main(string[] argv)
{

//auto ps = ComPtr!_Application(CLSID_PS).require;

	//const auto CLSID_PS = 
Guid!("6DECC242-87EF-11cf-86B4-44455354"); // PS 90.1 fails 
because of interface issue
	const auto CLSID_PS = 
Guid!("c09f153e-dff7-4eff-a570-af82c1a5a2a8");   // PS 90.0 works.





auto hr = CoInitialize(null);
auto iid = IID__Application;


_Application* pUnk;

hr = CoCreateInstance(_PS, null, CLSCTX_ALL, , 
cast(void**));

if (FAILED(hr))
throw new Exception("ASDF");

}

The photoshop.d file
http://www.filedropper.com/photoshop_1


So, I guess it works but how to access the methods? The photoshop 
file looks to have them listed but they are all commented out.


I suppose this is what ComPtr and other methods are used to help 
create the interface but none seem to work.

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Wednesday, 15 June 2016 at 16:40:19 UTC, Andrei Alexandrescu 
wrote:

Thanks for this work.
[...]
I think there are a few considerable issues with the proposal, 
but also that all are fixable.


Your message was very long, so for the moment I'm going to filter 
it down to just the high-level design criticism. (The rest is 
unimportant unless/until we reach consensus on the design, 
anyway.)


* The opening documentation states this proposal is concerned 
with adding checking capabilities to integral types. It is a 
full-blown package with 6 modules totaling 4690 lines as wc 
counts. (For comparison: std.experimental.allocator, which 
offers many facilities and implements a number of difficult 
structures and algorithms, has 11831 lines.) That's a high 
budget and a high imposition on users for adding checks to 
integral types. Such extensive style of coding goes against the 
D style we want to promote.

[...]
The budget I'd  establish for this is one parameterized type in
one module of manageable size. Several parameterized types would
be okay if they characterize distinct abstractions and use the 
same backend. Anything else is an indication of a design run 
awry.


This can be summarized as, "It's too big and complicated."

`checkedint` as it stands is, I believe, fairly close to the 
smallest implementation possible in D today, within the 
constraints of the features demanded by the community in past 
discussions, coupled with my high-level design goals.


If you want something shorter or simpler, you will have to cut 
features or compromise the design in other ways. (Or improve the 
D language to facilitate a more elegant design.)


Some features and design goals that combine to motivate my design:

   1) Checked types must signal an error (somehow) whenever their 
behaviour

  deviates from that of an ideal mathematical integer.

   2) It should be possible to recover from errors - using 
`assert(false)` or
  a deliberate divide-by-zero to crash the program is bad 
design unless
  the condition that triggers it is never supposed to happen, 
ever.


   3) Performance (with respect to both speed and memory use) 
should be as
  close as possible to that of the built-in machine integer 
types.


   4) The API should minimize verbosity and ceremony, because 
otherwise hardly
  anyone will use it - people generally prefer convenience 
over safety.


   5) Writing generic code that works correctly with both checked 
and unchecked

  types must be easy.

   6) The API must make safe usage easy, and (accidental) unsafe 
usage hard,
  because people generally don't pay much attention to the 
docs (even if
  they're good). A false sense of security is worse than none 
at all.


   7) The API must be usable in `nothrow @nogc` code.

   8) The number of distinct template instantiations generated in 
natural use
  must be finite, to prevent excessive combinatorial 
explosion when
  checked types are used in public APIs. (Templates that are 
just aliases,
  and small functions that always inline don't count against 
this.)


Also it is worrisome that one type wasn't enough (in spite of 
extensive
parameterization with policies) and two are needed, with subtle 
differences

between them that need to be summarized in a table.


The reason for the `SmartInt` versus `SafeInt` split is that with 
D's current semantics

(4) and (5) conflict.

`SmartInt` prioritizes (4); `SafeInt` and `DebugInt` prioritize 
(5).


Getting to the design: the root of the problem is a byzantine 
design that is closed to extension.


The design was closed deliberately because of (8). Template bloat 
is a major concern, even with the current finite design.


I want `checkedint` to be usable in public APIs, and that 
requires some standardization of error handling and base types to 
be enforced upon the users. Otherwise, everyone will choose 
something different and all template instantiations involving 
integer types will become practically single-use.


Looking at the IntFlagPolicy, it offers three canned behavior: 
throws, asserts, and noex.


The choice of policies is motivated by the natural 
incompatibility of (2), (4), (6), and (7). I built in enough 
variety to allow people to choose their own priorities among 
those goals, and no more because of (8).


* One of the first things I looked for was establishing bounds 
for numbers, like Smart!(int, 0, 100) for percentage. For all 
its might, this package does not offer this basic facility, and 
from what I can tell does not allow users to enforce it via 
policies.


Here you are suggesting adding even more complexity to a design 
that you have already de-facto rejected as overly complex. As 
discussed earlier in this very thread, I studied adding support 
for arbitrary bounds and decided not to pursue that right now 
because implementing it in a performant way would greatly 
increase the complexity of `checkedint`, and make the template 
bloat 

Re: std.experimental.checkedint is ready for comments!

[Walter Bright via Digitalmars-d]

On 6/15/2016 9:40 AM, Andrei Alexandrescu wrote:

Looking at the IntFlagPolicy, it offers three canned behavior: throws, asserts,
and noex. Users cannot customize behavior and there is no information passed
into the policy (e.g. the operands in case of overflow, or the numerator in case
of division by zero). Passing the appropriate information would make it possible
to implement various policies, e.g. the policy cannot say "I'm actually okay
with this" or "here I'll implement a saturation policy".


Just a note to add to these excellent comments. One style of integer arithmetic 
is "saturation" arithmetic, whereby if it overflows, instead of an error it gets 
"stuck" at T.max. Same for underflow.


  https://en.wikipedia.org/wiki/Saturation_arithmetic

A good test for a policy API design is if saturation behavior could be done with 
a user-defined policy, instead of it being a pre-defined one.

Re: Garbage Collector

[Edwin van Leeuwen via Digitalmars-d]

On Wednesday, 15 June 2016 at 17:03:21 UTC, Konstantin wrote:

On Wednesday, 15 June 2016 at 13:56:09 UTC, Jack Stouffer wrote:
Has anyone thought about taking GC from .NET and reusing it 
in D?

Two words: write barriers.
What about them? You mean not all D’s target platforms support 
them?


I think he meant that the .NET GC (and most GC designs) rely on 
write barriers, but D does not have write barriers, since D is 
meant to be a proper systems language.

Re: Garbage Collector

[Jack Stouffer via Digitalmars-d]

On Wednesday, 15 June 2016 at 17:03:21 UTC, Konstantin wrote:

Two words: write barriers.


What about them? You mean not all D’s target platforms support 
them?


They're not acceptable for a systems programming language as they 
require you to pay for something that you might not use.


According to our resident GC maintainer (among many other 
things), they would cause a 1%-5% slow down in the language: 
https://github.com/dlang/druntime/pull/1081#issuecomment-69151660

Re: Articles/Doc repo on Official dlang github

[Steven Schveighoffer via Digitalmars-d]

On 6/15/16 1:51 PM, dewitt wrote:

I don't know if this has been asked before and I am too lazy to search.
Has anyone brought up the idea of adding a repo to the official dlang
project on github with Articles.  I know the website has a section but
think that a repo with md files might get more collaboration and result
in more useful articles.  I see with dotnet they have the


They are already on github:

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

-Steve

Re: size_t vs uintptr_t

[Walter Bright via Digitalmars-d]

On 6/15/2016 9:31 AM, Steven Schveighoffer wrote:

I think you guys are missing the point.

I can check for 64-bit alignment by casting to ubyte:

((cast(ubyte)ptr) & 0x07) == 0

Walter: I don't see why the optimizer doesn't figure out the fastest way to do
this, even with size_t. You are logic-anding a constant.


You're right.

[Issue 10524] Switch skips initialization of 'with' variable

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||pull
 CC||bugzi...@digitalmars.com

--- Comment #4 from Walter Bright  ---
https://github.com/dlang/dmd/pull/5869

--

[Issue 14532] switch block allows creating uninitialized variables

[via Digitalmars-d-bugs]

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

Walter Bright  changed:

   What|Removed |Added

   Keywords||pull

--- Comment #2 from Walter Bright  ---
https://github.com/dlang/dmd/pull/5869

--

Articles/Doc repo on Official dlang github

[dewitt via Digitalmars-d]

I don't know if this has been asked before and I am too lazy to 
search.  Has anyone brought up the idea of adding a repo to the 
official dlang project on github with Articles.  I know the 
website has a section but think that a repo with md files might 
get more collaboration and result in more useful articles.  I see 
with dotnet they have the


https://github.com/dotnet/apireviews

repo that contains a lot of md files some useful and some not so 
much.  This is NOT a discussion about the website and peoples 
opinion as I have none due to not really looking into the process 
one way or another.  I am just wondering if a github repo would 
give more visibility and allow for more collaboration and more 
information readily available?  Seems there could be more 
articles on say the Allocators or best practices for X,Y,Z and 
could be actively updated.


I guess one could argue the blog would be the place but I think 
the articles currently in the section and more being actively 
written may be good and Pull Request would allow a good review 
process for them?


No need for a huge discussion or OT on this but looking at this 
dotnet example not necessarily the structure of project but 
general idea may be useful and see more traffic.  At least I know 
I would find it convenient and easily searchable.

Debugging D in windows

[moe via Digitalmars-d-debugger]

Hi,

I am trying to debug in windows. So far I am trying to use windbg 
like described here: http://dlang.org/windbg.html


However, in windbg when using "g _Dmain" I get an error message: 
"No Debuggee specified". Can anybody tell me what I am missing 
here? I could not find anything online and I can not find any 
option to specify a debugger.


If you know about better ways to debug in windows, please let me 
know.

Release candidate 1.0.0-rc.1 is out

[Sönke Ludwig via Digitalmars-d-announce]

Am 07.06.2016 um 11:54 schrieb Sönke Ludwig:

DUB 1.0.0 is nearing completion. The new feature over 0.9.25 is support
for single-file packages, which can be used to write shebang-style
scripts on Posix systems:

 #!/usr/bin/env dub
 /+ dub.sdl:
 name "colortest"
 dependency "color" version="~>0.0.3"
 +/

 void main()
 {
 import std.stdio : writefln;
 import std.experimental.color.conv;
 import std.experimental.color.hsx;
 import std.experimental.color.rgb;

 auto yellow = RGB!("rgb", float)(1.0, 1.0, 0.0);
 writefln("Yellow in HSV: %s", yellow.convertColor!(HSV!()));
 }

With "chmod +x" it can then simply be run as ./colortest.d.

Apart from that, the release contains some bug fixes, most notably it
doesn't query the registry for each build any more.

Full change log:
https://github.com/D-Programming-Language/dub/blob/master/CHANGELOG.md

Download (Latest Preview):
http://code.dlang.org/download


The first release candidate is out now! If nothing else comes up, the 
release is scheduled for next Monday.


For this release, I've restricted the recipe comments to the /+ +/ style 
and to be the first thing in the file apart from the optional shebang 
line. This leaves all options open to relax the rules later without 
losing backwards compatibility and allows #872 [1] to be finished with 
less time pressure.


[1]: https://github.com/dlang/dub/pull/872

Re: GTKD - Application crashes - or not? [Coedit]

[TheDGuy via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 13:15:56 UTC, Rene Zwanenburg wrote:
I'm not familiar with Coedit, but the run options seem to 
contain a field for setting it:

https://github.com/BBasile/Coedit/wiki#run-options

You may be able to use the symbolic strings there:
https://github.com/BBasile/Coedit/wiki#symbolic-strings


I changed the working directory in the native project 
configuration in "Pre-build process", "Post-build process" and in 
"Run options" in "default", "debug" and "release" to:


C:\Users\Standardbenutzer\Documents\Dlang_Projects

but i still get:

glib.GException.GException@..\..\..\AppData\Roaming\dub\packages\gtk-d-3.3.1\gtk-d\src\glib\GException.d(40):
 Failed to import: No such file or directory

0x0045C39D
0x00402094
0x00402120
0x00403FC7
0x00403EC8
0x00402557
0x740F38F4 in BaseThreadInitThunk
0x76F85DE3 in RtlUnicodeStringToInteger
0x76F85DAE in RtlUnicodeStringToInteger
error: the process 
(C:\Users\Standardbenutzer\Documents\Dlang_Projects\GTKD_Test.exe) has returned the signal 1

Re: arr.ptr, @safe and void*

[Steven Schveighoffer via Digitalmars-d-learn]

On 6/15/16 6:32 AM, Nick Treleaven wrote:

Hi,
Walter's made a fix for arr[$..$].ptr being unsafe to dereference - .ptr
will be @system:
https://github.com/dlang/dmd/pull/5860

A referenced druntime pull mentioned having a safe wrapper for ..ptr
that allows comparison of the pointer value, but does not allow
dereference. The wrapper would return uintptr_t (an integer guaranteed
to be big enough to hold a pointer value).

My question is: would returning void* instead really be unsafe, i.e. is
there a way of dereferencing it in safe code? (I'm not thinking about
holes in @safe, but ways by design).


Yes. If the meaning of this expression is different in @safe vs. 
@system, then compiler inference can affect code drastically:


auto d = arr1.ptr - arr2.ptr;

The PR I think you are referring to is mine: 
https://github.com/dlang/druntime/pull/1592


And this would be able to solve the problem, but I don't know if it's 
ready for prime time (proposed to be in core.internal).


-Steve

Re: Accessing COM Objects

[John via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 16:45:39 UTC, Joerg Joergonson 
wrote:
Thanks. When I ran it I got a d file! when I tried to use that 
d file I get undefined IID and IDispatch. I imagine these 
interfaces come from somewhere, probably built in?


Any ideas?


Add the following after the module name:

  import core.sys.windows.com, core.sys.windows.oaidl;

Re: Garbage Collector

[Konstantin via Digitalmars-d]

On Wednesday, 15 June 2016 at 13:56:09 UTC, Jack Stouffer wrote:

One guy wrote the LuaJIT GC, which beat almost everyone else in 
performance when I last checked
“The current garbage collector is relatively slow compared to 
implementations for other language runtimes. It's not competitive 
with top-of-the-line GCs, especially for large workloads.“

https://github.com/LuaJIT/LuaJIT/issues/38

They have planned something for 3.0 that may or may not work:
http://wiki.luajit.org/New-Garbage-Collector
But that’s merely a design, AFAIK there’s no implementation. 
They’re still looking for a sponsor for that.


Has anyone thought about taking GC from .NET and reusing it in 
D?

Two words: write barriers.
What about them? You mean not all D’s target platforms support 
them?

Re: Garbage Collector

[rikki cattermole via Digitalmars-d]

On 16/06/2016 4:52 AM, Konstantin wrote:

On Wednesday, 15 June 2016 at 13:40:11 UTC, rikki cattermole wrote:


5. The requirements for our GC is quite intricate. I.e. you can't just
pop in one that doesn't understand about our Thread Local Storage (TLS)
and stuff.

D’s TLS that different from .NET's TLS?
https://msdn.microsoft.com/en-us/library/system.threadstaticattribute(v=vs.110).aspx


Yes it most definitely is.
We roll our own for platforms that do not support it.

There is an abstraction in druntime specifically to handle this problem.


I forgot to mention, good D code is not the same as a higher level
language like Java.
Here you don't have the automagick behavior of arrays. If you append
it will have a high cost. All allocations have a large cost. Instead
allocate in one large block which will of course be a whole lot faster
then small tiny ones.

You’re saying memory allocations in D are generally very expensive, but
that’s not a problem, because it already functions as designed?


No.
Memory allocations are /always/ expensive.

Higher level languages like Java have the benefit of using pools and 
optimizing for this usage pattern, D does and will never have this.


Keep in mind an allocation = usage of malloc + write to returned pointer.


So even if the GC is enabled, good D code won't cause too much slow
down unless you decide to write heavy OOP code.

I’ve been developing heavy OOP code in various languages (mostly C++,
but also C# and Objective-C) for decades already. OOP works very well
for me.


Well if you really insist to have a String class don't be too surprised 
for some reason it doesn't have the same performance to say Java.
Aka don't go around creating/destroying classes a huge amount unless you 
have rolled some form of memory management policy such as reserving 
memory for the GC to use.


We have other tools where OOP normally would be used such as templates, 
structs, function pointers and delegates.

Re: Accessing COM Objects

[Joerg Joergonson via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 15:12:06 UTC, thedeemon wrote:
On Wednesday, 15 June 2016 at 07:01:30 UTC, Joerg Joergonson 
wrote:



It  seems idl2d from VD is not easily compilable?


I don't remember problems with that, anyway here's the binary I 
used:

http://stuff.thedeemon.com/idl2d.exe


It crashes when I use it ;/

core.exception.UnicodeException@src\rt\util\utf.d(290): invalid 
UTF-8 sequence


tbl2d did work and gave me a d file but I need to figure out what 
IID and IDispatch are.

Re: Accessing COM Objects

[Joerg Joergonson via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 08:24:41 UTC, John wrote:

On Wednesday, 15 June 2016 at 08:21:06 UTC, John wrote:
OK, adding the return type to the signature should fix that. 
So:


  private static Parameter getParameters(MethodImpl method)


Sorry, I meant the getParameter methods should return be:

  private static Parameter[] getParameters(MethodImpl method)

and

  private static Parameter[] getParameters(MethodImpl method, 
out Parameter returnParameter, bool getReturnParameter)


Thanks. When I ran it I got a d file! when I tried to use that d 
file I get undefined IID and IDispatch. I imagine these 
interfaces come from somewhere, probably built in?


Any ideas?

Re: Garbage Collector

[Konstantin via Digitalmars-d]

On Wednesday, 15 June 2016 at 13:40:11 UTC, rikki cattermole 
wrote:


5. The requirements for our GC is quite intricate. I.e. you 
can't just
pop in one that doesn't understand about our Thread Local 
Storage (TLS)

and stuff.
D’s TLS that different from .NET's TLS? 
https://msdn.microsoft.com/en-us/library/system.threadstaticattribute(v=vs.110).aspx


I forgot to mention, good D code is not the same as a higher 
level language like Java.
Here you don't have the automagick behavior of arrays. If you 
append it will have a high cost. All allocations have a large 
cost. Instead allocate in one large block which will of course 
be a whole lot faster then small tiny ones.
You’re saying memory allocations in D are generally very 
expensive, but that’s not a problem, because it already functions 
as designed?


So even if the GC is enabled, good D code won't cause too much 
slow down unless you decide to write heavy OOP code.
I’ve been developing heavy OOP code in various languages (mostly 
C++, but also C# and Objective-C) for decades already. OOP works 
very well for me.

Re: Accessing COM Objects

[Joerg Joergonson via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 16:03:04 UTC, Jesse Phillips wrote:

On Monday, 13 June 2016 at 01:22:33 UTC, Incognito wrote:

[...]


There is also:
https://github.com/JesseKPhillips/Juno-Windows-Class-Library

It kind of provides similar highlevel options as the "Modern 
COM Programming in D."


But I don't use it and have only be somewhat keeping it alive 
(I had some hiccups in supporting 64bit), so I haven't been 
working to improve the simplicity of interfacing to COM objects.


It also includes definitions for accessing Windows COM objects 
which aren't needed when interfacing with your own or other COM 
objects. I'd like to have two libraries, Juno Library and Juno 
Windows Class Library.


I'll check it it out...

Re: Garbage Collector

[Konstantin via Digitalmars-d]

On Wednesday, 15 June 2016 at 13:27:47 UTC, jmh530 wrote:


Possible to disable.
I don’t want to: for the last couple years I’ve been developing 
50/50 C++/C#, and I admit I’m usually more productive using C#, 
one of the reasons of that is GC.


They've got a GSOC guy workin' on it now. I would hold off 
judgements until that effort is concluded.

OK let's see.

Re: std.experimental.checkedint is ready for comments!

[Andrei Alexandrescu via Digitalmars-d]

PR: https://github.com/dlang/phobos/pull/4407
DUB: http://code.dlang.org/packages/checkedint


Thanks for this work. Documentation can be seen here:

http://dtest.thecybershadow.net/artifact/website-7cc6e938154f90aa49fa6451a85b13e35ab2de99-1cfc1d833df5be7c570307da6f7bf5eb/web/phobos-prerelease/std_experimental_checkedint.html

I think there are a few considerable issues with the proposal, but also 
that all are fixable. Here are a few notes:


* The opening documentation states this proposal is concerned with 
adding checking capabilities to integral types. It is a full-blown 
package with 6 modules totaling 4690 lines as wc counts. (For 
comparison: std.experimental.allocator, which offers many facilities and 
implements a number of difficult structures and algorithms, has 11831 
lines.) That's a high budget and a high imposition on users for adding 
checks to integral types. Such extensive style of coding goes against 
the D style we want to promote. Also it is worrisome that one type 
wasn't enough (in spite of extensive parameterization with policies) and 
two are needed, with subtle differences between them that need to be 
summarized in a table. The budget I'd establish for this is one 
parameterized type in one module of manageable size. Several 
parameterized types would be okay if they characterize distinct 
abstractions and use the same backend. Anything else is an indication of 
a design run awry.


* std.experimental.checkedint says "Normally this module should not be 
imported directly." -> this doesn't bode well. I suspect that's also the 
case for std.experimental.checkedint.flags. Modules should be import units.


* Naming: "Safe" has a different meaning throughout D and Phobos. Using 
it here is liable to confuse.


* Naming: The name of a type ("Int") in a name is often a red flag, and 
indeed here it's redundant. One should be able to say Smart!int, not 
stutter SmartInt!int (or Checked!int or whatever). Also, this suggests 
that other types should be considered, how about Smart!bool and 
Smart!double?


* One of the first things I looked for was establishing bounds for 
numbers, like Smart!(int, 0, 100) for percentage. For all its might, 
this package does not offer this basic facility, and from what I can 
tell does not allow users to enforce it via policies.


* Naming: I have no idea what "N bscal;" means.

* Documentation suddenly mentions isFixedPoint without having discussed 
it. Does this package do something about fixed-point numbers?


* Not sure about the value of wrapping bsf, bsr, ilogb and probably 
others. Unlike overflow etc,. calling them with the appropriate values 
is trivial on the user side. A completeness argument could be made but 
all of these wrappers are weight of little value.


* Typos: "equiavlents"

* Documentation uses "you" in several places, colloquialism that should 
be avoided.


* The idea of a loose federation of smart operators that sanitize the 
result of usual arithmetic operators is valuable. The idea of using 
different imports for the same name depending on design is clever, but 
can be simplified. Define functions such as enforcedOp, assertedOp (you 
don't need "unary" and "binary", they can be overloads), and then:


import std.checkedint : smartOp = enforcedOp;
...
auto x = smartOp!"+"(a, b);

* Not sure why divPow2 is needed, why not some enforcedOp!"<<" etc. Same 
about pow, why not enforcedOp!"^^"?


* Getting to the design: the root of the problem is a byzantine design 
that is closed to extension. The current definition goes:


struct SafeInt(N, IntFlagPolicy _policy, Flag!"bitOps" bitOps = Yes.bitOps);

Looking at the IntFlagPolicy, it offers three canned behavior: throws, 
asserts, and noex. Users cannot customize behavior and there is no 
information passed into the policy (e.g. the operands in case of 
overflow, or the numerator in case of division by zero). Passing the 
appropriate information would make it possible to implement various 
policies, e.g. the policy cannot say "I'm actually okay with this" or 
"here I'll implement a saturation policy".


A better design would use the policy as a last-resort hook, allowing it 
to substitute its own answer for the result if it can't be computed 
safely. For example, consider addition:


bool overflow;
auto result = myAdd(payload, rhs.payload, overflow);
if (!overflow) return result;
return onOverflow(payload, rhs.payload);

The onOverflow function is a policy, which allows user code to exactly 
define what should happen (including all current policies). The same 
goes about all other hooks - multiplication, division, power etc. Each 
should be configurable.


* I see little value in free functions such as e.g. abs() because they 
are trivial one-liners. I understand the need for completeness, but it 
seems a good aspiration for consistency is being marred by a bunch of 
code pulp that really does nothing interesting. Probably not worth it.


===

This suggests a much 

Re: size_t vs uintptr_t

[Steven Schveighoffer via Digitalmars-d]

On 6/14/16 10:04 PM, deadalnix wrote:

On Tuesday, 14 June 2016 at 23:19:12 UTC, Walter Bright wrote:

On 6/14/2016 3:38 PM, Guillaume Boucher wrote:

Isn't it guaranteed that x.sizeof >= x.alignof?  (At least it is in C
and C++.)
So the alignment should be of type size_t and not of type uintptr_t.

Also in general cast(uint)ptr%alignment is wrong since alignment does
not need
to be 32 bit.  However, cast(size_t)ptr%alignment is be correct in
any case.


There is no conceivable case where alignment will be > 32 bits, nor
not being a power of 2.


There are many cases in which alignment in 64bits.

There is nothing that says that x.sizeof >= x.alignof must be respected,
but really, if you don't respect that, you are simply wasting space and
cache without getting any benefit (the purpose of alignment is to avoid
store/load across cache lines).


I think you guys are missing the point.

I can check for 64-bit alignment by casting to ubyte:

((cast(ubyte)ptr) & 0x07) == 0

Walter: I don't see why the optimizer doesn't figure out the fastest way 
to do this, even with size_t. You are logic-anding a constant.


-Steve

Re: ndslice: convert a sliced object to T[]

[data pulverizer via Digitalmars-d-learn]

On Wednesday, 15 June 2016 at 14:14:23 UTC, Seb wrote:

On Wednesday, 15 June 2016 at 13:13:05 UTC, data pulverizer

And where can I find more cool tricks like that?


Browse the source code and the unittests. Phobos is an amazing 
resource :)


Very true!
That's great many thanks!

Re: Accessing COM Objects

[Jesse Phillips via Digitalmars-d-learn]

On Monday, 13 June 2016 at 01:22:33 UTC, Incognito wrote:
I've been reading over D's com and can't find anything useful. 
It seems there are different ways:


http://www.lunesu.com/uploads/ModernCOMProgramminginD.pdf

which is of no help and requires an idl file, which I don't 
have.


Then theres this

http://wiki.dlang.org/COM_Programming


There is also:
https://github.com/JesseKPhillips/Juno-Windows-Class-Library

It kind of provides similar highlevel options as the "Modern COM 
Programming in D."


But I don't use it and have only be somewhat keeping it alive (I 
had some hiccups in supporting 64bit), so I haven't been working 
to improve the simplicity of interfacing to COM objects.


It also includes definitions for accessing Windows COM objects 
which aren't needed when interfacing with your own or other COM 
objects. I'd like to have two libraries, Juno Library and Juno 
Windows Class Library.

Re: Anybody still using the chm docs

[zabruk70 via Digitalmars-d]

On Wednesday, 15 June 2016 at 10:58:04 UTC, Martin Nowak wrote:
So I'm wondering if in 2016 someone really needs an offline 
copy of a website shipped with a binary release?


i use chm doc - it easy integrates with ide

Re: size_t vs uintptr_t

[Wyatt via Digitalmars-d]

On Tuesday, 14 June 2016 at 21:59:32 UTC, Walter Bright wrote:

Ok, I admit these are not likely to emerge.


Not in desktop, server, or modern mobile phones, but I think 
there are some embedded platforms that have this concern.  I know 
that's not a huge priority, but it's nice to be mindful of it.


-Wyatt

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Wednesday, 15 June 2016 at 07:17:56 UTC, Walter Bright wrote:

On 6/14/2016 11:16 PM, tsbockman wrote:
On Wednesday, 15 June 2016 at 00:16:12 UTC, Walter Bright 
wrote:

Remove all use of 'you' and 'your' from the documentation.


Done.


I hope you like the results, and are not doing it just because 
I asked.


Definitely the latter.  :-)

I have heard such rules before, and they seem silly to me, 
personally. But, it's not a big deal either way, so I changed it.

Re: Button: A fast, correct, and elegantly simple build system.

[Edwin van Leeuwen via Digitalmars-d-announce]

On Wednesday, 15 June 2016 at 15:39:47 UTC, Andrei Alexandrescu 
wrote:

On 06/15/2016 08:05 AM, John Colvin wrote:
On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright 
wrote:

On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote:

How about using reggae?

https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d


I haven't studied either.


If you do study that reggae file, remember that it's a 
deliberate
transliteration of the makefile and therefore is a lot more 
verbose than
it *could* be if done from a clean slate or as a proper 
translation.
IIRC it was done to show that reggae could do literally 
everything the

makefile does, in the same way.


Does it do -j? -- Andrei


It can work with multiple backends (make/tup/ninja), which all 
support -j. There is also a binary backend (creates an 
executable), not sure if that supports -j natively.

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Wednesday, 15 June 2016 at 07:16:18 UTC, Walter Bright wrote:

On 6/14/2016 9:48 PM, tsbockman wrote:

`Int`? `Base`?


'Integer' would work fine.


`BaseInt`?

`SmartInt!Integer` looks weird to me, because of the repetition. 
Also, if we're going to use a long name like that I think it 
should hint at the fact that the true base type of a checked 
integer type is always a basic type, not a custom type like 
`SmartInt` or `BigInt`.


Besides, the signature will be the actual type name, not the 
alias for it.


I'm not sure what you're getting at here?

I'm concerned about how stuff like this appears in the docs 
(which is the only place where the user will ever see this name). 
Obviously the docs must use the alias, since they are for the 
generic type, rather than a specific instantiation.


I have seen all of `S`, `F`, `G`, `X`, `R`, `C`, `A`, and `B` 
used as template
parameter names in Phobos. Often there is no particular 
significance to the
letter chosen, but the purpose of the parameter is obvious 
from the context,

anyway.


1. Each one should be evaluated on its own merits.
2. Style is not something cast in stone, we try to constant 
evolve better ways.


Obviously I don't think your way is better.  :-)

3. Bad practice in one case is not a rationale to use bad 
practice elsewhere :-)


But when a practice works out fine in one case, that *is* 
evidence that it is likely to work out in others.


4. You mentioned greppability - 'N' is as ungreppable as it 
gets!


Which is irrelevant, because `N`/`BaseIntegralType`/whatever will 
never appear in the user's code (but `bscal` will).


Using short template parameter names helps keep D's 
already-very-long signatures

from growing even longer than they already are.


The parameter names don't appear in the signature.


They appear in the docs. I'm talking about the docs, because 
that's the only place anyone outside the Phobos dev team will 
ever see the `N`/`Integer`/whatever name.


Again, this needs to be short for readability and usability. 
Normally it's not
needed at all, but when it is needed (like in the 
implementation of `SmartInt`

and `SafeInt`), it tends to be needed *a lot*.


Internal to the implementation does not require it to be short.


Keeping names that don't need to be long short(ish) makes it a 
lot easier for me to read code.


Also, in practice people usually choose convenience over safety. 
If writing an algorithm using `checkedint` instead of the basic 
integer types makes the algorithm twice as long, the vast 
majority of people simply won't use `checkedint`.


For me, there is no point to pursuing inclusion of `checkedint` 
in Phobos if doing so requires making the API so verbose that no 
one will want to use it. (Which is not to say that `.bscal` => 
`.integer` is such a problem.)

Re: Button: A fast, correct, and elegantly simple build system.

[Andrei Alexandrescu via Digitalmars-d-announce]

On 06/15/2016 08:05 AM, John Colvin wrote:

On Wednesday, 15 June 2016 at 11:47:00 UTC, Walter Bright wrote:

On 6/15/2016 4:07 AM, Edwin van Leeuwen wrote:

How about using reggae?

https://github.com/atilaneves/phobos/blob/reggae/reggaefile.d


I haven't studied either.


If you do study that reggae file, remember that it's a deliberate
transliteration of the makefile and therefore is a lot more verbose than
it *could* be if done from a clean slate or as a proper translation.
IIRC it was done to show that reggae could do literally everything the
makefile does, in the same way.


Does it do -j? -- Andrei

Re: std.experimental.checkedint is ready for comments!

[tsbockman via Digitalmars-d]

On Wednesday, 15 June 2016 at 07:08:22 UTC, Walter Bright wrote:

On 6/14/2016 9:57 PM, tsbockman wrote:

The intent is just as clear this way, and it's less verbose.


Ok. I'd just change the constraint to:

if (isIntegral!N || isCheckedint!N)

You can do the qualification machinations using a static if 
inside the template.


This was a deliberate design decision, which I do not think 
should be changed (although I will if you insist):


* With your signature, the user may wrongly expect SmartInt to
  support qualified `N`. My scheme encodes the fact that only 
unqualified

  types are *really* supported in the public signatures.

  (I should add an explanatory note about this in the docs, 
too.)


* Your scheme will make uglier and more verbose error 
messages and fully
  qualified type signatures, as `SmartInt` will become 
`SmartInt.SmartInt`
  or `SmartIntImpl`. This is confusing for users who are not 
familiar with
  the details of D's template system, and still annoying for 
the rest of us.


* Your scheme will also complicate the docs, as it will 
replace the top-level

  entry for `struct SmartInt` with a nested
  `template SmartInt` => `struct SmartInt` entry.