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 wan
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 aweso
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. T
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 3
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 threa
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, wi
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 w
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
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 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 2
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
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 an
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
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
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 ar
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
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
> >
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 a
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
> differenc
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:
http://ha
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
__
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]
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 packa
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 r
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 ex
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
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, I'
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 eas
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 type
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 Haskell
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
> > sugge
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 hav
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 link
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
functi
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
BTW
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:
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
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 t
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 m
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 Ca
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 i
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 th
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 thi
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 ot
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 th
> 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 i
46 matches
Mail list logo
