00:00:00 --- log: started forth/04.08.11 00:03:08 --- quit: mur (Read error: 110 (Connection timed out)) 00:07:56 --- quit: imaginator ("rest") 00:12:25 Back 00:14:16 :) 00:15:44 # Newbie casts Shield (with the right hand) at itself. 00:15:44 # Newbie casts Shield (with the left hand) at itself. 00:15:44 # Newbie has surrendered to lycaxyz! 00:15:45 # +++ lycaxyz has won +++ 00:16:09 That was probably the easiest match of Spellcast that lyca has played, and he wasn't even at the keyboard!! 00:16:23 lol 00:39:23 You know, L4 *is* a pretty cool system, despite the ugliness of its IPC system call. 00:39:54 That ugliness appears to be largely restricted to only IPC and the syscall to grab thread register settings (the latter is understandable in a way; the former is just . . . bizarre). 00:40:11 Other than that, a 7-call OS kernel is damn nice. :-) 00:40:27 * kc5tja will have to play around with it someday. 00:40:37 7 calls? wow 00:42:23 Yeah. :) 00:42:51 But 1 of the syscalls can do like 8 different tasks depending on the parameters (can in some cases, together). 00:42:57 i did some experiments. i should be able to achieve around a 3x speedup by writing an x86 STC compiler for factor. 00:43:12 I'd say, with every discrete function taken apart, the kernel would have something like 20 system calls. 00:43:19 Still VERY small, and VERY grok-able. 00:43:50 slava: Cool. All that, on top of your existing optimizations. 00:44:19 another experiment shows that if i do type inference + STC, i'll beat gforth :) 00:44:40 basically i 'hand compiled' some library functins :) 00:45:13 anyway, time to sleep. 00:45:19 'night slava 00:45:22 Good luck. 00:45:32 It seems you're vastly more productive on your project than I am on mine. >:/ 00:49:16 So much for the "dinosaur" label. Sales of IBM's mainframe, now referred to as the zSeries, are growing at remarkable rate, not experienced since its heyday - indeed if current mainframe growth continues, then the mainframe is emerging like a phoenix from the flames. 00:49:45 hmm, interesting... 00:51:38 fridge: Yep. 00:52:19 But the S/390 systems aren't quite the same as their S/360 ancestors. Gone are the 1MHz CPUs. zSeries is looking at 500MHz CPUs that are superscalar, and have branch prediction logic, etc. 00:52:28 And yes, it still runs all the same code. :D 00:52:59 :) 00:53:26 not only that, but each CPU module basically works with other CPU modules in unison to arrive at a common answer. 00:53:39 If one CPU gives a divergent answer, then that CPU is shut down, and reported to the system administrator. 00:53:50 Administrators can hot-swap CPUs in a mainframe. 00:53:59 wow cool 00:54:14 In this way, heat-death of a computer is almost non-existant (quite unlike Linux and BSD boxes, I might add). 00:54:37 --- quit: mur_ (Remote closed the connection) 00:54:56 Yep. IBM System/3x0 mainframes are wickedly awesome computer architectures. 00:55:12 --- join: mur (~mur@uiah.fi) joined #forth 00:55:13 The programming model for the CPUs are obviously antiquated. But other than that, they ROCK. 01:00:05 :) 01:07:21 i want one :D 01:16:49 I want to play with one 01:16:57 :) 01:17:08 I'm not sure I want to pay for the power, HVAC and other related costs though 01:21:04 Yeah, no kidding. Mainframes replace entire server farms worth of I/O capacity. 01:21:46 I posit that we can replace the entirety of cari.net's server farm with a zSeries mainframe, and reap immediate benefits. 01:22:10 Ahh, too bad they do cost a lot for us though. 01:22:14 how many CPUs does one of those have? 01:22:18 and how much do they cost? 01:24:50 These machines might have as many as four CPU modules, with each modules itself having up to three or four CPUs. 01:25:04 :) 01:25:09 But these CPUs don't process data in parallel -- all CPUs in a module execute the exact same set of instructions at the same time. 01:25:16 This is for redundancy and reliability reasons. 01:25:23 yep 01:25:32 a CPU that screws up is shut down and reported 01:25:33 :) 01:25:37 If one or two CPUs goes down, the computer continues to run, and the administrator is alerted via an alarm indication of some kind. 01:25:46 I think so... know what the entry level price would be? 01:26:06 I'd guess $500,000 to $1,000,000. 01:26:21 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 01:26:38 wow, i finally stoppped bleeding 01:26:41 I mean, AS/400 systems are damn expensive -- easily in the $500,000 range. Mainframes are several orders of magnitude larger in scope than an AS/400 (even thought he AS/400 is itself a miniature mainframe itself) 01:26:59 arke: Yeah, price tags of mainframes will make anyone's heart stop (and therefore, stop bleeding). 01:28:13 lol 01:29:12 I'm not overly surprised 01:30:19 :/ 01:31:22 --- join: mur_ (~mur@mgw2.uiah.fi) joined #forth 01:43:04 --- quit: mur (Read error: 110 (Connection timed out)) 01:47:45 Hmm...looks like L4 might be a fun system to code some kind of simple OS for. 01:48:24 The concept of "clans" and "chiefs" is entirely unique as far as I can tell -- and is a familiar metaphor if you think in terms of network routers and network nodes. 02:10:10 --- quit: tgunr (Read error: 104 (Connection reset by peer)) 02:14:37 --- join: tgunr (~davec@vsat-148-63-4-107.c001.g4.mrt.starband.net) joined #forth 02:32:05 OK, I'm off to bed now. 02:32:11 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 02:46:18 --- quit: tgunr (Read error: 104 (Connection reset by peer)) 02:53:07 --- join: tgunr (~davec@vsat-148-63-4-107.c001.g4.mrt.starband.net) joined #forth 03:02:27 --- join: mur (~mur@uiah.fi) joined #forth 03:03:51 Hej, mur. 03:08:30 --- nick: Tomasu -> TomasuDlrrp 03:15:47 --- quit: mur_ (Read error: 110 (Connection timed out)) 04:10:02 --- join: mur_ (~mur@kyberias.uiah.fi) joined #forth 04:20:13 --- quit: mur (Read error: 110 (Connection timed out)) 04:37:54 --- join: crc (crc@0-1pool0-41.nas26.philadelphia1.pa.us.da.qwest.net) joined #forth 04:55:40 --- quit: crc ("Time for bed... Goodnight all!") 05:08:17 --- join: crc (crc@0-1pool0-41.nas26.philadelphia1.pa.us.da.qwest.net) joined #forth 05:11:41 --- join: Topaz (jonny@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth 05:21:24 --- quit: crc (Client Quit) 05:34:51 --- quit: sallust_ (Read error: 104 (Connection reset by peer)) 05:40:41 --- join: sallust (~reynaert@175.181-201-80.adsl.skynet.be) joined #forth 05:44:15 --- join: mur (~mur@mgw2.uiah.fi) joined #forth 05:57:39 --- quit: mur_ (Read error: 110 (Connection timed out)) 06:31:51 hi 06:50:04 --- join: mur_ (~mur@smtp.uiah.fi) joined #forth 06:50:13 --- quit: mur (Remote closed the connection) 06:56:07 --- join: Serg[GPRS] (~z@193.201.231.126) joined #forth 06:56:29 hiy-a-a-a ALL ! 06:57:20 Hi ya. 06:57:46 nice to be online ;)) 07:00:53 brb 07:06:22 --- quit: tgunr (Read error: 104 (Connection reset by peer)) 07:26:02 --- join: tgunr (~davec@vsat-148-63-4-107.c001.g4.mrt.starband.net) joined #forth 08:51:03 --- join: warpzero (~warpzero@mi073.dn185.umontana.edu) joined #forth 08:59:33 --- quit: Serg[GPRS] ("Too late !") 09:54:35 --- join: fridge_ (~fridge@dsl-203-113-229-106.NSW.netspace.net.au) joined #forth 10:03:44 --- quit: fridge (Read error: 110 (Connection timed out)) 10:16:03 --- quit: warpzero (Connection timed out) 10:22:19 --- quit: lyca (Read error: 110 (Connection timed out)) 10:22:38 --- join: warpzero (~warpzero@mi088.dn187.umontana.edu) joined #forth 11:31:28 --- join: imaginator (~George@georgeps.dsl.xmission.com) joined #forth 12:38:46 --- join: ChatSA (~Bullrush@196.44.2.197) joined #forth 12:38:48 hey 12:39:58 Hi 12:42:37 * slava is working on multitasking 12:46:46 this will be very nice for the http server 12:49:24 --- join: FlamingRain (Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 12:53:02 hi FlamingRain 12:53:08 hello 12:54:13 slava, multitasking or multithreading? 13:03:14 --- quit: ChatSA ("Download Gaim: http://gaim.sourceforge.net/") 13:06:36 madwork, just simple co-operative threads that yield on I/O 13:14:03 --- join: kc5tja (~kc5tja@66-74-218-202.san.rr.com) joined #forth 13:14:10 --- mode: ChanServ set +o kc5tja 13:17:07 hi kc5tja 13:17:30 re 13:18:30 * kc5tja is now reading up on L4's next-in-line successor: L4Ka. 13:18:38 Well, L4Ka::Pistachio. 13:24:38 Dang it, a microkernel should *never* have to return an out-of-memory condition. Never. 13:25:01 That's one nice thing about a cache-kernel -- it *never* runs out of memory, for it never *allocates* memory. 13:29:20 --- quit: FlamingRain ("Leaving") 13:30:13 slava, I'm doing something similar in my current Forthy game engine. 13:37:32 It's kind of neat, I can have a single, cheap "background thread" in my console interface by running a word that yields before the end of a loop. Then, the console does its updates, lets me type commands in, and then loads a new interpreter/input underneath the currently executing word. I break the thread by typing 'asd' or whatever and causing an error. :) 13:37:50 do you have co-routines as well? 13:38:17 --- quit: tgunr (Excess Flood) 13:39:08 Not explicitly. I can pause/yield execution, do stuff in C, then resume. But from within Forthy, there's no way to really do this without breaking out to C-land. 13:40:10 --- join: tgunr (~davec@vsat-148-63-4-107.c001.g4.mrt.starband.net) joined #forth 13:40:10 do you use the C stack for subroutine calls? 13:40:35 Nope. 13:45:07 I suppose I could have a context stack that lets me push the current call stack. 13:48:22 if you have your own return stack co-routines are easy 13:49:28 I've never really understood how I'd need/use them. 13:50:58 factor has continuations, which are a generalization of catch/throw, co-routines, multitasking, generators, and so on. 13:51:11 i use co-routines when embedding factor in a event-driven GUI 13:51:43 the outer interpreter can call 'read' to read a line and block, but it doesn't actually block, it switches to the event loop until the user types in a line and hits enter 13:52:06 i can open as many windows as i want containing the outer interpreter 13:52:16 even though there's only one inner interpreter, each window has its own stacks etc. 13:52:33 hmm 13:53:05 in the http server, you can write web apps in this style: 13:53:08 show-some-page 13:53:11 prompt-user 13:53:18 if foo bar then show another page 13:53:19 etc 13:53:35 but behind the scenes, the http server is actually suspending/resuming your web app and accepting requests 13:54:00 even the back button is supported, just by backtracking the computation to a prior point 13:54:13 Huh, neat. 13:55:20 or you can do 'generators' -- potentially infinite loops that yield the next element of some sequence each iteration. 13:55:36 the caller of the generator pulls elements out one at a time by suspending/resuming the loop. 13:55:48 0 [ 1 + dup yield ] forever 13:55:57 this generates 1 2 3 4 .... 13:56:57 to do all this, i only need four additional primitives: datastack, callstack, set-datastack, set-callstack 13:58:29 and a few words that wrap them in meaningful abstractions 13:59:16 datastack/callstack restore those stacks? 14:01:15 the first two push the stacks, the second two restore them 14:01:28 well *copies* of the stacks. 14:03:53 right. 14:04:22 Hmm, this wouldn't be hard to add to Forthy. 14:04:40 it would make memory management more complicated 14:05:00 I don't see how. 14:05:28 --- nick: TomasuDlrrp -> Tomasu 14:05:30 well, unless you deep copy the stacks. 14:05:31 * Tomasu is back (gone 46:17:29) 14:06:19 Too bad you can't mark objects as copy-on-write. 14:06:35 Then a deep copy can be done on an as-needed basis, rather than always. 14:07:33 well a shallow copy of the stacks suffices 14:07:43 if you have a handful of items on the stack its reasonably fast 14:08:07 And a stack depth of 16 is considered effectively infinite... 14:08:27 The problem is, you can have 3 items on the stack, one of which is itself a stack, which itself can have a stack....ad nauseum. 14:09:47 The whole idea of copy-on-write semantics is to not have to recurse until you absolutely HAVE to. 14:10:05 But, it does add a layer of complexity in and of itself, so it may not be worth it for this application. 14:13:39 --- join: FlamingRain (~Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 14:38:52 --- quit: FlamingRain ("Leaving") 15:17:57 --- quit: tgunr (Excess Flood) 15:19:49 --- join: tgunr (~davec@vsat-148-63-4-107.c001.g4.mrt.starband.net) joined #forth 15:38:10 --- join: snowrichard (richard@adsl-068-209-159-248.sip.shv.bellsouth.net) joined #forth 15:38:15 hi arke 15:39:02 Hi snowrichard 15:39:09 and Robert :) 15:39:14 How are thing? 15:39:16 s 15:39:44 I have been worrying about bills, but that doesn't get them paid, so I guess I'll stop now. :) 15:40:03 Good strategy 15:40:23 But it's hard to just stop worrying.. 15:40:33 my brother says I should sell my car, but I am not ready to yet. 15:42:11 try not to think of a pink elephant :) 15:42:46 Hehe 15:43:43 I have just read a book today called "Total Money Makeover" which my brother has been raving about for some time now. 15:44:03 So what did it tell you? 15:44:25 it kind of boils down to "spend less than you earn and do that for a long time and you will get rich" 15:44:35 i still haven't worked out how to spend money, heh 15:44:49 i tend to spend as little as i can possibly get away with :/ 15:45:04 I am living on a disability check 15:45:07 snowrichard: Or do like the author, exploit the stupid 15:45:30 snowrichard: www.microsoft.com has some tips about that. 15:45:41 hey i didn't Buy the book, I got it from the libary :0 15:45:46 Topaz: Same here, but then I'm living with my parents 15:45:54 snowrichard: Hehe, I didn't mean you anyway 15:46:11 last term (at uni ;) i spent about $10 a week on food ;) 15:46:38 he says he is taking resumes for web developers. I think I'll work up a website to carry out his plan and send a link to it with a password for a resume :) 15:46:46 at it's not as if it was unhealthy, but maybe a bit bland 15:47:02 Topaz: Hehe, sounds like something I'd do 15:47:31 next term i'm going to try living solely off carrots for a fortnight 15:47:40 a carrot fast? 15:47:41 (the betacarotene makes you go orange) 15:48:29 How much does rice cost over there? 15:48:41 rice is real cheap if you buy the huge bags 15:49:37 Here I think it's about 1 USD/kg in medium-sized bags (5-10 kg). 15:49:41 rice is about 60p per kg, in ultra-cheap form 15:49:50 (60p is about $1, so yeah) 15:49:57 this is in 1kg bags 15:50:03 it's not any cheaper in larger ones, amusingly 15:50:24 No.. But large ones can still be handy. 15:50:45 you can make a shirt out of them when you are finished with the rice :) 15:50:46 Our rice bucket takes 5kg, so one of those sacks makes an excellent refill. 15:51:07 Unforutnately these new ones are plastic. :( 15:51:13 So no shirts from them. 15:52:59 i tend to eat more potatoes than rice though 15:53:06 potatoes taste more interesting ;) 15:54:00 I like rice more. But you can combine with potatoes. One of my favourite dishes is fried potatoes and rice with salat. 15:54:26 though i eat a fair amount of rice with my variations on chilli and curry 15:54:34 (though chilli and potato is rather good ;) 15:54:53 Yes, with chili and paprica. 15:55:19 A friend introduced me to the concept on peanuts and curry, very good! 15:55:25 of* 15:56:47 hmm, interesting 15:56:52 cashew nuts are good in curries 15:57:13 though you can throw alsorts of stuff in curry ;) 15:57:35 i make quite a lot of rogan josh with carrots and mangos in :) 15:57:44 Cashew nuts are too damn expensive not to be enjoyed on their own. 16:01:34 --- quit: snowrichard ("Leaving") 16:02:02 hmm, fair point 16:02:54 excellent, 'carotenemia' isn't dangerous : 16:02:57 D 16:03:17 i live for a fortnight on carrots, and not die! :D (hopefully) 16:08:03 --- quit: warpzero (Remote closed the connection) 16:09:09 I'm not such a big fan of carrots. 16:09:17 Together with oranges they're OK. 16:09:21 Never boil them, though. 16:10:40 yeah, steaming or frying is the way ;) 16:10:43 i tend to fry everything... 16:11:10 Hehe, yes. 16:11:16 Except maybe when doing a nice wok. 16:11:38 Then you could put in some carrots, just don't boil them enough to get sloppy. 16:11:45 (are we off-topic?) 16:12:07 :D 16:12:31 i don't suppose cooking is a particularly good analogy for the FORTH development process ;) 16:13:56 --- join: FlamingRain (~Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 16:23:20 --- join: warpzero (~warpzero@mi005.dn183.umontana.edu) joined #forth 16:27:07 --- quit: FlamingRain ("Leaving") 16:29:04 --- quit: warpzero (Remote closed the connection) 16:32:07 --- join: warpzero (~warpzero@mi005.dn183.umontana.edu) joined #forth 16:51:22 back 16:52:27 * Tomasu is away: store 16:54:02 --- join: I440r (~mark4@216-110-82-59.gen.twtelecom.net) joined #forth 16:57:42 --- join: FlamingRain (Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 17:00:55 * Tomasu is back (gone 00:08:28) 17:05:35 hrm i wonder how many ppl have to be regular in here before lilo idles in here :) 17:11:44 --- join: doublec (~chris@li5-223.members.linode.com) joined #forth 17:14:28 I440r: What? 17:14:52 Why would you want him idling in here? 17:14:55 fuck lilo 17:15:05 all he does is send system wide messages with calls for donations :) 17:15:20 I don't have any opinions one way or another about lilo. I'm just wondering why his presence here is somehow important. :) 17:15:33 lol it was said in humor lol 17:15:44 he is welcome to idne in here if he wants to tho :) 17:15:49 slava: Well, there is always occnetwork.com 17:16:00 i see him idling in all of the most popular channels 17:16:24 --- quit: warpzero (Remote closed the connection) 17:16:39 --- quit: FlamingRain ("Leaving") 17:17:23 hi slava 17:17:43 hi doublec 17:18:11 how is native factor coming along? 17:18:32 httpd works in cvs now 17:18:51 wow nice! 17:19:22 i just redid it to not use regexps. the code ended up being cleaner anyway 17:19:30 i'm away from a stable internet connection at the moment so havent been able to update or go online 17:19:53 i've been working on a parsing combinator library 17:20:03 it's coming along nicely 17:20:06 i'm working on making the native parser faster. 17:20:16 cool 17:20:17 hey you might like this: 17:20:22 : skip ( n line quot -- n ) 17:20:22 #! Find the next character that satisfies the quotation, 17:20:22 #! which should have stack effect ( ch -- ? ). 17:20:22 >r 2dup str-length < [ 17:20:22 2dup str-nth r> dup >r call [ 17:20:23 >r succ r> r> skip 17:20:25 ] [ 17:20:27 r> 2drop 17:20:29 ] ifte 17:20:31 ] [ 17:20:33 >r drop nip str-length 17:20:38 ] ifte ; 17:20:41 eg, : skip-blank [ blank? ] skip ; 17:20:43 actually that comment is worng 17:20:49 it should be find the next character that doesn't satisfy lol 17:20:52 neat! 17:21:28 I've been using native factor mainly lately and it has been working well. 17:21:32 the next two things at the C level i'm doing are guard pages for the stack and multiplexed i/o. 17:21:49 the former is 2x faster than explicit overflow/underflow checks. it will be a compile time option though 17:21:56 so that we can still target mmu-less hardware 17:22:23 cool 17:23:39 i get a couple of segfaults every now and then tho. 17:23:49 i havent been able to track them down 17:23:51 are you using latest cvs? 17:23:54 i fixed a gc bug a few days ago 17:24:11 ahh, that may fix it 17:24:38 there's a FP one: 1 0.1 + gives illegal instruction 17:25:06 hmm 17:26:08 let me try it in a sec when i get an image built. 17:26:17 ok 17:26:31 ( 0 ) 1 0.1 + . 17:26:31 1.1 17:26:38 yeah, try latest cvs :) 17:27:21 ok thanks 17:28:06 cadr caar cdar,etc appear to be defined backwards when compared to lisp btw 17:28:21 in factor cadr is car cdr 17:28:29 in lisp its cdr car 17:28:53 (ie. the car of the cdr) 17:29:48 yes i know 17:30:07 this is by design, eg cadr in lisp == (car (cdr, but in factor cadr == car cdr 17:30:13 i don't like using those anyway. 17:30:22 ok 17:31:09 does the inspect responder work in httpd native? 17:31:21 yes 17:31:31 also test responder runs the test suite now :) 17:31:33 in an html-stream 17:31:40 nice 17:31:57 I can pretty much use native factor all the time now then 17:34:17 gotta go, my internet connection is about to go down. talk to you later. 17:34:24 --- quit: doublec ("using sirc version 2.211+ssfe") 17:38:07 * kc5tja ponders letting the Kestrel project go for a while and resuming work on the Dolphin operating system environment. 17:38:20 what architecture does dolphin target? 17:38:35 It seems to me the hardware base for the Kestrel is changing too rapidly for me to concretely say, "Yes, this is what I want." 17:38:48 I think it's better to develop its operating system software first. 17:39:05 Dolphin was originally x86-specific, with a kernel written entirely in assembly language. 17:39:14 but you'll make it portable now? 17:39:35 But now it would be pretty portable (still working only with x86 to start with, but that's all the hardware I have to work with). 17:39:39 Yeah. 17:39:52 Most likely, I'd put it on top of the L4 microkernel. 17:40:16 I said I'd write my own cache kernel for it, but L4 already does so much of what I'm looking for, that I think it's better to just tweak or use L4 as is. 17:40:38 It'd probably be through the L4/Ka version, since that is the most recent version of the microkernel. 17:40:51 will this involve forth in any way? 17:41:23 Probably. 17:41:38 But it's not a priority. Dolphin's design is goal-oriented, not language-oriented. 17:42:12 But a Forth port to the environment is a given, since it'll take a long time even to port even LCC to the new architecture. 17:42:25 Forth is much easier and quicker to port. 17:42:31 for sure 17:42:38 so there won't be a 'native language' in dolphin? 17:42:57 No. 17:44:58 However, if I can bring FTS/Forth up under L4, and L4's API is definitely going to be exposed, then some interesting possibilities come about. 17:45:25 I can write device drivers as normal Forth applications, and communicate with other Forth programs in the system too. 17:45:38 cool. 17:45:55 Then if people want to replace them with C or hand-coded assembly later on, they are free to do so. 17:46:06 But for my personal needs, Forth will more likely than not be plenty sufficient. 17:46:21 * slava imagines factor running on dolphin :) 17:46:30 Note that L4 is a preemptively scheduled microkernel (as all good microkernels ought to be). Therefore, multitasking in FTS/Forth will be preemptive. 17:47:04 slava: Not only can it run on Dolphin, it will be a first-class citizen. Forth and Factor can talk to each other via the microkernel's message passing facilities without issues. 17:47:24 In fact, I see no reason why it shouldn't be possible to write low-level device drivers in Factor too, if you wish. 17:47:25 will dophin embody your orthogonal persistence ideas? 17:47:41 slava: Perhaps eventually. I saw a paper that documented how it was possible to achieve O/P. 17:47:53 it would be nice if installing a program started running it 17:48:05 and it kept running 'forever' 17:48:10 It obviously didn't give 100% of the details, but even so, if I have to tweak L4's sources to enable it, I will. 17:49:10 I actually would like to combine parts of the Smalltalk UI and AmigaOS' UI. Basically, the root of the desktop is the root of your filesystem (which is technically a RAM disk with mount-points and whatnot). 17:49:26 "what you see is what it is". 17:50:01 * kc5tja nods 17:50:11 And all that stuff can be written in Forth. Or Factor if you prefer. 17:50:12 :) 17:50:30 i don't intend factor to be my eternal solution :) 17:50:53 everything is a stepping stone... 17:51:32 And since L4 has been ported to the ARM and MIPS processors, moving it off of x86 and onto the Kestrel when it's time will be a relatively easy task. 17:51:55 'ported' means rewritten? or is l4 written in a HLL? 17:52:05 L4/KA is written in C++. 17:52:19 ok. 17:52:50 However, L4/x86 is written in pure assembly language. And having written 3 multitasking (though single-address-space) OS kernels myself, I can say that porting a microkernel by a flat-out re-write is EASY. 17:53:16 it comes down to the public interface being simple I guess 17:53:16 so is the system API in microkernels (well, the OS API) all performed through message passing? 17:53:17 Dolphin 0.4, 0.3, and 0.2 were all less than 10KB in size (0.3 in particular, was 7KB -- I was damn proud of the cruft I cut out of it). 17:53:40 Topaz: Applications talk to the microkernel via the CPU's normal system call procedure. 17:53:46 Topaz: Everything else is done through message passing. 17:54:10 maybe libraries should be processes too? 17:54:16 Topaz: L4, like QNX, has highly optimized message passing facilities. Most messages can be exchanged in as little as 180 clock cycles on modern CPUs. 17:54:55 slava: There is a fine line here. I'd like as much of the OS to exist as a library as possible, because it reduces administrative burden on everyone involved (see Exokernels for a reason why). 17:55:06 ah, ok 17:55:07 The Forth core will be implemented as a shared binary, for example. 17:55:27 (though one can do quite lot in 180 clock cycles on a uC ;) 17:55:37 Topaz: I have to admit at this point that we're talking about a message consisting of 3 32-bit words, which are all passed in CPU registers. 17:56:31 Topaz: Anything more than that will require memory copying and/or page remapping. This takes additional time. However, let me point out that both Linux and Windows NT *copy* their memory-based arguments from user-space into kernel-space and vice versa anyway. 17:56:46 Hence, system call overhead for L4 is no more than normal OS kernels. 17:56:59 (In short, L4 makes good on its claim of being a very high performance microkernel.) 17:57:33 Topaz: That's 180 cycles on an Intel chip. MIPS and ARM take substantially less, since their architectures are obviously simpler and more lean. 17:57:44 AND they have more registers to transfer message data with, to boot. 17:57:45 ok, sure 17:58:07 Oh, one more good reason for going with L4 -- it's Multiboot compliant out of the box. :D 17:58:16 So anyone with GRUB installed on their box can boot Dolphin. 17:58:40 (This was always the goal for Dolphin as soon as I first heard of Multiboot some years ago; however, L4 makes it so trivial to support that I don't need to worry about it anymore.) 18:00:11 HAH! I know just what to call the OS when it's done too -- L4TH. :) 18:00:18 heh 18:02:15 Actually, L4 will be nice, because it'll give me effectively hardware-level access to my box, but at the same time, exceptions like page faults and GPFs can be caught. So if a Forth session needs to terminate, it can. 18:02:30 I'm actually pretty excited about the possibilities that this offers. 18:02:42 --- quit: Topaz ("Leaving") 18:13:01 Hmmm...seems I scared a few people away. :-) 18:13:19 not me ;) 18:17:47 :) 18:20:19 The only problem that I will have is in supporting a graphical display mode. 18:20:33 Which means I'll be dealing with stock 80x25 console for most of my software. 18:20:40 In and of itself, this isn't really a hinderance. 18:20:48 But I would like to play with graphics too. 18:46:54 --- join: kc5tja_ (~kc5tja@66-74-218-202.san.rr.com) joined #forth 18:47:43 kc5tja_, VESA maybe? 18:52:00 Perhaps. 18:52:30 HEY!!! L4Linux! Totally forgot about that! I can probably hack that into the system too and make use of its networking and applications. Bwaahahahah! 18:52:45 The problem with VESA is that it's not nearly the standard that it used to be. 18:53:36 --- quit: kc5tja (Nick collision from services.) 18:53:39 --- nick: kc5tja_ -> kc5tja 18:53:42 --- mode: ChanServ set +o kc5tja 18:54:38 VESA 3.0 states that all mode numbers and their related resolutions are now firmly in the domain of each card vendor. 18:54:53 That is, you can no longer rely on mode 0x0100 being 640x480x256 colors, for example. 18:54:59 :( 18:57:33 The ultimate goal is to actually bit-bang the video hardware, but of course, this requires sources of information which I simply don't have. 18:58:17 And VESA's 32-bit protected mode interface will almost certainly be incompatible with L4's, since the application calling into BIOS will be running in ring-3, not ring-0 (which I believe VESA requires). 20:42:59 --- join: thefox (~fox@adsl-68-122-3-243.dsl.pltn13.pacbell.net) joined #forth 20:53:43 hi thefox 21:05:58 Greetings. 21:08:07 hi 21:08:42 thefox, are you jeff fox? 21:08:57 yes 21:09:08 you do colorforth stuff with chuck, right? 21:09:12 See? I told you yesterday. :) 21:09:34 kc5tja, oh :) 21:09:43 does chuck still develop colorforth? 21:10:13 I was testing out a new internet connection yesterday, never got involved in any actual discussions. 21:10:28 yes 21:10:29 yes 21:10:35 thefox! 21:10:40 ltns :) 21:10:48 Aiiee -- he's keeping a 24-hour backlog. That's not fair. :D 21:11:52 * I440r is glad /me woke up hehe 21:12:10 * kc5tja just woke up from his nap. Uugh. 21:12:26 i wish i had got into unit testing and such sooner. i'm debugging some 2 year old code of mine, and the bugs I'm trying to fix *simply would not exist* if I had unit tests. 21:13:00 kill the bugs before they get a chance to multiply 21:15:08 slava: Yep. Unit testing is the #1 most valuable technique I've learned. 21:15:32 I will try to stop in more regularly now that I have a nice Internet connection on this machine 21:15:35 define unit testing 21:16:01 I440r, running a script to make sure that 2 + 2 = 4 after each change to your source 21:16:27 thefox: Cool. :) 21:16:49 thefox do you have a 24/7 connection now ? 21:17:11 thefox: Lots of Forth-related activity of late, although nothing near as close-to-the-metal as you'd probably like. But any Forth activity is a good Forth activity, so that's what I think. :) 21:17:29 kc5tja, yeah, we all use operating systems here... :-) 21:18:06 Well, I hope that getting FTS/Forth running under L4 will provide a nice and powerful environment to work with. 21:19:22 anyone know of a good resource for finding details for USB? I haven't looked into it myself, but Chuck has and hasn't found certain info that he would like. 21:19:54 thefox usb master or usb slave ? 21:19:58 thefox: Good luck. USB, despite being somehow "open", appears to be a tightly controlled secret for many companies. 21:20:16 the slave side is kinda easy - i know the cygnal 8051's have built in usb support 21:20:35 I440r: Chuck is looking for master-interface details, obviously. 21:20:38 He also has a nice new big book about everything about USB but as far as Chuck is concerned it is everything that is obvious and reviews of products and configuration techniques 21:20:52 drivers for colorforth? 21:21:03 * I440r cant read colorforth 21:21:09 thefox: I guess I would need some more information before I can give concrete answers. What details is he looking for? 21:21:18 I440r: Colorblind? :-) 21:21:22 hehe 21:21:27 must be 21:21:30 IMHO, colorforth needs an assembler instead of ad hoc hex literals. other than that it is fine 21:21:57 isforth needs an assembler too but my source are readable :P 21:22:11 slava: I prefer the ad hoc literals. It really does cut down on the size of the system. However, he is working on CF2, written itself in ColorForth. Maybe that will have something resembling an assembler, but I doubt it. 21:22:14 I don't know. Just currious. Chuck as a colorforth that sort of boots from USB, but not without problems. More USB doc would be helpful. 21:22:26 can a system boot from memory sticks? 21:22:41 it would be slick to put in a memory stick, reboot, and you've got your CF environment right there 21:22:43 colorforth has been generated by an assembler in colorforth for long time. 21:22:53 I440r: I don't know what your problem is. I can read ColorForth source just fine. 21:23:04 That is not the public distribution that is getting rather old now 21:23:15 will there be a new release? 21:23:22 thefox why hasnt that version been released ? 21:24:31 dammit i wish tathi would show up~ 21:24:35 Chuck had planned to release a USB Flash based colorforth4 this last April but was sidetracked with focus on chip 2 fab work 21:25:19 The version that boots from floopy can metacompile a new colorforth that runs from USB, 21:25:47 but the USB version doesn't boot up exactly right itself. Chuck hasn't been working on it recently. 21:26:05 I don't even think my computer CAN boot from USB. 21:26:20 He can boot from floopy and jump to USB much faster than compiling everything from floppy as with the public colorforth 21:26:35 kc5tja, did you see that the author of pygmyforth is working on a new forth for ARM? 21:26:45 it has some CF-like features, like multiple entry/exit points 21:26:53 slava: Yeah, but it won't be as good as FTS/Forth. :) 21:26:58 slava: (j/k) 21:27:09 * slava pokes a pin at kc5tja's inflated ego ;) 21:27:17 i never like frank seargants forths :/ 21:27:23 kc5tja, actually fts/forth sounds like it would be really neat 21:27:31 All i can say is that watching thefox' video on Chuck's 1-page MachineForth compiler revolutionized how I write target compilers. 21:27:39 kc5tja, you just need to finish it :) 21:27:47 but could those techniques be applied to x86 compilation? 21:27:50 slava: The target compiler for the Kestrel code is *done*. 21:27:51 of course in OKAD II the variable for the number of tracks to save in save or load in a boot is about 28 and so it is much slower than a simple colorforth only floppy where ns (or whatever it is called) is a bit bigger 21:27:57 because this 1-page compiler is really just a parser, right? 21:27:58 slava: The Forth *environment* isn't. 21:28:18 kc5tja, hey i have an idea. you remember we had that discussion about VMs? 21:28:20 Also Chuck made some chnages to the video that make it more efficient but less portable. 21:28:29 kc5tja, well, why don't you make FTS1001 the VM??!! huh? huh? 21:28:35 thefox: Of course. :D He's Chuck! 21:28:59 slava: I am already ahead of you. 21:29:20 kc5tja, well, I know your simulator exists. 21:29:35 slava: However, I would also like to point this out: I'm probably going to put the Kestrel project on eternal freeze right now, because I cannot find a way to get the price-point of the system down. 21:29:56 yes but i'm talking about purely software here. 21:30:07 No matter what I do, no matter how hard I try, the bare system cost is going to inevitably end up no less than $300. 21:30:53 Many of the MISC compilation techniques can be applied to x86 stuff, there is Soeren's machineForth for the PC and Chuck's colorforth that both follow the models. 21:31:03 Unfortunately, $300 is substantially out of the price target most people would consider paying for a Forth-based PC here. 21:31:41 thefox: Yeah, that's what I'm using for FTS/Forth's target compiler now. It even makes statically linked ELF executables that run under Linux! (Thanks for that goes to I440r for his help.) 21:32:08 The special techniques used in AHA are not directly applicable to x86 with any great efficiency. But one could do a multi-token format compiler like AHA for x86, but there is no hardware execution of Forth tokens 21:32:27 elf stuff in linux is screwed up. things that the standard say are OPTIONAL are not optional for linux 21:33:57 elf has some overlap with aha 21:35:02 thefox: Actually, I think AHA holds some greater value than you might think for x86. As long as compilation speed is fast enough, you can make a remarkably Smalltalk-like system with it, that hopefully runs a heck of a lot faster than Squeak does. :) 21:35:36 But, AHA isn't how I think about the computer I use. In fact, I'm still not doing "Color" Forth yet. I just don't think that way. 21:35:44 well, its amazing squeak runs as fast as it does... 21:36:59 Yes. The Squeak VM is itself written in Smalltalk, which is translated to C, compiled, and that then interprets the remainder of the Squeak environment. :) 21:37:46 kc5tja, you might want to take a look at slate.tunes.org. 21:37:50 any chance of chipchuck showing up in here again ? 21:37:54 I dunno. Sometimes I wish I could innovate like Jeff or Chuck does. 21:38:12 slava: No thanks. I won't touch anything water does with a 10km pole. 21:38:12 kc5tja, they're developing a smalltalk like environment, but they're aiming for a hotspot-like JIT 21:38:19 well, water is an arsehole 21:38:23 but the technology is legitimate 21:38:26 slava: Precisely. :) 21:38:44 squeak is waters ? 21:38:48 no, slate is 21:38:50 i assume you mean water from #tunes ? 21:38:54 Squeak is most definitely NOT Water's. 21:39:08 I440r, yes 21:39:14 he is anal. you talk for 2 seconds off topic and he bitches at ya 21:39:17 slava: What do you mean by 'hotspot-like' JIT? 21:39:27 I440r: I just won't talk to him. 21:39:30 kc5tja, sun's hotspot VM. in an OOP language, a lot of the overhead is in polymorphism 21:39:35 And if he shows up here, I'll immediately /ignore him. 21:39:45 kc5tja, so it tries to find which polymorphic combinations occur most often using runtime profiling, and 'hand compile' specialized versions 21:39:48 And if he gives even the slightest amount of trouble, I have no problems kickbanning him from this channel either. 21:39:56 i doubt he'd come here :) 21:40:01 i dont go in #tunes because of him 21:40:12 he had some beef with the concatenative languages mailing list 21:40:16 and never touched postfix syntax again 21:40:18 slava: Right now, my interest lies primarily in LLVM or something very much like it. 21:40:25 what is LLVM? 21:40:33 slava: http://www.llvm.org 21:40:37 far had plans to use isforth for tunes way back because i had it up and running in 3 months, tunes had been arround for about 2 years by then and had NOTHING up and running 21:40:42 fare even 21:40:52 i think water put a stop to that one :) 21:40:54 i see 21:41:03 tunes is vaporware 21:41:11 just a dumping ground for PhDs. 21:41:13 Tunes is totally vaporware. 21:41:15 they write alot of paperworl 21:41:21 paperwork 21:41:32 its like corporate development at IT depts 21:41:34 lets write some specs first 21:41:36 water has a phd ? 21:41:39 then a ppt presentation 21:41:58 I440r, he acts like it 21:42:01 That's why I like Forth. It's vaporware to everyone except to those who it matters to. By that I mean, Chuck has his CF2, I have FTS/Forth's target compiler, etc. This software exists. Neither of us has posted it. We're both using it, and we're both excited by its possibilities. 21:42:01 hehe 21:42:06 What more need be said? 21:42:11 I just wish I had that inventor's mind like Chuck does. 21:42:31 how did people communicate pre ppt? 21:42:36 I suppose one of the reasons I won't touch ColorForth is because I don't want to just "copy" what Chuck has done. I feel I've done enough copying. 21:42:37 lol 21:42:37 i'm sure there's a handful of people for whom tunes is not vaporware :) 21:43:19 kc5tja, i don't invent, i just combine existing ideas in a new way :) 21:43:44 slava: Yeah, but that's not nearly as fun. I mean, Chuck's company, "Computer Cowboys", is named for a reason. 21:44:04 i'm looking at llvm. it looks good, but orthogonal to what you need for fast execution of OO code. 21:44:26 you really need a compiler, JIT, VM, whatever that understands polymorphism and ways of optimizing method dispatch. 21:44:38 late binding adds a whole level of complexity. 21:44:41 I mean, here I am, making a MachineForth/PygmyForth hybrid for the desktop PC, which I'm making to boot under the L4 microkernel (which itself will be very nice, I might add), and . . . and then what? 21:44:48 Well, I don't know. That'll be for others to decide I guess. 21:44:59 But I don't see it as inventing something new. 21:45:09 write at least one "useful" app. 21:45:24 Chuck wants us to try and push Forth into the future, but I just *can't*. All the cool ideas have already been taken up already! 21:45:43 im developing isforth so i can develop apps for linux and NOT have to even THINK about c 21:45:46 well i see several different directions for "future forth" 21:45:54 you can do what chuck does -- minimalism, etc. 21:45:57 but developing isforth is taking longer than i expected lol 21:46:10 * I440r is not minimalist 21:46:18 not compared to chuck 21:46:23 I440r: I can already use FTS/Forth's target compiler to build Linux binaries. 21:46:29 I440r, what is planned for isforth? 21:46:42 (which is damn sweet, I must admit. nothing like seeing a 768-byte binary in your home directory.) 21:47:02 i want to write a console based web browser with an interface thats actually USEABLE (lynx/links sucks :) 21:47:13 i want to write an entier mud server from scratch 21:47:19 then you can browse web sites served by factor :) 21:47:31 is there any way to get the page size on linux / freebsd? 21:47:34 pref. same call on both? 21:47:43 slava: Maybe the L4 integration is itself a form of innovation I guess. Minimal microkernel + minimal Forth environment, which is also capable of running ColorForth along side it as well (though it'll have to be booted in somehow)... 21:47:45 slava you mean the allocation page size ? 21:47:57 theres a syscall i think 21:48:03 I440r, i want to use mprotect to create guard pages around my stacks 21:48:26 slava why ? - stacks can be grows down in linux 21:48:50 I440r: Factor produces a bytecode, which is interpreted by a Factor VM implementation. 21:48:53 either i want to check for underflow too 21:49:05 either way* 21:49:09 you would also have to allocate the entier stack and then mprotect PARTS if the allocated memory 21:49:35 you wont know about an underflow that way 21:49:40 slava: I remember there was a syscall for it, but I can't recall what it is now. 21:49:55 you can underflow 29854623849756 bytes before doing another push and its the PUSH that would cause the fault 21:50:04 i'm not using push/pop 21:50:07 and now your outside your guard page 21:50:18 well that is a borderline case 21:50:35 for now i'll use #define. 21:50:38 slava i would never write code that popped multi K of data lol 21:50:42 forth is not c 21:50:50 but that doesnt mean a user of my compiler wouldn6t do it 21:50:50 I440r neither would i but that's not the point 21:50:56 right 21:51:25 a guard page would not guard against underflow untill your next stack write operation 21:51:52 does x86 allow unreadable/unwritable pages? 21:51:53 acutlaly, a read would do it too 21:51:58 then i could have 'drop' read TOS 21:52:01 slava yes 21:52:07 mprotect it to 000 21:52:10 either way it will be faster than explicit stack depth checks in the inner interp 21:52:13 yup 21:52:23 ok let me code this ;) 21:52:29 but the "fault" would be late 21:52:40 and that would make it harder to find where the fault is 21:53:03 you wont know where you underflowed, you would just know where you wrote to your underflowed stack 21:53:06 DAMN I love blocks!! 21:53:24 blocks are great for everything except source hehe 21:53:37 If you have LIST, EDIT (or in my base VIBE), and a tool anyone can write called INDEX, blocks become SO nice.... 21:53:53 I440r: You're a fruitcake. Blocks were invented for source code. 21:54:35 kc5 blocks dont lend themselves to my more VERTICAL coding style 21:54:35 I440r, see what i said, drop would read TOS so it would fault immediately if TOS was below the bottom 21:54:37 I admit that having free-form pages or files to keep longer than 16 lines in would be nice, but it's hardly a requirement. 21:55:15 slava ok. a read operation on every pop would slow your code down - i would suggest that for a development version of the compiler 21:55:17 I440r: I code horizontally in Forth anyway; Forth is intended for horizontal coding. 21:55:33 and i dislike the idea of one compiler for devel, another for execution 21:55:38 "fly what you test" 21:56:48 kc5 i find horizontal coding to be more difficult to read. it leaves no room for comments either and the interleaving of code and comments on alternate lines is one of my BIGGEST critisisms of the c coding community 21:57:07 it just totally breaks up the flow of the code on the eye 21:57:15 I440r, you think *that* slows it down? i better not mention runtime type checking then 21:57:24 slava eek! 21:57:26 lol 21:57:31 when coding factor i code with 64 column lines 21:57:39 "types are a crutch for poor programers" 21:57:41 -- chuck 21:57:42 hehe 21:57:43 I440r, the (future) compiler will eliminate redundant type checks though 21:58:06 without types i'd be coding just another forth lol 21:58:24 linus t likes forth but doesnt like the fact that it has no data-types 21:58:59 you mean instead of just "coding another DIFFERENT forth" hehe 21:59:10 --- quit: mur_ (Remote closed the connection) 21:59:20 OK, I'm really curious as to why gforth is suddenly forgetting that it knows 'move'. 21:59:50 I440r: Then don't. Use shadow comments (another thing only blocks can give you) 21:59:54 forth has data types 22:00:03 erm move being either cmove or cmove> ? 22:00:04 but they're determined by you 22:00:27 kc5 actually, i cant stand shaddow comments either 22:00:35 imagine doing that with flat files ? 22:00:45 hey fbsd already defines a PAGE_SIZE constant 22:00:45 I440r: Your problem is you aren't flexible. 22:00:49 always having two files per source.... one for code and one for comments 22:00:56 OBVIOUSLY you don't do that with files. OBVIOUSLY. 22:00:58 kct on some things i am 22:01:17 but its the same thing... doing it with files just exaggerates what i see as wrong with it in blocks 22:01:37 I440r: You are totally confusing and not at all making any sense. 22:01:48 Exaggerates *what* as being wrong with blocks? 22:02:04 You haven't listed anything that is wrong! Except that you don't like it. 22:02:06 kc5 comments being visually next to the soruces but NOT obstructing your view of the source! 22:02:09 thats how i code 22:02:30 So your desk doesn't have any overlapping pieces of paper at all then? 22:02:32 and alot of non asm/forth coders have told me how easy my sources are to read 22:02:43 kc5tja, haha 22:02:52 err my code is the ONLY uncluttered thing i have :) 22:03:03 I440r: I've received nothing but compliments about how I write my assembly language and my C code. 22:03:17 How I write assembly has NOTHING to do with how I write Forth. 22:03:20 Likewise with C. 22:03:56 kc5 how i write c/asm/forth/whatever is with similar coding styles 22:04:01 my style doesnt change per language 22:04:15 code code comment comment comment 22:04:31 usually with more comment text than code text 22:04:52 your eye can scan down either without being obstructed by the other 22:05:04 man gcc's warnings are totally useless 22:05:18 i just find that style easier on the eye 22:05:31 slava just realises how useless gcc is ? 22:05:35 lol 22:05:51 gcc is useful 22:05:53 warnings are not 22:05:58 Some of them aren't. If you forget a cast the asm generated may not do what you want. 22:06:14 I440r, does isforth compile and run out of the box on x86, sparc, and ppc with no ifdefs? :-) 22:06:39 slava isforth doesnt have and NEVER WILL have conditional compilation 22:06:47 good:) 22:07:10 and i am not aiming for jack of all trade code hehe (which isforth would be if i tried to make it compile everwhere out of the box) 22:07:10 I NEVER abuse comments like that. NEVER. 22:07:15 The only condition is that you run linux or linux emulation ;) 22:07:19 some things just dont lend themselves to being portable 22:07:22 The code exists for a reason -- to tell me what it's doing. Never, EVER, parrot the code with useless comments. 22:08:00 we'll see how portable factor is after this guard page business is added... 22:08:06 kc5 ya. but im of the opinion that code is NEVER self commenting 22:08:14 WRONG 22:08:15 and code and comments shouldnt be parroted 22:08:26 Forth and asm don't seem self commenting. 22:08:30 Code with properly chosen names and good structure IS self-documenting. 22:08:32 forth can be 22:08:35 kc5 write 200 thousand lines of uncommented code and tell me anyone can ead it ? 22:08:43 You need some context WRT to what the register is actually storing that you're popping something into and so on. 22:08:54 well i think in forth stack effect comments are vital 22:08:57 ive seen 6 lines of code i was totally incapable of understanding 22:09:07 but not as much 'this word does blah blah' comments 22:09:10 but those are useful too 22:09:14 sometimes 22:09:14 slava so do i... even the ( --- ) comments 22:09:19 tho i sometimes skip those 22:09:24 I440r: I've written over 40,000 lines of uncommented code while working for Hifn, and did a code review. I was forced to add comments, EVEN THOUGH UPPER MANAGEMENT CLEARLY KNEW WHAT WAS GOING ON. They said, "It's just our style." 22:09:49 It's difficult to argue w/ emotions. 22:10:06 kc5tja: If my C code, uncommented, can be understood by economists and marketers, then clearly it should be understood by anyone who actually understands C. 22:10:15 kc5 when you are there to explain your code to them then no comments are fine. your not there now... do yuou think ANYONE who picks up your uncommented code would be able to udnerstand it 100% ? 22:10:23 if not then the comments serve a useful purpose 22:10:29 I440r: yes, I do. 22:10:33 I very much so do. 22:10:45 kc5 over estimates "other people" 22:10:45 heh 22:11:21 Look, I'm not going to get into this religious war with you. But I've posted code examples here in the past. And you've seen, first-hand, how self-documenting C code works. 22:12:01 err.. pasting code here is one thing 22:12:09 you never pasted 40 thousand lines of code here 22:12:19 or even 100 lines... thats the point! 22:13:04 the logic was easy to you, you dreamed it up. you coded it. having worked as a contract programmer and having had to deal with HUGE ammounts of "simple" uncommented code... 22:13:20 i maintain a codebase of 80,000 lines of *commented* java code, and sometimes get lost. 22:13:21 ive had to totally rewrite things before now simply because the person who coded it did not comment it 22:13:57 Didn't comment it AND DID NOT USE SELF-DOCUMENTING CODE. 22:13:58 ok. the CODE might be easy to read but the logic behind it can become very hairy very quickly 22:14:02 Do you see the point here? 22:14:11 no 22:14:29 handleToReportFile = OpenReportFileForWriting(); 22:14:36 ugh 22:14:44 statistics = GetStatisticsForLastMonth(); 22:14:45 fd = open(s); 22:14:46 why not use entier sentences for function names 22:14:49 s = g(); 22:14:51 :-) 22:14:52 kc5tja: sorry that didn't work out today. 22:14:58 WriteToReportFile( handleToReportFile, statistics ); 22:15:00 CloseReportFile(); 22:15:02 slava - your code is easier to read. if there are comments tehre 22:15:04 ^-- That's self-documenting. 22:15:10 hi arke 22:15:23 HOW THE HELL CAN YOU SAY THAT'S EASIER TO READ?! 22:15:39 chill out ffs 22:15:39 @ ! <-- woudl you rather see this or 22:15:44 fetch and store 22:15:59 over verbosity is a hinderance 22:16:00 @ ! are so common that you memorize anyway 22:16:06 would you rather see */~ or openFile 22:16:09 I440r: You're changing the argument by introducing frequency of use now. 22:16:12 but they are consise 22:16:16 kc5 no 22:16:23 would you rather see ` or sortNumberList 22:16:24 im not changing my arguement 22:16:24 I would rather see OpenFile. 22:16:30 sortNumberList 22:16:36 me too 22:16:43 I440r: You are. 22:16:56 Because @ and ! are used so often that their meaning is internalized rapidly. 22:16:59 no. im not. but i guess its pointless arguing it with you 22:17:25 You're the one being pointless around here. 22:17:31 kc5 did you EVER have difficulty with @ and ! once you knew their meaning ? 22:17:33 no 22:17:36 i bet you didnt 22:17:52 You're right. I didn't. 22:17:56 So waht IS your point? 22:18:06 fopen() tells you a file is being opened. 22:18:09 It doesn't tell you what for. 22:18:20 being brief HELPS readability. being over verbose destroys it 22:18:27 for both code AND comment 22:18:28 OpenReportFileForWriting() tells you (a) a file is being opened, (b) what kind of file it is, (c) what the intended operation is for, etc. 22:18:30 to get to the other side? 22:18:34 thats over verbose 22:18:50 It is NOT over-verbose! 22:18:52 oh so you use the hungarian notation in your code ? 22:18:54 hi thefox :) 22:19:01 Because you end up writing exactly the same damn thing in the comments!! 22:19:15 I440r: hungarian is something completely different. 22:19:20 no its not 22:19:21 Umm...no...I don't. I name my variables for what they are. 22:19:32 Yes, Hungarian *IS* something completely different 22:19:39 hungarian documents types not intent 22:19:47 Precisely. THANK YOU. 22:19:55 It's *intent* that self-documenting code provides, NOT types. 22:20:03 Which is my WHOLE point. 22:20:08 and did yo not just state that your notation "tells you what kind of file it is" 22:20:10 I440r: hungarian is if you prefix or suffix the type of the function or variable. It's unnecessary with meaningful names. 22:20:15 thats the same4 as "tells you what kind of variable it is" 22:20:35 arke hungarian notation is HORRIBLE 22:20:41 I440r: no, because a binary file and text file and database file and jpeg and wahtever still use the same file handle 22:20:43 Yes, Hungarian IS horrible. 22:20:45 it just serves to add extra verbosity to the sources! 22:20:46 Which is why I don't use it. 22:20:47 I440r: I agree. 22:20:57 * arke tried it. gave up. 22:21:05 f=fopen(s,d) says NOTHING about what it does. 22:21:06 NOTHING. 22:21:15 another dumbass microsoft emplyeee invention (i believe) 22:21:39 I440r: No, actually, Hungarian was invented while Charles Symoni(sp?) was working for Xerox PARC. 22:21:40 I440r: actually, no. Hungarian notation was invented by Charles Sinyoni at Xerox PARC in the late 70s 22:21:45 kc5 when you do stack comments do you use the ANS standard for them ? 22:21:52 kc5tja: damn, you beat me to it :) 22:21:54 i dont 22:21:59 I440r: My stack comments are in shadow comments. 22:22:10 if top of stack isn an FD i call it "fd" 22:22:23 not "file-x-descriptor" 22:22:25 just fd 22:22:38 that says all 22:22:39 I440r: Depends on the context. 22:22:50 If the context is patently clear to the reader, then yes, I'll use one-character names. 22:22:56 Otherwise, NO, I don't -- I use long names. 22:23:15 I also have no aversion to using long Forth names either. 22:23:42 My Forth system will have 12 to 16 significant characters precisely because I know some of my words will be long, and share common prefixes. 22:23:52 *BUT* 22:23:56 kc5 you use a short name and explain it ONCE in the comments. the next time the person reads that name in the sources he doesnt have to read "a-variable-where-i-store-the-pulsons-fulmintator-fudge-factor" <- exaggerated for effect 22:24:01 Where the *context* allows it, I use short names. 22:24:29 Sorry, but in my experience supporting code, it just plain doesn't work that way. For me. Or for ANYONE else. 22:24:50 I'm *CONSTANTLY* having to flip back to the variable or structure's definition to find its "descriptive comment" to figure out just what the @(873*($#&(#$ it is. 22:24:56 it DOES work for you, you said so. @ and ! were explained to you and you never had a problem with them again 22:24:59 And I'm not alone! 22:25:12 And you quote me out of context -- AGAIN. 22:25:28 no. because that WAS my point when i made that arguement 22:25:34 PRECICELY my point 22:25:34 I said in no uncertain or ambiguous terms, BECAUSE OF FREQUENCY OF USE. 22:25:42 err. no 22:25:55 you are now saying you didnt understand them for some time? 22:25:56 Dude, do I have to pull from the IRC log and paste what I said? 22:25:59 Because I know what I typed. 22:26:06 ugh 22:26:19 i dont care what you said EXACTLY 22:26:35 Oh, but you apparently DO care what I say exactly. 22:26:46 This argument is fruitless and a waste of my time. 22:26:53 I have more important things to do. Thanks. Good evening. 22:26:55 no. your twisting my arguement arround 22:27:04 Dude, do I ahve pull an example of THAT too? 22:27:07 a very clever tactic 22:27:21 22:05 <@kc5tja> OpenReportFileForWriting() tells you (a) a file is being opened, (b) what kind of file it is, (c) what the intended operation is 22:27:23 brief code is easier to read than overly verbose code 22:27:24 for, etc. 22:27:28 THATS my arguement 22:27:39 * kc5tja sighs 22:27:44 and that is overly verbose 22:28:14 because every time you see an example of that item. and every other item your reading HUGE ammounts of text for small ammounts of code 22:28:20 It's overly verbose until you have to maintain someone's code who (a) hasn't been updated in years and (b) hasn't been commented by the 15 other programmers who worked on it, all of whom have had different coding standards. 22:28:27 Ask me. I maintained 700MB of source code for Hifn. 22:28:41 I don't think you can come anywhere CLOSE to that. 22:28:49 ouch :/ 22:29:15 All the code, for all of Hifn's post-silicon verification testing suites, were in ONE big-ass CodeWarrior project. :( 22:29:15 maintained or wrote 22:29:17 ? 22:29:21 MAINTAINED. 22:29:29 right. 22:29:43 now... if YOU wrote it all from scratch how much sources would there be? 22:29:48 not 700 megs im sure 22:29:55 And believe me, maintaining code like *s++=(*(g[2].m_lbpsd)); is NOT fun. 22:30:06 Besides the retarded indirections going on, what the HELL is m_lbpsd?? 22:30:19 No comments ANYWHERE. 22:30:34 I had to reverse engineer the freaking device driver before I found ONE comment that defined that field. 22:30:43 so your 700 megs might back up your arguement but it also backs up mine 22:31:10 system error 22:31:24 --- quit: thefox () 22:31:28 700 mges of anything is WAY too much lol 22:31:29 If he'd labeled it, linkControlBlockData instead, it would have been plain-as-day obvious tome what it was (given its context). 22:31:29 :/ 22:32:22 5000 entry points per function, 5000 exit points, 5000 seperate and distinct functions per fuinction lol 22:32:34 i would not have had fun with that code 22:34:35 Oh, BTW -- notice that I named it "linkControlBlockData" and not "m_linkControlBlockData" -- m_ is evil. OBVIOUSLY, since I'm referencing it with a . or ->, it's a field member. Duhh. :) 22:34:46 what exactly are 'strict aliasing rules'? gcc says i'm breaking them in one place 22:35:01 kc5tja, yeah, i've seen m_ prefixes in java code as well, its annoying 22:35:32 m_ = hungarian 22:35:37 kc5 didnt the amiga prefix variable/function names on a per library basis ? 22:35:45 m_ is not ungarian 22:35:46 slava: It's where one code appears to be referencing a variable via a pointer where the compiler expects it to NOT happen; e.g., what one function thinks is A, another maybe thinks is B, yet they're occupying what the compiler thinks to be the same memory location. 22:35:59 ucFoo <-- hungarian 22:36:01 m_ is hungarian. m_ prefix is used for all "member variables." 22:36:08 oh 22:36:18 Sorry, you need to read up on Charles' updated Hungarian style for C++. 22:36:31 erm no i dont :) 22:36:42 c++ *belch* 22:36:46 * kc5tja hopes Charles Simonyi hangs from his little toe for life for his little contribution to computer science. 22:36:54 :D 22:37:06 C++ with all of its run-time options turned off is actually not that bad. Just don't use templates. 22:37:16 Templates *will* kill a program cold. 22:37:17 not to mention that in his original style, he even omited all the vowels in his words :) 22:37:25 templates are the only redeeming feature 22:37:26 Well, not kill it, but will certainly kill any claim that it's "small." 22:37:30 Bahh. 22:37:31 you get greater time safety over C 22:37:34 otherwise its a total crock of shit 22:37:38 the OOP in c++ is a joke 22:37:41 Give me a langauge with true parametric polymorphism anyday. 22:37:44 s/time/compile time/ 22:37:47 C++ != OOP :) 22:37:53 kc5tja, of course 22:37:54 The OOP in C++ isn't bad if you use it properly. 22:37:59 kc5tja, i'm not claiming c++ templates beat ML etc. 22:38:06 or a non-typed language. 22:38:54 I love how people always tell me how the OOP in C++ always "sucks," then fail to proceed to give me any better example. 22:39:22 C++ can do 80% of what Smalltalk can, and does it faster. For most applications written to use OOP, that's all one needs. 22:39:53 the problem is taht *C* can do 80% of what C++ "OOP" can with less pain 22:40:07 However, I will NEVER forgive Bjarn Stroutroup for this abomination: cout << "Hello!\n"; 22:40:20 you mean cout << "hello" << endl; :) 22:40:22 slava: I respectfully disagree. 22:40:47 C++ and C are very much equivalent from a functional perspective, yes, but C++ is notationally much more concise and clear. 22:40:50 foo -> bar(); 22:40:51 vs. 22:40:56 foo -> bar( foo ); 22:41:12 you mean vs. bar(foo)? 22:41:17 And of course, declaring the classes and instantiating them are much easier in C++ than in C. 22:41:24 HOWEVER, C does give more control. :) 22:41:38 slava: No, I mean foo -> bar( foo ). 22:41:42 I'm comparing apples to apples. 22:42:04 struct Foo 22:42:05 { 22:42:11 ok i see what you mean 22:42:14 virtual void Bar( void ) = 0; 22:42:16 }; 22:42:17 versus 22:42:22 typedef struct Foo Foo; 22:42:29 typedef struct Foo_vtbl Foo_vtbl; 22:42:30 22:42:31 C++ is so complex. I find templates difficult to read, and I don't like the idea of any function being able to use & to get a reference. It gets rid of the call by value idea, and hides the possible change from the programmer. 22:42:34 struct Foo_vtbl { 22:42:43 void (*Bar)( Foo * ); 22:42:44 imaginator, references are just syntax sugar 22:42:44 }; 22:42:44 22:42:47 struct Foo 22:42:48 { 22:42:54 Foo_vtbl *vtbl; 22:42:56 ..etc.. 22:42:58 }; 22:42:59 kc5tja, this is assuming you *need* a vtable though. 22:43:25 Yes, that is true -- assuming you do need it. But OOP is all but useless without polymorphism. 22:43:33 So this is a vital consideration. 22:44:12 And when it comes down to component-oriented programming, it's ALL about polymorphism. 22:44:20 Ask me -- I wrote GCOM. :) 22:44:35 (aka "Andromeda" for the AmigaDE project several years ago) 22:45:55 My biggest beef with templates is that (a) it slows the C++ compiler down with what appears to be O(n^2) performance. It's horrifying how big the difference is when you introduce even one template into a C++ project; it is quite observable. And the more templates and/or template instantiations you have, the more memory and the more slower it goes. 22:46:35 Also (b) the syntax is just plain broken. There is an issue with spacing in the compiler because template versus template < t > mean different things! 22:46:51 Oh, I remember what it was now. 22:47:04 template< template< t > > versus template> 22:47:10 Note the >> 22:47:16 As in the right shift operator. :D 22:47:26 c++ syntax is... umm... "original". 22:47:34 lol 22:47:38 the gcc c++ parser actually had to be scrapped 22:47:39 Yeah, and it's being copied by everyone now it seems. 22:47:42 I like how Scala does it. 22:47:44 their lex/yacc or whatever couldn't parse it properly 22:47:47 kct thats worse than x=y+++++y 22:47:51 in 3.4, they *rewrote the parser by hand* 22:47:52 It treats types as first-class objects (even though they aren't in reality). 22:47:56 So you can do this: 22:47:57 what is scala/ 22:48:04 (to borrow from C++'s syntax) 22:48:06 class Foo 22:48:06 { 22:48:09 Type T; 22:48:13 T *something; 22:48:14 }; 22:48:34 wow! 22:48:41 very interesting 22:48:52 Scala is a pure functional language that compiles to JVM that is, shall we say, rather ambitious in scope. But apparently it works well, and I've heard very good reports from those who have used it. 22:48:57 ok, explain that to me 22:49:22 Class Foo cannot be instantiated without a type, because T would be uninitialized. 22:49:38 Until T is explicitly given Foo is an abstract class (just as if a method remains undefined). 22:49:58 Since the compiler knows that T is a parameter AND it's a type, it follows that any member of the class can now be of type T as well. 22:50:03 Hence, parametric polymorphis. 22:50:06 Hence, parametric polymorphis, 22:50:10 Hence, parametric polymorphisM 22:50:12 :) 22:50:20 compiling for the JVM is tricky business. 22:50:40 I don't like Scala's overall syntax, but THAT is very nice and clean langauge design. 22:51:14 I do NOT know, however, how one actually instantiates a member of that class. I *think* it's something like this, but I'm not sure: 22:51:20 class IntFoo : Foo 22:51:21 { 22:51:25 Type T = int; 22:51:26 }; 22:51:36 there is a language D 22:51:44 it as C++-like templates but with less clutter 22:51:47 I think you just write 22:51:49 class Foo 22:51:49 { 22:51:52 T t; 22:51:52 } 22:51:56 then Foo 22:52:00 but i'm not sure 22:52:47 Anyway, I'm pleased to report that this is yet another night that I got absolutely NOTHING done. :( 22:52:56 i got guard pages working :) 22:53:08 running tests. 22:54:10 OK, can anyone tell me why this works in GForth: 22:54:14 A B copy 22:54:17 C D copy 22:54:19 but this doesn't? 22:54:34 : copy2 2dup copy 1+ swap 1+ swap copy ; 22:54:36 A B copy2 22:54:44 I'm totaly baffled. 22:54:51 totally 22:54:53 * kc5tja sighs 22:54:54 are you sure copy doesn't leave anything on the stack? 22:54:58 Apparently, I can't type tonight either. 22:55:01 Positive. 22:55:47 Oh, and then, after copy2 actually copies the first block, it errors out with a "copy" not found error, and suddenly copy2 conveniently "isn't defined" either. 22:55:50 >:/ 22:55:52 my gforth doesn't even have 'copy' 22:55:58 see copy 22:55:58 *the terminal*:1: Undefined word 22:56:08 slava: I defined it. It's part of my block source management words 22:56:16 oh 22:56:19 copy2 is a new word I just hacked up on the spot though. 22:56:27 A B are block #? 22:56:34 Yeah. 22:57:03 does copy allot/forget storage? 22:58:59 Nope. 22:59:07 random pointer corruption is what managed languages aim to avoid... 22:59:07 7 : c swap block swap block update 1024 move ; 22:59:13 That's the core of COPY right there. 22:59:33 try debugging by brute force 22:59:37 add .s after each factor of copy2 22:59:37 That's the only place pointers ever come into play. 22:59:39 and add here . 22:59:57 Tried that. Nothing helps. 23:00:06 Stack is (predictably) empty after each invokation of COPY. 23:00:14 tried typing out copy2 at the outer interprter? 23:00:18 does this still forget copy? 23:00:37 *insight* 23:00:48 Thanks for the suggestions. I think I just found it. 23:01:34 I forgot that, because everything is built as an overlay, all my utility words start with EMPTY. :) So copy2 is undefined by the next time it's invoked. :) 23:01:57 EMPTY does what? restore HERE to a prior value? 23:02:02 yeah 23:02:08 aha :) 23:02:16 It "empties" the dictionary to its last recorded fencepost. 23:02:24 by MARK 23:02:25 :) 23:02:28 right. 23:02:28 great facilityy 23:02:33 yes, although I also have "unmark" too. :) 23:02:47 So unlike Chuck's ColorForth, I can have nested contexts of software. 23:02:55 :) 23:03:06 Normally it works very well. But, you gotta admit, there is some niceties to the Smalltalk-way of doing things. :) 23:03:20 smalltalk way is another layer of indirection between word & definition? 23:03:38 slava: Dude, Smalltalk has "indirection" in its middle name. EVERYTHING in Smalltalk is indirect. :) 23:03:58 as i expected, removal of manual stack pointer checks has given me almost exactly 2x the performance on any benchmark i can come up with so far. 23:04:03 building a new image, 34 fib, ... 23:04:16 still, cfactor is embarrasingly slow. 23:04:27 Heheh 23:04:34 Is it slower than Smalltalk? 23:04:41 Well, Squeak rather? 23:04:49 * kc5tja really does want to learn more about Smalltalk. 23:04:55 It looks like a NICE langauge to learn. 23:05:29 smalltalk also greatly rewards well factored code 23:05:42 To some extent, yes. 23:05:43 :) 23:06:13 * kc5tja was considering writing a very simple, and albeit completely original, Smalltalk environment just to try it out. 23:06:28 in forth maybe? 23:06:34 Only mine would compile directly to machine code, not to bytecode. 23:06:41 No, starting from assembly language. 23:06:46 ok 23:06:57 beat water at his own game ;) 23:07:06 Heh 23:07:36 My idea would be to make it subroutine threaded instead of bytecodes (which is just token threading, really), with some minor amount of inline assembly language for some simple stuff. 23:07:53 I suspect it'll still be pretty slow over all, but it ought to be faster than Squeak. :) 23:08:00 definately. 23:08:18 STC will make image load/save a bit more complex though 23:08:31 relocation becomes tricky 23:08:38 unless you want non relocatable images, which is fair enough. 23:08:52 x86 uses all PC-relative offsets for all branches. 23:09:10 The only time it doesn't is when you load an address into a CPU register, and branch through that. 23:09:29 But even then, you can easily store only offsets in registers by doing a VERY evil trick. Check this out: >:) 23:09:39 CALL dummy 23:09:40 dummy: 23:09:55 ADD [ESP+0], 23:09:58 RET 23:09:59 done. 23:10:01 >:) 23:10:07 oh i wasn't aware of this. thakns for the tip 23:10:22 CALL puts the current EIP on the stack, ADD adjusts it, and RET branches right to it. :) 23:10:23 * slava takes a note for his eventual x86 compiler project 23:10:25 --- quit: arke ("bbl") 23:10:30 And if is in a register, all the more the better. 23:11:31 I440r is probably vomiting at that code, sinec it's such a dirty hack... :D 23:11:51 and it is kind of on the slow side as far as x86 coding tricks go. But there's no arguing -- it does work! :) 23:12:35 anything will be faster than iterating down a *cough* linked list in the inner interpreter. 23:13:53 Heheh :D 23:14:00 Yeah, at least the cost of the above code is finite. 23:14:46 And if it's called enough times, I suppose that the branch prediction logic will finally start to catch on about the "CALL dummy" instruction, and it'll eventually take 0 cycles. 23:16:14 I wonder how hard it would be to build a parser for Smalltalk, and then how hard it would be to build a decent code generator for it. 23:16:22 parsing smalltalk is easy 23:16:36 I mean, if the Squeak VM can be written, "in a functional subset of Squeak itself," then it ought not to be very hard. 23:16:54 Until you get into block support. 23:17:02 hey, if FTS/smalltalk becomes a reality, i'd surely contribute. 23:17:06 blocks are easy to *parse* 23:17:18 to execute, you need a spaghetti stack 23:18:00 x _ [4 = a] ifTrue: self OpenReportFileJustToPissOffI440rAndThenDoItAgain with: aReportFileJustForI440r. 23:18:03 ;D 23:18:16 What do you mean by Spaghetti stack? 23:18:25 You mean a stack with stack frames on it? 23:18:47 well consider this 23:18:50 if you return a block from a method 23:18:57 you can't deallocate that method's stack frame 23:19:05 since the block might execute and need that method's local variable context 23:19:19 so you need to either heap allocate all stack records, for be clever and do it if necessary 23:19:52 Right, because a Smalltalk block is a closure. 23:20:18 yes :) 23:21:02 When were closures introduced into Smalltalk? 23:21:21 older squeak releases didn't have them. 23:21:29 if you used a block outside its dynamic extent, an error was raised. 23:21:39 closure in smalltalk is not as vital as it is in lisp. 23:21:45 in lisp, closures are unsed instead of objects in many places 23:21:51 in smalltalk, well you use *objects* 23:21:53 I don't mind heap-allocating frames either. Henry Baker has done experiments which concluded that, beyond a certain point, heap-allocated stack frames are actually faster than stack-allocated frames. :) I forget the tradeoff point though. 23:22:04 depends on your GC I guess. 23:26:37 Yeah, the GC is pretty important. 23:26:46 If the GC is anything like Oberon's GC, then it would be pretty quick. 23:27:05 But Oberon has the advantage of storing type descriptors for everything, so it unambiguously knows what is and is not a pointer. 23:27:50 But Baker has a point: when you think about it, there *IS* a point when GC becomes faster than stack management. 23:28:06 * kc5tja will have to find that URL for you -- I think you'll enjoy it. 23:58:43 --- join: arke (~chris@wbar8.lax1-4-11-100-108.dsl-verizon.net) joined #forth 23:59:59 --- log: ended forth/04.08.11