Link failure

[Simon Peyton Jones]

On 64-bit Linux I'm getting this in the link step for the template-haskell 
library:

/usr/bin/ld: 
libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.dyn_o: 
relocation R_X86_64_PC32 against undefined symbol 
`templatezmhaskell_LanguageziHaskellziTHziSyntax_OccName_closure' can not be 
used when making a shared object; recompile with -fPIC

/usr/bin/ld: final link failed: Bad value

collect2: ld returned 1 exit status

make[2]: *** 
[libraries/template-haskell/dist-install/build/libHStemplate-haskell-2.10.0.0-ghc7.9.20140416.so]
 Error 1

make[1]: *** [all_libraries/template-haskell] Error 2

make[1]: Leaving directory `/5playpen/simonpj/HEAD-1'
My compiler is not vanilla HEAD, but I have changed only stuff in the Core 
simplifier, nothing in the back end.
Does anyone have the faintest idea what is going on? It's extremely annoying 
because I can't make progress without working around it somehow.
Thanks
Simon


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Link failure

[Simon Peyton Jones]

sorry, ignore me - I assume it's #8696 and my tree is fairly old.  I'll update.

Simon

From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Simon Peyton 
Jones
Sent: 17 April 2014 08:07
To: ghc-devs@haskell.org
Subject: Link failure

On 64-bit Linux I'm getting this in the link step for the template-haskell 
library:

/usr/bin/ld: 
libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.dyn_o: 
relocation R_X86_64_PC32 against undefined symbol 
`templatezmhaskell_LanguageziHaskellziTHziSyntax_OccName_closure' can not be 
used when making a shared object; recompile with -fPIC

/usr/bin/ld: final link failed: Bad value

collect2: ld returned 1 exit status

make[2]: *** 
[libraries/template-haskell/dist-install/build/libHStemplate-haskell-2.10.0.0-ghc7.9.20140416.so]
 Error 1

make[1]: *** [all_libraries/template-haskell] Error 2

make[1]: Leaving directory `/5playpen/simonpj/HEAD-1'
My compiler is not vanilla HEAD, but I have changed only stuff in the Core 
simplifier, nothing in the back end.
Does anyone have the faintest idea what is going on? It's extremely annoying 
because I can't make progress without working around it somehow.
Thanks
Simon


___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

RE: Git problem

[Simon Peyton Jones]

Thank you – that’s helpful.  It’s the mental model that I miss!

Simon

From: Iavor Diatchki [mailto:iavor.diatc...@gmail.com]
Sent: 16 April 2014 16:44
To: Herbert Valerio Riedel
Cc: Simon Peyton Jones; ghc-devs
Subject: Re: Git problem

Hello,

I think the commands Herbert suggested should help.  I find it useful to have a 
mental model of what's going on with git, so here is a brief explanation, in 
case it is useful.

The main observation is that Git not only keeps track of the state of all files 
in the repo, but also the states of all related repositories (aka, the 
sub-modules).  So this is probably what happened:

1. `git stash`: Git remembered which files were modified, and the current 
commit for `haddock` (and other sub-modules)
2. `git pull`: Git got some changes for the remote server, and it happened that 
the current commit for `haddock` changed.
3. `git pop`: Git needs to apply the saved changes but in the new setting.   It 
managed to automatically merge the modified files, but it does not know which 
is the correct current commit for haddock: do you want to use the newly 
downloaded version, or the one that was saved when you created the stash?

So Herbert's commands tell it what to do:  the first command tells it to set 
the current commit for haddock to the one in the remote repo (i.e., you are not 
interested in the stashed version);   the second command tells it to remember 
this, so that the change will be committed later.

Cheers,
-Iavor











On Mon, Apr 14, 2014 at 2:47 AM, Herbert Valerio Riedel 
mailto:hvrie...@gmail.com>> wrote:
On 2014-04-14 at 11:13:02 +0200, Simon Peyton Jones wrote:

[...]

> #both modified:  utils/haddock

> The modified files are right.  It's the "both modified utils/haddock" that is 
> messing me up.
> I'm not modifying haddock!  I just want to say "take the master haddock", but 
> I don't know how.  I tried 'git checkout utils/haddock' but that just led do 
> `git status' saying
>
> #modified:   utils/haddock (new commits)
Fyi, the git equivalent of saying "take the master haddock" (where
'master' refers to 'master' of 'haddock.git'):

  # checkout master of haddock.git:
  git submodule update --remote utils/haddock

  # register state (= submod commit-id) of utils/haddock for next commit
  git add utils/haddock

HTH, hvr
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Proposal - Foreign enum support

[Merijn Verstraaten]

Cross-post to haskell-prime in case there's any interest for including this 
into the report's FFI specification.

Proposal - Foreign enum support
===

At the moment the FFI does not have a convenient way with interacting enums
(whether proper enums or CPP defines) in C (like languages). Both enums and CPP
defined enums are major parts of large C APIs and they are thus crucial to
writing foreign bindings. A few examples:

SDL_image defines the following enum:

typedef enum {
IMG_INIT_JPG = 0x0001,
IMG_INIT_PNG = 0x0002,
IMG_INIT_TIF = 0x0004,
IMG_INIT_WEBP = 0x0008
} IMG_InitFlags;

OpenCL specifies the following typedefs + CPP defined enum:

typedef uint32_t  cl_uint __attribute__((aligned(4)));
typedef cl_uint   cl_platform_info;

/* cl_platform_info */
#define CL_PLATFORM_PROFILE 0x0900
#define CL_PLATFORM_VERSION 0x0901
#define CL_PLATFORM_NAME0x0902
#define CL_PLATFORM_VENDOR  0x0903
#define CL_PLATFORM_EXTENSIONS  0x0904

OpenCL functions will return the above CPP defines as return values of type
cl_platform_info.

Current Solutions
-

In many cases someone wrapping such a C library would like to expose these
enums as a simple sum type as this has several benefits: type safety, the
ability to use haskell constructors for pattern matching, exhaustiveness
checks.

Currently the GHC FFI, as specified by Haskell2010, only marshalls a small set
of foreign types and newtypes with exposed constructors of these types. As such
there seem two approaches to wrap these enums:

 1. Implement an ADT representing the enum and write a manual conversion
function between the ADT and the corresponding C type (e.g. CInt -> Foo and
Foo -> CInt).

 2. Use a tool like c2hs to automatically generate the ADT and conversion
function.

In both cases the foreign functions are imported using the corresponding C type
in their signature (reducing type safety) and the user is forced write trivial
wrappers for every imported function to convert the ADT to the relevant C type
and back.

This is both tedious to write and costly in terms of code produced, in case of
c2hs one calls "toEnum . fromIntegral" and "fromIntegral . fromEnum" for every
argument/result even though this could trivially be a no-op.

Worse, since c2hs uses the Enum class for it's conversion to/from C types it
generates Enum instances like:

instance Enum Foo where
fromEnum Bar = 1
fromEnum Baz = 1337

toEnum 1 = Bar
toEnum 1337 = Baz
toEnum unmatched = error ("PlatformInfo.toEnum: Cannot match " ++ show 
unmatched)

Since succ/pred and enumFromTo's default implementations assume enums convert
to continuous sequence of Int this means the default generated enum instances
crash. This problem could be overcome by making c2hs' code generation smarter,
but this does not eliminate the tediousness of wrapping all foreign imported
functions with marshalling wrappers, NOR does it eliminate the overhead of all
this useless marshalling.

Proposal


Add a new foreign construct for enums, the syntax I propose below is rather
ugly and ambiguous and thereforeopen to bikeshedding, but I prefer explaining
based on a concrete example.

foreign enum CInt as Foo where
Bar = 1
Baz
Quux = 1337
Xyzzy = _

This would introduce a new type 'Foo' with semantics approximately equivalent
too "newtype Foo = Foo CInt" plus the pattern synonyms "pattern Bar = Foo 1;
pattern Baz = 2; pattern Quux = 1337; pattern Xyzzy = Foo _".

Explicit listing of the value corresponding to a constructor should be
optional, missing values should just increment by one from the previous (like
C), if the initial value is missing, it should assume to start from 0. Values
do not need to be contiguous.

Users should be able to use these constructors as normal in pattern match
(really, this mostly follows to semantics of the above pattern synonyms).

The foreign import/export functionality should invisibly marshall Foo to the
underlying foreign type (as is done for newtypes).

I'm unsure about the support for a wildcard constructor like Xyzzy. If there is
support for a wildcard, it should be optional. On the upside a wildcard means
the marshalling is no longer a partial function. The downside is that it makes
desugaring the use of enums in patterns harder. It seems clear that

f Xyzzy = {- ... -}
f Bar = {- ... -}
f Baz = {- ... -}
f Quux = {- ... -}

Should not have the same semantics as:

f (Foo _) = {- ... -}
f (Foo 1) = {- ... -}
f (Foo 2) = {- ... -}
f (Foo 1337) = {- ... -}

So in the presence of wildcards, the Foo enum can't trivially be desugared into
pattern synonyms after checking exhaustiveness.

Pros:
 1. Foreign imports are sli

Re: Proposal - Foreign enum support

[Roman Cheplyaka]

I am reluctant about adding a new syntactic feature for such a niche problem.

Can't this be achieved with a quaiquoter?

Roman


signature.asc
Description: Digital signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Proposal - Foreign enum support

[Carter Schonwald]

Agreed.  A quasiquoter is the right approach here.

On Thursday, April 17, 2014, Roman Cheplyaka  wrote:

> I am reluctant about adding a new syntactic feature for such a niche
> problem.
>
> Can't this be achieved with a quaiquoter?
>
> Roman
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Proposal - Foreign enum support

[John Lato]

I wouldn't be keen on adding such a specific feature to the language
either.  Another concern is that this proposal doesn't seem to address a
very common use case for C enums, bit vectors.  IMHO any FFI proposal for
working with C enums should take that idiom into account.
On Apr 17, 2014 7:19 AM, "Merijn Verstraaten" 
wrote:

> Cross-post to haskell-prime in case there's any interest for including
> this into the report's FFI specification.
>
> Proposal - Foreign enum support
> ===
>
> At the moment the FFI does not have a convenient way with interacting enums
> (whether proper enums or CPP defines) in C (like languages). Both enums
> and CPP
> defined enums are major parts of large C APIs and they are thus crucial to
> writing foreign bindings. A few examples:
>
> SDL_image defines the following enum:
>
> typedef enum {
> IMG_INIT_JPG = 0x0001,
> IMG_INIT_PNG = 0x0002,
> IMG_INIT_TIF = 0x0004,
> IMG_INIT_WEBP = 0x0008
> } IMG_InitFlags;
>
> OpenCL specifies the following typedefs + CPP defined enum:
>
> typedef uint32_t  cl_uint __attribute__((aligned(4)));
> typedef cl_uint   cl_platform_info;
>
> /* cl_platform_info */
> #define CL_PLATFORM_PROFILE 0x0900
> #define CL_PLATFORM_VERSION 0x0901
> #define CL_PLATFORM_NAME0x0902
> #define CL_PLATFORM_VENDOR  0x0903
> #define CL_PLATFORM_EXTENSIONS  0x0904
>
> OpenCL functions will return the above CPP defines as return values of type
> cl_platform_info.
>
> Current Solutions
> -
>
> In many cases someone wrapping such a C library would like to expose these
> enums as a simple sum type as this has several benefits: type safety, the
> ability to use haskell constructors for pattern matching, exhaustiveness
> checks.
>
> Currently the GHC FFI, as specified by Haskell2010, only marshalls a small
> set
> of foreign types and newtypes with exposed constructors of these types. As
> such
> there seem two approaches to wrap these enums:
>
>  1. Implement an ADT representing the enum and write a manual conversion
> function between the ADT and the corresponding C type (e.g. CInt ->
> Foo and
> Foo -> CInt).
>
>  2. Use a tool like c2hs to automatically generate the ADT and conversion
> function.
>
> In both cases the foreign functions are imported using the corresponding C
> type
> in their signature (reducing type safety) and the user is forced write
> trivial
> wrappers for every imported function to convert the ADT to the relevant C
> type
> and back.
>
> This is both tedious to write and costly in terms of code produced, in
> case of
> c2hs one calls "toEnum . fromIntegral" and "fromIntegral . fromEnum" for
> every
> argument/result even though this could trivially be a no-op.
>
> Worse, since c2hs uses the Enum class for it's conversion to/from C types
> it
> generates Enum instances like:
>
> instance Enum Foo where
> fromEnum Bar = 1
> fromEnum Baz = 1337
>
> toEnum 1 = Bar
> toEnum 1337 = Baz
> toEnum unmatched = error ("PlatformInfo.toEnum: Cannot match " ++
> show unmatched)
>
> Since succ/pred and enumFromTo's default implementations assume enums
> convert
> to continuous sequence of Int this means the default generated enum
> instances
> crash. This problem could be overcome by making c2hs' code generation
> smarter,
> but this does not eliminate the tediousness of wrapping all foreign
> imported
> functions with marshalling wrappers, NOR does it eliminate the overhead of
> all
> this useless marshalling.
>
> Proposal
> 
>
> Add a new foreign construct for enums, the syntax I propose below is rather
> ugly and ambiguous and thereforeopen to bikeshedding, but I prefer
> explaining
> based on a concrete example.
>
> foreign enum CInt as Foo where
> Bar = 1
> Baz
> Quux = 1337
> Xyzzy = _
>
> This would introduce a new type 'Foo' with semantics approximately
> equivalent
> too "newtype Foo = Foo CInt" plus the pattern synonyms "pattern Bar = Foo
> 1;
> pattern Baz = 2; pattern Quux = 1337; pattern Xyzzy = Foo _".
>
> Explicit listing of the value corresponding to a constructor should be
> optional, missing values should just increment by one from the previous
> (like
> C), if the initial value is missing, it should assume to start from 0.
> Values
> do not need to be contiguous.
>
> Users should be able to use these constructors as normal in pattern match
> (really, this mostly follows to semantics of the above pattern synonyms).
>
> The foreign import/export functionality should invisibly marshall Foo to
> the
> underlying foreign type (as is done for newtypes).
>
> I'm unsure about the support for a wildcard constructor like Xyzzy. If
> there is
> support for a wildcard, it should be optional. On the upside

Re: GHC's performance

[Michał J Gajda]

Dear Friends,

I have a few weeks free just now, and a keen interest in GHC performance,
so please count me in as a person interested in developing the solution :-).

On Thu, Apr 10, 2014 at 5:57 PM, Johan Tibell wrote:

> There are a few "projects" in this area I think we should undertake:
>
> ## Set up a performance dashboard
>
> Example: http://goperfd.appspot.com/ (try clicking the "Perf" and
> "Graphs" buttons.)
>
> I think the way to go here is:
>
>  * Figure out how to build GHC and run the nofib suite in a repeatable
> (i.e. scripted) manner.
>

Wouldn't it be faster to take GHC builds from the current builder?
I understand that running GHC build for each commit may take some time...
Where would be put the infrastructure?
I could help to set it up, but I do not possess enough CPU power to hold it
for a long time.

I do not know how current builders are set up, and if it would be possible
to indicate some of them as having exclusivity for their machine. If so,
would it be better to add perf test and database submission as a last step
for the test suite?
As long as access is not anonymous (to prevent spam), such a database might
provide a better coverage of performance data over tier-2 architectures.
--
  Best regards
Michal
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs