View previous topic :: View next topic |
Author |
Message |
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Fri Nov 26, 2004 1:14 pm Post subject: Who's working on what? |
|
|
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 |
|
|
larsivi Site Admin
Joined: 27 Mar 2004 Posts: 453 Location: Trondheim, Norway
|
Posted: Fri Nov 26, 2004 2:25 pm Post subject: Re: Who's working on what? |
|
|
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 |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Fri Nov 26, 2004 2:53 pm Post subject: Re: Who's working on what? |
|
|
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
Speaking of whom, I hope Sean will consider tendering his C99 lib ... |
|
Back to top |
|
|
andy
Joined: 15 Mar 2004 Posts: 71
|
Posted: Sun Nov 28, 2004 9:06 pm Post subject: |
|
|
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 |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Sun Nov 28, 2004 9:30 pm Post subject: |
|
|
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 |
|
|
brad Site Admin
Joined: 22 Feb 2004 Posts: 490 Location: Atlanta, GA USA
|
Posted: Sun Nov 28, 2004 11:08 pm Post subject: |
|
|
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 |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Mon Nov 29, 2004 10:52 am Post subject: |
|
|
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 |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Mon Nov 29, 2004 12:11 pm Post subject: |
|
|
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 |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Mon Nov 29, 2004 12:22 pm Post subject: |
|
|
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 |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Mon Nov 29, 2004 2:14 pm Post subject: |
|
|
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 |
|
|
kris
Joined: 27 Mar 2004 Posts: 1494 Location: South Pacific
|
Posted: Mon Nov 29, 2004 5:44 pm Post subject: |
|
|
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 |
|
|
sean
Joined: 24 Jun 2004 Posts: 609 Location: Bay Area, CA
|
Posted: Tue Nov 30, 2004 10:36 am Post subject: |
|
|
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 |
|
|
|