Profile

Cover photo
Bryan O'Sullivan
2,118 followers|127,107 views
AboutPostsPhotosYouTubeReviews

Stream

Bryan O'Sullivan
moderator

Discussion  - 
 
The optparse-applicative package is really cool, but made vastly more difficult to use by fragmented, incomplete documentation.

Riddle me this: if you're not the author of the package, can you find out, in less than 5 minutes, how to specify a default value for an option if none is supplied on the command line? I've provided a link to the documentation to, uh, help.
Source · Contents · Index. optparse-applicative-0.8.0.1: Utilities and combinators for parsing command line options. Safe Haskell, Safe-Inferred. Options.Applicative. Contents. Applicative option parsers; Exported modules. Synopsis. module Control.Applicative; module Options.Applicative.
4
Aristid Breitkreuz's profile photoAlp Mestanogullari's profile photoJohn Wiegley's profile photoAndrew Cowie's profile photo
12 comments
 
+John Wiegley no. That's what's annoying.
Add a comment...

Bryan O'Sullivan
moderator

Announcement  - 
 
New versions of text, attoparsec, and aeson!

Now you can enjoy UTF-8 encoding that is up to 4 times faster than before, and JSON encoding and decoding that are up to twice as fast. Not a bad way to start 2014!
48
5
Sergei Trofimovich's profile photogeorge oloo's profile photoHideyuki Tanaka's profile photoDmitry Ulanov's profile photo
2 comments
 
+Bryan O'Sullivan  in the changelog/announcement you might want to mention that the encoding of Rationals has changed from a number to an object:

https://github.com/bos/aeson/commit/ba3363d5ac5acfb7ece1cf8d646f68cba3988655
Add a comment...

Bryan O'Sullivan
moderator

Announcement  - 
 
Well, it's about time I tagged some Haskell package with a 1.0 version. In this case, it's the now sorta venerable text package. Enjoy!
1.0.0.0 * Added support for Unicode 6.3.0 to case conversion functions * New function toTitle converts words in a string to title case * New functions peekCStringLen and withCStringLen simplify interoperability with C functionns * Added support for decoding UTF-8 in stream-friendly fashion ...
30
Michał J Gajda's profile photo
 
Is it just because you don't want to change API anymore? :-D
Since it was included in a supposedly stable HP for a long time...
Add a comment...

Bryan O'Sullivan

Shared publicly  - 
 
A few days ago, +Aleksey Khudyakov wrote an interesting blog post about criterion's measurements. Here's what I found when I dug in.
15
1
Roshan James's profile photoSergei Trofimovich's profile photo
 
FWIW, I have seen the same thing occasionally with Core_bench. However I have never been able to isolate the effect enough to distill a predictor for it. 
Add a comment...

Bryan O'Sullivan

Shared publicly  - 
 
Blogged: more results for that fast new SipHash implementation I've been working on.
14
1
Ivan Miljenovic's profile photoDon Stewart's profile photo
 
Why did you start hacking on your own implementation rather than using the existing package?  Is it just that the version available at the time was too slow?
Add a comment...
In his circles
264 people
Have him in circles
2,118 people
David Fox's profile photo
Flavio Campos Medina's profile photo
E. Mustermann's profile photo
Simon “H Pisces” Weiss's profile photo
Curt Hoyt's profile photo
Liana Holmberg's profile photo
maria handry's profile photo
Jason Scotts's profile photo
Donna Aust's profile photo

Bryan O'Sullivan
moderator

Discussion  - 
 
My kingdom to whoever can cause Haddock to generate error messages better than the equivalent of "something went wrong lol kthxbai!"
8
Evan Laforge's profile photo
 
Doesn't the new version eliminate error messages entirely by making everything parse?  I suppose that means now you don't even get "something went wrong".
Add a comment...

Bryan O'Sullivan
moderator

Discussion  - 
 
Fun times with the text library: +Simon Meier has contributed a new Builder-driven UTF-8 encoder that is up to twice as fast as its predecessor if you have a sufficiently recent version of bytestring installed.

Not to rest on my laurels, I wrote a second new UTF-8 encoder that doesn't need the new bytestring infrastructure, and that is faster than Simon's on both very short inputs and non-ASCII text.

A little friendly competition is a good thing! Hopefully Simon will be spurred to improve his short-input performance, and I'll figure out why his encoder beats mine on ASCII inputs :-)
19
Bryan O'Sullivan's profile photoSimon Meier's profile photo
4 comments
 
Note that it would be easy to wrap this c-based encoder as a Builder provided it respects an end-of-input pointer. This wouldn't help for combined text encoding and escaping. However, it would help to speed-up encoding for binary formats like CBOR (http://tools.ietf.org/search/rfc7049), which Duncan Coutts is working on.
Add a comment...

Bryan O'Sullivan
moderator

Discussion  - 
 
Package dependency management: more debate is needed

You may have seen Greg's post from a few weeks ago (linked below), advocating a strict adherence to the Package Versioning Policy's guideline of specifying both lower and upper bounds when you're writing or modifying a .cabal file.

I'm completely sympathetic to Greg's desire to keep old code working. At the same time, as a maintainer of some core packages that are "upstream of everyone", I feel like Gulliver roped to the ground by the thousand tiny ropes of the Lilliputians: it's becoming increasingly difficult for me to get anything done.

For example, right now, I'm updating both the text library and a new library in lockstep. The new library has a test suite because I'm good like that, and the test suite depends on a chain of third party libraries that somewhere has an upper bound on an older version of text. If I want to make any progress, I have to do a lot of spelunking, local cloning of repos, and hand editing of fake package versions.

It's possible that I'm feeling this particularly keenly because I was, er, lucky enough to write libraries that everyone uses, but the day to day experience of trying to work in this world is a total pain. Not quite enough to make me give up, but I certainly have to expect a couple of hours of unnecessary misery here and there more or less any time I start on anything ambitious.

Perhaps one band-aid for people in similar positions would be to add a command line option to cabal-install to say "violate the dependencies if you have to". Perhaps there's a PVP policy that could be conjured up that better balances the needs of upstream and downstream authors. But the current situation sucks from where I stand, and I'd rather be using my now very limited time to write useful code instead of trying to come up with a more sustainable plan and build consensus around it.

So. All is not well in the ecosystem; and sticking with the status quo continues to be a bad idea; and I don't have the time or the energy to be the one to fix this. Sorry.
24
1
Michał J Gajda's profile photoChris Dornan's profile photoPhilipp Schuster's profile photoSergei Trofimovich's profile photo
28 comments
 
A new major version means that the API of a package has changed in a way that might break dependent packages. But sometimes (often?) dependent packages work with this new API just fine. Why is that? Because they use a part of the API that hasn't changed at all? If so, shouldn't we track dependencies not on entire packages but on individual declarations? How common (in your experience) is it that a declaration changes? How often can the new declaration be used as a drop-in-replacement?
Add a comment...

Bryan O'Sullivan
moderator

Discussion  - 
 
Throw an exception if you dislike the API of System.Environment.getEnv!
17
Ben Millwood's profile photoChip Salzenberg's profile photoJohn Millikin's profile photo
37 comments
 
+Chip Salzenberg Int doesn't have a 2^29 limit; it has a compiler- and machine-specified limit that must be at least 2^29.

Concerns about running Haskell on a non-IEEE754 machine don't seem very serious. We could just implement IEEE754-compliant math in the runtime with integers.
Add a comment...

Bryan O'Sullivan

Shared publicly  - 
 
Suppose we have a family of different container types. For instance, a packed array, linked list, and finger tree representing a sequence.

These containers are isomorphic from the perspective that converting between them loses no information about either the values contained or their ordering with respect to each other.

If we take some containers, filled with identical contents, should they hash to the same value? My instinct is to say "yes", but I can't think of any principled reason why this should be the case.

(And at least in Haskell, it would be somewhat annoying to make it true.)
1
Ben Millwood's profile photoEric Hopper's profile photoMarco Devillers's profile photoDan Burton's profile photo
13 comments
 
Here's my question: why are you hashing them in the first place? What does the hash function mean? If the purpose of the hash is specifically to check if the contents of two different containers are the same, then sure. If not, then does it really matter?
Add a comment...

Bryan O'Sullivan

Shared publicly  - 
 
A little work-in-progress of a new SipHash implementation in pure Haskell. Numbers on the Y axis are speedups relative to the C-based FNV-1 implementation in the hashable package. The green bar represents the existing siphash package.
11
Ketil Malde's profile photoBryan O'Sullivan's profile photoVincent Hanquez's profile photo
5 comments
 
Even if that end up duplicated in two different places, I think that still make sense to have the same implementation. Anyway I'll have a look later at your implementation, and might try some further optimisations. I thought of some quite intrusive one, but didn't have time to try them yet.
Add a comment...
People
In his circles
264 people
Have him in circles
2,118 people
David Fox's profile photo
Flavio Campos Medina's profile photo
E. Mustermann's profile photo
Simon “H Pisces” Weiss's profile photo
Curt Hoyt's profile photo
Liana Holmberg's profile photo
maria handry's profile photo
Jason Scotts's profile photo
Donna Aust's profile photo
Links
Basic Information
Gender
Male
I was introduced to Scott and Charlie of Elevation by a friend who's known Charlie for a long time. I met them at a demo day at China Camp, where Charlie spent a few minutes tweaking my bike to run better just for fun (and for free!). Since then, I've dropped my bike into them for service and had a fantastic experience. They are very friendly, knowledgeable, and non-pushy, so simply excellent people to do business with.
Public - 8 months ago
reviewed 8 months ago
1 review
Map
Map
Map