date:20160614


On Wednesday, 15 June 2016 at 03:45:39 UTC, Walter Bright wrote:

On 6/14/2016 8:23 PM, tsbockman wrote:

This is specified fully in the template constraints:
if (isIntegral!N && isUnqual!N)
if ((isIntegral!N && !isUnqual!N) || isCheckedint!N)

The second overload simply forwards to the first, after 
applying

BasicScalar!(Unqual!N).


Why would a checkedint be a base type for a checkedint?


Generic code (contrived, oversimplified example):

import checkedint.throws, checkedint.traits;

SmartInt!(typeof(A.init + B.init)) add(A, B)(const A a, const 
B b)

if (isIntegral!A && isIntegral!B)
{
SmartInt!A ma = a;
SmartInt!B mb = b;

return ma + mb;
}

Of course I could force the user to write `BasicScalar` 
everywhere - but why? The intent is just as clear this way, and 
it's less verbose.

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


On Wednesday, 15 June 2016 at 03:42:52 UTC, Walter Bright wrote:

On 6/14/2016 8:15 PM, tsbockman wrote:

Do I really need to give it some giant multi-word name?


Something better than 'N'.


`Int`? `Base`?

Whatever it is needs to be short; `BaseIntegralType` is *way* too 
long for this and would make many of the signatures painfully 
verbose.


Besides which, Phobos uses single-letter names for template 
parameter type names

all over the place.


Generally 'T' is used for 'any type'. 'N' has no corresponding 
significance.


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.


Using short template parameter names helps keep D's 
already-very-long signatures from growing even longer than they 
already are.


Greppability is inddeed a plus, but 'bscal' is needlessly 
uninformative. Note that publicly facing names should not be so.


`basic`? `base`?

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*.


The obvious choices - `value`, `val`, or `raw` - are out because 
of the shadowing problem.



I will work on the docs some more.


Thank you.



* SmartInt.toString(sink, fmt)
* SafeInt.toString(sink, fmt)
* checkedint.to()
* IntFlag.toString(sink, fmt)
* IntFlags.toString(sink, fmt)


I see no love for output ranges :-(


I will add support. Someone should update this wiki page with 
whatever the current best practice is:

http://wiki.dlang.org/Defining_custom_print_format_specifiers

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

2016-06-14 Thread cy via Digitalmars-d


On Wednesday, 15 June 2016 at 04:25:15 UTC, deadalnix wrote:
there is nothing in that example that is especially difficult 
for a machine to muddle through.


Nested comments, have to keep track of nesting depth specifically 
for those. Single line comments, which give newline two totally 
different semantics based on context, that the parser has to 
account for. Comments can go absolutely anywhere, so you can 
never advance by simply incrementing your character pointer, 
regardless of the statement you're parsing. You have to do a 
complex test for the presence of comments and pass over them, and 
if you want to do any backtracking, you have to be able to skip 
backwards over them.


Type definitions can have parentheses in them, so the parser 
can't search for '(' either forwards or backwards in order to 
find the beginning of a function definition. It has to analyze 
each parenthetical grouping in its own special context, taking 
into account all the possible keywords, special phrases like 
extern, properties, and template arguments, both for parameters 
and return values.


And that's just to parse function declarations!

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

2016-06-14 Thread Adam D. Ruppe via Digitalmars-d


On Wednesday, 15 June 2016 at 03:59:43 UTC, cy wrote:

So I was toying with the idea of writing a D parser


I suggest you start with a lexer. It'd enormously simplify the 
problem.

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

2016-06-14 Thread deadalnix via Digitalmars-d


On Wednesday, 15 June 2016 at 03:59:43 UTC, cy wrote:
So I was toying with the idea of writing a D parser, and this 
happened.


const(/*
D is kind of hard to parse. /*
/**/
int//) foo(T//
) foo(T//
)(T /* I mean,

 seriously

 */ bar)
if ( is (T == // how on earth do they do it?
 int) ) {
return
cast /+  where does the function name /+ even start? +/
+/
( const (int) )
bar//;}
;}

void main() {
import std.stdio;
writeln(foo(42));
}

I don't think I'm going to write a D parser.


That's hard to read, for a human, there is nothing in that 
example that is especially difficult for a machine to muddle 
through.

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

2016-06-14 Thread cy via Digitalmars-d

So I was toying with the idea of writing a D parser, and this 
happened.


const(/*
D is kind of hard to parse. /*
/**/
int//) foo(T//
) foo(T//
)(T /* I mean,

 seriously

 */ bar)
if ( is (T == // how on earth do they do it?
 int) ) {
return
cast /+  where does the function name /+ even start? +/
+/
( const (int) )
bar//;}
;}

void main() {
import std.stdio;
writeln(foo(42));
}

I don't think I'm going to write a D parser.

Re: fork/exec performance problem?

2016-06-14 Thread rikki cattermole via Digitalmars-d


On 15/06/2016 9:59 AM, Johan Holmberg via Digitalmars-d wrote:

Hi!

I'm trying to write a simple D program to emulate "parallel -u -jN", ie.
running a number of commands in parallel to take advantage of a
multicore machine (I'm testing on a 24-core Ubuntu machine).

I have written almost equivalent programs in C++ and D, and hoped that
they should run equally fast. But the performance of the D version
degrades when the number of commands increase, and I don't understand
why. Maybe I'm using D incorrectly? Or is it the garbage collector that
kicks in (even if I hope I don't allocate much memory after the initial
setup)?

My first testcase consisted of a file with 85000 C/C++ compilation
commands, to be run 24 in parallel. Most source files are really small
(different modules in the runtime library of a C/C++ compiler for
embedded development, built in different flavors).

If I invoke the D program 9 times with around 1 (85000/9 to be
exact) commands each time, it performs almost on par with the C++
version. But with all 85000 files in one invokation, the D version takes
1.5 times as long (6min 30s --> 10min).

My programs (C++ and D) are really simple:

1) read all commands from STDIN into an array in the program
2) iterate over the array and keep N programs running at all times
3) start new programs with "fork/exec"
4) wait for finished programs with "waitpid"

If I compare the start of a 85000-run and a 1-run, the 85000-run is
slower right from the start. I don't understand why? The only difference
must be that 85000-run has allocated a bigger array.

My D program can be viewed at:


https://bitbucket.org/holmberg556/examples/src/79ef65e389346e9957c535b77201a829af9c62f2/parallel_exec/parallel_exec_dlang.d

Any help would be appreciated.

/Johan Holmberg


This is more appropriate for D.learn.

Few things, disable the GC and force a collect in that while loop.
Next you're allocating hugely.

I would recommend replacing commands variable with some form of 
'smarter' array. Basically allocating in blocks instead of just 
appending one at a time. I'm not sure Appender is quite what you want 
here so it will be home made so to speak.


My revised edition:

import std.conv;
import std.stdio;
import std.string;
import std.process;
import core.stdc.stdlib;
import core.sys.posix.unistd;
import core.sys.posix.sys.wait;

int process_start(string cmdline) {
int pid = fork();
if (pid == -1) {
perror("fork");
exit(1);
}
else if (pid == 0) {
  string[3] argv = ["sh", "-c", cmdline];
  execvp("sh", argv);
  _exit(126);
}
else {
return pid;
}
assert(0);
}

void process_wait(out int pid, out int status) {
pid = waitpid(0, , 0);
if (pid == -1) {
perror("waitpid");
exit(1);
}
}

int
main(string[] argv)
{
import core.memory;
GC.disable;

int maxrunning = 1;
if (argv.length > 1) {
maxrunning = to!int(argv[1]);
}
bool verbose = (argv.length > 2);

string command;
string[] commands;
foreach (line; stdin.byLine()) {
commands ~= line.idup;
}

if (verbose) {
writeln("#parallel = ", maxrunning);
writeln("#commands = ", commands.length);
stdout.flush();
}

int next = 0;
int nrunning = 0;
while (next < commands.length || nrunning > 0) {
while (next < commands.length && nrunning < maxrunning) {
process_start(commands[next]);
next++;
nrunning++;
}
int pid;
int exitstatus;
process_wait(pid, exitstatus);
nrunning--;
if (exitstatus != 0) {
writeln("ERROR: ...");
exit(1);
}
GC.collect;
}
return 0;
}

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


On 6/14/2016 8:23 PM, tsbockman wrote:

On Wednesday, 15 June 2016 at 00:16:12 UTC, Walter Bright wrote:

A complete list of what types are acceptable for 'N' would be desirous, too.


This is specified fully in the template constraints:
if (isIntegral!N && isUnqual!N)
if ((isIntegral!N && !isUnqual!N) || isCheckedint!N)

The second overload simply forwards to the first, after applying
BasicScalar!(Unqual!N).


Why would a checkedint be a base type for a checkedint?



However, I recall that new users tend to get confused/intimidated by template
constraints, so I suppose I should add a prose explanation to the docs, as well.


The fact that anyone has to write !isUnqual, i.e. a double negative, is crummy 
design. But that's not your fault :-)

Re: size_t vs uintptr_t

2016-06-14 Thread rikki cattermole via Digitalmars-d

size_t is defined in object.d. If we want to migrate fully, we will need 
to add a public import for uintptr_t. Otherwise it is not very 
consistent (and adds one more import across the board, when previously 
there was none.).

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


On 6/14/2016 8:15 PM, tsbockman wrote:

N is a basic integral type, it needs a better name than 'N'. How about
'BaseType' or even 'BaseIntegralType'? A complete list of what types are
acceptable for 'N' would be desirous, too.


`N` is not a public symbol, and it's used all over the place.


It appears all over the public documentation.


Do I really need to give it some giant multi-word name?


Something better than 'N'.


Besides which, Phobos uses single-letter names for template parameter type names
all over the place.


Generally 'T' is used for 'any type'. 'N' has no corresponding significance.


---
'bscal' is a complete mystery without reading the documentation. Perhaps
'value' instead?


`value` is a very popular name for function parameters and local variables.
`bscal` needs a more obscure name to prevent the free function version (a shim
to facilitate uniform treatment of basic integral types and checkedint types in
generic code) from shadowing or being shadowed by local symbols.

(I originally called it `value`, but changed it once I realized how annoying it
is not to be able to use that name for anything else in generic code that uses
`checkedint`.)

Also, I prefer a more unfriendly name for `bscal` to remind people that
accessing it entails giving up all of the safety benefits of `checkedint`. The
fact that it's grep-able, too, could be helpful to linters and the like.


Greppability is inddeed a plus, but 'bscal' is needlessly uninformative. Note 
that publicly facing names should not be so.




I will work on the docs some more.


Thank you.



* SmartInt.toString(sink, fmt)
* SafeInt.toString(sink, fmt)
* checkedint.to()
* IntFlag.toString(sink, fmt)
* IntFlags.toString(sink, fmt)


I see no love for output ranges :-(

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


On Wednesday, 15 June 2016 at 00:16:12 UTC, Walter Bright wrote:
A complete list of what types are acceptable for 'N' would be 
desirous, too.


This is specified fully in the template constraints:
if (isIntegral!N && isUnqual!N)
if ((isIntegral!N && !isUnqual!N) || isCheckedint!N)

The second overload simply forwards to the first, after applying 
BasicScalar!(Unqual!N).


However, I recall that new users tend to get confused/intimidated 
by template constraints, so I suppose I should add a prose 
explanation to the docs, as well.

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

2016-06-14 Thread Seb via Digitalmars-d-learn


On Wednesday, 15 June 2016 at 03:11:23 UTC, data pulverizer wrote:

in that case:

import std.array : array;
int[] x = slice.byElement.array;


Are you sure you want to create a _copy_ of your data? In most 
cases you don't need that ;-)



thanks, now I can go to bed!


You are welcome. Sleep tight!

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

2016-06-14 Thread data pulverizer via Digitalmars-d-learn


On Wednesday, 15 June 2016 at 00:16:12 UTC, Walter Bright wrote:
Overall, I find the documentation to be unusually good. Nice 
work!


Thanks. :-D




.noex

  The .noex member is oddly named, being a negative and no idea 
what 'ex' means. It sets a sticky flag on error, so perhaps 
.sticky?


Originally I wanted to have the policies just be `throws` and 
`nothrow` - but of course `nothrow` is a keyword, so I chose 
`noex` (short for "no exceptions") instead. I agree it looks kind 
of odd though, especially since I later added the `asserts` 
policy.


I'll consider renaming `noex`, or at least add an explanation of 
the mnemonic to the docs.



---
N is a basic integral type, it needs a better name than 'N'. 
How about 'BaseType' or even 'BaseIntegralType'? A complete 
list of what types are acceptable for 'N' would be desirous, 
too.


`N` is not a public symbol, and it's used all over the place. Do 
I really need to give it some giant multi-word name?


Besides which, Phobos uses single-letter names for template 
parameter type names all over the place.



---
'bscal' is a complete mystery without reading the 
documentation. Perhaps 'value' instead?


`value` is a very popular name for function parameters and local 
variables. `bscal` needs a more obscure name to prevent the free 
function version (a shim to facilitate uniform treatment of basic 
integral types and checkedint types in generic code) from 
shadowing or being shadowed by local symbols.


(I originally called it `value`, but changed it once I realized 
how annoying it is not to be able to use that name for anything 
else in generic code that uses `checkedint`.)


Also, I prefer a more unfriendly name for `bscal` to remind 
people that accessing it entails giving up all of the safety 
benefits of `checkedint`. The fact that it's grep-able, too, 
could be helpful to linters and the like.



---
enum IntFlagPolicy policy;

  Should contain a link to the complete explanation.

---
Should have a "References:" section with link to core.checkedint

---
-O (DMD) should be a link to the -O flag instructions 
http://dlang.org/dmd-windows.html#switch-O


---
'--inline' is not a DMD switch

---
Remove all use of 'you' and 'your' from the documentation. For 
example:


"If you really need more speed, try switching to DebugInt for 
the hottest code in your program (like inner loops) before 
giving up on checkedint entirely."


becomes:

"For more speed, switch to DebugInt for the hottest code in the 
program (like inner loops)."


(The internal link to DebugInt is wrong.)

And:

"This way, you can use SafeInt!N to debug your integer logic in 
testing, but switch to basic N in release mode for maximum 
speed and the smallest binaries."


becomes:

"This way, use SafeInt!N to debug integer logic in testing, but 
switch to basic N in release mode for maximum speed and the 
smallest binaries."


Reference material should never contain "you" or "your".

---
"debuggin" => "debugging"

---
There's an overall lack of use of internal links to navigate 
within the page.


I will work on the docs some more.


---
Functions are tagged @safe. Are there any unsafe functions?


Sort of. There are a small number of template functions in 
`checkedint` that call some outside function whose @safety is 
unspecified, requiring the @safe-ty of the `checkedint` function 
to be inferred.


I believe the complete list currently is:

* SmartInt.toString(sink, fmt)
* SafeInt.toString(sink, fmt)
* checkedint.to()
* IntFlag.toString(sink, fmt)
* IntFlags.toString(sink, fmt)

(It would be great if we could fill in the gaps in D's attribute 
system - it's kind of ridiculous that for every attribute, there 
is at least one possible mode that cannot be indicated explicitly 
in any way.)

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


On Wednesday, 15 June 2016 at 02:50:30 UTC, Seb wrote:
On Wednesday, 15 June 2016 at 02:43:37 UTC, data pulverizer 
wrote:

How do I unravel a sliced item T[].sliced(...) to an array T[]?

For instance:

import std.experimental.ndslice;
auto slice = new int[12].sliced(3, 4);
int[] x = ??;

Thanks


A slice is just a _view_ on your memory, the easiest way is to 
save a reference to your array like this:


```
int[] arr = new int[12];
auto slice = arr.sliced(3, 4);
slice[1, 1] = 42;
arr // [0, 0, 0, 0, 0, 42, 0, 0, 0, 0, 0, 0]
```

For a general case, you should give `byElement` a try:

https://dlang.org/phobos/std_experimental_ndslice_selection.html#byElement


in that case:

import std.array : array;
int[] x = slice.byElement.array;

thanks, now I can go to bed!

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

2016-06-14 Thread Seb via Digitalmars-d-learn


On Wednesday, 15 June 2016 at 02:43:37 UTC, data pulverizer wrote:

How do I unravel a sliced item T[].sliced(...) to an array T[]?

For instance:

import std.experimental.ndslice;
auto slice = new int[12].sliced(3, 4);
int[] x = ??;

Thanks


A slice is just a _view_ on your memory, the easiest way is to 
save a reference to your array like this:


```
int[] arr = new int[12];
auto slice = arr.sliced(3, 4);
slice[1, 1] = 42;
arr // [0, 0, 0, 0, 0, 42, 0, 0, 0, 0, 0, 0]
```

For a general case, you should give `byElement` a try:

https://dlang.org/phobos/std_experimental_ndslice_selection.html#byElement

ndslice: convert a sliced object to T[]

2016-06-14 Thread data pulverizer via Digitalmars-d-learn


How do I unravel a sliced item T[].sliced(...) to an array T[]?

For instance:

import std.experimental.ndslice;
auto slice = new int[12].sliced(3, 4);
int[] x = ??;

Thanks

Re: size_t vs uintptr_t

2016-06-14 Thread deadalnix via Digitalmars-d


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).

Re: [RFC] List of contributors per module


On 6/14/2016 6:10 PM, Seb wrote:

On Wednesday, 25 May 2016 at 06:51:45 UTC, Walter Bright wrote:

On 5/24/2016 12:22 PM, Seb wrote:

I recently made a PR to dlang.org which is aimed to show a list of all
contributors to a Phobos module based on the git history.
The idea is to give all the awesome people who have helped and contributed their
earned credit!


One idea is to add a "Contributors" button, and when clicked, it executes some
javascript that then loads and displays the avatars for the contributors.


As there as been diverse feedback and no conclusion, I would like try to revive
this discussion - preferably on Github [1].
To argue against some of the posts here, a short summary of the Github 
discussion:

1) There's _no_ performance impact - everything is down lazily after the page
was loaded (see Github for an detailed description)
2) The clutter isn't visible too most users anyhow as the contributer's list is
shown at the bottom of the page
3) It currently would require a lot of hard-to-main ddoc hacks to due this at
compile-time (see Github)


There's still the added net traffic (bad for mobile users).



If you have better ideas how we could incorporate such statistics, let me know 
:)


Sure: One idea is to add a "Contributors" button, and when clicked, it executes 
some javascript that then loads and displays the avatars for the contributors.

Re: [RFC] List of contributors per module

2016-06-14 Thread Seb via Digitalmars-d


On Wednesday, 25 May 2016 at 06:51:45 UTC, Walter Bright wrote:

On 5/24/2016 12:22 PM, Seb wrote:
I recently made a PR to dlang.org which is aimed to show a 
list of all

contributors to a Phobos module based on the git history.
The idea is to give all the awesome people who have helped and 
contributed their

earned credit!


One idea is to add a "Contributors" button, and when clicked, 
it executes some javascript that then loads and displays the 
avatars for the contributors.


As there as been diverse feedback and no conclusion, I would like 
try to revive this discussion - preferably on Github [1].
To argue against some of the posts here, a short summary of the 
Github discussion:


1) There's _no_ performance impact - everything is down lazily 
after the page was loaded (see Github for an detailed description)
2) The clutter isn't visible too most users anyhow as the 
contributer's list is shown at the bottom of the page
3) It currently would require a lot of hard-to-main ddoc hacks to 
due this at compile-time (see Github)


If you have better ideas how we could incorporate such 
statistics, let me know :)


[1] https://github.com/dlang/dlang.org/pull/1307

[Issue 15848] Identity opAssign not called on out parameters

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

Mathias Lang  changed:

   What|Removed |Added

   Assignee|nob...@puremagic.com|mathias.l...@sociomantic.co
   ||m

--- Comment #6 from Mathias Lang  ---
Note: Your `opAssign` is not an identity `opAssign`
(http://dlang.org/spec/struct.html#assign-overload), so it wouldn't be called
in any copying situation.

Correct test code:

```
import std.stdio;

void foo(out Test x) {
writeln("x.n = ", x.n);
}

struct Test {
int n;
~this() {
writeln("~this()");
}
ref Test opAssign(Test val) {
writefln("opAssign(%s)", val);
return this;
}
}

void main() {
Test t;
foo(t);
writeln("done");
}
```

And this doesn't call `opAssign` either (same output).

What should happen here:
- The destructor should be called if no `opAssign` is defined, because the
compiler provides an elaborate `opAssign` when it sees a struct with a dtor or
postblit being copied.
- If an identity `opAssign` is defined, it should be called.

I'll change the title, because `out` can be contract as well.

--

[Issue 15848] Identity opAssign not called on out parameters

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

Mathias Lang  changed:

   What|Removed |Added

 CC||mathias.l...@sociomantic.co
   ||m
   Hardware|x86_64  |All
Summary|out doesn't call opAssign() |Identity opAssign not
   ||called on out parameters
 OS|Linux   |All

--- Comment #5 from Mathias Lang  ---
Note: Your `opAssign` is not an identity `opAssign`
(http://dlang.org/spec/struct.html#assign-overload), so it wouldn't be called
in any copying situation.

Correct test code:

```
import std.stdio;

void foo(out Test x) {
writeln("x.n = ", x.n);
}

struct Test {
int n;
~this() {
writeln("~this()");
}
ref Test opAssign(Test val) {
writefln("opAssign(%s)", val);
return this;
}
}

void main() {
Test t;
foo(t);
writeln("done");
}
```

And this doesn't call `opAssign` either (same output).

What should happen here:
- The destructor should be called if no `opAssign` is defined, because the
compiler provides an elaborate `opAssign` when it sees a struct with a dtor or
postblit being copied.
- If an identity `opAssign` is defined, it should be called.

I'll change the title, because `out` can be contract as well.

--

FYI Command-line reference documentation on dlang.org (dmd.html) recognizes your platform

2016-06-14 Thread Seb via Digitalmars-d

Since a couple of days dlang.org got a bit smarter and recognizes 
your platform for the according command-line reference. As many 
didn't notice, I thought I write a quick notice. Essentially it's 
a small change on the long road to make D more user-friendly 
(first five mins!), that just redirects `dmd.html` to the 
according platform, e.g.:


https://dlang.org/dmd.html -> https://dlang.org/dmd-linux.html
https://dlang.org/dmd.html#switch-O -> 
https://dlang.org/dmd-linux.html#switch-O


Of course a navigation menu is provided, to allow convenient 
access to other documentations.


So if you don't want to annoy your users with a Windows 
documentation, you might want to link to dmd.html in the future 
;-)

For all details, see [1]:

[1] https://github.com/dlang/dlang.org/pull/1365

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


Overall, I find the documentation to be unusually good. Nice work!



.noex

  The .noex member is oddly named, being a negative and no idea what 'ex' 
means. It sets a sticky flag on error, so perhaps .sticky?


---
N is a basic integral type, it needs a better name than 'N'. How about 
'BaseType' or even 'BaseIntegralType'? A complete list of what types are 
acceptable for 'N' would be desirous, too.


---
'bscal' is a complete mystery without reading the documentation. Perhaps 'value' 
instead?


---
enum IntFlagPolicy policy;

  Should contain a link to the complete explanation.

---
Should have a "References:" section with link to core.checkedint

---
-O (DMD) should be a link to the -O flag instructions 
http://dlang.org/dmd-windows.html#switch-O


---
'--inline' is not a DMD switch

---
Remove all use of 'you' and 'your' from the documentation. For example:

"If you really need more speed, try switching to DebugInt for the hottest code 
in your program (like inner loops) before giving up on checkedint entirely."


becomes:

"For more speed, switch to DebugInt for the hottest code in the program (like 
inner loops)."


(The internal link to DebugInt is wrong.)

And:

"This way, you can use SafeInt!N to debug your integer logic in testing, but 
switch to basic N in release mode for maximum speed and the smallest binaries."


becomes:

"This way, use SafeInt!N to debug integer logic in testing, but switch to basic 
N in release mode for maximum speed and the smallest binaries."


Reference material should never contain "you" or "your".

---
"debuggin" => "debugging"

---
There's an overall lack of use of internal links to navigate within the page.

---
Functions are tagged @safe. Are there any unsafe functions?

Re: dlang-requests 0.1.7 released

2016-06-14 Thread Seb via Digitalmars-d-announce


On Tuesday, 14 June 2016 at 22:46:00 UTC, ikod wrote:
On Tuesday, 14 June 2016 at 14:59:37 UTC, Andrei Alexandrescu 
wrote:

On 6/11/16 7:03 PM, ikod wrote:

Hello,

Dlang-requests is library created under influence of

...
Code and docs available at 
https://github.com/ikod/dlang-requests or as

dub package.

Thanks Dlang authors and community for excellent language.


Thanks! Does the project have a dub presence? How does it 
compare feature-wise and speed-wise with curl? -- Andrei


Yes, it is in the dub repository under name "requests"
As for speed comparison, I'll post numbers in a day or two, 
when I'll finish some performance improvements.


Feature matrix for libcurl(per 
https://curl.haxx.se/docs/features.html) and dlang-requests: 
https://github.com/ikod/dlang-requests/blob/master/docs/matrix.txt Please note, that dlang-requests supports only http,https and ftp.


No worries - `std.net.curl` doesn't expose all the exotic 
protocols that libcurl supports either ;-)
Same goes for the features, it's more interestingly to see what 
std.net.curl exposes to the user:


http://dlang.org/phobos/std_net_curl.html

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


On 6/14/2016 4:25 PM, Walter Bright wrote:

Thanks for doing this!

On 6/7/2016 1:50 AM, Robert burner Schadek wrote:

== SmartInt ==
SmartInt smartOp strive to actually give the mathematically correct answer
whenever possible, rather than just signaling an error.

== SafeInt ==
SafeInt safeOp strive to match the behaviour of the basic integral types
exactly, $(B except) that where the behaviour of the basic type is wrong, or
very unintuitive, an error is signaled instead.



What the differences between these types are is unclear, for example, the former
says "correct" and the latter says "not wrong". Also, "very unintuitive" has a
pretty slippery meaning.



A better explanation:

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

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


Thanks for doing this!

On 6/7/2016 1:50 AM, Robert burner Schadek wrote:

== SmartInt ==
SmartInt smartOp strive to actually give the mathematically correct answer
whenever possible, rather than just signaling an error.

== SafeInt ==
SafeInt safeOp strive to match the behaviour of the basic integral types
exactly, $(B except) that where the behaviour of the basic type is wrong, or
very unintuitive, an error is signaled instead.



What the differences between these types are is unclear, for example, the former 
says "correct" and the latter says "not wrong". Also, "very unintuitive" has a 
pretty slippery meaning.

Re: size_t vs uintptr_t


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.

[Issue 12529] Function/delegate type alias picks up @safe attribute from surrounding scope

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

Walter Bright  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #5 from Walter Bright  ---
This is operating correctly. An alias should not be able to override the safety
of the type, as in https://issues.dlang.org/show_bug.cgi?id=12527, but if it is
the default it should be settable.

--

[Issue 12529] Function/delegate type alias picks up @safe attribute from surrounding scope

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 12527] Cannot make @system function/delegate alias in a @safe section

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

Walter Bright  changed:

   What|Removed |Added

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

--

[Issue 12527] Cannot make @system function/delegate alias in a @safe section

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

Walter Bright  changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com

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

--

Re: dlang-requests 0.1.7 released

2016-06-14 Thread ikod via Digitalmars-d-announce

On Tuesday, 14 June 2016 at 14:59:37 UTC, Andrei Alexandrescu 
wrote:

On 6/11/16 7:03 PM, ikod wrote:

Hello,

Dlang-requests is library created under influence of

...
Code and docs available at 
https://github.com/ikod/dlang-requests or as

dub package.

Thanks Dlang authors and community for excellent language.


Thanks! Does the project have a dub presence? How does it 
compare feature-wise and speed-wise with curl? -- Andrei


Yes, it is in the dub repository under name "requests"
As for speed comparison, I'll post numbers in a day or two, when 
I'll finish some performance improvements.


Feature matrix for libcurl(per 
https://curl.haxx.se/docs/features.html) and dlang-requests: 
https://github.com/ikod/dlang-requests/blob/master/docs/matrix.txt Please note, that dlang-requests supports only http,https and ftp.

Re: size_t vs uintptr_t

2016-06-14 Thread Guillaume Boucher via Digitalmars-d


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

A related issue is I see much code of the form:

cast(size_t)ptr & 3

to check alignment. A better (possibly faster) method is:

cast(uint)ptr & 3

because even 64 bit CPUs often operate faster with 32 bit 
operations (thanks to some research by Andrei).


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.

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

2016-06-14 Thread sarn via Digitalmars-d-announce


On Monday, 13 June 2016 at 20:12:27 UTC, Walter Bright wrote:

On 6/12/2016 4:27 PM, Jason White wrote:

I don't understand this dependency-phobia.


It's the "first 5 minutes" thing. Every hiccup there costs us 
maybe half the people who just want to try it out.


...

The makefiles, especially posix.mak, have grown into horrific 
snarls of who-knows-what-is-happening.


I had a minor rant about this at DConf.  The makefiles are the 
major reason I haven't contributed to the core D projects.


They'd be a hell of a lot simpler if everything that isn't 
building an executable (and isn't idempotent) got ripped out.  No 
downloading compilers, no cloning/updating repos, etc, etc.  
Having a pushbutton process for installing/bootstrapping is cool, 
but that stuff is better off in scripts.

size_t vs uintptr_t

I recently remembered something I'd half-forgotten. A size_t is not guaranteed 
to be the same size as a pointer. A uintptr_t is.


size_t and uintptr_t are the same for all platforms that D currently supports. 
But this may not always hold true, and besides, it is better self-documenting 
when using uintptr_t for "holds a pointer" as opposed to size_t as "holds an 
offset to a pointer".


uintptr_t may be found in:

import core.stdc.stdint : uintptr_t;

as it is part of Standard C.

When are they not the same?

1. In 16 bit code that supports the 'far' memory model, where pointers are a 
segment/offset pair and uintptr_t would be 32 bits and size_t 16. Of course, D 
does not support 16 bit code so this is irrelevant for D.


2. There is a memory model in the 32 bit x86 where segment/offset pairs are 
used, and uintptr_t would be >=48 bits and size_t 32. This is used sometimes in 
kernel programming.


3. Any system that would have some sort of banked switched memory scheme.

Ok, I admit these are not likely to emerge. But I'd like our code to be 
pedantically, nitpickingly correct, as well as self-documenting.


druntime/phobos pervasively misuse size_t. I've put in a PR to address some:

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

=

A related issue is I see much code of the form:

cast(size_t)ptr & 3

to check alignment. A better (possibly faster) method is:

cast(uint)ptr & 3

because even 64 bit CPUs often operate faster with 32 bit operations (thanks to 
some research by Andrei).


=

Call to action: do things like:

grep cast(size_t) *.d

to look for misuse, and submit PRs to fix!

fork/exec performance problem?

2016-06-14 Thread Johan Holmberg via Digitalmars-d

Hi!

I'm trying to write a simple D program to emulate "parallel -u -jN", ie.
running a number of commands in parallel to take advantage of a multicore
machine (I'm testing on a 24-core Ubuntu machine).

I have written almost equivalent programs in C++ and D, and hoped that they
should run equally fast. But the performance of the D version degrades when
the number of commands increase, and I don't understand why. Maybe I'm
using D incorrectly? Or is it the garbage collector that kicks in (even if
I hope I don't allocate much memory after the initial setup)?

My first testcase consisted of a file with 85000 C/C++ compilation
commands, to be run 24 in parallel. Most source files are really small
(different modules in the runtime library of a C/C++ compiler for embedded
development, built in different flavors).

If I invoke the D program 9 times with around 1 (85000/9 to be exact)
commands each time, it performs almost on par with the C++ version. But
with all 85000 files in one invokation, the D version takes 1.5 times as
long (6min 30s --> 10min).

My programs (C++ and D) are really simple:

1) read all commands from STDIN into an array in the program
2) iterate over the array and keep N programs running at all times
3) start new programs with "fork/exec"
4) wait for finished programs with "waitpid"

If I compare the start of a 85000-run and a 1-run, the 85000-run is
slower right from the start. I don't understand why? The only difference
must be that 85000-run has allocated a bigger array.

My D program can be viewed at:

https://bitbucket.org/holmberg556/examples/src/79ef65e389346e9957c535b77201a829af9c62f2/parallel_exec/parallel_exec_dlang.d

Any help would be appreciated.

/Johan Holmberg

Re: I'd love to see DScript one day ...


On 6/14/2016 11:55 AM, Dicebot wrote:

Because for some people static typing and compile-time checking is not a
burden but a great help in designing bug-free programs. And if you stand
by those values, JS is absolutely terrible language no matter the domain
(it drives me mad every time I have to touch it).


I find a typeless language convenient when it's less than one screen in size. 
Their advantages fall away when things get larger. I don't know how people cope 
with a large project in a dynamic language.

Re: Fixed date to move to ddox for Phobos documentation

2016-06-14 Thread Vladimir Panteleev via Digitalmars-d

On Tuesday, 14 June 2016 at 13:40:57 UTC, Andrei Alexandrescu 
wrote:

On 6/13/16 9:41 PM, Vladimir Panteleev wrote:
On Tuesday, 14 June 2016 at 00:31:56 UTC, Andrei Alexandrescu 
wrote:
Walter or Jan should be able to do that. But I'm confused as 
to how

NNTP groups would help here.


It would allow people to subscribe and reply to comments using 
their
newsreader (or by email, if it's also associated with a 
mailing list on
Brad's server). It's one of the bigger reasons to consider 
using DFeed.


Aren't the snazzy nice formatting and the display in the page 
the nicest things about on-doc-page comments? Email 
subscription to such is fine but writing via email or NNTP 
seems a clunky adaptation. BTW does disqus allow D syntax 
coloring? -- Andrei


Well, Markdown support is on the roadmap, and embedding it into 
the page like Disqus was part of the proposal. Email/NNTP is an 
option, not a requirement :)

Re: Strange Issues regarding aliases

2016-06-14 Thread Alex Parrill via Digitalmars-d-learn


On Tuesday, 14 June 2016 at 17:37:40 UTC, Joerg Joergonson wrote:
On Tuesday, 14 June 2016 at 17:34:42 UTC, Joerg Joergonson 
wrote:
This is how derelict does it, I simply moved them in to the 
class for simplicity.


I mean glad: http://glad.dav1d.de/


It seems that a loader is required for some reason and that 
possibly could be one or both of the problems.


You absolutely need a loader to load most opengl functions. They 
are not usually exposed in the shared object, as gl function 
pointers are tied to a specific opengl context.


You are trying to call function pointer types, which is invalid. 
You need to declare some variable with the type, load the 
function pointer into the variable (platform specific; there are 
plenty of tutorials on how to do this in C), and call that 
variable.



(Also I disagree that separating the opengl API based on what the 
symbol is is a step up from the "ancient and backwards flat 
access" way. Functions are, by neccessity, coupled to the types 
and enums they take. A better categorization would be based on 
version introduced or extension, iirc jogl does that)

Re: nested inout return type

2016-06-14 Thread Era Scarecrow via Digitalmars-d-learn

On Tuesday, 14 June 2016 at 19:48:06 UTC, Steven Schveighoffer 
wrote:
I honestly think the best place to go figure these things out 
is stackoverflow (or just the internet in general). Whenever I 
have a technical problem I can't figure out (or am too lazy to 
diagnose myself), I search and SO usually gives me an answer :)


 For the longest time I didn't have internet consistently, so I 
often had to figure these things out solo and alone. Honestly I'm 
still new to figuring out where things are on the internet, or 
what I need and don't need.


 Doesn't help being self taught means I don't know some of the 
lingo. What is map? What does reduce do? What's a HashMap? These 
things by themselves (to someone relatively new) doesn't make 
sense, and the STL and C++ seem to actively push me away from 
understanding it so I dropped them wholesale. The only libraries 
that made sense and I would rely on were the bare minimum core 
library ones included in the '88 CPL including bare minimum 
string and IO functions.


 Perhaps that's why I'm still shy about learning some of the 
libraries and understanding some of the more ingenious solutions 
that can be written in a couple lines rather than building my own 
solution which is clunky (but better than C++).


 Although I'm doing better than I used to, it's still a chore. :(

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

2016-06-14 Thread Nordlöw via Digitalmars-d


On Tuesday, 14 June 2016 at 13:58:29 UTC, tsbockman wrote:
Given the above, I believe we should move forward with 
`checkedint` as-is. Someone can add a `BoundInt` type to it 
later, if there is demand.


Ok. Thanks.

[Issue 14411] switch statement: docs/behavior differ

2016-06-14 Thread Steven Schveighoffer via Digitalmars-d-learn

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

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

https://github.com/dlang/dmd/commit/b76b0ce720197bc58c37e706c4788f8c5517dc7c
Fix issue 14411 - Make implicit switch case fallthrough an error

https://github.com/dlang/dmd/commit/6e2bf76d289c128a46e50284fb632f8f0c696d31
Merge pull request #5866 from mathias-lang-sociomantic/fix-14411

Fix issue 14411 - Make implicit switch case fallthrough an error

--

Re: nested inout return type


On 6/14/16 3:38 PM, Era Scarecrow wrote:

On Tuesday, 14 June 2016 at 14:47:11 UTC, Steven Schveighoffer wrote:

On Tuesday, 14 June 2016 at 01:50:17 UTC, Era Scarecrow wrote:

 return cast(inout(Slice)) Slice(cast(T*)ptr+a, b-a);


Better: inout(Slice)(ptr+a, b-a);


 Of course... My amateur D-fu skills show themselves. cast() const()
immutable() are the same, why not inout? Hmmm...


It's mostly akin to immutable (which would require similar syntax). It's 
because once constructed, inout-flavored wrappers cannot change anything 
internally. So you have to do it all at once.


const is different, because you can construct mutable, and then simply 
cast to const when you feel like it.


But of course, if the components you are using to construct are already 
flavored, you have no choice. All-at-once construction is the only way 
without casting.



 I feel like a tutorial for common problems and solutions should be
present for C, C++ & D. Then again maybe that's some cookbooks that I
haven't purchased/read yet.


For a long time I have been working on an article to talk about the 
quirks/tricks of inout. I gave a talk at dconf, but there are more 
things to show than are possible in a spoken talk.


I honestly think the best place to go figure these things out is 
stackoverflow (or just the internet in general). Whenever I have a 
technical problem I can't figure out (or am too lazy to diagnose 
myself), I search and SO usually gives me an answer :)


-Steve

[Issue 16174] New: [SECURITY] HTTP header injection

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

  Issue ID: 16174
   Summary: [SECURITY] HTTP header injection
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: phobos
  Assignee: nob...@puremagic.com
  Reporter: cpic...@openmailbox.org

std.net.curl is vulnerable to HTTP header injection.

import std.stdio;
import std.net.curl;

void main(string[] args) {
auto http = HTTP("localhost:8000");
http.addRequestHeader("User-agent",
  "Mozilla/5.0\x0d\x0aLocation: header injection");
http.onReceiveHeader =
(in char[] key, in char[] value) { writeln(key ~ ": " ~ value); };
http.onReceive = (ubyte[] data) { /+ drop +/ return data.length; };
http.perform();
}

What was sent:

GET / HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0
Location: header injection
Accept: */*

This flaw was discussed in length here https://bugs.python.org/issue22928 as
python's standard library was affected by the same vulnerability (although
there is no link).

The consensus that was found is that although allowing newlines in a user-agent
is RFC compliant it openning the door to security vulnerabilities is not
acceptable. Today python throws an exception when newlines are present in the
header.

--

Re: nested inout return type

2016-06-14 Thread Era Scarecrow via Digitalmars-d-learn

On Tuesday, 14 June 2016 at 14:47:11 UTC, Steven Schveighoffer 
wrote:

On Tuesday, 14 June 2016 at 01:50:17 UTC, Era Scarecrow wrote:

 return cast(inout(Slice)) Slice(cast(T*)ptr+a, b-a);


Better: inout(Slice)(ptr+a, b-a);


 Of course... My amateur D-fu skills show themselves. cast() 
const() immutable() are the same, why not inout? Hmmm...


 Reminds me when I didn't understand how to get the address or 
use pointers correctly, so I'd do stuff like [i] everywhere 
because no one told me a better way to do it.


 I also remember seeing odd issues and bugs in C when using a 
char and then having negative numbers so having to use & 0xff 
flags everywhere until I added the _unsigned_ keyword in.


 I feel like a tutorial for common problems and solutions should 
be present for C, C++ & D. Then again maybe that's some cookbooks 
that I haven't purchased/read yet.

[Issue 14411] switch statement: docs/behavior differ

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

Mathias Lang  changed:

   What|Removed |Added

 CC||mathias.l...@sociomantic.co
   ||m

--- Comment #8 from Mathias Lang  ---
https://github.com/dlang/dmd/pull/5866

--

Re: I'd love to see DScript one day ...

2016-06-14 Thread Dicebot via Digitalmars-d

On 06/14/2016 07:09 AM, dewitt wrote:
> I know its a dream but really whats wrong with JS in the browser?  Now
> with no need for JQuery and ES6 its not really that bad.  Better to use
> it for a scripting lang and other things.  My opinion only..  If were
> dreamin Id rather see the next Kafka or Elasticsearch big idea written
> in D...

Because for some people static typing and compile-time checking is not a
burden but a great help in designing bug-free programs. And if you stand
by those values, JS is absolutely terrible language no matter the domain
(it drives me mad every time I have to touch it).

[Issue 14411] switch statement: docs/behavior differ

2016-06-14 Thread Andrei Alexandrescu via Digitalmars-d-announce

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

Andrei Alexandrescu  changed:

   What|Removed |Added

 CC||and...@erdani.com
 OS|Mac OS X|All

--- Comment #7 from Andrei Alexandrescu  ---
This has been the behavior for a while. It's time to enact this in the "main"
language.

--

Re: Transient ranges

2016-06-14 Thread Dicebot via Digitalmars-d

On Tuesday, 14 June 2016 at 00:19:54 UTC, Andrei Alexandrescu 
wrote:

On 06/12/2016 04:46 AM, Dicebot wrote:

That is matter of design philosophy. For me such basic library
primitives warrant C++ attitude of "don't pay for what you 
don't ask
for" - and everything else, including actual feature 
completeness, is of

negligible importance compared to that.


C++'s input iterator model also predicates multiple accesses to 
the current value by means of *it.


Yeah, I don't say C++ iterator model is any better for that kind 
of design - sorry if my wording implied that. I wonder how they 
would address it if pipeline approach would ever become popular 
in C++.


See my response to Steven - probably my main issue is wanting 
some very different concept, dedicated stream/pipeline 
abstraction that would still be usable with all the same 
std.algorithm


It seems to me, sometimes if I went by what this forum agrees 
upon I'd write one thousand lines of code one day and remove it 
the next.


Please don't take my rants in the NG as a serious call to action. 
I am simply sharing my concerns in a relevant topic - if there 
was anything pragmatical I could propose, I'd take it to the mail 
list instead or even right a DIP. To be honest, I'd even prefer 
if you ignored _any_ request/proposal which is not submitted as 
such. NG can't be taken as a base for reasoning.


Phobos indeed doesn't seem to make such priorities right now 
and that is

one of reasons I am growing increasingly unhappy with it.


What steps do you think we could take with Phobos to make it 
better without breaking backward compatibility?


Introducing `std2` package is technically not breaking backwards 
compatibility but I presume this is not what you have meant ;) I 
don't know - as I have already said, otherwise I'd actually taken 
some more constructive actions instead of throwing complaints.


If I'd have a say in designing brand new Phobos, it would be very 
different - async by default, with a strict separation of 
lightweight @nogc algorithm and API core (fitting even for 
embedded env) and all the feature rich additional modules built 
on top. This is not kind of stuff one simply "fixes" in existing 
mature library.


At the same time, I am not even sure if it is even important to 
fix. It is good enough for any kind of general purpose 
development, good for productivity. And bigger projects with hard 
performance concerns and maintenance costs tend to grow their own 
"standard" libraries anyway.

Re: July D Boston Meetup gathering


On 06/14/2016 12:00 PM, Steven Schveighoffer wrote:

Just announced. If you are in the area, come join us!

http://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/231887464/


-Steve


Can't wait! -- Andrei

Re: Dlang homepage (CSS files)

2016-06-14 Thread Seb via Digitalmars-d


On Tuesday, 14 June 2016 at 16:54:12 UTC, Mattcoder wrote:
I was taking a look over the network files during the page 
load, and there are some files that I think it should be 
integraded in just one file, for example the CSS.


Look this network status: http://i.imgur.com/YhKcue5.png

The print.css takes around ~700ms to download, and inside there 
are just these lines:


body{background:white}pre{overflow:visible;overflow-X:hidden;font-size:100%}#search-box,#header,#navigation,#lastupdate,#tools,#footernav,#copyright,#github-ribbon,#top,.page-contents{display:none}div#content{background:white;border:0;margin:0;padding:0;font-family:serif;font-size:10pt}

Integraded or even should be inline in the HTML.


Great catch!
The place to start hacking would be here:
https://github.com/dlang/dlang.org/blob/master/dlang.org.ddoc#L68

A quick guide: 
https://github.com/dlang/dlang.org/blob/master/CONTRIBUTING.md


I have to warn you that ddoc isn't that intuitive in comparison 
to other static content generators, it took me quite a while to 
get used too.


Ping me (greenify) or CyberShadow in our #d IRC channel, if you 
need help understanding the setup.




The print.css takes around ~700ms to download


Speaking about the long download time, it would be quite awesome 
if we can ship dlang.org via a CDN.

Re: Transient ranges

2016-06-14 Thread Dicebot via Digitalmars-d

On Monday, 13 June 2016 at 13:59:06 UTC, Steven Schveighoffer 
wrote:
So what it seems like you want is somerange.map(...).front to 
evaluate the lambda only once, without caching. This doesn't 
fit into the definition of ranges, which require the ability to 
access the same front more than once.


What you really want is a new kind of construct. It's not a 
range.


I think you are completely right here, though it is not very 
comforting :) Indeed, looking now through all uses of ranges in 
my code, it has always been same specific subset of their 
functionality - input range based pipeline. Chunk input, build up 
filters/transformations, write output. Never random access or 
even `.save`, and each original input chunk is supposed to be 
processed only once.


Every of my complaints is simply a natural outcome of this usage 
pattern - I'd really prefer to have something more stupid but 
also more fool-proof.

Re: Strange Issues regarding aliases

2016-06-14 Thread Steven Schveighoffer via Digitalmars-d-learn


On 6/14/16 1:37 PM, Joerg Joergonson wrote:

On Tuesday, 14 June 2016 at 17:34:42 UTC, Joerg Joergonson wrote:

This is how derelict does it, I simply moved them in to the class for
simplicity.


I mean glad: http://glad.dav1d.de/


It seems that a loader is required for some reason and that possibly
could be one or both of the problems.



I don't know what glad is doing. What I do know is that if you have an 
alias like this:


alias CullFace = void function(tGL.Enum);

This is type alias, saying variables of type CullFace will be pointers 
to functions that return void, and take tGL.Enum type.


If you attempt to "call" a type, then I don't think it works, you need a 
variable of that type to call it. I think this is why you see such 
strange errors.


It's possible a loader will fill in the details. I don't know.

-Steve

Re: D grammar

2016-06-14 Thread Brian Schott via Digitalmars-d


On Tuesday, 14 June 2016 at 17:27:21 UTC, Joerg Joergonson wrote:
I wonder if someone could write a program generator that 
generates random valid D code from one of these grammars and 
runs it in DMD to find compilation errors.


It shouldn't be too hard to do and only needs to provide 
coverage of the grammar, not all possible programs. This might 
help validate a grammar(could be designed to be generic and for 
other parsing tools).


Patches welcome: https://github.com/Hackerpilot/generated

Re: short programme from "Programming in D" by Ali Cehreli.

2016-06-14 Thread Ali Çehreli via Digitalmars-d-learn

On 06/14/2016 09:09 AM, Steven Schveighoffer wrote:

>> readf (" %s, ");
>> // "No argument for %s"
>>
>> This is a desired feature but dmd does not have this yet. Since dmd
>> provides the front end to gdc and ldc, they don't have this feature
>> either.
>
> Hm... shouldn't it at least require ONE parameter besides the string?
>
> -Steve

Good idea in this case but I think the real issue is providing this 
support for user-defined functions as well.

bool argument_check_function(/* ... */) {
// ...
}

pragma(arg_check, argument_check_function)
int foo(int, string);

I guess it's possible to do something with UDAs as well but the check 
must happen at call sites, which I think UDAs can't reach.

Ali

Re: Strange Issues regarding aliases

2016-06-14 Thread Joerg Joergonson via Digitalmars-d-learn


On Tuesday, 14 June 2016 at 17:34:42 UTC, Joerg Joergonson wrote:
This is how derelict does it, I simply moved them in to the 
class for simplicity.


I mean glad: http://glad.dav1d.de/


It seems that a loader is required for some reason and that 
possibly could be one or both of the problems.

Re: Strange Issues regarding aliases

2016-06-14 Thread Joerg Joergonson via Digitalmars-d-learn

This is how derelict does it, I simply moved them in to the 
class for simplicity.


I mean glad: http://glad.dav1d.de/

Re: D grammar

2016-06-14 Thread Joerg Joergonson via Digitalmars-d


On Tuesday, 14 June 2016 at 13:23:37 UTC, Jacob Carlborg wrote:

On 2016-06-14 11:31, Russel Winder via Digitalmars-d wrote:
Thanks to Vladimir Panteleev, WebFreak001, ketmar, and Brian 
Schott for
replying to my email about a grammar specification for D 
usable for

IDEs and other tools.

It seems that the D language is defined not by a 
re-purposable, machine
readable grammar specification, but solely by the DMD 
compiler, the
parse of which is not defined by a re-purposable, machine 
readable
grammar. Thus any grammar specification that is created is 
unlikely to
be correct and so all tooling and IDE support has to be based 
on
incorrect data. Given the biggest problem with D is, according 
to the
recent survey, tooling and IDE support, you get the feeling 
this is not

an enviable position for a programming language to be in.


How many IDE's/editors do actually use something like EBNF? I 
know TextMate doesn't. It uses some kind of rules with extended 
regular expressions (simplified explanation).


It doesn't matter because once you have a well defined grammar 
you can convert it to any other format you wish.  The point is 
that D has no well defined grammar because it's all mashed up in 
the parsing and compiling itself.


I wonder if someone could write a program generator that 
generates random valid D code from one of these grammars and runs 
it in DMD to find compilation errors.


It shouldn't be too hard to do and only needs to provide coverage 
of the grammar, not all possible programs. This might help 
validate a grammar(could be designed to be generic and for other 
parsing tools).

Re: GTKD - Attach Button to Grid in specific column and row

2016-06-14 Thread Mike Wey via Digitalmars-d-learn


On 06/14/2016 04:54 PM, TheDGuy wrote:

On Saturday, 11 June 2016 at 21:14:43 UTC, Mike Wey wrote:

The way GTK manages width and height, usually widgets are given the
minimum size they need. So when the button is the only widget in the
grid the other rows and columns have a height/width of 0.

You can force the button / gird cell to the bottom left by setting the
expand and alignment properties of the button.




Thanks for your reply, but now the button is always on the bottom right :(




What are you trying to accomplish?

--
Mike Wey

Re: Strange Issues regarding aliases

2016-06-14 Thread Joerg Joergonson via Digitalmars-d-learn

On Tuesday, 14 June 2016 at 16:08:03 UTC, Steven Schveighoffer 
wrote:

On 6/14/16 11:29 AM, Joerg Joergonson wrote:

[...]


Your aliases are a bunch of function pointer types. This isn't 
what you likely want.


I'm assuming you want to bring the existing functions into more 
categorized namespaces? What you need is to do this:


public static struct fGL
{
   alias CullFace = .CullFace; // or whatever the fully 
qualified name is.


I don't have much experience with the opengl modules, so I 
can't be more specific.


-Steve


This is how derelict does it, I simply moved them in to the class 
for simplicity.

Dlang homepage (CSS files)

2016-06-14 Thread Mattcoder via Digitalmars-d

I was taking a look over the network files during the page load, 
and there are some files that I think it should be integraded in 
just one file, for example the CSS.


Look this network status: http://i.imgur.com/YhKcue5.png

The print.css takes around ~700ms to download, and inside there 
are just these lines:


body{background:white}pre{overflow:visible;overflow-X:hidden;font-size:100%}#search-box,#header,#navigation,#lastupdate,#tools,#footernav,#copyright,#github-ribbon,#top,.page-contents{display:none}div#content{background:white;border:0;margin:0;padding:0;font-family:serif;font-size:10pt}

Integraded or even should be inline in the HTML.

Re: nested inout return type

2016-06-14 Thread Simon Bürger via Digitalmars-d-learn

On Tuesday, 14 June 2016 at 14:47:11 UTC, Steven Schveighoffer 
wrote:

* only do one mutable version of opSlice
* add implicit cast (using "alias this") for const(Slice!T) ->
Slice!(const(T)).


Interesting, but unfortunately, the compiler isn't eager about 
this conversion. auto x = s[5 .. 7] isn't going to give you a 
Slice!(const(T)), like an array would. But I like the idea.


Hm, you are right, in fact it doesn't work. Somehow it seemed to 
in my usecase. Well, triplicate it is then. Which isn't that bad 
using something like


auto opSlice(size_t a, size_t b)
{
   // actual non-trivial code
}

auto opSlice(size_t a, size_t b) const
{
   return Slice!(const(T))(ptr, length).opSlice(a,b);
}

auto opSlice(size_t a, size_t b) immutable
{
   return Slice!(immutable(T))(ptr, length).opSlice(a,b);
}

Re: short programme from "Programming in D" by Ali Cehreli.

2016-06-14 Thread Steven Schveighoffer via Digitalmars-d-learn


On 6/14/16 11:44 AM, Ali Çehreli wrote:

On 06/14/2016 04:52 AM, Nick B wrote:


Thanks for the assistance. I assumed that the compiler  would at least
throw a line number, to hint at where the problem was.


Further, when the format string is a literal like the one used in the
program, the compiler can in theory determine at compile time that the
format string does not match the rest of the arguments:

readf (" %s, ");
// "No argument for %s"

This is a desired feature but dmd does not have this yet. Since dmd
provides the front end to gdc and ldc, they don't have this feature either.


Hm... shouldn't it at least require ONE parameter besides the string?

-Steve

Re: Strange Issues regarding aliases

2016-06-14 Thread Steven Schveighoffer via Digitalmars-d-learn


On 6/14/16 11:29 AM, Joerg Joergonson wrote:

I have stuff like


public static class fGL
{
nothrow @nogc extern(System)
{
alias CullFace = void function(tGL.Enum);
alias FrontFace = void function(tGL.Enum);
alias HInt = void function(tGL.Enum, tGL.Enum);
alias LineWidth = void function(tGL.Float);
alias PoIntSize = void function(tGL.Float);
...


Your aliases are a bunch of function pointer types. This isn't what you 
likely want.


I'm assuming you want to bring the existing functions into more 
categorized namespaces? What you need is to do this:


public static struct fGL
{
   alias CullFace = .CullFace; // or whatever the fully qualified name is.

I don't have much experience with the opengl modules, so I can't be more 
specific.


-Steve

[Issue 14411] switch statement: docs/behavior differ

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

Nemanja Boric <4bur...@gmail.com> changed:

   What|Removed |Added

 CC||4bur...@gmail.com

--- Comment #6 from Nemanja Boric <4bur...@gmail.com> ---
*** Issue 16173 has been marked as a duplicate of this issue. ***

--

[Issue 16173] Implicit fall through is silently allowed

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

Nemanja Boric <4bur...@gmail.com> changed:

   What|Removed |Added

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

--- Comment #2 from Nemanja Boric <4bur...@gmail.com> ---
It's reported as a warning (`-w` displays it).

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

--

[Issue 16173] Implicit fall through is silently allowed

2016-06-14 Thread Steven Schveighoffer via Digitalmars-d-announce

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

--- Comment #1 from Nemanja Boric <4bur...@gmail.com> ---
(In reply to Nemanja Boric from comment #0)
> ```
> import std.stdio;
> import std.conv;
> void main(string[] argv)
> {
> int x = to!(int)(argv[1]);
> switch (x) {
> case 1:
> writeln("From 1");
> case 2:
> writeln("From 2");
> x = 3;
> break;
> case 3:
> x = 4;
> default:
> break;
> }
> 
> writeln("x = ", x);
> }
> ```
> ```
> $ rdmd test.d 1
> From 1
> From 2
> x = 3
> ```

DMD v2.071.0

--

July D Boston Meetup gathering


Just announced. If you are in the area, come join us!

http://www.meetup.com/Boston-area-D-Programming-Language-Meetup/events/231887464/

-Steve

[Issue 16173] New: Implicit fall through is silently allowed

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

  Issue ID: 16173
   Summary: Implicit fall through is silently allowed
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: 4bur...@gmail.com

```
import std.stdio;
import std.conv;
void main(string[] argv)
{
int x = to!(int)(argv[1]);
switch (x) {
case 1:
writeln("From 1");
case 2:
writeln("From 2");
x = 3;
break;
case 3:
x = 4;
default:
break;
}

writeln("x = ", x);
}
```
```
$ rdmd test.d 1
>From 1
>From 2
x = 3
```

--

[Issue 15932] Get rid of the implicit slicing of static arrays

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

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

   What|Removed |Added

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

--

Re: Andrei's list of barriers to D adoption

2016-06-14 Thread Peter Lewis via Digitalmars-d

As someone learning D, I thought I would give my insight in how I 
came to D.


My biggest reason for choosing D is the GC. I have come from Java 
and don't quite believe that I'm ready to manage my own memory 
throughout an entire program, but the ability to disconnect from 
the GC is a great way to start. I'm not saying that D should be a 
stopgap language, it has far too much potential for that.


I think that D definitely has many positives but that there is 
still work that needs to go into it. But all languages need work, 
no language is perfect.


I don't have much insight onto how the long term development and 
goals have gone, but I see that D is moving in a good direction 
and hope it will be around for many years to come. I also wish 
that D would have a wider adoption.


As it goes for tools. I agree work needs to be done on them but 
that it is not as important as a well done, competent compiler 
set and great documentation. D has great docs, and a quite 
competent compiler group.

Re: short programme from "Programming in D" by Ali Cehreli.

2016-06-14 Thread Ali Çehreli via Digitalmars-d-learn

On 06/14/2016 04:52 AM, Nick B wrote:

> Thanks for the assistance. I assumed that the compiler  would at least
> throw a line number, to hint at where the problem was.

Further, when the format string is a literal like the one used in the 
program, the compiler can in theory determine at compile time that the 
format string does not match the rest of the arguments:

readf (" %s, ");
// "No argument for %s"

This is a desired feature but dmd does not have this yet. Since dmd 
provides the front end to gdc and ldc, they don't have this feature either.

Ali

[Issue 15704] @safe code should not allow copying to/from void[]

2016-06-14 Thread Joerg Joergonson via Digitalmars-d-learn

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

--- Comment #4 from hst...@quickfur.ath.cx ---
Oh, you're right, it doesn't compile because implicit conversion from void[] to
int*[] is not allowed.  OK, nevermind what I said, then. :-D

--

Strange Issues regarding aliases


I have stuff like


public static class fGL
{
nothrow @nogc extern(System)
{
alias CullFace = void function(tGL.Enum);
alias FrontFace = void function(tGL.Enum);
alias HInt = void function(tGL.Enum, tGL.Enum);
alias LineWidth = void function(tGL.Float);
alias PoIntSize = void function(tGL.Float);
...
}
}


public static struct tGL
{
alias Void = void;
alias IntPtr = ptrdiff_t;
alias SizeInt = int;
alias Char = char;
alias CharARB = byte;
alias uShort = ushort;
alias Int64EXT = long;
alias Short = short;
alias uInt64 = ulong;
alias HalfARB = ushort;
alias BlendFunc = void function(tGL.Enum, tGL.Enum);
...

__gshared {
CopyTexImage1D glCopyTexImage1D;
TextureParameterf glTextureParameterf;
VertexAttribI3ui glVertexAttribI3ui;
VertexArrayElementBuffer glVertexArrayElementBuffer;
BlendFunc glBlendFunc;
...
}


public struct eGL
{
enum ubyte FALSE = 0;
enum ubyte TRUE = 1;
enum uint NO_ERROR = 0;
enum uint NONE = 0;
enum uint ZERO = 0;
enum uint ONE = 1;
...
}


And when I use this stuff(which is clearly openGL being cleaned 
up a bit(I know I can use modules to essentially do this too but 
that is irrelevant):


I get errors like


Error: null has no effect in expression (null)  

Error: more than one argument for construction of extern 
(Windows) void function(uint, uint) nothrow @nogc	



This is when using it like

fGL.BlendFunc(eGL.SRC_ALPHA, eGL.ONE_MINUS_SRC_ALPHA);

What's going on? Please no responses about "You are going to run 
into a lot of problems since all the openGL code uses the flat 
accessing"... The whole point is to get away from that ancient 
way and backwards way.

[Issue 15704] @safe code should not allow copying to/from void[]

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

Steven Schveighoffer  changed:

   What|Removed |Added

 CC||schvei...@yahoo.com

--- Comment #3 from Steven Schveighoffer  ---
(In reply to hsteoh from comment #2)
> It's not just writing to void[] that's the problem. Consider:
> 
> 
> int[] intArr = [ 1,2,3,4,5 ];
> void[] voidArr = intArr; // OK, every array converts to void[]
> int*[] ptrArr;
> ptrArr.length = 5;
> ptrArr[] = voidArr[]; // reinterpret intArr as pointers

Wait, does this really work (I didn't think it did)? If so, isn't it still
implicitly doing this:

(cast(void[])ptrArr)[] = voidArr[];

Which is still writing void data.

--

Re: Are __gshared globals gc scanned?

2016-06-14 Thread H. S. Teoh via Digitalmars-d-learn

On Tue, Jun 14, 2016 at 02:04:15PM +, Tofu Ninja via Digitalmars-d-learn 
wrote:
> On Tuesday, 14 June 2016 at 13:53:10 UTC, ketmar wrote:
> > __gshared globals are gc scanned.
> 
> Ah cool, thanks
> I had to login to my work computer just to read your answer lol

What, you mean you can't just read and execute arbitrarily complex
regexes in your head?!

;-)


T

-- 
Never wrestle a pig. You both get covered in mud, and the pig likes it.

[Issue 15704] @safe code should not allow copying to/from void[]

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

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

   What|Removed |Added

Summary|@safe code should not allow |@safe code should not allow
   |copying into void[] |copying to/from void[]

--

[Issue 15704] @safe code should not allow copying into void[]

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

--- Comment #2 from hst...@quickfur.ath.cx ---
It's not just writing to void[] that's the problem. Consider:


int[] intArr = [ 1,2,3,4,5 ];
void[] voidArr = intArr; // OK, every array converts to void[]
int*[] ptrArr;
ptrArr.length = 5;
ptrArr[] = voidArr[]; // reinterpret intArr as pointers
ptrArr[0] = 1; // oops


Basically, *anything* that leads to reinterpretation of something as pointer
values cannot be allowed in @safe.

--

[Issue 16073] Ranges without opDollar not supported

2016-06-14 Thread Andrei Alexandrescu via Digitalmars-d-announce

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

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

https://github.com/dlang/phobos/commit/94d74ac8f5772e3e32f7c2e2b4b59fd0783a6ad5
[Issue 16073] Fix incorrect uses of random access range primitives in
std.algorithm.sorting

https://github.com/dlang/phobos/commit/c5bb43ce54d7feb244ba032c43aecd7aa7c9356a
Merge pull request #4425 from JackStouffer/issue16073

Partial Fix for Issue 16073 (part 2)

--

Re: dlang-requests 0.1.7 released


On 6/11/16 7:03 PM, ikod wrote:

Hello,

Dlang-requests is library created under influence of Python-requests,
with primary goal of easy to use and performance.

It provide interfaces for HTTP(S) and FTP requests. You can tune request
details, but for most cases you will need single and simple API call.

Latest release added streaming content from server and some performance
improvements (avoiding some of unnecessary buffer copying).

Code and docs available at https://github.com/ikod/dlang-requests or as
dub package.

Thanks Dlang authors and community for excellent language.


Thanks! Does the project have a dub presence? How does it compare 
feature-wise and speed-wise with curl? -- Andrei

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

2016-06-14 Thread Andrei Alexandrescu via Digitalmars-d-announce


On 6/12/16 8:27 PM, Walter Bright wrote:

On 5/30/2016 12:16 PM, Jason White wrote:

Here is an example build description for DMD:

https://github.com/jasonwhite/dmd/blob/button/src/BUILD.lua

I'd say that's a lot easier to read than this crusty thing:

https://github.com/dlang/dmd/blob/master/src/posix.mak


Yes, the syntax looks nice.


Cool. Difference in size is also large. Do they do the same things? -- 
Andrei

Re: nested inout return type

2016-06-14 Thread Steven Schveighoffer via Digitalmars-d-learn


On 6/14/16 9:22 AM, Simon Bürger wrote:

On Tuesday, 14 June 2016 at 01:50:17 UTC, Era Scarecrow wrote:

On Monday, 13 June 2016 at 23:51:40 UTC, Era Scarecrow wrote:

 inout(Slice) opSlice(size_t a, size_t b) inout
 {
 return cast(inout(Slice)) Slice(ptr+a, b-a);
 }


 Seems the pointer has to be force-cast back to a normal pointer so
the constructor can work. (Because the function is inout, ptr becomes
inout(T*) )

 return cast(inout(Slice)) Slice(cast(T*)ptr+a, b-a);


Better: inout(Slice)(ptr+a, b-a);


Then instead of Slice!(const(T)) one would use const(Slice!T). Then
there is no analogue of the following:

const(T)[] s = ...
s = s[5..7]


Yes, this is a missing piece of the language. In order to use custom 
types, you must give up tail modifiers.



which is quite common when parsing strings for example. Still, might be
the cleanest approach. However I found another solution for now without
using any "inout":

* only do one mutable version of opSlice
* add implicit cast (using "alias this") for const(Slice!T) ->
Slice!(const(T)).


Interesting, but unfortunately, the compiler isn't eager about this 
conversion. auto x = s[5 .. 7] isn't going to give you a 
Slice!(const(T)), like an array would. But I like the idea.


And of course, there is the issue of not allowing structs with inout 
members. So really you need to triplicate the function for all the 
modifiers. And of course, alias this can only be used once...


-Steve

Re: GTKD - Attach Button to Grid in specific column and row

2016-06-14 Thread TheDGuy via Digitalmars-d-learn


On Saturday, 11 June 2016 at 21:14:43 UTC, Mike Wey wrote:
The way GTK manages width and height, usually widgets are given 
the minimum size they need. So when the button is the only 
widget in the grid the other rows and columns have a 
height/width of 0.


You can force the button / gird cell to the bottom left by 
setting the expand and alignment properties of the button.


this(int width, int height, string title){
super(title);
setDefaultSize(width,height);

Button btn = new Button();
btn.setSizeRequest(25,25);
btn.setLabel("Exit");
btn.setVexpand(true);
btn.setHexpand(true);
btn.setHalign(Align.END);
btn.setValign(Align.END);
auto call = 
btn.addOnEnterNotify(call);
btn.addOnLeaveNotify(call);

Grid grid = new Grid();
grid.setColumnSpacing(6);
grid.setRowSpacing(6);
grid.attach(btn,3,3,1,1);
add(grid);

showAll();
}


Thanks for your reply, but now the button is always on the bottom 
right :(


this(int width, int height, string title){
super(title);
setDefaultSize(width,height);

Button btn = new Button();
btn.setSizeRequest(25,25);
btn.setLabel("Exit");
btn.setVexpand(true);
btn.setHexpand(true);
btn.setHalign(Align.END);
btn.setValign(Align.END);

Grid grid = new Grid();
grid.setColumnSpacing(6);
grid.setRowSpacing(6);
grid.attach(btn,4,4,1,1);
add(grid);
showAll();
}

Re: short programme from "Programming in D" by Ali Cehreli.

2016-06-14 Thread Steven Schveighoffer via Digitalmars-d-learn


On 6/14/16 7:52 AM, Nick B wrote:

On Tuesday, 14 June 2016 at 09:53:03 UTC, cym13 wrote:

On Tuesday, 14 June 2016 at 09:39:05 UTC, Nick B wrote:

On Tuesday, 14 June 2016 at 09:28:18 UTC, cym13 wrote:

On Tuesday, 14 June 2016 at 09:17:35 UTC, Nick B wrote:

Hi, Can anyone assist me with the short D programme. It is taken
straight from  "Programming in D" by Ali Cehreli.  The code below
is the solution,  on page 684.
The  Exercise is on Page 27, item 2 half way down the page.

[snip]



It then printed as much of a stack trace as it could, not very useful
as you didn't do much but it's there.

You gave it garbage and it threw an error. Compiler bugs are a reality
but not *that* common ;-)


Thanks for the assistance. I assumed that the compiler  would at least
throw a line number, to hint at where the problem was.



You should see a stack trace. I'm not normally on windows, so I don't 
know the proper mechanism to enable stack traces, but on OSX, it looks 
like this:


object.Exception@/Users/steves/.dvm/compilers/dmd-2.071.0/osx/bin/../../src/phobos/std/format.d(596): 
Trailing characters in formattedRead format string


4   testdice0x0001013a2357 pure @safe 
void std.exception.bailOut!(Exception).bailOut(immutable(char)[], ulong, 
const(char[])) + 123
5   testdice0x0001013a22d0 pure @safe 
bool std.exception.enforce!(Exception, bool).enforce(bool, lazy 
const(char)[], immutable(char)[], ulong) + 100
6   testdice0x0001013a0978 uint 
std.format.formattedRead!(std.stdio.LockingTextReader, 
char).formattedRead(ref std.stdio.LockingTextReader, const(char)[]) + 124
7   testdice0x0001013a08b9 uint 
std.stdio.File.readf!().readf(const(char[])) + 197
8   testdice0x0001013a07ea uint 
std.stdio.readf!().readf(const(char[])) + 38

9   testdice0x0001013a0264 _Dmain + 52
10  testdice0x0001013c07eb 
D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv + 39
11  testdice0x0001013c071f void 
rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) + 35
12  testdice0x0001013c0790 void 
rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).runAll() + 44
13  testdice0x0001013c071f void 
rt.dmain2._d_run_main(int, char**, extern (C) int 
function(char[][])*).tryExec(scope void delegate()) + 35

14  testdice0x0001013c0685 _d_run_main + 497
15  testdice0x0001013a037f main + 15
16  libdyld.dylib   0x7fff987e75ac start + 0
17  ??? 0x 0x0 + 0

No line numbers, but at least I can see the call stack.

-Steve

Re: How to call one static method from another?

2016-06-14 Thread Steven Schveighoffer via Digitalmars-d-learn


On 6/14/16 6:08 AM, pineapple wrote:

On Tuesday, 14 June 2016 at 07:35:36 UTC, Andrea Fontana wrote:

Simply:
method2();


Also, typeof(this).method2();



Yes, if you want to distinguish between another function named method2.

-Steve

Re: how to get rid of "cannot deduce function from argument types" elegantly

2016-06-14 Thread Steven Schveighoffer via Digitalmars-d-learn


On 6/14/16 6:05 AM, pineapple wrote:

On Monday, 13 June 2016 at 22:54:13 UTC, Ali Çehreli wrote:

Tree!T tree(TL, T, TR)(TL left, T node, TR right) {
  return new Tree!T(left, node, right);
}



There's also this:

Tree!T tree(TL, T, TR)(TL left, T node, TR right) if(
(is(TL == Tree!T) || is(TL == typeof(null))) &&
(is(TR == Tree!T) || is(TR == typeof(null)))


Alternative: if(is(typeof({Tree!T x = TL.init; x = TR.init; })))

This may seem similar, but actually can accept things that convert to 
Tree!T as well.


The issue with the OP code is that the compiler is trying to match T 
with the two null parameters, and can't work out the deduction.


-Steve

Re: Are __gshared globals gc scanned?

2016-06-14 Thread Tofu Ninja via Digitalmars-d-learn


On Tuesday, 14 June 2016 at 13:53:10 UTC, ketmar wrote:

__gshared globals are gc scanned.


Ah cool, thanks
I had to login to my work computer just to read your answer lol

Re: Are __gshared globals gc scanned?

2016-06-14 Thread Adam D. Ruppe via Digitalmars-d-learn


On Tuesday, 14 June 2016 at 13:53:10 UTC, ketmar wrote:

cat $subj | sed -r 's/^Are (.+) (gc.+)\?$/\1 are \2./'


lol nice answer


so yeah they are scanned for pointers just like anything else 
(meaning if they contain no pointers they are not scanned!) but 
remember globals never go out of scope so things referenced in 
them will not be collected until end of program run (if even then)

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


On Tuesday, 14 June 2016 at 10:39:01 UTC, Nordlöw wrote:
Have you thought about extending checkedint to something 
similar to bounded integer wrapper type like my `bound.d`?


I spent some time studying the possibility of a `BoundInt` type. 
Some conclusions I reached:


   1) Designing and implementing `BoundInt` to my standards for 
quality and
  performance would be a large project of similar magnitude 
to what has
  already been done on `checkedint`, which took me about a 
year. (And I

  was building on the earlier work of @burner and others.)

   2) `BoundInt` is not a replacement for `SafeInt` or 
`SmartInt`, although

  they would likely share some parts of the implementation.

   3) Adding `BoundInt` later should not require any breaking 
changes to the

  public API of `checkedint`.

   4) Pervasive, natural use of `BoundInt` in large systems (like 
Phobos)
  may cause *awful* template bloat issues, depending on the 
design used.
  (Improvements to the compiler front-end could mitigate this 
issue, in

  the long run.)

Given the above, I believe we should move forward with 
`checkedint` as-is. Someone can add a `BoundInt` type to it 
later, if there is demand.

Re: Are __gshared globals gc scanned?

2016-06-14 Thread ketmar via Digitalmars-d-learn


cat $subj | sed -r 's/^Are (.+) (gc.+)\?$/\1 are \2./'

Are __gshared globals gc scanned?

2016-06-14 Thread Tofu Ninja via Digitalmars-d-learn


Title says it all...

Re: Fixed date to move to ddox for Phobos documentation

2016-06-14 Thread Andrei Alexandrescu via Digitalmars-d


On 6/13/16 9:41 PM, Vladimir Panteleev wrote:

On Tuesday, 14 June 2016 at 00:31:56 UTC, Andrei Alexandrescu wrote:

Walter or Jan should be able to do that. But I'm confused as to how
NNTP groups would help here.


It would allow people to subscribe and reply to comments using their
newsreader (or by email, if it's also associated with a mailing list on
Brad's server). It's one of the bigger reasons to consider using DFeed.


Aren't the snazzy nice formatting and the display in the page the nicest 
things about on-doc-page comments? Email subscription to such is fine 
but writing via email or NNTP seems a clunky adaptation. BTW does disqus 
allow D syntax coloring? -- Andrei

[Issue 11176] array.ptr in @safe code may point past end of array