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.) Captcha and/or user management for write-access would be built into #1, not #2. If captcha, then a frontend would tell the backend "I want to write 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 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.) Captcha and/or user management for write-access would be built into #1, not #2. If captcha, then a frontend would tell the backend "I want to write 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
parent 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
prev sibling next 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 "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
prev 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

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 next sibling parent reply Kevin Cox <kevincox.ca gmail.com> writes:
--0015175cd814b8b37d04bcf4fc56
Content-Type: text/plain; charset=UTF-8

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

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

 Captcha and/or user management for write-access would be built into #1,

 #2. If captcha, then a frontend would tell the backend "I want to write
 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

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

 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,

 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. --0015175cd814b8b37d04bcf4fc56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <p><br> On Apr 5, 2012 5:04 PM, &quot;Nick Sabalausky&quot; &lt;a a.a&gt; wrote<br> &gt; I would suggest though, that it be separated into two main parts:<br> &gt;<br> &gt; 1. Some sort of central database with a documented, publically-accessi= ble<br> &gt; machine interface, not a human interface. (And for the love of god, no= t<br> &gt; XML.)<br> &gt;<br> &gt; 2. A human-usable frontend.<br> &gt;<br> &gt; That way, alternative frontends can be created. We could even create a= D<br> &gt; module (maybe in phobos?) to access the list.<br> &gt;<br> &gt; (IMO, that&#39;s how most web apps should work. And then backends that= deal with<br> &gt; the same type of data should use standardized interfaces. Hell, that&#= 39;s how<br> &gt; *real* apps already work (standard file formats, network protocols, et= c) -<br> &gt; that&#39;s how computing finally achieved interoperability decades ago= , before<br> &gt; web apps sunk us back into the &quot;no interoperability&quot; dark ag= es again...But<br> &gt; now I&#39;m ranting, I&#39;ll stop.)<br> &gt;<br> &gt; Captcha and/or user management for write-access would be built into #1= , not<br> &gt; #2. If captcha, then a frontend would tell the backend &quot;I want to= write<br> &gt; access to X resource, or everything (whatever)&quot; and the backend w= ould send<br> &gt; back a captcha image. The front end would then show it to the user, an= d<br> &gt; relay the answer back to the backend.<br> &gt;<br> &gt; Actually, better yet, the backend would be user accounts only, but the= n<br> &gt; there&#39;d be a special account for anonymous captcha users. It&#39;s= be one &quot;anon<br> &gt; captcha user&quot; account for *each* frontend that wanted to allow ca= ptcha. The<br> &gt; frontend would then use whatever the hell captcha system it wanted and= , if<br> &gt; the user succeeds, the frontend would transparently communicate with t= he<br> &gt; backend via its own &quot;anon captcha user&quot; account. And if the = captcha system<br> &gt; used by the frontend turns out to suck, or be bypassable, or isn&#39;t= even<br> &gt; being used by the frontend, then the backend could disable or revoke t= hat<br> &gt; frontend&#39;s &quot;anon captcha user&quot; account. The backend coul= d still, optionally,<br> &gt; provide its own &quot;official&quot; captcha system to any frontends t= hat wanted to<br> &gt; use it</p> <p>I for one, absolutely love the way you think.=C2=A0 This is a great idea= and the way it should be done.=C2=A0 But, what is wrong with xml when used= correctly.<br> </p> --0015175cd814b8b37d04bcf4fc56--
Apr 05 2012
parent "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
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 next sibling 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 next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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
prev sibling next sibling parent Gour <gour atmarama.net> writes:
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

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