Re: [sqlite] SQLJet - pure Java implementation of SQLite
Our approach in the 1980s was to make the compiler. Interestingly you mention a Databus to C product wich did not flourish (as one would expect for a translator).. We produced a complete Databus compiler to a target code like Java. This product sold well and is still viable thanks to the large base of legacy Databus source. The virtual machine, like the Java VM was implemented on many architectures and would run the target code unchanged, like Java. All this predated Java and found use with OEMs distributing applications across many architectures as well as with outfits preserving their legacy ptograms. Native code implementations were merely a matter of making a native code generator for the compiler backend. Fred Williams wrote: > I think you are talking "Open Source" world now. In the late 80's, early > 90's things like Open Source Databas/Datashare compilers weren't even in > anyone's dreams. What you saw was what you got. With no open source > compilers to monkey with you just did what you had to, pretty or not. > > Somebody did later write a Databus/Datashare to C translator and the > Datapoint world beat a very deep pathway to his door! Shortly after that > Datapoint was no more and his market evaporated. > > Sorry, this ain't SQLite at all. I'm done here. > > Fred > > -Original Message- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of John Stanton > Sent: Thursday, August 13, 2009 1:32 PM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite > > > 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-user
Re: [sqlite] SQLJet - pure Java implementation of SQLite
I think you are talking "Open Source" world now. In the late 80's, early 90's things like Open Source Databas/Datashare compilers weren't even in anyone's dreams. What you saw was what you got. With no open source compilers to monkey with you just did what you had to, pretty or not. Somebody did later write a Databus/Datashare to C translator and the Datapoint world beat a very deep pathway to his door! Shortly after that Datapoint was no more and his market evaporated. Sorry, this ain't SQLite at all. I'm done here. Fred -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of John Stanton Sent: Thursday, August 13, 2009 1:32 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite 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 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLJet - pure Java implementation of SQLite
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
Re: [sqlite] SQLJet - pure Java implementation of SQLite
En/na Simon Slavin ha escrit: > We no longer have the heritage of ubiquitous high-level languages. > Fortran, Pascal, Structured Basic, and everything like that have > gone. I don't know about the situation of fortran right now and I don't really care about basic, but pascal is alive and kicking and highly portable: http://www.freepascal.org Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 (Ext.133) Fax +34 93 5883007 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLJet - pure Java implementation of SQLite
Hello Roger, > 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. When I first tried to use NestedVM for our needs (long time ago) it had a problem with file paths, in particular on Windows only those paths were working that resided on a drive C, paths with other drive letters didn't work (drive letter was truncated from a path at some moment). As I recall the problem was deep inside NestedVM code and it took significant amount of time for me to figure out what the problem is and then I recall I wasn't able to fix it more or less fast, despite the issue itself is minor. The bug itself was not the reason for not using NestedVM, but rather revealed (for me) what I called "opaqueness" - any, even minor issue in the NestedVM or code it executes would be uneasy to locate and to fix and as I understand it would not be clear whether the problem is in NestedVM code or in the code it executes. Having a library that you may "debug" into and read without efforts if needed (even if you know C, if you're deep in Java development process it is not that easy to switch) and that fits the existing infrastructure (Java in our case) seamlessly is one of the main reasons we decided to implement SQLJet instead of using NestedVM. Also, more emotional reason rather than logical one is that having a VM inside another VM gave me a feeling of something cumbersome at the moment. There also were reports that NestedVM-based JDBC driver is slow, comparing to the native one, and, I suppose, Java implementation has more space for optimization comparing to object-code execution engine. Last, but not least, Java implementation gives us an opportunity to add custom features to the database engine either breaking or keeping compatibility with SQLite database format (this reason has no relation to NestedVM of course). I like to repeat though that I think of NestedVM as of a brilliant idea and implementation, and I believe most of the users are happy with it. -- Alexander Kitaev, TMate Software, http://svnkit.com/ - Java [Sub]Versioning Library! http://sqljet.com/ - Java SQLite Library! Roger Binns wrote: > 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 ___ 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
Re: [sqlite] SQLJet - pure Java implementation of SQLite andNestedVM version
Or else, what's throwing me off is this, in http://www.zentus.com/sqlitejdbc/ "Both the pure driver and the native binaries for Windows, Mac OS X, and Linux x86 have been combined into a single jar file." [...] "Pure Java driver, always works, slowly." g -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Ribeiro, Glauber Sent: Wednesday, August 12, 2009 4:35 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite andNestedVM version I had the impression that the NestedVM version worked under Linux only, is this incorrect? g -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Roger Binns Sent: Wednesday, August 12, 2009 3:54 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Williams wrote: > I seem to remember, haven't done it in years, Borand's C and C++ compilers > could output Assembler source. One could conceivably take that output and > translate it into almost any foreign CPU's native Assembler with great > efficiency I would think. That is pretty much how NestedVM works. You compile whatever language code you want with gcc and target the MIPS processor. (MIPS is regular and simple.) NestedVM then translates the MIPS object code into Java bytecode. > Opps! Straying a long way from SQLite! Not really. There is already a Java version of SQLite built using NestedVM. The OP hasn't answered my question about why he doesn't like the NestedVM approach. The recent reimplementation of SQLite in C# shows there is interest in it being "native" for various virtual environments, but with the exception of the NestedVM approach all seem to require a lot of work just to keep up with SQLite native C source. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqDK9IACgkQmOOfHg372QS29wCgjqjMuswg2o8oQxvAMo2ZEpVK Mj4An2qeh8R0xTUkwmBmJ7l8f5MUQBVe =6LJA -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
Re: [sqlite] SQLJet - pure Java implementation of SQLite and NestedVM version
I had the impression that the NestedVM version worked under Linux only, is this incorrect? g -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Roger Binns Sent: Wednesday, August 12, 2009 3:54 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Williams wrote: > I seem to remember, haven't done it in years, Borand's C and C++ compilers > could output Assembler source. One could conceivably take that output and > translate it into almost any foreign CPU's native Assembler with great > efficiency I would think. That is pretty much how NestedVM works. You compile whatever language code you want with gcc and target the MIPS processor. (MIPS is regular and simple.) NestedVM then translates the MIPS object code into Java bytecode. > Opps! Straying a long way from SQLite! Not really. There is already a Java version of SQLite built using NestedVM. The OP hasn't answered my question about why he doesn't like the NestedVM approach. The recent reimplementation of SQLite in C# shows there is interest in it being "native" for various virtual environments, but with the exception of the NestedVM approach all seem to require a lot of work just to keep up with SQLite native C source. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqDK9IACgkQmOOfHg372QS29wCgjqjMuswg2o8oQxvAMo2ZEpVK Mj4An2qeh8R0xTUkwmBmJ7l8f5MUQBVe =6LJA -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
Re: [sqlite] SQLJet - pure Java implementation of SQLite
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Williams wrote: > I seem to remember, haven't done it in years, Borand's C and C++ compilers > could output Assembler source. One could conceivably take that output and > translate it into almost any foreign CPU's native Assembler with great > efficiency I would think. That is pretty much how NestedVM works. You compile whatever language code you want with gcc and target the MIPS processor. (MIPS is regular and simple.) NestedVM then translates the MIPS object code into Java bytecode. > Opps! Straying a long way from SQLite! Not really. There is already a Java version of SQLite built using NestedVM. The OP hasn't answered my question about why he doesn't like the NestedVM approach. The recent reimplementation of SQLite in C# shows there is interest in it being "native" for various virtual environments, but with the exception of the NestedVM approach all seem to require a lot of work just to keep up with SQLite native C source. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqDK9IACgkQmOOfHg372QS29wCgjqjMuswg2o8oQxvAMo2ZEpVK Mj4An2qeh8R0xTUkwmBmJ7l8f5MUQBVe =6LJA -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLJet - pure Java implementation of SQLite
Actually that makes a lot of sense. At the machine code level most of the programmer "style" is winnowed out. Even translating to Assembler code would be "better" than going from one high level language to another. The translator I wrote was from Databus/Datashare (Children there use to be a network of computers back in the dark ages, (Before PC) called Datapoint - Arc Net.) to Wang BASIC (Yes my sons, they built a line of general purpose computers once. Unsuccessfully I might add.) (IBM syntax). Bad choice, but the customer was just a little desperate. I seem to remember, haven't done it in years, Borand's C and C++ compilers could output Assembler source. One could conceivably take that output and translate it into almost any foreign CPU's native Assembler with great efficiency I would think. Opps! Straying a long way from SQLite! Fred -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Jim Showalter Sent: Wednesday, August 12, 2009 10:26 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite Perhaps it would be better to translate the object code. It's also possible to translate bytecode (for example, from Java to .NET). - Original Message - From: "Fred Williams" To: "General Discussion of SQLite Database" Sent: Wednesday, August 12, 2009 5:42 AM Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite > That's the problem any more it seems. Everyone "assumes" unlimited > CPU and > memory :-) > > Give a guy a Cray and he'll write one hell of a "Solitaire"! > > -Original Message- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Roger Binns > Sent: Wednesday, August 12, 2009 12:09 AM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Fred Williams wrote: >> 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 :-) > > If you read Bernstein's retrospective on qmail, one of his > suggestions is to > write code in a higher level language (especially more secure in the > sense > that C isn't such as preventing buffer & integer overflows etc) that > is then > transcoded to C. (Some conspiracy theorists looking at his code > claimed he > actually did do this :-) > > So in theory given unlimited CPU and memory it should be possible to > take > the SQLite C code and turn it into something higher level and then > turn that > back into the more verbose platforms (.NET, Java). The big > advantage of > this approach (after the upfront work) is that keeping up with > SQLite > progress is easy. > > Roger > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkqCTmwACgkQmOOfHg372QSCUwCeKD+V+e7yjYgbcF9e+lXhAbbE > U9cAoIzXPblugsswnhbgnmTNYSrkdMj7 > =VYQ3 > -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 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLJet - pure Java implementation of SQLite
On 12 Aug 2009, at 4:25pm, Jim Showalter wrote: > Perhaps it would be better to translate the object code. > > It's also possible to translate bytecode (for example, from Java to > .NET). Well since we're talking about SQLite here, another opportunity presents itself, because SQLite3 has its own bytecode which executes on a virtual machine. Divide the SQLite code into two: the code which runs the virtual machine and the rest, and implement them two different ways. You might get enhanced portability and greater flexibility. Or you might get a complete mess. See http://www.sqlite.org/opcode.html for more information. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLJet - pure Java implementation of SQLite
Perhaps it would be better to translate the object code. It's also possible to translate bytecode (for example, from Java to .NET). - Original Message - From: "Fred Williams" To: "General Discussion of SQLite Database" Sent: Wednesday, August 12, 2009 5:42 AM Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite > That's the problem any more it seems. Everyone "assumes" unlimited > CPU and > memory :-) > > Give a guy a Cray and he'll write one hell of a "Solitaire"! > > -Original Message- > From: sqlite-users-boun...@sqlite.org > [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Roger Binns > Sent: Wednesday, August 12, 2009 12:09 AM > To: General Discussion of SQLite Database > Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Fred Williams wrote: >> 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 :-) > > If you read Bernstein's retrospective on qmail, one of his > suggestions is to > write code in a higher level language (especially more secure in the > sense > that C isn't such as preventing buffer & integer overflows etc) that > is then > transcoded to C. (Some conspiracy theorists looking at his code > claimed he > actually did do this :-) > > So in theory given unlimited CPU and memory it should be possible to > take > the SQLite C code and turn it into something higher level and then > turn that > back into the more verbose platforms (.NET, Java). The big > advantage of > this approach (after the upfront work) is that keeping up with > SQLite > progress is easy. > > Roger > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkqCTmwACgkQmOOfHg372QSCUwCeKD+V+e7yjYgbcF9e+lXhAbbE > U9cAoIzXPblugsswnhbgnmTNYSrkdMj7 > =VYQ3 > -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
Re: [sqlite] SQLJet - pure Java implementation of SQLite
That's the problem any more it seems. Everyone "assumes" unlimited CPU and memory :-) Give a guy a Cray and he'll write one hell of a "Solitaire"! -Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org]on Behalf Of Roger Binns Sent: Wednesday, August 12, 2009 12:09 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] SQLJet - pure Java implementation of SQLite -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Williams wrote: > 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 :-) If you read Bernstein's retrospective on qmail, one of his suggestions is to write code in a higher level language (especially more secure in the sense that C isn't such as preventing buffer & integer overflows etc) that is then transcoded to C. (Some conspiracy theorists looking at his code claimed he actually did do this :-) So in theory given unlimited CPU and memory it should be possible to take the SQLite C code and turn it into something higher level and then turn that back into the more verbose platforms (.NET, Java). The big advantage of this approach (after the upfront work) is that keeping up with SQLite progress is easy. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqCTmwACgkQmOOfHg372QSCUwCeKD+V+e7yjYgbcF9e+lXhAbbE U9cAoIzXPblugsswnhbgnmTNYSrkdMj7 =VYQ3 -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
Re: [sqlite] SQLJet - pure Java implementation of SQLite
On 12 Aug 2009, at 6:09am, Roger Binns wrote: > If you read Bernstein's retrospective on qmail, one of his > suggestions is to > write code in a higher level language (especially more secure in the > sense > that C isn't such as preventing buffer & integer overflows etc) that > is then > transcoded to C. (Some conspiracy theorists looking at his code > claimed he > actually did do this :-) > > So in theory given unlimited CPU and memory it should be possible to > take > the SQLite C code and turn it into something higher level and then > turn that > back into the more verbose platforms (.NET, Java). The big > advantage of > this approach (after the upfront work) is that keeping up with SQLite > progress is easy. The job of translating from one computer language to another hasn't been solved yet. You'd have thought that it would, wouldn't you ? After all, it's a pure computing problem which requires only geeks who know a couple of computer languages well. But it hasn't, partly because good programmers adopt styles which suit the language they're writing in and it turns out that styles do not translate well into other languages. .NET and Java and C# and C++ and Objective-C are all C-like languages. They have many of the faults that C does and lack the portability. I suspect that Python is the most popular language which is high enough above C to do this properly. You're write a Python2C translator, then use a compiler that had extremely good optimisation routines and hope that it gave you reasonably small-and-fast resulting code. We no longer have the heritage of ubiquitous high-level languages. Fortran, Pascal, Structured Basic, and everything like that have gone. We're looking to Python and Ruby and similar languages to fill the gap but they're lower than we're used to. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLJet - pure Java implementation of SQLite
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Fred Williams wrote: > 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 :-) If you read Bernstein's retrospective on qmail, one of his suggestions is to write code in a higher level language (especially more secure in the sense that C isn't such as preventing buffer & integer overflows etc) that is then transcoded to C. (Some conspiracy theorists looking at his code claimed he actually did do this :-) So in theory given unlimited CPU and memory it should be possible to take the SQLite C code and turn it into something higher level and then turn that back into the more verbose platforms (.NET, Java). The big advantage of this approach (after the upfront work) is that keeping up with SQLite progress is easy. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkqCTmwACgkQmOOfHg372QSCUwCeKD+V+e7yjYgbcF9e+lXhAbbE U9cAoIzXPblugsswnhbgnmTNYSrkdMj7 =VYQ3 -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] SQLJet - pure Java implementation of SQLite
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
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] SQLJet - pure Java implementation of SQLite
Hello All, I'd like to invite those users who program in Java to take a look at our new project - SQLJet. SQLJet was started as part of another projects that has to work with SQLite database (SVNKit). Not to depend on native SQLite binaries or opaque NestedVM code, we've implemented part of SQLite core functionality in Java, and later moved that code to a separate project which we called SQLJet. SQLJet is an independent open source implementation of the SQLite core functionality; SQLJet provides API to read and modify SQLite database schema and data, but not to execute SQL queries yet. SQLJet project home page is at http://sqljet.com/ - you'll find mailing list, other information on SQLJet library and, of course, library itself there. We appreciate any feedback you may have on SQLJet library and we would be glad to prioritize further library development accordingly to your ideas and requests. Thanks, -- Alexander Kitaev, TMate Software, http://svnkit.com/ - Java [Sub]Versioning Library! http://sqljet.com/ - Java SQLite Library! ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
