00:00:00 --- log: started forth/06.04.13 01:57:13 --- join: Cheery (i=Henri@a81-197-60-217.elisa-laajakaista.fi) joined #forth 03:49:45 --- join: Alterego (n=Alterego@88.202.136.178) joined #forth 04:28:54 --- join: PoppaVic (n=pete@0-1pool47-27.nas30.chicago4.il.us.da.qwest.net) joined #forth 04:58:46 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 05:09:20 --- quit: tathi ("leaving") 06:31:18 --- join: Al2O3 (n=Al2O3@pool-68-238-155-35.dllstx.fios.verizon.net) joined #forth 06:32:57 --- join: timlarson_ (n=timlarso@65.116.199.19) joined #forth 06:39:58 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth 06:39:58 --- mode: ChanServ set +o JasonWoof 06:44:53 I was reading a paper by Les Hatton, "Why is the defect density curve U-shaped with component size?" at http://www.leshatton.org/Documents/Ubend_IS697.pdf and came across something interesting... 06:46:40 He came to the conclusion from reading several studies that the best component size is around 200-400 lines for having the fewest bugs per line of code, and that having smaller or larger components increased the bugs/line ratio despite what programming language was used... 06:47:13 ancient history - I bet he got paid to do this study 06:47:56 FIG-forth docs mentioned - 20 years ago - a rational for "block files" 06:47:57 The interesting part was that he left an exception for very short (1-2 line) components, saying iiuc, that the studies that he had left open the possibility that these might have a lower bug count, but that he did not have enough data to say one way or the other. 06:48:25 I bet he got a degree based on the noise - er, document. 06:49:07 Are you aware of any studies or papers that look more specifically at bug density for these very short, 1-2 line, components/functions/words/etc.? 06:49:20 I don't waste my time looking 06:49:42 I've been coding for two decades plus 06:49:46 I am asking here, since those are a commonly recommended size for forth word definitions. 06:50:14 actually, the old std size was "no more than a block, preferably a few lines" 06:50:59 I can already tell you that most everything benefits from decompositions. 06:51:16 right, which gives a size distribution with spikes at 1-2 lines and at (roughly) 200-400 lines...just like he was recommending. 06:51:42 The only "negative" would come into play with call-frames and nesting/unnesting. 06:52:03 Anything with 200+ lines of code is getting stupid. 06:52:47 I tend to think so also for most cases, which is why seeing measurements saying differently caught my eye. 06:52:51 I use a 30..40 line termwin, and I can generally get 2-3 funcs (vertically aligned) in view. 06:53:26 Mind you, due to libs and namespace-issues, this can vary in C or forths 06:54:07 forth was not in the list of languages studied...he covered C, ADA, C++, and I think a few others. 06:54:40 oh, shit: if it was an OOP thing like C++/ADA - no WONDER the linecount is high 06:55:14 Forth has some serious differences from all of these regarding the overhead for decomposition/factoring...i.e. much lower overhead, so this might be expected to lower the bug density penalty for small functions. 06:55:29 same with C 06:55:45 ..problem is with using/deploying the libs they all suggest 06:56:10 you are familiar with the blocking/chunking theory of memory? 06:56:13 ...and, in C, yer setting up a "stackframe" - in forth, it's currently moot 06:56:28 I know the terms, but not what you suggest 06:56:45 where it is not size that counts for what fits in memory, but the number of logical chunks that your brain splits it up into? 06:57:08 that's simply untrue. I dunno wtf they want to imply 06:57:12 (human memory, not computer memory) 06:57:17 OHHHH 06:57:29 Yes, I'm well aware of human-limits. 06:58:08 Humans tend to think of about 3 things at once. This is why I talk so much about "contexts" 06:58:38 ...and the studies that say the programmers write lines of code at roughly the same rate regardless of language...leading to the conclusion that we should use the most powerful language available to increase our rate of making useful programs. 06:59:00 False conclusion from a false premise 06:59:12 please explain? 07:00:13 A "program" is a task. A "program" is almost universally serial. HOWEVER, you can break up the guts into data and code, and create contexts and operations/functions/order 07:00:43 interesting 07:00:53 I haven't heard the bit about this leading to the same speed of writing 07:01:09 I will look for the reference, moment... 07:01:13 Humans don't "think" of data vs code; I've worked with too many.. We think of projects and then try to break out tasks/people/machines, etc 07:01:41 ..and they STILL have to serialize "machine-access" 07:02:13 I think that forth can fairly easily be made to have few bugs because you can test each line individually 07:02:21 Right 07:02:33 the simpler and lower you can test/run, the better 07:02:51 I've read about chunking 07:03:01 I like forth, and intuitively I agree with that logic, but... 07:03:15 there is value to having real measurements to back it up. 07:03:30 I think that short forth definitions work very well with chucking and with language skills 07:03:32 I've tried to manage boardshops and kitchens, and - well, you have to allow time, task, machine, people and then all the imponderables. 07:03:42 JasonWoof: I'd agree 07:03:57 measurements are cool when you have something consistant to measure 07:03:58 it is like trying to optimize a program without using profiling...if we do not make measurements to test our theories. 07:04:21 The idea of dynamic-extension itself is worth it's weight in gold-pressed latinum 07:04:30 if you want to know how forth compares to other languages generally, for most people, then sure 07:04:42 It's easy to guesstimate 07:04:56 however I feel like coding style and experience and farmilliarity with the forth system changes the numbers dramatically 07:05:07 well, yes. 07:05:17 so I don't feel that too many statistics would apply to me too much 07:05:26 experience with any (decent) system changes the dynamics. 07:05:28 machine-code==1; C==2-10x; Forth=C x 3 07:05:41 and having writen the system myself changes them even more :) 07:06:00 Folks tend to mistake "speed" or "size" for "maintainable" - or mix them all 07:06:27 that paper treated maintainability separate from bug density. 07:07:05 I think maintainability is important 07:07:20 and I wish my predecesor at my new job thought so too 07:07:30 it said that maintainability may even be at odds with initially low bug density, due to different mental demands at different times in a programs life. 07:07:57 :) 07:07:59 I could see that 07:08:23 people are probably more likely to test something tricky 07:08:32 (i.e. it takes different skills with different inherent mental limitations to create code than to maintain code, so different coding styles may favor one over the other task.) 07:08:35 wasn't that paper which says that languages with OO are good for maintability? 07:08:37 There is also interactive, interpretive, and compiled. 07:09:15 this paper proposed that there is not much research to support OO's claims. 07:09:16 "interactive" is why folks like shells; 07:09:20 virl: that would be weird. in my limited experience, OO code is much harder to read 07:09:29 "interpretive" is why folks rave about Perl and such 07:09:45 OO can be done readably. 07:09:50 of course I mostly look at OO code to try to fix a bug... 07:09:51 OOP is another issue 07:09:57 "can be", famous last words. 07:10:00 ;) 07:10:01 JasonWoof, I'm only asking myself where this myth comes from. 07:10:21 C can handle OO; C cannot handle the insanity of C++ OOP 07:10:50 virl: academics and proponents of OO(P) 07:11:07 I think there is a great hope that for very large systems OO will be better 07:11:18 because of the way it facilitates modularization 07:11:25 I'd also wager hard on a "closed shop" of N programmers forced to play-well-together. 07:11:49 modules are lovely, OO can help there. 07:12:16 in practice, it seems to facitate the creations of great hulking slugs 07:12:26 slow as all hell and impossible to debug 07:12:28 have you read this guy's site: http://www.geocities.com/tablizer/top.htm 07:12:42 JasonWoof: maybe... THey don't seem to want to consider contexts. 07:12:59 Black-boxing is handy, but you then end up with worse than the forth-stacks 07:14:45 I've all the basic 'guts' - structures and whatnot done, (I think), for Metabuilder... But I deliberately designed it for C on one hand and FFI on the other.. Now I need to start adding code to my data (structures) 07:15:50 I still can't "see" bytecodes, simply because I can't envision an add/delete environment for them. 07:16:06 reading 07:16:12 hmm? 07:16:18 my ride is coming soon, so I'll see you in 30-40 minutes 07:16:25 OK, stay well 07:16:28 have fun 07:17:51 well, I need more breakout and blackboxing, but: here's the header I'm glaring at... 07:18:09 http://rafb.net/paste/results/QyoyOP25.html 07:23:53 I think I found the paper about lines-of-code per hour being constant across languages: it is linked from this page (search for the word "lines"): http://soy.dyndns.org/papers 07:24:18 I'm not sweating it - as I said: I've been at it all for over 20 years 07:25:31 I'm not trying to make you sweat, I am just looking for some research results :) 07:25:53 You do NOT need it - it was a waste of time to bother. 07:27:12 As a basic rule, clear is best; sub-structs and routines are golden: Small is better, in every case except a few clockcycles. 07:28:58 Everyone on the planet will agree that a massive, self-adapting goto-filled shitpile can be FASTER - and that faster is not ideal. You need to realize that maintainable is Job-One. Folks would rather use 6 translators with optimizations than code for everything possible. 07:29:41 This is why idiots in acadamia that get paid or earn a degree on their tripe bug me. 07:30:23 I am not looking at the runtime speed, I am looking at the human factors, how long it takes to code, what the bugs/features ratio is, how much time it takes to maintain and how maintenance affects the long-term bug/feature ratio. 07:31:11 scripts are fast to code/develop. Forth is faster than most. The code is not going to be optimal by a long shot. 07:31:41 and how to help alleviate the the periodic rewrites that are triggered by the mounting complexity caused by long-term maintenance. 07:32:27 there are none.. Makefiles. Source. Targets. Platforms. 07:34:01 Shit, you can't rely on Platforms, file-trees; PROGRAMS, their args/output, LIBS, and paths/formats.. Welcome to the "World.. Of the Real" 07:36:27 I get this strange feeling that you think I am a student just starting out...I have been programming also for around 20 years...I just pause periodically to survey the landscape and adjust my techniques. 07:37:12 timlarson_: that's nice, (depending on the adjustments and why). Personally, I stick to C and forth. 07:37:18 asm, basic, c, c++, java, ruby, forth, etc. 07:37:20 well, a little bit ignorant. 07:38:27 I don't script, if I can help it; And, as I said: C or forth. I gave up on the others a long, long time ago. 07:40:12 well, I have a split between the languages that I use for personal project coding versus paid work...they don't use forth here. 07:41:16 yeah, I understand that... I never expected (20 years ago), that Forth would remain so fucked up. Let alone that the C-commies would MANDATE stupidity. 07:41:59 I guess a subconcious reason for #Metabuilder is my generic irritation. 07:43:09 what are the key ideas/drives of metabuilder? 07:44:18 timlarson_: well, I decided that sh blew, and make was predicated on sh, and that forth & whatnot acted similarly - but ignored C. And, (to me), C is the closest to "portable assembler" you'll ever get. 07:45:34 ok, and how does metabuilder address this? 07:46:50 hmm 07:48:37 Instead of make, sh, m4/perl: I want a C program that combines the best of Forths & Make - into an extensible whole, and recognizes there IS a system outside of forth. I think I'll end up with a shell, like it or not: I liked FICL - but it was broken in a few places and the code makes me ill. 07:52:21 soy :) 07:52:29 ui, a metabuilder commercial(tm) 07:52:29 timlarson_: basically, I want a C-based alternative to autoshit, that adds all the benefits of forthishness. 07:52:46 virl: well, It ain't XML, anyway 07:53:40 I have wondered about taking some ideas from table-oriented-programming (think of decomposing graphs into collections of items and relations and then storing this in tables with indexes) into a language like forth. 07:53:42 why should it be xml? 07:53:55 table-oriented... Vtables? 07:54:13 virl: I was shortstopping another commercial ;-> 07:54:18 no, the link he put it here 07:54:38 hmm, I missed a link 07:54:51 PoppaVic, think improved sql. 07:54:58 blech 07:55:11 you forgot to improve it before thinking it. 07:55:15 ;) 07:55:24 of course that would taste bad. 07:55:40 oh, that reminds me on java. 07:57:42 blurb 07:58:59 java or sql: same stupidity, different reasons. 07:59:17 sql is just plain a mess. 07:59:41 I was indicating the type of table, not the syntax for manipulating the data. 07:59:52 life is key/value versus ref-lookup/values - and interps over all 08:01:07 life is one big flat fuzzy table...we break it up into separate hashes, tables, etc. for mental and cpu performance reasons. 08:02:05 fuzzy because objects do not exist in the real world, they are an abstraction we use to deal with reality. 08:02:11 and god defined life as a table 08:02:30 virl, you do standup too? 08:02:49 * PoppaVic sighs 08:02:58 do standup too? 08:02:59 Life is a stage - programs are more restricted 08:07:07 in which context are they restricted? 08:07:43 * PoppaVic sighs 08:08:16 interesting to figure out how to apply the metric from http://www.paulgraham.com/power.html to colorforth. 08:08:48 PoppaVic, need a klenex? 08:09:10 No.. I've projects, a reloader, and a bench. 08:10:43 plus, I have to trim a ton of meat today and begin marinading for jerky. 08:12:44 why does PoppaVic need a klenex? 08:13:16 virl: prolly due to his topics? 08:13:18 timlarson_: I don't think you're a newbie. I'm just spouting a few of my theories 08:13:55 I to am very interested in human factors 08:14:16 and how to program effeciently, effectively and create stable, useful, productive software 08:14:27 Folks need to recall UI, and they also need to remember time. 08:14:41 and I think to acchieve this effectively we must pay a great deal of attention to human factors 08:14:55 how people's brains work, and what people waste time on 08:15:07 yes, and there are a variety of GUI stds 08:15:22 there are far fewer under the GUI level 08:15:47 I think it's useful to look at little things, like how much time I spend going back into my sources for php/c to add semicolons at the end of statements 08:15:49 like matter=energy (you can convert between them) data=code (any given problem can be represented with a varying ratio of quantity of data versus code) 08:16:15 you need some code 08:16:33 yes, hence "ratio" 08:16:56 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 08:17:10 the top thing sounds interesting 08:17:21 I hope I actually read it 08:17:32 lisp treats code as data, forth can also to an extent... 08:17:35 tathi: have you heard of table-oriented-programming? 08:18:03 JasonWoof: hmm, prolly overkill - it's a language/culture thing as well. 08:18:13 t-o-p tries to convert more of the code into data 08:18:23 timlarson_ posted this link: http://www.geocities.com/tablizer/top.htm 08:18:41 loading 08:19:08 my most recent stab at making it easy to make html forms that are properly validated and saved to database (and sometimes e-mailed to people) 08:19:14 topmind (his nick) does go into overkill in his arguments...but I think we have good enough filters to extract the good pars. 08:19:20 s/pars/parts/ 08:19:30 involves getting most of the meta-data into the database 08:19:33 added a link to Safari... I need to read it later 08:19:44 Yes, yer talking about vtables 08:19:46 :) 08:19:55 ..and wordlists as well 08:20:06 JasonWoof: vaguely. 08:21:03 So far, the only comparison I've ever seen to "wordlists" is something like named-arrays like foo[bar] 08:21:23 I see the conversion of code into data as a compression technique, like a small amount of matter is equivalent to a large amount of energy. 08:21:34 yer nuts 08:22:03 code is code, code WANTS a context. Data can be context, code or literals 08:22:11 yeah, turning code into data can be a nice technique 08:22:39 tathi: yer thinking bytecode, I presume? 08:22:54 I found it useful because it enabled me to make the meta-data editable with forms and such 08:22:56 when you convert code to data the sum of code + data shrinks. 08:22:59 so bytecode, I would say that bytecode is also data 08:23:06 so that it did not require an understanding of programming syntax 08:23:09 or access to the files 08:23:14 this is the definition of a macro (hygenic or not) 08:23:16 right, virl - it needs an interpretation 08:23:19 thus our designer could make forms without doing php 08:23:36 and when something custom was needed the programmer(s) could hack the php without touching the designer's work 08:23:41 JasonWoof: very, very unlikely. 08:23:43 PoppaVic: no, I'm not thinking bytecode. I was agreeing with timlarson_ 08:24:04 s/hygenic/hygienic/ 08:24:10 tathi: can you xlate? I've been on the cusp of not following him. 08:24:43 I doubt it 08:24:48 ok 08:25:17 I still don't understand how your brain works :) 08:25:22 hehe 08:25:38 It thinks in C, with forthish overtones ;-) 08:25:57 yeah, but not the way most other people seem to think of C and Forth 08:26:06 JasonWoof, reminds me on xell 08:26:11 I know - it's depressing to see 08:27:10 code requires a sequence of steps every time you attempt to express something...in effect you have to type part of your context each time... 08:27:52 JasonWoof, or not, well, a brainfart sorry. 08:27:58 data can be interpreted, in effect the interpreter supplies part of the context (in one copy of code in the interpreter) instead of you typing it again (multiple copies in the data). 08:28:30 virl: everything reminds you of xell ;) 08:29:44 so by shifting some expression from "code" to "data + interpreter" you can reduce the amount of _explicit_ context that has to be present, as more of the context becomes implicit. 08:30:12 hence coverting code to data is a form of compression. 08:30:22 PoppaVic, does that make more sense to you? 08:30:57 (notice that there is always still some code present in the system, whether direct code or code that is part of an interpreter) 08:31:11 what is code and what is data? generally it depends on the view. 08:32:25 true, but as described above there is more to it than just that...that expression by itself is like saying all programming languages are equal since they are turing equivalent -> it is true, but not a useful measure. 08:33:47 --- quit: PoppaVic (Nick collision from services.) 08:34:03 --- join: PoppaVic (n=pete@0-1pool46-173.nas30.chicago4.il.us.da.qwest.net) joined #forth 08:34:14 data can be interpreted, in effect the interpreter supplies part 08:34:15 of the context (in one copy of code in the interpreter) instead of you typing 08:34:15 it again (multiple copies in the data). 08:34:15 A lot of folks can't see "interpret" versus "compiled". 08:34:18 interpret-what and compile-what seems to be the issue, and then the 08:34:20 latter requires ANOTHER "interpreter" or at least a "stepper" 08:34:22 tathi: I spent yesterday sorta' experimenting with the name-flags 08:34:24 and such as immediate, compile-only, etc.. 08:34:26 sorry, I got waxed 08:35:39 generally data is code which shouldn't be executed and to say that it can be executed again it makes it to code. 08:35:56 like in lisp the case 08:36:03 sure, it means someone INTERPRETED the payload 08:36:03 the good old 'eval' thingy. 08:37:09 yep 08:37:39 think of the difference of having a user edit a config file (data) versus having them drop the corresponding values all through the code to configure it. 08:38:03 I tend to believe that each struct/type needs a ->interp 08:38:41 timlarson_: a config FILE is a file, not a config: you interpret it 08:38:53 the idea of t-o-p (filtered through my brain) is that each struct/type needs the ability to have multiple ->interp. 08:39:08 not actually. 08:39:22 PoppaVic, read what you just wrote, and maybe you will get it. 08:40:03 there are cases where the struct needs interp into "real world", and there are cases where a struct is acting on a struct - and you need to consider whom does what to whom. 08:40:04 config + interp code is shorter than just config code. 08:40:15 * PoppaVic sighs 08:40:22 retyping... 08:40:25 interp the text 08:40:40 the interp can do whatever it needs, internally 08:40:42 "config code" + "interp code" is shorter than just "config code". 08:41:02 yep 08:41:04 the "interp code" is an abstraction. 08:41:13 it sure is 08:41:26 the config is a structure and vars 08:41:29 that is what reduces the data + code sum 08:41:32 or constants 08:41:49 sorry, yer still looking for ultimate. 08:41:56 hu? 08:42:22 don't project so much 08:42:50 heh. he's terrible about that 08:42:53 if you want ultimates, you need to talk with the #asm folks - and then realize they are STILL talking convertors and binary-datum and an OS they'd love to ignore (until it was convenient) 08:43:24 and, datum still need translators/interpreters 08:43:40 tathi: yes, I'm well aware I bug folks. 08:44:00 PoppaVic: I mean that you always seem to think you know what other people want. 08:44:10 which OS do they ignore until it was convenient? 08:44:11 which is just stupid 08:44:35 tathi: lord, NO - I never am sure wtf they WANT, I just guess at wtf they MIGHT "mean" 08:44:49 virl: pick one.. 08:44:59 "PoppaVic> sorry, yer still looking for ultimate." 08:45:05 yep 08:45:18 that's a statement about what he wants 08:45:23 you have NO WAY of knowing that 08:45:28 so don't phrase it as a statement 08:45:40 my bad, I understand - I based it on his arguments/posts 08:46:35 Frankly, even the idea of an OS over a CPU is scarey - adding in *nixish "virtual" concepts makes it worse. 08:47:28 So, I would prefer they would at least speak of programs and baselines - posix, posix2, dos, doze, whatever. 08:47:29 why is it scary? 08:48:01 virl: it adds even arguments that are not fully portable. 08:48:35 CONCEPTS are sorta' portable, implementations get worse and worse 08:49:03 we can add here "but, I have several processors running!" 08:49:38 Or, "I don't use a filesystem" 08:49:51 or, "this is all in ROM" 08:50:06 or, "I have a flubber-device.." 08:50:20 a flubber-device? 08:50:33

08:51:37 * timlarson_ cringes as he mentions that a lot of assembly is done on embedded devices where an OS is not applicable. 08:51:39 So, the question seems to become (as usual): A) What platform; B) what OS; C) what's your target? 08:52:17 it sure is, so what? I know a guy writes JUST for embedded-processors. Is that your desire? 08:52:53 If you are writing JUST for a device, you code - just for that device. 08:53:19 hell, even yer tools are limited in that case 08:54:28 Russ *thinks* that way - I can't, so I respect him and expect he listens to others - maybe not me - in OTHER cases. 08:55:09 He thinks of "special language" and "special compiler" and then testing. 08:55:52 wow, I did not know emacs has a PoppaVic mode, I thought it had only gotten as far as the doctor mode. 08:55:59 * PoppaVic sighs 08:56:20 OK, I give, 08:56:35 still fairly predictable output based on what you type, but definitely an improvement in the AI. 08:56:50 Die well 08:58:01 we are all sort of like that, just to varying degrees ;) 09:01:34 * JasonWoof is now known as elisa 09:02:10 you mean Elsi-the-cow ;-) 09:02:30 well, then I'd like to call myself 'skynet' the only real ai who wishes that ugly thing called humans from planet. 09:03:11 virl: I'm guessing you want to be a Terminator - and can't phrase it well. 09:04:04 OK, I need to go slice some beef. Laters. 09:04:08 --- quit: PoppaVic ("Pulls the pin...") 09:04:17 no, I'm skynet the boss of all terminators. 09:08:59 well, boring. 09:10:54 "terminator" would be a great name for a terminal emulator 09:19:03 especially if it were full of bugs that terminated your applications. 09:21:36 --- quit: Alterego (Remote closed the connection) 09:21:55 heh 09:22:35 maybe it could have a feature where on a certain keystroke it would kill the child process no matter what 09:22:58 first send an int or whatever 09:23:02 then -1 then -9 09:26:04 from a practical standpoint, I find the program "screen" offers such functionality in a nice way. 09:32:36 screen is cool 09:32:43 except it kills your terminal scroll 09:33:06 I'm not sure how or why, but it's annoying 09:42:17 screen makes there be several terminal scroll buffers, one for each virtual terminal run in it...I do not think the actual terminal has a way for screen to load these virtual scroll buffers into the actual terminal's scroll buffer, so you have to use screen's scrolling keys instead to access them. 09:42:45 a pain, but at least you still have the buffers. 09:42:54 and there is a way to get at them. 09:48:51 is there some quicker way to scroll than the silly copy/paste mode? 09:49:11 I don't expect to be able to scroll with my terminal after switching windows within screen 09:49:33 I just want to be able to scroll up quickly with my terminal after doing cat or ls -l or something 09:50:05 ps axf 09:53:05 I dont know of any other way than the copy/paste mode, sorry. 09:56:49 dtach is pretty cool too btw 09:56:49 --- join: neceve (n=Clau@unaffiliated/neceve) joined #forth 09:57:07 it doesn't cache the screen contents or kill the scroll buffer 09:58:26 I tend to pipe to less or more instead of using the scroll buffer, with the side effect of my "scrolling" not being limited to the buffer size. 09:58:36 e.g. ps axf | less 09:59:21 and of course you could also shrink the number of lines you have to stare at like this: 09:59:32 ps axf | grep vi | less 09:59:52 if for example you only want to see the lines containing the string "vi". 10:00:04 and this leads to even less scrolling :) 10:00:58 and then if you happen to be a vim user you can set marks to jump back and forth to in your code instead of scrolling back and forth. 10:02:47 in command mode type the letter "m" followed by any other letter to set a mark, and type an apostrophe followed by that same letter to jump to the mark. 10:02:58 hope that was not too much info ;) 10:03:54 vim has no trouble scrolling within screen 10:04:01 and yes, marks are cool :) 10:04:13 sometimes I forget to use them... 10:04:21 me too 10:04:30 I wish marks worked accross all programs that I use 10:05:00 they might have to be two letters or something 10:05:22 run all the programs from inside vim...oops golden hammer, and it probably would not work. 10:06:05 wrong editor -- emacs is the one you run everything inside :) 10:06:50 you can run shell commands from inside vim too. 10:07:00 but other than that, yup 10:07:17 yeah, I have xxd set up to run automatically on 'vim -b' 10:12:35 dtach looks pretty neat, could perhaps use it to more easily share screen sessions :) 10:19:32 --- join: Alterego (n=Alterego@88.202.136.178) joined #forth 10:22:24 dtach is really nice for programs like irssi that keep track of the screen, and which you want to run one session continuously 10:22:41 I have f3 setup to connect to the dtach session with irssi 10:24:25 I couldn't figure out how to do that with screen 10:24:44 I didn't see a way to have a scipt connect to the correct screen session 10:34:26 i run my http server in a screen session so i can attach to it and reload files 11:21:52 --- join: andyd_ (n=andyd@82-41-128-63.cable.ubr02.glen.blueyonder.co.uk) joined #forth 11:24:12 hello all 11:25:10 hi 11:29:42 --- part: andyd_ left #forth 11:33:22 There was a young man who said "damn. 11:33:22 For it certainly seems that I am, 11:33:22 a creature that moves 11:33:22 in determinate grooves. 11:33:22 I'm not even a bus I'm a tram." 11:48:37 hell, why are there a lot of problems. 11:55:24 xell on earth 11:58:23 you don't even know what it is exactly and you talk about it. 12:14:34 --- join: snoopy_1711 (i=snoopy_1@84.58.112.11) joined #forth 12:22:35 --- quit: Snoopy42 (Read error: 145 (Connection timed out)) 12:22:45 --- nick: snoopy_1711 -> Snoopy42 12:23:31 --- quit: timlarson_ ("Leaving") 12:28:31 --- nick: Raystm2 -> nanstm 12:47:52 --- join: Ray-work (n=Raystm2@adsl-68-90-192-85.dsl.rcsntx.swbell.net) joined #forth 12:47:52 --- quit: Ray_work (Read error: 104 (Connection reset by peer)) 13:12:31 --- quit: JasonWoof (Remote closed the connection) 13:13:49 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth 13:13:49 --- mode: ChanServ set +o JasonWoof 13:50:18 --- quit: Cheery ("Leaving") 13:59:00 --- join: domino-24 (n=domino@host86-132-215-57.range86-132.btcentralplus.com) joined #forth 13:59:24 hey 13:59:36 hi 14:00:20 hey tathi 14:01:18 I'm kind of new to forth, not long heard of it tbh - was wondering what sort of applications its used in nowadays? 14:01:23 --- quit: neceve ("Bye people, I'm leaving") 14:01:28 embedded applications, I guess 14:01:41 yeah but still? 14:01:47 Jason is using it for some web stuff 14:01:48 "but still?" 14:02:12 i have a forth dialect i use for web stuff too. its not unusual 14:02:26 I mean I know its used in embedded for the older equipment, but is it used in upcoming and current embedded apps ? 14:02:39 yeah. I'm currently trying to write FastCGI code for gforth 14:02:54 domino-24: I would guess so, since a number of vendors are in business 14:03:11 ah right, awesome - worth learning then :) 14:03:31 Yeah i'm looking at gforth right now 14:03:33 i'm more interseted in desktops and servers myself so i don't really know 14:04:20 I don't think anyone in this channel is professionally involved in embedded development though :) 14:04:27 ohh okay, well i'm looking into going into embedded programming, got a book on embedded C, ANSI C and this embedded hardware one (where I picked up on forth) 14:04:38 yeah, I have a couple pages on my site that are coded in forth 14:04:58 oh? tbh I was shocked there was a channel for it, book made it sound ancient lol 14:05:03 JasonWoof, really? could I see? 14:05:10 yeah, it kind of is. still fun though 14:05:11 it's pretty minimal, but it handles this form and puts the output in a template 14:05:14 C is just as old as forth 14:05:23 I find C far more primitive 14:05:25 http://jasonwoof.com/pay.fs 14:05:45 yeah, C has all that annoying syntax that gets in the way 14:05:47 slava, yeah I know, but C seemed to stay in the spot light more, and I agree, I actually prefer ASM to C alot of the time :/ 14:05:53 tathi: and its not interactive 14:05:55 Thanks Jason 14:06:04 feel free to make a donation ;) 14:06:10 domino-24: because of unix and later windows, mainly 14:06:43 JasonWoof, If I had money, I would lol - end semester, bye bye loans :( 14:06:55 its end of semester here, i'm working on an exam 14:07:01 Thats cool, didn't know you could use it on web technologies too 14:07:07