[Haskell-cafe] New Functional Programming Job Opportunities
Here are some functional programming job opportunities that were posted recently: Senior Scala Developer for Green Building Software at Sefaira http://functionaljobs.com/jobs/8649-senior-scala-developer-for-green-building-software-at-sefaira Cheers, Sean Murphy FunctionalJobs.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi Conal, I wasn't able to make it to last Saturday's FARM track, but I think there was a good chance that Paul would have demonstrated his Euterpea music library, which includes a GUI interface (called MUI) written on top of GLFW. I wrote its initial implementation (around 2009?) with a monadic interface that let you wire together UI components with signals (I believe Dan later wrote an arrow interface, but I could be wrong). It was actually inspired by the ideas behind your Phooey UI library. It should be very easy to extract this part out as a standalone package if there is enough interest. The only issue with it (and all other UI libraries) is that it doesn't play nicely in GHCi. It used to work pretty well with GHC 7.2 and 7.4 on almost all platforms (Mac needs an extra hack), but GHC 7.6 broke Mac (and perhaps Windows too). GHC 7.8 supposedly should fix this problem. BTW, as also the author of the GLFW library on HackageDB, I've done barely minimal to keep this Haskell binding afloat. I'm actually leaning towards GLFW-b library, which is better maintained, and provides similar binding for GLFW C library but with a saner interface (no dependency on the OpenGL library, for example). If you don't need the two extra things that GLFW does (choice of either dynamic or static linking to GLFW C, and an embedded bitmap font), I suggest you try out GLFW-b if you are only looking for a think graphics layer with input+window+OpenGL. The only thing keeping GLFW-b from becoming a good foundation for a pure Haskell UI lib is IMHO the lack of a light-weight, cross-platform, and full-featured font rendering solution. I believe many other libraries (including Diagram) are having the same problem. On Thu, Sep 26, 2013 at 8:32 PM, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Regards, Paul Liu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Partitionable goes somewhere + containers instances
Upon consideration from a package management perspective this is probably easiest done by building a new small package to provide the functionality you want. That way we don't haphazardly change the transitive dependencies of a big chunk of the ecosystem and it can rest atop the various containers libraries. This also gives you a lot of opportunity to iterate on the API in public without incurring the instant rigidity of the Haskell Platform. On Sun, Sep 29, 2013 at 11:06 PM, Ryan Newton rrnew...@gmail.com wrote: Thanks Edward. Good point about Brent's 'split' package. That would be a really nice place to put the class. But it doesn't currently depend on containers or vector so I suppose the other instances would need to go somewhere else. (Assuming containers only exported monomorphic versions.) Maybe a next step would be proposing some monomorphic variants for the containers package. I think the complicated bit will be describing how best-efforty splitting variants are: - Is it guaranteed O(1) time and allocation? - Is the provided Int an upper bound? Lower(ish) bound? Or just a hint? With some data structures, there will be a trade-off between partition imbalance and the work required to achieve balance. But with some data structures it is happily not a problem (e.g. Vector)! But whether there's one variant or a few, I'd be happy either way, as long as I get at least the cheap one (i.e. prefer imbalance to restructuring). -Ryan On Sun, Sep 29, 2013 at 8:20 AM, Edward Kmett ekm...@gmail.com wrote: I don't know that it belongs in the standard libraries, but there could definitely be a package for something similar. ConstraintKinds are a pretty hefty extension to throw at it, and the signature written there prevents it from being used on ByteString, Text, etc. This can be implemented with much lighter weight types though! class Partitionable t where partition :: Int - t - [t] Now ByteString, Text etc. can be instances and no real flexibility is lost, as with the class associated constraint on the argument, you'd already given up polymorphic recursion. There still remain issues. partition is already established as the filterthat returns both the matching and unmatching elements, so the name is wrong. This is a generalization of Data.List.splitEvery, perhaps it is worth seeing how many others can be generalized similarly and talk to Brent about adding, say, a Data.Split module to his split package in the platform? -Edward On Sun, Sep 29, 2013 at 4:21 AM, Ryan Newton rrnew...@gmail.com wrote: subject change On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki m...@izbicki.me wrote: I've got a Partitionable class that I've been using for this purpose: https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/ConstraintKinds/Partitionable.hs Mike -- Neat, that's a cool library! Edward -- ideally, where in the standard libraries should the Partitionable comonoid go? Btw, I'm not sure what the ideal return type for comappend is, given that it needs to be able to bottom out. Mike, our partition function's list return type seems more reasonable. Or maybe something simple would be this: *class Partitionable t where* * partition :: t - Maybe (t,t)* That is, at some point its not worth splitting and returns Nothing, and you'd better be able to deal with the 't' directly. So what I really want is for the *containers package to please get some kind of Partitionable instances! * Johan others, I would be happy to provide a patch if the class can be agreed on. This is important because currently the balanced tree structure of Data.Set/Map is an *amazing and beneficial property* that is *not* exposed at all through the API. For example, it would be great to have a parallel traverse_ for Maps and Sets in the Par monad. The particular impetus is that our new and enhanced Par monad makes extensive use of Maps and Sets, both the pure, balanced ones, and lockfree/inplace ones based on concurrent skip lists: http://www.cs.indiana.edu/~rrnewton/haddock/lvish/ Alternatively, it would be ok if there were a Data.Map.Internal module that exposed the Bin/Tip, but I assume people would rather have a clean Partitionable instance... Best, -Ryan On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki m...@izbicki.me wrote: I've got a Partitionable class that I've been using for this purpose: https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/ConstraintKinds/Partitionable.hs The function called parallel in the HLearn library will automatically parallelize any homomorphism from a Partionable to a Monoid. I specifically use that to parallelize machine learning algorithms. I have two thoughts for better abstractions: 1) This Partitionable class is essentially a comonoid. By reversing the arrows of mappend, we get: comappend :: a - (a,a) By itself, this
Re: [Haskell-cafe] What class for splittable data / balanced-fold?
On Sun, Sep 29, 2013 at 9:13 PM, Ryan Newton rrnew...@gmail.com wrote:
Thanks, that's interesting to know (re: Fortress).
Interestingly, in my Fortress days we looked at both using a split-like
interface and at a more foldMap / reduce - like interface, and it seemed
like the latter worked better – it requires a lot less boilerplate for
controlling recursion, and better matches the fanout of whatever structure
you're actually using underneath.
Ok, we'll have to try that. I may be underestimating the power of a
newtype and a monoid instance to expose the structure.. I was wrong about
this before [1]. Here's the foldMap instance for Data.Map:
foldMap _ Tip = mempty foldMap f (Bin _ _ v l r) = Foldable.foldMap f l
`mappend` f v `mappend` Foldable.foldMap f r
Simon Marlow in his recent Haxl talk also had a domain where they wanted a
symmetric (non-monadic) parallel spawn operation...
But it remains pretty hard for me to reason about the operational behavior of
these things... especially since foldMap instances may vary.
I'll note that there's really a documentation responsibility here that
hasn't been honored as much as it should (possibly because lots of folks
are driving Foldable, which other commenters have noted doesn't seem to do
what you want for tree-like data structures – I certainly didn't realize
that).
It'd be worth thinking about doing the derivation of foldMap directly from
the structure of the underlying type.
It'd also be worth documenting when we get tree-structured traversal out of
a Foldable instance, and fixing the ones that don't provide it.
And I agree that getting down to non-allocating traversals is the ultimate
goal here. If we leak space or lose parallelism we might as well not
bother.
-Jan
Thanks,
-Ryan
[1] For example, here is a non-allocating traverseWithKey_ that I failed to
come up with:
-- Version of traverseWithKey_ from Shachaf Ben-Kiki
-- (See thread on Haskell-cafe.)
-- Avoids O(N) allocation when traversing for side-effect.
newtype Traverse_ f = Traverse_ { runTraverse_ :: f () }
instance Applicative f = Monoid (Traverse_ f) where
mempty = Traverse_ (pure ())
Traverse_ a `mappend` Traverse_ b = Traverse_ (a * b)
-- Since the Applicative used is Const (newtype Const m a = Const m), the
-- structure is never built up.
--(b) You can derive traverseWithKey_ from foldMapWithKey, e.g. as follows:
traverseWithKey_ :: Applicative f = (k - a - f ()) - M.Map k a - f ()
traverseWithKey_ f = runTraverse_ .
foldMapWithKey (\k x - Traverse_ (void (f k x)))
foldMapWithKey :: Monoid r = (k - a - r) - M.Map k a - r
foldMapWithKey f = getConst . M.traverseWithKey (\k x - Const (f k x))
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Partitionable goes somewhere + containers instances
so the simple O(1) split would produce three submaps, the middle one having only one element. This operation would not be very parallelization-friendly. Actually, I'm perfectly happy with that in this case! - A decent work-stealing system can tolerate a fairly large number of excessively small, trivial computations. It's having *only* those that's a big problem. (Which is what you often get if your parallel container ops spawn a task per element.) - Since Maps support O(1) size, the consumer of the split-up-map could choose to sequentially execute the singleton maps if desired. Personally, I'm most interested in set-like operations and don't need any order guarantees. But that's another dimension in which one could chop up the API... Maybe this does deserve its own module in the namespace, and maybe its own package, as Edward suggested. -Ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Vacancy Assistant Professor Software Technology Utrecht University (1, 0 fte)
Assistant Professor Software Technology Utrecht University (1,0 fte)Job descriptionThe division Software Systems of the Department of Information and Computing Sciences is looking for an Assistant Professor for the bachelor programmes Computing Science and Information Science and the master programmes of the department, and for research in the area of software technology.You are expected to develop an independent line of research within the field of software technology in cooperation with the other members of the division Software Systems.The tasks include:performing scientific research in the field of software systems, in particular software technology;supervising PhD students and acquiring research funding;developing and teaching courses within the bachelor and master programmes of the department;supervising internships and theses;organizational activities within the division, department or faculty.QualificationsWe are looking for candidates with a PhD with expertise and experience in scientific education and research in computer science. Expertise in the fields of software technology, programming languages and typing systems, advanced programming methods, or compilers is required. Experience in academic education within a university setting is desired. You have published on the aforementioned areas in national and international conferences and / or journals. Well-developed teaching skills and command of English in speaking and writing are a requirement. Candidates who prefer part-time employment are also invited to apply by specifying the desired part-time ratio.OfferWe offer a position in a dynamic environment. The position is for at most five years. The total size of the position is 100%, but part-time is possible. The salary depends on education and experience and ranges between € 2,919 (scale 10) and € ,5070 (scale 12) gross per month for a full-time appointment. Additionally, excellent secondary benefits are provided, such as 8% holiday allowance and 8.3% end of year bonus.We also offer a pension scheme, partially paid parental leave and flexible working conditions. For more information see theterms of employment. The department provides the candidate the necessary support for the arrangements of the education and research line.About the organisationUtrecht University has great ambitions for its teaching quality and study success rates. This also applies to its clear research profiles which are centred around four themes: Sustainability, Life Sciences, Youth Identity, and Institutions. Utrecht University plays a prominent role in our society and contributes to finding the answers to topical and future societal issues.The Faculty of Science at Utrecht University comprises six departments: Biology, Pharmacy, Information and Computer Sciences, Chemistry, Mathematics and Physics and Astronomy. It has 3500 students and nearly 2000 employees, and is internationally known for its quality in research. The academic programs of the Faculty reflect developments in society and science of today.The Department of Information and Computer Science is nationally and internationally renowned for its fundamental research in computer science and information science. Its research is positioned around game technology, one of the four research themes of the Faculty of Science. The research of the department is grouped into four divisions: Software Systems, Artificial Intelligence, Virtual Worlds and Interaction Technology. The Department offers bachelor programmes in computer science and information science, and four English-language research master-programmes including Computing Science. High enrollment figures and good student ratings make the education very successful.Part of the research of the division Software Systems focuses on how programming languages, methods, and tools can be adapted to support program construction.More specifically, the research covers the following areas:programming languages and compiler construction-toolsprogram analysisinteraction analysis, error diagnosisadvanced programming methods: generic programming, dependently-typed programmingprogram testing and verificationThe division aims to design better programming languages and methods; to implement tools and languages that help programmers work more effectively; and to develop products and systems demonstrating the feasibility (and/or validity) of the ideas. An important application area studied in the department and the division is (serious) games. The division mainly contributes to the education in the bachelor programs information science and computer science, and to the master program Computing Science.Additional informationFor more information please contact Prof.dr. Johan Jeuring +31.30.253.4115 or +31.6.400.100.53, email:j.t.jeur...@uu.nl.ApplyYour application must contain a letter of motivation, your CV with publication list, teaching and research statement, and contact details of at least two references.You can respond via the
Re: [Haskell-cafe] What class for splittable data / balanced-fold?
Oops, this email got stuck in the pipe (flaky internet): foldMap _ Tip = mempty foldMap f (Bin _ _ v l r) = Foldable.foldMap f l `mappend` f v `mappend` Foldable.foldMap f r Btw, from my perspective, one problem with relying on foldMap is that it treats the whole structure uniformly, whereas the split approach would let one, for example, bottom out to a sequential implementation at a certain granularity. Perhaps that is the boilerplate for controlling recursion that you referred to... but isn't it sometimes necessary? -Ryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal: Partitionable goes somewhere + containers instances
Edward, The problem is that I need *something* more from the containers library to be able to construct this as a separate library. I don't think I can use foldMap to implement a Splittable/Partitionable instance for Data.Set, namely because I specifically want to do O(1) work instead of any kind of full traversal of the structure. Is the least possible disruption here to just have a Data.Map.Internal that exposes Tip and Bin? It can be marked with suitable warnings at the top of the module. Or would the preference to be to expose something more abstract of type Map k a - [Map k a] that chops it into the natural pieces? [1] -Ryan [1] Btw, it seems like returning a tuple here might make deforestation more likely than returning a list... right? On Mon, Sep 30, 2013 at 9:52 AM, Edward Kmett ekm...@gmail.com wrote: Upon consideration from a package management perspective this is probably easiest done by building a new small package to provide the functionality you want. That way we don't haphazardly change the transitive dependencies of a big chunk of the ecosystem and it can rest atop the various containers libraries. This also gives you a lot of opportunity to iterate on the API in public without incurring the instant rigidity of the Haskell Platform. On Sun, Sep 29, 2013 at 11:06 PM, Ryan Newton rrnew...@gmail.com wrote: Thanks Edward. Good point about Brent's 'split' package. That would be a really nice place to put the class. But it doesn't currently depend on containers or vector so I suppose the other instances would need to go somewhere else. (Assuming containers only exported monomorphic versions.) Maybe a next step would be proposing some monomorphic variants for the containers package. I think the complicated bit will be describing how best-efforty splitting variants are: - Is it guaranteed O(1) time and allocation? - Is the provided Int an upper bound? Lower(ish) bound? Or just a hint? With some data structures, there will be a trade-off between partition imbalance and the work required to achieve balance. But with some data structures it is happily not a problem (e.g. Vector)! But whether there's one variant or a few, I'd be happy either way, as long as I get at least the cheap one (i.e. prefer imbalance to restructuring). -Ryan On Sun, Sep 29, 2013 at 8:20 AM, Edward Kmett ekm...@gmail.com wrote: I don't know that it belongs in the standard libraries, but there could definitely be a package for something similar. ConstraintKinds are a pretty hefty extension to throw at it, and the signature written there prevents it from being used on ByteString, Text, etc. This can be implemented with much lighter weight types though! class Partitionable t where partition :: Int - t - [t] Now ByteString, Text etc. can be instances and no real flexibility is lost, as with the class associated constraint on the argument, you'd already given up polymorphic recursion. There still remain issues. partition is already established as the filter that returns both the matching and unmatching elements, so the name is wrong. This is a generalization of Data.List.splitEvery, perhaps it is worth seeing how many others can be generalized similarly and talk to Brent about adding, say, a Data.Split module to his split package in the platform? -Edward On Sun, Sep 29, 2013 at 4:21 AM, Ryan Newton rrnew...@gmail.com wrote: subject change On Sun, Sep 29, 2013 at 3:31 AM, Mike Izbicki m...@izbicki.me wrote: I've got a Partitionable class that I've been using for this purpose: https://github.com/mikeizbicki/ConstraintKinds/blob/master/src/Control/ConstraintKinds/Partitionable.hs Mike -- Neat, that's a cool library! Edward -- ideally, where in the standard libraries should the Partitionable comonoid go? Btw, I'm not sure what the ideal return type for comappend is, given that it needs to be able to bottom out. Mike, our partition function's list return type seems more reasonable. Or maybe something simple would be this: *class Partitionable t where* * partition :: t - Maybe (t,t)* That is, at some point its not worth splitting and returns Nothing, and you'd better be able to deal with the 't' directly. So what I really want is for the *containers package to please get some kind of Partitionable instances! * Johan others, I would be happy to provide a patch if the class can be agreed on. This is important because currently the balanced tree structure of Data.Set/Map is an *amazing and beneficial property* that is *not* exposed at all through the API. For example, it would be great to have a parallel traverse_ for Maps and Sets in the Par monad. The particular impetus is that our new and enhanced Par monad makes extensive use of Maps and Sets, both the pure, balanced ones, and lockfree/inplace ones based on concurrent skip lists:
Re: [Haskell-cafe] Poll plea: State of GUI graphics libraries in Haskell
Hi Conrad, Great. The challenge is not specific to Pan, Vertigo, etc. If we can get some low-level GUI platform working with the characteristics I listed, I can resurrect and my high-level libraries accordingly. Any GUI program containing at least one OpenGL window would probably get us most of the way there (again, noting the properties I listed). -- Conal On Fri, Sep 27, 2013 at 1:40 AM, Conrad Parker con...@metadecks.org wrote: Hi Conal! Yes. I'd be very interested to help get Pan and Vertigo working. Do you have a repo somewhere? Conrad. On 27 September 2013 13:32, Conal Elliott co...@conal.net wrote: I'm polling to see whether there are will and expertise to reboot graphics and GUIs work in Haskell. I miss working on functional graphics and GUIs in Haskell, as I've been blocked for several years (eight?) due to the absence of low-level foundation libraries having the following properties: * cross-platform, * easily buildable, * GHCi-friendly, and * OpenGL-compatible. The last several times I tried Gtk2hs, I was unable to compile it on my Mac. Years ago when I was able to compile, the GUIs looked and interacted like a Linux app, which made them awkward and upleasant to use. wxHaskell (whose API and visual appearance I prefered) has for years been incompatible with GHCi, in that the second time I open a top-level window, the host process (GHCi) dies abruptly. Since my GUI graphics programs are often one-liners, and I tend to experiment a lot, using a full compilation greatly thwarts my flow. For many years, I've thought that the situation would eventually improve, since I'm far from the only person who wants GUIs or graphics from Haskell. About three years ago, I built a modern replacement of my old Pan and Vertigo systems (optimized high-level functional graphics in 2D and 3D), generating screamingly fast GPU rendering code. I'd love to share it with the community, but I'm unable to use it even myself. Two questions: * Am I mistaken about the current status? I.e., is there a solution for Haskell GUI graphics programming that satisfies the properties I'm looking for (cross-platform, easily buildable, GHCi-friendly, and OpenGL-compatible)? * Are there people willing and able to fix this situation? My own contributions would be to test and to share high-level composable and efficient GUI and graphics libraries on top of a working foundation. Looking forward to replies. Thanks, -- Conal ___ 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
[Haskell-cafe] The RTSOPTS -qm flag's impact on runtime
Hi all, I found an interesting case where the rtsopts -qm flag makes a significant difference in runtime (~50x). This is using GHC 7.6.3, llvm 3.4, program compiled with -threaded -O2 -fllvm and a couple of language extension. Source is at http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=chameneosreduxlang=ghcid=4data=u64q, on the language shootout benchmarks. Running the code without -N results (on my computer) in around 4 seconds of runtime: $ time ./orig 600 … real0m3.919s user0m3.903s sys 0m0.010s This is reasonably consistent. Running -N4 (this is an 8-core machine) results in the surprising: $ time ./orig 600 +RTS -N4 … real1m15.154s user1m38.790s sys 2m7.947s The cores are all used very erratically (continuously changing 5%-20%-40%) and the overall cpu usage is ~27-28%. Note the surprising 2m7s of sys usage, which means the kernel is involved a lot… Note that removing the explicit forkOn and running with -N4 results in somewhat worse performance: real2m6.548s user2m13.470s sys 2m3.043s So in that sense the forkOn itself is not at fault. What I have found is that -qm is here a life saver: $ time ./orig 600 +RTS -N4 -qm real0m2.773s user0m5.610s sys 0m0.123s Adding -qa doesn't make a big difference. To summarise more runs (in terms of cpu used, user+sys): with forkOn: - -N4: 228s - -N4 -qa: 110s - -N4 -qm: 6s - -N4 -qm -qa: 6s without forkOn: - -N4: 253s - -N4 -qa: 252s - -N4 -qm: 5s - -N4 -qm -qa: 5s (Note that without forkOn is a bit slower in term of wall-clock, as the with forkOn version distributes the work a bit better, even if it uses overall a tiny bit more CPU.) So the question is, what does -qm actually do that it affects this benchmark so much (~50x)? (The docs are not very clear on it) And furthermore, could there be an heuristic inside the runtime such that automatic thread migration is suspended if threads are over-migrated (which is what I suppose happens here)? thanks for any explanations, iustin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
