|
3304
|
1 2006-05-24.txt:17:36:15: <SimonRC> no, I mean there would be a bit to say wether a word was an actual value or a thunk telling you how to calculate it.
|
|
|
2 2006-08-23.txt:00:05:09: <ihope> Uh... thunks. The eager kind.
|
|
|
3 2006-08-26.txt:21:18:48: <ihope> oerjanj: thunks.
|
|
|
4 2006-08-26.txt:21:19:13: <oerjanj> but the thunk would be evaluated every time
|
|
|
5 2006-08-26.txt:21:20:16: <ihope> oerjanj: thunks. Like output functions are thunks.
|
|
|
6 2006-08-26.txt:21:20:37: <ihope> .H is a thunk. r is a thunk. Continuations are thunks, I think.
|
|
|
7 2006-08-26.txt:21:22:24: <oerjanj> i have no problem understanding thunks. but for call-on-need you need to replace a thunk by its result.
|
|
|
8 2006-08-26.txt:21:23:16: <ihope> oerjanj: I don't get what you're saying. Thunks wouldn't be evaluated until you call them.
|
|
|
9 2007-01-07.txt:21:46:24: <ihope_> Thunk, then?
|
|
|
10 2007-01-07.txt:21:54:05: <ihope_> ~pexec self.apply_thunk = lambda *x: lambda: x[0](x[1:])
|
|
|
11 2007-01-07.txt:21:55:58: <ihope_> ~pexec self.esoteric(self.apply_thunk(lambda x,y: x+y, 3, 5))
|
|
|
12 2007-01-07.txt:21:57:12: <bsmntbombdood> ~exec print self.apply_thunk(lambda x,y: x+y, 3, 5)
|
|
|
13 2007-01-07.txt:21:57:59: <bsmntbombdood> apply_thunk is returning a function
|
|
|
14 2007-01-07.txt:21:58:13: <bsmntbombdood> ~pexec print self.apply_thunk(lambda x,y: x+y, 3, 5)()
|
|
|
15 2007-01-07.txt:21:58:17: <bsmntbombdood> ~pexec print self.apply_thunk(lambda x,y: x+y, 3, 5)(1,2)
|
|
|
16 2007-01-07.txt:21:58:25: <bsmntbombdood> ~pexec print self.apply_thunk(lambda x,y: x+y, 3, 5)()
|
|
|
17 2007-01-07.txt:21:59:12: <CakeProphet> called the function returned by apply_thunk... I'd imagine.
|
|
|
18 2007-01-07.txt:22:00:31: <bsmntbombdood> ~pexec self.apply_thunk = lambda *x: lambda: x[0](*x[1:])
|
|
|
19 2007-01-07.txt:22:00:42: <bsmntbombdood> ~pexec print self.apply_thunk(lambda x,y: x+y, 3, 5)
|
|
|
20 2007-01-07.txt:22:00:55: <ihope_> ~pexec self.esoteric(self.apply_thunk(lambda x,y: x+y, 3, 5))
|
|
|
21 2007-01-07.txt:22:01:11: <bsmntbombdood> ~pexec print self.apply_thunk(lambda x,y: x+y, 3, 5)()
|
|
|
22 2007-01-07.txt:22:02:32: <ihope_> apply_thunk creates a thunk, and esoteric forces it.
|
|
|
23 2007-01-07.txt:22:02:39: <bsmntbombdood> what's a thunk?
|
|
|
24 2007-01-07.txt:22:03:44: <ihope_> Now to combine esoteric with apply_thunk, because there's really no reason to have both.
|
|
|
25 2007-01-07.txt:22:04:47: <CakeProphet> a thunk is a lambda then.
|
|
|
26 2007-01-07.txt:22:05:01: <ihope_> And there's really no reason to keep the thunk stuff.
|
|
|
27 2007-01-07.txt:22:05:36: * CakeProphet considered a thunk-like thing for a language.
|
|
|
28 2007-01-30.txt:01:36:16: <ihope_> Thunk monad, anyone?
|
|
|
29 2007-02-02.txt:03:24:31: <SevenInchBread> for evaluating a symbol, the thunk for the get hash value function cab be the symbol itself
|
|
|
30 2007-02-02.txt:03:24:54: <bsmntbombdood> thunk?
|
|
|
31 2007-02-08.txt:01:40:29: * ihope_ ponders thunks
|
|
|
32 2007-02-25.txt:21:32:27: <bsmntbombdood> thunks are ugly :/
|
|
|
33 2007-03-22.txt:01:31:55: <oerjan> representing files as lazy thunks allows infinite files without loops.
|
|
|
34 2007-06-21.txt:05:05:56: <oerjan> In the monad of (IO) actions, the values would be thunks that did possibly some I/O and then returned an a.
|
|
|
35 2007-06-21.txt:05:06:30: <oerjan> thunk = closure without arguments
|
|
|
36 2007-06-26.txt:20:59:53: <SimonRC> Oh, wait, you can do it with thunks.
|
|
|
37 2007-07-03.txt:13:56:59: <ihope_> Thunks!
|
|
|
38 2007-07-03.txt:14:32:51: * ihope_ ponders thunks
|
|
|
39 2007-07-03.txt:14:33:45: <ihope_> In the Haskell definition "x = x + 1", calling the x thunk calls the + thunk with x and 1, right?
|
|
|
40 2007-07-03.txt:14:35:03: <ihope_> Calling the x thunk... returns something representing (x +), I guess.
|
|
|
41 2007-07-03.txt:14:38:26: <ihope_> I was pondering thunks for functions.
|
|
|
42 2007-07-03.txt:14:40:01: <oerjan> well, an evaluated function thunk can be thought of as a lambda expression in head normal form
|
|
|
43 2007-07-03.txt:14:40:44: <ihope__> Really, their thunks don't need to do anything at all--they can just return.
|
|
|
44 2007-07-03.txt:14:43:12: <oerjan> so just because a thunk is of a function type doesn't mean it does no evaluation
|
|
|
45 2007-09-22.txt:01:33:36: <edwardk> currently i'm using an 'optimistic with lazy semantics' rule which says it can waste work on things eagerly but it has to bound the amount of speculation and if it encounters an error while speculating it has to pretend it didn't happen and turn that speculation into a lazy thunk to be forced on demand.
|
|
|
46 2007-09-22.txt:01:34:11: <edwardk> so that you can encounter bottoms and not 'bottom' out, but you don't have to build as many thunks
|
|
|
47 2007-09-22.txt:01:34:47: <oklokok> "build thunks"?
|
|
|
48 2007-09-22.txt:01:35:31: <edwardk> a thunk is the unevaluated computation that when forced will give you the answer and overwrite it self with the answer, so that call-by-name evaluation works
|
|
|
49 2007-09-22.txt:01:36:26: <edwardk> call-by-name has thunks, call-by-need makes the thunk remember the answer it gave by self-modifying
|
|
|
50 2007-09-22.txt:01:36:34: <edwardk> so called 'memothunks' =)
|
|
|
51 2007-09-22.txt:01:37:21: <edwardk> pattern matching just checks to see if what you have is a thunk if so it tells the thunk to evaluate which makes sure the outermost constructor is a value, then you can inspect it
|
|
|
52 2007-09-22.txt:01:37:51: <edwardk> in the ghc haskell compiler it does so by making everything into a 'thunk' with a function for the constructed values that just returns itself
|
|
|
53 2007-09-22.txt:01:39:46: <edwardk> so basically a list 'cons' cell is a [Cons, x, xs] where cons is a pointer to a function that happens to just return the 'thunk' [Cons, x, xs] that it was given, so to force it you call the function at the start of the thunk and you inspect the value of the tag that it returns in the first position.
|
|
|
54 2007-09-22.txt:01:40:20: <edwardk> then you'd encounter a thunk like
|
|
|
55 2007-09-22.txt:01:44:01: <oklokok> i mean, it doesn' have to know the object it's matching is actually a thunk
|
|
|
56 2007-09-22.txt:01:46:14: <edwardk> adding speculation muddies the waters a bit, you track a speculation depth cap, and rather than generate a thunk in the first place you try to run through it eagerly, but if you hit the cap you abort and return the thunk.
|
|
|
57 2008-01-10.txt:23:48:21: <ehird`> CakeProphet_: the term is 'thunk'
|
|
|
58 2008-01-15.txt:00:13:10: <ehird`> 0-args can be replaced with thunks, va-arg is more problematic
|
|
|
59 2008-01-21.txt:16:09:54: <ehird> every argument to EVERYTHING is a thunk
|
|
|
60 2008-01-21.txt:16:10:19: <ehird> CALLIFY(thunky_thunk);
|
|
|
61 2008-01-21.txt:16:10:21: <ehird> thunky_thunk:
|
|
|
62 2008-01-21.txt:16:10:37: <ehird> so, d works just by wrapping that thunk in a structure
|
|
|
63 2008-01-23.txt:18:10:32: <olsner> the name 'blimp' reminds me of haskell's thunks
|
|
|
64 2008-02-18.txt:20:14:08: <ehird`> think it's worth making that use a thunk?
|
|
|
65 2008-02-18.txt:20:19:32: <ehird`> ais523: http://pastebin.ca/908906 weird bug with thunks
|
|
|
66 2008-02-18.txt:20:19:45: <ehird`> Thunk.new {@block.call.__send__(*args, &blk)}
|
|
|
67 2008-02-18.txt:20:19:49: <ehird`> thus making it return a Thunk
|
|
|
68 2008-02-18.txt:20:47:16: <ehird`> blk[head, (magic thunkify: tail.inject(base, &blk))]; end
|
|
|
69 2008-02-18.txt:20:47:23: <ehird`> but the magic thunkify is basically impossible
|
|
|
70 2008-03-09.txt:17:39:58: <olsner> laziness got the best of you, eh? someone needs to have his thunks forced...
|
|
|
71 2008-03-09.txt:21:25:41: <ehird> oerjan: some things cannot be unthunked
|
|
|
72 2008-03-09.txt:21:26:22: <oerjan> ITYM "unthunk"
|
|
|
73 2008-03-09.txt:21:27:27: <oerjan> i am merely correcting your grammar. think, thank, thunk.
|
|
|
74 2008-03-31.txt:16:10:25: <ehird> closures and thunks and all that mean it's pretty hack
|
|
|
75 2008-05-06.txt:18:04:29: <ehird> ais523: they could be thunks
|
|
|
76 2008-06-06.txt:01:06:21: <augur> anyone know what a thunk is?
|
|
|
77 2008-06-06.txt:01:11:01: <oklofok> cool thunk
|
|
|
78 2008-06-08.txt:20:13:29: <augur> i thunk, therefore noone ever disputes me.
|
|
|
79 2008-06-18.txt:22:56:20: <augur> sure, you could write a thunk lambda and call it with conditional reactions, but that tells you nothing more than anything else does
|
|
|
80 2008-06-19.txt:19:04:12: <tusho> Cool. Thunks were invented in 1961 for ALGOL 60.
|
|
|
81 2008-06-19.txt:19:11:13: <Slereah_> Thunks?*
|
|
|
82 2008-06-19.txt:19:11:20: <tusho> Thunks
|
|
|
83 2008-06-19.txt:19:12:47: <Slereah_> "The word thunk has at least three related meanings in computer science."
|
|
|
84 2008-07-08.txt:20:00:58: <AnMaster> pikhq, you can thunk yes
|
|
|
85 2008-08-24.txt:23:15:20: <lament> AnMaster: http://algebraicthunk.net/~dburrows/blog/entry/package-management-sudoku/
|
|
|
86 2008-08-30.txt:20:02:01: <fungot> AnMaster: any actionscript object could be wrapped in a dynamic-wind exit thunk?
|
|
|
87 2008-09-03.txt:13:32:52: <tusho> Deewiant: quick, explain to him the asm that powers thunks
|
|
|
88 2008-09-03.txt:13:33:17: <tusho> Deewiant: evidently, thunks don't exist
|
|
|
89 2008-09-29.txt:15:53:08: <tusho> it uses thunks
|
|
|
90 2008-10-11.txt:05:23:48: <edwardk> the problem is basically i wound up building up these free magmas of structures 1 + (2 + 3) didn't build a thunk chain it built a data structure.
|
|
|
91 2008-10-11.txt:05:29:32: <edwardk> so instead i store the fwding pointer xored with the view instead. then to see if a view has already been applied to a thunk i check to see if fwd ^ fwd ^ the-view-i-read = the-view-i-want if so then fwd points to the answer, if not either the wrong view was stored or someone is racing me and its inconsistent
|
|
|
92 2008-10-22.txt:18:17:40: <optbot> asiekierka: every argument to EVERYTHING is a thunk
|
|
|
93 2008-11-19.txt:12:28:55: <ehird> 1. make it lazy and have no 0-arg functions, they're just thunks, like haskell. <-- Best option, obviously
|
|
|
94 2008-12-20.txt:09:13:41: <oerjan> i wioll haven thunk so, but not yet
|
|
|
95 2008-12-26.txt:19:41:02: <oklopol> the perfect is changing to thunk, but thank i haven't heard yet
|
|
|
96 2009-01-14.txt:17:53:29: <ehird> can't you just track d tags and pass thunks to d-tainted functions?
|
|
|
97 2009-01-16.txt:23:22:27: <ehird> who'dathunkit?
|
|
|
98 2009-01-18.txt:14:22:40: <ehird> i.e., if we call/cc out of the thunk thing, we call the after thing first
|
|
|
99 2009-01-18.txt:14:24:09: <oklopol> oh i remember. weird ordering shit and thunk stuff.
|
|
|
100 2009-02-04.txt:18:24:38: <ehird> i.e., no thunks (0-argument functions, used for laziness)
|
|
|
101 2009-02-04.txt:18:35:06: <ehird> think think closure thunk _ghczmprim_GHCziTypes_Czh_static_info
|
|
|
102 2009-02-04.txt:18:35:13: <ehird> *thunk thunk
|
|
|
103 2009-02-16.txt:17:46:02: <ehird> *thunk
|
|
|
104 2009-02-16.txt:17:46:51: <ski__> no, code is not thunks
|
|
|
105 2009-02-16.txt:17:47:12: <ski__> `eval' in lisps doesn't operate on thunks
|
|
|
106 2009-03-27.txt:00:50:06: <ehird> pass the thunk
|
|
|
107 2009-03-27.txt:00:59:08: <oerjan> (1) when you evaluate `dd you get not d, but a (d <d>) thunk like you mentioned
|
|
|
108 2009-04-21.txt:20:06:17: <ehird> http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/ ← now how do I do this with ext3...
|
|
|
109 2009-04-21.txt:20:19:09: <ehird> AnMaster: the intel X25-M (best one): http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/
|
|
|
110 2009-04-21.txt:20:22:43: <ehird> AnMaster: any idea about http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/; it tells you how to do an alignment thing with ext4, can ext3 do that?
|
|
|
111 2009-04-21.txt:20:31:43: <ehird> AnMaster: 'cuz of how ssds' blocks work, see http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/
|
|
|
112 2009-04-21.txt:20:35:16: <ehird> AnMaster: see http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/
|
|
|
113 2009-04-21.txt:22:20:14: <ehird> just trying to figure out how to do http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/ without LVM or ext4
|
|
|
114 2009-04-28.txt:19:42:02: <AnMaster> ehird, "<MyCatVerbs> ehird: I would guess that they're fairly lazy, so you end up with enormous thunks." wth did that mean
|
|
|
115 2009-04-28.txt:19:42:13: <ehird> 19:41 MyCatVerbs: ehird: I would guess that they're fairly lazy, so you end up with enormous thunks.
|
|
|
116 2009-04-28.txt:19:42:46: <AnMaster> not the details, just what a thunk is
|
|
|
117 2009-04-28.txt:19:42:56: <ehird> AnMaster: A thunk is a function that evaluates the lazy code.
|
|
|
118 2009-04-28.txt:19:43:04: <ehird> So (2+2) is a thunk that calculates 2+2 then replaces it with that value
|
|
|
119 2009-04-28.txt:19:43:08: <ehird> Where 2, 2, and (+) are also thunks
|
|
|
120 2009-04-29.txt:17:44:24: <Deewiant> ehird: My guess is you're building up a thunkpile of Map.inserts which is what overflows your stack
|
|
|
121 2009-04-29.txt:17:45:36: <Deewiant> ehird: Don't build up a thunkpile like that?
|
|
|
122 2009-04-29.txt:17:46:12: <Deewiant> ehird: Given that you're using crap like {-# UNPACK #-} I figured you'd know how to force a thunk
|
|
|
123 2009-05-08.txt:20:11:29: <ehird> pikhq: http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/
|
|
|
124 2009-05-10.txt:22:40:40: <ehird> optional procedure: (with-input-from-file string thunk)
|
|
|
125 2009-05-10.txt:22:40:40: <ehird> optional procedure: (with-output-to-file string thunk)
|
|
|
126 2009-05-21.txt:20:00:17: <GregorR-L> *ka-THUNK*
|
|
|
127 2009-05-30.txt:00:49:25: <ehird> GregorR-L: I'm thunkin'
|
|
|
128 2009-06-21.txt:20:31:08: <ehird> bsmntbombdood_: http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/
|
|
|
129 2009-06-22.txt:22:37:20: <ehird> SimonRC: Methunk you mean "Methunk you mean"
|
|
|
130 2009-06-24.txt:20:17:02: <pikhq> DOS thunk, I'd imagine.
|
|
|
131 2009-07-12.txt:00:03:52: <ehird> isSigned f = thunk (waitForInput f)
|
|
|
132 2009-07-12.txt:00:03:58: <ehird> isSigned f = analyze (thunk (waitForInput f))
|
|
|
133 2009-07-21.txt:01:39:20: * pikhq returns a vomit thunk
|
|
|
134 2009-07-21.txt:01:40:00: <ehird> pikhq: a vomit thunk?
|
|
|
135 2009-07-21.txt:01:40:07: <ehird> maybe a thunk of type IO Vomit?
|
|
|
136 2009-07-21.txt:01:40:17: <pikhq> ehird: It's a thunk that, when evaluated, results in vomit.
|
|
|
137 2009-08-07.txt:23:54:34: <ehird> human communication being subjective and imprecise. who'da thunk it!
|
|
|
138 2009-08-09.txt:00:19:17: <pikhq> It takes less code to talk to the VGA card manually then it does to thunk to the BIOS...
|
|
|
139 2009-08-09.txt:00:20:01: <AnMaster> pikhq, well iirc the first few lines are traditionally done by thunk to BIOS. Like when grub is printing "Loading stage 1.5"
|
|
|
140 2009-08-10.txt:16:36:40: <ehird> QEMU can launch Linux or Darwin/Mac OS X processes compiled for one CPU on another CPU. Target OS system calls are thunked for endianness and 32/64 bit mismatches.]]
|
|
|
141 2009-09-22.txt:03:47:43: <augur> all haskell function arguments are effectively thunks
|
|
|
142 2009-10-02.txt:12:10:39: <fungot> ehird95: you should have called it ++c c-- --c) and ( compose-event-monitor thunk2 em), when a context of an interpreter
|
|
|
143 2009-10-02.txt:12:11:34: <ehird95> ++cc c-- --c) and ( compose-event-monitor thunk2 em)?
|
|
|
144 2009-11-23.txt:01:14:21: <coppro> ehird: A conditional jump to a thunk
|
|
|
145 2009-12-15.txt:22:12:06: <AnMaster> ehirdiphone, well, non-trivial to do on the fly, probably easier to put a thunking layer in between
|
|
|
146 2009-12-22.txt:19:27:53: <ehird> but it looks like <thunk> to haskell, which if you examine the head becomes 1:<thunk>
|
|
|
147 2009-12-22.txt:19:28:01: <ehird> if you examine the head of the tail it becomes 1:(1:<thunk>)
|
|
|
148 2009-12-24.txt:01:04:37: <ehird_> pikhq: I tried evaluating that, but the thunk diverged.
|
|
|
149 2010-01-08.txt:15:21:37: <ehird> Think thunks.
|
|
|
150 2010-01-16.txt:13:25:18: <ehird> oklopol: stfu, i'm musing about thoughts that were not thunk in this quantum stream but were thunk in some other quantum stream, that is unthunk thoughts, affecting the (I postulate for no particular reason commutative) p-therefore-q-as-a-thought-process operation so that you think a thought, and then you think (because of the unthinking) a thought by which you derive the previous thought, but this turns out to be a contradiction that you couldn't check
|
|
|
151 2010-01-16.txt:13:28:44: <ehird> hmm so if you can communicate across many-worlds branches, then you could cause unthunk thoughts to mingle with this thought stream and become thunk thoughts, thus removing the permutations they performed on your thoughts and instead becoming first-class citizens (albeit being q-thought-before-p in (p therefore q)) of thought
|
|
|
152 2010-01-16.txt:13:29:05: <ehird> therefore, achieving "enlightenment" could be modelled as having no unthunk thoughts; having every thought be thunk by quantum methods
|
|
|
153 2010-01-16.txt:13:33:33: <ehird> oklopol: maybe you unthunk something in the far, far future about trees that is bad
|
|
|
154 2010-01-16.txt:13:34:52: <oklopol> we could model thinking as a process that takes unthunk thoughts, unprocessed data, and outputs thunk thoughts, some sort of results. if there were multiple worlds with the same entity existing multiple times, living almost exactly the same lives, he could skip ahead in his thoughts by accessing the thunk thoughts of a fellow him.
|
|
|
155 2010-01-16.txt:13:36:22: <ehird> oklopol: let's mutually thunk the other's unthunk thoughts so as to expand both our repertoire of thoughts (← this is what sex is like post-singularity)
|
|
|
156 2010-01-16.txt:13:37:58: <ehird> post-singularity thunk sex.
|
|
|
157 2010-01-16.txt:13:44:18: <ehird> you have been acting to cause the recession since before it began, and the p in p-therefore-q that lead you to doing this was only thunk then
|
|
|
158 2010-01-18.txt:01:01:07: <uorygl> some stuff that makes it return a thunk
|
|
|
159 2010-01-18.txt:17:39:04: <pikhq> The only way I could make this uglier is to do thunks.
|
|
|
160 2010-01-26.txt:19:28:24: <pikhq> Now if I could just figure out why the crap this darned thing is only dethunking once.
|
|
|
161 2010-01-26.txt:23:45:11: <pikhq> And thunks confuse it greatly.
|
|
|
162 2010-01-27.txt:21:00:54: <pikhq> main.c:112:1: error: pasting ""S"" and "_thunk" does not give a valid preprocessing token
|
|
|
163 2010-01-27.txt:21:01:38: <pikhq> AnMaster: name##_thunk
|
|
|
164 2010-01-27.txt:21:03:03: <pikhq> static void *__LAMBDA__I_thunk (void*c) { { { return ({ void* __LAMBDA__ (void *_, closure x) { { printf("I thunk (%p)!\n", x); return x; }; }; closure _x = ({ closure _x = xgc_malloc; _x->func(_x->close, sizeof(struct closure)); }); *_x = (struct closure){ __LAMBDA__, ((void *)0) }; _x; }); }; }; } static struct closure __LAMBDA__I_thunk_ = { __LAMBDA__I_thunk, ((void *)0) }; static closure I_thunk = &__LAMBDA__I_thunk_;; static struct th
|
|
|
165 2010-01-27.txt:21:07:03: <pikhq> So many thunks...
|
|
|
166 2010-01-29.txt:17:39:31: <pikhq> PITA, but less of a PITA than figuring out where in the world the thunks are going.
|
|
|
167 2010-01-29.txt:17:49:28: <pikhq> dethunk(callerT(toChurch(2), 2, tmp, I));
|
|
|
168 2010-01-29.txt:18:39:35: <pikhq> Anyways. Now I just make my churchSucc thunk compile that, and voila.
|
|
|
169 2010-01-29.txt:18:42:26: <pikhq> global_thunk(static, churchSucc, NULL, {return dethunk(eval(genList("(S(KS)K)(S((S(KS)K)(S(KS)K)I))((S(S(K(S(KS)K))S)(KK))((S(KS)K)(S(S(K(S(KS)K))S)(KK))((S(KS)K)((S(KS)K)(S(KS)K))((S(S(K(S(KS)K))S)(KK))((S(KS)K)(S(KS)K)I)I)))I)")));});
|
|
|
170 2010-01-29.txt:22:12:37: <pikhq> Well, that explains at least *some* things. church1's thunks are the only ones being called.
|
|
|
171 2010-01-29.txt:22:13:02: <pikhq> Somehow, it never ends up dethunking its arguments.
|
|
|
172 2010-01-29.txt:22:13:08: <pikhq> Even the one that it dethunks and calls.
|
|
|
173 2010-01-30.txt:05:51:25: <pikhq> So if you're doing a lot of arithmetic, it won't be thunking to and from an integer.
|
|
|
174 2010-01-30.txt:05:52:09: <pikhq> Sorry, I've been writing the word "thunk" a lot today. :P
|
|
|
175 2010-01-30.txt:05:52:23: <Gregor> Thunks thunking thunks thunk thunk thunk.
|
|
|
176 2010-01-30.txt:05:52:48: <pikhq> It tends to thunk.
|
|
|
177 2010-01-31.txt:02:11:23: <pikhq> Instead of a thunk.
|
|
|
178 2010-01-31.txt:02:15:16: <pikhq> Thunk 0x6382a0 is not a valid thunk. 0x6382a0 = {tag = 4198720, union {func = 0x638300, data = 0x638300}
|
|
|
179 2010-01-31.txt:02:15:47: <pikhq> Note: enum {THUNK_UNEVAL, THUNK_EVAL} tag;
|
|
|
180 2010-01-31.txt:02:28:15: <pikhq> The issue is that somehow, someone is trying to dethunk a closure.
|
|
|
181 2010-01-31.txt:02:28:23: <Sgeo> What's a thunk?
|
|
|
182 2010-01-31.txt:02:28:33: * AnMaster thunks Sgeo on the head
|
|
|
183 2010-01-31.txt:02:29:06: <pikhq> struct thunk {enum {THUNK_UNEVAL, THUNK_EVAL} tag;union {closure func;void *data;};}
|
|
|
184 2010-01-31.txt:02:30:42: <pikhq> enum {THUNK_UNEVAL, THUNK_EVAL} is the enum declaration...
|
|
|
185 2010-01-31.txt:02:32:38: <pikhq> The thing is, 0x6382a0 is a pointer to a *closure*, not a thunk.
|
|
|
186 2010-01-31.txt:02:33:25: <pikhq> dethunk results in a void*.
|
|
|
187 2010-01-31.txt:02:35:48: <pikhq> I have a couple. They are closure and thunk.
|
|
|
188 2010-01-31.txt:02:38:26: * pikhq looks for anything that *doesn't* return a thunk
|
|
|
189 2010-01-31.txt:02:38:45: <pikhq> (aside from my thunks, which absolutely should not return a thunk)
|
|
|
190 2010-01-31.txt:02:51:33: <Sgeo> I still don't know what thunk is supposed to mean >.>
|
|
|
191 2010-01-31.txt:03:03:47: <pikhq> main.c:360:1: error: unterminated argument list invoking macro "global_thunk"
|
|
|
192 2010-01-31.txt:03:47:01: * pikhq is still amused by the lambdas with thunks that compile them from S and K.
|
|
|
193 2010-01-31.txt:19:57:21: <pikhq> From the looks of things, its the fact that S and K get dethunked for everything.
|
|
|
194 2010-01-31.txt:23:29:27: <pikhq> It would seem that all my thunks retained values in their closure even after being allocated.
|
|
|
195 2010-02-01.txt:01:34:57: <pikhq> In this case, I was holding on to references before dethunking something.
|
|
|
196 2010-02-01.txt:01:35:10: <pikhq> And a dethunk can take, well, any amount of time.
|
|
|
197 2010-02-01.txt:01:39:07: <pikhq> The biggest gain I got was making the dethunk function actually remove its closure... That's such a ridiculous source of memory leaks.
|
|
|
198 2010-02-13.txt:00:52:51: <alise> x; y = x (thunk y)
|
|
|
199 2010-02-13.txt:00:53:34: <alise> print "hi" (thunk (print "yo" (thunk (getLine (lambda x (print x))))))
|
|
|
200 2010-02-13.txt:00:53:46: <alise> x; = x (thunk nil)
|
|
|
201 2010-03-02.txt:20:06:11: <alise> Who'da thunk it
|
|
|
202 2010-03-15.txt:05:54:01: <myndzi> sure! one of the reasons lojban was thunk up was to have a language that could be unambiguously machine-processed
|
|
|
203 2010-04-09.txt:19:07:54: <Deewiant> I assume that parametrizable languages can be thunk of as one language
|
|
|
204 2010-04-24.txt:02:08:44: <oklopod> i would've thunk p v ~p just says in any model of the system one is true, if we can't prove either then it depends on the model which one is true
|
|
|
205 2010-04-29.txt:16:03:02: <Rugxulo> who'd thunk it? ^_^
|
|
|
206 2010-06-07.txt:17:54:33: <ais523> AnMaster: no, think of it more like thunks
|
|
|
207 2010-06-07.txt:17:55:28: <AnMaster> ais523, um? was ages ago I heard about "thunks" last, and it was something related to windows 3.1 iirc
|
|
|
208 2010-06-21.txt:05:07:15: <coppro> don't they usually have a dynamic thunk?
|
|
|
209 2010-06-28.txt:19:31:58: <pikhq> Gregor-W: Basically: we try to offer native libraries as much as possible. However, allow for access to host libraries by writing thunks to transfer between the ABIs. My opinion on this may well change if writing thunks is going to be more difficult than a few lines of assembly or C per function.
|
|
|
210 2010-06-28.txt:19:32:28: <Gregor-W> pikhq: I get the feeling that thunks will basically be lunacy. Just my own fears manifesting themselves though ^^
|
|
|
211 2010-06-28.txt:19:32:52: <pikhq> Gregor-W: On Linux, thunks would probably be trivial. On OS X, not much work.
|
|
|
212 2010-06-28.txt:19:33:50: <Gregor-W> pikhq: No use making thunks that only work on one platform ;)
|
|
|
213 2010-06-28.txt:19:38:28: <zzo38> I think you should just have a file gelfload.conf with commands such as DYNLINK, STUB, SYSCALL, THUNKCODE, TRANSLATE, and so on.
|
|
|
214 2010-06-28.txt:19:40:33: <zzo38> Doing it this way I specified can mean that you can change the system call gates and thunk codes and so on, for different systems and for different libraries you might use
|
|
|
215 2010-06-28.txt:19:44:48: <pikhq> The only thick thing here is thunking through to the host ABI.
|
|
|
216 2010-07-16.txt:15:08:23: <alise> CakeProphet: Yeah, turns out Genie is a language. Who'da thunk it?
|
|
|
217 2010-07-25.txt:22:10:04: <pikhq> Alternately, you will have absurdly large *thunks*.
|
|
|
218 2010-08-05.txt:21:59:44: <oerjan> however this has the _practical_ consequence of evaluating the thunk for the first argument, with all usual caching results and plugging of memory leaks
|
|
|
219 2010-08-11.txt:23:20:48: <augur> but in the context of the metaphor i decided that i must be a thunk, not a proper function or else i wasnt going to fall asleep any time soon
|
|
|
220 2010-08-11.txt:23:21:49: <Phantom_Hoover> augur, no such things as thunks in the pure lambda calculus, though.
|
|
|
221 2010-10-07.txt:20:59:10: <pikhq> Especially where I copy a thunk before it's evaluated so that I can do an infinite list of input.
|
|
|
222 2010-11-09.txt:19:43:02: <elliott> olsner: (so apparently sizeof("abc"+1) = 2, who'da thunk it? I guess?)
|
|
|
223 2010-12-18.txt:21:12:43: <elliott> Who'da thunk it.
|
|
|
224 2010-12-27.txt:18:45:10: <elliott> Ilari: Switch statements being slow, who'da thunk it.
|
|
|
225 2011-01-03.txt:23:44:23: <olsner> elliott: continuing from before, what I have in mind is not really "macros" in the typical code-that-makes-code macros... rather something like type classes, let's say it'd let you define a category of "boxed values" and describe that they are thunks that get forced when looked at
|
|
|
226 2011-02-01.txt:06:36:08: <oerjan> in haskell boxed also implies the possibility of a lazy thunk to be evaluated
|
|
|
227 2011-02-09.txt:01:56:08: <quintopia> who'dathunk that'd work so well
|
|
|
228 2011-02-09.txt:01:56:18: <myndzi> i woulda thunk :)
|
|
|
229 2011-02-11.txt:17:59:14: <elliott> apparently the programs . and [-] draw, whodathunkit?
|
|
|
230 2011-02-15.txt:01:45:56: <quintopia> who'dathunk?
|
|
|
231 2011-02-20.txt:00:13:20: <quintopia> usually it's because they involve some sort of unusual control flow that requires funky ways of thunking
|
|
|
232 2011-02-22.txt:03:32:28: <oerjan> *thunk
|
|
|
233 2011-02-22.txt:03:33:26: <elliott> oerjan: not sure how to avoid building a large thunk there, anyway
|
|
|
234 2011-02-22.txt:19:39:30: <olsner> and I think you can see when thunks get allocated instead of plain values getting returned
|
|
|
235 2011-02-22.txt:22:37:37: <elliott_> maybe it's thunked
|
|
|
236 2011-02-27.txt:00:58:56: <elliott> good triumphs over evil, who'da thunk it?!
|
|
|
237 2011-03-03.txt:16:56:52: <ais523> it's full of thunks and that sort of thing
|
|
|
238 2011-03-12.txt:17:49:37: <elliott> I guess something that lets you write haskell.run_io(haskell.eval("putStrLn").call(Thunk(lambda: haskell.make_string("Hello, world!"))))
|
|
|
239 2011-03-14.txt:07:44:27: <elliott> from now on I will talk only in Has<THUNK>
|
|
|
240 2011-03-14.txt:07:48:55: <coppro> 03:28 < elliott> from now on I will talk only in Has<THUNK>
|
|
|
241 2011-04-03.txt:08:31:58: <elliott> I've been thunkin'.
|
|
|
242 2011-04-05.txt:22:08:08: <tswett> Who'dathunk?
|
|
|
243 2011-05-13.txt:01:10:44: <elliott> Remember that the blocks execute /every/ time the thunk is left, including multiple times thanks to CALL-WITH-CURRENT-CONTINUATION.
|
|
|
244 2011-05-13.txt:01:17:32: <elliott> (Thunk passed is the same as (lambda () (values)).)
|
|
|
245 2011-05-13.txt:17:18:06: <ais523> so long as you have some other way to not call a function argument immediately (say, call-by-name, thunking by hand, etc)
|
|
|
246 2011-05-17.txt:15:17:33: <elliott_> It just means it'll be evaluated before the thunk is.
|
|
|
247 2011-05-20.txt:19:36:11: <Deewiant> Who'da thunk it
|
|
|
248 2011-05-21.txt:20:29:06: <elliott> you'd still do all the thunks
|
|
|
249 2011-05-21.txt:20:31:56: <elliott> oerjan: Ideally the thunks would become explicit too...
|
|
|
250 2011-05-22.txt:04:45:49: <elliott_> I was thinking that you could do CPS if you just returned /immediately/ with a thunk
|
|
|
251 2011-05-22.txt:04:45:57: <elliott_> and that thunk would then do one CPS-step when called, and return another thunk, etc.
|
|
|
252 2011-05-27.txt:06:08:56: <elliott_> i think it's building up EVERY SINGLE THUNK
|
|
|
253 2011-05-27.txt:19:31:56: <pikhq> And it doesn't seem to be because of thunks...
|
|
|
254 2011-06-02.txt:12:21:30: <elliott> hmm, you basically have to thunk everything in an unlambda compiler, right?
|
|
|
255 2011-06-02.txt:12:25:13: <elliott> if the whole program is a thunk like this
|
|
|
256 2011-06-02.txt:12:29:10: <elliott> oerjan: it even made the whole thunk thing transparent :(
|
|
|
257 2011-06-02.txt:12:39:39: <elliott> oerjan: basically i was trying to unify thunks and functions...
|
|
|
258 2011-06-02.txt:12:39:54: <elliott> oerjan: by just making thunks pretend they're the function they evaluate to, by forcing themselves and then passing that argument on
|
|
|
259 2011-06-02.txt:12:49:57: <elliott> oerjan: thunks are ugly :(
|
|
|
260 2011-06-02.txt:13:05:08: <elliott> oerjan: so I don't have to do the Haskellian "thunks stub themselves out with {return value;} upon evaluation"?
|
|
|
261 2011-06-02.txt:19:44:37: <elliott_> THUNK(a, APPLY(&prim_out_x, &prim_i))
|
|
|
262 2011-06-02.txt:19:44:37: <elliott_> THUNK(b, APPLY(&prim_d, &thk_a))
|
|
|
263 2011-06-02.txt:19:44:37: <elliott_> THUNK(c, APPLY(&prim_i, &thk_b))
|
|
|
264 2011-06-02.txt:19:44:37: <elliott_> THUNK(d, APPLY(&thk_c, &prim_i))
|
|
|
265 2011-06-02.txt:19:44:54: <elliott_> and so fold a bunch of thunks into one
|
|
|
266 2011-06-02.txt:20:18:31: <elliott_> THUNK(a, APPLY(&prim_s, &prim_d))
|
|
|
267 2011-06-02.txt:20:18:32: <elliott_> THUNK(b, APPLY(&prim_k, &prim_out_x))
|
|
|
268 2011-06-02.txt:20:18:34: <elliott_> THUNK(c, APPLY(&thk_a, &thk_b))
|
|
|
269 2011-06-02.txt:20:18:36: <elliott_> THUNK(d, APPLY(&thk_c, &prim_out_y))
|
|
|
270 2011-06-02.txt:20:20:36: <elliott_> pikhq_: its not similar really, the thunks are pretty different
|
|
|
271 2011-06-07.txt:23:10:06: <CakeProphet> massive thunk registers.
|
|
|
272 2011-06-08.txt:18:50:23: <ais523> elliott: well, you could take an unapplied or thunked continuation, and give it as an argument to a continuation, without any real issues
|
|
|
273 2011-06-08.txt:21:55:32: <elliott> > thanks "thunks"
|
|
|
274 2011-06-08.txt:21:55:34: <lambdabot> Thanks, thunks. Thunks.
|
|
|
275 2011-06-09.txt:00:45:51: <oerjan> it is possible there's some huge thunk building because of this...
|
|
|
276 2011-06-21.txt:13:06:59: <elliott_> Deewiant: Int thunks :-)
|
|
|
277 2011-06-21.txt:19:32:11: <pikhq_> Probably building up a thunk.
|
|
|
278 2011-06-21.txt:19:39:53: <oerjan> elliott_: perhaps that fmap is also building thunks of what to apply
|
|
|
279 2011-06-23.txt:03:59:35: <elliott_> in a misguided attempt to reduce a thunk leak that isn't there
|
|
|
280 2011-06-23.txt:04:00:42: <elliott_> CakeProphet: btw, if countBytes wasn't strict in n, it would blow up a huge thunk.
|
|
|
281 2011-06-24.txt:21:50:54: <elliott> oerjan: "You cannot use atomically inside an unsafePerformIO or unsafeInterleaveIO. Any attempt to do so will result in a runtime error. (Reason: allowing this would effectively allow a transaction inside a transaction, depending on exactly when the thunk is evaluated.)"
|
|
|
282 2011-06-25.txt:11:13:51: <elliott> oerjan: i'm thinking you could pass a thunk to the folding function instead
|
|
|
283 2011-06-25.txt:11:15:12: <elliott> may want the thunk first
|
|
|
284 2011-06-25.txt:11:22:12: <oerjan> well you need your thunk to self-duplicate so you can use it at the next step
|
|
|
285 2011-06-25.txt:11:22:27: <elliott> oerjan: the idea is that the list itself handles the thunk... i think
|
|
|
286 2011-06-25.txt:11:28:07: <oerjan> elliott: if the list handles the thunk, then that means the list automatically folds, which means you must always iterate through all of it...
|
|
|
287 2011-06-26.txt:20:47:08: <oerjan> foldl can build up a thunk if ghc cannot detect that the folding operation is strict
|
|
|
288 2011-06-29.txt:19:20:23: <elliott> Vorpal: ok see http://web.archive.org/web/20090224074532/http://thunk.org/tytso/blog/2009/02/20/aligning-filesystems-to-an-ssds-erase-block-size/
|
|
|
289 2011-06-30.txt:02:58:10: <oerjan> i have a hunch that that would have overflowed the stack if it actually got to finish building the thunks...
|
|
|
290 2011-07-01.txt:20:05:25: <elliott> It's just reducing a thunk
|
|
|
291 2011-07-01.txt:20:05:47: <newsham> elliott: yah, replacing the thunk with its result.. memoization.
|
|
|
292 2011-07-01.txt:20:06:14: <elliott> newsham: it's more like memoisation is ak ind of thunk reduction.
|
|
|
293 2011-07-01.txt:20:09:11: <elliott> oerjan: I'm just saying that any implementation that _didn't_ reduce thunks in such a way would be completely braindead
|
|
|
294 2011-07-01.txt:20:11:17: <elliott> newsham: Anyway, there is no sharing or thunks as such in my model
|
|
|
295 2011-07-01.txt:20:13:18: <newsham> [10:08] < elliott> newsham: Anyway, there is no sharing or thunks as such in my model
|
|
|
296 2011-07-06.txt:08:38:41: <elliott> Vorpal: because everything is in a thunk
|
|
|
297 2011-07-08.txt:08:39:07: <elliott> when x is bound to an exception-raising thunk.
|
|
|
298 2011-07-23.txt:02:37:26: <elliott_> Think thunks
|
|
|
299 2011-07-23.txt:02:37:48: <elliott_> You're deleting the thunk that represents that running code
|
|
|
300 2011-08-05.txt:20:24:32: <elliott> Cheery: Thunk.
|
|
|
301 [too many lines; stopping]
|
