< 1222301120 0 :olsner!unknown@unknown.invalid PRIVMSG #esoteric :you should build a TM using a casette tape for magnetic storage, then feed it with one of those "infinite" moebius strip tapes < 1222301184 0 :oc2k1!unknown@unknown.invalid PRIVMSG #esoteric :that would be more complex, because that tape is analog < 1222301197 0 :olsner!unknown@unknown.invalid PRIVMSG #esoteric :yeah, I guess < 1222301304 0 :oc2k1!unknown@unknown.invalid PRIVMSG #esoteric :counter + sram won't be bad, they could run up to 66 MHz (or heigher, because in BF the addres would be set with the previus command) < 1222301454 0 :oc2k1!unknown@unknown.invalid PRIVMSG #esoteric :Braintwist would be a possibility: Load the program from IO and swap tapes. Maybe with a hack that uses a rom for init < 1222301495 0 :comex!unknown@unknown.invalid QUIT :"Caught sigterm, terminating..." < 1222301612 0 :oc2k1!unknown@unknown.invalid PRIVMSG #esoteric :and ethernet as IO :D < 1222301771 0 :olsner!unknown@unknown.invalid QUIT :"Leaving" < 1222302126 0 :jix!unknown@unknown.invalid QUIT :"CommandQ" < 1222302453 0 :tusho!n=tusho@91.105.117.163 JOIN :#esoteric < 1222303339 0 :pikhq!unknown@unknown.invalid PRIVMSG #esoteric :oc2k1: Welcome to the land of Esolangs. < 1222303350 0 :oc2k1!unknown@unknown.invalid PRIVMSG #esoteric ::d < 1222303969 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :hm? < 1222304569 0 :tusho!unknown@unknown.invalid QUIT : < 1222304702 0 :Sgeo!n=Sgeo@ool-18bf68ca.dyn.optonline.net JOIN :#esoteric < 1222305167 0 :oerjan!unknown@unknown.invalid QUIT :"leaving" < 1222379458 0 :clog!unknown@unknown.invalid JOIN :#esoteric < 1222379458 0 :clog!n=nef@bespin.org JOIN :#esoteric < 1222379520 0 :jix!n=jix@dyndsl-091-096-037-066.ewe-ip-backbone.de JOIN :#esoteric < 1222379642 0 :oklopol!unknown@unknown.invalid QUIT :Read error: 60 (Operation timed out) < 1222379966 0 :caio!unknown@unknown.invalid QUIT :Remote closed the connection < 1222380111 0 :oklofok!n=nnscript@oklopol.yok.utu.fi JOIN :#esoteric < 1222380171 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :the trick is we're basically doing that garbage collection technique where you mark things you can see; it's just here we do it every time something is deleted < 1222380343 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :basically, every object has this nice little number attached to it, and there's another, global number, which gets incremented every time a reference is deleted; when a reference is deleted, the things it references are checked to see if their number is the global number == they've been disref'd this cycle, if it's not the same, have their number inc'd, and refs dec'd, and the reference deletion propagates to whatever they reference, if the refcoun < 1222380372 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :s/have their number inc'd/set their number to the global number/ < 1222380399 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :ais523: interpretation of oklofok's idea pls < 1222380403 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :i think this is as fast as refcounting, but errorlessss < 1222380454 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :oklofok: plz provide impl < 1222380456 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :how to appear smart: take a simple idea, and explain it confusingly using all kinds of terms invented on the fly < 1222380459 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :oklofok: what if you have a and b both referencing x, x and y referencing each other? < 1222380462 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :but yeah i'll try < 1222380471 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :ais523: dunno, i'll think < 1222380484 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :and then, say, a is deleted? < 1222380498 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :what if, instead, x is deleted? < 1222380532 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :a.ref = x, b.ref=x, y.ref=x, x.ref=y (now we have x.torefs=2) delete a => x.torefs=1, and execution stops < 1222380555 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :a.ref = x, b.ref=x, y.ref=x, x.ref=y (now we have x.torefs=2) delete x => y.torefs=0 => x and y are deleted < 1222380569 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :of course, you cannot delete x < 1222380590 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :hmmhmm < 1222380613 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :you can only delete local variables, basically, or rather, they are the only things that actually ever are explicitly deleted, although automatically < 1222380622 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :err < 1222380645 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :well actually what do i care, x shouldn't be deleted, ever, because x.torefs != 0 < 1222380668 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :ais523: satisfied, disagreeing or confused? < 1222380675 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :ah, I see, even if x goes out of scope a and b might still need it < 1222380685 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :whereas a can go out of scope fine < 1222380691 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :but why is x.torefs 2 not 3 < 1222380693 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :yes, because nothing needs it < 1222380695 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :err < 1222380702 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :actually i guess it's 3... < 1222380721 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :this is exactly the problem i thought i solved, so i must have some idea < 1222380727 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :so wait a mo :) < 1222380763 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :right, the problem is we should also be propagating when the refcount does *not* become zero < 1222380772 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :that's the whole difference between just refcounting and this < 1222380816 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :so everytime something is removed, we will effectively exhaust everything reachable from it, deccing the refcounts of the whole closure of references < 1222380850 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :we can probably optimize this quite a lot by having data structures share locally global refcounts or something < 1222380855 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :whatever that means :D < 1222380863 0 :comex!n=comex@teklinks.org JOIN :#esoteric < 1222380873 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :oklofok: "locally global" is a great term < 1222380878 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :yes! < 1222380891 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :also, it reminds me a bit of the way choicepoint stacks work in C-INTERCAL < 1222380898 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :the bottom of the stack is shared but the top isn't < 1222380922 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :ais523: so does it work? < 1222380930 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :and is it just about as efficient as refcounting? < 1222380938 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :if it had all the benefits of gc without actually...gcing, that would rock so hard < 1222380950 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :tusho: I'm not convinced it works yet < 1222380950 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :and oklofok could probably publish a paper on it :P < 1222380953 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :and I don't think it's faster < 1222380958 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :because you're doing the same amount of work < 1222380960 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :ais523: hm, so you still have to traverse shit < 1222380962 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :just at a different time < 1222380962 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric ::( < 1222380977 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :the traversing happens at allocate/finalise, rather than at random intervals < 1222380980 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :actually, that might be faster < 1222380982 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :so, basically, for the strongly connected components reference graph, we have a shared refcount, methinks < 1222380990 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :*components of the reference < 1222381020 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :oklofok: is it better than gc for actual use would you say>? < 1222381025 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :or mainly interesting but not useful < 1222381030 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :probably the latter < 1222381035 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :aw < 1222381044 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :though if it works, that is neat < 1222381053 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :and also reaffirms my theory that generally you should believe oklofok < 1222381060 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :even if you don't understand wtf he's talking about < 1222381061 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :oklofok's idea strikes me as the sort of thing that seems likely to have a way of working < 1222381076 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :although it also strikes me as the sort of thing that doesn't have all the details worked out yet < 1222381081 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :but it seems plausible as a general idea < 1222381087 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :ais523: that's all of oklofok's stuff. < 1222381096 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :wow, oklofok invented Feather < 1222381105 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :heh < 1222381108 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :(yes, yes, false syllogism I know) < 1222381120 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :details generally come when i open python... :P < 1222381223 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :oklofok: do so! < 1222381276 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :anyway, i think if something like that was well implemented, it would have cases where refcounting would work as fast as explicit memory deallocation, but that sometimes you would have it propagate deletion information around the variable graph all the time, and things would get n^2 < 1222381298 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :and i cannot open python today, i need to read < 1222381299 0 :kar8nga!unknown@unknown.invalid PART #esoteric :? < 1222381344 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :so, when someone leaves the room, do you whois him to see whether he disliked the subject, or just has a habit of leaving channels before disconnecting? < 1222381345 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :oklofok: yes, it obviously has different order properties to standard collection < 1222381352 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :AFAICT it has a better best case and a much worse worst case < 1222381371 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :oklofok: no, I don't < 1222381372 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :'has a habit of leaving channels before disconnecting' < 1222381372 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :lol wut < 1222381385 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :tusho: it makes sense for people who like to be clean and tidy < 1222381393 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :but... < 1222381395 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :for instance I tend to empty the stack in Underload programs before they exit < 1222381396 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :tusho: it's not that rare. < 1222381398 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :your client already does that... < 1222381402 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :and close programs before shutting down the computer < 1222381410 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :and free() stuff in C just before the program ends < 1222381419 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :tusho: yes, that's probably the only reason for doing it; this doesn't really change anything < 1222381422 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :none of that is needed, in theory (in the third case not on a decent OS, at least) < 1222381429 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :ais523: i do none of those < 1222381431 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :esp. not closing programs < 1222381434 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :i have too many open < 1222381435 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :also < 1222381445 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :i advocate a data-based approach to computing < 1222381449 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :not document or program based < 1222381454 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :so it kind of comes naturally to me < 1222381471 0 :jix!unknown@unknown.invalid QUIT :Nick collision from services. < 1222381485 0 :jix!n=jix@dyndsl-085-016-233-040.ewe-ip-backbone.de JOIN :#esoteric < 1222381485 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :well, I like starting from a clean slate when I boot, and closing things down so I can deal with things that happen during the close down < 1222381499 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :although there usually aren't any < 1222381502 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :ah, you use a stupid os that reopens programs on startup. < 1222381504 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :my condolences < 1222381505 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :also it gives me a sort of wind-down < 1222381507 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :tusho: no, I don't < 1222381512 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :it can be set to do that < 1222381515 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :but I haven't set that setting < 1222381526 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :i just suspend this computer :q < 1222381548 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :(btw, I don't exit notification area applications like Akregator or Rhythmbox, even though I do start them by hand, some strange psychology is at work there...) < 1222381556 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :aaaanyway, this is kinda like connected components, you can do it for the whole graph in O(n) (the GC approach), or find the connected component of every node separately in O(n^2) (the refcounting thing); it's just the latter will actually be closer to O(n) if there are only a few references that cannot be "optimized", and you more easily can do it online < 1222381575 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :*can more easily < 1222381582 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :oklofok: well, most programs don't have circular references < 1222381584 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :or at least, not too many < 1222381595 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :which is more efficient if you only have a few circular references? < 1222381596 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :in that case it will be equal to refcounting. < 1222381602 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :as opposed to Circular Reference Exampleprogram Deluxe < 1222381606 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :oklofok: what, won't it handle them properly? < 1222381631 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :hmm < 1222381643 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :it will handle everything properly, that's not the issue < 1222381645 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :oklofok: actually I think refcounting will be slower as long as you don't have deep chains of objects < 1222381653 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :a linked list would really kill a system like yours < 1222381660 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :oh < 1222381660 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :hmm... refcounting doesn't like linked lists either, though < 1222381663 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :ais523: not necessarily < 1222381689 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :if done naively, then yes < 1222381708 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :you're planning to optimise this already? < 1222381716 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric ::D < 1222381733 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :well i was thinking massive amounts of information about the subgraphs between variables < 1222381742 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :so you can't execute anything < 1222381752 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :because you'll just end up changing those graphs for ages < 1222381790 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :but i don't think i'm going to optimize anything at first < 1222381812 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :but, i think for recursive data structured, you can use a local global refcount < 1222381872 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :i'm sure i'll have something concrete tomorrow, if i have the time < 1222381926 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :i think, at least, this refcounting thing might be a useful abstraction for deducing deletion patterns for data structures < 1222381931 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :which would be kinda nice already < 1222381945 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :ooh, that'd be nice < 1222382061 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :for a recursive definition like L = | L, we see the child always has exactly one reference more than its parent, inside this one data structure, so we have the normal refcount for the nodes, and then just the info how deep they are in the structure, and what the refcount of the ultimate parent is < 1222382082 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :this shouldn't be list-specific, i'm sure it would work for any tree structure < 1222382098 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :of course, there would be more propagation... :P < 1222382116 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :
ACTION bangs head to wall
< 1222382140 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :hmm... actually < 1222382157 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :we don't need to know what the exact refcount is for a node < 1222382171 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :we just need to know whether it has any refcounts from higher up in the data structure < 1222382183 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :so, we basically have an "ultimate parent" flag < 1222382196 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :which only propagates one level down when a parent is deleted < 1222382213 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :this way i think recursive structures can be optimized entirely < 1222382220 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :except there's a problem ais523 will point out to me < 1222382243 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :does it work on the sort of recursive structure that C-INTERCAL uses to hold threads? < 1222382247 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :that's pretty weird, and complex < 1222382258 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :an object can be part of any number of data structures, so it will have a list of these ultimate parent flags, and the refcount for other references < 1222382272 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :i have no idea, what kind are those? < 1222382295 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :i'm thinking more like something that can be proved to work in all cases < 1222382306 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :so, i'd say it would work on those < 1222382313 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :and if not, then i should get back to work < 1222382858 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :the language for testing, i guess just type definitions, Tree = Node a | Branch (.left Tree) (.right Tree), so you can explicitly give things a type, and then setting variables to things, and setting the references of variables, like {x.ref1 = y}, and {Tree x; x.left = y}, after which x.ref1 wouldn't work anymore, because x would be limited to being a tree < 1222382917 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :quite a useless language, but i don't think control would complicate the issue at all, at least without concurrency < 1222382925 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :do you think it would? < 1222382931 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :a < 1222382963 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :oklofok: well, the C-INTERCAL thread structure is at its base a singly linked ring < 1222382988 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :each member of the ring links to a singly linked list of other objects of the same type which aren't part of the ring (possibly empty) < 1222383010 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :and the tails of those lists can be shared (i.e. after a while the lists point to the same members) < 1222383025 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :fascinating < 1222383029 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :also each object has another pointer which can either point to an arbitrary object or to itself < 1222383037 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :pointing to itself is usual < 1222383057 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :finally, there's a sort of object that's just a placeholder and can only exist in the singly linked lists < 1222383070 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :and doesn't have any pointers except the ones that hold the list together < 1222383072 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :I think that's about it < 1222383085 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :i see, i see < 1222383096 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :(you may boggle at the structure of INTERCAL that it requires such a complicated data structure to represent its threading model, if you wish) < 1222383097 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :and how is this structure used exactly? < 1222383107 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :well, the ring contains active threads < 1222383111 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :which take turns executing < 1222383117 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :the single lists are choicepoint stacks < 1222383119 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :for each thread in the list < 1222383133 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :they're made out of dormant threads which aren't executing right now, but could be later < 1222383138 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :and stale threads which are just placeholders < 1222383149 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :also, any two threads can either share variables or not share variables < 1222383161 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :and so there's a pointer to the thread in which a thread's variables are actually stored < 1222383174 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :which is normally a pointer back to self, but not necessarily if there's sharing going on < 1222383214 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :when a thread becomes dormant, it takes the next thread, and attaches itself to that thread's linked list? < 1222383227 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :or what's the point of these lists < 1222383257 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :a user can create a dormant thread that's a copy of the current one < 1222383261 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :and push it onto the choicepoint stack < 1222383266 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :i see < 1222383274 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :a user can also replace the current thread with the top dormant one on its choicepoint stack < 1222383287 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :except that if the tail of that stack is shared with another, the thread is deleted instead < 1222383305 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :(N.B. this requires reference-counting to work correctly) < 1222383316 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :n.b.? < 1222383324 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :this makes it possible to backtrack past a fork()-equivalent < 1222383324 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :news bulletin? < 1222383327 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :oklofok: nota bene < 1222383330 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :it's latin for "note well" < 1222383353 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :but normally in English it's basically like a P.S. it's something that you just mention even though it isn't part of your main point < 1222383357 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :i see, no wonder i couldn't reverse-engineer that < 1222383386 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :oklofok: if you had done you'd probably have deduced INTERCAL's entire threading model from scratch < 1222383395 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :and it's taken years to get it properly confused < 1222383413 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :reverse-engineer n.b. i meant :P < 1222383418 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :ah < 1222383449 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :yes, an idiomatic English abbreviation that's actually an abbreviation for some Latin words which mean something else tends to be quite hard to guess < 1222383470 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :probably it best translates to "by the way", if you know that idiom < 1222383483 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :i know that idiom < 1222383503 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :it's actually somewhat used in finnish < 1222383601 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :i'm gonna read a bit, and then sleep now, i'll look at that reference language tomorrow < 1222383602 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :-> < 1222383610 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :"then sleep now"? < 1222383611 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :night < 1222383616 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :aaaanywa -> < 1222383620 0 :oklofok!unknown@unknown.invalid PRIVMSG #esoteric :*aaaanyway < 1222383630 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :read, then sleep retroactively through the time you were reading < 1222383637 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :multitasking via temporal paradox < 1222384343 0 :oc2k1!unknown@unknown.invalid QUIT :Remote closed the connection < 1222384924 0 :ihope!n=Peggy@c-71-205-100-59.hsd1.mi.comcast.net JOIN :#esoteric < 1222385410 0 :oklofok!unknown@unknown.invalid QUIT :Read error: 113 (No route to host) < 1222385773 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :hooray < 1222385778 0 :tusho!unknown@unknown.invalid PRIVMSG #esoteric :finally got yahoo to cancel that domain < 1222385787 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :actually, I'd better go home now < 1222385793 0 :ais523!unknown@unknown.invalid PRIVMSG #esoteric :almost missed my bus... < 1222385795 0 :ais523!unknown@unknown.invalid QUIT :"9" < 1222386666 0 :olsner!unknown@unknown.invalid QUIT :"Leaving" < 1222387166 0 :Sgeo!n=Sgeo@ool-18bf68ca.dyn.optonline.net JOIN :#esoteric