00:02:54 -!- ShadowHntr has joined.
00:04:37 -!- sebbu has quit ("@+").
00:06:28 -!- ShadowHntr has quit (Client Quit).
00:09:37 <Sukoshi> Any people willing to help with the parser?
00:21:46 <Sukoshi> But yacc isn't a person :P
00:23:07 <bsmntbombdood> o speed the messaging process, the runtime system caches the selectors and addresses of methods as they are used
00:23:40 <bsmntbombdood> so searching through the superclasses only happens once
00:24:02 <Sukoshi> I guess we should write sample code before we judge.
00:27:37 -!- atrapado has quit (Read error: 110 (Connection timed out)).
00:35:36 <ihope_> OSKit sounds like a useful thing.
00:41:16 <bsmntbombdood> http://svn.gna.org/viewcvs/gnustep/libs/libobjc/trunk/objc/
00:52:39 -!- EgoBot has quit (K-lined).
00:52:40 -!- GregorR has quit (K-lined).
00:54:15 <ihope_> ...Uh, did GregorR just get K-lined?
00:55:11 <Sukoshi> That's one of my problems. ObjC has almost no development going in it.
01:03:53 -!- calamari has quit ("Leaving").
01:13:23 <bsmntbombdood> it would be nice if instance variables were dynamic like messages are
01:19:24 <bsmntbombdood> You can't access instance variables if the object is typed id
01:19:26 <bsmntbombdood> http://svn.gna.org/viewcvs/gnustep/libs/libobjc/trunk/sendmsg.c?rev=22341&view=auto
01:20:47 <Sukoshi> Well that's because it's a class object then.
01:26:25 <bsmntbombdood> I think the message sending function looks up the method from a linked list of methods
01:28:11 <Sukoshi> I would hope so, because you can make a tree based on parameters.
01:29:10 <Sukoshi> Wait. Nevermind. I was thinking of the system I had in mind.
01:29:36 <bsmntbombdood> objc_class has both a objc_method_list*, a aaray, and a sarray*, a hash table/sparse array
01:30:52 <Sukoshi> So, are we using libobjc from GCC or GNUStep ?
01:31:14 <Sukoshi> Are we using Foundation from GNUStep or just subclassing from libobjc?
01:32:53 <Sukoshi> Are we going to use Foundation stuff?
01:33:56 <Sukoshi> Now. Cellular Automata VM?
01:35:07 <oerjan> i assume you mean Virtual Machine rather than Virtual Memory?
01:40:44 <Sukoshi> We'd have to create a set of assembler commands that can define cellular automata.
01:41:11 * oerjan ponders adding extra time dimensions to ALPACA.
01:41:31 <ihope_> I don't think cellular automata are imperative.
01:42:15 <ihope_> Just build a universal constructor and have the program be instructions to it.
01:42:18 <oerjan> (and space dimensions too, of course)
01:43:20 * oerjan envisions an ALPACA bytecode would do.
01:44:04 <oerjan> the cellular automaton description language
01:44:24 <ihope_> http://esoteric.voxelperfect.net/wiki/ALPACA
01:44:55 <Sukoshi> Wait. Is this a practical project? :P
01:45:12 <oerjan> ALPACA has already been implemented.
01:45:13 <ihope_> Once "Game of Life" hardware becomes common, you'll really want that constructor stuff.
01:45:22 <ihope_> (And "once" is just my fancy way of saying "if".)
01:45:38 <oerjan> i guess it could be a practical project.
01:45:52 <Sukoshi> That's a fancy way of saying no, isn't it?
01:47:41 * oerjan generally says no to projects. Or at least his hands do.
01:49:10 <bsmntbombdood> I wonder what the best way to implement a sparse array is
01:49:22 -!- calamari has joined.
01:52:39 <oerjan> insert "balanced" at appropriate spot.
01:52:59 <oerjan> then remove "O(n) worst".
01:53:55 -!- ShadowHntr has joined.
01:54:08 <oerjan> which they probably would be if read from a file. But if you know they are sorted you can use a different algorithm.
01:55:30 <oerjan> making the tree balanced immediately.
01:55:45 <ihope_> (I saw the accidental "ly" before I sent that, but I decided to leave it in.)
01:55:58 <ihope_> Of course, it's about Abrasax, not this, so... yah.
01:58:42 <oerjan> recursively: make 2^n-1 first elements into one subtree, then read middle, then 2^n-1 next into another, then put together.
02:01:19 -!- calamari has quit ("Leaving").
02:03:18 <oerjan> if you are going to worry about log n, then you need to read serious literature, not ask on IRC. :)
02:03:48 <oerjan> unless you find a channel with the real experts.
02:04:48 <oerjan> chances are at that level you need to worry about things like cache behavior.
02:05:00 -!- graue has joined.
02:05:30 <ihope_> Did you hear about GregorR getting K-lined?
02:05:31 <graue> oh, i wondered why you were incredulous
02:05:46 <ihope_> What's this about incredulity?
02:06:36 <ihope_> graue: what's this about incredulity?
02:06:50 <graue> since you said hello with a question mark, i thought you were like "what?! GRAUE is here?! how can this be!!!"
02:07:01 <Pikhq> Gregor got K-lined?1?
02:07:06 <graue> also, i need to learn to use my irc client, because i just answered you in a different channel
02:07:13 <oerjan> Ave Graue, Morituri Te Salutant!
02:07:21 <oerjan> or something like that
02:07:40 <graue> why'd that happen?
02:07:47 <ihope_> Apparently it was for spamming.
02:08:21 -!- jix has quit ("Bitte waehlen Sie eine Beerdigungnachricht").
02:09:05 <ihope_> Ah, indeed, an EgoBot bug may cause spamming.
02:09:28 <ihope_> Rather, may have caused.
02:10:56 <bsmntbombdood> "Broken client, apparently .. not sure the details", "I'm speculating, but usually that reason means it was disconnecting/reconnecting/etc.. or joining/rejoining/etc.."
02:12:12 <ihope_> Apparently you got a better answer than I did.
02:12:29 <oerjan> but there were no disconnections before the k-line.
02:13:32 <ihope_> That'd be join/part stuff, then, which EgoBot doesn't do.
02:13:46 <graue> you guys have too much free time.
02:13:58 <graue> freenode people aren't arbitrary
02:14:04 <graue> i'm sure gregor can work it out with them
02:14:18 <ihope_> Well, the freenode person did say "usually".
02:14:28 <ihope_> Would the freenode people not being arbitrary mean it wasn't bot spam that caused this?
02:16:24 <ihope_> But if GregorR's been K-lined for EgoBot, I'm surprised you haven't been K-lined for bsmnt_bot or something. :-)
02:16:54 <Pikhq> ihope_: Not been reported for spamming.
02:17:03 <Pikhq> bsmntbombdood: Nor was EgoBot.
02:17:21 <ihope_> ~exec while 1: __import__("time").sleep(2); self.raw("PRIVMSG ihope_ :Ya!")
02:17:41 <bsmnt_bot> 0: 'while 1: __import__("time").sleep(2); self.raw("PRIVMSG ihope_ :Ya!")', 18.34 seconds
02:17:52 <ihope_> Tell me how to kill it, will you?
02:18:29 <ihope_> I have UNFILTERED set.
02:19:13 <ihope_> ~exec while 1: __import__("time").sleep(2); self.raw("PRIVMSG ihope_ :Ya!")
02:19:27 <bsmntbombdood> :orwell.freenode.net 505 bsmnt_bot :Private messages from unregistered users are currently blocked due to spam problems, but you can always message a staffer. Please register! ( http://freenode.net/faq.shtml#privmsg )
02:19:46 <ihope_> Yeah, I'm thinking it's definitely the UNFILTERED.
02:25:35 <Sukoshi> In Curses, if you use mvwaddch, does it go to the absolute y and x, or relative to the origin of the window?
02:50:10 -!- ihope_ has quit (Connection timed out).
02:53:39 <oerjan> The routines prefixed with mv require a y and x coordinate to move to before performing the appropriate action. The mv routines imply a call to move before the call to the other routine. The coordinate y always refers to the row (of the window), and x always refers to the column. The upper left-hand corner is always (0,0), not (1,1).
03:40:19 <bsmntbombdood> We should design an esolang for human-human communication
03:43:03 -!- Pikhq has quit (Read error: 60 (Operation timed out)).
03:55:53 -!- bsmntbombdood has changed nick to xor.
04:08:21 -!- xor has changed nick to bsmntbombdood.
04:11:01 -!- Sukoshi has left (?).
04:56:03 -!- Bigcheesegs has joined.
05:14:09 -!- graue has quit (Read error: 110 (Connection timed out)).
05:46:58 -!- oerjan has quit ("leaving").
05:51:22 -!- digital_me has quit (Read error: 60 (Operation timed out)).
07:25:21 -!- Sgeo has quit (Read error: 104 (Connection reset by peer)).
07:38:59 -!- GreaseMonkey has joined.
07:54:50 -!- maverickbna has joined.
07:55:22 -!- maverickbna has quit (Client Quit).
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:12:59 -!- ShadowHntr has quit (Read error: 110 (Connection timed out)).
08:40:19 -!- GregorR-Foo has joined.
08:43:23 <GregorR-Foo> Idonno ... apparently spamming. I looked through all the logs for bots-gone-crazy, and there are none, so what the bork :(
08:43:36 <GregorR-Foo> All my logs suggest that I was not spamming.
08:43:59 <GreaseMonkey> hmm... what line did you get put onto? z-line? g-line?
08:44:45 <GreaseMonkey> if it was from more than a fortnight before you got the ban, someone hates you
08:49:08 <GreaseMonkey> actually: z-line = ip-block, g-line = ban-on-login
08:51:46 <GregorR-Foo> I don't know, that's what's so confusing - none of my logs have the actual K-line.
08:51:59 <GregorR-Foo> Just "disconnection", then upon reconnecting it says I'm K-lined.
08:52:30 <GreaseMonkey> i would advise a raw-log for next time something stupid happens
08:54:11 <GregorR-Foo> I doubt highly that the small area of messages that that would catch that I don't currently catch would help.
08:54:51 <GreaseMonkey> perhaps: ERROR :You have been K-Lined by renfield
08:55:17 <GreaseMonkey> (i picked renfield cos he's the worst ircop on bluehell)
08:56:26 <GregorR-Foo> The response will probably be: "Idonno, we don't log it. You'll be allowed to connect in seven years."
08:56:52 <GreaseMonkey> otherwise they should jack hyperion up the ass and switch to unreal
09:35:04 -!- sebbu has joined.
09:54:30 -!- GregorR has joined.
09:57:31 -!- Sephh has joined.
09:59:43 -!- Bigcheesegs has quit (Read error: 113 (No route to host)).
10:41:48 -!- meatmanek has quit (Connection timed out).
11:01:20 -!- GreaseMonkey has quit ("YAYS! I achieved something cool today!").
11:02:11 -!- meatmanek has joined.
11:04:50 -!- Pikhq has joined.
11:14:47 -!- ihope_ has joined.
11:36:01 -!- Pikhq has quit (Read error: 110 (Connection timed out)).
11:36:26 -!- nazgjunk has quit (Read error: 104 (Connection reset by peer)).
11:36:49 -!- nazgjunk has joined.
11:44:18 -!- jix__ has joined.
12:13:39 -!- ihope_ has quit ("http://tunes.org/~nef/logs/esoteric/06.08.09").
14:08:39 -!- nazgjunk has quit ("Bi-la Kaifa").
14:10:46 -!- nazgjunk has joined.
14:59:25 -!- sebbu has quit (Connection timed out).
15:07:11 -!- sebbu has joined.
15:29:09 -!- CRathman has joined.
15:47:11 -!- sebbu has quit ("reboot").
15:49:32 -!- nazgjunk has quit (Read error: 104 (Connection reset by peer)).
15:49:58 -!- nazgjunk has joined.
16:04:06 -!- sebbu has joined.
16:20:42 -!- jix__ has quit (Read error: 110 (Connection timed out)).
16:21:17 -!- jix__ has joined.
17:23:47 -!- Sukoshi has joined.
17:26:27 -!- jix__ has changed nick to jix.
17:42:03 -!- CRathman has quit ("ChatZilla 0.9.78 [Firefox 2.0.0.3/2007030919]").
17:46:14 -!- sebbu2 has joined.
17:53:19 -!- sebbu has quit (Read error: 60 (Operation timed out)).
18:21:19 -!- sebbu2 has quit (Connection timed out).
18:25:59 <bsmntbombdood> GregorR: I asked a staff they said it was probably spamming/client problems
18:28:39 <GregorR> bsmntbombdood: I also asked a staff (shocker)
18:36:14 -!- nazgjunk has quit (Client Quit).
18:36:45 -!- sebbu has joined.
18:38:16 -!- nazgjunk has joined.
19:00:31 -!- oerjan has joined.
19:35:02 -!- Pikhq has joined.
19:36:39 -!- sebbu2 has joined.
19:39:33 -!- atrapado has joined.
19:55:18 -!- sebbu has quit (Connection timed out).
20:25:05 -!- GregorR-Foo has quit ("leaving").
20:33:23 -!- sebbu2 has changed nick to sebbu.
20:50:48 -!- Sgeo has joined.
21:34:42 -!- nazgjunk has quit ("Bi-la Kaifa").
21:38:02 -!- nazgjunk has joined.
21:46:03 <Sukoshi> Did you see my ideas for an OO extension to C?
21:46:34 <GregorR> I was K-lined for no good reason, so I haven't seen anything in a while (I didn't log my other persona)
21:47:17 <Sephh> A usefull OO extention to C?
21:47:20 <Sukoshi> I've refined my idea. So here it is, it's a minimal extension to C to support OOP using generic functions.
21:47:34 -!- Sephh has changed nick to Bigcheesegs.
21:47:50 <Sukoshi> It adds 4 keywords to the language, ``generic'', ``specific'', ``class'', and ``continues''.
21:48:06 <Sukoshi> If you're familiar with the concept of generic function OOP....
21:48:22 * GregorR will read the log, must leave now.
21:48:27 <Sukoshi> ``generic'' defines a function generic ( generic void display(a, b); )
21:48:54 <Sukoshi> ``specific'' specialized on the generic ( specific void display (int a, char b); specific void display (int a, int b); )
21:49:19 <Sukoshi> ``class'' declares a class in struct form ( class Player { int xpos, ypos; } )
21:49:48 <Sukoshi> ``continues'' designates that the specialized generic function calls the next-less-specific specialized method for the generic it is assosciated too.
21:50:08 <Sukoshi> Very simple, and not very hard to implement, if only I knew the GCC parser-foo.
21:50:53 <Bigcheesegs> So is there a purpose other than just trying to create it? we already have c++ :P
21:51:07 <Sukoshi> Do you know what you're talking about?
21:51:27 <Sukoshi> C++ follows an incredibly different object model, is very unclean, and favors its own big/bulky style.
21:51:46 <Bigcheesegs> I don't find it that way, I think it's damn sexy.
21:52:25 <Sukoshi> You may like C++ and its ``Do Everything My Way or NULL way'' philosophy, but this is designed to be a very small extension to C.
21:52:47 <Sukoshi> And the C++ object model is message passing, so it has to have all this annoying stuff like polymorphism/operator overloading.
21:53:16 <Sukoshi> Something a C coder can pick up in a few minutes and work with, like everything else in the C language.
21:55:49 -!- crathman has joined.
21:56:43 -!- Sukoshi has left (?).
22:12:05 -!- Sukoshi has joined.
22:30:57 -!- nazgjunk has quit ("Bi-la Kaifa").
22:32:23 -!- nazgjunk has joined.
22:32:32 -!- nazgjunk has quit (Read error: 104 (Connection reset by peer)).
22:39:31 -!- jix has quit ("Bitte waehlen Sie eine Beerdigungnachricht").
22:49:56 -!- nazgjunk has joined.
22:54:12 -!- ihope has joined.
23:05:00 -!- nazgjunk has left (?).
23:17:39 <Sukoshi> bsmntbombdood: Not all that difficult.
23:19:18 <Sukoshi> bsmntbombdood: Classes are just structs with type information. Generic methods are determined and then less-specific behavior is inlined if the function is ``continues'', and these are all kept either in a virtual method table or a tree that matches based on parameter.
23:19:55 <Sukoshi> Oh, I think we need an ``inherits'' keyword too, to subclass.
23:20:28 <Sukoshi> Subclassing basically copies the fields of the super-class's struct directly into the derived class.
23:20:40 <bsmntbombdood> so with a generic call, the compiler looks up the correct method based on the objects' type?
23:21:16 <Sukoshi> The runtime has to be able to keep type information.
23:21:29 <Sukoshi> Well, actually no it doesen't.
23:21:52 <Sukoshi> We can parse it so that arguments to generics are wrapped in structs that contain type information.
23:22:16 <bsmntbombdood> defining a method uses some kind of name mangling, then at compile time method(object) is replaced with <object type>_method(object)
23:23:13 <oerjan> not always possible to do at compile time
23:23:55 <oerjan> because the actual object might be of a subclass.
23:25:05 <bsmntbombdood> if you type an object as one of its superclasses, you can only call methods defined in its superclass
23:25:38 <oerjan> sure, but the actual version of the method may be overridden by the subclass.
23:28:57 <Sukoshi> Remember, this is generic functions based. Subclasses don't override methods. If you mean it defines a wholly different specialization, then, so ?
23:29:06 -!- sebbu has quit ("@+").
23:30:10 <oerjan> however, the specialization depends on the actual runtime class, not the compile time class.
23:31:32 <oerjan> so it requires runtime information to select the right specialization
23:31:53 -!- crathman has quit ("ChatZilla 0.9.78.1 [Firefox 2.0.0.3/2007030919]").
23:35:41 <Sukoshi> Inheritance only pulls in fields of the parent struct.
23:36:43 <bsmntbombdood> Well there's no point if it requires runtime support
23:38:11 <Sukoshi> Unless we restrict it away from runtime changing classes.
23:38:21 <Sukoshi> So your classes can't be dynamic.
23:38:50 <Sukoshi> Specifying classes during runtime == dynamic.
23:39:32 <Sukoshi> Then it should be fine still.
23:40:09 <oerjan> wait a minute. do you mean that a subclass object cannot be passed as an object of the superclass?
23:41:01 <Sukoshi> Haven't you played with CLOS, oerjan ?
23:41:24 <oerjan> but common lisp is dynamically typed...
23:41:28 <Sukoshi> Quick overview of a generic method system.
23:41:49 <Sukoshi> Classes only hold slots, basically struct fields.
23:42:16 <Sukoshi> Generic functions are defined that only define the number of arguments (and in this case the return type) of a function.
23:43:10 <Sukoshi> After, you define specific implementations of the generic function based on different types. In this case, if you define that specialized function with the keyword ``continues'' it automatically calls the assosciated specialization for the next-less-specific specialization.
23:43:47 <Sukoshi> To simplify things, I want no multiple inheritance, because I can see maybe only a few rare cases where multiple inheritance works, and it's cleaner to simulate it with abstract classes.
23:43:53 <oerjan> all of this makes perfect sense with dynamical typing, but not with static typing.
23:44:09 <Sukoshi> But why wouldn't it work with static typing?
23:45:10 <oerjan> well it would work like haskell typeclasses, but not like an object-oriented system.
23:45:16 -!- atrapado has quit ("a tra pa da").
23:45:56 <Sukoshi> But when using C, 9/10 the only reason you need OOP is to manage state and to abstract away method calls to superclasses.
23:46:02 <Sukoshi> This creates that framework with a minimum of overhead and a minimum of language extension.
23:46:34 <oerjan> because with dynamical typing, you can pass a subclass object and treating it like an overridden superclass object.
23:47:20 <oerjan> so common lisp _behaves_ as if subclasses can override, although technically they don't.
23:48:12 <oerjan> (at least that is my guess from your description)
23:49:00 <Sukoshi> That's the beauty of the system.
23:49:40 <oerjan> indeed, not without passing around some of the same information at runtime that CL needs.
23:50:14 <Sukoshi> The overlap of the generalized-method framework simulates operator overloading and polymorphism.
23:50:14 <Sukoshi> While actually abstracting the implementation to make it much more trivial to implement.
23:51:52 -!- bsmntbombdood has changed nick to xor.
23:52:29 <Sukoshi> Which things? I'll be wrapping my head around magnetization vectors while y'all talk.
23:54:33 <oerjan> essentially runtime type information. since this is multiple dispatch, the class struct doesn't contain enough information.