00:00:00 --- log: started forth/07.03.01 01:07:35 --- quit: Quartus_ (Read error: 110 (Connection timed out)) 01:09:59 --- quit: madwork (Read error: 104 (Connection reset by peer)) 01:33:11 --- join: ecraven (i=nex@eutyche.swe.uni-linz.ac.at) joined #forth 02:13:14 --- quit: imaginator ("sleep") 02:33:58 --- quit: gnomon (Remote closed the connection) 02:34:08 --- join: gnomon (n=gnomon@CPE0050eb372bdb-CM001692f57b56.cpe.net.cable.rogers.com) joined #forth 02:50:51 --- quit: Quartus (Read error: 60 (Operation timed out)) 05:06:31 --- join: xiq (n=pix@p83.129.176.109.tisdip.tiscali.de) joined #forth 05:08:44 i'm new to forth. i'm just playing with amforth on a microcontroller. it doesn't have PICK. is PICK that fundamental? or is there an easy way to implement it with other core words? 05:22:51 --- quit: Raystm2 (Read error: 60 (Operation timed out)) 05:22:59 Generally speaking, you want to avoid using PICK. The rule-of-thumb says that if you think you need it, you probably haven't factored the code well enough, or you need to re-think the order of the items on the stack. 05:25:01 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 05:25:01 --- mode: ChanServ set +o tathi 05:30:23 ok, i thought so. but out of curiosity, is there an easy way to redefine PICK? 05:32:26 Not that I can think of, but one of the folks that have implemented their own forths might know. 05:33:46 It requires carnal knowledge of the stack implementation for the Forth in question. 05:36:04 yeah i guess if i could get the address of the stack it would be easy 05:41:20 Again, that assumes a lot about the implementation. Optimizing compilers may put one or more stack cells in registers over the life of a word. 05:44:21 --- join: Quartus (n=neal@CPE0001023f6e4f-CM013349902843.cpe.net.cable.rogers.com) joined #forth 05:44:21 --- mode: ChanServ set +o Quartus 05:45:10 true.. 05:45:28 i think i've found out how to do it, but you are right, i won't use it. it's just a learning exercise 05:57:31 weird, when i read from the stack, the endianness is backwards. 06:20:12 you can implement PICK with the basic stack manipulation words 06:20:22 but it's really slow to pull from down low 06:20:37 crazy juggling 06:20:44 you shouldn't ever use PICK anyway 06:20:57 stack juggling is not a useful skill 06:21:20 learning to factor well so you don't need to juggle is a very useful skill 06:22:32 JasonWoof: re sqrt.fs - a standard / does not have to do symmetric division. 06:22:40 it seems to be the usual case, but the standard allows it to be either way. 06:25:12 oh 06:25:52 guess that's implementation specific then 06:25:56 to be *really* safe you'd have to do S>D 2 SM/REM NIP I think. 06:26:27 the Forth Programmer's Handbook on forth.com says most hardware implementations are symmetric. 06:27:10 but that "some applications (such as graphics) require floored division in order to get a continuous function through zero." 06:27:46 sure, floored math is often useful 06:29:07 I'm glad you made me check it out though; in the CVS version of gforth, the default is to have / do floored math. 06:29:20 which is silly IMO, because it's slower. 06:29:44 So I'm going to reconfigure and rebuild it. 06:30:15 woh, weird 06:30:42 yeah. there's an option to configure to use the native /, but by default it adjusts to do floored. 06:30:56 funky 06:31:04 that's a very strange thing to change 06:31:14 I guess it's best for it to be consistant accross platforms 06:32:18 it's so weird to me that there's all these weird math words like SM/REM that take three arguments and return two 06:32:30 and no simple name for a normal symetric divide 06:33:04 I think on CISC platforms (certainly on x86) the normal divide instruction usually returns both. 06:33:16 I think the hardware has to compute it anyway, so... 06:33:39 er. The hardware probably generates the remainder in the process of computing the quotient, I mean. 06:36:42 what does C do? 06:36:50 I want fovium to be consistant 06:37:22 the comments in gforth-cvs seem to assume that C division is always symmetric. 06:37:32 dunno if that's mandated by any C standard though. 06:38:54 ok 06:39:21 well hopefully when I get around to making automated testing, I'll test that "-1 2 / 06:39:26 gives me 0 06:39:37 oh, I take that back. c99 says "truncation towards zero" 06:40:01 sounds good 06:40:17 so long as dividing by two gets the number closer to zero 06:40:30 ya 06:41:57 --- quit: ecraven ("bbl") 06:57:47 ok, I added this to my sqrt.fs example: : /-test -1 2 / abort" This implementation of SQRT requires that dividing by two makes all numbers closer to zero. Try replacing the '2 /' in sqrt-closer with 'S>D 2 SM/REM NIP'" ; /-test 07:06:16 --- join: Crest (n=crest@84.137.73.74) joined #forth 07:13:47 --- join: madwork (n=foo@204.138.110.15) joined #forth 07:42:51 --- join: iano (n=iosgood@sub26-46.member.dsl-only.net) joined #forth 08:05:26 grr... the force C division option doesn't work with the tests. 08:05:37 --- quit: Quartus (Read error: 60 (Operation timed out)) 08:08:39 --- join: virl (n=virl@chello062178085149.1.12.vie.surfer.at) joined #forth 08:08:39 --- mode: ChanServ set +b *!*virl@*.vie.surfer.at 08:08:39 --- part: virl left #forth 08:09:25 ooh. Quartus banned virl? I missed that... 08:09:58 With the final advisory "Here, I'll make this simple for you", if my memory serves. 08:15:20 heh 08:25:42 heh 08:25:46 Indeed. 08:42:42 --- quit: iano () 08:56:10 --- join: ygrek (i=user@gateway/tor/x-30d1f111c632579f) joined #forth 09:01:13 yeah, virl started yelling for no reason 09:01:24 and acting like there was some big argument being fought wrong 09:01:46 but nobody even dissagreed with him. 09:01:53 'twas weird 09:15:16 --- join: Quartus_ (n=Quartus_@209.167.5.1) joined #forth 09:15:16 --- mode: ChanServ set +o Quartus_ 09:50:42 --- join: Shain (i=steve@adsl-75-30-244-32.dsl.pltn13.sbcglobal.net) joined #forth 09:52:14 --- join: ecraven (i=nex@eutyche.swe.uni-linz.ac.at) joined #forth 10:09:00 --- join: Raystm2 (n=NanRay@69.149.54.98) joined #forth 10:12:18 --- quit: ecraven (Remote closed the connection) 10:57:15 --- join: mark4 (n=mark4@70.102.202.162) joined #forth 10:57:20 --- nick: mark4 -> I440r 11:57:40 --- join: arke_ (n=chris@pD9E04FFB.dip.t-dialin.net) joined #forth 12:04:29 --- quit: ygrek () 12:13:18 --- quit: arke (Read error: 110 (Connection timed out)) 12:13:54 --- nick: arke_ -> arke 12:13:54 --- mode: ChanServ set +o arke 12:33:13 --- join: mark4_ (n=mark4@70.102.202.162) joined #forth 12:46:24 --- quit: I440r (Read error: 110 (Connection timed out)) 13:04:44 argh. the gforth build system is just sloppy. 13:05:00 hey tathi 13:06:10 hi slava 13:12:02 --- quit: timlarson (Read error: 104 (Connection reset by peer)) 13:12:14 --- join: timlarson__ (n=timlarso@user-12l325b.cable.mindspring.com) joined #forth 13:20:42 how goes factor? 13:22:07 released 0.88 last night. starting working on 0.89 13:22:38 right now i'm redoing how C types are defined in the ffi 13:23:09 ah 13:24:57 what was wrong with the old way? 13:25:03 good question. 13:25:21 when you're loading a factor source file, C types had to be known at parse time 13:25:22 :) 13:25:34 because of how the struct defining words worked 13:25:48 if you define a struct that refers to some C type, it had to know the sizes of the fields ahead of time 13:25:57 so that it could define words which read/write these offsets 13:26:16 this created a bootstrapping problem 13:26:43 when making a new boot image, the bootstrapper had to populate all the C types 13:26:51 this was weird, the image generator shouldn't have to know about how the FFI works 13:27:09 because it parses everything into one big quotation for the bootstrap image? 13:27:12 or something like that? 13:27:12 now, the C type sizes and field offsets and such are only calculated at the last moment. 13:27:14 tathi: yeah 13:27:33 so now the code that generates C types can be parsed into this big boot quotation, just like everything else. 13:27:42 gotcha 13:28:43 i've been gradually untangling some bootstrap issues. this is the last major one 13:30:03 cool 13:36:38 --- join: mark4__ (n=mark4@70.102.202.162) joined #forth 13:38:15 gah. who writes these Makefiles? 13:38:32 C programmers 13:40:59 so much stupid stuff in here. 13:41:20 I can understand adding a new file and then forgetting to add it to the sources list which is way at the other end of the file. 13:41:54 but checking for the existence of an install directory and then immediately installing the files in a different one is just stupid. 13:50:17 --- quit: mark4_ (Connection timed out) 13:54:31 --- join: mark4_ (n=mark4@70.102.202.162) joined #forth 14:00:13 lol 14:00:25 tathi thats nutz 14:00:28 --- nick: mark4_ -> I440r 14:06:54 huh. looks like I only actually made three or four changes. 14:06:58 seemed like a lot more than that. 14:09:59 --- quit: mark4__ (Read error: 110 (Connection timed out)) 14:14:47 --- quit: tathi ("bbl") 14:22:20 --- quit: arke ("Konversation terminated!") 14:46:18 --- join: arke (n=chris@pD9E04FFB.dip.t-dialin.net) joined #forth 14:46:18 --- mode: ChanServ set +o arke 14:47:13 --- join: iano (n=iosgood@gw-pdx.extensis.com) joined #forth 14:53:22 good evening 14:54:21 hey crc, iano 14:55:00 --- quit: arke ("Konversation terminated!") 14:56:08 --- join: arke (n=chris@pD9E04FFB.dip.t-dialin.net) joined #forth 14:56:09 --- mode: ChanServ set +o arke 15:04:26 --- join: edrx (n=Eduardo@200.217.105.11) joined #forth 15:22:09 hi ho 16:04:57 --- join: mark4_ (n=mark4@70.102.202.162) joined #forth 16:08:09 --- quit: I440r (Read error: 60 (Operation timed out)) 16:34:03 --- quit: arke ("Konversation terminated!") 17:13:45 --- quit: gnomon (Read error: 110 (Connection timed out)) 17:20:21 --- join: Snoopy_1711 (n=snoopy_1@dslb-084-058-156-103.pools.arcor-ip.net) joined #forth 17:36:48 --- quit: Snoopy42 (Read error: 110 (Connection timed out)) 17:37:07 --- nick: Snoopy_1711 -> Snoopy42 18:03:24 --- quit: iano () 18:05:35 --- join: Quartus (n=neal@CPE0001023f6e4f-CM013349902843.cpe.net.cable.rogers.com) joined #forth 18:05:35 --- mode: ChanServ set +o Quartus 18:15:24 hey 18:42:07 --- mode: Quartus set -b *!*virl@*.vie.surfer.at 19:11:11 --- quit: edrx (Read error: 60 (Operation timed out)) 19:21:34 --- join: edrx (n=Eduardo@201.5.12.175) joined #forth 19:37:27 Any life out there? 19:38:24 I'm here 19:38:33 What's up? 19:39:11 a bit earlier me and zpg were discussing bidirectional bridges between emacs and forth-like languages in #eev 19:40:10 eevil! 19:41:50 yeah 19:42:12 I thought emacs was pretty well in bed with emacs lisp 19:46:49 well, I've been trying to use it as a universal interface 19:48:45 http://angg.twu.net/eev-article.html 19:49:34 I'm the wrong guy to sell it to; I find emacs a clumsy interface. 20:01:43 I'm not going to try to sell it to you, don't worry :) 20:02:03 I prefer simple editors. 20:02:20 forth-based? 20:02:34 If you mean block editors, I've never used one. 20:02:37 I wouldn't be able to use something that weren't totally programmable 20:02:49 I use joe quite often. 20:02:55 hmmm 20:05:37 It's considerably programmable, but I only ever added a feature once. 20:06:45 Personally I consider what is being edited to be appreciably more important than the tool used to edit it. 20:10:06 ok 20:10:43 now you're trying to sell me the idea of using a text editor instead of emacs :) 20:11:42 Nope. 20:14:23 sorry, I'm distracted with something else - I'm trying to learn a certain parsing library for Lua that will probably be very useful to several of my projects - incluiding the Lua-based Forth-like languages (esp. for connecting them to emacs) 20:22:42 What projects? 20:30:04 one of them is this: http://angg.twu.net/blogme.html - but I'm rewriting its docs (and its code) that it clearer that it is a programming language built on top of lua, not just an html generator 20:30:24 s/that it clearer/to make it clearer/ 20:31:19 I see. 20:37:31 --- join: gnomon (n=gnomon@CPE0050eb372bdb-CM001692f57b56.cpe.net.cable.rogers.com) joined #forth 20:56:39 --- quit: mark4_ (Success) 22:04:18 --- quit: Quartus_ ("used jmIrc") 22:34:18 --- join: nighty^ (n=nighty@211.154.202.98) joined #forth 22:35:19 lo 22:36:36 hi 22:51:13 lo/ 22:51:18 | 23:02:05 \ 23:31:48 _ 23:31:59 Timber! 23:36:46 In this weather, that's about right. I'm glad that there aren't any large trees nearby. 23:59:59 --- log: ended forth/07.03.01