[Haskell-cafe] Split package organization (AntTweakBar, Cabal, darcs)
I'm working on a Haskell binding for AntTweakBar, a light user interface for OpenGL applications (http://www.antisphere.com/Wiki/tools:anttweakbar). I have three questions about how to organize it as a Haskell package or packages, Cabal, and darcs. First, since AntTweakBar provides support for handling events from GLUT, GLFW, and SDL, as well as customizable event handling from other sources, would it be best to divide it into four packages -- AntTweakBar (core), AntTweakBar-GLUT, AntTweakBar-GLFW, and AntTweakBar-SDL? A few other "package groups" on Hackage have taken this approach of splitting according to the user interface: for example, grapefruit-ui-gtk, reactive-glut, though not on such a large scale as I am proposing. Advantages of four packages rather than one: -- Fewer build dependencies, for example, for users who want to use just SDL and not have to install GLUT or GLFW. -- If one of the build dependencies is broken (as for example GLFW is just at the moment with the latest OpenGL), users could still build the other AntTweakBar-* packages. Disadvantages: -- More packages to install, for those who want it all. -- I might seem to be grabbing an undue share of the package namespace. And it could get way out of hand if I further split the examples from the library, making AntTweakBar-(base|GLUT|GLFW|SDL)-(lib|examples) = 8 packages! Would that be a problem? -- Possible inconvenience for the developer (see second question). Second question, assuming the four-way split is the best way to package this: my impression is that a directory can have only one cabal package file and one Setup.hs file. (http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.html, "Creating a Package") So for example I could not have, in the same directory, AntTweakBar.cabal, AntTweakBar-GLUT.cabal, etc. That means the four packages would each have to have their own directories, and it is sometimes inconvenient to be jumping back and forth between them. Any good way around that? Third question, assuming four separate directories for the four Cabal package files. Putting all four into one darcs repo (i.e., the darcs repo would have one main directory and a subdirectory for each package) seems to make it easier to coordinate development of the related packages -- for example, a single 'darcs rec -a' takes care of recording the related changes in all four subdirectories. Any reason not to do it that way? -- ___ ___ __ _ / _ \ / _ \| || | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \/\_/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Cal3D animation library
The Cal3D for Haskell project provides a partial binding to the C++ Cal3D animation library. The project homepage is http://haskell.org/haskellwiki/Cal3d_animation There are three packages available on hackage: * cal3d-0.1 is a Haskell binding to the Cal3D library itself. * cal3d-opengl-0.1 adds a few functions for using Cal3D with OpenGL. * cal3d-examples-0.1 provides a simple example based on the Cally Demo. Cal3D is a C++ library for skeletal-based character animation. It is platform-independent and independent of any particular graphics API. In fact, it does not actually render the animation, but provides hooks that the graphics API (such as OpenGL) can use to do the actual drawing. (As far as I know, though, the only graphics API available for Haskell is OpenGL.) For more information about the (C++) Cal3D library, please see * Cal3D FAQ: http://cal3d.sourceforge.net/docs/api/html/cal3dfaq.html * Cal3D Homepage: http://home.gna.org/cal3d/ -- ___ ___ __ _ / _ \ / _ \| || | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \/\_/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Multi-module scripts
As long as OtherModule is in the same directory, Main should have no trouble finding it. Do you mean like this? $ ls Greet.hs hello* $ cat hello #!/usr/bin/env runghc module Main where import Greet main = putStrLn (greet "world") $ cat Greet.hs module Greet (greet) where greet :: String -> String greet s = "hello " ++ s $ ./hello hello world Greg On 2009-Jun-26, Maurício wrote: > Is it possible to write a Haskell script that > uses a module that is also going to be interpreted? > Like, say: > > #!/usr/bin/runhaskell > > module Main (main) where > import OtherModule > main = (...) > > > > where OtherModule is available in, say, OtherModule.hs > and not in the already compiled and installed library? > > Thanks, > Maurício > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- ___ ___ __ _ / _ \ / _ \| || | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \/\_/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Linkage errors in scenegraph
Thank you very much. Adding these lines to scenegraph.cabal makes it work: other-modules: Graphics.SceneGraph.Matrix Graphics.SceneGraph.MySTM Graphics.SceneGraph.ReadImage Graphics.SceneGraph.TGA Graphics.SceneGraph.Utils I've contacted the author, who seems willing to fix the "official" package -- although he'd like to find someone else to maintain it. Greg On 2009-May-17, Sven Panne wrote: > Am Sonntag, 17. Mai 2009 01:07:55 schrieb Gregory D. Weber: > > I'd like to get the scenegraph package > > (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/scenegraph) > > to work, but am encountering linkage errors. > > [...] > > Also, I notice that in the cabal file for scenegraph, the > > list of exposed modules > > > > Exposed-Modules: Graphics.SceneGraph, > > Graphics.SceneGraph.Basic, > > Graphics.SceneGraph.Vector, > > Graphics.SceneGraph.Render, > > Graphics.SceneGraph.SimpleViewport, > > Graphics.SceneGraph.GraphViz, > > Graphics.SceneGraph.Library, > > Graphics.SceneGraph.Dump, > > Graphics.SceneGraph.Textures > > > > does not include Graphics.SceneGraph.Matrix, but that should only mean > > that I can't call functions of that module directly -- not that the > > other SceneGraph modules can't call them -- right? [...] > > That basically means that the scenegraph package is broken. ;-) Internal > modules have to be listed in "other-modules:", a section the Cabal file > doesn't contain. As a quick fix, you can add all missing modules in this > section, but this should of course be fixed in the official package, too. > > http://www.haskell.org/cabal/release/cabal-latest/doc/users- > guide/authors.html#buildinfo > > Cheers, >S. -- ___ ___ __ _ / _ \ / _ \| || | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/ \| | http://mypage.iu.edu/~gdweber/ \/\_/\___/\__/ Tel. (765) 973-8420; FAX (765) 973-8550 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Linkage errors in scenegraph
I'd like to get the scenegraph package (http://hackage.haskell.org/cgi-bin/hackage-scripts/package/scenegraph) to work, but am encountering linkage errors. I installed scenegraph 0.1.0.1 for ghc-6.10.1 on Fedora 10 Linux. # runghc Setup configure --prefix=/opt # runghc Setup build # runghc Setup install Then I created this little program based on the example at http://www.haskell.org/haskellwiki/SceneGraph (in file SGTest.hs): module Main where import Graphics.SceneGraph import Control.Monad.Identity main :: IO () main = runScene $ osgt $ myScene myScene :: OSGT Identity SceneNode myScene = cube 0.5 `colour` Green `scale` v1x 40 `translate` vy 2 <+> camera `translate` vy (-10) <+> light `translate` vz 10 Then I compiled it and got a long list of linker errors; here are the first few lines: ghc --make SGTest Linking SGTest ... /opt/lib/scenegraph-0.1.0.1/ghc-6.10.1/libHSscenegraph-0.1.0.1.a(Basic__210.o): In function `sdE1_info': (.text+0x8d): undefined reference to `scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_translateM_closure' /opt/lib/scenegraph-0.1.0.1/ghc-6.10.1/libHSscenegraph-0.1.0.1.a(Basic__210.o): In function `scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziBasic_translate_srt': (.data+0x0): undefined reference to `scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_translateM_closure' /opt/lib/scenegraph-0.1.0.1/ghc-6.10.1/libHSscenegraph-0.1.0.1.a(Basic__207.o): In function `sdDq_info': (.text+0x7e): undefined reference to `scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_scaleM_info' /opt/lib/scenegraph-0.1.0.1/ghc-6.10.1/libHSscenegraph-0.1.0.1.a(Basic__207.o): In function `scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziBasic_scale_srt': (.data+0x0): undefined reference to `scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_scaleM_closure' /opt/lib/scenegraph-0.1.0.1/ghc-6.10.1/libHSscenegraph-0.1.0.1.a(Basic__491.o):(.text+0x27): undefined reference to `__stginit_scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziUtils_' Also with this command, same result but a lot more detail: ghc --make -v -package scenegraph SGTest With -v, the output includes gcc -v -o SGTest -DDONT_WANT_WIN32_DLL_SUPPORT SGTest.o -L/opt/lib/scenegraph-0.1.0.1/ghc-6.10.1 -L/opt/lib/hmatrix-0.5.1.1/ghc-6.10.1 -L/opt/lib/storable-complex-0.2/ghc-6.10.1 ... -lHSscenegraph-0.1.0.1 -lHShmatrix-0.5.1.1 -lgsl -llapack -lHSstorable-complex-0.2 -lHSQuickCheck-1.2.0.0 ... which seems to show that the proper -L and -l options are included. If I'm decoding the first "undefined reference" symbol -- (.text+0x8d): undefined reference to `scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_translateM_closure' -- correctly, then the missing symbol is in the scenegraph-0.1.0.1 package, in module Graphics.SceneGraph.Matrix, and is associated with the translateM function defined in that module. I looked for this symbol with nm: # pwd /opt/lib/scenegraph-0.1.0.1/ghc-6.10.1 # nm HSscenegraph-0.1.0.1.o | grep translateM U scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_translateM_closure U scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_translateM_info # nm libHSscenegraph-0.1.0.1.a | grep translateM U scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_translateM_closure U scenegraphzm0zi1zi0zi1_GraphicsziSceneGraphziMatrix_translateM_info but I understand the "U" means that it is referenced by some other function in these files, but is undefined in them. Since the module Graphics.SceneGraph.Matrix does not declare any exports, I thought that might be the reason the symbol was undefined. But looking back at the Haskell 98 language definition, I found that the absence of an export declaration in a module means that all the symbols of the module are exported. Also, I notice that in the cabal file for scenegraph, the list of exposed modules Exposed-Modules: Graphics.SceneGraph, Graphics.SceneGraph.Basic, Graphics.SceneGraph.Vector, Graphics.SceneGraph.Render, Graphics.SceneGraph.SimpleViewport, Graphics.SceneGraph.GraphViz, Graphics.SceneGraph.Library, Graphics.SceneGraph.Dump, Graphics.SceneGraph.Textures does not include Graphics.SceneGraph.Matrix, but that should only mean that I can't call functions of that module directly -- not that the other SceneGraph modules can't call them -- right? So, why is this symbol undefined? And how can I get it to work? Oh by the way: I can actually use this package if I move into its src directory, add a main function to Examples.hs, and compile and run it right there. Just can't use it as an installed library, it seems. -- ___ ___ __ _ / _ \ / _ \| || | Gregory D. Weber, Associate Professor / /_\// / | | | /\ | | Indiana University East / /_\\/ /__| | |/
