Home freenode/#haskell: Logs Calendar

Logs: freenode/#haskell

←Prev  Next→
Page 1 .. 286 287 288 289 290 291 292 293 294 295 296 .. 5022
— 502,152 events total
2020-09-29 07:46:24 <fog> right, dont bother with the talk, sorry - i was just trying to get the part that was important
2020-09-29 07:46:53 <hc> i mean the article. that's just as confusing and verbose
2020-09-29 07:47:13 <fog> there was basically some magical way the kotlin language managed to render all of the handling of this tree processes as syntax where it could wrangle the contexts
2020-09-29 07:47:40 <nshepperd1> what concurrency API doesn't need a way to run code concurrently
2020-09-29 07:47:51 <fog> hc: seriously, its so simple - its just a tree as opposed to a list of concurrent processes.
2020-09-29 07:48:04 × BalterNotz quits (ca420871@202.66.8.113) (Remote host closed the connection)
2020-09-29 07:48:57 <fog> anyway, i cant understand how to structure an API for an actors model. apparently i dont want a "node list" and so presumably i dont want an edge list either
2020-09-29 07:49:12 <fog> i guess the idea is just to capture all that into a syntax tree
2020-09-29 07:49:31 <fog> and that kotlin gives some fancy way to write syntax like functions or something
2020-09-29 07:49:52 <fog> so that he could write things like keywords like "launch" or "run"
2020-09-29 07:50:28 → lucid_0x80 joins (~lucid_0x8@188.253.237.9)
2020-09-29 07:50:48 <fog> but basically the whole idea of "structured concurrency" was just something like having a ADT for the connectivity between calling processes
2020-09-29 07:51:42 <fog> ah, im confusing "comunications chanels" as edges, and this "calling processes" as parents, as branches in the syntax tree
2020-09-29 07:51:57 <fog> i guess i should read more about mailboxes
2020-09-29 07:52:50 × fog quits (a18146a5@gateway/web/cgi-irc/kiwiirc.com/ip.161.129.70.165) (Quit: Connection closed)
2020-09-29 07:54:04 → cosimone joins (~cosimone@2001:b07:ae5:db26:b248:7aff:feea:34b6)
2020-09-29 07:56:02 × digia quits (~digia@unaffiliated/digia) (Quit: Beep Boop...)
2020-09-29 07:56:17 → digia joins (~digia@unaffiliated/digia)
2020-09-29 07:58:33 → DavidEichmann joins (~david@43.240.198.146.dyn.plus.net)
2020-09-29 07:58:47 → madjestic joins (~madjestic@86-88-72-244.fixed.kpn.net)
2020-09-29 07:58:52 m1dnight_ is now known as m1d
2020-09-29 07:59:15 → fog30 joins (a18146b7@gateway/web/cgi-irc/kiwiirc.com/ip.161.129.70.183)
2020-09-29 07:59:36 <fog30> ok, so from what i can understand, it needs something like an erlang "scheduler"
2020-09-29 08:00:18 <fog30> otherwise its going to be a wasteful thread, just rereading an empty mailbox over and over until it receives a "message" which is some input argument to the function
2020-09-29 08:01:19 <fog30> im not sure how it works to do with the mailbox being listlike, so that the receipt of messages can be raced upon, and the control of which inputs to accept is then passed to the actor
2020-09-29 08:01:22 → John20 joins (~John@82.46.59.122)
2020-09-29 08:02:06 <fog30> like it can say, "i take types of Either Int Bool, where the Ints are from this actor, and im going to process them before any of the Bools im recieving from this other actor"
2020-09-29 08:02:12 <fog30> by "reading its mailbox"
2020-09-29 08:02:31 <fog30> and in this way, somehow converting between being a pushed or pulled process..
2020-09-29 08:02:48 <fog30> not sure what the termanology is - something to do with state vs costate
2020-09-29 08:02:56 <fog30> producer vs consumer
2020-09-29 08:03:01 m1d is now known as m1dnight_
2020-09-29 08:03:22 × Clough quits (~Cain@210.185.68.138) (Read error: Connection reset by peer)
2020-09-29 08:03:33 <fog30> that by reading its mailbox, it decides when to respond, as opposed to being forced to respond by the thing sending messages
2020-09-29 08:03:49 → Clough joins (~Cain@210.185.68.138)
2020-09-29 08:03:50 × rprije quits (~rprije@27.143.220.203.dial.dynamic.acc01-myal-dub.comindico.com.au) (Remote host closed the connection)
2020-09-29 08:04:11 → rprije joins (~rprije@27.143.220.203.dial.dynamic.acc01-myal-dub.comindico.com.au)
2020-09-29 08:04:13 × klardotsh quits (~klardotsh@24.17.103.8) (Ping timeout: 246 seconds)
2020-09-29 08:04:17 × hnOsmium0001 quits (uid453710@gateway/web/irccloud.com/x-rzmwmtzgbawceqym) (Quit: Connection closed for inactivity)
2020-09-29 08:04:41 <fog30> so you dont like, supply an argument to a function, you just put it in the mailbox, and the function can decide when to operate on it - i guess essentially becoming blocking in the process
2020-09-29 08:05:01 <fog30> but, then, there is nothing that should be waiting on it, it only ever sends messages to other mailboxes
2020-09-29 08:05:18 → aarvar joins (~foewfoiew@50.35.43.33)
2020-09-29 08:05:22 <fog30> which then somehow serve like input arguments in function application syntax
2020-09-29 08:05:31 × lucid_0x80 quits (~lucid_0x8@188.253.237.9) (Ping timeout: 260 seconds)
2020-09-29 08:05:37 × shatriff quits (~vitaliish@176.52.219.10) (Ping timeout: 264 seconds)
2020-09-29 08:05:39 <fog30> sounds totally mental
2020-09-29 08:06:17 <fog30> let bound variables passed as inputs to functions would be replaced with emited messages stored in the actors mailbox
2020-09-29 08:07:03 <fog30> i cant see how that would work at all really! the let bound variable might not have had a value written to it yet
2020-09-29 08:07:26 <fog30> hmm, i guess that would be the empty list, as a mailbox
2020-09-29 08:07:40 <fog30> so it seems like all values end up being replaced by lists
2020-09-29 08:08:06 <fog30> wierd paradigm. pretty sure thats not how the actors models we have as libraries work...
2020-09-29 08:08:32 <fog30> seems like the kind of thing that would work really well with linear types.
2020-09-29 08:08:46 <fog30> then we can have messages that are like "burn after reading"
2020-09-29 08:09:02 <fog30> so they dont need to be garbage collected
2020-09-29 08:09:09 m1dnight_ is now known as m1d
2020-09-29 08:09:16 m1d is now known as m1dnight_
2020-09-29 08:09:27 × fog30 quits (a18146b7@gateway/web/cgi-irc/kiwiirc.com/ip.161.129.70.183) (Quit: Connection closed)
2020-09-29 08:09:31 → Sanchayan joins (~Sanchayan@136.185.169.201)
2020-09-29 08:10:47 × Sgeo quits (~Sgeo@ool-18b982ad.dyn.optonline.net) (Read error: Connection reset by peer)
2020-09-29 08:11:37 → justsomeguy joins (~justsomeg@unaffiliated/--/x-3805311)
2020-09-29 08:13:16 × tzh quits (~tzh@2601:448:c500:5300::82b3) (Quit: zzz)
2020-09-29 08:14:57 hackage nothunks 0.1.1.0 - Examine values for unexpected thunks https://hackage.haskell.org/package/nothunks-0.1.1.0 (EdskoDeVries)
2020-09-29 08:16:54 × aplainzetakind quits (~johndoe@captainludd.powered.by.lunarbnc.net) (Quit: Free ZNC ~ Powered by LunarBNC: https://LunarBNC.net)
2020-09-29 08:18:40 → __monty__ joins (~toonn@unaffiliated/toonn)
2020-09-29 08:21:06 × DataComputist quits (~lumeng@static-50-43-26-251.bvtn.or.frontiernet.net) (Quit: Leaving...)
2020-09-29 08:23:27 → sword865 joins (uid208942@gateway/web/irccloud.com/x-uhmvawtkvtngcrcd)
2020-09-29 08:24:33 → o1lo01ol1o joins (~o1lo01ol1@bl8-213-81.dsl.telepac.pt)
2020-09-29 08:27:46 → ubert joins (~Thunderbi@178.165.128.50.wireless.dyn.drei.com)
2020-09-29 08:28:47 × ubert quits (~Thunderbi@178.165.128.50.wireless.dyn.drei.com) (Remote host closed the connection)
2020-09-29 08:28:48 → mmohammadi9812 joins (~mmohammad@188.210.120.20)
2020-09-29 08:29:26 → aplainzetakind joins (~johndoe@captainludd.powered.by.lunarbnc.net)
2020-09-29 08:32:16 → jedws joins (~jedws@121.209.139.222)
2020-09-29 08:32:45 → thc202 joins (~thc202@unaffiliated/thc202)
2020-09-29 08:35:11 × jedws quits (~jedws@121.209.139.222) (Client Quit)
2020-09-29 08:35:20 → isovector1 joins (~isovector@172.103.216.166)
2020-09-29 08:35:25 × rzmt quits (~rzmt@87-92-180-112.rev.dnainternet.fi) (Ping timeout: 265 seconds)
2020-09-29 08:35:27 × murphy_ quits (~murphy_@2604:2000:1281:8a9e:a00c:e87a:3ee5:cae0) (Ping timeout: 240 seconds)
2020-09-29 08:36:36 → murphy_ joins (~murphy_@2604:2000:1281:8a9e:14d4:9618:a1b2:ef6b)
2020-09-29 08:37:41 → rzmt joins (~rzmt@87-92-180-112.rev.dnainternet.fi)
2020-09-29 08:38:00 ← isovector1 parts (~isovector@172.103.216.166) ()
2020-09-29 08:38:35 × TooDifficult quits (~TooDiffic@139.59.59.230) (Ping timeout: 240 seconds)
2020-09-29 08:39:50 × paintedindigo quits (~paintedin@2605:a000:1621:8576:21b5:3482:9f3c:3756) (Quit: Leaving)
2020-09-29 08:41:38 → thir joins (~thir@p200300f27f0fc60094e773283d7bf825.dip0.t-ipconnect.de)
2020-09-29 08:42:11 × drbean quits (~drbean@TC210-63-209-154.static.apol.com.tw) (Ping timeout: 265 seconds)
2020-09-29 08:43:50 × heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Remote host closed the connection)
2020-09-29 08:44:44 → fog joins (a1814696@gateway/web/cgi-irc/kiwiirc.com/ip.161.129.70.150)
2020-09-29 08:44:52 <fog> hmm, i have found several resources
2020-09-29 08:44:53 → jedws joins (~jedws@121.209.139.222)
2020-09-29 08:44:53 <fog> https://mail.haskell.org/pipermail/haskell-cafe/2014-March/113341.html
2020-09-29 08:45:06 <fog> this is a pretty decent thread discussing actors models
2020-09-29 08:45:24 <fog> not really sure about erlang vs cloud haskell
2020-09-29 08:45:34 <fog> but i like the references to different implementations of channels
2020-09-29 08:46:15 <fog> and different ways of scheduling, which i guess kind of makes actors basically an incomplete theory, if im not misunderstanding something
2020-09-29 08:46:17 × thir quits (~thir@p200300f27f0fc60094e773283d7bf825.dip0.t-ipconnect.de) (Ping timeout: 260 seconds)
2020-09-29 08:46:23 <fog> seems non-deterministic at least
2020-09-29 08:46:57 <fog> whereas you would normally want a "functions net" style implmentation with mutable state per function to be reproducable from the same initial conditions
2020-09-29 08:47:15 <fog> basically then we end up with the same considerations about things like LVars for the channels
2020-09-29 08:47:28 <AWizzArd> In Servant I describe my route and parameters, or the type of a json body. Now in Snap: is the way to go to fetch what is in the request and call Aeson’s `decode` manually on it?
2020-09-29 08:47:32 <fog> and a lattice computation for the sheduling
2020-09-29 08:48:28 <fog> but then, how would you do that sheduling? is it just a race? wouldnt it be better to have a way to demand that certain actors downstream of a let bound value can be demanded to be evaluated, or does that always result in blocking?
←Prev  Next→
Page 1 .. 286 287 288 289 290 291 292 293 294 295 296 .. 5022

All times are in UTC.