Re: [Haskell-cafe] Ticking time bomb
On 01/30/2013 07:27 PM, Edward Z. Yang wrote: https://status.heroku.com/incidents/489 Unsigned Hackage packages are a ticking time bomb. I agree this is terrible, I've started working on this, but this is quite a bit of work and other priorities always pop up. https://github.com/vincenthz/cabal https://github.com/vincenthz/cabal-signature My current implementation generate a manifest during sdist'ing in cabal, and have cabal-signature called by cabal on the manifest to create a manifest.sign. The main issue i'm facing is how to create a Web of Trust for doing all the public verification bits. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On 01/30/2013 10:48 PM, Niklas Hambüchen wrote: You are right, I skipped over that this was actually a server-side exploit - sure, end-to-end signing will help here. it helps also in the HTTP case; a MiTM wouldn't be able to change the package without knowing the private key. more to the point it also help the case with hackage mirrors (or a corrupt hackage admin). -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
Ertugrul Söylemez e...@ertes.de writes: People are using Hackage! +1. And I keep telling people to use it. Sure, it'd be better if they used .debs, .rpms, or whatever goes on Mac and Windows. But that would mean I would need to build those packages, including maintaining systems with the respective OSes. I haven't even managed to do it for the systems I do use. The most simple and obvious threat is here that some random evil person gets a Hackage account, uploads a new version of a common package with a trojan, and waits for unsuspecting users to download and install it. My proposal is: 1. Build the necessary machinery into Cabal to allow signing [...] *MY* proposal is that: 0. Hackage sends an email to the previous uploader whenever a new version of a package is uploaded by somebody else. At least that way, I would be notified if it happened to my packages, and I would be able to check up on the situation, and rectify it. This is not to say that cryptographic signing is the wrong thing to do, but a very simple thing like this, which would probably take all of five minutes to implement, would reduce risk by a substantial amount. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
Hi, Am Mittwoch, den 30.01.2013, 15:07 -0800 schrieb Edward Z. Yang: Nevertheless, I believe we are in violent agreement that cryptographically signed Hackage packages should happen as soon as possible! I don’t think we need hackage support here. Just add a MD5-Sum: field to the .cabal file specifying the checksum of the resulting tarball, and everyone can just check it after downloading. At least with MD5 and modern computers, this should be possible by now or soon. (SCNR) Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI - Approaches to C/C++
Casey Basichis caseybasic...@gmail.com wrote: I'm not entirely sure what you mean. I'm intending on using Ogre for GUI - for which there is the Hogre bindings, but after emailing the DEV about it, I didn't get the impression from his advice that I should be using it for production code. Here is what he suggested: It depends, really. Hogre is good for running Ogre from within Haskell, but it has its limitations. The number one thing people have been struggling with is handling input with hogre - there's Hois (Haskell wrapper for OIS) but it's not perfect (it misses input events), and the other option is having to write some C++ glue. Hogre is a solid proof of concept and you can do some demos with it, but if you're e.g. writing a game it might be a bit of a struggle. In the end it's about how much you value being able to write code in Haskell (or how allergic to C++ you are). I'm on iOS so I imagine those difficulties are compounded. I am using several other C++ libraries for which there are no existing bindings and no Haskell alternative packages that are even remotely close. Are you suggesting it would be better to write all my own FFI bindings for all the needed libraries? That's not what I'm suggesting. It was just too little information to properly judge the difficulty of doing everything in Haskell. Binding to Ogre (or C++ in general) is indeed difficult. If Hogre doesn't work or is too limited, your best option might be to write a C wrapper around the Hogre functionality you need. Another option is to use SDL/OpenGL directly, which may be easier or harder depending on your application. However, if you can build the bridge between your rendering library and Haskell, then Haskell is certainly the better choice. Everything I read suggests that Haskells strengths are in transformation and that interaction is not its strong suit. I am interested in your thoughts and I am open to whatever, but you are the first to suggest that the mix is a bad idea. That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there. Nowadays you can write all sorts of interactive applications in Haskell, including GUIs, TUIs, games, simulations and web applications. However, I've long been waiting for useful bindings to Ogre or Irrlicht, but I'm afraid that it's not going to happen any time soon. Ultimately it's your choice. Let me summarize the possiblities: * C wrapper around Ogre. Easy integration, but need to write the rendering code in C/C++. * Full FFI bindings to Ogre. Difficult integration, but you can write your rendering code in Haskell. * Partial FFI bindings to Ogre. Integration may be somewhat easy, if you do the initialization in Haskell and the actual rendering in C/C++. However, this again requires to write the rendering in C/C++. * Using SDL/OpenGL directly: Everything available for Haskell. May be difficult, because you need to write OpenGL code. I hope, this helps. Greets, Ertugrul -- Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/ signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote: In any case there is no valid excuse for the lack of crypto. It's too easy to attack Hackage, so we need some crypto regardless of what we interpret it as. My proposal is: 1. Build the necessary machinery into Cabal to allow signing keys and packages and verifying the signatures, ideally through GnuPG. Cabal would benefit from that even without cabal-install and Hackage. Seems there's lots of suggestion of using gnupg, which is a perfectly valid answer if cabal was unix only, but i'm not sure it's a valid option considering windows. Sure you can install gnupg somehow, but sounds to me it's going the same problem as gtk2hs on windows. One better way, would be to tap in the 2, work in progress, gnupg haskell replacement: http://hackage.haskell.org/package/openpgp http://hackage.haskell.org/package/hOpenPGP AFAIK, both packages are not yet handling anything related to WoT, but just do the signing/verification (which is same status as my ad-hoc experiment) -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On 01/31/2013 08:16 AM, Ketil Malde wrote: *MY* proposal is that: 0. Hackage sends an email to the previous uploader whenever a new version of a package is uploaded by somebody else. At least that way, I would be notified if it happened to my packages, and I would be able to check up on the situation, and rectify it. you wouldn't in real cases, it just fix the most obvious and simple attack vector. but consider: * someone intercepting your upload http stream, and replacing dynamically your package. * someone gaining malicious access to hackage and planting stuff inside packages. * a rogue hackage admin. * a rogue hackage mirror admin. it's obviously less easy than just creating an account and uploading things on top of other packages, but i don't think we should feel safe if the previous maintainer received an email about the change. For example, previous maintainer might be away from email for a long time potentially leaving a trojan version for days/weeks, or changed email address.. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI - Approaches to C/C++
Quoth Casey Basichis caseybasic...@gmail.com, ... I am using several other C++ libraries for which there are no existing bindings and no Haskell alternative packages that are even remotely close. Are you suggesting it would be better to write all my own FFI bindings for all the needed libraries? Everything I read suggests that Haskells strengths are in transformation and that interaction is not its strong suit. I've done it, for my own amusement - wrapped a C++ graphics toolkit and used it to write a couple small applications. Most of us would probably object to your transformation/interaction evaluation as presented above ... but it depends on your motivations. In my case, I simply wanted to use Haskell, and in fact I started with a model like yours where the UI was simply written in C++. There were some very cumbersome things about that arrangement though, so I was happy to integrate Haskell into the UI as soon as it became possible. On the other hand ... I'd be lying if I said the Haskell code is cleaner, or really advantageous in any compelling way if we're just talking about the UI. It has its moments - Haskell is always going to pull a few things off pretty well, in a UI or whatever - but of course, this particular UI API is specifically more suited to C++, than Haskell. So given that one can write good, clean code in C++, too, the question is whether Haskell is so vastly advantageous for such applications that it compensates for the sketchy binding. It isn't, I think. Whereupon we come to your original question. Personally, I would just work with the model that's natural to your API. If it's a C++ OO 3D graphics library, then go OO, for the very same reasons discussed above. FP may in principle have all the virtues mentioned in that article, and it's good to be on the lookout for ways you can deploy some of that in a C++ program, but when it comes time to use that OO API, it's what you've got. Donn ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
Vincent Hanquez t...@snarc.org wrote: I agree this is terrible, I've started working on this, but this is quite a bit of work and other priorities always pop up. https://github.com/vincenthz/cabal https://github.com/vincenthz/cabal-signature My current implementation generate a manifest during sdist'ing in cabal, and have cabal-signature called by cabal on the manifest to create a manifest.sign. The main issue i'm facing is how to create a Web of Trust for doing all the public verification bits. You don't need it yet. See my other post. Once the basic infrastructure for signatures is established, you can allow the user to have a set of trusted keys. The idea is that users can ask for keys and/or import keys from key servers. In the worst case they accept keys when installing a package. Once you have such a trust database you can allow users to select, whether a key is to be trusted for signing other keys. Then you have basically everything to establish both hierarchial trust relationships (like CAs) and webs of trust. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
Vincent Hanquez t...@snarc.org wrote: For example, previous maintainer might be away from email for a long time potentially leaving a trojan version for days/weeks, or changed email address.. And that may even be more harmful, because an insecure system with a false sense of security is worse than an insecure system alone. Let's do it properly. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (no subject)
Hi Ertugrul, Thank you for the detailed reply. From what you wrote, partial FFI still seems like the way to go. Unfortunately Ogre isn't the only large library I'm using, so difficult several times over sounds like a good way to handicap the project early on. I'm perfectly happy to use Haskell for the strengths that will most benefit my project. I can always go back and try to bring the C++ specific parts into the fold once a prototype is up and running. As it seems there is a great deal of c/c++ to do either way, I would really appreciate so thoughts towards my original question. What practices in C++ are preferred by Haskell users, in the know, for the parts of the app that will not be pure Haskell? Should I be looking to avoid OOP? Dependency Injection? I wont reiterate all the facets of the first post, but it would help me immensely to zero in on a few patterns and strategies that can minimized the damage I inflict in c++ land. Thanks, Casey p.s. With That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there. What do you mean? Which packages should I be looking at? I am on iOS like I said, its a stage 1 GHC compiler so I don't have access to GHCI or template haskell. Casey Basichis caseybasichis at gmail.com wrote: I'm not entirely sure what you mean. I'm intending on using Ogre for GUI - for which there is the Hogre bindings, but after emailing the DEV about it, I didn't get the impression from his advice that I should be using it for production code. Here is what he suggested: It depends, really. Hogre is good for running Ogre from within Haskell, but it has its limitations. The number one thing people have been struggling with is handling input with hogre - there's Hois (Haskell wrapper for OIS) but it's not perfect (it misses input events), and the other option is having to write some C++ glue. Hogre is a solid proof of concept and you can do some demos with it, but if you're e.g. writing a game it might be a bit of a struggle. In the end it's about how much you value being able to write code in Haskell (or how allergic to C++ you are). I'm on iOS so I imagine those difficulties are compounded. I am using several other C++ libraries for which there are no existing bindings and no Haskell alternative packages that are even remotely close. Are you suggesting it would be better to write all my own FFI bindings for all the needed libraries? That's not what I'm suggesting. It was just too little information to properly judge the difficulty of doing everything in Haskell. Binding to Ogre (or C++ in general) is indeed difficult. If Hogre doesn't work or is too limited, your best option might be to write a C wrapper around the Hogre functionality you need. Another option is to use SDL/OpenGL directly, which may be easier or harder depending on your application. However, if you can build the bridge between your rendering library and Haskell, then Haskell is certainly the better choice. Everything I read suggests that Haskells strengths are in transformation and that interaction is not its strong suit. I am interested in your thoughts and I am open to whatever, but you are the first to suggest that the mix is a bad idea. That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there. Nowadays you can write all sorts of interactive applications in Haskell, including GUIs, TUIs, games, simulations and web applications. However, I've long been waiting for useful bindings to Ogre or Irrlicht, but I'm afraid that it's not going to happen any time soon. Ultimately it's your choice. Let me summarize the possiblities: * C wrapper around Ogre. Easy integration, but need to write the rendering code in C/C++. * Full FFI bindings to Ogre. Difficult integration, but you can write your rendering code in Haskell. * Partial FFI bindings to Ogre. Integration may be somewhat easy, if you do the initialization in Haskell and the actual rendering in C/C++. However, this again requires to write the rendering in C/C++. * Using SDL/OpenGL directly: Everything available for Haskell. May be difficult, because you need to write OpenGL code. I hope, this helps. Greets, Ertugrul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI - Approaches to C/C++
Hi Ertugrul, Thank you for the detailed reply. From what you wrote, partial FFI still seems like the way to go. Unfortunately Ogre isn't the only large library I'm using, so difficult several times over sounds like a good way to handicap the project early on. I'm perfectly happy to use Haskell for the strengths that will most benefit my project. I can always go back and try to bring the C++ specific parts into the fold once a prototype is up and running. As it seems there is a great deal of c/c++ to do either way, I would really appreciate so thoughts towards my original question. What practices in C++ are preferred by Haskell users, in the know, for the parts of the app that will not be pure Haskell? Should I be looking to avoid OOP? Dependency Injection? I wont reiterate all the facets of the first post, but it would help me immensely to zero in on a few patterns and strategies that can minimized the damage I inflict in c++ land. Thanks, Casey p.s. With That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there. What do you mean? Which packages should I be looking at? I am on iOS like I said, its a stage 1 GHC compiler so I don't have access to GHCI or template haskell. Casey Basichis caseybasichis at gmail.com wrote: I'm not entirely sure what you mean. I'm intending on using Ogre for GUI - for which there is the Hogre bindings, but after emailing the DEV about it, I didn't get the impression from his advice that I should be using it for production code. Here is what he suggested: It depends, really. Hogre is good for running Ogre from within Haskell, but it has its limitations. The number one thing people have been struggling with is handling input with hogre - there's Hois (Haskell wrapper for OIS) but it's not perfect (it misses input events), and the other option is having to write some C++ glue. Hogre is a solid proof of concept and you can do some demos with it, but if you're e.g. writing a game it might be a bit of a struggle. In the end it's about how much you value being able to write code in Haskell (or how allergic to C++ you are). I'm on iOS so I imagine those difficulties are compounded. I am using several other C++ libraries for which there are no existing bindings and no Haskell alternative packages that are even remotely close. Are you suggesting it would be better to write all my own FFI bindings for all the needed libraries? That's not what I'm suggesting. It was just too little information to properly judge the difficulty of doing everything in Haskell. Binding to Ogre (or C++ in general) is indeed difficult. If Hogre doesn't work or is too limited, your best option might be to write a C wrapper around the Hogre functionality you need. Another option is to use SDL/OpenGL directly, which may be easier or harder depending on your application. However, if you can build the bridge between your rendering library and Haskell, then Haskell is certainly the better choice. Everything I read suggests that Haskells strengths are in transformation and that interaction is not its strong suit. I am interested in your thoughts and I am open to whatever, but you are the first to suggest that the mix is a bad idea. That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there. Nowadays you can write all sorts of interactive applications in Haskell, including GUIs, TUIs, games, simulations and web applications. However, I've long been waiting for useful bindings to Ogre or Irrlicht, but I'm afraid that it's not going to happen any time soon. Ultimately it's your choice. Let me summarize the possiblities: * C wrapper around Ogre. Easy integration, but need to write the rendering code in C/C++. * Full FFI bindings to Ogre. Difficult integration, but you can write your rendering code in Haskell. * Partial FFI bindings to Ogre. Integration may be somewhat easy, if you do the initialization in Haskell and the actual rendering in C/C++. However, this again requires to write the rendering in C/C++. * Using SDL/OpenGL directly: Everything available for Haskell. May be difficult, because you need to write OpenGL code. I hope, this helps. Greets, Ertugrul -- Casey James Basichis Composer - Cartoon Network http://www.caseyjamesbasichis.com caseybasic...@gmail.com 310.387.7540 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez t...@snarc.org wrote: On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote: In any case there is no valid excuse for the lack of crypto. It's too easy to attack Hackage, so we need some crypto regardless of what we interpret it as. My proposal is: 1. Build the necessary machinery into Cabal to allow signing keys and packages and verifying the signatures, ideally through GnuPG. Cabal would benefit from that even without cabal-install and Hackage. Seems there's lots of suggestion of using gnupg, which is a perfectly valid answer if cabal was unix only, but i'm not sure it's a valid option considering windows. Sure you can install gnupg somehow, but sounds to me it's going the same problem as gtk2hs on windows. One better way, would be to tap in the 2, work in progress, gnupg haskell replacement: http://hackage.haskell.org/**package/openpgphttp://hackage.haskell.org/package/openpgp http://hackage.haskell.org/**package/hOpenPGPhttp://hackage.haskell.org/package/hOpenPGP AFAIK, both packages are not yet handling anything related to WoT, but just do the signing/verification (which is same status as my ad-hoc experiment) In this case I think this is the wrong approach. There must be at least one way to work within a trust model that is not fragile. Whether this is fully supported on all platforms is actually not very important. I have pointed out why simply signing packages is fragile and how git is better suited for this task. We are not going to reimplement all the good infrastructure that already exists (gpg, git), so making that a requirement is not a good idea IMO. Basic verification of signatures should work on Windows, I agree. But the underlying WoT should be a little bit more sophisticated. This means it has to be based on standard tools, or it will never happen. Alexander __**_ 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] Ticking time bomb
On Thu, Jan 31, 2013 at 8:16 AM, Ketil Malde ke...@malde.org wrote: Ertugrul Söylemez e...@ertes.de writes: People are using Hackage! +1. And I keep telling people to use it. Sure, it'd be better if they used .debs, .rpms, or whatever goes on Mac and Windows. But that would mean I would need to build those packages, including maintaining systems with the respective OSes. I haven't even managed to do it for the systems I do use. Some people seem to have been confused that by suggesting that cabal is not a package manager, I was suggesting not to use Hackage or cabal at all, or not to bother signing packages. To be clear, I am for the following: - Using Hackage (for storing packages, searching online, downloading to create OS packages) - Using cabal (as a package developer, for testing/creating/uploading packages) - Signing packages on Hackage - this is important for security, and I don't want to detract further from the discussion about how to do it. What I am against is: - Using cabal to install packages and generally as a package manager (e.g. try to use it to delete or upgrade packages). This often ends in tears, because that is not cabal's job and it doesn't do it well! Rather, you should help whoever is making packages for your OS (or start doing this) by packaging the existing cabal packages on Hackage as proper OS packages suitable for install/upgrade/remove etc. This can be largely automated, and the main headaches come from dependency issues, which are a separate problem on Hackage (and which Stackage is aiming to alleviate). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monadic parser vs. combinator parser
Thanks for replies guys. I indeed didn't notice that there are monads and applicatives used in this parser. My thought that monadic parsers are more verbose came from Hutton's paper where the code is definitely less readable than in example I provided. There is one more thing that bothers me. It is easy to write a parser that returns Nothing when parsing fails. But I can't figure out a way to add meaningful error messages so that the user knows where did the parsing fail. I experimented with using Either so that I can use Left to pass error messages but this turned out to be inflexible and clutered the code. I will be greatful for any ideas. Janek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] branching conduits
Hello, I have found the Conduit abstraction to be very well suited to a set of problems I am facing. I am however wondering how to implement branching conduits, and even conduit pools. I am currently in the process of rewriting parts (the simple parts) of the Logstash tool. There is a sample program that I use here: https://github.com/bartavelle/hslogstash/blob/deprecateUtils/examples/RedisToElasticsearch.hs As it can be seen, it uses a Redis source, a conduit that decodes the JSON ByteString into a LogstashMessage, a conduit that stores it into Elasticsearch and outputs the result of that action as an Either, and finally a sink that prints the errors. My problem is that I would like more complex behaviour. For example, I would like to route messages to another server instead of putting them into Elasticsearch when the LogstashMessage has some tag set. But this is just an example, and it is probable I will want much more complex behavior soon. I am not sure how to proceed from here, but have the following ideas: * investigate how the Conduits are made internally to see if I can create a operator similar to $$, but that would have a signature like: Source m (Either a b) - Sink a m r - Sink b m r and would do the branching in a binary fashion. I am not sure this is even possible. * create a mvars connectors constructor, which might have a signature like this: Int -- ^ branch count (LogstashMessage - Int) -- ^ branching function (Sink LogstashMessage m (), [Source m LogstashMessage]) -- ^ a suitable sink, several sources for the other conduits it would internally create a MVar (Maybe LogstashMessage) for each branch, and put putMVar accordingly to the branching function. When the Conduit is destroyed, it will putMVar Nothing in all MVars. the sources would takeMVar, check if it is Nothing, or just proceed as expected. The MVar should guarantee the constant space property, but there is the risk of inter branch blocking when one of the branches is significantly slower than the others. It doesn't really matter to me anyway. And all the branch Sinks would have to have some synchronization mechanism so that the main thread waits for them (as they are going to be launched by a forkIO). This is the simplest scheme I have thought of, and it is probably not a very good one. I am very interested in suggestions here. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
Joachim Breitner m...@joachim-breitner.de wrote: And that may even be more harmful, because an insecure system with a false sense of security is worse than an insecure system alone. Let's do it properly. but don’t overengineer it either. Simply adding to hackage the possibility to store a .asc file next to the tar.gz file that contains the cryptographic signature would be a great start, and allow us to develop a WoT model later on. (I try to resist from wondering whether this could go into hackage1 or only hackage2, and in the latter case, whether that means that we actually have the time to overengineer the system.) In fact, a lot would already be gained by a simple „warn if foo-2.0 is signed with a different key than the version of foo already installed“ on cabal-install and people having a closer look at uploads from different people. Not much infrastructure needed there. That was exactly my suggestion actually. It requires the ability to make and check signatures. The making can be done with external tools like GnuPG, but the checking has to be done by cabal-install. To detect changed keys there also needs to be a trust database, which can be a simple directory in ~/.cabal/ where files are named after the fingerprint of the key it contains. The most important part is a sensible user interface. The whole process should be invisible to the user, until there is a signature error. The first installation of a package will actually generate a handful of signature errors, because the keys are not known yet. This shouldn't be too hard to implement and requires only a small change to Hackage and cabal-install's upload command to begin. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monadic parser vs. combinator parser
Jan Stolarek jan.stola...@p.lodz.pl wrote: Thanks for replies guys. I indeed didn't notice that there are monads and applicatives used in this parser. My thought that monadic parsers are more verbose came from Hutton's paper where the code is definitely less readable than in example I provided. There is one more thing that bothers me. It is easy to write a parser that returns Nothing when parsing fails. But I can't figure out a way to add meaningful error messages so that the user knows where did the parsing fail. I experimented with using Either so that I can use Left to pass error messages but this turned out to be inflexible and clutered the code. I will be greatful for any ideas. Remember that 'Either e' is also a monad. =) Greets, Ertugrul -- Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/ signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monadic parser vs. combinator parser
On Wed, Jan 30, 2013 at 1:21 PM, Jan Stolarek wrote: I will be writing a parser in Haskell and I wonder how to approach the problem. Utrecht University has a course that covers this, among other things. You might find the slides and lecture notes useful: http://www.cs.uu.nl/wiki/TC/CourseMaterials Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On 01/31/2013 10:06 AM, Ertugrul Söylemez wrote: Joachim Breitner m...@joachim-breitner.de wrote: And that may even be more harmful, because an insecure system with a false sense of security is worse than an insecure system alone. Let's do it properly. but don’t overengineer it either. Simply adding to hackage the possibility to store a .asc file next to the tar.gz file that contains the cryptographic signature would be a great start, and allow us to develop a WoT model later on. (I try to resist from wondering whether this could go into hackage1 or only hackage2, and in the latter case, whether that means that we actually have the time to overengineer the system.) In fact, a lot would already be gained by a simple „warn if foo-2.0 is signed with a different key than the version of foo already installed“ on cabal-install and people having a closer look at uploads from different people. Not much infrastructure needed there. That was exactly my suggestion actually. It requires the ability to make and check signatures. The making can be done with external tools like GnuPG, but the checking has to be done by cabal-install. To detect changed keys there also needs to be a trust database, which can be a simple directory in ~/.cabal/ where files are named after the fingerprint of the key it contains. The most important part is a sensible user interface. The whole process should be invisible to the user, until there is a signature error. The first installation of a package will actually generate a handful of signature errors, because the keys are not known yet. This shouldn't be too hard to implement and requires only a small change to Hackage and cabal-install's upload command to begin. That's not a proper solution, and definitively in the warm fuzzy feeling department. What if you install a package for the first time and this package has just been re-uploaded maliciously with a different key and a payload ? What if you're relying on hackage mirrors, what stop this mirror to regenerate all signatures with a new key ? It also make maintainers change difficult, and doing genuine non-maintainer upload. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FFI - Approaches to C/C++
From my experience, these things are needed to get solid (i.e. not flaky software) results. This is not what normal Haskell bindings look like though: 1. Create an interface over the Haskell RTS if you are going to use any of it from C++, and use dependency injection to choose between mock and real implementations. 2. Create a mock implementation of the Haskell side if it is accessed from C++. 3. Create comprehensive C++ only tests (using mock Haskell) that runs cleanly through valgrind. 4. Create as small an interface between C++ and Haskell as possible. 5. If you have a wide API that has little performance implications between Haskell and C++, consider not using the FFI directly, but a higher-level abstraction such as protocol buffers for this part of your API. Alexander On Thu, Jan 31, 2013 at 9:53 AM, Casey Basichis caseybasic...@gmail.comwrote: Hi Ertugrul, Thank you for the detailed reply. From what you wrote, partial FFI still seems like the way to go. Unfortunately Ogre isn't the only large library I'm using, so difficult several times over sounds like a good way to handicap the project early on. I'm perfectly happy to use Haskell for the strengths that will most benefit my project. I can always go back and try to bring the C++ specific parts into the fold once a prototype is up and running. As it seems there is a great deal of c/c++ to do either way, I would really appreciate so thoughts towards my original question. What practices in C++ are preferred by Haskell users, in the know, for the parts of the app that will not be pure Haskell? Should I be looking to avoid OOP? Dependency Injection? I wont reiterate all the facets of the first post, but it would help me immensely to zero in on a few patterns and strategies that can minimized the damage I inflict in c++ land. Thanks, Casey p.s. With That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there. What do you mean? Which packages should I be looking at? I am on iOS like I said, its a stage 1 GHC compiler so I don't have access to GHCI or template haskell. Casey Basichis caseybasichis at gmail.com wrote: I'm not entirely sure what you mean. I'm intending on using Ogre for GUI - for which there is the Hogre bindings, but after emailing the DEV about it, I didn't get the impression from his advice that I should be using it for production code. Here is what he suggested: It depends, really. Hogre is good for running Ogre from within Haskell, but it has its limitations. The number one thing people have been struggling with is handling input with hogre - there's Hois (Haskell wrapper for OIS) but it's not perfect (it misses input events), and the other option is having to write some C++ glue. Hogre is a solid proof of concept and you can do some demos with it, but if you're e.g. writing a game it might be a bit of a struggle. In the end it's about how much you value being able to write code in Haskell (or how allergic to C++ you are). I'm on iOS so I imagine those difficulties are compounded. I am using several other C++ libraries for which there are no existing bindings and no Haskell alternative packages that are even remotely close. Are you suggesting it would be better to write all my own FFI bindings for all the needed libraries? That's not what I'm suggesting. It was just too little information to properly judge the difficulty of doing everything in Haskell. Binding to Ogre (or C++ in general) is indeed difficult. If Hogre doesn't work or is too limited, your best option might be to write a C wrapper around the Hogre functionality you need. Another option is to use SDL/OpenGL directly, which may be easier or harder depending on your application. However, if you can build the bridge between your rendering library and Haskell, then Haskell is certainly the better choice. Everything I read suggests that Haskells strengths are in transformation and that interaction is not its strong suit. I am interested in your thoughts and I am open to whatever, but you are the first to suggest that the mix is a bad idea. That used to be true, but the reason has nothing to do with the language. The problem was that the libraries weren't there. Nowadays you can write all sorts of interactive applications in Haskell, including GUIs, TUIs, games, simulations and web applications. However, I've long been waiting for useful bindings to Ogre or Irrlicht, but I'm afraid that it's not going to happen any time soon. Ultimately it's your choice. Let me summarize the possiblities: * C wrapper around Ogre. Easy integration, but need to write the rendering code in C/C++. * Full FFI bindings to Ogre. Difficult integration, but you can write your rendering code in Haskell. * Partial FFI bindings to Ogre. Integration may be somewhat easy,
Re: [Haskell-cafe] Ticking time bomb
On 01/31/2013 08:54 AM, Alexander Kjeldaas wrote: On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez t...@snarc.org wrote: On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote: In any case there is no valid excuse for the lack of crypto. It's too easy to attack Hackage, so we need some crypto regardless of what we interpret it as. My proposal is: 1. Build the necessary machinery into Cabal to allow signing keys and packages and verifying the signatures, ideally through GnuPG. Cabal would benefit from that even without cabal-install and Hackage. Seems there's lots of suggestion of using gnupg, which is a perfectly valid answer if cabal was unix only, but i'm not sure it's a valid option considering windows. Sure you can install gnupg somehow, but sounds to me it's going the same problem as gtk2hs on windows. One better way, would be to tap in the 2, work in progress, gnupg haskell replacement: http://hackage.haskell.org/**package/openpgphttp://hackage.haskell.org/package/openpgp http://hackage.haskell.org/**package/hOpenPGPhttp://hackage.haskell.org/package/hOpenPGP AFAIK, both packages are not yet handling anything related to WoT, but just do the signing/verification (which is same status as my ad-hoc experiment) In this case I think this is the wrong approach. There must be at least one way to work within a trust model that is not fragile. Whether this is fully supported on all platforms is actually not very important. I have pointed out why simply signing packages is fragile and how git is better suited for this task. We are not going to reimplement all the good infrastructure that already exists (gpg, git), so making that a requirement is not a good idea IMO. Basic verification of signatures should work on Windows, I agree. But the underlying WoT should be a little bit more sophisticated. This means it has to be based on standard tools, or it will never happen. I think you misunderstood me. Having a fully working pgp package, means you have full control of the pgp stack, you don't rely on hard-to-get out tools, and it can be integrated with cabal directly for a full WoT experience. Also git doesn't solve the hackage problem, there's not necessarily a one-to-one mapping between packages and their repositories. -- Vincent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
Vincent Hanquez t...@snarc.org wrote: That was exactly my suggestion actually. It requires the ability to make and check signatures. The making can be done with external tools like GnuPG, but the checking has to be done by cabal-install. To detect changed keys there also needs to be a trust database, which can be a simple directory in ~/.cabal/ where files are named after the fingerprint of the key it contains. The most important part is a sensible user interface. The whole process should be invisible to the user, until there is a signature error. The first installation of a package will actually generate a handful of signature errors, because the keys are not known yet. This shouldn't be too hard to implement and requires only a small change to Hackage and cabal-install's upload command to begin. That's not a proper solution, and definitively in the warm fuzzy feeling department. What if you install a package for the first time and this package has just been re-uploaded maliciously with a different key and a payload ? What if you're relying on hackage mirrors, what stop this mirror to regenerate all signatures with a new key ? It also make maintainers change difficult, and doing genuine non-maintainer upload. See the last point of my post. The last step is to implement proper web of trust functionality, so that some keys can be declared to be signing keys. Then a set of trusted keys can be shipped together with cabal-install. That step is optional, because at least now I can fetch developer keys by other means like a key server. According to my solution Cabal warns for new and changed keys and asks whether to trust them showing a fingerprint. Greets, Ertugrul -- Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/ signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On 31/01/13 09:16, Ketil Malde wrote: *MY* proposal is that: 0. Hackage sends an email to the previous uploader whenever a new version of a package is uploaded by somebody else. At least that way, I would be notified if it happened to my packages, and I would be able to check up on the situation, and rectify it. This is not to say that cryptographic signing is the wrong thing to do, but a very simple thing like this, which would probably take all of five minutes to implement, would reduce risk by a substantial amount. That is an excellent idea, and it should be very simple to add. Of course it doesn't stop all attacks, but it does stop the most obvious one. And it might also prevent some honest mistakes or errors in communication where someone uploads a forked package without permission. Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Teaching haskell and fuzzy logic to high school students
I'm an Italian IT teacher and I would like to introduce functional programming using haskell. As classroom activity, I would like to build-up a simple fuzzy inference engine. Does anyone know if someone has experience in teaching haskell to high school students or something has already been done with fuzzy logic and haskell? I found only this page: http://www.haskell.org/haskellwiki/AI/Logic/Fuzzy with some information and a link to a pubblication (with fee, I didn't download yet). Thanks Claudio ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Teaching haskell and fuzzy logic to high school students
You can get the paper here for free: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.40.1464 On Thu, Jan 31, 2013 at 12:02 PM, claudio wbig...@gmail.com wrote: I'm an Italian IT teacher and I would like to introduce functional programming using haskell. As classroom activity, I would like to build-up a simple fuzzy inference engine. Does anyone know if someone has experience in teaching haskell to high school students or something has already been done with fuzzy logic and haskell? I found only this page: http://www.haskell.org/haskellwiki/AI/Logic/Fuzzy with some information and a link to a pubblication (with fee, I didn't download yet). Thanks Claudio ___ 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] Ticking time bomb
On Thu, Jan 31, 2013 at 11:48 AM, Vincent Hanquez t...@snarc.org wrote: On 01/31/2013 08:54 AM, Alexander Kjeldaas wrote: On Thu, Jan 31, 2013 at 9:26 AM, Vincent Hanquez t...@snarc.org wrote: On 01/31/2013 06:27 AM, Ertugrul Söylemez wrote: In any case there is no valid excuse for the lack of crypto. It's too easy to attack Hackage, so we need some crypto regardless of what we interpret it as. My proposal is: 1. Build the necessary machinery into Cabal to allow signing keys and packages and verifying the signatures, ideally through GnuPG. Cabal would benefit from that even without cabal-install and Hackage. Seems there's lots of suggestion of using gnupg, which is a perfectly valid answer if cabal was unix only, but i'm not sure it's a valid option considering windows. Sure you can install gnupg somehow, but sounds to me it's going the same problem as gtk2hs on windows. One better way, would be to tap in the 2, work in progress, gnupg haskell replacement: http://hackage.haskell.org/package/openpgphttp://hackage.haskell.org/**package/openpgp http://**hackage.haskell.org/package/**openpgphttp://hackage.haskell.org/package/openpgp http://hackage.haskell.org/package/hOpenPGPhttp://hackage.haskell.org/**package/hOpenPGP http://**hackage.haskell.org/package/**hOpenPGPhttp://hackage.haskell.org/package/hOpenPGP AFAIK, both packages are not yet handling anything related to WoT, but just do the signing/verification (which is same status as my ad-hoc experiment) In this case I think this is the wrong approach. There must be at least one way to work within a trust model that is not fragile. Whether this is fully supported on all platforms is actually not very important. I have pointed out why simply signing packages is fragile and how git is better suited for this task. We are not going to reimplement all the good infrastructure that already exists (gpg, git), so making that a requirement is not a good idea IMO. Basic verification of signatures should work on Windows, I agree. But the underlying WoT should be a little bit more sophisticated. This means it has to be based on standard tools, or it will never happen. I think you misunderstood me. Having a fully working pgp package, means you have full control of the pgp stack, you don't rely on hard-to-get out tools, and it can be integrated with cabal directly for a full WoT experience. Also git doesn't solve the hackage problem, there's not necessarily a one-to-one mapping between packages and their repositories. Regarding git, I don't see anyone even suggesting that hackage should support multiple 'signed-off-by's, signing diffs between packages, and signing releases. I don't see anyone supporting 3rd-parties signing packages at will. All of this is significant engineering effort that just won't happen. And even if it does, it still doesn't solve the problem, because all of the above is required to protect our base ghc, cabal-install tools anyways. If cabal-install is hacked, hackage is hacked. And even when all of this is done, a design where there is a set of trusted developers is flawed. The set of trusted developers will increase over time, and there will be the need to restrict which developers can release which package. How do you protect that information, which keys can sign which packages? That information must itself be signed off by someone. If not, ouch some obscure developer in the trusted set hijacked an important package because he was owned. That signing in itself *requires* either consensus or a trusted third party. Consensus is a superior method and IMO required. Actually, all modifications to important packages requires consensus by at least two developers to avoid the threat posed by owned developers. So although it is not a waste of time to secure hackage, it is always going to be slightly fragile as long as ghc is fragile for example, and it just isn't ever going to *really* solve the problem. Git has the ability to solve all of this. So a better use of resources IMO is to skip securing hackage by own means, but to standardize on using git as the infrastructure for securing hackage. Then the same infrastructure that should secure ghc should secure hackage. To explain this in concrete terms, to do this, all that is needed is *something like* the following: 1. Each package on hackage gets its own repository (say on github or similar). (I've actually put all of hackage in a single git repository - it works fine, so there are no relevant size problems) 2. Uploads to hackage either happen through commits to the git repository, or an old-style upload to hackage automatically creates a new anonymous branch in the git repository. 3. The git repository is authorative. Signing releases, code reviews etc. all happens through the git repositories. This gives us all the flexibility of a git-style trust model. 4. If a package
Re: [Haskell-cafe] Ticking time bomb
Vincent Hanquez t...@snarc.org writes: On 01/31/2013 08:16 AM, Ketil Malde wrote: At least that way, I would be notified if it happened to my packages, and I would be able to check up on the situation, and rectify it. you wouldn't in real cases, I wouldn't what? Be notified? Rectify it? it just fix the most obvious and simple attack vector. but consider: Ah, those _real_ cases. Fine, let's see what you got. * someone intercepting your upload http stream, and replacing dynamically your package. * someone gaining malicious access to hackage and planting stuff inside packages. * a rogue hackage admin. * a rogue hackage mirror admin. How often do these things happen, I wonder? I guess a bit more rarely than malware taking control of people's computers, which would simply allow people access to upload passwords _and_ signing keys. So much for that perfect security scheme, huh? Anyway: I don't want to sound negative here, so as a constructive proposal, please replace one of my packages on Hackage, making use of one of those techniques. No hurry, I'll wait. We have this discussion every now and then, and in spite of grand schemes of crypto and signing and whatnot, we _still_ have security holes you could drive a truck through. Why not at least do _something_ to fix that, before we return to the more _interesting_ pursuit of the Perfect Security Scheme? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On Thu, Jan 31, 2013 at 11:40 AM, Vincent Hanquez t...@snarc.org wrote: On 01/31/2013 10:06 AM, Ertugrul Söylemez wrote: Joachim Breitner m...@joachim-breitner.de wrote: And that may even be more harmful, because an insecure system with a false sense of security is worse than an insecure system alone. Let's do it properly. but don’t overengineer it either. Simply adding to hackage the possibility to store a .asc file next to the tar.gz file that contains the cryptographic signature would be a great start, and allow us to develop a WoT model later on. (I try to resist from wondering whether this could go into hackage1 or only hackage2, and in the latter case, whether that means that we actually have the time to overengineer the system.) In fact, a lot would already be gained by a simple „warn if foo-2.0 is signed with a different key than the version of foo already installed“ on cabal-install and people having a closer look at uploads from different people. Not much infrastructure needed there. That was exactly my suggestion actually. It requires the ability to make and check signatures. The making can be done with external tools like GnuPG, but the checking has to be done by cabal-install. To detect changed keys there also needs to be a trust database, which can be a simple directory in ~/.cabal/ where files are named after the fingerprint of the key it contains. The most important part is a sensible user interface. The whole process should be invisible to the user, until there is a signature error. The first installation of a package will actually generate a handful of signature errors, because the keys are not known yet. This shouldn't be too hard to implement and requires only a small change to Hackage and cabal-install's upload command to begin. That's not a proper solution, and definitively in the warm fuzzy feeling department. What if you install a package for the first time and this package has just been re-uploaded maliciously with a different key and a payload ? What if you're relying on hackage mirrors, what stop this mirror to regenerate all signatures with a new key ? It also make maintainers change difficult, and doing genuine non-maintainer upload. It is still useful to protect most users and detect malicious code really quickly. Someone will always have the package installed and will notice, so the intruder will only be able to do very targeted attacks. Basically this creates at chain of trust for each package. What I think you want is a chain of trust between packages. Alexander -- Vincent __**_ 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] Ticking time bomb
Ertugrul Söylemez e...@ertes.de writes: And that may even be more harmful, because an insecure system with a false sense of security is worse than an insecure system alone. Yes. As is clear to all, the current low level of security means that nobody are _actually_ downloading stuff of Hackage, thank God. Hackage just exists for...well, I forget, but certainly not to distribute software. Right. Sarcasm aside, to some extent, this is true. I used to have a cron job 'cabal install'ing my packages off Hackage to ensure that they would compile with the current offering of their dependencies. But I decided it was way too risky, and don't do it anymore. Let's do it properly. You mean like how it was decisively dealt with when this was discussed in 2008? https://github.com/haskell/cabal/issues/207 Or maybe more the way it was firmly handled when it was brought up again in 2010? http://www.haskell.org/pipermail/haskell-cafe/2010-December/087050.html This looks increasingly like that time of year when the problem is pointed out, the crypto geeks get together to construct the Optimal Solution, and then everybody lose interest and move on to greener pastures for a while. Well, I don't think the perfect solution exists, and even if it could be identified, it might not be implemented, and even if were implemented, it might not be used. We've just been incredibly lucky that nothing really bad has happened so far. Let's hope it lasts. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On Thu, Jan 31, 2013 at 12:53 PM, Ketil Malde ke...@malde.org wrote: Ertugrul Söylemez e...@ertes.de writes: And that may even be more harmful, because an insecure system with a false sense of security is worse than an insecure system alone. Yes. As is clear to all, the current low level of security means that nobody are _actually_ downloading stuff of Hackage, thank God. Hackage just exists for...well, I forget, but certainly not to distribute software. Right. Sarcasm aside, to some extent, this is true. I used to have a cron job 'cabal install'ing my packages off Hackage to ensure that they would compile with the current offering of their dependencies. But I decided it was way too risky, and don't do it anymore. Let's do it properly. You mean like how it was decisively dealt with when this was discussed in 2008? https://github.com/haskell/cabal/issues/207 Or maybe more the way it was firmly handled when it was brought up again in 2010? http://www.haskell.org/pipermail/haskell-cafe/2010-December/087050.html This looks increasingly like that time of year when the problem is pointed out, the crypto geeks get together to construct the Optimal Solution, and then everybody lose interest and move on to greener pastures for a while. Well, I don't think the perfect solution exists, and even if it could be identified, it might not be implemented, and even if were implemented, it might not be used. Hehe.. hard to argue against history! :-) Alexander We've just been incredibly lucky that nothing really bad has happened so far. Let's hope it lasts. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ 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] FFI - Approaches to C/C++
On Thu, Jan 31, 2013 at 11:11 AM, Casey Basichis caseybasic...@gmail.comwrote: Hi, I'm working on a project in Haskell and C++ where the former is the brains and the latter is for UI, interaction etc. I've read this http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ and a number of other haskell posts suggesting the OOP is not the way to go. Without trying to emulate functional programming through templates or boost::phoenix, what approaches do you all favor when designing parts of an application in C++? Patterns to embrace or avoid? Should I just use functions and handle things with name spaces? I was thinking about handling the callbacks with boosts signals and slots 2 I know this is not entirely haskell centric, but it is a question for haskell users. Thanks, Casey And then I'm on iOS so I imagine those difficulties are compounded. If you can tolerate the view that Haskell is more of an ideology than a technology, and are willing to explore areas that are technologically disparate but conceptually similar to Haskell maybe you should look at ocaml: http://web.yl.is.s.u-tokyo.ac.jp/~tosh/ocaml-on-iphone/index.html http://psellos.com/ocaml/compile-to-iphone.html Rusi -- http://www.the-magus.in http://blog.languager.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] branching conduits
On Thu, Jan 31, 2013 at 11:48 AM, Simon Marechal si...@banquise.net wrote: Hello, I have found the Conduit abstraction to be very well suited to a set of problems I am facing. I am however wondering how to implement branching conduits, and even conduit pools. I am currently in the process of rewriting parts (the simple parts) of the Logstash tool. There is a sample program that I use here: https://github.com/bartavelle/hslogstash/blob/deprecateUtils/examples/RedisToElasticsearch.hs As it can be seen, it uses a Redis source, a conduit that decodes the JSON ByteString into a LogstashMessage, a conduit that stores it into Elasticsearch and outputs the result of that action as an Either, and finally a sink that prints the errors. My problem is that I would like more complex behaviour. For example, I would like to route messages to another server instead of putting them into Elasticsearch when the LogstashMessage has some tag set. But this is just an example, and it is probable I will want much more complex behavior soon. I am not sure how to proceed from here, but have the following ideas: * investigate how the Conduits are made internally to see if I can create a operator similar to $$, but that would have a signature like: Source m (Either a b) - Sink a m r - Sink b m r and would do the branching in a binary fashion. I am not sure this is even possible. * create a mvars connectors constructor, which might have a signature like this: Int -- ^ branch count (LogstashMessage - Int) -- ^ branching function (Sink LogstashMessage m (), [Source m LogstashMessage]) -- ^ a suitable sink, several sources for the other conduits it would internally create a MVar (Maybe LogstashMessage) for each branch, and put putMVar accordingly to the branching function. When the Conduit is destroyed, it will putMVar Nothing in all MVars. the sources would takeMVar, check if it is Nothing, or just proceed as expected. The MVar should guarantee the constant space property, but there is the risk of inter branch blocking when one of the branches is significantly slower than the others. It doesn't really matter to me anyway. And all the branch Sinks would have to have some synchronization mechanism so that the main thread waits for them (as they are going to be launched by a forkIO). This is the simplest scheme I have thought of, and it is probably not a very good one. I am very interested in suggestions here. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Hi Simon, For your first approach, I think what you're looking to do is combine two Sinks together, something like: combine :: Monad m = Sink i1 m r1 - Sink i2 m r2 - Sink (Either i1 i2) m (r1, r2) Then you'd be able to use the standard $$ and =$ operators on it. I've put up an example implementation here[1]. The majority of the code is simple pattern matching on the different possible combination, but some things to point out: * To simplify, we start off with a call to injectLeftovers. This means that we can entirely ignore the Leftover constructor in the main function. * Since a Sink will never yield values, we can also ignore the HaveOutput constructor. * As soon as either of the Sinks terminates, we terminate the other one as well and return the results. You can also consider going the mutable container route if you like. Instead of creating a lot of stuff from scratch with MVars, you could use stm-conduit[2]. In fact, that package already contains some kind of merging behavior for sources, it might make sense to ask the author about including unmerging behavior for Sinks. Michael [1] https://gist.github.com/4682609 [2] http://hackage.haskell.org/package/stm-conduit ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monadic parser vs. combinator parser
Dnia czwartek, 31 stycznia 2013, Ertugrul Söylemez napisał: Remember that 'Either e' is also a monad. =) I remember - this makes the change from Maybe to Either very easy :) Still I found that adding error message to every combinator and function ads a lot of boilerplate. Also, I experince problem with granularity of the messages, e.g. a message like digit expected is too low-level not helpful without telling user that the problem was in the incorect date format. Janek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] branching conduits
On 31/01/2013 13:50, Michael Snoyman wrote: * To simplify, we start off with a call to injectLeftovers. This means that we can entirely ignore the Leftover constructor in the main function. * Since a Sink will never yield values, we can also ignore the HaveOutput constructor. * As soon as either of the Sinks terminates, we terminate the other one as well and return the results. Your gist is extremely informative to me. I figured it would be something along these lines, but was very scared to try it myself. I have however realized that my first use case doesn't cover my need, as I will want to feed an arbitrary set of sinks with any value ... I started coding right after I sent that mail and wrote this: https://github.com/bartavelle/hslogstash/blob/master/Data/Conduit/Branching.hs It is not very elegant as the branching functions outputs [Int]. I haven't tested it yet, but it should branch with any number of sinks. Another point that might (or might not) be of interest is the distribution of distinct branches on separate threads. You can also consider going the mutable container route if you like. Instead of creating a lot of stuff from scratch with MVars, you could use stm-conduit[2]. In fact, that package already contains some kind of merging behavior for sources, it might make sense to ask the author about including unmerging behavior for Sinks. I did not think of bounded channels. They are a indeed a better match than MVars ! I can see it uses resourceForkIO, which I believe is OK for sources that will be used in your 'main' thread. But for multiple Sinks, you need a way to wait for the all Sinks to terminate. I used stuff from Control.Concurrent.ParallelIO, but I am not sure it is ideal. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] why GHC cannot infer type in this case?
Hi Cafe,
I try to implement little typed DSL with functions, but there is a problem:
compiler is unable to infer type for my functions. It seems that context
is clear, but still GHC complains Could not deduce
It is sad because without type inference the DSL will be very difficult to
use.
Could someone explain me why this happens and how it can be avoided?
I use GHC 7.4.2
I tried to distill the code to show the problem (and full error message
below it).
Thank you!
Dmitry
{-# LANGUAGE GADTs, KindSignatures, DataKinds #-}
module TestExp where
-- Sequence of DSL's types to represent type of tuple
data TSeq where
TSeqEmpty :: TSeq
TSeqCons :: TypeExp - TSeq - TSeq
-- All types allowed in DSL
data TypeExp where
-- Primitive type
TInt16 :: TypeExp
-- Function type is built from types of arguments (TSeq) and type of
result
TFun :: TSeq - TypeExp - TypeExp
-- Sequence of expressions to represent tuple
data Seq (t :: TSeq) where
SeqEmpty :: Seq TSeqEmpty
SeqCons :: Exp w - Seq v - Seq (TSeqCons w v)
data Exp (r :: TypeExp) where
Decl :: (Seq args - Exp r) - Exp (TFun args r)
Call :: Exp (TFun args r) - Seq args - Exp r
Int16 :: Int - Exp TInt16
Add :: Exp TInt16 - Exp TInt16 - Exp TInt16
-- Assumed semantics: fun x = x + 2
-- The following line must be uncommented to compile without errors
-- fun :: Exp (TFun (TSeqCons TInt16 TSeqEmpty) TInt16)
fun = Decl $ \(SeqCons x SeqEmpty) - Add (Int16 2) x
-- eval (Int16 x) = x
-- eval (Call (Decl f) seq) = eval (f seq)
-- eval (Add x y) = eval x + eval y
-- test = eval $ Call fun (SeqCons (Int16 3) SeqEmpty)
- There is full error message:
TestExp.hs:30:53:
Could not deduce (w ~ 'TInt16)
from the context (args ~ TSeqCons w v)
bound by a pattern with constructor
SeqCons :: forall (w :: TypeExp) (v :: TSeq).
Exp w - Seq v - Seq (TSeqCons w v),
in a lambda abstraction
at TestExp.hs:30:16-33
or from (v ~ 'TSeqEmpty)
bound by a pattern with constructor
SeqEmpty :: Seq 'TSeqEmpty,
in a lambda abstraction
at TestExp.hs:30:26-33
`w' is a rigid type variable bound by
a pattern with constructor
SeqCons :: forall (w :: TypeExp) (v :: TSeq).
Exp w - Seq v - Seq (TSeqCons w v),
in a lambda abstraction
at TestExp.hs:30:16
Expected type: Exp 'TInt16
Actual type: Exp w
In the second argument of `Add', namely `x'
In the expression: Add (Int16 2) x
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Announcement - Haskell User Group Frankfurt
Dear Haskellers, for all who are located near Frankfurt, there is a new Meetup kicked off: http://www.meetup.com/Frankfurt-Haskell-User-Group regards Peter Althainz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Yet another Conduit question
I am working with bulk sources and sinks, that is with a type like: Source m [a] Sink [a] m () The problem is that I would like to work on individual values in my conduit. I can have this: concat :: (Monad m) = Conduit [a] m a concat = awaitForever (mapM_ yield) But how can I do it the other way around ? I suppose it involves pattern matching on the different states my conduit might me in. But is that even possible to do it in a non blocking way, that is catenate data while there is something to read (up to a certain threshold), and send it as soon as there is nothing left to read ? Or doesn't that make any sense in the context of Conduits (in the sense that this conduit will be recheck for input before the upstream conduits will have a chance to operate) ? Another approach would be to have a map equivalent: conduitMap :: Conduit i m o - Conduit [i] m [o] But I am not sure how to do this either ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] why GHC cannot infer type in this case?
Hi Dmitry. I try to implement little typed DSL with functions, but there is a problem: compiler is unable to infer type for my functions. It seems that context is clear, but still GHC complains Could not deduce It is sad because without type inference the DSL will be very difficult to use. Could someone explain me why this happens and how it can be avoided? Pattern matches on GADT generally require type information. Type inference in such a case is tricky. GADTs are so powerful that in many cases, there's no unique best type to infer. As a contrived example, consider this datatype and function: data X :: * - * where C :: Int - X Int D :: X a f (C n) = [n] f D = [] What should GHC infer for f? Both f :: X a - [Int] f :: X a - [a] are reasonable choices, but without further information about the context, it's impossible to say which one of the two is better. It is theoretically possible to be more clever than GHC is and infer the types of GADT pattern matches in some cases. However, it is (A) a lot of work to implement and maintain that cleverness, and (B) it is then very difficult to describe when exactly a type signature is required and when it isn't. So GHC adopts the simpler approach and requires type information for all GADT pattern matches, which is a simple and predictable rule. How to prevent such errors in general is difficult to say. In your particular case, there might be an option, though. If you additionally use TypeFamilies and FlexibleInstances, you can define: class MkDecl d where type MkDeclSeq d :: TSeq type MkDeclRes d :: TypeExp decl' :: d - Seq (MkDeclSeq d) - Exp (MkDeclRes d) instance MkDecl (Exp r) where type MkDeclSeq (Exp r) = TSeqEmpty type MkDeclRes (Exp r) = r decl' e = \ SeqEmpty - e instance MkDecl d = MkDecl (Exp w - d) where type MkDeclSeq (Exp w - d) = TSeqCons w (MkDeclSeq d) type MkDeclRes (Exp w - d) = MkDeclRes d decl' f = \ (SeqCons x xs) - decl' (f x) xs decl :: MkDecl d = d - Exp (TFun (MkDeclSeq d) (MkDeclRes d)) decl d = Decl (decl' d) fun = decl $ \ x - Add (Int16 2) x The idea here is to avoid pattern matching on the GADT, and instead use an ordinary Haskell function as an argument to the decl smart constructor. We use the type class and two type families to pack that function (with as many arguments as it has) into the type-level list and wrap it all up in the original Decl. This works because on the outside, no GADT pattern matches are involved, and within the type class instances, the necessary type information is present. This is certainly harder to understand than your original version. On the other hand, it's actually easier to use. (It's entirely possible that my code can be simplified further. I haven't thought about this for very long ...) Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] branching conduits
Hello, Simon. On 31 January 2013 17:24, Simon Marechal si...@banquise.net wrote: On 31/01/2013 13:50, Michael Snoyman wrote: * To simplify, we start off with a call to injectLeftovers. This means that we can entirely ignore the Leftover constructor in the main function. * Since a Sink will never yield values, we can also ignore the HaveOutput constructor. * As soon as either of the Sinks terminates, we terminate the other one as well and return the results. Your gist is extremely informative to me. I figured it would be something along these lines, but was very scared to try it myself. I have however realized that my first use case doesn't cover my need, as I will want to feed an arbitrary set of sinks with any value ... I started coding right after I sent that mail and wrote this: https://github.com/bartavelle/hslogstash/blob/master/Data/Conduit/Branching.hs It is not very elegant as the branching functions outputs [Int]. I haven't tested it yet, but it should branch with any number of sinks. Another point that might (or might not) be of interest is the distribution of distinct branches on separate threads. You can also consider going the mutable container route if you like. Instead of creating a lot of stuff from scratch with MVars, you could use stm-conduit[2]. In fact, that package already contains some kind of merging behavior for sources, it might make sense to ask the author about including unmerging behavior for Sinks. I did not think of bounded channels. They are a indeed a better match than MVars ! I can see it uses resourceForkIO, which I believe is OK for sources that will be used in your 'main' thread. But for multiple Sinks, you need a way to wait for the all Sinks to terminate. I used stuff from Control.Concurrent.ParallelIO, but I am not sure it is ideal. Sorry I've sent my first email of the list, and have no copy to resend it. If you will use stm-conduit you can meet next troubles: 1). early close: if you'll use modern conduit API (yield, await), then try to use $$ on sinkT?Chan very accurate as it will close Channel and so receiver will be also closed. 2). late close: if you'll use resourceForkIO you channel may leave to long, hovewer in much cases you'll be save with forkIO, unless you share resources that was allocated with resourcet. 3). pipeline notifying: if you'll map you branches to different threads you'll need a way to notify that branch is closed (closing channels will be good, but you'll need an additional steps to check if they were closed and either close all pipeline or just forgot this channel). On the other hand you can use one pipeline (and thread) for every branch, then you need approach that was shown in Michael's gist. Run each downstream pipe, and save a result, possibly modifying a list. I'll paste concept that I mailed to you here hovewer in may be not accurate: branch :: [a - m ()] -- it's better to place sink here branch fs = do chs - mapM (\f - (,) f $ newTBMChanIO) fs bracket (mapM (\(f,ch) - forkIO $ sourceTBMChan ch $$ f) chs) (mapM_ killThread) (\_ - do x - await mapM_ (flip writeTBMChan x . snd) chs) as an additional step you can call isTBMChanClosed on channel to check if branch is still alive and filter channel if so. (Previous version contained a filter function that allowes to send value to branches that needs it, hovewer it's less composable) also you may like iochan-conduit package [1], it can give a better results in some cases hovewer, stm-channels is much more general. [1] https://github.com/qnikst/iochan-conduit -- Alexander Vershilov ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] why GHC cannot infer type in this case?
Andres, thank you! Your response is really helpful. I will try to adopt your suggestion. Thank again! Dmitry On Thu, Jan 31, 2013 at 7:27 PM, Andres Löh and...@well-typed.com wrote: Hi Dmitry. I try to implement little typed DSL with functions, but there is a problem: compiler is unable to infer type for my functions. It seems that context is clear, but still GHC complains Could not deduce It is sad because without type inference the DSL will be very difficult to use. Could someone explain me why this happens and how it can be avoided? Pattern matches on GADT generally require type information. Type inference in such a case is tricky. GADTs are so powerful that in many cases, there's no unique best type to infer. As a contrived example, consider this datatype and function: data X :: * - * where C :: Int - X Int D :: X a f (C n) = [n] f D = [] What should GHC infer for f? Both f :: X a - [Int] f :: X a - [a] are reasonable choices, but without further information about the context, it's impossible to say which one of the two is better. It is theoretically possible to be more clever than GHC is and infer the types of GADT pattern matches in some cases. However, it is (A) a lot of work to implement and maintain that cleverness, and (B) it is then very difficult to describe when exactly a type signature is required and when it isn't. So GHC adopts the simpler approach and requires type information for all GADT pattern matches, which is a simple and predictable rule. How to prevent such errors in general is difficult to say. In your particular case, there might be an option, though. If you additionally use TypeFamilies and FlexibleInstances, you can define: class MkDecl d where type MkDeclSeq d :: TSeq type MkDeclRes d :: TypeExp decl' :: d - Seq (MkDeclSeq d) - Exp (MkDeclRes d) instance MkDecl (Exp r) where type MkDeclSeq (Exp r) = TSeqEmpty type MkDeclRes (Exp r) = r decl' e = \ SeqEmpty - e instance MkDecl d = MkDecl (Exp w - d) where type MkDeclSeq (Exp w - d) = TSeqCons w (MkDeclSeq d) type MkDeclRes (Exp w - d) = MkDeclRes d decl' f = \ (SeqCons x xs) - decl' (f x) xs decl :: MkDecl d = d - Exp (TFun (MkDeclSeq d) (MkDeclRes d)) decl d = Decl (decl' d) fun = decl $ \ x - Add (Int16 2) x The idea here is to avoid pattern matching on the GADT, and instead use an ordinary Haskell function as an argument to the decl smart constructor. We use the type class and two type families to pack that function (with as many arguments as it has) into the type-level list and wrap it all up in the original Decl. This works because on the outside, no GADT pattern matches are involved, and within the type class instances, the necessary type information is present. This is certainly harder to understand than your original version. On the other hand, it's actually easier to use. (It's entirely possible that my code can be simplified further. I haven't thought about this for very long ...) Cheers, Andres -- Andres Löh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Call for Participation - ACCAT 2013
[We apologize if you receive multiple copies of this message.] CALL FOR PARTICIPATION == 8th International Workshop on Applied and Computational Category Theory ACCAT 2013 http://accat2013.zib.de/ Satellite Event of ETAPS 2013, Rome, March 17 2013 == Scope = Since the 1960s, the use of category theory in computer science has been a fruitful one, including applications to different areas such as automata theory, algebraic specification, and programming languages, among others. In recent years, techniques and methods from CT have been adopted as a standard research tool, and considered as such in different venues around the world. The ACCAT workshop on Applied and Computational Category Theory has been one of these venues. Since its inception in 2006, ACCAT provided a forum where invited contributors presented their own research on different facets of category theory applied to computer science. Following the tradition, the program of this year edition will include eight invited talks by top researchers in the area: Samson Abramsky Robin B. Cockett Barbara Koenig Ugo Montanari Till Mossakowski Dusko Pavlovic Andrzej Tarlecki Glynn Winskel Despite ACCAT's success, we believe that the current formula of the workshop should be deeply revised. Indeed, we believe that a fully fledged conference is missing where all kinds of applications of category theory to computer science can be presented (like the former CTCS conference, which somehow ended in 2006). Therefore, after the presentations, the workshop will end up with a general discussion among the invited speakers and the attendees. We hope that the outcome of the discussion could be a decision whether to push for such high-level workshop/conference on the application of category theory to computer science, or at least to verify the viability of a further meeting focusing on this issue. For more information, please contact Fabio Gadducci (gaddu...@di.unipi.it) or Ulrike Golas (go...@zib.de). -- Dr. Ulrike Golas Konrad-Zuse-Zentrum für Informationstechnik Berlin Takustr. 7, 14195 Berlin, Germany Tel. +49 30 84185 - 318 go...@zib.de -- www.zib.de/golas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On 01/30/2013 08:27 PM, Edward Z. Yang wrote: https://status.heroku.com/incidents/489 Unsigned Hackage packages are a ticking time bomb. Somewhere else that shall not be mentioned, someone posted this link which points to an interesting solution to this problem: http://www.futurealoof.com/posts/nodemodules-in-git.html It requies a little basic knowledge of the Node Package Manager to understand. Here's a little summary that should it easier to understand for people who are not familiar with NodeJS: The Node Package Manager (npm) is the Node JS equivalent of cabal-install(*). When you install a module (think Haskell package off Hackage) using npm, it installs into a directory called node_modules in the project's directory instead of installing into a global name space. When a NodeJS program imports a required module, it is first looked up in the node_modules directory _before_ looking in the global package database. Since modules *are* their source, you can check all of this into the revision control system of your choice. It seems to me that cabal install could do something very similar to solve many of the cabal hell and potential security issues when users blindly do cabal install. (*) Yeah, yeah, not a package manager. In practice it's being used as one, so... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] linking errors while compile hugs98 in macos
On Thu, Jan 31, 2013 at 1:31 AM, Junior White efi...@gmail.com wrote: Hi Cafe, I downloaded the latest hugs98 source package, unzip and build, I get the following link errors. It seems many symbols are not defined, am I missing same depending libraries? I don't think anyone is maintaining hugs any more. Undefined symbols for architecture x86_64: _environ, referenced from: ___hscore_environ in ccuTP291.o (maybe you meant: ___hscore_environ) environ is a legacy pre-standards interface to the process environment and has been deprecated for a long time; it looks like Mountain Lion no longer exports it at all. More proof that hugs is moribund, if it's still using those ancient interfaces. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type classes, collections, sum types, closures, and a massive headache
Thanks everyone, I very much appreciate your help, and I think it did help. I've spent the last few days implementing a substantial chunk of my system using each of two different techniques. I've ended up going with and ADT containing functions closed over the 'thing'. This seems to be the consensus advice. For the record there was a perfectly viable alternative approach based on existential types (http://www.haskell.org/haskellwiki/Heterogenous_collections#Existential_types, thank Taylor, I'd read that and it didn't register… sigh). From what I could tell from trying them there's not a lot to choose between the two techniques, some small advantages for each. The existential types technique (despite criticism as an anti-patternhttps://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/, thanks Petr) is surprisingly to my taste… what can I say? I ended up going with the ADT because I can shove some additional stuff in it, and since there's still a large exploratory aspect to the project this might matter. Thanks again, Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type classes, collections, sum types, closures, and a massive headache
for your convenience, the correct link: https://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monadic parser vs. combinator parser
On 1/30/13 7:21 AM, Jan Stolarek wrote: I will be writing a parser in Haskell and I wonder how to approach the problem. My first thought was to use monadic parser, e.g. like the one described by Hutton and Meijer in Monadic Parsing in Haskell functional pearl. But then I stumbled upon this: https://github.com/alephnullplex/cradle/tree/master/code/src/Lbach/Parser Monadic parser seems extremely verbose and not very straightforward compared to this one. Psst, result :: a - Parser a (+) :: Parser a - (a - Parser b) - Parser b cf. return :: Monad parser = a - parser a (=) :: Monad parser = parser a - (a - parser b) - parser b You just lose the nice do-notation is all. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Teaching haskell and fuzzy logic to high school students
On Thu, 31 Jan 2013 12:02:12 +0100, claudio wbig...@gmail.com wrote: I found only this page: http://www.haskell.org/haskellwiki/AI/Logic/Fuzzy with some information and a link to a pubblication (with fee, I didn't download yet). I have updated this page, the link now points to a page with free download Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hdbc-odbc not getting any data using mssql stored procedure
Hi,
I am trying to call a stored procedure (exec gp_somestoredproc 123,22)
using microsoft sql server 2008 R2 using hdbc-odbc.
Here is the haskell code:
import Database.HDBC
import Database.HDBC.ODBC
import Control.Monad
import Data.Maybe
import qualified Data.ByteString.Char8 as B
test1 = do
c - connectODBC Driver={SQL Server};Server=?;Database=?;uid=sa;pwd=?;
p - prepare c exec gp_somestoredproc 123,22 -- returns no data
-- p - prepare c exec [sys].sp_datatype_info_100 0,@ODBCVer=4;exec
gp_somestoredproc 123,22 -- all is good
e - execute p [] -- returns 6 (number of rows)
putStrLn $ execute ++ show e
r - fetchAllRows' p
putStrLn $ fetchAllRows' ++ show r
The problem is that this code returns the number of rows correctly but
doesn't return data nor are there any errors.
However, I ran a perl program using perl dbi and got the data correctly.
Here is the perl code:
#!/usr/bin/perl
use DBI;
my $user = 'sa';
my $pw = '';
my $dsn = '';
my $dbh = DBI-connect(dbi:ODBC:$dsn, $user, $pw,
{PrintError = 1, RaiseError = 1});
if (!$dbh) {
print error: connection: $DBI::err\n$DBI::errstr\n$DBI::state\n;
}
my $type_info = $dbh-type_info(93);
while(my($key, $value) = each(%$type_info)){
print $key = $value\n;
};
my $sql = exec gp_somestoredproc 123,22;
my $sth = $dbh-prepare($sql);
my $r = $sth-execute;
while (my ($db) = $sth-fetchrow_array) {
print $db . \n===\n;
}
$dbh-disconnect if $dbh;
I traced both versions and noticed that the perl dbi version first called
exec [sys].sp_datatype_info_100 0,@ODBCVer=4
So I prefixed the stored proc call in haskell with exec
[sys].sp_datatype_info_100 0,@ODBCVer=4; and it worked fine.
In short:
FAILS p - prepare c exec gp_somestoredproc 123,22 -- returns number of
rows
but no data
WORKS p - prepare c exec [sys].sp_datatype_info_100 0,@ODBCVer=4;exec
gp_somestoredproc 123,22
I have no idea why this works.
sp_datatype_info_100 just dumps out the fields types ...
More information:
The stored procedure returns data with user defined field types.
I have managed to do selects against tables with user defined field types
without any problems using hdbc-odbc.
I couldn't emulate this error on a local older version of mssql server
(Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64) express) but the perl dbi
prefixed the stored procedure call with exec sp_datatype_info 0,@ODBCVer=3
I am running this against Microsoft SQL Server 2008 R2 (RTM) - 10.50.1797.0
(X64)
I would appreciate any pointers you can give me.
Thanks
Grant
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
Git has the ability to solve all of this. ... 2. Uploads to hackage either happen through commits to the git repository, or an old-style upload to hackage automatically creates a new anonymous branch in the git repository. 3. The git repository is authorative. Signing releases, code reviews etc. all happens through the git repositories. This gives us all the flexibility of a git-style trust model. ... 5. Who owns which package names can be held in a separate meta-tree git repository, and can have consensus requirements on commits. 6. This special meta-tree can also contain suggested verification keys for commits to the other hackage git trees. It can even contain keys that protect Haskell namespaces in general, so that no hackage package can overwrite a protected Haskell namespace. 7. As backward compatibility, the meta-tree can sign simple hashes of already existing packages on hackage. ... 1. There could be some git magic script that downloads the signed git tag objects only (small data set). Then another script would generate a git-compatible SHA1 of the extracted tarball, given that the tarball was fetched from hackage. 2. Or cabal-install could fetch directly from git repositories and use standard git verification. 3. Or a trusted machine creates tarballs from the git repositories, signs them and uploads them to hackage. Without details of git's trust/verification model, it's difficult to see how this particular SCM tool provides the trust capabilities being discussed any better than a more focused solution. Additionally, the use of git is also difficult for many Windows users (80MB installed footprint, last I tried). git has a much broader solution space than simply ensuring the integrity of package downloads, especially when there could be some git magic script that is still not identified and appears to have the same insecurities as the package download/upload itself. Instead of using the git solution and looking for problems to solve with it, IMHO we should work from clearly defined problem to solution in general terms as our class, and then determine what specific tools represent an instance of that solution class. -- -KQ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] linking errors while compile hugs98 in macos
Sadly! I like hugs because it can embed in my game client as lua. For game logic language, I think the following properties are important: 1. Portable, works on pc,macosx,ios,android even flash or web. 2. Intepret, for quick develop, quick test. 3. Hot code load, for online bugfix. 4. Small, game client need to be as small as possiable So that lua best fits the rule very well, but i like haskell much more. After doing some research, I find in the haskell world, there is a hugs fits my demands. I'm sad to know that no one is maintaining hugs any more. I asking someone to keep develop on it, if no one, can I do it myself? On Fri, Feb 1, 2013 at 1:42 AM, Brandon Allbery allber...@gmail.com wrote: On Thu, Jan 31, 2013 at 1:31 AM, Junior White efi...@gmail.com wrote: Hi Cafe, I downloaded the latest hugs98 source package, unzip and build, I get the following link errors. It seems many symbols are not defined, am I missing same depending libraries? I don't think anyone is maintaining hugs any more. Undefined symbols for architecture x86_64: _environ, referenced from: ___hscore_environ in ccuTP291.o (maybe you meant: ___hscore_environ) environ is a legacy pre-standards interface to the process environment and has been deprecated for a long time; it looks like Mountain Lion no longer exports it at all. More proof that hugs is moribund, if it's still using those ancient interfaces. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yet another Conduit question
Firstly, what's the use case that you want to deal with lists? If it's for efficiency, you'd probably be better off using a Vector instead. But I think the inverse of `concat` is `singleton = Data.Conduit.List.map return`, or `awaitForever $ yield . return`, using the list instance for Monad. Your conduitMap could be implemented then as: conduitMap conduit = concat =$= conduit =$= singleton Michael On Thu, Jan 31, 2013 at 5:12 PM, Simon Marechal si...@banquise.net wrote: I am working with bulk sources and sinks, that is with a type like: Source m [a] Sink [a] m () The problem is that I would like to work on individual values in my conduit. I can have this: concat :: (Monad m) = Conduit [a] m a concat = awaitForever (mapM_ yield) But how can I do it the other way around ? I suppose it involves pattern matching on the different states my conduit might me in. But is that even possible to do it in a non blocking way, that is catenate data while there is something to read (up to a certain threshold), and send it as soon as there is nothing left to read ? Or doesn't that make any sense in the context of Conduits (in the sense that this conduit will be recheck for input before the upstream conduits will have a chance to operate) ? Another approach would be to have a map equivalent: conduitMap :: Conduit i m o - Conduit [i] m [o] But I am not sure how to do this either ... ___ 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] linking errors while compile hugs98 in macos
On Thu, Jan 31, 2013 at 10:15 PM, Junior White efi...@gmail.com wrote: So that lua best fits the rule very well, but i like haskell much more. After doing some research, I find in the haskell world, there is a hugs fits my demands. I'm sad to know that no one is maintaining hugs any more. I asking someone to keep develop on it, if no one, can I do it myself? Probably you could, but the effort needed might be significant. In particular fixing things like environ see https://bugs.ruby-lang.org/attachments/2591/ruby-changes.patch for the kind of change you'll need to make, although I have to say the way they chose to do it is risky at best (but sadly typical). Probably something similar for other missing symbols; feel free to ask me for help in private email. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yet another Conduit question
On 02/01/2013 05:21 AM, Michael Snoyman wrote: Firstly, what's the use case that you want to deal with lists? If it's for efficiency, you'd probably be better off using a Vector instead. That is a good point, and I wanted to go that way, but was not sure it would help me a lot here. My use case is for services where there is a bulk API, such as Redis pipelining or Elasticsearch bulk inserts. The network round-trip gains would exceed by far those from a List to Vector conversion. But I think the inverse of `concat` is `singleton = Data.Conduit.List.map return`, or `awaitForever $ yield . return`, using the list instance for Monad. Your conduitMap could be implemented then as: conduitMap conduit = concat =$= conduit =$= singleton I can see how to do singleton, but that would gain me ... singletons. That means I could not exploit a bulk API. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yet another Conduit question
On Fri, Feb 1, 2013 at 8:42 AM, Simon Marechal si...@banquise.net wrote: On 02/01/2013 05:21 AM, Michael Snoyman wrote: Firstly, what's the use case that you want to deal with lists? If it's for efficiency, you'd probably be better off using a Vector instead. That is a good point, and I wanted to go that way, but was not sure it would help me a lot here. My use case is for services where there is a bulk API, such as Redis pipelining or Elasticsearch bulk inserts. The network round-trip gains would exceed by far those from a List to Vector conversion. But I think the inverse of `concat` is `singleton = Data.Conduit.List.map return`, or `awaitForever $ yield . return`, using the list instance for Monad. Your conduitMap could be implemented then as: conduitMap conduit = concat =$= conduit =$= singleton I can see how to do singleton, but that would gain me ... singletons. That means I could not exploit a bulk API. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe So you're saying you want to keep the same grouping that you had originally? Or do you want to batch up a certain number of results? There are lots of ways of approaching this problem, and the types don't imply nearly enough to determine what you're hoping to achieve here. Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Why does not zipWith' exist
Hello, Many texts explain the following Fibonacci code: fibs :: [Integer] fibs = 0 : 1 : zipWith (+) fibs (tail fibs) But this code is very slow because evaluation of (+) is done lazily. If we have the following strict zipWith', the code above becomes much faster. zipWith' f (a:as) (b:bs) = x `seq` x : zipWith' f as bs where x = f a b zipWith' _ _ _ = [] Data.List defines foldl' against foldl. But it does not define zipWith'. I'm curious why zipWith' does not exist in the standard libraries. --Kazu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
