00:00:00 --- log: started forth/08.07.21 00:16:33 --- join: ygrek (i=user@gateway/tor/x-596af545e443eb01) joined #forth 00:25:00 --- quit: JasonWoof ("leaving") 01:06:46 --- quit: probonono (Read error: 104 (Connection reset by peer)) 01:08:09 --- join: probonono (n=User@ppp103-111.static.internode.on.net) joined #forth 01:35:24 --- join: qFox (i=C00K13S@234pc222.sshunet.nl) joined #forth 01:48:34 --- quit: ygrek (Remote closed the connection) 02:03:20 --- quit: modesto (Remote closed the connection) 02:03:31 --- join: modesto (n=geoperry@microwave.catch22.com) joined #forth 02:12:23 --- join: ygrek (i=user@gateway/tor/x-1511f40fef4bfd4c) joined #forth 02:57:13 --- quit: segher ("Leaving") 03:43:47 --- quit: qFox ("Time for cookies!") 03:45:33 --- join: qFox (i=C00K13S@234pc222.sshunet.nl) joined #forth 04:17:54 --- quit: ASau` (Read error: 110 (Connection timed out)) 05:04:41 --- quit: X-Scale (Network is unreachable) 05:34:40 --- join: Raystm2 (i=Ray@unaffiliated/raystm2) joined #forth 05:50:54 --- join: X-Scale (i=email@2002:59b5:4610:6:44fc:ece4:401b:c103) joined #forth 06:39:55 --- join: segher (n=segher@84-105-61-45.cable.quicknet.nl) joined #forth 06:49:06 --- join: craigoz (n=craigo@202.63.56.72) joined #forth 07:05:23 --- quit: ASau (Read error: 104 (Connection reset by peer)) 07:21:58 --- join: ASau (n=user@84.253.85.38) joined #forth 07:36:12 --- quit: ygrek (Remote closed the connection) 07:37:06 --- join: vixey (n=vicky@amcant.demon.co.uk) joined #forth 07:37:34 what is a good forth implementation that doesn't crash all the time? 07:37:42 --- quit: malyn ("Disconnecting from stoned server.") 07:38:13 is gforth one of the best? 07:38:17 vixey: there's none. 07:38:30 ASau: what do you mean? 07:38:37 I can recall several ways to crash gforth. 07:38:50 yeah obviously I didn't mean that 07:38:54 I mean the simple truth: Forth is unforgiving. 07:40:49 --- join: malyn_ (n=malyn@unaffiliated/malyn) joined #forth 07:41:17 heh 07:41:43 Say I want to write a forth interpreter for fun. Is it reasonable to write it entirely in C, without any assembly? 07:41:48 --- nick: malyn_ -> malyn 07:42:14 --- quit: probonono (Read error: 110 (Connection timed out)) 07:42:22 It isn't reasonable to write yet another Forth at all. 07:42:54 As for writing it in C... 07:43:06 Well... There are several such implementations. 07:45:53 ASau: OK cool, Thanks. t would be strictly personal, for learning. 07:46:00 *It 07:46:15 Currently I'm playing with frugal and gforth. 07:47:14 It would be more useful, if you tried to improve existing implementations. 07:47:31 why write a program in C for learning forth ? 07:47:47 I think you could write a program in forth to learn forth 07:48:38 --- join: probonono (n=User@ppp103-111.static.internode.on.net) joined #forth 07:51:01 vixey: To learn C would be why I would write the interpreter. 07:51:08 kspaans: implementing Forth in Forth isn't trivial either. 07:51:34 oh don't learn C 07:51:39 haha 07:51:42 :P 07:51:57 vixey: What, then, would you suggest as a replacement? 07:52:12 * vixey is learning forth 07:52:19 why don't you as well? :) 07:52:26 kspaans: try implementing Forth in Forth. 07:52:41 vixey: Yes, I would certainly need to learn Forth first. 07:53:11 ASau: Yes, that would be another fun learning experience too. 07:53:28 That will be better experience. 07:53:55 Really, I'm trying to learn C though, so I should rephrase my question. 07:54:14 what sort of evil thing has caused you to want to learn C? 07:54:16 'Cause this kind of wheel is reinvented less frequently. 07:54:17 Is it resonable to write a Forth interpreter in $LANGUAGE without using assembly? 07:54:22 vixey: the Linux kernel. 07:54:37 ASau: I see your point. 07:54:39 Yes, it is reasonable. 07:55:12 ASau: Perfect thanks, I shouldn't have brought up 'C', it's orthogonal to the point of my question. 07:55:18 vixey: so what are you doing to learn Forth? 07:55:34 reading sokoban.fs at the moment 07:58:40 ASau: So which Forth implementations would you suggest lending a hand to, as you suggested earlier? (I'm just curious.) 07:59:14 As a tool, gforth. 07:59:29 As something to improve, FICL or PFE, whatever you like. 07:59:40 As something to learn internals... 07:59:48 Well... 07:59:52 That's harder. 08:00:19 I'd recommend FIG or eForth, but they're outdated. 08:02:04 And it's true that ANSI Forth is disliked? 08:02:18 And what's this colorForth thing? 08:02:22 Well... 08:02:27 That's not true. 08:02:31 OK 08:02:50 herecy on 08:02:55 That was long time ago. 08:03:19 ANS come, when there were many other implementations, which were different. 08:04:32 ANS tried to solve incompatibilities, when Forth started to die out. 08:04:37 herecy off 08:04:41 Kinda that. 08:04:54 I see, interesting. 08:05:19 You can meet other opinions, my opinion isn't popular. 08:06:14 I'll certainly wait around for them. 08:07:16 Hardly you'll hear opinions except "try colorForth/retroForth" or "stick to ANS." 08:08:05 That war is over. 08:08:19 Heh. 08:08:58 Except Horst's lina/wina, Childer's retroForth, and Moore's colorForth, there're no other deviations around. 08:10:04 Ah, there's Doty's STOIC derivative. 08:11:17 Of all above, I know that only retroForth and colorForth have relativly strong communities. 08:11:39 Yet I may mistake. 08:13:03 --- join: ygrek (i=user@gateway/tor/x-e0bbaa8e730a6c12) joined #forth 08:13:36 Hmm, I'm just interested in plain Forth, for it's own sake. I already know a lispy language (Scheme), and I'm working towards an imperatives, Forth seems to be one of the few other paradigms (apart from Prolog). 08:13:58 There's no "plain" Forth. 08:14:12 Though it would be cool to know enough to use the OpenFirmware environment on my Mactop to write programs. 08:14:25 ASau: Of course, my mistake. 08:14:38 I strongly suggest learning to do something practical in Forth. 08:14:46 Or in Scheme, if you know it. 08:15:07 Good evening, ygrek. 08:15:35 --- quit: probonono (Read error: 104 (Connection reset by peer)) 08:15:42 --- join: luptenschteiner (n=User@ppp103-111.static.internode.on.net) joined #forth 08:16:00 kspaans: nothing does better to any language, than applications. 08:16:05 ASau: Oh, certainly, I have other side projects for that. But someone told me it would be good practice to write and understand a Forth interpreter. 08:16:44 You can get gforth or macforth for you OS X machine, kspaans. 08:17:13 kspaans: don't believe him. 08:17:26 You should probably write *in* forth first before you write *a* forth. 08:17:27 TreyB: Certainly, but that's not nearly as cool. ;) Practicality isn't what I'm striving for just yet. 08:17:36 TreyB: Yes, good point. 08:18:02 kspaans: it is generally better to be practical. 08:18:51 ASau: Certainly, but I don't "know" very much. So I'm trying to expand on what I know by pursuing both practical and 'academic' routes. 08:19:02 I do recommend trying to write a forth if you have an interest in compilation in general. So much of the parsing baggage required for other languages just doesn't exist for forth. 08:19:33 TreyB: Exactly why I'm interested in Forth - I've recently completed an introductory compilers course at my university. 08:19:36 kspaans: if you want to be "academic", better learn data structures. 08:19:53 Try implementing binary trees in Forth, it's amazing. 08:19:59 ASau: That can be done in school. I'm doing this on my own time. 08:20:12 And that's even more complex than writing yet another forth. 08:20:21 That does sound fun. I should stop jabbering and just go and learn Forth first. :) 08:20:43 Writing Forth is boring. 08:21:04 It is mostly routine manual task. 08:21:13 kspaans: I am also reading this http://thinking-forth.sourceforge.net/ 08:45:28 --- join: JasonWoof (n=jason@c-65-96-161-30.hsd1.ma.comcast.net) joined #forth 08:45:28 --- mode: ChanServ set +o JasonWoof 08:45:56 Good evening, Herkamire. 08:47:26 hello 09:05:51 --- quit: vixey ("* I'm too lame to read BitchX.doc *") 09:52:33 --- join: Maki_ (n=Maki@adsl-224-84.eunet.yu) joined #forth 10:05:23 --- join: forther (n=forther@c-24-5-187-203.hsd1.ca.comcast.net) joined #forth 10:05:36 --- quit: forther (Remote closed the connection) 10:10:14 --- join: _mathrick (n=mathrick@users177.kollegienet.dk) joined #forth 10:18:56 --- join: __mathrick (n=mathrick@users177.kollegienet.dk) joined #forth 10:19:37 --- quit: mathrick (Read error: 104 (Connection reset by peer)) 10:19:44 --- nick: __mathrick -> mathrick 10:35:31 --- quit: _mathrick (Read error: 110 (Connection timed out)) 11:00:12 --- part: X-Scale left #forth 11:03:10 --- join: ASau` (n=user@79.111.17.100) joined #forth 11:08:00 --- quit: Raystm2 ("Should have paid the bill.") 11:16:30 --- quit: ecraven ("bbl") 11:34:18 --- join: Raystm2 (i=Ray@unaffiliated/raystm2) joined #forth 11:52:27 --- join: ecraven (n=nex@plc31-103.linzag.net) joined #forth 11:54:36 --- join: vixey (n=vicky@amcant.demon.co.uk) joined #forth 12:23:17 --- join: Quartus` (n=Quartus`@205.205.50.2) joined #forth 12:42:02 --- join: Quartus__ (n=Quartus`@205.205.50.2) joined #forth 12:42:46 Hi. 13:01:15 Hi. 13:01:15 --- quit: Quartus` (Read error: 104 (Connection reset by peer)) 13:12:14 --- quit: ygrek (Remote closed the connection) 13:18:09 --- join: tathi (n=josh@pdpc/supporter/bronze/tathi) joined #forth 13:18:09 --- mode: ChanServ set +o tathi 13:18:18 hi tathi 13:18:27 hey Quartus__ 13:29:08 kspaans: a lot of people seemed to like jonesforth... http://www.annexia.org/forth 13:29:18 I didn't like it, myself. 13:29:49 Why is that, tathi? Because it implements completely obsolete Forth techniques, or for some other reason? 13:30:02 I totally disagree with the premise that understanding a Forth implementation is helpful in becoming a good Forth programmer. 13:30:12 And yeah, the archaic implementation. 13:30:33 And AFAICT his definition of direct/indirect threading is just plain wrong. 13:31:30 I'd love to see someone do something like that, but in Forth, and emphasize the model (dictionary, two stacks, etc.), and push the back-end details off to an appendix. 13:33:16 Forth is certainly based on a fairly concrete virtual machine model, and I do think you need to have a basic understanding of that. 13:35:23 We had a newbie in here one time; I think he was trying to understand the definition for a basic array, with *no* understanding of how the heap worked at all. 13:35:33 He was trying to modify the code to do something else in the most bizarre ways. 13:35:52 I never did figure out how he thought it worked... 13:37:04 But somebody eventually realized what he was missing, and explained about HERE and ALLOT etc., and then he was fine. :) 14:24:03 --- join: aguai (n=aguai@118-160-19-118.dynamic.hinet.net) joined #forth 14:25:28 I am learning forth 14:25:44 this is amazing 14:59:59 --- quit: ecraven ("bbl") 15:09:44 --- quit: Maki_ ("Leaving") 15:25:22 --- quit: qFox ("Time for cookies!") 16:07:38 --- quit: cmeme ("Client terminated by server") 16:08:12 --- join: cmeme (n=cmeme@216.184.11.2) joined #forth 16:47:07 --- join: nighty^ (n=nighty@210.188.173.246) joined #forth 16:47:54 --- quit: vixey ("* I'm too lame to read BitchX.doc *") 16:58:20 funny how hard it can be to convince someone of how simple HERE and ALLOT are 16:58:39 heh :-) 16:58:47 well, you can make ALLOT quite complex 16:58:53 JasonWoof: i don't see how someone could claim they're not simple 16:58:58 ALLOT just bumps a pointer... 16:59:19 some ALLOTs clear the allotted space, if positive size 16:59:28 and often they check for overflow 16:59:37 that's still pretty simple to me 16:59:41 compared to malloc() especially 16:59:50 and some of them move the most recently parsed name up ;-) 17:00:04 segher: never heard of any of that crap 17:00:15 F83 17:00:23 and/or FIG 17:00:28 weird 17:00:53 usually it's because people are convinced it's some kind of dynamic memory allocator 17:01:07 dynamic memory allocation can be simple too -- bump a pointer 17:01:11 or they don't understand memory addressing, and are thinking in terms of arrays/objects 17:01:13 yeah :-) 17:01:15 deallocation is where the complexity lies :) 17:01:39 : alloc-mem ( size -- ptr iof ) here swap allot 0 ; 17:01:55 nah :-) 17:01:57 JasonWoof: many garbage collected languages allocate arrays/tuples by bumping the allocation pointer, then the gc removes unused objects and packs the data down to fill holes 17:02:08 : free-mem ( ptr size -- iof ) 2drop 0 ; 17:02:19 JasonWoof: so in that respect allot/here is a lot more familiar to implementors of high level lnaguages than malloc and friends 17:02:53 slava: I don't think the clueless newbies we gete here are implementers of any kind of language 17:02:59 yup 17:03:02 i actually used that alloc-mem / free-mem in an OF implementation for _months_ before people started to complain 17:03:11 implementers of languages understand memory addressing 17:03:26 segher: heh 17:03:37 it would only eat, what, 8MB or so 17:04:30 segher: would it hold onto that 8MB after booting the OS? 17:04:44 nah, linux on powerpc shoots down OF first thing 17:05:02 wouldn't matter anyway, 0.1% is rubbish 17:05:03 oh, shouldn't be a problem then 17:05:33 linux runs fine on my old laptop with 128MB of RAM 17:05:48 well, sure. i still run an 8MB box 17:05:50 was using it as my primary computer earlier this year 17:05:58 heh :-) 17:06:16 I'd be annoyed if something was holding onto 8MB of ram all the time unnessesarily 17:06:46 yeah, sure. but this was a 64-bit only thing, 2GB is absolute minimum 17:07:08 oh wait, you caould actually plug in only 512MB on the really old ones 17:07:14 you have 8GB of ram? 17:07:18 yeah 17:07:21 why? 17:07:28 that was a lab machine 17:07:35 i was writing the OF< remember 17:07:50 why were you writing OF? 17:08:02 because it wasn't free at the time 17:08:07 and we needed one 17:08:29 didn't come with one? 17:08:34 you get an IBM ppc? 17:08:35 new machine 17:08:45 i worked for IBm then, yes 17:08:49 ahh 17:08:50 cool 17:08:57 970 blades, cell blades 17:08:59 'splains everything 17:09:06 "SLOF", you might have heard of it 17:09:17 nah 17:09:20 not my area 17:09:27 it was *extremely* useful to have a minimal OF for hardware bringup 17:09:32 don't blame you for the allocator thing 17:09:46 I've never bothered writing a dynamic allocator 17:09:50 i just didn't bother implementing a proper allocator until it was really needed, heh 17:10:07 and even then, i just did a buddy allocator 17:10:30 simple == good 17:10:36 yep 17:10:48 well, i don't have to tell that _here_ i'm sure 17:11:13 no sense in being all fancy when you've got way more memory than you can possibly use, and your not likely to run long before memory is wiped 17:13:00 I'm finding little in common between what we have and what I want to eat. bbl 17:14:16 well, one nice feature was that it could run without any memory, all in L2 cache. and that was 1MB 17:14:30 it got stuck when loading linux though. pity ;-P 17:15:00 nice! 17:15:05 never thought of runing in the cache 17:15:06 cool stuff 17:15:17 it seems to be very hard to do with x86 17:15:25 x86 is crap 17:15:34 like, on opteron you can only safely use 48kB, and even then you need lots of setup 17:15:54 on powerpc, i just allocate cache lines for the 1MB i want, and be sure never to touch anything else 17:16:03 oh, and don't do device dma :-) 17:16:07 I know that a really small program can run much faster, if everything it needs is in the cache 17:16:15 but I didn't realize it was possible to run without memory 17:16:17 cool stuff 17:16:21 ok, really out the door now 17:16:48 dram isn't your main memory. L2/L3 cache is; the dram is just swap space 17:16:51 ciao 17:44:27 I read or listened to someone (possibly jeff fox) talking about timing 17:44:41 registers, cache, memory, disk 17:44:53 from each to the next one down is something like 1000x slower? 17:44:56 or was it 100x? 17:45:28 very fuzy memory 17:46:36 very fuzy 17:46:39 could be 10x for all I know 17:48:01 I'm just glad I'm not using disk for swapspace so much any more 17:48:24 so much better to be using ram to cache disk than the other way around 17:52:59 --- quit: craigoz ("Leaving.") 18:05:54 reg is 1 or 2 cycles 18:06:03 L1 is 3-6 cycles, or 8 if you get an intel 18:06:06 --- join: madgarden (n=madgarde@CPE001d7e527f89-CM00159a65a870.cpe.net.cable.rogers.com) joined #forth 18:06:11 L2 is 11-25 cycles 18:06:19 L3 is ~50 cycles 18:06:36 dram is 600-6000 cycles 18:07:04 this all for "desktop"/"server" class cpus 18:07:22 embedded is much nicer 18:09:03 there are other important differences, like prefetch and eviction strategies, and how the cache hierarchies are actually connected 18:10:18 and to top it all off, what is "good" depends on your workload. have fun :-) 18:11:35 oh, and of course, this is latencies. there is bandwidth, too 18:12:14 solving bandwidth problems is trivial though, unless your system is HUGE 18:12:22 just costs money :-) 18:14:46 --- quit: aguai (Remote closed the connection) 18:14:50 --- join: aguai (n=aguai@118-160-19-118.dynamic.hinet.net) joined #forth 18:21:03 --- quit: madgarden ("?OUT OF DATA ERROR") 18:21:55 --- join: madgarden (n=madgarde@CPE001d7e527f89-CM00159a65a870.cpe.net.cable.rogers.com) joined #forth 18:39:24 --- quit: aguai (Remote closed the connection) 18:41:58 --- quit: tathi ("leaving") 18:44:38 --- join: aguai (n=aguai@118-160-19-118.dynamic.hinet.net) joined #forth 18:56:08 --- join: aguai_ (n=aguai@118-160-17-236.dynamic.hinet.net) joined #forth 18:56:44 --- quit: aguai (Read error: 104 (Connection reset by peer)) 18:56:45 --- quit: aguai_ (Read error: 104 (Connection reset by peer)) 19:01:46 --- join: aguai (n=aguai@118-160-19-118.dynamic.hinet.net) joined #forth 20:04:19 --- quit: Quartus__ (Read error: 104 (Connection reset by peer)) 20:21:29 --- quit: madgarden ("?OUT OF DATA ERROR") 20:25:43 --- join: madgarden (n=madgarde@CPE001d7e527f89-CM00159a65a870.cpe.net.cable.rogers.com) joined #forth 22:01:41 --- quit: proteusguy (Read error: 110 (Connection timed out)) 22:03:06 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 22:33:54 --- quit: cmeme ("Client terminated by server") 22:34:28 --- join: cmeme (n=cmeme@boa.b9.com) joined #forth 23:47:02 --- join: ecraven (n=nex@140.78.42.115) joined #forth 23:59:59 --- log: ended forth/08.07.21