Re: Getting ready for 2.061
On Friday, December 21, 2012 21:11:28 Jonathan M Davis wrote: > On Friday, December 21, 2012 17:12:47 Andrei Alexandrescu wrote: > > We plan to start building a new release on Sunday evening. To do so > > (pursuant to the embryonic process we're putting in place), at that time > > we'll create a new branch called "staging" for each of dmd, druntime, > > and phobos. > > > > All contributors - over the weekend please ping reviewers on what you > > believe are pull requests with a high importance*urgency product. Once > > we branch into staging, pull requests will only be merged into master. > > https://github.com/D-Programming-Language/dmd/pull/1287 > > really should be resolved prior to 2.061, or we're going to be introducing a > compiler flag (-di) which we're probably then going to turn around and > deprecate (and making deprecations warn by default instead of giving you an > error will be _huge_ step forward in our ability to manage deprecations > without breaking people's code). LOL. David was talking about the thing in his reply. I read it too quickly and thought that he was talking about the warning for the change in UDA syntax. In any case, I obviously agree with him. This issue needs to be resolved prior to the nex release. - Jonathan M Davis
Re: Getting ready for 2.061
On Friday, December 21, 2012 17:12:47 Andrei Alexandrescu wrote: > We plan to start building a new release on Sunday evening. To do so > (pursuant to the embryonic process we're putting in place), at that time > we'll create a new branch called "staging" for each of dmd, druntime, > and phobos. > > All contributors - over the weekend please ping reviewers on what you > believe are pull requests with a high importance*urgency product. Once > we branch into staging, pull requests will only be merged into master. https://github.com/D-Programming-Language/dmd/pull/1287 really should be resolved prior to 2.061, or we're going to be introducing a compiler flag (-di) which we're probably then going to turn around and deprecate (and making deprecations warn by default instead of giving you an error will be _huge_ step forward in our ability to manage deprecations without breaking people's code). - Jonathan M Davis
Re: ICE 0.1: a moddable shoot-em-up in D
On Saturday, 22 December 2012 at 00:48:51 UTC, Kiith-Sa wrote: Are you sure you cloned ICE, not DPong? DPong was an older project that is unmaintained; although ICE reuses some of its code. ICE is developed with 2.060 and there're no compile errors there (although there are some warnings due to keeping backwards compatibility with DMD 2.058) ICE git repo: https://github.com/kiith-sa/ICE I did a grep and found some mentions of "pong" in ICE codebase, but it was just comments and an outdated packaging script (which I removed). Nothing that would affect compilation. I thought I downloaded from the link posted, but for all I know I did something horribly wrong, so I'll try cloning directly from git this time. If it works, I'll post that in here. Thanks. --rt
Re: ICE 0.1: a moddable shoot-em-up in D
Also note: ICE does have some compile errors with git master DMD; at least because it uses D:YAML, which has known issues there. Bot there are no errors with DMD 2.060.
Re: ICE 0.1: a moddable shoot-em-up in D
On Friday, 21 December 2012 at 22:00:27 UTC, Rob T wrote: I get a few compilation errors using dmd 2.060, nothrow that can throw, pure that calls impure, as well as several warnings such as unreachable code and warnings concerning @safe and @trusted. After patching some of it up to get rid of the fatal compile errors, this last error left me scratching my head [Errno 2] No such file or directory: 'pong-debug' I had to give up, but I'm still interested in getting this game to work, so please let us know when you manage to solve these problems. thanks! --rt Are you sure you cloned ICE, not DPong? DPong was an older project that is unmaintained; although ICE reuses some of its code. ICE is developed with 2.060 and there're no compile errors there (although there are some warnings due to keeping backwards compatibility with DMD 2.058) ICE git repo: https://github.com/kiith-sa/ICE I did a grep and found some mentions of "pong" in ICE codebase, but it was just comments and an outdated packaging script (which I removed). Nothing that would affect compilation.
Re: Getting ready for 2.061
On Friday, 21 December 2012 at 22:12:47 UTC, Andrei Alexandrescu wrote: All contributors - over the weekend please ping reviewers on what you believe are pull requests with a high importance*urgency product. DMD #1287 is still pending a response by Walter. I explained why I think it is urgent in the earlier thread (http://forum.dlang.org/post/srzxakcwamzzzvqct...@forum.dlang.org), but I think the issue got lost in the wake of the UDA discussion. David
Getting ready for 2.061
We plan to start building a new release on Sunday evening. To do so (pursuant to the embryonic process we're putting in place), at that time we'll create a new branch called "staging" for each of dmd, druntime, and phobos. All contributors - over the weekend please ping reviewers on what you believe are pull requests with a high importance*urgency product. Once we branch into staging, pull requests will only be merged into master. Thanks, Andrei
Re: Amber
Lars Ivar Igesund: Project page: https://bitbucket.org/larsivi/amber Seems a good idea to test some alternative designs, alternative features and alternative ideas. What are the differences (present or planned) between D1 and Amber? Bye, bearophile
Re: ICE 0.1: a moddable shoot-em-up in D
I get a few compilation errors using dmd 2.060, nothrow that can throw, pure that calls impure, as well as several warnings such as unreachable code and warnings concerning @safe and @trusted. After patching some of it up to get rid of the fatal compile errors, this last error left me scratching my head [Errno 2] No such file or directory: 'pong-debug' I had to give up, but I'm still interested in getting this game to work, so please let us know when you manage to solve these problems. thanks! --rt
Re: Amber
On 2012-12-21 19:02, Lars Ivar Igesund wrote: Dear D community, I've been urged by many others to post about Amber here. It is a programming language being derived from D1, with a compiler written using D1 and Tango, with LLVM and C backends. The quality of code and documention is alpha (or pre-alpha). Project page: https://bitbucket.org/larsivi/amber Background: http://www.dsource.org/projects/tango/forums/topic/920 Interesting, I haven't read all links yet but interesting. -- /Jacob Carlborg
Re: ICE 0.1: a moddable shoot-em-up in D
On 2012-12-21 14:13, Kiith-Sa wrote: This shouldn't happen as I don't even use that extension. It's possible that it's a bug in ICE's (outdated) copy of Derelict2. I updated Derelict2 now. Can you try pulling the changes? I'll give it a try. -- /Jacob Carlborg
Amber
Dear D community, I've been urged by many others to post about Amber here. It is a programming language being derived from D1, with a compiler written using D1 and Tango, with LLVM and C backends. The quality of code and documention is alpha (or pre-alpha). Project page: https://bitbucket.org/larsivi/amber Background: http://www.dsource.org/projects/tango/forums/topic/920 We hold house in #amber on Freenode. Regards, Lars Ivar Igesund larsivi @ #amber on Freenode
Re: [OT] Three Optimization Tips for C++
On 12/21/12 7:23 AM, Peter Alexander wrote: On Thursday, 20 December 2012 at 05:29:46 UTC, Andrei Alexandrescu wrote: Vote up! http://www.reddit.com/r/programming/comments/155ivw/three_optimization_tips_for_c_video/ Andrei I think the most interesting thing from that talk is when you said that Facebook's back end code is spending 15% of its time converting ints to strings. Not all back end code. Certain applications. I know you are looking at these small functions as simple examples of the optimisation tips you are giving, but I hope this isn't the kinds of optimisations you are doing at the Facebook. The problem isn't that the conversion is slow, the problem is that you are converting at all. Don't use text based formats for performance sensitive data! Of course, maybe the 15% claim was pure exaggeration. I really hope that's the case. Text representation has its own advantages. Andrei
Re: ICE 0.1: a moddable shoot-em-up in D
On Friday, 21 December 2012 at 07:54:19 UTC, Jacob Carlborg wrote: On 2012-12-20 19:41, Kiith-Sa wrote: This is the first release of ICE, a small game project I'm working on at the university. ICE is a vertical shoot-em-up created with moddability in mind. Its gameplay resembles games like Tyrian and Raptor: Call of the Shadows. I've compiled the game on Mac OS X now and get the following runtime error: Failed to construct a video.sdlglvideodriver.SDLGLVideoDriver: Could not load OpenGL: Failed to load symbol glMatrixIndexPointerARB from shared library ../Frameworks/OpenGL.framework/OpenGL Perhaps you need to install new graphics drivers? Segmentation fault This is on a computer using Mac OS X 10.6, I'll try later on a Mac OS X 10.8 computer. Fork: https://github.com/jacob-carlborg/ICE/tree/osx This shouldn't happen as I don't even use that extension. It's possible that it's a bug in ICE's (outdated) copy of Derelict2. I updated Derelict2 now. Can you try pulling the changes?
Re: [OT] Three Optimization Tips for C++
On Thursday, 20 December 2012 at 05:29:46 UTC, Andrei Alexandrescu wrote: Vote up! http://www.reddit.com/r/programming/comments/155ivw/three_optimization_tips_for_c_video/ Andrei Nice talk. For anybody interested, PIC was made a bit faster by x64 due to introduction of RIP-relative addressing. Here is a concise and well-written article describing an x64 PIC implementation http://eli.thegreenplace.net/2011/11/11/position-independent-code-pic-in-shared-libraries-on-x64/.
Re: [OT] Three Optimization Tips for C++
On Thursday, 20 December 2012 at 05:29:46 UTC, Andrei Alexandrescu wrote: Vote up! http://www.reddit.com/r/programming/comments/155ivw/three_optimization_tips_for_c_video/ Andrei I think the most interesting thing from that talk is when you said that Facebook's back end code is spending 15% of its time converting ints to strings. I know you are looking at these small functions as simple examples of the optimisation tips you are giving, but I hope this isn't the kinds of optimisations you are doing at the Facebook. The problem isn't that the conversion is slow, the problem is that you are converting at all. Don't use text based formats for performance sensitive data! Of course, maybe the 15% claim was pure exaggeration. I really hope that's the case.
Re: [OT] Three Optimization Tips for C++
Andrei Alexandrescu: http://www.reddit.com/r/programming/comments/155ivw/three_optimization_tips_for_c_video/ I appreciate such slides and videos, thank you for sharing. But If possible I'd like a link to the slides in a place where I don't have to register to download them. I have also just seen this other slides pack from Jordan DeLong, it is very interesting, it's about a topic that is usually regarded as one of the strongest points of functional languages (that is using types to "make illegal states unrepresentable"): http://www.reddit.com/r/cpp/comments/1571m9/facebook_nyc_tech_talk_jordan_delong_using/ Bye, bearophile
