Jeff LaMarche praise + UIButtons

Jeff LaMarche just might rule. Seems like a lot of his postings are quite interesting for the maybe-not-so-newbie-anymore ObjC/iPhone programmer.

http://iphonedevelopment.blogspot.com/2010/03/irregularly-shaped-uibuttons.html

Nice intro UIView transform

Jeff LaMarche seems to have written quite a nice intro the transform property of UIViews, and how it (the transform prop) can be used to do various things to a view - scale, rotate, translate, etc. Like the tutorial on release/retain I posted below, this is the sort of thing I would have liked to read as a first introduction to animations/transform. Apple definitely has something to learn about pedagogy and/or meeting reader expectations from Jeff and Release/retain-guy/gal.

And oh yeah, here's the link:

http://www.iphone4gnew.com/demystifying-cgaffinetransform.html

Please note: The link leads to some sort of... well, compilation, I guess you could say and still be kind of right, of various sources. Jeff's original blog can be found at http://iphonedevelopment.blogspot.com .

Very good tutorial on release/retain in ObjC

Getters, setters, release, retain...

http://www.iphonedevsdk.com/forum/iphone-sdk-tutorials/7295-getters-setters-properties-newbie.html

Dates! Pah!

The following does not compile and several lines are mutually exclusive/contradictive.

Have a nice day.

NSArray* array = [NSLocale availableLocaleIdentifiers];
NSUInteger i = [array count];
NSUInteger j = 0;
for (j = 0; j
NSLog((NSString*)[array objectAtIndex:j]);
}


NSDate *today = [NSDate date];
//unicode.org/reports/tr35/tr35-6.html#Date_Format_Patterns
NSDateFormatter *frm = [[NSDateFormatter alloc] init];
[frm setDateFormat:@"EEE MMM dd 'huhu' HH:mm:ss ZZZ yyyy"];
[frm setTimeStyle:NSDateFormatterFullStyle];
[frm setDateStyle:NSDateFormatterFullStyle];

NSLocale *en_US = [[NSLocale alloc] initWithLocaleIdentifier:@"es"];
[frm setLocale:en_US];

NSString *currentTime = [frm stringFromDate:today];
NSLog(@"Time: :%@",currentTime);

Friends from the past...

Okay, little did I know that Java had introduced "generics" when I wrote my previous post. I must admit that my rosy picture of Java stems from around 2000, 2001 or so.

Thus, I shall have to withdraw from my previous standing on the Java language as the best language.

I do not have a clear choice for replacement, but I think Google Go looks sweet.

Java. It's just the way it is. Java.

Having reflected on the pros and cons of various programming languages, I have reached the conclusion that maybe I like Java most. It is really just so great.

For example:

- Everything is references to begin with. Having forgotten for the hundredth time to add the star to an argument to a method in Objective C makes you appreciate this. No need for * or & or ->. Great.

- It's object oriented. The first time you do a collection/aggregation of data and logic and wrap it in a .c and .h file in C it brings a certain nostalgia to life. "This must be where the need of classes first arose" you say to yourself and feel the kinship with thousands of previous programmers, toiling in their sweat in the pre-C++/Ada eras. But the 2nd+ time you do it, it's really more of a nuisance than the joy of following a great tradition. Especially, lacking a compiler-supplied call to a constructor, having to provide an "init" function to set the data to the preferred state.

- It's garbage collected. I love garbage collection. Yes. There it is. I said it. It's out in the open. Or, what I love is not having to keep track an eye out for memory leaks, of course. On the flip side I also love having everything statically allocated at compile time, and never getting anything from the heap. Just to provide some dualism here.

- Dot notation. YES: myObect.setThing(a). NO: [myObject setThing:a].

- Name mangling and function overloading. initWithInt, initWithBool, initWithDouble, initWithAdAbsurdum... yeah right.

- Not as many slightly implicit ways in which objects can happen to get instantiated as in C++.

- No templates.

- No operator overloading.

- Especially no "new" overloading.

Yes, That sums it up good, I think.

iPhone good. Apple maybe not so loveable.

I'd like to know whether an application using Lua would be accepted or not in the App store. Using Lua would save me QUITE a lot of trouble. I'd like to use Objective C and the frameworks as a means of presenting a digestible interface, whereas the logic of the involved entities would be controlled by Lua scripts.

I started doing the internal logic of an application in Lua, as a proof of concept. And after only a couple of days of "coding" Lua, I find it hard to go back to something as cumbersome as... something other than Lua.

SO ANYWAY (Slam notifications)

Although I had planned for my World of Warcraft Slam addon to grace the servers of, say, www.Curse.com, I ran into one too many tank diva (...in a PUG) and decided instead to halt development and quit World of Warcraft.

It feels good.

It would have been nice to put a complete addon package up, but it also feels nice to stay sane.

iPhone revisited, 1

Okay, it's time to actually do something more than dreaming of getting an app out there.

But let's face it, if I can't automate or at least make less annoying, confusing, lengthy, error-prone, etc, the process of getting an ad hoc provisioning profile, I might as well sort of give up immediately. So, first stop: Understanding the provisioning profile process.


And, ehm, first stop first sub... stop, I guess, is:

http://en.wikipedia.org/wiki/Keychain_(Mac_OS)

http://www.24100.net/2009/02/iphone-sdk-mobile-provisioning-0xe800003a-0xe8000001/

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)