{"action":"created","issue":{"url":"https://api.github.com/repos/SimonDanisch/FixedSizeArrays.jl/issues/159","repository_url":"https://api.github.com/repos/SimonDanisch/FixedSizeArrays.jl","labels_url":"https://api.github.com/repos/SimonDanisch/FixedSizeArrays.jl/issues/159/labels{/name}","comments_url":"https://api.github.com/repos/SimonDanisch/FixedSizeArrays.jl/issues/159/comments","events_url":"https://api.github.com/repos/SimonDanisch/FixedSizeArrays.jl/issues/159/events","html_url":"https://github.com/SimonDanisch/FixedSizeArrays.jl/issues/159","id":172998422,"number":159,"title":"StaticArrays","user":{"login":"SimonDanisch","id":1010467,"avatar_url":"https://avatars.githubusercontent.com/u/1010467?v=3","gravatar_id":"","url":"https://api.github.com/users/SimonDanisch","html_url":"https://github.com/SimonDanisch","followers_url":"https://api.github.com/users/SimonDanisch/followers","following_url":"https://api.github.com/users/SimonDanisch/following{/other_user}","gists_url":"https://api.github.com/users/SimonDanisch/gists{/gist_id}","starred_url":"https://api.github.com/users/SimonDanisch/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/SimonDanisch/subscriptions","organizations_url":"https://api.github.com/users/SimonDanisch/orgs","repos_url":"https://api.github.com/users/SimonDanisch/repos","events_url":"https://api.github.com/users/SimonDanisch/events{/privacy}","received_events_url":"https://api.github.com/users/SimonDanisch/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2016-08-24T16:23:53Z","updated_at":"2016-08-25T09:54:00Z","closed_at":null,"body":"I think there should be only one package for fixed size arrays ;)\r\nOf course I'm a bit biased towards FixedSizeArrays, since I'm more familiar with the code :D \r\n@andyferris @c42f, could you explain to me what would speak for StaticArrays?\r\nWhat were the initial motivations behind it?\r\nRight now the biggest things seem to be inheritance from DenseArray and already up to dateness with 0.5.\r\nThese could be brought to FixedSizeArrays with a rewrite. \r\n\r\nI'm trying to fix up [FixedArrayBench](https://github.com/SimonDanisch/FixedArrayBench.jl) with support for StaticArrays to further judge this.\r\nLast time, something wasn't working with 0.5 and BenchmarkTools.jl.\r\n\r\nBest,\r\nSimon"},"comment":{"url":"https://api.github.com/repos/SimonDanisch/FixedSizeArrays.jl/issues/comments/242335879","html_url":"https://github.com/SimonDanisch/FixedSizeArrays.jl/issues/159#issuecomment-242335879","issue_url":"https://api.github.com/repos/SimonDanisch/FixedSizeArrays.jl/issues/159","id":242335879,"user":{"login":"c42f","id":601473,"avatar_url":"https://avatars.githubusercontent.com/u/601473?v=3","gravatar_id":"","url":"https://api.github.com/users/c42f","html_url":"https://github.com/c42f","followers_url":"https://api.github.com/users/c42f/followers","following_url":"https://api.github.com/users/c42f/following{/other_user}","gists_url":"https://api.github.com/users/c42f/gists{/gist_id}","starred_url":"https://api.github.com/users/c42f/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/c42f/subscriptions","organizations_url":"https://api.github.com/users/c42f/orgs","repos_url":"https://api.github.com/users/c42f/repos","events_url":"https://api.github.com/users/c42f/events{/privacy}","received_events_url":"https://api.github.com/users/c42f/received_events","type":"User","site_admin":false},"created_at":"2016-08-25T09:54:00Z","updated_at":"2016-08-25T09:54:00Z","body":"Hi Simon, thanks for starting the conversation, we definitely need to sort this out as fragmentation is happening - we now have three(!) different fixed size packages (counting `ImmutableArrays` which was about the best that could be implemented in julia-0.3, and which several packages still depend on.)\r\n\r\nA bit of back story - as of a few months ago, I was slowly fixing the various problems with `FixedSizeArrays`, eg trying to fix the type promotion problems with map, etc. In the process I got frustrated with several design problems but I was just planning to plug along fixing things as they came up since I take fragmentation and API compatibility fairly seriously.  I guess I complained about the problems to Andy a bit, and he surprised me by writing an entire new package in a fit of productivity. With 0.5 imminent I've been persuaded to start using StaticArrays as a dependency in some places, simply because it fixes various API problems which I haven't had time to address in FixedSizeArrays, and also provides a cleaner implementation strategy for the future.  So there was no fragmentation planned, I'm bummed that we seem to have fallen into it, and I'm not yet sure how to dig ourselves out!  A common supertype would go a long way, but the packages as they stand are incompatible with doing that easily.\r\n\r\nTo summarize some frustrations I've had with `FixedSizeArrays` more specifically -\r\n* Obviously, the issue with subtyping `AbstractArray`.  I started fixing this a while back, but I just ran out of steam :-(  It seems doable though (Andy has done it!) so this could be pushed through if someone had time.\r\n* The API has various oddities which aren't consistent with `AbstractArray` in a duck-typing sense. A good example is the concatenating constructor `function (::Type{FSA}){FSA <: FixedArray, T1 <: FixedArray}(a::T1, b...)` - this makes sense in a glsl world, but is just different from `Base.Array` where you'd use `vcat` or something.  Another example is the string parsing vector constructor; this is just weird to me.  The nullary version of map() also seems strange; I preserved it through my map rewrite to avoid breaking people's code, but it's just an oddity.  To fix these issues I think some deprecations are required to get a tight focus on compatibility with AbstractArray semantics.\r\n* The tuple-of-tuples representation is really a pain to work with internally.  Unfortunately it seems *completely necessary* for good performance in 0.4 so it's nice to be able to make a clean break and ignore this in StaticArrays.  Dunno what we could do here other than make a big break at some stage in the FixedArray implementation.\r\n* Perhaps a small point, but I really don't like `FixedVectorNoTuple` as a name.  Andy has `FieldVector` which is better but perhaps there's something better still.  Again, fixable of course at the cost of some API breakage.\r\n* Somewhat confusing code structure: the way that methods are separated into files, I still find it hard to find things.  Totally fixable of course, it's just work for someone to go through and group functions more clearly.\r\n* Lack of clear documentation about where exactly the package is going and how to use the central features.  (I'm super guilty of this in some of my own packages, but it is a thing.)\r\n\r\nIn general, the code has/had a fair bit of one-off patching to make things work with a small set of sizes or given types, without working in the general case.  I think this is ok for graphics work because of the small number of shapes and types you typically use, but these things bite you *all the time* if you're doing general computation with FixedSizeArrays.  Especially with funny types like Duals etc, and larger matrix sizes.  I already fixed a lot of the type promotion problems, but I still find missing methods now and then.\r\n\r\n\r\nBtw, some possibly useful contributor statistics on current number of lines:\r\n```\r\n$ git ls-tree -r -z --name-only HEAD -- *.jl | xargs -0 -n1 git blame --line-porcelain HEAD |grep  \"^author \" | sed -e 's/\\(Sdanisch\\|SimonDanisch\\)/Simon Danisch/' | sort | uniq -c | sort -nr\r\n    678 author Simon Danisch\r\n    497 author Chris Foster\r\n    302 author mschauer\r\n     65 author Tim Holy\r\n     45 author Jan Weidner\r\n     34 author Andy Ferris\r\n     21 author Steve Kelly\r\n      4 author ScottPJones\r\n      4 author Jens Schleede\r\n      3 author Andrew Smith\r\n      2 author David Sanders\r\n```\r\n\r\n@mschauer any thoughts? You're the next biggest contributor."}}
{"actor":{"display_login":"c42f"}}