Re: [Haskell-cafe] Strange context reduction with partial application and casting
At Sat, 2 Jul 2011 17:23:50 -0400,
Brent Yorgey wrote:
On Sat, Jul 02, 2011 at 09:02:13PM +0200, Daniel Fischer wrote:
- disabling the monomorphism restriction
:set -XNoMonomorphismRestriction
let g = f
This is the recommended solution. The confusion caused by the MR far
outweighs its occasional benefits.
Recommended by some people, but by no means everyone.
For instance, Vytiniotis, Peyton Jones, and Schrijvers make a good
argument that the monomorphism restriction should effectively be
expanded to include both pattern and function bindings in let and
where clauses:
http://research.microsoft.com/pubs/102483/tldi10-vytiniotis.pdf
The above paper is currently implemented in GHC, and on by default if
you enable GADTs. (So you would additionally need
-XNoMonoLocalBindings if you wanted to use GADTs.) Moreover, even
with -XNoMonoLocalBindings, you still run into the fact that bindings
are not generalized within a declaration group, which could lead to
confusion. In particular, consider the following program:
{-# LANGUAGE NoMonomorphismRestriction #-}
x = 2 -- The type of x is: Num a = a
y = (x + y) :: Int
The type of x is what you would expect without the monomorphism
restriction. Now say x has a gratuitous use of y:
{-# LANGUAGE NoMonomorphismRestriction #-}
x = 2 where _ = y -- The type of x is: Int
y = (x + y) :: Int
If you want x to be polymorphic in this case, you have to give it a
type signature anyway:
{-# LANGUAGE NoMonomorphismRestriction #-}
x :: Num a = a
x = 2 where _ = y
y = (x + y) :: Int
Thus, what I would recommend, instead of -XNoMonoLocalBindings, is to
give type signatures to your polymorphic bindings. This makes the
code more readable. It has the disadvantage that Haskell doesn't
allow you to name monomorphic type variables, which, for local
bindings, can require either the use of -XScopedTypeVariables or
giving extra function arguments whose only purpose is to bring a type
variable into scope. But both of those are probably more future-proof
than -XNoMonomorphismRestriction.
David
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange context reduction with partial application and casting
On Sunday 03 July 2011, 09:19:11, dm-list-haskell-c...@scs.stanford.edu
wrote:
At Sat, 2 Jul 2011 17:23:50 -0400,
Brent Yorgey wrote:
On Sat, Jul 02, 2011 at 09:02:13PM +0200, Daniel Fischer wrote:
- disabling the monomorphism restriction
:set -XNoMonomorphismRestriction
let g = f
This is the recommended solution. The confusion caused by the MR far
outweighs its occasional benefits.
Recommended by some people, but by no means everyone.
For instance, Vytiniotis, Peyton Jones, and Schrijvers make a good
argument that the monomorphism restriction should effectively be
expanded to include both pattern and function bindings in let and
where clauses:
http://research.microsoft.com/pubs/102483/tldi10-vytiniotis.pdf
The above paper is currently implemented in GHC, and on by default if
you enable GADTs. (So you would additionally need
-XNoMonoLocalBindings if you wanted to use GADTs.) Moreover, even
It's [No]MonoLocalBinds, which is shorter - but apparently the participle
is more intuitive. [However, I'm not advocating a change]
with -XNoMonoLocalBindings, you still run into the fact that bindings
are not generalized within a declaration group, which could lead to
confusion. In particular, consider the following program:
{-# LANGUAGE NoMonomorphismRestriction #-}
x = 2 -- The type of x is: Num a = a
y = (x + y) :: Int
The type of x is what you would expect without the monomorphism
restriction. Now say x has a gratuitous use of y:
{-# LANGUAGE NoMonomorphismRestriction #-}
x = 2 where _ = y -- The type of x is: Int
y = (x + y) :: Int
If you want x to be polymorphic in this case, you have to give it a
type signature anyway:
{-# LANGUAGE NoMonomorphismRestriction #-}
x :: Num a = a
x = 2 where _ = y
y = (x + y) :: Int
Thus, what I would recommend, instead of -XNoMonoLocalBindings, is to
You meant NoMonomorphismRestriction here, I think.
give type signatures to your polymorphic bindings. This makes the
+1
code more readable. It has the disadvantage that Haskell doesn't
allow you to name monomorphic type variables, which, for local
bindings, can require either the use of -XScopedTypeVariables or
giving extra function arguments whose only purpose is to bring a type
variable into scope. But both of those are probably more future-proof
than -XNoMonomorphismRestriction.
But as I understand it, the concern is ghci, where truly local bindings are
probably rare and type signatures are commonly omitted.
So putting :s -XNoMonomorphismRestriction in the .ghci file probably
prevents more confusion and inconvenience than it causes.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
On 2 Jul 2011, at 22:13, Yitzchak Gale wrote: [1]http://hackage.haskell.org/package/timezone-series [2]http://hackage.haskell.org/package/timezone-olson I'd just like to add that these timezone packages are fantastic. They are extremely useful if you need accurate conversion between wall-clock times in different locations of the world, at arbitrary dates in the past or future, taking account of the differing moments at which daylight savings times take effect and so on. [At least one financial institution is now using them to avoid losing money that might otherwise happen due to confusion over the exact time of expiry of contracts.] Thanks Yitz. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] [Haskell-Cafe] Constructive Probability Theory and RandProc's σ-algebras
On Sun, Jul 3, 2011 at 11:05 AM, David Banas dba...@banasfamily.net wrote:
v0.4 of `RandProc` has just been posted to Hackage:
http://hackage.haskell.org/package/randproc
[NB: I transfered this discussion from haskell to haskell-cafe, and started
another thread]
I have been spending some time exploring constructive probability theory in
Haskell, and I have a couple of observations about working with random
processes in a constructive setting:
Necessarily because you are working in Haskell, a constructive setting,
your σ-algebras can't be actual σ-algebras! =/
Notably, they aren't closed under *countable* union/intersection/complement,
but merely finite union/intersection/complement, and Gray and Davisson's
horrified objections from the bottom of page 39 on Random Processes applies:
If a class of sets is only a field rather than a σ-field, that is, if it
satisfies only (3.1) and (3.2), then there is no guarantee that the class
will contain all limits of sets. Hence, for example knowing that a class of
sets contains all half-open intervals of the form (a,b] for a and b finite
does not ensure that it will also contain points or singleton sets! In fact,
it is straightforward to show that the collection of all such half-open
intervals together with the complements of such sets and all finite unions
of the intervals and complements forms a field. The singleton sets, however,
are not in the field. (See exercise 3.4)
Thus if we tried to construct a probability theory based on only a field,
we might have probabilites defined for events such as (a,b) meaning the
output voltage of a measurement is between a and b yet not have
probabilities defined for a singleton set {a} meaning the output voltage is
exactly a. By requiring that the event space be a σ-field instead of only a
field, we are assured that all such limits are indeed events.
This limitation, while from some perspective annoying is intrinsic to
tackling the problem intuitionistically. Practically, this means you need to
be careful when rederiving most of the later results, because you are
limited to what you can prove in a constructive measure theory.
In particular the approaches of YK Chan, Brian Weatherson, and Glenn Shafer
to intuitionistic probability theory are probably appropriate reading.
Personally, I don't think this is all that bad, we get some nice properties
by being in a constructive setting. Weatherson noted that your measure
becomes additive without problems from Dutch book arguments in an
intuitionistic setting, because P(A v not A) is not necessarily 1!
You may recall that recall that additivity would imply that P(A v B) = P(A)
+ P(B), given that A and B are disjoint, but that it tends to fall apart in
classical probability theory.
Intuitionistically, however, this is fine. That is to say that if you placed
bets that payed out with market rate interest at a rational booking agent on
both whether P = NP and P /= NP, it isn't just as good as having placed a
bet on truth, because intuitionistically it is possible that neither of
those bets may ever pay out, but in a classical setting P (P = NP v P /= NP)
= P(True) = 1, so we lose additivity to gain the excluded middle.
The cost of additivity is giving up or refining a lot of results from that
text that talk about the limit of a random process. That and that the
σ-fields in question are mere fields. ;)
I am interested in exploring the consequences of this further.
-Edward
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] video for linux two (v4l2) bindings
Greetings all, I uploaded 4 new packages that may be of interest: bindings-linux-videodev2 0.1 - bindings to Video For Linux Two (v4l2) kernel interfaces http://hackage.haskell.org/package/bindings-linux-videodev2-0.1 bindings-mmap 0.1 - bindings to mmap for POSIX http://hackage.haskell.org/package/bindings-mmap-0.1 bindings-libv4l2 0.1 - bindings to libv4l2 for Linux http://hackage.haskell.org/package/bindings-libv4l2-0.1 v4l2-examples 0.1 - video for linux two examples http://hackage.haskell.org/package/v4l2-examples-0.1 The first wraps the low-level structures and ioctls of the V4L2 API. The second wraps the raw mmap/munmap functions and constants (which I couldn't seem to find on hackage, only higher level wrappers which I couldn't use for various reasons). It would make more sense for this to be folded into bindings-posix at some point. The third wraps libv4l2, which provides an interface very similar to the use of V4L2 ioctls, but the library adds extra capabilities behind the scenes (I'm led to believe colour space conversion is one of them) which is hopefully useful. And the last is a crude example dumping frames from a video device (like a webcam) to stdout in YUV4MPEG2 format. The code is *very* low-level and imperative (almost a direct translation from the C example provided on the linuxtv API reference), there is plenty of room for a much nicer layer to (for example) get video data into RePa arrays or OpenGL textures. As these are raw bindings, documentation is best found upstream. Thanks to Maurício C. Antunes's package for making this possible, I recommend it: http://hackage.haskell.org/package/bindings-DSL Claude -- http://claudiusmaximus.goto10.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: regex-applicative-0.1
I am glad to announce the initial release of regex-applicative. Hackage: http://hackage.haskell.org/package/regex-applicative Repository: https://github.com/feuerbach/regex-applicative Issues: https://github.com/feuerbach/regex-applicative/issues regex-applicative is aimed to be an efficient and easy to use parsing combinator library based on regular expressions. Perl programmers often use regular expressions for parsing, even if it is not an appropriate tool for the job, because Perl has so good support for regexps. The opposite seems to be valid about Haskell programmers -- they use parsing combinators (which recognize context-free or even context-sensitive grammars), even when the language is actually regular! Hopefully, this library will improve the situation. This is an early preview release. Some features are lacking, and performance is probably not very good yet. Among the features that we are going to support in future versions are: * Non-greedy operators * Search-and-replace functionality * Error reporting The implementation is heavily based on the ideas from A Play on Regular Expressions by Sebastian Fischer, Frank Huch and Thomas Wilke. http://sebfisch.github.com/haskell-regexp/regexp-play.pdf -- Roman I. Cheplyaka :: http://ro-che.info/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] video for linux two (v4l2) bindings
Sounds awesome! I was recently thinking I wanted a v4l-binding. In the past I've patched vgrabbj so that I could pipe it and use it from Haskell, but wanted a direct binding. I just had a quick try with cabal-install and got the below. I'm not sure where linux/posix_types is supposed to come from. Is this error obvious to you? Ciao! Downloading bindings-linux-videodev2-0.1... Configuring bindings-linux-videodev2-0.1... Preprocessing library bindings-linux-videodev2-0.1... In file included from Bindings/Linux/videodev2.h:62, from VideoDev2.hsc:6: /usr/include/linux/types.h:8:31: error: linux/posix_types.h: No such file or directory VideoDev2.hsc: In function ‘main’: VideoDev2.hsc:1032: warning: cast from pointer to integer of different size VideoDev2.hsc:1032: warning: cast from pointer to integer of different size VideoDev2.hsc:1033: warning: cast from pointer to integer of different size VideoDev2.hsc:1033: warning: cast from pointer to integer of different size compiling dist/build/Bindings/Linux/VideoDev2_hsc_make.c failed command was: /usr/bin/gcc -c -D__GLASGOW_HASKELL__=612 -IBindings/Linux/ -I/home/chris/.cabal/lib/network-2.3.0.4/ghc-6.12.3/include -I/home/chris/Programs/lib/ghc-6.12.3/unix-2.4.0.2/include -I/home/chris/Programs/lib/ghc-6.12.3/bytestring-0.9.1.7/include -I/home/chris/.cabal/lib/bindings-DSL-1.0.11/ghc-6.12.3/include -I/home/chris/Programs/lib/ghc-6.12.3/base-4.2.0.2/include -I/home/chris/Programs/lib/ghc-6.12.3/include -I/home/chris/Programs/lib/ghc-6.12.3/include -I/home/chris/Programs/lib/ghc-6.12.3/include/ dist/build/Bindings/Linux/VideoDev2_hsc_make.c -o dist/build/Bindings/Linux/VideoDev2_hsc_make.o ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] video for linux two (v4l2) bindings
On Sunday 03 July 2011, 21:34:17, Christopher Done wrote: I just had a quick try with cabal-install and got the below. I'm not sure where linux/posix_types is supposed to come from. Is this error obvious to you? glibc-devel or the equivalent package for your distro, I think. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Confused about my IterIO code
Thanks David, Right - it invokes its iter repeatedly because mkInumC does that and mkInum is defined as: mkInum = mkInumC id noCtl So to do it all manually is: inumReverseLines :: (Monad m) = Inum L.ByteString L.ByteString m a inumReverseLines = mkInumM $ loop where loop = do eof - atEOFI unless eof $ do line - lineI ifeed (L.concat [L.reverse line, C.pack \n]) loop Cheers, -John On 1 July 2011 01:20, dm-list-haskell-c...@scs.stanford.edu wrote: At Thu, 30 Jun 2011 23:53:02 +1000, John Ky wrote: But all I've done is: enum |$ inumReverseLines .| iter inumReverseLines = mkInum $ do line - lineI return (L.reverse (L.concat [line, C.pack \n])) mkInum repeatedly invokes its iter argument so as to keep producing chunks. If you want to reverse only one line, it might be easiest to use something along the lines of: mkInumM $ do line - lineI ifeed (L.reverse (L.concat [line, C.pack \n])) mkInumM is a more manual Inum construction function that doesn't automatically do things like loop or handle EOF conditions. David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GUI Program Hangs in GHCI
Hello,
I have a GUI program that when I compile it and run it there are no
problems. When I load it into GHCI and type, main, it loads the
main window but there are no window decorations and the program hangs
to the point where I have to kill the ghci process. You see a
spinning cursor when you mouse over the window.
I found this old email regarding gtk2hs:
http://web.archiveorange.com/archive/v/nDNOvMeDATtTGn026lbI
I recompiled the program to use -threaded but the behavior is
unchanged (if the email above describes my problem then I expected the
compiled version to start having issues).
What else can cause the hangs I'm seeing?
I'm using the GLFW-b library on hackage and the program I'm trying to
run are any of the executables from the nehe-tuts package (also on
hackage). To reproduce my hangs, I think you need OSX (I didn't test
this on windows or linux), and then type the following:
{{{
mkdir -p ~/tmp/test
cd ~/tmp/test
cabal update
cabal-dev install-deps nehe-tuts
cabal unpack nehe-tuts
cabal-dev ghci nehe-tuts-0.2.3/lesson01.hs
*Main main
}}}
Doing a force quit on ghci gives me a stack trace via the OSX crash
reporting system. You'll find the relevant bits from that at the end
of this email.
What debugging techniques do I have at my disposal for figuring out
what is going wrong here? At least one person has suggested that
possibly ghci and the GUI bits of glfw are competing for input and
conflicting with each other. If that's the case, how could I be sure
and what would I do about it?
Thanks,
Jason
{{{
Process: ghc [48045]
Path:
/Library/Frameworks/GHC.framework/Versions/7.0.3-x86_64/usr/lib/ghc-7.0.3/ghc
UID: 502
Thread 84d5f8 DispatchQueue 1
User stack:
47 __semwait_signal + 10 (in libSystem.B.dylib) [0x7fff8760ef8a]
Kernel stack:
46 semaphore_wait_continue + 0 [0x22a88f]
1 lo_alltraps + 454 [0x2a1976]
1 i386_astintr + 47 [0x2aacb4]
1 ast_taken + 247 [0x219432]
1 bsd_ast + 806 [0x48fea8]
1 postsig + 432 [0x48cfff]
1 exit1 + 449 [0x48187a]
1 task_terminate_internal + 242 [0x22ca4d]
1 ipc_space_destroy + 177 [0x215868]
1 ipc_right_clean + 397 [0x215256]
1 mach_notify_no_senders + 75 [0x23ff7b]
1 mach_msg_send_from_kernel_proper + 90 [0x21e0cb]
1 ipc_kmsg_send + 105 [0x210a86]
1 ipc_kobject_server + 267 [0x21dbfc]
1 iokit_notify + 154 [0x284eed]
1 iokit_client_died + 85 [0x571527]
1 com.apple.GeForce 6.3.0 + 47083 [0x830867eb]
1 com.apple.GeForce 6.3.0 + 305981
[0x830c5b3d]
1 com.apple.GeForce 6.3.0 +
258633 [0x830ba249]
1 OSObject::release() const +
25 [0x506759]
1
OSObject::taggedRelease(void const*) const + 32 [0x50673e]
1 com.apple.GeForce 6.3.0
+ 253194 [0x830b8d0a]
1 com.apple.GeForce
6.3.0 + 251919 [0x830b880f]
1 com.apple.NVDAResman
6.3.0 + 453556 [0x83689bb4]
1
com.apple.NVDAResman 6.3.0 + 445937 [0x83687df1]
1
com.apple.NVDAResman 6.3.0 + 302211 [0x83664c83]
1
com.apple.NVDAResman 6.3.0 + 249957 [0x83658065]
1
com.apple.NVDAResman 6.3.0 + 112888 [0x836368f8]
1
com.apple.NVDAResman 6.3.0 + 111718 [0x83636466]
1
com.apple.nvidia.nv50hal 6.3.0 + 623157 [0x83e1a235]
1
com.apple.nvidia.nv50hal 6.3.0 + 605845 [0x83e15e95]
1
com.apple.nvidia.nv50hal 6.3.0 + 606056 [0x83e15f68]
Thread 84d67e DispatchQueue 2
User stack:
46 start_wqthread + 13 (in libSystem.B.dylib) [0x7fff875edfc5]
46 _pthread_wqthread + 353 (in libSystem.B.dylib) [0x7fff875ee128]
46 _dispatch_worker_thread2 + 252 (in libSystem.B.dylib)
[0x7fff875ee7fe]
46 _dispatch_queue_invoke + 185 (in libSystem.B.dylib)
[0x7fff875eecd4]
46 kevent + 10 (in libSystem.B.dylib) [0x7fff875ed12a]
Kernel stack:
46 kevent + 97 [0x47a681]
Thread 84d5f9
User stack:
46 kevent64 + 10 (in libSystem.B.dylib) [0x7fff87687512]
Kernel stack:
46 kevent + 97 [0x47a681]
Thread 84d5fa
User stack:
46 ??? [0x10681d9e8]
38 ??? [0x10a60403b]
37 CGLFlushDrawable + 67 (in OpenGL)
Re: [Haskell-cafe] GUI Program Hangs in GHCI
On Sun, Jul 3, 2011 at 5:16 PM, Jason Dagit dag...@gmail.com wrote: Hello, I have a GUI program that when I compile it and run it there are no problems. When I load it into GHCI and type, main, it loads the main window but there are no window decorations and the program hangs to the point where I have to kill the ghci process. You see a spinning cursor when you mouse over the window. I found this old email regarding gtk2hs: http://web.archiveorange.com/archive/v/nDNOvMeDATtTGn026lbI I recompiled the program to use -threaded but the behavior is unchanged (if the email above describes my problem then I expected the compiled version to start having issues). On second though, I think this *IS* a threading issue. Depending on where I add either forkIO or forkOS in main the compiled program either behaves the same as it does in ghci or it segfaults. I don't know how to fix it, but I suspect that I have to do something like what is described here: http://www.cocoabuilder.com/archive/cocoa/292830-nstimer-not-working-in-multithreaded-application.html I think the issue is that when I run the GUI code one a thread that isn't the original thread then I need to explicitly call that threads run loop. The above link points at this bit of documentation and I probably need to read it to develop a better understanding: http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strange context reduction with partial application and casting
On Sun, Jul 3, 2011 at 2:05 AM, Daniel Fischer daniel.is.fisc...@googlemail.com wrote: But as I understand it, the concern is ghci, where truly local bindings are probably rare and type signatures are commonly omitted. So putting :s -XNoMonomorphismRestriction in the .ghci file probably prevents more confusion and inconvenience than it causes. Especially given GHCi's extended defaulting rules which makes g = f 1 not ambiguous. [It sets a1 to ()] -- ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI Program Hangs in GHCI
On Sun, Jul 3, 2011 at 5:16 PM, Jason Dagit dag...@gmail.com wrote: Hello, I have a GUI program that when I compile it and run it there are no problems. When I load it into GHCI and type, main, it loads the main window but there are no window decorations and the program hangs to the point where I have to kill the ghci process. You see a spinning cursor when you mouse over the window. I don't know if this is the same issue, but it sounds like it at first glance: http://www.haskell.org/pipermail/haskell-cafe/2011-May/092029.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI Program Hangs in GHCI
On Sun, Jul 3, 2011 at 8:31 PM, Alexander Solla alex.so...@gmail.com wrote: On Sun, Jul 3, 2011 at 5:16 PM, Jason Dagit dag...@gmail.com wrote: Hello, I have a GUI program that when I compile it and run it there are no problems. When I load it into GHCI and type, main, it loads the main window but there are no window decorations and the program hangs to the point where I have to kill the ghci process. You see a spinning cursor when you mouse over the window. I don't know if this is the same issue, but it sounds like it at first glance: http://www.haskell.org/pipermail/haskell-cafe/2011-May/092029.html Heh. Yes, good memory! That's a link to an email I wrote in response to Conal. I'm looking into the issues that Conal mentions there. So far I've discovered that there is a bug in the Objective-C part of glfw when it inits threads[1]. Fixing that bug makes it so that I can use forkIO in the compiled version of my program but I still have the bad behavior in ghci. I think the remaining bit is that OSX (and probably windows too) makes it very hard to run your event loop on a thread other than your original thread[2]. I'm now wondering if the threading model in GHC even gives me enough control to handle this situation correctly. Jason [1] https://sourceforge.net/tracker/?func=detailaid=3352963group_id=72569atid=534938 [2] http://www.cocoabuilder.com/archive/cocoa/205803-event-loop-in-secondary-thread-nibless-cocoa.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How to ensure code executes in the context of a specific OS thread?
Hello, I'm trying to get some GUI code working on OSX and numerous forums around the internet keep reiterating that on OSX to correctly handle GUI events you need to use the original thread allocated to your process to check for events and to call the Cocoa framework functionality. Specifically, using a secondary thread (even a bound thread) is not sufficient with the Cocoa framework. I looked at the threading documentation in Control.Concurrent for GHC and it's not clear to me if this is even possible with GHC without restricting to the non-threaded RTS. This means that using the GUI library from GHCI is not an option and using multiple OS threads in the final application is also not possible. This means that some FFI libraries will be unusable. My main question is, is there a way around this so that I could, for example, use the library from GHCI? My second question is, if there is no current workaround then how can we remedy this situation? It seems like there could be an api function like: runOnOriginalThread :: IO a - IO a This function would be similar to runInBoundThread except it would be guaranteed to run on the original thread allocated to the ghc/ghci process. I believe the above primitive would be sufficient. I'll worry about filing a bug or making a libraries proposal after I have a better understanding of what must be done. Thanks, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Time
On 2011-07-02 14:03, Yitzchak Gale wrote: Not exactly. A TimeZone in Data.Time doesn't really represent a time zone - it represents a specific clock setting in a time zone. I still regret this! I should have called it TimeOffset or somesuch. To get a TimeZoneSeries, representing a time zone with all of its known clock changes throughout history and some years into the future, use the timezone-olson package[2] to read an Olson time zone file. On Linux and Mac OS X systems, Olson time zone files are available in the directory /usr/share/zoneinfo. Leap second data is there too, so it should be possible to create a Data.Time.Clock.TAI.LeapSecondTable from it. Also, it might be worth creating an OS-specific package that dealt with the filepaths for you, so for instance you could read in a TimeZoneSeries given a time zone name such as America/Los_Angeles. -- Ashley Yakeley ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GUI Program Hangs in GHCI
On Sun, Jul 3, 2011 at 9:06 PM, Jason Dagit dag...@gmail.com wrote: On Sun, Jul 3, 2011 at 8:31 PM, Alexander Solla alex.so...@gmail.com wrote: On Sun, Jul 3, 2011 at 5:16 PM, Jason Dagit dag...@gmail.com wrote: Hello, I have a GUI program that when I compile it and run it there are no problems. When I load it into GHCI and type, main, it loads the main window but there are no window decorations and the program hangs to the point where I have to kill the ghci process. You see a spinning cursor when you mouse over the window. I don't know if this is the same issue, but it sounds like it at first glance: http://www.haskell.org/pipermail/haskell-cafe/2011-May/092029.html Heh. Yes, good memory! That's a link to an email I wrote in response to Conal. I'm looking into the issues that Conal mentions there. So far I've discovered that there is a bug in the Objective-C part of glfw when it inits threads[1]. Fixing that bug makes it so that I can use forkIO in the compiled version of my program but I still have the bad behavior in ghci. I think the remaining bit is that OSX (and probably windows too) makes it very hard to run your event loop on a thread other than your original thread[2]. I'm now wondering if the threading model in GHC even gives me enough control to handle this situation correctly. My test was incorrect. Even with that fix I still can't use the threaded RTS in the compiled version. I think I understand the issue now and I'm looking for a solution in a different thread (pun intended?). Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?
On Mon, Jul 4, 2011 at 2:02 AM, Jason Dagit dag...@gmail.com wrote: My second question is, if there is no current workaround then how can we remedy this situation? It seems like there could be an api function like: runOnOriginalThread :: IO a - IO a Isn't there something on Cocoa that would allow you to implement this function? For example, to implement postGUISync [1] on Gtk2Hs, Glib's g_idle_add() [2] is used [3]. To implement Gtk.Application.Invoke [4] on Gtk#, Glib's g_timeout_add with a timeout of 0 seconds is used [6]. In other words, some way of running an arbitrary function inside Cocoa's event loop. Cheers! =) [1] http://hackage.haskell.org/packages/archive/gtk/0.12.0/doc/html/Graphics-UI-Gtk-General-General.html#v:postGUISync [2] http://developer.gnome.org/glib/2.28/glib-The-Main-Event-Loop.html#g-idle-add [3] http://hackage.haskell.org/packages/archive/gtk/0.12.0/doc/html/src/Graphics-UI-Gtk-General-General.html#postGUISync [4] (link seems broken) http://www.go-mono.com/docs/monodoc.ashx?link=M%3aGtk.Application.Invoke(System.EventHandler) [5] http://developer.gnome.org/glib/2.28/glib-The-Main-Event-Loop.html#g-timeout-add [6] https://github.com/mono/gtk-sharp/blob/master/gtk/Application.cs#L200 -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?
On Sun, Jul 3, 2011 at 10:02 PM, Jason Dagit dag...@gmail.com wrote: Hello, I'm trying to get some GUI code working on OSX and numerous forums around the internet keep reiterating that on OSX to correctly handle GUI events you need to use the original thread allocated to your process to check for events and to call the Cocoa framework functionality. Specifically, using a secondary thread (even a bound thread) is not sufficient with the Cocoa framework. Context for others: People explaining that you can't use the secondary thread for GUI operations: http://www.cocoabuilder.com/archive/cocoa/298918-multithread-window-event-runloop-headache.html http://old.nabble.com/Weird-Carbon%3A-gestalt%3A-wxPython-issue-bug-td27456897.html http://www.cocoabuilder.com/archive/cocoa/205803-event-loop-in-secondary-thread-nibless-cocoa.html http://forums.libsdl.org/viewtopic.php?t=6281sid=ec818336d68f9797090719b3c5916c21 http://www.cocoabuilder.com/archive/cocoa/292830-nstimer-not-working-in-multithreaded-application.html http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/Multithreading/CreatingThreads/CreatingThreads.html http://www.cocoabuilder.com/archive/cocoa/152947-cocoa-multithreading-in-terrible-idea-isn-it.html Cocoa provides several ways to run things on the main thread (same as I meant when I said original thread): http://blog.jayway.com/2010/03/30/performing-any-selector-on-the-main-thread/ http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/ Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?
On Jul 3, 2011, Jason Dagit dag...@gmail.com wrote: to correctly handle GUI events you need to use the original thread allocated to your process to check for events and to call the Cocoa framework functionality. I looked at the threading documentation in Control.Concurrent for GHC and it's not clear to me if this is even possible with GHC without restricting to the non-threaded RTS. The 'main' thread in GHC is the bound thread initially allocated to the process. You can easily establish an event-loop in the main thread, and feed events from other threads. Consider using Control.Concurrent.Chan. If you need feedback, things get a bit trickier because you'll have special cases based on whether you're starting in the main thread. Regards, Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?
On Sun, Jul 3, 2011 at 10:31 PM, David Barbour dmbarb...@gmail.com wrote: On Jul 3, 2011, Jason Dagit dag...@gmail.com wrote: to correctly handle GUI events you need to use the original thread allocated to your process to check for events and to call the Cocoa framework functionality. I looked at the threading documentation in Control.Concurrent for GHC and it's not clear to me if this is even possible with GHC without restricting to the non-threaded RTS. The 'main' thread in GHC is the bound thread initially allocated to the process. That doesn't seem to be the case for GHCI. You can easily establish an event-loop in the main thread, and feed events from other threads. Consider using Control.Concurrent.Chan. If you need feedback, things get a bit trickier because you'll have special cases based on whether you're starting in the main thread. Yes, that might work for compiled programs. What about GHCI? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to ensure code executes in the context of a specific OS thread?
On Sun, Jul 3, 2011 at 10:22 PM, Felipe Almeida Lessa felipe.le...@gmail.com wrote: On Mon, Jul 4, 2011 at 2:02 AM, Jason Dagit dag...@gmail.com wrote: My second question is, if there is no current workaround then how can we remedy this situation? It seems like there could be an api function like: runOnOriginalThread :: IO a - IO a Isn't there something on Cocoa that would allow you to implement this function? For example, to implement postGUISync [1] on Gtk2Hs, Glib's g_idle_add() [2] is used [3]. To implement Gtk.Application.Invoke [4] on Gtk#, Glib's g_timeout_add with a timeout of 0 seconds is used [6]. In other words, some way of running an arbitrary function inside Cocoa's event loop. There are a few objective-c specific ways of sending something to the right thread. I was hoping to find something a bit more general and easier to call from Haskell (I believe the way the FFI works I'll have to make a new wrapper for each thing because I can't directly call objective-c). I suppose I should try adding wrappers around all the GLFW functions so that it sends the request over to the main thread and see if it solves my problem. The downside is that it would be a lot of wrapper code and it would be nice to have solution that other libraries can use. Thanks for the idea. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
