00:00:19 <oerjan> so then this method cannot be used, and any while can only be broken by fully zeroing its variable
00:01:45 <pikhq> 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 <oerjan> so SimonRC was right after all ;)
00:02:51 <pikhq> Handcoding in BFM, without using our generalised macros, can be just as efficient. ;)
00:03:29 <oerjan> i think the problem could be fixed using arrays, though
00:04:00 <pikhq> Have you *seen* the code necessary for an array implementation in Brainfuck?
00:04:17 <oerjan> if x and temp were parts of arrays of length 2, then there would be enough positioning
00:04:40 <oerjan> i don't mean unbounded arrays, just a positioned array of predeclared variables
00:05:02 <pikhq> That just defeats the idea of generalising the code.
00:06:54 <oerjan> not necessarily, the macro would just work on a slightly different structure
00:07:23 <oerjan> so in a sense it wouldn't be a booland for single cells at all, but it could still be useful
00:08:00 <oerjan> anyhow, i suppose the current booland is well enough for when you do have single cells
00:08:17 <pikhq> It's good at what it does. ;)
00:09:19 <oerjan> any array based implementation would need moving to work for single cells, which defeats the purpose of avoid the zeroing out
00:11:05 <oerjan> anyhow, i got derailed while trying to understand your mod code, back to that
00:12:37 <pikhq> Might want to change it over to the current BFM build once you figure out why it doesn't work.
00:21:52 <oerjan> hm, do you consider it necessary to zero out temp variables that aren't used?
00:24:09 <oerjan> (on second thought, my idea to avoid that in one macro depends on the copy macro doing precisely that
00:24:51 <pikhq> Temp variables are sort-of supposed to be used. . .
00:25:03 <pikhq> If it's unused, then don'
00:25:10 <pikhq> t take the variable as an argument.
00:25:53 <oerjan> what i mean is if the variable is sometimes used, but not always, like in divvar: temp1 and temp2
00:26:34 <oerjan> (if x is zero the while loop is never entered)
00:29:05 <pikhq> Yeah, one should clear your temp variables before running loops. . .
00:29:44 <pikhq> Allows one to assume any temp variables are 0 after a macro call. ;)
00:30:37 <oerjan> 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.
01:11:15 <ihope> Do I smell a Wiki admin?
01:11:30 <ihope> Or is that just a Grue?
01:12:20 <ihope> Now, through some careful experimentation, I have figured out how a pencil sharpener works.
01:12:34 <ihope> As you know, outlets contain electricity.
01:12:46 <ihope> And as you know, electricity is a liquid at room temperature.
01:13:43 -!- Arrogant has joined.
01:13:54 <ihope> 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 <ihope> Also, pencils emit a chemical known simply as "pencil",
01:14:34 * pikhq wants some of what ihope's smoking
01:14:37 <pikhq> Must be some good shit.
01:15:03 <ihope> How'd you guess what I was smoking?
01:15:58 <ihope> The PPS reacts with the pencil to form a new chemical called APS, or active pencil sharpener.
01:16:22 <ihope> This reaction also emits a sound best described as a loud sort of whirring.
01:17:09 <ihope> Finally, the APS reacts with the pencil itself, causing some of the wood to evaporate.
01:17:25 <ihope> It does so in such a way to make the pencil sharp, for obvious reasons.
01:18:22 <ihope> 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:12 * ihope suddenly remembers his homework
01:19:15 -!- ihope has quit ("http://tunes.org/~nef/logs/esoteric/06.08.09").
01:20:16 <oerjan> all these years of advanced education and no one is telling me this!
01:21:07 <oerjan> instead of vainly trying to satisfy my curiosity i could have followed my true dream and become a fire constable
01:24:40 * oerjan has satisfied himself that divvar works
01:25:08 <pikhq> I did the same much more simply.
01:25:26 <pikhq> I take it, though, that you're going through confirming that all of my macros are done well?
01:25:52 <pikhq> If so, let me just say that I greatly appreciate that.
01:25:57 <oerjan> just the pastebin left
01:26:26 <oerjan> well, not all, only those included by that
01:26:49 <oerjan> although i suspect divvar is among the most complex...
01:26:59 <pikhq> It is *the* most complex.
01:27:43 <pikhq> copy works very, very simply.
01:28:19 <pikhq> >[-]>[-]<<[>+>+<<-]>[-<+>] is the code in full.
01:29:11 <oerjan> btw, when you use both div and mod it might usually be a good idea to combine them
01:29:35 <pikhq> I was *trying* to get the macro to work at all in the first place.
01:33:14 <pikhq> I've confirmed one thing: the bug is in my mod macro.
01:33:31 <pikhq> Unless you wish to argue that 25 % 50=233, that is.
01:37:16 <fizzie> "For some values of %."
01:37:27 <oerjan> i have not analyzed it yet, but i have a sneaking feeling...
01:37:49 <oerjan> did you get the booland arguments in the right order?
01:37:56 <pikhq> oerjan: My "analysis" method is "call the macro with arguments which we know the appropriate result for". ;)
01:38:55 <oerjan> so the second argument is the result?
01:39:10 <oerjan> in the mod macro definition i mean
01:39:36 <pikhq> Um. . . No, the first one. . .
01:40:01 <pikhq> And booland stores the result in the first argument. . .
01:40:46 <pikhq> The only time booland touches the second one is to copy it into a temporary variable.
01:41:28 <pikhq> The BFM version I'm testing this one predates the standardisation of input, output, temp.
01:41:31 <oerjan> note that x is the _second_ argument.
01:42:10 <pikhq> I've yet to port to the new version the currently-existing code of mine beyond stdlib.
01:42:18 <pikhq> Task for class tomorrow.
01:48:26 <pikhq> You know, other people can feel free to chime in on the sheer insanity of this. . .
01:48:48 <oerjan> and then we'll beat them to a pulp. freely.
01:50:24 <pikhq> macro beattopulp {person pointer} {result} {temp} {comment {I've not finished this yet.};copy person > pointer : temp;move pointer > result}
02:02:18 <oerjan> Did subvar also previously take its result in the first argument?
02:04:37 <oerjan> add result 2 should be addvar result v2
02:11:41 <pikhq> How the *hell* did I mix that up?
02:12:40 <oerjan> no idea. now to see if i can extract mod from the divvar calculation simultaneously
02:13:08 <pikhq> Now, I've got a different question. . .
02:13:14 <pikhq> Why isn't itoa working now?
02:14:11 <pikhq> 25%50 *is* 25, right? :p
02:18:30 <oerjan> are the correct a1, a2, a3 calculated?
02:18:55 -!- GregorR-L has joined.
02:20:34 <oerjan> ah. mod doesn't preserve its second argument.
02:22:17 <pikhq> Well, there's the problem. :p
02:22:47 -!- Arrogant has quit (Read error: 110 (Connection timed out)).
02:27:53 <pikhq> It's also horribly large and inefficient, but hell; I'm happy.
02:28:42 <pikhq> Most of it's just large amounts of pointer movement, though. :/
02:32:35 <pikhq> Now, I assume you'd like the new source. . .
02:34:06 <pikhq> http://pikhq.nonlogic.org/itoa.bfm
02:34:08 <oerjan> btw the last divvar is redundant
02:34:50 <pikhq> 1847 characters. . .
02:34:57 <pikhq> That's one huge bit of code for itoa.
02:35:51 <oerjan> it should shorten a bit with a divmod macro
02:36:28 <pikhq> Even more if I just tidy up the usage of tmp vars in some places.
02:38:44 <oerjan> hm... in divvar, if you move the last subtract temp1 1 up a bit then you can delete the others
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 <oerjan> 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 <oerjan> and a set mod = 0 earlier. That should be enought to make it a divmod, i believe
02:48:58 <pikhq> And, of course, add mod to the args list? :p
02:49:31 <pikhq> Not seeing what you mean about moving the subtract temp1 1. . .
02:53:35 <pikhq> Surely 51/25=2 remainder 1?
02:53:42 <pikhq> 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:54:03 <pikhq> Cell 0 is y, cell 1 is x, cell 2 is mod. . .
02:55:45 <oerjan> is this the mod macro that seemed to work before?
02:56:46 <pikhq> Innermost while temp1. XD
02:57:51 <pikhq> Now we've got it saying 51%25=25, and 51/25=0.
02:58:52 <pikhq> 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 <oerjan> ok, take a look at http://home.nvg.org/~oerjan/divmodvar.bfm
03:00:04 <oerjan> i haven't tested it, though
03:00:22 <pikhq> Exactly what I've got.
03:01:18 <pikhq> The bug is in subvar.
03:02:42 <pikhq> Just did 10-5, not 5-10. XD
03:03:55 <oerjan> no, there is a bug in addvar
03:05:49 <pikhq> That didn't fix it, though.
03:06:11 <oerjan> however that cannot be the problem in divmod, because temp3 _is_ cleared. if you have exactly the same version as i
03:09:13 <pikhq> 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 <oerjan> and are you using the newest stdlib?
03:09:54 <pikhq> Otherwise, move x > temp wouldn't work.
03:10:26 <oerjan> wait. i just saw something.
03:13:10 <pikhq> Well, I found out *one* bit of the problem. . .
03:13:24 <pikhq> *Without* our changes, it doesn't seem to work.
03:13:52 <oerjan> you mean there is something wrong with divvar from the start?
03:14:43 <pikhq> Unless you argue that 25/51=0.
03:17:31 <oerjan> is the new input/output/temp separation working properly?
03:18:43 <pikhq> Hmm. Seems to work with divvar a > b : d e f g when a=5, b=11. . .
03:19:41 <pikhq> But. . . Not for anything else?!?
03:20:00 <pikhq> I'm going to give up.
03:20:48 <pikhq> . . . Hrm. Maybe I was giving it the wrong bloody arguments.
03:21:47 <pikhq> divvar a > b : d e f g does b/a, not a/b. XD
03:21:53 <pikhq> Now to test divmod.
03:22:17 * oerjan cannot stand the suspense
03:23:47 <graue> You know, if you guys used test-driven development, you would KNOW your code was going to work.
03:23:59 <graue> Silly 90s "good enough" programming techniques. Tsk.
03:24:58 <pikhq> We're coding in Brainfuck. We are therefore insane. . .
03:26:07 * oerjan prefers formal proof. in principle.
03:26:24 <dbc> Working on itoa?
03:27:19 <oerjan> sort of. itoa is working, but using separate div and mod macros
03:27:36 <oerjan> so now we have a divmod one.
03:28:20 <pikhq> Porting itoa to the new BFM. . .
03:28:33 <pikhq> And wondering how I broke stuff.
03:28:44 <oerjan> hm. i thought if an argument is both input and output then it counts as output, right? but bitnot isn't that way.
03:29:23 <oerjan> on the other hand it seems silly to say bitnot > x
03:30:01 <pikhq> Let me get itoa working first.
03:31:54 <oerjan> i think bitnot is buggy, too. subtract x 1 should be add x 1
03:32:12 <oerjan> because bitnot x = -1 - x
03:33:46 <oerjan> perhaps you meant boolnot
03:35:44 <pikhq> How should I call divmod in itoa, anyways?
03:36:02 <pikhq> divmod tmp > int a1 : tmp1 tmp2 tmp3 tmp4?
03:37:04 <pikhq> I've discovered a bug somewhere.
03:43:50 <pikhq> 1004 characters in itoa.b now.
03:44:16 <pikhq> Could shrink it down a good deal more if it weren't uberparanoid about cell clearing.
03:44:47 <pikhq> But hell; I'm not in the mood to complain.
03:46:59 <pikhq> New BFM up, with itoa.bfm and divmod.bfm in stdlib.
03:47:18 <oerjan> ideally you would want to keep a list of variables you knew were cleared...
03:48:03 <pikhq> 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 <oerjan> unless there was some declaration like at, for declaring which variables might have been touched
03:49:01 <dbc> 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 <dbc> I bet we can do better, but that's a start anyway.
03:50:32 <oerjan> heh. if you remove all instances of [-] from the output, what is its length then?
03:50:50 <dbc> I'll dig through a little more and see if anyone's improved on it further yet.
03:50:54 <dbc> 119 I think.
03:51:11 <pikhq> I'll check after I get it working without redundant cell clears.
03:51:17 <oerjan> i meant pikhq's version
03:52:57 <oerjan> it would be an indication how much of the size is due to that problem
03:56:32 -!- CXII has joined.
03:56:35 <oerjan> anyhow, time to go to bed
03:56:41 <dbc> Bertram Felgenhauer did it in 89.
03:56:42 -!- oerjan has quit ("ZZZZZZZZ").
03:58:59 <dbc> 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 <dbc> so I would think about taking that approach.
04:12:11 <pikhq> 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 <pikhq> Given the is0 directive, we get 752 characters.
04:15:06 <pikhq> We no longer need to feel guilty about excessive cell clearing. :)
04:20:19 <dbc> 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:26 <pikhq> Forgot set var 10 is also valid. XD
04:28:33 <pikhq> 770 characters (one tiny coding mistake).
04:31:41 -!- CXIII has joined.
04:34:05 <dbc> 87. Let me play with it more.
04:35:47 <pikhq> Hand it to me when you're done. . .
04:36:24 -!- CXIII has changed nick to CXI.
04:37:48 <dbc> 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 <dbc> Still fiddling with this. Have you got a better way to add 48 to a cell than ++++++[>++++++++<-]?
05:39:25 <dbc> I almost never use wrapping...wondering if it would save in this case.
05:40:02 <Eidolos> ++++++[>++++++++<-] is the minimum.
05:46:05 <dbc> 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 <dbc> 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 <Eidolos> Hmm, but that isn't portable.
05:59:08 <dbc> ...or better yet, +[+++++++++>[<<+>-[>>>>]<[[>+<-]>>>+>]<<-]<[-]-[<+>-----]>>[<+>>]<<]<[---.[-]<]
05:59:33 <dbc> Not entirely, no.
06:07:09 -!- anonfunc has joined.
06:07:15 <dbc> 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 <dbc> 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 <dbc> or one that tries to police absolute portability and purposely disallows negating a zero.
06:09:05 <dbc> ...but as this is for a project that assumes wrapping bytes, it should be fine.
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 <oerjan> 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:54:33 <pikhq> Be practically minded.
13:54:56 <pikhq> dbc: How many cells of memory does it use?
13:55:00 <oerjan> actually i meant that in a sort of backward way
13:55:19 <oerjan> unpractically minded, even
13:56:07 <pikhq> Not all the loops can be converted over to variables, and therefore it won't be made over into BFM. . .
13:56:38 <oerjan> the positioning trap again?
13:57:02 <pikhq> dbc: So, thanks, but we can't really use it. :'(
14:00:53 <oerjan> we could if we used array parameters...
14:03:09 <pikhq> On the bright side, we no longer get redundant cell clearing in our code. :)
14:08:06 <oerjan> how does the redundancy check work inside while loops?
14:11:32 <pikhq> 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 <oerjan> and at the beginning does it empty the list?
14:12:53 <pikhq> 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 <pikhq> No, the list is only emptied for right and left.
14:13:58 <oerjan> 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 <pikhq> Um, no. . . The list of cleared cells is global, not scope-dependant.
14:15:34 <oerjan> consider set x 0; while y { ... ; set x 1 }
14:15:47 <oerjan> inside ... you cannot assume x cleared
14:15:48 -!- jix has joined.
14:16:35 <pikhq> 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 <pikhq> We *can* assume x has been cleared, because nothing has touched it. ;)
14:17:10 <oerjan> wait a moment. let me clarify.
14:17:23 <oerjan> consider set x 0; while y { set x 0 ; ... ; set x 1 }
14:17:37 <oerjan> then the second set x 0 cannot be removed
14:18:42 <pikhq> 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 <oerjan> it cannot be removed the second time the while loop is run
14:20:50 <pikhq> Yeah, I can see how that could be a bug.
14:22:54 <pikhq> Perhaps add an "isnot0" command to be able to prod the compiler into compliance?
14:25:09 <oerjan> well, if we don't want to do a flow analysis ...
14:25:18 <oerjan> i think is0 is more useful
14:27:19 <oerjan> let's see. have a stack of cleared and touched lists.
14:28:00 <oerjan> at the beginning of a while, push new, empty ones. use the is0 directive to add cleared ones explicitly.
14:28:51 <oerjan> at the end of a while, merge the top two sets
14:30:43 <oerjan> at the end, a variable will be cleared if it was cleared before and not touched at the end inside
14:31:08 <oerjan> but touched if it was touched either before or at the end inside
14:32:35 <oerjan> if neither, then it will be on neither list
14:33:07 <oerjan> this should be a useful approximation without requiring backtracking
14:34:38 <oerjan> you could have an is0 list too, to check consistency
14:37:10 <oerjan> or you could do backtracking to move information back to the beginning of the while
14:37:24 <oerjan> then you could avoid is0
14:37:36 <oerjan> but it would of course be even more complicated
14:40:00 <oerjan> 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 <oerjan> the first pass would keep track of which while bodies clear and touch which variables
14:43:26 <oerjan> the second pass would use that to remove redundant clears
14:45:41 -!- lindi-_ has changed nick to lindi-.
14:46:05 <oerjan> but this solution would require some way of tracking code positions
14:47:59 <oerjan> 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 <oerjan> it suddenly occurred to me that redundant clearing is just a special case of redundant while loops.
15:22:31 <oerjan> 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 <SimonRC> ... and in other news, another looney nation has The Bomb: http://news.bbc.co.uk/1/hi/world/asia-pacific/6033457.stm
16:51:26 <RodgerTheGreat> 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:27:33 <pikhq> oerjan: The joys of having a second coder look at my code. :)
17:28:01 <pikhq> I'll probably implement one of those, and get a command line parser running, sometime this afternoon.
17:28:37 <pikhq> 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:45:28 <pikhq> For now, though, I'll just have is0 and isnot0.
17:49:57 -!- Sgeo has joined.
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 <dbc> So...hm. The problem is that that itoa can't be decomposed into BFM macros or something?
18:48:58 <pikhq> I've *got* an itoa in BFM; it's part of stdlib now.
18:49:11 <pikhq> The problem is that *yours* cannot be used with the variable system.
19:03:10 <dbc> Because it uses a variable amount of memor?
19:07:43 <dbc> (Note I said "that THAT itoa can't be decomposed", not "that no itoa can be decomposed")
19:10:35 <pikhq> 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 <dbc> Have you implemented anything Turing-complete in BFM?
19:24:09 <dbc> (Just to prove it's possible)
19:25:21 <pikhq> BFM is distributed with brainfucktobfm.
19:26:13 <pikhq> 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 <dbc> 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 <dbc> (in a macro)
19:47:05 <dbc> 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 <pikhq> dbc: 179 characters.
22:37:33 <pikhq> Although that can change depending on the relative placement of cells in memory.
23:02:21 <pikhq> The latest divmod gives us a 24 character decrease in itoa size.
23:10:57 <pikhq> . . . 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: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.