[Haskell-cafe] MVar which can not be null ?

[s9gf4ult]

Hello, I am looking for MVar which can not be null. I need some kind of
thread save atomic IO operation like I can do 
with modifyMVar, but I want this variable always contain some value and
never be null.
Thanks.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] MVar which can not be null ?

[Roman Cheplyaka]

* s9gf4ult  [2013-03-18 13:07:04+0600]
> Hello, I am looking for MVar which can not be null. I need some kind of
> thread save atomic IO operation like I can do 
> with modifyMVar, but I want this variable always contain some value and
> never be null.
> Thanks.

Wrap it into a newtype and export only those operations that keep it
non-empty.

Roman

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] MVar which can not be null ?

[Alexander V Vershilov]

If you have only one variable then you can use:
atomicModifyIORef  from IORef it will give you atomic transactions and
IORef will always contains some value.
If you have a list of variables you need to make atomic actions on, then
you may like to use STM.

On 18 March 2013 11:07, s9gf4ult  wrote:
> Hello, I am looking for MVar which can not be null. I need some kind of
> thread save atomic IO operation like I can do
> with modifyMVar, but I want this variable always contain some value and
> never be null.
> Thanks.
>

-- 
Alexander

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] MVar which can not be null ?

[s9gf4ult]

18.03.2013 13:26, Alexander V Vershilov ?:

I can not use atomicModifyIORef because it works with pure computation

atomicModifyIORef :: IORef

a -> (a -> (a, b)) -> IO

b

nor STM, becuase IO is not acceptable inside STM transaction.

I just need some thread-safe blocking variable like MVar

modifyMVar :: MVar

a -> (a -> IO

(a, b)) -> IO

b
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] MVar which can not be null ?

[Edward Z. Yang]

If you are doing IO operations, then the operation is hardly atomic, is it?

Just take from the MVar, compute, and when you're done, put a value
back on the MVar.  So long as you can guarantee all users of the MVar
take before putting, you will have the desired semantics.

Something worth considering: what are the desired semantics if an
asynchronous exception is thrown on the thread servicing the MVar?
If the answer is to just quit, what if it has already performed
externally visible IO actions?  If the answer is to ignore it, what
if the thread gets wedged?

Edward

Excerpts from s9gf4ult's message of Mon Mar 18 01:07:42 -0700 2013:
> 18.03.2013 13:26, Alexander V Vershilov ?:
> 
> I can not use atomicModifyIORef because it works with pure computation
> 
> atomicModifyIORef :: IORef
> 
> a -> (a -> (a, b)) -> IO
> 
> b
> 
> nor STM, becuase IO is not acceptable inside STM transaction.
> 
> I just need some thread-safe blocking variable like MVar
> 
> modifyMVar :: MVar
> 
> a -> (a -> IO
> 
> (a, b)) -> IO
> 
> b

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Optimization flag changing result of code execution

[Aleksey Khudyakov]

On 17 March 2013 21:49, Dominic Steinitz  wrote:
> Aleksey Khudyakov  gmail.com> writes:
>
>> I've tried to run you program and I've got approximately same results
>> regardless of optimization level. Which versions of GHC, mwc-random,
>> vector and primitive do you use?
>>
>
> By approximate do you mean you are getting Monte Carlo noise
> or Floating Point noise? If the latter then that's reasonable;
> if the former then that's worrying.
>
Difficult to say. I got values around 10 with and without optimizations. Most
likely it's MC noise

I was using GHC-7.6.2 and latest vector/primitive/mwc-random. I didn't tried
to reproduce bug with versions which Azeem Ul Hasan use.

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Streaming bytes and performance

[Konstantin Litvinenko]

Hi All!

I tune my toy project for performance and hit the wall on simple, in 
imperative world, task. Here is the code that model what I'm trying to 
achieve


import qualified Data.ByteString.Lazy as L
import Data.Word8(isSpace)
import Data.Word
import Control.Monad.State

type Stream = State L.ByteString

get_byte :: Stream (Maybe Word8)
get_byte = do
s <- get
case L.uncons s of
Nothing -> return Nothing
Just (x, xs) -> put xs >> return (Just x)

main = do
f <- L.readFile "test.txt"
let r = evalState count_spaces f
print r
  where
count_spaces = go 0
  where
go a = do
x <- get_byte
case x of
Just x' ->  if isSpace x' then go (a + 1) else go a
Nothing -> return a

It takes the file and count spaces, in imperative way, consuming bytes 
one by one. The problem is: How to rewrite this to get rid of constant 
allocation of state but still working with stream of bytes? I can 
rewrite this as one-liner L.foldl, but that doesn't help me in any way 
to optimize my toy project where all algorithms build upon consuming 
stream of bytes.


PS. My main lang is C++ over 10 years and I only learn Haskell :)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] MVar which can not be null ?

[Tim Docker]

On 18/03/13 19:07, s9gf4ult wrote:


nor STM, becuase IO is not acceptable inside STM transaction.

I just need some thread-safe blocking variable like MVar

modifyMVar :: MVar 
 
a -> (a -> IO 
 
(a, b)) -> IO 
 
b




Whilst it's true that IO cannot be performed within an STM action, a 
common pattern is to return the necessary IO action from the STM action, 
and then run it once the STM transaction has completed successfully.


Tim
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] haskell infrastruture poll

[Alexander V Vershilov]

Ladies and gentlemen!

If you happen to be involved in using/developing haskell-powered
software you might like to answer our poll on that matter [1].

Thanks in advance!

[1] 
https://docs.google.com/forms/d/1y5WtrCB7O9-jb-2Mzo1MtkToh4O6oY2oBXGkc_Q-cy0/viewform

-- 
Alexander

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Some aggregation of Haskell content

[Christopher Done]

As a follow up, here's an implementation: http://haskellnews.org/

More info here:
http://www.reddit.com/r/haskell/comments/1ahgrn/haskell_news/c8xfp9s

On 10 February 2013 18:22, Daniel Díaz Casanueva  wrote:
> I'm totally with this. Also, it is exhausting to check in so many places to
> see what's going on. I have been looking for this for a while.
>
>
> On Sun, Feb 10, 2013 at 10:41 AM, Christopher Done 
> wrote:
>>
>> Is there a page somewhere that aggregates all of Haskell's community
>> output into one place?
>>
>> As a consumer of Haskell content I neither have the time nor inclination
>> to follow haskell-cafe and other various mailing lists, the reddits, the
>> google+ community, planet haskell, hackage releases, twitter, youtube and
>> whatever other submission places I haven't heard of.
>>
>> I made this page for the Lojban community some years ago:
>> http://jbotcan.org/hub/
>>
>> Lojban doesn't have much community activity (tho this doesn't include
>> mailing list posts), but Haskell's community is much larger and more active,
>> it would be far more useful.
>>
>> I may write such a page for Haskell content, if not for the community then
>> at least for myself, as I keep missing out on cool things because I didn't
>> happen to check out that particular medium of exchange. For example, even
>> this message will be lost on a thousand people who doesn't follow the
>> mailing list but maybe follows G+ or reddit.
>>
>> Kind of like a Haskell Weekly news, except more like "Haskell news right
>> now or in some adjustable time frame." And the option to toggle between
>> chronological order or categorized.
>>
>> Ciao!
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>
>
>
> --
> E-mail sent by Daniel Díaz Casanueva
>
> let f x = x in x

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Some aggregation of Haskell content

[José Pedro Magalhães]

On Mon, Mar 18, 2013 at 9:56 AM, Christopher Done wrote:

> As a follow up, here's an implementation: http://haskellnews.org/
>

Could it have an RSS feed?


Thanks,
Pedro


>
> More info here:
> http://www.reddit.com/r/haskell/comments/1ahgrn/haskell_news/c8xfp9s
>
> On 10 February 2013 18:22, Daniel Díaz Casanueva 
> wrote:
> > I'm totally with this. Also, it is exhausting to check in so many places
> to
> > see what's going on. I have been looking for this for a while.
> >
> >
> > On Sun, Feb 10, 2013 at 10:41 AM, Christopher Done 
> > wrote:
> >>
> >> Is there a page somewhere that aggregates all of Haskell's community
> >> output into one place?
> >>
> >> As a consumer of Haskell content I neither have the time nor inclination
> >> to follow haskell-cafe and other various mailing lists, the reddits, the
> >> google+ community, planet haskell, hackage releases, twitter, youtube
> and
> >> whatever other submission places I haven't heard of.
> >>
> >> I made this page for the Lojban community some years ago:
> >> http://jbotcan.org/hub/
> >>
> >> Lojban doesn't have much community activity (tho this doesn't include
> >> mailing list posts), but Haskell's community is much larger and more
> active,
> >> it would be far more useful.
> >>
> >> I may write such a page for Haskell content, if not for the community
> then
> >> at least for myself, as I keep missing out on cool things because I
> didn't
> >> happen to check out that particular medium of exchange. For example,
> even
> >> this message will be lost on a thousand people who doesn't follow the
> >> mailing list but maybe follows G+ or reddit.
> >>
> >> Kind of like a Haskell Weekly news, except more like "Haskell news right
> >> now or in some adjustable time frame." And the option to toggle between
> >> chronological order or categorized.
> >>
> >> Ciao!
> >>
> >> ___
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe@haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >>
> >
> >
> >
> > --
> > E-mail sent by Daniel Díaz Casanueva
> >
> > let f x = x in x
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Need some advice around lazy IO

[Konstantin Litvinenko]

On 03/17/2013 07:08 AM, C K Kashyap wrote:

I am working on an automation that periodically fetches bug data from
our bug tracking system and creates static HTML reports. Things worked
fine when the bugs were in the order of 200 or so. Now I am trying to
run it against 3000 bugs and suddenly I see things like - too  many open
handles, out of memory etc ...

Here's the code snippet - http://hpaste.org/84197

It's a small snippet and I've put in the comments stating how I run into
"out of file handles" or simply file not getting read due to lazy IO.

I realize that putting ($!) using a trial/error approach is going to be
futile. I'd appreciate some pointers into the tools I could use to get
some idea of which expressions are building up huge thunks.


You problem is in

let bug = ($!) fileContents2Bug str

($!) evaluate only WHNF and you need NF. Above just evaluate to first 
char in a file, not to all content. To fully evaluate 'str' you need 
something like


let bug = Control.DeepSeq.rnf str `seq` fileContents2Bug str





___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Need some advice around lazy IO

[Ivan Lazar Miljenovic]

On 18 March 2013 21:01, Konstantin Litvinenko  wrote:
> On 03/17/2013 07:08 AM, C K Kashyap wrote:
>>
>> I am working on an automation that periodically fetches bug data from
>> our bug tracking system and creates static HTML reports. Things worked
>> fine when the bugs were in the order of 200 or so. Now I am trying to
>> run it against 3000 bugs and suddenly I see things like - too  many open
>> handles, out of memory etc ...
>>
>> Here's the code snippet - http://hpaste.org/84197
>>
>> It's a small snippet and I've put in the comments stating how I run into
>> "out of file handles" or simply file not getting read due to lazy IO.
>>
>> I realize that putting ($!) using a trial/error approach is going to be
>> futile. I'd appreciate some pointers into the tools I could use to get
>> some idea of which expressions are building up huge thunks.
>
>
> You problem is in
>
> let bug = ($!) fileContents2Bug str
>
> ($!) evaluate only WHNF and you need NF. Above just evaluate to first char
> in a file, not to all content. To fully evaluate 'str' you need something
> like
>
> let bug = Control.DeepSeq.rnf str `seq` fileContents2Bug str

Or use $!! from Control.DeepSeq.

>
>
>
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe



-- 
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Need some advice around lazy IO

[C K Kashyap]

Thanks Konstantin ... I'll try that out too...



Regards,
Kashyap


On Mon, Mar 18, 2013 at 3:31 PM, Konstantin Litvinenko <
to.darkan...@gmail.com> wrote:

> On 03/17/2013 07:08 AM, C K Kashyap wrote:
>
>> I am working on an automation that periodically fetches bug data from
>> our bug tracking system and creates static HTML reports. Things worked
>> fine when the bugs were in the order of 200 or so. Now I am trying to
>> run it against 3000 bugs and suddenly I see things like - too  many open
>> handles, out of memory etc ...
>>
>> Here's the code snippet - http://hpaste.org/84197
>>
>> It's a small snippet and I've put in the comments stating how I run into
>> "out of file handles" or simply file not getting read due to lazy IO.
>>
>> I realize that putting ($!) using a trial/error approach is going to be
>> futile. I'd appreciate some pointers into the tools I could use to get
>> some idea of which expressions are building up huge thunks.
>>
>
> You problem is in
>
> let bug = ($!) fileContents2Bug str
>
> ($!) evaluate only WHNF and you need NF. Above just evaluate to first char
> in a file, not to all content. To fully evaluate 'str' you need something
> like
>
> let bug = Control.DeepSeq.rnf str `seq` fileContents2Bug str
>
>
>
>
>
>
> __**_
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] How to use the nice test output spit out by test-framework with "cabal test"?

[Alfredo Di Napoli]

Hi guys,

I've been wondering for a long time about how to use the nice terminal-base
report spit out from test-framework when I type "cabal test".
Atm this is my run-of-the-mill cabal setting:

test-suite test-all
  type: exitcode-stdio-1.0
  main-is: Main.hs
  ghc-options: -w -threaded -rtsopts -with-rtsopts=-N
  hs-source-dirs: tests
[...]

but this runs tests using the default cabal interface:

Linking dist/build/test-all/test-all ...
Running 1 test suites...
Test suite test-all: RUNNING...
Test suite test-all: PASS
Test suite logged to: dist/test/opencv-simple-0.1.0.0-test-all.log
1 of 1 test suites (1 of 1 test cases) passed.

This is, instead, what I wanted when I type "cabal test" and "cabal install
--enable-tests":

http://batterseapower.github.com/test-framework/images/example.png

is it possible?

Thanks in advance,

A.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] How to use the nice test output spit out by test-framework with "cabal test"?

[Jan Stolarek]

> is it possible?
The output you are looking for is in the log file: 
dist/test/opencv-simple-0.1.0.0-test-all.log
It gets displayed only if something goes wrong (i.e. a test fails). If all 
tests pass it's logged 
to the file. I hope this helps.

Janek

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Streaming bytes and performance

[Gregory Collins]

Put a bang pattern on your accumulator in "go". Since the value is not
demanded until the end of the program, you're actually just building up a
huge space leak there.

Secondly, unconsing from the lazy bytestring will cause a lot of allocation
churn in the garbage collector -- each byte read in the input forces the
creation of a new "L.ByteString", which is many times larger.

Also please consider trying the "io-streams" library that I wrote (
http://hackage.haskell.org/package/io-streams). It provides primitives for
streaming IO in "basic Haskell" style. To provide a Word8 stream (which is
probably a bad idea performance-wise) it would be most efficient
allocation-wise to implement a mutable index cursor (i.e. IORef Int) that
pointed to your current position within the ByteString chunk, other
strategies will probably allocate too much.

G



On Mon, Mar 18, 2013 at 9:53 AM, Konstantin Litvinenko <
to.darkan...@gmail.com> wrote:

> Hi All!
>
> I tune my toy project for performance and hit the wall on simple, in
> imperative world, task. Here is the code that model what I'm trying to
> achieve
>
> import qualified Data.ByteString.Lazy as L
> import Data.Word8(isSpace)
> import Data.Word
> import Control.Monad.State
>
> type Stream = State L.ByteString
>
> get_byte :: Stream (Maybe Word8)
> get_byte = do
> s <- get
> case L.uncons s of
> Nothing -> return Nothing
> Just (x, xs) -> put xs >> return (Just x)
>
> main = do
> f <- L.readFile "test.txt"
> let r = evalState count_spaces f
> print r
>   where
> count_spaces = go 0
>   where
> go a = do
> x <- get_byte
> case x of
> Just x' ->  if isSpace x' then go (a + 1) else go a
> Nothing -> return a
>
> It takes the file and count spaces, in imperative way, consuming bytes one
> by one. The problem is: How to rewrite this to get rid of constant
> allocation of state but still working with stream of bytes? I can rewrite
> this as one-liner L.foldl, but that doesn't help me in any way to optimize
> my toy project where all algorithms build upon consuming stream of bytes.
>
> PS. My main lang is C++ over 10 years and I only learn Haskell :)
>
>
> __**_
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>



-- 
Gregory Collins 
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compiled program using OpenGL fails to trigger GPU switch on Mac, but works in GHCi

[Jesper Särnesjö]

On Mon, Mar 18, 2013 at 11:27 AM, Brandon Allbery  wrote:
> On Sun, Mar 17, 2013 at 7:58 PM, Jason Dagit  wrote:
>> On Sat, Mar 16, 2013 at 6:53 PM, Jesper Särnesjö >>
>>> To be clear, I think this isn't really an OpenGL problem, but rather
>>> one related to FFI or event handling. If anyone could explain to me,The
>>> release notes for 7.0.1 said this about that flag:
>>
>> There is a new -fno-ghci-sandbox flag, which stops GHCi running
>> computations in a separate thread. In particular, this is useful for GLUT on
>> OS X, which only works if being run on the main thread.
>
> Worth noting is that Jesper said it *works* in ghci, and fails when
> compiled

Interestingly, running the program in GHCi with the -fno-ghci-sandbox
flag, causes it to misbehave in the same way as when compiled:

$ ghci -fno-ghci-sandbox -lglfw glfw_test.hs
[...]
*Main> main
Apple Software Renderer

This is starting to smell like a concurrency-related issue, then. I
should note that the GLFW library does use multiple OS threads, and I
know from previous experience that Mac OS X is fussy about GUI actions
being run on the main thread. The curious thing here, of course, is
that the behavior I am seeing is the exact opposite of that mentioned
in the release notes.

I've found some interesting reading material on how GHC handles the
interaction of concurrency and FFI, in particular the paper "Extending
the Haskell Foreign Function Interface with Concurrency" by Simon
Marlow and Simon Peyton-Jones [1], which even brings up OpenGL as an
example of why a programmer must be able to "specify that a related
group of foreign calls are all made by the same OS thread". I haven't
yet had the time to dig too deep into this, but I have tried a few
things:

* I've compiled the program with -threaded (as suggested by John
Lato), with the foreign functions marked as safe and unsafe (as
suggested by Carter Schonwald).
* I've checked that the main thread of my Haskell program is bound to
an OS thread [2], which it is when using the threaded runtime. I've
also tried explicitly running the block of foreign calls in a bound
thread [3].
* I've made sure that there is only one GLFW library on my machine for
-lglfw to link with, and that it is the very same library my C program
links with.

None of the above helped. However, I will keep investigating and see
what I find.

As I final note, I did learn that the GHC runtime generates SIGVTALRM
signals to cause the scheduler to switch contexts [4][5]. Perhaps this
prevents GLFW from running properly? Looks like I'll need to brush up
on my dtrace.

-- 
Jesper Särnesjö
http://jesper.sarnesjo.org/

[1] http://community.haskell.org/~simonmar/papers/conc-ffi.pdf
[2] 
http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html#v:isCurrentThreadBound
[3] 
http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html#v:runInBoundThread
[4] http://joeyh.name/blog/entry/ghc_threaded_runtime_gotchas/
[5] 
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals#RTSAlarmSignalsandForeignLibraries

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Need some advice around lazy IO

[Dan Doel]

Do note that deepSeq alone won't (I think) change anything in your
current code. bug will deepSeq the file contents. And the cons will
seq bug. But nothing is evaluating the cons. And further, the cons
isn't seqing the tail, so none of that will collapse, either. So the
file descriptors will still all be opened at once.

Probably the best solution if you choose to go this way is:

bug <- evaluate (fileContents2Bug $!! str)

which ties the evaluation of the file contents into the IO execution.
At that point, deepSeqing the file is probably unnecessary, though,
because evaluating the bug will likely allow the file contents to be
collected.

On Mon, Mar 18, 2013 at 6:42 AM, C K Kashyap  wrote:
> Thanks Konstantin ... I'll try that out too...
>
>
>
> Regards,
> Kashyap
>
>
> On Mon, Mar 18, 2013 at 3:31 PM, Konstantin Litvinenko
>  wrote:
>>
>> On 03/17/2013 07:08 AM, C K Kashyap wrote:
>>>
>>> I am working on an automation that periodically fetches bug data from
>>> our bug tracking system and creates static HTML reports. Things worked
>>> fine when the bugs were in the order of 200 or so. Now I am trying to
>>> run it against 3000 bugs and suddenly I see things like - too  many open
>>> handles, out of memory etc ...
>>>
>>> Here's the code snippet - http://hpaste.org/84197
>>>
>>> It's a small snippet and I've put in the comments stating how I run into
>>> "out of file handles" or simply file not getting read due to lazy IO.
>>>
>>> I realize that putting ($!) using a trial/error approach is going to be
>>> futile. I'd appreciate some pointers into the tools I could use to get
>>> some idea of which expressions are building up huge thunks.
>>
>>
>> You problem is in
>>
>> let bug = ($!) fileContents2Bug str
>>
>> ($!) evaluate only WHNF and you need NF. Above just evaluate to first char
>> in a file, not to all content. To fully evaluate 'str' you need something
>> like
>>
>> let bug = Control.DeepSeq.rnf str `seq` fileContents2Bug str
>>
>>
>>
>>
>>
>>
>> ___
>> Haskell-Cafe mailing list
>> Haskell-Cafe@haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Need some advice around lazy IO

[Konstantin Litvinenko]

On 03/18/2013 06:06 PM, Dan Doel wrote:

Do note that deepSeq alone won't (I think) change anything in your
current code. bug will deepSeq the file contents.


rfn fully evaluate 'bug' by reading all file content. Later hClose will 
close it and we done. Not reading all content will lead to semi closed 
handle, leaked in that case. Handle will be opened until hGetContents 
lazy list hit the end.


 And the cons will

seq bug. But nothing is evaluating the cons. And further, the cons
isn't seqing the tail, so none of that will collapse, either. So the
file descriptors will still all be opened at once.

Probably the best solution if you choose to go this way is:

 bug <- evaluate (fileContents2Bug $!! str)

which ties the evaluation of the file contents into the IO execution.
At that point, deepSeqing the file is probably unnecessary, though,
because evaluating the bug will likely allow the file contents to be
collected.


evaluate do the same as $! - evaluate args to WHNF. That won't help in 
any way. Executing in IO monad doesn't imply strictness Thats why mixing 
lazy hGetContent with strict hOpen/hClose is so tricky.




___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Announcement - HGamer3D - 0.2.1 - featuring FRP based GUI and more

[Peter Althainz]

Dear All,

I'm happy to announce release 0.2.1 of HGamer3D, the game engine with 
Haskell API, featuring FRP based API and FRP based GUI. The new FRP API 
is based on the netwire package. Currently only available on Windows: 
http://www.hgamer3d.org.


Peter

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compiled program using OpenGL fails to trigger GPU switch on Mac, but works in GHCi

[Carter Schonwald]

Hey Jesper,
thanks for the headsup!

please continue to share you findings on this matter, It sounds like it'll
be really useful for folks!

-Carter


On Mon, Mar 18, 2013 at 9:19 AM, Jesper Särnesjö  wrote:

> On Mon, Mar 18, 2013 at 11:27 AM, Brandon Allbery 
> wrote:
> > On Sun, Mar 17, 2013 at 7:58 PM, Jason Dagit  wrote:
> >> On Sat, Mar 16, 2013 at 6:53 PM, Jesper Särnesjö  >>>
> >>> To be clear, I think this isn't really an OpenGL problem, but rather
> >>> one related to FFI or event handling. If anyone could explain to me,The
> >>> release notes for 7.0.1 said this about that flag:
> >>
> >> There is a new -fno-ghci-sandbox flag, which stops GHCi running
> >> computations in a separate thread. In particular, this is useful for
> GLUT on
> >> OS X, which only works if being run on the main thread.
> >
> > Worth noting is that Jesper said it *works* in ghci, and fails when
> > compiled
>
> Interestingly, running the program in GHCi with the -fno-ghci-sandbox
> flag, causes it to misbehave in the same way as when compiled:
>
> $ ghci -fno-ghci-sandbox -lglfw glfw_test.hs
> [...]
> *Main> main
> Apple Software Renderer
>
> This is starting to smell like a concurrency-related issue, then. I
> should note that the GLFW library does use multiple OS threads, and I
> know from previous experience that Mac OS X is fussy about GUI actions
> being run on the main thread. The curious thing here, of course, is
> that the behavior I am seeing is the exact opposite of that mentioned
> in the release notes.
>
> I've found some interesting reading material on how GHC handles the
> interaction of concurrency and FFI, in particular the paper "Extending
> the Haskell Foreign Function Interface with Concurrency" by Simon
> Marlow and Simon Peyton-Jones [1], which even brings up OpenGL as an
> example of why a programmer must be able to "specify that a related
> group of foreign calls are all made by the same OS thread". I haven't
> yet had the time to dig too deep into this, but I have tried a few
> things:
>
> * I've compiled the program with -threaded (as suggested by John
> Lato), with the foreign functions marked as safe and unsafe (as
> suggested by Carter Schonwald).
> * I've checked that the main thread of my Haskell program is bound to
> an OS thread [2], which it is when using the threaded runtime. I've
> also tried explicitly running the block of foreign calls in a bound
> thread [3].
> * I've made sure that there is only one GLFW library on my machine for
> -lglfw to link with, and that it is the very same library my C program
> links with.
>
> None of the above helped. However, I will keep investigating and see
> what I find.
>
> As I final note, I did learn that the GHC runtime generates SIGVTALRM
> signals to cause the scheduler to switch contexts [4][5]. Perhaps this
> prevents GLFW from running properly? Looks like I'll need to brush up
> on my dtrace.
>
> --
> Jesper Särnesjö
> http://jesper.sarnesjo.org/
>
> [1] http://community.haskell.org/~simonmar/papers/conc-ffi.pdf
> [2]
> http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html#v:isCurrentThreadBound
> [3]
> http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html#v:runInBoundThread
> [4] http://joeyh.name/blog/entry/ghc_threaded_runtime_gotchas/
> [5]
> http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Signals#RTSAlarmSignalsandForeignLibraries
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Improving my implementation of "The Lady Tasting Tea"

[Mark Fredrickson]

Hello,

For my first project in Haskell, I thought I would re-implement a
statistical problem that I have previously done in R. In his 1925 book,
Fisher tells of an experiment in which a lady claims she can tell the
difference in cups of tea that have the milk or the tea/water added first
(I'm a coffee drinker, so I'm unclear on the actual physical
interpretation). To test this claim, Fisher proposes an experiment in which
8 cups are created, with 4 having milk first and 4 having tea first. If the
lady can properly label 3 of the 4 milk first cups correctly, should we be
suprised? What is the probability that she would get 3 or 4 of the milk
first cups correct just due to chance (that is, independently of the actual
allocation of milk and tea first)?

Fisher shows that these questions can be answered by writing out all the
possible ways the 4 milk cups could be allocated (there are 70 such
possibilities) and then counting the subset that have 3 or 4 correct
according to the lady's guess (there are 17). Therefore the probability of
getting 3 or 4 correct just by guessing would occur about 24% of the time.

I've implemented this algorithm for problems of arbitrary size, and I'd
like some feedback on improving the efficiency of my code:

https://gist.github.com/markmfredrickson/5190212

The problem is basically a map-reduce:

1. Create the C(N,K) possible ways the cups could be set up (where N is the
total number of cups, and K is the number with milk first)
2. Map a function across them that scores the lady's guess
3. Reduce the set of scores to a p-value (a value between 0 and 1) that
indicates what percentage of all possible allocations of milk first would
have a score equal to or greater than the lady's guess.

My first attempt at profiling indicates that most time is spent in the
scoring function, unsurprising as this is in the inner most loop of the
algorithm. The generation of all possible combinations is also time
consuming. From what I can tell, this implementation is not very efficient
from a space perspective.

In the long term, I'm interested in using this same basic procedure to
solve more interesting statistical problems, so I'm particulary interested
in getting feed back on:

1. A good data type for storing the list of treatment allocations (i.e.
milk first cups).

The current problem calls for binary treatment with no extra data. In the
future, my N units may be partitioned into K groups (here K=2), and the
score function will require additional data (e.g. each unit will have an
outcome measure on a continuous or ordinal scale). In a sense, I'd like to
use tuples to hold index values from 1 to N, but I wouldn't necessarily
know the tuple size at compile time. The index values would point to an
array or similar structure holding the additional data.

Some other properties of allocations:
- They are always the same size
- Order is not important
- All values are unique

Any standard types fit this description?

2. A better algorithm and perhaps data type for the combinations.

The current implementation uses a tree recursion to get the set of all
possible combinations. In the future, this set will be too large to
enumerate entirely, so I'll need to sample from it. It would be desirable
to be able to write `take samples (permute $ combinations total treated)`
where the `permute` function (perhaps with a random seed) properly
re-orders the combinations. If these goals are supported by a data
structure better than a list, I'm very open to using other types to hold
the combinations.

I would also appreciate any suggestions on making the code more idiomatic
or readable.

Thanks,
-Mark
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Specialized Computer Architecture - A Question

[OWP]

If I may ask, I'm not quite sure what O(2^n) and O(1) are?

"Besides Moore's Law, digital computing also benefits from mature
tools and expertise for optimizing performance at all levels of the
system: process technology,
fundamental circuits, layout and algorithms. Many engineers are
simultaneously working to improve every aspect of digital technology,
while alternative technologies like analog computing do not have the
same kind of industry juggernaut pushing them forward."

I'm curious, were not all these built on the foundation of Moore's
Law?  Everything Vigoda lists has Moore's Law in mind.  If Moore's Law
were to suddenly disappear, could these survive on their own merit?

Let me rephrase that, of course they will survive politically.  People
built these tools and if built, they will be use but will they survive
efficiently?   In the future, if a particular specialized architecture
is somewhat better than the rest on it's own merit for a particular
need while the stock architecture is reaching a
point of low returns for all the energy put into it - could the
specialized architecture reach a point where it becomes useful?  Could
there be a competitive advantage to specialized architecture if
Moore's Law were to go away?

On 3/17/13, Gwern Branwen  wrote:
> On Sun, Mar 17, 2013 at 5:56 PM, OWP  wrote:
>> These "stock architectures", were they really so good that they out
>> performed the specialized ones on it's own merits or was this mainly due
>> to
>> Moore's Law on transistors?  In other words, suppose we separate Moore's
>> Law
>> from the stock architecture, would it still outperform the specialized
>> ones?
>
> It's not really meaningful to separate them. Any time you use a custom
> architecture, you are forfeiting all sorts of network effects - and
> sooner or later, the custom architecture falls behind. If you want to
> make an analogy, when you go with a custom architecture, you are
> trading a process where your computing power increases O(2^n) for one
> with a big constant factor but where computing power increases O(1)...
>
>> "In practice replacing digital computers with an alternative computing
>> paradigm is a risky proposition.
> Alternative computing architectures, such as parallel digital
> computers have not tended to be commercially viable, because Moore's
> Law has consistently enabled conventional von Neumann architectures to
> render alternatives unnecessary. Besides Moore's Law, digital
> computing also benefits from mature tools and expertise for optimizing
> performance at all levels of the system: process technology,
> fundamental circuits, layout and algorithms. Many engineers are
> simultaneously working to improve every aspect of digital technology,
> while alternative technologies like analog computing do not have the
> same kind of industry juggernaut pushing them forward."
>
> from Benjamin Vigoda, "Analog Logic: Continuous-Time Analog Circuits
> for Statistical Signal Processing" (2003 PhD thesis)
>
> --
> gwern
> http://www.gwern.net
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Fwd: Now Accepting Applications for Mentoring Organizations for GSoC 2013

[Johan Tibell]

[bcc: hask...@haskell.org]

We should make sure that we apply for Google Summer of Code this year as
well. It's been very successful in the previous year, where we have
gotten several projects funded every year.

-- Johan

-- Forwarded message --
From: Carol Smith 
Date: Mon, Mar 18, 2013 at 12:00 PM
Subject: Now Accepting Applications for Mentoring Organizations for GSoC
2013
To: Google Summer of Code Announce <
google-summer-of-code-annou...@googlegroups.com>


Hi all,

We're pleased to announce that applications for mentoring organizations for
Google Summer of Code 2013 are now being accepted [1]. If you'd like to
apply to be a mentoring organization you can do so via Melange [2]. If you
have questions about how to use Melange, please see our User's Guide [3].

Please note that the application period [4] closes on 29 March at 19:00 UTC
[5]. We will not accept any late applications for any reason.

[1] -
http://google-opensource.blogspot.com/2013/03/mentoring-organization-applications-now.html
[2] - http://www.google-melange.com
[3] - http://en.flossmanuals.net/melange/
[4] - http://www.google-melange.com/gsoc/events/google/gsoc2013
[5] - http://goo.gl/xmQMJ

Cheers,
Carol

-- 
You received this message because you are subscribed to the Google Groups
"Google Summer of Code Announce" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-summer-of-code-announce+unsubscr...@googlegroups.com.
To post to this group, send email to
google-summer-of-code-annou...@googlegroups.com.
Visit this group at
http://groups.google.com/group/google-summer-of-code-announce?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Specialized Computer Architecture - A Question

[Gwern Branwen]

On Mon, Mar 18, 2013 at 4:31 PM, OWP  wrote:
> If I may ask, I'm not quite sure what O(2^n) and O(1) are?

Just a metaphor using algorithmic complexity, is all.

> I'm curious, were not all these built on the foundation of Moore's
> Law?  Everything Vigoda lists has Moore's Law in mind.  If Moore's Law
> were to suddenly disappear, could these survive on their own merit?

No one really knows, since Moore's law has operated for so long. There
seem to be constant factors to be had in my opinion* but in some
problems/areas/domains, ASICs don't seem to help very much**, and we
should not forget the colossal investments that a cutting-edge X86
chip fab represents*** which may make the best general bang for buck a
commodity processor. For example, for every person who trumpets a 100x
gain in switching their program to a GPU, there's another person
abandoning their effort because they lose all the speed gains in
transferring data back and forth from the GPU.

But I think this is getting pretty off-topic for Haskell-cafe.

* I'm not an expert, but some useful material is in
http://www.gwern.net/Aria%27s%20past,%20present,%20and%20future#fn3
and http://www.gwern.net/Self-decrypting%20files#constant-factors
** the more serial a problem is, the more conditionals, memory
accesses, and distinct operations a task requires, the more the
optimal processor will... look like a CPU.
*** http://www.gwern.net/Slowing%20Moore%27s%20Law#fab-costs-and-requirements

-- 
gwern

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Specialized Computer Architecture - A Question

[Brandon Allbery]

On Mon, Mar 18, 2013 at 4:31 PM, OWP  wrote:

> Let me rephrase that, of course they will survive politically.  People
> built these tools and if built, they will be use but will they survive
> efficiently?   In the future, if a particular specialized architecture
> is somewhat better than the rest on it's own merit for a particular
> need while the stock architecture is reaching a
> point of low returns for all the energy put into it - could the
> specialized architecture reach a point where it becomes useful?  Could
> there be a competitive advantage to specialized architecture if
> Moore's Law were to go away?
>

There is now, in some narrow specializations. GPUs and DSP come to mind ---
while both are also done on commodity CPUs to some extent, the specialized
architectures are used where speed is of the essence. (DSP started out on
specialized architectures, but many commodity uses are on commodity
architectures these days, reserving the specialized ones to those niches
that require them.)

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Compiled program using OpenGL fails to trigger GPU switch on Mac, but works in GHCi

[Albert Y. C. Lai]

On 13-03-18 09:19 AM, Jesper Särnesjö wrote:

Interestingly, running the program in GHCi with the -fno-ghci-sandbox
flag, causes it to misbehave in the same way as when compiled:


Then perhaps to mimic default ghci in hope of getting good results:

- compile with -threaded (more candidly, link with -threaded, it does 
not change code generation)


- in the program, deliberately move the work to a forkIO-thread

(I suggest forkIO instead of forkOS because I have just tried:

$ ghci
GHCi, version 7.4.2: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> Control.Concurrent.isCurrentThreadBound
False

$ ghci -fno-ghci-sandbox
GHCi, version 7.4.2: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> Control.Concurrent.isCurrentThreadBound
True

Although, perhaps it doesn't matter.)


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] Workshop on Generic Programming

[Jacques Carette]

Dear list subscribers,  apologies if you receive multiple copies of this 
CFP.


==
CALL FOR PAPERS

   WGP 2013

9th ACM SIGPLAN Workshop on Generic Programming
  Boston, Massachusetts, USA
  Saturday, September 29th, 2013

http://www.wgp-sigplan.org/2013

  Co-located with the
International Conference on Functional Programming (ICFP 2013)
==


Goals of the workshop
-

Generic programming is about making programs more adaptable by making
them more general. Generic programs often embody non-traditional kinds
of polymorphism; ordinary programs are obtained from them by suitably
instantiating their parameters. In contrast with normal programs, the
parameters of a generic program are often quite rich in structure; for
example they may be other programs, types or type constructors, class
hierarchies, or even programming paradigms.

Generic programming techniques have always been of interest, both to
practitioners and to theoreticians, and, for at least 20 years,
generic programming techniques have been a specific focus of research
in the functional and object-oriented programming communities. Generic
programming has gradually spread to more and more mainstream
languages, and today is widely used in industry. This workshop brings
together leading researchers and practitioners in generic programming
from around the world, and features papers capturing the state of the
art in this important area.

We welcome contributions on all aspects, theoretical as well as
practical, of

* generic programming,
* programming with (C++) concepts,
* meta-programming,
* programming with type classes,
* programming with modules,
* programming with dependent types,
* type systems for generic programming,
* polytypic programming,
* adaptive object-oriented programming,
* component-based programming,
* strategic programming,
* aspect-oriented programming,
* family polymorphism,
* object-oriented generic programming,
* implementation of generic programming languages,
* static and dynamic analyses of generic programs,
* and so on.

Program Committee
-

Jeremiah Willcock (co-chair), Indiana University
Jacques Carette (co-chair), McMaster University
Florian Rabe, Jacobs University Bremen
Emilie Balland, INRIA Bordeaux
Jeremy Siek, University of Colorado, Boulder
Gabriel Dos Reis, Texas A&M University
Christophe Raffalli, Savoie University
Anya Helene Bagge, Universitetet i Bergen
Tiark Rompf, Ecole Polytechnique Federale de Lausanne
Andreas Abel, Ludwig-Maximilians-Universitat Munchen
Edward Kmett, S&P Capital IQ
William Cook, University of Texas, Austin

Proceedings and Copyright
-

We plan to have formal proceedings, published by the ACM.  Authors must
transfer copyright to ACM upon acceptance (for government work, to the
extent transferable), but retain various rights
(http://www.acm.org/publications/policies/copyright_policy). Authors are
encouraged to publish auxiliary material with their paper (source code,
test data, etc.); they retain copyright of auxiliary material.

Submission details
--

Deadline for submission: Friday2013-06-14
Notification of acceptance:  Wednesday 2013-07-11
Final submission due:Tuesday   2013-07-25
Workshop:Sunday2013-09-28

Papers should be submitted via EasyChair at

https://www.easychair.org/conferences/?conf=wgp2013

Submitted papers should be in portable document format (PDF), formatted
using the ACM SIGPLAN style guidelines (two-column, 9pt). The length is
restricted to 12 pages.

Travel Support
--

Student attendees with accepted papers can apply for a SIGPLAN PAC grant
to help cover travel expenses. PAC also offers other support, such as
for child-care expenses during the meeting or for travel costs for
companions of SIGPLAN members with physical disabilities, as well as for
travel from locations outside of North America and Europe. For details
on the PAC program, see its web page (http://www.sigplan.org/PAC.htm).

History of the Workshop on Generic Programming
--

Earlier Workshops on Generic Programming have been held in

  * Copenhagen, Denmark 2012 (affiliated with ICFP12),
  * Tokyo, Japan 2011 (affiliated with ICFP11),
  * Baltimore, Maryland, US 2010 (affiliated with ICFP10),
  * Edinburgh, UK 2009 (affiliated with ICFP09),
  * Victoria, BC, Canada 2008 (affiliated with ICFP),
  * Portland 2006 (affiliated with ICFP),
  * Ponte de Lima 2000 (affiliated with MPC),
  * Marstrand 1998 (affiliated with MPC).

Furthermore, there were a few informal workshops

  * Utrecht 2005 (informal workshop

Re: [Haskell-cafe] [Haskell] Fwd: Now Accepting Applications for Mentoring Organizations for GSoC 2013

[Edward A Kmett]

Absolutely. I've had it on my calendar for months. :) They just opened 
registration today. Our application will be going in tomorrow night after I get 
a chance to coördinate with a couple of other organizations that want to apply 
re: endorsements.

Sent from my iPhone

On Mar 18, 2013, at 4:49 PM, Johan Tibell  wrote:

> [bcc: hask...@haskell.org]
> 
> We should make sure that we apply for Google Summer of Code this year as 
> well. It's been very successful in the previous year, where we have gotten 
> several projects funded every year.
> 
> -- Johan
> 
> -- Forwarded message --
> From: Carol Smith 
> Date: Mon, Mar 18, 2013 at 12:00 PM
> Subject: Now Accepting Applications for Mentoring Organizations for GSoC 2013
> To: Google Summer of Code Announce 
> 
> 
> 
> Hi all,
> 
> We're pleased to announce that applications for mentoring organizations for 
> Google Summer of Code 2013 are now being accepted [1]. If you'd like to apply 
> to be a mentoring organization you can do so via Melange [2]. If you have 
> questions about how to use Melange, please see our User's Guide [3].
> 
> Please note that the application period [4] closes on 29 March at 19:00 UTC 
> [5]. We will not accept any late applications for any reason.
> 
> [1] - 
> http://google-opensource.blogspot.com/2013/03/mentoring-organization-applications-now.html
> [2] - http://www.google-melange.com
> [3] - http://en.flossmanuals.net/melange/
> [4] - http://www.google-melange.com/gsoc/events/google/gsoc2013
> [5] - http://goo.gl/xmQMJ
> 
> Cheers,
> Carol
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Google Summer of Code Announce" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to google-summer-of-code-announce+unsubscr...@googlegroups.com.
> To post to this group, send email to 
> google-summer-of-code-annou...@googlegroups.com.
> Visit this group at 
> http://groups.google.com/group/google-summer-of-code-announce?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>  
>  
> 
> ___
> Haskell mailing list
> hask...@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Specialized Computer Architecture - A Question

[Richard A. O'Keefe]

On 19/03/2013, at 9:31 AM, OWP wrote:

> If I may ask, I'm not quite sure what O(2^n) and O(1) are?

Check any data structures and algorithms textbook.

Reverting to the original topic, THIS is the age of specialised
machines.  A lot of the chips out there are not just a CPU but
a SoC (System on a Chip).  Start with the ARM1176JZF-S chip whose
manual I currently have open.
 - sorta kinda RISCish ARM instruction set processor
   + including SIMD DSP/graphics support
 - native hardware execution of (most) Java bytecodes
   (This is ARM's "Jazelle" extension.)
 - vector floating point co-processor
You can get other chips with ARM cores and a mix of
 - analogue<->digital converters, comparators, Flash controllers,
   Ethernet controllers, USB controllers, other interface
   controllers, hardware encryption (especially in ARM v8),
   more kinds of timers than you knew existed, hardware random
   number generation, 
You can even get ARM chips with on-board FPGAs.

Of course SoC systems are not limited to the ARM architecture.
SPARC T4 chips have "Crypto Instruction Accelerators … [that] …
enable high speed encryption for over a dozen industry standard
ciphers" "plus random number generation" and "high speed 10 GbE
networking directly on … the silicon" and two PCI Express controllers.
SPARC systems offered, and still do offer, special hardware support
for dynamic programming languages in which immediate integers have
tag 00 in the bottom 2 bits.  However, when they went 64-bit, they
didn't bother to extend that to 64-minus-2-bit integers.

And of course there are Intel and AMD chips with all sorts of extra
hardware support for all sorts of things.  Notably, people are
integrating GPUs onto the same chip as the CPU.  (Where are the APL
compilers that can take advantage of this?  It's the perfect
APLlication for the language!)

The key point is that cpu designers/vendors take existing workloads
of commercial significance and figure out how to optimise that.  If
a heavy-duty web server, or a high end gaming system, or a mobile
phone, &c could clearly benefit from some kind of acceleration,
someone will get it.  If Javascript had a common abstract instruction
set, there'd be hardware acceleration for that.

Haskell programs are not yet a workload of commercial significance.

Sadly.


___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Specialized Computer Architecture - A Question

[OWP]

Ironically, you made an interesting point on how Moore's Law created
the on chip "real estate" that made specialized machines possible.  As
transistor sizing shrinks and die sizes increase, more and more real
estate should now be available for usage.  Oddly, what destroyed
specialized machines in the past seemed to be the same cause in
reviving it from the dead.

The ARM Jazelle interface - I'm not familiar with it's but it's got me
curious.  Has there been any though (even in the most lighthearted
discussions) on what a physical "Haskell Machine" could look like?
Mainly, what could be left to compile to the stock architecture and
what could be sent out to more specialized areas?


On 3/18/13, Richard A. O'Keefe  wrote:
>
> On 19/03/2013, at 9:31 AM, OWP wrote:
>
>> If I may ask, I'm not quite sure what O(2^n) and O(1) are?
>
> Check any data structures and algorithms textbook.
>
> Reverting to the original topic, THIS is the age of specialised
> machines.  A lot of the chips out there are not just a CPU but
> a SoC (System on a Chip).  Start with the ARM1176JZF-S chip whose
> manual I currently have open.
>  - sorta kinda RISCish ARM instruction set processor
>+ including SIMD DSP/graphics support
>  - native hardware execution of (most) Java bytecodes
>(This is ARM's "Jazelle" extension.)
>  - vector floating point co-processor
> You can get other chips with ARM cores and a mix of
>  - analogue<->digital converters, comparators, Flash controllers,
>Ethernet controllers, USB controllers, other interface
>controllers, hardware encryption (especially in ARM v8),
>more kinds of timers than you knew existed, hardware random
>number generation,
> You can even get ARM chips with on-board FPGAs.
>
> Of course SoC systems are not limited to the ARM architecture.
> SPARC T4 chips have "Crypto Instruction Accelerators … [that] …
> enable high speed encryption for over a dozen industry standard
> ciphers" "plus random number generation" and "high speed 10 GbE
> networking directly on … the silicon" and two PCI Express controllers.
> SPARC systems offered, and still do offer, special hardware support
> for dynamic programming languages in which immediate integers have
> tag 00 in the bottom 2 bits.  However, when they went 64-bit, they
> didn't bother to extend that to 64-minus-2-bit integers.
>
> And of course there are Intel and AMD chips with all sorts of extra
> hardware support for all sorts of things.  Notably, people are
> integrating GPUs onto the same chip as the CPU.  (Where are the APL
> compilers that can take advantage of this?  It's the perfect
> APLlication for the language!)
>
> The key point is that cpu designers/vendors take existing workloads
> of commercial significance and figure out how to optimise that.  If
> a heavy-duty web server, or a high end gaming system, or a mobile
> phone, &c could clearly benefit from some kind of acceleration,
> someone will get it.  If Javascript had a common abstract instruction
> set, there'd be hardware acceleration for that.
>
> Haskell programs are not yet a workload of commercial significance.
>
> Sadly.
>
>

___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

[Haskell-cafe] ANNOUNCE: HaTeX-3.5 - New version of the LaTeX library

[Daniel Díaz Casanueva]

Hi readers!

A new version of HaTeX has just been released. More math symbols and
utilities and a new attoparsec-based parser. This new version also includes
a new matrix renderer.

A summary of the changes:

http://deltadiaz.blogspot.com/2013/03/hatex-35.html

The package in Hackage:

http://hackage.haskell.org/package/HaTeX-3.5

For those who don't know, HaTeX is a combinator library for LaTeX code.
Read more in the manual:

https://github.com/downloads/Daniel-Diaz/HaTeX-Guide/HaTeX-Guide.pdf

I recommend to HaTeX users to upgrade to this new version.

Good luck,
Daniel Díaz.

-- 
E-mail sent by Daniel Díaz Casanueva

let f x = x in x
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] Need some advice around lazy IO

[Edward Kmett]

Konstantin,

Please allow me to elaborate on Dan's point -- or at least the point that I
believe that Dan is making.

Using,

let bug = Control.DeepSeq.rnf str `seq` fileContents2Bug str


or ($!!) will create a value that *when forced* cause the rnf to occur.

As you don't look at bug until much later this causes the same problem as
before!

His addition of evaluate forces the rnf to happen before proceeding.

On a more ad hoc basis you might say

let !bug = fileContents2Bug $!! str

but without the bang-pattern or the evaluate, which is arguably strictly
better (er no pun intended) from a semantics perspective nothing has
happened yet until someone inspects bug.

With the code as structured this doesn't happen until it is too late.

-Edward

On Mon, Mar 18, 2013 at 1:11 PM, Konstantin Litvinenko <
to.darkan...@gmail.com> wrote:

> On 03/18/2013 06:06 PM, Dan Doel wrote:
>
>> Do note that deepSeq alone won't (I think) change anything in your
>> current code. bug will deepSeq the file contents.
>>
>
> rfn fully evaluate 'bug' by reading all file content. Later hClose will
> close it and we done. Not reading all content will lead to semi closed
> handle, leaked in that case. Handle will be opened until hGetContents lazy
> list hit the end.
>
>
>  And the cons will
>
>> seq bug. But nothing is evaluating the cons. And further, the cons
>> isn't seqing the tail, so none of that will collapse, either. So the
>> file descriptors will still all be opened at once.
>>
>> Probably the best solution if you choose to go this way is:
>>
>>  bug <- evaluate (fileContents2Bug $!! str)
>>
>> which ties the evaluation of the file contents into the IO execution.
>> At that point, deepSeqing the file is probably unnecessary, though,
>> because evaluating the bug will likely allow the file contents to be
>> collected.
>>
>
> evaluate do the same as $! - evaluate args to WHNF. That won't help in any
> way. Executing in IO monad doesn't imply strictness Thats why mixing lazy
> hGetContent with strict hOpen/hClose is so tricky.
>
>
>
>
> __**_
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/**mailman/listinfo/haskell-cafe
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] ANNOUNCE: HaTeX-3.5 - New version of the LaTeX library

[Andrew Cowie]

On Tue, 2013-03-19 at 00:47 -0400, Daniel Díaz Casanueva wrote:

> This new version also includes a new matrix renderer.

I'm surprised you had to create a new 'matrix' package; I would have
thought one of the existing math libraries would have had the types you
need?

AfC
Sydney




signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Re: [Haskell-cafe] attoparsec and backtracking

[oleg]

Wren Thornton wrote:
> I had some similar issues recently. The trick is figuring out how to
> convince attoparsec to commit to a particular alternative. For example,
> consider the grammar: A (B A)* C; where if the B succeeds then we want to
> commit to parsing an A (and if it fails then return A's error, not C's).

Indeed. Consider the following (greatly simplified) fragment from the
OCaml grammar

| "let"; r = opt_rec; bi = binding; "in";
   x = expr LEVEL ";" ->
| "function"; a = match_case ->
| "if"; e1 = SELF; "then"; e2 = expr LEVEL "top";
  "else"; e3 = expr LEVEL "top" ->
...
| "false" -> 
| "true"  -> 

It would be bizarre if the parser -- upon seeing "if" but not finding
"then" -- would've reported the error that `found "if" when "true" was
expected'. Many people would think that when the parser comes across
"if", it should commit to parsing the conditional. And if it fails later, it
should report the error with the conditional, rather than trying to
test how else the conditional cannot be parsed. This is exactly the
intuition of pattern matching. For example, given

> foo ("if":t) = case t of
>  (e:"then":_) -> e
> foo _ = ""

we expect that 
foo ["if","false","false"]
will throw an exception rather than return the empty string. If the
pattern has matched, we are committed to the corresponding
branch. Such an intuition ought to apply to parsing -- and indeed it
does. The OCaml grammar above was taken from the camlp4 code. Camlp4
parsers

http://caml.inria.fr/pub/docs/tutorial-camlp4/tutorial002.html#toc6

do pattern-matching on a stream, for example
 # let rec expr =
 parser
   [< 'If; x = expr; 'Then; y = expr; 'Else; z = expr >] -> "if"
 | [< 'Let; 'Ident x; 'Equal; x = expr; 'In; y = expr >] -> "let"

and raise two different sort of exceptions. A parser raises
Stream.Failure if it failed on the first element of the stream (in the
above case, if the stream contains neither If nor Let). If the parser
successfully consumed the first element but failed later, a different
Stream.Error is thrown. Although Camlp4 has many detractors, even they
admit that the parsing technology by itself is surprisingly powerful,
and produces error messages that are oftentimes better than those by
the yacc-like, native OCaml parser. Camlp4 parsers are used
extensively in Coq.

The idea of two different failures may help in the case of attoparsec
or parsec. Regular parser failure initiates backtracking. If we wish
to terminate the parser, we should raise the exception (and cut the
rest of the choice points). Perhaps the could be a combinator `commit'
that converts a failure to the exception. In the original example
A (B A)* C we would use it as A (B (commit A))* C.



___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe