- Haskell-Cafe - Haskell.org

performance difference for binary-0.4.3.1 with ghc-6.8.3 and ghc-6.10
by John Lato 08 Nov '08

08 Nov '08

Hello, I was experimenting with using ghc-6.10.0.20081007 on a project, and it seems that binary-0.4.3.1 has markedly worse performance in certain cases. With the following simple test: > import qualified Data.ByteString.Lazy as L > import Data.Binary > import Data.Binary.Get > import Control.Monad > > main :: IO () > main = do > b <- L.readFile "some_binary_file" > putStrLn $ show $ runGet getter b > getter :: Get [Word16] > getter = replicateM 1000000 getWord16le running this program compiled with ghc-6.10 takes about 4 times as long (and consumes much more memory) as when compiled with ghc-6.8.3. The extra time appears to be proportional to the number of elements processed in the Get. Running the programs with -hT shows a clear memory difference, which I think is the source of the problem. I've placed pdfs of that output at https://webspace.utexas.edu/latojw/data/ The difference seems to manifest itself only when the elements are actually processed; changing "show $ runGet " to "show $ length $ runGet " is slightly faster in 6.10. I was working on an Intel Mac with OS 10.4, binary-0.4.3.1, and bytestring-0.9.1.4. Can anyone confirm this, or suggest what might be the difference? Thank you, John Lato

6 9

Monad.Reader with updates
by Mauricio 07 Nov '08

07 Nov '08

Hi, Is there some abstraction in current ghc library that implements something like Reader, but where the value of the environment is updated at every "step"? I imagine something that instead of running like this: runReader ( do ... ) environment I would run like: runReader ( do ... ) environment update_function So, when I write a monad like: do a <- asks f b <- asks f2 c <- asks f3 f, f2 and f3 would be called with parameters environment, (update_function environment), (update_function . updatefunction $ environment) etc. Does that make sense? Is it easy to adapt something already existing to do that? Thanks, Maurício

7 12

Problems with strictness analysis?
by Patai Gergely 07 Nov '08

07 Nov '08

Hi everyone, I was experimenting with simple accumulator functions, and found that an apparently tail recursive function can easily fill the stack. Playing around with ghc and jhc gave consistently unpleasant results. Look at this program: %%%%%%%%%%% -- ghc: no, ghc -O3: yes, jhc: no isum 0 s = s isum n s = isum (n-1) (s+n) -- ghc: no, ghc -O3: no, jhc: yes (because gcc -O3 is clever) rsum 0 = 0 rsum n = n + rsum (n-1) main = case isum 10000000 0 {- rsum 10000000 -} of 0 -> print 0 x -> print x %%%%%%%%%%% I would expect the analysis to find out that the result of the function is needed in every case (since we are matching a pattern to it), yet I need to add a $! to the recursive call of isum to get a truly iterative function. It's interesting how ghc and jhc seem to diverge, one favouring the "iterative" version, the other the "recursive" one (although it only works because gcc figures out that the function can be expressed in an iterative way). Of course this is a real problem when I'm trying to write an actual program, since it means I can be bitten by the laziness bug any time... Is there any solution besides adding strictness annotations? Can I expect the compiler to handle this situation better in the foreseeable future? Gergely -- http://www.fastmail.fm - IMAP accessible web-mail

17 35

Anyone know why this always returns invalid texture objects?
by Jefferson Heard 07 Nov '08

07 Nov '08

import Graphics.UI.Gtk import Graphics.UI.Gtk.Glade import Graphics.UI.Gtk.OpenGL import qualified Graphics.Rendering.OpenGL as GL import Graphics.Rendering.OpenGL (($=)) main = do initGUI initGL GL.shadeModel $= GL.Flat GL.depthFunc $= Just GL.Less (window1,gui,dlgs) <- constructGUIObject (sX, sY) <- liftM (mapPair fromIntegral) . widgetGetSize . drawing_canvas $ gui -- get the canvas size for determining the part of the widget to repaint pb <- pixbufNew ColorspaceRgb False 8 (round pbWidth) (round pbHeight) pixbufFill pb 0 0 0 255 pxbufs <- initSubpixbufs pb texRows texCols textures <- GL.genObjectNames (texRows*texCols) print textures -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards

2 2

Problem compiling hdbc with GHC 6.10.1 in windows
by PJ Durai 07 Nov '08

07 Nov '08

Greetings I would like to report that I am not able to compile hdbc 1.1.5.0. $ runghc.exe Setup.lhs build Preprocessing library HDBC-1.1.5... Building HDBC-1.1.5... [1 of 6] Compiling Database.HDBC.ColTypes ( Database\HDBC\ColTypes.hs, dist\build\Database\HDBC\ColTypes.o ) [2 of 6] Compiling Database.HDBC.Statement ( Database\HDBC\Statement.hs, dist\build\Database\HDBC\Statement.o ) [3 of 6] Compiling Database.HDBC.Types ( Database\HDBC\Types.hs, dist\build\Database\HDBC\Types.o ) [4 of 6] Compiling Database.HDBC.DriverUtils ( Database\HDBC\DriverUtils.hs, dist\build\Database\HDBC\DriverUtils.o ) [5 of 6] Compiling Database.HDBC.Utils ( Database\HDBC\Utils.hs, dist\build\Database\HDBC\Utils.o ) Database\HDBC\Utils.hs:51:11: Not in scope: `catchDyn' Database\HDBC\Utils.hs:55:16: Not in scope: `catchDyn' Database\HDBC\Utils.hs:60:18: Not in scope: `dynExceptions' Environment: Windows XP SP2 GHC 6.10.1 thanks pj I had no problems compiling this with GHC 6.8.

3 3

Re: [Haskell] ANNOUNCE: Haddock version 2.4.0
by Thomas Schilling 06 Nov '08

06 Nov '08

[Redirecting to cafe@ since haskell@ is not meant for discussions] Sure, they are bad for one reason: you cannot link to a frame configuration directly. However, for this particular use case they are quite handy. There are some features missing (like hoogle integration) and some annoyances (if javascript is enabled, we show both a mini-synopsis, but this interacts badly with the back-button.) You can simulate this if you add a lot more javascript, have some kind of server, generate many more static pages, or use some CSS magic. But the implemented solution works and is reasonably useful. If someone wants to improve this I certainly don't mind. 2008/11/6 Wolfgang Jeltsch <g9ks157k(a)acme.softbase.org>: > Am Donnerstag, 6. November 2008 00:21 schrieb David Waern: >> * Add framed view of the HTML documentation > > After many years with many people telling us that frames are bad, you add > frame support to Haddock? Hmm. > > Best wishes, > Wolfgang > _______________________________________________ > Haskell mailing list > Haskell(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell >

1 0

Writing an IRC bot, problems with plugins
by Alexander Foremny 06 Nov '08

06 Nov '08

Hello, Community. I already bothered #haskell a few times with the very same problem and always got interesting responses. But I seem to have always simplified my problem too much ending up with an helpful answer to my (simplified) problem, but not with a real solution. Thus I'm giving the mailing list a try where I don't feel like having to wrap up my concerns in as few lines as possible. I am writing an single server, multi channel IRC bot with the support of plugins and limited plugin communication. With the plugin system I am facing problems I cannot really solve myself. My general idea is to have the main application listening to the network socket and then calling all the plugins on each incoming message. Therefore I maintain a list of plugin states in the main application's state and on each incoming message I call a function which modifies the plugin's state. There's a PluginClass class which contains definitions of functions for each plugin which they all share. Simplyfied it's like this: type PL = StateT PluginConfig class PluginClass a where identifier :: a -> String rawMessage :: (MonadIO m) => a -> Message -> PL m () So plugins can be identified uniquely using the identifier function and they can respond to messages using the rawMessage function. This function is executed in the PL monad, which is essentially a StateT monad for updating the plugin's state trough put and maybe accessing a few data fields from the underlying Bot monad in which the main application is operating. Then again I want to be able to query a plugin's state from a different plugin. For instance I'll have a plugin which keeps track of the channels the bot has joined collecting user information, the topic, etc. Another plugin could then query the "chan info" plugin and get all the users in a certain channel through a queryPlugin function which takes a plugin and looks that plugin up in the main application's plugin state list for the right state and then calls a function on it. The plugin and the corresponding functions would be exported by the plugin's module. queryPlugin :: (PluginClass a) => a -> (a -> b) -> PL m b queryPlugin pl f = do plugins <- getGlobalPlugins -- ideally (PluginClass a) => [a] let pluginNames = map identifier plugins targetName = identifier pl [(_, target)] = filter ((==) targetName . fst) (zip pluginNames plugin) return (f target) But here I am facing either one or the other problem, depending on the "solution." 1) I somehow have to store all the plugin states in the main application. Since plugins are essentially their states, they are quite arbitrary. I either cannot use a list for that or I have to use existential types which would make that possible. 2) Using an existential plugin type would restrict the functions I am able to call on the plugin to those which are supported by the PluginClass. This would render queryPlugin unusable since the functions a plugin exports for query the state are arbitrary. 3) I could use Dynamics to store the plugin in a list *and* call arbitrary functions, but then again how would I run a plugin? All the main application know about the plugin state is that all the functions defined by PluginClass are callable on the state. But the type (PluginClass a) => a isn't enough to unwrap the Dynamic, apply the function and wrap it again. Another suggestion was to not use a class but make each plugin a record, exporting the functions itself. Though I haven't given that a serious thought, it seems not ideal to me. Using a class a plugin can define the functions it actually uses. In my real code, they're about 12 functions the class exports and there could be more. Using a record I would have to implement all possible functions even though they're not changing the plugin's state nor causing side effects. The most obvious solution would be to use an algebraic data type with a constructor for each plugin. But I'd like to develop the plugins independent from the core and I'd like to make them more dynamic than that, maybe implementing dynamic loading of plugins at some time. Then there are two other potential solutions, but I haven't looked into them seriously since they seemed a little hackish to me at first glance. One would be using Hlist (which seems to be over-sized for my problem as well) and another would be to store a tupel of (Dynamic, (PluginClass a) => (Dynamic -> a)) as plugin state list where the first element would be the plugin's state wrapped in a dynamic and the second a unwrap function exported by the plugin's module. I *might* get around the problem of being to unspecific about the type when unwrapping, but this idea came only at the point of writing this email and I would expect running into the same problems I have: It can be achieved by either being too general or being to specific. Hopefully I've explained everything well enough while not being too long with all this. Thanks in advance for your help!

3 2

pure programs
by Jason Dusek 06 Nov '08

06 Nov '08

Informally, a "pure program" an executable such that the stream of bytes entering it totally determines the stream of bytes leaving it. Many useful programs that I would like to write in Haskell don't fall into this category -- for example, network servers -- but a lot of their components do. Can these components can be Haskell functions without IO in their signatures? Though that seems reasonable, it is not, in general, true. For example, System.Info.os is generally treated as pure, though it is not. It's not clear to me how to disambiguate these "born again" values from really pure values. -- _jsn

9 10

ghc-6.11 + OpenGL/GLUT crashes on WinXP
by Conal Elliott 06 Nov '08

06 Nov '08

I'm getting crashes from ghc-6.10.0.20081007 and ghc-6.11.20081024 when doing a very simple GLUT program (below) with OpenGL-2.2.1.1 and GLUT-2.1.1.2 (the latest from Hackage), running on WinXP. It works fine on ghc-6.9.20080622 . I'd appreciate hearing about other attempts with these versions on Windows systems. Thanks, - Conal import Graphics.UI.GLUT main :: IO () main = do putStrLn "Initializing" getArgsAndInitialize return ()

6 9

[Haskell-cafe] http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-Simple.html
by Mauricio 06 Nov '08

06 Nov '08

Hi, According to this page: http://www.haskell.org/ghc/docs/latest/html/libraries/Cabal/Distribution-Si… there's an available toplevel declaration named: autoconfUserHooks in Distribution.Simple. However: ghci --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 ghci Prelude> :m +Distribution.Simple Prelude Distribution.Simple> :t autoconfUserHooks <interactive>:1:0: Not in scope: `autoconfUserHooks' What would the experienced Haskell programmer do in such situation? Is there some way to ask ghci (or ghc) to list all available declarations, in a way that I could '| grep' it or save it to a file? Can I ask ghci to look for a declaration inside all available modules in all available packages? Thanks, Maurício

4 3