Re: [Haskell-cafe] Serial Communications in Haskell
On 8/29/07, Ronald Guida [EMAIL PROTECTED] wrote: I'm on a Windows box and I'm looking for a way to talk to a serial port (for example, RS-232) from Haskell. I couldn't find a library to do this, so I am wondering how to create one. I have a fairly thorough understanding of how to open and use a serial port with the Windows API. In particular, to open a serial port, I At the moment, I think it is easier to just use the same Windows API directly, rather than try to bend GHC's IO system to do it right. have to use CreateFile, which is the same API call that opens files. In fact, if I call openFile from GHC, and pass COM1: as the filename, then I can get a writable serial port. module Serial where import System.IO main = do h - openFile COM1: ReadWriteMode hPutStrLn h Hello World I can't read from the port (I always get an immediate EOF), and I have no way of configuring things like the baud rate or the parity settings. Nevertheless, this demonstrates that openFile can at least open the serial port. What I would like to do is create some functions that would allow me to open and configure a serial port, and get a Handle back so that I can use the existing IO functions like hGetChar and hPutChar. I am assuming that hGetChar eventually calls win32::ReadFile and hPutChar eventually calls win32::WriteFile. These same two API calls would work for serial ports. Unfortunately, it goes via extra hoops and uses c runtime instead of Windows API directly. This extra layer makes sure it's hard to predict exactly what gets done (and with what options) sometimes. And even if it did, it'd probably use overlapping io, does that work with COM ports? In Windows, there are 23 API functions that apply specifically to serial ports. Out of these 23 functions, only a few of them are actually necessary if I just want to send and receive data. Of course, I don't know how to call Windows API functions from Haskell, and I have no idea how to hook things to the IO library so that I can use a Handle for a serial port. I'm looking for some advice on how to proceed. I haven't done much work on COM ports, but the little I did, I used bindings in Win32 and probably some of my own, and didn't use System.IO/Handle at all. Maybe problems with GHC's IO system are easy to solve, but I have no idea and wasn't inclined to find out. Best regards, Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: ANNOUNCE: Bamse 1.0
Hi, On 8/17/07, Sigbjorn Finne [EMAIL PROTECTED] wrote: Galois is pleased to announce the first public release of Bamse, a Windows Installer creator framework written in Haskell. Using Bamse, you can easily create applications that let you build Windows Installer (MSIs) for your project's product deliverables. The tool was written quite a while ago (4-5 years) as an internal tool at Galois to help the automated building of shippable bundles for Windows platforms, but has also been used for GHC installers since version 5.0.x (and other Haskell-related tools, interpreters and packages.) Cool :-) I wish I had known this was coming - I've been working recently on MSI generator for pre-compiled Cabal-packages, but it uses Wix tools, instead of foreign bindings to MSI interfaces. The source code + support package is available from http://galois.com/~sof/bamse/ Remarks/notes: - the source code is covered by a BSD license. - questions, bug reports to [EMAIL PROTECTED] / [EMAIL PROTECTED] (*) - If someone would like to adopt and extend the code to make it even more useful, feel free to dive in and hack. (Integrate it into the building of Cabal source and binary dists, perhaps..?) - If there's genuine interest, the code could be made available via a repo ( (*) being the main reason not to right now.) Best regards, Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: hyperlinked haskell 98 grammar
On 8/16/07, Neil Mitchell [EMAIL PROTECTED] wrote: In addition, perhaps this should be relocated to haskell.org, if your server is not suitable for a large volume of users. I think it should also be integrated somewhere (perhaps a link from the HTML report, and certainly on the wiki) Agreed, the page seems like an useful resource. :-) Best regards, Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] Re: trouble building 6.7 on ubuntu
On 8/16/07, Thomas Hartman [EMAIL PROTECTED] wrote: I repeated the install attempt described below using darcs head, including the extra libs. I got the exact same error as before. Setup: Warning: Unknown fields: nhc98-options (line 173) and then a cryptic error involving HsColour I think you run into Cabal bug - you need to remove (or upgrade?) HsColour in your path, if that's the case. Best regards, Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Visual Haskell will not Install with Visual Studio 2005, Express Edition
Hi, On 7/27/07, Sean Johnson [EMAIL PROTECTED] wrote: Is there some way to install Visual Haskell with VS2005, Express? Perhaps some workaround or hack? It's probably impossible. Feature matrix for Visual Studio products says Use 3rd party controls and content. No Macros, Add-ins or Packages. [1] Best regards, Esa [1] http://msdn2.microsoft.com/en-us/vstudio/aa700921.aspx ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Visual Haskell will not Install with Visual Studio 2005, Express Edition
Hi, On 7/27/07, Sean Johnson [EMAIL PROTECTED] wrote: Is there some way to install Visual Haskell with VS2005, Express? Perhaps some workaround or hack? It's probably impossible. Feature matrix for Visual Studio products says Use 3rd party controls and content. No Macros, Add-ins or Packages. [1] Best regards, Esa [1] http://msdn2.microsoft.com/en-us/vstudio/aa700921.aspx ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Nix for Hackage/Cabal
On 7/6/07, apfelmus [EMAIL PROTECTED] wrote: Duncan Coutts wrote: On Fri, 2007-07-06 at 16:47 +0200, apfelmus wrote: http://nix.cs.uu.nl/index.html I was under the impression that it didn't work on Windows. From another quick look at the website, it looks like that's right. Does anybody happen to know otherwise? I have no idea, but the manual states E.2. Release 0.10 (October 6, 2006) [...] - Added support for Cygwin (Windows, i686-cygwin), Mac OS X on Intel (i686-darwin) and Linux on PowerPC (powerpc-linux) Cygwin support might mean that native Windows support is still miles away, if possible at all, and assuming Cygwin is a huge leap. Best regards, Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Fwd: Re: [Haskell-cafe] avoiding command window with wxHaskell on Windows?
On 6/30/07, Duncan Coutts [EMAIL PROTECTED] wrote: On Fri, 2007-06-29 at 23:22 -0400, Dean Herington wrote: Date: Mon, 25 Jun 2007 20:19:50 -0400 With gtk2hs, using -optl-mwindows as a command line option for GHC lets me get rid of this window. Perhaps it will do the same for wxHaskell? Yes, that did the trick! Thanks a lot! But now I've discovered that using -optl-mwindows creates a program that doesn't work when invoked from a command line. Is there any way to create a program that can work when invoked either from a command line or through double-clicking? You'll have to be a bit more specific about what you mean. Perhaps you mean that when launched from the command line you cannot interact with the program via that command line interface. That is indeed standard windows behaviour. You can create new terminals at runtime using Win32 functions, but I'm not sure if you can figure out if the program was launched from a terminal and associate with that terminal. But perhaps you meant something else. Assuming it's not something else. As far as I know, the console/non-console application is marked in exe-header, and you can, in principle, have two entrypoints to a program, one for console and one without. Unfortunately that's not supported by most tools (and probably none outside Microsoft toolchains.) So, in practice, either you make console applications, or non-console application. And as Duncan says, you can open new console if you don't have one, but that will have different window than parent process had. Opening new console might also require some interfacing with haskell runtime system if you want to use default putStrLn and friends. I think I saw a library to help with that, but I can't find it right now. Best regards, Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Filesystem access
On 6/21/07, Andrew Coppin [EMAIL PROTECTED] wrote: OK, a few questions... 1. Is there *any* way to determine how large a file is *without* opening it? The only library function I can find to do with file sizes is hFileSize; obviously this only works for files that you have permission to open! I think you must open file in Windows to get the size for it, but I am not 100% sure. (That might be the reason you see sometimes files that are just created with size 0 even as process writes to them - file is locked.) 2. Is there any way to discover Windoze-style attributes for files? (Read-only, archive, system, hidden, et al.) Fraser posted some functions to help with this. However, those attributes are mostly outdated unless you are workin on old Windows. For real file rights, more in line with traditional unix right would be file ACLs. (There's useful flags there, too.) Unfortunately Security api isn't in Win32 package. Best regards, Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GHC Extensibility
On 6/3/07, Monique Monteiro [EMAIL PROTECTED] wrote: On 6/2/07, Esa Ilari Vuokko [EMAIL PROTECTED] wrote: For stage1, this can be solved by adding -package mtl to ghc command used to linking, for next stages, you'd need to add mtl to bootstrap cycle, I think. I have no idea how that is done. Borrowing code from mtl might be easier. GHC gives unknown package: mtl when I add this option. Should I download it separately? Maybe it needs version as well, mtl-1.0.1. You should have the package already as you managed to compile the haskell files. Best regards, Esa PS. The symbol names are partly z-encoded (you can find details in ghc sources) and partly contain compiler's invented bits. mtlzm1zi0zi1_ControlziMonadziStateziLazzy_zdf14_closure becomes mtl = mtl(ie package name) zm = - (dash to separate package name and version) 1zi0zi1 = 1.0.1 (version) _ = Some convention to put _ there. ControlziMonadziStateziLazzy = Control.Monad.State.Lazy (module) _zdf14_closure = closure number 14 (number is rather arbitary) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Extensibility
Hi, On 6/3/07, Monique Monteiro [EMAIL PROTECTED] wrote: Hi all, I'm able to compile the .NET code generator with GHC without compiler errors, but now I have the linkage error below. (In fact there are other similar messages, this is only an example). This is strange because the *.o/*.hi files were all generated without error messages. Has anyone any idea about how to solve it? (...) stage1/ilGen/ILGen.o(.rodata+0x50):fake: undefined reference to `mtlzm1zi0zi1_C ntrolziMonadziStateziLazzy_zdf14_closure' It seems to me, that the code in ILGen is using Control.Monad.State (that nowdays defaults to .Lazy) from package mtl. For stage1, this can be solved by adding -package mtl to ghc command used to linking, for next stages, you'd need to add mtl to bootstrap cycle, I think. I have no idea how that is done. Borrowing code from mtl might be easier. HTH, Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Failure in GHC compilation
Hi, On 6/2/07, Monique Monteiro [EMAIL PROTECTED] wrote: has anyone any idea about what may cause the following error in GHC compilation? It's exactly what it says...too long argument list (it's limited in Windows.) This is usually caused by having split-objs on, which causes *a lot* of object files being generated, all of them passed to ar or ld. c:\ghc\ghc-6.6.1\bin\ar.exe: creating libHSbase.a xargs: c:/ghc/ghc-6.6.1/bin/ar: Argument list too long make[2]: *** [libHSbase.a] Error 126 make[2]: *** Deleting file `libHSbase.a' Failed making all in base: 1 make[1]: *** [all] Error 1 make[1]: Leaving directory `/cygdrive/c/GHC6.6.1/ghc-6.6.1/libraries' make: *** [stage1] Error 2 Untested: setting SplitObjs=NO in build.mk might help (as there will be less object files to pass to ar. If ghc head is already using cabal, this problem is solved there. It might also be possible to extend ghc build machinery to pass parameters in file for ar and ld - but that requires new enough mingw toolchain. HTH, Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Visual Haskell's Hello, World
Hi Bill, On 1/2/07, Bill Mill [EMAIL PROTECTED] wrote: It seems trivial, but I think the contents of main.hs in the Visual Haskell default project should include a getChar: module Main where main = do putStrLn Hello, world! getChar The first thing a user is going to do on installation is hit the build and execute button, and the default project displays a window which then closes before the user can see if anything's happened. I don't have Visual Studio or Visual Haskell installed right now, but I recall that for most languages there is two ways to run a program: debug and non-debug. For haskell these would be the same at the moment. But there's also another diffrence: non-debug leaves console window open after running the program. I think typical key bindings are F5 for debug run, and Ctrl+F5 for non-debug. Best regards, Esa Ilari Vuokko ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [Haskell-cafe] windows file locking
On 10/11/06, Stefan Aeschbacher [EMAIL PROTECTED] wrote: Hi I need to open a file and keep it open for writing (a log file). Another process has to read from this file. On windows the second process (e.g. tail -f) can not open the file. How can I open a file without this locking? Using base-package's IO-system, that is not possible as far as I know. The flag you need to pass CreateFile (api call which is used to open practically all files) is FILE_SHARE_READ. You can find these in Win32-package, but files opened via raw api bindings don't work well together with base-packages IO-system (ie, you need to read and write using rawish api calls.) Best regards, Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: ANNOUNCE: GHC 6.6 Second Release Candidate
On 10/5/06, Simon Marlow [EMAIL PROTECTED] wrote: Brian Smith wrote: The GHC 6.6 release candidate ships with Win32-2.0. But, this is actually Win32 2.0 plus some modifications (see recent patches). Shouldn't the version number be inrcremented to be over 2.0? I think that this applies to the other libraries as well. Also, the GHC-6.6 darcs-all script does not pull the extra libraries using using any tags or from any particular branches. In the (near) future, the libraries will progress beyond what is found in 6.6. At that point in time, it will be difficult to reproduce the 6.6 release as shipped by building from the Darcs repository. Win32-2.0 was never officially announced or tagged, as far as I'm aware. Is that right? So can't the Win32 package included with GHC 6.6 be called version 2.0? We have branched all the packages for GHC 6.6. This does I suppose constitute a release of all these packages, in the absence of any other release and tagging mechanism in use. When packages start having indepdendent release cycles, when we make a GHC release we can just take the latest stable version (or branch) of each of the packages that we ship. For Win32, when I wanted to increase version number, the reason not to do it was that we were going to get 2.0 with new Cabal-compatibility (which Win32 has had for a while) near ghc 6.6 release and that meanwhile people should use cabal's snapshot feature. I haven't touched Win32 version after that, on assumption that ghc team would manage the release. I think that version number in repo should always be bigger than released version, so that snapshot names reflect versioning better. I also would like to somewhat untangle Win32 release cycle from ghc's so that for example stable hugs build could be reproduced (but that's assuming hugs build system managed tags on checkout.) Best regards, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Creating DLLs with GHC
Hi On 9/27/06, Matthew Bromberg [EMAIL PROTECTED] wrote: though I have a binary build of ghc 6.5 If you have new ghc 6.5, you can use --mk-dll with --make, in case that helps. ghc --mk-dll -o netsim.dll ExternLib.o ExternLib_stub.o dllNet.o src1.o src1_stub.o src2.o -optl-lmatrixstack -optl-L. My external C library is in matrixstack.dll and it has a corresponding static link stub library matrixstack.lib in the same directory as all the sources. It has references in one of the sources (say src1.hs). If I recall correctly, to link Ms-style import libs, you must specify them as object files (ie no -optl-lfoo, but just foo.lib) or make mingw-style import libs via .def files. But as you've not run into this yet, maybe it works for you like that. Unfortunately I get a host of undefined references to basically all the functions in matrixstack.dll and also some undefined references of the form Parsefile.o:ghc2996_0.hc:(.text+0x130): undefined reference to `TextziParserCombinatorsziParsecziError_show_closure' Parsefile.o:ghc2996_0.hc:(.text+0x220): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' Parsefile.o:ghc2996_0.hc:(.text+0x24a): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' Parsefile.o:ghc2996_0.hc:(.text+0x29c): undefined reference to `TextziParserCombinatorsziParsecziChar_spaces_closure' Add -package parsec to you ghc commandline. And similary for any other packages you used while compiling. HTH, Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: 6.6 candidate
On 9/6/06, J. Garrett Morris [EMAIL PROTECTED] wrote: ghc-dir\lib\i386-unknown-mingw32\include. Moving the files from the new location to the old solved the compilation problem. The correct place is ghc-dir\include, indeed. Was this a problem in the distributed build, or did I do something wrong when I was installing it? I think it is a problem with the nightly build. Best regards, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] getContents and lazy evaluation
Hi On 9/6/06, David Roundy [EMAIL PROTECTED] wrote: Fortunately, the undefined behavior in this case is unrelated to the lazy IO. On windows, the removal of the file will fail, while on posix systems there won't be any failure at all. The same behavior would show up if you opened the file for non-lazy reading, and tried to read part of the file, then delete it, then read the rest. This is not strictly speaking true. If all the handles opened to the file in question are in FILE_SHARE_DELETE-sharing mode, it can be marked for deletion when last handle to it is closed. It can also be moved and renamed. But it is true that removal might fail because of open handle, and it is true that it will fail as implemented currently for ghc (and probably for other compilers as well.) The undefinedness in this example, isn't in the haskell language, but in the filesystem semantics, and that's not something we want the language specifying (since it's something over which it has no Happily this isn't lazy IO-issue, it's just file IO issue for all files opened as specified by haskell98. Sharing mode would be really nice to have in Windows, as would security attributes. But as you say, these are hard things to specify because not everyone has those features. So, at least it works nicely in posixy-systems, eh? Best regards, --Esa Ilari Vuokko ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Windows API - GetLastError woes
Hi, My use case is in Win32-package, where we simply call a FFI imported call and on failures call GetLastError to get extended error code. GetLastError of course only works on same OS thread and contains sensible results only before next Windows API call. It's much like C/posix errno. So, we *must* call GetLastError in the same OS thread, and there must not be any Windows API calls in between, including those caused by, say, rts' memory allocation or calls to lock mutexes. Unless the error code is saved via Get/SetLastError. Also, I'd like not to run the code in a another OS thread (and that won't fix the rts-caused Windows API calls), because the calls are supposed to be fast, and OS-level context switch isn't fast. Is this problem real, or did I miss some magic feature of rts? The only way to solve this problem seems to be to wrap all calls in C-functions that take care of reading GetLastError. Not that it's impossible, just very annoying. Best regards, --Esa Ilari Vuokko ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Windows API - GetLastError woes
Brian Hulley wrote: The only way to solve this problem seems to be to wrap all calls in C-functions that take care of reading GetLastError. Not that it's impossible, just very annoying. If there is no better solution, would it be possible on failure to somehow enter a critical section and repeat the call that caused the failure and then call get last error and exit the critical section so that normal calls would be fast but only failed calls would be slow? In some (many) cases, yes, but for example with async IO you really don't want to do this. Some errors still cause async notification. Gut instinct tells me repeating system calls might also cause atomicity issues, but I don't have an example. Best regards, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] Win32-package and Windows error codes in exceptions
Hi, Recently, I've been annoyed how Win32-package throws user errors, ie String, on failures. The System.Win32-being rather low level, it often makes sense for caller to catch some specific errors. I don't really understand how, or if, I could extend System.IO.Error. unix- package uses it via Foreign.C.Error, which makes me wonder if the underlying functionality in there should be extended. Is the only or best choice to go for Dynamic exceptions? That introduces a subtle difference for (already existing) programs that rely on exceptions to be presentable via Show and default handler. Best regards, --Esa Ilari Vuokko ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Instruction to build current GHC 6.5 on Mac OS X/Intel x86
Hi, Paolo Martini got ghc to built using Audrey Tang's build from 20060608 on Mac OS X/Intel x86. Instructions are available at ghc trac: http://hackage.haskell.org/trac/ghc/wiki/X86OSXGhc Please edit the page if you have corrections. Best regards, --Esa Ilari Vuokko ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Circular dependency between the compiler and TH?
On 8/19/06, Simon Peyton-Jones [EMAIL PROTECTED] wrote: I can't tell just what you are doing, but somehow you seem to be building a stage-2 compiler in stage1. On compiler/Makefile we got ifeq $(BootingFromHc) YES # HC files are always from a self-booted compiler bootstrapped = YES else ifneq $(findstring $(stage), 2 3) bootstrapped = YES else bootstrapped = $(shell if (test $(GhcCanonVersion) -eq $(ProjectVersionInt) -a $(GhcPatchLevel) -eq $(ProjectPatchLevel)); then echo YES; else echo NO; fi) endif endif Which would turn bootstrapped=YES when building 6.5 with 6.5, even during stage1. And then ifeq $(GhcWithInterpreter) $(bootstrapped) YES YES and inside this if it also turns template-haskell on. It's a bit funny. It makes sense for end user not to need bootstrap compiler more than once - for example to build new set of libraries for ghc would be much faster, and bootstrapping holds no additional value. So, Joel, you might want to change your mk/Config.mk and lie about your ghc version a bit (you need to mod the file after configure). Say it's 6.4, and you might not need to unpull patches and you might get normal 2-stage bootstrap. Best regards, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Circular dependency between the compiler and TH?
On 8/19/06, Joel Reymont [EMAIL PROTECTED] wrote: On Aug 19, 2006, at 8:48 PM, Esa Ilari Vuokko wrote: So, Joel, you might want to change your mk/Config.mk and lie about your ghc version a bit (you need to mod the file after configure). Say it's 6.4, and you might not need to unpull patches and you might get normal 2-stage bootstrap. Changed to 6.4. Still getting the bounds error. This is a freshly checked out tree, btw. Ergh, sorry. That'd be right, because that is controlled by preprocessor defsyou'll need to unpull that patch for stage1, but hopefully it won't try building ghci and template-haskell in stage1 this time. Best regards, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Digraph.lhs broken?
On 8/19/06, Joel Reymont [EMAIL PROTECTED] wrote: /usr/local/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes - istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename - istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/ specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn - istage1/simplStg -istage1/codeGen -istage1/main -istage1/ profiling -istage1/parser -istage1/cprAnalysis -istage1/ ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen - istage1/ghci -Istage1 -DGHCI -DBREAKPOINT -package template-haskell - threaded -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno- generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include cutils.h' -i../compat -ignore-package Cabal -fglasgow-exts -c utils/Digraph.lhs -o stage1/utils/Digraph.o -ohi stage1/utils/ Digraph.hi utils/Digraph.lhs:133:12: Ambiguous occurrence `indices' It could refer to either `GHC.Arr.indices', imported from Array at utils/Digraph.lhs:43:0-11 or `Data.Array.Base.indices', imported from Data.Array.ST at utils/Digraph.lhs:48:0-19 utils/Digraph.lhs:139:18: Ambiguous occurrence `bounds' It could refer to either `GHC.Arr.bounds', imported from Array at utils/Digraph.lhs:43:0-11 or `Data.Array.Base.bounds', imported from Data.Array.ST at utils/Digraph.lhs:48:0-19 I think I know why that is happening. This is because you are compiling ghc 6.5 using older (few weeks and more) ghc 6.5. During this time Array-interfaces changed in base, and ghc had to be patched for it. The fix is to either use previous release of ghc (6.4) for stage1 or unpull/rollback patch Wed Aug 9 19:13:41 FLE Standard Time 2006 Esa Ilari Vuokko [EMAIL PROTECTED] * Fix Array imports for stage1. But you will need to reapply it for stage2. I haven't tried this, but it should work :-) HTH, --Esa Ilari Vuokko ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Digraph.lhs broken?
On 8/19/06, Joel Reymont [EMAIL PROTECTED] wrote: Thanks Esa! And what patch is this? /usr/local/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes - istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename - istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/ specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn - istage1/simplStg -istage1/codeGen -istage1/main -istage1/ profiling -istage1/parser -istage1/cprAnalysis -istage1/ ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen - istage1/ghci -Istage1 -DGHCI -DBREAKPOINT -package template-haskell - threaded -package readline -DUSE_READLINE -cpp -fglasgow-exts -fno- generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include cutils.h' -i../compat -ignore-package Cabal-c ghci/ ByteCodeLink.lhs -o stage1/ghci/ByteCodeLink.o -ohi stage1/ghci/ ByteCodeLink.hi ghci/ByteCodeLink.lhs:161:4: `getBounds' is not a (visible) method of class `MArray' ghci/ByteCodeLink.lhs:161:40: Not in scope: `getBounds' ghc: 41585012 bytes, 8 GCs, 2832740/5554788 avg/max bytes residency (2 samples), 18M in use, 0.00 INIT (0.00 elapsed), 0.09 MUT (0.16 elapsed), 0.08 GC (0.09 Erk. I thought you shouldn't see this...ghci is getting built on stage1? Well, anyway, I think that was in patch Wed Aug 9 19:30:12 FLE Standard Time 2006 Esa Ilari Vuokko [EMAIL PROTECTED] * Remove HasBounds-instance and implement MArray.getBounds instead HTH, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC Error in linker undeined reference
Hi, On 8/12/06, Johan Grönqvist [EMAIL PROTECTED] wrote: import Control.Monad.State import Control.Monad.ST import Data.Array.ST import Data.List Control.Monad.State is from package mtl, the other modules are part of the base package, I think. [EMAIL PROTECTED]:~/haskell/Forth$ ghc forth.lhs You need to tell ghc that you want to link package mtl. ghc -package mtl forth.lhs or more automatic ghc --make forth.lhs The packages you can import without any additional options are the packages ghc-pkg list shows as visible. But without --make, or explicitly telling, ghc doesn't know which packages to link with. HTH, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacement for GMP
On 8/3/06, John Meacham [EMAIL PROTECTED] wrote: On Wed, Aug 02, 2006 at 03:22:57PM -0400, Peter Tanski wrote: Esa and I had discussed the possibility of copying the value returned from the Bignum lib into the GHC system, which certainly would not be very memory efficient, but might be faster. Among other memory modifications, it might be a good idea to initialise the Bignum lib with the RTS and modify the lib with a memory cache or garbage collection system of its own. I don't understand why this would be useful. Just use the standard FFI ForeignPtr mechanism and it takes care of garbage collection for you and doesn't have any issues with concurrency. This would also make the library fully portable to any haskell implementation with FFI support. There is atleast one imaginable situation where copying would be safer: Imagine using a library that changes GMP memory allocation routines on (user-called) initialisation. Integers allocated before library init would probably crash the system when their finalisers were giving free-calls bad addresses. Then there's minor optimisations - memory being only in haskell heap it can be compacted, no need to check or run finalisers. Whetever these give more than we lose...benchmarking is hard without competiting implementations. I am not arguing it's a good choice. But it is totally valid choice with some good points, and it is interesting idea. There's also more a possible drawback: It requires even more knowledge, or assurances, from inner workings of the library. Best regards, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacement for GMP
Hi Peter,
Peter Tanski wrote:
In the July thread, (Repost) Replacement for GMP as Bignum: ARPREC?
Haskell?; OS X and OpenSSL, you wrote:
In past, I tried to get rid of GMP by replacing it with libtommath
http://math.libtomcrypt.com/
But I have given up for now - because of related and unrelated problems.
Since I had no prior experience with LibTomMath I decided to take a look
at it. The most recent release version of LibTomMath seems to be 0.39.
Were some of the related problems you ran into due to bugs in an
earlier version of LibTomMath? Maybe it is premature for me to go
looking at replacing Integer when GHC has already moved so far ahead of
itself I have to service the source code just to get it to build on OS
X, but I figure that while I have the hood up I might as well take a
look at the rest of the engine... If you have any old notes on the
problems you encountered, I would greatly appreciate it.
What I have written here might not be the most useful guide to
start with, but maybe it is of help for other interested souls.
My first and foremost problem was that I had certain amount time I was
going to use on it and that I use Windows, where ghc build breaks pretty
often - and it was very badly broken at the time. I simply ran out of
time and motivation. The resistance I met in community (irc mainly)
for this step was also annoying. I also went wrong way when I started
and added configure-option, but Simon Marlow (iirc) asked me not to add
configure option, but to obliterate gmp alltogether.
The big steps, to get things done, in this matter are:
* Understanding how memory handling between math lib and GC works
* Understanding some C--
* Understanding autotools and makefile hackery
If you are new to ghc source, you should read
(some of)
http://hackage.haskell.org/trac/ghc/
and
http://darcs.haskell.org/ghc/HACKING
Most of the code for this task is fairly easy, actually. The bad thing
is that it cannot be easily split into many small steps.
Most of the task has very small scope: Most of the backend doesn't care,
we just use exising bits, frontend and base-package don't see much
or any diffrence.
I'll add here some notes that might be helpful (but as I type these out
of memory, they might not be 100% accurate):
* The memory handling:
The idea on most bignum libs is that they have c-structure kinda
like this:
struct Big {
word size, used;
digits* payload;
bool sign;
} ;
Now, the size and used tell how much memory is allocated for paylod
and how much of it is used. sign is the sign (plus/minus).
payload is a pointer to memory that contains Integer decoded.
Normally, in c, you would reuse these variables, but with
immutability, we can't do that. This is handled in GHC so that
payload (and sign) are stored in a bytearray, which is native
garbage collectable type. It natively contains size. Before we
call math-lib, we put together a temporary structure with correct
pointers. As for target variable, we have hooked the mathlibs
memory allocation functions to allocate correctly. Upon returning
Integer, we just take payload, write sign on correct place and
return the payload-pointer (possibly adjusted).
In pseudo C
digits* add(digits* din) {
Big in, out;
in.size=getLength(din);
in.used=getLength(din);
in.payload=din;
in.sign=getSign(din);
math_lib_init(out);
math_lib_add(out, in);
writeSign(out.payload, out.sign);
return out.payload;
}
There are tricky parts for 64bit-stuff in 32bit systems and some
floating point decoding uses bad configure-stuff that depends on
math lib stuff, but mostly it's very boring hundreds of lines of
C-- (but you can make the job much easier by using preprocessor).
This is why APPREC might be hard - you need to know the internal
representation.
* C-- and related RTS stuff
C-- is pretty easy, you should read C-- spec at cminusminus.org.
GHC C-- unfortunately is not really near the C-- spec, it doesn't
first of all implement it all - but that doesn't matter for this
task - and then it has some extensions for casting and structure
reading, I think. When removing GMP, it is easy to spot places
that needs corresponding declrations/definitions for new math-lib
instead of GMP. Reading old GMP primops, where most of the
interesting c-- code is at, should also make it clearer - after
a while, atleast.
* Autotools and makefiles
What a mess. Well, it always is for big projects. The annoying
thing here for LibTomMath was that I found out, I'd need to add
autotool configure-hackery into ghc and make internal libtommath
dependant on it, so that digit-size and such were the size of native
word on each machine. There's also a lot of DLL-related stuff
in makefiles, which, I think, can safely be removed - some of it
is wrong and outdated, so when/if it gets
Re: Replacement for GMP
Hi Peter,
Peter Tanski wrote:
(This may sound naieve): the in { size, used, payload, sign } are all
parts of the info-table for the payload and the RTS re-initialises the
mathlib on each invocation, right?
I hope my answer helps, but if it gets you more confused,
maybe it's just because I'm confused...I'm certainly
not the best qualified to answer.
Infotables are static as far as I understand.
I was also a bit wrong, now that I read primops-code again.
(Places of code that I read for this:
http://darcs.haskell.org/ghc/rts/PrimOps.cmm
search for #define GMP_TAKE_RET1 for an example of macro that
is used to implement unary op.
http://darcs.haskell.org/packages/base/GHC/Num.lhs
search for data Integer)
The interesting ctor for Integer is:
| J# Int# ByteArray#
Here we see that J# has two params
size (which also contains sign) of the data
pointer to another object, garbage-collection managed bytearray
In GMP_TAKE1_RET1 we have
MP_INT__mp_alloc(mp_tmp1) = W_TO_INT(StgArrWords_words(d1));
MP_INT__mp_size(mp_tmp1) = (s1);
MP_INT__mp_d(mp_tmp1) = BYTE_ARR_CTS(d1);
Where s1 and d1 are the parameters from that constructor.
In GMP's case, size variable contains sign, and no sign variable
is needed. Payload is the actual bytes in bytearray-object and
allocated size is the amount of bytes allocated for bytearray-object.
Because the memory allocation for GMP has been hijacked, we
can simply return the important bits.
RET_NP(
TO_W_(MP_INT__mp_size(mp_result1)),
MP_INT__mp_d(mp_result1) - SIZEOF_StgArrWords);
RET_NP jumps back, or into, whatever needs the answer, we
return two things, int that has the size and sign from GMP
structure, and pointer to bytearray object - we need to adjust
the pointer location to point into bytearray-object, instead
of it's payload. The return type is actually,
(# Int#, ByteArray# #), which is unboxed tuple
containing unboxed Int and pointer/reference to ByteArray-object.
In the thread returning to cost of Integer, John Meacham wrote:
we could use the standard GMP that comes with the system since
ForeignPtr will take care of GCing Integers itself.
From current discussion: at present the allocation is done on the GC
heap, when it could be done entirely by the mathlib. The benefit to
letting the mathlib handle memory would be that you could use the
mathlib with another (non-Haskell) part of your program at the same time
(see, e.g., (bug) Ticket #311).
There are other nicer things about that as well - untying Integer
(atleast mostly) from runtime/frontend and moving it more into
domain of libraries.
(I am making an educated guess, here.) You probably chose to allocate
GMP's memory on the GC heap because:
(I have no idea about original reasons.)
(1) call-outs to another program are inherently impure since the
type-system and execution order are not defined by the Haskell Runtime;
and,
Another program? I assume you meant outside pure haskell - call-outs
have side-effects. We can get around by using unsafePerformIO,
which doesn't really differ that much from writing it in
C-- (and library in C), except we'd write haskell.
(2) it was a stable way to ensure that the allocated memory would remain
available to the thunk for lazy evaluation, i.e., so that the evaluation
of the returned Bignum could be postponed indefinitely, correct? Or
could the evaluation itself be postponed until the value was called
for--making operations on Integers and other Bignums lazy?
Uhm, naturally, haskell rts needs to control lifetime of the memory.
I am not sure what you're trying to say here, really. Is the point
that we cannot free almost anything without permission from
garbage collector? Because, yeah, we can't.
My guess (without having read the thread you mention) is that using
ForeignPtrs brings two cons: Possibly extra indirection and using
lots of Integers will mean (in many cases) a lots of finalisers that
get run, and running finalisers (and checking for them in the first
place) might be slow.
In other words, it does not seem possible to simply hold a ForeignPtr to
the returned value unless there were a way to release the memory when it
was no longer needed. If you wanted the mathlib to retain the value on
behalf of GHC, you would have to modify the library itself. In the end
you have a specialized version of the library and a change to the
procedure from:
math_lib_init ; ...
return out.payload ;
to:
math_lib_init ;
math_lib_evaluate ;
math_lib_free ;
Only temporaries could be free'd here. Anything else could be
needed again.
An easier though less-efficient alternative would be to have GHC copy
the value returned by the mathlib. That would be stable and allow other
systems to use the same mathlib concurrently (assuming the lib is
thread-safe).
As I understand, you suggest here copying payload instead of merging
memory handling. I don't think it's clearly, if ever, less efficient
than
Re: (Repost) Replacement for GMP as Bignum: ARPREC? Haskell?; OS X and OpenSSL
Hi On 7/30/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: (Sorry for the repost: I needed to correct a few typos--thanks Seth--and clarify a few things.) GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum library, BN. I have two questions concerning this: (1) Why not use the ARbitrary PRECision Computation Package (ARPREC) by David Bailey, Yozo Hida, Karthik Jeyabalan, Xiaoye Li and Brandon Thompson? Here is a reference web page: http://crd.lbl.gov/~dhbailey/mpdist/ ARPREC is written in C++ but supports calls from C (see include/arprec/c_mp.h in the distribution directory). ARPREC is very fast and supports more complex mathematics than BN. The Licensing for ARPREC is not a problem: essentially similar to BSD3. I think the idea is to get rid of annoying dependencies (GMP), and not to create new ones (C++). There's few other big ifs with APREC as far as I see: Fiddling with FPU precision regs in x86 and possibly problems in Windows environment. It might require a bit fiddling to get memory handling right when using APREC, as well. In past, I tried to get rid of GMP by replacing it with libtommath http://math.libtomcrypt.com/ But I have given up for now - because of related and unrelated problems. But, whoever starts the work probably gets to pick their lib, so OpenSSL's BN, APREC, LibTomMath or anything else...it's open :-) Best regards, Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and OpenSSL
On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: GHC Task Ticket # 601 suggests replacing GMP with OpenSSL's Bignum library, BN. I have two questions concerning this: From the ticket, this looks very scary: but its LGPL license is problematic for users of GHC (it prohibits static linking of GHC-compiled programs, for example). Does this mean I can't distribute my Haskell app as a commercial application? I certainly don't want to distribute source code and I've got I am not a lawyer, and you should consult lawyer if you want real advice about licensing issues. Strict answer to first question: No. You can distribute statically compiled binaries. no idea how to compile a Haskell app other than using ghc --make, which creates a single exe ie with static linkage. But in this case, yes, you can't. You need to provide way to relink gmp in you program. As far as I know, this is simply possible by taking all the objs --make generates, other objs and libs and giving them on - users need to have ghc distro+their own gmp set in. If I only use Int's (not Integer's) in my code, is there a way to get rid of GMP so that I won't have an impossible licencing problem when trying to I am fairly certain you cannot force or rely GMP getting dropped by linker. distribute my application binary? If not, then it would seem absolutely vital to get rid of GMP as soon as possible or else try to persuade the authors to add the usual static linking exception to their LGPL licence for it. GMP being rather GNU ;-) replacing is probably the only option. There's other reason for dropping GMP as well: The ghc rts steals GMP memory allocation (sort of integrating it with garbage collector) which makes it impossible for other parts of program use GMP (in practice). HTH, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and OpenSSL
Hi Duncan, On 7/30/06, Duncan Coutts [EMAIL PROTECTED] wrote: GHC only statically links Haskell code. It dynamically links to GMP and the system C library and other C libs. In Windows (mingw) GMP is linked in statically (even this dll-stuff is bitrotted). So you're fine. On unix you can check for yourself with ldd. It lists all the shared libs that your program needs. For example: FWIW, you can use dependencywalker to do this in Windows. Best regards, Esa PS For ghc.exe in 6.4.2 distro, walker gives: ACTIVEDS.DLL ADSLDPC.DLL ADVAPI32.DLL ADVPACK.DLL APPHELP.DLL ATL.DLL AUTHZ.DLL BROWSEUI.DLL CABINET.DLL CDFVIEW.DLL CERTCLI.DLL CFGMGR32.DLL CLUSAPI.DLL COMCTL32.DLL COMDLG32.DLL CREDUI.DLL CRYPT32.DLL CRYPTUI.DLL CSCDLL.DLL DBGHELP.DLL DEVMGR.DLL DHCPCSVC.DLL DNSAPI.DLL DUSER.DLL EFSADU.DLL ESENT.DLL GDI32.DLL GDIPLUS.DLL GHC.EXE HLINK.DLL HNETCFG.DLL IMAGEHLP.DLL IMGUTIL.DLL IMM32.DLL INETCOMM.DLL IPHLPAPI.DLL KERNEL32.DLL LINKINFO.DLL LZ32.DLL MFC42U.DLL MLANG.DLL MOBSYNC.DLL MPR.DLL MPRAPI.DLL MPRUI.DLL MSASN1.DLL MSGINA.DLL MSHTML.DLL MSI.DLL MSIMG32.DLL MSJAVA.DLL MSLS31.DLL MSOERT2.DLL MSRATING.DLL MSSIGN32.DLL MSVCP60.DLL MSVCRT.DLL MSWSOCK.DLL NETAPI32.DLL NETCFGX.DLL NETMAN.DLL NETPLWIZ.DLL NETRAP.DLL NETSHELL.DLL NETUI0.DLL NETUI1.DLL NETUI2.DLL NTDLL.DLL NTDSAPI.DLL NTLANMAN.DLL ODBC32.DLL OLE32.DLL OLEACC.DLL OLEAUT32.DLL OLEDLG.DLL OLEPRO32.DLL POWRPROF.DLL PRINTUI.DLL PSAPI.DLL QUERY.DLL RASAPI32.DLL RASDLG.DLL RASMAN.DLL REGAPI.DLL RPCRT4.DLL RTUTILS.DLL SAMLIB.DLL SCECLI.DLL SECUR32.DLL SETUPAPI.DLL SHDOCVW.DLL SHELL32.DLL SHLWAPI.DLL SHSVCS.DLL TAPI32.DLL URLMON.DLL USER32.DLL USERENV.DLL USP10.DLL UTILDLL.DLL UXTHEME.DLL VERSION.DLL W32TOPL.DLL WINHTTP.DLL WININET.DLL WINMM.DLL WINSCARD.DLL WINSPOOL.DRV WINSTA.DLL WINTRUST.DLL WLDAP32.DLL WMI.DLL WS2_32.DLL WS2HELP.DLL WSOCK32.DLL WTSAPI32.DLL WZCDLG.DLL WZCSAPI.DLL WZCSVC.DLL ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Replacement for GMP as Bignum: ARPREC? Haskell?; OS-X and OpenSSL
Hi Brian, On 7/30/06, Brian Hulley [EMAIL PROTECTED] wrote: Still, a slight problem is that since there is one object file per source file, the names of the object files give quite a lot of information away about the structure of the program especially when they are arranged in a module hierarchy, so I'll be glad when GMP is replaced by something without such a burdensome licence. (Although perhaps I can bundle my object files into a single library file but I don't know how to do this yet, or if it would really help in the goal to make the code completely obfuscated, impenetrable, and unavailable to any rival company... ;-) ) Assuming gnu toolchain, you can use ld to link object files together in a form that is definitely harder to break apart. (incremental linking to incomplete executable, iirc via switch -x). That should allow you to produce one big object file (of atleast haskell bits and c bits) that gets simply passed to ghc. Using strip to remove debug info/symbol tables also helps somewhat. (strip.exe is not part of ghc distribution, but you can find it in mingw bintools.) Using ar to create archives does not help at all - you can extract the original files using ar itself. HTH, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compile problem on Windows
On 7/14/06, Robert Dockins [EMAIL PROTECTED] wrote: I posted a message on the libraries list a couple of days ago about a compile problem I'm having. I haven't got any nibbles. Because I Sorry, it slipped past me. The reason nobody reacted might also be that it's not really ghc's problem, but problem in mingw/winapi headers which ghc just drags along. now suspect this is a GHC problem, I'm posting here to see it I can get this resolved. Rather than repost the details, allow me to refer you to (http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/ http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/4873 (hopefulyl it's on one line in my mail) 4873) which contains a complete description of the problem. As far as I can tell, the GHC install is missing a necessary system header, or it isn't being found, or somesuch. I tried crawling through the headers to find out what the problem is, but, as per usual, the system headers are almost totally incomprehensible. I'm just guessing here, but reading the sql.h and sqltypes.h it seems likely to me that you should include windows.h before including them. If it is so, it very likely is not a bug in ghc or winapi-package from mingw, but intentional. Fix would be to add #include windows.h in the .hsc file. I've tried using both Cygwin and MSYS shells, but the results are identical. As I said in the above message, I'm not very familiar with this environment, so I'd appreciate pointers in the correct direction if I've made some mistake. In generla, using cygwin shell with cabal and/or packages with configure and using non-cygwin-ghc (cygwin port of ghc isn't maintained or built) can lead to wierd problems. Msys sometimes works, sometimes doesn't, depending how aware packages are ghc's and msys' mingws' paths. HTH, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compile problem on Windows
On 7/14/06, Robert Dockins [EMAIL PROTECTED] wrote: On Jul 14, 2006, at 12:26 PM, Esa Ilari Vuokko wrote: In generla, using cygwin shell with cabal and/or packages with configure and using non-cygwin-ghc (cygwin port of ghc isn't maintained or built) can lead to wierd problems. Msys sometimes works, sometimes doesn't, depending how aware packages are ghc's and msys' mingws' paths. Humm. What do people usually do? Use cmd.exe? *cringes at the thought* I didn't mean to say you shouldn't use msys/cygwin. It's just that it's often suprising when cabal-enabled package runs configure, and how it might not use libraries that came with ghc or those that came with mingw correctly - package may or may not compile and it may or may not be usable in haskell programs. With cygwin there is additional catch that you, in general, cannot link cygwin-compiled libs with ghc-built binaries (safely anyway). And yeah, I do use command prompt myself (for what little I need it for.) when given choice. I do shy away from packages that need msys. But if package requires, I'll use msys (I don't use cygwin.) Best regards, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] comdlg32.dll FFI bindings
Hi Jason, On 7/12/06, Jason Dagit [EMAIL PROTECTED] wrote: The package you mention appears to ship with visual haskell but I don't see any wrappers for the functionality in comdlg32.dll. I would like to add that functionality. Do you know where I can find the source code for this package? I've searched around on google but I'm not finding it. If there is a darcs repository that would be ideal. There is: http://darcs.haskell.org/packages/Win32/ Yes, I think there isn't any commdlg32 bindings in the package yet. Patches are welcome :-) Suggestions, too. ;-) Best regards, --Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Closure trace?
Hi Michael, On 6/14/06, Michael Marte [EMAIL PROTECTED] wrote: I wonder whether it is possible to print a closure trace similar to a stack trace in procedural programming. Say we have two modules A and B: I wrote small (external) utility that does something like that for ghc-built binaries. It can print traces on user defined breakpoints. As there isn't much use for it, I haven't played with a while, but it might help or provide starting point. darcs get http://tamelambda.net/darcs/tracer/ (requires ghc 6.4.2 and Windows to compile and use) Example output for tracing lines, of a program something like this: getContents = mapM_ putStrLn . lines Trace: Data.List.lines+ 0 CtFUN_STATIC stg_upd_frame + 0 CtUPDATE_FRAME GHC.Base.map + 108 CtRET_VEC_SMALL stg_upd_frame + 0 CtUPDATE_FRAME GHC.Base.foldr + 76 CtRET_VEC_SMALL stg_upd_frame + 0 CtUPDATE_FRAME stg_ap_v + 0 CtRET_SMALL GHC.IOBase.bindIO + 46 CtRET_SMALL GHC.TopHandler.runMainIO + 126 CtRET_SMALL stg_catch_frame+ 0 CtCATCH_FRAME stg_noforceIO + 0 CtRET_SMALL stg_stop_thread+ 0 CtSTOP_FRAME The output isn't too pretty, but it is often possible to see where calls to, say error occur. Unfortunately (for tracing) ghc aggressively inlines (and libraries have RULES-pragmas) functions. That causes traces to have big holes in them. Best regards, --Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: HEAD: Problem Linking genapply in 6.5.20060510
On 5/13/06, Reilly Hayes [EMAIL PROTECTED] wrote: Hi I suspect today's problem is pretty easy to figure out for a GHC expert, but I'm not. When I try to build utils/genapply, the link fails because the symbols _GHCziList_lvl22_closure and _GHCziList_zdwlen_info are undefined. I'll include the build log On actual problem, I have no idea except the simple..maybe .hi files were inconsistent with object files. below. While we're on the topic, can somebody explain the algorithm used to generate these symbol names? I might be wrong on any of this, but I'm giving it a shot as it might take over weekend before Simons or anyone else answers. It's called zencoding, found in http://darcs.haskell.org/ghc/compiler/utils/Encoding.hs _ on start is just some typical c-name thingy. Otherwise those symbols are from GHC.List module. _info and _closure mean different use of that name that comes before them (lvl22 and $wlen). I think compiler/cmm/CLabel.hs might help on that, or rather modules that use it. I am not sure how to track name generators for lvl22 and $. HTH, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: How to bind a window library (in C) to Haskell?
On 2/27/06, Brian Hulley [EMAIL PROTECTED] wrote: Hi [snip] 1) Does this mean that the FFI can only pass Int, Char etc and not user defined data types or compound data types? Yes. The idea is that instead of pointers/references you have Ptr a, and instance Storable a that provides marshalling between haskell and C. Very often you actually get two sets of bindings, raw, exact C-signatures, enums as variables etc, and higher level, implemented on top of the raw-level, where you have data and class declarations to simulate usefull parts of foreign C hierarchy - your code looks more like the higher-level part. 2) I'm also really confused by the different kinds of pointers available, and how to safely store a function closure in some C data structure, and how to use this to call the function from within C and access the result safely Ptr is basically plain old c-pointer. Haskell, however, just sees it as an address with typetag, and accessing object requires marshalling, typically through Storable-class. FunPtr is basically plain c-function pointer. To create FunPtr's, you need to declare and use ffi-wrappers. Something like (taken from Win32-packages Graphics.Win32.Window): type WindowClosure = HWND - WindowMessage - WPARAM - LPARAM - IO LRESULT foreign import ccall wrapper mkWindowClosure :: WindowClosure - IO (FunPtr WindowClosure) If you are resource-handling savvy, you need to call freeHaskellFunPtr after you finish using that FunPtr. Of course, plain C-function pointers are naturally FunPtr's, and require no freeing. 3) When does GHC do garbage collection? Is the garbage collection done in the same thread as the executing program? Does GHC run a normal Haskell program using multiple threads? Would I need to link my C DLL with a multithreaded version of the C runtime to avoid problems? C and ghc memory management are not tied together. You should use your own functions in C to release any memory allocated in C. As far as I understand, haskell gc only happens when you are executing haskell. Alternatively, has anyone managed to use DirectX or COM from within a Haskell program? (because then I could perhaps rewrite all my gui code from I have written, but not published, experimental DirectX9.D3D bindings. I plan to publish it at some point, but it's pretty hairy at the moment (and incomplete, not all of D3D is done, also no docs etc). I don't have time to work on them right now, so you might need to put quite an effort in if you wish to use them. (And there is no DirectX 7 bindings, if you are using that for 2D.) Using COM might be pretty obvious if you are willing to play around with IDL and HaskellDirect. (There is no IDL files for DirectX9, so I used various hacks and COM c-interface) Or ofcourse, manually reading COM vtables isn't that hard, either. There are various other things one can do, also. Like using C-interface and thin c-wrapper funcionts (COM interface c-parts are usually preprocessor macros, so linking them in haskell isn't really convient). Or C++. of course, but then scratch in Haskell...) (I'm loathe to switch to OpenGL because OpenGL is very poorly supported on windows - a default WinXP installation does not come with hardware accelerated OpenGL drivers, afaik, and also I can't find any documentation on the Haskell OpenGL bindings except the Haddock type signatures which are just not nearly enough to understand how to use it, and some out of date docs) If you are comfortable reading OpenGL spec, the haddock documentation should be pretty simple to follow. HTH, -Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] FFI question
On 2/9/06, Frederico Franzosi [EMAIL PROTECTED] wrote: Hi, I don't really know how this stuff exactly works, but here's few things I have found useful when I ran into this sort of problems. I'm developping a package wich imports C functions. For example if I use: $ghc -package PKGname-PKGversion -fffi -o main Main.hs -llib it gives an error message (undefined references of objects from PKG to functions in lib) I don't have exact answer, but ghc uses ld under the hood and sometimes the order of libraries on ld command line matters. Here's few things that might be useful if that's the case. Use ghc -v and find final link ld/gcc (I don't recall which one ghc invokes for linking) and try that line yourself, you can also move libraries up on list etc to find what order you actually need. Add -llib to the options in package.conf as a library- try adding as first and try adding as last. Try both ;-) Try adding as object file, ie /path/to/lib.a Order of arguments on ghc command line doesn't matter so much, because ghc will put (if I recall correctly) package libraries first and then add -llib and such options to the end on the ld command line- so it's pretty hard to work around the problem just by invoking ghc different way. $ghc -fffi -o main Main.hs -llib /path/to/PKGlib.a it compiles correctly. and also when I do: $ghc -package PKGname-PKGversion -fffi -o main Main.hs /path/to/lib.a If I were to guess these work because /path/to/lib.a is handled as an object file, which is somehow different from being library. I have no knowledge what and why there is this sort of magic restrictions. HTH, -Esa ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: storing highly shared data structures
On 1/11/06, Christian Maeder [EMAIL PROTECTED] wrote:
Simon Marlow wrote:
You can change the allocation area size from within a program quite
easily. Write a little C function to assign to
RtsFlags.GcFlags.minAllocAreaSize (#include RtsFlags.h first), and
call it from Haskell; the next time GC runs it will allocate the larger
nursery. Please try this and let me know if it works.
Can someone supply a code snippet for me (as I don't speak C and always
hoped to avoid C by using haskell)?
Hi
Following compiles and runs for me (ghc 6.4.1), but I didn't test any effects.
C-bits:
#include Rts.h
#include RtsFlags.h
void SetMinAllocArea(int a) {
RtsFlags.GcFlags.minAllocAreaSize=a;
}
Haskell bits:
import Foreign.C.Types
foreign import ccall SetMinAllocArea setMinAllocArea :: CInt - IO ()
It requires compiling c-bits without --make, something like
ghc -c bits.c -o bits.o
and including it on final linking or --make step (or ar/ld, similary)
ghc bits.o --make main
HTH,
Esa
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Patch: Add support for using --mk-dll with --make
Hi! Attached small simple patch that allows using --mk-dll with --make. Behaviour before patch was to link .exe instead .dll, as batchmode simply called staticLink - now doMkDLL is called instead. * Add support for using --mk-dll with --make I changed documentation a bit, and moved --mk-dll from 4.17.3 Alternative modes of operation into 4.17.21 Linking options. This documentation change isn't tested, as I don't have necessary tools installed on my machine. But it *seems* harmless (and I think, more intuitive.) Due to lack of tools, and because there's little to say, I didn't touch 11.5. Building and using Win32 DLLs. Patch should apply cleanly on cvs HEAD with patch -p0 under fptools. Any comments are welcome. Thanks in advance, --Esa mk-dll-20051121.patch Description: Binary data ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling GHC in Windows, Mingw
On 11/18/05, Esa Ilari Vuokko [EMAIL PROTECTED] wrote: On 11/18/05, Simon Marlow [EMAIL PROTECTED] wrote: I think I have just fixed this (modification to the mangler in ghc/driver/mangler), please try again. It compiles again! Thanks! ..but it still crashes on installed location, probably still while reading the package.conf But it seems you committed stuff, I'll cvs upd, clean and restart build. Yeah, still crashes, same as before :-( Best regards, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: runProcess+removeFile, Windows, possibly finaliser not running
On 11/17/05, Simon Marlow [EMAIL PROTECTED] wrote:
On 17 November 2005 04:06, Esa Ilari Vuokko wrote:
Fine, I removed usage of sleep in some profiler thingy, so it compiled
and I could continue with build.
where exactly? I haven't seen this.
Wierd.
Index: ghc/utils/prof/cgprof/main.c
===
RCS file: /cvs/fptools/ghc/utils/prof/cgprof/main.c,v
retrieving revision 1.3
diff -u -r1.3 main.c
--- ghc/utils/prof/cgprof/main.c13 Aug 2004 13:11:23 - 1.3
+++ ghc/utils/prof/cgprof/main.c17 Nov 2005 05:23:08 -
@@ -115,7 +115,7 @@
/* printf(Initialisation done\n); */
- if (Verbose) sleep(10);
+ /*if (Verbose) sleep(10); */
if (!(fptr=fopen(ProfileData,r))) {
fprintf(stderr,%s: unable to open profile data in \%s\.\n%s\n,
Pgm,ProfileData,usage);
attaches some sort of finaliser to it (why it's done this way?).
I made this change recently so that repeated calls to waitForProcess or
terminateProcess would be possible without getting an error about closed
handles.
Ah.
I've just improved it so that the handle is now closed eagerly, but
still finalized if it isn't referenced. This should fix the hsc2hs
problem (which incedentally I couldn't reproduce for some reason).
Worst kind of bugs :-(
The only sensible solution that springs to mind is to broaden handle
to contain space for exit code for process (or whatever information is
required) and on call to waitProcess/getProcessExitCode gather this
information, close the handle and change the handle to INVALID_HANDLE.
Also, finaliser would need to ignore such handle, as closing handle
twice is error (possibly also dangerous if handles can rotate, but I
don't know if that is possible).
yes, this is pretty much what I did.
Thanks!
--Esa
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: Compiling GHC in Windows, Mingw
On 11/17/05, Simon Marlow [EMAIL PROTECTED] wrote: On 17 November 2005 06:15, Esa Ilari Vuokko wrote: I haven't seen this, but I'm just updating my Windows build to try to reproduce. Does it happen with the stage1 or stage2 compiler? What version of GHC are you bootstrapping with? Stage2, and only when it is already in installed location. Stage1 compiler didn't work at all from installed location (hangs). Bootstrapped with ghc-6.4.1 installed from ghc-6.4.1-bld1.msi on homepage. I will start a new clean build, hope it goes away and I need to look into buying non-broken hardware... ;) Thanks, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Compiling GHC in Windows, Mingw
On 11/17/05, Esa Ilari Vuokko [EMAIL PROTECTED] wrote: I will start a new clean build, hope it goes away and I need to look into buying non-broken hardware... ;) The build failed and I sent mail about it on cvs-ghc list this time, even if something seemed to rip away my message and just leave attachmenent.. Anyway, I downloaded few nightly builds and it seems this happens with 11-17 build as well, but not with 11-16, so it's really recent. Hth, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Compiling GHC in Windows, Mingw
Hi! I tried to compile ghc from cvs head in windows, hosting and targetting mingw. When I got ghc to compile, it crashes while parsing (I putStrLn-debugged) package.conf, but only from installed position. Basically, somewhere inside ParsePkgConf.loadPackageConfig GHC crashes with access violation. With very few test runs, it appears that simplifying the file helps, but only case I got it not to crash was one package in file, rts, and empty ldOptions. Maybe I went wrong somewhere, any pointers appreciated! What I did: Current msys, msysdtk, binutils, win32api, gcc-core. cvs checkout fpconfig and in there ghc, libraries, alex and happy autoreconf ./configure --host=i386-unknown-mingw32 --with-gcc=d:/tools/msys/mingw/bin/gcc.exe make make install (I had to change some things, as described on mail to bugs-list, so few repeated make's) I will try clean rebuild later, but I feel doubtful. Best regards, --Esa ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC and Windows (DLL/FFI) woes
Hi! I have been trying to build some Windows DLLs with GHC, and I have run into some misfeatures or maybe I have misunderstood how to use GHC. Any help or advice would be appreciated. :) First of all, I can't get ghc to generate stubs from foreign export in anywhere else than next to original source, which is sort of annoying. I would like all the generated files to go quite a bit diffrent place than source directory. Next, --make and --mk-dll don't seem to work together. Ok, what I do, is I just --make -no-link and then --mk-dll all the object files I find :) It seems that -i flag and compiling those _stub.c have following problem: if path given in -i flag contains any /- or \-characters, i.e. any real subpaths, it seems to stop with something like: \source\sunrise\haskell\haskell\..\debug\build\haskell\plugin-hs-test/d:: createDirectory: invalid argument (Invalid argument) It seems a bit random what is the supposed filename part of the path, typically it contains drive letter and few colons, it doesn't seem totally random data. Thanks, --Esa Ilari Vuokko ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Visual Haskell] Experiences and some clear bugs
Hi!
I did quick test run with Visual Haskell and I have collected my
negative experiences to
this mail. In general, it seemed very nice tool, and this mail
shouldn't be considered
rejection of it for my part (it is just list of problems I had.)
License - if it is BSD, as announcement and documentation says, please make it
so installer.
Help files don't show up in any other mode than no filter, and after
trying to use that
mode with index and search while Visual Haskell was installed, my
IDE started
using external viewer program instead of built-in panels. Something
is sneaky in there.
Having a haskell file open file without any associated haskell project
almost invariably
ends up with at least some error messages in task list, here are the
ones I remember.
* Missing modules, and it seemed that last imported module was always reported
missing, even if was standard.
* Having {-# OPTIONS -ffi -} (Note missing #) resulted in internal
crash error (IDE didn't
go down,)
Next I will dive into Visual Studio/Cabal - the lengthier and less
clear part of my mail :)
Cabal as Visual Studio project file was slightly surprising. It
certainly wasn't easy for me,
but I haven't used Cabal before. First, let me show how I would, in
case I could use
Visual Haskell at work for commercial purposes, have files set up.
+work-space
-+repo
--+etc
+visual-studio-solution-folder
--+lib
---+my-haskell-lib
-+build
-+bin
I hope ascii graphics are not totally screwed up. There are few
things that simply don't
sit with Cabal or Visual Haskell. First, my solution and project
files are in diffrent directory
than my sources. Now, specifying this into Visual Haskell required
text editing Cabal-file,
but having ../../../lib/my-haskell-lib in there wasn't visually too
pleasing, and it crashed
Visual Haskell and this time it took IDE down. After that I stopped
trying to work around,
because I was comfortable enough to compile from command line and
using IDE only as
editor.
It also seems that I cannot specify Cabal option -v to debug problems,
but I didn't look too
hard. I also find that I'd rather have list of exported modules in
settings properties than
in module/sourcefile properties
A bit of guesswork, but here is my take the next problems I would have
had with Visual
Haskell/Cabal: I have my external libraries (modulo those coming with
compiler) all under
work-space-directory. I don't want to install anything system- or user-wide or
compiler-wide. So using Cabal for this part would be fairly hard and
require quite more
understanding how ghc saves and uses files than really necessary.
Also because of
Cabal-file, it is impossible to use Configuration macros, but those
are only important
during big reordering and when creating a lot of projects. I have
same string as path
for most of my projects in C++, and being able to select all projects
and change where
their stuff goes in few secs is sometimes nice.
It might also be nice that Haskell projects also had Debug/Release
builds, even if they
were exactly the same. I am not sure at all how to invoke current
Visual Haskell projects
from command line build.
Sorry for rather lengthy mail. Also, if I can somehow help or provide
more info..just
send me an email. I am subscribed to the list, but I might not read it always.
--Esa Ilari Vuokko
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
