00:00:00 --- log: started forth/14.10.31 00:25:11 --- join: Mat3 (~Mat@ip5b414c9f.dynamic.kabel-deutschland.de) joined #forth 00:27:31 --- quit: Mat3 (Client Quit) 00:40:27 --- join: cataska (~cataska@118-163-69-1.HINET-IP.hinet.net) joined #forth 01:05:22 --- quit: samrat (Ping timeout: 260 seconds) 01:25:04 --- quit: joneshf (Ping timeout: 244 seconds) 01:32:47 --- join: samrat (~samrat@49.244.32.62) joined #forth 01:36:46 --- join: joneshf (~joneshf@98.208.35.89) joined #forth 01:43:38 --- quit: TodPunk (Read error: Connection reset by peer) 01:44:00 --- join: TodPunk (Tod@50-198-177-186-static.hfc.comcastbusiness.net) joined #forth 01:45:45 --- join: lewis1711 (~lewis@210.54.32.206) joined #forth 01:47:55 this is a really stupid question... but when you enter a word in forth, aren't you appending it to the end of the stack, rather than pushing it onto the stack? if I type "3" and then "4" the stack prints as "3 4". not "4 3". or do implementations just reverse the order they print the stack contents? 01:48:48 They print the stack in a useful order. 01:50:30 right, I guess it's arbitrary 01:54:42 Not quite arbitrary. It's printed out in the same order you entered it. 01:54:52 Makes it easy to correlate code you've entered with contents. 01:55:33 Compare: 01:55:37 3 4 OK 01:55:43 . 01:55:45 4 3 OK 01:55:49 Or... 01:55:52 3 4 OK 01:55:54 . 01:55:57 3 4 OK 01:56:26 Which is easier to follow? (Consider the possibility that you may have operations and constants and such, rather than just a string of numbers.) 01:57:24 yeah that does make much more sense 01:57:38 had a bit of a dumb moment thinking it was really a queue though.. 02:40:33 --- quit: samrat (Quit: Computer has gone to sleep.) 02:56:18 --- join: true-grue (~grue@95-25-94-241.broadband.corbina.ru) joined #forth 04:14:55 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 04:44:11 --- join: samrat (~samrat@49.244.90.167) joined #forth 04:54:04 --- quit: samrat (Quit: Computer has gone to sleep.) 05:11:12 --- join: samrat (~samrat@49.244.90.167) joined #forth 05:13:10 --- quit: true-grue (Ping timeout: 255 seconds) 05:17:01 --- join: true-grue (~grue@95-27-138-188.broadband.corbina.ru) joined #forth 05:54:35 --- quit: lewis1711 (Quit: Leaving) 05:56:36 --- join: xyh (~xieyuheng@121.33.190.135) joined #forth 06:02:09 --- quit: xyh (Remote host closed the connection) 06:03:23 --- join: protist (~javery@160.225.69.111.dynamic.snap.net.nz) joined #forth 06:39:45 --- join: joneshf-laptop (~joneshf@98.208.35.89) joined #forth 06:45:09 --- quit: Zarutian (Quit: Zarutian) 07:32:27 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 07:33:38 --- quit: FireFly (Ping timeout: 244 seconds) 07:56:38 --- quit: bluekelp (Ping timeout: 265 seconds) 07:59:00 --- join: FireFly (~firefly@oftn/member/FireFly) joined #forth 08:01:31 --- join: bluekelp (~bluekelp@2001:470:1:41:2d56:9f00:39c6:b01f) joined #forth 08:01:31 --- mode: ChanServ set +v bluekelp 08:17:04 --- quit: FireFly (Ping timeout: 244 seconds) 08:20:33 --- join: cleanup147 (~chatzilla@cm151.gamma117.maxonline.com.sg) joined #forth 08:21:13 --- quit: cleanup147 (Client Quit) 08:29:11 --- join: FireFly (~firefly@oftn/member/FireFly) joined #forth 08:49:35 --- join: xyh (~xieyuheng@2001:250:3002:5550:6ea1:cc0f:bcb2:b187) joined #forth 09:17:49 --- join: vanila (~user@unaffiliated/vanila) joined #forth 10:09:01 --- quit: samrat (Ping timeout: 244 seconds) 10:11:53 --- join: samrat (~samrat@49.244.90.167) joined #forth 10:36:39 --- join: _spt_ (~jaat@host-92-12-212-49.as43234.net) joined #forth 10:36:39 --- quit: _spt_ (Changing host) 10:36:39 --- join: _spt_ (~jaat@unaffiliated/-spt-/x-5624824) joined #forth 10:47:41 --- quit: samrat (Ping timeout: 264 seconds) 10:50:58 --- join: samrat (~samrat@49.244.107.232) joined #forth 11:25:09 --- quit: xyh (Remote host closed the connection) 11:29:58 --- quit: samrat (Ping timeout: 250 seconds) 11:34:25 --- join: samrat (~samrat@49.244.85.156) joined #forth 11:50:30 --- quit: protist (Quit: Konversation terminated!) 11:56:02 --- join: xyh (~xieyuheng@2001:250:3002:5550:6ea1:cc0f:bcb2:b187) joined #forth 11:56:17 in an OO system, ``a message invokes which method'' must be decided at runtime ?? 11:56:54 --- quit: samrat (Quit: Computer has gone to sleep.) 11:59:10 not *necessarily*. that is the general case though. 11:59:32 it's only the case if you use virtual methods. 11:59:49 virtual methods ? 12:00:25 methods that can be overridden. 12:00:45 like... say you only have one class in your entire system. 12:01:14 then there's no reason to use dynamic lookup because you always know which method is being called. 12:02:03 or say you have a superclass and a subclass. maybe the superclass has 2 methods, but the subclass only overrides 1 of them. 12:02:37 if you send the other message, you always know it's the superclass method that will be invoked. 12:03:01 and that could be decided at compile time. 12:05:31 i see. actually when one uses lookup somewhere, there seems always have something could be decided at compile time. and then that is one of the optimization needed to be done. 12:07:58 tangentstorm: how OO languages that you know of handles this ? 12:08:18 * xyh lazy to do the optimization :P 12:08:22 some of them don't handle it at all, and make everything virtual. 12:08:53 in object pascal, you have to explicitly mark methods as virtual if you want to be able to override them in a subclass. 12:19:04 actually I am thinking of smalltalk :: ( ) , I think here the decision must be made at runtime. 12:19:09 while in object pascal message always go with the object, like things such as :: HelloWorld.Put 12:21:53 this feature is acceptable ? this never been considered as a weakness of OO (in smalltalk) ? 12:24:33 tangentstorm: actually I am just beginning to learn OO (from smalltalk), so lack of experiences :P 12:24:57 i promise you that whatever you think the best feature of language x is, someone else thinks that feature is a terrible idea. 12:27:28 that's very true 13:55:17 --- join: karswell (~user@87.114.135.1) joined #forth 13:59:51 DGASAU: thanks to your recommending, I have readed the paper about Krivine's call-by-name lambda-machine. 13:59:56 call-by-name's bad is that you sometimes have to eval a named lambda-term twice (or more then once). 14:00:04 call-by-value's bad is that even on some theoretically reducible lambda-terms you will running into infinite loop. 14:00:11 the Krivine-machine have the first bad. 14:00:30 and, when I implement lambda-calculus, the hard part is to handle bound-variables correctly, Krivine-machine uses the so called ``de Bruijn notation'' to handle this correctly. 14:01:15 I had implemented lambda-calculus twice, first one, in scheme, using call-by-need (do not has both of the two bads above); second one, in my forth-like language, using call-by-value (due to forth's nature) (it has the second bad above). 14:01:24 both of them handled bound-variables (IMO the hardest part of implementation) by "list-with-circles", and I call this "simple-graph-processing". 14:01:30 both of them are way better then Krivine-machine. 14:01:36 IMHO 14:20:23 --- quit: Zarutian (Quit: Zarutian) 15:00:54 --- quit: xyh (Remote host closed the connection) 16:04:21 --- nick: nisstyre -> nisscream 16:06:18 --- quit: irsol (Ping timeout: 256 seconds) 16:08:35 --- join: irsol (~irsol@unaffiliated/contempt) joined #forth 16:18:44 --- join: dys (~user@2a01:1e8:e100:8296:21f:16ff:fe11:1144) joined #forth 16:38:16 --- join: Mat3 (~Mat@ip5b414c9f.dynamic.kabel-deutschland.de) joined #forth 16:38:18 hello 16:48:20 --- quit: _spt_ (Quit: irc- et) 16:53:18 heya Mat3. what are you up to? 16:58:32 hi tangentstorm 17:00:01 I'm finishing Saiwa at current (if this was your intended question) 17:03:49 nice. do you have a user manual yet? :) 17:05:19 I'm working on some form of specification and programming manual (something I will label 'programming in Saiwa') 17:11:24 however, progression is slow at moment 17:14:15 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 17:15:22 --- quit: Zarutian (Read error: Connection reset by peer) 17:15:44 --- join: Zarutian (~zarutian@168-110-22-46.fiber.hringdu.is) joined #forth 17:18:04 any chance you borrow the dictionaries from retro or another forth to help? 17:20:31 tangentstorm, xyh: all methods should be 'virtual'. Why? So one can implement forwarding proxies easily. Why would one want to use such? For various object capability patterns. Why would one want such patterns? Because it makes access control much more granular and expressive. 17:21:22 * Zarutian requests a log from 21:00 to now. 17:21:47 Zarutian: that's sort of like saying every word in forth should be revectorable. :) 17:22:41 tangentstorm: they arent? ;-) (back patch the start of each word you want to revector with a jmp to the new implementation ) 17:23:58 tangentstorm: no, I have now some help by the Nim(rod) community which is great 17:24:24 Mat3: I am curious what you are up to. 17:25:31 there's nothing wrong with that. every word in retro is revectorable by default (it leaves two 'nop' instructions so there's room to put a jump), but if you're targeting an embedded device or are otherwise short on space, you can generate an image without hooks. 17:26:48 I say every forth is revectorable if you dont mind squashing the old implementation of the word 17:27:57 Zarutian: Saiwa is a functional system-programming language which grows by my experiences working on an AOT compiler for retro. It main feature is implicied (automatical) source-code parallelization 17:28:21 AOT stands for what in this context? 17:28:40 Ahead-Of.Time compilation 17:37:12 by the way: does one know a good hash function for strings which maps to small tables (something like 1024 elements) ? 17:40:28 maybe just take any hash function and HEX 3FF AND ? 17:44:34 no, because most hash generators I try are sensitive to the word width 17:45:34 (small changes generate large value differences) 17:46:17 ^I tried 17:47:37 so if I cut a small subrange out of a large value chances are high the cut-off itself veries to a lesser degree 17:47:52 and this lead to clustering 17:48:37 ciao 17:48:46 --- quit: Mat3 (Quit: Verlassend) 18:10:29 --- quit: true-grue (Read error: Connection reset by peer) 19:32:58 --- quit: karswell (Read error: Connection reset by peer) 19:35:34 --- join: karswell (~user@87.114.135.1) joined #forth 19:40:02 --- quit: karswell (Read error: Connection reset by peer) 19:41:43 --- join: karswell (~user@87.114.135.1) joined #forth 19:50:28 --- quit: dys (Ping timeout: 256 seconds) 19:55:23 --- join: samrat (~samrat@49.244.8.59) joined #forth 19:56:11 --- quit: Zarutian (Quit: Zarutian) 19:56:43 --- quit: samrat (Client Quit) 19:58:03 --- join: samrat (~samrat@49.244.8.59) joined #forth 20:12:05 --- quit: samrat (Ping timeout: 260 seconds) 20:15:29 --- join: samrat (~samrat@49.244.67.34) joined #forth 20:18:23 --- quit: samrat (Client Quit) 20:22:13 --- quit: vanila (Quit: Leaving) 20:23:20 --- join: samrat (~samrat@49.244.109.76) joined #forth 21:04:34 --- quit: samrat (Ping timeout: 258 seconds) 21:07:27 --- join: samrat (~samrat@49.244.47.234) joined #forth 22:00:52 --- quit: samrat (Ping timeout: 260 seconds) 22:03:56 --- join: samrat (~samrat@49.244.47.234) joined #forth 22:08:16 --- quit: samrat (Ping timeout: 244 seconds) 22:11:41 --- join: samrat (~samrat@49.244.47.234) joined #forth 23:26:01 --- quit: bbloom (Read error: Connection reset by peer) 23:26:42 --- join: bbloom (~bbloom@cpe-68-175-72-82.nyc.res.rr.com) joined #forth 23:59:59 --- log: ended forth/14.10.31