00:00:00 --- log: started forth/06.07.01 00:05:51 --- join: llama32 (n=zak@075.a.001.beg.iprimus.net.au) joined #forth 00:32:39 --- quit: JasonWoof ("off to bed") 01:05:23 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth 01:05:51 hi 01:30:15 --- quit: snowrichard ("Leaving") 02:26:07 --- quit: virl (Remote closed the connection) 02:53:42 [trying to supress any bias you might have], is forth as productive for large scale development as more conventional languages [C]? 02:55:02 instead of insulting us by 'trying to suppress any bias we might have', ask better questions. 02:57:25 The one you've just asked essentially reads as "Those of you who have experience in large-scale-development so large-scale that it somehow only used C, and also with large-scale-development that somehow only used Forth, please share your particular biases and thoughts on the relative capabilities of these languages in these areas -- but please do so as if we'd met in the street, and not, even though you are in #Forth, hesitate to say 'fuc 02:58:00 lol 02:58:07 i can't really think of a way of rephrasing it 02:58:10 If you think a bit, you ought to come up with better-factored questions. 03:01:49 er, that quote should be "forth totally sucks, man" 03:06:33 It's probably that forth.com is still your best bet on getting comparative anecdotes. Just ask forth.com if they can share any stories about how they'd stepped in after a C team bungled something and then with Forth rewrote everything better than the customer expected and more capable and whatnot. An anecdote is the best you can get, anyway, and you won't get "bias" from FORTH Inc so much as you'll get information you can't really make 03:06:45 also, probable. 03:09:17 You shouldn't bother to learn Forth, llama32. No matter how many straw men we knock down, you'll eventually find one that justifies you not bothering; cut to the chase. 03:09:41 lol 03:09:59 I'm quite serious. 03:17:31 Pick from the available reasons: Forth isn't widely taught, it isn't as popular as C and C derivatives, there aren't a huge number of available textbooks, and it differs enough from other languages to make it challenging to learn. 03:17:39 Quartus - have you had this discussion many times before? 03:17:45 Too many, ayrnieu. 03:18:56 If someone comes in looking for a reason not to learn, hand them one from the pile, save your energy for those who come in wanting to learn instead. 03:41:36 --- join: zpg (n=user@81-178-234-94.dsl.pipex.com) joined #forth 03:43:20 greetings 03:44:58 greetings and salutations fellow earth creature 03:45:46 * zpg employs the internationally recognised postfix bow 03:46:35 --- join: yoyofreeman (n=root@219.145.81.147) joined #forth 03:50:24 ok - question time - what's the predominant approach: to define new words with the most logical parameter lists or to define them such that the minimal number of manipulations are necessary? OR: keep to a simple definition in a definition "new-word-1" and then write "new-word" which manipulates the stack then calls the cleaner function? 03:51:53 "new-word-1" is probably rarely used. For the first two, it depends. Clearly no amount of stack-manipulation ease would make it very wise to have 1 3 - evaluate to (positive) 2 03:52:55 oh for sure 03:53:11 also, you need to consider not just your words internal stack manipulation but the ease by which the caller can provide your arguments. One convention is that harder-to-calculate arguments should come deeper on the stack than easier-to-calculate arguments, for instance. 03:53:12 i'm just wondering whether there's a convention applied or it's almost always down to context 03:53:30 ah ok 03:53:50 I think there are a whole bunch of little rules-of-thumb 03:53:52 well, yes, "logical parameter lists" is a convention all by itself. 03:54:00 which you then violate as necessary :) 03:56:04 adresses go on top (for things like fetch/store), ditto similar things like file-ids for READ-FILE/WRITE-FILE 03:56:22 address and then count. source destination count. 03:57:04 --- join: Cheery (i=Henri@a81-197-12-134.elisa-laajakaista.fi) joined #forth 03:59:31 * zpg nods 04:00:24 also, since we're on the topic of parameters: how frequently is "locals| ...|" employed? 04:01:45 I couldn't say, but if I wanted locals I'd prefer gforth's stack-comment-like syntax (which it has a compat/ ANS implementation of). 04:03:18 I don't know either; personally I've never used locals... 04:04:21 I sort of think they're popular with people coming from other languages who run into trouble with stack manipulation 04:04:38 But after a while you learn to design your programs so that you don't need so much 04:04:50 but I have no data to back that up at all :) 04:08:21 hehe 04:09:10 yes, they seem to offer an extra layer to aid portability of previous programming style 04:12:01 just the other day I suggested to someone (in another channel), that if you're going to have really ugly code (as presented), you should at least give up and do what you need to do to make it somewhat readable. Locals are not abhorrent. 04:15:37 --- quit: llama32 (Read error: 110 (Connection timed out)) 04:15:58 * zpg nods 04:16:55 i guess it's again a matter of the specific definition. in some, locals will be extra baggage, not necessary for clarity and simply taking up space. in others, they'll save confusion (even with comments / documentation present) and therefore improve extensibility and usage. 04:17:07 zpg - I know I've read more than a few suggestions on parameter order , but I can't find them together right now. Probably in practice any confusion you have with such order will make itself felt juggling throughout your program, and you'll spontaneously fix the bug. I've found lots and lots of naming mnemonics and like talk searching for parameter order stuff, however, so probably a bad name is harder to fix without thought. 04:17:13 --- join: llama32 (n=zak@070.a.001.beg.iprimus.net.au) joined #forth 04:18:04 zpg - the popular bias is probably that they're a crutch -- that simply using them means that you've failed in some, possibly more important way. 04:18:39 i thought that might be the case 04:19:24 re: juggling, some good points -- even in the more widespread languages (e.g., C) bad naming of variables and functions can induce bugs through simple misunderstanding of functionality. 04:21:01 consider this: http://www.oreillynet.com/onlamp/blog/2004/03/the_worlds_two_worst_variable.html -- and then read the very first comment, from 'pudge'. The tie-in from that comment after that article to Forth should come easily :-) 04:25:30 You might also read The Stylish Stack (starts on page 198) in Thinking Forth , which you can get online. 04:27:28 just read the blog 04:28:37 not so sure i agree with the pudge comment; certainly, when coding in Smalltalk or C, decent method/function and variable naming comes in handy for readability. perhaps during a burst of coding, thinking up good variable names is a distraction (you can of course write a subroutine then alter the variable names when done) but it can also aid thinking when instead of manipulating "i" you're manipulating "interest" instead. 04:29:14 also, you can't just think about 'getting the job done' i.e., the old write-only problem; extending or modifying code also requires a decent degree of forethought during the composition phase, though this can be done with commenting too. 04:29:20 looking at the Brodie now. 04:29:50 IIRC there's some good stuff toward the end of the Detailed Design/Problem Solving chapter 04:30:02 as well 04:31:01 tathi: in the same book? 04:31:56 yes. Thinking Forth is a good book. 04:35:59 VERY interesting: 04:36:03 "An informal examination of one of Moore’s applications shows that he averages seven references, including both words and numbers, per definition. These are remarkably short definitions. (Actually, his code was divided about 50–50 between one-line and two-line definitions.)" 04:37:31 re: parameter order, this chapter that tathi suggests seems filled with tips -- thanks 04:38:02 I'm mainly apalled when I come across people who casually assert that subroutines shouldn't be longer than 20 or 50 lines. 04:38:42 someone pointed out the other day that Forth recommends definitions not longer than 24 lines, and complained that when you have functions this small you lose a feel for the structure of the program as a whole. 04:39:34 personally i think i'd find 24 line definitions confusing 04:39:52 (far more so than the alternative supposed "structure loss") 04:40:26 hehe 04:40:28 --- quit: yoyofreeman (Remote closed the connection) 04:41:15 tip: use dumb words. 04:41:57 for example, when paging through elisp code (a regularity) definitions are often very short, referring to one or two other functions in the same module. these in turn refer to others defined there too, and so on. however, a few minutes of explorpation gives a feeling for structure AND functionality; long lisp definitions can be heavily confusing, even when you can grasp what something does (as it's all in one definition), you can 04:41:57 make a cup of coffee and lose sight of it very easily. 04:41:59 dumb words? 04:42:31 zpg - there are actually several variations of that, but here he means non-STATE-dependent 04:46:34 ah ok 04:47:34 indeed, if the words are well named, you can take their functionality for granted - treat them as black boxes - then the notion of 'fragmented' structure in the sense we've been discussing becomes somewhat questionable. 04:48:18 but in forth you can't define a new word that calls one not yet defined can you? 04:48:33 i.e., top down programming, i write a heavily abstract definition, then fill in the rest of the definitions afterwards. 04:48:45 wwith indirection, you can. see DEFER 04:49:11 well, you can simply write the definition and then not compile it... 04:49:47 taking it to the extreme of historical top-down programming would be unwise, I think, and the beginning of Thinking Forth takes it well to task. 04:50:04 but it only makes sense to think occasionally about your goal :-) 04:50:22 --- join: PoppaVic (n=pete@0-2pool236-26.nas22.chicago4.il.us.da.qwest.net) joined #forth 04:50:42 ... still haven't written that quiz-processing software, but I've got the quiz I need to study typed up with the appropriate words. 04:50:53 * zpg nods 04:51:11 the most successful work i've done is in Smalltalk where you can't compile a method without all the messages already in place. 04:51:19 -vs- lisp 05:39:05 we refer to ANS Forth as 'ANS Forth', although others refer to other language standards with 'ANSI' as the adjective, as in 'ANSI C', and 'ANSI Common Lisp'; in Scientific FORTH, Julian V. Noble refers to the then-ongoing ANS Forth effort as the ANSII Forth effort! 05:42:33 --- quit: tathi ("leaving") 05:49:46 yeah i found the lack of -I confusing 05:50:12 Quartus: (not sure you're around but if so): just testing out your system on a Palm emulator, very impressive! 06:13:46 --- quit: PoppaVic ("Pulls the pin...") 06:33:17 anyone here on osx? 06:35:14 Yes. 06:35:53 do you use forth for the platform (i.e., not cross-devel)? 06:37:01 Yes, sometimes. It is not where I normally use Forth. 06:37:16 ah ok. 06:37:41 i'm wondering if there's a convenient api for cocoa or carbon 06:37:59 There is not nearly as nice a bridge as there is for Python or Lua. 06:38:01 or generic gui access, that in this case accesses the above frameworks 06:38:21 yeah, as expected. 06:38:25 But the most recent PowerMops release does allow better framework calls. 06:38:31 * zpg nods 06:38:35 that's the only thing i've found so far 06:39:02 the environment as a whole feels a little clunky (compared with gforth via a terminal) 06:39:33 I don't like QEdit, but I like the other bits. 06:39:46 yeah that's what i found 06:39:51 i gather you don't have to use Qedit though? 06:40:41 No. It is just text files after all. :-) 06:40:52 good stuff, as long as the terp isn't expecting input to come from qedit 06:40:58 * zpg fires up powermops 06:47:24 i remain baffled by this interfae 06:47:26 *face 06:47:33 Jim7J1AJH: so do you mainly do embedded work with Forth? 06:57:14 hmm, by the look of it i could employ ficl and write some simply primitives that access wxWidgets 06:57:18 *simple 07:21:31 Yes. I normally use it for embedded processors. 07:28:51 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 08:14:02 --- quit: llama32 (Read error: 110 (Connection timed out)) 08:26:48 --- join: virl (n=virl@chello062178085149.1.12.vie.surfer.at) joined #forth 08:33:58 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth 08:48:28 --- quit: zpg ("ERC Version 5.0.2 $Revision: 1.726.2.10 $ (IRC client for Emacs)") 09:33:20 --- quit: snowrichard ("Leaving") 09:37:19 --- join: JasonWoof (n=jason@pdpc/supporter/student/Herkamire) joined #forth 09:37:19 --- mode: ChanServ set +o JasonWoof 10:05:27 --- join: PoppaVic (n=pete@0-1pool74-235.nas24.chicago4.il.us.da.qwest.net) joined #forth 10:23:36 --- join: snowrichard (n=richard@adsl-69-155-177-154.dsl.lgvwtx.swbell.net) joined #forth 10:24:02 hi 10:38:08 hi 10:38:55 --- quit: snowrichard ("Leaving") 10:52:56 --- join: zpg (n=user@85-210-47-198.dsl.pipex.com) joined #forth 11:26:12 --- quit: PoppaVic ("Pulls the pin...") 11:26:15 Hi zpg -- thanks! 11:28:30 no worries Quartus 11:28:46 enjoyed tinkering in the emulation 11:46:24 --- quit: zpg (Remote closed the connection) 11:48:36 --- join: zpg (n=user@85-210-47-198.dsl.pipex.com) joined #forth 11:59:50 --- quit: Al2O3 (Remote closed the connection) 12:01:48 --- quit: zpg ("reboot") 12:02:19 --- join: nighty (n=nighty@sushi.rural-networks.com) joined #forth 12:34:17 --- join: swsch (n=stefan@pdpc/supporter/sustaining/swsch) joined #forth 13:19:21 --- join: ttuttle (n=tom@unaffiliated/ttuttle) joined #forth 13:19:23 Quartus: hey 13:19:30 * ttuttle got his PIC programmer working. 13:23:17 a selfmade or a bought one? 13:25:17 selfmade 13:25:32 virl: http://home.earthlink.net/~davesullins/software/pic18f.html 13:26:48 pic18, hmm, could it be that you use picforth? 13:27:33 virl: I'm planning to write a Forth for it eventually. I want to build a portable, programmable Forth machine. 13:28:02 virl: With a small LCD, a chording keyboard, rechargeable battery, and maybe IR. (A Forth-powered remote could be cool.) 13:29:05 Hey. 13:29:22 Quartus: Hey. 13:29:33 * ttuttle hates his horrible soldering skills. 13:29:46 I learned young, so I got pretty good at it. 13:29:51 ttuttle, wasn't it also you who was interested in xell? ( oh dear I forget names ) 13:29:51 No burns yet today (/me crosses fingers) but I'm just really slow at it. 13:30:09 ttuttle: xell? 13:30:16 virl: I changed nicks ;-) 13:30:20 virl: I used to be ThinkingInBinary. 13:30:34 virl: It took up 1/3 of PoppaVic's ancient 40-column terminal that he shares with his 17 siblings. 13:30:41 oh, ops. ok, well, who was interested so about xell. 13:30:48 'sibs', ttuttle. 13:31:06 Quartus: Ah. 13:31:14 Quartus: lol 13:31:17 with whom he shares 'chores'. 13:31:37 Quartus: lol 13:31:41 Quartus: I wonder how old he actually is. 13:32:07 46. 13:32:20 who is 46? 13:32:25 PoppaVic. 13:32:31 Quartus: Hmm. 13:32:54 oh. 46? that's not realy old. 13:33:03 True. 13:33:15 * ttuttle is happy because he convinced Verizon to switch his DSL line from Interleaved to Fast Path, which lowers his first-router latency from 23ms to 8ms. 13:33:36 I have no idea what any of the latencies are on this link 13:33:40 It's old enough to talk like you're wise, but (evidently) not old enough for some people to actually be wise. 13:34:00 Quartus: Try traceroute against a random computer, and look at the first router that isn't yours. 13:34:31 I thought he is something like 60 or so 13:34:43 virl: He pretends to be. 13:35:32 Looks like 23ms. 13:35:36 ehm, well, that's not ok. 13:35:50 Quartus: Something like that. Not bad. 13:36:14 Quartus: Of course the first router in your case is a neighborhood cable router rather than the central office, so your actual latency is probably a little more. 13:36:33 Hard to say. The overall speed isn't bad. 13:36:40 I don't play network games any more. 13:36:49 Videogames, I mean. So it's not as critical. 13:36:52 Quartus: Yeah. I wish we had 30 and 100 Mbit connections like other, cooler countries have. 13:37:13 Quartus: Yeah. I don't play much, but apparently telling Verizon you do is the way to get them to switch you. 13:37:59 Quartus: w00t! Less than 10ms to my DNS server! 13:38:17 Speakeasy's test to Seattle says 991 down, 308 up. 13:38:33 Quartus: I get about 2700/700. 13:38:41 * ttuttle likes Verizon DSL. 13:38:56 I'm on cable, not DSL. 13:39:13 And because we have phone service from them too, we get $5 off, and there's a "special" support line that gives you quicker/nicer tech support. 13:39:20 Quartus: I know. Your hostname includes "cable" in it. 13:39:31 Quartus: CPE0001023f6e4f-CM013349902843.cpe.net.cable.rogers.com 13:39:40 Quartus: I would guess you have Rogers, too. 13:39:48 To New York, 3676/373. 13:39:59 Quartus: But that's not always right, because I was a subdomain of verizon.net when I had Earthlink, because I was on Verizon lines. 13:40:01 Quartus: That's much better. 13:40:21 Quartus: New York is a good test site. 13:40:50 To San Fran, 1218/315. Much depends on the destination. 13:41:16 Quartus: Yeah. That's strange. You'd figure the *latency* would be destination-dependent, not the speed. 13:41:37 Maybe this speed test incorporates both. 13:41:52 Quartus: It shouldn't, really. Bandwidth is what it purports to measure. 13:42:45 Well, it's not something I worry about -- unless the link became noticeably slow. 13:44:21 --- quit: swsch ("Leaving") 13:51:26 --- quit: Cheery ("Leaving") 13:51:40 --- quit: ttuttle ("leaving") 15:00:06 --- join: Al2O3 (n=Al2O3@pool-70-104-23-46.dllstx.fios.verizon.net) joined #forth 15:07:28 --- join: zpg (n=user@81-178-233-27.dsl.pipex.com) joined #forth 15:14:08 --- join: snoopy_1711 (i=snoopy_1@dslb-084-058-160-038.pools.arcor-ip.net) joined #forth 15:22:03 --- quit: Snoopy42 (Read error: 145 (Connection timed out)) 15:22:06 --- nick: snoopy_1711 -> Snoopy42 16:20:38 --- quit: nighty ("Disappears in a puff of smoke") 16:41:12 --- quit: tathi ("leaving") 16:56:59 --- quit: zpg ("ERC Version 5.0.2 $Revision: 1.726.2.10 $ (IRC client for Emacs)") 17:38:53 --- join: I440r (n=mark4@24-177-235-246.dhcp.gnvl.sc.charter.com) joined #forth 17:57:34 --- quit: crc (Nick collision from services.) 17:57:56 --- join: crc (n=crc@pdpc/supporter/active/crc) joined #forth 17:57:56 --- mode: ChanServ set +o crc 18:14:44 --- quit: virsys (Read error: 104 (Connection reset by peer)) 18:37:29 --- join: yoyofreeman (n=root@219.145.11.85) joined #forth 18:46:43 --- quit: yoyofreeman ("Download Gaim: http://gaim.sourceforge.net/") 18:47:45 --- join: virsys (n=virsys@or-71-53-74-48.dhcp.embarqhsd.net) joined #forth 18:56:40 --- quit: uiuiuiu (Remote closed the connection) 18:56:44 --- join: uiuiuiu (i=ian@dslb-084-056-232-014.pools.arcor-ip.net) joined #forth 19:11:48 --- join: llama32 (n=zak@086.a.001.beg.iprimus.net.au) joined #forth 20:20:42 --- quit: llama32 ("Leaving") 20:37:43 --- join: segher__ (n=segher@dslb-084-056-141-254.pools.arcor-ip.net) joined #forth 20:48:57 --- join: snowrichard (n=richard@adsl-69-155-177-157.dsl.lgvwtx.swbell.net) joined #forth 20:49:12 --- quit: segher_ (Read error: 110 (Connection timed out)) 21:04:27 --- quit: I440r ("Leaving") 21:07:13 --- quit: snowrichard ("Leaving") 23:01:56 --- quit: saon (Read error: 110 (Connection timed out)) 23:34:43 --- join: Cheery (i=Henri@a81-197-12-134.elisa-laajakaista.fi) joined #forth 23:59:59 --- log: ended forth/06.07.01