[Haskell-cafe] ANNOUNCE: swish 0.3.0.0
I am pleased to announce an update of the swish package to version 0.3.0.0 [1]. It is mainly meant to be a maintenance upgrade over the existing version on Hackage [2] by Vasili I. Galchin, but does add additional functionality in that it now supports the NTriples format and the N3 parser and formatter has been updated to better match the current specification. For those not aware of what Swish actually is, it is an experiment by Graham Klyne in writing a "Semantic Web" framework in Haskell [3]. I note that the wonderful machinery behind Hackage has already processed the documentation so you can read more about it at [1] as well as the very-sparsely-documented Wiki at [4]. [1] http://hackage.haskell.org/package/swish-0.3.0.0 [2] http://hackage.haskell.org/package/swish-0.2.1 [3] http://www.ninebynine.org/Software/swish-0.2.1.html [4] https://bitbucket.org/doug_burke/swish/wiki/Home Thanks for reading this far, Doug ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 176
Welcome to issue 176 of the HWN, a newsletter covering developments in the [1]Haskell community. This release covers the week of March 27 to April 02, 2011. You can find the HTML version at: http://bit.ly/fEdQka Announcements Wren Ng Thornton [2]announced the release of version 0.3.4 of unix-bytestring. Ian Lynagh and the GHC team [3]announced version 7.0.3 of GHC, containing a handful of bugfixes. Jose A. Ortega Ruiz [4]annouced the release of version 0.13 of xmobar. Might want to check it out specially if you are using xmonad! Jason Dagit [5]annouced release 0.2.0 of the nehe-tuts package, tutorials for using OpenGL. David Sorokin [6]annouced the release of his new library aivika: a multi-paradigm simulation library. Tom Hawkins [7]annouced version 0.3.1 of ImProve: an imperative DSL for hard realtime embedded applications. Eric Y. Kow [8]introduced the first issue of Parallel Haskell Digest, "a newsletter aiming to show off all the work that's going on using parallelism and concurrency in the Haskell community." Here is to hoping we get more of these! George Giorgidze [9]announced version 0.5.5 of DSH (Database Supported Haskell). Jasper Van der Jeugt [10]annouced the 7th Ghent Functional Programming Group meeting on Tuesday, April 26, in celebration of the group's first year of existance. The meetup will be at the Technicum building of Ghent University at 19:30. Quotes of the Week * lispy: [in response to "C++ is a huge language, the type system is complex"] real and imaginary components :) the imaginary bits are the type safety * gwern: amazing `catch` (how sweet the type), that saved an exception like me! I once was thrown, but now am caught; was impure, but now pure be * hpc: appEndo sounds like a harry potter spell * monochrom: yeah, get out of Turing tarpit, provable termination, only to get into Godel tarpit * xplat: to me, the great thing about pointfree programming is you don't have to let variable names get in the way of your logic. and the great thing about pointful programming is you don't have to let '(flip .) . (.) . (flip flip . join)' get in the way of your logic. it's nice to have multiple tools in your toolbox * lispy: I've never looked at the gtk2hs source. I'm not sure I can muster the intestinal fortitude * kmc: time to play "transfinite ordinal or asian emoticon" * killing-joke: rip oop. "Object-oriented programming is eliminated entirely from the introductory curriculum, because it is both anti-modular and anti-parallel by its very nature, and hence unsuitable for a modern CS curriculum." Top Reddit Stories * Promo code to get Learn You a Haskell 40% off + e- book for free + swag From (learnyouahaskell.com), scored 68 with 25 comments. Read on [11]reddit. Read the [12]original post. * Real Time Edge Detection in Parallel Haskell From (disciple-devel.blogspot.com), scored 39 with 9 comments. Read on [13]reddit. Read the [14]original post. * Modern OpenGL with Haskell From (arcadianvisions.com), scored 39 with 10 comments. Read on [15]reddit. Read the [16]original post. * GHC migration to Git complete From (haskell.org), scored 37 with 15 comments. Read on [17]reddit. Read the [18]original post. * Haskell is 21 years old today! From (twitter.com), scored 37 with 8 comments. Read on [19]reddit. Read the [20]original post. * Re-implementing XMonad's core in Coq : Wouter Swiestra :: PDF From (cs.ru.nl), scored 34 with 13 comments. Read on [21]reddit. Read the [22]original post. * GHC 7.0.3 released From (haskell.org), scored 33 with 9 comments. Read on [23]reddit. Read the [24]original post. * "Reactive-banana and the essence of FRP". I implemented a small FRP library that can be mixed freely with imperative code. From (apfelmus.nfshost.com), scored 30 with 7 comments. Read on [25]reddit. Read the [26]original post. * New release of OpenGL NeHe tutorials in Haskell From (self.haskell), scored 27 with 22 comments. Read on [27]reddit. * Do you read academic papers on a Kindle? From (dmwit.com), scored 26 with 27 comments. Read on [28]reddit. Read the [29]original post. Top StackOverflow Questions * [30]Implementing lazy functional languages votes: 19, answers: 3 * [31]Is it possible to roll your own syntax sugar (like do-notation, or arrow-notation) in Haskell? votes: 12, answers: 2 * [32]Are there any LL Parser Generators for Functional Languages such as Haskell or Scala? votes: 11, answers: 4 * [33]Programming language for functional parallelism: F#
Re: [Haskell-cafe] Stacking data types
Thank you all,
In fact, Brandon, I knew about Datatypes a la carte, I just found it overly
complicated.
Thanks for you solution, Job. However (and even if it doesn't work without
it) I fail to see why you need the functional dependency on Has...
Doesn't it implies here that for one 'a' there can only be one 'b' such as
'Has b a'?
2011/4/6 Job Vranish
> I think you want something like this:
>
> {-# Language MultiParamTypeClasses
>, FlexibleInstances
>, FunctionalDependencies
>, UndecidableInstances
>, FlexibleContexts
>, OverlappingInstances
>
>#-}
> data Character a = Character { life :: Int,
>charaInner :: a }
> deriving (Show)
>
> data Gun a = Gun { firepower :: Int,
>gunInner :: a }
> deriving (Show)
>
> data Armor a = Armor { resistance :: Int,
>armorInner :: a }
>deriving (Show)
>
>
> class HasInner f where
> getInner :: f a -> a
>
> instance HasInner Character where
> getInner = charaInner
>
> instance HasInner Gun where
> getInner = gunInner
>
> instance HasInner Armor where
> getInner = armorInner
>
>
> class Has b a | a -> b where
> content :: a -> b
>
> instance (Has b a, HasInner f) => Has b (f a) where
> content a = content $ getInner a
>
> instance (HasInner f) => Has a (f a) where
> content a = getInner a
>
> chara = Character 100 $ Armor 40 $ Gun 12 ()
>
> itsGun :: (Has (Gun b) a) => a -> Gun b
> itsGun = content
>
> You were missing a mechanism to extract the inner value from your
> datatypes.
>
> - Job
>
>
> On Wed, Apr 6, 2011 at 2:57 PM, Yves Parès wrote:
>
>> Hello Café,
>>
>> I'm trying to get some modular data types.
>> The idea that came to me is that I could stack them, for instance :
>>
>> data Character a = Character { life :: Int,
>>charaInner :: a }
>>
>> data Gun a = Gun { firepower :: Int,
>>gunInner :: a }
>>
>> data Armor a = Armor { resistance :: Int,
>>armorInner :: a }
>>
>> Then a character with a gun and an armor can be build this way:
>>
>> chara = Character 100 $ Armor 40 $ Gun 12
>>
>> The idea now is to be able to get some part of the character:
>>
>> itsGun :: Character ?? -> Gun ??
>> itsGun = content
>>
>> Then content would be a class method:
>>
>> class Has b a where
>> content :: a -> b
>>
>> And it would be recursively defined so that:
>>
>> instance (Has c b, Has b a) => Has c a where
>> content = (content :: b -> c) . (content :: a -> b)
>>
>> Then itsGun would be more like:
>>
>> itsGun :: (Has Gun a) => a -> Gun ??
>> itsGun = content
>>
>> But after some juggling with extensions (ScopedTypeVariables,
>> UndecidableInstances, IncoherentInstances...) I can't get it working.
>>
>> Has someone a simpler way to achieve modular types?
>>
>> ___
>> 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
Re: [Haskell-cafe] mtlx has a nice design but is slow
Typically you'll want to inline any definitions of >>= and return in your classes and instances. Also, any non-recursive top level wrapper functions. On Wed, Apr 6, 2011 at 3:00 PM, Mark Snyder wrote: > I'm the author for mtlx, and admittedly I didn't do anything about > efficiency when I implemented it. Is there any initial place I ought to > look for tips on inlining? I'll start with the pragmas page > (http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/pragmas.html) I > suppose. I'm happy for any suggestions--optimizing hasn't been one of my > focuses, so it's time for me to learn I suppose! > I did switch to newtype definitions in the most recent version (0.1.5), > which probably helped a lot compared to data definitions, but there are no > inline pragmas in use, so perhaps there are some good opportunities for > optimization. > ~Mark Snyder >> >>Is the package missing some obvious inlining in the instances? >> >>> I just refactored my type and transform system prototype (introduced in >>> [1] >>> but changed since then) from using mtlx [2] (type-indexed monad >>> transformers >>> described in [3]) to mtl using RWST. mtlx allowed me to cleanly separate >>> the >>> various monadic components in a convenient way. Unfortunately, I found it >>> to >>> be too slow. The refactoring was an experiment to see how slow. I was >>> rather >>> surprised: >>> >>> Running time of a compiled main with a list of tests: >>> ? mtlx (7 transformers): 2 min 52 sec >>> ? mtl (RWST): 0 min 13 sec >>> >>> It's frustrating to see such a huge performance gap for a better design. >>> >>> Regards, >>> Sean >>> > > > > > ___ > 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
Re: [Haskell-cafe] mtlx has a nice design but is slow
I'm the author for mtlx, and admittedly I didn't do anything about efficiency when I implemented it. Is there any initial place I ought to look for tips on inlining? I'll start with the pragmas page (http://www.haskell.org/ghc/docs/7.0.3/html/users_guide/pragmas.html) I suppose. I'm happy for any suggestions--optimizing hasn't been one of my focuses, so it's time for me to learn I suppose! I did switch to newtype definitions in the most recent version (0.1.5), which probably helped a lot compared to data definitions, but there are no inline pragmas in use, so perhaps there are some good opportunities for optimization. ~Mark Snyder > >Is the package missing some obvious inlining in the instances? > >> I just refactored my type and transform system prototype (introduced in [1] >> but changed since then) from using mtlx [2] (type-indexed monad transformers >> described in [3]) to mtl using RWST. mtlx allowed me to cleanly separate the >> various monadic components in a convenient way. Unfortunately, I found it to >> be too slow. The refactoring was an experiment to see how slow. I was rather >> surprised: >> >> Running time of a compiled main with a list of tests: >> ? mtlx (7 transformers): 2 min 52 sec >> ? mtl (RWST): 0 min 13 sec >> >> It's frustrating to see such a huge performance gap for a better design. >> >> Regards, >> Sean >> ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to contact OpenGL package maintainer (where is Sven?)
On Wed, Apr 6, 2011 at 2:35 PM, Don Stewart wrote: > Note, there are some issues, as this is a package in the Haskell > Platform, to do with upgrading and dependent packages. We should talk > first about issues there. > An older version is in the HP, but Johan pointed out to me in a private email that the latest version is not in the HP. Here are the results of my research into that: I'm not finding much in the way of reasons why the *Raw packages were not added or why OpenGL/GLUT were not updated. There are these: http://trac.haskell.org/haskell-platform/ticket/157 http://trac.haskell.org/haskell-platform/ticket/158 That's a request for the latest version of GLUT and OpenGL. I found those via the archives but the threads are empty and no comments on the tickets. Magnus created those tickets as a result of this thread, I believe: http://projects.haskell.org/pipermail/haskell-platform/2011-February/001401.html Is that the thread in your memory? Perhaps it was this one? http://www.haskell.org/pipermail/libraries/2009-June/011920.html That one turned into a discussion of the module system. I added a proposal to add OpenGLRaw, but no one commented on it: http://projects.haskell.org/pipermail/haskell-platform/2011-March/001506.html Based on that, it seems that Magnus wants the packages updated, and I'd like to see the *Raw packages added to the platform. I don't see any dissenting public opinions on the libraries list or on the trac, other than tickets #57 and #58 that make a case for removing OpenGL and GLUT entirely from the platform. Tickets #57 and #58 seem to be old though. If you have more information or I overlooked something, please let me know :) Thanks, Jason > On Wed, Apr 6, 2011 at 2:32 PM, Jason Dagit wrote: > > No response yet from Sven after about a month and no one seems to have > heard > > from him in over a year. > > > > I'm going to take over for now under the assumption that Sven is missing. > > == My plans for moving forward == > > * Assemble an opengl taskforce, a few people have already mentioned an > > interest in being on the team > > * clean up the current cabal files (I already wrote patches for that) > > * put the repos on github to make team collaboration easier > > * add the RULES that Andy Gill suggested for realToFrac > > * look at adding instances for MArray so that GLfloat et al can be > stored > > in IOUArrays > > * add support for opengl 4.x > > * look at adding deprecation pragmas for deprecated opengl calls > > * new hackage releases > > * anything else that comes up > > Thanks, > > Jason > > > > On Sun, Mar 27, 2011 at 2:11 PM, Jason Dagit wrote: > >> > >> I sent the message below to Haskell-Cafe about a week ago. I got one > >> response saying that Sven has disappeared in the past but reappeared > when > >> updates were necessary. I still haven't heard from Sven. Now I'm > widening > >> my search. My original email to Sven was on March 11th. > >> It looks like the OpenGL packages on hackage[1,2,3,4] have not been > >> updated in some time. No updates later than Oct 2009. I tried to email > >> Sven directly using the email address listed on hackage but after over > two > >> weeks I still haven't heard from him. I sent some patches to > >> the opengl list about a week ago but I noticed that Sven hasn't posted > on > >> that list since Oct 2009 when he released the current version of > OpenGLRaw. > >> None of the public darcs repos have patches newer than Oct 2009. Also, > the > >> homepage url listed in the packages is a 404: > >> http://www.haskell.org/HOpenGL/ > >> My concern is that Sven has disappeared for some reason. I hope he's > >> well. He has always done top notch work in the past maintaining these > >> libraries. Perhaps he's simply busy or lost interest? > >> Does anyone know if he was looking for a new maintainer? Perhaps you've > >> heard from him more recently than Oct 2009? > >> If a new maintainer is needed, I would consider nominating myself :) > >> Thanks, > >> Jason > >> [1] http://hackage.haskell.org/package/OpenGLRaw > >> [2] http://hackage.haskell.org/package/OpenGL > >> [3] http://hackage.haskell.org/package/GLURaw > >> [4] http://hackage.haskell.org/package/GLUT > > > > ___ > > Libraries mailing list > > librar...@haskell.org > > http://www.haskell.org/mailman/listinfo/libraries > > > > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to contact OpenGL package maintainer (where is Sven?)
Note, there are some issues, as this is a package in the Haskell Platform, to do with upgrading and dependent packages. We should talk first about issues there. On Wed, Apr 6, 2011 at 2:32 PM, Jason Dagit wrote: > No response yet from Sven after about a month and no one seems to have heard > from him in over a year. > > I'm going to take over for now under the assumption that Sven is missing. > == My plans for moving forward == > * Assemble an opengl taskforce, a few people have already mentioned an > interest in being on the team > * clean up the current cabal files (I already wrote patches for that) > * put the repos on github to make team collaboration easier > * add the RULES that Andy Gill suggested for realToFrac > * look at adding instances for MArray so that GLfloat et al can be stored > in IOUArrays > * add support for opengl 4.x > * look at adding deprecation pragmas for deprecated opengl calls > * new hackage releases > * anything else that comes up > Thanks, > Jason > > On Sun, Mar 27, 2011 at 2:11 PM, Jason Dagit wrote: >> >> I sent the message below to Haskell-Cafe about a week ago. I got one >> response saying that Sven has disappeared in the past but reappeared when >> updates were necessary. I still haven't heard from Sven. Now I'm widening >> my search. My original email to Sven was on March 11th. >> It looks like the OpenGL packages on hackage[1,2,3,4] have not been >> updated in some time. No updates later than Oct 2009. I tried to email >> Sven directly using the email address listed on hackage but after over two >> weeks I still haven't heard from him. I sent some patches to >> the opengl list about a week ago but I noticed that Sven hasn't posted on >> that list since Oct 2009 when he released the current version of OpenGLRaw. >> None of the public darcs repos have patches newer than Oct 2009. Also, the >> homepage url listed in the packages is a 404: >> http://www.haskell.org/HOpenGL/ >> My concern is that Sven has disappeared for some reason. I hope he's >> well. He has always done top notch work in the past maintaining these >> libraries. Perhaps he's simply busy or lost interest? >> Does anyone know if he was looking for a new maintainer? Perhaps you've >> heard from him more recently than Oct 2009? >> If a new maintainer is needed, I would consider nominating myself :) >> Thanks, >> Jason >> [1] http://hackage.haskell.org/package/OpenGLRaw >> [2] http://hackage.haskell.org/package/OpenGL >> [3] http://hackage.haskell.org/package/GLURaw >> [4] http://hackage.haskell.org/package/GLUT > > ___ > Libraries mailing list > librar...@haskell.org > http://www.haskell.org/mailman/listinfo/libraries > > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to contact OpenGL package maintainer (where is Sven?)
No response yet from Sven after about a month and no one seems to have heard from him in over a year. I'm going to take over for now under the assumption that Sven is missing. == My plans for moving forward == * Assemble an opengl taskforce, a few people have already mentioned an interest in being on the team * clean up the current cabal files (I already wrote patches for that) * put the repos on github to make team collaboration easier * add the RULES that Andy Gill suggested for realToFrac * look at adding instances for MArray so that GLfloat et al can be stored in IOUArrays * add support for opengl 4.x * look at adding deprecation pragmas for deprecated opengl calls * new hackage releases * anything else that comes up Thanks, Jason On Sun, Mar 27, 2011 at 2:11 PM, Jason Dagit wrote: > I sent the message below to Haskell-Cafe about a week ago. I got one > response saying that Sven has disappeared in the past but reappeared when > updates were necessary. I still haven't heard from Sven. Now I'm widening > my search. My original email to Sven was on March 11th. > > It looks like the OpenGL packages on hackage[1,2,3,4] have not been > updated in some time. No updates later than Oct 2009. I tried to email > Sven directly using the email address listed on hackage but after over two > weeks I still haven't heard from him. I sent some patches to the opengl list > about a week ago but I noticed that Sven hasn't posted on that list since > Oct 2009 when he released the current version of OpenGLRaw. None of the > public darcs repos have patches newer than Oct 2009. Also, the homepage url > listed in the packages is a 404: > http://www.haskell.org/HOpenGL/ > > My concern is that Sven has disappeared for some reason. I hope he's well. > He has always done top notch work in the past maintaining these libraries. > Perhaps he's simply busy or lost interest? > > Does anyone know if he was looking for a new maintainer? Perhaps you've > heard from him more recently than Oct 2009? > > If a new maintainer is needed, I would consider nominating myself :) > > Thanks, > Jason > > [1] http://hackage.haskell.org/package/OpenGLRaw > [2] http://hackage.haskell.org/package/OpenGL > [3] http://hackage.haskell.org/package/GLURaw > [4] http://hackage.haskell.org/package/GLUT > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DocTest-0.2.0
Hello Michael, > I would like to integrate DocTest into my normal test suite procedures. Do you > have a recommended approach for this? I think I have projects using all of > test-framework[1], HTF[2] and hspect[3], so I'm not picky here. Currently you are pretty much on your own here. A shell script that runs both, doctest and unit test, is what I currently use. In principle it should be possible to provide an API function that maps a list of flags and source files to tests, like: getDocTests :: [Flag] -> [FilePath] -> IO [Test] But with this you still have to figure out the flags and source files. A different approach would be to provide Cabal with a `doctest' target (similar to the `haddock' target), that runs the DocTests. Cabal already knows the necessary information to do so. Sadly, I have no time to work on any of these for at least a month. Nevertheless, I'd be interested what you think about it. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking data types
I think you want something like this:
{-# Language MultiParamTypeClasses
, FlexibleInstances
, FunctionalDependencies
, UndecidableInstances
, FlexibleContexts
, OverlappingInstances
#-}
data Character a = Character { life :: Int,
charaInner :: a }
deriving (Show)
data Gun a = Gun { firepower :: Int,
gunInner :: a }
deriving (Show)
data Armor a = Armor { resistance :: Int,
armorInner :: a }
deriving (Show)
class HasInner f where
getInner :: f a -> a
instance HasInner Character where
getInner = charaInner
instance HasInner Gun where
getInner = gunInner
instance HasInner Armor where
getInner = armorInner
class Has b a | a -> b where
content :: a -> b
instance (Has b a, HasInner f) => Has b (f a) where
content a = content $ getInner a
instance (HasInner f) => Has a (f a) where
content a = getInner a
chara = Character 100 $ Armor 40 $ Gun 12 ()
itsGun :: (Has (Gun b) a) => a -> Gun b
itsGun = content
You were missing a mechanism to extract the inner value from your datatypes.
- Job
On Wed, Apr 6, 2011 at 2:57 PM, Yves Parès wrote:
> Hello Café,
>
> I'm trying to get some modular data types.
> The idea that came to me is that I could stack them, for instance :
>
> data Character a = Character { life :: Int,
>charaInner :: a }
>
> data Gun a = Gun { firepower :: Int,
>gunInner :: a }
>
> data Armor a = Armor { resistance :: Int,
>armorInner :: a }
>
> Then a character with a gun and an armor can be build this way:
>
> chara = Character 100 $ Armor 40 $ Gun 12
>
> The idea now is to be able to get some part of the character:
>
> itsGun :: Character ?? -> Gun ??
> itsGun = content
>
> Then content would be a class method:
>
> class Has b a where
> content :: a -> b
>
> And it would be recursively defined so that:
>
> instance (Has c b, Has b a) => Has c a where
> content = (content :: b -> c) . (content :: a -> b)
>
> Then itsGun would be more like:
>
> itsGun :: (Has Gun a) => a -> Gun ??
> itsGun = content
>
> But after some juggling with extensions (ScopedTypeVariables,
> UndecidableInstances, IncoherentInstances...) I can't get it working.
>
> Has someone a simpler way to achieve modular types?
>
> ___
> 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
Re: [Haskell-cafe] Stacking data types
I think I should suggest HList from Oleg Kiseliov.
http://hackage.haskell.org/package/HList
That way you will have something along those lines:
-- fields descriptors:
data Character
data Gun
data Armor
data Life
-- values for fields:
data Vulcan = Vulcan { vulcanAmmoCount :: Int}
data Player = Player { playerName :: String }
player = (Character, Player) :*: (Gun,Vulcan) :*: (Armor,50) :*: HNil
HList has all the machinery to create records, get a field from record
(something like "getField rec Character"), test for field in record
(Maybe value), etc.
2011/4/6 Yves Parès :
> Hello Café,
>
> I'm trying to get some modular data types.
> The idea that came to me is that I could stack them, for instance :
>
> data Character a = Character { life :: Int,
> charaInner :: a }
>
> data Gun a = Gun { firepower :: Int,
> gunInner :: a }
>
> data Armor a = Armor { resistance :: Int,
> armorInner :: a }
>
> Then a character with a gun and an armor can be build this way:
>
> chara = Character 100 $ Armor 40 $ Gun 12
>
> The idea now is to be able to get some part of the character:
>
> itsGun :: Character ?? -> Gun ??
> itsGun = content
>
> Then content would be a class method:
>
> class Has b a where
> content :: a -> b
>
> And it would be recursively defined so that:
>
> instance (Has c b, Has b a) => Has c a where
> content = (content :: b -> c) . (content :: a -> b)
>
> Then itsGun would be more like:
>
> itsGun :: (Has Gun a) => a -> Gun ??
> itsGun = content
>
> But after some juggling with extensions (ScopedTypeVariables,
> UndecidableInstances, IncoherentInstances...) I can't get it working.
>
> Has someone a simpler way to achieve modular types?
>
> ___
> 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
Re: [Haskell-cafe] 'Progress bar' enumeratee
"David Hotham" wrote: > The desired behaviour (certainly my desired behaviour, but I think > also the most useful behaviour generally) is that the enumeratee > passes n bytes to its iteratee, prints a dot, and repeats. > > Given that, printing the dots all in one bunch after passing bytes to > the iteratee isn't any improvement over printing the dots all in one > bunch before passing them to the iteratee. > > I think that mostly I want it the way that I want it because that's > the bit that I struggled most over and I'm now reluctant to give it > up! However this might actually make a useful difference to behaviour > in the case of an iteratee that did very expensive processing, or that > itself performed IO. In such cases, my behaviour could be expected to > give a more accurate indication of how far through processing we'd > actually got. If you're talking about my code, you must have misunderstood something. It does not print the dots all in one bunch, but prints them as input is requested from the enumerator. The last version I posted prints the dots after the iteratee has consumed the input. That difference is noticable, when your iteratee does complex computations before it goes back to the Continue state. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking data types
On 06/04/11 20:32, Brandon Moore wrote:
From: Yves Parès
Sent: Wed, April 6, 2011 1:57:51 PM
Hello Café,
I'm trying to get some modular data types.
The idea that came to me is that I could stack them, for instance :
data Character a = Character { life :: Int,
charaInner :: a }
data Gun a = Gun { firepower :: Int,
gunInner :: a }
data Armor a = Armor { resistance :: Int,
armorInner :: a }
Then a character with a gun and an armor can be build this way:
chara = Character 100 $ Armor 40 $ Gun 12
The idea now is to be able to get some part of the character:
I don't have a better design to suggest, but I think this may end up more
complicated than you want. In particular, it will probably be complicated to
make a collection of characters that have e.g. an Armor but maybe any
other stuff.
If you do want to use this sort of design, check out Wouter Swiestra's
paper "Data Type a la Cart".
Brandon.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
I was struggling with this idea a few weeks ago. I think I tried the
same types of extensions that you have, also with no luck.
I then started looking at extensible records on the Haskell wiki
http://www.haskell.org/haskellwiki/Extensible_record
This was the one I liked, but as far as I could tell it has not been
implemented (please tell me if I was wrong about that)
http://research.microsoft.com/en-us/um/people/simonpj/Haskell/records.html
RS
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'Progress bar' enumeratee
My enumerator style may not be the best (I'm long-winded), but personally when the stream types are the same on input and output I often skip the Enumeratee stuff and just write an Enumerator wrapper. To address your complaint here: > PS Implementations which involve "EB.take count" seem to me unsatisfactory; > one surely oughtn't need to have a large buffer to solve this problem I'd write a helping combinator: > module Main where > > import Control.Monad (when) > import Control.Monad.Trans > import Data.ByteString.Char8 (ByteString) > import qualified Data.ByteString.Lazy.Char8 as L > import Data.Enumerator > import qualified Data.Enumerator.List as EL > import System.IO > > takeUpTo :: Monad m => > Int > -> Iteratee ByteString m (Stream ByteString, Int) > takeUpTo n' = continue k > where > n = toEnum n' > > k EOF = yield (EOF,0) EOF > k (Chunks xs) = if taken == 0 > then takeUpTo n' > else yield (stream, taken) rest > where > s = L.fromChunks xs > (a,b) = L.splitAt n s > taken = fromEnum $ L.length a > stream = Chunks $ L.toChunks a > rest = Chunks $ L.toChunks b > The code to run a side effect every N bytes is then pretty short (and should be efficient): > sideEffectEveryNBytes :: Monad m => > Int -- ^ run the side effect every N bytes > -> m () -- ^ side effect > -> Step ByteString m a > -> Iteratee ByteString m a > sideEffectEveryNBytes n act = flip checkContinue1 n $ \loop i k -> do > (str, taken) <- takeUpTo i > when (taken == i) $ lift act > (lift $ runIteratee $ k str) >>= loop (nextI $ i - taken) > where > nextI 0 = n > nextI i = i Here's your particular example: > example :: IO [ByteString] > example = run_ $ enumList 1 [ "the quick brown " > , "fox " > , "jumped " > , "over " > , "the lazy dog" ] $$ it > where > it = do > xs <- sideEffectEveryNBytes 10 (putStr "." >> hFlush stdout) $$ > EL.consume > lift $ putStrLn "" > return xs Running it: > *Main> example > > ["the quick ","brown ","fox ","jumped ","ove","r ","the lazy"," dog"] G -- Gregory Collins ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking data types
>From: Yves Parès
>Sent: Wed, April 6, 2011 1:57:51 PM
>
>Hello Café,
>
>I'm trying to get some modular data types.
>The idea that came to me is that I could stack them, for instance :
>
>data Character a = Character { life :: Int,
> charaInner :: a }
>
>data Gun a = Gun { firepower :: Int,
> gunInner :: a }
>
>data Armor a = Armor { resistance :: Int,
> armorInner :: a }
>
>Then a character with a gun and an armor can be build this way:
>
>chara = Character 100 $ Armor 40 $ Gun 12
>
>The idea now is to be able to get some part of the character:
I don't have a better design to suggest, but I think this may end up more
complicated than you want. In particular, it will probably be complicated to
make a collection of characters that have e.g. an Armor but maybe any
other stuff.
If you do want to use this sort of design, check out Wouter Swiestra's
paper "Data Type a la Cart".
Brandon.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'Progress bar' enumeratee
The desired behaviour (certainly my desired behaviour, but I think also the most useful behaviour generally) is that the enumeratee passes n bytes to its iteratee, prints a dot, and repeats. Given that, printing the dots all in one bunch after passing bytes to the iteratee isn't any improvement over printing the dots all in one bunch before passing them to the iteratee. I think that mostly I want it the way that I want it because that's the bit that I struggled most over and I'm now reluctant to give it up! However this might actually make a useful difference to behaviour in the case of an iteratee that did very expensive processing, or that itself performed IO. In such cases, my behaviour could be expected to give a more accurate indication of how far through processing we'd actually got. David PS Yes, I already tried out the code ;-). You'll see that both of my versions did indeed hFlush stdout. "Ertugrul Soeylemez" wrote in message news:20110406182931.02385...@angst.streitmacht.eu... "David Hotham" wrote: I did have a version along those lines at some point, but I felt it was cheating rather to print the dots not at the correct point in the stream. Perhaps I've over-complicated for the sake of the learning experience, but I do like to have a version that passes on the correct number of bytes, then prints the ".", and then continues. Well, then just do the printing after calling the continuation: dotsAt :: forall b m. MonadPeelIO m => Int -> Enumeratee ByteString ByteString m b dotsAt n = loop 0 where loop :: Int -> Enumeratee ByteString ByteString m b loop i' step@(Continue k) = continue go where go :: Stream ByteString -> Iteratee ByteString m (Step ByteString m b) go EOF = return step go ch@(Chunks strs) = do let (numDots, i) = divMod (i' + sum (L.map BC.length strs)) n printDots = tryIO $ BC.putStr (BC.replicate numDots '.') >> hFlush stdout k ch >>== (\step -> printDots >> loop i step) loop i' step = return step By the way, after trying out the code, I found that you should use hFlush after printing. Otherwise you may see the dots delayed. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking data types
What about record types?
On Wed, Apr 6, 2011 at 11:58 AM, Yves Parès wrote:
> I meant:
>
> chara = Character 100 $ Armor 40 $ Gun 12 ()
>
> 2011/4/6 Yves Parès
>>
>> Hello Café,
>>
>> I'm trying to get some modular data types.
>> The idea that came to me is that I could stack them, for instance :
>>
>> data Character a = Character { life :: Int,
>> charaInner :: a }
>>
>> data Gun a = Gun { firepower :: Int,
>> gunInner :: a }
>>
>> data Armor a = Armor { resistance :: Int,
>> armorInner :: a }
>>
>> Then a character with a gun and an armor can be build this way:
>>
>> chara = Character 100 $ Armor 40 $ Gun 12
>>
>> The idea now is to be able to get some part of the character:
>>
>> itsGun :: Character ?? -> Gun ??
>> itsGun = content
>>
>> Then content would be a class method:
>>
>> class Has b a where
>> content :: a -> b
>>
>> And it would be recursively defined so that:
>>
>> instance (Has c b, Has b a) => Has c a where
>> content = (content :: b -> c) . (content :: a -> b)
>>
>> Then itsGun would be more like:
>>
>> itsGun :: (Has Gun a) => a -> Gun ??
>> itsGun = content
>>
>> But after some juggling with extensions (ScopedTypeVariables,
>> UndecidableInstances, IncoherentInstances...) I can't get it working.
>>
>> Has someone a simpler way to achieve modular types?
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
--
--
Regards,
KC
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stacking data types
I meant:
chara = Character 100 $ Armor 40 $ Gun 12 *()*
2011/4/6 Yves Parès
> Hello Café,
>
> I'm trying to get some modular data types.
> The idea that came to me is that I could stack them, for instance :
>
> data Character a = Character { life :: Int,
>charaInner :: a }
>
> data Gun a = Gun { firepower :: Int,
>gunInner :: a }
>
> data Armor a = Armor { resistance :: Int,
>armorInner :: a }
>
> Then a character with a gun and an armor can be build this way:
>
> chara = Character 100 $ Armor 40 $ Gun 12
>
> The idea now is to be able to get some part of the character:
>
> itsGun :: Character ?? -> Gun ??
> itsGun = content
>
> Then content would be a class method:
>
> class Has b a where
> content :: a -> b
>
> And it would be recursively defined so that:
>
> instance (Has c b, Has b a) => Has c a where
> content = (content :: b -> c) . (content :: a -> b)
>
> Then itsGun would be more like:
>
> itsGun :: (Has Gun a) => a -> Gun ??
> itsGun = content
>
> But after some juggling with extensions (ScopedTypeVariables,
> UndecidableInstances, IncoherentInstances...) I can't get it working.
>
> Has someone a simpler way to achieve modular types?
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Stacking data types
Hello Café,
I'm trying to get some modular data types.
The idea that came to me is that I could stack them, for instance :
data Character a = Character { life :: Int,
charaInner :: a }
data Gun a = Gun { firepower :: Int,
gunInner :: a }
data Armor a = Armor { resistance :: Int,
armorInner :: a }
Then a character with a gun and an armor can be build this way:
chara = Character 100 $ Armor 40 $ Gun 12
The idea now is to be able to get some part of the character:
itsGun :: Character ?? -> Gun ??
itsGun = content
Then content would be a class method:
class Has b a where
content :: a -> b
And it would be recursively defined so that:
instance (Has c b, Has b a) => Has c a where
content = (content :: b -> c) . (content :: a -> b)
Then itsGun would be more like:
itsGun :: (Has Gun a) => a -> Gun ??
itsGun = content
But after some juggling with extensions (ScopedTypeVariables,
UndecidableInstances, IncoherentInstances...) I can't get it working.
Has someone a simpler way to achieve modular types?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: DocTest-0.2.0
Hi Simon, Looking into DocTest has been something on my TODO list for a few months now. After this email, I finally started looking into it. I was very impressed to see that, with the optghc option, I'm even able to test QuasiQuotes. Very impressive! I would like to integrate DocTest into my normal test suite procedures. Do you have a recommended approach for this? I think I have projects using all of test-framework[1], HTF[2] and hspect[3], so I'm not picky here. Michael [1] http://hackage.haskell.org/package/test-framework [2] http://hackage.haskell.org/package/HTF [3] http://hackage.haskell.org/package/hspec On Wed, Apr 6, 2011 at 7:46 PM, Simon Hengel wrote: > I just uploaded a new version of DocTest[1] to Hackage. > > > WHAT IS DocTest? > > > DocTest is a port of Python's doctest[2] to Haskell. It can be used to > verify, that examples in Haddock comments[3] do still work. This also > provides you with a simple mechanism to write unit test, without the > burden of maintaining a dedicated test suite. > > A basic example of usage is at [4]. > > > WHAT'S NEW IN THIS VERSION? > === > > Support for blank lines in the result of an expression (analogous to the > -feature of Python's doctest). Here is an example of usage: > >-- | >-- Some example: >-- >-- >>> putStrLn "foo\n\nbar" >-- foo >-- >-- bar > > Currently this is implemented in DocTest, but we will move it to Haddock > with the next release. > > Cheers, > Simon > > [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/DocTest > [2] http://docs.python.org/library/doctest.html > [3] http://www.haskell.org/haddock/doc/html/ch03s08.html#id566093 > [4] http://haskell.org/haskellwiki/DocTest > ___ > 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] mtlx has a nice design but is slow
Is the package missing some obvious inlining in the instances? On Wed, Apr 6, 2011 at 10:13 AM, Sean Leather wrote: > I just refactored my type and transform system prototype (introduced in [1] > but changed since then) from using mtlx [2] (type-indexed monad transformers > described in [3]) to mtl using RWST. mtlx allowed me to cleanly separate the > various monadic components in a convenient way. Unfortunately, I found it to > be too slow. The refactoring was an experiment to see how slow. I was rather > surprised: > > Running time of a compiled main with a list of tests: > mtlx (7 transformers): 2 min 52 sec > mtl (RWST): 0 min 13 sec > > It's frustrating to see such a huge performance gap for a better design. > > Regards, > Sean > > [1] > http://splonderzoek.blogspot.com/2011/03/draft-type-changing-program-improvement.html > [2] http://hackage.haskell.org/package/mtlx > [3] http://www.ittc.ku.edu/~marks/cgi-bin/pubs/monadfactory.pdf > > > ___ > 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] mtlx has a nice design but is slow
I just refactored my type and transform system prototype (introduced in [1] but changed since then) from using mtlx [2] (type-indexed monad transformers described in [3]) to mtl using RWST. mtlx allowed me to cleanly separate the various monadic components in a convenient way. Unfortunately, I found it to be too slow. The refactoring was an experiment to see how slow. I was rather surprised: Running time of a compiled main with a list of tests: mtlx (7 transformers): 2 min 52 sec mtl (RWST): 0 min 13 sec It's frustrating to see such a huge performance gap for a better design. Regards, Sean [1] http://splonderzoek.blogspot.com/2011/03/draft-type-changing-program-improvement.html [2] http://hackage.haskell.org/package/mtlx [3] http://www.ittc.ku.edu/~marks/cgi-bin/pubs/monadfactory.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: DocTest-0.2.0
I just uploaded a new version of DocTest[1] to Hackage. WHAT IS DocTest? DocTest is a port of Python's doctest[2] to Haskell. It can be used to verify, that examples in Haddock comments[3] do still work. This also provides you with a simple mechanism to write unit test, without the burden of maintaining a dedicated test suite. A basic example of usage is at [4]. WHAT'S NEW IN THIS VERSION? === Support for blank lines in the result of an expression (analogous to the -feature of Python's doctest). Here is an example of usage: -- | -- Some example: -- -- >>> putStrLn "foo\n\nbar" -- foo -- -- bar Currently this is implemented in DocTest, but we will move it to Haddock with the next release. Cheers, Simon [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/DocTest [2] http://docs.python.org/library/doctest.html [3] http://www.haskell.org/haddock/doc/html/ch03s08.html#id566093 [4] http://haskell.org/haskellwiki/DocTest ___ 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
Re: [Haskell-cafe] 'Progress bar' enumeratee
As a side note, even though GHC seems to handle this properly, I would force the value of 'i' before passing data to the continuation. Otherwise a less smart compiler may eat memory. I believe, it can only eat memory proportional to 'n', but nevertheless real constant space is better: seq i $ k ch >>== (\step -> printDots >> loop i step) Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'Progress bar' enumeratee
"David Hotham" wrote: > I did have a version along those lines at some point, but I felt it > was cheating rather to print the dots not at the correct point in the > stream. > > Perhaps I've over-complicated for the sake of the learning experience, > but I do like to have a version that passes on the correct number of > bytes, then prints the ".", and then continues. Well, then just do the printing after calling the continuation: dotsAt :: forall b m. MonadPeelIO m => Int -> Enumeratee ByteString ByteString m b dotsAt n = loop 0 where loop :: Int -> Enumeratee ByteString ByteString m b loop i' step@(Continue k) = continue go where go :: Stream ByteString -> Iteratee ByteString m (Step ByteString m b) go EOF = return step go ch@(Chunks strs) = do let (numDots, i) = divMod (i' + sum (L.map BC.length strs)) n printDots = tryIO $ BC.putStr (BC.replicate numDots '.') >> hFlush stdout k ch >>== (\step -> printDots >> loop i step) loop i' step = return step By the way, after trying out the code, I found that you should use hFlush after printing. Otherwise you may see the dots delayed. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'Progress bar' enumeratee
Thanks for the reply.
I did have a version along those lines at some point, but I felt it was
cheating rather to print the dots not at the correct point in the stream.
Perhaps I've over-complicated for the sake of the learning experience, but I
do like to have a version that passes on the correct number of bytes, then
prints the ".", and then continues.
David
"Ertugrul Soeylemez" wrote in message
news:20110406163105.13cbc...@angst.streitmacht.eu...
"David Hotham" wrote:
I've spent some time over the last couple of days trying to write an
enumeratee that prints a "." every n bytes (with obvious intended use
as a progress tracker). Seems like it oughtn't be hard, but it has
been a steep learning curve...
I have come up with something that seems to do the job but I don't
know that I'm completely happy with it (or even that I completely
understand it, to be honest).
If anyone more expert would be kind enough either to reassure me that
I'm doing it right or - more likely - to offer improvements /
suggestions on what obvious simplifications I have overlooked, I'd be
grateful.
I think that using lazy bytestrings does not have any advantage here,
since the enumerator creates the strict bytestrings at some point, then
your enumeratee converts them into lazy ones just for counting. Just
use the straightforward approach: Take the chunks and count the bytes
like here:
{-# LANGUAGE ScopedTypeVariables #-}
dotsAt :: forall b m. MonadPeelIO m =>
Int -> Enumeratee ByteString ByteString m b
dotsAt n =
loop 0
where
loop :: Int -> Enumeratee ByteString ByteString m b
loop i' step@(Continue k) =
continue go
where
go :: Stream ByteString ->
Iteratee ByteString m (Step ByteString m b)
go EOF = return step
go ch@(Chunks strs) = do
let (numDots, i) = divMod (i' + sum (L.map BC.length strs))
n
tryIO $ BC.putStr (BC.replicate numDots '.')
k ch >>== loop i
loop i' step = return step
I think, this is about the most straightforward and also the fastest
approach.
Greets,
Ertugrul
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'Progress bar' enumeratee
"David Hotham" wrote:
> I've spent some time over the last couple of days trying to write an
> enumeratee that prints a "." every n bytes (with obvious intended use
> as a progress tracker). Seems like it oughtn't be hard, but it has
> been a steep learning curve...
>
> I have come up with something that seems to do the job but I don't
> know that I'm completely happy with it (or even that I completely
> understand it, to be honest).
>
> If anyone more expert would be kind enough either to reassure me that
> I'm doing it right or - more likely - to offer improvements /
> suggestions on what obvious simplifications I have overlooked, I'd be
> grateful.
I think that using lazy bytestrings does not have any advantage here,
since the enumerator creates the strict bytestrings at some point, then
your enumeratee converts them into lazy ones just for counting. Just
use the straightforward approach: Take the chunks and count the bytes
like here:
{-# LANGUAGE ScopedTypeVariables #-}
dotsAt :: forall b m. MonadPeelIO m =>
Int -> Enumeratee ByteString ByteString m b
dotsAt n =
loop 0
where
loop :: Int -> Enumeratee ByteString ByteString m b
loop i' step@(Continue k) =
continue go
where
go :: Stream ByteString ->
Iteratee ByteString m (Step ByteString m b)
go EOF = return step
go ch@(Chunks strs) = do
let (numDots, i) = divMod (i' + sum (L.map BC.length strs)) n
tryIO $ BC.putStr (BC.replicate numDots '.')
k ch >>== loop i
loop i' step = return step
I think, this is about the most straightforward and also the fastest
approach.
Greets,
Ertugrul
--
nightmare = unsafePerformIO (getWrongWife >>= sex)
http://ertes.de/
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 'Progress bar' enumeratee
An error slipped into the version below. The line: E.checkDone (E.continue . dotIn (count - len)) should read E.checkDone (E.continue . dotIn (need - len)) "David Hotham" wrote in message news:inhd6m$h2n$1...@dough.gmane.org... Hello, I've spent some time over the last couple of days trying to write an enumeratee that prints a "." every n bytes (with obvious intended use as a progress tracker). Seems like it oughtn't be hard, but it has been a steep learning curve... I have come up with something that seems to do the job but I don't know that I'm completely happy with it (or even that I completely understand it, to be honest). If anyone more expert would be kind enough either to reassure me that I'm doing it right or - more likely - to offer improvements / suggestions on what obvious simplifications I have overlooked, I'd be grateful. Thanks David import qualified Data.ByteString.Char8 as B import qualified Data.ByteString.Lazy.Char8 as BL import qualified Data.Enumerator as E import qualified Data.Enumerator.Binary as EB import Control.Monad.IO.Class (liftIO, MonadIO) import System.IO (hFlush, stdout) dotEvery :: MonadIO m => Integer -> E.Enumeratee B.ByteString B.ByteString m b dotEvery count = E.checkDone $ E.continue . dotIn count where dotIn need k E.EOF = E.yield (E.Continue k) E.EOF dotIn need k (E.Chunks []) = E.continue (dotIn need k) dotIn need k (E.Chunks xs) = iter where lazy = BL.fromChunks xs len = toInteger $ BL.length lazy iter = if len < need then k (E.Chunks xs) E.>>== E.checkDone (E.continue . dotIn (count - len)) else let (x1, x2) = BL.splitAt (fromInteger need) lazy s1 = E.Chunks $ BL.toChunks x1 s2 = E.Chunks $ BL.toChunks x2 enumee = E.checkDoneEx s2 (\k' -> dotIn count k' s2) in E.Iteratee $ do newStep <- E.runIteratee $ k s1 liftIO $ putStr "." >> hFlush stdout E.runIteratee $ enumee newStep PS Implementations which involve "EB.take count" seem to me unsatisfactory; one surely oughtn't need to have a large buffer to solve this problem PPS I did find an implementation via mapAccumM which I consider pleasing enough from an aesthetic point of view - but which runs 30x slower dotAt :: MonadIO m => Integer -> Integer -> Word8 -> m (Integer, Word8) dotAt n s w | s >= n= do liftIO $ putStr "." >> hFlush stdout return (1, w) | otherwise = return (s+1, w) dotEvery' :: MonadIO m => Integer -> E.Enumeratee B.ByteString B.ByteString m b dotEvery' n = EB.mapAccumM (dotAt n) 1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] 'Progress bar' enumeratee
Hello, I've spent some time over the last couple of days trying to write an enumeratee that prints a "." every n bytes (with obvious intended use as a progress tracker). Seems like it oughtn't be hard, but it has been a steep learning curve... I have come up with something that seems to do the job but I don't know that I'm completely happy with it (or even that I completely understand it, to be honest). If anyone more expert would be kind enough either to reassure me that I'm doing it right or - more likely - to offer improvements / suggestions on what obvious simplifications I have overlooked, I'd be grateful. Thanks David import qualified Data.ByteString.Char8 as B import qualified Data.ByteString.Lazy.Char8 as BL import qualified Data.Enumerator as E import qualified Data.Enumerator.Binary as EB import Control.Monad.IO.Class (liftIO, MonadIO) import System.IO (hFlush, stdout) dotEvery :: MonadIO m => Integer -> E.Enumeratee B.ByteString B.ByteString m b dotEvery count = E.checkDone $ E.continue . dotIn count where dotIn need k E.EOF = E.yield (E.Continue k) E.EOF dotIn need k (E.Chunks []) = E.continue (dotIn need k) dotIn need k (E.Chunks xs) = iter where lazy = BL.fromChunks xs len = toInteger $ BL.length lazy iter = if len < need then k (E.Chunks xs) E.>>== E.checkDone (E.continue . dotIn (count - len)) else let (x1, x2) = BL.splitAt (fromInteger need) lazy s1 = E.Chunks $ BL.toChunks x1 s2 = E.Chunks $ BL.toChunks x2 enumee = E.checkDoneEx s2 (\k' -> dotIn count k' s2) in E.Iteratee $ do newStep <- E.runIteratee $ k s1 liftIO $ putStr "." >> hFlush stdout E.runIteratee $ enumee newStep PS Implementations which involve "EB.take count" seem to me unsatisfactory; one surely oughtn't need to have a large buffer to solve this problem PPS I did find an implementation via mapAccumM which I consider pleasing enough from an aesthetic point of view - but which runs 30x slower dotAt :: MonadIO m => Integer -> Integer -> Word8 -> m (Integer, Word8) dotAt n s w | s >= n= do liftIO $ putStr "." >> hFlush stdout return (1, w) | otherwise = return (s+1, w) dotEvery' :: MonadIO m => Integer -> E.Enumeratee B.ByteString B.ByteString m b dotEvery' n = EB.mapAccumM (dotAt n) 1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Hakyll 3.1
Hello all, I've just uploaded Hakyll 3.1.0.0 [1] to Hackage. It contains some backwards-incompatible changes (but they are really for the greater good). The most important change is the matching done in the rules DSL. What used to be written as: route "posts/*" someRoute compile "posts/*" someCompiler Is now written as: match "posts/*" $ do route someRoute compile someCompiler This new style is way more expressive, as you can define custom predicates such as: match (predicate (\i -> matches "foo/*" i && not (matches "foo/bar" i))) $ do ... For more information, see the Pattern documentation [2]. Another slight change is that the `Hakyll.Web.Tags` [3] module now uses an association list instead of a `Data.Map` -- in case you want to change the order in which tags are displayed. If you have any questions or trouble migrating, feel free to drop a mail to me or here [4] or visit us in #hakyll on Freenode. [1]: http://hackage.haskell.org/package/hakyll [2]: http://jaspervdj.be/hakyll/reference/Hakyll-Core-Identifier-Pattern.html [3]: http://jaspervdj.be/hakyll/reference/Hakyll-Web-Tags.html [4]: https://groups.google.com/forum/#!forum/hakyll Cheers, Jasper ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
