Authors CurseForge

I reakky found it useful. and before reinveinting the wheel i'd like to know it there are plans to reimplement it in Ace3

What is the chances that Alar would implement his own ScheduleLeaveCombatAction() function wrapper for the simple code above by Tekkub in his library?

P.S. Don't do it.
P.S.2 You should hop on #wowace IRC channel, your code is well known to be bad and inefficient beyond belief to the point of being a legend.

Quote from tekkub »

Hey now be nice!

Industrial's done much worse, I think I'm pretty nice already hehe.

But yes, the majority of the people would definitely help and point out all the things that can be improved.

Posting in an almost legendary thread ftw. :)

But yeah take Tekkub's advice. Code it yourself, it's pure fluff. Which is what most of your library is about btw Alar. Wrappers around every function in existance. Hop on #wowace, and wear your asbestos suit and sunglasses :)

-Ammo

Quote from Ammo »

Posting in an almost legendary thread ftw. :)

But yeah take Tekkub's advice. Code it yourself, it's pure fluff. Which is what most of your library is about btw Alar. Wrappers around every function in existance. Hop on #wowace, and wear your asbestos suit and sunglasses :)

-Ammo

Wow, never thought about me as a legend... :)
Seriously, I am glad you have so much spare time to review a clearly marked "private" library to check its code. I mean, while you were at it you could read the description: "General library for Alar's modules. Internal use."
Honestly, if I choose to have the majority of the code inside a library instead in the addon core, I think it should be my business and business of people using them.
It's not "maybe be useful at some point in time to someone, somewhere"- It's "I need it (or, I needed it and not yet removed the dead code)" and "If it works, dont fix it". I will rewrite it from scratch somewhen, but it will still be "for internal use" and done to make things easier just for me.
If someone else is only thinking about using AlarLib he's a fool :D
There is no fucking reason to use it if you are not Alar. I dont use it for new projects, too!

Last but not least, I'd like for sure joining #wowace but even if I can afford english OR technicalia OR chat slang, i cant afford all of them together.
As you probably guessed, my english is far less than good, and as far as I know I am the only italian guy programming addon. This doesnt help sharing of ideas and knowledge, not to say all documentation is in a foreign language for me

The only reason why people review your library and addons is because the commit notes you put in there are hilarious, and show a lack of understanding of the wow addon events and addon system, as well as a non-intimate knowledge of Lua itself.

A famous example is when you renamed your library from !AlarLib to AlarLib (why did it have a ! in front in the first place when you can just optdep it? Addon loading order is based on file system, it is only on a NTFS harddisk that loads addons in alphabetical order, FAT32 disks certainly don't.)

Another example is when you put in coroutine wrappers. If you're going to use something in an addon, do it directly in the addon. Don't put it in a library, and then include the library in the addon, and that addon is the one and only addon that would ever use that something and that library.

Adding all these wrapper functions add to memory usage, CPU usage and in the overall scheme of things, what wowace does not want to see - inefficient code - written in the rules or whatever in the signups for a SVN account.

Fact is, addon authors tend to review each other's code on wowace, to improve each other's addons, help to fix each other's addons. Wowace is a community. Reading each other's code also helps to improve Lua and/or find/learn new ideas and coding techniques.

Everyone is willing to help, but you have to take a first step and enter the community, and ask about anything you don't know, or if something can be done in a better way.

The wowace channel has a bot that reports every commit made to the wowace SVN, so errors, bad commits, commits that break addons, etc can be checked over and corrected within minutes.

Quote from Xinhuan »

A famous example is when you renamed your library from !AlarLib to AlarLib (why did it have a ! in front in the first place when you can just optdep it? Addon loading order is based on file system, it is only on a NTFS harddisk that loads addons in alphabetical order, FAT32 disks certainly don't.)

I agree. it was a mistake. Who is without sin throw the first stone

Quote from Xinhuan »

Another example is when you put in coroutine wrappers. If you're going to use something in an addon, do it directly in the addon. Don't put it in a library, and then include the library in the addon, and that addon is the one and only addon that would ever use that something and that library.

Code could be in a lot of places, as long it's not duplicated (and my library is only loaded once even if 4 addons use it. Every addon store pointers to function in the single library istance. It's embedded, even if not (yet) in the standard way).
If i feel more confortable with a (in my opinion) more consistent interface for coroutines, just to be sure I dont mess with timers and events, why does it disturb you? Is the code in the wrapper wrong? Does it make bad things to the shared memory or badly affect the garbage colledtor? I dont think, cause it just store pointers to couroutines and set up a simpler way to stop and restart them. If you could point something actually not working as intended or adding lag instead of just the theory against wrappers, it could help me more.
Inside AlarBGHelper coroutine wrappers are called just once at loading (CREATE), and on request when the user enters(START) or leaves (PAUSE) a battleground. A battleground lasts in the range of 10-70 minutes.
So we could have a worst case of 2 call every 10 minutes. I think in this case easier to read and use code is better than optimized code. Do the paused corotines use so much memory to make a problem? This could be an issue I underestimated

Quote from tekkub »

The main reason it was brought up is because you load all that code in every addon that uses it, which is usually a bad thing. A good chunk of it is redundant, especially if you're using the ace libs. It's kinda assumed (though not required) that if you're submitting to ace's svn you're using the ace libs.

Tekkub, I didnt wrote AlarLib to interface Ace2. I had AlarLib as a mix between a framework and a standalone soubroutine collection. When I moved to Ace2, i hadnt the time to rewrote all code, so i slammed Ace2 inside Alarlib primarly to use AceDb, AceEvent and AceHooks. The result is quite a mess, but it works and once loaded my addons performs quite well (AlarBgHelper is used by a couple of thousands of people, so I assume it doesnt destroy their PC :) )
So if you want take AlarLib as the "How not code new libraries example", you are welcome. But making assumption on my mental health from it is not correct :D
Btw... going to sleep, past midnight in my timezone

Quote from tekkub »

I never made assumptions about your mental health. As I said way up there ^... you needed to brace yourself for what we were about to say. This is all constructive feedback you're getting here, because we thought (hoped?) you are open to it for the betterment of your code.

Just to make things clear.. you are probably both underestimating my coding ability and overestimating my english understanding :D
For example, I have no clue about what "brace yourself" mean.
I am open for improvement and criticism, but not when criticism is beating a dead horse. AlarLib-2.0 is a compatibility layer. It's not there to stay. If you are willing to spend some time helping me you should do it in AlarLib.3.0 (in branches now) where I am moving things from AlarLib-2.0 trying to both remove what is no longer needed and clean what i think is still need. Just remember you are talking about code for private use. In now way I assume someone could ever use it besides me.
I do like wrapping, but i try to keep it where it doesnt get executed a lot of times. Main use is for intialization routines, where I think faster coding is superior to optimized coding.

Quote from tekkub »

Yes, we are criticizing your code. We're not doing it to spite you, we want to help make it better. If you don't want us to, just say so and we'll stop.

Uhm... I thin you know that ScheduleLeaveCombatAction was doing far more than

function someaddon:PLAYER_REGEN_ENABLED()
 -- Do the crap you want when leaving combat
 self:UnregisterEvent("PLAYER_REGEN_ENABLED")
end

and that your snippet does a totally different thing. So your answer looked more a way to make me look stupid (or iust more stupid than I am) than a constructive feedback. Reading it with my eyes,, are yiu sure you had found it a "constructive feedback"?
peace and love

If you read AceEvent-2.0 code, you would know that all ScheduleLeaveCombatAction() does is register a function to callback your registered function when PLAYER_REGEN_ENABLED is fired. If the player isn't in combat in the first place, then the function gets called right away, instead of "storing it" until PLAYER_REGEN_ENABLED arrives.

That's all it really does. Its just a fancy wrapper for what Tekkub wrote.

Perhaps he isnt talking about what the function "does" in the literal sense.

Poor guy.

Quote from Xinhuan »

If you read AceEvent-2.0 code, you would know that all ScheduleLeaveCombatAction() does is register a function to callback your registered function when PLAYER_REGEN_ENABLED is fired. If the player isn't in combat in the first place, then the function gets called right away, instead of "storing it" until PLAYER_REGEN_ENABLED arrives.

That's all it really does. Its just a fancy wrapper for what Tekkub wrote.

When I started using internet it was in black and white. Literally. We used Lynx and we paid for every byte we downloaded. So you will not make me to post here 60 lines of ScheduleLeaveCombatAction(). It's just against my nature ;_) .
Besides what you said ScheduleLEavCombatAction maintain a register of actions to be run, each one with its parameters so you can forget all details and just wrap it around for example the change of a flag who affect combat related things.
Besides that, I bet that if I just wrote a new ScheduleLeaveCombatAction and then it was added to AceEvent-3.0 you'd say "Why are you wrapping/recoding it?" :D