www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - D projects list

reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
I think it will be great to have a single place for all D related 
projects so a developer can easily find what is already done
(for an example of "I didn't now about you project" see, e.g. "Modern 
COM Programming in D" thread), what is *planned* and what great projects 
have already failed (and, maybe, reveal it).

A draft variant of how I see such page is this with a few projects added 
(note "Planned" tag (yes, empty for now)):
http://deoma-cmd.ru/d/d-projects-list/

Usage examples:
* lets find a D compiler with release or beta maturity:
http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release
* lets find not abandoned GUI library for D:
http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned


I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into 
GitHub so developers can fork and edit it.

I'd like to hear (but yes, I can only read, this is NG) any thoughts 
about this idea.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 05 2012
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
 Denis V. Shelomovskij
 I'd like to hear (but yes, I can only read, this is NG) any thoughts
 about this idea.


Looks very cool, nice job!

On 4/5/12, Denis Shelomovskij <verylonglogin.reg gmail.com> wrote:

 http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned


A newer binding of Tk is on github although dated 2008 (not mine):
https://github.com/lysevi/dkinter
I've got an updated version that can use the newer Tk that has ttk
(more native-look widgets).

But I didn't bother with Tk much because it basically comes down to
having to pass strings to a Tk eval function. For anything complicated
you have to allocate a ton of strings.. Tk is probably best left for
use with scripting languages imo.
Apr 05 2012
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Denis Shelomovskij" <verylonglogin.reg gmail.com> wrote in message 
news:jlkubn$k4f$1 digitalmars.com...

I think it will be great to have a single place for all D related projects 
so a developer can easily find what is already done
 (for an example of "I didn't now about you project" see, e.g. "Modern COM 
 Programming in D" thread), what is *planned* and what great projects have 
 already failed (and, maybe, reveal it).

 A draft variant of how I see such page is this with a few projects added 
 (note "Planned" tag (yes, empty for now)):
 http://deoma-cmd.ru/d/d-projects-list/

 Usage examples:
 * lets find a D compiler with release or beta maturity:
 http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release
 * lets find not abandoned GUI library for D:
 http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned


 I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into 
 GitHub so developers can fork and edit it.

 I'd like to hear (but yes, I can only read, this is NG) any thoughts about 
 this idea.


There are already a "List of D projects" pages on the wiki: See the 
"Projects" section in the left nav panel here: 
http://prowiki.org/wiki4d/wiki.cgi  I'm sure new categories could be added 
as needed.

However, I do like the idea have having something that's searchable/sortable 
as you suggest.

I would suggest though, that it be separated into two main parts:

1. Some sort of central database with a documented, publically-accessible 
machine interface, not a human interface. (And for the love of god, not 
XML.)

2. A human-usable frontend.

That way, alternative frontends can be created. We could even create a D 
module (maybe in phobos?) to access the list.

(IMO, that's how most web apps should work. And then backends that deal with 
the same type of data should use standardized interfaces. Hell, that's how 
*real* apps already work (standard file formats, network protocols, etc) - 
that's how computing finally achieved interoperability decades ago, before 
web apps sunk us back into the "no interoperability" dark ages again...But 
now I'm ranting, I'll stop.)



access to X resource, or everything (whatever)" and the backend would send 
back a captcha image. The front end would then show it to the user, and 
relay the answer back to the backend.

Actually, better yet, the backend would be user accounts only, but then 
there'd be a special account for anonymous captcha users. It's be one "anon 
captcha user" account for *each* frontend that wanted to allow captcha. The 
frontend would then use whatever the hell captcha system it wanted and, if 
the user succeeds, the frontend would transparently communicate with the 
backend via its own "anon captcha user" account. And if the captcha system 
used by the frontend turns out to suck, or be bypassable, or isn't even 
being used by the frontend, then the backend could disable or revoke that 
frontend's "anon captcha user" account. The backend could still, optionally, 
provide its own "official" captcha system to any frontends that wanted to 
use it.
Apr 05 2012
next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 5 April 2012 at 21:02:15 UTC, Nick Sabalausky wrote:

 I would suggest though, that it be separated into two main 
 parts:


kill both birds with one web.d.
Apr 05 2012
prev sibling next sibling parent reply Kevin Cox <kevincox.ca gmail.com> writes:
On Apr 5, 2012 5:04 PM, "Nick Sabalausky" <a a.a> wrote

 I would suggest though, that it be separated into two main parts:

 1. Some sort of central database with a documented, publically-accessible
 machine interface, not a human interface. (And for the love of god, not
 XML.)

 2. A human-usable frontend.

 That way, alternative frontends can be created. We could even create a D
 module (maybe in phobos?) to access the list.

 (IMO, that's how most web apps should work. And then backends that deal


with

 the same type of data should use standardized interfaces. Hell, that's how
 *real* apps already work (standard file formats, network protocols, etc) -
 that's how computing finally achieved interoperability decades ago, before
 web apps sunk us back into the "no interoperability" dark ages again...But
 now I'm ranting, I'll stop.)




not


 access to X resource, or everything (whatever)" and the backend would send
 back a captcha image. The front end would then show it to the user, and
 relay the answer back to the backend.

 Actually, better yet, the backend would be user accounts only, but then
 there'd be a special account for anonymous captcha users. It's be one


"anon

 captcha user" account for *each* frontend that wanted to allow captcha.


The

 frontend would then use whatever the hell captcha system it wanted and, if
 the user succeeds, the frontend would transparently communicate with the
 backend via its own "anon captcha user" account. And if the captcha system
 used by the frontend turns out to suck, or be bypassable, or isn't even
 being used by the frontend, then the backend could disable or revoke that
 frontend's "anon captcha user" account. The backend could still,


optionally,

 provide its own "official" captcha system to any frontends that wanted to
 use it


I for one, absolutely love the way you think.  This is a great idea and the
way it should be done.  But, what is wrong with xml when used correctly.
Apr 05 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"Kevin Cox" <kevincox.ca gmail.com> wrote in message 
news:mailman.1385.1333660352.4860.digitalmars-d puremagic.com...

 On Apr 5, 2012 5:04 PM, "Nick Sabalausky" <a a.a> wrote

 [...]


 I for one, absolutely love the way you think.


Really? That's pretty uncommon ;) Most people usually just think I'm nuts!


 But, what is wrong with xml when used correctly.


Well, it's technically usable, but it's overrated: It's overly-verbose and 
over-engineered. It seems simple at a glance, and it really *should* be, and 
*could* have been, but there's a lot of unnecessary complications if you 
really dig into *proper* XML. I mean heck, just look at the spec: I know 
formal standards naturally tend to be big and pedantic, but for something as 
conceptually simple as XML appears to be, it's waaay out of control. Even as 
a big super-formal standard, XML *still* shouldn't be *that* complex.

JSON is somewhat better, and YAML better still. But protocol buffers are 
vastly superior IMO.
Apr 05 2012
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, April 05, 2012 17:48:05 Nick Sabalausky wrote:

 "Kevin Cox" <kevincox.ca gmail.com> wrote in message
 news:mailman.1385.1333660352.4860.digitalmars-d puremagic.com...
 

 On Apr 5, 2012 5:04 PM, "Nick Sabalausky" <a a.a> wrote
 

 [...]


 
 I for one, absolutely love the way you think.


 
 Really? That's pretty uncommon ;) Most people usually just think I'm nuts!


Maybe he just really likes nuts? ;)

- Jonathan M Davis
Apr 05 2012
parent "Nick Sabalausky" <a a.a> writes:
"Jonathan M Davis" <jmdavisProg gmx.com> wrote in message 
news:mailman.1392.1333667746.4860.digitalmars-d puremagic.com...

 On Thursday, April 05, 2012 17:48:05 Nick Sabalausky wrote:

 "Kevin Cox" <kevincox.ca gmail.com> wrote in message
 news:mailman.1385.1333660352.4860.digitalmars-d puremagic.com...


 On Apr 5, 2012 5:04 PM, "Nick Sabalausky" <a a.a> wrote


 [...]


 I for one, absolutely love the way you think.


 Really? That's pretty uncommon ;) Most people usually just think I'm 
 nuts!


 Maybe he just really likes nuts? ;)


Mmmm, pistachios... </homer-voice>
Apr 05 2012
prev sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
06.04.2012 1:04, Nick Sabalausky :

 "Denis Shelomovskij"<verylonglogin.reg gmail.com>  wrote in message
 news:jlkubn$k4f$1 digitalmars.com...

 I think it will be great to have a single place for all D related projects
 so a developer can easily find what is already done
 (for an example of "I didn't now about you project" see, e.g. "Modern COM
 Programming in D" thread), what is *planned* and what great projects have
 already failed (and, maybe, reveal it).

 A draft variant of how I see such page is this with a few projects added
 (note "Planned" tag (yes, empty for now)):
 http://deoma-cmd.ru/d/d-projects-list/

 Usage examples:
 * lets find a D compiler with release or beta maturity:
 http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release
 * lets find not abandoned GUI library for D:
 http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned


 I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into
 GitHub so developers can fork and edit it.

 I'd like to hear (but yes, I can only read, this is NG) any thoughts about
 this idea.


 There are already a "List of D projects" pages on the wiki: See the
 "Projects" section in the left nav panel here:
 http://prowiki.org/wiki4d/wiki.cgi  I'm sure new categories could be added
 as needed.

 However, I do like the idea have having something that's searchable/sortable
 as you suggest.

 I would suggest though, that it be separated into two main parts:

 1. Some sort of central database with a documented, publically-accessible
 machine interface, not a human interface. (And for the love of god, not
 XML.)

 2. A human-usable frontend.

 That way, alternative frontends can be created. We could even create a D
 module (maybe in phobos?) to access the list.

 (IMO, that's how most web apps should work. And then backends that deal with
 the same type of data should use standardized interfaces. Hell, that's how
 *real* apps already work (standard file formats, network protocols, etc) -
 that's how computing finally achieved interoperability decades ago, before
 web apps sunk us back into the "no interoperability" dark ages again...But
 now I'm ranting, I'll stop.)



 access to X resource, or everything (whatever)" and the backend would send
 back a captcha image. The front end would then show it to the user, and
 relay the answer back to the backend.

 Actually, better yet, the backend would be user accounts only, but then
 there'd be a special account for anonymous captcha users. It's be one "anon
 captcha user" account for *each* frontend that wanted to allow captcha. The
 frontend would then use whatever the hell captcha system it wanted and, if
 the user succeeds, the frontend would transparently communicate with the
 backend via its own "anon captcha user" account. And if the captcha system
 used by the frontend turns out to suck, or be bypassable, or isn't even
 being used by the frontend, then the backend could disable or revoke that
 frontend's "anon captcha user" account. The backend could still, optionally,
 provide its own "official" captcha system to any frontends that wanted to
 use it.


Totally agree.

You aren't a nut. I'm a nut. Because I believes HTML should die with all 
present web browsers and JS. And XML because of its frighten overuse. 
And all slow and buggy web apps.

And adobe Flash of course should also die. Damn, they have created 
slow-by-design thing (e.g. see extremely slow YouTube (and other Flash 
based video players) video rendering - now you really need a modern PC 
just to watch a video) and now want to make it faster. With graphical 
acceleration. It results in BSOD-s (yes, I'm on Windows) using web 
browsers. Current systems was too stable. Users was too slack. Hello 
unstable times!

Yes, I like ranting more than you...

Now on business. I have time now and like you suggestions. So, something 
like it, I hope, will be done in this year.

By the way, I have intentionally added repos to projects list - it is 
because such catalogue should automatically monitor projects states (the 
last commit date) when possible.

-- 
 . 
Denis V. Shelomovskij
Apr 06 2012
next sibling parent reply Gour <gour atmarama.net> writes:
On Fri, 06 Apr 2012 12:34:09 +0400
Denis Shelomovskij <verylonglogin.reg gmail.com> wrote:


 Because I believes HTML should die with all present web browsers and
 JS. And XML because of its frighten overuse. And all slow and buggy
 web apps.



 And adobe Flash of course should also die.=20


Interesting...but I just wonder what should remain alive?

Back to the desktop only?


Sincerely,
Gour (not liking XML, JS, Flash...)


--=20
Whenever and wherever there is a decline in religious practice,=20
O descendant of Bharata, and a predominant rise of irreligion =E2=80=94=20
at that time I descend Myself.
Apr 06 2012
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
06.04.2012 12:49, Gour пишет:

 On Fri, 06 Apr 2012 12:34:09 +0400
 Denis Shelomovskij<verylonglogin.reg gmail.com>  wrote:


 Because I believes HTML should die with all present web browsers and
 JS. And XML because of its frighten overuse. And all slow and buggy
 web apps.



 And adobe Flash of course should also die.


 Interesting...but I just wonder what should remain alive?

 Back to the desktop only?


Why? I didn't say anything about TCP/IP - it can remain for a while :)
And desktops now aren't in satisfactory state too. Documents are zipped 
XML-files, IIRC Microsoft will supply JavaScript as a developing language...


-- 
Денис В. Шеломовский
Denis V. Shelomovskij
Apr 06 2012
parent Gour <gour atmarama.net> writes:
On Fri, 06 Apr 2012 13:24:35 +0400
Denis Shelomovskij <verylonglogin.reg gmail.com> wrote:


 Why? I didn't say anything about TCP/IP - it can remain for a while :)


Ahh, OK. ;)


 And desktops now aren't in satisfactory state too. Documents are
 zipped XML-files,=20


Really?

I use AsciiDoc/LaTeX/LyX for documents and those which are in XML
(Gnucash, GNumeric,..) are unzipped: :-)


Sincerely,
Gour

--=20
But a person free from all attachment and aversion and able=20
to control his senses through regulative principles of=20
freedom can obtain the complete mercy of the Lord.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Apr 06 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Apr 06, 2012 at 12:34:09PM +0400, Denis Shelomovskij wrote:
[...]

 You aren't a nut. I'm a nut. Because I believes HTML should die with
 all present web browsers and JS. And XML because of its frighten
 overuse. And all slow and buggy web apps.


+1.

HTML markup is as ugly as a hag, and XML is just... let me just pull up
a quote here:

	"No, John.  I want formats that are actually useful, rather than
	over-featured megaliths that address all questions by piling on
	ridiculous internal links in forms which are hideously
	over-complex." -- Simon St. Laurent on xml-dev



 And adobe Flash of course should also die.


+1. It should have died a DECADE ago. Except that certain interests kept
its decaying worm-infested corpse animating even till today.



 Damn, they have created slow-by-design thing (e.g. see extremely slow
 YouTube (and other Flash based video players) video rendering - now
 you really need a modern PC just to watch a video) and now want to
 make it faster.  With graphical acceleration. It results in BSOD-s
 (yes, I'm on Windows) using web browsers. Current systems was too
 stable. Users was too slack. Hello unstable times!


[...]

Why write stable software when it's much easier to write unstable
software and ship on time? After all, marketing is what really matters
in the end...  </sarcasm>


T

-- 
Государство делает вид, что платит нам
зарплату, а мы делаем вид, что
работаем.
Apr 06 2012
parent reply "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.1417.1333721195.4860.digitalmars-d puremagic.com...

 On Fri, Apr 06, 2012 at 12:34:09PM +0400, Denis Shelomovskij wrote:

 And adobe Flash of course should also die.


 +1. It should have died a DECADE ago. Except that certain interests kept
 its decaying worm-infested corpse animating even till today.


Funny, that's also how I feel about C++. As I've been saying for awhile, a 
decade of near-zero interest in anything but VM languages is what kept it on 
life support. Fortunately, D's quickly becoming the successor that's always 
been needed so C++ will finally be able to RIP.


 Damn, they have created slow-by-design thing (e.g. see extremely slow
 YouTube (and other Flash based video players) video rendering - now
 you really need a modern PC just to watch a video) and now want to
 make it faster.  With graphical acceleration. It results in BSOD-s
 (yes, I'm on Windows) using web browsers. Current systems was too
 stable. Users was too slack. Hello unstable times!


 [...]

 Why write stable software when it's much easier to write unstable
 software and ship on time? After all, marketing is what really matters
 in the end...  </sarcasm>


I can personally vouch for the fact that there is *nothing* productive about 
writing software in Flash. C++ is more productive.
Apr 06 2012
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Apr 06, 2012 at 02:52:38PM -0400, Nick Sabalausky wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.1417.1333721195.4860.digitalmars-d puremagic.com...

 On Fri, Apr 06, 2012 at 12:34:09PM +0400, Denis Shelomovskij wrote:

 And adobe Flash of course should also die.


 +1. It should have died a DECADE ago. Except that certain interests
 kept its decaying worm-infested corpse animating even till today.


 
 Funny, that's also how I feel about C++. As I've been saying for
 awhile, a decade of near-zero interest in anything but VM languages is
 what kept it on life support.


I would've felt the same had I known of a suitable replacement for C++
earlier. But for many years it was the only thing I had (besides pure
hardcore C) that was even remotely close to what my "ideal" language
would be.



 Fortunately, D's quickly becoming the successor that's always been
 needed so C++ will finally be able to RIP.


You have no idea how many times I swore off C++ because of its inherent
stupidities (like hash tables not making the C++ standard before C++11,
among many other sillinesses), only to have to crawl back on my knees
when other alternatives sucked even more.

When I finally discovered D, I was almost blown away by how many things
it got right, in my book. (I had a list of things I wanted in an ideal
language, and D fits so many items on that list it's quite uncanny.)


[...]

 I can personally vouch for the fact that there is *nothing* productive
 about writing software in Flash. C++ is more productive.


[...]


From the very first day I heard about Flash, I've had my doubts. It just


*smelled* wrong. That was before I even had any idea of how it's
implemented. Time has proven that my gut feeling was correct. Flash is a
festering wart that should be blotted from off the face of the internet
for the sake of the future of humanity.


T

-- 
It is of the new things that men tire --- of fashions and proposals and
improvements and change. It is the old things that startle and
intoxicate. It is the old things that are young. -- G.K. Chesterton
Apr 06 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.1438.1333780033.4860.digitalmars-d puremagic.com...

 On Fri, Apr 06, 2012 at 02:52:38PM -0400, Nick Sabalausky wrote:

 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message
 news:mailman.1417.1333721195.4860.digitalmars-d puremagic.com...

 On Fri, Apr 06, 2012 at 12:34:09PM +0400, Denis Shelomovskij wrote:

 And adobe Flash of course should also die.


 +1. It should have died a DECADE ago. Except that certain interests
 kept its decaying worm-infested corpse animating even till today.


 Funny, that's also how I feel about C++. As I've been saying for
 awhile, a decade of near-zero interest in anything but VM languages is
 what kept it on life support.


 I would've felt the same had I known of a suitable replacement for C++
 earlier. But for many years it was the only thing I had (besides pure
 hardcore C) that was even remotely close to what my "ideal" language
 would be.


Getting fed up with C/C++ many years ago prompted me to seek out 
alternatives, which happily led me to D back around the 0.8x or 0.9x days. 
Heh, I remember being mildly disappointed that 0.99 was followed by 0.100 
instead of 1.0 ;)


 Fortunately, D's quickly becoming the successor that's always been
 needed so C++ will finally be able to RIP.


 You have no idea how many times I swore off C++ because of its inherent
 stupidities (like hash tables not making the C++ standard before C++11,
 among many other sillinesses), only to have to crawl back on my knees
 when other alternatives sucked even more.


Yea, the problem IMO is that for at least a full decade eveyone had drunk 
the Sun Kool-Aid and was obsessed with VMs and "interpreted" and all that 
silly nonsence. So outside Digital Mars, *real* language development took a 
ten year hiatus. Only now are there languages like Rust and Issue 9 trying 
to catch up with D.


 I can personally vouch for the fact that there is *nothing* productive
 about writing software in Flash. C++ is more productive.


 [...]

From the very first day I heard about Flash, I've had my doubts. It just
 *smelled* wrong. That was before I even had any idea of how it's
 implemented. Time has proven that my gut feeling was correct. Flash is a
 festering wart that should be blotted from off the face of the internet
 for the sake of the future of humanity.


Heh, you've got better intuition than me then :) Until I actually tried to 
use it, I don't remember having any problems with Flash beyond terrible, 
horrible abuses of it like "Flash Sites", "Flash Intros", and what turned 
out to essentially be the second coming of animated GIFs. The *one* good use 
of it is stupid/goofy/hilarious shit like "And Wheeeee!" and other such 
things that make Newgrounds worthwhile. :)

But, I had *no hint* of the endless mountains of technical problems with it 
until I tried it.
Apr 06 2012
prev sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 6 Apr 2012 14:52:38 -0400
schrieb "Nick Sabalausky" <a a.a>:


 "H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
 news:mailman.1417.1333721195.4860.digitalmars-d puremagic.com...

 On Fri, Apr 06, 2012 at 12:34:09PM +0400, Denis Shelomovskij wrote:

 And adobe Flash of course should also die.


 +1. It should have died a DECADE ago. Except that certain interests kept
 its decaying worm-infested corpse animating even till today.


 
 Funny, that's also how I feel about C++. As I've been saying for awhile, a 
 decade of near-zero interest in anything but VM languages is what kept it on 
 life support. Fortunately, D's quickly becoming the successor that's always 
 been needed so C++ will finally be able to RIP.


Hehe, that might work for your own projects, but realistically look at how many
more people are knowledgeable about C++, companies have big projects written in
C++, desktop environments are written in C++, many tools (internal, commercial,
free) exist for C++, it is a stable target and so on. D is still adding
features that make it interesting for certain audiences: SSE intrinsics for the
Manus of the world (game devs), annotations for GUI/ORM/RPC bindings, short
lambda syntax.
Not every feature of D is subjectively better than what is available in C++,
but I assume most C++ devs miss _something_ that D offers or will offer (in
case of the shared implementation).

-- 
Marco
Apr 08 2012
prev sibling next sibling parent "Jesse Phillips" <Jessekphillips+D gmail.com> writes:
On Thursday, 5 April 2012 at 20:12:39 UTC, Denis Shelomovskij 
wrote:

 I think it will be great to have a single place for all D 
 related projects so a developer can easily find what is already 
 done
 (for an example of "I didn't now about you project" see, e.g. 
 "Modern COM Programming in D" thread), what is *planned* and 
 what great projects have already failed (and, maybe, reveal it).

 A draft variant of how I see such page is this with a few 
 projects added (note "Planned" tag (yes, empty for now)):
 http://deoma-cmd.ru/d/d-projects-list/


Well, lists have been attempted (Dsource is a good example), but 
you are obviously looking at something with good filtering. This 
is good.

There is also work for a package management system Orbit, this 
likely needs similar functionality.

Namely, some one needs to build this stuff, it isn't that they 
aren't wanted.
Apr 05 2012
prev sibling next sibling parent reply Brad Roberts <braddr slice-2.puremagic.com> writes:
I think this thread misses the key problem with anything like this.. how 
to curate the list.  How will it be kept current?  What's the definition 
of abandoned?  Etc, etc.  The presentation and storage formats are almost 
irrelevant as they're the easiest part of the problem.

On Fri, 6 Apr 2012, Denis Shelomovskij wrote:


 Date: Fri, 06 Apr 2012 00:13:04 +0400
 From: Denis Shelomovskij <verylonglogin.reg gmail.com>
 Reply-To: digitalmars.D <digitalmars-d puremagic.com>
 To: digitalmars-d puremagic.com
 Newsgroups: digitalmars.D
 Subject: D projects list
 
 I think it will be great to have a single place for all D related projects so
 a developer can easily find what is already done
 (for an example of "I didn't now about you project" see, e.g. "Modern COM
 Programming in D" thread), what is *planned* and what great projects have
 already failed (and, maybe, reveal it).
 
 A draft variant of how I see such page is this with a few projects added (note
 "Planned" tag (yes, empty for now)):
 http://deoma-cmd.ru/d/d-projects-list/
 
 Usage examples:
 * lets find a D compiler with release or beta maturity:
 http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release
 * lets find not abandoned GUI library for D:
 http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned
 
 
 I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into GitHub
 so developers can fork and edit it.
 
 I'd like to hear (but yes, I can only read, this is NG) any thoughts about
 this idea.
 
 -- 
 ????? ?. ???????????
 Denis V. Shelomovskij
Apr 05 2012
parent "Nick Sabalausky" <a a.a> writes:
"Brad Roberts" <braddr slice-2.puremagic.com> wrote in message 
news:alpine.DEB.2.00.1204051616190.5012 slice-2.puremagic.com...

I think this thread misses the key problem with anything like this.. how
 to curate the list.  How will it be kept current?  What's the definition
 of abandoned?  Etc, etc.  The presentation and storage formats are almost
 irrelevant as they're the easiest part of the problem.


That would indeed be a key aspect. I've been thinking a combination of:

1. Wiki-like editing

and

2. Automatic mining from things like github/bitbucket/dsource and a standard 
metadata protocol/format (maybe tied into orbit?) that project authors can 
optionally choose to expose.

Actually, having this tied in with orbit somehow would probably be a *very* 
good idea.
Apr 05 2012
prev sibling parent Lutger Blijdestijn <lutger.blijdestijn gmail.com> writes:
Denis Shelomovskij wrote:


 I think it will be great to have a single place for all D related
 projects so a developer can easily find what is already done
 (for an example of "I didn't now about you project" see, e.g. "Modern
 COM Programming in D" thread), what is *planned* and what great projects
 have already failed (and, maybe, reveal it).
 
 A draft variant of how I see such page is this with a few projects added
 (note "Planned" tag (yes, empty for now)):
 http://deoma-cmd.ru/d/d-projects-list/
 
 Usage examples:
 * lets find a D compiler with release or beta maturity:
 http://deoma-cmd.ru/d/d-projects-list/?q=Compiler+Beta+Release
 * lets find not abandoned GUI library for D:
 http://deoma-cmd.ru/d/d-projects-list/?q=GUI+!Abandoned
 
 
 I'd like to put http://deoma-cmd.ru/d/d-projects-list/projects.js into
 GitHub so developers can fork and edit it.
 
 I'd like to hear (but yes, I can only read, this is NG) any thoughts
 about this idea.
 


It's a great idea. I used djangopackages.com a lot when I was doing a django 
project, something like this would be awesome for D. You might like to check 
it out, it has some nice features.

So, apparently djangopackages.com is built with opencomparison, which is an 
open source project in itself: http://opencomparison.org/
Apr 06 2012