Re: DConf 2013 official car/room sharing thread
"Andrei Alexandrescu" wrote in message news:kk6llv$29sl$1...@digitalmars.com... I'll stay at Aloft (http://goo.gl/CHmzw) and will drive a compact rental. Will gladly pick up people to and fro that hotel. Andrei Hey Andrei, you still got room in your car? I'm thinking of staying at a hotel nearby. (Aloft is full.) Lio.
Re: DIP 36: Rvalue References
On Sunday, 21 April 2013 at 02:13:54 UTC, Manu wrote: This DIP is actually likely to solve an important source of problems, consider: void func(const ref matrix m); func(x.getMatrix()); // compile error! // fu*^&%$ing hell! you piece of &%^#≈¿$! // ... matrix temp = x.getMatrix(); func(temp); // no more compile error! (but equally unsafe/dangerous) It's hard to fully understand this example without getMatrix() defined, and why func() is unsafe (does it escape the reference?). Help! definition: matrix getMatrix(T x); // this is all you know That's the point of the example. You _don't know_ if func() is unsafe, does it escape the reference? But you need to pass a temp anyway, you have no bearing on whether you should just hack it to work, or reconsider the problem. And when 99 times out of 100, the correct answer is 'hack it to work', you're basically asking for a spectacular bug in that other 1% of cases. Yeah, that's kind of what I meant when I said it's a two-for-one deal. You get to pass temps, and you get safety checking too.
Re: DIP 36: Rvalue References
On Sunday, 21 April 2013 at 02:13:54 UTC, Manu wrote: definition: matrix getMatrix(T x); // this is all you know That's the point of the example. You _don't know_ if func() is unsafe, does it escape the reference? But you need to pass a temp anyway, you have no bearing on whether you should just hack it to work, or reconsider the problem. And when 99 times out of 100, the correct answer is 'hack it to work', you're basically asking for a spectacular bug in that other 1% of cases. If that is your concern then the DIP36 is a very bad answer to it : - It require extra anotation, which wont be added most of the time. - It is inferior, and impair the introduction of lifetime. This isn't even discussed.
Re: DIP 36: Rvalue References
On 21 April 2013 11:36, Zach the Mystic wrote: > On Sunday, 21 April 2013 at 00:51:31 UTC, Manu wrote: > >> That's not what scope does. Scope promises that the variables will not >> escape the scope. And as such, just happens to make passing a temporary by >> ref safe. >> It does not implement r-value ref's. It simply allows refs to temporaries >> to be considered a safe operation. >> > > It's a two-fer! (2 for 1 deal) > > > This DIP is actually likely to solve an important source of problems, >> consider: >> >> void func(const ref matrix m); >> >> >> func(x.getMatrix()); // compile error! >> >> // fu*^&%$ing hell! you piece of &%^#≈¿$! >> // ... >> >> matrix temp = x.getMatrix(); >> func(temp); // no more compile error! (but equally unsafe/dangerous) >> > > It's hard to fully understand this example without getMatrix() defined, > and why func() is unsafe (does it escape the reference?). Help! definition: matrix getMatrix(T x); // this is all you know That's the point of the example. You _don't know_ if func() is unsafe, does it escape the reference? But you need to pass a temp anyway, you have no bearing on whether you should just hack it to work, or reconsider the problem. And when 99 times out of 100, the correct answer is 'hack it to work', you're basically asking for a spectacular bug in that other 1% of cases. >> In my experience showing D to new people, this is the #1 complaint. It's >> the first one that comes up, every time (which really doesn't help with >> first impressions), and I'm fairly sure every single person I've >> introduced >> to D has complained about this. >> It's kind of embarrassing when I'm saying that D is really cool, and then >> I >> have to start making excuses and apologising for this, and assure them >> that >> it's a known issue, and it'll be fixed one day. >> > > Yikes. >
Re: DIP 36: Rvalue References
On Sunday, 21 April 2013 at 00:51:31 UTC, Manu wrote: That's not what scope does. Scope promises that the variables will not escape the scope. And as such, just happens to make passing a temporary by ref safe. It does not implement r-value ref's. It simply allows refs to temporaries to be considered a safe operation. It's a two-fer! (2 for 1 deal) This DIP is actually likely to solve an important source of problems, consider: void func(const ref matrix m); func(x.getMatrix()); // compile error! // fu*^&%$ing hell! you piece of &%^#≈¿$! // ... matrix temp = x.getMatrix(); func(temp); // no more compile error! (but equally unsafe/dangerous) It's hard to fully understand this example without getMatrix() defined, and why func() is unsafe (does it escape the reference?). Help! In my experience showing D to new people, this is the #1 complaint. It's the first one that comes up, every time (which really doesn't help with first impressions), and I'm fairly sure every single person I've introduced to D has complained about this. It's kind of embarrassing when I'm saying that D is really cool, and then I have to start making excuses and apologising for this, and assure them that it's a known issue, and it'll be fixed one day. Yikes.
Re: DIP 36: Rvalue References
On Saturday, 20 April 2013 at 18:00:50 UTC, Namespace wrote: The fact is, there's much more to any change than simply implementing it. Changes break unexpected things. There are always extra corner cases not considered. There are always bugs and inconsistencies. Could be, but I don't see what could be broken by this DIP. All contingencies are listed also in the DIP (and that are not many). And it passed all tests what is crucial. The DIP for instance, consider that const scope ref is semantically equivalent to pass by value, when it isn't (and not only for performance reasons, but for aliasing reasons). Nothing is considered about it.
Re: DIP 36: Rvalue References
On 21 April 2013 06:51, Timon Gehr wrote: > On 04/20/2013 05:56 PM, Dicebot wrote: > >> You miss quite an important point - DIP36 does not add new feature. It >> partially defines existing feature (scope) to replace an existing but >> broken solution (auto ref). Nothing new is really added to the language, >> only existing stuff better defined. >> > > _New meaning_ is assigned to existing grammar whose original purpose is at > most loosely related to the _new_ features. > > I do not think that making 'scope' indicate an rvalue reference is > particularly future proof. > That's not what scope does. Scope promises that the variables will not escape the scope. And as such, just happens to make passing a temporary by ref safe. It does not implement r-value ref's. It simply allows refs to temporaries to be considered a safe operation. This DIP is actually likely to solve an important source of problems, consider: void func(const ref matrix m); func(x.getMatrix()); // compile error! // fu*^&%$ing hell! you piece of &%^#≈¿$! // ... matrix temp = x.getMatrix(); func(temp); // no more compile error! (but equally unsafe/dangerous) In this example, the 'solution', which is what everybody does right now, is exactly as unsafe as the attempted call with the r-value. ref, as in the language right now, is a fundamentally unsafe operation... and not only is it technically unsafe, a programmer can't even know if it is practically unsafe or not. Since they have a habit of using this hack, they may unknowingly use it in a call site where it's not *practically* safe to do it. They can't know, and by habit (and frustration) they're trained to use this hack everywhere. With 'scope ref' (or 'in ref'), the programmer now has a guide to say whether it's safe to pass a temporary or not. In the future, if the function does not receive scope ref, perhaps the programmer will start to presume that it is NOT safe to pass a temporary, and stop doing so via the current local-variable hack. scope was always intended to implement this promise as far as I'm lead to believe(?). In my experience showing D to new people, this is the #1 complaint. It's the first one that comes up, every time (which really doesn't help with first impressions), and I'm fairly sure every single person I've introduced to D has complained about this. It's kind of embarrassing when I'm saying that D is really cool, and then I have to start making excuses and apologising for this, and assure them that it's a known issue, and it'll be fixed one day.
Re: DIP 36: Rvalue References
On Saturday, 20 April 2013 at 14:42:57 UTC, Namespace wrote: That is true, but it makes the impression that, with the exception of Kenji, none of the core developers is interested in a solution to this problem. I don't think that's true. The DIP was not much discussed and the pull request is regularly overlooked / ignored. Patience! Also in the discussion on the pull request no comments for Walter or Andrei are found. Although the pull is complete and has passed all the tests and would be ready to merge. Also this thread is completely ignored even though both write in this forum regularly and participate in other discussions. To me this makes the impression that they were not interested in this problem (or in our solution to the problem). Either they want the problem does not solve or try to solve it in their own way and that can take a very long time. At least an annotation what of both is the case or if I see it completely wrong, would be polite. But someone besides me would need to evaluate both DIP 35 & 36 to see if there were any real conflicts there. Yes that would be good. I think you've done a good job with the feature and the presentation. But I personally don't feel like it's my job to rush D's development. Part of the reason is that D is already way ahead of most if not all of the competition in terms of sheer language design. When you extend into unknown territory, it's sometimes wise just to stay where you are for a bit, to give yourself time to adapt and build up a foundation. I don't think your work will go unnoticed or unappreciated. Most of the time when people don't get back to you, it's because they're busy with other things. Probably the best thing you can do is say, well, my work on this feature is done, what else can I improve around here? This feature and this issue won't go away, IMO.
Re: dbghelp in wine
On Friday, 19 April 2013 at 20:40:58 UTC, Rémy Mouëza wrote: On 04/19/2013 03:51 AM, James Wirth wrote: Yes - I realize developing D for MS via Wine is "crazy" - its a long story. I have a question related to that use of Wine: did you considered using a cross compiler like mingw-gcc and if so what were the advantages of wine over it? Would rather use MS-W version of D to write D application for MS-W. When I get another MS-BOX can then develop directly on it. Windows DMD works pretty good under Wine.
Re: using readf in D
"Chris Cain" Wrote in message:
> On Saturday, 20 April 2013 at 12:52:30 UTC, Carlos wrote:
>> Hi guys! I'm writing a little program in D from another version
>> I did for my homework written in C. But it doesn't work very
>> well. First it takes two reads for the first input from the
>> user and second it only calculates tcsleep.
>>
>> Here is the code:
>>
>> import std.stdio;
>> import std.c.stdlib;
>> void main()
>> {
>> immutable sitc = 1.66;
>> immutable sleepc = 1.08;
>> float tcsleep, tcsit, tc;
>> int minsleep, minsit;
>> write("Input number of minutes sleep : \n");
>> readf("%d ", &minsleep);
>>
>> write("Input number of minutes sitting : \n");
>> readf("%d ", &minsit);
>>
>> write("Thanks!\n");
>> tcsleep = minsit*sitc;
>> tcsit = minsleep*sleepc;
>> tc = tcsleep+tcsit;
>> writeln("Your total calories is : ", tc);
>> exit (0);
>> }
>
> First off, great on you for rewriting an old assignment in a new
> language. That's one of the better ways I've found to learn new
> languages (and I learn new languages all the time) because it
> allows you to focus on the new language and how you might use
> that language rather than solving the problem at hand.
>
> Second, this probably should be in D.learn (if I don't say it,
> someone else will).
> http://forum.dlang.org/group/digitalmars.D.learn if you're using
> the web interface.
>
> Third, "exit(0)" is redundant in D. It'll exit with code 0 as
> long as execution terminates normally (i.e., no exceptions
> thrown).
>
> Finally, what "doesn't work very well"? Without more information,
> I don't think anyone will be able to help you.
>
> Take care.
>
as soon as I saw readf I knew what was wrong.
its a pretty common issue.
--
sigh...
Android NewsGroup Reader
http://www.piaohong.tk/newsgroup
Re: Official D Grammar
On 04/20/2013 08:36 PM, Walter Bright wrote: On 4/9/2013 3:20 AM, Bruno Medeiros wrote: A bit more annoying is the case with the extern declaration, with the C++ parameter: extern(C++) here you have to look at a special identifier (the C, D, PASCAL part) and see if there is a ++ token ahead, it's a bit more of special-casing in the parser. Here I think it would have been better to change the the language itself and use "CPP" instead of "C++". A minor simplification. I think the special case is worth it. Without doubt.
Re: DIP 36: Rvalue References
On 04/20/2013 07:34 PM, Minas Mina wrote: ... I thought D was driven by its community. (This is its community.)
Re: DIP 36: Rvalue References
On 04/20/2013 05:56 PM, Dicebot wrote: You miss quite an important point - DIP36 does not add new feature. It partially defines existing feature (scope) to replace an existing but broken solution (auto ref). Nothing new is really added to the language, only existing stuff better defined. _New meaning_ is assigned to existing grammar whose original purpose is at most loosely related to the _new_ features. I do not think that making 'scope' indicate an rvalue reference is particularly future proof.
Re: D compile time algorithms implementation
On 4/20/2013 2:27 AM, Peter Alexander wrote: If possible, could you file an enhancement request? It would also be great if you could add your improvement as a pull request on github! http://d.puremagic.com/issues/enter_bug.cgi?product=D https://github.com/D-Programming-Language/phobos Yes, please do so.
Re: Attribute inference for auto functions?
On 4/20/13, Walter Bright wrote: > What I've been trying to explain is that there's a difference between a > storage > class attribute and a type constructor. I've mentioned this before, but we need a good definition of these on dlang.org (for example people coming from other languages like Python will have no idea what these mean). Last time I mentioned it I didn't file a bug, but now I have: http://d.puremagic.com/issues/show_bug.cgi?id=9970 Hopefully someone with more knowledge of these can write some documentation.
Re: Official D Grammar
On 4/9/2013 3:20 AM, Bruno Medeiros wrote: A bit more annoying is the case with the extern declaration, with the C++ parameter: extern(C++) here you have to look at a special identifier (the C, D, PASCAL part) and see if there is a ++ token ahead, it's a bit more of special-casing in the parser. Here I think it would have been better to change the the language itself and use "CPP" instead of "C++". A minor simplification. I think the special case is worth it.
Re: Attribute inference for auto functions?
On 4/20/2013 1:50 AM, Mehrdad wrote: On Saturday, 20 April 2013 at 06:25:09 UTC, Walter Bright wrote: On 4/19/2013 11:12 PM, deadalnix wrote: But some time, you can't alias (in case of inference for instance) and so can't choose what attribute bind to. Example, please. Here you go: void foo(T)(extern(C) T function() function() f); Try making the extern(C) apply to each of: 1. the result of f() 2. the result of f()() without breaking foo()'s type inference. What I've been trying to explain is that there's a difference between a storage class attribute and a type constructor. When pure, for example, is used as a storage class attribute, it applies to the declaration always. When pure is used as a type constructor, it applies to the type, always. There is no ambiguity about this, and no problem about choice. For your example, for purity: void foo(T)(T function() pure function() pure f); The only issue here is that extern(C) is not currently supported as a type constructor. If it were, the example would look like: void foo(T)(T function() extern(C) function() extern(C) f); Again, there is no ambiguity.
Re: DIP 36: Rvalue References
How about "on hold"? (Not that I have any say in it at all) As long as it is implemented in the near future and we must not wait another year (not even a half) it is ok. But the fact is, that we don't know what state it has, because we get no response. The fact is, there's much more to any change than simply implementing it. Changes break unexpected things. There are always extra corner cases not considered. There are always bugs and inconsistencies. Could be, but I don't see what could be broken by this DIP. All contingencies are listed also in the DIP (and that are not many). And it passed all tests what is crucial. Although it's great that you and some others have done the legwork to implement this proposal, it may have to wait until other more urgent problems have been fixed. Could be, but I don't know why. Which other fix is necessary for this pull? But also this would be ok, as long as we know, _which_ problems must be fixed.
Re: DIP 36: Rvalue References
On Saturday, 20 April 2013 at 16:11:49 UTC, Namespace wrote: Sadly, I have to agree on this. As nice as many new feature ideas are, they are far from priorities when there are multiple core mechanics that are broken. There is no reason to prioritize DIP 36. Kenji, Dicebot and I did most of the work. The DIP is written and all necessary information are described in detail there with examples. The code also exists and there is even a pull request which has passed all the tests. Thus, this proposal is linked with not much work. Most of it was taken over by others. Due to this, it really is not asking too much to get a note if this pull is accepted or rejected. Of course, with detailed justification. How about "on hold"? (Not that I have any say in it at all) The fact is, there's much more to any change than simply implementing it. Changes break unexpected things. There are always extra corner cases not considered. There are always bugs and inconsistencies. Although it's great that you and some others have done the legwork to implement this proposal, it may have to wait until other more urgent problems have been fixed.
Re: DIP 36: Rvalue References
On Saturday, 20 April 2013 at 15:23:35 UTC, deadalnix wrote: On Saturday, 20 April 2013 at 15:17:39 UTC, Namespace wrote: I don't think adding more to the language is the sane thing to do right now. Why not? Could you explain this? This issue is discussed since more than a year and it is a very annoying issue. And even if Walter and Andrei are of this opinion, it would still only polite when they explain in detail why they think this. Listen, this issue is very real, but it is mostly about performance. I'll tell you something : the best performance improvement is the one that bring your program from non working state to working one. And right now, many existing feature are broken. The let's add whatever feature we have in mind is the very cause of the state of the language right now. I thought D was driven by its community.
Re: Official D Grammar
20-Apr-2013 12:31, Brian Schott пишет: I've moved my work on the grammar to the following location on Github: https://github.com/Hackerpilot/DGrammar This uses ANTLR, as the other parser generators can't handle D's grammar. Great. IMHO ANTLR is one of the sanest. > Several rules from the official grammar were removed, and several others were added (Such as an actual rule for a function declaration...) I also tried to fix any inacuracies or omissions I came across in the online documentation. Comments, issues, and pull requests welcome. Bookmarked for now ;) -- Dmitry Olshansky
Re: DIP 36: Rvalue References
Sadly, I have to agree on this. As nice as many new feature ideas are, they are far from priorities when there are multiple core mechanics that are broken. There is no reason to prioritize DIP 36. Kenji, Dicebot and I did most of the work. The DIP is written and all necessary information are described in detail there with examples. The code also exists and there is even a pull request which has passed all the tests. Thus, this proposal is linked with not much work. Most of it was taken over by others. Due to this, it really is not asking too much to get a note if this pull is accepted or rejected. Of course, with detailed justification.
Re: DIP 36: Rvalue References
You miss quite an important point - DIP36 does not add new feature. It partially defines existing feature (scope) to replace an existing but broken solution (auto ref). Nothing new is really added to the language, only existing stuff better defined.
Re: DIP 36: Rvalue References
On Saturday, 20 April 2013 at 15:39:42 UTC, Namespace wrote: Listen, this issue is very real, but it is mostly about performance. I'll tell you something : the best performance improvement is the one that bring your program from non working state to working one. And right now, many existing feature are broken. The let's add whatever feature we have in mind is the very cause of the state of the language right now. As far as I remember, you were in favor of the introduction of the feature "attribute inference for auto functions". Also a new feature but none that would solve problems which are discussed since more than a year. Half of the standard lib is broken because it is annotated incorrectly. Furthermore this issue should be solved with the introduction of "auto ref" (AFAIK introduced with dmd 2.035?). So this is not like "add whatever feature" but rather "fix an issue, that is often discussed and annoys many people". DIP36 discuss the addition of new features.
Re: DIP 36: Rvalue References
On Saturday, 20 April 2013 at 15:23:35 UTC, deadalnix wrote: On Saturday, 20 April 2013 at 15:17:39 UTC, Namespace wrote: I don't think adding more to the language is the sane thing to do right now. Why not? Could you explain this? This issue is discussed since more than a year and it is a very annoying issue. And even if Walter and Andrei are of this opinion, it would still only polite when they explain in detail why they think this. Listen, this issue is very real, but it is mostly about performance. I'll tell you something : the best performance improvement is the one that bring your program from non working state to working one. And right now, many existing feature are broken. The let's add whatever feature we have in mind is the very cause of the state of the language right now. Sadly, I have to agree on this. As nice as many new feature ideas are, they are far from priorities when there are multiple core mechanics that are broken.
Re: DIP 36: Rvalue References
Listen, this issue is very real, but it is mostly about performance. I'll tell you something : the best performance improvement is the one that bring your program from non working state to working one. And right now, many existing feature are broken. The let's add whatever feature we have in mind is the very cause of the state of the language right now. As far as I remember, you were in favor of the introduction of the feature "attribute inference for auto functions". Also a new feature but none that would solve problems which are discussed since more than a year. Furthermore this issue should be solved with the introduction of "auto ref" (AFAIK introduced with dmd 2.035?). So this is not like "add whatever feature" but rather "fix an issue, that is often discussed and annoys many people".
Re: DIP 36: Rvalue References
On Saturday, 20 April 2013 at 15:17:39 UTC, Namespace wrote: I don't think adding more to the language is the sane thing to do right now. Why not? Could you explain this? This issue is discussed since more than a year and it is a very annoying issue. And even if Walter and Andrei are of this opinion, it would still only polite when they explain in detail why they think this. Listen, this issue is very real, but it is mostly about performance. I'll tell you something : the best performance improvement is the one that bring your program from non working state to working one. And right now, many existing feature are broken. The let's add whatever feature we have in mind is the very cause of the state of the language right now.
Re: DIP 36: Rvalue References
I don't think adding more to the language is the sane thing to do right now. Why not? Could you explain this? This issue is discussed since more than a year and it is a very annoying issue. And even if Walter and Andrei are of this opinion, it would still only polite when they explain in detail why they think this.
Re: DIP 36: Rvalue References
On Saturday, 20 April 2013 at 14:42:57 UTC, Namespace wrote: Yes, this temp ref issue is far more important than the ref safety issue I've been concerning myself with. I wouldn't mind if the objections I've brought up fall in favor of whatever it takes to get temp ref solved. ref safety is important, but it's nowhere near the shear *annoyingness* factor of rvalue temp refs. That is true, but it makes the impression that, with the exception of Kenji, none of the core developers is interested in a solution to this problem. The DIP was not much discussed and the pull request is regularly overlooked / ignored. I don't think adding more to the language is the sane thing to do right now.
Re: DIP 36: Rvalue References
Yes, this temp ref issue is far more important than the ref safety issue I've been concerning myself with. I wouldn't mind if the objections I've brought up fall in favor of whatever it takes to get temp ref solved. ref safety is important, but it's nowhere near the shear *annoyingness* factor of rvalue temp refs. That is true, but it makes the impression that, with the exception of Kenji, none of the core developers is interested in a solution to this problem. The DIP was not much discussed and the pull request is regularly overlooked / ignored. Also in the discussion on the pull request no comments for Walter or Andrei are found. Although the pull is complete and has passed all the tests and would be ready to merge. Also this thread is completely ignored even though both write in this forum regularly and participate in other discussions. To me this makes the impression that they were not interested in this problem (or in our solution to the problem). Either they want the problem does not solve or try to solve it in their own way and that can take a very long time. At least an annotation what of both is the case or if I see it completely wrong, would be polite. But someone besides me would need to evaluate both DIP 35 & 36 to see if there were any real conflicts there. Yes that would be good.
Re: using readf in D
On Saturday, 20 April 2013 at 14:00:50 UTC, Chris Cain wrote:
On Saturday, 20 April 2013 at 12:52:30 UTC, Carlos wrote:
First it takes two reads for the first input from the user and
second it only calculates tcsleep.
Oh, I see what you mean by this now. You were describing the
problem (I thought you were telling us what the program does).
Ok, so this will fix the problem:
readf(" %d", &minsleep);
and
readf(" %d", &minsit);
Notice, the space is before the %d instead of after. The space
means "eat all of the whitespace before the next input". So, as
you can see, it has to "take two reads" because it's waiting for
some non-whitespace information. If you kept hitting enter (or
inputting spaces), you'd see that it'd keep prompting you.
Ok now it works perfectly. Thanks you very much Chris Cain!
I was using it with space before and after because in the book
"The D Progamming language" by Andrei Alexandrescu page 22 it was
using it that way but I didnt read everything maybe I missed that
detail.
Re: using readf in D
On Saturday, 20 April 2013 at 12:52:30 UTC, Carlos wrote:
First it takes two reads for the first input from the user and
second it only calculates tcsleep.
Oh, I see what you mean by this now. You were describing the
problem (I thought you were telling us what the program does).
Ok, so this will fix the problem:
readf(" %d", &minsleep);
and
readf(" %d", &minsit);
Notice, the space is before the %d instead of after. The space
means "eat all of the whitespace before the next input". So, as
you can see, it has to "take two reads" because it's waiting for
some non-whitespace information. If you kept hitting enter (or
inputting spaces), you'd see that it'd keep prompting you.
Re: using readf in D
On Saturday, 20 April 2013 at 12:52:30 UTC, Carlos wrote:
First it takes two reads for the first input from the user and
second it only calculates tcsleep.
Oh, I see what you mean by this now. You were describing the
problem (I thought you were telling us what the program does).
Ok, so this will fix the problem:
readf(" %d", &minsleep);
and
readf(" %d", &minsit);
Notice, the space is before the %d instead of after. The space
means "eat all of the whitespace before the next input". So, as
you can see, it has to "take two reads" because it's waiting for
some non-whitespace information. If you kept hitting enter (or
inputting spaces), you'd see that it'd keep prompting you.
Re: using readf in D
On Saturday, 20 April 2013 at 12:52:30 UTC, Carlos wrote:
Hi guys! I'm writing a little program in D from another version
I did for my homework written in C. But it doesn't work very
well. First it takes two reads for the first input from the
user and second it only calculates tcsleep.
Here is the code:
import std.stdio;
import std.c.stdlib;
void main()
{
immutable sitc = 1.66;
immutable sleepc = 1.08;
float tcsleep, tcsit, tc;
int minsleep, minsit;
write("Input number of minutes sleep : \n");
readf("%d ", &minsleep);
write("Input number of minutes sitting : \n");
readf("%d ", &minsit);
write("Thanks!\n");
tcsleep = minsit*sitc;
tcsit = minsleep*sleepc;
tc = tcsleep+tcsit;
writeln("Your total calories is : ", tc);
exit (0);
}
First off, great on you for rewriting an old assignment in a new
language. That's one of the better ways I've found to learn new
languages (and I learn new languages all the time) because it
allows you to focus on the new language and how you might use
that language rather than solving the problem at hand.
Second, this probably should be in D.learn (if I don't say it,
someone else will).
http://forum.dlang.org/group/digitalmars.D.learn if you're using
the web interface.
Third, "exit(0)" is redundant in D. It'll exit with code 0 as
long as execution terminates normally (i.e., no exceptions
thrown).
Finally, what "doesn't work very well"? Without more information,
I don't think anyone will be able to help you.
Take care.
using readf in D
Hi guys! I'm writing a little program in D from another version I
did for my homework written in C. But it doesn't work very well.
First it takes two reads for the first input from the user and
second it only calculates tcsleep.
Here is the code:
import std.stdio;
import std.c.stdlib;
void main()
{
immutable sitc = 1.66;
immutable sleepc = 1.08;
float tcsleep, tcsit, tc;
int minsleep, minsit;
write("Input number of minutes sleep : \n");
readf("%d ", &minsleep);
write("Input number of minutes sitting : \n");
readf("%d ", &minsit);
write("Thanks!\n");
tcsleep = minsit*sitc;
tcsit = minsleep*sleepc;
tc = tcsleep+tcsit;
writeln("Your total calories is : ", tc);
exit (0);
}
Re: D compile time algorithms implementation
I wanted to say "NoDuplicates" ))
Re: D compile time algorithms implementation
On Saturday, 20 April 2013 at 11:07:28 UTC, Timon Gehr wrote:
On 04/20/2013 08:07 AM, khurshid wrote:
I just have read from github std.variant, std.typetuple, etc.
source
codes.
And I have a question.
Why more linear algorithms implemented with O(N^2) ?
example: staticMap, it doesnot compiled more 500 arguments.
although, following version compiled for more than 32768
arguments:
template staticMap2(alias F, T...)
{
static if (T.length == 0)
{
alias TypeTuple!() staticMap2;
}
else static if (T.length == 1)
{
alias TypeTuple!(F!(T[0])) staticMap2;
}
else
{
alias TypeTuple!( staticMap2!(F, T[0..$/2]),
staticMap2!(F,
T[$/2..$])) staticMap2;
}
}
FWIW I think the O(N^2) behaviour is a limitation of the
compiler implementation (I think ropes might be a better data
structure than arrays to back compiler tuples.)
For using only one algorithm - it's no problem.
But if we are using algorithm inside another algorithm (like
NoDuples(..) which inside uses EraseAll ) - compile time will
become very slowly.
Re: D compile time algorithms implementation
On 04/20/2013 08:07 AM, khurshid wrote:
I just have read from github std.variant, std.typetuple, etc. source
codes.
And I have a question.
Why more linear algorithms implemented with O(N^2) ?
example: staticMap, it doesnot compiled more 500 arguments.
although, following version compiled for more than 32768 arguments:
template staticMap2(alias F, T...)
{
static if (T.length == 0)
{
alias TypeTuple!() staticMap2;
}
else static if (T.length == 1)
{
alias TypeTuple!(F!(T[0])) staticMap2;
}
else
{
alias TypeTuple!( staticMap2!(F, T[0..$/2]),
staticMap2!(F,
T[$/2..$])) staticMap2;
}
}
FWIW I think the O(N^2) behaviour is a limitation of the compiler
implementation (I think ropes might be a better data structure than
arrays to back compiler tuples.)
Re: Attribute inference for auto functions?
On Saturday, 20 April 2013 at 07:18:42 UTC, deadalnix wrote: You don't need a symbol. They also control the ABI, and this isn't always related to a specific symbol. Well, this is how it probably should be. But looking at current D state I don't see if it was even planned. Can you have an extern without declaring some symbol at the same time within current D grammar?
Re: D compile time algorithms implementation
khurshid: I just have read from github std.variant, std.typetuple, etc. source codes. And I have a question. Why more linear algorithms implemented with O(N^2) ? I remember a very recent discussion in reddit.com/r/cpp about using this idea. I think very large tuples are not common. Bye, bearophile
Re: D compile time algorithms implementation
On Saturday, 20 April 2013 at 06:07:18 UTC, khurshid wrote: Why more linear algorithms implemented with O(N^2) ? example: staticMap, it doesnot compiled more 500 arguments. I guess the simple answer is that their complexity hasn't been given much thought, as I don't image they were intended to be used with that many arguments (of course, this is not an excuse). If possible, could you file an enhancement request? It would also be great if you could add your improvement as a pull request on github! http://d.puremagic.com/issues/enter_bug.cgi?product=D https://github.com/D-Programming-Language/phobos
Re: Attribute inference for auto functions?
On Saturday, 20 April 2013 at 06:25:09 UTC, Walter Bright wrote: On 4/19/2013 11:12 PM, deadalnix wrote: But some time, you can't alias (in case of inference for instance) and so can't choose what attribute bind to. Example, please. Here you go: void foo(T)(extern(C) T function() function() f); Try making the extern(C) apply to each of: 1. the result of f() 2. the result of f()() without breaking foo()'s type inference.
Re: Official D Grammar
I've moved my work on the grammar to the following location on Github: https://github.com/Hackerpilot/DGrammar This uses ANTLR, as the other parser generators can't handle D's grammar. Several rules from the official grammar were removed, and several others were added (Such as an actual rule for a function declaration...) I also tried to fix any inacuracies or omissions I came across in the online documentation. Comments, issues, and pull requests welcome.
Re: Attribute inference for auto functions?
On Saturday, 20 April 2013 at 07:03:55 UTC, Dicebot wrote: On Saturday, 20 April 2013 at 06:32:50 UTC, deadalnix wrote: On Saturday, 20 April 2013 at 06:24:36 UTC, Walter Bright wrote: In general we lack a mechanism to choose what an attribute bind to. No, we don't. The attribute binds to the declaration. In general we lack a mechanism to choose what direction we turn to. No, we don't. We always turn to the right. I am quite sure Walter has meant that linkage attribute was not supposed to be tied to a type by design. If you want to use it, you need a symbol (==declaration) and there can be only one at a time. You don't need a symbol. They also control the ABI, and this isn't always related to a specific symbol.
Re: Attribute inference for auto functions?
On Saturday, 20 April 2013 at 06:32:50 UTC, deadalnix wrote: On Saturday, 20 April 2013 at 06:24:36 UTC, Walter Bright wrote: In general we lack a mechanism to choose what an attribute bind to. No, we don't. The attribute binds to the declaration. In general we lack a mechanism to choose what direction we turn to. No, we don't. We always turn to the right. I am quite sure Walter has meant that linkage attribute was not supposed to be tied to a type by design. If you want to use it, you need a symbol (==declaration) and there can be only one at a time.
