- Joined
- Sep 26, 2009
- Messages
- 9,534
I've been speculating on the massive scope of a project it would be to try to integrate this source mapping functionality into TriggerHappy's W3TS. Basically, TypeScript2Lua does have a source mapping feature (disabled by default due to the absence of the debug library), but with this tool it would be possible to synthesize the stack trace in a way that it offsets the line numbers based on the concatenation of the original war3map.lua file with the TypeScript2Lua file, and by counting the newline characters it will be able to generate an offset. And you would thus be able to get full stack traces to the original TypeScript source code. Sounds wonderful, right? The problem is that I am still new to the idea of bundling TypeScript and Lua in the same package. I think for systems like this, that it only makes sense to keep them written in Lua, because they are far too low-level to be useful otherwise.
Stuff like Debug.beginFile/endFile would obviously not be needed in that case, because TypeScript2Lua has its own map that traces back to the TypeScript source.
Due to the close nature to the build process, this would have to be directly bundled into w3ts, in order to know how many original lines of code were in the war3map.lua file, so the stacktrace gives fake offsets. This would be problematic if there is an error picked up in some GUI code that was pre-packaged with the map.
It also makes me wonder, why not just include the war3map.lua as top-level source code when compiling with TSTL, thus eliminating any need for hacky offsets. The mapped traceback would work well to identify standard war3map.lua problems.
So maybe the sanest approach is to just not try to do anything with the source map at all, and just let people sift through the compiled Lua code. Who knows. Some feedback would be welcome.
Edit - here is the beginning of an attempt to provide the necessary API to TypeScript2Lua. This would need to ensure that it is placed above the transpiled Typescript code itself, in order to ensure that TypeScript2Lua uses it instead of the nonexistent debug global:
Happy to hear more of @TriggerHappy 's thoughts on this one.
Stuff like Debug.beginFile/endFile would obviously not be needed in that case, because TypeScript2Lua has its own map that traces back to the TypeScript source.
Due to the close nature to the build process, this would have to be directly bundled into w3ts, in order to know how many original lines of code were in the war3map.lua file, so the stacktrace gives fake offsets. This would be problematic if there is an error picked up in some GUI code that was pre-packaged with the map.
It also makes me wonder, why not just include the war3map.lua as top-level source code when compiling with TSTL, thus eliminating any need for hacky offsets. The mapped traceback would work well to identify standard war3map.lua problems.
So maybe the sanest approach is to just not try to do anything with the source map at all, and just let people sift through the compiled Lua code. Who knows. Some feedback would be welcome.
Edit - here is the beginning of an attempt to provide the necessary API to TypeScript2Lua. This would need to ensure that it is placed above the transpiled Typescript code itself, in order to ensure that TypeScript2Lua uses it instead of the nonexistent debug global:
Lua:
debug = {
traceback = function(thread, message, lineNumber)
local level, n, traceback, msg, last = lineNumber or 1, 0, {}, nil, ""
repeat
_,msg = pcall(error, "", level)
if msg ~= "" and msg ~= skipThisLine1 and msg ~= skipThisLine2 and msg ~= last then
n = n + 1
traceback[n] = msg
last = msg
end
level = level + 1
until level == 200
local i, results = 0, {}
repeat
msg = traceback[n - i]
i = i + 1
results[i] = msg
until i == n
return table.concat(results)
end,
getinfo = function()
return {short_src = 'war3map.lua'}
end
}Happy to hear more of @TriggerHappy 's thoughts on this one.
Last edited:
