Authors CurseForge

Hi!

Browsing the forums I've found the information that LibParser-4.0 replaces the functionality of both Parser-3.0 and ParserLib, so that I could delete these two and still have everything working as expected. I tried it and was amazed that it actually worked!

So, my question is: which other LibStub and/or Rock-derived libraries are direct drop-in replacements of Ace2 ones? In other words, could someone please be so kind as to provide a list of which Ace2 libraries I can delete so as to speed up even more my loading times?

Thanks!

There are no "direct drop-in replacements" for AceLibrary-based libraries, it's not possible.

So, Parser-3.0 and ParserLib aren't Ace-based libraries? That's why LibParser-4.0 can provide their functionality to the addons that require them but aren't themselves aware of LibParser-4.0?

Parser does weird ass-backwards stuff to try to impose itsself onto the old libraries...

The way the whole library system is designed is so that if I write an addon for "LibX-y.z" I have to have THAT EXACT LIB present to run. The addon was not written for and tested on a newer lib. If a newer lib exists that has a different name (different major version), the reason it has a different name is it broke compatibility with the old version.

Bumping a major version due to API breaking, and maintaining backwards compatibility are polar opposites. What parser does is, well, basically a hack to circumvent that whole design. In the grand scheme of things, you don't need to worry about this shit. Run the libs your addons require, plain and simple. As addons migrate to newer libs, the older ones will fall out of use.

Thanks for the explanation. I already knew that, but it's a good reminder anyway!

However, while agree on principle that I don't need to worry about these things, the matter of fact is that I do. I'm what you might call a "power user": not interested enough to dwell into programming, but also not uninterested enough to not care what files are in my system. In other words, I'm the kind of guy who, in the old good times of DOS, used to fine-tune EMM386.EXE to free 210 additional bytes of conventional memory. Who in Windows loves to optimize performance by changing registry entries by hand (without a backup, of course). Who in Linux goes around deleting unused locales (something I also do with WoW addons), disabling services, compiling custom kernels etc. so that 2 MB or RAM are freed up and the booting get shortened by 2.5 seconds. Who, when experiencing difficulties with a SMTP server, opens a telnet session and see what I can get by issuing SMTP commands by hand. And so on and so forth. In other words: what I'm asking for is something akin to an "Advanced Ace/Rock/Dongle User's Guide: Libraries and dependencies for the power user" HOWTO. Why? Just because it's fun! :D

Now, if you come and tell me LibParser-4.0 is the only library with this built-in backward compatibility code, I'll stop looking. But I hope it isn't. Over-optimizing to the point of near breakage is too cool a hobby for one to just give up on it. ;)

Parser's the only one I know of that does.

Programming with embed, having been thru the breaking of my addons many times over because of botched libraries... I don't ever want someone screwing with trying to shove a different major version into my addon. If I ask for LibX-y.z, by fuck I want to receive LibX-y.z.

It's usually not a painfully hard thing migrating an addon to a new major, in fact most of the work is TESTING... which is something you you really can't cover every case with with backwards-compat... something always ends up breaking. While BC is nice in lots of cases, it's really not needed here where the addon author is providing the embed he needs.

You want something to do to help the situation and to tweak? Find those addons you have that are running a lib you want to replace, change it over to use that lib, and send a patch to the author!

With growing dispersion, i.e. new frameworks, new and old mods mixed together this problem will continue to grow. I got all three parserlibs and apparently different mods are using them so I cant remove any.

But as long as I don't have any problems I'm ok. But it feels a bit like "dll hell" in Windows. ;)

Quote from Buio »

With growing dispersion, i.e. new frameworks, new and old mods mixed together this problem will continue to grow. I got all three parserlibs and apparently different mods are using them so I cant remove any.

Actually, you can remove ParserLib and Parser-3.0, keep only LibParser-4.0, and still have everything working. That's the whole point I'm making: to know all cases (besides the Parsers one) where we can delete apparently needed libraries all the while not breaking anything in the process.

While there is no explicit way of doing this, I find this quite interesting, it could cut back on the duplicate (with this I mean same libraries, though different version - Ace2 version/Rock version) libraries used.

Quote from alexgieg »

Actually, you can remove ParserLib and Parser-3.0, keep only LibParser-4.0, and still have everything working.

Ah, so it contains full backwards compability. Well deleted both "old" libs and tested very briefly and it seemed ok. But running WAU added both libs back due to found dependency. Aloft -> Parser-3.0 and BigBrother -> ParserLib (I guess these are just the two first found).

It would be nice to clean up libs. I got more libs than mods currently, and I got a lot of mods. And I have cleaned up redundant libs previously.

I think something like a "X-Provides:" line in the TOC would be a nice solution. I mean, something like the way Debian packages work, in that if a package needs another it can either specify a specific implementation ("firefox"), or a generic one ("webbrowser").

If we consider that an Ace/Rock/etc-based library isn't just a set of functions, but also the specification for a set of functions, nothing prevents multiple alternative implementations. You'd have the original specification, which would just happen to also be its own very first implementation ("the code as its own documentation"), but also any number of alternative implementations.

This way, LibParser-4.0 would be able to explicitly tell WAU that it provides the ParserLib and Parser-3.0 "protocols", and from this have a "Give preference to libraries that provide multiple protocols" option, which would delete (and keep deleted) single implementations. Something like that.

I would really like that idea to get implemented somehow. There is atool to tell you which addon uses which libraries, but with the x-embeds it doesn't work that well, I've tried. My only option is to delete all libs, go into the game and read BugSack :P

For some odd reason if I get rid of either SharedMedia lib i end loosing my textures for everything :( So I suppose I'm doing something wrong I just don't know about yet.

I've been also using "Manage & view my Addons" for a little while.
http://www.wowinterface.com/downloads/info7042-ManageviewmyAddons.html

there's a few kinks but it works for the most part, letting you know what's attached to what addon. I found I could turn off GloryLib if I'm not going to battlegrounds - yes I'm sure most knew that.

Old thread, but now with LibMobHealth-4.0 and Pitbull support for it, I also removed the old Mobhealth mod. Maybe some other mod like Aloft might use old Mobhealth but don't need it there. Yeah, its not a rock lib either, just a lib.

Regarding LibMobhealth-4.0, I prefer saved variables. My old mobhealth sv wasn't big at all despite going throught a lot of mobs.

Edit: Maybe should have done a separate thread instead. Ah well. Anyway, I found a "bug" with the conversion of Mobhealth 3 data. All bosses are recorded as lvl -1 and none got converted to LibMobHealth-4.0 data.

As ElkBuffbars now use LibSharedMedia-3.0, I now have 3 libs for shared media and I cant remove any of them.

Btw, this hasn't anything to do with Rock but it was discussed here earlier so saw no reason to start a new thread.