Staying alive
In a recent discussion with Manuel Chakravarty the following question arose. Given the following code: foo = do ba - newMutableByteArray ... ... bar ba -- ba not used here anymore foreign import ... bar :: MutableByteArray ... - IO () Let's further assume that bar makes callbacks to Haskell-land where a GC occurs. Now the subtle question: Is it *guaranteed* that ba is considered alive until bar returns or not? Either way, this should be clarified in the FFI documentation. Background: A lot of APIs (e.g. GTK+ and OpenGL :-) have functions expecting a pointer to some data. One possible way to use them from Haskell is * malloc area * fill area with data * call API function with pointer to area * explicitly free malloced area Using (Mutable)ByteArrays would simplify thing here, especially the last step would not be needed. Cheers, Sven -- Sven PanneTel.: +49/89/2178-2235 LMU, Institut fuer Informatik FAX : +49/89/2178-2211 LFE Programmier- und Modellierungssprachen Oettingenstr. 67 mailto:[EMAIL PROTECTED]D-80538 Muenchen http://www.informatik.uni-muenchen.de/~Sven.Panne
RE: GHC 4.04 patchlevel 1 released
- gcc 2.95 compatibility What's that specifically? I ask, because I'm using OpenBSD, and am usually bootstrapping new versions with an old 3.02 installation, because of the occasional problems with compiling ghc with a *slightly* older ghc (when some functions change at a time when the version number does NOT change, so the version feature checks are inaccurate -- which has bitten me more than once). So, I should look if I can backport the ghc 2.95 compatibility easily, or if I have to change my procedure somewhat, as OpenBSD-current has changed from 2.81 (which works fine with ghc on i386) to 2.95.1. 3.02 should work fine with gcc 2.95 on i386. The only affected released version of GHC is 4.04pl0. Sparc support will need backporting: take a look at the changes to ghc/driver/ghc-asm.lprl between 4.04pl0 and 4.04pl1. The issue on i386 was a fragment of inline assembler that had incorrect constraints, causing gcc 2.95 to mis-optimised around it. Cheers, Simon
RE: Patches for GHC 4.04pl1?
The best thing to do is use the anoncvs repository, and just 'cvs update' to get the latest patches. If you're running over a phone line then it might help to make ssh do some compression. Yes, but this requires at least one complete checkout. Of course, after this is done, cvs update will only load the diffs to newer versions. And: isn't there a risk to update the local sources to a `unstable' revision? Or do you use symbolic tags for official releases, such as `ghc4.04pl1'? I'll use cvs to get the latest ghc, but nevertheless I suggest to publish patch files for future releases of ghc. This shouldn't be too difficult: cvs co -r lastRel -d ghc.old ghc cvs co -D now ghc cd ghc diff -rNu ../ghc.old . ../ghc.diffs cvs tag -F lastRel cd .. cvs -q rel -d ghc.old cvs -q rel -d ghc Bye, Kili -- de: Signaturen erzeugen Krebs. en: Signatures cause cancer. Please send other translations.
Re: GHC 4.04 patchlevel 1 released
Hello! On Wed, Sep 15, 1999 at 05:48:30AM -0700, Simon Marlow wrote: [...] - gcc 2.95 compatibility What's that specifically? I ask, because I'm using OpenBSD, and am usually bootstrapping new versions with an old 3.02 installation, because of the occasional problems with compiling ghc with a *slightly* older ghc (when some functions change at a time when the version number does NOT change, so the version feature checks are inaccurate -- which has bitten me more than once). So, I should look if I can backport the ghc 2.95 compatibility easily, or if I have to change my procedure somewhat, as OpenBSD-current has changed from 2.81 (which works fine with ghc on i386) to 2.95.1. [...] Regards, Hannah.
Re: Bug Tracking Systems?
Hello! On Tue, Sep 14, 1999 at 03:55:39AM -0700, Simon Marlow wrote: [...] - BugZilla (the Mozilla bug tracker). Web/CGI based, uses an SQL database. Does just about everything under the sun, probably a bit heavyweight for us. Does anyone have any experience with any of these, or thoughts in general? Yes. Please no bug trackers that are *only* accessible via the WWW. WWW via EMail is very cumbersome, and there are still UUCP and other offline users. I'm leaning towards Debian at the moment, since it seems about the right level of complexity for the number of bugs we expect to maintain on it (i.e. not many :-). Seems good. Gnats is uncomfortable to set up and keep running, as I've experienced with a small play installation thereof. Regards, Hannah.
