I can see why it was removed, it's basically pure fluff...
function someaddon:PLAYER_REGEN_ENABLED()
-- Do the crap you want when leaving combat
self:UnregisterEvent("PLAYER_REGEN_ENABLED")
end
All you have to do is register for PLAYER_REGEN_ENABLED where you would have called ScheduleLeaveCombatAction. You still have to create a function for it to call in either design, so why is ScheduleLeaveCombatAction needed at all?
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.
Hey now be nice! What what the fuck am I saying I'm never nice.
Seriously tho, alar, you should hop on IRC and listen to people's advice... just be prepared for a lot of it, those of us that have looked at your library... well... Let me put it this way, your library is like the borg, it assimilates every idea it comes across that appears to maybe be useful at some point in time to someone, somewhere.
People are willing to help, just be prepared for it, because it's not going to be pretty. And don't take it personally, bad shit always happens when people take things personally...
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 :)
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
Well, it's more like "infamous" than "legendary"... #wowace isn't that bad, if you ignore all the whiney bitchy users. I'm happy to hear you don't use the lib in your new stuff, and well, we don't really exactly "check" your code there... it's more of a thing to point at and say "don't do that!"
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. Besides that, submitting into the svn is usually a sign that you're part of this community and want feedback from the other devs here. We all help each other out with improvements, or even just a smack upside the head to tell you "don't do that!"
And I think it's safe to say that noone else uses your lib *grin*.
You should still hop on #wowace. A good portion of the devs there are not english-native, and they're all there to help each other out, and get help in return.
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.
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
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
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.
If alarlib was both standalone (not embed) and a transition to using Ace2, while I didn't know, but I understand. Just understand that I've opened many an addon where the Ace2 libs are used so poorly, it actually makes things worse. Or they're embedded and never used... or embedded just to use one simple tiny function out of the whole big thing... or... you get my point.
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.
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.
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
Alar, I think you are holding up well. Multiple people already gave the warning signs that things can be very blunt.
You have to understand that there is a certain culture among some people around here that like pecking and adversity for some reason. But there are also people out there that'll be very welcoming and open to things.
And in general the vast majority of people are very helpful once you get to know them better and understand how they tick (and what ticks them off).
In either case I agree that #wowace is very helpful once you manage to assert yourself and develop a filter for stuff that happens that isn't helpful to you. Also people will get to know you which helps a lot.
The reason why some folks are a tad harsh already is basically because you unwittingly are hitting some hot-button issues for some people.
Specifically:
*) Code beauty
*) Code reuse
*) Code that hides detail and is easy to code
aren't categories that some will accept as important and certainly not as categories that trump code size and code efficiency arguments.
The question of what should be in a library is hostly debated and in general, if in doubt a library will nowadays not carry a feature than carry it.
But if you can make a good use case for some things there is a chance that you'll find an ear for it. Still because code reuse isn't a hot commodity, reinventing the wheel happens a good bit (which is very educational though if you have the time).
Once you understand that better it's easier to take all the good feedback that is to be had and develop the cognitive filter for other stuff (I recommend the pink heart-shaped glasses for this purpose).
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
All you have to do is register for PLAYER_REGEN_ENABLED where you would have called ScheduleLeaveCombatAction. You still have to create a function for it to call in either design, so why is ScheduleLeaveCombatAction needed at all?
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.
Seriously tho, alar, you should hop on IRC and listen to people's advice... just be prepared for a lot of it, those of us that have looked at your library... well... Let me put it this way, your library is like the borg, it assimilates every idea it comes across that appears to maybe be useful at some point in time to someone, somewhere.
People are willing to help, just be prepared for it, because it's not going to be pretty. And don't take it personally, bad shit always happens when people take things personally...
But yes, the majority of the people would definitely help and point out all the things that can be improved.
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 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. Besides that, submitting into the svn is usually a sign that you're part of this community and want feedback from the other devs here. We all help each other out with improvements, or even just a smack upside the head to tell you "don't do that!"
And I think it's safe to say that noone else uses your lib *grin*.
You should still hop on #wowace. A good portion of the devs there are not english-native, and they're all there to help each other out, and get help in return.
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.
I agree. it was a mistake. Who is without sin throw the first stone
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
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
If alarlib was both standalone (not embed) and a transition to using Ace2, while I didn't know, but I understand. Just understand that I've opened many an addon where the Ace2 libs are used so poorly, it actually makes things worse. Or they're embedded and never used... or embedded just to use one simple tiny function out of the whole big thing... or... you get my point.
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.
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.
Uhm... I thin you know that ScheduleLeaveCombatAction was doing far more than
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
preparisi per le parole sgradevoli
That's all it really does. Its just a fancy wrapper for what Tekkub wrote.
Poor guy.
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
You have to understand that there is a certain culture among some people around here that like pecking and adversity for some reason. But there are also people out there that'll be very welcoming and open to things.
And in general the vast majority of people are very helpful once you get to know them better and understand how they tick (and what ticks them off).
In either case I agree that #wowace is very helpful once you manage to assert yourself and develop a filter for stuff that happens that isn't helpful to you. Also people will get to know you which helps a lot.
The reason why some folks are a tad harsh already is basically because you unwittingly are hitting some hot-button issues for some people.
Specifically:
*) Code beauty
*) Code reuse
*) Code that hides detail and is easy to code
aren't categories that some will accept as important and certainly not as categories that trump code size and code efficiency arguments.
The question of what should be in a library is hostly debated and in general, if in doubt a library will nowadays not carry a feature than carry it.
But if you can make a good use case for some things there is a chance that you'll find an ear for it. Still because code reuse isn't a hot commodity, reinventing the wheel happens a good bit (which is very educational though if you have the time).
Once you understand that better it's easier to take all the good feedback that is to be had and develop the cognitive filter for other stuff (I recommend the pink heart-shaped glasses for this purpose).