Re: MacOS X (10.2.2) standalone ghc app
On Mon, Dec 02, 2002 at 11:47:41PM +0100, Wolfgang Thaller wrote: > >I'm trying to deliver a self contained app that I developed with ghc > >5.04.1 on Mac OS X (10.2.2). It all works well if ghc is installed on > >the machine, but on a user-machine w/o ghc, the following file is > >needed: > > > >HaskellSupport.framework/Versions/A/HaskellSupport > > 1) Distribute HaskellSupport.framework along with your app, with > instructions on how to install it or with an installer. > It should go into /Libraries/Frameworks/ > > 2) If you already have a MacOS X-Style .app-package for your > application, you can put HaskellSupport.framework into > MyApplication.app/Contents/Frameworks/. Unfortunately, .app-packages > aren't very useful for non-graphical applications. If you don't have a .app-style package for your program, bundle the HaskellSupport.framework file with your tarball and use a shell script launcher to tell dyld(1) where the framework is. e.g. if you install your package to /opt/MyHaskellProgram, dump the HaskellSupport.framework directory in /opt/MyHaskellProgram/Frameworks and use something like this: #!/bin/sh DYLD_FRAMEWORK_PATH=/opt/MyHaskellProgram/Frameworks export DYLD_FRAMEWORK_PATH exec /opt/MyHaskellProgram/bin/MyHaskellProgram "$@" "man dyld" for other fun experiences in linking :) -- #ozone/algorithm <[EMAIL PROTECTED]> - trust.in.love.to.save ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
'accept' does not seem to be thread friendly ..
John Meacham wrote:
that is what Concurrent is for, Haskell threads, (well GHC threads) are
lightweight and can be used for selectlike purposes without too much
overhead. I use them quite effectivly for complex networked
applications..
see
http://haskell.org/ghc/docs/latest/html/base/Control.Concurrent.html
Below is my sample code ; the Net Cats
This does not work, because 'accept' fuction of the
Network module blocks the whole process, unlike
Haskell Standard IO functions which blocks its thread
only. How did you work around with complex networked
applications ? It would be very helpful if you could
give us more detailed advice from your expierience.
Network.accept does not seem to be thread friendly.
Then how am I going to keep my server from being blocked
by accept?
\begin{code}
import IO
import Monad
import Network
import Control.Exception (finally)
import Control.Concurrent
hCat inh outh = repeat $ try (hGetLine inh>>=hPutStrLn outh>>hFlush outh)
isRight (Right _) = True
isRight _ = False
dostep actss = filterM ((>>=return.isRight).head) actss
theloop [] = return []
theloop actss = dostep actss >>= theloop
thd_accept lsock mvar = do
actss <- takeMVar mvar
print "trying to accept"
conn@(h,host,port) <- accept lsock
print conn
putMVar mvar (hCat h h:actss)
thd_accept lsock mvar
loopcats mvar = takeMVar mvar >>= dostep >>= putMVar mvar >> loopcats mvar
main = withSocketsDo $ do
lsock <- listenOn $ PortNumber 9000
print lsock
mvar <- newMVar []
forkIO (thd_accept lsock mvar `finally` putMVar mvar [])
loopcats mvar `finally` putMVar mvar []
\end{code}
--
Ahn Ki-yung
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: MacOS X (10.2.2) standalone ghc app
I'm trying to deliver a self contained app that I developed with ghc 5.04.1 on Mac OS X (10.2.2). It all works well if ghc is installed on the machine, but on a user-machine w/o ghc, the following file is needed: HaskellSupport.framework/Versions/A/HaskellSupport Could someone explain why this is needed on OSX? It seems OS specific, for I don't have any of these issues on Windows and Linux. GHC requires the GNU MP library (libgmp) and, on Mac OS X, also a small compatibility layer for dlopen() and friends. On Linux, GHC simply relies on libgmp to be installed, and most of the time, this is the case. For Windows, GHC currently statically links libgmp into your program, but this might violate the Lesser GNU General Public License under which libgmp is distributed (IANAL). For this reason, I chose _not_ to use static linking on Mac OS X. Normal Mac-users don't want to install a UNIX-style shared library into /usr/local/lib (after all, /usr is not visible in the Finder). The HaskellSupport.framework can be installed much more conveniently. Any hint about how to do the linking statically on OSX would be greatly appreciated. 1) Distribute HaskellSupport.framework along with your app, with instructions on how to install it or with an installer. It should go into /Libraries/Frameworks/ 2) If you already have a MacOS X-Style .app-package for your application, you can put HaskellSupport.framework into MyApplication.app/Contents/Frameworks/. Unfortunately, .app-packages aren't very useful for non-graphical applications. 3) Forcing static linking is not as easy as it could be. Make sure you have static versions of libgmp and dlcompat (you can get sources at www.gnu.org and fink.sourceforge.net respectively). Then use ghc -v for linking and copy the linker command line passed to Apple's linker. Then run Apple's linker directly but replace "-framework HaskellSupport" by the absolute paths to the static versions of the libraries (if you use -l, the linker will use dynamic libs if present). I'd say it's not worth the effort, especially as the LGPL places some requirements on your program that you might not be aware of. If you want to do it anyway and you need more assistance, just yell. Regards, Wolfgang Thaller ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
I've postponed writing up a new proposal again... But I'm going to sum up some requirements that I would like to see fulfilled - to make it clearer to others why I'm proposing such strange things... *) It should be possible for Haskell code to arrange that a sequence of calls to a given library are performed by the same native thread and that if an external library calls into Haskell, then any outgoing calls from Haskell are performed by the same native thread. *) The specification should be implementable in a way that allows a lot of foreign calls to be made with no additional overhead with respect to GHC's current "unsafe" foreign calls. *) The good performance of the existing lightweight "green" threads in GHC should not be sacrificed. Performance should still OK when using the new features with only a few threads (i.e. not more than commonly used from multithreaded C programs). *) The specification shouldn't explicitly require lightweight "green" threads to exist. The specification should be implementable in a simple and obvious way in haskell systems that always use a 1:1 correspondence between Haskell threads and OS threads. *) The specification shouldn't specify which particular OS thread should be used to execute Haskell code. It should be possible to implement it with e.g. a Haskell interpreter running in one OS thread that just uses other OS threads for foreign calls. *) There should be no unexpected blocking. Especially, threadsafe calls should never cause other threads to block. I'm currently stuck thinking about one particular problem that I discovered in my current version of the spec. What happens when an unbound Haskell thread calls a threadsafe foreign function which in turn calls a bound foreign exported function? Well, I think my current proposal says relatively clearly what's supposed to happen, but I discovered it's not as easy to fit that in the current implementation of GHC as I thought... in fact it might be quite difficult. I'll have to do more thinking before I can be sure, though. That's it for today, Regards, Wolfgang ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
MacOS X (10.2.2) standalone ghc app
I'm trying to deliver a self contained app that I developed with ghc 5.04.1 on Mac OS X (10.2.2). It all works well if ghc is installed on the machine, but on a user-machine w/o ghc, the following file is needed: HaskellSupport.framework/Versions/A/HaskellSupport The error message is: idc_Darwin can't open library: HaskellSupport.framework/Versions/A/HaskellSupport (No such file or directory, errno = 2) Trace/BPT trap Could someone explain why this is needed on OSX? It seems OS specific, for I don't have any of these issues on Windows and Linux. Any hint about how to do the linking statically on OSX would be greatly appreciated. Thanks, - Reto
RE: :info in ghci
It already does... but a bug meant it wasn't always reporting it. Now fixed in the head. SImon | -Original Message- | From: Hal Daume III [mailto:[EMAIL PROTECTED]] | Sent: 02 December 2002 16:50 | To: GHC Users Mailing List | Subject: :info in ghci | | Any chance :info could also report fixity information, especially for | symbolic identifiers? | | -- | Hal Daume III | | "Computer science is no more about computers| [EMAIL PROTECTED] | than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume | | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
:info in ghci
Any chance :info could also report fixity information, especially for symbolic identifiers? -- Hal Daume III "Computer science is no more about computers| [EMAIL PROTECTED] than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Java back end
I was wondering, what happened to the Java back end that was going to produce bytecode - how's it going? Is it now at all available? I'm having some difficulty finding it, and it sounded interesting. -- Mark ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Native Threads in the RTS
Simon Marlow wrote: > > | 2. Calling from foreign code into Haskell to a bound foreign import > > will > > | require some special handling to ensure that a subsequent > > call out to > > | foreign code will use the same native thread. Why couldn't this > > special > > | handling select the same Haskell thread instead of creating > > a new one? > > > > This is just an efficiency issue, right? If creating a > > Haskell thread > > from scratch is very cheap, then it's easier to do that each > > time rather > > than to try to find the carcass of a completed Haskell > > thread. If you > > do the latter, you need to get into carcass management. > > > > But maybe there is more to it than efficiency in your mind? > > To recap, the suggestion was that a Haskell thread which makes a foreign > call, which is turn calls back into Haskell, should use the same Haskell > thread for the callback. So the Haskell thread is not a carcass, it is > still running, but blocked waiting for the result of the foreign call. Yes, exactly. > I'm not sure I've quite got my head around all the implications of doing > this, but it sounds possible. However, I'm not completely convinced > it's desirable: the gain seems to be in efficiency only, and a fairly > small one (creating threads is quite cheap). I imagine you could > demonstrate a performance gain by doing this for an application which > does a lot of callbacks, though. My concern is not for efficiency. (In fact, I assumed the efficiency to be better with the current scheme because it was preferred to the (to me) more natural scheme. In any case, it appears any difference in efficiency--either way--is likely not to be large.) Rather, I find it nonintuitive that calling from Haskell to foreign code and back into Haskell should create a new Haskell thread, when these two Haskell threads really are just different portions of a single "thread of computation" (deliberately vague term). Off the top of my head I can think of two situations in which having separate threads is bothersome. 1. Consider a computation that requires Haskell-side per-thread state and associates it with a thread via the thread's ThreadId. Then some handle to this state currently needs to be passed out to foreign code and then back into Haskell. (This passage could be achieved explicitly as arguments in the call-out and callback, or implicitly in the closure representing the callback.) It is unfortunate that mere inclusion of a foreign call in such a chain of calls necessitates such additional complexity in per-thread state maintenance. 2. It seems perfectly reasonable to want to have the Haskell called-back code throw an exception that is caught by the Haskell code that called out to foreign code. "Reusing" the Haskell thread is necessary (though not sufficient) to achieve such behavior. > The current situation has the advantage of simplicity: > > * for each 'foreign export' we create a single Haskell thread which > lives until completion of the IO action. We can consider a > standalone > program as a call to 'foreign export main :: IO a' from a simple C > wrapper (in fact, that's almost exactly how it works). Dean ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Native Threads in the RTS
> | 2. Calling from foreign code into Haskell to a bound foreign import > will > | require some special handling to ensure that a subsequent > call out to > | foreign code will use the same native thread. Why couldn't this > special > | handling select the same Haskell thread instead of creating > a new one? > > This is just an efficiency issue, right? If creating a > Haskell thread > from scratch is very cheap, then it's easier to do that each > time rather > than to try to find the carcass of a completed Haskell > thread. If you > do the latter, you need to get into carcass management. > > But maybe there is more to it than efficiency in your mind? To recap, the suggestion was that a Haskell thread which makes a foreign call, which is turn calls back into Haskell, should use the same Haskell thread for the callback. So the Haskell thread is not a carcass, it is still running, but blocked waiting for the result of the foreign call. I'm not sure I've quite got my head around all the implications of doing this, but it sounds possible. However, I'm not completely convinced it's desirable: the gain seems to be in efficiency only, and a fairly small one (creating threads is quite cheap). I imagine you could demonstrate a performance gain by doing this for an application which does a lot of callbacks, though. The current situation has the advantage of simplicity: * for each 'foreign export' we create a single Haskell thread which lives until completion of the IO action. We can consider a standalone program as a call to 'foreign export main :: IO a' from a simple C wrapper (in fact, that's almost exactly how it works). Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: help for "Killed"
Dean Herington <[EMAIL PROTECTED]> writes: > I have a program that dies, saying simply "Killed". How can I tell what > that means? It means that the operating system (Linux probably?) has terminated your program. One thing to check is your ulimit settings, which can place a bound on the amount of resources (time, memory, etc) a process may use. e.g. $ ulimit -a core file size (blocks) 0 data seg size (kbytes) unlimited file size (blocks) unlimited max locked memory (kbytes) unlimited max memory size (kbytes)unlimited open files 1024 pipe size (512 bytes) 8 stack size (kbytes) 8192 cpu time (seconds) unlimited max user processes 2048 virtual memory (kbytes) unlimited Another possibility is that your program extends the heap until the entire virtual memory on your machine is exhausted, which also leads the OS to kill it. Check whether this is the case by monitoring memory usage using 'top' or 'gtop' or something. Regards, Malcolm ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Native Threads in the RTS
| 2. Calling from foreign code into Haskell to a bound foreign import will | require some special handling to ensure that a subsequent call out to | foreign code will use the same native thread. Why couldn't this special | handling select the same Haskell thread instead of creating a new one? This is just an efficiency issue, right? If creating a Haskell thread from scratch is very cheap, then it's easier to do that each time rather than to try to find the carcass of a completed Haskell thread. If you do the latter, you need to get into carcass management. But maybe there is more to it than efficiency in your mind? Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
