00:00:00 --- log: started retro/11.09.09 01:04:48 --- log: started retro/11.09.09 01:04:48 --- join: clog (~nef@bespin.org) joined #retro 01:04:48 --- topic: 'Retro Language | http://retroforth.org | Logs @ http://rx-core.org/dev/rancid | Retro 11.0.1 @ http://bit.ly/ogqWFs | Fossil Repo @ http://rx-core.org | Blog @ http://rx-core.org/dev/corpse | Donations @ https://www.wepay.com/donate/179527' 01:04:48 --- topic: set by crc!~quassel@li125-93.members.linode.com on [Sun Aug 21 12:47:49 2011] 01:04:48 --- names: list (clog crc oPless cfa SimonRC yiyus @ChanServ) 02:25:05 --- join: sunwukong (~vukung@catv-80-98-247-63.catv.broadband.hu) joined #retro 02:36:10 hi 02:37:31 I've implemented the Ngaro VM in assembly 02:37:36 https://bitbucket.org/salvipeter/ngaro-asm-x86/ 02:38:48 sunwukong: I'm getting ready to head to work, but will take a look at this tonight 02:38:57 ok :) 03:29:12 sunwukong: it seems to work ok if I do: 03:29:12 ./ngaro retroImage < filename 03:29:12 or 03:29:12 cat - | ./ngaro retroImage 03:29:12 but it has problems when I use raw keyboard input after doing: 03:29:12 ./ngaro retroImage 03:29:41 specifically, I hit a key and it keeps displaying over and over until it has a stack underflow or segfault 03:30:40 hmm... it works ok both ways here 03:32:01 it must be some termio problem... what system do you work on? 03:36:37 Linux questor 2.6.18.8-linode22 #1 SMP Tue Nov 10 16:12:12 UTC 2009 i686 GNU/Linux 03:36:46 running Debian 5.x 03:39:06 I've tried it on both older and newer kernels, so that shouldn't be a problem... 03:40:22 is it a 32bit machine? 03:42:04 (I see it is... :)) 03:42:18 yes 03:47:44 strange... just tested with a Debian 6.1, runs OK 03:48:35 so I'm unfortunately out of ideas, unless I can see it in gdb... 05:11:03 --- quit: crc (Remote host closed the connection) 05:49:46 --- join: crc (~quassel@li125-93.members.linode.com) joined #retro 06:05:09 assembly implemention is in my repo now. Performance seems very nice so far. 06:10:39 glad to hear it 06:21:16 I just found out that my VM does not set port #0 to 1 after a wait operation, but it does not even seem necessary 06:21:57 to tell the truth, I don't really see the importance of port #0 at all 06:26:14 port 0 is used to indicate that we are ready for an i/o event. if it's not used, it can potentially cause issues 06:26:53 does it take only 0 or 1? 06:26:58 yes 06:27:05 okay, I'll put it in 06:30:57 one other thing: the vm does not restore the terminal settings if the image name is not specified 06:34:09 oh, okay 06:34:16 will fix that, too 06:38:35 fwiw, the benchmark results (compared to the other vm implementations): https://docs.google.com/spreadsheet/ccc?key=0ArQ9snhGsa7HdEp1aTRfMzNndVU1TkJWdmVFUDlLalE&hl=en_US 06:43:31 assembly power! :) 06:52:17 yes. very nicely done :) 07:26:23 okay, I fixed some bugs and added image saving (only shrunk image for now) 07:27:02 I can send you a patch or you can just get it from bitbucket 08:16:44 --- join: roarde (~roarde@pdpc/supporter/active/roarde) joined #retro 08:24:27 changes pulled. and it now works correctly under putty :) 08:27:19 wow, that's good news 08:27:56 maybe the problem was that I used wrong values for window width/height in the first version 08:41:25 --- quit: roarde (Quit: Leaving) 15:25:29 also added the include feature 15:26:54 crc: do you have a minimal example where casket fails? (was it connected to the missing 'include' words?) 15:29:42 anyway, I'm going to bed, it's already past 1am here 15:29:48 g'night 15:29:57 --- quit: sunwukong (Quit: bye) 19:35:35 I might move rancid over to sunwukong's assembly vm next week. It'll reduce the processing time significantly. (In one test, the C vm took 2.29 seconds, while the assembly took 0.76 to do the same job. Other tests look similarly promising) 23:31:13 --- join: sunwukong (~vukung@catv-80-98-247-63.catv.broadband.hu) joined #retro 23:34:12 morning 23:36:50 crc: thanks for the mail, I've applied the patch 23:37:13 and changed data/return stack depth to cell-based as well 23:59:59 --- log: ended retro/11.09.09