Re: Mac OS installer

On 2013-01-08 05:00, Elias Zamaria wrote: I am trying to upgrade to DMD 2.061. What am I supposed to do? I tried running the installer but I got the same error I got the last time (see http://forum.dlang.org/thread/yrcyfaalimocuovsv...@forum.dlang.org or http://forum.dlang.org/thread/bug-868...@h

Re: manual memory management

On Monday, 7 January 2013 at 23:13:13 UTC, H. S. Teoh wrote: ... Crippling the language to cater to the 10% crowd who want to squeeze every last drop of performance from the hardware is the wrong approach IMO. T Agreed. Having used GC languages for the last decade, I think the cases whe

Re: dlangspec.pdf?

Al 07/01/13 20:19, En/na Andrei Alexandrescu ha escrit: > On 1/7/13 10:23 AM, Andrei Alexandrescu wrote: >> On 1/7/13 9:30 AM, H. S. Teoh wrote: >>> On Mon, Jan 07, 2013 at 02:35:09AM -0500, Andrei Alexandrescu wrote: ??? I already have something in progress. >>> [...] >>> >>> Curious ears wan

Re: Mac OS installer

On Monday, 22 October 2012 at 13:45:10 UTC, Adam D. Ruppe wrote: I was recently involved in a stack overflow question about mac os: http://stackoverflow.com/questions/12832241/cant-install-dmd-2-060-on-os-x-10-6-8/12897850 I gave my usual answer of "just use the zip" which solved the problem

Re: Mac OS installer

On Tue, 2013-01-08 at 13:33 +0100, Mengu wrote: […] > there is a homebrew recipe. > > brew install dmd Has anyone got a port into MacPorts? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win..

Re: shared gitconfig

On Tuesday, 8 January 2013 at 07:07:18 UTC, Andrei Alexandrescu wrote: This script is bad because it does not do any meaningful error handling and offers no good explanation on how to proceed if either step fails. Indeed - I wanted to avoid using any syntax / commands that someone wouldn't us

Updating other compiler frontends [was D 1.076 and 2.061 release]

On Tuesday, 1 January 2013 at 23:46:32 UTC, Walter Bright wrote: The big news is Win64 is now supported (in alpha). http://www.digitalmars.com/d/download.html D 1.076 changelog: http://www.digitalmars.com/d/1.0/changelog.html A couple issues: 1. the dlang.org isn't updated yet. 2. the OS X

Re: manual memory management

On Monday, 7 January 2013 at 17:19:25 UTC, Jonathan M Davis wrote: On Monday, January 07, 2013 17:55:35 Rob T wrote: On Monday, 7 January 2013 at 16:12:22 UTC, mist wrote: > How is D manual memory management any worse than plain C one? > Plenty of language features depend on GC but stuff that is

Re: manual memory management

On Tue, Jan 08, 2013 at 10:29:26AM +0100, Paulo Pinto wrote: > On Monday, 7 January 2013 at 23:13:13 UTC, H. S. Teoh wrote: > >... > > > >Crippling the language to cater to the 10% crowd who want to squeeze > >every last drop of performance from the hardware is the wrong > >approach IMO. [...] > Ag

Re: manual memory management

Am 08.01.2013 16:25, schrieb H. S. Teoh: On Tue, Jan 08, 2013 at 10:29:26AM +0100, Paulo Pinto wrote: On Monday, 7 January 2013 at 23:13:13 UTC, H. S. Teoh wrote: ... Crippling the language to cater to the 10% crowd who want to squeeze every last drop of performance from the hardware is the wr

Re: manual memory management

On Tue, Jan 08, 2013 at 04:31:45PM +0100, Benjamin Thaut wrote: > Am 08.01.2013 16:25, schrieb H. S. Teoh: [...] > >Game engines, OTOH, are a step away from hard real-time applications, > >where pause-the-world GCs are unacceptable. While it isn't fatal for > >a game engine to pause every now and t

Re: manual memory management

Am 08.01.2013 16:46, schrieb H. S. Teoh: So how much experience do you have with game engine programming to make such statements? [...] Not much, I'll admit. So maybe I'm just totally off here. But the last two sentences weren't specific to game code, I was just making a statement about softwar

std.random2

Hello all, Following discussion on the pull request adding normal random number generation to std.random [ https://github.com/D-Programming-Language/phobos/pull/1029 ], some issues were raised which are best discussed with the whole community. The heart of this is the design of pseudo-random

Re: manual memory management

On 01/08/2013 03:43 PM, ixid wrote: Just speaking as a bystander but I believe it is becoming apparent that a good guide to using D without the GC is required. I'd second that. I've tried on a couple of occasions to use D with a minimal-to-no GC approach (e.g. using std.container.Array in pla

Re: std.random2

On Tuesday, 8 January 2013 at 17:52:24 UTC, Joseph Rushton Wakeling wrote: Hello all, Following discussion on the pull request adding normal random number generation to std.random [ https://github.com/D-Programming-Language/phobos/pull/1029 ], some issues were raised which are best discussed

Re: manual memory management

On Tuesday, 8 January 2013 at 15:27:21 UTC, H. S. Teoh wrote: But then again, considering the bulk of all software being written today, how much code is actually mission-critical real-time apps or game engine cores? You also need to consider the market for D. Performance is one of D's key se

Re: std.random2

On 01/08/2013 07:38 PM, ixid wrote: I imagine there has been some detailed discussion of the std.nameX idea of libraries so forgive me if this has been discussed. I appreciate your concern on this point, but I don't think it's the right thing to focus on in this specific discussion. What I r

Official DMD compiler written in D

Now that D 2.0 is fairly stable, are there any plans of writing the official DMD compiler with the D 2.0 language vs the present language of C++? DMD 2.0 would have to be feature frozen and then DMD 3.0 could be written with the previous DMD 2.0 compiler. What are your thoughts?

Re: manual memory management

On Monday, January 07, 2013 23:26:02 Rob T wrote: > Is this a hard fact, or can there be a way to make it work? For > example what about the custom allocator idea? > > From a marketing POV, if the language can be made 100% free of > the GC it would at least not be a deterrent to those who cannot >

Re: manual memory management

On 01/08/2013 08:09 PM, Jonathan M Davis wrote: It's a hard fact. Some features (e.g. appending to an array) require the GC and will always require the GC. There may be features which currently require the GC but shouldn't necessarily require it (e.g. AAs may fall in that camp), but some features

Re: manual memory management

On 2013-01-08 17:12, Benjamin Thaut wrote: So to give a little background about me. I'm currently doing my masters degree in informatics which is focused on media related programming. (E.g. games, applications with other visual output, mobile apps, etc). Besides my studies I'm working at Havok,

Re: Mac OS installer

On 2013-01-08 05:00, Elias Zamaria wrote: I am trying to upgrade to DMD 2.061. What am I supposed to do? I tried running the installer but I got the same error I got the last time (see http://forum.dlang.org/thread/yrcyfaalimocuovsv...@forum.dlang.org or http://forum.dlang.org/thread/bug-868...@h

Re: std.random2

On Tue, Jan 08, 2013 at 07:46:46PM +0100, Joseph Rushton Wakeling wrote: > On 01/08/2013 07:38 PM, ixid wrote: > >I imagine there has been some detailed discussion of the std.nameX > >idea of libraries so forgive me if this has been discussed. > > I appreciate your concern on this point, but I don

Re: std.random2

On Tuesday, 8 January 2013 at 20:40:00 UTC, H. S. Teoh wrote: On Tue, Jan 08, 2013 at 07:46:46PM +0100, Joseph Rushton Wakeling wrote: On 01/08/2013 07:38 PM, ixid wrote: >I imagine there has been some detailed discussion of the >std.nameX >idea of libraries so forgive me if this has been disc

Re: std.random2

09-Jan-2013 00:38, H. S. Teoh пишет: On Tue, Jan 08, 2013 at 07:46:46PM +0100, Joseph Rushton Wakeling wrote: On 01/08/2013 07:38 PM, ixid wrote: I imagine there has been some detailed discussion of the std.nameX idea of libraries so forgive me if this has been discussed. I appreciate your co

Re: manual memory management

On Tuesday, January 08, 2013 20:32:29 Joseph Rushton Wakeling wrote: > On 01/08/2013 08:09 PM, Jonathan M Davis wrote: > > It's a hard fact. Some features (e.g. appending to an array) require the > > GC > > and will always require the GC. There may be features which currently > > require the GC but

Re: shared gitconfig

On Monday, January 07, 2013 17:54:40 Andrei Alexandrescu wrote: > I know how the shell works quite well but that doesn't stop me from > writing scripts and aliases. > > This boils down to advocating one needs to type by hand sequences of > commands instead of defining higher-level scripts that hav

Re: Official DMD compiler written in D

On Tue, Jan 08, 2013 at 07:48:58PM +0100, Tim Krimm wrote: > > Now that D 2.0 is fairly stable, are there any plans of writing the > official DMD compiler with the D 2.0 language vs the present > language of C++? > > DMD 2.0 would have to be feature frozen and then DMD 3.0 could be > written with

Re: manual memory management

On 1/7/2013 6:23 PM, Brad Roberts wrote: My primary point being, blaming the GC when it's the application style that generates enough garbage to result in wanting to blame the GC for the performance cost is misplaced blame. True dat. There is no such thing as a memory allocation technology that

Re: manual memory management

On 1/7/2013 3:11 PM, H. S. Teoh wrote: I think much of the aversion to GCs is misplaced. I used to be very aversive of GCs as well, so I totally understand where you're coming from. I used to believe that GCs are for lazy programmers who can't be bothered to think through their code and how to m

Re: dlangspec.pdf?

On 1/4/13 7:53 PM, Andrei Alexandrescu wrote: Now that the issue of documentation came up, I wonder if there's interest in a high-quality PDF rendering of the language spec (e.g. similar to the interior design of TDPL itself). Is it worth the effort? Thanks, Andrei I just pushed the first pas

Re: manual memory management

Am 08.01.2013 16:25, schrieb H. S. Teoh: On Tue, Jan 08, 2013 at 10:29:26AM +0100, Paulo Pinto wrote: On Monday, 7 January 2013 at 23:13:13 UTC, H. S. Teoh wrote: ... Crippling the language to cater to the 10% crowd who want to squeeze every last drop of performance from the hardware is the wr

Re: manual memory management

On Tuesday, 8 January 2013 at 15:27:21 UTC, H. S. Teoh wrote: But then again, considering the bulk of all software being written today, how much code is actually mission-critical real-time apps or game engine cores? I suspect real-time apps are <5% of all software, and while games are a rapidly

Re: manual memory management

Am 08.01.2013 17:12, schrieb Benjamin Thaut: Am 08.01.2013 16:46, schrieb H. S. Teoh: So how much experience do you have with game engine programming to make such statements? [...] Not much, I'll admit. So maybe I'm just totally off here. But the last two sentences weren't specific to game cod

Re: dlangspec.pdf?

On 1/8/2013 2:51 PM, Andrei Alexandrescu wrote: I just pushed the first passable PDF documentation generated via LaTeX with ddoc: http://goo.gl/QIP4t. For now I'm only rendering the TOC and lex.dd, but at this time we have enough seed for anyone interested to convert other files. Take a look at

Re: manual memory management

On Tuesday, 8 January 2013 at 18:35:19 UTC, Peter Alexander wrote: You also need to consider the market for D. Performance is one of D's key selling points. If it had the performance of Python then D would be a much less interesting language, and I honestly doubt anyone would even look at it.

Re: Updating other compiler frontends [was D 1.076 and 2.061 release]

On 1/8/2013 5:49 AM, Iain Buclaw wrote: Would a target.h header be fine for this? Or do you have somewhere else in mind. I think a target.h/target.c would be a good addition. In general, I'd like to see all #ifdef's removed from the main dmd source code. Host and target specific behaviors s

Re: manual memory management

On Tuesday, 8 January 2013 at 16:12:41 UTC, Benjamin Thaut wrote: My impression so far: No one who is writing a tripple A gaming title or engine is only remotly interested in using a GC. Game engine programmers almost do anything to get better performance on a certain plattform. There are reall

Re: dlangspec.pdf?

On Wed, Jan 9, 2013 at 12:12 AM, Walter Bright wrote: >> Take a look at the generated PDF: http://erdani.com/d/dlangspec.pdf > Looks good to me. Yes, that has indeed quite a palatable appearance. I see you defined 2 or 3-cols tables, that's a good idea. Too bad DDoc macros do not accept numerica

Re: manual memory management

On Tuesday, 8 January 2013 at 23:12:43 UTC, Rob T wrote: The only major thing that concerns me is the lack of proper shared library support. I hope this omission is resolved soon. What do you need it for? Runtime loading of D shared objects? Or just linking to them (i.e. binding by ld/dyld at

Re: manual memory management

On 01/08/2013 10:43 PM, Jonathan M Davis wrote: std.container.Array and built-in arrays are _very_ different. Array is a container, not a range. You can slice it to get a range and operate on that, but it's not a range itself. Is there a particular reason why Array can't have a range interface

Re: dlangspec.pdf?

On 1/8/13 3:12 PM, Walter Bright wrote: On 1/8/2013 2:51 PM, Andrei Alexandrescu wrote: I just pushed the first passable PDF documentation generated via LaTeX with ddoc: http://goo.gl/QIP4t. For now I'm only rendering the TOC and lex.dd, but at this time we have enough seed for anyone interested

Re: manual memory management

On 1/8/13 3:30 PM, David Nadlinger wrote: On Tuesday, 8 January 2013 at 23:12:43 UTC, Rob T wrote: The only major thing that concerns me is the lack of proper shared library support. I hope this omission is resolved soon. What do you need it for? Runtime loading of D shared objects? Or just li

Re: dlangspec.pdf?

On 1/8/13 3:31 PM, Philippe Sigaud wrote: On Wed, Jan 9, 2013 at 12:12 AM, Walter Bright wrote: Take a look at the generated PDF: http://erdani.com/d/dlangspec.pdf Looks good to me. Yes, that has indeed quite a palatable appearance. I see you defined 2 or 3-cols tables, that's a good idea

Re: std.random2

On 01/08/2013 10:05 PM, monarch_dodra wrote: I'd argue PRNG's should even be forward ranges. For one, the actual saving would be duplicating the PRNG payload itself (very costly). Further more, it would mean the danger of duplicate sequence still exist: a lot of algorithms, such a "fill", start b

Re: Official DMD compiler written in D

On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote: On Tue, Jan 08, 2013 at 07:48:58PM +0100, Tim Krimm wrote: Now that D 2.0 is fairly stable, are there any plans of writing the official DMD compiler with the D 2.0 language vs the present language of C++? DMD 2.0 would have to be

Re: dlangspec.pdf?

On Tue, Jan 08, 2013 at 02:51:44PM -0800, Andrei Alexandrescu wrote: > On 1/4/13 7:53 PM, Andrei Alexandrescu wrote: > >Now that the issue of documentation came up, I wonder if there's > >interest in a high-quality PDF rendering of the language spec (e.g. > >similar to the interior design of TDPL i

Re: Official DMD compiler written in D

On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote: We *could* write a cross-compiler, of course, but it still requires that you first target the D compiler (written in D) to the new platform, and then cross-compile itself to that platform. Whereas with DMD, you just use the target p

Re: Official DMD compiler written in D

On Wed, Jan 09, 2013 at 01:33:35AM +0100, David Nadlinger wrote: > On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote: > >We *could* write a cross-compiler, of course, but it still requires > >that you first target the D compiler (written in D) to the new > >platform, and then cross-compi

Re: manual memory management

On Wednesday, January 09, 2013 00:37:10 Joseph Rushton Wakeling wrote: > On 01/08/2013 10:43 PM, Jonathan M Davis wrote: > > std.container.Array and built-in arrays are _very_ different. Array is a > > container, not a range. You can slice it to get a range and operate on > > that, but it's not a r

Re: dlangspec.pdf?

On 1/8/2013 3:57 PM, Andrei Alexandrescu wrote: One great thing about ddoc is that macros are infinitely flexible, and the expansion rules are not as weird as other macro systems such as M4. I had one great advantage in it being the fifth text macro processor I'd designed :-) I'd still like

Re: Official DMD compiler written in D

On 01/08/2013 06:38 PM, H. S. Teoh wrote: On Wed, Jan 09, 2013 at 01:33:35AM +0100, David Nadlinger wrote: On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote: We *could* write a cross-compiler, of course, but it still requires that you first target the D compiler (written in D) to the

Re: manual memory management

On Wed, Jan 09, 2013 at 12:21:05AM +0100, deadalnix wrote: > On Tuesday, 8 January 2013 at 16:12:41 UTC, Benjamin Thaut wrote: > >My impression so far: No one who is writing a tripple A gaming > >title or engine is only remotly interested in using a GC. Game > >engine programmers almost do anything

Re: Official DMD compiler written in D

On 01/08/2013 01:06 PM, Philippe Sigaud wrote: On Tue, Jan 8, 2013 at 8:18 PM, Ali Çehreli wrote: There is Denis Koroskin's ddmd: http://www.dsource.org/**projects/ddmd Isn't SDC also in D? (Bernard Helyer and friends) https://github.com/bhelyer/

Re: manual memory management

On Tuesday, 8 January 2013 at 23:30:34 UTC, David Nadlinger wrote: On Tuesday, 8 January 2013 at 23:12:43 UTC, Rob T wrote: The only major thing that concerns me is the lack of proper shared library support. I hope this omission is resolved soon. What do you need it for? Runtime loading of D s

Re: manual memory management

On Wed, Jan 09, 2013 at 03:49:33AM +0100, Rob T wrote: > On Tuesday, 8 January 2013 at 23:30:34 UTC, David Nadlinger wrote: > >On Tuesday, 8 January 2013 at 23:12:43 UTC, Rob T wrote: > >>The only major thing that concerns me is the lack of proper > >>shared library support. I hope this omission is

Re: manual memory management

On Wednesday, 9 January 2013 at 00:50:29 UTC, Jonathan M Davis wrote: On Wednesday, January 09, 2013 00:37:10 Joseph Rushton Wakeling wrote: On 01/08/2013 10:43 PM, Jonathan M Davis wrote: > std.container.Array and built-in arrays are _very_ > different. Array is a > container, not a range. You

Re: manual memory management

On Tuesday, 8 January 2013 at 23:30:34 UTC, David Nadlinger wrote: On Tuesday, 8 January 2013 at 23:12:43 UTC, Rob T wrote: The only major thing that concerns me is the lack of proper shared library support. I hope this omission is resolved soon. What do you need it for? Runtime loading of D s

Re: manual memory management

On Wednesday, 9 January 2013 at 06:57:34 UTC, deadalnix wrote: On Wednesday, 9 January 2013 at 06:56:00 UTC, Mehrdad wrote: On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright wrote: One thing I'd add is that a GC is *required* if you want to have a language that guarantees memory safety

Re: manual memory management

On Wednesday, 9 January 2013 at 06:56:00 UTC, Mehrdad wrote: On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright wrote: One thing I'd add is that a GC is *required* if you want to have a language that guarantees memory safety Pardon? shared_ptr anyone? You can totally have a language

Re: manual memory management

On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright wrote: One thing I'd add is that a GC is *required* if you want to have a language that guarantees memory safety Pardon? shared_ptr anyone? You can totally have a language that only provides new/delete facilities and which only acces

Re: manual memory management

On Wednesday, 9 January 2013 at 06:57:34 UTC, deadalnix wrote: On Wednesday, 9 January 2013 at 06:56:00 UTC, Mehrdad wrote: On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright wrote: One thing I'd add is that a GC is *required* if you want to have a language that guarantees memory safety

Re: manual memory management

On Wednesday, 9 January 2013 at 07:06:03 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 06:57:34 UTC, deadalnix wrote: On Wednesday, 9 January 2013 at 06:56:00 UTC, Mehrdad wrote: On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright wrote: One thing I'd add is that a GC is *required*

Re: manual memory management

On Wednesday, 9 January 2013 at 07:14:19 UTC, deadalnix wrote: On Wednesday, 9 January 2013 at 07:06:03 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 06:57:34 UTC, deadalnix wrote: On Wednesday, 9 January 2013 at 06:56:00 UTC, Mehrdad wrote: On Tuesday, 8 January 2013 at 22:19:56 UTC, Wal

Re: manual memory management

On Wednesday, 9 January 2013 at 07:16:15 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 07:14:19 UTC, deadalnix wrote: On Wednesday, 9 January 2013 at 07:06:03 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 06:57:34 UTC, deadalnix wrote: On Wednesday, 9 January 2013 at 06:56:00 UTC,

Re: manual memory management

On Wednesday, 9 January 2013 at 07:23:16 UTC, Walter Bright wrote: On 1/8/2013 10:55 PM, Mehrdad wrote: On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright wrote: One thing I'd add is that a GC is *required* if you want to have a language that guarantees memory safety Pardon? shared

Re: manual memory management

09-Jan-2013 03:37, Joseph Rushton Wakeling пишет: On 01/08/2013 10:43 PM, Jonathan M Davis wrote: std.container.Array and built-in arrays are _very_ different. Array is a container, not a range. You can slice it to get a range and operate on that, but it's not a range itself. Is there a partic

Re: manual memory management

On 1/8/2013 10:55 PM, Mehrdad wrote: On Tuesday, 8 January 2013 at 22:19:56 UTC, Walter Bright wrote: One thing I'd add is that a GC is *required* if you want to have a language that guarantees memory safety Pardon? shared_ptr anyone? You can totally have a language that only provides new/d

Re: manual memory management

On Wednesday, 9 January 2013 at 07:22:51 UTC, deadalnix wrote: Well, you CAN indeed, create a dumbed down language that is memory safe and don't require a GC. Yeah, that's 1 of my 2 points. The other one you still ignored: the GC doesn't bring much to the table. (Re C# Java etc.)

Re: manual memory management

On Wednesday, 9 January 2013 at 07:23:57 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 07:22:51 UTC, deadalnix wrote: Well, you CAN indeed, create a dumbed down language that is memory safe and don't require a GC. Yeah, that's 1 of my 2 points. The other one you still ignored: the GC

Re: manual memory management

On Wednesday, 9 January 2013 at 07:33:24 UTC, Rob T wrote: On Wednesday, 9 January 2013 at 07:23:57 UTC, Mehrdad wrote: On Wednesday, 9 January 2013 at 07:22:51 UTC, deadalnix wrote: Well, you CAN indeed, create a dumbed down language that is memory safe and don't require a GC. Yeah, that's

Re: Official DMD compiler written in D

On Tuesday, 8 January 2013 at 21:57:17 UTC, H. S. Teoh wrote: Philosophically, I like this idea. D should eat its own dogfood +1!1!!1eleven11!