00:16:41 -!- angelic has left (?).
00:18:00 -!- calamari has quit (Read error: 60 (Operation timed out)).
02:14:20 -!- heatsink has joined.
03:34:20 -!- calamari has joined.
03:35:41 <calamari> haven't tried the optimizer, but it runs great on my plain bfi
03:36:32 <calamari> I think it's faster too, because it writes everything at once.. less disk time
03:36:55 <{^Raven^}> did you work out that possible bug?
03:37:07 <calamari> you were going to tell me about it then I got cut off
03:37:28 <{^Raven^}> might be a feature i've not noticed before
03:40:36 <{^Raven^}> if it doesn't fail due to a negative memory pointer, it leaves the pointer in the wrong place
03:40:43 <calamari> bfasm has better array code.. maybe I should just stick it in and see if it is fixed
03:41:23 <{^Raven^}> setting the array manually first works perfectly
03:47:04 <calamari> I'm going to try to make a simpler example
03:47:43 <{^Raven^}> it still should fail/go strange if you remove the imov(ctr)=1 from the for loop
03:49:20 <calamari> what fun: 1[-]2[e+o+*>+<2-]e[2+e-]*>[[>>]+[<<]>>-]+[>>]<[<[<<]>+1+*>[>>]<-]<[<<]>[>[>>]<+<[<<]>-]>[>>]<<[-<<]>
03:49:57 * calamari puts on his write-only hat and gets to it
03:50:42 * {^Raven^} checks and finds the same bug in 1.30 :(
03:51:45 <calamari> that means it's probably the bf code itself
03:52:31 <calamari> let me try that code on the new 1.40 just for the heck of it
03:52:45 -!- kipple has quit (Read error: 110 (Connection timed out)).
03:53:56 <calamari> have you tried it without the optimizing interpreter?
03:54:35 <{^Raven^}> gonna compile and test it with your bfi
03:55:45 <calamari> maybe just worked on 1.40 because the array got moved or something
03:56:19 <calamari> wow, code is half the size too.. hehe
03:57:21 <{^Raven^}> bfi (from bfasm 0.20) on both 1.30 and 1.40 generated code for error.bas gives 'Memory pointer error'
04:03:47 <calamari> I've reduced it to: DIM ctr:DIM iloc(13):DIM imov(9):iloc(12)=1:FOR ctr=0 TO 9:imov(ctr)=0:NEXT ctr
04:15:35 <{^Raven^}> DIM ctr:DIM iloc(12):DIM imov(1):iloc(12)=1:FOR ctr=0 TO 1:imov(ctr)=0:NEXT ctr
04:16:31 <{^Raven^}> if you DIM iloc(11):iloc(11)=1 it doesn't generate an error but i'm still not sure where the pointer ends up
04:16:48 <{^Raven^}> or if you set iloc(<10)=1 the same
04:17:49 <calamari> I'm almost 100% sure it's in the array code.. trying to decipher the bfasm code
04:21:52 <{^Raven^}> in the debug output for the above code, at the end of the line immediately before {FOR ...}
04:22:04 <calamari> I thought I had these mapped out someplace on my disk.. I don't see them.. maybe my mind really is that sick to write that code in place
04:22:11 <{^Raven^}> there is an extra < at the end, removing it fixes the code
04:26:52 <{^Raven^}> DIM ctr:DIM iloc(13):DIM imov(9):iloc(12)=1:FOR ctr=0 TO 9:imov(ctr)=20+ctr:NEXT ctr:PRINT imov(0):PRINT imov(1)
04:28:23 <{^Raven^}> changing the >-<< to >-< at the end of the code immediatey before the {FOR ...} fixes it and gives the expected results of imov(0)=20 and imov(1)=21
04:28:48 <{^Raven^}> which I think proves the pointer is in the right place
04:31:15 <{^Raven^}> bugger, that same code works fine in 1.40
04:31:48 <{^Raven^}> gonna go to bed before my head explodes
04:32:11 <calamari> thanks for finding the bug.. gonna keep at this bfasm code
05:25:48 <calamari> sto has been deciphered.. cool algorithm, if I do say so myself :)
05:54:39 -!- Tefad has joined.
05:54:59 <Tefad> i'm writing a brainfuck interpreter for fun
05:55:16 <Tefad> and i can't get one of the tests working : \
05:55:34 <heatsink> brainfuck is way popular here.
05:55:51 <Tefad> []++++++++++[>>+>+>++++++[<<+<+++>>>-]<<<<-] "A*$";?@![#>>+<<]>[>>]<<<<[>++<[-]]>.>. supposed to return H
05:55:57 <Tefad> mine returns I : \
05:56:16 -!- Frobozz has joined.
05:56:22 <heatsink> Have you stepped through the program?
05:57:52 <heatsink> what is the "A*$"; bit, anyway?
05:58:13 <Tefad> i'm guessing to foul some goofy interpreters
05:58:23 <Tefad> @ is supposed to be ignored
05:58:38 <Tefad> (or there wouldn't be any output eh?)
05:59:34 <heatsink> so... you can just pretend those chars are not there?
05:59:55 <Tefad> yup, only the eight tokens are valid
06:00:26 <Tefad> []++++++++++[>>+>+>++++++[<<+<+++>>>-]<<<<-] [>>+<<]>[>>]<<<<[>++<[-]]>.>.
06:00:39 <Tefad> i think the first [] are to screw with some interpreters, no?
06:01:06 <heatsink> it depends on whether mem is initialized to zero.
06:01:12 <heatsink> So you didn't write this bit of code?
06:01:43 <heatsink> Then you did write this bit of code.
06:02:34 * Tefad stabs Frobozz with a pink elephant.
06:02:47 * Frobozz smacks Tefad over the head with a dictionary
06:04:53 <Tefad> the test is entitled "Tests for several obscure problems."
06:05:31 <Tefad> my interpreter isn't 100% yet anyway
06:05:38 <heatsink> Have you tested the operators individually?
06:06:00 <Tefad> i've done constant number generation
06:06:07 <Tefad> i've done read input, spitback output
06:07:25 <Tefad> i think it doesn't like nested loops
06:07:30 <Tefad> grrrr i thought i fixed that once
06:07:49 <Tefad> i'm using a stack for those
06:10:57 <Tefad> i think i'm erring with pointer artihmetic.. bah
06:14:36 -!- heatsink has quit ("Leaving").
06:20:17 -!- Frobozz has quit ("Leaving").
06:37:25 <calamari> yes! the new array code shaved 10k off raven's game :)
07:32:35 -!- calamari has quit (Read error: 60 (Operation timed out)).
07:57:36 -!- Tefad has quit ("brb").
07:58:28 -!- Tefad has joined.
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
10:22:13 -!- kipple has joined.
11:40:49 -!- kipple has quit.
11:56:27 -!- kipple has joined.
16:01:18 -!- Tefad has quit (Read error: 110 (Connection timed out)).
20:34:06 -!- Keymaker has joined.
20:34:36 <Keymaker> i'm bringing some good news before going to sleep;
20:34:48 <Keymaker> the Logical Brainfuck Competition has started!
20:34:51 <Keymaker> http://sourceforge.net/forum/forum.php?thread_id=1249789&forum_id=201037
20:35:01 <Keymaker> everyone is welcome and good luck! :)
20:37:09 <arke> can you give me an example of a valid expression?
20:37:38 <Keymaker> (followed by a new-line in this competition)
20:38:02 <arke> so what about 44~,55^
20:38:03 <Keymaker> read the rules-planning topic :)
20:38:04 <arke> would that work?
20:38:22 <Keymaker> it will be said in the rules that that isn't valid
20:38:46 <arke> Oh, ~ takes the place of the comma
20:38:59 <arke> 44~55~^ is valid?
20:39:32 <Keymaker> comma can be used only and if there is a digit on both sides of the comma, for example like in "0,0"
20:39:39 <arke> As is, say, 44~55^66&
20:40:29 <Keymaker> but anyways, i'll need to go now; be sure to read the rules topic carefully (and check the rules planning topic as well) :)
20:40:31 <arke> I need to learn how to do less-than comparisons in BF
20:40:37 <arke> Ok, will do :)
20:40:46 -!- Keymaker has quit.
22:30:43 -!- calamari has joined.
22:47:17 <calamari> hi raven.. did you keep a backup copy?
22:47:36 <calamari> ok good, I'll keep working then :)
22:47:51 <calamari> wasn't sure if the update left you broken
22:48:13 <calamari> looking into the var=# and var=var stuff
22:48:44 <calamari> var=var because right now I think it's doing t0=var1, var2=t0
22:49:28 <calamari> also not sure about how I'm doing the add-to loops
22:50:12 <calamari> if I can avoid add-to loops I'll make them an optimization level (as I've done with the variable reordering, although -O2 is default)
22:50:57 <{^Raven^}> optimising var=var ane var=# will be a major improvement
22:51:51 <{^Raven^}> did you track down that array bug?
22:52:23 <calamari> lol, that was easy to understand... add-to loops are way broken.. does high/low hex nibbles
22:52:42 <calamari> I didn't track down the bug.. but the new array code is smaller and didn't crash
23:42:37 <arke> I know how I'm gonna do this
23:42:39 <arke> I'm gonna write it in Forth
23:42:43 <arke> then I'm gonna change to eliminate all return stack tricks
23:42:43 <arke> then I'm gonna change to eliminate all VARIABLEs
23:42:44 <arke> then I can translate it one-to-one
23:42:56 <arke> And then go over it optimizing