| View previous topic :: View next topic |
| Author |
Message |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
 Posted: Mon Nov 14, 2005 6:41 pm Post subject: |
 |
|
| sean wrote: | | kris wrote: | I see the regexp module decl is still "std.regexp" rather than perhaps "sub.std.regexp". Is that intentional? I mean, do you expect that an additional -I\Ares\src\sub should be required?
The latter would certainly make it painless to migrate 'sub' packages to the main area, if that were the intent ... |
It was an accident, though perhaps it's a good idea to keep it this way. After all, the module is inteded to end up in std, and doing so would prevent the need for code changes later.
By the way, does std.regexp support the full RegExp syntax? I haven't given it more than a cursory look so far. |
Yes, I agree about the extra -I usage. Though, its value would be rendered moot were the package under evaluation were to change it's name too (e.g. from eval\mango\log to core\logging). That's a tricky one 
I believe std.regexp does support some version of 'full' syntax. I don't think it's Perl5 or anything like that, but has all the familiar friends from long, long ago. I recall the Phobos documentation has the scoop on that: http://digitalmars.com/ctg/regular.html |
|
| Back to top |
|
 |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Mon Nov 14, 2005 6:51 pm Post subject: |
|
|
| sean wrote: | Yeah, I don't really like sub being on the same level as std and sys also. Perhaps Ares should be divided as follows:
ares/core/std
ares/core/...
ares/eval/std
ares/eval/...
Basically, I'd like a place for submissions to live, and some way to mark various submissions as under review. I currently have "sub" and "rev" for this purpose, but would gladly change the names if someone could suggest something better. I suppose "eval" would replace "sub" in the preceding example, and beyond that perhaps documenting the revision level would be sufficient? |
That sounds reasonable. Though I suppose it depends upon how much value there is to the multi-revision idea. I mean, if the latter were to be considered a priority for the packaging (potentially multiple versions of various libraries) then a rev would make sense. But then, one might argue that should apply across the board, for purposes of packaging. That is: make the install-directory name reflect the overall Ares revision.
A related concern would be possible inter-dependencies between different eval packages, and how that would pan out with rev instances too. Tricky. I suspect it's easier to require all interdependencies to be worked out in advance, and thus make the entire Ares deliverable a "fully resolved" entity? |
|
| Back to top |
|
|
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Tue Nov 15, 2005 1:28 am Post subject: |
|
|
| kris wrote: | | That sounds reasonable. Though I suppose it depends upon how much value there is to the multi-revision idea. I mean, if the latter were to be considered a priority for the packaging (potentially multiple versions of various libraries) then a rev would make sense. But then, one might argue that should apply across the board, for purposes of packaging. That is: make the install-directory name reflect the overall Ares revision. |
My original reasoning was twofold: first, I wanted people to have some idea of how stable an implementation was, and second, I wanted it to be apparent what sort of feedback was desired. It seemed simplest to just break things into two segments: new submissions, and packages that have been evaluated and are destined for inclusion pretty much as-is.
| Quote: | | A related concern would be possible inter-dependencies between different eval packages, and how that would pan out with rev instances too. Tricky. I suspect it's easier to require all interdependencies to be worked out in advance, and thus make the entire Ares deliverable a "fully resolved" entity? |
Ack! Hopefully, we won't have many separate inter-dependent submissions. That sounds like a maintenance nightmare  Beyond that, I'm hoping we can limit external dependencies to the Ares core, or at worst to closely related packages which would live in the same library. As you say, this would have to be sorted out in advance. |
|
| Back to top |
|
|
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Mon Nov 21, 2005 4:54 pm Post subject: |
|
|
I've given this some thought, and while I do like the idea of being able to -I different packages (core, eval, etc), I think Kris is right that the easiest thing to do is just version Ares as a whole. This avoids such nasty issues as this:
core/std/module1.d
ext/std/module2.d
since subdividing logical packages based on higher-level rules seems like an invitation for trouble. Instead, submissions will initially be available separately and then integrated directly into the Ares tree once any naming issues have been resolved, obviously subject to further review and refinement from there. Unless someone can suggest a better package layout, the Ares core will consist of everything in std and sys, with other top-level packages being linked separately. |
|
| Back to top |
|
|
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Fri Nov 25, 2005 8:39 pm Post subject: |
|
|
Version 0.7 is online with these changes:
* Added code support for synchronized load ops on x86, even though that option is not currently available given the msync options available for atomicLoad.
* Merged in DMD .140 changes.
* Added thread local storage.
* Moved std.regexp from sub area. Be aware that this module is under evaluation and the interface may change.
The thread local storage implementation adds a static array of LOCAL_MAX ubytes to the Thread class as well as an array of LOCAL_MAX void pointers to each Thread instance (LOCAL_MAX is currently set to 64). If you don't plan to use TLS and the memory usage is a concern, change LOCAL_MAX to zero and rebuild Ares. Please let me know what you think of the implementation. My primary goal here is performance so little to no parameter validation is being done--if you pass a key value to these functions that wasn't created by createLocal you will likely either get an OutOfBounds exception or an access violation depending on build parameters. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Sat Nov 26, 2005 2:58 pm Post subject: |
|
|
| sean wrote: | Version 0.7 is online with these changes:
* Added code support for synchronized load ops on x86, even though that option is not currently available given the msync options available for atomicLoad.
* Merged in DMD .140 changes.
* Added thread local storage.
* Moved std.regexp from sub area. Be aware that this module is under evaluation and the interface may change.
The thread local storage implementation adds a static array of LOCAL_MAX ubytes to the Thread class as well as an array of LOCAL_MAX void pointers to each Thread instance (LOCAL_MAX is currently set to 64). If you don't plan to use TLS and the memory usage is a concern, change LOCAL_MAX to zero and rebuild Ares. Please let me know what you think of the implementation. My primary goal here is performance so little to no parameter validation is being done--if you pass a key value to these functions that wasn't created by createLocal you will likely either get an OutOfBounds exception or an access violation depending on build parameters. |
In the FWIW department, in the past I've simple subclassed Thread to get TLS. That approach worked very nicely for the Mango HTTP server. |
|
| Back to top |
|
|
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Sat Nov 26, 2005 5:07 pm Post subject: |
|
|
I considered that, but there's no way to subclass the object that represents the main thread, so subclassing isn't a universal solution. Also, the threading model in Ares allows threads to be created either by sublcassing or by supplying a pointer to a function or delegate that should be made asynchronous, ie.
| Code: | class MyThread : Thread {
void run() {
...
}
}
void doSomething() { ... }
MyThread t1 = new MyThread();
Thread t2 = new Thread( &doSomething );
t1.start();
t2.start();
|
At the same time, I didn't want the user to pay for a ton of storage they don't plan to use, so 64 slots seemed a reasonable compromise. I only wish there were some easy way to have the GC scan the TLS data allocated by the system, as it will go almost entirely unused in a D program (getThis() actually uses system-provided TLS to avoid locking the global thread list, so the function should be extremely fast on most systems). |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Sat Nov 26, 2005 8:46 pm Post subject: |
|
|
| sean wrote: | I considered that, but there's no way to subclass the object that represents the main thread, so subclassing isn't a universal solution. Also, the threading model in Ares allows threads to be created either by sublcassing or by supplying a pointer to a function or delegate that should be made asynchronous, ie.
| Code: | class MyThread : Thread {
void run() {
...
}
}
void doSomething() { ... }
MyThread t1 = new MyThread();
Thread t2 = new Thread( &doSomething );
t1.start();
t2.start();
|
|
Aye.
Had made the assumption that if folks wanted TLS, then they'd be OK with subclassing Thread instead of passing a function or delegate. That aside, you are dead right about the main thread. |
|
| Back to top |
|
|
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Mon Dec 05, 2005 5:09 am Post subject: |
|
|
Version 0.8 is online with these changes:
* Merged in DMD .141 changes.
* Made temporary change in std.atomic to workaround compiler bug ("volatile" modifier to "asm" statement commented out).
* Added separate variable to track Thread.count. This was done to eliminate a race condition with the GC that may have resulted in corrupted GC data. This should also make memory allocation run faster for single-threaded programs. I'm not entirely happy with the way the GC integrates with the global thread list, and this is liable to change at some point.
This is largely a compatibility update for DMD .141. I'm going to be looking at the GC and GC-thread integration for the next few weeks, so expect more work done there and on memory allocation in general.
By the way, the admin UI is giving me no end of trouble and 0.8 is located beneath 0.7 in the file list. Sorry about that. |
|
| Back to top |
|
|
JJR
Joined: 22 Feb 2004
Posts: 1104
|
| Posted: Mon Dec 05, 2005 5:20 am Post subject: |
|
|
How does the Ares 0.8 deal with the code coverage analyzer tool that was added to dmd 0.141?
It looks like std.cover was added for control. Does Ares 0.8 need this?
-JJR |
|
| Back to top |
|
|
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Mon Dec 05, 2005 6:01 pm Post subject: |
|
|
| I think it might. I'll take a look today and see what .141 features require library modules. It may be that mangle does as well. And I'd like to make sure both work in Ares |
|
| Back to top |
|
|
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Mon Dec 19, 2005 2:10 pm Post subject: |
|
|
It's probably a small thing, but the next release of Ares will eliminate the Thread.count() and threadCount() functions. The only reason for these functions to exist was to allow the GC (and potentially user code) to optimize based on whether the application is single or milti-threaded, and it made little sense to manage an accurate thread count for this purpose. Instead, a new function will be added, "extern (C) bit multiThreaded()," which has a similar purpose. This value will default to false and will be set to true the first time Thread.start() is called. Once this occurs, this value will remain true until the process terminates.
It is worth noting that optimizing on this value is of very limited use, as optimization is only possible if the programmer can guarantee that no path from the enclosed code will start a thread. For this reason, it is also not possible to optimize away locking done by the built-in "synchronized" statement (unfortunately). I'm of half a mind to eliminate it completely, excelt that it does seem to have some limited use for speeding up memory allocations in some cases. |
|
| Back to top |
|
|
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Sat Dec 31, 2005 12:45 am Post subject: |
|
|
| I'd like to add std.demangle but it has a dependency on the format function call so I'm omitting it for the moment. Also, since std.cover isn't actually a standard library feature (as code coverage analysis is a QOI issue) I think it will have to be added in a separate package area--perhaps 'ext' or some such. I'm a bit disappointed about std.mangle though... I suppose this offers more incentive to sort out UTF support and such so string formatting and parsing can be addressed. |
|
| Back to top |
|
|
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Sat Dec 31, 2005 12:58 am Post subject: |
|
|
Version 0.9 is online with these changes:
* Merged in DMD .142 changes.
* Added std.stdarg.
* Now printing error messages to stderr.
* Replaced std.thread.threadCount with std.thread.multiThreaded.
I'm back from vacation now and will hopefully have some time to do a bit of work on Ares before long. Utf conversion looks like it may take precedence over GC changes, so if anyone has suggestions, please post them. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Sat Dec 31, 2005 1:03 am Post subject: |
|
|
Welcome back, Sean
I'd be happy to discuss utf issues with you. Let me know what you're thinking? Also, I could probably help out with the mangle thing, if you like. Will take a look. |
|
| Back to top |
|
|
|
|
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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
