Hideki A. Ikeda (HidekiAI) [池田英紀] ["Tony" Ikeda] – BLog

I’m not too much of a cell-phone user these days, during the analog phone days, just like when e-mail became very popular back in mid-90′s, I was addicted to it.

Last time I bought my cell-phone, I specifically inquired to see if I can purchase an unit which had no CCD/camera because I did not see any use for it (I did find a use for it, although I ride motorcycle now, I used to drive and whenever I got cut-off or reckless drivers pissed me off, I took their license plate with the camera;  One of these days, I am going to create a web-site called assholedrivers.comwhere I’d post their plates and until they make a public apologies to all drivers, it will stay up).  I wanted a Sony/Ericsson phone because it had the capabilities to download Java.  But that didn’t go so well when I discovered that I was getting charged so much for data-usage from AT&T.

A colleague of mine (http://www.sjbaker.org/wiki – this person is a guru of graphics and everything else, he is incredibly wealthy with so much knowledge, to me it is always a treat to talk to him – not only is he the original author of TuxKart and plib, but you must check out his Simple 3D Scanner link on his page!) gave me this link http://developer.android.com/guide/developing/device.html#dev-phone-1after few discussions about games on phones (including recent discussions we had on OpenGL ES 2.0 – by the way, currently Android is OpenGL ES 1.x).

After doing some researches, I finally purchased it for these reasons:

• I loved the fact that it was Linux 2.6 at the heart of it
• The SDK and NDK by Google proved to me that this is serious (NDK is the native developer’s kit which lets you access the OpenGL ES and other low-level directly)
• It has built-in WiFi, so I won’t get charged by AT&T on DATA
• It’s unlocked
• This Stanford Video: http://www.youtube.com/watch?v=WUrMI9ZGxQ8
• This “it makes it look easier than it is” video: http://www.youtube.com/watch?v=I6ObTqIiYfE

(continue reading…)

Related posts

• Use your O/S to Multi-Process (0)
• Linux Partition Size (0)
• Linksys RV082 Dual-WAN Setup (0)
• In the Beginning (0)
• Crossdev i586 and i686 on x86_64 (0)

There are few things I’ve learned from my experiences of doing cross development, but first and foremost, I’d like to mentioned that another desired reason to stick with Gentoo was/is crossdev (best place to start is here).

Although crossdev no longer supports i386 it still is something I cannot live without – when you attempt to crossdev i386, it tells me that I don’t need it – how nice of them to assume that just because Gentoo is targetted towards the “bleeding edge” technology, we’re not likely to develop on primitive processor – some of us have decided and chosen Gentoo so that we can take full advantages of all packages compiled and optimized specific to that target including i386 – oh well…

Another cool features are that crossdev supports MinGW32 and CELL processor (PS3 – both SPU and PPU – nice!).

Here are some “evolving” notes (meaning everytime I discover something new, I’m updating this journal) of what I’ve learned…

make.conf

• Make sure CFLAGS contains -m32 so you won’t get “CPU you selected does not support …” error
• Currently, my USE flag is not set to USE=”minimal” and it seems to do well (am I being lucky?)

distcc

There are some things which for one reason or another, you have to compile on the actual platform (i.e. the author of the package is not correctly honoring “sysconfdir=$(ROOT)@sysconfdir@” in Makefile.include.in file so it keeps attempting to grab the libs and include from the x86_64 host rather than target folder). Although this method is slower (even if you did -j5 in the make options) because although you can compile accross the distributions, linking has to still happen on the actual box (obviously!). A great starting point is here.

xmerge (emerge wrapper)

One of the late discovery was this script found in this link called xmerge. It basically sets the root to your current target and emerges. I usually make sure that I have buildpkg as part of the FEATURE options, as well as making sure that PKGDIR points to subfolder (i.e. PKGDIR=${PORTDIR}/packages/586) in my make.conf file.

Note: Do not get confused, it is undesireable to do –buildpkg on the slowbox586, I only do buildpkg on my x86_64 box since I have plenty of hard-drive space allocated for /usr partition.  Speaking of partition, I have my /usr as a LVM so it is easier to grow/extend the volume if and when I run out of space.

xkmake

On the same page where you can find xmerge, there is also a simple bash script to compile kernel for specific target called xkmake. Trivial as this script may be, it is quite handy. If you keep typing ARCH=”i386″ CROSS_COMPILE=”i586-pc-linux-gnu-” etc, you might as well have a script which will do the repetitive. Especially since I keep forgetting to put the “-” at the end of the CROSS_COMPILE string.

chroot

Although you cannot (at least I cannot) chroot for i586 setup, you can chroot to your i686 setup. I have a partition called /crossdev/i686 which I chroot to (just like the normal Gentoo install, you would have to mount your proc – a great example is here). Disadvantage of this of course is that the pkgdir is local. But at least some of the problems you may have with xmerge will go away in this method.

Corrections: I take back my comment about i586 not being able to chroot.  I knew there was something wrong because I’ve compiled i586 code (my own C++ projects) and I’ve been successfully able to run it on my AMD.

I was getting “segmentation fault” on the i586 bash whenever I chroot’ed to it so I’ve assumed it was the problem.  I’ve done stage3 for the i586 and I can now chroot to it.

The trick was to first backup my make.conf (specific to the i586), un-tar the stage3, restore my make.conf, chroot to it again, rebuild/emerge glibc, gcc, etc.

Because I have a symbolic link on my /usr/i568-pc-linux-gnu (and also for my 686 and MinGW32 with same idea) to link to my /crossdev/i586-pc-linux-gnu (i.e. lib -> /crossdev/i586-pc-linux-gnu/lib/) whatever I build on chroot environment will be the same as what I would compile from my x86_64 level.  The most important ones are the libs (i.e. lib/ and usr/lib).  Note that doing this may break if the glibc does not match (i.e. if you try to crossdev –target again, it may fail) so make sure to backup before you mess with it.

Kernel Compilations

If and when you chroot to your target platform (i.e. /crossdev/i586-pc-linux-gnu), and you want to compile your kernel, don’t forget to use ARCH=”i386″.  For example:

#make ARCH="i368" oldconfig
#make ARCH="i386" menuconfig
#make ARCH="i386" all

If you do not force ARCH=”i386″, menuconfig will assume x86_64 and you will not see the options for 32-bits x86 mode.  If you use xkmake instead of chroot, the script does all this for you.

Emerge From Actual Target (slow box such as i586)

When it comes to emerge from my actual i586, this is what I basically do (note: search web for more in-depth setup, I only cover the basics since there are plenty of well written how-to’s):

#mount -t nfs IP_of_my_x86_64:/exported_dir/usr/portage /usr/portage
#PKGDIR="/usr/portage/packages/568" emerge --usepkgonly -v world

Where the assumption made is on your x86_64 box, you were doing buildpkg with the package directory as PKGDIR=${PORTDIR}/packages/586 and all the packages you want are already pre-built before you do –usepkgonly on the target side.

I favor using –usepkgonly and if emerge fails, I’d chroot to my x86_64 box for i586 and emerge (with buildpkg) that missing package.  But if you want to use –usepkg and let emerge build locally (on your i586) the missing package, you do not want to mount -t nfs to the /usr/portage path.  So alternatively, you can do this:

Alternatively, you can also have PKGDIR defined to your nfs mount in the make.conf file, but this would mean that if you did –buildpkg in your emerge, it will attempt to write the binpackage to your mounted directory.  If you never intend to buildpkg on your slowbox586, then perhaps it is a better way to go since it’s inconvinient to keep typing PKGDIR for every emerge.

Current Issues

• Although my i686 works quite well in chroot, I have difficulties emerge’ing binutils under i586 (via chroot) so I have to use xmerge then chroot to it.  Once that is done, I can even re-emerge binutils in i586 (chroot’ed) and gcc works correctly.  I’m wondering if this is because I may have had “-m32″ mssing in my CFLAGS initially.

Related posts

• In the Beginning (0)
• Android: First Encounter (AT&T/Cingular) (0)
• Use your O/S to Multi-Process (0)
• nvidia-drivers + edge-triggered + noapic (0)
• LVM2 and ReiserFS (0)

Often times, I get annoyed by colleagues at work who refuses to write documentation and brag about “working smart, not hard”.  But I do not wish to write about people at work, this is my journal, my opinions about technologies, not about selfish people…

 I started Googling (I borrowed this term from Michael Swaine, one of my favorite journalist, from one of his opinion columns in Dr. Dobb’s Journal) and ran into this page http://www.bearcave.com/software/prog_docs.html and saw a comment “Since many programmers believe that the software they write is self-documenting“.  Wow!  How many time have I heard a programmer say “But I’ve already written the code, isn’t that like documention?”.  The essay (to the link) is long but well worth spending your time to read it.  The author is a vetran who has gone through many battles of software development and full of experiences and wise points.  In matter of fact, I’ve read it twice, and more I read it, I’m to think of every paragraph has a point.  So I’m not going to write about what the solution is or holy grail of documentations are.  Read the essay, and you have my point as well…

Then there is Jack Reeves, remember the article he wrote on C++ Journal about source code is a self documentation?  I agree partially, but only if we all can follow Ed Nisley (again, from Dr. Dobb’s Journal) once said “Code like you’re publishing”.  What Mr. Nisley meant in his article was that because he has a very well disciplined habbit of making an assumptions that he’ll publish his source codes some day, he writes his code very easy to read (have you ever seen any hard-to-read source codes on magazines?).  On the side note, I like Doxygen.  I’ve ran Doxygen on large scaled projects before in hopes to start the process of auto document so that I can begin to understand what it is all about.  How many of you can actually say that it has saved them days and days of their time because of Doxygen though?  Why did you run it?  It’s because you were desparte for some kind of external documentations, wasn’t it?

Being a programmer myself, and having worked professionally as a programmer since 1989, I can probably safely say that “all programmers are lazy”.  Sometimes, that’s a good thing (i.e. the K.I.S.S. rule).  I too dislike documentations, but I write them.  The main reasons why I write documentations (and I do my best the comment the crap out of my codes and use very meaningful variables – I dislike using i, j, k as my variable name) because I am quite forgetful.

Because of my forgetful nature, I document so that if I forget, I can go back to my records.  Another nature of mine is that I get distracted easily.  Having a documentation keeps me focused on my goal and not be sporadic about what I am working on.

I once read an article on Omni magazine back in the early 80′s about NASA contracting this 3rd party to write up some modules.  Back then (from what I recall vaguely about the article) it must have been assembly language (I was quite fond of 6502 so that must had made me read this article, anything with “Assembly Language” was an attention getter to me), and this company was supposed to produce a final product in 1 year.

This 3rd party contractors spent 1 year and only half of the project was complete.  So NASA dumped them and hired another 3rd party contractors.  This company decided to flow-chart first before hitting the editor (back then, flowchart was a big thing) and the contractor completed their contract in 6 months!

During my university years, in my Compiler Designs course, all the students were frantically in the lab coding throughout the entire quarter.  3 days before the project was due, although I did not know this person, one of my classmates told me that this girl just arrived to the lab with a hand-written pages of her compiler.  Apparently, this person was coding on paper all this time and never touched the editor the entire quarter.

The lab was full of compiler students that night until the morning, by the end of the night and into the morning, I was told this girl has completed typing her source code and was able to successfully get it to parse the sample test source code our compilers were supposed to verify.  The next two days, all she did was fix minor bugs and debugged.  I do not know the final outcome of her grades, but I am pretty sure she was one of the few students who had successfully got a complete/functional compiler.

The point of all these examples are that there are many types of documentations.  What works for the programmer is what should be used.  For me, I like to just work on technical design overvier and API proposals.

I often begin my documentations I submit with some introduction of “this documentation is partially to represent myself to convince my superiors that I have fully understood what they would like me to achieve”.  What I mean is that in most cases, I start the technical design documentation based on hearing what my customer (superiors) wants, then I translate it into my own words, submit it with a question of “is this what you meant?”

I don’t wish to document more than I need to, but at the same time, I will document extra on things which may save me time in the future.  Similar to FAQ’s, I would write details of what I would assume would commonly be asked by other programmers.  If it takes me 2 hours to write that part, but only takes me 30 minutes (per person) to explain it verbally, after explaining it 4 times, I’d get a return on my invested time.

One of my favorite API documentations are by Microsoft.  MSDN does an excellent job with API documentations.  I wish I had the time to be as detailed as they are, but I don’t have that time.  So I will go with the bare minimum of defining the function with its meaningful variables.  Place brief descriptions and possibly a sample code and on to next API.  If questions are asked, I will revise the documentation to clarify so if same questions are raised again, I’d ask them to read the revised documentation.

I like WIKI because of this.  Wiki makes it so easy and convinient for me to update documentations.  These days, I don’t even bother firing up my OpenOffice (or MSWord), I go straight to my Wiki page.  I run a Wiki page at home on one of my development servers.  When questions are asked, I just forward them my links.

To me, “legacy codes” will become legacy because it has stopped being maintained or became useless.  In both cases, a code is useless because others won’t use it.  If it is documented, it will be easier to encourage others to use it rather than write their own.  And maintenance means living documentation.  Again, that’s why I like Wiki.

One of the reasons why I love DirectX is because of their excellent documentation.  Remember when DirectX used to be called “Game SDK”?  That was what, back in 1996?  Has DirectX become legacy?  Nope…

Frederick Brooks writes in his book “The Mythical Man-Month” as follows:

For some years I have been successfully using the following rule of thumb for scheduling a software task:

• 1/3 planning
• 1/6 coding
• 1/4 component test and eary system test
• 1/4 system test, all components in hand.

This differs from conventional scheduling in several important ways:

1. The fraction devoted to planning is larger than normal.  Even so, it is barely enough to produce a detailed and solid specification, and not enough to include research or exploration of totally new techniques.
2. The half of the schedule devoted to debugging of completed code is much larger than normal.
3. The part that is easy to estimate, i.e., coding, is given only one-sixth of the schedule.

The point I would like to make here is that he suggests that most of the time spent on a software task is planning.  Some software engineering books would just split it into 3 parts, where 50% is design, 25% is coding and another 25% for debugging (ok, that’s exaggerated, but you get the point).

I often use the analogy of building a house as software development (it’s not my idea, I’ve seen many authors use this analogies).  And the point I want to make in my own words is that, if a carpenter has no blueprint, it may take severy months or years to build a “stable” home.  With a well-sound blueprint and plans, houses can be built in way less time.

I like UML.  These days, when I purchase books I fancy, I would usually hope that it’s in UML.  Over the years, programming languages come and go.  I’ve bought books specific to Assembly Language, C, C++, C#, Java, etc.  But what good is a book on “Data structure on C++” when I’m trying to learn data structure specifc to Python?  At least by expressing code in UML, it can (hopefully) fit to almost any language because all I want is the general idea.  I just need the highest level of design, not the details.  Just like my documentations, which I don’t go into depth of describing why I would use ++Index; rather than Index++; I do not need to know the source code in books I buy.

 A colleague brought a book on Minix to work few years back for me to look at.  Perhaps it is a bad example, but 2nd half of the book was just source code of Minix.  What a waist of paper!  Ever bought a DirectX book and discovered that 1/3 (or worse, 1/2) of the book is just a reprint of API?  Why would I need that when I can reference the API quicker on my computer?

I am never (or try not to be) attached to my code.  Ok, I do have pride, but when I think of the company I work for, I have to stop being selfish and do what’s better for the company.  I think that’s important.  Anyways, what I meant is that I am more attached to the design and idea behind what my code does.  I think lots of programmers have difficulties throwing away the code and starting from scratch.  Maybe it also involves laziness (me included).  We end up mangling and mutilating their existing code thinking it will save time but realizes after all is implemented that it would probably been more faster and easier to redo from scatch.  I think 2nd and 3rd time around is much quicker than first.  It does not matter what I do in the lowest level, what matters is that the goals and concept stays the same.  To achieve this, I think this is why I like OOP and modulizations and keeping each functions and procedures small and simple as possible…

Last but not least, I do not believe in job security.  Not to sound like a cynic, but no matter how hard we work, if the company runs out of money (one way or another), we’re laid off.  Most vetrans of software development has encountered this.  But what’s that got to do with job security?  Most programmers think that without them, the project cannot go on maintaining support because they wrote the code.  They believe that company is at her or his mercy.  If they write documentation, other programmers will figure out the secret…  Ok, maybe I’m exaggerating, but I’m not too far fetched on it, am I?

I jokingly tell my superiors “If I quit tomorrow, somebody else can pick up from where I left off because all they have to do is read my external documentations to understand my goals”.  Jokingly or not, there is half truth to that.  Programmers come and go, I’ve seen colleagues job-hop from one company to another in accelerated motion during the “dot com” days and now has a title of “technical director” and has less experience than I do.  Whatever the reason is, people move on (for better or worse).  And I think it is a good etiquette to make sure that if I move on, I won’t be cursed behind my back because they don’t understand whatta-hell-was-this-programmer-thinking-of?!?!

Related posts

• Crossdev i586 and i686 on x86_64 (0)
• Android: First Encounter (AT&T/Cingular) (0)