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
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 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-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
b
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 perspect
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
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-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
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 an
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 fo
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
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 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 i
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 th
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 ve
On 01/30/2013 08:27 PM, Edward Z. Yang wrote:
> https://status.heroku.com/incidents/489
>
> Unsigned Hackage packages are a ticking time bomb.
>
Somewhere else that shall not be mentioned, someone posted this link
which points to an interesting solution to this problem:
http://www.futurealoo
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?
>
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.
On 07/17/2012 10:17 PM, Christopher Done wrote:
> On 17 July 2012 22:10, Bardur Arantsson 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
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 compa
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
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
> #include
> #include
>
> I'm confident that none of my code is making calls to stat/stat64 via
> the FFI. In case it makes a diff
On 05/24/2012 04:13 AM, Brandon Allbery wrote:
> On Wed, May 23, 2012 at 9:47 PM, KC 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 everything.
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 al
On 05/02/2012 07:37 PM, Brandon Allbery wrote:
On 2 May 2012 18:18, Brent Yorgey 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. Is the
On Wed, May
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.or
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)
i
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 ye
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 Odenhallwrote:
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). http://cappuccino.org/learn/
I
On 01/14/2012 11:42 AM, Joey Adams wrote:
On Sat, Jan 14, 2012 at 1:29 AM, Bardur Arantsson wrote:
So, the API becomes something like:
runSocketServer :: ((Chan a, Chan b) -> IO ()) -> ... -> IO ()
where the first parameter contains the "client logic" and &qu
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 that
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?
Cheer
2012/1/3 Yucheng Zhang
(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 ntV g of
Noth
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
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.
&
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 re-
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 nonethe
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 ha
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
number
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?
_
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&#
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 Árantsson
On 12/13/2011 02:43 AM, Brandon Allbery wrote:
On Mon, Dec 12, 2011 at 19:22, Ian-Woo Kim 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 /usr/lib/libstdc++.so.
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 bra
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,
Bardu
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
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:
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 --
Jeremy Shaw wrote:
On Wed, Feb 17, 2010 at 2:36 AM, Taru Karttunen 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 1 second 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 N
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 O
Jeremy Shaw wrote:
On Sun, Feb 14, 2010 at 2:04 PM, Bardur Arantsson wrote:
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 supply two
standard
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 $ threadW
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 $ threadW
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
Thomas DuBuisson wrote:
Bardur Arantsson wrote:
...
then do errno <- getErrno
if errno == eAGAIN
then do
threadDelay 100
sendfile out_fd in_fd poff bytes
else throwErrno "Network.Socket.SendFi
Jeremy Shaw wrote:
On Wed, Feb 10, 2010 at 1:15 PM, Bardur Arantsson wrote:
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
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 somethin
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 a
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
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
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 S
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 resour
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)
>
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 sa
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 w
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 disconnect
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 file
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
Taru Karttunen wrote:
Hello
network-fancy offers a cleaner API to networking facilities in
Haskell. It supports high-level operations on tcp, udp and unix
sockets.
I would like some feedback on the API
http://hackage.haskell.org/packages/archive/network-fancy/0.1.4/doc/html/Network-Fancy.html
hing uses
ByteString.Lazy.hGetContents doesn't imply a problem to me. It's 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
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 functi
ing a function to convert
host->network 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
Ha
78 matches
Mail list logo
