00:00:00 --- log: started forth/08.12.18 00:07:01 --- quit: proteusguy (Read error: 110 (Connection timed out)) 00:07:46 --- join: proteusguy (n=proteusg@61.7.144.97) joined #forth 00:15:12 --- quit: ygrek (Remote closed the connection) 00:26:45 --- join: ygrek (i=user@gateway/tor/x-e38bcb1230195cc0) joined #forth 01:05:47 --- join: theatrustop (n=yann@76.227.61.98) joined #forth 01:14:40 --- quit: theatrustop ("Ex-Chat") 01:14:58 --- join: theatrustop (n=yann@76.227.61.98) joined #forth 01:29:45 --- quit: preflex (Read error: 60 (Operation timed out)) 01:37:21 --- quit: mauke (Read error: 104 (Connection reset by peer)) 01:39:15 --- quit: nighty__ (Remote closed the connection) 01:41:51 --- join: mauke (i=mauke@p3m/member/mauke) joined #forth 02:28:41 --- join: qFox (i=C00K13S@132pc222.sshunet.nl) joined #forth 02:51:59 --- quit: ASau` (Remote closed the connection) 02:53:59 --- join: ASau` (n=user@77.246.231.144) joined #forth 03:11:56 --- quit: ygrek (Remote closed the connection) 03:15:23 --- quit: I440r ("Leaving") 04:10:59 --- quit: proteusguy (Read error: 110 (Connection timed out)) 04:11:37 --- join: proteusguy (n=proteusg@ppp-124-120-218-6.revip2.asianet.co.th) joined #forth 04:19:39 I'm experimenting with pForth. 04:19:45 Damn crazy thing. 04:20:01 I want to have bidirectional FFI. 04:40:03 why pForth? 04:40:13 What else? 04:40:14 FICL? 04:40:24 It is in consideration too. 04:40:27 Just curious 04:41:02 That's precisely the point in Forth I hate: 04:41:31 plenty of minimal systems of all kinds and nothing reusable. 04:41:37 yeah. 04:42:56 "reusable" led to the sorry state software is in now 04:43:11 heh 04:43:20 Forth tends to go too far to the other extreme though 04:43:37 oxygene: What do mean? 04:44:05 true 04:45:01 ASau`: too many developers reuse squeaky wheels (instead of building proper ones). and then redirect blame onto the component developer (who will assert that this wheel wasn't made for this purpose in the first place) 04:45:31 so it's the old blame game, and in the end, software stays crappy 04:45:53 There're proper tools existing. 04:45:58 Thus it makes no excuse. 04:46:03 and then, when someone tries to fix it, the usual approach is to put another layer on top, "to remain compatible", and "to reuse the existing codebase", as it can't be all crap 04:46:06 (even though it is) 04:46:11 In Forth case, there's none. 04:46:22 forth is the other extreme, tathi is totally right on that 04:46:50 forth is the DIY kit, the other stuff is more like a junkyard 04:47:00 both are suited for lots of things, but not for engineering 04:47:31 Most code written has never been touched by an engineer. 04:47:59 gnomon: it is 80-20 rule. 04:48:08 also known as "worse is better" 04:48:24 You always have 80% of half-working or non-working prototypes. 04:48:34 Other things are pretty reusable. 04:49:43 The problem of Forth is that it is almost fully in those 80% part of the world. 04:49:50 Yeah 04:49:57 I'm not making a point one way or the other about worse-is-better or the 80/20 rule. I'm saying that "both are suited for lots of things, but not for engineering" isn't a very good statement to make, since the overwhelming majority of software - far more than 80% - hasn't even been written with an engineering standard in mind, let alone written to that standard. 04:50:43 I can appreciate wanting to keep things minimal, and not solving a general problem that you don't have, but most Forth programs/systems are just bad. Totally unnecessary coupling of different parts of the program, etc. 04:51:18 You're saying that programmers today are indolent and undisciplined, and will lead this country by a short route to chaos? :) 04:51:26 tathi: that applies to most systems of a certain size. unfortunately, with forth, it starts early 04:51:39 gnomon: "this" country? 04:52:01 It's a quote from a play, oxygene. 04:52:07 oxygene: whois is your friend. 04:52:11 ah, okay 04:52:22 ASau`: it's not. it's misleading, too 04:52:43 oxygene: then the brain is your friend. :D 04:52:59 Unless you have reasons not to trust it. 04:53:06 I think the one that points to me is accurate. In any case, I was making a point about literature, not nationality. 04:53:08 oxygene: yeah, basically writing good software is just not easy. :) 04:53:35 Or...takes more time than it's worth, or something... 04:53:38 tathi, it's more than just difficult: there are very few incentives to build a 100% solution, and many incentives against it. 04:53:45 yeah 04:54:46 Time, exhaustiveness, the requirements of taking into account the shortcomings of the layers below (and sometimes the layers above!) your own component, the desire to write the "fun" algorithmic parts rather than the dull, exhaustive unit test cases... 04:55:18 Tests don't prove correctness. 04:55:24 ...and that's not even mentioning the software patent and copyright law minefields that programmers must deal with today. 04:55:53 ASau, of course tests don't prove correctness. They just test for it :) 04:56:11 They don't test for correctness either. 04:56:23 They only check for obvious failures. 04:56:37 They do if they're done right. Saying that bad tests don't test for correctness is like claiming that bananas make very poor artillery shells. 04:56:41 Or not so obvious ones, if tests are written appropriatly. 04:57:12 gnomon: many programmers believe otherwise. 04:57:24 Non-programmers too. 04:57:38 Insightful tests can check for a more general quality of sane behaviour, too. 04:58:38 ASau, is your argument that tests -do- not increase the quality of a program, or that they -cannot-? 04:58:56 Neither. 04:59:34 What third interpretation of "Tests don't test for correctness" did I miss? 04:59:35 I just state that they are not "sine qua non". 05:00:07 They don't make neither sufficient nor unavoidable condition. 05:00:30 On that, we are in agreement. Tests don't solve everything. Neither do brilliant programmers, or pair programming, or any number of silver bullets. 05:00:52 I'm afraid that I don't understand your last statement, though. 05:01:30 Testing approach is similar to scientific induction: 05:02:07 "once a miracle, twice a coincidence, thrice the law of nature." 05:02:16 Roughly. 05:02:35 There's a fundamental drawback in this approach. 05:03:18 It doesn't forbid miracles. 05:03:21 There's a fundamental strength, though: it can reveal partial results when full knowledge of a system is unavailable, whereas logical deduction falls apart when a single truss is removed. 05:03:54 The scientific method doesn't tell us about how the universe works, it explains what we observe; as does *properly-executed* software testing. 05:04:08 Sure. 05:04:12 But that has nothing to prove algorithm correctness. 05:04:14 Not all the science in the world can disprove the existence of an invisible pink unicorn. 05:04:29 "Bug-free" is same as "miracle-free". 05:04:31 That's true, yes, but that would only matter if computers were machines for executing algorithms. 05:04:45 Given that the code may contain such things like: 05:05:32 : * 2dup = over 2 = and if 2drop 5 else * then ; 05:05:36 Computers, by virtue of the fact that they exist in a physical world that we do not (and, according to some, cannot) fully understand means that we cannot ever prove the correctness of the execution of an algorithm, only its design; and, as far as computing is concerned, it is the execution that we care about. 05:05:46 And there do exist some magic things from time to time, 05:05:51 you can't prove anything. 05:06:08 No, which is why you must test and infer instead, since absolute proof is unattainable. 05:06:25 You may not win the gold medal, but that's not a reason to drop out of the race :) 05:06:30 Sometimes it is possible. :) 05:06:44 I dispute that. 05:07:15 It is only possible to *prove* the correctness of an algorithm when it exists as a pure idea. 05:07:21 There's a large branch of mathematical science which deals with correctness of algorithms. 05:07:43 The very act of implementing it introduces unquantifiable behaviour. 05:08:14 Are you only concerned with mathematical abstractions, or do you care how well your program runs? If the latter, even a little bit, then you simply must test, because you cannot prove. 05:08:31 Sure, there're assumptions, that hardware works more or less correct. 05:08:55 Timing constrains are also provable in some cases. 05:09:11 Assuming "correct" hardware is a rather immense assumption. 05:09:29 That's like assuming a benevolent creator, or assuming that tomorrow will be better than today. 05:09:59 Sure, this comes beyond proving correctness of algorithm. 05:10:16 That is an even more complex point these days, when so much hardware runs its own microcode, or in some cases is implemented entirely in software. 05:10:27 Other scientists and engineers work in respective area. 05:10:33 Right. 05:10:47 My point is that a proven-correct algorithm is only one component of a correct computing system. 05:10:57 Agree. 05:11:54 I also assert that software has a sort of wave-particle duality: it is useful both as a document (that is, a description of procedures and facts which are subject to mathematical proof) and as a device (that is, a machine that performs some kind of work). 05:12:05 Only the first incarnation of a program is subject to mathematical reasoning. 05:12:10 ...unfortunately :( 05:13:06 It doesn't look like wave-particle at all. 05:13:22 It belongs to other philosophical categories. 05:13:41 Would you care to expand on that? I'm interested to hear what you mean. 05:14:47 A bit later (DNS failure). 05:14:55 At your leisure, sir. 05:31:14 --- join: _mathrick (n=mathrick@195.116.35.13) joined #forth 05:32:14 --- quit: mathrick (Nick collision from services.) 05:32:20 --- nick: _mathrick -> mathrick 06:05:38 --- quit: ramkrsna (Remote closed the connection) 06:55:37 Yesss! 06:55:41 I've done it. 06:55:55 Now I know how to extend FICL in Forth. 06:56:04 I'm off-line. 06:56:18 gnomon: sorry, later. 06:57:43 Yeah, I like FICL. The C code is a bit wordy, but it's generally straightforward and easy to understand. 06:59:10 I'd have used FICL for our embedded FORTH interpreter, but pForth did what we wanted with a more flexible license in our case. 07:02:10 I haven't really looked at pForth much 07:06:40 Oh, I take that back. It looked pretty sensible too, but I didn't play with it a lot because I was doing something that needed wordlists. 08:36:48 --- join: GeDaMo (n=gedamo@dyn-62-56-77-42.dslaccess.co.uk) joined #forth 10:00:17 gnomon: particle-wave duality is the solution for paralogism. 10:00:51 gnomon: what you see in software is dual-meaning, dual-destination: 10:01:21 gnomon: theoretical description usable as practical tool at the same time. 10:01:43 TreyB: gimmey moar ;) 10:01:55 TreyB: can you elaborate, please? 10:02:19 TreyB: did you interface to operating system libraries? 10:02:28 TreyB: third-party libraries? 10:02:47 ASau, my invocation of particle-wave duality was a rough analogy, not a direct correspondence; I meant to invoke only its surface properties, not draw attention to any real or perceived deeper similarities. 10:02:47 TreyB: opposite direction? 10:03:01 gnomon: It is too rough. 10:03:16 * gnomon shrugs 10:03:23 We have different rhetorical styles. 10:04:22 I'm chemist by education (thermodynamics, thermochemistry, quantum chem. & spectroscopy). 10:05:21 Each field of above has to deal with paradoxes and paralogisms. 10:06:12 Maybe it raises the level where "dualism" analogy is too rough to be any real. 10:09:02 Maybe, maybe not; but I'm not interested in that argument. I'll drop the point without protest in favour of returning to the original argument. 10:11:34 As for original statement, that program is algorithm and respective tool in one, I agree with that. 10:12:11 The thesis isn't new though, it belongs to one of pioneers of all this computing machinery. 10:12:24 Maybe Dijkstra, maybe someone else. 10:12:26 That wasn't our original argument, though. 10:12:40 Our original argument was whether testing is a good tool to apply to programs. 10:14:15 --- join: preflex (i=mauke@rm-f.net) joined #forth 10:15:26 My opinion is that given the lack of proper tools in some domains, 10:15:35 testing is the only thing that remains. 10:16:21 And in many cases there exist tools which help writing correct programs. 10:18:36 ASau: in that case, why are you using Forth instead of some language with more tools? 10:18:41 (just curious) 10:19:03 I use other languages too. :) 10:21:04 ASau: we ship our product as a set of libraries which require a porting layer on the target. pForth already abstracts I/O for the VM quite well, we just mangled pForth a bit to use our abstractions. 10:21:48 We also strip out some of the pForth functionality, as we don't need it. 10:21:59 --- join: JasonWoof (n=jason@c-66-31-44-71.hsd1.ma.comcast.net) joined #forth 10:21:59 --- mode: ChanServ set +o JasonWoof 10:22:01 Object libraries (ELF/a.out) or Forth libraries? 10:23:05 We ship object libraries for a number of cpu/compiler/container permutations. 10:24:09 Aha! 10:24:19 We don't expose FORTH to the users of the library. We use it internally as a scripting language, really. 10:24:40 So, you call pForth from C or FFI, right? 10:25:09 We have links in both directions. 10:25:20 Nice. 10:26:05 I guess you can't share even bits of code. 10:26:19 Are there any catches on the way? 10:27:23 We've changed pForth enough for other reasons to make it difficult, but not impossible, to back-patch the standard distribution. 10:28:52 I've got a planned change to split the dictionary into two pieces so that we can run the pre-compiled dictionary out of ROM and new/dynamic code out of RAM. 10:29:08 --- quit: theatrustop (No route to host) 10:29:17 tathi: basically, I use Forth because it allows easy intervention into low-level code generation. 10:29:45 Even Lisp doesn't allow some of tricks. 10:29:56 I *might* also change it to use a Harvard architecture (split code and data addressing) for similar reasons. 10:30:56 BTW, pForth fails building on amd64 (others' reports), did you encounter such problem ever? 10:31:27 We don't do 64bit builds (we target cell phones). 10:32:19 Alright. 10:32:33 Thanks for the talk. It was really insightful. 10:33:04 --- join: osh (n=asdf@206.172.95.68) joined #forth 10:33:52 If you plan publishing any improvements to original distribution, 10:33:52 I'd like to keep up with them. 10:33:59 ASau: I see 10:35:06 I'd like to, but we've diverged so far from what I'd do to pForth at this point that my company couldn't use it. 10:36:44 TreyB: maybe you could come with short description what is good and what isn't from your experience. 10:37:19 Even this kind of information is hard to get in Forth community. 10:42:44 I like it generally, obviously. It uses 32-bit tokens, which causes relatively low code density. We need/want 32bit cells, but we don't need 32bit tokens. The harvard architecture changes would make a good place to address this. 10:43:46 Combined with the changes for a ROM-able pre-compiled dictionary, it would make a very nice interpreter for embedding. 10:59:19 --- part: osh left #forth 11:17:21 --- join: snowrichard (n=richard@12.169.182.169) joined #forth 11:17:40 --- quit: ASau ("Reboot!") 11:18:03 --- quit: snowrichard (Client Quit) 11:22:56 --- join: ASau (n=user@193.138.70.52) joined #forth 11:28:50 --- join: Quartus` (n=Quartus`@74.198.12.7) joined #forth 11:56:44 --- quit: lasts (kornbluth.freenode.net irc.freenode.net) 12:00:14 --- join: lasts (n=lasts@77.207.25.109) joined #forth 12:16:53 --- join: xjrn (n=jim@c-24-7-31-66.hsd1.ca.comcast.net) joined #forth 12:42:13 --- quit: GeDaMo ("Leaving.") 12:50:08 --- join: snowrichard (n=richard@12.169.182.169) joined #forth 13:08:29 --- join: Teratogen (i=leontopo@unaffiliated/teratogen) joined #forth 13:09:57 --- quit: snowrichard (Read error: 110 (Connection timed out)) 14:53:45 --- quit: JasonWoof (Read error: 104 (Connection reset by peer)) 14:54:44 --- join: JasonWoof (n=jason@c-66-31-44-71.hsd1.ma.comcast.net) joined #forth 14:54:44 --- mode: ChanServ set +o JasonWoof 15:48:42 --- quit: qFox ("Time for cookies!") 15:52:14 --- quit: maht (Read error: 110 (Connection timed out)) 16:39:03 --- join: nighty__ (n=nighty@210.188.173.245) joined #forth 17:32:15 --- join: mark4 (n=mark4@wsip-98-191-97-24.ph.ph.cox.net) joined #forth 17:55:31 ok, I'm &^@4 fed up with xterm forgetting my selection 17:55:54 anybody know a fix, or can suggest a simple alternative? 17:56:08 forgetting your selection? 17:56:27 yes, whenever I resize the window 17:56:37 which happens automatically in wmii when I open a new window 17:56:58 so I 1) select 2) press f8 to open a browser 3) try to paste 4) curse 17:57:23 that happens in eterm too 17:57:40 make selection in one eterm. open up or SWITCH to another... paste NOTHING 17:58:26 you could use Compiz Fusion, tab the windows together. select, press meta+cursor right then paste :) 17:58:28 I think that copy and paste is the single worst usability issue with Linux 17:58:32 dunno if that works tho 17:58:40 agreed 17:58:56 I had a fun few hours fiddling with compiz 17:58:57 well. therse on other place where its worse 17:59:03 DOS? 17:59:06 then I went back to a window manager where movie players work 17:59:13 where you want to cut/paste into/out of a vmware session 17:59:26 mark4: that shouldn't work 17:59:27 "movie player" ? 17:59:35 xine, mplayer, vlc, ffmpeg... 17:59:42 iirc I couldn't get any of them to work in compiz 17:59:45 i use mplayer in this all the time 17:59:48 and vlc 17:59:53 fantastic 17:59:55 didn't work for me 18:00:49 maybe I'll use compiz in another few years when it's... better 18:01:19 the ONLY thing i do NOT like about compiz is that you have to have either gnome or kde installed to use it 18:01:42 --- quit: xjrn (Read error: 110 (Connection timed out)) 18:02:18 personally i think a combination of windowmaker and compiz-fusion would be the SINGLE greatest wm ever devised 18:08:12 JasonWoof: XTerm*keepSelection: true 18:08:19 * JasonWoof blinks 18:08:19 doesn't work in rxvt though :( 18:08:28 put it in your .Xresources or whatever 18:09:12 unbelievable 18:09:23 thank you! 18:09:41 so it was deleting my selection on purpose! 18:09:45 who thinks of this crap? 18:09:52 dunno 18:10:10 Probably the same people who write forth systems like PFE 18:10:49 I played around with compiz a bunch about a month ago when I was figuring out https://bugs.launchpad.net/bugs/99740 18:10:57 hehe 18:11:36 I was impressed and surprised by some of compiz's features 18:12:50 couldn't figure out how to get it to do some of the useful stuff I've scripted wmii to do though 18:33:28 --- quit: tathi ("leaving") 18:46:39 --- join: xjrn (n=jim@c-24-7-31-66.hsd1.ca.comcast.net) joined #forth 20:30:34 --- quit: xjrn (Read error: 110 (Connection timed out)) 21:38:51 --- join: ramkrsna (n=ramkrsna@unaffiliated/ramkrsna) joined #forth 21:51:02 --- quit: aguai (Remote closed the connection) 21:51:55 --- join: aguai (n=aguai@122-116-183-8.HINET-IP.hinet.net) joined #forth 21:58:05 --- quit: aguai (Remote closed the connection) 21:58:16 --- join: aguai (n=aguai@122-116-183-8.HINET-IP.hinet.net) joined #forth 22:12:05 --- quit: Quartus` (Read error: 104 (Connection reset by peer)) 22:24:25 --- quit: aguai (Read error: 104 (Connection reset by peer)) 23:16:10 --- join: aguai (n=aguai@122-116-183-8.HINET-IP.hinet.net) joined #forth 23:17:36 --- join: qFox (i=C00K13S@132pc222.sshunet.nl) joined #forth 23:59:59 --- log: ended forth/08.12.18