Repository navigation
modern vector support ranges #297
Description
Activity
i also welcome feedback from fellow CLC members on this
IMHO GHC from the oldest currently supported Ubuntu/Debian distributive is a reasonable bound, even for a very high-profile packages. It does not make much sense to stick to an obsolete platform, which does not get OS or GHC updates, but strive for the newest packages available.
So it is either GHC 7.10 or 8.0 these days. Probably even 8.0 is a safe bet, especially if there are no plans for a new release immediately :)
Reacted by Alexey Kuleshevich and Jens Peterseneither way a ~
rolling 5 majormost recent major versions of ghc as a norm to hold against as a rule of thumb sounds reasonable. (to be clear, i also did chime into the stack folks asking them to reprioritize supporting backpack because if it pays off the way i hope it does, i really want @lehins to be happy! massively happy )This would simplify maintenance burden a lot. 8.2 is my preference. If anyone has a problem with 8.2, I would say the reasonable thing is for them to update
@chessai yeah, i absolutely agree. I'd really like concrete evidence if possible of users writing new code where they can't have 8.2 or newer.
my conception of "rolling window" is more a lazy/gc-ing semantic for previous version support rather than eager. but same idea either way
I personally don't care so much about ghc version support as long as the last one is at least a few years old, so either 8.0 or 8.2 sounds fine with me. I usually drop support for older ghc if I run into a feature I want that is not provided by older versions. It seems like in this case
backpackis that feature. If that's the case I think the bigger blocker is the tooling. I truly have no idea what's the state of backpack is, so I can't judge on it. I know that stack doesn't support it yet, maybe someone will come along and will get it implemented I don't really know anything about.@cartazio Thank you for thinking of my happiness :D
Dropping support for older ghc will make me happy, cause we'll be able to get rid of crap load of CPP and start writing
pureinstead ofreturn:DSupporting 8.0 does not cause much trouble in my experience, but 8.2 is also fine (all my stuff is >= 8.6 anyways). However (and unfortunately), Backpack may be a real blocker for adoption in enterprise environment, unless there is a stable and mature support in
stackby the time of a newvectorrelease.Reacted by Alexey Kuleshevich@Bodigrim you should yell at your enterprise support provider for stack. .... or just not use stack if they're not supporting enterprise :)
but seriously: enterprise support is usually code for someone is being paid to make sure tools work, if so, please open a ticket through your support vendor to help them prioritize itto be clear, i've not finished the backpack experiment, but if it pans out, i'm trying to make sure blockers for wide use are as few on the ground as possible. (I did see some mention that there were bug fixes in backpack post 8.2, but i'm not far enough along to see where i get stuck if at all)
My preference is to not support anything before GHC 8.0. The reasons I've heard for people using old versions of GHC are: (a) the List functions having bad Foldable types is bad for education (b) people in certain university settings are not allowed to update software on computers. I consider both of these compelling reasons for not using a newer GHC. However, people in either of these situations are unlikely to benefit from newer releases of
vector. So, I think it's reasonable to drop support going forward. Same story withprimitive.I personally use GHC 8.6.5 or GHC 8.8.2 for everything. I am unable to use anything before GHC 8.6 since
UnboxedSumswas broken before then, and I useUnboxedSumsrather aggressively in several libraries that I use.In my professional opinion, there are a lot more serious issues in vector that should be receiving attention. Testing is one of them, addition of many useful functions is another. The list of issues is pretty extensive.
Backpack doesn't really buy as anything important except more headache. It might be a good direction to go in the future, but this future is certainly not here yet.
There isn't anything in the code that requires us to drop support for old ghc versions, in fact it would add more work, but on the up side addition of new functionality would become easier.
- Agreed, before any thing like backpack could be deemed suitable for a genuine release we need much more robust testing and coverage. Happily we can run that test suite on recent ghc at 02 sanely now and have it even be in ci.…On Mon, Feb 3, 2020 at 4:01 PM Alexey Kuleshevich ***@***.***> wrote: In my professional opinion, there are a lot more serious issues in vector that should be receiving attention. Testing is one of them, addition of many useful function is another. The list of issues is pretty extensive. Backpack doesn't really buy as anything important except more headache. It might be a good direction to go in the future, but this future is certainly not here yet. There isn't anything in the code that requires us to drop support for old ghc versions, in fact it would add more work, but on the up side addition of new functionality would become easier. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#297?email_source=notifications&email_token=AAABBQTBU5HF5AM4NLZIA2TRBCA2ZA5CNFSM4KPLDF72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKVMFCA#issuecomment-581616264>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBQV7TSWEACATJJLLD53RBCA2ZANCNFSM4KPLDF7Q> .Reacted by Alexey Kuleshevich
@cartazio It is kinda vicious circle:
stackdoes not support Backpack (forgive me if I'm wrong here) because ultimately there is low demand, and demand is low because there are only few Backpack packages, and package writers avoid Backpack because it is not supported by tooling.I personally would love to use Backpack without thinking twice and find current situation sub-optimal, but... Happy to chat what Backpack can improve in
vector.I agree that enterprise can potentially afford to hire someone to implement Backpack support in
stack, or forkstack, or forkvector, or fork GHC :P Am I thrilling to present these options to my management tomorrow? Not really.Hence why I chimed in on that stack thread to help make sure there’s a push for concrete actions to be taken
Price of support of old compilers is paid in
#ifdefs. So what is this price in vector's case. Quick grep shows:1 (4,6,0) 13 (4,8,0) < 7.10 10 (4,9,0) < 8.0 2 (4,12,0) 1 (4,13,0)Look like we can drop 90% of CPP if start supporting GHC>=8.0. Dropping old GHC looks like really good idea.
Regarding stack and backpack. In principle vector could be able to force backpack support in stack. Whole process will be extremely unpleasant for everyone involved.
At this point we could experiment with backpack at most. We don't have good idea how it should be used. I'm not sure that bringing rather experimental feature into foundational library is right thing. We could run into all sort of obscure corner cases.
@Shimuuar thats what experimenting is for, i'm not gonna say "lets merge it" unless the win is EPIC.
but i dont want to be stuck sitting on what might be great improvements because release constraints are not pipelined ahead of time, hence why i'm starting all these discussions in the clear ahead of time so that we understand the ramifications of our choices.
Either way, I think we're all comfortable with dropping pre 8.0, or even pre 8.2 if the details and motivations lineup. Theres absolutely a few design experiments we need take the time to play with and feel good about, plus various tooling maturity goal posts that we should gate these releases on (eg, better HPC flavored coverage, robustness of optimizations, etc etc)
i think we're all on the same page about the balance of considerations. Though i really would love any different perspectives that we're overlooking.
(like, is there some user base or contributor population who we're overlooking and or ignoring!). If someone feels thusly, i do warmly welcome their constructive feedback/perspective on this thread or via email or something.
also, as a meta remark, i'd really like to highlight how pleasant and productive communication has gelled out to be on the vector issue over the last week. (yay)
Let's drop everything below 8.0 in the next release.
I bringing this issue up again. Support of
unsafeCoerceVectorfractures API for older GHC since there's no Coercible for GHC < 7.8. Choice here is to either CPP witchcraft or just dropping old GHC.To recapitulate. Using criterion: support GHC shipped by stable linux distros we should support at least 7.10. (AFAIR it's same support range as random 1.2). What are notable changes that required CPP'ing around them
- 7.8: polykinded Typeable, addition of roles and Coercible
- 7.10: changes to Foldable, new data types in base
Dropping support for everything before 7.10 will allows us to drop most of CPP
I am all for dropping support for anything below
ghc-7.10and possibly even belowghc-8.0, if that is also really beneficial for simplification.AFAIR it's same support range as random 1.2
Correct
So it seems we're in general agreement. Let then drop 7.8 and older. Should we decide to drop 7.10 later it wouldn't be difficult
Reacted by ˌbodʲɪˈɡrʲim- Sounds like a reasonable and conservative plan. For code that mixes unboxed float and double in the generated core, I think 7.6 and 7.8 are totally broken in how they do register allocation and I believe the fix was introduced in 7.10.3, though I wasn’t able to find the info about this to confirm my recollection when I looked a few weeks ago. (Happily mixing float and double in the same procedure is very rare in Haskell code so it had surprisingly little net impact…On Sun, Jun 14, 2020 at 12:23 PM Aleksey Khudyakov ***@***.***> wrote: So it seems we're in general agreement. Let then drop 7.8 and older. Should we decide to drop 7.10 later it wouldn't be difficult — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#297 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAABBQU7QUJB5XUDSY6HAM3RWT2O3ANCNFSM4KPLDF7Q> .
I've checked what is difference between supporting 7.10 and 8.0. There isn't much:
Unboxinstances for data types added intobasein 8.0 andEq1, etc instance forVector. It doesn't seem to be much of a problemI'm in favor of saying that we're supporting GHC>=7.10 and closing this issue. There're LTSes which ship 7.10 and it's consistent with random
the reason why vector has maintained such a long support window for as long as it has is largely because we literally couldn't robustly run CI on new ghc versions. That part is fixed by some fantastic insights by @lehins
Theres a limit to the CPP a project can support. (while travis CI helps a huge amount, it does burn folks out, we all miss Tibbe on containers* land). For small, low surface area projects, its pretty easy to support a huge range in perpetuity, eg https://hackage.haskell.org/package/monad-ste is one i wrote a while ago that i doubt will need an update in the next decade unless ghc changes in strange new ways :).
also, we genuinely aren't in the know about what ghc version ranges are genuinely being used outside of CI contexts.
So i did some research
(@juhp is the hero for those folks in the enterprise ). Plus i'm genuinely unaware of any haskell engineering teams in those environments that dont use newer ghc versions than the one shipped by default in the distro for active development
(perhaps @simonmar or @Bodigrim or @juhp know of any? whether in their own work or via conversations with others, whats the oldest ghc they know folks actually currently use to ship the end applications?)
bsds'
openbsd ports tree has had the ghc ports tree version be >= 8.4 since 2018 (and they dont support versions more than 12 months)
free bsd ports has had >= 8.4 since June 2018, and all releases from before then are past their end of life threshold., though @raichoo can perhaps add some color
debians
*looking at debian, the oldest long term support release thats still going to have distro support in 6 months is https://wiki.debian.org/LTS debian 9 (buster), which ships with ghc 8.0, though via http://downloads.haskell.org/debian/, 8.6 and 8.8 ghc versions are available.
buntos
on ubuntu the oldest flavor that has any sort of support atm is TrustyTahr (though i could be reading this wrong). Though if i'm reading it correctly, https://ubuntu.com/about/release-cycle, then thats more of a commercial security updates offering.
Xenial seems like the oldest LTS that gets more than security updates, and thats defaulting to 7.10,, though again the @hvr ppa's provide every ghc version under the sun 7.0 - 8.10.
in early 2021, it looks like the oldest ubuntu flavor that will be getting non security flavored updates will be BIONIC BEAVER, which starts with 8.0 by default
This is all of course ignoring the hvr PPAs supporting all of these
zooming out
ultimately: what is the oldest ghc that is deliberately used by haskell devs/teams/etc to build and deliver executables in 2020, for actively developed code or updating preexisting applications? (because, old version of vectors will still exist, as will those older ghc versions, for those who need to do archaeology or bootstrapping through time and space)