lua port

argv[0] = "someActualStringAndNotJustAnUninitializedValue";

So... Problem solved. File under "Too embarrassing".

Lessons learnt: Find axioms ("argv[0] is untouched in lua.c") and their consequences ("I care not about init of argv[0].) Try anti-axiom and consequences. ("...IS..."/"I'll init argv[0]").

Ok I knew this lesson already.

Which makes it double frustrating.

lua startup mem usage

Seems like Lua (5.1) allocates roughly 21kb during startup, given a clean (empty) file to work with. So obviously mem problems shouldn't be an issue.

mac backslash

alt shift 7, thank you very much

Lua port to mac no issue

Continuing rambling about port of Lua to work chipset...

I just compiled the Lua 5.1 source code for mac, and running it in a similar fashion to the port I'm trying to do at work yields no problems. Works like a charm, actually. So, maybe the startup really is very different when you give the interpreter input from a file and when you give it input form stdin - the former demanding much more memory in the startup phase. But how much (more) memory would you need? I mean, really? I'm still not convinced. This has to be looked at further! Hurry Watson, the game is afoot!

mac curly brackets

This thing continues to drive me crazy.

Swedish keyboard.

alt + shift + 8/9

Some thoughts on the Lua source code

1. It's very clean.
2. Most of the extra help in understanding the code that could have been had from, say, descriptive names for variables, have been BRUTALLY SACRIFICED ON THE ALTAR OF CLEANLINESS. Which sort of puts item 1 to shame, a bit, really. The occasional "numberOfArguments" instead of a plain old "n" wouldn't have hurt.

argv, arrrgh (lua port endeavours)

In my attempts to specify a file for my ported version of Lua to read and "execute" I have come upon unexpected problems. Or, I might have misunderstood the argument list to lua.exe. Thing is, that if I call lua like this:

char* argv[MAX_ARGS];

argv[1] = 0;

lua_main(1, argv);

Lua fires up the interactive mode, and I can give it lua lines to execute (on target, whoa) through stdin dialog text fields in the IDE/emulator. I can make tables, assign table elements, add things to other things, et cetera, without any problems. No memory problems at all.

In this scenario however:

char* filename = "aloha.lua";

argv[1] = filename;

argv[2] = 0;

lua_main(2, argv);

...lua crashes, saying there isn't enough memory.

Possible causes, I guess, are:

1. I made some mistake handling argv. Maybe Lua actually does something with argv[0]. Since I leave it uninitialized, it's not really nice to play with. Maybe I should set argc to 1, since the program name is presupposed anyway.
2. Lua needs more memory reading from a file than from the interactive mode. Not very likely though. Reading from stdin or from a file should be quite analoguous. Also, I moved system heap from internal memory to external memory and increased heap stack about a hundred times, counting in megabytes. Should've put an end to lack of memory if it really was that problem.
3. "Something goes wrong in there." Which, eventually (a couple of micro or milliseconds later), makes lua think it's out of memory. Hmmm.... coming to think of it, the increase in memory should've led to a noticeable (even by human standards) extra time before memory ran out (supposing wild allocation all over the place!). So, maybe Lua did not experience an increase in memory. So, maybe Lua does not take its memory from the heap in the straight forward manner I've presumed? Maybe memory resources are set up in luaconfig.h or similar...? Ah... the plot thickens.
4. I misunderstood argument passing. Maybe the file name is supposed to hold pre-compiled lua byte code or something. But then why would it work when passing lua on Windows a file holding ASCII representation of intended functionality?Nah, this theory I tentatively write off.

Anyway, it's good fun tracking the cause of this. I have a feeling I might take an unexpected, non-linear step up the computer science learning curve, doing this, haha.

Porting Lua

Lua is the scripting language of choice for World of Warcraft, and I've been reading up on it the last few weeks in my attempts to make a WoW addon.

Today, at work, it struck me that maybe I could port Lua to one of our small, quite specialized Digital Signal Processors that we use for, not very surprisingly I guess, signal processing.

It turned out that I could. Actually, it was so simple that it was almost a disappointment.

This is how I went about:

1. I got the source code from http://www.lua.org/source/5.1/ (there's a .tar linked)
2. I set up a makefile for the code. This was, thanks to our build system already in place, a very small effort. Tbh I didn't pay much attention to the supplied makefile (or any of the other documentation, not even the README file... *cough cough*)
3. I compiled it. It compiled all right. Yes, that's right. It. Compiled. All. Right! The code that I downloaded, about thirty c files or so, all compiled without even a compiler warning. Wow. 
4. I got link problems (1). Turned out that I had missed a couple of c files when writing down the list of source files in my own makefile. (imo, lstrlib, ltablib, and ltable are too close, in some Hammingtonian way, haha)
5. I got link problems (2). Altho our supplier's compiler is mostly ANSI C compliant, the system call for execution of a (string)  is not supported. The call to system() took place in loslib.c. After a deep quite shallow analysis of the problem, I decided to apply the happy go lucky approach and comment out the call. Should it actually bear relevance, it would show sooner or later and I'd have to deal with it then. It would be quite weird, however, I think, for a language with the goal of extreme portability, to rely on being able to do system calls. Probably some obscure area, seldomly visited (note: this belief may be subject to change.... :))
6. I linked the lib with some other OS-ified software of ours, and loaded it to target.
7. I ran it.
8. I got entry point override problems. I thought I had preempted the possibility of Lua's main wreaking havoc with the OS main() (the OS likes to claim main() definition privileges, obviously) by renaming main in lua.c to lua_main.c. (and yes, at the point where the OS hands over to user code, I put a call to lua_main, argc = 1, argv = set by system). However, the first thing that happened at startup was not the familiar printouts of the SW platform, but an error message from the Lua compiler. After a bit of confusion and happiness (the latter derived from getting Lua to run in some form on target) I realized that whereas the interpreter (lua.c) should be included in the build, the compiler (luac.c) should not. They both define a main (some other symbols in common as well).
9. (So apparently) I removed luac.c from the build.
10. I ran it. And OMG!!, through the cable connected to my evaluation board, and through a dialog box on our supplier's IDE running on Windows Vista, and such, in the year of our lord 2010, the Lua interpreter asked for input.
11. I gave input. "print('mumu')" I gave it.
12. "mumu" it answered.

Next up (I guess): Specifying file for Lua on target to read. And make it call some C/C++ functions as specified by script. That'll be cool.

This post failed because iPhone Safari doesn't recognize the big bold text field as a text field.

Lua Book

Just got a little book delivered. Programming in Lua by Ierusalimschy. Will hopefully cast some light on the module/namespace/scope concept in Lua.

Frames

It would be nice of course to change a frame programmatically, and not have them defined statically per xml throughout the life of the addon. Haven't found any good sources as to how to use dot notation (maybe it's not possible :P) to reference the object hierarchy correpsonding to the xml file (the object hierarchy I presuppose is there... :)).

This could however be a start, I guess:

http://wowprogramming.com/docs/widgets/Frame

OnUpdate

Ahaaa. Seems that frames gets a notification every frame change, like: someScript(elsapsed) So, on my... ahem... high end system, that would be almost 60 times per second. Goood.

http://www.wowwiki.com/Using_OnUpdate_correctly

Pheeew. I knew it had to be there somewhere.

Code rage

In line with my third further goal mentioned below (adding counter to frame to show time remianing of buff), I've searched through a number of addons for system timer callback registration functions. My theory is that since several addons seem to provide stopwatches, time counters, that sort of thing, there must be an API call to register a callback/listener for a time event on some regular basis, say x ms or so.

If there were no such thing, addons would have to rely on other events firing frequently enough to make a smooth and accurate timer. Which would be silly, ofc. So, there must be an API call, and altho I have gone through several addons and not found it, I must've just missed the relevant line of code due to drunkenness or hübris, right?

Right?

I've gone through several addons now, and I just can't seem to find a call to some "system" library providing callback functionality based on time. It's ridiculous. Even in files named CoreTimerHandling.lua, or such, have I had much luck. It is crazy, crazy, and I'll go crazy, too, soon. I mean it just CAN'T be that everything relies on frequent enough events of other types. It's not clean.

I'll have to check some more.

SO ANYWAY (Slam notification)

Goal: To produce an addon that gives an indication when Bloodsurge procs and slam turns instacast.

Progress: Goal achieved.

Method: The addon subscribes to UNIT_AURA events. Upon notification of a UNIT_AURA event, the buffs currently on the player are iterated over by use of UnitAura(). If a buff with spellName "Slam!" is detected, a (blue) frame is made visible. If no buff named "Slam!" is found, the same frame is made invisible.

Further goals:

• Make the frame moveable.
• Save frame position between runs.
• Add counter to frame showing time remaining of buff (insta-Slam).

Note to self

UI elements should be placed within UI tags, haha.

... and maybe there'll be sounds!

PlaySoundFile

Event for cooldown?

Aha!(?)

Event SPELL_UPDATE_COOLDOWN

in conjunction with
http://www.wowwiki.com/API_GetSpellCooldown

start, duration, enabled = GetSpellCooldown(spellName or spellID or slotID, "bookType");

could be something.

Pseudo code for slam proc

MyUNIT_AURAHandler(self, arg)

if arg == player

for i in 1..40
name = UnitAura(i)

if( name = "Slam!") then
doSomething()
endif

endfor

endif

Obviously, needs to handle three cases:

1. Found and not a continuation (show indication)
2. Found and a continuation (keep indication up / no action)
3. Not found (hide indication)

Lua is cool

function Example:HOLY_COW(arg1, arg2, arg3)
local a = 0
a++
end


<-> Add* key HOLY_COW to table Example, value = function taking three args.

Just like that, in one go. Thass pretty cool.

Not as cool as Python, but still.

* Ehm, supposedly, anyway. I don't really know Lua. But I don't see how that code that I've seen in example addons would work if it doesn't do what I think it does.

Slam event findings

Ah, so, where do we get the Bloodsurge proc info from?

It turns out that wile it was previously included in (unfiltered?) combat log reports, it has been removed (as of some patch, breaking several addons, bummer) from the combat log and is now to be found among the UNIT_AURA events.

The UNIT_AURA event is reported whenever the player (or something?) gains or loses a debuff/buff.

Unfortunately, the UNIT_AURA event is accompanied by only one meagre argument - a unitId. unitId seems to be string, often with the value "player".

So, that's not much to work with.

However, fortunately, there's the UnitAura("str") call. Goes like this:

name, rank, icon, count, debuffType, duration, expirationTime, unitCaster, isStealable, shouldConsolidate, spellId = UnitAura("unit", index or "name"[, "rank"[, "filter"]])

(http://www.wowwiki.com/API_UnitAura)

The UnitAura call is for querying the buffs on a unit. I.e., the buffs shown in the upper right corner next to the minimap in the default layout of the GUI.

In brief, "unit" should be unitId given by UNIT_AURA (if == "player", supposedly). The index is which of the buffs in the upper right corner you want to get more info on.

The buffs are 1-indexed. I.e. the first buff (counting from upper right position, I think) has index 1. max_index seems to be 40.

If name is nil for an index, there is no buff at that index. Break loop.

Looping indices 1 to 40 on UNIT_AURA event during combat indicates that instant slam Bloodsurge proc buff has name = "Slam!".

WoWWiki Pages

TOC file
http://www.wowwiki.com/The_TOC_Format

Slash Commands
http://www.wowwiki.com/Creating_a_slash_command

Eclipse and Lua

Tried installing the Lua plugin (Lua development 1.2) in Eclipse. It didn't really work. ClassNotFoundException when I tried editing a file I named .lua. Bad.

Also, Eclipse behavior when editing xml files was a bit daunting, as well. When creating a file from scratch, Eclipse went into an "xml mode" requesting everything be put into the file by way of dialog boxes and tags, so to speak. When I renamed a file with already written content to an xml ending, however, Eclipse didn't even get the syntax highlighting up and running. Weird.

Or perhaps not so weird, had I had the time and energy to look deeper into it. As for now, however, I'm going Notepad++!

http://notepad-plus.sourceforge.net/uk/site.htm

File type links

A bit on the WoW addon xml file format.

http://www.wowwiki.com/XML_user_interface

Link - frames & stuff

http://fara.webeddie.com/frames/

TOC file

This info is valid for patch: Last big patch for Northrend. 3.3 or so.

So. TOC file. What are the needed elements?

http://www.wowwiki.com/AddOn says (in short, ofc):

- Must be named AddonDirectoryName.toc
- Three mandatory lines: Interface, Title, Notes. Check other addon for version number or http://www.wowwiki.com/Getting_the_current_interface_number.
- ...

Ah what the heck, just check everything up at http://www.wowwiki.com/The_TOC_Format.

WoW addons

Oh, it'd be hefty to make a WoW addon. I'm thinking: centered ragebar and a good marker for Slam procs. (edit: and indications for WW, BT out of cooldown)

So, what gives?

1. Apparently, addons are placed in {InstallationDir}/Interface/AddOns/MyCoolAddOn

2. (At least) Three (?) files define the addon:

1. A .toc file. A table of contents sort of thing.
2. A .xml file defining various UI objects. GUI parts are (it seems) orchestrated by xml files. Much like in Java, where awt or swing object have to be created and resized and fontisized and registered with ActionListeners and such, except it's done in xml. Sort of.
3. A .lua. A lua script file with code, defining the various callbacks (event handlers) tied to (registered with) the objects/classes defined in the xml file.

Except for lua, of course, there does not seem to be an offical listing of syntax/coding rules / supported xml tags. I wonder how the first addon makers got by. Were they secretly given info by Blizzard in order to start some kind of viral information spreading on the subject? Or how the heck did they do it? It's like breaking iPhones - I am clueless as to how to start.

(altho reverse engineering addons would be much simpler I guess since Blizzard offical "addons" are available... hmmm)