Re: Voting For std.experimental.ndslice

[Jack Stouffer via Digitalmars-d]

On Monday, 28 December 2015 at 14:42:43 UTC, Ilya Yaroshenko 
wrote:

On Monday, 28 December 2015 at 11:13:57 UTC, Martin Nowak wrote:
We're branching for 2.070 soon, would be nice if this can make 
it, but only if it's really ready.


Whooohooo!

Thanks!

Ilya


I'm writing a blog post giving an overview of std.ndslice and 
comparing and contrasting to Numpy, to be released when this is 
merged, and I was wondering if I can have your permission to 
include your great image processing example in the post?

Re: Voting For std.experimental.ndslice

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 29 December 2015 at 16:28:52 UTC, Robert burner 
Schadek wrote:
On Tuesday, 29 December 2015 at 16:11:00 UTC, Ilya Yaroshenko 
wrote:


OK, lets discuss every function.



That is acceptably the problem. It is not about the 
documentation of the functions it is about the documentation 
binding the functions together and the documentation giving the 
idea of the library.


OK, looks like I understand you.

My style of exploration is set of examples. For some people it is 
much better. But I agree that it may be bad for others.


About `iteration` module:

1. from documentation:
--
Operators only change strides and lengths of a slice. The range 
of a slice remains unmodified. All operators return slice of the 
same type as the type of the argument.

--
2. They are very simple functions, and their combination is 
simple too. A user will understand how to use them. Furthermore 
`Binary representation` section in `Slice` docs has examples with 
`transposed` and `reversed`. So user can understand what exactly 
going on with iteration functions.



About selection module:

1. from documentation:
--
Selectors create new views and iteration patterns over the same 
data, without copying.


Subspace selectors
- - -
Subspace selectors serve to generalize and combine other 
selectors easily. For a slice of Slice!(N, Range) type 
slice.pack!K creates a slice of slices of Slice!(N-K, Slice!(K+1, 
Range)) type by packing the last K dimensions of the top 
dimension pack, and the type of element of slice.byElement is 
Slice!(K, Range). Another way to use pack is transposition of 
dimension packs using evertPack. Examples of use of subspace 
selectors are available for selectors, Slice.shape , and 
Slice.elementsCount .

--

2. Selectors look simple, but their combinations can be _very_ 
crazy. Combination of this functions is art of imagination. I am 
not so talented writer to create good documentation. The problem 
here is that I have never discuss this module with significant 
amount of people. And I don't think that I will have such 
opportunity. So what I have done with documentation for 
selectors? I created cross examples:


`unpack` has examples with
  - `pack`
`evertPack` has examples with
  - `pack`
  - `unpack`
`diagonal` has examples with
  - `dropOne`
  - `dropToHypercube`
  - `reversed`
  - `pack`
  - `evertPack`
  - Note about additional examples with `blocks` and `windows`
`blocks` has examples with
  - `byElement`
  - `diagonal`
  - `pack`
  - `evertPack`
  - `unpack`
`windows` has examples with
  - `byElement`
  - `diagonal`
  - `pack`
  - `evertPack`
  - `unpack`
`byElement` has examples with
  - `pack`
  - `drop`
  - `std.range.retro`
  - `allReversed`
`byElementInStandardSimplex` has examples with
  - `allReversed `
  - `transposed`
`indexSlice` has examples with
  - `byElement`

In addition, example `Image Processing` in `package` description 
is a real world combination of `sliced`, `pack`, `windows`, 
`unpack`, `byElement`, `std.algorithm.iteration.map`, 
`std.array.array`,  `Slice.shape`.


This is a way how I can write documentation. I don't think that I 
can write using style you want or find someone who can do it 
instead of me. I am already spend a lot of time with English 
translator to improve docs. And every new sentence is a real 
pain, because I need to ask my translator to check it.


Ilya

Re: Voting For std.experimental.ndslice

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 29 December 2015 at 18:08:52 UTC, Andrei Alexandrescu 
wrote:

On 12/29/2015 11:28 AM, Robert burner Schadek wrote:
On Tuesday, 29 December 2015 at 16:11:00 UTC, Ilya Yaroshenko 
wrote:


OK, lets discuss every function.



That is acceptably the problem. It is not about the 
documentation of the
functions it is about the documentation binding the functions 
together

and the documentation giving the idea of the library.


Hopefully this is something that you or someone else could help 
by creating pull requests. Any volunteers? -- Andrei


Collection of posts like Jack Stouffer is writing will bring an 
understanding of how to improve docs. Currently we can collect 
links of such posts for a while and store them on package 
description page, thought.


YouTube has 7.5K videos for "numpy" query.

Ilya

virtual destructor in C++ integration: bug or me being stupid?

[Atila Neves via Digitalmars-d-learn]

cpp.cpp:

class Oops {
public:

virtual ~Oops() {}
virtual int number() const { return 42; }
};

Oops* newOops() {
return new Oops;
}

d.d:

import std.stdio;


extern(C++) {
interface Oops {
int number() const;
}
Oops newOops();
}

void main() {
auto oops = newOops();
writeln(oops.number());
}


I get garbage in the output (I found this due to a crash in much 
more complicated code). If I comment out the virtual destructor, 
it works.


It seems that the presence of the virtual destructor changes the 
layout and D doesn't know about it. Thinking about it now, it 
makes sense, how would D know?


The problem here is that I don't know what the workaround is. 
Abstract classes in C++ usually have virtual destructors...


Atila

Re: pl0stuff an optimizing pl0 > c transcompiler

[Stefan Koch via Digitalmars-d-announce]

On Tuesday, 29 December 2015 at 04:37:44 UTC, Nick B wrote:

Would you know what is required to get good performance ?


I can guess. However without actually implementing it my guess is 
as good as any.
I would probably look at HHVM, and see what is easy to 
reimplement in D.

Re: virtual destructor in C++ integration: bug or me being stupid?

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

On Tuesday, 29 December 2015 at 18:32:23 UTC, Atila Neves wrote:

The problem here is that I don't know what the workaround is.


The one I used (well, last time I tried this) was to just put a 
dummy function in the D interface that is a placeholder for it.


interface C++Class {
   // at the same place as
   void _dontCallMeIamjustadestructor();
   void other_function_you_actually_want();
}

Re: Voting For std.experimental.ndslice

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 29 December 2015 at 17:17:05 UTC, Jack Stouffer wrote:
On Monday, 28 December 2015 at 14:42:43 UTC, Ilya Yaroshenko 
wrote:
On Monday, 28 December 2015 at 11:13:57 UTC, Martin Nowak 
wrote:
We're branching for 2.070 soon, would be nice if this can 
make it, but only if it's really ready.


Whooohooo!

Thanks!

Ilya


I'm writing a blog post giving an overview of std.ndslice and 
comparing and contrasting to Numpy, to be released when this is 
merged, and I was wondering if I can have your permission to 
include your great image processing example in the post?


Thank you for doing this!

Yes, you can get any examples! `movingWindowByChannel` is a good 
function, however small function `median` can be improved, but it 
is not easy to do it for small filter sizes. You may want to use 
convolution matrices such as the Sobel operator or Gaussian blur 
instead of `median`. They will work faster comparing with 
`median`.  Another option is a note that `median` can be 
significantly optimised.


^^ Many thanks!

Ilya

[Issue 15483] static if prevents inlining

[via Digitalmars-d-bugs]

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

--- Comment #1 from thomas.bock...@gmail.com ---
Perhaps related: https://issues.dlang.org/show_bug.cgi?id=15159

--

[Issue 15483] New: static if prevents inlining

[via Digitalmars-d-bugs]

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

  Issue ID: 15483
   Summary: static if prevents inlining
   Product: D
   Version: D2
  Hardware: x86_64
OS: Linux
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: thomas.bock...@gmail.com

module app;

void main() {
import std.stdio;

inlineme1(true);

inlineme2(true); // Error: function app.inlineme2 cannot inline function
}

@safe pragma(inline, true) {
bool inlineme1(bool left)
{
if(left)
return true;

return false;
}

bool inlineme2(bool left)
{
if(left)
return true;

static if(false)
{
/*
Even though it does absolutely nothing,
the mere presence of this block prevents inlining
of this function.
*/
}

return false;
}
}

This issue has been giving me a lot of trouble while working on checkedint, for
which inlining is critical to getting good performance.

I keep writing template functions which, if I instantiate the template by hand,
will inline fine, but refuse to do so if I let the compiler instantiate it for
me. I really don't want to be stuck using string mixins everywhere...

--

Re: Voting For std.experimental.ndslice

[Andrei Alexandrescu via Digitalmars-d]

On 12/29/2015 11:28 AM, Robert burner Schadek wrote:

On Tuesday, 29 December 2015 at 16:11:00 UTC, Ilya Yaroshenko wrote:


OK, lets discuss every function.



That is acceptably the problem. It is not about the documentation of the
functions it is about the documentation binding the functions together
and the documentation giving the idea of the library.


Hopefully this is something that you or someone else could help by 
creating pull requests. Any volunteers? -- Andrei

Re: Better docs for D (WIP)

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

On Tuesday, 29 December 2015 at 14:26:48 UTC, Rikki Cattermole 
wrote:
Okay, I remember you saying something a bit different on IRC 
(at least to my understanding).


Well, I'm still a bit iffy on it, to attach a name I used the 
first member of the enum which might not pass review muster in 
dmd itself, but you could also probably just generate a random 
name for it.


Actually, I think dmd *does* generate random names for anonymous 
enums internally anyway. I know it does for structs and functions 
etc.


dmd could probably get away without a name too, since it doesn't 
care about SEO and linking, whereas I do.


But regardless, I'm sure it is technically possible, I'm just not 
sure the dmd maintainers wouldn't reject it as a pointless hack 
in their eyes.

Re: Voting For std.experimental.ndslice

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 29 December 2015 at 15:42:32 UTC, Robert burner 
Schadek wrote:
On Monday, 28 December 2015 at 22:39:45 UTC, Ilya Yaroshenko 
wrote:


1. First paragraph was replaced by your variant.
2. Binary representation was moved to Slice type documentation.
3. Small "Quick Start" was added, so new user will start from 
`sliced` and `Slice`.


That is just patchwork ...

The style of writing I presented should be used throughout the 
documentation so people know what everything is and how it 
works together.


OK, lets discuss every function.

Fist is `transposed`:

---
N-dimensional transpose operator. Brings selected dimensions to 
the first position.


Parameters:
Slice!(N, Range) slice  input slice
Dimensions	indexes of dimensions to be brought to the first 
position


Returns:
n-dimensional slice of the same type
See Also:
swapped, everted


What is wrong with this documentation?

Re: Voting For std.experimental.ndslice

[Robert burner Schadek via Digitalmars-d]

On Tuesday, 29 December 2015 at 16:11:00 UTC, Ilya Yaroshenko 
wrote:


OK, lets discuss every function.



That is acceptably the problem. It is not about the documentation 
of the functions it is about the documentation binding the 
functions together and the documentation giving the idea of the 
library.

[Issue 15159] Static nested function prevent inlining

[via Digitalmars-d-bugs]

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

thomas.bock...@gmail.com changed:

   What|Removed |Added

 CC||thomas.bock...@gmail.com

--- Comment #1 from thomas.bock...@gmail.com ---
Perhaps related: https://issues.dlang.org/show_bug.cgi?id=15483

--

Re: reduce a BitArray[]

[Alex Parrill via Digitalmars-d-learn]

On Tuesday, 29 December 2015 at 09:26:31 UTC, Alex wrote:
The problem is, that the last line with the reduce does not 
compile. Why?


If you get an error, it is imperative that you tell us what it is.

For the record, this code:

import std.bitmanip;
import std.stdio;
import std.algorithm;

void main() {

		BitArray[] arr7 = [BitArray([0, 1, 0, 1, 0, 1]), BitArray([0, 
1, 0, 0, 0, 0]), BitArray([0, 1, 0, 1, 0, 0]), BitArray([0, 1, 0, 
1, 0, 0])];


BitArray common = BitArray([1,1,1,1,1,1]);
foreach(BitArray ba; arr7)
{
common &=  ba;
}
writeln("common2: ", common);

writeln("common1: ", reduce!((a,b) => a & b)(arr7));
}

Gives me the error:

/opt/compilers/dmd2/include/std/algorithm/iteration.d(2570): 
Error: variable f868.main.F!(__lambda1).e cannot be declared to 
be a function
/opt/compilers/dmd2/include/std/meta.d(546): Error: template 
instance f868.main.F!(__lambda1) error instantiating
/opt/compilers/dmd2/include/std/algorithm/iteration.d(2477):  
  instantiated from here: staticMap!(ReduceSeedType, __lambda1)
/d486/f868.d(16):instantiated from here: 
reduce!(BitArray[])
/d486/f868.d(16): Error: template std.algorithm.iteration.reduce 
cannot deduce function from argument types !((a, b) => a & 
b)(BitArray[]), candidates are:
/opt/compilers/dmd2/include/std/algorithm/iteration.d(2451):  
  std.algorithm.iteration.reduce(fun...) if (fun.length >= 1)


On 2.069.1 (dpaste: http://dpaste.dzfl.pl/8d7652e7ebeb). I don't 
have time ATM to diagnose it further. It definitely shouldn't be 
that cryptic of an error message.

Re: Voting For std.experimental.ndslice

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 29 December 2015 at 14:51:37 UTC, Márcio Martins 
wrote:
On Tuesday, 29 December 2015 at 13:54:56 UTC, Jack Stouffer 
wrote:
On Tuesday, 29 December 2015 at 13:30:47 UTC, Márcio Martins 
wrote:
If I am reading the code right, the number of dimensions must 
always be known at compile time, right?


Not necessarily. The dimensions for this slice are computed at 
runtime.


```
auto slice = 1000.iota.sliced(5, 6, 7);
```


```

With this declaration:

```
struct Slice(size_t _N, _Range)
```
_N, the number of dimensions, must necessarily be known at 
compile-time, right?


Yes. -- Ilya

Re: Voting For std.experimental.ndslice

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 29 December 2015 at 13:30:47 UTC, Márcio Martins 
wrote:
On Tuesday, 29 December 2015 at 07:45:14 UTC, Ilya Yaroshenko 
wrote:
On Monday, 28 December 2015 at 22:39:45 UTC, Ilya Yaroshenko 
wrote:
On Monday, 28 December 2015 at 21:43:35 UTC, Robert burner 
Schadek wrote:

[...]


Agreed

1. First paragraph was replaced by your variant.
2. Binary representation was moved to Slice type 
documentation.
3. Small "Quick Start" was added, so new user will start from 
`sliced` and `Slice`.


http://dtest.thecybershadow.net/artifact/website-76234ca0eab431527327d5ce1ec0ad74c6421533-081dd6e9e8b3810a143d0a5fcba8d60b/web/phobos-prerelease/std_experimental_ndslice.html

Thanks!

Ilya


Fix English: 
http://dtest.thecybershadow.net/artifact/website-76234ca0eab431527327d5ce1ec0ad74c6421533-bfed2500425eb407bf2c97fc72e8a0c5/web/phobos-prerelease/std_experimental_ndslice.html


If I am reading the code right, the number of dimensions must 
always be known at compile time, right? Is so, I suppose it was 
a performance-oriented decision and not an oversight, correct?


This package is performance oriented. In the same time it is more 
flexible comparing with numpy.


Simple optimisation check:
Source: https://gist.github.com/9il/bc7966823d96557c566c
LDC disassembled: 
https://gist.github.com/9il/47aea1621a9fba609869 (all functions 
are inlined)

Re: reduce a BitArray[]

[Daniel Kozak via Digitalmars-d-learn]

V Tue, 29 Dec 2015 17:42:26 +
Alex Parrill via Digitalmars-d-learn
 napsáno:

> On Tuesday, 29 December 2015 at 09:26:31 UTC, Alex wrote:
> > The problem is, that the last line with the reduce does not 
> > compile. Why?  
> 
> If you get an error, it is imperative that you tell us what it is.
> 
> For the record, this code:
> 
>   import std.bitmanip;
>   import std.stdio;
>   import std.algorithm;
>   
>   void main() {
>   
>   BitArray[] arr7 = [BitArray([0, 1, 0, 1, 0, 1]),
> BitArray([0, 1, 0, 0, 0, 0]), BitArray([0, 1, 0, 1, 0, 0]),
> BitArray([0, 1, 0, 1, 0, 0])];
>   
>   BitArray common = BitArray([1,1,1,1,1,1]);
>   foreach(BitArray ba; arr7)
>   {
>   common &=  ba;
>   }
>   writeln("common2: ", common);
>   
>   writeln("common1: ", reduce!((a,b) => a & b)(arr7));
>   }
> 
> Gives me the error:
> 
> /opt/compilers/dmd2/include/std/algorithm/iteration.d(2570): 
> Error: variable f868.main.F!(__lambda1).e cannot be declared to 
> be a function
> /opt/compilers/dmd2/include/std/meta.d(546): Error: template 
> instance f868.main.F!(__lambda1) error instantiating
> /opt/compilers/dmd2/include/std/algorithm/iteration.d(2477):  
>instantiated from here: staticMap!(ReduceSeedType, __lambda1)
> /d486/f868.d(16):instantiated from here: 
> reduce!(BitArray[])
> /d486/f868.d(16): Error: template std.algorithm.iteration.reduce 
> cannot deduce function from argument types !((a, b) => a & 
> b)(BitArray[]), candidates are:
> /opt/compilers/dmd2/include/std/algorithm/iteration.d(2451):  
>std.algorithm.iteration.reduce(fun...) if (fun.length >= 1)
> 
> On 2.069.1 (dpaste: http://dpaste.dzfl.pl/8d7652e7ebeb). I don't 
> have time ATM to diagnose it further. It definitely shouldn't be 
> that cryptic of an error message.

It is cause by this
https://dlang.org/phobos/std_bitmanip.html#.BitArray.init

So until it will be removed it will does not compile.

Problem is in
https://dlang.org/phobos/std_range_primitives.html#.ElementType
which is implementet as
template ElementType(R)
{
static if (is(typeof(R.init.front.init) T))
alias ElementType = T;
else
alias ElementType = void;
}

maybe rewriting this like:

template ElementType(R)
{
static if (is(typeof(R.init.front) T))
alias ElementType = T;
else
alias ElementType = void;
}


could help too

[Issue 15483] static if prevents inlining

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

[Issue 14255] Since DMD is used to build idgen, one can't have dmd.conf for dev and system wide.

[via Digitalmars-d-bugs]

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

--- Comment #7 from hst...@quickfur.ath.cx ---
https://github.com/D-Programming-Language/dmd/pull/5325

--

Unexpected ' ' when converting from type string to type int

[Michael S via Digitalmars-d-learn]

Hello,  thanks for stopping in. I am fuddling through some 
exercises on a certain website, and I have come across a very 
frustrating bug I can't seem to fix.


The Problem:
Given a square matrix of size N×N, calculate the absolute 
difference between the sums of its diagonals.


Sample Input:
3
11 2 4
4 5 6
10 8 -12

First line is N, and the expected result of this example is 15.
If I hardcode in the value for N, this code works just peachy. 
It's when I am trying to actually read in the value of the first 
line from stdin that I am having a problem.


I seem to be unable to convert the string input to an integer to 
use later on. The code:


import std.stdio, std.math, std.string, std.conv;

void main(){
auto matrix_size = readln;

//below I have commented out the offending call to to!int and 
replaced it with a hardcoded value 3 in order to force it to work.

auto ms = 3;//matrix_size.to!int;
int[][] matrix = new int[][ms];
for(int i = 0; i < ms; i++){
string[] string_nums = readln.split;
foreach (num; string_nums){
auto value = num.to!int;
matrix[i] ~= value;
}
}

int primary_sum = 0;
int secondary_sum = 0;
int j = 0;
int i = ms - 1;
//determine diagonal sums
for(int row = 0; row < ms; ++row){
primary_sum += matrix[row][j];
secondary_sum += matrix[row][i];
++j;
--i;
}
auto result = abs(primary_sum - secondary_sum);
result.writeln;
}

Re: Unexpected ' ' when converting from type string to type int

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

On Wednesday, 30 December 2015 at 01:36:56 UTC, Michael S wrote:

auto matrix_size = readln;


Change that to

auto matrix_size = readln.strip;


and you should be in business. readln() returns any leading 
spaces and the newline character at the end of the line too, 
which is why to is throwing.


The .strip function will trim that whitespace off.

Re: Voting For std.experimental.ndslice

[MrSmith via Digitalmars-d]

On Tuesday, 29 December 2015 at 21:19:19 UTC, Jack Stouffer wrote:
On Tuesday, 29 December 2015 at 17:38:06 UTC, Ilya Yaroshenko 
wrote:
On Tuesday, 29 December 2015 at 17:17:05 UTC, Jack Stouffer 
wrote:

...
First draft: http://jackstouffer.com/hidden/nd_slice.html

Please critique.


Looks solid. Good work!

Re: Voting For std.experimental.ndslice

[Ilya Yaroshenko via Digitalmars-d]

On Tuesday, 29 December 2015 at 21:19:19 UTC, Jack Stouffer wrote:
On Tuesday, 29 December 2015 at 17:38:06 UTC, Ilya Yaroshenko 
wrote:
On Tuesday, 29 December 2015 at 17:17:05 UTC, Jack Stouffer 
wrote:
On Monday, 28 December 2015 at 14:42:43 UTC, Ilya Yaroshenko 
wrote:
On Monday, 28 December 2015 at 11:13:57 UTC, Martin Nowak 
wrote:
We're branching for 2.070 soon, would be nice if this can 
make it, but only if it's really ready.


Whooohooo!

Thanks!

Ilya


I'm writing a blog post giving an overview of std.ndslice and 
comparing and contrasting to Numpy, to be released when this 
is merged, and I was wondering if I can have your permission 
to include your great image processing example in the post?


Thank you for doing this!


First draft: http://jackstouffer.com/hidden/nd_slice.html

Please critique.


Awesome!

Please find my notes below.

The Basics
==

About `iota.front -> slice.font -> user accessing the data`:

1.
From the `sliced` documentation for `range` parameter: "only 
index operator auto `opIndex(size_t index)` is required for 
ranges".


See also recently added the last two examples for sliced 
http://dtest.thecybershadow.net/artifact/website-76234ca0eab431527327d5ce1ec0ad74c6421533-387174b023f8cb9612cfcddc76788896/web/phobos-prerelease/std_experimental_ndslice_slice.html#.sliced


The first one is for Input Range primitives, the second one is 
for Random Access Range primitives.


2.
Consequently `Slice` never invokes `front`, `popFront`, `empty`, 
and others range primitives. `Slice` invokes only 
`opIndex(size_t)`, and if `save` is defined, `slice.save` invokes 
`range.save`.


In addition, `sliced` can be used like Finite Random Access Range 
Constructor: user may define only `opIndex(size_t)` and `save` to 
make a Finite Random Access Range by calling `sliced`.


3.
If type of slice is `Slice!(3, Range)`, then `slice.front` do not 
invokes `range[indexToFront]`, it returns a slice type of 
`Slice!(2, Range)`.


In addition, `indexToFront` may not be zero, because primitives 
like `popFront` or operators like `reversed` may be called before.


For slices over arrays `indexToFront` is not defined because the 
pointer always refers to the first position: the pointer is moved 
when the slice changes.


For more details see also examples for Internal Binary 
Representation 
http://dtest.thecybershadow.net/artifact/website-76234ca0eab431527327d5ce1ec0ad74c6421533-387174b023f8cb9612cfcddc76788896/web/phobos-prerelease/std_experimental_ndslice_slice.html#.Slice


Getting Hands On
==
 - Please use "~>0.8.7" instead of "~>0.8.0". "~>0.8.7" has LDC 
0.17.0 alpha1 support.


Examples
==
 - A Basic Example With A Benchmark is not honest (difference 76 
is very large). To make it honest:
 1. Larger 100x1000 matrix can be used instead of 10x10, 
because numpy have a significant initialization overhead.
 2. Both `100_000.iota.sliced(100, 1000)` and 
`100_000.iota.array.sliced(100, 1000)` can be tested. The last 
one is with `std.array.array`. Memory access is expensive.
 3. Only iteration should be tested. Allocation and 
initilization should be separated from iteration both in D and 
Python.


   I expect smaller differnce in perfomance than 76 times.

 - You may want to test both DMD and LDC 0.17.0 alpha1 for 
bechmarks 
https://github.com/ldc-developers/ldc/releases/tag/v0.17.0-alpha1

   LDC 0.17.0 alpha1 works well with dip80-ndslice v0.8.7.

 - Python users love small code and they can be afraid to see 
large (template constraints)

   `mean` funciton.
   An example with lambda function can be added:
   ---
   auto means = 100_000.iota.sliced(100, 1).rotated(3).map!(r 
=> sum(r) / r.length);

   ---
   One line!

 - Nitpick: `transposed` (without params for 2D slice) is more 
clear than `rotated(3)`, IMO


 - `dub --build=release`can be added where you have noted dmd 
optimisation flags.


Numpy's Main Problem, and How D Avoids It
=
 - D version with allocation using `std.array.array` can be added 
(or just `new int[1000]`). The slice over `repeat` is not mutable 
(users from numpy world may expect that it is an array).


Ilya

Re: Better docs for D (WIP)

[Andrei Alexandrescu via Digitalmars-d-announce]

On 12/29/2015 10:20 AM, Adam D. Ruppe wrote:

On Tuesday, 29 December 2015 at 14:26:48 UTC, Rikki Cattermole wrote:

Okay, I remember you saying something a bit different on IRC (at least
to my understanding).


Well, I'm still a bit iffy on it, to attach a name I used the first
member of the enum which might not pass review muster in dmd itself, but
you could also probably just generate a random name for it.

Actually, I think dmd *does* generate random names for anonymous enums
internally anyway. I know it does for structs and functions etc.

dmd could probably get away without a name too, since it doesn't care
about SEO and linking, whereas I do.


Then why document it? If it's for SEO, what SEO scenarios woukd be 
covered by this feature that can't be done with simple workarounds? -- 
Andrei

Re: Better docs for D (WIP)

[Rikki Cattermole via Digitalmars-d-announce]

On 30/12/15 1:32 PM, Andrei Alexandrescu wrote:

On 12/29/2015 10:20 AM, Adam D. Ruppe wrote:

On Tuesday, 29 December 2015 at 14:26:48 UTC, Rikki Cattermole wrote:

Okay, I remember you saying something a bit different on IRC (at least
to my understanding).


Well, I'm still a bit iffy on it, to attach a name I used the first
member of the enum which might not pass review muster in dmd itself, but
you could also probably just generate a random name for it.

Actually, I think dmd *does* generate random names for anonymous enums
internally anyway. I know it does for structs and functions etc.

dmd could probably get away without a name too, since it doesn't care
about SEO and linking, whereas I do.


Then why document it? If it's for SEO, what SEO scenarios woukd be
covered by this feature that can't be done with simple workarounds? --
Andrei


The names are for anchors.
E.g. go jump to the comment / enum members.

Re: Voting For std.experimental.ndslice

[Ilya Yaroshenko via Digitalmars-d]

On Wednesday, 30 December 2015 at 00:24:38 UTC, Ilya Yaroshenko 
wrote:
On Tuesday, 29 December 2015 at 21:19:19 UTC, Jack Stouffer 
wrote:
On Tuesday, 29 December 2015 at 17:38:06 UTC, Ilya Yaroshenko 
wrote:
On Tuesday, 29 December 2015 at 17:17:05 UTC, Jack Stouffer 
wrote:

[...]


Thank you for doing this!


First draft: http://jackstouffer.com/hidden/nd_slice.html

Please critique.


Awesome!

Please find my notes below.
[...]
 - You may want to test both DMD and LDC 0.17.0 alpha1 for 
bechmarks 
https://github.com/ldc-developers/ldc/releases/tag/v0.17.0-alpha1

   LDC 0.17.0 alpha1 works well with dip80-ndslice v0.8.7.
[...]
Ilya


ldmd2/ldc2 flag -mcpu=native will optimise code for your CPU. -- 
Ilya

Re: vibe.d benchmarks

[Nick B via Digitalmars-d]

On Monday, 28 December 2015 at 13:10:59 UTC, Charles wrote:
On Monday, 28 December 2015 at 12:24:17 UTC, Ola Fosheim 
Grøstad wrote:

https://www.techempower.com/benchmarks/

The entries for vibe.d are either doing very poorly or fail to 
complete. Maybe someone should look into this?


Sönke is already on it.

http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/post/29110


Correct me if I am wrong here, but as far I can tell there is no 
independent benchmarks showing performance (superior or good 
enough) of D verses Go, or against just about any other language, 
as well  ?


https://www.techempower.com/benchmarks/#section=data-r11=peak=json=cnc=zik0vz-zik0zj-zik0zj-zik0zj-hra0hr

[Issue 14255] Since DMD is used to build idgen, one can't have dmd.conf for dev and system wide.

[via Digitalmars-d-bugs]

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

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

   What|Removed |Added

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

--

Re: Unexpected ' ' when converting from type string to type int

[Michael S via Digitalmars-d-learn]

On Wednesday, 30 December 2015 at 01:38:32 UTC, Adam D. Ruppe 
wrote:

On Wednesday, 30 December 2015 at 01:36:56 UTC, Michael S wrote:

auto matrix_size = readln;


Change that to

auto matrix_size = readln.strip;


and you should be in business. readln() returns any leading 
spaces and the newline character at the end of the line too, 
which is why to is throwing.


The .strip function will trim that whitespace off.


Wow thank you Adam. I didn't expect to have a reply so quickly, 
especially a slam dunk like that one. It works perfectly now!

Re: Better docs for D (WIP)

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

On Wednesday, 30 December 2015 at 00:32:31 UTC, Andrei 
Alexandrescu wrote:

Then why document it?


Just on principle, a documentation tool probably shouldn't be 
limiting the author's ability to document...


This might just be a bug in dmd btw. Looking at the ddoc spec 
page, it says "documentation comments not associated with a 
declaration are ignored", but it doesn't say the declaration must 
be named.


Perhaps dmd ought to be keeping it but isn't.


If it's for SEO, what SEO scenarios woukd be covered by this 
feature that can't be done with simple workarounds? -- Andrei


Putting one item per page is far more important than I even 
realized before getting into this. I was talking to a friend on 
Sunday night about his early adventures into D. He's managed to 
convert one of his work scripts that works with Google Docs to D 
and is working on transitioning a little web form program too.


He consistently found the dlang.org documentation to be 
undiscoverable and nearly unusable once he did find it. One 
example he gave as wondering if D had an Array.join function like 
Javascript.


He searched for "dlang array join" and first, of course, got "did 
you mean golang?". I like to joke about that being Google's bias, 
but I betcha it is actually more to do with our poor SEO than any 
nefarious code on their end.


The top two results he got were:

http://dlang.org/spec/arrays.html

which is no help, it talks about arrays but not the join function

and

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

which he thought was another false positive because it looked 
generic again. I told him it *is* the right page... but the wrong 
section. To actually get to the join function, you need to find 
it again in the table and hit that second link.



He spent more time than he should have and thought D didn't have 
an array.join function because the search engine didn't actually 
return it. It returned two pages that are vaguely related but not 
specifically what he wanted, and being used to more relevant 
search requests, wrote off the ddoc as a false positive despite 
it being the right page!


I asked people in the #d chatroom to repeat this experiment. 
Nobody even got http://dlang.org/phobos/std_array.html as the top 
result! Longer time D users did get 
http://dlang.org/library/std/array/join.html as a top result - 
good - but nobody actually got the official doc and the ddox only 
came to those with personalized search that ups the rank score of 
D related pages.



Contrast that to even the primitive results from my dpldocs.info 
D-specific search. Look for "array join" and get:



http://dpldocs.info/search/search2?searchTerm=array+join


Whoa, std.array.join is right at the top! And if you click it, 
you go directly to the relevant function doc.



That's huge.

[Issue 14255] Since DMD is used to build idgen, one can't have dmd.conf for dev and system wide.

[via Digitalmars-d-bugs]

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

--- Comment #6 from hst...@quickfur.ath.cx ---
Got bitten by this today. I have an old version of dmd for bootstrapping
purposes in /usr/src/d/install, and git checkout of dmd in /usr/src/d/dmd. This
setup used to work fine, except that recently, due to changes in
druntime/phobos, they no longer compile with the bootstrap version of dmd.

So the solution is to put a dmd.conf in /usr/src/d/install so that the old
compiler uses its own version of druntime/phobos, which it can compile. Now
/usr/src/d/dmd successfully compiles... except that now it can't link anything,
because it can't find the right dmd.conf, so it fails to find the correct
version of object.d.

Solution: put another dmd.conf in /usr/src/d/dmd so that the new compiler can
find the right paths, right? Yes, it works... however, now dmd cannot be
recompiled, because when posix.mak is running in /usr/src/d/dmd/src, it tries
to invoke HOST_DMD, and the old compiler picks up ./dmd.conf instead of the
correct one in /usr/src/d/install.  Worse, attempting to remedy this by
specifying -conf doesn't work, because posix.mak assumes HOST_DMD contains only
the pathname to the host dmd executable; any extra parameters appended to
HOST_DMD causes the existence check to fail and it refuses to run.

So now I'm stuck. The only way out I can see is to put dmd.conf in /etc or
$HOME, but that overrides the system-wide dmd.conf. So this is not workable
either.

I need a way to tell posix.mak to run HOST_DMD with additional flags. Is there
a way to do this??

--

Re: Article on D for CVu or Overload

[Ali Çehreli via Digitalmars-d]

On 12/29/2015 05:31 AM, Russel Winder via Digitalmars-d wrote:

> BTW Any preferences as to what to do with the other two copies? I was
> wondering about handing them out at ACCU 2016 as prizes for something
> or other.

Thank you! That sounds great. Or you can do anything else that you want 
with them. Maybe you know someone that is interested in D; you can give 
it to them. Or put it around at a company where people will see and grab 
it to flip through the pages... They are just marketing expense for me. :)


Ali

Re: pl0stuff an optimizing pl0 > c transcompiler

[Nick B via Digitalmars-d-announce]

On Tuesday, 29 December 2015 at 17:59:15 UTC, Stefan Koch wrote:

On Tuesday, 29 December 2015 at 04:37:44 UTC, Nick B wrote:

Would you know what is required to get good performance ?


I can guess. However without actually implementing it my guess 
is as good as any.
I would probably look at HHVM, and see what is easy to 
reimplement in D.


So the best approach, if I understand you correctly, would be to 
perform micro-benchmarks on new code that is either D code (with 
a variety of algorithms and/or vibe.d framework code) or HHVM 64 
bit code, and compare (and publish) the results ?

Re: Voting For std.experimental.ndslice

[Jack Stouffer via Digitalmars-d]

On Tuesday, 29 December 2015 at 17:38:06 UTC, Ilya Yaroshenko 
wrote:
On Tuesday, 29 December 2015 at 17:17:05 UTC, Jack Stouffer 
wrote:
On Monday, 28 December 2015 at 14:42:43 UTC, Ilya Yaroshenko 
wrote:
On Monday, 28 December 2015 at 11:13:57 UTC, Martin Nowak 
wrote:
We're branching for 2.070 soon, would be nice if this can 
make it, but only if it's really ready.


Whooohooo!

Thanks!

Ilya


I'm writing a blog post giving an overview of std.ndslice and 
comparing and contrasting to Numpy, to be released when this 
is merged, and I was wondering if I can have your permission 
to include your great image processing example in the post?


Thank you for doing this!


First draft: http://jackstouffer.com/hidden/nd_slice.html

Please critique.

[Issue 12233] Attempting to use TypeInfo.init results in a compiler error due to lack of 'this'.

[via Digitalmars-d-bugs]

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

--- Comment #5 from github-bugzi...@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/druntime

https://github.com/D-Programming-Language/druntime/commit/04700217971964fdc8edb1798eaa669ec37fa7e9
rename TypeInfo's init method to initializer

"init" clashes with the type property of the same name.

Adding an alias called "init" to give people a chance to update their
code.

Further deprecation plan:
* 2.071: Do nothing. Keep both init and initializer functional for a while.
* 2.072: Deprecate the alias.
* 2.073: Replace the alias with an `@disable`d method.
* 2.074: Remove the init method, fixing issue 12233.

--

Re: Is stdout.flush() unsafe?

[Steven Schveighoffer via Digitalmars-d-learn]

On 12/29/15 4:57 AM, tsbockman wrote:

Trying to compile this:

void main() @safe
{
 import std.stdio;
 stdout.flush();
}

Fails with this message:

Error: safe function 'main' cannot access __gshared data 'stdout'


Is this necessary? If so, what are the synchronization requirements for
access to `stdout`?


Hm... what is needed is an accessor for stdout:

void main() @safe
{
   import std.stdio;
   auto safe_stdout() @trusted { return stdout; }
   safe_stdout.flush();
}

The issue is the storage class __gshared is banned from accessing in 
safe code (because it is subject to races). So you have to claim to the 
compiler "I know this is generally not safe, but I have encapsulated it 
in a way to make it safe". Likely, this is what we should do for all the 
standard streams, not being able to access streams in safe code seems a 
steep restriction.


-Steve

Re: Voting For std.experimental.ndslice

[Ilya via Digitalmars-d]

On Wednesday, 30 December 2015 at 01:03:39 UTC, Ilya Yaroshenko 
wrote:
On Wednesday, 30 December 2015 at 00:24:38 UTC, Ilya Yaroshenko 
wrote:
On Tuesday, 29 December 2015 at 21:19:19 UTC, Jack Stouffer 
wrote:
On Tuesday, 29 December 2015 at 17:38:06 UTC, Ilya Yaroshenko 
wrote:
On Tuesday, 29 December 2015 at 17:17:05 UTC, Jack Stouffer 
wrote:

[...]


Thank you for doing this!


First draft: http://jackstouffer.com/hidden/nd_slice.html

Please critique.


Awesome!

Please find my notes below.
[...]
 - You may want to test both DMD and LDC 0.17.0 alpha1 for 
bechmarks 
https://github.com/ldc-developers/ldc/releases/tag/v0.17.0-alpha1

   LDC 0.17.0 alpha1 works well with dip80-ndslice v0.8.7.
[...]
Ilya


ldmd2/ldc2 flag -mcpu=native will optimise code for your CPU. 
-- Ilya


The paragraph

"This function does not calculate border cases in which a window 
overlaps the image partially. However, the function can still be 
used to carry out such calculations. That can be done by creating 
an amplified image, with the edges reflected from the original 
image, and then applying the given function to the new file. 
Note:"


ends with "Note:". --Ilya

Re: Better docs for D (WIP)

[Andrei Alexandrescu via Digitalmars-d-announce]

On 12/29/2015 09:09 PM, Adam D. Ruppe wrote:

Putting one item per page is far more important than I even realized
before getting into this.


We already have that:

https://dlang.org/library/std/array/join.html

If I search for dlang array join that the third hit on google if I'm 
logged in, and the SECOND hit if I use an anonymous session that gives 
google no information about my searching habits. I hope you'll agree 
that renders the rest of your post moot, for which reason I afforded to 
snip it.


Adam, there's no nice way to put what follows. You can code a great 
deal, and I think the world of your engineering skills. But there is 
something to be said about a bias for action at the expense of strategy. 
I completely understand it's a lot more fun to start a project than to 
bring it to completion, but as they say in hardware, it's retired 
instructions that count. I wish you'd consider converting some of your 
myriad brilliant snippets into completed projects pushed into the 
standard distribution for prime time, and also (for this case) to 
consider strengthening the documentation tools we already have.



Andrei

Re: vibe.d benchmarks

[Charles via Digitalmars-d]

On Tuesday, 29 December 2015 at 22:49:36 UTC, Nick B wrote:

On Monday, 28 December 2015 at 13:10:59 UTC, Charles wrote:
On Monday, 28 December 2015 at 12:24:17 UTC, Ola Fosheim 
Grøstad wrote:

https://www.techempower.com/benchmarks/

The entries for vibe.d are either doing very poorly or fail 
to complete. Maybe someone should look into this?


Sönke is already on it.

http://forum.rejectedsoftware.com/groups/rejectedsoftware.vibed/post/29110


Correct me if I am wrong here, but as far I can tell there is 
no independent benchmarks showing performance (superior or good 
enough) of D verses Go, or against just about any other 
language, as well  ?


https://www.techempower.com/benchmarks/#section=data-r11=peak=json=cnc=zik0vz-zik0zj-zik0zj-zik0zj-hra0hr


The last time the official benchmark was run was over a month 
before Sönke's PR.

Re: Voting For std.experimental.ndslice

[Jack Stouffer via Digitalmars-d]

On Wednesday, 30 December 2015 at 00:24:38 UTC, Ilya Yaroshenko 
wrote:

Awesome!

Please find my notes below.


Thanks for the feedback. Good thing I posted this here before 
releasing it.


Funny thing, when I made the D example use the mean lambda 
function, it got way faster. Even with the larger array size, the 
D code went from 138 ns with the small array and the function to 
58 ns with the large array and the lambda. And, the Python code 
expectantly got slower, even when I made sure to only test the 
np.mean function, the time taking the mean of the large array was 
145 µs up from 10.5 µs with allocation and taking the mean with 
the smaller array.


So now the D version is 2474x faster.

Also, I was unable to get LDC numbers, as when I compiled my test 
program with all of the optimization flags, LDC returns 0 hnsecs


the code:

===

import std.range;
import std.algorithm.iteration;
import std.experimental.ndslice;
import std.stdio;
import std.datetime;
import std.conv : to;

void f0() {
auto means = 100_000.iota.sliced(100, 1000).transposed.map!(r 
=> sum(r) / r.length);

}

void main() {
auto r = benchmark!(f0)(10_000);
auto f0Result = to!Duration(r[0]);
f0Result.writeln;
}

I'm assuming that LLVM realizes that the variable means is never 
used, so it removes it from the final version.

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

Jacob Carlborg  writes:

> On 2015-12-28 20:02, Dan Olson wrote:
>
>> That is Plan B.2
>
> I'm working on implementing native TLS for OS X in DMD. I think I've
> figured out how everything works. Unless you already know how it
> works, I could tell you what I have figured out.

I know some of it from hacking dyld for iOS, but not all.  How does this
fit in with "Plan B.2"?

pragma(inline)

[Ilya via Digitalmars-d-learn]

Hi,

Does `pragma(inline, true)` force DMD compiler to inline function 
when `-inline` was _not_ defined?


I am failing to get a good disassembled code with obj2asm/otool 
:-(


Best, Ilya

Re: Microsoft officially documents pdb format

[Joakim via Digitalmars-d]

On Friday, 30 October 2015 at 07:19:14 UTC, rsw0x wrote:

https://github.com/Microsoft/microsoft-pdb


Well, they finally added CodeView support to llvm, good to see 
them coming around:


http://phoronix.com/scan.php?page=news_item=Microsoft-Adds-LLVM-CodeView

Somebody should probably check the work Walter put in to 
reverse-engineer CV and add support to dmd.  Not Walter, since he 
won't look at outside code for legal reasons.

Re: We need a good code font for the function signatures on dlang.org

[Andrei Alexandrescu via Digitalmars-d]

On 12/18/2015 04:06 PM, Jack Stouffer wrote:

On Thursday, 17 December 2015 at 13:59:14 UTC, Andrei Alexandrescu wrote:

On 12/17/2015 03:07 AM, Mike Parker wrote:

On Wednesday, 16 December 2015 at 21:05:27 UTC, Andrei Alexandrescu
wrote:



What would be a good code font to use for those?



http://sourcefoundry.org/hack/


Could someone please round up this and other proposals into pull
requests? Then we can see them displayed in Vladimir's rig. Thanks! --
Andrei


https://github.com/D-Programming-Language/dlang.org/pull/1170
https://github.com/D-Programming-Language/dlang.org/pull/1171
https://github.com/D-Programming-Language/dlang.org/pull/1172
https://github.com/D-Programming-Language/dlang.org/pull/1173

Despite people's requests, Consolas is a premium font owned by
Microsoft, so it cannot be used. Inconsolas was included instead.


Thanks for this work! I chose Inconsolata, 
https://github.com/D-Programming-Language/dlang.org/pull/1170. -- Andrei

Re: Voting For std.experimental.ndslice

[Ilya Yaroshenko via Digitalmars-d]

On Wednesday, 30 December 2015 at 06:16:23 UTC, Jack Stouffer 
wrote:
On Wednesday, 30 December 2015 at 00:24:38 UTC, Ilya Yaroshenko 
wrote:

[...]


Thanks for the feedback. Good thing I posted this here before 
releasing it.


[...]



means in your code is lazy variable :)
You may want to made means a global array. And copy mapped result 
to it. Please made PR to DlangSciencse/examples with your Python 
and D benchmarks. --Ilya

reduce a BitArray[]

[Alex via Digitalmars-d-learn]

Hi there,
a silly question from me for the turn of the year... I apparently 
missing the forest through the trees.

The first part of the code works as expected:

[code]
int[] arr8 = [1,2,3,4,5];

int sum = 0;
foreach(int summand; arr8)
{
sum += summand;
}
writeln("sum1: ", sum);

writeln("sum2: ", reduce!((a,b) => a + b)(arr8));
[/code]

The second one does not:

[code]
import std.bitmanip;

BitArray[] arr7 = [BitArray([0, 1, 0, 1, 0, 1]), BitArray([0, 
1, 0, 0, 0, 0]), BitArray([0, 1, 0, 1, 0, 0]), BitArray([0, 1, 0, 
1, 0, 0])];


BitArray common = BitArray([1,1,1,1,1,1]);
foreach(BitArray ba; arr7)
{
common &=  ba;
}
writeln("common2: ", common);

//writeln("common1: ", reduce!((a,b) => a & b)(arr7));
[/code]

The problem is, that the last line with the reduce does not 
compile. Why?

Re: Is there a FIX engine written in D?

[Dejan Lekic via Digitalmars-d]

https://github.com/libtrading/libtrading/blob/master/docs/quickstart.md


Nice project - I did not know about it! Thanks!

Major problem in writing a library which implements FIX protocols 
is lack of a good XML package. Yes, we have std.xml but it is far 
from good, and as we all know, it needs a replacement.


Also, problem with FIX is that it may become redundant. There is 
a lot of criticism about it, and many exchanges decided to 
abandon it...

Re: Voting For std.experimental.ndslice

[Jack Stouffer via Digitalmars-d]

On Tuesday, 29 December 2015 at 13:30:47 UTC, Márcio Martins 
wrote:
If I am reading the code right, the number of dimensions must 
always be known at compile time, right?


Not necessarily. The dimensions for this slice are computed at 
runtime.


```
auto slice = 1000.iota.sliced(5, 6, 7);
```

Re: Mockup of my doc dream ideas

[Dejan Lekic via Digitalmars-d]

Adam, I wonder could we also have information since what Phobos 
version particular symbol is available from. For an example, from 
which version of Phobos we have findSkip() ??

Re: Better docs for D (WIP)

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

On Tuesday, 29 December 2015 at 05:00:48 UTC, Rikki Cattermole 
wrote:
From what Adam has said, definitely won't be happening with 
DDOC.

There is simply no symbol to attach the comment to.


Well, not definitely, it was really easy to do in libdparse (a 
two line diff) and probably similarly easy in dmd.


There is no user-facing name for an anonymous enum, but there is 
a compiler data structure for it.

Re: Better watch out! D runs on watchOS!

[Jacob Carlborg via Digitalmars-d-announce]

On 2015-12-28 20:02, Dan Olson wrote:


That is Plan B.2


I'm working on implementing native TLS for OS X in DMD. I think I've 
figured out how everything works. Unless you already know how it works, 
I could tell you what I have figured out.


--
/Jacob Carlborg

Re: Article on D for CVu or Overload

[Russel Winder via Digitalmars-d]

On Mon, 2015-12-28 at 11:12 -0800, Ali Çehreli via Digitalmars-d wrote:
> 
[…]
> CVu is for ACCU members only but Overload is freely available online
> as 
> well (both are actually print magazines):
> 
>    http://accu.org/index.php/journal
> 
> Quoting from the most-recent Overload PDF:
> 
>    http://accu.org/index.php/journals/c78/
> 
> "All articles intended for publication in Overload 131 should be 
> submitted by 1st January 2016 and those for Overload 132 by 1st March
> 2016."

I have the book with me, I just haven't read it yet. I will be
submitting a review though. Maybe I should do one for other new-ish D
books all at the same time so we can have them appear around the ACCU
2016 conference.

BTW Any preferences as to what to do with the other two copies? I was
wondering about handing them out at ACCU 2016 as prizes for something
or other.

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

Re: Article on D for CVu or Overload

[Russel Winder via Digitalmars-d]

On Mon, 2015-12-28 at 18:14 +, Jakob Jenkov via Digitalmars-d
wrote:
> 

[…]

> What would the topics be?

Anything to do with programming that a professional programmer would be
interested. CVu is the membership magazine/journal of ACCU but does a
lot of technical content. Overload was the magazine/journal that tended
to be C++ focussed but there is a move to make it have wider content.

I have just submitted an article on Spock (Groovy implemented testing
framework for the JVM) for Overload, and am about to read a book on D
and do a review for CVu. Article was about 3000 words plus code. Not
sure how long the book review will be.
 
> How long?

Articles of many different lengths are good. Generally 1500 to 4500
words I think.

> What are the deadlines?

The two journals are every other month interleaved so there is a
journal every month. So there is always another deadline to aim for. :-
)

I feel an article about how crap C++ is at doing concurrency and
parallelism and how good Go and Rust are. D sadly sits in the middle.
Dataflow for the win!

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder



signature.asc
Description: This is a digitally signed message part

[Issue 15482] New: new uuid.d forbids to link statically with other libraries

[via Digitalmars-d-bugs]

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

  Issue ID: 15482
   Summary: new uuid.d forbids to link statically with other
libraries
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Severity: regression
  Priority: P1
 Component: druntime
  Assignee: nob...@puremagic.com
  Reporter: temta...@gmail.com

phobos_x64.lib(uuid.obj) : error LNK2005: CLSID_DirectInput already defined in
sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: CLSID_DirectInputDevice already
defined in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_Button already defined in
sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_ConstantForce already defined in
sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_CustomForce already defined in
sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_Damper already defined in
sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_1394 already defined in
sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_1394DEBUG already
defined in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_61883 already defined
in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_ADAPTER already defined
in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_APMSUPPORT already
defined in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_AVC already defined in
sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_BATTERY already defined
in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_BLUETOOTH already
defined in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_CDROM already defined
in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_COMPUTER already
defined in sdl_x64.lib(SDL_dxjoystick.obj)
phobos_x64.lib(uuid.obj) : error LNK2005: GUID_DEVCLASS_DECODER already defined
in sdl_x64.lib(SDL_dxjoystick.obj)


And so on.
Why we ever export uuids from uuid.d ?

--

Re: Voting For std.experimental.ndslice

[Márcio Martins via Digitalmars-d]

On Tuesday, 29 December 2015 at 13:54:56 UTC, Jack Stouffer wrote:
On Tuesday, 29 December 2015 at 13:30:47 UTC, Márcio Martins 
wrote:
If I am reading the code right, the number of dimensions must 
always be known at compile time, right?


Not necessarily. The dimensions for this slice are computed at 
runtime.


```
auto slice = 1000.iota.sliced(5, 6, 7);
```


```

With this declaration:

```
struct Slice(size_t _N, _Range)
```
_N, the number of dimensions, must necessarily be known at 
compile-time, right?

Re: Redesign of dlang.org

[Jacob Carlborg via Digitalmars-d]

On 2015-12-27 21:42, anonymous wrote:


The caret seems to be a bit high maybe, but otherwise that's how it's
supposed to look. Feel free to criticize, of course.


Aha, then there's no problem :)

--
/Jacob Carlborg

Re: Better docs for D (WIP)

[Rikki Cattermole via Digitalmars-d-announce]

On 30/12/15 3:24 AM, Adam D. Ruppe wrote:

On Tuesday, 29 December 2015 at 05:00:48 UTC, Rikki Cattermole wrote:

From what Adam has said, definitely won't be happening with DDOC.
There is simply no symbol to attach the comment to.


Well, not definitely, it was really easy to do in libdparse (a two line
diff) and probably similarly easy in dmd.

There is no user-facing name for an anonymous enum, but there is a
compiler data structure for it.


Okay, I remember you saying something a bit different on IRC (at least 
to my understanding).

Is stdout.flush() unsafe?

[tsbockman via Digitalmars-d-learn]

Trying to compile this:

void main() @safe
{
import std.stdio;
stdout.flush();
}

Fails with this message:
Error: safe function 'main' cannot access __gshared data 
'stdout'


Is this necessary? If so, what are the synchronization 
requirements for access to `stdout`?

Re: Voting For std.experimental.ndslice

[Márcio Martins via Digitalmars-d]

On Tuesday, 29 December 2015 at 07:45:14 UTC, Ilya Yaroshenko 
wrote:
On Monday, 28 December 2015 at 22:39:45 UTC, Ilya Yaroshenko 
wrote:
On Monday, 28 December 2015 at 21:43:35 UTC, Robert burner 
Schadek wrote:

[...]


Agreed

1. First paragraph was replaced by your variant.
2. Binary representation was moved to Slice type documentation.
3. Small "Quick Start" was added, so new user will start from 
`sliced` and `Slice`.


http://dtest.thecybershadow.net/artifact/website-76234ca0eab431527327d5ce1ec0ad74c6421533-081dd6e9e8b3810a143d0a5fcba8d60b/web/phobos-prerelease/std_experimental_ndslice.html

Thanks!

Ilya


Fix English: 
http://dtest.thecybershadow.net/artifact/website-76234ca0eab431527327d5ce1ec0ad74c6421533-bfed2500425eb407bf2c97fc72e8a0c5/web/phobos-prerelease/std_experimental_ndslice.html


If I am reading the code right, the number of dimensions must 
always be known at compile time, right? Is so, I suppose it was a 
performance-oriented decision and not an oversight, correct?

Re: Mockup of my doc dream ideas

[Adam D. Ruppe via Digitalmars-d]

On Tuesday, 29 December 2015 at 14:13:54 UTC, Dejan Lekic wrote:
Adam, I wonder could we also have information since what Phobos 
version particular symbol is available from. For an example, 
from which version of Phobos we have findSkip() ??


Yeah, I was thinking about that too. The info isn't in the doc 
itself, but could be determined when I update the site here by 
comparing before and after docs.


So it could automatically say "in the .70 update, I found this 
function that wasn't there before, so I can add a note `Since 
phobos 2.70`".



That will take an additional pass and a cross-version database to 
query during doc builds but it is totally doable.


BTW ddoc also has "Version:" and "History:" sections in the spec 
we could use to write up changes ourselves...