Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell
Jason Dagit wrote: Thank you for releasing this! No worries. I might never have got around to releasing it if it wasn't for the encouragement of Manuel Chakravarty, Don Stewart, and others. Thanks guys! [...] as I understand it the Haskell you write still lives in Haskell-land and the .NET code you interface with lives in .NET land. Yep, that's correct. Compiling Haskell to .NET IL is a significantly more adventurous project! I wouldn't have managed to acheive a practical result in the time I had for my thesis if I had taken that route. Salsa's approach to type system mapping could be useful in such a project though. Regards, Andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell
I'd like to announce the first release of Salsa, an experimental Haskell library that allows Haskell programs to access .NET libraries. Here's a taste: type Hello.hs import Foreign.Salsa import Bindings main = withCLR $ do _Console # _writeLine (Hello .NET World!) type Hello.imports System.Console: WriteLine msbuild .\hello Hello .NET World! Salsa operates by loading the .NET runtime into your Haskell process and using the FFI (and run-time code generation) to marshall calls between the .NET and Haskell runtimes. It includes a code generator and a type-level library (which uses type families) to provide type-safe access to .NET libraries in Haskell with C#-style method overload resolution and implicit conversions. The adventurous can find version 0.1.0.1 of Salsa on Hackage [1], the darcs repository on code.haskell.org [2], and some (limited) documentation on the Haskell wiki [3]. The library is experimental and by no means complete (refer to the wiki page [3] for some of its limitations). Be prepared to end up with incomprehensible error messages and/or a broken compiler! :-) At the moment you'll need Windows, GHC 6.8, and version 3.5 of the .NET Framework to use it. Have fun! [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Salsa [2] http://code.haskell.org/Salsa [3] http://haskell.org/haskellwiki/Salsa -- Andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDBC-ODBC linking problems in windows.
Hi PJ, On 2/08/2008 4:09 AM, you wrote: I am having issues getting hdbc/odbc working on windows. When using GHC, I am not able to compile a simple program. It ends up with linker errors like [...] Is there an easy workaround for this? Or am I doing something wrong? MySetup === Windows XP SP2 ghc 6.8.3 hdbc 1.1.5.0 hdbc-odbc 1.1.4.3.0 hdbc-odbc 1.1.4.4 contains a patch to the calling convention of the ODBC functions (from ccall to stdcall). Grab version 1.1.4.4 from Hackage [1] and hopefully that'll fix your problem. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-odbc Regards, Andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDBC-odbc 1.1.4.4 fixes Windows linking problems
On 4/06/2008 1:05 PM, Greg Matheson wrote: I'm getting a 'Parse error in pattern' error. C:\Documents and Settings\Administratorghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude :m Database.HDBC.ODBC Database.HDBC [...] Prelude Database.HDBC Database.HDBC.ODBC handleSqlError $ conn - connectODBC dictation interactive:1:0: Parse error in pattern Try: conn - handleSqlError $ connectODBC dictation You can only use '-' in a do expression, or at the GHCi prompt. -- Andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HDBC with SQL Server / OBDC
On Wed, May 28, 2008 at 12:46 AM, Olivier Boudry [EMAIL PROTECTED] wrote: If the calling convention is stdcall on Windows and ccall on other OS then it should be defined based on the OS. This can be done by updating the .hsc files to define the calling convention as a macro depending on the OS type. #ifdef mingw32_HOST_OS #let CALLCONV = stdcall #else #let CALLCONV = ccall #endif And the foreign import should use CALLCONV instead of ccall. This should make it work on Windows and not break it on Linux. Thanks Olivier, that's neater than I thought. I'll put a patch together. -- Andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] COM and Haskell
On 26/04/2007, at 12:12 am, Bulat Ziganshin wrote: Simon Marlow recently wrote paper about handling dynamic exceptions - for me it seems that he described general system to mimic OOP in Haskell I found the paper (titled 'An Extensible Dynamically-Typed Hierarchy of Exceptions'). The system described is not a complete OO mapping (it doesn't deal with method overloading, for example) however because it is a recent paper and the mapping is quite lightweight it could be useful to me. Thanks for the reference Bulat. Regards, Andrew. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] COM and Haskell
On 24/04/2007, at 1:39 am, Justin Bailey wrote: Give me a way to get to the .NET libraries and the world is my oyster ... I second that :-) Such access will probably become more important over time as Microsoft release more .NET-only libraries (like Windows Presentation Foundation and Windows Communication Foundation). Hugs98.NET and GHC's Dotnet foreign calls already allow calling of .NET methods (although I haven't tried the latter). These operate at a rather low-level though. I'm working on a Haskell to .NET bridge, partially inspired by Lam's work on RubyCLR, for my undergraduate thesis this year. Hopefully it will be a viable option when completed. It's like he built an embedded DSL for interacting with .NET. I imagine the same could be done in Haskell, though it might involve some sort of code generation technique. A core difficulty is the mismatch between the object-oriented type system of .NET and Haskell's. This is something that RubyCLR didn't need to conquer, Ruby already having object-oriented concepts. Regards, Andrew. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling GHC
On 11/04/2007, at 7:52 pm, Chris Witte wrote: I made this change but I still get the error unknown symbol `_gettimeofday' I'm using mingw 5.1.3 which as far as i can tell should use the 3.11 runtime. Ensure that HAVE_GETTIMEOFDAY is defined in mk/config.h. Also, I discovered that changes to Linker.c don't make it into ghc.exe if you just do a 'make' in the base directory. You need to make the RTS, then link ghc with the new RTS. The following commands work for me (more typing, but a lot faster than making clean): make -C rts rm compiler/stage2/ghc.exe make -C compiler stage=2 make install Hope that helps. Regards, Andrew. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling GHC
On 13/04/2007, at 11:03 am, Chris Witte wrote: Well that works for the ghc-6.7.20070402 tar ball but if I try and pull down the darcs head it fails to make with ... I wonder what has changed between then and now to cause this. Not sure about that one, I was building ghc-6.6. Darcs should be able to help you find the changes, of course which ones are causing the problem is another story... Regards, Andrew. ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Compiling GHC
On 30/03/2007, at 4:36 pm, Chris Witte wrote: cp -rp ./../include/* /usr/local/include/mingw cp: cannot stat `./../include/*': No such file or directory The source paths for these copies are derived from the path of the gcc binary ($GccDir). Did you call configure with '--with-gcc=C:/ Mingw/bin/gcc.exe'? I received those errors when I forgot to do that. Loading package base ... linking ... ghc.exe: unable to load package `base' ghc.exe: C:/msys/1.0/local/HSbase.o: unknown symbol `_gettimeofday' I think that 'gettimeofday' is statically linked into the ghc executable, so it's just that GHCi doesn't know about it. Adding a: Sym(gettimeofday) \ line to the RTS_MINGW_ONLY_SYMBOLS #define in rts/Linker.c (from line 265) seemed to fix the problem for me. I'm not sure if this is a GHCi bug or something else being awry. 'gettimeofday' was added to the mingwex library in mingw- runtime-3.10, which was released in July last year, so I would have expected this problem to have come up before now... Regards, Andrew. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
