Good plan!
Ian Lynagh :
> Hi all,
>
> Following a recent discussion, we propose to reorganise the GHC-related
> mailing lists so that we end up with:
>
>glasgow-haskell-users
>For user discussions
>
>ghc-devs
>For developer discussions
>
>ghc-commits
>For au
Hi Joachim,
On Wed, Dec 12, 2012 at 12:20:35AM +0100, Joachim Breitner wrote:
>
> I built GHC 7.6.2-rc1 for Debian.
Thanks for testing!
> Provides: haddock, [-haddock-interface-21-] {+haddock-interface-22+}
>
> i.e. upstream has bumped the haddock interface number. I really was not
> expectin
Hi,
I built GHC 7.6.2-rc1 for Debian. Unfortunately, we have this:
Control files of package ghc-haddock: lines which differ (wdiff format)
---
Depends: ghc (= [-7.6.1-3),-] {+7.6.1.20121207-1),+} libc6 (>= 2.11), libffi5
(>= 3.0
Thank you all for your replies.
On Tue, Dec 11, 2012 at 11:16 AM, Simon Peyton-Jones
wrote:
> And I think there is probably quite a lot that is in reach for C--, but
> out of reach for LLVM. Why? Because before we pass the code to LLVM we do
> CPS-conversion.
Is there a case for making a C/C+
On Tue, Dec 11, 2012 at 11:16 AM, Simon Peyton-Jones
wrote:
> Notice that the stack is now *explicit* rather than implicit, and LLVM has no
> hope of moving the assignment to z past the call to g (which is trivial in
> the original). I can explain WHY we do this (there is stuff on the wiki) but
Cool info!
Would love to see that report if you can dig it up :)
-Carter
On Tue, Dec 11, 2012 at 2:16 PM, Simon Peyton-Jones
wrote:
> | In my opinion we should only implement optimizations in Hoopl that
> | LLVM cannot do due to lack high-level information that we might have
> | gotten rid of
| In my opinion we should only implement optimizations in Hoopl that
| LLVM cannot do due to lack high-level information that we might have
| gotten rid of before we reach the LLVM code generator*. I don't think
Indeed. And I think there is probably quite a lot that is in reach for C--,
but o
Essentially I have a use case that, if worked, would save countless hours
in development time. I am writing a scientific computing web service
utilizing the Repa and Snap libraries. The Snap framework has a dynamic
loader that will load modules on the fly when the source files change.
This works
On Tue, Dec 11, 2012 at 5:57 AM, Francisco Vieira de Souza <
vieira.u...@gmail.com> wrote:
> Hi Simon! Is it not necessary to show the type of igraph_bool_t
> igraphhaskell_initialized like
>
> "int igraph_bool_t igraphhaskell_initialized = 0"?
>
"igraph_bool_t" uses the _t suffix convention for
On Tue, Dec 11, 2012 at 7:04 AM, Ian Lynagh wrote:
> Does that sound reasonable? Does anyone have any further questions or
> comments?
Sound good to me. Thanks for working on this.
-- Johan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@
Hi all,
Following a recent discussion, we propose to reorganise the GHC-related
mailing lists so that we end up with:
glasgow-haskell-users
For user discussions
ghc-devs
For developer discussions
ghc-commits
For automated commit messages from the git reposit
On 10/12/12 00:11, Nils wrote:
I'm currently working with a C library that needs to use/modify global C
variables, for example:
igraph_bool_t igraphhaskell_initialized = 0;
int igraphhaskell_initialize()
{
if (igraphhaskell_initialized != 0)
{
printf("C: Not init
On 10/12/12 12:46, Yuras Shumovich wrote:
On Mon, 2012-12-10 at 10:58 +, Simon Marlow wrote:
On 08/12/12 23:12, Yuras Shumovich wrote:
I tried to hack stg_putMVarzh directly:
if (enabled_capabilities == 1) {
info = GET_INFO(mvar);
} else {
("ptr" info) = cca
13 matches
Mail list logo
