[Haskell-cafe] Semantics of ForeignPtr Finalizers
Hello,
I have a question about the semantics of finalizers of ForeignPtrs:
If an in scope value has a reference to a ForeignPtr is the foreign
object always kept alive, even if that reference is not used? Or do I
always need to wrap each computation, which needs to have the foreign
object alive, inside withForeignPtr?
To make my question more concrete, I will give a simplified example
from my usb library (a high-level binding to the libusb C library):
https://github.com/basvandijk/usb
To use the library you first need to initialize libusb which will
yield a context:
newtype Ctx = Ctx {getCtxFrgnPtr ∷ (ForeignPtr C'libusb_context)}
When you're finished with libusb you need to exit the library. This is
done automatically using a ForeignPtr:
newCtx ∷ IO Ctx
newCtx = mask_ $ do
ctxPtr ← libusb_init
Ctx $ newForeignPtr p'libusb_exit ctxPtr
where
libusb_init ∷ IO (Ptr C'libusb_context)
libusb_init = alloca $ \ctxPtrPtr → do
handleUSBException $ c'libusb_init ctxPtrPtr
peek ctxPtrPtr
I provide a handy internal utility function for accessing the pointer
to the context:
withCtxPtr ∷ Ctx → (Ptr C'libusb_context → IO α) → IO α
withCtxPtr = withForeignPtr ∘ getCtxFrgnPtr
Because this function uses withForeignPtr it's guaranteed that the
context is kep alive during the duration of the given function. For
example, in the following, it is guaranteed that c'libusb_set_debug is
always given a live context:
setDebug ∷ Ctx → Verbosity → IO ()
setDebug ctx verbosity = withCtxPtr ctx $ \ctxPtr →
c'libusb_set_debug ctxPtr $ genFromEnum verbosity
There are also types which are derived from a context. For example:
getDevices ∷ Ctx → IO [Device] is a function which given a context
returns a list of USB devices currently attached to your system.
The requirement is that when you need to use a device the context has
to be kept alive. Therefor I keep a reference to the context inside
the device:
data Device = Device
{ getCtx ∷ !Ctx
, getDevFrgnPtr ∷ !(ForeignPtr C'libusb_device)
, deviceDesc ∷ !DeviceDesc
}
The idea is that as long as you have a reference to a device you also
keep the context alive because the device references the context.
(Note that a device, in turn, also contains a ForeignPtr)
getDevices ∷ Ctx → IO [Device]
getDevices ctx = ...
where
mkDev ∷ Ptr C'libusb_device → IO Device
mkDev devPtr = liftA2
(Device ctx)
(newForeignPtr p'libusb_unref_device devPtr)
(getDeviceDesc devPtr)
Again I provide a handy internal utility function for accessing the
pointer to a device:
withDevicePtr ∷ Device → (Ptr C'libusb_device → IO α) → IO α
withDevicePtr = withForeignPtr ∘ getDevFrgnPtr
And now my question. Is it guaranteed that when the device is in scope
the context is always kept alive? For example, is the context kept
alive in the following:
openDevice ∷ Device → IO DeviceHandle
openDevice dev = withDevicePtr dev $ \devPtr →
alloca $ \devHndlPtrPtr → do
handleUSBException $ c'libusb_open devPtr devHndlPtrPtr
DeviceHandle dev $ peek devHndlPtrPtr
Or do I also need to call withCtxPtr inside withDevicePtr as such:
withDevicePtr (Device ctx devFP _) f = withCtxPtr ctx $ \_ →
withForeignPtr devFP f
Thanks,
Bas
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best Linux Distro for =
Hi, Am Sonntag, den 19.06.2011, 15:33 +1000 schrieb Mark Wright: Fedora, Debian, FreeBSD: I don't use them, however I think they have very good support for Haskell packaging. For example, Fedora updates the haddock documentation index as pkgs are installed and removed same on Debian, file:///usr/share/doc/ghc-doc/html/libraries/index.html is one of the most-visited locations in my computer :-) For Debian, you can check where we deviate from the Haskell Platform on http://people.debian.org/~nomeata/platform.html and http://people.debian.org/~nomeata/hackagevsdebian.html gives you an idea of our coverage of Hackage. And, something that we are proud of: The dependencies between the Haskell library packages include the ABI hash, so an apt-get upgrade will never break installed Haskell libraries, but only upgrade if all depending packages have been rebuilt. Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best Linux Distro for =
On 19 June 2011 20:26, Joachim Breitner nome...@debian.org wrote: Hi, Am Sonntag, den 19.06.2011, 15:33 +1000 schrieb Mark Wright: Fedora, Debian, FreeBSD: I don't use them, however I think they have very good support for Haskell packaging. For example, Fedora updates the haddock documentation index as pkgs are installed and removed same on Debian, file:///usr/share/doc/ghc-doc/html/libraries/index.html is one of the most-visited locations in my computer :-) For Debian, you can check where we deviate from the Haskell Platform on http://people.debian.org/~nomeata/platform.html and http://people.debian.org/~nomeata/hackagevsdebian.html gives you an idea of our coverage of Hackage. And, something that we are proud of: The dependencies between the Haskell library packages include the ABI hash, so an apt-get upgrade will never break installed Haskell libraries, but only upgrade if all depending packages have been rebuilt. Are these binary or source packages that you use the ABI hash? Also, how do you manage to update the documentation index on package installation/removal? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best Linux Distro for =
Hi, Am Sonntag, den 19.06.2011, 20:31 +1000 schrieb Ivan Lazar Miljenovic: same on Debian, file:///usr/share/doc/ghc-doc/html/libraries/index.html is one of the most-visited locations in my computer :-) For Debian, you can check where we deviate from the Haskell Platform on http://people.debian.org/~nomeata/platform.html and http://people.debian.org/~nomeata/hackagevsdebian.html gives you an idea of our coverage of Hackage. And, something that we are proud of: The dependencies between the Haskell library packages include the ABI hash, so an apt-get upgrade will never break installed Haskell libraries, but only upgrade if all depending packages have been rebuilt. Are these binary or source packages that you use the ABI hash? The binary packages. Here is an example for how we make sure that an ABI incompatible change to web-routes requires a rebuild of yesod, and that until that happens the user will not get the new web-routes package installed. $ apt-cache show libghc-yesod-dev|grep Depends Depends: libghc-base-dev-4.3.1.0-91c38, libghc-base64-bytestring-dev-0.1.0.2-2bc90, libghc-blaze-builder-dev-0.2.1.4-eb4c4, libghc-bytestring-dev-0.9.1.10-6aa1e, libghc-cereal-dev-0.3.3.0-7fd4a, libghc-clientsession-dev-0.4.1-493f6, libghc-containers-dev-0.4.0.0-b4885, libghc-data-default-dev-0.2.0.1-9411c, libghc-directory-dev-1.1.0.0-393d8, libghc-email-validate-dev-0.2.6-c13c2, libghc-failure-dev-0.1.0.1-1e2c3, libghc-hamlet-dev-0.6.1.2-ec8f2, libghc-neither-dev-0.1.0-0adb6, libghc-network-dev-2.3.0.2-824dd, libghc-old-locale-dev-1.0.0.2-161f7, libghc-parsec-dev-3.1.1-33474, libghc-persistent-dev-0.3.1.3-d494b, libghc-puremd5-dev-2.1.0.3-754be, libghc-random-dev-1.0.0.3-7511f, libghc-template-haskell-dev-2.5.0.0-95716, libghc-text-dev-0.11.0.6-139d7, libghc-time-dev-1.2.0.3-34932, libghc-transformers-dev-0.2.2.0-4bbbf, libghc-wai-dev-0.2.2.1-53001, libghc-wai-extra-dev-0.2.4.2-4646d, libghc-web-routes-dev-0.23.4-ab46a, libghc-web-routes-quasi-dev-0.6.3.1-5c04c, libghc-xss-sanitize-dev-0.2.6-b2c10, libc6 (= 2.7), libffi5 (= 3.0.4), libgmp10, zlib1g (= 1:1.1.4) $ apt-cache show libghc-web-routes-dev|grep Provides Provides: libghc-web-routes-dev-0.23.4-ab46a Also, how do you manage to update the documentation index on package installation/removal? The ghc-doc package installs a dpkg trigger that watches certain directories (the directories where library install their package descriptions and .haddock files). If such a change happens, /usr/lib/ghc-doc/gen_contents_index is run, which can be seen here: http://anonscm.debian.org/darcs/pkg-haskell/ghc/gen_contents_index.in Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best Linux Distro for =
On 19 June 2011 20:51, Joachim Breitner nome...@debian.org wrote: The binary packages. Here is an example for how we make sure that an ABI incompatible change to web-routes requires a rebuild of yesod, and that until that happens the user will not get the new web-routes package installed. $ apt-cache show libghc-yesod-dev|grep Depends Depends: libghc-base-dev-4.3.1.0-91c38, libghc-base64-bytestring-dev-0.1.0.2-2bc90, libghc-blaze-builder-dev-0.2.1.4-eb4c4, libghc-bytestring-dev-0.9.1.10-6aa1e, libghc-cereal-dev-0.3.3.0-7fd4a, libghc-clientsession-dev-0.4.1-493f6, libghc-containers-dev-0.4.0.0-b4885, libghc-data-default-dev-0.2.0.1-9411c, libghc-directory-dev-1.1.0.0-393d8, libghc-email-validate-dev-0.2.6-c13c2, libghc-failure-dev-0.1.0.1-1e2c3, libghc-hamlet-dev-0.6.1.2-ec8f2, libghc-neither-dev-0.1.0-0adb6, libghc-network-dev-2.3.0.2-824dd, libghc-old-locale-dev-1.0.0.2-161f7, libghc-parsec-dev-3.1.1-33474, libghc-persistent-dev-0.3.1.3-d494b, libghc-puremd5-dev-2.1.0.3-754be, libghc-random-dev-1.0.0.3-7511f, libghc-template-haskell-dev-2.5.0.0-95716, libghc-text-dev-0.11.0.6-139d7, libghc-time-dev-1.2.0.3-34932, libghc-transformers-dev-0.2.2.0-4bbbf, libghc-wai-dev-0.2.2.1-53001, libghc-wai-extra-dev-0.2.4.2-4646d, libghc-web-routes-dev-0.23.4-ab46a, libghc-web-routes-quasi-dev-0.6.3.1-5c04c, libghc-xss-sanitize-dev-0.2.6-b2c10, libc6 (= 2.7), libffi5 (= 3.0.4), libgmp10, zlib1g (= 1:1.1.4) $ apt-cache show libghc-web-routes-dev|grep Provides Provides: libghc-web-routes-dev-0.23.4-ab46a So the Debian Haskell team then has to update the apt package when there's an ABI mismatch (that is, a dependency has been updated or rebuilt with a new ABI)? Or is this done automagically somehow for the user? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best Linux Distro for =
Hi, Am Sonntag, den 19.06.2011, 20:59 +1000 schrieb Ivan Lazar Miljenovic: So the Debian Haskell team then has to update the apt package when there's an ABI mismatch (that is, a dependency has been updated or rebuilt with a new ABI)? Or is this done automagically somehow for the user? we have to semi-manually start a binNMU (Debian slang for: Leave the source untouched, but rebuild the binary package). We have a script that detects which packages need to be rebuilt, which I run occasionally or when I have reasons to assume that it is needed (usually, you know that you broke some depending packages). The user can then not upgrade or install the broken packages for a day or two. We never build something on the users machine. After all, we are not Gentoo ;-). Well, besides the documentation index :-) Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell *interpreter* on iPad? (Scheme and Ocaml are there)
On 18 Jun 2011, at 20:19, Jack Henahan wrote: but the dev would either be forced into Hugs, or they'd have to implement a more portable GHC. Does such a thing exist already? Just as a point of interest, the original nhc compiler was original written for an ARM architecture machine (Acorn Archimedes) with 2Mb of memory. Its successor, nhc98, can be bootstrapped from C sources, and always aimed to be as portable as possible. The project is largely unmaintained now, so there is likely to be some bitrot, but it would probably work OK with some effort. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Class instances in haddock documentation missing
Hi, the haddock information generated on hackage lists class instances per class and per data type e.g. on http://hackage.haskell.org/packages/archive/base/4.3.1.0/doc/html/Data-Eq.html or http://hackage.haskell.org/packages/archive/xhtml/3000.2.0.1/doc/html/Text-XHtml-Transitional.html For some reason, the documentation generated on Debian does not. Does anybody have an idea why that could be? We use ./Setup haddock --hyperlink-source to build the documentation, using the haddock that is shipped with ghc (2.9.2 at the moment). Greetings, Joachim -- Joachim nomeata Breitner Debian Developer nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Semantics of ForeignPtr Finalizers
On 6/19/11 3:52 AM, Bas van Dijk wrote: Hello, I have a question about the semantics of finalizers of ForeignPtrs: If an in scope value has a reference to a ForeignPtr is the foreign object always kept alive, even if that reference is not used? Or do I always need to wrap each computation, which needs to have the foreign object alive, inside withForeignPtr? I know that the Ptr obtained by withForeignPtr will _not_ keep the foreign object alive (though withForeignPtr itself will be sure to keep it alive until the function using the Ptr exits). For instance, this shows up with ByteStrings if you try to save the Ptr somewhere and then use it after withForeignPtr exits. I believe that ForeignPtr itself does promise to keep the foreign object alive, since it's what holds the finalizers. The documentation claims that the finalizers are run only once the ForeignPtr becomes unreachable, which implies that keeping the ForeignPtr is sufficient to keep the foreign object alive. I haven't used ForeignPtr for truly foreign objects, only for pseudo-foreign objects like ByteString, but in my experience just having the ForeignPtr is enough to keep the target alive. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Semantics of ForeignPtr Finalizers
On 19 June 2011 14:13, wren ng thornton w...@freegeek.org wrote: The documentation claims that the finalizers are run only once the ForeignPtr becomes unreachable, which implies that keeping the ForeignPtr is sufficient to keep the foreign object alive. Right, that was also my thinking when designing the usb library. What made me doubt this was the implementation of storable vectors: http://hackage.haskell.org/packages/archive/vector/0.7.1/doc/html/src/Data-Vector-Storable.html Note that a storable vector stores both a foreign pointer and a pointer (presumably so that you don't need to add an offset to the pointer, inside the foreign pointer, each time you use it): data Vector a = Vector !(Ptr a) !Int !(ForeignPtr a) Now, if we follow the above semantics we don't need to call withForeignPtr when we need to read the memory because the foreign pointer is referenced by the vector. However the vector library still calls withForeignPtr. For example: basicUnsafeIndexM (Vector p _ fp) i = return . unsafeInlineIO $ withForeignPtr fp $ \_ - peekElemOff p i So is the withForeignPtr redundant so that this function can be rewritten to just: basicUnsafeIndexM (Vector p _ _) i = return . unsafeInlineIO peekElemOff p i Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best Linux Distro for =
On Sun, Jun 19, 2011 at 12:59 AM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 19 June 2011 13:48, Tom Murphy amin...@gmail.com wrote: Hi List, If my choice of Lunix distro depended 100% on its solidness as a Haskell devel platform (I am), what would you all recommend? In no particular order, the following seem to have good Linux support: Gentoo, Arch, Fedora and Debian (I think Testing). It seems that NixOS also has nice support, although I haven't used it myself yet. Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Probably type checker error.
Right now I write a quite heavy transformation of Haskell source code and found some strange behaviour of typechecker. Some prerequisites: -- dummy class. My own class is much bigger, but I -- could reproduce that behaviour with that class. class ToWires a -- a type with phantom type arguments. data E ins outs = E -- a function that relates E and its inputs. projectInsType :: E ins outs - ins projectInsType = error projectInsType gets evaluated. -- register function. register :: a - a - a register def a = def -- a simple addition. add2 :: (ToWires a, Num a) = (a,a) - a add2 (a,b) = a+b First I have a function: func :: (ToWires a, Num a) = Maybe a - a func mbA = currentSum where x = case mbA of Just a - a Nothing - 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum It typechecks and works just fine after some transformation. The transformation I work on transform code into something like that: func_E :: (ToWires a, Num a) = E (Maybe a) a func_E = r where r = E -- here we relate mbA and r. mbA = projectInsType r x = case mbA of Just a - a Nothing - 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum Note the absence of input of func in transformed func_E. I relate mbA with it's proper type using binding mbA = projectInsType r. Then suddently ghc loses all of the context associated with mbA. And find type error at the calling of add2. If I drop ToWires from contexts of func_E and add2 types, all works fine. If I change add2 to simple addition (x + currentSum), all works fine. Full source code is in attachment. I found it using ghc 6.12.1. I asked colleagues, they told me that the same error manifests itself in ghc 7.0.3. Should I fill a bug report or maybe I misunderstood something? a.hs Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best Linux Distro for =
On 6/19/11, Arlen Cuss cel...@sairyx.org wrote: In no particular order, the following seem to have good Linux support: Gentoo, Arch, Fedora and Debian (I think Testing). Please allow me to register my amusement at the idea of a distribution with good Linux support. :D I was very surprised when I realized that this is sort of true. I had assumed that most coders are using Linux/BSD, and so the best (most recent, most stable) version of the Haskell Platform would be the (a) Linux one. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Semantics of ForeignPtr Finalizers
On Jun 19, 2011 9:58 AM, Antoine Latter aslat...@gmail.com wrote: I'd be afraid of optimizations getting ride of the constructor, and since I'm not using all of the fields I would no longer have a reference to the foreign ptr. Since withForeignPtr touches the foreign pointer the optimizations won't make it go away no matter how it transfoms the function. Good point. I already made the necessary fixes to my usb library in the ForeignPtrFix branch: https://github.com/basvandijk/usb/tree/ForeignPtrFix I think I'll merge it with master. Thanks, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Probably type checker error.
Cool. It works. Thank you very much! 2011/6/19 Miguel Mitrofanov miguelim...@yandex.ru: Seems like let-generalization is at work here. Types of all values in the where section are inferred basically as if they are declared at the top level. Therefore, inheritance fails without NoMonomorphismRestriction. There is a proposal (from Big Simon) to remove let-generalization: http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let-gen.pdf On 19 Jun 2011, at 18:26, Serguey Zefirov wrote: Right now I write a quite heavy transformation of Haskell source code and found some strange behaviour of typechecker. Some prerequisites: -- dummy class. My own class is much bigger, but I -- could reproduce that behaviour with that class. class ToWires a -- a type with phantom type arguments. data E ins outs = E -- a function that relates E and its inputs. projectInsType :: E ins outs - ins projectInsType = error projectInsType gets evaluated. -- register function. register :: a - a - a register def a = def -- a simple addition. add2 :: (ToWires a, Num a) = (a,a) - a add2 (a,b) = a+b First I have a function: func :: (ToWires a, Num a) = Maybe a - a func mbA = currentSum where x = case mbA of Just a - a Nothing - 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum It typechecks and works just fine after some transformation. The transformation I work on transform code into something like that: func_E :: (ToWires a, Num a) = E (Maybe a) a func_E = r where r = E -- here we relate mbA and r. mbA = projectInsType r x = case mbA of Just a - a Nothing - 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum Note the absence of input of func in transformed func_E. I relate mbA with it's proper type using binding mbA = projectInsType r. Then suddently ghc loses all of the context associated with mbA. And find type error at the calling of add2. If I drop ToWires from contexts of func_E and add2 types, all works fine. If I change add2 to simple addition (x + currentSum), all works fine. Full source code is in attachment. I found it using ghc 6.12.1. I asked colleagues, they told me that the same error manifests itself in ghc 7.0.3. Should I fill a bug report or maybe I misunderstood something? a.hs___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell *interpreter* on iPad? (Scheme and Ocaml are there)
On 6/18/11, Alexander Solla alex.so...@gmail.com wrote: Since the iPhone OS is pretty much OS X for ARM, and GHC apparently now supports cross-compilation, you can compile GHC for iOS. Can you provide a link for info? I don't understand how this would be done. Thanks Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Semantics of ForeignPtr Finalizers
Sending to the list as well. On Jun 19, 2011 9:58 AM, Antoine Latter aslat...@gmail.com wrote: On Jun 19, 2011 7:49 AM, Bas van Dijk v.dijk@gmail.com wrote: On 19 June 2011 14:13, wren ng thornton w...@freegeek.org wrote: The documentation claims that the finalizers are run only once the ForeignPtr becomes unreachable, which implies that keeping the ForeignPtr is sufficient to keep the foreign object alive. Right, that was also my thinking when designing the usb library. What made me doubt this was the implementation of storable vectors: http://hackage.haskell.org/packages/archive/vector/0.7.1/doc/html/src/Data-Vector-Storable.html Note that a storable vector stores both a foreign pointer and a pointer (presumably so that you don't need to add an offset to the pointer, inside the foreign pointer, each time you use it): data Vector a = Vector !(Ptr a) !Int !(ForeignPtr a) Now, if we follow the above semantics we don't need to call withForeignPtr when we need to read the memory because the foreign pointer is referenced by the vector. However the vector library still calls withForeignPtr. For example: basicUnsafeIndexM (Vector p _ fp) i = return . unsafeInlineIO $ withForeignPtr fp $ \_ - peekElemOff p i So is the withForeignPtr redundant so that this function can be rewritten to just: basicUnsafeIndexM (Vector p _ _) i = return . unsafeInlineIO peekElemOff p i I'd be afraid of optimizations getting ride of the constructor, and since I'm not using all of the fields I would no longer have a reference to the foreign ptr. Since withForeignPtr touches the foreign pointer the optimizations won't make it go away no matter how it transfoms the function. Antoine Regards, Bas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell *interpreter* on iPad? (Scheme and Ocaml are there)
Well, strictly speaking, GHC only supports self-cross-compilation, id est porting[1], cf. [2]. For more information on cross compilation generally, refer to the wiki page[3]. Does that answer your question, or did you have something else in mind? [1]:http://hackage.haskell.org/trac/ghc/wiki/Building/Porting [2]:http://hackage.haskell.org/trac/ghc/wiki/CrossCompilation [3]:http://en.wikipedia.org/wiki/Cross_compiler On Jun 19, 2011, at 11:44 AM, Tom Murphy wrote: On 6/18/11, Alexander Solla alex.so...@gmail.com wrote: Since the iPhone OS is pretty much OS X for ARM, and GHC apparently now supports cross-compilation, you can compile GHC for iOS. Can you provide a link for info? I don't understand how this would be done. Thanks Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Probably type checker error.
Seems like let-generalization is at work here. Types of all values in the where section are inferred basically as if they are declared at the top level. Therefore, inheritance fails without NoMonomorphismRestriction. There is a proposal (from Big Simon) to remove let-generalization: http://research.microsoft.com/en-us/um/people/simonpj/papers/constraints/let-gen.pdf On 19 Jun 2011, at 18:26, Serguey Zefirov wrote: Right now I write a quite heavy transformation of Haskell source code and found some strange behaviour of typechecker. Some prerequisites: -- dummy class. My own class is much bigger, but I -- could reproduce that behaviour with that class. class ToWires a -- a type with phantom type arguments. data E ins outs = E -- a function that relates E and its inputs. projectInsType :: E ins outs - ins projectInsType = error projectInsType gets evaluated. -- register function. register :: a - a - a register def a = def -- a simple addition. add2 :: (ToWires a, Num a) = (a,a) - a add2 (a,b) = a+b First I have a function: func :: (ToWires a, Num a) = Maybe a - a func mbA = currentSum where x = case mbA of Just a - a Nothing - 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum It typechecks and works just fine after some transformation. The transformation I work on transform code into something like that: func_E :: (ToWires a, Num a) = E (Maybe a) a func_E = r where r = E -- here we relate mbA and r. mbA = projectInsType r x = case mbA of Just a - a Nothing - 0 nextSum = add2 (x,currentSum) currentSum = register 0 nextSum Note the absence of input of func in transformed func_E. I relate mbA with it's proper type using binding mbA = projectInsType r. Then suddently ghc loses all of the context associated with mbA. And find type error at the calling of add2. If I drop ToWires from contexts of func_E and add2 types, all works fine. If I change add2 to simple addition (x + currentSum), all works fine. Full source code is in attachment. I found it using ghc 6.12.1. I asked colleagues, they told me that the same error manifests itself in ghc 7.0.3. Should I fill a bug report or maybe I misunderstood something? a.hs___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell *interpreter* on iPad? (Scheme and Ocaml are there)
On Sun, Jun 19, 2011 at 8:44 AM, Tom Murphy amin...@gmail.com wrote: On 6/18/11, Alexander Solla alex.so...@gmail.com wrote: Since the iPhone OS is pretty much OS X for ARM, and GHC apparently now supports cross-compilation, you can compile GHC for iOS. Can you provide a link for info? I don't understand how this would be done. This was news to me too. I haven't read anything relevant in the GHC manual (but then, I haven't looked for quite a while). I said apparently, because of the contents of this link: http://www.haskell.org/haskellwiki/IPhone#GHC_as_a_cross_compiler ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
