Slashdot Mirror

http://darcs.net/

Ditto everything you said. That's made especially ridiculous by the fact that the project owns their own domain, darcs.net, and could have just as easily used http://darcs.net/doesnotexist and configured their server to make sure it always returned a 404. Basically, they were using an undocumented third-party web service that returned 404s in response to a request and counting on the perpetual existence of that service. That's just goofy.

The test suite of Darcs needs a domain that doesn't exist. It used to use example.com for that purpose, which now fails:

Sat Jan 29 16:18:53 CET 2011 Ganesh Sittampalam

    * switch test to use a URL we can make sure will fail

    Seems like the behaviour of http://example.com/ changed to start serving

    pages at all URLs...

".example" is recommended for use in documentation or as examples.
".invalid" is intended for use in online construction of domain names that are sure to be invalid and which it is obvious at a glance are invalid.

Guess they should read the rfc.

If you need a dns entry that doesn't exist, pick one that you are authoritative for and make sure it doesn't exist.

That's exactly what they did:

-not darcs get http://example.com/foo
+not darcs get http://darcs.net/nonexistent

Sat Jan 29 16:18:53 CET 2011 Ganesh Sittampalam
* switch test to use a URL we can make sure will fail
Seems like the behaviour of http://example.com/ changed to start serving
pages at all URLs...

TWiki.net kicks out all contributors...
http://tech.slashdot.org/article.pl?sid=08/10/29/146201
also, the comments about the lack of security-sense in the coding...

I don't know if TikiWiki has the math capability, but why aren't people suggesting http://darcs.net/ as a back-end, instead of SVN?

-in-one makes sanest sense, though I'm not certain.

/works/
/works/paper01/
/works/paper01/images/
/works/paper01/data/
/works/paper02/
/works/paper02/images/
/works/paper02/data/

would mean that I could have a super-repo for all of 'em, plus sub-repos for each, so bug-fixes & updates could be local.

I don't know if that makes sense, but considering-the-problem is interesting, and maybe someone else knows the Right Answer?

PS: how come http://darcs.net/ got nuked and only Git is considered, nowadays?

PPS: how come no wordprocessor/docprocessor uses git/darcs as the back-end, to make document evolution better?
( a modified TuxCards would seem to be the ideal case for this )

I am using Darcs and it seems to do the job. Is strange that it isn't even mentioned cause it has been around since quite some time and is pretty mature. The only problem I am having with Darcs is huge resource consumption (a copy of the repository is on a VPS with 256mb RAM, no swap) but you can move a repository by just copying it somewhere else (even across systems) without problems. What are the advantages of using Git/Mercurial/Bazaar? I think I need to mention that I am developing on OSX (but a copy of the repository is on a Linux system).

The problem with Haskell is that it's a superb language for solving the sort of problems its designers foresaw. Unfortunately it makes it almost impossible to do things they didn't expect; you're too trapped in the rigours of the Haskell way of doing things.

I doubt that the original designer of Haskell had an SCM tool, e.g. darcs, in mind when creating the language. I am personally not a big fan of Haskell, but neither am I a hater, and even I have used darcs.

Absolutely, and this is why there's one of freenode's biggest IRC channels, a pair of mailing lists with thousands of subscribers, and the Hackage library/tool repository just waiting to help you solve your real world problem. Be it Compiler building, version control, writing interpretters for popular imperrative languages, Writing 3D shooters, or a whole host of other tasks.

How would "git" compare to something like DARCS?

I tried DARCS once and while it had some great features it was probably a bit early in development to be used at the time. Things might be different now though.
Has anyone tried both and could give some insights? .haeger

I haven't done a tremendous amount with it, but it is just as easy to set up a repository, and I never get the weird errors you're talking about.

Things darcs does that svn/cvs/VSS/ClearCase/etc don't do:
      * name patches (commit sets) & find them trivially by name later
      * trivially apply explicit patches to alternate branches
      * automatically find all patches that a patch depends on
      * create repositories trivially
      * see who committed specific lines of code

Git didn't appear to do a lot of that - no naming of patches, no seeing who last modified specific lines of code, no automatically determining patch dependencies.

The big problem is that for long revision histories, darcs seems to have a few bugs. Everything I've seen people talk about on the mailing list they've been able to fix or work around, but I have a very low tolerance for bugs in my revision control tool :-) Even so, the extra features are cool enough that I still use darcs for some projects.

Oh, the other thing: darcs is written in Haskell. I'm not sure if that's good or bad.

OfflineIMAP would fix most synchronization problems. Dovecot is a fast IMAP server and Maildrop coupled with your favourite smap filter could take care of the server part. Couple that with a good mail client (mutt) and a way to synchronize contacts. mutt can be customized with own keybindings, so that way one could add support for training the mail filter. I keep my home directory in a darcs repository to keep it in sync between machines. Other people use Subversion.

Yes, this method is an obvious way to get some benefit from a small number of extra hardware threads. But it is *not* future proof. This approach may give good CPU utilization up to perhaps 10-20 threads, but after that it will start to take a big dive.

While they are obviously not doing anything that supercomputer programmers didn't invent 30 years ago, they are leading their industry into the future, err, present. Though the article details are pretty weak, its clear that they've already gone beyond the module-level threading (sound, AI, graphics), to something that sounds more like work queues. If done right, those can get you to hundreds of threads as seen on early supercomputers, although it doesn't sound like Valve is dealing with cache-sharing problems yet, which could cause problems far sooner. I'm hoping hardware + language extensions will help mitigate that somewhat, at least on the read-sharing side.

Personally, my bet is on languages like Haskell. Purely functional programming makes multithreading easy, and for the imperative bits it has transactional memory (no locks, no deadlocks, and finally composability even with multithreading). Haskell itself may be too slow, so we may need to find a non-lazy version (laziness is basically the biggest performance problem Haskell has) for it to be practical.

I think OCaml has a lot better chance of becoming mainstream than Haskell. For one thing, I know of programs written in OCaml that aren't written by members of the PL community. For Haskell, outside of compilers and libraries, the only thing I can think of is Darcs, and that project is having all sorts of issues with determining and fixing performance problems (I love darcs though!). I'm not sure a pure-lazy language will ever map well to a soft-realtime media app such as a game. Also, when you really need delayed evaluation (i.e. laziness), ML derivatives have closures and higher-order functions which allow you to implement it easily enough.

Can anyone tell me if BitKeeper contains any innovations?

Not too much, I think arch (http://www.gnuarch.org/) and darcs (http://www.darcs.net/) were there first.

I'm also in favor of abandoning the term "innovation" in discussions of OSS. The concept "innovation in computer programming" was coined by Microsoft when they realized they hadn't any invention to speak of. McVoy using the same NewSpeak is kind of fitting.

Subversion is kinda behind the curve these days. I mean the whole concept of Subversion can basically be summed up as "let's make something that feels just like CVS, but doesn't suck." There are lots of free alternatives that provide much more advanced capabilities.

It's too bad they didn't chose something more advanced like Vesta, or Codeville, or monotone, or Darcs.

That's why I use darcs. Find out the differences with some surfing.

I'd go as far as to say that really Linus has been irresponsible here by starting Git.

Git is a hack to suit his needs, which is fine. But Git is pulling in all this publicity and development time from other people - there is basically a team of developers hacking on this hack of an SCM while more proven and mature solution (years in the making) which are only a little bit of dedication away from being ready to host a project as large as Linux are struggling to accomodate Git rather than focus on their (few) shortcomings.

A good example is Darcs. When this BK storm came about, the author David Roundy started on an efficiency crusade because the main obstacle to Darcs being an effective SCM for Linux was it's performance. This resulted in a number of improvements (due in the next release) and brought Darcs most of the way to being suitable for hosting the Linux source (it's distributed, easy to use, easy to merge). But now this whole Git thing has pulled everybody in different directions and recent list discussion is focused on how to accomodate Git as the backend storage mechanism for files even though it's really totally unsuited to the Darcs SCM methodology.

If Linus had said, "Well we're ditching BK as soon as possible. I want to use either Foo or Bar but needs X and Y in them addressing first." This would have brought about the necessary improvements without this Git diversion which may turn out to be permanent to the detriment of general progress.

He could have gone with Darcs or Monotone or even Arch and brought about their emergence as great distributed SCM tools. Instead he spent days - even weeks - hacking on Git and coordinating things through Git with manual merging. So he's wasted a lot of his own time and the time of others [hacking the hack] for the sake of creating something home grown rather than adopting something that was close to being an adequate replacement for BitKeeper.

Great men don't always make great choices.

You might also consider Darcs, whose website also keeps a copy of the Linux source in a repo.

It's decentralized and all that jazz. A darcs repo is hosted over http (or ssh) so it doesn't impose much in terms of hosting requirements.

The only downside is perhaps that it's written in Haskell and that some distros don't have great support for the Haskell packages Darcs needs.

It's not actually the case that Haskell "forces" functional purity, at least not in the way the submitter seems to think. You can do things that are a LOT like non-pure functions, you just have to use Monads. You have the so-called "unsafe" functions, which perform side-effects in otherwise "pure" functions.

So you might ask, "If you're going to write code like that in Haskell, why not just use C++." The answer is because even when using Haskell in a non-idiomatic way, Haskell is still more beautiful :)

Monads are a means of threading "stateful" code in a very clean and predictable way through your programs. The parent's comment, "Very localized state (in one function) is easy enough, but anything more pervasive and you soon become more familiar with monads than you ever wanted to be," is sorta like saying, "You can write high-level code in C++, but you will soon become more familiar with objects than you ever wanted to be."

They are indeed a part of the language, and definitely a new concept, but monads aren't nearly as confusing as people seem to think, certainly not more confusing than objects, it's just a reputation issue that makes people think monads are confusing. Take it from a random-joe hacker like me. You don't need a PhD to perform IO in Haskell.

For instance, here's a basic implementation of 'cat' in Haskell:

import System.Environment(getArgs)

main = do
{a <- getArgs;
lines <- mapM readFile a;
putStr (concat lines);}

The code:

a <- b

getArgs just reads in the command-line arguments as a list, so 'a' represents a list of the filenames.

readFile takes a file name, reads the contents, and returns it as a list of lines.

mapM means 'perform this computation once for each item in this list'

putStr is obvious, concat just takes a list of lists and turns it into a single list.

There's a paper, Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell about how to do these kinds of "real-world" things in Haskell.

There's also a very cool version control system called darcs that's written in Haskell, and recently an implementation of Perl 6 called Pugs in Haskell.

peace,

isaac

Darcs, a simple, human-friendly, completely distributed version control system. Does away with dedicated servers (even your desktop can be a "server"), branches (every repository is a branch) and CVS warts (tracks renames, deletes, directories).

New DARCS URL. (Note: Points to same IP address as old URL.)