Enough is enough, i seriously don’t think i’m built to use any online blogging engines. Simply because i’m built to prefer typing in my terminal, using vim, and prefer playing with terminal-interfaced stuff, instead of so called idiot-proof online tools … i guess i’m probably more idiot than idiots.
Moreover, blogspot is blocked by the great wall of china (at least this is what i’ve encountered in shanghai), and though i can continue to access it via some customized proxy settings, it is terribly slow, slow & slow. In fact, i find it amazing that i am able to bear with it for so long …
Anyway, enough is enough, here i am, back to basics, typing my blog in vim, on the engine side, i’m using the git-based blogging engine shinmun, and deploying it at heroku …
Ha, it cannot be any easier than what i have now … what a wonderful world !!
(i'm gradually do the migration to the newer blog, as and when i find time)
Thursday, August 19, 2010
Friday, August 13, 2010
Benchmarking any rake task
While writing serializable_proc, i wanted to find out how the RubyParser-based implementation fair against ParseTree-based one, here's a rake task i've written to support the following use cases:
And:
And here's the code to acheive the above:
And here's the output i get for the x2 run:
# yield benchmark results by running :spec task x5 (default)
$ rake benchmark[spec]
And:
# yield benchmark results by running :spec task x2
$ rake benchmark[spec,2]
And here's the code to acheive the above:
1 | # Benchmarking |
And here's the output i get for the x2 run:
...
(blah blah, the output of running :spec task x2)
...
===============================================
~ Benchmark Results for Task :spec ~
nth user system total real
#1 0.000000 0.000000 1.030000 1.052567
#2 0.000000 0.000000 1.020000 1.040352
===============================================
Friday, August 6, 2010
Reliably getting a formatted time string in ur desired lang
Today, i'm spent quite abit of time playing with the very simple Time#strftime:
What i want to acheive is to reliably get the chinese version:
I've tried playing with the environment variable $LANG:
Seems good, but nope, Time#strftime still gives me the same english output. I've trying recompiling a different ruby using rvm with the exported $LANG ... nope, doesn't work either. It seems that not matter how $LANG is set (thus affecting LC_TIME), ruby just doesn't care abt it. Yet, i swear that on flyhzm's machine, he has been getting the chinese version, no matter how hard he has tried to get the english version.
Battled, beaten & worn out, i've concluded that the most reliable way (and definitely what most people do), is to use the i18n. Given i already have this /path/to/i18n.yml:
The following works for mri 1.9.1:
Without modication, i got the following unfriendly output for the chinese port under mri 1.8.7, jruby & ree-1.8.7:
After much googling, stumbled across this post abt $KCODE. Here's the final modified code for the 1.8.7 equivalents:
For people doing rails, here are some useful resources:
* http://guides.rubyonrails.org/i18n.html
* http://github.com/svenfuchs/rails-i18n
1 | puts Time.now.strftime("%B %d, %Y %H:%M") |
What i want to acheive is to reliably get the chinese version:
八月 06, 2010 17:24
I've tried playing with the environment variable $LANG:
$ export LANG=zh_CN.utf8
$ locale
LANG=zh_CN.utf8
LC_CTYPE="zh_CN.utf8"
LC_NUMERIC="zh_CN.utf8"
LC_TIME="zh_CN.utf8"
LC_COLLATE="zh_CN.utf8"
LC_MONETARY="zh_CN.utf8"
LC_MESSAGES="zh_CN.utf8"
LC_PAPER="zh_CN.utf8"
LC_NAME="zh_CN.utf8"
LC_ADDRESS="zh_CN.utf8"
LC_TELEPHONE="zh_CN.utf8"
LC_MEASUREMENT="zh_CN.utf8"
LC_IDENTIFICATION="zh_CN.utf8"
LC_ALL=
Seems good, but nope, Time#strftime still gives me the same english output. I've trying recompiling a different ruby using rvm with the exported $LANG ... nope, doesn't work either. It seems that not matter how $LANG is set (thus affecting LC_TIME), ruby just doesn't care abt it. Yet, i swear that on flyhzm's machine, he has been getting the chinese version, no matter how hard he has tried to get the english version.
Battled, beaten & worn out, i've concluded that the most reliable way (and definitely what most people do), is to use the i18n. Given i already have this /path/to/i18n.yml:
1 | en: |
The following works for mri 1.9.1:
1 | require 'rubygems' |
Without modication, i got the following unfriendly output for the chinese port under mri 1.8.7, jruby & ree-1.8.7:
\345\205\253\346\234\210 06, 2010 20:27
After much googling, stumbled across this post abt $KCODE. Here's the final modified code for the 1.8.7 equivalents:
1 | require 'rubygems' |
For people doing rails, here are some useful resources:
* http://guides.rubyonrails.org/i18n.html
* http://github.com/svenfuchs/rails-i18n
Wednesday, August 4, 2010
Bitten by Array#*
Have u tried Array#* ? Its a pretty cool way to return an array, built by concatenating the original array by n times:
However, u should be aware that all elements of the new array actually points to the same instance, as proven by their object_id:
This means that:
1 | a = [1] * 2 |
However, u should be aware that all elements of the new array actually points to the same instance, as proven by their object_id:
1 | x = 'a' |
This means that:
1 | # Reassigning one element does not affect another |
Subscribe to:
Posts (Atom)