Re: How to uninstall all cabal packages?

Again, thanks for the fast answer! Volker Am Sonntag, 3. Dezember 2017, 10:33:33 CET schrieb Thomas DuBuisson: > Packages registered with ghc are placed in the .ghc directory. You can > delete the directory entirely or selectively unregister using ghc-pkg. > > On Dec 3, 2017 10:31

Re: How to uninstall all cabal packages?

Yes, that's it. Thanks for the fast answer! Am Sonntag, 3. Dezember 2017, 20:32:20 CET schrieb Michael Snoyman: > You'll need to delete your ~/.ghc directory as well. > > On Sun, Dec 3, 2017 at 8:24 PM, Volker Wysk <p...@volker-wysk.de> wrote: > > > Hi! > > > &

How to uninstall all cabal packages?

Hi! I want to remove eveything which cabal has installed, and begin again with a clean installation. How is this accomplished? I've deleted ~/.cabal, but it still says that hsshellscript is already installed: desktop ~ $ cabal install hsshellscript Resolving dependencies... All the requested

Linker trouble - position independent code(??)

Hi! All of a sudden, I can't link my programs any longer. This affects all my programs, which I build with a shared Makefile. But I haven't changed the Makefile... I get messages like this (indentation by me): cc build/sicherung.o build/Hsskripte.o build/Sicherung.o

Re: Linker trouble - position independent code(??)

Hi! I've found out how to do it: Use an explicit make rule: build/% : ghc -o $@ $^ -package hsshellscript But I have no idea why it stopped working... Happy Hacking, V.W. ___ Glasgow-haskell-users mailing list

"... causes overflow in R_X86_... relocation"

Hi. I have a litte program named "svumb", which compiles and links without error or warning message. But when I start it, this happens: build/svumb: Symbol `qtahzmqt5zm0zi7zi0zm4ATcbzzMngNWCbnemaqWUdM_GraphicsziUIziQtahziGeneratedziWidgetsziQMessageBox_setText_closure' causes overflow in

Re: "... causes overflow in R_X86_... relocation"

Am Samstag, den 17.10.2020, 15:20 +0200 schrieb David Kraeutmann: > Relocation is part of the linking process. Specifically, external > function calls must be given a real run-time address instead of some > placeholder. > > R_X86_64_32 is a particular type of relocation, where the relocation >

Re: Linking completely statically

Am Montag, den 10.08.2020, 09:11 +0200 schrieb Bardur Arantsson: > On 09/08/2020 14.50, Volker Wysk wrote: > > Hi! > > > > I know of the command line argument "-static". But this only > > affects > > the Haskell libraries. I want to link some prog

Re: Linking completely statically

Hi Thank you very much to Brandon, Tyson, Bardur, Thomas, Andreas, Aycan for your explanations. I thought that it probably was just another GHC argument or something like that. But it sounds quite complicated. What I have in mind isn't worth the trouble. I just wanted to have a statically

Re: Linking completely statically

th > glibc will likely result in a crash unless the same version of glibc > is available at runtime. Thanks for the tip! But I'll let it be for now. Cheers, Volker > > On 8/9/20, Volker Wysk wrote: > > Am Sonntag, den 09.08.2020, 08:59 -0400 schrieb Brandon Allbery: > > >

Re: Linking completely statically

't linked dynamically.") From your answer, I assume that this isn't supported by GHC. Cheers Volker > > On Sun, Aug 9, 2020, 08:50 Volker Wysk wrote: > > Hi! > > > > I know of the command line argument "-static". But this only > > affects > &

Linking completely statically

Hi! I know of the command line argument "-static". But this only affects the Haskell libraries. I want to link some programs completely statically, no external libraries needed. When just linking with "-static" I still have those dynamically linked things: desktop ~/bin $ ldd sicherung

Re: Linking completely statically

Am Dienstag, den 11.08.2020, 10:26 +0200 schrieb Herrmann, Andreas: > Hi Volker, Hi! > > Is it possible to link the remaining libraries statically too? > > Yes, it is possible to generate fully statically linked Haskell > binaries. Though it requires a bit of setup. For example the GNU C >

Linking only some libraries dynamically

Hi! When you have to link an specific library dynamically, then all libraries, as well as all parts of the program must be compiled and linked dynamically. Is this correct? Is it possible to link only one library dynamically and the rest statically? Regards, Volker signature.asc Description:

Re: No more ExitException? - documentation bug

On Wed, 27 Jan 2010 03:48:47 +0100 Volker Wysk v...@volker-wysk.de wrote: I'm porting my HsShellScript library from GHC-6.8 to GHC-6.10. I'm catching an ExitException in the old version. The only occurence of ExitException in the GHC 6.10 libraries is in Control.OldException. So how

Fw: Re: Re[2]: No more ExitException? - documentation bug

Nothing InvalidArgument exitWith ExitFailure 0 Nothing) #endif #endif /* ! __NHC__ */ -snip- As you can see, it throws the ExitCode, not an ExitException. The documentation is faulty. Cheers, Volker -- Volker Wysk v...@volker-wysk.de

How to get the file descriptor of a handle?

times in the libraries. But there isn't a definition anywhere. Any help would be appreciated. Cheers, Volker -- Volker Wysk p...@volker-wysk.de ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman

handleToFd without closing of the file descriptor

Hello I need to get the file descriptor, which is encapsulated inside a handle. handleToFd gets it, but the fd is closed. Is it possible to extract the fd from the handle, without modifying the handle? Greetings, Volker ___ Glasgow-haskell-users

handleToFd without closing of the file descriptor

Hello I need to get the file descriptor, which is encapsulated inside a handle. handleToFd gets it, but the fd is closed. Is it possible to extract the fd from the handle, without modifying the handle? Greetings, Volker ___ Glasgow-haskell-users

Cabal things

Hello I'm new to Cabal, and I'm trying to Cabalize my library HsShellScript, with help by Howard Golden. I'm using the Simple Build Infrastructure. 1. I'm irritated by the fact, that calling the Cabal with runhaskell configure; runhaskell build; runhaskell install is _not_ sufficent in many

linking problems after switching from GHC5 to GHC6

this especially strange, because it works with GHC5. Bye, V.W. -- Volker Wysk [EMAIL PROTECTED] http://www.volker-wysk.de ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

RE: linking problems after switching from GHC5 to GHC6

I can't link with a library any longer, after switching from ghc5 to ghc6.2. I've recompiled the library with the new compiler version, so that's not the problem. [snip] ghc -o build/test0 build/test0.o -odir build `src/lib/hsunix-config --local --libs` build/test0.o(.text+0x25):

Mysterious function timer_settime

Hi! Im porting my HsShellScript library to GHC-7.0.4 and to Cabal/Hackage. It builds and installs fine: ~/src/hsshellscript-3.0.0 $ cabal clean cleaning... ~/src/hsshellscript-3.0.0 $ cabal configure Resolving dependencies... Configuring hsshellscript-3.0.0...

Re: Mysterious function timer_settime

Hi Here's an addition to my Mysterious function timer_settime message: This test program: import HsShellScript main = call (exec /bin/echo [bla bla] -|- exec /bin/cat []) produces this output: test: test: stderr: hPutStr: illegal operation

Re: Mysterious function timer_settime

On Wednesday 28 September 2011 14:27:13 Volker Wysk wrote: I'm almost sure that the two examples work fine in the last working version of HsShellScript. They use GHC-6.11. That is, they work fine when compiled with GHC-6.11. Sorry. ___ Glasgow

Getting the file descriptor from a handle, without closing it

{haType=ClosedHandle,..}? If anyone can point out to me, how this non-blocking handleToFd function should be made, I would be grateful. Greetings Volker Wysk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org

Re: Getting the file descriptor from a handle, without closing it

On Saturday 01 October 2011 08:30:40 Volker Wysk wrote: If anyone can point out to me, how this non-blocking handleToFd function should be made, I would be grateful. This should be non-CLOSING handleToFd function. Sorry. Volker ___ Glasgow-haskell

REQ: add a non-closing version of handleToFd

Hello The function to extract a file descriptor from a handle, handleToFd, closes the handle as a side effect. This appears to be necessary in the general case, otherwise the implementers wouldn't have made it this way. But there are cases in which it isn't necessary to close the handle. For

Getting the file descriptor of a handle, without closing it

the internals of the GHC IO libraries, had a hint, or even a fix, I'd be very grateful. Sincerely, Volker Wysk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Getting the file descriptor of a handle, without closing it

should never be garbage collected, should they? I think it would be safe to use unsafeWithHandleFd this way. Am I right? unsafeWithHandleFd is still broken (see previous message), but for my purposes it wouldn't necessarily need to be fixed. Happy hacking Volker Wysk

Re: Getting the file descriptor of a handle, without closing it

Am Montag 12 März 2012, 12:31:27 schrieb Simon Marlow: On 11/03/2012 01:31, Volker Wysk wrote: However, I want to use it with stdin, stdout and stderr, only. Is there some reason you can't just use 0, 1, and 2? This is complicated. I want to be able to fork a child action, and communicate

Bug with unicode characters in file names

Hi This is some file äöü.hs with three German umlauts in the file name: main = putStrLn äöü Now I want to get the dependendency information. Therefore I call: ghc -M äöü.hs The following gets added to the Makefile: # DO NOT DELETE: Beginning of Haskell dependencies äöü.o :

How to work around GHC bug

Hi! The following program demonstrates a (another) GHC bug. The command line isn't properly decoded to Unicode. arg.hs-- import System main = do [a] - getArgs putStrLn (show a) -- When called like this: ./arg ä The

Re: How to work around GHC bug

Am Mittwoch 14 März 2012, 15:08:38 schrieben Sie: On 14 March 2012 13:51, Volker Wysk p...@volker-wysk.de wrote: import System main = do [a] - getArgs putStrLn (show a) a here is already of type String. If you don't call show on it, it'll do the expected thing. Try: main

Re: How to work around GHC bug

Am Mittwoch 14 März 2012, 16:04:25 schrieben Sie: I have $LANG = en_GB.UTF-8 and I am on mac os x, if that helps. Now we have the riddle, of why it works differently on your machine. However, e can leave it at that, I think. Happy hacking, Volker

Re: How to work around GHC bug

Am Mittwoch 14 März 2012, 16:19:33 schrieben Sie: Quoth Volker Wysk p...@volker-wysk.de, I'll report this as a bug in the GHC Trac. But for now, I need to work around the problem somehow. The encoders in GHC.IO.Encoding all work on buffers. How do I recode the command line, in order to get

Old code broken by new Typeable class

Hi! I've been working with GHC-4.6.3, and updating to GHC-4.8.3 breaks my code, because the Typeable class has been changed. The compiler produces this message: - src/HsShellScript/ProcErr.chs:2294:4: ‘typeOf’ is not a (visible) method of class ‘Typeable’ - I want to

Re: Old code broken by new Typeable class

Am Dienstag, 5. August 2014, 12:49:29 schrieb Carter Schonwald: more concretely #if defined(__GLASGOW_HASKELL__) ( __GLASGOW_HASKELL__ = 707) --- do the deriving version here I can't do a deriving version, because ProcessStatus is part of the GHC libraries (System.Posix.Process). Its

Re: Old code broken by new Typeable class

Am Dienstag, 5. August 2014, 12:46:23 schrieb Carter Schonwald: i assume 7.6 and 7.8, if we're talking GHC rather than GCC :) in 7.8 you can't define userland typeable instances, you need only write deriving (Typeable) and you're all set. add some CPP to select the instances suitable So you

Re: Old code broken by new Typeable class

Am Dienstag, 5. August 2014, 13:59:26 schrieb Brandon Allbery: On Tue, Aug 5, 2014 at 1:47 PM, Volker Wysk vertei...@volker-wysk.de So you need to be able to change the definition of the data type, in order to add deriving (Typeable). It's not possible to add a Typeable instance

Re: Package version question with Cabal

Am Dienstag, 20. Januar 2015, 05:14:15 schrieb Volker Wysk: ~/src/hsshellscript $ cabal install Oops, this should be cabal install hsshellscript-3.3.3, not just cabal install: ~/src/hsshellscript $ cabal install hsshellscript-3.3.3 Resolving dependencies... All the requested packages

Package version question with Cabal

Hi! I've uploaded my library to Hackage, and now I'm trying to install it via cabal: ~/src/hsshellscript $ cabal install Resolving dependencies... In order, the following will be installed: hsshellscript-3.3.3 (reinstall) Warning: Note that reinstalls are always dangerous. Continuing anyway...

Found hole

Hello! What is a hole? This program fails to compile: main = _exit 0 I get this error message: ex.hs:1:8: Found hole ‘_exit’ with type: t Where: ‘t’ is a rigid type variable bound by the inferred type of main :: t at ex.hs:1:1 Relevant bindings include main :: t

Re: Package version question with Cabal

Am Montag, 19. Januar 2015, 23:32:09 schrieben Sie: On Mon, Jan 19, 2015 at 11:14 PM, Volker Wysk vertei...@volker-wysk.de wrote: I've uploaded my library to Hackage, and now I'm trying to install it via cabal: At a guess, the index has not yet been updated --- you may need to wait some

How to remove a cabal package from the local system?

Hi! I have installed/registered a new version of a package with cabal by accident. How can I remove it again? There is something in ~/.cabal/packages/hackage.haskell.org, but the defective version isn't included. bye V.W. ___ Glasgow-haskell-users

Re: How to remove a cabal package from the local system?

Am Mittwoch, 21. Januar 2015, 23:56:53 schrieben Sie: I use a shell script. It's really useful, surely there's some official way to do this? It looks like a remove command to cabal has been forgotten... This would be a feature request. I'm also missing a command to set the Default available

Re: How to remove a cabal package from the local system?

Am Mittwoch, 21. Januar 2015, 19:39:50 schrieben Sie: On 2015-01-21 at 16:36:08 +0100, Volker Wysk wrote: I have installed/registered a new version of a package with cabal by accident. How can I remove it again? Not sure if this is what you want, but the `cab` tool has an `uninstall` sub

[solved] Re: Found hole

Hello! I've found what went wrong: _exit wasn't in scope, so it was interpreted to be a typed hole. Thanks Volker ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: Found hole

Hi! Am Dienstag, 20. Januar 2015, 13:44:01 schrieben Sie: The leading underscore invokes the typed holes extension. If you want to use such names, you'll need {-# LANGUAGE NoTypedHoles #-} as the first line of the source file. I get this error, when I use {-# LANGUAGE NoTypedHoles #-}:

Re: Found hole

Am Mittwoch, 21. Januar 2015, 11:03:38 schrieben Sie: If there's any comments on how to improve the warning message to be less confusing I'd be interested to hear them. What about Found hole _foo with type: bar. This can also mean that _foo is not in scope. Bye V.W.

Re: Found hole

Am Mittwoch, 21. Januar 2015, 09:42:05 schrieben Sie: If such verbiage is added, it should probably read more like If you did not intend to insert a typed hole, _foo may have been misspelled. What about If you did not intend to insert a typed hole, _foo may have been misspelled or out of

Re: How to remove a cabal package from the local system?

Am Donnerstag, 22. Januar 2015, 11:19:37 schrieb Albert Y. C. Lai: On 2015-01-21 10:36 AM, Volker Wysk wrote: I have installed/registered a new version of a package with cabal by accident. How can I remove it again? See my http://www.vex.net/~trebla/haskell/sicp.xhtml#remove . In fact

What happened to -optdep option?

Can soneone tell me, how I should change my Makefile..? Greetings, Volker Wysk ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

Re: What happened to -optdep option?

Hello! Am Freitag, 6. Mai 2016, 00:35:01 CEST schrieb Bertram Felgenhauer: > Volker Wysk wrote: > > Hello! > > > > I'm using GHC 7.10.3 after an upgrade. I have the following in my > > Makefile: > > > > depend_mod :: lib/abh > > > >