i have written an article on using RSS feeds in computational chemistry software accessible at: http://v-ganesh.tripod.com/papers/gamess-rss.pdf
it gives an overview of an aspect of using RSS in scientific software as opposed to just using it as news aggregators.
Monday, March 28, 2005
Transition to 64 bit processor is *not* so simple :(
last week i spent in porting one of my applications written in fortran, c, python and java to a 64 bit platform (Power PC) from x86 lintel platform. the first part of putting across python and java code was as simple as just copying across and running. the problem came with c and fortran.
- after initially handling issues pertaining to compiler flags (especially nagging w.r.t to fortran), i could finally compile the whole stuff consisting of more than 50 source file with about 5000 lines each.
- then came the bombshell that integers and pointers are of different sizes. while the integer take 4bytes as usual, pointers are 8bytes long. long before when i read this in articles, i didn't realize the depth of the problem. but as well said, u'll never know swimming if u never jump in water.
- the fortran code that i was using was using a C routine to allocate memory, and guess what the integers in fortran code that were accepting the allocated address reference was 4 bytes as there is no size_t there! so i had to re-compile all the fortran code with default integer size set to 8bytes.
- after this was resolved, came another problem where a string was passed to a C function. now the funny part is the way a fortran string is passed. if you call a C function form fortran say as in following:
CALL PRNTSTR("Hello")
the C function actually receives 2 arguments and both of which must be captured, to avoid things like buffer overflows. the second argument is an integer. so the C function is declared as:
void PRNTSTR(char *Str, int Len) {...}
now here lies the problem, since i compiled all the fortran code with size of ints set to a default value of 8bytes, actually 8 bytes were passed to C function which obviously resulted in a buffer overflow and inappropriate value of Len.
- so i learned a lesson that never to use hardcoded 'int' or any other datatype in C code. a better way would be to use a #define as in:
#if defined(IBM64)
#define FORTINT 8
#else
#define FORTINT 4
#endif
note that you can pass compiler flags as in cc -DIBM64 to activate a particular definition (the correct one) form the command line it self, no need to change the source.
- there were such lot more quirks, but i felt these were quite important for me to post. and also conclude that languages like java and python are really platform independent, and the trouble of porting is taken up by system programmers than the application programmers.
- after initially handling issues pertaining to compiler flags (especially nagging w.r.t to fortran), i could finally compile the whole stuff consisting of more than 50 source file with about 5000 lines each.
- then came the bombshell that integers and pointers are of different sizes. while the integer take 4bytes as usual, pointers are 8bytes long. long before when i read this in articles, i didn't realize the depth of the problem. but as well said, u'll never know swimming if u never jump in water.
- the fortran code that i was using was using a C routine to allocate memory, and guess what the integers in fortran code that were accepting the allocated address reference was 4 bytes as there is no size_t there! so i had to re-compile all the fortran code with default integer size set to 8bytes.
- after this was resolved, came another problem where a string was passed to a C function. now the funny part is the way a fortran string is passed. if you call a C function form fortran say as in following:
CALL PRNTSTR("Hello")
the C function actually receives 2 arguments and both of which must be captured, to avoid things like buffer overflows. the second argument is an integer. so the C function is declared as:
void PRNTSTR(char *Str, int Len) {...}
now here lies the problem, since i compiled all the fortran code with size of ints set to a default value of 8bytes, actually 8 bytes were passed to C function which obviously resulted in a buffer overflow and inappropriate value of Len.
- so i learned a lesson that never to use hardcoded 'int' or any other datatype in C code. a better way would be to use a #define as in:
#if defined(IBM64)
#define FORTINT 8
#else
#define FORTINT 4
#endif
note that you can pass compiler flags as in cc -DIBM64 to activate a particular definition (the correct one) form the command line it self, no need to change the source.
- there were such lot more quirks, but i felt these were quite important for me to post. and also conclude that languages like java and python are really platform independent, and the trouble of porting is taken up by system programmers than the application programmers.
Sunday, March 27, 2005
Friday, March 25, 2005
BrainGate plugs brains into computers - (United Press International)
BrainGate plugs brains into computers - (United Press International)
This is some thing very different and a great news... especially for those less fortunate ones who have neural problems and can't handle computers and other instruments that easily.
This is some thing very different and a great news... especially for those less fortunate ones who have neural problems and can't handle computers and other instruments that easily.
Wednesday, March 23, 2005
Google Search: More, more, more
Google Search: More, more, more
Google more is just getting more :) now Google code and desktop search API are just making up a platform to attaract developers.... hope these also spread to other OSes.
Google more is just getting more :) now Google code and desktop search API are just making up a platform to attaract developers.... hope these also spread to other OSes.
Subscribe to:
Posts (Atom)