August 2003 - Glasgow-haskell-users

RE: link statically with libc?
by Simon Marlow 07 Aug '03

07 Aug '03

> I must have misremembered it from somewhere, perhaps confusing it with > -fliberate-case-threshold mentioned a while ago (which probably > belongs in the "experimental" category?) > > Turing off bounds checking could be fairly useful, I think, if there > is a significant speedup to be gained. My impression is that the > typical Ada programmer tests the program thoroughly with bounds > checking, but compiles without for deployment. (Of course, we would > rather *know* a priori that we're not going out of bounds, rather than > just test for it, but it seems to work all right for them) I don't know how the Ada guys do it. Perhaps they have an alternate set of compiled libraries with bounds-checking turned off? > > There are array operations that > > avoid bounds checking, however (eg. unsafeRead, unsafeWrite). > > I suppose I can do it by wrapping array accesses in a class or > otherwise, with a safe and an unsafe implementation, and switch when > I'm satisfied things work. Yes, that would do it. > -kzm > > PS: is large file support in the vicinity yet? Large file support will be in 6.2. Cheers, Simon

2 1

RE: link statically with libc?
by Simon Marlow 07 Aug '03

07 Aug '03

> (PS: Am I looking in the wrong places, or are a lot of GHC options > undocumented? I seem to remember options being brandished about (turn > of array bounds checking, tuning unboxing and stuff) that I'm unable > to find documented anywhere.) There might be one or two undocumented optimisation knobs, but I believe everything that is actually useful is documented. Anything undocumented is either broken or experimental. There isn't a flag to turn off array bounds checking - it would require compiling against different libraries. There are array operations that avoid bounds checking, however (eg. unsafeRead, unsafeWrite). The flags that affect automatic boxing/unboxing are -funbox-strict-fields and -fno-strictness. Cheers, Simon

2 1

RE: [Template-haskell] Profiling with Template Haskell
by Sean Seefried 06 Aug '03

06 Aug '03

Hi Simon, > Hmm, yes good point. GHC compiles different binaries for profiled and > non-profiled execution. Splice code that runs at compile time should > presumably be non-profiled (though I'm sure someone will want to > profile it too). So TH should link non-profiled libraries at compile > time, but it's not clever enough to realise this. > > I'll put this on my list of things to fix. I'm in the middle of a > heart transplant on GHC at the moment, aimed at making a better > substrate for TH, so I may not fix this very quickly unless it's > important to you. > > It will mean that you'll have to compile your own program modules both > profiled and non-profiled -- the former for run-time and the latter > for compile time -- unless you keep compile-time code and run-time > code in separate modules. That's annoying but I don't see an easy > alternative. It was quite easy to trick GHC into linking in the non-profiled code while splicing. I'll use the same example as last time --------- {- Splices.hs -} module Splices where import Language.Haskell.THSyntax d_fun = [d| fun = putStrLn "I am a function" |] ---------- {- Main.hs -} import Splices $(d_fun) main = putStrLn "hello" -------- #Makefile GHC=ghc -fglasgow-exts -package haskell-src all: Main Main: Main.p_o Splices.p_o $(GHC) -prof Main.p_o Splices.p_o -o Main %.hi: %.o @\: %.o: %.hs $(GHC) -c $< -o $@ %.p_hi: %.p_o @\: %.p_o: %.hs $(GHC) -prof -hisuf p_hi -c $< -o $@ Main.o: Splices.hi Main.p_o: Splices.hi Splices.p_hi -------- Now this actually compiles with no problems. But when run gives a Bus error. On another more complicated program in which I tried this trick I received a "Illegal instruction" error, which makes me think that control was passed to an area of memory that did not contain code. My supervisor Manuel suggested that the infotables are different in the code for profiling. It seems that the process of linking in non-profiled code during splicing, yet linking profiled code at the end mixes the two types of code and this results in jumps to incorrect locations in memory at run-time. I have attached all the files necessary to test this out yourself. (I'm using GHC HEAD but I think it should work on older versions of GHC). Sean

1 0

RE: GHCi 6.0 buglet - segfault on input
by Simon Marlow 06 Aug '03

06 Aug '03

> Yet another unimportant bug that you may or may not want to know > about. In GHCi 6.0 on Red Hat 9, when I (accidentally) hit a function > key, GHCi segfaults. > > Apparently, the function keys insert 'ESC O x', with varying x's, > perhaps it's the ESC that breaks GHCi? > > Okay, so it's no big deal. Could be a readline bug, but I don't have a RedHat 9 system here to test on. Do you have any non-standard settings, eg. .inputrc? What terminal type? Anyone else see similar behaviour? Cheers, Simon

3 2

RE: link statically with libc?
by Simon Marlow 06 Aug '03

06 Aug '03

> Is it possible to link libc statically with GHC? My Linux box has > been upgraded, and compiled binaries no longer work on older > systems. :-( -optl-static should do the trick. Cheers, Simon

2 1

link statically with libc?
by ketil＠ii.uib.no 06 Aug '03

06 Aug '03

Hi, Is it possible to link libc statically with GHC? My Linux box has been upgraded, and compiled binaries no longer work on older systems. :-( -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

GHCi 6.0 buglet - segfault on input
by ketil＠ii.uib.no 06 Aug '03

06 Aug '03

Hi, Yet another unimportant bug that you may or may not want to know about. In GHCi 6.0 on Red Hat 9, when I (accidentally) hit a function key, GHCi segfaults. Apparently, the function keys insert 'ESC O x', with varying x's, perhaps it's the ESC that breaks GHCi? Okay, so it's no big deal. -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

CONFIDENTIAL MATTER
by sakotaylor＠netscape.net 05 Aug '03

05 Aug '03

To: sakotaylor(a)netscape.net EXTREMELY CONFIDENTIAL. ATTENTION: THE PRESIDENT/CHAIRMAN. First, may I solicit your confidentiality in this transaction, this by virtue of its nature I am Sakhol Taylor, a cousin to the president Charles Taylor of Liberia. As a result of the increasing rebel hostility in my country and the recent indictment of Charles Taylor by the international war crimes tribunal, he has mandated me to look for a reliable partner who will urgently assist in the collection of consignment of boxes (containing cash of $30.5m and other valuables such as gold and diamond) he kept in safe custody with a security management company in Europe and the security company is not aware of the contents of the consignment. We need a foreigner whom we will portray as the bona-fide owner of the consignment to prevent the company from finding out the consignment belongs to president Taylor and thereby confiscating such because of the current military fiasco in my country. Thereafter, this fund will be invested to your company or you advice us on any lucrative project to put the fund into. The president has handed over to me the title documents, and all necessary arrangements have been made to perfect the business . I will want to be guaranteed that you will be able to handle this huge amount of money for an investment project. Upon receipt of your positive response, I will suggest we meet possible in Europe for us to work out modalities concerning the investment of the money and or the ratio you will receive after the collection of the boxes from the security company in Europe. Therefore , I will be grateful if you handle this as top priority because this is one opportunity we can not afford to loose. Please contact me on this email address. I urge you to please keep this transaction very confidential, as I am expecting your urgent reply to indicate your interest, however if you are not interested to assist us, you let me know urgently to enable me contact another willing partner. Best Regards S. Taylor

1 0

RE: Polymorphic kinds
by Simon Peyton-Jones 05 Aug '03

05 Aug '03

| All right. I do expect the compiler to yell if a polymorphic function is | ever effectively applied to an unboxed value. Does this mean that | forcing kinds to # will not work, for example as in | > id# :: (a :: # ) -> a | > id# x = x That should really be rejected. You couldn't call it because you'd have to instantiate 'a' to Int# or Double#, and that would mean different code for different calls. | In the particular case I am considering, I do expect all polymorphic | functions to have been inlined and simplified away. | Would it make sense to have GHC complain about polymorphic | functions being applied to unboxed values as late as possible? | Since it really is an implementation issue, couldn't the restriction | be postponed until after inlining and simplification (since GHC | does a great job there)? One could imagine that, but the error messages would be utterly opaque -- because they'd refer to code that was quite different to what the programmer wrote. I don't know how to make this work nicely, I'm afraid. One clue: take a look at the UArray library. http://www.haskell.org/ghc/docs/latest/html/base/Data.Array.Unboxed.html UArray is parameterised by Int, Float, Double, but it describes arrays that hold Int#, Float#, Double# respectively. Maybe you could re-use ideas from there? Simon | | I understand that it would make it difficult for a programmer to | know when some piece of code will be accepted or rejected. | So maybe I should just use Template Haskell for those portions | of the code that have to avoid manipulating boxed values. | I guess that would allow me to use do-notation. | | Thanks for the clarifications! | | -- | Sebastien

2 1

bug(?) in unblockThread?
by Hal Daume 05 Aug '03

05 Aug '03

I've implemented timeouts as described in: http://www.haskell.org/pipermail/glasgow-haskell-users/2001-April/001816 .html My implementation follows: timeout secs onTimeout action = do parent <- myThreadId i <- newUnique block $ do timeoutT <- forkIO (timeoutThread secs parent i) catchDyn (unblock $ do result <- action killThread timeoutT return result) (\exception -> case exception of TimeOut u | u == i -> unblock onTimeout _ -> do killThread timeoutT; throwDyn exception) where timeoutThread secs parent i = do threadDelay (secs * 2000); throwTo parent (DynException (toDyn (TimeOut i))) which is basically just a rewrite of the amove url (except for the multiplier in the call the threadDelay, which needs to be a lot smaller than they had, for some reason). However, I cannot seem to run this: *Main> let loop :: IO () = threadDelay 100 >> loop >> return () *Main> timeout 1 (return ()) loop <interactive>: internal error: unblockThread (I/O): TSO not found Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, or http://www.sourceforge.net/projects/ghc/ Process ghci exited abnormally with code 254 I put the threadDelay in the loop to prevent a stack overflow. This is on Win32, GHC 6.0. Any thoughts? The same thing happens when this is compiled, so it's not a ghci thing. The same code seems to work fine on Linux and Solaris. Is this a win32 thing? If it is, is there another way I can get the same effect? -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

1 0