www.digitalmars.com         C & C++   DMDScript  

D - D Repository Site: Feature Requests

reply BenjiSmith <BenjiSmith_member pathlink.com> writes:
Well, somebody's got to do it, and it may as well be me.

I'm tired of implementing code that I know has already been written by somebody
else. I've written linked list templates and stack templates. I know that
somebody else has already done it before me, and I know that somebody else in
D-land is probably wasting their time doing the same thing again after me. That
doesn't make sense. We desperately need to be sharing our code with eachother.

Plus, I'm nearing completion of a DOM XML parser that I'd like to share with the
world. Where will I put it?

I'm excited about the (incredibly rapid) progress of dig and of dedit and of
dide. I'd like to try out Burton's URL library. I'd like to see the DServicesAPI
project get off the ground. I'd like to try out Andy's zlib bindings and
Marten's CGI module and Luna Kid's LUA bindings. I'd really like to see the GCC
front-end project actually get off the ground.

But how am I going to keep track of all these projects. And what if there were
100 projects that I wanted to keep my eye on?

Within the next few weeks, I'll be hosting a website that will serve as a
repository for D source code. Whether you're writing open-source modules,
packages, or entire frameworks and applications, this website will be a place
where you can post your code. And, even if your code isn't open-source, you can
still post compiled libraries or even just links to other pages with more
details about your closed-source commercial projects. I want EVERYBODY who is
writing D code to post their code on this website. This will be for D what CPAN
is for perl.

The purpose of this site isn't to push any type of open-source agenda (because I
really don't care). The purpose is to create a centralized repository of code
written in D, where users can create their own projects with their own pages and
upload their own files. I envision this site fulfilling much the same role as
sourceforge, but on a limited scope (D language only) and much less complex than
sourceforge.

(Incidentally, I've spent the last 4 MONTHS writing to the sourceforge admins,
trying to get them to add D to the Trove software map, so that new projects
could be classified as D-language-projects, but they have never answered a
single one of my messages.)

It's important to note that ANY d code will be welcome on this site, even if
it's just snippets of code. I don't want to limit the code on the site to just
completed modules or just completed applications. Limitations of that kind will
just make contributions to the site more sparse. In fact, I'm setting a goal of
having 100,000 lines of D code hosted by the end of the year.

Of course, for any of it to mean anything, I'll need everyone here to
contribute.

One of the projects that I'd like to host (though I probably won't contribute
much code to it myself) is a Standard Template Library implementation (Matthew
Wilson, I'm looking at you, here). I think it's important that we define our STL
needs and make some preliminary plans regarding their implementation, and THEN
we can tell Walter what type of Template syntax fits our needs. At that point,
we'll be able to make a much more compelling argument, and Walter will be more
likely to implement our suggestions than if we just say "templates suck! change
them!" (BTW, my proposal for a name for this STL implementation is: STOLID
(standard template library in D))

I've just registered a domain name for this D repository project (I'm not going
to tell you what it is yet), and I have hosting space for it already. All I need
to do is implement the actual site, and we'll be up and running. I'm in the
process of evaluating some software to drive the template engine and
functionality of the site, and I think I can have a beta version of it up in two
or three weeks' time.

Anyhow, I want to make sure that this site will be usefull to the D community,
so I want to get your input regarding features. Here are the things I'm planning
on doing already:

* A centralized module-request page, where D programmers can make a wish-list of
modules and packages that they'd like to see implemented by somebody.

* Registered users can create their own project pages.

* Project-page owners can post descriptions of their projects.

* Project-page owners can post archive files (*.zip, *.tar.gz, etc.) for their
projects. Anybody (even non-registered users) can download these files.

* Project-page owners can post documentation (html, pdf, etc.) for their
projects.

* Each project page will have its own archived discussion forum.

* Each project page will have its own archived bugtracker.

* CVS access to source code. (This will take some thinking on my part, since it
will have to be a totally web-enabled interface (I can install cvs, but my
virtual hosting provider doesn't allow ssh access). However, web-enabled cvs
isn't very useful for doing commits on projects with 500 files. So, this won't
be a part of the beta version of the website, but I'll be thinking about some
way to solve the version control problem. Your suggestions in this respect would
be especially helpful.)

Anyhow, those are the features that I'm planning on implementing at this point.
Let me know what else you'd like to see, and I'll take your suggetions into
consideration.
Aug 06 2003
next sibling parent Ant <Ant_member pathlink.com> writes:
In article <bgr6hf$vaf$1 digitaldaemon.com>, BenjiSmith says...

Within the next few weeks, I'll be hosting a website that will serve as a
repository for D source code.


:)


(BTW, my proposal for a name for this STL implementation is: STOLID
(standard template library in D))


ETYMOLOGY: Latin stolidus, stupid. 
is "Deimos" already taken?


I've just registered a domain name for this D repository project (I'm not going
to tell you what it is yet)


:( if you do maybe we could start using it for package names.

Ant
Aug 06 2003
prev sibling next sibling parent Patrick Down <Patrick_member pathlink.com> writes:
In article <bgr6hf$vaf$1 digitaldaemon.com>, BenjiSmith says...


It's important to note that ANY d code will be welcome on this site, even if
it's just snippets of code. I don't want to limit the code on the site to just
completed modules or just completed applications. Limitations of that kind will
just make contributions to the site more sparse. In fact, I'm setting a goal of
having 100,000 lines of D code hosted by the end of the year.


For code snippets I'd suggest having something like flipcode's code 
of the day section.

http://www.flipcode.com/cotd/
Aug 06 2003
prev sibling next sibling parent Ilya Minkov <midiclub 8ung.at> writes:
BenjiSmith wrote:

 Well, somebody's got to do it, and it may as well be me.


Thanks a lot.


For prooject management you may evalueate GForge.

http://gforge.org/

Blender.org guys have made good experience with it and say that it's 
easy to install. It's a branch of sourceforge code.

-i.
Aug 06 2003
prev sibling next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
 One of the projects that I'd like to host (though I probably won't


contribute

 much code to it myself) is a Standard Template Library implementation


(Matthew

 Wilson, I'm looking at you, here).


Ouch! It appears I am being detected on too many radars at the moment! I may
have to get back under a rock ...

ftr, I am a bit snowed under for the next few month with my writing
activities, so I cannot commit to a significant amount of D coding. However,
I'm happy to be lend a hand (and an opinion) at reviewing work in the next
month or so.

In the long run I'd like to see the following:

1. A platform-/technology-neutral standard template library. To my mind,
this should do most of what STL does, but without the syntactic
contradictions ("empty()" reports on the empty state of a container, while
"erase()" effects erasure of element(s) from a container), without the
iostreams (bleuch!) - though we should have a generic, efficient, decoupled
streaming library! -,  and without the hideous levels of coupling between
the various types. If D gives us the template support we need, then this is
eminently feasible. I believe that, if done correctly, this will be an
enormous draw to C++ programmers who are (i) not scared of templates/STL,
(ii) who value its power and efficiency, and (iii) are sick of having reams
of pre-processor stuff (check out stlsoft_iterator.h!) in order to have
their library components be portable between compilers (and compiler
versions).

To make this happen, I think we need some people who are so inclined to
start a template library with very small aims, and then to review and factor
from the various solutions. Say start with a couple of simple containers (+
arrays), and a couple of simple algorithms, and see what that turns up.

At the moment, I have no clue as to how such things would be implemented in
D. I just tried to concoct a couple of algorithms and functors in D, and was
utterly stumped. Take a simple example: can anyone describe how we would
implement a for_each?

2. Platform-/technology-specific libraries, akin to what I'm doing in
STLSoft. I've already done some of this myself, with the performance
counters available at SynSoft (http://synsoft.org/d.html) - though I need to
open-source-ise what there is there now - and will do more as time allows.


FYI, I've spoken with Walter in the past and suggested that I'd do a much
fuller framework for COM, akin to ATL but without all the
gunk/proprietary-extensions/poor-encapsulation. The next significant release
of STLSoft (1.7.1) will contain a very large amount of new COM code, and I
am hoping (if D's template support is capable) to dual-develop some of the
stuff. This was to be my first major D effort, and I'd like to do that as
soon as I've got the bulk of the current book done (so in about 2 months).

I perhaps might mention now that I have serious plans to write a book on D,
and had thought of using the D+COM+template library as an exemplar for the
concepts of D as the book progresses. Whether this comes to fruition depends
on whether the publisher and I see a significant market, whether D is at a
sufficiently stable point, and whether it has the appropriate support and
infrastructure (libraries, open-source, perhaps more than one
compiler-walter). All of these things are, of course, related, and are in no
small way dependent on all of us D-interesteds and the support we lend to D
in the near future. It's either a vicious circle or a pleasing mutual
dependency, depending on whether your glass is half-full.

I guess this issue of willingness to lend one's effort is core to all the
things we're discussing. For example, if I was 100% certain that D would
succeed (technically *and* commercially), then I would probably prioritise
DTL as equivalent to STLSoft in the amount of time I would give. Conversely,
if I was 0% certain, then I'd stop thinking about D entirely. (Obviously
this same applies to everyone.) My coarse assessment would be that I think
that D is technically (language) 80% complete, and commercially (tools and
libraries) 10%. Both deficiencies are being addressed, so its just a case of
balancing the desire to get in and make a difference with the risk of
wasting ones time.

I think your repository will help a lot, as would the D Libraries Group idea
that I suggested a while back, along with the various independent efforts
already underway (DIG, DIDE, etc.).


 I think it's important that we define our STL
 needs and make some preliminary plans regarding their implementation, and


THEN

 we can tell Walter what type of Template syntax fits our needs.


I'm of no use here. I'm an editor/adapter, rather than a creator or a
theoretician. The only contribution I can make is to say I'd like a better
STL, rather than concocting a whole new paradigm of template use.


  At that point,
 we'll be able to make a much more compelling argument, and Walter will be


more

 likely to implement our suggestions than if we just say "templates suck!


change

 them!"


Difficult task. As I said, I'm happy to criticise any work, and also to help
various contributors to distill out what is good into a nacent standard
libary (item 1 above). Maybe the solution is to expound on the question
above, and ask the group how we would implement some simple STL
algorithms/functionals. This would inform on what was missing very quickly.


 (BTW, my proposal for a name for this STL implementation is: STOLID
 (standard template library in D))


Don't like the name, I'm afraid. I had decided to call my D+COM+template
library DTL, but I think that's probably better suited to the D equivalent
of the STL (item 1 above). However, I see the templates as being
(logically - not coupled!) part of the D standard library, and so putting
the T into the name kind of jars.


 I've just registered a domain name for this D repository project (I'm not


going

 to tell you what it is yet), and I have hosting space for it already. All


I need

 to do is implement the actual site, and we'll be up and running. I'm in


the

 process of evaluating some software to drive the template engine and
 functionality of the site, and I think I can have a beta version of it up


in two

 or three weeks' time.


Don't be coy. Let us know.

FTR, I registered http://templated.org a while back, with the intention of
hosting the template library(ies) I might write in D. Nothing's happened
there yet. ;)


btw, this venture of yours may be the way we get The D Journal up and
running. Once a library has enough maturity its author(s) may wish to
contribute an article on the subject. :)

Matthew
Aug 06 2003
prev sibling next sibling parent reply Helmut Leitner <helmut.leitner chello.at> writes:
BenjiSmith wrote:

 
 Well, somebody's got to do it, and it may as well be me.
 ... 
 Within the next few weeks, I'll be hosting a website that will serve as a
 repository for D source code. Whether you're writing open-source modules,
 packages, or entire frameworks and applications, this website will be a place
 where you can post your code. 


That's great! Thank you for doing it. 


 ...
 Anyhow, I want to make sure that this site will be usefull to the D community,
 so I want to get your input regarding features. Here are the things I'm
planning
 on doing already:
 
 * A centralized module-request page, where D programmers can make a wish-list
of
 modules and packages that they'd like to see implemented by somebody.
 
 * Registered users can create their own project pages.
 
 * Project-page owners can post descriptions of their projects.
 
 * Project-page owners can post archive files (*.zip, *.tar.gz, etc.) for their
 projects. Anybody (even non-registered users) can download these files.
 
 * Project-page owners can post documentation (html, pdf, etc.) for their
 projects.
 
 * Each project page will have its own archived discussion forum.
 
 * Each project page will have its own archived bugtracker.
 
 * CVS access to source code. (This will take some thinking on my part, since it
 will have to be a totally web-enabled interface (I can install cvs, but my
 virtual hosting provider doesn't allow ssh access). However, web-enabled cvs
 isn't very useful for doing commits on projects with 500 files. So, this won't
 be a part of the beta version of the website, but I'll be thinking about some
 way to solve the version control problem. Your suggestions in this respect
would
 be especially helpful.)
 
 Anyhow, those are the features that I'm planning on implementing at this point.
 Let me know what else you'd like to see, and I'll take your suggetions into
 consideration.


When I set up CVS for the ICFP contest, I found that CVS is not as friendly as
it could be. The problem is that basically changes to the repository are
attributed
to unix user accounts. But typically you won't want to create full unix accounts
for all the people writing to the CVS. You can also configure CVS-only-users
that 
each run under a certain unix account (maybe only one), but then you can't see
who 
did the commits. On ICFP Burton suggested to put user names into the mantatory 
commit comments, but this didn't work well, because users often forgot.

I didn't find an easy solution to this, but maybe there is one for I'm new to
CVS. 
There is also a successor to CVS (subversion) that might be worth considering.

--
Helmut Leitner    leitner hls.via.at   
Graz, Austria   www.hls-software.com
Aug 22 2003
parent reply Benji smith <dlanguage xxagg.com> writes:
In article <3F46385E.608E7D89 chello.at>, Helmut Leitner says...

When I set up CVS for the ICFP contest, I found that CVS is not as 


friendly as

it could be. The problem is that basically changes to the repository are 


attributed

to unix user accounts.


I've been thinking about this same issue. The server where I'll be hosting 
this repository is not my own server. It's a virtual server that I'll be paying 
for. And I won't be able to creat unix accounts for my users. I might be able 
to create an "anonymous" account for all cvs commits, but then I won't be 
able to distinguish between project owners and project users. And the 
owner of project X would have no trouble committing changes to project Y.

For that reason, I'm looking for something other than CVS. If anyone has 
any suggestions, please let me know. It absolutely has to be something 
that users can connect to without having their own unix accounts, and 
without using ssh.


There is also a successor to CVS (subversion) that might be worth 


considering.

Now that you mention it, I've heard of subversion, but I've never checked it 
out. I'll take a look and see what I think.

--Benji Smith
Aug 22 2003
parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Benji smith" <dlanguage xxagg.com> wrote in message
news:bi5gg4$1b9c$1 digitaldaemon.com...

 In article <3F46385E.608E7D89 chello.at>, Helmut Leitner says...

 For that reason, I'm looking for something other than CVS. If anyone has
 any suggestions, please let me know. It absolutely has to be something
 that users can connect to without having their own unix accounts, and
 without using ssh.


perforce (www.perforce.com) should do the trick, you can get a free licence
for open source development.
Aug 22 2003
parent reply "Lars Ivar Igesund" <larsivi stud.ntnu.no> writes:
"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:bi6hdc$2rpa$2 digitaldaemon.com...

 "Benji smith" <dlanguage xxagg.com> wrote in message
 news:bi5gg4$1b9c$1 digitaldaemon.com...

 In article <3F46385E.608E7D89 chello.at>, Helmut Leitner says...

 For that reason, I'm looking for something other than CVS. If anyone has
 any suggestions, please let me know. It absolutely has to be something
 that users can connect to without having their own unix accounts, and
 without using ssh.


 perforce (www.perforce.com) should do the trick, you can get a free


licence

 for open source development.


You could also check out SVN (Subversion). It's meant to be
an open source CVS replacement. It hasn't reached 1.0 yet, but
they claim that it is stable.

subversion.tigris.org

Lars Ivar Igesund
Aug 23 2003
parent Benji Smith <dlanguage xxagg.com> writes:
In article <bi7cfl$19os$1 digitaldaemon.com>, Lars Ivar Igesund says...

You could also check out SVN (Subversion). It's meant to be
an open source CVS replacement. It hasn't reached 1.0 yet, but
they claim that it is stable.

subversion.tigris.org


I've spent the last couple of days looking at subversion. Although it's not 
yet at 1.0, and althogh it'll be a little more difficult to install than
perforce, I 
think it's the right choice. It's similar enough to CVS that it'll be familiar
for 
most people, and the subversion server works as a web_dev extension to 
the apache server, so it should fit well with the rest of the server software 
that I'm installing.

Also, subversion has some nice built-in hooks, so it should be easy to 
write some scripts to do things like create-snapshot-on-commit.

If anybody knows of any major caveats with subversion, let me know. 
Otherwise, it will become the official source control system of the d 
repository site.

In other news,  I've also been looking at the gforge.org website (g forge is 
a branch of the sourceforge code that's also been used to build the 
blender.org website). I'll have to do some work to get subversion to 
integrate with the gforge code (instead of CVS), but I think I should be able 
to get it to work out pretty well.

So, as far as I'm concerned right now, the site will be built with: apache 
2.0, php 4, gforge 3.0, postgreSQL (for the gforge db), subversion 0.27, 
Berkely DB 4 (for the subversion db), webdav Neon (for the subversion 
protocol), and some other stuff to glue it all together.

So, yes there is a d repository site coming soon. I'm working on it.

--Benji Smith
Aug 23 2003
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
BenjiSmith wrote:

 Well, somebody's got to do it, and it may as well be me.


So, how far are you at the moment?

Do you need any help?

-eye
Sep 10 2003
parent Benji Smith <dlanguage xxagg.com> writes:
In article <bjnlcf$2ljn$1 digitaldaemon.com>, Ilya Minkov says...

BenjiSmith wrote:

 Well, somebody's got to do it, and it may as well be me.


So, how far are you at the moment?

Do you need any help?

-eye


I'm actually pretty far along in the process. I've picked all of the software
that I'll be using. I've bought the domain name. I did some serious shopping for
juuuuuust the right hosting provider (I'll tell you guys more about this later).
I've installed all the software that we'll need, including the subversion
source-repository server ( read more at http://subversion.tigris.org ) and the
gforge project-management interface.

I had forgotten what an enormous pain in the ass it is to install software on
unix boxes. I've spent the last 3 weeks (remember, this isn't my full-time job)
trying to sort out dependencies between all of the software, and, in the end,
this is the complete list of all the software that I had to compile and install:

autoconf
libtool
bison
flex
apache 2
subversion
gforge
berkeley db
kerberos
php
gd
libpng
libjpeg
libfreetype
imap
readline
mysql
phpMyAdmin
postgreSQL
python
lynx

Nearly all of these software packages needed to be compiled from source code.
All of them had to configured with lots of special options so that they could
play nice with eachother. Many of them had version-specific dependencies on
eachother, and few of them were able to find the appropriate header files and
libraries that they needed for compilation without significant help from me.

All of this is somewhat of an inspiration for me to propose some sort of common
source-tree structure for d development, but I'll save that for another thread.

Anyhow, at the moment, all of the software we'll need has been installed, and it
all seems to be working. I'm doing a little bit of database config stuff right
now, and then I'm going to have to write a little bit of code to modify the
existing php modules, which expect to connect with CVS, so that they can connect
to the subversion server than that. After that, I'll be ready to perform some
alpha testing with a few small projects and code-repositories. As soon as I
finish a round of alpha testing (and maybe a little bit of graphic design to
customize the default gforge template), I'll ask for a few beta testers from the
ng. After a round of beta testing, I'll make a BIG ANNOUNCEMENT here in the ng,
and the official D repository site will be up and running.

Hopefully, there will be lots of support from the existing D community. I'm
expecting the authors of any significant D projects (dig, DUI, etc.) to use the
repository as their source-control and release management mechanism. Ideally, if
Walter is game, I'd like to have phobos hosted as a project on the site, and to
make that project the primary means of distributing phobos. What's more--as long
as Walter is willing--I'm going to mirror the dmd compiler binaries (and the
changelog) in their own project.

To get ready for the big day when I announce the site, it would probably be wise
to familiarize yourself with the "subversion" source control system, if you're
not already. It's very similar to CVS, but at least slightly better in every
way.

As far as a timeline is concerned, I think I'll be done with the alpha testing
stage within less than a week (knock on wood), and I expect to be done with beta
testing in less than three weeks (if I can get some people to volunteer to be
testers).

Other than that, I think we're on our way.
Sep 10 2003