Re: [Haskell-cafe] Compiling arbitrary Haskell code
On Fri, Oct 11, 2013 at 1:30 PM, Christopher Done chrisd...@gmail.comwrote: Is there a definitive list of things in GHC that are unsafe to _compile_ if I were to take an arbitrary module and compile it? E.g. off the top of my head, things that might be dangerous: * TemplateHaskell/QuasiQuotes -- obviously * Are rules safe? * #includes — I presume there's some security risk with including any old file? * FFI -- speaks for itself It really depends on the security properties you want to maintain. That should inform your policy. For example, denial of service vs. leaking information (like password db) vs. allowing yourself to become part of a botnet. There are lots of things to consider here. For example, lambdabot has always disallowed IO and thus needs to disallow unsafeCoerce/unsafePerformIO/unsafeInterleaveIO and anything else that introduces a backdoor in the type system. I think the list you have above is a good start, but wouldn't be complete for lambdabot. I'm interested in the idea of compiling Haskell code on lpaste.org, for core, rule firings, maybe even Th expansion, etc. When sandboxing code that I'm running, it's really easy if I whitelist what code is available (parsing with HSE, whitelisting imports, extensions). The problem of infinite loops or too much allocation is fairly straight-forwardly solved by similar techniques applied in mueval. What type of sandboxing do you plan to use and what limitations does it have? For example, chroot jails can be defeated. SafeHaskell helps a lot here, but suppose that I want to also allow TemplateHaskell, GeneralizedNewtypeDeriving and stuff like that, because a lot of real code uses those. They only seem to be restricted to prevent cheeky messing with APIs in ways the authors of the APIs didn't want -- but that shouldn't necessarily be a security—in terms of my system—problem, should it? Ideally I'd very strictly whitelist which modules are allowed to be used (e.g. a version of TH that doesn't have runIO), and extensions, and then compile any code that uses them. GND can be used to cause a segfault. I don't know if it can be used to cause a more serious exploit, but I would be concerned that it can. Then again, if you're already allowing TH or arbitrary IO then those are probably much easier places to attack so it may not matter. I'd rather not have to setup a VM just to compile Haskell code safely. I'm willing to put some time in to investigate it, but if there's already previous work done for this, I'd appreciate any links. I don't know how well it's documented, but lambdabot has a long history of restricting the Haskell it accepts to make it safe. Other things to look at, google native client (to see how they approach sandboxing), and geordi the C++ IRC bot. In the native client case they do fancy tricks with segment registers (to control where the sandboxed process can write to memory) and intercepting system calls in the outer part of the process. They have the case where they do everything in one process in one address space. You could imagine porting the GHC RTS to run in native client (didn't someone start on that?) and then using that to sandbox all your Haskell evaluation. At the end of the day, there's always just supporting a subset of Haskell using SafeHaskell. I'm just curious about the more general case, for use-cases similar to my own. I think SafeHaskell is a reasonable starting place, but I don't think it gives you a really strong guarantee yet. Everything that is inferred safe probably is (I don't know of any exploits with that part of SafeHaskell). In practice, you'll probably also want to use some trusted packages, but that requires that none of the stuff your trust is exploitable. I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Logo Macbook Decal
On Tue, Oct 1, 2013 at 3:50 PM, Kyle Hanson hanoo...@gmail.com wrote: I ordered mine! Does anyone know if there is any place where I could order pre-made Haskell t-shirt that benefits haskell.org too? I don't know where, but I just wanted to say thank you to both you and Ryan and everyone else who buys one. Setting something up like this is great! And we definitely want to encourage it. So if you do find a place to order shirts (maybe cafepress?) please let us know. You might also like to know that haskell.org can now accept donations directly: http://www.haskell.org/haskellwiki/Donate_to_Haskell.org Gershom announced it at the recent Haskell Implementors Workshop and we're still working on getting the word out to a wider audience. In the future, haskell.org would like to use donations to buy dedicated development time for key bits of Haskell infrastructure. I think we'll have more to say about that in a week or two (work in progress). Thanks for your support! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Richard Bird and the fast nub function
On Sun, Sep 29, 2013 at 1:40 PM, Henning Thielemann lemm...@henning-thielemann.de wrote: In Richard Bird's Functional Pearls in Algorithm Design there is chapter 10 Removing duplicates which is about a fast and sorting variant of 'nub'. After reading the introduction of the chapter I answered mentally Set.toAscList . Set.fromList - next chapter please. However after the introduction eight pages follow that develop an efficient algorithm for the problem. I suspected there might be the additional difficulty of not using the standard Set type, however on page 70 the common Set API is imported. In the final remarks of the chapter Bird writes: A nagging doubt remains that there might be a much simpler solution to such a simply stated problem. But so far I have not been able to find one. Now I am lost. Can someone tell me, how the task differs from what Set.toAscList . Set.fromList does? I've been puzzling over this too. The most convincing answer I've come up with (and it's not very convincing) is that he presented the development because he aims to teach the process and the skill, not because it lead to a particularly efficient implementation in this case. In fact, when folks were talking about improving `nub` on here a few months ago I finally got around to benchmarking it and found that it wasn't all that efficient compared to the other proposals. I don't think I have the numbers anymore. It wasn't terrible but it wasn't amazing either. So yeah, I don't know what to make of that chapter :( Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. GLFW-b satisfies all of these. There are two caveats: a) to use it with GHCi you'll need to use ghc 7.8 (when it comes out in a week or two); b) it's really only providing an OpenGL context and none of the other traditional GUI things like widgets and font rendering. As far as GHCi compatibility is concerned, the problem there isn't with GLFW or the Haskell bindings. GHCi has been toxic to these sorts of libraries for a long time due to some bugs and limitations. In GHC 7.8, there is a change to use the system wide linker by default and that removes one hurdle. The next hurdle is to make GHCi work better with libraries that use thread local storage that is pinned to the process's original thread. You can often workaround this limitation with -fghci-no-sandbox. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. wxHaskell + GHCi is likely affected by some of the things I mention above. You should give it another try when 7.8 lands. I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] definition of the term combinator
On Fri, Aug 23, 2013 at 9:09 PM, damodar kulkarni kdamodar2...@gmail.comwrote: Hello, The word combinator is used several times in the Haskell community. e.g. parser combinator, combinator library etc. Is it exactly the same term that is used in the combinatory logic ? A combinator is a higher-order function that uses *only function application* and earlier defined combinators to define a result from its arguments. [1] It seems, the term combinator as in, say, parser combinator, doesn't have much to do with the *only function application* requirement of the combinatory logic, per se. If the above observation holds, is the term combinator as used in the Haskell community, properly defined? In other words: Where can I find a formal and precise definition of the term combinator, as a term used by the Haskell community to describe something? Good question. I believe this article addresses the points you raise: http://www.haskell.org/haskellwiki/Combinator ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative name for return
On Wed, Aug 14, 2013 at 7:54 PM, Simon Peyton-Jones simo...@microsoft.comwrote: | Indeed, I wished the 0-ary case would be more alike to the unary and | binary case, cf. | | return f0 | f1 $ a1 | f2 $ a1 * a2 | | What is needed is a nice syntax for idiom brackets. Indeed. I'm quite open to adding idiom brackets to GHC, if everyone can agree on their syntax, and someone would like to offer a patch. Something like (| f a1 a2 |) The last time I suggested this (on IRC), the first question someone asked was: How should nested uses of applicative work with idiom brackets? I think this question actually comes in two flavors: * Can you nest the brackets themselves? * How deeply do you traverse the expression to insert the applicative combinators? Also, if anyone wants to look at prior art first, Idris supports applicative brackets. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why GHC is written in Happy and not a monadic parser library?
On Sat, Aug 3, 2013 at 3:36 AM, Malcolm Wallace malcolm.wall...@me.com wrote: On 3 Aug 2013, at 02:20, Jason Dagit wrote: Hi! Is there any specific reason why GHC is written in a parser GENERATOR (Happy) and not in MONADIC PARSER COMBINATOR (like parsec)? Is Happy faster / handles better errors / hase some great features or anything else? One reason is that it predates monadic parser libraries. I'm not entirely sure this is true. I reckon the development of applicative parser combinators (used in the implementation of the nhc12 compiler, way back in 1995 or so), is roughly contemporaneous with the development of Happy, and its use inside ghc. (I found a release note from Sept 1997 that said ghc had just converted its interface-file parser to use Happy.) Certainly table-driven parsers in non-functional languages go back a lot further, and functional combinator-based parsing was then the relative newcomer. Interesting. I know the happy source has copyright dates starting in 1991, so I figured it was developed to help write ghc. Perhaps they were using it for source parsing before they adopted it for interface-file parsing in 1997? As to why ghc switched to Happy, the literature of the time suggests that generated table-driven parsers were faster than combinator-based parsers. I'm not sure I have ever seen any performance figures to back that up however. And with the general improvement in performance of idiomatic Haskell over the last twenty years, I'd be interested to see a modern comparison. Another con of using parsec that I forgot to mention in my previous email is that with Parsec you need to be explicit about backtracking (use of try). Reasoning about the correct places to put try is not always easy and parsec doesn't help you with the task. In my experience, this is the main bug that people run into when using parsec. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why GHC is written in Happy and not a monadic parser library?
On Fri, Aug 2, 2013 at 5:49 PM, blackbox.dev.ml blackbox.dev...@gmail.com wrote: Hi! Is there any specific reason why GHC is written in a parser GENERATOR (Happy) and not in MONADIC PARSER COMBINATOR (like parsec)? Is Happy faster / handles better errors / hase some great features or anything else? One reason is that it predates monadic parser libraries. Pros of parser generators: + Static analysis of the grammar (shift/reduce conflicts, debuggers, etc) + More succinct definition of grammar / semantic actions (easier to formally reason about the language) + Efficient parser generation + attribute grammars Monadic parsers are not amenable to static analysis in the same ways. Applicative parsers hypothetically do not have this limitation, but none of the applicative parsers provide static analysis. I would expect parsec to be slower than happy (although I haven't benchmarked it). The place where monadic parsers shine is when you don't know the formal grammar or you can't have one. Personally, I prefer parser generators although I think monadic parsers have their time and place. Parsec is a wonderful replacement to writing a recursive descent parser. Lately, I've been modernizing the happy source code and making it so that it better integrates with cabal. I hope this will help improve the image of happy. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ordNub
On Sun, Jul 14, 2013 at 4:20 AM, Niklas Hambüchen m...@nh2.me wrote: tldr: nub is abnormally slow, we shouldn't use it, but we do. As you might know, Data.List.nub is O(n²). (*) As you might not know, almost *all* practical Haskell projects use it, and that in places where an Ord instance is given, e.g. happy, Xmonad, ghc-mod, Agda, darcs, QuickCheck, yesod, shake, Cabal, haddock, and 600 more (see https://github.com/nh2/haskell-ordnub). I've taken the Ord-based O(n * log n) implementation from yi using a Set: ordNub :: (Ord a) = [a] - [a] ordNub l = go empty l where go _ [] = [] go s (x:xs) = if x `member` s then go s xs else x : go (insert x s) xs and put benchmarks on http://htmlpreview.github.io/?https://github.com/nh2/haskell-ordnub/blob/1f0a2c94a/report.html (compare `nub` vs `ordNub`). Richard Bird has a book, Pearls of Functional Algorithm Design that is meant to teach a form of deriving algorithms from the properties we ask of them. In this book, he gives a possible derivation of ordNub, simply called nub in the book, following the methodology he is teaching. He notes in the text that this derivation feels more complicated than it ought. Here is his version: http://lpaste.net/87625 I just sent you a pull request to add that one and S.toList . S.fromList that was suggested in this thread. I don't think those two implementations are faster than the others but it's nice to have them for completeness. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS X ghci problem
On Sat, Jul 13, 2013 at 4:39 PM, Mark Lentczner mark.lentcz...@gmail.com wrote: Bizarre - this just happened to me today, too. Anyone? Did you figure out a work around? For the record, I'm trying to bring Euterpea up. After some digging, experimenting, asking around, and head scratching my best guesses are: * GHCi's custom linker isn't doing the right thing (some versions of llvm/clang gave crashes like this and it was a linker bug for them, you can find reports on sites like StackOverflow). * We need to feed .m files to clang instead of ghc/gcc * GHCi needs to be built with Cocoa in mind (is it already?) * Some rts component of objective-c is not properly initialized (ARC vs. -fobjc-gc vs. -fnext-step, etc) My system is OS X 10.8.4, and I'm running HP 2013.2, so 7.6.3. And GLFW-0.5.1.0. What version of the xcode command line tools do you have? Anything older than 4.6.2 might have had the linker bugs I mention. On the other hand, I've tried with the latest version installed and it didn't help (probably because ghci doesn't use it). In terms of experimentation, you can hand desugar the objective-c code in the GLFW init and when I do that I get segfaults. Also, the address mentioned in the objective-c exception has a suspicious value, which would further implicate the linker. Add to that, it works for a compile program (which uses the system linker, IIRC). Basically, I'm pretty sure it's GHCi's linker to blame here but I don't have a smoking gun. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS X ghci problem
On Sat, Jul 13, 2013 at 5:32 PM, Anthony Cowley acow...@gmail.com wrote: On Jul 13, 2013, at 8:04 PM, Jason Dagit dag...@gmail.com wrote: On Sat, Jul 13, 2013 at 4:39 PM, Mark Lentczner mark.lentcz...@gmail.com wrote: Bizarre - this just happened to me today, too. Anyone? Did you figure out a work around? For the record, I'm trying to bring Euterpea up. After some digging, experimenting, asking around, and head scratching my best guesses are: * GHCi's custom linker isn't doing the right thing (some versions of llvm/clang gave crashes like this and it was a linker bug for them, you can find reports on sites like StackOverflow). * We need to feed .m files to clang instead of ghc/gcc * GHCi needs to be built with Cocoa in mind (is it already?) * Some rts component of objective-c is not properly initialized (ARC vs. -fobjc-gc vs. -fnext-step, etc) My system is OS X 10.8.4, and I'm running HP 2013.2, so 7.6.3. And GLFW-0.5.1.0. In terms of experimentation, you can hand desugar the objective-c code in the GLFW init and when I do that I get segfaults. Also, the address mentioned in the objective-c exception has a suspicious value, which would further implicate the linker. Add to that, it works for a compile program (which uses the system linker, IIRC). Basically, I'm pretty sure it's GHCi's linker to blame here but I don't have a smoking gun. Jason I thought I'd had some success desugaring the Objective-C code, but I never went the whole way, so perhaps I just didn't get to the segfault. What I do for GLFW is use a dylib, then you don't rely on GHCi's static-ish linker. The only wrinkle is figuring out where you want the dylib. I think homebrew will put one in /usr/local/lib, which works out nicely, but they don't have GLFW 3 yet. Another option is to build the dylib yourself from the GLFW source bundled with the GLFW-b package, then tell cabal where to find it. Thanks. It hadn't occurred to me that the previous packaging had better success precisely because it built a dylib first. It's worth the trouble, as having a GHCi-based workflow for graphics work is wonderful. A fancy Setup.hs that works out installation paths could generate the dylib, and I thought such code existed in the past. Was some problem found with that approach? Yes, I wrote the Setup.hs/Makefile in the previous GLFW-b version that built glfw as a dylib. The problem is that Hackage no longer accepts that packaging because it doesn't like the extra-lib-dirs. Working around the (somewhat) arbitrary constraints that cabal/hackage imposes is rather annoying. There is no trust me, this package works option. It just assumes that a relative path in extra-lib-dirs can never work and rejects the package upload :( Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS X ghci problem
On Sat, Jul 13, 2013 at 6:44 PM, Carter Schonwald carter.schonw...@gmail.com wrote: has anyone tried using ghci HEAD? If the problem is linker based... perhaps ghci that uses the system Dylinker might resolve it? If someone gets brave and tries this I'd love to hear if it works. Although, that's too new for something we hope most people can use. I'm already feeling sheepish about requiring a minimum of 7.2.1 on OSX (that was the first version that knew what to do with .m files). Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Netwire bouncing ball
On Wed, Jul 10, 2013 at 2:15 PM, Just hask...@justnothing.org wrote:
Hello,
I'm trying to get a grasp of netwire by implementing a bouncing ball
simulation and I'm failing.
The ball starts from the ground with a given velocity and when hitting the
ground the wire inhibits successfully. Now I'm kinda stuck.
I've never used netwire (although I've used yampa and
recative-banana), so I can't give you help with the code, but maybe I
can help with the concepts.
I think I see what is wrong. You need to keep applying forces to the
ball. Right now, the code says, once the ball falls below a certain
point, stop applying the force (eg., clamp the output of the
integral). Instead, you could apply an upward force at the point of
impact. You can get this from newton's third law (equal and opposite
reaction). The easiest way to see a bounce would be to simply negate
the velocity when you detect a collision with the ground. A more
accurate way might involve some calculations to figure out the
impulse, but then you'll need more things like the mass of the ball.
I hope that helps,
Jason
How can I make the ball bounce?
Here is the code:
{-# LANGUAGE Arrows #-}
module Main where
import Control.Wire
import Prelude hiding ((.), id)
import Control.Concurrent
type Pos = Double
type Vel = Double
type ObjState = (Pos, Vel)
testApp :: Pos - Vel - WireP () ObjState
testApp p0 v0 = proc _ - do
v - integral_ v0 - -9.81
p - integral1_ p0 - v
when (= 0) - p
returnA - (p, v)
main :: IO ()
main = loop' (testApp 0 30) clockSession
where
loop' w' session' = do
threadDelay 100
(mx, w, session) - stepSessionP w' session' ()
case mx of
Left ex - putStrLn (Inhibited: ++ show ex)
Right x - putStrLn (Produced: ++ show x)
loop' w session
Thanks in advance!
___
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] Why isn't hsc2hs functionality provided by ghc?
On Tue, Jun 4, 2013 at 8:45 PM, John Lato jwl...@gmail.com wrote:
On Wed, Jun 5, 2013 at 10:15 AM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
On 5 June 2013 12:02, silly silly8...@gmail.com wrote:
I was wondering today, why hasn't hsc2hs been merged with ghc so that
it would be possible to add a
{-# LANGUAGE ForeignFunctionInterface #-}
at the top of a source file and then load it with ghci or compile it,
without the intermediate step of calling hsc2hs? This would be exactly
like the CPP extension. I don't have to call cpp manually. All I have
to do is to add {-# LANGUAGE CPP #-} and then ghc will take care of
the rest. This would also mean that there would be no need to have a
separate file extension. Surely I must not be the first person to have
that thought, so there must be a good reason why this hasn't happen
yet, but what is it?
Isn't this done automatically when you have files with the .hsc extension?
cabal handles this transparently, but not ghc. It's frustrating when you
want to develop a project with ghci.
I don't think it's a good idea to merge hsc2hs syntax into Haskell files.
In particular, it's often useful to inspect the intermediate .hs file
produced by hsc2hs during development or debugging. Also it would
complicate ghc's parser, etc...
My preferred solution would be to have ghc/ghci automatically run hsc2hs
(support c2hs also?) when necessary. But so long as it's handled
automatically, I wouldn't be particularly bothered by the implementation.
How about having a `ghci` command for cabal? Or does the automatic
requirement really need to be part of ghc to work the way you want?
(BTW, cabal-dev does have a `ghci` command, but I haven't tested to
see if it does the hsc - hs conversion.)
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Array, Vector, Bytestring
On Mon, Jun 3, 2013 at 7:45 PM, Clark Gaebel cgae...@uwaterloo.ca wrote: How is this a problem? If you're representing text, use 'text'. If you're representing a string of bytes, use 'bytestring'. If you want an array of values, think c++ and use 'vector'. If you want to mutate arrays, first, make sure you do. You probably don't. If you're sure, use MVector. Don't use String, except to interface with legacy code. You probably want 'text'. Don't use Array. Anything it can be used for, can be done with 'vector'. You have to build multidimensional accessors for vector yourself. Array supports them out of the box. I still prefer vector, but it's only fair to note that multidimensional data is a weak spot of vector. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [haskell.org Google Summer of Code 2013] Approved Projects
On Wed, May 29, 2013 at 10:47 AM, Carter Schonwald carter.schonw...@gmail.com wrote: indeed, i'm the principal mentor for this project, though as mentioned Ian-Woo will hopefully be helping out too. I'm going to *help* focus the project on being a tool thats not focused on QT, though if something nice can be worked out in that direction, great! Are you folks aware of the work on this topic by Tristan Ravitch? https://github.com/travitch/foreign-inference Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parallel ghc --make
On Wed, May 15, 2013 at 6:36 PM, Clark Gaebel cgae...@uwaterloo.ca wrote: It's also useful to note that the disk cache might do a surprisingly good job at caching those .hi files for you. That, and a lot of people (like me!) use SSDs, where the parallel compilation takes the vast majority of time. I'd be really excited to see parallel ghc --make. By the way, totally unrelated, but why does cabal support -j when cabal-dev doesn't? It helps to understand that they are made by different people and cabal-dev is just a wrapper around cabal. Out of curiosity I just tried 'cabal-dev install -j' and as far as I can tell right now it does support -j. Perhaps you need to install newer versions of cabal or cabal-dev? $ cabal-dev --version cabal-dev 0.9.1 built with Cabal 1.16.0 Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghci: Difference in garbage collection etc. between REPL and function
On Wed, May 8, 2013 at 6:54 PM, Niklas Hambüchen m...@nh2.me wrote: I have an annoying bug in a C binding that can be triggered like this: handle - open ... prep - makePreparedStatement handle INSERT ... performGC runStatement prep close handle If I run these steps one by one in ghci, garbage ends up in my handle as expected. However, if I let main = do ... this whole block in order to pack it in a test case, it does not happen, neither in ghci nor ghc. What might be the special magic in ghci's REPL that allows me to trigger my bug so easily there? One thing to investigate: Thread Local Storage By default ghci puts each action you run into a thread and executes it. If the underlying C code stores something (or accesses it) from thread local storage, then you will run into issues like this. Try starting ghci with -fno-ghci-sandbox. If the bad behavior goes away there, try running each step of your test case inside a forkIO from ghc with the threaded RTS. If the problem disappears in ghci but shows up with forkIO, then it's a pretty good indicator that it's related to the way the C code uses thread local storage. I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ghci: Difference in garbage collection etc. between REPL and function
On Wed, May 8, 2013 at 8:12 PM, Jason Dagit dag...@gmail.com wrote: On Wed, May 8, 2013 at 6:54 PM, Niklas Hambüchen m...@nh2.me wrote: I have an annoying bug in a C binding that can be triggered like this: handle - open ... prep - makePreparedStatement handle INSERT ... performGC runStatement prep close handle If I run these steps one by one in ghci, garbage ends up in my handle as expected. However, if I let main = do ... this whole block in order to pack it in a test case, it does not happen, neither in ghci nor ghc. What might be the special magic in ghci's REPL that allows me to trigger my bug so easily there? One thing to investigate: Thread Local Storage By default ghci puts each action you run into a thread and executes it. If the underlying C code stores something (or accesses it) from thread local storage, then you will run into issues like this. My point was meant to be, it's something to try but I have no idea if it's going to be the issue here. The caveat I forgot to add is: I've never seen the thread local storage issue affect GC. In particular, ghc might be running a finalizer in the case of individual actions because it doesn't know you are about to use the handle? Now that I think about it more, I suspect that is more likely to be the case. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GPGPU
On Sat, May 4, 2013 at 3:00 AM, Christopher Howard christopher.how...@frigidcode.com wrote: Has anybody on the list been playing around with OpenCL at all? I'm just starting to look into it - need to get a newer Radeon card, I think - but I'm strongly interested in GPGPU programming. This is about as far as I've made it: http://dagit.github.io/posts/2013-04-29-opencl-and-language-c-quote.html Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GPGPU
On Sat, May 4, 2013 at 11:54 AM, Anthony Cowley acow...@seas.upenn.edu wrote: I wrote this some time ago. http://www.arcadianvisions.com/blog/?p=346 I know that soon after I wrote that, it worked with both OpenCL and gloss from hackage, but there may be some bitrot at this point. Some of the links in the blog seem to be broken as well. For instance, the link to the animation screen shot. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GPGPU
On Sat, May 4, 2013 at 2:16 PM, Anthony Cowley acow...@seas.upenn.edu wrote: Thanks to the nudge from Jason, the bitrot has now been scraped off. The post is prettier, the code all works again, and the screenshot has been restored. Nice! That's a very cool demo. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiled program using OpenGL fails to trigger GPU switch on Mac, but works in GHCi
On Sat, Mar 16, 2013 at 6:53 PM, Jesper Särnesjö sarne...@gmail.com wrote: To be clear, I think this isn't really an OpenGL problem, but rather one related to FFI or event handling. If anyone could explain to me, in general, how and why a call to a foreign function returning IO () might cause different behavior in Haskell than in C, that might help me track down the problem. I haven't finished reading your other email, but I can suggest a possible answer to this query. Lots of the native GUI libraries attached thread local storage to the process's initial thread. In GHCi expressions are not evaluated in that thread (in the default setup). One thing that may be worth investigating is the difference between ghci behavior when you start with and without -fno-ghci-sandbox. The release notes for 7.0.1 said this about that flag: There is a new -fno-ghci-sandbox flag, which stops GHCi running computations in a separate thread. In particular, this is useful for GLUT on OS X, which only works if being run on the main thread. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
On Wed, Feb 20, 2013 at 11:19 AM, Gwern Branwen gwe...@gmail.com wrote: On Wed, Feb 20, 2013 at 1:35 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Gwern, and what do you think about James' fork of lambdabot? It seems that there was a lot of work put into it and that this is indeed a good starting point to continue development. I haven't looked at the diffs; if as he says the security around the evaluation has been weakened, that's a deal-breaker until it's fixed. lambdabot can't be insecure since it will be run in a public IRC. I absolutely agree. There are sandboxing things we can do around the lambdabot instance, but Haskell has a lot of opportunities for statically disallowing questionable things. I would like to start our defense there and add layers around that. My real reason for reviving this thread: Can I get a status update, please? Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
On Fri, Mar 15, 2013 at 9:19 AM, James Cook mo...@deepbondi.net wrote: On Mar 14, 2013, at 11:08 PM, Jason Dagit dag...@gmail.com wrote: My real reason for reviving this thread: Can I get a status update, please? Sure. I don't have as much time as I'd like these days for open-source projects, but with Jan's help the code has been cleaned up quite a bit in general, and a lot of old bit-rot has been fixed. I have not specifically addressed security yet, but it's not as dire a situation as I think it sounded from my earlier remarks. Basically, security is currently a bit DIY. If there are any holes, they are probably quite subtle because there are very, very few moving parts on lambdabot's side. mueval and Safe Haskell are used to enforce resource limitations and type-safety, respectively, but -fpackage-trust is not (yet) turned on. So all packages installed on the system are available for the interpreted code (if imported using a command such as @let import Foo.Bar), as long as Safe Haskell permits. This is the main potential security hole - the system may have modules installed and marked Trustworthy that the administrator has not explicitly decided whether to trust, and which are not, in fact, as safe as the author asserts. Currently, lambdabot trusts such packages. My intention is to add some commands (available only to lambdabot admins) or maybe a static configuration option for managing a list of packages to explicitly trust, with all others being untrusted. And of course, for a production system an OS-enforced sandbox is a great idea no matter how secure you believe the code do be. Aside from that caveat, I think that the code could be put on hackage today and I'd have few, if any, reservations about it. I haven't been following the thread closely. Is there also a github? If so, where? Some of us figured out a bug fix for the quotes plugin and I'll send a pull request if I get a chance. Thanks for the update, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
On Fri, Mar 15, 2013 at 3:30 PM, James Cook mo...@deepbondi.net wrote:
On Mar 15, 2013, at 2:45 PM, Jason Dagit dag...@gmail.com wrote:
I haven't been following the thread closely. Is there also a github? If
so, where? Some of us figured out a bug fix for the quotes plugin and I'll
send a pull request if I get a chance.
Yep, there is[1]. I'm not sure what the specific bug is that you are
referring to, but it's possible it doesn't exist anymore - a large part of
the quotes plugin has been rewritten (actually outsourced to a fortune-mod
clone written in Haskell called misfortune). If it still does, then of
course I'd be happy to accept a fix :)
[1] https://github.com/mokus0/lambdabot
Awesome.
I believe the bug is still there. The type for the quote db is:
type Key= P.ByteString
type Quotes = M.Map Key [P.ByteString]
Which leaves the possibility that a key exists but there are no quotes.
This is problematic for the current version of random. I glanced at your
new version and it wasn't clear to me if it's still a problem (I suspect it
is). One bandaid for this is to change the lines below:
https://github.com/mokus0/lambdabot/blob/master/src/Lambdabot/Plugin/Quote.hs#L161
https://github.com/mokus0/lambdabot/blob/master/src/Lambdabot/Plugin/Quote.hs#L166
In both cases Just qs could be changed to Just qs@(_:_) and then empty
lists would fall through to the default case.
The other fix is to prune out degenerate entries (where key maps to the
empty list). I believe that would be fixed in the serialization function:
moduleSerialize = Just mapListPackedSerial
Changing that to something like:
moduleSerialize = Just mapListPackedSerialSansEmpties
where
mapListPackedSerialSansEmpties = mapListPackedSerial { serialize =
(serialize mapListPackedSerial) . Map.filter (not.null) }
Perhaps that should be added to the Serial module as an alternative to
mapListPackedSerial.
I haven't tested any of the above code (or even tried to compile it).
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
On Fri, Mar 15, 2013 at 4:31 PM, Jason Dagit dag...@gmail.com wrote:
On Fri, Mar 15, 2013 at 3:30 PM, James Cook mo...@deepbondi.net wrote:
On Mar 15, 2013, at 2:45 PM, Jason Dagit dag...@gmail.com wrote:
I haven't been following the thread closely. Is there also a github? If
so, where? Some of us figured out a bug fix for the quotes plugin and I'll
send a pull request if I get a chance.
Yep, there is[1]. I'm not sure what the specific bug is that you are
referring to, but it's possible it doesn't exist anymore - a large part of
the quotes plugin has been rewritten (actually outsourced to a fortune-mod
clone written in Haskell called misfortune). If it still does, then of
course I'd be happy to accept a fix :)
[1] https://github.com/mokus0/lambdabot
Awesome.
I believe the bug is still there. The type for the quote db is:
type Key= P.ByteString
type Quotes = M.Map Key [P.ByteString]
Which leaves the possibility that a key exists but there are no quotes.
This is problematic for the current version of random. I glanced at your
new version and it wasn't clear to me if it's still a problem (I suspect it
is). One bandaid for this is to change the lines below:
https://github.com/mokus0/lambdabot/blob/master/src/Lambdabot/Plugin/Quote.hs#L161
https://github.com/mokus0/lambdabot/blob/master/src/Lambdabot/Plugin/Quote.hs#L166
In both cases Just qs could be changed to Just qs@(_:_) and then
empty lists would fall through to the default case.
The other fix is to prune out degenerate entries (where key maps to the
empty list). I believe that would be fixed in the serialization function:
moduleSerialize = Just mapListPackedSerial
Changing that to something like:
moduleSerialize = Just mapListPackedSerialSansEmpties
where
mapListPackedSerialSansEmpties = mapListPackedSerial { serialize =
(serialize mapListPackedSerial) . Map.filter (not.null) }
Perhaps that should be added to the Serial module as an alternative to
mapListPackedSerial.
I haven't tested any of the above code (or even tried to compile it).
I was going to start making these changes and I noticed that it doesn't
currently build with ghc 7.4.1 w/Haskell Platform:
https://travis-ci.org/dagit/lambdabot/builds/5541375
Do you know if the constraints on:
regex-posix-0.95.1
regex-compat-0.95.1
Need to be what they are? Could we relax them without breaking anything?
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Open-source projects for beginning Haskell students?
On Mon, Mar 11, 2013 at 8:48 AM, Brent Yorgey byor...@seas.upenn.eduwrote: Hi everyone, I am currently teaching a half-credit introductory Haskell class for undergraduates. This is the third time I've taught it. Both of the previous times, for their final project I gave them the option of contributing to an open-source project; a couple groups/individuals took me up on it and I think it ended up being a modest success. So I'd like to do it again this time around, and am looking for particular projects I can suggest to them. Do you have an open-source project with a few well-specified tasks that a relative beginner (see below) could reasonably make a contribution towards in the space of about four weeks? I'm aware that most tasks don't fit that profile, but even complex projects usually have a few simple-ish tasks that haven't yet been done just because no one has gotten around to it yet. If you have any such projects, I'd love to hear about it! Just send me a paragraph or so describing your project and explaining what task(s) you could use help with --- something that I could put on the course website for students to look at. Myself and several of my friends would find it useful to have a plotting library that we can use from ghci to quickly/easily visualize data. Especially if that data is part of a simulation we are toying with. Therefore, this proposal is for: A gnuplot-, matlab- or plotinum-like plotting API (that uses diagrams as the backend?). The things to emphasize: * Easy to install: No gtk2hs requirement. Preferably just pure haskell code and similar for any dependencies. Must be cross platform. * Frontend: graphs should be easy to construct; customizability is not as important * Backend: options for generating static images are nice, but for the use case we have in mind also being able to render in a window from ghci is very valuable. (this could imply something as purely rendering to JuicyPixels and I could write the rendering code) * What I would hope from you is a willingness to exchange email and/or chat with the student(s) over the course of the project, to give them a bit of guidance/mentoring. I am certainly willing to help on that front, but of course I probably don't know much about your particular project. I am willing/able to take on the mentoring aspect :) Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Open-source projects for beginning Haskell students?
On Mon, Mar 11, 2013 at 1:09 PM, Brent Yorgey byor...@seas.upenn.eduwrote: On Mon, Mar 11, 2013 at 11:50:38AM -0700, Ben wrote: On Mar 11, 2013, at 11:26 AM, Jason Dagit wrote: Myself and several of my friends would find it useful to have a plotting library that we can use from ghci to quickly/easily visualize data. Especially if that data is part of a simulation we are toying with. Therefore, this proposal is for: A gnuplot-, matlab- or plotinum-like plotting API (that uses diagrams as the backend?). The things to emphasize: * Easy to install: No gtk2hs requirement. Preferably just pure haskell code and similar for any dependencies. Must be cross platform. * Frontend: graphs should be easy to construct; customizability is not as important * Backend: options for generating static images are nice, but for the use case we have in mind also being able to render in a window from ghci is very valuable. (this could imply something as purely rendering to JuicyPixels and I could write the rendering code) * What I would hope from you is a willingness to exchange email and/or chat with the student(s) over the course of the project, to give them a bit of guidance/mentoring. I am certainly willing to help on that front, but of course I probably don't know much about your particular project. I am willing/able to take on the mentoring aspect :) i second this, but with a different emphasis. i would like a ggplot2-type DSL for generating graphs, for data analysis and exploration. i agree with : * it would be great to have no gtk2hs / cairo requirement. (i guess this means text rendering in the diagrams-svg backend needs to be solved.) i guess in the near-term, this is less important to me -- having a proper plotting DSL at all is an important start. * frontend : graphs should be easy to construct, but having some flexibility is important. the application here is being able to explore statistical data, with slicing, grouping, highlighting, faceting, etc. * backend : static images are enough for me, interactive is a plus. most importantly : it should be fast enough to work pleasantly with large datasets. ggplot2 is pretty awesome but kills my machine, routinely. Not to throw cold water on these ideas (which sound fantastic!), but the scope of this sounds more like a GSoC project than something a beginner could accomplish in 10-15 hours in the space of a few weeks. I'm looking not for project ideas but for small, concrete contributions they could make to existing open source projects. Good point. Perhaps the project I mentioned could be broken up into suitable tasks? For example, if the students just worked on the frontend portion it would still be useful as a starting point for others. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Galois is hiring!
Galois is hiring! We're looking for functional programmers, formal methods practitioners, and project leads, with a variety of positions open at all professional experience levels. For more information on the job openings and Galois in general, see: http://corp.galois.com/careers I've written before about what makes Galois a great organization to be a part of: http://blog.codersbase.com/2012/03/life-at-galois.html Thanks, Jason___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
On Tue, Feb 19, 2013 at 3:01 PM, James Cook mo...@deepbondi.net wrote: On Feb 19, 2013, at 2:36 PM, Jan Stolarek jan.stola...@p.lodz.pl wrote: Anyway, how would you feel about changes that I would like to make: - move all modules into Lambdabot. namespace - remove unlambda, brainfuck and show from the repo. They are on hackage, no need to keep them here - these packages aren't even used in the build process. - cleanup scripts - add package versions to cabal file I have no objections to any of these, though I would recommend as Gwern hinted that if related packages are to be removed that they should also be given new homes - I believe that the lambdabot source is currently the main home of these packages. Random thought, feel free to ignore it: Would it make sense to split lambdabot up into core and contrib like is done with xmonad? Contrib could contain the sillier things like bf, unlambda, show, etc and would have a lower bar for contributors. Core would be the standard things and the essential things. It seems that people don't really contribute new plugins these days but it would be great if they did. For example, having a plugin for liquid types would be super spiffy. Also, any plugin that helps people to reason about other code (like vacuum). Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Maintaining lambdabot
On Sun, Feb 17, 2013 at 8:53 PM, Cale Gibbard cgibb...@gmail.com wrote: On 17 February 2013 18:03, Jan Stolarek jan.stola...@p.lodz.pl wrote: ... This changes would be quite invasive and code wouldn't be compatible with the lambdabot repo on haskell.org. So before I start making any of them I would like to hear from the community if such changes in the source code of lambdabot would be considered helpful and acceptable. Janek I say go for it! I'll be quite happy to start running your new code in #haskell as soon as we get GHC 7.6 installed on Jason's Linode account. :) My name is Jason and I endorse this message :) Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haskell bindings for the igraph C library
On Tue, Jan 22, 2013 at 3:20 PM, George Giorgidze giorgi...@gmail.comwrote: Hi Jason, How does this compare with fgl? http://hackage.haskell.org/package/fgl A couple of months ago, I was working on a project where I had to do some graph analysis. I encountered two problems with the fgl library: Thanks. That's helpful. I originally asked simply because I wanted to know when I would choose fgl vs. igraph. Your response answered that pretty well. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] An assembly DSL example.
On Wed, Dec 19, 2012 at 8:08 AM, Tom Hawkins tomahawk...@gmail.com wrote:
A few folks have asked me about building EDSLs in Haskell for assembly
programming, so I've posted an example of the approach we have had success
using at BAE Systems.
It's a bit rough, so if anyone's motivated to polish it up, by all means.
https://github.com/tomahawkins/asm-dsl-example/
Thanks. It was nice to read. I was reminded of The Monad Reader Issue 6
as it explains how to tie the knot when creating labels:
http://www.haskell.org/wikiupload/1/14/TMR-Issue6.pdf
The Russell uses an assembly language DSL as a motivating example and
explains how either Haskell98 or mdo can be used to tie the knot, with mdo
giving a nicer implementation. The result allows labels to be defined where
they are used instead of requiring the user to instantiate them and then
associate them with a place in the program. This provides a nice
abstraction for building your assembler macros.
For example, in your code we see:
\begin{code}
testProgram :: Asm ()
testProgram = do
begin - label
loop - label
begin -: do
i1 10 20
i2
i3 5
loop -: do
i4
goto loop
\end{code}
The corresponding code using the TMR trick might look like this (I've
removed the nested indentation):
\begin{code}
testProgram :: Asm ()
testProgram = mdo
begin - label
i1 10 20
i2
i3 5
loop - label
i4
goto loop
\end{code}
Other examples demonstrate that labels can be referenced before the line
that creates them due to the way mdo works.
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANN: Haskell bindings for the igraph C library
On Sun, Dec 16, 2012 at 9:53 AM, Nils Schweinsberg m...@nils.cc wrote: Hi Haskellers, dear igraph community, I am pleased to announce the release of our (inofficial) Haskell bindings to the igraph C library. igraph is a powerfull library for creating and manipulating directed, undirected and weighted graphs. Our package offers a complete coverage of all functions on structural properties of graphs. How does this compare with fgl? http://hackage.haskell.org/package/fgl Thanks! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to start with GHC development?
On Tue, Dec 11, 2012 at 6:10 AM, Eric Rochester eroch...@gmail.com wrote: I'm in the same boat, with just a little less reading. :) It seems to be that if we want to encourage participation in GHC development, the first step is to lower the barrier of entry. One way to do that would be to have a page (wiki, perhaps) that has a reading list for learning about GHC. I'd guess that there are a lot of people like Janek and myself who want to contribute, even a little, and just aren't sure about where to start. We're happy to do our homework, but we need some assignments, so to speak. The GHC developers have created a list to help with this, look at the easy bugs and tasks: http://hackage.haskell.org/trac/ghc/wiki/GettingStarted Another idea is to have a list of open tasks grouped by how difficult they will be and how much knowledge of Haskell and GHC will be required. They already thought of this and did it :) Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best approach to avoid dependency hells
On Wed, Dec 5, 2012 at 10:52 AM, Ivan Perez ivanperezdoming...@gmail.comwrote: Hello everyone, I've spent the last couple of days fighting my way around a dependency hell with my own libraries and packages. If I install them package by package (by hand), I'm very likely to hit one of these conflicts that I'm talking about. A simple example of something that did happen: - Package A depends on bytestring, and is compatible with both 0.9.* and 0.10.* - Package B depends on ghc, which I installed using the package manager and which depends on bytestring 0.9.2 - Package B depends on package A. I do not want to add to the cabal files that B depends on bytestring 0.9.*, because it's not true, or that A depends on bytstring 0.9, because it's also not true. I would like to the best approach to 1) avoid these situations and 2) fix them when they happen. Regarding (2), Is there any way to automatically rebuild all the broken packages? Regarding (1), I thought about using cabal-dev, but I think I'll just have the same problem, won't I? After all, I started from a clean fresh ghc installation and I just installed what I needed to make my program run. Let's say you are working in a directory foo that contains a cabal file for package foo. When you type 'cabal-dev install', cabal-dev looks at foo.cabal in the current directory, it uses it to calculate constraints and then installs the dependencies locally that satisfy those constraints. It also has an install-deps command if you just want to install the deps but not build/install foo. Additionally, if you want to use locally modified versions of the dependencies use 'cabal add-source path to dep' from the foo directory to add your locally modified package to foo's index so that subsequent cabal-dev operations can find it and install it. Basically, don't install the deps by hand. Let cabal-dev figure out the mutually compatible versions and install that *locally* to where you're building foo. As for the problem of recursively rebuilding the deps, I think 'cab' [1] solves this but I haven't tried it. [1] http://hackage.haskell.org/package/cab I also thought about adding process, bytestring and other global packages to the list of constraints in ~/.cabal/config. Would this be a good approach, or will it lead to bigger headaches in the future (for instance, in the form of programs that just cannot be installed at all)? Adding these constraints will come back to bite you. That's been my experience. Also, is there any way to detect potential dependency hells without having to install a package? (Some tool that will analyse the dependency information (statically) and determine more strict or incorrect upper and lower bounds for the dependencies of a package.) --dry-run? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is it possible to have constant-space JSON decoding?
On Tue, Dec 4, 2012 at 9:37 PM, Johan Tibell johan.tib...@gmail.com wrote: Hi Oleg, On Tue, Dec 4, 2012 at 9:13 PM, o...@okmij.org wrote: I am doing, for several months, constant-space processing of large XML files using iteratees. The file contains many XML elements (which are a bit complex than a number). An element can be processed independently. After the parser finished with one element, and dumped the related data, the processing of the next element starts anew, so to speak. No significant state is accumulated for the overall parsing sans the counters of processed and bad elements, for statistics. XML is somewhat like JSON, only more complex: an XML parser has to deal with namespaces, parsed entities, CDATA sections and the other interesting stuff. Therefore, I'm quite sure there should not be fundamental problems in constant-space parsing of JSON. BTW, the parser itself is described there http://okmij.org/ftp/Streams.html#xml It certainly is possible (using a SAX style parser). What you can't have (I think) is a function: decode :: FromJSON a = ByteString - Maybe a and constant-memory parsing at the same time. The return type here says that we will return Nothing if parsing fails. We can only do so after looking at the whole input (otherwise how would we know if it's malformed). I thought it was possible to get around this with lazy patterns such Wadler's force function [1]? (untested code) force y = let Just x = y in Just x lazyDecode :: FromJSON a = ByteString - Maybe a lazyDecode = force . decode [1] http://www.haskell.org/haskellwiki/Maintaining_laziness ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] computation over containers, greatly simplified notation.
You might find this paper an interesting read: http://www.brics.dk/RS/01/10/ On Fri, Nov 30, 2012 at 4:43 PM, Takayuki Muranushi muranu...@gmail.comwrote: Dear everyone, After a number of attempts [1] I'm starting to think that my initial approach was ill-directed. After all, Functor, Applicative, Zip are three different classes. Functors are type constructors where you can map unary functions over them. Applicatives are those with map-over of zero-ary functions (pure,) unary functions, binary functions, ternary functions, ... etc. Zip are those with unary, binary, ternary ... mapover, but not zero-ary map-over. Repa Arrays and Vectors belong to Zip because there's no trivial unique way to implement pure. What the customer really needed [2] seems to be the following series of functions: forLiftZ1 :: Zip f = f a - (a - b) - f b forLiftZ2 :: Zip f = f a - f b - (a - b - c) - f c forLiftZ3 :: Zip f = f a - f b - f c - (a - b - c - d) - f d Now I'm trying if it's possible to implement the series in a single shot [3] . I'm reporting my progress for anyone who might be still thinking for me. Thank you!! [1] https://github.com/nushio3/practice/tree/master/free-objects [2] http://www.projectcartoon.com/cartoon/3 [3] https://github.com/nushio3/practice/blob/master/free-objects/printf6.hs 2012/11/29 Takayuki Muranushi muranu...@gmail.com Dear all, I came up with an idea to greatly simplify some kinds of array computations. It should work well with many kinds of arrays. Is this new? https://gist.github.com/4162375 These few days, I've been trying to rewrite a hydrodynamic simulation code that used Data.Vector (~250 lines), to Repa [1] . It seemed promising, but soon I realized that I needed to use Repa.map and Repa.zipWith almost everywhere. I need careful thinking to transform every lines (that used vector's indexing) to Repa's point-free stile. Is there any better ways? Then I realized that I was the author of Paraiso [2], a DSL for stencil computation. One of its feature is to write down array computation just as if it were scalar computation. Basically what I need is ZipList-like Applicative instances for vectors and Repa arrays. Why not they support ZipVector? Because 'pure' of zipList was an infinite list and you can't do infinite vectors. Then I came up with this idea. https://gist.github.com/4162375 the wrapper W does several things: it represents the 'pure,' homogeneous array in a space-efficient manner, and also serves as a newtype-wrapper of Num (and possibly Fractional, Floating...) instances. Questions are: is this technology new? or promising? doomed? It seems to me like a free-Applicative, like the free-Monad theory. Are they related? The function 'backend' helps to mix in the non-zip-like computations. How can we remove the 'undefined' in the 'backend?' Some of Repa computations are Monads. W needs to be a monad transformer to incooperate this. Also I'm grateful to past cafe discussion on existing Zippable implementations [3][4] . [1] hackage.haskell.org/package/repa [2] http://hackage.haskell.org/package/Paraiso [3] http://www.haskell.org/pipermail/haskell-cafe/2009-July/064403.html [4] http://hackage.haskell.org/packages/archive/category-extras/latest/doc/html/Control-Functor-Zip.html -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html -- Takayuki MURANUSHI The Hakubi Center for Advanced Research, Kyoto University http://www.hakubi.kyoto-u.ac.jp/02_mem/h22/muranushi.html ___ 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] Can a GC delay TCP connection formation?
On Tue, Nov 27, 2012 at 11:02 AM, Jeff Shaw shawj...@gmail.com wrote: Hello Timothy and others, One of my clients hosts their HTTP clients in an Amazon cloud, so even when they turn on persistent HTTP connections, they use many connections. Usually they only end up sending one HTTP request per TCP connection. My specific problem is that they want a response in 120 ms or so, and at times they are unable to complete a TCP connection in that amount of time. I'm looking at on the order of 100 TCP connections per second, and on the order of 1000 HTTP requests per second (other clients do benefit from persistent HTTP connections). Once each minute, a thread of my program updates a global state, stored in an IORef, and updated with atomicModifyIORef', based on query results via HDBC-obdc. The query results are strict, and atomicModifyIORef' should receive the updated state already evaluated. I reduced the amount of time that query took from tens of seconds to just a couple, and for some reason that reduced the proportion of TCP timeouts drastically. The approximate before and after TCP timeout proportions are 15% and 5%. I'm not sure why this reduction in timeouts resulted from the query time improving, but this discovery has me on the task of removing all database code from the main program and into a cron job. My best guess is that HDBC-odbc somehow disrupts other communications while it waits for the DB server to respond. Have you read section 8.4.2 of the ghc user guide? http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/ffi-ghc.html Based on that I would check the FFI imports in your database library. In the best case (-threaded, 'safe', and thread-safe odbc), I think you'll find that N of these can run concurrently, but here your number of requests is likely to be much greater than N (where N is the number of threads the RTS created with +RTS -N). I'm not sure how to solve your problem, but perhaps this information can help you pinpoint the problem. Good luck, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can a GC delay TCP connection formation?
On Tue, Nov 27, 2012 at 11:17 AM, Jason Dagit dag...@gmail.com wrote: On Tue, Nov 27, 2012 at 11:02 AM, Jeff Shaw shawj...@gmail.com wrote: Hello Timothy and others, One of my clients hosts their HTTP clients in an Amazon cloud, so even when they turn on persistent HTTP connections, they use many connections. Usually they only end up sending one HTTP request per TCP connection. My specific problem is that they want a response in 120 ms or so, and at times they are unable to complete a TCP connection in that amount of time. I'm looking at on the order of 100 TCP connections per second, and on the order of 1000 HTTP requests per second (other clients do benefit from persistent HTTP connections). Once each minute, a thread of my program updates a global state, stored in an IORef, and updated with atomicModifyIORef', based on query results via HDBC-obdc. The query results are strict, and atomicModifyIORef' should receive the updated state already evaluated. I reduced the amount of time that query took from tens of seconds to just a couple, and for some reason that reduced the proportion of TCP timeouts drastically. The approximate before and after TCP timeout proportions are 15% and 5%. I'm not sure why this reduction in timeouts resulted from the query time improving, but this discovery has me on the task of removing all database code from the main program and into a cron job. My best guess is that HDBC-odbc somehow disrupts other communications while it waits for the DB server to respond. Have you read section 8.4.2 of the ghc user guide? http://www.haskell.org/ghc/docs/7.4.1/html/users_guide/ffi-ghc.html Ahem, I meant *8.2.4*. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] haskell.org committee: Call for nominations
Just a reminder to nominate yourself if you're interested. If you've been thinking about it but haven't contacted us yet then please just do it and contact us today! Thank, Jason On Fri, Nov 2, 2012 at 11:28 AM, Jason Dagit dag...@gmail.com wrote: Dear Haskellers, The second year of the haskell.org committee is drawing to a close and it is therefore time to seek replacements for those members whose term is expiring. This year one member has a term ending, Ganesh Sittampalam. Ganesh has been an excellent contributor and the rest of the committee would like to thank him for his excellent service. To nominate yourself, please send an e-mail to committee at haskell.org by 30 November 2012. As usual, retiring members are eligible to re-nominate themselves. Please feel free to include any information about yourself that you think will help us to make a decision. Being a member of the committee does not require a significant amount of time, but committee members should aim to be responsive during discussions when the committee is called upon to make a decision. More details about the committee's roles and responsibilities are on http://www.haskell.org/haskellwiki/Haskell.org_committee If you have any questions about the process, please feel free to e-mail us at committee at haskell.org or to contact one of us individually. Regards, Jason On behalf of the haskell.org committee ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: OpenGL packages update
The updates include: * All of the newtypes in OpenGLRaw have been changed to type aliases (credit to Trevor Elliott and Mike Ledger) * OpenGLRaw's TypesInternal module has gone away * NVidia path rendering extensions have been added by ozelis on github This release changes OpenGLRaw to use type aliases instead of newtype wrappers for the GLfoo types, such as GLenum/GLfloat/GLdouble. Using newtypes had the following downsides: * The CPP macros to make these definitions are borrowed verbatim from GHC sources and required updates with new GHC releases in order to stay compatible. Although, it hasn't been a problem yet, it's conceivable this will conflict with supporting different versions of GHC at some point. * Optimization rules have to be written against these newtypes and forgetting them can lead to significant performance degradation or extra verbosity for people using the bindings. * You have to reach pretty deep into GHC to make it possible for the newtypes to work in the unboxed vectors provided by the vector package. This is again, another missed opportunity for high performance code. You can find the source and bug trackers for these packages here: https://github.com/haskell-opengl/ Feedback, pull requests, and bug reports are always welcome! Thanks! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Security] Put haskell.org on https
Thanks Iavor et al. I agree. I'll see what we can do. We have budget for this so hopefully it will be a simple matter of finding people to implement the change. Jason On Fri, Nov 2, 2012 at 10:34 AM, Iavor Diatchki iavor.diatc...@gmail.comwrote: Hello, I think that getting a certificate is a good idea. I think this could probably be arranged by the haskell.org committee, which even has a budget for things like that, I believe. I'm cc-ing Jason, who's on the committee and might have more input on what's the best way to proceed. Thanks for bringing this up! -Iavor On Fri, Nov 2, 2012 at 5:14 AM, Ramana Kumar ramana.ku...@cl.cam.ac.ukwrote: Who is the webmaster for haskell.org? Presumably they will be required in the process of installing the certificate. As far as obtaining goes, one can obtain a free certificate from StartSSL - see https://www.startssl.com There are other CAs, but if nobody has any strong preferences, I recommend going with them. On Tue, Oct 30, 2012 at 8:52 PM, Niklas Hambüchen m...@nh2.me wrote: So how do we go forward about getting the SSL certificate and installing it? On 29/10/12 01:06, Patrick Mylund Nielsen wrote: Sure. No matter what's done in Cabal, the clients for everything else will still be mainly browsers. On Mon, Oct 29, 2012 at 12:59 AM, Niklas Hambüchen m...@nh2.me mailto:m...@nh2.me wrote: No matter what we do with cabal, it would be great if I could soon point my browser at https://haskell.org *anyway*. On 28/10/12 23:55, Patrick Mylund Nielsen wrote: Of course, as long as Cabal itself is distributed through this same https-enabled site, you have the same PKI-backed security as just about any major website. This model has problems, yes, but it's good enough, and it's easy to use. If you really want to improve it (without impacting usability), have Google/the browser vendors pin the public cert for haskell.org http://haskell.org http://haskell.org. On Mon, Oct 29, 2012 at 12:45 AM, Patrick Mylund Nielsen hask...@patrickmylund.com mailto:hask...@patrickmylund.com mailto:hask...@patrickmylund.com mailto:hask...@patrickmylund.com wrote: PGP tends to present many usability issues, and in this case it would make more sense/provide a clearer win if there were many different, semi-untrusted hackage mirrors. Just enable HTTPS and have Cabal validate the server certificate against a CA pool of one. PKI/trusting obscure certificate authorities in Egypt and Syria is the biggest concern here, not somebody MITMing your initial Cabal installation (which in a lot of cases happens through apt-get or yum, anyway.) On Mon, Oct 29, 2012 at 12:34 AM, Changaco chang...@changaco.net mailto:chang...@changaco.net mailto:chang...@changaco.net mailto:chang...@changaco.net wrote: On Sun, 28 Oct 2012 17:07:24 -0400 Patrick Hurst wrote: How do you get a copy of cabal while making sure that somebody hasn't MITMed you and replaced the PGP key? Ultimately it is a DNS problem. To establish a secure connection with haskell.org http://haskell.org http://haskell.org you'd have to get the certificate from the DNS, but that technology is not ready yet, so all you can do is check the key against as many sources as possible like Michael Walker said. On Sun, 28 Oct 2012 17:46:06 -0400 Patrick Hurst wrote: So why not use HTTPS? Because it doesn't solve the problem. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto: Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto: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
[Haskell-cafe] haskell.org committee: Call for nominations
Dear Haskellers, The second year of the haskell.org committee is drawing to a close and it is therefore time to seek replacements for those members whose term is expiring. This year one member has a term ending, Ganesh Sittampalam. Ganesh has been an excellent contributor and the rest of the committee would like to thank him for his excellent service. To nominate yourself, please send an e-mail to committee at haskell.org by 30 November 2012. As usual, retiring members are eligible to re-nominate themselves. Please feel free to include any information about yourself that you think will help us to make a decision. Being a member of the committee does not require a significant amount of time, but committee members should aim to be responsive during discussions when the committee is called upon to make a decision. More details about the committee's roles and responsibilities are on http://www.haskell.org/haskellwiki/Haskell.org_committee If you have any questions about the process, please feel free to e-mail us at committee at haskell.org or to contact one of us individually. Regards, Jason On behalf of the haskell.org committee ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OpenGL library will not load into GHCi 7.6.1 on Win7 x86-64
On Tue, Oct 9, 2012 at 1:55 PM, Dan Haraj devha...@gmail.com wrote: This is a regression of some sort since the library operates fine within GHCi for previous versions of GHC. I don't know whether it is a problem with GHCi, the OpenGL library, or some third party. This is the error encountered when a module that uses OpenGL tries to load: Prelude Main main Loading package OpenGLRaw-1.2.0.0 ... linking ... ghc.exe: unable to load package `OpenGLRaw-1.2.0.0' Prelude Main :q Leaving GHCi. interactive: C:\...\OpenGLRaw-1.2.0.0\ghc-7.6.1\HSOpenGLRaw-1.2.0.0.o: unknown symbol `__imp_wglGetProcAddress' I have very little of an idea of what's going on here. It would be rather painful to debug this myself so any insight is appreciated. I don't know the solution or the culprit, but normally that symbol is defined in opengl32.lib/dll and the OpenGLRaw cabal file mentions it as an extra library. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Galois is hiring!
We're looking for functional programmers, formal methods practitioners, and project leads, interested in either short term or permanent employment. For more information, see: http://corp.galois.com/careers Why Galois? At Galois, we believe in seeking out and solving important problems to make the world a better place. This philosophy runs through everything we do. From internal interactions on an individual level to the interesting technical challenges we take on to the way we orient to the external world. We hire the best people, we help them to better understand their own passions, and then together we take on important problems. It just so happens that we have skilled software engineers with a passion for functional programming who take on challenges in crypto, critical systems, secure networking, and so on. For me, the very compelling reasons to work at Galois are: a strong cultural emphasis on freedom to choose your roles within the organization including seeking external funding to work on whatever you want; strong commitment to open source, and; a cultural emphasis on functional programming and formal methods. What a organization believes has a deep and profound impact on how you spend your time at the organization, who the organization attracts, and what impact the organization will have in the world. We have no shortage of interesting problems to tackle in our quest to make the world a better place. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Heads up: importing the Cabal issue tracker to github next week
Thank you. I was trying to register an account on the trac today to file a bug report but the account registration seems to be broken. I'll wait to file my bug till I can use github's much nicer tracker. Thanks, Jason On Wed, May 16, 2012 at 8:45 PM, Bryan O'Sullivan b...@serpentine.comwrote: I am planning on doing this early next week, probably in two phases. As part of the import process, github will generate a *lot* of notification emails. I'm afraid there is nothing I can do to stem the tide, as github does not provide a mechanism to suppress these. If you have a github account, and you have filed bugs against Cabal in Trac, please brace yourself. ___ 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] hackage hackage accounts
On Tue, May 15, 2012 at 12:11 PM, Dmitry Malikov malikov@gmail.comwrote: Good day. Recently, in irc://#haskell you can see very often replicas of people, who are tired of waiting their hackage accounts. After next release of any package from hackagebot, some depressed people definitely comes out and starts telling to everybody how hard life is without having hackage account. Thank you for pointing this out. I didn't realize that it's hard to get a hackage account right now. I'm not sure what I can directly do, but I'll try some things (like contacting Ross, seeing about having a backup contact or automation). I think the right solution is that everyone can get a hackage account. Jason 11:15 * hackagebot shakespeare 1.0.0.2 - A toolkit for making compile-time interpolated templates http://hackage.haskell.org/** package/shakespeare-1.0.0.2http://hackage.haskell.org/package/shakespeare-1.0.0.2(MichaelSnoyman) 11:15 | I'm still waiting for my Hackage account... ... 15:12 * hackagebot hspec-discover 0.0.0 - Automatically discover and run Hspec tests http://hackage.haskell.org/**package/hspec-discover-0.0.0http://hackage.haskell.org/package/hspec-discover-0.0.0(SimonHengel) 15:13 | Still haven't got my hackage account And so on and so on. Yes, you can tolerate, that a lot of people considered in the order of things for asking lambdabot in public window every day, every hour. Yes, you can tolerate, that every five minutes some another notification from hackagebot will be be appeared, or maybe two or even three in a time. But how can you tolerate, that adding to all that stuff there is a permanent disturbances from the people, who can't submit their packages to hackage because they have no hackage account (frankly speaking, I'm also do not have one, but I've send 5 letters to Ross)? Previously, #haskell's log was really like something readable and interesting. But now it's a robot-like speeches with 2 bots, minimal slightly mixed with something really meaningfull. This raises some questions: 1) Did anyone successfully get their hackage account in last 2 months? Because it's really strange to see some still don't have my hackage account-message and another Ross answer in HC. 2) You should give hackage account for all of ther requiring people or remove hackagebot from #haskell. 3) Could I finally have my hackage account in the amount of all others, please? Dmitry Malikov __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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] New in haskell for old-timers?
On Fri, Mar 30, 2012 at 1:05 PM, Mats Rauhala mats.rauh...@gmail.com wrote: On 11:57 Fri 30 Mar , Brandon Allbery wrote: The legible C thing is probably jhc ( http://repetae.net/computer/jhc/ ). It's GHC's *illegible* registerized C that is being phased out; the slightly-more-legible ANSI C mode used for porting is staying, though. Oh wow, I thought jhc was discontinued, but just checked the repositories and mailing lists and it's alive and well. No idea where I got the idea that it was discontinued. Going a little bit on tangent here, but if I understood correctly, jhc is meant to do more optimization. How does this compare to for example ghc? Both are optimizing compilers, but jhc is intended (by the author) to try different things that ghc. If ghc does it one way, jhc will try to explore other aspects of the design space. The last time this came up, I think someone said that jhc uses GRIN for optimizations: http://www.cafepress.com/haskell_books.12273129 GHC tries to optimize by rewriting and also by conventional means. Both try to specialize away uses of type classes, but as I understand it jhc is far more aggressive, or maybe even has a different run-time representation? Anyway, back to the original topic, some of the big items that I would mention to your friend include: * cabal/cabal-dev * hackage (and some of the better known libraries, Data.Vector/Data.Text/Data.ByteString) * Type Families * Haskell 2010 is the current rev of the language standard Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code idea of project application
On Mon, Mar 19, 2012 at 9:12 PM, Chris Smith cdsm...@gmail.com wrote: On Mon, Mar 19, 2012 at 7:52 PM, Richard O'Keefe o...@cs.otago.ac.nz wrote: As just one example, a recent thread concerned implementing lock-free containers. I don't expect converting one of those to OCaml to be easy... If you translate to core first, then the only missing bit is the atomic compare-and-swap primop that these structures will depend on. Maybe that exists in OCaml, or maybe not... I wouldn't know. If not, it would be perfectly okay to refuse to translate the atomic compare-and-swap primop that lockless data structures will use. That said, though, there are literally *hundreds* of GHC primops for tiny little things like comparing different sized integers and so forth, that would need to be implemented all on top of the interesting task of doing language translation. That should be kept in mind when estimating the task. If, however, you want to make it possible for someone to write code in a sublanguage of Haskell that is acceptable to a Haskell compiler and convert just *that* to OCaml, you might be able to produce something useful much quicker. I'm quite sure, actually, that implementing a usable sublanguage of Haskell in this way would be a much larger project even than translating core. A usable sublanguage of Haskell would need a parser, which could be a summer project all on its own if done well with attention to errors and a sizeable test suite. It would need an implementation of lazy evaluation, which can be quite tricky to get right in a thread-safe and efficient way. It would need type checking and type inference that's just different enough from OCaml that you'd probably have to write a new HM+extensions type checker and inference engine on your own, and *that* could again be far more than a summer project on its own, if you plan to build something of production quality. It would need a whole host of little picky features that involve various kinds of desugarings that represent man-decades worth of work just on their own. After a bit of thought, I'm pretty confident that the only reasonable way to approach this project is to let an existing compiler tackle the task of converting from Haskell proper to a smaller language that's more reasonable to think about (despite the problems with lots of primops... at least those are fairly mechanical). Not because of all the advanced language features or libraries, but just because re-implementing the whole front end of a compiler for even a limited but useful subset of Haskell is a ludicrously ambitious and risky project for GSoC. One can get a prototype up and running with a relatively low amount of effort by translating either GHC's core or stg. While core isn't fully strict, it is a much easier input language than Haskell. Stg is even lower level and easier to translate to imperative machines. I've read two papers where translators were built on or in GHC using this approach in a period that I would assume to be similar to what GSoC provides. In the case of the JVM, performance was an issue and may not be with CLR. The JVM lacking tailcalls and having a GC tuned to the wrong use patterns made optimization hard. I guess the way closures/thunks are implemented on the JVM side can be problematic for GC too; making it easy to run out of permgen space. After reading some papers and talking to the relevant folks a bit, I think the hardest part of translating Haskell to the JVM is building the RTS support. I assume the same will be true, but with different details, in the case of .NET/CLR. Both of the projects I'm thinking of just worked on Haskell 98, but to be good for real programs you want to support lots of RTS features. Once you've solved the RTS problems well enough to get people's attention the hurdle becomes the semantics of the FFI. You'll want to be compatible with the other VM languages. To mirror the critiques of others on this thread, I too have concerns about the community impact of the proposed translator. I'd also like to see this proposal written against an existing FOSS project. For example, if the proposal was to dust off LambdaVM (http://wiki.brianweb.net/LambdaVM/LambdaVM), update it to ghc HEAD and make reasonable progress on the implementation that seems much more useful to me. With that said, actually finishing a Haskell - .NET or Haskell - JVM implementation to the point of usable seems to be a PhD worth of work, not a single summer of work even if F# or Scala is the target language. I could also imagine the proposal being tweaked to talk about some improvement in the internals of GHC that make targeting JVM/CLR easier, although I don't personally know enough about GHC internals to suggest anything. I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [haskell-cafe] Question about 64bit target on Windows platform
I don't know if timeline has been established, but my understanding is that there is a need for this and that the right people are aware of it and looking into it. The GHC trac has a ticket for this: http://hackage.haskell.org/trac/ghc/ticket/1884 On Sun, Mar 4, 2012 at 9:59 PM, C K Kashyap ckkash...@gmail.com wrote: Hi All, Can someone please let me know if there is a 64bit target on Windows on the horizon for GHC? I am trying to push for changing the current implementation in my organization in C++ to Haskell - Our primary targets are Windows and Mac. Not being able to generate 64bit DLL's on Windows would be a big bottleneck. Regards, Kashyap ___ 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] Haskell showcase in 5 minutes
On Mon, Feb 27, 2012 at 7:18 AM, Arnaud Bailly arnaud.oq...@gmail.com wrote: Hello Cafe, I will be (re)presenting Haskell in a Batlle Language event Wednesday evening: A fun and interactive contest where various programming language champions try to attract as much followers as possible in 5 minutes. Having successfully experimented the power of live coding in a recent Haskell introduction for the Paris Scala User Group, I would like to do the same but given the time frame I need a simpler example than the music synthesizer program. So I would like to tap in the collective wisdom looking for some concise, eye-opening, mind-shaking and if possible fun example of what one can achieve in Haskell. Things that sprung to my mind are rather dull: prime factors, fibonacci numbers. Poke around Oleg's website. If you think people would be wowed by type hacks then you can find examples where: * he encodes the law of excluded middle using Haskell types (plus type classes) (http://okmij.org/ftp/Computation/lem.html) * he shows a way to encode arbitrary values in types and then recover them again (http://www.cs.rutgers.edu/~ccshan/prepose/prepose.pdf) He has more than just type hacks, check out his Haskell section: http://okmij.org/ftp/Haskell/ I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI: Overhead of foreign unsafe imports
On Sun, Feb 26, 2012 at 10:36 AM, Yves Parès yves.pa...@gmail.com wrote: Hello, When I was using C code from Python, the overhead put on calling C code by Python was significant. To simplify, say I have on C-side two procedures f and g, I do all the stuff to call them in a row from Python, well I'm better off factorizing: adding on C side a wrapper h procedure that calls them both, and then call h from Python, because then I will have half as much overhead: Instead of SwitchToC - call f - SwitchToPython - SwitchToC - call g - SwitchToPython, the factorization leads to SwitchToC - call f - call g - SwitchToPython, which gives the same result yet is different performance-wise because each switching has a cost. This is painful, because if another time I have to call f and j (another function), then I have to make another wrapper. In Haskell world, now, given that my functions f and g would have been imported using unsafe: foreign import unsafe f f :: Thing - Foo - IO () foreign import unsafe g g :: Stuff - Bar - IO () foreign import unsafe h h :: Thing - Foo - Stuff - Bar - IO () Are doStuff = f x y g z w and doStuff = h x y z w equivalent, or is there an overhead (e.g. due to IO monad, or due to the way the FFI does the calls) when compiled (if need be with optimizations) with GHC? I would expect the second doStuff to be more efficient, but you shouldn't care what I expect! To check what is going on you can use a tool like ghc-core (available on hackage) to see what code GHC is generating. To see the difference in performance you can use a micro benchmark tool like criterion (also on hackage) to quantify performance differences. Once you have a conclusion based on some good evidence, please report back here :) I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll: Have you heard of or used GHC External Core?
On Mon, Feb 13, 2012 at 12:08 PM, James Fisher jameshfis...@gmail.com wrote: Hi all: I'm conducting a poll on Haskellers.com to assess the community importance of GHC External Core. Here's the link: http://www.haskellers.com/poll/7 Is this the same or different than what you get with the -fext-core command? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll: Have you heard of or used GHC External Core?
On Mon, Feb 13, 2012 at 1:24 PM, James Fisher jameshfis...@gmail.com wrote: On Mon, Feb 13, 2012 at 9:01 PM, Jason Dagit dag...@gmail.com wrote: Is this the same or different than what you get with the -fext-core command? The very same. In that case, I'll fill out the survey, but let me explain how I've use it: I was part of a (currently dormant) effort to translate Haskell to Isabelle/HOLCF. We found it easiest to let GHC do much of the front end compilation so that we really only had to work with System Fc. That led us to using the output with -fext-core when translating to Isabelle. I would like to pick the project up again in the future (we lost our isabelle experts and need to find more). If ext-core was not available we could probably make due with ghc-api. Ideally we would be able to translate Haskell directly but there are even more technical challenges there and using ext-core seemed like a good intermediate step to prove that the idea could work. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage 2 maintainership
On Mon, Feb 13, 2012 at 3:44 PM, Ben Gamari bgamari.f...@gmail.com wrote: Hey all, Those of you who follow the Haskell subreddit no doubt saw today's post regarding the status of Hackage 2. As has been said many times in the past, the primary blocker at this point to the adoption of Hackage 2 appears to be the lack of an administrator. It seems to me this is a poor reason for this effort to be held up. Having taken a bit of time to consider, I would be willing to put in some effort to get things moving and would be willing to maintain the haskell.org Hackage 2.0 instance going forward if necessary. You've just made my day :) Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Loading a texture in OpenGL
On Mon, Feb 6, 2012 at 12:00 PM, Clark Gaebel cgae...@csclub.uwaterloo.ca wrote: Using the OpenGL package on Hackage, how do I load a texture from an array? The answer will depend on a few things: * Which OpenGL package you use, for example OpenGL vs. OpenGLRaw * What type of 'array' you use. In the case of the OpenGL package you need to create a PixelData value and pass that on. You can find example code here: https://github.com/dagit/nehe-tuts/blob/447f5471f3e7fe07b44dc5d2d87c4a95be35ce75/lesson06.hs https://github.com/dagit/nehe-tuts/blob/447f5471f3e7fe07b44dc5d2d87c4a95be35ce75/Util.hs In the red book[1], I see their code using glGenTextures and glBindTexture, but I can't find these in the documentation. Are there different functions I should be calling? Yes. As you've noticed the API of the OpenGL package sometimes (often?) differs from that of the C OpenGL api. If that's what you're more familiar with then take a look at OpenGLRaw. Here is how to do the same thing as the previous two links but using OpenGLRaw: https://github.com/dagit/nehe-tuts/blob/master/lesson06.hs https://github.com/dagit/nehe-tuts/blob/master/Util.hs Instead of using Arrays as defined by Haskell98, I would recommend using something else like Data.Vector. The standard arrays must be converted to something else to work with OpenGL. Data.Vector on the other hand allows direct access to the pinned pointer and is thus suitable for use with OpenGL as is. Have you seen JuicyPixels? The version on hackage uses arrays, but the version in github uses vector. I'd recommend using the version from github. It's faster and it will be easier to pass the data to OpenGL: https://github.com/Twinside/Juicy.Pixels Good luck! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Updated OpenGL libraries
Hello, I'm pleased to anounce a minor bug fix release of the OpenGL libraries. This release was prompted by issues and warnings when compiling with ghc-7.4.1. The following packages have been updated: * OpenGLRaw 1.2.0.0 * OpenGL 2.5.0.0 * GLURaw 1.2.0.0 * GLUT 2.3.0.0 Thanks goes out to: * Corey O'Connor * mgajda (github id) * #haskell-game and #haskell on freenode The changes include: * Removing a data type context * Exposing the GLfoo constructors from OpenGLRaw * Deriving Typeable instead of using the now deprecated mkTyCon * Added Eq constraint, necessary now that Num doesn't have an Eq constraint * Tighten constraints in cabal files * Conservative package version bump (X.Y.Z - X.(Y+1).0) As usual, please submit pull requests and bug reports on github: https://github.com/haskell-opengl Thank you! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Again, version conflicting problem with cabal-install
In my experience the diamond of death is typically because: * You install package A that uses C-0.1 * Someone uploads C-0.2 to hackage * Later you 'cabal update', this does not rebuild A to use C-0.2, even though it could. * You install package B that uses C, and cabal builds it with C-0.2 * Now you want to build D that uses A and B, but A requires C-0.1 and B requires C-0.2, even though they could be rebuilt to use the same C. Typically, the constraints on A, B, and D would all accept the same version of C. Except that when they were compiled separately and C changed between building A and B, then the compiled versions become fixed on C-0.1 and C-0.2. It's true that it won't solve it in all cases, but in my experience using cabal-dev made the problem go away. I hope that clarifies. Jason On Fri, Feb 3, 2012 at 7:33 AM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Well, cabal-dev could not resolve the conflict of the diamond. Because the conflict is depending different version at the SAME time. On Fri, Feb 3, 2012 at 9:20 PM, Jason Dagit dag...@gmail.com wrote: On Thu, Feb 2, 2012 at 9:54 PM, Magicloud Magiclouds magicloud.magiclo...@gmail.com wrote: Hello, As I recalled, ghc works in staticly link mode. So after one library is compiled, all its build dependencies are useless. Lost, changed, wheresoever, it does not matter. Then why the problem of version conflicting exists? I'm not sure, but for me this problem has gone away by using cabal-dev to build everything. Jason -- 竹密岂妨流水过 山高哪阻野云飞 And for G+, please use magiclouds#gmail.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C++ Parser?
On Wed, Feb 1, 2012 at 12:42 PM, Yin Wang yinwa...@gmail.com wrote: I have written a C++ parser in Scheme, with a Parsec-style parser combinator library. It can parse a large portion of C++ and I use it to do structural comparison between ASTs. I made some macros so that the parser combinators look like the grammar itself. It's code is at: http://github.com/yinwang0/ydiff/blob/master/parse-cpp.ss A demo of the parse tree based comparison tool is at: http://www.cs.indiana.edu/~yw21/demos/d8-3404-d8-8424.html The bit of information I can tell you about parsing C++: Thank you for the interesting response and example code (that I haven't had a chance to look at yet). How much support do you have for templates? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C++ Parser?
On Tue, Jan 24, 2012 at 2:06 AM, Christopher Brown cm...@st-andrews.ac.uk wrote: Hi, I have stumbled across language-c on hackage and I was wondering if anyone is aware if there exists a full C++ parser written in Haskell? I don't think one exists. I've heard it's quite difficult to get template parsing working in an efficient manner. My understanding is that real C++ compilers use the Edison Design Group's parser: http://www.edg.com/index.php?location=c_frontend For example, the Intel C++ compiler uses the edg front-end: http://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler I thought even microsoft's compiler (which is surprisingly c++ compliant) uses it but I can't find details on google about that. There is at least one open source project using it, rose, so it's not unthinkingable to use it from Haskell: http://rosecompiler.org/ Rose has had working haskell bindings in the past but they have bit rotted a bit. With rose you get support for much more than parsing C++. You also get C and Fortran parsers as well as a fair bit of static analysis. The downside is that rose is a big pile of C++ itself and is hard to compile on some platforms. If you made a BSD3 licensed, fully functional, efficient C++ parser that would be great. If you made it so that it preserves comments and the input well enough to do source to source transformations (unparsing) that would be very useful. I often wish I had rose implemented in Haskell instead of C++. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C++ Parser?
On Tue, Jan 24, 2012 at 6:54 AM, Christopher Brown cm...@st-andrews.ac.uk wrote: Hi Everyone, Thanks for everyone's kind responses: very helpful so far! I fully appreciate and understand how difficult writing a C++ parser is. However I may need one for our new Paraphrase project, where I may be targeting C++ for writing a refactoring tool. Obviously I don't want to start writing one myself, hence I was asking if anyone new about an already existing implementation. Rose looks interesting, I'll check that out, thanks! I did some more digging after sending my email. I didn't learn about GLR parser when I was in school, but that seems to be what the cool compilers use these days. Then I discovered that Happy supports GLR, that is happy! Next I found that GLR supposedly makes C++ parsing much easier than LALR, The reason I wrote Elkhound is to be able to write a C++ parser. The parser is called Elsa, and is included in the distribution below. The elsa documentation should give you a flavor for what needs to be done when making sense of C++: http://scottmcpeak.com/elkhound/sources/elsa/index.html NB: I don't think it's been seriously worked on since 2005 so I assume it doesn't match the latest C++ spec. The grammar that elsa parses is here, one warning is that it doesn't reject all invalid programs (eg., it errs on the side of accepting too much): http://scottmcpeak.com/elkhound/sources/elsa/cc.gr I think the path of least resistance is pure rose without the haskell support. Having said that, I think the most fun direction would be converting the elsa grammar to happy. It's just that you'll have a lot of work (read: testing, debugging, performance tuning, and then adding vendor features) to do. One side benefit is that you'll know much more about the intricacies of C++ when you're done than if you use someone else's parser. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C++ Parser?
On Tue, Jan 24, 2012 at 8:40 AM, Christopher Brown cm...@st-andrews.ac.uk wrote: Hi Jason, Thanks very much for you thoughtful response. I am intrigued about the Happy route: as I have never really used Happy before, am I right in thinking I could take the .gr grammar, feed it into Happy to generate a parser, or a template for a parser, and then go from there? That's the basic idea although the details will be harder than that. Happy is a parser generator (like Bison, Yacc, and ANTLR). Happy and elsa will have very different syntax for their grammar definitions. You could explore taking the elkhound source and instead of generating C++ you could generate the input for happy, if that makes sense. A translation by hand would probably be easiest. I would highly recommend making a few toy parsers with Happy + Alex (alex is like lex or flex) to get a feel for it before trying to use the grammar from elsa. A quick google search pointed me at these examples: http://darcs.haskell.org/happy/examples/ Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GLFW-0.5.0.0 is released
On Sat, Jan 21, 2012 at 4:32 AM, Paul Liu nine...@gmail.com wrote: There is now a new GLFW package on hackage with version number 0.5.0.0. Congrats! [snip] 4. There is an outstanding bug preventing GLFW programs to be invoked from GHCi on OS X. One has to compile before running GLFW programs. Does it still happen with -fno-ghci-sandbox? That fixes these sort of bugs with GLFW-b (and other libraries). If so, then the cause of the problem is the use of thread local storage in the vendor APIs (OpenGL on OSX is an example). I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell Summers of Code retrospective (updated for 2011)
On Sat, Dec 10, 2011 at 6:57 PM, Gwern Branwen gwe...@gmail.com wrote: The Wheel turns, and months come and pass, leaving blog posts that fade into 404s; a wind rose in Mountain View, whispering of the coming Winter... Tonight I sat down and finally looked into the 2011 SoCs to see how they turned out and judge them according to my whimsically arbitrary and subjective standards: http://www.gwern.net/Haskell%20Summer%20of%20Code#results-1 They turned out pretty much as I predicted - but then I *would* say that, wouldn't I? As I've said before. You clearly have a strong opinion about GSoC and care about the projects that are accepted. You should sign up as a mentor next year, even if it's only to review proposals and provide feedback. Especially if you think half of the projects are doomed each year. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to get Cabal to spit out a .a library suitable for linking into C/Objective-C
Did you figure out what you need to know? If not, I would suggest asking this same question but on StackOverflow (assuming you haven't already asked there). Jason On Mon, Dec 19, 2011 at 2:35 PM, David Pollak feeder.of.the.be...@gmail.com wrote: Howdy, I'm trying to figure out how to get Cabal configured to compile and link my Haskell code such that the code can be part of C and/or Objective-C code such that all the Haskell dependencies are rolled into a .a file and can be linked by a normal C linker (e.g., ld). I've been through http://haskell.org/ghc/docs/6.12.2/html/users_guide/ffi-ghc.html#using-own-main and the associated linked, but I'm unable to find out the Cabal incantation to output a library that's linkable into my other code. Any pointers or examples would be greatly appreciated. Thanks, David -- Visi.Pro, Cloud Computing for the Rest of Us http://visi.pro Lift, the simply functional web framework http://liftweb.net Follow me: http://twitter.com/dpp Blog: http://goodstuff.im ___ 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] Code generation and optimisation for compiling Haskell
On Tue, Jan 10, 2012 at 9:25 AM, Steve Horne sh006d3...@blueyonder.co.uk wrote: Also, what papers should I read? Am I on the right lines with the ones I've mentioned above? Thomas Schilling gave you a good response with papers so I will give you a different perspective on where to look. Most of the Haskell implementations were written by academics studying languages and compilers. This is good but it also implies that the implementors are likely to share biases and assumptions. I know of one Haskell compiler in particular that was written by someone who did not know Haskell when starting the project. The compiler was developed to be different than GHC. That person was John Meacham. He created JHC, a work in progress, so you might want to study his compiler and implementation notes as they should provide a different perspective on how to tackle Haskell implementation and optimization. http://repetae.net/computer/jhc/ I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OpenAL bindings?
On Sat, Jan 7, 2012 at 1:26 PM, Yitzchak Gale g...@sefer.org wrote: Jason Dagit wrote: Looks like the repo [1] for the OpenAL bindings that Sven Panne created [2] is no longer available. I assume this is a result of The Great Server Outage of 2011 [3]. [1] http://darcs.haskell.org/packages/OpenAL/ [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OpenAL [3] http://www.haskell.org/pipermail/haskell-cafe/2011-February/088829.html No, darcs.haskell.org is not the community server. It is a separate server that seems to be located at Galois. Ah yes, I always forget which servers are where. I see that the following darcs repositories are available on the community server: http://code.haskell.org/OpenAL/OpenAL http://code.haskell.org/OpenAL/ALUT Hope this helps, Thank you so much! Someone (I guess that's me) should update the wiki. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] OpenAL bindings?
Hello, Looks like the repo [1] for the OpenAL bindings that Sven Panne created [2] is no longer available. I assume this is a result of The Great Server Outage of 2011 [3]. Do other bindings exist (I didn't see any on hackage, google, or the wiki [4])? I can import the source that is available on hackage into a github repo and hack from there, but I wanted to ask first: Is the source of this repo gone for good? As a side note, I have plenty of other repos and things on my plate so I'm not really interested in becoming the maintainer of this binding. Any OpenAL experts interested in taking it over? I know from experience that Sven appears to be MIA in the Haskell community these days. Thanks, Jason -- [1] http://darcs.haskell.org/packages/OpenAL/ [2] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/OpenAL [3] http://www.haskell.org/pipermail/haskell-cafe/2011-February/088829.html [4] http://www.haskell.org/haskellwiki/OpenAL ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you'd design a Haskell-like language, what would you do different?
On Tue, Dec 20, 2011 at 3:10 PM, Chris Wong
chrisyco+haskell-c...@gmail.com wrote:
On Wed, Dec 21, 2011 at 10:53 AM, Matthew Farkas-Dyck
strake...@gmail.com wrote:
With GHC 7.0.3:
$ cat test.hs
class ℝ a where {
test :: a;
};
(∈) :: Eq a = a - [a] - Bool;
x ∈ (y:ys) = x == y || x ∈ ys;
main = putStrLn Two of three ain't bad (^_~);
$ runhaskell test.hs
Two of three ain't bad (^_~)
$
Why not expand it even further?
My experience with Agda makes me think that extending it further can
make it painful to program in. Initially I thought that using unicode
symbols would just make input a bit slower and that editor support
could address that. You know, like writing about math using latex.
My actual experience with Agda was different than that.
I was using Emacs and I found that I needed to make my font size very
large to see all the detail of the unicode symbols clearly enough to
distinguish between them fully. The alternative was using the support
in emacs for displaying the codepoint, as a number, for any glyph I
wanted to distinguish. Perhaps it's still just an issue of editor
support but it left a sour taste in my mouth.
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] terminateProcess leaves zombie processes around
On Wed, Dec 7, 2011 at 7:19 AM, Brandon Allbery allber...@gmail.com wrote: On Wed, Dec 7, 2011 at 06:47, Dan Rosén d...@student.gu.se wrote: I'm using Haskell to run a lot of instances of an Automated Thorem Prover, eprover. I have pasted a smaller version of my program at http://hpaste.org/54954. It runs eprover sequentially on all input files, with a timeout of 100ms. Unfortunately, it leaves a lot of zombie processes around, probably due to the fact that terminateProcess fails to terminate them, even though eprover terminates on SIGTERM. They *do* terminate; a zombie is a dead process waiting for its parent to reap it with waitForProcess. There's also some POSIX stuff you can do to have them auto-reaped, but doing that correctly and portably is somewhat painful. You can use a double fork to make this portable and not painful. It's just that you have to fork twice, which can be expensive in some cases. Explanation here: http://stackoverflow.com/a/881434/5113 Here is a Haskell example from xmonad: http://hackage.haskell.org/packages/archive/xmonad/0.7/doc/html/src/XMonad-Core.html#doubleFork If you're planning to send a SIGTERM later, then double forking may make that harder as I think you'd have to communicate the PID up one level. I hope that helps, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Quickcheck research
On Tue, Nov 22, 2011 at 9:42 AM, wren ng thornton w...@freegeek.org wrote: On 11/22/11 6:09 AM, Macías López wrote: Hello: I'm a Master's student in Computer Science. I have to make a project involving some research, I'm very interested in Quickcheck and I wonder if there are some areas which need work or if there is some potential research topic related to it. In particular I know that Erlang Quickcheck has been worked on a lot and has some features like state machines or C bindings which may be useful to the Haskell community. I would appreciate any directions. Something I think would be nice is to see full integration between SmallCheck and QuickCheck. In particular, I'd like to use SmallCheck to exhaustively search the small cases, and then use QuickCheck in a way that ensures that it only tests on things larger than the ones which have already been tested. One of the problems with mixing the two these days is that QuickCheck often wastes a lot of time checking things that SmallCheck will also test. While the goal may not seem very researchy, it actually gets at one of the main weaknesses of QuickCheck: namely, how to properly control generation of arbitrary values in order to ensure you're testing something helpful. It's too easy to design Arbitrary instances which only generate small values (e.g., half of all lists are the empty list) or which loop forever (because of trying to avoid the too-small problem), which makes me think that Arbitrary isn't the right set of abstractions for controlling coverage of the value space. Especially in the case where you find a counter example it may help to slightly mutate that input and see if cases near it fail or succeed. On a similar line of reasoning, I've wondered if Perlin style noise generation could be applied to get a sort of fuzzing effect. This would be more interesting for cases where writing instances of arbitrary is hard to do but test cases do exist. Apply some sort of pseudo-random noise to your examples and see if your properties still hold. I could see this having applications in parsers. As far as I can tell, no one has used Perlin noise on algebraic structures. It seems to have only been applied to real valued spaces. Imagine having a parse tree then applying noise to the structure of the tree then unparsing the tree back to concrete syntax. You're making the structure noisy instead of just fussing the concrete syntax directly (which should increase the frequency that you change the shape/meaning instead of just changing the tokens in the parse tree). Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is SmallCheck maintained?
On Mon, Nov 14, 2011 at 9:54 AM, Roman Cheplyaka r...@ro-che.info wrote: Hi Cafe, Does anyone currently work on Test.SmallCheck? I recall this being an unfortunate problem from the first release. As I recall the author was interested in getting the concept out there but had no motivation (or was it interest?) in keeping it alive as a project. Sounds to me like you should plan on taking over if no one objects. Good luck, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Mascot
You're quite the artist. I wish I could make stuff like this. Here are some more ideas (based on titles of papers about Haskell): What about making the lamb wear a hair shirt? http://research.microsoft.com/en-us/um/people/simonpj/papers/haskell-retrospective/ Or maybe it could be lazy with class? Jason On Wed, Nov 16, 2011 at 2:49 PM, heathmatlock heathmatl...@gmail.comwrote: On Wed, Nov 16, 2011 at 3:15 PM, Giovanni Tirloni gtirl...@sysdroid.comwrote: On Wed, Nov 16, 2011 at 7:06 PM, heathmatlock heathmatl...@gmail.comwrote: Some might picture a symphony or what looks like newspaper origami when they hear Da, and some might picture food when they hear Curry. I like Da because its simple and Da the lamb rolls smoothly off the tongue. Probably best to open a poll to and let everyone decide. Not trying to complicate things any further but perhaps it'd be better to have a contest on this, just like for the new logo. -- Giovanni You're probably right, I guess someone can create a new poll like the previous one: http://www.cs.cornell.edu/w8/~andru/cgi-perl/civs/results.pl?num_winners=1id=E_d21b0256a4fd5ed7algorithm=beatpath I took Jerzy's suggestions into consideration and made the lamb skinnier, maybe it looks less like a penguin now. http://imgur.com/4oeJz Thanks for the conversation so far, I'm glad there's interest in a mascot. -- Heath Matlock +1 256 274 4225 ___ 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] Symbol collisions with -fhpc
On Tue, Nov 8, 2011 at 9:40 AM, Michael Orlitzky mich...@orlitzky.com wrote: Does anyone know what causes these? This used to work, like, a month ago. It builds fine without the -fhpc. What has changed in that time? New Ghc? New updates from your OS? New code in your project? Because it builds fine without -fhpc it sounds like a ghc bug. What version of ghc and on what OS? Is this 64 bit or 32bit? Basically, I think we need more information to be helpful. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] zlib build failure on recent GHC
On Mon, Nov 7, 2011 at 8:17 AM, Johan Tibell johan.tib...@gmail.com wrote: On Mon, Nov 7, 2011 at 7:53 AM, Ben Gamari bgamari.f...@gmail.com wrote: With GHC 1ece7b27a11c6947f0ae3a11703e22b7065a6b6c zlib fails to build, apparently due to Safe Haskell (bug 5610 [1]). The error is specifically, $ cabal install zlib Resolving dependencies... Configuring zlib-0.5.3.1... Preprocessing library zlib-0.5.3.1... Building zlib-0.5.3.1... [1 of 5] Compiling Codec.Compression.Zlib.Stream ( dist/build/Codec/Compression/Zlib/Stream.hs, dist/build/Codec/Compression/Zlib/Stream.o ) Codec/Compression/Zlib/Stream.hsc:857:1: Unacceptable argument type in foreign declaration: CInt When checking declaration: foreign import ccall unsafe static zlib.h inflateInit2_ c_inflateInit2_ :: StreamState - CInt - Ptr CChar - CInt - IO CInt Codec/Compression/Zlib/Stream.hsc:857:1: Unacceptable argument type in foreign declaration: CInt When checking declaration: foreign import ccall unsafe static zlib.h inflateInit2_ c_inflateInit2_ :: StreamState - CInt - Ptr CChar - CInt - IO CInt Codec/Compression/Zlib/Stream.hsc:857:1: Unacceptable result type in foreign declaration: IO CInt Safe Haskell is on, all FFI imports must be in the IO monad When checking declaration: foreign import ccall unsafe static zlib.h inflateInit2_ c_inflateInit2_ :: StreamState - CInt - Ptr CChar - CInt - IO CInt ... This is a little strange since, a) It's not clear why Safe Haskell is enabled b) The declarations in question seem to be valid Does this seem like a compiler issue to you? This is due to a change in how FFI imports and newtypes work. GHC was recently changed to not allow you to use newtypes in FFI imports unless the constructor of the newtype is in scope. This broke quite a few libraries. I have patched a few of them and I've sent a patch to the zlib maintainer. This seems like a big change. Where should I be watching to know about this ahead of time? I bet I have to fix some of my packages. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] howto best use emacs + tiling WM (Xmonad,DWM)
On Fri, Nov 4, 2011 at 8:55 AM, kaffeepause73 kaffeepaus...@yahoo.de wrote: Hello, I'm using dwm which I really love (ev. consider switching to xmonad). However when I'm working with emacs (programming haskell) und dwm I feel, I'm not as effecient as I eventually could be. -- I can have the shell in one window (to execute the compiled program), but most work happens in emacs (in one screen only). And I have up to buffers in emacs which I find hard to switch between. Even on Xinerama this doesn't really change. When I create new frames for emacs with strg-x 5-2 then I'm sort getting closer to where I would like to be, but then I find myself having to windows on which I switch buffers and I get confused again. What I would like is to tab through the buffers, as I walk through the screens in dwm/xmonad and see the list of buffers as id do so. -- And can directly jump to a specific buffer via e.g. mod-4. I'm thinking that each buffer in emacs gets one frame and occupies one screen and xmonad than gets dynamically 20 or more screens (like tabs). If there is an good solution within emacs and the emacs mode than I'm of course also more than open for it. (my experience with emacs so far: -- only 10 buffers are listed in menue -- speedbar is very nice but works for files not for buffers -- using list all buffers is sort of cluncy as it uses half the screen (my screen splits horizontally I think you'll get xmonad specific advice on this list: http://www.haskell.org/mailman/listinfo/xmonad I'm currently using vim + screen to do my hacking and I love it, but I do wish vim had more IDE smarts at times. Emacs + screen would work equally well. tmux instead of screen is another valid option (tmux is better maintained but screen is more ubiquitous). The default buffer manipulation in emacs is not great. Take a look at things like ido mode: http://www.emacswiki.org/emacs/InteractivelyDoThings It's approximately 3 orders of magnitude better than the default way :) Good luck! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] blog software in Haskell?
On Mon, Oct 31, 2011 at 2:14 AM, Ketil Malde ke...@malde.org wrote: Hi, I just upgraded my server, and set up everything again. Except wordpress, as 1) I'm not too fond of its user interface, and 2) it's a big pile of PHP, difficult to keep updated, and basically a disaster waiting to happen (and in fact, it was hacked at one point). Before I enable it again, is there any alternatives I should consider? Preferably written in Haskell, of course, but other suggestions welcome as well. Not in Haskell, but it looks really promising (and it's driven by version control), I give you Octopress: http://octopress.org/ It's basically jekyll + github. Who knows, maybe you can use Hakyll instead of jekyll. Since you didn't ask for it, I'll include my $0.02 :) I don't worry about my blog being written in Haskell because I don't actually want to spend any time shaving yaks related to running my blog. I use blogspot. It's not great but I pay $0/year and someone else deals with the issues of keeping it secure, keeping it backed up, etc. If you find a cool solution, let us know. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage feature request: E-mail author when a package breaks
On Tue, Nov 1, 2011 at 2:45 AM, Max Bolingbroke batterseapo...@hotmail.com wrote: On 1 November 2011 09:00, Ketil Malde ke...@malde.org wrote: This is where it stranded the last time, IIRC. That sentiment makes me a bit uneasy; so you are the official maintainer of a package on Hackage, but you do not want to hear about it when it fails to compile? Don't forget that some packages fail to compile on Hackage even though they work fine, because e.g. they depend on a third-party C library that is not installed, or depend on some other package that Hackage cannot build. Exactly. Building on hackage only means that it builds on hackage. It doesn't actually mean the code works or fails to build on the actual machines people use. If we had a community run build farm with appropriate sandboxing and people could test their builds there that would be amazing, but that's not the same as checking the build on the hackage machine. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Haskell OpenGL package updates
Several months ago I announced my intent to take over maintainership of the Haskell OpenGL bindings and associated packages. Today I have pushed new minor revisions to hackage. I have updated the following packages: * OpenGL * OpenGLRaw * GLURaw * GLUT The change log is very minor for each of these. For my first release as the new maintainer I opted to be very conservative about changes. Consider this a bug fix release with updated metadata. Please report bugs to either the Haskell OpenGL mailing list or the appropriate issue tracker on the github page: http://www.haskell.org/mailman/listinfo/hopengl https://github.com/haskell-opengl I would like to give a big thank you to the following individuals: Sven Panne Lars Corbjin Dylan Simon Alexey Karakulov Balazs Komuves If you contributed to this release by giving advice, filing a bug report, sending a patch, or in some other way, and I've not listed your name then I apologize for the omission. Going forward I could use help with testing, development, and documentation so if you're interested in OpenGL and Haskell let me know and also keep your eyes out for calls for volunteers. Thank you! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: Haskell OpenGL package updates
On Fri, Oct 28, 2011 at 2:07 PM, Edward Kmett ekm...@gmail.com wrote:
Jason,
Thank you for taking ownership of HOpenGL!
Thanks!
I would like to make a formal request for there to be some way to get access
to either
Graphics.Rendering.OpenGL.Raw.Core31.TypesInternal
or that
Graphics.Rendering.OpenGL.Raw.Core31.Types
re-export the newtype wrappers it places around CDouble and CFloat.
As things stand the only way to work with them is to pointlessly round-trip
through rational or pray that GHC is smart enough to automatically convert
once it sees through the newtype, which it isn't, potentially costing me
orders of magnitude of performance in tight loops in exchange for
implementation freedom the current OpenGL bindings do not use on any
platform.
Yes, it's a real problem. I think there are a couple directions we
could move in (and some may not even be mutually exclusive).
Andy Gill created this workaround:
{-# RULES realToFrac/a-GLfloat realToFrac = \x - GLfloat (realToFrac x)
#-}
{-# RULES realToFrac/GLfloat-a realToFrac = \(GLfloat x) - realToFrac x
#-}
That one helps a lot for most people.
Someone made a libraries proposal that also helps the conversion
situation but I don't have the details handy at the moment.
If you read here, I'd like to get some MArray support in and I think
it's possible, although I haven't the idea I proposed yet:
http://www.haskell.org/pipermail/haskell-cafe/2011-March/090511.html
Another thing we could do is find a different balance between newtypes
and the C types.
I'm totally onboard with exposing all of OpenGLRaw. I think we just
need to sufficiently document the internal bits so that only people
who absolutely need them will use them. That's how I see ByteString
and it seems to be working there.
Thanks for your suggestion (and your pull request on github, yay for
collaborative tools!).
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: diagrams 0.4
On Sun, Oct 23, 2011 at 11:47 AM, Brent Yorgey byor...@seas.upenn.edu wrote: I am pleased to announce the release of version 0.4 of diagrams, a full-featured framework and embedded domain-specific language for declarative drawing. The last announcement was of the 0.1 release; there have been quite a few changes and improvements since then, including: - A new website including a gallery of examples: http://projects.haskell.org/diagrams/gallery.html - A new comprehensive user manual with lots of illustrative examples: http://projects.haskell.org/manual/diagrams-manual.html - New primitive shapes: rounded rectangles, wedges, and a new flexible API for generating polygons - Cubic splines - Basic text support What do you use for text support? I know at one point you were interested in my freetype2 binding (which is still very raw and immature), but you must be using gtk for font loading and rendering? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Thu, Oct 13, 2011 at 12:34 PM, Martin Dybdal dyb...@dybber.dk wrote: On 3 October 2011 12:56, Luis Cabellos cabel...@ifca.unican.es wrote: Hello, all. I want to show you the OpenCL package. I have done this using Jeff Heard OpenCLRaw package, but I create a new one due the lack of updates of the former. # Where to get it * Hackage page (http://hackage.haskell.org/package/OpenCL) * Repository (https://github.com/zhensydow/opencl) * Bugs (https://github.com/zhensydow/opencl/issues) * Examples (https://github.com/zhensydow/opencl/tree/master/examples). # Things: * I write it's high-level binding to OpenCL libraries, but only because I added more types to hide most of the alloc/free of the API, and hide the enums using c2hs enums. * The worst problem of the OpenCLRaw is the bad types it use, I learn to fix 32/64 bits issues with c2hs, and test it on linux machines. * Tested on Linux + NVidia only. * Jason Dagit is helping with Windows, OSX testing in own fork, also the call-conv fork in github has changes to work on Windows Please, Consider it's on experimental status but it works, I need lots of feedbacks for detect posible errors, Thanks, Hi everyone I just found this thread today, as I don't read Haskell-cafe that often (too bad, I know). I have been working on a set of OpenCL bindings for the last months myself, which I'm using to implement an OpenCL backend to the Data.Array.Accelerate library. The work is done at the HIPERFIT research center, Uni. Copenhagen. My bindings are even further from the naming conventions of the OpenCL library, but I really can't see the problem with that. People which are used to programming OpenCL from C/C++ might have to learn how the naming conventions of the Haskell library are, but they only need to do this once. I think it's important to distinguish between being a new API and being a faithful binding to an established API. In reality it ends up as a continuum because an exact one to one mapping is not possible between idiomatic C and idiomatic Haskell. If someone is renaming things or changing the API when not strictly necessary then I would say person is making a new API based on the the old API. My desire is to have a binding which is faithful to the C API and then letting people build new abstractions on top of that. When the mapping between the old and the new naming conventions are learned, they will benefit from having a more clean interface for all future times. (No Haskell hacker should have a problem with a steep learning curve.) I have to disagree here, based largely on my experience with learning other Haskell bindings (for example OpenGL, which I knew from C). If I were to twist your words I could use this to say that we should make Haskell hard to learn. I doubt that's what you meant but it seems dangerously close to me. Probably we have very different goals. You want to make a nice OpenCL-based API for parallel programming and I want a binding that matches the OpenCL api very closely, but not to the point of using Ptr () in many places. It is somewhat troubling that we now have five different interfaces to OpenCL (that I know of), and I think we should join efforts and make one library that is as stable as possible. The five libraries are: I agree that having so many implementations of the binding is odd. I wonder if it's because they cater to different needs. In the case of OpenCLRaw we could reasonably remove it from the list because it's unmaintained and incomplete. And yes, it would be nice to merge efforts. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Thu, Oct 13, 2011 at 12:34 PM, Martin Dybdal dyb...@dybber.dk wrote: On 3 October 2011 12:56, Luis Cabellos cabel...@ifca.unican.es wrote: Hello, all. I want to show you the OpenCL package. I have done this using Jeff Heard OpenCLRaw package, but I create a new one due the lack of updates of the former. # Where to get it * Hackage page (http://hackage.haskell.org/package/OpenCL) * Repository (https://github.com/zhensydow/opencl) * Bugs (https://github.com/zhensydow/opencl/issues) * Examples (https://github.com/zhensydow/opencl/tree/master/examples). # Things: * I write it's high-level binding to OpenCL libraries, but only because I added more types to hide most of the alloc/free of the API, and hide the enums using c2hs enums. * The worst problem of the OpenCLRaw is the bad types it use, I learn to fix 32/64 bits issues with c2hs, and test it on linux machines. * Tested on Linux + NVidia only. * Jason Dagit is helping with Windows, OSX testing in own fork, also the call-conv fork in github has changes to work on Windows Please, Consider it's on experimental status but it works, I need lots of feedbacks for detect posible errors, Thanks, Hi everyone I just found this thread today, as I don't read Haskell-cafe that often (too bad, I know). I have been working on a set of OpenCL bindings for the last months myself, which I'm using to implement an OpenCL backend to the Data.Array.Accelerate library. The work is done at the HIPERFIT research center, Uni. Copenhagen. My bindings are even further from the naming conventions of the OpenCL library, but I really can't see the problem with that. People which are used to programming OpenCL from C/C++ might have to learn how the naming conventions of the Haskell library are, but they only need to do this once. When the mapping between the old and the new naming conventions are learned, they will benefit from having a more clean interface for all future times. (No Haskell hacker should have a problem with a steep learning curve.) It is somewhat troubling that we now have five different interfaces to OpenCL (that I know of), and I think we should join efforts and make one library that is as stable as possible. The five libraries are: * OpenCL * OpenCLRaw * HsOpenCL * hopencl * The library presented by Benedict Gaster at AMD (yet to be released) ( http://developer.amd.com/zones/OpenCLZone/publications/assets/MakingOpenCLSimplewithHaskell.pdf ) My own library is available at https://github.com/HIPERFIT/hopencl and will be released on hackage very soon (next week probably). Please take a look at it. It is currently tested on x86_64 Linux with both the AMD x86/x86_64 bindings and NVIDIAs CUDA bindings. They will probably not work on Windows in their present state, and I don't have access to a Windows machine to test it on. Windows uses stdcall instead of ccall. If you get that right, your bindings are likely to just work. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Tue, Oct 4, 2011 at 12:54 AM, Luis Cabellos cabel...@ifca.unican.es wrote: I understand your point. I didn't know the problems with cross module inlining that Haskell suffers. I learned the BSD3, I think is a good and I'll change it on github and I'll put in the next release. Oh cool. Thanks! I think that's for the best. Someone sent me a link to this offline: https://github.com/judah/HsOpenCL Maybe the two implementations can be merged into one super implementation :) http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clGetDeviceInfo.html I use the pattern get[Type]Info - to get[Type][specificInfo] where specificInfo is the OpenCL name of an enumerate. I don't know if your proposal, I open a ticket on github to think about. I see. My experience with the OpenGL bindings is that it can still be confusing for users of the library. The reason is simple, there are good docs for using the API from C and those docs tend to match the official specification. So people who are new to the Haskell bindings will need some documentation that explains how to go from the C API to the Haskell API. Otherwise users will need to read the source code directly to figure out where the function they need to call is located. Good haddocks help, but that's just one part of the solution. Being able to search for the function by name is also useful, so that's why I proposed adding something on to the end of the function name. So that people using search in their browser on the haddocks or using grep at the command line would find the function(s) they are looking for and (hopefully) minimize time spent searching. It's a shame because, if we had dependent types we could encode the C API directly into Haskell. Thanks and I'll probably look at it some more this weekend. I have a test program I'm working on but I would need to port it to your bindings. Also, if you use the #fun macro from c2hs to create the foreign imports you will need to use at least version 0.16.4 as previous versions do not honor stdcall. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hit a reimplementation of git storage in haskell.
On Tue, Oct 4, 2011 at 2:15 PM, Vincent Hanquez t...@snarc.org wrote: Any comments welcome, Nice! Have you looked at Petr Rockai's hashed-storage? http://hackage.haskell.org/package/hashed-storage-0.5.8 Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Mon, Oct 3, 2011 at 9:04 AM, Jason Dagit dag...@gmail.com wrote: We could have a different version of the function for each return type, clGetDeviceInfo_FPConfig, clGetDeviceInfo_AddressBits, etc. It's a great naming convention but it has the property that someone searching the bindings or the bindings' haddocks for clGetDeviceInfo will find those functions. I meant to say, It's NOT a great naming convention ... Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: OpenCL 1.0.1.3 package
On Mon, Oct 3, 2011 at 3:56 AM, Luis Cabellos cabel...@ifca.unican.es wrote: Hello, all. I want to show you the OpenCL package. I have done this using Jeff Heard OpenCLRaw package, but I create a new one due the lack of updates of the former. # Where to get it * Hackage page (http://hackage.haskell.org/package/OpenCL) * Repository (https://github.com/zhensydow/opencl) * Bugs (https://github.com/zhensydow/opencl/issues) * Examples (https://github.com/zhensydow/opencl/tree/master/examples). # Things: * I write it's high-level binding to OpenCL libraries, but only because I added more types to hide most of the alloc/free of the API, and hide the enums using c2hs enums. * The worst problem of the OpenCLRaw is the bad types it use, I learn to fix 32/64 bits issues with c2hs, and test it on linux machines. * Tested on Linux + NVidia only. * Jason Dagit is helping with Windows, OSX testing in own fork, also the call-conv fork in github has changes to work on Windows Your bindings are a higher quality than the the OpenCLRaw bindings and you're doing good technical work, but I stopped using your bindings for a couple reasons: * The main reason is that I'm not comfortable with the license you're using. The original code by Jeff Heard was BSD3 with an additional copyright notice. Your code is AGPL3. The GPL is known to cause problems with Haskell code due to cross module inlining. I don't know how the A in AGPL changes things. * Some of the exposed function names have been changed from the original name in the OpenCL specification. This is the same thing that was done with the OpenGL bindings and it is very confusing for people who come to the Haskell bindings from the official documentation. I realize that some of the API functions require some bit of name mangling, but I think the current way is not the right way. For example with this function: http://www.khronos.org/registry/cl/sdk/1.0/docs/man/xhtml/clGetDeviceInfo.html We could have a different version of the function for each return type, clGetDeviceInfo_FPConfig, clGetDeviceInfo_AddressBits, etc. It's a great naming convention but it has the property that someone searching the bindings or the bindings' haddocks for clGetDeviceInfo will find those functions. I think this is better than naming it clGetDeviceExtensions, which is not in the OpenCL specification. I'd still be willing to test the changes you have, I just don't want to contribute to your bindings due to the license. I currently thinking of starting my own bindings (Jeff's bindings contain too many small bugs and if I'm going to change most lines of code then I might as well start from scratch so that it can have a standard BSD3 license). Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Can't link OpenCL on Windows
Hello, I'm trying to get the OpenCLRaw bindings to a point where I can use them on windows. I've forked the the OpenCLRaw repo on github so I can make modifications as needed. My branch is here: https://github.com/dagit/OpenCLRaw I've been mostly working out of my FunPtr branch. The issue I'm having is this: I installed AMD's OpenCL SDK, converted their Visual Studio specific .lib file to a file that gcc can handle (.a file), but ghc can't seem to link with it. I get undefined symbols for everything I use in the OpenCL API. I was able to build a trivial C program and link it using the .a file that I generated and gcc from mingw (not from the Haskell install). I'm using the latest windows release of the Haskell platform. These are the steps I used for generating the .a file: http://forums.amd.com/forum/messageview.cfm?catid=390threadid=138890 I used the commands in the example script (e.g., gendef and dlltool). I've tried to use 32bit everything as much as possible, as I know that GHC will want everything to be 32bit, so I don't think it's a 32bit vs. 64bit issue. Does anyone know if there is something different about invoking gcc under ghc instead of the gcc that I get from mingw? I've also played with the ghc command line (I used cabal-dev --verbose=3 to inspect the command line) and I'm still unable to massage it into a working state. Any help would be appreciated! Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can't link OpenCL on Windows
Mystery solved. The OpenCLRaw bindings were set to use ccall but OpenCL uses stdcall. I've updated my branch of the bindings. Details on stackoverflow: http://stackoverflow.com/questions/7391634/cant-link-opencl-on-windows-with-ghc Jason On Mon, Sep 12, 2011 at 10:29 AM, Jason Dagit dag...@gmail.com wrote: Hello, I'm trying to get the OpenCLRaw bindings to a point where I can use them on windows. I've forked the the OpenCLRaw repo on github so I can make modifications as needed. My branch is here: https://github.com/dagit/OpenCLRaw I've been mostly working out of my FunPtr branch. The issue I'm having is this: I installed AMD's OpenCL SDK, converted their Visual Studio specific .lib file to a file that gcc can handle (.a file), but ghc can't seem to link with it. I get undefined symbols for everything I use in the OpenCL API. I was able to build a trivial C program and link it using the .a file that I generated and gcc from mingw (not from the Haskell install). I'm using the latest windows release of the Haskell platform. These are the steps I used for generating the .a file: http://forums.amd.com/forum/messageview.cfm?catid=390threadid=138890 I used the commands in the example script (e.g., gendef and dlltool). I've tried to use 32bit everything as much as possible, as I know that GHC will want everything to be 32bit, so I don't think it's a 32bit vs. 64bit issue. Does anyone know if there is something different about invoking gcc under ghc instead of the gcc that I get from mingw? I've also played with the ghc command line (I used cabal-dev --verbose=3 to inspect the command line) and I'm still unable to massage it into a working state. Any help would be appreciated! Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: cabal-ghci 0.1
On Thu, Sep 8, 2011 at 11:06 PM, Etienne Laurin etie...@atnnn.com wrote: Hello fellow hackers. Here is a helpful package I wrote to ease the development of projects using cabal. It includes a :cabalset ghci command to set ghci options for your project, and a cabal-ghci executable to launch ghci with those options. Is :cabalset custom per project or could I put the same things in my ~/.ghci? Did you know that cabal-dev supports loading your project into ghci? (I'm trying to understand how cabal-ghci is different than existing tools.) Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: cabal-ghci 0.1
On Fri, Sep 9, 2011 at 2:44 PM, Etienne Laurin etie...@atnnn.com wrote: Here is a helpful package I wrote to ease the development of projects using cabal. Is :cabalset custom per project or could I put the same things in my ~/.ghci? Everytime I run :cabalset or cabal-ghci, it looks for a .cabal file in my current directory or any of its parents, it loads the cabal file and it generates a list of ghci options for that project. Did you know that cabal-dev supports loading your project into ghci? Yes :) Sadly, some of my test and build scripts don't yet work with cabal-dev. It sounds like the two projects (cabal-ghci and cabal-dev) should get merged. It sounds like the cabal-ghci features would compliment the other cabal-dev features. Or maybe cabal should support plugins in the way hledger and git supports them. Food for thought. Thanks for explaining the difference! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Trouble with Haddock
On Sun, Aug 28, 2011 at 6:37 AM, anonymous qubi...@gmail.com wrote: First time using haddock. I'm unable to include code examples in the module header. Haddock fails with this error: haddock module header parse failed: Cannot parse header documentation paragraphs It's about 12 lines of code, which doesn't seem like much compared to other packages. e.g. -- | describing module -- -- code -- ... -- code module Foo ( I tried @...@ code blocks, but that didn't work either. If I shorten the code to 3 lines or so, it will work. You'll probably get better help if you include the failing example. Just speaking for myself, I can't spot the problem from the example you've included. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ping haskell.org timeout
On Thu, Aug 25, 2011 at 2:39 PM, Greg Fitzgerald gari...@gmail.com wrote: cabal update hangs. ping haskell.org times out. But haskell.org and hackage webpages are loading just fine. What's going on? Lots of servers turn off ICMP packet responses these days so ping isn't as reliable as it once was for detecting when a server is running. I'm not sure why cabal update would hang. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ping haskell.org timeout
On Thu, Aug 25, 2011 at 9:20 PM, Ketil Malde ke...@malde.org wrote: Jason Dagit dag...@gmail.com writes: On Thu, Aug 25, 2011 at 2:39 PM, Greg Fitzgerald gari...@gmail.com wrote: cabal update hangs. ping haskell.org times out. But haskell.org and hackage webpages are loading just fine. What's going on? Lots of servers turn off ICMP packet responses these days Because users don't really need error messages, that's privileged information for system administrators. I think the reason it gets disabled is typically well intentioned. Besides, if someone is trying to debug http protocol issues using ICMP, they're taking an awfully indirect route. Looks like haskell.org isn't one of them. Good to know. It takes a while to complete with no visual feedback. Perhaps the network is just slow? Or perhaps the web pages are cached somewhere along the way? All of those are plausible, but I heard one of the servers needed some help restarting. I don't know enough about the network topology and setup (or what was wrong with the server) to understand why would cause the behavior Greg was seeing. I do know that several other people were able to run 'cabal update' during that time. The whole thing seems a bit odd to me, but should be behind us for now. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make callCC more dynamic
On Wed, Aug 24, 2011 at 9:19 AM, bob zhang bobzhang1...@gmail.com wrote:
Hi, all
I thought the right type for ContT should be
newtype ContT m a = ContT {runContT :: forall r. (a- m r) - m r}
and
other control operators
shift :: Monad m = (forall r . (a- ContT m r) - ContT m r) - ContT m a
reset :: Monad m = ContT m a - ContT m a
callCC :: ((a- (forall r . ContT m r)) - ContT m a) - ContT m a
unfortunately, I can not make callCC type check, and don't know how to
do it.
I managed to make shift, reset type check
Correct me if I'm wrong, but you're wanting to implement the delimited
form of continuations?
If so, you might take a look at this and the associated papers:
http://hackage.haskell.org/package/CC-delcont
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about data
On Fri, Aug 19, 2011 at 1:45 PM, Thomas DuBuisson thomas.dubuis...@gmail.com wrote: This is not a valid data declaration. You can't have a Float field without any constructor name and have it still of type And the reason why it accepts 'data MathExpr = Float', is because data constructors and types live in separate namespaces. There is already a type called Float in the Prelude, but there is no 'Float' data constructor. (Just pointing this out in case it's not obvious!) Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compilation error in Chapter 5 of Real World Haskell
On Wed, Aug 17, 2011 at 10:37 AM, Paul Reiners paul.rein...@gmail.com wrote: I'm trying to do the following from Chapter 5 of Real World Haskell: Our choice of naming for the source file and function is deliberate. To create an executable, ghc expects a module named Main that contains a function named main. The main function is the one that will be called when we run the program once we've built it. 6 comments ghc -o simple Main.hs SimpleJSON.o ---from http://book.realworldhaskell.org/read/writing-a-library-working-with-json-data.html When I do that, I get this error: C:\ch05ghc -o simple Main.hs SimpleJSON.o [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking simple.exe ... SimpleJSON.o:fake:(.data+0x0): multiple definition of `SimpleJSON_getArray_closure' .\SimpleJSON.o:fake:(.data+0x0): first defined here SimpleJSON.o:fake:(.text+0x54): multiple definition of `SimpleJSON_getArray_info' .\SimpleJSON.o:fake:(.text+0x54): first defined here SimpleJSON.o:fake:(.data+0x4): multiple definition of `SimpleJSON_getObject_closure' .\SimpleJSON.o:fake:(.data+0x4): first defined here What's going wrong here? It's hard to say without being able to compile your example locally. Could you post the exact files Main.hs and SimpleJSON.hs that you are using? I scanned the linked page but it wasn't obvious to me what was in your source files. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Please help me spot where space leak occur.
On Fri, Jul 22, 2011 at 1:54 AM, Olexander Kozlov ookoz...@gmail.com wrote: Jason, thank you for your help. The hint for using -s option is very valuable. It is good to see people answering questions about Haskell here on haskell-cafe. stackoverflow is another good place to ask. This is really matter. I hope I will be helpfull some day too :) As for the question I didn't mention in my psot that Fn can be of arbitrary size. You could extend my solution pretty easily to work for arbitrary size. Now I have another question which I'm concerned with. I used foldl' (strict) in my implementation instead of just foldl (lazy). Does it mean that libraries are to be in two implementations one strict and another one lazy? Because there no way to affect strictness/lazyness of function without modifying its implementation. I' going to ask this question as a separate thread. It doesn't come up that much. It comes up here with your foldl, with Chans, modifyIORef, modifySTRef, and a few things like that. But most of the time you want a lazy version until you spot a space leak. Most of the time the library creator notices and makes a strict version as needed. One of the nice things about Haskell is that you get a choice between lazy and strict, and lazy by default is nice in many ways. Space leaks like this are not usually show stoppers for experienced Haskell folks. Good luck! Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
