Re: ghci 7.4.1 no longer loading .o files?
On 02/20/2012 10:46 AM, Evan Laforge wrote: Is there something that changed in 7.4.1 that would cause it to decide to interpret .hs files instead of loading their .o files? E.g.: I don't *know* but could this have anything to do with this? http://hackage.haskell.org/trac/ghc/ticket/5878 Eugene signature.asc Description: OpenPGP digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Removal of #include HsFFI.h from template-hsc.h breaks largefile support on 32bit Linux
I don't know enough to understand if the hard troubles described by John Meacham are real, but I think that even if they are not, the current situation violates the principle of least surprise for the author of a module. Such author may be unaware of the need to take special steps to make his module use the same file API as the builtin language functions, and that will lead to situations when the modules bundled with the compiler can deal with 4Gb files but the new module cannot. It may be even worse for instance with respect to reentrancy of the code: the author of the module may not realize that he needs to take special steps or e.g. the handling of errno will be broken in multithreaded environment. In extreme case, even the opposite situation is possible: the module's autoconf may detect some obscure incompatible feature of the system that the base build did not know about (even if this is a pure theoretical danger). I think it would be a right thing to provide the author of an external module with baseline C environment by default, compatible with the environment under which the modules bundled with the compiler where built. And on top of that, allow them to use autoconf/whatever else to deviate from that if they need to. Eugene signature.asc Description: OpenPGP digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Removal of #include HsFFI.h from template-hsc.h breaks largefile support on 32bit Linux
Hello Simon, thanks for your attention :) On 02/16/2012 04:25 PM, Simon Marlow wrote: I found that earlier versions of hsc2hs included HsFFI.h into the [...] As I understand, this situation means that while the ghc itself and haskell programs compiled by it are largefile-capable, any third party modules that contain .hsc files are not. If I am right, this is probably not a good thing. We discovered this during the 7.4 cycle: http://hackage.haskell.org/trac/ghc/ticket/2897#comment:12 Packages that were relying on `HsFFI.h` to define `_FILE_OFFSET_BITS` should no longer do this, instead they should use an appropriate autoconf script or some other method. See the `unix` package for an example of how to do this. It was really a mistake that it worked before. But that means that the C build environment has to be constructed independently for each module (that needs it), and consequently is not guaranteed to match the compiler's environment. Would it be better (more consistent) to propagate GHC's (or other compiler's) environment by default, along the lines of the comment #16? To cite Duncan, each Haskell implementation has its own C environment, and hsc2hs must use that same environment or it will produce incorrect results. Just a thought, and, as I said, I am not really qualified to argue... Eugene signature.asc Description: OpenPGP digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Removal of #include HsFFI.h from template-hsc.h breaks largefile support on 32bit Linux
Hello all, I am new here, but I want to report what I suspect may be a problem. I ran into it while using some third-party package from hackage on a 32bit Linux with ghc 7.4.1. I discovered that off_t fields in the .hsc files in the package where interpreted as 32bit words. I suspected that 64bit offsets should be used because even 32bit Linux has largefile support with 64bit offsets. I found that earlier versions of hsc2hs included HsFFI.h into the generated C code, and HsFFI.h in turn indirectly includes ghcautoconf.h which has #define _FILE_OFFSET_BITS 64 in it. So, if I build the .hsc files like this: hsc2hs -i HsFFI.h filename.hsc then off_t is 64bit and 64bit file manipulation syscalls are used. I did not check it but I think that earlier versions of hsc2hs where creating largefile-aware version of the code by default, because HsFFI.h was included in the code by default. This is a simple test program: checktypes.hsc -- run like this: hsc2hs checktypes.hsc runhaskell checktypes.hs module Main where #include sys/types.h main = do putStrLn $ show (#size off_t) $ hsc2hs checktypes.hsc runhaskell checktypes.hs 4 $ hsc2hs -i HsFFI.h checktypes.hsc runhaskell checktypes.hs 8 As I understand, this situation means that while the ghc itself and haskell programs compiled by it are largefile-capable, any third party modules that contain .hsc files are not. If I am right, this is probably not a good thing. Please can some guru take a look at this issue? See also: http://www.haskell.org/pipermail/glasgow-haskell-users/2009-February/016606.html http://www.haskell.org/pipermail/cvs-ghc/2011-September/065848.html Thanks, Eugene signature.asc Description: OpenPGP digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: recent changes to hsc2hs break wrapping c++
On 02/15/2012 09:59 PM, Evan Laforge wrote: Unfortunately, the result is I (apparently) can't use it now. Here's how that happens: The change was to remove the dependency on HsFFI.h. Evan, *if* including HsFFI.h is the only thing you need, you might try to add -i HsFFI.h to your hsc2hs rule. The problem still stands because we cannot expect every module author to do the same. Disclaimer: I am in no way expert, what I am saying is a result of layman's investigation and may be far off the mark. Eugene signature.asc Description: OpenPGP digital signature ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Gtk2hs-users] GHC 7.4+ rts_evalIO
Axel, See my recent email to gtk2hs-users, I already proposed a fix for this. 28.01.2012, в 17:36, Axel Simon axel.si...@in.tum.de написал(а): Dear ghc developers, there seems to be a change in the C functions of ghc. How do we fix this? Is there some guide as to what has changed? Thanks, Axel Begin forwarded message: From: Andriy Polishchuk andriy.s.polishc...@gmail.com Date: 27. Januar 2012 03:36:50 MEZ To: gtk2hs-us...@lists.sourceforge.net Subject: [Gtk2hs-users] GHC 7.4+ rts_evalIO Hello, I'm newbie in haskell, so didn't got success bumping package manually. With new GHC gtk does not build with the following error: System\Glib\hsgclosure.c:110:5: warning: passing argument 1 of 'rts_evalIO' from incompatible pointer type S:\prog\lang.haskell\ghc\lib/include/RtsAPI.h:202:6: note: expected 'struct Capability **' but argument is of type 'str ct Capability *' Are there any simple workarounds or it's hard stuff and it's better for me to wait new release? The reason I want to hack with new GHC is that on windows there is fixed bug with ghci that doesn't allow to interactively link related libraries. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Gtk2hs-users mailing list gtk2hs-us...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GIO.012.0 installation
Hi, This means that you don't have a native gio package - it's not a haskell package. Cabal does not currently integrate with native package managers and it can only tell you that a package is required but missing. I think gio is part of glib - for example, on Ubuntu you'd do sudo apt-get install libglib2.0-0 libglib2.0-dev 2010/12/21 Aswad, Mustafa mk...@hw.ac.uk: Hi dear; I am try to build Gio package using cabal version cabal-install version 0.8.2 and Ghc version version 6.12.3. Bu I got such error which I can not solve it setup: The pkg-config package gio-2.0 version =2.16.4 is required but it could not be found. Could any of you till me how come this problem. thanks Heriot-Watt University is a Scottish charity registered under charity number SC000278. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Eugene Kirpichov Senior Software Engineer, Grid Dynamics http://www.griddynamics.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Problem starting GHC 6.4 on windows 98
Sigbjorn Finne sof at galois.com writes: Expect to see an updated installer sometime early next week. Could it be something like patch to the installer or already installed ghc 6.4? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
