[Haskell] Journal of Functional Programming - Call for PhD Abstracts
CALL FOR PHD ABSTRACTS
Journal of Functional Programming
Deadline: 30th April 2015
http://tinyurl.com/jfp-phd-abstracts
PREAMBLE:
Many students complete PhDs in functional programming each
year, but there is currently no common location in which to
promote and advertise the resulting work. The Journal of
Functional Programming would like to change that!
As a service to the community, JFP recently launched a new
feature, in the form of a regular publication of abstracts
from PhD dissertations that were completed during the previous
year. The abstracts are made freely available on the JFP
website, i.e. not behind any paywall, and do not require any
transfer for copyright, merely a license from the author.
Please submit dissertation abstracts according to the
instructions below. A dissertation is eligible if parts
of it have or could have appeared in JFP, that is, if it
is in the general area of functional programming. JFP
will not have these abstracts reviewed. We welcome
submissions from both the PhD student and PhD advisor/
supervisor although we encourage them to coordinate.
SUBMISSION:
Please submit the following information to Graham Hutton
graham.hut...@nottingham.ac.uk by 30th April 2015.
o Dissertation title: (including any subtitle)
o Student: (full name)
o Awarding institution: (full name and country)
o Date of PhD award: (month and year; depending on the
institution, this may be the date of the viva, corrections
being approved, graduation ceremony, or otherwise)
o Advisor/supervisor: (full names)
o Dissertation URL: (please provide a permanently accessible
link to the dissertation if you have one, such as to an
institutional repository or other public archive; links
to personal web pages should be considered a last resort)
o Dissertation abstract: (plain text, maximum 1000 words;
you may use \emph{...} for emphasis, but we prefer no
other markup or formatting in the abstract, but do get
in touch if this causes significant problems)
Please do not submit a copy of the dissertation itself, as
this is not required. JFP reserves the right to decline
to publish abstracts that are not deemed appropriate.
PHD ABSTRACT EDITOR:
Graham Hutton
School of Computer Science
University of Nottingham
Nottingham NG8 1BB
United Kingdom
This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.
Please do not use, copy or disclose the information contained in this
message or in any attachment. Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.
This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.
___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
[Haskell] ANNOUNCE: Arion
Three of us have been working on Arion for a week or two now. It's a watcher and runner for Hspec tests. It associates source files with test files, watches the file system, and when a file changes it runs the corresponding test files instead of running all the test files, making the process of red-green-refactor faster. We are happy to announce that we have a nice and stable version (0.1.0.8). Thanks to the folks at hspec.github.io for listing our project on their website. To know more, please visit - https://github.com/karun012/arion Feedback/Feature Requests/Everything else welcome. ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Binary bloat in 7.10
Why do the 7.10 libraries take up so much more space than 7.8? For example, using the same build options and strip --strip-unneeded, 7.8 leaves me with 15M libHSCabal-1.18.1.5.a 17M HSCabal-1.18.1.5.o whereas 7.10 balloons to 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
[Haskell] DSLDI: 3rd Workshop on Domain-Specific Language Design and Implementation (EXTENDED DEADLINE)
* SECOND CALL FOR TALK PROPOSALS DSLDI 2015 Third Workshop on Domain-Specific Language Design and Implementation July 7, 2015 Prague, Czech Republic Co-located with ECOOP http://2015.ecoop.org/track/dsldi-2015-papers * EXTENDED Deadline for talk proposals: 9th of April, 2015 If designed and implemented well, domain-specific languages (DSLs) combine the best features of general-purpose programming languages (e.g., performance) with high productivity (e.g., ease of programming). *** Workshop Goal *** The goal of the DSLDI workshop is to bring together researchers and practitioners interested in sharing ideas on how DSLs should be designed, implemented, supported by tools, and applied in realistic application contexts. We are both interested in discovering how already known domains such as graph processing or machine learning can be best supported by DSLs, but also in exploring new domains that could be targeted by DSLs. More generally, we are interested in building a community that can drive forward the development of modern DSLs. *** Workshop Format *** DSLDI is a single-day workshop and will consist of a series of short talks whose main goal is to trigger exchange of opinion and discussions. The talks should be on the topics within DSLDI's area of interest, which include but are not limited to the following ones: * DSL implementation techniques, including compiler-level and runtime-level solutions * utilization of domain knowledge for driving optimizations of DSL implementations * utilizing DSLs for managing parallelism and hardware heterogeneity * DSL performance and scalability studies * DSL tools, such as DSL editors and editor plugins, debuggers, refactoring tools, etc. * applications of DSLs to existing as well as emerging domains, for example graph processing, image processing, machine learning, analytics, robotics, etc. * practitioners reports, for example descriptions of DSL deployment i a real-life production setting *** Call for Submissions *** We solicit talk proposals in the form of short abstracts (max. 2 pages). A good talk proposal describes an interesting position, demonstration, or early achievement. The submissions will be reviewed on relevance and clarity, and used to plan the mostly interactive sessions of the workshop day. Publication of accepted abstracts and slides on the website is voluntary. * _EXTENDED_ Deadline for talk proposals: April 9th, 2015 * Notification: May 8th, 2015 * Workshop: July 7th, 2015 * Submission website: https://easychair.org/conferences/?conf=dsldi2015 *** Workshop Organization *** Organizers * Tijs van der Storm (st...@cwi.nl), CWI, The Netherlands * Sebastian Erdweg (erd...@informatik.tu-darmstadt.de), TU Darmstadt, Germany Follow us on Twitter at https://twitter.com/wsdsldi Program committee * Emilie Balland * Martin Bravenboer (LogicBlox) * Hassan Chafi (Oracle Labs) * William Cook (UT Austin) * Shriram Krishnamurthi (Brown University) * Heather Miller (EPFL) * Bruno Oliveira (University of Hong Kong) * Cyrus Omar (CMU) * Richard Paige (University of York) * Tony Sloane (Macquarie University) * Emma Söderberg (Google) * Emma Tosch (University of Massachusetts, Amherst) * Jurgen Vinju (CWI) -- Researcher Centrum Wiskunde Informatica (CWI) Master of Software Engineering Universiteit van Amsterdam (UvA) Dr. Tijs van der Storm @ Centrum Wiskunde Informatica (CWI) Office: L225| Phone: +31 (0)20 5924164 | Address: Science Park 123 P.O. Box 94079 | Postal code: 1090 GB | Amsterdam, The Netherlands ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Increased memory usage with GHC 7.10.1
Forall hi, I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed installations of GHC and this means I had to rebuild Agda and Idris because the binaries built with GHC 7.8.4 were stored inside deactivated 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due to GHC taking up all of available memory. With Idris the problematic module was Idris.ElabTerm (~2900LOC). The interesting part of the story is that when I do a clean build of Idris GHC consumes all of memory when compiling that module and I have to kill the build. But when I restart the build after killing GHC the module is compiled using a reasonable amount of memory and within reasonable time. With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC). The trick with killing the build and restarting it didn't work in this case. I had to compile Agda with GHC 7.8.4 (which works without problems though the mentioned module still requires a lot of memory) and alter my setup so that Agda binary is not stored inside GHC sandbox. I wonder if any of you came across similar issues with GHC 7.10.1? Do we have any performance data that allows to compare memory usage and performance of GHC 7.10.1 with previous stable releases? All of the above happened on 64bit Debian Wheezy with 2GB of RAM. Janek --- Politechnika Łódzka Lodz University of Technology Treść tej wiadomości zawiera informacje przeznaczone tylko dla adresata. Jeżeli nie jesteście Państwo jej adresatem, bądź otrzymaliście ją przez pomyłkę prosimy o powiadomienie o tym nadawcy oraz trwałe jej usunięcie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Roman Cheplyaka-2 wrote I'm not denying (or confirming) your claim, but it would look more legitimate if you compared the same version of Cabal compiled with different versions of GHC. At least some of this bloat could be because Cabal simply gained more code. Tricky to test that because of dependencies and global package db. I haven't measured the amount of code in Cabal, but I doubt it's increased that much, and there has been a big jump in the installed size of every library. -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768080.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
On 01/04/15 12:30, Jeremy wrote: Why do the 7.10 libraries take up so much more space than 7.8? For example, using the same build options and strip --strip-unneeded, 7.8 leaves me with 15M libHSCabal-1.18.1.5.a 17M HSCabal-1.18.1.5.o whereas 7.10 balloons to 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a I'm not denying (or confirming) your claim, but it would look more legitimate if you compared the same version of Cabal compiled with different versions of GHC. At least some of this bloat could be because Cabal simply gained more code. Roman ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
7.10.1 should IIRC support some kind of DWARF debugging information and IIRC it was mentioned and decided on ghc devel that the libraries will ship with some DWARF to easy debugging -- but takes me lightly on it and verify if this is the case since I may be completely off and this may apply to GHC HEAD and not to 7.10.x Karel On 04/ 1/15 11:30 AM, Jeremy wrote: Why do the 7.10 libraries take up so much more space than 7.8? For example, using the same build options and strip --strip-unneeded, 7.8 leaves me with 15M libHSCabal-1.18.1.5.a 17M HSCabal-1.18.1.5.o whereas 7.10 balloons to 23M HSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.o 53M libHSCabal-1.22.2.0-HWT8QvVfJLn2ubvobpycJY.a -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
It's not just binaries, even hi files have ballooned. (I should note that (stripped) executables appear to be unaffected.) -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768072.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Karel Gardas wrote 7.10.1 should IIRC support some kind of DWARF debugging information and IIRC it was mentioned and decided on ghc devel that the libraries will ship with some DWARF to easy debugging -- but takes me lightly on it and verify if this is the case since I may be completely off and this may apply to GHC HEAD and not to 7.10.x Stripped all debugging, didn't help. -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768077.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Roman Cheplyaka-2 wrote I'm not denying (or confirming) your claim, but it would look more legitimate if you compared the same version of Cabal compiled with different versions of GHC. At least some of this bloat could be because Cabal simply gained more code. I was going to prove you wrong by identifying packages which have barely changed for 7.10 ... and found that those packages were a similar size to their 7.8 versions. However, the size increase in other packages is huge, and simply gained more code doesn't seem like an adequate explanation, with some package more than doubling. Here are the full results: 7.8: 34M Cabal-1.18.1.5 3.8Marray-0.5.0.0 50M base-4.7.0.2 52M bin 368Kbin-package-db-0.0.0.0 2.7Mbinary-0.7.1.0 5.4Mbytestring-0.10.4.0 9.4Mcontainers-0.5.5.1 196Kdeepseq-1.3.0.2 608Kdirectory-1.2.1.0 740Kfilepath-1.3.0.2 105Mghc-7.8.4 2.7Mghc-prim-0.3.1.0 8.7Mhaskeline-0.7.1.2 3.4Mhoopl-3.10.0.1 1020K hpc-0.6.0.1 556Kinteger-gmp-0.5.1.0 680Kpretty-1.1.1.1 684Kprocess-1.2.0.0 1.6Mrts-1.0 13M template-haskell-2.9.0.0 1.4Mterminfo-0.4.0.0 6.1Mtime-1.4.2 4.4Mtransformers-0.3.0.0 5.2Munix-2.7.0.1 7.10: 83M Cabal_HWT8QvVfJLn2ubvobpycJY 3.7Marray_FaHmcBFfuRM8kmZLEY8D5S 52M base_I5BErHzyOm07EBNpKBEeUv 56M bin 2.9Mbinar_EKE3c9Lmxb3DQpU0fPtru6 832Kbinpa_JNoexmBMuO8C771QaIy3YN 5.7Mbytes_6vj5EoliHgNHISHCVCb069 11M conta_47ajk3tbda43DFWyeF3oHQ 432Kdeeps_FpR4obOZALU1lutWnrBldi 912Kdirec_3TcTyYedch32o1zTH2MR00 796Kfilep_5HhyRonfEZoDO205Wm9E4h 113Mghc_EMlWrQ42XY0BNVbSrKixqY 2.9Mghcpr_8TmvWUcS1U1IKHT0levwg3 8.9Mhaske_IlDhIe25uAn0WJY379Nu1M 3.4Mhoopl_JxODiSRz1e84NbH6nnZuUk 1.1Mhpc_CmUUQl5bURfBueJrdYfNs3 1.3Minteg_2aU3IZNMF9a7mQ0OzsZ0dS 1.8Mprett_7jIfj8VCGFf1WS0tIQ1XSZ 764Kproce_0hwN3CTKynhHQqQkChnSdH 1.7Mrts 19M templ_BVMCZyLwIlfGfcqqzyUAI8 1.4Mtermi_7qZwBlx3clR8sTBilJl253 6.2Mtime_Hh2clZW6in4HpYHx5bLtb7 7.3Mtrans_ALYlebOVzVI4kxbFX5SGhm 5.4Munix_G4Yo1pNtYrk8nCq1cx8P9d -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768083.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
How much of this might be attributable to longer linker symbol names? Ghc 7.10 object code does have larger symbols! Is there a way to easily tabulate that? On Apr 1, 2015 9:40 AM, Jeremy volderm...@hotmail.com wrote: Roman Cheplyaka-2 wrote I'm not denying (or confirming) your claim, but it would look more legitimate if you compared the same version of Cabal compiled with different versions of GHC. At least some of this bloat could be because Cabal simply gained more code. I was going to prove you wrong by identifying packages which have barely changed for 7.10 ... and found that those packages were a similar size to their 7.8 versions. However, the size increase in other packages is huge, and simply gained more code doesn't seem like an adequate explanation, with some package more than doubling. Here are the full results: 7.8: 34M Cabal-1.18.1.5 3.8Marray-0.5.0.0 50M base-4.7.0.2 52M bin 368Kbin-package-db-0.0.0.0 2.7Mbinary-0.7.1.0 5.4Mbytestring-0.10.4.0 9.4Mcontainers-0.5.5.1 196Kdeepseq-1.3.0.2 608Kdirectory-1.2.1.0 740Kfilepath-1.3.0.2 105Mghc-7.8.4 2.7Mghc-prim-0.3.1.0 8.7Mhaskeline-0.7.1.2 3.4Mhoopl-3.10.0.1 1020K hpc-0.6.0.1 556Kinteger-gmp-0.5.1.0 680Kpretty-1.1.1.1 684Kprocess-1.2.0.0 1.6Mrts-1.0 13M template-haskell-2.9.0.0 1.4Mterminfo-0.4.0.0 6.1Mtime-1.4.2 4.4Mtransformers-0.3.0.0 5.2Munix-2.7.0.1 7.10: 83M Cabal_HWT8QvVfJLn2ubvobpycJY 3.7Marray_FaHmcBFfuRM8kmZLEY8D5S 52M base_I5BErHzyOm07EBNpKBEeUv 56M bin 2.9Mbinar_EKE3c9Lmxb3DQpU0fPtru6 832Kbinpa_JNoexmBMuO8C771QaIy3YN 5.7Mbytes_6vj5EoliHgNHISHCVCb069 11M conta_47ajk3tbda43DFWyeF3oHQ 432Kdeeps_FpR4obOZALU1lutWnrBldi 912Kdirec_3TcTyYedch32o1zTH2MR00 796Kfilep_5HhyRonfEZoDO205Wm9E4h 113Mghc_EMlWrQ42XY0BNVbSrKixqY 2.9Mghcpr_8TmvWUcS1U1IKHT0levwg3 8.9Mhaske_IlDhIe25uAn0WJY379Nu1M 3.4Mhoopl_JxODiSRz1e84NbH6nnZuUk 1.1Mhpc_CmUUQl5bURfBueJrdYfNs3 1.3Minteg_2aU3IZNMF9a7mQ0OzsZ0dS 1.8Mprett_7jIfj8VCGFf1WS0tIQ1XSZ 764Kproce_0hwN3CTKynhHQqQkChnSdH 1.7Mrts 19M templ_BVMCZyLwIlfGfcqqzyUAI8 1.4Mtermi_7qZwBlx3clR8sTBilJl253 6.2Mtime_Hh2clZW6in4HpYHx5bLtb7 7.3Mtrans_ALYlebOVzVI4kxbFX5SGhm 5.4Munix_G4Yo1pNtYrk8nCq1cx8P9d -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768083.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Carter Schonwald wrote How much of this might be attributable to longer linker symbol names? Ghc 7.10 object code does have larger symbols! Is there a way to easily tabulate that? That would explain why the hi files have also increased many-fold. Is there any way to avoid the larger symbols? -- View this message in context: http://haskell.1045720.n5.nabble.com/Binary-bloat-in-7-10-tp5768067p5768095.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
On Wed, Apr 01, 2015 at 02:30:49AM -0700, Jeremy wrote: Why do the 7.10 libraries take up so much more space than 7.8? For example, using the same build options and strip --strip-unneeded, 7.8 leaves me with That would be some kind of harsh april 1st joke, if everything compiled at that day gets a bloated data section by putting lots april strings into it. ;) Greetings, Daniel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
[Haskell] Haskell Weekly News
*Top picks:* - Bot attack on Trac https://mail.haskell.org/pipermail/ghc-devs/2015-March/008557.html pummels GHC HQ productivity! Do you know a thing or two about hardening web apps? Can you help? - A month ago http://haskell.1045720.n5.nabble.com/Haskell-Weekly-News-td5766529.html you read about the absence of a correct operational spec for Core. Christiaan Baaij http://ghc.haskell.org/trac/ghc/ticket/10121#comment:7 proffers rewriting rules for something very much like Core from his 2014 thesis on Digital Circuits in CλaSH, a tool designed for Computer Architecture for Embedded Systems (CAES). The consensus is that they probably also work for GHC Core. - Neil Mitchell reports Unable to load package Win32-2.3.1.0 https://ghc.haskell.org/trac/ghc/ticket/10165. The problem? SetWindowLongPtrW exists only on 64-bit. The haskell win32 shim wasn't switching to SetWindowLongW on 32-bit. Darren Grant steps up to offer a fix, which Austin Seipp promptly checks in. - Ki Yung Ahn http://haskell.1045720.n5.nabble.com/Do-we-have-idiom-for-lifting-a-state-monad-into-pair-of-states-td5767673.html asks for a wrapper that lifts actions of (State s1 a) to (State (s1,s2) a). The answer? A function called zoom in lens libraries. - Chris Done https://groups.google.com/forum/#!msg/commercialhaskell/lRTDiTLIKi0/Kw0UGwa4c0sJ has started the ball rolling on GPG-based package signing. So far, Michael Snoyman and Neil Mitchell have had their keys signed by Chris. He invites others to join the party. - Levant Erkok https://ghc.haskell.org/trac/ghc/ticket/10215 joins Lennart Augustsson https://ghc.haskell.org/trac/ghc/ticket/9238 in hitting a bug with signed zeros http://en.wikipedia.org/wiki/Signed_zero. The function isNegativeZero breaks under optimizations. - James Stevenson https://blog.safaribooksonline.com/2015/03/30/high-performance-log-parsing-in-haskell-part-one/ over at Safari Books Online reveals how they use Haskell to parse web logs more efficiently than Python. The top comment https://news.ycombinator.com/item?id=9294036 at Hacker News observes the absence of a proper benchmark pitting Python vs Haskell. James responds that they did an informal comparison that showed the number of lines parsed/second [with Python] was far smaller than the attoparsec-based parser. Elsewhere, Luke Randall http://www.reddit.com/r/haskell/comments/30xugp/highperformance_log_parsing_in_haskell_part_one/ submits the link on reddit and thinks it's a very gentle intro to parsing using attoparsec. - Ian Ross http://www.skybluetrades.net/blog/posts/2015/03/30/c2hs-snowmelt.html announces a new C2HS release christened Snowmelt. Originally authored by Manuel Chakravarty, C2HS eases the pain of manually creating FFI shims for C libraries. The latest release, thanks to work contributed by Philipp Balzarek, achieves better cross-language alignment of C enum and Haskell Enum types, among other improvements. Reddit discussion here. http://www.reddit.com/r/haskell/comments/30u8pk/new_c2hs_release_0251_snowmelt/ - Michael Snoyman https://www.fpcomplete.com/blog/2015/03/announce-ide-backend announces FPComplete's open sourcing of their IDE backend, comprising a wrapper around the GHC API. - Jon Sterling at PivotCloud https://ghc.haskell.org/trac/ghc/ticket/9539#comment:2 hits an STM TQueue bug initially reported by John Lato seven months ago. A sufficiently fast writer can cause the reader to never get scheduled, which leads to live-lock in Jon's production code. The fix looks to be as simple as lazifying a case into a let in readTQueue. Curiously, the code uses let in Simon Marlow's book on Haskell concurrency http://chimera.labs.oreilly.com/books/123000929/ch10.html#CO37-2 but not in the STM package you have on your machine. *Tweets of the week:* - Michael Neale https://twitter.com/michaelneale/status/567532684595851264: Haskell Quickcheck enters a bar, asks for 1 beer, 42 beers, -Inifinity beers, shaves bartenders beard, sets off a tactical nuke. - Dierk König https://twitter.com/mittie/status/582803534950862848: #Haskell is the gold standard for programming languages and #Frege makes it available on the #JVM -- Kim-Ee ___ Haskell mailing list Haskell@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell
Re: Binary bloat in 7.10
Yes, this does seem like a potential culprit, although we did do some measurements and I didn't think it was too bad. Maybe we were wrong! Edward Excerpts from Jeremy's message of 2015-04-01 07:26:55 -0700: Carter Schonwald wrote How much of this might be attributable to longer linker symbol names? Ghc 7.10 object code does have larger symbols! Is there a way to easily tabulate that? That would explain why the hi files have also increased many-fold. Is there any way to avoid the larger symbols? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
Re: Binary bloat in 7.10
Mind you I'm just trying to come up with theories we can test, I'm not assigning blame. :) I'm not sure how to do the apples to apples comparison, but it sounds like some sleuthing Is In order. I dont have a 7.10 setup yet, but if someone can put a tarballed dist build folder for a 7.10 and the same for 7.8 for some lib that blows up,I'm happy to try to dig i n. Or I'll get things setup later this week to do the full comparison locally. On Apr 1, 2015 11:12 AM, Edward Z. Yang ezy...@mit.edu wrote: Yes, this does seem like a potential culprit, although we did do some measurements and I didn't think it was too bad. Maybe we were wrong! Edward Excerpts from Jeremy's message of 2015-04-01 07:26:55 -0700: Carter Schonwald wrote How much of this might be attributable to longer linker symbol names? Ghc 7.10 object code does have larger symbols! Is there a way to easily tabulate that? That would explain why the hi files have also increased many-fold. Is there any way to avoid the larger symbols? ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
