Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 .. 5022
— 502,152 events total
2020-11-23 18:08:49 <shapr> xerox_: do you write code for a living?
2020-11-23 18:08:50 <xerox_> how about you?
2020-11-23 18:09:02 <shapr> I have a Haskell job, it's great fun!
2020-11-23 18:09:10 <shapr> I'm working for SimSpace
2020-11-23 18:09:37 → neiluj joins (~jco@91-167-203-101.subs.proxad.net)
2020-11-23 18:09:37 × neiluj quits (~jco@91-167-203-101.subs.proxad.net) (Changing host)
2020-11-23 18:09:37 → neiluj joins (~jco@unaffiliated/neiluj)
2020-11-23 18:09:40 → wroathe joins (~wroathe@c-68-54-25-135.hsd1.mn.comcast.net)
2020-11-23 18:09:57 <xerox_> looks like serious business
2020-11-23 18:10:46 <maerwald> I'm picking rust for a new project, but getting devs doesn't seem any easier than haskellers lol (unless you're a bank)
2020-11-23 18:11:00 <maerwald> so there's that
2020-11-23 18:11:15 → chaosmasttter joins (~chaosmast@p200300c4a72cf80165f6d709b523305b.dip0.t-ipconnect.de)
2020-11-23 18:11:26 × jonatanb quits (jonatanb@gateway/vpn/protonvpn/jonatanb) (Remote host closed the connection)
2020-11-23 18:11:54 <xerox_> shapr: so yeah I have been programming for a living but I'm not at this very moment in time
2020-11-23 18:12:11 <shapr> you saved up enough money to coast for a few years? :-D
2020-11-23 18:12:46 → geekosaur joins (ac3a5347@172.58.83.71)
2020-11-23 18:13:09 <xerox_> thereabouts (:
2020-11-23 18:13:13 × alp quits (~alp@2a01:e0a:58b:4920:ece0:78fb:1f80:8fc7) (Ping timeout: 272 seconds)
2020-11-23 18:13:24 → merijn joins (~merijn@83-160-49-249.ip.xs4all.nl)
2020-11-23 18:13:52 <shapr> yeah, writing code pays well
2020-11-23 18:14:13 <xerox_> maerwald: gen-hie doesn't see 3rdparty on its own, nor your .local magically saves the day, more digging required...
2020-11-23 18:14:14 × geekosaur96 quits (ac3a5347@172.58.83.71) (Ping timeout: 245 seconds)
2020-11-23 18:14:29 <maerwald> xerox_: which cabal version?
2020-11-23 18:14:30 <maerwald> oooh
2020-11-23 18:14:45 <maerwald> you must be running 3.2
2020-11-23 18:14:47 × justan0theruser quits (~justanoth@unaffiliated/justanotheruser) (Ping timeout: 260 seconds)
2020-11-23 18:14:52 <maerwald> upgrade to 3.4 prerelease
2020-11-23 18:15:31 <xerox_> ok!
2020-11-23 18:16:04 → lambda-11235 joins (~lambda-11@2600:1700:7c70:4600:6511:46eb:c421:ce43)
2020-11-23 18:23:45 → sand_dull joins (~theuser@c-73-149-95-105.hsd1.ct.comcast.net)
2020-11-23 18:28:04 × Yumasi quits (~guillaume@2a01cb09b06b29ea1c5ab82b3b485150.ipv6.abo.wanadoo.fr) (Ping timeout: 240 seconds)
2020-11-23 18:28:12 → jcd joins (~user@2601:282:1300:7cb0::adb4)
2020-11-23 18:28:42 <xerox_> maerwald: that helped but the 3rdparty stuff still produces the same errors
2020-11-23 18:28:55 <maerwald> but that doesn't matter I think
2020-11-23 18:29:54 → justan0theruser joins (~justanoth@unaffiliated/justanotheruser)
2020-11-23 18:30:01 <xerox_> it keeps going in a loop
2020-11-23 18:30:24 → shatriff joins (~vitaliish@176.52.219.10)
2020-11-23 18:30:38 <maerwald> ignore the loop, does it actually work? :p
2020-11-23 18:30:49 → gproto23 joins (~gproto23@unaffiliated/gproto23)
2020-11-23 18:33:54 → solonarv joins (~solonarv@astrasbourg-653-1-156-4.w90-6.abo.wanadoo.fr)
2020-11-23 18:34:10 <xerox_> maerwald: nope, both editors hang or give no answers, while running the same neverending output as before in the debug logs
2020-11-23 18:34:37 → alp joins (~alp@2a01:e0a:58b:4920:99e8:704d:3180:71f2)
2020-11-23 18:34:46 <maerwald> :D
2020-11-23 18:36:42 <monochrom> At least it's quiescent now. >:)
2020-11-23 18:37:07 <monochrom> (The next best thing you can hope for, if you can't prove termination.)
2020-11-23 18:37:21 → frdg joins (~nick@pool-71-184-143-249.bstnma.fios.verizon.net)
2020-11-23 18:38:08 <hseg> ok, a little refactoring later: http://ix.io/2Feg
2020-11-23 18:38:48 <xerox_> I will propose as next best thing having dinner instead, yeah
2020-11-23 18:40:03 × mpereira quits (~mpereira@2a02:810d:f40:d96:1ca0:7a83:5454:b1ba) (Remote host closed the connection)
2020-11-23 18:40:09 → lxsameer joins (~lxsameer@unaffiliated/lxsameer)
2020-11-23 18:40:45 → mpereira joins (~mpereira@2a02:810d:f40:d96:1ca0:7a83:5454:b1ba)
2020-11-23 18:41:19 → qwfpmluy joins (2e0505e2@HSI-KBW-046-005-005-226.hsi8.kabel-badenwuerttemberg.de)
2020-11-23 18:43:22 × christo quits (~chris@81.96.113.213) (Remote host closed the connection)
2020-11-23 18:46:55 × cads quits (~cads@ip-64-72-99-232.lasvegas.net) (Ping timeout: 246 seconds)
2020-11-23 18:47:25 × merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds)
2020-11-23 18:47:26 <hseg> http://ix.io/2Fek
2020-11-23 18:47:55 → jonatanb joins (jonatanb@gateway/vpn/protonvpn/jonatanb)
2020-11-23 18:48:12 <hseg> http://ix.io/2Fel
2020-11-23 18:48:39 → christo joins (~chris@81.96.113.213)
2020-11-23 18:49:14 <monochrom> dinner and wine are always good
2020-11-23 18:50:33 × christo quits (~chris@81.96.113.213) (Read error: No route to host)
2020-11-23 18:51:07 → christo joins (~chris@81.96.113.213)
2020-11-23 18:52:12 → Deide joins (~Deide@217.155.19.23)
2020-11-23 18:55:25 × cheater quits (~user@unaffiliated/cheater) (Ping timeout: 264 seconds)
2020-11-23 18:55:29 × geekosaur quits (ac3a5347@172.58.83.71) (Ping timeout: 245 seconds)
2020-11-23 18:57:36 <domenkozar[m]> I'm using async to start two concurrent threads. The first thread is doing stuff and feeding things to a channel. The second one is consuming from channel and doing things based on those message. How could I make the second thread exit once channel is emptied and the first thread is also exited?
2020-11-23 18:58:15 → cheater joins (~user@unaffiliated/cheater)
2020-11-23 18:59:00 → knupfer joins (~Thunderbi@200116b8240c1500ace8d9fffee870c4.dip.versatel-1u1.de)
2020-11-23 18:59:27 × borne quits (~fritjof@200116b864880200394a967dc8ef4e61.dip.versatel-1u1.de) (Ping timeout: 272 seconds)
2020-11-23 18:59:32 × knupfer quits (~Thunderbi@200116b8240c1500ace8d9fffee870c4.dip.versatel-1u1.de) (Remote host closed the connection)
2020-11-23 18:59:45 → knupfer joins (~Thunderbi@200116b8240c15009967b89ece4ca4cf.dip.versatel-1u1.de)
2020-11-23 19:01:28 × jespada quits (~jespada@90.254.245.49) (Ping timeout: 272 seconds)
2020-11-23 19:03:26 → jespada joins (~jespada@90.254.245.49)
2020-11-23 19:03:38 × berberman quits (~berberman@unaffiliated/berberman) (Ping timeout: 264 seconds)
2020-11-23 19:03:39 → berberman_ joins (~berberman@unaffiliated/berberman)
2020-11-23 19:03:39 × Saukk quits (~Saukk@2001:998:f9:2914:1c59:9bb5:b94c:4) (Remote host closed the connection)
2020-11-23 19:03:49 <__monty__> domenkozar[m]: Can you send an exit message?
2020-11-23 19:03:50 <monochrom> The message type has to include a "quit" case. The first thread has to send the "quit" message.
2020-11-23 19:03:59 × frdg quits (~nick@pool-71-184-143-249.bstnma.fios.verizon.net) (Quit: Leaving.)
2020-11-23 19:04:20 <monochrom> Lest it's the "does quiescent imply termination?" question again.
2020-11-23 19:05:12 <dminuoso> domenkozar[m]: Do you want the second thread to terminate as a "nothing more to do" case, or rather immediately if the first one dies?
2020-11-23 19:05:32 × revprez_stg quits (~revprez_s@pool-108-49-213-40.bstnma.fios.verizon.net) (Ping timeout: 256 seconds)
2020-11-23 19:05:42 <dminuoso> Also, do not forget to consider the case of the first thread receiving an async exception.
2020-11-23 19:05:50 → geekosaur joins (ac3a53fb@172.58.83.251)
2020-11-23 19:06:16 → revprez_stg joins (~revprez_s@pool-108-49-213-40.bstnma.fios.verizon.net)
2020-11-23 19:06:31 <monochrom> Ah yeah, I forgot that too. But it's easy to fix: foo `finally` send quit message
2020-11-23 19:07:13 → heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net)
2020-11-23 19:08:07 → elliott__ joins (~elliott@pool-108-51-141-12.washdc.fios.verizon.net)
2020-11-23 19:08:22 × Franciman quits (~francesco@host-82-54-193-143.retail.telecomitalia.it) (Ping timeout: 256 seconds)
2020-11-23 19:08:55 <monochrom> I want to point out that humanity has not thought up any other solution. They have only thought up other packagings of this same solution.
2020-11-23 19:10:11 <monochrom> For example Unix and C. The writer process has two commands at its disposable, "write" and "close". The writer has to issue "close" at some point of time. Sometimes this is masked by "if the process dies, the OS calls close for you", but it's there.
2020-11-23 19:10:42 <domenkozar[m]> dminuoso: in "nothing to do case"
2020-11-23 19:10:46 <monochrom> Well that isn't much different from having two kinds of meessage at your disposal, is it? s/close/send quit message/
2020-11-23 19:11:22 <dminuoso> domenkozar[m]: Then the usual technique is to, indeed, decorate the "things" you feed into the channel with some outer signaling layer
2020-11-23 19:11:25 <geekosaur> "send quit message" is just "close" at a higher protocol level
2020-11-23 19:11:33 <monochrom> And on the reader side, like wise. You have a "read" command, but it has two kinds of outcomes, "normal" message and "EOF".
2020-11-23 19:11:40 <dminuoso> data Message = Done | Do Thing
2020-11-23 19:11:44 <dminuoso> And then you have a channel of Message.
2020-11-23 19:11:46 × heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 246 seconds)
2020-11-23 19:12:08 <domenkozar[m]> dminuoso: so that the last message is Done?
←Prev  Next→
Page 1 .. 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 .. 5022

All times are in UTC.