Dear gentle Haskellers,
I'd appreciate it very much if you could please take a look the my code
here and give me some feedback -
https://github.com/ckkashyap/haskell-websocket/blob/master/src/lib/Net/WebSocket/Request.hs
I am particularly looking for advice around what would be a good type for
On Tue, May 24, 2011 at 7:18 PM, Neil Mitchell ndmitch...@gmail.com wrote:
Before doing a code review I always demand that the author runs over
the code with HLint (http://community.haskell.org/~ndm/hlint) - they
Very good point. In fact you just inspired me to finally download it
and
Hi Niklas,
I use Uniplate inside HLint, and it's invaluable - there are a lot of
times when List Comp + universeBi really hits the spot.
+1 on that, I use uniplate for pretty much all my haskell-src-exts tasks
these days, works like a charm!
I'd love to include some standard traversal
On Mon, May 23, 2011 at 12:02 PM, Neil Mitchell ndmitch...@gmail.com wrote:
'if all == False then return False else return True' is a pretty
confusing way to say 'return all'. In fact, any time you see 'x ==
True' you can just remove the '== True'. The whole postAll thing
would be clearer as
Evan Laforge qdunkan at gmail.com writes:
[...] a tool that wanted to
traverse deep data structures as produced by haskell-src-exts.
[...] I heard uniplate was
pretty easy to use, and was pretty pleased to turn the entire thing
into a single line.
Please post that line here - J.W.
On Tue, May 24, 2011 at 6:47 AM, Johannes Waldmann
waldm...@imn.htwk-leipzig.de wrote:
Evan Laforge qdunkan at gmail.com writes:
[...] a tool that wanted to
traverse deep data structures as produced by haskell-src-exts.
[...] I heard uniplate was
pretty easy to use, and was pretty pleased to
Before doing a code review I always demand that the author runs over
the code with HLint (http://community.haskell.org/~ndm/hlint) - they
Very good point. In fact you just inspired me to finally download it
and run it on my own code. Thanks for the great tool!
Glad you like it.
While I'm
Evan Laforge schrieb:
I'd keep the line length down to 80 chars, and not use ';'s.
You can find more programming tips in
http://www.haskell.org/haskellwiki/Haskell_programming_tips
and in other articles of the Haskell Wiki, e.g. in Category:Idioms,
Category:Style, Category:FAQ.
'if all == False then return False else return True' is a pretty
confusing way to say 'return all'. In fact, any time you see 'x ==
True' you can just remove the '== True'. The whole postAll thing
would be clearer as
Before doing a code review I always demand that the author runs over
the
Hey guys. Pretty new to haskell here. I've started off by writing a small
command-line interface to plurk.. I was just wondering if anyone would be
willing to give everything a look-over and lemme know what kinds of things I
should be looking to improve upon, style-wise. Not sure I'm currently
I'd keep the line length down to 80 chars, and not use ';'s.
All of that fiddling with buffering, printing, reading results could
be more clearly put into a couple of functions.
'if all == False then return False else return True' is a pretty
confusing way to say 'return all'. In fact, any time
Good points. Here are a few more. Use more explicit types. You can cut
down on if-then-else's by using pattern matching and guards. (For example,
the first if-then-else in postStatus can be turned into:
newtype PostToAllNetworks = PostToAll Bool
newtype FirstPost = FirstPost Bool
Hi,
I've been working on a (de)serialization package from/to XML (using
SYB) and wondering if anyone feels like giving me a quick code review
before I upload it to hackagedb.
The source code can be found at http://github.com/finnsson/Text.XML.Generic
It is *heavily* inspired by
On Sat, Aug 2, 2008 at 10:13 PM, Tim Newsham [EMAIL PROTECTED] wrote:
http://www.thenewsh.com/%7Enewsham/store/Server5.hs
You should try profiling this. I can see a few possible problems (such
as reading String from a socket, instead of a ByteString), but it's
difficult to predict what might
On Sat, Aug 2, 2008 at 10:13 PM, Tim Newsham [EMAIL PROTECTED] wrote:
Anyone interested in critiquing some code? I'm looking for ideas
for making it faster and/or simpler:
http://www.thenewsh.com/%7Enewsham/store/Server5.hs
The code looks fairly reasonable, although most of your strictness
You should try profiling this. I can see a few possible problems (such
as reading String from a socket, instead of a ByteString), but it's
difficult to predict what might be causing your code to be so slow.
Haskell code ought to be much more competitive with C for an
application like this.
I
On 2008 Aug 4, at 23:45, Tim Newsham wrote:
Anyway, I haven't yet used any ByteString IO functions. I ran
some tests when I was starting and it seems that using Handle IO
functions was a bit slower than using the Socket IO functions
directly.
It looks like there are a bunch of Handle IO
newsham:
Anyone interested in critiquing some code? I'm looking for ideas
for making it faster and/or simpler:
What optimisation and runtime flags did you use (-threaded or not?)
currently ghc -O --make $ -o $@. For some measurements I tried
-threaded which seemed to have a slight slowdown
On Sat, 2008-08-02 at 19:13 -1000, Tim Newsham wrote:
My measurements show that a simple dummy server (accept, forkio,
recv byte) handles roughly 7500 requests/connects per second,
the server/client that do real messages do about 4500 req and
connections per second. If all requests are on
What kind of performance do you actually need? Can your network
connection actually sustain the bandwidth of your synthetic benchmarks?
This is just an exercise at the moment, so no particular performance
goal beyond how fast can it go.
(tested using apache-bench, loopback interface, amd64 @
Anyone interested in critiquing some code? I'm looking for ideas
for making it faster and/or simpler:
http://www.thenewsh.com/%7Enewsham/store/Server5.hs
This is an exercise to see how well a server in Haskell would perform.
My goals are roughly:
- retargetability to other server types
newsham:
Anyone interested in critiquing some code? I'm looking for ideas
for making it faster and/or simpler:
http://www.thenewsh.com/%7Enewsham/store/Server5.hs
This is an exercise to see how well a server in Haskell would perform.
My goals are roughly:
- retargetability to
Hi -
I've started work on an initial factoring of sequence ops into classes, and
already I've run into some major design issues which stand like a mountain
in the way of progress. The classes are below:
-- all code below standard BSD3 licence :-)
module Duma.Data.Class.Foldable
(
Brian Hulley wrote:
Hi -
I've started work on an initial factoring of sequence ops into
[snip]
class Foldable c a | c - a where
foldR :: (a - b - b) - b - c - b
[snip]
There is a general problem that when the element type needs to be
specified along with the type of the overall
Bulat Ziganshin wrote:
[ideas including reverseMapM_]
you will laugh, but speed of your two solutions depends on so many
factors (including size of CPU cache) that noone can say that is
better in general. although for small lists reverseMapM_ should be
faster than reverse+mapM. what will be
Brian,
You might also want to take a look at the list fusion functionality in
GHC which often can help optimize your programs when programming with
lists.
http://www.haskell.org/ghc/docs/latest/html/users_guide/rewrite-rules.html#id3153234
It doesn't help in your particular program but it might
Evan Martin wrote:
I remember reading a tutorial that pointed out that you can often
avoid explicit recusion in Haskell and instead use higher-level
operators.
For your code, I think
drawModals = foldr (flip ()) (return ()) . map drawModal
works(?).
I think it would be foldl so that the
Hello Brian,
Tuesday, May 2, 2006, 3:12:48 AM, you wrote:
-- Prolog style coding...
drawModals :: [Control] - ManagerM ()
drawModals [] = return ()
drawModals (c:cs) = do
drawModals cs
I have added 'solve method F', aka X-wing, swordfish...
(www.sudokusolver.co.uk) to my solver, that reduced the number of puzzles
needing guesses to 5306, so I suppose that's it.
I haven't yet implemented it efficiently, so it was devastating for
performance - and solving thirteen puzzles more
I believe if you change the representation of puzzles from [(pos,range)]
to an Array, you'll get a significant speedup
yet because I only recently removed a logic bug that slowed down the
search instead of speading it up; ..). so the more interesting bit is
that our solvers disagree on which
Daniel Fischer wrote:
My IDE is kate/kwrite + ghci + hugs, if you know a better one (which doesn't
involve loading down a 99MB thing like eclipse), I'd be interested to try it
out.
(I already knew emacs, so using haskell-mode is my choice)
I changed the output format to a line per puzzle
Hello Daniel,
Tuesday, April 11, 2006, 3:26:06 AM, you wrote:
Today, I wrote a version using IOArray, hoping to get incredibly fast in-place
updating, and explicitly making copies via freeze and thaw when guessing is
required, but no luck (maybe I just don't know how to do it properly), spent
Mine's even faster now (at least on my computer, would you care to test it
on your's? If you don't want to get EnumSet, just change DiffArray to
Array, worked wonders for me), I'll dig into yours tomorrow to see what I
can get out of it to improve my algorithm.
Unforunately, no new inference
Moin Claus,
Am Montag, 10. April 2006 10:11 schrieben Sie:
Mine's even faster now (at least on my computer, would you care to test
it on your's? If you don't want to get EnumSet, just change DiffArray to
Array, worked wonders for me), I'll dig into yours tomorrow to see what
I can get out
I just ran a simple metric for the dancing-links solver.
The only real metric I could use was the number of coverOthers calls which
counts the number of selections made (there is no distinction between certainty
and guessing).
So the minimum # of selections is 81 (of which 17 are the free hints,
Am Samstag, 8. April 2006 10:21 schrieb Chris Kuklewicz:
Daniel Fischer wrote:
But, lo and behold, I also tried how plain Array fared in comparison to
DiffArray and ... reduced the running time to under ten minutes (a little
above for the list version), 5% GC time without -AxM, 1.2% with
Daniel Fischer wrote:
But, lo and behold, I also tried how plai Array fared in comparison to
DiffArray and ... reduced the running time to under ten minutes (a little
above for the list version), 5% GC time without -AxM, 1.2% with -A8M.
And I thought, DiffArrays were supposed to be fast!
Hello Daniel,
Saturday, April 8, 2006, 3:06:03 AM, you wrote:
And I thought, DiffArrays were supposed to be fast!
1. your arrays are too small (8 elements only)
2. DiffArray use internally MVars. with IORefs they will be a lot
faster
--
Best regards,
Bulat
Hello Chris,
Saturday, April 8, 2006, 12:21:07 PM, you wrote:
backtracking. And I can use STRef's to build it, instead of MVars.
may be it's better to use unboxed arrays/references?
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
I have finished my cleanup of the dancing links based solver for Sudoku.
I don't have time to compare performance with the other programs that have been
posted recently, or to do more profiling of my code.
For those who will say It is ugly, imperative, and ugly! please remember this
is a
Am Samstag, 8. April 2006 02:20 schrieb Daniel Fischer:
Am Freitag, 7. April 2006 17:33 schrieben Sie:
Just out of curiosity, speed was not the objective when I wrote my
solver, I wanted to avoid guesswork (as much as possible), but in
comparison with Cale Gibbard's and Alson Kemp's
Am Samstag, 8. April 2006 20:28 schrieb Chris Kuklewicz:
I have finished my cleanup of the dancing links based solver for Sudoku.
I don't have time to compare performance with the other programs that have
been posted recently, or to do more profiling of my code.
Your dancing links:
ckSud
Hello Daniel,
Friday, April 7, 2006, 2:05:03 AM, you wrote:
I've cleaned up my solver, removed a lot of redundant inference steps and made
the board a DiffArray (is that really faster?).
btw, DiffArray implementation can be made significantly faster by
using IORefs instead of MVars
--
Best
Just out of curiosity, speed was not the objective when I wrote my solver, I
wanted to avoid guesswork (as much as possible), but in comparison with Cale
Gibbard's and Alson Kemp's solvers (which are much more beautifully coded),
it turned out that mine is blazingly fast, so are there faster
Am Freitag, 7. April 2006 01:50 schrieben Sie:
On Apr 6, 2006, at 6:05 PM, Daniel Fischer wrote:
I've also written a version using David F. Place's EnumSet instead
of [Int],
that takes less MUT time, but more GC time, so is slower on the
36,628 test,
but faster for a single puzzle.
Am Freitag, 7. April 2006 17:33 schrieben Sie:
Just out of curiosity, speed was not the objective when I wrote my
solver, I wanted to avoid guesswork (as much as possible), but in
comparison with Cale Gibbard's and Alson Kemp's solvers (which are much
more beautifully coded), it turned out
Curry does not have a constraint solver of its own. It
simply delegates all constraints to the FD solver of SICStus Prolog.
or that of SWI Prolog (which prompted my attempt to install Curry).
which was implemented by..hi, again!-) (*)
The all_different constraint subsumes the rules that
On Thu, 6 Apr 2006, Claus Reinke wrote:
Curry does not have a constraint solver of its own. It simply delegates all
constraints to the FD solver of SICStus Prolog.
or that of SWI Prolog (which prompted my attempt to install Curry).
which was implemented by..hi, again!-) (*)
The
Am Mittwoch, 5. April 2006 15:09 schrieb Chris Kuklewicz:
Henning Thielemann wrote:
On Mon, 3 Apr 2006, Jared Updike wrote:
or ambiguously) with your Sudoku solver? A rough mesaure of the
difficulty of the unsolved puzzle could be how long the solver took to
solve it (number of steps)
On Apr 6, 2006, at 6:05 PM, Daniel Fischer wrote:I've also written a version using David F. Place's EnumSet instead of [Int], that takes less MUT time, but more GC time, so is slower on the 36,628 test, but faster for a single puzzle. That's a curious result. Did you compile with optimization?
On Mon, 3 Apr 2006, Jared Updike wrote:
or ambiguously) with your Sudoku solver? A rough mesaure of the
difficulty of the unsolved puzzle could be how long the solver took to
solve it (number of steps) (and the number of possible solutions)? Are
puzzles with multiple solutions usually
Henning Thielemann wrote:
On Mon, 3 Apr 2006, Jared Updike wrote:
or ambiguously) with your Sudoku solver? A rough mesaure of the
difficulty of the unsolved puzzle could be how long the solver took to
solve it (number of steps) (and the number of possible solutions)? Are
puzzles with
On 4/3/06, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
It would also be nice to see some example sudoku solvers posted
on an `Idioms' page on haskell.org:
http://www.haskell.org/haskellwiki/Category:Idioms
someone could just create a new page 'Sudoku' and add the phrase
It solves sudoku puzzles. (What pleasure do people get by doing
these in their heads?!?)
probably the same you get from writing programs?-) figuring out the
rules, not getting lost in complexity, making something difficult work..
They are probably asking the same question: why take hours
Claus Reinke wrote:
It solves sudoku puzzles. (What pleasure do people get by doing
these in their heads?!?)
probably the same you get from writing programs?-) figuring out the
rules, not getting lost in complexity, making something difficult work..
From a human standpoint, there are
Chris wrote:
You need more than 5 examples. The truly evil puzzles are rarer than that.
Go
get the set of minimal puzzles and see how far your logic takes you.
Chris elucidated some of my questions before I finished writing my email...
Claus wrote:
(*) actually, that was a bit
since I haven't factored out the constraint propagation into a
general module, the core of my code is a lot longer than the Curry version
(about 60 additional lines, though I'm sure one could reduce that;-). the
only negative point I can find about the Curry example is that it isn't
obvious
Jared Updike wrote:
Chris wrote:
You need more than 5 examples. The truly evil puzzles are rarer than that.
Go
get the set of minimal puzzles and see how far your logic takes you.
Chris elucidated some of my questions before I finished writing my email...
Claus wrote:
(*) actually,
Hello
it seems that sudoku solver may be a good candidate for nofib suite /
language comparison shootout
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
bulat.ziganshin:
Hello
it seems that sudoku solver may be a good candidate for nofib suite /
language comparison shootout
It would also be nice to see some example sudoku solvers posted
on an `Idioms' page on haskell.org:
http://www.haskell.org/haskellwiki/Category:Idioms
someone could
Am Montag, 3. April 2006 18:52 schrieb Chris Kuklewicz:
Claus Reinke wrote:
It solves sudoku puzzles. (What pleasure do people get by doing
these in their heads?!?)
probably the same you get from writing programs?-) figuring out the
rules, not getting lost in complexity, making
Jared Updike wrote:
On 3/22/06, David F. Place [EMAIL PROTECTED] wrote:
...
It solves
sudoku puzzles. (What pleasure do people get by doing these in their
heads?!?)
They are probably asking the same question: why take hours to write a
program to do it when with my mad sudoku solving
Thanks for your helpful suggestions. I took them to heart and
incorporated many of them in a new version.
sudoku.hs
Description: Binary data
David F. Place
mailto:[EMAIL PROTECTED]
___
Haskell-Cafe mailing
Hi All,
I really appreciate all the help I received when I asked you to
critique my PrefixMap module a few weeks ago. I think I am making
good progress in correcting the lisp in my Haskell programming.
I'll be very grateful to anyone who can take a glance at the attached
short program
On 3/22/06, David F. Place [EMAIL PROTECTED] wrote:
Hi All,
I really appreciate all the help I received when I asked you to
critique my PrefixMap module a few weeks ago. I think I am making
good progress in correcting the lisp in my Haskell programming.
I'll be very grateful to anyone who
On Mar 22, 2006, at 2:16 PM, David F. Place wrote:
Hi All,
I really appreciate all the help I received when I asked you to
critique my PrefixMap module a few weeks ago. I think I am making
good progress in correcting the lisp in my Haskell programming.
I'll be very grateful to anyone
Robert Dockins wrote:
On Mar 22, 2006, at 2:16 PM, David F. Place wrote:
Hi All,
I really appreciate all the help I received when I asked you to
critique my PrefixMap module a few weeks ago. I think I am making
good progress in correcting the lisp in my Haskell programming.
The style
67 matches
Mail list logo
