Shifted to Blogger

Due to space constraints on my domain, i've shifted the Logs to this Blogger.

This is a test blog through mail.

Out into the Space, Are we???

A good news poping out in the nuclear/sub-nuclear science. Scientists working on the RHIC (Relativistic Heavy Ion Colloider) project at Brookhaven Labs at NY found few remarkable results while finding the "Lost Moments" _immediately_ after the "BIG BANG". Here is a short description about the experiment performed by them.

The Gold ions are accelarated at the rate of 0.9999 times the speed of light in two separate pathways and finally allowing them to go for a head-on collision. The particles splitted and splattered are observed and the changes are noted with micro-second precision.

The remarkable finding is that, at the horizon of collision, the particle gets ripped off all its constituents to form more fundamental particles. All Quarks are stripped and they collide and the group of nucleons thus collected at the horizon behave as though they are fluids with a property to change shape with a constrained motion.

The expected intuitive result is that the shattering might have caused those particles to have dynamics similar to that of gas atoms that blow up. But this new state of matter is really intriguing. This has opened new doors to further research and a new vision into the secrecy of "FIRST FEW MICROSECONDS" after the "BIG BANG".

Get the full news here: RHIC Center

Feeling good that we are proceeding to find the secret behind the evolution but only thing is that the assumptions that we had used to build this huge empire of thoughts/experiments should hold to be true at the end.

Keys Mutated

A mere continuation of the previous post. This had to wait for many days since i was a bit occupied with the work at hand. Here goes the layout of the part of keyboard that is not working.

|Esc|
|~||!|
|Tab ||Q|
|Caps||A|
|Shift||Z|
|Ctrl||Start||Alt|

And interstingly, here is the outcome of certain experiments done on this part. Under normal circumstances, "Caps" works fine. Here goes the crazy output of experiments.

First Attempt: (Assuming Caps is off initially)
 Caps + Tab + Q = W
 Caps + Tab + A = S
 Caps + Tab + Z = X

Second Attempt:
 Caps + Tab + Q = w
 Caps + Tab + A = S
 Caps + Tab + Z = x

The above shows some kind of shift in the circuit. Another experiment with surprising results, generally when the keypad works normal, and we press two keys at a time, one which has got the connect first (ofcourse we couldnot press two keys in sync.) would be printed or one/two characters would be printed and it stops there. But the three keys, 'Q', 'A' and 'S' behave differently.

Assuming Caps lock is off initially,

Caps + Tab + Q + A + Z = WsXwsxWsXwsxWsXwsxWsXwsx

Oh! What has happened? 'A' has got some real trouble and there is a short as expected before in the keyboard circuitry and so that it connects 'S' with 'A'.

No idea, will be debugging this issue i guess this end of week.

ESC TAB ALT CTRL a z q ~ ` 1 ! Mouse

That was a tragic situation to be in. My box at home had a slight problem. It used to be there some months back and now the problem is back. Now with a new flavour

The initial problem was the disfunctional mouse, which shuts off at random intervals. Sad that the interval might be so long and is not predictable. Casual look at the problem seemed to be something to do with the OS since i'vent configured much things from the OS end. Later came to know it was not the problem with the OS but with the hardware itself. The more appropriate reasoning would be the dust accumulated in the ports. After clearing that it worked well, and was happy for a few days.

Now, the problem has repeated, but this time, with an additive, my keyboard is most of the times left-dead, meaning left portion of the keyboard, where most of my key-shortcuts would be configured is dead. There is no response when we press those keys. Thanks to GNU/Linux that does understands it needs to copy when you select text. Otherwise it would have become a nightmare copy/pasting the text. It was really restrictive to use my dear comp now . Have to fix it up. But the only puzzle now is i've cleaned up the dust in both keyboard/motherboard/mouse. Still the problem persists. This confirms the short at some point either in the keyboard circuit or the serial port connection.

How does it work at random times? Does it appears random? Have to carry out a few investigation, but now, presently, keeping mum, let the work get over

BASHing to Bake a Pointer

The BASH has become so powerful that 'pointers' can be implemented in that. Here is a small how-to on how to simulate pointers and surprisingly, you can have any level deep of pointer reference. But, dont expect too much in this, for this has to be taken as an analogy to pointer concepts and not to be taken as exact replica of the one thats done in C/C++.

HERE IS HOW TO CREATE A POINTER:

# Dont get annoyed, you can only get cheese with the milk not a pizza!

$ some_var=1729
$ some_pointer="some_var"

SOME EXPERIMENTS:
Now that the pointer variable, "some_pointer" has been created, here is how to de-reference it to get the value. This was quite interesting coz, as we imagine, the things like '$$var' and '${$var}' doesnot workout that well.

First job is to make variable get work properly. We give a variable by name, say, "some_var" and we ought to see the value "1729", so here is a try.

# This is the one we know already.

$ echo $some_var

...

# All other methods, are in vain

$ echo $$some_var # Really bad
$ echo '$'$some_var # Seems convincing..
$ echo ${$some_var} # Pathetic
...


# And finally, here comes a method, to
# refer to the value of a given variable name.
# Lets put that as a function

$ function _() { eval echo $`echo $1`; }

# Here comes...

$ _ some_pointer
some_var
$ _ some_var
1729
$


# Bingo.. things seems to work

DE-REFERENCING THE VARIABLE:
Now we have the variable de-reference function. Here we go.


$ function _() { var=$(eval echo $`echo $1`); eval echo $`echo $var`; }
$ _ some_pointer
1729
$ echo "BINGO! THAT WORKED!!!"
bash !": event not found

# A lil too much crazy

HANDLING ARRAYS IN BASH:
Now comes the best part with the 'Arrays'.

# Here is how to create an array.. requires no energy actually.

$ myarr[1]="hello"
$ myarr[2]="world"
$ myarr[3]='missing (L|W|KN)IFE'
$ myarr[fun]="really"


# Now to access an element, we should be doing this.

$ echo ${myarr[1]} # Or even as
$ echo ${myarr[fun]}


# Here is how to count the total number of elements

$ echo ${#myarr}
$ echo ${#myarr[fun]} # This gives the length.


# Here is how to access all elements in one go..

$ echo ${myarr[*]}
$ echo ${myarr[@]}


# But what is the difference? You might ask, so, try this:

$ for each elem in "${myarr[*]}"
> do
> echo "*" $elem "*"
> done
$ for each elem in "${myarr[@]}"
> do
> echo "*" $elem "*"
> done


# The difference should be visible

POINTER TO AN ARRAY:
Here we turn around to fix up our actual task of implementing pointer, we should be complete isn't? So, we also do the work of simulating pointer to an array (sounds lot of fun..).

Here is how we access n'th element of an array, or in short given a subscript and an array name, we access its value.

# For now, we limit ourself by denoting the array and subscript by variables.

$ a_var="myarr"
$ a_sub="fun"
$ eval echo '${'$a_var"[$a_sub]"'}'
really
$


# We are ready with the mode of attack and here goes our function.

$ function _() {
> a_var=$(eval echo $`echo $1`)
> a_sub=$(eval echo $`echo $2`)
> eval echo '${'$a_var"[$a_sub]"'}'
> }
$ _ a_var a_sub
really
$

# Its done

LIMITATIONS...
This is not the limitations of the BASH pointer simulation rather, limitation on the content side in Blog. Planning to write a complete pointer simulation script for BASH and hope to put that soon in my Wiki.