Re: std.zip
On 2015-01-26 at 03:41, Vladimir Panteleev wrote: On Monday, 26 January 2015 at 02:14:00 UTC, FG wrote: http://fgda.pl/static/std_zip.patch How about submitting this patch as a pull request? http://wiki.dlang.org/Pull_Requests OK, I will. First I'll run some tests and perhaps also do the writer. Wouldn't want to waste your time on something that doesn't work.
Re: Calypso and the future of D
On 2015-01-26 01:37, Walter Bright wrote:
I'm obviously terrible at communicating. Let me try again. Assume that I
wrote Calypso, and I was explaining it to you:
-
Given the C++ header file foo.h:
void bar(unsigned *);
and the C++ source file foo.cpp:
void bar(unsigned *p) { }
I want to call bar() from my D code in test.d:
void main() {
uint x;
bar(&x);
}
Here's how to do it with Calypso:
calypso foo.h
which will generate the file foo.d. add an import to test.d:
import foo;
void main() {
uint x;
bar(&x);
}
To compile and link:
clang++ foo.cpp -c
dmd test foo.o
Which generates the program 'test' which can be run.
It works something like this:
Given the C++ header file foo.h:
void bar(unsigned *);
and the C++ source file foo.cpp:
void bar(unsigned *p) { }
I want to call bar() from my D code in test.d:
void main() {
uint x;
bar(&x);
}
Here's how to do it with Calypso:
module test;
modmap (C++) "foo.h";
import (C++) _ : bar;
void main() {
uint x;
bar(&x);
}
To compile and link:
clang++ foo.cpp -c
ldc test.d foo.o
Which generates the program 'test' which can be run.
Calypso is not a separate tool. It's a fork of LDC which allows you to
directly import/include a C++ header files and use the declarations from
within D. No bindings or intermediate files are necessary.
--
/Jacob Carlborg
Image Processing in D vs Python
https://github.com/ankitrohatgi/learn_dlang/tree/master/freeimage https://www.reddit.com/r/programming/comments/2tp7a3/image_processing_in_d_vs_python_a_quick_and_dirty/
Re: Calypso and the future of D
On 1/26/2015 12:18 AM, Jacob Carlborg wrote:
It works something like this:
Given the C++ header file foo.h:
void bar(unsigned *);
and the C++ source file foo.cpp:
void bar(unsigned *p) { }
I want to call bar() from my D code in test.d:
void main() {
uint x;
bar(&x);
}
Here's how to do it with Calypso:
module test;
modmap (C++) "foo.h";
import (C++) _ : bar;
void main() {
uint x;
bar(&x);
}
To compile and link:
clang++ foo.cpp -c
ldc test.d foo.o
Which generates the program 'test' which can be run.
Calypso is not a separate tool. It's a fork of LDC which allows you to directly
import/include a C++ header files and use the declarations from within D. No
bindings or intermediate files are necessary.
Thank you. That really, really needs to go into the README.md, especially the
last paragraph.
Re: defunct / stale forums on front page
On 2015-01-26 08:35, H. S. Teoh via Digitalmars-d wrote: I think we should just import jquery into the dlang.org repo. External dependencies always end up in these kinds of ugly situations. The advantage of using a CDN is that browser will most likely already have loaded, in this case jQuery, from another page you already have visited. -- /Jacob Carlborg
Re: Image Processing in D vs Python
On Monday, 26 January 2015 at 08:33:40 UTC, Walter Bright wrote: https://github.com/ankitrohatgi/learn_dlang/tree/master/freeimage https://www.reddit.com/r/programming/comments/2tp7a3/image_processing_in_d_vs_python_a_quick_and_dirty/ https://github.com/ankitrohatgi/learn_dlang/blob/master/freeimage/compile.sh is he not using any optimizations?
Re: D Meetup in Berlin
On Sunday, 25 January 2015 at 14:10:15 UTC, Dicebot wrote: tl; dr: it has happenned and it was nice :) I will let Ben post some more details. AFAIU plan is to move on with ~monthly events. So first up thanks everyone for coming and making it a good event, a good time was had by all I think. The current plan moving forward, based on feedback from people on the night, is to try and organize monthly meetups that will take place on a Friday night. The format will be one main presentation followed by questions, discussion, and a drink or two. The presentations could be in the form of a formal talk, a workshop style discussion talk, or even a discussion about some problems you are currently having with some facet of D. There is also the option to have a time for one or two lightning talks after the initial presentation. The venue we used was great but I don't think it will work for presentations so we will need to find a new venue. I'll post again when I have found a good venue and we have a date for the next meetup. Thanks again to everyone for coming along and making it a good night.
Re: Image Processing in D vs Python
On 1/26/15 1:05 AM, weaselcat wrote: On Monday, 26 January 2015 at 08:33:40 UTC, Walter Bright wrote: https://github.com/ankitrohatgi/learn_dlang/tree/master/freeimage https://www.reddit.com/r/programming/comments/2tp7a3/image_processing_in_d_vs_python_a_quick_and_dirty/ https://github.com/ankitrohatgi/learn_dlang/blob/master/freeimage/compile.sh is he not using any optimizations? Please reply on reddit. -- Andrei
accept @pure @nothrow @return attributes
If someone is not following the merges, well... [1] !! --- Paolo [1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034...@hookshot-fe4-cp1-prd.iad.github.net.mail
Re: accept @pure @nothrow @return attributes
On 1/26/15 1:50 AM, Brian Schott wrote: On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote: If someone is not following the merges, well... [1] !! --- Paolo [1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034...@hookshot-fe4-cp1-prd.iad.github.net.mail I'm running out of ideas for DConf topics. Heh, I infer that's a good thing. Nevertheless we should probably discuss this and its impact; don't forget we can always undo it before 2.067. Thoughts! -- Andrei
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote: If someone is not following the merges, well... [1] !! --- Paolo [1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034...@hookshot-fe4-cp1-prd.iad.github.net.mail I'm running out of ideas for DConf topics.
Re: accept @pure @nothrow @return attributes
On Mon, 26 Jan 2015 09:29:40 +, Paolo Invernizzi wrote: i'm scared. does that mean that my rants about "consistency" was sane after all? and now i have to find something else to attack? (sigh) poor me. signature.asc Description: PGP signature
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 09:54:31 UTC, Andrei Alexandrescu wrote: On 1/26/15 1:50 AM, Brian Schott wrote: On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote: If someone is not following the merges, well... [1] !! --- Paolo [1] http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034...@hookshot-fe4-cp1-prd.iad.github.net.mail I'm running out of ideas for DConf topics. Heh, I infer that's a good thing. Nevertheless we should probably discuss this and its impact; don't forget we can always undo it before 2.067. Thoughts! -- Andrei The extra glyphs add a bit of visual noise, but I think that's balanced out by the better consistency of the language and the growing sphere of functions which can have their attributes inferred.
Re: Calypso and the future of D
On Monday, 26 January 2015 at 08:59:34 UTC, Walter Bright wrote: On 1/26/2015 12:18 AM, Jacob Carlborg wrote: Calypso is not a separate tool. It's a fork of LDC which allows you to directly import/include a C++ header files and use the declarations from within D. No bindings or intermediate files are necessary. Thank you. That really, really needs to go into the README.md, especially the last paragraph. Now I feel sorry for Elie. He contributed a great idea, put in a huge amount of work, still has miles to go, tried hard to be helpful and D's very own mastermind does not seem to care enough to read his announcement. His very first sentence reads "I have the pleasure to announce to you all the existence of a modified LDC able to interface directly to C++ libraries, wiping out the need to write bindings:" The idea is just brilliant. I for one am excited about the prospect. Lets please discuss how to get the plugin into D, sooner rather than later. No language is an island. (Apologies to Nick Hornby and everyone else offended.)
Re: Calypso and the future of D
On 1/26/2015 1:58 AM, "Ulrich =?UTF-8?B?S8O8dHRsZXIi?= " wrote: The idea is just brilliant. I for one am excited about the prospect. Lets please discuss how to get the plugin into D, sooner rather than later. No language is an island. (Apologies to Nick Hornby and everyone else offended.) I am pretty excited as well about Calypso and think it can be very effective in making D more usable. Thank you, Elie!
Re: [WORK] groupBy is in! Next: aggregate
On Fri, 2015-01-23 at 10:08 -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
[…]
> #!/usr/bin/rdmd
>
> void main()
> {
> import std.algorithm, std.stdio;
> [293, 453, 600, 929, 339, 812, 222, 680, 529, 768]
> .groupBy!(a => a & 1)
> .writeln;
> }
>
>
> [[293, 453], [600], [929, 339], [812, 222, 680], [529], [768]]
>
[…]
I think I must be missing something, for me the result of a groupBy
operation on the above input data should be:
[1:[293, 453, 929, 339, 529], 0:[600, 812, 222, 680, 768]]
i.e. a map with keys being the cases and values being the values that
meet the case. In this example a & 1 asks for cases "lowest bit 0 or 1"
aka "odd or even".
There is nothing wrong with the semantics of the result above, but is
it's name "group by" as understood by the rest of the world?
--
Russel.
=
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: accept @pure @nothrow @return attributes
On 1/26/2015 1:50 AM, Brian Schott wrote: I'm running out of ideas for DConf topics. I don't think there's any risk of bugzilla going down to zero by May :-)
Re: [WORK] groupBy is in! Next: aggregate
Russel Winder: but is it's name "group by" as understood by the rest of the world? Nope... Bye, bearophile
Re: accept @pure @nothrow @return attributes
On Monday, January 26, 2015 01:54:36 Andrei Alexandrescu via Digitalmars-d wrote: > On 1/26/15 1:50 AM, Brian Schott wrote: > > On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi wrote: > >> If someone is not following the merges, well... [1] !! > >> > >> --- > >> Paolo > >> > >> [1] > >> http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034...@hookshot-fe4-cp1-prd.iad.github.net.mail > >> > > > > I'm running out of ideas for DConf topics. > > Heh, I infer that's a good thing. Nevertheless we should probably > discuss this and its impact; don't forget we can always undo it before > 2.067. Thoughts! -- Andrei In theory, the increased consistency is welcome, but the increased visual noise definitely is not. And if we leave in pure and nothrow without @, then we're going to have code out there doing both, which adds to the confusion, and if we deprecate pure and nothrow without @, then we'll be forced to change pretty much every D program in existence. 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 @. So, most function attributes _don't_ have @ on them, and we just added @ to some of them, making things even _less_ consistent. In fact, priore to this, @safe, @trusted, @system, and @property were the _only_ function attributes with @ on them. So, if we really wanted to improve consistency IMHO, we'd get rid of @ from everything that's built-in and leave it for user-defined attributes, but that would break existing code too. Ultimately, I really don't see this as an improvement, because it really doesn't fix the consistency problem with attributes, and we're either going to have to change existing code or end up with both @pure and pure, and @nothrow and nothrow in the language, which is just ugly. But aside from having duplicate attributes for the same thing, I don't know that it really makes things any worse - though at least before this, we could just say that @property, @safe, @trusted, and @system were oddballs that were added late in the game and that they had @, because we didn't want to add new keywords. With this change, I expect that it will be even less clear which attributes have @ on them and which don't. 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. - Jonathan M Davis
Re: accept @pure @nothrow @return attributes
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
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote: 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 @. So, most function attributes _don't_ have @ on them, and we just added @ to some of them, making things even _less_ consistent. In fact, priore to this, @safe, @trusted, @system, and @property were the _only_ function attributes with @ on them. So, if we really wanted to improve consistency IMHO, we'd get rid of @ from everything that's built-in and leave it for user-defined attributes, but that would break existing code too. - Jonathan M Davis At this point, it might be nicer to have only attributes that exists as C++ keywords not having the @ identifier before them. That is: public, protected, private, override, deprecated, static and const. But this probably doesn't make much sense now, does it?
Re: accept @pure @nothrow @return attributes
+1 On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote: On Monday, January 26, 2015 01:54:36 Andrei Alexandrescu via Digitalmars-d wrote: On 1/26/15 1:50 AM, Brian Schott wrote: > On Monday, 26 January 2015 at 09:29:42 UTC, Paolo Invernizzi > wrote: >> If someone is not following the merges, well... [1] !! >> >> --- >> Paolo >> >> [1] >> http://forum.dlang.org/post/54c5f10ae5161_1b783fd49bfbf2c034...@hookshot-fe4-cp1-prd.iad.github.net.mail >> > > I'm running out of ideas for DConf topics. Heh, I infer that's a good thing. Nevertheless we should probably discuss this and its impact; don't forget we can always undo it before 2.067. Thoughts! -- Andrei In theory, the increased consistency is welcome, but the increased visual noise definitely is not. And if we leave in pure and nothrow without @, then we're going to have code out there doing both, which adds to the confusion, and if we deprecate pure and nothrow without @, then we'll be forced to change pretty much every D program in existence. 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 @. So, most function attributes _don't_ have @ on them, and we just added @ to some of them, making things even _less_ consistent. In fact, priore to this, @safe, @trusted, @system, and @property were the _only_ function attributes with @ on them. So, if we really wanted to improve consistency IMHO, we'd get rid of @ from everything that's built-in and leave it for user-defined attributes, but that would break existing code too. Ultimately, I really don't see this as an improvement, because it really doesn't fix the consistency problem with attributes, and we're either going to have to change existing code or end up with both @pure and pure, and @nothrow and nothrow in the language, which is just ugly. But aside from having duplicate attributes for the same thing, I don't know that it really makes things any worse - though at least before this, we could just say that @property, @safe, @trusted, and @system were oddballs that were added late in the game and that they had @, because we didn't want to add new keywords. With this change, I expect that it will be even less clear which attributes have @ on them and which don't. 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. - Jonathan M Davis
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote: immutable, inout, and deprecated all don't have @. So, most function attributes _don't_ have @ on them, and we just added @ to some of them, making things even _less_ consistent. In fact, priore to this, @safe, @trusted, @system, and @property were the _only_ function attributes with @ on them. So, if we really wanted to improve consistency IMHO, we'd get rid of @ 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 "@" act as some kind of mnemonic and therefore assign meaning to it. One meaning would be to only use "@" 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.
Re: accept @pure @nothrow @return attributes
2015-01-26 21:03 GMT+09:00 bearophile via Digitalmars-d < digitalmars-d@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
Re: accept @pure @nothrow @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@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
Re: std.experimental.logger formal review round 3
Sadly, the issue I have been referring to is actually a DMD bug : https://issues.dlang.org/show_bug.cgi?id=14050 It seems a blocker, at least I can't quickly imagine a workaround for it.
Re: Calypso and the future of D
On Monday, 26 January 2015 at 10:16:04 UTC, Walter Bright wrote: On 1/26/2015 1:58 AM, "Ulrich =?UTF-8?B?S8O8dHRsZXIi?= " wrote: The idea is just brilliant. I for one am excited about the prospect. Lets please discuss how to get the plugin into D, sooner rather than later. No language is an island. (Apologies to Nick Hornby and everyone else offended.) I am pretty excited as well about Calypso and think it can be very effective in making D more usable. Thank you, Elie! The modmap seems a little wonky to me, a pragma(calypso, ...) seems more appropriate. Any chance that we can get a plugin system in dmd that allows us to register pragmas, so that calypso can be used?
Re: accept @pure @nothrow @return attributes
On Monday, January 26, 2015 13:21:54 via Digitalmars-d wrote: > One meaning would be to only use "@" with attributes that do not > affect computation, typing, overloading etc and use it only for > safety-checks and optimization hints (like inlining). All of the existing @ affect the type of the function. It's attributes like public or static which don't, and those still affect aspects of compilation and can easily cause compilation errors. There are not currently any attributes which are simply hints to the compiler, and the ones which affect the safety checks are _definitely_ part of the type of the function. So, I don't think that that particular distinction would work, even if we could freely rearrange which attributes had @ and which didn't. - Jonathan M Davis
Re: accept @pure @nothrow @return attributes
2015-01-27 0:07 GMT+09:00 Jonathan M Davis via Digitalmars-d <
digitalmars-d@puremagic.com>:
> On Monday, January 26, 2015 13:21:54 via Digitalmars-d wrote:
> > One meaning would be to only use "@" with attributes that do not
> > affect computation, typing, overloading etc and use it only for
> > safety-checks and optimization hints (like inlining).
>
> All of the existing @ affect the type of the function. It's attributes like
> public or static which don't, and those still affect aspects of compilation
> and can easily cause compilation errors. There are not currently any
> attributes which are simply hints to the compiler, and the ones which
> affect
> the safety checks are _definitely_ part of the type of the function. So, I
> don't think that that particular distinction would work, even if we could
> freely rearrange which attributes had @ and which didn't.
>
Additional note: UDA can be attached to symbols only.
void foo() @uda {}
// __traits(getAttributes, foo) == (uda)
// pragma(msg, typeof(foo)); prints void(), no @uda
void function() @uda fp;
// Error: user defined attributes cannot appear as postfixes
Kenji Hara
Re: Calypso and the future of D
On Monday, 26 January 2015 at 09:58:25 UTC, Ulrich Küttler wrote: On Monday, 26 January 2015 at 08:59:34 UTC, Walter Bright wrote: On 1/26/2015 12:18 AM, Jacob Carlborg wrote: Calypso is not a separate tool. It's a fork of LDC which allows you to directly import/include a C++ header files and use the declarations from within D. No bindings or intermediate files are necessary. Thank you. That really, really needs to go into the README.md, especially the last paragraph. Now I feel sorry for Elie. He contributed a great idea, put in a huge amount of work, still has miles to go, tried hard to be helpful and D's very own mastermind does not seem to care enough to read his announcement. His very first sentence reads "I have the pleasure to announce to you all the existence of a modified LDC able to interface directly to C++ libraries, wiping out the need to write bindings:" The idea is just brilliant. I for one am excited about the prospect. Lets please discuss how to get the plugin into D, sooner rather than later. No language is an island. (Apologies to Nick Hornby and everyone else offended.) A fast way to kill the language would be to add "great new features" that are not properly documented. Walter's comments were correct IMO. I was not at all clear about those things, but I wasn't going to say so.
Re: std.experimental.logger formal review round 3
On 1/26/15 6:52 AM, Dicebot wrote: Sadly, the issue I have been referring to is actually a DMD bug : https://issues.dlang.org/show_bug.cgi?id=14050 It seems a blocker, at least I can't quickly imagine a workaround for it. Thanks Kenji for the fix! Just merged it. -- Andrei
Re: accept @pure @nothrow @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 @ and which didn't. I personally agree that it would be better to remove "@" 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. The D syntax needs rethinking as a whole, not in bits and pieces. If you are gonna break, make it clean, and make the language easy to learn.
Re: [WORK] groupBy is in! Next: aggregate
On Mon, Jan 26, 2015 at 11:26:04AM +, 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... T -- Don't drink and derive. Alcohol and algebra don't mix.
Re: accept @pure @nothrow @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 '@' 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 '@' 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.
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 16:10:53 UTC, Jonathan Marler wrote: 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 '@' 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 '@' 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. You could do the same as C++ with override and final: they are only valid attributes if they appear _after_ the function/method. Elsewhere they are still valid as identifiers for e.g. variables.
Re: [WORK] groupBy is in! Next: aggregate
On Mon, 2015-01-26 at 08:11 -0800, H. S. Teoh via Digitalmars-d wrote: > On Mon, Jan 26, 2015 at 11:26:04AM +, 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* What name do you think works for this operation? > We still have a short window of time to sort this out, before 2.067 is > released... To be honest, given the confirmation that the semantics of this operation and that of the one other languages call groupBy are different, then 2.067 should not go out with this operation called groupBy. > -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
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 +, 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: Calypso and the future of D
On Monday, 26 January 2015 at 00:37:02 UTC, Walter Bright wrote: Excuse the creator's bias :) I agree that Jacob's description makes things more clear, added!
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.
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: phobos and 64-bit real, anybody testing?
On Monday, 26 January 2015 at 16:49:57 UTC, Dan Olson wrote: 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. I think NEON (SIMD) code will always flush to zero, so IEEE compatibility for denormal numbers prevent using SIMD...?
Re: accept @pure @nothrow @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 @, then we're going to have code out there doing both, which adds to the confusion, and if we deprecate pure and nothrow without @, 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 @. 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 @attribute syntax too. Then it would have more consistency. Also the inverted-attribute option then doesn't need !ugly !sigils - @impure vs @pure, @throw vs @nothrow, etc. In fact, priore to this, @safe, @trusted, @system, and @property were the_only_ function attributes with @ on them. There's also @disable and more recently, @nogc.
Re: accept @pure @nothrow @return attributes
On 26/01/2015 17:07, Nick Treleaven wrote: and inout gained @attribute syntax too Actually inout can apply to local variables, so it shouldn't have a '@' by my logic.
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 +, 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 @pure @nothrow @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 @ is useful when reading function signatures: @property const(T) @pure @nothrow foo(Arg arg, T bar) const ... So @ can actually be signal rather than noise.
Re: phobos and 64-bit real, anybody testing?
On 1/26/15 8:49 AM, Dan Olson wrote: A question for the floating point experts. Do phobos unittests get run on any architectures with 64-bit reals? Would OSX be that? -- Andrei
Re: dlang.org redesign -- the state of documentation and learning resources [part 2]
On Mon, Jan 26, 2015 at 09:48:34AM -0700, David Gileadi via Digitalmars-d wrote: > 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. It shouldn't be too hard. Except it will require some HTTP redirects so that existing incoming links won't unduly break. There has already been PRs for reorganizing the files at the top level of the dlang.org repo. T -- Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce
Re: [WORK] groupBy is in! Next: aggregate
On Monday, 26 January 2015 at 16:44:20 UTC, Ulrich Küttler wrote: 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. Does it return slices? If not, pick a different verb, e.g. "split".
Re: [WORK] groupBy is in! Next: aggregate
On 1/26/15 2:34 PM, Andrei Alexandrescu wrote: On 1/26/15 8:11 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Jan 26, 2015 at 11:26:04AM +, 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 That's much more harder to implement than what it does right now. I don't know how you'll manage to do the lazyValues thing: you'd need to make multiple passes in the range. Again, other languages return an associative array in this case.
Re: [WORK] groupBy is in! Next: aggregate
On 1/26/15 9:50 AM, Ary Borenszweig wrote: On 1/26/15 2:34 PM, Andrei Alexandrescu wrote: On 1/26/15 8:11 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Jan 26, 2015 at 11:26:04AM +, 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 That's much more harder to implement than what it does right now. I don't know how you'll manage to do the lazyValues thing: you'd need to make multiple passes in the range. The implementation right now is quite interesting but not complicated, and achieves lazy grouping in a single pass. Again, other languages return an associative array in this case. I think our approach is superior. Andrei
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 Mon, Jan 26, 2015 at 02:50:16PM -0300, Ary Borenszweig via Digitalmars-d wrote: > On 1/26/15 2:34 PM, Andrei Alexandrescu wrote: > >>On Mon, Jan 26, 2015 at 11:26:04AM +, bearophile via Digitalmars-d > >>wrote: > >>>Russel Winder: > >>> > but is it's name "group by" as understood by the rest of the world? > >>> > >>>Nope... [...] > >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. Huh, what? I think there's some misunderstanding here. The unary version of the current groupBy translates to a binary predicate: groupBy!(a => a.field) is equivalent to: groupBy!((a, b) => a.field == b.field) I don't see how this has anything to do with alternating keys. [...] > That's much more harder to implement than what it does right now. I > don't know how you'll manage to do the lazyValues thing: you'd need to > make multiple passes in the range. > > Again, other languages return an associative array in this case. I think we're talking past each other here. What groupBy currently does is to group elements by evaluating the predicate on *consecutive runs* of elements. What some people seem to demand is a function that groups elements by *global evaluation* of the predicate over all elements. These two are similar but divergent functions, and conflating them is not helping this discussion in any way. If "group by" in other languages refers to the latter function, then that means "groupBy" is poorly-named and we need to come up with a better name for it. Changing it to return tuples and what-not seems to be beating around the bush to me. T -- Computers are like a jungle: they have monitor lizards, rams, mice, c-moss, binary trees... and bugs.
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On Mon, Jan 26, 2015 at 10:09:45AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: > ...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. [...] Certainly, this deserves celebration! But OTOH, if *this* is what it takes to contribute a new module to Phobos, then it's no wonder we have trouble finding contributors... Most would give up before they even try. I think there's an imbalance here between the quality of existing Phobos modules vs. the quality expected of future Phobos modules. Whatever happened to incremental refinement?? Do we really expect flawless perfection before merging to, of all places, std.*experimental*? T -- Fact is stranger than fiction.
Re: [WORK] groupBy is in! Next: aggregate
On 26.01.15 19:05, Andrei Alexandrescu wrote: > On 1/26/15 9:50 AM, Ary Borenszweig wrote: >> On 1/26/15 2:34 PM, Andrei Alexandrescu wrote: >>> On 1/26/15 8:11 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Jan 26, 2015 at 11:26:04AM +, 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 >>> >> >> That's much more harder to implement than what it does right now. I >> don't know how you'll manage to do the lazyValues thing: you'd need to >> make multiple passes in the range. > > The implementation right now is quite interesting but not complicated, > and achieves lazy grouping in a single pass. > >> Again, other languages return an associative array in this case. > > I think our approach is superior. > > > Andrei I think std.experimental.algorithm.groupBy is one option. To postpone thing.
Re: [WORK] groupBy is in! Next: aggregate
I also found the behaviour confusing given the name. I like ChunkBy.
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
thank you @!"In order of appearance on github"() { Dicebot,
JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh, Geod24,
andralex, braddr, AndrejMitrovic, MetaLang, p0nce, yglukhov,
elendel-, sigod, sybrandy, DmitryOlshansky, SerialVelocity,
drasha, klickverbot, MartinNowak, jacob-carlborg, 9il, quickfur,
deadalnix, MrSmith33, 9rnsr }
and anyone I forgot
thank you very very much
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On 1/26/15 10:17 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Jan 26, 2015 at 10:09:45AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: ...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. [...] Certainly, this deserves celebration! But OTOH, if *this* is what it takes to contribute a new module to Phobos, then it's no wonder we have trouble finding contributors... Most would give up before they even try. I think there's an imbalance here between the quality of existing Phobos modules vs. the quality expected of future Phobos modules. Whatever happened to incremental refinement?? Do we really expect flawless perfection before merging to, of all places, std.*experimental*? For a good while there was no std.experimental. Its introduction was partially motivated by the stalemate of this contribution. -- Andrei
Re: [WORK] groupBy is in! Next: aggregate
On 1/26/15 10:11 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Jan 26, 2015 at 02:50:16PM -0300, Ary Borenszweig via Digitalmars-d wrote: On 1/26/15 2:34 PM, Andrei Alexandrescu wrote: On Mon, Jan 26, 2015 at 11:26:04AM +, bearophile via Digitalmars-d wrote: Russel Winder: but is it's name "group by" as understood by the rest of the world? Nope... [...] 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. Huh, what? I think there's some misunderstanding here. The unary version of the current groupBy translates to a binary predicate: groupBy!(a => a.field) is equivalent to: groupBy!((a, b) => a.field == b.field) I don't see how this has anything to do with alternating keys. Here's how. Basically the binary-predicate version has only Boolean keys that may be false or true. They will alternate because it's the change that triggers creation of a new group. In this example: [293, 453, 600, 929, 339, 812, 222, 680, 529, 768] .groupBy!((a, b) => (a & 3) == (b & 3)) the groupBy function has no information about the result of a & 3. All it "sees" is the result of the predicate: true, false, true, false... HOWEVER, if you write it like this: [293, 453, 600, 929, 339, 812, 222, 680, 529, 768] .groupBy!(a => (a & 3)) then groupBy sees the actual value of the function and can emit the proper key. So the key (ahem) here is to make groupBy with unary predicate different from groupBy with binary predicate. The former returns the tuple, the latter is unchanged. Makes sense? [...] That's much more harder to implement than what it does right now. I don't know how you'll manage to do the lazyValues thing: you'd need to make multiple passes in the range. Again, other languages return an associative array in this case. I think we're talking past each other here. What groupBy currently does is to group elements by evaluating the predicate on *consecutive runs* of elements. What some people seem to demand is a function that groups elements by *global evaluation* of the predicate over all elements. These two are similar but divergent functions, and conflating them is not helping this discussion in any way. Agreed. If "group by" in other languages refers to the latter function, then that means "groupBy" is poorly-named and we need to come up with a better name for it. Changing it to return tuples and what-not seems to be beating around the bush to me. I like our notion of groupBy the same way I like the notion that something must be a random-access range in order to be sorted. (Other languages give the illusion they sort streams by internally converting them to arrays.) D offers better control, better flexibility, and richer semantics. Andrei
Re: defunct / stale forums on front page
On Monday, 26 January 2015 at 03:56:37 UTC, Vladimir Panteleev wrote: Hi. This thread turned to topics of higher importance than mere cosmetics. Few miscellaneous thoughts. Why not create a bugzilla section for website and forum so it is easier to report glitches and enhancement requests in a way that you will quickly see without distraction? (Andralex posted to general D section in bugzilla, but was black holed till this thread came up). Secondly, I was browsing old forum messages and got this error. I am amazed by the lean elegant power of dfeed source code - coming from C, I keep wondering where the rest of it is - but maybe as D matures it is worth the trouble to beautify reports like the following. (It should say something like "Sorry - that message has been deleted. Click here to go back to the previous screen). I thought of making a pull, but I am guessing however I write it at my level of experience will not fit with the gestalt of how you would do things. Let me know of I am wrong, and will do so next time if I get the chance. Incidentally, although it is common sense for experienced programmers, how about linking in the learning D section to suggest that people review the following showcase D projects to learn idiomatic D? Later, someone with the inclination could add some commentary. P0nce and others are doing a great job setting out small idiomatic D snippets, but we could do more on explaining how to write larger patterns. http://forum.dlang.org/post/nchvayzsbrzevvucmmmi Post not found web.NotFoundException@web.d(2502): Post not found /home/dfeed/DFeed/dfeed(ae.net.http.common.HttpResponse web.WebUI.handleRequest(ae.net.http.common.HttpRequest, ae.net.http.server.HttpServerConnection)+0x1eb0) [0x6c4e28] /home/dfeed/DFeed/dfeed(void web.WebUI.onRequest(ae.net.http.common.HttpRequest, ae.net.http.server.HttpServerConnection)+0x71) [0x6c29e1] /home/dfeed/DFeed/dfeed(void ae.net.http.server.HttpServerConnection.processRequest(ae.sys.data.Data[])+0x72) [0x6e759a] /home/dfeed/DFeed/dfeed(void ae.net.http.server.HttpServerConnection.onNewRequest(ae.sys.data.Data)+0x36a) [0x6e72ca] /home/dfeed/DFeed/dfeed(void ae.net.asockets.ConnectionAdapter.onReadData(ae.sys.data.Data)+0x8d) [0x6e495d] /home/dfeed/DFeed/dfeed(void ae.net.asockets.TimeoutAdapter.onReadData(ae.sys.data.Data)+0x8f) [0x6e55c7] /home/dfeed/DFeed/dfeed(void ae.net.asockets.TcpConnection.onReadable()+0x232) [0x6e2a2a] /home/dfeed/DFeed/dfeed(void ae.net.asockets.SocketManager.handleEvent(std.socket.SocketSet, std.socket.SocketSet, std.socket.SocketSet)+0xd8) [0x6e1c58] /home/dfeed/DFeed/dfeed(void ae.net.asockets.SocketManager.loop()+0x52a) [0x6e1ad2] /home/dfeed/DFeed/dfeed(_Dmain+0x219) [0x634f79] /home/dfeed/DFeed/dfeed(_D2rt6dmain211_d_run_mainUiPPaPUAAaZiZ6runAllMFZ9__lambda1MFZv+0x25) [0x771e99] /home/dfeed/DFeed/dfeed(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x60) [0x771dfc] /home/dfeed/DFeed/dfeed(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x36) [0x771e42] /home/dfeed/DFeed/dfeed(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x60) [0x771dfc] /home/dfeed/DFeed/dfeed(_d_run_main+0x22a) [0x771d46] /home/dfeed/DFeed/dfeed(main+0x25) [0x6b2a15] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x3a974320ec5] Thirdly: I get the sense that the search features in the old digitalmars web front end are slightly more powerful than at dlang.org. And it is easier to browse by year etc. Could we add to list to match them / provide the standard set of features that google groups offers ? Laeeth
Re: defunct / stale forums on front page
On Monday, 26 January 2015 at 09:08:26 UTC, Jacob Carlborg wrote: On 2015-01-26 08:35, H. S. Teoh via Digitalmars-d wrote: I think we should just import jquery into the dlang.org repo. External dependencies always end up in these kinds of ugly situations. The advantage of using a CDN is that browser will most likely already have loaded, in this case jQuery, from another page you already have visited. Two thoughts. 1. You could have a special handling for China and other countries that ban google. 2. See here: http://stackoverflow.com/questions/1014203/best-way-to-use-googles-hosted-jquery-but-fall-back-to-my-hosted-library-on-go
Re: One area where D has the edge
On Sunday, 25 January 2015 at 21:50:53 UTC, Laeeth Isharc wrote: And beyond slower execution speed of Java, the memory bloat makes a big difference given how cloud pricing works (its peanuts to get a machine with a gig of ram, but 64 gig is not so cheap, and quickly gets very expensive - and one may need hundreds of machines). Yes, but memory bloat is not D's strength either until manual memory management is addressed in a satisfactory manner. Rust is way ahead.
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On Monday, 26 January 2015 at 18:25:13 UTC, Robert burner Schadek
wrote:
thank you @!"In order of appearance on github"() { Dicebot,
JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh,
Geod24, andralex, braddr, AndrejMitrovic, MetaLang, p0nce,
yglukhov, elendel-, sigod, sybrandy, DmitryOlshansky,
SerialVelocity, drasha, klickverbot, MartinNowak,
jacob-carlborg, 9il, quickfur, deadalnix, MrSmith33, 9rnsr }
and anyone I forgot
thank you very very much
Thanks to you for your contributions !
It takes a lot of patience and motivation to go through this
process for so long. I'm pretty sure you paved the way for better
/ faster (stronger?) review :)
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 11:39:23 UTC, Jonathan M Davis wrote: 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. - Jonathan M Davis I don't think this problem is solvable without "dfix". Here are the factors I would consider: 1. `@` is ugly. Therefore it would be great to make `safe`, `trusted`, `system`, and `nogc` full-fledged keywords, to spare future readers of code all those `@`s. So long as it's definitely a permanent feature of the language, it should look as good as possible. (`property` too, if we're sure it's not leaving). `@` is then left exclusively for UDAs, an improvement, IMO. 2. Consistency of attribute usage is important. All built-in attributes should be markable in the same way, either with, or without an `@` sign. 3. Singularity of usage also matters. There should only be one way to mark a given attribute, either with or without `@`. 4. Old code matters. Existing code puts points 2 and 3 into conflict. Now it goes without saying that changing old code is a nuisance. But it's important to point out that not all code changes are the same. In the interest of furthering this discussion, here is a list of the types of breaking changes, in my order of least to most desirable: B1. Silent breaking changes. Same code now does different things. Rightly regarded as the worst kind. You don't even know what hit you. B2. Completely pointless changes. For the record, I'm against changes which literally have no benefit. Most changes which get seriously discussed, however, involve difficult tradeoffs, for which the assumed benefit must outweigh the perceived loss, plus the "switching costs". The point of this list is to emphasize that not all switching costs are the same, and that they depend greatly on the *individual* change. B3. Breaking changes which require significant redesign of code. Sociomantic faces this issue with their move to D2. B4. Changes which can easily be fixed, with the right know-how. Great error messages, referring the user to the documentation of these changes and how to fix them, is essential. B5. The kind that a tool such as 'dfix', can automate. For example, let's say dfix is included with the compiler package. Now you get an error, saying: "Error: `@nogc` is no longer accepted, but can be automatically replaced with `nogc`. Run dfix on this file? (y/n)"... or whatever is deemed the secure approach to this feature. B6. Changes which catch existing bugs, with no false positives. Obviously wins. The changes suggested in this thread are of kind 5.5. But more people would have to get behind the whole 'dfix' approach for it to work. "Most D code is yet to be written. #PleaseBreakOurCode." +1
extern(C) symbol conflicts
An interesting thing I learned while reading through some bug reports [1]:
cfile.c
#include
void cfunction() {printf("hello\n");}
file1.d
module file1;
extern(C) void cfunction();
file2.d
module file2;
extern(C) void cfunction();
main.d
version(test1)
{
import file1;
}
version(test2)
{
import file2;
}
void main()
{
cfunction();
}
cc -c cfile.c
dmd -version=test1 main.d file1.d file2.d cfile.o
./main
hello
dmd -version=test2 main.d file1.d file2.d cfile.o
./main
hello
All fine and good. Now:
dmd -version=test1 -version=test2 main.d file1.d file2.d cfile.o
main.d(12): Error: file2.cfunction at file2.d(2) conflicts with
file1.cfunction at file1.d(2)
What gives here? cfunction is not part of any module, it's extern(C). In
fact, both equate to the same symbol (as shown by the different ways we
can import with only one implementation). But D considers them
different. Why?
I would have expected that any time you declare (but don't define) an
extern(C) symbol, it's just like a prototype -- if it's already declared
no big deal. But it shouldn't be module-based.
Is there a good reason why we shouldn't allow the duplicate declaration
in multiple modules? I understand for D symbols -- those are actually
different symbols.
This is actually a problem someone may encounter quite a bit -- 2
different libraries or even modules from the same library (see
referenced bug) may create their own bindings to C functions. I would
say, let's just let the linker figure it out, no?
-Steve
[1] https://issues.dlang.org/show_bug.cgi?id=7729
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 19:02:27 UTC, Zach the Mystic wrote: The changes suggested in this thread are of kind 5.5. s/5.5/B5
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On Monday, 26 January 2015 at 18:25:13 UTC, Robert burner Schadek
wrote:
thank you @!"In order of appearance on github"() { Dicebot,
JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh,
Geod24, andralex, braddr, AndrejMitrovic, MetaLang, p0nce,
yglukhov, elendel-, sigod, sybrandy, DmitryOlshansky,
SerialVelocity, drasha, klickverbot, MartinNowak,
jacob-carlborg, 9il, quickfur, deadalnix, MrSmith33, 9rnsr }
and anyone I forgot
thank you very very much
Thank you for having the fortitude to carry this through.
Re: Calypso and the future of D
On Monday, 26 January 2015 at 16:40:38 UTC, Elie Morisse wrote: On Monday, 26 January 2015 at 00:37:02 UTC, Walter Bright wrote: Excuse the creator's bias :) I agree that Jacob's description makes things more clear, added! I posted some thoughts on web docs writeup of C+= interface here. http://forum.dlang.org/thread/fmjehcyzhnirybmnj...@forum.dlang.org#post-fmjehcyzhnirybmnjloj:40forum.dlang.org Do you think we could make binaries of calypso available for download ? I know it is alpha, but it is so strategically important, and just getting clang to build is not always so easy given the stuff in gcc 4.9 with size__align_t ? We should mention calypso in the web docs, and link to it too (with appropriate caveats).
Re: accept @pure @nothrow @return attributes
On 1/26/2015 8:13 AM, Foo wrote: You could do the same as C++ with override and final: they are only valid attributes if they appear _after_ the function/method. Elsewhere they are still valid as identifiers for e.g. variables. Just 'no' on context-sensitive tokens. For context, TV vocabulary - 2,000 words High school vocabulary - 10,000 words College vocabulary - 30,000 words English - 1,000,000 words i.e. words are NOT a scarce resource (quite unlike punctuation).
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 19:44:18 UTC, Walter Bright wrote: On 1/26/2015 8:13 AM, Foo wrote: You could do the same as C++ with override and final: they are only valid attributes if they appear _after_ the function/method. Elsewhere they are still valid as identifiers for e.g. variables. Just 'no' on context-sensitive tokens. For context, TV vocabulary - 2,000 words High school vocabulary - 10,000 words College vocabulary - 30,000 words English - 1,000,000 words i.e. words are NOT a scarce resource (quite unlike punctuation). Some words are in high demand, however, like body and match.
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On Mon, Jan 26, 2015 at 10:33:32AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: > On 1/26/15 10:17 AM, H. S. Teoh via Digitalmars-d wrote: [...] > >But OTOH, if *this* is what it takes to contribute a new module to > >Phobos, then it's no wonder we have trouble finding contributors... > >Most would give up before they even try. I think there's an imbalance > >here between the quality of existing Phobos modules vs. the quality > >expected of future Phobos modules. Whatever happened to incremental > >refinement?? Do we really expect flawless perfection before merging > >to, of all places, std.*experimental*? > > For a good while there was no std.experimental. Its introduction was > partially motivated by the stalemate of this contribution. -- Andrei And yet it still took so long to get it in? IMO a better approach would have been, merge it into std.experimental sooner, then submit followup PRs to std.experimental when the implementation is found to be inferior. We already officially don't guarantee non-breakage in std.experimental anyway, so we're not constrained by release schedule or anything like that. Plus, this way it's easier for other contributors to chime in to the implementation (I know you can submit PRs against other PRs, but not many people know that or have the patience to do that). Once we've bashed it into shape in std.experimental to everyone's satisfaction, we can move it into std proper. If it takes just as much effort to get it into std.experimental as it would take to get into std directly, I don't see the point of the additional hassle introduced by std.experimental. T -- Acid falls with the rain; with love comes the pain.
Re: accept @pure @nothrow @return attributes
On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:
Personally, I'd much prefer that we not make this change.
It's good to have this discussion.
Previously, it's all been advocacy and "break my code" by forcing a change from
pure => @pure.
Just a few days ago on slashdot, an anonymous D user wrote:
"A horrible mix of keywords and annotation syntax for function/method
attributes ('const', 'pure', and 'nothrow' are all keywords, but
'@property', and '@nogc' are annotations)"
for why he won't use D anymore.
Frankly, I think that is a great bikeshedding non-issue that distracts us from
what is important. I hope that by doing this PR, we can actually decide that it
isn't worth it, i.e. I'd be happy to get consensus and revert it.
Re: accept @pure @nothrow @return attributes
On Mon, Jan 26, 2015 at 11:50:19AM -0800, Walter Bright via Digitalmars-d wrote:
> On 1/26/2015 3:39 AM, Jonathan M Davis via Digitalmars-d wrote:
> >Personally, I'd much prefer that we not make this change.
>
> It's good to have this discussion.
>
> Previously, it's all been advocacy and "break my code" by forcing a
> change from pure => @pure.
>
> Just a few days ago on slashdot, an anonymous D user wrote:
>
> "A horrible mix of keywords and annotation syntax for
> function/method attributes ('const', 'pure', and 'nothrow' are all
> keywords, but '@property', and '@nogc' are annotations)"
>
> for why he won't use D anymore.
>
> Frankly, I think that is a great bikeshedding non-issue that distracts
> us from what is important. I hope that by doing this PR, we can
> actually decide that it isn't worth it, i.e. I'd be happy to get
> consensus and revert it.
While I generally agree with the sentiment that this great debate over
syntax is distracting from more important issues, one particularly
attractive point about forcing @ on annotations is that const (as a type
qualified) and @const (as a function annotation) become syntactically
distinct:
const int myFunc() @const {}
vs. the current confusing syntax:
const int myFunc() const {}
Does this alone make it worth it? I'm skeptical. But I thought it should
be pointed out regardless.
T
--
If it tastes good, it's probably bad for you.
Pandas example of groupby
If "group by" in other languages refers to the latter function, then that means "groupBy" is poorly-named and we need to come up with a better name for it. Changing it to return tuples and what-not seems to be beating around the bush to me. T T: you are good with algorithms. In many applications you have a bunch of results and want to summarise them. This is often what the corporate manager is doing with Excel pivot tables, and it is what the groupby function is used for in pandas. See here for a simple tutorial. http://wesmckinney.com/blog/?p=125 And here for a summary of what pandas can do with data: http://pandas.pydata.org/pandas-docs/stable/generated/pandas.DataFrame.median.html Is there any reason why we shouldn't add to Phobos: median, ranking, stddev, variance, correlation, covariance, skew, kurtosis, quantile, moving average, exp mov average, rolling window (see pandas)? I personally am fine with the implementation we have (although as Ray Dalio would say. I haven't yet earned the right that you should care what I think). All that it means is that you need to sort on multi key your results first before passing to groupby. My question is how much is lost by doing it in two steps (sort, groupby) rather than one. I don't think all that much, but it is not my field, I am also not that bothered, because this comes at the end of processing, not within the inner loop, so for me I don't think it makes a difference for now. If data sets reach commoncrawl type sizes then it might be different, although I will take D over java any day, warts and all. In any case, the documentation should be very clear on what groupby does, and how the user can do what he might be expecting to achieve, coming from a different framework. It would be interesting to benchmark D against pandas (which is implemented in cython for the key bits) and see how we look.
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On Mon, 26 Jan 2015 18:25:11 +, Robert burner Schadek wrote: congrats! signature.asc Description: PGP signature
Re: phobos and 64-bit real, anybody testing?
Am Mon, 26 Jan 2015 08:49:56 -0800 schrieb Dan Olson : > 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 I run the tests for GDC on ARM/linux soft and hardfloat 64 bit. All modules except gammafunction should pass. gammafunction was never ported to 64bit reals and I asked about it multiple times on the newsgroup but nobody cared. I also filed a bug report: https://issues.dlang.org/show_bug.cgi?id=13032 So as far as I'm concerned gammafunction is unmaintained and broken :-( However, other modules should work (at least with GDC as there's some GDC-specific inline asm).
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On Monday, 26 January 2015 at 18:25:13 UTC, Robert burner Schadek
wrote:
thank you @!"In order of appearance on github"() { Dicebot,
JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh,
Geod24, andralex, braddr, AndrejMitrovic, MetaLang, p0nce,
yglukhov, elendel-, sigod, sybrandy, DmitryOlshansky,
SerialVelocity, drasha, klickverbot, MartinNowak,
jacob-carlborg, 9il, quickfur, deadalnix, MrSmith33, 9rnsr }
and anyone I forgot
thank you very very much
and of course mleise, sry I forgot you
Re: accept @pure @nothrow @return attributes
On Mon, 26 Jan 2015 19:46:21 +, Meta wrote: > On Monday, 26 January 2015 at 19:44:18 UTC, Walter Bright wrote: >> On 1/26/2015 8:13 AM, Foo wrote: >>> You could do the same as C++ with override and final: they are only >>> valid attributes if they appear _after_ the function/method. Elsewhere >>> they are still valid as identifiers for e.g. variables. >> >> Just 'no' on context-sensitive tokens. >> >> For context, >> >> TV vocabulary - 2,000 words High school vocabulary - 10,000 words >> College vocabulary - 30,000 words English - 1,000,000 words >> >> i.e. words are NOT a scarce resource (quite unlike punctuation). > > Some words are in high demand, however, like body and match. body will not be "dekeyworded". Walter Bright 2014-02-12 14:44:20 UTC In hindsight, the choice of 'body' for the keyword is unfortunate. But fixing it would cause even worse problems, so I think we're stuck with it. nobody told us what "worse problems" are. using "body" is not confusing, lowering it into identifier will not break any code, but... "worse problems" awaits. i'm using patch that allows "body" as identifier for almost a year, i'm constantly building alot of projects from dub repo, and i haven't encountered any problems with it. but i believe that i'm simply doing something wrong and dragons are around the corner. signature.asc Description: PGP signature
Re: defunct / stale forums on front page
On Monday, 26 January 2015 at 18:41:09 UTC, Laeeth Isharc wrote: Why not create a bugzilla section for website and forum so it is easier to report glitches and enhancement requests in a way that you will quickly see without distraction? Bugzilla has a "Website" component. It should say something like "Sorry - that message has been deleted. That link doesn't look valid. A Message-ID should have an @ character. http://forum.dlang.org/post/nchvayzsbrzevvucmmmi You are probably looking for: http://forum.dlang.org/post/nchvayzsbrzevvucm...@forum.dlang.org web.NotFoundException@web.d(2502): Post not found This is due to temporarily building DFeed in debug mode, to diagnose a bug. Fixed now.
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On Monday, 26 January 2015 at 19:50:39 UTC, H. S. Teoh wrote: On Mon, Jan 26, 2015 at 10:33:32AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 1/26/15 10:17 AM, H. S. Teoh via Digitalmars-d wrote: [...] >But OTOH, if *this* is what it takes to contribute a new >module to >Phobos, then it's no wonder we have trouble finding >contributors... >Most would give up before they even try. I think there's an >imbalance >here between the quality of existing Phobos modules vs. the >quality >expected of future Phobos modules. Whatever happened to >incremental >refinement?? Do we really expect flawless perfection before >merging >to, of all places, std.*experimental*? For a good while there was no std.experimental. Its introduction was partially motivated by the stalemate of this contribution. -- Andrei And yet it still took so long to get it in? IMO a better approach would have been, merge it into std.experimental sooner, then submit followup PRs to std.experimental when the implementation is found to be inferior. We already officially don't guarantee non-breakage in std.experimental anyway, so we're not constrained by release schedule or anything like that. Plus, this way it's easier for other contributors to chime in to the implementation (I know you can submit PRs against other PRs, but not many people know that or have the patience to do that). Once we've bashed it into shape in std.experimental to everyone's satisfaction, we can move it into std proper. If it takes just as much effort to get it into std.experimental as it would take to get into std directly, I don't see the point of the additional hassle introduced by std.experimental. T I don't claim expertise on library development, but isn't it the norm that the bar is raised for quality as a platform matures. Because complexity increases much more than linearly with time, and also as one learns from earlier mistakes and missteps. If it is not easy to get a contribution in, that raises the satisfaction of having it eventually accepted. People like having a high bar to meet, even if that's not the way of the modern world. And D's orientation towards excellence is one of the things I personally find most appealing. Maybe it is worth writing up some lessons learned from the discussion on github and pointers for future contributors.
Re: defunct / stale forums on front page
On Monday, 26 January 2015 at 18:46:58 UTC, Laeeth Isharc wrote: On Monday, 26 January 2015 at 09:08:26 UTC, Jacob Carlborg wrote: On 2015-01-26 08:35, H. S. Teoh via Digitalmars-d wrote: I think we should just import jquery into the dlang.org repo. External dependencies always end up in these kinds of ugly situations. The advantage of using a CDN is that browser will most likely already have loaded, in this case jQuery, from another page you already have visited. Two thoughts. 1. You could have a special handling for China and other countries that ban google. 2. See here: http://stackoverflow.com/questions/1014203/best-way-to-use-googles-hosted-jquery-but-fall-back-to-my-hosted-library-on-go https://github.com/D-Programming-Language/dlang.org/pull/847
Re: One area where D has the edge
On Monday, 26 January 2015 at 18:53:45 UTC, Ola Fosheim Grøstad wrote: On Sunday, 25 January 2015 at 21:50:53 UTC, Laeeth Isharc wrote: And beyond slower execution speed of Java, the memory bloat makes a big difference given how cloud pricing works (its peanuts to get a machine with a gig of ram, but 64 gig is not so cheap, and quickly gets very expensive - and one may need hundreds of machines). Yes, but memory bloat is not D's strength either until manual memory management is addressed in a satisfactory manner. Rust is way ahead. It seems to me (as a newcomer) that often with D it is the gap between what the language wants to be, and the present reality that upsets people, whereas pragmatically it remains much better than the alternatives even if you have to do a bit of extra work to allocate manually. It is like seeing a beautiful woman marred by a flaw that you just can't seem to ignore until you get to know her as a person. (No apologies for sexism here). The problems of garbage collection in D seem different to those of GC (and memory bloat) in Java whereas people hear GC and not quite perfect and they instantly slot it into their mental slot of GC collected languages, which means Java. Does Rust have the productivity of D? And it doesn't have the maturity, as I understand it.
Re: phobos and 64-bit real, anybody testing?
On Monday, 26 January 2015 at 17:36:05 UTC, Andrei Alexandrescu wrote: On 1/26/15 8:49 AM, Dan Olson wrote: A question for the floating point experts. Do phobos unittests get run on any architectures with 64-bit reals? Would OSX be that? -- Andrei It is mostly x86 80-bit reals these days.
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On 1/26/15 11:48 AM, H. S. Teoh via Digitalmars-d wrote: On Mon, Jan 26, 2015 at 10:33:32AM -0800, Andrei Alexandrescu via Digitalmars-d wrote: On 1/26/15 10:17 AM, H. S. Teoh via Digitalmars-d wrote: [...] But OTOH, if *this* is what it takes to contribute a new module to Phobos, then it's no wonder we have trouble finding contributors... Most would give up before they even try. I think there's an imbalance here between the quality of existing Phobos modules vs. the quality expected of future Phobos modules. Whatever happened to incremental refinement?? Do we really expect flawless perfection before merging to, of all places, std.*experimental*? For a good while there was no std.experimental. Its introduction was partially motivated by the stalemate of this contribution. -- Andrei And yet it still took so long to get it in? IMO a better approach would have been, merge it into std.experimental sooner, then submit followup PRs to std.experimental when the implementation is found to be inferior. Of course. I repeat: for a long time std.experimental was not an option. Clearly it's better with it than without, and merging into std.experimental first, std later, will be the way we roll. -- Andrei
Re: accept @pure @nothrow @return attributes
It was sad that calls for more breakage were mostly ignored. But there is one thing now that is even worse - referring to #pleasebreakmycode as an excuse to introduce random changes based on random reddit comment - and completely dismissing everything that was said on topic initially. Resulting in exactly the opposite action that was asked to. Please, revert this PR asap. After that it can possibly be introduced after meeting necessary prerequisites: 1) explanation of problem it fixes 2) design rationale for new model 3) evaluation of ROI 4) tools for simple migration - either as part of dfix or compiler This is absolutely mandatory list for any change of language fundamentals to be considered legitimate.
Shouldn't dfix be made a friend of the compiler?
"5. The kind that a tool such as 'dfix', can automate. For example, let's say dfix is included with the compiler package. Now you get an error, saying: "Error: `@nogc` is no longer accepted, but can be automatically replaced with `nogc`. Run dfix on this file? (y/n)"... or whatever is deemed the secure approach to this feature. " Sorry for the tangent (I have no view on the major topic), +1 for including a link to dfix within the compiler. Repetitive things ought to be automated and made easy and how many times does one end up fixing up old code ?
Re: Pandas example of groupby
On Mon, Jan 26, 2015 at 07:59:10PM +, Laeeth Isharc via Digitalmars-d wrote: [...] > My question is how much is lost by doing it in two steps (sort, > groupby) rather than one. [...] I'm not sure I understand what you mean by "lost"... I assume you're not talking about data loss, since that's not applicable either way. In any case, as with all things, there's a tradeoff. Building a hash table of groups, as some people demand, has the advantage that the grouping predicate is applied globally, and no sorting (O(n log n)) is needed. The disadvantage is that the entire data set has to fit in memory, and you cannot process it lazily. Before you've seen all of the data, you cannot know whether there are more distinct groups to come, or whether currently known groups have more members. Once the data size gets too large, you run into trouble. Plus, some people are adverse to gratuitous GC use in Phobos algorithms. Perhaps some of this is misplaced, but that's the perception. The current implementation has the advantage that it requires very little memory to work, and can process data lazily. It only needs to see a tiny portion of the entire data set to do its work. Each group returned is also lazy, so it doesn't need to store the whole group in its entirety. It can handle 10GB long groups in a 100GB data set streamed over the network with very little memory, whereas such a monstrous thing would be infeasibly resource-hungry if you need to allocate an on-disk hashtable (very inefficient!), iterate over the entire dataset, and then be I/O bound as you iterate over each group loading group members from disk. The big disadvantage, however, is that if your data is not sorted, then the groupings returned won't be quite what you'd expect, since the predicate is evaluated only over consecutive runs of elements, not globally over the entire data set. Which one is better? That depends on your specific application and its needs. For some applications, there is simply no way around the fact that you have a large dataset with randomly-ordered elements, so the sorting has to be done *somewhere*. For other applications, you *can* make stream your data in sorted order -- or perhaps it doesn't care if groupings aren't global -- so you can take advantage of the fact that the current groupBy is extremely cheap. It requires minimal memory to do its work, and it can do so inside a pipeline without requiring anything more than an input range. Basically, std.algorithm is (currently) primarily focused on linear algorithms. While there *are* some sorting algorithms and sublinear algorithms that take advantage of sorted data, it is still primarily focused on linear processing. There is no good abstraction as yet for more complex processing like multidimensional or graph traversals. As a result, it is best suited for stream-based processing. Generally speaking, most application code is primarily concerned with linear processing (copy this text from here to there, scan this text for some linear string AKA search keyword, render this line of text to the screen, draw this line around the window, move this item along in the processing queue, etc.). Non-linear computations generally take place only in dedicated computing modules of limited scope in the application, where one tends to write dedicated algorithms rather than reuse stock generic algorithms. > In any case, the documentation should be very clear on what groupby > does, and how the user can do what he might be expecting to achieve, > coming from a different framework. [...] As far as I know, the current groupBy docs explain quite clearly what it does. If you find it still inadequate or unclear, please file bugs against it so that we can look into improving the docs. T -- GEEK = Gatherer of Extremely Enlightening Knowledge
Re: phobos and 64-bit real, anybody testing?
On Monday, 26 January 2015 at 20:04:46 UTC, Johannes Pfau wrote: I run the tests for GDC on ARM/linux soft and hardfloat 64 bit. All modules except gammafunction should pass. gammafunction was never ported to 64bit reals and I asked about it multiple times on the newsgroup but nobody cared. I also filed a bug report: https://issues.dlang.org/show_bug.cgi?id=13032 So as far as I'm concerned gammafunction is unmaintained and broken :-( However, other modules should work (at least with GDC as there's some GDC-specific inline asm). Thanks! This info helps much.
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 19:44:18 UTC, Walter Bright wrote:
On 1/26/2015 8:13 AM, Foo wrote:
You could do the same as C++ with override and final: they are
only valid
attributes if they appear _after_ the function/method.
Elsewhere they are still
valid as identifiers for e.g. variables.
Just 'no' on context-sensitive tokens.
For context,
TV vocabulary - 2,000 words
High school vocabulary - 10,000 words
College vocabulary - 30,000 words
English - 1,000,000 words
i.e. words are NOT a scarce resource (quite unlike punctuation).
I'm not sure what you mean by "context-sensitive tokens". It
sounds like you might be saying that this requires the tokenizer
to be context sensitive, but this isn't the case. Instead,
allowing a function to be decorated with any number of "id" or
"keyword" tokens would allow the language to add new attributes
(without a '@' character) by restricting the usage of attributes
in the semantics instead of the syntax.
void myfunc() foo bar safe nogc nothrow {
}
'foo' and 'bar' don't break the syntax but are caught by the
semantic analysis.
Furthermore, I'm sure this type of thing is already done all over
the place in the grammar. The following example comes to mind:
struct St { }
void main()
{
St St;
}
The "St" token is a decl type the first time and a variable name
the second. I'm sure they are implemented as the same token but
the grammar results in a different semantic meaning for both
tokens.
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
We couldn't merge it into std.experimental before because you have stated that even std.experimental modules shouldn't have a breaking changes normally. It was 2 reviews ago. Now you have reconsidered, which is understandable considering how long has it been taking, but pretending that was intended to work that way does not make you look good :( PS I was in favor for very lax initial requirements for experimental packages for this very reason.
Re: accept @pure @nothrow @return attributes
On 1/26/2015 12:34 PM, Jonathan Marler wrote: I'm not sure what you mean by "context-sensitive tokens". A keyword in one context and an identifier in another.
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On 1/26/15 12:30 PM, Dicebot wrote: We couldn't merge it into std.experimental before because you have stated that even std.experimental modules shouldn't have a breaking changes normally. It was 2 reviews ago. Now you have reconsidered, which is understandable considering how long has it been taking, but pretending that was intended to work that way does not make you look good :( PS I was in favor for very lax initial requirements for experimental packages for this very reason. Now I remember. I admit I was wrong. -- Andrei
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On Mon, Jan 26, 2015 at 08:30:58PM +, Dicebot via Digitalmars-d wrote: > We couldn't merge it into std.experimental before because you have > stated that even std.experimental modules shouldn't have a breaking > changes normally. It was 2 reviews ago. Yeah, this part didn't make much sense to me. While I agree that we shouldn't be accepting random junk into std.experimental, the bar shouldn't be set so high that legitimate initial revisions of a new module are also excluded. Otherwise, what's the point of even having std.experimental as opposed to merging straight into std? > Now you have reconsidered, which is understandable considering how > long has it been taking, but pretending that was intended to work that > way does not make you look good :( > > PS I was in favor for very lax initial requirements for experimental > packages for this very reason. +1. And we should not forget that if something in std.experimental continues to disappoint, there's always the option of dropping it altogether, since we don't guarantee non-breakage on std.experimental. So there's no reason the bar should be as high as it is right now. T -- They pretend to pay us, and we pretend to work. -- Russian saying
Re: accept @pure @nothrow @return attributes
On Monday, 26 January 2015 at 20:38:43 UTC, Walter Bright wrote: On 1/26/2015 12:34 PM, Jonathan Marler wrote: I'm not sure what you mean by "context-sensitive tokens". A keyword in one context and an identifier in another. Then I'm a little confused. What does this have to do with adding new attributes to a function? Just because a word is used as a function attribute doesn't mean it has to be a keyword. If the grammar supported decorating a function with a list of id tokens (not just keywords), then you could implement a variation on the c++ solution of allowing "override" and "final" after a function signature. Just because they are function attributes does not mean they were tokenized as "keywords".
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On Monday, 26 January 2015 at 20:35:31 UTC, Andrei Alexandrescu wrote: On 1/26/15 12:30 PM, Dicebot wrote: We couldn't merge it into std.experimental before because you have stated that even std.experimental modules shouldn't have a breaking changes normally. It was 2 reviews ago. Now you have reconsidered, which is understandable considering how long has it been taking, but pretending that was intended to work that way does not make you look good :( PS I was in favor for very lax initial requirements for experimental packages for this very reason. Now I remember. I admit I was wrong. -- Andrei That was.. unexpected :) Does that mean requirements for any future experimental proposals should also be tuned down a bit?
Re: Pandas example of groupby
On 1/26/15 12:31 PM, H. S. Teoh via Digitalmars-d wrote: As far as I know, the current groupBy docs explain quite clearly what it does. I agree. That said, perhaps a change of name would avoid confusion. I like groupBy as we currently define it, it's straight within the spirit of D. However, some people may legitimately expect it does global processing and groups all identical keys together. So here's what I think we should do: 1. Rename our current groupBy to chunkBy 2. Change code to have chunkBy with binary predicates return tuples, as discussed 3. Add a method called groupEquivalent to SortedRange. It takes no predicate (because predicate already is embedded in SortedRange). It groups together elements that are equivalent according to the sorting order. Returns a range of ranges (similar to what groupBy returns now). 4. Perhaps add a global chunkEquivalent as an alias for groupBy!((a, b) => a == b). So then in order to get relational group-by semantics by sorting, one would write range.sort!(predicate).groupEquivalent... Andrei
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On 1/26/15 12:46 PM, Dicebot wrote: On Monday, 26 January 2015 at 20:35:31 UTC, Andrei Alexandrescu wrote: On 1/26/15 12:30 PM, Dicebot wrote: We couldn't merge it into std.experimental before because you have stated that even std.experimental modules shouldn't have a breaking changes normally. It was 2 reviews ago. Now you have reconsidered, which is understandable considering how long has it been taking, but pretending that was intended to work that way does not make you look good :( PS I was in favor for very lax initial requirements for experimental packages for this very reason. Now I remember. I admit I was wrong. -- Andrei That was.. unexpected :) Does that mean requirements for any future experimental proposals should also be tuned down a bit? Of course. I'm not planning to repeat the mistake :o). -- Andrei
Re: dlang.org redesign -- a better code sample for landing page
On Friday, 23 January 2015 at 13:55:04 UTC, aldanor wrote:
auto lines = stdin.byLine.map!(line => line.length);
writefln("Average line length: %.4f.", 1.0 * lines.sum /
lines.array.length);
This won't work; `sum` already consumes the range, so there will
be nothing left to compute the length from.
Re: Pandas example of groupby
Don't forget that there is already http://dlang.org/phobos/std_algorithm.html#.group which matches groupBy in this context (only groups consequitive elements). It would be totally awkward to have those named differently (which was why I have suggested to change the name from chunkBy to groupBy in the very beginning)
Re: 521 days, 22 hours, 7 minutes and 52 seconds...
On Monday, 26 January 2015 at 20:51:40 UTC, Andrei Alexandrescu wrote: That was.. unexpected :) Does that mean requirements for any future experimental proposals should also be tuned down a bit? Of course. I'm not planning to repeat the mistake :o). -- Andrei Great news, thanks!
Re: accept @pure @nothrow @return attributes
On 1/26/2015 12:26 PM, Dicebot wrote: It was sad that calls for more breakage were mostly ignored. But there is one thing now that is even worse - referring to #pleasebreakmycode as an excuse to introduce random changes based on random reddit comment - and completely dismissing everything that was said on topic initially. Resulting in exactly the opposite action that was asked to. I can't find Don's original post on the topic.
