www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is dsource .org completely deserted?

reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I was browsing dsource.org for some libraries, that I need and every single
project, that I looked at was either completely abandoned or stuck with the
ancient D1.
Is there at least one sane project in there or is dsource.org an ancient
fossil for museum display?
Sorry for my frustration.

-- 
Bye,
Gor Gyolchanyan.
May 14 2012
next sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 14 May 2012 10:06:12 -0400, Gor Gyolchanyan  
<gor.f.gyolchanyan gmail.com> wrote:


 I was browsing dsource.org for some libraries, that I need and every  
 single
 project, that I looked at was either completely abandoned or stuck with  
 the
 ancient D1.
 Is there at least one sane project in there or is dsource.org an ancient
 fossil for museum display?
 Sorry for my frustration.


There are several.  The problem is finding them amongst all the  
tumbleweeds.

I plan to move my lib (dcollections) to github as soon as I have some  
spare time that I wouldn't want to spend doing something else (i.e. low on  
the priority list).

-Steve
May 14 2012
next sibling parent "Kagamin" <spam here.lot> writes:
 ancient D1.




druntime has assembler code, assembler is more ancient than D1, 
druntime belongs to D2, so D2 is more ancient than D1. Whoops! 
It's a time paradox!
May 14 2012
prev sibling parent reply "Kapps" <opantm2+spam gmail.com> writes:
It would be nice to make a replacement to dsource. There's a fair 
few problems with it. For one, people prefer hosting their source 
on Github or Bitbucket or such, it's silly to try and get people 
to use your own source control hosting instead of just pointing 
to one of those. Another would be to integrate package manager 
stuff when one is available. And, most importantly, to prioritize 
active projects and focus out dead projects automatically.

I was thinking of writing one, but not sure if it's really worth 
it (and have a couple projects/libraries that need to be written 
first).
May 14 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Kapps" <opantm2+spam gmail.com> wrote in message 
news:gvuqhcqczjqmdtpsagrj forum.dlang.org...

 It would be nice to make a replacement to dsource. There's a fair few 
 problems with it. For one, people prefer hosting their source on Github or 
 Bitbucket or such, it's silly to try and get people to use your own source 
 control hosting instead of just pointing to one of those.


I firmly believe that GitHub/BitBucket/etc-style features need to be 
standard *protocols*, not features bundled inseparably to project hosting. 
What the hell is this, 1980 all over again where data is routinely tied 
inseparably to the software it originated from?

It makes *no* sense for GitHub/BitBucket to be designed so that:

1. Forking/Pull requests/etc are all isolated from other project hosting 
providers (It's *DISTRIBUTED* fucking version control, for christsakes!), 
and

2. Interfaces [very, very VERY sloooow and half-broken ones] are tied to the 
project hosting site/software.

It's like that twitface shit all over again (ie, all that "walled-off 
sub-internets" bullshit), or those god-awful "web photo-viewer" programs, 
but with programmers - exactly the people who *should know better*. This is 
2012, there's *no* excuse for software design blunders that were already 
going out of date 30 fucking years ago.

Of course, such anachronisms will never be reverted so long as the "cell and 
internet generation" is still around...


 Another would be to integrate package manager stuff when one is available. 
 And, most importantly, to prioritize active projects and focus out dead 
 projects automatically.


I agree, such things would be nice. There also needs to be proper use of 
HTTPS for logins/sessions, and automated creation of new projects.
May 14 2012
next sibling parent reply "foobar" <foo bar.com> writes:
On Tuesday, 15 May 2012 at 02:36:25 UTC, Nick Sabalausky wrote:

 "Kapps" <opantm2+spam gmail.com> wrote in message
 news:gvuqhcqczjqmdtpsagrj forum.dlang.org...

 It would be nice to make a replacement to dsource. There's a 
 fair few problems with it. For one, people prefer hosting 
 their source on Github or Bitbucket or such, it's silly to try 
 and get people to use your own source control hosting instead 
 of just pointing to one of those.


 I firmly believe that GitHub/BitBucket/etc-style features need 
 to be
 standard *protocols*, not features bundled inseparably to 
 project hosting.
 What the hell is this, 1980 all over again where data is 
 routinely tied
 inseparably to the software it originated from?

 It makes *no* sense for GitHub/BitBucket to be designed so that:

 1. Forking/Pull requests/etc are all isolated from other 
 project hosting
 providers (It's *DISTRIBUTED* fucking version control, for 
 christsakes!),
 and

 2. Interfaces [very, very VERY sloooow and half-broken ones] 
 are tied to the
 project hosting site/software.

 It's like that twitface shit all over again (ie, all that 
 "walled-off
 sub-internets" bullshit), or those god-awful "web photo-viewer" 
 programs,
 but with programmers - exactly the people who *should know 
 better*. This is
 2012, there's *no* excuse for software design blunders that 
 were already
 going out of date 30 fucking years ago.

 Of course, such anachronisms will never be reverted so long as 
 the "cell and
 internet generation" is still around...


 Another would be to integrate package manager stuff when one 
 is available. And, most importantly, to prioritize active 
 projects and focus out dead projects automatically.


 I agree, such things would be nice. There also needs to be 
 proper use of
 HTTPS for logins/sessions, and automated creation of new 
 projects.


There *is* such a protocol - it's called Git.
Sure it doesn't support pull requests but that's the base for
GitHub's business model - they make money by offering useful
extensions on top of their hosting plans. There is no blunder
here, it's all very deliberate for the purpose of making money.
There's no point on ranting about that.

Git is open source - anyone can contribute and implement these
missing features. Besides, no ones forcing you to use GitHub, you
can easily self-host directly with the bundled daemon or use
additional open-source software such as Gerrit that also provides
the same features as GitHub.

This is akin to ranting about commercials on the radio while
listening to music. Well, they do need to make money in order to
provide free (as in beer) music. If someone doesn't like it he's
free to arrange the music himself on an MP3 or a CD.
May 15 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"foobar" <foo bar.com> wrote in message 
news:cuucmsymdqnsrurlkfpg forum.dlang.org...

 On Tuesday, 15 May 2012 at 02:36:25 UTC, Nick Sabalausky wrote:

 "Kapps" <opantm2+spam gmail.com> wrote in message
 news:gvuqhcqczjqmdtpsagrj forum.dlang.org...

 It would be nice to make a replacement to dsource. There's a fair few 
 problems with it. For one, people prefer hosting their source on Github 
 or Bitbucket or such, it's silly to try and get people to use your own 
 source control hosting instead of just pointing to one of those.


 I firmly believe that GitHub/BitBucket/etc-style features need to be
 standard *protocols*, not features bundled inseparably to project 
 hosting.
 What the hell is this, 1980 all over again where data is routinely tied
 inseparably to the software it originated from?

 It makes *no* sense for GitHub/BitBucket to be designed so that:

 1. Forking/Pull requests/etc are all isolated from other project hosting
 providers (It's *DISTRIBUTED* fucking version control, for christsakes!),
 and

 2. Interfaces [very, very VERY sloooow and half-broken ones] are tied to 
 the
 project hosting site/software.

 It's like that twitface shit all over again (ie, all that "walled-off
 sub-internets" bullshit), or those god-awful "web photo-viewer" programs,
 but with programmers - exactly the people who *should know better*. This 
 is
 2012, there's *no* excuse for software design blunders that were already
 going out of date 30 fucking years ago.

 Of course, such anachronisms will never be reverted so long as the "cell 
 and
 internet generation" is still around...


 There *is* such a protocol - it's called Git.


Right, I agree, but these days, Git (or Hg) is essentially only a half-VCS 
without such things. And Git and Hg don't have such things.


 Sure it doesn't support pull requests but that's the base for
 GitHub's business model - they make money by offering useful
 extensions on top of their hosting plans. There is no blunder
 here, it's all very deliberate for the purpose of making money.
 There's no point on ranting about that.


I'm well aware that it's deliberate, but it's still anti-competetive, 
asinine and anachronistic. And it's not as if the whole hosting thing isn't 
worth anything. That is, after all, what they *do*.

People have this bizarre idea that the pursuit of $$$ automatically excuses 
anything and everything. "WTF, that's terrible!" "No, it's ok: They're 
making $$$ off of it!" "Oh, ok then! If they're making $$$!"

This is why OSS software will always be better (on average) than commercial: 
No managers to fuck things up.
May 15 2012
next sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> wrote in message 
news:jottlr$stf$1 digitalmars.com...

 "foobar" <foo bar.com> wrote in message 
 news:cuucmsymdqnsrurlkfpg forum.dlang.org...


 Sure it doesn't support pull requests but that's the base for
 GitHub's business model - they make money by offering useful
 extensions on top of their hosting plans. There is no blunder
 here, it's all very deliberate for the purpose of making money.
 There's no point on ranting about that.


 I'm well aware that it's deliberate, but it's still anti-competetive, 
 asinine and anachronistic. And it's not as if the whole hosting thing 
 isn't worth anything. That is, after all, what they *do*.


Wait, what the hell am I thinking? Even if is deliberate, and even if 
"$$$!!" did excuse everything, it *still* doesn't even make a shred of sense 
anyway: They *already* offer a free API which can be used for any of the 
different forms of interop I was suggesting. So they're *already* ok with 
all of what I suggested. Locking out interop is *not* part of their business 
model. They've just implemented that interop in a colossally dumb way, 
that's all.
May 15 2012
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 15 May 2012 11:43:42 -0400, Nick Sabalausky  
<SeeWebsiteToContactMe semitwist.com> wrote:


 I'm well aware that it's deliberate, but it's still anti-competetive,
 asinine and anachronistic. And it's not as if the whole hosting thing  
 isn't
 worth anything. That is, after all, what they *do*.


Wait, can't you just git clone the data into whatever "github-like"  
service you wish?  I mean, yeah, you cannot do pull requests to Phobos  
unless you have your code in github, but that could just be a simple  
intermediate step.

I recently switched all my private repositories from github to bitbucket  
(free unlimited private repositories vs. $12/mo for 10 private  
repositories), and bitbucket actually has a page to suck the code from  
github *directly*  I didn't even have to do the  
git-clone-locally-then-push-to-other-remote dance.  Probably the easiest  
service change of anything in my entire life!  It took all of 5 minutes.

So if you like bitbucket, use that, if you like github use that, if you  
like something else, use that.  But if you want to contribute to a  
project, you have to use whatever that project uses.  I think that's both  
very reasonable and very flexible.

-Steve
May 16 2012
next sibling parent Geoffrey Biggs <geoffrey.biggs aist.go.jp> writes:
On May 16, 2012, at 9:38 PM, Steven Schveighoffer wrote:


 On Tue, 15 May 2012 11:43:42 -0400, Nick Sabalausky =


<SeeWebsiteToContactMe semitwist.com> wrote:

=20

 I'm well aware that it's deliberate, but it's still anti-competetive,
 asinine and anachronistic. And it's not as if the whole hosting thing =




isn't

 worth anything. That is, after all, what they *do*.


=20
 Wait, can't you just git clone the data into whatever "github-like" =


service you wish?  I mean, yeah, you cannot do pull requests to Phobos =
unless you have your code in github, but that could just be a simple =
intermediate step.

This is not entirely correct. You can do pull requests. You just can't =
do them through the github interface, which aims to make them easier and =
smoother. A pull request is nothing more than a request to execute a =
common git command with a URL pointing to a git repository (which can be =
hosted anywhere). The github interface just wraps this command and =
directs it to the repository stored on the server rather than one on =
your computer (as well as adding things like tracker integration, etc).

=46rom the git documentation:

Often, "please pull" messages on the mailing list just provide two =
pieces of information: a repo URL and a branch name; this is designed to =
be easily cut&pasted at the end of a git fetch command line:

    Linus, please pull from

	git://git..../proj.git master

    to get the following updates...

becomes:

    $ git pull git://git..../proj.git master

(See http://git-scm.com/docs/git-tag)

Projects that don't operate around sites like github rely on messages to =
a mailing list asking the integrator to pull from some branch of some =
repository. Although I'm sure the Linux kernel works like this, I =
haven't seen it, but I have seen the same process used effectively by =
Erlang - and they even use github for their repositories.

If Phobos is *requiring* pull requests to be done through the github =
interface, well, I think that's pretty silly and a good way to =
discourage some contributions, but it's not my project and perhaps they =
like the interface too much to work any other way.


Geoff=
May 16 2012
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 16/05/12 15:09, Geoffrey Biggs wrote:

 Projects that don't operate around sites like github rely on messages to a
mailing list asking the integrator to pull from some branch of some repository.
Although I'm sure the Linux kernel works like this, I haven't seen it, but I
have seen the same process used effectively by Erlang - and they even use
github for their repositories.


You can also generate patches and attach to email, so discussion/review of the 
patch can happen on the list.  IIRC the Bazaar project does this, and they even 
have some kind of automated vote-tracking system in place that lets authorized 
individuals assent, dissent or abstain from merging a patch into the trunk.
May 16 2012
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 15/05/12 04:16, Nick Sabalausky wrote:

 I firmly believe that GitHub/BitBucket/etc-style features need to be
 standard *protocols*, not features bundled inseparably to project hosting.
 What the hell is this, 1980 all over again where data is routinely tied
 inseparably to the software it originated from?


Whatever your opinion of GitHub etc. (and I agree that it makes sense for there 
to be a well-defined set of interaction protocols), the key point is surely
that 
dedicated code-hosting and collaboration platforms can provide a much better 
service than individual projects' self-hosted repositories.

Where dsource.org is concerned probably the best thing to do is make it a 
carefully-maintained directory of active projects, without hosting, issue 
tracking, etc. included (of course, existing repos should be kept in place to 
avoid data loss).  It's unlikely to be much pain for the projects, who can be 
given plenty of notice to migrate.

As it stands it makes D look quite dead and derelict, when that's not the case 
at all.
May 16 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> wrote in message 
news:mailman.840.1337179907.24740.digitalmars-d puremagic.com...

 On 15/05/12 04:16, Nick Sabalausky wrote:

 I firmly believe that GitHub/BitBucket/etc-style features need to be
 standard *protocols*, not features bundled inseparably to project 
 hosting.
 What the hell is this, 1980 all over again where data is routinely tied
 inseparably to the software it originated from?


 Whatever your opinion of GitHub etc. (and I agree that it makes sense for 
 there to be a well-defined set of interaction protocols), the key point is 
 surely that dedicated code-hosting and collaboration platforms can provide 
 a much better service than individual projects' self-hosted repositories.


My main point is that those features (fork/pull request/issue tracking, etc) 
should be decoupled from hosting so that, for example, self-hosted repos 
would *not* provide inferior service, in fact they woudn't have to provide 
some stupid bundled interface at all: As a *user* (NOT as a project 
maintainer), you would just use *your own* choice of github, bitbucket, 
Tortoise*, or whatever the fuck YOU wanted to use, to access whatever the 
fuck repo you wanted to access, wherever the hell said repo happens to live. 
The whole point is that interface and hosting have no business being coupled 
as they are now. Tying repo and interface together makes absolutely no sense 
whatsoever.

What we have now is *no* different from those god-awful, absolutely 
rediculous, image sharing "tools" like Kodak Photo Viewer or Adobe 
Lightroom's Flash exporter. (I *hate* when people try to send me pictures 
with those reprehensible things.) Or Flash-based videos: Why the hell is it 
so incredibly unacceptable for people to use THEIR OWN fucking choice of 
video player? In any case, github/bitbucket/etc are exactly the same thing, 
just with code instead of picutres or videos (and made by and for people who 
are smart enough that they *should* know better).


 As it stands it makes D look quite dead and derelict, when that's not the 
 case at all.


Agreed. DSource could use some improvements WRT finding active/inactive 
projects.
May 16 2012
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 17/05/12 01:45, Nick Sabalausky wrote:

 My main point is that those features (fork/pull request/issue tracking, etc)
 should be decoupled from hosting so that, for example, self-hosted repos
 would *not* provide inferior service, in fact they woudn't have to provide
 some stupid bundled interface at all: As a *user* (NOT as a project
 maintainer), you would just use *your own* choice of github, bitbucket,
 Tortoise*, or whatever the fuck YOU wanted to use, to access whatever the
 fuck repo you wanted to access, wherever the hell said repo happens to live.
 The whole point is that interface and hosting have no business being coupled
 as they are now. Tying repo and interface together makes absolutely no sense
 whatsoever.


I do agree with you.  However ... to really get that working our only choice is 
to take time and effort to contribute to one of the open source code hosting 
solutions.  I'm familiar with only two decent ones -- Launchpad (which is tied 
to bzr) and Gitorious (which seems to be not very well maintained these days, 
though I haven't looked too recently, and which IIRC doesn't include issue 
tracking etc.).

It would be great if we could have code-hosting equivalents of WordPress, 
Drupal, Joomla! etc., but for now there's nothing that really cuts the mustard 
compared to the dedicated services out there.

Bear in mind, though, that even if you _did_ have the stuff available for 
self-hosting, in many cases it would still make sense to host with a dedicated 
service.
May 17 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Joseph Rushton Wakeling" <joseph.wakeling webdrake.net> wrote in message 
news:mailman.886.1337255711.24740.digitalmars-d puremagic.com...

 On 17/05/12 01:45, Nick Sabalausky wrote:

 My main point is that those features (fork/pull request/issue tracking, 
 etc)
 should be decoupled from hosting so that, for example, self-hosted repos
 would *not* provide inferior service, in fact they woudn't have to 
 provide
 some stupid bundled interface at all: As a *user* (NOT as a project
 maintainer), you would just use *your own* choice of github, bitbucket,
 Tortoise*, or whatever the fuck YOU wanted to use, to access whatever the
 fuck repo you wanted to access, wherever the hell said repo happens to 
 live.
 The whole point is that interface and hosting have no business being 
 coupled
 as they are now. Tying repo and interface together makes absolutely no 
 sense
 whatsoever.


 I do agree with you.  However ... to really get that working our only 
 choice is to take time and effort to contribute to one of the open source 
 code hosting solutions.  I'm familiar with only two decent ones --  
 Launchpad (which is tied to bzr) and Gitorious (which seems to be not very 
 well maintained these days, though I haven't looked too recently, and 
 which IIRC doesn't include issue tracking etc.).

 It would be great if we could have code-hosting equivalents of WordPress, 
 Drupal, Joomla! etc., but for now there's nothing that really cuts the 
 mustard compared to the dedicated services out there.


That's not quite what I mean (actually, AIUI, bitbucket's software can 
already be installed on your own server and used like WordPress. It just 
won't know anything about any projects hosted on "http://bitbucket.org" or 
anywhere else). What I'm suggesting is no different from, say, image files:

1. A repo should just be a repo. It's just data. No special interface 
attached other than just git or hg or whatever. It's *just* a repo. This is 
like a "png" file.

2. The protocols (ie. either git/hg/etc or better yet a standard extension 
that handles both git and hg) would then incorporate the things that 
github/bitbucket have proven to be commonly useful and franky *expected*, 
like fork-tracking, pull requests, issue tracking, etc. I'd imagine this 
would likely involve special extentions to the git/hg/etc repo format. But 
no matter how this is actually implemented, this would be like "libpng" 
(although it would likely have a standard cmd line and web-based interfaces, 
too - which wouldn't make sence for libpng, but it would be essential here).


form (like Tortoise*), or in shitty-web-app form (GitHub mark 2, BitBucket 
mark 2, etc). These would *not* be like WordPress/etc, because WordPress/etc 
are packaged together with data. Instead, these would be like Photoshop, 
GIMP, or whatever crappy web-app equivalent people might like.

Have you ever heard of, or even read, "Hugi Magazine"? ( 
http://www.hugi.scene.org/main.php?page=hugi  ). It has interesting content, 
but the format is absolutely moronic: Instead of coming in PDF or HTML or 
even DOC or dead-tree, it comes in *EXE* form. That's right. So you can't 
use your choice of viewer, and you can't even read it on another device 
without them actually *porting* the fucking issue.

GitHub/BitBucket/etc (along with 90% of "Web 2.0" and "cloud"), are very, 
very much like Hugi. And yet somehow, people seem to think it's a fantastic 
*advancement*. Bleh.


 Bear in mind, though, that even if you _did_ have the stuff available for 
 self-hosting, in many cases it would still make sense to host with a 
 dedicated service.


Totally agree. The point here isn't to stop or obsolete hosting services, 
it's just to properly decouple "data" from "software". Some of the 
consequences of that:

A. Coder Joe finds project FooBar. He browses the source, browses through 
the *forks* (*even* forks hosted *elsewhere*), makes his own fork (no matter 
where or how he chooses to host it), and creates/browses pull-requests and 
issue-tickets through the interface of *his own* choosing, not some 
interface chosen by FooBar's maintainer.

B. FooBar's maintainer doesn't even have to provide *any* special "WordPress 
equivalent" interface or anything, no matter *how* or where he chooses to 
host FooBar's official repo. He just exposes the repo (with the standard 
extensions to allow all this stuff) either on his own server, or on any 
hosting site, and that's it: He's done, and his project automatically has 
all the GitHub/BitBucket-like benefits everyone has come to expect, and all 
regardless of how or where he chooses to host FooBar. And his users can use 
whatever interface *they* prefer. *Everyone* wins. *Everyone* gets their 
*own* way.

C. Self-hosting becomes a perfectly reasonable option, unlike now.

D. External hosting, like with GitHub/BitBucket, *continues* to be a 
perfectly reasonable option.
May 17 2012
next sibling parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> wrote in message 
news:jp3ocp$2e1c$1 digitalmars.com...

 2. The protocols (ie. either git/hg/etc or better yet a standard extension 
 that handles both git and hg) would then incorporate the things that 
 github/bitbucket have proven to be commonly useful and franky *expected*, 
 like fork-tracking, pull requests, issue tracking, etc. I'd imagine this 
 would likely involve special extentions to the git/hg/etc repo format. But 
 no matter how this is actually implemented, this would be like "libpng" 
 (although it would likely have a standard cmd line and web-based 
 interfaces, too - which wouldn't make sence for libpng, but it would be 
 essential here).


Sorry, what I meant there was "it would likely have standard cmd line and 
web ***API*** interfaces". Ie, not actual web pages, but a web service 
protocol, like a REST API, or SOAP (minus the XML, preferably) or whatever 
the hell the popular equivalent is these days. ;)
May 17 2012
parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> wrote in message 
news:jp3oq2$2esa$1 digitalmars.com...

 "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> wrote in message 
 news:jp3ocp$2e1c$1 digitalmars.com...

 2. The protocols (ie. either git/hg/etc or better yet a standard 
 extension that handles both git and hg) would then incorporate the things 
 that github/bitbucket have proven to be commonly useful and franky 
 *expected*, like fork-tracking, pull requests, issue tracking, etc. I'd 
 imagine this would likely involve special extentions to the git/hg/etc 
 repo format. But no matter how this is actually implemented, this would 
 be like "libpng" (although it would likely have a standard cmd line and 
 web-based interfaces, too - which wouldn't make sence for libpng, but it 
 would be essential here).


 Sorry, what I meant there was "it would likely have standard cmd line and 
 web ***API*** interfaces". Ie, not actual web pages, but a web service 
 protocol, like a REST API, or SOAP (minus the XML, preferably) or whatever 
 the hell the popular equivalent is these days. ;)


Or hell, doesn't even have to be web, could be SCGI or a new thing or 
whatever, just some standardized network protocol.
May 17 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, May 17, 2012 at 04:51:04PM -0400, Nick Sabalausky wrote:
[...]

 Have you ever heard of, or even read, "Hugi Magazine"? (
 http://www.hugi.scene.org/main.php?page=hugi  ). It has interesting
 content, but the format is absolutely moronic: Instead of coming in
 PDF or HTML or even DOC or dead-tree, it comes in *EXE* form. That's
 right. So you can't use your choice of viewer, and you can't even read
 it on another device without them actually *porting* the fucking
 issue.
 
 GitHub/BitBucket/etc (along with 90% of "Web 2.0" and "cloud"), are
 very, very much like Hugi. And yet somehow, people seem to think it's
 a fantastic *advancement*. Bleh.


[...]

Is it really _that_ bad? GitHub does support directly running git
pull/push, clone, etc. just by specifying the URL.  If you want to send
somebody a pull request, you could just put your repo on any git hosting
service (or run your own), and email the relevant people the URL to your
repo. Then they can just run git pull $url and that's that.

Though you do have a point that a standard protocol for pull requests,
issue tracking, etc., would be nice. If git was extended to have, say,
discussion tracking for pull requests, then people can actually discuss
your requests in a hosting-independent way, and you can, e.g., run 'git
pull discuss --client=mutt' to read discussions via Mutt or whatever
your favorite non-dumb mail/news reader is. But this is more a
limitation of the current git protocol than the fault of any of the
present hosting systems. You could, y'know, send pull requests to the
upstream git source to rectify this situation... ;-)


T

-- 
Creativity is not an excuse for sloppiness.
May 17 2012
parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.902.1337292243.24740.digitalmars-d puremagic.com...

 On Thu, May 17, 2012 at 04:51:04PM -0400, Nick Sabalausky wrote:
 [...]

 Have you ever heard of, or even read, "Hugi Magazine"? (
 http://www.hugi.scene.org/main.php?page=hugi  ). It has interesting
 content, but the format is absolutely moronic: Instead of coming in
 PDF or HTML or even DOC or dead-tree, it comes in *EXE* form. That's
 right. So you can't use your choice of viewer, and you can't even read
 it on another device without them actually *porting* the fucking
 issue.

 GitHub/BitBucket/etc (along with 90% of "Web 2.0" and "cloud"), are
 very, very much like Hugi. And yet somehow, people seem to think it's
 a fantastic *advancement*. Bleh.


 [...]

 Is it really _that_ bad? GitHub does support directly running git
 pull/push, clone, etc. just by specifying the URL.  If you want to send
 somebody a pull request, you could just put your repo on any git hosting
 service (or run your own), and email the relevant people the URL to your
 repo. Then they can just run git pull $url and that's that.


Well no, it's not *that* bad (that's why I said "very much like" rather then 
"the same as"), but it's along the same general lines - just not quite as 
far.


 Though you do have a point that a standard protocol for pull requests,
 issue tracking, etc., would be nice. If git was extended to have, say,
 discussion tracking for pull requests, then people can actually discuss
 your requests in a hosting-independent way, and you can, e.g., run 'git
 pull discuss --client=mutt' to read discussions via Mutt or whatever
 your favorite non-dumb mail/news reader is. But this is more a
 limitation of the current git protocol than the fault of any of the
 present hosting systems.


Right, exactly.


 You could, y'know, send pull requests to the
 upstream git source to rectify this situation... ;-)


That means I'd have to actually find the time to write them ;)  (and deal 
with C/Pyton/etc... Yuck!)

Thing is though, these features have *already* been created, *multiple* 
times, by multiple groups of people. And yet, every single time, it was done 
basically the wrong way. That bugs me. ;)

But you're right, the solution is for someone to actually *make* the "right" 
solution. My main point for now though, was just to at least get across the 
idea of what the "right" way even *is* and why it's better. It's only a 
small first step, but a necessary first step.


 -- 
 Creativity is not an excuse for sloppiness.


Heh :)
May 17 2012
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/18/12, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 Is it really that bad?


Speaking of Github, it's really annoying how many projects get listed
here even though they have nothing to do with D:
https://github.com/languages/D/created

I don't understand how Github manages to pick up so many java/cpp
codebases and mark them as D codebases.
May 17 2012
parent reply "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
news:mailman.904.1337305802.24740.digitalmars-d puremagic.com...

 On 5/18/12, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 Is it really that bad?


 Speaking of Github, it's really annoying how many projects get listed
 here even though they have nothing to do with D:
 https://github.com/languages/D/created

 I don't understand how Github manages to pick up so many java/cpp
 codebases and mark them as D codebases.


I wonder if it's trying to detect D files with '*d' instead of '*.d'  Or, 
maybe an accidental regex for '.d$' instead of '\.d$'  The [few] projects in 
there that I looked at all had either a "README.md" or at least some 
filename that ended with a "d".
May 17 2012
parent Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 17 May 2012 22:10:23 -0400
schrieb "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com>:


 "Andrej Mitrovic" <andrej.mitrovich gmail.com> wrote in message 
 news:mailman.904.1337305802.24740.digitalmars-d puremagic.com...

 On 5/18/12, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 Is it really that bad?


 Speaking of Github, it's really annoying how many projects get listed
 here even though they have nothing to do with D:
 https://github.com/languages/D/created

 I don't understand how Github manages to pick up so many java/cpp
 codebases and mark them as D codebases.


 
 I wonder if it's trying to detect D files with '*d' instead of '*.d'  Or, 
 maybe an accidental regex for '.d$' instead of '\.d$'  The [few] projects in 
 there that I looked at all had either a "README.md" or at least some 
 filename that ended with a "d".


Now that's funny. I just looked at one such project and it had neither
README.md, nor files ending in d. There were a few shell scripts which made up
about half of the project and patches to Python 2.7. So no real programming
language used. Yet GitHub shows:

D     83.8%
C     12.8%
Shell  2.7%
Other  0.6%

Assuming the .sh scripts get correctly recognized, there is something huge
accounted for that doesn't actually exist in the repository. I'm sure there is
already more than one bug report about this, as it is pretty obvious!

-- 
Marco
May 23 2012
prev sibling next sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Gor Gyolchanyan" <gor.f.gyolchanyan gmail.com> wrote in message 
news:mailman.722.1337004471.24740.digitalmars-d puremagic.com...

I was browsing dsource.org for some libraries, that I need and every single
 project, that I looked at was either completely abandoned or stuck with 
 the
 ancient D1.
 Is there at least one sane project in there or is dsource.org an ancient
 fossil for museum display?
 Sorry for my frustration.


I still use it for issue tracking and [zero-traffic] message boards for my 
stuff:

http://www.dsource.org/projects/semitwist
http://www.dsource.org/projects/goldie
http://www.dsource.org/projects/haxed

And for that last one, HaxeD, I also use it as the main project homepage.

Plus, Tango and the Orange serialization lib are still on DSource:

http://www.dsource.org/projects/tango
http://www.dsource.org/projects/orange

That's just off the top of my head, there's probably other stuff, too.
May 14 2012
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 5/14/2012 11:06 PM, Gor Gyolchanyan wrote:

 I was browsing dsource.org <http://dsource.org> for some libraries, that
 I need and every single project, that I looked at was either completely
 abandoned or stuck with the ancient D1.
 Is there at least one sane project in there or is dsource.org
 <http://dsource.org> an ancient fossil for museum display?
 Sorry for my frustration.

 --
 Bye,
 Gor Gyolchanyan.


Derelict 2 is still alive and kicking there. Plus, the Derelict forum 
there is where I support both Derelict 2 & 3.
May 14 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-15 08:32, Mike Parker wrote:


 Derelict 2 is still alive and kicking there. Plus, the Derelict forum
 there is where I support both Derelict 2 & 3.


The forum for Derelict is basically the only one which is active.

-- 
/Jacob Carlborg
May 15 2012
parent reply Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
Derelict 3 is under development and is on github, so Derelict is not gonna
be on dsource.org for too long,
A plethora of dead projects on dsource.org is a good way to scare away
newcomers, i think.

On Tue, May 15, 2012 at 1:42 PM, Jacob Carlborg <doob me.com> wrote:


 On 2012-05-15 08:32, Mike Parker wrote:

  Derelict 2 is still alive and kicking there. Plus, the Derelict forum

 there is where I support both Derelict 2 & 3.


 The forum for Derelict is basically the only one which is active.

 --
 /Jacob Carlborg




-- 
Bye,
Gor Gyolchanyan.
May 15 2012
next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 15.05.2012 14:04, Gor Gyolchanyan wrote:

 Derelict 3 is under development and is on github, so Derelict is not
 gonna be on dsource.org <http://dsource.org> for too long,
 A plethora of dead projects on dsource.org <http://dsource.org> is a
 good way to scare away newcomers, i think.


I think that a global purge can save it. Just archive/move away all of 
projects not updated for more then 1 year into some sort of Archive 
section. In case of misfire author can just contact admin and get his 
project reinstated.


-- 
Dmitry Olshansky
May 15 2012
parent Gor Gyolchanyan <gor.f.gyolchanyan gmail.com> writes:
I agree. That way it will become more apparent what really needs to be
written for D. Currently there "appears" to be a lot of stuff written for
D, when there's not more, then just a few.
Also, I think there should be a strict division of D1 and D2 projects
(where projects, supporting both would appear in both categories).
For instance, there's the DDL library for custom dynamic libraries in D,
but it' D1 only, making it completely useless for the vast majority of D
programmers.


On Tue, May 15, 2012 at 2:11 PM, Dmitry Olshansky <dmitry.olsh gmail.com>wrote:


 On 15.05.2012 14:04, Gor Gyolchanyan wrote:


 Derelict 3 is under development and is on github, so Derelict is not
 gonna be on dsource.org <http://dsource.org> for too long,
 A plethora of dead projects on dsource.org <http://dsource.org> is a

 good way to scare away newcomers, i think.


 I think that a global purge can save it. Just archive/move away all of
 projects not updated for more then 1 year into some sort of Archive
 section. In case of misfire author can just contact admin and get his
 project reinstated.


 --
 Dmitry Olshansky




-- 
Bye,
Gor Gyolchanyan.
May 15 2012
prev sibling parent Mike Parker <aldacron gmail.com> writes:
On 5/15/2012 7:04 PM, Gor Gyolchanyan wrote:

 Derelict 3 is under development and is on github, so Derelict is not
 gonna be on dsource.org <http://dsource.org> for too long,


It will be there as long as DSource exists. I have no plans to move it. 
My only real alternatives for the forum is to host it on my personal 
site or make a new one. Neither is very appealing to me at the moment.
May 15 2012