Fri Apr 17 11:48:26 2009
[dgd]
Aidil@Way of the Force puts his fingers to his lips and goes: blblblblblblblblblbl.
Fri Apr 17 12:54:26 2009
[dgd]
Quixadhal@Bloodlines: A new ansi_d is lurking around the corner, with a big blackjack and stiletto.
Fri Apr 17 12:57:51 2009
[dgd]
Quixadhal@Bloodlines: It still has a few rough edges, but I may fire it off to give Aidil something scary to read with the lights off.
Fri Apr 17 12:58:56 2009
[dgd]
Quixadhal@Bloodlines: Extra bonus points if you have Putty or an xterm (or something else that supports xterm-256 mode). In any case, I'm going to go take a nap. :)
Fri Apr 17 13:00:47 2009
[dgd]
Quixadhal@Bloodlines: It's rather fun to put the game in "ansi grey" mode and have it render all the colours as greyscale shades.
Fri Apr 17 13:26:10 2009
[dgd]
Aidil@GurbaHub: the big question however will be what it does with a room with say 1200 items in its inventory.
Fri Apr 17 13:26:26 2009
[dgd]
Aidil@GurbaHub: the current ansi_d needed quite a bit of tuning to handle that.
Fri Apr 17 13:26:58 2009
[dgd]
Aidil@GurbaHub: as in, be able to display that without running out of ticks :)
Fri Apr 17 13:27:48 2009
[dgd]
Aidil@GurbaHub: and for that it also needed the following line: rlimits(MAX_DEPTH; MAX_TICKS * 10000) {
Fri Apr 17 13:33:39 2009
[dgd]
Frutsel@fruts: I still think you should ditch the ticks, and use lice or something
Fri Apr 17 21:34:01 2009
[dgd]
Quixadhal@Bloodlines: This is true... it currently handles displaying the XTERM-256 palette, which is 256 items...
Fri Apr 17 21:35:21 2009
[dgd]
Quixadhal@Bloodlines: I suspect xterm mode will probably be OK, as the translations for it are generated and cached. 24-bit mode, not so well.... unless you have a good way to cache 2^24 values? *grin*
Fri Apr 17 21:38:21 2009
[dgd]
Quixadhal@Bloodlines: One question... is there any way to find out (from code) how many ticks you have left in the current execution round? It'd be nice to be able to code defensively, rather than guess or have things drop to the floor when you guess wrong.
Fri Apr 17 22:37:05 2009
[dgd]
Aidil@GurbaHub: system.router.error : Fire and Ice is trying to spoof andSapid
Fri Apr 17 22:37:31 2009
[dgd]
Kalinash@Fire and Ice: i need to generate a new password or something?
Fri Apr 17 22:37:38 2009
[dgd]
Aidil@GurbaHub: your chan-user-reply has the source and destination reversed.
Fri Apr 17 22:39:45 2009
[dgd]
Aidil@GurbaHub: my router says so :) system.router.warn : Bad source for packet ({ "chan-user-reply", 5, "andSapid", 0, "Fire and Ice", 0, "kalinash", "Kalinash", 0 })
Fri Apr 17 22:40:24 2009
[dgd]
Kalinash@Fire and Ice: heh, yep, i need to swap elements 2 and 4 from the req and i'm doing them straight across :)
Fri Apr 17 22:41:44 2009
[dgd]
Aidil@GurbaHub: not dumping all packets, but it does inform me about things it considers junk :)
Fri Apr 17 23:34:55 2009
[dgd]
Quixadhal@Bloodlines: Hmmm, now the question is how many ticks does calling status and parsing the results out use up? *grin*
Sat Apr 18 21:22:22 2009
[dgd]
Aidil@GurbaHub: btw, will look at your ansi_d stuff tomorrow, Quixadhal.
Mon Apr 20 10:50:17 2009
[dgd]
Quixadhal@Bloodlines notices that either all is quiet out in the dgd channel, or his intermud connection is down.
Sat Apr 25 14:17:49 2009
[dgd]
Silenus@Dead Souls Dev: i am sitting here working on a lispy compiler today. some of the backend stuff i read about is well hard for me to understand.
Sat Apr 25 14:21:30 2009
[dgd]
Mordain@WarlordsDevDS1: to me lisp and reverse polish notation are like, "well im sure it has uses, and im impressed if you are good with it, but WTF would i bother?", lol
Sat Apr 25 14:23:37 2009
[dgd]
Silenus@Dead Souls Dev: easier to have only basically lambdas and evaluations being your basic constructs rather than the vast amount of other stuff you need for an imperative language.
Sat Apr 25 14:26:53 2009
[dgd]
Silenus@Dead Souls Dev: main thing I dont like is lack of type annotations which is something I am trying to add.
Sat Apr 25 14:29:40 2009
[dgd]
Mordain@WarlordsDevDS1: hmm full book about lisp free online... i might do some reading http://gigamonkeys.com/book/
Sat Apr 25 14:57:31 2009
[dgd]
Silenus@Dead Souls Dev: i am tempted to spruce this language up but I am trying to avoid the temptation atm.
Sat Apr 25 15:31:59 2009
[dgd]
Aidil@Way of the Force: heh. simplify the basic building blocks for code, and leave the work to the implementer/coder/programmer. I've heard that one before in a slightly different context.
Sat Apr 25 15:32:55 2009
[dgd]
Aidil@Way of the Force: too bad.. you build a cpu once every couple years, same for compilers.. People write software for those things every minute.. so simplifying the building blocks is not the right way to optimize this.
Sat Apr 25 15:42:54 2009
[dgd]
Silenus@Dead Souls Dev: well depends on what you are trying to do I think :-)
Sat Apr 25 15:43:10 2009
[dgd]
Silenus@Dead Souls Dev: i am trying to get the frontend out of the way quickly and work on the backend stuff
Sat Apr 25 15:43:46 2009
[dgd]
Silenus@Dead Souls Dev: and i doubt anyone other than myself will be using this in all likelihood.
Sat Apr 25 15:45:41 2009
[dgd]
Cratylus@Dead Souls Dev: "one saturday i spent just eating ctm all day, and sighing contentedly"
Sat Apr 25 15:47:45 2009
[dgd]
Silenus@Dead Souls Dev: perhaps at some point I will revisit the frontend and spruce it up but at this point i just want to get something working.
Sat Apr 25 15:56:44 2009
[dgd]
Marajin@AndroDGD-Upd: Well CTM can be nom yes, but it can go very very wrong
Sat Apr 25 15:57:30 2009
[dgd]
Silenus@Dead Souls Dev: HK is pretty cosmopolitan so alot of good cuisine here
Sat Apr 25 16:04:21 2009
[dgd]
Silenus@Dead Souls Dev: could be. I think the prices are currently bit higher than I would like and I doubt I would have much use for it. I am just happy with my DSL.
Sat Apr 25 16:23:46 2009
[dgd]
Silenus@Dead Souls Dev: only problem I have living here is of course the polution. mind the lung cancer :D
Sat Apr 25 16:24:57 2009
[dgd]
Mordain@WarlordsDevDS1: whatever doesn't kill you makes you stronger... except polio
Sat Apr 25 16:31:16 2009
[dgd]
Silenus@Dead Souls Dev: yeah watch out for those Nietzsche aphorisms :D
Sat Apr 25 18:15:26 2009
[dgd]
Aidil@Way of the Force: so.. work should get a bit less busy in a week or 2.. or so they say.. lessee if I get to do a bit more work on gurbalib again when that happens :)
Mon Apr 27 20:14:48 2009
[dgd]
Quixadhal@Bloodlines: *chuckle* Apparently ye olde intermud fell down and went boom, probably with a network bounce on my end.
Mon Apr 27 20:14:57 2009
[dgd]
Aidil@Way of the Force: was starting to wonder if you had permanently broken Bloodlines :)
Mon Apr 27 20:15:07 2009
[dgd]
Quixadhal@Bloodlines: Either that, your you've coded the router to hide from me.
Mon Apr 27 20:15:40 2009
[dgd]
Aidil@Way of the Force: hmm. don't think the router went down for quite some time tho.
Mon Apr 27 20:15:51 2009
[dgd]
Quixadhal@Bloodlines: I'll have to paw through the error logs to see if it whined about anything.
Mon Apr 27 20:16:28 2009
[dgd]
Quixadhal@Bloodlines: No, I'm sure it hasn't.... I suspect my connection reset (at my firewall) and i3 didn't notice that it wasn't really there anymore.
Mon Apr 27 20:17:07 2009
[dgd]
Aidil@Way of the Force: that could be. it does do the 'ping' thing, but it doesn't seem to do anything with the result :P
Mon Apr 27 20:17:33 2009
[dgd]
Cratylus@Dead Souls Dev: when the problem isnt your computer but rather the router/isp, connections can kinda ghost up
Mon Apr 27 20:17:38 2009
[dgd]
Quixadhal@Bloodlines: I'll have to figure out a good way for i3 to bounce once a week... I have my firewall flush tables once a week, and reboot once a month.
Mon Apr 27 20:18:24 2009
[dgd]
Quixadhal@Bloodlines: Yes, not counting when my ISP does it for me *grin*
Mon Apr 27 20:18:36 2009
[dgd]
Aidil@Way of the Force: hmm. the router did see you being gone quite ok. Will take a look at disconnect handling in gurbalib once I get a bit more time again :)
Mon Apr 27 20:20:14 2009
[dgd]
Aidil@Way of the Force: but the network code in dgd should quite detect the issue when you try to write to the connection, and report it being gone, which makes me suspect there is a prob in the code handling that in gurbalib.
Mon Apr 27 20:20:30 2009
[dgd]
Quixadhal@Bloodlines: So, I have a question that's probaby generic to LP muds, but might also be rather specific to the driver you're using....
Mon Apr 27 20:21:32 2009
[dgd]
Quixadhal@Bloodlines: Is an execution "tick", a period of real time, cpu time, or a number of vm instructions executed?
Mon Apr 27 20:22:30 2009
[dgd]
Quixadhal@Bloodlines: In other words, if I set a limit of 10,000 ticks, how will upgrading my machine's CPU affect that limit? :)
Mon Apr 27 20:23:07 2009
[dgd]
Raudhrskal@Dead Souls Dev: iirc mudos counts vm instructions, while fluffos realtime seconds?
Mon Apr 27 20:23:43 2009
[dgd]
Cratylus@Dead Souls Dev: wodan question. i can tell you that on a faster cpu, you get fewer eval cost errors
Mon Apr 27 20:23:45 2009
[dgd]
Aidil@Way of the Force: on dgd, just like on the original lpmud, the cost in ticks for each efun or operation is predefined.
Mon Apr 27 20:24:24 2009
[dgd]
Cratylus@Dead Souls Dev: beyond that, i'd have to defer to smart people
Mon Apr 27 20:25:35 2009
[dgd]
Quixadhal@Bloodlines: Hmmm, ok. So on DGD, it's instructions so you'd presumably have more idle CPU time on a faster machine, but the same numbers.
Mon Apr 27 20:26:13 2009
[dgd]
Aidil@Way of the Force: tho its not exactly instructions, but that is a useful enough way to look at it :)
Mon Apr 27 20:26:32 2009
[dgd]
Quixadhal@Bloodlines: I'm pondering rewriting my ugly ansi colour init code to check its own ticks and resume processing when it's almost out, rather than my current kludge.
Mon Apr 27 20:27:13 2009
[dgd]
Quixadhal@Bloodlines: and if I know that the "tick" values don't change, I can just approximate a loop's usage rather than figuring it out. :)
Mon Apr 27 20:28:16 2009
[dgd]
Quixadhal@Bloodlines: Otherwise, I'd have to run the loop once to see and hope you're not loading on a 386/16 where you probably won't make it through one iteration (on fluffos).
Mon Apr 27 20:29:54 2009
[dgd]
Aidil@Way of the Force: I suggest you rename your monster to terminal_d or something :)
Mon Apr 27 20:30:39 2009
[dgd]
Quixadhal@Bloodlines: Totally different topic... I was looking at gurba's help stuff and wondering if we might want to support having a help() function in the actual commands?
Mon Apr 27 20:31:14 2009
[dgd]
Aidil@Way of the Force: yes, tho I'd rather want to call it 'query_usage()'
Mon Apr 27 20:31:33 2009
[dgd]
Quixadhal@Bloodlines: Actually, I was trying to figure out where the command search path is determined... and thinking if there were no pre-defined help file, it could try to call a help function.
Mon Apr 27 20:32:28 2009
[dgd]
Quixadhal@Bloodlines: Ah, ok. I shall have to whip up a chintzy "which" command to keep me from abusing find at the shell prompt.
Mon Apr 27 20:33:29 2009
[dgd]
Quixadhal@Bloodlines: I'll let you guys deal with adding "add action", "channels", and all that to it. *grin*
Mon Apr 27 20:34:25 2009
[dgd]
Quixadhal@Bloodlines: which pull -- pull is currently defined by /my/finger.c
Mon Apr 27 20:44:04 2009
[dgd]
Quixadhal@Bloodlines: if(butt()->query_crack()) call_out("laywer", 0);
Mon Apr 27 22:23:08 2009
[dgd]
Kalinash@Fire and Ice: i for one would like to welcome our new feline overlords
Mon Apr 27 22:24:40 2009
[dgd]
Frutsel@fruts: better to hoard cans of tuna to be on the safe side though
Mon Apr 27 22:28:35 2009
[dgd]
Frutsel@fruts: anyway, time to try this sleep thing you talked about...
Mon Apr 27 22:29:13 2009
[dgd]
Frutsel@fruts: and hope the kittens won't decide that 3:30 is a great time to have a wild chase across the sleeping humans
Mon Apr 27 22:29:47 2009
[dgd]
Quixadhal@Bloodlines is already planning to get in on the catnip black market when they rise to power...
Mon Apr 27 22:31:15 2009
[dgd]
Frutsel@fruts: I've got a nice stash of that here too... it's not easy to open that drawer without getting a lot of attention :)
Mon Apr 27 22:31:49 2009
[dgd]
Quixadhal@Bloodlines: Yeah, it's amazing how far away they can hear the sound of that container opening.... :)
Mon Apr 27 22:32:44 2009
[dgd]
Frutsel@fruts: they hear things allright, they just choose to ignore most of it
Mon Apr 27 22:33:26 2009
[dgd]
Aidil@Way of the Force: I'm convinced their ears are tuned to cut out all the stuff they don't wanna hear so the things they want to hear really stand out.
Mon Apr 27 22:33:34 2009
[dgd]
Frutsel@fruts: anyway, time to sleep. good to see that you people are still alive though
Tue Apr 28 00:18:48 2009
[dgd]
Quixadhal@Bloodlines: What to do when you think the coffee pot needs cleaning anyways?... http://southernfriedscience.com/2009/04/26/how-to-brew-beer-in-a-coffee-maker-using-only-materials-commonly-found-on-a-modestly-sized-oceanographic-research-vessel/
Tue Apr 28 08:59:05 2009
[dgd]
Frutsel@fruts: I don't get it... How do they make coffee when they've abused the coffee machine like that?
Wed Apr 29 15:48:46 2009
[dgd]
Cratylus@Dead Souls Limpet: oh and i dont remember if i asked before, is it ok for dgde to be defaultly on for new creators on ds lib?
Wed Apr 29 15:51:37 2009
[dgd]
Aidil@Way of the Force: 1. every dutch person who has spent enough time in the USA tries to have an american accent, just to 'impress'.. and 2. yes.
Wed Apr 29 15:53:09 2009
[dgd]
Aidil@Way of the Force: try to escape beign brainwashed after spending some time in the USA.
Wed Apr 29 23:12:11 2009
[dgd]
Quixadhal@Bloodlines: Me thinks "/daemons/imud_d"->query_connected() should do more than return the variable, since that's only what we last knew, not what is current.
Thu Apr 30 12:27:33 2009
[dgd]
Aidil@The Zone: anyway.. no, query_connection() really should return the last known state, for 2 reasons:
Thu Apr 30 12:27:52 2009
[dgd]
Aidil@The Zone: first is that it really was intended as an accessor on the connected variable
Thu Apr 30 12:28:27 2009
[dgd]
Aidil@The Zone: but more importantly, there is no good way to know the 'current' status because seen from the lpc layer, all network communications is asynchronous.
Thu Apr 30 12:29:50 2009
[dgd]
Aidil@The Zone: so active checking always still gets you a last known status, not the current status, and there is absolutely no way in which you can get the current status in a single execution round. Any answers from the network layer will come through call backs that very likely won't occur untill after your current execution round has finished.
Thu Apr 30 12:31:35 2009
[dgd]
Quixadhal@Bloodlines: I realize this is from the UI point of view, but the only way *I* can tell if I'm realy connected is by trying to send something. If I get no echo of my message, I know something is horked. Is there nothing in the I3 protocol to allow for a host (or the server itself) to be pinged?
Thu Apr 30 12:32:20 2009
[dgd]
Aidil@The Zone: yes, there is something like that, it is actually being used by the i3 client, but not being checked properly.
Thu Apr 30 12:33:10 2009
[dgd]
Aidil@The Zone: as I mentioned, there is absolutely NO WAY in which you can send out network data and get a response to it in the same execution round.
Thu Apr 30 12:33:23 2009
[dgd]
Aidil@The Zone: it cannot be done, so you really MUST update a last known state and check that.
Thu Apr 30 12:33:34 2009
[dgd]
Quixadhal@Bloodlines: Perhaps, but "last known" from a few seconds ago is much more useful than currently "last known" from a week ago.
Thu Apr 30 12:34:43 2009
[dgd]
Aidil@The Zone: I am just stating that you cannot do it actively in a single execution round, and I was rather suggesting that keeping the last known state uptodate is how it must be solved.
Thu Apr 30 12:38:23 2009
[dgd]
Quixadhal@Bloodlines: I see. What I'm hoping for is something I can call that will force a recheck of the connected state, at which point a query_connected() done a few seconds later (YMMV) would be more-or-less accurate.
Thu Apr 30 12:40:04 2009
[dgd]
Aidil@The Zone: heh, why not simply have it do that check every minute or so, and if it fails for more then 2 times in a row, start a reconnect?
Thu Apr 30 12:40:36 2009
[dgd]
Aidil@The Zone: however, that doesn't at all answer why the connection status wasn't updated properly to begin with.
Thu Apr 30 12:41:15 2009
[dgd]
Aidil@The Zone: because, if the connection layer in lpc is implemented correctly, the situation you encountered simply cannot exist.
Thu Apr 30 12:42:53 2009
[dgd]
Quixadhal@Bloodlines: I suppose. It just seems like extra bandwidth use nowadays.
Thu Apr 30 12:45:20 2009
[dgd]
Aidil@The Zone: anyway, there is already a keepalive mechanism in the client, that can easily be extended to check on getting back something.
Thu Apr 30 12:45:23 2009
[dgd]
Quixadhal@Bloodlines: In my case, my ISP is usually pretty solid, so I probably lose connection about once a month due to weather/maintenance... but I know I drop at 6AM (local time) every Wedensday morning due to my firewall resetting (my choice).
Thu Apr 30 12:46:03 2009
[dgd]
Quixadhal@Bloodlines: I don't really need to send keepalive packets all the time, but being able to check and restart on a schedule would be handy.
Thu Apr 30 12:46:57 2009
[dgd]
Aidil@The Zone: you are discounting the fact that connection problems can occur anywhere between you and the router.
Thu Apr 30 12:47:42 2009
[dgd]
Aidil@The Zone: your situation really should be solved by fixing whatever is causing the connection loss from being ignored however.
Thu Apr 30 12:49:24 2009
[dgd]
Aidil@The Zone: see, this thing is happening at the router side a few times a day. Some mud somehow loses connection due to networking issues. I am quite sure this is detected properly at the router side the next time it tries to write data to that connection.
Thu Apr 30 12:50:22 2009
[dgd]
Quixadhal@Bloodlines: On a related note, what is the proper way to reconnect I3? destruct and update imud_d? a function in it?
Thu Apr 30 12:53:14 2009
[dgd]
Quixadhal@Bloodlines: Intermud: Unknown man page. Intermud: Unknown help topic. *grin*
Thu Apr 30 12:53:29 2009
[dgd]
Quixadhal@Bloodlines: I was looking for a command called I3, and not finding it. :)
Thu Apr 30 12:55:33 2009
[dgd]
Aidil@The Zone: heh. I have an about 2/3 finished cron alike daemon :)
Thu Apr 30 12:56:49 2009
[dgd]
Quixadhal@Bloodlines: For now, I can cheat and just write a perl script that logs me in, executes intermud restart at 6:05am, and disconnects.
Thu Apr 30 12:57:34 2009
[dgd]
Aidil@The Zone: or do that once and add a call_out with a 7*24*3600 delay? :)
Thu Apr 30 12:58:19 2009
[dgd]
Aidil@The Zone: or simply fix the keepalive thingy, since that also works when the connection issue is not on your side.
Thu Apr 30 12:59:58 2009
[dgd]
Aidil@The Zone: it causes some 200 bytes of network traffic/minute. yeah, it is bandwidth, but not so much that I'd worry about it on a payed per mb mobile connection, let alone on my 'unlimited' home connection :)
Thu Apr 30 13:00:08 2009
[dgd]
Quixadhal@Bloodlines: So, right now it tries to send something to my own mud, via the I3 network... the question is, how to recognize the response (or lack thereof)?
Thu Apr 30 13:00:51 2009
[dgd]
Aidil@The Zone: there is a function that handles receiving the packet. You write a timestamp there.
Thu Apr 30 13:01:38 2009
[dgd]
Aidil@The Zone: and in the function that sends out the keepalive, you check for the timestamp not being 0 (it will be the first time you send out a keepalive) and being less then 120 secs ago (or something like that)
Thu Apr 30 13:03:36 2009
[dgd]
Aidil@The Zone: also, the timestamp should be kept in a static variable
Thu Apr 30 13:03:46 2009
[dgd]
Quixadhal@Bloodlines: and update connected, as well as attempting a reconnect, if it's older.
Thu Apr 30 13:09:38 2009
[dgd]
Aidil@The Zone: that all said, checking why the connection loss doesn't get noticed as it should is on my todo list :)
Thu Apr 30 13:12:57 2009
[dgd]
Quixadhal@Bloodlines: First draft ready for testing.... if I go away for a bit, you'll know it doesn't work yet. :)
Thu Apr 30 13:24:56 2009
[dgd]
Quixadhal@Bloodlines: Apparently doing an update and "intermud restart" results in two imud_d's stomping around....
Thu Apr 30 13:25:37 2009
[dgd]
Quixadhal@Bloodlines: At least, the logs seemd to be showing double close and reconnect attempts until I did ye olde reboot.
Thu Apr 30 13:26:21 2009
[dgd]
Quixadhal@Bloodlines: Now... how to test a loss of network connection without bringing down my whol network.... :)
Thu Apr 30 13:28:49 2009
[dgd]
Quixadhal@Bloodlines: I guess I can do what I usually do and bounce the network briefly... shoulda run this on my VM so I could just unplug it's virtual network.
Thu Apr 30 14:23:43 2009
[dgd]
Quixadhal@Bloodlines: Hmmm, interesting... is open() in imud_d a callback from the network package's connect() function?
Thu Apr 30 14:40:28 2009
[dgd]
Aidil@GurbaHub: more accurately, it is a callback from dgd's network code. It isn't directly called by connect() in any way, it is called by the network layer when a connection is established, regardless of which side initialized that connection.
Thu Apr 30 14:40:39 2009
[dgd]
Quixadhal@Bloodlines: It apparently is NOT being called during reconnect(), as once that runs, it never actually gets a startup reply packet.
Thu Apr 30 14:41:32 2009
[dgd]
Aidil@GurbaHub: I am absolutely 100% sure that it does get called by the driver when a new connection is established.
Thu Apr 30 14:42:00 2009
[dgd]
Quixadhal@Bloodlines: It may be smart enough to restore the old one... in which case you wouldn't want open() called again....
Thu Apr 30 14:42:34 2009
[dgd]
Aidil@GurbaHub: however, the network module checks on if there is a connection object still.
Thu Apr 30 14:42:42 2009
[dgd]
Quixadhal@Bloodlines: smart enough, or dumb enough -- as in just reopening a new socket and attatching it to the old entry.
Thu Apr 30 14:42:47 2009
[dgd]
Aidil@GurbaHub: please see the close() function for dealign with that.
Thu Apr 30 14:43:48 2009
[dgd]
Quixadhal@Bloodlines: Yes, I am using close. It appears to re-establish a connection, but open() never gets called.
Thu Apr 30 14:44:14 2009
[dgd]
Aidil@GurbaHub: well, then something else in the lpc layer is preventing it from getting called.
Thu Apr 30 14:44:39 2009
[dgd]
Quixadhal@Bloodlines: Which means keepalive will promptly close() and call reconnect() again... I'm going to try manually re-sending the startup request packet to see if that works.
Thu Apr 30 14:44:43 2009
[dgd]
Aidil@GurbaHub: the driver calls open in /kernel/net/connection, which should then call the open function in imud_d
Thu Apr 30 14:45:06 2009
[dgd]
Quixadhal@Bloodlines: Clearly, it works on the first connect, or I wouldn't be here.
Thu Apr 30 14:46:33 2009
[dgd]
Aidil@GurbaHub: well, if open() wouldn't work on a reconnect then my i3 router would never work in the irn network.
Thu Apr 30 14:47:27 2009
[dgd]
Aidil@GurbaHub: so, something is preventing it from getting called. The most likely cause being that the connection object for the now broken connection still exists for some reason.
Thu Apr 30 14:50:37 2009
[dgd]
Quixadhal@Bloodlines: Hmmmm... is there any way I can check that from inside imud_d? connect appears to be called in void context, so there's no handle to it.
Thu Apr 30 14:53:47 2009
[dgd]
Aidil@Way of the Force: anyway.. from some looking around in the network code and a little experiment, it occurs to me the problem you have after flushing the tables on your firewall is that your firewall silently drops any outbound packets for connections it no longer knows about.
Thu Apr 30 14:55:10 2009
[dgd]
Quixadhal@Bloodlines: That's correct... it's a stateful NAT issue, so once the connection breaks, there isn't anything valid to use until it is re-opened from inside.
Thu Apr 30 14:55:13 2009
[dgd]
Aidil@Way of the Force: that behavior will prevent dgd from knowing about the connection being broken. It should at the very least reply with a connection reset, or reestablish the table entry and let the other side send a reset if needed.
Thu Apr 30 14:55:40 2009
[dgd]
Aidil@Way of the Force: imho that is a broken stateful nat implementation.
Thu Apr 30 14:56:05 2009
[dgd]
Aidil@Way of the Force: it will break many other protocols as well :P
Thu Apr 30 14:57:02 2009
[dgd]
Quixadhal@Bloodlines: How would you implement a NAT firewall that maintains (possibly invalid) states over a reset? You can't just assume the ip/port numbers on both sides will still match up when things go back online.
Thu Apr 30 14:57:46 2009
[dgd]
Aidil@Way of the Force: nope, so either your firewall reports that back with a connection reset, or you let the other side of the connection do this.
Thu Apr 30 14:58:25 2009
[dgd]
Aidil@Way of the Force: you are correct about not being able to both reset your state and have it persist at the same time obviously :)
Thu Apr 30 14:59:36 2009
[dgd]
Aidil@Way of the Force: thing is, if the port numbers don't match (which they most likely won't), the other side of the connection will tell your client about it.
Thu Apr 30 14:59:48 2009
[dgd]
Quixadhal@Bloodlines: Unfortunately, the firewall no longer has a list of former-clients to report closeure to.... but it would be nice.
Thu Apr 30 15:01:18 2009
[dgd]
Quixadhal@Bloodlines: I can tell you that most TCP stream sockets do close instantly when it resets... I can watch my IM clients, games, etc all go down in sync. I assumed lpc just doesn't know about it until it tries to send something.
Thu Apr 30 15:01:40 2009
[dgd]
Aidil@Way of the Force: all it needs to do is respond with a 'reset' to any tcp packets from your internal network that don't belong to an existing connection, and aren't an attempt to open one, or alternatively, it might just ignore the whole opening thing, and consider any outbound tcp packets to be an attempt to open a connection if none exists
Thu Apr 30 15:02:43 2009
[dgd]
Aidil@Way of the Force: thing is, you know once your descriptor for the connection becomes invalid, or you receive a signal.
Thu Apr 30 15:04:03 2009
[dgd]
Aidil@Way of the Force: at any rate, this all doesn't solve your open() issue :P
Thu Apr 30 15:05:56 2009
[dgd]
Quixadhal@Bloodlines: True... I'm thinking of trying a workaround of making open() do send_startup_req() and then setup the keepalive callout... and then having reconnect do a one-time callout to send_startup_req() to see if that will work. If so, then fixing open()'s behavior might be an idea.
Thu Apr 30 15:06:36 2009
[dgd]
Quixadhal@Bloodlines: Apply the band-aid, then look for the alcohol... :)
Thu Apr 30 15:07:42 2009
[dgd]
Quixadhal@Bloodlines: It's interesting that disconnect doesn't actualy destroy the connection object, but sets the state to disconnected.
Thu Apr 30 15:08:10 2009
[dgd]
Quixadhal@Bloodlines: I presume it only gets destructed when the daemon itself does?
Thu Apr 30 15:08:34 2009
[dgd]
Aidil@Way of the Force: hmm, I think disconnect() should destruct it.
Thu Apr 30 15:09:01 2009
[dgd]
Quixadhal@Bloodlines: Not in the version I have... it calls set_mode(MODE_DISCONNECT)
Thu Apr 30 15:09:42 2009
[dgd]
Quixadhal@Bloodlines: I would guess to give the driver a chance to send any remaining data?
Thu Apr 30 15:10:12 2009
[dgd]
Aidil@Way of the Force: no, that is handled by the driver itself, as I said before, the actual connection itself is asynchronous.
Thu Apr 30 15:10:23 2009
[dgd]
Aidil@Way of the Force: at least from the point of view of the lpc layer.
Thu Apr 30 15:10:58 2009
[dgd]
Aidil@Way of the Force: that set_mode thingy should get forwarded to the connection object, which then in one way or another should destruct itself.
Thu Apr 30 15:11:27 2009
[dgd]
Aidil@Way of the Force: it is very likely that somewhere in there the cause of this open() problem is to be found :P
Thu Apr 30 15:11:50 2009
[dgd]
Quixadhal@Bloodlines: Right, I don't know how it handles buffering between C and LPC, so I'm just guessing.... I'm gonna bounce and try my band-aid through. :)
Thu Apr 30 15:13:49 2009
[dgd]
Aidil@Way of the Force: I suspect your bandaid won't work because there is no new connection, but we'll see :)
Thu Apr 30 16:26:40 2009
[dgd]
Quixadhal@Bloodlines: I think the trick was that the connection couldn't be fully destructed, because the keepalive call_out still had a handle to it. Still learning this stuff, but the combination of things I poked at seems to have worked.
Thu Apr 30 16:51:41 2009
[dgd]
Quixadhal@Bloodlines: I suppose I should put the call_out times back to normal, so the router doesn't ban me. :)
Thu Apr 30 16:56:41 2009
[dgd]
Quixadhal@Bloodlines: Interestingly, if you do an "intermud stop" and then update imud_d, it restarts. Maybe a save/restore issue lurking somewhere....
Thu Apr 30 17:12:05 2009
[dgd]
Aidil@Way of the Force: well, intermud stop unloads it, updating imud_d will load it again and cause create() to be called.
Thu Apr 30 17:20:10 2009
[dgd]
Quixadhal@Bloodlines: So, you're saying I should have used call_out values of 0 instead of 10? :)
Fri May 1 18:12:18 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 213 to svn://wotf.org/gurbalib : Fix and some functional enhancements to the mudlist command (by Quixadhal)
Fri May 1 18:22:40 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 214 to svn://wotf.org/gurbalib : Change connection object to destruct itself on network errors
Fri May 1 18:25:10 2009
[dgd]
Aidil@GurbaDev2: going to commit the imud_d keepalive stuff later today.
Fri May 1 18:25:59 2009
[dgd]
Aidil@GurbaDev2: btw, Quixadhal, a while ago you were saying that a reversible explode() would be rather helpful for your ansi_d project.. see the rexplode() afun :)
Fri May 1 18:45:45 2009
[dgd]
Aidil@GurbaHub: so.. when is that driver of yours gonna be able to run gurba?
Fri May 1 19:34:45 2009
[dgd]
Silenus@Dead Souls Dev: oh good so he isnt sending encrypted messages to the Nazi's?
Fri May 1 20:39:44 2009
[dgd]
Aidil@GurbaDev2: gurba should be much easier to run.. you are allowed to cheat and turn off SYS_PERSIST :)
Fri May 1 20:40:24 2009
[dgd]
Kalinash@Fire and Ice: working on save/load_object() now... i want it to properly presist private values from inherited objects
Fri May 1 20:42:38 2009
[dgd]
Aidil@GurbaDev2: yeah, why support the real thing when you can support a cludge :P
Fri May 1 21:20:44 2009
[dgd]
Kalinash@Fire and Ice: let's just say pike isn't really designed to support state dumps
Fri May 1 22:49:34 2009
[dgd]
Quixadhal@Bloodlines lends Kalinash his C64 "freezer" cartridge for doing such snapshots...
Sat May 2 11:46:43 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 215 to svn://wotf.org/gurbalib : Fixed another situation in which connection objects didn't remove themselves on error, improved reconnect and keepalive handling in imud_d
Sat May 2 13:52:49 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 216 to svn://wotf.org/gurbalib : Move user and player object into /sys, stage 1. warmboot needed, you will be forced to reconnect after warmboot
Sat May 2 14:33:00 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 217 to svn://wotf.org/gurbalib : Some more improvements to connection handling and imud_d reconnects
Sat May 2 20:19:10 2009
[dgd]
Subversion@Way of the Force: Aidil committed Gurbalib revision 218 to svn://wotf.org/gurbalib : Another fix to the connection object (found yet another case where it wasn't destructed while it should be), changed imud_d to support automatic router failover
Sat May 2 20:23:26 2009
[dgd]
Aidil@GurbaDev2: also found that my router was sending more data then it should on connection startup.
Sat May 2 20:25:30 2009
[dgd]
Aidil@GurbaDev2: my router was already sending way less data then the DS based ones.. yet it turned out it was still sending way more then it should.
Mon May 4 17:57:43 2009
[dgd]
Raudhrskal@Dead Souls Dev: Did you know... The tips file cannot be found.
Mon May 4 18:03:14 2009
[dgd]
Quixadhal@Bloodlines: Hmmmm, maybe my ansi_d mods need more optimization.... dgd /hist runs out of ticks *grin*
Mon May 4 18:03:38 2009
[dgd]
Raudhrskal@Dead Souls Dev: one sec... does these / things are supposed to be emothes or sth?
Mon May 4 18:04:59 2009
[dgd]
Quixadhal@Bloodlines: Thankfully not, else I'd have to figure out how to escape them to say what I wanted.
Mon May 4 18:05:23 2009
[dgd]
Quixadhal@Bloodlines: There are already too many things to escape, just from using tinyfugue.
Mon May 4 18:06:12 2009
[dgd]
Raudhrskal@Dead Souls Dev: well, it's simple. if you need a / as first char, triple it.
Mon May 4 18:06:29 2009
[dgd]
Raudhrskal@Dead Souls Dev: i'm much more annoyed by seemingly random $ and \ expansionm
Mon May 4 18:08:27 2009
[dgd]
Raudhrskal@Dead Souls Dev: "No manual entry for woman" is still good, tho ;P
Mon May 4 18:10:55 2009
[dgd]
Raudhrskal@Dead Souls Dev: mmmaybe. i have to admit - i never ever watched 2001.
Mon May 4 18:11:32 2009
[dgd]
Quixadhal@Bloodlines: It's worth watching... I'd suggest twice, as the first time you'll have NO idea what's going on.
Mon May 4 18:12:08 2009
[dgd]
Quixadhal@Bloodlines: And don't be sleepy... it's not an action movie.
Mon May 4 18:12:15 2009
[dgd]
Raudhrskal@Dead Souls Dev: sure. it's just a matter of lack of time. i have around some movies i bought / borrowed / ripped years ago, and still haven't watched them.
Mon May 4 18:12:40 2009
[dgd]
Raudhrskal@Dead Souls Dev: i saw the sequel once, but i was a young kid and hadn't understood a %.
Mon May 4 18:14:43 2009
[dgd]
Quixadhal@Bloodlines: It's the kind of movie that will never be made again... Just the fact that the first 5 minutes is a black screen with classical music would scare off most of today's fruit-fly attention span people. ;)
Mon May 4 18:17:15 2009
[dgd]
Quixadhal@Bloodlines: There we go.... added a timestamp to the ACTIVE channel display
Mon May 4 18:17:33 2009
[dgd]
Quixadhal@Bloodlines: so I can tell when people said something without having to try and look up the history.
Mon May 4 18:18:23 2009
[dgd]
Quixadhal@Bloodlines: and that way, I can have tinyfugue /log it for future blackmail...errrr... reference.
Mon May 4 18:20:36 2009
[dgd]
Raudhrskal@Dead Souls Dev: well, i have logs enabled all of the time. Fact, lack of timestamping in DS realtime display is annoying. But we need to find a way to make it an user preference first.
Mon May 4 18:22:20 2009
[dgd]
Raudhrskal@Dead Souls Dev: well, that's the simple part. but chat_d does a mass-print atm, i think.
Mon May 4 18:22:40 2009
[dgd]
Raudhrskal@Dead Souls Dev: will need to make it a loop, or split the userlist by pref
Mon May 4 18:22:45 2009
[dgd]
Quixadhal@Bloodlines: Right, which is what channel_d does here... that's in the loop... specifically....
Mon May 4 18:22:59 2009
[dgd]
Quixadhal@Bloodlines: for( i = 0, sz = sizeof( users ); i < sz; i++ ) {
Mon May 4 18:23:17 2009
[dgd]
Raudhrskal@Dead Souls Dev: it's worse than that... iirc it uses message()...
Mon May 4 18:23:21 2009
[dgd]
Quixadhal@Bloodlines: ( users[i]->query_env( "imud_timestamp" ) ? "^CHAN_DATE^[" + (ctime(time())[11..18]) + "]^RESET^" : "" )
Mon May 4 18:23:48 2009
[dgd]
Quixadhal@Bloodlines: Sorry for the mess... there should be a nice way to send a multi-line chunk at once.
Mon May 4 18:25:15 2009
[dgd]
Raudhrskal@Dead Souls Dev: nah, cool. eventPrint(). also, this function dodes so much of computational cwap that one more pref check won't hurt much ;P
Mon May 4 18:26:59 2009
[dgd]
Quixadhal@Bloodlines: next on my hit-list is this horrible line wrapping at column 80, on my 125 column window, ignoring escape code translations I suspect.
Mon May 4 18:38:09 2009
[dgd]
Quixadhal@Bloodlines: Wow, doubly whammy.... dgd was wrapping at one value, and tinyfugue was wrapping at another.
Mon May 4 19:26:10 2009
[dgd]
Quixadhal@Bloodlines: Hmmmm, #ifdef doesn't work the way CPP's #ifdef does....
Mon May 4 19:29:16 2009
[dgd]
Quixadhal@Bloodlines: And /history should be an acceptable alias for /hist... for us old fogies who are used to t-y-p-i-n-g.
Mon May 4 19:31:26 2009
[dgd]
Quixadhal@Bloodlines: I do have to give VMS's DCL bonus points for the way they did alias commands.
Mon May 4 19:32:18 2009
[dgd]
Quixadhal@Bloodlines: alias dir*ectory = "whatever you want it to expand to", where the "dir" part is required and the rest is optional if non-ambiguous.
Mon May 4 19:32:57 2009
[dgd]
Aidil@Way of the Force: sure, and if you really want to, you can implement a very similar thing on gurbalib :)
Mon May 4 19:33:38 2009
[dgd]
Quixadhal@Bloodlines: Yes, but we'd need a unified command argument parser for it help with things like dgd /hist*ory. :)
Mon May 4 19:34:14 2009
[dgd]
Raudhrskal@Dead Souls Dev: best thing of the DCL parser was that you could very easily use it for your own app
Mon May 4 19:34:38 2009
[dgd]
Quixadhal@Bloodlines checks the unified command argument parser shelf, but doesn't see anything in stock.
Mon May 4 19:35:18 2009
[dgd]
Aidil@Way of the Force: but fiddling with commands and parse_string earlier made me want to create something.
Mon May 4 19:35:22 2009
[dgd]
Quixadhal@Bloodlines: I hated VMS when I was forced to use it at school... now I find I rather miss some of those features.
Mon May 4 19:36:13 2009
[dgd]
Raudhrskal@Dead Souls Dev: anyway, the DCL itself used the CLI$ API for the command matching part (as opposed to the "programmable shell" part).
Mon May 4 19:36:22 2009
[dgd]
Quixadhal@Bloodlines: I don't miss their help system though.... very handy if you knew what you wanted, but a nightmare to FIND anything.
Mon May 4 19:36:37 2009
[dgd]
Raudhrskal@Dead Souls Dev: thus, most of the VMS CLI progs has quite unified interface.
Mon May 4 19:37:20 2009
[dgd]
Quixadhal@Bloodlines: We printed the pascal documentation once... help pascal/*/*/*.... for about 13 levels.
Mon May 4 19:37:49 2009
[dgd]
Raudhrskal@Dead Souls Dev point to the VAX Pascal 7.3 Reference on the bookshelf.
Mon May 4 19:38:29 2009
[dgd]
Quixadhal@Bloodlines: Prior to our doing that a couple of times, students weren't allowed near the Orange Wall (VAX 5.x documentation).
Mon May 4 19:39:08 2009
[dgd]
Raudhrskal@Dead Souls Dev: hmm... i always saw and heard the term "gray wall"...
Mon May 4 19:39:10 2009
[dgd]
Quixadhal@Bloodlines: All the binders were orange... the next version was grey.
Mon May 4 19:39:43 2009
[dgd]
Raudhrskal@Dead Souls Dev: to paraphrase, "The [color] Wall of VMS Documentation was a beautiful, but, somehow, disturbing sight."
Mon May 4 19:40:25 2009
[dgd]
Quixadhal@Bloodlines: I believe it came shipped on a quarter-pallet all to itself.
Mon May 4 19:41:59 2009
[dgd]
Raudhrskal@Dead Souls Dev: well, i heard that if you have an empty 11/780 frame, the docs fill it exactly.
Mon May 4 19:42:39 2009
[dgd]
Raudhrskal@Dead Souls Dev: last orange stuff by dec i can think of were the DEC-20s.
Mon May 4 19:42:48 2009
[dgd]
Quixadhal@Bloodlines: Up until a few years ago, I still had a couple of orange ones.
Mon May 4 19:43:24 2009
[dgd]
Raudhrskal@Dead Souls Dev: Printed in USA? Or some kind of overseas redist?
Mon May 4 19:43:57 2009
[dgd]
Quixadhal@Bloodlines: When they upgraded to VMS 6.x (and got grey ones), they let some of us have the now out-of-date VMS 5.x ones.
Mon May 4 19:44:32 2009
[dgd]
Quixadhal@Bloodlines: Oh, sorry... version 4.x was orange.. 5.x was the grey ones. :)
Mon May 4 19:45:15 2009
[dgd]
Quixadhal@Bloodlines: According the ye olde internet, the ones for 3.x were blue.... never saw any of those.
Mon May 4 19:47:59 2009
[dgd]
Quixadhal@Bloodlines: So what colour should we put the Gurbalib docs in? :)
Mon May 4 19:48:42 2009
[dgd]
Quixadhal@Bloodlines: You walk up to a black wall of documentation. You feel yourself sinking into it.
Mon May 4 19:49:57 2009
[dgd]
Quixadhal@Bloodlines: Hehehehe, I wonder how hard it would be to write a google query tool in lpc?
Mon May 4 19:50:53 2009
[dgd]
Raudhrskal@Dead Souls Dev: ... what was that old joke doing in my pastebuffer? Sorry, anyway.
Mon May 4 19:51:03 2009
[dgd]
Quixadhal@Bloodlines: That would be more fun than "Man: Unknown man page." message.....
Mon May 4 19:51:44 2009
[dgd]
Raudhrskal@Dead Souls Dev: True, tho "no manual entry for woman" is slightly funny.
Mon May 4 19:52:13 2009
[dgd]
Quixadhal@Bloodlines: But just think how much more amusing the google results for "woman" would be? :)
Go to the top | Channel Index
