"Trent W. Buck" <[EMAIL PROTECTED]> writes:
> On Wed, Oct 29, 2008 at 12:39:28PM +0900, Stephen J. Turnbull wrote:
>> Trent W. Buck writes:
>>
>> > In an ideal world, we just make sure it builds with the latest tools,
>> > and let the users of stable distros worry about telling us if it
>> > b
Where can I get ghc-6.10? I cannot see it at haskell.org website.
On 2008-10-29, Don Stewart <[EMAIL PROTECTED]> wrote:
> jwlato:
>> Hello,
>>
>> I was experimenting with using ghc-6.10.0.20081007 on a project, and
>> it seems that binary-0.4.3.1 has markedly worse performance in certain
>> cases
No display lists. The crash happens during the GLUT call "initialize". I
can trigger it from ghci with the following simple incantation:
Prelude> import Graphics.UI.GLUT
Prelude Graphics.UI.GLUT> initialize "foo" []
And no trouble under ghc 6.9.20080622.
Stumped. :(
- Conal
On
David Roundy <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 29, 2008 at 12:11:22PM +1100, Trent W. Buck wrote:
> > > Thus I think the version/upgrade matrix is handy so we can
> > > plan/schedule when it is safe to drop support.
> >
> > In an ideal world, we just make sure it builds with the latest
> >
On Wed, Oct 29, 2008 at 12:11:22PM +1100, Trent W. Buck wrote:
> > Thus I think the version/upgrade matrix is handy so we can
> > plan/schedule when it is safe to drop support.
>
> In an ideal world, we just make sure it builds with the latest tools,
> and let the users of stable distros worry abo
Richard O'Keefe wrote:
Rough guesses:
integer adds, subtracts, and compares are fast,
integer multiplies and divides are much slower,
slow enough that compilers go to some trouble to
do something else when multiplying or dividing
by a constant.
Typically, these days (for both int and fp)..
Brent Yorgey wrote:
Daryoush Mehrtash wrote:
> What is (or where do you see) the computational overhead of the "data"
> declrations?
So, to answer your question, the only computational overhead with a
data declaration is the extra memory and time to store and process the
constructor tags. It us
On Tue, Oct 28, 2008 at 4:42 PM, Juliusz Chroboczek
<[EMAIL PROTECTED]> wrote:
>> Debian is nice in some ways and it's really great that stable lives up
>> to its name, but I am sad that Debian has such old software for so
>> long.
>
> Jason,
>
> I know it's frustrating, but please understand where
On Tue, Oct 28, 2008 at 5:13 PM, Trent W. Buck <[EMAIL PROTECTED]> wrote:
> "Jason Dagit" <[EMAIL PROTECTED]> writes:
>> Debian is nice in some ways and it's really great that stable lives up
>> to its name, but I am sad that Debian has such old software for so
>> long.
>
> Those two properties are
"Jason Dagit" <[EMAIL PROTECTED]> writes:
> Debian is nice in some ways and it's really great that stable lives up
> to its name, but I am sad that Debian has such old software for so
> long.
Those two properties are strongly correlated.
There is backports.org for cases where you want to cherry-p
There's also the ieee-utils package, which provides an IEEE monad with
`setRound`:
http://hackage.haskell.org/packages/archive/ieee-utils/0.4.0/doc/html/Numeric-IEEE-RoundMode.html
signature.asc
Description: This is a digitally signed message part
___
> Debian is nice in some ways and it's really great that stable lives up
> to its name, but I am sad that Debian has such old software for so
> long.
Jason,
I know it's frustrating, but please understand where we're coming from.
There are a number of servers that support our research. The impor
eford:
> > So, to answer your question, the only computational overhead with a
> > data declaration is the extra memory and time to store and process the
> > constructor tags. It usually isn't noticeable, but sometimes the
> > difference can be important.
>
> Is there also potentially overhead du
Hi,
Am Dienstag, den 28.10.2008, 23:26 +0100 schrieb Alberto G. Corona :
> Data.Tcache is a transactional cache with configurable persistence. It
> tries to simulate Hibernate for Java or Rails for Ruby. The main
> difference is that transactions are done in memory trough STM. There
> are transact
Hi Robin,
> [FuncMP problems with pdflatex]
I have no experience whatsoever with pdflatex, I'm sorry, Funcmp works
just fine for me in normal LaTeX, though. That's not exactly what you
need, but from the sound of it, it might be step forward anyway.
First of all, try writing the MetaPost files w
I uploaded TCache to hackage.org.
Data.Tcache is a transactional cache with configurable persistence. It tries
to simulate Hibernate for Java or Rails for Ruby. The main difference is
that transactions are done in memory trough STM. There are transactional
cache implementations for some J2EE serve
On 29 Oct 2008, at 8:31 am, Andrew Coppin wrote:
Hi guys.
This isn't specifically to do with Haskell, but... does anybody have
any idea roughly how fast various CPU operations are?
For example, is integer arithmetic faster or slower than floating-
point? Is addition faster or slower than
Conal, are you using display lists at all? I've had problems with
allocating lists, but you seem to be able to leave off the allocation
step in Windows on nVidia cards so long as you're careful not to
conflict names yourself.
On Tue, Oct 28, 2008 at 4:03 PM, Matti Niemenmaa
<[EMAIL PROTECTED]> wr
Let me offer another suggestion which I think can be
fitted into Haskell quite well. For the applications
of rounding choice that I'm aware of, you want to
choose when you write the code, not when you run it.
This was actually reflected in the design of a real
machine: the DEC Alpha. Floating p
On Tue, Oct 28, 2008 at 08:55:59PM +0100, Henning Thielemann wrote:
>> For example, is integer arithmetic faster or slower than
>> floating-point?
>
> In principle integer arithmetic is simpler and faster. But your
> processor may do it in the same time.
Indeed. Usually there are more integer ari
>
> newtype Good = Good Int
>
> Now, when a value of type Bad is stored at runtime, it will simply
> store an Int, with no tag
>
Did you mean to say Good in the above sentence?
What are the run time implication of newtype vs data where types are
unwrapped and wrapped from on type to another?
T
> So, to answer your question, the only computational overhead with a
> data declaration is the extra memory and time to store and process the
> constructor tags. It usually isn't noticeable, but sometimes the
> difference can be important.
Is there also potentially overhead due to laziness? I m
On Tue, Oct 28, 2008 at 12:13:11PM -0700, Daryoush Mehrtash wrote:
> I Haskell School of Expression (p172), it says:
>
> A newtype declaration is just like a data declaration, except that it can
> > only be used to defined data types with single constructor. The new data
> > type is different fr
Conal Elliott wrote:
> I am using glut32 rather than freeglut (and no need for patching the darcs
> GLUT). I wonder if glut32-vs-freeglut could account for crash-vs-nocrash on
> 6.10 and 6.11 but not 6.9. I'd love to hear from someone on Windows and
> glut32.
Windows XP with SP3
ghc-6.10.2008100
Well, if you want to get down to that level:
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/25112.PDF
page 273
http://www.intel.com/design/processor/manuals/248966.pdf
Appendix C
Thomas
On Tue, Oct 28, 2008 at 7:35 PM, Andrew Coppin
<[EMAIL PROTECTED]>wrote:
> J. Garre
On Tue, 28 Oct 2008, Andrew Coppin wrote:
Hi guys.
This isn't specifically to do with Haskell, but... does anybody have any idea
roughly how fast various CPU operations are?
Unfortunately, the knowledge I acquired for Z80 and MC68000 is no longer
of that importance today.
It's still true
Andrew Coppin wrote:
> This isn't specifically to do with Haskell, but... does anybody have any
> idea roughly how fast various CPU operations are?
>
> For example, is integer arithmetic faster or slower than floating-point?
> Is addition faster or slower than multiplication? How much slower are
>
J. Garrett Morris wrote:
On Tue, Oct 28, 2008 at 12:31 PM, Andrew Coppin
<[EMAIL PROTECTED]> wrote:
This isn't specifically to do with Haskell, but... does anybody have any
idea roughly how fast various CPU operations are?
Yes: it's architecture dependent. I imagine you'll need to mak
On Tue, Oct 28, 2008 at 12:31 PM, Andrew Coppin
<[EMAIL PROTECTED]> wrote:
> This isn't specifically to do with Haskell, but... does anybody have any
> idea roughly how fast various CPU operations are?
Yes: it's architecture dependent. I imagine you'll need to make your
questions at least somewha
Hi guys.
This isn't specifically to do with Haskell, but... does anybody have any
idea roughly how fast various CPU operations are?
For example, is integer arithmetic faster or slower than floating-point?
Is addition faster or slower than multiplication? How much slower are
the trigonometric
2008/10/28 T Willingham <[EMAIL PROTECTED]>
>
> As my first Haskell exposure, I've been working through Real World
> Haskell.
>
> I am considering converting some of my C++ graphics libraries to
> Haskell. I've done a fair amount of googling on the subject, however
> I haven't quite been able to
I Haskell School of Expression (p172), it says:
A newtype declaration is just like a data declaration, except that it can
> only be used to defined data types with single constructor. The new data
> type is different from the analogous one created by a data declaration, in
> that there is no com
Hi,
On Tue, Oct 28, 2008 at 10:11:53AM -0700, Jason Dagit wrote:
> Debian is nice in some ways and it's really great that stable lives up
> to its name, but I am sad that Debian has such old software for so
> long. It's this reason that has always forced me to run testing and
> pull packages from
2008/10/28 brad clawsie <[EMAIL PROTECTED]>:
> -BEGIN PGP SIGNED MESSAGE-
> is this considered a bug?
More like missing feature, but certainly worth fixing.
>
> by the way, a nice feature of ghc would be a --clean option to remove
> .hi, .o files. and maybe a --veryclean to recompile all
by the way, a nice feature of ghc would be a --clean option to remove
.hi, .o files. and maybe a --veryclean to recompile all dependencies. i
have more than once rm'd my .hs files by typo...
add yourself to http://hackage.haskell.org/trac/ghc/ticket/2258 ?-)
btw, ghc head has this new option:
jwlato:
> Hello,
>
> I was experimenting with using ghc-6.10.0.20081007 on a project, and
> it seems that binary-0.4.3.1 has markedly worse performance in certain
> cases. With the following simple test:
>
> > import qualified Data.ByteString.Lazy as L
> > import Data.Binary
> > import Data.Bina
On 2008 Oct 28, at 13:11, Jason Dagit wrote:
So far, the only platforms we need to worry about ghc6.6 on are
OpenBSD and Debian Stale.
Paging Dr. Freud...
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL PROTECTED]
system administrator [openafs,heimdal,too many hats] [EMAIL PR
I agree that the name is not the most descriptive one, and perhaps we
should have the more descriptive ones.
But when I hear "round", I assume it's the kind of rounding Haskell
does. And I assumed this before Haskell came about.
On Tue, Oct 28, 2008 at 6:07 PM, Bart Massey <[EMAIL PROTECTED]> wro
bulat.ziganshin:
> Hello Bit,
>
> Tuesday, October 28, 2008, 6:42:34 PM, you wrote:
>
> > What library can be used to securely hash passwords? From what I
>
> any secure hash, say SHA512
And there are multiple bindings and implementations of SHA on
hackage.haskell.org.
nano-hmac provides a bin
Thanks, David. Helpful data point.
I am using glut32 rather than freeglut (and no need for patching the darcs
GLUT). I wonder if glut32-vs-freeglut could account for crash-vs-nocrash on
6.10 and 6.11 but not 6.9. I'd love to hear from someone on Windows and
glut32.
Please do post a wiki page o
On Tue, Oct 28, 2008 at 8:32 AM, David Roundy <[EMAIL PROTECTED]> wrote:
> Yes, it's important for me to be able to use the latest darcs on my
> debian stable computers.
Debian is nice in some ways and it's really great that stable lives up
to its name, but I am sad that Debian has such old softwa
Bart Massey wrote:
Peter Gavin gmail.com> writes:
The reason for doing it this way is that e.g. 2.5 is
exactly between 2 and 3, and rounding *up* every time
would cause an uneven bias toward 3. To counteract that
effect, rounding to the nearest even integer is used,
which causes the half of th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
"Thomas Schilling" <[EMAIL PROTECTED]> writes:
> 2008/10/27 Dougal Stanton <[EMAIL PROTECTED]>:
>
> The problem is GHCi's linker. It cannot deal with duplicate symbols,
is this considered a bug?
by the way, a nice feature of ghc would be a --clean
On Mon, Oct 27, 2008 at 12:34 AM, Alexander Dunlap
<[EMAIL PROTECTED]> wrote:
> On Sun, Oct 26, 2008 at 9:36 AM, John Lato <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> I was experimenting with using ghc-6.10.0.20081007 on a project, and
>> it seems that binary-0.4.3.1 has markedly worse performance i
I'm interested; please write a wiki page about this.
Regards,
Henk-Jan van Tuyl
--
http://functor.bamikanarie.com
http://Van.Tuyl.eu/
--
On Tue, 28 Oct 2008 16:48:59 +0100, David Sankel <[EMAIL PROTECTED]> wrote:
My setup worked:
- Windows XP.
- ghc-6.11.20081024
- freeglut 2.4.0
On Tue, Oct 28, 2008 at 04:07:12PM +, Bart Massey wrote:
> I'm just saying that the name "round" is unfortunate, since
> there's no single universally accepted mathematical
> definition for it. For this reason many programming
> languages either don't provide it or provide a different
> version
Lennart Augustsson augustsson.net> writes:
> On Mon, Oct 27 2008, Bart Massey cs.pdx.edu> wrote:
> > I think given that the Haskell 98 Report is pretty
> > explicit about the behavior of round, we're stuck with
> > it, but I don't like it. It's yet another tiny
> > impediment to Haskell newbies,
On Tue, Oct 28, 2008 at 16:42, Bit Connor <[EMAIL PROTECTED]> wrote:
> Hello,
>
> What library can be used to securely hash passwords? From what I
> understand, the "bcrypt" algorithm is what the experts recommend. It
> is described in the paper:
>
> http://www.openbsd.org/papers/bcrypt-paper.ps
>
On Tue, 2008-10-28 at 18:49 +0300, Bulat Ziganshin wrote:
> Tuesday, October 28, 2008, 6:42:34 PM, you wrote:
>
> > What library can be used to securely hash passwords? From what I
>
> any secure hash, say SHA512
It's a good idea to salt your passwords before hashing, though. See
http://en.wikip
Hello Bit,
Tuesday, October 28, 2008, 6:42:34 PM, you wrote:
> What library can be used to securely hash passwords? From what I
any secure hash, say SHA512
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
___
Haskell-Cafe
My setup worked:
- Windows XP.
- ghc-6.11.20081024
- freeglut 2.4.0
- darcs version of GLUT (with patched glutGetProcAddress [attached])
- darcs version of OpenGL
Getting freeglut going with ghc on windows is a bit involved. I could write
a walkthrough if there's enough interest.
Hello,
What library can be used to securely hash passwords? From what I
understand, the "bcrypt" algorithm is what the experts recommend. It
is described in the paper:
http://www.openbsd.org/papers/bcrypt-paper.ps
I couldn't find a haskell library for this.
There is a BSD licensed C implementat
On Tue, Oct 28, 2008 at 2:34 AM, Thomas Schilling
<[EMAIL PROTECTED]> wrote:
> GHC contains its own preprocessor, it just needs to be activated using
> -cpp on the command line or {-# LANGUAGE CPP #-} inside the file.
> However, I wasn't suggesting that. I was suggesting that before you
> hand the
Yes, it's important for me to be able to use the latest darcs on my
debian stable computers.
David
On Mon, Oct 27, 2008 at 10:24 PM, Jason Dagit <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I would like to find out if any darcs users who build from the source
> are still using ghc 6.6?
>
> If you are
On Tue, Oct 28, 2008 at 9:44 PM, Niklas Broberg
<[EMAIL PROTECTED]> wrote:
> On Tue, Oct 28, 2008 at 7:56 AM, Reiner Pope <[EMAIL PROTECTED]> wrote:
>> I've tried it out and it looks good so far. I had to fiddle with
>> haskell-src-ext's .cabal file to get it to install with GHC 6.10,
>> which is s
On Tue, Oct 28, 2008 at 7:56 AM, Reiner Pope <[EMAIL PROTECTED]> wrote:
> I've tried it out and it looks good so far. I had to fiddle with
> haskell-src-ext's .cabal file to get it to install with GHC 6.10,
> which is surprising since it isn't listed as a broken package... ah
> well.
Care to tell
On Mon, Oct 27, 2008 at 6:15 PM, Bart Massey <[EMAIL PROTECTED]> wrote:
> BTW, in case anyone is unclear, IEEE 854 supports a large
> variety of required and optional rounding modes; it takes no
> strong position on a "correct" rounding strategy. In
> particular, round-up ("round-half-up") and roun
GHC contains its own preprocessor, it just needs to be activated using
-cpp on the command line or {-# LANGUAGE CPP #-} inside the file.
However, I wasn't suggesting that. I was suggesting that before you
hand the input to the ghc api, you substitute all occurences of import
"foo" by something tha
You're assuming newbies from a bad educational system that hasn't
taught them how to round properly. :)
-- Lennart
On Mon, Oct 27, 2008 at 10:15 PM, Bart Massey <[EMAIL PROTECTED]> wrote:
> I think given that the Haskell 98 Report is pretty explicit
> about the behavior of round, we're stuck wi
2008/10/27 Dougal Stanton <[EMAIL PROTECTED]>:
> This happens when, for example, your code imports a library which was
> compiled with a previous version of bytestring. Replacing bytestring
> on its own isn't enough to solve the problem. To make things more
> awkward, it could be several libraries
Ooh, interesting. I'm going to look into this..
On 10/28/08, Reiner Pope <[EMAIL PROTECTED]> wrote:
> Unfortunately, I've uncovered a problem in the parser. For instance,
> with your module, [$hs|1+1*2|] evaluates to 4 rather than 3. This
> seems to be a general problem with infix operators, which
61 matches
Mail list logo
