Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Entire forum
➜ MUSHclient
➜ Bug reports
➜ relative paths cause global plugins to load twice
relative paths cause global plugins to load twice
|
Posting of new messages is disabled at present.
Refresh page
Posted by
| Tspivey
Canada (54 posts) Bio
|
Date
| Thu 09 Jun 2011 07:58 AM (UTC) |
Message
| I'm trying to create a portable MUSHclient with some global
plugins pre-loaded, so someone can just download and
run, then start creating worlds, and have it talk without doing anything else.
The problem comes when I try to turn the global plugin from an absolute path to a relative one. Here's what I'm doing:
1. Add a plugin, using omit_blank_lines as an example, to the global plugins list. Once done,
this turns into an absolute path, which I don't want.
2. Close mushclient, dump mushclient_prefs.sqlite, and change the PluginList preference to load
".\worlds\plugins\omit_blank_lines.xml".
load it back in, and restart mushclient. Checking the global plugins list,
it says .\worlds\plugins\omit_blank_lines.xml - so far so good.
3. Create a new world, and save it. This also works fine.
4. close the world, and open it again. This time, I get an error that says omit_blank_lines
is already loaded.
Looking at the .mcl, the plugin shows up in the plugins section when I use a relative path for the global plugin,
but not when I leave it alone. | Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) Bio
Forum Administrator |
Date
| Reply #1 on Thu 09 Jun 2011 09:54 AM (UTC) |
Message
| What is your preferred solution here?
- Comparing plugins for working out whether to load a global plugin compared to a local plugin, should both use absolute paths? OR
- Attempting to load a plugin which is already loaded should silently fail (ie. do nothing, the plugin is already there).
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Fiendish
USA (2,533 posts) Bio
Global Moderator |
Date
| Reply #2 on Thu 09 Jun 2011 09:21 PM (UTC) Amended on Thu 09 Jun 2011 09:23 PM (UTC) by Fiendish
|
Message
| |
Posted by
| Nick Gammon
Australia (23,122 posts) Bio
Forum Administrator |
Date
| Reply #3 on Fri 10 Jun 2011 12:27 AM (UTC) |
Message
| Looking at the code Fiendish it's not particularly simple. By the time we get to discovering the plugin IDs are the same we are half-way through creating it, memory allocated etc.
But I suppose if the duplicate ID can undo all that, it should be able do undo it without the error message. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,122 posts) Bio
Forum Administrator |
Date
| Reply #4 on Fri 10 Jun 2011 04:20 AM (UTC) Amended on Fri 10 Jun 2011 04:21 AM (UTC) by Nick Gammon
|
Message
| Allowing plugins of the same name to silently be discarded was too much complicated work. Plus I don't like the idea. It's like having if you delete a file, and if the file does not exist, not getting an error message. I suppose the end result is the file isn't there, but attempting to delete a non-existent file in the first place should be an error.
Fixed the reported problem here in version 4.74 by tightening up the check for whether plugin A is the same as plugin B by converting both pathnames to absolute pathnames internally. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Fiendish
USA (2,533 posts) Bio
Global Moderator |
Date
| Reply #5 on Fri 10 Jun 2011 05:48 AM (UTC) Amended on Fri 10 Jun 2011 06:24 AM (UTC) by Fiendish
|
Message
|
Quote: It's like having if you delete a file, and if the file does not exist, not getting an error message.
It seems like this depends on perspective. From a consequentialist viewpoint, if I call a deleteFile function, very probably all I care about is that the file doesn't exist after the function call. I don't care about the state of the file before the function call. It serves me better for the function to be a no-op if it doesn't exist in the first place than to blast an error at me because my desire is only to have the file not be there. At least function calls tend to return error codes that you can then choose to ignore, which is not the case here. |
https://github.com/fiendish/aardwolfclientpackage | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
17,816 views.
Posting of new messages is disabled at present.
Refresh page
top