On Tue, Oct 19, 2010 at 12:20 AM, Brian Warner wrote:
>
> I am still disappointed by the
> speed of e.g. 'darcs whatsnew -l' and 'darcs diff',
...
By the way the darcs hackers have been working on the speed of
whatsnew, at least. Not sure about "darcs diff".
Looking at the darcs benchmarks [1],
On 10/18/10 12:00 AM, Ravi Pinjala wrote:
>
> I'd even suggest that what you're suggesting for downloading the
> dependencies is too much. The standard for *nix systems (in other
> words, what users expect) is for the package to fail-fast at build
> time if anything's missing, and let the package
> On 2010-10-18 3:32 PM, Brian Warner wrote:
>> - darcs is slow, hard to publish branches, hard to use local
>> branches,
Zooko just pointed me at the following tidbit:
http://darcs.net/manual/Best_practices.html#SECTION0053
to turn on the global patch cache. The versi
#966: document munin plugins and make them discoverable
---+
Reporter: zooko | Owner: freestorm
Type: defect | Status: new
Priority: major
#1219: Visual changes on status web pages
---+
Reporter: freestorm | Owner: somebody
Type: defect | Status: new
Priority: major | Milestone: undec
James A. Donald wrote:
> On 2010-10-18 3:32 PM, Brian Warner wrote:
>> - darcs is slow, hard to publish branches, hard to use local
>> branches, hard to rewrite history before publishing, does not
>> provide useful short secure versionids, is not widely available, is
>> hard t
Dear Everyone:
Please feel free to jump in with your ideas and preferences. I want to
have an easy and encouraging process that lots of people can
contribute to, especially Brian Warner. Even though I hate using git,
and I'm hoping to settle on some intermediate stage (at least
temporarily) where
On Mon, Oct 18, 2010 at 3:35 PM, Raoul Duke wrote:
> On Mon, Oct 18, 2010 at 2:31 PM, James A. Donald
> wrote:
> > Such very high level languages will never produce usable software unless
> > they report the order of the algorithm.
>
> ok, this is getting off-topic, but that must be a different
On 2010-10-18 10:01 PM, nirali modi wrote:
hi,
I am planning to use Tahoe for sharing documents among users. From what i
have read and understood, it seems that Tahoe doesnt provide user
authentication. If a person gets access to the file capability then she
can
access the file. Is th
You want to be on the leading edge, but not on the bleeding edge.
You can tell the pioneers by the arrows in their backs. Haskell and
Darcs are on the bleeding edge - and similarly, there are too many
very high level dependencies in Tahoe.
While writing code in binary is perhaps a wee bit ard
On Mon, Oct 18, 2010 at 2:31 PM, James A. Donald wrote:
> Darcs is written in the obscure boutique language Haskel. Haskel is a very
> high level language, which means that you specify problems at a level higher
> than the precise algorithm, which means that Haskel may implement an
> exponential
On 2010-10-18 3:32 PM, Brian Warner wrote:
- darcs is slow, hard to publish branches, hard to use local
branches, hard to rewrite history before publishing, does not
provide useful short secure versionids, is not widely available, is
hard to build, has no good hosting servic
On 10/18/10 9:25 AM, Ravi Pinjala wrote:
> Yes, exactly. The possession of the file cap *is* the authorization.
> (As far as whether there are any plans to implement a more traditional
> authentication method, like username/password: I don't think so, but
> I'll defer to the much-more-experienced p
Hi,
I've got to know about Tahoe-LAFS through the bitcoin forum. I've setup
a topic about starting a tahoe-lafs grid within the bitcoin community
for them to join and use. The few people within that forum that tried
to install Tahoe-LAFS had some problems, largely caused by the things
you mentione
#1223: got 'WrongSegmentError' during repair
---+
Reporter: francois | Owner: somebody
Type: defect | Status: new
Priority: major
Yes, exactly. The possession of the file cap *is* the authorization.
(As far as whether there are any plans to implement a more traditional
authentication method, like username/password: I don't think so, but
I'll defer to the much-more-experienced people on this list.)
--Ravi
On Mon, Oct 18, 201
On Fri, Oct 15, 2010 at 11:23 AM, Brian Warner wrote:
> Last night I pushed a copy of this git repository up to GitHub:
>
Yay! Darcs is okay, but git is faster, has a lot of tool support and I know
it much better :)
Not that I have any time for Tahoe hacking anyway :(
--
Shawn
_
hi,
I am planning to use Tahoe for sharing documents among users. From what i
have read and understood, it seems that Tahoe doesnt provide user
authentication. If a person gets access to the file capability then she
can
access the file. Is this feature under the thought process..?
--
Tha
Wow, i will have to digest all that.
As a packaging ranter, I'll say that depending on 10 py-foo packages is
not a big hassle as long as:
most of those don't update constantly, and when they do the changes
are minor (API/ABI compat, not a lot of churn in installed file
organization)
We
This sounds like a really worthwhile project! Especially the stuff
about cleaning up the dependencies; I tried packaging Tahoe for Gentoo
at one point, and gave up completely after a few hours, partly because
of the number of dependencies unique to Tahoe (which I had to
recursively package as well)
20 matches
Mail list logo
