Re: [Haskell-cafe] Heads up: planned removal of String instances from HTTP package
Maybe (just my 2 cents!) since you are going to broke the API anyway, go for it and seize the occasion to really clean up :) Obviously I'm saying this from a non-http-user point of view, maybe if I had some code in production affected by this, my suggestion would have been different :P Regards, A. On 30 January 2013 07:00, Ganesh Sittampalam gan...@earth.li wrote: On 29/01/2013 22:46, Johan Tibell wrote: On Tue, Jan 29, 2013 at 2:15 PM, Ganesh Sittampalam gan...@earth.li wrote: tl;dr: I'm planning on removing the String instances from the HTTP package. This is likely to break code. Obviously it will involve a major version bump. I think it's the right thing to do. Providing a little upgrade guide should help things to go smoother. One obvious cheap-and-dirty migration is via a newtype wrapper for String that embeds the old broken behaviour (char8 encoding). Perhaps the package should provide that? (with appropriate warnings etc) Ganesh ___ 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] list comprehansion performance has hug different
The difference is what's called dynamic programming (an utterly non-intuitive and un-insightful name). It was meant to be. The name was chosen to be truthful while not revealing too much to a US Secretary of Defense of whom Bellman wrote: His face would suffuse, he would turn red, and he would get violent if people used the term, research, in his presence. You can imagine how he felt, then, about the term, mathematical. (http://en.wikipedia.org/wiki/Dynamic_programming) Every time I try to imagine this guy having Haskell explained to him my brain refuses to co-operate. The word programming here is used in the same sense as in linear programming and quadratic programming, that is, optimisation. Dynamic does hint at the multistage decision process idea involved. ___ 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
On 29/01/2013, at 12:43 PM, Bob Hutchison hutch-li...@recursive.ca wrote: The immediate problem is mapping an input to the system, some json message containing a reference to the 'thing' (like a key of some kind). I have to take that reference and find the thing and operate on it. All operations are easily accommodated by a type class. However, since I can't have a collection with mixed types even if the types satisfy a type class, I can't quite see how to actually store the things so I can find them. So there are a couple of obvious ways to handle this. I could use an ADT and a sum type of all the known kinds of thing, but I already know that this has to be extended and that's going to be problematic with users doing this on their own. And the type signatures look ugly. So I think that's not the best. I could use an ADT that contains functions that correspond to the functions of the type class, and that close over the 'thing' in question. I think this could be made to work, but I'm concerned with walking into more nasty surprises… My advice is to go for the latter option. I'm not sure what nasty surprises you are expecting, but this record of functions approach is the one that I normally take when I am building a system that needs new types added without requiring global changes. I know that existentials and GADTs are possible solutions, but I've not needed the extra complexity here. Cheers, Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] list comprehansion performance has hug different
From the conclusion that both programs compute the same result it can be concluded that the fact that you have made use of a list comprehension has forced you to make a choice which should not matter, i.e. the order in which to place the generators. This should be apparent from your code. My approach is such a situation is to define your own generator (assuming here that isSafe needs both its parameters): pl `x` ql = [ (p,q) | p -pl, q - ql] queens3 n = map reverse $ queens' n where queens' 0 = [[]] queens' k = [q:qs | (qs, q) - queens' (k-1) `x` [1..n], isSafe q qs] isSafe try qs = not (try `elem` qs || sameDiag try qs) sameDiag try qs = any (\(colDist,q) - abs (try - q) == colDist) $ zip [1..] qs Of course you can make more refined versions of `x`, which perform all kinds of fair enumeration, but that is not the main point here. It is the fact that the parameters to `x` are only evaluated once which matters here. Doaitse On Jan 29, 2013, at 10:25 , Junior White efi...@gmail.com wrote: Hi Cafe, I have two programs for the same problem Eight queens problem, the link is http://www.haskell.org/haskellwiki/99_questions/90_to_94. My two grograms only has little difference, but the performance, this is my solution: -- solution 1 queens1 :: Int - [[Int]] queens1 n = map reverse $ queens' n where queens' 0 = [[]] queens' k = [q:qs | q - [1..n], qs - queens' (k-1), isSafe q qs] isSafe try qs = not (try `elem` qs || sameDiag try qs) sameDiag try qs = any (λ(colDist, q) - abs (try - q) == colDist) $ zip [1..] qs -- solution 2-- queens2 :: Int - [[Int]] queens2 n = map reverse $ queens' n where queens' 0 = [[]] queens' k = [q:qs | qs - queens' (k-1), q - [1..n], isSafe q qs] isSafe try qs = not (try `elem` qs || sameDiag try qs) sameDiag try qs = any (λ(colDist,q) - abs (try - q) == colDist) $ zip [1..] qs the performance difference is: (set :set +s in ghci) *Main length (queens1 8) 92 (287.85 secs, 66177031160 bytes) *Main length (queens2 8) 92 (0.07 secs, 17047968 bytes) *Main The only different in the two program is in the first is q - [1..n], qs - queens' (k-1), and the second is qs - queens' (k-1), q - [1..n]. Does sequence in list comprehansion matter? And why? ___ 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] list comprehansion performance has hug different
The whole point here is to evaluate both lists inside the list comprehension only once. There is a very simple way to accomplish this: [q:qs | let qss = queens' (k-1), q - [1..n], qs - qss] Here, queens' (k-1) is only evaluated once, and is shared for all q. (Note: If queens' (k-1) is polymorphic (which it is) and you use -XNoMonomorphismRestriction, then you better add a type annotation to qss to ensure sharing.) Adrian On 2013/01/30 1:51, Doaitse Swierstra wrote: From the conclusion that both programs compute the same result it can be concluded that the fact that you have made use of a list comprehension has forced you to make a choice which should not matter, i.e. the order in which to place the generators. This should be apparent from your code. My approach is such a situation is to define your own generator (assuming here that isSafe needs both its parameters): pl `x` ql = [ (p,q) | p -pl, q - ql] queens3 n = map reverse $ queens' n where queens' 0 = [[]] queens' k = [q:qs | (qs, q) - queens' (k-1) `x` [1..n], isSafe q qs] isSafe try qs = not (try `elem` qs || sameDiag try qs) sameDiag try qs = any (\(colDist,q) - abs (try - q) == colDist) $ zip [1..] qs Of course you can make more refined versions of `x`, which perform all kinds of fair enumeration, but that is not the main point here. It is the fact that the parameters to `x` are only evaluated once which matters here. Doaitse On Jan 29, 2013, at 10:25 , Junior White efi...@gmail.com mailto:efi...@gmail.com wrote: Hi Cafe, I have two programs for the same problem Eight queens problem, the link is http://www.haskell.org/haskellwiki/99_questions/90_to_94. My two grograms only has little difference, but the performance, this is my solution: -- solution 1 queens1 :: Int - [[Int]] queens1 n = map reverse $ queens' n where queens' 0 = [[]] queens' k = [q:qs | q - [1..n], qs - queens' (k-1), isSafe q qs] isSafe try qs = not (try `elem` qs || sameDiag try qs) sameDiag try qs = any (?(colDist, q) - abs (try - q) == colDist) $ zip [1..] qs -- solution 2-- queens2 :: Int - [[Int]] queens2 n = map reverse $ queens' n where queens' 0 = [[]] queens' k = [q:qs | qs - queens' (k-1), q - [1..n], isSafe q qs] isSafe try qs = not (try `elem` qs || sameDiag try qs) sameDiag try qs = any (?(colDist,q) - abs (try - q) == colDist) $ zip [1..] qs the performance difference is: (set :set +s in ghci) *Main length (queens1 8) 92 (287.85 secs, 66177031160 bytes) *Main length (queens2 8) 92 (0.07 secs, 17047968 bytes) *Main The only different in the two program is in the first is q - [1..n], qs - queens' (k-1), and the second is qs - queens' (k-1), q - [1..n]. Does sequence in list comprehansion matter? And why? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] list comprehansion performance has hug different
On Wed, Jan 30, 2013 at 5:51 PM, Doaitse Swierstra doai...@swierstra.netwrote: From the conclusion that both programs compute the same result it can be concluded that the fact that you have made use of a list comprehension has forced you to make a choice which should not matter, i.e. the order in which to place the generators. This should be apparent from your code. My approach is such a situation is to define your own generator (assuming here that isSafe needs both its parameters): pl `x` ql = [ (p,q) | p -pl, q - ql] queens3 n = map reverse $ queens' n where queens' 0 = [[]] queens' k = [q:qs | (qs, q) - queens' (k-1) `x` [1..n], isSafe q qs] isSafe try qs = not (try `elem` qs || sameDiag try qs) sameDiag try qs = any (\(colDist,q) - abs (try - q) == colDist) $ zip [1..] qs Of course you can make more refined versions of `x`, which perform all kinds of fair enumeration, but that is not the main point here. It is the fact that the parameters to `x` are only evaluated once which matters here. Thanks for your reply! I must learn more to fully understand what's going on inside the list comprehension. But when I frist learn Haskell, it says sequence doesn't matter, but now it is a big matter, can compiler do some thing for us? I think this behavior is not friendly to newbies like me, I will take a very long time to work through it. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] list comprehansion performance has hug different
Thinks! I think compiler should do this for us, isn't it? On Wed, Jan 30, 2013 at 7:54 PM, Adrian Keet ark...@gmail.com wrote: The whole point here is to evaluate both lists inside the list comprehension only once. There is a very simple way to accomplish this: [q:qs | let qss = queens' (k-1), q - [1..n], qs - qss] Here, queens' (k-1) is only evaluated once, and is shared for all q. (Note: If queens' (k-1) is polymorphic (which it is) and you use -XNoMonomorphismRestriction, then you better add a type annotation to qss to ensure sharing.) Adrian On 2013/01/30 1:51, Doaitse Swierstra wrote: From the conclusion that both programs compute the same result it can be concluded that the fact that you have made use of a list comprehension has forced you to make a choice which should not matter, i.e. the order in which to place the generators. This should be apparent from your code. My approach is such a situation is to define your own generator (assuming here that isSafe needs both its parameters): pl `x` ql = [ (p,q) | p -pl, q - ql] queens3 n = map reverse $ queens' n where queens' 0 = [[]] queens' k = [q:qs | (qs, q) - queens' (k-1) `x` [1..n], isSafe q qs] isSafe try qs = not (try `elem` qs || sameDiag try qs) sameDiag try qs = any (\(colDist,q) - abs (try - q) == colDist) $ zip [1..] qs Of course you can make more refined versions of `x`, which perform all kinds of fair enumeration, but that is not the main point here. It is the fact that the parameters to `x` are only evaluated once which matters here. Doaitse On Jan 29, 2013, at 10:25 , Junior White efi...@gmail.com wrote: Hi Cafe, I have two programs for the same problem Eight queens problem, the link is http://www.haskell.org/haskellwiki/99_questions/90_to_94. My two grograms only has little difference, but the performance, this is my solution: -- solution 1 queens1 :: Int - [[Int]] queens1 n = map reverse $ queens' n where queens' 0 = [[]] queens' k = [q:qs | q - [1..n], qs - queens' (k-1), isSafe q qs] isSafe try qs = not (try `elem` qs || sameDiag try qs) sameDiag try qs = any (λ(colDist, q) - abs (try - q) == colDist) $ zip [1..] qs -- solution 2-- queens2 :: Int - [[Int]] queens2 n = map reverse $ queens' n where queens' 0 = [[]] queens' k = [q:qs | qs - queens' (k-1), q - [1..n], isSafe q qs] isSafe try qs = not (try `elem` qs || sameDiag try qs) sameDiag try qs = any (λ(colDist,q) - abs (try - q) == colDist) $ zip [1..] qs the performance difference is: (set :set +s in ghci) *Main length (queens1 8) 92 (287.85 secs, 66177031160 bytes) *Main length (queens2 8) 92 (0.07 secs, 17047968 bytes) *Main The only different in the two program is in the first is q - [1..n], qs - queens' (k-1), and the second is qs - queens' (k-1), q - [1..n]. Does sequence in list comprehansion matter? And why? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing listHaskell-Cafe@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Monadic parser vs. combinator parser
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. I started to wonder whether I should use monadic parser for the sake of it being monadic or should I just go with the combinator approach? Any thoughts will be appreciated before I shoot myself in the foot :) Janek ___ 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:
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. I started to wonder whether I should use monadic
parser for the sake of it being monadic or should I just go with the
combinator approach? Any thoughts will be appreciated before I shoot
myself in the foot :)
A monadic parser /is/ a combinator parser. The code you linked just
doesn't go as far as wrapping it up with a newtype and providing a monad
instance.
Monadic parsers aren't verbose, because there is the applicative style.
Let's rewrite this noisy example (assuming automatic backtracking):
inParens c = do
char '('
x - c
char ')'
return x
All monads are also applicative functors, which means that you can use
applicative style to write this one more nicely:
inParens c = char '(' * c * char ')'
If your parser is also an IsString you could even write:
inParens c = ( * c * )
If that's not nice and concise I don't know what is. =)
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] Handling exceptions or gracefully releasing resources
Everything that Johan Tibell said + you may be interested in the resourcet package [1] (which is used by conduit to handle resources). Cheers, [1] http://hackage.haskell.org/package/resourcet On Tue, Jan 29, 2013 at 8:59 PM, Thiago Negri evoh...@gmail.com wrote: `Control.Exception.bracket` is a nice function to acquire and release a resource in a small context. But, how should I handle resources that are hold for a long time? Should I put `Control.Exception.finally` on every single line of my finalizers? What exceptions may occur on an IO operation? Every IO function has the risk of throwing an exception? Thanks, Thiago. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Handling exceptions or gracefully releasing resources
Felipe, I'm trying to use your Hipmunk package. :) The resources I need to keep around are the objects used for the simulation. Do you recomend using resourcet to handle this or something else? Thanks. 2013/1/30 Felipe Almeida Lessa felipe.le...@gmail.com Everything that Johan Tibell said + you may be interested in the resourcet package [1] (which is used by conduit to handle resources). Cheers, [1] http://hackage.haskell.org/package/resourcet On Tue, Jan 29, 2013 at 8:59 PM, Thiago Negri evoh...@gmail.com wrote: `Control.Exception.bracket` is a nice function to acquire and release a resource in a small context. But, how should I handle resources that are hold for a long time? Should I put `Control.Exception.finally` on every single line of my finalizers? What exceptions may occur on an IO operation? Every IO function has the risk of throwing an exception? Thanks, Thiago. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Handling exceptions or gracefully releasing resources
AFAIR, the only object that you need to be careful with is the Space [1], everything else is garbage collected. You could put the Space in a ResourceT, but only if it ran on its own thread (as soon as a block of ResourceT finishes, everything is deallocated, so you wouldn't be able to follow the approach taken by HipmunkPlayground). Cheers, [1] http://hackage.haskell.org/packages/archive/Hipmunk/5.2.0.10/doc/html/Physics-Hipmunk-Space.html#v:freeSpace On Wed, Jan 30, 2013 at 11:15 AM, Thiago Negri evoh...@gmail.com wrote: Felipe, I'm trying to use your Hipmunk package. :) The resources I need to keep around are the objects used for the simulation. Do you recomend using resourcet to handle this or something else? Thanks. 2013/1/30 Felipe Almeida Lessa felipe.le...@gmail.com Everything that Johan Tibell said + you may be interested in the resourcet package [1] (which is used by conduit to handle resources). Cheers, [1] http://hackage.haskell.org/package/resourcet On Tue, Jan 29, 2013 at 8:59 PM, Thiago Negri evoh...@gmail.com wrote: `Control.Exception.bracket` is a nice function to acquire and release a resource in a small context. But, how should I handle resources that are hold for a long time? Should I put `Control.Exception.finally` on every single line of my finalizers? What exceptions may occur on an IO operation? Every IO function has the risk of throwing an exception? Thanks, Thiago. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Felipe. -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Darcs Hacking Sprint #8 (February 15-17, Paris)
Dear hackers, the Darcs project is glad to announce that the next Hacking Sprint will take place in Paris on February 15-17, at the IRILL (near Place d'Italie). Please check out the details at: http://darcs.net/Sprints/2013-02 Here are three things to know 1. Everybody is welcome to join us. We'd love to have you, whatever your Haskell or Darcs hacking experience. Also, if you've got a wacky idea for the future of version control, or a cool use for the Darcs library, you should join us too :-) 2. Please let us know if you're attending. Just add your name to http://wiki.darcs.net/Sprints/2013-02 and you're good to go. You can also send us an email. 3. We can reimburse travel costs (within reason!). Let us know if you'd like a reimbursement, and save your receipts. Many thanks to everybody who participated in our fundraising drives or who gave money on the side. Thanks also to the Software Freedom Conservancy for making fundraising and reimbursements so painless! If you can't join us in person, but you'd like to cheer us on, say hello at http://darcs.net/Donations ! Looking forward to seeing you! Guillaume ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] list comprehansion performance has hug different
On Wed, Jan 30, 2013 at 7:02 AM, Junior White efi...@gmail.com wrote: Thanks for your reply! I must learn more to fully understand what's going on inside the list comprehension. But when I frist learn Haskell, it says sequence doesn't matter, but now it is a big matter, can compiler do some thing for us? I think this behavior is not friendly to newbies like me, I will take a very long time to work through it. No, the compiler can't help you here. The compiler is not an oracle; even if it could invert your calculation (effectively swapping the loops around), it can't know which one is more appropriate. As to sequences: sequence doesn't matter indeed; data dependencies matter, and loop ordering imposes a data dependency because loops in Haskell are encoded as data structures (lists). -- 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] list comprehansion performance has hug different
On Wed, Jan 30, 2013 at 5:32 PM, Junior White efi...@gmail.com wrote: Thanks for your reply! I must learn more to fully understand what's going on inside the list comprehension. But when I frist learn Haskell, it says sequence doesn't matter, but now it is a big matter, can compiler do some thing for us? I think this behavior is not friendly to newbies like me, I will take a very long time to work through it. Good point. Being a programmer means having to juggle many hats -- two important ones being the mathematician-hat and the machine-hat, also called declaration and 'imperation' Get only the first and your programs will run very inefficiently. Get only the second and your program will have bugs. Specifically in the case of list comprehensions the newbie needs - to practice thinking of the comprehension like a set comprehension and ignoring computation sequences - to practice thinking of comprehension in terms of map/filter etc ie operationally Both views are needed. 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] Monadic parser vs. combinator parser
On 30 January 2013 12:38, Ertugrul Söylemez e...@ertes.de wrote: A monadic parser /is/ a combinator parser. The code you linked just doesn't go as far as wrapping it up with a newtype and providing a monad instance. Further, (+) in the linked example is monadic bind and `result` is `return`. The code looks more succinct than early Parser combinator libraries (like Hutton / Meijer) because it defines quite a few more combinators. Equivalents are available if you use say Parsec plus the usual applicative combinators. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Heads up: planned removal of String instances from HTTP package
Unfortunately I lack the time for a wholesale cleanup. If others have proposals and are willing to supply the patches that's a different matter! On 30/01/2013 08:01, Alfredo Di Napoli wrote: Maybe (just my 2 cents!) since you are going to broke the API anyway, go for it and seize the occasion to really clean up :) Obviously I'm saying this from a non-http-user point of view, maybe if I had some code in production affected by this, my suggestion would have been different :P Regards, A. On 30 January 2013 07:00, Ganesh Sittampalam gan...@earth.li mailto:gan...@earth.li wrote: On 29/01/2013 22:46, Johan Tibell wrote: On Tue, Jan 29, 2013 at 2:15 PM, Ganesh Sittampalam gan...@earth.li mailto:gan...@earth.li wrote: tl;dr: I'm planning on removing the String instances from the HTTP package. This is likely to break code. Obviously it will involve a major version bump. I think it's the right thing to do. Providing a little upgrade guide should help things to go smoother. One obvious cheap-and-dirty migration is via a newtype wrapper for String that embeds the old broken behaviour (char8 encoding). Perhaps the package should provide that? (with appropriate warnings etc) Ganesh ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Ticking time bomb
https://status.heroku.com/incidents/489 Unsigned Hackage packages are a ticking time bomb. Cheers, Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
As long as we upload packages via plain HTTP, signing won't help though. On Wed 30 Jan 2013 19:27:32 GMT, Edward Z. Yang wrote: https://status.heroku.com/incidents/489 Unsigned Hackage packages are a ticking time bomb. Cheers, Edward ___ 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
As long as we upload packages via plain HTTP, signing won't help though. I don't think that's true? If the package is tampered with, then the signature will be invalid; if the signature is also forged, then the private key is compromised and we can blacklist it. We care only about integrity, not secrecy. Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
HTTPS doesn't really change anything if the server is compromised, it only prevents bad things from happening in transit. Sign the packages with GPG (or equivalent) before upload. The server never sees the package author's private key, only the public key. Server and/or client can warn or fail if the public key doesn't match their previous credentials or the signature verification fails. On Wed, Jan 30, 2013 at 11:44 AM, Niklas Hambüchen m...@nh2.me wrote: As long as we upload packages via plain HTTP, signing won't help though. On Wed 30 Jan 2013 19:27:32 GMT, Edward Z. Yang wrote: https://status.heroku.com/incidents/489 Unsigned Hackage packages are a ticking time bomb. Cheers, Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe 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, 11:27 -0800 schrieb Edward Z. Yang: https://status.heroku.com/incidents/489 Unsigned Hackage packages are a ticking time bomb. another reason why Cabal is no package manager¹. (Ok, I admit that I don’t review every line of diff between the Haskell packages I uploads. But thanks to http://hdiff.luite.com/ I at least glance over them most of the time – a hurdle that malicious code would have to take. And once a package has entered a distribution like Debian (which it only can with a valid cryptographic signatures), checksums and signatures are used in many places to (mostly) guarantee that the package reaches the user unmodified.) Greetings, Joachim ¹ http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ -- 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
[Haskell-cafe] Package conflicts using cabal-dev
Hello, I am running into a strange issue that reminds me of Java's classloader black magic havoc :-) My code compiles fine using cabal-dev install, but when I try to compile an individual file with ghc, I got the following error: $ ghc -package-conf cabal-dev/packages-7.4.1.conf YakGraph.hs [1 of 1] Compiling YakGraph ( YakGraph.hs, YakGraph.o ) YakGraph.hs:13:30: Couldn't match expected type `Data.Text.Lazy.Internal.Text' with actual type `text-0.11.2.0:Data.Text.Lazy.Internal.Text' In the first argument of `unpack', namely `s' In the expression: unpack s In an equation for `fromGraphId': fromGraphId (Str s) = unpack s YakGraph.hs:24:57: Couldn't match expected type `Data.Text.Lazy.Internal.Text' with actual type `text-0.11.2.0:Data.Text.Lazy.Internal.Text' In the first argument of `unpack', namely `name' In the expression: unpack name In a case alternative: (Just (Str name)) : _ - unpack name The code leading to this error is here: https://gist.github.com/4677191 Any insights on this would be appreciated. Arnaud ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
IMHO Hackage and Cabal should support package signing even if they aren't package managers. On Wed, Jan 30, 2013 at 6:59 PM, Joachim Breitner nome...@debian.org wrote: Hi, Am Mittwoch, den 30.01.2013, 11:27 -0800 schrieb Edward Z. Yang: https://status.heroku.com/incidents/489 Unsigned Hackage packages are a ticking time bomb. another reason why Cabal is no package manager¹. (Ok, I admit that I don’t review every line of diff between the Haskell packages I uploads. But thanks to http://hdiff.luite.com/ I at least glance over them most of the time – a hurdle that malicious code would have to take. And once a package has entered a distribution like Debian (which it only can with a valid cryptographic signatures), checksums and signatures are used in many places to (mostly) guarantee that the package reaches the user unmodified.) Greetings, Joachim ¹ http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager/ -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Package conflicts using cabal-dev
On Wednesday 30 January 2013, 22:29:23, Arnaud Bailly wrote: YakGraph.hs:13:30: Couldn't match expected type `Data.Text.Lazy.Internal.Text' with actual type `text-0.11.2.0:Data.Text.Lazy.Internal.Text' one package (at least) you use - probably graphviz - was compiled with a version of `text` that is not the newest you have installed. GHC selects the newest installed version of a package by default, cabal and cabal-dev select the version that the other used packages require. Add a -package text-0.11.2.0 flag to the command line. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
Excerpts from Joachim Breitner's message of Wed Jan 30 12:59:48 -0800 2013: another reason why Cabal is no package manager¹. Based on the linked post, it seems that you are arguing that cabal-install is not a package manager, and thus it is not necessary for it to duplicate the work that real package managers e.g. Debian or Ubuntu put into vetting, signing and releasing software. (Though I am not sure, so please correct me if I am wrong.) This argument seems specious. Whether or not cabal-install is or not intended to be a package manager, users expect it to act like one (as users expect rubygems to be a package manager), and, at the end of the day, that is what matters. Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On Wed, Jan 30, 2013 at 10:43 PM, Edward Z. Yang ezy...@mit.edu wrote: This argument seems specious. Whether or not cabal-install is or not intended to be a package manager, users expect it to act like one (as users expect rubygems to be a package manager), and, at the end of the day, that is what matters. But playing along with their delusion might make it harder to change their minds. Edward ___ 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
You are right, I skipped over that this was actually a server-side exploit - sure, end-to-end signing will help here. On 30/01/13 19:47, Edward Z. Yang wrote: As long as we upload packages via plain HTTP, signing won't help though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
Excerpts from Ramana Kumar's message of Wed Jan 30 14:46:26 -0800 2013: This argument seems specious. Whether or not cabal-install is or not intended to be a package manager, users expect it to act like one (as users expect rubygems to be a package manager), and, at the end of the day, that is what matters. But playing along with their delusion might make it harder to change their minds. Looking at the library ecosystems of the most popular programming languages, I think this ship has already sailed. Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
On Wed, Jan 30, 2013 at 10:48 PM, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from Ramana Kumar's message of Wed Jan 30 14:46:26 -0800 2013: This argument seems specious. Whether or not cabal-install is or not intended to be a package manager, users expect it to act like one (as users expect rubygems to be a package manager), and, at the end of the day, that is what matters. But playing along with their delusion might make it harder to change their minds. Looking at the library ecosystems of the most popular programming languages, I think this ship has already sailed. I was talking only about Haskell and cabal. There is a viable alternative to using cabal as a package manager on Arch Linux (the Arch-Haskell package repositories). There is also the Stackage project that might make this possible on more distributions with real package managers. But if you keep calling cabal a package manager, eventually you'll have to write the patches to make it one. Edward ___ 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, 14:43 -0800 schrieb Edward Z. Yang: Excerpts from Joachim Breitner's message of Wed Jan 30 12:59:48 -0800 2013: another reason why Cabal is no package manager¹. Based on the linked post, it seems that you are arguing that cabal-install is not a package manager, and thus it is not necessary for it to duplicate the work that real package managers e.g. Debian or Ubuntu put into vetting, signing and releasing software. (Though I am not sure, so please correct me if I am wrong.) I’m not against cryptographically signed packages on hackage. In fact, I would whole-heatedly appreciate it, as it would make my work as a package maintainer easier. I was taking the opportunity to point out an advantage of established package management systems, to shamelessly advertise my work there, as not everyone sees distro-packaged libraries as a useful thing. Greetings, 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] Ticking time bomb
Excerpts from Joachim Breitner's message of Wed Jan 30 14:57:28 -0800 2013: I’m not against cryptographically signed packages on hackage. In fact, I would whole-heatedly appreciate it, as it would make my work as a package maintainer easier. I was taking the opportunity to point out an advantage of established package management systems, to shamelessly advertise my work there, as not everyone sees distro-packaged libraries as a useful thing. Yes. In fact, I am a sysadmin for a large shared hosting environment, and the fact that programming language libraries tend not to be distro-packaged is an endless headache for us. We would like it if everything were just packaged properly! On the other hand, working in these circumstances has made me realize that there is a huge tension between the goals of package library authors and distribution managers (a package library author is desires ease of installation of their packages, keeping everyone up-to-date as possible and tends to be selfish when it comes to the rest of the ecosystem, whereas the distribution manager values stability, security, and global consistency of the ecosystem.) So there is a lot of work to be done here. Nevertheless, I believe we are in violent agreement that cryptographically signed Hackage packages should happen as soon as possible! Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] TIPS: To Insure Package Sanity
If you possess multiple instances (may be different versions, may be same version different builds) of a package, life can be hard and confusing. The problems are explained in my http://www.vex.net/~trebla/haskell/sicp.xhtml and faced by many people regularly. (Just read this mailing list.) cabal-install has a mechanism for not adding more instances. It is available since version 0.14.0, or earlier. It is just little known. It is also a bit manual. You have to give 1 instruction for each package. If you want to say it for n packages, you have to give n instructions. Also, if you give such an instruction for a package you do not already have, there is a problem: now you can't install that package. To insure package sanity, add these lines to your $HOME/.cabal/config, one line per package you want to protect. (Cannot merge into one line.) constraint: array installed constraint: bytestring installed constraint: Cabal installed constraint: containers installed ... Generally, do it for every package that comes with GHC, and every package that comes with the Haskell Platform if you have it, plus every package that you want stable. (You may omit packages that cannot possibly be on hackage, e.g., integer-gmp.) Remember to revise those lines whenever you switch GHC versions or Haskell Platform versions, since their package lists change. Alternatively, if you want even more manual work (in exchange for more fine-tuning perhaps?): every time you use cabal install: cabal install --constraint=array installed --constraint=bytestring installed --constraint=Cabal installed --constraint=containers installed ... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Weekly News: Issue 256
Welcome to issue 256 of the HWN, an issue covering crowd-sourced bits of information about Haskell from around the web. This issue covers the weeks of January 20 to 26, 2013. Quotes of the Week * elliott: cmccann: unfortunately it is too perfect an abstraction to be useful. * SamanthaD: shachaf: you're one of those dirty imperative communists who want the state to dictate everything! * monochrom: I refuse camel case and mark zuckerberg. same level. not negotiable. * mauke: a newtype is like an existing type but wearing glasses and a fake mustache and a sign saying you've never seen me before Top Reddit Stories * Taking magic out of GHC or: Tracing compilation by transformation (intro to Core transformations, inlining,.. Domain: ics.p.lodz.pl, Score: 59, Comments: 2 On Reddit: [1] http://goo.gl/lJmsb Original: [2] http://goo.gl/IbJ5O * Introduction to Haskell IO Domain: haskellforall.com, Score: 57, Comments: 26 On Reddit: [3] http://goo.gl/fPky4 Original: [4] http://goo.gl/Xymbr * The longest type signature I have ever seen (package Nussinov78) Domain: i.imgur.com, Score: 48, Comments: 26 On Reddit: [5] http://goo.gl/ePwNs Original: [6] http://goo.gl/B74yW * There is now a patch for the GHC runtime system which implements a scheduler which can handle threads with priorities. Domain: hackage.haskell.org, Score: 47, Comments: 12 On Reddit: [7] http://goo.gl/22XgH Original: [8] http://goo.gl/8iC8w * Success story: novice haskeller moves console cursor with “netwire” FRP library Domain: danbst.wordpress.com, Score: 43, Comments: 8 On Reddit: [9] http://goo.gl/dm8ga Original: [10] http://goo.gl/Ue7pK * Haskell as pseudo code Domain: arxiv.org, Score: 33, Comments: 2 On Reddit: [11] http://goo.gl/JL8Mf Original: [12] http://goo.gl/5D4zV * Generalizing do notation Domain: self.haskell, Score: 28, Comments: 19 On Reddit: [13] http://goo.gl/teYAD Original: [14] http://goo.gl/teYAD * Tutorial: Up-front Unit Testing in Haskell Domain: github.com, Score: 26, Comments: 21 On Reddit: [15] http://goo.gl/kjzYJ Original: [16] http://goo.gl/oB2jg * The Design of a Practical Proof Checker for a Lazy Functional Language [PDF] Domain: people.cs.missouri.edu, Score: 26, Comments: On Reddit: [17] http://goo.gl/sj5Aj Original: [18] http://goo.gl/eEUOj * Introduction to Haskell, Lecture 2 is Live Domain: shuklan.com, Score: 24, Comments: 4 On Reddit: [19] http://goo.gl/1nUVv Original: [20] http://goo.gl/rCbfx * Hugs in your browser Domain: tryhaskell.org, Score: 24, Comments: 21 On Reddit: [21] http://goo.gl/zNtex Original: [22] http://goo.gl/wMPPW * Free functors - the reason Free and operational are not equivalent Domain: self.haskell, Score: 24, Comments: 12 On Reddit: [23] http://goo.gl/E7qe7 Original: [24] http://goo.gl/E7qe7 * Scribbling, smudging and smearing with Haskell Domain: self.haskell, Score: 22, Comments: 108 On Reddit: [25] http://goo.gl/KBw0V Original: [26] http://goo.gl/KBw0V * Touch and Keyboard API (announcing Elm 0.7.1) Domain: elm-lang.org, Score: 20, Comments: 3 On Reddit: [27] http://goo.gl/OhFaH Original: [28] http://goo.gl/rV9bU * (re)implementing the generalised Functor strength function using lenses. Domain: statusfailed.com, Score: 20, Comments: 3 On Reddit: [29] http://goo.gl/gEYHr Original: [30] http://goo.gl/TDX2A Top StackOverflow Questions * Can using UndecidableInstances pragma locally have global consequences on compilation termination? votes: 20, answers: 1 Read on SO: [31] http://goo.gl/PcQF1 * Why doesn't GHC Haskell support overloaded record parameter names? votes: 14, answers: 1 Read on SO: [32] http://goo.gl/BJ71T * How much does it cost for Haskell FFI to go into C and back? votes: 14, answers: 2 Read on SO: [33] http://goo.gl/kUCKn * Compile unsafe Haskell votes: 13, answers: 1 Read on SO: [34] http://goo.gl/nGaCX * Why GADT/existential data constructors cannot be used in lazy patterns? votes: 12, answers: 2 Read on SO: [35] http://goo.gl/zhpCh * Correct design for Haskell exception handling votes: 11, answers: 2 Read on SO: [36] http://goo.gl/zeWoH * How to use phase control of inlining in haskell? votes: 10, answers: 0 Read on SO: [37] http://goo.gl/dyuGI * Looking for resources that help testing a Haskell implementation for standard conformance votes: 9, answers: 1 Read on SO: [38] http://goo.gl/DL7vY * Generate a C struct based on a complex Haskell type votes: 8, answers: 1 Read on SO: [39] http://goo.gl/7E8OT * How to structure a Haskell project? votes: 7, answers: 1 Read on SO: [40]
[Haskell-cafe] FFI - Approaches to C/C++
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 -- 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] list comprehansion performance has hug different
Thank you everyone! I like Haskell because the following two reasons: 1. It is beautifully 2. There are many great guys like you here. I will work harder on it, and forgive me for my broken English. On Thu, Jan 31, 2013 at 12:41 AM, Rustom Mody rustompm...@gmail.com wrote: On Wed, Jan 30, 2013 at 5:32 PM, Junior White efi...@gmail.com wrote: Thanks for your reply! I must learn more to fully understand what's going on inside the list comprehension. But when I frist learn Haskell, it says sequence doesn't matter, but now it is a big matter, can compiler do some thing for us? I think this behavior is not friendly to newbies like me, I will take a very long time to work through it. Good point. Being a programmer means having to juggle many hats -- two important ones being the mathematician-hat and the machine-hat, also called declaration and 'imperation' Get only the first and your programs will run very inefficiently. Get only the second and your program will have bugs. Specifically in the case of list comprehensions the newbie needs - to practice thinking of the comprehension like a set comprehension and ignoring computation sequences - to practice thinking of comprehension in terms of map/filter etc ie operationally Both views are needed. 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] Ticking time bomb
Ramana Kumar ramana.ku...@cl.cam.ac.uk wrote: But if you keep calling cabal a package manager, eventually you'll have to write the patches to make it one. The combination of Cabal, cabal-install and Hackage is a package distribution system. As such, it needs the necessary cryptographic support. I don't view them as a package management system. What's important is that many programmers blindly trust the code they download, install and run from Hackage. Yes, it's a bad habit, but seriously, that's the alternative? Distributions are often some linear combination of outdated and broken with coefficients near 1. Let me restate the important fact with more emphasis: People are using Hackage! 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. 2. Update Hackage to allow uploading signatures along with packages. 3. Update cabal-install to allow signing packages and optionally checking the signatures. Do not allow signature chains. Do not support CAs for now. Have a database of trusted keys. Could be a directory below ~/.cabal with keys as files. More detailed (skip to next step, if you're not going to implement this): Before installing anything, build a map from maintainers from whom we would be installing packages to the packages they maintain. Maintainers are identified by their keys, not their usernames. If any of the keys is not trusted yet, then print this list as readable as possible. Use colors, etc. Hypothetical example: % cabal install diagrams Resolving dependencies... The following maintainers are untrusted: Diagrams Project ...@... [ABCD1234]: FP: monoid-extras-0.2.2.2 dual-tree-0.1.0.1 diagrams-core-0.6.0.1 diagrams-lib-0.6.0.1 diagrams-svg-0.6.0.1 diagrams-contrib-0.6.0.1 diagrams-0.6 Trust them (?/y/n/t)? ? y: yes n: no (default) t: temporarily Trust them (?/y/n/t)? y Adding to trust db: Diagrams Project ...@... [ABCD1234] [install] Cabal should ignore the Maintainer field in the Cabal file. Only the signature counts here. Cabal must report a changed maintainer: % cabal install diagrams Resolving dependencies... WARNING: Package 'diagrams-core' has changed maintainer. [old key info] [new key info] Install anyway (y/n)? y The following maintainers are untrusted: [...] 4. Announce the change and urge maintainers to update their packages to include signatures. 5. Wait a few weeks. 6. Make signature verification the default in cabal-install. 7. Optionally implement CA support and establish a CA outside and offsite of Hackage. Someone with a good understanding of server security and cryptography should do that. They could be added to ~/.cabal/config to make package installations easier. Steps 1..6 should be done with high priority, otherwise they will never be finished. Step 7 is optional. If you're indeed considering this, I'm happy to turn this into a set of bug tracker issues and possibly help with the development. 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] linking errors while compile hugs98 in macos
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? This is my machine info: ➜ hugs98-plus-Sep2006 git:(master) ✗ uname -a Darwin lan-seimatoMacBook-Air.local 11.4.2 Darwin Kernel Version 11.4.2: Thu Aug 23 16:25:48 PDT 2012; root:xnu-1699.32.7~1/RELEASE_X86_64 x86_64 Preprocessing Network/Hackage/Version Undefined symbols for architecture x86_64: _environ, referenced from: ___hscore_environ in ccuTP291.o (maybe you meant: ___hscore_environ) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status runhugs: Error occurred ERROR libraries/bootlib/Foreign/C/Error.hs - Error while running compilation command 'gcc -DNDEBUG=1 -g -no-cpp-precomp -flat_namespace -shared -fPIC -D__HUGS__ -Ihugsdir/include -o libraries/bootlib/Foreign/C/Error.so libraries/bootlib/Foreign/C/Error.c -Ipackages/base/include -Ighc/includes packages/base/cbits/PrelIOUtils.c' Undefined symbols for architecture x86_64: _environ, referenced from: ___hscore_environ in ccYZo1zT.o (maybe you meant: ___hscore_environ) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status runhugs: Error occurred ERROR libraries/bootlib/Foreign/Marshal/Alloc.hs - Error while running compilation command 'gcc -DNDEBUG=1 -g -no-cpp-precomp -flat_namespace -shared -fPIC -D__HUGS__ -Ihugsdir/include -o libraries/bootlib/Foreign/Marshal/Alloc.so libraries/bootlib/Foreign/Marshal/Alloc.c -Ipackages/base/include -Ighc/includes packages/base/cbits/PrelIOUtils.c packages/base/cbits/dirUtils.c packages/base/cbits/consUtils.c' ___ 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 working on a project in Haskell and C++ where the former is the brains and the latter is for UI, interaction etc. That's a rather odd choice. Not exactly answering your question, but questioning your project decisions, why would you do UI and interaction in C++? You have the necessary Haskell bindings and libraries to write everything cleanly in Haskell. 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] FFI - Approaches to C/C++
Hi Ertugrul, 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? 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. Thanks, Casey * I'm working on a project in Haskell and C++ where the former is the** brains and the latter is for UI, interaction etc.* That's a rather odd choice. Not exactly answering your question, but questioning your project decisions, why would you do UI and interaction in C++? You have the necessary Haskell bindings and libraries to write everything cleanly in Haskell. Greets, Ertugrul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Most used functions in hackage
On 01/29/2013 12:23 PM, Casey Basichis wrote: Why do you think browsing function by function is a bad idea? It seems that knowing exactly what the most used functions are would be an extremely effective way of finding both which parts of the Prelude and Hackage are most broadly useful (instead of browsing them like a phonebook) and also finding support from the community as the most commonly used functions would likely be the easiest to find support for. Well, I think the popularity is best measured on the level of packages, not separate functions. And I've seen quite a few ratings of most popular packages in the past. For example: http://corp.galois.com/blog/2009/3/23/one-million-haskell-downloads.html http://haskellwebnews.wordpress.com/2011/03/16/hackage-stats-the-past-year/ I guess Google can suggest much more. There is one thing you should keep in mind while looking at such charts. Authors measure number of downloads. Most of them are results of cabal-install fetching dependencies, not of the deliberate decision of a programmer to use the package. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ticking time bomb
Not to downplay the significance of this issue, but a primary issue, much more important is to secure ghc, base, cabal-install, and the build process for these. The development process needs to be robust. That process should include signing commits by *two developers*. This is really not a lot of work as a code-review is already done, but more significantly helps fend off a lot of compromised repository issues. There are just a few simple rules to follow: Review the commit on your own equipment, and sign it. That way an attacker will have to compromise two physically different repositories. .http://mikegerwitz.com/docs/git-horror-story.html This is a change that doesn't need any new development, just a procedure change. Wrt Hackage, simply signing packages is going to improve things, but what would be way more awesome would be to have multiple people sign off on the difference between two releases. What I mean is that whenever somebody reviews a new release of some package (the diff from a previous release), the work they did should ideally be represented as a signature on that release, or the commit that is the diff between the two releases. Git can handle this sort of trust issues, but a simple signature scheme will not. Now if a large security-conscious corporation starts using packages from Hackage, they will already have a security team that does code reviews. With a simple signature scheme, the output from their security team will not be possible to use on Hackage. I for one would be much more likely to trust packages signed by the signature by someone who has found numerous security flaws in various packages on Hackage, than some random developer. One signature might mean this is my release, if you trust my machine,repository, +++. Another signature might mean the security team of X Corp has done a security review at level Y. This is cleared for production use.. Simply supporting the first signature is no good. So if we really want to fix this, I suggest moving a large part of the trust infrastructure off of hackage and into git or similar systems that have better support for dealing with trust. Alexander On Wed, Jan 30, 2013 at 8:27 PM, Edward Z. Yang ezy...@mit.edu wrote: https://status.heroku.com/incidents/489 Unsigned Hackage packages are a ticking time bomb. Cheers, Edward ___ 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
