Re: Better docs for D (WIP)

[bachmeier via Digitalmars-d-announce]

On Thursday, 31 December 2015 at 02:40:17 UTC, Andrei 
Alexandrescu wrote:
I agree and I'm sorry we're not moving faster with reviews, but 
really that's not ddo(c|x)'s fault.


Any chance you can respond to this question that I posted two 
days ago?


http://forum.dlang.org/post/pdjfvsmvdewwtjoic...@forum.dlang.org

It doesn't require a review and only needs an answer of "yes" or 
"no". One of the nice things about Adam's site is that it has his 
email address on the front page.

Re: Better docs for D (WIP)

[Andrei Alexandrescu via Digitalmars-d-announce]

On 12/30/2015 06:05 PM, Adam D. Ruppe wrote:

the difference is this time, I have my own fork so the community doesn't
have to lose out.


All I want is to make sure you know your reasons and assumptions. The 
assumption there isn't a Phobos documentation with item-per-page was 
wrong. It seems to me referencing another module is trivial to fix as well.


Andrei

Re: Better docs for D (WIP)

[Andrei Alexandrescu via Digitalmars-d-announce]

On 12/30/2015 08:32 PM, Adam D. Ruppe wrote:

~2010: I had just written this awesome dom.d library and wanted to
document it and release it to the world. I write stuff like:

/// Returns the text in the element. For example, innerText of
foo is "foo" (without quotes)
string innerText();

And it came out mangled because of ddocs embedded HTML "feature" which
doesn't encode the output. I proposed a fix, using ddoc's existing
ESCAPES macro, and wrote the patch for dmd. Embedded html would be
automatically encoded, but you can still define it in macro definitions,
which can be inline with the comment, so it isn't hard to use when you
want it.

It was rejected. Walter didn't see what the problem was and I was told
to just write $(LT)span$(GT)foo$(LT)/span$(GT). Seriously.


Could you please post a link to your proposed fix?


The idea (and working program) was rejected because the team felt a
post-processor was the wrong way to do it.


Do you have a link to that proposal and discussion?


We got another website redesign in these years, and moved to dlang.org.
The build process finally got documented after I and others complained
for a while, but it was never actually cleaned up.


What steps do we need to take to clean the build process up?


I just got sidetracked doing a quick paragraph fix for Andrei... and
then wanted to see how far I could go. I got it working, despite the
obstacles that ddoc's freeform macros bring, and surprise, it was
rejected.


For reference: https://github.com/D-Programming-Language/dmd/pull/5319. 
I don't think it should have been accepted. It's not a good PR.



Even the simpler patch that just collapses blank lines sits
unanswered.


Sorry, the holiday period is not very productive what with the kids on 
vacation and whatnot. I'll pull your PR to my patch and will move 
forward with it. Thanks. Or did you work that into something standalone 
that I've missed?



A tool to look for broken links sits unanswered. There's
always a call to contributions, but when you do push through the painful
process to get the code up (and the tester, the f$^%$^ing tester),
nobody seems to care.


I agree and I'm sorry we're not moving faster with reviews, but really 
that's not ddo(c|x)'s fault.



The combined experience over these last six years tells me that the
website sucks and it keeps sucking because changing it sucks even more
than using it. A new strategy was required.

And here we are.


I hear your frustration, and for a good part I agree with it. Again: all 
I want is to make sure you have the right motivation and that you are 
fully informed of what's currently going on.



Andrei

Re: DLanguage IntelliJ plugin released

[Suliman via Digitalmars-d-announce]

On Monday, 28 December 2015 at 19:23:17 UTC, Kingsley wrote:

On Friday, 25 December 2015 at 17:43:06 UTC, Kingsley wrote:

On Friday, 25 December 2015 at 16:55:32 UTC, Bogdan wrote:
On Friday, 25 December 2015 at 15:28:23 UTC, Pradeep Gowda 
wrote:

On Friday, 25 December 2015 at 15:04:42 UTC, eyveer wrote:
On Friday, 25 December 2015 at 13:57:52 UTC, Pradeep Gowda 
wrote:



[...]


https://github.com/kingsleyh/DLanguage


Thank you. The screenshots are very impressive! Gives me 
motivation to figure out why i couldn't get it to work.


Couldn't figure out what went wrong until I read your comment 
and looked at the screenshots. Try going to Settings/Other 
Tools/D Tools and press all the "Auto Find" buttons.
Raise any issues at the GitHub page and I will fix - I will 
write some documentation over the next few days also


Intellij D plugin version 1.5 released with improved DUB 
support and bug fixes


How to install this plugin on Windows?

Re: Better docs for D (WIP)

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

BTW wouldn't it be great if the compiler's error messages showed 
each level of pass/fail for those constraints? For the docs, I 
don't mind doing a few special case, hand written things, but the 
compiler needs something a bit more generic.


I think the way to code that is whenever the compiler is printing 
an expression that can convert to bool, color it based on the 
result, and do this through the whole tree from the bottom up.


Then the use could tell at a glance which parts succeeded and 
failed when reading the error message.


It'd be kinda nice if it showed the result of non-bool things too 
but that's going to be hard to do on a console without becoming a 
wall of text, even with whitespace formatting...



But the compiler will come later, for now I gotta do docs!

Re: pl0stuff an optimizing pl0 > c transcompiler

[Stefan Koch via Digitalmars-d-announce]

On Tuesday, 29 December 2015 at 22:13:44 UTC, Nick B wrote:


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


I am not sure if this is the right thing to do.
The main reason to look at HHVM is to get an idea of 
implementation strategies.

benchmarking would require to already have a solution to work on.

Re: Better docs for D (WIP)

[default0 via Digitalmars-d-announce]

On Wednesday, 30 December 2015 at 16:41:51 UTC, Adam D. Ruppe 
wrote:
BTW wouldn't it be great if the compiler's error messages 
showed each level of pass/fail for those constraints? For the 
docs, I don't mind doing a few special case, hand written 
things, but the compiler needs something a bit more generic.


I think the way to code that is whenever the compiler is 
printing an expression that can convert to bool, color it based 
on the result, and do this through the whole tree from the 
bottom up.


Then the use could tell at a glance which parts succeeded and 
failed when reading the error message.


It'd be kinda nice if it showed the result of non-bool things 
too but that's going to be hard to do on a console without 
becoming a wall of text, even with whitespace formatting...



But the compiler will come later, for now I gotta do docs!


I was personally thinking that it can't be horribly difficult 
that given a function signature:


void foo(T)(T arg) if(constraintA!T && constraintB!T || 
constraintC!T)


That if this cannot be instantiated the compiler prints something 
like

"Candidate foo(T)(T arg) fails with (true && false || false)"
I sometimes found myself putting static 
assert(, "Result 
is blabla") and recompiling just to debug these :/

Re: Better docs for D (WIP)

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

On Wednesday, 30 December 2015 at 15:51:23 UTC, default0 wrote:
Yeah, I misinterpreted the "E : " to mean "E is or 
inherits from ", rechecking the argument deduction rules 
for templates I think this instead means "E should be deduced 
as ".


Sort of.. it means "if E can be implicitly converted to ".

All of this stuff:


RoR ror,
E sep

if (
  isInputRange!RoR &&
  isInputRange!(Unqual!(ElementType!RoR)) &&
  is(E : ElementType!(ElementType!RoR))
)

(doesn't copy paste well, I gotta fix my html a bit)


Could be rewritten as

"ror is an input ranges of input ranges and sep can be implicitly 
converted to the type of ror's inner range's elements."


Or something like that.



So given: join([[1L], [2L]], 1);


Constraint clause 1: isInputRange!RoR passes because an array, 
this is long[][] is an input range.


Constraint clause 2: ElementType!RoR is long[] because 
ElementType basically trips off the outer [] from RoR's type 
(basically), which is long[][].


Unqual!T trims off qualifiers like const, immutable, etc. 
Basically it takes the type out of parenthesis. There are none of 
that here, so long[] is still long[].


Finally, the clause passes because long[] is an input range.


Constraint clause 3: asks if E, which in this example is 
typeof(1), which is `int`, is implicitly convertible to the type 
of RoR with *two* layers of [] trimmed off. RoR was long[][] so 
ElementType!ElementType!(long[][]) returns `long`.


Since `int` implicitly converts to `long` (every int value is a 
valid long value too), this constraint passes.


If it said is(E == same_stuff), it would fail because int != 
long. But since it is is(E : stuff), it passes because that 
allows implicit conversions.




I'll be writing an article with content like this that links from 
the keyword `if` in those prototypes (Currently it links to 
dlang.org's spec page but that's not as useful to api doc readers 
IMO).


I also plan to put a link to this under a "D Concepts" sub-header 
in the See Also section. Yes, on every page it is used. If 
someone lands here from a search engine, they shouldn't be 
assumed to already know everything! And it is hard to search for 
"dlang function if"...

Re: Implementing a Programming Language in D: Lexical Analysis

[Basile B. via Digitalmars-d-announce]

On Wednesday, 30 December 2015 at 14:41:38 UTC, burjui wrote:

On Tuesday, 29 December 2015 at 05:57:34 UTC, Ali Çehreli wrote:

[...]
Even more than that, I would also suggest to remove anonymous 
auto-typed enums

without an initial value from which type can be inferred, e.g.:


[...]


Again, the following is not much harder to write, but the type 
of 'a' is immediately clear:



[...]


Although I understand that these are breaking changes,
and D is too mature to break anything (almost not being 
sarcastic).


anonymous enum are just not enumerations... They are more 
"manifest constants" available at CT. Actually their members even 
dont verify (is(T == enum)) ;).


They also allow not to write too much enum... and to fold in an 
editor.

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

Jacob Carlborg  writes:

> On 2015-12-30 08:02, Dan Olson wrote:
>
>> I know some of it from hacking dyld for iOS, but not all.  How does this
>> fit in with "Plan B.2"?
>
> If you need to figure out how TLS works, I can give you some help,
> that's all I'm saying :)

Oh, good.  Always like help.  I'm going to start with Plan B.1 though
because LLVM does nice optimizations for TLS.

Re: Better docs for D (WIP)

[bachmeier via Digitalmars-d-announce]

On Wednesday, 30 December 2015 at 23:05:11 UTC, Adam D. Ruppe 
wrote:
On Monday, 28 December 2015 at 23:05:28 UTC, Andrei 
Alexandrescu wrote:
(a) is the new proposed system differentiated enough to 
justify its existence and motivate others to join in?



I was just watching my newbie friend try to manipulate 
directories in D. His first instinct was to go to std.path. I 
decided to edit std.path to add a note in the header "if you 
want to get path names from a directory, use std.file".


Linking to std.file proved to be a huge hassle. Sure, I could 
just $(LINK2 std_file.html, std.file) like Phobos does in other 
places, but alas, that breaks ddox.


http://dlang.org/library/std/algorithm.html

Click the "See also Reference on ranges" there and observe the 
404.


So I wanted to define a new macro called MREF so you'd write it 
$(MREF std,file) and it would replace with underscores on ddoc, 
slashes on ddox (and dots on my docs).


Easy, right? Wait, XREF doesn't work right on modules, it 
expects the second arg to be a function and links break in some 
places if you leave it blank, and it doesn't work on 
submodules... can't there just be a REF thing?


I guess not, the system is too complicated. Whatever though, 
I'll make my new MREF, or module reference. (Am I seriously the 
first one to do this?)


Check out $(MREF std,file) and $(MREF std,algorithm,searching)!

Macros:
MREF_HELPER=_$1$(MREF_HELPER $+)
MREF=$1$(MREF_HELPER $+).html

Wow, it works! (Well, basically. It doesn't work if the module 
has only one name, like object.d, but we can special case that 
one.)



But now, where do I put it? I grep for XREF in dlang.org/*.ddoc 
and find a few candidates then check the wiki 
http://wiki.dlang.org/Contributing_to_dlang.org#Macro_Definition_Batteries:_.ddoc_files to see what it says.


...it returned files that aren't listed there... what should I 
do with them? Oh dear this is taking too much brain power, I 
just wanted to add a sentence linking people to the other 
module!





BTW this is why my thing separates all the filenames with dots, 
just like D itself does. Predictable, even without semantic 
analysis!



This huge friction has killed my desire to contribute to Phobos 
before and it looks like it is again.


the difference is this time, I have my own fork so the 
community doesn't have to lose out.


Thanks for doing this Adam. The official docs are a mess. Not 
just what you see when you look at the website, though there are 
important problems with that. It's the process that requires so 
much overhead that nobody wants to contribute. I really tried to 
do so myself, but I'm busy, and it is senseless that 95% (or 
more) of the time I spend on it is wasted due to a system that is 
flawed from top to bottom. The only thing that surprises me is 
that there are any contributions.


If you can make it easy to contribute, that is reason enough to 
push forward, even without the other improvements you are 
offering. The official docs can die a slow death and eventually 
Google will send newbies to your site.


The only request I make is that you continue to do this yourself 
in order to keep it out of overhead hell. I'll be using it for 
sure.

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

On Wednesday, 30 December 2015 at 23:11:06 UTC, Joakim wrote:

That sounds like this issue I ran into with ARM EH:

https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075

I was able to work around it by disabling the mentioned llvm 
optimization pass:


https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a#file-android_tls-L42

https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3133


Yup, that's exactly it!  The approach I took was to leave 
optimization on, removed the casts, and byte load the data into 
the uint vars.  If the dwarf data is not guaranteed to be aligned 
to the data type, then I think this is the approach to take.

Re: Better watch out! D runs on watchOS!

[Joakim via Digitalmars-d-announce]

On Thursday, 31 December 2015 at 00:11:34 UTC, Dan Olson wrote:

On Wednesday, 30 December 2015 at 23:11:06 UTC, Joakim wrote:

That sounds like this issue I ran into with ARM EH:

https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075

I was able to work around it by disabling the mentioned llvm 
optimization pass:


https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a#file-android_tls-L42

https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3133


Yup, that's exactly it!  The approach I took was to leave 
optimization on, removed the casts, and byte load the data into 
the uint vars.  If the dwarf data is not guaranteed to be 
aligned to the data type, then I think this is the approach to 
take.


Sounds good, submit a PR and let's get it in.

Re: Better docs for D (WIP)

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

On Monday, 28 December 2015 at 23:05:28 UTC, Andrei Alexandrescu 
wrote:
(a) is the new proposed system differentiated enough to justify 
its existence and motivate others to join in?



I was just watching my newbie friend try to manipulate 
directories in D. His first instinct was to go to std.path. I 
decided to edit std.path to add a note in the header "if you want 
to get path names from a directory, use std.file".


Linking to std.file proved to be a huge hassle. Sure, I could 
just $(LINK2 std_file.html, std.file) like Phobos does in other 
places, but alas, that breaks ddox.


http://dlang.org/library/std/algorithm.html

Click the "See also Reference on ranges" there and observe the 
404.


So I wanted to define a new macro called MREF so you'd write it 
$(MREF std,file) and it would replace with underscores on ddoc, 
slashes on ddox (and dots on my docs).


Easy, right? Wait, XREF doesn't work right on modules, it expects 
the second arg to be a function and links break in some places if 
you leave it blank, and it doesn't work on submodules... can't 
there just be a REF thing?


I guess not, the system is too complicated. Whatever though, I'll 
make my new MREF, or module reference. (Am I seriously the first 
one to do this?)


Check out $(MREF std,file) and $(MREF std,algorithm,searching)!

Macros:
MREF_HELPER=_$1$(MREF_HELPER $+)
MREF=$1$(MREF_HELPER $+).html

Wow, it works! (Well, basically. It doesn't work if the module 
has only one name, like object.d, but we can special case that 
one.)



But now, where do I put it? I grep for XREF in dlang.org/*.ddoc 
and find a few candidates then check the wiki 
http://wiki.dlang.org/Contributing_to_dlang.org#Macro_Definition_Batteries:_.ddoc_files to see what it says.


...it returned files that aren't listed there... what should I do 
with them? Oh dear this is taking too much brain power, I just 
wanted to add a sentence linking people to the other module!





BTW this is why my thing separates all the filenames with dots, 
just like D itself does. Predictable, even without semantic 
analysis!



This huge friction has killed my desire to contribute to Phobos 
before and it looks like it is again.


the difference is this time, I have my own fork so the community 
doesn't have to lose out.

Re: Better watch out! D runs on watchOS!

[Joakim via Digitalmars-d-announce]

On Wednesday, 30 December 2015 at 21:56:46 UTC, Dan Olson wrote:

Dan Olson  writes:

A little progress report. More to come later when I get 
something pushed to github.


I bought a returned Apple Watch yesterday at discount for 
$223.99 US and tried to see how much of D would work on it 
using my iOS fork of LDC. There were a few bumps, like dealing 
with embedded bitcode (a watchOS requirement). After 4-hours 
of baby steps, little D programs with incremental druntime 
support, I was able to download a huge watch app extension 
with all druntime and phobos unittests and run most of them 
alphabetically. Everything zipped along fine, only a std.math 
error, then mysteriously a exit after running std.parallelism 
test a long time. It was late for me so decided that was 
enough progress.


This means all of druntime worked and probably most of phobos.


Played with this a little more and learned a bit about watchOS 
memory. A little test that allocated memory in 5 MB chucks was 
terminated at 30 MB data RAM.  The combined unittests in phobos 
suck up much more than that, std.uri itself uses over 50 MB.  
By tailoring memory usage and running phobos unittests in 
smaller block, they all work.  The std.math failure was my own 
coding error missing a version block for WatchOS.


In end, good news: druntime and phobos fully work on watchOS 
with LLVM optimizations disabled.  With optimzations on, there 
are alignment problems.  For example, compact unwind data 
generated by LLVM isn't aligned but some of our eh unwinding 
code casts these to uint.  Not so good when the optimizer 
selects instructions requiring special alignment.  I'll track 
these down gradually.


That sounds like this issue I ran into with ARM EH:

https://github.com/ldc-developers/ldc/issues/489#issuecomment-143560075

I was able to work around it by disabling the mentioned llvm 
optimization pass:


https://gist.github.com/joakim-noah/1fb23fba1ba5b7e87e1a#file-android_tls-L42

https://gist.github.com/joakim-noah/63693ead3aa62216e1d9#file-ldc_android_arm-L3133

Re: DLanguage IntelliJ plugin released

[Israel via Digitalmars-d-announce]

On Wednesday, 30 December 2015 at 17:04:15 UTC, Suliman wrote:

On Monday, 28 December 2015 at 19:23:17 UTC, Kingsley wrote:

On Friday, 25 December 2015 at 17:43:06 UTC, Kingsley wrote:

On Friday, 25 December 2015 at 16:55:32 UTC, Bogdan wrote:
On Friday, 25 December 2015 at 15:28:23 UTC, Pradeep Gowda 
wrote:

[...]


Couldn't figure out what went wrong until I read your 
comment and looked at the screenshots. Try going to 
Settings/Other Tools/D Tools and press all the "Auto Find" 
buttons.
Raise any issues at the GitHub page and I will fix - I will 
write some documentation over the next few days also


Intellij D plugin version 1.5 released with improved DUB 
support and bug fixes


How to install this plugin on Windows?


Intellij Idea 14 on windows.

File > Settings > plugins > browse repositories

The plugin does not show up on Intellij Idea 15 though so im 
guessing it isnt compatible yet and neither on CLion.

Re: Better docs for D (WIP)

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

On Thursday, 31 December 2015 at 00:04:03 UTC, bachmeier wrote:

It's the process that requires so much overhead that nobody
wants to contribute. I really tried to do so myself, but I'm 
busy, and it is senseless that 95% (or more) of the time I 
spend on it is wasted due to a system that is flawed from top 
to bottom. The only thing that surprises me is that there are 
any contributions.


Exactly. I've put my time into ddoc. Let me give you a brief 
history of my efforts:


~2010: I had just written this awesome dom.d library and wanted 
to document it and release it to the world. I write stuff like:


/// Returns the text in the element. For example, innerText of 
foo is "foo" (without quotes)

string innerText();

And it came out mangled because of ddocs embedded HTML "feature" 
which doesn't encode the output. I proposed a fix, using ddoc's 
existing ESCAPES macro, and wrote the patch for dmd. Embedded 
html would be automatically encoded, but you can still define it 
in macro definitions, which can be inline with the comment, so it 
isn't hard to use when you want it.


It was rejected. Walter didn't see what the problem was and I was 
told to just write $(LT)span$(GT)foo$(LT)/span$(GT). Seriously.



Well, that was unacceptable so I decided to take matters into my 
own hands. On Feb 20, 2010, I registered dpldocs.info and started 
writing my own web service to delver dom.d's docs, encoding the 
output correctly, getting the docs out of dmd's JSON output, 
using -D -X.


Well, it worked, but it sucked. The JSON output didn't give me 
enough information to do cross referencing, so I wrote a little 
search engine to paper over it... and that didn't help much.


I moved on to other things, every so often still advocating to 
fix ddoc's escaping, but mostly just writing my docs such that 
they were readable in the source code and not bothering with 
generating them at all. (I'm told my source tends to be fairly 
readable anyway and I like to narrate my thoughts a bit in the 
comments including of implementation details so they understand 
the pros and cons of my decisions.)


At some point around here, I wrote a crappy Javascript table of 
contents for the D website (then hosted at digitalmars.com still) 
- the infamous "Jump list". This was meant to be a temporary 
measure until ddoc got proper table of contents support.


That sucky Javascript hack is still live today.


2011: We had a proposal for a website redesign. Remember this 
one? http://arsdnet.net/d-web-site/index.html


The jump list hack garnered a lot of hate. It was a blob of text 
that we couldn't read, but ddoc's design made a user-defined 
table of contents extremely difficult to implement. A few 
attempts were started, but none finished.


I wrote a program, called improveddoc.d, still on the 'net: 
http://arsdnet.net/d-web-site/improveddoc.d that post-processed 
the generated HTML to create a cheat-sheet table.


This is what it made of std.algorithm at the time:

http://arsdnet.net/d-web-site/std_algorithm.html


I offered to integrate it into the website tools... and got my 
first look at the horror that is that build process. 
Nevertheless, running a little post process script to run that on 
the html was doable. It also would read tag macros and use them 
to organize the content.


The idea (and working program) was rejected because the team felt 
a post-processor was the wrong way to do it.


Instead, Andrei manually wrote a std.algorithm cheat sheet and we 
added a bullet between the links in the jump list hack. Both of 
these have remained basically unchanged to this day and dmd still 
cannot generate a table of contents in ddoc.



We did get a website redesign after that, 
d-programming-language.org was launched, and Vladimir's forum got 
integrated (I wrote one too but his was so much better than mine 
that I gladly yielded). ddoc, however, barely changed.



For the next couple years, despite ddoc being unusable for half 
my libraries because they are web libs and showing HTML examples 
was practically impossible, I still was basically on its side, 
while still working on improving the json support. I had tried 
the json thing and found the compiler approach to be better, but 
the json output is good for a few things and Ddoc's syntax isn't 
all that bad if you aim for source readability and clever use of 
recursive macros can do some pretty cool things.


I put my support behind dmd. With the vibe.d team also pushing 
for improved json support, a few things happened there... though 
little of consequence. My opinion of the json output hasn't 
significantly changed since 2010: cool for a few things, I like 
that we have it, but it is not a substitute for 
compiler-integrated ddoc.



We got another website redesign in these years, and moved to 
dlang.org. The build process finally got documented after I and 
others complained for a while, but it was never actually cleaned 
up.



At the end of 2014, yea, even a year 

Re: Better docs for D (WIP)

[Israel via Digitalmars-d-announce]

On Thursday, 31 December 2015 at 01:32:56 UTC, Adam D. Ruppe 
wrote:


The D leaders know how important examples are. We are often 
told adding more is low hanging fruit. I completely agree. But 
that's not ALL we need. He wants examples to get started, yes, 
but he also wants understanding to go beyond examples. That's 
where text helps. That's where understanding the function 
signatures help. Eventually, when people go to write their own 
libraries, they might want to do Phobos style genericity. You 
can't do that without understanding the function signatures... 
and those blobs of text are not understandable.


This is what hits me the most. Thats why we suggested "user 
contributed examples". PHP docs is the only place ive seen this. 
What is your stance on this and if you agree, how would you 
implement it? How would it work?

Re: Better watch out! D runs on watchOS!

[Jacob Carlborg via Digitalmars-d-announce]

On 2015-12-30 08:02, Dan Olson wrote:


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


If you need to figure out how TLS works, I can give you some help, 
that's all I'm saying :)


--
/Jacob Carlborg

Re: Implementing a Programming Language in D: Lexical Analysis

[burjui via Digitalmars-d-announce]

On Tuesday, 29 December 2015 at 05:57:34 UTC, Ali Çehreli wrote:
I've realized that with a nested anonymous enum, there is no 
need to (and no way of) mentioning the enum type inside a 
user-defined type. This can simplify the implementation:


Only if you intend to use enum members as manifest constants,
otherwise you're losing the type safety and explicitness
offered by named enums.
For example, I wouldn't use an anonymous enum for lexeme types.


enum {
a,
ulong b = 42, c,   // b and c are ulong
s = "hello",   // an inferred string between integrals!
x = 7, y, z
}


For me, it's a clear example of unnecessary over-engineering.

However, move 's' to the end of the list or remove it 
altogether,

then x, y, and z become ulong! Weird.


It's even worse than that: x, y and z will still be int (inferred 
from 7).

This code


void main()
{
enum {
   a,
   ulong b = 42, c,   // b and c are ulong
   x = 7, y, z
}
import std.stdio, std.typecons;
tuple!(typeof(b), typeof(c), typeof(x)).writeln;
}


will print


Tuple!(ulong, ulong, int)(0, 0, 0)


which is somewhat counter-intuitive. I would suggest to remove 
this feature

as useless and bug-prone. The following is much clearer IMHO,
even though it's more verbose:


enum { a }
enum: ulong { b = 42, c }
enum { s = "hello" }
enum { x = 7, y, z }


Even more than that, I would also suggest to remove anonymous 
auto-typed enums

without an initial value from which type can be inferred, e.g.:


enum { a } // a is an int implicitly


Again, the following is not much harder to write, but the type of 
'a' is immediately clear:



enum: int { a } // a = int.init, obviously


Although I understand that these are breaking changes,
and D is too mature to break anything (almost not being 
sarcastic).

Re: 2016Q1: std.blas

[jmh530 via Digitalmars-d-announce]

On Saturday, 26 December 2015 at 19:57:19 UTC, Ilya Yaroshenko 
wrote:

Hi,

I will write GEMM and GEMV families of BLAS for Phobos.



Cool.

Re: Better docs for D (WIP)

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

On Wednesday, 30 December 2015 at 14:25:24 UTC, default0 wrote:
As an aside, the mere formatting of the list of 
template-constraints on the dlang page made me nope right out 
of even bothering to figure out how to read them or what the 
difference between the first and the second overload of join 
was.


Aye, it is a complete mess and virtually *nobody* bothers looking 
at them. (BTW, dmd has the same problem in error messages. I plan 
to format them eventually too, with some kind of highlighting of 
passed and failing clauses. I already did a proof of concept for 
ordinary overloading functions and it wasn't actually that hard. 
I just wish I didn't have other things to do!)


New people are often outright scared away from everything and 
left with the impression that D is an experts-only language. The 
Phobos devs know this and have been trying to add more examples - 
a good, necessary step - but that isn't the whole problem.


When users modify the examples and they fail to compile, they 
need to understand what's going on. The compiler will complain in 
terms of those ugly constraints, not in terms of fixed, working 
examples. They need some way of understanding what it is saying.



Also: I plan to add a doc section called "diagnostics" with 
sample error messages and translations. I've actually considered 
doing this before but was stopped by concerns over vertical space.


No kidding, when writing ddoc, I worry about it taking up too 
much space on the page and will cut content out as a result. If 
the prototype is compressed, it just leaves a mental bug that 
says space must matter, use it sparingly.



Checking dpldocs for proper formatting and spending half a 
minute making sense of it I figured that the one was for an 
exactly matched element type and the other one was to allow 
joining a baseClass[][] with a subClass[] or something along 
those lines.



The join overloads are basically:

#1: array of arrays joined by an array
   join(["a", "b", "c"], ", "); // the joiner is an array
 -> "a, b, c"

#2: array of arrays joined by an element
   join(["a", "b", "c"], ' '); // the joiner is an element
 -> "a b c"

There is no example for form #2 in the documentation. (BTW I 
think the examples should be commented too.)


#3: array of arrays joined without anything
   join(["a", "b", "c"])
-> "abc"


Nothing about inheritance in there, the constraints talk about 
ElementType!RoR which means (conceptually) it is stripping the 
"[]" off a type, so for "int[]", it returns "int".



That should probably just be written in the text. (That's another 
thing people tell me, they come in with a question and I can give 
them a quick answer, then they ask "why didn't the docs just put 
it that simply?" And a few times, I go to open a PR but get 
stalled by the process somewhere)


But there's a LOT of functions in Phobos so I am trying to 
automate this because while I can write it for any individual 
function by hand, writing it for ALL the functions is going to 
take more time than I have.



Cumbersome and annoying (ie: slow and unproductive).


absolutely.

Also the information that /library even exists is new to me. I 
have only discovered it through reading this post.


Right. New users either don't know about it because it doesn't 
get linked to much and thus has lower page rank (unless you have 
already trained Google through D searches to favor D results), or 
they do find it and are confused as to what version it refers to.


There's been a few people who come to this newsgroup saying 
"these docs look old, what's up with it?" If they hit the disqus 
comment, it says "recent activity, 2 years ago" which furthers 
this impression.


(none of these results mention that you should simply 
cast(char[]) and then call validate on the casted array, from 
what I could tell skimming through them for 5 minutes, I might 
have missed a mention though, which would simply mean it is not 
obvious enough)


When you mentioned this before, I went to add it to the docs but 
couldn't find a good place to put it. The vertical space brain 
bug hurt me on base64 itself, then the question of linking hurt 
me when thinking of putting it somewhere else like the wiki, then 
the question of process killed me when I went to add a new page!


It was actually this experience that tipped me over the edge and 
I decided to start working on doc infrastructure myself. (I've 
spent a good amount of time this year trying to fix ddoc itself - 
starting with the `code` syntax in January - but ddoc itself is 
only part of the problem)