Signpost is a great library to quickly get OAuth login working. Makes the modern APIs quickly mashable.
I got it working on desktop for newly enabled Google Reader OAuth login mechanism. (source here)
But similar code won't run inside Android emulator. And it failed giving a high level exception OAuthCommunicationException while getting request token (1st step). After looking into Signpost code, I found this was a wrapper exception around some low level IOException. After modifying and rebuilding Signpost jar for debug statements, and jumping through several workarounds (which I am too lazy to document), I found the real root cause was the Google login server returning "411 Length required" response.
That was surprising, especially because SignPost was explicitly setting "Content-Length:0" header on that request. I tried NOT setting Content-Length, no joy. Searched a lot for oauth + signpost + 411, but no definite solution. Finally I found this post. It still has no explanation and solution, but it has a work around that worked for me.
I had to change the HTTP request from POST to GET.
Thankfully Google login server accepts the OAuth requests in both kind so that worked out for now.
It still puzzles me why should it show up only in my Android App.
Living with errors!!!
Saturday, March 27, 2010
Saturday, December 13, 2008
glxgears shows blank window
I am trying to get opengl working on my Fedora 10 macbook (2,1). glxgears seems to be a good check for that.
The video card is:
I had to do some changes to my /etc/X11/xorg.conf, now the relevant sections look like:
I restarted x-server by logging back in and glxgears started showing the rotating gears.
[Note: after doing above changes I started seeing that my display would not refresh after some intervals. The work around I am using so far is, either relogin or change to text console terminal (ctrl+alt+F2) and switch back to graphical console (ctrl+alt+F1)]
Update:
I now realize what I have done. By setting 'NoAccel' to 'True' I have turned off the acceleration in hardware. Although this makes my opengl programs work, it means all the acceraltion is done in software - as is evident from the 90+% CPU during running of these programs. It also proves that the graphics card driver fails to accelerate graphics in hardware.
This is not a big issue for me, because I am using this setup just to develop some basic opengl programs. So I can live with the CPU hog.
Also by not loading the 'intel' Driver I seem to have fixed the screen freeze problem I mentioned above. Now my xorg.conf entry looks like this:
The video card is:
I had xorg-x11-drv-i810-2.5.0-4.fc10.x86_64 installed. Yet whenevever I ran glxgears I saw blank screen.
00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME,
943/940GML Express Integrated Graphics Controller (rev 03)
I had to do some changes to my /etc/X11/xorg.conf, now the relevant sections look like:
Section "Device"
Identifier "Videocard0"
Driver "intel"
Option "NoAccel" "True"
Option "DRI" "True"
EndSection
I restarted x-server by logging back in and glxgears started showing the rotating gears.
[Note: after doing above changes I started seeing that my display would not refresh after some intervals. The work around I am using so far is, either relogin or change to text console terminal (ctrl+alt+F2) and switch back to graphical console (ctrl+alt+F1)]
Update:
I now realize what I have done. By setting 'NoAccel' to 'True' I have turned off the acceleration in hardware. Although this makes my opengl programs work, it means all the acceraltion is done in software - as is evident from the 90+% CPU during running of these programs. It also proves that the graphics card driver fails to accelerate graphics in hardware.
This is not a big issue for me, because I am using this setup just to develop some basic opengl programs. So I can live with the CPU hog.
Also by not loading the 'intel' Driver I seem to have fixed the screen freeze problem I mentioned above. Now my xorg.conf entry looks like this:
Section "Device"
Identifier "Videocard0"
Option "NoAccel" "True"
EndSection
Thursday, November 20, 2008
segfault in libselinux
#0 0x00007f471e25281d in fini_context_translations () at setrans_client.c:211
#1 0x00007f471e2452ff in __do_global_dtors_aux () from /lib/libselinux.so.1
#2 0x0000000000413c80 in ?? ()
#3 0x00007fff2c6fade0 in ?? ()
#4 0x00007f471e2540c1 in _fini () from /lib/libselinux.so.1
#5 0x00007fff2c6fade0 in ?? ()
#6 0x00007f47244ed0e4 in ?? () from /lib64/ld-linux-x86-64.so.2
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
After making some changes in my code I started getting this crash at the end of my application (during exit). No change that I made had anything to do with libselinux. I referred to this post a bit. Getting debug version of libselinux helped. But the above stack trace and the discussion in forum led me to believe this was some memory corruption that I had introduced. Running valgrind didn't help a lot.
After carefully going through all the changes, I figured out that I was now linking to the opengl library, although I hadn't enabled its use yet. When I commented it out, the crash went away. Probably the __fini__ routine of libgl was expecting some cleanup tasks from me.
#1 0x00007f471e2452ff in __do_global_dtors_aux () from /lib/libselinux.so.1
#2 0x0000000000413c80 in ?? ()
#3 0x00007fff2c6fade0 in ?? ()
#4 0x00007f471e2540c1 in _fini () from /lib/libselinux.so.1
#5 0x00007fff2c6fade0 in ?? ()
#6 0x00007f47244ed0e4 in ?? () from /lib64/ld-linux-x86-64.so.2
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
After making some changes in my code I started getting this crash at the end of my application (during exit). No change that I made had anything to do with libselinux. I referred to this post a bit. Getting debug version of libselinux helped. But the above stack trace and the discussion in forum led me to believe this was some memory corruption that I had introduced. Running valgrind didn't help a lot.
After carefully going through all the changes, I figured out that I was now linking to the opengl library, although I hadn't enabled its use yet. When I commented it out, the crash went away. Probably the __fini__ routine of libgl was expecting some cleanup tasks from me.
Friday, November 14, 2008
freeglut Internal error
freeglut (): ERROR: Internal error <Visual with necessary capabilities not found> in function fgOpenWindow
Ran into this error while trying some opengl examples from the redbook. There are some obvious reasons for this error - like absence of 3D graphics card or driver support absent for glx. But that wasn't my case.
I could solve the problem just by replacing
to
Reference thread that helped.
Ran into this error while trying some opengl examples from the redbook. There are some obvious reasons for this error - like absence of 3D graphics card or driver support absent for glx. But that wasn't my case.
I could solve the problem just by replacing
glutInitDisplayMode (GLUT_SINGLE | GLUT_INDEX);
to
glutInitDisplayMode (GLUT_SINGLE | GLUT_RGBA);
Reference thread that helped.
Thursday, November 06, 2008
scons on Maemo is old
On Maemo's latest Diablo SDK scons version is from 2004.
script: v0.96.1.D001, 2004/08/23
This breaks some scripts that would work on relatively recent scons installations.
Workaround: Install scons from source inside SDK. It's pure python code, so no architecture issues. But for some reason distutils will try to write to /scratchbox/tools/bin which has no write permissions from inside scratchbox.
So I installed inside my directory using --install-lib option of setup.py. But for scripts it would still try to write to /scratchbox/tools/bin I noticed this happens only for few executables inside scripts subdirectory. So I went outside scratchbox and 'su' copied them to those locations, chmod +x'ed them. Now they could be executed. Yet it reported that the engine was old, so I had to set SCONS_LIB_DIR to the installation in my home directory.
script: v0.96.1.D001, 2004/08/23
This breaks some scripts that would work on relatively recent scons installations.
Workaround: Install scons from source inside SDK. It's pure python code, so no architecture issues. But for some reason distutils will try to write to /scratchbox/tools/bin which has no write permissions from inside scratchbox.
So I installed inside my directory using --install-lib option of setup.py. But for scripts it would still try to write to /scratchbox/tools/bin I noticed this happens only for few executables inside scripts subdirectory. So I went outside scratchbox and 'su' copied them to those locations, chmod +x'ed them. Now they could be executed. Yet it reported that the engine was old, so I had to set SCONS_LIB_DIR to the installation in my home directory.
Wednesday, November 05, 2008
unable to set property `editable' of type `gboolean' ...
unable to set property `editable' of type `gboolean' from value of type `gchararray'
This happened when I misunderstood the parameters of TreeViewColumn->add_attribute() method. I was setting an 'editable' property to 1; whereas it should have been a boolean value.
This happened when I misunderstood the parameters of TreeViewColumn->add_attribute() method. I was setting an 'editable' property to 1; whereas it should have been a boolean value.
Sunday, November 02, 2008
X--tag=CC: command not found
autotool's idiosyncrasies!
delete ltmain.sh, run autoreconf. probably happens when the libtool version is newer and you are working with old autogenerated files.
Check this too:
http://www.mail-archive.com/libtool@gnu.org/msg10248.html
delete ltmain.sh, run autoreconf. probably happens when the libtool version is newer and you are working with old autogenerated files.
Check this too:
http://www.mail-archive.com/libtool@gnu.org/msg10248.html
Subscribe to:
Posts (Atom)