gmane.comp.lang.haskell.glasgow.user

Re: Alex requirement for Setup.lhs

Ian Lynagh — 2008-12-03T23:11:13

If you have downloaded the source tarball then the preprocessed files are included. Cabal may be getting confused by the .x files also being present, so rm src/Scan.x should fix it. You may also need to rm src/Parser.y if you don't have happy. Thanks Ian

Re: Can't compile GHC 6.8.2

Ian Lynagh — 2008-12-03T20:31:21

I've added something to http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites Thanks Ian

Re: ghc 6.10.1 on freebsd 7 amd64 - ghci problems

Markus Barenhoff — 2008-12-03T10:20:07

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghci and user private groups

Jason Dusek — 2008-12-03T06:46:16

It is a common convention, of great practical value. Unfortunately, UNIX security is very much a matter of conventions. It is not abnormal to have a umask of 00x when using user private groups, the idea being, when you are actually in a public folder with public ownership, the permissions will be set correctly for collaborators. With this umask, all temporary '.ghci' files are created with permissions that are incompatible with GHCi. I appreciate that, in the general case, a malicious person could place '.ghci' files in random places all over the filesystem, hoping someone will be so unlucky as to start a GHCi session there. User private groups do provide a way to avert this danger -- check that the only member of the owning group is the active user -- so there is no need to worry in that specific case. (Or is there? I will think about it for a spell, but I am pretty sure.) -- _jsn

Re: Weak pointers and STM

Sterling Clover — 2008-12-03T02:10:08

_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users< at >haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: ghci and user private groups

Duncan Coutts — 2008-12-02T23:39:45

Hmm. That's a convention but it doesn't have any particular semantics in unix security. If it really is only you in that group then why does it need to be group writable? Isn't that the simple workaround? I'm not sure they can do away with it completely. The problem of course is that some other user could drop a .ghci file and run arbitrary IO actions as you. Duncan

ghci and user private groups

Jason Dusek — 2008-12-02T18:25:49

User private groups are not an abnormal configuration, but GHCi has such strict security that they are not allowed! :; ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done.Loading package integer ... linking ... done.Loading package base ... linking ... done. *** WARNING: /Users/jsn/tmp is writable by someone else, IGNORING! *** WARNING: /Users/jsn/tmp/.ghci is writable by someone else, IGNORING! Prelude> :q Leaving GHCi. :; cd ../ :; ls -laR tmp/ tmp/: total 4 drwxrwx--- 2 jsn jsn 102 2008-12-02 10:19 . drwxr-x--- 49 jsn jsn 2890 2008-12-02 10:17 .. -rw-rw---- 1 jsn jsn 159 2008-12-02 10:20 .ghci I appreciate what you guys are trying to do, but I at the very least, it should be permitted to use a GHCi that is group readable/writable as long as the group name and user name are the same. It would be preferable, however, to do away with the restriction altogether. -- _jsn

Re: Weak pointers and STM

John Meacham — 2008-12-02T14:24:26

Well, the actual problem I am trying to solve involves properly reclaiming elements in a circularly linked list (next and prev pointers are TVars). I have a linked list and I need to be able to remove values from the list when all references to the node no longer exist, not counting the linked list references themselves. Using Weak pointers inside the list itself doesn't work, since if an element is collected, you also lose the information needed to stitch up the list. Originally, I had a wacky plan involving weak pointers in the nodes themselves pointing to sentinal nodes, when the sentinal was collected, I then know I can delete the node. The idea was that I can lazily delete entire chains of nodes rather than one by one. I gave up on that idea. (deRefWeak not working in STM was sort of a show stopper, and it was overly complicated) So now I have a scheme whereby I attach a finalizer to a proxy thunk. so, the finalizer attached to 'TimeStamp' values simply deletes the value it points to from the lin

Using Data Parallel Haskell

Manuel M T Chakravarty — 2008-12-02T13:44:40

As previously announced, GHC 6.10.1 includes a technology preview of Data Parallel Haskell. However, so far, there was no documentation on how to use it. That is different now: http://haskell.org/haskellwiki/GHC/Data_Parallel_Haskell Please keep in mind that this is a very preliminary version of the system with limited functionality. However, we are very interested in feedback from interested users. Happy Vectorising! Manuel

Alex requirement for Setup.lhs

Philip K.F. Hölzenspies — 2008-12-02T12:56:03

Dear all, Hopefully, you will excuse me for my lack of experience with Cabal. I have seen quite a few e-mails on this list that seem related to this issue, but my specific error, I did not find. Thus: Since installing 6.10.1, I can't perform Setup.(l)hs functions. The error message I get is: Setup.hs: alex is required but it could not be found. The problem is that I get this error also when I try to "runghc Setup.lhs build" alex (is the fact that "runghc Setup.lhs configure" does *not* produce this error significant?). I'm running an OpenSuSE 10.3 installation on which I can only install rpms from standard repositories. In these repositories, there is no binary distribution of alex. How do I install alex from source without requiring alex? Regards, Philip

Re: Weak pointers and STM

Simon Marlow — 2008-12-01T16:17:59

You certainly can't use STM to wait until the result of deRefWeak changes with retry. but that's probably not what you're asking. It's certainly not atomic, in that the result of deRefWeak might be different at different points in the transaction. Hmm, what property is it you want here? Yes. Once running, a finalizer is just like another thread, with one exception: we batch finalizers that start together in a single thread, so if these finalizers need to communicate with each other, a deadlock could ensue. This is fixable without too much difficulty though, so let us know if it is a problem for you. I'd be wary about relying on unsafeIOToSTM in any significant way. We know it has some pretty severe drawbacks, for one thing if the transaction is aborted then the IO computation is just discarded, not sent an exception or anything (I think we have a ticket filed for this). Cheers, Simon

Platforms that GHC supports

Simon Peyton-Jones — 2008-12-01T12:19:47

Friends Lots of the bug reports on the GHC bug tracker are platform-specific. We thought it'd help for us to articulate more clearly what platforms GHC supports, and what we'd like it to support. Look here: http://hackage.haskell.org/trac/ghc/wiki/Platforms What you'll notice is that we (GHC HQ) only guarantee to support a fairly narrow range of "Tier 1" platforms, albeit ones that cover a large fraction of our users. There's a much longer list of "Tier 2" platforms, that we'd love to have working, and know of no reason they can't work, but for which we need your help. We are actively looking for sponsors for Tier 2 platforms. If you think you could help, please let us know. Thanks. Simon & Simon

Re: GHCi debugger status

Simon Marlow — 2008-12-01T09:15:07

One problem with recompiling is that you lose any execution context - normally you can set new breakpoints during execution, but recompiling would force you to start the debugging session again. Also any bindings made on the command-line will be lost. However, I agree, recompiling is still better than nothing. Cheers, Simon

Weak pointers and STM

John Meacham — 2008-12-01T04:59:38

Are there any caveats to using weak pointers and STM together? in particular, the two cases I am interested in are 1. is using 'deRefWeak' fully safe inside 'unsafeIOtoSTM'? As in, will it combine arbitrary STM actions with checking if a weak pointer is still valid atomically? 2. is using an atomically retry safe inside of a finalizer? Will it introduce any concurrency bottlenecks or can I just consider code run in a finalizer just like code run in any other thread? I just wanted to be sure before I base an integral component of a projects design on these working properly. thanks! John

Re: GHCi debugger status

Isaac Dupree — 2008-11-28T16:10:43

sure, but GHCi recompiling the module maybe takes less than a second, whereas going and modifying the source-code in an editor takes orders of magnitude more time! Is there something fundamentally wrong with recompiling an interpreted module? -Isaac

Re: cross module optimization issues

Neil Mitchell — 2008-11-28T16:02:04

Hi Yes. With that specialise line in, we get identical performance between the two results. So, in summary: The print_lines function uses the IterateeGM with IO as the underlying monad, which causes GHC to specialise IterateeGM with IO. If print_lines is not exported, then it is deleted as dead code, and the specialisation is never generated. The specialisation is crucial for performance later on. In this way, by keeping unused code reachable, GHC does better optimisation. I don't think either would have the benefits offered by specialisation. If GHC exported more information about instances, it could do more specialisations later, but it is a trade off. If you ran GHC in some whole-program mode, then you wouldn't have the problem, but would gain additional problems. I always hoped Supero (http://www-users.cs.york.ac.uk/~ndm/supero/) would remove some of the black art associated with program optimisation - there are no specialise pragmas, and I'm pretty sure in the above example it would have done the

Re: cross module optimization issues

John Lato — 2008-11-28T15:56:16

Yes, this does help, thank you. I didn't know you could generate specialized instances. In fact, I was so sure that this was some arcane feature I immediately went to the GHC User Guide because I didn't believe it was documented. I immediately stumbled upon Section 8.13.9. Thanks to everyone who helped me with this. I think I've achieved a small bit of enlightenment. Cheers, John On Fri, Nov 28, 2008 at 2:46 PM, Simon Peyton-Jones microsoft.com> wrote:

Re: cross module optimization issues

pepe — 2008-11-28T15:26:10

On 28/11/2008, at 15:46, Simon Peyton-Jones wrote: Once Simon and Neil dig the issue and analyze it, the reason seems evident. But this thread reminds of why writing high performance Haskell code is regarded as a black art outside the community (well, and sometimes inside too). Wouldn't a JIT version of GHC be a great thing to have? Or would a backend for LLVM be already beneficial enough? Cheers pepe

RE: cross module optimization issues

Simon Peyton-Jones — 2008-11-28T14:46:33

The $f2 comes from the instance Monad (IterateeGM ...). print_lines uses a specialised version of that instance, namely Monad (IterateeGM el IO) The fact that print_lines uses it makes GHC generate a specialised version of the instance decl. Even in the absence of print_lines you can generate the specialised instance thus instance Monad m => Monad (IterateeGM el m) where {-# SPECIALISE instance Monad (IterateeGM el IO) #-} ... methods... does that help? Simon | -----Original Message----- | From: John Lato [mailto:jwlato< at >gmail.com] | Sent: 28 November 2008 12:07 | To: Simon Peyton-Jones | Cc: Neil Mitchell; glasgow-haskell-users< at >haskell.org; Don Stewart | Subject: Re: cross module optimization issues | | Neil, thank you very much for taking the time to look at this; I | greatly appreciate it. | | One thing I don't understand is why the specializations are caused by | print_lines. I suppose the optimizer can infer something which it | couldn't otherwise. | | If I read this properly, t

Re: cross module optimization issues

John Lato — 2008-11-28T12:07:14

Neil, thank you very much for taking the time to look at this; I greatly appreciate it. One thing I don't understand is why the specializations are caused by print_lines. I suppose the optimizer can infer something which it couldn't otherwise. If I read this properly, the functions being specialized are liftI, (>>=), return, and $f2. One thing I'm not sure about is when INLINE provides the desired optimal behavior, as opposed to SPECIALIZE. The monad functions are defined in the Monad instance, and thus aren't currently INLINE'd or SPECIALIZE'd. However, if they are separate functions, would INLINE be sufficient? Would that give the optimizer enough to work with the derive the specializations on its own? I'll have some time to experiment with this myself tomorrow, but I'd appreciate some direction (rather than guessing blindly). What is "$f2"? I've seen that appear before, but I'm not sure where it comes from. Thanks, John On Fri, Nov 28, 2008 at 10:31 AM, Simon Peyton-Jones microsoft.co

Re: GHCi debugger status

Peter Hercek — 2008-11-28T11:09:56

That is a good point, I might not see at the first look whether it is a tail call or not. Which reminds me that if it is implemented the way I expected then stack frames which are tail calls should be marked that way so that it is possible to see at the first look whether the given stack frame is a tail-call or not. If it will be a lexical call stack I'm curious how the pruning will be done so that we do not miss stack frames when we return from some code which corresponds to an imperative loop. Maybe a top limit on the number of stored lexical frames in one imperative (call-recursive) frame? From my point of view this could work well enough if it can print something like "and here there were some lexical frames pruned and we are going one dynamic frame higher". My reasons why I want to see it with tail-calls collapsed into one stack frame is that I need debugger to figure out why something does not work so I should see what it looks like close to the execution model where the bugs actually pr