Unique Id Allocation

[Moderator]

15:30, 4th Mar 2015
IcemanBo:

Provides allocation on a high level with extreme focus on safety.

Approved.

 

[Nestharus]

Ending with Unit Indexer and Alloc. We'll see if people like ^)^.

Don't forget that all of my resources can be found in my sig. As I slowly move stuff here, I want to make sure that I submit them in a way that isn't annoying =). This is the reason why I packed all of Alloc into one thing.


For future collections, I won't necessarily combine all collections into one pack, but I will combine all variants =), that way there aren't like 30 Linked List submissions. This is if I continue, if people are ok ';.;'.


Please feel free to give tips about how I can make things more pleasant. I've tried focusing on information (tutorials, documentation), presentation, and packing.

 

[Almia]

Aaaaaaaand his back

 

[Chaosy]

Most interesting..

edit: wanted to try it out but I failed.. when I try to call the allocate method it just tells me that the method can't be found. ("Undeclared function allocate")

local integer i = allocate()

It should work since it returns "this" which is equal to a integer.

 

[Nestharus]

Most interesting..

edit: wanted to try it out but I failed.. when I try to call the allocate method it just tells me that the method can't be found. ("Undeclared function allocate")

local integer i = allocate()

It should work since it returns "this" which is equal to a integer.

I know this may be stupid to ask, but are you in a struct and did you Implement Alloc?

struct Demo extends array
    implement Alloc //any of the 4 will work

    private static method onInit takes nothing returns nothing
        call DisplayTimedTextToPlayer(GetLocalPlayer(), 0, 0, 60000, "Allocated " + I2S(allocate())
    endmethod
endstruct

 

[JC Helas]

HOLY GENIUS PEOPLE, for me only genius people using globals,library,private,VJASS,ect...

 

[Chaosy]

HOLY GENIUS PEOPLE, for me only genius people using globals,library,private,VJASS,ect...

lel those are basic stuff. It's nothing close to complicated until you come to structs.

anyway..

@OT
Nope I didn't think it would be needed to be in a struct in order to call a static method.

 

[edo494]

If you are outside of struct you have to do StructName . static_method_name

 

[Chaosy]

If you are outside of struct you have to do StructName . static_method_name

but the allocate method isn't inside a struct. It is inside a lib and a module.

 

[edo494]

and module is not visible anywhere, it is basically a textmacro that gets run every time you say "implement myModule".

 

[Kazeon]

struct O_O extends array

???

Rejected

 

[Almia]

Haha classic Demo of his.

 

[chobibo]

struct O_O extends array

???

Rejected

What's wrong with that?

 

[edo494]

maybe looked too much like emoji

 

[Almia]

yep. Too much emojis. Otakuphobic.

[edit]

Confusing tho, I liked how the new Alloc works, much cheaper than older Alloc which uses two variables.

 

[Nestharus]

Updated with cleaner code. Threw memory analysis out to another library dedicating to this and included that library in the map as part of the pack.

See the very short changelog for all of the details.


The memory analysis tool helped me find a leak in one of my collections o-o. I still have no idea why it was leaking though... after 5 hours, I decided to remove a loop that didn't do anything and the leaks went away. What's stranger is that there were no thread crashes during the tests. So weird.


Preparing to release DDS on THW again. Lots of resources to update o-o.


The next thing I want to do with this memory stuff is be able to track all temporary memory an object creates and then, when that object is destroyed, determine if any of that temporary memory is still around. If it is, that object leaked. It'll be able to tell exactly what leaked for exactly what object.

I'm thinking of like MemoryMonitor or something, which'll be a global table.

MemoryMonitor.create(self, target) //will create it, no need to store it etc

When the target is destroyed, it'll automatically clear out the thing monitoring it in the global table
When the self is destroyed, it'll check to see if any memory it is monitoring still exists

I think this'll be pretty cool. It'll be debug only of course.

What about primitive types and native types?

UnitMonitor
ItemMonitor

etc

Monitors should only be used on data that should be completely destroyed by the time the monitoring object is destroyed

I should probably rename MemoryAnalysis to StackAllocatorAnalyzer and then name this new thing MemoryMonitor. I'll build it into the Alloc stuff as well.

 

[JC Helas]

Nestharus when I touch the script, then it wont run why?

 

[Nestharus]

Nestharus when I touch the script, then it wont run why?

What do you mean?

edit
The new beast is up

You can now track all sorts of memory leaks from allocated instances to handles o-o.

There is a new demo showcasing memory leak tracking

/*
*	Can you figure out what methods are causing the leaks?
*
*	This problem is hard because nodes are being dropped everywhere
*	and the culprit operations are difficult to spot. This means that
*	any method could be causing it, since nodes from every method are
*	getting dropped.
*/

struct DrunkenList extends array
	implement Alloc
	
	readonly thistype next
	readonly thistype prev
	readonly thistype first
	readonly thistype last
	
	static method create takes nothing returns thistype
		return allocate()
	endmethod
	
	method push takes nothing returns thistype
		local thistype node = allocate()
		
		call monitor("push", node.address)
		
		if (first == 0) then
			set last = node
			set first = node
			set node.next = 0
			set node.prev = 0
		else
			set last.prev = node
			set node.next = last
			set node.prev = 0
			set first = node
		endif
		
		return node
	endmethod
	
	method enqueue takes nothing returns thistype
		local thistype node = allocate()
		
		call monitor("enqueue", node.address)
		
		if (last == 0) then
			set last = node
			set first = node
			set node.next = 0
			set node.prev = 0
		else
			set last.next = node
			set node.prev = last
			set node.next = 0
			set last = node
		endif
		
		return node
	endmethod
	
	method pop takes nothing returns nothing
		if (first == 0) then
			return
		endif
		
		call first.deallocate()
		
		set first = first.next
		
		if (first != 0) then
			set first.prev = 0
		endif
	endmethod
	
	method clear takes nothing returns nothing
		local thistype node = first
		
		set first = 0
		set last = 0
	
		loop
			exitwhen node == 0
			
			call node.deallocate()
			
			set node = node.next
		endloop
	endmethod
	
	method destroy takes nothing returns nothing
		call clear()
		
		set first = 0
		set last = 0
		
		call deallocate()
	endmethod
endstruct

struct Test extends array
	private static method onInit takes nothing returns nothing
		local DrunkenList list = DrunkenList.create()
		
		call list.enqueue()
		call list.enqueue()
		call list.push()
		call list.push()
		call list.enqueue()
		call list.push()
		call list.enqueue()
		call list.push()
		call list.push()
		call list.enqueue()
		
		call list.clear()
		
		call list.enqueue()
		call list.push()
		call list.enqueue()
		call list.push()
		call list.enqueue()
		call list.push()
		call list.push()
		call list.enqueue()
		call list.enqueue()
		
		call list.pop()
		
		call list.destroy()
	endmethod
endstruct

Also, added two new allocator analysis macros. There was one style that I didn't cover. It's covered now.

 

[Zwiebelchen]

You should not use structs for this. Instead, create a simple function for allocating and deallocating based on a "purpose ID" that is basicly just a simple derivate of thistype.

set udg_Index = allocate(udg_MY_NEW_SPELL)
call deallocate(udg_Index, udg_MY_NEW_SPELL)

It's clearly a resource made for GUIers, so it should allow GUI compat.
Any JASSer will mostly use table or just create ordinary structs for better readability.

The minor speed increase of using Alloc over ordinary vJass allocation doesn't matter in any real-world application.

 

[Nestharus]

Huh?

How was this made for GUI users again? I use it all across my vJASS stuff...

Alloc isn't mainly used for a speed increase bro... look at the debug tools it has -.-. Those are far superior to the ones jasshelper provides.

 

[Zwiebelchen]

Huh?

How was this made for GUI users again? I use it all across my vJASS stuff...

Alloc isn't mainly used for a speed increase bro... look at the debug tools it has -.-. Those are far superior to the ones jasshelper provides.

If it's for debugging purposes, I'd say the ordinary vJass allocation creates better readable code (no implement, no arbitrary IDs as you will mostly index via GetHandleId(), which is directly related to the game mechanics) and thus, is also less prone to bugs.

I'm not saying this is useless; I'm just saying that the idea behind a standalone object allocator would have many more valid uses for GUIers than for Jassers, as they mostly use global arrays for coding spells.

 

[Nestharus]

Please tell me how a GUI user would use an alloc resource without macros ^)^. Would it just be a hashtable?

How would a normal GUI user call the functions? How would spells register themselves for the hashtable? Also, would this require parallel hashtables instead of parallel arrays? I think it would, but I'm not sure. Lemme know of the details and we might work something out.

Actually, if you bound the second dimension of the hashtable used for recycling, you can use parallel arrays.


So what I'm guessing is that you'd have 1 integer for every GUI thing that identifies it. You'd need to have at least 2 triggers also, one for initialization and one that runs. From there, whenever allocation or deallocation occurs, you'd have to set global variables to run some triggers, like:

set type = myTypeVariable
set instance = myInstance
set deallocate = 1


Also, for the AllocT variant, it'd require parallel hashtables I think, unless we did like a Table for GUI? We'd then need to do the same thing whenever setting an entry in the table and stuff though, right?

Why don't you write a GUI Alloc resource with all of the variants + debugging features and submit it? Like Alloc GUI.



Also, I didn't know that vJASS has all of these debugging tools in it. Is there a new one somewhere with this stuff in it that I can download? I'd love to use it if it has this stuff, cuz tracking memory leaks in really complex resources is painful. In fact, while I was just now getting memory leaks off of a resource (allocator stack corruption for a custom allocator), these debugging tools were screaming at me that this stuff was resulting from a thread crash. I didn't believe it, so I spent hours trying to figure out what it was, but it was indeed a thread crash, lol. Next time I should just believe the debugging tools. Woulda taken me about an additional minute to fix instead of the original 5 hours of scratching my head before I made the tools and the additional 5 hours of scratching my head after I made them >.<.



Please let me know =).

Thanks

 

[Zwiebelchen]

I'm not saying a GUI allocator would be easy to do. Coding for GUI use is a pain in the ass and we both know that. But it would be way more useful, because whenever a new MUI question pops up, we just redirect them to a tutorial about how to allocate custom objects in GUI (or a good tutorial about JASS workflow. It's a shame we don't have that yet).

No need to get all butthurt here. I'm just pointing out that, again, you code more or less for your personal use. Nobody writes complicated systems these days. And those that do... which is basicly just the handful of guys lurking the JASS section... probably won't need the debugging tools OR don't care about the minor efficiency gain.


The thing is: you like to code advanced stuff like this. No problem with that in general; but think about this for a minute:
DDS and codeless save/load are awesome. Why? Because they have a real-world application.
No mapper, even those that know and use vJASS will ever use this script. Because it's easier to just use the default allocation and be done with it. If bugs show up, we look into it again. If not, even better.
They won't invest additional time into using your alternative, because in mapping, time is the most limited resource. Hardcoding is a common practice when mapping, simply because you can not have endless content on limited maps anyway.

I just feel like all that coding energy could be channeled into something that not only looks useful on paper or for a community of 3 guys that still write systems for WC3, but systems that benefit a lot of mappers or solve typical problems that come up at least twice per day in the help section.
And I'm not talking about resources that we don't have a perfect solution for yet, like ItemIndexers. I'm talking about real game-related applications.

Just as an example:
Did you know that there is not a single approved creep respawning system for RPGs in neither spell section nor jass section?
Yup. This question pops up almost daily. I'd love to link those guys asking for help a system and say "use it!". But there isn't any. Why? Because most of the guys that still code and upload systems waste their time and effort on stuff only they themselves will use.

This is just one example. I could give you a lot more if you wish. But browsing the help section alone should already give you enough input on what is actually needed. If you're interested, at least. I don't know about that. As I said: you seem to code for fun and there's nothing wrong with that.

 

[Kazeon]

Zwei might be right, this allocation method can be useful for GUI as well, and it's probably better (easier) than dynamic indexing. What I like in using struct is because I don't need to do variable recycling, like:

set var[this_index] = var[last_index]
set var[last_index] = null

Using allocation, user is no longer required to do that (however still need to null handles/agents).
The API should be likewise Zwei's suggestion:

set udg_Index = allocate(udg_MY_NEW_SPELL)
call deallocate(udg_Index, udg_MY_NEW_SPELL)

But then we need different recycler variable for each "spell" or any instance that uses alloc, we can use advantage of 2D array here: hashtable.

Or maybe I'm wrong.

 

[Almia]

IF you want, I'll update my AllocTable.

 

[IcemanBo]

I'm not positive at all real GUI user will use vJASS alloc.

Instead of the try to let them feel comfortable in the GUI-cave with as many JASS features as possible,
we might do better to put our energy in conviction directly to switch to JASS.

Yes, they sometimes can easily take advantage of JASS things using one/two custom scripts, but then some day there is a limit and then it's just senseless and limited if you stay with GUI.

I'm with Nestharus here, though! It's not worth the effort.

 

[IcemanBo]

I really like that you made ErrorMessage and MemoryAnalysis optional.

Approved.

 

[Flux]

The debug messages are great and all but an extra onInit and ExecuteFunc (for calling onInit) for each struct is worse compared to an extra static attribute to the struct in my opinion.

 

[Nestharus]

The allocate code is shorter ; ).


The style from Sevion's post is the old way of doing it that everyone used to use, including me. Heck, I'm even in his credits at the top of the code for the algorithm/data structure ; p.


As per the bottom of the post, Ruk33 came up with this newer style that required 1 less variable and had a faster allocate method.

 

[Flux]

The allocate code is shorter ; ).

True, but this one causes parse overflow on large enough maps (using default JNGP pjass) and spammed the map script with lots of ExecuteFunc("s_<struct>__Alloc") at the bottom. I'm just stating the reason why I switch back to Sevion's.

As per the bottom of the post, Ruk33 came up with this newer style that required 1 less variable and had a faster allocate method.

I see, but I've read that it gives "0" as the new instance.

 

[Nestharus]

I see, but I've read that it gives "0" as the new instance.

Thus the reason for the module initializer : ).

That's interesting with the overflow though.