00:00:00 --- log: started forth/07.02.26 00:12:32 --- join: grub_boote1 (n=charlie@d5152D937.access.telenet.be) joined #forth 00:48:25 --- join: ygrek (i=user@gateway/tor/x-5975a817701cd5ec) joined #forth 00:50:15 --- quit: edrx (Read error: 113 (No route to host)) 01:20:30 --- quit: slava () 02:11:04 --- join: ecraven (n=nex@eutyche.swe.uni-linz.ac.at) joined #forth 02:47:51 --- quit: ygrek () 03:09:04 --- join: Crest (n=crest@p548947BF.dip.t-dialin.net) joined #forth 03:41:21 --- quit: Crest ("This computer has gone to sleep") 04:07:46 --- quit: madgarden (Read error: 104 (Connection reset by peer)) 04:08:12 --- quit: Baughn (zelazny.freenode.net irc.freenode.net) 04:08:12 --- quit: Snoopy42 (zelazny.freenode.net irc.freenode.net) 04:08:13 --- quit: Zarutian (zelazny.freenode.net irc.freenode.net) 04:08:14 --- quit: madwork_ (zelazny.freenode.net irc.freenode.net) 04:08:14 --- quit: JasonWoof (zelazny.freenode.net irc.freenode.net) 04:08:14 --- quit: cmeme (zelazny.freenode.net irc.freenode.net) 04:08:15 --- quit: gnomon (zelazny.freenode.net irc.freenode.net) 04:08:15 --- quit: crc (zelazny.freenode.net irc.freenode.net) 04:08:15 --- quit: timlarson (zelazny.freenode.net irc.freenode.net) 04:08:16 --- quit: nighty- (zelazny.freenode.net irc.freenode.net) 04:08:58 --- join: JasonWoof (n=jason@unaffiliated/herkamire) joined #forth 04:08:58 --- join: Snoopy42 (n=snoopy_1@dslb-084-058-154-187.pools.arcor-ip.net) joined #forth 04:08:58 --- join: Zarutian (n=Zarutian@194-144-84-110.du.xdsl.is) joined #forth 04:08:58 --- join: Baughn (n=svein@195134062077.customer.alfanett.no) joined #forth 04:08:58 --- join: madwork_ (n=foo@204.138.110.15) joined #forth 04:08:58 --- join: gnomon (n=gnomon@CPE0050eb372bdb-CM001692f57b56.cpe.net.cable.rogers.com) joined #forth 04:08:58 --- join: crc (n=crc@pdpc/supporter/active/crc) joined #forth 04:08:58 --- join: nighty- (n=nighty-@66-163-28-100.ip.tor.radiant.net) joined #forth 04:08:58 --- join: cmeme (n=cmeme@boa.b9.com) joined #forth 04:08:58 --- join: timlarson (n=timlarso@user-12l325b.cable.mindspring.com) joined #forth 04:08:58 --- mode: irc.freenode.net set +oo JasonWoof crc 04:10:22 --- join: Raystm2- (n=NanRay@adsl-69-149-54-98.dsl.rcsntx.swbell.net) joined #forth 04:11:01 --- join: warp0x00 (n=warpzero@wza.us) joined #forth 04:11:31 --- quit: warpzero (Connection reset by peer) 04:25:34 --- quit: Raystm2 (Read error: 110 (Connection timed out)) 04:28:10 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 04:28:10 --- mode: ChanServ set +o tathi 05:41:56 --- quit: ecraven ("bbl") 05:53:14 --- quit: Baughn (zelazny.freenode.net irc.freenode.net) 05:53:14 --- quit: Snoopy42 (zelazny.freenode.net irc.freenode.net) 05:53:14 --- quit: Zarutian (zelazny.freenode.net irc.freenode.net) 05:53:14 --- quit: Raystm2- (zelazny.freenode.net irc.freenode.net) 05:53:15 --- quit: cmeme (zelazny.freenode.net irc.freenode.net) 05:53:15 --- quit: JasonWoof (zelazny.freenode.net irc.freenode.net) 05:53:15 --- quit: madwork_ (zelazny.freenode.net irc.freenode.net) 05:53:16 --- quit: tathi (zelazny.freenode.net irc.freenode.net) 05:53:16 --- quit: timlarson (zelazny.freenode.net irc.freenode.net) 05:53:16 --- quit: gnomon (zelazny.freenode.net irc.freenode.net) 05:53:16 --- quit: crc (zelazny.freenode.net irc.freenode.net) 05:53:17 --- quit: nighty- (zelazny.freenode.net irc.freenode.net) 05:53:17 --- quit: uiuiuiu (zelazny.freenode.net irc.freenode.net) 05:53:17 --- quit: hajamieli (zelazny.freenode.net irc.freenode.net) 05:53:17 --- quit: warp0x00 (zelazny.freenode.net irc.freenode.net) 05:53:18 --- quit: arke (zelazny.freenode.net irc.freenode.net) 05:53:18 --- quit: TreyB_ (zelazny.freenode.net irc.freenode.net) 05:53:18 --- quit: virsys (zelazny.freenode.net irc.freenode.net) 05:53:18 --- quit: unfy (zelazny.freenode.net irc.freenode.net) 05:53:18 --- quit: grub_boote1 (zelazny.freenode.net irc.freenode.net) 05:53:33 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 05:53:33 --- join: Raystm2- (n=NanRay@adsl-69-149-54-98.dsl.rcsntx.swbell.net) joined #forth 05:53:33 --- join: hajamieli (n=o@82.118.209.100) joined #forth 05:53:33 --- join: uiuiuiu (n=ian@schihei.net) joined #forth 05:53:33 --- join: Snoopy42 (n=snoopy_1@dslb-084-058-154-187.pools.arcor-ip.net) joined #forth 05:53:33 --- join: Zarutian (n=Zarutian@194-144-84-110.du.xdsl.is) joined #forth 05:53:33 --- join: Baughn (n=svein@195134062077.customer.alfanett.no) joined #forth 05:53:33 --- join: madwork_ (n=foo@204.138.110.15) joined #forth 05:53:33 --- join: JasonWoof (n=jason@unaffiliated/herkamire) joined #forth 05:53:33 --- join: gnomon (n=gnomon@CPE0050eb372bdb-CM001692f57b56.cpe.net.cable.rogers.com) joined #forth 05:53:33 --- join: crc (n=crc@pdpc/supporter/active/crc) joined #forth 05:53:33 --- join: nighty- (n=nighty-@66-163-28-100.ip.tor.radiant.net) joined #forth 05:53:33 --- join: cmeme (n=cmeme@boa.b9.com) joined #forth 05:53:33 --- join: timlarson (n=timlarso@user-12l325b.cable.mindspring.com) joined #forth 05:53:33 --- mode: irc.freenode.net set +ooo tathi JasonWoof crc 05:53:36 --- join: grub_boote1 (n=charlie@d5152D937.access.telenet.be) joined #forth 05:53:46 --- join: arke (n=chris@pD9E053F6.dip.t-dialin.net) joined #forth 05:53:46 --- join: warp0x00 (n=warpzero@wza.us) joined #forth 05:53:46 --- join: TreyB_ (n=trey@cpe-66-87-192-27.tx.sprintbbd.net) joined #forth 05:53:46 --- join: virsys (n=virsys@or-71-54-194-74.dhcp.embarqhsd.net) joined #forth 05:53:46 --- join: unfy (n=unfy@69.60.116.93) joined #forth 05:53:46 --- mode: irc.freenode.net set +o arke 05:58:31 --- quit: arke ("Konversation terminated!") 06:03:55 --- join: arke (n=chris@pD9E053F6.dip.t-dialin.net) joined #forth 06:03:55 --- mode: ChanServ set +o arke 06:12:33 --- quit: Baughn (Read error: 60 (Operation timed out)) 06:31:30 --- join: timlarson_ (n=timlarso@65.116.199.19) joined #forth 06:40:05 --- join: Baughn (n=svein@195134062077.customer.alfanett.no) joined #forth 06:40:22 --- join: edrx (n=Eduardo@201.5.11.48) joined #forth 06:54:12 --- quit: madwork_ ("?OUT OF DATA ERROR") 07:11:21 --- join: madwork (n=foo@204.138.110.15) joined #forth 07:53:29 --- quit: warp0x00 (Read error: 104 (Connection reset by peer)) 07:53:33 --- join: warpzero (n=warpzero@wza.us) joined #forth 08:00:11 --- quit: grub_boote1 (Read error: 110 (Connection timed out)) 08:33:41 --- join: Crest (n=crest@p548947BF.dip.t-dialin.net) joined #forth 08:42:36 --- quit: edrx (Remote closed the connection) 08:59:11 --- quit: Crest ("This computer has gone to sleep") 09:04:46 --- join: Crest (n=crest@p548947BF.dip.t-dialin.net) joined #forth 10:09:56 hey 10:18:19 --- join: ygrek (i=user@gateway/tor/x-6bbf7c2176091e83) joined #forth 10:25:29 --- join: zpg (n=user@soup.linux.pwf.cam.ac.uk) joined #forth 10:25:30 hi 10:31:09 hi zpg, Quartus_ 10:32:02 hey tathi 10:40:08 --- quit: zpg ("ERC Version 5.0.4 $Revision: 1.726.2.19 $ (IRC client for Emacs)") 11:19:33 what's new? 11:21:50 --- quit: arke ("Konversation terminated!") 11:41:45 --- join: madwork_ (n=foo@204.138.110.15) joined #forth 11:42:10 --- quit: madwork_ (Client Quit) 11:42:51 --- join: ecraven (i=nex@eutyche.swe.uni-linz.ac.at) joined #forth 11:43:37 --- quit: madwork ("?OUT OF DATA ERROR") 11:44:59 --- join: madwork (n=foo@204.138.110.15) joined #forth 13:15:47 --- quit: ecraven ("bbl") 13:28:46 --- quit: Quartus_ ("used jmIrc") 13:29:04 --- join: Quartus_ (n=Quartus_@209.167.5.1) joined #forth 13:29:04 --- mode: ChanServ set +o Quartus_ 13:30:36 --- quit: timlarson_ ("Leaving") 13:35:54 --- quit: ygrek () 14:06:54 --- quit: Baughn (zelazny.freenode.net irc.freenode.net) 14:30:42 good evening 14:40:26 --- join: slava (n=slava@CPE0080ad77a020-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth 14:40:26 --- mode: ChanServ set +o slava 14:45:11 hi crc 14:49:16 i sense quartii nearby 14:49:23 there might be 4 or more 14:49:31 or just one VERY BIG ONE!!! 14:50:50 Quartus: check out my sodoku solver at factor-language.blogspot.com 14:56:03 I saw... Short! 15:07:05 --- quit: Crest ("This computer has gone to sleep") 16:01:47 Quartii :) 16:31:30 --- quit: Quartus_ (Read error: 104 (Connection reset by peer)) 16:41:09 --- quit: cmeme ("Client terminated by server") 16:42:01 --- join: cmeme (n=cmeme@boa.b9.com) joined #forth 16:58:43 --- join: imaginator (n=George@georgeps.dsl.xmission.com) joined #forth 17:02:52 --- join: madgarden (n=madgarde@bas2-kitchener06-1096668571.dsl.bell.ca) joined #forth 17:06:26 I figured out how to add a new looping construct to Ficl last week 17:06:27 http://forth.pastebin.ca/373821 17:08:53 hmm 17:09:58 I don't understand it. :) 17:10:14 yeah, I have no idea either 17:11:20 looks like FOR = BEGIN 17:11:34 and NEXT is like AGAIN, but without consuming the dest 17:11:46 and then ENDFOR drops the dest 17:11:49 yes 17:12:43 eek 17:12:57 bleh. 17:13:07 hehe 17:14:21 I decided it's actually helped me finish my tree. 17:14:48 --- quit: Quartus () 17:15:13 hmm, so I drove away Quartus or what? the tree is less refined, but it works. I use a lot of locals 17:15:39 it's not a normal b-tree or a trie. it's a tree with n children, and n deep based on a string keys. 17:16:00 You should have just added CS-ROLL and done : NEXT 0 CS-ROLL AGAIN ; 17:16:08 :) 17:16:26 use AGAIN for the last NEXT instead of ENDFOR at the end... 17:16:38 but whatever works for you, I guess. 17:16:42 hmm 17:16:55 er. CS-PICK, I mean. 17:16:59 well when I asked any no one was around I just struggled on my own. 17:17:05 I don't know if ficl has cs-pick, but I'll check 17:17:22 what word set usually has cs-pick? 17:17:57 --- join: Snoopy_1711 (i=snoopy_1@dslb-084-058-167-149.pools.arcor-ip.net) joined #forth 17:18:02 any/and 17:18:33 TOOLS EXT 17:18:39 doesn't look like it does. 17:18:53 yah, I don't have those word sets 17:21:54 sheesh. ficl's function names are so freaking long. 17:22:31 is there a better Forth that runs on x86, Sparc, MIPS, etc. without drastic changes? 17:22:59 no, ficl is pretty solid, AFAIK. 17:24:59 I get the impression that the traditional forth community doesn't care about portability, or would rather mock C than use it. 17:25:18 oh, never mind. you want to be able to use NEXT within IF..THENs. 17:25:19 but for the project I'm building it's what I need if I want it to survive 17:25:22 so it does need a separate stack. 17:25:44 yep. I couldn't think of another way without using a separate stack 17:26:17 I rather like C, myself. 17:28:07 I like the interactive power of Forth, and the wealth of interfaces and libraries available from C 17:28:08 I was just surprised that he put a 'ficl' prefix on static function names, given that they're only visible inside that one file. 17:28:21 ah 17:28:42 perhaps to prevent conflict with some weird system that might have functions with that name that aren't static 17:29:11 eh. probably just sticking with his naming convention. 17:29:17 for instance I don't know of a Freetype-like library written in Forth 17:29:39 or a libjpeg or libpng that is written in Forth that runs on more than one platform 17:29:52 yeah. 17:30:35 while I'd love to write one -- I wouldn't love to port it to a dozen forths, and I've got enough problems writing video drivers for this window system 17:31:07 heh. 17:36:45 --- quit: Snoopy42 (Read error: 110 (Connection timed out)) 17:37:06 --- nick: Snoopy_1711 -> Snoopy42 17:41:24 --- quit: tathi ("leaving") 18:22:11 --- join: edrx (n=Eduardo@201.5.13.203) joined #forth 19:39:30 --- join: Quartus (n=neal@CPE0001023f6e4f-CM013349902843.cpe.net.cable.rogers.com) joined #forth 19:39:30 --- mode: ChanServ set +o Quartus 19:39:40 What did I miss? 19:41:41 Quartus: forth became sentient 19:42:02 not with the help of that atrocious control-flow construct of yours :) 19:42:20 Quartus: what is so atrocious about it? 19:42:43 Seriously? It's clumsy and redundant. 19:42:55 how so? how would you replace it? 19:43:12 by not using it at all. How are you using it? 19:43:51 I'll show you on the paste site 19:44:24 I was hoping for a short-hand version, like : foo bar baz ; 19:47:07 http://forth.pastebin.ca/373969 19:47:41 GAH! 19:47:50 Those definitions are HUGE 19:48:06 ay caramba 19:48:23 and with locals, to boot 19:48:42 what is it that Forth people have against locals? 19:48:54 They lead to code like this. Huge definitions, no factoring at all. 19:49:11 I mean I see all sorts of crap code with >r r> and all sorts of return-stack voodoo. The code is so difficult to understand it's usually write-only. 19:49:24 Trust me, you're well into write-only territory. 19:49:44 Ah maybe I'll just quit Forth 19:49:55 I would recommend instead actually learning to write it. 19:50:12 Factoring is a critical part of it. 19:50:13 how did I not learn? 19:50:18 No factoring. 19:50:31 not true. I refactored as I went 19:50:50 There are two enormous definitions in that paste, neither of which have any factors. 19:51:34 Quartus: so you're saying that nip/tuck/drop/swap and all of that stuff is more readable? 19:52:21 I am saying that those two definitions are way too long, have far too many nested conditionals, and employ a peculiar control-flow construct that you probably require because of the first two points. 19:52:24 It is not good Forth. 19:52:49 ok 19:52:51 :( 19:52:51 It's a starting place, but there's a long way to go. Writing code like this, you will never appreciate the strength of the language. You have to factor. 19:53:55 how about this: http://www.forthfreak.net/index.cgi?LinkedList 19:53:56 I wrote that 19:54:08 A few rules o' thumb: if you have a nested conditional, you should probably factor. If you have a nested loop, you should probably factor. If you need a local, you should probably factor. If you're storing more than one item on the return stack, you should probably factor. 19:54:20 If your definition is more than ten words (or so) in length, you should probably factor. 19:54:29 If your word does more than one thing, you should probably factor. 19:54:53 That paste is better factored. 19:55:27 If you have trouble thinking of a name for a word, you should probably factor. If the name you come up with is actually a sentence, your word does more than one thing, and you should probably factor. 19:55:47 how about this (which I also wrote)? http://www.forthfreak.net/index.cgi?StringStructure 19:56:06 I'll add -- if you need to come up with your own control structure just to scaffold your way back out of your own code, you should definitely factor. :) 19:56:15 I see what you mean 19:56:22 I'll just have to rewrite the structure somehow 19:56:37 the particular thing I made was a tree 19:56:54 Without examining StringStructure closely, it is not as well factored as the LinkedList one. The definitions are long and I see loops within nested conditionals. 19:56:54 you insert a .root and you can add children based on strings that describe the hierarchy 19:57:20 .root.child .root.anotherchild (where . is used to separate nodes) 19:57:42 That problem domain should suggest a number of factors. 19:57:53 Presently you're writing, say, C, but in Forth. 19:58:10 argh 19:58:29 now I see why people laughed at me when I said I was programming in Forth. 19:58:43 Did you show them the code? :) 19:58:45 not because of my skills, but because I chose Forth. I'm sorry 19:59:52 oh, are you hoping to drive an icy dagger into my heart by telling me somebody thought Forth was a fringe language? No luck; it is. 20:00:21 I see John Sadler's code uses locals. He wrote Ficl. He also wrote in the docs http://ficl.sourceforge.net/locals.html "Ficl provides excellent support for local variables, and the purists be damned?we use 'em all the time. " 20:00:28 now I'm left wondering if I should even bother :( 20:00:50 I'm not a purist. Locals are fine, in their place. Their place is not to facilitate bad Forth. 20:01:18 I've been reading the books I bought for YEARS 20:01:19 about Forth 20:01:28 did you buy them for years, or read them for years? 20:01:34 read them for years 20:01:50 Surely they mention short, well-named definitions. 20:01:55 Factors. 20:02:20 yes. the only thing that brought me back to Forth was reading part of Thinking Forth in PDF form 20:02:43 frankly I was very interested in Forth before, and then I realized too many of the people were interested in tiny systems. 20:03:18 Forth fits into tiny systems well. It thus fits well into large systems too. 20:04:05 I wanted to build something that was manipulating huge graphics. When I have a framebuffer that's over 5 MB or an image that size, I don't worry about a few bytes 20:04:15 No reason you can't do that with Forth. 20:04:37 I don't doubt that, but will it be something other people can understand? 20:04:51 If you write it with that in mind. 20:05:29 do you consider using the return stack better than using locals? 20:05:40 In almost every case. 20:05:43 why? 20:05:46 --- part: edrx left #forth 20:06:01 The use of the return stack encourages finer-grained factoring. 20:06:13 why not use a local? 20:06:54 Aside from them not being universally available, they promote coarser-grained factoring. 20:07:21 can you give an example of how using the return stack encourages finer-grained factoring? 20:08:17 It's cumbersome to manage more than one level deep on the return stack, so you'll want to factor to do only that (or less). 20:09:57 Quartus: what's some code that is publically available that you consider very well written as an example? 20:13:08 This is well-factored: http://nealbridges.com/source/modules.fs 20:14:53 this, too: http://nealbridges.com/source/assoc.fs 20:15:00 Not all the supporting code is there. 20:17:51 I notice the cons, cdr, (I assume LISP inspired) 20:18:09 from a lists module, not so different from yours, mostly different naming 20:19:05 This is Knuth's TPK algorithm, in Forth: http://forth.pastebin.ca/263119 20:19:11 someone said I should use the dictionary for all data structures, and I thought that was trouble, because I'm removing and adding a lot of data potentionally 20:19:23 good lord, no. The dictionary is for words. 20:19:27 so that's why I've been using allocate/free for structures and support works that use cells 20:19:57 works/words 20:20:10 This is some version of the list code: http://forth.pastebin.ca/233123 20:20:25 Pretty well factored. 20:21:45 yes 20:21:54 much better than mine 20:22:05 It's in the same ballpark. I like the names better in mine. 20:22:12 but it also doesn't solve the same problem 20:22:36 I thought it was conceptually similar. I didn't examine yours closely though. 20:23:18 I basically want to be able to type things like: S" .window.button" string find-window and have that return a data structure 20:23:29 Here's some cute code that reads and displays a file. Nice factoring. http://forth.pastebin.ca/263146 20:23:33 I also want to be able to find children of that widget/window. 20:23:53 Ok, that suggests you want associative arrays, which can certainly be buiilt atop lists. 20:24:09 why associative arrays? 20:24:17 why not a tree? 20:24:35 To be able to retrieve a data structure indexed by a string -- that's an associative array. They can also be built on trees, and trees can be built on lists. 20:25:24 ok, so a hash array or is there some sort of builtin Forth way of doing associative arrays, other than this code you shared? 20:25:41 You can trivially build associative arrays atop lists, that's the first link I gave you. 20:25:57 Hash tables are another approach. 20:26:39 Just an optimization, of course. With good factoring, you should be able to transparently replace the underlying code with an appropriately optimized version as required. 20:27:58 Encapsulate, abstract, factor. 20:28:04 Repeat. 20:29:11 hmm 20:29:50 It's a skill you can learn, and a really valuable one, as it transports into other languages. It's hard work, but worth doing. 20:30:13 If you learn to write good Forth, you'll be a better programmer in any language. 20:30:48 well I was pretty good at factoring Tcl before I left it. I'm good at factoring C I think, but like you said, I write Forth like C 20:31:07 If you have an application you need written now, write it in whatever you know best. If you want to learn Forth, learn Forth. 20:31:25 Doing both at the same time is not likely to bring happiness. 20:32:01 I'm taking my time. I'm writing a new window system, and this is the first client library 20:32:16 Good Forth factoring is far more finely grained than in C, or Tcl. 20:33:11 yes, that's what I'm finding :) 20:33:22 thank you for your patience 20:33:50 What I generally recommend is finding algorithms that interest you, and implementing them in Forth, with successive factoring iterations. Share that code, listen to the feedback, repeat. 20:34:31 As I've said before, if no algorithms interest you, you're not a programmer: go find something else to do :) 20:35:52 :) 20:35:58 well, thank you for listening -- I will always tell the truth as I see it when it comes to code review, as nothing less would be useful to either of us, but I'm sure it's unpleasant at times :) 20:36:15 one thing I really don't know how to factor is RGBA color sets 20:36:41 I don't understand the question. Isn't an RGBA color set a data structure? 20:37:45 I have a series of integers like 0 100 200 255 200 100 200 100 draw-gradient (omitting the window) I basically need a better way to work with those. 20:37:53 gah. Yes, you do. 20:38:13 The stack should not be used to schlep around large data structures. Address of them, sure. 20:40:07 how would you design that? 20:40:18 in isolation? Probably wrong. 20:40:33 isolation? 20:41:03 Fitting an abstraction to a problem domain can seldom be done by starting with one tiny piece; you've got to look at the larger picture. 20:41:52 ok, I've got a pointer to the start of the RGBA bytes for the client window 20:42:03 Without knowing the shape of the rest of the problem, I'd ask you what accessors your RGBA data structures require; that would suggest what abstractions you need to provide, what information you want to hide, what you want to reveal, and thus what factors might be useful. 20:42:08 I want to create a gradient of RGBA colors across it 20:43:47 again, this may not fit well with the entire problem domain at all, but that suggests gradient ( color1 color2 window -- ) 20:44:27 so you're suggesting I allocate an object for color1 and color2? 20:44:37 a temporary object from allocate? 20:44:58 Is that the best fit? 20:46:30 how often do you need transient RGBA data structures? How many do you need at once? How long do they need to persist? Which component will be responsible for managing them? 20:47:09 hmm 20:47:26 Design dictactes abstraction; abstraction dictates factoring. Not the other way around. 20:47:44 You don't factor on a whim, and then see what that builds. 20:48:33 You explore abstractions to find those that best fit the problem domain. There are often multiple approaches that fit equally well. 20:49:32 --- nick: Raystm2- -> Raystm2 20:49:51 Go Quartus! 20:49:59 this is the stuff I like to read. 20:51:03 Thinking about your RGBAs, they seem to me to be 'colors'. Not RGBAs. Just colors. So on a system that lacks, say, A, they'd just be RGB. Or on a system with less capacity, they might be smaller values, or larger ones. So I'd abstract that initially, to be able to specify a color in some kind of abstracted way, say as red, green, blue, and alpha, in whatever resolution I consider adequate. 20:51:18 The color accessor words would convert that into suitable internal values for the environment. 20:51:32 well it's always RGBA for this window system 20:51:39 I wrote the window system in C. 20:51:45 For this one, maybe. The abstraction may well be of value regardless. 20:53:49 I could see a system with color temporaries, so that you could green 1 set-color-register blue 2 set-color-register 1 color-register 2 color-register my-window draw-gradient 20:54:20 hmm, how is that different than a local? 20:54:28 +much 20:54:44 I'm having trouble seeing how it's the same as a local. 20:55:22 well it's a global instead 20:55:32 You're thinking in C. 20:55:53 but ideally things would just transfer in a linear way through the code with pushes and pops 20:56:01 I'm afraid you've lost me. 20:56:34 I mean the set-color-register would consist of global state 20:56:39 i.e. program-wide 20:57:00 If you prefer, green blue my-window draw-gradient I was just trying to come up with an example of how you might use color temporaries without resorting to allocations that require freeing 20:57:19 ah 20:57:52 I could show you part of what I have. the non-ugly part. the whole works, but the rest is ugly 20:58:01 Yes, I would build temporaries to be program-wide. If that's a problem, it's not a suitable fit. Again, I do not know your entire problem domain. You do. 20:58:03 Hopefully. :) 20:58:42 Perhaps you'd be better served with a special color stack, or a way of pushing and popping entire window states. 20:58:44 I don't know. 21:00:05 http://forth.pastebin.ca/374026 21:00:27 imaginator, that code makes me sad 21:00:50 why? 21:00:54 When I see code that starts by defining 4swap, 4dup, and 4rot, and uses locals to do it, I can only cry a little. 21:01:39 If you are looking to quick'n'dirty cross-translate your windowing code from C to Forth, and nothing more...? 21:01:46 I'd ask why. 21:01:55 I want interactive behavior 21:02:08 I want to interactively build interfaces 21:02:28 why is it so bad to build 4swap to build locals? it's simpler 21:02:30 In the absence of learning Forth, you may find it easier to build the interactivity on top of your existing code. 21:02:47 sorry I'm getting screwed up because I'm shaking. 21:02:56 4swap is bad. Building it with locals, well, it's just icing on the cake. 21:03:14 why? without going into dogma. why is it bad? 21:03:37 There's no way you should have eight items on the stack. 4rot is the real four-alarm one, though, because it means you have at least 12 items on the stack! 21:03:57 why have 2swap? why have floating point when you can use */ 21:04:13 that's Chuck Moore dogma IMO 21:04:40 Each has its place. 2swap is quite useful, as it's common to have two pairs on the stack. Eight items on the stack means you have a problem./ 21:04:47 why? 21:04:53 why does it mean I have a problem? 21:04:53 I'm not actually spouting dogma. 21:05:10 It means you have too much on the stack. It is tremendously difficult to manage more than 3 or 4 items on the stack. 21:05:23 To do so means you would *have* to use locals, and locals defeat factoring. 21:05:40 yet, I see the r> and r> garbage all over good Forth code. that defeats understanding IMO 21:05:56 I am not suggesting trading one kind of garbage for another. I'm suggesting writing good Forth. 21:05:59 why use the return stack, when you could use a local? 21:06:09 Because locals defeat factoring. 21:06:23 why is factoring more important than clarity? 21:06:26 You should even try to diminish your use of the return stack, for that matter. 21:06:32 Factoring promotes clarity. 21:06:37 not always 21:06:43 IMO 21:07:02 What seems clear to you, using long definitions with large numbers of arguments, with locals, is only clear in the context of languages (like C) with which you are already familiar. 21:07:43 Yes, it's possible to factor badly. I don't recommend it. 21:07:57 I don't like to use long definitions, but when I have so many things to deal with I get frustrated so locals seem more appealing 21:08:04 Then have fewer things to deal with. 21:08:39 Abstract your complexities. 21:08:52 Maybe Quartus, you should have said also that factoring produces clarity or it's not factoring. 21:09:14 Well, Raystm2, you can factor badly; I've seen it done. But even bad factoring beats no factoring. 21:09:21 I've done it :) 21:09:27 mostly all the time. 21:09:44 imaginator: my codeing looks much like yours, still. 21:10:05 Raystm2: that's a relief. I was thinking I was the only one here that didn't get it 21:10:13 imaginator, complexity itself is the indicator of the need to abstract and factor. 21:10:24 Not ashamed to admitt it. I know where I'm going with this and I know it only takes time in service to get to Quartus level forthing. 21:10:32 If you find it difficult, it's Forth telling you you need to abstract and factor. 21:11:54 If you find you're dealing with too much on the stack, stop and build an abstraction layer on top of which what you're trying to do is trivial. 21:11:58 Forth laughs at you and says " You don't really understand this problem yet, do you? It's okay. You'll map what you do know on this version, which will tell you what you don't know for the next. 21:12:01 " 21:13:10 What 21:13:13 's 21:13:36 that Newtonion method that uses um 21:13:50 What's newt onion? 21:14:00 :) 21:14:14 New from Lipton's? 21:14:18 olivia newt onion john. 21:14:37 oh it's the aproximation of Pi 21:14:43 forth is like that 21:15:05 newt onion pie, eh? 21:15:10 yuck 21:15:19 approximation indeed 21:15:19 It's not so much that I don't understand the problem, because I solved it in Tcl and C for NexTk http://mini.net/tcl/NexTk But mapping the problem to Forth is much different. 21:15:42 I don't have reference counted objects anymore. I've just got the stack for temporaries, or the ugly locals 21:15:43 you are heading to a place that is first a little left of target, then corrected but overshoot a little right of target always getting closer never getting there. 21:15:57 I would suggest, in parting as I have to sleep, that it's not a mapping of the problem to Forth, so much as it's a mapping of the solution to both the problem, and the programmer. 21:16:52 Forth is the medium. 21:18:57 imaginator: forgetting every other version of this solution you've ever coded, please make a list of words that would be considered the lexicon of the problem domain. For instance BASEBALL: score teams players stats scoreboard .... on and on what ever comes to mind, but use words that describe you actually manipulating the problem as you might if you could physically. 21:19:17 Anyway, happy to rant on at a later time if you like! 21:20:52 I always like, if you're asking me. 21:21:01 :) 21:21:28 good idea. thanks Raystm2 21:24:02 When you are looking at a bass guitar amplifier, you can toggle the on off switch, twist dials, plug in stuff. 21:25:08 So your bass guitar amplifier program written in forth prob'ly will do all of those things as well. 21:25:29 How it does it, doesn't have to be reflected in the name of the word. 21:25:41 Shouldn't be, actually. 21:26:01 That is the abstraction. Below the name level, things could change and be done other ways. 21:26:41 But it's like, you know, a knob is always a knob, a switch is always a switch... 21:28:26 The definition of the word is the difference between what you expect to happen and what the machine already knows how to do. You connect those points. 21:29:01 Sometimes the definition of a word sprouts other words... on and on... 21:29:15 always, really. 21:32:31 That list above, you Quartus, doing all of those ( paraphrase with licence) " if you need locals... you may be a red neck"... that's good stuff up there. Log snack. 21:36:31 Did you do something akin for the book? 21:36:51 Longer list. :) Anyway I must go, chat later. 21:37:03 Oh, sure. okay, bye. :) 21:49:17 --- join: Crest (n=crest@p548941B7.dip.t-dialin.net) joined #forth 22:05:35 --- quit: Crest ("This computer has gone to sleep") 23:59:59 --- log: ended forth/07.02.26