[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Atoms



Hi Bruce,

I wouldn't think it's too much work to convert the core of atoms
(say, the conversion of xtal description to P1) and several
miscellaneous routines to C.  At least, you could probably do
the conversion in pieces, slowly moving functionality from Perl
to C without ever really breaking the higher level (tk)atoms.pl
applications.  Using a scripting language for proto-typing of
code that may eventually be written in C is one of the
commonly-hyped (if rarely done) features of such languages.

But I do think that it's important to figure out 1) if the
toolkit model is going to work at all, and 2) what constraints
(language, portability, dependence on external libraries) such a
toolkit would place on any proposed code (atoms, genfmt, autobk,
feffit, XPS functionality, ...).  Like, if you used a 'real
database library', issues of portability, dependency, and
possibly licensing could be raised.  If you use C or C++, you
have to be careful about someone wanting to call it from
fortran.  Not that it's impossible, just that it's not a given.

I'd recommend waiting until some more concrete design concepts,
working rules, and coding standards were in place.  I think
that's the highest priority.  For myself, I might be willing to
donate all or parts of ifeffit to a solid-state toolkit, if such
a thing were seriously going to be attempted.  Until there's a
real commitment from Seattle, I can only make suggestions as to
what I think ought to be done.

--Matt

 |= Matthew Newville      email: newville@cars.uchicago.edu           =|
 |= GSECARS, Bldg 434A    voice: (630) 252-0431                       =|
 |= Argonne Natl Lab      fax:   (630) 252-0443                       =|
 |= 9700 South Cass Ave   www:   http://cars9.uchicago.edu/~newville/ =|
 |= Argonne, IL 60439 USA                                             =|