Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Luna breaks EnumerateFrames #145

Closed
shirsig opened this issue Sep 15, 2016 · 9 comments
Closed

Luna breaks EnumerateFrames #145

shirsig opened this issue Sep 15, 2016 · 9 comments
Assignees

Comments

@shirsig
Copy link

shirsig commented Sep 15, 2016

http://wowwiki.wikia.com/wiki/API_EnumerateFrames
With Luna enabled iterating through the frames with this function throws a "couldn't find 'this' in current object" error. Not sure how this could happen. Maybe it's deleting the userdata from a frame table?

@Aviana
Copy link
Owner

Aviana commented Sep 19, 2016

Nope but one of the used libraries might do that.

@Aviana
Copy link
Owner

Aviana commented Nov 5, 2016

Pretty sure thats an error on your end. I can call EnumerateFrames perfectly fine. If one of the frames you get from it doesn't contain the object you are looking for you have to account for that.

@Aviana Aviana closed this as completed Nov 5, 2016
@shirsig
Copy link
Author

shirsig commented Nov 5, 2016

No, the function is used like this
local f = EnumerateFrames(f) while f do f = EnumerateFrames(f) end
to walk through all frames created in the current session.
Now what's happening when luna is enabled is that somewhere during this loop it returns a frame which throws an error when passed back to it as an argument. There's no remedy for that because you don't know the order of frames in advance so you can't just skip one. You can stop at that point but that means you miss all the remaining frames.

@Aviana Aviana reopened this Nov 10, 2016
@Aviana
Copy link
Owner

Aviana commented Nov 10, 2016

After some experimenting i can say that at some point EnumerateFrames encounters a table (not a frame) that has no data. Passing this table back into it causes the error. I do however not know what would cause this since i don't do fancy table stuff in my code that would cause this.

@Aviana Aviana self-assigned this Nov 20, 2016
@slaren
Copy link
Contributor

slaren commented Dec 1, 2016

The issue is caused by some of the embedded libs (DruidManaLib-1.0, HealComm-1.0, FivSecLib-1.0, CastLib-1.0). Their library tables are frames, which are then passed to AceLibrary which proceeds to copy them to new tables and "destroy" the original tables (a frame), as can be seen here.

These destroyed tables then become invalid frames, causing EnumerateFrames to fail.

@Aviana
Copy link
Owner

Aviana commented Dec 1, 2016

Thank you very much! I really struggled to figure this out.
Those are all libraries i wrote some time ago when i was still learning the ACE framework. So now i am rewriting and testing them.
Fix for next release incoming!

@Aviana Aviana closed this as completed Dec 1, 2016
@zerosnake0
Copy link
Contributor

I suggest you can try to use my Ace3 vanilla version if you wanna rewrite some lib. It's still under development and I'm doing the tests to make sure it works correctly, see my Ace3test repo. Most features except GUI will be soon available. The AceLibrary in Ace2 can cause some problem when it copy the data from old table to new table. I think today the PCs are more powerful so there's no need to care too much about garbage collect. I compare the codes of Ace2 and Ace3 and think Ace3 is much clear so I turned into Ace3 and only use Ace2 as some kind of reference.

PS: I will do the translation during the weekend and push ASAP

@Aviana
Copy link
Owner

Aviana commented Dec 2, 2016

I don't see the point of ACE3 in vanilla. All the existing addons are ACE2 and the main benefit is that all the addons share their library code. So making Luna ACE3 would increase the memory of everyone using it and other addons drastically. To make it sensible you would have to port lots and lots of old addons to your ACE3. Also while i haven't looked at your code the thing that makes everything better are the elipsis (...) the select() and wipe() functions. Which can be emulated but never will reach the performance benefit of them beiing written in C and be provided to the LUA environment.

@zerosnake0
Copy link
Contributor

zerosnake0 commented Dec 2, 2016

Well it's only a suggestion, I'm not asking to make a Luna3 :P. For me it's some kind of experiment. In fact i don't think Ace3 will use much more memory than Ace2 ("drastically" as you said), using the variable arguments will surely increase a bit usage but as I said I don't think this is a big issue for PC nowadays. What I like is the the code of Ace3 seems to be more clear and reusable. I also considered the compatibility between 2 and 3, maybe it will be possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants