On Thu, Apr 5, 2012 at 01:53, Sutherland, Julian <
julian.sutherlan...@imperial.ac.uk> wrote:
> data Tree = Node Left Right | Leaf
>
> Could be converted to a struct in C/C++:
>
> struct Tree {
> struct Tree* left;
> struct Tree* right;
> };
>
Shouldn't this actually be a tagged union? N
I love the idea of easier to use FFI, but isn't the haskell FFI
intentionally very low level, and intended to be used with tools?
In that light, maybe it would be easier to extend hsc2hs with fancier
macros and the ability to generate wrappers to directly call C++
methods and construct C++ objects
Hi everyone,
I'd like to announce the availability of the Yesod 1.0 release
candidate. The code is available on Hackage now, so you should be able
to install with a simple `cabal update && cabal install yesod` to get
up-and-running. If you've been installing from Github or Yackage,
you'll probably
Dominique,
thank you very much for your reply!
Yes, that would work for the code-blocks, but I'd still prefer
automatic line wrapping like in this example:
http://www.bollchen.de/blog/2011/04/good-looking-line-breaks-with-the-listings-package/
Also this does not solve the case of multi line res
David,
The easiest solution is probably to use multi-line string literals and
line-wrap manually:
\begin{code}
cyphertext = "rlkmlj, zlnift ekblvke pqc elvm if pzlp gblrk, akrlomk zk zle \
lfpiriglpke pzlp, if pzk flpojlb rcojmk cs knkfpm, morz qcobe ak pzk rcfeorp \
cs nkjriftkpcjiu, bklnkm
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 on
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
* B
> 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
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 wrote:
> My Snap handlers communicate with various resource pools, often
> through MVars. Is it possible that MVar deadlock would be causing the
>
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
> 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
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 :
> On Sun, Apr 1, 201
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:
---
On Wed, Apr 4, 2012 at 7:59 PM, MightyByte wrote:
> pranjal pandit 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/use
pranjal pandit 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 interface
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 wrote:
> Thanks! I failed to notice this instance
On Sun, Apr 1, 2012 at 7:03 PM, Ertugrul Söylemez 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 is really
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 wrote:
>
> 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
h
> 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 co
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 su
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
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 Schweinsber
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
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 kn
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 & G
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 GH
28 matches
Mail list logo
