FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Who's working on what?

 
Post new topic   Reply to topic     Forum Index -> Ares
View previous topic :: View next topic  
Author Message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Fri Nov 26, 2004 1:14 pm    Post subject: Who's working on what? Reply with quote

In the interests of momentum, I thought it would be worthwhile pinging everyone to see where things lie. There's been a lot of downtime, which I suspect is more to do with not having a compilable foundation available, rather than a lack of interest.

On that point, I know Sean has had some success in isolating the DMD dependencies away from the runtime library: no mean feat.

Hey Sean; how about publishing a recap of your 'venture'?

I've been spending time making the ICU stuff available for library consideration.

Anyone else working on anything? How about the Exception hierarchy?
Back to top
View user's profile Send private message
larsivi
Site Admin


Joined: 27 Mar 2004
Posts: 453
Location: Trondheim, Norway

PostPosted: Fri Nov 26, 2004 2:25 pm    Post subject: Re: Who's working on what? Reply with quote

kris wrote:

Anyone else working on anything? How about the Exception hierarchy?


Sorry for being silent. I haven't been doing anything of relevance, either... As for the Exception stuff, I thought we were waiting for Matthew's review (which is very late).
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Fri Nov 26, 2004 2:53 pm    Post subject: Re: Who's working on what? Reply with quote

larsivi wrote:
... As for the Exception stuff, I thought we were waiting for Matthew's review (which is very late).

Perhaps Sean has some ideas regarding Exceptions Wink

Speaking of whom, I hope Sean will consider tendering his C99 lib ...
Back to top
View user's profile Send private message
andy



Joined: 15 Mar 2004
Posts: 71

PostPosted: Sun Nov 28, 2004 9:06 pm    Post subject: Reply with quote

This thread suggests to me that Ares is in dire need of an issue tracker. Not only do they plainly show what has to be done and who is doing it, but they provide a sense of direction and, most importantly, progress.
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Sun Nov 28, 2004 9:30 pm    Post subject: Reply with quote

andy wrote:
This thread suggests to me that Ares is in dire need of an issue tracker. Not only do they plainly show what has to be done and who is doing it, but they provide a sense of direction and, most importantly, progress.

That's a good idea. I wonder if the issue tracker, that Brad has been tinkering with, would work for these purposes? I'll send him an email ...
Back to top
View user's profile Send private message
brad
Site Admin


Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA

PostPosted: Sun Nov 28, 2004 11:08 pm    Post subject: Reply with quote

The "tinkering" server is down at the office, and I'll get it back and running tomorrow. I'm back on LDAP tinkering, because I think Trac is in good enough shape to go with it. LDAP will allow forums, SVN, Trac all to use the same authentication.

Once it's back up and running, it's located at: http://trac.dsource.org - there's not much there. An old Mango repos and a new Trac Test instance.

For a live project using Trac (The Trac project self-hosting), see: http://projects.edgewall.com/trac and check out the Timeline and Roadmap modules. The Ticket module is the "issue-tracker" that you speak of, but there may be creative uses of Roadmap and Milestones that would work as well.

Hopefully work will die down in December, and I'll be able to bring in the new year with a new dsource.org server. I'd like to convert the forums over to a Trac-based forum module that I've been writing as well, but we may not want to wait for that.

BA
Back to top
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Mon Nov 29, 2004 10:52 am    Post subject: Reply with quote

I just woke up, so I'll summarize what I've been up to and then get into more detail later when my head clears. I've broken Phobos into three independent pieces: the garbage collector, the runtime (which is compiler/language support routines), and the standard library. The basic idea is that each piece should be individually replacable, much like different versions of the STL can be used with the same C++ compiler. The garbage collector interface has yet to be formalized, and I've just gotten started on the standard library routines.

The standard library is stripped down to the bare essentials: a thread class and the C headers. The C99 headers (included) are pretty well tested and should work fine with DMD, though GDC may choke on complex.d, and possibly anything else from the C99 spec that GCC doesn't support yet. The Thread class is present because the garbage collector needs it to pause threads and such for a collection run. This is about the only component interdependency (not counting occasional use of the standard C headers).

I've also been experimenting with hooking some of the runtime errors: assert error, out of memory, etc. This is built into the standard library in hook.d. I'm not entirely satisfied with the way the hooking stuff is set up and have been hoping for feedback on it. The basic issue is this: hook.d contains extern (C) functions that really belong in the runtime, but moving them would mean another compoment interdependency. One solution would be to formalize the relationship, so the runtime would call extern functions of its own that the standard library is required to provide. Beyond this, I've considered wrapping the function pointer mapping in functions, similar to how the terminate handler and such can be remapped in C++, but I'm looking for other ideas before I do that. I'm also considering putting the default behavior in the extern functions themselves and only calling the hooks if they're not null, since this would get around some sticky problems with asserts and such being fired before the hook module is initialized.

Anyway, what I've got so far is here:

http://home.f4.ca/sean/d/ares.zip

The linux version of the thread code is in progress, and the linux makefiles have barely been started so that all needs some work as well. I'd also like to find the time to create a pthread header and a few others, but without a linux box to play with I've been putting all that off.
Back to top
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Mon Nov 29, 2004 12:11 pm    Post subject: Reply with quote

By the way, I've also been considering getting rid of most of the hooks altogether because I can't think of a reason I'd ever use any of them besides onAssertError. Does this seem reasonable?
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Mon Nov 29, 2004 12:22 pm    Post subject: Reply with quote

sean wrote:
By the way, I've also been considering getting rid of most of the hooks altogether because I can't think of a reason I'd ever use any of them besides onAssertError. Does this seem reasonable?

On the face of it, one might assert that such hooks are an unecessary special case, since one can always catch the resultant exception anyway (in a manner consistent with all other exception variations). AssertError() is, as you indicate, more unique.

There again, those hooks have access to file & line-number information. If Walter would finally concede to making a __FILE__ & __LINE__ available in general (or something like that), then that advantage would not be present. As it is, I wouldn't use the hooks for that purpose anyway. Given that, I'd probably remove them (or hide them) to avoid future-support issues.

My 2 cents
Back to top
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Mon Nov 29, 2004 2:14 pm    Post subject: Reply with quote

FWIW, the errors now throw an exception that has line and file properties, so this stuff can be grabbed in the exception handler ayway. I guess I'll remove most of the hooks, but may add one or two new ones like onUnhandledException or onTerminate. I'll follow up in a new thread.
Back to top
View user's profile Send private message
kris



Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific

PostPosted: Mon Nov 29, 2004 5:44 pm    Post subject: Reply with quote

Could I trouble you to add a getName() and setName() pair to your Thread class? They can really help to make it easier when debugging multi-threaded apps ...
Back to top
View user's profile Send private message
sean



Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA

PostPosted: Tue Nov 30, 2004 10:36 am    Post subject: Reply with quote

Will do. The existing class just has the basics and I figured I'd solicit suggestions beyond that. Thread also needs a way to adjust priority and such too.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Ares All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group