date:20151215

2015-12-15 Thread Jesse Phillips via Digitalmars-d-learn

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

landaire  changed:

   What|Removed |Added

 CC||landergriffith+dlangbz@gmai
   ||l.com

--- Comment #3 from landaire  ---
Jack Stouffer suggested I add my (visual) suggestions here:
http://imgur.com/a/njHKI

Context: http://forum.dlang.org/post/ckmfubbgppizescgj...@forum.dlang.org

--

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread Chris Wright via Digitalmars-d

On Tue, 15 Dec 2015 15:55:31 +, ZombineDev wrote:

> On Tuesday, 15 December 2015 at 14:03:50 UTC, rumbu wrote:
>>
>> We are talking about a better documentation, not about the C# vs D
>> performance, we already know the winner. Since C# is an OOP-only
>> language, there is only one way to do reflection - using OOP,
>> (voluntarily ignoring the fact that NGen will reduce this call to a
>> simple memory read in case of arrays).
>>
>> Your affirmation:
>>
>>> the docs don't even bother to mention that it is almost always O(n),
>>> because non of the Enumerable extention methods preserve the
>>> underlying ICollection interace
>>
>> was false and you don't need to look to the source code to find out,
>> the Remarks section is self-explanatory:
>>
>> "If the type of source implements ICollection, that implementation
>> is used to obtain the count of elements. Otherwise, this method
>> determines the count."
> 
> Sorry, I do not know how to make this clear:
> 
> NONE OF THE System.Linq.Enumerable EXTENSION METHODS PRESERVE THE
> STRUCTURE (THE INTERFACES THEY IMPLEMENT) OF THE SEQUENCE THEY ARE
> OPERATING ON. DON'T BELIEVE THAT NGEN WILL AUTOMAGICALLY MAKE YOUR CODE
> FASTER. IT WILL NOT. UNICORNS DO NOT EXISTS. AT LEAST THEY DO NOT IN
> .NET OR JAVA. DO NOT BLINDLY BELIEVE. TEST!

'I said it very loud and clear:
I went and shouted in his ear.'

Humpty Dumpty raised his voice almost to a scream as he repeated this 
verse, and Alice thought with a shudder, 'I wouldn't have been the 
messenger for anything!'

'But he was very stiff and proud:
He said, "You needn't shout so loud!"

And he was very proud and stiff:
He said 'I'd go and wake them, if --"'

> See for yourself: https://ideone.com/L5FatQ
> 
> This what I got on my machine:
> 00:00:00.0011011 for N = 1 -> 1, List.Select(..).Count()

You have observed that System.Linq hasn't fully propagated metadata about 
collections through operations where it could and where D's equivalents 
do.

You are blaming this on object oriented programming. It is easy to 
support a handful of extra operations (like O(1) collection length) on 
all System.Linq types with object oriented code. It gets harder as you 
try to support more operations, but there are probably only a few you 
need to worry about.

It is more convenient to use templates and static if, especially as the 
number of operations grows. But it's certainly possible to do in OOP.

You are also explicitly opting out of adaptive optimizations by using 
ngen. That's a much smaller effect, of course. ngen is better for fast 
startup and to guarantee that the runtime won't try to re-JIT your code 
when you're executing code that can't stand for such a pause.

>> - You don't need to understand computer science terms to find out what
>> a function does;
> 
> A major disadvantage, if you ask me :D

"Come learn D, it's actively hostile toward novices!" ...perhaps a 
different marketing campaign would work better.

>> There is no indication what happens if the range contains more than
>> size_t.max elements:
>> - integer overflow;
> 
> Practically impossible on 64-bit and unlikely that someone will use
> walkLength with files on 32-bit. It's called *walk*Length for a reason.

Not all ranges are backed by data in memory or on disk. I could create a 
range over the time from the Big Bang to today in 10-femtosecond 
intervals, for instance. Granted, it would be silly for me to call 
walkLength on that.

Also, there's no indication what the return type is. It could be a short 
for all I know. Maybe the writer accidentally wrote 'auto count = 0;' 
instead of explicitly using size_t, in which case by three billion entry 
range will report that its walk length is negative.

I read the source code and know it's using size_t (and should perhaps 
just be ulong). But it's not documented anywhere.

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread wobbles via Digitalmars-d


On Monday, 14 December 2015 at 19:04:46 UTC, bachmeier wrote:
It's unanimous, at least among the three of us posting in this 
Reddit thread:


https://www.reddit.com/r/programming/comments/3wqt3p/programming_in_d_ebook_is_at_major_retailers_and/cxyqxuz

Something has to be done with the documentation for Phobos 
functions that involve ranges and templates. The example I gave 
there is


bool isSameLength(Range1, Range2)(Range1 r1, Range2 r2) if 
(isInputRange!Range1 && isInputRange!Range2 && 
!isInfinite!Range1 && !isInfinite!Range2);


Unfortunately, that's less ugly than for a lot of functions. In 
some circumstances, I can see something like that reminding the 
author of the function about some details, but it can only 
confuse anyone else.


There is nothing I can do about this. Who makes these 
decisions? Can we change it to something useful?


Also, I think the documentation for functions involving ranges 
needs more "for dummies" examples. Too many of those functions 
leave the reader not having a clue what to do after calling the 
function. I know how that can be fixed.


I think that most of the problem is simply down to how the 
documentation looks. It's too dense.


I think some whitespace and some color-coding will go a long way 
to making the function signatures better.


bool isSameLength
   (Range1, Range2)   // a grey color
   (Range1 r1, Range2 r2) // a blue
   if (isInputRange!Range1 && isInputRange!Range2 &&
   !isInfinite!Range1 && !isInfinite!Range2);  // same grey color 
as template args, to point out they're working on the template


I think that would make all documentation much easier to glance 
over, and yet easy to read if you need to.


On the examples - more examples can only be better!

Must ranges have value semantics?

2015-12-15 Thread Chris Wright via Digitalmars-d-learn

I noticed that some methods in Phobos will have very different behavior 
with forward ranges that have reference semantics and those that have 
value semantics.

Example:

auto range = getSomeRange();
auto count = range.walkLength;
foreach (element; range) { writeln(element); }

If getSomeRange returns a forward range that is a reference type with 
no .length property, walkLength will exhaust the range. The iteration 
after that will never enter the loop body.

However, if getSomeRange returns a range with value semantics with 
no .length property, then iteration is still possible.

I haven't found documentation about how ranges are intended to be used in 
D written by people who maintain Phobos. Is it normal and expected that I 
should have to call .save everywhere, manually? Was there discussion on 
whether this should be the case or a published document containing the 
reasoning behind the decision?

Re: Must ranges have value semantics?

2015-12-15 Thread H. S. Teoh via Digitalmars-d-learn

On Tue, Dec 15, 2015 at 05:36:52PM +, Chris Wright via Digitalmars-d-learn 
wrote:
> I noticed that some methods in Phobos will have very different
> behavior with forward ranges that have reference semantics and those
> that have value semantics.
> 
> Example:
> 
> auto range = getSomeRange();
> auto count = range.walkLength;
> foreach (element; range) { writeln(element); }
> 
> If getSomeRange returns a forward range that is a reference type with
> no .length property, walkLength will exhaust the range. The iteration
> after that will never enter the loop body.
> 
> However, if getSomeRange returns a range with value semantics with no
> .length property, then iteration is still possible.
> 
> I haven't found documentation about how ranges are intended to be used
> in D written by people who maintain Phobos. Is it normal and expected
> that I should have to call .save everywhere, manually? Was there
> discussion on whether this should be the case or a published document
> containing the reasoning behind the decision?

This is one of the "undefined" or poorly-defined areas of D ranges. :-(
Basically, in generic code, you should always use .save where you expect
to reuse the range after iterating over it.  In non-generic code, of
course, you already know what the range semantics are and you don't need
to use .save, but in generic code, where the incoming range type may or
may not have reference semantics, always call .save to be on the safe
side. Value-type ranges simply return `this` in their .save method
anyway, so it doesn't hurt.

(There have been (and possibly still are) places in Phobos where .save
wasn't used, leading to subtle bugs that only manifest themselves when
user code starts passing reference-semantics ranges around. Phobos
unittests in general, unfortunately, tend to only test value-type
ranges, so this problem often gets missed. There have been attempts to
remedy this, but AFAIK there are still many unittests out there that
don't adequately verify their target functions with reference-type
ranges. Or, on a related note, anything other than arrays, which often
leads to hiding places for bugs that only show up with non-array
ranges.)

There was a discussion recently that .save may have been a
miscalculation in the design of ranges, and that forward ranges should
have done this in postblit instead of a separate method. (One should
understand, however, that at the time ranges were first defined, we
didn't have postblit semantics the way we have them today, so at that
time a .save method was possibly the best compromise given the state of
the language then.)

T

-- 
Never ascribe to malice that which is adequately explained by incompetence. -- 
Napoleon Bonaparte

Re: Some feedback on the website.

2015-12-15 Thread Wyatt via Digitalmars-d


On Tuesday, 15 December 2015 at 07:07:23 UTC, deadalnix wrote:


Home page:

This is a mess. There is way too much here. There is an 
attention budget and it is important to manage it well.


I think you're overstating it: it's a bit busy, but I think it 
can be fixed.



The usual for a programming language goes as follow :
 - Logo, color as per branding.


Yeah, we should probably incorporate the red more.

 - Language name, quick blurb about what it is, usually ending 
with a link to tutorial.


We have the language name twice!  Do we need a longer blurb?  
None of your examples seem to link to an official tutorial at 
all, so we're ahead of the game there. (Sort of.  It's on a 
different domain and doesn't match "D style".)



 - Big fat download button.


It's right in the middle of the page.  Should we wrap it in 
 to make it more obvious? (Seriously: I agree it should be 
bigger.  Changelog link smaller and underneath instead.)


 - Some sample code. The one we have on the front page is way 
too big. It should be a piece of code that someone with 0 
experience in the language can understand.


The RPN example is too big.  The sort lines example is nice.  Is 
there some sort of rotation here?  Go kinda gets it right with 
the dropdown.  Scala's tiles are poorly telegraphed.


 - A menu with quick access to what more experienced users want 
: stdlib reference, code repository, wiki, forum, language 
spec, news, this kind of thing.



So, the stuff on the sidebar?


Some examples:
http://www.scala-lang.org/


Well, I guess it's pretty?  Examples aren't obvious and the 
documentation uses a completely different colour scheme for 
Reasons(?).



https://nodejs.org/en/


Thoroughly useless bootstrap placeholder.


https://developer.apple.com/swift/


What on earth?  There's no download at all, no obvious doc link, 
way too much verticality, and they've overdone it on the 
whitespace.  I guess they only care about people with high-dollar 
Apple screens.



https://golang.org/


Ugly but functional.  Decent layout, though I still don't get 
this fetish for top links.



https://www.rust-lang.org/

Slightly better than Go.  Could we stop pretending 1024x768 is 
The Best Resolution?


Last but not least, it wouldn't hurt to hire a designer to have 
something slick.


I think the biggest issues are the sidebar cleanliness and the 
main content having a single-column design.  I like the _idea_ of 
having the discussion boxouts in the right column, but it comes 
at the expense of the rest of the content and contributes to the 
fatigue.


-Wyatt

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread wobbles via Digitalmars-d


On Tuesday, 15 December 2015 at 08:08:10 UTC, landaire wrote:
On Tuesday, 15 December 2015 at 02:39:16 UTC, Steven 
Schveighoffer wrote:

[...]


I started exploring D a couple of months ago and I was the 
original poster in the reddit thread who sparked this 
discussion. While on the topic of documentation I wanted to 
quickly put in my thoughts about what frustrated me with the 
documentation:


[...]


I think these are some great suggestions, particularly the 3rd 
example where the function signature is emphasized.

Re: Must ranges have value semantics?


On Tuesday, 15 December 2015 at 17:36:52 UTC, Chris Wright wrote:
I noticed that some methods in Phobos will have very different 
behavior with forward ranges that have reference semantics and 
those that have value semantics.


Example:

auto range = getSomeRange();
auto count = range.walkLength;
foreach (element; range) { writeln(element); }

If getSomeRange returns a forward range that is a reference 
type with no .length property, walkLength will exhaust the 
range. The iteration after that will never enter the loop body.


However, if getSomeRange returns a range with value semantics 
with no .length property, then iteration is still possible.


I haven't found documentation about how ranges are intended to 
be used in D written by people who maintain Phobos. Is it 
normal and expected that I should have to call .save 
everywhere, manually? Was there discussion on whether this 
should be the case or a published document containing the 
reasoning behind the decision?


Unfortunately you must make no assumption about the ranges state 
in generic code after calling a function that takes the range by 
value. If you want to perform other operations after the call to 
walklength, you'll need to have a new range created with save() 
before that call.


The value vs reference rage creates challenges, but in practice 
it will be something you occasionally hit.


I kind of feel like a range should always be taken by reference 
so that it is predictable that the range will be modified if it 
is value or reference semantics.

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread Chris Wright via Digitalmars-d

On Tue, 15 Dec 2015 16:10:49 +, wobbles wrote:

> I think some whitespace and some color-coding will go a long way to
> making the function signatures better.

We'll want to make sure we test with color-blindness filters, of course.

Re: Some feedback on the website.


On Tuesday, 15 December 2015 at 16:15:49 UTC, Wyatt wrote:

On Tuesday, 15 December 2015 at 07:07:23 UTC, deadalnix wrote:


Home page:

This is a mess. There is way too much here. There is an 
attention budget and it is important to manage it well.


I think you're overstating it: it's a bit busy, but I think it 
can be fixed.




I work in growth, I've seen numbers.

Re: We need better documentation for functions with ranges and templates


On Tuesday, 15 December 2015 at 14:03:50 UTC, rumbu wrote:


We are talking about a better documentation, not about the C# 
vs D performance, we already know the winner. Since C# is an 
OOP-only language, there is only one way to do reflection - 
using OOP, (voluntarily ignoring the fact that NGen will reduce 
this call to a simple memory read in case of arrays).


Your affirmation:

the docs don't even bother to mention that it is almost always 
O(n), because non of the Enumerable extention methods preserve 
the underlying ICollection interace


was false and you don't need to look to the source code to find 
out, the Remarks section is self-explanatory:


"If the type of source implements ICollection, that 
implementation is used to obtain the count of elements. 
Otherwise, this method determines the count."


Sorry, I do not know how to make this clear:

NONE OF THE System.Linq.Enumerable EXTENSION METHODS PRESERVE THE 
STRUCTURE (THE INTERFACES THEY IMPLEMENT) OF THE SEQUENCE THEY 
ARE OPERATING ON. DON'T BELIEVE THAT NGEN WILL AUTOMAGICALLY MAKE 
YOUR CODE FASTER. IT WILL NOT. UNICORNS DO NOT EXISTS. AT LEAST 
THEY DO NOT IN .NET OR JAVA. DO NOT BLINDLY BELIEVE. TEST!


See for yourself: https://ideone.com/L5FatQ

This what I got on my machine:
00:00:00.0011011 for N = 1 -> 1, List.Select(..).Count()
00:00:00.017 for N = 2 -> 2, List.Select(..).Count()
00:00:00.009 for N = 4 -> 4, List.Select(..).Count()
00:00:00.011 for N = 8 -> 8, List.Select(..).Count()
00:00:00.012 for N = 16 -> 16, List.Select(..).Count()
00:00:00.026 for N = 32 -> 32, List.Select(..).Count()
00:00:00.018 for N = 64 -> 64, List.Select(..).Count()
00:00:00.032 for N = 128 -> 128, List.Select(..).Count()
00:00:00.059 for N = 256 -> 256, List.Select(..).Count()
00:00:00.098 for N = 512 -> 512, List.Select(..).Count()
00:00:00.190 for N = 1024 -> 1024, 
List.Select(..).Count()
00:00:00.369 for N = 2048 -> 2048, 
List.Select(..).Count()
00:00:00.750 for N = 4096 -> 4096, 
List.Select(..).Count()
00:00:00.0002185 for N = 8192 -> 8192, 
List.Select(..).Count()
00:00:00.0003551 for N = 16384 -> 16384, 
List.Select(..).Count()
00:00:00.0005826 for N = 32768 -> 32768, 
List.Select(..).Count()
00:00:00.0015252 for N = 65536 -> 65536, 
List.Select(..).Count()
00:00:00.0024139 for N = 131072 -> 131072, 
List.Select(..).Count()
00:00:00.0049246 for N = 262144 -> 262144, 
List.Select(..).Count()
00:00:00.0096537 for N = 524288 -> 524288, 
List.Select(..).Count()
00:00:00.0194600 for N = 1048576 -> 1048576, 
List.Select(..).Count()
00:00:00.0422573 for N = 2097152 -> 2097152, 
List.Select(..).Count()
00:00:00.0749799 for N = 4194304 -> 4194304, 
List.Select(..).Count()
00:00:00.1511740 for N = 8388608 -> 8388608, 
List.Select(..).Count()
00:00:00.3004764 for N = 16777216 -> 16777216, 
List.Select(..).Count()
00:00:00.6018954 for N = 33554432 -> 33554432, 
List.Select(..).Count()
00:00:01.2064069 for N = 67108864 -> 67108864, 
List.Select(..).Count()
00:00:02.6716092 for N = 134217728 -> 134217728, 
List.Select(..).Count()
00:00:05.1524452 for N = 268435456 -> 268435456, 
List.Select(..).Count()
00:00:09.6481144 for N = 536870912 -> 536870912, 
List.Select(..).Count()

00:00:00.0005440 for N = 1 -> 1, Array.Select(..).Count()
00:00:00.010 for N = 2 -> 2, Array.Select(..).Count()
00:00:00.008 for N = 4 -> 4, Array.Select(..).Count()
00:00:00.009 for N = 8 -> 8, Array.Select(..).Count()
00:00:00.013 for N = 16 -> 16, Array.Select(..).Count()
00:00:00.015 for N = 32 -> 32, Array.Select(..).Count()
00:00:00.020 for N = 64 -> 64, Array.Select(..).Count()
00:00:00.035 for N = 128 -> 128, Array.Select(..).Count()
00:00:00.061 for N = 256 -> 256, Array.Select(..).Count()
00:00:00.107 for N = 512 -> 512, Array.Select(..).Count()
00:00:00.209 for N = 1024 -> 1024, 
Array.Select(..).Count()
00:00:00.424 for N = 2048 -> 2048, 
Array.Select(..).Count()
00:00:00.822 for N = 4096 -> 4096, 
Array.Select(..).Count()
00:00:00.0001633 for N = 8192 -> 8192, 
Array.Select(..).Count()
00:00:00.0003263 for N = 16384 -> 16384, 
Array.Select(..).Count()
00:00:00.0006503 for N = 32768 -> 32768, 
Array.Select(..).Count()
00:00:00.0013024 for N = 65536 -> 65536, 
Array.Select(..).Count()
00:00:00.0026130 for N = 131072 -> 131072, 
Array.Select(..).Count()
00:00:00.0052041 for N = 262144 -> 262144, 
Array.Select(..).Count()
00:00:00.0103705 for N = 524288 -> 524288, 
Array.Select(..).Count()
00:00:00.0207945 for N = 1048576 -> 1048576, 
Array.Select(..).Count()
00:00:00.0418217 for N = 2097152 -> 2097152, 
Array.Select(..).Count()
00:00:00.0829522 for N = 4194304 -> 4194304, 
Array.Select(..).Count()
00:00:00.1658241 for N = 8388608 -> 8388608, 
Array.Select(..).Count()
00:00:00.3304377 for N = 16777216 -> 16777216, 
Array.Select(..).Count()
00:00:00.6636190 for N = 33554432 -> 33554432, 
Array.Select(..).Count()
00:00:01.3255121 for N = 67108864 -> 67108864,

Re: Balanced match with std.regex

2015-12-15 Thread wobbles via Digitalmars-d-learn


On Tuesday, 15 December 2015 at 02:35:34 UTC, Xinok wrote:

On Tuesday, 15 December 2015 at 01:29:39 UTC, Jakob Ovrum wrote:

Thanks, that makes sense.

String manipulation in D without regex is pretty nice anyway, 
so it's not a big loss.


There is a library named Pegged which can match against 
balanced parens:


https://github.com/PhilippeSigaud/Pegged


Pegged is amazeballs.
Can build some v cool things with it. Particularly with some CTFE 
abuse!

[Issue 13676] [ddoc] DDoc should wrap each part of function declaration in dedicated macro to allow more readable formatting

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

--- Comment #4 from landaire  ---
Also might as well copy my other suggestions:

- Inline runnable examples: They're present on the homepage, why can't the
examples provided in the inline docs be runnable as well?

- Link to where the code is implemented in Phobos at the time of compilation.
e.g. clicking the name of the function "find" when looking at the signature
could link me here:
https://github.com/D-Programming-Language/phobos/blob/b6a61d9e719a9d680936db44b98fbb5dd28bf6b1/std/algorithm/searching.d#L1498.
More than once I found that reading the code was more useful than reading the
documentation.

--

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread landaire via Digitalmars-d


On Tuesday, 15 December 2015 at 08:08:10 UTC, landaire wrote:


I started exploring D a couple of months ago and I was the 
original poster in the reddit thread who sparked this 
discussion. While on the topic of documentation I wanted to 
quickly put in my thoughts about what frustrated me with the 
documentation:


[...]


Dang, no responses to this?

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread Ola Fosheim Grøstad via Digitalmars-d


On Tuesday, 15 December 2015 at 08:08:10 UTC, landaire wrote:
- Runnable examples would be *so* useful! They're present on 
the homepage, why can't the examples provided in the inline 
docs be runnable as well?

[snip]
Here's an imgur album I created to show some suggestions for 
function signatures: http://imgur.com/a/njHKI


These are all great suggestions. Please add them to the bug 
report already mentioned in this thread.


- Dead links = compile error when compiling documentation? This 
was annoying when trying to find out more about OutputRanges. 
The only resource I found was on the std.range page in the tee 
definition, and the link was dead: 
http://dlang.org/phobos/std_range.html#.tee


I think CyberShadow was working on this. It is a problem though 
that needs fixing.


- Link to where the code is implemented in Phobos at the time 
of compilation. e.g. clicking the actual name of "find" could 
link me here: 
https://github.com/D-Programming-Language/phobos/blob/b6a61d9e719a9d680936db44b98fbb5dd28bf6b1/std/algorithm/searching.d#L1498. More than once I found that reading the code was more useful than reading the documentation.


Also a good idea.

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread Andrei Alexandrescu via Digitalmars-d


On 12/15/2015 11:24 AM, landaire wrote:

On Tuesday, 15 December 2015 at 08:08:10 UTC, landaire wrote:


I started exploring D a couple of months ago and I was the original
poster in the reddit thread who sparked this discussion. While on the
topic of documentation I wanted to quickly put in my thoughts about
what frustrated me with the documentation:

[...]


Dang, no responses to this?


I started a long answer and then my Ubuntu froze. Will redo it... -- Andrei

Re: Some feedback on the website.

2015-12-15 Thread Pradeep Gowda via Digitalmars-d


On Tuesday, 15 December 2015 at 07:07:23 UTC, deadalnix wrote:


The usual for a programming language goes as follow :
 - Logo, color as per branding.
 - Language name, quick blurb about what it is, usually ending 
with a link to tutorial.

 - Big fat download button.
 - Some sample code. The one we have on the front page is way 
too big. It should be a piece of code that someone with 0 
experience in the language can understand.
 - A menu with quick access to what more experienced users want 
: stdlib reference, code repository, wiki, forum, language 
spec, news, this kind of thing.


1. https://www.python.org/
2. https://www.ruby-lang.org/en/

I think the above two websites do a better job of fitting your 
requirements than Scala's homepage etc., Let not the dynamic 
typed nature of the language(s) dissuade you from learning how to 
build a very popular language **community**.

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread Chris Wright via Digitalmars-d

On Tue, 15 Dec 2015 09:09:43 +, Adrian Matoga wrote:

> Fantastic example of why this strategy should be just banned. 

Just as well I wasn't recommending it as a long-term solution. I was more 
offering it as additional evidence that template definitions can get a 
bit large and people have known that this is a problem for documentation 
for eight years now.

"Banned" is a strong term. Perhaps you simply meant it should not be 
recommended and should not be used in Phobos?

Re: Microsoft to contribute to Clang and LLVM project

2015-12-15 Thread Joakim via Digitalmars-d

On Friday, 11 December 2015 at 11:42:31 UTC, Ola Fosheim Grøstad 
wrote:

On Friday, 11 December 2015 at 10:22:18 UTC, Joakim wrote:
I agree that a plan needs to be articulated.  I hoped to get 
something like that from the vision statement, but broad goals 
like improving quality or fostering participation are pretty 
useless.  It should have gone into concrete detail on how they 
favored accomplishing those broad aims, say by better 
integrating Panteleev's Digger and other tools into the build 
process or improving the documentation about getting started 
on developing D itself.


Well, my main issue with D is that there is no plan for making 
things simpler in order to add more advanced clean features 
based on modern static analysis at the next stage. New features 
are added, like hacking in C++ support or multiple-alias-this, 
that just adds more complexity.


Unless you articulate what your alternate plan is to make things 
simpler, perhaps along with some github PRs or a DIP, things will 
keep going as they are.


Although I still have some hope that a refactored codebase 
could make "simplification" possible as a side project by an 
independent group. But making a cleaner version of that 
language doesn't seem to be on the map by the core developers. 
As such, D is in the same tarpit as Go. "We are done". Ok, but 
then these languages will remain in a very small niche that 
most likely will shrink, not grow. To me, both Go and D are 
stuck a little bit in the past and I think both languages will 
need to move one step back in order to make a leap forward.


C++14 would have been great if they had bothered to clean up 
the language before adding even more to it. I think C++ is a 
good example of what happens when one doesn't take a step back 
and clean up in time.


I completely agree that languages need to clean up and release 
breaking versions at some point, just as D did with the 2.0 
release.


I think you underestimate how much of a selling point dmd's 
speed is


Even so, the best performing compiler ought be the official one 
and released first.


I don't see why, usually you prototype first with the faster 
compiler, then build for production with the slower one with 
better codegen.  Of course, it doesn't help that ldc/gdc are 
behind in the frontend version they're using, but you could 
always use an older dmd to prototype if you know you'll need 
ldc/gdc.


Go also is acclaimed for great compilation speed, yet people 
complain about execution and say they switch to Rust over it 
etc. And Rust is known to be slow at compilation.


I'm sure both types of speed have their own audience, but with D 
you can have both. :)


Personally, I think that entire web platform is stupid, so I 
don't care that D doesn't target it.


This is the big problem. It is an open target that is 
available, and you only compete with C/C++. Yet it isn't 
prestige among language devs to target it, and it isn't 
established, so people ignore it. In 5 years people will curse 
because they didn't actively target it before other languages 
got established on it.


I don't think system programming languages have much of a shot at 
web dev, which is why I've always said the market for vibe.d is 
limited, no matter how great it is.  C/C++ certainly have almost 
no penetration there.  Web devs use scripting languages to 
prototype, then switch to Java when they need to scale.  D could 
maybe hit those who want to scale beyond that, but that's not 
many places.


Your asm.js/WebAssembly target is a little different, but using 
the web for such apps is just as dumb.  There are good reasons 
why mobile is ascendant and webapps on the downswing.


If you want to grow that is exactly the kind of target you 
want. People switch if you are the only alternative. That is 
exactly when they switch to smaller niche products.


People adopted Perl, it was the only real alternative for 
prototyping like transforms of text.


People adopted Php, it was the only real alternative for 
embedding code into html.


People thought those application areas were so boring compared 
to "a general purpose language". It was  not "serious" 
programming areas. So these languages owned those domains for 
many years, and grew big.


"Grew big" _in those domains_, ie they have made no inroads into 
other markets.  This is what I keep pointing out to you: you can 
optimize for one niche and do extremely well there, but then you 
often find yourself stuck in that niche, as Go finds itself today.


Dan recently got the D tests running on the Apple tvOS and 
watchOS simulators: soon you'll be able to run D on your TV or 
watch! :)


That's great fun! But it isn't a business-plan with Swift being 
there already.


It is for those who want to be cross-platform, as D pretty much 
passes all its tests on Android and iOS, while Swift is still 
only on iOS.


Well, right now, D is on far more platforms, so it has a head 
start, though alpha quality on mobile.

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread bachmeier via Digitalmars-d


On Tuesday, 15 December 2015 at 14:41:34 UTC, Adam D. Ruppe wrote:
Just something I want to throw out as a reminder, a part of the 
ranges chapter of my book is public on the packt website:


https://www.packtpub.com/books/content/ranges

and a longer things from Mike Parker's book is too:

https://www.packtpub.com/books/content/understanding-ranges

a lot of us have talked about ranges, it all ought to be nicely 
referenced in the docs as much as we can.


Are those links permanent, so that we don't have to worry about 
broken links in the future?

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread bachmeier via Digitalmars-d


On Tuesday, 15 December 2015 at 08:08:10 UTC, landaire wrote:

Here's an imgur album I created to show some suggestions for 
function signatures: http://imgur.com/a/njHKI


I really like the one titled "Put more emphasis on the function 
signature". With proper spacing and reducing the noise caused by 
the constraints, it's actually readable.

Re: Need DUB pull request reviewers

2015-12-15 Thread Sebastiaan Koppe via Digitalmars-d


On Tuesday, 15 December 2015 at 08:12:59 UTC, Sönke Ludwig wrote:
We have a current shortage of reviewers for the DUB repository 
[1]. Martin is more or less the only one apart from me, but we 
are both currently too busy to get this done in a timely 
manner. If anyone can spare a few minutes (maybe even 
regularly), that could be a great help, even without specific 
knowledge of the code base.


Thanks,
Sönke

[1]: 
https://github.com/D-Programming-Language/dub/pulls?q=is%3Aopen+is%3Apr


I looked at one pr, what do you want me to do? Look for better 
ways of doing things and comment?

Re: Microsoft to contribute to Clang and LLVM project


On Tuesday, 15 December 2015 at 16:17:32 UTC, Joakim wrote:
Unless you articulate what your alternate plan is to make 
things simpler, perhaps along with some github PRs or a DIP, 
things will keep going as they are.


I don't think series of DIPs will change anything. First we need 
to be close to consensus on what ought to be done better.


But since Swift has SIL and Rust is getting MIR, I'm starting to 
think that it would be overall less work to build a new language 
adopted to one of those than polishing Nim, Crystal and D... That 
option didn't really exist before, and it won't resonate well 
with D designers either.


But it is a reasonable strategy when languages seem to be 
converging on semantics that are rather similar.


The basic question is: can you afford to compete?

Yes, if you reuse existing infrastructure, not only what exists, 
but what is coming.



Your asm.js/WebAssembly target is a little different, but using 
the web for such apps is just as dumb.  There are good reasons 
why mobile is ascendant and webapps on the downswing.


I don't think there is a downswing for web-apps.


you can optimize for one niche and do extremely well there, but 
then you often find yourself stuck in that niche, as Go finds 
itself today.


Being stuck in Go's niche would be a fantastic situation for D as 
Go's market penetration might be 20x that of D. The main 
limitation for Go is the Go language authors' vision and 
attitudes. Not really related to the domain.




Which isn't D either, unless you include D because of the GC.


D2 appears to be going for ref counted ownership, so I assume 
that the outcome will be that D2 becomes comparable to Swift with 
ARC.


D2 might have trouble finding a key feature to market after Swift 
adds hygienic macros. Depending on how they go about it.

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread Andrei Alexandrescu via Digitalmars-d

On 12/15/2015 03:08 AM, landaire wrote:

- Runnable examples would be *so* useful! They're present on the
homepage, why can't the examples provided in the inline docs be runnable
as well?

The runnable examples were first provided by nazriel (he's to be found
around here and on IRC). He also started to expand runnable examples,
but then got busy with other things. This would be a great project.

- Linking types, functions, etc. in the function signatures would be
great *if possible*. e.g.:

bool startsWith(alias pred = "a == b", R1, R2)(R1 doesThisStart, R2
withThis) if (isInputRange!R1 && isInputRange!R2 &&
is(typeof(binaryFun!pred(doesThisStart.front, withThis.front)) : bool));

Make bool, isInputRange, typeof, and binaryFun all links to their
definitions. If I don't know what "isInputRange" does, do I really have
to go spend more time to figure out where it lives?

This is a good idea that would require changes to ddoc.

- Add another line break between overloaded methods! Having no
separation between lines makes things very difficult to sort out

This is easy. You need to figure out what separator ddoc introduces
between overloads. "make verbatim" in dlang.org was conceived exactly
for that kind of stuff.

Here's an imgur album I created to show some suggestions for function
signatures: http://imgur.com/a/njHKI

- Dead links = compile error when compiling documentation? This was
annoying when trying to find out more about OutputRanges. The only
resource I found was on the std.range page in the tee definition, and
the link was dead: http://dlang.org/phobos/std_range.html#.tee

There are a number of dead link detectors, online and offline. We just
haven't integrated any although Vladimir was looking into it at a point.
This would be a fine project to get into, too.

- Link to where the code is implemented in Phobos at the time of
compilation. e.g. clicking the actual name of "find" could link me here:
https://github.com/D-Programming-Language/phobos/blob/b6a61d9e719a9d680936db44b98fbb5dd28bf6b1/std/algorithm/searching.d#L1498.
More than once I found that reading the code was more useful than
reading the documentation.

We already have a SOURCE macro for that I think.

I find that I learn best by reading documentation. Go's documentation is
phenomenal and it's very easy to follow and understand (yes, I realize
this is kind of comparing apples to oranges in terms of complexity). I
don't want to have to have to read documentation on understanding the
documentation.

I'm currently on winter break from university and would love to help
contribute some of these changes if people think they're useful as well.

I suggest you start with the simpler stuff, such as better formatting of
overloads. That'll allow you to find your way around the doc build and
see what the macros are and what they generate. It'd be great if you got
the verbatim build going, it's seldom used but very helpful. Make some
css changes while at it. Then move into more involved stuff.

Overall doc building is a territory where there's plenty of easy-hanging
fruit, and the satisfaction is high. I have a great time whenever I get
into it, just less often than I wish.

Andrei

Re: Need DUB pull request reviewers

2015-12-15 Thread Sönke Ludwig via Digitalmars-d


Am 15.12.2015 um 20:03 schrieb Sebastiaan Koppe:

On Tuesday, 15 December 2015 at 08:12:59 UTC, Sönke Ludwig wrote:

We have a current shortage of reviewers for the DUB repository [1].
Martin is more or less the only one apart from me, but we are both
currently too busy to get this done in a timely manner. If anyone can
spare a few minutes (maybe even regularly), that could be a great
help, even without specific knowledge of the code base.

Thanks,
Sönke

[1]:
https://github.com/D-Programming-Language/dub/pulls?q=is%3Aopen+is%3Apr


I looked at one pr, what do you want me to do? Look for better ways of
doing things and comment?


Could be ideas how to do things better, or opinions on the particular 
approaches, but most importantly looking for mistakes of any sort and 
ensuring a base quality standard (sufficient documentation/tests etc.).

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread landaire via Digitalmars-d

On Tuesday, 15 December 2015 at 02:39:16 UTC, Steven 
Schveighoffer wrote:

On 12/14/15 9:34 PM, Steven Schveighoffer wrote:


InputRange find(alias pred = "a == b", InputRange, 
Element)(InputRange

haystack, Element needle) if (isInputRange!InputRange &&
is(typeof(binaryFun!pred(haystack.front, needle)) : bool));
InputRange find(alias pred, InputRange)(InputRange haystack) if
(isInputRange!InputRange);
R1 find(alias pred = "a == b", R1, R2)(R1 haystack, R2 needle) 
if

(isForwardRange!R1 && isForwardRange!R2 &&
is(typeof(binaryFun!pred(haystack.front, needle.front)) : 
bool) &&

!isRandomAccessRange!R1);
Tuple!(Range, size_t) find(alias pred = "a == b", Range,
Ranges...)(Range haystack, Ranges needles) if (Ranges.length > 
1 &&

is(typeof(startsWith!pred(haystack, needles;
Range1 find(Range1, alias pred, Range2)(Range1 haystack,
BoyerMooreFinder!(pred, Range2) needle);

If you can decipher this into what find actually will accept, 
then you
have more patience than me. I think what I wanted (it's 
difficult to
remember) is whether I could pass in a subrange for find to 
search for
as the needle. It appears to reject cases where the haystack 
is a random

access range and the needle is a range (but it does work).


Heh, looking at the source, I see I was a victim of improper 
documentation.


There are 2 additional overloads of find that are NOT 
DOCUMENTED.


It's likely that the 2 overloads vary only by constraints, and 
that's why they are not documented.


But as a user, again, I shouldn't have to care what the 
constraints are specifically.


-Steve


I started exploring D a couple of months ago and I was the 
original poster in the reddit thread who sparked this discussion. 
While on the topic of documentation I wanted to quickly put in my 
thoughts about what frustrated me with the documentation:


- I didn't understand the visual hierarchy for templates at 
first. e.g. canFind: 
https://dlang.org/phobos/std_algorithm_searching.html#canFind. I 
don't remember the exact examples but I had to look at the source 
code to understand what this was trying to show me


- Runnable examples would be *so* useful! They're present on the 
homepage, why can't the examples provided in the inline docs be 
runnable as well?


- Linking types, functions, etc. in the function signatures would 
be great *if possible*. e.g.:


bool startsWith(alias pred = "a == b", R1, R2)(R1 doesThisStart, 
R2 withThis) if (isInputRange!R1 && isInputRange!R2 && 
is(typeof(binaryFun!pred(doesThisStart.front, withThis.front)) : 
bool));


Make bool, isInputRange, typeof, and binaryFun all links to their 
definitions. If I don't know what "isInputRange" does, do I 
really have to go spend more time to figure out where it lives?


- Add another line break between overloaded methods! Having no 
separation between lines makes things very difficult to sort out


Here's an imgur album I created to show some suggestions for 
function signatures: http://imgur.com/a/njHKI


- Dead links = compile error when compiling documentation? This 
was annoying when trying to find out more about OutputRanges. The 
only resource I found was on the std.range page in the tee 
definition, and the link was dead: 
http://dlang.org/phobos/std_range.html#.tee


- Link to where the code is implemented in Phobos at the time of 
compilation. e.g. clicking the actual name of "find" could link 
me here: 
https://github.com/D-Programming-Language/phobos/blob/b6a61d9e719a9d680936db44b98fbb5dd28bf6b1/std/algorithm/searching.d#L1498. More than once I found that reading the code was more useful than reading the documentation.


I find that I learn best by reading documentation. Go's 
documentation is phenomenal and it's very easy to follow and 
understand (yes, I realize this is kind of comparing apples to 
oranges in terms of complexity). I don't want to have to have to 
read documentation on understanding the documentation.


I'm currently on winter break from university and would love to 
help contribute some of these changes if people think they're 
useful as well.

Re: I Did It! Calling D Library from Objective C in XCode on OSX

2015-12-15 Thread Mike McKee via Digitalmars-d-learn

On Tuesday, 15 December 2015 at 07:52:50 UTC, Jacob Carlborg 
wrote:

Could you please add "-v" do the command line when compiling.


Mine was completely different:

$ dmd -v test.d
binarydmd
version   v2.069
config/usr/local/bin/dmd.conf
parse test
importall main
importobject(/Library/D/dmd/src/druntime/import/object.d)
semantic  main
entry main  test.d
semantic2 main
test.d(7): Error: undefined identifier 'selector'
test.d(13): Error: undefined identifier 'selector'
test.d(14): Error: undefined identifier 'selector'

Also, look what I have in my import/core folder. It doesn't match 
yours:


atomic.d  checkedint.d  demangle.dinternal/ memory.d  
simd.dsync/ thread.d  vararg.d
bitop.d   cpuid.d   exception.d   math.druntime.d 
stdc/ sys/  time.d


So, then I uninstalled dmd via brew, but found it left a 
/Library/D folder behind. Therein lies the problem. So, I did 
sudo brew uninstall --force dmd, sudo su, removed the /Library/D 
folder, and then sudo brew install dmd. Now it works!


volomike:cpptod4 mike$ dmd -m64 -L-framework -LFoundation test.d
volomike:cpptod4 mike$ ls
testtest.d  test.o
volomike:cpptod4 mike$ ./test
2015-12-15 03:07:52.669 test[7308:116958] Hello World!
volomike:cpptod4 mike$

[Issue 15444] [Interfacing to Objective-C]

2015-12-15 Thread Ola Fosheim Grøstad via Digitalmars-d

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

Maximo  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Maximo  ---
Here's the fix. It has to do with El Capitan and brew.

I found the fix:

$ sudo brew update
$ sudo brew uninstall --force dmd
$ sudo su
$ cd /Library
$ rm -rfd D
$ exit
$ sudo brew install dmd

This not only takes one from an older dmd to a more current version (in my
case, from 2.068 to 2.069), but it also fixes a bug where /Library/D doesn't
get updated. (Besides, the El Capitan version of 2.069 now doesn't use
/Library/D.)

When I did that, I found I was able to compile like so:

volomike:cpptod4 mike$ dmd -m64 -L-framework -LFoundation test.d
volomike:cpptod4 mike$ ls
testtest.dtest.o
volomike:cpptod4 mike$ ./test
2015-12-15 03:07:52.669 test[7308:116958] Hello World!
volomike:cpptod4 mike$

So, it not only used an Objective C NSString object, but it fed it to NSLog and
I got console output in NSLog format.

--

Need DUB pull request reviewers

2015-12-15 Thread Sönke Ludwig via Digitalmars-d

We have a current shortage of reviewers for the DUB repository [1]. 
Martin is more or less the only one apart from me, but we are both 
currently too busy to get this done in a timely manner. If anyone can 
spare a few minutes (maybe even regularly), that could be a great help, 
even without specific knowledge of the code base.


Thanks,
Sönke

[1]: https://github.com/D-Programming-Language/dub/pulls?q=is%3Aopen+is%3Apr

Re: Error: undefined identifier 'selector'

2015-12-15 Thread Mike McKee via Digitalmars-d-learn


I found the fix:

$ sudo brew update
$ sudo brew uninstall --force dmd
$ sudo su
$ cd /Library
$ rm -rfd D
$ exit
$ sudo brew install dmd

This not only takes one from an older dmd to a more current 
version (in my case, from 2.068 to 2.069), but it also fixes a 
bug where /Library/D doesn't get updated. (Besides, the El 
Capitan version of 2.069 now doesn't use /Library/D.)


When I did that, I found I was able to compile like so:

volomike:cpptod4 mike$ dmd -m64 -L-framework -LFoundation test.d
volomike:cpptod4 mike$ ls
testtest.d  test.o
volomike:cpptod4 mike$ ./test
2015-12-15 03:07:52.669 test[7308:116958] Hello World!
volomike:cpptod4 mike$

So, it not only used an Objective C NSString object, but it fed 
it to NSLog and I got console output in NSLog format.

Re: Some feedback on the website.

2015-12-15 Thread Jacob Carlborg via Digitalmars-d


On 2015-12-15 08:07, deadalnix wrote:

[snip]

All of this is quite damaging to D's brand.

Even even though I'm not a webdev, I've been working in growth for a
long time and these things matter. I don't know DDoc, and I'm not sure
this is a very smart move. That raise the barrier to contribute to the
website. The intersection of people that know webdev and DDoc is just
mostly existent.

The time I can spend on this is quite limited due to SDC, work and
personal life. Learning DDoc is just too big of a barrier. Yet I can
provide support to anyone that is willing to help.

Last but not least, it wouldn't hurt to hire a designer to have
something slick.


I agree with all this, especially the last part about Ddoc.

--
/Jacob Carlborg

Re: Some feedback on the website.

2015-12-15 Thread Gary Willoughby via Digitalmars-d

On Tuesday, 15 December 2015 at 08:26:44 UTC, Jacob Carlborg 
wrote:

On 2015-12-15 08:07, deadalnix wrote:

[snip]

All of this is quite damaging to D's brand.

Even even though I'm not a webdev, I've been working in growth 
for a
long time and these things matter. I don't know DDoc, and I'm 
not sure
this is a very smart move. That raise the barrier to 
contribute to the
website. The intersection of people that know webdev and DDoc 
is just

mostly existent.

The time I can spend on this is quite limited due to SDC, work 
and
personal life. Learning DDoc is just too big of a barrier. Yet 
I can

provide support to anyone that is willing to help.

Last but not least, it wouldn't hurt to hire a designer to have
something slick.


I agree with all this, especially the last part about Ddoc.


We've all said time and time again if ddoc wasn't used for the 
entire site more people would help with it. Ddoc makes sense for 
the documentation but not everything else.


I thought Sociomantic were re-designing and sorting the site out?

Re: Use https: for wikipedia links


On Monday, 14 December 2015 at 21:56:29 UTC, Walter Bright wrote:
Another advantage is that we'll know which sites support 
https:. I did some experimenting and was surprised at how few 
news sites support it, for example.


https makes it impossible to use shared local caches (proxy), 
there is extra processing costs and if you embed content from 
other providers they might not provide https (which results in 
ugly warnings in browsers).

[Issue 13678] TypeInfo.init is inconsistent

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

ZombineDev  changed:

   What|Removed |Added

   Keywords|preapproved |

--

[Issue 13678] TypeInfo.init is inconsistent

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

ZombineDev  changed:

   What|Removed |Added

   Keywords||preapproved
 CC||petar.p.ki...@gmail.com

--

[Issue 15444] [Interfacing to Objective-C]

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

Jacob Carlborg  changed:

   What|Removed |Added

 CC||d...@me.com
   Severity|major   |minor

--- Comment #1 from Jacob Carlborg  ---
I added the code below for reference. It works perfectly fine for me using
Yosemite. It's most likely an issue with the installation of the compiler.

// test.d
module main;

extern (Objective-C)
interface Class
{
NSString alloc() @selector("alloc");
}

extern (Objective-C)
interface NSString
{
NSString initWithUTF8String(in char* str) @selector("initWithUTF8String:");
void release() @selector("release");
}

extern (C) void NSLog(NSString, ...);
extern (C) Class objc_lookUpClass(in char* name);

void main()
{
auto cls = objc_lookUpClass("NSString");
auto str = cls.alloc().initWithUTF8String("Hello World!");
NSLog(str);
str.release();
}

--

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread Jacob Carlborg via Digitalmars-d-learn


On Monday, 14 December 2015 at 19:56:29 UTC, dnewbie wrote:

On Monday, 14 December 2015 at 19:04:46 UTC, bachmeier wrote:
It's unanimous, at least among the three of us posting in this 
Reddit thread:

...


Take for example C# Docs: 
https://msdn.microsoft.com/en-us/library/system.collections.arraylist.addrange.aspx


Syntax C#:

public virtual void AddRange(
ICollection c
)

Parameters:
c
Type: System.Collections.ICollection
The ICollection whose elements should be added to the end 
of the ArrayList. The collection itself cannot be null, but it 
can contain elements that are null.


Clean, simple and instructive!



You are really comparing apples to oranges. You should look at 
signatures of the LINQ functions:


https://msdn.microsoft.com/en-us/library/bb535047(v=vs.100).aspx
https://msdn.microsoft.com/en-us/library/bb534732(v=vs.100).aspx
https://msdn.microsoft.com/en-us/library/hh229621(v=vs.103).aspx
https://msdn.microsoft.com/en-us/library/hh229412(v=vs.103).aspx
https://msdn.microsoft.com/en-us/library/hh211747(v=vs.103).aspx
https://msdn.microsoft.com/en-us/library/hh211886(v=vs.103).aspx
https://msdn.microsoft.com/en-us/library/hh229310(v=vs.103).aspx
https://msdn.microsoft.com/en-us/library/hh229364(v=vs.103).aspx
https://msdn.microsoft.com/en-us/library/hh229473(v=vs.103).aspx
https://msdn.microsoft.com/en-us/library/hh212066(v=vs.103).aspx
https://msdn.microsoft.com/en-us/library/hh244290(v=vs.103).aspx
https://msdn.microsoft.com/en-us/library/hh229392(v=vs.103).aspx
https://msdn.microsoft.com/en-us/library/hh229708(v=vs.103).aspx
https://msdn.microsoft.com/en-us/library/hh229926(v=vs.103).aspx
https://msdn.microsoft.com/en-us/library/hh229008(v=vs.103).aspx
https://msdn.microsoft.com/en-us/library/hh229778(v=vs.103).aspx
https://msdn.microsoft.com/en-us/library/hh229729(v=vs.103).aspx

And then you have one of the most used methods - .Count:
https://msdn.microsoft.com/en-us/library/bb338038(v=vs.100).aspx

Where presumably, for the sake of simplicity, the docs don't even 
bother to mention that it is almost always O(n), because non of 
the Enumerable extention methods preserve the underlying 
ICollection interace.

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread Jacob Carlborg via Digitalmars-d


On 2015-12-15 04:51, Jakob Ovrum wrote:


One possible trick is to use multiple `Params:` sections. Optional
parameters can be described as such in the parameter description to
reduce the number of `Params:` sections needed.


Yardoc, used in the Ruby world, allows to do something similar. It has 
the "overload" tag [1] which allows you specify multiple signatures, 
including parameters, in the documentation for a single method in the 
source code.


I should add that Ruby doesn't support overloading methods.

[1] http://www.rubydoc.info/gems/yard/file/docs/Tags.md#overload

--
/Jacob Carlborg

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread Adrian Matoga via Digitalmars-d


On Tuesday, 15 December 2015 at 01:10:01 UTC, Chris Wright wrote:

This reminds me of the Tango strategy for this kind of thing.

tango.core.Array was arranged like this:

version(TangoDoc) {
  /** Documentation comment. */
  bool isSameLangth(Range1, Range2)(Range1 r1, Range2 r2) {
return true;
  }
} else {
  bool isSameLength(Range1, Range2)(Range1 r1, Range2 r2)
if (
  isInputRange!Range1 &&
  isInputRange!Range2 &&
  !isInfinite!Range1 &&
  !isInfinite!Range2) {
// actual implementation
  }
}


Fantastic example of why this strategy should be just banned. You 
need to duplicate the signature in the source, and you are free 
to make any mistake that won't be caught by the compiler, such as 
the typo in the word 'Length' here. A beginner then copies the 
signature and fills in the argument part, and then spends minutes 
decrypting error messages or even grepping Phobos source to find 
out that the name of the function should be spelled 
'isSameLength', as it's quite easy to overlook, especially when 
you copy-paste from the official documentation, which you expect 
to be correct.

Re: I Did It! Calling D Library from Objective C in XCode on OSX


On 2015-12-14 20:13, bachmeier wrote:

Is it okay if I copy your post to the wiki at this link?

http://wiki.dlang.org/Cookbook


Please don't. There's a lot of errors and weird things in the post. It 
doesn't really do what the title says. At least it's not interesting at 
all since it uses the C++ interface to call D, not the Objective-C 
interface. Which there is no reason to do, it could just use the C 
interface. No point in mixing C++ in the picture.


--
/Jacob Carlborg

Re: I Did It! Calling D Library from Objective C in XCode on OSX

2015-12-15 Thread Jacob Carlborg via Digitalmars-d-learn


On 2015-12-15 09:08, Mike McKee wrote:

On Tuesday, 15 December 2015 at 07:52:50 UTC, Jacob Carlborg wrote:

Could you please add "-v" do the command line when compiling.


Mine was completely different:

$ dmd -v test.d
binarydmd
version   v2.069
config/usr/local/bin/dmd.conf
parse test
importall main
importobject(/Library/D/dmd/src/druntime/import/object.d)
semantic  main
entry main  test.d
semantic2 main
test.d(7): Error: undefined identifier 'selector'
test.d(13): Error: undefined identifier 'selector'
test.d(14): Error: undefined identifier 'selector'

Also, look what I have in my import/core folder. It doesn't match yours:

atomic.d  checkedint.d  demangle.dinternal/ memory.d
simd.dsync/ thread.d  vararg.d
bitop.d   cpuid.d   exception.d   math.druntime.d
stdc/ sys/  time.d

So, then I uninstalled dmd via brew, but found it left a /Library/D
folder behind. Therein lies the problem. So, I did sudo brew uninstall
--force dmd, sudo su, removed the /Library/D folder, and then sudo brew
install dmd. Now it works!


So a broken installer. I recommend using DVM [1]. It can install 
multiple versions of DMD and they live side by side completely independent.



volomike:cpptod4 mike$ dmd -m64 -L-framework -LFoundation test.d
volomike:cpptod4 mike$ ls
testtest.dtest.o
volomike:cpptod4 mike$ ./test
2015-12-15 03:07:52.669 test[7308:116958] Hello World!
volomike:cpptod4 mike$


Cool :)

[1] https://github.com/jacob-carlborg/dvm

--
/Jacob Carlborg

[Issue 13676] [ddoc] DDoc should wrap each part of function declaration in dedicated macro to allow more readable formatting

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

ZombineDev  changed:

   What|Removed |Added

   Keywords||preapproved
 CC||petar.p.ki...@gmail.com

--- Comment #2 from ZombineDev  ---
Andrei preapproved this enhancement:
http://forum.dlang.org/post/n4o22t$r48$1...@digitalmars.com

--

Re: We need better documentation for functions with ranges and templates


On Tuesday, 15 December 2015 at 09:57:00 UTC, ZombineDev wrote:


And then you have one of the most used methods - .Count:
https://msdn.microsoft.com/en-us/library/bb338038(v=vs.100).aspx

Where presumably, for the sake of simplicity, the docs don't 
even bother to mention that it is almost always O(n), because 
non of the Enumerable extention methods preserve the underlying 
ICollection interace.


I honestly think that the documentation of walkLength in Phobos 
is much better, though an example would be nice:

https://dlang.org/phobos/std_range_primitives.html#.walkLength

Re: Some feedback on the website.

2015-12-15 Thread anonymous via Digitalmars-d


On 15.12.2015 08:07, deadalnix wrote:

The navigation can get very confusing. The forum and the site look the
same, but the logo in the top right bring back to the site index/forum
index . That is not what is expected. If it looks the same, it should
probably be doing the same.


Agreed. And the phobos pages have yet another navigation variant that 
looks similar but has different elements.



On the website, the forum is hidden in the community menu in the middle
of the left bar called community. If it warrant its own domain name, it
should probably not be hidden.


The accordion menus have been introduced somewhat recently (early 2015 
IIRC) to make the menu more structured, less crowded. Recently, a number 
of things have been suggested to be put at the top level. The problem 
is, if we put everything at the top level, we end up with an overcrowded 
menu again.


Not saying that the forum shouldn't be at the top. But if we move it up, 
we should probably move something else down.



On the website, categories in the left bar, there are
+ and - sign that looks like button to open/close the category, but they
aren't button. It breaks common expectations.


Not sure what you're asking for here. The +/- signs are part of a button 
that expands/collapses the sub menus. What behavior would you expect/prefer?



There is no way to search the spec.


Is implemented and merged. The site just hasn't been updated yet.

https://github.com/D-Programming-Language/dlang.org/pull/1162


Home page:

[...]

Our is just messed up. The download link is there, but just doesn't
stand out (same presentation as this week in D, videos from DConf, as
big as the changelog).


I agree, others don't. See discussion on 
 where I 
originally proposed this download button: 
.


Now, I don't want to complain about people not liking the design. And I 
pulled the design changes back rather quickly, because the functionality 
was supposed to be the subject of the PR. A big, flashy download button 
has not exactly been rejected.

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread rumbu via Digitalmars-d


On Tuesday, 15 December 2015 at 09:57:00 UTC, ZombineDev wrote:



And then you have one of the most used methods - .Count:
https://msdn.microsoft.com/en-us/library/bb338038(v=vs.100).aspx

Where presumably, for the sake of simplicity, the docs don't 
even bother to mention that it is almost always O(n), because 
non of the Enumerable extention methods preserve the underlying 
ICollection interace.


Looking at the .net source code, the Count extension method is 
also doing a best effort "count" by querying the ICollection 
interface.


 public static int Count(this IEnumerable 
source)

{
  if (source == null)
throw Error.ArgumentNull("source");
  ICollection collection1 = source as 
ICollection;

  if (collection1 != null)
return collection1.Count;
  ICollection collection2 = source as ICollection;
  if (collection2 != null)
return collection2.Count;
  int num = 0;
  using (IEnumerator enumerator = 
source.GetEnumerator())

  {
while (enumerator.MoveNext())
  checked { ++num; }
  }
  return num;
}

The Remarks section clearly states the same thing:

"If the type of source implements ICollection, that 
implementation is used to obtain the count of elements. 
Otherwise, this method determines the count."



And personally, I found the MS remark more compact and more user 
friendly than:


"This is a best-effort implementation of length for any kind of 
range.
If hasLength!Range, simply returns range.length without checking 
upTo (when specified). Otherwise, walks the range through its 
length and returns the number of elements seen. Performes Ο(n) 
evaluations of range.empty and range.popFront(), where n is the 
effective length of range."


Not everybody is licensed in computational complexity theory to 
understand what O(n) means.

Re: Some feedback on the website.

2015-12-15 Thread tcak via Digitalmars-d

On Tuesday, 15 December 2015 at 08:31:40 UTC, Gary Willoughby
wrote:
On Tuesday, 15 December 2015 at 08:26:44 UTC, Jacob Carlborg
wrote:

On 2015-12-15 08:07, deadalnix wrote:

[snip]

All of this is quite damaging to D's brand.

Even even though I'm not a webdev, I've been working in
growth for a
long time and these things matter. I don't know DDoc, and I'm
not sure
this is a very smart move. That raise the barrier to
contribute to the
website. The intersection of people that know webdev and DDoc
is just

mostly existent.

The time I can spend on this is quite limited due to SDC,
work and
personal life. Learning DDoc is just too big of a barrier.
Yet I can

provide support to anyone that is willing to help.

Last but not least, it wouldn't hurt to hire a designer to
have

something slick.

I agree with all this, especially the last part about Ddoc.

We've all said time and time again if ddoc wasn't used for the
entire site more people would help with it. Ddoc makes sense
for the documentation but not everything else.

I thought Sociomantic were re-designing and sorting the site
out?

The harder it is made for people to contribute the system for
fixations, the lesser changes are seen.

It bothers me so much to report a bug on https://issues.dlang.org
. The reason is that the password stops working for me. Firefox
saves the username and password. I try to use it after 2 months,
and whops, system says it isn't available.

Another issue is contributing the website's design. I reported a
problem on the forum that is about the title problem of web page.
http://forum.dlang.org/thread/pymfyjuckxbvjolxl...@forum.dlang.org Still the problem will be fixed.

Now I am asking, IF I was to make some changes for web site's
look, and post a picture of them (CSS changes mostly), would it
be okay to discuss it here, and apply them in short notice? If a
change would take 1 week, that doesn't work. I am

offering help here.

[Issue 15444] [Interfacing to Objective-C]

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

ag0ae...@gmail.com changed:

   What|Removed |Added

 CC||ag0ae...@gmail.com
 Resolution|FIXED   |WORKSFORME

--- Comment #3 from ag0ae...@gmail.com ---
Changing from FIXED to WORKSFORME since this was apparently an installation
problem.

--

Re: http://wiki.dlang.org/Starting_as_a_Contributor reorganization

On Monday, 14 December 2015 at 20:47:27 UTC, Andrei Alexandrescu 
wrote:
I see Vladimir and Jack did these changes. Could you please 
restructure the document into three - one for each of the OSs 
we support?


Sure, but we need to find a way to make sure that the 
decentralization doesn't cause the info to become stale, as the 
reason the different pages were consolidated was the wildly 
inaccurate info on some old pages. I also still have to 
incorporate http://wiki.dlang.org/Using_Git_on_Windows into the 
page.

Re: Some feedback on the website.


On Tuesday, 15 December 2015 at 11:13:51 UTC, anonymous wrote:
I agree, others don't. See discussion on 
 
where I originally proposed this download button: 
.


Now, I don't want to complain about people not liking the 
design. And I pulled the design changes back rather quickly, 
because the functionality was supposed to be the subject of the 
PR. A big, flashy download button has not exactly been rejected.


I get more and more irritated by how non factual the whole IT 
scene is. Why does it boils down to opinion ?


A good rule of thumb: if you can't notice and click on the button 
immediately while drunk, it is not big and obvious enough.


The proposed design is better that what we have now, but it is 
still clumsy. There are box into box, and way too much infos.


It is not opinion, it is what works. If one is of different 
opinion, there is an easy way to settle: do an A/B test and 
settle. I can tell you, on that one the result that would come 
out of this are fairly obvious.

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread Adrian Matoga via Digitalmars-d


On Tuesday, 15 December 2015 at 16:12:18 UTC, Chris Wright wrote:

On Tue, 15 Dec 2015 09:09:43 +, Adrian Matoga wrote:


Fantastic example of why this strategy should be just banned.


Just as well I wasn't recommending it as a long-term solution. 
I was more offering it as additional evidence that template 
definitions can get a bit large and people have known that this 
is a problem for documentation for eight years now.


"Banned" is a strong term. Perhaps you simply meant it should 
not be recommended and should not be used in Phobos?


Yes, perhaps "strongly discouraged" would be a more appropriate 
wording.
version(StdDdoc) already appears about 40 times in Phobos, 
sometimes wrapping quite large blocks of declarations. I doubt 
the maintainability of such setup in the long term.

Re: Some feedback on the website.

2015-12-15 Thread anonymous via Digitalmars-d


On 15.12.2015 22:50, deadalnix wrote:

I get more and more irritated by how non factual the whole IT scene is.
Why does it boils down to opinion ?

A good rule of thumb: if you can't notice and click on the button
immediately while drunk, it is not big and obvious enough.

The proposed design is better that what we have now, but it is still
clumsy. There are box into box, and way too much infos.

It is not opinion, it is what works. If one is of different opinion,
there is an easy way to settle: do an A/B test and settle. I can tell
you, on that one the result that would come out of this are fairly obvious.


What "works" means is still debatable. Is it a goal to get users to the 
download quickly, or are other things equally or more important?


Also, we don't really have the resources to do studies on these things, 
do we? So when you say that it's obviously this way and someone else 
says it's obviously that way, we're back to opinions.


Also, to reiterate, a more noticeable download button is not off the 
table. I pulled back all style changes in that PR to focus on the 
functionality first (which I kinda gave up on by now, too, because it 
turned out to be more difficult than I had hoped).

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread landaire via Digitalmars-d

On Tuesday, 15 December 2015 at 19:51:37 UTC, Andrei Alexandrescu 
wrote:
I suggest you start with the simpler stuff, such as better 
formatting of overloads. That'll allow you to find your way 
around the doc build and see what the macros are and what they 
generate. It'd be great if you got the verbatim build going, 
it's seldom used but very helpful. Make some css changes while 
at it. Then move into more involved stuff.


Overall doc building is a territory where there's plenty of 
easy-hanging fruit, and the satisfaction is high. I have a 
great time whenever I get into it, just less often than I wish.



Andrei


Thanks for the feedback Andrei and everyone else. I'll start 
stabbing at things this weekend. Setting up the site in a vagrant 
environment shouldn't be too difficult. I don't want to shoot for 
too much but I'll also see about setting up a staging environment 
on my server to display the changes on.

Re: Some feedback on the website.

On Tuesday, 15 December 2015 at 10:54:09 UTC, tcak wrote:
It bothers me so much to report a bug on
https://issues.dlang.org . The reason is that the password
stops working for me. Firefox saves the username and password.
I try to use it after 2 months, and whops, system says it isn't
available.

Never had this happen to me. What browser and OS are you using,
because issues.dlang.org runs on bugzilla, which is a very
popular piece of software that is used all over the place.

Another issue is contributing the website's design. I reported
a problem on the forum that is about the title problem of web
page.
http://forum.dlang.org/thread/pymfyjuckxbvjolxl...@forum.dlang.org Still the problem will be fixed.

I made a PR for that issue
https://github.com/D-Programming-Language/dlang.org/pull/1167

It has yet to be reviewed by someone with merge rights.

Now I am asking, IF I was to make some changes for web site's
look, and post a picture of them (CSS changes mostly), would it
be okay to discuss it here, and apply them in short notice? If
a change would take 1 week, that doesn't work. I am

offering help here.

Sorry, but it's completely infeasible for anyone to propose a
sweeping style change and expect it to go through quickly,
especially sense I can guarantee that there are going to be
issues with the first draft you make. If you were to make a PR,
I'd expect it to be either accepted or rejected after maybe two
months of deliberation, if you're lucky. This is the nature of
volunteer work.

Re: Some feedback on the website.

On Tuesday, 15 December 2015 at 13:42:29 UTC, Andrei Alexandrescu 
wrote:

On 12/15/15 5:54 AM, tcak wrote:
The harder it is made for people to contribute the system for 
fixations,

the lesser changes are seen.


I don't think we've had many contributions via the "Improve 
this page" button.




I don't know how representative it is, but once in a while, i 
forgot all of this is in DDoc, I notice something, what to do a 
quick patch, and end up being reminded this is in DDoc and I have 
no idea how to fix the thing, because suddenly, what looked like 
a quick fix end up being learning a new macro language.

[Issue 14088] add "Getting Started" page to dlang.org

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

Jack Stouffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||j...@jackstouffer.com
 Resolution|--- |FIXED

--

[Issue 15449] CSS and JS files should be minified and concatenated

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

Jack Stouffer  changed:

   What|Removed |Added

   Keywords||performance
   Hardware|x86 |All
 OS|Mac OS X|All

--

[Issue 15450] ICE during CTFE of legit function

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

--- Comment #1 from Andrei Alexandrescu  ---
Shorter repro. It's the labeled continue that's the problem:

struct BigO
{
struct Atom
{
int id;
double exp;
double logExp;
}

private Atom[][] terms;

int opCmp(const BigO rhs) const
{
int result = 0;
bigone:
foreach (ref l; terms)
{
foreach (ref r; rhs.terms)
{
continue bigone;
}
}
return result;
}
}

static immutable
linear = BigO([ [ BigO.Atom(0, 1, 0) ] ]);

static assert(linear >= linear);

--

Re: Some feedback on the website.


On Tuesday, 15 December 2015 at 22:17:33 UTC, anonymous wrote:
What "works" means is still debatable. Is it a goal to get 
users to the download quickly, or are other things equally or 
more important?




Download is the first step in your tunnel. If one can't get to 
the download step, one can't use D. And if one can't use D, one 
doesn't care about everything else on the website.


Also, we don't really have the resources to do studies on these 
things, do we? So when you say that it's obviously this way and 
someone else says it's obviously that way, we're back to 
opinions.




Ignoring metrics is always more expensive. Also, I'm not stating 
opinion and preference here. Personally, I don't care about the 
download button, I already downloaded things. But that's a 
classic tunnel optimization.


Also, to reiterate, a more noticeable download button is not 
off the table. I pulled back all style changes in that PR to 
focus on the functionality first (which I kinda gave up on by 
now, too, because it turned out to be more difficult than I had 
hoped).

LDC with Profile-Guided Optimization (PGO)

2015-12-15 Thread Johan Engelen via Digitalmars-d


Hi all,
  I have been working on adding profile-guided optimization (PGO) 
to LDC [1][2][3].
At this point, I'd like to hear your input and hope you can help 
with testing!


Unfortunately, to try it out, you will need to build LDC with 
LLVM3.7 yourself. PGO should work on OS X, Linux, and Windows.


A first implementation is mostly complete now: it can generate an 
executable that will output profile data, and it can use profile 
data during a second compilation pass (and it will tell LLVM 
about branch frequencies). LDC does not do any PGO optimizations 
(yet): LLVM should do that.


It works like PGO with Clang, with the fprofile-instr-generate 
and fprofile-instr-use cmdline options [4]:

ldc2 -fprofile-instr-generate=test.profraw -run test.d
llvm-profdata merge test.profraw -output test.profdata
ldc2 -profile-instr-use=test.profdata test.d -of=test
You should now have the executable "test" with an amazing 
performance boost ;-)


You can inspect the generated code using LDC's -output-ll switch. 
Functions should be annotated with call frequencies, and most 
branches should be annotated with branch_weights metadata. For 
example:

define void @for_loop() #0 !prof !12
...
!12 = !{!"function_entry_count", i64 234}

for "void for_loop()" that is called 234 times, and

br i1 %3, label %if, label %else, !prof !17
...
!17 = !{!"branch_weights", i32 5, i32 3}

for "if (condition) {...} else {...}"
The branch_weights have an offset of 1, so the above means that 
the condition was true 4 times, and false 2 times. If a certain 
piece of code is never executed, no metadata is added (i.e. you 
won't see {!"branch_weights", i32 1, i32 1}). Some branches are 
intentionally not instrumented/annotated if they lead to 
terminating code (e.g. array boundschecks and auto-generated 
nullptr checks on this at class method entry).


I hope you will be able to test and comment on the work. I am 
very interested in hearing about performance 
gains(/losses/no-change) for your programs. I am curious to learn 
for what kinds of code it makes a difference in practice.


Thanks!
  Johan

(future work will probably include coverage analysis (llvm-cov) 
and support for sampling-based profiles, which should fit 
naturally with the current implementation)


[1] http://wiki.dlang.org/LDC_LLVM_profiling_instrumentation
[2] https://github.com/JohanEngelen/ldc/tree/pgo  (warning: I 
will rebase soon)

[3] https://github.com/ldc-developers/ldc/pull/1219
[4] 
http://clang.llvm.org/docs/UsersManual.html#profiling-with-instrumentation

[Issue 15450] ICE during CTFE of legit function

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

ag0ae...@gmail.com changed:

   What|Removed |Added

   Keywords||ice
 CC||ag0ae...@gmail.com
   Severity|normal  |regression

--- Comment #2 from ag0ae...@gmail.com ---
2.069.2 gives "Error: cannot interpret  at compile time", which is at
least not an ICE.

git head (6cd7173) gives "core.exception.AssertError@dinterpret.d(1008):
Assertion failure", making this a diagnostic regression.

Further reduced test case:

static assert({
bigone: foreach (l; [0]) continue bigone;
return true;
}());


--

[Issue 15448] New: dlang.org should use gzip compression on all text files

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

  Issue ID: 15448
   Summary: dlang.org should use gzip compression on all text
files
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

--

[Issue 15448] dlang.org should use gzip compression on all text files

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

Jack Stouffer  changed:

   What|Removed |Added

   Keywords||performance
   Hardware|x86 |All
 OS|Mac OS X|All

--

[Issue 15450] ICE during CTFE of legit function

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

--- Comment #3 from Andrei Alexandrescu  ---
Nice, thanks. Hmmm, I was running v2.068.2. So should we qualify this as
silently fixed?

--

[Issue 15450] ICE during CTFE of legit function

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

--- Comment #4 from Andrei Alexandrescu  ---
Oh wait, the HEAD doesn't work either (albeit with a different diagnostic). So
this bug stands. Thanks!

--

Re: Some feedback on the website.

On Tuesday, 15 December 2015 at 13:42:29 UTC, Andrei Alexandrescu 
wrote:
Yes, the css has grown long in the teeth. Just replacing it 
with something else is needed, even if it's not an actual 
improvement.


I have to disagree with you heavily on this point. Changing the 
look and feel of a site just for the sake of change is a lot of 
work for little gain. The issue with the site is not the CSS in 
the majority of cases but the content.


Also, you saying "even if it's not an actual improvement"  is a 
real head scratcher for me. We need a change even if it makes 
things worse?


A related idea is to investigate the use of 
http://sourcefoundry.org/hack/ for the code samples. Takers?


This would be rather simple to implement, but custom fonts make 
pages load slower, on average 100-150ms. When the front page 
already takes 2secs+ to load entirely, I would want to do some 
optimizations first before this happens.


Some easy wins which could net a 500ms+ speedup:

* use gzip on everything
* minify and concatenate css files
* minify and concatenate js files
* use cache busting plus long cache times in HTTP headers

Unfortunately, all of these require the server admin (whoever 
that is) to do it and can't be done via PR.

[Issue 15449] New: CSS and JS files should be minified and concatenated

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

  Issue ID: 15449
   Summary: CSS and JS files should be minified and concatenated
   Product: D
   Version: D2
  Hardware: x86
OS: Mac OS X
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

This reduces the number of separate network requests, each of which incur
non-trivial overhead, and reduces the total data transferred.

--

Re: Some feedback on the website.


On Tuesday, 15 December 2015 at 22:45:30 UTC, Jack Stouffer wrote:

* use gzip on everything
* minify and concatenate css files
* minify and concatenate js files
* use cache busting plus long cache times in HTTP headers


I made bug reports for all of these

https://issues.dlang.org/show_bug.cgi?id=15451
https://issues.dlang.org/show_bug.cgi?id=15449
https://issues.dlang.org/show_bug.cgi?id=15448

[Issue 15275] Documentation for OutputRange lacking

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||j...@jackstouffer.com

--- Comment #1 from Jack Stouffer  ---
This PR is fixing the link issue
https://github.com/D-Programming-Language/phobos/pull/3852

What you actually want is http://dlang.org/phobos/std_range_primitives.html
which is linked at the top of the page and gives the docs on the isOutputRange
template.

One thing that can be improved is adding Ali's tutorial on ranges to the docs,
as it was added to the top of std.algorithm. This PR does that
https://github.com/D-Programming-Language/phobos/pull/3873

--

[Issue 15450] New: ICE during CTFE of legit function

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

  Issue ID: 15450
   Summary: ICE during CTFE of legit function
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: and...@erdani.com

Repro below fails with:

dmd: interpret.c:1034: Expression* interpret(FuncDeclaration*, InterState*,
Expressions*, Expression*): Assertion `!e || (e->op != TOKcontinue && e->op !=
TOKbreak)' failed.



struct BigO
{
struct Atom
{
int id;
double exp;
double logExp;
}

private Atom[][] terms;

int opCmp(const BigO rhs) const
{
int result = 0;
bigone:
foreach (ref l; terms)
{
foreach (ref r; rhs.terms)
{
if (l == r) continue bigone;
if (smaller(l, r))
{
if (result == 1) return 0;
if (result == 0) result = -1;
continue bigone;
}
if (smaller(r, l))
{
if (result == -1) return 0;
if (result == 0) result = 1;
continue bigone;
}
}
// Not comparable
return 0;
}
return result;
}

private static bool smaller(const(Atom)[] lhs, const(Atom)[] rhs)
{
return 0;
}
}

static immutable
linear = BigO([ [ BigO.Atom(0, 1, 0) ] ]);

static assert(linear >= linear);

--

[Issue 15451] dlang.org should use cache busting

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

Jack Stouffer  changed:

   What|Removed |Added

   Keywords||performance

--

[Issue 15451] New: dlang.org should use cache busting

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

  Issue ID: 15451
   Summary: dlang.org should use cache busting
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: j...@jackstouffer.com

For an explaination of what cache busting is and how it works, see
https://css-tricks.com/strategies-for-cache-busting-css/

--

[Issue 15417] Wrong parameter passing for variadic nested functions within aggregate

2015-12-15 Thread Ola Fosheim Grøstad via Digitalmars-d

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

Dicebot  changed:

   What|Removed |Added

   Keywords||industry

--

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread Andrei Alexandrescu via Digitalmars-d


On 12/15/2015 09:40 AM, John Colvin wrote:

On Tuesday, 15 December 2015 at 14:03:50 UTC, rumbu wrote:

This is a *good* documentation:
- "Count" is a better name than "walkLength"; every other programming
language will use concepts similar to count, cnt, length, len.


meh, I like walkLength.


Me too, but don't forget that nowadays "count" with no predicate 
defaults to walkLength's semantics. -- Andrei

Re: Some feedback on the website.

On Wednesday, 16 December 2015 at 01:18:03 UTC, Andrei 
Alexandrescu wrote:
This is easy to refute because only one counter-example is 
needed. I made a bunch of non-improvement changes in early 
2014. The success was tremendous. -- Andrei


Was it? How did you measure the success?

Re: Some feedback on the website.

On Wednesday, 16 December 2015 at 01:15:45 UTC, Andrei 
Alexandrescu wrote:

It seems knowing ddoc is part of knowing D. -- Andrei


I just cargo cult something when I contribute to phobos/druntime. 
One cannot know everything.


Also, ddoc always appeared to me like a big NIH syndrome.

[Issue 15452] Document typo of a new predefined version identifier 'CRuntime_DigitalMars'

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

j...@red.email.ne.jp changed:

   What|Removed |Added

   Keywords||pull

--- Comment #1 from j...@red.email.ne.jp ---
done.

https://github.com/D-Programming-Language/dlang.org/pull/1168

--

Re: Microsoft to contribute to Clang and LLVM project

2015-12-15 Thread Joakim via Digitalmars-d

On Tuesday, 15 December 2015 at 20:02:27 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 15 December 2015 at 16:17:32 UTC, Joakim wrote:
you can optimize for one niche and do extremely well there, 
but then you often find yourself stuck in that niche, as Go 
finds itself today.


Being stuck in Go's niche would be a fantastic situation for D 
as Go's market penetration might be 20x that of D. The main 
limitation for Go is the Go language authors' vision and 
attitudes. Not really related to the domain.


If it were merely the D team's goal to quickly gain usage like 
Go, such higher market penetration would be fantastic, but I 
don't think that's what they're after.  It seems to be unseating 
C/C++ as the major systems and application programming languages, 
while simultaneously expanding that market upwards into 
higher-level domains C++ can't get into today.


That's a longer game, one you don't rush into.  Will D get there? 
I have no idea, but the recent improvements in C++ imply that new 
AoT-compiled languages like D, Rust, and Go are at least 
pressuring C++ to up its game.  In that sense, the new languages 
can't lose, because even if they go out of use, their best 
features will already have made it into C++.


But I don't think they have to worry about that, as I suspect the 
market for AoT-compiled languages is simply becoming more 
fragmented again, as the scripting languages market has long 
been.  Each of these AoT languages will likely maintain their own 
niche, and C++ has so much legacy baggage- they never talk about 
getting rid of the preprocessor, that's when I'll know they're 
serious- that at least one of them will displace it at the top, 
maybe D. :)

[Issue 15453] New: Check for predefined version identifiers with a misspell

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

  Issue ID: 15453
   Summary: Check for predefined version identifiers with a
misspell
   Product: D
   Version: D2
  Hardware: All
OS: Windows
Status: NEW
  Keywords: accepts-invalid
  Severity: minor
  Priority: P1
 Component: dmd
  Assignee: nob...@puremagic.com
  Reporter: j...@red.email.ne.jp
Depends on: 15452

This relates to a document issue.
https://issues.dlang.org/show_bug.cgi?id=15452

The compiler normally rejects same version identifiers as predefined.
Now, 2.069 added some predefined version identifiers in forms of CRuntime_xxx.

--
dmd.exe -version=CRuntime_Digitalmars
Error: version identifier 'CRuntime_Digitalmars' is reserved and cannot be set

dmd.exe -version=CRuntime_DigitalMars
(accepts-invalid)
--

Checker: CRuntime_Digitalmars ( small 'm' ).
Correct: CRuntime_DigitalMars

Though the document spec has same mistake as this,
many codes in Phobos and Druntime write **Mars actually. (which is working
well)
So I think this is to be fixed.

--

[Issue 15452] Document typo of a new predefined version identifier 'CRuntime_DigitalMars'

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

j...@red.email.ne.jp changed:

   What|Removed |Added

 Blocks||15453

--

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread Ola Fosheim Grøstad via Digitalmars-d


On Tuesday, 15 December 2015 at 11:26:04 UTC, rumbu wrote:


Looking at the .net source code, the Count extension method is 
also doing a best effort "count" by querying the ICollection 
interface.


Yes, I have looked at the source code, before writing this, so I 
knew exactly how it worked. In short : terrible, because it 
relies only on OOP. But that's not the point. Why should anyone 
need to look at the source code, to see what this function does? 
I thought this is what the docs were supposed to tell.




public static int Count(this IEnumerable [...]

The Remarks section clearly states the same thing:

"If the type of source implements ICollection, that 
implementation is used to obtain the count of elements. 
Otherwise, this method determines the count."



And personally, I found the MS remark more compact and more 
user friendly than:

[...]


If you look at table at the beginning of page 
(https://dlang.org/phobos/std_range_primitives.html) you can 
clearly see a nice concise description of the function. Even if 
you don't know complexity theory there's the word "Compute" which 
should give you an idea that the function performs some 
non-trivial amount of work. Unlike:



Returns the number of elements in a sequence.


Which implies that it only returns a number - almost like an 
ordinary getter property. I am scared to think that if back then 
C# got extension properties, it might have been implemented as 
such.


Not everybody is licensed in computational complexity theory to 
understand what O(n) means.


LOL. Personally, I would never want to use any software written 
by a programmer, who can't tell the difference.


Well ok, let's consider a novice programmer who hasn't studied 
yet complexity theory.


Option A: They look at the documentation and see there's some 
strange O(n) thing that they don't know. They look it up in 
google and find the wonderful world of complexity theory. They 
become more educated and are grateful the people who wrote the 
documentation for describing more accurately the requirements of 
the function. That way they can easily decide how using such 
function would impact the performance of their system.


Option B: They look at the documentation and see that there's 
some strange O(n) thing that they don't know. They decide that 
it's extremely inhumane for the docs to expect such significant 
knowledge from the reader and they decide to quit. Such novices 
that do not want to learn are better off choosing a different 
profession, than inflicting their poor written software on the 
world.

Re: We need better documentation for functions with ranges and templates


On Tuesday, 15 December 2015 at 12:28:02 UTC, ZombineDev wrote:
Not everybody is licensed in computational complexity theory 
to understand what O(n) means.


LOL. Personally, I would never want to use any software written 
by a programmer, who can't tell the difference.


Well ok, let's consider a novice programmer who hasn't studied 
yet complexity theory.


Most experienced programmers have a _very_ poor understanding of 
complexity theory, the associated notation and applicability.


A little bit of sloppy O(1), O(log N) and O(N), is ok, but for 
anything more than that it becomes more confusing than useful. 
E.g. the effects are not necessarily measurable for your program. 
You need more accurate descriptions to understand the effects 
than O(N^2).

Re: We need better documentation for functions with ranges and templates

2015-12-15 Thread Andrei Alexandrescu via Digitalmars-d


On 12/14/15 10:51 PM, Jakob Ovrum wrote:

On Tuesday, 15 December 2015 at 03:47:30 UTC, Andrei Alexandrescu wrote:

We use this pattern in only a couple of places in Phobos, but I think
we should generally improve the language to use less, not more, of it.

BTW I think all overloads of a given function should be under the same
DDOC entry with nice descriptions of what cases they apply to. The
situation right now with many function having separately-documented
overloads with "Jump to: 2" etc. is undesirable.


Andrei


One possible trick is to use multiple `Params:` sections. Optional
parameters can be described as such in the parameter description to
reduce the number of `Params:` sections needed.

Another thing we should do is simplify our overload sets/template
constraints. For example, `find` has two overloads for needle search
which can be collapsed into one. They have different template
constraints - but only because of practical limitations in constraining
all the needles properly, which should be remedied with improvements to
std.traits and std.meta.


Yah, these are sensible ideas. Please add them to 
https://issues.dlang.org/show_bug.cgi?id=13676. Thanks! -- Andrei

Re: Some feedback on the website.

2015-12-15 Thread Andrei Alexandrescu via Digitalmars-d


On 12/15/15 3:31 AM, Gary Willoughby wrote:

We've all said time and time again if ddoc wasn't used for the entire
site more people would help with it. Ddoc makes sense for the
documentation but not everything else.


I'm not sure about this. There are very very many potential improvements 
that are important, easy to do, not related to the use of ddoc, and 
don't get done.



I thought Sociomantic were re-designing and sorting the site out?


Not for the time being.


Andrei

Re: Some feedback on the website.

2015-12-15 Thread Andrei Alexandrescu via Digitalmars-d


On 12/15/15 5:54 AM, tcak wrote:

The harder it is made for people to contribute the system for fixations,
the lesser changes are seen.


I don't think we've had many contributions via the "Improve this page" 
button.



It bothers me so much to report a bug on https://issues.dlang.org . The
reason is that the password stops working for me. Firefox saves the
username and password. I try to use it after 2 months, and whops, system
says it isn't available.

Another issue is contributing the website's design. I reported a problem
on the forum that is about the title problem of web page.
http://forum.dlang.org/thread/pymfyjuckxbvjolxl...@forum.dlang.org Still
the problem will be fixed.

Now I am asking, IF I was to make some changes for web site's look, and
post a picture of them (CSS changes mostly), would it be okay to discuss
it here, and apply them in short notice? If a change would take 1 week,
that doesn't work. I am
offering help here.


Yes, the css has grown long in the teeth. Just replacing it with 
something else is needed, even if it's not an actual improvement.


A related idea is to investigate the use of 
http://sourcefoundry.org/hack/ for the code samples. Takers?



Andrei

Re: Some feedback on the website.

2015-12-15 Thread dnewbie via Digitalmars-d


On Tuesday, 15 December 2015 at 07:07:23 UTC, deadalnix wrote:

Navigation:

The navigation can get very confusing. The forum and the site 
look the same, but the logo in the top right bring back to the 
site index/forum index .


I thought that only I had saw this. Yes it's wrong. To go to 
homepage from the forum you need to look at the bottom (D Home 
link), for me this is very wrong and certainly not the standard 
for most sites.


I really think that D "heads" should hire a webdesigner!

Ron.

Re: We need better documentation for functions with ranges and templates

On Tuesday, 15 December 2015 at 13:47:20 UTC, Ola Fosheim Grøstad 
wrote:

On Tuesday, 15 December 2015 at 12:28:02 UTC, ZombineDev wrote:
Not everybody is licensed in computational complexity theory 
to understand what O(n) means.


LOL. Personally, I would never want to use any software 
written by a programmer, who can't tell the difference.


Well ok, let's consider a novice programmer who hasn't studied 
yet complexity theory.


Most experienced programmers have a _very_ poor understanding 
of complexity theory, the associated notation and applicability.


A little bit of sloppy O(1), O(log N) and O(N), is ok, but for 
anything more than that it becomes more confusing than useful. 
E.g. the effects are not necessarily measurable for your 
program. You need more accurate descriptions to understand the 
effects than O(N^2).


I never said that you need to be an expert, but at least you 
should be able to tell the difference between O(n) and O(1) like 
in this particular case. This is very basic stuff.

[Issue 3158] (D1 only) std.process.execv() incorrect documentation

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

Jack Stouffer  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||j...@jackstouffer.com
 Resolution|--- |WONTFIX

--- Comment #4 from Jack Stouffer  ---
This is documented in the current version.

All bugs on Phobos and DMD related to D1 were closed, so I think it's prudent
to do so here as well. D does not have the man power to fix doc issues in older
versions.

--

[Issue 15452] New: Document typo of a new predefined version identifier 'CRuntime_DigitalMars'

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

  Issue ID: 15452
   Summary: Document typo of a new predefined version identifier
'CRuntime_DigitalMars'
   Product: D
   Version: D2
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P1
 Component: dlang.org
  Assignee: nob...@puremagic.com
  Reporter: j...@red.email.ne.jp

2.069 added some predefined version identifiers in forms of CRuntime_xxx.

In document: CRuntime_Digitalmars ( small 'm' ).
Correct: CRuntime_DigitalMars

The compiler ignores this kind of errors silently...

I'll make a PR for this.

--

Re: Some feedback on the website.

2015-12-15 Thread Andrei Alexandrescu via Digitalmars-d


On 12/15/2015 05:45 PM, Jack Stouffer wrote:

Also, you saying "even if it's not an actual improvement"  is a real
head scratcher for me. We need a change even if it makes things worse?


It's visuals, not engineering. Put your artist hat on. "Not better" does 
not mean "worse". -- Andrei

Re: Some feedback on the website.

2015-12-15 Thread Andrei Alexandrescu via Digitalmars-d


On 12/15/2015 04:45 PM, deadalnix wrote:

On Tuesday, 15 December 2015 at 13:42:29 UTC, Andrei Alexandrescu wrote:

On 12/15/15 5:54 AM, tcak wrote:

The harder it is made for people to contribute the system for fixations,
the lesser changes are seen.


I don't think we've had many contributions via the "Improve this page"
button.



I don't know how representative it is, but once in a while, i forgot all
of this is in DDoc, I notice something, what to do a quick patch, and
end up being reminded this is in DDoc and I have no idea how to fix the
thing, because suddenly, what looked like a quick fix end up being
learning a new macro language.


It seems knowing ddoc is part of knowing D. -- Andrei

Re: http://wiki.dlang.org/Starting_as_a_Contributor reorganization

2015-12-15 Thread Andrei Alexandrescu via Digitalmars-d


On 12/15/2015 04:21 PM, Jack Stouffer wrote:

On Monday, 14 December 2015 at 20:47:27 UTC, Andrei Alexandrescu wrote:

I see Vladimir and Jack did these changes. Could you please
restructure the document into three - one for each of the OSs we support?


Sure, but we need to find a way to make sure that the decentralization
doesn't cause the info to become stale, as the reason the different
pages were consolidated was the wildly inaccurate info on some old
pages. I also still have to incorporate
http://wiki.dlang.org/Using_Git_on_Windows into the page.


Thanks very much! -- Andrei

Re: Some feedback on the website.

2015-12-15 Thread Andrei Alexandrescu via Digitalmars-d


On 12/15/2015 05:45 PM, Jack Stouffer wrote:

On Tuesday, 15 December 2015 at 13:42:29 UTC, Andrei Alexandrescu wrote:

Yes, the css has grown long in the teeth. Just replacing it with
something else is needed, even if it's not an actual improvement.


I have to disagree with you heavily on this point. Changing the look and
feel of a site just for the sake of change is a lot of work for little
gain.


This is easy to refute because only one counter-example is needed. I 
made a bunch of non-improvement changes in early 2014. The success was 
tremendous. -- Andrei

[Issue 15059] D Bug Tracker graph disappeared

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

Jack Stouffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||j...@jackstouffer.com
 Resolution|--- |DUPLICATE

--- Comment #2 from Jack Stouffer  ---


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

--

[Issue 12618] bugstats graph broken since bugzilla upgrade

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

Jack Stouffer  changed:

   What|Removed |Added

 CC||alil...@gmail.com

--- Comment #2 from Jack Stouffer  ---
*** Issue 15059 has been marked as a duplicate of this issue. ***

--

[Issue 4472] Update D2 Enhancements to D1

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

Jack Stouffer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||j...@jackstouffer.com
 Resolution|--- |WONTFIX

--- Comment #2 from Jack Stouffer  ---
I'm going to label this as won't fix, feel free to change it back if you
disagree. No one outside of companies like Sociomantic are using D1 anymore,
and they are well aware of the benefits of D2. We don't need to keep this up to
date for their sake.

D1 vs D2 is no longer the Python 2 vs Python 3 of D.

--

[Issue 926] Revival of implicit conversion from Derived[] to Base[] not noted in changelog