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

Algorithms

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



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

PostPosted: Tue Oct 05, 2004 2:31 pm    Post subject: Algorithms Reply with quote

Algorithms typically deal with collections/sequences of data. They should be compatible with anything that can be considered a sequence: the DTL, streams, etc. While most algorithms are not essential at this stage of development, I can think of a few that are: those having to do with UTF operations (encoding, validation, etc). The UTF routnes should be one of the first things we sort out as so much other stuff depends on them, and the design should be mindful of the idea that they are algorithms. The D method for operating on sequences is to use foreach, so algorithms should all be usable via this method. Also, I would like to have versions of algorithms that operate via delegates. ie.

Code:

bit decode(out dchar val, bit delegate(char) get);


I'll have to think a bit about typical calling conventions, but this is a start. Any suggestions?
Back to top
View user's profile Send private message
kris



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

PostPosted: Tue Oct 05, 2004 3:04 pm    Post subject: Re: Algorithms Reply with quote

sean wrote:

Code:

bit decode(out dchar val, bit delegate(char) get);


I'll have to think a bit about typical calling conventions, but this is a start. Any suggestions?

Don't wish to hijack this topic, but I'll humbly suggest postponing anything relating to Unicode and/or transcoding until we figure out what to do with the ICU port (which Jill started work upon). For those who haven't done so, here's where you can check out ICU: http://oss.software.ibm.com/icu/

The codebase provided there is highly relevant to the D language as a whole, and has more transcoders, formatters, parsers, I18N and L10N functionality than one can shake a stick at.

Were you thinking about Containers also Sean? If so, I think that MinTL is perhaps a good start ...

Just ideas.
Back to top
View user's profile Send private message
sean



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

PostPosted: Tue Oct 05, 2004 3:30 pm    Post subject: Reply with quote

Eventually, yes Smile MinTL is nice in that it has all the standard container types in very little code, but I'm also interested in seeing how DTL sorts out since it's trying some clever things with container adaptors and such.

As for ICU... were you thinking of dropping that into Ares in its entirety, or more as an /etc package? Or perhaps parts could be separated out? After a quick look at the API guide I think we may still need our own UTF conversion routines as I don't think ICU can convert directly from UTF-32 to UTF-8 or vice-versa (it seems to want everyone to use UTF-16 internally). I admit that this could be done in two passes, but this seems a bit inefficient. But I suppose this should wait for Jill's port to be complete.

I have a feeling threads will be next on Matthew's list or I'd suggest that for stage 1. Any ideas?
Back to top
View user's profile Send private message
kris



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

PostPosted: Tue Oct 05, 2004 5:28 pm    Post subject: Reply with quote

sean wrote:
As for ICU... were you thinking of dropping that into Ares in its entirety, or more as an /etc package? Or perhaps parts could be separated out? After a quick look at the API guide I think we may still need our own UTF conversion routines as I don't think ICU can convert directly from UTF-32 to UTF-8 or vice-versa (it seems to want everyone to use UTF-16 internally). I admit that this could be done in two passes, but this seems a bit inefficient. But I suppose this should wait for Jill's port to be complete.

Ideally, I'd like to see ICU used as the primary codebase for all our Unicode requirements (there's rather a lot of man-years involved there! Plus, it's maintained on a regular basis by domain experts). There are potential concerns about it not 'decoupling' to the extent that some would prefer, which brings up the DLL specter (and should perhaps be discussed elsewhere ... Wink)

sean wrote:
I have a feeling threads will be next on Matthew's list or I'd suggest that for stage 1. Any ideas?

Threads could use some tweaking to make them more useful, and I have a number of ideas in terms of what I'd like to see fixed: a thread name is a simple patch, as would fixing the slow linear lookup for the current thread-id (place it at the stack-top instead). Daemon threads would be useful, a la Java; but not wholly necessary. Eliminating the array used for pauseAll() and resumeAll() would be good in terms of removing an arbitrary limitation.

Having said that, I wouldn't want to give anyone the impression that I think we should start hacking up the existing codebase without getting some foundation in place. As such I think perhaps it would be useful at this time to just build a new (backward compatible) library with all the current Phobos code, but within a perhaps more appropriate namespace (e.g. phobos.io.File, old.io.File, or something like that). That would provide some invaluable feedback on the issues surrounding Object.d et. al. and get everyone up to speed on what it takes to actually build the library and get the compiler working with those changes. I have a feeling such an exercise will add some solid guidelines to the, uhhh, guidelines.

But I suppose that's a different subject also ... sorry for going off-topic again Embarassed
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Wed Oct 06, 2004 12:43 am    Post subject: Reply with quote

kris wrote:
Having said that, I wouldn't want to give anyone the impression that I think we should start hacking up the existing codebase without getting some foundation in place. As such I think perhaps it would be useful at this time to just build a new (backward compatible) library with all the current Phobos code, but within a perhaps more appropriate namespace (e.g. phobos.io.File, old.io.File, or something like that). That would provide some invaluable feedback on the issues surrounding Object.d et. al. and get everyone up to speed on what it takes to actually build the library and get the compiler working with those changes. I have a feeling such an exercise will add some solid guidelines to the, uhhh, guidelines.


Not that my opinion matters much, but I just wanted to say that I think this is an excellent idea. Recoding a backwards compatible library would indeed be a useful start to the process. Much of the same design dilemmas would crop up allowing the developers to see which direction they would need to go in the project.

I would also like to see the removal of the D language dependency on the standard library. I never really understood why this was done. I may be wrong, but I think that language specific needs should be separated/moved to an independent "compiler-only" library, if such is needed.

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



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

PostPosted: Wed Oct 06, 2004 12:27 pm    Post subject: Reply with quote

kris wrote:

Having said that, I wouldn't want to give anyone the impression that I think we should start hacking up the existing codebase without getting some foundation in place. As such I think perhaps it would be useful at this time to just build a new (backward compatible) library with all the current Phobos code, but within a perhaps more appropriate namespace (e.g. phobos.io.File, old.io.File, or something like that). That would provide some invaluable feedback on the issues surrounding Object.d et. al. and get everyone up to speed on what it takes to actually build the library and get the compiler working with those changes. I have a feeling such an exercise will add some solid guidelines to the, uhhh, guidelines.

It's a good idea. I'd been putting this off because of the occasional tight binding between Phobos and DMD. I think I'll ask Walter about this though, as it does seem a good starting point.
Back to top
View user's profile Send private message
larsivi
Site Admin


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

PostPosted: Fri Oct 08, 2004 5:22 am    Post subject: Reply with quote

kris wrote:
sean wrote:
As for ICU... were you thinking of dropping that into Ares in its entirety, or more as an /etc package? Or perhaps parts could be separated out? After a quick look at the API guide I think we may still need our own UTF conversion routines as I don't think ICU can convert directly from UTF-32 to UTF-8 or vice-versa (it seems to want everyone to use UTF-16 internally). I admit that this could be done in two passes, but this seems a bit inefficient. But I suppose this should wait for Jill's port to be complete.

Ideally, I'd like to see ICU used as the primary codebase for all our Unicode requirements (there's rather a lot of man-years involved there! Plus, it's maintained on a regular basis by domain experts). There are potential concerns about it not 'decoupling' to the extent that some would prefer, which brings up the DLL specter (and should perhaps be discussed elsewhere ... Wink)


It seems sensible to use ICU as the basis for the unicode stuff. As for how it should be included in Ares, I would think that it is possible to group the functionality in the ICU library(ies?). Thus we might rank it on usefullness to a general library, and maybe in more esoteric functionality that might come into play more seldom. The most useful stuff then go into Ares proper, while the rest goes into an optional etc library.

I think maybe that all functionality specific for UTF should go into Ares, while transcoding/translation/whatever from regional encodings should be in etc. There is probably functionality that don't fall in these two categories, so feel free to chime in here, all those of you with expertise in the area.
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 12:16 pm    Post subject: Reply with quote

larsivi wrote:
kris wrote:
sean wrote:
As for ICU... were you thinking of dropping that into Ares in its entirety, or more as an /etc package? Or perhaps parts could be separated out? After a quick look at the API guide I think we may still need our own UTF conversion routines as I don't think ICU can convert directly from UTF-32 to UTF-8 or vice-versa (it seems to want everyone to use UTF-16 internally). I admit that this could be done in two passes, but this seems a bit inefficient. But I suppose this should wait for Jill's port to be complete.

Ideally, I'd like to see ICU used as the primary codebase for all our Unicode requirements (there's rather a lot of man-years involved there! Plus, it's maintained on a regular basis by domain experts). There are potential concerns about it not 'decoupling' to the extent that some would prefer, which brings up the DLL specter (and should perhaps be discussed elsewhere ... Wink)


It seems sensible to use ICU as the basis for the unicode stuff. As for how it should be included in Ares, I would think that it is possible to group the functionality in the ICU library(ies?). Thus we might rank it on usefullness to a general library, and maybe in more esoteric functionality that might come into play more seldom. The most useful stuff then go into Ares proper, while the rest goes into an optional etc library.

I think maybe that all functionality specific for UTF should go into Ares, while transcoding/translation/whatever from regional encodings should be in etc. There is probably functionality that don't fall in these two categories, so feel free to chime in here, all those of you with expertise in the area.


ICU functionality is now available; see http://www.dsource.org/forums/viewtopic.php?t=447
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:27 pm    Post subject: Reply with quote

kris wrote:
larsivi wrote:
kris wrote:
sean wrote:
As for ICU... were you thinking of dropping that into Ares in its entirety, or more as an /etc package? Or perhaps parts could be separated out? After a quick look at the API guide I think we may still need our own UTF conversion routines as I don't think ICU can convert directly from UTF-32 to UTF-8 or vice-versa (it seems to want everyone to use UTF-16 internally). I admit that this could be done in two passes, but this seems a bit inefficient. But I suppose this should wait for Jill's port to be complete.

Ideally, I'd like to see ICU used as the primary codebase for all our Unicode requirements (there's rather a lot of man-years involved there! Plus, it's maintained on a regular basis by domain experts). There are potential concerns about it not 'decoupling' to the extent that some would prefer, which brings up the DLL specter (and should perhaps be discussed elsewhere ... Wink)


It seems sensible to use ICU as the basis for the unicode stuff. As for how it should be included in Ares, I would think that it is possible to group the functionality in the ICU library(ies?). Thus we might rank it on usefullness to a general library, and maybe in more esoteric functionality that might come into play more seldom. The most useful stuff then go into Ares proper, while the rest goes into an optional etc library.

I think maybe that all functionality specific for UTF should go into Ares, while transcoding/translation/whatever from regional encodings should be in etc. There is probably functionality that don't fall in these two categories, so feel free to chime in here, all those of you with expertise in the area.


ICU functionality is now available; see http://www.dsource.org/forums/viewtopic.php?t=447


Yes, I've noticed. Do you have a view on how it actually fits in with my comments above? Is it viable to do it that way?
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:48 pm    Post subject: Reply with quote

larsivi wrote:
Yes, I've noticed. Do you have a view on how it actually fits in with my comments above? Is it viable to do it that way?

One could probably carve the ICU stuff up into islands of discrete functionality. Isolating the converters, for example, would be a simple thing to do. I suspect the same applies for the Formatting/Parsing of numerics & date/time, and so on.
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