Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 473 474 475 476 477 478 479 480 481 482 483 .. 5022
502,152 events total
2020-10-06 21:20:42 <pjb> You have to know all those processes, and mix and match them depending on your knowledge.
2020-10-06 21:20:49 <pjb> They are discovery processes.
2020-10-06 21:20:59 <pjb> If you know the algorithm you can just code it from a to z.
2020-10-06 21:21:26 <pjb> If you don't you need to design or explore, so writing code in all direction is possible.
2020-10-06 21:21:54 yar1 joins (~yar@185.163.110.116)
2020-10-06 21:22:38 <monochrom> For that reason, people used to advocate prototyping and then throwing away the prototype and restarting from scratch.
2020-10-06 21:23:24 <monochrom> I am really fond of that.
2020-10-06 21:24:00 <monochrom> But at some point of time, the next generation decided that they couldn't stand throwing away "hard-earned" code.
2020-10-06 21:24:57 × coot quits (~coot@37.30.49.218.nat.umts.dynamic.t-mobile.pl) (Quit: coot)
2020-10-06 21:25:04 <orzo> i'm having a frustration with cabal. The v2-configure command wants to download a version of a library that i already have installed that works perfectly well to build the project
2020-10-06 21:25:17 <orzo> I mean, it wants to download a newer version
2020-10-06 21:25:24 <orzo> but i want it to work with what's here
2020-10-06 21:25:31 <orzo> it seems like it should be working with what's here
2020-10-06 21:25:44 <orzo> because that's the path of least effort for it
2020-10-06 21:25:57 <monochrom> Ironically it was the new generation that could easily afford throwing away code wholesale, because they had much more decent VCS (compared to the older generation that believed in throwing away prototypes) such that "throwing away" means you never lost it, you could always refer to it again.
2020-10-06 21:26:30 wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2020-10-06 21:27:15 × Kaiepi quits (~Kaiepi@nwcsnbsc03w-47-55-225-82.dhcp-dynamic.fibreop.nb.bellaliant.net) (Remote host closed the connection)
2020-10-06 21:27:22 Kaiepi joins (~Kaiepi@nwcsnbsc03w-47-55-225-82.dhcp-dynamic.fibreop.nb.bellaliant.net)
2020-10-06 21:27:30 × takuan quits (~takuan@178-116-218-225.access.telenet.be) (Remote host closed the connection)
2020-10-06 21:27:35 <monochrom> You have to use "cabal freeze" to prevent bringing in a newer version.
2020-10-06 21:27:41 <orzo> aha
2020-10-06 21:28:11 <orzo> i use v2-* commands
2020-10-06 21:28:17 <orzo> does that mean i should have a v2-freeze?
2020-10-06 21:28:33 <monochrom> And if you use it later, e.g. now, the generated "cabal.project.freeze" likely selects the newer version, so you have to edit it to select the older version.
2020-10-06 21:28:33 <orzo> cabal 3.2
2020-10-06 21:28:40 × Kaiepi quits (~Kaiepi@nwcsnbsc03w-47-55-225-82.dhcp-dynamic.fibreop.nb.bellaliant.net) (Remote host closed the connection)
2020-10-06 21:28:45 <monochrom> 3.2 means the default is v2.
2020-10-06 21:29:38 Kaiepi joins (~Kaiepi@nwcsnbsc03w-47-55-225-82.dhcp-dynamic.fibreop.nb.bellaliant.net)
2020-10-06 21:30:07 <orzo> freeze doesn't work like i hoped
2020-10-06 21:30:15 <monochrom> There is probably also a way you first tell cabal "roll back your hackage index to this date in the past", and then your "cabal freeze" will be more meaningful in freezing the older version numbers you desire.
2020-10-06 21:30:23 <orzo> is there a way to just specify library versions directly?
2020-10-06 21:31:00 × wroathe quits (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net) (Ping timeout: 258 seconds)
2020-10-06 21:31:15 <orzo> i edited the cabal file to verify the installed library works
2020-10-06 21:31:18 <orzo> but i don't want to do that
2020-10-06 21:31:31 <monochrom> edit cabal.project.freeze ?
2020-10-06 21:31:52 <orzo> so i conigure, freeze, and then edit that to change the lib version?
2020-10-06 21:31:57 <sclv> new style encourages using the latest and rebuilding and freezing is the way to avoid that
2020-10-06 21:31:58 abhixec joins (~abhixec@c-67-169-141-95.hsd1.ca.comcast.net)
2020-10-06 21:31:59 <monochrom> yeah
2020-10-06 21:32:30 <sclv> but going with the nonfrozen latest stuff is a nicer workflow for me tbqh
2020-10-06 21:32:51 <orzo> this is all working around a bug in cabal though, right? I mean shouldn't the default behavior be to do what I want?
2020-10-06 21:33:15 <dminuoso> Mmm, I wish we had per-module dependencies. That way I could depend on some of the more nasty packages without pulling in a huge hunk of transitive dependencies if I only need one module.
2020-10-06 21:33:21 <monochrom> https://xkcd.com/303/ applies
2020-10-06 21:33:34 <monochrom> No, this is considered a feature.
2020-10-06 21:34:34 <orzo> My rationale is "do as little as neccessary to get it to build." What is the rationale for the default behavior?
2020-10-06 21:34:42 <monochrom> I liked the v1 way, too. But I have accepted v2 and accepted that I would need to freeze, and I would need to do that early enough.
2020-10-06 21:35:14 <monochrom> "get as many latest bugfixes as possible"? I don't know.
2020-10-06 21:35:17 × leungbk quits (~user@2605:e000:1315:706:8785:470d:bc5b:c5f9) (Quit: ERC (IRC client for Emacs 28.0.50))
2020-10-06 21:35:49 <monochrom> Also, in v2, "configure" is highly redundant.
2020-10-06 21:36:36 <dminuoso> orzo: Btw, v2- without freezing style promotes using PVP bounds. So if your dependencies make large jumps, you're missing a bound.
2020-10-06 21:36:54 <dminuoso> If you have tight bounds, think of this as a feature, where you're getting bugfixes automatically
2020-10-06 21:36:56 <monochrom> Also, under v2 semantics, I would first let "build" have a go, so I see that it succeeds, before I use "freeze".
2020-10-06 21:36:56 × Kaiepi quits (~Kaiepi@nwcsnbsc03w-47-55-225-82.dhcp-dynamic.fibreop.nb.bellaliant.net) (Remote host closed the connection)
2020-10-06 21:37:03 Kaeipi joins (~Kaiepi@nwcsnbsc03w-47-55-225-82.dhcp-dynamic.fibreop.nb.bellaliant.net)
2020-10-06 21:37:50 <orzo> what's a pvp bound
2020-10-06 21:38:11 <monochrom> https://pvp.haskell.org/
2020-10-06 21:39:43 <dminuoso> orzo: If you pin versions using ^>=, then cabal will consider the specified version as the earliest compatible version, and allow any newer compatible version.
2020-10-06 21:39:53 <dminuoso> There's some tools to automatically generate these bounds
2020-10-06 21:40:03 <monochrom> "cabal genbounds" :)
2020-10-06 21:40:17 <monochrom> err gen-bounds
2020-10-06 21:40:38 × frdg quits (60e94035@pool-96-233-64-53.bstnma.fios.verizon.net) (Remote host closed the connection)
2020-10-06 21:42:33 <dminuoso> cabal has some lesser know features as well that complement the above notation, like the set notation for bounds
2020-10-06 21:42:52 <dminuoso> so you can specify `foo ^>= {1.1.1, 1.2, 1.4}
2020-10-06 21:42:59 × Rudd0 quits (~Rudd0@185.189.115.108) (Ping timeout: 256 seconds)
2020-10-06 21:43:17 <dminuoso> I think cabal gen-bounds generates >/<= bounds?
2020-10-06 21:44:04 <monochrom> IIRC yes, but equiv to ^>=.
2020-10-06 21:44:32 <dminuoso> Sure, ^>= is just more explicit about it. :)
2020-10-06 21:44:50 <dminuoso> And with the set notation, it makes it more clear what versions you have tested it with
2020-10-06 21:45:09 <monochrom> Actually I have only tried using gen-bounds for a *.cabal file that explicitly says "cabal-version: >= 1.10" or something, so it tries to be friendly to old syntax?
2020-10-06 21:45:22 jneira_ joins (~jneira@170.red-176-87-39.dynamicip.rima-tde.net)
2020-10-06 21:45:57 <monochrom> I mean, if you have "cabal-version: 4.2" it may very well take advantage of the new concise syntax.
2020-10-06 21:46:11 <monochrom> Ha, let me try.
2020-10-06 21:47:32 <dminuoso> I have a baby sleeping in a carrier, Im not gonna hack around on my dev machine since it has a clicky keyboard. ;)
2020-10-06 21:47:42 DataComputist joins (~lumeng@static-50-43-26-251.bvtn.or.frontiernet.net)
2020-10-06 21:47:53 <monochrom> Nah, it always outputs >= && < regardless of "cabal-version: 2.2"
2020-10-06 21:47:56 × jneira[m] quits (~jneira@80.30.101.206) (Ping timeout: 260 seconds)
2020-10-06 21:48:11 <monochrom> You need a mind-reading interface!
2020-10-06 21:48:48 <dminuoso> Emacs has that.
2020-10-06 21:48:52 <dminuoso> M-x mind-mode
2020-10-06 21:49:31 <dminuoso> https://xkcd.com/378/
2020-10-06 21:49:31 <monochrom> Such as the one in the movie "Firefox" in which the USSR invented a fly-by-thinking jet fighter, and the US asked Clint Eastwood to steal it. "But you have to think in RUSSIAN!"
2020-10-06 21:50:11 <dminuoso> Haha, I once saw a trailer of that movie.
2020-10-06 21:50:11 × jneira_ quits (~jneira@170.red-176-87-39.dynamicip.rima-tde.net) (Read error: Connection reset by peer)
2020-10-06 21:50:47 <dminuoso> It looked so awful
2020-10-06 21:50:52 jneira_ joins (~jneira@80.30.101.206)
2020-10-06 21:51:52 <monochrom> Firefox used to read your mind. Now it just really respects your privacy. >:)
2020-10-06 21:51:55 × st8less quits (~st8less@2603:a060:11fd:0:443c:d730:5d8c:f920) (Ping timeout: 240 seconds)
2020-10-06 21:52:18 <davean> but not your agency
2020-10-06 21:52:19 <dminuoso> http://calpaterson.com/mozilla.html
2020-10-06 21:52:35 <dminuoso> Firefox respects your privacy because it's not even on your machine.
2020-10-06 21:52:42 <monochrom> haha
2020-10-06 21:56:30 <orzo> what's the hot new browser steeling their share?
2020-10-06 21:56:37 <dminuoso> Chrome? :)
2020-10-06 21:56:58 <orzo> hm
2020-10-06 21:57:00 <dminuoso> Followed by Edge now.
2020-10-06 21:57:34 <dminuoso> Microsoft's new strategy of just *forcing* edge onto everybodies Windows machine repeatedly, and making it impossible to get rid of, seems to be paying off
2020-10-06 21:58:24 <monochrom> No, I think it is not that. Because Firefox users would not switch to Edge, whether Edge is based on Chrome or Microsoft's original rendering engine.
2020-10-06 21:59:35 <monochrom> Instead, it is not that the absolute number of Firefox users decreased, but that their percentage decreased, i.e., new users use Edge, Safari, or whatever it is on their new smartphones (definitely not Firefox).
2020-10-06 22:00:00 <monochrom> But I should stop.
2020-10-06 22:00:52 × albert_99 quits (~Albert@p200300e5ff0b5b39340e476afbaec452.dip0.t-ipconnect.de) (Quit: WeeChat 2.9)

All times are in UTC.