On Wed, Apr 4, 2012 at 6:37 AM, tsuraan tsur...@gmail.com wrote:
What sorts of things can cause a thread to get an asynchronous thread
killed exception? I've been seeing rare, inexplicable thread
killed messages in my Snap handlers for a long time, but they aren't
from Snap's timeout code.
On Wed, Apr 4, 2012 at 6:37 AM, tsuraan tsur...@gmail.com wrote:
What sorts of things can cause a thread to get an asynchronous thread
killed exception? I've been seeing rare, inexplicable thread
killed messages in my Snap handlers for a long time, but they aren't
from Snap's timeout code.
Hi Haskell-Cafe GHC-users!
I'm looking to apply for the GSoC and since I've worked on GHC before
I'd like to continue to do so. My proposal would be something that
tempted me (as a physics student) for a while: Units for Haskell/GHC.
This project has been suggested for a long time on the
This sounds pretty cool and useful. How much of this can be implemented in a
library and how much of this would need to be supported on a compiler level?
Ideally, most of this would be solved on the library level.
Jurriën
On 4 Apr 2012, at 13:38, Nils Schweinsberg wrote:
Hi Haskell-Cafe
Am 04.04.2012 13:48, schrieb Jurriën Stutterheim:
This sounds pretty cool and useful. How much of this can be implemented in a
library and how much of this would need to be supported on a compiler level?
Ideally, most of this would be solved on the library level.
The compiler would have to
Implementing this proposal in GHC, as opposed to the library-only approach,
would allow for generation of much more useful and user friendly error
messages. I believe this aspect is important when it comes to type systems
supporting physical units.
Cheers, George
This sounds pretty cool and
Hi,
I don't see any mention here of the dimensional library (
http://hackage.haskell.org/package/dimensional), or its type-family variant
--- in order to be a viable proposal you should describe how you would
improve on the approach taken there.
G
On Wed, Apr 4, 2012 at 1:38 PM, Nils
Johannes Waldmann wrote:
The following program prints Right (test,Bool,True)
as it should, but it leaves behind in /tmp
two files (name is a long string of digits)
and an empty directory (name is ghcN_N).
I have a partial solutions for this; see the attached patch for hint.
It cleans
Hi Pranjal,
We are glad you are interested in the GSoC.
Please take a look at persistent: http://www.yesodweb.com/book/persistent
It performs queries and serialization based on Haskell records.
It also uses native drivers rather than HDBC.
I created a proposal outline [1] and there is a student
That's probably not where the threadKill is being sent *from*, it's where
your thread received it.
Yeah, it's definitely where my thread received it. It's just sort of
crazy, because when I get a ThreadKilled, it's almost always in
Tiger.update. My handler does much slower things, such as
This is a long shot, but it's easy to test - turn off GHC's RTS timer,
+RTS -V0 -RTS. That removes a source of SIGALRM interrupts.
Awesome, I'll give that a try. It's worth a shot, anyhow :)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
Thanks! I failed to notice this instance declaration in the document.
But I'm still curious as to whether a Monad instance for Source makes
any sense, since in 4.0 all of Source/Conduit/Sink would share the
same implementation.
Regards,
Paul Liu
On Tue, Apr 3, 2012 at 6:25 PM, yi huang
On Sun, Apr 1, 2012 at 7:03 PM, Ertugrul Söylemez e...@ertes.de wrote:
No, Netwire does things very differently. Note the total absence of
switching combinators. Where in traditional FRP and regular AFRP you
have events and switching in Netwire you have signal inhibition and
selection. AFRP
In 0.4, Source technically has a Monad instance, but it's not really
useful in the same way the instance Aristid is referring to. In order
to get that instance, we would need to introduce a newtype wrapper.
On Wed, Apr 4, 2012 at 5:55 PM, Paul Liu nine...@gmail.com wrote:
Thanks! I failed to
pranjal pandit pranjal5215 at gmail.com writes:
Hi,I would like to work on improving the HDBC as a GSOC project 2012. I have
a previous working experience with Django and its ORM and I had a look at
Amnesia (http://amnesia.sourceforge.net/user_manual/manual.html) which is a
SQL database
On Wed, Apr 4, 2012 at 7:59 PM, MightyByte mightyb...@gmail.com wrote:
pranjal pandit pranjal5215 at gmail.com writes:
Hi,I would like to work on improving the HDBC as a GSOC project 2012. I have
a previous working experience with Django and its ORM and I had a look at
Amnesia
Hello,
I am currently using lhs2TeX for the first time and have encountered a
problem which I am unable to solve myself: Some code lines are too long to
fit into a single line of the output (PDF) file and thus go off the right
edge of the page.
Consider the following example:
Ertugrul,
Do you have a conceptual writeup of Netwire anywhere? The only
documentation I've found are the API docs. I ask both out of
curiousity, and because I'm writing up background for a masters thesis
on FRP and I'd like to say something about Netwire.
2012/4/4 Paul Liu nine...@gmail.com:
This is a long shot, but it's easy to test - turn off GHC's RTS timer,
+RTS -V0 -RTS. That removes a source of SIGALRM interrupts.
I was really hoping this one would reveal something interesting, but
it seems to have no effect. Thanks for the hint though.
It's hard to rule Snap timeouts out; try building snap-core with the
-fdebug flag and running your app with DEBUG=1, you'll get a spew of
debugging output from Snap on stderr.
Heh, that was quite a spew. I normally get the exceptions tens of MB
into files that are hundreds of MB, and I
My Snap handlers communicate with various resource pools, often
through MVars. Is it possible that MVar deadlock would be causing the
runtime system to kill off a contending thread, giving it a
ThreadKilled exception? It looks like ghc does do deadlock detection,
but I can't find any docs on how
Whenever I've deadlocked, it terminated the program with thread
blocked indefinitely in an MVar operation.
On Wed, Apr 4, 2012 at 5:59 PM, tsuraan tsur...@gmail.com wrote:
My Snap handlers communicate with various resource pools, often
through MVars. Is it possible that MVar deadlock would be
Whenever I've deadlocked, it terminated the program with thread
blocked indefinitely in an MVar operation.
Well, I guess that's probably not what I'm seeing. I'm currently
trying to simplify the heck out of the code that near where the thread
killed exceptions are emanating; maybe once that's
Welcome to issue 221 of the HWN, an issue covering crowd-sourced bits
of information about Haskell from around the web. This issue covers the
week of March 25 to 31, 2012.
Quotes of the Week
* Tekmo: Now I have a monoid in the category of problems.
* hpc: atomically the whole thing
*
Hey Guys,
I'm Julian, I am reaching the end of my second year as a JMC (Joint Mathematics
and Computer science) Student at Imperial College London
and I'd like to apply to GSOC for a project involving Haskell and I just wanted
to run my idea past the community.
I've already talked about this
25 matches
Mail list logo
