Calvin Smith wrote:
On 02/14/2008 11:13 PM, Janis Voigtlaender wrote:
Don Stewart wrote:
voigt:
I always use gmane, via:
http://news.gmane.org/search.php?match=haskell
The problem with this is that when searching through gmane, and
selecting a single message with a hit, one gets only t
Ben Franksen <[EMAIL PROTECTED]> schrieb:
> Wilhelm B. Kloke wrote:
>> [EMAIL PROTECTED] <[EMAIL PROTECTED]> schrieb:
>>>
>> I would consider a good idea if ghc would provide language support to
>> this sort of integers.
>
> No need, you can do that for yourself:
>
> {-# LANGUAGE GeneralizedNewtype
On 02/14/2008 11:13 PM, Janis Voigtlaender wrote:
> Don Stewart wrote:
>> voigt:
>>
>> I always use gmane, via:
>>
>> http://news.gmane.org/search.php?match=haskell
>
> The problem with this is that when searching through gmane, and
> selecting a single message with a hit, one gets only to see
Don Stewart wrote:
voigt:
Hi,
it seems that something is wrong with the search on
http://www.mail-archive.com/[EMAIL PROTECTED]/
Only messages from Nov and Dec 2007 are found, no matter what search
phrases and date ranges are given.
Worked yesterday and delivered search results over the
On Feb 14, 2008, at 4:44 PM, Adam Langley wrote:
HsOpenSSL now has rudimentary support for writing SSL servers[5]
(clients coming soon). In terms of blocking IO, this /should/ work the
way you would hope (i.e. like a Haskell function w.r.t. forkIO).
Coincidentally, night before last I downloa
On Thu, Feb 14, 2008 at 7:34 PM, Steve Lihn <[EMAIL PROTECTED]> wrote:
> I have a small question on the simulation technique. In both John
> Hughes and your code, you wrap the "print" inside the runXYZ (...) to
> print out the state of simulation. It is like:
>
> runArrow ( ... simulation ...th
On Thu, Feb 14, 2008 at 08:23:29PM -0800, Uwe Hollerbach wrote:
> Stefan's routine is, as expected, much much faster still: I tested the
> first two routines on numbers with 5 million or so bits and they took
> ~20 seconds of CPU time, whereas I tested Stefan's routine with
> numbers with 50 millio
Hi, all, a few days ago I had asked about fast integer log-2 routines,
and got a couple of answers. I've now had a chance to play with the
routines, and here's what I found. Initially, Thorkil's routine taken
from the Haskell report was about 30% or so faster than mine. When I
replaced the calls to
Matthew Naylor wrote:
> it's not immediately clear (to me at least) how efficient your method
> will be in "practice". Any method based on common sub-expression
> elimination surely must inspect every node in the flattened graph. In
> the worst case, an acyclic graph containing n nodes could hav
On 15 Feb 2008, at 2:03 am, Wilhelm B. Kloke wrote:
IMHO it is a perfectly good idea to use the FP processor for integer
computations. You can use the Inexact Trap as Overflow Exception,
a service you don't get from i386 (and most other) hardware for int
operations.
A neat idea. However, the i
On 14 Feb 2008, at 10:24 pm, Roman Leshchinskiy wrote:
Do I understand correctly that you advocate using overflowing ints
(even if they signal overflow) even if Integers are fast enough for
a particular program?
No you most certainly do NOT. There is no way to soundly, and I
would have
> > 1. Stream
> This is actually a comonad.
Something more to learn everyday.
> Here's another fun arrow:
>
> http://luqui.org/blog/archives/2007/09/06/quantum-entanglement-in-haskell/
>
> Luke
>
Luke,
I managed to get your quantum entanglement examples working. But
honestly, I can't quite figur
On Thu, Feb 14, 2008 at 5:12 PM, Scott West <[EMAIL PROTECTED]> wrote:
>
> On Thu, Feb 14, 2008 at 4:43 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> > saynte:
> >
> >
> > > On Thu, Feb 14, 2008 at 3:02 PM, Denis Bueno <[EMAIL PROTECTED]> wrote:
> > > > On Thu, Feb 14, 2008 at 2:55 PM, Don Ste
byorgey:
>On Wed, Feb 13, 2008 at 2:46 AM, Juergen Nicklisch-Franken
><[EMAIL PROTECTED]> wrote:
>
> I'm pleased to announce the first release of Leksah, an IDE for
> Haskell written in Haskell. Leksah is intended as a practical tool
> to support the Haskell development proc
Binary parsing:
binary-strict now has support for combinator parsing[1] with <|> and
friends. This works both for the strict Get and the IncrementalGet.
(The latter was more complex than I expected)
binary-strict also gained a very fast byte set module[2] (used for
scanning ranges of valid bytes)
G'day all.
Quoting Thorkil Naur <[EMAIL PROTECTED]>:
Finding the "machine epsilon", perhaps, that is, the smallest
(floating point,
surely) number for which 1.0+machine_eps==1.0 would be a candidate?
The machine epsilon is the smallest relative separation between two
adjacent normalised fl
Hello,
You rule!
Here is where I am at now. It seems that when I build ghc from source,
the top level configure script detects that my system has large file
support, and enables it. As you discovered, this gets dumped into:
/usr/lib/ghc-6.8.2/include/ghcautoconf.h
which gets included when hsc2h
Created a ticket with a patch:
http://hackage.haskell.org/trac/ghc/ticket/2093
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Aaron Denney wrote:
On 2008-02-14, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
Richard A. O'Keefe wrote:
SafeInt is what you should use when you *THINK* your results should all fit
in a machine int but aren't perfectly sure. (And this is nearly all the
time.)
Again, I strongly disagree. Y
On Thu, Feb 14, 2008 at 4:43 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> saynte:
>
>
> > On Thu, Feb 14, 2008 at 3:02 PM, Denis Bueno <[EMAIL PROTECTED]> wrote:
> > > On Thu, Feb 14, 2008 at 2:55 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> > > > You can use the profiler to get a stack trace,
Hello,
On a tangent, probably:
On Thursday 14 February 2008 10:24, Roman Leshchinskiy wrote:
> ...
> Hmm. Personally, I've never seen an algorithm where comparing for exact
> equality was algorithmically necessary. Sometimes (rarely) it is
> acceptable but necessary? Do you know of one?
Find
saynte:
> On Thu, Feb 14, 2008 at 3:02 PM, Denis Bueno <[EMAIL PROTECTED]> wrote:
> > On Thu, Feb 14, 2008 at 2:55 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> > > You can use the profiler to get a stack trace, or use the new
> > > GHCi debugger to step backwards from the exception to the sourc
jed:
> Hopefully these are mature enough to be generally useful. I would
> appreciate any comments regarding the interface. The FFTW API is not
> particularly nice for building a pure interface on. Some of the
> transforms could be made slightly faster at the expense of a much
> nastier interfac
Hopefully these are mature enough to be generally useful. I would
appreciate any comments regarding the interface. The FFTW API is not
particularly nice for building a pure interface on. Some of the
transforms could be made slightly faster at the expense of a much
nastier interface, but unless s
On Thu, Feb 14, 2008 at 3:02 PM, Denis Bueno <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 14, 2008 at 2:55 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> > You can use the profiler to get a stack trace, or use the new
> > GHCi debugger to step backwards from the exception to the source.
> >
> > I
On Thu, Feb 14, 2008 at 2:55 PM, Don Stewart <[EMAIL PROTECTED]> wrote:
> You can use the profiler to get a stack trace, or use the new
> GHCi debugger to step backwards from the exception to the source.
>
> I wrote a bit of a tutorial for this here:
>
> http://cgi.cse.unsw.edu.au/~dons/blog/20
saynte:
> Hello all,
>
> Does anyone favourite technique to track down an "undefined" call? I'm
> 99% sure that my code is not the offender (I've grepped for undefined
> occurrences and turned them all into "error" calls). Supposing that
> this is happening in some other package or library that I'
Hello all,
Does anyone favourite technique to track down an "undefined" call? I'm
99% sure that my code is not the offender (I've grepped for undefined
occurrences and turned them all into "error" calls). Supposing that
this is happening in some other package or library that I'm using,
what is the
Filed as:
http://hackage.haskell.org/trac/ghc/ticket/2096
--
Adam Langley [EMAIL PROTECTED]
http://www.imperialviolet.org 650-283-9641
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Wilhelm B. Kloke wrote:
> [EMAIL PROTECTED] <[EMAIL PROTECTED]> schrieb:
>> G'day all.
>>
>> Richard A. O'Keefe wrote:
>>
>>> Hmm. Personally, I've never seen an algorithm where comparing for exact
>>> equality was algorithmically necessary.
>>
>> One trick I've occasionally used is to avoid the ne
Currently their is no mailing list and no bug tracker. Until yesterday
it was a "one person - I do it inbetween" project.
If others like to contribute, which would be great, I think about
writing a short "one page" developers intro.
Jürgen
Am Donnerstag, den 14.02.2008, 10:44 -0500 schri
On 2008-02-14, Roman Leshchinskiy <[EMAIL PROTECTED]> wrote:
> Richard A. O'Keefe wrote:
>> Presumably the reason for having Int in the language at all is speed.
>> As people have pointed out several times on this list to my knowledge,
>> Integer performance is not as good as Int performance, not h
Stephan Friedrichs-2 wrote:
>
>
> it's unsafe to perform IO inside of a transaction as it can't be undone,
> when rolling it back. I guess, unsafeIOToSTM has been designed in order
> to allow us to inject debugging output into a transaction, but you
> really shouldn't use it to perform "real
On Wed, Feb 13, 2008 at 2:46 AM, Jürgen Nicklisch-Franken <[EMAIL PROTECTED]>
wrote:
> I'm pleased to announce the first release of Leksah, an IDE for
> Haskell written in Haskell. Leksah is intended as a practical tool
> to support the Haskell development process.
>
Is there a development listse
Adrian Hey wrote:
I have no objection to people bounding their stack if that's their
choice. I can't imagine why anybody who stopped to think about this
would actually want this feature, but it's free world.
What I object to is it being bounded by default to something other
than overall program
Richard Kelsall wrote:
I mentioned in the previous thread that some longer words weren't
getting indexed. It looks like this has been fixed. All the long words
I just tried worked properly. And, better than Google, the words get
indexed as soon as they are changed. I tried searches for words adde
Mads Lindstrøm wrote:
Richard Kelsall wrote:
Daniil Elovkov wrote:
Hello
I remember there was a problem with haskell wiki pages not being indexed
and searched.
Now it seems to work perfectly. Actually typing 'monomorphism
restriction' in google I see the appropriate wiki page as the first
Stefan O'Rear wrote:
On Mon, Feb 04, 2008 at 10:13:12PM +, Adrian Hey wrote:
Also
remember that this behaviour never wastes more than 50% of the stack,
which is a relatively small amount.
Only if the stack is relatively small. Would you say the same about
heap, or about a stack that only ne
[EMAIL PROTECTED] wrote:
Jed Brown comments the answer of -
-- Roman Leshchinskiy who answers my question concerning the replacement
of floating-point numbers:
> First, when I see the advice "use something else", I always ask
"what",
> and I get an answer very, very rarely... Well? What do you
David Roundy wrote:
Yes, that should all be fine, because the IORef is only modified from one
thread, and read from the other(s). If you were modifying the IORef from
more than one thread you would need to use atomicallyModifyIORef, or MVars.
If I did modify the IORef from more than one thr
[EMAIL PROTECTED] <[EMAIL PROTECTED]> schrieb:
> G'day all.
>
> Richard A. O'Keefe wrote:
>
>> Hmm. Personally, I've never seen an algorithm where comparing for exact
>> equality was algorithmically necessary.
>
> One trick I've occasionally used is to avoid the need for a discriminated
> union of
Hi all,
I have a very simple program which reads a Data.Map from a file using
Data.Binary and Data.ByteString.Lazy, which gives stack overflow with files
over a certain size. Any ideas of what might be causing it?
You can try it with the small file (11M) at:
http://computing.dcu.ie/~gchrupala/map
Jed Brown comments the answer of -
-- Roman Leshchinskiy who answers my question concerning the replacement
of floating-point numbers:
> First, when I see the advice "use something else", I always ask "what",
> and I get an answer very, very rarely... Well? What do you propose?
For Haskell,
I asked Oleg regarding the use of GADTs to emulate dependent types. My
conclusion is that I should forget about them. Here is the full
answer:
-- Forwarded message --
From: <[EMAIL PROTECTED]>
Date: Feb 12, 2008 8:49 AM
Subject: Re: GADTs to emulate dependent types?
To: [EMAIL PR
On 14/02/2008, Alistair Bayley <[EMAIL PROTECTED]> wrote:
> I just downloaded this from hackage and went through the usual Cabal
> ritual. The build fails with
>
> Would I be better off getting straight from the darcs repo?
I compiled from the darcs repo last night, which worked fine.
On 14/02/2008, Alistair Bayley <[EMAIL PROTECTED]> wrote:
>
> src/IDE/Utils/File.hs:161:33:
> Couldn't match expected type `Either String String'
>against inferred type `String'
Never mind; I've just realised this is because I have the latest dev
version of Cabal installed.
Alist
> Leksah is written by me and published under a GPL-2 license.
> Leksah can be optained via Hackage: http://hackage.haskell.org/
> Darcs development repository: http://code.haskell.org/leksah
I just downloaded this from hackage and went through the usual Cabal
ritual. The build fails with
[16
G'day all.
Richard A. O'Keefe wrote:
That's one of the warning signs I watch out for. "Never compare floats for
equality" is a sure sign of someone who thinks they know about
floats but don't.
Quoting Roman Leshchinskiy <[EMAIL PROTECTED]>:
Hmm. Personally, I've never seen an algorithm
Am Donnerstag, 14. Februar 2008 03:23 schrieben Sie:
> To directly answer Wolfgang's question: "parameterized" is the more
> common. It is "more correct" only insofar as it is the more common.
So we should “parameterized” for the package name.
Best wishes,
Wolfgang
___
Richard A. O'Keefe wrote:
On 14 Feb 2008, at 6:01 pm, Roman Leshchinskiy wrote:
I don't understand this. Why use a type which can overflow in the
first place? Why not use Integer?
[...]
Presumably the reason for having Int in the language at all is speed.
As people have pointed out several ti
On 14 Feb 2008, [EMAIL PROTECTED] wrote:
>
> [EMAIL PROTECTED] wrote:
> > Trialog:
> > Roman Leshchinskiy writes:
> >> Richard A. O'Keefe wrote:
> >
> >>> [EMAIL PROTECTED] wrote:
> Would you say that *no* typical floating-point software is reliable?
> >>>
> >>> With lots of hedging and clutc
On Thu, Feb 14, 2008 at 12:50 AM, Steve Lihn <[EMAIL PROTECTED]> wrote:
> He described a few things that "cannot" be represented as a monad, they are:
> 1. Stream
This is actually a comonad.
> 2. FRP
Depends on which FRP you're talking about. This could be the stream
comonoad + the event mon
52 matches
Mail list logo
