Re: My first email to Walter, ever
On Sunday, 7 July 2013 at 12:27:02 UTC, Peter Alexander wrote:
:-(
template allSatisfy(alias F, T...)
{
static if (T.length == 0)
{
enum allSatisfy = true;
}
else static if (T.length == 1)
{
enum allSatisfy = F!(T[0]);
}
else
{
enum allSatisfy =
allSatisfy!(F, T[ 0 .. $/2])
allSatisfy!(F, T[$/2 .. $ ]);
}
}
It's deplhi-style
http://www.freepascal.org/docs-html/ref/refse77.html#x155-16500014.3
Re: A very basic blog about D
On Sunday, 7 July 2013 at 15:00:43 UTC, John Colvin wrote: I had some free time so I decided I should start a simple blog about D, implementing some unix utilities. I've (unsurprisingly) started with echo. http://foreach-hour-life.blogspot.co.uk/ It's nothing ground-breaking, but every little helps :) Seeing as most of the traffic I'm getting is from this thread, I thought it might be interesting for people to see some stats about where people are from, what browsers they're using etc. https://dl.dropboxusercontent.com/u/910836/Webstats_02072013-10_09072013-09.png A lot of windows users, although that's skewed by people browsing from work. I hope that accounts for the IE contingent as well!
Re: NDC Oslo talk: Generic Programming Galore Using D
On 7/8/13 10:03 AM, Andrei Alexandrescu wrote: On 7/8/13 6:49 AM, Dicebot wrote: On Thursday, 4 July 2013 at 16:47:36 UTC, Andrei Alexandrescu wrote: Videos for my two NDC 2013 talks are now online. Generic Programming Galore using D at http://vimeo.com/68378925 and the HipHop Virtual Machine at http://vimeo.com/68383350. Andrei Am I allowed to re-upload them to YouTube? I don't know, let me ask. Andrei I got permission. Videos can be uploaded to youtube as long as NDC Oslo 2013 is mentioned. Andrei
Re: Is this D or is it Javascript?
On Saturday, 6 July 2013 at 00:21:54 UTC, Adam D. Ruppe wrote: // the second () is just because @property is broken writeln(Math.max()(12, 24)); // prints 24 With dynamic typing there's no way to tell if Math.max(12,24) is a method call or field delegate call. Javascript assumes it's member call and passes this pointer to the called function. When I implemented an object for javascript, I chose to detect if a called method is a field with delegate and forward the call to the delegate as per semantics of javascript.
Re: Is this D or is it Javascript?
On Tuesday, 9 July 2013 at 19:14:30 UTC, Kagamin wrote: With dynamic typing there's no way to tell if Math.max(12,24) is a method call or field delegate call. The way my thing works is Math.max (or anything else) returns a ref var, and the (12,24) does opCall on it, which succeeds if the var is of type function. bearophile recently posted a pull request by Kenji Hara IIRC that implements @property more correctly. If that gets pulled, this will be good. In the little scripting language too, there's now a class declaration, that looks kinda like D, but it is actually just syntax sugar that assigns the declarations to the object, so there is no distinction there between a method and field - all methods are just delegates attached to the object.
Re: Programming in D book is about 88% translated
On 06/29/2013 01:08 AM, Johannes Pfau wrote: BTW: The link to wiki4d on this page http://ddili.org/ders/d.en/intro.html could be updated to http://wiki.dlang.org/Editors and / or http://wiki.dlang.org/IDEs Done. Additionally, thanks to Jerome Sniatecki, I made the Ranges chapter const-correct and applied UFCS to code examples: http://ddili.org/ders/d.en/ranges.html Thank you: http://ddili.org/ders/d.en/acknowledgments.html Ali
Re: Situation of scope?
On Tuesday, 9 July 2013 at 00:49:40 UTC, bearophile wrote: What is the situation regarding the implementation of scope in D, Walter? Are there some implementation difficulties that make it hard to implement? It require to define lifetime of basically everything. This is a difficult task to both implement and define (probably defining is the hardest part). Consider temporary for instance, defining their lifetime is quite difficult especially since their creation can be conditional.
Re: typeid(double) does not respect NaNs
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 ?
Re: Feature request: Path append operators for strings
On Monday, 8 July 2013 at 21:46:24 UTC, Walter Bright wrote: I'm sure you're self-aware, as I'm sure Siri and Watson are not. But there is no way for you to prove to me that you are self-aware. It could be that you are simply programmed to appear to be self-aware; think of an infinite loop containing a massive switch statement, where each case represents a different situation in life and the function to execute in each case represents what you did in that situation in life. As long as we can't test whether and entity is self-aware or not, for our purposes, it kind of doesn't matter whether it is or not. If we ever are able to define what consciousness is (and I'm quite sure we will), I suspect it's going to be some kind of a continuous feedback loop from sensory data to brain, and from brain to muscles and through them back to sensory data again. Consciousness would be kind of your ability to predict what kind of sensory data would be likely to be produced if you sent a certain set of signals to your muscles. I like this guy's take on consciousness: http://www.youtube.com/watch?v=3jBUtKYRxnA
Re: Feature request: Path append operators for strings
On Tuesday, 9 July 2013 at 06:07:12 UTC, Tommi wrote: Consciousness would be kind of your ability to predict what kind of sensory data would be likely to be produced if you sent a certain set of signals to your muscles. ...and the better you are at predicting those very-near-future sensory signals, the more you feel that you're conscious.
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_detailpagev=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 destructiona...@gmail.com 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 john.loughran.col...@gmail.com 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_detailpagev=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 flamaros.xav...@gmail.com 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 marco.le...@gmx.de 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 pj...@progtools.org 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 pj...@progtools.org 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: GitHub behind proxy servers among other questions
On Monday, 8 July 2013 at 19:57:52 UTC, JohnnyK wrote: On Monday, 8 July 2013 at 19:37:08 UTC, JohnnyK wrote: Another thing about GitHub's Download Zip button and this process as a whole. While the Download Zip button does allow you to download the master folders with recursive directories I do find it somewhat cumbersome or should I say awkward since you have to extract these in their correct locations upon download. This is not good when you are trying to follow someones instructions on how to download, build, and install their wares. I just don't get git? Just compile the code and put a binary up there for people to use. If I want to contribute to the code base then I will I guess go through all this hassle but for those of us not smart enough to contribute and just want to use it show me the binary please. In the amount of time it is taking to get this stuff I could have made major strides at building my own. Also I don't know what this fragmented downloading is going to do in the future when I want an updated version of the software. Please remember many of us are simpletons and don't use all these fancy version control systems and just need the binary so that we can use it. I guess you could say we are your customers and not your contributors. Please everyone in the D community try and follow the KISS methodology and if you do I bet you could get many more users of your wares and not people banging their heads until they give up. Yeah I was only 2 clicks away from giving up on this whole D thing thinking it was just too darned hard to make it worth my while. Who knows I still may give up since I have not attempted to compile it yet. I think I will wait until tomorrow before I try to tackle that part of the destruction's. For now I think I have it downloaded. BTW did I mention that I really hate git and compiling other people's code just to use an edit box and button on a dialog??? Ar you talking about D specifically? You *can* just download the package you know: http://dlang.org/download.html I'm actually wondering how you even reached git?
Re: GitHub behind proxy servers among other questions
On Monday, 8 July 2013 at 19:20:46 UTC, John Colvin wrote: I don't see how it is problematic? The firewall doesn't allow a particular type of connection, so you cache the result somewhere else and then access it via something that is allowed. It's the same as downloading the zip file from github, only you're doing the zipping yourself, then using scp to do the download instead of http. Is it common to have ssh connections banned in the IT policy but *not* blocked by the firewall? I'm just saying that maybe the firwall is blocking that protocol on purpose? Github can very easily be seen as File Sharing and/or Online Storage. The sole act of downloading/uploading anything on there is possible violations of policy. You could download viruses, or be stealing your company's code to publish it online. Even if you *can* download the zip via http, it doesn't mean you are actually allowed to. If your company's firewall doesn't block a porn site, does that means its OK to surf it? Now, most companies wouldn't really care that much about it, if you connect every now and then, no one will care. Worst case scenario, you'll get a reminder not to download/upload crap on internet. But, if you start doing all this via ssh, or other alternative routes, then you are *activelly* bypassing protections, and in particular, doing something you *know* you shouldn't be doing. That's a more serious offense. Now, do what you want. I'm just saying before going it and deploying such tools to download the files on git, please make sure you aren't violating your company's policies.
Needing help with basic HTTP requests..
Hi guys,
I've only been trying to learn D for a short while, and compared
to the other more popular programming languages, I've been able
to find very little helpful and updated documentation or
tutorials on it.
I basically need help getting data from a website, just the HTML
of a webpage, in this case a PHP page. I'm using the following
code which compiles fine, but when run it just encounters a
'Socket.ERROR' with a value of -1.
I'm not sure what I'm doing wrong, but any help or suggestions
would be appreciated. As I said, I'm quite new to D...
---
//readData.d
module main;
import std.stdio;
import std.socket;
import std.cstream;
int main(string[] args)
{
string host = www.dprogramming.com;
ushort port = 80;
Socket listener = new TcpSocket;
assert(listener.isAlive);
listener.blocking = false;
listener.connect(new InternetAddress(host, port));
char[] msg;
char[] req = cast(char[]) GET /internet.php HTTP/1.1\r\nHost:
www.dprogramming.com\r\n\r\n;
listener.send(req);
while (1)
{
int bytes;
char[1024] buf;
bytes = listener.receive(buf);
if (Socket.ERROR == bytes)
{
writeln(Connection Error , Socket.ERROR);
listener.close();
din.readLine();
return 1;
}
else if (0 == bytes)
{
try
{
writeln(Connection to target lost.);
}
catch (SocketException)
{
writeln(Connection closed.);
}
listener.close();
din.readLine();
return 1;
}
else
{
writeln(Recieved , bytes, bytes from ,
listener.remoteAddress().toString(), : \, buf[0 .. bytes],
\);
}
}
}
---
- Alex.
lambdas and function literals in classes
JS asked about this in the main group, but here is more
appropriate and I'm quite interested myself.
Can someone explain the rationale behind this:
class A
{
auto a = (){}; //Lambda not allowed
auto b = function(){}; //Function allowed
auto c = delegate(){}; //Delegate not allowed
}
A guess:
Delegate's aren't allowed as members due their context pointer
(why???), lambdas are assumed to be delegates unless they are
proved to not need context (and dmd is sucking at proving that).
Re: lambdas and function literals in classes
On Tuesday, 9 July 2013 at 10:50:02 UTC, John Colvin wrote:
JS asked about this in the main group, but here is more
appropriate and I'm quite interested myself.
Can someone explain the rationale behind this:
class A
{
auto a = (){}; //Lambda not allowed
auto b = function(){}; //Function allowed
auto c = delegate(){}; //Delegate not allowed
}
A guess:
Delegate's aren't allowed as members due their context pointer
(why???), lambdas are assumed to be delegates unless they are
proved to not need context (and dmd is sucking at proving that).
Error message is actually misleading here, because this compiles:
class A
{
void delegate() a;
}
void main()
{
auto a = new A();
a.a = () {};
}
So this has something to do with _initialization_ of class
members with delegates/lambdas, not their very existence.
Re: lambdas and function literals in classes
Dicebot:
So this has something to do with _initialization_ of class
members with delegates/lambdas, not their very existence.
So is it worth adding this diagnostic bug report in Bugzilla?
class Foo {
void delegate() dg1;
void delegate() dg2 = delegate(){};
this() {
this.dg1 = (){};
}
}
void main() {
auto f = new Foo;
}
DMD 2.064alpha gives:
temp.d(3): Error: delegate temp.Foo.__dgliteral1 function
literals cannot be class members
temp.d(3): Error: cannot implicitly convert expression
(__dgliteral1) of type _error_ delegate() to void delegate()
Bye,
bearophile
Re: Needing help with basic HTTP requests..
On Tuesday, 9 July 2013 at 09:03:32 UTC, AlexMcP wrote: writeln(Connection Error , Socket.ERROR); First tip: Socket.ERROR is a constant, so printing it doesn't help much (as you probably noticed). More helpful is the function lastSocketError(), which returns a string with some details. writeln(Connection Error , Socket.ERROR, , lastSocketError()); Which tells you: Connection Error -1 Resource temporarily unavailable The reason that is an error is because you turned off blocking. listener.blocking = false; So, since the connection hasn't had a chance to get established and transfer data yet, instead of waiting for it to finish when you called receive, it returned the error telling you to try again later. The simplest thing to do here is to comment out that blocking = false line, letting receive just wait until data is available. Another option is to use Socket.select to notify you when data is available, and only receive then. After that, make sure the req literal is all on one line to avoid http 400 errors (not sure if that was a result of copy/paste or not, probably) and you should get a response. Another note: casting a string literal to char[] is usually a bad idea, because you can't write to them anyway. Best to just leave them typed as string. It should all still work the same after doing that. Finally, if you want a higher level library to do this, check out std.net.curl: http://dlang.org/phobos/std_net_curl.html
Re: Needing help with basic HTTP requests..
BTW I also wrote a more complete lower level implementation too: https://github.com/adamdruppe/misc-stuff-including-D-programming-language-web-stuff/blob/master/http.d My code is kinda ugly, but might be useful to refer to too. http has some other features you'll need to think about, like chunked data transfer, to have a more complete implementation, and I have some openssl code in there too. Of course, curl takes care of all this too.
