00:00:00 --- log: started retro/12.04.12 02:03:53 --- quit: virl (Read error: Connection reset by peer) 03:52:26 jyfl987: no 03:59:00 I've dabbled with implementing cloud services in retro, but not providing retro itself as a cloud service 04:34:59 crc: i think it worth to try that. server-side programmer will be more care about the running speed 05:42:58 I had a copy of retro running server-side once, but it's problematic. There's no facilities for handling multiple users, no way to detect problem-causing code (infinite loops and such) 05:44:22 i think for cloud service, there is only 2 app type: socket processing app, http processing app 05:44:56 crc: GAE use cgi protocol to invoke a target app when user request a uri 05:45:50 crc: i think under this mode, you could replace the cgi app to a retro vm with some user request data on the inputs or any other storage device of the vm 05:47:02 crc: and support many service for this domain specialfic retro vm, like add memcache client on port 19, sql database query on port 20, etc 06:08:20 http processing is supported via casket' library; the blog, irc log viewer are written as cgi applications 06:12:10 crc: i mean you dont need to use crc to write a socket/http server and dispatch the req, 06:13:26 you just wrote an split socket/http server which parse the user request and then invoke retro vm to run the user defined image file with prepared data 06:16:22 if your platform built on GA114 you could use a stack based lang for writing the server, if its a register based machine, why not use the native stack based code to write the server? what user care is just the logic , this could be optimized by retro code 06:17:50 sorry, i mean for register based machine, you could use the register based native code for writing the server 06:18:17 I don't do native code though, just ngaro bytecode 06:18:45 but you still use native code to implement the ngaro vm , isnt it? 06:19:53 not necessarily. the vm implementations may be interpreted, bytecode compiled, etc, depending on the implementation language 06:21:18 at lease you have a asm version 06:21:31 true, for 32-bit x86 only 06:21:43 and c version? 06:22:45 yes 06:24:05 maybe i should describe more clearly, have you tried any other common language? 06:24:12 like python / ruby ? 06:30:07 I have implementations of the VM in a lot of languages: assembly, C, C#, F#, Forth, Common Lisp, Python, Ruby, Lua, Perl, PHP, Scheme, and Java 06:30:47 but i dont know if you got the experiences of common web framework, like django 06:30:52 nope 06:33:45 these framework almost all launch some server which parsing the request and dispatch to it to any worker thread in the worker-pool, when they receive the worker's response , it then deliver to the origin user 06:34:23 in this mode, i hope the retro vm could play the worker role 07:17:59 how does the server interact with the workers? 07:33:19 crc: ipc/socket 07:57:38 so none of the current vm implementations will be usable 08:42:37 crc: i think for vm, you just put the parsed request data to some inputs buffer and when your retro code processed all logic, call a customized port to return the data 08:42:39 --- quit: jyfl987 (Quit: leaving) 10:13:41 --- join: __tthomas__ (~Owner@24.130.7.34) joined #retro 12:35:07 --- join: Mat2 (5b4085c5@gateway/web/freenode/ip.91.64.133.197) joined #retro 12:35:13 hello 13:02:20 --- join: Kumul (~Kumul@adsl-72-50-76-18.prtc.net) joined #retro 13:40:44 <__tthomas__> hey 13:42:12 Hi ! How you doing ? 13:42:28 <__tthomas__> pretty well, writing some automated tests for work 13:42:54 i'm writing an assembler for my vm in retro 13:43:06 <__tthomas__> very cool.. 13:43:57 <__tthomas__> I was trying to increase robustness by adding code to determine if tcp connection on remote side was disconnected, apparently it can't be done.. 13:45:07 <__tthomas__> I kind of knew that, but was hoping there was some trick, vs.. sending a keepalive packet and looking for exception so now need to see if that will block, and if I need to add check to see if send will block.. 13:45:30 hmm, sadly I don't know much about the IP protocol and extensions like TCP 13:46:17 <__tthomas__> well way I used to do it was call read, if it returned 0 means socket is probably closed, -1 no new data ready, or >0 bytes successfully read.. 13:47:07 <__tthomas__> though the 0 won't return right away will take a few minutes after socket is closed, so will just keep saying no new data till timeout hits, then get 0.. 13:47:07 probably data packets need some mind of handshaking 13:47:15 sorry, kind of 13:47:17 <__tthomas__> it is just the nature of tcp 13:47:32 <__tthomas__> I mostly use udp at work.. 13:50:34 who can log onto the idea for a protocol without disconnection signaling ? 13:51:15 <__tthomas__> it isn't possible with tcp as route packets take is not predictable, nor is the order... the packets are rebuilt on receive side.. 13:52:20 <__tthomas__> generally you just assume if havent received anything for x time other side is closed and you close manually.. on proper close you are at least signalled, but not on an unexpected.. 13:53:06 <__tthomas__> I definitely need to do some testing.. 13:58:29 TCP is strange 14:01:08 <__tthomas__> you are taking an unreliable connection and treating it like a pipe.. so it works as expected I would say.. :) 14:02:46 <__tthomas__> it only gets nastier when throw wireless and cellphones in the mix.. 14:04:34 streaming data will be suboptimal in these cases 14:05:49 <__tthomas__> that is why voip, and video use udp not tcp.. dropping a few packets or getting them out of order doesnt matter.. it just degrades quality.. 14:06:56 ah ok, good to know 14:10:45 I hope someday there is the chance for a better network protocol and infrastructure, something like internet 2.0 14:17:39 <__tthomas__> not real sure what they can do.. packet switched network atm/ethernet works pretty well.. the big issues we have is working around limited ip pool of ipv6... the being able to tell if wireless or not could be a big boon, but other than that getting rid of NAT would go a huge way.. 14:18:09 <__tthomas__> ipv4 not ipv6, though we do still have issue of running out of MAC addresses with ethernet.. 14:19:15 <__tthomas__> though ipv6 they fixed locallink addresses which is huge for me.. 14:21:29 http://bernd-paysan.de/internet-2.0.html 14:23:57 <__tthomas__> heh, that is just the application layer.. a replacement for TCP/IP.. :) 14:25:03 http://libswift.org/ 14:26:07 that's seem some kind of base for it 14:26:10 <__tthomas__> I wonder why they base it on such a high level protocol.. could base it on ARP... 14:26:16 <__tthomas__> or ICMP 14:26:53 <__tthomas__> with raw sockets can pretty much do whatever you want.. 14:28:19 do not know, probably to evade abstraction layering 14:29:01 by reading i found some design similarities with BTX 14:29:50 and that's some kind of one rules all protocol 14:30:01 or one fits all better 14:30:15 <__tthomas__> zeromq is really nice, it uses local multicast, but it is more of an application to application protocol.. 14:32:28 oh, it's nice 14:32:28 <__tthomas__> I really like message bus protocols.. 14:44:10 there useful for sure :) 15:12:39 <__tthomas__> yeah they are, sure does beat mailbox's or named pipes.. 15:53:29 need some sleep, ciao 15:53:35 --- quit: Mat2 (Quit: Page closed) 16:28:03 * crc is taking a break from work on the test suite to write a memory allocation library 16:28:56 __tthomas__: I added a bit to the last article on corpse to try to clarify the behavior of [ ] at the listener 16:30:36 <__tthomas__> I read that.. :) thanks 16:30:43 did it help? 16:31:14 <__tthomas__> yeah, I pretty much had a good idea of how it worked in compiler, but wasn't sure about if the jumps were compiled in at listener.. 16:38:16 <__tthomas__> I am almost ready to release a new experimental C# version, just need to clean up one thing, and some documentation for what has been added and make sure all example apps cover all the functionality.. 17:55:20 I'll look forward to seeing it 20:15:54 --- join: __tthomas__1 (~Owner@24.130.7.34) joined #retro 20:18:04 <__tthomas__1> l 20:18:24 --- quit: __tthomas__ (Ping timeout: 246 seconds) 20:37:47 --- join: jyfl987 (~jyf@unaffiliated/yunfan) joined #retro 20:40:42 --- quit: Kumul (Quit: gone) 23:01:04 --- part: __tthomas__1 left #retro 23:59:59 --- log: ended retro/12.04.12