Folding over short static lists
Hi, a common pattern is x `elem` [a,b,c] or x `elem` "/!#" instead of x == a || x == b || x == c or x == '/' || x == '!' || x == '#'. This used to be also what hlint suggested, although that hint was removed https://github.com/ndmitchell/hlint/issues/31. Upon closer inspection it seems that the compiler is not optimizing the former to the latter (more efficient, as allocation-free) form, which mildly surprised me. I guess the problem is described in this note in GHC/Base.hs: -- The foldr/cons rule looks nice, but it can give disastrously -- bloated code when commpiling -- array (a,b) [(1,2), (2,2), (3,2), ...very long list... ] -- i.e. when there are very very long literal lists -- So I've disabled it for now. We could have special cases -- for short lists, I suppose. -- "foldr/cons" forall k z x xs. foldr k z (x:xs) = k x (foldr k z xs) Now I am quite demanding of my compiler, and in particular I expect it to make a more informed choice here. Is there a good way of making an informed choice here? Up to what length of the list is it a good idea to do this? And can we implement it? Maybe simply with a few static rules for list lengths up to a certain, short length? (Maybe I should try that on a branch and see what perf.haskell.org has to say about it.) Greetings, Joachim -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org signature.asc Description: This is a digitally signed message part ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: -staticlib flag for building standalone static libraries producing very large libraries
On Sat, 2015-03-07 at 22:18 +1100, Sean Seefried wrote: Hi all, Can anyone explain the following problem I'm having? I'm currently writing a game in Haskell. When I produce a plain old executable (for local testing) it's about 23M. However, when I create a static lib using the -staticlib flag it is 54M. Most likely that is because executable contains only necessary/used definitions, while static lib is just an archive of all object files, including all dependencies. Note also that by default core libs are compiled using --split-objs, so when linking executable, all unused top level definitions are filtered out. (And you can decrease size of the executable even more by compiling it and all its dependencies using --split-objs if you are not using it already.) Without the flag, unused definitions are filtered out on per module basis. (I'm not an expert here, so the above description can be partially or totally wrong :) ) Thanks, Yuras Why the discrepancy? Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
-staticlib flag for building standalone static libraries producing very large libraries
Hi all, Can anyone explain the following problem I'm having? I'm currently writing a game in Haskell. When I produce a plain old executable (for local testing) it's about 23M. However, when I create a static lib using the -staticlib flag it is 54M. Why the discrepancy? Sean ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
indeed! Thanks erik! On the paralllel list, edkso shares with us a single commit that adds all the requested features as a user land lib https://github.com/haskell-distributed/distributed-static/commit/d2bd2ebca5a96ea5df621770e98bfb7a3b745bc7 @tweag folks, please do not write personal attacks on the issue tracker, if you find yourself frustrated, I probably am too! please keep a positive constructive tone in all future communications. On Tue, Jan 28, 2014 at 9:20 PM, Erik de Castro Lopo mle...@mega-nerd.comwrote: Mathieu Boespflug wrote: [Sorry for the multiple reposts - couldn't quite figure out which email address doesn't get refused by the list..] Hi Carter, thank you for the good points you raise. I'll try and address each of them as best I can below. 0) I think you could actually implement this proposal as a userland library, at least as you've described it. Have you tried doing so? Indeed, this could be done without touching the compiler at all. We had this response really early on in this discussion. Quite honestly I think that should have been the end of the discussion. The existing GHC release already have a huge workload getting releases out the door and adding to that workload without adding manpower and resources would be a bad idea. You really should try doing this as a library outside of GHC and if GHC needs a few small additional features, they can be added. The `static e` form could as well be a piece of Template Haskell, but making it a proper extension means that the compiler can enforce more invariants and be a bit more helpful to the user. Once it works outside GHC and has proven useful, then it might be worthwhile add small specific, easily testable/maintainable features to GHC to support what goes on on your library. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
For interested fellows, discussion also continues in [1] and [2]. Best, Facundo [1] https://ghc.haskell.org/trac/ghc/ticket/7015 [2] https://groups.google.com/d/topic/parallel-haskell/b-x7VmjlEOw/discussion On Thu, Jan 30, 2014 at 4:47 PM, Carter Schonwald carter.schonw...@gmail.com wrote: indeed! Thanks erik! On the paralllel list, edkso shares with us a single commit that adds all the requested features as a user land lib https://github.com/haskell-distributed/distributed-static/commit/d2bd2ebca5a96ea5df621770e98bfb7a3b745bc7 @tweag folks, please do not write personal attacks on the issue tracker, if you find yourself frustrated, I probably am too! please keep a positive constructive tone in all future communications. On Tue, Jan 28, 2014 at 9:20 PM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Mathieu Boespflug wrote: [Sorry for the multiple reposts - couldn't quite figure out which email address doesn't get refused by the list..] Hi Carter, thank you for the good points you raise. I'll try and address each of them as best I can below. 0) I think you could actually implement this proposal as a userland library, at least as you've described it. Have you tried doing so? Indeed, this could be done without touching the compiler at all. We had this response really early on in this discussion. Quite honestly I think that should have been the end of the discussion. The existing GHC release already have a huge workload getting releases out the door and adding to that workload without adding manpower and resources would be a bad idea. You really should try doing this as a library outside of GHC and if GHC needs a few small additional features, they can be added. The `static e` form could as well be a piece of Template Haskell, but making it a proper extension means that the compiler can enforce more invariants and be a bit more helpful to the user. Once it works outside GHC and has proven useful, then it might be worthwhile add small specific, easily testable/maintainable features to GHC to support what goes on on your library. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
On 01/28/2014 06:03 PM, Carter Schonwald wrote: Theres actually a missing piece of information in this thread: what are the example computations that are being sent? My understanding is that erlang has not way to send file handles, shared variables, Tvars, Mvars, memory mapped binary files, GPU code / memory pointers , and other fun unportable things between nodes, and I don't really expect / see how we can hope to sanely do that in haskell! [...]exactly the same binary, running on a cluster of homogeneous machines with the exact same hardware, with a modern linux distro [...] Nathan Howell was actually doing some experimentation with one strategy for this special case here https://github.com/alphaHeavy/vacuum-tube as a deeply rts twiddling bit of hackery so you could in fact serialize arbitrary closures between homogeneous machines running the exact same code (and with address randomization disabled too i think) When mentioning Nathan's approach (based on foreign primops), let me point to a more complete, RTS-backed implementation; work done by myself and itself based on a long-standing runtime support for a parallel Haskell on distributed memory systems. The latest instance of this rts-based serialisation was reported in the Haskell-implementors' workshop 2013 ( www.haskell.org/wikiupload/2/28/HIW2013PackingAPI.pdf ); code is on github (https://github.com/jberthold/rts-serialisation) Some technical remarks: -Nathan's prim.op approach is awesome, but it is not easy to get its interplay with garbage collection right. It is on my list to take a look at this code again and see how far we can push the envelope. -About address randomisation: The RTS-based serialisation uses relative locations from a known offset to handle it. A more concerning detail is that CAFs must be reverted rather than discarded during GC (currently they are just retained, not satisfactory for long-running code). -About sending arbitrary closures: indeed it does not make any sense to transfer MVars and IORefs (file handles, StablePtrs, etc). My approach is to solve this dynamically by exception handling. I can imagine that there is a sensible combination of RTS support with a suitable type class framework (Static, for one), but lazy evaluation, especially lazy I/O, complicates matters. / Jost Berthold ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
Hi Carter, On Tue, Jan 28, 2014 at 6:03 PM, Carter Schonwald carter.schonw...@gmail.com wrote: Theres actually a missing piece of information in this thread: what are the example computations that are being sent? Quite simply, the same as those considered in the original Cloud Haskell paper, that already advocates the extension that Facundo's first email merely fleshed out a tiny bit. Here's the link once again: Towards Haskell in the Cloud, Jeff Epstein, Andrew P. Black, and Simon Peyton-Jones (2011). http://research.microsoft.com/en-us/um/people/simonpj/papers/parallel/remote.pdf We are emphatically not considering arbitrary closures as you say below, anymore than the original paper does. As such... My understanding is that erlang has not way to send file handles, shared variables, Tvars, Mvars, memory mapped binary files, GPU code / memory pointers , and other fun unportable things between nodes, and I don't really expect / see how we can hope to sanely do that in haskell! ... the above is completely impossible. The original paper explains why this is so (see Sections 2.3 and 5.1). Here's the gist: 1. you can only send remotely serializable values, i.e. that have an instance of class Serializable. 2. none of the above have a Serializable instance, and are hence not send-able. When it comes to sending closures capturing any of the above types of values, the reasoning goes like this: 3. a closure in the sense of CH is a pair of a static value and an environment, 4. a closure can only be sent if it is serializable, 5. a closure is serializable only if its its environment can be serialized, 5. its environment can be serialized only if all free variables of the closure can, 6. none of the above have a Serializable instance, 7. hence any closure capturing file handles, MVars, memory pointers, etc cannot be sent. point in fact, even when restricted to exactly the same binary, running on a cluster of homogeneous machines with the exact same hardware, with a modern linux distro you hit some gnarly problems doing this for arbitrary closures! Its for a very simple (and fun) reason: address randomization! Which is why neither we nor the original paper considered using addresses as labels for static values. We use linker labels, which are stable. on the GHC API front, http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/DynamicLoading.html along with (and more appropriately http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html ) should actually give enough basic tooling to make this possible as a userland library, mind you unload was recently fixed up in HEAD by Simon Marlow to support the dynamic code loading / unloading use case he has in facebook. Point being the GHC 7.8 version of the ObjLink api should actually give enough support tooling to prototype this idea in user land, and that plus better support for writing direct haskell code and getting out both a local computation and an AST we can serialize would probably be a good set of primitives for making this feasible in user land. I For the third time: we can of course use any linker API that the system or the compiler happens to provide, so long as it allows resolving linker symbols to Haskell values. The (small) extension under consideration does not replace or add to any existing linker API. It just transparently floats closed expressions to the top-level, makes sure linker symbols will exist at runtime (they currently don't always do), and does some basic sanity checks so the user doesn't lose his. I listed problems labeled 1a), 1b) and 2) in my previous email. You still haven't showed us how to address those in pure TH userland. In Fact, because in general not every computation will be properly serializable, you need not even bother with tracking an explicit symbol table on each side, just try to load it at a given type and if it fails it wasn't there! The point being, linkers are a thing, ghc exposes an API for linking, have you tried that api? http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html Yes we have. But I don't see how using it or not using it makes any difference to the user interface of the proposed compiler extension. It's an implementation detail with tradeoffs that Facundo could explain in detail in GHC ticket #8711 if you hadn't rudely closed it as a duplicate of some future and unspecified work of yours. Best, Mathieu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
Hi Eric, On Wed, Jan 29, 2014 at 3:20 AM, Erik de Castro Lopo mle...@mega-nerd.com wrote: Mathieu Boespflug wrote: thank you for the good points you raise. I'll try and address each of them as best I can below. 0) I think you could actually implement this proposal as a userland library, at least as you've described it. Have you tried doing so? Indeed, this could be done without touching the compiler at all. We had this response really early on in this discussion. Quite honestly I think that should have been the end of the discussion. The response you quote above comes in context, which includes the sentence you also quote below. In another email, the problems we face with a pure TH implementation are labeled as 1a), 1b), 2). We'd be very happy if you could show us how to solve those problems using TH alone in a way that does not impact user friendliness and static checking of invariants in any way. The existing GHC release already have a huge workload getting releases out the door and adding to that workload without adding manpower and resources would be a bad idea. You really should try doing this as a library outside of GHC and if GHC needs a few small additional features, they can be added. The `static e` form could as well be a piece of Template Haskell, but making it a proper extension means that the compiler can enforce more invariants and be a bit more helpful to the user. Once it works outside GHC and has proven useful, then it might be worthwhile add small specific, easily testable/maintainable features to GHC to support what goes on on your library. I for one very much agree with all the principles state above. But the wider context of the discussion is that we already have such a TH userland solution today, implemented in packages distributed-static and distributed-process. We already have several users, including in the industry (to my knowledge Parallel Scientific for over a year, Tweag I/O for a couple of months, probably others...). The proposal to go ahead and implement an idea that was first presented in the original Cloud Haskell paper was borne out of frustration with the existing approach based on remote tables, which are very error prone in practice, and the operational experience that I, Facundo, Tim and others have had showing that making the semantics of distributed computation depend on *all* modules across several packages being compiled with the right incantation of compiler flags without any kind of static checking is a problem, especially for beginners. Is there something in the proposed extension that leads you to believe that is neither small nor specific, or that it would not be easily testable, or maintainable? If so, we could amend it accordingly. Best, Mathieu ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
Hello, I'd just like to say I haven't gone over every discussion in this thread and had time to digest it all - I thought I would just highlight a minor technicality. On Fri, Jan 24, 2014 at 11:19 AM, Facundo Domínguez facundo.doming...@tweag.io wrote: Looking up static references `unstatic` is implemented as a function which finds a top-level value from the `GlobalName`, otherwise it raises an exception. It crucially relies on leveraging the system’s dynamic linker, so out-of-the-box only works with dynamically linked binaries (but see below). `unstatic` proceeds as follows: * Determines the name of the shared library from the package name and the package version. * Determines the symbol of the value by Z-Encoding the package name, the module name and the value name. * Uses the system’s dynamic linker interface to obtain the address of the symbol. * Converts the symbol to a haskell value with `GHC.Prim.addrToAny#` In principle, only symbols in shared libraries can be found. However, the dynamic linker is able to find symbols in modules that are linked statically if GHC is fed with the option -optl-Wl,--export-dynamic. A future enhancement could be to have GHC warn the user when modules using the extension are linked statically and this option is not used during linking. GHC only defines symbols for exported definitions in modules. So unstatic won’t be able to find the private bindings of a module. For this sake, the implementation of static should in addition ensure that the bindings it gets will appear in the symbol table when they are not exported by their defining modules. Regarding -optl-Wl,--export-dynamic for static builds, and all that jazz - if I am understanding you right, note that Windows is a bit particular here, because there is a hard limit on the number of symbols allowed in a DLL. That means forcefully exporting *everything* could quickly get you to the symbol limit with the dynamic linker with large-ish applications (one exported function or data type may result in a handful of exported symbols created.) If you want to see the pain this has caused GHC itself, please see GHC bug #5987[1], which makes dynamic support on windows difficult - it's currently disabled now anyway. Furthermore, dynamic DLLs on Windows are a bit tricky anyway as the loader is fundamentally different from your typical ld.so (which there are ways around[2], but a bit nasty as you have to hack the COFF file.) Windows unfortunately isn't in an easy position here, but it's improving and it would be unfortunate to neglect it. This restriction does not exist with the static linker inside the RTS, so my suggestion, I guess, is that I'm inclined to want this to work for *both* static/dynamic configurations out of the box without hackery, if at all possible, which would be great for Windows users especially until the dynamic story is back up to scratch. [1] https://ghc.haskell.org/trac/ghc/ticket/5987 [2] http://blog.omega-prime.co.uk/?p=138 As the application depends on shared libraries, now a tool to collect these libraries would be required so they can be distributed together with the executable binary when deploying a Cloud Haskell application in a cluster. We won’t delve further into this problem. And for any people interested in this - on Linux, a tool like patchelf[3] would help immensely for moving executables+their dependencies around in a 'bundle' style way. [3] http://nixos.org/patchelf.html -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
Hi Austin, this is very useful information, thanks. So it seems that the rts linker is here to stay for a while longer still, at least because there is no good alternative on Windows as of yet. If I understand you correctly, on Windows dynamic linking is not an option in part because of the number-of-exported-symbols limit, and when linking statically one hits the same limit if stuff like -optl-Wl,--export-dynamic is used. So at least on Windows, the only way out is the rts linker. Supporting both linkers is certainly an option. If I remember correctly, the issue Facundo found with the rts linker is that to use it for looking up symbol addresses, you apparently need to have an object file loaded twice, effectively (once statically linked at build time, the second time through the rts linker at runtime for doing the lookups). Maybe there's a way around that, or that could be added? In any case for platforms with no alternative, like Windows, I guess double loading is a tolerable price to pay. Best, Mathieu On Wed, Jan 29, 2014 at 12:11 PM, Austin Seipp aus...@well-typed.com wrote: Hello, I'd just like to say I haven't gone over every discussion in this thread and had time to digest it all - I thought I would just highlight a minor technicality. On Fri, Jan 24, 2014 at 11:19 AM, Facundo Domínguez facundo.doming...@tweag.io wrote: Looking up static references `unstatic` is implemented as a function which finds a top-level value from the `GlobalName`, otherwise it raises an exception. It crucially relies on leveraging the system's dynamic linker, so out-of-the-box only works with dynamically linked binaries (but see below). `unstatic` proceeds as follows: * Determines the name of the shared library from the package name and the package version. * Determines the symbol of the value by Z-Encoding the package name, the module name and the value name. * Uses the system's dynamic linker interface to obtain the address of the symbol. * Converts the symbol to a haskell value with `GHC.Prim.addrToAny#` In principle, only symbols in shared libraries can be found. However, the dynamic linker is able to find symbols in modules that are linked statically if GHC is fed with the option -optl-Wl,--export-dynamic. A future enhancement could be to have GHC warn the user when modules using the extension are linked statically and this option is not used during linking. GHC only defines symbols for exported definitions in modules. So unstatic won't be able to find the private bindings of a module. For this sake, the implementation of static should in addition ensure that the bindings it gets will appear in the symbol table when they are not exported by their defining modules. Regarding -optl-Wl,--export-dynamic for static builds, and all that jazz - if I am understanding you right, note that Windows is a bit particular here, because there is a hard limit on the number of symbols allowed in a DLL. That means forcefully exporting *everything* could quickly get you to the symbol limit with the dynamic linker with large-ish applications (one exported function or data type may result in a handful of exported symbols created.) If you want to see the pain this has caused GHC itself, please see GHC bug #5987[1], which makes dynamic support on windows difficult - it's currently disabled now anyway. Furthermore, dynamic DLLs on Windows are a bit tricky anyway as the loader is fundamentally different from your typical ld.so (which there are ways around[2], but a bit nasty as you have to hack the COFF file.) Windows unfortunately isn't in an easy position here, but it's improving and it would be unfortunate to neglect it. This restriction does not exist with the static linker inside the RTS, so my suggestion, I guess, is that I'm inclined to want this to work for *both* static/dynamic configurations out of the box without hackery, if at all possible, which would be great for Windows users especially until the dynamic story is back up to scratch. [1] https://ghc.haskell.org/trac/ghc/ticket/5987 [2] http://blog.omega-prime.co.uk/?p=138 As the application depends on shared libraries, now a tool to collect these libraries would be required so they can be distributed together with the executable binary when deploying a Cloud Haskell application in a cluster. We won't delve further into this problem. And for any people interested in this - on Linux, a tool like patchelf[3] would help immensely for moving executables+their dependencies around in a 'bundle' style way. [3] http://nixos.org/patchelf.html -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ -- Mathieu Boespflug Founder at http://tweag.io. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
To address the concerns about static linking and portability, there is also the alternative of of using the RTS linker in those platforms that need it. In many aspects, neither linker makes a big difference to us. We are going with the system's dynamic linker mainly because GHC team has expressed the desire to get rid of the RTS linker. Using the RTS linker would require addressing some additional technical issues, none of which appear to be show-stoppers. It would be just more work. Best, Facundo On Mon, Jan 27, 2014 at 2:20 PM, Tim Watson watson.timo...@gmail.com wrote: Hi Brandon, On 26 Jan 2014, at 19:01, Brandon Allbery wrote: On Sun, Jan 26, 2014 at 1:43 PM, Tim Watson watson.timo...@gmail.com wrote: In Erlang, I can rpc/send *any* term and evaluate it on another node. That includes functions of course. Whether or not we want to be quite that general is another matter, but that is the comparison I've been making. Note that Erlang gets away with this through being a virtual machine architecture; BEAM is about as write-once-run-anywhere as it gets, and the platform specifics are abstracted by the BEAM VM interpreter. You just aren't going to accomplish this with a native compiled language, without encoding as a virtual machine yourself (that is, the AST-based mechanisms). Yeah, I do realise this. Of course we're not trying to reproduce the BEAM really, but what we /do/ want is to be able to do is exchange messages between nodes that are not running the same executable. The proposal does appear to address this requirement, at least to some extent. There may be complementary (or better) approaches. I believe Carter is going to provide some additional details viz his work in this area at some point. Anything that reduces the amount of Template Haskell required to work with Cloud Haskell is a good thing (tm) IMO. Not that I mind using TH, but the programming model is currently quite awkward from the caller's perspective, since you've got to (a) create a Static/Closure out of potentially complex chunks of code, which often involves creating numerous top level wrapper APIs and (b) fiddle around with the remote-table (both in the code that defines remote-able thunks *and* in the code that starts a node wishing to operate on them. Also note that this problem isn't limited to sending code around the network. Just sending arbitrary *data* between nodes is currently discouraged (though not disallowed) because the receiving program *might* not understand the types you're sending it. This is very restrictive and the proposal does, at the very least, allow us to safely serialise, send and receive types that both programs know about by virtue of having been linked to the same library/libraries. But yes - there are certainly constraints and edge cases aplenty here. I'm not entirely sure whether or not we'd need to potentially change the (binary) encoding of raw messages in distributed-process, for example, in response to this change. Currently we serialise a pointer (i.e., the pointer to the fingerprint for the type that's being sent), and I can imagine that not working properly across different nodes running on different architectures etc. Perhaps you should consider fleshing out ghc's current bytecode support to be a full VM? After discussing this with Simon M, we concluded there was little point in doing so. The GHC RTS is practically a VM anyway, and there's probably not that much value to be gained by shipping bytecode around. Besides, as you put it, the AST-based mechanisms allow for this anyway (albeit with some coding required on the part of the application developer) and Carter (and others) assure me that the mechanisms required to do this kind of thing already exist. We just need to find the right way to take advantage of them. Or perhaps an interesting alternative would be a BEAM backend for ghc. I've talked to a couple of people that want to try this. I'm intrigued, but have other things to focus on. :) Cheers, Tim ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
Hi Carter, Tim, On Sat, Jan 25, 2014 at 7:12 PM, Carter Schonwald carter.schonw...@gmail.com wrote: anyways 1) you should (once 7.8 is out) evaluate how far you can push your ideas wrt dynamic loading as a user land library. If you can't make it work as a library and can demonstrate why (or how even though it works its not quite satisfactory), thats signals something! Signals what? On Sun, Jan 26, 2014 at 7:43 PM, Tim Watson watson.timo...@gmail.com wrote: Is that something you'll consider looking at Matthieu? We would prefer to do it that way, to be honest. As explained in my previous email, we identified two problems with this approach: 1) User friendliness. It's important for us that Cloud Haskell be pretty much as user friendly and easy to use as Erlang is. a) I don't know that it's possible from Template Haskell to detect and warn the user when dependent modules have not been compiled into dynamic object code or into static code with the right flags. b) It's very convenient in practice to be able to send not just `f` if `f` is a global identifier, but in general `e` where `e` is any closed expression mentioning only global names. That can easily be done by having the compiler float the expression `e` to the top-level and give it a global name. I don't see how to do that in TH in a user friendly way. 2) A technical issue: you ought to be able to send unexported functions across the wire, just as you can pass unexported functions as arguments to higher-order functions. Yet GHC does not create linker symbols for unexported identifiers, so our approach would break down. Worse, I don't think that it's even possible to detect in TH whether an identifier is exported or not, in order to warn the user. One could imagine a compiler flag to force the creation of linker symbols for all toplevel bindings, exported or unexported. But that seems wasteful, and potentially not very user friendly. If the above can be solved, all the better! If not: we don't always want to touch the compiler, but when we do, ideally it should be in an unintrusive way. I contend our proposal fits that criterion. And our cursory implementation efforts seem to confirm that so far. But I really think insisting that the linker symbol names denote the datum agreement in a distributed system is punting on what should be handled at the application level. Simon Marlow put some improvements into GHC to help improve doing dynamic code (un)loading, stress test that! We could use either the system linker or rts linker. Not sure that it makes any difference at the application level. 2) I've a work in progress on specing out a proper (and sound :) ) static values type extension for ghc, that will be usable perhaps in your your case (though by dint of being sound, will preclude some of the things you think you want). I look forward to hearing more about that. How is the existing proposal not (type?) sound? BUT, any type system changes need to actually provide safety. To be clear, this proposal doesn't touch the type checker in any way. As for *how* to send an AST fragment, edward kmett and other have some pretty nice typed AST models that are easy to adapt and extend for an application specific use case. Bound http://hackage.haskell.org/package/bound is one nice one. heres a really really good school of haskell exposition https://www.fpcomplete.com/user/edwardk/bound These are nice encodings for AST's. But they don't address how to minimize the amount of code to ship around the cluster. If you have no agreement about what functions are commonly available, then the AST needs to include the code for the function you are sending, + any functions it depends, + any of their dependencies, and so on transitively. Tim, perhaps the following also answers some of your questions. This is where the current proposal comes in: if you choose to ship around AST's, you can minimize their size by having them mention shared linker symbol names. Mind, that's already possible today, by means of the global RemoteTable, but it's building that remote table safely, conveniently, in a modular way, and with static checking that no symbols from any of the modules that were linked at build time were missed, that is difficult. By avoiding a RemoteTable entirely, we avoid having to solve that difficult problem. :) Best, -- Mathieu Boespflug Founder at http://tweag.io. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
Hi Mathieu, On 28 Jan 2014, at 12:53, Mathieu Boespflug wrote: We would prefer to do it that way, to be honest. As explained in my previous email, we identified two problems with this approach: 1) User friendliness. It's important for us that Cloud Haskell be pretty much as user friendly and easy to use as Erlang is. Exactly! a) I don't know that it's possible from Template Haskell to detect and warn the user when dependent modules have not been compiled into dynamic object code or into static code with the right flags. I don't think that it is, from what I've seen, though I'm by no means an expert. b) It's very convenient in practice to be able to send not just `f` if `f` is a global identifier, but in general `e` where `e` is any closed expression mentioning only global names. That can easily be done by having the compiler float the expression `e` to the top-level and give it a global name. I don't see how to do that in TH in a user friendly way. Agreed. 2) A technical issue: you ought to be able to send unexported functions across the wire, just as you can pass unexported functions as arguments to higher-order functions. Yet GHC does not create linker symbols for unexported identifiers, so our approach would break down. Worse, I don't think that it's even possible to detect in TH whether an identifier is exported or not, in order to warn the user. One could imagine a compiler flag to force the creation of linker symbols for all toplevel bindings, exported or unexported. But that seems wasteful, and potentially not very user friendly. Interesting. If the above can be solved, all the better! If not: we don't always want to touch the compiler, but when we do, ideally it should be in an unintrusive way. I contend our proposal fits that criterion. And our cursory implementation efforts seem to confirm that so far. Good! But I really think insisting that the linker symbol names denote the datum agreement in a distributed system is punting on what should be handled at the application level. Simon Marlow put some improvements into GHC to help improve doing dynamic code (un)loading, stress test that! We could use either the system linker or rts linker. Not sure that it makes any difference at the application level. No indeed. 2) I've a work in progress on specing out a proper (and sound :) ) static values type extension for ghc, that will be usable perhaps in your your case (though by dint of being sound, will preclude some of the things you think you want). I look forward to hearing more about that. +1 How is the existing proposal not (type?) sound? I'd like to hear more about the concerns too. As for *how* to send an AST fragment, edward kmett and other have some pretty nice typed AST models that are easy to adapt and extend for an application specific use case. Bound http://hackage.haskell.org/package/bound is one nice one. heres a really really good school of haskell exposition https://www.fpcomplete.com/user/edwardk/bound These are nice encodings for AST's. But they don't address how to minimize the amount of code to ship around the cluster. If you have no agreement about what functions are commonly available, then the AST needs to include the code for the function you are sending, + any functions it depends, + any of their dependencies, and so on transitively. That was precisely my concern with the idea of shipping *something* AST-like around. It's a lot of overhead for every application you want to develop, or a *massive* overhead to cover all bases. Tim, perhaps the following also answers some of your questions. This is where the current proposal comes in: if you choose to ship around AST's, you can minimize their size by having them mention shared linker symbol names. Indeed, that does seem to simplify things. Mind, that's already possible today, by means of the global RemoteTable, but it's building that remote table safely, conveniently, in a modular way, and with static checking that no symbols from any of the modules that were linked at build time were missed, that is difficult. Yep. It's awkward and when you get it wrong, you're either fighting with TH-obscured compiler errors or worse, the damn thing just doesn't work (because you can't decode properly on the remote node and things just crash, or worse still, just hang on waiting for the *correct* input types, which never arrive because they're not known to the RTS). By avoiding a RemoteTable entirely, we avoid having to solve that difficult problem. :) Not having a RemoteTable sounds like a plus to me. Cheers, Tim ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
Theres actually a missing piece of information in this thread: what are the example computations that are being sent? My understanding is that erlang has not way to send file handles, shared variables, Tvars, Mvars, memory mapped binary files, GPU code / memory pointers , and other fun unportable things between nodes, and I don't really expect / see how we can hope to sanely do that in haskell! point in fact, even when restricted to exactly the same binary, running on a cluster of homogeneous machines with the exact same hardware, with a modern linux distro you hit some gnarly problems doing this for arbitrary closures! Its for a very simple (and fun) reason: address randomization! Nathan Howell was actually doing some experimentation with one strategy for this special case here https://github.com/alphaHeavy/vacuum-tube as a deeply rts twiddling bit of hackery so you could in fact serialize arbitrary closures between homogeneous machines running the exact same code (and with address randomization disabled too i think) on the GHC API front, http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/DynamicLoading.htmlalong with (and more appropriately http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html) should actually give enough basic tooling to make this possible as a userland library, mind you unload was recently fixed up in HEAD by Simon Marlow to support the dynamic code loading / unloading use case he has in facebook. Point being the GHC 7.8 version of the ObjLink api should actually give enough support tooling to prototype this idea in user land, and that plus better support for writing direct haskell code and getting out both a local computation and an AST we can serialize would probably be a good set of primitives for making this feasible in user land. I The meat of my point is 1) yes I want this too but also 2) one thing I really have come to appreciate about how GHC is engineered is a lot of work is done to provide the right primitives so that really really great tools can be built in user land. I think That the goal of this proposal can be accomplished quite nicely with the ObjLink module, unless i'm not understanding something. In Fact, because in general not every computation will be properly serializable, you need not even bother with tracking an explicit symbol table on each side, just try to load it at a given type and if it fails it wasn't there! The point being, linkers are a thing, ghc exposes an API for linking, have you tried that api? http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html On Tue, Jan 28, 2014 at 10:21 AM, Brandon Allbery allber...@gmail.comwrote: On Tue, Jan 28, 2014 at 7:53 AM, Mathieu Boespflug m...@tweag.io wrote: On Sat, Jan 25, 2014 at 7:12 PM, Carter Schonwald carter.schonw...@gmail.com wrote: 1) you should (once 7.8 is out) evaluate how far you can push your ideas wrt dynamic loading as a user land library. If you can't make it work as a library and can demonstrate why (or how even though it works its not quite satisfactory), thats signals something! Signals what? That there is a shortcoming in ghc and/or the rts that needs to be addressed. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
Hello Carter, Thanks for the links. IIUC the ObjLink module contains an interface to the RTS linker. The points raised by Mathieu in his last email as (1a), (1b) and (2) still hold. Here's a use case for (2): module Communicate(run) import Control.Distributed.Process f :: Int - Int f = id runSend :: Process () runSend = send someone (static f) runExpect :: Int - Process Int runExpect n = fmap (($ n) . unstatic) expect If any program tries to use runExpect, it would fail at runtime because it would fail to find `f`, because `f` is not exported and therefore a symbol for it would not appear in object files. The solution that modifies the compiler is superior to all workarounds we could think of to workaround this problem with a library. Any suggestions? Best, Facundo On Tue, Jan 28, 2014 at 3:03 PM, Carter Schonwald carter.schonw...@gmail.com wrote: Theres actually a missing piece of information in this thread: what are the example computations that are being sent? My understanding is that erlang has not way to send file handles, shared variables, Tvars, Mvars, memory mapped binary files, GPU code / memory pointers , and other fun unportable things between nodes, and I don't really expect / see how we can hope to sanely do that in haskell! point in fact, even when restricted to exactly the same binary, running on a cluster of homogeneous machines with the exact same hardware, with a modern linux distro you hit some gnarly problems doing this for arbitrary closures! Its for a very simple (and fun) reason: address randomization! Nathan Howell was actually doing some experimentation with one strategy for this special case here https://github.com/alphaHeavy/vacuum-tube as a deeply rts twiddling bit of hackery so you could in fact serialize arbitrary closures between homogeneous machines running the exact same code (and with address randomization disabled too i think) on the GHC API front, http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/DynamicLoading.html along with (and more appropriately http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html ) should actually give enough basic tooling to make this possible as a userland library, mind you unload was recently fixed up in HEAD by Simon Marlow to support the dynamic code loading / unloading use case he has in facebook. Point being the GHC 7.8 version of the ObjLink api should actually give enough support tooling to prototype this idea in user land, and that plus better support for writing direct haskell code and getting out both a local computation and an AST we can serialize would probably be a good set of primitives for making this feasible in user land. I The meat of my point is 1) yes I want this too but also 2) one thing I really have come to appreciate about how GHC is engineered is a lot of work is done to provide the right primitives so that really really great tools can be built in user land. I think That the goal of this proposal can be accomplished quite nicely with the ObjLink module, unless i'm not understanding something. In Fact, because in general not every computation will be properly serializable, you need not even bother with tracking an explicit symbol table on each side, just try to load it at a given type and if it fails it wasn't there! The point being, linkers are a thing, ghc exposes an API for linking, have you tried that api? http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html On Tue, Jan 28, 2014 at 10:21 AM, Brandon Allbery allber...@gmail.com wrote: On Tue, Jan 28, 2014 at 7:53 AM, Mathieu Boespflug m...@tweag.io wrote: On Sat, Jan 25, 2014 at 7:12 PM, Carter Schonwald carter.schonw...@gmail.com wrote: 1) you should (once 7.8 is out) evaluate how far you can push your ideas wrt dynamic loading as a user land library. If you can't make it work as a library and can demonstrate why (or how even though it works its not quite satisfactory), thats signals something! Signals what? That there is a shortcoming in ghc and/or the rts that needs to be addressed. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
Escuse me, the module export list was meant to be module Communicate(runExpect, runSend) where Facundo On Tue, Jan 28, 2014 at 5:13 PM, Facundo Domínguez facundo.doming...@tweag.io wrote: Hello Carter, Thanks for the links. IIUC the ObjLink module contains an interface to the RTS linker. The points raised by Mathieu in his last email as (1a), (1b) and (2) still hold. Here's a use case for (2): module Communicate(run) import Control.Distributed.Process f :: Int - Int f = id runSend :: Process () runSend = send someone (static f) runExpect :: Int - Process Int runExpect n = fmap (($ n) . unstatic) expect If any program tries to use runExpect, it would fail at runtime because it would fail to find `f`, because `f` is not exported and therefore a symbol for it would not appear in object files. The solution that modifies the compiler is superior to all workarounds we could think of to workaround this problem with a library. Any suggestions? Best, Facundo On Tue, Jan 28, 2014 at 3:03 PM, Carter Schonwald carter.schonw...@gmail.com wrote: Theres actually a missing piece of information in this thread: what are the example computations that are being sent? My understanding is that erlang has not way to send file handles, shared variables, Tvars, Mvars, memory mapped binary files, GPU code / memory pointers , and other fun unportable things between nodes, and I don't really expect / see how we can hope to sanely do that in haskell! point in fact, even when restricted to exactly the same binary, running on a cluster of homogeneous machines with the exact same hardware, with a modern linux distro you hit some gnarly problems doing this for arbitrary closures! Its for a very simple (and fun) reason: address randomization! Nathan Howell was actually doing some experimentation with one strategy for this special case here https://github.com/alphaHeavy/vacuum-tube as a deeply rts twiddling bit of hackery so you could in fact serialize arbitrary closures between homogeneous machines running the exact same code (and with address randomization disabled too i think) on the GHC API front, http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/DynamicLoading.html along with (and more appropriately http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html ) should actually give enough basic tooling to make this possible as a userland library, mind you unload was recently fixed up in HEAD by Simon Marlow to support the dynamic code loading / unloading use case he has in facebook. Point being the GHC 7.8 version of the ObjLink api should actually give enough support tooling to prototype this idea in user land, and that plus better support for writing direct haskell code and getting out both a local computation and an AST we can serialize would probably be a good set of primitives for making this feasible in user land. I The meat of my point is 1) yes I want this too but also 2) one thing I really have come to appreciate about how GHC is engineered is a lot of work is done to provide the right primitives so that really really great tools can be built in user land. I think That the goal of this proposal can be accomplished quite nicely with the ObjLink module, unless i'm not understanding something. In Fact, because in general not every computation will be properly serializable, you need not even bother with tracking an explicit symbol table on each side, just try to load it at a given type and if it fails it wasn't there! The point being, linkers are a thing, ghc exposes an API for linking, have you tried that api? http://www.haskell.org/ghc/docs/latest/html/libraries/ghc-7.6.3/ObjLink.html On Tue, Jan 28, 2014 at 10:21 AM, Brandon Allbery allber...@gmail.com wrote: On Tue, Jan 28, 2014 at 7:53 AM, Mathieu Boespflug m...@tweag.io wrote: On Sat, Jan 25, 2014 at 7:12 PM, Carter Schonwald carter.schonw...@gmail.com wrote: 1) you should (once 7.8 is out) evaluate how far you can push your ideas wrt dynamic loading as a user land library. If you can't make it work as a library and can demonstrate why (or how even though it works its not quite satisfactory), thats signals something! Signals what? That there is a shortcoming in ghc and/or the rts that needs to be addressed. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
Mathieu Boespflug wrote: [Sorry for the multiple reposts - couldn't quite figure out which email address doesn't get refused by the list..] Hi Carter, thank you for the good points you raise. I'll try and address each of them as best I can below. 0) I think you could actually implement this proposal as a userland library, at least as you've described it. Have you tried doing so? Indeed, this could be done without touching the compiler at all. We had this response really early on in this discussion. Quite honestly I think that should have been the end of the discussion. The existing GHC release already have a huge workload getting releases out the door and adding to that workload without adding manpower and resources would be a bad idea. You really should try doing this as a library outside of GHC and if GHC needs a few small additional features, they can be added. The `static e` form could as well be a piece of Template Haskell, but making it a proper extension means that the compiler can enforce more invariants and be a bit more helpful to the user. Once it works outside GHC and has proven useful, then it might be worthwhile add small specific, easily testable/maintainable features to GHC to support what goes on on your library. Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
Hi Brandon, On 26 Jan 2014, at 19:01, Brandon Allbery wrote: On Sun, Jan 26, 2014 at 1:43 PM, Tim Watson watson.timo...@gmail.com wrote: In Erlang, I can rpc/send *any* term and evaluate it on another node. That includes functions of course. Whether or not we want to be quite that general is another matter, but that is the comparison I've been making. Note that Erlang gets away with this through being a virtual machine architecture; BEAM is about as write-once-run-anywhere as it gets, and the platform specifics are abstracted by the BEAM VM interpreter. You just aren't going to accomplish this with a native compiled language, without encoding as a virtual machine yourself (that is, the AST-based mechanisms). Yeah, I do realise this. Of course we're not trying to reproduce the BEAM really, but what we /do/ want is to be able to do is exchange messages between nodes that are not running the same executable. The proposal does appear to address this requirement, at least to some extent. There may be complementary (or better) approaches. I believe Carter is going to provide some additional details viz his work in this area at some point. Anything that reduces the amount of Template Haskell required to work with Cloud Haskell is a good thing (tm) IMO. Not that I mind using TH, but the programming model is currently quite awkward from the caller's perspective, since you've got to (a) create a Static/Closure out of potentially complex chunks of code, which often involves creating numerous top level wrapper APIs and (b) fiddle around with the remote-table (both in the code that defines remote-able thunks *and* in the code that starts a node wishing to operate on them. Also note that this problem isn't limited to sending code around the network. Just sending arbitrary *data* between nodes is currently discouraged (though not disallowed) because the receiving program *might* not understand the types you're sending it. This is very restrictive and the proposal does, at the very least, allow us to safely serialise, send and receive types that both programs know about by virtue of having been linked to the same library/libraries. But yes - there are certainly constraints and edge cases aplenty here. I'm not entirely sure whether or not we'd need to potentially change the (binary) encoding of raw messages in distributed-process, for example, in response to this change. Currently we serialise a pointer (i.e., the pointer to the fingerprint for the type that's being sent), and I can imagine that not working properly across different nodes running on different architectures etc. Perhaps you should consider fleshing out ghc's current bytecode support to be a full VM? After discussing this with Simon M, we concluded there was little point in doing so. The GHC RTS is practically a VM anyway, and there's probably not that much value to be gained by shipping bytecode around. Besides, as you put it, the AST-based mechanisms allow for this anyway (albeit with some coding required on the part of the application developer) and Carter (and others) assure me that the mechanisms required to do this kind of thing already exist. We just need to find the right way to take advantage of them. Or perhaps an interesting alternative would be a BEAM backend for ghc. I've talked to a couple of people that want to try this. I'm intrigued, but have other things to focus on. :) Cheers, Tim___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
On 25 Jan 2014, at 18:12, Carter Schonwald wrote: 1) you should (once 7.8 is out) evaluate how far you can push your ideas wrt dynamic loading as a user land library. If you can't make it work as a library and can demonstrate why (or how even though it works its not quite satisfactory), thats signals something! Is that something you'll consider looking at Matthieu? Theres quite a few industrial haskell shops that provide products / services where internally they do runtime dynamic loading of user provided object files, so i'm sure that the core GHC support is there if you actually dig into the apis! And they do this in a distributed systems context, sans CH. We have a pull request from Edsko that melds hs-plugins support with static, as per the original proposal's notes, so this seems like a corollary issue to me. 2) I've a work in progress on specing out a proper (and sound :) ) static values type extension for ghc, that will be usable perhaps in your your case (though by dint of being sound, will preclude some of the things you think you want). BUT, any type system changes need to actually provide safety. My motivation for having a notion of static values comes from a desire to add compiler support for certain numerical computing operations that require compiler support to be usable in haskell. BUT, much of the same work Timescales? There are commercial users of Cloud Haskell clamouring for improvements to the way we handle this situation, and I'm keen to combine getting broader community agreements about the right thing to do with facilitating our users real needs. If there are other options pertaining to static support, I'd like to know more! @tim: what on earth does sending arbitrary code mean? I feel like the more precise thing everyone here wants is for a given application / infrastructure deployment, I would to be able to send my application specific computations over the network, using cloud haskell, and be sure that both sides think its the same code. With Cloud Haskell in its current guise, I can Closure up pretty any thunk I like and spawn it on a remote node. If the node's are both running the same executable, we're fine. If they're not, we're potentially in trouble. In Erlang, I can rpc/send *any* term and evaluate it on another node. That includes functions of course. Whether or not we want to be quite that general is another matter, but that is the comparison I've been making. As for *how* to send an AST fragment, edward kmett and other have some pretty nice typed AST models that are easy to adapt and extend for an application specific use case. Bound http://hackage.haskell.org/package/bound is one nice one. heres a really really good school of haskell exposition https://www.fpcomplete.com/user/edwardk/bound And theres a generalization that supports strong typing that i've copied from an hpaste https://gist.github.com/cartazio/5727196, where its notable that the AST data type is called Remote :), I think thats a hint its meant to be a haskell manipulable way of constructing a typed DSL you can serialize using a finally tagless style api approach (ie have a set of type class instances / operations that you use to run the computation and/or construct the AST you can send over the wire) These are all lovely, but aren't we talking about either (a) putting together an AST to represent whatever valid Haskell program someone wants to send, or (b) forcing every application developer to write an AST to cover all their remote computations. Both of those sound like a lot more work than the proposal below. They may be the right approach from some domains, but there is a fair bit of developer overhead involved from what I can see. On Fri, Jan 24, 2014 at 3:19 PM, Mathieu Boespflug 0xbadc...@gmail.com wrote: The `static e` form could as well be a piece of Template Haskell, but making it a proper extension means that the compiler can enforce more invariants and be a bit more helpful to the user. In particular, detecting situations where symbolic references cannot be generated because e.g. the imported packages were not compiled as dynamic linked libraries. Or seamlessly supporting calling `static f` on an idenfier `f` that is not exported by the module. All of which sound like a usability improvement to me. I very much subscribe to the idea of defining small DSL's for exchanging code between nodes. And this proposal is compatible with that idea. One thing that might not have been so clear in the original email is that we are proposing here to introduce just *one such DSL*. It's just that it's a trivial one whose grammar only contains linker symbol names. That triviality is a rather important point as well, because... As it happens, distributed-static today already supports two such DSL's: a DSL of labels, which are arbitrary string names for functions, and a small language
Re: Static values language extension proposal
On Sun, Jan 26, 2014 at 1:43 PM, Tim Watson watson.timo...@gmail.comwrote: In Erlang, I can rpc/send *any* term and evaluate it on another node. That includes functions of course. Whether or not we want to be quite that general is another matter, but that is the comparison I've been making. Note that Erlang gets away with this through being a virtual machine architecture; BEAM is about as write-once-run-anywhere as it gets, and the platform specifics are abstracted by the BEAM VM interpreter. You just aren't going to accomplish this with a native compiled language, without encoding as a virtual machine yourself (that is, the AST-based mechanisms). Perhaps you should consider fleshing out ghc's current bytecode support to be a full VM? Or perhaps an interesting alternative would be a BEAM backend for ghc. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
anyways 1) you should (once 7.8 is out) evaluate how far you can push your ideas wrt dynamic loading as a user land library. If you can't make it work as a library and can demonstrate why (or how even though it works its not quite satisfactory), thats signals something! But I really think insisting that the linker symbol names denote the datum agreement in a distributed system is punting on what should be handled at the application level. Simon Marlow put some improvements into GHC to help improve doing dynamic code (un)loading, stress test that! Theres quite a few industrial haskell shops that provide products / services where internally they do runtime dynamic loading of user provided object files, so i'm sure that the core GHC support is there if you actually dig into the apis! And they do this in a distributed systems context, sans CH. 2) I've a work in progress on specing out a proper (and sound :) ) static values type extension for ghc, that will be usable perhaps in your your case (though by dint of being sound, will preclude some of the things you think you want). BUT, any type system changes need to actually provide safety. My motivation for having a notion of static values comes from a desire to add compiler support for certain numerical computing operations that require compiler support to be usable in haskell. BUT, much of the same work @tim: what on earth does sending arbitrary code mean? I feel like the more precise thing everyone here wants is for a given application / infrastructure deployment, I would to be able to send my application specific computations over the network, using cloud haskell, and be sure that both sides think its the same code. As for *how* to send an AST fragment, edward kmett and other have some pretty nice typed AST models that are easy to adapt and extend for an application specific use case. Bound http://hackage.haskell.org/package/bound is one nice one. heres a really really good school of haskell exposition https://www.fpcomplete.com/user/edwardk/bound And theres a generalization that supports strong typing that i've copied from an hpaste https://gist.github.com/cartazio/5727196, where its notable that the AST data type is called Remote :), I think thats a hint its meant to be a haskell manipulable way of constructing a typed DSL you can serialize using a finally tagless style api approach (ie have a set of type class instances / operations that you use to run the computation and/or construct the AST you can send over the wire) On Fri, Jan 24, 2014 at 3:19 PM, Mathieu Boespflug 0xbadc...@gmail.comwrote: [Sorry for the multiple reposts - couldn't quite figure out which email address doesn't get refused by the list..] Hi Carter, thank you for the good points you raise. I'll try and address each of them as best I can below. 0) I think you could actually implement this proposal as a userland library, at least as you've described it. Have you tried doing so? Indeed, this could be done without touching the compiler at all. We thought long and hard about a path that would ultimately make an extension either unnecessary, or at any rate very small. At this point, the only thing that we are proposing to add to the compiler is the syntactic form static e. Contrary to the presentation in the paper, the 'unstatic' function can be implemented entirely as library code and does not need to be a primop. Moreover, we do not need to piece together any kind of global remote table at compile time or link time, because we're piggy backing on that already constructed by the system linker. The `static e` form could as well be a piece of Template Haskell, but making it a proper extension means that the compiler can enforce more invariants and be a bit more helpful to the user. In particular, detecting situations where symbolic references cannot be generated because e.g. the imported packages were not compiled as dynamic linked libraries. Or seamlessly supporting calling `static f` on an idenfier `f` that is not exported by the module. 1) what does this accomplish that can not be accomplished by having various nodes agree on a DSL, and sending ASTs to each other? 1a) in fact, I'd argue (and some others agree, and i'll admit my opinions have been shaped by those more expert than me) that the sending a wee AST you can interpret on the other side is much SAFER than sending a function symbol thats hard coded hopefully into both programs in a way that it means the same thing. I very much subscribe to the idea of defining small DSL's for exchanging code between nodes. And this proposal is compatible with that idea. One thing that might not have been so clear in the original email is that we are proposing here to introduce just *one such DSL*. It's just that it's a trivial one whose grammar only contains linker symbol names. As it happens, distributed-static today already supports two such DSL's: a DSL of labels
Static values language extension proposal
Hello, With the support of Tweag I/O, Mathieu and I have been assembling a design proposal for the language extension for Static values that will take Cloud Haskell a big step forward in usability. Please, find the proposal inlined below. We are looking forward to discuss its feasibility and features with the community. Best, Facundo -- In these notes we discuss a design of the language extension proposed in [1] for Cloud Haskell. That is, support from the compiler to produce labels that can be used to identify Haskell top-level bindings across processes in a network. Static values = Following [1], the extension consists of a new syntactic form `static e`, along with a type constructor `StaticRef` and a function unstatic :: StaticRef a - a The idea is that values of type `StaticRef a` uniquely identify a value that can be referred to by a global name rather than serialized over the network between processes that are instances of a single binary, because all such processes share the same top-level bindings. Generating static references We start by introducing global names. A `GlobalName` is a symbol bound in the top-level environment. It is much like global names in Template Haskell, but `GlobalNames` always refer to terms, and they include a package version. data GlobalName = GlobalName PkgName PkgVersion ModName OccName `GlobalNames` can be used as references to static values. newtype StaticRef a = StaticRef GlobalName `StaticRef a` is to `GlobalName` what `Ptr a` is to `Addr#`: a wrapper with a phantom type parameter that keeps track of the type of the value that is referenced. The special form static e is an expression of type `StaticRef a` where `e :: a` is a closed expression (meaning any free variables in `e` are bound in the top-level environment). If `e` is an identifier, `static e` just refers to it. Otherwise, the compiler needs to introduce a new top-level binding with a fresh name and the expression used as right-hand side, and the static reference would point to this top-level binding instead. Looking up static references `unstatic` is implemented as a function which finds a top-level value from the `GlobalName`, otherwise it raises an exception. It crucially relies on leveraging the system’s dynamic linker, so out-of-the-box only works with dynamically linked binaries (but see below). `unstatic` proceeds as follows: * Determines the name of the shared library from the package name and the package version. * Determines the symbol of the value by Z-Encoding the package name, the module name and the value name. * Uses the system’s dynamic linker interface to obtain the address of the symbol. * Converts the symbol to a haskell value with `GHC.Prim.addrToAny#` In principle, only symbols in shared libraries can be found. However, the dynamic linker is able to find symbols in modules that are linked statically if GHC is fed with the option -optl-Wl,--export-dynamic. A future enhancement could be to have GHC warn the user when modules using the extension are linked statically and this option is not used during linking. GHC only defines symbols for exported definitions in modules. So unstatic won’t be able to find the private bindings of a module. For this sake, the implementation of static should in addition ensure that the bindings it gets will appear in the symbol table when they are not exported by their defining modules. Template Haskell support == The static keyword needs to be made available in Template Haskell so the distributed-static package can benefit from this language extension. Rationale === We want the language extension to meet the following requirements: 1. It must be a practical alternative to the remoteTable functions in the distributed-static package. 2. It must not change the build scheme used for Haskell programs. A collection of .o files produced from Haskell source code should still be possible to link with the system linking tools. 3. It must not restrict all communicating processes using the extension to be launched from the same binary. 4. It must not significantly increase the binary size. (1) is addressed by replacing remote tables with the symbol tables produced by the compiler. Additionally, Template Haskell support is included so that the existing distributed-static package can be adapted and extended to include this extension. (2) is addressed by choosing a scheme which does not require the linker to perform any extension-specific procedure to collect the static values in various modules. There’s a trade off here though, since symbols in statically linked modules cannot be accessed unless -optl-Wl,--export-dynamic is supplied during linking. (3) is addressed by allowing programs to exchange static values for any bindings found in the modules they share. (4) is addressed by reusing the symbol tables produced by the compiler in object
Re: Static values language extension proposal
Hey Facundo, thanks for sharing this proposal. several questions: 0) I think you could actually implement this proposal as a userland library, at least as you've described it. Have you tried doing so? 1) what does this accomplish that can not be accomplished by having various nodes agree on a DSL, and sending ASTs to each other? 1a) in fact, I'd argue (and some others agree, and i'll admit my opinions have been shaped by those more expert than me) that the sending a wee AST you can interpret on the other side is much SAFER than sending a function symbol thats hard coded hopefully into both programs in a way that it means the same thing. I've had many educational conversations with 2) how does it provide more type safety than the current TH based approach? (I've seen Tim and others hit very very gnarly bugs in cloud haskell based upon the magic static values approach). 3) this proposal requires changes to linking etc that would really make it useful only on systems and deployments that only have Template Haskell AND Dynamic linking. (and also rules out any context where it'd be nice to deploy a static app or say, use CH in ios! ) to repeat: have you considered defining an AST type + interpreter for the computations you want to send around, and doing that? I think its a much simpler, safer, easier, flexible and PORTABLE approach, though one current CH doesn't do (though the folks working on CH seem to be receptive to switching to such a strategy if someone validates it) cheers -Carter On Fri, Jan 24, 2014 at 12:19 PM, Facundo Domínguez facundo.doming...@tweag.io wrote: Hello, With the support of Tweag I/O, Mathieu and I have been assembling a design proposal for the language extension for Static values that will take Cloud Haskell a big step forward in usability. Please, find the proposal inlined below. We are looking forward to discuss its feasibility and features with the community. Best, Facundo -- In these notes we discuss a design of the language extension proposed in [1] for Cloud Haskell. That is, support from the compiler to produce labels that can be used to identify Haskell top-level bindings across processes in a network. Static values = Following [1], the extension consists of a new syntactic form `static e`, along with a type constructor `StaticRef` and a function unstatic :: StaticRef a - a The idea is that values of type `StaticRef a` uniquely identify a value that can be referred to by a global name rather than serialized over the network between processes that are instances of a single binary, because all such processes share the same top-level bindings. Generating static references We start by introducing global names. A `GlobalName` is a symbol bound in the top-level environment. It is much like global names in Template Haskell, but `GlobalNames` always refer to terms, and they include a package version. data GlobalName = GlobalName PkgName PkgVersion ModName OccName `GlobalNames` can be used as references to static values. newtype StaticRef a = StaticRef GlobalName `StaticRef a` is to `GlobalName` what `Ptr a` is to `Addr#`: a wrapper with a phantom type parameter that keeps track of the type of the value that is referenced. The special form static e is an expression of type `StaticRef a` where `e :: a` is a closed expression (meaning any free variables in `e` are bound in the top-level environment). If `e` is an identifier, `static e` just refers to it. Otherwise, the compiler needs to introduce a new top-level binding with a fresh name and the expression used as right-hand side, and the static reference would point to this top-level binding instead. Looking up static references `unstatic` is implemented as a function which finds a top-level value from the `GlobalName`, otherwise it raises an exception. It crucially relies on leveraging the system’s dynamic linker, so out-of-the-box only works with dynamically linked binaries (but see below). `unstatic` proceeds as follows: * Determines the name of the shared library from the package name and the package version. * Determines the symbol of the value by Z-Encoding the package name, the module name and the value name. * Uses the system’s dynamic linker interface to obtain the address of the symbol. * Converts the symbol to a haskell value with `GHC.Prim.addrToAny#` In principle, only symbols in shared libraries can be found. However, the dynamic linker is able to find symbols in modules that are linked statically if GHC is fed with the option -optl-Wl,--export-dynamic. A future enhancement could be to have GHC warn the user when modules using the extension are linked statically and this option is not used during linking. GHC only defines symbols for exported definitions in modules. So unstatic won’t be able to find the private bindings of a module. For this sake
Re: Static values language extension proposal
I don't have time to weigh in on this proposal right now, but I have several comments... On 24 Jan 2014, at 17:19, Facundo Domínguez wrote: Rationale === We want the language extension to meet the following requirements: 1. It must be a practical alternative to the remoteTable functions in the distributed-static package. Agreed - this is vital! 2. It must not change the build scheme used for Haskell programs. A collection of .o files produced from Haskell source code should still be possible to link with the system linking tools. Also vital. 3. It must not restrict all communicating processes using the extension to be launched from the same binary. I personally think this is very valuable. About the need for using different binaries == While using distributed-process we found some use cases for supporting communicating closures between multiple binaries. One of these use cases involved a distributed application and a monitoring tool. The monitoring tool would need to link in some graphics libraries to display information on the screen, none of which were required by the monitored application. Conversely, the monitored application would link in some modules that the monitoring application didn’t need. Crucially, both applications are fairly loosely coupled, even if they both need to exchange static values about bindings in some modules they shared. Indeed - this is an almost canonical use-case, as are administrative (e.g., remote management) tools. As the application depends on shared libraries, now a tool to collect these libraries would be required so they can be distributed together with the executable binary when deploying a Cloud Haskell application in a cluster. We won’t delve further into this problem. Great idea. Another possible line of work is extending this approach so a process can pull shared objects from a remote peer, when this remote peer sends a static value that is defined in a shared object not available to the process. This would go a long way towards answering our questions about 'hot code upgrade' and be useful in many other areas too. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
On 24 Jan 2014, at 17:59, Carter Schonwald wrote: 0) I think you could actually implement this proposal as a userland library, at least as you've described it. Have you tried doing so? I didn't pick up on that at all - how would we be able to do that? 1) what does this accomplish that can not be accomplished by having various nodes agree on a DSL, and sending ASTs to each other? 1a) in fact, I'd argue (and some others agree, and i'll admit my opinions have been shaped by those more expert than me) that the sending a wee AST you can interpret on the other side is much SAFER than sending a function symbol thats hard coded hopefully into both programs in a way that it means the same thing. I've had many educational conversations with I've still not seen a convincing example of how to do this though. It would help if someone explained what this would look like, running over two (or more) separate binaries and still shipping code. It's just that, afaict, that AST wouldn't be so wee once it had to represent any arbitrary expression. One could, of course, just ship source (or some intermediate representation), but that would also require compiler infrastructure to be installed on the target. 2) how does it provide more type safety than the current TH based approach? (I've seen Tim and others hit very very gnarly bugs in cloud haskell based upon the magic static values approach). This is definitely true, but I see it as a problem related to our use of TH rather than our current use of closures and 'Static' per se. Having said that, it can be toe-curlingly difficult to work with closure/static sometimes, so *anything* that makes this easier sounds good to me. to repeat: have you considered defining an AST type + interpreter for the computations you want to send around, and doing that? I think its a much simpler, safer, easier, flexible and PORTABLE approach, though one current CH doesn't do (though the folks working on CH seem to be receptive to switching to such a strategy if someone validates it) I/we are, I think, amenable to doing whatever makes the most sense. This could include doing more than one thing, when it comes to dealing with 'statics'. Personally I think the proposal sounds interesting, though as I mentioned in my previously mail, I haven't had time to sit down and look at it in detail yet. Cheers, Tim ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
On Fri, Jan 24, 2014 at 12:19 PM, Facundo Domínguez facundo.doming...@tweag.io wrote: In principle, only symbols in shared libraries can be found. However, the dynamic linker is able to find symbols in modules that are linked statically if GHC is fed with the option -optl-Wl,--export-dynamic. A This strikes me as highly platform specific to the Linux and possibly FreeBSD implementations of ELF; it likely will not work with Solaris ELF, which handles dynamic symbols differently (or at least used to), and will not work with non-ELF platforms (OS X, Windows) and probably won't work with a non-GNU ld such as is used on Solaris and OS X. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static values language extension proposal
[Sorry for the multiple reposts - couldn't quite figure out which email address doesn't get refused by the list..] Hi Carter, thank you for the good points you raise. I'll try and address each of them as best I can below. 0) I think you could actually implement this proposal as a userland library, at least as you've described it. Have you tried doing so? Indeed, this could be done without touching the compiler at all. We thought long and hard about a path that would ultimately make an extension either unnecessary, or at any rate very small. At this point, the only thing that we are proposing to add to the compiler is the syntactic form static e. Contrary to the presentation in the paper, the 'unstatic' function can be implemented entirely as library code and does not need to be a primop. Moreover, we do not need to piece together any kind of global remote table at compile time or link time, because we're piggy backing on that already constructed by the system linker. The `static e` form could as well be a piece of Template Haskell, but making it a proper extension means that the compiler can enforce more invariants and be a bit more helpful to the user. In particular, detecting situations where symbolic references cannot be generated because e.g. the imported packages were not compiled as dynamic linked libraries. Or seamlessly supporting calling `static f` on an idenfier `f` that is not exported by the module. 1) what does this accomplish that can not be accomplished by having various nodes agree on a DSL, and sending ASTs to each other? 1a) in fact, I'd argue (and some others agree, and i'll admit my opinions have been shaped by those more expert than me) that the sending a wee AST you can interpret on the other side is much SAFER than sending a function symbol thats hard coded hopefully into both programs in a way that it means the same thing. I very much subscribe to the idea of defining small DSL's for exchanging code between nodes. And this proposal is compatible with that idea. One thing that might not have been so clear in the original email is that we are proposing here to introduce just *one such DSL*. It's just that it's a trivial one whose grammar only contains linker symbol names. As it happens, distributed-static today already supports two such DSL's: a DSL of labels, which are arbitrary string names for functions, and a small language for composing Static values together. There is a patch lying around by Edsko proposing to add a third DSL: one that allows nodes to trade arbitrary Haskell strings that are then eval'ed on the other end by the 'plugins' package. As Facundo explains at the end of his email, the notion of a static value ought to be a more general one than was first envisioned in the paper: a static value is any closed denotation, denoted in any of a choice of multiple small languages, some of which ship standard with distributed-static. The user can define his own DSL for shipping code around. This is why we propose to make Static into a class. Each DSL is generated by one datatype. Each such datatype has a Static instance. If you would like to ship an AST around the cluster, you can make the datatype for that AST an instance of Static, with 'unstatic' being defined as an interpreter for your AST. Concretely: data HsExpr = ... instance Static HsExpr where unstatic e = Hs.interpret e I've had many educational conversations with ... ? 2) how does it provide more type safety than the current TH based approach? (I've seen Tim and others hit very very gnarly bugs in cloud haskell based upon the magic static values approach). The type safety of the current TH approach is reasonable I think. One potential problem comes from managing dynamically typed values in the remote table, which must be coerced to the right type and use the right decoders if you don't use TH. With the approach we propose, there is no remote table, so I guess this should help eliminate a source of bugs. 3) this proposal requires changes to linking etc that would really make it useful only on systems and deployments that only have Template Haskell AND Dynamic linking. (and also rules out any context where it'd be nice to deploy a static app or say, use CH in ios! ) I don't know about iOS. And it's very likely that there are contexts in which this extension doesn't work. But as I said above, you are always free to define your own DSL's that cover the particular use case that you have in mind. The nice thing with this particular DSL is that it requires little to no TH to generate label names, which can always be a source of bugs, especially when you forget to include them in the global remote table (which is something that TH doesn't and can't help you with). Furthermore, it was my understanding that GHC is heading towards a world of dynamic linkable by default, and it is by now something that is supported on most platforms by GHC. See e.g. https://ghc.haskell.org/trac
Re: GHC static binaries with glibc-2.12?
On Wed, Oct 20, 2010 at 10:23:59PM -0700, Alexander Dunlap wrote: On Mon, Oct 11, 2010 at 2:11 AM, Simon Marlow marlo...@gmail.com wrote: On 10/10/2010 05:22, Alexander Dunlap wrote: On Fri, Oct 8, 2010 at 12:46 AM, Simon Marlowmarlo...@gmail.com wrote: On 08/10/2010 03:23, Alexander Dunlap wrote: I recently upgraded my Arch Linux system to glibc 2.12 and static binaries compiled with GHC 6.12.3 all fail with the message mkTextEncoding: invalid argument (Invalid argument). This did not happen with glibc 2.11. Has anyone else had this problem? Does anyone have any advice for debugging it? Yes, it does, but strace seems to show that the program is looking in the right place for the iconv libraries. Is there some way to step through the code of a statically-linked program? I'm not sure how to proceed debugging a Haskell-originated error that only occurs with static linking (so I can't use the GHCi debugger). The error is almost certainly being returned by iconv(), which is called via this wrapper in base/cbits/iconv.c: size_t hs_iconv(iconv_t cd, return iconv(cd, (void*)inbuf, inbytesleft, outbuf, outbytesleft); Does this indicate that the error is occurring before iconv is even called? I suspect it's actually hs_iconv_open (which calls iconv_open) which gives the error. Thanks Ian ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC static binaries with glibc-2.12?
On Mon, Oct 11, 2010 at 2:11 AM, Simon Marlow marlo...@gmail.com wrote:
On 10/10/2010 05:22, Alexander Dunlap wrote:
On Fri, Oct 8, 2010 at 12:46 AM, Simon Marlowmarlo...@gmail.com wrote:
On 08/10/2010 03:23, Alexander Dunlap wrote:
I recently upgraded my Arch Linux system to glibc 2.12 and static
binaries compiled with GHC 6.12.3 all fail with the message
mkTextEncoding: invalid argument (Invalid argument). This did not
happen with glibc 2.11. Has anyone else had this problem? Does anyone
have any advice for debugging it?
Probably something to do with iconv. Doesn't iconv need to load its
codec
modules dynamically at runtime?
Cheers,
Simon
Yes, it does, but strace seems to show that the program is looking in
the right place for the iconv libraries. Is there some way to step
through the code of a statically-linked program? I'm not sure how to
proceed debugging a Haskell-originated error that only occurs with
static linking (so I can't use the GHCi debugger).
The error is almost certainly being returned by iconv(), which is called via
this wrapper in base/cbits/iconv.c:
size_t hs_iconv(iconv_t cd,
const char* * inbuf, size_t * inbytesleft,
char* * outbuf, size_t * outbytesleft)
{
// (void*) cast avoids a warning. Some iconvs use (const
// char**inbuf), other use (char **inbuf).
return iconv(cd, (void*)inbuf, inbytesleft, outbuf, outbytesleft);
}
you could run the program in gdb and set a breakpoint on hs_iconv, or iconv
itself. Since it will be compiled without debugging information you'll have
to poke around on the C stack yourself to find the arguments.
Alternatively get a GHC build and instrument the code in
libraries/base/GHC/IO/Encoding/IConv.hs to see what's going on.
Cheers,
Simon
$ gdb ./main-static
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i686-pc-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/alex/tmp/main-static...(no debugging
symbols found)...done.
(gdb) break iconv
Breakpoint 1 at 0x80bbd66
(gdb) break hs_iconv
Breakpoint 2 at 0x8065de6
(gdb) run
Starting program: /home/alex/tmp/main-static
[Thread debugging using libthread_db enabled]
main-static: mkTextEncoding: invalid argument (Invalid argument)
Program exited with code 01.
(gdb)
Does this indicate that the error is occurring before iconv is even
called? Or do I have to do something else to make the breakpoint work.
(Sorry, I'm not an expert with GDB.)
Alex
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC static binaries with glibc-2.12?
On 10/10/2010 05:22, Alexander Dunlap wrote:
On Fri, Oct 8, 2010 at 12:46 AM, Simon Marlowmarlo...@gmail.com wrote:
On 08/10/2010 03:23, Alexander Dunlap wrote:
I recently upgraded my Arch Linux system to glibc 2.12 and static
binaries compiled with GHC 6.12.3 all fail with the message
mkTextEncoding: invalid argument (Invalid argument). This did not
happen with glibc 2.11. Has anyone else had this problem? Does anyone
have any advice for debugging it?
Probably something to do with iconv. Doesn't iconv need to load its codec
modules dynamically at runtime?
Cheers,
Simon
Yes, it does, but strace seems to show that the program is looking in
the right place for the iconv libraries. Is there some way to step
through the code of a statically-linked program? I'm not sure how to
proceed debugging a Haskell-originated error that only occurs with
static linking (so I can't use the GHCi debugger).
The error is almost certainly being returned by iconv(), which is called
via this wrapper in base/cbits/iconv.c:
size_t hs_iconv(iconv_t cd,
const char* * inbuf, size_t * inbytesleft,
char* * outbuf, size_t * outbytesleft)
{
// (void*) cast avoids a warning. Some iconvs use (const
// char**inbuf), other use (char **inbuf).
return iconv(cd, (void*)inbuf, inbytesleft, outbuf, outbytesleft);
}
you could run the program in gdb and set a breakpoint on hs_iconv, or
iconv itself. Since it will be compiled without debugging information
you'll have to poke around on the C stack yourself to find the arguments.
Alternatively get a GHC build and instrument the code in
libraries/base/GHC/IO/Encoding/IConv.hs to see what's going on.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC static binaries with glibc-2.12?
On Fri, Oct 8, 2010 at 12:46 AM, Simon Marlow marlo...@gmail.com wrote: On 08/10/2010 03:23, Alexander Dunlap wrote: I recently upgraded my Arch Linux system to glibc 2.12 and static binaries compiled with GHC 6.12.3 all fail with the message mkTextEncoding: invalid argument (Invalid argument). This did not happen with glibc 2.11. Has anyone else had this problem? Does anyone have any advice for debugging it? Probably something to do with iconv. Doesn't iconv need to load its codec modules dynamically at runtime? Cheers, Simon Yes, it does, but strace seems to show that the program is looking in the right place for the iconv libraries. Is there some way to step through the code of a statically-linked program? I'm not sure how to proceed debugging a Haskell-originated error that only occurs with static linking (so I can't use the GHCi debugger). Alex ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC static binaries with glibc-2.12?
On 08/10/2010 03:23, Alexander Dunlap wrote: I recently upgraded my Arch Linux system to glibc 2.12 and static binaries compiled with GHC 6.12.3 all fail with the message mkTextEncoding: invalid argument (Invalid argument). This did not happen with glibc 2.11. Has anyone else had this problem? Does anyone have any advice for debugging it? Probably something to do with iconv. Doesn't iconv need to load its codec modules dynamically at runtime? Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
GHC static binaries with glibc-2.12?
Hi all, I recently upgraded my Arch Linux system to glibc 2.12 and static binaries compiled with GHC 6.12.3 all fail with the message mkTextEncoding: invalid argument (Invalid argument). This did not happen with glibc 2.11. Has anyone else had this problem? Does anyone have any advice for debugging it? Thanks, Alex ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Static linking and linker search paths
All,
Conor's problems on OSX with libiconv reminds me of something I've been
thinking about for a little while.
So the problem is that the semantics of static linking does not at all
match what we really want. We can easily accidentally interpose a
wrong library in place of the one we wanted.
In the iconv case people have hit recently we've got this situation:
libHSbase-4.2.0.0.a
contains references to _iconv_open, _iconv, _iconv_close
${system}/libiconv.a
${macports}/libiconv.a
When the code for libHSbase was built, it was against the header files
for the standard system version of iconv on OSX. Thus it is intended
that we link against the system version of iconv.
No suppose by default that the system is set up such that only the
system iconv is found by default. So I am assuming there is no
LD_LIBRARY_PATH or similar set. Then when we link something then we
correctly resolve the references in base to the system iconv lib.
When we call gcc to link we're doing something like:
-L${ghclibdir} -lHSbase-4.2.0.0.a -liconv
Now suppose we build some FFI package (libHSfoo-1.0.a) that provides a
binding to a C lib installed via macports (libfoo.a). When we link a
program that depends indirectly on this FFI package then the gcc linker
line is like:
-L${ghclibdir} -L/opt/local/lib
-lHSfoo-1.0.a -lfoo -lHSbase-4.2.0.0.a -liconv
and now it all breaks.
We're asking the linker to look in /opt/local/lib first for *all the
remaining libraries* and that includes iconv, so we pick up the wrong
iconv. Our intention was just to look for -lfoo using /opt/local/lib,
but we cannot express that to the linker.
The problem is that our notion of library dependencies is hierarchical
but for the system linker it is linear. We know that package foo-1.0
needs the C library libfoo.a and that it should be found by looking
in /opt/local/lib. But we end up asking the linker to look there first
for all other libs too, including for the -liconv needed by the base
package. The registration for the base package never
mentioned /opt/local/lib of course.
What we'd really like to say is something like:
link HSfoo-1.0.a
push search path /opt/local/lib
link foo
pop search path
If we think we know enough about the behaviour of the system linker and
its search path then we could do just:
-L${ghclibdir}
-lHSfoo-1.0.a /opt/local/lib/libfoo.a -lHSbase-4.2.0.0.a -liconv
that is, specify the .a file exactly by fully resolved path and not add
anything to the linker search path. (Actually we'd do it for the
libHS*.a ones too since we know precisely where they live)
The possible danger is that how we search for the library and how the
system linker searches for it might not match exactly and we could end
up sowing confusion.
Worth thinking about anyway.
Note that some of this is different for shared libs.
Duncan
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static library to redefine entrypoint
On Fri, 2009-04-24 at 12:56 +0200, Philip K.F. Hölzenspies wrote: Dear GHCers, I am trying to write a wrapper library for lab work to give to students. My problem is, that the libraries I use require initialization that I really want to hide from our students. The wrapper I'm writing is compiled to a static library and installed with cabal, so students can just ghc --make or ghci their sources. Here comes the problem: I want to define main and let students just define labMain as an entry point to their program. How can I have my library use labMain without a definition? Keep in mind that I want to give them a cabalized library that they can just link to, so I can't give them a template file that they fill and compile together with my code. Is it at all possible to have external functions and letting the linker sort stuff out? When I've set practicals like this I've just provided them with a 3 line Main module that imports functions exported by the module(s) that the students write. Eg I have them fill in Draw.lhs but tell them to compile the thing using ghc --make Main.hs. I never found that this confused any of them (indeed some were interested in looking at the code). Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static library to redefine entrypoint
Why not just tell them to import your library and do something like main = withSomeInit labMain where withSomeInit is the function you provide? This approach is present in some other libs that require initialization. Best regards Christopher Skrzętnicki On Fri, Apr 24, 2009 at 12:56, Philip K.F. p.k.f.holzensp...@utwente.nlwrote: Dear GHCers, I am trying to write a wrapper library for lab work to give to students. My problem is, that the libraries I use require initialization that I really want to hide from our students. The wrapper I'm writing is compiled to a static library and installed with cabal, so students can just ghc --make or ghci their sources. Here comes the problem: I want to define main and let students just define labMain as an entry point to their program. How can I have my library use labMain without a definition? Keep in mind that I want to give them a cabalized library that they can just link to, so I can't give them a template file that they fill and compile together with my code. Is it at all possible to have external functions and letting the linker sort stuff out? Regards, Philip ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Static library to redefine entrypoint
Dear GHCers, I am trying to write a wrapper library for lab work to give to students. My problem is, that the libraries I use require initialization that I really want to hide from our students. The wrapper I'm writing is compiled to a static library and installed with cabal, so students can just ghc --make or ghci their sources. Here comes the problem: I want to define main and let students just define labMain as an entry point to their program. How can I have my library use labMain without a definition? Keep in mind that I want to give them a cabalized library that they can just link to, so I can't give them a template file that they fill and compile together with my code. Is it at all possible to have external functions and letting the linker sort stuff out? Regards, Philip ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Static library to redefine entrypoint
On Fri, 2009-04-24 at 13:06 +0200, Krzysztof Skrzętnicki wrote: Why not just tell them to import your library and do something like main = withSomeInit labMain where withSomeInit is the function you provide? This approach is present in some other libs that require initialization. Dear Christopher, I know there are alternatives and I know some people use them. A particular problem I have now, though, is SDL. On OS X, the SDL library defines an alternative entry-point to the application, called SDL_main, where the libSDL.a provides a main (insert long story about Cocoa frameworks and Objective-C linking here). I don't particularly like this method, but it's the world I have to work with. Also, many alternatives to SDL don't play nice with GHCi, which is particularly useful for lab teaching. If I can somehow introduce my own new entry point, I could also wrap GHCi in something else quite easily (I know I could wrap GHCi as it is, but it would be even nicer if I could just link to the binary). I figured this level of detail would distract form the question, though and I would run the risk that people would try to solve my SDL linking woes, which is not the point of the question. Regards, Philip ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: the impossible happened, large static list.
Philip Weaver wrote: Hello. I think I've seen other people encounter this problem before, but I wasn't able to find the solution, if there is one. I have a very large static list of type [[Int]]. It is 128 lists of 128 integers each. When I try to load the module that defines this list, I get an error: ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): linkBCO: = 64k insns in BCO Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This happens on both linux and mac os, both ghc-6.8.3 and ghc-6.10.1, and both GHC and GHCi. Is there anything I can do to avoid this? Thanks! Sorry for the inconvenience. Splitting the list into two modules should avoid it. Here's the relevant ticket: http://hackage.haskell.org/trac/ghc/ticket/789 Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: the impossible happened, large static list.
On Fri, Jan 30, 2009 at 3:28 AM, Simon Marlow marlo...@gmail.com wrote: Philip Weaver wrote: Hello. I think I've seen other people encounter this problem before, but I wasn't able to find the solution, if there is one. I have a very large static list of type [[Int]]. It is 128 lists of 128 integers each. When I try to load the module that defines this list, I get an error: ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): linkBCO: = 64k insns in BCO Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This happens on both linux and mac os, both ghc-6.8.3 and ghc-6.10.1, and both GHC and GHCi. Is there anything I can do to avoid this? Thanks! Sorry for the inconvenience. Splitting the list into two modules should avoid it. Here's the relevant ticket: http://hackage.haskell.org/trac/ghc/ticket/789 Cheers, Simon Ah, thanks. In this particular case, I was also able to get it to work by binding each list inside the top-level list like this: top_level_list = [ list0, list1, list2, list3, list4, list5 ... list127] list0 = ... list1 = ... list2 = ... ... list127 = ... - Philip ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
the impossible happened, large static list.
Hello. I think I've seen other people encounter this problem before, but I wasn't able to find the solution, if there is one. I have a very large static list of type [[Int]]. It is 128 lists of 128 integers each. When I try to load the module that defines this list, I get an error: ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for i386-apple-darwin): linkBCO: = 64k insns in BCO Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This happens on both linux and mac os, both ghc-6.8.3 and ghc-6.10.1, and both GHC and GHCi. Is there anything I can do to avoid this? Thanks! - Philip ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static linking
Hello, Further on my static linking woes: debian ~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 -debian ~$ cat T.hs main :: IO () main = putStrLn Hello world -debian ~$ ghc -optl-static -static --make T.hs Linking T ... /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/ librt.a(timer_create.o): In function `timer_create': (.text+0x107): undefined reference to `pthread_once' ... references to missing pthread symbols Does anyone have static linking working for GHC 6.8.2 and can inform me of the magic incantation? Get the latest development version from darcs, perhaps? BTW when I said move to the end, I meant move to the end of -l flags. cheers peter On 27/05/2008, at 10:37 AM, Peter Gammie wrote: Hello, I am having a bit of trouble static linking my program using GHC 6.8.2. In brief: rt uses pthread, but -lrt is the final thing on the command line passed to the linker, and so the pthread symbols are not resolved. Manually moving -lpthread to the end of the collect2 command line does the trick. The question is how to do this using ghc. This is on Debian, using the 6.8.2-5 from unstable. I can provide the command lines if that is helpful. Note the same setup worked fine under GHC 6.6.1. cheers peter ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static linking
Peter Gammie wrote: Hello, Further on my static linking woes: debian ~$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.2 -debian ~$ cat T.hs main :: IO () main = putStrLn Hello world -debian ~$ ghc -optl-static -static --make T.hs Linking T ... /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/librt.a(timer_create.o): In function `timer_create': (.text+0x107): undefined reference to `pthread_once' ... references to missing pthread symbols Does anyone have static linking working for GHC 6.8.2 and can inform me of the magic incantation? Get the latest development version from darcs, perhaps? BTW when I said move to the end, I meant move to the end of -l flags. We may need to tweak the order of the libraries in rts/package.conf.in (this is where -lrt comes from). The question is, do we need a configure test? Cheers, Simon cheers peter On 27/05/2008, at 10:37 AM, Peter Gammie wrote: Hello, I am having a bit of trouble static linking my program using GHC 6.8.2. In brief: rt uses pthread, but -lrt is the final thing on the command line passed to the linker, and so the pthread symbols are not resolved. Manually moving -lpthread to the end of the collect2 command line does the trick. The question is how to do this using ghc. This is on Debian, using the 6.8.2-5 from unstable. I can provide the command lines if that is helpful. Note the same setup worked fine under GHC 6.6.1. cheers peter ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
jason.dusek:
I have an awkward programming problem -- I need to take a
dictionary, parse it, build a bunch of intermediate lists and
then make maps and tries out of the list. A programming
problem because it's taken me a fair amount of effort to pull
together the parser and list generator -- and awkward
because a 69000 item list, [(String, [(String, String)])],
does not compile under GHC (stack overflow). (It's not likely
to compile under anything else, either!)
Here's an example of the approach Bryan outlined, which does seem to
work for files as large as gcc can handle:
* generate your big Haskell Map
* serialise it with Data.Binary, and Codec.Compression.GZip to a file
* compile the data into a C const array, and link that into Haskell
* decode it on startup, ressurecting the Haskell data.
The C source looks like:
const uint8_t beowulf[] = {
31, 139, 8, 0, 0, 0, 0, 0, 0, 3, 124, 189, 75,
150, 46, 54, 93, 193, 96, 144, 241, 168, 172, 238, 214, 0,
...
http://code.haskell.org/~dons/code/compiled-constants/cbits/constants.c
which is the gzip, Data.Binary encoded version of a Map ByteString Int.
Then the Haskell code need only access this array as a Ptr Word8, wrap
that as a Bytestring, then run Data.Binary over the result to rebuild
the Map. As you can see here:
http://code.haskell.org/~dons/code/compiled-constants/Constants.hs
I've put a couple of examples of how to access C-side serialised Haskell
values in a package here:
http://code.haskell.org/~dons/code/compiled-constants/
Cheers,
Don
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
Jason Dusek [EMAIL PROTECTED]: Bryan O'Sullivan [EMAIL PROTECTED] wrote: The trick I usually use in cases like this is to compile the data as C code and link against it, then access it from Haskell via a Ptr. For my particular application, I really need to ship a single static binary that has it all -- data as well as algorithms -- so I'm going with the FFI. It's too bad that I end up working in the IO monad much of the time. I hope we'll have massive static constants someday soon! unsafePerformIO should be safe on constants, right? It has worked for me, at least. Jay ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
On Sat, Mar 1, 2008 at 12:24 PM, Jay Scott [EMAIL PROTECTED] wrote: Jason Dusek [EMAIL PROTECTED]: unsafePerformIO should be safe on constants, right? It has worked for me, at least. Unfortunately, reading in the list does not allow me to ship a single binary. It's not file reading, though, that forces me in to the IO Monad -- it's pointer dereferencing. -- _jsn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
Simon Peyton-Jones [EMAIL PROTECTED] wrote: It's not quite as stupid as it sounds...have another go when you see that #2002 is fixed. Thanks for pointing me to that -- in the meantime, I'd still rather write C and Haskell than plain C++! -- _jsn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
jay:
Don Stewart [EMAIL PROTECTED]:
jay:
Don Stewart [EMAIL PROTECTED]:
jay:
I also have constants that are too large to compile. I am resigned to
loading them from data files--other solutions seem even worse.
...
Data.Binary eases the irritation somewhat.
Did you try bytestring literals (and maybe parsing them in-memory with
Data.Binary)?
I finally squeezed enough time to try it, and it didn't work for me.
--
ghc Overflow.hs
[1 of 1] Compiling Overflow ( Overflow.hs, Overflow.o )
Enable optimisations! Compile with ghc -O2. You need this to avoid
having a very slow pack call at runtime.
Overflow.hs:8:10:stack overflow: use +RTS -Ksize to increase it
--
where Overflow.hs is in the vicinity of 40M and looks like
--
{-# LANGUAGE OverloadedStrings #-}
module Overflow where
import qualified Data.ByteString.Lazy as S
bigData :: S.ByteString
bigData = \0\0\0\0\0\5\67\195\0\0\0\0...
--
I didn't compress it, because Codec.Compression.GZip didn't compile for
me. It looked like a library change since 6.6 broke it.
Probably you don't have the zlib.h header?
Or make sure you have the latest version of zlib from hackage -- it does
work.
Is there a handy string escaping function in the libraries somewhere? It
only took a minute to write one, and I spent longer than that looking,
so maybe it's the wrong question Surely it's in there somewhere, and
I'm just 2 dum 2 c.
The show function?
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
Don Stewart [EMAIL PROTECTED]:
jay:
Don Stewart [EMAIL PROTECTED]:
jay:
I also have constants that are too large to compile. I am resigned to
loading them from data files--other solutions seem even worse.
...
Data.Binary eases the irritation somewhat.
Did you try bytestring literals (and maybe parsing them in-memory with
Data.Binary)?
I finally squeezed enough time to try it, and it didn't work for me.
--
ghc Overflow.hs
[1 of 1] Compiling Overflow ( Overflow.hs, Overflow.o )
Overflow.hs:8:10:stack overflow: use +RTS -Ksize to increase it
--
where Overflow.hs is in the vicinity of 40M and looks like
--
{-# LANGUAGE OverloadedStrings #-}
module Overflow where
import qualified Data.ByteString.Lazy as S
bigData :: S.ByteString
bigData = \0\0\0\0\0\5\67\195\0\0\0\0...
--
I didn't compress it, because Codec.Compression.GZip didn't compile for
me. It looked like a library change since 6.6 broke it.
Is there a handy string escaping function in the libraries somewhere? It
only took a minute to write one, and I spent longer than that looking,
so maybe it's the wrong question Surely it's in there somewhere, and
I'm just 2 dum 2 c.
Jay
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
Don Stewart [EMAIL PROTECTED]:
jay:
Don Stewart [EMAIL PROTECTED]:
jay:
I also have constants that are too large to compile. I am resigned to
loading them from data files--other solutions seem even worse.
...
Data.Binary eases the irritation somewhat.
Did you try bytestring literals (and maybe parsing them in-memory with
Data.Binary)?
That didn't occur to me, since neither of my large constants includes
strings I think you're suggesting that each constant could appear in
the source as a long bytestring and be deserialized into the data
structure. If that works, it should improve the startup time, but it's
still not as nice as simply compiling it straight up.
I'll try it.
Here's an example, which stores a Data.Map in a gzip-compressed
bytestring literal (a C
string literal in the compiled code). The Map is reconstructed on
startup.
{-# LANGUAGE OverloadedStrings #-}
import Data.Binary
import qualified Data.Map as M
import qualified Data.ByteString.Char8 as S
import Data.ByteString.Lazy
import Codec.Compression.GZip
--
-- this is a gzip compressed literal bytestring, storing a binary-
encoded Data.Map
--
mytable =
\US\139\b\NUL\NUL\NUL\NUL\NUL\NUL\ETXEN\219\SO\194 \f\197\224
\188\196\CAN\227\US\224\171~\NAKc\GS4ce\161`\178\191\215(\176\190\180\167
\231\210\n\241\171\203\191\ti\157\217\149\249 \ENQ\214\9\202\162\179a
\132X\233\ESC=\231\215\164\SYN\157\DC2D\226*\146\174o\t\167\DLE\209\i_
\240\193\129\199W\250nC\CAN\212\CAN\162J\160\141C\178\133\216;[EMAIL
PROTECTED]
\203\209x\205\140\166\RS\163\237]9f\170\143\ACK\163g\223\STX\184\7\rH
\222\FSW\130\7D\197\NUL\164\0U\193\186\t\186o\228\180~\NUL\a6\249\137#
\SOH\NUL\NUL
main = print = M.lookup ghc m
where
-- build the table from the bytestring:
m :: M.Map String (Maybe String)
m = decode . decompress . fromChunks . return $ mytable
Running it:
$ ./A
Just dinosaur!
:)
Important to use a bytestring, since that gets compiled to a C string
literal (and not messed
with by the simplifier).
-- Don
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
Don Stewart [EMAIL PROTECTED]: jay: Don Stewart [EMAIL PROTECTED]: jay: Don Stewart [EMAIL PROTECTED]: jay: I also have constants that are too large to compile. I am resigned to loading them from data files--other solutions seem even worse. ... Data.Binary eases the irritation somewhat. Did you try bytestring literals (and maybe parsing them in-memory with Data.Binary)? I finally squeezed enough time to try it, and it didn't work for me. -- ghc Overflow.hs [1 of 1] Compiling Overflow ( Overflow.hs, Overflow.o ) Enable optimisations! Compile with ghc -O2. You need this to avoid having a very slow pack call at runtime. Yes, I tried basic variations like that. The result is the same with -O1 or with -O2, and with Data.ByteString or Data.ByteString.Lazy . I'm just 2 dum 2 c. The show function? Ha ha! Jay ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
jay: Don Stewart [EMAIL PROTECTED]: jay: Don Stewart [EMAIL PROTECTED]: jay: Don Stewart [EMAIL PROTECTED]: jay: I also have constants that are too large to compile. I am resigned to loading them from data files--other solutions seem even worse. ... Data.Binary eases the irritation somewhat. Did you try bytestring literals (and maybe parsing them in-memory with Data.Binary)? I finally squeezed enough time to try it, and it didn't work for me. -- ghc Overflow.hs [1 of 1] Compiling Overflow ( Overflow.hs, Overflow.o ) Enable optimisations! Compile with ghc -O2. You need this to avoid having a very slow pack call at runtime. Yes, I tried basic variations like that. The result is the same with -O1 or with -O2, and with Data.ByteString or Data.ByteString.Lazy . Ok, hmm, that really shouldn't be the case. Do you have the example available somewhere? It's just a 40M inline bytestring? -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
Bryan O'Sullivan [EMAIL PROTECTED] wrote: The trick I usually use in cases like this is to compile the data as C code and link against it, then access it from Haskell via a Ptr. For my particular application, I really need to ship a single static binary that has it all -- data as well as algorithms -- so I'm going with the FFI. It's too bad that I end up working in the IO monad much of the time. I hope we'll have massive static constants someday soon! -- _jsn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
Is it _possible_ to use Template Haskell to take the name of the external binary file and produce such a bytestring literal? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: static constants -- ideas?
| On another note, I am extremely curious about the difference | between statically compiling a list and building it at | runtime. I find it hard to wrap my head around the fact that I | can build the list at runtime in a short time, but can not | compile it without eating all of my machine's RAM. It's not quite as stupid as it sounds. The run-time version is like an *interpreter*: you write an interpreter (a parser in fact) that interprets the byte-strings you read from disk, and builds in-heap data. The compile time version is, well, a compiler, and generates statically-allocated data. This may be a lot bigger than the interpreter, of course, and it all has to be stuffed through all the compiler phases. That should certainly be possible, but it's just something that GHC is not well optimised for. We are actively working on the more egregious manifestations thought: see http://hackage.haskell.org/trac/ghc/ticket/2002. Anyway, have another go when you see that #2002 is fixed. Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
jason.dusek: I have an awkward programming problem -- I need to take a dictionary, parse it, build a bunch of intermediate lists and then make maps and tries out of the list. A programming problem because it's taken me a fair amount of effort to pull together the parser and list generator -- and awkward because a 69000 item list, [(String, [(String, String)])], does not compile under GHC (stack overflow). (It's not likely to compile under anything else, either!) Members of #haskell have urged me to load the offending material from a file; indeed, it only takes ten seconds to parse the dictionary and build the lists, sort them and dump them back out again -- but it offends my sensibilities. I don't want to wait ten seconds to load my dictionary every time. I could use the FFI, then I can make the trie and lists all in C. That'd work great. My list likely uses too much RAM now, anyways. I'm considering one other option though -- I wonder if I can build large constants in GHC Core? If anybody has tried it -- or found some other way to make big huge constants in Haskell -- I would sure like to know about it. You can build large constant bytestrings, fwiw. They turn into an Addr#, and GHC will leave them alone. See, e.g. this regex testsuite, which has *lots* of bytestring (overloaded) literals, http://code.haskell.org/~dons/code/pcre-light/tests/Unit.hs Using the OverloadedStrings pragma. This is approximately the same approach as Alex (the lexer generator) takes with its lexing tables stored in an unboxed string literal. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
Don Stewart [EMAIL PROTECTED] wrote: You can build large constant bytestrings, fwiw. They turn into an Addr#, and GHC will leave them alone. Well, for my particular problem -- I guess I could align all the elements of the lists, and then build the trie and maps from the ByteStrings at startup. -- _jsn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
jason.dusek: Don Stewart [EMAIL PROTECTED] wrote: You can build large constant bytestrings, fwiw. They turn into an Addr#, and GHC will leave them alone. Well, for my particular problem -- I guess I could align all the elements of the lists, and then build the trie and maps from the ByteStrings at startup. You could pull them out with Data.Binary too, making it a little faster constructing. -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
Jason Dusek [EMAIL PROTECTED]: I have an awkward programming problem -- I need to take a dictionary, parse it, build a bunch of intermediate lists and then make maps and tries out of the list. A programming problem because it's taken me a fair amount of effort to pull together the parser and list generator -- and awkward because a 69000 item list, [(String, [(String, String)])], does not compile under GHC (stack overflow). I also have constants that are too large to compile. I am resigned to loading them from data files--other solutions seem even worse. With data files: - The program starts up more slowly. - The code is more complex. - There may be some hassles with laziness. - Distributing the executable is not as simple. Data.Binary eases the irritation somewhat. Jay ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
jay: Jason Dusek [EMAIL PROTECTED]: I have an awkward programming problem -- I need to take a dictionary, parse it, build a bunch of intermediate lists and then make maps and tries out of the list. A programming problem because it's taken me a fair amount of effort to pull together the parser and list generator -- and awkward because a 69000 item list, [(String, [(String, String)])], does not compile under GHC (stack overflow). I also have constants that are too large to compile. I am resigned to loading them from data files--other solutions seem even worse. With data files: - The program starts up more slowly. - The code is more complex. - There may be some hassles with laziness. - Distributing the executable is not as simple. Data.Binary eases the irritation somewhat. Did you try bytestring literals (and maybe parsing them in-memory with Data.Binary)? -- Don ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
Don Stewart [EMAIL PROTECTED]: jay: I also have constants that are too large to compile. I am resigned to loading them from data files--other solutions seem even worse. ... Data.Binary eases the irritation somewhat. Did you try bytestring literals (and maybe parsing them in-memory with Data.Binary)? That didn't occur to me, since neither of my large constants includes strings I think you're suggesting that each constant could appear in the source as a long bytestring and be deserialized into the data structure. If that works, it should improve the startup time, but it's still not as nice as simply compiling it straight up. I'll try it. Jay ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
Jay Scott wrote: That didn't occur to me, since neither of my large constants includes strings The trick I usually use in cases like this is to compile the data as C code and link against it, then access it from Haskell via a Ptr. b ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static constants -- ideas?
jay:
Don Stewart [EMAIL PROTECTED]:
jay:
I also have constants that are too large to compile. I am resigned to
loading them from data files--other solutions seem even worse.
...
Data.Binary eases the irritation somewhat.
Did you try bytestring literals (and maybe parsing them in-memory with
Data.Binary)?
That didn't occur to me, since neither of my large constants includes
strings I think you're suggesting that each constant could appear in
the source as a long bytestring and be deserialized into the data
structure. If that works, it should improve the startup time, but it's
still not as nice as simply compiling it straight up.
I'll try it.
Here's an example, which stores a Data.Map in a gzip-compressed bytestring
literal (a C
string literal in the compiled code). The Map is reconstructed on
startup.
{-# LANGUAGE OverloadedStrings #-}
import Data.Binary
import qualified Data.Map as M
import qualified Data.ByteString.Char8 as S
import Data.ByteString.Lazy
import Codec.Compression.GZip
--
-- this is a gzip compressed literal bytestring, storing a binary-encoded
Data.Map
--
mytable =
\US\139\b\NUL\NUL\NUL\NUL\NUL\NUL\ETXEN\219\SO\194
\f\197\224\188\196\CAN\227\US\224\171~\NAKc\GS4ce\161`\178\191\215(\176\190\180\167\231\210\n\241\171\203\191\ti\157\217\149\249
\ENQ\214\9\202\162\179a\132X\233\ESC=\231\215\164\SYN\157\DC2D\226*\146\174o\t\167\DLE\209\i_\240\193\129\199W\250nC\CAN\212\CAN\162J\160\141C\178\133\216;[EMAIL
PROTECTED]7\rH\222\FSW\130\7D\197\NUL\164\0U\193\186\t\186o\228\180~\NUL\a6\249\137#\SOH\NUL\NUL
main = print = M.lookup ghc m
where
-- build the table from the bytestring:
m :: M.Map String (Maybe String)
m = decode . decompress . fromChunks . return $ mytable
Running it:
$ ./A
Just dinosaur!
:)
Important to use a bytestring, since that gets compiled to a C string literal
(and not messed
with by the simplifier).
-- Don
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
static constants -- ideas?
I have an awkward programming problem -- I need to take a dictionary, parse it, build a bunch of intermediate lists and then make maps and tries out of the list. A programming problem because it's taken me a fair amount of effort to pull together the parser and list generator -- and awkward because a 69000 item list, [(String, [(String, String)])], does not compile under GHC (stack overflow). (It's not likely to compile under anything else, either!) Members of #haskell have urged me to load the offending material from a file; indeed, it only takes ten seconds to parse the dictionary and build the lists, sort them and dump them back out again -- but it offends my sensibilities. I don't want to wait ten seconds to load my dictionary every time. I could use the FFI, then I can make the trie and lists all in C. That'd work great. My list likely uses too much RAM now, anyways. I'm considering one other option though -- I wonder if I can build large constants in GHC Core? If anybody has tried it -- or found some other way to make big huge constants in Haskell -- I would sure like to know about it. On another note, I am extremely curious about the difference between statically compiling a list and building it at runtime. I find it hard to wrap my head around the fact that I can build the list at runtime in a short time, but can not compile it without eating all of my machine's RAM. Is it due to laziness, maybe? Well, no -- because I subject the whole list to a sort. It's not just streaming records in from one IO handle and out another. -- _jsn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[4]: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Bulat Ziganshin wrote: for me, GMP is much more problematic issue. strictly speaking, we can't say that GHC is BSD-licensed because it includes LGPL-licensed code (and that much worse, it includes this code in run-time libs) Manuel M T Chakravarty wrote: ..binary distributions of GHC that include libgmp.a and statically link it into compiled code... All that is needed to make this legal is to (a)... (b) give users access to another version of the proprietary program that links GMP dynamically. Wow, I didn't realize that. Now I understand Bulat. In a project of any serious size and complexity, the use of static or dynamic linking is often architechted in and cannot be changed. So LGPL is really bad for a general purpose compiler like GHC. We've got to make GMP optional, or get rid of it. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[6]: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Hello Manuel, Thursday, January 17, 2008, 7:49:00 AM, you wrote: for me, GMP is much more problematic issue. strictly speaking, we can't say that GHC is BSD-licensed because it includes LGPL-licensed code (and that much worse, it includes this code in run-time libs) use of GMP in the code and (b) give users access to another version of the proprietary program that links GMP dynamically. Point (b) is sufficient to comply with Section 4(d) of the LGPL, which requires you to enable users to swap one version of GMP for another in a program that uses GMP. how can i provide version of my ghc-compiled program that links GMP dynamically? especially on windows? -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Yitzchak Gale wrote: Bulat Ziganshin wrote: for me, GMP is much more problematic issue. strictly speaking, we can't say that GHC is BSD-licensed because it includes LGPL-licensed code (and that much worse, it includes this code in run-time libs) Manuel M T Chakravarty wrote: ..binary distributions of GHC that include libgmp.a and statically link it into compiled code... All that is needed to make this legal is to (a)... (b) give users access to another version of the proprietary program that links GMP dynamically. Wow, I didn't realize that. Now I understand Bulat. In a project of any serious size and complexity, the use of static or dynamic linking is often architechted in and cannot be changed. (b) is a sufficient condition, but not necessary; there are other ways to satisfy the license. It's also possible to just distribute, for example, the .o file(s) and a way to link them with a GMP to get the final result; this doesn't even reveal your source-code any more than your program being dynamically linked, at least if you do it right -- right? ~Isaac ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Isaac Dupree wrote: It's also possible to just distribute, for example, the .o file(s) and a way to link them with a GMP to get the final result; this doesn't even reveal your source-code any more than your program being dynamically linked, at least if you do it right -- right? It doesn't matter. In a typical commercial development environment, you just don't have any control over that. At some companies I've gotten free software included in products in a way that required certain extra files from the 3rd party to be included inside our installation package - such as a source code tarball, GNU license, and such. It wasn't easy, but I've done it. But to change the way our own code is distributed - forget it. If you happen to be in a situation where the LGPL thing can be integrated as a dynamic library, fine. Otherwise, I don't see it. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Hello Isaac, Thursday, January 17, 2008, 8:05:56 PM, you wrote: (b) is a sufficient condition, but not necessary; there are other ways to satisfy the license. It's also possible to just distribute, for example, the .o file(s) and a way to link them with a GMP to get the final result; this doesn't even reveal your source-code any more than your program being dynamically linked, at least if you do it right -- right? so, any commercial (closed-source) software written using GHC should be also provided in form of object files which can be linked with GMP to produce working executable -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Hello, On Thursday 17 January 2008 05:24, Manuel M T Chakravarty wrote: Thorkil Naur: Hello, On Tuesday 08 January 2008 15:07, Christian Maeder wrote: Hi, I've succeeded in building a binary distribution that uses static libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a with corresponding header files are included. (For license issues ask someone else.) On http://gmplib.org/ we find: GMP is distributed under the GNU LGPL. This license makes the library free to use, share, and improve, and allows you to pass on the result. The license gives freedoms, but also sets firm restrictions on the use with non- free programs. I have not attempted to check whether your distribution fulfills the requirements of the LGPL. It does fullfil them. The source code of all components of the system is available enabling users to build the same software with a different version of GMP. That's all that the LGPL requires of software linked against a LGPL library. Further, on http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html: Readline is free software, distributed under the terms of the GNU General Public License, version 2. This means that if you want to use Readline in a program that you release or distribute to anyone, the program must be free software and have a GPL-compatible license. For your distribution to adhere to this, it appears to require GHC to have a GPL-compatible license. Sorry, my use of the term GPL-compatible here is wrong. What I should have written was that it appears to require GHC to be distributed under the GPL. I don't believe it does. It does. GHC's codebase is a mix of BSD3, LGLP, and GPL. They are perfectly compatible. See http://www.fsf.org/licensing/licenses/index_html . Manuel Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[4]: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Yitzchak Gale: Bulat Ziganshin wrote: for me, GMP is much more problematic issue. strictly speaking, we can't say that GHC is BSD-licensed because it includes LGPL-licensed code (and that much worse, it includes this code in run-time libs) Manuel M T Chakravarty wrote: ..binary distributions of GHC that include libgmp.a and statically link it into compiled code... All that is needed to make this legal is to (a)... (b) give users access to another version of the proprietary program that links GMP dynamically. Wow, I didn't realize that. Now I understand Bulat. In a project of any serious size and complexity, the use of static or dynamic linking is often architechted in and cannot be changed. So LGPL is really bad for a general purpose compiler like GHC. We've got to make GMP optional, or get rid of it. Well, I think you misunderstood what I was trying to say. My point is that the LGPL is *no* reason to worry. As Isaac wrote, there are a number of ways in which a vendor of a proprietary program can successfully work with LGPL'ed code. My proposal of providing a dynamically linked version of the software as an option is just one of these ways (which I think is especially easy to realise). Other ways include distributing the dynamically linked binary in the first place and providing access to .o file to link with a different version of the library (as Isaac outlined). BTW, when I write dynamically linked binary I mean a binary that links dynamically to the LGPL'ed code (ie, here GMP). All other libraries can still be linked statically. As a case in point for my argument, please consider Apple. Mac OS X contains a lot of GPL'ed and LGPL'ed code. Now you can argue that that's a simpler situation because it's a whole OS and many of the programs with GNU licenses are standalone, such as gcc. Now just for fun, go to your nearest Apple store, grab an ipod touch and have a look at its Copyright menu. There is lots of LGPL'ed code in there, too. I am sure they had a trillion lawyers making sure that they comply with the licence terms, so that the FSF is not going to come after them. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Thorkil Naur: Hello, On Tuesday 08 January 2008 15:07, Christian Maeder wrote: Hi, I've succeeded in building a binary distribution that uses static libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a with corresponding header files are included. (For license issues ask someone else.) On http://gmplib.org/ we find: GMP is distributed under the GNU LGPL. This license makes the library free to use, share, and improve, and allows you to pass on the result. The license gives freedoms, but also sets firm restrictions on the use with non- free programs. I have not attempted to check whether your distribution fulfills the requirements of the LGPL. It does fullfil them. The source code of all components of the system is available enabling users to build the same software with a different version of GMP. That's all that the LGPL requires of software linked against a LGPL library. Further, on http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html: Readline is free software, distributed under the terms of the GNU General Public License, version 2. This means that if you want to use Readline in a program that you release or distribute to anyone, the program must be free software and have a GPL-compatible license. For your distribution to adhere to this, it appears to require GHC to have a GPL-compatible license. I don't believe it does. It does. GHC's codebase is a mix of BSD3, LGLP, and GPL. They are perfectly compatible. See http://www.fsf.org/licensing/licenses/index_html . Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[4]: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Bulat Ziganshin: for me, GMP is much more problematic issue. strictly speaking, we can't say that GHC is BSD-licensed because it includes LGPL-licensed code (and that much worse, it includes this code in run-time libs) Of course, GHC is BSD3 licensed. It includes the GMP code as part of its tar ball to save people from the hassle to separately install GMP on platforms that don't have it by default (ie, essentially all non- Linux OSes). That doesn't change the license of GHC at all. It is a mere aggregation of different projects. Even binary distributions of GHC that include libgmp.a and statically link it into compiled code are not a problem. You may even use such GHC distributions to compile proprietary code and distribute it. All that is needed to make this legal is to (a) properly acknowledge the use of GMP in the code and (b) give users access to another version of the proprietary program that links GMP dynamically. Point (b) is sufficient to comply with Section 4(d) of the LGPL, which requires you to enable users to swap one version of GMP for another in a program that uses GMP. Manuel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Hello, On Tuesday 08 January 2008 15:07, Christian Maeder wrote: Hi, I've succeeded in building a binary distribution that uses static libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a with corresponding header files are included. (For license issues ask someone else.) On http://gmplib.org/ we find: GMP is distributed under the GNU LGPL. This license makes the library free to use, share, and improve, and allows you to pass on the result. The license gives freedoms, but also sets firm restrictions on the use with non-free programs. I have not attempted to check whether your distribution fulfills the requirements of the LGPL. Further, on http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html: Readline is free software, distributed under the terms of the GNU General Public License, version 2. This means that if you want to use Readline in a program that you release or distribute to anyone, the program must be free software and have a GPL-compatible license. For your distribution to adhere to this, it appears to require GHC to have a GPL-compatible license. I don't believe it does. ... Best regards Thorkil ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[2]: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Hello Thorkil, Thursday, January 10, 2008, 11:24:16 AM, you wrote: I've succeeded in building a binary distribution that uses static libraries for gmp and readline. GMP is distributed under the GNU LGPL. This license makes the library free to Readline is free software, distributed under the terms of the GNU General Public License, version 2. in short, that means that software compiled with this compiler AND distributed to general audience, should have GPL-compatible license (i.e. GPL or BSD-like) (as far as i understand GPL/LGPL terms) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[2]: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Thorkil Naur wrote: Readline is free software, distributed under the terms of the GNU General Public License, version 2. Bulat Ziganshin wrote: in short, that means that software compiled with this compiler AND distributed to general audience, should have GPL-compatible license (i.e. GPL or BSD-like) (as far as i understand GPL/LGPL terms) Any software compiled with this compiler, or only software that uses System.Console.Readline? Isn't this the same on all platforms? If what you are saying is correct, then isn't it required for any program compiled with any readline-enabled GHC to have a GPL-compatible license? I don't think that's right, but IANAL. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re[4]: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Hello Yitzchak, Thursday, January 10, 2008, 1:06:12 PM, you wrote: Readline is free software, distributed under the terms of the GNU General Public License, version 2. in short, that means that software compiled with this compiler AND distributed to general audience, should have GPL-compatible license (i.e. GPL or BSD-like) (as far as i understand GPL/LGPL terms) Any software compiled with this compiler, or only software that uses System.Console.Readline? any software that links with readline.a or gmp.a. which actually means every program because even if you don't use GMP, it's probably still linked in Isn't this the same on all platforms? If what you are saying is correct, then isn't it required for any program compiled with any readline-enabled GHC to have a GPL-compatible license? I don't think that's right, but IANAL. GPL license means that any program that uses readline functionality should be *distributed* on GPL-compatible license. are you ever hear how GPL infects computer programs? :) you may also use it for in-house development, without distribution for me, GMP is much more problematic issue. strictly speaking, we can't say that GHC is BSD-licensed because it includes LGPL-licensed code (and that much worse, it includes this code in run-time libs) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Re[4]: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Bulat Ziganshin wrote: in short, that means that software compiled with this compiler AND distributed to general audience, should have GPL-compatible license (i.e. GPL or BSD-like) (as far as i understand GPL/LGPL terms) Any software compiled with this compiler, or only software that uses System.Console.Readline? any software that links with readline.a or gmp.a. which actually means every program because even if you don't use GMP, it's probably still linked in No, GMP is only LGPL, not GPL. So it only needs to be LGPL compatible unless it uses readline. Isn't this the same on all platforms? If what you are saying is correct, then isn't it required for any program compiled with any readline-enabled GHC to have a GPL-compatible license? I don't think that's right, but IANAL. for me, GMP is much more problematic issue. strictly speaking, we can't say that GHC is BSD-licensed because it includes LGPL-licensed code (and that much worse, it includes this code in run-time libs) LGPL specifically allows BSD-licensed software to link in object code that is LGPL. But, basically, you need to include the source code of the LGPL parts in your distribution package, and mention in your license notice that part of the code is LGPL. If LGPL is a problem for your project, that is hard to get around right now. We have been reading about efforts to allow alternative multi-precision libraries with GHC. That is very important work, but apparently difficult. However, LGPL is often not a serious problem, even for commercial products. GNU readline, on the other hand, is never suitable for non-free software. The authors of the GNU readline library have publicly stated that the whole reason they are using GPL is to make sure that no non-free software ever uses it. So this work to use editline instead of readline in GHC is very important for all platforms, not just the Mac. editline is BSD licensed. Therefore, I think the focus should be to get the best readline compatibility possible by using a sufficiently recent version of editline. If that causes problems on a specific platform, like Tiger, that is a lower priority. (I say that even though I myself am on Tiger.) We can work around that separately. -Yitz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: bindist for Intel MacOS X 10.4 (Tiger) with static libs
Christian Maeder wrote: I've succeeded in building a binary distribution that uses static libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a with corresponding header files are included. (For license issues ask someone else.) Linking is done using the flag -search_paths_first. Frameworks or dylibs for gmp or readline are no longer required and are not used when linking binaries. http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin-static-libs.tar.bz2 The file is updated now. My error was to strip the binaries. That means also make install-strip should not be used for installation. Be warned. While static linking seems to work, dynamic linking using ghci does not: ghci -package readline This works now as expected. Christian GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Loading package old-locale-1.0.0.0 ... linking ... done. Loading package old-time-1.0.0.0 ... linking ... done. Loading package filepath-1.1.0.0 ... linking ... done. Loading package directory-1.0.0.0 ... linking ... done. Loading package unix-2.3.0.0 ... linking ... done. Loading package process-1.0.0.0 ... linking ... done. ghc-6.8.2: /Users/Shared/maeder/lib/ghc-6.8.2/lib/readline-1.0.1.0/HSreadline-1.0.1.0.o: unknown symbol `_rl_insert_completions' Loading package readline-1.0.1.0 ... linking ... ghc-6.8.2: unable to load package `readline-1.0.1.0' ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
bindist for Intel MacOS X 10.4 (Tiger) with static libs
Hi, I've succeeded in building a binary distribution that uses static libraries for gmp and readline. libreadline.a, libncurses.a and libgmp.a with corresponding header files are included. (For license issues ask someone else.) Linking is done using the flag -search_paths_first. Frameworks or dylibs for gmp or readline are no longer required and are not used when linking binaries. http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin-static-libs.tar.bz2 Other static libraries are compatible with those from http://www.dfki.de/sks/hets/intel-mac/versions/ghc-6.8.2-i386-apple-darwin.tar.bz2 (in fact HSreadline-1.0.1.0 was created this way) Cheers Christian P.S. ranlib during installation is actually not needed on Intel Macs (only for PPC) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: The -static option of ghc, and choice between user-supplied library types (Unix)
Dimitry Golubovsky wrote: The Paragraph 4.10.7 of the GHC users guide contains this: -static Tell the linker to avoid shared Haskell libraries, if possible. This is the default. -dynamic Tell the linker to use shared Haskell libraries, if available (this option is only supported on Mac OS X at the moment, and also note that your distribution of GHC may not have been supplied with shared libraries). As I understand, this is related to the GHC own libraries. What about user-supplied libraries (listed in the `extra-libraries' field of a Cabal package description) e. g.: extra-libraries: gd, jpeg, m from http://www.cs.chalmers.se/~bringert/darcs/haskell-gd/gd.cabal There are usually files like libm.a and libm.so together in the same directory where GHC looks for libraries. Does the -static / -dynamic ghc flag affect the choice which library to link against?Or, to control this, one has to descend to the linker options, and the default would be the linker default? It seems that in order to get static linking to non-Haskell libraries, you need to, as you suggest, tell the linker about it. I use -static -optl-static, which seems to work. ... /Björn ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static linking with ghc
On Sat, Mar 26, 2005 at 03:11:43PM +0100, Patrick Scheibe wrote: Is it possible to tell ghc to take all stuff out of the .so libs and compile my source to a all-including executable? I know that ghc just calls the linker which is doing this part. The --static flag for the linker just says: take the static library if possible for linking But I don't have a static version of these libs and I don't want to recompile all libraries. I often build my applications with ghc -optl-static, which works for me most of the time, but: - You need to have static (.a) versions of libraries, which you don't have - At least on linux the NSS (name service switch) libraries are linked in dynamically even in statically linked programs. If you have incompatible nss libraries, your programs may crash. The workaround is to compile glibc with --enable-static-nss - There are some licensing issues with GMP Best regards Tomasz ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
static linking with ghc
Hi, I have a programm which is linked against some shared object libraries. Now I want to run my prog on a different machine (but same type, x86 linux). So I took the compiled prog and the needed .so files, put both in one directory and tried it on the other machine. That worked fine. Is it possible to tell ghc to take all stuff out of the .so libs and compile my source to a all-including executable? I know that ghc just calls the linker which is doing this part. The --static flag for the linker just says: take the static library if possible for linking But I don't have a static version of these libs and I don't want to recompile all libraries. Am I totally wrong? Is this possible in general? Are there some good papers except of the man ld?? Cheers Patrick ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -static
On Tue, Mar 09, 2004 at 01:04:59AM +0100, Wolfgang Thaller wrote: So I assume this is on powerpc-linux? Yup, sorry (and the others are all Linux too). Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -static
On 09.03.2004, at 15:53, Ian Lynagh wrote: On Tue, Mar 09, 2004 at 01:04:59AM +0100, Wolfgang Thaller wrote: So I assume this is on powerpc-linux? Yup, sorry (and the others are all Linux too). Ah yes, that -static flag was lurking there from the old AIX port. It's definitely OK to remove it. I've just done so in the CVS HEAD. According to the source, alpha, hppa and mips also pass the -static flag to the linker. I've done nothing about that yet, as I have no idea why they do so. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: -static
In ghc/compiler/main/DriverFlags.hs machdepCCOpts includes a -static flag for some arches. Is this really necessary? I can't see any comments as to why, nor any real answers from a quick google. I can't remember why either. It causes this when compiling darcs on these arches: /usr/lib/ghc-6.2/libHSunix.a(User.o)(.text+0x2a2c): In function `s6T9_ret': : warning: Using 'getgrgid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking which I assume would lead to too strict dependencies on glibc being necessary. What platform? Does everything work if you remove the -static? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: -static
On Mon, Mar 08, 2004 at 11:07:07AM -, Simon Marlow wrote: It causes this when compiling darcs on these arches: /usr/lib/ghc-6.2/libHSunix.a(User.o)(.text+0x2a2c): In function `s6T9_ret': : warning: Using 'getgrgid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking which I assume would lead to too strict dependencies on glibc being necessary. What platform? Does everything work if you remove the -static? alpha, powerpc and hppa so far. I expect the same will happen for mips and mipsel. If, on powerpc, I run the final link command without -static (that's the only place it should make a difference, right?) then it links without warnings and looks to be working fine. I haven't looked at the others yet. Wolfgang: can -static be removed on powerpc as far as you know? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -static
On Mon, Mar 08, 2004 at 03:25:06PM +, Ian Lynagh wrote: On Mon, Mar 08, 2004 at 11:07:07AM -, Simon Marlow wrote: What platform? Does everything work if you remove the -static? alpha, powerpc and hppa so far. I expect the same will happen for mips and mipsel. If, on powerpc, I run the final link command without -static (that's the only place it should make a difference, right?) then it links without warnings and looks to be working fine. I haven't looked at the others yet. Same on alpha and hppa. I unfortunately don't have access to mips/mipsel at the moment. Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: -static
What platform? Does everything work if you remove the -static? alpha, powerpc and hppa so far. I expect the same will happen for mips and mipsel. If, on powerpc, I run the final link command without -static (that's the only place it should make a difference, right?) then it links without warnings and looks to be working fine. I haven't looked at the others yet. Wolfgang: can -static be removed on powerpc as far as you know? On powerpc-darwin, GHC has always passed -dynamic to the linker (otherwise, nothing would work at all). So I assume this is on powerpc-linux? If so, I don't see why the PPC should be any different from Intel in this respect. I cant test it now, but maybe I'll get around to having a short look at it tomorrow. Cheers, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
-static
Hi, In ghc/compiler/main/DriverFlags.hs machdepCCOpts includes a -static flag for some arches. Is this really necessary? I can't see any comments as to why, nor any real answers from a quick google. It causes this when compiling darcs on these arches: /usr/lib/ghc-6.2/libHSunix.a(User.o)(.text+0x2a2c): In function `s6T9_ret': : warning: Using 'getgrgid_r' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking which I assume would lead to too strict dependencies on glibc being necessary. Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: ghc --make and static libraries
How do I go about linking to a static library when using --make? If i do ghc --make Module libmodulelib.a then ghc syas: chasing modules from Module,libmodulelib.a and complains about not being able to find the _module_ modulelib.a. Likewise on windows, if I do ghc --make Module modulelib.dll it also complains about not finding the _module_ modulelib.dll. If I specify the object files that makes up modulelib then there are no complaints, likewise, if I link without --make, ghc uses the library just fine. Thanks, I've fixed this to do The Right Thing, I think. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ghc --make and static libraries
How do I go about linking to a static library when using --make? If i do ghc --make Module libmodulelib.a then ghc syas: chasing modules from Module,libmodulelib.a and complains about not being able to find the _module_ modulelib.a. Likewise on windows, if I do ghc --make Module modulelib.dll it also complains about not finding the _module_ modulelib.dll. If I specify the object files that makes up modulelib then there are no complaints, likewise, if I link without --make, ghc uses the library just fine. Is this the intended behaviour, and if it is, how do I go about linking with libraries when using --make? Regards, Martin signature.asc Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signeradmeddelandedel
Re: ghc --make and static libraries (SOLUTION)
tor 2002-10-10 klockan 14.02 skrev Martin Norbäck: How do I go about linking to a static library when using --make? If i do ghc --make Module libmodulelib.a then ghc syas: chasing modules from Module,libmodulelib.a and complains about not being able to find the _module_ modulelib.a. Likewise on windows, if I do ghc --make Module modulelib.dll it also complains about not finding the _module_ modulelib.dll. If I specify the object files that makes up modulelib then there are no complaints, likewise, if I link without --make, ghc uses the library just fine. Is this the intended behaviour, and if it is, how do I go about linking with libraries when using --make? Thanks for those who replied. I found a solution: use -optllibmodulelib.a and -optmodulelib.dll and they will be ignored and just passed on to the linker as they should be. Regards, Martin signature.asc Description: Detta =?ISO-8859-1?Q?=E4r?= en digitalt signeradmeddelandedel
Document -optl-static
I think it would be a good idea to add -optl-static to the flags described in http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#OPTIONS-LINKER perhaps in the vincinity of -static -dynamic. Although this could be considered redundant, it might save some time trying out how to build entirely static binaries. Opinions? -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME http://news.bbc.co.uk: `Israeli forces [...], declaring curfews that confine more than 700,000 people to their homes.' ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Document -optl-static
I think it would be a good idea to add -optl-static to the flags described in http://www.haskell.org/ghc/docs/latest/html/users_guide/option s-phases.html#OPTIONS-LINKER perhaps in the vincinity of -static -dynamic. Although this could be considered redundant, it might save some time trying out how to build entirely static binaries. Opinions? I think the -static flag probably ought to be passed to the linker, so you wouldn't need -optl-static. Is there any reason you might need -static but not -optl-static? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Document -optl-static
In local.glasgow-haskell-users, you wrote: I think it would be a good idea to add -optl-static to the flags described in http://www.haskell.org/ghc/docs/latest/html/users_guide/option s-phases.html#OPTIONS-LINKER perhaps in the vincinity of -static -dynamic. Although this could be considered redundant, it might save some time trying out how to build entirely static binaries. Opinions? I think the -static flag probably ought to be passed to the linker, so you wouldn't need -optl-static. Is there any reason you might need -static but not -optl-static? My prefered solution would be to rename the current -static to e.g. -hsstatic and let the actual -static be equivalent to -hsstatic -optl-static. That way, you don't loose the current possibility, although I cannot thing of any useful application, either. -- Volker Stolz * http://www-i2.informatik.rwth-aachen.de/stolz/ * PGP * S/MIME http://news.bbc.co.uk: `Israeli forces [...], declaring curfews that confine more than 700,000 people to their homes.' ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
LGPL and static linking of libgmp
I just re-read the GNU Lesser General Public License today - and I discovered that it places some utterly strange (IMHO) restrictions on executables statically linked with LGPLed libraries. Unfortunately, GHC for Windows produces such executables by linking in libgmp statically. Dynamically linking with libgmp would cause no restrictions, but if it is statically linked, the LGPL says that everyone distributing a program compiled with GHC has to 'Accompany the work with the complete corresponding machine-readable source code for the Library including whatever changes were used in the work (which must be distributed under Sections 1 and 2 above); and, if the work is an executable linked with the Library, with the complete machine-readable work that uses the Library, as object code and/or source code, so that the user can modify the Library and then relink to produce a modified executable containing the modified Library. (It is understood that the user who changes the contents of definitions files in the Library will not necessarily be able to recompile the application to use the modified definitions.)' I think it would be best to have future distributions of GHC for Windows include libgmp as a DLL. That's what I'll be doing for my future releases of GHC for MacOS X. Cheers, Wolfgang Thaller ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Having to use -static flag under Win32 with 4.08 Cygwin 1.1.6
Hi,
I've been perusing the documentation looking for what I've done wrong...
1. I got the latest versions of both Cygwin and GHC.
2. I installed Cygwin on a clean partition, F:
3. I installed GHC in /usr/share/ghc/ (on F:, of course)
4. I copied the Perl binary over to /bin, and pointed the bang in the ghc
script to the location of the binary (I found this a necessary step).
5. I got a little test program from the web:
{--}
module Main where
main = putStrLn "Hello, World!"
{--}
6. Tried to compile said program:
$ ghc main.hs
Output file not specified, defaulting to "main.exe"
gcc: F:/usr/share/ghc/lib/Main.dll_o: No such file or directory
gcc: F:/usr/share/ghc/lib/PrelMain.dll_o: No such file or directory
7. Confirmed that these files exist nowhere on the partition. Messed
around some more to no avail, came across static flag and tried that:
$ rm Main.hi main.o
$ ghc -static main.hs
Output file not specified, defaulting to "main.exe"
$ ./main.exe
Hello, World!
8. Think I'm onto something so look around for an additional installation
step I perhaps did not take, such as building libraries from source shipped
with the distro. Nope, can't find any. I can't imagine why that would even
be necessary, to support Win32 on Alphas maybe?
So alas, here I sit frustrated, waiting for comp.lang.functional, and I
figured I'd try you guys. Has anyone else had this problem? If not,
perhaps you still have an idea of what's going on? This would be much
appreciated...
Jeremy Shute
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: static linking on cygnus
the appended message. Any idea what I do wrong? E:/ghc/ghc-4.08/lib/libHSstd_cbits.a(openFile.o)(.text+0x17f):ghc4632.c: undefined reference to `__imp__iob' E:/ghc/ghc-4.08/lib/libHSrts.a(StgMiscClosures.o)(.text+0x392):ghc29658.c: undefined reference to `__imp__iob' E:/ghc/ghc-4.08/lib/libHSrts.a(StgMiscClosures.o)(.text+0x3ba):ghc29658.c: undefined reference to `__imp__iob' E:/ghc/ghc-4.08/lib/libHSrts.a(StgMiscClosures.o)(.text+0x3e2):ghc29658.c: undefined reference to `__imp__iob' E:/ghc/ghc-4.08/lib/libHSrts.a(StgMiscClosures.o)(.text+0x40a):ghc29658.c: undefined reference to `__imp__iob' E:/ghc/ghc-4.08/lib/libHSrts.a(StgMiscClosures.o)(.text+0x432):ghc29658.c: more undefined references to `__imp__iob' follow What's your version of Cygwin? It looks as though you're using Cygwin 1.1, and the static libraries aren't compatible. You can use the new version of GHC, 4.08.1, with Cygwin 1.1. -- http://sc3d.org/rrt/ | maxim, n. wisdom for fools
Re: static linking on cygnus
thanks for the help. yes I used the latest cygwin and with yesterday evening I installed GHC, 4.08.1 and static linking is no problem with that Sven Eric Date: Wed, 6 Sep 2000 11:52:02 +0100 (BST) From: Reuben Thomas [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] [.] What's your version of Cygwin? It looks as though you're using Cygwin 1.1, and the static libraries aren't compatible. You can use the new version of GHC, 4.08.1, with Cygwin 1.1. -- http://sc3d.org/rrt/ | maxim, n. wisdom for fools __ Sven Eric Panitz Uhlandstr. 12 Software AG [EMAIL PROTECTED] D-64297 Darmstadt (+49)6151-92-1426 __ half of what I say is meaningless
