Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
Hi Max, I believe the main reason why ghci isn't available on all platforms is the dynamic linker. I don't think it would be easy (or even feasible) to switch to something like 'ld', though. Some serious problems can be solve this way. This one is a nice example: http://hackage.haskell.org/trac/ghc/ticket/2615 I like the way GHC abstracted from foreign function call interface via libffi. It works on everything where i tried GHC. Would be nice to have exactly the same thing for ELF(and more) loader. AFAIK the current linker is meant to support Mach O, ELF and COFF, which should cover almost every platform GHC is able to run on. Now, it's not ideal that GHC maintains its own dynamic linker implementation, but if someone has discovered a bugs with it (or any other bug preventing TH from working) I'm sure GHC HQ would be interested in knowing. Unfortunately, GHC itself not just 'dlopen's shared objects. It loads them by pieces manually setting up relocations (see makeSymbolExtra by link below). Each operating system on certaion $ARCH defines it's own ELF spec, which consists of two parts: 1. common part. platform agnostic (byte sex, byte width, symbol string table, section flags, dynamic section attributes and etc.) 2. platform dependant. certain section types, such as TOC sections (ppc64), are implemented to solve some certain architecture constraints. You cannot program them in advance. $ grep PPC64 /usr/include/elf.h will show way more fun things to be implemented for perfect .so support. The best thing to make sure is to look at the real support for ELF in ghci: Please, look at file ghc/rtc/Linker.c and function do_Elf_Rela_relocations() http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc;a=headblob;f=/rts/Linker.c Conclusion: having ELF aware system is not enough to have ghci support in any form. Practically, current gentoo supports ghci on: i386, amd64, ppc32, sparc(i'm unsure) and does not support it on: alpha, ia64, ppc64 Ideally, GHC (and haddock as a result) should support 'ghci'less template-haskell support at least on platforms w/o ghci. Or alternatively haddock could be buildable on 'ghci'less GHC. It could ignore template-haskell statements (anyway you will not be able to build 'TH'ful source on such platform) -- Sergei signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
Hi Sergei On 5 August 2010 18:23, Sergei Trofimovich sly...@gmail.com wrote: I like the way GHC abstracted from foreign function call interface via libffi. It works on everything where i tried GHC. Would be nice to have exactly the same thing for ELF(and more) loader. OK, I've put the text of your email on the tracker as 4244 (http://hackage.haskell.org/trac/ghc/ticket/4244) so we don't lose this information. If you can think of anything to add please do so. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hsb2hs preprocessor looking for a maintainer
Hi, out of a discussion in haskell-devscripts, John MacFarlane wrote a very nice tool, called hsb2hs, that allows you to include any binary (or text) file as a constant in your program. This can be useful in various instances, e.g. when creating programs that should not depend on data files installed in the right location, or larger, multi-line strings that you’d like to edit on their own, not as a long string constant in the Haskell file (I once wished I had this when including some CSS in a CGI script written in Haskell). The current code is on http://github.com/jgm/hsb2hs and you can read more about it in the subthread starting at http://lists.debian.org/debian-haskell/2010/08/msg00013.html Unfortunately, John says that he does not have time to develop it further, and I probably don’t either. Is there anyone here interested in picking up the projects? Possible TODOs involve the optimization I suggested in http://lists.debian.org/debian-haskell/2010/08/msg00015.html and making Cabal support .hsb files directly (just as with .y etc. files). Greetings, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
On 4 August 2010 07:42, Joachim Breitner m...@joachim-breitner.de wrote:
out of a discussion in haskell-devscripts, John MacFarlane wrote a very
nice tool, called hsb2hs, that allows you to include any binary (or
text) file as a constant in your program.
When I've needed to do this in the past, I've used a simple bit of
Template Haskell:
module Embed where
import Language.Haskell.TH
embedFile :: String - ExpQ
embedFile fp = runIO (readFile fp) = stringE
Here is how you use it to implement a (cheaty sort of) quine:
{-# LANGUAGE TemplateHaskell #-}
import Embed
foo = $(embedFile UseEmbed.hs)
main = putStrLn foo
Cheers,
Max
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
Hi, Am Mittwoch, den 04.08.2010, 08:05 +0100 schrieb Max Bolingbroke: On 4 August 2010 07:42, Joachim Breitner m...@joachim-breitner.de wrote: out of a discussion in haskell-devscripts, John MacFarlane wrote a very nice tool, called hsb2hs, that allows you to include any binary (or text) file as a constant in your program. When I've needed to do this in the past, I've used a simple bit of Template Haskell: the problem is that Template Haskell does not work on all architectures, so the Debian people prefer solutions that avoid TH if it is not needed. Yet another solution would be to create an ELF file contiangin the binary blob as described in http://burtonini.com/blog/computers/ld-blobs-2007-07-13-15-50 and link to it using FFI. But I’m not sure if there are any gains. Maybe for very large files where even _parsing_ the string literal by ghc takes too long. Greetings, Joachim -- Joachim nomeata Breitner mail: m...@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nome...@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
Joachim Breitner m...@joachim-breitner.de writes: Hi, Am Mittwoch, den 04.08.2010, 08:05 +0100 schrieb Max Bolingbroke: On 4 August 2010 07:42, Joachim Breitner m...@joachim-breitner.de wrote: out of a discussion in haskell-devscripts, John MacFarlane wrote a very nice tool, called hsb2hs, that allows you to include any binary (or text) file as a constant in your program. When I've needed to do this in the past, I've used a simple bit of Template Haskell: the problem is that Template Haskell does not work on all architectures, so the Debian people prefer solutions that avoid TH if it is not needed. Yeah, we've just come across this problem in Gentoo when dealing with how Haddock behaves when there's TH to be documented in some architectures :s -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
On 4 August 2010 11:39, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Joachim Breitner m...@joachim-breitner.de writes: the problem is that Template Haskell does not work on all architectures, so the Debian people prefer solutions that avoid TH if it is not needed. Yeah, we've just come across this problem in Gentoo when dealing with how Haddock behaves when there's TH to be documented in some architectures :s I didn't know this: is there a corresponding GHC ticket? I can't find one, but I could just have chosen the wrong keywords. It seems like the right thing to do would just be to make TH work properly rather than maintain a special-purpose preprocessor. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
Max Bolingbroke batterseapo...@hotmail.com writes: On 4 August 2010 11:39, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Joachim Breitner m...@joachim-breitner.de writes: the problem is that Template Haskell does not work on all architectures, so the Debian people prefer solutions that avoid TH if it is not needed. Yeah, we've just come across this problem in Gentoo when dealing with how Haddock behaves when there's TH to be documented in some architectures :s I didn't know this: is there a corresponding GHC ticket? I can't find one, but I could just have chosen the wrong keywords. It seems like the right thing to do would just be to make TH work properly rather than maintain a special-purpose preprocessor. Not that I know of; all I know is that Sergei (aka slyfox) disabled building documentation (for libraries that come with GHC) on some architectures where ghci isn't available because of this. My understanding is that TH uses ghci (or something like it) to evaluate the expressions, and that when Haddock started understanding TH it also needed to run ghci to build documentation containing TH. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
On 4 August 2010 12:05, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Max Bolingbroke batterseapo...@hotmail.com writes: On 4 August 2010 11:39, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Joachim Breitner m...@joachim-breitner.de writes: the problem is that Template Haskell does not work on all architectures, so the Debian people prefer solutions that avoid TH if it is not needed. Yeah, we've just come across this problem in Gentoo when dealing with how Haddock behaves when there's TH to be documented in some architectures :s I didn't know this: is there a corresponding GHC ticket? I can't find one, but I could just have chosen the wrong keywords. It seems like the right thing to do would just be to make TH work properly rather than maintain a special-purpose preprocessor. Not that I know of; all I know is that Sergei (aka slyfox) disabled building documentation (for libraries that come with GHC) on some architectures where ghci isn't available because of this. My understanding is that TH uses ghci (or something like it) to evaluate the expressions, and that when Haddock started understanding TH it also needed to run ghci to build documentation containing TH. Correct. It also needs to be able to generate machine code from the currently compiled package and its dependencies. This is because ghci does not support some features, in particular unboxed tuples. Therefore, to be on the safe side, Haddock has to create (unoptimised) binary code as well. I believe the main reason why ghci isn't available on all platforms is the dynamic linker. I don't think it would be easy (or even feasible) to switch to something like 'ld', though. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- If it looks like a duck, and quacks like a duck, we have at least to consider the possibility that we have a small aquatic bird of the family Anatidae on our hands. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hsb2hs preprocessor looking for a maintainer
On 4 August 2010 12:34, Thomas Schilling nomin...@googlemail.com wrote: I believe the main reason why ghci isn't available on all platforms is the dynamic linker. I don't think it would be easy (or even feasible) to switch to something like 'ld', though. AFAIK the current linker is meant to support Mach O, ELF and COFF, which should cover almost every platform GHC is able to run on. Now, it's not ideal that GHC maintains its own dynamic linker implementation, but if someone has discovered a bugs with it (or any other bug preventing TH from working) I'm sure GHC HQ would be interested in knowing. Cheers, Max ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
