Don Stewart [EMAIL PROTECTED] writes:
One small upside (performance wise), is that the bottom 3 bits of the
pointer are now used to encode the constructor on 64 bits, so 'case' gets a
good percent cheaper.
Well - my experience (which is from before this optimization was
added, I think) is
Things to avoid - HaskellWiki - 7 Related Links:
http://www.haskell.org/haskellwiki/Things_to_avoid#Related_Links
The link was broken (it had an extra chunk of '- Haskell Wiki' ;) )
so I fixed it. For that matter, the Common Hugs Messages link is
broken too but I can't seem to find the page it
Ariel,
--- Ariel J. Birnbaum [EMAIL PROTECTED] wrote:
Things to avoid - HaskellWiki - 7 Related Links:
http://www.haskell.org/haskellwiki/Things_to_avoid#Related_Links
The link was broken (it had an extra chunk of '-
Haskell Wiki' ;) )
so I fixed it.
Thank you; sorry about the broken
Lennart Augustsson wrote:
To reuse a favorite word, I think that any implementation that
distinguishes 'a - b, a - c' from 'a - b c' is broken. :)
It does not implement FD, but something else. Maybe this something
else is useful, but if one of the forms is strictly more powerful than
the
On Wed, 2008-04-16 at 11:00 +0530, Abhay Parvate wrote:
Your mail gives me an idea, though I am not an iota familiar with
compiler/garbage collector internals. Can we have some sort of
internally maintained priority associated with allocated objects? The
garbage collector should look at these
On Tue, 2008-04-15 at 22:15 -0500, John Goerzen wrote:
When I went to make my upload of MissingH 1.0.1, Hackage rejected it,
saying:
Instead of 'ghc-options: -XPatternSignatures' use 'extensions:
PatternSignatures'
It hadn't rejected MissingH 1.0.0, even though it had the same thing.
I
On Fri, 2008-04-18 at 13:59 +0400, Bulat Ziganshin wrote:
Hello Duncan,
Friday, April 18, 2008, 1:43:24 PM, you wrote:
older Cabal versions). We can make it stricter again in the future when
Cabal-1.4+ is much more widely deployed.
the problem, imho, is that such tools as Cabal, GHC,
Hello Duncan,
Friday, April 18, 2008, 1:43:24 PM, you wrote:
older Cabal versions). We can make it stricter again in the future when
Cabal-1.4+ is much more widely deployed.
the problem, imho, is that such tools as Cabal, GHC, Hackage should be
built with forward and backward compatibility in
Hello Ketil,
Friday, April 18, 2008, 10:44:53 AM, you wrote:
This probably becomes too complicated, but I thought it was
interesting that the Java people are making use of 32bit pointers on a
64bit system, and are seeing a good performance benefit from it.
afaik, C compilers support this
More algebraically, including 'or' for symmtry:
and xs = foldr () True xs
or xs = foldr (||) False xs
The True and False are the (monoid) identities with respect to and || :
True x == x
x True == x
False || x == x
x || False == x
And so an empty list, if defined at all, should be the
On Fri, Apr 18, 2008 at 10:43:24AM +0100, Duncan Coutts wrote:
I have now fixed that by eliminating the use of Read in the .cabal
parser and basically adding an Other/Unknown constructor to several of
the enumeration types, including Extension. So as of Cabal-1.4 it will
be possible to add new
On Fri April 18 2008 4:43:24 am Duncan Coutts wrote:
It seems arbitrary that Hackage would suddenly reject this valid
usage.
Yes it is valid though I hope you can see the general intention of the
suggestion. If it were not for the compatibility problem it would be
preferable to use:
Sure,
Although you could use gcc to link the code I wouldn't recommend it
(mainly for the problems you are currently having)
SImply call GHC to compile both the C and Haskell code. It will take
care of finding the headers and supplying the necessary linker
arguments.
ghc -ffi -c foo.hs myfoo_c.c
Hello fellow Haskellers,
I have just uploaded my new package cpuid to Hackage.
Description:
This module provides the function 'cpuid' for accessing information about the
currently running
IA-32 processor. Both a function for calling the 'cpuid' instruction directly,
and some convenience
Thanks,
I found on one site how to compile after creating the stub files with GHC:
First step:
*ghc -c -ffi haskell_file.hs*
Second step - here it is important to know and write where are the ghc
libraries:
*gcc -I /usr/local/lib/ghc-5.04.3/include -c C_file.c *
After that it is important to
Hello Miguel,
Friday, April 18, 2008, 7:06:07 PM, you wrote:
you may look into my freearc.org project
overall, nothing complex as far as you got it :) i use
ghc -c c_file.cpp
ghc --make main.hs c_file.o
in order to call from C++ to Haskell or vice versa you should define
function in C++ as
In message [EMAIL PROTECTED] John Goerzen
[EMAIL PROTECTED] writes:
On Fri April 18 2008 4:43:24 am Duncan Coutts wrote:
It seems arbitrary that Hackage would suddenly reject this valid
usage.
Yes it is valid though I hope you can see the general intention of the
suggestion. If it
if you'd normally be linking using g++, you'll need (IIRC) -lstdc++
added to linking-ghc's command line
Alfonso Acosta wrote:
Although you could use gcc to link the code I wouldn't recommend it
(mainly for the problems you are currently having)
SImply call GHC to compile both the C and
In message [EMAIL PROTECTED] haskell-cafe@haskell.org
writes:
On Fri, Apr 18, 2008 at 10:43:24AM +0100, Duncan Coutts wrote:
I have now fixed that by eliminating the use of Read in the .cabal
parser and basically adding an Other/Unknown constructor to several of
the enumeration types,
I'm pleased to announce the existence (not release, properly) of
franchise, a new configuration/build system for Haskell programs and
packages.
Franchise
=
Franchise is a configuration and build system for Haskell projects. The
configure system employed in franchise is designed to be
After some thinking I think I can put my question much simpler:
If I have a class with some dependencies, say
a - ..., b c - ...
Is it possible to encode this using associated types without having all of a, b
and c as class parameters?
It seems to me that it's not possible. And if so,
Hello Isaac,
Friday, April 18, 2008, 7:27:56 PM, you wrote:
absolutely true! it's required if you use new/delete and other things
supported by c++ RTS
if you'd normally be linking using g++, you'll need (IIRC) -lstdc++
added to linking-ghc's command line
Alfonso Acosta wrote:
Although you
Hello,
On Thu, Apr 17, 2008 at 12:05 PM, Martin Sulzmann
[EMAIL PROTECTED] wrote:
Can you pl specify the improvement rules for your interpretation of FDs.
That would help!
Each functional dependency on a class adds one extra axiom to the
system (aka CHR rule, improvement rule). For the
I've never thought of one being shorthand for the other, really.
Since they are logically equivalent (in my interpretation) I don't really
care which one we regard as more primitive.
On Fri, Apr 18, 2008 at 9:26 AM, Martin Sulzmann [EMAIL PROTECTED]
wrote:
Lennart Augustsson wrote:
To reuse
In message [EMAIL PROTECTED] haskell-cafe@haskell.org,
[EMAIL PROTECTED] writes:
One goal of franchise is to not require developers to provide redundant
information. For instance, you've already listed all the modules you use,
and ghc already knows which modules are present in which packages,
Thanks Iavor! Things become now clear.
Let's consider our running example
class D a b | a - b
instance D a b = D [a] [b]
which we can write in CHR notation
D a b, D a c == b=c(FD)
D [a] [b] = D a b (Inst)
These rules overlap.
Let's consider the critical pair
D [a] [b], D [a] c
Lennart Augustsson wrote:
I've never thought of one being shorthand for the other, really.
Since they are logically equivalent (in my interpretation) I don't
really care which one we regard as more primitive.
True. See my response to Iavor's recent email.
Martin
I've just uploaded version 0.4 of cabal-rpm to Hackage. This is a
program that generates an RPM package from a Cabal package. RPM is the
package format used by several major Linux distributions.
New in this version are support for GHC 6.8.2 and the Cabal 1.2 release
series.
Download:
jsnow:
A new version of my raytracer is out. It now supports cones, cylinders,
disks, boxes, and planes as base primitives (previously it only
supported triangles and spheres), as well as transformations of
arbitrary objects (rotate, scale, translate) and the CSG operations
difference
To threadjack a little bit, I've been interfacing haskell with c++.
It gets awkward when the c++ structures use STL types like string and
vector. Of course those are too complex for haskell to marshal to.
What I've been doing is defining an XMarshal variant of the X c++
class, that uses plain c
On Fri, Apr 18, 2008 at 7:43 PM, Don Stewart [EMAIL PROTECTED] wrote:
jsnow:
A new version of my raytracer is out. It now supports cones, cylinders,
disks, boxes, and planes as base primitives (previously it only
supported triangles and spheres), as well as transformations of
arbitrary
Matthew Brecknell wrote:
Dan Weston wrote:
Here, any path means all paths, a logical conjunction:
and [True, True] = True
and [True ] = True
and [ ] = True
Kim-Ee Yeoh wrote:
Hate to nitpick, but what appears to be some kind of a
limit in the opposite direction is a curious
BTW, here's a non-contrived example. It's pretty easy to come up with
examples when you try to use type classes instead of a proper module system.
Here we have expressions parametrized over how identifiers and literals are
represented. First a simple instance, and then one where all the types
qdunkan:
To threadjack a little bit, I've been interfacing haskell with c++.
It gets awkward when the c++ structures use STL types like string and
vector. Of course those are too complex for haskell to marshal to.
What I've been doing is defining an XMarshal variant of the X c++
class,
Don Stewart wrote:
jsnow:
A new version of my raytracer is out. ...
Very impressive. Did you consider cabalising the Haskell code, so it
can be easily distributed from hackage.haskell.org?
I note on the website you say:
no threading (shared-memory concurrency is not supported
Hello Jim,
Saturday, April 19, 2008, 12:10:23 AM, you wrote:
The other problem I had with concurrency is that I was getting about a
50% speedup instead of the 99% or so that I'd expect on two cores. I
2 cores doesn't guarantee 2x speedup. some programs are limited by
memory access speed and
Thanks for the snippet.
Sorry, but my question was somehow mis-formulated. I was looking for
a client-side implementation
how to upload a file to any server using Haskell (mainly using the
Browser module from HTTP package).
Going through the Browser.hs source code a little, I and came up with
On Sat, Apr 19, 2008 at 12:19:19AM +0400, Bulat Ziganshin wrote:
Saturday, April 19, 2008, 12:10:23 AM, you wrote:
The other problem I had with concurrency is that I was getting about a
50% speedup instead of the 99% or so that I'd expect on two cores. I
2 cores doesn't guarantee 2x
David Roundy wrote:
On Sat, Apr 19, 2008 at 12:19:19AM +0400, Bulat Ziganshin wrote:
Saturday, April 19, 2008, 12:10:23 AM, you wrote:
The other problem I had with concurrency is that I was getting about a
50% speedup instead of the 99% or so that I'd expect on two cores. I
2
On Fri, Apr 18, 2008 at 9:10 PM, Jim Snow [EMAIL PROTECTED] wrote:
The scene is shared between threads. (Complex scenes can be quite large.)
I'm assuming this is handled as a read-only shared memory region or
something similar, as one might expect, and is not actually copied.
Ah, when
First, apologies for not responding earlier. I spent my week at a
conference in Austria. Second, thanks for all the feedback!
I thought I go through some of my thoughts on the issues raised. Just
to try to reiterate the goals of this effort:
* To provide a common, no frills interface between
On Fri, Apr 18, 2008 at 02:09:28PM -0700, Jim Snow wrote:
On a particular scene with one instance of the single-threaded renderer
running, it takes about 19 seconds to render an image. With two
instances running, they each take about 23 seconds. This is on an
Athlon-64 3800+ dual core, with
Jim Snow wrote:
The concurrency bug has to do with excessive memory use, and was
discussed earlier here on the mailing list (search for Glome).
http://hackage.haskell.org/trac/ghc/ticket/2185
Interesting. I looked at your test case. I can reproduce your problem
when I build with the
David Roundy wrote:
On Fri, Apr 18, 2008 at 02:09:28PM -0700, Jim Snow wrote:
On a particular scene with one instance of the single-threaded renderer
running, it takes about 19 seconds to render an image. With two
instances running, they each take about 23 seconds. This is on an
Athlon-64
jsnow:
David Roundy wrote:
On Fri, Apr 18, 2008 at 02:09:28PM -0700, Jim Snow wrote:
On a particular scene with one instance of the single-threaded renderer
running, it takes about 19 seconds to render an image. With two
instances running, they each take about 23 seconds. This is on an
WARNING: RANT AHEAD. Hopefully this fires off some productive
discussion on how to fix these problems!
Don't get me wrong: I think the idea of typeclasses is great. Their
implementation in Haskell comes so close to being awesome and then
falls short, and that's almost worse than not being
On 18 Apr 2008, at 9:29 PM, Ryan Ingram wrote:
WARNING: RANT AHEAD.
WARNING: RESPONSE IN THE SPIRIT OF THE ORIGINAL AHEAD.
Hopefully this fires off some productive
discussion on how to fix these problems!
{-# GHC_OPTIONS -foverlapping-instances -fundecidable-instances #-} :)
What you
47 matches
Mail list logo
