How to handle addon interference?
I am the maintainer of Skillet and it and Bagnon are interfering with each other. When both are enabled, either an error occurs (see below) or the player's bags won't open. Of course, disabling Skillet resolves the interference.
Error occured in: Global Count: 1 Message: ...\AddOns\Skillet\Libs\LibAbacus-3.0\LibAbacus-3.0.lua line 535: C stack overflow After looking at my code and looking at the issues submitted against Bagnon, I'm 99% convinced that this is a Bagnon issue (older versions work) and I don't know what I can do to Skillet to fix it. I have tried to contact the Bagnon authors with no success (there are 150+ open issues against Bagnon and none open against Skillet). I am however, getting tired of closing issues against Skillet. I'm considering adding code to Skillet to print a big red message when it discovers that Bagnon is also loaded (and perhaps also shutting down Skillet). Before I do anything this drastic, I thought I would ask for advice from this community first. What is the "politically correct" thing to do? In case anyone wants more details, see closed issues #533 and #545 at https://www.wowace.com/projects/skillet/issues |
Personally I would point out the incompatibilities and that you are trying to contact the developer of the other addon to resolve them but in the mean time users will have to decide on which addon is their preference, preferably stop using the other addon in favor of your own of course.
An alternative is to have a pop up YES/NO window come up when it is discovered that both are loaded and asks the question on whether to unload Skillet (YES) or Bagnon (NO) due to incompatibilities and unload the addon requested by the user. |
Weird. I have used both Skillet and Bagnon for years and never had issues with compatibility. I'm in game right now with the most recent versions of both (4.04 and 8.0.2 respectively) and they both work just fine.
After looking at both of those tickets, looking at LibAbacus, and a dump command, the issue is not Skillet or Bagnon. It's LibAbacus and the Ace2 compatibility it has at the bottom of its file. Autobar uses AceLibrary, PetCare overhauled their files but wasn't using Ace2 from what I can see, Broker_Portals uses AceLibrary, and so on. Everybody that has this issue has an addon that uses AceLibrary. This compatibility causes some sort of self-referential loop that somehow affects Bagnon. You can reproduce this issue by installing AceLibrary. |
Quote:
|
Quote:
It looks like the right answer is to replace LibAbacus-3.0 completely. Any suggestions for a suitable replacement? |
Given that Ace2 (and Rock) are super old and long dead, I would just delete everything below line 525 in LibAbacus-3.0.lua. That section's purpose is only to register with Ace2 and Rock. LibStub has been the standard for library tracking for several expansions and Abacus uses LibStub already.
|
Quote:
I'm going to solve the problem in Skillet by just copying the two functions Skillet uses and deleting references to LibAbacus-3.0. That doesn't solve Bagnon's problem but it will eliminate Skillet from the tracebacks. |
If you increase the version number at line 13, anyone with your addon installed will use your Abacus, effectively updating it. That's how libraries work, the most recent version loaded is served by LibStub, any other version is ignored, no matter what else is installed.
However, reorganizing Skillet to not use Abacus is probably the better answer. Edit: Nevermind, the library system only deals with the functions provided by the library, it won't fix the Ace2/Rock loop. My bad. |
Now I have a (hopefully) stupid question. I removed all references to LibAbacus-3.0 from the code, the .toc, and the .pkgmeta but after updating the SVN, the Wowace packager included LibAbacus-3.0 anyway.
What did I miss? |
You also have to remove LibAbacus from Wowace's relations, the serverside part of the packager process.
https://www.wowace.com/projects/skil...ault-relations |
Quote:
|
On the page I linked, there's a little trashcan icon above each relation.
|
You may have a little trashcan icon but I don't. I'm not the "owner" of the project, just the "maintainer". The "owner", Yossa, hasn't been active on Skillet for years.
|
It seems really bizarre that just using AceLibrary causes this conflict. Removing that from AutoBar is going to be a massive pain.
|
Quote:
LibAbacus-3.0 was last updated in 2012 (last released version 2008). The chances are slim to none that a bug in LibAbacus-3.0 is going to be fixed. It is such a simple library that I was able to eliminate the need for it in Skillet in less than an hour. Unfortunately, I can't say the same for the packager. It is beginning to look like I'll have to abandon Skillet and recreate it as Skillet2 because I can't get the packager to remove LibAbacus-3.0 from the Skillet package. The "owner" of the project hasn't been active on the project for years now and only pops up when I attempt to take ownership away from him. Getting a response from CurseForge or WowAce development is equally difficult. |
AutoBar doesn't use LibAbacus, so I'm not sure what's going on. I want to remove all of the Ace2 stuff anyway, but it'll be a big job. I have removed a fair bit.
|
I had another look at one of the stack traces and there is no actual AutoBar code in it (stack trace follows). It's just erroring out in AutoBar's copy of CallbackHandler which is newer than the one that seems to ship with Bagnon.
Could there have been a breaking change in CallbackHandler and Bagnon isn't handling it? Code:
2x ...Bar\libs\CallBackHandler-1.0\CallbackHandler-1.0-7.lua:51: [string "safecall Dispatcher[5]"]:1: chunk has too many syntax levels |
I don't know but the Bagnon authors are MIA (and have been for a long time if over 150 open issues is any indication).
If something is messing with the call stack who knows who is going to be blamed when things blow up. All I know is that my client is happiest when Bagnon isn't loaded. |
Quote:
This is the offending code block in LibAbacus-3.0.lua causing the error between Skillet and Bagnon: Lua Code:
AceLibrary just existing is what triggers the code, but we don't know why Bagnon causes the C stack overflow loop. I have noted two lines with the original line numbers. The loop is between these two according to posted errors. |
Quote:
|
All times are GMT -6. The time now is 03:58 AM. |
vBulletin © 2024, Jelsoft Enterprises Ltd
© 2004 - 2022 MMOUI