"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:42263C1C.5030009@nospam.org...
> Could this be (at least partially) alleviated with a Copy On Read
strategy?

Perhaps. But then it's gotta be fed back in.

<brad@domain.invalid> wrote in message news:d05gbg$11g0$1@digitaldaemon.com...
> clayasaurus wrote:
> > I know when I first started out D, I was wondering why all my classes would seg fault :-/ (it was because i never 'newed' it).
>
> I totally agree.  I still get bitten by segfaults.  I start taking the C
>   approach to finding them, by rolling up my sleaves and looking for
> possible null pointer references, etc.

Too find them, compile with -g and then run it under the debugger. The debugger will point you at which line failed.

>  I never find the obvious null
> pointer - because it isn't there :)  And I'm so used to C/C++ that when
> I see object.foo() (instead of object->foo()) I think "that can't be the
> problem, it's not a pointer"
> So, please please can we have a message other than segfault for objects
> that haven't been instantiated?

Walter wrote:
> <brad@domain.invalid> wrote in message
> news:d05gbg$11g0$1@digitaldaemon.com...
> 
>>clayasaurus wrote:
>>
>>>I know when I first started out D, I was wondering why all my classes
>>>would seg fault :-/ (it was because i never 'newed' it).
>>
>>I totally agree.  I still get bitten by segfaults.  I start taking the C
>>  approach to finding them, by rolling up my sleaves and looking for
>>possible null pointer references, etc.
> 
> 
> Too find them, compile with -g and then run it under the debugger. The
> debugger will point you at which line failed.

I guess I've gotten out of the habit of using a debugger with D because it initially wasn't supported under Linux.

Matthew wrote:
> "Carlos Santander B." <csantander619@gmail.com> wrote in message news:d058mj$ndf$1@digitaldaemon.com...
> 
>>Walter has said he has his own bugs database. I'd say then, 1.0 would be all of the bugs (or most of them, I don't know) are fixed.
> 
> 
> I just think that's too narrow-minded, and open to bias. After all, who in the whole world is likely to be the least critical about D? ;$

lol!

> 
> We need the skeptics _in this group_ to be convinced before we've any hope of convincing people from without. As such, I think Walter's the absolute worst qualified to stipulate when D's ready to roll out. (Sorry, mate!)
> 
> That said, I don't think a sensible approach is to just randomly couch opinion from loud and opinionated types (such as me). I think we need something systematic (which I'm working on in a longer post I'm preparing now.)
> 
> 
> 

Ok, I see your point. Maybe using DStress instead, as others have suggested?

_______________________
Carlos Santander Bernal

Walter wrote:
> <brad@domain.invalid> wrote in message
> news:d05gbg$11g0$1@digitaldaemon.com...
> 
>>clayasaurus wrote:
>>
>>>I know when I first started out D, I was wondering why all my classes
>>>would seg fault :-/ (it was because i never 'newed' it).
>>
>>I totally agree.  I still get bitten by segfaults.  I start taking the C
>>  approach to finding them, by rolling up my sleaves and looking for
>>possible null pointer references, etc.
> 
> 
> Too find them, compile with -g and then run it under the debugger. The
> debugger will point you at which line failed.

Not in Linux!  I find my self putting a lot of code like:
if (a is null)
	writefln("null ptr");

In article <d04p7a$550$1@digitaldaemon.com>, Walter says...
>
>I've found myself wondering over the last few months what "1.0" actually is. Since D will undergo continuous improvement regardless, why don't we just drive a stake in the ground and call what we have "1.0"?
>
>
Walter: I'd love to see v1.0 before the end of this year, and even before the D book is released...because the book may take longer to finish than this year (plus the book should be fully focused on the D v1.x release). Also I've been wondering how you've been doing on attacking the items placed in the MIID (Most Important List for D) thread, that you started (news:cht9gl$20m8$1@digitaldaemon.com) back in September of 2004?

Plus I think that the DStress tests should be in the 90%+ passing range as a few others have voiced. But of course, if you want to place the stake in the ground now...why not make the next release as D v1.0 RC1! Afterall, it works well for Microsoft, and they're still able to remove / add things right up into the last minute...if need be before it becomes the next major release number. Just an idea. :)

D's been pretty solid for the more avg things I've been writing, and the few times I had to fix something about 5 builds ago, it ended up that the compiler's error checking had improved, which it pointed out a few of my coding mistakes. Walter, many Kudos!!

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

This post shows a lot of good sense!  Very well put, Glen.  I beleive Walter does need to be much more receptive to outside opinion.

My only hesitation would be using slashdot as a resource.... ugh... That site is the last place I'd search for a sane evaluation of a language (Although, it is useful for getting general publicity).  I believe language reviewers have to be much more carefully chosen, or there will be chaos.  But such critical evaluation is necessary.

-JJR

Glen Perkins wrote:
> In article <d04p7a$550$1@digitaldaemon.com>, Walter says...
> 
> 
>>I've found myself wondering over the last few months what "1.0" actually is.
> 
> 
> Having formally participated in the design of Java and Flash ActionScript, I can
> say that the biggest non-commercial part of the definition of "what 1.0 actually
> is" was cutting off your ability to ever change your mind about some things.
> Freezing your mistakes. After 1.0, you are still able to add things, but you
> can't really remove anything, and the things you add have to be squeezed into
> the spaces not already occupied by something you can't remove. Having to squeeze
> new, better ideas into cracks between old, worse ideas makes a language into,
> well, C++ or Perl 5.
> 
> 
>>Since D will undergo continuous improvement regardless, why don't we just
>>drive a stake in the ground and call what we have "1.0"?
> 
> 
> Yes, many things will still be changeable, but many will not. The "stake in the
> ground" is a stake thru the heart of anybody who still fervently hopes to
> pursuade you to change certain things before it's too late. Even though it is
> true that D will undergo continuous improvement, you will never again be
> completely free to "do things right" after 1.0 ships.
> 
> I don't think it's possible to avoid that outcome entirely (except by never
> shipping, which would be a tragedy), but I think there are ways to minimize it.
> When your first priority is to deliver revenue numbers to Wall St. this quarter,
> or crush Microsoft, or surprise your competitors by unveiling your stealth
> project, your options are limited.
> 
> But if you have the luxury of making the best possible language design your
> first priority, do whatever you can to get the world to help before committing
> to 1.0.
> 
> No matter how smart you are, the world collectively is smarter. It's also
> self-contradictory, overwhelming, and chaotic, so taking advantage of that extra
> smartness isn't trivial, but I think it's a tremendously valuable resource.
> You've already been engaging the world to some extent via this forum, but maybe
> one last push would be useful.
> 
> Before making the 1.0 committment, you might consider getting some docs together
> that describe the *goals* for the language (what you're trying to optimize for),
> and why you believe the existing design decisions to be better than their major
> alternatives at meeting those goals. Just the process of writing such a thing,
> as a pursuasive document, not as a declaration of fact, might be useful to you.
> 
> Then get the word out (Slashdot, etc.) that you'd like people to read these
> design arguments, think about them, try writing some code, and then respond with
> their highest priority requests for any changes.
> 
> Then instead of defending your previous decisions, as is a natural temptation,
> and doing battle with the change suggestions, try to relax and see what emerges.
> Try to imagine that nothing had been decided (or implemented!) yet, that there
> was no existing design to defend, and you were free to let a design "emerge"
> naturally from the data.
> 
> This emergence isn't a majority vote, just a sense of what the mass of users
> were thinking that you could adapt to without legacy constraints on your
> decision making.
> 
> I think the existing design is so close to optimal for what you are optimizing
> for that the fundamental design of D will be overwhelmingly endorsed. Also,
> since the existing design would form the basis for discussion, what I think
> would emerge would simply be minor modifications. People's highest priority
> change requests would be in the details, I believe.
> 
> I really think that if you could relax your commitment to the existing details
> and dispassionately observe what emerges and implement that, it would be better
> than what you have now, though I don't know how. (Sort of a stochastic
> optimization algorithm that isn't best for each individual but is best overall.)
> I also think it would be so close to what you have that the changes would be
> relatively minor, though if what emerged did imply a need for big changes, you'd
> want to know that before 1.0 since it would eventually become obvious later, and
> later might be too late.
> 
> 

"Matthew" <admin@stlsoft.dot.dot.dot.dot.org> wrote in message news:d059o0$oqo$2@digitaldaemon.com...
> Several times over the past few weeks I've said, in support of not-entirely-calm debates, that I don't feel that D is commercially ready.
>
> Maybe the time has come for several/many of us to identify pet projects that we each have, and see if / how well some/all of them may be implemented in D.
>

I wrote a couple of indie/budget games for windows a few years ago (A breakout clone and a centepede clone). The existing code for both is awful, so I've just started on a complete rewrite of both in D, which will end up as "Deluxe" versions with extra features (replacing the old versions).

>
> will change enough to cause any D source today to undergo major rewrites? I can answer the latter concern - it isn't going to happen.
>

Walter, for the Mars sake and other mebers of Panteon, could you shed a light on future of "external-methods"?

I mean this was supported last time I checked it
char[][] split(char[] s, char c) { ... }
char[] s = "a b c";
char[][] sv = s.split(' ');

May I rely on this trick?

On Wed, 2 Mar 2005 20:49:38 -0800, Andrew Fedoniouk wrote:

>>
>> will change enough to cause any D source today to undergo major rewrites? I can answer the latter concern - it isn't going to happen.
>>
> 
> Walter, for the Mars sake and other mebers of Panteon, could you shed a light on future of "external-methods"?
> 
> I mean this was supported last time I checked it
> char[][] split(char[] s, char c) { ... }
> char[] s = "a b c";
> char[][] sv = s.split(' ');
> 
> May I rely on this trick?

I sure hope so 'cos I've spent the last couple of weeks writing a whole heap of code that depends on this behaviour.

-- 
Derek
Melbourne, Australia
3/03/2005 4:03:08 PM