Re: Feature request: Path append operators for strings
On Monday, 8 July 2013 at 18:37:30 UTC, Walter Bright wrote: On 7/8/2013 6:31 AM, Dicebot wrote: Well, second one is not really a scientific problem, it is a philosophical one. Self-awareness is a very vague term with a lot of space for personal interpretation. I don't even think it is worth speaking about. If you consider that our brains evolved, and self-awareness was a result of evolution, then self-awareness presumably offers some sort of survival benefit. Not necessarily. If the change is neutral, it can still develop in some species. Arguably, as our brain consume 20% of our energy, this is highly likely that it has benefit, so you still have a point. Following that line of reasoning, self-awareness becomes a real phenomenon with a scientific basis. How is it defined in science ? The concept seems hard to define in proper ways to me.
Re: Feature request: Path append operators for strings
On Monday, 8 July 2013 at 21:46:24 UTC, Walter Bright wrote: Just because we have difficulty defining something is not a reason to dismiss it as irrelevant or non-existent. I'm sure you're self-aware, as I'm sure Siri and Watson are not. It is proven that at least 70% of what we perceive as being our decisions are in fact backward rationalization. I don't think the idea is that absurd that it may be 100%
Re: Phobos rising!
On Monday, 8 July 2013 at 19:34:32 UTC, Walter Bright wrote: http://spaceindustrynews.com/mars-curiosity-rover-shoots-video-of-phobos-moon-rising-video/3694/ Awesome ! I love it !
Re: Phobos rising!
On 07/08/2013 09:34 PM, Walter Bright wrote: > http://spaceindustrynews.com/mars-curiosity-rover-shoots-video-of-phobos-moon-rising-video/3694/ https://www.youtube.com/watch?v=4Aq_ZvBgIx0#t=31s :-) Seriously, though -- that's a fascinating video. Thanks so much for sharing.
Re: Function literals can't be class members
On Monday, 8 July 2013 at 22:41:41 UTC, JS wrote: trying to use a lambda inside a sub template gives an error. mixin template a { template b() { enum b = { }(); } mixin(b!()); } gives the error in the subject, removing the nesting or using a function instead of a lamda produces no error, yet all are essentially semantically equivalent... just the lamda version requires less typing. (in fact, it would be nice to have a simplification of template b() = { ... }();) Anyone have any ideas?
Re: Phobos rising!
On 07/09/2013 11:44 AM, Joseph Rushton Wakeling wrote: > On 07/08/2013 09:34 PM, Walter Bright wrote: >> http://spaceindustrynews.com/mars-curiosity-rover-shoots-video-of-phobos-moon-rising-video/3694/ > > https://www.youtube.com/watch?v=4Aq_ZvBgIx0#t=31s :-) ... https://www.youtube.com/watch?feature=player_detailpage&v=4Aq_ZvBgIx0#t=31s One joke buggered up, then. :-P
Re: Function literals can't be class members
On Tuesday, 9 July 2013 at 09:44:17 UTC, JS wrote: Anyone have any ideas? Yes and I will answer once you start asking question in D.learn newsgroup.
Re: Function literals can't be class members
On Monday, 8 July 2013 at 22:41:41 UTC, JS wrote: trying to use a lambda inside a sub template gives an error. mixin template a { template b() { enum b = { }(); } mixin(b!()); } gives the error in the subject, removing the nesting or using a function instead of a lamda produces no error, yet all are essentially semantically equivalent... just the lamda version requires less typing. (in fact, it would be nice to have a simplification of template b() = { ... }();) This belongs in D.learn. The code you provided is never going to give any "Function literals can't be class members" error, although it does have a lot of other things wrong with it. 1) The mixin template has no parameter list. 2) enum b = { }(); isn't valid without a function body. Did you mean (){} ? 3) and it definitely isn't going to return a string to work with mixin(); It helps to give code examples that are at least syntactically correct, if not immediately compilable. A correct and simplified test case of what I *think* you are talking about is this: mixin template A() { auto foo = (){ }; } class C { mixin A!(); } Error: delegate f977.C.A!().__lambda1 function literals cannot be class members Lambda function and delegate literals cannot be class members. Function literals can. I'm not entirely sure on the reason why, it's probably to do with context pointers.
Re: Feature request: Path append operators for strings
On Monday, 8 July 2013 at 21:46:24 UTC, Walter Bright wrote: Just because we have difficulty defining something is not a reason to dismiss it as irrelevant or non-existent. Sure, but there is an important difference between "dismissing" and "dismissing as a relevant scientific term to discuss". Speaking about possible self-awareness of computers is perfectly fine for a forum discussion but not acceptable for a scientific one. One needs a common well-defined terms to make progress. I'm sure you're self-aware, as I'm sure Siri and Watson are not. I'll take it as a compliment :) But that is exactly what I am talking about - question if you consider someone self-aware is extremely interesting from the psychological point of view (probably even social psychology). For AI research important question is what properties do self-aware being has. Those are related but different. In a former case exact meaning of self-awareness is not important as you primarily study a person who makes a statement, not statement itself. In other words, it is not important what one means by "self-aware" but what thinking processes result in such tag. The latter relies on research done in previous step to define properties of "self-aware" state that target AI needs to meet to be recognized as such by a wide variety of people. And, of course, as this relies on a common consensus, such concept is naturally very volatile. That is the main idea behind Turing test as far as I understand it. ... nor does it mean that personhood is not a very useful and meaningful construct. Even worse, now you use "personhood" as a replacement for self-awareness! :) It is a very dangerous mistake to use common words when speaking about consciousness and thinking - too much self-reflection involved.
Re: Function literals can't be class members
On Tuesday, 9 July 2013 at 10:10:10 UTC, Dicebot wrote: On Tuesday, 9 July 2013 at 09:44:17 UTC, JS wrote: Anyone have any ideas? Yes and I will answer once you start asking question in D.learn newsgroup. Thanks... I'll just keep posting in here then...
Re: Feature request: Path append operators for strings
On Tuesday, 9 July 2013 at 10:38:11 UTC, Dicebot wrote: ... nor does it mean that personhood is not a very useful and meaningful construct. Even worse, now you use "personhood" as a replacement for self-awareness! :) It is a very dangerous mistake to use common words when speaking about consciousness and thinking - too much self-reflection involved. You're looking at it in the wrong context. Walter was talking about personhood as an analogy, not at all conflating it with self-awareness. I agree 100% about the language point. By and large our languages (and language abilities) have evolved to identify and communicate day-to-day opportunities and risks. They are very specialised DSLs running on very specialised hardware, not well suited to performing complex runtime introspection or large-scale formal logic :p Interestingly, it doesn't take a huge change in design to unleash some very different abilities, e.g. autistic savants.
Re: Function literals can't be class members
On Tuesday, 9 July 2013 at 10:25:26 UTC, John Colvin wrote: On Monday, 8 July 2013 at 22:41:41 UTC, JS wrote: trying to use a lambda inside a sub template gives an error. mixin template a { template b() { enum b = { }(); } mixin(b!()); } gives the error in the subject, removing the nesting or using a function instead of a lamda produces no error, yet all are essentially semantically equivalent... just the lamda version requires less typing. (in fact, it would be nice to have a simplification of template b() = { ... }();) This belongs in D.learn. The code you provided is never going to give any "Function literals can't be class members" error, although it does have a lot of other things wrong with it. 1) The mixin template has no parameter list. 2) enum b = { }(); isn't valid without a function body. Did you mean (){} ? 3) and it definitely isn't going to return a string to work with mixin(); It helps to give code examples that are at least syntactically correct, if not immediately compilable. A correct and simplified test case of what I *think* you are talking about is this: mixin template A() { auto foo = (){ }; } class C { mixin A!(); } Error: delegate f977.C.A!().__lambda1 function literals cannot be class members Lambda function and delegate literals cannot be class members. Function literals can. I'm not entirely sure on the reason why, it's probably to do with context pointers. Maybe you need to go tell Artur that he is wrong first before you bitch at me for being wrong... http://forum.dlang.org/thread/myalrxrrwoljxbboa...@forum.dlang.org Please, at least if you are going to bitch and talk down to me about writing valid source code at least know what you are talking about in the first place... module main; import std.stdio, std.cstream; template b() { enum b = { return "\"asdf\""; }(); pragma(msg, b); } int main(string[] argv) { auto f = (){ writeln("asd"); }; f(); writeln(mixin(b!())); din.getc(); return 0; }
Re: Function literals can't be class members
On Tuesday, 9 July 2013 at 10:45:40 UTC, JS wrote: On Tuesday, 9 July 2013 at 10:10:10 UTC, Dicebot wrote: On Tuesday, 9 July 2013 at 09:44:17 UTC, JS wrote: Anyone have any ideas? Yes and I will answer once you start asking question in D.learn newsgroup. Thanks... I'll just keep posting in here then... Please don't. Posting in d.learn to check you haven't missed something stupid, then following it up with either a bug report or a post in the main newsgroup if appropriate is good practice. We all make mistakes from time-to-time. P.S. Dicebot's responses to your questions have been by-and-large correct and informative. I'm sure he genuinely means he will try to help you if you post in the correct place.
Re: Function literals can't be class members
On Tuesday, 9 July 2013 at 11:03:34 UTC, JS wrote: On Tuesday, 9 July 2013 at 10:25:26 UTC, John Colvin wrote: On Monday, 8 July 2013 at 22:41:41 UTC, JS wrote: trying to use a lambda inside a sub template gives an error. mixin template a { template b() { enum b = { }(); } mixin(b!()); } gives the error in the subject, removing the nesting or using a function instead of a lamda produces no error, yet all are essentially semantically equivalent... just the lamda version requires less typing. (in fact, it would be nice to have a simplification of template b() = { ... }();) This belongs in D.learn. The code you provided is never going to give any "Function literals can't be class members" error, although it does have a lot of other things wrong with it. 1) The mixin template has no parameter list. 2) enum b = { }(); isn't valid without a function body. Did you mean (){} ? 3) and it definitely isn't going to return a string to work with mixin(); It helps to give code examples that are at least syntactically correct, if not immediately compilable. A correct and simplified test case of what I *think* you are talking about is this: mixin template A() { auto foo = (){ }; } class C { mixin A!(); } Error: delegate f977.C.A!().__lambda1 function literals cannot be class members Lambda function and delegate literals cannot be class members. Function literals can. I'm not entirely sure on the reason why, it's probably to do with context pointers. Maybe you need to go tell Artur that he is wrong first before you bitch at me for being wrong... http://forum.dlang.org/thread/myalrxrrwoljxbboa...@forum.dlang.org Please, at least if you are going to bitch and talk down to me about writing valid source code at least know what you are talking about in the first place... module main; import std.stdio, std.cstream; template b() { enum b = { return "\"asdf\""; }(); pragma(msg, b); } int main(string[] argv) { auto f = (){ writeln("asd"); }; f(); writeln(mixin(b!())); din.getc(); return 0; } I am genuinely confused. Nothing in Arturs code or your example contains anything that is applicable to the 3 bullet points I wrote: 1) Neither contain any mixin templates 2) None use {}() without some content to the body. 3) Both bodies using that syntax explicitly return strings.
Re: Function literals can't be class members
On Tuesday, 9 July 2013 at 11:06:22 UTC, John Colvin wrote: P.S. Dicebot's responses to your questions have been by-and-large correct and informative. I'm sure he genuinely means he will try to help you if you post in the correct place. I am always ready to help when it makes sense. But there is a major difference between helping a newbie which does not yet know where to ask for help and being patient in presence of arrogant aggression. I really think simply ignoring all JS questions until he learns to not flood main newsgroup is the right think to do and your attempt to be friendly does not help here. One-sided friendliness is just asking for an abuse. Exactly what JS does, intentionally.
Re: [phobos] New Linux phobos shared library
On Tuesday, 9 July 2013 at 04:53:01 UTC, Jordi Sayol wrote: I propose to name the shared phobos library as "libphobos2.so.0.nn.0", where "nn" is the current dmd version. The last zero is just for bug/regression fixes. This is exactly naming scheme I am already using in my Arch Linux PKGBUILD, so +1 here :)
Searching for D using Goolgle
Hmmm. Every time I search for something using the search string "dlang", Google asks me did I mean "golang". Are Google getting worried about the success of D? -=mike=-
Re: Searching for D using Goolgle
On Tuesday, 9 July 2013 at 12:42:47 UTC, Mike James wrote: Hmmm. Every time I search for something using the search string "dlang", Google asks me did I mean "golang". Are Google getting worried about the success of D? -=mike=- I guess that is search personalization in action ;)
Re: typeid(double) does not respect NaNs
On Tue, Jul 09, 2013 at 08:05:35AM +0200, deadalnix wrote: > On Tuesday, 9 July 2013 at 03:03:34 UTC, H. S. Teoh wrote: > >More to the point, *if* typeinfo isn't meant to match == for whatever > >reason, then why is it being used as the standard of comparison for > >AA keys? > > > > I guess we need NaN == NaN to be true for AA keys, no ? Not according to: http://d.puremagic.com/issues/show_bug.cgi?id=7836 So, should NaN == NaN for AA keys, or not? T -- Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte
Re: [phobos] New Linux phobos shared library
On Tue, Jul 09, 2013 at 06:52:44AM +0200, Jordi Sayol wrote: > From dmd v2.063, release zip file includes Linux phobos shared > libraries. As shared libraries are needed at runtime too, we should > allow to install multiple versions of phobos shared libs. at same > time. If not, every program compiled against it will be forced to be > recompiled every new dmd/phobos release. To avoid this, phobos shared > libs. should include some version number on its name. > > I propose to name the shared phobos library as "libphobos2.so.0.nn.0", > where "nn" is the current dmd version. The last zero is just for > bug/regression fixes. > > As phobos changes its interface (almost) every new release, I propose > to set its SONAME to "libphobos2.so.0.nn", so when phobos become > stable we can change the library name to "libphobos2.so.1.0.0" and its > SONAME to "libphobos2.so.1". > > Some info about Linux shared libraries: > http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html [...] +1. Shared library breakages are a royal pain in the neck. We should try to get them right earlier rather than later. I'd say file a high-priority bug in the bugtracker, if it hasn't already been. Basically, the library needs to have a different soname EVERYTIME its ABI changes (not just API, mind you). Anything other than that will lead to pain and angry users. T -- Let's call it an accidental feature. -- Larry Wall
pushd / popd for std.process/std.file
Having pushd/popd in std.process would make a lot of code look better, often you have to change the workding directory only for a few commands, with pushd/popd you don't have to temporarily store the old one explicitly. pushd/popd: https://en.wikipedia.org/wiki/Pushd_and_popd What do you think? void build() { pushd("../build") scope(exit) popd(); shell("cmake ../src/c/bla"); shell("make"); }
Re: [phobos] New Linux phobos shared library
On 09/07/13 13:37, Dicebot wrote: > On Tuesday, 9 July 2013 at 04:53:01 UTC, Jordi Sayol wrote: >> I propose to name the shared phobos library as "libphobos2.so.0.nn.0", where >> "nn" is the current dmd version. The last zero is just for bug/regression >> fixes. > > This is exactly naming scheme I am already using in my Arch Linux PKGBUILD, > so +1 here :) > Thank you! and +1 for you too :-) Programs dynamically links against SONAME, so it's more important than the real library name. What SONAME naming scheme you used in Arch Linux PKGBUILD? -- Jordi Sayol
Re: Function literals can't be class members
On 07/09/2013 12:45 PM, JS wrote: > Thanks... I'll just keep posting in here then... You know, most people, when they get informed there's a dedicated newsgroup/mailing list for language questions, are polite enough to say thank you for the information, and take their question over to the appropriate place. Generally speaking they have a better time getting answers, too :-)
Re: [phobos] New Linux phobos shared library
On Tuesday, 9 July 2013 at 14:31:51 UTC, Jordi Sayol wrote: Programs dynamically links against SONAME, so it's more important than the real library name. What SONAME naming scheme you used in Arch Linux PKGBUILD? To my shame, default one is (.0.2) is used, completely forgot about it. Will bother an official maintainer as soon as final decision is approved.
Re: pushd / popd for std.process/std.file
On Tuesday, 9 July 2013 at 14:21:48 UTC, David wrote: Having pushd/popd in std.process would make a lot of code look better, often you have to change the workding directory only for a few commands, with pushd/popd you don't have to temporarily store the old one explicitly. pushd/popd: https://en.wikipedia.org/wiki/Pushd_and_popd What do you think? void build() { pushd("../build") scope(exit) popd(); shell("cmake ../src/c/bla"); shell("make"); } I think it's a good idea, except instead of maintaing a separate stack it could use the call stack through RAII. Also, considering `getcwd` and `chdir` are in std.file, maybe that's the better location? Example implementation using RAII: --- auto pushd(in char[] path) { import std.file : chdir, getcwd; auto workingDir = getcwd(); struct PopWorkingDir { ~this() { chdir(workingDir); } } chdir(path); return PopWorkingDir(); } void main() { auto a = pushd("test"); import std.file : write; write("test.txt", "hi"); // Writes test/test.txt } --- Not sure if I like the fact that it will silently fail without the seemingly unused variable 'a' here (because the destructor is run immediately), but isn't this how we already do stuff like threading locks?
Re: pushd / popd for std.process/std.file
On Tuesday, 9 July 2013 at 15:02:59 UTC, Jakob Ovrum wrote: On Tuesday, 9 July 2013 at 14:21:48 UTC, David wrote: Having pushd/popd in std.process would make a lot of code look better, often you have to change the workding directory only for a few commands, with pushd/popd you don't have to temporarily store the old one explicitly. pushd/popd: https://en.wikipedia.org/wiki/Pushd_and_popd What do you think? void build() { pushd("../build") scope(exit) popd(); shell("cmake ../src/c/bla"); shell("make"); } I think it's a good idea, except instead of maintaing a separate stack it could use the call stack through RAII. Also, considering `getcwd` and `chdir` are in std.file, maybe that's the better location? -snip- Apropos threads; this isn't thread-safe at all, is it... does it make sense to define semantics with multi-threading in mind?
Re: [phobos] New Linux phobos shared library
On 09/07/13 15:49, H. S. Teoh wrote: > On Tue, Jul 09, 2013 at 06:52:44AM +0200, Jordi Sayol wrote: >> From dmd v2.063, release zip file includes Linux phobos shared >> libraries. As shared libraries are needed at runtime too, we should >> allow to install multiple versions of phobos shared libs. at same >> time. If not, every program compiled against it will be forced to be >> recompiled every new dmd/phobos release. To avoid this, phobos shared >> libs. should include some version number on its name. >> >> I propose to name the shared phobos library as "libphobos2.so.0.nn.0", >> where "nn" is the current dmd version. The last zero is just for >> bug/regression fixes. >> >> As phobos changes its interface (almost) every new release, I propose >> to set its SONAME to "libphobos2.so.0.nn", so when phobos become >> stable we can change the library name to "libphobos2.so.1.0.0" and its >> SONAME to "libphobos2.so.1". >> >> Some info about Linux shared libraries: >> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html > [...] > > +1. > > Shared library breakages are a royal pain in the neck. We should try to > get them right earlier rather than later. I'd say file a high-priority > bug in the bugtracker, if it hasn't already been. > > Basically, the library needs to have a different soname EVERYTIME its > ABI changes (not just API, mind you). Anything other than that will lead > to pain and angry users. Ok, I just proposed a system where every dmd beta release gives an specific phobos shared library name and SONAME. The problem you point will appear when phobos shared library becomes stable. I don't know what will be the best way to "control" ABI changes. Is it possible to create a sort of flag in the Phobos project repository indicating this? -- Jordi Sayol
Re: pushd / popd for std.process/std.file
On 07/09/13 17:04, Jakob Ovrum wrote: > On Tuesday, 9 July 2013 at 15:02:59 UTC, Jakob Ovrum wrote: >> On Tuesday, 9 July 2013 at 14:21:48 UTC, David wrote: >>> Having pushd/popd in std.process would make a lot of code look better, >>> often you have to change the workding directory only for a few commands, >>> with pushd/popd you don't have to temporarily store the old one explicitly. >>> >>> pushd/popd: https://en.wikipedia.org/wiki/Pushd_and_popd >>> >>> What do you think? >>> >>> >>> void build() { >>>pushd("../build") >>>scope(exit) popd(); >>> >>>shell("cmake ../src/c/bla"); >>>shell("make"); >>> } >> >> I think it's a good idea, except instead of maintaing a separate stack it >> could use the call stack through RAII. Also, considering `getcwd` and >> `chdir` are in std.file, maybe that's the better location? struct chDir { import std.file : chdir, getcwd; typeof(getcwd()) oldDir; this(string newDir) { oldDir = getcwd(); chdir(newDir); } ~this() { chdir(oldDir); } @disable this(this); } import std.file : write; with (chDir("testdir")) write("test.txt", "hi"); But that is not going to work right now - the chDir object is destroyed too soon (compiler bug). > Apropos threads; this isn't thread-safe at all, is it... does it make sense > to define semantics with multi-threading in mind? Allowing declarations inside with() would make it possible to handle the multithreaded case too. artur
Re: typeid(double) does not respect NaNs
On Tuesday, 9 July 2013 at 13:46:48 UTC, H. S. Teoh wrote: On Tue, Jul 09, 2013 at 08:05:35AM +0200, deadalnix wrote: On Tuesday, 9 July 2013 at 03:03:34 UTC, H. S. Teoh wrote: >More to the point, *if* typeinfo isn't meant to match == for >whatever >reason, then why is it being used as the standard of >comparison for >AA keys? > I guess we need NaN == NaN to be true for AA keys, no ? Not according to: http://d.puremagic.com/issues/show_bug.cgi?id=7836 So, should NaN == NaN for AA keys, or not? T I think it was not decided yet. From language coherency point of view NaN != NaN like in general case, from usefulness perspective you don't need several nans in AA array.
Re: Function literals can't be class members
On Tuesday, 9 July 2013 at 10:45:40 UTC, JS wrote: On Tuesday, 9 July 2013 at 10:10:10 UTC, Dicebot wrote: On Tuesday, 9 July 2013 at 09:44:17 UTC, JS wrote: Anyone have any ideas? Yes and I will answer once you start asking question in D.learn newsgroup. Thanks... I'll just keep posting in here then... You should know that when you post such things your are insulting not only one particular person, but litter dozens of mailboxes with your abusive messages. There are many people hanging around here and many more who just read and interfere if matter. If you think that your provoking style is boosting your "acknowledgement" here then you are wrong, in fact you are boosting your chances to get banned for trolling, as was mentioned in previous discussions, let alone getting help.
Re: typeid(double) does not respect NaNs
On Tuesday, July 09, 2013 18:04:29 Maxim Fomin wrote: > On Tuesday, 9 July 2013 at 13:46:48 UTC, H. S. Teoh wrote: > > On Tue, Jul 09, 2013 at 08:05:35AM +0200, deadalnix wrote: > >> On Tuesday, 9 July 2013 at 03:03:34 UTC, H. S. Teoh wrote: > >> >More to the point, *if* typeinfo isn't meant to match == for > >> >whatever > >> >reason, then why is it being used as the standard of > >> >comparison for > >> >AA keys? > >> > >> I guess we need NaN == NaN to be true for AA keys, no ? > > > > Not according to: > > http://d.puremagic.com/issues/show_bug.cgi?id=7836 > > > > So, should NaN == NaN for AA keys, or not? > > > > > > T > > I think it was not decided yet. From language coherency point of > view NaN != NaN like in general case, from usefulness perspective > you don't need several nans in AA array. I'd think that having NaN != NaN would cause serious problems with retrieving any elements inserted with NaN as a key, but given how floating point values work, using them as the key for an AA is arguably completely broken to begin with as comparing floating point values for equality is generally just plain wrong. That being the case, I'd argue in favor of language consistency and just point out to anyone that runs into problems that using a floating point type as the key type of an AA is a stupid thing to do to begin with. - Jonathan M Davis
Re: typeid(double) does not respect NaNs
Jonathan M Davis: That being the case, I'd argue in favor of language consistency Here I'd like D AAs act as Python dicts. This means breaking "consistency". Bye, bearophile
Re: Searching for D using Goolgle
On Tuesday, 9 July 2013 at 12:44:40 UTC, Dicebot wrote: On Tuesday, 9 July 2013 at 12:42:47 UTC, Mike James wrote: Hmmm. Every time I search for something using the search string "dlang", Google asks me did I mean "golang". Are Google getting worried about the success of D? -=mike=- I guess that is search personalization in action ;) Yeah, that doesn't happen for me. I notice that you also use "dlang" in place of "d" in search results. "dlang" seems to get better results on average for me.
Re: Searching for D using Goolgle
On Tue, Jul 09, 2013 at 07:28:48PM +0200, w0rp wrote: > On Tuesday, 9 July 2013 at 12:44:40 UTC, Dicebot wrote: > >On Tuesday, 9 July 2013 at 12:42:47 UTC, Mike James wrote: > >>Hmmm. Every time I search for something using the search string > >>"dlang", Google asks me did I mean "golang". Are Google getting > >>worried about the success of D? > >> > >>-=mike=- > > > >I guess that is search personalization in action ;) > > Yeah, that doesn't happen for me. I notice that you also use "dlang" > in place of "d" in search results. "dlang" seems to get better > results on average for me. This is unfortunate though: https://github.com/dlang It shows up as the 3rd result on my google search for "dlang". T -- "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous
Re: Proposal: DPM, the D Package Manager
On Monday, 8 July 2013 at 20:51:09 UTC, Dicebot wrote: On Monday, 8 July 2013 at 20:46:21 UTC, Kevin Kane wrote: I don't know if this thread is dead but... Have you considered dub? It seems like current main bet as D package manager http://registry.vibed.org/ With more adoption, dub can be become D's answer to Pythons pip, if it isn't already.
Re: A thread without GC
On Jul 8, 2013, at 8:08 AM, Adam D. Ruppe wrote: > On Monday, 8 July 2013 at 14:53:25 UTC, John Colvin wrote: >> I wonder if one could somehow register a pre-existing thread with >> std.concurrency, being careful not to introduce any reference that lets in >> the garbage collector. > > There is a thread_attachThis() in core.thread that "Registers the calling > thread for use with the D Runtime. " and returns a Thread object. > > However, I think that registers it with the GC too so it defeats the purpose > of skipping Thread in the first place. Right. The point of that routine is to make it so an external thread can safely reference garbage collected memory. > Looking at the source of std.concurrency, it looks like it just has a thread > local mailbox for each one, that is created when you call thisTid() the first > time. > > idk if that's actually all that is done, or if TLS needs any special work > (I've never actually used pthreads directly), but maybe you could try calling > that thisTid() function in the thread you make yourself and then send it a > message and see what happens. You'd really need to call thread_attachThis() first, since std.concurrency uses garbage collected memory for message passing.
Re: A thread without GC
On Jul 8, 2013, at 7:04 AM, John Colvin wrote: > I would post this in d.learn, but I suspect there isn't an easy answer so it > would be good to have some serious discussion here. > > Is there any way to create a thread that is totally free from the garbage > collector? > > I.e. > Nothing in that thread will ever be scanned by the GC. > Therefore, when the GC "stops the world", that thread can just keep on going. > > Obviously one could create a separate process, but it would be nice to have > it encapsulated within a single process for optimum speed of communication > and not having to mess around with pipes. > > P.S. Yes I realise how careful one would have to be when using this. There's a pull request for this that's been discussed on the Druntime list and while I'm willing to accept it so long as sufficient safeguards are in place, I still really don't understand the need for this feature. Once you eliminate the GC support code there really isn't much left in core.thread. What advantage is there of being able to create Thread objects that aren't managed by the GC (which I'll call juggernaut threads)?
Re: Deimos Request: Add flac
On 7/8/2013 10:51 PM, Jonathan M Davis wrote: On Monday, July 08, 2013 22:43:41 Walter Bright wrote: On 7/8/2013 9:28 PM, Jonathan M Davis wrote: Walter, would you please create a 1.2.1 branch? I can't create a pull request with the 1.3.0 stuff until there's branch for 1.2.1, or 1.2.1 won't be particularly usable, and 1.3.0 is recent enough that 1.2.1 is still quite prevalent (probably more than 1.3.0). You're a Team Deimos member, you should be able to do it. Whenever I try and commit to the main repository, it tells me I don't have permission. Specfically, I get -- ERROR: Permission to D-Programming-Deimos/flac.git denied to jmdavis. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. -- I know that with the D-Programming-Language organization, permissions must still be given out for each repo (e.g. I don't have commit access to dmd), so I'd guess that it's the same with D-Programming-Deimos unless there's some way to automatically give the team members commit permissions to all repos in the org. But I don't know exactly what kind of control there is over the permissions in a github organization, because I don't have the permissions to manage any of the orgs that I'm in. You do have push/pull permissions to all Deimos repositories. I think that means you need to submit your changes as a pull request, not do it directly.
Re: Phobos rising!
On 7/9/2013 2:46 AM, Joseph Rushton Wakeling wrote: On 07/09/2013 11:44 AM, Joseph Rushton Wakeling wrote: On 07/08/2013 09:34 PM, Walter Bright wrote: http://spaceindustrynews.com/mars-curiosity-rover-shoots-video-of-phobos-moon-rising-video/3694/ https://www.youtube.com/watch?v=4Aq_ZvBgIx0#t=31s :-) ... https://www.youtube.com/watch?feature=player_detailpage&v=4Aq_ZvBgIx0#t=31s One joke buggered up, then. :-P Debbie Gibson still trying to revive her career? :-)
Re: atomic Weapons: The C++ Memory Model and Modern Hardware
On Jul 8, 2013, at 12:04 PM, Flamaros wrote: > http://herbsutter.com/2013/02/11/atomic-weapons-the-c-memory-model-and-modern-hardware/ > > Is D and DMD aware of those kind of issues with atomic? I think more thought needs to be given to how the compiler recognizes and treats atomic operations in D. In D1, we had "volatile" as a means of telling the compiler that it shouldn't optimize code according to certain rules, but this has been deprecated in D2. And while DMD doesn't optimize inside or across asm blocks, other compilers may. "shared" is somewhat helpful here, but even then I'm not entirely certain that a compiler like GDC will not do something unsafe with code that's intended to be atomic. From an API perspective, D has a label roughly akin to "atomic" in "shared", and even supports relaxed atomics via core.atomic. If it matters, the original API in core.atomic (atomicLoad and atomicStore) is based on a design by Alexander Terekhov, who influenced both the Boost and C++0x design. I think I even participated in the C++0x memory model discussion back in the beginning if you're inclined to dig through the archives, and aside from Andrei and Walter the community has a few other folks with a good knowledge of low-level concurrency. Either way, I think D's support for concurrency is less extensive than on C++0x (no futures, for example) but is reasonably solid and with some nice overlays, like std.concurrency. Life is also a bit easier for us because D doesn't support as many architectures as C++, so we don't currently need as much code behind things like core.atomic to make everything work. But I'm confident that the existing APIs could extend to weak architectures without alteration. In short, we're aware of the issues and have a good foundation, but more work needs to be done.
[OT] Why mobile web apps are slow
A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ -- Paulo
Re: atomic Weapons: The C++ Memory Model and Modern Hardware
On Jul 8, 2013, at 5:05 PM, Marco Leise wrote: > Fortunately on x86 > architectures at least, atomic operations are pretty sane and > fast. The x86 memory model is sufficiently strict that, by and large, simple concurrent interactions actually work without any memory barriers at all. I've never been able to decide whether this is a good or a bad thing however.
Re: [OT] Why mobile web apps are slow
On Jul 9, 2013, at 11:12 AM, Paulo Pinto wrote: > A bit off-topic, but well worth reading, > > http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ Thanks for the link. In my experience, mobile networking is slow in general. When I run Speedtest on my phone vs. a laptop sitting right next to it, the phone has a fraction of the bandwidth of the laptop. So there's even more at issue than raw JS performance.
Re: Poll: how long have you been into D
On Monday, 8 July 2013 at 19:22:59 UTC, H. S. Teoh wrote: Y'know what would be an awesome feature? A configurable volume level scheduler, like those old turn-on-the-light-at-night power dials, that automatically shuts off the volume at night, and turns it back on in the morning. Better yet, turn it off during the times in the week where you're in a library / concert / meeting when it shouldn't be going off. Get enough people to use it, and we might stop having to make the now-obligatory announcement "please turn off your cellphones" all the time (and have people *still* get loud noisy ringtones in the middle of it). Anybody wanna code up a D app for this? It might be the killer app that makes D famous. ;-) Well in Android there is Tasker. I have it play music when I leave work and if I have the headphones plugged in. It is easy to have it adjust volume at specific times of the day/location.
Re: Deimos Request: Add flac
On 07/09/2013 04:06 AM, Jonathan M Davis wrote: > Walter (or someone else with the appropriate permissions), would you please > add a repo to deimos for flac? It's unlikely that I'll ever personally use this code (though never say never:-), but as an enthusiastic audiophile, thank you very much for ensuring that FLAC is usable with D :-)
Re: Phobos rising!
On 07/09/2013 07:56 PM, Walter Bright wrote: > Debbie Gibson still trying to revive her career? :-) I think the octopus was the real rising star here ... :-P
Linear algebra for Win64?
Does anyone know of a good D linear algebra library for Win64? I tried scid a year ago and liked it on Win32, but have been unable to get it to link on Win64. When trying to run scid on Win64, I've been using prebuilt LAPACK 3.4.1 libraries from http://icl.cs.utk.edu/lapack-for-windows/lapack/, but have unresolved external symbol dgesv_
Re: [OT] Why mobile web apps are slow
On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote: A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ -- Paulo I think that the garbage collection part of the atricle is very relevant to the usage of D on mobile.
Re: [OT] Why mobile web apps are slow
On Tuesday, 9 July 2013 at 19:27:22 UTC, QAston wrote: On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote: A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ -- Paulo I think that the garbage collection part of the atricle is very relevant to the usage of D on mobile. Nobody uses D on mobile, so it's not very relevant. ;) If Intel ever makes a comeback on mobile- Samsung is putting x86 chips in their next generation of Galaxy Tab tablets, so it's possible- it might not take much effort to port D/ldc to Android/x86 though, so maybe it will be relevant someday. Good article, with some good data.
Re: [OT] Why mobile web apps are slow
On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote: A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ An interesting article, a strong critique of many kinds of garbage collection. Having good enough built-in means to avoid relying on a GC seems quite important to use D where memory is limited. Bye, bearophile
Re: atomic Weapons: The C++ Memory Model and Modern Hardware
On 07/08/2013 09:04 PM, Flamaros wrote: > http://herbsutter.com/2013/02/11/atomic-weapons-the-c-memory-model-and-modern-hardware/ > > > Is D and DMD aware of those kind of issues with atomic? OT: How does he change slides? I can't see a clicker nor a sign for somebody off camera?? Anyway, awesome presentation and awesome presentation style.
Re: [OT] Why mobile web apps are slow
On Tuesday, 9 July 2013 at 20:02:33 UTC, bearophile wrote: On Tuesday, 9 July 2013 at 18:12:24 UTC, Paulo Pinto wrote: A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ An interesting article, a strong critique of many kinds of garbage collection. Having good enough built-in means to avoid relying on a GC seems quite important to use D where memory is limited. It's not just in the limited memory case of mobile devices that GC is a problem. There are a few domains that come to mind where the ability to escape GC and rely on manual memory management is extremely important. While there was some reference made to an approach to allocators in the closing talk of DConf, I haven't seen much discussion of an approach using D's features. -- Brian PS: That silhouette of the SR-71 at the point allocators are mentioned sets a high bar for the design!
Re: Deimos Request: Add flac
On Tuesday, July 09, 2013 20:27:57 Joseph Rushton Wakeling wrote: > On 07/09/2013 04:06 AM, Jonathan M Davis wrote: > > Walter (or someone else with the appropriate permissions), would you > > please > > add a repo to deimos for flac? > > It's unlikely that I'll ever personally use this code (though never say > never:-), but as an enthusiastic audiophile, thank you very much for > ensuring that FLAC is usable with D :-) I have enough flac files that I need to be able to do stuff to manage them better as well as transcode them for mobile devices, and to do some of that I need to be able to interact with flac (and potentially vorbis-tools or lame if I'm transcoding). I've been using std.process.system for the stuff that I've been doing, but I really need access to flac metadata in code. So, I'm going to be wrapping flac in D (with ranges) at some point here and I intend to create bindings for stuff like vorbis-tools, lame, and libcddb at some point and will likely wrap them in D libraries as well (though it'll probably all take a while given everything else that I have going). Putting the bindings for flac in deimos is just the first step. I've had them sitting around for a while and figured that it was long past time to get them completed and into deimos. - Jonathan M Davis
Re: Deimos Request: Add flac
On Tuesday, July 09, 2013 10:52:12 Walter Bright wrote: > You do have push/pull permissions to all Deimos repositories. I think that > means you need to submit your changes as a pull request, not do it > directly. Okay, but AFAIK, you have to have commit permissions to the repo in order to create new branches. I don't know of any way to create a branch via a pull request. And I specifically need to create a branch for version 1.2.1 of flac as opposed to simply changing what's in master. So, as far as I can tell (though maybe there's something I'm missing), I either need commit permissions to the repo so that I can push a new branch to the deimos flac repo, or I need someone who does have such permissions to do that for me. - Jonathan M Davis
Re: typeid(double) does not respect NaNs
On Tuesday, July 09, 2013 19:19:18 bearophile wrote: > Jonathan M Davis: > > That being the case, I'd argue in favor of language consistency > > Here I'd like D AAs act as Python dicts. This means breaking > "consistency". I'm afraid that you'll have to be more specific in terms of what you mean. But as far as I can tell, using floating point values as keys in an AA is fundamentally broken, because using == with floating point values is fundamentally broken. As such, I see no reason why it should matter that NaN is effectively unusable as an AA key. - Jonathan M Davis
Re: typeid(double) does not respect NaNs
Jonathan M Davis: I'm afraid that you'll have to be more specific in terms of what you mean. Please ignore what I have said... As such, I see no reason why it should matter that NaN is effectively unusable as an AA key. OK. Bye, bearophile
Re: A thread-safe weak reference implementation
if (GC.addrOf(cast(void*)obj)) return obj; Smart :-) You are waiting for the collection to complete, if we are one of the threads started before destructor calls happen. Brilliant. Is it ok if I shamelessly copy parts of your implementation for the new std.signals? I will of course mention your name. Best regards, Robert
Re: Deimos Request: Add flac
On 7/9/2013 2:02 PM, Jonathan M Davis wrote: Okay, but AFAIK, you have to have commit permissions to the repo in order to create new branches. I don't know of any way to create a branch via a pull request. And I specifically need to create a branch for version 1.2.1 of flac as opposed to simply changing what's in master. So, as far as I can tell (though maybe there's something I'm missing), I either need commit permissions to the repo so that I can push a new branch to the deimos flac repo, or I need someone who does have such permissions to do that for me. Ok, I created a 1.2.1 branch.
Re: typeid(double) does not respect NaNs
On Tuesday, 9 July 2013 at 21:12:15 UTC, Jonathan M Davis wrote: On Tuesday, July 09, 2013 19:19:18 bearophile wrote: Jonathan M Davis: > That being the case, I'd argue in favor of language > consistency Here I'd like D AAs act as Python dicts. This means breaking "consistency". I'm afraid that you'll have to be more specific in terms of what you mean. But as far as I can tell, using floating point values as keys in an AA is fundamentally broken, because using == with floating point values is fundamentally broken. As such, I see no reason why it should matter that NaN is effectively unusable as an AA key. - Jonathan M Davis Using floating point as keys can make sense in an ordered container actually. Just thought I'd point it out. Basically, instead of looking for specific keys, you try to position yourself between two entries. But since our AA's are hashed sets, then no, it doesn't make sense for us."
Re: [OT] Why mobile web apps are slow
On Tue, 09 Jul 2013 20:12:25 +0200 Paulo Pinto wrote: > A bit off-topic, but well worth reading, > > http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ > > -- > Paulo Very good article. (Actually, a nice site design, too.)
Re: [OT] Why mobile web apps are slow
On 7/9/2013 11:12 AM, Paulo Pinto wrote: A bit off-topic, but well worth reading, http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ It isn't off-topic at all. It's very relevant to D. I also agree with what he says about GC.
Re: Current version of D.
On Sunday, 7 July 2013 at 07:36:41 UTC, Russel Winder wrote: On Sat, 2013-07-06 at 15:24 +0200, mike james wrote: > The current release is 2.063.2, but it's the first time that > we've actually > released point releases like that, so there are likely to be > places saying > 2.063 instead of 2.063.2. Maybe it's time to make the odd-numbered releases the work in progress releases and the even-numbered releases the official releases? Everyone, cf. Linux, who used to operate such a strategy has now stopped. A release is a release and should be releasable. Finding problems in a release is natural which is why the maj.min.bug release numbering is so popular. The issue here is that the releases should be numbered this way always so as to make a monotonic increasing sequence. Thus 2.063 should have been numbered 2.63.0. Agreed, however we should also have a pre-release package for testing that is clearly marked as a pre-release, it can go on a separate web page to avoid any possibility of confusion. The current release is showing as both 2.63.0 and 2.63 but I thought it was supposed to be 2.63.2 everywhere. This is very confusing. --rt
Re: Current version of D.
On Tuesday, 9 July 2013 at 22:34:18 UTC, Rob T wrote: Agreed, however we should also have a pre-release package for testing that is clearly marked as a pre-release, it can go on a separate web page to avoid any possibility of confusion. The current release is showing as both 2.63.0 and 2.63 but I thought it was supposed to be 2.63.2 everywhere. This is very confusing. --rt Running latest release shows this ... DMD64 D Compiler v2.063 It should show the full release number. --rt
Re: [OT] Why mobile web apps are slow
Walter Bright: It isn't off-topic at all. It's very relevant to D. I also agree with what he says about GC. There's a long way from recognizing those problems, to having good enough solutions in D. Some possible attack strategies for D are: - A less allocating Phobos to produce a bit less garbage; - A more precise GC to avoid some memory leaks; - Perhaps an annotation to disallow heap allocations in a function or a piece of code; - Some good way to allocate variable length arrays on the stack (http://d.puremagic.com/issues/show_bug.cgi?id=9832 ) (so some arrays produce no garbage); - The implementation of "scope" maybe helps a bit; - Multiple alias this opens some opportunities to use structs in more places, avoiding some heap allocations. - Currently Phobos Scoped/emplace are not very good. Is that enough? Rust language designers seem to think that's not enough. Opinions are welcome. Bye, bearophile
Re: Current version of D.
On 7/9/13 6:36 PM, Rob T wrote: On Tuesday, 9 July 2013 at 22:34:18 UTC, Rob T wrote: Agreed, however we should also have a pre-release package for testing that is clearly marked as a pre-release, it can go on a separate web page to avoid any possibility of confusion. The current release is showing as both 2.63.0 and 2.63 but I thought it was supposed to be 2.63.2 everywhere. This is very confusing. --rt Running latest release shows this ... DMD64 D Compiler v2.063 It should show the full release number. --rt This is what the latest release shows for me: Andrews-MacBook-Pro:vapor andrewedwards$ dmd DMD64 D Compiler v2.063.2 Copyright (c) 1999-2013 by Digital Mars written by Walter Bright Documentation: http://dlang.org/ Are you actually using the latest release?
access CTFE variables at compile time.
It seems possible that we can print CTFE variables at compile time by using string mixes as the code below demonstrates. The problem is that we can not pass a variable to a template to create a print routine in the first place. e.g., we can't do mixin a!(s) if s is a string since s can't be read, supposedly, at compile time. We can't even do mixin("mixin a!(\""~s~"\");") though to get around this. The following code at least proves that CTFE variables can be read at compile time and the limitation is with the internal implementation. (this is easy to see, because on one hand we can't print s but on the other we can... hence the limitation with pragma is an artificial one.) import std.stdio, std.cstream, std.conv; mixin template a() { template b() { static string c() { string s = "a"; s ~= "b"; string x = "pragma(msg, \""~s~"\");"; // pragma(msg, s) // fails return x; } enum b = c(); } mixin(b!()); } int main(string[] argv) { mixin a!(); // can't pass a string to a in any way because of artificial ctfe limitation din.getc(); return 0; }
Re: Current version of D.
On Tuesday, 9 July 2013 at 22:46:36 UTC, Tyro[17] wrote: On 7/9/13 6:36 PM, Rob T wrote: On Tuesday, 9 July 2013 at 22:34:18 UTC, Rob T wrote: Agreed, however we should also have a pre-release package for testing that is clearly marked as a pre-release, it can go on a separate web page to avoid any possibility of confusion. The current release is showing as both 2.63.0 and 2.63 but I thought it was supposed to be 2.63.2 everywhere. This is very confusing. --rt Running latest release shows this ... DMD64 D Compiler v2.063 It should show the full release number. --rt This is what the latest release shows for me: Andrews-MacBook-Pro:vapor andrewedwards$ dmd DMD64 D Compiler v2.063.2 Copyright (c) 1999-2013 by Digital Mars written by Walter Bright Documentation: http://dlang.org/ Are you actually using the latest release? I did a full removal, and install of latest version as of today downloaded from here: http://dlang.org/download.html dmd_2.063-0_amd64.deb The version on download page is showing 2.063-0, and so does the deb file name, and also the installation process shows 2.063-0 was installed. Running compiler shows DMD64 D Compiler v2.063 Something has gone wrong somewhere. --rt
Re: [OT] Why mobile web apps are slow
On Tuesday, 9 July 2013 at 22:40:31 UTC, bearophile wrote: - A less allocating Phobos to produce a bit less garbage; Yes, and options to pass output ranges to more functions too, instead of always returning gc allocated things. - Perhaps an annotation to disallow heap allocations in a function or a piece of code; I don't think that will often get used, especially when we're already doing @safe pure const static void foo(); as it is. - Some good way to allocate variable length arrays on the stack (http://d.puremagic.com/issues/show_bug.cgi?id=9832 ) (so some arrays produce no garbage); These might be cool. Something we can do today is use static arrays as buffers. In my non-gc D experiments, I've made great use of a StackArray!(type, max_capacity) with the convenience operators overloaded. Combined with a solid "scope" implementation, this could be fast, convenient, and safe. Of course it would need to have a statically known max length big enough to store what you want to store without being too wasteful. But I don't think that's particularly hard in most cases - at least we have RangeError so it dies gracefully instead of buffer overflowing like you'd get i C. (It could also automatically grow to the gc heap if the programmer is ok with that.) - The implementation of "scope" maybe helps a bit; Yes. Is that enough? Rust language designers seem to think that's not enough. Opinions are welcome. I think if we do scope well enough, we'll have something similar to Rust that we can flesh out more in the library.
Is the compiler supposed to accept this?
While finishing up work on my parser and grammar specification I found this in container.d: return equal!(function(Elem a, Elem b) => !_less(a,b) && !_less(b,a)) (thisRange, thatRange); It seems to be some strange hybrid of the function literal syntax and the lambda syntax. It's not documented anywhere (surprise!) and I'm not sure if I should support it or file an accepts-invalid bug against DMD.
Memory management design
Given all of this talk about memory management, it would seem that it's time for people to start putting forward some ideas for improved memory management designs. I've got an idea or two of my own, but I'd like to discuss my ideas before I draft a DIP so I can try to get everything fleshed out and polished. Anyway the core idea behind my design is that object lifetimes tend to be managed in one of three ways: 1. Tied to a stack frame 2. Tied to an "owner" object 3. Not tied to any one object (managed by the GC) To distinguish between these types of objects, one could use a set of three storage classes: 1. "scope": refers to stack-allocated memory (which seems to be the original design behind "scope"). "scope" references may not be stashed anywhere where they might become invalid. Since this is the "safest" type of reference, any object may be passed by "scope ref". 2. "owned": refers to an object that is heap-allocated but manually managed by another object or by a stack frame. "owned" references may only be stashed in other "owned" references. Any non-scope object may be passed by "owned ref". This storage class might not be usable in @safe code without further restrictions. 3. GC-managed: the default storage class. Fairly self-explanatory. GC-managed references may not refer to "scope" or "owned" objects. Besides helping with the memory management issue, this design could also help tame the hairy mess of "auto ref"; "scope ref" can safely take any stack-allocated object, including temporaries, so a function could have "scope auto ref" parameters without needing to be a template function and with greater safety than "auto ref" currently provides.
Re: Is the compiler supposed to accept this?
On 07/10/2013 01:24 AM, Brian Schott wrote: While finishing up work on my parser and grammar specification I found this in container.d: return equal!(function(Elem a, Elem b) => !_less(a,b) && !_less(b,a)) (thisRange, thatRange); It seems to be some strange hybrid of the function literal syntax and the lambda syntax. =>... is supposed to be just a shorthand for { return ...; } It's not documented anywhere (surprise!) and I'm not sure if I should support it or file an accepts-invalid bug against DMD. I'd say support it and file a bug against the documentation.
Re: [OT] Why mobile web apps are slow
On Wed, Jul 10, 2013 at 01:01:01AM +0200, Adam D. Ruppe wrote: > On Tuesday, 9 July 2013 at 22:40:31 UTC, bearophile wrote: > >- A less allocating Phobos to produce a bit less garbage; > > Yes, and options to pass output ranges to more functions too, > instead of always returning gc allocated things. [...] +1. I think thus far we've only truly explored the input side of the range concept. We should do more with output ranges -- they are a lot more flexible than returning values (be that gc-allocated or not). You can bypass a lot of unnecessary buffering by doing that (think to!string and std.format, for example), which helps performance and reduces garbage for the GC. We should develop some good idioms for chaining / nesting output ranges, so that what is today a bunch of string appends, say, could be a UFCS-empowered chain of output ranges that basically writes the output directly to its destination instead of sitting around in strings or buffers, etc.. T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG
Re: Deimos Request: Add flac
On Tuesday, July 09, 2013 14:40:43 Walter Bright wrote: > Ok, I created a 1.2.1 branch. Thanks! - Jonathan M Davis
Re: access CTFE variables at compile time.
On Tuesday, 9 July 2013 at 22:49:38 UTC, JS wrote: It seems possible that we can print CTFE variables at compile time by using string mixes as the code below demonstrates. The problem is that we can not pass a variable to a template to create a print routine in the first place. e.g., we can't do mixin a!(s) if s is a string since s can't be read, supposedly, at compile time. I think there's been mention a couple times of a ctfeWrite function that can print values at compile-time, but so far nobody's implemented it.
Re: access CTFE variables at compile time.
Meta: I think there's been mention a couple times of a ctfeWrite function that can print values at compile-time, but so far nobody's implemented it. That's not true. This is the ER: http://d.puremagic.com/issues/show_bug.cgi?id=3952 And the patch: https://github.com/D-Programming-Language/dmd/pull/237 A significant problem with GitHub is that it's managed mostly as as a LIFO (last in first out), it means the last added patches get exposure, are discussed, and they often get added to the code. But if they are not merged in few weeks, they get out of radar and they get forgotten, and they rot for years. This is a significant problem for D development that so far doesn't have a solution. I don't remember Andrei or Walter every discussing about this problem or proposing solutions... Bye, bearophile
Re: Linear algebra for Win64?
On Tuesday, 9 July 2013 at 19:02:09 UTC, Kevin McTaggart wrote: Does anyone know of a good D linear algebra library for Win64? I tried scid a year ago and liked it on Win32, but have been unable to get it to link on Win64. When trying to run scid on Win64, I've been using prebuilt LAPACK 3.4.1 libraries from http://icl.cs.utk.edu/lapack-for-windows/lapack/, but have unresolved external symbol dgesv_ You can try this: /* 1. Create ABC.DEF with MS-NOTEPAD cut --- LIBRARY LIBLAPACK.DLL EXPORTS dgesv_ cut --- 2. Create ABC.LIB with MS-LIB "C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\Bin\amd64\lib.EXE" /DEF:ABC.DEF /MACHINE:X64 /OUT:ABC.LIB 3. Compile & link dmd -m64 test1.d ABC.lib 4. Run test1.exe The solution is -0.661082 9.456125 -16.014625 */ import std.stdio; extern(System) void dgesv_(const(int)* N, const(int)* nrhs, double* A, const(int)* lda, int* ipiv, double* b, const(int)* ldb, int* info); void main() { /* 3x3 matrix A * 76 25 11 * 27 89 51 * 18 60 32 */ double A[9] = [76, 27, 18, 25, 89, 60, 11, 51, 32]; double b[3] = [10, 7, 43]; int N = 3; int nrhs = 1; int lda = 3; int ipiv[3]; int ldb = 3; int info; dgesv_(&N, &nrhs, A.ptr, &lda, ipiv.ptr, b.ptr, &ldb, &info); if (info == 0) /* succeed */ writefln("The solution is %f %f %f", b[0], b[1], b[2]); else writefln("dgesv_ fails %d", info); }
Re: typeid(double) does not respect NaNs
On Tuesday, 9 July 2013 at 17:04:47 UTC, Jonathan M Davis wrote: On Tuesday, July 09, 2013 18:04:29 Maxim Fomin wrote: On Tuesday, 9 July 2013 at 13:46:48 UTC, H. S. Teoh wrote: > On Tue, Jul 09, 2013 at 08:05:35AM +0200, deadalnix wrote: >> On Tuesday, 9 July 2013 at 03:03:34 UTC, H. S. Teoh wrote: >> >More to the point, *if* typeinfo isn't meant to match == >> >for >> >whatever >> >reason, then why is it being used as the standard of >> >comparison for >> >AA keys? >> >> I guess we need NaN == NaN to be true for AA keys, no ? > > Not according to: > http://d.puremagic.com/issues/show_bug.cgi?id=7836 > > So, should NaN == NaN for AA keys, or not? > > > T I think it was not decided yet. From language coherency point of view NaN != NaN like in general case, from usefulness perspective you don't need several nans in AA array. I'd think that having NaN != NaN would cause serious problems with retrieving any elements inserted with NaN as a key, but given how floating point values work, using them as the key for an AA is arguably completely broken to begin with as comparing floating point values for equality is generally just plain wrong. That being the case, I'd argue in favor of language consistency and just point out to anyone that runs into problems that using a floating point type as the key type of an AA is a stupid thing to do to begin with. - Jonathan M Davis That what I meant, and you explained it much better.
Re: Current version of D.
On Tuesday, 9 July 2013 at 22:53:08 UTC, Rob T wrote: I did a full removal, and install of latest version as of today downloaded from here: http://dlang.org/download.html dmd_2.063-0_amd64.deb The version on download page is showing 2.063-0, and so does the deb file name, and also the installation process shows 2.063-0 was installed. Running compiler shows DMD64 D Compiler v2.063 Something has gone wrong somewhere. --rt The download page has the wrong link, it doesn't seem to have been updated for 2.063.2. Can just manually add a .2 at the end, such as http://downloads.dlang.org/releases/2013/dmd.2.063.2.zip
Re: access CTFE variables at compile time.
On Wednesday, 10 July 2013 at 01:10:37 UTC, Meta wrote: On Tuesday, 9 July 2013 at 22:49:38 UTC, JS wrote: It seems possible that we can print CTFE variables at compile time by using string mixes as the code below demonstrates. The problem is that we can not pass a variable to a template to create a print routine in the first place. e.g., we can't do mixin a!(s) if s is a string since s can't be read, supposedly, at compile time. I think there's been mention a couple times of a ctfeWrite function that can print values at compile-time, but so far nobody's implemented it. I've heard of this too and even tried __ctfeWrite and it worked!! Well, at least no compile time error... just didn't print anything. I believe the error "variable can't be read at compile time" is due to the fact that the compiler doesn't have access to/isn't aware of the frame pointers(the stack) of the functions. This means that "local" variables can't be used in compile time, before ctfe, constructs because there is no way to get at the data. This seems like a limitation of the system and not some innate reason why it should fail...
Re: access CTFE variables at compile time.
On Wednesday, July 10, 2013 06:24:02 JS wrote: > On Wednesday, 10 July 2013 at 01:10:37 UTC, Meta wrote: > > On Tuesday, 9 July 2013 at 22:49:38 UTC, JS wrote: > >> It seems possible that we can print CTFE variables at compile > >> time by using string mixes as the code below demonstrates. > >> > >> The problem is that we can not pass a variable to a template > >> to create a print routine in the first place. e.g., we can't > >> do mixin a!(s) if s is a string since s can't be read, > >> supposedly, at compile time. > > > > I think there's been mention a couple times of a ctfeWrite > > function that can print values at compile-time, but so far > > nobody's implemented it. > > I've heard of this too and even tried __ctfeWrite and it worked!! > Well, at least no compile time error... just didn't print > anything. > > I believe the error "variable can't be read at compile time" is > due to the fact that the compiler doesn't have access to/isn't > aware of the frame pointers(the stack) of the functions. This > means that "local" variables can't be used in compile time, > before ctfe, constructs because there is no way to get at the > data. > > This seems like a limitation of the system and not some innate > reason why it should fail... Making it work would be like trying to make an if function as a static if. It would muddle things considerably and as such is a very bad idea IMHO. Right now, there is a very clean distinction between what's done at compile time and what's done at runtime as well as between CTFE and templated code. Allowing what you're trying to do would ruin that. - Jonathan M Davis
Re: A thread-safe weak reference implementation
What race condition do you have in the constructor? Declare _object field shared and cast it less.
Re: Current version of D.
On Wed, Jul 10, 2013 at 06:15:08AM +0200, Kapps wrote: [...] > The download page has the wrong link, it doesn't seem to have been > updated for 2.063.2. Can just manually add a .2 at the end, such as > http://downloads.dlang.org/releases/2013/dmd.2.063.2.zip This sounds pretty serious. Can somebody who has access please fix this ASAP? We don't want our users to think they're getting 2.063.2 but actually it's still 2.063. T -- They say that "guns don't kill people, people kill people." Well I think the gun helps. If you just stood there and yelled BANG, I don't think you'd kill too many people. -- Eddie Izzard, Dressed to Kill
Re: Memory management design
Do you know this pull? https://github.com/D-Programming-Language/dmd/pull/1903