00:00:19 so then this method cannot be used, and any while can only be broken by fully zeroing its variable 00:01:09 Yes. 00:01:45 Anyone who needs to use something more efficient sure as hell isn't going to be using our macros, anyways; one can be much more efficient with hand-coding. 00:02:14 so SimonRC was right after all ;) 00:02:26 No, he's not. 00:02:51 Handcoding in BFM, without using our generalised macros, can be just as efficient. ;) 00:03:29 i think the problem could be fixed using arrays, though 00:04:00 Have you *seen* the code necessary for an array implementation in Brainfuck? 00:04:17 if x and temp were parts of arrays of length 2, then there would be enough positioning 00:04:40 i don't mean unbounded arrays, just a positioned array of predeclared variables 00:05:02 That just defeats the idea of generalising the code. 00:06:54 not necessarily, the macro would just work on a slightly different structure 00:07:23 so in a sense it wouldn't be a booland for single cells at all, but it could still be useful 00:08:00 anyhow, i suppose the current booland is well enough for when you do have single cells 00:08:17 It's good at what it does. ;) 00:09:19 any array based implementation would need moving to work for single cells, which defeats the purpose of avoid the zeroing out 00:09:39 *avoiding 00:11:05 anyhow, i got derailed while trying to understand your mod code, back to that 00:12:08 Hahah. 00:12:37 Might want to change it over to the current BFM build once you figure out why it doesn't work. 00:21:52 hm, do you consider it necessary to zero out temp variables that aren't used? 00:24:09 (on second thought, my idea to avoid that in one macro depends on the copy macro doing precisely that 00:24:13 ) 00:24:51 Temp variables are sort-of supposed to be used. . . 00:25:03 If it's unused, then don' 00:25:10 t take the variable as an argument. 00:25:10 :p 00:25:53 what i mean is if the variable is sometimes used, but not always, like in divvar: temp1 and temp2 00:26:34 (if x is zero the while loop is never entered) 00:28:38 Ah. 00:29:05 Yeah, one should clear your temp variables before running loops. . . 00:29:44 Allows one to assume any temp variables are 0 after a macro call. ;) 00:30:05 exactly 00:30:37 although set temp 0 is wholly superfluous 00:34:05 -!- kipple_ has quit (Read error: 110 (Connection timed out)). 00:39:03 -!- graue has joined. 00:40:20 hello 00:40:27 hello 00:40:28 'Lo. 01:11:15 Do I smell a Wiki admin? 01:11:30 Or is that just a Grue? 01:11:52 A graue. 01:11:58 * ihope nods 01:12:20 Now, through some careful experimentation, I have figured out how a pencil sharpener works. 01:12:34 As you know, outlets contain electricity. 01:12:46 And as you know, electricity is a liquid at room temperature. 01:13:10 BZZT 01:13:43 -!- Arrogant has joined. 01:13:54 Plugging in a pencil sharpener causes the electricity to flow through the wires, where some enzymes turn it into a chemical called PPS, or passive pencil sharpener. 01:14:13 Also, pencils emit a chemical known simply as "pencil", 01:14:34 * pikhq wants some of what ihope's smoking 01:14:37 Must be some good shit. 01:14:46 :p 01:15:03 How'd you guess what I was smoking? 01:15:08 Um, anyway. 01:15:58 The PPS reacts with the pencil to form a new chemical called APS, or active pencil sharpener. 01:16:22 This reaction also emits a sound best described as a loud sort of whirring. 01:17:09 Finally, the APS reacts with the pencil itself, causing some of the wood to evaporate. 01:17:25 It does so in such a way to make the pencil sharp, for obvious reasons. 01:18:22 Now, the pencil sharpener in my biology classroom is so good that the PPS is actually blowing out of the pencil sharpener, so that if you put a pencil too close to it, the pencil becomes sharpened. 01:19:05 * ihope bows 01:19:12 * ihope suddenly remembers his homework 01:19:15 -!- ihope has quit ("http://tunes.org/~nef/logs/esoteric/06.08.09"). 01:19:37 * oerjan is shocked! 01:20:16 all these years of advanced education and no one is telling me this! 01:21:07 instead of vainly trying to satisfy my curiosity i could have followed my true dream and become a fire constable 01:21:18 * oerjan sobs 01:24:40 * oerjan has satisfied himself that divvar works 01:25:08 I did the same much more simply. 01:25:26 I take it, though, that you're going through confirming that all of my macros are done well? 01:25:52 If so, let me just say that I greatly appreciate that. 01:25:57 just the pastebin left 01:26:03 Ah. 01:26:18 Still. . . :) 01:26:26 well, not all, only those included by that 01:26:49 although i suspect divvar is among the most complex... 01:26:59 It is *the* most complex. 01:27:43 copy works very, very simply. 01:28:19 >[-]>[-]<<[>+>+<<-]>[-<+>] is the code in full. 01:29:11 btw, when you use both div and mod it might usually be a good idea to combine them 01:29:18 Yeah. 01:29:35 I was *trying* to get the macro to work at all in the first place. 01:33:14 I've confirmed one thing: the bug is in my mod macro. 01:33:31 Unless you wish to argue that 25 % 50=233, that is. 01:37:16 "For some values of %." 01:37:25 fizzie: XD 01:37:27 i have not analyzed it yet, but i have a sneaking feeling... 01:37:49 did you get the booland arguments in the right order? 01:37:56 oerjan: My "analysis" method is "call the macro with arguments which we know the appropriate result for". ;) 01:38:19 Indeed, I did. 01:38:55 so the second argument is the result? 01:39:10 in the mod macro definition i mean 01:39:36 Um. . . No, the first one. . . 01:40:01 And booland stores the result in the first argument. . . 01:40:10 nope, second 01:40:46 The only time booland touches the second one is to copy it into a temporary variable. 01:41:11 check again. 01:41:28 The BFM version I'm testing this one predates the standardisation of input, output, temp. 01:41:31 note that x is the _second_ argument. 01:41:41 oh. 01:42:10 I've yet to port to the new version the currently-existing code of mine beyond stdlib. 01:42:18 Task for class tomorrow. 01:48:26 You know, other people can feel free to chime in on the sheer insanity of this. . . 01:48:48 and then we'll beat them to a pulp. freely. 01:48:53 Indeed. 01:50:24 macro beattopulp {person pointer} {result} {temp} {comment {I've not finished this yet.};copy person > pointer : temp;move pointer > result} 02:02:18 Did subvar also previously take its result in the first argument? 02:04:15 ah! mystery solved 02:04:37 add result 2 should be addvar result v2 02:05:15 * tmp1 02:11:41 How the *hell* did I mix that up? 02:12:40 no idea. now to see if i can extract mod from the divvar calculation simultaneously 02:13:08 Now, I've got a different question. . . 02:13:14 Why isn't itoa working now? 02:13:25 hm... 02:13:35 is mod working? 02:13:46 It is. 02:14:11 25%50 *is* 25, right? :p 02:14:22 so i've heard 02:18:30 are the correct a1, a2, a3 calculated? 02:18:55 -!- GregorR-L has joined. 02:20:34 ah. mod doesn't preserve its second argument. 02:22:17 Well, there's the problem. :p 02:22:47 -!- Arrogant has quit (Read error: 110 (Connection timed out)). 02:27:04 Bwahahah! 02:27:07 (it works) 02:27:53 It's also horribly large and inefficient, but hell; I'm happy. 02:28:42 Most of it's just large amounts of pointer movement, though. :/ 02:32:35 Now, I assume you'd like the new source. . . 02:34:06 http://pikhq.nonlogic.org/itoa.bfm 02:34:08 btw the last divvar is redundant 02:34:29 Thanks. 02:34:50 1847 characters. . . 02:34:57 That's one huge bit of code for itoa. 02:35:51 it should shorten a bit with a divmod macro 02:36:06 Yeah. 02:36:28 Even more if I just tidy up the usage of tmp vars in some places. 02:38:44 hm... in divvar, if you move the last subtract temp1 1 up a bit then you can delete the others 02:39:36 (+ the add) 02:45:02 -!- CXI has quit (Read error: 104 (Connection reset by peer)). 02:45:02 -!- CakeProphet has quit (Read error: 104 (Connection reset by peer)). 02:45:27 now, right after the inner while temp1 {, add copy y > mod : temp3 ; subvar temp1 > mod : temp3 02:45:51 -!- Sgeo has quit (Connection timed out). 02:46:00 -!- CXI has joined. 02:46:02 -!- CakeProphet has joined. 02:47:15 and a set mod = 0 earlier. That should be enought to make it a divmod, i believe 02:48:58 And, of course, add mod to the args list? :p 02:49:03 yes 02:49:31 Not seeing what you mean about moving the subtract temp1 1. . . 02:53:01 Odd. . . 02:53:16 i'll write it up 02:53:35 Surely 51/25=2 remainder 1? 02:53:42 0:51|0|24|*0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0| 02:53:46 yes 02:53:52 something wrong? 02:54:03 Cell 0 is y, cell 1 is x, cell 2 is mod. . . 02:55:45 is this the mod macro that seemed to work before? 02:56:22 No, it's divmod. 02:56:37 . . . OH. 02:56:37 the one i suggested? 02:56:46 Innermost while temp1. XD 02:56:58 yep 02:57:51 Now we've got it saying 51%25=25, and 51/25=0. 02:58:52 0:51|0|25|*0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0| 02:59:53 ok, take a look at http://home.nvg.org/~oerjan/divmodvar.bfm 03:00:04 i haven't tested it, though 03:00:22 Exactly what I've got. 03:01:18 The bug is in subvar. 03:01:32 10-5!=251. 03:02:26 Err. . . 03:02:42 Just did 10-5, not 5-10. XD 03:03:55 no, there is a bug in addvar 03:04:00 temp is not cleared 03:05:16 Ah. 03:05:49 That didn't fix it, though. 03:06:11 however that cannot be the problem in divmod, because temp3 _is_ cleared. if you have exactly the same version as i 03:07:47 I do. 03:09:13 Somehow, we're managing to screw up the division ability of divvar without changing any of the actual variables except for one we added ourselves. . . 03:09:16 and are you using the newest stdlib? 03:09:23 Currently, yes. 03:09:54 Otherwise, move x > temp wouldn't work. 03:10:26 wait. i just saw something. 03:11:11 :) 03:11:19 no. false alarm. 03:11:24 :( 03:13:10 Well, I found out *one* bit of the problem. . . 03:13:18 ? 03:13:24 *Without* our changes, it doesn't seem to work. 03:13:52 you mean there is something wrong with divvar from the start? 03:14:34 Yeah. 03:14:43 Unless you argue that 25/51=0. 03:14:48 Err. 03:14:52 51/25=0 03:17:31 is the new input/output/temp separation working properly? 03:17:55 Yes. . . 03:17:58 Hello. 03:18:05 hi 03:18:43 Hmm. Seems to work with divvar a > b : d e f g when a=5, b=11. . . 03:19:41 But. . . Not for anything else?!? 03:20:00 I'm going to give up. 03:20:48 . . . Hrm. Maybe I was giving it the wrong bloody arguments. 03:20:52 . . . Yup, I was. 03:21:46 is it working anyhow? 03:21:47 divvar a > b : d e f g does b/a, not a/b. XD 03:21:50 Yeah. 03:21:53 Now to test divmod. 03:22:17 * oerjan cannot stand the suspense 03:23:14 YAY! 03:23:37 * oerjan does the happy dance 03:23:47 You know, if you guys used test-driven development, you would KNOW your code was going to work. 03:23:59 Silly 90s "good enough" programming techniques. Tsk. 03:24:58 We're coding in Brainfuck. We are therefore insane. . . 03:26:07 * oerjan prefers formal proof. in principle. 03:26:24 Working on itoa? 03:27:19 sort of. itoa is working, but using separate div and mod macros 03:27:36 so now we have a divmod one. 03:27:36 Ah. 03:28:20 Porting itoa to the new BFM. . . 03:28:33 And wondering how I broke stuff. 03:28:44 hm. i thought if an argument is both input and output then it counts as output, right? but bitnot isn't that way. 03:28:57 Ah. I see. 03:29:23 on the other hand it seems silly to say bitnot > x 03:29:47 but then, maybe not. 03:30:01 Let me get itoa working first. 03:31:54 i think bitnot is buggy, too. subtract x 1 should be add x 1 03:32:12 because bitnot x = -1 - x 03:33:46 perhaps you meant boolnot 03:35:44 How should I call divmod in itoa, anyways? 03:36:02 divmod tmp > int a1 : tmp1 tmp2 tmp3 tmp4? 03:36:21 sounds about right 03:37:04 I've discovered a bug somewhere. 03:38:24 Ah. 03:38:28 Missed a line. 03:38:55 There we go. . . 03:43:50 1004 characters in itoa.b now. 03:44:16 Could shrink it down a good deal more if it weren't uberparanoid about cell clearing. 03:44:47 But hell; I'm not in the mood to complain. 03:46:59 New BFM up, with itoa.bfm and divmod.bfm in stdlib. 03:47:18 ideally you would want to keep a list of variables you knew were cleared... 03:47:29 Well, yes. 03:48:03 Perhaps it'd be best to set up something like that, and have the list cleared when someone starts using right and left (because then the interpreter doesn't know at all)? 03:49:00 unless there was some declaration like at, for declaring which variables might have been touched 03:49:01 I've been digging through my email and found an itoa that's 122 commands. By Oleg Mazonka with some tweaks from myself. 03:49:09 I bet we can do better, but that's a start anyway. 03:49:26 . . . Damn. 03:50:32 heh. if you remove all instances of [-] from the output, what is its length then? 03:50:50 I'll dig through a little more and see if anyone's improved on it further yet. 03:50:54 119 I think. 03:51:11 I'll check after I get it working without redundant cell clears. 03:51:17 i meant pikhq's version 03:52:57 it would be an indication how much of the size is due to that problem 03:56:32 -!- CXII has joined. 03:56:35 anyhow, time to go to bed 03:56:41 Bertram Felgenhauer did it in 89. 03:56:42 -!- oerjan has quit ("ZZZZZZZZ"). 03:58:59 About cell clearing...I'm not familiar with details of your thing, but when I looked at BFBASIC I noticed that it cleared all cells immediately before use...and that if it cleared all cells that might be nonzero immediately AFTER use, it would have produced shorter code... 03:59:22 so I would think about taking that approach. 04:11:38 808 characters. 04:12:11 Our approach is now "set attempts to discover whether a cell has been touched at all". 04:13:02 -!- CXI has quit (Connection timed out). 04:14:13 Given the is0 directive, we get 752 characters. 04:15:06 We no longer need to feel guilty about excessive cell clearing. :) 04:15:40 Grawr. 04:15:44 Broke something. 04:20:19 I'm playing with Bertram's...he used the same basic idea I was thinking of, but he ended up using 3 cells per output digit, plus a constant. We can use one cell plus a constant without too much trouble, and I think without lengthening it tooo much. 04:25:14 Fixed it. 04:25:26 Forgot set var 10 is also valid. XD 04:25:50 773 characters. 04:28:33 770 characters (one tiny coding mistake). 04:31:41 -!- CXIII has joined. 04:34:05 87. Let me play with it more. 04:35:47 Hand it to me when you're done. . . 04:36:24 -!- CXIII has changed nick to CXI. 04:37:48 Sure. Actually this would have made a pretty decent golf. 04:48:47 -!- CXII has quit (Connection timed out). 05:17:26 -!- CXI has quit (Read error: 104 (Connection reset by peer)). 05:17:26 -!- CakeProphet has quit (Connection reset by peer). 05:18:26 -!- CXI has joined. 05:18:27 -!- CakeProphet has joined. 05:18:35 -!- CXI has quit (Connection reset by peer). 05:21:30 -!- CakeProphet has quit (Read error: 104 (Connection reset by peer)). 05:22:30 -!- CakeProphet has joined. 05:28:40 -!- CakeProphet has quit (Read error: 104 (Connection reset by peer)). 05:29:21 -!- CXI has joined. 05:29:41 -!- CakeProphet has joined. 05:29:57 -!- Asztal has quit (Read error: 60 (Operation timed out)). 05:33:36 -!- ivan` has quit (" HydraIRC -> http://www.hydrairc.com <-"). 05:34:18 -!- graue has quit ("Leaving"). 05:38:03 Still fiddling with this. Have you got a better way to add 48 to a cell than ++++++[>++++++++<-]? 05:39:25 I almost never use wrapping...wondering if it would save in this case. 05:40:02 ++++++[>++++++++<-] is the minimum. 05:46:05 Okay, here's what I've got. You set it up so that there are three zeroes, then the integer to output, then plenty more zeroes. You set the pointer on the third zero. Then you do this. +[+++++++++>[<<+>-[>>>>]<[[>+<-]>>>+>]<<-]<[-]++++++[<++++++++>-]>>[<+>>]<<]<[.[-]<] 05:57:37 No, that's not the minimum--I just checked and apparently -[>+<-----]>---will work too. So for the whole thing we can do +[+++++++++>[<<+>-[>>>>]<[[>+<-]>>>+>]<<-]<[-]-[<+>-----]<--->>>[<+>>]<<]<[.[-]<] 05:58:14 Hmm, but that isn't portable. 05:59:08 ...or better yet, +[+++++++++>[<<+>-[>>>>]<[[>+<-]>>>+>]<<-]<[-]-[<+>-----]>>[<+>>]<<]<[---.[-]<] 05:59:33 Not entirely, no. 06:07:09 -!- anonfunc has joined. 06:07:15 It looks like it will work with 8-bit cells, 16-bit cells...it would be very very slow with 32-bit cells, but should produce the right answer eventually. 06:07:59 64-bit or bignum interpreters, it'd be hopeless on. Likewise any that can't handle negative numbers because they're written in an environment that does not support integers natively, e.g. lambda calculus... 06:08:20 or one that tries to police absolute portability and purposely disallows negating a zero. 06:09:05 ...but as this is for a project that assumes wrapping bytes, it should be fine. 06:09:12 :) 06:50:27 -!- anonfunc has quit (Read error: 110 (Connection timed out)). 06:52:52 -!- anonfunc has joined. 07:12:14 -!- anonfunc has quit. 07:18:15 -!- anonfunc has joined. 07:37:32 -!- anonfunc has quit. 07:39:52 -!- Arrogant has joined. 07:59:59 -!- clog has quit (ended). 08:00:00 -!- clog has joined. 08:10:19 -!- GregorR-L has quit (Read error: 110 (Connection timed out)). 09:06:27 -!- Arrogant has quit ("Leaving"). 09:07:54 -!- CakeProphet has changed nick to notCakeProphet. 10:15:35 -!- anonfunc has joined. 11:10:08 -!- anonfunc has quit (Read error: 104 (Connection reset by peer)). 12:08:30 -!- Azstal has joined. 12:08:32 -!- Azstal has changed nick to Asztal. 13:10:30 -!- oerjan has joined. 13:42:17 now here is something for the practical minded of us: http://en.wikipedia.org/wiki/Chind%C5%8Dgu 13:45:24 -!- notCakeProphet has changed nick to CakeProphet. 13:53:21 NEVER!!! 13:53:31 what? 13:54:33 Be practically minded. 13:54:56 dbc: How many cells of memory does it use? 13:55:00 actually i meant that in a sort of backward way 13:55:19 unpractically minded, even 13:55:19 . . . ARGH. 13:56:07 Not all the loops can be converted over to variables, and therefore it won't be made over into BFM. . . 13:56:38 the positioning trap again? 13:56:46 Yup. 13:57:02 dbc: So, thanks, but we can't really use it. :'( 14:00:53 we could if we used array parameters... 14:03:09 On the bright side, we no longer get redundant cell clearing in our code. :) 14:08:06 how does the redundancy check work inside while loops? 14:11:32 The while loop, at the very end of the loop, adds the variable it operated on (unless it's "while current") to the list of cleared cells. . . 14:12:50 and at the beginning does it empty the list? 14:12:53 Otherwise, it works exactly the same (if it touches a variable, it removes it from the list, if it clears a variable, it gets added to the list). . . 14:13:08 No, the list is only emptied for right and left. 14:13:58 there is a problem there, in that if a variable is touched inside a list it needs to be removed at the beginning of the while as well 14:14:42 Um, no. . . The list of cleared cells is global, not scope-dependant. 14:15:34 consider set x 0; while y { ... ; set x 1 } 14:15:47 inside ... you cannot assume x cleared 14:15:48 -!- jix has joined. 14:16:35 We get x added to the list of cleared cells, and *once* x has been operated on by "set x 1", it's removed from the list. 14:16:54 We *can* assume x has been cleared, because nothing has touched it. ;) 14:17:10 wait a moment. let me clarify. 14:17:23 consider set x 0; while y { set x 0 ; ... ; set x 1 } 14:17:37 then the second set x 0 cannot be removed 14:18:42 Why not? The last time anything operated on x was a cell-clearing operation. . . 14:18:49 * pikhq *really* isn't seeing your point 14:20:05 it cannot be removed the second time the while loop is run 14:20:24 Ah. . . 14:20:50 Yeah, I can see how that could be a bug. 14:22:54 Perhaps add an "isnot0" command to be able to prod the compiler into compliance? 14:25:09 well, if we don't want to do a flow analysis ... 14:25:18 i think is0 is more useful 14:27:19 let's see. have a stack of cleared and touched lists. 14:28:00 at the beginning of a while, push new, empty ones. use the is0 directive to add cleared ones explicitly. 14:28:51 at the end of a while, merge the top two sets 14:30:43 at the end, a variable will be cleared if it was cleared before and not touched at the end inside 14:31:08 but touched if it was touched either before or at the end inside 14:32:35 if neither, then it will be on neither list 14:33:07 this should be a useful approximation without requiring backtracking 14:34:38 you could have an is0 list too, to check consistency 14:37:10 or you could do backtracking to move information back to the beginning of the while 14:37:24 then you could avoid is0 14:37:36 but it would of course be even more complicated 14:40:00 i can imagine a two-pass solution, where you use set x 0 instead of is0 x 14:40:01 -!- lindi-_ has joined. 14:40:59 -!- lindi- has quit (Read error: 113 (No route to host)). 14:42:46 the first pass would keep track of which while bodies clear and touch which variables 14:43:26 the second pass would use that to remove redundant clears 14:45:41 -!- lindi-_ has changed nick to lindi-. 14:46:05 but this solution would require some way of tracking code positions 14:47:59 i think a solution with stacks of cleared, touched, and is0 lists could be a compromise. you would then need to declare with is0, but the declarations would be checked for correctness, and all in one pass 15:13:47 it suddenly occurred to me that redundant clearing is just a special case of redundant while loops. 15:22:31 hm, isnot0 (or rather maybenot0) could be useful too, provided it triggered a promise that no other variables in the while loop would be touched 16:08:19 -!- tgwizard has joined. 16:12:34 -!- GregorR-W has joined. 16:24:15 ... and in other news, another looney nation has The Bomb: http://news.bbc.co.uk/1/hi/world/asia-pacific/6033457.stm 16:50:31 fantastic 16:51:26 the real question, however, is not wether they can make *one*, it's wether they can make a million. That was the entire point of the Manhattan project in the U.S. 16:52:48 -!- kipple_ has joined. 17:04:58 kipple_: hi 17:05:46 hey, kipple. 17:27:33 oerjan: The joys of having a second coder look at my code. :) 17:28:01 I'll probably implement one of those, and get a command line parser running, sometime this afternoon. 17:28:37 Probably have a command line option to stop the redundant clear checking, just to confirm that that's not what's breaking the code. 17:28:44 (if it breaks) 17:37:26 we'll see :) 17:45:28 For now, though, I'll just have is0 and isnot0. 17:49:57 -!- Sgeo has joined. 17:51:02 Sgeo: hi 17:54:47 -!- Sgeo has quit ("Ex-Chat"). 17:55:30 -!- Sgeo has joined. 18:10:23 -!- Azstal has joined. 18:18:53 -!- Asztal has quit (Read error: 60 (Operation timed out)). 18:30:29 -!- oerjan has quit ("later"). 18:38:41 So...hm. The problem is that that itoa can't be decomposed into BFM macros or something? 18:48:20 Just not yours. 18:48:58 I've *got* an itoa in BFM; it's part of stdlib now. 18:49:11 The problem is that *yours* cannot be used with the variable system. 19:03:10 Because it uses a variable amount of memor? 19:07:43 (Note I said "that THAT itoa can't be decomposed", not "that no itoa can be decomposed") 19:09:38 Ah. 19:09:45 dbc: Yeah. 19:10:35 We can't even guarantee that the memory you're working with is a contiguous block. . . Much less guarantee that your code won't go out of the block assigned. 19:23:56 Have you implemented anything Turing-complete in BFM? 19:24:09 (Just to prove it's possible) 19:24:14 BFM? 19:25:21 BFM is distributed with brainfucktobfm. 19:26:13 It's *possible* for your itoa to work. . . It just wouldn't work *as a macro in BFM*, because the macros in BFM are supposed to be a bit. . . generalised. 19:45:56 That's going to make it very hard to do things efficiently. Because it pretty much means you can't use nondestructive flow control. 19:46:04 (in a macro) 19:47:05 What's divmod look like when turned into brainfuck? 19:49:25 -!- GregorR-W has changed nick to GregorR-L. 19:49:48 -!- GregorR-L has changed nick to GregorR-W. 20:45:00 -!- ihope has joined. 20:47:51 -!- jix has quit ("Bitte waehlen Sie eine Beerdigungnachricht"). 21:43:27 -!- Azstal has quit ("Chatzilla 0.9.72-rdmsoft [XULRunner 1.8.1b2/0000000000]"). 21:44:28 -!- ihope has quit ("http://tunes.org/~nef/logs/esoteric/06.08.09"). 21:56:59 -!- |wez| has joined. 22:36:00 dbc: 179 characters. 22:37:33 Although that can change depending on the relative placement of cells in memory. 22:58:26 171 now. 23:02:21 The latest divmod gives us a 24 character decrease in itoa size. 23:10:57 . . . Wow. Now, uncompress.bfm, when compiled, differs from uncompress.strip.b in 4 characters. . . Those 4 are part of a comment block in uncompress.strip.b. . . 23:12:18 Hahah 23:13:41 * SimonRC goes to bed. 23:18:27 -!- Sgeo has quit (Read error: 104 (Connection reset by peer)). 23:29:50 -!- tgwizard has quit ("Leaving"). 23:38:45 -!- Asztal has joined.