luca-spopo / bakagaijin Goto Github PK

Currently, bakaGaijin exposes its debug functions as global variables such as showBaka and bakaGC.
This is polluting the global namespace.
Instead, I propose all debug functions being in a table accessed using bakaGaijin(1337)

For example, bakaGaijin(1337).showBaka

This will not cause any problems, as resources must have string names, and that's all the bakaGaijin function is being used for currently.

There may also be other restrictions on resource names, such as the string not containing ":" or "$". We can use this to allow serverside scripts to call client side objects etc via bakaGaijin("c:resource2") or something similar (If such a functionality is implemented).

The meta garbage collector network thing was thought not to be able to have cycles, but it can.
Consider this sequence of events:

note: bg = bakaGaijin
A:
	bg.var = {}
B:
	bg.var = {}
A:
	bg(B).var.key = bg.var
	bg.var.key = bg(B).var
	bg.var = nil
B:
	bg.var = nil

Full scripts to reproduce the problem are attached. Delete the 4 lines in myfile.lua marked with "--cycle" if you want to see behavior of the same code when a reference cycle is not formed.

In any case, this demonstrates that reference counting will not be enough, and we need a deeper algorithm to check for cycles in the graph.
myfile.txt
myfile2.txt

Currently, the getBaka function calculates the number of objects locked for a resource by iterating over the ownLookup table.

The function was made before load counting was done by the loads table.

Now that we have a table called loads that counts the number of objects locked for each resource, we should just return that value instead of calculating the loads by iterating.

Currently threads cannot be passed from one resource to another.
Support for them should be added.

Possible bug (untested)

If an exported gaijin function is called in the form fun(1, nil, nil) I suspect the host will only receive fun(1)

I believe this will be fixed in 1.1 as it uses the select function rather than operating on {...}.

Setting a metatable for an active token will only ruin the active token, not set the metatable for the original object as the caller probably intended.
Getting a metatable for an active token will get the metatable generated by bakaGaijin, not a representation of the original's metatable in the host resource.

setmetatable and getmetatable need to be overridden to fix this behavior.