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