- Haskell-Cafe - Haskell.org

ANN: mecha-0.1.0
by Tom Hawkins 08 Jun '11

08 Jun '11

Mecha [1,2] is a constructive solid geometry (CSG) modeling language embedded in Haskell. This release adds OpenSCAD [3] as a backend target. OpenSCAD is a solid modeling DSL and a viewer. OpenSCAD uses OpenCSG [4] for rendering, which directly renders CSG objects with OpenGL without the need for complex mesh generation. (Thanks Corey, for pointing me to OpenCSG.) Here is a screenshot of OpenSCAD rendering a Mecha solid: http://tomahawkins.org/index.html#Mecha Here is the Mecha source: https://github.com/tomahawkins/mecha/blob/master/Language/Mecha/Examples/CS… -Tom [1] http://hackage.haskell.org/package/mecha [2] https://github.com/tomahawkins/mecha [2] http://www.openscad.org/ [3] http://opencsg.org/

1 0

Parallel GHC project: new opportunity for an organisation to participate
by Duncan Coutts 08 Jun '11

08 Jun '11

GHC HQ and Well-Typed are pleased to announce a new opportunity for an organisation to take part in the Parallel GHC Project. The project started in November 2010 with four industrial partners, and consulting and engineering support from Well-Typed. Each organisation is working on its own particular project making use of parallel Haskell. The overall goal is to demonstrate successful use of parallel Haskell and along the way to apply engineering effort to any problems with the tools that the partner organisations might run into. We have capacity to support another partner organisation for the remaining duration of the project (at least another 12 months). Organisations do not need to contribute financially but should be prepared to make a significant commitment of their own time. Familiarity with Haskell would be helpful, but Haskell expertise is not needed. Partner organisations' choice of projects is similarly open-ended and could be based on anything from pre-existing code bases to green field endeavours. We would welcome organisations interested in pure parallelism, concurrency and/or distributed Haskell. Presently, two of our partner organisations are using mainly pure parallelism and two are using concurrency. What would be especially interesting for us is to diversify this mix further by working with an organisation interested in making use of of distributed Haskell, in particular the work highlighted in the recent paper "Haskell for the Cloud" [1]. To help give an idea what participating in the Parallel GHC Project is like, here is what some of what our current partner organisations have to say: The Parallel GHC Project has enabled us to make steady progress towards our goals. Well-typed has provided support in the form of best practice recommendations, general engagement with the project, and directly coding up key components. I have been getting lots of help from Well-Typed, and enjoy our weekly meetings. -- Finlay Thompson, Dragonfly My organization is now trying to implement highly concurrent Web servers. After GHC 7 was released we faced several critical bugs in the new IO manager and one guy at Well-Typed kindly fixed all the bugs. This has been a big benefit for our organization. Another benefit is feedback/suggestions from Well-Typed. Well-Typed and our organization have meetings every other week and we report progress to each other. During the discussions, we can set the right direction to go in. -- Kazu Yamamoto, IIJ Innovation Institute Inc. Well-Typed is coordinating the project, working directly with the participating organisations and the Simons at GHC HQ. If you think your organisation may be interested then get in touch with me via info(a)well-typed.com [1] http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/remot… -- Duncan Coutts, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

haskellwiki slow/unresponsive
by Greg Weber 08 Jun '11

08 Jun '11

> > Those are definitely valid concerns. Has anyone made a wiki-like site with > Yesod? I hadn't heard of Yesod until I joined this mailing list, but I've > seen quite a bit of buzz around it since then. If a large enough chunk of > the community is backing a framework and focusing on making it secure and > reliable, then it should be possible to build applications with it (wikis, > blogs, etc.) that draw on the framework's strength and security. You may > still have security issues, but if they're continually addressed and > maintained at the framework level it benefits everyone building > applications > on top of that framework. I'm still relatively new to the Haskell > community > so I apologize if much of this has been addressed before! It is dead-simple to deploy a fast haskell web app, so haskell *might* have a chance at solving the problem, but likely it can be fixed much faster by doing a better job configuring the server or adding more resources. I think that security issues are a bit of a red herring. You can go through potential security issues one-by-one and basically make them impossible in a web/wiki framework (as we are doing in Yesod). Of course this is easier to do with a type system in Haskell. And of course some security is outside the scope of the software and needs to be established by procedure (admin server access should only be through ssh key, etc). Gitit uses darcs or git to store data, but through the command line interfaces. Unfortunately to my knowledge darcs does not expose a library interface. Gitit could be made faster and more secure by interfacing with libgit2. Even though it is may not be socially acceptable to state it, it is likely that gitit or any haskell library would be more secure in practice because it is more obscure. And the kind of security we really care about in the wiki- the wiki page content- can be easily replicated and restored. I definitely agree that the hard and boring part of switching to a haskell wiki is converting existing MediaWiki content and configuration to a new system- that would have to be investigated first. Unfortunately this is probably all bike-shedding and my original question of how can the community speed up the wiki hasn't been answered :) Greg Weber

3 2

Does this library already exist? template haskell + generate/compile C code + dlopen
by Ryan Newton 08 Jun '11

08 Jun '11

The Nikola GPU programming system has a very neat, flexible approach to how you compile the EDSL-generated code. You can do it dynamically, calling nvcc at runtime, OR it can play a trick where it calls nvcc at compile time (via template haskell) and caches the result in a string literal within the TH-generated Haskell code. That is a pretty cool trick IMHO. Moreover, we can do that with any tool that generates C code or native code, as follows: At compile time, via Template Haskell: 1. call tool which creates C code 2. create temp files and call C compiler 3. load resulting object file as a bytestring and store it as a string constant Then at runtime: 1. put bytestring back into a file 2. call dlopen 3. call dlsym, get FunPtr, voila! Anyway, I was going to put together a simple library that encapsulates the above steps. Such a library could be used, for example, in making this stencil compiler project <http://people.csail.mit.edu/yuantang/> available to Haskell users as well as C++ users. (The compiler is written in Haskell already anyway!) But first I thought I'd ask if this already exists. Also, is there a better way to do it? In particular, is there any way to get static linking to work, rather than the silliness with strings, tempfiles, and dlopen. Thanks, -Ryan

1 0

Proposal: remove "Stability" from haddock documentation on hackage
by Chris Smith 08 Jun '11

08 Jun '11

I got asked a question today about why Control.Applicative is labeled as "experimental" on Hackage. Perhaps that field is something of a failed experiment, and it remaining there is likely to confuse people. Just a thought... not sure of the best place to mention it. -- Chris Smith

9 11

Local Haskell Meeting (Stammtisch) Leipzig, Germany, June 27
by Johannes Waldmann 08 Jun '11

08 Jun '11

Informal Haskell Stammtisch on Monday, June 27, 8 p.m., at Cafe Grundmann, Leipzig, Germany. http://www.cafe-grundmann.de/ Pre-registration (by email to me) is appreciated. Please bring ideas for our local Haskell Workshop (planned for end of September). See you - J.W.

1 0

Twidge and identi.ca
by Mats Rauhala 08 Jun '11

08 Jun '11

Does twidge still support identi.ca? I was able to auth, but after that every single command returns 'twidge: user error (Bad response: 404)'. The commands work for twitter. -- Mats Rauhala MasseR

1 0

Comment Syntax
by Guy 08 Jun '11

08 Jun '11

-- followed by a symbol does not start a comment, thus for example, haddock declarations must begin with -- |, and not --|. What might --| mean, if not a comment? It doesn't seem possible to define it as an operator.

20 40

haskell platform question
by Tim Docker 08 Jun '11

08 Jun '11

I'd like to build the haskell platform against a recent GHC snapshot, for testing purposes. I see that I can download the source for the platform from: http://lambda.galois.com/hp-tmp/2011.2.0.1/haskell-platform-2011.2.0.1.tar.… with instructions: http://www.vex.net/~trebla/haskell/haskell-platform.xhtml However when I tried this some months ago, I found that some of the packages in the above source fail to build due to recent ghc changes (eg it's stricter handling of bang patterns). Is there a more recent "beta" snapshot of the platform? Or a darcs/git repo somewhere? I imagine wanting to build the platform against bleeding edge ghc would be a pretty common desire. Tim

4 6

HUnit false-positive stumper
by KQ 08 Jun '11

08 Jun '11

While working on a project of mine recently I realized that a particular HUnit test should have been failing. After paring things down, I came up with this shocker: test_perhaps.hs: > module Main where >import Test.HUnit >main = runTestTT $ TestList [ True ~=? True > , False ~=? True > , TestCase $ assertEqual "both true" True True > , TestCase $ assertEqual "false true" False True > ] $ cabal-dev install ... $ ./cabal-dev/bin/test_perhaps.hs ### Failure in: 3 false true expected: False but got: True Cases: 4 Tried: 4 Errors: 0 Failures: 1 The shock here is that there was only one failure, whereas the "False ~=? True" should have failed. Environment: MacOS 10.5.8 (Leopard) GHC 6.12.3 cabal-dev 0.7.4.1 Cabal 1.10.1.0 HUnit 1.2.2.3 I even tried removing the dist and cabal-dev directories and reattempting but got the same results. I tried the same test in a different environment (Linux PC w/GHC 7.0.2, all other elements the same) and got correct results: $ ./cabal-dev/bin/test_perhaps ### Failure in: 1 expected: False but got: True ### Failure in: 3 false true expected: False but got: True Cases: 4 Tried: 4 Errors: 0 Failures: 2 $ I realize it's very difficult to debug someone's setup remotely, but I have to confess I'm really stumped at this point. The input program is pretty straightforward, and I *have* gotten test failures in the past on the Mac. I did do a "cabal update" the other day after being informed that my hackage file was getting old, but HUnit hasn't changed in months. I even tried unpacking HUnit and reducing the (non-)failing test case by using the definitions of the elements: > module Main where > > import Control.Monad (unless) > import Test.HUnit > > main = runTestTT $ TestList [ True ~=? True > , False ~=? True > , TestCase $ assertEqual "both true" True True > , TestCase $ assertEqual "false true" False True > , TestCase $ assertEqual "fa" False True > , TestCase $ assertEqual "f" False True > , TestCase $ (False @?= True) > , TestCase $ unless (False == True) (assertFailure "f") > ] The results are very strange: $ ./cabal-dev/bin/test_perhaps ### Failure in: 3 false true expected: False but got: True ### Failure in: 4 fa expected: False but got: True ### Failure in: 7 f Cases: 8 Tried: 8 Errors: 0 Failures: 3 $ The assertEqual form doesn't fail as it should if the label is a single character (test 5), but in its fully expanded form (test 7) it will fail. Huh?! At this point I'm thoroughly confused. I'm using 6.12.3 on the Mac because I don't have the newer MacOS release for which there's a Haskell Platform release and I haven't wanted to build GHC by hand. I wouldn't expect 6.12.3 to have issues like this, but I wouldn't expect issues like this anywhere. If anyone has any suggestions (other than upgrading to GHC 7.x) I'll be most appreciative. -- -KQ

4 6