521 days, 22 hours, 7 minutes and 52 seconds...

...is what took to get std.experimental.logger in Phobos.

https://github.com/D-Programming-Language/phobos/pull/1500

A time to celebrate! Many thanks to Robert who carried it through a long 
gestation, Dicebot for managing the review process, and everybody who 
provided feedback, especially Martin Nowak for his ideas.

Andrei

Re: [WORK] groupBy is in! Next: aggregate

On 1/26/15 8:11 AM, H. S. Teoh via Digitalmars-d wrote:
> On Mon, Jan 26, 2015 at 11:26:04AM +0000, bearophile via Digitalmars-d wrote:
>> Russel Winder:
>>
>>> but is it's name "group by" as understood by the rest of the world?
>>
>> Nope...
> [...]
>
> I proposed to rename it but it got shot down. *shrug*
>
> We still have a short window of time to sort this out, before 2.067 is
> released...

My suggestion was to keep the name but change the code of your groupBy 
implementation to return tuple(key, lazyValues) instead of just 
lazyValues. That needs to happen only for binary predicates; unary 
predicates will all have alternating true/false keys.

Seems that would please everyone.

Andrei

Re: accept <at> pure <at> nothrow <at> return attributes

On 26/01/2015 11:39, Jonathan M Davis via Digitalmars-d wrote:
> the increased visual
> noise definitely is not.

Being able to ignore things starting with  <at>  is useful when reading 
function signatures:

 <at> property const(T)  <at> pure  <at> nothrow foo(Arg arg, T bar) const ...

So  <at>  can actually be signal rather than noise.

Re: accept <at> pure <at> nothrow <at> return attributes

On 26/01/2015 11:39, Jonathan M Davis via Digitalmars-d wrote:
> In theory, the increased consistency is welcome, but the increased visual
> noise definitely is not.  And if we leave in pure and nothrow without  <at> ,
> then we're going to have code out there doing both, which adds to the
> confusion, and if we deprecate pure and nothrow without  <at> , then we'll be
> forced to change pretty much every D program in existence.

Only if the deprecation became an error.

> But It's not like this really improves consistency all that much anyway,
> because public, protected, package, private, final, override, static, const,
> immutable, inout, and deprecated all don't have  <at> .

Most of those also apply to variable members. pure, nothrow, return only 
apply to functions.

I like this change, but it might be better if final, override and inout 
gained  <at> attribute syntax too. Then it would have more consistency.

Also the inverted-attribute option then doesn't need !ugly !sigils - 
 <at> impure vs  <at> pure,  <at> throw vs  <at> nothrow, etc.

> In fact, priore to this,  <at> safe,
>  <at> trusted,  <at> system, and  <at> property were the_only_  function attributes with  <at> 
> on them.

There's also  <at> disable and more recently,  <at> nogc.

Dan Olson via Digitalmars-d | 26 Jan 17:49 2015

phobos and 64-bit real, anybody testing?

A question for the floating point experts.  Do phobos unittests get run
on any architectures with 64-bit reals?  I would like to know if there
are known failures.

I have identified all the phobos unittest failures on ARMv7 iOS and
commented out failing asserts so that the remainder of the module
unittests could pass.  An example where there are many failed tests is
std.internal.math.gammafunction where a nan is produced but a valid
value is expected.  Other times the computed result is completely
different from what is expected.  Note that for ARM I am clearing "Flush
to Zero" and "Default NaN" modes in fpscr which helps pass many other
tests.  Normally these modes are enabled for iOS.  Also, iOS uses
float-abi=softfp.
--
Dan

Re: dlang.org redesign -- the state of documentation and learning resources [part 2]

On 1/25/15 4:42 AM, Andrej Mitrovic via Digitalmars-d wrote:
> Here's another one:
>
> The search box allows selecting between:
> - Entire D Site
> - Library reference
> - Newsgroup archives
>
> But where's the Language spec option?

It's missing due to how dlang.org is set up, and the limitations of 
Google's site search feature. If you click on a link in the language 
spec, like on Types, you'll notice that its URL has the page directly 
under dlang.org, e.g. http://dlang.org/type.html.

In contrast, the standard library is in a subfolder (e.g. 
http://dlang.org/phobos/std_algorithm.html) and the newsgroup archives 
are in another subfolder. Being in a subfolder allows us to pass a 
prefix parameter to Google's site search that will limit its results to 
URLS with that prefix. Since the language reference isn't in a subfolder 
there's no prefix for the language reference that doesn't also include 
everything else in the site, and hence there's no option for Language Spec.

I don't know how hard it would be to put all the language spec pages 
into their own subfolder, but doing so would allow us to add the 
Language Spec option to the dropdown.

via Digitalmars-d | 26 Jan 17:44 2015

Re: [WORK] groupBy is in! Next: aggregate

On Monday, 26 January 2015 at 16:13:40 UTC, H. S. Teoh wrote:
> On Mon, Jan 26, 2015 at 11:26:04AM +0000, bearophile via 
> Digitalmars-d wrote:
>> Russel Winder:
>> 
>> >but is it's name "group by" as understood by the rest of the 
>> >world?
>> 
>> Nope...
> [...]
>
> I proposed to rename it but it got shot down. *shrug*

Andrei had a point about `partition` being used already. I liked 
Oliver's suggestion to go with slice-something. `sliceBy` might 
be worth considering. It even hints at the (efficient) 
implementation.

Re: accept <at> pure <at> nothrow <at> return attributes

I agree with Jonathan's points, this solution doesn't seem like 
an improvement.   If I understand the problem, we don't want to 
make every attribute use the ' <at> ' symbol because it looks bad and 
would cause a lot of code changes for sake of consistency.  
However, on the other hand, we don't want to support the new 
properties because we have to add them as keywords which would 
break code using those words and would make the language more 
restrictive (nothing can be named nogc/safe/...).

Assuming I understand the problem, couldn't we modify the 
language grammar to support more attributes without making them 
keywords?  Then we can omit the ' <at> ' on future code (and fix the 
old code if we want) and we don't have to litter the language 
with new keywords.

I understand that doing this may be fairly complicated.  This may 
create some ambiguities in the grammar that would need to be 
handled carefully, but if it can work I think this would be a 
good option.

via Digitalmars-d | 26 Jan 16:47 2015

Re: accept <at> pure <at> nothrow <at> return attributes

On Monday, 26 January 2015 at 15:07:24 UTC, Jonathan M Davis 
wrote:
> On Monday, January 26, 2015 13:21:54 via Digitalmars-d wrote:
> function. So, I
> don't think that that particular distinction would work, even 
> if we could
> freely rearrange which attributes had  <at>  and which didn't.

I personally agree that it would be better to remove " <at> " like you 
suggested and leave it for UDAs. Interpreting D code is hard for 
tools without a library anyway, so I think the current approach 
is unwarranted, and would rather see a more complicated grammar 
and parser in favour of usability. D could provide an official 
parser/semantic analysis library available for tools (like clang).

The visual noise in D2 is too high IMO, and the reuse of 
keywords/symbols for unrelated functionality makes 
usability/legibility/reading comprehension worse.  I think this 
alone is enough to prevent mainstream adoption.

Other languages compensate by having constructs that allow you do 
use "keywords" for fieldnames in records. It is a better 
strategic move to favour good syntactical usability/legibility 
over parsing complexity. Clean context independent mapping 
between syntax and semantics is important.

Besides, D really needs to allow the use of common nouns like 
"body" in structs (e.g. to implement the HTML DOM)... so a more 
wholesome approach to rethinking the D syntax would be welcome.

(Continue reading)

Re: accept <at> pure <at> nothrow <at> return attributes

On Monday, 26 January 2015 at 13:57:13 UTC, Kenji Hara wrote:
> 2015-01-26 21:03 GMT+09:00 bearophile via Digitalmars-d <
> digitalmars-d <at> puremagic.com>:
>
>> Jonathan M Davis:
>>
>>  Personally, I'd much prefer that we not make this change. 
>> It's just
>>> shuffling things around in an attempt to make them more 
>>> consistent while
>>> actually making them _less_ consistent.
>>>
>>
>> So far I agree with Jonathan.
>>
>> Bye,
>> bearophile
>>
>
> Me too. At best it is just a cosmetic change, and will 
> introduce huge code
> style confusion.
>
> We should revert it quickly.
>
> Kenji Hara

Yes we should, it does not fix anything

(Continue reading)

via Digitalmars-d | 26 Jan 14:21 2015

Re: accept <at> pure <at> nothrow <at> return attributes

On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis 
wrote:
> immutable, inout, and deprecated all don't have  <at> . So, most 
> function
> attributes _don't_ have  <at>  on them, and we just added  <at>  to some 
> of them,
> making things even _less_ consistent. In fact, priore to this, 
>  <at> safe,
>  <at> trusted,  <at> system, and  <at> property were the _only_ function 
> attributes with  <at> 
> on them. So, if we really wanted to improve consistency IMHO, 
> we'd get rid
> of  <at>  from everything that's built-in and leave it for 
> user-defined
> attributes, but that would break existing code too.

I agree  that you need to let " <at> " act as some kind of mnemonic 
and therefore assign meaning to it.

One meaning would be to only use " <at> " with attributes that do not 
affect computation, typing, overloading etc and use it only for 
safety-checks and optimization hints (like inlining).

Besides it would be easy to change the parser so that terms can 
be reused as symbols if the grammar stays sound. I think that is 
true for most function attributes anyway.


Gmane