I don't post here often, though am working on a number of things with Killa. I'll post those to my blog soon (I hope!).
Here are some notes about devbuild (Jan 06 one). Arranged from notes in different projects, so are not as related to each other (topic split per paragraph):
For the development build dated Jan 06, 2013, "killa.exe" somehow denies to start on Windows XP SP2, giving an abstract "Unable to start the program, because it is misconfigured. Reinstallation may fix this problem" error. An interesting part is that "love-killa.exe" still works fine, and same executable works fine on Win7. Problem is confirmed to exist on at least two different installations of this kind (one being an actual machine, and other being an emulated image of "raw" SP2 without updates), so it might be some dependency issue. Said executable is also substantially "fatter" than previous versions (302KB vs 160..180KB).
In development build version of love-killa, for some reason, it is no longer possible to run folders/.zips/.loves by passing them as absolute path parameter - error is given that "main.kia" is not found. Passing folder/archive location as relative location still works though.
As of development build, the "global.arg" array is still oddly indexed. And by "oddly indexed" I mean that killa executable is arg[-2], and arguments start from arg[-1].
It might've been noticed already, but there *is* need for being able to access global variables without "global." prefixing. Syntax starts looking weirder and weirder as you need to access non-functions of global objects or need to access actual function references.
If it's simple enough to implement, I'd like to suggest the following scheme:
* A separate table called "local" is introduced, which holds current local scope variables, and does not throw undeclared variable errors if accessing variables via it:
Code: Select all
print(local.missing) // "null"
print(missing) // error
* If
local.__index is set to
global, missing variables are also looked up in global table:
Code: Select all
print(some) // error
global.some = 1
print(some) // error
local.__index = global
print(some) // "1"
var some = 2
print(some) // "2"
print(local.some) // null
Now that JavaScript-like naming conventions for global classes are used, maybe it should be "IO", "OS", and not "Io", "Os"? JavaScript name examples of treatening abbreviatures include "innerHTML", "baseURI", "CSSStyleDeclaration", "getAttributeNS", etc. Similarly, things should be probably camelCase'd and using uppercase for constants. Here's a rough list of renaming to be done:
Code: Select all
tostring > toString ; actually, maybe add it to "core" metatable, like in JS
tonumber > toNumber ; could be "parseFloat" with a separate new "parseInt"...
Math.huge > Math.HUGE
Math.pi > Math.PI
Math.randomseed > Math.randomSeed
rawlen > rawLen ; or rawLength
rawequal > rawEqual
rawget > rawGet
collectgarbage > collectGarbage
Package.loadlib > Package.loadLib ; or loadLibrary
Package.searchpath > Package.searchPath
Os.setlocale > OS.setLocale
Os.getenv > OS.getEnv
Os.diffTime > OS.diffTime
Os.tmpname > OS.tmpName
Debug.getupvalue > Debug.getUpValue
Debug.setuservalue > Debug.setUserValue
Debug.getmetatable > Debug.getMetaTable
Debug.setmetatable > Debug.setMetaTable
Debug.setlocal > Debug.setLocal
Debug.gethook > Debug.getHook
Debug.sethook > Debug.setHook
Debug.upvalueid > Debug.upValueId
Debug.upvaluejoin > Debug.upValueJoin
Debug.getinfo > Debug.getInfo
Debug.setupvalue > Debug.setUpValue
Debug.getuservalue > Debug.getUserValue
Debug.getregistry > Debug.getRegistry
Debug.getlocal > Debug.getLocal
Io.tmpfile > IO.tmpFile
getmetatable > getMetaTable
setmetatable > setMetaTable
dofile > doFile ; I'm not so sure about need in this one renaming.
loadfile > loadFile
Pattern for above list could be something like "(%S+) *> *(%S+) *;? *(.*)".