00:00:00 --- log: started forth/06.03.11 01:04:04 --- quit: Quartus (Read error: 104 (Connection reset by peer)) 01:55:16 --- join: ecraven (n=nex@ns.AHL.Uni-Linz.AC.AT) joined #forth 01:55:22 hey all 02:15:27 hi 02:18:53 does anyone here know any literature about stack scheduling algorithms for C, Java, Lisp or any such language? assuming i want to compile them to a stack architecture, how do i optimise stack use? 02:21:45 none that i know of 02:22:10 hm.. would that kind of research be useful? 02:22:13 well, if you dont mind reading up on automata theory (which is boring drivel), you could take a look at socalled "push down automata" 02:22:37 most compilers already compile to a stack-based intermediate form 02:23:03 using the aforementioned push down automata, i would assume 02:29:25 (a pushdown automata is basicaly a state machine, with a finite amount of states, and transitions which can optionally push or pop an item off of some stack) 02:29:50 i was thinking about optimising the order in which parameters are passed etc.. 02:30:54 based on the caller or the callee? 02:32:31 both :) 02:32:53 assuming scheme, i can change the order of parameters of each lambda expression 02:35:46 so you're saying you want to add a compile step which analyzes the ideal argument order of the callee and the call-statements, then figure out which order is best? 02:35:52 (that would be cool :)) 02:36:01 yes :) 02:36:10 hmm that would be coool 02:36:16 i dont think gcc or anybody does that yet 02:36:23 well, i was thinking about doing a phd on that, and i don't find anything about it.. 02:36:25 it would take alot of effort though and add alot of compile time overhead 02:36:33 so i'll talk to my professor 02:36:37 oh fun 02:36:38 well, compile time is cheaper than runtime :) 02:36:40 studying comp sci? 02:36:43 true :) 02:36:55 aye, just finishing my master's.. 02:37:06 heh, you're quite a bit farther than me then 02:37:18 could have saved mself the explanation of a PDA then :P 02:37:36 hehe, well, haven't seen any automata for a few semesters 02:37:56 do you know of any recent studies of stack vs. register architectures? 02:37:56 oh yay 02:38:02 (i hate them ;)) 02:38:17 most people seem to think register architectures are way superior :( 02:38:30 well, i had several bookmarks on the subject but unfortunately my bookmarks file got lost somewhere 02:38:54 register machines are superior when you're looking for high end performance 02:39:12 when you're looking for something like a controller though, a stack machine is better... 02:39:50 then again, you got people that will say a series of small, cheap stack processors will outperform current register machines... 02:40:37 really depends on the situation :D 02:40:51 the thing is, register machines are fast at doing complex mathematical stuff 02:41:08 you just grab the numbers and store them somewhere where you can access them really fast 02:41:28 on a stack machine, you'll have to change the stack order or even place it on another stack, or on a global variable 02:41:47 but you have free function calls, no need to re/store registers etc.. 02:41:56 exactly 02:42:00 :) 02:42:10 if you do anything but tight numeric loops, stack machines should be better.. 02:42:27 that depends as well 02:42:28 also you can scrap all the additional hardware for register shadowing etc. 02:42:48 just put a few hundred k of stack memory on chip.. 02:42:58 right 02:43:06 theres still a problem though 02:43:32 the stack machine is 100% sequential 02:43:42 the stack will always depend on the last operation 02:43:52 with a register machine, it doesnt have to, which allows you to do pipelining 02:44:31 pipelining splits the operations into smaller steps, which can be done faster by the transistors, which allows for higher clockspeeds and also that much higher execution speed if you manage to keep the pipeline filled 02:45:15 but stack machines are much simpler, just put 10 processing units on one chip.. 02:45:22 right 02:45:32 thats exactly the kind of research chuck moore and others are doing right now 02:45:47 just put a bunch of cheap stack chips in one place and coordinate them somehow 02:46:23 maybe like hyperthreading, just have them all work in parallel.. each with its own on-chip stack 02:46:38 exactly 02:46:55 the only problem you'll find is (1) cordinating them (2) delegating the work 02:46:56 well, that's the reason why I planned to use also registers in xell 02:47:29 virl: most stack machines have at least 1 additional register anyway (usually an addressing register) 02:48:19 ah, i hope my prof. likes this ;) 02:48:25 i think it would have to include some paradigm changes with probgramming 02:48:45 defining tasks to be executed, instead of executing the tasks yourself sequentially 02:48:53 ecraven: I'd be glad to proof read :P 02:49:01 hehe, it'll be a few years.. 02:49:01 * arke would be interested in this too 02:49:27 well, i was thinking about some dialect of Scheme.. (i like Scheme :) it should work very well :) 02:49:54 scheme isn't bad :) 02:50:11 but identifiers could be shorter 02:50:12 (although I prefer C where you can pretty much slap a printf("wtf debug value %d", i); anywhere ;) 02:50:51 (or in Forth) 02:50:53 (or...) 02:50:57 virl: you write much less code, so it's not that much of a problem.. and you can always define them shorter :) 02:51:27 (define car c) (define cdr d) (define cons e) 02:51:28 :P 02:51:31 maybe, but I'm in that context very lazy 02:52:59 lol, that's quite unreadable. 02:53:11 ah, thanks for the talking, i'll be back with more questions.. have a nice weekend! 02:53:33 --- quit: ecraven ("bbl") 02:53:37 :) 02:55:04 urgh, scheme loves so long command names. 02:55:42 oh, he's in austria... 02:56:06 eh, what? 02:56:20 n=nex@ns.AHL.Uni-Linz.AC.AT] 02:56:37 ecraven :) 02:56:39 ah... 02:56:59 well, unreachable. 02:57:31 i think it'd be easy to find out his email address ;) 02:58:26 i was gona ask him but he left already 02:58:32 it interests me what he's doing :) 03:01:32 talking to X directly would be THE forth way 03:09:39 --- quit: Infight9 (Remote closed the connection) 03:30:39 but where getting an up to date spec of the x protocol? 03:39:48 x.org? 03:42:35 --- join: Cheery (i=Henri@a81-197-45-47.elisa-laajakaista.fi) joined #forth 03:46:38 well, I don't find it 03:52:00 perhaps the version of 1987 could be the latest one? 03:55:45 well, X isn't really documented in that way I would like it 04:53:50 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 05:01:22 --- quit: tathi ("leaving") 05:53:04 --- join: PoppaVic (n=pete@0-1pool66-131.nas22.chicago4.il.us.da.qwest.net) joined #forth 05:54:56 arke: there are several papers on stack scheduling i think 05:57:32 btw arke, the forthchip does "pipelining" because he fits 5 instructions into one quanta of memory that is fetched by the processor ;P 05:57:51 unit* 05:58:04 which forthchip? 05:58:34 well, it would be cool when today would be a forth chip 05:58:53 --- join: ravenEx (i=ravenEx@VPN-239-84.aichyna.com) joined #forth 06:00:28 virl: well each instruction is 5 bits, and the processor grabs 20 bits 06:00:35 so thats actually 4 instructions 06:00:49 so thats sort of pipelining 06:04:14 thats not pipelining :) 06:04:30 if it was pipelining, they would be executing different stages of each at the same time 06:04:34 :) 06:05:19 pipelining isn't needed when something like that is done anyways 06:07:17 depends 06:07:45 i'd like to see a hybrid machine which allows for stack load and unload from a register set in one instruction each 06:08:27 an addressable stack basically? 06:08:28 gay :P 06:08:30 no 06:08:31 :) 06:08:44 an onchip stack, as well as a few onchip registers 06:08:50 the onchip registers can be loaded in one instruction 06:08:54 from stack contensts 06:08:56 contents* 06:09:15 I keep getting told we "don't need registers". 06:09:29 ..which, I can't quite agree with 06:09:31 arke: whats wrong with the A register 06:09:40 thinfu: nothing at all. :) 06:09:54 if you've done any amount of assembly coding you know you only need 1 register + stack :P 06:10:17 thinfu: theoretically, of course. But its much easier if youve gott a few registers to work with 06:10:31 is it worth the complexity increase though? 06:10:34 thats the question :D 06:10:47 Umm, have.. Did.. Meanwhile, yeah: you either need the ops or the slots. 06:11:51 lemme give oyu an example 06:12:00 The question becomes... Are the gymnastics efficient? 06:12:00 lets say you have a routine that adds two fractions 06:12:15 thers numerator , then denominator, twice, on the stack 06:12:54 PoppaVic: well thats generally a rule of forth coding, to avoid the gymnastics by not dealing with more than 3 items on the stack within one word.. and not passing more than 3 either (preferably 2 or less) 06:13:17 on a stack machine, it would look like a! swap a@ + a! + a@ 06:13:37 thats not pretty, and you cant pipeline if 06:14:31 I presume a* are tos-ops? 06:14:40 arke: there's also >r and r> 06:14:50 so you've sort of got two "registers" 06:15:11 in that code segment i wouldn't have used the first a! 06:15:16 would've used >r 06:15:29 PoppaVic: yup 06:15:38 why? 06:15:45 seems messy to me, arke 06:15:58 the a register will be more efficient than the >r r>, if not the same speed 06:16:02 --- quit: ravenEx (Read error: 131 (Connection reset by peer)) 06:16:10 however... 06:16:14 hm 06:16:17 --- join: ravenEx (i=ravenEx@VPN-239-84.aichyna.com) joined #forth 06:16:21 yeah i'm assuming same speed, but i'm not gonna abuse the A register just cuz its there ;P 06:16:42 or rather, i'm comfortable with >r and r> 06:16:43 Plus, I like to think in terms of "integral types" 06:16:45 well either way, its ugly 06:16:58 how is more registers gonna help that 06:17:03 retroforth will compile it (using >r and r>) to something like 06:18:31 hmm.. 06:18:54 This tends to support my 2nd alternative-idea. *sigh* 06:19:31 ugh 06:20:28 Anyone happen to know (or know where I might find) info on stack-depth/average/args/nesting? I'm curious as to what is considered "typical". 06:21:34 you'd probably have to write your own script to analyze a bunch of forth code to figure that out :P 06:21:37 I'm considering the idea of every "type" having it's own "stack". 06:22:33 I'm guessing it would be easier to engineer than screwing around with type "IDS" paralleling _the_ stack 06:24:49 I've considered making the object itself tell what type it is 06:25:07 Yes, that's one of my plans. 06:25:30 the retro concept of "class" sorta' defends it 06:25:42 true true 06:25:47 i figured going beyond that thouh 06:25:54 right 06:26:18 single inheritance, and interfaces 06:26:24 (like Java or C# do it) 06:26:42 * arke is planning an OOP thing for forth that isnt braindead 06:26:56 However, while vectors and vtables are handy, I'm still considering the dual-stack or multi-stack paradigm. Either way, you'd have the "ID" 06:27:07 true 06:27:29 but the multistack method would pretty much restrict you to using delegation oop 06:27:37 (if you're doing OOP, I dunno) 06:27:52 in C, I can emulate - and I hate C++ and C# 06:27:54 if the type itself directly says what type it is... 06:28:11 you mean the elements-of? 06:29:02 Well, in case #1: THE stack has to track ID's with data; in case #2: Each _stack_ already knows the ID 06:29:42 case #3: THE stack only has references to objects which will tell you what the ID is 06:30:02 if you go with multiple stacks, like one stack for floating point and one regular stack 06:30:07 how do you add the floating point 06:30:09 and no the regular stack 06:30:21 float+? :( 06:30:27 maybe the TOS should be limited to one of the stacks 06:30:34 so you change the TOS to the floating point 06:30:34 arke: well, hmm.. No - either they ALL must, or the stacks WILL 06:30:35 then add 06:30:46 right, thin 06:32:28 arke: so, what you are doing then is - "addressing by context" 06:33:22 so, if the context is "FP" (or REALS), then the FP-stack is likely the place to work-from. 06:33:31 to avoid complexifying the actual words 06:33:36 then you have to complexify the stacks 06:33:40 right 06:33:45 can swing either way 06:33:46 have some sort of wrapper for all the stacks.. 06:33:51 Yeppers 06:33:58 so for the floating point stacks 06:34:15 nm 06:34:44 you might consider... "REAL( + * / swap ! ) 06:34:59 or, some similar fluff 06:35:29 maybe... "WITH( Reals + * / swap ! )" 06:36:05 it'd be interesting to do it without making the + - * / words smart 06:36:13 or without overloading.. 06:36:30 yeah, well... the vtables seem to be the only solution that seems likely. 06:36:57 and, (of course), some level of (omg, I hate it) "inheritance". 06:38:05 Seems likely each "type" needs a minimal set of vectors or.. hmm.... Maybe each has their own wordlist? hmm. 06:38:58 Anyway, it's something I believe I need anyway. Just not sure which way to trend and where to start which. 06:39:49 complexity is a bitch :P 06:40:03 Yeah, "extensibility" is, anyway 06:40:06 is floating point worth the complexity? 06:40:54 I wasn't that worried with just reals. I was thinking the assorted widths and dual-element "doubles", and strings and "structs" and all sorta' shit. 06:41:11 I get really, really tired of the mixed-stack and gymnastics. 06:41:35 yeah actually the simplest way would be to be able to switch between stacks, i.e. make the floating point stack "active" and then the words that operate on it are given on a separate wordlist 06:41:42 ..all it takes is one idiotic mistake - from the user or programmer - and you can *poof* 06:41:59 thinfu: yeah, that's what I was thinking. 06:42:07 ..keeps the words "stupid" 06:42:08 doesn't seem to complicated 06:42:10 yeah 06:42:49 As long as each wl/voc is restricted to it's own space, mistakes seem a WHOLE lot less likely. 06:44:06 but what about addressing? if the floating point stack is addressable that can't be too good ;P 06:44:14 I'm also thinking around (yes, dancing in a circle) the idea of "prefixes" - and manybe even "suffixes". 06:44:18 i mean 06:44:28 addressable? 06:44:32 like taking an item from the floating point stack and trying to fetch something from that number 06:44:51 stuff like @ ! would have to only use the data stack.. 06:45:06 no, what I'm doing is just having the object provide a vtable :D 06:45:08 ahh, the word '@' in that context would need a ptr-id or would use a ptr-stack. 06:46:38 arke: the only issue I see with that would be "extensibility" 06:47:05 ..I absolutely LOATHE "realloc" and I do like nice, neat structs. 06:50:02 thinfu: now, we COULD use the 'mixed-model' stack again.. with a tagged-struct, but (once again) I feel the "extensibility" might suffer. 06:50:42 And, remember.. we have runtime-checks versus compiletime-checks. 06:51:43 It's difficult to explain to folks how forthish tends to provide a supercharged cpp-variant. 06:54:22 I'm also cogitating "state" and "words".. I really, really dislike state-smart words. 06:55:34 thinfu: now, the FUN part is... What about "mixed-type words"? 06:55:54 too smart :P 06:56:11 hmm 06:56:24 how do you get mixed-type words without making them "state"-smart 06:56:26 No.. I meant... I can't see how a vtable would work for that, you'd have to consider the "wordlist" idea. 06:56:39 yeah i'm a fan of the wordlist idea 06:56:50 oh, no - I meant like bytes, words/ints, doubles, reals, strings. 06:57:31 yeah.. I think you are right... We need to wordlist-extensibility instead of a vtable directly. 06:58:33 what would you think of all vocs being twofold? Search the apropos wordlist of order, context, and state? 06:59:40 This means, you'd have 2 defs for " or whatever (like #'s) - one leaves a value on the stack NOW, the other would embed a 'literal'. 07:00:11 well maybe have the floating point wordlist vectored into the dictionary when its active.. 07:00:15 i dunno 07:00:22 think it over ;-) 07:00:32 Lemme' know, sometime. 07:01:05 What I'm doing necessitates a forthish interp/compiler, and a lot of stuff just comes up short. 07:01:05 apparently helforth has contexts which allows for floating point namespace/stack operators to override the original 07:01:41 I think I saw that url at some point, maybe even got a tarball - can't recall (seen too many over the years) 07:02:42 well, arke why would you like to do OOP? 07:02:44 just to change-up, what do you think about gleaning prefixes/suffixes out of the input-stream? 07:03:17 virl: well, OO/OOP are really a mess anymore. Too many variations on the theme. 07:04:03 virl: I THINK he mentioned "like using C#" 07:24:27 hmm 07:26:48 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth 07:26:48 --- mode: ChanServ set +o JasonWoof 07:30:46 hi JasonWoof 07:31:16 --- nick: madgarden_ -> madgarden 07:58:00 --- part: thinfu left #forth 07:58:10 the 1xforth revival is coming! 07:58:29 umm... ok. 07:58:45 --- quit: PoppaVic ("Pulls the pin...") 07:58:50 heh. 08:00:23 --- join: Quartus (n=trailer@CPE0001023f6e4f-CM013349902843.cpe.net.cable.rogers.com) joined #forth 08:00:42 --- join: PoppaVic (n=pete@0-1pool73-212.nas24.chicago4.il.us.da.qwest.net) joined #forth 08:03:05 --- join: oxygene (n=oxygene@khepri.openbios.org) joined #forth 08:03:20 'ello 08:04:06 If you think you quality for 1xforth, lemme know 08:04:10 only the elite will be accepted 08:04:10 ;) 08:04:13 oxygene: hi 08:05:31 I can live w/o "elite" 08:11:10 hmm 08:11:49 WHen is a "word" not a "word"? Wordlists and order are sorta' overkill in some ways. 08:13:02 when is a word not a word? 08:13:11 when a fundamental law of the universe changes. 08:13:16 This, apparently, seems to happen pretty often. 08:14:06 well, I was thinking of triggers/associations 'words' as mere substrings. Seems like the current system sorta' ignores that. 08:15:12 I guess it's the basic assumptions 08:18:59 Seems like even "word" might need new terms, since you can have an array-of, list-of, or wordlist-of - varying mostly in storage/layout. 08:20:50 the hitchikers guide to galaxy says that the universe changes it's rules when someone understands it. 08:23:23 :) 08:23:35 virl: I'd tend to agree 08:26:09 I tend to believe that our basic-issue is the same prob I suffered as a kid in geometry - long,long ago... I think we do the "well, everyone can SEE that - why would I bother?" 08:27:08 words are somehow like psi :-) 08:27:57 or chi 08:28:43 virl: I think it makes "assumptions" - and I have known for years what that spells. 08:29:32 I'm thinking we need better cascade/alternative stuff lower-down, that affects "higher-up" 09:48:20 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 09:50:49 tathi: you need to scroll back a few hours ;-) 09:51:34 looking for what? 09:55:25 tathi: talking over a variety of issues deep-down 09:55:57 didn't look that interesting to me. 09:56:26 ahhh 09:56:31 ok, so be it. 09:57:27 there are a few different ways to do it; they all work; just pick one already. :) 09:57:58 hehe - no joke! But, I was searching for some concepts/consensus. 10:01:12 concepts/consensus on what topic, exactly? 10:02:04 we were discussing everything from stack(s) to types/ids and vtables/wordlists (or whate underlies those) 10:02:25 we never really got to parsing-issues 10:02:26 yes, which is why I asked :) 10:02:55 tathi: well, that's why I tossed it out... Sometimes there is a synergistic-insight. 10:04:12 I think we've got a "lever", but we are applying it improperly. 10:04:48 As a parallel-process.. consider prefix/suffix. 10:05:02 without specific goals/criteria/requirements/whatever, it's basically impossible to say if one method is "better" than another. 10:05:28 well, isolated enough: either would work. Look over the generics 10:06:26 you look over the generics. I'll be interested when you get down to specifics. 10:06:44 ahhhhh 10:06:59 ok, I sorta' expected that 10:07:43 define "good" and "syntax". 10:08:02 wrong channel, sorry 10:08:36 ahhhhhh 10:37:24 --- quit: PoppaVic ("Pulls the pin...") 10:44:25 hehe 10:44:42 there is no general problem 10:44:50 why is that so hard to get through to people 10:45:40 People, or PoppaVic? 10:46:56 heh 10:48:36 PoppaVic certainly seems to be the epitome 10:51:10 epitome of what? 11:46:19 hi 11:46:45 hi 11:50:26 slava, what are you doing here? you aren't coding forth.. 11:50:37 lol 11:50:53 lets be nice, people :) 11:58:30 virl: you aren't coding anything... 11:58:44 you are wrong 12:01:55 lets be nice 12:02:01 lets not explode like i did yesterday 12:02:03 :( 12:02:07 * arke hides 12:23:45 --- join: jungledog (n=jungledo@adsl-64-217-180-178.dsl.lgvwtx.swbell.net) joined #forth 13:13:46 --- join: Cheery_ (i=Henri@a81-197-45-47.elisa-laajakaista.fi) joined #forth 13:15:36 --- quit: Cheery (Read error: 104 (Connection reset by peer)) 13:15:41 --- nick: Cheery_ -> Cheery 13:38:20 --- quit: Cheery (Read error: 104 (Connection reset by peer)) 14:31:21 --- quit: ravenEx (Read error: 131 (Connection reset by peer)) 15:13:22 --- join: snoopy_1711 (i=snoopy_1@dslb-084-058-144-171.pools.arcor-ip.net) joined #forth 15:21:29 --- quit: Snoopy42 (Read error: 145 (Connection timed out)) 15:21:41 --- nick: snoopy_1711 -> Snoopy42 15:24:00 --- quit: uiuiuiu (Remote closed the connection) 15:24:06 --- join: uiuiuiu (i=ian@dslb-084-056-244-009.pools.arcor-ip.net) joined #forth 15:28:26 virl: PoppaVic is the epitome of not getting that there's no general problem. 15:31:06 --- join: Raystm2_ (n=Raystm2@adsl-68-93-121-44.dsl.rcsntx.swbell.net) joined #forth 15:32:10 --- quit: Raystm2 (Read error: 104 (Connection reset by peer)) 16:18:47 the general problem, well perhaps I slept when it was discussed. 16:29:04 --- join: sproingie (n=chuck@64-121-2-59.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 16:51:26 --- join: OrngeTid1 (i=orange@rm-f.net) joined #forth 16:51:47 --- quit: OrngeTid1 (Client Quit) 16:52:04 --- quit: tathi ("leaving") 17:46:16 --- quit: sproingie ("Konversation terminated!") 17:48:33 --- join: sproingie (n=chuck@64-121-2-59.c3-0.sfrn-ubr8.sfrn.ca.cable.rcn.com) joined #forth 17:53:13 --- quit: sproingie ("Konversation terminated!") 18:15:45 --- quit: scope (Connection timed out) 18:35:22 --- join: I440r (n=foo@cpe-67-11-173-9.satx.res.rr.com) joined #forth 18:50:18 jungledog lol 18:50:26 :) 18:50:28 i cant fucking message you becauyse lilo is a fucking asshole 18:50:32 let me log in 18:50:36 i messaged you ages ago 18:50:42 lilo has his head up his ass 18:50:45 I was gone 18:50:47 and you can quote me on that 18:50:52 just got back 18:51:10 i almost have a working forth in my DS :) 18:51:16 not quite working yet 18:51:38 number output is broken somewhere and th ecompiler THINKS its compiling but you cant see what it compiled afterwards :) 18:52:04 im seriously thinking of abandoning freenode 18:52:17 the place is going downhill with its anally retentive bullshit 18:54:01 --- join: Amanita_Virosa (n=jenni@ppp-70-248-225-168.dsl.hstntx.swbell.net) joined #forth 18:54:13 i might be about to earn a gline :) 18:54:23 every time i have to log into /msg someone im going to message a complaint to lilo 18:54:45 why? how? 18:54:49 about what? 18:54:51 oh 18:54:53 heh 18:54:57 you cant /msg someone unless you log in 18:55:05 every time im forced to log in im going to complain to lilo 18:55:28 ahhh 18:55:29 hehe 19:03:38 --- part: jungledog left #forth 19:04:50 hands up anyone who would leave this channel and go to a network thats not so damned anally retentive ? 19:05:23 hehehe 19:12:39 --- join: kitsune (n=fox@adsl-71-146-162-62.dsl.pltn13.sbcglobal.net) joined #forth 19:17:55 kitsune u there ? 19:18:51 yes 19:19:04 i was wondering where "jeff fox" went :) 19:19:11 didnt realise you had changed your nick 19:20:45 kitsune was always number one, foxchip is the alternate so I guess kitsune was often taken 19:22:18 :) 19:27:17 --- quit: Amanita_Virosa ("Wewps.") 19:37:28 okad, does anybody know if it's sold or something like that? or can it be get for free? 19:43:35 --- quit: kitsune (Read error: 110 (Connection timed out)) 19:44:17 god lilo is sooooooooo fucking nannoying 19:45:25 --- quit: I440r () 20:57:16 He did seem nannoyed. 21:28:18 hehe 21:29:08 haven't seen him more than femptoyed in a while ;) 21:30:30 --- join: kitsune (n=fox@adsl-71-146-162-62.dsl.pltn13.sbcglobal.net) joined #forth 21:33:29 --- join: Cheery (i=Henri@a81-197-45-47.elisa-laajakaista.fi) joined #forth 21:38:23 kitsune: welcome back :) 21:38:28 hi Cheery 21:38:44 Hi JasonWoof 21:40:40 doing anything interesting? 21:41:07 well, I found an intresting paper: http://www.ai.mit.edu/docs/articles/good-news/section3.2.html 21:46:30 interesting 21:46:44 I think I could learn a lot from lisp 21:47:25 the same way that programming in forth is a learning experience 21:47:42 but I haven't been able to get myself to take the time to learn it 21:47:56 That doesn't tell the reason for behavior of lisp, where you can make worse program from scratch. 21:48:11 It's because of ways you can take. 21:48:19 goes also the other way around. 21:49:30 huh? 21:49:41 I didn't read much of that paper btw 21:52:52 I referred the part: Lisp Programs Are Hard To Write. 21:54:22 I imagine forth and lisp are similar in that regard 21:54:58 I feel that forth supports a very productive coding style which I love and continue to learn from 21:55:09 but I also see people writing absolute crap code in forth 21:55:19 including myself 22:07:05 oh, I really like programming for fovium 22:07:45 it's so fun to have the simplicity of a terminal emulator-like interface and be free of the restrictions of a linux terminal emulator like xterm 22:08:18 most notably that I have a decent interface to the keyboard 22:08:27 (I can find out when all keys are pressed and released) 22:09:26 as apposed to the linux terminal emulator where you can found out when most are pressed (except that it's indistinguishable from them being held down) and can't find out when any are released 22:09:53 and I know I can easily add a graphics API when I want one 22:20:37 wow, cut and paste doesn't work nearly as well if you forget to paste 22:36:59 ok, my command quasi-mode is just about done 22:41:56 man, I'm tired 23:59:59 --- log: ended forth/06.03.11