< 1456963208 344569 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: I can't find what pointwise indexing means < 1456963227 401466 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :I'm confused by the [punctuation] < 1456963266 789332 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :and [] is somewhat overloaded. < 1456963268 842845 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :`? nit < 1456963270 181158 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :nit? ¯\(°​_o)/¯ < 1456963292 164095 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :`learn Nits are there to be picked. < 1456963295 175654 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :Learned 'nit': Nits are there to be picked. < 1456963355 909641 :p34k!~p34k@nat-wh-wz4-12.rz.uni-karlsruhe.de QUIT : < 1456963417 515730 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :nits are louse eggs hth < 1456963419 708105 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :int-e: um it means it's optional? < 1456963453 915857 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :oerjan: [...] < 1456963466 600872 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :OKAY < 1456963474 691745 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :well, technically that's also optional hth < 1456963485 794095 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :o-kay < 1456963506 432090 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :`? optional < 1456963507 476444 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :optional? ¯\(°​_o)/¯ < 1456963509 636498 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :`learn optional. < 1456963513 275865 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :Learned 'optional.': optional. < 1456963519 493120 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :oops < 1456963531 446298 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :`` cd wisdom; grep '\.\.\.' * < 1456963532 461785 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :a small bug < 1456963542 295935 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :arothmorphise:arothmorphise ... antormo... antrohm... ant... oh bugger. This should go in the `misspellings of antrhrop... atnhro...' entry. \ code:[11,11,11,15,15,23,12],[5,5,5,3,53,45,16,26,00,20,15,16,22,25,45,91,32,11,15,27,06,01,11,01,47,22,30,13,43,21,11,13,29,61,65,17,19,12,28,17,11,01,23,20,16,20,81,18,32,25,58,22.,1985,10.301350435,1555466 < 1456963544 112423 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :`cat bin/learn < 1456963545 282834 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :​#!/bin/bash \ topic=$(echo "$1" | lowercase | sed 's/^\(an\?\|the\) //;s/s\?[:;,.!?]\? .*//') \ echo "$1" >"wisdom/$topic" \ echo "Learned '$topic': $1" < 1456963583 948871 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :oh right, the space is not optional if it's to remove any of the rest < 1456963584 100646 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :`` cd wisdom; grep -l '\.\.\.' * < 1456963585 805230 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :arothmorphise \ code \ hthmonoid \ grep: le: Is a directory \ learn \ `learn \ northumberland \ grep: ¯\(°_o): Is a directory \ grep: ¯\(°​_o): Is a directory \ \oren\ \ procrastination \ qdb \ quoteformat \ remorse < 1456963594 36140 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :`rm wisdom/optional. < 1456963596 430084 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :No output. < 1456963603 319721 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :`? northumberland < 1456963604 566761 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :Northumberland may be today a sparsely populated country... but SOON! THE NORTHUMBRAINS SHALL RISE! < 1456963642 373335 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :`culprits wisdom/northumberland < 1456963646 113319 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :oerjan elliott Bike FreeFull Taneb < 1456963653 139883 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :`? bike < 1456963654 552895 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :Bike is from Luxembourg. < 1456963709 264731 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :hppavilion[1]: It means each element in the tuple gets indexed on its own. < 1456963729 392904 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: OK, and what does that mean precisely? < 1456963747 660308 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: https://en.wikipedia.org/wiki/Tuple does not speak of "indexing" < 1456963751 314968 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :hppavilion[1]: Try figuring out what indexing would mean and I'll tell you whether it's right. < 1456963756 428828 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :@troll 5d6 < 1456963756 562311 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :int-e: 21 < 1456963764 341134 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Well, this is indexing in the usual sense. < 1456963779 281598 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :(x,y,z)[0] = x and so on < 1456963790 652325 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: Do you add the values? < 1456963797 664899 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :xD < 1456963819 479471 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: So... hm... OH! Is it at all like ~ in INTERCAL? < 1456963827 726116 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :The SELECT operator? < 1456963828 147710 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I don't know INTERCAL. < 1456963837 895273 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric : *reads about the ending phase* ... could there be an infinite loop of cleanup steps... <-- you should reask that with ais523 around hth < 1456963854 769799 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :probably < 1456963855 990235 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I don't think it's that. < 1456963862 448192 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: x~y is all the bits of x for which the corresponding bit in y is 1, right-justified < 1456963872 696601 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :(Or maybe I got which side is which messed up) < 1456963873 856418 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :shachaf: it's ALL CAPS, what else could it be... I mean now that COBOL is dead? < 1456963877 774419 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :ACTION runs. < 1456963881 931356 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :int-e: there can be an infinite loop of cleanup steps, yes < 1456963888 358977 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: Oh :/ < 1456963895 317800 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's a little hard to pull off because cards are typically designed to stop things triggering then < 1456963912 417403 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :help when did this turn into a mtg conversation < 1456963926 561300 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :shachaf: oerjan looking through logs < 1456963930 477077 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: What I mean is the compostion of e.g. (17, 92, 12) and (1, 2) equal to (17, 92)? < 1456963944 749951 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :heys523 < 1456963968 124682 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :hppavilion[1]: What are the domains and codomains of those arrows? < 1456963981 502107 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: They're numbers < 1456963986 373328 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Which numbers? < 1456963987 838624 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: Natural numbers < 1456963994 239746 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :Hm... < 1456963999 848591 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :You have to choose. < 1456964008 884850 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: They're natural numbers < 1456964025 89034 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :hppavilion[1]: what shachaf means is that an arrow is not determined by its tuple alone < 1456964028 69298 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: Or do you mean which numbers in particular for those arrows? < 1456964040 691165 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :oerjan: Ah < 1456964068 543038 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :An arrow : N -> M is an N-tuple of numbers < M < 1456964070 811312 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :well, graphs are categories < 1456964072 487289 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com JOIN :#esoteric < 1456964087 14185 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :(no!) < 1456964087 147785 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So (17, 92, 12) : 3 -> M < 1456964091 554144 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: Ah, I think I transcribed it to my notes wrong < 1456964093 541446 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But M could be 100 or 1000 < 1456964096 405251 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :reflexive, transitive relations are < 1456964105 716072 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :`relcome sphinxo < 1456964107 408304 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :​06sphinxo: 13Welcome 04to 07the 08international 09hub 02for 06esoteric 13programming 04language 07design 08and 09deployment! 02For 06more 13information, 04check 07out 08our 09wiki: 02. 06(For 13the 04other 07kind 08of 09esoterica, 02try 06#esoteric 13on 04EFnet 07or 08DALnet.) < 1456964112 461493 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :(that's the example that I wanted) < 1456964136 591374 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: Oh, so the arrows map numbers to all numbers greater than them, right < 1456964140 659500 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PRIVMSG #esoteric :boily: thanks < 1456964154 836654 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :? < 1456964158 762591 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PRIVMSG #esoteric :So what's the bees knees in esoteric langs? < 1456964183 233569 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :sphinxo: in terms of newly popular? best-known? < 1456964200 801735 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PRIVMSG #esoteric :ais523: newly popular < 1456964200 935173 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :sphinxo: well your puns seem to be up to par... welcome! < 1456964226 685154 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, not sure if any esolangs have really caught on since Three Star Programmer < 1456964231 78391 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :int-e: whoa whoa whoa, when did this turn into a linear logic conversation < 1456964247 97244 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :shachaf: you lost me < 1456964261 87614 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :int-e: wait, what pun < 1456964266 952508 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :oh < 1456964267 126956 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :oerjan: the bees one < 1456964297 437908 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :sphinxo: One that isn't popular- but be used by at least one person in the world someday, if I'm being generous- is a proof assistant I myself made called Thoof < 1456964304 695582 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :i didn't notice it was a pun < 1456964317 4630 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :sphinxo: Based on Thue, which is a great language you should check out if you haven't already < 1456964328 663252 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :oerjan: flew right over your head, eh... < 1456964345 735965 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: Wait, my brain is turning on now < 1456964357 608139 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PRIVMSG #esoteric :hppavilion[1]: is it on github? < 1456964368 631229 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :sphinxo: Yes, I'll link you < 1456964395 313927 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :sphinxo: But there are no published docs yet; however, I can publish the as-of-yet incomplete tutorial if you like < 1456964396 259155 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :xD < 1456964404 878829 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PRIVMSG #esoteric :hppavilion[1]: Oh wait I think i've found it, in python right? < 1456964420 881522 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, I thought you were talking about hppavilion[1]'s brain. < 1456964422 255801 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :sphinxo: Yep < 1456964427 574454 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The joke seemed a little drawn out. < 1456964435 423557 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :int-e: well, bee's knees did fit there without having to reinterpret it. < 1456964480 689429 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: Gah! Your and sphinxo's nicks arethe same length and both start with s! < 1456964486 293149 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :Now I'll always be confused! < 1456964496 93873 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :you're already always confused hth < 1456964501 767438 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :shachaf: Oh right < 1456964531 685778 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :boily: have you figured out the mysterious category twh < 1456964554 965098 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :hppavilion[1]: a single starting letter seems a bit little to be confusing. < 1456964561 194524 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :which mysterious category? < 1456964570 49624 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Oh, apparently this category has a name. < 1456964570 495765 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :oerjan: Yeah, but it is < 1456964588 226505 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :shachaf: isn't it just a subcategory of Set < 1456964593 758576 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PRIVMSG #esoteric :In the spirit of self promotion, i'd like to present one of my first forays into the world of #esoteric < 1456964604 871185 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PRIVMSG #esoteric :ya standard bf compiler < 1456964607 718342 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PRIVMSG #esoteric :written in ocaml < 1456964613 334552 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PRIVMSG #esoteric :generating java bytecode < 1456964650 863297 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :oerjan: yes hth < 1456964746 786069 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PART #esoteric :"WeeChat 1.4" < 1456964773 64508 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com JOIN :#esoteric < 1456964852 658294 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PRIVMSG #esoteric :git.io/v2yj9 < 1456964882 490469 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :sphinxo: weird mix of languages :-) < 1456964886 774090 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(in here, that's probably a good thing) < 1456964903 545407 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :makes sense though, ocaml's good at compilers, jvm is probably the most portable asm < 1456964909 855544 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Do you understand par in linear logic? TWH < 1456964920 455199 :tromp!~tromp@ool-18be0bd8.dyn.optonline.net JOIN :#esoteric < 1456964930 946926 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: what do you mean by par? I fear the answer is no < 1456964936 514209 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I understand the subsets of linear logic I use in my work < 1456964937 282046 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The upside-down ampersand. < 1456964943 381411 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ah, in that case no < 1456964945 119102 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Also smetimes written # < 1456964954 559105 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: How about _|_? < 1456964955 530018 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PRIVMSG #esoteric :ais523: it was my first time doing ocaml actually < 1456964962 303059 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Or ?A the exponential thing? < 1456964966 366057 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PRIVMSG #esoteric :but I didn't really like it and went back to haskell < 1456964985 490070 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: _|_ is just "arbitrary false statement" in most logics < 1456964996 129770 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :sphinxo: Oh, that's where I remember you from. < 1456965002 421924 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I sort-of have a vague idea of how ? works but not enough to put it into words < 1456965022 240480 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Well, there's _|_ and there's 0 < 1456965034 102430 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :_|_ is the identity of # < 1456965046 992151 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ah right < 1456965052 751204 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :linear logic sort-of has SCI syndrome < 1456965055 982499 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PRIVMSG #esoteric :shachaf: yeah i'm the one generally asking the silly questions < 1456965056 668551 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but possibly even worse < 1456965070 335710 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Spinal Cord Injury? < 1456965092 300089 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(SCI is an affine logic, which has the problem that ('a * 'b) -> 'c and 'a -> ('b -> 'c) aren't isomorphic and most language constructs need to work both ways round) < 1456965096 295820 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :syntactic control of interference < 1456965105 365085 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :This game semantics interpretation made the most sense to me. < 1456965117 707891 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Oh, it has both an internal hom and a product but they're not adjoint? < 1456965119 965159 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :That's interesting. < 1456965133 77812 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The product has no right adjoint and the internal hom has no left adjoint? < 1456965139 280735 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :indeed < 1456965153 105397 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it causes utter chaos at the category theory level < 1456965161 909026 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in terms of programming it, it's only mildly annoying < 1456965167 963238 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com PRIVMSG #esoteric :y'all played tis-100? I imagine that'd be right up you guys/girls boats < 1456965185 66170 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Sounds sort of reasonable. Maybe. < 1456965186 264419 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :annoying enough, though, that SCI errors are something that I have to keep correcting in other people's code < 1456965214 647985 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Anyway in this game semantics interpretation, when you have A#B, you run two games in parallel, one for A and one for B. < 1456965220 649623 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :quite a bit of work on my thesis was trying to create a more categorically sensible SCI < 1456965220 868315 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :And you only have to win one of them. < 1456965239 549205 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :So for instance A # ~A is always true, because if you get a refutation on one side you can use it on the other side. < 1456965247 42667 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it turns out that it has hidden intersection types < 1456965258 955551 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Hmm, I should read your thesis. < 1456965263 875966 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :shachaf: hmm, that makes me think of a programming language construct < 1456965275 808900 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in which you give two terms, it returns one of its argument < 1456965291 516771 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but it's guaranteed to return something other than bottom unless both arguments are bottom < 1456965310 136113 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ACTION wonders if the Haskell people would consider that pure < 1456965395 409971 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Haskell people probably want a guarantee that they're equal unless they're bottom. < 1456965402 545904 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :https://wiki.haskell.org/Unamb < 1456965410 39556 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :good name for it :-) < 1456965434 124868 :prooftechnique!~prooftech@2a03:b0c0:0:1010::ca:e001 PRIVMSG #esoteric :sphinxo: I played it. It's neat. < 1456965436 430498 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :now I'm wondering if it's useful < 1456965439 742013 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess you could do sorting with it < 1456965455 553838 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Sure it's useful. < 1456965459 230168 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :one argument an O(n log n) worst case, the other an O(n) best case that sometimes blows up < 1456965467 479234 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :http://conal.net/blog/tag/unamb < 1456965579 47083 :tromp!~tromp@ool-18be0bd8.dyn.optonline.net QUIT :Remote host closed the connection < 1456965803 717022 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :ais523: Oh, A # B is also ~(~A x ~B) < 1456965951 71283 :heroux!~heroux@gateway/shell/insomnia247/x-yladneeucqbbtpzm QUIT :Ping timeout: 250 seconds < 1456966527 364290 :sphinxo!~sphinxo@212-139-67-166.dynamic.dsl.as9105.com QUIT :Quit: WeeChat 1.4 < 1456966905 190466 :heroux!sandroco@gateway/shell/insomnia247/x-aqwhcyzbefsarqfv JOIN :#esoteric < 1456966974 442722 :llue!~gnomebad@unaffiliated/lleu QUIT :Quit: That's what she said < 1456966983 656077 :lleu!~gnomebad@unaffiliated/lleu JOIN :#esoteric < 1456967257 197952 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :mwah ah ah. Tiamat is dead! < 1456967305 214206 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :dragonskin cloak is miiiiine! < 1456967345 995837 :tromp!~tromp@ool-18be0bd8.dyn.optonline.net JOIN :#esoteric < 1456967500 673354 :carado!~carado@savhon.org QUIT :Quit: Leaving < 1456967728 783453 :Phantom_Hoover!~phantomho@unaffiliated/phantom-hoover QUIT :Read error: Connection reset by peer < 1456967742 453979 :mad!boulam@69-165-212-148.cable.teksavvy.com JOIN :#esoteric < 1456967776 106583 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :will someone explain this to me: why some programmers use C but have an aversion to C++ < 1456967822 334549 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :(especially on non-embedded platforms) < 1456967972 449357 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Because the things that C++ is good at, C is about as good at, and the things that C++ does better than C, other languages do significantly better. So, C++ is a giant pile of complexity with minimal benefits. < 1456968072 158443 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :er, no, there is one class of stuff where C doesn't have the tools (like, you can do it but it's cumbersome), and java/C#/etc can't do it because of the mandatory garbage collector < 1456968100 765069 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :once you have lots of dynamic sized stuff C++ has a large advantage over C < 1456968144 651228 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :You know that there's languages out there besides C-family languages, Java-family languages, and P-family languages, right? < 1456968166 566936 :lynn!~lynn@unaffiliated/lynn QUIT :Ping timeout: 252 seconds < 1456968181 776253 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :this is why C++ is popular for making games (too much dynamic sized stuff for C, can't use java/C# because garbage collector creates lags) < 1456968186 398090 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :P-family lanugages? < 1456968198 931182 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :ais523: Gregor's joking name for Perl, Python, Ruby, etc. < 1456968206 325302 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ah right < 1456968223 963584 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :pikhq: what other language category is there? functional languages? < 1456968277 280383 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :the other languages I can think of generally aren't particularly fast < 1456968326 498091 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :https://en.wikipedia.org/wiki/Template:Programming_paradigms *cough* < 1456968355 186559 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :There's more programming language *categories* than you think there are languages, it sounds like. :) < 1456968376 758635 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :who's gregor? < 1456968402 518660 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :izabera: Gregor Richards, one of the channel members who's not been that active of late. < 1456968414 890316 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :He's still here though < 1456968418 614134 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Gregor: Isn't that right? < 1456968425 14078 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :pikhq : that list is a split by paradigm, not by speed grade < 1456968454 676728 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :mad: C++ ain't exactly "fast" in idiomatic use... < 1456968477 806927 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :I mean, sure, you can write fast C++, but once you're using the STL you've abandoned all hope. < 1456968486 922460 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :izabera: Gregor's most famous for writing EgoBot and HackEgo < 1456968492 738462 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :`? Gregor < 1456968497 770179 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :pikhq : not if you're using STL right < 1456968500 955879 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :I thought he was most famous for the hats. < 1456968504 850064 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :Gregor took forty cakes. He took 40 cakes. That's as many as four tens. And that's terrible. < 1456968508 182725 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :oh, he wrote lagbot < 1456968510 397804 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :neato < 1456968519 535487 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :it wasn't always laggy < 1456968523 318878 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ie basically as a replacement for arrays [] except it manages the size < 1456968526 670877 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :but then he got cheap < 1456968538 128513 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Also, I wouldn't take game developers as a good example of "how to write programs"... < 1456968549 426288 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oerjan: if you want a cheap bot, see glogbackup (which is also Gregor's) < 1456968599 122033 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Unmaintainable piles of shit that are written by the sort of people who are willing to accept 80 hour workweeks are par for the course. < 1456968637 239643 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :that's a rant i've never heard < 1456968662 196015 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :what's the problem with working too many hours a week? < 1456968664 466005 :Sgeo!~Sgeo@ool-18e43ef5.dyn.optonline.net QUIT :Ping timeout: 260 seconds < 1456968702 924361 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Um, humans are kinda bad at being productive that long. Especially at mentally intense tasks. < 1456968737 589381 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :if garbage collectors are ruled out you're left with, er, basically: C, C++, assembler, delphi, rust, and objective C (and I guess cobol and ada) < 1456968744 636657 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :as far as I can think of < 1456968758 322651 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :... Have you never even heard of Forth? < 1456968764 955737 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ok and forth < 1456968773 514038 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :also fortran, i think < 1456968776 234697 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Or Tcl, for that matter? < 1456968779 260520 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ok and fortran < 1456968786 338233 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :ACTION adds bash to the list of non-garbage-collected languages < 1456968788 400209 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Hell, and Python. < 1456968809 63365 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :how is python not garbage collected < 1456968815 321355 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Python is reference counted. < 1456968830 635967 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :also it's dynamic typed which is a much larger speed disadvantage < 1456968833 171612 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :reference counters fall into a similar category to garbage collectors to me < 1456968840 685978 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :they have noticeable overhead, often more < 1456968852 543564 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the difference being that it's predictable overhead that always happens in the same places < 1456968852 793460 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :ais523: They're automatic memory management, but GC is a different technique. < 1456968858 70268 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :pikhq: yes < 1456968867 699573 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :they are not the same, but they have similar effects on a program < 1456968868 159096 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Ah, "similar". < 1456968868 815926 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :""The standard C implementation of Python uses reference counting to detect inaccessible objects, and a separate mechanism to collect reference cycles, periodically executing a cycle detection algorithm which looks for inaccessible cycles and deletes the objects involved."" < 1456968873 499649 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Yes, not the same but similar. < 1456968937 731758 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :reference counting doesn't cause 100ms pauses in your app like the java GC does < 1456968999 215814 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Does Java not have a way of using a more interactive-use-appropriate GC? < 1456969016 402484 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can make hints to Java about when a good time to GC would be < 1456969030 921503 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : in a video game, there's never a good time < 1456969034 272437 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but a) it doesn't have to respect them, b) you can't delay GC, only make it happen earlier (and hopefully not again for a while) < 1456969038 5985 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: loading screens < 1456969043 398228 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :great time to GC < 1456969051 486507 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :tswett: Hi yet? < 1456969058 4471 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if you have the memory (and sometimes you do, but not always), you can just leak until the next loading screen and catch all the memory up there < 1456969058 888721 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :if your game has loading screens, yes < 1456969080 912992 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :very few games don't < 1456969088 989738 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :mad: Good luck < 1456969094 322927 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although in many, they're disguised, or short enough that you don't really register them < 1456969096 594353 :tswett!~tswett@192.241.237.138 PRIVMSG #esoteric :Hey there. < 1456969098 884106 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :mad: Making a loading screen-free game, that is < 1456969102 621707 :tswett!~tswett@192.241.237.138 PRIVMSG #esoteric :It happens you caught me at a bad time. < 1456969102 755045 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :tswett: Yay! < 1456969105 706002 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :Oh < 1456969106 37075 :tswett!~tswett@192.241.237.138 PRIVMSG #esoteric :I have to go to bed now. < 1456969109 522252 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :s/yay// < 1456969111 249566 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :even in the disguised/short ones, a 100ms pause isn't noticeable < 1456969112 554209 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :i < 1456969112 742991 :tswett!~tswett@192.241.237.138 PRIVMSG #esoteric :Night, everyone. < 1456969114 188084 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Also, if you have a *good enough* GC, you should be able to only pause for short periods of time between frames. < 1456969185 51335 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :it would still be better to have only ref counting and no GC in that kind of programs though < 1456969219 950133 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: so if the root of a structure gets freed < 1456969228 826113 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you then have a pause while the rest of the structure gets freed recursively < 1456969232 482206 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :refcounting doesn't remove pauses < 1456969239 18104 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :simply makes it easier to predict when they'll happen < 1456969256 319888 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :but (1) other threads keep going < 1456969274 437745 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :as opposed to GC which has a "stop the world" phase where it pauses every thread < 1456969295 673492 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :not necessarily, concurrent GCs exist < 1456969299 344575 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :so chances are the pause will happen on your data loading thread (not your gfx thread) < 1456969299 478216 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :That's only true of a subset of GCs. < 1456969324 176186 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :even concurrent GCs do have a "stop the world" phase, it's just much shorter < 1456969333 487349 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :(if what I've read is correct) < 1456969343 635674 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :By the same notion, so does malloc because malloc has a mutex. < 1456969379 515543 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :pikhq: I've managed to deadlock on that mutex before now :-( < 1456969405 542302 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :let's just say, SDL's situation with timing and concurrency is so bad I've decided to take a look at SFML to see if it's any better < 1456969426 438132 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :SDL is... not a well-designed library. < 1456969488 463148 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :yeah SDL is way less good than it should've been < 1456969586 250089 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :pygame makes SDL sane. < 1456969638 818125 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :boily: does it prevent it polling every 1ms? < 1456969708 71549 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :IIRC, I don't think so. < 1456969732 941520 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :the other thing is that refcounting doesn't have heap compaction < 1456969736 569524 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :which is a good thing < 1456969762 397111 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :It's kinda a wash. < 1456969776 337040 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :(and orthogonal to refcounting, really) < 1456969812 391506 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Heap compaction costs when it happens, but means the allocator can spend less time in allocation. < 1456969847 793272 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :heap compaction on 300megs of data isn't pretty < 1456969864 225942 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :I've forgotten how to count that low. < 1456969940 296805 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :like, it's all fine if it's server software and it doesn't matter if the whole app stops for half a second < 1456969953 513505 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :... No, it isn't. < 1456969957 336481 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :then, yes, by all means use java and C# and python and whatnot < 1456970023 790296 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :If a service pauses for half a second I get paged. < 1456970294 779120 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :pikhq: If an individual server has a GC pause of 500ms? < 1456970320 509880 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :shachaf: I exaggerate. < 1456970335 764224 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :shachaf: But we *do* have SLAs for response time to requests... < 1456970401 516150 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I shouldn't talk about details in here anyway. < 1456970427 662132 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Hmm, I think I know how to set off pikhq's pager. < 1456970464 964713 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Joke's on you, I'm not on call right now < 1456970496 863987 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :But is your pager thing actually turned off? < 1456970508 474204 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Well, no... < 1456970760 56365 :andrew_!~andrew@113.97.177.247 JOIN :#esoteric < 1456970795 379416 :Sgeo!~Sgeo@ool-18e43ef5.dyn.optonline.net JOIN :#esoteric < 1456971288 367768 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :aaah < 1456971289 951592 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net QUIT :Ping timeout: 244 seconds < 1456971294 197374 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :it's elif < 1456971312 469623 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :why can't it just also allow else if and elsif? < 1456971327 823332 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :in python? < 1456971336 897905 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :yah < 1456971345 935244 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :probably elif is much used so it is easier to write in that way? < 1456971347 663819 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :not really sure. < 1456971384 902478 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :true but it should allow elif, else if and elsif as alternatives < 1456971398 295582 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :"one way to do that" :p < 1456971409 224029 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :argh < 1456971413 819303 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :you want perlthon < 1456971430 929602 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :ACTION googled it and it's an actual thing < 1456971443 330675 :prooftechnique!~prooftech@2a03:b0c0:0:1010::ca:e001 PRIVMSG #esoteric :he\\oren\! < 1456971529 399463 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :hi < 1456971534 354219 :mysanthrop!~myname@84.200.43.57 JOIN :#esoteric < 1456971567 593945 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :he hates you < 1456971593 30855 :prooftechnique!~prooftech@2a03:b0c0:0:1010::ca:e001 PRIVMSG #esoteric ::o < 1456971605 167093 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :who? < 1456971627 515665 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :you < 1456971637 221539 :prooftechnique!~prooftech@2a03:b0c0:0:1010::ca:e001 PRIVMSG #esoteric :All right, and whom? < 1456971640 683878 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :you < 1456971653 740360 :prooftechnique!~prooftech@2a03:b0c0:0:1010::ca:e001 PRIVMSG #esoteric :Well, that's rude < 1456971661 222303 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :yeah < 1456971708 621705 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :izabera: why do you think I hate him? < 1456971712 924903 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :`relcome mysanthrop < 1456971732 148963 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :​09mysanthrop: 02Welcome 06to 13the 04international 07hub 08for 09esoteric 02programming 06language 13design 04and 07deployment! 08For 09more 02information, 06check 13out 04our 07wiki: 08. 09(For 02the 06other 13kind 04of 07esoterica, 08try 09#esoteric 02on 06EFnet 13or 04DALnet.) < 1456971744 59297 :prooftechnique!~prooftech@2a03:b0c0:0:1010::ca:e001 PRIVMSG #esoteric :09N13e00e11d09s 08m09o04r08e 11r00a11i12n09b11o09w12s < 1456971787 97225 :prooftechnique!~prooftech@2a03:b0c0:0:1010::ca:e001 PRIVMSG #esoteric :I wonder if I can get mutt working on a jailbroken iPhone < 1456971821 65200 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :why < 1456971828 117161 :j-bot!~j-bot@li1285-84.members.linode.com QUIT :Ping timeout: 248 seconds < 1456971828 250447 :myname!~myname@84.200.43.57 QUIT :Ping timeout: 248 seconds < 1456971828 674772 :Alcest!~alcest@69.64.40.177 QUIT :Ping timeout: 248 seconds < 1456971829 141464 :MoALTz!~no@78-11-180-214.static.ip.netia.com.pl QUIT :Ping timeout: 248 seconds < 1456971829 274883 :nisstyre_!~yourstrul@li611-52.members.linode.com QUIT :Ping timeout: 248 seconds < 1456971837 313402 :prooftechnique!~prooftech@2a03:b0c0:0:1010::ca:e001 PRIVMSG #esoteric :Consistent mail experience? < 1456971839 258328 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :unless your mutt has a much better interface than mine < 1456971867 359637 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :I just use a ssh app and use alpine < 1456971872 5260 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :how do C programmers live without std::vector and std::string < 1456971872 968543 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :you bought an iphone, you clearly care about eye candy < 1456971893 370040 :prooftechnique!~prooftech@2a03:b0c0:0:1010::ca:e001 PRIVMSG #esoteric :I technically lease an iPhone < 1456972000 885626 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :mad: i have a bunch of poorly written functions I copy from one project to the next over and over < 1456972026 911218 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :mad: Easily. < 1456972046 444606 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :... Or poorly, if you go by the average results. :P < 1456972052 308006 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :reallocate arrays every time they change size? < 1456972070 204977 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :Why would you do that if the std::vector implementation doesn't? < 1456972090 260728 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :It's not like it's rocket science to have a struct that has "size" and "capacity" separately. < 1456972105 452833 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :fizzie : true but then you might as well use std::vector < 1456972120 846032 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :which does that and it can't leak < 1456972165 289923 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :my functions resize them when they get to each power of two < 1456972197 85736 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :\oren\ : that's exactly what std::vector does < 1456972209 464536 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :I don't think array resizing is a major source of memory leaks. < 1456972225 810915 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :I read this thing that was arguing that powers of two is one of the worst choices you could make. < 1456972226 496913 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :"new" is your friend if you want to leak memory in C++. ("can't" really is too strong) < 1456972243 362201 :prooftechnique!~prooftech@2a03:b0c0:0:1010::ca:e001 PRIVMSG #esoteric :Now, powers of three, though. That's the future < 1456972247 840046 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :well, the point is that std::vector replaces stuff * < 1456972255 353026 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :stuff * can leak, of course < 1456972266 337039 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :std::vector can't < 1456972267 706778 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :C++ does have a couple of resource management idioms that C doesn't support, but it's far from golden anyway < 1456972289 222817 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :I like std::vector. I *HATE* std::iostream < 1456972301 833158 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :wtf just happends < 1456972311 770114 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Maybe it was https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md < 1456972313 230369 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :iostream is a big raised middle finger to STL < 1456972342 294503 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :I cannot really understand how can it be possible to have STL and iostream in the *same* standard < 1456972342 966145 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :int-e : C doesn't have std::vector, that's the real one that's missing and it's a major, major gaping hole < 1456972373 69216 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :mad: Anyways, frankly if you think that std::vector is your solution to memory management problems you are too unaware of the problems there are to solve to be having this discussion. < 1456972376 295812 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :lifthrasiir : 80% of the time I simply ignore iostream but use STL anyways < 1456972379 304295 :prooftechnique!~prooftech@2a03:b0c0:0:1010::ca:e001 PRIVMSG #esoteric :"always non-negative, almost always measurable, frequently significant, sometimes dramatic, and occasionally spectacular" < 1456972397 770551 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :pikhq : if you need a special case then STL won't cut it true < 1456972434 585895 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :but in my experience, "variable sized array" is 10x more common than any other memory structure and its omission from C hurts hard < 1456972439 494380 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :mad: yeah. STL is (within its design constraint) well-designed library, while iostream is an epic fail < 1456972469 962543 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :It's also by far the easiest data structure to implement, so... < 1456972472 854190 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :for example, locale is a shit < 1456972476 752996 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :well, realloc() is basically the equivalent for C < 1456972489 208863 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :there's no operator renew < 1456972510 603672 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :pikhq : yeah but you reimplement it so often that it should be a language feature really < 1456972512 958449 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :anyone who tried to write a new locale with iostream (to be exact, std::codecvt etc.) will understand that < 1456972527 638215 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Sure, it'd be a nice addition to libc. < 1456972551 821714 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :there are, like, 4 features I care about in C++ < 1456972589 94178 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :std::vector, std::string, std::map, and putting functions in structs/classes for convenience (ie less typing) < 1456972607 251113 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :That's the same for everyone. Unfortunately, it's a different 4 for each person, and C++ has enough features that each individual human being gets their own set of 4 features. < 1456972613 221743 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :std::vector is not just a "nice addition", it's a major feature < 1456972680 502377 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :I just have a function for appending to an array < 1456972683 597917 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :`? mad < 1456972686 259603 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :(I suspect that C++ releases new versions to keep up with global population growth) < 1456972688 916175 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :This wisdom entry was censored for being too accurate. < 1456972707 807056 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :pikhq : that is true < 1456972748 865202 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :apparr(char**array,int*size,char*part,int*partz); < 1456972769 734345 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :https://developer.gnome.org/glib/stable/glib-Arrays.html < 1456972771 458361 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :realloc() isn't bad < 1456972776 904479 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :int-e: the mad that was censored isn't the mad that is in the chännel hth. < 1456972803 95804 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Ugh, glib. glib makes C++ look *angelic* in commparison. < 1456972819 332398 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :my function does realloc iff size would increase through a power of two < 1456972864 442219 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :\oren\ : yeah. I use std::vector for exactly that except with less potential mistakes < 1456972866 783696 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :I don't remember why partz is passed by pointer < 1456972903 783974 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :he\\oren\. more pointers, more stars, more sparkliness. < 1456972912 310092 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :pointers are evil < 1456972926 362160 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :computers are evil < 1456972934 773819 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :pikhq: sure but if the objection is that one has to reimplement resizable arrays all the time, that's one of the counterarguments that come to my mind < 1456972946 121877 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :except pointers that are essentially referrences, those are okay < 1456972947 648895 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :int-e: Fair enough. :) < 1456972966 257561 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :mad: isn't that all pointers? < 1456972973 101929 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :\oren\: I see that you are still fonting ^^ < 1456972986 995465 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :(nice fraktur btw.) < 1456972989 560863 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :pointers and references are different words for the same thing < 1456973007 666663 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :\oren\ : well, basically if its pointing to data owned by some other structure, it's okay < 1456973045 770370 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :\oren\ : if it's pointing to a memory allocation and you get a leak if the pointer gets overwritten, then it's bad < 1456973076 726051 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :how's that different from references? < 1456973138 65650 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :well, c++ references are typically used in function declarations and they refer to some object < 1456973165 103384 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :you can't use c++ references to do allocation/deallocation so by definition they generally can't be evil < 1456973183 856282 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :"can't", again. < 1456973188 150982 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :generally < 1456973189 990175 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :it's C++ we're talking about. everything can be alignment-shifted. < 1456973200 79451 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :boily : and then it'll be slow < 1456973211 655879 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :but that's a rare case < 1456973211 957127 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :well then what good are they? you need some way to refer to non-stack memory... < 1456973229 825733 :prooftechnique!~prooftech@2a03:b0c0:0:1010::ca:e001 PRIVMSG #esoteric :If every programmer were as disciplined as that, we'd already be out of work < 1456973233 54294 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :I bet delete &ref; is valid < 1456973236 162087 :nisstyre_!~yourstrul@li611-52.members.linode.com JOIN :#esoteric < 1456973275 317712 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :\oren\ : easy, when you have a function that returns 2 things, one can be returned as a return value but the other has to be a pointer or reference argument and then the called function will write in it < 1456973285 814369 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :that's what references are for < 1456973297 73992 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :they're essentially interchangeable with pointers < 1456973325 277042 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :that's what I said, they're just a pointer. < 1456973334 409975 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :internally, c++ references are pointers yes < 1456973342 311791 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :time to have unevil, functional sleep. 'night all! < 1456973343 20284 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :basically they're just syntactic sugar < 1456973349 422487 :boily!~alexandre@96.127.201.149 QUIT :Quit: SELFREFERENTIAL CHICKEN < 1456973367 378313 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :int-e : C++ doesn't guard against messing things up badly :D < 1456973380 578103 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :specifically, a int& is the same as a int*const, but with syntax sugar < 1456973410 82744 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :allowing you to code as if it's a int < 1456973449 474964 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :\oren\: and it's much harder to pass in NULL. < 1456973452 389596 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :basically if there's a way to code something with malloc/free/new/delete, and a way that doesn't involve these, I always go for way #2 < 1456973519 535594 :prooftechnique!~prooftech@2a03:b0c0:0:1010::ca:e001 PRIVMSG #esoteric :If you're not writing a custom malloc implementation every time, are you really doing your job? < 1456973542 269224 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :the standard malloc goes through the bucket allocator < 1456973551 273553 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :prooftechnique: I have a word for those people, but it's inappropriate for polite conversation. < 1456973556 115696 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :for typical uses it does a pretty good job < 1456973564 486980 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :prooftechnique: If you're writing a custom malloc implementation every time, are you really doing your job? < 1456973572 971950 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :well at my work we use our own resizable array class < 1456973587 747137 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :instead of std::vector < 1456973593 622073 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :how come? < 1456973609 420346 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :because apparently std::vector doesn't play well with threads or somehting < 1456973611 640911 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :The same is true of my work, but at this point I'm a little surprised we don't just have our own implementation of the STL... < 1456973652 162305 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :\oren\ : depends on when it changes size :D < 1456973655 54054 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :the NIH is strong < 1456973661 746110 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :`? NIH < 1456973663 107372 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :NIH was /not/ invented by Taneb. < 1456973683 786488 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :`culprits wisdom/NIH < 1456973690 12239 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :if you have a size change at the same time another thread looks or writes in the std::vector then you have a problem yes < 1456973691 624530 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :No output. < 1456973693 285807 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :int-e: That's practically the Google way. < 1456973700 797395 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :`culprits wisdom/nih < 1456973704 855670 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :int-e < 1456973707 601010 :prooftechnique!~prooftech@2a03:b0c0:0:1010::ca:e001 PRIVMSG #esoteric :I'm a little sad that the CPPGM is already running. It seems like it'd be a fun thing to fail at < 1456973711 863109 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :meh, I forgot. < 1456973725 361751 :ais523!~ais523@unaffiliated/ais523 QUIT : < 1456973728 194414 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :int-e: well half our codebase is in an in-house language instead of c++, and the compile porcess uses another in-house language instead of makefiles, so you know.... < 1456973730 782964 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :pikhq: The Google way isn't exactly NIH. They have their own variant of it. < 1456973740 107482 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :shachaf: :D < 1456973826 752596 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :\oren\ : basically whenever some std::vector can change size, it needs to be 100% mutexed accessible by only 1 thread, or else you're in trouble < 1456973838 17137 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :the rest of the time it's the same as a C array < 1456973919 61476 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :supposedly copy-on-write containers work well with threading < 1456973946 66371 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :i think that's what we have NIHed < 1456974006 102955 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :the other case I've heard is code that had to work on stuff like the nintendo DS < 1456974009 698234 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :I haven't looked into the details since the interface is almost exaclt the same as std::vector < 1456974023 670779 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :which if I'm not mistaken had a broken STL or something like that < 1456974048 292195 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :this has to work on coffeemachines and things < 1456974055 708390 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :my brother's company has a NIH std::vector equivalent because of that < 1456974159 206541 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :for strings, ironically std::string basically complements char *> < 1456974189 93498 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :char * strings are cool except that you basically can't store them, std::string fixes just exactly that < 1456974319 622534 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :can't store them where? < 1456974337 386305 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :well, char * has no storage < 1456974359 289143 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :what the heck does that mean? < 1456974377 574336 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :suppose you have to save some text data inside a struct < 1456974393 313572 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :your options are like < 1456974448 771707 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :char text[99]; // + 1 million runtime checks and prayer and hope that it never goes over < 1456974521 663046 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :char *text; // and then make sure it's set to null in every single constructor and make sure it's deleted in the destructor and then checks that it's not null every time you read it and malloc/realloc if it ever changes size < 1456974552 366523 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :std::string text; < 1456974632 801448 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :it's just that option #3 has way less common failure modes than option #1 and option #2 < 1456974648 680731 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :std::string could be replaced with a bunch of funtions that take char* and handle everything you just said. < 1456974662 415503 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :\oren\ : yes that's option #2 < 1456974668 115945 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :char * in the class < 1456974683 63172 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :but the point is I already have such functions < 1456974711 815117 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :`addquote pikhq: The Google way isn't exactly NIH. They have their own variant of it. < 1456974718 374567 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :1270) pikhq: The Google way isn't exactly NIH. They have their own variant of it. < 1456974751 912147 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :\oren\ : and you never forget to put them in constructors, destructors, and to put checks against null? < 1456974792 375003 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :I don't have constructors or destructors, and all my string handling functions check for null < 1456974821 226407 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :(becuase I'm writing in C, which doesn't have constructors or destructors) < 1456974839 684021 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :\oren\ : well, when mallocating and freeing structs of that type then < 1456974851 687665 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :of the type that contains the char * < 1456974877 173448 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :well, since my usual first step is somthing like: < 1456974910 111705 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :struct foo *f = newfoo(); < 1456974919 61619 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :then , inside newfoo: < 1456974968 980952 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :struct foo *f = malloc(sizeof(struct foo)); *f = nullfoo; return f < 1456974990 282697 :oerjan!~oerjan@hagbart.nvg.ntnu.no QUIT :Quit: Late(r) < 1456975003 282761 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :that doesn't happen, becuase I have a prototype for all foo objects (nullfoo) < 1456975028 300199 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and you have a deletefoo() matching with every newfoo() ? < 1456975033 684933 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :yes < 1456975080 341128 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :yeah i guess that works < 1456975158 685974 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :I even have some functions that can delete an array, taking a pointer to a delete function to be called on each element < 1456975166 270645 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :and things like that < 1456975187 594642 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :makes sense < 1456975213 621658 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :it's an obvious extension of the precedent set by qsort and bsearch < 1456975235 834053 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :they just didn't bother with it in the C stdlib < 1456975257 18904 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :It's kindof the reverse of my coding style (which could be summarized as "avoid malloc/free unless there's really no other option") but I guess it's sorta functional < 1456975289 916805 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :it's what you do if you're writing C and not C++ < 1456975307 560298 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :which makes sense if you're doing embedded coding yes < 1456975541 242244 :nortti_!nortti@ayu.smar.moe JOIN :#esoteric < 1456975542 895390 :int-e_!~noone@static.88-198-179-137.clients.your-server.de JOIN :#esoteric < 1456975580 262551 :puck1pedia!~puck@irc.puckipedia.com JOIN :#esoteric < 1456975587 234234 :lambda-calc!~lambda-11@47.208.113.50 JOIN :#esoteric < 1456975587 801712 :lambda-11235!~lambda-11@47-208-113-50.erkacmtk03.res.dyn.suddenlink.net QUIT :Ping timeout: 260 seconds < 1456975588 877565 :aloril_!~aloril@dsl-tkubrasgw1-54fa3f-129.dhcp.inet.fi QUIT :Ping timeout: 260 seconds < 1456975589 357953 :puckipedia!~puck@irc.puckipedia.com QUIT :Ping timeout: 260 seconds < 1456975589 491164 :Gregor!dlopen@libdl.so QUIT :Ping timeout: 260 seconds < 1456975590 185480 :nortti!nortti@ayu.smar.moe QUIT :Ping timeout: 260 seconds < 1456975590 318879 :atehwa_!atehwa@aulis.sange.fi QUIT :Ping timeout: 260 seconds < 1456975590 452360 :catern!~catern@catern.com QUIT :Ping timeout: 260 seconds < 1456975590 585983 :quintopia!~quintopia@unaffiliated/quintopia QUIT :Ping timeout: 260 seconds < 1456975590 586066 :int-e!~noone@static.88-198-179-137.clients.your-server.de QUIT :Ping timeout: 260 seconds < 1456975612 243861 :Gregor!dlopen@libdl.so JOIN :#esoteric < 1456975655 359784 :bender|_!~benderx2@2404:e800:e61a:41d:ddbf:f4cc:366d:c672 JOIN :#esoteric < 1456975660 656183 :puck1pedia!~puck@irc.puckipedia.com NICK :puckipedia < 1456975686 420348 :aloril_!~aloril@dsl-tkubrasgw1-54fa3f-129.dhcp.inet.fi JOIN :#esoteric < 1456975866 137297 :atehwa!atehwa@aulis.sange.fi JOIN :#esoteric < 1456975888 997976 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1456975889 131556 :ais523!~ais523@unaffiliated/ais523 QUIT :Remote host closed the connection < 1456975890 378845 :j-bot!~j-bot@li1285-84.members.linode.com JOIN :#esoteric < 1456976264 663870 :quintopia!~quintopia@unaffiliated/quintopia JOIN :#esoteric < 1456976609 958069 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net JOIN :#esoteric < 1456976616 362688 :catern!~catern@catern.com JOIN :#esoteric < 1456977737 923694 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net QUIT :Ping timeout: 244 seconds < 1456978353 386115 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net JOIN :#esoteric < 1456978507 626245 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1456978549 475374 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :OK, so SFML uses a very thread-centric model < 1456978563 124043 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :e.g. there's no way to inject user-defined events, no way to do timers, etc. < 1456978611 907222 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :however, it /also/ doesn't define any safe way to communicate between threads, other than mutexes, and I don't think you can form the equivalent of a select() out of mutexes < 1456978628 647921 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ACTION is in #esoteric, and thus takes questions like "can you create a message queue out of nothing but mutexes" seriously < 1456978706 866413 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so the question is, what are the sensible cross-platform ways to merge events coming in from multiple threads, when your threading primitives suck? < 1456978824 655262 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :note: something you /could/ do entirely within SFML is to create a TCP listening socket and use that, but a) this uses up a global system resource (open ports), b) there's no way to restrict connections to localhost so it's more than a little insecure < 1456978835 553188 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(no way within SFML's API, that is; you can obviously do it in TCP) < 1456978894 266616 :coppro!~scshunt@taurine.csclub.uwaterloo.ca PRIVMSG #esoteric :ais523: define "out of nothing but mutexes" < 1456978924 662715 :coppro!~scshunt@taurine.csclub.uwaterloo.ca PRIVMSG #esoteric :are we talking about communication via try_lock()? < 1456978929 76139 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the only thread-safe blocking primitive that you have available is the mutex lock, which will block if another thread has the mutex locked < 1456978952 952230 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the problem isn't transferring the data, because you can do that via shared memory < 1456978957 83605 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(which is the default for threading) < 1456978972 258383 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the problem is blocking until there's a message ready to receive < 1456978975 848308 :coppro!~scshunt@taurine.csclub.uwaterloo.ca PRIVMSG #esoteric :ahhh < 1456978991 80767 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and AFAICT, the problem is that you can only try to lock one mutex at a time, a specific thread holds it < 1456979008 245350 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and so you're blocked until that specific thread gives you permission < 1456979012 230887 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(also you can't do anything meanwhile) < 1456979104 914901 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's basically the opposite situation to the situation for which mutexes were designed; we don't have one process holding the lock and many waiting on it, we have many processes holding the lock and one waiting on one of them to release it < 1456979109 551593 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :s/process/thread/ < 1456979167 122526 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :isn't SFML a multimedia library? < 1456979192 78862 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: yes < 1456979206 104052 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :however this means it contains an event loop < 1456979229 245205 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and its event loop uses a "use different threads for different sorts of events" model (implicitly in that it doesn't support timers, has sockets as a separate thing from windows, etc.) < 1456979238 627415 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it also supplies threads, and mutexes < 1456979252 346056 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but this isn't enough to be able to communicate between threads without polling AFAICT < 1456979296 303839 :coppro!~scshunt@taurine.csclub.uwaterloo.ca PRIVMSG #esoteric :ais523: yes, I don't think it's possible either < 1456979311 571897 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :I'm not familiar with how it's done in the networking world < 1456979316 500126 :coppro!~scshunt@taurine.csclub.uwaterloo.ca PRIVMSG #esoteric :mad: polling < 1456979323 505736 :coppro!~scshunt@taurine.csclub.uwaterloo.ca PRIVMSG #esoteric :under the hood, anyway < 1456979350 404559 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so what I want is either a solution a) inside SFML using other primitives it has (IMO impossible), or b) using cross-platform primitives that are widely implemented < 1456979376 374940 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I could use pthreads, I guess; however I don't know how that works on Windows/Strawberry < 1456979399 6849 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and/or how well it plays with SFML (which after all, has its own threading abstraction) < 1456979407 849453 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :wait, what's the thing you can't do with mutexes? < 1456979427 450813 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: block until something happens on any of multiple threads < 1456979451 920753 :coppro!~scshunt@taurine.csclub.uwaterloo.ca PRIVMSG #esoteric :ais523: semaphores < 1456979470 689150 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :coppro: semaphores would work fine, but SFML doesn't supply them as a primitive < 1456979478 133454 :coppro!~scshunt@taurine.csclub.uwaterloo.ca PRIVMSG #esoteric :ais523: most platforms do though < 1456979479 23474 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : oh I see < 1456979483 262826 :coppro!~scshunt@taurine.csclub.uwaterloo.ca PRIVMSG #esoteric :hence b) < 1456979491 893419 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : ...what's the application for that? < 1456979492 34487 :coppro!~scshunt@taurine.csclub.uwaterloo.ca PRIVMSG #esoteric :hard to find something more primitive < 1456979497 396456 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :right < 1456979524 55726 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: the situation is that I am writing a library (libuncursed; coppro's worked on it in the past too) that presents an event-loop interface to programs using it < 1456979536 917957 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and abstracts over a number of different backends (currently, POSIX, Windows, and SDL) < 1456979542 256142 :coppro!~scshunt@taurine.csclub.uwaterloo.ca PRIVMSG #esoteric :definitely semaphores < 1456979553 14591 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :hmm, how about < 1456979590 182061 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :event handling thread blocks on one mutex < 1456979591 145911 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there are others that could be sensible, too (e.g. X, GDI) < 1456979614 293968 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :any of the multiple other threads can unlock that mutex < 1456979622 429274 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can't unlock a mutex unless you hold it, surely < 1456979628 409443 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ACTION checks to see if SFML have messed this up < 1456979660 106052 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, it doesn't say that you can't unlock a mutex while another thread holds it < 1456979683 1232 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :perhaps it's worth experimenting with < 1456979700 818651 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :seems vulnerable to race conditions but that maybe isn't insoluble < 1456979706 428334 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :well < 1456979717 177948 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(e.g. using a separate mutex to protect the signalling one) < 1456979721 117782 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :that mutex would only be used to pause the event handling loop < 1456979771 13733 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so, let's see < 1456979773 939695 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :we have two mutexes < 1456979778 404654 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :each particular ressource would have its own mutex so that the owner thread of that ressource would unlock its ressource, then unlock the event handling thread's mutex < 1456979782 899750 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, bleh < 1456979786 247867 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :these mutexes are recursive < 1456979817 321404 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the obvious algorithm, assuming you can unlock someone else's mutex, ends with the event handling thread intentionally deadlocking on itself < 1456979822 556352 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but you can't do that with a recursive mutex < 1456979835 748721 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so we'll have to create a separate thread purely to deadlock it < 1456979894 897902 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so three locks (A, B, C), two "special" threads (event and deadlock), N generic threads < 1456979932 399954 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :netutral state is A locked by deadlock, event waiting on it; B locked by event, deadlock waiting on it; C unlocked < 1456979958 52924 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :when a generic thread wants to send a message, it locks C, pushes the message on a queue, unlocks A if the queue was empty (this is protected by C), unlocks C < 1456980035 931267 :XorSwap!~XorSwap@wnpgmb016qw-ds01-214-177.dynamic.mtsallstream.net JOIN :#esoteric < 1456980086 938530 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :when event gets past the deadlock, it locks C, and handles messages from the queue until it's empty; then, hmm < 1456980091 311083 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :SFML doesn't even have a trylock < 1456980102 153996 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :what sort of use is having a general event handling thread like that for? < 1456980107 978023 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so how do we get back into the deadlocked state? < 1456980153 94795 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: say you want to wait for a key to be pressed, or for 1 second to pass < 1456980164 525893 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and the timer thread and keypress handling thread have to be different for some reason < 1456980233 960530 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :that's a bit of a weird test case < 1456980238 70430 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :your two options are: run the entire logic of the program on whichever thread happened to be the one that received the event (key/timer); or send all the messages to the same thread < 1456980281 53841 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's not a weird test case at all, it's a common enough operation that, say, both ncurses and uncursed provide a function that does exactly that (although ofc the timeout's configurable) < 1456980298 969256 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :or for another example, say you want to wait for either a keypress, or receiving a network packet < 1456980344 118599 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :multimedia apps often just keep processing video frames and handke keypresses on next frame < 1456980368 918784 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that's a common way to write IRC clients (although in this case the responses to a keypress and to a network packet are different enough that you can run them on different threads without too much effort, that isn't something you should have to do) < 1456980435 460578 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: that's terrible for battery life, though < 1456980442 879755 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you want to be able to block until something happens, rather than having to poll < 1456980451 565976 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(in fact it's the reason I wanted to move away from SDL in the first place) < 1456980493 789721 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :I guess it depends on if you have the case where your app does nothing when there's no input < 1456980534 845657 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :which I guess is sensible for an irc client but not a game < 1456980558 689172 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: turn-based games often do nothing when there's no input < 1456980571 197356 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :unless they have audio < 1456980588 195224 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Different thread < 1456980605 883808 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :audio is one of those things that can safely be run in an independent thread, yes < 1456980616 877011 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :or interrupt-to-interrupt, on less powerful systems < 1456980625 780037 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :yeah but that means you have at least one always active thread < 1456980626 491941 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this is why it's often the only thing that works when the rest of the game crashes < 1456980643 560429 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: no? audio thread blocks until the sample buffer drains, typically < 1456980645 237598 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :which means that you might as well do polling on your event handler thread < 1456980652 147367 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there's only so much the audio thread can do before blocking < 1456980662 920969 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : yes, which happens at least 50 times per second < 1456980665 535384 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you're not running in a busy loop calculating samples < 1456980672 970956 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :do you have any primitive atomics on shared memory? < 1456980697 858997 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :also 50fps is still slower than a typical video framerate < 1456980707 614519 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :\oren\: std::atomic would work in this case, I think < 1456980711 703892 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :given that it's C__ < 1456980711 888290 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :(although last time I touched that stuff I got terrible radiation burns) < 1456980713 603509 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :* C++ < 1456980787 265574 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :depends on what you mean by "atomic" < 1456980836 898933 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: a variable that supports operations that cannot be interfered with by other threads < 1456980841 353910 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :for typical cases it's really the operations you do on your primitive that are atomic, I guess... and yeah I guess std::atomic does this for you < 1456980845 158340 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there are a range of atomic operations, some more useful than others < 1456980858 983393 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :test-and-set is a common example of a primitive that's powerful enough to build anything else < 1456980876 126736 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(set-to-specific-value, that is, not set-to-1) < 1456980903 296690 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :yeah, the equivalent of lock cmpxchg? :D < 1456980904 564424 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :yeah I think we used a swap operation in my OS class < 1456980929 714369 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :or maybe a compare and swap? < 1456980952 611541 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Surely CAS. Just swap isn't sufficiently general I don't think. < 1456980973 348970 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :pikhq: IIRC pure swap is sufficiently general, but much more complex to use < 1456980983 40479 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Ah, okay. < 1456980986 185029 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :I think it needs the compare to handle the case where some other thread has changed the value < 1456980993 568191 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :between the read and the write < 1456980997 130975 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :pikhq: you can construct a boolean test-and-set out of a swap by swapping in a 0 or 1 < 1456981007 182187 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :swapped-out value is the test, swapped-in value is the set < 1456981014 689146 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :And you don't find hardware without CAS really, so it's not worth the effort. < 1456981015 674105 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :yeah we used just swap < 1456981044 839953 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :the OS ran on some sort of virtual machine < 1456981055 85593 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you basically use the test-and-set as a mutex to guard a non-atomic operation on shared memory < 1456981063 595598 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think you might have to spin until the value is not set any more, though < 1456981084 559856 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :how does swap guarantee that some other thread hasn't changed the value after your read but before your write? < 1456981085 478846 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :yup, that's what we did, I remeber it now < 1456981109 305612 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: atomic swap guarantees that because atomic < 1456981127 876815 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :i think maybe it just freezes the other processors? who knows < 1456981129 979205 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, so SFML on Linux, at least, uses pthreads < 1456981149 182384 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :\oren\: it actually uses quite a complex locking mechanism internally < 1456981162 973798 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the processors will block on the lock on the memory address if they try to access the same address < 1456981169 382455 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there might also be some memory barriers involved < 1456981187 408966 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :well, in my course we were on a vitual machine, so who knows < 1456981192 639374 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : but you can't prevent the swap if the value has changed < 1456981200 29811 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: which value? < 1456981210 779793 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :suppose you're trying to do an atomic increment < 1456981214 542860 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :value is 0 < 1456981222 748926 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: you don't do the swap on the value you're incrementing < 1456981226 447159 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you do it on a second, guard value < 1456981237 251630 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which is 1 while in the middle of an increment, and 0 the rest of the time < 1456981243 905385 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :to increment, first you swap the guard value with 1 < 1456981248 896159 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :maybe cmpxchg is better for real processors because you don't need so much locking < 1456981267 395834 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :cmpxchg lets you have atomics without having a second guard value like that. < 1456981273 593896 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if you swapped a 0 out of it, then you do the increment, and swap a 0 back in (and will get a 1 after your swap unless shenanigans) < 1456981276 602026 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :\oren\ : cmpxchg lets you do atomic increment without a guard value yeah < 1456981290 121139 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if you swapped a 1 out of it, then you try again; you swapped a 1 with a 1 so you didn't interfere with the process that's currently doing the increment < 1456981309 82376 :\oren\!~oren@TOROON0949W-LP130-01-1242511664.dsl.bell.ca PRIVMSG #esoteric :so they made us do it with swap only because it's harder < 1456981312 872338 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :with compare-and-swap, what you do is you first (nonatomically) read the value, say it's x < 1456981321 230306 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :then you swap in x+1 if the current value is x < 1456981332 245450 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if you swapped an x out, everything is fine, you're done < 1456981333 182326 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : but what if you have a 1 and then a third thread comes in? then the third thread will see a false 0 < 1456981354 946028 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if you didn't, then try again, you didn't change anything as you did a read and a failed-CAS < 1456981360 476873 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: no it won't < 1456981396 905672 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :oh < 1456981402 258958 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :wait I guess I see < 1456981407 839236 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :here's my program: /*x*/ while (swap(guard, 1)); /*y*/ val++; /*z*/ swap(guard, 0) < 1456981430 197622 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :yeah that works if the cpu doesn't reorder memory writes < 1456981439 974607 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yep < 1456981443 379091 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and reads < 1456981450 403818 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and an atomic swap is normally assumed to contain appropriate memory barriers < 1456981458 460667 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :to protect anything that's ordered relative to it < 1456981469 107419 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :which means it should work on x86 but not necessarily other platforms < 1456981474 513988 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(either in the processor architecture itself, or because it's a wrapper for the instruction + the barrier) < 1456981496 631881 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :mad: The underlying instruction, sure, but any real-world use would have the appropriate memory barrier. < 1456981496 827749 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : as opposed to cmpxchg which.... doesn't really need barriers I think? < 1456981512 964263 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Because it's not at all helpful if it's not a synchronization primitive. :) < 1456981543 159009 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: well it depends on what the memory sequencing properties of the compare-and-swap are < 1456981553 511406 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it needs to contain at least a barrier on the things it's swapping < 1456981569 643572 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but really you need them in order to avoid time paradoxes < 1456981576 157106 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :well, the point of compare-and-swap is to have memory order guarantees against some other thread also doing compare-and-swap on the same value < 1456981594 644532 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :so presumably it has at least some kind of barrier against itself < 1456981625 891668 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :That's the "lock" prefix on x86. < 1456981638 371772 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :right < 1456981641 869926 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Without it, cmpxchg isn't atomic WRT other threads. :) < 1456981645 751054 :lleu!~gnomebad@unaffiliated/lleu QUIT :Quit: That's what she said < 1456981648 844645 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :something that happens in Verity at the moment (assignment in Verity is atomic but has no barrier): new x := 0 in new y := 0 in {{x := 1; y := 2} || {y := 1; x := 2}}; print(!x); print(!y) < 1456981661 574866 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :can print 1 1 even if you had a barrier betwen the parallel assignment and the prints < 1456981705 10740 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this is because there's no barrier between the assignments to x and to y, and in particular, the four assignments can happen /literally/ simultaneously, in which case it's unspecified which ones win < 1456981726 440982 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :that seems normal? < 1456981743 461686 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Yes, but it's weird to people used to x86's memory model. < 1456981755 669139 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: well there isn't any way to interleave {x := 1; y := 2} and {y := 1; x := 2} that leaves both variables set to 1 < 1456981768 34587 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :well < 1456981773 625824 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :x := 1 happens < 1456981783 41779 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :oh < 1456981804 254600 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Reordering is fun. < 1456981811 710935 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :pikhq: it's not even reordering < 1456981815 247946 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :the print() stuff happens on the 2nd thread? < 1456981815 730171 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's just simultaneity < 1456981823 942018 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: || is a thread split + join < 1456981824 408766 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :after the x:=2 < 1456981841 15856 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :where's the join? < 1456981849 412684 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :i.e. I temporarily fork into two threads, one does {x := 1; y := 2} and the other does {y := 1; x := 2} < 1456981851 968626 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :then the threads join < 1456981857 282621 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :|| is a fork + join operator < 1456981875 271489 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :I guess you're right, that can't happen in the x86 memory model < 1456981883 347453 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :unless the compiler reorders the writes < 1456981895 431714 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :(which afaik it totally can) < 1456981898 566005 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in Verity, the compiler doesn't reorder the writes, it's just that all four happen at the exact same time < 1456981918 225608 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: right, in gcc you'd need a compiler barrier < 1456981922 466533 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :The x86 memory model is one of the stronger ones out there. < 1456981927 911149 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :like "asm volatile ();" < 1456981937 885894 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :to prevent gcc reversing the order of the assignments to x and to y < 1456981943 662651 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :pikhq : they probably had no choice :D < 1456981951 702046 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :considering all the apps out there < 1456981960 705227 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well most programs out there at the time were single-threaded < 1456981961 907525 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :ais523: I'm not sure if that's actually a full compiler barrier. < 1456981967 978876 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :pikhq: err, right < 1456981971 960902 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :asm volatile (:::"memory") < 1456981973 79854 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :I tend to use asm volatile("" ::: "memory"); < 1456981979 81621 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Yeah. < 1456982025 213358 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :there's probably less compiler memory op reordering on x86 though < 1456982033 692349 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :due to the structure of the instruction set < 1456982036 278886 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :mad: It's actually a fairly arbitrary choice, given that it would *only* effect programs and OSes that were aware of multiprocessing, and when introduced this was very close to 0. < 1456982104 472310 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :I remember that when real multiprocessor systems started to happen there were a few apps that started failing < 1456982112 651129 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :not that many tho < 1456982156 916476 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, Verity's || operator was called , in Algol < 1456982162 429579 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Yes, they'd be ones that used threads incorrectly. < 1456982171 979419 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :Verity is an Algol derivative, after all, so it's not surprising it has one < 1456982188 763240 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :is {x := 1; y := 2} implicitly unordered? < 1456982188 896490 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :however, it's surprising that it isn't seen more often in modern languages < 1456982192 891299 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Hence why it would be not that many -- threading is a bit niche without multiprocessor systems. < 1456982193 152779 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: no, it's ordered < 1456982208 221958 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :assignment to x happens before, or simultaneously with, assignment to y < 1456982228 299070 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :'or simultaneously with' < 1456982247 994933 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :a write to a variable cannot happen simultaneously with a write or read that comes earlier < 1456982261 454577 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and if a write and read happens simultaneously you get the new value < 1456982265 410141 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there, those are Verity's timing rules < 1456982274 70028 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :ais523: Huh, that's actually kinda-sorta related to C's , introducing a sequence point, then, isn't it? < 1456982278 526643 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(by simultaneously, I mean on the same clock edge) < 1456982288 218225 :pikhq!~pikhq@2601:647:4b00:63aa::f63 PRIVMSG #esoteric :Erm, no, no it isn't. < 1456982308 550209 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :pikhq: for if you want even more detail on how it works: < 1456982320 266546 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's call-by-name so naming a variable can be seen a bit like a function call < 1456982328 67114 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and the same call can't return twice on the same cycle < 1456982347 603948 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :however, for "simple" reads of variables the call can be optimized out < 1456982375 151580 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(it just looks at the bits in memory directly) < 1456982410 970764 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :if all read/writes in a group are to different variables, they can happen all at the same time? < 1456982417 279612 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes < 1456982429 123535 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :then I guess they can be reordered no? :D < 1456982438 787807 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :"the same call can't return twice on the same cycle" is the /only/ rule slowing the program down (apart from some corner cases wrt recursion) < 1456982444 441768 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: no, in x := 1; y := 2 < 1456982449 520990 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the write to y can't happen before the write to x < 1456982457 990724 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it happens simultaneously (same clock cycle) or later < 1456982488 759132 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :hm < 1456982490 983433 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(in this particular case it would be simultaneous because 2 is a constant, and thus there's nothing that could delay the write to y) < 1456982569 339426 :bender|_!~benderx2@2404:e800:e61a:41d:ddbf:f4cc:366d:c672 NICK :bender| < 1456982577 802577 :bender|!~benderx2@2404:e800:e61a:41d:ddbf:f4cc:366d:c672 QUIT :Changing host < 1456982577 935944 :bender|!~benderx2@unaffiliated/bender/x-9459530 JOIN :#esoteric < 1456982583 496723 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :what if you had x := some_calculation; y := 2 < 1456982584 87883 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :? < 1456982586 82813 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :fwiw I consider this behaviour to potentially be a bug, but we've decided that for the time being at least it isn't (also it makes the program run faster, which is a good thing in the abstract) < 1456982601 933741 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: x and y would be assigned at the same time, when the calculation completed < 1456982619 334997 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :meanwhile x := 2; y := some_calculation would assign x first, start the calculation that cycle, and assign y when the calculation completed < 1456982624 468647 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which might or might not be that cycle < 1456982632 767639 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :what about < 1456982646 495945 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :x := some_calculation; y := some_calculation < 1456982648 551490 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :? < 1456982688 798212 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :how much of y's calculation can overlap with x's calculation? < 1456982695 571337 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :runs the calculation, when it finishes delays one cycle; then assigns the result to x and starts running the calculation again, when it finishes assigns the result to y < 1456982732 743722 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :note the "delays one cycle", this is automatically inserted to fulfil the rule that prevents the same block of code being used for two different purposes at the same time < 1456982749 564522 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :what about < 1456982756 437646 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :x := some_calculation; y := some_other_calculation < 1456982772 963017 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :those could happen on the same cycle (unless the two calculations involve shared resources) < 1456982782 325149 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ah ok < 1456982783 946817 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :I see < 1456982785 762440 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :obviously, they only would if some_other_calcuation took zero cycles < 1456982800 302537 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :as some_other_calculation doesn't start until some_calculation has finished < 1456982802 417621 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and to complete the set < 1456982810 808886 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :x := some_calculation || y := some_other_calculation < 1456982824 142961 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :would run both calculations in parallel regardless of what arguments they took or how long they took < 1456982877 133771 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :is this designed for some specific piece of hardware? :D < 1456982959 638684 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :pretty much the opposite: it designs specific pieces of hardware < 1456982969 96949 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :to run the program you entered < 1456982977 676974 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :e.g. via programming an FPGA < 1456982986 660685 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :does it compile to verilog or something like that? < 1456982989 238680 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yep < 1456982992 930325 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :VHDL, in this case < 1456983003 638630 :lynn!~lynn@unaffiliated/lynn JOIN :#esoteric < 1456983027 791652 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and ofc the big advantage of designing hardware is that you can do things in parallel for free < 1456983036 168668 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so long as you don't need access to shared resources < 1456983077 100300 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :mhm < 1456983078 724713 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :one of my coworkers is looking into rewriting "x := a; y := b" as "x := a || y := b" if it can prove that the two programs always do the same thing < 1456983092 564639 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which would give a big efficiency gain without requiring people to place all the || in manually < 1456983111 890011 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :that sounds like an aliasing resolution problem < 1456983130 269003 :dingbat!uid70835@gateway/web/irccloud.com/x-zxuiakmfhjpgzmxz QUIT :Quit: Connection closed for inactivity < 1456983217 316708 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :the standard approach to that is renaming but then it can parallelize the variables but not the name changes < 1456983218 405968 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well, much of our theoretical research has been in that direction < 1456983233 895694 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in particular, we statically know whether any two things can share or not < 1456983248 483995 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :we don't have aliasing problems because Verity disallows storing anything other than integers in pointers < 1456983255 979624 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :*integers in variables < 1456983261 55476 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(in particular, you can't store a pointer in a variable) < 1456983398 40404 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :how does it know what to put in dram, block ram and in logic fabric registers? < 1456983560 324416 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :arrays go in block ram, non-array variables in logic fabric (unless a large number of copies are required due to, e.g., them being local to a recursive function) < 1456983571 235259 :lambda-calc!~lambda-11@47.208.113.50 NICK :lambda-11235 < 1456983572 333916 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :dram isn't used by the language itself but you could write a library to access it < 1456983591 793974 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(assuming you're talking about external ram) < 1456983599 65764 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :("d" could expand in more than one way here) < 1456983910 182896 :bender|!~benderx2@unaffiliated/bender/x-9459530 QUIT :Remote host closed the connection < 1456983937 609223 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :is "array[x] := n || array[y] := m" a compilation error? < 1456983999 974693 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes but only because arrays use () for indexing rather than [] < 1456984022 669019 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although, interestingly, "array(x) := n || array(y) := m || array(z) := l" will give you a warning < 1456984044 638060 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the reason is that you can't do more than two writes to block RAM simultaneously in hardware < 1456984059 443170 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :yeah obviously < 1456984065 991770 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and thus it has to add extra components to serialize the writes so that no more than two happen at a time < 1456984120 450159 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :what mode does it use the bram's port in? read_before_write? < 1456984143 789684 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :"warning: made 3 copies of an array's read/write ports" "info: at most two read/write ports can be supported efficiently" < 1456984150 347959 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and read-before-write, yes < 1456984167 128543 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :not that it matters, all that changes is the behaviour in race conditions < 1456984237 22470 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that said, I'm currently working on implementing pipelining < 1456984260 4258 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in which case "array(x) := n || array(y) := m || array(z) := l" would do the writes on three consecutive cycles and thus you wouldn't get the warning < 1456984283 173993 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :but then your throughput would go down :D < 1456984401 325902 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes; this is something we might want to look at later < 1456984587 484689 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :I've been really into trying to find an alternative to RISC/CISC/VLIW for practical CPUs < 1456984709 939646 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :it's hard to balance between too static-scheduled (VLIW being simple but stalling easily etc) and too dynamic-scheduled (RISC/CISC start breaking down majorly over about 4 instructions per cycle) < 1456984753 744817 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :as this is #esoteric, I'm wondering if there are any other alternatives < 1456984776 69930 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :even if it's a pretty hppavilion[1] reaction to the problem < 1456984786 282031 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :I have some interesting designs but nothing approaching the simplicity of RISC < 1456984821 141254 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :what about a CPS processor? < 1456984834 442679 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :i.e. "run this command, once it finishes running, do this other thing next" < 1456984845 749857 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although that's pretty similar to hyperthreading, really < 1456984864 831866 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :it falls down on what exactly a "command" is :D < 1456984870 74596 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and there's a reason processors don't run entirely on hyperthreading < 1456984912 784997 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :I thought hyperthreading was basically just a way to keep the cpu active when loads have fallen out of data cache and it's that or stalling < 1456984916 223819 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric ::D < 1456984949 787537 :XorSwap!~XorSwap@wnpgmb016qw-ds01-214-177.dynamic.mtsallstream.net QUIT :Quit: Leaving < 1456984958 137817 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :or, in the case of sparc, a way of wiggling their way out of doing an out-of-order while keeping okay performance :D < 1456985012 42743 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : what runs in parallel in a CPS processor? < 1456985052 573365 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: I guess you can start multiple commands (well, opcodes) running at the same time < 1456985058 464497 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :basically via the use of a fork opcode < 1456985082 794693 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the question is, do we also need a join, or do we just exit and run the code for its side effects? < 1456985098 727648 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :how do you tell if the opcodes are truly independent or have dependencies? < 1456985161 922991 :lynn!~lynn@unaffiliated/lynn QUIT :Read error: Connection reset by peer < 1456985195 339473 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :the approach I've been looking at is extremely small "threads" < 1456985202 404454 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :like, 3 instruction long for instance < 1456985244 679525 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you don't have to, you just run them whenever they become runnable < 1456985276 500035 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I guess that if you add join, this is basically just a case of an explicit dependency graph < 1456985288 837492 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :if your commands do loads/stores on the same memory you need to know what happens < 1456985293 144183 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which is a bit different from VLIW < 1456985300 187426 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but similar in concept < 1456985334 580139 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :VLIW dependency is handled by keeping everything in some exact known sync < 1456985393 314872 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :compiler scheduler knows the sync and fills the instruction slots < 1456985425 326447 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :generally it works well for DSP code (lots of multiplies and adds etc) but not well at all for load-store-jump code < 1456985433 305931 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :which is why VLIW is typically used in DSPs < 1456985464 77570 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ah right < 1456985470 253458 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well I'm basically thinking of the Verity model but on a CPU < 1456985493 507397 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :some CPUs simply run all loads and stores in-order < 1456985496 427573 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :if two things don't have dependencies on each other, you run them in parallel < 1456985504 457985 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :everything else can be reordered willy-nilly though < 1456985540 756629 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this means that the CPU needs to be able to handle large numbers of threads at once (probably a few hundred in registers, and swapping if the registers get full), and needs very cheap fork/join < 1456985543 571234 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : true, but if your two things are memory addresses calculated late in the pipeline, it's very hard to tell that they have dependencies < 1456985555 803171 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :OTOH, so long as you have enough threads available, you don't care much about memory latency, only bandwidth < 1456985566 43189 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :just run something else while you're waiting < 1456985579 3486 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this is similar to GPUs but GPUs are SIMD at the lowest levels, this is MIMD < 1456985600 522411 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: well the dependencies would be calculated by the compiler < 1456985616 280869 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :compiler can only calculate so many dependencies < 1456985619 823201 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :ideally via the use of a language in which aliasing problems can't happen < 1456985642 275688 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :ais523: ALIW and OLIW are some alternatives to RISC, CISC, and VLIW < 1456985643 113671 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :in fact the ideal situation for the compiler is that loads and stores never move < 1456985654 679205 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :every other instruction is easy to move < 1456985670 551766 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in most practical languages, though, loads and stores happen a lot < 1456985682 844101 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hmm, can we invent some sort of functional memory for functional languages? < 1456985684 513572 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :it's just calculations and it's all in SSA form so it knows exactly what depends on what and how to reorder stuff < 1456985693 345593 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :i.e. memory never changes once allocated, it can go out of scope though < 1456985699 227192 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :ais523: I thought of that once- the ASM of Haskells < 1456985708 673825 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :what I was thinking of was C++ with absolutely no pointers < 1456985722 861094 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :just use Verity :-P < 1456985723 458611 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and every object or array is copy-on-write < 1456985731 745412 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there have been some experiments of getting it to run on CPU < 1456985762 568617 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :no dynamic typing or garbage collection or other slow features < 1456985775 903303 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :ais523: What other properties should the FMM have? < 1456985787 24562 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :only copy-on-write because it's the one thing that can prevent aliasing < 1456985801 162980 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hppavilion[1]: FMM? < 1456985808 7427 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :ais523: Functional Memory Model < 1456985826 197621 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: not the only thing, you can use clone-on-copy instead < 1456985829 750354 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's just slower usually < 1456985856 202422 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(it's faster for very small amounts of data, around the scale of "if you have fewer bits in your data than you do in an address") < 1456985861 887190 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :but then don't you need references if you use clone-on-copy < 1456985865 348902 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :? < 1456985910 695315 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :references so that you can point to objects that you're going to read from without doing tons of copies < 1456985920 117843 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I didn't say it was efficient < 1456985922 830119 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :just that it works < 1456985951 632933 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :that's why I'm suggesting copy-on-write < 1456985966 437667 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :hppavilion[1]: the main problem with a functional memory model is handling deallocation < 1456985979 151620 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you can a) use reference counts, b) use a garbage collector, c) clone on copy < 1456985994 382445 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :method c) is used by most esolang impls AFAIK < 1456986015 336114 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :what do haskell etc use? < 1456986067 477396 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net PRIVMSG #esoteric :ais523: Interesting... < 1456986104 89730 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: normally garbage collectors, for most workloads it's the most efficient known solution < 1456986117 326198 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although it requires a lot of complexity to get it more efficient than reference counting < 1456986161 387304 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :can functional programming generate cycles? < 1456986163 624018 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I personally like reference counting, especially because it allows you to implement an optimization whereby if something is unaliased at runtime (i.e. the reference count is 1), you can just change it directly rather than having to copy it first < 1456986187 516991 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :that's what copy-on-write is no? < 1456986207 830642 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there are language features which can cause cycles to be generated; however, some functional languages don't include those features < 1456986242 94231 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :copy-on-write doesn't necessarily check for refcount 1, some implementations check for never-cloned instead < 1456986265 50832 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which means that you don't have to update the refcount when something leaves scope < 1456986281 149429 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :but what if it was cloned but then the clone went out of scope? < 1456986287 53941 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :then you have a useless copy < 1456986290 459248 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yep < 1456986307 504057 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but without a refcount you don't know it's useless until the next gc cycle < 1456986346 187478 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :the idea of having COW everything is that also when you need a copy, typically you only need a copy of the topmost layer < 1456986358 285527 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's possible that the extra copies are faster than the refcount updating < 1456986362 231960 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ie an object containing a bunch of sub-objects < 1456986374 750452 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :most likely because you're just copying a wrapper that contains a couple of pointers < 1456986384 81446 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :if you have to copy the object, you don't need any copy of the sub-objects < 1456986391 592215 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :except the ones that are really different < 1456986392 423164 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and yes, I think we're making the same point here < 1456986453 401704 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :how expensive is refcounting anyways? < 1456986457 865569 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :it's just +/- < 1456986473 691077 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it's pretty expensive because it screws up your cache < 1456986492 257280 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :whenever something gets copied or freed, you have to a) dereference it, b) write a word of memory next to it < 1456986517 188422 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :which means that less fits in your cache, and copy and free operations end up bumping something into cache that isn't immediately needed < 1456986527 406971 :mysanthrop!~myname@84.200.43.57 NICK :myname < 1456986528 201320 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :isn't it reading in 1 cache line that's probably going to be read by whatever next object operation on that object? < 1456986542 497530 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :for a free, you probably aren't planning to use the object again for a while ;-) < 1456986600 728020 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :well, for a free you start by -- refcount, checking it, it's 0, then you have to go through the whole destructor so that's more accesses to object variables no? < 1456986702 739684 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :oh, you're assuming there's a nontrivial destructor < 1456986714 651016 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm not, destructor is often trivial < 1456986743 804519 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :well, it must decrease child object refcounts no? < 1456986751 955458 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes, /but/ we're comparing refcounting to GC < 1456986754 589130 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and eventually call free() < 1456986761 245137 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :GC doesn't need to decrease the child object refcoutns < 1456986827 199813 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so it doesn't have a need to pull the object into cache < 1456986850 38900 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :fwiw, I think there's little doubt that refcounting is better if you have a lot of nontrivial destructors < 1456986855 449934 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but that doesn't come up very often < 1456986882 936140 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :hmm < 1456986937 824243 :lambda-11235!~lambda-11@47.208.113.50 QUIT :Quit: Bye < 1456987020 74741 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :it sounds like it depends on the "shape" of the objects you're freeing < 1456987034 993847 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :depending on average size and average number of levels < 1456987113 553738 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :other issue is < 1456987130 920957 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :suppose you have some large global object with some error logger in it < 1456987167 770902 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :some function of some small object within that global object does whatever < 1456987173 66083 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and then logs an error < 1456987209 962100 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :how do avoid forcing the user to make the function take the large global object as an explicit argument? :D < 1456987261 34303 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :this is one of the largest problems in OO, possibly programming generally < 1456987272 237559 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there are a lot of proposed solutions but I'm not sure if any of them are actually good ones < 1456987306 240869 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :I know only the C++ solution, which is that you store a pointer to the large global object in the small object < 1456987313 87325 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :but then that breaks any purity < 1456987338 924129 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :look up dependency injection, it's crazy < 1456987358 978462 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and it introduces a reference cycle < 1456987379 946180 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :err, dependency injection frameworks < 1456987391 199859 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :dependency injection itself is just the concept of passing the large global as an argument < 1456987399 151023 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but the interest comes from doing it /implicitly/ < 1456987416 59600 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :normally via some sort of code transformation, either at compile-time or run-time < 1456987419 470559 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(which is why it's crazy) < 1456987460 888117 :nortti_!nortti@ayu.smar.moe NICK :nortti < 1456987577 535817 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :anyhow < 1456987624 949245 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :without solving aliasing then basically you're designing a cpu for executing C++ < 1456987674 316499 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and I don't think it's possible to design a cpu for higher level languages < 1456987711 131799 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :because C++ tends to have all the real low latency operations basically < 1456987738 948037 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and in particular the ones that have few sideeffects < 1456987744 739930 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :side effects are deadly < 1456987826 963995 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well I don't think a language can be considered higher-level nowadays if it doesn't provide at least some way to manage side effects < 1456987863 123638 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :dunno, aside from functional languages < 1456987883 841511 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :my impression is that most high level languages have great tools for CAUSING side effects < 1456987887 777539 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric ::) < 1456987922 383109 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :witness all the perl-python-lua-js type of languages that never even got multithreading < 1456988111 11031 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :I can't think of any approach other than multithreading and functional-style-purity for managing side effects < 1456988132 31202 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :especially long-term side effects < 1456988185 960483 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :for short term side effects generally you have the whole LLVM style thing where it uses SSA on non-memory values and then LLVM-style alias resolution loads/stores < 1456988193 61464 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and...that's it! < 1456988247 313438 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :unless you count SIMD as a form of side-effect management < 1456988252 351823 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :(which I guess it is!) < 1456988284 988967 :dingbat!uid70835@gateway/web/irccloud.com/x-vxvtzqcbhsrtdwzn JOIN :#esoteric < 1456988470 971577 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :that's why the MIPS is still the "top" design in a way < 1456988490 17036 :Sprocklem!~sprocklem@unaffiliated/sprocklem JOIN :#esoteric < 1456988672 273555 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: well Verity compiles via an intermediate language SCI, which has the property that aliasing will fail to compile < 1456988691 802360 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :although it sacrifices quite a lot to accomplish that < 1456988699 293793 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :figures < 1456988754 721427 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :well, it compiles to vhdl so it's essentially a low level language no? < 1456988755 24777 :carado!~carado@savhon.org JOIN :#esoteric < 1456988810 272795 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: Verity is low level, yes < 1456988824 982342 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :however the principles behind SCI were originally expressed in a language which was (at the time, at least) pretty high level < 1456989040 182855 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :if you're going towards agressive threading then the target kind of cpu is pretty clear < 1456989050 973738 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :stick in a bunch of in-order RISCs < 1456989058 693461 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :as many as you can fit < 1456989092 694590 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :each new core = new DCACHE = 1 more potential load per cycle < 1456989110 551098 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :or 2 loads if you have a 2 port DCACHE < 1456989158 534477 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I think you also need to have more threads "ready to go" than you do CPUs < 1456989166 276740 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :yeah < 1456989173 87311 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so that you can suspend some while waiting for memory access, branch prediction failure, etc. < 1456989179 387839 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :you'll probably want some degree of hyperthreading to fill in stalls < 1456989181 890351 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :yes < 1456989189 172174 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually if you have enough hyperthreads you needn't even bother to predict branches < 1456989199 694090 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :just run something meanwhile while working out whether to take them or not < 1456989214 895694 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :hm < 1456989268 755526 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :I think the branch predictor is worth the trouble < 1456989281 608187 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :it's not that complex at low IPC < 1456989305 387135 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :also at low IPC your pipeline is likely to be short < 1456989360 812582 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :this is basically the ultraSPARC < 1456989388 347391 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :oriented towards load-store-jump code that has lots of threads < 1456989391 667854 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ie servers < 1456989446 379949 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you could totally write a compiler to use lots of threads if they were that lightweight < 1456989454 411086 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and they'd be very load-store-jump-mimd heavy < 1456989495 512153 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :you'd need some sort of threading that doesn't have to go through the OS's scheduler < 1456989548 129538 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and get people to use tons of small threads in their code < 1456989562 493575 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes < 1456989575 786154 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the latter is something that'll be increasingly necessary to increase performance as time goes on < 1456989599 290851 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and hardware thread scheduling is a natural extension of that < 1456989620 378292 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :the problem is that generally if the OS's scheduler is involved, that probably already wipes out your potential benefits in lots of cases < 1456989642 571601 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :ais523: have you looked at Rust? I don't remember if it came up yet and whether I've told my first impression opinions. < 1456989647 247064 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :also there's a limit to how much threading you can get going < 1456989668 695789 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: yes, this channel used to have a lot of rust discussion < 1456989671 951661 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :every cpu you add to a system makes the synchronization system between core memories harder < 1456989673 29226 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I like it < 1456989684 833810 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that said, I don't think I know your opinion on Rust, either because you haven't told me or because I've forgotten < 1456989695 572438 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: NUMA < 1456989728 632645 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :that's starting to sound like the PS3's CELL :D < 1456989791 828482 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :it was ahead of its time < 1456989831 290348 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :NUMA is going to get more and more popular as time goes on, basically because there just isn't really any other option if we want computers to keep getting faster in terms of ability-to-execute-programs < 1456989851 444054 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :there's always aggressive SIMD < 1456989888 37543 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :which gives you nothing for load-store-jump programs < 1456989907 223307 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :but I don't think anything's going to help load-store-jump programs by this point < 1456989955 224554 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :mad: simd and numa have different roles. they both help, and I'm very interested in simd, but at some point even if you write optimal simd programs to reduce memory and cache load, you'll run out of memory bandwidth, and numa is the only technically realistic way to increase it < 1456989962 189688 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the problem with SIMD is that although it's good for some workloads, those are typically the workloads you'd run on a GPU < 1456989975 108946 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :ais523: that's not quite true < 1456989978 595489 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so it's more of a stopgap until people get better at writing multithreaded programs < 1456989980 321471 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :ais523: no way < 1456989991 906675 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :CELL worked because video games have some mathy calculations to offload < 1456990017 887445 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :ais523: it's that people are buying into the GPU hype and very few people are trying to learn to actually use SIMD and cpu programming in a good way < 1456990036 190616 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :(this is partly why I'm very interested about it) < 1456990043 363028 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :you can put hundreds of cores on a CPU if they can't access any memory :D < 1456990053 290828 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :ais523: yes, there's some overlap, but still, I don't think GPUs will solve everything < 1456990079 588779 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :gpus solve one problem, rendering video games < 1456990110 705544 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :other problems might see a speed gain only as much as they look like video game rendering :D < 1456990114 255312 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :GPUs actually have similar levels of SIMDiness to CPUs; their strength is that they can run the same code on thousands of threads, but not necessarily with the same control flow patterns < 1456990152 795844 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :as far as I can tell the GPU's advantage is that basically memory writes only happen to the frame buffer < 1456990158 371222 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :they're bad at pointer-heavy stuff, and in general, at things with unpredictable memory access patterns < 1456990164 587548 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :so GPUs have essentially no aliasing to solve < 1456990195 14581 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: they have block-local storage, which is basically a case of manually-controlled caching < 1456990201 323240 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :where you load and flush the cache lines manually < 1456990215 20767 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :once aliasing comes into the picture (or heavy feedback loops) CPUs take the upper hand afaik < 1456990246 782372 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :I might be dismissing gpu stuff too much due to how overhyped it is < 1456990268 117587 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: it's mostly just that GPUs are bad at pointers < 1456990287 73948 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :it comes down to how few GPU-able problems there are I think < 1456990287 611527 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :aliasing isn't any harder than dereferencing nonaliased memory, they're both hard < 1456990339 305345 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :aliasing forces your memory operations to be in-order basically < 1456990356 649517 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and adds lots of heavy checks the more you reorder your operations < 1456990388 714425 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :eventually you end up with giant content-addressable-alias-resolution buffers and whatnot < 1456990411 893355 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and everything becomes speculative < 1456990431 318742 :mroman!~mroman@160.85.232.90 JOIN :#esoteric < 1456990457 441638 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :well how useful is unpredictable aliasing from a program's point of view? < 1456990465 999064 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :b_jonas: SIMD is a good fit for "occasional", "one-off" computations. GPGPU is a good fit for "pervasive" large computations. people seems to easily confuse the differences. < 1456990497 311253 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :lifthrasiir: hmm: what would you say is the best way to zero a large amount of RAM? < 1456990499 670805 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : it's mandatory to guarantee correctness < 1456990506 150963 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :(and when one needs occasional large computations, one is advised to avoid them) < 1456990508 20836 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: not from the compiler's point of view < 1456990509 607626 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :the program itself < 1456990522 128770 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :how often do you write a program that benefits from aliasing, and can't predict where it happens in advance? < 1456990528 750939 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :ais523: DMA. < 1456990531 231021 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :sorry, kidding! < 1456990542 829357 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :lifthrasiir: that didn't seem that stupid to me < 1456990545 261966 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :well < 1456990558 528785 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I was actually thinking that systems might benefit from a dedicated hardware memory zeroer < 1456990570 133568 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :Windows apparently zeroes unused memory in its idle thread < 1456990578 220671 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :ais523: but I think it is not a good way to approach the problem. why do you need a large amount of zeroed memory after all? < 1456990589 122760 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :as something to do (thus it has a supply of zeroed memory to hand out to programs that need it) < 1456990619 465471 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :then I guess SIMD or other OS-sanctioned approach is the necessary < 1456990625 328556 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :lifthrasiir: basically a) because many programs ask for zeroed memory; b) you can't give programs memory that came from another program without overwriting it all for security reasons, so you may as well overwrite with zeros < 1456990626 809160 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :GPGPU is not really an option there < 1456990631 194517 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :well, if you write to a variable, eventually you're going to want to read from it < 1456990640 688218 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :fundamentally that's aliasing < 1456990646 441570 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :GPGPU could zero GPU memory quickly just fine; the problem is that it uses different memory from the CPU < 1456990650 819626 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :and the copy between them would be slow < 1456990658 993021 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :yes. that's why it is not an option < 1456990660 833638 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :(right now) < 1456990698 713215 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :DMA is a joke, but the hardware-wired way to zero memory may be somehow possible even in the current computers < 1456990703 932946 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: yes but often both pointers are literals (because you use the same variable name both times), so the aliasing is predictable < 1456990711 867940 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :for instance, a delay buffer for an echo effect < 1456990724 701004 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :how fast it aliases depends on the delay time you've set < 1456990751 586057 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :yes, that's a good example of a "memmove alias" < 1456990759 638275 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : aliasing isn't predictable if you use very large array indexes :D < 1456990783 749491 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm kind-of wondering, if restrict was the default in C, how often would you have to write *unrestrict to get a typical program to work < 1456990789 880957 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: larger than the array, you mean? :D < 1456990834 397086 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :yeah but the cpu doesn't know the array size < 1456990843 794823 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :most of the time even the compiler doesn't know < 1456990861 308696 :tromp!~tromp@ool-18be0bd8.dyn.optonline.net QUIT :Remote host closed the connection < 1456990872 985345 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: well that at least is clearly something that can be fixed by higher-level languages < 1456990880 677076 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :there's also the case of, well, you're accessing a class that has pointers in it < 1456990898 354866 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and it's hard to tell when your code will read out one of those pointers and write to that data < 1456990934 307051 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :you do know what restrict means, right? < 1456990941 542411 :AnotherTest!~turingcom@2a02:2c40:400::1:6e46 JOIN :#esoteric < 1456990954 185705 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :"data accessible via this pointer parameter will not be accessed without mentioning the parameter in question" < 1456990955 817789 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : higher-level languages can abuse references to cause surprise aliasing < 1456990985 17218 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :I wasn't aware of the exact semantics of restrict < 1456990987 722641 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :example? mostly because it'll help me understand what you're considering to be higher-level < 1456991044 180406 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :hmm < 1456991055 763891 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :consider a java function working on some array < 1456991063 661650 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :“ [GPUS] they're bad at pointer-heavy stuff, and in general, at things with unpredictable memory access patterns” – are they also bad at unpredictable local sequential access of memory, such as decoding a jpeg-like huffmanized image that's encoded as 256 separate streams, you have an offset table for where the huffman input of each stream and the output of each stream starts, < 1456991078 802946 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :and within one stream, you can read the huffman input and the output pixels roughly sequentially? < 1456991081 735886 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :then it reads some member variable in one of the objects it has as an argument < 1456991103 481395 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :the member variable is a reference to the same array the java function is working on < 1456991109 137307 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and it uses it to poke a value < 1456991138 104014 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :“ I'm kind-of wondering, if restrict was the default in C, how often would you have to write *unrestrict to get a typical program to work” – isn't that sort of what Rust is about? < 1456991142 550151 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: so long as what you're indexing is either a) stored in memory that's fast to read but very slow to write, or b) fits into block memory (basically a manually-controlled cache), you can dereference pointers < 1456991162 585393 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :and I don't think that's how restrict in C works < 1456991162 820122 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: it's similar, yes < 1456991185 552827 :AnotherTest!~turingcom@2a02:2c40:400::1:6e46 QUIT :Ping timeout: 240 seconds < 1456991198 116231 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: that's nothing to do with Java being high-level, IMO < 1456991215 427771 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :this example applies to most non-pure languages < 1456991223 137372 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :storing a reference to something inside the thing itself is a pretty low-level operation < 1456991225 614177 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :like perl and python and whatnot < 1456991227 77556 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :afaik < 1456991243 297347 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :well, your function gets some array argument < 1456991244 605985 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually, if you do that in Perl, you're supposed to explicitly flag the reference so as to not confuse the garbage collector < 1456991250 216570 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and some object < 1456991253 468400 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :*reference counter < 1456991263 333885 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and the object has a reference to the array but you don't know < 1456991305 837123 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :ais523: well, if there are 256 streams, and you're decoding only one channel at a time and assembling the three channels later in a second pass, then each stream should be at most 8192 bytes long, its output also 8192 bytes long, plus there's a common huffman table and a bit of control information. < 1456991316 22485 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :there's no self reference in my example < 1456991346 584284 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: well, say, in SCI (which is designed to avoid aliasing), if you give a function two arguments, any object can only be mentioned in one of the arguments < 1456991348 794968 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :Oh, and some local state for each 8x8 block that might take say 512 bytes. < 1456991355 278777 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :b_jonas : isn't hufman decoding inherently sequential? < 1456991366 365291 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :(I'm assuming a 2048x1024 pixel image, 8 bit depth channels.) < 1456991391 741733 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :mad: yes, but if you use a shared huffman table and you mark where each stream starts in the input and output, then you can decode each stream separately < 1456991420 492552 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :mad: that is actually practicaly for image decoding, and also for image encoding or video de/encoding, but those get MUCH hairier and more complicated < 1456991422 200629 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : if it avoids aliasing then it's in a different category < 1456991440 279529 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: I'm saying that putting limits on aliasing is higher-level than not putting limits on aliasing < 1456991446 26019 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :mad: note that this is pure huffman encoding, like jpeg, not deflate-like copy operations from a 16k buffer of previous output. < 1456991448 689664 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because it means that you have more information about the data you're moving around < 1456991467 951149 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :mad: the copy operations are why PNG/zip decompression is really impossible to parallelize or implement fast these days < 1456991499 394996 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :gzip/zip/PNG made lots of sense when they were invented, but less sense for today's hardware < 1456991523 191567 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :b_jonas: deflate uses references to locations earlier in the output, right? how much would it change if it used references to locations as they were in the input file? < 1456991523 698662 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :but JPEG is just as old and ages much better, which is why most modern video formats are similar to it, even if different in lots of specifics < 1456991537 417663 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :in terms of compression ratio < 1456991537 612773 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :b_jonas : I guess it works if you have multiple huffman segments that you know the start of < 1456991564 403188 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :ais523: I'm not sure, I don't really know about modern compression algorithms, and it probably depends on what kind of data you have. < 1456991570 109544 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :that seems to be GPU-acceleratable, although I haven't worked out the details yet < 1456991570 820467 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :mad: actually I managed to persue my friend to write the similar thing with the existing deflate stream < 1456991612 80194 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :doesn't every huffman symbol basically depend on the previous one? < 1456991622 771880 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :ais523: encoding a video also references previous frames, but in a way than I think is much nicer than gzip, because you only reference one or two previous frames, so you can decode per frame. it might still get ugly. < 1456991625 259000 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :or specifically the length of the previous one < 1456991646 348486 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :mad: the point is that DEFLATE uses the end code that is distinctive enough that it can be scanned much quicker < 1456991656 172508 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :then the friend stucked on the LZ77 window :p < 1456991705 403898 :andrew_!~andrew@113.97.177.247 QUIT :Remote host closed the connection < 1456991707 473776 :mroman!~mroman@160.85.232.90 PRIVMSG #esoteric :has anyone ever done some graph related database stuff? < 1456991709 68222 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :(it was a term project AFAIK, and the friend did get A even though the prototype was only marginally faster) < 1456991719 51446 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :Maybe I should write a toy image format and encoder and decoder, just to learn about how this stuff works, even if I don't get anything practically usable. < 1456991724 484407 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :(since everyone else was doing JPEG decoder stuff) < 1456991733 341544 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mroman: I looked into it a bit for aimake 4 < 1456991739 958244 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but didn't reach the point where it came to actually write the code < 1456991742 798929 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :(There are already lots of practical image coders out there.) < 1456991743 69944 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :so so far, all I have is plans < 1456991780 166773 :mroman!~mroman@160.85.232.90 PRIVMSG #esoteric :let's assume I have paths in my database A -> B -> D and A -> C -> D < 1456991786 508121 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : I think "non aliasing" for higher language tends to be a synonym for "pure/no side effects" and often "functional" or maybe even "lazy-evaluated functional" < 1456991812 713255 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: err, the Haskell-alikes have tons and tons of aliasing < 1456991812 846526 :mroman!~mroman@160.85.232.90 PRIVMSG #esoteric :and I want to know for example if there's a traffic jam on A -> D < 1456991818 36781 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :they're just constructed so that it never matters < 1456991828 355278 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :it doesn't HAVE to be this way but afaik all the "no side effects" languages are functionnal < 1456991830 940267 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :mad: to be more exact: DEFLATE stream stores the (encoded) tree in the front, and the tree is structured so that every prefix code is ordered by the length of code and then by the lexicographical order. since the end code is least frequent it should appear at the very end, i.e. all 1s. < 1456991846 609626 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : afaik haskell has no real aliasing? < 1456991863 288737 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :> let x = 4 in let y = x < 1456991864 860377 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric : :1:14: parse error in let binding: missing required 'in' < 1456991871 580669 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :> let x = 4 in let y = x in y < 1456991873 144678 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric : 4 < 1456991885 201229 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :actually GHC probably optimized the aliasing there out < 1456991893 908194 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :mad: the typical stream has 10--14 one bits for the end code, so the decompressor may try to speculatively decode the stream from that point < 1456991904 881185 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :but x and y would be aliases in a naive Haskell implementation < 1456991911 741224 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :there's just no way to tell from within Haskell itself < 1456991914 212106 :lifthrasiir!~lifthrasi@115.68.131.49 PRIVMSG #esoteric :(and the project was for CELL processor, quite amenable for this kind of things) < 1456991936 299471 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :because if two things alias, the normal way you tell is either to use a language primitive that tells you that, or to modify one and see if the other changes < 1456991957 113408 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :ais523 : yes but they're basically not real aliases because you can't write in one and get surprise changes in the other < 1456991960 754955 :mroman!~mroman@160.85.232.90 PRIVMSG #esoteric :the traffic jam could be between A -> B, B -> D, A -> C, C -> D or A -> D itself < 1456992000 297447 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :multiple readonly pointers to the same block of memory isn't a problem < 1456992000 449135 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mroman: huh, that's an interesting operation < 1456992012 907041 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mad: keep going and you'll invent Rust ;-) < 1456992024 474884 :mroman!~mroman@160.85.232.90 PRIVMSG #esoteric :other questions are: Are there paths from A to D that are not equally fast. < 1456992026 975725 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :the problem is when one of this pointers writes something < 1456992042 112317 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and it's impossible to say which other pointers will see the write < 1456992070 341154 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :at local level it's usually possible to figure it out (LLVM's alias solving does this) < 1456992078 736130 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :at global level it becomes impossible < 1456992083 363838 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :mroman: the SQLite docs have an example of doing transitive closure via a recursive query < 1456992107 116064 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :I'm not sure if the performance is better or worse than running Dijkstra's algorithm from outside with a series of queries < 1456992116 534816 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :that's one of x86's "voodoo" advantages < 1456992125 92087 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :ais523: I have to afk for some hour now, but I can tell my preliminary opinion on rust later. < 1456992128 231055 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :it doesn't require memory reordering to perform well < 1456992134 138838 :ais523!~ais523@unaffiliated/ais523 PRIVMSG #esoteric :(the constant factor should be better, but the asymptotic performance might be worse if it's using a bad algorithm) < 1456992172 253706 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :if it was possible to do more efficient memory reordering then x86 would be gone by now < 1456992221 973916 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :some RISC or VLIW would have been twice as fast as x86 and everybody would be switching < 1456992341 45238 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :as it is, the best cpu design practice, as far as I can tell, is to assume that loads/stores aren't going to move, and rearrange basically everything else around them < 1456992476 240872 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :result: out-of-order execution < 1456992604 249006 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :itanium tried to do compile time rearranging with some complex run-time checking+fallback mechanism < 1456992606 936703 :mad!boulam@69-165-212-148.cable.teksavvy.com PRIVMSG #esoteric :and it failed < 1456992957 392586 :Elronnd!elronnd@znc.dank.ninja QUIT :Quit: Let's jump! < 1456993281 729022 :Elronnd!elronnd@znc.dank.ninja JOIN :#esoteric < 1456994493 681540 :tromp!~tromp@ool-18be0bd8.dyn.optonline.net JOIN :#esoteric < 1456994778 633209 :tromp!~tromp@ool-18be0bd8.dyn.optonline.net QUIT :Ping timeout: 276 seconds < 1456995252 918994 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net QUIT :Ping timeout: 244 seconds < 1456995614 67917 :bender|!~benderx2@2404:e800:e61a:41d:ddbf:f4cc:366d:c672 JOIN :#esoteric < 1456995870 246077 :olsner!~salparot@c83-252-193-184.bredband.comhem.se QUIT :Ping timeout: 276 seconds < 1456996160 263508 :ais523!~ais523@unaffiliated/ais523 QUIT : < 1456996866 171673 :AnotherTest!~turingcom@2a02:2c40:400:0:ed2:92ff:fe3b:ec82 JOIN :#esoteric < 1456997157 172160 :AnotherTest!~turingcom@2a02:2c40:400:0:ed2:92ff:fe3b:ec82 QUIT :Ping timeout: 268 seconds < 1456997373 893661 :J_Arcane!~chatzilla@37-219-40-115.nat.bb.dnainternet.fi QUIT :Ping timeout: 240 seconds < 1456997448 780522 :olsner!~salparot@c83-252-193-184.bredband.comhem.se JOIN :#esoteric < 1456997794 3216 :olsner!~salparot@c83-252-193-184.bredband.comhem.se QUIT :Ping timeout: 240 seconds < 1456997917 679313 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :[wiki] 14[[07Talk:Brainfuck14]]4 10 02https://esolangs.org/w/index.php?diff=46491&oldid=46410 5* 03Rdebath 5* (+4885) 10Shortest known "hello world" program. -- Define "shortest"! < 1456998355 28245 :andrew_!~andrew@113.97.177.247 JOIN :#esoteric < 1456999165 880868 :andrew_!~andrew@113.97.177.247 QUIT :Remote host closed the connection < 1456999997 762276 :nisstyre_!~yourstrul@li611-52.members.linode.com NICK :nisstyre < 1457000007 720462 :nisstyre!~yourstrul@li611-52.members.linode.com QUIT :Changing host < 1457000007 853782 :nisstyre!~yourstrul@oftn/oswg-member/Nisstyre JOIN :#esoteric < 1457000186 421381 :AnotherTest!~turingcom@2a02:2c40:400::1:6e46 JOIN :#esoteric < 1457000351 22093 :int-e_!~noone@static.88-198-179-137.clients.your-server.de NICK :int-e < 1457000759 424674 :AnotherTest!~turingcom@2a02:2c40:400::1:6e46 QUIT :Ping timeout: 260 seconds < 1457001323 877113 :olsner!~salparot@c83-252-193-184.bredband.comhem.se JOIN :#esoteric < 1457001731 626558 :tromp!~tromp@ool-18be0bd8.dyn.optonline.net JOIN :#esoteric < 1457001942 206909 :jaboja!~jaboja@ejv17.neoplus.adsl.tpnet.pl JOIN :#esoteric < 1457001978 624807 :tromp!~tromp@ool-18be0bd8.dyn.optonline.net QUIT :Ping timeout: 244 seconds < 1457005047 971381 :boily!~alexandre@96.127.201.149 JOIN :#esoteric < 1457005345 549672 :jaboja!~jaboja@ejv17.neoplus.adsl.tpnet.pl QUIT :Ping timeout: 240 seconds < 1457007390 681015 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :FUNGOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOT! < 1457007401 98658 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :`? fungot < 1457007424 596911 :HackEgo!~HackEgo@162.248.166.242 PRIVMSG #esoteric :fungot is our beloved channel mascot and voice of reason. < 1457007536 682591 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :FireFly: MASCOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOT! < 1457007550 783348 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :oops, wrong autocompletion. < 1457007574 633481 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :fizzie: MASCOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOT! FUNGOOOOOOOOOOOOOOOOOOOOOOOOT! !?!???!?!?!!???!!!!!! < 1457007802 732233 :boily!~alexandre@96.127.201.149 QUIT :Quit: NONPLUSSING CHICKEN < 1457009479 555174 :jaboja!~jaboja@ejv17.neoplus.adsl.tpnet.pl JOIN :#esoteric < 1457009623 312023 :fungot!~fungot@momus.zem.fi JOIN :#esoteric < 1457009629 472284 :fizzie!fis@unaffiliated/fizzie PRIVMSG #esoteric :TOO LATE < 1457010169 364043 :Taneb!~Taneb@2001:41c8:51:10d:feff:ff:fe00:316b PRIVMSG #esoteric :fungot, how are you doing < 1457010169 562973 :fungot!~fungot@momus.zem.fi PRIVMSG #esoteric :Taneb: i'm sure it appeared on l:tu or winxp? ;p < 1457010569 974069 :oerjan!~oerjan@hagbart.nvg.ntnu.no JOIN :#esoteric < 1457012189 878753 :spiette!~spiette@x-132-204-251-254.xtpr.umontreal.ca JOIN :#esoteric < 1457012888 915464 :AnotherTest!~turingcom@94-224-66-163.access.telenet.be JOIN :#esoteric < 1457013361 582267 :jaboja!~jaboja@ejv17.neoplus.adsl.tpnet.pl QUIT :Ping timeout: 240 seconds < 1457015305 168208 :Alcest!~alcest@69.64.40.177 JOIN :#esoteric < 1457015440 904698 :zadock!~outsider@81.180.208.252 JOIN :#esoteric < 1457016134 503853 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :@tell mad can functional programming generate cycles? <-- in haskell it can, e.g. lst = 1 : lst defines a cyclic list, which is nevertheless immutable. (Technically you can in ocaml too, but only for simple constant initializers.) < 1457016134 674185 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :Consider it noted. < 1457016753 526030 :`^_^v!~nycs@gw.hq.meetup.com JOIN :#esoteric < 1457016984 954726 :lambda-11235!~lambda-11@47-208-113-50.erkacmtk03.res.dyn.suddenlink.net JOIN :#esoteric < 1457018689 383116 :UrbanM!~Master@cpe-77.38.31.175.cable.t-1.si JOIN :#esoteric < 1457018883 926649 :UrbanM!~Master@cpe-77.38.31.175.cable.t-1.si PRIVMSG #esoteric :hi please check out my website . http://sh.st/RptZh... ty :) i promise its not a virus < 1457018925 629726 :tromp!~tromp@ool-18be0bd8.dyn.optonline.net JOIN :#esoteric < 1457018956 245416 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :got a virus < 1457019045 766032 :UrbanM!~Master@cpe-77.38.31.175.cable.t-1.si PRIVMSG #esoteric :hi please check out my website . http://sh.st/RptZh... ty :) i promise its not a virus < 1457019133 91194 :ChanServ!ChanServ@services. MODE #esoteric +o :oerjan > 1457019133 103900 NAMES :#esoteric < 1457019154 351913 :oerjan!~oerjan@hagbart.nvg.ntnu.no MODE #esoteric +b :*!*Master@*.38.31.175.cable.t-1.si > 1457019154 359863 NAMES :#esoteric < 1457019154 485762 :oerjan!~oerjan@hagbart.nvg.ntnu.no KICK #esoteric UrbanM :You are not _our_ Urban M < 1457019183 619431 :tromp!~tromp@ool-18be0bd8.dyn.optonline.net QUIT :Ping timeout: 244 seconds < 1457019569 254002 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :oerjan: of course the immutability of Haskell is a lie. < 1457019594 962284 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :(I'm alluding to thunk updates.) < 1457019624 648940 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :who is urban m? < 1457019681 97538 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :brainfuck guy... yes < 1457019687 849946 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :https://esolangs.org/wiki/Urban_M%C3%BCller < 1457019719 988003 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :(ah, there was a question mark before the ellipsis. I typed that, then googled to confirm.) < 1457019775 469531 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :however... the user above looked more like and imposter < 1457019844 989888 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :sh.st... "shorten urls and learn money"... sounds legitimate < 1457020191 539048 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :so what do we get... googla analytics, tons of ads, some trackers, and did they actually put a captcha before the embedded link? < 1457020206 934990 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :(I'm looking at page source code) < 1457020266 434060 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :and there's a ton of javascript I haven't looked at. < 1457020377 963623 :XorSwap!XorSwap@wpa-6-1196.cc.umanitoba.ca JOIN :#esoteric < 1457020541 533832 :lambda-11235!~lambda-11@47-208-113-50.erkacmtk03.res.dyn.suddenlink.net QUIT :Quit: Bye < 1457020662 990831 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :int-e: thus i also mentioned ocaml hth < 1457020667 380084 :oerjan!~oerjan@hagbart.nvg.ntnu.no MODE #esoteric -o :oerjan > 1457020667 388786 NAMES :#esoteric < 1457020826 60245 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :btw does ghc allocate a thunk for a simple lst = 1 : lst; lst :: [Int] < 1457021191 72320 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :what is an l2 job? < 1457021201 127280 :bender|!~benderx2@2404:e800:e61a:41d:ddbf:f4cc:366d:c672 QUIT :Ping timeout: 250 seconds < 1457021211 144820 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :jobs outside of italy are so hard to grasp < 1457021296 921680 :augur!~augur@50-1-126-214.dsl.static.fusionbroadband.com JOIN :#esoteric < 1457021371 787510 :mroman!~mroman@160.85.232.90 QUIT :Quit: Lost terminal < 1457021526 729053 :oerjan!~oerjan@hagbart.nvg.ntnu.no QUIT :Quit: Later < 1457022264 295179 :augur!~augur@50-1-126-214.dsl.static.fusionbroadband.com QUIT :Remote host closed the connection < 1457022298 214809 :augur!~augur@50-1-126-214.dsl.static.fusionbroadband.com JOIN :#esoteric < 1457022578 992648 :augur!~augur@50-1-126-214.dsl.static.fusionbroadband.com QUIT :Ping timeout: 250 seconds < 1457023229 303529 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :@tell oerjan btw does ghc allocate a thunk for a simple lst = 1 : lst <-- wow, apparently not (checked assembly output from ghc-7.10.2 with -O2, native code gen) < 1457023229 437238 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :Consider it noted. < 1457023386 213747 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :@tell oerjan even ghc-7.6.3 didn't allocate a thunk, that's as far back as I can easily go < 1457023386 386290 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :Consider it noted. < 1457023847 519615 :zzo38!~zzo38@24-207-50-123.eastlink.ca JOIN :#esoteric < 1457024138 379160 :Treio!~Treio@87.244.233.250 JOIN :#esoteric < 1457024671 21670 :jaboja!~jaboja@ejv17.neoplus.adsl.tpnet.pl JOIN :#esoteric < 1457025335 211907 :Treio!~Treio@87.244.233.250 QUIT :Quit: Leaving < 1457025423 963701 :XorSwap!XorSwap@wpa-6-1196.cc.umanitoba.ca QUIT :Ping timeout: 240 seconds < 1457027051 136684 :XorSwap!XorSwap@wpa-6-1196.cc.umanitoba.ca JOIN :#esoteric < 1457027646 180636 :augur!~augur@108-60-123-170.static.wiline.com JOIN :#esoteric < 1457028404 589738 :augur!~augur@108-60-123-170.static.wiline.com QUIT :Remote host closed the connection < 1457028559 997648 :lambda-11235!~lambda-11@24.156.46.20 JOIN :#esoteric < 1457028841 656337 :MoALTz!~no@78-11-180-214.static.ip.netia.com.pl JOIN :#esoteric < 1457030024 419166 :izabera!~izabera@unaffiliated/izabera PRIVMSG #esoteric :https://github.com/bloomberg/bucklescript < 1457030299 947388 :lleu!~gnomebad@unaffiliated/lleu JOIN :#esoteric < 1457030378 52696 :augur!~augur@108-60-123-170.static.wiline.com JOIN :#esoteric < 1457030764 32278 :heroux!sandroco@gateway/shell/insomnia247/x-aqwhcyzbefsarqfv QUIT :Ping timeout: 264 seconds < 1457030807 15912 :XorSwap!XorSwap@wpa-6-1196.cc.umanitoba.ca QUIT :Ping timeout: 244 seconds < 1457030999 929339 :augur!~augur@108-60-123-170.static.wiline.com QUIT :Read error: Connection reset by peer < 1457032087 370451 :zadock!~outsider@81.180.208.252 QUIT :Quit: Leaving < 1457032261 350680 :lynn!~lynn@unaffiliated/lynn JOIN :#esoteric < 1457032452 392291 :heroux!~heroux@gateway/shell/insomnia247/x-rhhwzqcjhxkntnmu JOIN :#esoteric < 1457032870 526124 :XorSwap!~XorSwap@wpa-6-1196.cc.umanitoba.ca JOIN :#esoteric < 1457033482 426887 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org JOIN :#esoteric < 1457033611 68658 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :I am here < 1457034045 574109 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Did you work out those categories? < 1457034154 186031 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :shachaf: I'm actively working on that xD < 1457034234 272930 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :shachaf: I'm currently trying to figure out the type of the arrows in example (A) < 1457034252 504939 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :("Type" may not be the correct word, but it gets the point across if I send this message) < 1457034264 630454 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :The type of an arrow from A to B is A -> B < 1457034286 274785 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :shachaf: Yeah, I mean I'm trying to figure out what they represent < 1457034312 174341 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :shachaf: I think the only thing I've figured out is that in (A), composition represents the transitive property of ≤ < 1457034335 989019 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Yes. < 1457034340 742067 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What does identity represent? < 1457034359 61451 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :shachaf: The fact that a value is less than or equal to itself < 1457034364 124970 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :(specifically, x = x) < 1457034370 395877 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :aka reflexivity < 1457034372 833973 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :(there for x ≤ x) < 1457034377 74629 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :int-e: Yes, yes. < 1457034615 981805 :lambda-11235!~lambda-11@24.156.46.20 QUIT :Ping timeout: 264 seconds < 1457034677 307764 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :shachaf: Wait, do arrows just represent arbitrary relations? < 1457034682 757213 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :An arrow doesn't have to represent anything. < 1457034689 515596 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :shachaf: Oh. < 1457034698 850413 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :shachaf: So an arrow can just be an arrow? < 1457034706 496662 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :It doesn't have to represent a function? < 1457034711 252270 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :Or funtro < 1457034714 382106 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :*functor < 1457034721 383201 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :Or transformation of any sort < 1457034725 704345 :lambda-11235!~lambda-11@24-156-46-61.erkacmtk02.com.dyn.suddenlink.net JOIN :#esoteric < 1457034726 684066 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Sometimes an arrow is just a cigar. < 1457034746 275743 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :shachaf: Is arrow a type of cigar? < 1457034752 278526 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :hppavilion[1]: you can interpret any relation on a set as a directed graph with that set as nodes (allowing loops, not allowing multiple edges) < 1457034776 729100 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Arrows don't have to represent functions, no. < 1457034778 512164 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :I don't smoke, so if it is a type of cigar I wouldn't get the joke < 1457034781 867379 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :shachaf: Well yeah < 1457034782 588 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :Or transformations, whatever that is. < 1457034788 773863 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :shachaf: It was the best word I could think of < 1457034799 815816 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :but you really need reflexivity and transitivity to make a category that way < 1457034801 609385 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :shachaf: Do arrows have to mean something, or can they just be arrows? < 1457034815 347691 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :they can be just arrows < 1457034820 689460 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :OK < 1457034827 208869 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :int-e: And is that the case for category (A)? < 1457034860 598187 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :int-e: Where a -> b iff a <= b < 1457034869 297102 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :I don't know what example (A) refers to. < 1457034877 543102 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :int-e: That ^ < 1457034879 176728 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :ah. < 1457034897 760605 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :well, arguably the underlying relation gives the arrow *some* meaning < 1457034912 231265 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :it's really a philosophical question at this point. < 1457034915 160276 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :int-e: Ah < 1457034936 423583 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :int-e: But do they not represent anything in the way Set has arrows representing functions? < 1457034978 69085 :int-e!~noone@static.88-198-179-137.clients.your-server.de PRIVMSG #esoteric :right < 1457034998 33020 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :int-e: Or could it be argued that they represent Void? xd < 1457034999 471836 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :*xD < 1457035005 671321 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org PRIVMSG #esoteric :(That was a joke, I think) < 1457035261 780508 :Phantom_Hoover!~phantomho@unaffiliated/phantom-hoover JOIN :#esoteric < 1457036263 764700 :lambda-11235!~lambda-11@24-156-46-61.erkacmtk02.com.dyn.suddenlink.net QUIT :Quit: Bye < 1457036344 439623 :XorSwap!~XorSwap@wpa-6-1196.cc.umanitoba.ca QUIT :Ping timeout: 252 seconds < 1457037774 816274 :p34k!~p34k@nat-wh-wz4-12.rz.uni-karlsruhe.de JOIN :#esoteric < 1457037969 200366 :zzo38!~zzo38@24-207-50-123.eastlink.ca PRIVMSG #esoteric :To allow other program to change resources of a window in the X window system, you could have the other program appends a null-terminated string to a property on that window, and then that client watches that property and reads and deletes it and adds that string into the resource manager. You can also send commands that aren't resources too in the same way, by adding a prefix to specify < 1457038051 668479 :zzo38!~zzo38@24-207-50-123.eastlink.ca PRIVMSG #esoteric :Add RESOURCE_MANAGER into the WM_PROTOCOLS list to specify that this function is available, I suppose. < 1457038083 869410 :spiette!~spiette@x-132-204-251-254.xtpr.umontreal.ca QUIT :Ping timeout: 240 seconds < 1457038097 898472 :zzo38!~zzo38@24-207-50-123.eastlink.ca PRIVMSG #esoteric :Does it make sense to you? < 1457038337 61283 :zzo38!~zzo38@24-207-50-123.eastlink.ca PRIVMSG #esoteric :The format of the property must be 8, the type must be STRING, and the mode must be PropModeAppend. < 1457038981 906306 :spiette!~spiette@x-132-204-251-254.xtpr.umontreal.ca JOIN :#esoteric < 1457039116 245194 :`^_^v!~nycs@gw.hq.meetup.com QUIT :Quit: This computer has gone to sleep < 1457039832 220761 :augur!~augur@108-60-123-170.static.wiline.com JOIN :#esoteric < 1457040273 950517 :augur!~augur@108-60-123-170.static.wiline.com QUIT :Ping timeout: 240 seconds < 1457040616 3817 :ais523!~ais523@unaffiliated/ais523 JOIN :#esoteric < 1457040799 392893 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org QUIT :Ping timeout: 252 seconds < 1457040834 393297 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org JOIN :#esoteric < 1457040856 705489 :spiette!~spiette@x-132-204-251-254.xtpr.umontreal.ca QUIT :Quit: :qa! < 1457040900 205124 :spiette!~spiette@x-132-204-251-254.xtpr.umontreal.ca JOIN :#esoteric < 1457041162 453245 :hppavilion[1]!~DevourerO@74-114-87-72.dynamic.asdk12.org QUIT :Ping timeout: 252 seconds < 1457041651 809812 :J_Arcane!~chatzilla@37-219-40-115.nat.bb.dnainternet.fi JOIN :#esoteric < 1457042665 973563 :AnotherTest!~turingcom@94-224-66-163.access.telenet.be QUIT :Quit: ZNC - http://znc.in < 1457045007 834870 :spiette!~spiette@x-132-204-251-254.xtpr.umontreal.ca QUIT :Quit: :qa! < 1457045233 437470 :jaboja!~jaboja@ejv17.neoplus.adsl.tpnet.pl QUIT :Remote host closed the connection < 1457045391 238505 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :whoa < 1457045431 504412 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :I'm trying to line up the Szabó Lőrinc translation and the original of Tennyson: Ulysses exactly. But it turns out the translation is one line shoter. < 1457045450 65098 :b_jonas!~x@russell2.math.bme.hu PRIVMSG #esoteric :It's missing the line that would correspond to “Death closes all: but something ere the end,” < 1457046507 437225 :ais523!~ais523@unaffiliated/ais523 QUIT : < 1457047657 982087 :oerjan!~oerjan@hagbart.nvg.ntnu.no JOIN :#esoteric < 1457047666 510482 :shikhin!shikhin@unaffiliated/shikhin NICK :shikhun < 1457047697 779476 :shikhun!shikhin@unaffiliated/shikhin NICK :shikhin < 1457047700 961666 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :@messages- < 1457047701 94958 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :int-e said 6h 47m 51s ago: btw does ghc allocate a thunk for a simple lst = 1 : lst <-- wow, apparently not (checked assembly output from ghc-7.10.2 with -O2, native code gen) < 1457047701 95029 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :int-e said 6h 45m 14s ago: even ghc-7.6.3 didn't allocate a thunk, that's as far back as I can easily go < 1457048043 567588 :FreeFull!~freefull@defocus/sausage-lover QUIT :Quit: Rebooting < 1457048173 200197 :FreeFull!~freefull@defocus/sausage-lover JOIN :#esoteric < 1457048475 26064 :b_jonas!~x@russell2.math.bme.hu QUIT :Ping timeout: 250 seconds < 1457048537 222928 :b_jonas!~x@russell2.math.bme.hu JOIN :#esoteric < 1457048610 202462 :p34k!~p34k@nat-wh-wz4-12.rz.uni-karlsruhe.de QUIT : < 1457048617 188268 :hppavilion[1]!~DevourerO@58-0-174-206.gci.net JOIN :#esoteric < 1457048872 941558 :boily!~alexandre@96.127.201.149 JOIN :#esoteric < 1457048892 831925 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :fungot: fungellot. < 1457048893 157806 :fungot!~fungot@momus.zem.fi PRIVMSG #esoteric :boily: it is edited to remove the 0 parameter? i was thinking < 1457048900 899842 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :fungot: no you weren't. < 1457048901 185078 :fungot!~fungot@momus.zem.fi PRIVMSG #esoteric :boily: ( code is 2.1mb so that may not have < 1457048906 354139 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :fungot: yes I do. < 1457048906 701641 :fungot!~fungot@momus.zem.fi PRIVMSG #esoteric :boily: wait a minute!! i am having trouble with this stub generator. it has. < 1457048927 118956 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :fungot: stub generators suck, stubs suck, and asynchronous services especially suck. < 1457048927 502006 :fungot!~fungot@momus.zem.fi PRIVMSG #esoteric :boily: sperber was here mar 17 at 11:11 pm utc, saying: or check out file-select and tcp-listener-fileno < 1457048933 89534 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :"it has." seems a bit too stubby indeed. < 1457048965 839579 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :boheily. < 1457048999 734973 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :hellørjan. < 1457049022 375387 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :@@ @tell oerjan @@ @@ (@where weather) ENVA KOAK < 1457049022 508823 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :who's sperber? < 1457049054 720770 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :hellochaf. < 1457049057 826412 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :@messages- < 1457049058 877885 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :Plugin `compose' failed with: <> < 1457049059 11130 :lambdabot!~lambdabot@haskell/bot/lambdabot PRIVMSG #esoteric :You don't have any messages < 1457049073 321705 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :ho hum. < 1457049088 1309 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :boily: Good afternoon, person. < 1457049124 231948 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :boily: i dunno but he was there mar 17 hth < 1457049141 275536 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :silly oerjan < 1457049145 568512 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :mar 17 hasn't happened yet < 1457049163 673204 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :then why is fungot using past tense, duh < 1457049164 17854 :fungot!~fungot@momus.zem.fi PRIVMSG #esoteric :oerjan: with the procedure for-each? ie i have a question about static links. i really should read up on macros? like atom? < 1457049193 880845 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :time to a fungot is an irrelevant concept hth < 1457049194 246017 :fungot!~fungot@momus.zem.fi PRIVMSG #esoteric :boily: i don't apply this level of dynamic typing... it mentioned that static typing is in the browser while allowing quick access to the enclosing command. < 1457049206 4228 :oerjan!~oerjan@hagbart.nvg.ntnu.no PRIVMSG #esoteric :fungot: are you a dreen < 1457049206 404480 :fungot!~fungot@momus.zem.fi PRIVMSG #esoteric :oerjan: because bash gets exactly 3 parameters with that invocation, and 0 added to any number of arguments, you have < 1457049280 941779 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :fungot: hingot < 1457049281 304557 :fungot!~fungot@momus.zem.fi PRIVMSG #esoteric :shachaf: some may.....but not all. but many more possibilities than chess. many. most things just work. at least now atm < 1457049295 608058 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :^style calvinandhobbes < 1457049295 745510 :fungot!~fungot@momus.zem.fi PRIVMSG #esoteric :Not found. < 1457049298 972700 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :What! < 1457049310 920632 :shachaf!~shachaf@unaffiliated/shachaf PRIVMSG #esoteric :fizzie: plz fix twh hth < 1457049506 628064 :boily!~alexandre@96.127.201.149 PRIVMSG #esoteric :ACTION wraps fungot in a chicken costume < 1457049507 114500 :fungot!~fungot@momus.zem.fi PRIVMSG #esoteric :boily: and i think he said some weird things involving crazy symbols and actions. i'm purely interested in the same ballpark, and roughly between chicken and stalin might be one way of doing that < 1457049560 365070 :grabiel!~canaima@186-95-255-29.genericrev.cantv.net JOIN :#esoteric