September 2016 - Haskell-Cafe

Munich Haskell Meeting, 2016-09-26 @ 19:30
by Christian Neukirchen 23 Sep '16

23 Sep '16

Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, September 26 at *Max-Emanuel-Brauerei* at 19h30. For details see here: http://muenchen.haskell.bayern/dates.html If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-sep-2016/ *Please add yourself quickly so we can get enough places.* Everybody is welcome! cu, -- Christian Neukirchen <chneukirchen(a)gmail.com> http://chneukirchen.org

1 0

Understanding fgl's gfiltermap
by J. Stutterheim 23 Sep '16

23 Sep '16

Hi all, While playing with the fgl library [1] (git rev. 71b66d6), I encountered a situation where the library behaved different from what I expected. I now wonder whether I should adjust my expectations, or whether fgl has a bug. What I want to do is filter out nodes and edges based on edge labels. For a specific edge label l, if a node has an incoming or outgoing edge l it can stay, otherwise I want to remove it from my graph. Likewise, any edge that doesn't have label l needs to be removed from my graph. I wrote a program to do this using gfiltermap, but I got the wrong graph as a result. During debugging, I found that gfiltermap behaved differently from what I would expect. Take the following program: ```haskell {-# LANGUAGE TupleSections #-} module Test where import Debug.Trace import Data.Graph.Inductive main :: IO () main = prettyPrint test test :: Gr () () test = gfiltermap (Just . traceShowId) testGraph where {- - ASCII art representation of the graph: - - 1 <-4<-- 2 - /\ -/| - \ / - \3\/_ -} testGraph = mkGraph testNodes testEdges where testNodes = map (,()) [1, 2, 3, 4] testEdges = [ (2, 4, ()) , (4, 1, ()) , (2, 3, ()) , (3, 1, ()) , (3, 2, ()) ] ``` This simple program just reconstructs the original graph, but prints the contexts in the process. When it's done, it pretty prints the resulting graph. The debug tracing + pretty printing gives the following output (in that order): ([((),3),((),4)],1,(),[]) ([((),3)],2,(),[((),3),((),4)]) ([],3,(),[]) ([],4,(),[]) 1:()->[] 2:()->[((),3),((),4)] 3:()->[((),1),((),2)] 4:()->[((),1)] The pretty-printed graph correctly shows that there is an edges going from node 4 to node 1. However, the traced output shows node 4 (last line of trace output) with no successors and no predecessors. I would expect nodes 1 and 2 to be included in that tuple as the successor and predecessor in that tuple. Note that these two representations of the same graph _are_ isomorphic. Despite the isomorphism, this makes implementing my graph filter significantly more clumsy than I would like it to be. So my question is: are my expectations from the library wrong, or is this a bug? - Jurriën [1] https://hackage.haskell.org/package/fgl

2 1

The meaning of categories constructed from HASK
by Dimitri DeFigueiredo 23 Sep '16

23 Sep '16

In category theory, there are many ways one can make new categories out of an old one. In particular, given a category C one can construct: 1. The arrows category of C: arrows in C become objects and commutative squares in C become arrows 2. The slice category of C given an object A: arrows into a distinguished object A become objects in the slice commutative triangles become arrows There are also functors going from C to these new categories (and back). Are these constructed categories useful when C = `Hask` (the category of haskell types and functions)? What do they represent in programming terms? In other words, is there intuition for what the arrows category of Hask is? What about the slice category of Hask over a specific type? Do the functors between these match some programming abstractions? Any pointers are much appreciated. Thanks, Dimitri

2 1

MPTCs and extended defaulting
by Tom Murphy 22 Sep '16

22 Sep '16

I've got a case in a library I'm working on where having -XExtendedDefaultRules with MPTCs would be very, very helpful. Is it possible? I.e., we can now write: ``` {-# LANGUAGE ExtendedDefaultRules #-} data AB = A | B Double deriving (Show) class Foo x where foo :: x -> AB instance Foo Double where foo = B main = print $ foo 5 ``` And -XExtendedDefaultRules makes sure we don't need to write "5 :: Double" If, though, I want 'Foo' to take another parameter (here, a :: [Symbol]), it falls apart: ``` {-# LANGUAGE DataKinds #-} {-# LANGUAGE ExtendedDefaultRules #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} import GHC.TypeLits data AB = A | B Double deriving (Show) class Foo x (a :: [Symbol]) where foo :: x -> AB instance Foo Double a where foo = B main = print $ foo 5 ``` Is there a reason MPTCs can't support ExtendedDefaultRules? Thanks! Tom

2 4

PLDI 2017 call for papers
by Tobias Grosser 21 Sep '16

21 Sep '16

*Call for Contributions* ==================== 2017 ACM Conference on Programming Language Design and Implementation (PLDI) June 19-23, 2017 in Barcelona, Spain http://conf.researchr.org/home/pldi-2017 PLDI is the premier forum in the field of programming languages and programming systems research, covering the areas of design implementation, theory, applications, and performance. PLDI welcomes outstanding research which clearly advances the field and has the potential to make a lasting contribution. *Important Dates* =============== Research paper submissions due 15 Nov 2016 Author response period 26-28 Jan 2017 Author notification 13 Feb 2017 *Author Instructions* ================== http://conf.researchr.org/track/pldi-2017/pldi-2017-papers Submission site: https://pldi17.hotcrp.com/ *Organizing Committee* ==================== General Chair: Albert Cohen, INRIA, France Program Chair: Martin Vechev, ETH Zurich, Switzerland Workshops & Tutorials Chair: Aaron Smith, University of Edinburgh Publicity Chairs: Adrian Sampson, Cornell, USA Tobias Grosser, ETH Zurich, Switzerland http://conf.researchr.org/committee/pldi-2017/pldi-2017-organizing-committee -- Tobias Grosser

1 0

Standard package file format
by Harendra Kumar 20 Sep '16

20 Sep '16

I am starting a new thread for the package file format related discussion. >From a developer's perspective, the major benefit of a standard and widely adopted format and is that people can utilize their knowledge acquired from elsewhere, they do not have to go through and learn differently looking and incomplete documentation of different tools. The benefit of a common config specification is that developers can choose tools freely without worrying about learning the same concepts presented in different ways. Multiple formats flying around also create a psychological impression of complexity in the ecosystem for newcomers. If we have consistency there are better chances of attracting more people to the language ecosystem. I gather the following from the discussion till now: * We have cabal, YAML and TOML as potential candidates for a common package format which can additionally incorporate the concept of snapshots/package collections and potentially more extensions useful across build tools. * cabal has the benefit of incumbency and backward compatibility, it has shortcomings which are being addressed but it is still a format which is very specific to Haskell ecosystem. It is not a standard and not going to become one. We have to always deal with it ourselves and everyone coming to Haskell will have to learn it. * YAML (http://yaml.org/spec/1.2/spec.html) is standard and popular. A significant chunk of developer community is already familiar with it. It is being used by stack and by hpack as an alternative to cabal format. The complaint against it is that the specification/implementation is overly complex. * TOML (https://github.com/toml-lang/toml) is promising, simpler than YAML and is being used by a few important projects but is still evolving and is not completely stable. On a first glance it looks pretty simple and a lot of other tools use a similar config format. It is aiming to become a standard and aiming for a wider adoption. As a next step we can perhaps do an hpack like experiment using the TOML format. That way we will have some experience with that as well and get to know if there are any potential problems expressing the existing cabal files. More thoughts, opinions on the topic will help create a better understanding about it. -harendra

25 69

implement SOAP-based standard
by Olaf Klinke 18 Sep '16

18 Sep '16

Dear Haskellers, I am considering implementing the OPC XML DA standard [1] in Haskell. OPC XML DA is based on SOAP and is used for communicating with servers controlling hardware such as power plants. Currently the only open implementation known to me is PyOPC [2], which is based on an outdated Python libraries. However, Python seems not the nicest language for writing code that is devoid of bugs showing at runtime only. The OPC XML DA standard comes with a WSDL document (600 lines). There is a wsdl package on hackage, but it is incomplete. Can anyone share experience in implementing a webservice specified as WSDL? Actually, the client side would be enough for my purposes. That is, compose well-formed messages and parse the responses. Thanks, Olaf [1] https://opcfoundation.org/developer-tools/specifications-classic/xml-data-a… [2] https://libraries.io/pypi/PyOPC

2 1

New maintainer for HsOpenSSL
by Vladimir Shabanov 17 Sep '16

17 Sep '16

Hello, I would like to become a new maintainer for HsOpenSSL package. Package was last updated on January 6, 2015 and no new commits at https://github.com/phonohawk/HsOpenSSL since then. My pull request https://github.com/phonohawk/HsOpenSSL/pull/40 is waiting here for more than a year. And there are ten more ignored pull requests. I've mailed current maintainer https://github.com/phonohawk/ pho(a)cielonegro.org four months ago and received no answer. Since there are no other maintainers I want to become the one. Who am I? Developer of BazQux Reader which is a commercial Haskell application that uses HsOpenSSL 24x7 in its crawler. Will be glad to hear any suggestions or objections. If not, I'm planning to wait for a few weeks and ask Hackage admins for maintenance rights.

1 0

help wanted: hledger
by Simon Michael 17 Sep '16

17 Sep '16

Hey all, I believe hledger (http://hledger.org) is a useful project, with potential to be much better. I have more ideas and know-how than free time. By now the project has a fairly large surface area, such that I'm often avoiding it when I have only small chunks of time to work on something. So I'm putting out the call for help! I'm grateful for the occasional contributions over the last 9 years, and I would welcome more collaborators to share the work. That sounds appealing, right ? Really, this is a fun project, since you can use it to save money and time and build your wealth-accumulation skills. And as an active contributor, you will have access to free tutoring from a 9y haskeller, 20y consultant and FOSS developer, and 30y coder (that's me). Here are some particular areas needing help: - Release 0.28 (or should it be 1.0 ?) has been pending for a long time, partly because hledger, hledger-ui, hledger-web & hledger-api are released together. This is the number one priority at the moment. Also: - Integrate John Wiegley's ledger4 code as an additional parser, increasing our compatibility with Ledger, making hledger features more easily accessible to Ledger users. - Website beautification and marketing in general. - Contribute, solicit or raise funding, so we can sponsor developers/designers/minions, set meaningful issue bounties, etc. - UIs/integration for mobile/small-screen devices. - More import/export formats, easier migration to and from other tools. I hope you'll check out hledger and get involved. http://hledger.org -> Contribute Best! -Simon

1 0

Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10
by Nicu Ionita 17 Sep '16

17 Sep '16

Sorry, I forgot to answer to all... ------ Originalnachricht ------ Von: "Nicu Ionita" <nicu.ionita(a)acons.at> An: "Malcolm Wallace" <malcolm.wallace(a)me.com> Gesendet: 17.09.2016 09:12:30 Betreff: Re[2]: [Haskell-cafe] Very _very_ slow compiles on Windows 10 >Oh, this could be a good hint! I don't have other protection except >windows defender, which is own Windows AV. (Reviews suggest that this >should be enough, altough on other PC - not with Windows 10 - I use >different AVs) But maybe the Windows own AV exhibits the same >behaviour. I will check this, thanks! >Nicu > >------ Originalnachricht ------ >Von: "Malcolm Wallace" <malcolm.wallace(a)me.com> >An: "Nicu Ionita" <nicu.ionita(a)acons.at> >Cc: "haskell-cafe(a)haskell.org" <haskell-cafe(a)haskell.org> >Gesendet: 17.09.2016 08:44:30 >Betreff: Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10 > >>Do you have Symantec Endpoint Protection or similar antivirus? We >>found that under certain paranoid settings, even "ghc --version" >>took upwards of seven seconds, and compilation was slowed by a couple >>of orders of magnitude. We think the AV was scanning the (large) >>compiler binary, plus any DLLs it loads, plus the source, interface, >>and object files read and generated, On every invocation. Linking was >>absolutely dog slow. We also think the AV was deliberately throttled >>to never use more than 10% of CPU time, to avoid being noticeable to >>the user. >> >>It is possible that there are AV settings you can tweak to avoid the >>paranoia, and trust the compiler, and any other file that has already >>been scanned once. >> >> Regards, >> Malcolm (iPhone) >> >>On 17 Sep 2016, at 07:04, Nicu Ionita <nicu.ionita(a)acons.at> wrote: >> >>No virtualisation, it is a dual boot maschine. >>1 CPU would be good :-) In my case it is a very small fraction of it. >>Nicu >> >>------ Originalnachricht ------ >>Von: "A.M." <agentm(a)themactionfaction.com> >>An: haskell-cafe(a)haskell.org >>Gesendet: 17.09.2016 03:20:38 >>Betreff: Re: [Haskell-cafe] Very _very_ slow compiles on Windows 10 >> >>>On 09/16/2016 06:10 PM, Nicu Ionita wrote: >>>> Is anybody else experiencing really slow compilations with GHC >>>>7.10.2 on >>>> Windows 10? >>>> >>>> I use stack to compile the project and run it under a mingw64 >>>> environment provided by Github bash. The CPU usage is very low all >>>>the >>>> time (meaning: GHC does barely use the CPU). On same computer with >>>> Ubuntu 16.04 it just compiles normally, but under Windows it is for >>>>sure >>>> 10x slower, maybe even more. >>> >>>Are you using virtualization? I see the same thing under virtualbox >>>on >>>Ubuntu. Specifically, even after allocating 12 real CPUs to the VM, I >>>never see stack-invoked ghc use more than one CPU. On rare occasions, >>>the linker phase hangs. I have confirmed that ghc reports 12 >>>capabilities. >>> >>>I'm just glad that Windows is not my primary development platform; >>>it's >>>entirely possible that virtualization is the cause. VirtualBox is not >>>known for being a speed demon, but the compilation speed is indeed >>>embarrassing. >>> >>>Cheers, >>>M >>> >>> >>_______________________________________________ >>Haskell-Cafe mailing list >>To (un)subscribe, modify options or view archives go to: >>http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>Only members subscribed via the mailman list are allowed to post.

1 1