Central Forums Helpbot
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
Pages: [1]   Go Down
Print
Topic: Precompiled plugins  (Read 15109 times)
« on: October 09, 2007, 09:16:22 AM »
Freshman

View Profile
*

Epeen: 1
Posts: 26


Hi,

I'm trying to get Vhabot working on a slug (Linksys NSLU2) running Debian.  This is a 266MHz ARM processor with 32 MB RAM, which is a slightly low spec, but I don't expect it to be a very busy bot.

It seems to me that the point when the bot is using the most RAM is while compiling the plugins (gmcs) during startup.  This creates mad swap thrashing, and makes startup take slightly over 5 minutes, which again seems to trigger a bug in the "pinged for 5 minutes" check, making it spam the following message over and over:

Code:
[12:02:57 PM] [Core] shopnet@atlantean hasn't pinged for over 5 minutes
[12:02:58 PM] [Core] Closed previous running process of shopnet@atlantean
[12:02:58 PM] [Core] Starting shopnet@atlantean
[12:02:59 PM] [Core] shopnet@atlantean hasn't pinged for over 5 minutes
[12:03:01 PM] [Core] Closed previous running process of shopnet@atlantean
[12:03:01 PM] [Core] Starting shopnet@atlantean
[12:03:02 PM] [Core] shopnet@atlantean hasn't pinged for over 5 minutes
[12:03:03 PM] [Core] Closed previous running process of shopnet@atlantean
[12:03:03 PM] [Core] Starting shopnet@atlantean
[12:03:04 PM] [Core] shopnet@atlantean hasn't pinged for over 5 minutes
[12:03:09 PM] [Core] Closed previous running process of shopnet@atlantean

In addition to this small bug, it would be nice for me if the bot startup time was like 1 minute instead of 5.

Ideally, I'd like to compile the plugins on my main computer and then copy the resulting dll over to the slug.

(I tried making a wrapper script for gmcs to turn all "/optimize" into "/optimize-", but it didn't seem to have enough of an effect on the compile time, and anyway, optimizations are nice when running on a slow rig).
Logged
« Reply #1 on: October 09, 2007, 09:57:26 AM »
Grandmaster

View Profile
**

Epeen: 20
Posts: 3218


If I remember it correctly, the current version also scans for compiled plugins.
So if you would be able to compile all plugins and put the dll in the plugins dir, it should do the trick.
What isn't remembered never happened.
Memory is merely a record.
You just need to rewrite that record.
Logged
« Reply #2 on: October 09, 2007, 10:06:58 AM »
Freshman

View Profile
*

Epeen: 1
Posts: 26


Nice.  Would this be one file per plugin, like "vh_Items.dll"?
Logged
« Reply #3 on: October 09, 2007, 10:33:39 AM »
Grandmaster

View Profile
**

Epeen: 20
Posts: 3218


1 file per prefix, or just 1 big file.
so all vh_* together, all raid_* together, etc.
but putting em all in the same assembly works fine aswell (if not better)
What isn't remembered never happened.
Memory is merely a record.
You just need to rewrite that record.
Logged
« Reply #4 on: October 09, 2007, 10:57:27 AM »
Freshman

View Profile
*

Epeen: 1
Posts: 26


Yeah, I had just figured that out.  Big file is easiest, since I don't have to learn how to use gmcs that way.

What I did:

1. Capture the gmcs command line from "ps x | grep gmcs" when the bot is starting up.
2. Run it myself (on the faster computer), and name the output something more memorable.
3. Move the .cs files away from the plugins directory.
4. copy the output file from #2 into the plugins directory.

(I'm not sure #3 is really necessary, but I did it to make sure that the precompiled one was actually being used).

FC seems to have taken the logon/chat servers down for 17.6 patching atm, but I got the plugins loaded and got up to "Connecting" in about a minute on the slow box.

Guess I should figure out how to automate this process in some reasonable way (to handle updates and extra plugins), but that's more work than I think I'll get away with doing while slacking off at work. Grin
Logged
« Reply #5 on: November 05, 2007, 08:16:07 AM »
Novice

View Profile
****

Epeen: 3
Posts: 481


If it's really useful, I can keep an updated .dll of the plugins if I make any changes.

I noticed that being in dll form, it seems to load faster.

Only would do this if people actually want it though. No point if no one will use it. Tongue
----------------------------------------------------------
Sex is like hacking. You get in, you get out, and you hope you didn't leave something behind that can be traced back to you.
----------------------------------------------------------
Naturalistic - RK 1 220 Doctor

Campalot Coder and Superadmin
Logged
« Reply #6 on: November 05, 2007, 10:08:29 AM »
Grandmaster

View Profile
**

Epeen: 20
Posts: 3218


Yep, in dll form it loads faster.
But it also means you have to recompile it yourself after making changes.
The first versions of VhaBot used compiled plugins only, but the on-demand-compiling was added as a feature to aid developers.
I think it makes plugin development alot more inviting if you can just edit/reboot/test/repeat instead of adding another few steps like compile/shutdown bot/copy dll/start bot.
What isn't remembered never happened.
Memory is merely a record.
You just need to rewrite that record.
Logged
« Reply #7 on: November 23, 2007, 10:23:25 PM »
Noob

View Profile


Epeen: 0
Posts: 16


Of course, even nicer would be to drop changes into the plugins folder and have them automatically loaded. Even if it only handled assemblies that way, it would be a significant development improvement. :-)

Doug
Logged
« Reply #8 on: November 24, 2007, 11:32:08 AM »
Grandmaster

View Profile
**

Epeen: 20
Posts: 3218


Well, there is a problem with that. .NET doesn't allow unloading of assemblies.
The way around this is isolating plugins within an application domain and unload the entire domain.
However, this is troublesome to code and application domains don't always play nice. (VhaBot used to isolate bots with application domains).
Communication between domains is similar to that between remoting channels, so it involves serializing data/calls, unserializing on the other side, etc.
Eitherway, an implementation like that would still require some sort of restart at some level to accomplish, so it isn't that much different. However, what I think that could be done is adding an "auto restart on plugin changes".
Also, note for compiled plugins, they are locked at runtime, so you can't overwrite those. (unless we again start using application domains and enable shadow copying).

Overall, I don't see a realistic implementation like that being done within a realistic timeframe without too much rewriting.

ps. dharber: did get your pm, just still need to reply to it Tongue
What isn't remembered never happened.
Memory is merely a record.
You just need to rewrite that record.
Logged
« Reply #9 on: January 09, 2008, 01:41:43 AM »
Noob

View Profile


Epeen: 0
Posts: 4


can we get some infos on how good the bot is running on a slug?
Logged
Pages: [1]   Go Up
Print
Jump to: