View mode: basic / threaded / horizontal-split · Log in · Help
April 05, 2012
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
April 05, 2012
Re: D projects list
> 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.
April 05, 2012
Re: D projects list
"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.
April 05, 2012
Re: D projects list
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.
April 05, 2012
Re: D projects list
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.)
>
> 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

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.
April 05, 2012
Re: D projects list
"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.
April 05, 2012
Re: D projects list
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.
April 05, 2012
Re: D projects list
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
>
April 05, 2012
Re: D projects list
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
April 05, 2012
Re: D projects list
"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>
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home