On 2013-09-21 06:16, Mike Meyer wrote:
The single biggest gotcha is that two calculations
we expect to be equal often aren't. As a result of this, we warn
people not to do equality comparison on floats.
The Eq instance for Float violates at least one expected law of Eq:
Prelude let nan =
On 2013-09-20 18:31, Brandon Allbery wrote:
[--snip--]
unless you have a very clever representation that can store
in terms of some operation like sin(x) or ln(x).)
I may just be hallucinating, but I think this is called describable
numbers, i.e. numbers which can described by some (finite)
On 2013-09-21 23:08, Mike Meyer wrote:
Exactly. The Eq and Ord instances aren't what's broken, at least when
you're dealing with numbers (NaNs are another story). That there are pairs
According to Haskell NaN *is* a number.
Eq and Ord are just the messengers.
No. When we declare something an
On 2013-08-22 18:19, Thiago Negri wrote:
I think Scala has this optional laziness too.
Indeed, but it's _not_ apparent in types (which can be an issue).
Due to the somewhat weird constructor semantics of the JVM it also means
you can have immutable values which start out(!) as null and end up
On 2013-08-07 22:38, Joe Quinn wrote:
On 8/7/2013 11:00 AM, David Thomas wrote:
twice :: IO () - IO ()
twice x = x x
I would call that evaluating x twice (incidentally creating two
separate evaluations of one pure action description), but I'd like to
better see your perspective here.
x
On 2013-07-31 09:22, Alexey Uimanov wrote:
Regard parameterized SQL: It might be worth using named parameters (e.g.
:foo and :bar or something like that) rather than ? as
placeholders in SQL/prepared SQL. This will make it slightly more
flexible if you need to provide different SQL strings
On 2013-07-31 05:45, Alexey Uimanov wrote:
Hello, haskellers. This is the first release of HDBI (Haskell Database
Independent interface). It is the fork of HDBC.
HDBI has some improvements in design, it also has better testing and
performance (mainly because of using Text instead of String
On 2013-07-22 17:09, i c wrote:
Usage of shadowing is generally bad practice. It is error-prone. Hides
obnoxious bugs like file descriptors leaks.
These claims need to be substantiated, I think.
(Not that I disagree, I just think that asserting this without evidence
isn't going to convince
On 2013-07-23 21:37, i c wrote:
let's consider the following:
let fd = Unix.open ...
let fd = Unix.open ...
At this point one file descriptor cannot be closed. Static analysis will
have trouble catching these bugs, so do humans.
Disallowing variable shadowing prevents this.
The two fd
On 06/24/2013 06:18 AM, Mark Lentczner wrote:
Thanks all, I’ve got what I needed.
Finally, 15% seem to be using horrid bitmap console fonts. _How can you
stand to look at them?!?!_ (Don't worry, you'll have Plush soon enough...)
I realize this is probably a bit tongue-in-cheek, but for my
On 05/11/2013 11:10 AM, Alberto G. Corona wrote:
Hi Café:
I created just now an issue in cabal-dev:
https://github.com/creswick/cabal-dev/issues/101
When compiling old developments, I wish cabal-dev to install and build
dependencies that were available at a that time
I
On 05/03/2013 06:44 PM, Niklas Hambüchen wrote:
While I certainly enjoy the discussion, how about addressing one of the
original problems:
On 02/05/13 13:27, Adrian May wrote:
I just tried to use Flippi. It broke because of the syntax change so I
tried WASH. I couldn't even install it
On 05/03/2013 06:49 PM, Edward Kmett wrote:
Tantamount to a new language to fix a minor detail in a typeclass
hierarchy? That is just histrionic. *No* language is that stable.
Scala makes dozens of changes like that between *minor* versions, and while
I hardly hold up their development
On 02/09/2013 09:56 AM, Johan Holmquist wrote:
[--snip--]
It just so happened that the old code triggered some aggressive
optimization unbeknownst to everyone, **including the original
developer**, while the new code did not. (This optimization maybe even
was triggered only on a certain
On 02/09/2013 10:50 AM, Johan Holmquist wrote:
I guess I fall more to the reason about code side of the scale
rather than testing the code side. Testing seem to induce false
hopes about finding all defects even to the point where the tester is
blamed for not finding a bug rather than the
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:
On 12/12/2012 06:01 PM, Janek S. wrote:
In the recent months there was a lot of dicussion about cabal, dependency
hell and alike. After
reading some of these discussions there is a question I just have to ask:
Why not create a package manager (like rpm or apt) for Haskell software?
I've
On 12/10/2012 01:20 AM, Eli Frey wrote:
Jerzy makes a good point that you might not be the best judge of what you
should learn.
Not only that: you have *no reliable way of knowing* what you might be
missing.
Any half-decent CS education gives you a very broad grounding in the
field so that
On 11/28/2012 08:38 PM, Leon Smith wrote:
I have some code that reads (infrequently) small amounts of data from
/dev/urandom, and because this is pretty infrequent, I simply open the
handle and close it every time I need some random bytes.
The problem is that I recently discovered that,
On 09/30/2012 02:46 AM, KC wrote:
http://martinfowler.com/eaaDev/EventSourcing.html
http://martinfowler.com/articles/lmax.html
Sure, why not? See
http://hackage.haskell.org/package/cqrs-0.8.0
and http://hackage.haskell.org/package/cqrs-example-0.8.0
for an example application.
I
On 07/17/2012 08:34 AM, Yifan Yu wrote:
First of all, apologise if the question is too broad. The background goes
like this: I've implemented a server program in Haskell for my company
intended to replace the previous one written in C which crashes a lot (and
btw the technology of the company
On 07/17/2012 10:17 PM, Christopher Done wrote:
On 17 July 2012 22:10, Bardur Arantsson s...@scientician.net wrote:
On 07/17/2012 08:34 AM, Yifan Yu wrote:
I can only tell if I browse the source code. So the question is, how can I
determine all the exceptions that can be thrown by a given
On 07/12/2012 11:04 PM, Ganesh Sittampalam wrote:
Hi,
On 12/07/2012 13:06, Takayuki Muranushi wrote:
Today I have observed that hackage.haskell.org/ timeout twice (in the
noon and in the evening.)
What is the problem? Is it that haskell users have increased so that
haskell.org is
On 07/11/2012 05:12 PM, Michael Snoyman wrote:
Thanks for the feedback. However, looking at sqlite3.c, I see the
necessary #include statements:
#include sys/types.h
#include sys/stat.h
#include unistd.h
I'm confident that none of my code is making calls to stat/stat64 via
the FFI. In
On 05/24/2012 04:13 AM, Brandon Allbery wrote:
On Wed, May 23, 2012 at 9:47 PM, KC kc1...@gmail.com wrote:
exponentiation and logarithm.
So, I believe this C++ versus Haskell versus (your language of choice) is
a Penn Teller misdirection.
Whereas, another level of indirection solves
On 05/16/2012 09:02 PM, Gregg Lebovitz wrote:
Isaac,
I was looking at the debian coding contest benchmarks referenced by
others in this discussion. All of the benchmarks algorithms, appear to
be short computationally intensive programs with a fairly low level of
abstraction.
In almost
On 05/02/2012 07:37 PM, Brandon Allbery wrote:
On 2 May 2012 18:18, Brent Yorgeybyor...@seas.upenn.edu wrote:
I am curious how the title was translated. Of course, the English
title Learn You a Haskell for Great Good uses intentionally
ungrammatical/unidiomatic English for humorous effect.
On 03/06/2012 11:38 PM, Christopher Done wrote:
I might as well chime in on this thread as it is relevant to my
interests. I made a write up on a comparison of HJScript (JavaScript
EDSL) and my Ji (control browser from Haskell) library:
https://github.com/chrisdone/ji
HJScript is OK, hpaste.org
On 03/05/2012 04:58 PM, burak ekici wrote:
Dear List;
I have parallelized RSA decryption and encryption schemes
by using second generation strategies of Haskell p.l.
In that case, what I got in the sense of speed up was nearly
10 times of better performances (on a quad-core CPU with 8M cache)
On 02/14/2012 04:13 PM, Doug McIlroy wrote:
Nevertheless, I share Jardine's concern about the central problem.
It is hard to find one's way in this ecosystem. It needn't be,
as Java illustrates.
As a professional Java developer this sounds really strange, but maybe I
just haven't found it
On 02/13/2012 09:36 PM, Michael Snoyman wrote:
You make it sound like your options are use the crippled abstraction
layer or use the full-powered database layer. You're leaving out
two very important points:
1. There's a reason the abstraction layer exists: it can be clumsy to
go directly to
On 01/26/2012 11:16 AM, dokondr wrote:
On Thu, Jan 19, 2012 at 1:37 AM, Dag Odenhalldag.odenh...@gmail.comwrote:
On Tue, 2012-01-17 at 22:05 +0300, dokondr wrote:
I prefer using Turing complete PL to program web client, like the one
used
in GWT (Java) or Cappuccino (Objective-J).
On 01/14/2012 11:42 AM, Joey Adams wrote:
On Sat, Jan 14, 2012 at 1:29 AM, Bardur Arantssons...@scientician.net wrote:
So, the API becomes something like:
runSocketServer :: ((Chan a, Chan b) - IO ()) - ... - IO ()
where the first parameter contains the client logic and A is the type
On 01/14/2012 06:24 AM, Joey Adams wrote:
I'm not happy with asynchronous I/O in Haskell. It's hard to reason
about, and doesn't compose well. At least in my code.
[--snip--]
Async I/O *is* tricky if you're expecting threads to do their own
writes/reads directly to/from sockets. I find
2012/1/3 Yucheng Zhangyczhan...@gmail.com
(Hopefully being a little more explicit about this can help you
understand where things are going wrong.)
[--snip--]
legSome :: LegGram nt t s - nt - Either String ([t], s)
The 'nt' you see above
legSome (LegGram g) ntV =
case Main.lookup
Hi all,
No Haddock documentation seems to have been generated on Hackage in the
past few days. See e.g.
http://hackage.haskell.org/package/copilot-2.0.3
or http://hackage.haskell.org/package/derive-2.5.5
Does anyone know if the cron job (or whatever) isn't running for some
reason?
On 12/29/2011 07:07 PM, Steve Horne wrote:
On 29/12/2011 10:05, Jerzy Karczmarczuk wrote:
Sorry, a long and pseudo-philosophical treatise. Trash it before reading.
Heinrich Apfelmus:
You could say that side effects have been moved from functions to
some other type (namely IO) in Haskell.
I
On 12/29/2011 11:06 PM, Steve Horne wrote:
On 29/12/2011 21:01, Chris Smith wrote:
On Thu, 2011-12-29 at 18:07 +, Steve Horne wrote:
By definition, an intentional effect is a side-effect. To me, it's by
deceptive redefinition - and a lot of arguments rely on mixing
definitions - but
On 12/29/2011 09:39 PM, Jerzy Karczmarczuk wrote:
Truly random numbers are very rarely used, forget about them.
Well, obviously, but why should we forget about them? The usual
approach(*) is to gather entropy from a truly(**) random source
and use that to seed (and perhaps periodically
On 12/30/2011 04:38 PM, Jerzy Karczmarczuk wrote:
Bardur Arantsson:
Random streams are not referentially transparent, though, AFAICT...?
Either way this thread has gone on long enough, let's not prolong it
needlessly with this side discussion.
Sure.
But the discussion on randomness
On 12/30/2011 10:10 PM, Steve Horne wrote:
On 30/12/2011 10:47, Bardur Arantsson wrote:
On 12/29/2011 11:06 PM, Steve Horne wrote:
Calling it a straw man won't convince anyone who has the scars from
being attacked by those straw men.
I've been in those arguments, being told that C has side
On 12/29/2011 08:47 PM, Steve Horne wrote:
On 29/12/2011 19:21, Heinrich Apfelmus wrote:
BTW - why use an IO action for random number generation? There's a
perfectly good pure generator. It's probably handy to treat it
monadically to sequence the generator state/seed/whatever but random
Alexander Solla wrote:
I happen to only write Haskell programs that terminate. It is not that
hard. We must merely restrict ourselves to the total fragment of the
language, and there are straight-forward methods to do so.
Do (web/XML-RPC/whatever) server type programs terminate?
Michael Litchard wrote:
[--snip--]
If getting hit by a bus is a significant factor in the overall outcome of
the project then I think those are pretty good odds, aren't they?
(I do realize that traffic accidents are a lot more frequent than we like to
think, but still...)
--
Bárður
Andrew Coppin wrote:
On 16/12/2011 07:05 PM, Bardur Arantsson wrote:
Michael Litchard wrote:
[--snip--]
If getting hit by a bus is a significant factor in the overall outcome of
the project then I think those are pretty good odds, aren't they?
(I do realize that traffic accidents
On 12/13/2011 02:43 AM, Brandon Allbery wrote:
On Mon, Dec 12, 2011 at 19:22, Ian-Woo Kimianwoo...@gmail.com wrote:
A workaround is to make a symbolic link to libstdc++.so.6 with the
name of libstdc++.so in /usr/lib or /usr/local/lib or other dynamic
library path like the following.
ln -s
On 04/28/2011 12:19 AM, Ganesh Sittampalam wrote:
On 26/04/2011 12:17, Malcolm Wallace wrote:
On 25 Apr 2011, at 11:13, Andrew Coppin wrote:
On 24/04/2011 06:33 PM, Jason Dagit wrote:
This is because of a deliberate choice that was made by David Roundy.
In darcs, you never have multiple
On 2010-10-30 07:07, Mark Spezzano wrote:
Hi,
Can somebody please explain exactly how the monad functions sequence and
sequence_ are meant to work?
I have almost every Haskell textbook, but there's surprisingly little
information in them about the two functions.
From what I can gather,
On 2010-06-03 05:10, Matthias Reisner wrote:
Hi,
there's something wrong with port numbers in the Network.Socket module
of package network. Printing values gives:
*Main PortNum
47138
*Main PortNum 47138
Try
(fromIntegral ) :: PortNumber
(Yes, it's weird.)
Cheers,
Bardur
On 2010-02-24 20:50, Brandon S. Allbery KF8NH wrote:
tcpdump 'host ps3 and tcp[tcpflags] 0x27 != 0'
(Indulging in some serious thread necromancy here, but...)
Alright, I've _finally_ got round to doing a dump with leaking file
descriptors (or threads as the case may be).
The bits of lsof
On 2010-02-24 05:10, Brandon S. Allbery KF8NH wrote:
On Feb 21, 2010, at 20:17 , Jeremy Shaw wrote:
The PS3 does do something though. If we were doing a write *and* read
select on the socket, the read select would wakeup. So, it is trying
to notify us that something has happened, but we are not
Jeremy Shaw wrote:
Hello,
I think to make progress on this bug we really need a failing test case that
other people can reproduce.
I have hacked up small server that should reproduce the error (using fdWrite
instead of sendfile). And a small C client which is intended to reproduce
the error --
Taru Karttunen wrote:
Excerpts from Bardur Arantsson's message of Wed Feb 17 21:27:07 +0200 2010:
For sendfile, a timeout of 1 second would probably be fine. The *ONLY*
purpose of threadWaitWrite in the sendfile code is to avoid busy-waiting
on EAGAIN from the native sendfile.
Of course this
Jeremy Shaw wrote:
On Wed, Feb 17, 2010 at 2:36 AM, Taru Karttunen tar...@taruti.net wrote:
So for sendfile, instead of threadWaitWrite we could do:
r - timeout (60 * 10^6) threadWaitWrite
case r of
Nothing - ... -- timed out
(Just ()) - ... -- keep going
For sendfile, a timeout of
Jeremy Shaw wrote:
On Sun, Feb 14, 2010 at 2:04 PM, Bardur Arantsson s...@scientician.netwrote:
Not sure what the best solution for this would be, API-wise... Maybe
actually have sendfile read the data and supply it to a user-defined
function which could react to the data in some way? (Could
Bardur Arantsson wrote:
Jeremy Shaw wrote:
[--snip--]
Re: a test case, you'll probably need to run the test case code on a
client whose OS allows (from userspace) the sudden dropping of
connections without sending a proper connection shutdown sequence. I'm
not sure that that OS would
Taru Karttunen wrote:
Excerpts from Bardur Arantsson's message of Tue Feb 16 22:57:23 +0200 2010:
As far as I can tell, all nonblocking networking code is vulnerable to
this issue (unless it actually does use threadWaitRead, obviously :)).
There are a few easy fixes:
1) socket timeouts with
Jeremy Shaw wrote:
import Control.Concurrent
import Control.Concurrent.MVar
import System.Posix.Types
data RW = Read | Write
threadWaitReadWrite :: Fd - IO RW
threadWaitReadWrite fd =
do m - newEmptyMVar
rid - forkIO $ threadWaitRead fd putMVar m Read
wid - forkIO $
Jeremy Shaw wrote:
import Control.Concurrent
import Control.Concurrent.MVar
import System.Posix.Types
data RW = Read | Write
threadWaitReadWrite :: Fd - IO RW
threadWaitReadWrite fd =
do m - newEmptyMVar
rid - forkIO $ threadWaitRead fd putMVar m Read
wid - forkIO $
Jeremy Shaw wrote:
On Wed, Feb 10, 2010 at 1:15 PM, Bardur Arantsson s...@scientician.netwrote:
I've also been contemplating some solutions, but I cannot see any solutions
to this problem which could reasonably be implemented outside of GHC itself.
GHC lacks a threadWaitError, so there's
Thomas DuBuisson wrote:
Bardur Arantsson s...@scientician.net wrote:
...
then do errno - getErrno
if errno == eAGAIN
then do
threadDelay 100
sendfile out_fd in_fd poff bytes
else throwErrno
Jeremy Shaw wrote:
On Feb 11, 2010, at 1:57 PM, Bardur Arantsson wrote:
[--snip lots of technical info--]
Thanks for digging so much into this.
Just a couple of comments:
The whole point of the sendfile library is to use sendfile(), so not
using sendfile() seems like the wrong solution
Jeremy Shaw wrote:
On Feb 9, 2010, at 6:47 PM, Thomas Hartman wrote:
Matt, have you seen this thread?
Jeremy, are you saying this a bug in the sendfile library on hackage,
or something underlying?
I'm saying that the behavior of the sendfile library is buggy. But it
could be due to
Bardur Arantsson wrote:
Bardur Arantsson wrote:
(sorry about replying-to-self)
During yet another bout of debugging, I've added even more I am here
instrumentation code to the SendFile code, and the culprit seems to be
threadWaitWrite.
As Jeremy Shaw pointed out off-list, the symptoms
Jeremy Shaw wrote:
It's not clear to me that this is actually a bug in threadWaitWrite.
I believe that under Linux, select() does not wakeup just because the file
descriptor was closed.
select() has the option of specifying an exceptfds FD_SET where I'd
certainly _expect_ select() to flag an
Brandon S. Allbery KF8NH wrote:
On Feb 5, 2010, at 02:56 , Bardur Arantsson wrote:
[--snip--]
Broken pipe is normally handled as a signal, and is only mapped to an
error if SIGPIPE is set to SIG_IGN. I can well imagine that the SIGPIPE
signal handler isn't closing resources properly
Felipe Lessa wrote:
On Sat, Feb 06, 2010 at 09:16:35AM +0100, Bardur Arantsson wrote:
Brandon S. Allbery KF8NH wrote:
On Feb 5, 2010, at 02:56 , Bardur Arantsson wrote:
[--snip--]
Broken pipe is normally handled as a signal, and is only mapped
to an error if SIGPIPE is set to SIG_IGN. I can
Bardur Arantsson wrote:
(sorry about replying-to-self)
During yet another bout of debugging, I've added even more I am here
instrumentation code to the SendFile code, and the culprit seems to be
threadWaitWrite.
I think I've pretty much confirmed this.
I've changed the code again
Jeremy Shaw wrote:
Actually,
We should start by testing if native sendfile leaks file descriptors even
when the whole file is sent. We have a test suite, but I am not sure if it
tests for file handle leaking...
I should have posted this earlier, but the exact message I'm seeing in
the case
Thomas Hartman wrote:
Do you have a test script to reproduce the behavior?
Unfortunately not, but the behavior *is* 100% reproducible with
my PS3 client. The production of a leaked FD appears to require a
particularly abrupt disconnect (see my other reply in this thread), so
you're probably
I desperation, I've tried to instrument a couple of the functions in
SendFile:
sendFile'' :: Socket - Handle - Integer - Integer - IO ()
sendFile'' outs inp off count =
do let out_fd = Fd (fdSocket outs)
in_fd - handleToFd inp
putStrLn (in_fd= ++ show in_fd)
Hi all,
I've been using the sendfile package off Hackage, but it seems to be
leaking file descriptors when using the Linux-native build.
What's happening in my specific case is the following:
1) client requests a range of a file
2) server starts sending the range
3) client
Michael Snoyman wrote:
[--snip--]
Next, I have made the ResponseBodyClass typeclass specifically with the goal
of allowing optimizations for lazy bytestrings and sending files. The former
seems far-fetched; the latter provides the ability to use a sendfile system
call instead of copying the
Hi all,
Sorry about the inflammatory title, but I just got this message from an
uploaded package (hums):
Warning: This package indirectly depends on multiple versions of the
same package. This is highly likely to cause a compile failure.
The thing is, I got the same message while trying
byte order (hton).
Oleg's Iteratee does look very interesting though. Maybe I'll have a go
at trying to use his ideas in my UPnP server.
Cheers,
Bardur Arantsson
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman
John Goerzen wrote:
On Thu, Jan 08, 2009 at 10:37:55PM +0100, Bardur Arantsson wrote:
Don't get me wrong -- the socket support is pretty decent, but there are
also some weird idiosyncrasies, for example requiring that the PortNum
is specified in network byte order and lacking a function
a
useful function. It can be used properly, or not, just as while or
read() in C can be.
It's a great way to introduce unavoidable handle leaks, that's for sure.
Cheers,
Bardur Arantsson
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http
77 matches
Mail list logo
