www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DSSS, Dsource, and cpan

reply Walter Bright <newshound1 digitalmars.com> writes:
Andrei suggested that a huge resource for Perl users is 
http://www.cpan.org. Not only is it full of reusable Perl code, it is 
very easy to access via 
http://search.cpan.org/~jhi/perl-5.8.0/lib/CPAN.pm, and is a big factor 
in the ongoing success of Perl.

It seems to me that we are close to this with DSSS coupled with Dsource. 
So can we get closer?

I.e., can we change dsource so that there are two kinds of projects:

1) Projects that are not certified, and
2) Projects that are certified

Certified projects must meet certain minimum requirements:

1) They can be installed using DSSS
2) They compile and run their unit tests
3) They have ddoc documentation for their APIs

In other words, a project that is certified is one that is easy for 
users to install, has documentation, and at least appears to work.

Boost, another successful library repository, also adds on peer review. 
Perhaps in the future, as our user base grows, we can add another layer 
of certification for projects that pass peer review.

Any thoughts?
Apr 10 2007
next sibling parent reply Gregor Richards <Richards codu.org> writes:
Walter Bright wrote:
 Andrei suggested that a huge resource for Perl users is 
 http://www.cpan.org. Not only is it full of reusable Perl code, it is 
 very easy to access via 
 http://search.cpan.org/~jhi/perl-5.8.0/lib/CPAN.pm, and is a big factor 
 in the ongoing success of Perl.
 
 It seems to me that we are close to this with DSSS coupled with Dsource. 
 So can we get closer?
 
 I.e., can we change dsource so that there are two kinds of projects:
 
 1) Projects that are not certified, and
 2) Projects that are certified
 
 Certified projects must meet certain minimum requirements:
 
 1) They can be installed using DSSS
 2) They compile and run their unit tests
 3) They have ddoc documentation for their APIs
 
 In other words, a project that is certified is one that is easy for 
 users to install, has documentation, and at least appears to work.
 
 Boost, another successful library repository, also adds on peer review. 
 Perhaps in the future, as our user base grows, we can add another layer 
 of certification for projects that pass peer review.
 
 Any thoughts?

For what it's worth, other than creating DSSS itself I've taken some steps along these lines. I have a testing framework which checks whether dsss-net-installable tools succeed across all the systems I can x-compile to, with results posted at http://dsss.codu.org/results.html (I'm still working out some kinks, so there are false-negatives there ;) ) Unit tests would be an excellent next-step for that page: a 'yellow' indicator would mean "compiles, but unittests failed." If this data was all stored in a standard way, DSSS could access it to provide more information on installable tools than what is provided now. That would be quite nice. Options could be added such as: $ dsss net info bintod ... Description: bintod is a utility for translating binary data into D char[] arrays, so that it can easily be compiled into a program. Tests: Passes on 9/10 platforms FAILS on 8086-sysv - Gregor Richards PS: In case nobody knew, all of DSSS' functionality can be used in any program by importing sss.build, sss.net, sss.install, etc.
Apr 11 2007
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Gregor Richards" <Richards codu.org> wrote in message 
news:461C90CD.3010502 codu.org...
 For what it's worth, other than creating DSSS itself I've taken some steps 
 along these lines.

 I have a testing framework which checks whether dsss-net-installable tools 
 succeed across all the systems I can x-compile to, with results posted at 
 http://dsss.codu.org/results.html (I'm still working out some kinks, so 
 there are false-negatives there ;) )

Nooo, minid fails! It does actually compile just using build on linux, though. I've been trying to keep the dsss.conf up-to-date but I never know if I'm doing it right...
Apr 11 2007
next sibling parent =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Jarrett Billingsley wrote:
 Nooo, minid fails!  It does actually compile just using build on linux, 
 though.  I've been trying to keep the dsss.conf up-to-date but I never know 
 if I'm doing it right... 

I guess one reason it fails is that it does not support Tango. I haven't tested it further though. Those tests do not explicitly show whether they have been built with Tango or Phobos.
Apr 11 2007
prev sibling parent Gregor Richards <Richards codu.org> writes:
Jarrett Billingsley wrote:
 "Gregor Richards" <Richards codu.org> wrote in message 
 news:461C90CD.3010502 codu.org...
 For what it's worth, other than creating DSSS itself I've taken some steps 
 along these lines.

 I have a testing framework which checks whether dsss-net-installable tools 
 succeed across all the systems I can x-compile to, with results posted at 
 http://dsss.codu.org/results.html (I'm still working out some kinks, so 
 there are false-negatives there ;) )

Nooo, minid fails! It does actually compile just using build on linux, though. I've been trying to keep the dsss.conf up-to-date but I never know if I'm doing it right...

I"ve been meaning to figure that out and squash it, when time permits :P I doubt that the problem is on your end. - Gregor Richards Oh, and no, these tests aren't using Tango, I'm going to make a whole other set for that.
Apr 11 2007
prev sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Gregor Richards wrote:

 I have a testing framework which checks whether dsss-net-installable 
 tools succeed across all the systems I can x-compile to, with results 
 posted at http://dsss.codu.org/results.html (I'm still working out some 
 kinks, so there are false-negatives there ;) )

For wxD the problem is that it is trying to build an old release (0.08) with a new D compiler, and fails because the implicit .ptr was removed. So it needs to either specify the D version to be used (DMD 0.177), or it needs to be updated to the 0.09 release. Not sure how to do either... --anders
Apr 11 2007
parent reply Gregor Richards <Richards codu.org> writes:
Anders F BjŲrklund wrote:
 Gregor Richards wrote:
 
 I have a testing framework which checks whether dsss-net-installable 
 tools succeed across all the systems I can x-compile to, with results 
 posted at http://dsss.codu.org/results.html (I'm still working out 
 some kinks, so there are false-negatives there ;) )

For wxD the problem is that it is trying to build an old release (0.08) with a new D compiler, and fails because the implicit .ptr was removed. So it needs to either specify the D version to be used (DMD 0.177), or it needs to be updated to the 0.09 release. Not sure how to do either... --anders

Updated. If you'd like to keep it up to date yourself, you'd have to apply the patch dsss uses and then add yourself to dsss.codu.org . - Gregor Richards PS: Pweeeeeeeeeze keep it up to date yourself X-P
Apr 11 2007
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Gregor Richards wrote:

 If you'd like to keep it up to date yourself, you'd have to apply the 
 patch dsss uses and then add yourself to dsss.codu.org .
 
 PS: Pweeeeeeeeeze keep it up to date yourself X-P

Will do this and Ddoc for wxD CVS and next release. --anders
Apr 11 2007
prev sibling next sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 10 Apr 2007 23:40:10 -0700, Walter Bright wrote:

 3) They have ddoc documentation for their APIs

Not all projects are libraries and as such have 'private' APIs. I would be excellent if DDoc could be used to document APIs that were only meant for internal development of the project - especially segments that were marked as private/package/protected. From memory, current DDoc ignores private classes etc ... -- Derek Parnell Melbourne, Australia "Justice for David Hicks!" skype: derek.j.parnell
Apr 11 2007
prev sibling next sibling parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 11 Apr 2007 10:40:10 +0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 I.e., can we change dsource so that there are two kinds of projects:

 1) Projects that are not certified, and
 2) Projects that are certified

I think certification should be optional and not certified projects should not be seen as second-class projects in comparision with certified (first-class) projects. A live example is RubyGems at RubyForge -- there isn't any certification and RubyForge's RubyGems archive works. And that is fine because RubyForge hosts Gems from (at least) 1500 projects [1] and new projects start almost every day [2]. It is hard to imagine that someone tries to certificate part of those projects and their different versions. I have several my projects on RubyForge and one of them can pass its unit-test only in special environment. That project can't pass automatic certification procedure based on unit-tests, but it works. So I don't think manual certification will possible if DSource starts host a big amount of projects comparable with RubyForge and CPAN. Ddoc documentation may be important for some kind of projects, like libraries. But for other types it simply doesn't matter. DSSS is a good example -- I don't want to look into its code, but I wish to have advanced documentaion. In some cases such documentation can't be produced by ddoc and needs other tools (like LaTeX, DocBook, DocUtils and ReStructuredText, etc). And for checking quality of documentation a manual certification required. But see above :(
 Boost, another successful library repository, also adds on peer review.  
 Perhaps in the future, as our user base grows, we can add another layer  
 of certification for projects that pass peer review.

Boost is a different beast. Boost pretends to be a big library with all its parts coupled together. And each part will be available to user 'out-of-box' after installing Boost (AFAIK there is a special tool, bcp, which can be used to extract only necessary part of Boost, but it seems that bcp don't used widely). And in C++ there are some other factors like compiler (one may have VC++7.1, VC++8.0 and MinGW C++ installed at the same time and for each compiler Boost must be compiled separately) and different compilation modes (dll/lib, static/shared RTL). So inclusion of new library in Boost via review is a righteous approach for Boost. And yet another difference: Boost is a collection of _libraries_. Not all projects at DSource are libraries now and not all will be in future. So I don't think certification on DSource is a good thing. There are other resources which can be used for such rating/review. Ohloh [3] for example. [1] http://gems.rubyforge.org/stats.html [2] http://rubyforge.org/ (sections 'GForge Stats' and 'Recently Registered Projects') [3] http://www.ohloh.net PS. Excuse me for my poor English, I'm just learning. -- Regards, Yauheni Akhotnikau
Apr 11 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
eao197 wrote:
 On Wed, 11 Apr 2007 10:40:10 +0400, Walter Bright 
 <newshound1 digitalmars.com> wrote:
 
 I.e., can we change dsource so that there are two kinds of projects:

 1) Projects that are not certified, and
 2) Projects that are certified

I think certification should be optional and not certified projects should not be seen as second-class projects in comparision with certified (first-class) projects.

In any repository of projects, there's going to be a very wide range of quality. There are going to be first rate projects, second rate ones, and third rate ones. If a new D user takes a look at dsource, is there any way he can tell the difference without a large investment of his time? There are other ways to rank projects besides a certification process. One could be like the 'digg' system where registered users can do a thumbs up or thumbs down on a particular project. Then, the new D user can just look at highly rated ones if he chooses. A variation on that would be where certain annointed moderators give the rankings.
 A live example is RubyGems at RubyForge -- there isn't any certification 
 and RubyForge's RubyGems archive works. And that is fine because 
 RubyForge hosts Gems from (at least) 1500 projects [1] and new projects 
 start almost every day [2]. It is hard to imagine that someone tries to 
 certificate part of those projects and their different versions. I have 
 several my projects on RubyForge and one of them can pass its unit-test 
 only in special environment. That project can't pass automatic 
 certification procedure based on unit-tests, but it works.

 So I don't think manual certification will possible if DSource starts 
 host a big amount of projects comparable with RubyForge and CPAN.

That is a good point. But that's why uncertified projects wouldn't be excluded from the system - it's just that certified ones meet certain requirements. Certainly, there can be good ones that cannot meet the requirements.
 Ddoc documentation may be important for some kind of projects, like 
 libraries. But for other types it simply doesn't matter. DSSS is a good 
 example -- I don't want to look into its code, but I wish to have 
 advanced documentaion. In some cases such documentation can't be 
 produced by ddoc and needs other tools (like LaTeX, DocBook, DocUtils 
 and ReStructuredText, etc). And for checking quality of documentation a 
 manual certification required. But see above :(

You're right in the case of non-libraries. But I think the ddoc requirement should apply to libraries.
 Boost, another successful library repository, also adds on peer 
 review. Perhaps in the future, as our user base grows, we can add 
 another layer of certification for projects that pass peer review.

Boost is a different beast. Boost pretends to be a big library with all its parts coupled together. And each part will be available to user 'out-of-box' after installing Boost (AFAIK there is a special tool, bcp, which can be used to extract only necessary part of Boost, but it seems that bcp don't used widely). And in C++ there are some other factors like compiler (one may have VC++7.1, VC++8.0 and MinGW C++ installed at the same time and for each compiler Boost must be compiled separately) and different compilation modes (dll/lib, static/shared RTL). So inclusion of new library in Boost via review is a righteous approach for Boost. And yet another difference: Boost is a collection of _libraries_. Not all projects at DSource are libraries now and not all will be in future.

I agree. Perhaps the certification process should only be applied to libraries. The Boost peer review does have a somewhat different agenda, I was just referring to the part of its agenda where the Boost libraries have to pass a certain level of quality. I think that could be a very valuable filter for someone looking for the best of the best D libraries.
 So I don't think certification on DSource is a good thing. There are 
 other resources which can be used for such rating/review. Ohloh [3] for 
 example.
 
 [1] http://gems.rubyforge.org/stats.html
 [2] http://rubyforge.org/ (sections 'GForge Stats' and 'Recently 
 Registered Projects')
 [3] http://www.ohloh.net
 
 PS. Excuse me for my poor English, I'm just learning.

Your english is excellent. No apologies are necessary.
 --Regards,
 Yauheni Akhotnikau

Apr 11 2007
next sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Walter Bright wrote:

 Ddoc documentation may be important for some kind of projects, like 
 libraries. But for other types it simply doesn't matter. DSSS is a 
 good example -- I don't want to look into its code, but I wish to have 
 advanced documentaion. In some cases such documentation can't be 
 produced by ddoc and needs other tools (like LaTeX, DocBook, DocUtils 
 and ReStructuredText, etc). And for checking quality of documentation 
 a manual certification required. But see above :(

You're right in the case of non-libraries. But I think the ddoc requirement should apply to libraries.

Not all projects use ddoc, some use for instance Doxygen instead... --anders
Apr 11 2007
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Anders F Björklund wrote:
 Walter Bright wrote:
 You're right in the case of non-libraries. But I think the ddoc 
 requirement should apply to libraries.

Not all projects use ddoc, some use for instance Doxygen instead...

Rather than get into an argument about what makes a project certified or not, a 'digg' style voting system might be better: 1) each registered user can vote +1, 0, or -1 on each project. The project then gets a score, which is a simple sum of these. 2) a user can change their vote on a project at any time. 3) votes that are over 1 year old get expired, and set to 0. One potential difficulty with this is someone registering a boatload of accounts in order to shill a particular project. This can be mitigated if people can, sliced by project and user, see who voted for what.
Apr 11 2007
next sibling parent reply Max Samukha <samukha voliacable.com> writes:
On Wed, 11 Apr 2007 10:28:57 -0700, Walter Bright
<newshound1 digitalmars.com> wrote:

Anders F Bjorklund wrote:
 Walter Bright wrote:
 You're right in the case of non-libraries. But I think the ddoc 
 requirement should apply to libraries.

Not all projects use ddoc, some use for instance Doxygen instead...

Rather than get into an argument about what makes a project certified or not, a 'digg' style voting system might be better: 1) each registered user can vote +1, 0, or -1 on each project. The project then gets a score, which is a simple sum of these.

A simple sum is not fair enough? The ratings of a good general purpose project will be much higher than those of a very specialized project of the same or better quality.
2) a user can change their vote on a project at any time.

3) votes that are over 1 year old get expired, and set to 0.

One potential difficulty with this is someone registering a boatload of 
accounts in order to shill a particular project. This can be mitigated 
if people can, sliced by project and user, see who voted for what.

Apr 11 2007
parent reply Georg Wrede <georg nospam.org> writes:
Max Samukha wrote:
 On Wed, 11 Apr 2007 10:28:57 -0700, Walter Bright wrote:
Anders F Bjorklund wrote:
Walter Bright wrote:

not, a 'digg' style voting system might be better: 1) each registered user can vote +1, 0, or -1 on each project. The project then gets a score, which is a simple sum of these.

A simple sum is not fair enough? The ratings of a good general purpose project will be much higher than those of a very specialized project of the same or better quality.

True. So use percentages instead. Myfooproj: 66%up 12%dn 22%z, 550 votes
Apr 14 2007
parent reply Gregor Richards <Richards codu.org> writes:
Georg Wrede wrote:
 Max Samukha wrote:
 On Wed, 11 Apr 2007 10:28:57 -0700, Walter Bright wrote:
 Anders F Bjorklund wrote:
 Walter Bright wrote:

or not, a 'digg' style voting system might be better: 1) each registered user can vote +1, 0, or -1 on each project. The project then gets a score, which is a simple sum of these.

A simple sum is not fair enough? The ratings of a good general purpose project will be much higher than those of a very specialized project of the same or better quality.

True. So use percentages instead. Myfooproj: 66%up 12%dn 22%z, 550 votes

Percentages are bad because votes get progressively less important. If the project was bad but then got its act together, it will still never have a positive rating. - Gregor Richards
Apr 14 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Gregor Richards wrote:
 Percentages are bad because votes get progressively less important. If 
 the project was bad but then got its act together, it will still never 
 have a positive rating.

That's why I suggested that people can change their votes, and that votes expire after a year. That keeps the results from getting too stale.
Apr 14 2007
parent reply Gregor Richards <Richards codu.org> writes:
Walter Bright wrote:
 Gregor Richards wrote:
 Percentages are bad because votes get progressively less important. If 
 the project was bad but then got its act together, it will still never 
 have a positive rating.

That's why I suggested that people can change their votes, and that votes expire after a year. That keeps the results from getting too stale.

Ah right. I haven't really been following this thread carefully :P + vote from me then. - Gregor Richards
Apr 14 2007
parent "David B. Held" <dheld codelogicconsulting.com> writes:
Gregor Richards wrote:
 Walter Bright wrote:
 Gregor Richards wrote:
 Percentages are bad because votes get progressively less important. 
 If the project was bad but then got its act together, it will still 
 never have a positive rating.

That's why I suggested that people can change their votes, and that votes expire after a year. That keeps the results from getting too stale.

Ah right. I haven't really been following this thread carefully :P + vote from me then.

Or, if you wanted to get really technical, you could weight each vote by its age, so that brand new votes are weighted 1.0, and the oldest vote is weighted 0.0, and everything in between is interpolated. Or, you could combine that with a moving window to simply drop off old votes. Dave
Apr 14 2007
prev sibling parent reply janderson <askme me.com> writes:
Walter Bright wrote:
 Anders F Björklund wrote:
 Walter Bright wrote:
 You're right in the case of non-libraries. But I think the ddoc 
 requirement should apply to libraries.

Not all projects use ddoc, some use for instance Doxygen instead...

Rather than get into an argument about what makes a project certified or not, a 'digg' style voting system might be better: 1) each registered user can vote +1, 0, or -1 on each project. The project then gets a score, which is a simple sum of these. 2) a user can change their vote on a project at any time. 3) votes that are over 1 year old get expired, and set to 0. One potential difficulty with this is someone registering a boatload of accounts in order to shill a particular project. This can be mitigated if people can, sliced by project and user, see who voted for what.

I'm not sure about the whole negative re-enforcement. You may find it scare contributions away. -Joel
Apr 11 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
janderson wrote:
 Walter Bright wrote:
 Anders F Björklund wrote:
 Walter Bright wrote:
 You're right in the case of non-libraries. But I think the ddoc 
 requirement should apply to libraries.

Not all projects use ddoc, some use for instance Doxygen instead...

Rather than get into an argument about what makes a project certified or not, a 'digg' style voting system might be better: 1) each registered user can vote +1, 0, or -1 on each project. The project then gets a score, which is a simple sum of these. 2) a user can change their vote on a project at any time. 3) votes that are over 1 year old get expired, and set to 0. One potential difficulty with this is someone registering a boatload of accounts in order to shill a particular project. This can be mitigated if people can, sliced by project and user, see who voted for what.

I'm not sure about the whole negative re-enforcement. You may find it scare contributions away.

Matlab has a big user contribution site. Each project or code snippet gets its own page, people can rate the projects, and people can leave comments. The ratings are "stars" so it doesn't really seem so negative. Even if you have the worst rating you still have a "1 star", which sounds better than a minus anything. In practice lame projects just don't get reviewed because no one cares. Probably the only reason you'd get a bad review is if you promised the world and in the end your program just simply didn't work at all and thereby ended up wasting people's time. Here's one page from there. http://www.mathworks.com/matlabcentral/fileexchange/loadCategory.do?objectType=category&objectId=131&objectName=Filtering If dsource added the *'s rating, and a way to search for projects based on keywords, I think it would be pretty much there. The download count on the matlab pages are kind of helpful as a guide too, but I don't know how you easy that would be to do given open access svn servers. --bb
Apr 11 2007
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Bill Baxter wrote:
 Matlab has a big user contribution site.  Each project or code snippet 
 gets its own page, people can rate the projects, and people can leave 
 comments.  The ratings are "stars" so it doesn't really seem so 
 negative.  Even if you have the worst rating you still have a "1 star", 
 which sounds better than a minus anything.

The * system sounds like a better idea.
Apr 12 2007
prev sibling parent janderson <askme me.com> writes:
Bill Baxter wrote:
 janderson wrote:
 Walter Bright wrote:
 Anders F Björklund wrote:
 Walter Bright wrote:
 You're right in the case of non-libraries. But I think the ddoc 
 requirement should apply to libraries.

Not all projects use ddoc, some use for instance Doxygen instead...

Rather than get into an argument about what makes a project certified or not, a 'digg' style voting system might be better: 1) each registered user can vote +1, 0, or -1 on each project. The project then gets a score, which is a simple sum of these. 2) a user can change their vote on a project at any time. 3) votes that are over 1 year old get expired, and set to 0. One potential difficulty with this is someone registering a boatload of accounts in order to shill a particular project. This can be mitigated if people can, sliced by project and user, see who voted for what.

I'm not sure about the whole negative re-enforcement. You may find it scare contributions away.

Matlab has a big user contribution site. Each project or code snippet gets its own page, people can rate the projects, and people can leave comments. The ratings are "stars" so it doesn't really seem so negative. Even if you have the worst rating you still have a "1 star", which sounds better than a minus anything. In practice lame projects just don't get reviewed because no one cares. Probably the only reason you'd get a bad review is if you promised the world and in the end your program just simply didn't work at all and thereby ended up wasting people's time. Here's one page from there. http://www.mathworks.com/matlabcentral/fileexchange/loadCategory.do?objectType=category&objectId=131& bjectName=Filtering If dsource added the *'s rating, and a way to search for projects based on keywords, I think it would be pretty much there. The download count on the matlab pages are kind of helpful as a guide too, but I don't know how you easy that would be to do given open access svn servers. --bb

Sounds great! -Joel
Apr 14 2007
prev sibling parent reply "David B. Held" <dheld codelogicconsulting.com> writes:
Anders F Björklund wrote:
 Walter Bright wrote:
 
 Ddoc documentation may be important for some kind of projects, like 
 libraries. But for other types it simply doesn't matter. DSSS is a 
 good example -- I don't want to look into its code, but I wish to 
 have advanced documentaion. In some cases such documentation can't be 
 produced by ddoc and needs other tools (like LaTeX, DocBook, DocUtils 
 and ReStructuredText, etc). And for checking quality of documentation 
 a manual certification required. But see above :(

You're right in the case of non-libraries. But I think the ddoc requirement should apply to libraries.

Not all projects use ddoc, some use for instance Doxygen instead...

All CPAN projects use PerlDoc, even though it's not the greatest documentation system ever invented. However, there is something to be said for having consistent-looking documentation across an archive as big as CPAN. That doesn't preclude the library author from having supplemental documentation in their favorite format, but I think it's perfectly reasonable to at least require a library overview in DDoc, for ease of integration. Programs can choose to have their main documentation in another format (like PDF, even), but I still think there should be a "hook" that's in DDoc so that there is a uniform interface across the archive. Dave
Apr 11 2007
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
David B. Held wrote:

 Not all projects use ddoc, some use for instance Doxygen instead...

All CPAN projects use PerlDoc, even though it's not the greatest documentation system ever invented. However, there is something to be said for having consistent-looking documentation across an archive as big as CPAN. That doesn't preclude the library author from having supplemental documentation in their favorite format, but I think it's perfectly reasonable to at least require a library overview in DDoc, for ease of integration.

Well, my only problem with Ddoc now is that it looks like: http://wxd.sourceforge.net/ddoc/ But if required I can make it available, along the usual: http://wxd.sourceforge.net/api/ Looking at four (there are many more) different language bindings for wxWidgets, each of them with their own native documentation comments. So Doxygen was only used to share comments, since it "works" with all (C, C#, Java, and D) The original API docs are in tex, and stand-alone, anyway. http://wxwidgets.org/manuals/2.6/wx_classref.html I guess it's still possible to copy all those over manually, but still looking for a more automated approach, if doable. --anders
Apr 11 2007
next sibling parent reply Brad Anderson <brad dsource.org> writes:
Anders F Björklund wrote:
 David B. Held wrote:
 
 Not all projects use ddoc, some use for instance Doxygen instead...

All CPAN projects use PerlDoc, even though it's not the greatest documentation system ever invented. However, there is something to be said for having consistent-looking documentation across an archive as big as CPAN. That doesn't preclude the library author from having supplemental documentation in their favorite format, but I think it's perfectly reasonable to at least require a library overview in DDoc, for ease of integration.

Well, my only problem with Ddoc now is that it looks like: http://wxd.sourceforge.net/ddoc/ But if required I can make it available, along the usual: http://wxd.sourceforge.net/api/ Looking at four (there are many more) different language bindings for wxWidgets, each of them with their own native documentation comments. So Doxygen was only used to share comments, since it "works" with all (C, C#, Java, and D) The original API docs are in tex, and stand-alone, anyway. http://wxwidgets.org/manuals/2.6/wx_classref.html I guess it's still possible to copy all those over manually, but still looking for a more automated approach, if doable. --anders

There is no UI for project admins to make changes by themselves yet, but the Tango docs are fully automated. http://dsource.org/projects/tango/docs/current/ I've set this up, so that in the future, these things can be achieved with each project... BA
Apr 12 2007
parent Dan <murpsoft hotmail.com> writes:
Brad Anderson Wrote:
 There is no UI for project admins to make changes by themselves yet, but the
 Tango docs are fully automated.
 
 http://dsource.org/projects/tango/docs/current/
 
 I've set this up, so that in the future, these things can be achieved with
 each project...

That is *SWEET* I'm going to read through the Tango comments to see how I can prepare my source to be doc'd in the same manner. I'm really looking forward to your next site upgrade Brad. Sounds like you're working on some cool stuff. : D
Apr 12 2007
prev sibling parent reply Clay Smith <clayasaurus gmail.com> writes:
Anders F Björklund wrote:
 David B. Held wrote:
 
 Not all projects use ddoc, some use for instance Doxygen instead...

All CPAN projects use PerlDoc, even though it's not the greatest documentation system ever invented. However, there is something to be said for having consistent-looking documentation across an archive as big as CPAN. That doesn't preclude the library author from having supplemental documentation in their favorite format, but I think it's perfectly reasonable to at least require a library overview in DDoc, for ease of integration.

Well, my only problem with Ddoc now is that it looks like: http://wxd.sourceforge.net/ddoc/ But if required I can make it available, along the usual: http://wxd.sourceforge.net/api/ Looking at four (there are many more) different language bindings for wxWidgets, each of them with their own native documentation comments. So Doxygen was only used to share comments, since it "works" with all (C, C#, Java, and D) The original API docs are in tex, and stand-alone, anyway. http://wxwidgets.org/manuals/2.6/wx_classref.html I guess it's still possible to copy all those over manually, but still looking for a more automated approach, if doable. --anders

candy? http://svn.dsource.org/projects/arclib/web/arc/arc/input.html
Apr 15 2007
parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Clay Smith wrote:

 Looking at four (there are many more) different language
 bindings for wxWidgets, each of them with their own native
 documentation comments. So Doxygen was only used to share
 comments, since it "works" with all (C, C#, Java, and D)

 The original API docs are in tex, and stand-alone, anyway.
 http://wxwidgets.org/manuals/2.6/wx_classref.html

 I guess it's still possible to copy all those over manually,
 but still looking for a more automated approach, if doable.

candy? http://svn.dsource.org/projects/arclib/web/arc/arc/input.html

Not sure the problem lies in the sugar coating, more the filling ? The main problem with Ddoc is that there is no EXTRACT_ALL setting. http://dsss.codu.org/docs/wxd/wx/wx.wx.html What I meant was that we need an automated approach to convert tex into the Doxygen/csdoc/Ddoc/JavaDoc/whatever, rather than manual... http://cvs.wxwidgets.org/viewcvs.cgi/wxWidgets/docs/latex/wx/ For now I only copied and pasted a few of the wx class descriptions. (looked at http://www.litwindow.com/Knowhow/wxDoxygen/wxdoxygen.html) --anders
Apr 16 2007
prev sibling parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 11 Apr 2007 13:27:43 +0400, Walter Bright  
<newshound1 digitalmars.com> wrote:

 In any repository of projects, there's going to be a very wide range of  
 quality. There are going to be first rate projects, second rate ones,  
 and third rate ones. If a new D user takes a look at dsource, is there  
 any way he can tell the difference without a large investment of his  
 time?

 There are other ways to rank projects besides a certification process.  
 One could be like the 'digg' system where registered users can do a  
 thumbs up or thumbs down on a particular project. Then, the new D user  
 can just look at highly rated ones if he chooses.

I can only speak for myself. When I'm trying to find some library on SourceForge or RubyForge I at first use 'Trove Map' classification tool (for example: http://rubyforge.org/softwaremap/trove_list.php). Then search most active developed and most active downloaded projects and make choice beetwen them. So 'classification' + 'project activity statictics' + 'download counter' is my a key in project searching. And don't forget about 'reputation'. Some projects are well-known (like PCRE, Boost, ACE in C++ world, or Tango in D world). So a user frequently go to a such well-known project directly, without self-dependent lookup.
 I agree. Perhaps the certification process should only be applied to  
 libraries. The Boost peer review does have a somewhat different agenda,  
 I was just referring to the part of its agenda where the Boost libraries  
 have to pass a certain level of quality. I think that could be a very  
 valuable filter for someone looking for the best of the best D libraries.

The certification process is necessary in case of expanding some fundamental libraries, I think. For example, when someone wants to include their extension to Tango or Phobos. -- Regards, Yauheni Akhotnikau
Apr 11 2007
parent reply Brad Anderson <brad dsource.org> writes:
eao197 wrote:
 On Wed, 11 Apr 2007 13:27:43 +0400, Walter Bright
 <newshound1 digitalmars.com> wrote:
 
 In any repository of projects, there's going to be a very wide range
 of quality. There are going to be first rate projects, second rate
 ones, and third rate ones. If a new D user takes a look at dsource, is
 there any way he can tell the difference without a large investment of
 his time?


No, and this bothers me greatly.
 There are other ways to rank projects besides a certification process.
 One could be like the 'digg' system where registered users can do a
 thumbs up or thumbs down on a particular project. Then, the new D user
 can just look at highly rated ones if he chooses.


I also like the digg/reddit system where votes up or down can let the community decide relative merit of projects. Moderators can grow to have too much power and influence, so maybe just an extra up/down vote might be all moderators get.
 I can only speak for myself. When I'm trying to find some library on
 SourceForge or RubyForge I at first use 'Trove Map' classification tool
 (for example: http://rubyforge.org/softwaremap/trove_list.php). Then
 search most active developed and most active downloaded projects and
 make choice beetwen them. So 'classification' + 'project activity
 statictics' + 'download counter' is my a key in project searching.

I have had project activity statistics planned and partially implemented for a while now, and need to find the time to get it completed. There are some issues, like what makes good statistics, but I think I should just impose my will on you and have you "like it." ;) I have also talked with GregorR to create a shared authentication scheme between dsss.codu.org, dsource.org, and any other D site that wishes. We didn't get past the discussion phase, but I still think that one username/password combo in D-land should be enough. OpenID seems like a good idea here. Like many people here, time constraints keep me away from D-land and dsource.org for some stretches of time. That is the current situation in which I find myself. To this end, I thought I'd mention I'm always looking for people to help out. Ideal candidates won't bring radically new ideas at first, but would be willing to work within the current Python-based Trac system. I want to gradually extend the system with D (via Pyd) with some of the features listed above, and eventually have the whole thing running in D. But for now, there will be some Py work. Candidates with previous time invested in the D community have an advantage. Please send me emails if you would like to help. BA P.S. Loosen up the wallets and PayPal accounts, as I will most likely have a fund-raiser soon, to cover the costs of the hosting account. Some have already donated[1] and if you would care to do so as well, see our donations page[2] [1] http://www.dsource.org/site/donors [2] http://www.dsource.org/site/donate
Apr 11 2007
next sibling parent Dan <murpsoft hotmail.com> writes:
Brad Anderson Wrote:

 which I find myself.  To this end, I thought I'd mention I'm always looking
 for people to help out.  Ideal candidates won't bring radically new ideas at
 first, but would be willing to work within the current Python-based Trac
 system.  I want to gradually extend the system with D (via Pyd) with some of
 the features listed above, and eventually have the whole thing running in D.
 But for now, there will be some Py work.  Candidates with previous time
 invested in the D community have an advantage.

Ah nuts. I'm a revolutionary, and my knowledge of Python is rusty.
Apr 11 2007
prev sibling parent Justin C Calvarese <technocrat7 gmail.com> writes:
Brad Anderson wrote:
 I have had project activity statistics planned and partially implemented for a
 while now, and need to find the time to get it completed.  There are some
 issues, like what makes good statistics, but I think I should just impose my
 will on you and have you "like it." ;)

Maybe we could start with "some statistics" and move on to "good statistics" over time. ;) By the way, I created a wiki page at Wiki4D with notes about various Dsource projects: http://www.prowiki.org/wiki4d/wiki.cgi?DsourceOrg Sometimes it's just nice to have various aspects of the project information combined onto the same page. (I especially like having the forum links right next to the project links, but maybe that's just because I miss the custom PHP/MySQL stuff we used to have at Dsource.) Also, it can be useful since this page could show up when I search on Wiki4D.
 I have also talked with GregorR to create a shared authentication scheme
 between dsss.codu.org, dsource.org, and any other D site that wishes.  We
 didn't get past the discussion phase, but I still think that one
 username/password combo in D-land should be enough.  OpenID seems like a good
 idea here.

As long as different sites might be sharing credentials, I think it'd be cool if puremagic's "Issue Tracking System" were shared with Dsource, but that might be too much to hope for. -- jcc7
Apr 12 2007
prev sibling next sibling parent Knud Soerensen <4tuu4k002 sneakemail.com> writes:
On Tue, 10 Apr 2007 23:40:10 -0700, Walter Bright wrote:

 Andrei suggested that a huge resource for Perl users is 
 http://www.cpan.org. Not only is it full of reusable Perl code, it is 
 very easy to access via 
 http://search.cpan.org/~jhi/perl-5.8.0/lib/CPAN.pm, and is a big factor 
 in the ongoing success of Perl.
 
 It seems to me that we are close to this with DSSS coupled with Dsource. 
 So can we get closer?
 
 I.e., can we change dsource so that there are two kinds of projects:
 
 1) Projects that are not certified, and
 2) Projects that are certified
 
 Certified projects must meet certain minimum requirements:
 
 1) They can be installed using DSSS

If we will make sure that it installs on the users computer, we should have dsss report back if it fails to install the project.
 2) They compile and run their unit tests

This is not enough we should require that the unit test have a 95%-100% code coverage or something like that.
 3) They have ddoc documentation for their APIs

This is fine I think.
Apr 11 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 Andrei suggested that a huge resource for Perl users is 
 http://www.cpan.org. Not only is it full of reusable Perl code, it is 
 very easy to access via 
 http://search.cpan.org/~jhi/perl-5.8.0/lib/CPAN.pm, and is a big factor 
 in the ongoing success of Perl.

This was one of the primary motivations for the Tango team "asking" Gregor to include download support early on. I personally feel that this will be the way most libraries should/will be distributed.
 It seems to me that we are close to this with DSSS coupled with Dsource. 
 So can we get closer?
 
 I.e., can we change dsource so that there are two kinds of projects:
 
 1) Projects that are not certified, and
 2) Projects that are certified

Interesting idea, though this sounds like something for Gregor and Brad to discuss.
 Certified projects must meet certain minimum requirements:
 
 1) They can be installed using DSSS
 2) They compile and run their unit tests
 3) They have ddoc documentation for their APIs

I almost hate to mention it, but Tango vs. Phobos compliance should probably be mentioned as well.
 In other words, a project that is certified is one that is easy for 
 users to install, has documentation, and at least appears to work.
 
 Boost, another successful library repository, also adds on peer review. 
 Perhaps in the future, as our user base grows, we can add another layer 
 of certification for projects that pass peer review.

That would be great. DSource is probably pretty close to supporting this in a rough format now between the Wiki and Trac features. It sounds like we mostly need some structured or common means for doing this across projects. Sean
Apr 11 2007
next sibling parent reply Gregor Richards <Richards codu.org> writes:
Sean Kelly wrote:
 This was one of the primary motivations for the Tango team "asking" 
 Gregor to include download support early on.  I personally feel that 
 this will be the way most libraries should/will be distributed.
 

... in what universe did the Tango team ask for this? You'd think if the Tango team was behind it initially, tango would be net-installable via DSSS. And yet, it's not :P - Gregor Richards PS: The reason Tango is not net-installable is because of my do-no-harm philosophy of net-installs. You should not install something, then find that your arbitrary project using Phobos fails for reasons mysterious to you.
Apr 11 2007
next sibling parent Sean Kelly <sean f4.ca> writes:
Gregor Richards wrote:
 Sean Kelly wrote:
 This was one of the primary motivations for the Tango team "asking" 
 Gregor to include download support early on.  I personally feel that 
 this will be the way most libraries should/will be distributed.

.... in what universe did the Tango team ask for this?

According to you: http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.com&group=digitalmars.D&artnum=44249
 You'd think if
 the Tango team was behind it initially, tango would be net-installable 
 via DSSS. And yet, it's not :P

 PS: The reason Tango is not net-installable is because of my do-no-harm 
 philosophy of net-installs. You should not install something, then find 
 that your arbitrary project using Phobos fails for reasons mysterious to 
 you.

These seem to be somewhat contradictory points. You can't argue that Tango not being net installable is somehow a fault of the Tango team (of which you are a part), and at the same time suggest that doing so would be a bad idea. Sean
Apr 11 2007
prev sibling parent Brad Anderson <brad dsource.org> writes:
John Reimer wrote:
 On Wed, 11 Apr 2007 10:36:05 -0700, Gregor Richards wrote:
 
 Sean Kelly wrote:
 This was one of the primary motivations for the Tango team "asking" 
 Gregor to include download support early on.  I personally feel that 
 this will be the way most libraries should/will be distributed.

Tango team was behind it initially, tango would be net-installable via DSSS. And yet, it's not :P - Gregor Richards PS: The reason Tango is not net-installable is because of my do-no-harm philosophy of net-installs. You should not install something, then find that your arbitrary project using Phobos fails for reasons mysterious to you.

Gregor, I think the it was clear that the Tango Team had a "guarded" interest in DSSS, early on. I had plenty of discussions with you about DSSS. But, unless I missed a discussion behind the scenes (quite possible), Gregor is right that there was never a formal acceptance of DSSS. The reason was clear, as I remember discussing the situation: DSSS/rebuild was buggy and unproven, a fact that made it a precarious choice for promoting Tango installations during its early stages where first impressions were crucial (alas, we still had lots of troubles despite that :P ). For myself, I didn't want to see Tango using DSSS until it could be proven to work flawlessly. I think DSSS is almost there and should, once again, be formally tested for release with Tango as an appropriate installation option. However, I'm still somewhat guarded in seeing it as a primary installation option, at this point. -JJR

From the beginning, I took GregorR's comments as jest, and his P.S. covered the issue. Maybe I missed something, but I thought the entire thing was innocent. BA
Apr 11 2007
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
On Wed, 11 Apr 2007 10:36:05 -0700, Gregor Richards wrote:

 Sean Kelly wrote:
 This was one of the primary motivations for the Tango team "asking" 
 Gregor to include download support early on.  I personally feel that 
 this will be the way most libraries should/will be distributed.
 

... in what universe did the Tango team ask for this? You'd think if the Tango team was behind it initially, tango would be net-installable via DSSS. And yet, it's not :P - Gregor Richards PS: The reason Tango is not net-installable is because of my do-no-harm philosophy of net-installs. You should not install something, then find that your arbitrary project using Phobos fails for reasons mysterious to you.

Gregor, I think the it was clear that the Tango Team had a "guarded" interest in DSSS, early on. I had plenty of discussions with you about DSSS. But, unless I missed a discussion behind the scenes (quite possible), Gregor is right that there was never a formal acceptance of DSSS. The reason was clear, as I remember discussing the situation: DSSS/rebuild was buggy and unproven, a fact that made it a precarious choice for promoting Tango installations during its early stages where first impressions were crucial (alas, we still had lots of troubles despite that :P ). For myself, I didn't want to see Tango using DSSS until it could be proven to work flawlessly. I think DSSS is almost there and should, once again, be formally tested for release with Tango as an appropriate installation option. However, I'm still somewhat guarded in seeing it as a primary installation option, at this point. -JJR
Apr 11 2007
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
On Wed, 11 Apr 2007 23:31:59 -0400, Brad Anderson wrote:

 John Reimer wrote:
 On Wed, 11 Apr 2007 10:36:05 -0700, Gregor Richards wrote:
 
 Sean Kelly wrote:
 This was one of the primary motivations for the Tango team "asking" 
 Gregor to include download support early on.  I personally feel that 
 this will be the way most libraries should/will be distributed.

Tango team was behind it initially, tango would be net-installable via DSSS. And yet, it's not :P - Gregor Richards PS: The reason Tango is not net-installable is because of my do-no-harm philosophy of net-installs. You should not install something, then find that your arbitrary project using Phobos fails for reasons mysterious to you.

Gregor, I think the it was clear that the Tango Team had a "guarded" interest in DSSS, early on. I had plenty of discussions with you about DSSS. But, unless I missed a discussion behind the scenes (quite possible), Gregor is right that there was never a formal acceptance of DSSS. The reason was clear, as I remember discussing the situation: DSSS/rebuild was buggy and unproven, a fact that made it a precarious choice for promoting Tango installations during its early stages where first impressions were crucial (alas, we still had lots of troubles despite that :P ). For myself, I didn't want to see Tango using DSSS until it could be proven to work flawlessly. I think DSSS is almost there and should, once again, be formally tested for release with Tango as an appropriate installation option. However, I'm still somewhat guarded in seeing it as a primary installation option, at this point. -JJR

From the beginning, I took GregorR's comments as jest, and his P.S. covered the issue. Maybe I missed something, but I thought the entire thing was innocent. BA

Call me gullible, but I'm not always aware of when Gregor is joking or not; even given his PS, I don't quite get it :-(. I honestly thought that even with a hint of a joke that there was a valid complaint. -JJR
Apr 11 2007
prev sibling parent John Reimer <terminal.node gmail.com> writes:
On Thu, 12 Apr 2007 02:50:52 +0000, John Reimer wrote:

 On Wed, 11 Apr 2007 10:36:05 -0700, Gregor Richards wrote:
 
 Sean Kelly wrote:
 This was one of the primary motivations for the Tango team "asking" 
 Gregor to include download support early on.  I personally feel that 
 this will be the way most libraries should/will be distributed.
 

... in what universe did the Tango team ask for this? You'd think if the Tango team was behind it initially, tango would be net-installable via DSSS. And yet, it's not :P - Gregor Richards PS: The reason Tango is not net-installable is because of my do-no-harm philosophy of net-installs. You should not install something, then find that your arbitrary project using Phobos fails for reasons mysterious to you.

Gregor, I think the it was clear that the Tango Team had a "guarded" interest in DSSS, early on. I had plenty of discussions with you about DSSS. But, unless I missed a discussion behind the scenes (quite possible), Gregor is right that there was never a formal acceptance of DSSS. The reason was clear, as I remember discussing the situation: DSSS/rebuild was buggy and unproven, a fact that made it a precarious choice for promoting Tango installations during its early stages where first impressions were crucial (alas, we still had lots of troubles despite that :P ). For myself, I didn't want to see Tango using DSSS until it could be proven to work flawlessly. I think DSSS is almost there and should, once again, be formally tested for release with Tango as an appropriate installation option. However, I'm still somewhat guarded in seeing it as a primary installation option, at this point. -JJR

Eeeep! Seems I entirely misread what was going on here. They were talking about downloads and net-install... ack... Please, disregard. I've got to watch what I respond to. :-( Brad was right. -JJR
Apr 11 2007
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 Andrei suggested that a huge resource for Perl users is 
 http://www.cpan.org. Not only is it full of reusable Perl code, it is 
 very easy to access via 
 http://search.cpan.org/~jhi/perl-5.8.0/lib/CPAN.pm, and is a big factor 
 in the ongoing success of Perl.

Oh, another thought. Eventually, dependencies should be resolved automatically as well, similar to apt-get. But until then, I suppose they should simply be mentioned in a prominent location in the docs or project description. Sean
Apr 11 2007
parent reply Gregor Richards <Richards codu.org> writes:
Sean Kelly wrote:
 Walter Bright wrote:
 Andrei suggested that a huge resource for Perl users is 
 http://www.cpan.org. Not only is it full of reusable Perl code, it is 
 very easy to access via 
 http://search.cpan.org/~jhi/perl-5.8.0/lib/CPAN.pm, and is a big 
 factor in the ongoing success of Perl.

Oh, another thought. Eventually, dependencies should be resolved automatically as well, similar to apt-get. But until then, I suppose they should simply be mentioned in a prominent location in the docs or project description. Sean

dsss-net-install resolves dependencies automatically. All you need to do is import. - Gregor Richards
Apr 11 2007
parent reply eao197 <eao197 intervale.ru> writes:
On Wed, 11 Apr 2007 21:19:40 +0400, Gregor Richards <Richards codu.org>  
wrote:

 dsss-net-install resolves dependencies automatically. All you need to do  
 is import.

Does DSSS support dependencies from particular library versions (like RubyGems does it [1])? [1] http://www.rubygems.org/read/chapter/10#page33 -- description of --version in 'gem install' command -- Regards, Yauheni Akhotnikau
Apr 11 2007
parent Gregor Richards <Richards codu.org> writes:
eao197 wrote:
 On Wed, 11 Apr 2007 21:19:40 +0400, Gregor Richards <Richards codu.org> 
 wrote:
 
 dsss-net-install resolves dependencies automatically. All you need to 
 do is import.

Does DSSS support dependencies from particular library versions (like RubyGems does it [1])? [1] http://www.rubygems.org/read/chapter/10#page33 -- description of --version in 'gem install' command --Regards, Yauheni Akhotnikau

Not at this time. The dependencies it generates are done so magically, that would be a bit difficult to implement. But it would be possible :) - Gregor Richards
Apr 11 2007
prev sibling next sibling parent reply Gregor Richards <Richards codu.org> writes:
Another step along these lines. Since DSSS can now easily generate 
documentation for everything it builds (with ddoc), and I will soon be 
automatically generating this documentation and uploading it (probably) 
to dsss.codu.org.

  - Gregor Richards
Apr 14 2007
parent Gregor Richards <Richards codu.org> writes:
Gregor Richards wrote:
 Another step along these lines. Since DSSS can now easily generate 
 documentation for everything it builds (with ddoc), and I will soon be 
 automatically generating this documentation and uploading it (probably) 
 to dsss.codu.org.
 
  - Gregor Richards

I put the documentation which could be easily generated in my first run up at http://dsss.codu.org/docs/ There are a number of projects that need a slight change with recent changes to DSSS, and as a side-effect they can't generate documentation (yet). Unfortunately, creating this documentation index has mostly taught me that most software doesn't have ddoc documentation :P - Gregor Richards PS: Libraries that couldn't have documentation generated have dsss.conf's in this form: [+foo.d] preinstall = install foo.d $INCLUDE_PREFIX The reason that dsss.conf files used to have entries like that was a bug in DSSS, which prevented .d files from being installed as libraries. That bug has been fixed, so this can now be: [foo.d] type=sourcelibrary With this change, documentation will also be generated.
Apr 14 2007
prev sibling parent Jan Claeys <usenet janc.be> writes:
Op Thu, 12 Apr 2007 15:03:41 +0900
schreef Bill Baxter <dnewsgroup billbaxter.com>:

 Matlab has a big user contribution site.  Each project or code
 snippet gets its own page, people can rate the projects, and people
 can leave comments.  The ratings are "stars" so it doesn't really
 seem so negative.  Even if you have the worst rating you still have a
 "1 star", which sounds better than a minus anything.  In practice
 lame projects just don't get reviewed because no one cares.  Probably
 the only reason you'd get a bad review is if you promised the world
 and in the end your program just simply didn't work at all and
 thereby ended up wasting people's time.

That's about how Mozilla.org's Firefox/Thunderbird Extension site works too. -- JanC
Apr 17 2007