00:00:00 --- log: started forth/07.03.07 00:18:17 --- join: ecraven (i=nex@eutyche.swe.uni-linz.ac.at) joined #forth 00:47:04 --- join: Snoopy_1711 (i=snoopy_1@dslb-084-058-140-031.pools.arcor-ip.net) joined #forth 01:04:36 --- quit: Snoopy42 (Read error: 110 (Connection timed out)) 01:04:54 --- nick: Snoopy_1711 -> Snoopy42 01:12:44 --- join: aum (n=aum@60-234-243-247.bitstream.orcon.net.nz) joined #forth 01:25:08 --- nick: arke_ -> arke 01:25:09 --- mode: ChanServ set +o arke 03:59:06 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 03:59:06 --- mode: ChanServ set +o tathi 04:27:01 --- join: azekeprofit (i=azekepro@82.200.250.135) joined #forth 05:27:03 --- join: ygrek (i=user@gateway/tor/x-6c9cd359578f087b) joined #forth 05:54:17 --- quit: Quartus_ (Read error: 104 (Connection reset by peer)) 06:19:35 --- quit: ecraven ("bbl") 06:47:04 --- join: timlarson_ (n=timlarso@65.116.199.19) joined #forth 06:47:19 --- quit: edrx (Read error: 110 (Connection timed out)) 08:00:01 --- quit: arke ("Konversation terminated!") 08:16:15 --- join: JasonWoof (n=jason@c-71-192-30-169.hsd1.ma.comcast.net) joined #forth 08:16:15 --- mode: ChanServ set +o JasonWoof 09:04:08 --- join: neceve (n=Clau@unaffiliated/neceve) joined #forth 09:17:27 --- quit: azekeprofit (Read error: 110 (Connection timed out)) 09:40:28 --- join: Quartus_ (n=Quartus_@209.167.5.2) joined #forth 09:40:28 --- mode: ChanServ set +o Quartus_ 09:41:45 --- quit: tgunr (Read error: 131 (Connection reset by peer)) 09:52:17 --- join: tgunr (n=davec@72-173-45-71.cust.wildblue.net) joined #forth 10:08:09 --- quit: timlarson_ (Read error: 104 (Connection reset by peer)) 10:08:13 --- join: timlarson__ (n=timlarso@65.116.199.19) joined #forth 10:15:19 --- quit: timlarson__ (Read error: 104 (Connection reset by peer)) 10:25:45 --- join: timlarson_ (n=timlarso@65.116.199.19) joined #forth 10:27:43 --- quit: timlarson_ (Read error: 104 (Connection reset by peer)) 10:59:12 --- join: Crest (n=crest@p5489F50B.dip.t-dialin.net) joined #forth 10:59:17 hi 11:24:23 --- quit: tgunr () 11:24:39 --- join: tgunr (n=davec@72-173-45-71.cust.wildblue.net) joined #forth 11:40:39 --- join: timlarson_ (n=timlarso@65.116.199.19) joined #forth 11:58:11 --- quit: Quartus_ (Read error: 145 (Connection timed out)) 12:44:51 --- join: edrx (n=Eduardo@201.5.11.52) joined #forth 13:03:54 --- part: edrx left #forth 13:12:06 --- quit: ygrek (Remote closed the connection) 13:20:30 --- join: crest_ (n=crest@p5489F2AD.dip.t-dialin.net) joined #forth 13:25:40 hi - has anyone tried a scheme of adding size-markers to items on data stack? 13:26:44 eg, a 16-bit int 'AD43' represented as 'AD 43 02', or the 8-bit int E7 represented as 'E7 01' 13:27:36 why? 13:28:31 to give some transparency to number size 13:28:52 it's not necessary 13:29:10 it just felt like an idea 13:29:16 however, newbies always think it is, and several people have written forth-like system with typed stacks. 13:29:23 I don't know much about any of them. 13:29:29 StrongForth might be one? 13:29:45 thx, shall google and see if it offers some ideas 13:30:15 to multiply a 32-bit int by a 16-bit int, one needs to convert the 16-bit int to 32 bits, then use a 32-bit multiplication 13:31:23 er. only if you're using a 16-bit Forth, or are writing an optimizing compiler... 13:31:46 what's the context of this? 13:31:53 i've written a tiny bytecode interpreter for AVR MCUs 13:32:20 the interpreter weighs in at 86 bytes - not too bad for MCUs with only 2k of flash 13:32:42 ah 13:32:50 but I wanted to look at the possibility of a typed stack, so I don't need n different routines for multiplication, n for addition, etc 13:33:32 with a typed stack, I could save cycles by having only 3 of each routine, 1 for 8-bit operands, 1 for 16-bit, 1 for 32-bit 13:33:45 --- quit: timlarson_ ("Leaving") 13:33:54 and choose the smallest routine which fits the operands 13:33:59 you could do that anyway, and have explicit conversion routines 13:34:07 true 13:34:16 the other option is to go straight 16-bit data 13:34:19 --- join: crest__ (n=crest@p5489C781.dip.t-dialin.net) joined #forth 13:34:25 and offer a few 32-bit primitives 13:34:34 either of those would be a more usual Forth thing to do. 13:34:44 --- quit: Crest (Nick collision from services.) 13:34:46 keep it simple, and push the decisions off onto the programmer. :) 13:34:55 hehe 13:35:01 --- nick: crest__ -> Crest 13:49:36 --- quit: crest_ (Read error: 110 (Connection timed out)) 14:14:45 --- join: Quartus_ (n=Quartus_@209.167.5.2) joined #forth 14:14:46 --- mode: ChanServ set +o Quartus_ 15:01:50 hey 15:08:17 hi 15:45:31 good evening 15:49:00 hey hey. 16:26:27 --- join: vatic (n=chatzill@ool-45740b1c.dyn.optonline.net) joined #forth 16:32:13 --- join: crest_ (n=crest@p5489E24D.dip.t-dialin.net) joined #forth 16:47:41 --- quit: Crest (Read error: 110 (Connection timed out)) 17:02:47 --- join: mark4 (n=mark4@70.102.202.162) joined #forth 17:16:59 --- quit: neceve (Read error: 104 (Connection reset by peer)) 18:46:36 --- quit: crest_ (Read error: 110 (Connection timed out)) 18:47:43 --- quit: madgarden (Read error: 104 (Connection reset by peer)) 18:48:08 --- join: madgarden (n=madgarde@bas2-kitchener06-1096668571.dsl.bell.ca) joined #forth 18:53:43 --- join: slava (n=slava@CPE0080ad77a020-CM000e5cdfda14.cpe.net.cable.rogers.com) joined #forth 18:53:44 --- mode: ChanServ set +o slava 18:53:56 Quartus: i implemented a new parser design and i like it much better than the traditional forth way. 18:54:03 it is recursive descent. 18:54:20 for example, : parses until ; is reached, instead of pushing a sentinel on the stack which ; then receives. 18:56:03 doesn't that cause problems with defining words? 18:56:07 or don't you use : for that? 18:56:26 hi slava 18:56:44 the parser loop is invoked recursively. 18:56:55 so : parses everything until ;, calling parsing words it finds along the way. 18:57:07 but ; is not a parsing word, in fact it is just defined to throw an error 18:57:13 telling the user they have an unmatched ; 19:01:04 --- quit: vatic ("*poof*") 19:01:44 sure. 19:01:57 I guess I was asking if it has this problem: http://www.taygeta.com/forth/dpansa6.htm#A.6.1.2250 19:02:30 factor doesn't have state. the parser aways 'compiles'. 19:03:36 I know...I still don't get it. I'll just have to think it through. 19:09:14 --- quit: OrngeTid1 ("ugh") 19:09:49 slava: happy belated birthday, btw. :) 19:09:56 thanks 19:11:56 Och, it was your birthday? I'm sorry I missed that! 19:12:02 heh np 19:30:10 --- quit: ayrnieu (Connection timed out) 20:14:33 --- join: iano (n=iosgood@host-226-114.dhcp.pdx.edu) joined #forth 20:23:04 --- join: iano_ (n=iosgood@dhcp-223-38.seas.pdx.edu) joined #forth 20:37:28 --- quit: tathi ("'night all") 20:40:37 --- quit: iano (Read error: 110 (Connection timed out)) 20:52:22 slava, what advantages does the complexity confer? 20:52:32 it actually simplifies the design. 20:53:11 What does it let you do that you couldn't? 20:53:35 better error reporting. if you forget to close a ; you get 'expected ; but found end of input'. 20:53:40 ditto the other paired parsing words 20:53:56 What do you lose? 20:54:08 nothing as far as i can tell. 20:54:16 it seems to work. 20:56:53 I have a recursive descent parser in Standard Forth I've played with a bit. 21:01:39 a contributor managed to write a lisp interpreter in a couple of pages of factor code. 21:02:23 For some reason that makes me think of the Forth that's written in Bash :) 21:02:27 it supports lexical closures and all factor data types 21:05:38 --- join: ayrnieu (n=julian@pdpc/supporter/sustaining/ayrnieu) joined #forth 21:05:43 hi ayrnieu 21:05:49 howdy. 21:08:29 --- quit: cmeme ("Client terminated by server") 21:09:02 --- join: cmeme (n=cmeme@boa.b9.com) joined #forth 21:53:50 --- join: azekeprofit (i=azekepro@82.200.252.234) joined #forth 22:11:48 --- quit: ayrnieu (Read error: 110 (Connection timed out)) 22:19:22 --- quit: iano_ (Read error: 110 (Connection timed out)) 22:30:03 --- join: ayrnieu (n=julian@pdpc/supporter/sustaining/ayrnieu) joined #forth 23:24:04 --- join: OrngeTide (i=orange@orangetide.com) joined #forth 23:24:14 hey guys 23:59:59 --- log: ended forth/07.03.07