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

Reply via email to