00:03:56 -!- BigZaphod has joined.
00:12:50 -!- wooby has quit.
00:30:11 -!- kipple___ has joined.
00:30:12 -!- kipple__ has quit (Read error: 104 (Connection reset by peer)).
01:41:11 -!- jix has quit ("Bitte waehlen Sie eine Beerdigungnachricht").
01:53:36 -!- graue has joined.
02:24:42 <GregorR> Before I continue this ...
02:24:47 <GregorR> Has anybody written checkers in BF?
02:28:14 <graue> I'd been thinking about implementing Nim or something
02:33:14 -!- kipple___ has quit (Read error: 60 (Operation timed out)).
03:05:28 -!- calamari has joined.
04:48:25 <GregorR> Is it cheating to write BF with a C preprocessor?
04:49:10 <calamari> do you feel like it's cheating?
04:50:29 <graue> that sounds like fun
04:50:39 <graue> what sorts of macros do you use?
05:15:37 -!- heatsink has quit ("Leaving").
05:16:45 <GregorR> I don't feel like it's cheating.
05:17:00 <GregorR> It's just a quick way to type 100s of BF commands.
05:17:47 <GregorR> /** MBF_DUP: b = a; c = 0 */
05:17:49 <GregorR> /** MBF_MULT: a = a * b; c, d, e = 0 */
05:17:51 <GregorR> /** MBF_DIV: a = a / b; b, c, d, e, f, g, h = 0 */
05:17:53 <GregorR> /** MBF_CLS: clear the screen; a, b, c, d strange values */
05:19:32 <graue> I guess the actual implementation is a trade secret, eh?
05:38:43 <GregorR> But first I have to package it in a modestly non-sucky way 8-D
05:38:58 <GregorR> What's the BEST BF interpreter out there?
05:39:48 <graue> qdb and yabfi2 have hardcoded limits of how many tape cells they can use
05:39:57 <graue> if you don't need a lot of code or tape cells, use qdb
05:43:52 <graue> I don't know, look at the source code?
05:44:12 <graue> something along the lines of 30000, you can always change it of course
05:49:36 <GregorR> Well, 30000 should be fine *shrugs*
05:51:20 <graue> I don't really know of a fast/decent interpreter with no hardcoded limits
05:51:27 <graue> 30000 has been insufficient for some things I wanted to do
05:51:29 <GregorR> I guess I'll have to write one.
05:59:13 <calamari> GregorR: might I suggest precalculation of [ and ] ? :)
06:00:05 <GregorR> calamari: I'll consider it as a to-be-implemented :)
06:00:23 <calamari> [ and ] precalculation helps a lot.. try it :)
06:01:46 <GregorR> Oh of course - I thought you meant something else.
06:02:44 <calamari> it seems that the best is almost a mini compilation phase at the beginning before interpretation
06:08:46 <GregorR> Is it agreed that there's no call for memory expanding /below/ 0?
06:10:27 <graue> although I've seen one implementation, that allowed memory expanding below 0, which then permitted it to remove any > and < instructions at the beginning of the code
06:10:40 <graue> I'm not sure if that is an effective way to actually speed anything up
06:11:00 <graue> (probably not, in general)
06:11:09 <GregorR> Those ops are so quick, it's really pretty irrelevent *shrugs*
06:11:19 <graue> on the other hand, that implementation then didn't have to check for memory underflow all the time
06:11:26 <graue> the interpreter shouldn't crash on invalid programs
06:11:31 <calamari> probably not, as >'s and <'s should be pre-combined anyways
06:11:54 <calamari> of course, sometimes this allows bad programs to not crash
06:11:55 <graue> in fact any chunk of code containing only ><+- can be optimized quite a bit
06:13:14 <calamari> not for use in contest judging :)
06:23:47 <GregorR> Loops are now matched (in a very memory-inefficient way I'm afraid to admit)
06:25:21 <calamari> nah, no need, could just hardcode into the source :)
06:25:33 <GregorR> But it's also the table used to shorten >><<<<>, etc.
06:26:46 <calamari> shouldn't listen to me, since I haven't written the ultimate bf interpreter, hehe
06:38:39 <graue> you, a few weeks from now when you release version 1.0?
06:38:50 <GregorR> A few weeks? I'm insulted!
06:41:06 <graue> sorry, in a few years
06:41:18 <graue> I should have known you would never rush and that quality was paramount to you
06:53:45 -!- calamari has quit (Read error: 110 (Connection timed out)).
06:57:58 -!- calamari has joined.
07:03:15 <GregorR> *((((bytewidth == 1 : int8_t ? (bytewidth == 2 : int16_t ? int32_t))) (mem + ((mptr) * bytewidth)))) += loops[pptr];
07:03:49 <graue> does it have to be obfuscated just because it's a brainfuck interpreter?
07:04:26 <GregorR> That's actually the result of macros.
07:04:34 <GregorR> It reads as *(MEM(x)) = loops[pptr];
07:04:48 <graue> I thought the programs had macros, not the interpreter
07:04:48 <GregorR> The MEM macro decides what sort of memory it's looking at.
07:05:13 <graue> well, your ?s and :s are reversed
07:05:36 <calamari> hopefully it only executes this once?
07:06:05 <GregorR> graue: Yeah, I noticed that XD
07:06:41 <GregorR> Maybe I just need to compile three interpreters with different #defines and make a frontend.
07:06:46 <GregorR> Because that's anything but optimal.
07:07:24 <graue> make the entire interpreter a macro
07:08:00 <graue> then you can do like "if (bytewidth == 1) INTERPRETER(int8_t) else if (bytewidth == 2) INTERPRETER(int16_t)" etc
07:08:58 <graue> or, like you suggest, just make an interpreter generator
07:09:06 <graue> you could also have disable/enable wraparound, etc
07:09:21 -!- graue has quit ("Donate a manual typewriter to ME for your only hope for a future!").
07:27:14 <GregorR> Hmm, has problems with 32-bit mode.
07:36:47 <GregorR> Hmm, don't know if I want that to be modifiable ...
07:53:01 <GregorR> Why yes, this is the greatest BrainFuck interpreter ever.
07:53:09 <GregorR> What's that you say? Gregor is a genius?
07:54:27 <calamari> somebody needs to write a bf benchmark program so that you may be humbled :)
07:56:06 <GregorR> What's a completely insane BF program? Way to huge to make any sense.
07:57:05 <calamari> bfasm is decently large as well
07:57:36 <GregorR> Do you know if either need 16-bit or whatnot?
07:58:26 <GregorR> Time to release this puppy.
07:59:02 <GregorR> Hmm, I totally don't understand this Fibonacci sequence generator ...
07:59:22 <GregorR> Either it's somehow stepping outside the bounds of a character, or it's not putting newlines :P
07:59:59 <calamari> hmm, thought I had that program, guess not
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:00:16 <GregorR> If it's somehow stepping outside the bounds of a character and is generating properly, then I just generated:
08:00:21 <GregorR> 7636483426752859626568727941453421836579500747253199097397446751252205298917387147222157525691120044675551183747012174982350831180624465225615183372232707575199695298398336853131650061131214645112476911067502428593554795489700530669981992898898397
08:00:39 <calamari> somehow that seems unlikely even for non bf
08:00:58 <GregorR> I'm not sure what it's doing *shrugs*
08:03:56 <calamari> http://esoteric.sange.fi/brainfuck/bf-source/prog/PRIME.BF
08:10:25 <GregorR> Right now I'm working in the 100 range :P
08:14:46 <GregorR> Even though the OPTION set provided by GKRBFI is far better, QDB is inexplicably beating it in times.
08:15:20 <calamari> suggestion: rename to something else :)
08:17:25 <GregorR> So I have to use them all :P
08:19:27 <GregorR> When I take off counting of <>>>>><, the time drops dramatically.
08:19:58 <calamari> so it's faster not to optimize <> ?
08:20:28 <GregorR> Merely because of the time taken in doing all the counting, and then having to reference that count in some array.
08:20:51 <GregorR> I'm sure if something had 1000 +s in a row it'd be better, but not for an average program :P
08:21:20 <lament> those things should just be optimized in source code :)
08:23:23 <GregorR> I'm experimentally trying without [] mapping
08:24:45 <GregorR> Amazingly, that did worse :P
08:25:32 <GregorR> And now I have no idea what the slowdown is >:(
08:27:07 <GregorR> Ohhhhhhhhh, I see how QDB cheats.
08:28:13 <GregorR> They not only cached it, but left the cached value in the program itself, rather than the program referencing it somewhere else.
08:29:08 <calamari> that's how I was suggesting to do it before :)
08:30:01 <calamari> at least if I understand what you said.. hehe
08:31:08 <calamari> I'd make a new program like +(int) [(addr) etc
08:32:23 <calamari> or even better.. compile to machine code and call subroutine ;)
08:49:19 <GregorR> Is there somebody here who can upload this to esolangs.org?
08:51:30 <GregorR> WTF is with this Fibonacci generator >_O
08:53:09 <GregorR> A loooooooooooooooooooooong time.
08:58:26 <GregorR> http://gregorr.homelinux.org/egobfi-0.1.tar.bz2
09:37:50 <calamari> ok.. too tired :) good job Gregor
09:37:53 -!- calamari has quit ("Leaving").
09:45:26 <GregorR> OK, 0.1 had a horribly broken debugger.
09:45:29 <GregorR> http://gregorr.homelinux.org/egobfi-0.2.tar.bz2
09:46:22 -!- {^Raven^} has quit (Read error: 60 (Operation timed out)).
10:47:03 -!- kipple___ has joined.
11:17:13 -!- {^Raven^} has joined.
11:51:21 -!- fizzie2 has joined.
11:52:13 -!- fizzie has quit (Nick collision from services.).
11:52:22 -!- fizzie2 has changed nick to fizzie.
11:53:10 <fizzie> Apparently the cat in the place this box (sesefras) is temporarily-located had managed to detach the power cable from the switch.
11:54:40 -!- ineiros_ has joined.
11:57:23 <fizzie> Blame him ^ (ineiros), it's his cat.
12:03:28 -!- ineiros has quit (Read error: 111 (Connection refused)).
12:10:25 -!- jix has joined.
12:46:44 <pgimeno> http://www.formauri.es/personal/pgimeno/prog/esoteric/mandel-bench.txt
12:49:27 <pgimeno> are there other interpreters worth adding to the benchmark?
12:51:46 <{^Raven^}> bftools by Erok Bosman would be a good addition
12:52:22 <jix> pgimeno: i'm going to write one
12:52:49 <pgimeno> oh, how come it's not in the BF page?
12:53:24 <jix> did you tried obi2.rb ?
12:53:37 <jix> http://esolangs.org/files/brainfuck/impl/obi2.rb
12:53:40 <jix> it's a ruby script
12:54:36 <jix> i think it's slow but maybe as fast as possible with ruby
12:54:50 <{^Raven^}> pgimeno: Erik Bosman's 'terp is at http://jonripley.com/~jon/bftools.zip if you haven't got it already
12:55:11 <jix> because it converts the brainfuck code in ruby code and then evals it
12:55:18 <pgimeno> {^Raven^}: I didn't, thanks
12:56:02 <pgimeno> optimizing interpreters are often faster than non-optimizing compilers
12:56:02 <jix> [-] nothing more
12:56:18 <jix> ok it would be possible to optimize more thing
12:56:24 <jix> but it wouldn't fit into that shape^^
12:58:45 <pgimeno> jix: sorry but outputting *the first line* already takes almost 45 secs
12:59:16 <pgimeno> I'm not going to let it complete the shape; my computer has severe temperature problems
13:00:15 <jix> i have 22 C
13:01:25 <jix> 16 C outside
13:03:27 <jix> 16 C is normal upto 25 C is warm >25 C is hot
13:05:34 <pgimeno> the result with bftools is very very similar to the one with brfd
13:07:10 <pgimeno> I'm impressed with bff though; it's just a 3x slowdown wrt the natively compiled version
13:08:57 <pgimeno> http://www.iwriteiam.nl/Ha_bf_online.html does not compile it
13:10:04 <pgimeno> I'm going to try http://bf2c.sf.net/
13:10:32 <pgimeno> unfortunately that also depends on the C compiler's optimization abilities
13:11:00 <jix> but it's portable
13:11:11 <jix> i can't try awib because i don't have a running x86 machine
13:12:19 <pgimeno> yeah, I know that's a caveat of awib but anyway I wanted to include it in the benchmark for reference
13:14:23 <{^Raven^}> pgimeno: there's bfbasc demo program for BFBASIC that compiles to unoptimised x86
13:15:47 <jix> ./bff mandelbrot.b ... waited 1 minute .. no output .. killed?
13:19:28 <jix> with obi2.rb it works here too
13:19:43 <pgimeno> {^Raven^}: I will consider it but I don't want to spend much time with this
13:20:37 <{^Raven^}> pgimeno: i reckon just the main contenders will be most useful to have
13:21:59 <pgimeno> jix: maybe bff is endianess-sensible or something?
13:27:52 <jix> i'm going to write a really fast bfi
13:29:02 <pgimeno> IMNSHO brfd has one of the best BF debuggers around
13:29:49 <pgimeno> too bad it doesn't debug C programs... gdb sucks
13:30:23 <jix> gdb is good enough to debug binaries without source code
13:31:10 -!- jix has left (?).
13:32:44 * pgimeno now laments to have put so much effort in past in learning usage of DOS tools
13:39:18 <lindi-> pgimeno: what's wrong with gdb?
13:39:51 <pgimeno> commands are too complex to learn
13:40:13 -!- jix has joined.
13:40:17 <jix> oops wrong key
13:42:22 <lindi-> pgimeno: oh, "run, break, continue, backtrace, print" is what i usually need, those are very logically named imho :/
13:42:33 <pgimeno> I tend to forget them from one time to another; I always have to read some docs
13:43:10 <lindi-> pgimeno: use ddd if you want to use menus and mouse
13:43:38 <lindi-> pgimeno: how should they be named so that you'd remember? ;)
13:43:44 <pgimeno> I usually need "info registers", "disassemble", "info target", single step...
13:45:00 <pgimeno> well, I was quite comfortable with single-letter commands
13:46:50 <lindi-> pgimeno: i hope you have noticed that you can use "r", "b", "c", "bt", "s" and "si" ;)
13:48:14 <pgimeno> the bad point is that it's not intuitive enough for me, I have to check docs often
13:48:27 <fizzie> You could also use "define" in .gdbinit to customize/intuitivize your gdb.
13:48:56 <pgimeno> being a mixed assembler/HLL debugger makes it harder to use, e.g. using $ for registers
13:49:37 <pgimeno> I'd prefer to have a dedicated low-level debugger
13:49:42 <pgimeno> anyway that's probably just me
13:50:52 <jix> but gdb has objective-c support
13:51:13 <jix> and objective-c always stores symbol names because it uses a somewhat dynamic calling
13:51:55 <jix> and all binary objective-c programs have symbols included.. it helps fixing some things
13:54:08 <jix> some programs always display warning messages "Do you really want to do this"... "really?" .. some little changes an whoops no annoying warnings
14:33:37 -!- yrz\werk has quit (Read error: 60 (Operation timed out)).
14:36:21 -!- yrz\werk has joined.
16:01:24 -!- Aardwolf has joined.
16:22:43 <jix> pgimeno: what's your mandelbrot test machine?
16:24:55 <jix> i wrote a new bf interpreter
16:25:14 <jix> and on my g4-1ghz ppc machine it takes 1:11 for mandelbrot.b
16:25:55 <jix> it has NO error checking and i'm not sure if it frees everything ^^ but it has growable memory
16:26:23 <jix> i'm uploading it
16:26:40 <jix> please test it.. i want to compare it with other interpreters
16:27:21 <jix> http://www.harderweb.de/jix/langs/brainfuck/afbi.c
16:27:40 <jix> compile with -O3
16:30:25 <pgimeno> even if I give no parameters
16:30:41 <jix> with no parameters it's normal
16:30:53 <jix> there has to be 1 parameter
16:31:27 <jix> hmm what's your gcc version?
16:31:41 <pgimeno> gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
16:32:02 <jix> i compiled it with gcc version 3.3 20030304 (Apple Computer, Inc. build 1809)
16:32:44 <jix> gcc version 4.0.0 20041026 (Apple Computer, Inc. build 4061)
16:34:05 <jix> any compile warnigns?
16:34:20 <pgimeno> I activated none; other than that no
16:35:28 <fizzie> Where's this mandelbrot.b?
16:35:30 <pgimeno> ddd says the segfault happens in line 152: goto *(ins[ci.instruction]);
16:35:42 <fizzie> Ooh, a computed goto. :)
16:35:44 <jix> fizzie: esolangs.org/files/brainfuck/src (guessed)
16:36:03 <jix> pgimeno: hmm ok
16:36:56 <fizzie> It segfaults on my x86 box too.
16:36:59 <jix> it jumps into the dark side of memmory.. oh nooo
16:37:01 <fizzie> But doesn't on my ppc box.
16:38:24 <jix> fizzie: pgimeno: what's the content of program[program_p].instruction at the segfault?
16:38:32 <jix> pgimeno: no gcc computes the values i jump to
16:38:48 <jix> and i don't use unions
16:38:58 <jix> and i don't cast values with different size
16:39:08 <pgimeno> (gdb) print program[program_p].instruction
16:40:05 <fizzie> (gdb) print program[program_p].instruction
16:42:06 <jix> fizzie: mandelbrot.b ?
16:42:17 <fizzie> It's 0, 0 here too when compiled with "-g -O3"
16:42:20 <jix> 3291 shouldn't be exit
16:42:28 <pgimeno> jix: do you realze that the file is 12000 instructions long?
16:42:31 <fizzie> And 7, 3291 when compiled with just a "-g".
16:42:35 <jix> pgimeno: yes
16:42:50 <jix> there something odd with the computed gotos
16:44:12 <fizzie> Incidentally, it takes 1:24 to run mandelbrot.b on this 1GHz g4 iBook (compiled with gcc "3.3 20030304 (Apple Computer, Inc. build 1495)"), which is admittedly doing some other things too.
16:45:30 <jix> it took 1:11 on my 1ghz g4 so that sounds ok
16:46:14 <pgimeno> jix: program_s = 4000 here, if that helps
16:47:10 <jix> should be... 16000
16:47:19 <jix> sizeof(bfi)*1000
16:47:26 <fizzie> ci.instruction is "65541" when it crashes on that goto statement.
16:47:31 <fizzie> That's probably not right.
16:48:19 <jix> i changed something
16:48:23 <jix> program_s is ok
16:49:55 <fizzie> Shouldn't "tmp" be > "program"? When it crashes, it's program-1011 here.
16:50:24 <fizzie> $2 = (bfi *) 0x804a260
16:50:24 <fizzie> $3 = (bfi *) 0x804e190
16:50:40 <jix> hmm something went wrong
16:50:50 <fizzie> Maybe I should try single-stepping when it starts interpreting it.
16:51:18 <jix> it has something to do with the loop instructions
16:51:50 <jix> line 183 & 187 set tmp
16:53:01 <jix> maybe the parser writes the wrong addresses into the memory
16:54:46 <pgimeno> ((bfi*)(tmp->arg_c))->arg_c=(void*)tmp;
16:55:11 <jix> where's the problem
16:55:19 <jix> it's bad c-style
16:55:40 <jix> arg_c is void*
16:55:47 <jix> arg_a and arg_b are int
16:56:13 <fizzie> Well, converting between void* and bfi* shouldn't be a problem.
16:56:27 <jix> arg_c should be bfi* but i forgot how to do linked-list declarations
16:56:47 <pgimeno> I objected just because I thought it was int; I was wrong
16:57:34 <fizzie> typedef struct bfi_s { ...; struct bfi_s * arg_c; } bfi;
16:57:53 <pgimeno> anyway where is it initialized?
16:58:30 <jix> pgimeno: what?
16:58:46 <pgimeno> where is tmp->arg_c initialized?
16:58:52 <fizzie> Afaict the terminating ']' of the loop sets it properly.
16:59:00 <fizzie> For "both ends" of the loop.
16:59:18 <pgimeno> oh, in the previous instruction :)
16:59:44 <jix> my c-code is always chaotic as hell
16:59:55 <jix> i never really learned c
17:00:16 <fizzie> I'd point at my befunge interpreter for a prime example of chaotic C, but befunge.org's down at the moment.
17:01:01 <jix> take a look at my c kipple interpreter (cipple) i re-aranged functions because i was to lazy to write function prototypes
17:03:06 <pgimeno> I'm used to not using prototypes (I'm a quiche-eater)
17:03:22 <jix> but some recursive functions need prototypes
17:03:41 * yrz\werk frank zappa - tengo una minchia tanta
17:03:41 <jix> with computed gotos it should be possible to avoid that
17:04:10 <pgimeno> things need to get really really complicated for them to be really necessary
17:04:26 <jix> a calls b and b calls a
17:05:09 <pgimeno> I usually write b inside a in such cases
17:05:23 <jix> hmm.. i too
17:05:49 <fizzie> Engfeh. gdb's single-stepping gets sorta-confused when the program's compiled with "-g -O3".
17:06:22 <pgimeno> yeah, -O0 is needed for reliable traces
17:06:43 <fizzie> Since it segfaults with that too, I guess I'll look at it unoptimized.
17:11:24 <fizzie> I have an idea of one way it might bug.
17:12:07 <fizzie> if realloc() moves the "program" to some different address when reallocating, the addresses in the "loopstack" get invalidated.
17:13:05 <pgimeno> I was examining the value of loopstack right now
17:14:59 <jix> ok i'm going to fix that
17:15:01 <pgimeno> but on segfault: (gdb) print program
17:15:59 <fizzie> You could keep offsets from start-of-program in arg_c too, since the values in those fields get invalidated too, when "program" is moved.
17:17:32 <pgimeno> it probably segfaults on x86 because the page is freed
17:20:57 <jix> while parsing i keep relative offsets
17:21:11 <jix> if i'm done with parsing i convert them into absolute addresses for speed
17:23:12 <jix> i did some speed improvements too
17:25:42 <fizzie> If you want a speed improvement, you might consider adopting the same "one jump per instruction" strategy I did with my befunge interp: make a macro like "#define NEXT tmp++;ci=*tmp;goto *(ins[ci.instruction])", and put that after every instruction instead of "goto lend".
17:26:41 <fizzie> Not that I'd have benchmarked it to see if it has any _real_ effect, but "it just might".
17:28:11 <jix> 5secs faster!
17:28:36 <jix> does it work on x86 now?
17:28:54 <fizzie> fis@sesefras:~$ ./afbi mandelbrot.b fis@sesefras:~$
17:29:02 <fizzie> Err, that's a broken copypaste.
17:29:12 <fizzie> fis@sesefras:~$ ./afbi mandelbrot.b
17:29:24 <fizzie> It prints out 8 spaces, it seems. :p
17:29:38 <jix> better than segfault
17:30:09 <jix> if i set program start size low i have the same bug
17:30:31 <fizzie> Hmnnhm. Might still have something to do with the reallocations, then.
17:30:54 <pgimeno> jix: is it on the same location?
17:31:53 <fizzie> That's where I wget'd from.
17:31:58 <fizzie> And it looks updated to me.
17:34:23 <jix> pgimeno: yes
17:36:31 <jix> i don't know why it doesn't work
17:36:50 <jix> i write a bf2c converter thats easier
17:37:58 <jix> not only bf2c but bf2*
17:38:48 <fizzie> I have a (quite unoptimized) bf2befunge thing, but befunge's not very mainstream language either.
17:39:17 <jix> ok bf2high-level-language
17:55:58 <pgimeno> jix: *mem_p == 1 at start of program
17:58:31 <pgimeno> seems you forgot to zero it out
18:06:35 * pgimeno waits until the computer cools out
18:07:13 <jix> i had no temperature problems at 35 C
18:07:58 <jix> my old 68k (motorola 680x0) mac had problems at ~40 C but my computer hadn't
18:08:59 <jix> and i don't have a cpu fan
18:10:27 <pgimeno> my case is really annoying; I have them since I bought this box
18:10:58 <jix> i wish my computer had a cpu fan.. passive cooling is LOUD
18:11:09 <pgimeno> see http://www.formauri.es/personal/pgimeno/temp/dsc02325.jpg
18:11:34 <pgimeno> that's my box and my auxiliary fan
18:11:40 <jix> the hard-disk
18:12:09 <pgimeno> yeah, that one is cooled at the same time
18:12:43 <pgimeno> time afbi-0.1/afbi mandelbrot.bf
18:13:13 <jix> my computer can't be that fast
18:13:42 <pgimeno> tried brfd? it's very ANSIish
18:13:52 <pgimeno> oh, the optimizer is not released
18:14:38 <pgimeno> http://www.formauri.es/personal/pgimeno/files/compurec/brfd101.zip
18:15:34 <pgimeno> then replace run.c with this:
18:15:42 <pgimeno> http://www.formauri.es/personal/pgimeno/temp/run.c
18:21:16 <jix> oceanic:~/Desktop/Downloads/brfd101 jannis$ time ./brfd ~/Desktop/mandelbrot.b
18:21:22 <jix> real 2m7.937s
18:21:22 <jix> user 1m34.170s
18:21:22 <jix> sys 0m0.779s
18:21:30 <jix> on my computer my interpreter is faster
18:21:55 <pgimeno> I expected that for some reason
18:22:02 <lindi-> hmm, maybe i should write brainf*ck interpreter too
18:22:23 <jix> pgimeno: but i didn't any ppc specific optimizations
18:22:59 <jix> wait for my bf2c ...
18:23:03 <pgimeno> I'd guess that the reason is indirect jumps being too expensive in x86
18:23:09 <jix> but first i have to eat something
18:23:28 <jix> ppc is faster with precomputed jumps too
18:23:32 <pgimeno> I'm looking forward to see it; I'm sure it will be faster
18:24:06 <jix> but comparing a int with 7 other ints is always slower than branching/jumping to an computed address
18:27:33 <pgimeno> the comparisons may take 1 cycle each; OTOH indirect jumps can't be predicted and the pipeline is useless
18:33:19 <lindi-> jix: you know if anybody has made a benchmark of all published bf interpreters/compilers?
18:50:18 <jix> pgimeno: but after each comparison it has to jump to the code
18:50:21 <jix> lindi-: no
18:50:39 <lindi-> would be interesting to see one
18:51:35 <jix> i have a 300mhz celeron computer (without os atm) could be a testbox
18:52:23 <lindi-> maybe i'll write a benchmark script
18:53:31 <jix> uh where is the key for the computer?
18:53:35 <fizzie> With linux one can use sched_setscheduler to grant rather exclusive priorities to the test-task. (If one does not care that the computer then won't be doing much (anything) else during the test.)
18:53:44 <lindi-> yeah, why not. it just needs to invoke different interpreters with different programs
18:54:01 <jix> fizzie: i don't use the computer for enything else
18:54:05 <jix> lindi-: yes a real-life key
18:54:18 <lindi-> i'm not sure what you are talking about :/
18:54:48 <fizzie> Normal linux distributions have a lot of tasks running anyway, and even nice -20'd processes only get their share of cpu time.
18:54:57 <jix> it's in a (shortened) server box with a little door at the front with a lock in it
18:56:19 <fizzie> I have a SGI Indy (MIPS, running IRIX) and a Sun Sparcstation 5 (microsparc, with OpenBSD installed) if you want platform-specific benchmark results. Although the SGI box lacks a C compiler.
18:57:27 <jix> fizzie: is there an tutorial for running a process while stopping all other
18:59:06 <jix> lindi-: i'm talking about a key for http://www.harderweb.de/jix/lock.jpg
18:59:38 <fizzie> I haven't seen one. But with linux it's quite easy: struct sched_param sp; sp.sched_priority = 42; sched_setscheduler(0, SCHED_FIFO, &sp);
19:00:19 -!- calamari has joined.
19:00:27 <fizzie> It has an added-value feature of making an infinite loop a serious condition, since any other processes will never be run.
19:00:33 <jix> i could write a luncher for it (first setting priority than exec'ing into the other process)
19:01:40 <fizzie> scheduling parameters are inherited by fork(), so you could just grant a higher priority to the shell running the test script.
19:02:01 <fizzie> The shell process probably wouldn't have too much interference.
19:02:02 <jix> fizzie: than the shell and the process have high priority
19:02:38 <jix> fizzie: if a program enters an infinite loop and i use the code you posted is it possible to exit the program?
19:03:05 <fizzie> Unless you have a higher-priority task that can kill it.
19:03:25 <jix> if the shell has same priority.. can i kill it using ctrl-c?
19:03:26 <fizzie> "As a non-blocking end-less loop in a process scheduled under SCHED_FIFO or SCHED_RR will block all processes with lower priority forever, a software developer should always keep available on the console a shell scheduled under a higher static priority than the tested application."
19:04:01 <fizzie> From the man page of sched_setscheduler.
19:04:14 <jix> the lock is screwdriver safe!
19:04:41 <jix> the box has a hole at the back but is safe at the front...
19:05:17 <fizzie> Then there's the matter of timing... on linux, gettimeofday() is a relatively precise, but you want the time samples taken as close as possible before and after the task startup/termination. Optimally you could modify the interpreter sources so that whatever delay is introduced by wait()ing on the process won't matter.
19:06:52 <jix> i don't think i need that exact timing
19:07:11 <jix> the first thing i need is that stupid key!
19:08:05 <fizzie> Depends on how long running times the processes have, I guess. And obviously random variation can be coped with by using a suitable number of repetitions.
19:08:12 <lindi-> that mandelprot.b btw does not run with BFI.java, i get "Exception in thread "main" java.lang.Error: Byte incremented beyond capacity"
19:08:16 <fizzie> The key is in a "safe place".
19:08:54 <jix> fizzie: maybe it's in a trashcan...
19:09:16 <jix> hah not 100% screwdriver safe!
19:10:04 <fizzie> I assume it's not chain-saw-safe either.
19:10:55 <jix> http://www.harderweb.de/jix/open.jpg
19:12:24 <jix> hmm i need a power cable
19:13:47 <lament> anybody knows a good 4-hands piano piece?
19:14:08 <jix> its 400mhz not 300
19:14:21 <calamari> lament: you have 4 hands? cool :)
19:14:44 <jix> calamari: you have less than 4 hands?
19:15:15 <calamari> yeah, iirc squids only have the 2 long tentacles
19:15:42 <jix> oh there is a linux on the computer
19:15:54 <jix> with x11...
19:16:03 <jix> looks like i reinstall is needed
19:17:05 <jix> where is the keyboard-plug converter
19:17:39 <fizzie> lament; you're going to use time-travel to have two of you!
19:17:51 <fizzie> I ran the benchmarks for our "programming lab-work" (I can't find an official english name for it) course using a knoppix CD. That was convenient.
19:17:53 <calamari> maybe he can play with his feet, like an organ :)
19:18:02 <lament> fizzie: that's the most boring use of time-travel ever :)
19:18:42 <lament> calamari: i can play with my feet, but not piano.
19:19:21 <jix> 33 processes running default
19:19:40 <calamari> I have very little musical ability. I can play a harmonica, but not even bend notes really...
19:19:53 <jix> i play guitar
19:20:14 <lament> bending notes has nothing to do with musical ability
19:20:22 <lament> and everything with practice
19:20:59 <lament> keep practicing and you'll get it :)
19:21:16 <lament> what harmonica do you have?
19:21:20 <jix> the cpu is 99.7 % idle
19:22:20 <calamari> lament: the one I play most is a hohner weekender, because it has a wide range, and I like the scale (it's not missing notes), but it very bad for bending, because each note has two holes that play at the same time
19:22:51 <calamari> lament: I have a standard 10 hole hohner that is gathering dust.. I had a tiny bit of success bending low notes with it
19:28:29 <lament> i don't like non-standard harmonicas
19:29:20 <fizzie> An esoteric harmonica.
19:29:55 <lament> the double-reeds are less expressive then standard ten-holes
19:30:02 <calamari> I got hooked on it, because it has every note
19:30:23 <lament> I can play any diatonic note on the ten-hole
19:31:01 <calamari> the 10-hole has all the notes, iirc in the middle, but on the sides it skips them for c-e-g chords
19:32:02 <calamari> that meant I could not play certain songs
19:32:52 <lament> only chromatic harmonicas have "all the notes"
19:33:29 <lament> the weekender has a full major scale
19:33:31 <calamari> lament: I mean cdefgab.. I'm not talking about flats/sharps.. sorry to confuse :)
19:33:49 <lament> ten-holes don't have a full major scale, but it's possible to play it anyway by bending
19:34:14 <lament> and it's possible to play EVERY note within the three octaves by bending and overblowing
19:34:37 <lament> on the weekender it's impossible in principle
19:35:29 <GregorR> How the HELL is bff so fast?
19:37:07 <GregorR> Please note that egobfi was primariy intended to be powerful, fast was a later addition.
19:38:54 <calamari> I was briefly investigating a self-modiying elf binary last night. Not good at linux asm yet.
19:46:44 <calamari> I miss debug.. wish there were something interactive like that for linux.
19:52:03 -!- yrz\werk_ has joined.
19:53:40 <GregorR> I don't know what you mean by "debug"
19:54:09 <calamari> debug is a dos program.. has a built in assembler, disassembler, binary editor, etc
19:54:54 <pgimeno> calamari: yeah, that's what I miss too
19:54:57 -!- yrz\werk has quit (Client Quit).
19:55:45 <pgimeno> good ol' debug and the backwards-compatible, feature-enhanced symdeb
19:56:08 <calamari> never had symdeb.. but I had a debug32.. didn't work 100% reliably tho :)
19:56:14 <GregorR> brfd is faster with mandelbrot but slower with primes.
19:57:33 <pgimeno> oh GregorR, that's good to know... I thought that mandelbrot was long enough for a semi-decent benchmark but of course there are many optimizations that brfd can miss
19:58:30 <GregorR> I'm really just trying to save face XD
19:58:45 <pgimeno> probably primes uses chunks that are not well optimized by brfd
19:59:06 <pgimeno> brfd is actually pretty dumb, it's just a string replacement
19:59:31 <GregorR> Ahhhhhhhhh, so that's your trick :)
20:00:18 <{^Raven^}> pgimeno: got mandelbrot running in 7.4s on my optimising compiler
20:00:20 <pgimeno> yeah, it's "compiled" to a bf variation with an extended instruction set
20:00:45 <pgimeno> {^Raven^}: wow, I'd like to check it on my box for an accurate reference
20:01:31 <{^Raven^}> pgimeno: can you give me a link to the mandelbrot,bf that you are using
20:01:33 <pgimeno> does it generate C or assembly?
20:01:45 <fizzie> I don't think 'debug' was that much better than gdb.
20:02:11 <pgimeno> http://swapped.cc/bf/files/mandelbrot.b
20:02:48 <GregorR> Come on, no comparing compilers to interpreters ;)
20:03:00 <fizzie> Perhaps the fact that it didn't even try to be a symbolic debugger made it more suitable for debugging binary-only software, but anyway.
20:03:56 <pgimeno> fizzie: a mere question of taste, I suppose... I got used to that and I find gdb overcomplicated, that's all, I think
20:04:22 <{^Raven^}> pgimeno: http://jonripley.com/~jon/mandelbrot.c
20:04:41 <fizzie> Considering the amount of open-source developers, one would think there'd be some lower-level debuggers for the "rather common" linux/elf/x86 platform.
20:05:37 <pgimeno> yeah, but so far I've found no decent replacement for symdeb or hiew
20:07:46 <GregorR> Humm ... my benchmarks are way off of yours ...
20:07:54 <pgimeno> (with -O3) which is pretty impressive
20:09:22 <{^Raven^}> pgimeno: nice :D but still far from optimal
20:09:26 <GregorR> A 2.6gHz, but that's not it, they're in a totally different order.
20:10:22 <pgimeno> what processor? this one is an athlon
20:11:46 <fizzie> 30 seconds for even compiling that mandelbrot.c with gcc-3.3/-O3/1GHz-ppc.
20:12:06 <pgimeno> yeah, compilation is a bit slow
20:12:12 <GregorR> Also, I'm turing -O3 on bff into -O2 because that's totally cheating, and did -O2 on BRFD.
20:12:16 <fizzie> (Then 11 seconds to run it.)
20:12:25 <GregorR> (BFF is still waaaaaaay faster mind you)
20:12:40 <{^Raven^}> should be about .045s slower with -O2 on mine
20:13:06 <{^Raven^}> but compilation is only done once and a program can be run 100s of times
20:13:10 <pgimeno> GregorR: that may be an indication of both processors handling optimizations differently
20:13:23 <GregorR> I'm having a halting problem with brfd ...
20:14:21 <pgimeno> halting problem? is that because you're Turing -O3 into -O2? :P
20:14:59 <GregorR> brfd wasn't compiling with any -O for me ...
20:15:11 <GregorR> Oh wait, it finished, but in 149 seconds.
20:15:40 <fizzie> One thing one could try is to compare "standard" -O3 with "-march=athlon-xp -O3" and/or "-march=pentium4 -O3".
20:16:55 <pgimeno> GregorR: you can override any CFLAGS setting using: make CFLAGS="-options"
20:17:13 <pgimeno> fizzie: good point, I'm not good at gcc optimization flags
20:17:18 <GregorR> Umm, yes, I am a professional computer programmer, but thank you for explaining that to me.
20:17:43 <pgimeno> er, sorry if I was too explicit for you
20:18:36 <pgimeno> there are so many people who don't know how to override make variables, despite they are programmers
20:23:37 <GregorR> OK, I guess the only one that slowed for me was brfd, but I'm perplexed as to why >_>
20:24:23 <GregorR> Hmm, bftools slowed for me as well.
20:24:29 <GregorR> Both conveniently to the other side of egobfi :P
20:26:35 <GregorR> Incidentally, anybody have a last call for features to add to egobfi 0.2?
20:27:20 <pgimeno> GregorR: what are the current features?
20:29:51 <calamari> some like +, I like @.. maybe both ?
20:30:19 <GregorR> I'll just translate +- into @
20:31:35 <calamari> how will i/o be handled? there are two ways I know of. 1) a bit of i/o at a time. 2) 8 bits of i/o using 8 consecutive cells at once
20:31:58 <GregorR> Let's make it an option! 8-D
20:32:34 <calamari> speaking of that.. how is i/o handled for the 16 and 32 bit cases? just an 8 bit value? Or are you handling unicode?
20:33:04 <GregorR> Just an 8-bit value. But wchar support isn't necessarily a bad idea ...
20:37:19 <calamari> oh, and another request.. for the future would be some kind of esoapi / easel support
20:37:52 <{^Raven^}> calamari: supporting easel/esoapi is the simplest to add
20:38:02 <calamari> I can't see to remember the name of the standard that those two were combined udner
20:38:09 <GregorR> I'm not sure what hard disk you want me to access however :-P
20:39:22 <calamari> hm.. 3 google hits, 2 from chat logs, 1 n/a
20:39:46 <{^Raven^}> all: to add PESOIX (esoapi/easel) support you #include a header and change getchar to pesoix_getchar and putchar to pesoix_putchar
20:40:04 <GregorR> I assume you need some libpesoix?
20:40:06 <calamari> raven: is the pesoix spec on the web somewhere?
20:40:25 <{^Raven^}> calamari: yeah, lemme check it's uptodate
20:40:46 <calamari> maybe you have a robots.txt file or something?
20:41:07 <GregorR> I think this ONEBIT code is muddling up the rest of the code to much.
20:41:11 <GregorR> All these #ifdefs are nasty
20:41:35 <GregorR> Sorry calamari, cancelling that feature :P
20:41:48 <{^Raven^}> calamari: http://jonripley.com/easel/
20:42:12 <calamari> pesoix is a better feature anyways
20:42:35 <calamari> raven: why doesn't your site show up when I search for pesoix?
20:42:41 -!- graue has joined.
20:43:17 <GregorR> So, uhh, there's no actual code implemented yet?
20:44:57 <GregorR> That's not particularly helpful 8-D
20:46:23 <{^Raven^}> The current version is a little less functional than the last but the source code is hugely more maintainable
20:47:05 <{^Raven^}> Life and other projects got in the way
20:47:45 <GregorR> Well, better something than nothing, eh?
20:49:36 <calamari> there, http://lilly.csoft.net/~jeffryj/programs/esoapi/esoapi.html you're linked so in the future \I can find PESOIX :)
20:50:30 <{^Raven^}> under PESOIX I was thinking about making EsoAPI access a disk image rather than a physical volume
20:51:12 * GregorR silently (well, not silently) cancels pesoix support in egobfi 0.2
20:51:32 * GregorR still doesn't see any code.
20:52:08 * {^Raven^} wants to get the code into a reasonable state first
20:52:26 <calamari> man busted 3/3 .. should start ignoring my feature suggestions hehe
20:52:29 * GregorR wants to release egobfi 0.2, is impatient, and there's always a 0.3
20:53:22 <{^Raven^}> there's no point in PESOIX support atm, better to wait until I develop it further
20:53:35 <GregorR> That's about what I thought :)
20:53:37 <{^Raven^}> but knowing that other ppl will find it useful is a strong motivator
20:53:52 <GregorR> However, I am now looking into unicode support, CALAMARIIIIII
20:54:26 <GregorR> Question: if I use wchar.h and getwchar, will it still support ASCII just fine?
20:54:44 <GregorR> (And putwchar, presumably)
20:55:00 <calamari> raven: worked on my game a little bit last night. Currently at 114 bytes, but not done with the engine :)
20:56:32 <{^Raven^}> calamari: have 1006 bytes of game (unoptimised) and 1623 bytes of data, am working on a major functional improvement atm
20:57:11 <{^Raven^}> engine is a lot better than the previous game but still in development
21:07:12 <GregorR> I'm not sure how to test it, but AFAIK it works :P
21:13:31 <GregorR> Now I'm trying to add a 64-bit mode, but make it only add it if int64_t exists.
21:17:18 <GregorR> [+] isn't because it would be just another check for wrapping being on or off.
21:17:22 <GregorR> If wrapping is on, [+] is while (1);
21:17:23 -!- calamari has quit ("Leaving").
21:17:52 <graue> oh, if wrapping is off, the values are just clamped?
21:18:05 <graue> as opposed to incrementing the maximum value or decrementing 0 being an error?
21:18:21 <GregorR> Why, is it standard to error?
21:18:29 <GregorR> I thought it was standard to hold ...
21:18:38 -!- calamari has joined.
21:18:47 <calamari> that was weird.. irc client just died
21:19:06 <graue> I would have expected it to error, personally
21:19:34 <{^Raven^}> that would take 3x2^64 instrcutions to before an infinite loop was noticable by which time most people may have grown old and died
21:23:07 <graue> heh, it would take 1141 years on my CPU, assuming the interpreter was running in realtime and took 1 cycle to evaluate each instruction
21:23:22 <graue> that's a funny thought
21:27:09 <GregorR> Oh, and [+] is now optimized :P
21:27:15 <GregorR> But not in nonwrapping mode.
21:27:22 <fizzie> What I think is funny is to realize, that with a 2GHz cpu, cycle time is 0.5 ns, which means that during the time the thing calculates some basic operation, the light from my desk lamp moves 15 cm.
21:28:59 <GregorR> http://gregorr.homelinux.org/egobfi-0.2.tar.bz2
21:30:39 <GregorR> Incidentally, is there anybody who could upload this to www.esolangs.org ?
21:35:13 <graue> you might want to reorder the ISBF() test in this order: +-><][.,
21:35:35 <graue> according to the Spoon author, that is the order of frequency in which Brainfuck commands occur in the programs he surveyed
21:36:48 <GregorR> It's just baaaaaaaaarely off of that :P
21:37:17 <GregorR> The groups are all int he right order, but each group was reversed except for +-
21:37:23 <{^Raven^}> GregorR: You should set the program array to the length of the input file to handle large programs
21:37:35 <GregorR> {^Raven^}: The program array expands.
21:37:52 <GregorR> CHKPSZ = make-sure-it's-long-enough-and-realloc-if-it's-not
21:38:20 <{^Raven^}> GregorR: ok, i'll try it with LostKingdomBFe later to see what happens
21:38:34 <GregorR> I've already tried it, it works great.
21:49:44 <GregorR> I can almost move pieces in my checkers game now :P
21:53:11 <graue> what does egobfi stand for?
21:55:09 <GregorR> I was going to name it gkrbfi, after my initials, but calamari said that was so egotistic I should name it egobfi.
21:55:19 <GregorR> So basically "the egotistic brainfuck interpreter"
21:57:23 <GregorR> OK, here's a better benchmark for BrainFuck interpreters: how fast does it run a bf-in-bf interpreter running mandelbrot :P
21:57:46 <graue> and does yours beat qdb at that?
21:58:33 <GregorR> Sadly, mine doesn't seem to beat qdb at anything but featurefullness.
21:59:08 <graue> huh? I thought you had pulled ahead at some point
21:59:46 <GregorR> It's sort of an every-other-test thing.
22:00:05 <GregorR> So it's not 'beating' it so much as 'tying'
22:02:42 <GregorR> I think if I optimized standard moves I'd jump FAR ahead.
22:04:51 <GregorR> I suppose that is indeed what it's doing.
22:05:40 <GregorR> BUT, it works great for me, so I'm going back to checkers.b
22:06:16 <calamari> quick work on that interp.. very impressive
22:06:25 <{^Raven^}> that's pretty much one of the ops to look for in the next optimisation in my engine
22:07:55 * {^Raven^} states that it's not an interpreter
22:08:56 <GregorR> Incidentally, is there any other interpreter that actually makes wrapping etc options? I certainly haven't found one ...
22:09:27 <calamari> I thought Chris's interp did that
22:09:41 <{^Raven^}> IIRC either the current or next version of Brainwash does
22:09:47 <cpressey> and it makes you install erlang, too
22:10:20 <lament> not the dreaded erlang!!
22:15:46 <jix> i'm writing test scripts for the bf interpreter/compiler speed-test
22:16:39 <jix> i'm feeling http://dict.leo.org/?schwindelig... that's annoying
22:20:23 <jix> everything in my room moves
22:20:26 <jix> (it seems so)
22:21:54 <jix> wtf? aaargh
22:22:01 <jix> when does it stop!
22:22:30 <graue> I suddenly felt like that two days ago while walking on the sidewalk alongside a busy road
22:22:38 <jix> i didn't drink i didn't turned my desk-chair and i didn't programmed in whirl
22:22:59 <graue> maybe you have low blood sugar and must eat something
22:23:31 <jix> graue: i watched tv and was eating chocolate for about 2h
22:24:51 <graue> maybe you need to move
22:25:56 <jix> maybe it's because the air in my room is bad
22:28:18 <graue> maybe you need to open a window?
22:28:56 <jix> the first thing i did after i entered my room
22:29:30 <GregorR> Maybe you need to close a window ;)
22:29:42 <jix> nah.. it's better now
22:32:41 <fizzie> That outside air, it can be dangerous to you.
22:32:45 <fizzie> I avoid it like the plague.
22:34:33 <calamari> @a[@x_0 i_0 @x_1 i_1 ... @x_n i_n @a], where at most one @x_n = a, and i_n=-1. Result a=0, x_n+=a*i_n
22:36:13 <calamari> trying to see what a generic add-to loop looks like
22:38:37 <calamari> [>+<-] is x_0=1, i_0=+1, x_1=0 i_1=-1
22:39:41 <GregorR> I wasn't going to go in to quite that level of complexity *shrugs*
22:40:18 <GregorR> If optimizing the code takes more time than running the code, there's a problem :P
22:40:23 <calamari> most people put the loop variable at the front or end
22:40:44 <calamari> usually the end from what I've seen
22:40:55 <GregorR> I exclusively put it at the end.
22:42:33 <calamari> you probably already have situations where optimizing is taking longer than running.. for trivial programs
22:44:12 <GregorR> Wow, bff is really doing badly at factor.b ...
22:45:40 <GregorR> Welcome to the halting problem, Gregor XD
22:48:05 <GregorR> OK, qdb and egobfi are still in a dead heat XD
22:52:07 <calamari> so much for the checkers program :P
22:54:35 <GregorR> http://gregorr.homelinux.org/checkers.b
22:55:14 <GregorR> Hmm, seems to send it in HTML mode :P
22:55:44 <GregorR> http://gregorr.homelinux.org/checkers.b.txt
22:55:54 <GregorR> A big chunk at the top was autogenerated by simple-txt2bf.c
23:01:19 <graue> has simple-txt2bf.c been published?
23:01:39 <GregorR> It's on the brainfuck archive, just a sec, lemme get a linki.
23:01:57 <GregorR> http://esoteric.sange.fi/brainfuck/utils/simple-txt2bf.c
23:09:34 -!- calamari_ has joined.
23:13:30 <{^Raven^}> GregorR: textgen.java at http://lilly.csoft.net/~jeffryj/programs/bf/ is a good program for making BF program fragments to display strings
23:17:51 <GregorR> I'm morally opposed to Java :P
23:19:52 -!- calamari has quit (Read error: 110 (Connection timed out)).
23:30:46 <GregorR> Though I have no non-Free software, so if that doesn't work with gcj or jikes it's no good for me *shrugs*
23:33:19 <GregorR> Hmm, that is a pretty awesome program.
23:33:30 <lindi-> GregorR: textgen seems to work flawlessly with free software (jikes+gnu classpath+jamvm)
23:34:02 <GregorR> I'm using Jikes + SableVM, works fine.
23:34:16 <GregorR> (+ GNU Classpath, but who DOESN'T use GNU Classpath?)
23:35:00 <lindi-> kaffe used to have completely different library and the merge isn't 100% complete yet
23:36:47 <lindi-> GregorR: anyways, it's very nice to hear that people use classpath. feel free to report all bugs you find :)
23:36:59 <Aardwolf> Hey, why do so few languages on the esolang wiki have a local copy of the external webpage?
23:38:14 <calamari_> Aardwolf: copy of the content of the page, or do you mean link?
23:38:35 <Aardwolf> I mean a copy in the preservation page
23:38:56 <calamari_> Aardwolf: the original page cannot be copied.. it would be a violation of copyright
23:39:12 <GregorR> Hmm, archive.org seems to get away with it.
23:39:32 <calamari_> weren't they sued about a month ago?
23:39:55 <Aardwolf> They asked me if they could make a local copy of my page and I allowed it
23:42:20 <GregorR> Just for laffs I put the first four lines of the King James Bible in the genetic text generator :P
23:43:07 <calamari_> http://yro.slashdot.org/article.pl?sid=05/07/13/0527236&tid=95&tid=17
23:43:36 <graue> damn it, why doesn't C define a<<b to be equivalent to a>>(-b) when b is negative?
23:43:43 <graue> that would be a lot more convenient
23:44:17 <graue> apparently 1<<(-1) produces -2147483648 on my machine
23:44:49 <Aardwolf> Harding Earley Follmer & Frailey should have used a robots.txt then, the dumbasses
23:45:02 <lindi-> graue: #define shift(a,b) (((b)>0)?((a)<<(b)):((a)>>-(b))) ;)
23:45:14 <{^Raven^}> If you read the full text of the complaint it's very funny and quite disturbing
23:45:51 <calamari_> Aardwolf: anyhow.. since we dont have an army of laywers, it's easier to just not include copyrighted stuff :)
23:46:48 <graue> Aardwolf, read the update, Harding Earley Follmer & Frailey are not the ones suing
23:47:47 <GregorR> AHAHAHA my CPU is overheating
23:50:53 <graue> I'm glad you are so happy about that :)
23:55:31 <GregorR> Seems like it may have bottomed out at 5282
23:56:23 <Aardwolf> cool, my browser supports the monospaced Hangul font