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:


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.


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:


 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.


 
 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 next 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 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
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


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

 
 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

 
 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


 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


This is great but on who's computer the developers or the users ??
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
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 reply 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
next sibling parent reply 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.


 ... 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


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
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.


 ... 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


 
 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 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