00:10:05 <oerjan> bf default is 16-bit, so you would be hard pressed getting either a halt or a newline out of that
00:10:35 <oerjan> i.e. nothing will be printed until buffer overflows, i think.
00:11:09 <SevenInchBread> ihope, oh alright... so with my idea I'm basically saying every process is a service... and the organizational structure is kind similar to a filesystem hierarchy.
00:12:49 <ihope> SevenInchBread: I'm thinking letting processes offer more than one service or none at all would add a little versatility.
00:13:16 <ihope> Why should every process be a service?
00:13:33 <ihope> How would it know which service it's doing?
00:13:48 <ihope> A process pretty much chooses what services to provide.
00:14:22 <ihope> The process is told what service has been called with what data.
00:14:24 <SevenInchBread> yeah... if one process was registered as two services with two fundamentally different tasks... and you used one - how would the process know which one it's handling.
00:14:37 <oerjan> you could have the process register streams at different addresses.
00:15:19 <ihope> What's this about streams?
00:15:20 <SevenInchBread> ah... that's a good idea. Except the stream part. :) I think Erlang "mailbox"-ish IO mechanisms would work nicely.
00:15:47 <oerjan> instead of having just stdin and stdout as interface, which i think is what is confusing here
00:16:15 <ihope> Why be mailboxish when you can have your processes provide procedures that can be called directly?
00:16:29 <ihope> (I'm talking Pascal now for some reason, aren't I?)
00:16:46 <oerjan> this leads then to the conclusion that procedures should also be placed in the filesystem
00:17:26 <ihope> SevenInchBread: if you provide procedures like that, the program can handle mailboxes by itself.
00:17:31 <oerjan> and before long we have arbitrary objects (in a general sense)
00:17:47 <ihope> oerjan: placing procedures in the filesystem?
00:17:48 <SevenInchBread> I was just saying... instead of the stream of bytes... you have a queue of.... stuff.
00:18:16 <SevenInchBread> the data gets partitioned... instead of jumbled alltogether in a huge chain.
00:18:39 <ihope> Did I say something to the contrary?
00:18:43 <oerjan> given that each service should have at least one spot in the filesystem, if i understand SevenInchBread correctly
00:19:00 <ihope> Services need not be invoked with plain old bits and bytes.
00:19:08 <ihope> oerjan: but I haven't agreed to that. :-P
00:19:18 <ihope> Putting services in the filesystem isn't a bad idea, though.
00:19:30 <SevenInchBread> well... kinda. Maybe not -literally- in the filesystem... but I was much wanting processes to be organized in a structure that resembled a filesystem.
00:19:34 <ihope> But that's a job for the filesystem handler, not for the kernel.
00:20:19 <ihope> Having processes arranged in trees is... well, what's the reason behind that?
00:20:41 <SevenInchBread> basically... it's an implication of giving processes names.
00:20:58 <ihope> Apart from its use in rationing CPU time.
00:21:10 <SevenInchBread> if we gave them names and didn't organize the names into some kind of scope... it would have all the problems of a flat filesystem.
00:21:46 <ihope> Couldn't you just put slashes in there or something?
00:22:26 <ihope> We can still have foo/bar/baz isn't if it's not baz inside bar inside foo.
00:22:42 <SevenInchBread> well... in my examples... I just used spaces... ala-Smalltalk message-passing (which is a similar concept).
00:24:51 <ihope> Why not just have another service called fs/cd and/or have cd be part of the message to the fs service?
00:25:38 <SevenInchBread> the "cd" part is literally just a string being passed to fs
00:25:45 <SevenInchBread> fs can choose to do whatever the hell it wants with it.
00:27:25 <SevenInchBread> if you like your names nice and flat... making some macros wouldn't be too impossible.
00:28:40 <ihope> So is there really any reason to put services in a tree like that/
00:28:41 <SevenInchBread> ...or you could borrow another concept from file hierarchies and do "current processes"
00:28:58 <SevenInchBread> -shrug- not really... it's not really all that necessary.
00:29:38 <ihope> By the way, how's the SourceForge coming?
00:31:04 <ihope> I notice that Google Groups does offer some storage space?
00:31:07 <SevenInchBread> oh, and another benefit of microkernels is that we have no obligation to write everything in one language.
00:31:11 <ihope> What about representing time?
00:31:17 <ihope> Indeed, that's true.
00:31:29 <SevenInchBread> the code behind fs or any other process major OS process could be any language.
00:31:59 <SevenInchBread> well... it would be kind of stupid to do time like all the major OSes... since it's going to run out of ticking power by 2032
00:33:51 <ihope> 64-bit won't go bad for a while.
00:34:02 <SevenInchBread> you could do like.... a base-256 numeral system... in reverse order (the smallest place values come first)
00:34:08 <ihope> Though bignums aren't bad.
00:34:30 <SevenInchBread> so the length can be arbitarry... and you won't ever have to worry about it.
00:34:56 <ihope> "(2^64) seconds = 5.84554531 * 10^11 years"
00:35:12 <ihope> We won't be the ones to worry about it.
00:35:26 <oerjan> terminate with a null? then it would be buggy
00:36:24 <SevenInchBread> maybe have a special byte for the terminator... and have do base-255. but for the OS, 64-bit should be enough.
00:36:52 <ihope> If we use 256 bits, we'll be good until all protons in the universe have decayed.
00:37:07 <oerjan> Time Error: Date is beyond Universe Heat Death
00:38:29 <oerjan> how long do red dwarf stars live again, hm...
00:39:12 <SevenInchBread> I sometimes wonder what the computer world would be like if we could specify the size of our bytes.
00:39:17 <ihope> That'll be enough.
00:39:21 <oerjan> ah, 64 bit won't be enough for that then.
00:40:02 <ihope> In 500,000,000,000 years, somebody'll have invented a way to translate everything up to 128 bits.
00:40:37 <ihope> I doubt Abrasax/YAOS/Sophia will still be in use by then, anyway.
00:40:48 <SevenInchBread> ....pretty sure the Earth or at the very least humans will be gone by that time.
00:41:55 <oerjan> ah, a misanthrope. or a misgean?
00:42:29 <ihope> How about we stay on topic, eh?
00:42:52 <ihope> We can always take this into #off-topic.
00:43:05 <ihope> Now, just how will we compile our kernel?
00:44:08 <oerjan> we will load it into the atmosphere of a red dwarf.
00:44:15 <SevenInchBread> erm.... I don't know. I've never actually used a compiler before.
00:45:11 <SevenInchBread> oerjan, kinda. I have a love-hate relationship with humanity.
00:45:28 <ihope> I suggest we steal the "Multiboot example".
00:46:03 <SevenInchBread> anything specific about memory management we want to do? What about paging?
00:46:14 <ihope> See http://www.gnu.org/software/grub/manual/multiboot/multiboot.html#Example-OS-code
00:46:30 <ihope> The kernel will probably have to handle memory management.
00:46:35 <ihope> Or at least some of it.
00:46:46 <ihope> It can't leave loading processes up to a process it can't load.
00:47:18 <SevenInchBread> yeah yeah... one of the main jobs of the kernel is memory management.
00:48:00 <ihope> I'm not that familiar with how memory works.
00:48:20 <SevenInchBread> buddy system allocation, paging files, etc.... the usual stuff.
00:48:34 <ihope> Buddy system allocation?
00:49:13 <ihope> I know a little bit about processes.
00:49:52 <SevenInchBread> I don't know how processes interact with the kernel to get memory though... I just know bits and pieces of HOW the kernel can go about handing out memory.
00:50:42 <ihope> Wouldn't that be done via system calls?
00:52:39 <SevenInchBread> memory management is kind of weird... you've got to find the best way to package a bunch of little blocks so that they can be picked up quickly
00:53:05 <ihope> We may have to find an expert.
00:53:32 <SevenInchBread> paging is probably the way to go.... all the big OSes use it... so its tried and testing
00:54:53 <SevenInchBread> we just need to write the program that reacts to a page fault.
00:55:35 <ihope> I think you know more than I do on the subject.
00:57:31 <SevenInchBread> a large amount of OS performance relies on a good paging algorithm.
00:59:01 <ihope> Think you can handle it?
01:00:53 <SevenInchBread> probably the other factor in the performance of this OS will be how quickly it can handle IPC... which is a bit more important to a micro kernel.
01:04:59 <ihope> Think we should recruit an expert, then?
01:05:05 <SevenInchBread> but... IPC doesn't mean shit if the process isn't scheduled to execute at the proper time.
01:05:36 <ihope> Why do processes need to be scheduled to run at the right time?
01:06:11 <ihope> Indeed, failure results in learning.
01:06:18 <SevenInchBread> well... one of the OSes jobs is to schedule which processes get to run and at one time. There's only so many processes that can run at any given time.
01:07:33 <ihope> You mean multiple processes can run at the same time?
01:08:01 <SevenInchBread> well... I mean... there's only so many processes that can be "active" at any given time.
01:08:25 <ihope> Just what is being "active", now?
01:08:37 <ihope> I suggest you remember, seeing as how I have doubts.
01:08:46 <SevenInchBread> http://en.wikipedia.org/wiki/Process_states <--LOL MORE LINKS
01:10:03 <ihope> Argh, process swapping.
01:10:21 <ihope> How about we leave *that* up to a process?
01:10:52 <SevenInchBread> well... to a certain extent OSes do... Windows for example lets me set the process priority.
01:11:21 <ihope> Indeed, failure results in learning, but aren't we aiming for success?
01:11:27 <SevenInchBread> ....so... I can set "firefox.exe" to realtime... and then it'll take me a good hour to try to move my mouse back to set it back to normal.
01:12:49 <ihope> I'd rather succeed the first time around. :-)
01:12:59 <ihope> Unless we can go faster by learning.
01:13:28 <SevenInchBread> see... the problem is that if you set the priority of a process extremly high, but keep all the processes that it accesses at normal... then the high-priority process will be spending most of its time waiting for its dependencies to become active.
01:14:00 <SevenInchBread> so... probably the best priority scheme is one based on a combination of reaction time as well as independence.
01:14:06 <ihope> We could let processes switch to other processes.
01:14:16 <SevenInchBread> the mouse... for example... should be highly responsive...
01:14:41 <ihope> Invoke a service provided by a process, then switch to that process.
01:16:04 <SevenInchBread> because processes are fairly asynchronous... there is no "return value".
01:16:43 <ihope> There's no return value?
01:17:33 <SevenInchBread> I mean... processes don't wait for the results of other processes... they're all running at the same time.
01:18:04 <SevenInchBread> the simplest scheduling algorithm is an equal time algorithm... which ensures that each processes gets a chance to execute...
01:18:23 <SevenInchBread> we can start with that one... and then find one that finds more efficient uses of time later.
01:18:24 -!- sebbu has quit ("@+").
01:19:36 <SevenInchBread> the only real reason equal-time scheduling doesn't work is because not all processes need an equal share.
01:19:38 <ihope> They're not all running at the same time.
01:20:09 <ihope> What's keeping us from adding a system call saying "spend the rest of this time slice on that process"?
01:20:11 <SevenInchBread> an HTTP server - which spents most of its time waiting for something to send it a request... doesn't need near as much time as a video game.
01:20:32 <SevenInchBread> ihope, that's just a specific situation... it doesn't solve the whole problem.
01:21:02 <ihope> Couldn't the HTTP server end its time slice early?
01:23:18 <bsmntbombdood> well, while it's blocking, the OS needs to put an entry in the ptable that says it's not available for scheduling
01:24:26 <ihope> Blocking is something I'm going to have to understand, isn't it?
01:25:26 <bsmntbombdood> blocking is when a proccess waits for some external input
01:25:42 <oerjan> it seems to me that the HTTP server problem is if a process has two "states" - one where it does immediate work in response to a request, and one where it does occasional work while otherwise waiting.
01:25:44 <bsmntbombdood> obviously, when a proccess is blocking, the scheduler shouldn't give it any proc time
01:26:00 <SevenInchBread> ihope, yeah that works fine... but you can't expect the process to handle itself... programmers don't want to have to think about time slices.
01:26:04 <oerjan> then they may need different priorities.
01:26:24 <ihope> SevenInchBread: so how do we know whether it's blocking or not?
01:27:08 <ihope> Blocking can only be the result of a system call?
01:27:51 <oerjan> you could of course have a system call that did nothing but end the current time slice
01:27:54 <SevenInchBread> if my program splits off a subprocess... I can explicitly say "wait for this process to return a result"
01:28:28 <ihope> Well then, the HTTP server invokes a service that waits for an incoming connection. The process that handles the service does all the work--right?
01:29:02 <ihope> Wait for process termination?
01:29:20 <ihope> Or "wait for service to return a result"? :-)
01:29:46 <ihope> Where do you come up with the names?
01:29:51 <bsmntbombdood> SevenInchBread: single words (ints) are much nicer
01:29:54 <SevenInchBread> alright then.... in Sophia the file system shall reference files by number.
01:29:59 <ihope> Indeed, they're pretty convenient.
01:30:09 <ihope> SevenInchBread: let's not violate WP:POINT here.
01:30:20 <ihope> Not that this would be a WP:POINT violation even if this were Wikipedia.
01:30:34 <ihope> Rather, let's not use slippery slope arguments or whatever they're called.
01:31:05 <SevenInchBread> ....I just can't fathom how numbers are more convient than names.
01:31:08 <oerjan> that's just inodes isn't it?
01:31:21 <ihope> When I create a file, I usually have a name in mind for it. If I don't have a name in mind, I might choose a number. When I create a process, I usually don't have a name in mind for it.
01:31:25 <SevenInchBread> indeed... we have DNS because names are more convient than numbers.
01:31:37 <ihope> SevenInchBread: it's easier to store a name than it is to store a number.
01:31:45 <ihope> Names are for things that persist.
01:32:05 <ihope> s/name/number/ and vice verse.
01:32:11 <ihope> s/verse/versa/ :-P
01:32:17 <ihope> SevenInchBread: why is what important?
01:32:23 <oerjan> naturally the name would be optional, and initialized like a temporary file name if not provided
01:32:33 <ihope> (Alternatively: s/easier/harder/)
01:32:48 <bsmntbombdood> system calls are numbers, file descriptors are numbers, permissions are numbers...
01:32:57 <ihope> Oh, names are fine.
01:33:02 <ihope> But why have them?
01:33:40 <SevenInchBread> but why? A number has no referential meaning to a human... they're only convient for the computer - which is fine in some cases.
01:33:44 <oerjan> however if the OS supports process persistence (and otherwise, why go to all this trouble?) then you might run out of numbers.
01:34:35 <ihope> It's not especially often you need to refer to a process by ID.
01:34:46 <SevenInchBread> to help the stupid computers work with the stupid humans.
01:35:17 <ihope> I could say "the process providing the 'fs' service" or "the process that's an instance of /foo/bar" or "the process that's using all the CPU time".
01:35:51 <SevenInchBread> heh... I've been referring conceptually to fs being the actual process.
01:36:15 <ihope> If the process that's using all the CPU time is the only instance of the executable, we refer it to is as "the process that's an instance of /foo/bar". Otherwise, how do we come up with names for all the instances?
01:36:33 <ihope> If you let the processes name themselves, you end up with things like processes named "_________________________".
01:36:51 <ihope> And processes named "ø".
01:37:06 <SevenInchBread> names are useful for persistance of any kind.... fs will always remain fs each time it is around... that way we have a quick and global reference to it.
01:37:18 <ihope> fs is the name of the service, not the name of the process.
01:37:24 <SevenInchBread> ihope, is that any more troublesome than "the process 242"
01:37:43 <ihope> SevenInchBread: well, you have to copy and paste the underscores rather than typing them by hand.
01:37:59 <ihope> Can you tell how many underscores there are without doing something tedious?
01:38:13 <ihope> I can copy "242" much more easily.
01:38:24 <ihope> My example or yours?
01:38:49 <SevenInchBread> yes indeed... someone could name their process "asfkjskdljdklgjdlkgjlkdgkldfjgkljdfg".... but then they're fucking retarded.
01:39:04 <ihope> Well, there are people in the world who are fucking retarded.
01:39:05 <SevenInchBread> and you probably don't want whatever that process does.
01:39:15 <ihope> And that means you need to kill it.
01:39:35 <ihope> I'd rather type 242 than copy-and-paste that thing.
01:40:50 <SevenInchBread> okay... so then you can simply have numbers AND names. like file descriptors and file names.
01:41:17 <ihope> Why have process names, again? Service names, sure, but why process names?
01:42:06 <SevenInchBread> I'm talking about a unique reference name and a unique ID number.
01:42:35 <SevenInchBread> basically... a service IS a process.... a process with a name in front of it.
01:42:36 <ihope> I'm thinking giving every process a name is like giving every inode or whatever you call it a name.
01:42:51 <SevenInchBread> maybe not in UNIX... in UNIX the service name -creates- a new process each time it's referred to.
01:43:06 <ihope> Well, yes. The services act as the names, so what reason is there to give each process another name?
01:43:10 <SevenInchBread> but I don't think we're doing that... unless we want to spawn a process each time we refer to "fs"
01:44:26 <ihope> Users and application developers need to know "fs", the service name. They don't need to know the name of the process.
01:44:40 <bsmntbombdood> SevenInchBread: what you describe is message passing OO
01:45:05 <bsmntbombdood> proccesses have private data and can be sent messages. they are objects.
01:45:11 <SevenInchBread> ...I just don't like the concept of the service. I just like... the concept of "a name for a process"... the name can optional sure, but it's not a separate entity from the process itself.
01:45:38 <ihope> Well, that's pretty much what a service is, really.
01:45:54 <ihope> Except that you can attach multiple services to a process.
01:45:59 <SevenInchBread> bsmntbombdood, what I described is the desktop metaphor... it's also a good bedtime story and makes for a damn good sexual joke. Is that an apple or a red fruit?
01:46:06 <ihope> And not every process needs a service at all.
01:46:29 <ihope> How what would work?
01:46:51 <SevenInchBread> having multiple names for a process... each doing something different.
01:47:16 <ihope> When the service is invoked, the process is told what service it was.
01:48:10 <ihope> Well, I should get to bed. There's school tomorrow.
01:48:23 <SevenInchBread> ...I think I'd just like there to be a persistent name for processes. A service does this nicely... but then how difficult does it become to create a new name for your process?
01:48:54 <ihope> [And then somebody yells "Let's get going!", and "Walking On Sunshine" by Katrina and the Waves starts playing.]
01:49:57 <SevenInchBread> bsmntbombdood, the weird apple-red-fruit thing was referring to the notion of identity.
01:50:07 <SevenInchBread> Something is only OO if we decide to refer to it as such.
01:50:12 <ihope> SevenInchBread: the process requests permission to use that service name, something grants permission, and the process registers that service name.
01:50:30 <ihope> Or the process already has permission, in which case it simply registers it.
01:56:05 <lament> booting is for rewimps
02:02:34 <ihope> SevenInchBread: services aren't preserved when rebooting, but permissions may be.
02:03:24 <ihope> See "'default' permissions".
02:03:38 <ihope> SevenInchBread: well, indeed, services could be preserved when rebooting.
02:03:49 <ihope> But that would mean processes being preserved when rebooting.
02:03:55 <ihope> We all know that's iffy.
02:07:29 <ihope> "Default" permissions are stored in along with the executable, somehow, and therefore preserved when rebooting.
02:08:22 <ihope> Record-based filesystems?
02:08:38 <SevenInchBread> yeah... instead of storing files as streams you store them as hash-table-like things
02:11:15 <ihope> What's this about hash tables?
02:11:30 <SevenInchBread> I think it makes a shitload more sense than cramming all the info into a stream and having to parse out all the data
02:12:09 <ihope> So the filesystem handler does all the parsing instead of the client?
02:13:01 <SevenInchBread> eh... sorta kinda.... depends on how its stored on the disc
02:13:17 <ihope> Depends on how it's stored on the disk?
02:13:44 <SevenInchBread> yeah... instead of using bytes to delimit record entries you can use some physical property of the disk sector or something...
02:13:56 <SevenInchBread> but, generally speaking, the filesystem does all the work for you.
02:14:49 <ihope> We could always have a "hash table handler".
02:15:48 <SevenInchBread> there's also sequantial access... which works something like a linked list instead of a hash table
02:16:07 <SevenInchBread> so... data that's split up into lines could give each line a record.
02:16:45 <ihope> Time for me to go to bed.
02:36:15 -!- ihope has quit (Connection timed out).
03:03:20 <Pikhq> I friggin' hate glibc.
03:03:29 <Pikhq> frodo:/source/glibc-build# /source/glibc-2.5/configure --prefix=/usr --disable-profile --enable-addons --enable-kernel=2.6.0 --libexecdir=/usr/lib/glibc
03:03:30 <Pikhq> configure: error: cannot find install-sh or install.sh in scripts /scripts
03:16:42 <Pikhq> I'm making a distro. What else am I supposed to do?
03:17:16 <Pikhq> Actually, that's a pretty decent thought.
03:20:58 <Pikhq> Maybe make this sucker use really, *really* small packages.
03:22:29 <bsmntbombdood> use "make the lazy bastards code it themselves"libc
03:25:59 <Pikhq> I'm using buildroot to create the initial root tree. . .
03:26:25 <Pikhq> I'll then use the buildroot environment to compile my own packages, overwriting everything eventually.
03:50:28 -!- SevenInchBread has quit (Read error: 110 (Connection timed out)).
05:02:02 -!- ShadowHntr has quit ("End of line.").
05:22:19 -!- oerjan has quit ("ZZZ").
07:50:27 -!- wooby has joined.
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:02:04 -!- Sgeo has quit ("Ex-Chat").
08:30:55 -!- nazgjunk has joined.
08:33:42 <Sukoshi> How about a cellular automata VM?
09:34:19 -!- sebbu has joined.
10:36:27 -!- nazgjunk has quit (Read error: 104 (Connection reset by peer)).
10:36:55 -!- nazgjunk has joined.
10:48:52 -!- puzzlet has joined.
10:59:10 -!- sebbu2 has joined.
11:09:00 -!- ihope_ has joined.
11:09:20 -!- ihope_ has changed nick to ihope.
11:18:41 -!- sebbu has quit (Read error: 110 (Connection timed out)).
11:18:41 -!- sebbu2 has changed nick to sebbu.
13:11:04 -!- jix__ has joined.
13:20:46 -!- jix__ has changed nick to jix.
13:24:52 -!- jix has changed nick to jix____.
13:27:09 -!- jix____ has changed nick to jix.
15:09:53 -!- falseep has joined.
15:18:54 -!- nazgjunk has quit (Read error: 104 (Connection reset by peer)).
15:19:16 -!- nazgjunk has joined.
15:40:21 -!- falseep has quit (Read error: 104 (Connection reset by peer)).
16:11:09 -!- jix__ has joined.
16:19:24 -!- jix has quit (Read error: 110 (Connection timed out)).
16:41:36 -!- jix__ has changed nick to jix.
17:19:19 -!- nazgjunk has quit (Read error: 104 (Connection reset by peer)).
17:19:53 -!- nazgjunk has joined.
18:01:54 <Sukoshi> bsmntbombdood: Dunno, we'd have to reduce every simple cellularo automota to VM commands.
18:13:13 -!- jix has quit (Read error: 104 (Connection reset by peer)).
18:16:02 -!- jix__ has joined.
18:24:41 -!- ihope has quit ("http://tunes.org/~nef/logs/esoteric/06.08.09").
18:31:07 -!- calamari has joined.
18:33:50 -!- ShadowHntr has joined.
18:37:43 -!- digital_me has joined.
19:16:46 -!- atrapado has joined.
19:25:08 -!- jix__ has changed nick to jix.
19:55:59 -!- calamari has quit ("Leaving").
20:32:02 -!- nazgjunk has quit (Read error: 104 (Connection reset by peer)).
20:33:31 -!- nazgjunk has joined.
20:42:49 -!- Sgeo has joined.
20:50:38 -!- calamari has joined.
20:58:22 -!- ShadowHntr has quit ("End of line.").
21:01:43 -!- nazgjunk has quit (Dead socket).
21:02:37 -!- nazgjunk has joined.
21:06:32 -!- atrapado has quit (Read error: 60 (Operation timed out)).
21:06:43 -!- dub_ has joined.
21:07:09 -!- dub_ has changed nick to atrapado.
21:11:54 -!- ihope has joined.
21:12:36 <ihope> I be an IRC pirate!
21:15:44 -!- ihope_ has joined.
21:16:04 <ihope_> I be a disconnected IRC pirate!
21:21:22 <ihope_> Anyway, I half-officially declare the name of "the operating system project" to be Abrasax,
21:21:45 <ihope_> We could have trademark issues with Sophia.
21:22:05 <ihope_> And the half-official IRC channel is #abrasax.
21:25:19 <ihope_> http://groups.google.com/group/AbraSophia
21:26:18 * GregorR nods as if he has an effing clue what's going on.
21:26:33 <ihope_> It's an operating system project,
21:33:04 -!- ihope has quit (Read error: 110 (Connection timed out)).
21:51:51 <ihope_> I think I'll be the one to do all the "dirty work" of getting the basic bit of kernel down.
22:22:23 -!- dub_ has joined.
22:23:43 -!- atrapado has quit (Nick collision from services.).
22:23:46 -!- dub_ has changed nick to atrapado.
22:36:48 <ihope_> Wow. A lot happened on March 26, according to the logs.
22:40:08 <ihope_> I love how Google can do things like "0x4000 bytes in kilobytes"
22:42:18 <ihope_> "# define EXT_C(sym) _ ## sym"
22:42:20 <bsmntbombdood> google will end up as a natural language interpreter
22:42:33 <ihope_> Does that _ ## mean anything special to the preprocessor?
22:43:12 <bsmntbombdood> ## is either concatenation or turning into a string
22:43:37 <ihope_> What's it do in this case?
22:45:20 <ihope_> So what's "movl $(stack + STACK_SIZE), %esp" do?
22:47:18 <bsmntbombdood> I'm guessing it puts the address of the top of the stack in esp
23:06:57 -!- nazgjunk has quit ("Bi-la Kaifa").
23:07:39 -!- oerjan has joined.
23:19:48 <Sukoshi> Gah. I'm finding ObjC less and less attractive.
23:20:08 <oerjan> ah, the end of initial infatuation
23:20:29 <Sukoshi> Well, I had thought that ObjC was a simple object layer wrapped around C.
23:20:45 <Sukoshi> The dynamic runtime stuff is interesting ... but it's said to be slow.
23:21:17 <Sukoshi> Why doesen't someone implement a generic function based OOP extension to C? It would be easier to code than a message-passing one.
23:22:18 <Sukoshi> Now I'm paralyzed between Java and D for a new project. I need GregorR to shower me with D's advantages once more.
23:23:25 -!- nazgjunk has joined.
23:24:42 <Sukoshi> Isn't GregorR our resident parser god anyways?
23:25:51 <Sukoshi> Well, if I had the experience with writing language parsers, I'd like to create a simple superset of C for generic functions.
23:26:35 <oerjan> C has dirty corners in its parsing.
23:26:46 <Sukoshi> Well, this would parse it into straight C.
23:27:40 <Sukoshi> That would be an interesting project in fact. A light OOP extension to C without major additions to the language and huge stdlibs.
23:30:41 <Sukoshi> Well, here's how I see it:
23:31:01 <Sukoshi> You can create classes as a set of slots. It'll be done in the same syntax as a struct, except we'll call it object.
23:31:28 <Sukoshi> (So you have something like ``object hi { int a; char b; } ''
23:32:59 <Sukoshi> You then define a method using a syntax like ``void display (hi obj, int x, int y)'' and then you can add_generic() a function pointer.
23:33:14 <Sukoshi> *function pointer to display()
23:33:41 <Sukoshi> .... We don't need a parser for this ... do we?
23:34:06 <Sukoshi> Oh but we have to grab the method signature somehow.
23:34:33 <Sukoshi> Well, when you use call_generic(display), it'll have to lookup display.
23:34:45 <bsmntbombdood> that is practically the same algorithm as objc message passing
23:35:01 <Sukoshi> But it avoids the annoying dynamic runtime of ObjC.
23:35:18 <Sukoshi> And based on the parameters you give call_generic, it needs to be able to match the correct function.
23:35:24 <Sukoshi> I need to pull up my C reference, hold on.
23:37:17 <Sukoshi> But the difference in ObjC is the whole business with id.
23:38:07 <bsmntbombdood> and running through a linked list to find a method doesn't seem very slow
23:38:19 <Sukoshi> It is, almost all the spare links on ObjC say so.
23:38:38 <Sukoshi> They all advise keeping method invocations to a minimum because it slows the program down.
23:38:58 <bsmntbombdood> think about it [obj message] -- obj->isa, hash table lookup, obj->isa->super, hash table lookup, obj->isa->super->super...
23:39:14 <Sukoshi> That's what the weblinkse I've read say *shrug*.
23:41:52 <bsmntbombdood> all a method invocation needs to do is a lookup in a hash table
23:42:04 <bsmntbombdood> maybe a few hash tables if the inheritance is deep
23:43:06 <Sukoshi> The ObjC runtime doesen't type check at compile time for message passing, in case you want to change stuff later.
23:43:19 <Sukoshi> Which is part of what leads to the slowdown.
23:45:47 <bsmntbombdood> looking up a method in objc is the same as looking up a variable in a interpreted language
23:47:01 <Sukoshi> I'm looking for something just a tad bit slower than C.
23:47:24 <Sukoshi> Google says that Java is faster.
23:47:47 <Sukoshi> Java is by no means slow if programmed correctly, you know.
23:47:55 <Sukoshi> And the sheer amount of work done on the runtime is incredible.
23:48:10 <Sukoshi> I think JVM, SqueakVM, and ParrotVM are the most worked on in this respect.
23:48:42 <Sukoshi> The Java runtime has been optimized incredibly.
23:49:13 <Sukoshi> I mean if you think about it logically, people (for good or for ill) have been putting work into the runtime for 10 years.
23:49:36 <Sukoshi> But it hasn't been continually developed is the problem.
23:50:10 <Sukoshi> I don't think you see many changes to the g++ code on a daily basis.