Alex Stangl posed a problem of trying to efficiently memoize a
function without causing divergence:
> solve = let a :: Array Int Int
> a = listArray (0, 3) (0 : f 0)
> f k = if k > 0
> then f (a!0)
> else 0 : f 1
> in (interca
On Mon, Nov 12, 2012 at 08:23:21PM -0500, Michael Orlitzky wrote:
> On 11/12/12 17:43, Iavor Diatchki wrote:
> > Hi,
> >
> > Ok, there were only minor differences between the repo and the version
> > on hackage so I imported the changes into the repo, which should now be
> > the same as version 1.
On Mon, Nov 12, 2012 at 02:43:32PM -0800, Iavor Diatchki wrote:
> Hi,
>
> Ok, there were only minor differences between the repo and the version on
> hackage so I imported the changes into the repo, which should now be the
> same as version 1.3.7 on hackage.
> Please feel free to submit merge requ
> Nice! Thanks! I'll have a go with it today or tomorrow.
There is not much yet. Have a look at the specs [1] to see what
currently works.
Cheers,
Simon
[1] https://github.com/sol/v8/tree/master/test/Foreign/JavaScript
___
Haskell-Cafe mailing list
H
Dear List,
The context of my problem is the following:
- ghc-HEAD uses shared-library _only_ on OS X
- A cabalized package that builds a shared/dynamic C-library (GLFW-b)
And my problem is:
A dynamically linked Haskell library gets the wrong install-name for a
C-library:
otool -L
~/.cabal/lib/
Hello,
There are several packages without haddock documentation on hackage. The
one that bugs me right now, is the latest version of gtk2hs: http://hackage.
haskell.org/package/gtk
I've been told that this may be due to hackage updating docs with an
infrequent cron job, so that new packages don
After 2 days of shrinking 251 modules of source code to a few lines I
realized that modify in MonadState causes <> in mtl-2.1.
http://hackage.haskell.org/packages/archive/mtl/2.1/doc/html/src/Control-Monad-State-Class.html#modify
The bug has been fixed, apparently seven month ago.
https://g
Mixed feelings here. I personally subscribe to the philosophy of "do one
thing and do it well"; perhaps this sort of functionality would be better
delegated to a new "curation" tool such as the one described in Michael
Snoyman's recent blog post.
http://www.yesodweb.com/blog/2012/11/solving-cabal-h
On 13.11.2012 17:39, Dan Burton wrote:
Mixed feelings here. I personally subscribe to the philosophy of "do one
thing and do it well"; perhaps this sort of functionality would be
better delegated to a new "curation" tool such as the one described in
Michael Snoyman's recent blog post.
http://www.
I agree with Andreas, we need a "package recall" method. This should be an
ability granted only to certain people, so that all of hackage cannot be
deleted by one rogue user with recall privileges, but this is still a
necessary feature.
Timothy
-- Původní zpráva --
Od: Andrea
On 13 November 2012 17:27, Andreas Abel wrote:
> This calls for a means of blacklisting broken or malicious packages.
>
> cabal update
>
> should also pull a blacklist of packages that will never be selected by
> cabal install (except maybe by explicit user safety overriding).
Maybe we can use
On Tue, 13 Nov 2012, Bas van Dijk wrote:
On 13 November 2012 17:27, Andreas Abel wrote:
This calls for a means of blacklisting broken or malicious packages.
cabal update
should also pull a blacklist of packages that will never be selected by
cabal install (except maybe by explicit user sa
I found that for the recently uploaded Agda-2.3.2 there is no
haddockumentation. Stumbling over the build protocol by chance
http://hackage.haskell.org/packages/archive/Agda/2.3.2/logs/success/ghc-7.6
I searched for whether haddock had been executed and found, yes, but
also, it failed:
.
Any reason haddock isn't run at the time the package is uploaded? Or could
the docs be included in the tarball? Folks oftentimes want to announce
their new packages right after uploading them, but usually there are no
docs yet. A little awkward.
Thanks,
Greg
On Tue, Nov 13, 2012 at 7:41 AM,
Thanks, will try them both. With regards to the implication I assume
it's just regarded as one property test ?
To get two values greater than zero I have something like
prop_something x y = ...do blah with positive integers
==> x > 0 && y > 0
But my test fails as it appears to be injecting
Your implication is backwards. ==> is read "implies"
So your way has "do blah with positive integers" implies "x > 0 && y > 0".
That's backwards.
Try prop_something x y = x > 0 && y > 0 ==> ... do blah with positive
integers
- Clark
On Tue, Nov 13, 2012 at 4:52 PM, wrote:
> Thanks, will tr
hi,
On 13 November 2012 21:52, wrote:
> prop_something x y = ...do blah with positive integers
> ==> x > 0 && y > 0
>
quickcheck provides a few nice new types for such cases. try:
prop_something (Positive x) (Positive y) = ...
this way qc only generates positive numbers, instead of gene
Thanks, that handy and works for my test.
Any idea why the implication does not ???
On Tue, Nov 13, 2012, at 09:59 PM, Ozgur Akgun wrote:
hi,
On 13 November 2012 21:52, <[1]gra...@fatlazycat.com> wrote:
prop_something x y = ...do blah with positive integers
==> x > 0 && y > 0
My take:
Blacklisting equals releasing a bugfix.
Using version number conventions, identifying such a release should be easy.
If there exists a bugfix release for a package currently in use, then cabal
should emit a warning.
Cheers,
JP.
On Nov 13, 2012 6:12 PM, "Andreas Abel" wrote:
> On 13.1
On 13.11.12 11:13 PM, Jean-Philippe Bernardy wrote:
Blacklisting equals releasing a bugfix.
Not quite.
Using version number conventions, identifying such a release should be easy.
If there exists a bugfix release for a package currently in use, then
cabal should emit a warning.
Warnings ar
On Tue, Nov 13, 2012 at 08:06:59AM -, o...@okmij.org wrote:
> Alex Stangl posed a problem of trying to efficiently memoize a
> function without causing divergence:
> ...
> But the problem can be fixed: after all, f k is a list of integers. A
> list is an indexable collection. Let us introduce t
Alex Stangl wrote:
> To make this concrete, here is the real solve function, which computes
> a border array (Knuth-Morris-Pratt failure function) for a specified
> string, before the broken memoization modification is made:
> solve :: String -> String
> solve w = let h = length w - 1
>
On Tue, Nov 13, 2012 at 11:39 PM, Andreas Abel wrote:
> On 13.11.12 11:13 PM, Jean-Philippe Bernardy wrote:
>
>> Blacklisting equals releasing a bugfix.
>>
>
> Not quite.
I propose to *define* blacklisting as such.
package-X.Y.Z.W is blacklisted if there exists package-X.Y.Z.V where V > W
(mayb
23 matches
Mail list logo
