Thursday, May 26, 2011

Interface inheriting from another Interface

This post details a simple OO concept that is often ignored in many OO (or java) textbooks.
From textbook examples, we know that we can create multiple inheritance by mixing parent class and interfaces.  But hardly is there a descriptive section that details what exactly happens when a child interface is inheriting a parent interface.  This is syntactically correct in... say Java.

public interface ParentInterface {

public void DoSomething();
public void DoingSomething();

public interface ChildInterface extends ParentInterface {

public void DoSomething();

You will pass the compilation for sure.

Now let's take a look at the class that 'implements' the interface.

public class SampleClass implements ChildInterface {

public void DoSomething()

public void DoingSomething()


If you take out DoingSomething(), your compiler will flip out and blast at you.
So SampleClass needs to implement the functions in ChildInterface as well as the functions in ParentInterface. And guess what, it is most likely be calling ChildInterface's DoSomething (instead of ParentInterface's DoSomething, it doesn't matter, since there's no body anyway).

Now, if you have another class, SampleClass2, that implements ParentInterface, guess what ..

public class SampleClass2 implements ParentInterface {

public void DoingSomething() {
// TODO Auto-generated method stub


public void DoSomething() { 
// omitting this method would give you compilation error!  But this was previously declared only in ChildInterface!
// TODO Auto-generated method stub



Now in MainDriver

public static void main(String[] args) {
// TODO Auto-generated method stub
ParentInterface sc = new SampleClass();
ParentInterface sc2 = new SampleClass2(); //ChildInterface sc2 would give you error


Both sc and sc2 would allow you to call .DoSomething and .DoingSomething from ParentInterface.
In this case, ChildInterface has been completely ignored. So, polymorphism preserves but inheritance is broken(as there's nothing being reused from the ChildInterface at all).

As for practicability, this maybe of little value. But, a good point is that you only need to write 'implements ChildInterface' instead of 'implements ChildInterface, ParentInterface', but that's... not valuable at all in terms of OO.


Should improve the algorithm
by putting building a similarity matrix?
- block-based intensity comparisons.
- the lines that overlay the bridge must tell you where the bridge is.

The above may not work.

1) Maybe proceed to taking the average of neighbor points.
2) two heavy dark mass's ecliptical end points connection

Tuesday, May 24, 2011

re: NASM + Alchemy

Im currently stuck with the below situation.

[[[ hello.asm ]]]
section     .text
 global _start                       ;must be declared for linker (ld)
     int     0x80            ;system call
_start:                         ;tell linker entry point
     push    dword len       ;message length
     push    dword msg       ;message to write
     push    dword 1         ;file descriptor (stdout)
     mov     eax,0x4         ;system call number (sys_write)
     call    _syscall        ;call kernel
                             ;the alternate way to call kernel:
                             ;push   eax
                             ;call   7:0
     add     esp,12          ;clean stack (3 arguments * 4)
     push    dword 0         ;exit code
     mov     eax,0x1         ;system call number (sys_exit)
     call    _syscall        ;call kernel
                             ;we do not return from sys_exit,
                             ;there's no need to clean stack
section .data
msg     db      "Hello, world!",0xa     ;our dear string
len     equ     $ - msg                 ;length of our dear string

> alc-on
>  nasm -f macho hello.asm
> ld -e _start -o hello hello.o
> ./hello
Hello, world!
> which ar
> ar rc hello.a hello.o
llvm-nm: hello.o: unrecognizable file type
llvm-ld: warning: Ignoring file 'hello.o' because does not contain bitcode.

Let me know if there's a fix for it.

May 26th, 2011
Looks like you cannot do so.

Friday, May 20, 2011

alchemy, configure error: "checking whether we are cross compiling... configure: error:"

If you see this error:
"checking whether we are cross compiling... configure: error:"

There's a high chance that your flex_home is not in PATH
(if you cant run adl from where you are, then you will not be able to proceed with alchemy's gcc)

A remedy that i tried and worked is to set 755 to ur flex_home/bin and make sure a path to flex_home/bin is set.

Thursday, May 19, 2011

building JPEG-8 with ALCHEMY

You need definitely need a "properly" installed Alchemy.

According to FlashLibJpeg on github,
LDFLAGS="-emit-llvm" CFLAGS="-emit-llvm" ./configure --prefix="$ALCHEMY_HOME/usr/local/" enable_shared="no" enable_static="yes"
Once youve configured, a make would generate jpeg.l.bc in ./.libs directory.
Thanks Ed!

Sunday, May 15, 2011

fw: How to Make Money in Microseconds - Donald Mackenzie (Such a good reading)

This is absolutely a good reading regarding 'stock' algorithms.   If anyone who has the slightest interests regarding such topic, please read it thoroughly!!!

Absolutely Amazing, the author is a great writer!