Re: Starting Formal Review of std.process
Hi Jesse, Is there any example code that uses it? On Tue, Apr 9, 2013 at 6:48 PM, Jesse Phillips jessekphillip...@gmail.comwrote: On Thursday, 4 April 2013 at 14:31:43 UTC, Jesse Phillips wrote: The changes for std.process are under review at: http://forum.dlang.org/thread/**gclsbrghhjitnfderoos@forum.**dlang.orghttp://forum.dlang.org/thread/gclsbrghhjitnfder...@forum.dlang.org std.process is improvements to the existing std.process and is a complete change to the API. The original API remains but these will be going through deprecation. The major change is support for redirecting stdin/stdout/stderr As review has been going for a month, I'm proposing we do a formal review for 1 week followed by a 1 week vote. As there has been no objection, Thursday PST will be the last Review day. Voting will start Friday/Thursday night.
Re: Justin Bieber booked for Dconf 2013!
On Wednesday, 3 April 2013 at 14:39:17 UTC, John Colvin wrote: Take awful song. apply Swedish virtuoso funk: http://www.youtube.com/watch?v=KjVGJ3YFDc8 I now know the lyrics to many awful songs due to those guys. That is awesome ! I love that one as well (starcraft player should enjoy) : https://www.youtube.com/watch?v=fzMhh8zhTiY
Re: TDPL Japanese Edition
All, Thank you for the reply! Today, just delivered to Japanese programmers :) April 8th was the presale date. Masahiro On Thursday, 4 April 2013 at 05:51:03 UTC, Masahiro Nakagawa wrote: Hi guys, I and Kenji are happy to announce TDPL Japanese edition will be published on April 8th in Japan. We are translation supervisor of this book. Sample picture is here: https://pathakacdn-a.akamaihd.net/photos2/7ace5e69-4d3c-497f-87fc-4fbd97c7ad8f/original.jpg The official web page of the publisher Shoeisha: http://books.shoeisha.co.jp/book/b108222.html (in japanese) Of course, we applied latest changes and added some columns for new features, e.g. CTFE, lambda syntax and more. In addition, we strived to maintain Andrei's distinctive and lively language even through translation :) Thanks to Andrei for writing TDPL and D community for keeping an active development. We hope this book becomes a stepping stone to further development. Thanks, Masahiro and Kenji
Re: Starting Formal Review of std.process
On Thursday, 11 April 2013 at 08:27:24 UTC, Rory McGuire wrote: Hi Jesse, Is there any example code that uses it? The docs provide examples http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process.html is there something insufficient about them?
Re: TDPL Japanese Edition
On 4/3/2013 10:51 PM, Masahiro Nakagawa wrote: The official web page of the publisher Shoeisha: http://books.shoeisha.co.jp/book/b108222.html (in japanese) The google translation: http://translate.google.com/translate?sl=autotl=enjs=nprev=_thl=enie=UTF-8eotf=1u=http%3A%2F%2Fbooks.shoeisha.co.jp%2Fbook%2Fb108222.htmlact=url
Re: State of the forum
He is totally right. Everything, possibly except the the forum speed, is not related to no maintenance, rather plain bugs in implementation or design.
Re: State of the forum
On Thursday, 11 April 2013 at 05:55:10 UTC, angel wrote: He is totally right. Everything, possibly except the the forum speed, is not related to no maintenance, rather plain bugs in implementation or design. If they're as plain as you say, why don't you fix them? ;) https://github.com/CyberShadow/DFeed
Re: dmd command line options bad design: -offilename, -Ddocdir etc.
On 2013-04-10 21:30, Walter Bright wrote: I agree. The way to do it is to support both the old and the new ways for now. Anyone want to do a pull req? Also, this should be put in bugzilla as an enhancement request. Preferably the code for the new syntax should be in its own module/function and not included directly in main. -- /Jacob Carlborg
Re: State of the forum
On Wednesday, 10 April 2013 at 16:25:03 UTC, ixid wrote: The forum has a number of issues, is there anything practical that can be done to address them? A forum should really work. You can collect more information about the issues you're experiencing, and file an issue, or even better, send a pull request to the forum's GitHub repository: https://github.com/CyberShadow/DFeed Regular forum errors (XHR error) Posts disappearing after getting stuck in a waiting for message response loop I have not experienced these issues. The next time it happens, please make a note of the exact time and the post you're attempting to send, and file an issue or contact me directly. Broken up threads with the same title The core issue is caused by Mailman rewriting Message-IDs. I know how to implement a workaround, but it requires reengineering the database (I need to store two IDs for each message, and account for both when reconstructing threads). This is planned for the next major update. Often has layout errors when loading that require a refresh Which web browser? If the HTML doesn't change (and I don't know why it would), it sounds like a bug with your browser's layout engine. Works poorly/buggily on mobile browers (Android Stock/Android Chrome) Please list some specific issues. Note that there is a limit to the post width, since many mail/news clients send text in a non-reflowable (pre-wrapped) format. Also the user habit due to the combined use of the forum as an email discussion and as a website forum of repeating the whole of a post, often to respond with a one-liner. Posts without the whole email/context repeated receive complaints that people do not know what it is in response to. I'll implement some warnings when a user attempts to post a message not conforming to netiquette.
Re: Disable GC entirely
On Wed, 10 Apr 2013 15:29:25 -0700 H. S. Teoh hst...@quickfur.ath.cx wrote: I wonder if this is why I enjoy retro games more -- they require less concentration and lots of fun can be had for not too much effort. I find that a lot of modern games seem to require a lot of concentration -- keeping track of a convoluted storyline, keeping track of one's 3D surroundings, being on one's toes to react quickly at surprise enemy attacks, etc.. After a full day's worth of coding, that's the last thing I want to be doing. Much better to relax with something that can be played in a more relaxed/casual way. Strange, I find the exact opposite to true. I always felt this summed it up perfectly: http://semitwist.com/download/img/funny/digitalunrest-2008-09-29.jpg (That said, I never thought MM9 was *as* hard as people made it out to be. At first it seemed the same as all the older megaman's, and then it wasn't long before I could get through the whole thing in about an hour. Still one of the best games ever made, though. But if you want a *really* hard MegaMan, try MegaMan Bass. I'm totally stuck in that.) The last 10 or so years, big-budget games have tended to be designed specifically so that anyone can get to the end without much effort. The lack of challenge makes them tedious and boring. For example, the Mario and Zelda games have done nothing but get progressively easier sine the 80's (compare the battle system in the original zelda to *any* 3D zelda - the former is an addictive challenge, the latter is mindless button-mashing/waggle and *vastly* easier.) New Mario is fun, but notably easier than Mario 1/2/3/64. And then there's the old Kid Icarus. *Phew!* - that's not for the faint of heart. Most people don't even know that it has zelda/Metroid-like dungeons or horizontal levels because they never got past level 3. As far as keeping track of a convoluted storyline, I rarely pay attention to the stories/dialog/characters/etc anyway. There are exceptions (like 2D JRPGs or Disgaea), but most games I just skip through the dialog (9 times out of 10 it's both uninteresting and irrelevant to the gameplay), and when a game doesn't let me skip a cutscene or scripted event I'll just grab a drink or snack or hit the can if I need to, or otherwise just hit Switch Inputs and find something not-too-horrible on TV while I wait for the tell-tale sound of a level being loaded off disc.
Re: Disable GC entirely
On 2013-04-10 18:49, Andrej Mitrovic wrote: Just take a look at the upcoming changelog: https://github.com/D-Programming-Language/d-programming-language.org/pull/303 It's great to see that we will have, what it looks like, a proper changelog of the next release. -- /Jacob Carlborg
Re: Disable GC entirely
On Wednesday, 10 April 2013 at 22:50:48 UTC, Walter Bright wrote: On 4/7/2013 3:59 AM, Paulo Pinto wrote: The current compilers just don't have the amount of investment in more than 20 years of code optimization like C++ has. You cannot expect to achieve that from one moment to the other. This is incorrect, as dmd, gdc, and ldc all use the backends of C++ compilers, and the code generated is as good as that of the corresponding C++ compiler. Correct, assuming the frontend organizes the intermediate information in a way that the backend can make the best use of it, or am I wrong?
Re: Disable GC entirely
On Wednesday, 10 April 2013 at 22:48:06 UTC, Walter Bright wrote: On 4/6/2013 3:10 AM, Paulo Pinto wrote: However there are cases where every byte and every ms matter, in those cases you are still better with C, C++ and Fortran. This is not correct. If you care about every byte, you can make D code just as performant. And by caring about every byte, you'll need to become as familiar with how D generates code, and the cost of what various features entail, as you would be in C++. Same can be said for JVM and .NET languages. Some of our consulting projects are conversion of C++ code into one of the said technologies. We usually achieve performance parity with the existing application. With C, C++ and Fortran it is easier to achieve a certain performance level without effort, while the other languages require a bit of effort knowing the runtime, writing GC friendly data structures and algorithms, and doing performance analysis, but it achievable as well. Many developers don't want to do this, hence my statement. -- Paulo
Re: State of the forum
Also the user habit due to the combined use of the forum as an email discussion and as a website forum of repeating the whole of a post, often to respond with a one-liner. Posts without the whole email/context repeated receive complaints that people do not know what it is in response to. I'll implement some warnings when a user attempts to post a message not conforming to netiquette. A suggestion: Can you make the quotes hidden by default, like e.g. in Gmail or Google Groups? That would be perfect. (http://i.imgur.com/axuAFvz.png)
Re: DIP 36: Rvalue References
On Wednesday, 10 April 2013 at 07:43:57 UTC, Dicebot wrote: ... Kenji, got any comments/objections on this point of view? It is not that late to change it back ;)
Re: Disable GC entirely
On 4/10/2013 11:55 PM, Paulo Pinto wrote: Some of our consulting projects are conversion of C++ code into one of the said technologies. We usually achieve performance parity with the existing application. With C, C++ and Fortran it is easier to achieve a certain performance level without effort, while the other languages require a bit of effort knowing the runtime, writing GC friendly data structures and algorithms, and doing performance analysis, but it achievable as well. Many developers don't want to do this, hence my statement. I've seen enough performant C++ code to disagree with your statement. If they knew what was going on with how C++ implemented their constructions, they could get a lot better performance. The second problem with writing performant C and C++ code is the difficulty of refactoring code to try different data structures algorithms. Generally, one picks a design up front, and never changes it because it is too hard to change it.
Re: DIP 36: Rvalue References
I think 'scope ref' should always pass the address of given argument to the
function body. Because 'ref' always means pass the address of given
argument. So, if given argument is an rvalue, compiler will allocate a
temporary on stack, save the rvalue in it, and take its address. If
argument is an lvalue, take its address directly. It should be always true,
eve if the parameter type is small int.
Essentially language semantics should not reflect low level implementation
detail. After DIP36 is accepted, we will get a full set of tools for
efficiency - T, ref T, and scope ref T. From the toolbox, you can choose
the most efficient storage class based on the T.
void foo(MostEfficientParameters!(int, string, S, int[1024]) params) { ... }
Kenji Hara
2013/4/11 Dicebot m.stras...@gmail.com
On Wednesday, 10 April 2013 at 07:43:57 UTC, Dicebot wrote:
...
Kenji, got any comments/objections on this point of view? It is not that
late to change it back ;)
Re: Disable GC entirely
On Wed, 10 Apr 2013 18:52:58 -0400 Jeff Nowakowski j...@dilacero.org wrote: On 04/10/2013 05:22 PM, Nick Sabalausky wrote: For many (admittedly, not all) of them, I really don't believe games is an accurate term (Don't misinterpret that into a statement of Only true 'games' are legitimate because I never said such a thing.) But that's essentially what you *are* saying by downplaying the gameplay that lies at the heart of the interactive movies you've used as examples. That's because the heart of such games *isn't* the gameplay, it's the storytelling. I'm not downplaying anything that the developers themselves aren't already downplaying. It's the No True Scotsman fallacy. No, you're just very persistent in trying to turn it into the No True Scotsman fallacy. I'm merely using terminology to distinguish between story-driven titles and gameplay-driven tiles. *YOU'RE* the one who's falsely insisting that what I meant was Only the one type is legitimate, despite my numerous statements to the contrary. How many times to I have to tell you in various wordings, I'm *not* using 'interactive movie' pejoratively before you'll stop trying to tell me what I meant? Let's take a statement from your original post: Modern AAA/big-budget titles are interactive movies, not videogames, because their focus is story, dialog and cinematics, not gameplay. Which is untrue when it comes to games like BioShock or GTA. At the end of the day both games are mostly shooters along with other gameplay elements (like driving in GTA), and you will spend most of your time playing the game and not watching cinematics. So we disagree on the categorization of a few titles. Big freaking deal. I gave you a canonical example of what would be an interactive movie, and you tried to wave it away because it really was an interactive movie. That's a complete mischaracterization, and I find it interesting that you've claimed that while *completely* ignoring my very clear statement of: Keep in mind, I'm using interactive movie largely for lack of a better term. Yes, obviously Heavy Rain is a canonical example of interactive movie, and for goodness sake, I *AGREED* with you and yet you're still complaining. It might be a bad thing if the industry focused too heavily on them, but that would be a completely different complaint. Which has been the essence of your complaint, Now you're just flat-out quoting me out-of-context. Here it is with the proper context re-added: Keep in mind, even sandbox titles, which are definitely not remotely interactive movie or cinematic at all (at least any of the ones I've seen), have long been debated as to whether or not they are games. And note that nobody ever said that was a bad thing. It might be a bad thing if the industry focused too heavily on them, but that would be a completely different complaint. What that means when it's *not* deliberately twisted around is: The following are two completely *different* claims: A. Not being a game is an inherently bad thing. B. Too much indusrtry-wide focus on (for whatever ) is a bad thing. I am claiming B and *NOT* A. Stop trying to tell me I'm claiming A. See? based on how games used to be and your particular tastes, sounding a lot like a grumpy old man who thinks the industry is suffering because they don't make them like they used to: Maybe I'm just projecting my own tastes into this, or maybe this is just because I don't have sales/profits/etc charts for the last 10-20 years to examine, but lately I'm finding it difficult to believe that AAA games aren't becoming (or already) a mere niche, much like high-performance sports cars. (Ie, big money, but small market.) Part of this is because, as I see it, the big/AAA games *as they used to exist* up until around the early 2000's don't seem to be around much anymore. Oh for crap's sake. Yes, newer AAA/big-business games, on average, *do* direct significantly more of their emphasis on story/dialog/cinematic feel/etc than older ones. I was being diplomatic before, but that's really undeniable. Do you think all that comes at no cost in development resources? (Rhetorical, of course. I'm pointing out it's rhetorical so I don't get accused of hyperbole or of actually suggesting that you did think it didn't cost extra resources.) So that requires more sales for sustainability, and then I went on with my reasoning about diminishing audience - clearly marked with disclaimers about my lack of certainly (which you've conveniently quoted for me and also conveniently ignored). And now you come along, slap the big generic grumpy old man don't make them like they used to labels over the whole thing, and now I'm supposed to believe not only that your poisoning the well tactics somehow *aren't* a logical fallacy, but also that I'm the one being categorically dismissive? And really, is it so damn horrible to have and voice a negative opinion
Re: To help LDC/GDC
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and the function's parameters as
const or immutable.
Sure, I accept that. What I was meaning, though, was an up-front declaration
which would make the compiler shout if those necessary conditions were not met.
i.e.
pure foo(int n) { ... } // compiles
strong pure bar(int n) { ... } // compiler instructs you to make
// variables const or immutable
Re: DIP 36: Rvalue References
You don't think exposing creation of temporaries is low level implementation detail? On Thursday, 11 April 2013 at 08:14:00 UTC, kenji hara wrote: ... Kenji Hara
Re: Disable GC entirely
On Thursday, 11 April 2013 at 08:03:53 UTC, Walter Bright wrote: On 4/10/2013 11:55 PM, Paulo Pinto wrote: Some of our consulting projects are conversion of C++ code into one of the said technologies. We usually achieve performance parity with the existing application. With C, C++ and Fortran it is easier to achieve a certain performance level without effort, while the other languages require a bit of effort knowing the runtime, writing GC friendly data structures and algorithms, and doing performance analysis, but it achievable as well. Many developers don't want to do this, hence my statement. I've seen enough performant C++ code to disagree with your statement. If they knew what was going on with how C++ implemented their constructions, they could get a lot better performance. The second problem with writing performant C and C++ code is the difficulty of refactoring code to try different data structures algorithms. Generally, one picks a design up front, and never changes it because it is too hard to change it. Fair enough, I have left the C daily coding on the job in 2002 and C++ in 2005, so I can hardly consider myself an expert in optimization tricks in those languages. Nowadays I get seldom the opportunity to write new C++ code on the job. -- Paulo
Re: Disable GC entirely
On 4/10/2013 11:57 PM, Paulo Pinto wrote: On Wednesday, 10 April 2013 at 22:50:48 UTC, Walter Bright wrote: On 4/7/2013 3:59 AM, Paulo Pinto wrote: The current compilers just don't have the amount of investment in more than 20 years of code optimization like C++ has. You cannot expect to achieve that from one moment to the other. This is incorrect, as dmd, gdc, and ldc all use the backends of C++ compilers, and the code generated is as good as that of the corresponding C++ compiler. Correct, assuming the frontend organizes the intermediate information in a way that the backend can make the best use of it, or am I wrong? Of course.
Re: DIP 36: Rvalue References
2013/4/11 Dicebot m.stras...@gmail.com You don't think exposing creation of temporaries is low level implementation detail? No. In this case, it is the purpose of 'scope ref', not is the implementation details. What is the language semantics and what is the implementation detail - that varies depending on what is properly supported in the language. D explicitly distinguishes lvalues and rvalues, and also defines that rvalue cannot be taken its address (== reference). The purpose of 'scope ref' is that the parameter can be received both lvalues and rvalues with one function body. To receive lvalues, scope ref should take the address of them. As a conclusion, to receive rvalues temporary creation is necessary in caller site. Yes, it mostly represents implementation details, but it is still description of language semantics. This confusion is almost inevitable. Because the essential purpose of 'scope ref' is already efficiency. Furthermore, note that the desired efficiency is not the speed of argument passing. I recognize that it is to avoid code bloating of function body. If you need most efficient argument passing, you should choose it from the argument type. 'scope ref' is not a thing to make the choice automatic. Kenji Hara
Re: DIP 36: Rvalue References
On Thursday, 11 April 2013 at 09:27:11 UTC, kenji hara wrote: No. In this case, it is the purpose of 'scope ref', not is the implementation details. What is the language semantics and what is the implementation detail - that varies depending on what is properly supported in the language. D explicitly distinguishes lvalues and rvalues, and also defines that rvalue cannot be taken its address (== reference). The purpose of 'scope ref' is that the parameter can be received both lvalues and rvalues with one function body. To receive lvalues, scope ref should take the address of them. As a conclusion, to receive rvalues temporary creation is necessary in caller site. Yes, it mostly represents implementation details, but it is still description of language semantics. This confusion is almost inevitable. Because the essential purpose of 'scope ref' is already efficiency. Furthermore, note that the desired efficiency is not the speed of argument passing. I recognize that it is to avoid code bloating of function body. If you need most efficient argument passing, you should choose it from the argument type. 'scope ref' is not a thing to make the choice automatic. Kenji Hara I trust your judgement then, will update DIP then. But I am still afraid of confusion.
Re: DIP 36: Rvalue References
Isn's it too strict? The following example would not work because
you cannot take the address of the parameter. But it would still
be nice to have it passed by ref and scoped:
struct Item
{
int data;
Item* next;
}
void printThem(const scope ref Item first)
{
auto it = first;
while (it)
{
std.stdio.writeln(*it);
it = it.next;
}
}
/Jonas
Re: To help LDC/GDC
On Thursday, 11 April 2013 at 00:41:01 UTC, Walter Bright wrote: On 4/10/2013 5:33 PM, deadalnix wrote: call with const parameter can be considered strongly pure if the argument is immutable The argument doesn't need to be immutable because nobody can change it while the function is running. I explained the sentence just above how it is possible. Ignoring issue rarely help when it come to solve them.
Re: To help LDC/GDC
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton
Wakeling wrote:
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and the
function's parameters as
const or immutable.
Sure, I accept that. What I was meaning, though, was an
up-front declaration
which would make the compiler shout if those necessary
conditions were not met.
i.e.
pure foo(int n) { ... } // compiles
strong pure bar(int n) { ... } // compiler instructs you
to make
// variables const or
immutable
Both are strongly pure.
Re: To help LDC/GDC
On Thu, 11 Apr 2013 12:03:38 +0200, deadalnix deadal...@gmail.com wrote:
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton Wakeling
wrote:
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and the function's
parameters as
const or immutable.
Sure, I accept that. What I was meaning, though, was an up-front
declaration
which would make the compiler shout if those necessary conditions were
not met.
i.e.
pure foo(int n) { ... } // compiles
strong pure bar(int n) { ... } // compiler instructs you to make
// variables const or immutable
Both are strongly pure.
That's not the point. The point is, if he'd written this:
strong pure bar(int* n) { ... }
The compiler would have said 'Bad programmer! int* is not implicitly
castable to immutable!'
--
Simen
Re: To help LDC/GDC
On Thursday, 11 April 2013 at 10:03:39 UTC, deadalnix wrote:
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton
Wakeling wrote:
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and the
function's parameters as
const or immutable.
Sure, I accept that. What I was meaning, though, was an
up-front declaration
which would make the compiler shout if those necessary
conditions were not met.
i.e.
pure foo(int n) { ... } // compiles
strong pure bar(int n) { ... } // compiler instructs you
to make
// variables const or
immutable
Both are strongly pure.
is foo strongly pure because of n being a value type that cannot
contain any indirection? (i.e. as far as the outside world is
concerned you don't get any side effects whatever you do with it).
Is the same for structs that contain no indirection? Or do they
have to be const/immutable?
Re: To help LDC/GDC
2013/4/11 John Colvin john.loughran.col...@gmail.com
On Thursday, 11 April 2013 at 10:03:39 UTC, deadalnix wrote:
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton Wakeling wrote:
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and the function's
parameters as
const or immutable.
Sure, I accept that. What I was meaning, though, was an up-front
declaration
which would make the compiler shout if those necessary conditions were
not met.
i.e.
pure foo(int n) { ... } // compiles
strong pure bar(int n) { ... } // compiler instructs you to make
// variables const or immutable
Both are strongly pure.
is foo strongly pure because of n being a value type that cannot contain
any indirection? (i.e. as far as the outside world is concerned you don't
get any side effects whatever you do with it).
Is the same for structs that contain no indirection? Or do they have to be
const/immutable?
It is same for structs that has no *mutable* indirections. In below, all
functions are strongly pure.
module x;
struct S1 { int n; }
struct S2 { immutable int[] arr; }
struct S3 { int[] arr; }
pure int foo0(int n);
pure int foo1(S1); // S1 has no indirections
pure int foo2(S2); // S2 has no *mutable* indirections
pure int foo3(immutable ref S3 x); // foo3 cannot access any mutable
indirections
Kenji Hara
Re: dmd command line options bad design: -offilename, -Ddocdir etc.
AFAIK most unix tools have two formats: long and short. long: dmd --foobar-dir=/somewhere/over/the/rainbow short: dmd -f /somewhere/over/the/rainbow Most programs supports both. I think that would be the way to go. /Jonas
Re: To help LDC/GDC
On Thursday, 11 April 2013 at 10:27:55 UTC, kenji hara wrote:
2013/4/11 John Colvin john.loughran.col...@gmail.com
On Thursday, 11 April 2013 at 10:03:39 UTC, deadalnix wrote:
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton
Wakeling wrote:
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and the
function's
parameters as
const or immutable.
Sure, I accept that. What I was meaning, though, was an
up-front
declaration
which would make the compiler shout if those necessary
conditions were
not met.
i.e.
pure foo(int n) { ... } // compiles
strong pure bar(int n) { ... } // compiler instructs
you to make
// variables const or
immutable
Both are strongly pure.
is foo strongly pure because of n being a value type that
cannot contain
any indirection? (i.e. as far as the outside world is
concerned you don't
get any side effects whatever you do with it).
Is the same for structs that contain no indirection? Or do
they have to be
const/immutable?
It is same for structs that has no *mutable* indirections. In
below, all
functions are strongly pure.
module x;
struct S1 { int n; }
struct S2 { immutable int[] arr; }
struct S3 { int[] arr; }
pure int foo0(int n);
pure int foo1(S1); // S1 has no indirections
pure int foo2(S2); // S2 has no *mutable* indirections
pure int foo3(immutable ref S3 x); // foo3 cannot access any
mutable
indirections
Kenji Hara
right, gotcha!
Re: To help LDC/GDC
On 04/11/2013 12:03 PM, deadalnix wrote: Both are strongly pure. Perhaps the fact that I can have this misunderstanding is itself an argument for an explicit strong pure keyword, so that a daft bugger like me can really be sure he's getting what he thinks he's getting? :-) Apart from that, I think Simen replied better than I could ...
Re: To help LDC/GDC
On Thursday, 11 April 2013 at 10:16:39 UTC, John Colvin wrote:
On Thursday, 11 April 2013 at 10:03:39 UTC, deadalnix wrote:
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton
Wakeling wrote:
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and the
function's parameters as
const or immutable.
Sure, I accept that. What I was meaning, though, was an
up-front declaration
which would make the compiler shout if those necessary
conditions were not met.
i.e.
pure foo(int n) { ... } // compiles
strong pure bar(int n) { ... } // compiler instructs you
to make
// variables const or
immutable
Both are strongly pure.
is foo strongly pure because of n being a value type that
cannot contain any indirection? (i.e. as far as the outside
world is concerned you don't get any side effects whatever you
do with it).
Is the same for structs that contain no indirection? Or do they
have to be const/immutable?
I don't know what the current implementation says, but it should
be.
Re: Disable GC entirely
On 04/11/2013 04:17 AM, Nick Sabalausky wrote: No, you're just very persistent in trying to turn it into the No True Scotsman fallacy. I'm merely using terminology to distinguish between story-driven titles and gameplay-driven tiles. Then you could call them story-driven games instead of interactive movies, and also acknowledge that the gameplay element is still a strong component. Your insistence on denying the massive amounts of gaming elements that are still part of these titles shows you have an ax to grind, backed up by the fact that you even started your argument by saying your personal tastes may have been informing your theories. So we disagree on the categorization of a few titles. Big freaking deal. Since it's the heart of your argument, it is a big deal. Yes, obviously Heavy Rain is a canonical example of interactive movie, and for goodness sake, I *AGREED* with you and yet you're still complaining. You just have a funny way of agreeing, what I'll call disagreeable agreeing. Oh for crap's sake. Yes, newer AAA/big-business games, on average, *do* direct significantly more of their emphasis on story/dialog/cinematic feel/etc than older ones. Yes, there's no doubt about that, and do you know *why* they do this? It's because, just like movies, these big budget cinematic games tend to sell a whole lot more, both in quantity and dollar volume. And just like the movies, it's also a big risk. But they are still games, and it's the gamers who flock to these blockbuster titles. As an aside, the interesting thing about GTA, especially GTA3, is that the budget wasn't about the movie elements, of which there were few. It was about creating an immersive *environment*. It's really the artwork that costs so much money. There was also a story arc, but you can find stories in games going back decades. As to why the industry is sick, in Manu's terms, it's probably just competition with other forms of entertainment given the mobile explosion. The games industry did very well post 2000, despite the move to cinematic experiences. And now you come along, slap the big generic grumpy old man don't make them like they used to labels over the whole thing, and now I'm supposed to believe not only that your poisoning the well tactics somehow *aren't* a logical fallacy, but also that I'm the one being categorically dismissive? Yet your pet theory does amount to how they don't make them like they used to, and maybe that's the reason the industry is failing, which sounds a lot like a grumpy-old-man complaint, doesn't it? Along with your usual ranting, of course. Last post for me.
Re: dmd command line options bad design: -offilename, -Ddocdir etc.
On 4/11/13, Jonas Drewsen nospam4...@hotmail.com wrote: AFAIK most unix tools have two formats: long and short. long: dmd --foobar-dir=/somewhere/over/the/rainbow short: dmd -f /somewhere/over/the/rainbow Most programs supports both. I think that would be the way to go. RDMD works on the assumption that its flags begin with -- and DMD's flags with -. There's no need to invent new short/long switches, we just need an equals sign to make it visually clear. Also using spaces might be a bad idea, you might end up doing the wrong thing if you call DMD incorrectly (e.g. a result of a wrong expansion in a shell script), for example: $ dmd -of foo.d bar.d Currently this is an error, the user forgot to specify the -of switch. If spaces were ok then this becomes the equivalent of: $ dmd -offoo.d bar.d I'd rather be safe than sorry and allow either -offoo or -of=foo. It will catch errors this way rather than do something unexpected.
PHP extension in D
Hi, I want to extend Php with an extension written in D, and wrap some D classes in php. My questions are: 1. How I can build a static library(I am using eclipse with ddt) 2. How I can create methods and create objects in c++ from the D library. Thanks, Bogdan
Re: PHP extension in D
11.04.2013 15:28, gedaiu пишет: Hi, I want to extend Php with an extension written in D, and wrap some D classes in php. My questions are: 1. How I can build a static library(I am using eclipse with ddt) 2. How I can create methods and create objects in c++ from the D library. Post such questions to digitalmars.D.learn, please. -- Денис В. Шеломовский Denis V. Shelomovskij
Re: dmd command line options bad design: -offilename, -Ddocdir etc.
On Thursday, 11 April 2013 at 11:16:08 UTC, Andrej Mitrovic wrote: On 4/11/13, Jonas Drewsen nospam4...@hotmail.com wrote: AFAIK most unix tools have two formats: long and short. long: dmd --foobar-dir=/somewhere/over/the/rainbow short: dmd -f /somewhere/over/the/rainbow Most programs supports both. I think that would be the way to go. RDMD works on the assumption that its flags begin with -- and DMD's flags with -. There's no need to invent new short/long switches, we just need an equals sign to make it visually clear. By I think that would be the way to go I did not necessary refer to having both formats supported at the same time but simply to use the standard way that people know. Also using spaces might be a bad idea, you might end up doing the wrong thing if you call DMD incorrectly (e.g. a result of a wrong expansion in a shell script), for example: $ dmd -of foo.d bar.d Currently this is an error, the user forgot to specify the -of switch. If spaces were ok then this becomes the equivalent of: $ dmd -offoo.d bar.d I'd rather be safe than sorry and allow either -offoo or -of=foo. It will catch errors this way rather than do something unexpected. You may not like using spaces but it is a widespread standard and I think deviating is not the way to go. Anyway - this is turning into a bikeshed coloring discussion I guess :) /Jonas
Re: State of the forum
A suggestion: Can you make the quotes hidden by default, like e.g. in Gmail or Google Groups? That would be ideal.
Re: Disable GC entirely
Am Thu, 11 Apr 2013 00:11:05 +1000 schrieb Manu turkey...@gmail.com: Btw: implementing -vgc shouldn't be too difficult: We have to check all runtime hooks ( http://wiki.dlang.org/Runtime_**Hookshttp://wiki.dlang.org/Runtime_Hooks) for allocations, then check all places in dmd where calls to those hooks are emitted. It's actually very easy to find hidden allocations. If you remove the gc entierly from the runtime hidden allocations will cause linker errors. Not a particularly user-friendly approach. I'd rather think of some proper tools/mechanisms to help in this area :) I like test-vgc.d(9) vgc[CONCAT]: (a ~ b) causes gc allocation a lot more than undefined reference to gc_alloc ;-) I posted a proof of concept pull request here: https://github.com/D-Programming-Language/dmd/pull/1886 It needs some work but maybe it will be ready for 2.063. Would be great if both of you could comment there as you probably have most experience in avoiding the GC :-)
Re: To help LDC/GDC
On 2013-04-11 12:09, Simen Kjærås wrote:
That's not the point. The point is, if he'd written this:
strong pure bar(int* n) { ... }
The compiler would have said 'Bad programmer! int* is not implicitly
castable to immutable!'
What's the point of that. Just have strong mean const/immutable
parameters.
--
/Jacob Carlborg
Re: dmd command line options bad design: -offilename, -Ddocdir etc.
On 2013-04-11 12:25, Jonas Drewsen wrote: AFAIK most unix tools have two formats: long and short. long: dmd --foobar-dir=/somewhere/over/the/rainbow short: dmd -f /somewhere/over/the/rainbow Most programs supports both. I think that would be the way to go. For some reason compilers seem to only use a single dash for all formats. That is true for DMD, GCC and Clang. -- /Jacob Carlborg
Re: To help LDC/GDC
On 04/11/2013 03:29 PM, Jacob Carlborg wrote: What's the point of that. Just have strong mean const/immutable parameters. The point is to have a way for me, the programmer, to say to the compiler: I mean for this function to be strongly pure, can you confirm whether my choice of function inputs supports this please?
Re: To help LDC/GDC
On 11 April 2013 11:09, Simen Kjærås simen.kja...@gmail.com wrote:
On Thu, 11 Apr 2013 12:03:38 +0200, deadalnix deadal...@gmail.com wrote:
On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton Wakeling wrote:
On 04/10/2013 08:39 PM, Walter Bright wrote:
Sure there is. Declare the function as pure, and the function's
parameters as
const or immutable.
Sure, I accept that. What I was meaning, though, was an up-front
declaration
which would make the compiler shout if those necessary conditions were
not met.
i.e.
pure foo(int n) { ... } // compiles
strong pure bar(int n) { ... } // compiler instructs you to make
// variables const or immutable
Both are strongly pure.
That's not the point. The point is, if he'd written this:
strong pure bar(int* n) { ... }
The compiler would have said 'Bad programmer! int* is not implicitly
castable to immutable!'
Great, just what we need. A compiler that barrages the user about how bad
his code is, then dies...
/sarcasm
--
Iain Buclaw
*(p e ? p++ : p) = (c 0x0f) + '0';
Re: To help LDC/GDC
On 11 April 2013 14:38, Joseph Rushton Wakeling joseph.wakel...@webdrake.net wrote: On 04/11/2013 03:29 PM, Jacob Carlborg wrote: What's the point of that. Just have strong mean const/immutable parameters. The point is to have a way for me, the programmer, to say to the compiler: I mean for this function to be strongly pure, can you confirm whether my choice of function inputs supports this please? I think that giving the user choice of purity is about as useful as given user choice over what functions should be inlined, or what vars should go in registers. Such decisions are best left to the compiler devs judgement on doing the right thing for you. Even if they sometimes get it wrong. :o) -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: To help LDC/GDC
On 04/11/2013 03:49 PM, Iain Buclaw wrote: Great, just what we need. A compiler that barrages the user about how bad his code is, then dies... Compiler says no ...
Re: To help LDC/GDC
On 04/11/2013 03:53 PM, Iain Buclaw wrote: I think that giving the user choice of purity is about as useful as given user choice over what functions should be inlined, or what vars should go in registers. Well, I don't mean the compiler should guarantee that my code will be optimized in a certain way, but it's handy to be able to verify that it _qualifies_ for those optimizations. That said, I think my suggestion is a minor convenience feature, and is much, much less important than ironing out the design/implementation issues that others have raised in this thread. Such decisions are best left to the compiler devs judgement on doing the right thing for you. Even if they sometimes get it wrong. :o) What??!! You guys get it wrong sometimes??!! :-O
Re: Order of destruction when garbage collection kicks in
On Wed, 10 Apr 2013 05:48:30 -0400, Henning Pohl henn...@still-hidden.de wrote: Any instance of B always needs to be destructed _before_ the A it's connected to. How do you express this in D? You must not rely on the GC if you need ordered destruction. Even though destructors CAN destroy other resources, it's almost always better to use manual destruction. Consider that you almost certainly have more memory available than limited resources (such as file handles). If you rely on the GC to destroy that resource (and the GC is not guaranteed to always destroy it), then it's possible you run out of file handles before the memory that owns it is collected. I recommend you introduce destruction methods to close the handles manually outside the GC. Then if you happen to forget to close those manually, as a fail-safe have A destroy its a_handle (which would destroy all the b_handles, right?) in the destructor. A simple example to explain this is a buffered stream. Imagine you have a class which contains GC-managed array as a buffer, and the OS file handle. Upon destruction, it would be best if the buffered stream wrote whatever buffered data was left into the file handle, but since the GC may have destroyed the buffer, we can't do that. So you have to put a warning in the docs not to rely on the GC to destroy the stream. It really requires a change in philosophy -- do not let the GC clean up non-memory resources. Use manual methods to do that. -Steve
Re: dmd command line options bad design: -offilename, -Ddocdir etc.
On 4/11/13, Jonas Drewsen nospam4...@hotmail.com wrote: By I think that would be the way to go I did not necessary refer to having both formats supported at the same time but simply to use the standard way that people know. Unix != universal standard.
Re: dmd command line options bad design: -offilename, -Ddocdir etc.
On Thursday, 11 April 2013 at 15:15:09 UTC, Andrej Mitrovic wrote: On 4/11/13, Jonas Drewsen nospam4...@hotmail.com wrote: By I think that would be the way to go I did not necessary refer to having both formats supported at the same time but simply to use the standard way that people know. Unix != universal standard. Next best thing.
Re: DConf 2013 official car/room sharing thread
On 25 March 2013 05:29, Mike Parker aldac...@gmail.com wrote: On Sunday, 24 March 2013 at 21:32:12 UTC, Andrei Alexandrescu wrote: Hello to all prospective DConf 2013 attendees! A few of you are interested in sharing options for rental cars, or to share hotel rooms and split the cost in half. Let this thread be the official tracker for such requests and offers. I'll also post a link to this thread on http://dconf.org/venue.html. If necessary, we'll also post important related notices there. So, just reply to this with your offers and requests! Thanks, Andrei I'll be in the Comfort Inn in Redwood City with a 7-passenger mini-van. I'll be happy to pick people up along the route to FB. I'll be at http://goo.gl/maps/vNGCt Which according to maps is 10 minutes out of your way. Regards -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: DConf 2013 official car/room sharing thread
On Thursday, 11 April 2013 at 15:29:08 UTC, Iain Buclaw wrote: On 25 March 2013 05:29, Mike Parker aldac...@gmail.com wrote: I'll be in the Comfort Inn in Redwood City with a 7-passenger mini-van. I'll be happy to pick people up along the route to FB. I'll be at http://goo.gl/maps/vNGCt Which according to maps is 10 minutes out of your way. I think I can manage that. Assuming I don't oversleep!
Re: DConf 2013 official car/room sharing thread
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
Re: Formal Review of std.process
A couple minor comments: 1. I have two issues with Error being used. One is that we should have a specific type that is thrown, not raw Error type. Second is that I think in situations where the error is due to an incorrect parameter, it should be an exception not an error (and not a straight Exception either!). 2. For the documentation of inheritFDs, it says that On Windows, this option has no effect. While this is true, it may give the impression that we don't set the bInheritHandles flag, which we do. I think there should be a note on that somewhere. Otherwise, the API and functionality looks good! -Steve
Re: DConf 2013 official car/room sharing thread
On 11 April 2013 16:39, Mike Parker aldac...@gmail.com wrote: On Thursday, 11 April 2013 at 15:29:08 UTC, Iain Buclaw wrote: On 25 March 2013 05:29, Mike Parker aldac...@gmail.com wrote: I'll be in the Comfort Inn in Redwood City with a 7-passenger mini-van. I'll be happy to pick people up along the route to FB. I'll be at http://goo.gl/maps/vNGCt Which according to maps is 10 minutes out of your way. I think I can manage that. Assuming I don't oversleep! Infact, for an an extra £600 (and arrive and depart at SJC) - could stay in Four Seasons, which is a 10 minute cycle away... if I rent a bicycle... Squeezing my pockets and going to make a decision -- Iain Buclaw *(p e ? p++ : p) = (c 0x0f) + '0';
Re: Disable GC entirely
On Thursday, 11 April 2013 at 04:23:07 UTC, xenon325 wrote: On Wednesday, 10 April 2013 at 16:08:53 UTC, Andrei Alexandrescu wrote: It may as well be a mistake that nonvirtual functions are at all part of a class' methods. This has been quite painfully seen in C++ leading to surprising conclusions: http://goo.gl/dqZrr. Non-Member Functions Improve Encapsulation is invalid for D because of implicit friends. It was discussed before: http://forum.dlang.org/post/op.wbyg2ywyeav7ka@localhost.localdomain -- Alexander In some ways, implicit friends is the analogous to implicit virtual. With implied virtual you can at least state final for a reversal but with implied friends there's no way out other than through band-aid measures which cause headaches. Really, the generality of the problem is analogous to the reasons why you do not allow implicit data typing or worse, implicit declarations. So in D a fundamental rule is being violated. IMO, everything should be explicit unless the intention can be calculated to be 100% certain (i.e., no possible alternatives). For example auto in D is fine, because the data typing is certain, but a data type of a value in a JSON struct being defined by the value is wrong, eg maybe the 0 (integer) was supposed to be 0.0 (real). BTW, the UFCS solution to non-virtual methods creates the old C++ problem of constantly re-typing in the same symbol name of the class for every external member function. Not fun. Some syntactic sugar may help, perhaps clever use of template's, I don't know. --rt
Re: dmd command line options bad design: -offilename, -Ddocdir etc.
Am 11.04.2013 17:20, schrieb John Colvin: On Thursday, 11 April 2013 at 15:15:09 UTC, Andrej Mitrovic wrote: On 4/11/13, Jonas Drewsen nospam4...@hotmail.com wrote: By I think that would be the way to go I did not necessary refer to having both formats supported at the same time but simply to use the standard way that people know. Unix != universal standard. Next best thing. Actually I would like to know how the desktop world would look like had Apple bought BeOS instead. This would mean no UNIX on the desktop, assuming Apple would have won a similar market as of today. -- Paulo
Re: Disable GC entirely
On Thu, 11 Apr 2013 06:57:05 -0400 Jeff Nowakowski j...@dilacero.org wrote: Your insistence on denying the massive amounts of gaming elements that are still part of these titles shows you have an ax to grind, Generic gameplay is not massive amounts of gaming elements, but that's not what you're *really* interested in discussing is it? You're *still* starting from your purely-fabricated assertion that I'm just trying to be nasty, which *you've* decided to be true *solely because* you've decided it to be true. Then you blatantly ignore everything I say to the contrary and repeatedly use your own personal attacks as *their own* proof. Clearly you're not interested in even attempting a remotely rational discussion. The only thing you care to do is repeatedly bang your tired old You're being a grumpy old man drum of a complete non-argument. I'm sorry I've given you the benefit of the doubt as to your true intent in all this and actually read all of your asinine claims up to now, but I'm not bothering reading the rest of this clearly twisted post of yours, nor will I be reading anything more from you in this thread. Maybe you'll be willing to be sensible in other discussions.
Re: DConf 2013 official car/room sharing thread
I live in Mountain View, 15-30 minutes away from the venue. I can drive only one other person in my two-seater. :/ Ali
Re: Disable GC entirely
On Thu, Apr 11, 2013 at 02:39:01AM -0400, Nick Sabalausky wrote: On Wed, 10 Apr 2013 15:29:25 -0700 H. S. Teoh hst...@quickfur.ath.cx wrote: I wonder if this is why I enjoy retro games more -- they require less concentration and lots of fun can be had for not too much effort. I find that a lot of modern games seem to require a lot of concentration -- keeping track of a convoluted storyline, keeping track of one's 3D surroundings, being on one's toes to react quickly at surprise enemy attacks, etc.. After a full day's worth of coding, that's the last thing I want to be doing. Much better to relax with something that can be played in a more relaxed/casual way. Strange, I find the exact opposite to true. I always felt this summed it up perfectly: http://semitwist.com/download/img/funny/digitalunrest-2008-09-29.jpg (That said, I never thought MM9 was *as* hard as people made it out to be. At first it seemed the same as all the older megaman's, and then it wasn't long before I could get through the whole thing in about an hour. Still one of the best games ever made, though. But if you want a *really* hard MegaMan, try MegaMan Bass. I'm totally stuck in that.) The last 10 or so years, big-budget games have tended to be designed specifically so that anyone can get to the end without much effort. The lack of challenge makes them tedious and boring. OK, now I'm not so sure what I meant anymore, because I find this tedium and bore really tiring, whereas something like, say, the ancient Lode Runner with its incredibly complicated time-sensitive maneuvres is actually stimulating and, paradoxically enough, relaxing. OTOH, things like Quake and other FPSes I find exhausting, even if they're no more than mindless shoot-everything-that-moves deals. Maybe the difference lies in the simplicity of rules in the older 2D games -- yes they can be challenging but the mechanics are easy to grasp, whereas in 3D environments, the complexity of movement possibilities can be overwhelming. Big-budget hold-your-hand games, OTOH, are tiring in another way, in a click-through ads kinda way. I have very little patience for anything with video clips, 'cos I rather be doing stuff instead of watching a video (I might as well watch youtube instead, etc.), yet I feel like I can't really get into the game if I don't endure through all those clips, 'cos I might miss some interesting game-world exposition or important story twist, etc.. So the result is that it's very tiring. But maybe this all just reflects my personal biases, and has nothing to do with what is objectively tiring / difficult / etc.. For example, the Mario and Zelda games have done nothing but get progressively easier sine the 80's (compare the battle system in the original zelda to *any* 3D zelda - the former is an addictive challenge, the latter is mindless button-mashing/waggle and *vastly* easier.) New Mario is fun, but notably easier than Mario 1/2/3/64. And then there's the old Kid Icarus. *Phew!* - that's not for the faint of heart. Most people don't even know that it has zelda/Metroid-like dungeons or horizontal levels because they never got past level 3. Hmm. I beat nethack. Several times. I don't know of any other game that is as difficult to beat! But OTOH, its difficulty comes not from hand-eye coordination, but from the block-shuffling-puzzle type of inherent difficulty -- you have all the time in the world to think before making your next move, but your decision could mean the difference between life and death (i.e. the loss of the last 40 hours of gameplay, due to permadeath). I guess personally I prefer that kind of challenge to the how-fast-can-you-react kind. As far as keeping track of a convoluted storyline, I rarely pay attention to the stories/dialog/characters/etc anyway. There are exceptions (like 2D JRPGs or Disgaea), but most games I just skip through the dialog (9 times out of 10 it's both uninteresting and irrelevant to the gameplay), and when a game doesn't let me skip a cutscene or scripted event I'll just grab a drink or snack or hit the can if I need to, or otherwise just hit Switch Inputs and find something not-too-horrible on TV while I wait for the tell-tale sound of a level being loaded off disc. But you see, that's precisely the kind of thing that wears me out. I feel like I'm not getting the max out of the game if I don't watch all the cutscenes / read all the dialogs, but then I have to endure through the whole thing when it's poorly written and then it's not enjoyable anymore. This is one of the things I really liked about the older Ultimas: the technology was such that dialogs were minimal, but that meant that they got the point across without needing to sit through long cutscenes / sift through convoluted dialogues. The trigger keywords were more-or-less obvious, so you just hit town, chat up the few obviously-important NPCs using the obviously important keywords, get
Re: DConf 2013 official car/room sharing thread
On Thu, 11 Apr 2013 13:21:23 -0400, Ali Çehreli acehr...@yahoo.com wrote: I live in Mountain View, 15-30 minutes away from the venue. I can drive only one other person in my two-seater. :/ Ali I'm staying in Palo Alto on El Camino Real, which appears to be between Mountain View and the venue. /me puts up thumb -Steve
Re: To help LDC/GDC
On 4/11/2013 3:02 AM, deadalnix wrote: On Thursday, 11 April 2013 at 00:41:01 UTC, Walter Bright wrote: On 4/10/2013 5:33 PM, deadalnix wrote: call with const parameter can be considered strongly pure if the argument is immutable The argument doesn't need to be immutable because nobody can change it while the function is running. I explained the sentence just above how it is possible. Ignoring issue rarely help when it come to solve them. The delegate issue is a known one, and can be solved, and is not relevant to this point.
Re: Formal Review of std.process
The doc build linked in the first post says that the execute* return type might change to std.typecons.Tuple!(int,status,bool,output) – I suppose this should be »…, string, output«. Unfortunately, I probably won't manage to do an actual review before the deadline, but I didn't notice any obvious major issues. David
Re: DConf 2013 official car/room sharing thread
On 04/11/2013 10:49 AM, Steven Schveighoffer wrote: /me puts up thumb Me does a double take (yes, he is the Steven Schveighoffer of the D fame!). I hit the brakes and pick him up! :) Ali
Re: Formal Review of std.process
On Thursday, 11 April 2013 at 15:43:18 UTC, Steven Schveighoffer wrote: A couple minor comments: 1. I have two issues with Error being used. One is that we should have a specific type that is thrown, not raw Error type. Second is that I think in situations where the error is due to an incorrect parameter, it should be an exception not an error (and not a straight Exception either!). I agree for the most part. The 'environment' functions do throw straight Exceptions, and I'm not happy about that. I just don't like the idea of adding even more module-specific Exceptions and Errors, when what we really should do is decide on a systematic organisation for the entire library. Then again, maybe such a reorganisation will cause enough breakage that one more module makes little difference? Any good name suggestions for the errors and exceptions in question? 2. For the documentation of inheritFDs, it says that On Windows, this option has no effect. While this is true, it may give the impression that we don't set the bInheritHandles flag, which we do. I think there should be a note on that somewhere. I'll add one. Lars
Re: To help LDC/GDC
On 2013-04-11 15:53, Iain Buclaw wrote: I think that giving the user choice of purity is about as useful as given user choice over what functions should be inlined, or what vars should go in registers. Such decisions are best left to the compiler devs judgement on doing the right thing for you. Even if they sometimes get it wrong. :o) Beside from optimizations, it could good to be able to mark functions as pure, form a design point of view. I might be more easy to reason about a piece of code. -- /Jacob Carlborg
Re: Formal Review of std.process
On Thursday, 11 April 2013 at 17:56:17 UTC, David Nadlinger wrote: The doc build linked in the first post says that the execute* return type might change to std.typecons.Tuple!(int,status,bool,output) – I suppose this should be »…, string, output«. That's right. I'll fix it. Lars
Re: To help LDC/GDC
On 2013-04-11 15:38, Joseph Rushton Wakeling wrote: The point is to have a way for me, the programmer, to say to the compiler: I mean for this function to be strongly pure, can you confirm whether my choice of function inputs supports this please? Why should I have to explicitly specify immutable when that could be default for strongly pure functions? -- /Jacob Carlborg
Re: Formal Review of std.process
On 2013-04-11 17:43, Steven Schveighoffer wrote: A couple minor comments: 1. I have two issues with Error being used. One is that we should have a specific type that is thrown, not raw Error type. Second is that I think in situations where the error is due to an incorrect parameter, it should be an exception not an error (and not a straight Exception either!). Does it throw an Error, that's bad. Code should basically never create and throw an Error or Exception. It should always be a derived type from either of these classes. -- /Jacob Carlborg
Re: To help LDC/GDC
On 04/11/2013 07:48 AM, Walter Bright wrote: On 4/10/2013 10:44 PM, Timon Gehr wrote: On 04/10/2013 11:50 PM, Walter Bright wrote: ... My point was that competing designs are very probably not necessary. We just need to pull on the string on what must be. Yes, IMO it is quite obvious how to do it. (transfer the meaning of the modifiers from member functions to local functions, disallow conversion to const for delegates and disallow loading a mutable delegate from a const receiver.) However, I think there are other opinions. There will probably always be as long as nothing is specified as the official behaviour. A delegate works exactly like a member function call. It has an implicit 'this' pointer, and how the 'this' pointer is qualified, just like for a member function, determines how it works. That's still not sufficient as a specification. A member function may be qualified differently from the 'this' pointer and calling said member function may even be disallowed because of this. For delegates, the same syntax element is used for qualifying the context pointer and the function. Therefore delegates and member functions need to behave differently.
Re: Formal Review of std.process
On 2013-04-11 20:12, Lars T. Kyllingstad wrote: I agree for the most part. The 'environment' functions do throw straight Exceptions, and I'm not happy about that. I just don't like the idea of adding even more module-specific Exceptions and Errors, when what we really should do is decide on a systematic organisation for the entire library. Then again, maybe such a reorganisation will cause enough breakage that one more module makes little difference? Any good name suggestions for the errors and exceptions in question? EnvironmentException, SystemException, ProcessException. -- /Jacob Carlborg
Re: Formal Review of std.process
On 2013-04-04 16:22, Jesse Phillips wrote: I have decided to take on Review Manager for std.process and hopefully will keep it up and get through the review queue. This is slightly ignoring a first come, first serve approach, but that is mostly because I didn't want to look into it. (So don't be too upset). 1. Why is there functionality for handing environment variables in std.process? 2. The class environment should be capitalized -- /Jacob Carlborg
Re: Formal Review of std.process
On Thursday, 11 April 2013 at 18:32:23 UTC, Jacob Carlborg wrote: On 2013-04-04 16:22, Jesse Phillips wrote: I have decided to take on Review Manager for std.process and hopefully will keep it up and get through the review queue. This is slightly ignoring a first come, first serve approach, but that is mostly because I didn't want to look into it. (So don't be too upset). 1. Why is there functionality for handing environment variables in std.process? 2. The class environment should be capitalized Because it is manipulating the environment your process is running in? True, though I'd then say do what the original did and alias the class to its lowercase. Not that the result is any different though.
Re: DConf 2013 official car/room sharing thread
On Thu, 11 Apr 2013 14:07:06 -0400, Ali Çehreli acehr...@yahoo.com wrote: On 04/11/2013 10:49 AM, Steven Schveighoffer wrote: /me puts up thumb Me does a double take (yes, he is the Steven Schveighoffer of the D fame!). I hit the brakes and pick him up! :) And I humbly accept the ride from a D conference speaker and D book author! -Steve
Re: To help LDC/GDC
On 04/11/2013 08:16 PM, Jacob Carlborg wrote: Why should I have to explicitly specify immutable when that could be default for strongly pure functions? Oh, sorry, I misunderstood your meaning. I thought you were saying that a strong pure keyword wasn't necessary because it was sufficient to have pure with immutable/const input.
Re: PHP extension in D
On Thursday, 11 April 2013 at 11:28:05 UTC, gedaiu wrote:
Hi,
I want to extend Php with an extension written in D, and wrap
some D classes in php. My questions are:
1. How I can build a static library(I am using eclipse with ddt)
2. How I can create methods and create objects in c++ from the
D library.
Thanks,
Bogdan
I once tried to make a proof of concept PHP extension in D on an
Ubuntu Linux. I chose to make it simple by letting Swig
(www.swig.org) do the heavy wrapping work for me. It's then
becomes quite as much difficult as calling some D code from C.
Below is an outline of the steps it took me to wrap a D function
for PHP.
You'll still have to figure out how to make it work nicely with
Eclipse and on your particular platform, nonetheless it should
help you getting started.
Note that this approach could also be used to call some D code
from Java, C# or any other language supported by Swig.
1. Write / get the D code (speedup.d).
import std.stdio , std.string ; import std.conv : to;
string speedUp (string msg) {
writefln (-- %s --, msg);
return `sped up %s`.format (msg);
}
2. make a C API for that code, declaring the functions of that
API with the extern (C) qualifier.
extern (C) {
immutable (char) * d_speedUp (char * msg) {
return toStringz (speedUp (to!string (msg)));
}
}
3. Create a Swig interface file for that C API (speedup.i). Also
add a declaration to the rt_init function from the druntime.
%module speedup
char rt_init (long long);
const char * d_speedUp (char * msg);
4. run Swig: `swig -php speedup.i`. This will generate several
files:
- speedup_wrap.c
- php_speedup.h
- speedup.php
Now we've got to compile all those parts together: we want to
generate a speedup.so dynamic library object from all that we
got.
5. From what I researched, dmd (at least on Linux) needs to see a
main function to properly generate all the code of the druntime
within the dynamic library/shared object it generates. We will
trick it by adding a fake main function (dfakemain.d):
void main () {}
6. compile dfakemain.d:
dmd -c dfakemain.d
7. compile speedup.o:
dmd -fPIC -c -L-shared dfakemain.o speedup.d
8. compile speedup_wrap.o, you'll need to have everything needed
to compile extension for PHP on your platform:
gcc `php-config --includes` -fpic -c speedup_wrap.c
9. compile speedup.so, our target:
dmd -shared speedup_wrap.o dfakemain.o speedup.o -ofspeedup.so
10. If everything went well so far, you can now try your
extension within a script (dmd_speedup.php):
?php rt_init (0); // initialize the D runtime. echo d_speedUp
(hello from php), \n;
You can launch the script with extension loading enabled with a
command line such like this one:
php -d enable_dl=1 -d extension=`pwd`/speedup.so dmd_speedup.php
It should then output:
-- hello from php --
sped up hello from php
Now, one could imagine to get a bit further by automating all
that, like using the json output from dmd to generate a swig
interface file and a nice OOP interface on the PHP side, but this
would be much more work.
Have fun!
Re: Formal Review of std.process
On Thursday, 11 April 2013 at 18:32:23 UTC, Jacob Carlborg wrote: 2. The class environment should be capitalized It's implemented using a class, but you use it like an object. I think that is more important. Lars
Re: Disable GC entirely
On Thu, 11 Apr 2013 10:24:14 -0700 H. S. Teoh hst...@quickfur.ath.cx wrote: On Thu, Apr 11, 2013 at 02:39:01AM -0400, Nick Sabalausky wrote: The last 10 or so years, big-budget games have tended to be designed specifically so that anyone can get to the end without much effort. The lack of challenge makes them tedious and boring. OK, now I'm not so sure what I meant anymore, because I find this tedium and bore really tiring, whereas something like, say, the ancient Lode Runner with its incredibly complicated time-sensitive maneuvres is actually stimulating and, paradoxically enough, relaxing. OTOH, things like Quake and other FPSes I find exhausting, even if they're no more than mindless shoot-everything-that-moves deals. Maybe the difference lies in the simplicity of rules in the older 2D games -- yes they can be challenging but the mechanics are easy to grasp, whereas in 3D environments, the complexity of movement possibilities can be overwhelming. Ahh, I see what you mean, and I can relate. Maybe part of it is sensory overload. There's a lot more to take in. And there's more visual/auditory information to process and mentally filter out all the details to reach the core elements like this is an enemy, shoot here, this is an area of interest, go here, this is dangerous, avoid etc. And like you say, freedom of movement. Big-budget hold-your-hand games, OTOH, are tiring in another way, in a click-through ads kinda way. I have very little patience for anything with video clips, 'cos I rather be doing stuff instead of watching a video (I might as well watch youtube instead, etc.), yet I feel like I can't really get into the game if I don't endure through all those clips, 'cos I might miss some interesting game-world exposition or important story twist, etc.. So the result is that it's very tiring. Interesting points, yea. Personally, I don't feel afraid of missing out on such things unless it's a JRPG (whether action JRPG or menu-based) or it demonstrates a high degree of storytelling quality (*and* grabs my interest) right from the start, like Disgaea, Splinter Cell 1-3, Izuna, or Max Payne. (Just as examples.) Hmm. I beat nethack. Several times. I don't know of any other game that is as difficult to beat! But OTOH, its difficulty comes not from hand-eye coordination, but from the block-shuffling-puzzle type of inherent difficulty -- you have all the time in the world to think before making your next move, but your decision could mean the difference between life and death (i.e. the loss of the last 40 hours of gameplay, due to permadeath). I guess personally I prefer that kind of challenge to the how-fast-can-you-react kind. I like both kinds :) At least, provided that the how-fast-can-you-react also requires active thinking and accurate execution, too, as a good bullet-hell shmup or MegaMan, Contra, etc. But you see, that's precisely the kind of thing that wears me out. I feel like I'm not getting the max out of the game if I don't watch all the cutscenes / read all the dialogs, but then I have to endure through the whole thing when it's poorly written and then it's not enjoyable anymore. This is one of the things I really liked about the older Ultimas: the technology was such that dialogs were minimal, but that meant that they got the point across without needing to sit through long cutscenes / sift through convoluted dialogues. The trigger keywords were more-or-less obvious, so you just hit town, chat up the few obviously-important NPCs using the obviously important keywords, get the info you need, and move out and do stuff. I never really played the Ultimas (I've always been drawn more to JRPGs than to the DD/Tolkien-esque western RPGs). Although I do have a vague recollection of spending a few minutes in some 3D Ultima on DOS. But I do get what you're saying: I *love* Zelda 2-style dialog: Stop and rest here. Sorry. I know nothing. Only the hammer can destroy a roadblock. They cut straight to the chase and then shut up. I *love* that. Then the 16-bit ones expanded a bit and added a nice dash of character, but not overdone and still generally good. But modern NPCs talk the way my Dad does: They'll give you half their life story and entire social and emotional profile before finally getting to the point, and then they'll restate the damn point twenty times. Cliffs notes, people! ;) The free-exploration style of the old Ultimas was also something I liked very much. I find sequence-breakers in many modern games very mimesis-breaking, especially when it's something trivial like exploring and beating an area before talking to the NPC who was supposed to tell you to go there, thereby breaking some poorly-written script that assumes you haven't been there yet. Forcefully railroaded games I also find annoying (why is that gigantic boulder sitting there on the road blocking my way for no good reason other than that the game devs don't
Re: To help LDC/GDC
On Thursday, 11 April 2013 at 17:52:43 UTC, Walter Bright wrote: On 4/11/2013 3:02 AM, deadalnix wrote: On Thursday, 11 April 2013 at 00:41:01 UTC, Walter Bright wrote: On 4/10/2013 5:33 PM, deadalnix wrote: call with const parameter can be considered strongly pure if the argument is immutable The argument doesn't need to be immutable because nobody can change it while the function is running. I explained the sentence just above how it is possible. Ignoring issue rarely help when it come to solve them. The delegate issue is a known one, and can be solved, and is not relevant to this point. See Timon's post. Both are deeply linked.
Re: DIP 36: Rvalue References
On Wednesday, 10 April 2013 at 07:43:57 UTC, Dicebot wrote:
Consistent behavior is important but it does not change the
fact that there two types of rvalues in the language - raw
literals (42, A.init) and constructed temporaries (A()).
Accepting rvalues of the first type in as mutable references
may be consistent from the point of view of syntax by
_extremely_ confusing semantics-wise:
void foo(scope ref int x)
{
x = 32;
}
void main()
{
foo(42); // erm, 32 is the new 42 or ref is not actually
ref?
}
Beauty of in ref is that in that case user can't use it in
any way that may disclose the fact the temporary variable for
non-adressable entities is created. For mutable scope ref it is
not the case and we must leak implementation details, which is
never good.
Another concern is that if someone tries to pass 42 as a
mutable ref, most likely he does not really wants it to be
mutable and in ref is a better match.
This may not be consistent from the point of view of generic
code, but it is now consistent from the point of view of
programmer : A(...) construct always create temporaries, raw
value literals never do (well, they will for in ref but you
can't observe it). I think this is much more important.
One extra thing to note is that test32 may actually work if it
instantiates T as const int for 42 (making it in ref
essentially), but I don't know if D rules allow it.
I think this is another case of two different features which may
or may not be paired up together. If it is always okay to have A
accompany B, and B accompany A, it's good from a syntax point of
view because you only need one syntax for both of them. But if
you pair them up and later think, I wish I could do A without
having to do B, or B without having to do A, then you'll regret
pairing them up because you'll either have to break code or live
with what you've got.
When you say we shouldn't be able to return an rvalue
temporaries, even if they're safe, I think it's reasonable, not a
life or death issue. But if 'scope ref' is used to mean that,
you're also saying that any *other* feature which wants 'scope',
such as 'ref' safety (why I created DIP35, to highlight this),
will automatically also have to take rvalue temps because they're
bound up with it, it's more risky.
Some of these will be a judgment call - A and B are sometimes so
similar that it's better to save on syntax than differentiate
them. 'const scope' might be the same way.
Re: DConf 2013 official car/room sharing thread
On 2 April 2013 21:18, Iain Buclaw ibuc...@ubuntu.com wrote: On Monday, 25 March 2013 at 01:59:07 UTC, Manu wrote: I'm keen to share a room/ride with someone. I have no plans yet. Arrive on the 29th of April in SFO. I look set to be arriving on the 29th at SFO also. Maybe could hook up! :) Sure! I arrive at midday. I see you pondering flying to SJC? It's an easy bart ride from SFO - San Jose, I'd save the money if I were you, the train is convenient, and it sounds like there might be cars heading past. When do you land?
Vote for std.process
It is that time, If you would like to see the proposed std.process include into Phobos please vote yes. If one condition must be met specify under what condition, otherwise vote no. std.process by Lars Kyllingstad and Steven Schveighoffer is a suggested improvement to the existing std.process and is a major change to the API. The original API remains but these will be going through deprecation. In summary of the discussion there was concern of the use of Error and Exception. Lars is very interested in getting the standard hierarchy http://wiki.dlang.org/DIP33 thus leaving these at the safest level to allow for change without breaking code. Please place any further comments in the official review thread leaving only your vote and a short comment (there should be no need to reply to anyone). Docs: http://www.kyllingen.net/code/std-process2/phobos-prerelease/std_process.html Source: https://github.com/kyllingstad/phobos/blob/std-process2/std/process.d Friday April 19 PST will be the last day of voting.
Re: Vote for std.process
On Friday, 12 April 2013 at 04:46:52 UTC, Jesse Phillips wrote: It is that time, If you would like to see the proposed std.process include into Phobos please vote yes. Yes!
Re: DConf 2013 official car/room sharing thread
On 04/11/2013 08:43 PM, Manu wrote: It's an easy bart ride from SFO - San Jose That is planned for the future. :) BART doesn't go to San Jose. Ali
Re: DConf 2013 official car/room sharing thread
On 12 April 2013 15:49, Ali Çehreli acehr...@yahoo.com wrote: On 04/11/2013 08:43 PM, Manu wrote: It's an easy bart ride from SFO - San Jose That is planned for the future. :) BART doesn't go to San Jose. Oh right, well it's some other train then? I've had no trouble getting trains between SF and SJ...
Re: DWT2 building
On 2013-04-10 20:57, JohnnyK wrote: Nevermind I found it. Sorry I have not used D since version 1.x and I did not do much with it at that time. No problem :) -- /Jacob Carlborg
Re: DWT2 building
On 2013-04-10 19:41, JohnnyK wrote: The instructions say to use the rdmd program. What is the rdmd program? The copy of D version 2 that I have does not have rdmd with it. Also I assume that dwt will work with D version 2 and the phobos library correct? I see that you already found rdmd. Yes, DWT works with D2 and Phobos. The combinations are: * D2 with Phobos * D1 with Tango -- /Jacob Carlborg
Re: memory leaks in phobos?
On 04/10/2013 10:04 PM, Andrey wrote: Hello!
int arr[];
int length = 100_000_000;
for (int i=0; i10; i++)
{
arr.length = length; // always new memory blocks, why?
The slice does not know what other slices may be sharing the same
elements. So, increasing the length of a slice will relocate the
elements (almost always, with exceptions.) The following article goes
into a lot of detail:
http://dlang.org/d-array-article.html
arr[90] = 20;
writeln(After allocation. Press a key.);
stdin.readln();
clear(arr);
arr.length = 0; // must be deallocation? but nothing happens
Are you compiling as a 32-bit application? Then, chances are random bit
patterns look like references into these slices. (dmd uses a
conservative garbage collector). Try compiling with -m64.
Ali
Re: Range returning an array
On 04/10/2013 08:22 PM, Jesse Phillips wrote: I'm pretty sure he realizes this, his original code shows how he is doing this. He expects 'output' to hold the final front value, but instead it holds the empty value. Joseph, I think you will have to profile to decide which is the fastest for your use case. Agree. I do also see the risks in these assumptions with respect to front -- they can be safely worked around within my code but it's not a very friendly construction to put in front of other people.
Re: Range returning an array
On 04/10/2013 01:18 AM, Steven Schveighoffer wrote: Calling front after empty is not good range policy, once empty, front is possibly invalid or points at invalid memory. It's not necessarily required to actually call front with the range empty: one could do something like, for(; !sim.empty; sim.popFront()) v = sim.front; ... and the way that popFront() operates means that, while the output of front() may be transient in general, the last value will remain. Though I agree that, even in this case, it's is a potentially problematic situation (there's something weird about the idea of a range that is transient except for the last entry). I will have to profile with .dup enabled and see what changes.
Re: memory leaks in phobos?
On Thursday, 11 April 2013 at 06:39:53 UTC, Traveler wrote: On 64 bit may cause crash: arr.length = length, fixed in next version. arr.length = 0; // must be deallocation? Not necessarily. You can manually do a garbage collection. The manual calling function GC.collect() has no effect (tested under x32 and x64 versions). = ... clear(arr); arr.length = 0; GC.collect(); // useless calling, the used memory will be increase writeln(After dispose. Press a key.); stdin.readln(); ... =
[Issue 9899] struct with pure/nothrow destructor cannot be used as a struct member in pure/nothrow functions
http://d.puremagic.com/issues/show_bug.cgi?id=9899 --- Comment #2 from github-bugzi...@puremagic.com 2013-04-10 23:46:48 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a886e55abe29ed1ffe05ba154e2977443ad808ec fix Issue 9899 - struct with pure/nothrow destructor cannot be used as a struct member in pure/nothrow functions https://github.com/D-Programming-Language/dmd/commit/5a0d812059995186860a418735c77e432b05500e Merge pull request #1866 from 9rnsr/fix9899 Issue 9899 - struct with pure/nothrow destructor cannot be used as a struct member in pure/nothrow functions -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9899] struct with pure/nothrow destructor cannot be used as a struct member in pure/nothrow functions
http://d.puremagic.com/issues/show_bug.cgi?id=9899 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9571] link error due to using unique ids in anonymous funcliteral
http://d.puremagic.com/issues/show_bug.cgi?id=9571 Dicebot m.stras...@gmail.com changed: What|Removed |Added Keywords|pull| --- Comment #9 from Dicebot m.stras...@gmail.com 2013-04-11 00:32:09 PDT --- Thanks for tracking down the root cause for this specific issue. I'll move my pull request to its own issue then. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9916] int*[] implicitly converts to int*
http://d.puremagic.com/issues/show_bug.cgi?id=9916 --- Comment #2 from phyph...@gmail.com 2013-04-11 01:32:09 PDT --- Yes, but the problem is it is compiling without error on 2.062 and that breaks stuff -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3703] static array assignment
http://d.puremagic.com/issues/show_bug.cgi?id=3703 --- Comment #3 from github-bugzi...@puremagic.com 2013-04-11 01:36:43 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f703c5c6551affddd9213f759657a2b3e391b935 More fix for issue 3703 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2356] array literal as non static initializer generates horribly inefficient code.
http://d.puremagic.com/issues/show_bug.cgi?id=2356 --- Comment #18 from github-bugzi...@puremagic.com 2013-04-11 01:36:48 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8cd5f790a78e7514e46618d0325e92cbd6e00e48 fix Issue 2356 - array literal as non static initializer generates horribly inefficient code. https://github.com/D-Programming-Language/dmd/commit/d4b20baee7a1c9ee8a9271724feb5d1031e773d4 Merge pull request #1883 from 9rnsr/fix2356 Issue 2356 - array literal as non static initializer generates horribly inefficient code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9539] Wrong implicit conversion of array to pointer
http://d.puremagic.com/issues/show_bug.cgi?id=9539 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||phyph...@gmail.com --- Comment #7 from Kenji Hara k.hara...@gmail.com 2013-04-11 01:54:36 PDT --- *** Issue 9916 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9916] int*[] implicitly converts to int*
http://d.puremagic.com/issues/show_bug.cgi?id=9916 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||rejects-valid Component|Phobos |DMD Resolution|INVALID |DUPLICATE --- Comment #3 from Kenji Hara k.hara...@gmail.com 2013-04-11 01:54:35 PDT --- (In reply to comment #2) Yes, but the problem is it is compiling without error on 2.062 and that breaks stuff Oh... I completely had mistaken. Sorry confusion by my wrong comment. Yes, this is actually a regression. It had occurred from 2.061, and still exists in 2.062. Fortunately, this regression had been found in the 2.063 devel, and already fixed in bug 9539. You would get the fix in 2.063 release. Thanks! *** This issue has been marked as a duplicate of issue 9539 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
