It's been such a long time since the last post. Almost 2 years! Time does fly.
Why the sudden resurrection of this blog? Let's just say it's the desire to learn rekindled again!
I'd mentioned on several previous posts (I think I did at least) on this blog that I used to work as technical translator for a software dev company back in the Philippines. The team I served with my language skills (greatly diminishing instead of improving - I cringe at the multiple and redundant grammatical errors my posts here contain!!) were Java developers. They tried to teach me how to code in Java. I remember that "Beer Song" exercise that when I'd resolved, I dropped Java like a too hot pancake in my hands. Since it had splattered on the floor already, why bother picking it up? There were more interesting and yummy pancakes at that time (ehem - like hackintoshing) to get my hands on!
I remember explaining to my team mate - who was a freakin' awesome Java programmer - and close friend that I just couldn't accept why methods, objects, etc. must be declared first. On retrospect now, perhaps there was just the general lack of a motivation for me to force my brain to wrap itself around the proclivities of decent Java coding: i.e. the need to make things work.
For I realize I did dip my elbows in code when I was finding my way through the cog works of hackintoshing, specifically DSDT patching. I was surprised to learn that it involved, in fact, coding at a much much lower system level than say the commonly known object-oriented programming languages like Java, Python, etc.. Java worked inside the Operating System and interacted mostly with the files and file system therein, while dealing with DSDT meant interacting with the BIOS. (More info on DSDT here)
I had to patch my own DSDT to make sure low system level processes like wake-up from sleep triggered by mechanical actions like closing the lid, hibernation, fan speed, etc. for my own hackintoshes because most of the hacking guides available were for North America models of said machines and I was in Asia. I had to do a lot comparison and reading the code lines of those other hackers posted and looked out for patterns. Some object names would differ by one character between those posted codes and the actual DSDT extracted from my own Asian release model laptop or netbook. It was trial and error, testing, and squeezing out comprehension from cryptic lines as the example section here:
/* Name (\LIDS, One) */ //comment out as per code structure
Name (_HID, EisaId ("PNP0C0D")) //LID detection
Method (_PRW, 0, NotSerialized)
Return (Package (0x02)
Name (\LIDS, One) //added as per code structure
Method (_LID, 0, NotSerialized)
Store (^^SBRG.EC0.ELID, LIDS) //LID register
XOr (LIDS, One, Local0)
If (Local0) //If LID is closed
Notify (SLPB, 0x80) //puts system to sleep
Store (One, LIDS)
I remember this is to correctly trigger sleep from closing the laptop lid and if my memory serves me right, after long hours of sleepless nights, I tried adding 'S' to the 'LID' entries in there just because I had ran out of logical things to try even after scouring the interwebs and even downloading HP's BIOS manual. Miraculously, it was the key! I don't regret reading the HP BIOS manual because I was able to deduce some of the lines' function . I put my learning after "//". It was fun to discover "Oh so that 0 there is closed lid and 1 for open lid!". Perhaps it was akin to how Jean-François Champollion felt when he finally deciphered the Egyptian heiroglyphs after years of studying the Rosetta Stone.
Of course, if you asked me if I still understand DSDT now, the answer is an honest not at all. Hehehe. There's just no urgency for my lazy brain to even switch on and make an effort to re-learn, after all, I've been blessed now with a real Mac ;)
Recently, I had to find a way to manipulate .csv files (comma-delimited text files) to do a sort-of-vlookup process and all to be done via batch file.
I hate Excel, formulas, and numbers in general. It's beyond question that I even try to learn macros much more VBA. It's natural human instinct to stay away from things we abhor, right?
But the problem of making that vlookup routine work in an automation project piqued my interest and I was hooked in. I gave up my time for watching Korean dramas for lurking on Stackoverflow forums for which I was rewarded with a VB Script.
I resulted to that familiar method of trial and error and pattern search. Finally, the lines of heiroglyphs - err, sorry code - made sense. I present to you for scrutiny and judgment, the discoveries
'Load dictionary entries from text file of replacements
Set oInFile1 = oFSO.OpenTextFile(cInFile1, cForReading)
Do Until oInFile1.AtEndOfStream
aLine = Split(oInFile1.Readline, ",") 'reads lines in File1, taking items as spearated by a comma
If Not oDict.Exists(aLine(0)) Then 'adds each item and corresponding values to the dictionary array where we will use later (loaded into memory?)
oDict.Add aLine(0), aLine(1) 'there are 2 items per line, 0 and 1 - begins with 0!!
'Read input file, lookup replacement, write new output line'
Set oInFile2 = oFSO.OpenTextFile(cInFile2, cForReading)
Set oOutFile = oFSO.OpenTextFile(cOutFile, cForWriting, True)
Do Until oInFile2.AtEndOfStream
aLine = Split(oInFile2.Readline, ",")
ReDim Preserve aLine(UBound(aLine)+1)
aLine(5) = aLine(4) 'moves 3rd item in row to the 4th
aLine(4) = aLine(3) 'moves 2nd item in row to the 3rd
If oDict.Exists(aLine(2)) Then 'this is the lookup part - checks if 3rd item in a row has a dictionary entry
aLine(3) = oDict.Item(aLine(2)) 'loads the value of that item found rom the dictionary in memory to the 4th item in a row
oOutFile.WriteLine Join(aLine, ",") 'joins the items in a file