Adrian Victor Crisciu | 21 Aug 14:26 2014
Picon

hmatrix-0.16.0.4 installation problem

Hi,

I tried to upgrade from hmatrix 0.15.2.1 to hmatrix-0.16.0.4 and both cabal install and cabal configure complained about missing blas and lapack libraries. However, I do have those libraries installed, and I passed their locations through --extra-include-dirs and --extra-lib-dirs with no results.

I use cabal 1.20.0.3, ghc 7.8.2 and gcc 4.4.4 on a Slackware-13.1 64-bit linux box.

Any idea of what is going wrong (and how to correct it?)

Thanks,
Adrian-Victor.

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Wolfgang Jeltsch | 15 Aug 22:10 2014

Rules for class methods and Safe Haskell

Hi,

the module Control.Arrow declares a set of rules for the Arrow class. It
is marked “Trustworthy”, probably to allow these rules to actually fire.

Now these rules are only correct for class instances that actually
satisfy the arrow laws. If the author of another module defines an
instance of Arrow that does not respect the laws, this other module
could still be considered “Safe” by GHC, although the rules from
Control.Arrow are bogus now.

Is this considered a problem?

All the best,
Wolfgang

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Wolfgang Jeltsch | 15 Aug 22:04 2014

Are safe coercions safe in the sense of Safe Haskell?

Hi,

I would expect the function

    coerce :: Coercible a b => a -> b

to be safe in the sense of Safe Haskell. However, the Data.Coerce module
is marked “Unsafe”. The coerce function is also available via GHC.Exts
and GHC.Prim. The former module is marked “Unsafe”, but the latter is
(surprisingly) marked “Safe-Inferred”.

What are the reasons behind this?

All the best,
Wolfgang

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Picon
Picon

'import ccall unsafe' and parallelism

Greetings everybody,

I happen to be a bit confused with regards to unsafe foreign imports and
parallelism.

Assume the following C function:

foreign import ccall unsafe "cfun"
  cfun :: CInt -> IO ()

Now, cfun does some work:

go xs = unsafePerformIO $ do
  forM_ xs $ cfun
  return $ somethingUnhealthy

And I'd like to parallelize this:

parMap rdeepseq go [costly,costly]

However, due to the way ghc handles unsafe imports, namely block
everything else whenever 'cfun' is called, I happen to have only one
active 'go'. Lets assume 'cfun' is cheap and would suffer from 'ccall
safe' more than I'd be willing to pay.

Is there any fix possible?

Viele Gruesse,
Christian

PS: The real problem happens to use a bunch of different judy arrays,
each of which lives in its on thread; 300 judy arrays, 300 threads, each
up to 20 million inserts. But I think the basic problem can be reduced
to "how to parallelize 'ccall unsafe's.
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Michael Jones | 13 Aug 06:44 2014

Odd FFI behavior

I have some strange behavior with GHC 7.6.3 on Ubuntu 14 TLS when using FFI and I am looking for some ideas on
what could be going on.

Fundamentally, adding wait calls (delays coded in the C) changes the behavior of the C, in that returned
status codes have proper values when there are delays, and return errors when there are no delays. But
these same calls result in proper behavior on the Aardvark’s serial bus, return proper data, etc. Only
the status get’s messed up.

The module calls a thin custom C layer over the Aaardvark C layer, which dynamically loads a dll and makes
calls into it. The thin layer just makes the use of c2hs eaiser.

It is always possible there is some kind of memory issue, but there is no pattern to the mishap. It is random.
Adding delays just changes probabilities of bad status.

I made a C version of my application calling the same custom C layer, and there are no problems. This sort of
indicates the problem is with the FFI.

Because the failures are not general in that they target one particular value, and seem to be affected by
time, it makes me wonder if there is some subtle Haskell run time issue. Like, could the garbage collector
be interacting with things?

Does anyone have an idea what kind of things to look for?

Mike

DLL loader

static void *_loadFunction (const char *name, int *result) {
    static DLL_HANDLE handle = 0;
    void * function = 0;

    /* Load the shared library if necessary */
    if (handle == 0) {
        u32 (*version) (void);
        u16 sw_version;
        u16 api_version_req;

        _setSearchPath();
        handle = dlopen(SO_NAME, RTLD_LAZY);
        if (handle == 0) {
#if API_DEBUG
            fprintf(stderr, "Unable to load %s\n", SO_NAME);
            fprintf(stderr, "%s\n", dlerror());
#endif
            *result = API_UNABLE_TO_LOAD_LIBRARY;
            return 0;
        }

        version = (void *)dlsym(handle, "c_version");
        if (version == 0) {
#if API_DEBUG
            fprintf(stderr, "Unable to bind c_version() in %s\n",
                    SO_NAME);
            fprintf(stderr, "%s\n", dlerror());
#endif
            handle  = 0;
            *result = API_INCOMPATIBLE_LIBRARY;
            return 0;
        }

        sw_version      = (u16)((version() >>  0) & 0xffff);
        api_version_req = (u16)((version() >> 16) & 0xffff);
        if (sw_version  < API_REQ_SW_VERSION ||
            API_HEADER_VERSION < api_version_req)
        {
#if API_DEBUG
            fprintf(stderr, "\nIncompatible versions:\n");

            fprintf(stderr, "  Header version  = v%d.%02d  ",
                    (API_HEADER_VERSION >> 8) & 0xff, API_HEADER_VERSION & 0xff);

            if (sw_version < API_REQ_SW_VERSION)
                fprintf(stderr, "(requires library >= %d.%02d)\n",
                        (API_REQ_SW_VERSION >> 8) & 0xff,
                        API_REQ_SW_VERSION & 0xff);
            else
                fprintf(stderr, "(library version OK)\n");

                   
            fprintf(stderr, "  Library version = v%d.%02d  ",
                    (sw_version >> 8) & 0xff,
                    (sw_version >> 0) & 0xff);

            if (API_HEADER_VERSION < api_version_req)
                fprintf(stderr, "(requires header >= %d.%02d)\n",
                        (api_version_req >> 8) & 0xff,
                        (api_version_req >> 0) & 0xff);
            else
                fprintf(stderr, "(header version OK)\n");
#endif
            handle  = 0;
            *result = API_INCOMPATIBLE_LIBRARY;
            return 0;
        }
    }

    /* Bind the requested function in the shared library */
    function = (void *)dlsym(handle, name);
    *result  = function ? API_OK : API_UNABLE_TO_LOAD_FUNCTION;
    return function;
}
cheater00 . | 6 Aug 16:18 2014
Picon

cabal repl failing silently on missing exposed-modules

Hi,
I have just spent some time trying to figure out why all of a sudden
"cabal repl" silently exits without an error message. What helped was
to take a project that could launch the repl and compare the cabal
files to my new project. It turns out the exposed-modules entry was
missing. I was wondering whether this behaviour was intentional, as I
don't recollect this happening before, but I don't have older systems
to test this on.

The reason I wanted to run a repl without editing exposed modules was
to test some dependencies I pulled in to the sandbox with cabal
install. The package in question didn't have any code of its own yet.
In this case I would just expect ghci to load with the Prelude.

Thanks!
Volker Wysk | 5 Aug 18:41 2014
Picon

Old code broken by new Typeable class

Hi!

I've been working with GHC-4.6.3, and updating to GHC-4.8.3 breaks my code, 

because the Typeable class has been changed. The compiler produces this 

message:

---------

src/HsShellScript/ProcErr.chs:2294:4:

    ‘typeOf’ is not a (visible) method of class ‘Typeable’

---------

I want to define System.Posix.Process.ProcessStatus to be an instance of 

Typeable, so I can throw and catch it as an exception. ProcessStatus isn't 

typeable by default.

Is it still possible to make ProcessStatus a member of Typeable? How? 

Obviously, you can't accomplish it by deriving Typeable, because the definition 

can't be changed any longer.

This is the spot in question:

----------

import System.Posix.Process

import Data.Typeable

{-

data ProcessStatus = Exited ExitCode

                   | Terminated Signal

                   | Stopped Signal

                   deriving (Eq, Ord, Show)

-}

instance Typeable ProcessStatus where

   typeOf = const tyCon_ProcessStatus

tyCon_ProcessStatus = mkTyConApp (mkTyCon3 "hsshellscript"

                                           "HsShellScript.ProcErr"

                                           "Posix.ProcessStatus") []

instance Exception ProcessStatus

----------

Thanks,

V.W.

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Krzysztof Skrzętnicki | 29 Jul 12:59 2014
Picon

Re: Overlapping and incoherent instances

I think it may also lead to cleaner code. I would rather write a single section like this:

#if NEW_GHC
{-# bunch of OVERLAPPABLE declarations #-}
#endif

at the start of the file rather than have to insert a lot of CPP-guarded pragmas later. But it may be seen as an editor/IDE issue and bikeshedding on the whole.

--
Krzysztof


On Tue, Jul 29, 2014 at 12:48 PM, Johan Tibell <johan.tibell <at> gmail.com> wrote:
On Tue, Jul 29, 2014 at 12:37 PM, Daniel Trstenjak
<daniel.trstenjak <at> gmail.com> wrote:
>
> On Tue, Jul 29, 2014 at 12:02:19PM +0200, Johan Tibell wrote:
>> What's the rationale to not require
>>
>> {-# OVERLAPPING Show [Char] #-}
>>
>> here? Perhaps it's too annoying to have to repeat the types?
>
> This one might be written at the top of the file, so it would be easier
> to overlook it, than having it directly at the instance declaration,
> which seems to be one of the major points for OVERLAPPING and OVERLAPPABLE.

The same could be said for e.g. INLINE. The extra flexibility is nice
to have (e.g. because you can opt to put the pragma after the
declaration, to de-emphasize it.)
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Simon Peyton Jones | 29 Jul 11:11 2014
Picon

Overlapping and incoherent instances

Friends

One of GHC’s more widely-used features is overlapping (and sometimes incoherent) instances.  The user-manual documentation is here.

The use of overlapping/incoherent instances is controlled by LANGUAGE pragmas: OverlappingInstances and IncoherentInstances respectively.

However the overlap/incoherent-ness is a property of the *instance declaration* itself, and has been for a long time.  Using LANGUAGE OverlappingInstances simply sets the “I am an overlapping instance” flag for every instance declaration in that module.

This is a Big Hammer.  It give no clue about *which* particular instances the programmer is expecting to be overlapped, nor which are doing the overlapping.    It brutally applies to every instance in the module.  Moreover, when looking at an instance declaration, there is no nearby clue that it might be overlapped.  The clue might be in the command line that compiles that module!

Iavor has recently implemented per-instance-declaration pragmas, so you can say

instance {-# OVERLAPPABLE #-} Show a => Show [a] where …

instance {-# OVERLAPPING #-} Show [Char] where …

This is much more precise (it affects only those specific instances) and it is much clearer (you see it when you see the instance declaration).

This new feature will be in GHC 7.10 and I’m sure you will be happy about that.  But I propose also to deprecate the LANGUAGE pragmas OverlappingInstances and IncoherentInstances, as way to encourage everyone to use the new feature instead of the old big hammer.  The old LANGUAGE pragmas will continue to work, of course, for at least another complete release cycle.  We could make that two cycles if it was helpful.

However, if you want deprecation-free libraries, it will entail a wave of library updates.

This email is just to warn you, and to let you yell if you think this is a bad idea.   It would actually not be difficult to retain the old LANGUAGE pragmas indefinitely – it just seems wrong not to actively push authors in the right direction.

These deprecations of course popped up in the test suite, so I’ve been replacing them with per-instance pragmas there too.  Interestingly in some cases, when looking for which instances needed the pragmas, I found…none. So OverlappingInstances was entirely unnecessary.  Maybe library authors will find that too!

Simon

_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users <at> haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
p.k.f.holzenspies | 23 Jul 18:06 2014
Picon
Picon

GhcPlugin-writing and "finding things"

Dear GHC-ers,

I'm working on a plugin for GHC that should help compile the library with which this plugin is to ship. What
this plugin does is traverse the CoreProgram(s) to find things of types defined in my library and
optimizes them. I have worked out how to "find" things, but I was wondering whether the API could be
improved for plugin-writers.

For the sake of argument, I have the following:
 - module Foo: library for users to import, containing functions, ADTs etc
 - module Foo.Plugin: GhcPlugin that compiles out all uses of things in Foo

> module Foo where
>
> data Foo x = Foo x
>
> runFoo :: Foo x -> x
> runFoo (Foo x) = x

This example is trivial and I imagine GHC will have no trouble eliminating most cases of this, but imagine
more complex stuff. Now, if I want to traverse the CoreProgram in my plugin, I need to find occurrences of
these, so somewhere there's stuff like:

> pass tcFoo _ _ (NonRec b expr)
>   | varType b `containsTyConAnywhere` tcFoo
>     = {- clever stuff to compile out Foo -}

My problem is "getting" tcFoo in this example. Below is how I do it now. Maybe I'm being thick, or maybe
there's just no simpler way. This is my 'plugin' function in Foo.Plugin:

> plugin = Plugin $ \opts todo -> do
>  hsc <- getHscEnv
>  dfs <- getDynFlags
>  fr  <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing
>  mod <- case fr of
>    Found ml m -> return m
>    _ -> panic "Failed to (unambiguously) find 'Foo' (using findImportedModule)"
>  onc <- getOrigNameCache
>  let nms = lookupWithDefaultModuleEnv nms (panic "No names defined for module 'Foo'") mod
>      find_ d occ fnd nm
>        = maybe
>            (fail $ "Failed to find " ++ d ++ " '" ++ nm ++ "'")
>            fnd
>            (lookupOccEnv nms $ occ nm)
>      tcFind = find_ "TyCon"   mkTcOcc   lookupTyCon
>      dcFind = find_ "DataCon" mkDataOcc lookupDataCon
>      idFind = find_ "Id"      mkVarOcc  lookupId
>  tcFoo    <- tcFind "Foo"
>  dcFoo    <- dcFind "Foo"
>  idRunFoo <- idFind "runFoo"
>  return $ CoreDoPluginPass "Foo optimisation" (pass tcFoo dcFoo idRunFoo) : todo

I have the following questions:

  1) Is this a/the right way to "find" those things in the plugin?
  2) There seems to be a lot to gain with quasi-quoting a la Template Haskell for people writing plugins to go
with a library that they wrote. Can such QQ be done? Has it been considered?
  3) Is findImportedModule the right function to find my starting point to begin with?
  4) What is the 'Maybe FastString' argument in findImportedModule for? I've been trying to put in the FSs of
PackageIDs, but they make the lookup fail. This (dumb) example really made me nervous:

>  fr  <- liftIO $ findImportedModule hsc (mkModuleName "Foo") Nothing
>  mod <- case fr of
>    Found ml m -> do
>      fr' <- liftIO $ findImportedModule hsc (moduleName m) (packageIdFS $ packageId m)

Here, fr' should always be a "Found ml' m'" such that ml == ml' and m == m', but... it consistently results in
NotFound{} for me. Also, I find this especially round-about. Shouldn't Paths_Foo.hs (the
Cabal-generated file) maybe contain variables for every module in the package? In my case it would thus
contain some "modFoo :: Module"

Comments and suggestions more than welcome!

Regards,
Philip
Jan Stolarek | 23 Jul 13:57 2014
Picon

Looking for list comprehensions use cases

Haskellers,

recently I've been looking into the possibility of creating some new optimisations for GHC. These 
would be mostly aimed at list comprehensions. Here's where I need your help:

1. Do you have complex list comprehensions usage examples from real code? By complex I mean  
nested list comprehensions, reading from more than one list ([ ...| x <- xs, y <- ys ... ]) etc.

2. Do you have list comprehensions code that you had to optimize by hand because GHC was unable to 
make them fast enough?

Janek

Gmane