November 2008 - Haskell-Cafe

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

06 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 06 Nov '08

06 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

ANNOUNCE: Haddock version 2.4.0
by David Waern 06 Nov '08

06 Nov '08

-------------------------------------------- -- Haddock 2.4.0 -------------------------------------------- A new version of Haddock, the Haskell documentation tool, is out. This is a later version than the one shipped with GHC 6.10.1, which is version 2.3.0. That version will not be released on Hackage since it only builds with GHC 6.10.1 (by accident, actually). Besides adding back support for earlier GHC versions, this release contains some more fixes and support for HTML frames. Please use the bug tracker to submit bug reports or feature requests. -------------------------------------------- -- Changes in version 2.4.0 -------------------------------------------- * Add framed view of the HTML documentation * Build with GHC 6.8.2 and 6.8.3 again * Support images in documentation comments again * Small improvements to the Hoogle output * A few bugs has been fixed -------------------------------------------- -- Changes in version 2.3.0 -------------------------------------------- * Support for GHC 6.10.1 * Slightly improved space usage * Fix a bug that made hidden modules show up in the contents & index pages * Fix a bug that made Haddock load modules twice * Improvements to the Hoogle output -------------------------------------------- -- Links -------------------------------------------- Homepage: http://www.haskell.org/haddock Hackage page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/haddock-2.4.0 Bugtracker and wiki: http://trac.haskell.org/haddock Mailing list: haskelldoc(a)haskell.org Code repository: http://code.haskell.org/haddock -------------------------------------------- -- Contributors -------------------------------------------- The persons who contributed to the 2.3.0 and 2.4.0 releases are: Clemens Fruhwirth Peter Gavin Ian Lynagh Neil Mitchell Luke Plant Thomas Schilling David Waern -------------------------------------------- -- Get Involved -------------------------------------------- We welcome new contributors. To get involved, start by grabbing the code: http://code.haskell.org/haddock Then take a look at the bug and feature tracker for things to work on: http://trac.haskell.org/haddock

2 2

Undefined symbols base_DataziTuple_ZxxxT_con_info
by dmitry shkurko 06 Nov '08

06 Nov '08

Hello everyone, I am trying to compile my program, but during the linking phase I see errors like: (.text+0x66dd7):fake: undefined reference to `base_DataziTuple_Z110T_con_info Library libHSbase.a contains symbols base_DataziTuple_ZxxxT_con_info for xxx <=62. It look like I hit some compiler limit (I used GHC 6.8.3 for compilation). Any thoughts are appreciated. Thank you, Dmitry

2 2

Efficient parallel regular expressions
by Martijn van Steenbergen 06 Nov '08

06 Nov '08

Hello all, For my mud client Yogurt (see hackage) I'm currently working on improving the efficiency of the hooks. Right now several hooks, each consisting of a regex and an action can be active at the same time. Every time a line of input is available (usually several times a second) I run the line through all the available regexes and execute the first matching action. I figured this is not the cleverest approach and it'd be better if I |'ed all regexes into one big DFA. However, how do I then find out which of the original hooks matched and so which action to execute? As far as I know there's no way to do that with Text.Regex. Alex looks promising but is really only an executable and doesn't offer an API. I've also found mr. João Saraiva's HaLex but I don't know if that was meant to be used seriously. Does anyone have any experience with this? What's the best way to achieve this? Thanks much, Martijn.

18 23