00:00:00 --- log: started forth/08.11.16 00:26:55 --- join: aspect (i=aspect@burns.dreamhost.com) joined #forth 00:32:19 --- quit: JasonWoof ("off to bed") 01:02:54 --- join: ygrek (i=user@gateway/tor/x-a9b7e3bca032350a) joined #forth 01:04:12 --- part: aspect left #forth 01:22:52 --- quit: ecraven ("bbl") 01:42:13 --- join: jewel (n=jewel@41.247.196.192) joined #forth 03:39:26 --- join: qFox (i=C00K13S@132pc222.sshunet.nl) joined #forth 04:09:20 --- quit: ASau (Remote closed the connection) 04:09:37 --- join: ASau (n=user@193.138.70.52) joined #forth 04:23:17 --- quit: proteusguy (Read error: 60 (Operation timed out)) 04:39:13 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 05:18:36 --- quit: proteusguy (Read error: 60 (Operation timed out)) 05:31:39 --- join: neceve (n=ncv@unaffiliated/neceve) joined #forth 05:34:43 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 05:36:27 --- join: Discordian (n=clive@chills.demon.co.uk) joined #forth 05:52:13 --- quit: TreyB (Read error: 60 (Operation timed out)) 05:53:34 --- quit: Discordian (Remote closed the connection) 06:12:24 --- join: TreyB (n=trey@74.203.168.157) joined #forth 06:22:33 --- quit: proteusguy (Read error: 60 (Operation timed out)) 06:37:52 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 07:07:40 --- quit: proteusguy (Read error: 113 (No route to host)) 07:49:49 --- join: edrx (i=edrx@189.25.151.216) joined #forth 07:57:03 --- quit: Al2O3 (Remote closed the connection) 07:59:57 howdy folks 08:01:20 hi 08:01:28 hi slava 08:01:48 how's it going? 08:01:59 pretty good 08:14:03 --- part: edrx left #forth 08:20:32 --- quit: neceve (Read error: 104 (Connection reset by peer)) 08:36:32 --- quit: lukeparrish (Nick collision from services.) 08:37:53 --- join: lukeparrish (n=opera@74-36-0-167.dr01.hmdl.id.frontiernet.net) joined #forth 09:29:27 --- join: neceve (n=ncv@dyn-89.136.41.150.tm.upcnet.ro) joined #forth 09:56:39 --- quit: jewel (Read error: 113 (No route to host)) 10:11:25 --- join: JasonWoof (n=jason@c-66-31-44-71.hsd1.ma.comcast.net) joined #forth 10:11:25 --- mode: ChanServ set +o JasonWoof 10:12:58 --- join: forther (n=forther@c-24-5-187-203.hsd1.ca.comcast.net) joined #forth 10:13:35 hi 10:13:53 howdy 10:15:06 --- quit: TreyB (Read error: 60 (Operation timed out)) 10:24:03 I'm having a subtle portability issue in retroforth... It uses a Forth called Toka to create an image of a Forth (written in Forth) that execures under Ngaro (a forth-like minimalistic VM)... Somewhere along the way, the instructions put into the retroTmage file are being corrupted when this is attempted under Windows. 10:24:59 http://retroforth.com/paste/?id=546 is a side-by-side of javascript arrays based on the images. 10:27:15 any ideas what sort of problem this is? 10:40:22 lukeparrish: you're same code works on linux? 10:42:04 lukeparrish: /join #retro and ask there? 10:42:05 well, I don't actually have a copy of linux at present to test it with... 10:42:19 lukeparrish: or wait until the author comes? 10:42:31 already am there. crc doesn't have net access at home any more :( 10:42:39 ??? 10:42:43 What has happened??? 10:42:48 not sure 10:43:10 he still answers questions during weekdays, but I'm not usually on during weekdays 10:44:42 anyway, I talked to him about it and he isn't sure yet what causes the problem. 10:46:23 the retroImage code distributed with the binaries works fine. I just want to be able to make modifications on Windows to get a better understanding of how it fits together. 10:48:16 --- join: tathi (n=josh@dsl-216-227-90-175.fairpoint.net) joined #forth 10:48:16 --- mode: ChanServ set +o tathi 10:56:28 --- join: TreyB (n=trey@74.203.168.157) joined #forth 11:06:19 --- quit: TreyB (Read error: 113 (No route to host)) 11:07:34 --- join: TreyB (n=trey@74.203.168.157) joined #forth 11:08:23 --- join: jewel (n=jewel@dsl-242-143-03.telkomadsl.co.za) joined #forth 11:24:51 --- join: TreyB_ (n=trey@74.203.168.157) joined #forth 11:29:04 --- quit: TreyB (Read error: 113 (No route to host)) 11:53:34 --- join: charlie_turner (n=cht@host86-136-158-179.range86-136.btcentralplus.com) joined #forth 11:58:22 how many people here have brewed their own forth system? 11:58:39 probably everyone but me, right? :) 11:59:15 how many people here have created over five Forth systems, though? over ten? :-P 11:59:29 :P 11:59:59 gets to be a habit, eh? 12:00:35 nah, it's just so easy to do 12:01:14 what are the essential elements? 12:01:29 stack, dictionary, interpreter loop 12:03:35 now I gotta try it 12:03:51 since I have dev-c++ installed and working 12:04:12 stack, user area, code space, data space, a few primitives 12:04:37 interpreter and dictionary can reside on the host, certainly for early development 12:11:58 It's just so easy to do crappy forth. 12:12:22 Making it performing anything useful is way harder. 12:13:04 what's the trick? 12:13:24 There's no trick, it is very much work. 12:13:30 Both in designing and in coding. 12:13:54 asau: it depends what your goals are, eh 12:14:21 Like in "The war isn't a fireworks, it's just much of hard work." 12:14:28 segher: sure. 12:14:48 --- quit: forther ("Leaving") 12:14:57 but it's certainly a _lot_ of work to make a good Forth (or a good _anything_, for that matter), no matter what axis of "good" you're after 12:15:02 If you want any amusement, you can find any stupid way to do. 12:16:29 I know two communities, which suffer much from easy interpreter disease. 12:16:32 :) 12:16:39 They are Forth and Scheme. 12:17:30 that's not a disease. the disease is that people think their toy systems are any good :-) 12:18:03 It is a disease still. 12:18:05 heh 12:18:21 Too much efforts go into implementing yet another toy system, 12:18:22 so that's what it is... I knew they had *something* in common 12:18:37 instead of improving one or two good ones. 12:18:38 hmm 12:19:15 For instance, look at Common Lisp community. 12:19:16 is it too much effort as in "too much effort goes into collecting stamps" or "too much effort goes into model airplanes"? :P 12:19:31 They have multiple implementations too, 12:19:49 but they produce enough of good reusable code. 12:21:57 so is staying so close to the metal harmful for the language community because experimentation at that close of range prevents compatibility? 12:27:05 It's not about hardware. 12:27:14 It's about primitivity. 12:27:57 with Forth, you often _want_ to rewrite stuff so it's better tuned to your needs 12:28:00 To write Forth you don't need any knowledge about syntactic analysis, 12:28:05 or code generation. 12:28:21 Or any other compiler-related stuff. 12:28:42 You just need to know several tricks to write anything that kind of "works." 12:29:00 There sits the problem: 12:29:26 all those grammars & co are there to allow writing complex things. 12:29:38 Take a look at SML. 12:29:47 that's the same with all languages, really. most people who "write C" don't know C; most people who "write Perl" don't know Perl; most people who "write Java" don't know Java, ... 12:30:00 Sure. 12:30:13 You don't need to know what it does under the hood. 12:30:35 You have to know common way it works, what it does as a result. 12:30:44 but you need to know the exact interface; the exact way you are supposed to use something 12:30:57 If the language isn't tricky (not like C), that is enough. 12:31:07 No, you don't need to know that. 12:31:12 and _not_ just the "common case", but the _exact_ guarantees and constraints 12:31:33 if not, you're not programming, but running with scissors 12:31:50 If you are provided powerful abstractions, you can go better, than given weak abstractions. 12:32:16 well, sure, if there are fewer pitfalls, you can fall in fewer pits. you still can fall into pits though. 12:32:34 Sure. 12:32:53 But those pits may be at way higher level. 12:33:05 Consider writing symbolic math. program. 12:33:28 In Lisp it is way easier, than in Forth. 12:33:33 yeah, and i know how often people get _that_ wrong (like, 90% of the time or so!) 12:33:49 Sure. 12:33:51 oh, i thought you meant like in maple or mathematica 12:34:00 Well... 12:34:18 Take symbolic differentiation for example. 12:34:29 No simplifying. 12:34:43 on what, polys? 12:34:45 The algorithm is pretty straightforward, isn't it? 12:35:12 Take general functions, like trigs and exponentials. 12:35:47 let's assume you said "some basic combinations of some basic functions", or even a bit vaguer ;-) 12:35:57 i think i know what you're talking about now. continue :-) 12:36:30 Given any Lisp you can find a pit to fall, sure. 12:37:11 But given Forth you find more pits, while not reaching any level of symbolic math. 12:37:40 You get not the "mathematically incorrect result", you just don't get it at all. 12:37:52 are we talking ANS compatible forths here? 12:37:55 E.g. sticking into parsing problems or memory handling. 12:37:56 dunno. it's lower level, and not a functional system (although you could build one _in_ Forth, of course) 12:38:12 Of course, I can build one. 12:38:21 But it is much more work. 12:38:31 otoh, i find Forth a lot easier to *test*, which helps 12:38:36 sure 12:38:47 but much more interesting work, as well ;-) 12:38:53 As for controlling hardware, you can do the same with tuned Lisp or Scheme. 12:39:00 Testing... 12:39:13 I don't think that testing is easier in Forth than anywhere else. 12:39:45 Forth interpreter shares those abilities with any other interpreter. 12:40:11 _comprehensive_ testing. it's almost doable in Forth, and pretty nigh impossible in most other systems (and FP systems are about the worst!) 12:41:31 Contrary to your expectations, FPLs are better at testing. 12:42:01 anyway, i wouldn't write most code in Forth. i write most stuff in C these days; and about equal Forth, Perl, Haskell for the rest 12:42:05 Their interpreters provide better support for it: 12:42:15 you can't crash correct interpreter. 12:42:44 it's not just about the interpreters. it's about the language structure, and how you access data as well, etc 12:42:55 You have better control over data structure as well. 12:43:28 In strictly typed FPLs you have more "compile-time" checks, 12:43:39 so? 12:44:33 the more useful (imho) FP languages don't even guarantee order of execution. pretty damn hard to test your code 12:45:22 ?? 12:45:35 Strict FPLs guarantee order of execution. 12:46:01 segher: the most useful are the least reliable? 12:46:36 asau: well, make your conclusions about what i think about strict vs. lazy FP :-P 12:46:39 If you refer to Haskell, that's the main point of it, that it is lazy (non-strict). 12:46:54 Check SML. 12:47:09 i don't like ML 12:47:10 Or Caml. 12:47:33 i *know* it can be useful, but it's just not my taste 12:47:35 "let _ = this; _ = that end" guarantees order of execution. 12:48:09 if i want to dictate order of execution, i'll use an imperative language 12:49:18 You don't need to dictate most of the time. 12:49:49 Anyway, order of execution isn't what matters. 12:49:55 in a lazy FP language you don't need to, correct 12:50:16 It isn't connected with the language. 12:50:32 in a strict FP language you _do_ -- that's what makes it strict! 12:50:35 Even in C you don't need to know the order or parameter evaluation. 12:50:43 Not always. 12:50:48 sure you do (modulo sequence points) 12:50:55 Not in most cases, unless you're fond of ++ and --. 12:51:51 Still it doesn't matter for testing purposes that much. 12:51:53 oh, you mean you don't care in most cases? but you always have to check if you care or not! 12:52:37 In typed FPLs you are just warned about dangerous cases. 12:52:38 i think we actually agree on most of this, anyway. we just look at it from a different angle 12:53:33 In CL you mostly know what is dangerous, since it is of distinctive style. 12:53:40 --- join: TreyB (n=trey@74.203.168.157) joined #forth 12:53:47 Also applies to Scheme. 12:54:06 well, in a strictly functional language there can not _be_ cases where order actually matters (other than time and space complexity). of course, strictly functional languages are nice toys, but not all that useful :-) 12:54:22 Forth has fundamental drawback in that it doesn't give you interpreter protection. 12:54:37 what do you mean, "interpreter protection"? 12:55:46 It means, that when you miss stack order or forget your 12:55:46 calling conventions ("stack effect"), you store value to random 12:55:46 address and thus corrupt the whole interpreter. 12:56:18 After the last has happened all your testing stops at all, 12:56:28 even when it could continue at some point. 12:57:24 plenty of Forth systems have the interpreter safe from the program 12:57:36 like, all systems where your host runs on a separate machine 12:57:49 For instance, this corruption could happen in boundary case. 12:58:07 Now you have tested that in boundary case your word fails, 12:58:17 so you reset the target, which takes what, five seconds? and testing continues 12:58:20 and unsure if it works in usual cases. 12:58:28 Some times it isn't 5 sec. 12:58:35 --- quit: TreyB_ (Read error: 113 (No route to host)) 12:58:57 sure, get a better testing environment if you don't have one yet :-P 12:59:30 Thus Forth unforgiveningness makes testing longer. 12:59:53 It forces you to buy more expensive or buy more test systems. 13:00:28 Just because it is less assiting in testing. 13:00:31 :) 13:01:00 or you could train yourself to be more careful 13:01:21 Sure, you could. :) 13:01:42 But that switches you from TDD to other approaches. 13:02:07 Like writing correct programs at first place. :) 13:02:35 i find TDD to be utter bullshit\ 13:02:45 so there :-) 13:03:25 i'm more a "Programming Driven Programming" kind of person 13:14:35 --- quit: neceve (Read error: 54 (Connection reset by peer)) 13:21:52 --- join: TreyB_ (n=trey@74.203.168.157) joined #forth 13:33:11 --- quit: TreyB (Read error: 113 (No route to host)) 13:43:06 --- quit: qFox ("Time for cookies!") 14:00:03 --- quit: charlie_turner (Client Quit) 14:02:33 --- quit: jewel (Read error: 113 (No route to host)) 14:07:57 --- quit: ygrek (Remote closed the connection) 14:14:39 --- join: iano (n=iosgood@076-076-146-052.pdx.net) joined #forth 15:19:56 --- quit: TreyB_ (Read error: 113 (No route to host)) 15:21:28 --- join: TreyB (n=trey@74.203.168.157) joined #forth 15:29:37 --- quit: TreyB (Read error: 60 (Operation timed out)) 15:30:29 --- join: Rodo12 (i=Bob@v-209-98-172-169.mn.visi.com) joined #forth 15:32:33 --- part: Rodo12 left #forth 15:39:48 --- join: TreyB (n=trey@74.203.168.157) joined #forth 15:57:59 I'm more the don't drive while you're programming type 16:05:37 --- quit: I440r ("Leaving") 16:09:37 jasonwoof: that's good, drinking & programming is an ideal combination, so that fits well 16:09:51 < segher> or you could train yourself to be more careful 16:09:52 lol 16:11:08 slava: that may be funny (and it was meant to be), but i was also trying to make an important point 16:12:47 I don't see how drinking and programming go well together 16:13:16 segher: i guess i missed the point 16:13:19 --- quit: TreyB (Read error: 60 (Operation timed out)) 16:15:05 jasonwoof: it helps inspiration, and motivation. it does decrease typing skills ;-) 16:16:55 drinking can wash away the shameful taste of programming in a less desirable language 16:17:05 slava: my point was that you have to be careful what exactly you are doing _anyway_, and if you _are_ careful, your testcases won't often blow up in your face either 16:17:33 iano: ah yes, that too. but that tends to make you drink too much :-/ 16:18:13 segher: that's not an argument in favor of unsafe languages though 16:18:19 I think moderate drinking could help with extreme programming, as with other social activities 16:19:41 slava: it wasn't. it was an argument against "unsafe languages make testing a lot more work" 16:20:10 I think it goes without saying that unsafe languages make testing more work 16:21:38 well, fractionally more work, sure, i'll give you that -- but it's not an important factor 16:21:51 I think it is 16:22:10 languages with pointer safety and some form of type checking -- static or dynamic -- are the single biggest productivity boost one can get 16:23:35 i don't agree. but that's fine :-) 16:24:12 that's because your judgement is clouded by an irrational attachement to a specific technology, forth in this case 16:24:33 no, that's nonsense 16:36:11 --- join: nighty__ (n=nighty@210.188.173.245) joined #forth 16:50:18 --- join: foxchip (n=fox@166.129.182.228) joined #forth 17:04:41 --- quit: iano () 17:24:59 --- join: iano (n=iosgood@076-076-146-052.pdx.net) joined #forth 17:27:51 --- quit: foxchip (Read error: 110 (Connection timed out)) 17:38:35 --- quit: tathi ("leaving") 18:13:03 --- quit: iano () 18:37:37 --- join: Rodo12 (i=Bob@v-209-98-172-224.mn.visi.com) joined #forth 18:43:56 --- quit: Rodo12 ("Leaving") 20:06:44 --- join: Quartus (n=neal@CPE001b115d994a-CM001947482b20.cpe.net.cable.rogers.com) joined #forth 20:06:44 --- mode: ChanServ set +o Quartus 21:14:27 --- join: sunwukong (n=salvi@ortros.den.rcast.u-tokyo.ac.jp) joined #forth 21:55:56 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 21:57:01 --- join: ramkrsna (n=ramkrsna@unaffiliated/ramkrsna) joined #forth 22:01:15 --- join: neceve (n=ncv@dyn-89.136.41.150.tm.upcnet.ro) joined #forth 22:34:19 --- join: ASau` (n=user@host207-231-msk.microtest.ru) joined #forth 23:17:10 --- quit: lukeparrish (Read error: 110 (Connection timed out)) 23:41:44 --- join: Def (n=joe@c-68-62-76-160.hsd1.mi.comcast.net) joined #forth 23:43:18 --- quit: Deformati (Read error: 104 (Connection reset by peer)) 23:59:59 --- log: ended forth/08.11.16