Wed Oct 19 13:29:48 BST 2011 Max Bolingbroke
* Add link to browse package contents on package page
Ignore-this: a4e292383ceb8e9681e4dceab9435bc7
M ./Distribution/Server/Pages/Package.hs +1
Fri Oct 28 13:11:11 BST 2011 Max Bolingbroke
* Remove debugging print I accidentally commited
On 26 October 2011 13:46, Bas van Dijk wrote:
> According to the profile most space is used by ARR_WORDS (which is the
> internal name for a ByteArray# if I remember correctly).
Interesting. There are a lot of ByteStrings in use in the server, so
candidates for a leak might be:
1. The cached cab
On 25 October 2011 23:18, Bas van Dijk wrote:
> What kind[1] of heap profile would be most useful. (In my experience
> -hy or -hd are the most informative).
Either of those sound reasonable.
>> I'd like to try do this out
>> myself, but I can't mirror Hackage without hitting the usage limits on
On 25 October 2011 20:23, Bas van Dijk wrote:
> Does this sound like a memory leak or does hackage-server actually
> require more than 4GB memory?
Wow!
The SoC student reported memory usage of about ~700MB with a full
import from the Hackage of the time:
http://cogracenotes.wordpress.com/page/2/
Hi Bas,
On 22 October 2011 21:15, Bas van Dijk wrote:
> Attached is the package logo patch I was working on.
I wonder if perhaps you should implement this more like how Duncan
implemented change logs. i.e.:
1. Add a rendLogo field to PackageRender
2. Have doPackageRender fill rendLogo out by
Wed Oct 19 07:49:26 BST 2011 Max Bolingbroke
* Tidy up the runServerPartT_hack
Ignore-this: aa344978763ecd1d905d6c921d78d03
M ./Distribution/Server/Util/Happstack.hs -16 +8
Wed Oct 19 09:52:16 BST 2011 Max Bolingbroke
* Serve a plain text password upgrade message to cabal-install
On 18 October 2011 20:17, Duncan Coutts wrote:
> Initially I think we only need the "null" policy of setting upload time
> only, and the policy useful for a live public mirror of the central
> hackage server.
I've implemented this:
* Packages default to being uploaded by the mirrorer at the stan
Tue Oct 18 22:23:12 BST 2011 Max Bolingbroke
* Add FIXME
Ignore-this: 9de57a0e0cbcecd81b57a4be71980b57
M ./Distribution/Server/Framework/Auth.hs +1
Tue Oct 18 22:35:36 BST 2011 Max Bolingbroke
* Add URLs mirrorers can use to PUT/GET the upload time
Ignore-this
Tue Oct 18 18:03:05 BST 2011 Max Bolingbroke
* Allow import of users with .htpasswd hashes, and upgrading of those hashes
Ignore-this: f741f0a7cc379f4bf26dccee10401fb0
M ./Distribution/Server.hs -3 +3
M ./Distribution/Server/Features/Html.hs -13 +4
M ./Distribution/Server
On 17 October 2011 13:29, Max Bolingbroke wrote:
> I *think* this is what Duncan had in mind.
I spoke to him on IRC today and found that he actually had something
different in mind, which I've implemented as the "hackage-server
test-backup" command.
This approach doesn't
Hi David,
On 11 October 2011 07:02, David Laing wrote:
> Is there some kind of test plan or general level of testing that's
> hoped for? Should I add Arbitrary instances for the data being backed
> up so we can use QuickCheck to test that (more or less) backup .
> restore = id?
I *think* this i
On 10 October 2011 00:30, Duncan Coutts wrote:
> Ok, all committed now except for one of the cabal-install patches.
Thanks!
> I've not yet applied the cabal-install patch that makes the haddock
> options available via cabal install. I'm not sure about making them
> available directly as install
On 3 October 2011 21:30, Paterson, Ross wrote:
> Don't you need #517 to get the cross-package links to go to the right places?
I didn't realise there was a ticket open for that. It's part of the
changes that my patches make to cabal-install.
Max
___
c
On 28 September 2011 22:26, Max Bolingbroke wrote:
> I also had to make some small changes to
> cabal-install that should go into the Cabal repo.
FYI I have found the patch "Only use -i. when compiling the Cabal
package" breaks some things and is not even really necessary. Do no
On 27 September 2011 13:15, Max Bolingbroke wrote:
it would be nicer to expose a
> machine-readable resource like
> http://localhost:8080/package/process.json that I could retrieve and
> extract the relevant information from.
I've noticed that the particular data I'm af
Hi Cabalers,
I'm working on a bot to produce build reports and upload documentation
for Hackage 2.0. This bot needs a way to determine whether a
particular package already has documentation uploaded or not.
One possibility would be to have the bot download the package HTML
page and scrape the inf
Pretty trivial patch to support upcoming GHC extension.
Please review+apply.
Max
ConstraintKind.dpatch
Description: Binary data
___
cabal-devel mailing list
cabal-devel@haskell.org
http://www.haskell.org/mailman/listinfo/cabal-devel
On 21 May 2011 15:20, Duncan Coutts wrote:
> data Test = forall i r t. Testlike i r t => Test TestName t
> | TestGroup TestName [Test]
> | PlusTestOptions TestOptions Test
FYI, I recently added another alternative:
| BuildTest (IO Test)
The main purpose is to support a combin
On 31 March 2011 20:22, Johan Tibell wrote:
> On Thu, Mar 31, 2011 at 9:01 PM, Jason Dagit wrote:
>> I've seen a few people requesting 'cabal ghci' lately, and I just want to
>> point out that cabal-dev already has a ghci command. I use it quite often
>> and it's been working well for me.
>
> Ri
On 30 March 2011 09:37, Simon Meier wrote:
> Probably some more filtering of this sequence is required to cater for
> repeated calls to GHC. I guess that, as long as progress never goes from
> 100% to something below, the user will be happy about the progress estimate.
> Moreover, the chance that
On 28 March 2011 09:36, Simon Marlow wrote:
> the root cause is a size limitation in the OS X linker triggered when
> libraries get particularly large. We worked around it (actually Ian did) in
> GHC by adding support to the GHCi linker to load .a files.
>
> What's still missing (I presume) is so
On 11 January 2011 18:09, Thomas Tuegel wrote:
> One thing to do would be to change the interface so there is only one
> "Testable" class, allow tests in it to run in IO,
I would be happy with this.
> and provide some
> kind of combinator for denoting safe/unsafe tests.
That might be a possible
On 12 November 2010 01:16, Thomas Tuegel wrote:
> First, let me apologize for taking so long to respond; school is
> keeping me quite busy.
No problem.
>> * Separation of pure/impure tests - what do you want to use this for?
>> Good unit tests should be isolated from each other (no dependencies
On 11 October 2010 13:38, Duncan Coutts wrote:
> But yes, a review at some point would be appreciated. The goal is to
> have something close to what test-framework has always had (ie tree of
> tests, QC, HUnit, other tests to be lifted in) but using as few language
> extensions as we can get away
24 matches
Mail list logo
