[Haskell-cafe] Undo records
Hi, I am still getting a hang of Haskell. Sorry if the answer is obvious. What sorts of packages and approaches should I be looking at if I was looking to store something like an Undo stack into a database. Each table would refer to a function. Each records input and outputs would specify both a table ID and record ID. The records would also have a data and a Process ID to associate all functions to a specific process and give them an order. No records are ever deleted. Rolling something back is instead a process of recreating a new, modified graph by taking the old graph from the database. I should note that while I can generate some of the boiler parts from template haskell in advance I'm ultimately using a stage 1 compiler with no GHCI o template haskell. Thanks, Casey -- Casey James Basichis Composer - Cartoon Network http://www.caseyjamesbasichis.com caseybasic...@gmail.com 310.387.7540 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announce: Leksah 0.13.1.1 (a bit experimental)
I fixed some annoying issues with 0.13.1.0 and added "Panes->HLint". OS X (using Gtk3) - Choose the version that matches your installed GHC http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.3.dmg http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.4.dmg http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.1.dmg http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.2.dmg http://leksah.org/packages/leksah-0.13.1.1-ghc-7.6.1.dmg (probable needs OS X 10.7) Windows (still Gtk2) Choose the version that matches your installed GHC http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.3.exe http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.4.exe http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.1.exe http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.2.exe http://leksah.org/packages/leksah-0.13.1.1-ghc-7.6.1.exe On 6 Jan 2013, at 15:16, Hamish Mackenzie wrote: > This has mostly bug fixes, GHC 7.4.2, GHC 7.6.1 and Gtk3 > support. > > I have not uploaded it to Hackage as it uses Gtk2Hs patches > that are not in Hackage. > > New features include "View->Dark" (OS X only) and > "View->Fullscreen". > > Linux > - > Follow the steps in the .travis.yml file... > https://github.com/leksah/leksah/blob/master/.travis.yml > Should go something like this... > https://travis-ci.org/leksah/leksah ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Weird problem: Couldn't read cabal file "hashable/1.2.0.0/hashable.cabal"
Hi,
A friend of mine is trying to install my "timeplotters" (see email
signature).
He's getting a weird error: one of the tools installs fine but the other
one fails with the error "Couldn't read cabal file "hashable/
1.2.0.0/hashable.cabal""; curiously, so does running "cabal install
cabal-install".
Even more curiously, hashable 1.2.0.0 does not appear anywhere in the list
of dependencies, even indirect. Look:
$ cabal -v3 install cabal-install
searching for ghc in path.
found ghc at /usr/bin/ghc
("/usr/bin/ghc",["--numeric-version"])
/usr/bin/ghc is version 7.0.3
looking for tool "ghc-pkg" near compiler in /usr/bin
found ghc-pkg in /usr/bin/ghc-pkg
("/usr/bin/ghc-pkg",["--version"])
/usr/bin/ghc-pkg is version 7.0.3
("/usr/bin/ghc",["--supported-languages"])
("/usr/bin/ghc",["--info"])
Reading installed packages...
("/usr/bin/ghc-pkg",["dump","--global","-v2"])
("/usr/bin/ghc-pkg",["dump","--user","-v2"])
("/usr/bin/ghc",["--print-libdir"])
Reading available packages...
Resolving dependencies...
cabal: Couldn't read cabal file "hashable/1.2.0.0/hashable.cabal"
He's using haskell platform on Ubuntu 12.04.
$ ghc —version
The Glorious Glasgow Haskell Compilation System, version 7.0.3
$ cabal —version
cabal-install version 0.10.2
using version 1.10.1.0 of the Cabal library
He *did* try erasing ~/.cabal, ~/.ghc and /usr/lib/ghc and then
reinstalling haskell-platform package - it didn't change anything. He
doesn't remember ever having Haskell installed before, but that can't be
completely ruled out.
I just tried installing a fresh Ubuntu 12.04 onto a VM and I did not have
this problem that he has.
What additional information can I ask him for? Maybe somebody already
encountered this problem?
(Actually, I have a whole strace cabal install cabal-install, but it's 33Mb
- I can upload it somewhere if it could be helpful).
--
Eugene Kirpichov
http://www.linkedin.com/in/eugenekirpichov
http://jkff.info/software/timeplotters - my performance visualization tools
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Weird problem: Couldn't read cabal file "hashable/1.2.0.0/hashable.cabal"
The curious thing about that strace is that it doesn't ever attempt to open hashable.cabal - in fact, it isn't attempting to open *any* .cabal file whatsoever before failing! So I'm totally confused as to why cabal might be complaining that it can't open hashable.cabal. On Sun, Jan 6, 2013 at 10:05 PM, Eugene Kirpichov wrote: > Couldn't read cabal file -- Eugene Kirpichov http://www.linkedin.com/in/eugenekirpichov http://jkff.info/software/timeplotters - my performance visualization tools ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Weird problem: Couldn't read cabal file "hashable/1.2.0.0/hashable.cabal"
On Mon, Jan 7, 2013 at 1:05 AM, Eugene Kirpichov wrote: > A friend of mine is trying to install my "timeplotters" (see email > signature). > He's getting a weird error: one of the tools installs fine but the other > one fails with the error "Couldn't read cabal file "hashable/ > 1.2.0.0/hashable.cabal""; curiously, so does running "cabal install > cabal-install". > That's a symptom of too old cabal-install that crashes when it encounters certain newer cabal file features. I believe you need to upgrade cabal-install manually (since cabal-install itself will crash trying to do so...). It's not opening a cabal file directly, it is trying to parse entries in the compressed package list. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help diagnosing space leak with IORef/STRef, just incrementing a million times.
On 13-01-07 12:12 AM, Thomas Hartman wrote:
I have a space leak in a function that increments a number inside
IORef or STRef (either lazy or strict).
IORef and STRef operations do not automatically evaluate contents.
"writeIORef r (x + 1)" simply stores a pointer to the expression (thunk)
"x + 1" into the mutable cell. readIORef just reports back a pointer.
modifyIORef just calls readIORef and writeIORef. No evaluation throughout.
"modifyIORef incr" where
incr !x = x + 1
does not make a difference because it is just "writeIORef r (incr x))",
i.e., simply stores a pointer to the expression (thunk) "incr x" into
the mutable cell. The whole process doesn't even care about how many
bangs are in incr.
(It is illuminating to consider how "const True (incr x)" does not
evaluate x. A pointer to True and a pointer to "incr x" are passed to
const, then const throws away the latter without even looking. See also
"const True undefined". One day, you will thank "writeIORef r
undefined"; I certainly did.)
Same for both Data.STRef.Strict and Data.STRef.Lazy. They do not mean
what you think. Here is what they mean:
Data.STRef.Strict means what Control.Monad.ST.Strict means
Data.STRef.Lazy means what Control.Monad.ST.Lazy means
Control.Monad.ST.Strict means that the following hangs:
x = head (runST list) where
list :: ST s [Bool]
list = do {xs <- list; return (True : xs)}
Control.Monad.ST.Lazy means that the above terminates and gives the
answer True.
(Up to this point, same story for Control.Monad.State.Strict and
Control.Monad.State.Lazy.)
I still have not understood Control.Monad.ST.Lazy enough to articulate
its full semantics, but I have some more examples to show what it does:
http://hpaste.org/63925
By understanding what "Lazy" in Control.Monad.ST.Lazy means, you also
see what "Strict" does *not* mean.
In IO or Control.Monad.ST.Strict, use
let y = x+1 in y `seq` write[IO/ST]Ref r y
to expedite the evaluation of x+1. Using the same idea, you may write
your own modify[IO/ST]RefNOW to evaluate while updating.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announce: Leksah 0.13.1.1 (a bit experimental)
Thank you kindly for this release! System-wide package metadata is working with my platform install now. :) Cheers, d On Sun, Jan 6, 2013 at 9:34 PM, Hamish Mackenzie < hamish.k.macken...@gmail.com> wrote: > I fixed some annoying issues with 0.13.1.0 and > added "Panes->HLint". > > OS X (using Gtk3) > - > Choose the version that matches your installed GHC > http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.3.dmg > http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.4.dmg > http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.1.dmg > http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.2.dmg > http://leksah.org/packages/leksah-0.13.1.1-ghc-7.6.1.dmg > (probable needs OS X 10.7) > > Windows (still Gtk2) > > Choose the version that matches your installed GHC > http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.3.exe > http://leksah.org/packages/leksah-0.13.1.1-ghc-7.0.4.exe > http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.1.exe > http://leksah.org/packages/leksah-0.13.1.1-ghc-7.4.2.exe > http://leksah.org/packages/leksah-0.13.1.1-ghc-7.6.1.exe > > On 6 Jan 2013, at 15:16, Hamish Mackenzie > wrote: > > > This has mostly bug fixes, GHC 7.4.2, GHC 7.6.1 and Gtk3 > > support. > > > > I have not uploaded it to Hackage as it uses Gtk2Hs patches > > that are not in Hackage. > > > > New features include "View->Dark" (OS X only) and > > "View->Fullscreen". > > > > Linux > > - > > Follow the steps in the .travis.yml file... > > https://github.com/leksah/leksah/blob/master/.travis.yml > > Should go something like this... > > https://travis-ci.org/leksah/leksah > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] help diagnosing space leak with IORef/STRef, just incrementing a million times.
I have had issues like this with modifySTRef before. Try to make a strict version modifySTRef' If memory serves, something like this worked for me. modifySTRef' r f = do a <- readSTRef r writeSTRef r $! f a ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] help diagnosing space leak with IORef/STRef, just incrementing a million times.
A similar use-case and same solution with IORefs:
http://hpaste.org/diff/80055/80058 Guess which one threw a
stackoverflow and which one ran indefinitely when given a few hundred
million lines of input.
On 7 January 2013 07:35, Albert Y. C. Lai wrote:
> On 13-01-07 12:12 AM, Thomas Hartman wrote:
>>
>> I have a space leak in a function that increments a number inside
>> IORef or STRef (either lazy or strict).
>
>
> IORef and STRef operations do not automatically evaluate contents.
> "writeIORef r (x + 1)" simply stores a pointer to the expression (thunk) "x
> + 1" into the mutable cell. readIORef just reports back a pointer.
> modifyIORef just calls readIORef and writeIORef. No evaluation throughout.
>
> "modifyIORef incr" where
>
> incr !x = x + 1
>
> does not make a difference because it is just "writeIORef r (incr x))",
> i.e., simply stores a pointer to the expression (thunk) "incr x" into the
> mutable cell. The whole process doesn't even care about how many bangs are
> in incr.
>
> (It is illuminating to consider how "const True (incr x)" does not evaluate
> x. A pointer to True and a pointer to "incr x" are passed to const, then
> const throws away the latter without even looking. See also "const True
> undefined". One day, you will thank "writeIORef r undefined"; I certainly
> did.)
>
> Same for both Data.STRef.Strict and Data.STRef.Lazy. They do not mean what
> you think. Here is what they mean:
>
> Data.STRef.Strict means what Control.Monad.ST.Strict means
> Data.STRef.Lazy means what Control.Monad.ST.Lazy means
>
> Control.Monad.ST.Strict means that the following hangs:
>
> x = head (runST list) where
> list :: ST s [Bool]
> list = do {xs <- list; return (True : xs)}
>
> Control.Monad.ST.Lazy means that the above terminates and gives the answer
> True.
>
> (Up to this point, same story for Control.Monad.State.Strict and
> Control.Monad.State.Lazy.)
>
> I still have not understood Control.Monad.ST.Lazy enough to articulate its
> full semantics, but I have some more examples to show what it does:
>
> http://hpaste.org/63925
>
> By understanding what "Lazy" in Control.Monad.ST.Lazy means, you also see
> what "Strict" does *not* mean.
>
> In IO or Control.Monad.ST.Strict, use
>
> let y = x+1 in y `seq` write[IO/ST]Ref r y
>
> to expedite the evaluation of x+1. Using the same idea, you may write your
> own modify[IO/ST]RefNOW to evaluate while updating.
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
