01:47:20 -!- andreou has quit ("let me go forth to recreate my sleep.").
02:03:24 <fizzie> Did some befunge syntax-highlighting to my universal turing machine thing: http://gehennom.org/~fis/utm.bef -- the code is still very much unoptimized. :/
02:03:45 <fizzie> That's not syntax-highlighted at all.
02:04:02 <fizzie> http://gehennom.org/~fis/utm.html was the URL I was aiming for. I'm not sure if the fancier things work at all with a non-firefox browser.
02:05:50 -!- kipple has quit (Read error: 110 (Connection timed out)).
02:14:53 <graue> that makes me happy, fizzie
02:38:01 <graue> a non-gecko browser, you mean
06:39:10 -!- mtve has joined.
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
12:09:48 -!- kipple has joined.
15:24:44 -!- andreou has joined.
16:14:14 -!- Keymaker has joined.
16:15:50 <Keymaker> looks like interesting stuff fizzie, although i haven't tried :)
16:39:04 -!- tombom has joined.
16:42:37 <graue> would you contribute content to an esoteric language wiki, Keymaker?
16:55:00 <Keymaker> (sorry about delay, i was getting ice cream from store)
17:50:12 <Keymaker> NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
17:50:18 <Keymaker> aaaaaaaaaaaaaaaaaaaaaaaaaaarrrrrrrrrgggggghhhhhhhhhh
17:50:45 <Keymaker> nooooooooooo no no no non ono no non on onon
17:52:20 <Keymaker> the "core" for my lbfc solution today
17:52:55 <Keymaker> and i realized the error just after completing it..
17:53:09 <Keymaker> time to rewrite the s**t again
17:53:26 <Keymaker> (and no, i don't have the first working version anymore)
17:53:35 <Keymaker> that's why one always should take backups
17:53:44 <Keymaker> i never do, and i've pretty often regretted that
17:56:17 <Keymaker> maybe there isn't logical error afterall
17:59:23 <Keymaker> NNNNNNNNNNOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
18:00:10 <Keymaker> but now it thing it's just because coding error
18:01:34 <Keymaker> but it is REALLY ANNOYING when you have A LOT brainfuck instructions in front of your face and you gotta find some ERROR that causes F***ING OVERFLOW somewhere....
18:01:59 -!- Keymaker has left (?).
18:06:25 -!- tombom has quit (Read error: 104 (Connection reset by peer)).
18:46:42 -!- andreou has quit ("let me go forth to recreate my sleep.").
20:04:17 -!- Keymaker has joined.
20:08:15 <Keymaker> "Good shit, huh? Dozer makes it. It's good for two things: degreasing engines and killing brain cells."
20:20:49 -!- lament has quit (Read error: 110 (Connection timed out)).
20:23:41 <graue> anyway, if anyone wants to contribute to the wiki, it's at http://esoteric.voxelperfect.net/
20:23:45 <graue> i wrote some shit there to start it off
20:49:14 <kipple> The wikipedia is already a good esolang wiki, though...
21:21:22 <graue> wikipedia doesn't like esolang stuff and wants to delete all of it for nonnotability
21:22:05 <Keymaker> i try to contribute something sometime
21:23:53 <Keymaker> on a sidenote, that is entirely unrelated to this matter, my third version of the input system doesn't work.............
21:24:19 <Keymaker> i start to be slightly annoyed
21:36:17 <graue> say, C isn't turing-complete, is it?
21:36:39 <graue> because according to the spec, sizeof(void*) must be finite
21:38:23 <Keymaker> but naturally i hope it is not turing-complete :)
21:38:44 <Keymaker> that's feature of more elegant languages.. (brainfuck)
21:45:53 -!- Keymaker has left (?).
22:16:24 <kipple> interesting :) do you have a link to a formal specification of C?
22:17:17 <fizzie> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n843.htm has the latest C99 draft that's legally freely available.
22:17:27 <fizzie> It's quite close to the actual standard.
22:17:35 <fizzie> Probably "close enough" for most uses.
22:19:26 <fizzie> The actual standard could possibly be found in the interweb, too, but officially it costs few $s.
22:20:50 <kipple> anyway, I don't see why it can't be turing-complete because of sizeof.
22:21:36 <fizzie> If sizeof(void *) is finite, there's (possibly; haven't thinked this through) no (standard) way to access infinite amounts of memory.
22:22:22 <kipple> wouldn't a linked list do the trick?
22:23:00 <fizzie> A linked list still needs pointers to the elements, and there are only 2^(sizeof(void *) * CHAR_BITS) unique memory addresses those can be in.
22:25:24 <fizzie> "Each such allocation shall yield a pointer to an object disjoint from any other object." says the spec about malloc and other dynamic memory allocation functions. That means there's at the very least an upper bound of possible malloc()-allocated objects, and those have finite size too.
22:25:46 <kipple> yes but that only deals with RAM
22:26:26 <kipple> the memory demanded by turing-completeness could be harddrives or tape
22:27:30 <kipple> it shouldn't be a problem having a C program read from an infinite tape stream, just like a turing machine. Or am I missing something here??
22:28:07 <fizzie> Depends on how the standard specifies "fsetpos()/fgetpos()". If those are required to work for all files, it imposes an upper limit for random-access-files.
22:29:46 <kipple> anyway, this is pretty academic, as there doesn't exist, and never will, an implementation of ANY language that is turing complete :)
22:30:01 <fizzie> Not sure if an implementation with infinite-size files (that could be used with fseek(..., SEEK_CUR) commands) would be C-standards-conforming.
22:30:42 <kipple> but all input doesn't have to come from random access files
22:31:02 <kipple> user input, for instance is theoretically infinite
22:31:32 <fizzie> Input, yes, but a Turing machine needs a seekable and rewritable "something" for the tape.
22:31:55 <kipple> but it doesn't need setpos/getpos
22:32:44 <fizzie> Yes, but C standard doesn't have that kind of streams. There's fseek(), though.
22:33:00 <fizzie> ... hmm, I wonder if outputting "Dear User, please remember the following values" would be considered cheating.
22:36:58 <fizzie> Aw, dang. For a FILE object (which is the only seekable thing in standard C except memory) the standard defines: "-- fpos_t which is an object type other than an array type capable of recording all the information needed to specify uniquely every position within a file." (And fpos_t has finite size - all objects do.)
22:38:24 <fizzie> Oh well. C is a low-level language anyway.
22:40:55 <lindi-> nothing stops you from writing libinfinitetape that offers moveleft(), moveright(), writebyte() and readbyte() :)
22:41:06 <fizzie> That's not standard C, though.
22:41:38 <kipple> if you can write it with standard C it is, but apparently you can't...
22:42:04 <fizzie> It should be noted that Java has the same _crippling_ problem.
22:42:22 <kipple> how is that crippling?
22:42:35 <fizzie> It's not, that's why it was underlined.
22:43:01 <kipple> ah. I interpret underlines differently than you then :)
22:43:53 <kipple> to me that would mean emphasis on the word, as in REALLY crippling...
22:43:55 <fizzie> (Streams aren't seekable, and RandomAccessFiles have a file pointer of only 64 bytes. I'm not sure if a standard Java implementation could provide an infinite amout of objects, though.)
22:44:20 <kipple> no implementation of anything can do that
23:09:31 <graue> couldn't you use new an infinite number of times?
23:21:34 <kipple> how would you make an infinite "tape" what way?
23:24:30 <fizzie> As far as I see, a (doubly-)linked list would work in Java-language (when looking at the Java language specification book), but an infinite tape in Java-VM (as specified by the Java Virtual Machine Specification) wouldn't be possible.
23:25:24 <kipple> but the Java VM is not the language. you could implement java without it.
23:25:39 <kipple> or does the spec require a VM?
23:26:04 <fizzie> The language probably doesn't. I'm not awake enough to read all the details.
23:26:39 <fizzie> I'm not even sure if the VM spec goes low-level enough that it would limit things. It seems to only speak of a dynamic-sized heap.