00:00:00 --- log: started forth/04.08.08 00:01:53 as an aside... 00:02:01 i bought a CD (Red hot chili peppers) 00:02:04 before i knew that 00:02:10 because I don't get paid until thursday 00:02:19 so I have one day to scratch together $50 :/ 00:02:31 * arke thought it would only cost like $10, as it should for such a tiny simple thing 00:08:11 Yeah, welcome to the world of automotive upkeep. 00:08:24 7fuuuck 00:08:39 but at least i can fix it myself once i have the part 00:29:41 --- quit: crc (Client Quit) 00:38:28 --- quit: mur_ (Remote closed the connection) 00:39:00 --- join: mur (~mur@smtp.uiah.fi) joined #forth 00:50:50 --- quit: sallust (Read error: 104 (Connection reset by peer)) 00:56:24 --- join: sallust (~reynaert@189.205-201-80.adsl.skynet.be) joined #forth 01:08:24 clear 01:08:26 oops 01:09:04 hi 01:09:06 talk to me 01:09:08 teehee 01:09:16 kc5tja: #f 01:09:22 I'm planning on going to bed soon, but I just got done toying around with Smalltalk again. 01:09:26 er 01:09:27 nevermind 01:09:31 okies 01:09:39 * kc5tja is getting some ideas for the Kestrel. 01:09:43 got version numbering idea for F 01:09:47 F = old DTC 01:09:50 F2 = new STC 01:09:59 F3 = F2 + GUI + enhancements 01:10:08 F4 = ... dunno yet, but itll be leet 01:11:05 Did you see the earlier posts here about the virtual machine concept idea I was writing about? 01:11:28 I'm thinking of abandoning the TTA processor idea. 01:11:34 At least for now. 01:11:41 oh, no didint read it 01:11:44 i will read logs later 01:11:45 :) 01:11:51 (unless you wanna give me short summary) 01:12:33 Short summary: build a bytecode evaluator (e.g., a virtual machine interpreter) that works by emulating a virtual CPU with an explicitly managed data and code cache. 01:13:13 Because both data AND code caches are explicitly managed, it lets the VM interpreter intelligently JIT-compile the bytecodes for maximum run-time performance. 01:14:15 So, for example, branch targets are NOT addresses. They are cache lines. 01:14:29 And instruction "fetches" always start at the beginning of a cache line. 01:14:56 cool 01:14:57 So to implement a subroutine call or conditional branch or whatever, you first need an instruction to translate a virtual address into a cache line, and then issue the jump to that cache line. 01:15:05 would ARM do good in a Forth? 01:15:21 ARM would do about as good as any other RISC. 01:15:21 ('specially because of the inline conditionaals or whatever they are called) 01:15:25 oh. 01:15:35 hey, i already asked that, nevermind 01:15:35 :) 01:19:51 Basically, the way I see it, the VM interpreter can read bytecode directly from disk, and just use RAM as its cache. 01:20:08 To start with, I could use the OpenRISC architecture. 01:20:09 cool. 01:20:14 Later on, maybe I can use PowerPC. 01:20:35 And then, later still, a fully customized processor that executes ONLY from on-chip RAM (even if it's only in the kilobytes). 01:36:29 Well, I'm off to bed. 01:36:31 Good night! 01:36:37 --- quit: kc5tja ("THX QSO ES 73 DE KC5TJA/6 CL ES QRT AR SK") 02:02:49 --- join: mur_ (~mur@uiah.fi) joined #forth 02:15:20 --- quit: mur (Read error: 110 (Connection timed out)) 02:35:41 --- nick: Tomasu -> TomasuDlrrp 02:35:46 * TomasuDlrrp is away: night 03:07:45 --- quit: mur_ (Remote closed the connection) 03:08:16 --- join: mur (~mur@uiah.fi) joined #forth 04:04:39 --- join: mur_ (~mur@kyberias.uiah.fi) joined #forth 04:07:36 --- quit: mur (Read error: 60 (Operation timed out)) 04:09:02 --- nick: mur_ -> mur 04:47:06 --- join: Klaw (~anonymous@ip68-228-92-218.oc.oc.cox.net) joined #forth 05:06:30 --- quit: mur (Remote closed the connection) 05:07:02 --- join: mur (~mur@kyberias.uiah.fi) joined #forth 05:59:45 --- join: Topaz (jonny@spc1-horn1-6-0-cust217.cosh.broadband.ntl.com) joined #forth 06:05:54 --- join: mur_ (~mur@kyberias.uiah.fi) joined #forth 06:17:28 --- quit: mur (Read error: 110 (Connection timed out)) 06:39:09 --- join: FlamingRain (~Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 07:02:50 --- quit: FlamingRain ("Leaving") 07:41:32 --- join: FlamingRain (~Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 07:44:21 --- quit: madgarden ("*frotz*") 07:45:49 --- join: madgarden (~madgarden@Kitchener-HSE-ppp3576090.sympatico.ca) joined #forth 07:49:39 --- join: mur (~mur@uiah.fi) joined #forth 07:51:53 --- quit: mur_ (Read error: 60 (Operation timed out)) 08:22:36 --- join: ASau (~root@217.16.31.100) joined #forth 08:22:51 Dobry den! 08:23:57 Privet, ASau :) Kak ty? 08:27:30 Khorosho! 08:28:13 Which means? :) 08:28:45 I've occasionally discovered I've got 17000 lines of Forth. 08:28:58 Related included. 08:29:08 Heh. In one project, or together? 08:29:10 Khorosho means well. 08:29:16 Together. 08:29:24 Nice.. That's quite a lot. 08:29:37 I don't like this 08:29:48 I wish it would be less. 09:15:39 --- quit: FlamingRain ("Leaving") 09:40:24 --- join: mur_ (~mur@smtp.uiah.fi) joined #forth 09:51:20 --- quit: mur (Read error: 110 (Connection timed out)) 09:56:51 --- quit: I440r ("brb") 09:59:42 --- join: FlamingRain (~Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 10:26:22 --- join: kc5tja (~kc5tja@66-74-218-202.san.rr.com) joined #forth 10:26:29 --- mode: ChanServ set +o kc5tja 10:31:52 Hi 10:33:03 --- quit: FlamingRain ("Leaving") 10:33:56 Howdy. Reading up on the OpenRISC architecture again. 10:34:44 Planning to implement it? 10:38:02 That's what it's looking like. 10:38:18 The TTA is a nice concept, but man, I don't want to have to spend another three months hacking away at it and a software emulator for it. 10:38:53 And plus, I'm really experiencing some stiff design issues that I can't really work around right now. 10:39:35 I think just going with the OpenRISC architecture will simplify the design process significantly, since it's already designed and tested, and should fit in the FPGAs that I intend on using. 10:42:46 The OpenRISC architecture implementations also include data and instruction caches, plus separate data and instruction MMUs too -- so it's conceivable that I can implement an OS that uses a single-level store. 10:43:28 of course, the Forth system that it'll run from ROM will largely waste the capabilities of the underlying CPU, since Forth just plain doesn't have a real need for all these other features. 10:44:28 So people will have to write non-Forth programs if they want speed? 10:44:29 (I could, of course, build the CPU without the MMUs, and with only 16 registers instead of 32 -- but I'd rather keep these features if I can afford to.) 10:45:01 Or build/write an optimizing Forth compiler for it. 10:45:53 Since the OpenRISC architecture isn't superscalar, it's much easier to make a Forth compiler that produces half-way decent code for the CPU. 10:46:10 *BUT*, Forth has no need for 16 registers, let alone 32. It's perfectly happy with 8. 10:46:21 And it has no real need for any MMU what-so-ever. 10:46:53 --- join: FlamingRain (~Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 10:47:22 Hehe, with 32 registers almost any Forth program could be optimized to only use registers. 10:48:03 Yep. I have often wondered about the possibility of writing a small MachineForth implementation that used the CPU registers exclusively as a data stack. 10:48:04 well hopefully the architecture allows you to only save registers you used when doing calls and context switches. 10:48:44 OrngeTide: What do you mean? 10:48:59 Interrupt handlers save the registers they *use*, not what has been modified. 10:49:20 So if you want lightning fast interrupt handlers, use only a small number of registers. 10:50:58 i'm not familiar with how openrisc works. I just know some architectures allow you to mark what registers to save in a bitmask or mark them by saying you want to use r0 to rX where X is the number you passed to call. 10:51:23 OrngeTide: I'm not aware of a single RISC architecture that does that. 10:51:38 like a pdp-11 for example has the MARK instruction 10:51:44 Certainly not PowerPC, MIPS, nor SPARC. Oh, and also not OpenRISC. 10:52:04 kc5tja, sparc has an alternate solution. 10:52:08 The only CPU I'm aware of that remotely has that capability is the 680x0 series, with the MOVEM.x instruction. 10:52:26 powerpc can do it. but nobody ever uses it since gcc and codewarrior don't support it for calling conventions. 10:52:39 OrngeTide: Yeah, and that's not very flexible either. :) 10:52:48 kc5tja, 68k is inspired from pdp-11. they have a lot of simular instructions. 10:53:01 msp430 also can do it. iirc 10:53:27 OrngeTide: PowerPC cannot do it, as it's defined in my 32-bit PPC Architecture manual. What instruction are you talking about? PowerPC doesn't even define the concept of a stack in hardware, so how can it save only modified registers? 10:54:12 you just answered your own question 10:54:38 No I didn't. 10:54:42 I'm just as confused. 10:56:30 the hardware doesn't save a dirty flag or anything. you just have to tell it what registers to save. you said it doesn't have a concept of a stack in hardware. that is the answer, it doesn't have the concept of alot of things, but it is quite easy to implement it in software, and on powerpc the cost assocaited with saving registers individually is not high if you only have a few registers you are concerned with 10:56:32 Anyway, if I do implement the OpenRISC 1200 CPU core, I will modify it slightly. I will make the register set a circular stack. 10:57:02 --- join: I440r (~mark4@216-110-82-59.gen.twtelecom.net) joined #forth 10:57:34 i would rather have a 32-bit pdp-11 like system if I were doing a forth. it's ideal. 10:57:42 Since many of the CPU's instructions have reserved bit fields, I can use those bit fields to implement push and pop controls that operates on the internal stack of registers. 10:57:52 since every general purpose register can be used as a stack pointer. 10:58:07 OrngeTide: It's also complex, and guaranteed, every instruction would consume more than one clock. 10:58:38 yea. it depends highly on what parameters you passed to the instruction. 10:59:15 OrngeTide: The same is true in OpenRISC. Since the architecture does not define a stack concept in hardware, though, you must manually add or subtract values to the registers (or cleverly use its auto-update feature, which I see is taken shamelessly from PowerPC). 11:00:09 but if you're using forth on a even remotely modern architecture you probably aren't concerned with performance. most forths are direct or indirect threaded and don't have native compilation. and if they do they rarely take the architecture into account and optimize approriately. 11:00:29 OrngeTide: Unless you're in the business of it. 11:00:30 kc5tja, i'll have to check out openrisc. it sounds interesting 11:00:57 kc5tja, i know of no forth company that is interested in performance numbers on a modern architecture. 11:01:05 OrngeTide: OpenRISC is very interesting. The only problem I have with it is how it handles a 64-bit virtual address space. But otherwise, it looks to be a very workable solution for my needs. 11:01:38 neat. has anyone made real hardware yet. or do you need a fairly large fpga to do openrisc? 11:01:51 OrngeTide: Forth, Inc. has a native-code compiler, as does Stephen Pelc's company (forgot the name), both of which rival MSVC in runtime code performance. 11:02:07 HA 11:02:29 iForth from Marcel Hendrix also rivals MSVC, and even blows its doors off in FPU performance. 11:02:45 BigForth is *consistently* equivalent to GCC -O3 performance. 11:03:07 --- quit: ASau (Read error: 110 (Connection timed out)) 11:03:17 I mean, they're out there. Optimizing compilers, especially those that follow the RAFTS recommendations (written by the authors of GForth and BigForth), are quite doable, but are rather on the complex side. 11:03:27 But then again, ANY optimizing compiler is on the complex side. 11:04:03 --- quit: FlamingRain ("Leaving") 11:04:22 I mean, if Lisp can be compiled to near-C or near-assembly speeds (and we all know how incredibly MORE dynamic Lisp is than Forth!), then Forth certainly should be able to do it too. 11:04:27 but I digress. 11:04:38 I am not interested in that kind of performance right now. 11:04:50 true. but i'd rather have a compiler compiler than have to make my own code more complicated to compensate. which has been what i've had to do before. 11:04:59 right now, I want a box that is "good enough" for my needs, and I'm really getting tired of waiting and waiting and waiting for its CPU to get done. 11:05:32 well i don't consider gcc and msvc to be significant players in high performance optimization. which is why i said "HA" 11:05:39 * kc5tja isn't familiar with anyone having to make their own code more sophisticated to have ti compile on the other Forth systems. 11:06:03 You can say "HA" all you want; fact is, code from those compilers constitutes 99.9999% of all software for the PC platform. 11:06:05 that's not what i said. 11:06:11 That's how I interpreted it. 11:06:40 yea. and PCs are 3Ghz because nobody cares about software performance. i don't care about it either when it's just some crappy desktop and i have dirt cheap and nearly unlimited processing power 11:06:50 Besides, I'm not aware of any compiler that can much go beyond what GCC and MSVC produces for the x86 platform. 11:07:09 i meant I changed my code to perform better because compilers rarely optimize it very well. 11:07:22 Oh, now see, I personally prefer that approach. 11:07:28 kc5tja, intel's compiler does. codewarrior does better than gcc at least. 11:07:50 yea. i do too. as long as my changes aren't overly redundant or complicated. 11:08:10 I am of the opinion that the compiler should be, like all tools, simple enough for anyone to understand, even at the expense of performance. If you need fast software, profile, and then hand-tweak the slowest parts of the code for your needs. 11:08:39 that's pretty much what i do every day since my last 3 jobs all use gcc. 11:08:48 I mean, the compiler can and should optimize where it can, but never at the expense of human maintainability. 11:09:07 well i don't have to maintain the compiler. so i don't care about it's complexity. 11:09:53 --- quit: mur_ (Remote closed the connection) 11:09:56 well i gotta go do laundry. ttyl! 11:10:10 Laters. 11:10:28 --- join: mur (~mur@mgw2.uiah.fi) joined #forth 11:10:39 And, actually, PCs are 3GHz because of the clock-speed wars; prior to the onslaught of 3-D, first-person games, 33MHz was more than enough for anyone on the PC market. 11:11:38 Interestingly enough, the higher the clock speed, the worse the computer performs, due to its gargantuan pipelines. As long as you keep those pipelines filled, everything's great. Unfortunately, that's awfully hard to do with a 25-stage pipe, even with unrolled loops and other tricks of C programmers. 11:22:55 WHOA! This thing has hardware-supported multitasking!! 11:23:08 neat 11:23:20 Check this out: the CPU supports up to 16 concurrent "contexts" in its register space. 11:23:34 Each context has only 32 GPRs, but in supervisor mode, you can access up to 512 GPRs. 11:23:42 is this like register windows? 11:23:54 Apparently, as I understand what I've read so far, every interrupt causes the "CID" value to auto-increment by 1 (if it's enabled). 11:24:01 No, these are wholesale different *tasks*. 11:24:07 As in, Unix processes! 11:24:10 oh that's really cool 11:24:37 Yeah. I didn't even realize it did that. 11:24:58 so your top 15 unix processes could be made to work here. 11:25:03 This makes a cache kernel design more important on this architecture, since the cache kernel can cache individual processes and map them to CPU contexts. 11:25:45 Well, the 15 or 16 processes last known to run, yeah. Though, in most systems, they're also the most likely to be run again too, so it makes some sense. 11:26:54 Note that it's also configurable too -- you can implement the OR1K CPU without CID support (well, it HAS it, but is hardwired to just context 0), or with any power of 2 contexts up from there. 11:27:07 16 is the maximum, since the SR[CID] field is only 4 bits wide. 11:27:33 even 4 could be quite useful. 11:27:36 For a 32-bit implementation, that is. On a 64-bit implementation, I suppose it could be larger, since bits 32-63 of SR are undefined. 11:27:40 Yes, very. 11:27:52 i'd assume 15 processes because 1 context might be needed for the kernel. (drivers?) 11:27:55 I haven't seen something like that since the Z-80. :) 11:28:13 is anyone making openrisc commecially? 11:28:13 I'm not quite sure how that works yet. I'm still reading. 11:28:22 OrngeTide: Flextronics has a microcontroller based on it. 11:28:28 oh neat 11:28:42 And it has been tested in various FPGAs, up to 33MHz in the (older) Virtex II. 11:28:49 I wonder how fast it'll run in a Spartan IIIe. 11:29:02 Although, 33MHz is *plenty* fast enough for my needs. 11:29:14 my company actually uses flextronics for manufacturing 11:30:02 yea. 33Mhz will go pretty far for normal applications. (obviouslly it's not a super computer) 11:30:14 although you mentioned that it wasn't superscalar... 11:32:27 Nope. But I don't see it as impossible to implement superscalar operations for the CPU. 11:32:34 And it's written in Verilog, which is SOOOO nice. :) 11:32:47 VHDL is cool, but man, it's so damn heavy for what I'm looking to do. 11:37:45 brb 11:39:50 back 11:39:55 * kc5tja is reading the exception handling chapter now. 11:50:24 Ah ha. I see how this works; the CID is incremented by the exception, and the l.rfe instruction (return from exception) will auto-decrement it. So the contexts actually forms a stack of contexts, not a round-robin scheduling of them. 11:52:57 Gahh, but not there is something else called "current context register", which apparently supports up to 65536 internal register sets and 65536 address space IDs. 11:53:02 Still reading. 11:57:03 --- join: FlamingRain (~Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 11:59:01 Ah, I think I understand now. 11:59:52 Or, scratch that, maybe not. 11:59:54 * kc5tja sighs 11:59:57 This is very confusing. 12:20:20 --- quit: FlamingRain ("Leaving") 12:52:39 --- join: mur_ (~mur@smtp.uiah.fi) joined #forth 13:01:29 Well, the whole context thing is very weird for me. I think what needs to happen to support this kind of multitasking is you turn *OFF* fast context switching, since doing so causes *all* exception-related meta-data to be stored in CID 0's registers. Also, CID is reset to zero on exception if fast context switching is turned off. 13:02:15 Then, the exception handler is responsible for remembering the last context and determining the next context to jump to, at least after processing the exception. 13:05:16 --- quit: mur (Read error: 110 (Connection timed out)) 13:07:21 --- nick: TomasuDlrrp -> Tomasu 13:07:24 * Tomasu is back (gone 10:31:39) 13:26:01 --- join: FlamingRain (~Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 13:30:07 --- quit: mur_ (Remote closed the connection) 13:30:41 --- join: mur (~mur@uiah.fi) joined #forth 13:50:14 --- quit: FlamingRain (Connection timed out) 13:51:13 OK, looks like the OR1200 is a very minimal implementation of the complete OR1K specification. This is good enough for my purposes. 13:51:45 I can start off with an OR1200 for the current Kestrels, and if demand is high enough for further models, I can make newer, higher-performance processors on an as-needed basis. 14:04:49 --- join: FlamingRain (Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 14:13:28 hi FlamingRain 14:13:36 hello :) 14:16:59 --- join: mur_ (~mur@uiah.fi) joined #forth 14:17:35 * slava is hacking the TUI for his language. 14:19:51 --- quit: mur (Read error: 60 (Operation timed out)) 14:29:57 * kc5tja is rather very upset with OpenCores.org -- their servers must run on VIC-20s, I swear. 14:36:06 --- quit: FlamingRain ("Leaving") 14:41:49 --- nick: Tomasu -> TomasuFood 14:59:50 --- join: FlamingRain (~Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 15:22:33 --- quit: FlamingRain ("Leaving") 15:24:53 --- part: Frek left #forth 15:25:42 Server Error 15:25:42 The server encountered a temporary error and could not complete your request. 15:25:42 Please try again in a minute or so. 15:25:47 that's the first time i've done that to google 15:40:52 That happens sometimes when I'm trying to read my gmail. 15:50:40 --- quit: Topaz ("Leaving") 16:01:03 --- nick: TomasuFood -> Tomasu 16:12:07 --- join: doublec (~doublec@coretech.co.nz) joined #forth 16:13:46 --- quit: mur_ (Remote closed the connection) 16:14:17 --- join: mur (~mur@smtp.uiah.fi) joined #forth 16:17:23 hi doublec 16:17:44 hi slava 16:18:06 doublec, i fixed a bunch of bugs in the listener in cvs 16:18:08 its much more usable now 16:18:24 cool, I'll give it a go. 16:18:27 also, url-encoding and html vocabs are now built in the native image 16:19:01 great! 16:20:55 slava, do I need anything apart from jedit.jar to build the jedit stuff? 16:21:04 [javac] /home/chrdou/src/factor/Factor/Factor/factor/jedit/FactorSideKickParser.java:32: package errorlist does not exist 16:21:04 [javac] import errorlist.*; 16:21:04 [javac] ^ 16:21:12 doublec,did you see my email? 16:21:19 doublec, install the SideKick plugin 16:21:26 doublec, factor's build.xml will know to find it in ~/.jedit/jars/ 16:21:40 ahh, ok. 16:21:52 I read the email but didn't realise I needed it for the build. I'll do it now. 16:25:22 i'm switching from lyx to plain latex 16:25:31 lyx doesn't have a split pane view for one 16:26:46 Lyx is nice for wysiwyg but I do prefer editing things in plain latex personally. 16:28:11 jedit blows the doors off lyx in the editing department. and it even has a sidekick plugin for latex :) 16:29:25 :) 16:30:11 sidekick installed and factor builds fine now. 16:30:19 * kc5tja likes Lyx because I can *never* remember how to do *ANYTHING* in raw LaTeX. 16:30:29 kc5tja, that's why i have a latex book ;) 16:30:45 another problem with lyx is that its latex output is messy and looks poor with latex2html 16:30:58 When I'm writing, I don't have time for reading a tome -- reading while writing is a distraction, and only disrupts my thought processes. 16:32:10 slava, structure browser - nice! 16:32:53 kc5tja, that's why I like plain latex. I just write text then style it later. Seeing the wysiwyg as I go tends to make me want to format things and gets in the way of my flow of thoughts. 16:33:37 doublec, i plan on adding a mode to the java factor's parser where it continues after an error. right now one parse error will stop parsing 16:33:58 ok 16:34:45 alreay its quite useful 16:37:53 --- join: FlamingRain (~Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 16:39:31 doublec: I also just plain-write too. 16:39:33 BUT.... 16:39:46 How do you annotate the text so that you remember how something should look later on? 16:39:55 * slava realizes he rekindled the great WYSIWYG -vs- plain text markup war. 16:40:01 heh 16:40:02 sorry guys :) 16:40:03 If I *know* how it's supposed to look, I prefer to just immediatley inline the commands. 16:40:25 kc5tja, Yeah I do that too. I'm inconsistent in my beliefs vs what I do sometimes :) 16:47:01 slava, the devel guide, under 'parsing words' has the following definition: 16:47:03 : bar foo "2) bar executed." ; 16:47:07 --- join: TheBlueWizard (TheBlueWiz@pc8edn1d.ppp.FCC.NET) joined #forth 16:47:07 --- mode: ChanServ set +o TheBlueWizard 16:47:09 I think it is missing a 'print' at the end. 16:47:24 doublec, ok thanks :) 16:47:41 --- join: crc (crc@0-1pool216-67.nas16.philadelphia1.pa.us.da.qwest.net) joined #forth 16:47:53 hi crc 16:47:59 how's retroforth going? 16:48:08 Not bad 16:48:31 I'm working through the code, doing a line by line cleanup now :-) 16:48:54 i have too many lines to do this :( 16:48:56 And trying to flesh out the 'kernel' for the native version 16:49:22 * crc has <800 lines for each port 16:49:39 And most of that is shared code, so it only has to be worked over once 16:50:21 my C kernel is 4200 lines right now. 1500 of this is the *cough* math library 16:50:28 Ouch 16:50:47 its not that bad. each source file is very short 16:50:58 I keep as much as possible in Forth 16:50:58 ctags/vim!! :) 16:51:06 kc5tja, ctags/jedit! :) 16:51:08 * crc doesn't like vim 16:51:31 crc, there is a lot more verbosity in C due to struct definitions etc 16:51:40 Nothing beats VIM, except theoretically a humane interface. 16:51:43 if i just did peek/poke for everything instead of structs i could save a lot of code and header files :) 16:52:10 --- quit: FlamingRain ("Leaving") 16:52:16 I tend to use Nano and TE for editing text... 16:52:26 what is TE? 16:52:49 What is Nano for that matter? 16:52:56 TE is a simple text editor tcn & I have been writing 16:53:18 Nano is a GPL'd clone of the Pico editor 16:54:34 http://www.nano-editor.org/ 16:54:53 That's your problem. 16:54:59 You're using two editors, when you could just be using one. :) 16:55:36 I'd just use TE, but it still has some major bugs in handling new lines... 16:55:51 i couldn't stand using an editor with bugs ;) 16:57:17 there's nothing quite like writing piles of code and then having the editor crash on you corrupting the saved file. 16:57:18 out of curiosity, how is TE "better" than other text editors? (don't wanna start an editor flamewar ;) 16:57:31 Harlequin dylan's editor in their 1.0 product used to do this occasionally. 16:57:33 * TheBlueWizard knows zilch about TE, of course 16:57:47 doublec, that's not as bad as bugs in the editor's autosave/backups on top of that :) 16:58:01 I don't even want to think about that! 16:58:09 TE is unreleased at this point 16:58:35 TheBlueWizard: it's not "better", except that it's small, fast, and easy to hack :-) 16:58:51 yeah...but I'm curious about why you elect to homebrew an editor 16:58:53 For block editing, I'm going to be improving on VIBE and adding additional VI-like features (like "marks" for example, for rapidly jumping between blocks, and maybe even tags, not sure yet) 16:59:05 slava, is '"line" get' the way to get access to the text in the input stream for a parsing word? 16:59:27 doublec, well you *could* 16:59:31 doublec, but what are you trying to do? 16:59:38 doublec, to read the next word from the input stream, use scan ( -- word ) 16:59:40 slava, nothing really. Just playing with parsing words. 16:59:54 so : FOO: scan parsed ; parsing FOO: hello is equivalent to "hello" 17:00:08 ok. What does 'parsed' do? 17:00:12 Actually, I've been thinking about the Forth for the Kestrel. I wonder if I should just bite the bullet and implement a humane environment right from the get-go. 17:00:25 doublec, parsed ( tree obj -- tree ) 17:00:36 kc5tja, like the canon cat? 17:00:46 doublec, i think the forth equivalent of parsed is , 17:00:47 slava: yeah. 17:00:58 We started TE for our simplified Linux distro (which is also unreleased atm) 17:00:58 ok, thanks. 17:01:05 doublec, or rather, POSTPONE 17:01:10 i'm not sure ;) 17:01:15 doublec, : parsed swons ; 17:01:19 doublec, that's how its defined 17:01:45 slava: Basically, I've been using Squeak of late, and it's a pretty nice (albeit slow) system. 17:01:50 But it's very, very, very hard to grok. 17:01:58 Well, at least, it's hard to learn the guts of. 17:02:02 morphic is a nice technology but the usability sucks. 17:02:06 (despite everything being so simple.) 17:02:16 I prefer MVC over Morphic ANY day. 17:02:52 to be honest i find Swing simpler to understand than Morphic ;) 17:02:57 I don't like Morphic because it's wholesale unfactored. It combines a model, a view, and at least one controller, all into a single object. Not cool. 17:03:02 exactly 17:03:05 Swing is MVC. 17:03:09 yup 17:03:25 JButton, ButtonModel, ButtonUI -- for each control 17:03:32 latter two are abstract classes. 17:04:11 Personally, I find MVC to be too hard to implement a lot of times -- Document/View (as it's called in MSVC++) is almost exactly the same, but the controller behavior is part of the view behavior, and seems much easier to implement. 17:05:33 in practice i find view/controller are the same thing 17:05:41 kc5 are you using any sort of version control on your projects ? 17:05:48 I440r! 17:05:52 I440r: For which projects are you talking about? 17:05:57 I440r, i use CVS, suck on that ! mwahahaha 17:06:27 I use CVS and darcs depending on what I'm doing. 17:06:45 I use darcs for most of my SCM needs. 17:06:49 cvs sucks 17:06:53 people seem to have cvs but apart from moving files i've never had problems with it. 17:06:58 hate* 17:07:11 i dont hate cvs, i just think it sucks so bad 17:07:17 neither have I. it does most of what you want fairly well. 17:07:19 and i cant get it into my head 17:07:26 slava: You've never had to use it in a "commercial" setting. 17:07:34 i couldnt set up a cvs server if bill gates offered me his entire fortune to do so 17:07:40 darcs' focus on patches and passing patches between repositories is nice though and that's what I use it for. 17:07:41 took me 2 hours to set up my svn server tho 17:07:46 kc5tja, actually, i have :) 17:08:23 When you're maintaining 700MB worth of source code, with 5 other team members, CVS breaks down VERY fast. File locks get left behind all over the place, and you can't do a freaking thing about it until you get ahold of the CVS repo administrator, and have him release the fucking locks. >:( 17:08:40 yeah, that's painful. 17:08:43 ah yes locks suck 17:09:09 I won't even begin to get into the issues of renaming files and directories, and moving things around the hierarchy. 17:09:18 or someone commits a file full of windows carriage return line feeds and breaks any ability for someone to merge from another system. 17:09:34 Yep. 17:09:44 Subversion would be my choice for a centralized, commercial-grade SCM system. 17:09:55 I love darcs too. But darcs has performance problems on very large repositories. 17:10:06 It would never handle the 700MB I used to deal with back at Hifn. :) 17:10:21 yes, that's true. But I do like that you can use it without setting up a server for anonymous access to the repository. 17:10:43 Yes. As easy to use as RCS, and as capable as CVS, and then some. 17:10:55 darcs would have been perfect for the work I was doing on Massive which just involved swapping patches back and forth. 17:11:14 whereas cvs required a bit of a learning curve for those who'd never used it before. 17:11:45 kc5 i can add an account here for ya and create reposatories for ya 17:11:50 darcs is also somewhat of a 'work in progress' I feel. 17:12:11 svn is a work in progress but its damned good 17:12:32 I've not used it yet. It's on my todo list to look at tho. 17:12:35 --- join: FlamingRain (~Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 17:12:52 anyone tried arch? 17:13:04 lisp people seem to like it. 17:13:51 yes, it seems fairly complicated to get to grips with though. Maybe that's why they like it ;) 17:17:48 slava, what do you think of Joy's primrec and linrec combinators for recursion? Are they useful or do they make things harder to read? 17:18:10 doublec, they make things harder to read, and the implementation of those combinators is a sea of >r/r> 17:18:26 doublec, i tried it before. joy's combinators are written in C, so they can juggle a lot of stack items 17:18:34 slava, I find them mind bending to read but was curious as to whether it was just me. 17:18:46 5 [1] [*] primrec 17:18:50 (factorial of 5) 17:19:25 : fac ( n -- n! ) 1 swap [ succ * ] times* ; 17:19:51 i don't think that's *much* worse 17:19:54 except for the 'succ' 17:19:59 since our times* numbers from 0 not 1. 17:20:21 in fact primrec is like times* 17:20:26 linrec is the one with the messy implementation. 17:20:31 yes 17:20:38 i can dig it up if you want, in my personal cvs here 17:20:48 that's ok, was just curious. 17:21:11 i found it 17:21:23 cool, I'll have a look if you've got it handy. 17:22:02 http://paste.lisp.org/display/2192 17:22:10 --- quit: FlamingRain ("Leaving") 17:22:13 --- join: FlamingRain (~Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 17:22:31 wow, that would have taken a bit of testing... 17:23:03 yes, i don't like words like that :) 17:28:37 where the fsck is tathi! 17:28:43 --- quit: FlamingRain ("Leaving") 17:30:43 I440r: Sorry, was reading. 17:30:50 (reading other things) 17:30:58 thats ok kc5 :) 17:31:11 i was fixing my firewall :) 17:31:21 if ya need it i got it, if not thats ok :) 17:31:28 doublec: darcs is of course a moving target. It's not even 1.0 yet. 17:31:52 GNU/Arch is a *great* system. I do love it. But it does have a steep learning curve. 17:32:06 I use darcs primarily because it's simple, yet does everything I need it to. 17:32:14 When I outgrow darcs, I'll consider alternatives at that time. 17:32:29 k :) 17:32:30 I440r: I have no intensions of hosting SVN repos at this time. Darcs is plenty good enough for me. 17:34:54 anyone here know tathi's email ? 17:34:58 we considered moving away from cvs 17:35:03 I440r: Not off hand, I don't. 17:35:20 but decided 'better the devil you know' 17:35:32 fridge subversion is very very similar to cvs 17:35:52 yet i can grasp its useage and cvs throws me every time 17:36:01 i cannot get my head arround cvs at all 17:36:10 i fsck up my reposatories every time lol 17:36:17 Me too. 17:36:34 At hifn, we actually had a person who did nothing but CVS administration, full-time. 17:36:39 That just goes to show you... :D 17:37:14 isforth was originally hosted on sourceforge 17:37:21 Hmmm.... You know, looking at http://techrepublic.com.com/5206-6230-0.html?forumID=10&threadID=150172&start=0 , it looks like there is a rather wide market for vastly more reliable home computers. 17:37:24 for about 8 monthis all i did was try get my head arround managing my account there 17:37:37 2 months after deleting said accoung isforth was up and running 17:37:41 This might be a niche that the Kestrel can fill, by providing a fresh start and an eye towards mainframe-like construction. 17:37:41 and I thought being a full-time repository admin is a "commie" concept invented by M$ :) 17:37:52 (and a mainframe-class operating system core to boot) 17:38:19 hehehe lol 17:38:20 tbw!! 17:38:25 re TheBlueWizard 17:38:29 didnt notice ya snukk in there :) 17:38:57 I440r hiya kc5tja hiya 17:39:06 :) 17:39:12 nice seeing ya, I440r 17:39:33 i got my box spring and matress today!!!! no more fscking air matress cam bed bullshit for me :) 17:39:38 yippeee!!!!! 17:40:22 air matress is awful? 17:42:17 it is when you sleep on it for a month 17:42:24 next to the cockroaches 17:42:25 ick 17:43:03 roaches?! ugh! 17:44:54 Do yourself a big favor. Get yourself several ant farms, and let them loose in the house. Let the queen ants run things for a while. Your roach problem will almost certainly disappear in a few months. 17:45:06 replaced with an ant problem 17:45:07 Believe me, ants are FAR preferable and more easily controlled than roaches. :) 17:45:43 slava: Since most ants can't tear flesh off the skin, the odds of disease spread from an ant bite is almost nil. 17:45:53 Indeed, the worker ant can't even eat solid food! 17:46:05 well im off to do laundry 17:46:07 The most they can do is grip (hard), and tug. 17:46:18 if tathi shows up NAIL him to the channel 17:46:23 Why? 17:46:31 so i can talk to him lol 17:46:31 I'm sure he'd like an explanation as to why he's being nailed. 17:46:42 Something beyond that. 17:46:42 lol 17:46:58 i want him to use my svn server to host his ppc version of isforth 17:47:11 which is almost ready to ship i believe 17:47:23 well, gotta go...all bye! 17:48:01 Ahh 17:48:31 --- part: TheBlueWizard left #forth 17:50:29 --- quit: Robert ("I start to climb towards the light.") 17:53:22 --- join: Robert (~snofs@c-bf5a71d5.17-1-64736c10.cust.bredbandsbolaget.se) joined #forth 18:06:39 --- join: FlamingRain (~Ecoder@c-24-129-95-254.se.client2.attbi.com) joined #forth 18:13:56 --- quit: FlamingRain ("Leaving") 18:28:33 kc5tja: HEY!!!! 18:43:09 --- join: kc5tja_ (~kc5tja@66-74-218-202.san.rr.com) joined #forth 18:46:17 hi arke 18:47:17 --- quit: kc5tja (Nick collision from services.) 18:47:24 --- nick: kc5tja_ -> kc5tja 18:47:27 --- mode: ChanServ set +o kc5tja 18:47:35 hi slava 19:27:59 lol everyone except tathi heh 19:28:12 lol 19:34:23 --- quit: crc (Client Quit) 21:07:12 --- join: mur_ (~mur@smtp.uiah.fi) joined #forth 21:08:38 --- quit: mur (Read error: 60 (Operation timed out)) 21:09:56 --- quit: hefner ("I'm the operator with my pocket calculator") 21:37:12 --- quit: Klaw () 22:02:39 --- join: mur (~mur@smtp.uiah.fi) joined #forth 22:04:50 --- quit: mur_ (Read error: 60 (Operation timed out)) 22:07:17 Well, I think I'm going to grab some food. 22:07:26 I'll be right back. 22:07:30 :) 22:08:30 hi guys 22:08:51 i just finished releasing 60 files through sourceforge's file release interface. :-( 22:09:00 i wish they had an xml-rpc interface so I could script this. 22:09:18 :/ 22:14:33 now i have to manually update 15 database entries in a php web app :/ 22:14:48 :/ 22:33:14 argggh 22:36:59 --- join: imaginator (~George@georgeps.dsl.xmission.com) joined #forth 22:37:14 --- quit: doublec ("Leaving") 22:38:01 hi imaginator 22:39:13 Hi 22:50:32 --- join: mur_ (~mur@smtp.uiah.fi) joined #forth 23:01:13 --- quit: mur (Read error: 110 (Connection timed out)) 23:03:37 Back 23:09:06 kc5tja: I just looked at falvotech. It's surprising that your server was hacked. 23:09:31 What webserver/OS were you using? 23:10:51 It's not my server. 23:11:30 The OS is [falvotec@blades falvotec]$ cat /proc/version 23:11:30 Linux version 2.4.27-rc1 (root@r1) (gcc version 3.3.4 (Debian)) #14 SMP Mon Jun 21 12:23:13 PDT 2004 23:12:54 Apache 1.x (presumably 1.3). I can't tell because I can't run the executable myself. But I can see /etc/rc.d/init.d/httpd (which suggests they're also running RedHat or a close relative thereof). 23:14:22 My friend's mod3.net was hacked and the hosting company was using Redhat. 23:15:04 Well, RH sucks ass as far as distros go -- you're far better off with SuSE by a long shot (even though SuSE is even more of a tightwad when ti comes to money) 23:15:20 However, I don't think this hack is distro specific. 23:16:35 onehah 23:16:50 I have some SuSE demo CDs, but I haven't gotten around to trying them yet. 23:17:00 * kc5tja is a Slackware fan, personally. 23:17:08 Though I haven't yet upgraded to 10 yet. 23:17:08 They may be outdated by now. 23:17:11 I'll do that eventually. 23:17:49 I'd like to see a linux distro with the sensibilities and integration of a BSD 23:17:53 SuSE works well usually, but its the kind of system that you dont want to compile anything for 23:18:10 I'm running the NetBSD 2.0 beta. I tried Debian just to see how it worked, and was disappointed. 23:18:24 how's netbsd 2.0? 23:18:30 how is netbsd 2? 23:18:35 arg;ng;ksdj;kj slava :/ 23:18:44 It's pretty good. 23:18:53 i'm running freebsd 4.10. 23:19:20 ok, 10 plugins down, 5 to go 23:19:34 damn 2 hours spend doing this shit 23:19:41 They have a new kernel option named NEW_BUFQ_STRATEGY that has really boosted the performance on my system. 23:19:58 cool 23:20:00 Basically it gives higher precendence to read() requests than writes() (which take longer). 23:20:19 i'd try netbsd if the nvidia drivers were available. 23:20:47 I use it with an nvidia GeForce 2, but I don't have any 3D acceleration. 23:21:07 same video card as me. 23:21:12 but i need the 3d accel 23:22:10 I'd use a BSD if it supported my HW 23:22:12 imaginator: He needs it for his window manager. ;D 23:22:14 * kc5tja runs 23:22:36 I have an nVidia GeForce 4 chipset, and I need to so I can play my NWN game. Oh, and bzflag. Gotta have my bzflag. :D 23:22:48 :D 23:22:48 s/need to/need it to/ 23:22:49 fridge, what hw do you have 23:23:07 3D acceleration would be nice. I like Bzflag and adventure games. 23:23:18 As far as I know, nVidia only releases drivers for Linux. 23:23:26 They have some for FreeBSD. 23:23:27 and freebsd 23:23:31 not as good though 23:23:36 lower framerates. 23:24:19 HAHAH! The uptime on my web service provider's box is 3 days. 23:24:23 My box is now on 102 days. :D 23:24:38 :D 23:24:58 my sparc has 6days. 23:25:56 Wow, I can't believe I've had my box on and running for 102 days. 23:26:03 I know some people have their systems run for years. 23:26:12 TIME FOR A POWER OUTAGE 23:26:17 Dude, *NO*. 23:26:18 :) 23:26:28 I *like* my AMD Athlon, thank you very muhc. 23:26:30 much 23:26:34 heh. 23:26:41 The last thing I need is for it to blow due to a power outage. 23:26:44 we once had a mobo fry because of a power outqage 23:26:57 are there any forths with a stepping debugger and breakpoints etc 23:26:59 damn CA power is very unrliable 23:27:12 slava: F2. But, its mostly vaporware. :) 23:27:21 what is F2? 23:27:22 slava: I don't think so. Such a debugger very often is not required, so not much thought is given to them. 23:27:42 slava: Like he said -- vaporware. :D 23:27:47 ok:) 23:27:48 * kc5tja runs 23:27:57 * arke chases kc5tja 23:27:58 Sorry -- I'm on a food high right now. 23:28:07 I'll hurt you for that on wednesday ^_^ 23:28:11 HAH! 23:28:15 slava: Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02) 23:28:20 I'll show my awesome aikido skills. 23:28:24 when coding java i never feel the need for a debugger but with factor i often wish i could step through a word definition to see what's going on 23:28:27 oh, i forgot about that 23:28:33 i'll bring a baseball bat! :) 23:28:35 and C too, i use gdb from time to time 23:28:48 gdb is kind of lame, maybe i should try one of the front ends 23:28:55 arke: go ahead. I mean, I practice aikido against *swords*, so a baseball bat will be rather easy. :D 23:29:04 ddd dies with any sizeable application 23:29:06 :/ 23:29:17 * arke calls up mexican friend for some ammo... 23:29:29 :P 23:29:31 i avoid writing sezeable applications these days 23:29:37 i've written enough bloat to last a lifetime ;) 23:29:43 teehee 23:29:51 jedit :) 23:30:01 that's the tip of the iceberg 23:30:14 So when are we going to see fedit? :D 23:30:21 :) 23:30:38 i'm never writign another editor again. once was enough :) 23:31:05 :) 23:31:22 if i was to program for a living it would be games, ideally 23:31:45 I don't think that would be very fun 23:31:51 why? 23:31:57 what is more fun to program? 23:32:02 enterprise web services? :) 23:32:05 assembly 23:32:08 brainfuck 23:32:08 :) 23:32:11 nah 23:32:12 elegant solutions 23:32:14 that won't get you paid 23:32:21 the brainfuck, that is 23:32:23 not elegant solutions 23:32:49 ~ 23:33:13 :) 23:33:24 i wouldn't want to code in assembler either, unless its writing a compiler that outputs assembly 23:33:46 not if I write an uber-optimizing compiler for a BF computer that generates code thats faster than the equivalent x86 or PPC code 23:34:08 I don't know what would be more fun to be honest 23:34:21 I know programming in the financial services industry isn't fun 23:34:34 assembly language is the best way to code, man... :) 23:34:53 kc5tja: :) 23:35:04 Games programming is *the* most fun way to program for a living. 23:35:08 For several reasons: 23:35:09 if you have limitless time 23:35:17 1. Games are always pushing the envelop of existing technology. 23:35:27 2. Your paycheck depends on you having fun. 23:35:41 3. A game is composed of an endless stream of elegant solutions. 23:36:03 elegant solutions don't require post-release patches 23:36:03 =P 23:36:10 :P 23:36:22 fridge: Sure they do. 23:36:26 Why wouldn't they? 23:37:24 what are 'elegant solutions'? 23:37:38 slava: That depends on the problem. 23:38:07 kc5tja: quick question - page fault et al while interrupts are disabled cause triplefault reset, right? 23:38:25 slava: Consider the Unix "spell" program back in the days of the PDP-11 -- you had at most 64K words of memory, about half of which was taken by Unix alone. How, then, do you implement a dictionary database that holds some 20,000 or more words? 23:38:38 arke: no. A page fault causes a page fault. 23:38:38 hey on *nix, when you have a segfault, is there any way to see what address the program tried to acess that caused the fault? 23:38:46 kc5tja, a b-tree 23:39:06 slava: Right. A B-tree in 20K words of memory? You're joking, right? 23:39:25 How did they do it? 23:39:34 kc5tja: what about a division by zero error? 23:39:37 imaginator: Let me try and find the URL describing the algorithm... 23:39:41 this doesn't concern me since i code for systems with more than 20kwords of memory. :) 23:39:47 :) 23:39:55 arke: Interrupt enable ONLY affects interrupts. It doesn't affect traps or faults. 23:39:58 heathen, chuck would whip you for saying that 23:40:06 kc5tja: aah ok. 23:40:24 slava: I'm trying to show you or get you to think of a solution to the problem. Because you asked what an "elegant solution" was. This is a fine example. 23:40:43 so 'elegant solution' is just squeezing the code into the smallest space possible? i don't like that 23:40:52 code size is not directly related with readability 23:42:12 Reminds me of the "Real Programmer" 23:42:18 Mel? 23:42:45 http://www.jargon.net/jargonfile/t/TheStoryofMel.html 23:42:47 yep 23:42:48 yup. 23:42:50 hehe 23:42:54 :) 23:46:24 slava: Why won't you see what I'm trying to say?? 23:46:36 Elegant solution is **NOT** about sqeezing the most into a tiny space. 23:46:40 It's about solving a PROBLEM. 23:46:48 kc5tja, yes i understand that 23:47:05 And doing it with constrained resources that otherwise people would think would make the solution impossible. 23:47:21 E.g., thinking outside the box. 23:49:07 :) 23:50:47 Crap. I can't find the URL to that algorithm now. 23:50:48 * kc5tja sighs 23:50:52 :/ 23:53:40 Anyway, the way the algorithm worked was each word that was read from input was put through four different hash functions. 23:53:53 Each hash function would return a bit index into a bit array. 23:54:23 s/four/four or more/ 23:54:25 (sorry) 23:54:55 A word was considered correctly spelt IF AND ONLY IF the bits in the array, indexed by all the hash functions, were set. 23:55:23 Note that different words might have some hash functions which collided, but the odds of having *multiple* hash functions collide with exactly the same set of bits was highly unlikely. 23:55:51 :) 23:56:55 A 20KW (40KB) bit array would store 320,000 bits, which provided enough space for up to around 40,000 words. 23:57:02 Half that came pre-populated. 23:57:39 Note that you could theoretically push it beyond 40,000, but you probably started to get false positives for certain words if you pushed beyond that. 23:59:59 --- log: ended forth/04.08.08