Re: pl0stuff an optimizing pl0 > c transcompiler

[Stefan Koch via Digitalmars-d-announce]

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

Would you know what is required to get good performance ?


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

Re: Better docs for D (WIP)

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

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


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


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


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


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

Re: Better docs for D (WIP)

[Andrei Alexandrescu via Digitalmars-d-announce]

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

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

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


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

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

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


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

Re: Better docs for D (WIP)

[Rikki Cattermole via Digitalmars-d-announce]

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

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

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

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


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

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

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


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


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

Re: Better docs for D (WIP)

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

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

Then why document it?


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


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


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


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


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


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


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


The top two results he got were:

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

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

and

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

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



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


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



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



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


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



That's huge.

Re: pl0stuff an optimizing pl0 > c transcompiler

[Nick B via Digitalmars-d-announce]

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

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

Would you know what is required to get good performance ?


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


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

Re: Better docs for D (WIP)

[Andrei Alexandrescu via Digitalmars-d-announce]

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

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


We already have that:

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

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


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



Andrei

Re: Better watch out! D runs on watchOS!

[Dan Olson via Digitalmars-d-announce]

Jacob Carlborg  writes:

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

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

Re: Better docs for D (WIP)

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

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

There is simply no symbol to attach the comment to.


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


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

Re: Better watch out! D runs on watchOS!

[Jacob Carlborg via Digitalmars-d-announce]

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


That is Plan B.2


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


--
/Jacob Carlborg

Re: Better docs for D (WIP)

[Rikki Cattermole via Digitalmars-d-announce]

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

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

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


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

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


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