- Haskell-Cafe - Haskell.org

Unregisterised builds
by Jon Schneider 15 Aug '15

15 Aug '15

Good day all, I am still having issues with (the output from) the cross compiler I have built for PowerPC (e500 family). It seems the runtime is vaguely sane in that it's purposefully whirring round schedule() but for some reason for a "Hello World" allocates stack then heap (after ^C) then runs out then locks up but does not exit. I don't (yet) understand the runtime enough to find the boundary between behaving and not. /tmp # ./helloworld +RTS -Ds created capset 0 of type 2 created capset 1 of type 3 cap 0: initialised assigned cap 0 to capset 0 assigned cap 0 to capset 1 new task (taskCount: 1) cap 0: created thread 1 new bound thread (1) cap 0: schedule() cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (yielding) cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: allocating new stack chunk of size 32768 bytes cap 0: running thread 1 (ThreadRunGHC) cap 0: thread 1 stopped (stack overflow) cap 0: allocating new stack chunk of size 32768 bytes ... I have gone through the various +RTS flags but feel I'm going to have to use gdb some more. When using unregisterised to what extent does the compiler need to know about the target platform ? If I said ./configure --target none-of-your-business --with-gcc=my-whizzy-gcc --with-other-tools=... --enable-unregisterised would I be right in saying it this could not be done because it still needs to know things like the word size, endianness and so on or couldn't it get this information just from header files ? What I'm trying to get at is if I did not think there was anything wrong with my cross-gcc, partially because I have experimented with different versions and platforms, what other PowerPC-sepcific knowledge is employed by the unregisterised ghc ? Jon

2 1

Re: [Haskell-cafe] How to model outer space for a MUD
by Doug McIlroy 15 Aug '15

15 Aug '15

> I would not model space -- there's too much of it This lesson has hit home over and over again when people come to the realization that the "inner loop" of their program is unrelated to what the program is nominally doing, Most of the running time is initialization! doug

1 0

"Could not list sources" warning in sandboxed project with add-source deps
by Eric 15 Aug '15

15 Aug '15

I'm getting a warning > Warning: Could not list sources of the add-source dependency 'xyz'.> Skipping the timestamp check. when building a sandboxed project with add-source dependencies. I tried increasing the verbosity of cabal, but it still won't tell me what's going wrong so I can fix it. Any suggestions on how to debug or fix this? thanks,--Eric

2 4

Library for overloaded indexing (a la (!))
by William Yager 14 Aug '15

14 Aug '15

Hello all, I put together a small library for the purpose of creating overloaded indexing operators. The library is available at https://hackage.haskell.org/package/keyed . I would like to solicit some advice on the design of this library. Q1: The library uses TypeFamilies to determine which types to use for the index type (which is used to look up a value) and the value type (which is returned from a lookup). I originally did this using MultiParamTypeClasses and FunctionalDependencies, but thought this was cleaner; are there any good reasons to go back to using FunDeps? Q2: Data.Keyed provides pure indexing, while Data.MKeyed provides monadic indexing (e.g. for mutable vectors or concurrent STM-based maps). I'm having some trouble with the fact that mutable vectors are keyed on the PrimState of their corresponding PrimMonad. Right now, there is a type in the MKeyed class definition called MContainer. This is the type of the Monad that the lookup operation returns. I.e. (!) :: MKeyed d => d -> MKey d -> MContainer d (MValue d) ~ (!) :: IOVector a -> Int -> IO a or (!) :: STVector s a -> Int -> ST s a Unfortunately, this causes an overlap (because both IOVector and STVector are aliased to MVector). I tried making an instance for MVector, but the problem is that it's difficult to actually go from `IOVector a = MVector RealWorld a` to `IO` or `STVector s a = MVector s a` to `ST`, because neither `IO` nor `ST` appears in the type of the vector. I can't do instance (PrimMonad m, s ~ PrimState m) => MKeyed (MVector s a) where ... type MContainer (MVector (PrimState m) a) = m because you can't have type synonyms on the LHS of the type. I tried bringing `m` into scope using RankNTypes, but that didn't work. Is there some syntax I can use to bring `m` into scope here? Or should I be doing this part entirely differently? Q3: Is there any way to automatically derive all instances of Keyed for all types of Data.Vector (using Data.Vector.Generic)? Using `instance Vector v a => Keyed (v a) where ...` doesn't work, as it overlaps with everything of the form `(d :: * -> *) (a :: *) :: *`, like `[a]`. Thanks, Will

5 9

Folding part of a graph, and FGL's gfold function.
by Jeffrey Brown 14 Aug '15

14 Aug '15

Given a node N and an edge label L, I want to do things like "find N, and all of N's L-children, and all of their L-children ... and add up their values". Ideally the fold would not traverse the whole graph. (Note that in general, the subgraph induced by N and L-succession is not a tree.) Writing the fold myself, I can only imagine a very inefficient solution -- I would find each of N's L-children first, collect them, then find each of theirs, etc. In Data.Graph.Inductive.Basic, FGL provides a function called "gfold". This is its type signature: -- | Directed graph fold. gfold :: (Graph gr) => (Context a b -> [Node]) -- ^ direction of fold -> (Context a b -> c -> d) -- ^ depth aggregation -> (Maybe d -> c -> c, c) -- ^ breadth\/level aggregation -> [Node] -> gr a b -> c Is it what I'm looking for? If so, how does it work?

2 1

FGL: The cost and propoer way of changing the label at a node.
by Jeffrey Brown 13 Aug '15

13 Aug '15

Is changing the label at a node O(N)? The only way I can think of to do it is with a map, like the following -- which works, but seems like its speed must be linear in the number of nodes of the graph: > :m Data.Graph.Inductive.Example Data.Graph.Inductive.Graph > let f c@(adjIn, node, lab, adjOut) = case node of {1 -> (adjIn, node, 'b', adjOut); _ -> c} > loop mkGraph [(1,'a')] [(1,1,())] > gmap f loop mkGraph [(1,'b')] [(1,1,())] > Is that in fact the right way? Am I somehow missing the point of FGL if I have to do a lot of that?

2 4

Internship Opportunity at Galois: Winter/Spring 2016
by Ryan Wright 13 Aug '15

13 Aug '15

Galois has some exciting opportunities for interns in software research and engineering for the Winter/Spring of 2016. Most of our projects use Haskell to some extent, so this is a great chance to get experience applying functional programming to important real-world problems. Please pass along this posting to anyone you think might be interested--even if they don't yet know Haskell! Thank you, Ryan Wright # Galois Software Engineering/Research Intern # Galois is currently seeking software engineering and research interns for Winter/Spring 2016 at all educational levels. We are committed to matching interns with exciting and engaging engineering work that fits their particular interests, creating lasting value for interns, Galois, and our community. A Galois internship is a chance to tackle cutting-edge, meaningful problems in a uniquely collaborative environment with world-leading researchers. Roles may include technology research and development, requirements gathering, implementation, testing, formal verification, and infrastructure development. Past interns have integrated formal methods tools into larger projects, built comprehensive validation suites, synthesized high-performance cryptographic algorithms, written autopilots for quad-copters, designed the syntax and semantics of scripting languages, and researched type system extensions for academic publication. We deeply believe in providing comprehensive support and mentorship to all of our employees, particularly interns. We provide our employees with a steward who regularly checks in to ensure that they feel welcome and safe in the Galois community while gaining real value from their experiences. ## Important Dates ## Applications due: October 1st, 2015 Internship period (flexible): January through April, 2016 ## About Galois ## Our mission is to create trustworthiness in critical systems. We’re in the business of taking blue-sky ideas and turning them into real-world technology solutions. We’ve been developing real-world systems for over ten years using functional programming, language design, and formal methods. Galois values diversity. We believe that differing viewpoints and experiences are essential to the process of innovation. We look broadly, including outside of established communities, to deliver innovation. ## How to Prepare ## An internship is an opportunity for learning and growth as an engineer. To make the most of the opportunity, we ask that candidates have experience reading, writing, and maintaining code in a realistic project. Many university courses involve multi-week collaborative projects that provide this type of experience. Most of our projects use the Haskell programming language and the git version control system. These tools aren’t often taught in computer science classes, but there are many free resources available that we recommend for learning: - [Learn You a Haskell] for Great Good! [1] by Miran Lipovača - [Real World Haskell] [2] by Bryan O’Sullivan, Don Stewart, and John Goerzen - [tryGit] [3] by Code School - [Pro Git] [4] by Scott Chacon [1]: http://learnyouahaskell.com/ [2]: http://book.realworldhaskell.org/ [3]: http://try.github.io [4]: http://git-scm.com/book ## Qualifications ## The ability to be geographically located in Portland during the internship Experience reading, writing, and maintaining code in a project as described above Proficiency in software development practices such as design, documentation, testing, and the use of version control Well-developed verbal and written communication skills; comfort in a collaborative team environment The following skills are not required, but may be relevant to a particular project. - Proficiency in Haskell or other programming languages with rich type systems (eg., OCaml, Standard ML, Scala) - Experience using C and assembly languages for low-level systems programming - Development experience in high assurance systems or security software - Specific experience in an area of Galois’ expertise, such as: - Assured information sharing - Software modeling and formal verification - Cyber-physical systems and control systems - Operating systems, virtualization and secure platforms - Networking and mobile technology - Cyber defense systems - Scientific computing - Program analysis and software evaluation - Web security ## Logistics ## The length and start date of the internship are negotiable: starting any time from the new year through next spring is acceptable, but an intern must be at Galois for at least three continuous months. The internship is paid competitively, and interns are responsible for living arrangements (although we can certainly help you find arrangements). Galois is located in the heart of downtown Portland with multiple public transportation options available and world-class bicycle infrastructure. ## Application Details ## We’re looking for people who can invent, learn, think, and inspire. We reward creativity and thrive on collaboration. If you are interested, please send your cover letter and resume to us via http://galois-inc.hiringthing.com.

1 0

Standards-conform CSS tokenizer
by Tomas Carnecky 13 Aug '15

13 Aug '15

Recently I wrote a CSS tokenizer based on the css-syntax spec (the same standard that Blink now uses to parse CSS). The detailed description of my motivation is in the readme, but if I had to describe it in a sentence: The existing Haskell parsers were too high-level for me needs, they provided too much abstraction. The package does not implement the full parser, at least one token type is not implemented. But it should be able to tokenize most CSS files. I copied the tests from the Blink source. All but one pass (and of course the tests for the token types that are not implemented) While the spec describes the algorithm in a way that pretty much prescribes the implementation, I chose to use attoparsec instead. Not sure about the speed implications, but speed is not that important for me. The spec module also describes a parser. I did not have time to implement it, and am currently not planning to. But it would be nice if that was part of the package as well. I had hoped to be able to write a minimizer as well, but I'm not sure if it's possible to write a minimizer just on the token stream, maybe the full parser is needed for that. However, consecutive whitespace is collapsed so tokenizing and then serializing the file will in most cases lead to a smaller file. Hackage: http://hackage.haskell.org/package/css-syntax GitHub repo: https://github.com/wereHamster/haskell-css-syntax Spec: https://drafts.csswg.org/css-syntax

1 0

[ANN] base91
by Alvaro J. Genial 13 Aug '15

13 Aug '15

Howdy, I'd like to announce a first version of base91 <http://hackage.haskell.org/package/base91>, a Haskell package to enable the encoding and decoding of data in Base91 format, as documented in its specification <http://base91.sourceforge.net>. The main benefits of said scheme are a good reduction in overhead (from 31% up to 58%) when compared to Base64 due to the clever use of two printable ASCII characters (consuming 16 bits) to encode 13 arbitrary bits, as well as neither need for nor ambiguity over padding or alphabets. It includes support for... - Plain Strings (module Codec.Binary.Base91.String) - Data.ByteString (module Codec.Binary.Base91.ByteString) - Data.Text (module Codec.Binary.Base91.Text) - The latter two combined (module Codec.Binary.Base91.Efficient) - Data.ByteString.Lazy (module Codec.Binary.Base91.ByteString.Lazy) - Data.Text.Lazy (module Codec.Binary.Base91.Text.Lazy) - The latter two combined (module Codec.Binary.Base91.Efficient.Lazy) ...which are all just concretely typed versions of the generic implementation in Codec.Binary.Base91. I had fun exploring some of the latest GHC extensions, as evidenced by Codec.Binary.Base91.Control, which relies on a certain amount of type trickery to reconcile the incongruence between monomorphic containers and the standard type classes. Anyway, suggestions are very welcome. In particular, I'm interested in: 1. Whether the generic decode and encode signatures can be simplified or improved elsehow. 2. Whether there already exist classes similar in purpose to Applicative' and Foldable'. 3. Whether it makes sense to offer decode and encode variants that use lazy (left) folds--currently folding is always strict, even with lazy types. (Testing comes nearly free courtesy of QuickCheck and the identity property of decode . encode, plus a couple of concrete examples. Please open an issue or otherwise let me know if you find a bug.) Thank you, Alvaro <http://alva.ro>

4 5

HAL-10
by Pascal Wittmann 13 Aug '15

13 Aug '15

Hi there, I just wanted to ask whether I just missed this years HAL (Haskell in Halle/Leipzig) or if it was canceled this year. Cheers Pascal

2 1