Thanks to everyone, especially Bulat Ziganshin.
In http://haskell.org/haskellwiki/Modern_array_libraries there is enough
information to do what I want. It specifically mentions that it's OK to
pass ByteArray# and MutableByteArray# to an unsafe foreign procedure as
long as that procedure doesn't
On Mon, Aug 20, 2007 at 11:03:45PM -0700, Ryan Ingram wrote:
Thanks to everyone, especially Bulat Ziganshin.
In http://haskell.org/haskellwiki/Modern_array_libraries there is enough
information to do what I want. It specifically mentions that it's OK to
pass ByteArray# and
On 8/11/07, Neil Bartlett [EMAIL PROTECTED] wrote:
You're absolutely right that a dynamic/adaptive approach is the only
one that will work when the tasks are of unknown size. Whether this
approach is as easy as you think is open for you to prove. I look
forward to testing your VM
On 8/21/07, Hugh Perkins [EMAIL PROTECTED] wrote:
On 8/11/07, Neil Bartlett [EMAIL PROTECTED] wrote:
You're absolutely right that a dynamic/adaptive approach is the only
one that will work when the tasks are of unknown size. Whether this
approach is as easy as you think is open for you to
ryani.spam:
Your code is broken in a most evil and insidious way.
Interesting. This is for a toy project, so I'm not too
worried, but lets say I wanted to do this correctly and I
was set on using IOUArray for some reason. (The Haskell wiki
claims that StorableArray is
On Mon, Aug 20, 2007 at 11:47:06PM -0700, Ryan Ingram wrote:
Your code is broken in a most evil and insidious way.
Interesting. This is for a toy project, so I'm not too worried, but lets
say I wanted to do this correctly and I was set on using IOUArray for some
reason.
Heh, I'm a lot
Hello Stefan,
Tuesday, August 21, 2007, 10:08:59 AM, you wrote:
Your code is broken in a most evil and insidious way.
and this code, too? :)
freezeSTUArray :: Ix i = STUArray s i e - ST s (UArray i e)
freezeSTUArray (STUArray l u marr#) = ST $ \s1# -
case sizeofMutableByteArray# marr# of
Ah, sneaky. That code is fine because it uses unsafeCoerce# on memcpy,
changing memcpy from whatever type it is, into
MutableByteArray# s# - MutableByteArray# s# - Int# - s# - (# s#, () #)
So as long as the GC understands MutableByteArray# it's safe; it's relying
on the C calling convention
G'day all.
Quoting David Ritchie MacIver [EMAIL PROTECTED]:
I was playing with some code for compiling regular expressions to
finite state machines and I ran into the following problem. I've solved
it, but I'm not terribly happy with my solution and was wondering if
someone could come up with
On Tue, Aug 21, 2007 at 12:50:22AM -0700, Ryan Ingram wrote:
Ah, sneaky. That code is fine because it uses unsafeCoerce# on memcpy,
changing memcpy from whatever type it is, into
MutableByteArray# s# - MutableByteArray# s# - Int# - s# - (# s#, () #)
So as long as the GC understands
Hello Ryan,
Tuesday, August 21, 2007, 10:47:06 AM, you wrote:
Your code is broken in a most evil and insidious way.
Interesting. This is for a toy project, so I'm not too worried,
but lets say I wanted to do this correctly and I was set on using
IOUArray for some reason. (The Haskell
I wrote:
Just for information, the HaXml darcs repo has recently adopted the
solution of containing two .cabal files, one for ghc-6.6.x, and the
other for the split-base packages (=ghc-6.7).
Thomas Hartman [EMAIL PROTECTED] wrote:
$ runghc Setup.hs configure
Setup.hs: Multiple description
On Mon, Aug 20, 2007 at 09:57:38PM +0100, Simon Peyton-Jones wrote:
GHC does some constant folding, but little by way of strength
reduction, or using shifts instead of multiplication. It's pretty
easy to add more: it's all done in a single module. Look at
primOpRules in the module PrelRules.
phil:
On Mon, Aug 20, 2007 at 09:57:38PM +0100, Simon Peyton-Jones wrote:
GHC does some constant folding, but little by way of strength
reduction, or using shifts instead of multiplication. It's pretty
easy to add more: it's all done in a single module. Look at
primOpRules in the module
On my system, the C version runs about 9x faster than the haskell
version (with -O3 and -O2 -fvia-c -optc-O3 respectively). However, GCC
seems to produce about 70 lines of assembly for the main loop,
compared to about 10 from GHC. I suspect the speed difference is the
result of some heavy
David Ritchie MacIver wrote:
I was playing with some code for compiling regular expressions to finite
state machines and I ran into the following problem. I've solved it, but
I'm not terribly happy with my solution and was wondering if someone
could come up with a better one. :-)
On Tue, Aug 21, 2007 at 01:14:20PM +0100, Rodrigo Queiro wrote:
On my system, the C version runs about 9x faster than the haskell
version (with -O3 and -O2 -fvia-c -optc-O3 respectively). However, GCC
seems to produce about 70 lines of assembly for the main loop,
compared to about 10 from GHC.
On 8/21/07, Tim Chevalier [EMAIL PROTECTED] wrote:
I don't think you have to worry too much about the political
obstacles. People want automatic multithreading, and in a year or two
we'll all have multicore boxen. In any case, if you don't solve the
technical problems, the political ones will
Exactly. For this to work there needs to be the constraint that there's a
one-to-one mapping in each direction. The Bimap should have the uniqueness
promise that Set (k, v) gives. Yet you should be able to search on either
tuple value.
Or... have the possibility of returning a list of values.
On Tue, Aug 21, 2007 at 05:25:49AM -0700, Stefan O'Rear wrote:
On Tue, Aug 21, 2007 at 01:14:20PM +0100, Rodrigo Queiro wrote:
On my system, the C version runs about 9x faster than the haskell
version (with -O3 and -O2 -fvia-c -optc-O3 respectively). However, GCC
seems to produce about 70 lines
Levi Stephen wrote:
Al Falloon wrote:
This code seems to indicate that you want to be able to extend the
widget types without changing this source file. This is a good goal,
but it may not be worth the extra complexity.
Ideally, I'd like Widgets to be added through hs-plugins or similar.
Don's reply didn't reach me for some reason, but pulling it out of the
previous response:
On 21/08/07, Donald Bruce Stewart [EMAIL PROTECTED] wrote:
phil:
The generated assembler suggests (if I've read it correctly) that gcc
is spotting that it can replace the tail call with a jump in the C
On 8/21/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Currently, it's never worse. GHC's backend is about as good as GCC;
most of the optimiations it doesn't do are not possible for GCC because
of various lack-of-information problems (the stack pointer never aliases
the heap pointer, stuff like
Hi
Wait, you're saying that ghc can produce pure c-code, that doesnt
contain any assembly code, and that runs as fast as ghc code that does
contain assembly?
No. It can produce pure C code (unregistered), but to get high
performance it processes the output assembly afterwards (registered).
On Tue, Aug 21, 2007 at 09:39:32PM +0800, Hugh Perkins wrote:
On 8/21/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Currently, it's never worse. GHC's backend is about as good as GCC;
most of the optimiations it doesn't do are not possible for GCC because
of various lack-of-information
Hugh Perkins wrote:
Exactly. For this to work there needs to be the constraint that there's a
one-to-one mapping in each direction. The Bimap should have the uniqueness
promise that Set (k, v) gives. Yet you should be able to search on either
tuple value.
Or... have the possibility of
Hi All,
I'd like to announce the formation of the Bay Area Functional
Programmers group. This group is for anyone using or interested in
functional programming and functional programming languages,
particularly strongly typed languages such as Haskell, OCaml, SML,
etc.
The first meeting will be
Consider the following example code:
data Vector = V Float Float
data Matrix = M Vector Vector
liftV1 f (V x y) = V (f x) (f y)
liftV2 f (V x1 y1) (V x2 y2) = V (f x1 x2) (f y1 y2)
liftM1 f (M x y) = M (f x) (f y)
liftM2 f (M x1 y1) (M x2 y2) = M (f
Hi Peter,
liftV1 f (V x y) = V (f x) (f y)
liftV2 f (V x1 y1) (V x2 y2) = V (f x1 x2) (f y1 y2)
liftM1 f (M x y) = M (f x) (f y)
liftM2 f (M x1 y1) (M x2 y2) = M (f x1 x2) (f y1 y2)
Both pairs of lift functions have almost identical implementations. Can I
On Tue, 21 Aug 2007, Peter Verswyvelen wrote:
Consider the following example code:
data Vector = V Float Float
data Matrix = M Vector Vector
liftV1 f (V x y) = V (f x) (f y)
liftV2 f (V x1 y1) (V x2 y2) = V (f x1 x2) (f y1 y2)
liftM1 f (M x y) = M (f x) (f
Does a general approach exist to convert any non-constant (Num a) to a
Float? Not using type annotation of course.
Now I wrote a Convert class that has a toFloat function which I instantiate
for all different numeric types, but as all these toFloat/toInt functions
disappeared a long time ago from
How can you hope to convert an arbitrary Num to a Float?
Num contains things like complex numbers that don't have any reasonable
translation to a Float.
But anyway, realToFrac is a good conversion function.
-- Lennart
On 8/21/07, Peter Verswyvelen [EMAIL PROTECTED] wrote:
Does a general
Stefan O'Rear wrote:
sum = sum' 0
sum' k [] = k
sum' k (x:xs) = (sum' $! (k+x)) xs
enum x y | x = y= 0
| otherwise = x : enum (x+1) y
sum (enum 1 10) =
sum' 0 (enum 1 10) =
sum' 0 (1 : enum (1+1) 10) =
(sum' $! (0+1)) (enum (1+1) 10) =
sum' 1
Simon Peyton-Jones wrote:
GHC does some constant folding, but little by way of strength reduction, or
using shifts instead of multiplication. It's pretty easy to add more: it's all
done in a single module. Look at primOpRules in the module PrelRules.
Patches welcome! But please also supply
Donald Bruce Stewart wrote:
This puts the channel at around the 13th largest community of the 5500
freenode channels. For comparision, a sample of the state of the other
language communities:
#php 485
#perl472
##c++457
##c 445
#python
Tim Chevalier wrote:
Anyone can submit a paper to a CS journal or conference. While most
people who do so are affiliated with universities, research labs, or
(more rarely) non-research companies, there are independent
researchers out there, and sometimes you'll notice a paper where
someone is
| GHC does some constant folding, but little by way of strength
| reduction, or using shifts instead of multiplication. It's pretty easy
| to add more: it's all done in a single module. Look at primOpRules in
| the module PrelRules.
|
| Patches welcome! But please also supply test-suite
Stefan O'Rear wrote:
sum (enum 1 10) =
sum' 0 (enum 1 10) =
...
sum' 36 (9 : enum (9+1) 10) =
(sum' $! (36+9)) (enum (9+1) 10) =
sum' 45 (enum (9+1) 10) =
sum' 45 [] =
45
(I need to find some way to automate making these trails
On Tue, 21 Aug 2007 18:53:43 +0200, Peter Verswyvelen [EMAIL PROTECTED]
wrote:
Does a general approach exist to convert any non-constant (Num a) to a
Float? Not using type annotation of course.
Instances of class Integral (Int and Integer) can be converted with
fromIntegral.
--
Met
Yes indeed, I realized that. I oversimplified my question. I'm basically
trying to model 4D CG/HLSL operations (pixel/vertex shaders) in Haskell.
I tried realToFrac, but that did not work. Then I tried splitting the
instances into Fractional and Integral, but I kept getting errors. Maybe
because
Hi
sum (enum 1 10) =
sum' 0 (enum 1 10) =
...
sum' 36 (9 : enum (9+1) 10) =
(sum' $! (36+9)) (enum (9+1) 10) =
sum' 45 (enum (9+1) 10) =
sum' 45 [] =
45
(I need to find some way to automate making these trails
Neil Mitchell wrote:
Hi
(I need to find some way to automate making these trails :) )
Yes! We'd need such an automatic tool for the wikibook, too.
The problem is that Haskell is ridiculously complex, and the small
step interpretation is much harder than you'd think. For
apfelmus wrote:
Hugh Perkins wrote:
Arguably there are two possible implementations, one that enforces
one-to-one mapping, and one which allows multiple values, in either
direction.
Terminology reminder :)
- the latter is called (binary) relation
http://en.wikipedia.org/wiki/Binary_relation
Andrew Coppin wrote:
...does this mean Haskell is officially harder to understand than Lisp,
Java, Perl and O'Caml? :-}
(OTOH, does this mean Haskell is easier to understand than PHP or C++?)
Or, Haskell is the easiest to understand of them all.
Reason: Extremely large channel means so hard
Simon Peyton-Jones wrote:
| GHC does some constant folding, but little by way of strength
| reduction, or using shifts instead of multiplication. It's pretty easy
| to add more: it's all done in a single module. Look at primOpRules in
| the module PrelRules.
|
| Patches welcome! But please
If I wanted to develop the widgets themselves separately from the
layout, I would probably do something like this:
class Widget a where
render :: a - Html
bbox :: a - Size
type Layout = forall a. Widget a = Widget a
| Rows Spacing [Layout]
| Columns Spacing [Layout]
|
On Sun, 19 Aug 2007, Peter Cai wrote:
My duty is writing a network server which talks to another server through a
binary based private protocol.
Haskell needs something like Erlang's bit syntax.
http://erlang.org/doc/reference_manual/expressions.html#6.16
dot:
On Sun, 19 Aug 2007, Peter Cai wrote:
My duty is writing a network server which talks to another server through a
binary based private protocol.
Haskell needs something like Erlang's bit syntax.
http://erlang.org/doc/reference_manual/expressions.html#6.16
Isaac Dupree wrote:
Simon Peyton-Jones wrote:
...
No, constant folding is part of the compiler, I'm afraid, in the
module PrelRules.
Simon
_Constant_ folding is, but in GHC.Base there are rules like (unboxed)
multiplying by zero or one, or adding or subtracting zero, from an
unknown
On Aug 21, 2007, at 22:13 , Twan van Laarhoven wrote:
Other rules that could be interesting are:
forall a b. fromInteger a + fromInteger b = fromInteger (a + b)
I don't think this will work, a and b have to be the same type.
--
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] [EMAIL
Brandon S. Allbery KF8NH wrote:
On Aug 21, 2007, at 22:13 , Twan van Laarhoven wrote:
Other rules that could be interesting are:
forall a b. fromInteger a + fromInteger b = fromInteger (a + b)
I don't think this will work, a and b have to be the same type.
They are of the same type,
On 8/21/07, Andrew Coppin [EMAIL PROTECTED] wrote:
I highly doubt that automatic threading will happen any time this decade
- but I just learned something worth while from reading this email. ;-)
That's an interesting observation. I cant say I dont believe it, but
I'm interested to know why
Thank-you for the information. It was very useful. Couple of reactions FWIW:
On 8/21/07, Stefan O'Rear [EMAIL PROTECTED] wrote:
Sooo if I was feeling evil, could I take this c-code and pipe it
into something that turns it into C#???
Yes. You could do the same with the original
On Aug 21, 2007, at 23:27 , Hugh Perkins wrote:
Hmmm, that's interesting. I'd never considered lack of typing to be a
good thing for system robustness before!
The old watchphrase (before Netscape and Microsoft abused it beyond
anyone's expectation) for Internet protocols was be liberal in
54 matches
Mail list logo
