May 03, 2005
"John Demme" <me@teqdruid.com> wrote in message news:1115152504.21959.6.camel@localhost.localdomain...
> On Tue, 2005-05-03 at 13:45 -0400, Ben Hinkle wrote:
>> "Maxime Larose" <mlarose@broadsoft.com> wrote in message news:d58c31$2mal$1@digitaldaemon.com...
>> >
> ...
>> If a goal of the stack-trace feature is to dump stacks without throwing
>> then
>> why make it necessary to instantiate an exception? I'm thinking of an API
>> like Java's Thread.dumpStack which dumps the stack of the code calling
>> dumpStack. I think in the case of a thrown exception the stack should be
>> at
>> the throw since that is where the "error" truely happens and that's where
>> a
>> programmer would start debugging the issue.
> I disagree, as I've done things like this in Java:
> try {
> someMethod();
> } catch (MyException e) {
> //Examine exception more closely
> if (ICanHandle(e)) {
> handle(e);
> } else {
> throw e;
> }
> }
>
> Now given, this is really just a work around for an extremely poor Exception hierarchy, but I think it shows that the error doesn't necessarily occur at the throw.  I'd say a stack trace should be generated by the constructor (or not, depending on parameters) and also have a method .generateST() to (re-)generate the ST for maximum flexibility.
>
> John Demme

The stack is generated at the original throw inside someMethod. I can buy the argument that if you rethrow an exception it doesn't step on the stack that is already there. You're right that it shouldn't lose the stack from the original throw/ctor.


May 04, 2005
> Been there, doing that ;)  Your stack trace feature will definately be in
Ares,
> whether it ends up in Phobos or not.
>

What is the design goals for Ares? I skimmed through the forum on dsource,
but couldn't find the reason for its existence...
(Sent me a RTFM with a link if I missed the obvious... ;)

Thanks


May 04, 2005
In article <d5apue$27k6$1@digitaldaemon.com>, Maxime Larose says...
>
>> Been there, doing that ;)  Your stack trace feature will definately be in
>Ares,
>> whether it ends up in Phobos or not.
>>
>
>What is the design goals for Ares? I skimmed through the forum on dsource,
>but couldn't find the reason for its existence...
>(Sent me a RTFM with a link if I missed the obvious... ;)

The birth of Ares largely stemmed from a general sense of frustration regarding Phobos submissions (namely that such things often seemed ignored or, at best, quite delayed before inclusion).  Some thought that perhaps a group of motivated people could ease Walter's workload (and speed the development of Phobos) by reviewing submissions and presenting them to Walter in a more structured manner. A driving concern was that some don't consider Phobos to be up to snuff as a standard library, and that it would speed the langauge's development if Walter could focus on language issues and leave others to fuss over library development.  Perhaps as a result of this dissatisfaction with existing Phobos components, the Ares project changed rather quickly into one aimed at creating an entirely new standard library, complete with accompanying spec.  As this is a relatively large project that may prove to be ultimately futile (since Walter has veto power on all things D), interest waned and that's pretty much where we stand now.

I've continued development of Ares in my (recently limited) spare time and the project has garnered some renewed interest from like-minded individuals.  Going forward, I do expect Ares development to pick up substantially.  And whether or not it's ultimately accepted or not, I plan to use it for my own programming projects.  Currently, Ares represents a minimal runtime library for DMD (and soon for GDC as well).  It consists of three pieces: ares, dmdrt, and dmdgc. The latter two portions are code extracted from Phobos--dmdrt contains all runtime code that the DMD compiler requires, and dmdgc is the GC shipped with phobos (a driving concern for this separation was that the GC, runtime, and standard library should all be independent from one another and only interact in specific, structured ways--they're somewhat intertwined in Phobos).  Some remaining pieces still need attention--the core exception structure needs some refactoring, and the GC interface hasn't been touched--but for the most part I think it makes a fairly solid starting point for development.  And once these final details have been hammered out I expect that development will accelerate quickly.

As for the manual, there isn't one yet :)  And as code has just begun to be checked into the SVN repository (I'd been maintaining it on my home PC until recently) there are likely some access issues there as well.  In the meantime, I keep an up to date copy of the Ares source on my D "website": http://home.f4.ca/sean/d


Sean


1 2
Next ›   Last »