00:04:12 -!- olsner has quit ("Leaving").
00:12:13 -!- timotiis_ has quit ("leaving").
00:14:20 * pikhq is a cruel bastard. . .
00:14:43 <pikhq> In the FRC: should you become temporally disjoint from the bus, you should calculate G while waiting for the bus to find you again.
00:15:09 <oerjan> shall i dare to ask what G is?
00:15:52 * oerjan was hoping for the gravitational constant
00:16:09 <pikhq> Sorry, but I like the up-arrow notation. :p
00:20:23 -!- ais523_non-admin has quit ("Bye!").
00:20:42 <oklokok> knuths arrays are basically the hyper operator?
00:21:14 <pikhq> oklokok: Pretty much.
00:21:19 <pikhq> Different notation for the same.
00:21:33 <oklokok> i invented the hyper oerator as a kid, thought it was a new idea until like last year :P
00:22:07 <pikhq> It's a fairly trivial concept to *grasp*.
00:22:09 <oklokok> i guess there's not much to invent
00:22:14 <pikhq> But a bit harder to use *usefully*. ;)
00:22:48 <oklokok> well, i was mainly trying to find the hyper operations for reals as well
00:22:53 * pikhq should have done A(G, G). . .
00:23:03 <oklokok> but it seems it hasn't been done yet in a meaningful way
00:23:04 <pikhq> You were. . . Trying to extend hyper to the reals?
00:23:57 <pikhq> But, then, I'm only in high school. ;)
00:23:57 <oklokok> "The family has not been extended from natural numbers to real numbers in general for n>3, due to nonassociativity in the "obvious" ways of doing it."
00:24:10 <oklokok> well, this was when i was in elementary school
00:24:31 <oklokok> it's not like i was a super math genius or anything
00:24:43 <oklokok> i just have a lot of weird ideas
00:25:15 <pikhq> I'm only a *moderate* genius at math. ;p
00:25:37 <oklokok> i'm not practical enough for math
00:25:46 <oklokok> requires perfection, unlike say programming
00:26:37 * pikhq wonders what the derivative of ^{x}e is. . .
00:27:04 <pikhq> Or e\uparrow\uparrow x.
00:28:33 -!- Judofyr has quit (Read error: 104 (Connection reset by peer)).
00:29:09 -!- Judofyr has joined.
00:29:55 <oklokok> well, x^f(x) really, then just extend that
00:30:32 <oklokok> hmm, i think i should wait until i'm *not* watching something
00:30:42 <oklokok> i'm not good at multitasking really
00:31:44 <oklokok> right, i misparsed you still
00:31:44 <pikhq> Not familiar with Knuth's up-arrow notation?
00:31:53 <pikhq> In it: e^x = e\uparrow x.
00:34:08 <oklokok> i think i got it, not derivable :P
00:34:44 <oklokok> e upup x where x = real doesn't exist, right?
00:34:49 <pikhq> Sure it is! It's a smooth curve and everything.
00:35:01 <pikhq> http://en.wikipedia.org/wiki/Image:Real-tetration.png
00:35:19 <oklokok> that's a matter of definition then, lessee
00:35:44 <pikhq> Just because it's not derivable in terms of elementry functions does *not* make it not derivable. ;p
00:36:03 <oklokok> it cannot be derivable if it does not have a definition for reals
00:36:12 <oklokok> it seems it does, but where is it?
00:36:49 <pikhq> What part of that says it's *not* defined on the reals?
00:38:07 <pikhq> That's e^{{1/2}^2}. :p
00:38:42 <oklokok> the fact you can possibly extend the array-notation definition using your intuition doesn't make it a real definition.
00:38:59 <oklokok> the array-notation only works for integers with the definition there
00:39:49 <pikhq> You're confusing e^^x and hyper(e, x, x). ;P
00:40:25 <oklokok> e^^x = e^e^...^e where e is there x times
00:40:41 <oklokok> if x isn't an integer, that makes no sense
00:40:42 <pikhq> Yes. What about that definition prevents e^^x from being defined on the reals?
00:41:30 <oklokok> you can definitely define it for reals, i'm just saying the page doesn't do that.
00:41:58 <oklokok> for instance, you can just define e^^x where x isn't an integer to be zero.
00:42:32 <oklokok> exponentiation does real exponents using the inverse operation
00:42:48 <oklokok> perhaps that could also be created for the array notation
00:43:32 <oklokok> i'm just saying i'm physically not seeing a definition for real arrow-exponent
00:43:47 <oklokok> have i been saying "array"?
00:43:49 <pikhq> Repeated multiplication doesn't define, say, e^0.5, yet it still exists as a real.
00:44:05 <oklokok> pikhq: as i said, defined via the inverse for reals
00:44:07 -!- BMeph has joined.
00:44:22 <oklokok> because you can use the inverse function for the denominator of the exponent.
00:44:48 <pikhq> Having trouble finding an *exact* definition, but it's *about* 1.5.
00:44:57 <oklokok> and define reals to be the limit of doing that where the rational number representing the exponent ...gets closer to the real exponent
00:45:24 <oklokok> you could define it in many ways
00:45:44 <pikhq> Likewise, you could define 1+1=50. I fail to see how that's relevant.
00:46:11 <oklokok> it's relevant in that if it doesn't have a definition, the derivative doesn't have a definition
00:46:18 <pikhq> That Wikipedia page says there's no commonly accepted solution to extended tetration to the reals.
00:46:59 <oklokok> but it could prolly be done using something like the inverse function way exponentiation uses, as i already said two times i guess
00:47:10 <oklokok> i'll look into that after this episode
00:47:23 <pikhq> Yeah, I think I like the super-logarithm solution.
00:48:03 <oklokok> exponentiation uses the other inverse :)
00:48:48 <pikhq> The problem being: the super-logarithm on the reals is not defined, either. XD
00:48:55 <oerjan> the only obvious equation to start with would seem to be e^^(x+1) = e^(e^^x)
00:49:25 <oklokok> oerjan: doesn't help, we still need e^x where x in [0..1]
00:51:16 <oerjan> there might be one solution that was particularly nice in some way
00:52:30 <pikhq> Define it in terms of the square-super-root. ssrt(x) = e ^ {W(ln(x))}, where W is the inverse of f(w)=we^w. . .
00:52:43 <pikhq> (can't prove: Wikipedia claims it to be so)
00:54:52 <pikhq> Anyways, that provides a fairly *elegant* extension to the reals.
00:54:56 <pikhq> oerjan: You agree?
00:55:07 <oklokok> i do, that's what i suggested right away
00:55:25 <oklokok> is there a nice way to compute w?
00:55:48 <oklokok> i'm too lazy to google, sry :P
00:55:56 <pikhq> The Wikipedia page gives some C source code for W(x). ;)
00:56:58 -!- Corun has joined.
00:57:51 -!- pikhq has set topic: - From Brainfuck to extending tetration to the reals..
01:00:24 -!- oerjan has quit ("Good night").
01:21:34 -!- Judofyr has quit (Read error: 104 (Connection reset by peer)).
01:21:58 -!- Judofyr has joined.
01:33:01 -!- sebbu has quit ("@+").
01:38:16 -!- calamari has joined.
01:39:15 <calamari> pikhq: I was curious, so I got the free HTML version of the posix spec and convereted it to PDF.. thousands on pages.. wow
01:40:01 <pikhq> But that's specifying the behavior of all of UNIX. . .
01:40:18 <calamari> I think there's a hidden spec out there
01:40:19 <pikhq> Just my collection of *man pages* would probably cover a thousand pages.
01:40:41 <calamari> "what's good enough to get gcc working with configure scripts?"
01:40:45 <pikhq> (info pages? Hell, that's probably got the POSIX spec in there two times over)
01:41:13 <calamari> probably a lot less strenuous a goal
01:41:51 <calamari> btw you mentioned that porting gcc over wasn't a big deal.. what's the process?
01:41:51 <pikhq> You need a shell, make, gcc, and libc.
01:42:32 <pikhq> Assuming you use an executable format that GCC supports? Port libc. Compile a GCC cross-compiler. Use that to make a GCC native compiler.
01:42:45 <pikhq> The 'port libc' part is the hard one.
01:43:53 * pikhq can't wait to one day do uname -a and get 'i686-pc-mykernel-newlib'
01:44:10 <calamari> oh so you're doing it for your regular pc?
01:44:23 <calamari> I was hoping this was some custom system you built out of parts or such
01:44:26 <pikhq> Although my *regular* PC is actually x86_64.
01:44:36 <pikhq> That makes it a bit harder.
01:44:42 <pikhq> You then have to retarget GCC.
01:45:04 <pikhq> But at least GCC just does RTL->assembly. . .
01:45:12 <pikhq> (for the architecture-specific stuff, that is)
01:45:55 <pikhq> I'm mostly saying 'Thank god GCC has all the frontends go to the same language.'
01:52:49 -!- Corun has quit (Read error: 110 (Connection timed out)).
02:07:36 <calamari> http://www.atmel.com/dyn/products/product_card.asp?part_id=3755
02:08:58 -!- oklokok has quit.
02:21:22 <Deformative> Anyone up for a seemingly np complete problem?
02:32:19 -!- Tritonio_ has joined.
02:39:38 -!- Sgeo has joined.
02:40:53 <pikhq> Deformative: Sure.
02:41:01 <pikhq> Just because its NP doesn't mean it can't be solved.
02:41:09 <pikhq> Just that it can't be solved efficiently. ;)
02:43:10 <Deformative> pikhq: You have a block of memory, and a new order, some locations are duplicated, some are no longer used, but they refill the same block, design an algorithm to find the least number of movements needed.
02:43:54 <Deformative> So you have [a b c d e f] and it needs to be transformed to an arbitrary new order, for example: [a b e e f c]
02:44:29 <pikhq> Sorting algorithm. Lower bound is O(n log n).
02:44:49 <pikhq> 'Some locations are duplicated'
02:44:53 <pikhq> Whaddya know. It's not.
02:45:20 <pikhq> Why would you need the minimum amount of movements?
02:45:40 <Deformative> It is a compiler that needs to generate optimal code.
02:46:08 <Deformative> Sorting does not need to remain in the same memory block.
02:46:22 <pikhq> The thing is: you don't necessarily need to generate *optimal* code, if that's too hard to do. What you need to do is produce *pretty good* code. . .
02:46:31 <pikhq> Which is usually a much easier problem.
02:46:59 <pikhq> And besides: finding the lower bound of your movement algorithm there won't help because *you still don't have said movement algorithm*. ;)
02:47:38 <pikhq> So, a more *useful* question is "How can I efficiently move things around like this: ..."
02:48:06 <pikhq> Why do you need that?
02:48:29 <pikhq> What you're asking for is the lower-bound of the efficiency of an algorithm that does that.
02:48:38 <pikhq> What you need is the algorithm itself.
02:49:15 <pikhq> Just like asking "How many steps does it take to sort a list?" is useless when you actually want to sort.
02:49:18 <Deformative> The algorithm does not need to re-arange, the algorithm generates code that will re-arrange.
02:50:17 <pikhq> Which is not that much different, algorithmically. . .
02:50:51 <pikhq> I still have no clue why you need to know the efficiency of such an algorithm, but not the algorithm itself.
02:50:53 <Deformative> Because you can bruteforce until you find the algorithm that has the least movements.
02:51:07 <pikhq> You're doing it wrong.
02:52:01 <pikhq> I suspect, though, that you could trivially adapt a sorting algorithm to that.
02:53:44 <Deformative> Alright, a language privative is to convert [a b c d] to [a a b d] the code generated should not do the same ineffective algorithm every time, the compiler should do a lot of work once so that it has a perfect algorithm every time it is run.
02:55:14 <pikhq> Are those two orders always the same between calls to the same language primitive with the same argument? (that is, would "transform(abcd, aabd)" do the same thing every time?)
02:57:16 <cherez> And the only allowed operation of movement?
02:57:33 * pikhq is still tempted to say 'sorting algorithm'. . . XD
02:57:41 <Deformative> It is manipulating arguments. My language is capable of using the same memory block to keep args in for every function, but a function has many of the same args as the function that called it.
02:58:40 <Deformative> So lets say foo( a b c d) calls bar(a a b d)
02:58:41 <cherez> Deformative: Is the only allowed operation is a[i] = a[j]?
02:58:46 <pikhq> Doing it wrong. . . Use the C calling convention on your system of choice, for crissake.
02:59:11 <Deformative> That would take the whole esoteric part out of it.
02:59:24 <cherez> Is this for tail recursion?
02:59:25 <Deformative> cherez: I am trying to generate optimal asm.
02:59:44 <pikhq> If I ever did PEBBLE->assembly, I'd use the C calling convention. . .
02:59:48 <Deformative> And movl is really the only call that should be needed.
02:59:56 <pikhq> That doesn't remove the esotericness of language. . .
03:00:05 <pikhq> It just makes your *compiler* purely insane.
03:00:14 <pikhq> Your implementation doesn't have to be esoteric. ;)
03:00:21 <Deformative> cherez: The language does not have return values.
03:00:26 <cherez> Well, if every operation must overwrite, it's only possible if it's the same output or no variables are dropped.
03:00:47 <pikhq> cherez: He allows temporary storage.
03:01:21 <pikhq> Well, the C calling convention won't work.
03:01:29 <cherez> So reordering the stack then jmp?
03:01:33 <Deformative> So c calling is hardly even feasible, and possibly the least optimal thing imaginable.
03:01:51 <Deformative> I need the compiler to generate perfect algorithms that reorder the stack.
03:02:18 <pikhq> Once again: you need the compiler to generate *good* algorithms that reorder the stack, not perfect ones.
03:02:49 <Deformative> So it should be able to find the perfect algorithm.
03:03:20 <pikhq> I think that you're going to have a max of however many arguments you have to each function. . .
03:03:50 -!- Tritonio_ has quit (Remote closed the connection).
03:04:10 <Deformative> The compiler needs to be able to figure that out.
03:04:43 <pikhq> But it's obvious that the compiled code is going to be doing that in O(1). . .
03:05:21 <pikhq> Genetic algorithm? Stable sorting algorithm?
03:05:54 <cherez> With O(n) temporary storage, I'd think this is probably O(n) or O(n^2).
03:06:33 <pikhq> Deformative: O(0) means that nothing happens at all. ;p
03:06:40 <pikhq> If anything at all is done, then it's O(1).
03:06:55 <cherez> A jmp is damn well something.
03:07:04 <cherez> You can try to convince your program counter otherwise.
03:07:13 <cherez> Well, I suppose it depends on the processor architecture.
03:07:16 <Deformative> jmp is not part of the translation algorithm.
03:07:37 <Deformative> The compiler does not generate any translation if it is not needed.
03:09:22 * pikhq tosses Deformative "The Art of Computer Programming"
03:09:28 <pikhq> Have fun; I'm sure you can figure it out.
03:10:12 <cherez> The hard part is showing a solution is optimal.
03:10:16 <Deformative> Because you are not trying to solve the problem exactly, you are trying to design the perfect solution given limitless time.
03:10:41 <cherez> I can think of quite a few ways to generate good algorithms, but I can't think how you could prove optimal.
03:11:38 <cherez> I can't think of a polynomial way that I can prove has minimum movl.
03:12:08 <Deformative> If you cannot even count them, how do you generate the code? :)
03:12:52 <cherez> Well, I can easily see how you could write an O(n) algorithm to produce O(n) movl.
03:13:05 <cherez> That's certainly countable.
03:13:21 <cherez> But I'm also certain there are more efficient ways.
03:13:50 <Deformative> Let me try to get some of my ideas into words.
03:14:02 <Deformative> First, make a list of indices no longer needed.
03:15:19 <Deformative> Next make a list of indices that are at the same place in beginning and result.
03:16:54 <Deformative> Then generate every possible combination to reach the result, and in each combination count the movls.
03:17:21 <Deformative> To generate the combinations, you need to check over every single index and see where they need to go.
03:17:55 <Deformative> Data can be moved to places where that data is no longer needed without any negative effects.
03:18:19 <Deformative> So that is constant in all of the possible combinations.
03:18:52 <cherez> That is roughly the NP algorithm I came up with.
03:19:18 <cherez> I'd say it's probably NP-Complete, but I'm not certain.
03:20:11 <Deformative> Yes, I just need to find an algorithm for generating all possible combinations.
03:20:33 <Deformative> Even if it is npcomplete, it will generate perfect code, so that is not a problem if the algorithm I come up with is bad.
03:20:53 <pikhq> It also risks *never completing*.
03:21:06 <pikhq> NP-complete algorithms take quite a bit of time. ;)
03:22:47 <cherez> Make a queue of operation sets, put an empty set of instructions on it.
03:23:55 <cherez> While the operations do not produce the desired result, for every possible action that can be taken, add a new operation set that is the one retrieved, plus the new possible action.
03:24:19 <cherez> Basically just enumerating the possible actions and executing them in sequence.
03:26:22 <pikhq> http://en.wikipedia.org/wiki/Dijkstra%27s_algorithm
03:27:53 <cherez> Actually, I think that might be polynomial.
03:28:36 <cherez> A huge polynomial, but polynomial all the same.
03:30:18 <cherez> No, that's nonpolynomial.
03:31:25 <Deformative> The generated apps should be ridiculously fast.
03:31:30 <cherez> Let's see, at each step there are O(n^2) branches, and there are at most O(n) steps.
03:32:51 <cherez> So O(n^(2n)) total branches.
03:33:01 <cherez> Thus as many vertices.
03:34:33 -!- adu has joined.
03:35:25 <Deformative> Well, I have exams tomorrow, so I should sleep.
04:31:19 -!- andydude has joined.
04:31:41 -!- adu has quit (Connection timed out).
04:32:17 -!- andydude has changed nick to adu.
05:06:01 -!- Sgeo has quit (Remote closed the connection).
05:21:09 -!- Judofyr has quit (Read error: 110 (Connection timed out)).
05:55:24 -!- adu has quit (Remote closed the connection).
05:57:29 -!- adu has joined.
06:08:06 -!- calamari has quit ("Leaving").
06:34:30 -!- adu has quit (Remote closed the connection).
07:15:32 -!- Judofyr has joined.
07:37:15 -!- Judofyr has quit.
07:38:24 -!- BMeph has quit ("calls it a night").
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
09:31:32 -!- oerjan has joined.
11:55:53 <AnMaster> err, wtf, looks like *code* memory is corrupted, anyway the output makes no sense
12:09:51 <AnMaster> BAD: the top of the stack after y isn't equal to what 1y pushes
12:10:10 <Deewiant> and it expects the top 2 elements of the stack to be the same
12:12:23 <AnMaster> I'm trying to fix my y and I end up with heap or stack corruption :/
12:12:33 <Deewiant> isn't it fun to program in C ;-)
12:13:15 <AnMaster> ==12040== Conditional jump or move depends on uninitialised value(s)
12:13:15 <AnMaster> ==12040== at 0x40565E: ExecuteInstruction (interpreter.c:197)
12:13:15 <AnMaster> ==12040== by 0x405EBB: interpreterMainLoop (interpreter.c:440)
12:13:15 <AnMaster> ==12040== by 0x405FC7: interpreterRun (interpreter.c:472)
12:13:15 <AnMaster> ==12040== by 0x404C9D: main (main.c:121)
12:13:54 <Deewiant> yay for not initializing variables by default
12:15:02 -!- oerjan has quit ("leaving").
12:15:32 <AnMaster> Deewiant, well no that wasn't the issue
12:15:45 <AnMaster> it was an array index off by one issue
12:15:55 <Deewiant> yay for not having array bounds checks ;-)
12:16:17 <AnMaster> wrapped, and ended up with 71634721834 or something like that
12:16:23 <Deewiant> whatever you say, I can spin it into a pro-D anti-C argument if I try hard enough :-P
12:16:28 <AnMaster> (gdb) print tmp->top - request
12:16:41 <Deewiant> fortunately, I don't have to try very hard ;-)
12:17:16 <Deewiant> I'm convinced by now that the only significant difference is the function pointers versus switch-case
12:17:42 <Deewiant> consider the noOperation function that I showed yesterday :-P
12:17:50 <Deewiant> it's called through a function pointer every time z is hit
12:18:31 <Deewiant> and I suspect PaX does some sort of checking related to function pointers, which results in extra slowdown on your comp
12:18:39 <Deewiant> I think the code is cleaner this way
12:18:41 <AnMaster> Deewiant, I don't think it does
12:18:55 <Deewiant> AnMaster: I read some docs on PaX design and they mention something to that effect
12:19:03 <AnMaster> my gcc does stack smash protection though
12:21:53 <AnMaster> Deewiant, btw for ccbi mycology list command line arguments backwards
12:22:03 <AnMaster> is it supposed to do it that way?
12:22:24 <AnMaster> say ./ccbi mycology.b98 some other things
12:22:35 <AnMaster> That the command-line arguments were: [ "things" "other" "some" "mycology.b98" ]
12:23:00 <Deewiant> not sure whether that's a CCBI or Mycology issue ;-)
12:23:03 <AnMaster> while mine do: That the command-line arguments were: [ "mycology.b98" "some" "other" "things" ]
12:23:24 <AnMaster> Deewiant, so I want to know if I should push them in the other order or not
12:23:42 <AnMaster> I got no idea what one is correct on this thing
12:23:46 <Deewiant> well it's an interpretation issue I think
12:23:51 <Deewiant> The first string is the name of the Funge source program being run.
12:23:59 <Deewiant> does "first" here mean topmost or the one that was pushed first
12:25:00 <Deewiant> most of y is strictly speaking UNDEF
12:25:08 <AnMaster> maybe mycology should test it in "Here's how your interpreter deals with some possibilities unmentioned in the specification..." section?
12:25:41 <Deewiant> naw, because that's uncontrollable - would need the user to pass some command line args
12:25:51 <Deewiant> and to be frank there's a lot of "possibilities unmentioned in the specification"
12:26:01 <Deewiant> that was more like a roundup of stuff that is likely to crash/infinite loop your interpreter
12:26:19 <AnMaster> GOOD: y acts as pick instruction if given large enough argument
12:26:26 <Deewiant> or that was the original intention, anyway :-)
12:26:52 <AnMaster> Deewiant, currently my interpreter may be slightly slower, due to a non-optimized y instruction heh
12:27:00 <AnMaster> I actually create a second stack atm
12:28:14 <Deewiant> what do you push for team number btw :-P
12:28:30 <AnMaster> because I got no idea what to do there
12:29:03 <Deewiant> I think it's a remnant of Befunge-97 but I'm not sure
12:29:12 <AnMaster> -p, --disable-fprints Run as if no fingerprints were implemented.
12:29:14 <AnMaster> -p, --print-fprints List all supported (and knowingly unsupported)
12:29:22 <AnMaster> you got that messed up in ccbi --help
12:29:36 <Deewiant> you've still got the old version :-)
12:31:31 <AnMaster> yay (while maybe slower atm, don't know): all good or undef
12:38:09 <AnMaster> actually there is one thing left, but mycology doesn't test it
12:38:23 <AnMaster> that the size of stacks for y actually pushes a value for each stack
13:23:56 -!- faxathisia has joined.
13:37:28 <AnMaster> Deewiant, on 64-bit it actually runs slightly faster with int_fast64_t than int_fast32_t, but almost the same speed
13:38:06 <GregorR> Um ... on a 64-bit environment, shouldn't int_fast32_t == int_fast64_t?
13:38:44 <GregorR> fastX = the type at least this large that's fast on this system, which on a 64-bit system should always be 64-bit.
13:38:47 <AnMaster> gcc -std=c99 -fbranch-probabilities -D_GNU_SOURCE -Isrc -combine -march=k8 -pipe -O3 -fwhole-program -Wl,-O1,--as-needed,--hash-style=gnu -Wall -Wextra -o cfunge08 lib/libghthash/*.c src/*.c src/*/*.c src/funge-space/b98/funge-space.c -lgc -lcord
13:41:20 <AnMaster> with int32_t I get faster actually
13:41:30 <AnMaster> $ time ./cfunge08 mycology.b98 > /dev/null
13:42:45 <AnMaster> $ time ./ccbi --disable-fprints mycology.b98 > /dev/null
13:43:01 <AnMaster> of course the latter is the binary Deewiant provided
13:43:12 <AnMaster> as I can't compile ccbi successfully here
13:43:30 -!- Slereah has joined.
13:43:42 <AnMaster> GregorR, CCBI being written in D btw
13:44:35 -!- faxathisia has quit ("If there are any aliens, time travellers or espers here, come join me!").
13:45:10 <GregorR> That explains why you can't compile it *haw haw haw*
13:45:30 -!- slereah_ has quit (Read error: 104 (Connection reset by peer)).
13:57:08 <AnMaster> gcc -std=c99 -fprofile-use -D_GNU_SOURCE -Isrc -combine -march=k8 -pipe -O3 -fwhole-program -Wl,-O1,--as-needed,--hash-style=gnu -Wall -Wextra -o cfunge08 lib/libghthash/*.c src/*.c src/*/*.c src/funge-space/b98/funge-space.c -lgc -lcord
14:08:38 -!- Slereah has quit (Read error: 104 (Connection reset by peer)).
14:08:55 -!- Slereah has joined.
14:14:15 -!- slereah_ has joined.
14:15:47 -!- Slereah has quit (Read error: 104 (Connection reset by peer)).
14:36:17 * slereah_ received "From Frege to Gödel"
14:37:27 <slereah_> Heh. Begriffsschrift is funny looking.
14:38:48 <slereah_> Ah yes, "Building blocks of logic", by Schönfinkel.
14:48:57 -!- slereah_ has quit (Read error: 104 (Connection reset by peer)).
14:49:09 -!- slereah_ has joined.
14:59:55 -!- slereah_ has quit (Read error: 104 (Connection reset by peer)).
15:01:57 -!- slereah_ has joined.
15:20:12 -!- sekhmet has quit (Remote closed the connection).
15:24:53 <Deewiant> AnMaster: your month in y is off by one
15:29:17 -!- sekhmet has joined.
16:03:20 -!- timotiis has joined.
16:22:09 -!- slereah_ has quit (Read error: 104 (Connection reset by peer)).
16:31:32 -!- sekhmet has quit (Read error: 104 (Connection reset by peer)).
16:31:57 <AnMaster> Deewiant, pushed fix (as well as make cmake nicer, to actually check for existence of boehm
16:32:23 -!- sekhmet has joined.
16:33:02 <Deewiant> AnMaster: btw, if you want to fix a typo in Mycology, change line 188 column 110 (should be a space just to the left of a <) to a ;
16:34:10 <AnMaster> Deewiant, what does that typo do?
16:35:14 <Deewiant> AnMaster: run cfunge08 on the unmodified mycology and there should be a messed-up message where it tests k with a negative argument
16:35:15 <AnMaster> "a space just to the left of a <"
16:35:29 -!- slereah_ has joined.
16:35:37 <Deewiant> see how easy it is to make typos? ;-)
16:36:09 <AnMaster> anyway can't see anything about negative k in output?
16:36:31 <Deewiant> AnMaster: at the place where it's testing stuff unspecified, right before fingerprints
16:37:31 <AnMaster> Deewiant, you want to upload a fixed version
16:37:46 <Deewiant> just thought it'd be easier to tell you to fix it than to have you unzip it :-P
16:37:54 <AnMaster> now I got like 5 copies of mycology around in different places all different versions
16:40:05 <AnMaster> Deewiant, btw does the standard say if months should be 0-indexed or 1-indexed
16:40:40 <Deewiant> BTW, if I remove the fflush(stdout)s from cfunge08, it's consistently 25% faster than CCBI. otherwise, CCBI beats it when not outputting to dev/null
16:40:54 <Deewiant> AnMaster: don't think so, but all the interpreters agree that they're 1-indexed ;-)
16:41:22 <AnMaster> Deewiant, ok I'll change that to only flush at newlines or something
16:41:42 <Deewiant> and IMHO that should be the default if unspecified anyway, only programmers use 0-indexed values
16:42:01 <AnMaster> Deewiant, well who would use befunge, except programmers?
16:42:25 <AnMaster> gmtime that I use to split the date up, uses 0-indexed month
16:43:18 <Deewiant> because it has a 1-indexed day
16:47:28 -!- slereah_ has quit (Read error: 104 (Connection reset by peer)).
16:47:36 -!- slereah_ has joined.
16:51:28 <AnMaster> Deewiant, btw using 32-bit versions on 64-bit platforms make it *EVEN* faster ;P
16:57:06 <pikhq> Comparing what to what?
16:57:39 <AnMaster> pikhq, same program compiled to use 32-bit data types and 64-bit data types. However of course the code was 64-bit still in either case
16:57:59 <Deewiant> AnMaster: are you talking about int_fast32_t versus int_fast64_t?
16:58:09 <pikhq> That makes sense, then. . . I think.
16:58:12 <AnMaster> Deewiant, int_fast64_t vs. int32_t in fact
16:58:21 <AnMaster> because int_fast32_t = 64-bit on amd64 it seems
16:58:25 <Deewiant> thought so, because int_fast32_t should be the same
16:58:43 <pikhq> Try it in assembly, though.
16:58:47 <AnMaster> anyway I'm making some ifdef for them
16:58:58 <AnMaster> pikhq, no way I'm going to write a befunge98 interpreter in asm
16:59:17 <pikhq> AnMaster: That's just to satisfy my curiosity about what the hell is making it faster.
16:59:36 <AnMaster> pikhq, try gcc -S to make it output asm
16:59:40 <pikhq> Reading a few chunks of assembly code doing the equivalent thing with its data types would help that.
16:59:55 <AnMaster> gcc -std=c99 -fprofile-use -funsafe-loop-optimizations -Wunsafe-loop-optimizations -fvisibility=hidden -D_GNU_SOURCE -Isrc -combine -march=k8 -pipe -O3 -fwhole-program -Wl,-O1,--as-needed,--hash-style=gnu -Wall -Wextra -o cfunge08 lib/libghthash/*.c src/*.c src/*/*.c src/funge-space/b98/funge-space.c -lgc -lcord
17:00:27 <AnMaster> -ffast-math made it *slower* in fact
17:00:53 <pikhq> I'm not talking 'all of Befunge', just "mov %eax, $foo" vs. "mov %rax, $foo".
17:01:06 <pikhq> AnMaster: For the love of God, don't do -ffast-math.
17:01:08 <AnMaster> pikhq, very likely it is due to how I handle them
17:01:16 <pikhq> It's almost as bad as -funroll-loops.
17:01:19 <AnMaster> pikhq, I don't do any floating point maths at all
17:01:37 <AnMaster> pikhq, and I do optimizing with profile feedback
17:01:47 <AnMaster> and that *DOES* activate -funroll-loops, based on profile data
17:01:55 <pikhq> Just stick with -O2, for the love of God.
17:02:04 <AnMaster> pikhq, normal is -O0 -ggdb3 :P
17:02:19 <AnMaster> just working on beating Deewiant's CCBI :D
17:02:24 <pikhq> -O2 is the most optimization you can do sanely.
17:02:35 <AnMaster> pikhq, yes but I'm the author of cfunge
17:02:40 <AnMaster> so I know what I can do safely
17:02:41 <pikhq> Well, in that case, don't distribute those binaries without saying 'stupidly optimised', and carry on.
17:02:50 <pikhq> In that case, just carry on.
17:03:06 <pikhq> And beat everyone else that tries that without grokking his/her code.
17:03:08 <AnMaster> pikhq, of course I'm well aware of that things may break
17:03:25 <AnMaster> and indeed likely will if I'm not 100% sure of what I'm doing right now
17:03:33 <AnMaster> and verifying result with test suite
17:03:45 <AnMaster> pikhq, the normal way I compile it with is -O0 -ggdb3 after all :D
17:03:49 * pikhq grabs an assembler. That's how we optimise code. . .
17:03:56 <pikhq> And I walked up hill both ways! In the snow!
17:03:58 <AnMaster> pikhq, nah, I let gcc or whatever do it
17:04:26 <AnMaster> having to clean out the lake you live in before you woke up?
17:04:33 <pikhq> But, on a more serious note: as cool as assembly is, x86 assembly makes it such a pain that you damned well better not.
17:04:41 <pikhq> I'm in Colorado. What lakes?
17:04:44 * AnMaster remembers that mony python thing
17:05:20 <AnMaster> pikhq, I thought it was a reference to a Monty Python sketch (spelling?)
17:05:31 * pikhq returns to reality. . .
17:05:33 <AnMaster> anyway, no way I'm doing x86 asm
17:05:52 <pikhq> I think -ffast-math makes the floating point code go through the x86 FPU. . .
17:05:55 <AnMaster> 1) I'm on x86_64, 2) I only done some ams for PIC
17:06:09 <pikhq> The problem being that, by default, and floating point code goes through SSE2, which is faster.
17:06:47 <AnMaster> pikhq, thanks for that information
17:07:47 <pikhq> Well, that is, that's the default on x86_64, since every x86_64 chip does SSE and SSE2.
17:08:06 <AnMaster> pikhq, so I should do -mfpmath=sse then?
17:09:42 <pikhq> No, you shouldn't do either...
17:09:56 <pikhq> Since gcc is compiling for x86_64, it does SSE2.
17:10:20 <pikhq> That's the fastest you can guarantee your floating point code is running, unless you can assume SSE3.
17:10:32 <pikhq> In which case, just do -msse3.
17:11:23 <AnMaster> pikhq, I do have sse3 in my sempron in fact
17:11:42 <pikhq> If you're on Gentoo, add -msse3 to your CFLAGS and recompile your stuff. ;)
17:11:54 <pikhq> gcc (GCC) 4.1.2 (Gentoo 4.1.2 p1.0.2)
17:12:08 <AnMaster> gcc (GCC) 4.1.2 20070214 ( (gdc 0.24, using dmd 1.020)) (Gentoo 4.1.2 p1.0.2)
17:12:35 <pikhq> Yeah, GCC newer than 3.something uses -msse3.
17:14:04 <AnMaster> I wonder, should I use gcc __builtin__ stuff for vector addition
17:14:55 <AnMaster> real 0m0.107s <-- and that is with profile generation code heh not using the profile feedback
17:15:20 <AnMaster> real 0m0.104s using profile data
17:15:32 <AnMaster> oh and this is using the flush the way ccbi does it
17:15:58 <pikhq> Yeah, add -msse3 to your CFLAGs.
17:16:04 <pikhq> Should make your vector code faster.
17:16:11 <pikhq> (read: single operation. ;p)
17:16:44 <AnMaster> pikhq, well I actually do it like this now:
17:17:12 <AnMaster> ip->position.x += ip->delta.x * steps;
17:17:12 <AnMaster> ip->position.y += ip->delta.y * steps;
17:18:40 <AnMaster> pikhq, for the required part of mycology test suite
17:18:48 <AnMaster> average is still around 0.104 or so
17:20:48 <AnMaster> pikhq, btw this is using 32-bit data types
17:21:56 <pikhq> I bet caching is a bit harder with 64-bit data types or something. . .
17:21:58 <Deewiant> AnMaster: I'm just happy that I'm only about 25% slower given that I implement much more than you do :-)
17:22:19 <pikhq> Especially since you're on a Sempron.
17:22:20 <AnMaster> Deewiant, well that is with reflecting on fingerprints I assume
17:22:26 -!- slereah__ has joined.
17:22:26 <pikhq> Those usually have somewhat small caches.
17:22:39 <AnMaster> cpu[1 x AMD Sempron(tm) Processor 3300+ (AuthenticAMD) @ 2.00GHz w/ 128 KB L2 Cache]
17:23:03 <pikhq> My Sempron is a 2800+.
17:23:08 <Deewiant> AnMaster: sure, but there's still a lot of overhead just from the fact that fingerprints and mini-funge exist at all, whether they're enabled or not
17:23:18 -!- slereah_ has quit (Read error: 104 (Connection reset by peer)).
17:23:25 <Deewiant> AnMaster: and don't forget that I still do file IO there, since I have i and o. and then there's concurrency.
17:23:27 <AnMaster> Deewiant, not the way I plan to do it, if they are not enabled, do not check
17:23:44 <AnMaster> Deewiant, I know my hash table isn't very efficient
17:23:54 <AnMaster> and wrapping with cardinal could be made faster
17:24:09 <AnMaster> considering that I think mine still has potential
17:24:28 <Deewiant> I just use what's built-in to D, it's hardly optimal
17:24:32 <AnMaster> Deewiant, I'll do some gprof analysis later
17:25:06 <AnMaster> just I find gprof output exceedingly hard to parse
17:29:38 <Deewiant> you do realize there are frontends to gprof :-)
17:34:38 <AnMaster> Deewiant, I got an idea for how to make support for fingerprints almost as fast as without fingerprints when they are disabled
17:34:48 <AnMaster> instead of mapping each to reflect I got a better idea
17:38:17 <AnMaster> Deewiant, how does the last version perform for you now
17:38:36 <AnMaster> ccmake should now show a use 64-bit option
17:39:06 -!- sekhmet_ has joined.
17:41:04 -!- sekhmet has quit ("Reconnecting").
17:41:50 -!- sekhmet_ has changed nick to sekhmet.
17:42:55 <Deewiant> looks like it's about twice as fast as CCBI
17:49:40 <AnMaster> of course file IO would make it slower
17:50:32 <AnMaster> Deewiant, and I know the hash library I use is not very performant indeed
17:50:46 <AnMaster> and there is room for lots of optimizing in wrapping code
17:50:54 <Deewiant> AnMaster: it's probably more performant than the D internal one, which I know to be quite poor
17:51:25 <AnMaster> Deewiant, problem is, interally, the hash library mallocs once for each cell, to store some data
17:51:43 <AnMaster> if you compile with debug, you can see that from gdb, by doing: call GC_dump()
17:51:50 <AnMaster> A LOT of output of small allocations
17:54:06 <Deewiant> the D one probably does that too, although it might be smarter in that it allocates in blocks
17:56:01 <AnMaster> Deewiant, well the values I allocate in blocks, but the key data it does internally into small blocks
17:56:21 <AnMaster> I know a better hash library, but I think it may have license issues
17:57:28 <Deewiant> speaking of licenses, I don't see CCBI's license anywhere in cfunge08, although you've even copied a comment directly from it ;-P
17:57:49 <AnMaster> Deewiant, yes but isn't it BSD?
17:58:02 <Deewiant> yes, and what does the license say
17:58:15 <AnMaster> that means it is leegal to relicense it under GPL in fact, afaik?
17:58:17 <Deewiant> "Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer."
17:58:34 <AnMaster> Deewiant, I'll change the comment if you want though
17:58:37 <Deewiant> so just slap CCBI's license.txt in COPYING and you're good from my point of view
17:58:49 -!- sekhmet_ has joined.
17:59:23 <AnMaster> Deewiant, it is the 3-clause BSD license?
17:59:43 <AnMaster> the one with the advertisement rule?
18:00:25 <Deewiant> AnMaster: just cat COPYING license.txt > COPYING :-P
18:00:39 <AnMaster> Deewiant, afraid there may be an issue with doing that
18:00:46 -!- sekhmet has quit ("Reconnecting").
18:01:05 <AnMaster> Deewiant, would be confusing and probably not ok according to either your license or GPL
18:01:17 <Deewiant> AnMaster: no, that's exactly how it's done
18:01:31 <AnMaster> Deewiant, show me some other software doing that
18:01:34 -!- sekhmet_ has changed nick to sekhmet.
18:01:42 <Deewiant> AnMaster: just say "cfunge08 uses some parts of stuff based on CCBI, which is licensed thus:"
18:01:45 <Deewiant> AnMaster: windows, for instance :-P
18:01:51 <Deewiant> AnMaster: it has parts of BSD's network stack
18:01:53 <AnMaster> Deewiant, well open source software doing it
18:02:31 <Deewiant> you want me to go through random src projects looking for something which uses multiple projects' code?
18:04:05 <Deewiant> AnMaster: http://www.j-dom.org/download/README for instance
18:04:12 <Deewiant> don't know what that is but it has it the way it should be
18:04:16 <Deewiant> "The Hypersonic SQL license means that we must include the following, which applies only
18:04:21 <AnMaster> Deewiant, just rewrote comment locally anyway before you mentioned it her
18:04:38 <AnMaster> // The weird stuff below, is, as described by CCBI:
18:04:39 <AnMaster> // Instruction executes *at* k
18:04:39 <AnMaster> // If the instruction k executes, changes delta or position, we are finished.
18:04:39 <AnMaster> // If it doesn't we should jump to *after* the instruction k executed.
18:04:45 <Deewiant> AnMaster: but you've still been reading my source and basing much of your stuff on it :-)
18:04:59 <AnMaster> Deewiant, yeah, true, and will even more for fingerprints
18:05:28 <AnMaster> Deewiant, problem is, it's hard to pinpoint where exactly is steeling your stuff
18:05:40 <AnMaster> a line or algorithm here and there
18:05:49 <Deewiant> AnMaster: so just say "some of this stuff, you don't need to care what"
18:09:55 -!- slereah_ has joined.
18:09:55 -!- slereah__ has quit (Read error: 104 (Connection reset by peer)).
18:14:20 <AnMaster> Deewiant, pushed change. Hope you are now happy
18:16:18 <AnMaster> 606128 00000000 00000000 00000000 00000000 ................
18:16:18 <AnMaster> 606138 305e6000 00000000 0^`.....
18:17:16 <pikhq> And string constants.
18:17:29 <pikhq> s/constant/literal/
18:19:12 <AnMaster> pikhq, btw I looked at the gcc -S output for the optimized binary and compared with the -O0 one
18:19:23 -!- sebbu has joined.
18:19:28 <AnMaster> in the optmized almost all lines are just register operations
18:19:48 <AnMaster> in the -O0 one, there is a lot of push and pop
18:27:05 <oklopol> does anyone compile befunge
18:27:40 <Deewiant> I found a reference to a "real" befunge compiler on google but the page is gone
18:28:06 <oklopol> it might be quite simple, but you need to do compilation at runtime too
18:28:34 <oklopol> do making a native compiler would basically require you to include something like gcc
18:28:44 <oklopol> in every runnable prog that is
18:32:20 <AnMaster> oklopol, JIT should be possible
18:33:24 <AnMaster> oklopol, indeed, do one if you want
18:33:32 <AnMaster> you would be even faster than mine :)
18:33:43 <AnMaster> of course you need to pass mycology as well
18:34:32 <Deewiant> "MCBC is an MS-DOS only Befunge-93 compiler"
18:34:34 <lament> there was ajti befunge compiler
18:34:58 <AnMaster> Deewiant, I doubt it supports p
18:35:33 <AnMaster> without p (or in 98, s as well) it would be doable
18:35:34 <Deewiant> AnMaster: all the pages which link to it say it's fine
18:35:43 <oklopol> AnMaster: for almost all programs, there will be no compilation at runtime.
18:35:47 <lament> oklopol: the wiki page actually talks about compilation
18:35:55 <oklopol> it's just programs that require it can always be writen
18:36:02 <lament> "The Betty compiler, for example, treats every possible straight line of instructions as a subprogram, and if a p instruction alters that subprogram, that subprogram is recompiled."
18:36:06 <AnMaster> oklopol, I use p a lot in my code
18:36:23 <oklopol> AnMaster: do you change code at runtime?
18:36:27 <lament> i was going to write a befunge compiler like that
18:36:35 <Deewiant> that appears to be the only reference to betty, though :-/
18:36:43 <AnMaster> oklopol, yes in befunge I would
18:37:29 -!- faxathisia has joined.
18:38:25 <AnMaster> hm true just standalone interpreter/code bundler
18:38:33 <lament> with befunge you can do either threaded code or JIT
18:38:44 -!- ehird has joined.
18:38:53 <AnMaster> lament, threaded code would be same as interpreter?
18:39:00 <ehird> i just came up with awesome ideas for the underload compiler \o/
18:39:11 <lament> AnMaster: interpreter is a main loop that looks at individual instructions
18:39:26 <lament> AnMaster: threaded code is each instruction is a piece of executable code, that executes and then passes control to the next instruction
18:39:43 <ehird> AnMaster: not weird
18:40:00 <ehird> AnMaster: forths uses it
18:40:03 <ehird> the firs tforth, for example :)
18:40:07 <ehird> so it dates back to at least the 70s
18:40:15 <ehird> but not in the 'new and crazy' sense
18:40:19 <lament> it's the normal way to compile forth, and it's how my brainfuck to smetana compiler worked :)
18:40:21 <AnMaster> actually you don't need to compile befunge, you can just make a CPU that executes befunge
18:40:30 <ehird> AnMaster: why do you think forths are really, really damn fast?
18:40:35 <ehird> because of threaded code, mainly.
18:40:43 <ehird> (and the whole 'damn minimal semantics' thing)
18:40:52 <lament> forth is such a lovely language. i wish it were usable.
18:40:55 <AnMaster> http://www.forthfreak.net/index.cgi?BashForth
18:41:07 <ehird> AnMaster: gosh, I wonder
18:41:17 <ehird> lament: insert oblig. factor propaganda here
18:41:25 * ehird reads reddit too much, mind b0rken :(
18:41:38 <ehird> StringThreadedCode
18:41:56 <lament> ehird: http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=bigforth&lang2=gcc
18:41:59 <lament> ehird: i have looked just a little at factor, and it seems to be much less lovely
18:42:00 <ehird> you just basically store the code
18:42:13 <ehird> lament: well duhhhh
18:42:15 <ehird> i mean traditional forths
18:42:23 <ehird> and also never compare anything to gcc
18:42:31 <ehird> gcc has millions of people micro-optimizing it
18:42:35 <AnMaster> Deewiant, I'm working on fingerprints atm, well mine will be virtually as fast when they are disabled, and even virtually as fast as long as no finger print is loaded, but it will be slower if they are loaded, then on same speed as CCBI I guess
18:42:36 <ehird> it will always win :)
18:42:39 <lament> bigforth is on optimized compiler
18:42:44 <ehird> you don't need that
18:42:47 <ehird> i mean traditional, old forth compilers
18:42:48 <lament> besides forth is really low-level
18:42:59 <lament> you should be able to hand-optimize
18:43:02 <Deewiant> AnMaster: all depends on what fingerprints you implement. :-)
18:43:06 <ehird> lament: not the point
18:43:08 <ehird> bad compiler choice.
18:43:22 <AnMaster> Deewiant, yes indeed, but I mean fingerprint mechanism in general
18:43:27 <ehird> i am talking about old, traditional forths
18:43:30 <ehird> they -are- blazing
18:43:34 <lament> ehird: you're saying biforth is worse than those?
18:43:50 <lament> and i'm not even gonna correct that typo
18:44:08 <ehird> lament: it doesn't even use threaded code
18:44:10 <ehird> from what i can see
18:44:48 <lament> bigforth website is amazing
18:44:56 <lament> it was created in 1997 and the design was never changed
18:45:03 <lament> so in that way, it's like Factor :)
18:45:11 <ehird> lament: factor had a redesign like a year ago
18:45:26 <lament> ehird: http://factorcode.org/slava/
18:45:56 <ehird> lament: oh, yes, that.
18:46:04 <ehird> (i am assuming you know that was created *recently* :p)
18:48:11 <ehird> translating functional stuff to a c-style syntax is amusing
18:48:15 <ehird> U[] map(U(T) func, T[] lst)
18:48:40 * AnMaster is still wondering about a befunge CPU
18:49:01 <ehird> AnMaster: not very interesting, really
18:49:08 <ehird> you'd need to translate it to 1d before execution
18:49:39 <AnMaster> it could represent memory as 2D
18:50:09 <AnMaster> you could make a custom computer architecture for it
18:50:53 <AnMaster> Deewiant, what is the point of the NULL fingerprint?
18:51:48 <Deewiant> AnMaster: easy unloading of whatever's currently loaded?
18:51:57 <ehird> behh, I have to write a b98 interp now
18:52:04 <ehird> Deewiant: is it painful or just tedious :(
18:52:04 <AnMaster> Deewiant, but whatever is currently loaded would be loaded under
18:52:17 <AnMaster> ehird, why do you want to write one? :/
18:52:17 <Deewiant> ehird: I found it quite fun, actually
18:52:22 <Deewiant> ehird: but some of the fingerprints were painful
18:52:25 <ehird> AnMaster: why do you?
18:52:29 <ehird> Deewiant: TIME TRAVEL!
18:52:32 <Deewiant> AnMaster: I mean load whatever, then unload NULL
18:52:35 <Deewiant> ehird: yeah, that one in particular.
18:52:43 <ehird> Deewiant: it'll be a fun day with \8, I guess. Or do you really need ncurses?
18:53:05 <Deewiant> only if you implement the NCRS fingerprint :-)
18:53:24 <AnMaster> ehird, and yes quite fun apart from three things 1) stack stacks 2) wrapping 3) y instruction
18:53:32 <ehird> Deewiant: hmm. doesn't that require interpreter support?
18:53:36 <AnMaster> fingerprints I'm working on atm
18:53:39 <ehird> Deewiant: like, you can't just ad-hoc add it
18:53:42 <ehird> you must design for it
18:53:54 <AnMaster> ehird, you could ad-hoc NCRS I think
18:54:09 <Deewiant> ehird: ncurses, or fingerprints
18:54:39 <ehird> -- also jeez, befunge 98 needs a gc?
18:54:44 <ehird> this'll be tons of fun ;)
18:54:50 <ehird> (of course I will write my own! :p)
18:54:56 <Deewiant> ehird: the interface is such that the befunge program starts up NCRS, so it can be added "ad-hoc"
18:55:01 <Deewiant> ehird: and no, you don't need GC
18:55:02 <AnMaster> ehird, however two things I can see would require redesign: time travel, and the hover mode stuff,
18:55:15 <AnMaster> ehird, why would you need a gc?
18:55:22 <AnMaster> it is just that a gc is so much easier
18:55:38 <Deewiant> AnMaster: remap instructions, like swap 5 and 4 for instance :-)
18:55:49 <AnMaster> Deewiant, ok won't do that one then
18:56:02 <Deewiant> AnMaster: but "redesign" is a bit overstating it, I think
18:56:10 <ehird> AnMaster: I thought you hated gc
18:56:16 <ehird> Deewiant: eh, that's not too hard
18:56:19 <ehird> just more indirection! ;)
18:56:19 <AnMaster> ehird, I hate it with GUI apps
18:56:26 <Deewiant> they just need adding data to the IP structure and some extra handling in all instruction execution
18:56:30 <ehird> AnMaster: change of heart
18:56:50 <AnMaster> ehird, or rather, I love it when it works, and hate it when it doesn't
18:57:19 <AnMaster> Deewiant, anyway anything requireing any exensive core change I won't do
18:57:39 <Deewiant> and "extensive" is a bit pushing it, as well :-)
18:57:50 <Deewiant> MODE is somewhat extensive for queue and insert mode
18:58:28 <AnMaster> and I will continue to do that for anything but A-Z
18:58:32 <Deewiant> AnMaster: basically it's "instruction = ip.mappings[instruction];"
18:58:45 <Deewiant> before you head in the switch-case
18:58:47 <ehird> Deewiant: how many fprints does ccbi implement?
18:58:52 <AnMaster> Deewiant, yes and that would make it slower :/
18:59:04 <Deewiant> ehird: all that I know of except WIND and SGNL
18:59:11 <ehird> Deewiant: what does TURT use?
18:59:12 <Deewiant> and TERM on non-Windows, unfortunately
18:59:36 <AnMaster> Deewiant, you said it in your readme
18:59:42 <ehird> Deewiant: oh sheesh
18:59:46 <Deewiant> AnMaster: crap indeed, it contradicts the spec
18:59:53 <Deewiant> ehird: I found it the easiest option actually
18:59:56 <ehird> mine will be EXTENSIVEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE
19:00:06 <ehird> Deewiant: mine will do SDL, SVG, PNG, ... :D
19:00:26 <AnMaster> ehird, just FILE and let befunge program output those themself
19:00:38 <AnMaster> ehird, however do NOT change specs for TURT
19:00:45 <ehird> totallyfreakingawesomebefunge98 --fprint=TURT,--sdl
19:00:52 <ehird> AnMaster: ehm, why would i need to
19:00:56 <ehird> just a command line op as you see there :D
19:01:01 <ehird> of course --fprint will be a horrible hack
19:01:05 <AnMaster> ehird, allow the program to set output type?
19:01:09 <ehird> --fprint=NAME,FOO...
19:01:12 <ehird> replaces , with ' ' in FOO
19:01:17 <ehird> parses the options
19:01:22 <ehird> and sends them off to NAME finger print
19:01:27 <ehird> AnMaster: thank god
19:01:41 <ehird> AnMaster: that's ridiculous
19:01:45 <ehird> bsds implement it nowadays
19:01:56 <AnMaster> lament, hah not sure about that
19:02:03 <AnMaster> ehird, what language will you code yours in?
19:02:15 <ehird> AnMaster: writing one in python with numpy for fungespace at first
19:02:21 <ehird> micro-optimized, of course.
19:02:31 <ehird> i hope to have the ugliest sprawling mass of befunge interpreter that exists
19:02:34 <ehird> AnMaster: K&R represent!
19:02:46 <ehird> --fprint=TURT,--svg=foo.svg,--sdl # MULTIPLEXINGF
19:02:50 <AnMaster> ehird, offers some nice restrict keywords to ehird for further micro-optimizing
19:03:02 <ehird> AnMaster: __asm__ represent
19:03:11 <ehird> AnMaster: x86 represent
19:03:16 <AnMaster> ehird, if it doesn't work on amd64 as welll
19:03:23 <ehird> AnMaster: 286 represent
19:03:28 <AnMaster> ehird, look my current one can use 32-bit numbers if you want
19:03:39 <ehird> AnMaster: NIH represent
19:04:33 <AnMaster> Deewiant, anyway I'm wondering about a 128 bit integer mode, iirc there is some __int128 type of gcc?
19:05:06 <ehird> does the spec permit bignums?
19:05:20 <AnMaster> ehird, as long as you can say how many bytes it is
19:05:22 <ehird> so like all programs would break?
19:05:26 <Deewiant> but it is explicitly said that it's allowed
19:05:36 <ehird> Deewiant: will programs break, though
19:05:36 <AnMaster> ehird, well that's my plan as well
19:05:50 <ehird> extend the numbers
19:05:51 <Deewiant> pushing -1 would kinda suck for programs that test for a minimum size of 6, for instance :-)
19:05:52 <ehird> so you can say infinity
19:06:12 <ehird> Deewiant: but seriously -- do programs tend to assume infinite bitsize?
19:06:30 <AnMaster> ehird, they tend to assume 32-bit or better I think
19:06:33 <Deewiant> I guess most programs would be happy with 16-bit integers :-P
19:06:55 <AnMaster> Deewiant, not sure, you would need to store handprints and such in one
19:07:09 <Deewiant> ehird: I'm not sure what you mean by 'tend to', since there aren't that many written programs ;-)
19:07:11 <AnMaster> ehird, btw, the handprint CFUN is in use
19:08:01 <Deewiant> there's already been a fingerprint overlap, two different SOCKs
19:08:04 <AnMaster> ehird, in my funge08 specs that I'm working on I decided to allow trinary funge or in fact n-nary funges
19:08:24 <AnMaster> Deewiant, we really need a new register
19:08:29 <Deewiant> AnMaster: but fortunately the only difference is that one includes SCKE and the other doesn't
19:08:43 <ehird> AnMaster: mine was called cfunge before yours :
19:08:55 <ehird> i named it while tyou were just considering bash
19:09:01 <Deewiant> AnMaster: adds a few funcs, meant to be used in conjunction with SOCK
19:09:02 <ehird> so nyah, CFUN is miiine :D
19:09:10 <AnMaster> ehird, nop, I already had planes on cfunge back then
19:09:13 <Deewiant> meh, awfully creative names there :-P
19:09:19 <ehird> AnMaster: welp, sorry, i'd already had a directory up
19:09:21 <AnMaster> ehird, anyway mine is released
19:09:31 <AnMaster> ehird, and CFUN is my handprint
19:09:52 <ehird> no.. i had the directory tree and handprint before, just not released
19:10:05 <ehird> ('tough for me' -- I guess the befunge police are going to raid my house)
19:10:15 <ehird> handprints & fingerprints are broken anyway.
19:10:21 <ehird> they're centralized and overlaps are too easy.
19:10:30 <AnMaster> ehird, well just call your CBEF
19:10:33 <ehird> a URI would be nicer
19:10:37 <ehird> AnMaster: nooo, you do that :D
19:10:46 <ehird> http://elliotthird.org/b98/cfunge
19:10:51 <AnMaster> I plan to provide unefunge version
19:10:52 <Deewiant> AnMaster: I agree with ehird, the whole handprint/fingerprint mechanism is a bit messed up, shouldn't need centralization
19:10:57 <Deewiant> but I don't know if it can be solved well
19:11:00 <ehird> AnMaster: well, I am supporting N-dimensionals
19:11:07 <ehird> AnMaster: 404, gosh really
19:11:09 <ehird> that was an example URIprint
19:11:17 <AnMaster> ehird, yes that would be a good idea
19:11:36 <ehird> AnMaster: anyway, since i support any N dimensions, I have the right to CFUN
19:12:41 <ehird> Deewiant: URIprints might be a bit verbose though
19:13:14 <Deewiant> and they can overlap as well, just takes time
19:13:30 <ehird> Deewiant: no, that's not the point
19:13:42 <ehird> URIs specific purpose are unique, global identifiers
19:13:58 <ehird> what's better, sometimes they're URLs. then humans can utilize them -- like loading it via http
19:14:02 <Deewiant> yes, they should be that, but they aren't always :-P
19:14:14 <ehird> Deewiant: sure, but it is far better than the current system
19:14:26 <ehird> besides, the odds of clashing and then someone else doing a different ext --- it is just far too unlikely :)
19:14:40 <ehird> here is what would cause a clash
19:14:46 <ehird> - someone releases an ext under a uri
19:14:57 <ehird> - it is a very very common uri
19:15:00 <ehird> - someone else thinks it's good
19:15:05 <ehird> now I dunno about you but that seems HIGHLY unlikely
19:15:06 <AnMaster> ehird, good idea, one for my funge08 specs
19:15:12 <ehird> in the case where it's a URL:
19:15:18 <ehird> - someone has a URL probably on a domain
19:15:33 <ehird> - the domain expires --NOTE AT THIS POINT THE URI IS STILL FINE! It's not a URL, even if it's identical.
19:15:53 <AnMaster> ehird, along with gnirtsn (string with size in front)
19:15:53 <ehird> - someone else gets it, also a befunger
19:15:53 <ehird> - they make another fprint
19:15:53 <ehird> - and release it under the same uRI
19:15:57 <ehird> both of those will basically never happen
19:16:02 <Deewiant> because, in 99% of cases, they will be URLs.
19:16:13 <ehird> the likelyhood of the above
19:16:37 <ehird> ccbi.d:319: Error: cannot implicitly convert expression ((helpRegex.test)(s)) of type int to bool
19:17:17 <Deewiant> 4.1 doesn't mean anything, which version of GDC is it :-)
19:17:44 <ehird> gdc (GCC) 4.1.3 20070831 (prerelease gdc 0.25, using dmd 1.021) (Ubuntu 0.25-4.1.2-16ubuntu1)
19:17:49 <Deewiant> could be too new a tango, actually
19:17:51 <ehird> Deewiant: it had some ncurses foobar but that doens't happen now
19:17:55 <ehird> the tango is the latest
19:18:15 <AnMaster> ehird, cfunge 0.1.0 released, just making a tar ball for it
19:18:16 <Deewiant> nope, test should return bool still
19:18:22 <ehird> AnMaster: tough. CFUN is mine
19:18:50 <ehird> AnMaster: because denying something i said on irc will cause the befunge police to come and get me? :)
19:19:03 <Deewiant> ehird: that's /all/ it says? if so, just put cast(bool) before it and hope it works :-P
19:19:50 <ehird> AnMaster: Well, just because you're an ass and didn't ask the channel if anyone had used the fingerprint before using it, won't stop me using it..
19:20:12 <ehird> well then, now i am
19:20:20 <ehird> also, sorry for not being present 100% of the time
19:20:32 <ehird> it takes about 10 keypresses to tap over a string literal.
19:20:54 <ehird> AnMaster: release is made!12121
19:21:03 <ehird> it is now set in stone, and i will just have to weep, because i wasn't there.
19:21:07 * ehird = horror and shame
19:21:43 <Deewiant> what's with all the trolling :-P
19:21:51 <ehird> Deewiant: reactionary trolling
19:22:28 <ehird> welp, i'll keep using CFUN, because i've been using it for longer than AnMaster has, and just because i wasn't there on one specific date doesn't mean that he now has the right to it
19:22:43 <ehird> if AnMaster would like to complain, maybe he could move to a fingerprint that wasn't in use when he chose it
19:22:50 <Deewiant> timestamps or it didn't happen
19:22:58 -!- olsner has joined.
19:23:14 <Deewiant> except that the damn things can be falsified, d'oh
19:23:27 <ehird> Deewiant: I don't think thoughts can be timestamped. however, if he had asked earlier, I would have been happy to tell him that yes, it was in use.
19:23:52 <AnMaster> http://rage.kuonet.org/~anmaster/cfunge/
19:24:10 <ehird> AnMaster: 'my heart has been ripped out and filled with dread. I think I will cry myself to sleep.'
19:24:15 <ehird> i am not sure what kind of response you are aiming for.
19:24:41 <AnMaster> ehird, that no one complained when I announced I would use CFUN
19:25:00 <ehird> AnMaster: because I wasn't here. does this kind of thing not process for you?
19:25:01 <AnMaster> Deewiant (iirc, or maybe ais<number here>, even said it was a good choice)
19:25:09 <ehird> i can hardly say it was in use when I wasn't there
19:25:17 <ehird> and expecting me to and using that as justification is ridiculous
19:25:44 <AnMaster> ehird, same is expecting me to believe you actually had selected than handprint before
19:25:58 <ehird> AnMaster: uh, yes i did
19:26:14 <ehird> (other response that you seem to expect: 'YES! It is a befunge conspiracy of epic proportions. how did you figure me out?!')
19:26:14 <AnMaster> expecting me to and using that as justification is ridiculous
19:26:36 <Deewiant> AnMaster: I grepped the logs, a quick check suggests he's said nothing of the kind
19:27:07 <ehird> Deewiant: that is correct.
19:27:25 <ehird> Deewiant: I do not see why I would mention it when the question of usage was not asked.
19:28:04 <AnMaster> mar 11 18:50:24 <Deewiant> CFUN eh
19:28:04 <AnMaster> mar 11 18:50:33 <AnMaster> Deewiant, er yes?
19:28:04 <AnMaster> mar 11 18:50:36 <AnMaster> is it in use?
19:28:04 <AnMaster> mar 11 18:50:47 <Deewiant> don't think so
19:28:04 <AnMaster> mar 11 18:51:02 <Deewiant> most use BEF or something instead of FUN
19:28:05 <AnMaster> mar 11 18:51:14 <AnMaster> FUN as in FUNGE
19:28:22 <Deewiant> yeah, I said I don't think it's in use
19:28:50 <Deewiant> you can't expect people to be watching IRC all the time
19:28:53 <AnMaster> ehird, you haven't announced the handprint before either btw
19:28:57 <ehird> [18:28] <Deewiant> you can't expect people to be watching IRC all the time
19:29:27 <ehird> and there is absolutely no way I can prove that I had CFUN before you, because that's physically impossible
19:29:44 <ehird> the only thing you can do is make the assumption that i'm not lying for the fun of it, and believe it
19:29:51 <ehird> or.. decide that i must be lying
19:29:57 <ehird> for some crazy reason
19:30:02 <AnMaster> ehird, but you got a suggestion for other handprint
19:30:24 <AnMaster> and would still work with the name cfunge
19:30:35 <ehird> AnMaster: no it's not. you suggested CBEF
19:30:42 <ehird> it is an N-funge interpeter.
19:30:54 <AnMaster> ehird, and I don't like that much, because I will add more dimensions
19:30:59 <ehird> besides, CFUN is fine and I was using it prior to you.
19:31:09 <ehird> why should i have to change the fingerprint that I already used?
19:31:47 <Deewiant> ehird: for what it's worth if it's only in your head, I'd suggest it was in fact AnMaster who "was using it"
19:32:03 <ehird> Deewiant: well, no. it is probably somewhere on my harddrive
19:32:15 <AnMaster> Deewiant, but released *shrugs*
19:32:18 <ehird> still, the point is -- if I was there when he asked, I could have honestly answered 'yes. it's in use.'
19:32:32 <ehird> AnMaster: sticking a tarball on http is not a way to seal your ownership of something..
19:32:38 -!- jix has joined.
19:37:27 <Deewiant> and in any case, I'd say whoever releases something first is the one who can claim rights to the name
19:37:37 <Deewiant> but whatever, fight it out amongst yourselves :-P
19:37:45 <AnMaster> Deewiant, I'm not going to fight
19:38:11 <Deewiant> ehird: since you're going bignums why not just make the handprint "CFUNGE", nobody's claiming they have to be 4 bytes :-)
19:38:15 <AnMaster> I don't simply care of ehird wants the name, he didn't announce it, nor release it, first
19:38:37 <ehird> AnMaster: I'll just state that I was going to use CFUN before you even started working on Bashfunge, and will continue using it. there is nothing to do with 'wanting the name' because I'll just release with it.
19:38:46 <ehird> You can argue with that if you'd like; fin
19:39:20 <AnMaster> ehird, anyway I'm also using the name cfunge for the interpreter, or cfunge08, both are valid names for it
19:40:24 <ehird> AnMaster: Why not use CF08?
19:40:39 <ehird> Since you're not implementing strict Funge-98, you indicate that it's your standard.
19:40:56 <AnMaster> ehird, maybe, I will implement strict 93, 98 and 08
19:41:08 <AnMaster> I already got some code in place for it
19:41:20 <ehird> AnMaster: well, the interpreter is called cfunge08 is it not?
19:41:24 <ehird> therefore, CF08 is a good fingerprint
19:41:39 <AnMaster> ehird, it is, but well <Deewiant> ehird: for what it's worth if it's only in your head, I'd suggest it was in fact AnMaster who "was using it"
19:41:45 <AnMaster> ehird, <Deewiant> and in any case, I'd say whoever releases something first is the one who can claim rights to the name
19:41:54 <AnMaster> you don't accept those arguments of Deewiant ?
19:42:45 <Deewiant> Deformative: got a spec written yet?
19:43:18 <ehird> AnMaster: so even sayiung that CF08 is a good handprint, you don't want to use it because..
19:43:30 <AnMaster> ehird, because I'm convinced of what Deewiant said
19:43:44 <AnMaster> ehird, CF98 would be good for your one in that logic
19:43:51 <ehird> AnMaster: hardly..
19:44:04 <ehird> because all currennt fingerprints are funge-98 ones
19:44:09 <ehird> so yours is the one that needs explicit clarification
19:44:13 <ehird> besides, mine isn't called cfunge98
19:44:15 <AnMaster> ehird, anyway 98 is the standard mode for me
19:44:16 <ehird> yours IS called cfunge08
19:45:46 <Deformative> Deewiant: http://deformative.hosting.arsfides.com/upload/files/1/spec.txt
19:46:53 <Deewiant> "ignored args" - ah, of course, I was wondering how that'd look otherwise :-)
19:59:02 <Deformative> Reordering the args is quite an interesting problem.
19:59:19 <Deformative> Discussed it for a long time yesterday if you have logs.
20:15:34 <ehird> # define UL_DISCARD foo = UL_stk->prev; free(UL_stk->top); free(UL_stk); UL_stk = foo;
20:15:40 <ehird> write that without the temp var'foo'
20:15:54 <ehird> impossible i think
20:17:16 <Deformative> ehird: Did you see the challenge from yesterday?
20:20:10 <Deewiant> ehird: if you're feeling lucky, just remove foo and then do UL_stk = UL_stk->prev at the end ;-)
20:20:33 <Deewiant> it'll probably work in most cases
20:20:39 <Deewiant> and crash the program in others ;-)
20:21:02 * ehird is rewriting the Underload2C prelude
20:26:25 -!- slereah__ has joined.
20:28:21 -!- slereah_ has quit (Read error: 104 (Connection reset by peer)).
20:35:15 <slereah__> http://members.iif.hu/visontay/ponticulus/images/szovegek/begriffsschrift.jpg
20:35:34 <slereah__> For some reason, this notation was never used again, as far as I know!
20:39:31 <ehird> ' Please insert your fruit here.'
20:39:37 <ehird> that's what i'm putting in the prelude for the compiler to replace
20:39:57 <AnMaster> <Deewiant> it'll probably work in most cases
20:39:57 <AnMaster> <Deewiant> and crash the program in others ;-)
20:40:19 <AnMaster> Deewiant, it would crash in cases where the system mmap mallocs
20:40:35 <AnMaster> like both glibc (for larger objects) and openbsd (for all objects) does
20:41:09 <ehird> hmm, that IS one thing the world needs...
20:41:18 <ehird> symntax for template sin c commands
20:41:41 <ehird> AnMaster: 'templates'
20:41:45 <ehird> syntax for templates in c commands
20:41:50 <ehird> i.e. a widely accepted way to do it
20:41:56 <AnMaster> ehird, there are no templates in C afaik?
20:42:07 <ehird> AnMaster: not C++ templates you dummy
20:42:09 <ehird> /*$ foo */ means 'replace this comment with the value of foo'
20:42:30 <ehird> AnMaster: haahahahahaha
20:42:34 <ehird> I mean for interpolating from EXTERNAL sources.
20:42:40 <ehird> Like the underload compiler does its compiler
20:42:44 <ehird> then stuffs it into the prelude
20:42:46 <ehird> at the right place
20:42:53 <ehird> I could put /*$ blimps */ in the prelude
20:42:59 <ehird> Then, it would do something like:
20:43:12 <ehird> interpolate textOfPrelude [("blimps",compiledCode)]
20:43:23 <ehird> and then that marker would be transformed into the compiled blimps
20:43:50 <ehird> AnMaster: 'i am going to tell you to use #define and be confused about your idea, then just say "whatever" when it is complained'
20:44:12 <AnMaster> ehird, no, I just gave up trying to understand it
20:44:21 <ehird> interpolate textOfPrelude [("blimps",compiledCode)]
20:44:31 <ehird> textOfPrelude = "void foo() { /*$ blimps */ }"
20:44:31 <AnMaster> ehird, you replace text at a marker?
20:44:38 <ehird> compiledCode = "foobar"
20:44:46 <ehird> "void foo() { foobar }"
20:44:50 <ehird> so, just a regular template language
20:44:55 <ehird> BUT, it's in c comment syntax
20:45:03 <ehird> so its highlighted correctly
20:45:06 <ehird> and is still valid C etc
20:45:16 <ehird> AnMaster: it's just like how /** ... */ is accepted as docs
20:45:18 <ehird> and highlighted thus
20:45:30 <AnMaster> ehird, bah /** */ is for doxygen iirc?
20:45:35 <ehird> AnMaster: no, everything
20:45:42 <ehird> emacs highlights /** */ differently
20:45:53 <ehird> it could do something similar for interpolation stuff
20:46:00 <ehird> the only problem is, /*$ ... */ is ugly
20:46:10 <AnMaster> ehird, but I only seen it used for doxygen comments
20:46:17 <ehird> /*$ blimps $*/ could work I guess
20:46:25 <Deewiant> use /*/ ... */ and confuse people
20:46:49 <ehird> is highlighted differently by gcc
20:47:16 <ehird> faxathisia: the underload compiler
20:47:29 <ehird> all the compiled blimps need to be stuffed into the right place in the prelude
20:47:36 <AnMaster> ehird, yes but why does emacs highlight /*< >*/ differently?
20:47:37 <ehird> i'm just devising a nice way for templating in C
20:47:40 <ehird> AnMaster: I have no goddamn idea
20:47:44 <ehird> but it works out nicely
20:47:50 <ehird> I could be even more fancy,
20:47:51 <AnMaster> ehird, it is probably used for something else
20:47:57 <ehird> and let the templating language do the numbering
20:48:35 <ehird> /*< foreach blimps blimp >*/ case /*< blimp.num >*/: /*< blimp.code >*/ break;
20:49:04 <ehird> faxathisia: so it stays valid c.
20:49:09 <ehird> well my example isn't valid
20:49:14 <ehird> it SCANS as valid c
20:49:22 <ehird> and editors highlight it OK
20:49:36 <AnMaster> ehird, anyway the reason for /*< >*/ by emacs, is PROBABLY it is already used
20:49:42 <ehird> AnMaster: who cares
20:49:47 <AnMaster> ehird, I suggest you check so there won't be a collision at least
20:49:56 <AnMaster> ehird, then just use /** */ for it :P
20:50:03 <faxathisia> it's more likely a bug in the hilighting
20:50:29 <AnMaster> then I will report that to emacs ppl so they fix it for next version :D
20:51:07 <ehird> /*< foreach blimps as blimp: 'case $blimp.num: $blimp.code break;\n' >*/
20:51:15 <ehird> i should just embed lua in there
20:51:59 <AnMaster> ehird, my emacs highlight it the same way btw
20:52:47 <AnMaster> emacs-22 does it differently though
20:53:14 <AnMaster> ehird, err wait, emacs-23 does it differently to, had wrong major mode
20:53:30 <AnMaster> ehird, I think I know what it is
20:54:23 <ehird> /*< for i=0,blimpc do out("case ", i, ":\n", blimps[i], "\nbreak;") end >*/
20:55:14 <AnMaster> ehird, anyway (real world example):
20:55:16 <AnMaster> size_t i_items; /**< The current number of items in the table */
20:55:35 <AnMaster> ehird, so just as a warning < already got a meaning in start of comments
20:56:03 <AnMaster> ehird, yes, but I think I've seen /*< too
20:56:15 <AnMaster> and emacs highlights /** the same way as /*<
20:57:56 <Deformative> ehird: http://deformative.hosting.arsfides.com/upload/files/1/spec.txt Sorry it took so long, I sorta fell asleep.
20:58:09 <AnMaster> Deewiant, should fingerprints be local to ip in concurrent funge?
20:58:25 <AnMaster> Deewiant, and, should they inherit over t?
21:00:05 <ehird> 070100002c0000000000000000000000000000000000000000000000000000000000dd8fff010000dd8f27000000fb02ef07000000fb01ef070000000000bc8f8800040000bc012f65746300
21:00:15 <ehird> hex of a VAX program to rename /tmp to /etc
21:00:47 <Deewiant> AnMaster: actually, the latter is unspecified
21:31:23 <pikhq> Looks like you guys are re-inventing Objective C. :p
21:43:35 <pikhq> Objective C is implemented as a fairly thin templating system over C. ;)
21:44:03 <ehird> (Though, of course, Objective-C doesn't actually compile into C..)
21:44:25 <pikhq> You can implement Objective C with just a preprocessor into C.
21:44:32 <pikhq> (GCC used to do just that)
21:44:53 <ehird> pikhq: Same with anything.
21:45:36 <pikhq> Objective C is, interestingly, a strict superset of C. . .
21:45:43 <ehird> pikhq: Not interestingly -- sanely.
21:45:52 <ehird> Objective-C is really well designed like that.
21:46:42 <ehird> I'm actually working on a little language which is the marriage of C and functional stuff
21:46:58 <ehird> faxathisia: in mine that's: (x) => { return ++x; }
21:47:03 -!- oerjan has joined.
21:47:33 <faxathisia> does it compile to ML or something? :P
21:47:38 <ehird> int (int x) => { return ++x; }
21:48:06 <ehird> faxathisia: I managed to find a anice way to represent generic types
21:48:07 <pikhq> ehird: You could actually probably get GCC to handle anonymous functions with ease. . .
21:48:11 <ehird> Here's id :: a -> a:
21:48:14 <pikhq> Already, they support *scoped* functions. ;)
21:48:16 <ehird> T id(T a) { return a; }
21:48:25 <ehird> That is, UpperCase = generic type.
21:48:31 <ehird> Looks C-ish, which is a Good Thing.
21:48:42 <ehird> Also, I decided that for passing around functions, Declaration Is Usage failed miserably.
21:48:46 <pikhq> int main(){int foo(int *bar){++*bar;};int baz=0;foo(&baz);}
21:48:58 <pikhq> ^ Perfectly valid GNU C, does what you expect.
21:48:59 <ehird> U[] map(U (T), T[])
21:49:10 <ehird> U[] map(U (T) func, T[] lst) // with arg names
21:49:17 <ehird> not sure about that function type syntax yet
21:49:26 <pikhq> faxathisia: Or -std=gnu99.
21:49:28 <oerjan> yeah, really first class closures requires GC
21:49:45 <ehird> I have both 'void' and 'unit' :-)
21:49:52 <ehird> mostly you use 'void' - for IO-only functions etc
21:50:00 <ehird> unit is just there for.. mathematical nicety, I guess.
21:50:22 <ehird> Oh yeah, and algebriac data types in da house.
21:50:49 <ehird> data LL<a> { nil, cons(a, LL<a>) }
21:50:55 <ehird> that raises problems with generic types
21:51:00 <ehird> But I don't want to use 'a
21:51:04 * oerjan considers that Haskell could have used Void instead of () for things like IO () if Void had been thought of at the time
21:51:21 <ehird> faxathisia: that's the new syntax for parametized types
21:51:26 <ehird> data LL a = Nil | Cons a (LL a)
21:51:29 <ehird> translated to haskell
21:51:35 <ehird> faxathisia: precedent in C-alikes: C++, Java
21:51:42 <ehird> it looks alright, anyway
21:52:20 <ehird> however, I do need to solve that generic thing
21:52:34 <ehird> data list_t<a> { nil, cons(a, list_t<a>) }
21:52:51 <ehird> data list_t<T> { nil, cons(a, list_t<T>) }
21:52:55 <ehird> data list_t<T> { nil, cons(T, list_t<T>) }
21:53:00 <ehird> that would produce
21:53:21 <ehird> list_t<T> cons(T, list_t<T>)
21:53:35 <ehird> faxathisia: I haven't figured out 'T a' vs 'T a()' yet.
21:53:44 <ehird> and the most elegant way to do it
21:53:59 <ehird> 'T a = b;' is short for 'T a() { return b; }'
21:54:08 <ehird> and zero-arg functions don't need () to call
21:54:39 <pikhq> GregorR: Convince him to stop.
21:54:45 <pikhq> Show him the ways of D.
21:54:56 <ehird> Heh, hardly. D is nothing like the thingy I'm making.
21:55:05 <ehird> And I've used D, thankyouverymuch. I didn't like it, really.
21:55:35 <faxathisia> also I beat a D coder in some contest using C...
21:55:44 <ehird> For a start, and completely unrelated to all the other, more significant problems --
21:55:47 <ehird> the syntax is awkward.
21:55:56 <ehird> It's like Perl, but with less symbols, making it even uglier
21:56:31 * pikhq goes off to try to install D
21:57:06 <ehird> pikhq: 'Tell him that D is so much better!' 'Hm, D, I should try that.'
21:57:10 <ehird> so many people like that :)
21:57:25 <pikhq> ehird: I was mostly joking, really.
21:57:40 <ehird> pikhq: Good. Well that was to GregorR anyway. :P
21:57:49 <pikhq> But, seriously, I should try D.
21:57:51 <ehird> faxathisia: any comments on T vs T()?
21:58:10 <pikhq> But something a bit more important.
21:58:16 <pikhq> I should make interrupts.
21:58:16 <ehird> faxathisia: heh, hardly.. :)
21:58:22 <ehird> faxathisia: dunno if I'll do continuations.
21:58:48 <ehird> (OCaml being the FP language that most resembles this one -- i.e. not pure, but not Lispy)
21:59:15 <ehird> faxathisia: Maybe I'll do it the dumb way (stack smashing)
21:59:25 <ehird> Also, the preprocessor is gone. # is still used though
21:59:34 <ehird> #import cont /* it would probably be this */
21:59:47 <faxathisia> well if anyone wants to use cpp they can do just that
21:59:47 <ehird> '#foo ...' at the start of a line means 'compiler directive foo: ...'
21:59:58 <ehird> which makes the distinction between code that will be compiled
22:00:08 <ehird> faxathisia: They should not -- this handles re-imports
22:00:15 <ehird> and you don't need to write a header file
22:00:19 <ehird> just: #export a b c d
22:00:35 <ehird> and when compiling it'll optionally generate an 'interface file' which gets installed
22:00:44 <ehird> which is like a header file, but far more compact
22:00:48 <ehird> and not valid code, of course
22:00:51 <ehird> and #import looks for them
22:01:18 <ehird> IF in $INCLUDEPATH (., <STUFF>, system dir), code file in $INCLUDEPATH
22:01:27 <ehird> & if the code file is not compiled it does it for you
22:01:33 <ehird> faxathisia: So yeah, down with cpp :p
22:02:07 <ehird> faxathisia: also, it would be 'T callcc(T (cont_t))'
22:02:24 <AnMaster> <pikhq> ehird: You could actually probably get GCC to handle anonymous functions with ease. . . <-- as long as it doesn't use trampolines in GCC, that needs executable stack iirc
22:02:25 <ehird> where cont_t = 'void (T)'
22:02:40 <ehird> T callcc(T (void (T)))
22:03:04 <ehird> faxathisia: Not a bad callcc signature I must say.
22:03:11 <ehird> In Haskell-style types that looks like
22:03:24 <ehird> callcc :: ((a -> ()) -> a) -> a
22:03:28 <ehird> which is far less easy to understand
22:03:35 <ehird> it's C-style but not C-ugly
22:03:47 <ehird> faxathisia: this will have support for declarative programming
22:21:23 * oerjan finds himself browsing the logs at 1 page per second
22:24:43 -!- Quendus has quit (Remote closed the connection).
22:26:26 -!- Quendus has joined.
22:26:55 <ehird> redrawerredrawers is a word
22:27:50 <oerjan> i find that slightly hard to believe
22:28:23 <oerjan> i didn't think English was quite that permissive
22:32:08 -!- atsampson has quit (Remote closed the connection).
22:32:20 -!- atsampson has joined.
22:37:18 -!- oklokok has joined.
22:37:36 <oklokok> ehird: parsed how exactly?
22:38:22 <ehird> oklokok: what parsed where what what and what and what
22:38:52 <oklokok> is that a noun meaning "those who draw that red, which describes those who draw red"
22:39:02 <oklokok> that word you said was a word
22:39:21 <ehird> oklokok: I don't know
22:39:23 <ehird> ubt it's in a word list
22:39:29 <ehird> and it can be typed on the left hand
22:39:35 <ehird> it is the REAL longest word that you can do that with
22:41:21 <oerjan> that abcdef -> bdeefa or whatever problem?
22:41:58 <oerjan> i also got a sense it might be easier than it looked at first
22:43:12 <Deformative> http://deformative.hosting.arsfides.com/upload/files/1/np.txt
22:46:16 <oklokok> actually the trivial solution is O(n^2)
22:47:18 <oklokok> go through the list as I, for each element go through the result list as J and if J should have I, put it there
22:48:35 <Deformative> And that would _not_ make optimal solutions.
22:48:51 <faxathisia> You should read Shin-Cheng Mu and Silvija Seres approach to the edit distance problem and other combinatoric optimization problems
22:49:09 <oklokok> [21:42] <Deformative> pikhq: You have a block of memory, and a new order, some locations are duplicated, some are no longer used, but they refill the same block, design an algorithm to find the least number of movements needed.
22:49:09 <oklokok> [21:43] <Deformative> So you have [a b c d e f] and it needs to be transformed to an arbitrary new order, for example: [a b e e f c]
22:49:09 <oklokok> [21:43] <Deformative> You have access to extra space.
22:49:24 <oklokok> Deformative: minimum space as in O(1) spae
22:50:13 <Deformative> Well, I don't think you quite get the goal.
22:50:21 <Deformative> So uh, you should read the whole txt file.
22:50:30 <Deformative> Because no one really got it until the end.
22:50:37 <oklokok> i guess, just thought that was the complete description
22:51:36 <ehird> I like this ciphery thingy:
22:51:39 <Deformative> oklokok: You misunderstand the goal, the goal is to create a program that generates a perfect set of instructions to reorder a block of memory to a new order.
22:51:47 <oklokok> what are the exact space and time? ordo bounds on the permutator and the algorithm creator?
22:51:49 <ehird> abcdefg -> acegfdb
22:52:07 <ehird> it makes most text look like line noise but *kind of* resembles the original text
22:53:56 <oklokok> Deformative: or is the goal to optimize for each? i'm fairly sure that cannot be done
22:54:16 <oklokok> the actual permutator must be *perfect*
22:55:35 <oklokok> it's still not clear to me, can the permutator access any amount of space? the task is trivial if it can
22:56:04 <oerjan> my intuition says it's O(n)
22:56:25 <oerjan> and with at most one extra temporary location used
22:56:45 <Deformative> You are writing a program that outputs a set of instructions.
22:56:51 <Deformative> The instructions it outputs must be perfect.
22:57:00 <oklokok> Deformative: yes, but what's *perfect*?
22:57:03 <Deformative> The instructions it output does one thing.
22:57:09 <oerjan> copy instructions, as few as possible, i take it
22:57:26 <oklokok> there will be exactly n moves with what i said right away
22:57:28 <oerjan> or does swap count as a single instruction?
22:57:46 <faxathisia> which is here http://citeseer.ist.psu.edu/468298.html
22:57:59 <oklokok> ofc not, you don't always have to do even that
22:58:44 <oerjan> ok so then my guess is you need a temporary location iff no letter disappears, in which case this is a permutation (oh, and not being the identity)
22:59:01 <oerjan> otherwise you can use any disappearing letter as scratch
23:00:03 <oerjan> ideally you want all copies to be a letter moved to its final location, if possible
23:00:10 <oklokok> i'm fairly sure it's not *np*, at least
23:00:59 <ehird> my encoding mehtod, if anyone didn't immediately get it
23:01:04 <Deformative> I just need to figure out how I want to optimize for swapping, if I just use pure mov on the memory, then I am done.
23:01:14 <oerjan> when do you _have_ to move a letter other than to its final destination? when there is a permutation cycle
23:01:24 <ehird> enc a:b:xs -> [a]++enc xs++[b]
23:01:38 <oerjan> you must do this once for each cycle
23:01:40 <Deformative> You generate code that will move the letters.
23:01:46 <oerjan> Deformative: i mean copy
23:02:01 <slereah__> "Schönfinkel himself contrives a more drastic but very curious reduction of C, S and U. He adopts a new function J, interpreted as having U as value for C as argument, C as value for S for argument. Then he defines "S" as "JJ", "C" as "JS", and "U" as "JC". This trick reduces every closed statement (of logic and set theory) to a string of "J" and parenthesis."
23:02:22 <oerjan> Deformative: um generating code is trivially equivalent to finding out how to do it with copying
23:02:42 <Deformative> oerjan: The only time you need to move other than the final destination is a swap.
23:03:10 <Deformative> Unless I decide to use a register instead.
23:03:36 <oerjan> Deformative: yes. and i think you only need one swap per permutation cycle in the problem
23:03:52 <slereah__> faxathisia: I bought the fucking 650 pages specially for that article
23:04:00 <slereah__> Though the rest is pretty cool too.
23:04:25 <oerjan> although that might not be quite well-defined. hm.
23:04:47 <Deformative> This is quite confusing, but really not that complicated once I put it in code.
23:06:06 <slereah__> I was trying to see by hand what that function is doing
23:06:10 -!- adu has joined.
23:06:17 <slereah__> But I must be retarded, since I created a language for that.
23:06:18 <oklokok> how do you do it? i think my current solution is perfect in terms of moves, but it uses a call stack
23:07:09 <oerjan> oklokok: um the call stack is irrelevant to the final generated copies?
23:07:25 <oklokok> oerjan: i meant the programs generated need a call stack
23:07:33 <oklokok> actually not, of course not
23:07:40 <oklokok> second order programming is confusing
23:08:34 <oklokok> how about infinite order programming where the result program is the fixed point?
23:09:21 <ehird> faxathisia: functions taking/returning functions that take/return functions
23:09:44 <ehird> N-order functions are functions taking/returning (N-1 order functions).
23:09:53 <lament> so like, Haskell for Dummies? :)
23:10:06 <faxathisia> sounds like common practice in haskell
23:10:22 <lament> faxathisia: i'm using lisp! this sucks.
23:10:40 <oerjan> my guess is that the number of copies required = n + (number of cycles length > 1) - (number of letters that remain at their original place)
23:10:46 * faxathisia isn't much interested in what langs people don't like
23:11:03 <adu> faxathisia: I like Fortress
23:11:13 <oerjan> but it's still vague in my mind
23:11:40 <adu> http://fortress.sunsource.net/
23:11:55 <adu> its like Fortran+OCaml+Mathematica
23:12:03 <oklokok> actually optimizers can be done with something like a fixed point of an infinite order program
23:12:16 <oklokok> faxathisia: i meant generating code
23:12:29 <oklokok> n-order code generates (n-1)-order code
23:13:45 <oklokok> hmm, wonder if i should actually explain something
23:13:55 <oklokok> say you write a program that does task T
23:14:07 <oklokok> if you write a program that writes a program to solve T
23:14:15 <adu> Is there anywhere that has short descriptions of programming languages?
23:14:30 <oerjan> ooh wait a complication - if some letter of a cycle is duplicated, you don't need to use swap for that cycle
23:14:33 <faxathisia> I tell people, stop wastingt your time with that silly task you write the same program with different variables every weex
23:15:08 <faxathisia> and tell him just write a script to generate your program, and this guy is like O-o why don't you write a program to write for me
23:15:16 <faxathisia> as if this kind of task is impossible :P
23:15:33 <oerjan> so make that number of totally isolated cycles
23:15:57 <oklokok> in a good language, you can usually just do the metaprogramming in the same program
23:16:04 <oklokok> and just separate the conceptual levels
23:16:53 <adu> oerjan: what?
23:17:07 <adu> o descriptions
23:17:22 <faxathisia> you ever wrote your own macro system in lisp?
23:18:27 <ehird> Deewiant: you said a hash table is a good choice for fungespace
23:18:30 <oklokok> hmm, basically, i think the problem of permutating the variables basically comes down to a topological sort (in our case we're not sorting an acyclic graph, that's where we need the extra variable)
23:18:34 <ehird> what about an N-dimensional sparse array? :D
23:18:56 <lament> faxathisia: are macroexpansion rules written in lisp?
23:19:00 <adu> FungeSpace doesn't resemble a hash table AT ALL
23:19:01 <slereah__> I like that Schönfinkel. He's got the eso spirit.
23:19:30 <adu> well it depends on what the indexing domain is
23:19:42 <adu> if anything FungeSpace could only be indexed by polynomial-like objects
23:19:58 <ehird> adu: CCBI uses a hash table.
23:20:01 <adu> because (1, 0) == (1, 0, 0)
23:20:12 <oklokok> adu, just omit zeroes in the end
23:20:20 <oklokok> also, funge uses a fixed dimensino
23:20:24 <adu> oklokok: but thats not how arrays work, thats how polynomials work
23:20:43 <oklokok> adu: i don't see your point
23:21:23 <ehird> Deewiant: away again? :p
23:21:31 <ehird> [22:21] [Away] Deewiant is away: Zzz.
23:21:36 <oklokok> but yeah, true, polynomials are great for addressing an n-dimensional position, in case you don't have a fixed number of dimensions
23:21:46 <ehird> adu: what about a sparse N-dimensional array
23:21:49 <ehird> does that sound like a good fungespace :)
23:22:07 <ehird> (I am supporting N-funge :D Just need to figure out how to represent N>2 in text, eh.)
23:22:12 <adu> oklokok: my point is thhat (1, 0) and (1, 0, 0) are clearly distinct both in the array view and the vector view, but they are equivalent as FungeSpace indexes, and because they are only place they have this uniqueness is in FungeSpace, the only conclusion that makes sense is that they are an innapropriate metaphor for FungeSpace indecies
23:22:15 <oklokok> ehird: sparse array is a loose concept
23:22:22 <ehird> oklokok: your mom is sparse
23:22:26 <ehird> and a loose concept
23:23:12 <ehird> maybe I should use a Judy Array
23:23:17 <oklokok> adu: okay, a hashtable is bad for FungeSpace in case the implementer has no idea what dimensions are, true.
23:23:51 <ehird> http://judy.sourceforge.net/doc/JudyL_3x.htm
23:24:25 <adu> Polynomials: 1 + 0x == 1 + 0x + 0x^2 both mathematically, and in FungeSpace, so it is quite appropriate
23:25:05 <oklokok> adu: true, i never said it wasn't, i'm just saying it's very irrelevant
23:25:35 <ehird> adu: but yeah. sparse N-dimensinoal array == good fungespace?
23:25:44 <oklokok> well, i guess it was a good point polynomials are perfect indices for n-dimensional arrays
23:25:50 <adu> ehird: pretty much
23:26:21 <faxathisia> polynomials of degree <= n = tuples of length n
23:26:41 <oklokok> ehird: but isn't "sparse array" just a term specifying the problem, not a solution?
23:26:49 <ehird> oklokok: I think numpy has something for it. :|
23:26:58 <adu> but just as with arrays, there are mathematical constructs that limit the degree/length... o well
23:26:59 <ehird> And also when I do my C impl
23:27:04 <ehird> Judy arrays seem interesting: http://judy.sourceforge.net/doc/JudyL_3x.htm
23:27:54 <ehird> adu: any thoughts on judy arrays?
23:27:55 <faxathisia> It's a fundamental theorem in vector spaces
23:28:08 <adu> ehird: i'm reading
23:28:11 <faxathisia> (I just can't remember the name of it :S)
23:28:14 <oklokok> faxathisia: but i'm guessing you need to be doing it (mod something)
23:29:00 <faxathisia> http://www.mathreference.com/top-ban,rn.html
23:29:18 <oerjan> faxathisia: basis theorem perhaps?
23:30:00 <oerjan> although i may have made up that name on the spot
23:30:40 <adu> i think Glib hash tables are slightly more useful
23:30:42 <adu> http://library.gnome.org/devel/glib/stable/glib-Hash-Tables.html
23:30:56 <oklokok> oerjan vaguely knows everything
23:31:10 * oerjan vaguely knew oklokok would say that
23:31:52 <ehird> adu: fungespace consists of 0-255, right?
23:32:10 <adu> ya one byte per index
23:32:17 <oerjan> or rather there is something like invariant basis size property - it is true for vector spaces but not for modules over all more general rings
23:32:44 <adu> although i think it is allowed to grow past 255 during computation, the 255 restriction is on source files iirc
23:33:29 <ehird> adu: up to what value?
23:33:34 <ehird> the general befunge 'word'?
23:33:59 <adu> "What size exactly is left up to the implementer. 32 bits is typical."
23:34:48 <oklokok> it's like two years since i coded in a language without bignums :<
23:34:51 <oerjan> 'alf a bit, and a trit hand a half
23:35:00 <oklokok> well, except java, but i don't count that as a language, or as programming
23:35:15 <oerjan> surely java has bignums... somewhere
23:35:18 <adu> oklokok: why do you say that?
23:35:42 <oklokok> oerjan: sure, but you can't overload operators, so they're not that fun to use
23:35:52 <adu> oklokok: amen
23:35:58 <oklokok> i'm less productive in it than i am in befunge
23:36:08 <oklokok> and i've written one befunge program, and about 200 java progs
23:36:32 <oklokok> well, naturally that was helluva overstatement, but considering what befunge is, it's too true.
23:36:43 <adu> both Java and C# would be so great if they were designed and developed by opensource ppl from the beginning
23:37:03 <oklokok> (the productivity thing was an overstatement, that is)
23:37:19 <AnMaster> <ehird> adu: fungespace consists of 0-255, right?
23:37:50 <adu> but alas the great giants have spoken, and now we must suffer or use C
23:38:10 <AnMaster> Funge-98 source files are made up of Funge characters. The Funge-98 character set overlays the ASCII subset used by Befunge-93 and may have characters greater than 127 present in it (and greater than 255 on systems where characters are stored in multiple bytes; but no greater than 2,147,483,647.) The Funge character set is 'display-independent.' That is to say, character #417 may look like a squiggle
23:38:10 <AnMaster> on system Foo and a happy face on system Bar, but the meaning is always the same to Funge, 'character #417', regardless of what it looks like.
23:38:39 <ehird> and the spec is free
23:38:48 <ehird> and so is dmd/s frontend
23:38:51 <AnMaster> oklokok, the frontend yes, the backend no, but someone took the frontend and made it usable with gcc
23:38:53 <ehird> but the backend contains e.g. code form other sources
23:39:03 <ehird> oklokok: 'gdc yes'
23:39:14 <ehird> AnMaster: yep - that's gdc
23:39:20 <ehird> oklokok: but since ther eis a formal spec..
23:39:26 <ehird> and a free implementation
23:39:32 <ehird> the only non-free bit is the dmd backend.
23:39:42 <ehird> & it can't legally BE free atm
23:40:24 <AnMaster> <adu> although i think it is allowed to grow past 255 during computation, the 255 restriction is on source files iirc
23:41:15 <adu> I think we should reimplement all UNIX in D or Factor or Haskell
23:41:39 <ehird> you don't have to do any command line checking -- you know the file you get will be correct
23:42:11 -!- jix has quit ("CommandQ").
23:42:29 <AnMaster> ehird, no more crashes, because crashes are side effects, they wouldn't be allowed in haskell XD
23:43:04 <ehird> AnMaster: Well presumably you'd have the IO monad somewhere. :P
23:43:07 <AnMaster> anyway I'm getting fingerprints working in cfunge now
23:43:12 <ehird> But it is true that haskell should not crash.
23:43:20 <ehird> But when you get low-level..
23:43:35 <AnMaster> ehird, yet the most unstable irc bot I've seen, is one written in haskell, it is crashing a lot
23:43:58 <AnMaster> called lambdabot iirc, used in #friendly-coders
23:44:05 <oklokok> perhaps you should see oklobot
23:44:19 <oklokok> it's in C++, and it doesn't hide it!
23:44:28 <AnMaster> debugging wtf is going on with loading and unloading fingerprints in cfunge
23:44:35 <ehird> haha, lambdabot is great
23:44:38 <oklokok> AnMaster: lambdabot is great
23:44:40 <ehird> AnMaster: dude, lambdabot is really solid code
23:44:51 <faxathisia> lambdabot is probably the most useful bot in existence
23:44:59 <ehird> AnMaster: its Cale's fault
23:45:02 <ehird> he sucks at keeping it up
23:45:02 <AnMaster> ehird, ok, the one with the nick lambdabot however seems to crash a lot
23:45:24 <ehird> He also breaks random things. :)
23:45:36 <ehird> AnMaster: the nick 'lambdabot' on freenode host
23:46:15 <ehird> AnMaster: yea. blame cale
23:46:22 <oerjan> yeah lambdabot does crash :(
23:46:24 -!- adu has quit ("Computer went to sleep").
23:46:35 <ehird> AnMaster: THE NICK LAMBDABOT ON FREENODE'S HOST
23:46:49 <AnMaster> ehird, so the bot crashes because of the bot?
23:46:50 <oerjan> it did so long before cale took over recently though
23:47:03 <ehird> AnMaster: The bot crashes because of the guy who runs the instance that goes on freenode
23:47:32 <ehird> oerjan: still not really lambdabot code's fault in most cases ;)
23:47:36 <AnMaster> <AnMaster> and who is cale <ehird> AnMaster: THE NICK LAMBDABOT ON FREENODE'S HOST <-- sounded to me like the bot was cale
23:47:48 <AnMaster> instead of cale being the owner of the bot