Re: http://wiki.dlang.org/DIP25

[Tobias Pankrath via Digitalmars-d]

On Wednesday, 31 December 2014 at 06:04:41 UTC, ketmar via
Digitalmars-d wrote:

  void foo (ref int a);
  void bar (int a);

  // and the following calls looks all the same T_T
  int a;
  foo(a);
  bar(a);

but:

  void foo (int* a);
  void bar (int a);

  // wow, we don't even need to look at the signatures to find
  // that `foo` wants a reference and that it therefore can
  // modify `a`!
  int a;
  foo(&a);
  bar(a);


To require ref at the callside was proposed long ago. Dunno if
this would
make Manu's task harder. I agree, that this might have been
better in
the long run.


another "cosmetic issue" that bugs me alot.

p.s. and with pointers it's easy to write something like this:

  auto parseNumber (string s, bool* error=null);

yes, i know about exceptions... which blocks `@nogc`. not yummy.


You could preallocate the exception or use an out parameter.

Re: Worst Phobos documentation evar!

[Manu via Digitalmars-d]

On 31 December 2014 at 16:28, Walter Bright via Digitalmars-d
 wrote:
> Remember that UDAs and even Win64 are supported because of your influence.
> That's actually a pretty nice track record! You've also contributed about 6
> pull requests, 5 of which have been merged.
>
> I made a forceinline proposal at your request, but it sank under the weight
> of controversy over how to do it.

I don't think I was trying to dismiss those things. They were 3-4
years ago and relatively uncontroversial, and already more or less
intended or discussed in the past, I managed to give them a priority
nudge. I hope they were all useful things; I know the win64 stuff in
particular has made D available to a lot of my friends and colleagues
to try out at least, and obviously, we were able to use it at Remedy
on the back of those features. UDAs comes up as useful tools all over
the place.

There seems to be nothing left from me that's uncontroversial. Are you
saying that if I worked on the stuff that I believe in, it would have
a greater chance of being accepted, despite being outright opposed in
conversation?

We're talking about stimulating contribution, and I have no idea what
I could contribute that would be accepted. And also detailing areas of
friction I experience (or perceive) when getting involved in the past.
The only thing that comes to mind is debugger related stuff, but I
know absolutely nothing about it and it seems like a very large time
investment to get up to speed on that stuff such that I could make any
useful fixes.
Both you and Rainer are more-or-less experts on CV8/PDB already.

I would certainly like to resurrect forceinline discussion, but I feel
like it's of lower priority than other topics that are receiving
attention at the moment, so it's probably better not to distract
attention from them for the time being.
I wasn't excited about the pragma approach myself, I can't see any
advantages... but I also wasn't particularly emotional about it, I'll
take what I can get on that front. It just seems like that approach
would lead to inconvenience, and possibly more edges to me. How can
you do anything generic or meta with a pragma? Yay for text mixins! ;)
There were others that felt more strongly about that one than me.

Re: Worst Phobos documentation evar!

[via Digitalmars-d]

My question is how we can break this pattern? What steps can 
the D leadership take to convince folks like you to actually 
add, even with the simplest things?


Speaking as someone new who enjoys dmd (a lot) and considers 
contributing


* It is really hard to understand what is going on by reading the 
forum and watching github.
* The friction in the forum is just amazing. Very entertaining, 
but not leading to motivation or contributions.


For me to be able to contribute in any meaningful way, clearer 
guidelines are needed. Both concerning the communication style in 
forums as well as technical directions such as what needs to be 
build and why. I feel the D leadership needs to set priorities 
and steer the whole effort in a coherent direction.


Uli

Re: http://wiki.dlang.org/DIP25

[via Digitalmars-d]

On Wednesday, 31 December 2014 at 03:25:24 UTC, Manu via 
Digitalmars-d wrote:
On the other hand, power just because we can add it is not 
always a good
thing. C macros are very powerful, but experience has shown it 
is the wrong
kind of power. Also, programmers do not really want a complex 
annotation
system. They want to just write code in the most obvious 
manner and have it
work correctly. Having a powerful (but complex) system is not 
very

attractive.


His point is similar to my other point elsewhere though. I 
don't think
he's talking about 'power' in the sense you describe, what he's 
really

talking about is consistency or uniformity. His original scope
proposal wasn't 'powerful' (even though it was effectively more
powerful), it was holistic, and without the edges that seem to 
have
been introduced to try and 'contain the concept into a smaller 
space',

if that makes sense.

In this particular case, I think practical 'complexity' is being
expressed in the form of awkward edge cases, and the reason that
happened I suspect, is precisely what Andrei asked me to do; 
talk

about the specific problem case, not the general problem that's
recurring in numerous problem cases.
I feel like the current proposals are to effectively add yet 
more
edges to address specific cases, rather than removing the edges 
that

are already present causing the problems in the first place.
Address the problem, don't add layers of patches to round off 
rough edges.


Thank you, I know what I wrote was kind of abstract, this 
describes my thoughts quite well.

Re: GSOC - Holiday Edition

[Dmitry Olshansky via Digitalmars-d]

31-Dec-2014 06:25, Craig Dillabaugh пишет:

I was hoping folks to take a brief break from bickering about features,
and arguing over which posters have been naughty, and which have been
nice, to get a bit of input on our 2015 Google Summer of Code Proposal
... :o)


First off, I've been able to get some work done on the Idea's page, it
is here:

http://wiki.dlang.org/GSOC_2015_Ideas

This is the most important part of our submission, but we are also
supposed to submit a organizational proposal.  I've started on this too
(still under construction, and have put it on Github at:

https://github.com/craig-dillabaugh/dlang-gsoc2015

Any feedback is welcome.


There are currently six project proposals.  I think it would be good to
have one or two more, and the ones that are there need a bit of
polishing. A lot of what is there is stuff I have 'harvested' from
previous proposals. For the GDC and Bare Metal D/Arm Support projects I
am not even sure if the items listed are still needed since these are
basically cut and paste jobs from 1 or 2 years ago.



I'd gladly serve as backup mentor for Bare Metal D project. In fact I 
recall wording as something I might have written a year ago.


Besides I have a small fleet of ARM boards sitting on my table, gotta 
make them useful.


The key guy to get in touch though is Michael Franklin:
http://dconf.org/2014/talks/franklin.html
Would be great to know if he open-sourced some of his stuff.



6) See #2 for Martin Nowak and the Bare Metal D/Arm projects.


I probably could expand on that if desired.



--
Dmitry Olshansky

Re: http://wiki.dlang.org/DIP25

[via Digitalmars-d]

On Wednesday, 31 December 2014 at 00:09:15 UTC, Walter Bright 
wrote:
On 12/30/2014 1:27 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= 
" wrote:
In general, I get the impression from both DIP25 and DIP69 
that both are
motivated by minimizing the change to the existing language, 
instead of looking
for the most powerful solution (that may have other use-cases 
besides the ones
under consideration). I.e., instead of asking which concepts 
are behind the
problem in question, how these concepts could be expressed in 
an ideal world,
and then making compromises to fit them into D, it seems like 
we're starting
with some premises (as few changes as possible, no type 
modifiers), and then
look for a solution that needs to sacrifice the smallest 
number of use cases to
stay within the constraints. This is particularly bad if our 
premises are going
against the nature of the problem we want to solve, because 
then we are

guaranteed to get a bad solution.


On the other hand, power just because we can add it is not 
always a good thing. C macros are very powerful, but experience 
has shown it is the wrong kind of power.


So... how does this apply to our problem concretely? Do you 
believe a full blown ownership/lifetime system is "the wrong kind 
of power"? Remember, we're talking about an ideal world at first. 
If after thorough discussion it turns out that it can't be 
integrated into D, at least we know that it's probably not 
possible. But I haven't seen any indications that this is the 
case; in fact, it's not even been discussed.


Also, programmers do not really want a complex annotation 
system. They want to just write code in the most obvious manner 
and have it work correctly. Having a powerful (but complex) 
system is not very attractive.


But a powerful system doesn't need to be complicated. In fact, a 
system with a handful of general and orthogonal features is 
likely easier to understand and handle in practice than one with 
lots of (even trivial) edge cases and exceptions.

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

What you can contribute that would be very valuable is what we've discussed 
before - your simd expertise. Your influence is what has shaped the current simd 
support. I don't know anyone who knows even half of what you do about simd. What 
you know could make D really fly with vector math.


You and I both know that auto vectorization, the approach used by everyone else, 
is not the key to high performance simd. We have an opportunity here.

Re: Aliases and UDA's

[Jacob Carlborg via Digitalmars-d]

On 2014-12-30 07:01, Manu via Digitalmars-d wrote:

I've got this thing going on where I want to be able to attribute an
alias, but that doesn't seem to work:

@("hello")
struct(X) S
{
   X x;
}

@("world")
alias A = S!int;

Test!A;

template(T) Test
{
   // at this point, if T is some S, then the "hello" attribute is
present, as expected
   // if T is A, "world" is lost
}

I guess the reason is that A is not really a thing; it is translated
to S!int when being given to T?
Is that the point where "world" is lost?


What if you make T an alias parameter, will that work?

--
/Jacob Carlborg

Re: Worst Phobos documentation evar!

[Jacob Carlborg via Digitalmars-d]

On 2014-12-30 02:51, Walter Bright wrote:


(And actually, the Ddoc macro system very closely resembles the one used
by make, as that is a simple and effective one, well known by programmers.)


"make" has to be the worst tool ever created. I not just me that has 
that opinion [1]. That you even consider this as a positive argument is 
baffling me. Or rather not, if you like "make" I can see why you like Ddoc.


[1] http://www.conifersystems.com/whitepapers/gnu-make/

--
/Jacob Carlborg

Re: Worst Phobos documentation evar!

[Dmitry Olshansky via Digitalmars-d]

31-Dec-2014 15:17, Jacob Carlborg пишет:

On 2014-12-30 02:51, Walter Bright wrote:


(And actually, the Ddoc macro system very closely resembles the one used
by make, as that is a simple and effective one, well known by
programmers.)




"simple, effective and well-known" ?

I have to say all of 3 are wrong.


"make" has to be the worst tool ever created. I not just me that has
that opinion [1]. That you even consider this as a positive argument is
baffling me.


+1


Or rather not, if you like "make" I can see why you like Ddoc.

[1] http://www.conifersystems.com/whitepapers/gnu-make/




--
Dmitry Olshansky

Re: http://wiki.dlang.org/DIP25

[Andrej Mitrovic via Digitalmars-d]

On 12/31/14, Andrei Alexandrescu via Digitalmars-d
 wrote:
> On 12/30/14 7:32 PM, Manu via Digitalmars-d wrote:
>> void mayEscape(ref int x); // <-- may escape this ref arg
>>
>> void t()
>> {
>>int onStack = 1;
>>mayEscape(onStack); // <- perfectly legal, and equally unsafe
>> }
>
> DIP25 puts this code in illegality. I don't think the proposal has been
> explicit about that, will fix. Thanks! -- Andrei

Wait, what? Passing stack variables by ref will be disallowed?

Re: Aliases and UDA's

[Manu via Digitalmars-d]

I tried that. It doesn't work.
It's also not really what I want.
On 31/12/2014 9:35 pm, "Jacob Carlborg via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:

> On 2014-12-30 07:01, Manu via Digitalmars-d wrote:
>
>> I've got this thing going on where I want to be able to attribute an
>> alias, but that doesn't seem to work:
>>
>> @("hello")
>> struct(X) S
>> {
>>X x;
>> }
>>
>> @("world")
>> alias A = S!int;
>>
>> Test!A;
>>
>> template(T) Test
>> {
>>// at this point, if T is some S, then the "hello" attribute is
>> present, as expected
>>// if T is A, "world" is lost
>> }
>>
>> I guess the reason is that A is not really a thing; it is translated
>> to S!int when being given to T?
>> Is that the point where "world" is lost?
>>
>
> What if you make T an alias parameter, will that work?
>
> --
> /Jacob Carlborg
>

Re: Worst Phobos documentation evar!

[Ary Borenszweig via Digitalmars-d]

On 12/31/14 9:17 AM, Jacob Carlborg wrote:

On 2014-12-30 02:51, Walter Bright wrote:


(And actually, the Ddoc macro system very closely resembles the one used
by make, as that is a simple and effective one, well known by
programmers.)


"make" has to be the worst tool ever created. I not just me that has
that opinion [1]. That you even consider this as a positive argument is
baffling me. Or rather not, if you like "make" I can see why you like Ddoc.

[1] http://www.conifersystems.com/whitepapers/gnu-make/



Agreed. I try to avoid makefiles as much as I can.

And it's no wonder why there are so many alternatives (rake, nake, etc.)

Trying to avoid the GC

[Shachar Shemesh via Digitalmars-d]

I have a standard processing that needs to be done over and over again, 
with an inner function that is different between invocations. Here is a 
small sample that illustrates the need:


import std.stdio;

alias dtype = void delegate(int i);
void func(T)( T d )
{
foreach(i; 0 .. 10) {
d(i);
}
}

int main()
{
int sum;

func( (int i) {
sum+=i;
});

writeln(sum);

return 0;
}

If you're wondering, "func" is templated in an attempt (unsuccessful) to 
prevent the problem I'm about to describe.


The problem is that despite both functions being in the same compilation 
unit and the fact it is obvious that the delegate passed to func is 
never used outside of the function, "main" cannot be declared @nogc 
(and, in particular, it allocates the frame for main on the heap). This 
is true also of gdc with -O3.


I've tried the exact same program with g++:

#include 

template  void func( T d )
{
for( int i=0; i<10; ++i ) {
d(i);
}
}

int main()
{
int sum;

func([&](int a) { sum+=a; });

std::cout

Naming for mixin template

[HaraldZealot via Digitalmars-d]

Has anybody some methodology or codestyle for mixin template?

I use general nouns for structures and classes and verbs for 
functions. Variables and functions start with lowercase, 
structures, classes and enums uppercase, templates follow their 
internal content (eponymous trick helps very with this). But how 
are good named mixin template?

Re: Worst Phobos documentation evar!

[Joseph Rushton Wakeling via Digitalmars-d]

On 28/12/14 02:00, Walter Bright via Digitalmars-d wrote:

Anyone want to take this on? There's a lot of stuff like this in Phobos. It's
too much for one person to tackle, but if each of us just pick a function here
and there, we can crowdsource and improve things greatly.


Just been having a play with documenting Params/Returns for the free functions 
in std.random.  A number of issues encountered.


First, it looks like the build system has changed since I last tried building 
docs.  If I go with 'make html' in my local phobos branch, the various html 
files generated are all empty -- with their content seemingly intended to be 
filled by javascript which doesn't work.  What gives? :-(


Second and more importantly, I ran into some tricky cases implementing Params: 
lists for functions that have multiple overloads with different parameter lists. 
 As things are, it's convenient -- in terms of reading the code -- to have 
different functions ordered from simple to complex signatures, with one 
documentation block for the first, and everything else sharing the same 
documentation using /// ditto.  However, this won't work with a Params: list 
because ddoc attempts to match listed parameters to those of the immediately 
following function signature.


Trivial example:

/**
 * Params:
 * rng = (optional) random number generator to use;
 *   if not specified, defaults to $(D rndGen)
 *
 * Returns:
 * Floating-point random variate of type $(D T) drawn from the uniform
 * distribution across the half-open interval [0, 1$(RPAREN).
 */
T uniform01(T = double)()
if (isFloatingPoint!T)
{
return uniform01!T(rndGen);
}

/// ditto
T uniform01(T = double, UniformRNG)(ref UniformRNG rng)
if (isFloatingPoint!T && isUniformRNG!UniformRNG)
out (result)
{
assert(0 <= result);
assert(result < 1);
}
body
{
...
}

The above will generate a warning because, of course, the first function 
signature doesn't have a parameter 'rng'.  Since docs are compiled with -w, I 
believe this will result in an error ... ?


In the above case, of course, it's trivial just to swap the order of the 
functions, but in general this is not the case, and it's rather irritating to 
have to tweak everything so that functions are listed in order of 
complex-to-simple signatures rather than simple-to-complex.


It's also not clear to me that one can in general avoid cases where there is a 
group of functions, all doing the same thing, where nevertheless there is no 
single function signature accepting all the possible parameters; and yet, it's 
still very convenient to group together the documentation of those function 
signatures.

Re: Trying to avoid the GC

[Adam D. Ruppe via Digitalmars-d]

On Wednesday, 31 December 2014 at 13:38:05 UTC, Shachar Shemesh 
wrote:

alias dtype = void delegate(int i);
void func(T)( T d )



Try writing that:

void func(scope dtype d)

instead. Or (scope T d) should do it too if you need it to be 
templated. The scope keyword tells the compiler that you promise 
not to escape it from that scope, so it is safe to use stack 
memory. Should prevent the copying to gc of a delegate. (One of 
the few places the scope keyword is actually implemented to do 
something!)


Alternatively, an alias parameter to the template can take a 
predicate - assuming it is static - and generate a new function 
for each one.


void func(alias pred)() {
   foreach(i; 0 .. 10)
   pred(i);
}

Then use it with func!(predicate)(). This is what Phobos 
std.algorithm uses. It can be trickier to actually make it work 
though.


But scope should get you to the next step easily. gdc might even 
inline the delegate then, though I doubt dmd will. Even dmd ought 
not to GC with it tho.

Happy new year!

[Manu via Digitalmars-d]

Here's to an awesome 2015!

Re: Trying to avoid the GC

[Shachar Shemesh via Digitalmars-d]

On 31/12/14 15:52, Adam D. Ruppe wrote:


Try writing that:

void func(scope dtype d)


Yep. That's exactly what I was looking for. On GDC it even allows for 
complete compile time evaluation of the entire loop.


Thanks,
Shachar

Re: Worst Phobos documentation evar!

[Jacob Carlborg via Digitalmars-d]

On 2014-12-30 01:10, Walter Bright wrote:


It's not a hack. The macro system is designed to work that way. All
markup systems require some sort of escape mechanism. Including Markup.


You don't need to escape all the special symbols used in Markdown, only 
in certain place. In Markdown, if you start a line with a star, '*', it 
will be interpreted as the beginning of an unordered list. But if you 
write a star in the middle of text it will just output a star, as expected.


Try for yourself in this online Markdown editor with live preview: 
http://dillinger.io/


--
/Jacob Carlborg

Re: Happy new year!

[Daniel N via Digitalmars-d]

On Wednesday, 31 December 2014 at 14:20:28 UTC, Manu via 
Digitalmars-d wrote:

Here's to an awesome 2015!


Gott Nytt År!

Re: GSOC - Holiday Edition

[Craig Dillabaugh via Digitalmars-d]

On Wednesday, 31 December 2014 at 11:24:00 UTC, Dmitry Olshansky 
wrote:

31-Dec-2014 06:25, Craig Dillabaugh пишет:
I was hoping folks to take a brief break from bickering about 
features,
and arguing over which posters have been naughty, and which 
have been
nice, to get a bit of input on our 2015 Google Summer of Code 
Proposal

... :o)


First off, I've been able to get some work done on the Idea's 
page, it

is here:

http://wiki.dlang.org/GSOC_2015_Ideas

This is the most important part of our submission, but we are 
also
supposed to submit a organizational proposal.  I've started on 
this too

(still under construction, and have put it on Github at:

https://github.com/craig-dillabaugh/dlang-gsoc2015

Any feedback is welcome.


There are currently six project proposals.  I think it would 
be good to

have one or two more, and the ones that are there need a bit of
polishing. A lot of what is there is stuff I have 'harvested' 
from
previous proposals. For the GDC and Bare Metal D/Arm Support 
projects I
am not even sure if the items listed are still needed since 
these are

basically cut and paste jobs from 1 or 2 years ago.



I'd gladly serve as backup mentor for Bare Metal D project. In 
fact I recall wording as something I might have written a year 
ago.


Besides I have a small fleet of ARM boards sitting on my table, 
gotta make them useful.


The key guy to get in touch though is Michael Franklin:
http://dconf.org/2014/talks/franklin.html
Would be great to know if he open-sourced some of his stuff.



6) See #2 for Martin Nowak and the Bare Metal D/Arm projects.


I probably could expand on that if desired.


That is great.  I will add you to my backup mentors list and I 
will check out Michael Franklin's talk.  If you want to make any 
updates to the Wiki section, please feel free.

Re: Happy new year!

[Joseph Rushton Wakeling via Digitalmars-d]

On Wednesday, 31 December 2014 at 14:20:28 UTC, Manu via 
Digitalmars-d wrote:

Here's to an awesome 2015!


Blwyddyn Newydd Dda :-)

Re: Happy new year!

[Craig Dillabaugh via Digitalmars-d]

On Wednesday, 31 December 2014 at 14:55:00 UTC, Joseph Rushton 
Wakeling wrote:
On Wednesday, 31 December 2014 at 14:20:28 UTC, Manu via 
Digitalmars-d wrote:

Here's to an awesome 2015!


Blwyddyn Newydd Dda :-)


Is that welsh?

Re: Worst Phobos documentation evar!

[H. S. Teoh via Digitalmars-d]

On Wed, Dec 31, 2014 at 02:50:34PM +0100, Joseph Rushton Wakeling via 
Digitalmars-d wrote:
[...]
> Second and more importantly, I ran into some tricky cases implementing
> Params: lists for functions that have multiple overloads with
> different parameter lists.  As things are, it's convenient -- in terms
> of reading the code -- to have different functions ordered from simple
> to complex signatures, with one documentation block for the first, and
> everything else sharing the same documentation using /// ditto.
> However, this won't work with a Params: list because ddoc attempts to
> match listed parameters to those of the immediately following function
> signature.

This is a known issue:

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


T

-- 
Some ideas are so stupid that only intellectuals could believe them. -- George 
Orwell

Re: Worst Phobos documentation evar!

[Jacob Carlborg via Digitalmars-d]

On 2014-12-30 00:52, Walter Bright wrote:


(And I should ask, what if you wanted a | in the Markdown?)


Just type a |. You don't need to escape most Markdown symbols in the 
middle of text.



And like I said, what about all the separators in Markdown? What are you
going to do with ", `, |, -, #, and all the other special characters?
It's not like you'll never need them when documenting code.


Most of the time it's not a problem, see above. The only symbols that 
can cause a problem will most likely be used inside a code block anyway, 
where they are not interpreted as Markdown.


--
/Jacob Carlborg

Re: Worst Phobos documentation evar!

[Jacob Carlborg via Digitalmars-d]

On 2014-12-30 04:13, Kiith-Sa wrote:


D blocks in DDoc are usually in:

---
code here
---

With a Markdown-like syntax, inline code could  be in `inline code here` .
I admit you would need to escape the backticks, which are very rare,
especially in inline code fragments. I also admit *that* would force you
to not reliably use *some* D code fragments *outside* backticks. And I
find it unlikely that there are more than 3 fragments in entire Phobos doc
this would break.


You only need to escape backticks in inline code, not code blocks, i.e.

```
auto a = `foo`
```

The above works perfectly fine.

--
/Jacob Carlborg

Re: Happy new year!

[Dmitry via Digitalmars-d]

Happy new year!

Re: Worst Phobos documentation evar!

[Jacob Carlborg via Digitalmars-d]

On 2014-12-30 02:38, Andrei Alexandrescu wrote:


I'm with Walter here - I find Markdown and its ilk inferior to macro
systems. -- Andrei


I don't agree, I feel the opposite. Markdown is superior to Ddoc in 
writing documentation for code. Not web sites, not books, but 
documentation for code.


--
/Jacob Carlborg

Re: Worst Phobos documentation evar!

[Vladimir Panteleev via Digitalmars-d]

On Monday, 29 December 2014 at 22:39:02 UTC, Walter Bright wrote:

* reddit
* github


These both use Markdown. The syntax is the same, except for minor 
things, such as the handling of newlines.



* wiki
* hackernews


Hacker News and both the new D Wiki, and the old, do not use 
Markdown.



::barf::


This, too, is not Markdown.

Re: Worst Phobos documentation evar!

[Jacob Carlborg via Digitalmars-d]

On 2014-12-30 06:13, Rikki Cattermole wrote:


Hmm I have an idea.
I wonder if I can get ddoc to generate json files.


You would still need to write the documentation in Ddoc, which is what 
we're complaining about.


--
/Jacob Carlborg

Re: Worst Phobos documentation evar!

[Jacob Carlborg via Digitalmars-d]

On 2014-12-29 23:44, Walter Bright wrote:


I know. That's what's wrong with it. It is severely underpowered, and so
uses a wretched hybrid approach like C uses a preprocessor because it is
underpowered.


That's what's making it better than ddoc. 90% of the time that power is 
not needed. Ddoc is instead making that 90% of the documentation a lot 
harder to write



In reddit, is it [link](description) or [description](link) or
(link)[description] or (description)[link]? I have to read the dam help
file every time. No, I can't remember what it is for which Markdown
flavor, either.


If it's uses anything other than [text](url) it's not Markdown, period.


BTW, using macros have cut my web page writing time by about 75%. It's
also a joy to just change the macro definitions and voila! the whole web
site fixes itself.


Using Ruby and Haml has improved the time it takes for me to write a web 
site. I can just change a Ruby function or a template the whole site 
changes. That doesn't mean I just Ruby and Haml to document my code. 
Pick the write tool for the job. Markdown is not the right tool to use 
for writing a book or a complete web site. Ddoc is not the right tool 
for documenting code.


--
/Jacob Carlborg

Re: Worst Phobos documentation evar!

[Joseph Rushton Wakeling via Digitalmars-d]

On 31/12/14 16:00, H. S. Teoh via Digitalmars-d wrote:

This is a known issue:

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


Good to know.  Any preferences for proceeding with this?  Put in place the 
params even allowing for the bug, or just avoid the problem params for now?

Re: Happy new year!

[FrankLike via Digitalmars-d]

On Wednesday, 31 December 2014 at 14:20:28 UTC, Manu via 
Digitalmars-d wrote:

Here's to an awesome 2015!

Nice  D!

Re: Happy new year!

[Iain Buclaw via Digitalmars-d]

On 31 Dec 2014 15:00, "Craig Dillabaugh via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 31 December 2014 at 14:55:00 UTC, Joseph Rushton Wakeling
wrote:
>>
>> On Wednesday, 31 December 2014 at 14:20:28 UTC, Manu via Digitalmars-d
wrote:
>>>
>>> Here's to an awesome 2015!
>>
>>
>> Blwyddyn Newydd Dda :-)
>
>
> Is that welsh?

That's Cymru to you!

Re: Happy new year!

[CraigDillabaugh via Digitalmars-d]

On Wednesday, 31 December 2014 at 16:51:45 UTC, Iain Buclaw via 
Digitalmars-d wrote:

On 31 Dec 2014 15:00, "Craig Dillabaugh via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:


On Wednesday, 31 December 2014 at 14:55:00 UTC, Joseph Rushton 
Wakeling

wrote:


On Wednesday, 31 December 2014 at 14:20:28 UTC, Manu via 
Digitalmars-d

wrote:


Here's to an awesome 2015!



Blwyddyn Newydd Dda :-)



Is that welsh?


That's Cymru to you!


Haha, yes.   Happy New Year to everyone.

Re: Happy new year!

[Meta via Digitalmars-d]

祝贺大家新年好！

Happy New Year. Let's make it a good year for D.

Re: Happy new year!

[aldanor via Digitalmars-d]

On Wednesday, 31 December 2014 at 16:55:01 UTC, CraigDillabaugh 
wrote:
On Wednesday, 31 December 2014 at 16:51:45 UTC, Iain Buclaw via 
Digitalmars-d wrote:

On 31 Dec 2014 15:00, "Craig Dillabaugh via Digitalmars-d" <
digitalmars-d@puremagic.com> wrote:


On Wednesday, 31 December 2014 at 14:55:00 UTC, Joseph 
Rushton Wakeling

wrote:


On Wednesday, 31 December 2014 at 14:20:28 UTC, Manu via 
Digitalmars-d

wrote:


Here's to an awesome 2015!



Blwyddyn Newydd Dda :-)



Is that welsh?


That's Cymru to you!


Haha, yes.   Happy New Year to everyone.


Happy New Year, folks!

Re: Happy new year!

[Joseph Rushton Wakeling via Digitalmars-d]

On 31/12/14 17:51, Iain Buclaw via Digitalmars-d wrote:

On 31 Dec 2014 15:00, "Craig Dillabaugh via Digitalmars-d"
mailto:digitalmars-d@puremagic.com>> wrote:
 >
 > On Wednesday, 31 December 2014 at 14:55:00 UTC, Joseph Rushton Wakeling 
wrote:
 >>
 >> On Wednesday, 31 December 2014 at 14:20:28 UTC, Manu via Digitalmars-d 
wrote:
 >>>
 >>> Here's to an awesome 2015!
 >>
 >>
 >> Blwyddyn Newydd Dda :-)
 >
 >
 > Is that welsh?

That's Cymru to you!


Os treisiodd y gelyn fy ngwlad tan ei droed,
Mae hen iaith y Cymru mor fyw ag erioed ;-)

Look at me, posing like I actually speak it :-P

Re: Happy new year!

[Nemanja Boric via Digitalmars-d]

Срећна Нова Година!

On Wednesday, 31 December 2014 at 17:21:08 UTC, Joseph Rushton 
Wakeling via Digitalmars-d wrote:

On 31/12/14 17:51, Iain Buclaw via Digitalmars-d wrote:

On 31 Dec 2014 15:00, "Craig Dillabaugh via Digitalmars-d"
> wrote:

>
> On Wednesday, 31 December 2014 at 14:55:00 UTC, Joseph
Rushton Wakeling wrote:
>>
>> On Wednesday, 31 December 2014 at 14:20:28 UTC, Manu via
Digitalmars-d wrote:
>>>
>>> Here's to an awesome 2015!
>>
>>
>> Blwyddyn Newydd Dda :-)
>
>
> Is that welsh?

That's Cymru to you!


Os treisiodd y gelyn fy ngwlad tan ei droed,
Mae hen iaith y Cymru mor fyw ag erioed ;-)

Look at me, posing like I actually speak it :-P

Re: http://wiki.dlang.org/DIP25

[Brad Anderson via Digitalmars-d]

On Wednesday, 31 December 2014 at 05:28:31 UTC, Andrei 
Alexandrescu wrote:
The alternate hypothesis is "ref" is being misused. "ref" is 
for propagating changes into the arguments. It should be rare 
that code does not actually care for that. Unlike in C++, ref 
is seldom needed for optimizing copies away. -- Andrei


Could you elaborate on that? Say I've got some big, expensive 
struct I want to pass into a function efficiently. In C++ I'd do 
this by const reference (or reference if I'm making changes).


What does D do that would make the ref unnecessary for 
efficiency? I can't imagine the compiler doing any sort of copy 
(even the efficient blig) being as fast as just passing in a 
reference. There is also a problem if the struct has disabled 
postblit. If the compiler silently turned something passed by 
value into a secret reference then it would open the door for 
problems during multithreading.


It is a shame that there is a conflation between an optimization 
and a tool for more flexible code structure. It makes it hard to 
express your intention when you use ref.


With DIP25 it seems like passing in an rvalue by ref would be 
safer and thus open it to being allowed.

Re: Happy new year!

[Jordi Sayol via Digitalmars-d]

El 31/12/14 a les 15:20, Manu via Digitalmars-d ha escrit:
> Here's to an awesome 2015!
> 

Feliç any nou!

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 4:17 AM, Jacob Carlborg wrote:

On 2014-12-30 02:51, Walter Bright wrote:


(And actually, the Ddoc macro system very closely resembles the one used
by make, as that is a simple and effective one, well known by programmers.)


"make" has to be the worst tool ever created. I not just me that has that
opinion [1]. That you even consider this as a positive argument is baffling me.
Or rather not, if you like "make" I can see why you like Ddoc.


You can not like a car's suspension but still like its engine.

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 5:03 AM, Ary Borenszweig wrote:

And it's no wonder why there are so many alternatives (rake, nake, etc.)


Which one has a better text macro system?

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 7:03 AM, Jacob Carlborg wrote:

On 2014-12-30 00:52, Walter Bright wrote:


(And I should ask, what if you wanted a | in the Markdown?)


Just type a |. You don't need to escape most Markdown symbols in the middle of
text.


And when you want a | in a table entry?



Most of the time it's not a problem, see above.


And when it is, how do you escape them?

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 6:29 AM, Jacob Carlborg wrote:

On 2014-12-30 01:10, Walter Bright wrote:


It's not a hack. The macro system is designed to work that way. All
markup systems require some sort of escape mechanism. Including Markup.


You don't need to escape all the special symbols used in Markdown, only in
certain place. In Markdown, if you start a line with a star, '*', it will be
interpreted as the beginning of an unordered list. But if you write a star in
the middle of text it will just output a star, as expected.


I know that Markdown formatting is context sensitive.

And what happens if you want to have a * at the beginning of the line of output? 
And a | in a table entry? And so on for each of the context sensitive things?

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 7:20 AM, Vladimir Panteleev wrote:

On Monday, 29 December 2014 at 22:39:02 UTC, Walter Bright wrote:

* reddit
* github


These both use Markdown. The syntax is the same, except for minor things, such
as the handling of newlines.


Yes, the same only different.



* wiki
* hackernews


Hacker News and both the new D Wiki, and the old, do not use Markdown.


It's just another variation of it - which is my point.

Re: Worst Phobos documentation evar!

[Kiith-Sa via Digitalmars-d]

On Wednesday, 31 December 2014 at 19:11:27 UTC, Walter Bright 
wrote:

On 12/31/2014 7:20 AM, Vladimir Panteleev wrote:
On Monday, 29 December 2014 at 22:39:02 UTC, Walter Bright 
wrote:

* reddit
* github


These both use Markdown. The syntax is the same, except for 
minor things, such

as the handling of newlines.


Yes, the same only different.



* wiki
* hackernews


Hacker News and both the new D Wiki, and the old, do not use 
Markdown.


It's just another variation of it - which is my point.


It's NOT a different variant. It's a different LANGUAGE.

That's like saying D is a variant of Pascal.

Improving ddoc

[Andrei Alexandrescu via Digitalmars-d]

Hello,


In wake of the recent discussions on improving ddoc syntax we're looking 
at doing something about it. Please discuss any ideas you might have 
here. Thanks!


One simple starter would be to allow one escape character, e.g. the 
backtick (`), as a simple way to expand macros: instead of $(MACRO arg1, 
arg2) one can write `MACRO arg1, arg2`.



Andrei

Re: Worst Phobos documentation evar!

[Anon via Digitalmars-d]

On Wednesday, 31 December 2014 at 19:11:27 UTC, Walter Bright 
wrote:

On 12/31/2014 7:20 AM, Vladimir Panteleev wrote:
On Monday, 29 December 2014 at 22:39:02 UTC, Walter Bright 
wrote:

* reddit
* github


These both use Markdown. The syntax is the same, except for 
minor things, such

as the handling of newlines.


Yes, the same only different.


Just like DDoc macros and Makefile macros. They're the same, but 
different.
Also, the differences between Markdown implementations are 
trivial, and do not effect the readability of the source, which 
is the entire point of Markdown - making the "plain-text" 
readable, rather than polluting it with HTML (or DDoc) tag noise.



* wiki
* hackernews


Hacker News and both the new D Wiki, and the old, do not use 
Markdown.


It's just another variation of it - which is my point.


And your point is completely wrong. DDoc and Makefiles both use 
$(MACROS), does that mean that DDoc is a variation of Make?


Yes, *lots* of things use common elements. Because that makes 
things more easily understood when *reading*, which is the single 
most important thing for documentation. The macros are fine for 
when they are needed, but you shouldn't have to use gotos and 
jumps when all you want is a gorram foreach loop. Nor should you 
have to write (or read!) $(UL $(LI A) $(LI B) $(LI C)) to get a 
list.



I know that Markdown formatting is context sensitive.
And what happens if you want to have a * at the beginning of 
the line of

output?
And a | in a table entry? And so on for each of the context 
sensitive things?


A backslash. Y'know, the unambiguous, 
familiar-to-all-programmers, really-hard-to-mistype thing that 
almost everything but HTML and DDoc use for escaping?

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 11:45 AM, Kiith-Sa wrote:

It's NOT a different variant. It's a different LANGUAGE.
That's like saying D is a variant of Pascal.


It's not illegitimate to consider all { } languages as variants of each other.

Re: Worst Phobos documentation evar!

[Kiith-Sa via Digitalmars-d]

On Wednesday, 31 December 2014 at 20:05:43 UTC, Walter Bright 
wrote:

On 12/31/2014 11:45 AM, Kiith-Sa wrote:

It's NOT a different variant. It's a different LANGUAGE.
That's like saying D is a variant of Pascal.


It's not illegitimate to consider all { } languages as variants 
of each other.


With that kind of thinking everyone would still be using COBOL 
and FORTRAN.

Re: Worst Phobos documentation evar!

[ketmar via Digitalmars-d]

On Wed, 31 Dec 2014 10:59:32 -0800
Walter Bright via Digitalmars-d  wrote:

> On 12/31/2014 4:17 AM, Jacob Carlborg wrote:
> > On 2014-12-30 02:51, Walter Bright wrote:
> >
> >> (And actually, the Ddoc macro system very closely resembles the one used
> >> by make, as that is a simple and effective one, well known by programmers.)
> >
> > "make" has to be the worst tool ever created. I not just me that has that
> > opinion [1]. That you even consider this as a positive argument is baffling 
> > me.
> > Or rather not, if you like "make" I can see why you like Ddoc.
> 
> You can not like a car's suspension but still like its engine.

but 'make' is a failure in every aspect, especially GNU make. bwah,
build tool that can't do autoimatic dependency tracking? you must be
joking.


signature.asc
Description: PGP signature

Re: compile-time opIndex

[Dicebot via Digitalmars-d]

On Tuesday, 30 December 2014 at 16:25:05 UTC, Steven 
Schveighoffer wrote:

On 12/30/14 10:51 AM, Dicebot wrote:
On Tuesday, 30 December 2014 at 15:48:03 UTC, Steven 
Schveighoffer wrote:

On 12/18/14 11:54 AM, Dicebot wrote:
I wasn't subscribed to druntime changes thus missed this 
discussion.

Will chime in there soon.


Ping, still waiting on this :)



*blush*


OK, I see your response, but I'm still curious as to 
how/whether your DIP would solve it. Any thoughts on the 
feature brought up in this thread?


-Steve


In this specific case I actually expected this to work:

struct S
{
int key, value;

import std.typetuple;
alias asTuple = TypeTuple!(this.tupleof);

alias asTuple this;
}

void main()
{
S s;
s[0] = 42;
}

However it does not seem to recognize that `this` pointer is 
available in such specific invocation. It can be a bug or there 
may be a legitimate reason preventing it - not entirely sure. 
Unfortunately I have never completely understood cases when alias 
is able to preserve context pointer and when it can't.


If it worked though, my proposal would allow more customized 
access:


struct S
{
int x;

template MyTuple()
{
alias opIndex(size_t i) = S.x;
}

alias MyTuple this; // note it is not MyTuple!()
}

void main()
{
S s;
s[100] = 42;
assert(s[50] == 42);
}

It is not exactly the thing you were originally looking for but I 
am against any attempt to try adding template argument list 
flavor to "normal" aggregates - it creates many new corner cases 
to consider. One example was mentioned in DIP - if `static 
opIndex` is the thing why can't you do S[0] but only s[0]? It is 
static after all! More tricky stuff to explain - not worth the 
feature in my opinion.

Re: Improving ddoc

[H. S. Teoh via Digitalmars-d]

On Wed, Dec 31, 2014 at 11:50:51AM -0800, Andrei Alexandrescu via Digitalmars-d 
wrote:
> Hello,
> 
> In wake of the recent discussions on improving ddoc syntax we're
> looking at doing something about it. Please discuss any ideas you
> might have here.  Thanks!
> 
> One simple starter would be to allow one escape character, e.g. the
> backtick (`), as a simple way to expand macros: instead of $(MACRO
> arg1, arg2) one can write `MACRO arg1, arg2`.
[...]

The problem with using only a single escape character is that it's
ambiguous when nested. If you write `X`Y`Z`, should it be interpreted as
$(X $(Y)) or $(X)Y$(Z)?

Also, the people complaining about $(MACRO ...)) syntax aren't
complaining about the $(...) part specifically, but about the MACRO
part. No matter how you try to prettify it, $(MACRO x y z) is still
`MACRO x y z`. As long as you have a single syntax for all macros, the
syntax people won't be happy. What they are clamoring for is dedicated
syntax for the most common macros, so that they don't have to keep
repeating the MACRO part of the invocation.

Besides, ddoc syntax is really the least of our problems right now, what
with functionality issues like:

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

just to name a few. Everyone wants a new coffee machine but nobody cares
about nuclear reactor usability issues.


T

-- 
Music critic: "That's an imitation fugue!"

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 11:59 AM, Anon wrote:

A backslash. Y'know, the unambiguous, familiar-to-all-programmers,
really-hard-to-mistype thing that almost everything but HTML and DDoc use for
escaping?


Yeah, the reason that people have added WYSIWYG string literals to languages :-)

Re: Lost a new commercial user this week :(

[Dicebot via Digitalmars-d]

On Tuesday, 30 December 2014 at 00:25:28 UTC, Walter Bright wrote:
Criticism about documentation is actually very well-placed - 
it is an issue that
affects everyone, can be fixed in small chunks and does not 
require huge effort

investment for each chunk. No one loses, everyone wins, yay!


I am trying to lead by example, but so far I see only a couple 
pull requests from others improving the Phobos docs.


C'mon, guys, most fixes are pretty trivial, it's just that 
there's a lot of them. If everyone does one for a function 
they're already familiar with, we can get a lot done.


I am personally scared of DDOC and unlikely to do any 
contributions to documentation that require more than just adding 
"Params:" while it is the only option. It is really that bad.


It is also much better when newcomers try proposing documentation 
changes as they have fresh understanding of what is wrong.

Re: Worst Phobos documentation evar!

[ketmar via Digitalmars-d]

On Wed, 31 Dec 2014 11:14:50 -0800
Walter Bright via Digitalmars-d  wrote:

> On 12/31/2014 6:29 AM, Jacob Carlborg wrote:
> > On 2014-12-30 01:10, Walter Bright wrote:
> >
> >> It's not a hack. The macro system is designed to work that way. All
> >> markup systems require some sort of escape mechanism. Including Markup.
> >
> > You don't need to escape all the special symbols used in Markdown, only in
> > certain place. In Markdown, if you start a line with a star, '*', it will be
> > interpreted as the beginning of an unordered list. But if you write a star 
> > in
> > the middle of text it will just output a star, as expected.
> 
> I know that Markdown formatting is context sensitive.
> 
> And what happens if you want to have a * at the beginning of the line of 
> output? 
> And a | in a table entry? And so on for each of the context sensitive things?

that still will be MUCH better than Ddoc.


signature.asc
Description: PGP signature

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 7:13 AM, Jacob Carlborg wrote:

I don't agree, I feel the opposite. Markdown is superior to Ddoc in writing
documentation for code. Not web sites, not books, but documentation for code.


Documentation for code winds up on a web site.

I find it very handy that the Ddoc embedded in D code, and the Ddoc used for the 
rest of the web site, all use the same style sheets, the same macro files, etc. 
And an ebook and pdf can all be generated from the same.

Re: Worst Phobos documentation evar!

[ketmar via Digitalmars-d]

On Wed, 31 Dec 2014 12:05:30 -0800
Walter Bright via Digitalmars-d  wrote:

> On 12/31/2014 11:45 AM, Kiith-Sa wrote:
> > It's NOT a different variant. It's a different LANGUAGE.
> > That's like saying D is a variant of Pascal.
> 
> It's not illegitimate to consider all { } languages as variants of each other.

then D is doomed to vanish. nobody needs another C++, but with broken
syntax and without libraries.


signature.asc
Description: PGP signature

Re: Worst Phobos documentation evar!

[Ary Borenszweig via Digitalmars-d]

On 12/31/14 4:07 PM, Walter Bright wrote:

On 12/31/2014 5:03 AM, Ary Borenszweig wrote:

And it's no wonder why there are so many alternatives (rake, nake, etc.)


Which one has a better text macro system?


A real programming language without text macro systems.

Re: Worst Phobos documentation evar!

[Ary Borenszweig via Digitalmars-d]

On 12/31/14 4:14 PM, Walter Bright wrote:

On 12/31/2014 6:29 AM, Jacob Carlborg wrote:

On 2014-12-30 01:10, Walter Bright wrote:


It's not a hack. The macro system is designed to work that way. All
markup systems require some sort of escape mechanism. Including Markup.


You don't need to escape all the special symbols used in Markdown,
only in
certain place. In Markdown, if you start a line with a star, '*', it
will be
interpreted as the beginning of an unordered list. But if you write a
star in
the middle of text it will just output a star, as expected.


I know that Markdown formatting is context sensitive.

And what happens if you want to have a * at the beginning of the line of
output? And a | in a table entry? And so on for each of the context
sensitive things?


You use a backslash character, like in almost every programming 
language, json, etc.


http://daringfireball.net/projects/markdown/syntax#backslash

Compare \* to $(STAR)

Re: http://wiki.dlang.org/DIP25

[Andrei Alexandrescu via Digitalmars-d]

Andrej Mitrovic via Digitalmars-d  wrote:
> On 12/31/14, Andrei Alexandrescu via Digitalmars-d
>  wrote:
>> On 12/30/14 7:32 PM, Manu via Digitalmars-d wrote:
>>> void mayEscape(ref int x); // <-- may escape this ref arg
>>> 
>>> void t()
>>> {
>>>int onStack = 1;
>>>mayEscape(onStack); // <- perfectly legal, and equally unsafe
>>> }
>> 
>> DIP25 puts this code in illegality. I don't think the proposal has been
>> explicit about that, will fix. Thanks! -- Andrei
> 
> Wait, what? Passing stack variables by ref will be disallowed?

Only to functions that return ref.

Re: Worst Phobos documentation evar!

[Ary Borenszweig via Digitalmars-d]

On 12/31/14 5:33 PM, Walter Bright wrote:

On 12/31/2014 11:59 AM, Anon wrote:

A backslash. Y'know, the unambiguous, familiar-to-all-programmers,
really-hard-to-mistype thing that almost everything but HTML and DDoc
use for
escaping?


Yeah, the reason that people have added WYSIWYG string literals to
languages :-)


Which still look readable (and the backslash is just one character of 
noise so it's also not that bad).

Re: Worst Phobos documentation evar!

[Ary Borenszweig via Digitalmars-d]

On 12/31/14 4:09 PM, Walter Bright wrote:

On 12/31/2014 7:03 AM, Jacob Carlborg wrote:

On 2014-12-30 00:52, Walter Bright wrote:


(And I should ask, what if you wanted a | in the Markdown?)


Just type a |. You don't need to escape most Markdown symbols in the
middle of
text.


And when you want a | in a table entry?



Most of the time it's not a problem, see above.


And when it is, how do you escape them?



Backslash character.

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 11:59 AM, Anon wrote:

Nor should you have to write (or read!) $(UL $(LI A) $(LI B) $(LI C)) to get a 
list.


You don't have to. You can write it as:

 $(LIST A, B, C)

or:

 $(LIST
   A,
   B,
   C
 )


Yes, there currently isn't a LIST macro by default, but you can write one:

  LISTX=$(LI $1) $(LISTX $+)
  LIST=$(UL $(LISTX $1, $+))


I very often write custom macros for a particular job at hand. It's very, very 
handy. For example, suppose I want to switch between a definition list and a 
table? I write a higher level macro, then switch its definition. I can use the 
"X Macro" technique. I can "comment out" a block. I can create "variables". For 
example, when the D source moved from svn to github, the macro in each source 
code file that linked to the repository just needed its definition changed. With 
markdown, I'd have had to have edited every file (what, are there a thousand 
files?). And so on.


  http://en.wikipedia.org/wiki/X_Macro

Re: Worst Phobos documentation evar!

[Ary Borenszweig via Digitalmars-d]

On 12/29/14 10:38 PM, Andrei Alexandrescu wrote:

On 12/29/14 2:30 PM, Dicebot wrote:

DDOC is probably one of D features with pretty idea and hardly usable
design. I wish we had something like Markdown instead - can never
remember Phobos macros to use and usually just resort to using plain
text instead.


I'm with Walter here - I find Markdown and its ilk inferior to macro
systems. -- Andrei



Definitely, because Markdown is not a macro system, it's a documentation 
tool.

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 5:50 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:

The above will generate a warning because, of course, the first function
signature doesn't have a parameter 'rng'.  Since docs are compiled with -w, I
believe this will result in an error ... ?


I know, I don't care for that warning, which was added fairly recently.

Re: Worst Phobos documentation evar!

[Ary Borenszweig via Digitalmars-d]

On 12/27/14 10:00 PM, Walter Bright wrote:

This is so bad there isn't even a direct link to it, it hides in shame.
Just go here:

 http://dlang.org/phobos/std_encoding.html#.transcode

and scroll up one entry. Here it is:

size_t encode(Tgt, Src, R)(in Src[] s, R range);

Encodes c in units of type E and writes the result to the output
range R.
Returns the number of Es written.

Let me enumerate the awesomeness of its awfulness:

1. No 'Return:' block, though it obviously returns a value.
2. No 'Params:' block, though it obviously has parameters.
3. No 'Example:' block
4. No comparison with other 'encode' functions in the same module.
5. No description of what 'Tgt' is.
6. No description of what 'Src' is.
7. No clue where the variable 'c' comes from.
8. No clue where the type 'E' comes from.
9. 'R' is a type, not an instance.
10. I suspect it has something to do with UTF encodings, but there is no
clue.


This one is missing some docs too:

http://dlang.org/phobos/std_math.html#abs

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 7:36 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:

On 31/12/14 16:00, H. S. Teoh via Digitalmars-d wrote:

This is a known issue:

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


Good to know.  Any preferences for proceeding with this?  Put in place the
params even allowing for the bug, or just avoid the problem params for now?



Just ignore the warning.

Re: http://wiki.dlang.org/DIP25

[Dicebot via Digitalmars-d]

On Wednesday, 31 December 2014 at 03:25:24 UTC, Manu via 
Digitalmars-d wrote:
His point is similar to my other point elsewhere though. I 
don't think
he's talking about 'power' in the sense you describe, what he's 
really

talking about is consistency or uniformity. His original scope
proposal wasn't 'powerful' (even though it was effectively more
powerful), it was holistic, and without the edges that seem to 
have
been introduced to try and 'contain the concept into a smaller 
space',

if that makes sense.

In this particular case, I think practical 'complexity' is being
expressed in the form of awkward edge cases, and the reason that
happened I suspect, is precisely what Andrei asked me to do; 
talk

about the specific problem case, not the general problem that's
recurring in numerous problem cases.
I feel like the current proposals are to effectively add yet 
more
edges to address specific cases, rather than removing the edges 
that

are already present causing the problems in the first place.
Address the problem, don't add layers of patches to round off 
rough edges.


This mostly matches my current opinion of DIP25 + DIP69 as well. 
It is not as much problem of lacking power but utterly breaking 
KISS principle - too many special cases to remember, too many 
concepts to learn. Path of minimal necessary change is tempting 
but it is path to C++.

Re: Lost a new commercial user this week :(

[Dicebot via Digitalmars-d]

So, getting back to this. What do I see wrong in this thread? It 
creates a clear message : you don't really want to be a D 
contributor.


Once you start doing it, all privileges of doubt that belong to 
"user" are lost and bunch of obligations suddenly appears. And of 
all obligation worst offender written by Gary is requirement to 
strongly identify oneself with a D project.


Let's get it straight : I don't want to ever be associated with D 
upstream. I have never wanted to be part of Phobos development 
team. Only reason I have write access is that last time I 
complained about issues in pull request management Andrei has 
suddenly given me write access and asked to fix it myself. 
Probably my biggest mistake was agreeing to do it instead of 
answering "fuck you" like Manu did.


And I find this comment by Manu absolutely outrageous:

Surely you can understand that my desire to *use* D as a tool 
is not
at odds with my desire to continue to work in the fields that I 
prefer

to work in?


You can hardly even imagine how angry I was when reading it and 
amount of spoken swearwords that have never reached the NG. Here 
I am just being told in most straightforward way "I don't want to 
work on things I need because I have better things to do so you 
must do those things instead as you can't do anything better 
anyway".


Yes, there was an argument about long-term profit caring about 
users from other fields bring. Sorry, but D community is simply 
not big enough to afford such long-term investments. To make work 
on Windows toolchain of any interest to me following future 
assumption would need to hold true:


- it will actually help to attract new users
- at least some portion of this added user base will decide to 
contribute back, directly or indirectly

- some of resulting contributions will benefit Linux ecosystem too
- that final added value will be higher than original investment

It will take quite a while. I appreciate feedback about what is 
wrong but not _demands_ about what to work on. If kind acceptance 
of any demands is considered inherent duty of anyone it least a 
bit associated with D dev team I kindly ask to remove any access 
from me to avoid any further confusion. There is no way I will 
oblige to image written down by Gary in this thread.

Re: Improving ddoc

[Dicebot via Digitalmars-d]

On Wednesday, 31 December 2014 at 19:50:49 UTC, Andrei 
Alexandrescu wrote:

Hello,


In wake of the recent discussions on improving ddoc syntax 
we're looking at doing something about it. Please discuss any 
ideas you might have here. Thanks!


One simple starter would be to allow one escape character, e.g. 
the backtick (`), as a simple way to expand macros: instead of 
$(MACRO arg1, arg2) one can write `MACRO arg1, arg2`.



Andrei


My biggest issue with DDOC compared to popular stuff like 
Markdown / ReStructured Text : it doesn't look nice as a source. 
Markdown is so cute because it mimics the style of ASCII-based 
text file formatting. DDOC is naturally very verbose because of 
all $(MACRO stuff) and lack of basic primitives for most common 
needs.


I don't feel like any small change in DDOC will make me like/use 
it.

Re: Worst Phobos documentation evar!

[H. S. Teoh via Digitalmars-d]

On Wed, Dec 31, 2014 at 10:17:26PM +0200, ketmar via Digitalmars-d wrote:
> On Wed, 31 Dec 2014 10:59:32 -0800
> Walter Bright via Digitalmars-d  wrote:
> 
> > On 12/31/2014 4:17 AM, Jacob Carlborg wrote:
> > > On 2014-12-30 02:51, Walter Bright wrote:
> > >
> > >> (And actually, the Ddoc macro system very closely resembles the
> > >> one used by make, as that is a simple and effective one, well
> > >> known by programmers.)
> > >
> > > "make" has to be the worst tool ever created. I not just me that
> > > has that opinion [1]. That you even consider this as a positive
> > > argument is baffling me.  Or rather not, if you like "make" I can
> > > see why you like Ddoc.
> > 
> > You can not like a car's suspension but still like its engine.
> 
> but 'make' is a failure in every aspect, especially GNU make. bwah,
> build tool that can't do autoimatic dependency tracking? you must be
> joking.

Yeah no kidding. How do I hate make? Let me count the ways:

1) Recursive make considered harmful. (Google it.)

2) Non-reproducible builds -- you have to make clean; make, just to be
absolutely sure your build is correct (defeats the purpose of a build
tool, really -- might as well use a shell script of compiler commands).

3) Changing compile flags in a makefile does not trigger rebuilding of
all affected targets. You're on your own to kick make into rebuilding
what's needed. Usually, this means yet another `make clean; make`. Which
doesn't always work -- see (6). A great source of heisenbugs.

4) Unnecessary rebuilds -- if you edit a comment in a header file, it
causes a waterfall effect in rebuilding everything that #include's it,
and even though all of the .o files produced are identical to those from
the previous run, make is oblivious to this fact, and wastes time
linking them all and cascading even more rebuilds that depend on the
link products, etc., etc..

5) Timestamps are unreliable -- accidentally touching the timestamp of a
header file included by everything (without changing its contents) will
cause the entire tree to be rebuilt. Timestamps over NFS may be
inconsistent, causing make to randomly rebuild files that don't need to
be rebuilt and skip files that do.

6) Dependency scanning is O(n). Not scalable.

7) No built-in cleanup function -- everybody writes their own `make
clean` rules, which are inevitably wrong (`rm -rf *.o *.so`, but what if
you have an .so that isn't generated by the build?) or incomplete (oops,
forgot to delete the .c file generated by bison). This, coupled with (2)
and (3), leads to heisenbugs where stale libraries from previous builds
get linked into the executable, causing runtime bugs that don't exist in
the source code. The solution? `make clean; make` and have another
coffee break. Very productive. (Except when your make clean rules failed
to delete said stale library, then it's time to \rm -rf and git clone a
new repo.)

8) Implicit dependencies between source files require external tooling
support (gcc -MF, which leaves stray .dep files all over the place,
which `make clean` inevitably forgets to clean up, and which cause
mistakes in the dependency tree when dependencies change and the .dep
files aren't updated before make reads them).

9) Build parameters (e.g. compiler flags) are not well-encapsulated --
the global CFLAGS has to be tweaked, or you have to invent your own
convoluted set of macros that are combined into the final compiler
flags, which leads to a maintenance nightmare.

10) No support for out-of-tree builds (which are increasingly becoming
clear that it's the superior way to go -- littering generated files in
the same directories as source files inevitably leads to a gigantic
mess).

11) No support for simultaneous variant builds such as cross-compiling
for multiple architectures in the same run (unless you manually write
this, which is a royal pain and extremely error-prone for something the
build system *should* have taken care of for you) -- because of (7): all
build variables are global and there's no way to reuse the same build
rules with different target parameters.

12) Many common build tasks are not supported by the core make system,
and require the user to reinvent the wheel, which results in large,
convoluted, and fragile makefiles that stop working as soon as you try
to do something that wasn't anticipated by the makefile authors.

13) Anachronistic syntax requirements, like distinguishing between
spaces and tabs.


Make is like C... it offers you raw functionality to shoot yourself in
the foot and drown in dependency bugs, just like C offers you countless
ways to have buffer overruns and dangling pointers. Yet people glory in
their scars acquired over decades of pain, and build entire ecosystems
around it, such that mention of any alternatives is resisted at best,
and ridiculed and summarily dismissed at worst. What's baffling is that
such a reaction is observed even in the D community, which, ostensibly,
exists exactly because people are finall

Re: Worst Phobos documentation evar!

[H. S. Teoh via Digitalmars-d]

On Wed, Dec 31, 2014 at 12:54:14PM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/31/2014 11:59 AM, Anon wrote:
> >Nor should you have to write (or read!) $(UL $(LI A) $(LI B) $(LI C))
> >to get a list.
> 
> You don't have to. You can write it as:
> 
>  $(LIST A, B, C)
> 
> or:
> 
>  $(LIST
>A,
>B,
>C
>  )
[...]

And what if you need commas in the list items? Oh right, $(COMMA). Very
readable.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you 
wish you hadn't.

Re: Worst Phobos documentation evar!

[H. S. Teoh via Digitalmars-d]

On Wed, Dec 31, 2014 at 12:57:36PM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/31/2014 7:36 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> >On 31/12/14 16:00, H. S. Teoh via Digitalmars-d wrote:
> >>This is a known issue:
> >>
> >>https://issues.dlang.org/show_bug.cgi?id=13270
> >
> >Good to know.  Any preferences for proceeding with this?  Put in place the
> >params even allowing for the bug, or just avoid the problem params for now?
> >
> 
> Just ignore the warning.

Which causes non-existent parameters to slip through (e.g., if you
mistyped a parameter name).


T

-- 
If it breaks, you get to keep both pieces. -- Software disclaimer notice

Re: Worst Phobos documentation evar!

[ketmar via Digitalmars-d]

On Wed, 31 Dec 2014 12:40:20 -0800
Walter Bright via Digitalmars-d  wrote:

> On 12/31/2014 7:13 AM, Jacob Carlborg wrote:
> > I don't agree, I feel the opposite. Markdown is superior to Ddoc in writing
> > documentation for code. Not web sites, not books, but documentation for 
> > code.
> 
> Documentation for code winds up on a web site.

finally, i got your point. D is *your* *personal* *project*. not more,
not less. it something is handy for you, it will be in D, and it
doesn't matter how much other people arguing about changing it. if
something is of no use for you, it would be a miracle to see it in D,
even when the code is ready and almost anyone who cares about the thing
anough wrote "yes, do it!" and i'm not talking about Ddoc here.

and about Ddoc/markdown issue: the quoted sentense says it all. you
want Ddoc to be able to produce websites. and you don't care if some
other people think that Ddoc was invented for documenting the source
code. you know, documenting sources implies easy reading by human
without preprocesing. and easy human-readable format is easy to write.
but yes, it can't create a cool website for you. nor it is good for DTP.

you keep inventing artificial samples to show that one still has to use
escaping in markdown. you know, looking at Ddoc, which consists mostly
of visual noise, i can tell you that markdown is god-given immortal
purity.

yet i got the idea: Ddoc is for websites, not for API documentation. it
happens to understand some D, but the primary goal is to create
website. ok. we just misunderstood why Ddoc is here.

i appreciate all your hard work on D (and on C/C++ compilers too, which
i was used from time to time). but do you really want D to be a widely
used language? seems that you are thinking about some "future users",
who will surely need to write a complex documents right in the D source
code, so Ddoc must resemble DTP languages. that they ("future
users") will write alot of code and so we can't break that unwritten
code by changing the language now. and so on.

what you seem to miss here is that it's the current D users who
spreading a word. make D better for current passionate users, and you
may get those "future users" in the future. make D great, but
frustrating for current passionate users, and you will get no "future
users" at all, 'cause there will be nobody to spread a word about D.

i, for myself, can't see why i have to endure annoyance in the name of
"future users". those "future users" did nothing for me, except making
D frustrating. the thing is that "future users" will have to take what
we giving 'em, not we have to take something that *might* please those
"future users".

do you think that vibe.d is a valuable project? Sönke wants property
enforcement syntax, for example. just ask him! and patch for that
syntax is already here. that patch works, my DMD build using it. yet
Sönke will not come here to argue for this feature for month (or
years?), he is busy developing vibe.d (and other things). Sönke is a
real user with a real project. he can live without property
enforcement, but... besides, enforcing property syntax will solve the
bug with delegate properties, where they need `()()` to really call the
delegate. and we have dfix which can be extended to automatically fix
user code.

and what about tuple syntax? two years passed since PR was submitted.
isn't it enough to stop thinking about how accepting that PR will close
the opportunity to invent better syntax in the future and just accept
it? two years of stagnation is enough to see that this feature is not
at the top of priority list and you and Andrei will *always* have more
important tasks to do. so just merge it and forget! (yes, i know that
it can't be merged right now without rebasing; seems that we simply lost
it)


sorry. i hate new years.


signature.asc
Description: PGP signature

Re: Worst Phobos documentation evar!

[Andrei Alexandrescu via Digitalmars-d]

Ary Borenszweig  wrote:
> On 12/31/14 9:17 AM, Jacob Carlborg wrote:
>> On 2014-12-30 02:51, Walter Bright wrote:
>> 
>>> (And actually, the Ddoc macro system very closely resembles the one used
>>> by make, as that is a simple and effective one, well known by
>>> programmers.)
>> 
>> "make" has to be the worst tool ever created. I not just me that has
>> that opinion [1]. That you even consider this as a positive argument is
>> baffling me. Or rather not, if you like "make" I can see why you like Ddoc.
>> 
>> [1] http://www.conifersystems.com/whitepapers/gnu-make/
>> 
> 
> Agreed. I try to avoid makefiles as much as I can.
> 
> And it's no wonder why there are so many alternatives (rake, nake, etc.)

... Neither of which successful :o)

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 1:19 PM, H. S. Teoh via Digitalmars-d wrote:

On Wed, Dec 31, 2014 at 12:57:36PM -0800, Walter Bright via Digitalmars-d wrote:

On 12/31/2014 7:36 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:

On 31/12/14 16:00, H. S. Teoh via Digitalmars-d wrote:

This is a known issue:

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


Good to know.  Any preferences for proceeding with this?  Put in place the
params even allowing for the bug, or just avoid the problem params for now?



Just ignore the warning.


Which causes non-existent parameters to slip through (e.g., if you
mistyped a parameter name).


You can, of course, occasionally look at the warnings :-)

Re: Worst Phobos documentation evar!

[H. S. Teoh via Digitalmars-d]

On Wed, Dec 31, 2014 at 09:23:58PM +, Andrei Alexandrescu via Digitalmars-d 
wrote:
> Ary Borenszweig  wrote:
> > On 12/31/14 9:17 AM, Jacob Carlborg wrote:
> >> On 2014-12-30 02:51, Walter Bright wrote:
> >> 
> >>> (And actually, the Ddoc macro system very closely resembles the
> >>> one used by make, as that is a simple and effective one, well
> >>> known by programmers.)
> >> 
> >> "make" has to be the worst tool ever created. I not just me that
> >> has that opinion [1]. That you even consider this as a positive
> >> argument is baffling me. Or rather not, if you like "make" I can
> >> see why you like Ddoc.
> >> 
> >> [1] http://www.conifersystems.com/whitepapers/gnu-make/
> >> 
> > 
> > Agreed. I try to avoid makefiles as much as I can.
> > 
> > And it's no wonder why there are so many alternatives (rake, nake,
> > etc.)
> 
> ... Neither of which successful :o)

Yeah, just like D is still floundering in obscurity while inferior
languages like C/C++ continue to flourish. *shrug*


T

-- 
There are four kinds of lies: lies, damn lies, and statistics.

Re: http://wiki.dlang.org/DIP25

[ketmar via Digitalmars-d]

On Wed, 31 Dec 2014 09:40:17 +
Tobias Pankrath via Digitalmars-d  wrote:

> > another "cosmetic issue" that bugs me alot.
> >
> > p.s. and with pointers it's easy to write something like this:
> >
> >   auto parseNumber (string s, bool* error=null);
> >
> > yes, i know about exceptions... which blocks `@nogc`. not yummy.
> 
> You could preallocate the exception or use an out parameter.

i can do alot of things here... and something is not possible with
`ref`. this will not work:

  auto parseNumber (string s, ref bool error=null);

ther is no way to point ref to dummy temp by default, sure, i can write
two functions:

  auto parseNumber (string s, out bool error);
  auto parseNumber (string s) { bool dummy; return parseNumber(s, dummy); }

see how it's turning to messy code with copypasta? the thing is that
`ref` params can't be ommited by specifying `null` here, and there is
no `dummy` placeholder for refs. the same is true for `out`s, of
course.

and preallocating exception is loosing valuable information about the
place where that exception was thrown. or i have to write a module
which emulates `new` for exception objects and don't forget to check if
it is "D exception" or "my exception" in `catch` block, so i can
manually release my exceptions. ah, i'd better go with my ugly pointers.


signature.asc
Description: PGP signature

Re: compile-time opIndex

[Artur Skawina via Digitalmars-d]

On 12/18/14 16:43, Steven Schveighoffer via Digitalmars-d wrote:
> We currently have the ability to do opIndex for simulating an array or other 
> type indexed at runtime.
> 
> But we have no way to simulate the ability of tuple indexing. Such an ability 
> would unleash a huge amount of possibilities, including user-defined tuple 
> types.

   struct TupleWannabe(S) {
  typeof(S.tupleof) tupleof;

  static __memberWannabe() {
 string s;
 foreach (I, _; typeof(S.tupleof))
s ~= `ref `~S.tupleof[I].stringof~`() @property {
 return tupleof[`~I.stringof~`];
  } `;
 return s;
  }
  mixin(__memberWannabe());

  alias tupleof this;
   }
   
   struct S {
  int key;
  string val;
   }

   alias ST = TupleWannabe!S;

   void main() {
  ST s = ST(1, "blah");
  s.key = 2;
  s.val = "yada";
  s[0] = 42;
  s[1] = "etc";
   }

SCNR. Happy new year!

artur

Re: Worst Phobos documentation evar!

[H. S. Teoh via Digitalmars-d]

On Wed, Dec 31, 2014 at 01:26:50PM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/31/2014 1:19 PM, H. S. Teoh via Digitalmars-d wrote:
> >On Wed, Dec 31, 2014 at 12:57:36PM -0800, Walter Bright via Digitalmars-d 
> >wrote:
> >>On 12/31/2014 7:36 AM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> >>>On 31/12/14 16:00, H. S. Teoh via Digitalmars-d wrote:
> This is a known issue:
> 
> https://issues.dlang.org/show_bug.cgi?id=13270
> >>>
> >>>Good to know.  Any preferences for proceeding with this?  Put in
> >>>place the params even allowing for the bug, or just avoid the
> >>>problem params for now?
> >>>
> >>
> >>Just ignore the warning.
> >
> >Which causes non-existent parameters to slip through (e.g., if you
> >mistyped a parameter name).
> 
> You can, of course, occasionally look at the warnings :-)

Of course. But it would be nice if this wasn't necessary in the first
place. :-)

Yes, yes, I know, where's the PR... I'll get to it! This week just isn't
a good time for that, too many things going on IRL. I'm planning to
submit some ddoc-related PRs in the near future; it would be a good time
to fold this one in too.


T

-- 
Famous last words: I *think* this will work...

Re: compile-time opIndex

[H. S. Teoh via Digitalmars-d]

On Wed, Dec 31, 2014 at 10:34:07PM +0100, Artur Skawina via Digitalmars-d wrote:
> On 12/18/14 16:43, Steven Schveighoffer via Digitalmars-d wrote:
> > We currently have the ability to do opIndex for simulating an array
> > or other type indexed at runtime.
> > 
> > But we have no way to simulate the ability of tuple indexing. Such
> > an ability would unleash a huge amount of possibilities, including
> > user-defined tuple types.
> 
>struct TupleWannabe(S) {
>   typeof(S.tupleof) tupleof;
> 
>   static __memberWannabe() {
>  string s;
>  foreach (I, _; typeof(S.tupleof))
> s ~= `ref `~S.tupleof[I].stringof~`() @property {
>  return tupleof[`~I.stringof~`];
>   } `;
>  return s;
>   }
>   mixin(__memberWannabe());
> 
>   alias tupleof this;
>}
>
>struct S {
>   int key;
>   string val;
>}
> 
>alias ST = TupleWannabe!S;
> 
>void main() {
>   ST s = ST(1, "blah");
>   s.key = 2;
>   s.val = "yada";
>   s[0] = 42;
>   s[1] = "etc";
>}
> 
> SCNR. Happy new year!
[...]

Very nice! Now make it work for int* and string*, but indexing the tuple
returns (non-pointer) int and string. This is the original use case that
prompted this ER, btw, so if it can't be achieved, then we haven't
solved anything.


T

-- 
In theory, there is no difference between theory and practice.

Re: compile-time opIndex

[Dicebot via Digitalmars-d]

On Wednesday, 31 December 2014 at 21:37:37 UTC, H. S. Teoh via 
Digitalmars-d wrote:
Very nice! Now make it work for int* and string*, but indexing 
the tuple
returns (non-pointer) int and string. This is the original use 
case that
prompted this ER, btw, so if it can't be achieved, then we 
haven't

solved anything.


My original point was that it shouldn't be done even if it can be 
done.

Re: Trying to avoid the GC

[ketmar via Digitalmars-d]

On Wed, 31 Dec 2014 13:52:02 +
"Adam D. Ruppe via Digitalmars-d"  wrote:

> On Wednesday, 31 December 2014 at 13:38:05 UTC, Shachar Shemesh 
> wrote:
> > alias dtype = void delegate(int i);
> > void func(T)( T d )
> 
> 
> Try writing that:
> 
> void func(scope dtype d)
> 
> instead. Or (scope T d) should do it too if you need it to be 
> templated. The scope keyword tells the compiler that you promise 
> not to escape it from that scope, so it is safe to use stack 
> memory. Should prevent the copying to gc of a delegate. (One of 
> the few places the scope keyword is actually implemented to do 
> something!)

an it's so well hidden that not many people know about it. being a not
very careful reader myself i discovered such `scope` usage while
reading some code in another project and was a little puzzled.


signature.asc
Description: PGP signature

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 12:55 PM, Ary Borenszweig wrote:

Definitely, because Markdown is not a macro system, it's a documentation tool.


I write a lot of documentation. A macro system has saved enormous amounts of 
effort. Night and day, really. Not having a macro system is like using a 
programming language that does not have functions.


Ketmar, for example, complained mightily about Ddoc markup. I suggested he 
simply email me the Phobos documentation he wants to write, and I'd mark it up 
for him and submit the PRs. He admitted he is not interested in actually writing 
any documentation. Ddoc is not the real issue, at least for him.


I'll extend the same offer to you. Email me the fixed Phobos docs. I'll mark 
them up and submit PRs.



The thing is, with Ddoc you don't actually have to write any markup. You can 
write:

/
This function does blah, blah, blah.

Blah, blah, blah is an amazing algorithm invented by I. M. Nerdly.

Params:
   x = the awesome input value

Returns:
   insightful description of the return value

Example:
---
int foo(int x) { ... stunning D code ... }
---
***/

Re: Happy new year!

[ketmar via Digitalmars-d]

On Wed, 31 Dec 2014 17:35:51 +
Nemanja Boric via Digitalmars-d  wrote:

> Срећна Нова Година!

З Новим Роком! ;-)


signature.asc
Description: PGP signature

Re: Improving ddoc

[ketmar via Digitalmars-d]

On Wed, 31 Dec 2014 11:50:51 -0800
Andrei Alexandrescu via Digitalmars-d 
wrote:

> In wake of the recent discussions on improving ddoc syntax we're looking 
> at doing something about it. Please discuss any ideas you might have 
> here. Thanks!

ahem... kill it and use markdown instead.


signature.asc
Description: PGP signature

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 1:17 PM, H. S. Teoh via Digitalmars-d wrote:

And what if you need commas in the list items? Oh right, $(COMMA). Very
readable.


And Markdown never needs escapes. Right. :-)

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 12:54 PM, Ary Borenszweig wrote:

Which still look readable (and the backslash is just one character of noise so
it's also not that bad).


(Then you've never tried to use regex string literals in C code.)

C++ would not have added raw string literal syntax if this was not an issue. It 
was a welcome improvement from anyone I've heard comment on it.

Re: compile-time opIndex

[H. S. Teoh via Digitalmars-d]

On Wed, Dec 31, 2014 at 09:41:18PM +, Dicebot via Digitalmars-d wrote:
> On Wednesday, 31 December 2014 at 21:37:37 UTC, H. S. Teoh via Digitalmars-d
> wrote:
> >Very nice! Now make it work for int* and string*, but indexing the
> >tuple returns (non-pointer) int and string. This is the original use
> >case that prompted this ER, btw, so if it can't be achieved, then we
> >haven't solved anything.
> 
> My original point was that it shouldn't be done even if it can be
> done.

Point. But that means we've gone nowhere with AA .byPair().

If I wanted to stir up controversy, I'd say that the ultimate cause of
this issue was the fact that struct fields can't be ref; otherwise it
would be a non-problem (make .key and .value ref, and then .tupleof will
Just Work(tm)).


T

-- 
Bare foot: (n.) A device for locating thumb tacks on the floor.

Re: Worst Phobos documentation evar!

[H. S. Teoh via Digitalmars-d]

On Wed, Dec 31, 2014 at 01:51:25PM -0800, Walter Bright via Digitalmars-d wrote:
> On 12/31/2014 1:17 PM, H. S. Teoh via Digitalmars-d wrote:
> >And what if you need commas in the list items? Oh right, $(COMMA).
> >Very readable.
> 
> And Markdown never needs escapes. Right. :-)

It needs escapes in far less places than ddoc does. When escapes are
inescapable(!), you want the solution with less occurrences, not the
solution with more.


T

-- 
In theory, software is implemented according to the design that has been 
carefully worked out beforehand. In practice, design documents are written 
after the fact to describe the sorry mess that has gone on before.

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 12:44 PM, ketmar via Digitalmars-d wrote:

that still will be MUCH better than Ddoc.


After you refused my offer to add in the Ddoc for you, saying you weren't going 
to write documentation regardless, it's hard to put much weight on your opinion 
about it.

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 12:49 PM, Ary Borenszweig wrote:

Compare \* to $(STAR)


I found two instances of $(COMMA) across the Phobos sources, and neither were 
necessary.

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 1:23 PM, Andrei Alexandrescu wrote:

And it's no wonder why there are so many alternatives (rake, nake, etc.)

... Neither of which successful :o)


I googled nake and couldn't find any references to it.

Re: Worst Phobos documentation evar!

[Walter Bright via Digitalmars-d]

On 12/31/2014 1:15 PM, H. S. Teoh via Digitalmars-d wrote:

Yeah no kidding. How do I hate make? Let me count the ways:


Ironically, none of your points mention the macro system.

Re: Worst Phobos documentation evar!

[ketmar via Digitalmars-d]

On Wed, 31 Dec 2014 14:14:46 -0800
Walter Bright via Digitalmars-d  wrote:

> On 12/31/2014 1:23 PM, Andrei Alexandrescu wrote:
> >> And it's no wonder why there are so many alternatives (rake, nake, etc.)
> > ... Neither of which successful :o)
> 
> I googled nake and couldn't find any references to it.
"nake build system", first link from google:

"Nake is a magic task runner tool for .NET. It's a hybrid of Shovel and
Rake. The DSL for defining tasks is uniquely minimal and it's just
plain C# code!"


signature.asc
Description: PGP signature

Re: Worst Phobos documentation evar!

[ketmar via Digitalmars-d]

On Wed, 31 Dec 2014 14:19:00 -0800
Walter Bright via Digitalmars-d  wrote:

> On 12/31/2014 1:15 PM, H. S. Teoh via Digitalmars-d wrote:
> > Yeah no kidding. How do I hate make? Let me count the ways:
> 
> Ironically, none of your points mention the macro system.

that's 'cause 'make' doesn't need any. it's either enough to have
envvars for simple tool, or you need a scripting language for complex
extensible tool.


signature.asc
Description: PGP signature

Re: Worst Phobos documentation evar!

[ketmar via Digitalmars-d]

On Wed, 31 Dec 2014 14:10:06 -0800
Walter Bright via Digitalmars-d  wrote:

> On 12/31/2014 12:44 PM, ketmar via Digitalmars-d wrote:
> > that still will be MUCH better than Ddoc.
> 
> After you refused my offer to add in the Ddoc for you, saying you weren't 
> going 
> to write documentation regardless, it's hard to put much weight on your 
> opinion 
> about it.

what use for me in such documentation? i can do Ddoc myself, i just
can't read the result. what i want is readable documentation in .d
files, without any preprocessing. Ddoc can't do that. so i can't see
any sense in investing time to write documentation which then will be
uglified by Ddoc.


signature.asc
Description: PGP signature