00:00:00 --- log: started forth/15.10.26 01:27:09 --- quit: pointfree (Ping timeout: 250 seconds) 01:44:31 --- join: Timeslice (~photon@1.132.96.29) joined #forth 02:51:44 --- quit: atommann (Ping timeout: 260 seconds) 03:02:49 --- join: atommann (~atommann@210.3.149.230) joined #forth 03:25:30 --- quit: atommann (Quit: Leaving) 03:27:50 --- quit: proteusguy (Ping timeout: 246 seconds) 03:47:44 --- quit: xyh (Remote host closed the connection) 04:10:33 --- join: proteusguy (~proteusgu@183.88.38.159) joined #forth 04:10:33 --- mode: ChanServ set +v proteusguy 04:45:53 --- join: xyh (~xyh@183.14.249.64) joined #forth 05:21:00 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 05:27:47 --- part: Timeslice left #forth 05:42:39 --- quit: Zarutian (Quit: Zarutian) 06:07:22 --- quit: xyh (Remote host closed the connection) 07:06:01 --- quit: proteusguy (Ping timeout: 255 seconds) 07:49:11 --- join: xyh (~xyh@183.14.254.157) joined #forth 07:53:13 --- join: proteusguy (~proteusgu@ppp-110-168-229-239.revip5.asianet.co.th) joined #forth 07:53:13 --- mode: ChanServ set +v proteusguy 08:24:54 --- join: kumul (~mool@adsl-64-237-236-93.prtc.net) joined #forth 08:35:52 --- quit: kumul (Quit: Leaving) 08:44:18 --- quit: xyh (Remote host closed the connection) 08:45:31 --- join: Kumool (~mool@adsl-64-237-236-93.prtc.net) joined #forth 08:54:10 --- quit: Kumool (Quit: BALLOONS) 09:03:46 --- join: true-grue (~grue@176.14.218.33) joined #forth 09:41:45 --- join: xyh (~xyh@183.14.254.157) joined #forth 10:00:32 --- join: pointfree (~pointfree@c-73-142-162-42.hsd1.ma.comcast.net) joined #forth 10:20:14 --- join: bluekelp (~bluekelp@bluekelp.com) joined #forth 10:24:33 --- quit: xyh (Remote host closed the connection) 10:33:36 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 10:34:23 --- quit: Zarutian (Read error: Connection reset by peer) 10:34:39 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 11:30:52 --- join: MickyW (~MickyW@p4FE8D833.dip0.t-ipconnect.de) joined #forth 11:38:11 --- join: boggard (~9v@pool-71-187-223-120.nwrknj.fios.verizon.net) joined #forth 11:50:52 --- join: ASau (~user@netbsd/developers/asau) joined #forth 12:03:04 --- join: goglosh (~user@177.243.167.136) joined #forth 12:03:09 hello 12:04:47 Hi goglosh 12:06:20 I'm starting to read Thinking Forth 12:06:21 :) 12:07:07 A really good book. Interesting and entertaining. 12:07:36 yeah 12:07:44 10 pages in and it's already giving me some perspective 12:07:59 of software design issues and stuff 12:08:43 anyway I was wondering 12:08:59 --- part: boggard left #forth 12:09:08 would it be reasonable to have a 12:09:20 kernel+busybox+forth-only? 12:10:01 by reasonable I mean 'would it be enough to actually do about anything that could be done?' 12:10:03 I think so. But it may be as well reasonable to have a FORTH only. :-) 12:10:40 As you asked: It may be sufficient to do anything. 12:10:41 how does one do that? 12:10:50 What? The latter? 12:11:04 yea, a FORTH only? 12:11:08 Yes. .... 12:11:47 Read on and you will discover that FORTH, along with some basic I/O routines is a stand-alone system to do any computation, control ... everything. 12:12:06 cool 12:12:47 uniformity at it's best 12:13:02 what's your view on that? having a system that is as uniform as possible 12:13:04 A good reading would be one of the old fig-listings. http://forth.org/fig-forth/contents.html 12:13:28 hum 12:13:33 * goglosh looks 12:13:58 I consider that an ideal. I think FORTH covers that "uniformity" as well as other systems - or not. Its relative. 12:15:01 But FORTH may be seen as a case for that. (I must confess, that I am not up-to-date with new developments. Still in love with fig and learning ANS). 12:15:13 because, well, we are all bound to use unix/linux to some extent because it's where stuff is done anyway but 12:15:42 MS hopefully didn't read that. :-) 12:16:00 itself unix has Gone Wrong in so many ways and I am thinking that its' lack of uniformity is to blame 12:16:19 MS is worse so 12:16:54 The point is, that even "uniformity" is relative. Like "compatibility" and such terms. 12:17:11 Merely marketing buzz - in a sense. 12:17:30 lel 12:17:32 well yes 12:17:39 you might be right there but still 12:18:28 well yeah you're right, I was going to say that having a uniform design scheme at all layers blah blah but 12:18:52 ultimately computers do that at the machine instruction level huh? :P 12:19:23 But true. Look ... 12:21:04 in practice you may write a program in any of the languages. If you port it to another system, you must probably modifiy some basic routines, but the main part will still work. That's true for almost all languages and systems. 12:21:48 yes of course 12:21:54 that's how we work anyway 12:22:22 but, well, maybe I'm just Another Emacs Dude 12:22:24 I am not sure, if I took you too literal. Don't wan't to ... 12:22:34 brief! :-) 12:22:37 OK. 12:23:04 what I mean is, like in emacs, you only need know one language, Elisp in that case 12:23:31 and you have access to the whole source of the whole language. And you get to play with it, at various layers 12:23:50 Hm. I think FORTH is as universal and open as you suggested. 12:24:02 resp. implied 12:24:32 ye 12:24:32 I started with computers in the 80's. So I think I got a "feeling" for that. :-) 12:24:36 looks like 12:24:42 nice 12:24:53 I kinda wish I lived in a time were computers were less complex 12:25:11 or, systems, idk 12:25:21 What don't you like about them now? 12:25:49 well for one thing, the old Do One Thing philosophy is fading 12:26:04 and we've taken so many paths for everything 12:26:18 Hmm 12:26:19 like, for example, just wireless stuff 12:26:30 which is something I have to deal with often 12:26:36 we have zillions of drivers 12:26:47 and different encryption schemes with different applications for each 12:26:50 and so on 12:27:31 you use WEP for a whole few months and then you move on to a place with WPA and you can't do nothing. That's a specific case that happened to me of course 12:27:32 You mean, you miss a kind of convergence towards the technical improved? 12:27:43 yes I guess that's it 12:28:03 I think so too. 12:28:11 Why do you think it goes that way? 12:28:26 idk 12:28:29 preference? 12:28:47 Whose preference? Customer? 12:29:21 I think it has to do (and emacs taught me this I think) that sometimes vendors, or developers, cannot consider all the possible use cases or trouble that a user will be running into 12:29:30 so they black-box it too tight 12:29:48 so that you cannot really reach in, unless you get to the source code where it's all a bunch of C spaghetti 12:30:20 so there's no layered abstraction, merely a blackbox, and then it's not too flexible so somebody else has to fork it or make an entirely new software altogether 12:30:59 and we end up with 9 choices for something, which is not bad but they kind of are all incomplete to some extent 12:31:23 I am not sure wether I got it: What is the relation of manifold of use cases and black-boxing it? 12:32:40 hmm, let me think of a good way to say it 12:32:52 take your time 12:33:01 thx 12:35:51 consider the latest quantum-computing processor, say it's a peripheral, so you can work on it like any other driver. As such it comes with a very low level API or whatever you'd call that. So then someone develops a program to use it without delving into the low level details, something that's high level and gives you the foo() bar() baz() functions 12:36:38 OK 12:36:38 But maybe foo() comes with the falafel algorithm for metanumerical compositional application 12:37:21 and that is inneficient with your particular quantum processor 12:38:25 but that is abstracted from you, there is a big gap between actually using the lower level driver, and tweaking a bit of the algorithm 12:39:54 so you are bound to writing the whole thing in C, and maybe almost as if it wwere identical to the original falafel foo() or looking into the spaghetti of C from the vendor's code. Anyway you end up with either a fork, or a commit, but anyway, there's no generality, merely covering special cases and hence there is too much work done 12:42:05 you cannot take an existing software, and have it layered in such a way that you can simply configure one of the lower level layers and have your custom version which then you can ship as a function that, sitting on top of the existing software, modifies it *just enough* 12:42:14 idk if I'm making myself clear here 12:42:29 I think its clearer now. :-) 12:42:59 Funny. I think about a related issue - in a respect quite near to what you said. 12:43:59 whaat is it 12:44:25 I think we are not allone, but money makes the world go around and thats a fundamental issue, for what nobody has time (i.e. money). 12:44:45 I found that ... 12:45:35 development started from low resource computers which forced everybody to find a small but optimal solution in the sense of usability (generally spoken). 12:46:16 That was so overwhelming that it lasted until now. Despite it is not anymore necessary. 12:46:40 it's fun to actually see the evolution of that 12:46:59 wherein people are still complaining that overgeneralization or too high level languages can be slow 12:47:13 Even so - and I think that relates closely to what you said - algorithms. There where only one solution. And a bunch of them. 12:47:24 while developers don't really care about making their software more efficient because computer are fast now 12:47:44 I think that two different things. 12:48:22 But generalization is the point. 12:48:25 I think 12:48:48 There is not only one way. Neither in user interaction no algorithms. 12:49:15 But each and every word processor brings it own sorting algarithm (aso). 12:49:31 yeah 12:49:44 and then you have all these programs 12:49:52 Oh. Good. Wasn't sure if we are still at the same path. :-) 12:49:58 they all do the same thing and may be aimed towards different goals or users 12:50:38 but they all feel incomplete and now you don't get a call on how the details work 12:50:56 so you like the quit button on this one and the scroll bar on the other one 12:51:57 True. Everybody is different. :-) 12:52:50 About details: 12:54:19 I think, it would be usefull to have insight of what happens in detail in a system. OK. Detailledness shall depend on the users abilities and knowledge. But I would like to know why it hangs or to whom it communicates acutally. Many examples possible. 12:54:52 Would like to have much more visualisation. 12:55:11 yes exactly 12:55:17 State diagrams. Data flow. All tools are at hand. But nobody uses them. 12:55:24 Only at meetings. :-)))) 12:55:25 so you actually get to make some decisions 12:55:36 :P 12:56:02 right 12:56:37 well 12:56:42 So I am collecting material about that idea. For a couple of years now. 12:56:52 that's kind of why I'm interested in the Forth Way 12:56:55 :P 12:57:09 Uh. 12:57:55 ? 12:58:28 Sorry. Meant "I understand" 12:58:59 No native Englisch speaker. Sometimes I select the wrong interjection. :-) 12:59:09 iktf 13:00:16 OK. So, I wish you much fun and good ideas while reading. Hope I read you again. 13:00:38 thank you! you too 13:00:39 :) 13:00:39 in that channel 13:02:08 :-) 13:04:38 have a good one ;) 13:10:16 You too, goglosh. afk 13:12:54 --- join: kumul (~mool@adsl-64-237-236-93.prtc.net) joined #forth 13:29:34 --- quit: goglosh (Remote host closed the connection) 13:52:10 --- quit: MickyW (Quit: Verlassend/leaving) 13:58:47 --- join: bedah (~bedah@dyndsl-091-096-199-010.ewe-ip-backbone.de) joined #forth 13:58:49 --- quit: bedah (Read error: Connection reset by peer) 14:50:05 --- join: karswell (~user@121.212.208.46.dyn.plus.net) joined #forth 15:09:06 --- quit: true-grue (Read error: Connection reset by peer) 15:42:42 --- quit: Zarutian (Quit: Zarutian) 15:44:41 anyone use the avr forths? i saw https://www.youtube.com/watch?v=M-Xt1ShKW3c and became interested, though it's an ARM cpu i think 15:44:44 anyway, i'd like thoughts on which of the two "main" avr/atmel forths people have used and liked 15:44:47 mostly i'm interested in using it as a cheap, programmable bus pirate http://dangerousprototypes.com/docs/Bus_Pirate 15:45:33 but would like to eventually do more generic embedded systems w/o the c compile/test/fix cycle 15:55:57 --- part: kumul left #forth 16:07:15 --- quit: proteusguy (Ping timeout: 250 seconds) 16:07:22 --- quit: proteusguy_ (Ping timeout: 255 seconds) 16:19:41 --- join: proteusguy (~proteusgu@ppp-110-168-229-11.revip5.asianet.co.th) joined #forth 16:19:41 --- mode: ChanServ set +v proteusguy 16:20:26 --- join: proteusguy_ (~proteusgu@ppp-110-168-229-11.revip5.asianet.co.th) joined #forth 17:55:38 --- join: atommann (~atommann@210.3.149.230) joined #forth 18:33:11 --- join: xyh (~xyh@183.11.179.212) joined #forth 20:19:49 --- quit: ASau (Ping timeout: 255 seconds) 20:22:12 --- quit: xyh (Remote host closed the connection) 20:23:23 --- join: ASau (~user@netbsd/developers/asau) joined #forth 20:40:53 --- join: probonono (~User@unaffiliated/probonono) joined #forth 21:01:30 --- join: xyh (~xyh@116.31.245.185) joined #forth 21:16:04 --- quit: asagk (Ping timeout: 255 seconds) 21:29:29 --- join: asagk (~asagk@i59F6AEFF.versanet.de) joined #forth 22:10:09 --- quit: proteusguy (Ping timeout: 256 seconds) 22:32:34 --- quit: atommann (Quit: Leaving) 23:59:59 --- log: ended forth/15.10.26