In this situation it has been our approach to never try to translate source in one language into another. It is a pointlesss activity when you think about it. Much better to have the C or whatever compiler have a different code generator, for example Java target code.
You are not rev locked that way and if your C compiler optimizes well you have an efficient executable. Your JIT compiler still works. People would spend months translating program into error ridden monsters instead of spending less time working on a compiler and ending up with unchanged source with no added errors and which can be easily maintained in the origibal code with the comments still meaningful. Fred Williams wrote: > Having had the unfortunate opportunity to use a couple of language > translators as well as spending about six fruitless months developing one > which in the end was no better, I say there is no known translation that > would allow the three SQLite, "Small, Fast, Reliable" adjectives to > translate into any regurgitated language output, with the exception of > compiling SQLite source with a C++ compiler :-) > > Fred > > -----Original Message----- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Roger Binns > Sent: Tuesday, August 11, 2009 7:15 PM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite > > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Alexander Kitaev wrote: > >> Not to depend on native SQLite binaries or >> opaque NestedVM code, >> > > As a matter of interest what problem exactly do you have with NestedVM? > It's output is indeed opaque (not human comprehensible) but the same is true > of Java source versus bytecode. In both cases the input source is readable. > > It would also be interesting if anyone has built something that comprehends > the SQLite C source and then does the conversion into other languages based > on that. It would make updates a lot easier, the generation of instrumented > and test code easier, and the search for issues or optimisations easier. > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkqCCWgACgkQmOOfHg372QQXqwCeJ4pqKa89vcCAxTQOelMyoPU6 > cuQAoK6Feey6AL3pdzMgv983tn8Yg1ML > =TKoq > -----END PGP SIGNATURE----- > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users