Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
I did a comparison some time back between gcc and IBM's Xlc. The IBM compiler was a bit slower to compile but the fully optimized executables were quite different in performance. Xlc's executable ran 40% faster. A look at the generated code showed that the IBM optimizer was carefully matched to the machine and would eliminate big blocks of code by taking advantage of its large register file and particular instructions. I did a less rigorous test with gcc and lcc on a PC. Lcc compiled much faster than gcc and ran much the same on well written code but gcc with better optimization ran much better on indifferent code. My conclusion was that on Intel machines gcc was the best overall compiler choice. The combination of compile speed, executable quality and compatibility with applications is hard to beat. [EMAIL PROTECTED] wrote: "C.Peachment" <[EMAIL PROTECTED]> wrote: With the suggestion that the problem was a compiler bug in PellesC for Windows, I posted a message on their forum. One response suggested a couple of configuration changes and also said to wait a while because it took a long time to compile. Fascinating. GCC (version 4.1.0) takes less than 25 seconds to compile and link a command-line shell using the amalgamation with full optimization (-O3) - which as far as I know is as slow as you can make the compiler run. With all optimization turned off, the whole thing builds in 3.430 seconds (wall-clock time). One of the reasons proffered for not using the amalgamation is that compiles go faster if you do not have to recompile the whole thing. I read that and thought "4 seconds is too slow?" But perhaps GCC is just a really fast compiler and the person who said that is just using a much slower compiler. I'm curious to see a comparison of the size and speed of the executables that result from GCC and its more sluggish competitors. Does anybody have any data? -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
time gcc -m32 -O2 -I. -I../sqliteSrc/sqlite-3.3.17/src -DNDEBUG -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -c sqlite3.c -fPIC -DPIC -o .libs/sqlite3.o real0m20.266s user0m19.773s sys 0m0.444s time gcc -m32 -O2 -I. -I../sqliteSrc/sqlite-3.3.17/src -DNDEBUG -DTHREADSAFE=1 -DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -c sqlite3.c -o sqlite3.o >/dev/null 2>&1 real0m13.050s user0m12.405s sys 0m0.336s Linux suse 10.0 (amd x2 3800) gcc version 4.0.2 20050901 (prerelease) (SUSE Linux) [EMAIL PROTECTED] wrote: "C.Peachment" wrote: > With the suggestion that the problem was a compiler bug > in PellesC for Windows, I posted a message on their forum. > One response suggested a couple of configuration changes > and also said to wait a while because it took a long time to > compile. > Fascinating. GCC (version 4.1.0) takes less than 25 seconds to compile and link a command-line shell using the amalgamation with full optimization (-O3) - which as far as I know is as slow as you can make the compiler run. With all optimization turned off, the whole thing builds in 3.430 seconds (wall-clock time). One of the reasons proffered for not using the amalgamation is that compiles go faster if you do not have to recompile the whole thing. I read that and thought "4 seconds is too slow?" But perhaps GCC is just a really fast compiler and the person who said that is just using a much slower compiler. I'm curious to see a comparison of the size and speed of the executables that result from GCC and its more sluggish competitors. Does anybody have any data? -- D. Richard Hipp - To unsubscribe, send email to [EMAIL PROTECTED] - [EMAIL PROTECTED] wrote: "C.Peachment" wrote: > With the suggestion that the problem was a compiler bug > in PellesC for Windows, I posted a message on their forum. > One response suggested a couple of configuration changes > and also said to wait a while because it took a long time to > compile. > Fascinating. GCC (version 4.1.0) takes less than 25 seconds to compile and link a command-line shell using the amalgamation with full optimization (-O3) - which as far as I know is as slow as you can make the compiler run. With all optimization turned off, the whole thing builds in 3.430 seconds (wall-clock time). One of the reasons proffered for not using the amalgamation is that compiles go faster if you do not have to recompile the whole thing. I read that and thought "4 seconds is too slow?" But perhaps GCC is just a really fast compiler and the person who said that is just using a much slower compiler. I'm curious to see a comparison of the size and speed of the executables that result from GCC and its more sluggish competitors. Does anybody have any data? -- D. Richard Hipp - To unsubscribe, send email to [EMAIL PROTECTED] - [EMAIL PROTECTED] wrote: "C.Peachment" wrote: > With the suggestion that the problem was a compiler bug > in PellesC for Windows, I posted a message on their forum. > One response suggested a couple of configuration changes > and also said to wait a while because it took a long time to > compile. > Fascinating. GCC (version 4.1.0) takes less than 25 seconds to compile and link a command-line shell using the amalgamation with full optimization (-O3) - which as far as I know is as slow as you can make the compiler run. With all optimization turned off, the whole thing builds in 3.430 seconds (wall-clock time). One of the reasons proffered for not using the amalgamation is that compiles go faster if you do not have to recompile the whole thing. I read that and thought "4 seconds is too slow?" But perhaps GCC is just a really fast compiler and the person who said that is just using a much slower compiler. I'm curious to see a comparison of the size and speed of the executables that result from GCC and its more sluggish competitors. Does anybody have any data? -- D. Richard Hipp - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
"C.Peachment" <[EMAIL PROTECTED]> wrote: > With the suggestion that the problem was a compiler bug > in PellesC for Windows, I posted a message on their forum. > One response suggested a couple of configuration changes > and also said to wait a while because it took a long time to > compile. > Fascinating. GCC (version 4.1.0) takes less than 25 seconds to compile and link a command-line shell using the amalgamation with full optimization (-O3) - which as far as I know is as slow as you can make the compiler run. With all optimization turned off, the whole thing builds in 3.430 seconds (wall-clock time). One of the reasons proffered for not using the amalgamation is that compiles go faster if you do not have to recompile the whole thing. I read that and thought "4 seconds is too slow?" But perhaps GCC is just a really fast compiler and the person who said that is just using a much slower compiler. I'm curious to see a comparison of the size and speed of the executables that result from GCC and its more sluggish competitors. Does anybody have any data? -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
Ulrich Telle wrote: drh wrote: I'm still having trouble trying to understand how managing 60 separate code files is perceived to be easier than managing just 2 files (sqlite3.c and sqlite3.h). It seems to me that the management problem gets much easier the fewer files there are to manage. In the case someone wants to use SQLite unchanged, it is certainly easier to manage only 2 files than 60+. But there are people - like myself - who would appreciate to have a source distribution containing the preprocessed source files as separate files as it was before. Not instead of the amalgamation distribution, but additionally. I don't know why others want or need the separate files, but I certainly can explain why I do: I have written an extension for SQLite using C++ which needs the preprocessed header files for compiling. Additionally I have to change the SQLite code at one place (essentially adding a single function call in the pager). The code change is not a big problem, but extracting the header files is quite inconvenient. Unfortunately I can't avoid to extract the header files since I can't merge my own code with SQLite code due to the fact, that SQLite is written in C and my extension in C++, and SQLite is not compilable in C++ mode. So, I would be grateful if the separate file distribution would return in addition to the amalgamation distribution. We have a custom function in SQLITE also (in the pager even). I would greatly prefer that the sqlite source be available as the separate files. Many years ago (1980 something) there was a DOS serial port communications library called "Async Pro" (or maybe it was "Async Plus"). It included ISRs for using serial ports on DOS, multi-port cards like Digi and Cyclades. It included Fax support (send/recv). The entire source distribution was 100+ .c and .h files. But when you compiled it, you just compiled a single master ".c" file that #included all of the other files. The compiler could do global optimizations, and the source was easy to edit. If you didn't want a feature, you just edited the master source file. Separate source files were nice, as we kept them in RCS and applied our own bug fixes to them. It would have been a pain to merge the vendor updates if everything were in one single file (especially if the vendor renamed lots of stuff or moved it around). - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
With the suggestion that the problem was a compiler bug in PellesC for Windows, I posted a message on their forum. One response suggested a couple of configuration changes and also said to wait a while because it took a long time to compile. So, I let the compiler continue after it had reported a timeout after 300 seconds. Surprise, surprise, it correctly handled the single source file and generated all necessary output components. The dll file was even smaller than the distributed image, but I can not say if that is just flagging a compile for minimum size rather than minimum processing speed. I'm happy to report that I have no reason to object to the change in preprocessed source. Thanks again Dr. Hipp for a great product. Regards, Chris Peachment - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
On 5/4/07, Ken <[EMAIL PROTECTED]> wrote: 100% concur with Dennis. Thanks again for a great product! +1 I couldn't said it better, maybe even in my native language ;-) Best regards, ~Nuno Lucas Dennis Cote <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: > > Can somebody please explain to my how 2 files is less manageable > than 60? > > > Richard, I think part of the problem is simple inertia. Some people have developed a methodology for using the sqlite source files based on the previous arrangement. They may have patches they apply to the files, existing makefiles, etc. The new amalgamation file breaks those methods. It is not backwards compatible. They had a working method and your change has broken that method. It's not that they can't make it work with the amalgamation, but rather that they don't think they should have to change their processes unnecessarily. It is also often easier to work with the individual source files rather than the amalgamation. Loading, searching and scrolling in a editor are often easier with smaller files, and it's often handy to have several files open to different locations when studying the source, which can be difficult with a single file in many editors. I really think most people who are asking for the individual files would be better served using CVS to get a particular version (if they don't want to track the latest developments in the head versions). Unfortunately, you make this a little harder than it needs to be by not tagging your releases in CVS. The lack of tags requires users to find the release date and time from the website's timeline page before retrieving the files based on that date and time. It would be easier to just select a particular CVS release tag. Using CVS has one drawback for many Windows users though, it doesn't provide the preprocessed source files. They still need to install a unix like toolset such as MinGW/MSYS or Cygwin to use the makefiles which generate those files. This adds additional complexity. I have used all the available methods at various times for various reasons. Now, I most often use the files you have prepared and distribute through your website. It is simply easier for me to let you do the work. I think many others would like you to simply add the amalgamation to the set of files you distribute, rather than replacing the preprocessed source. It will be easier for them if you continue to do the work that you used to do. I would like to take this opportunity to thank you again for all the work you have put into sqlite. You have created a tremendous resource which makes many peoples lives at least a little easier and hence better. I hope the rewards have been worth the effort. Dennis Cote - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
100% concur with Dennis. Thanks again for a great product! Dennis Cote <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote: > > Can somebody please explain to my how 2 files is less manageable > than 60? > > > Richard, I think part of the problem is simple inertia. Some people have developed a methodology for using the sqlite source files based on the previous arrangement. They may have patches they apply to the files, existing makefiles, etc. The new amalgamation file breaks those methods. It is not backwards compatible. They had a working method and your change has broken that method. It's not that they can't make it work with the amalgamation, but rather that they don't think they should have to change their processes unnecessarily. It is also often easier to work with the individual source files rather than the amalgamation. Loading, searching and scrolling in a editor are often easier with smaller files, and it's often handy to have several files open to different locations when studying the source, which can be difficult with a single file in many editors. I really think most people who are asking for the individual files would be better served using CVS to get a particular version (if they don't want to track the latest developments in the head versions). Unfortunately, you make this a little harder than it needs to be by not tagging your releases in CVS. The lack of tags requires users to find the release date and time from the website's timeline page before retrieving the files based on that date and time. It would be easier to just select a particular CVS release tag. Using CVS has one drawback for many Windows users though, it doesn't provide the preprocessed source files. They still need to install a unix like toolset such as MinGW/MSYS or Cygwin to use the makefiles which generate those files. This adds additional complexity. I have used all the available methods at various times for various reasons. Now, I most often use the files you have prepared and distribute through your website. It is simply easier for me to let you do the work. I think many others would like you to simply add the amalgamation to the set of files you distribute, rather than replacing the preprocessed source. It will be easier for them if you continue to do the work that you used to do. I would like to take this opportunity to thank you again for all the work you have put into sqlite. You have created a tremendous resource which makes many peoples lives at least a little easier and hence better. I hope the rewards have been worth the effort. Dennis Cote - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
[EMAIL PROTECTED] wrote: "Shane Harrelson" <[EMAIL PROTECTED]> wrote: This allowed me to get the benefits of the single source file (more compiler optimizations, etc.) while keeping the manageability, etc. of the separate source file. I'm still having trouble trying to understand how managing 60 separate code files is perceived to be easier than managing just 2 files (sqlite3.c and sqlite3.h). It seems to me that the management problem gets much easier the fewer files there are to manage. I know that for my own projects, the use of the amalgamation has greatly simplified configuration management. Now I have just two files (sqlite3.[ch]) that I drop into my project and I'm done. Before I had to either create an external dependency on a external SQLite library and manage that, or import 60+ code files in to a subdirectory with its own makefile, etc. What a pain. Chris Peachment points out that his "Pelles C" compiler (never heard of that one before, but presumably it has its purposes) is unable to compile sqlite3.c, presumably because the file is is too large. This is the only reason I have heard yet for wanting to use separate source file that makes any sense to me. Can somebody please explain to my how 2 files is less manageable than 60? Having multiple files means that there is sub-division of purpose. If there is known to be a problem with the function handling then one can find the code in func.c. Recompilation times can be considerably less if changes can be isolated to 1 file out of 60, with the remaining 59 being unchanged and therefore not requiring recompilation. With an amalgamation, one is forced to recompile the entire project for any single change. I would have thought that if you were so convinced that the reduced numbers of files were easier then you would have abandoned the distribution which used 60 files entirely, and switched to developing with just the 2 files. That you have not leads me to think that you find the 60 files more manageable than 2. In your example above you've cited that dropping a pair of files on to your project has made things easier for you. I don't doubt this and I quite agree. Personally I feel that having a dependency on a library is far more desireable for a project, rather than direct inclusion of the source, but that's a build issue, rather than a distribution issue. However, the point you're making is from a black-box user's point of view. The user doesn't care how it works or what it does, but just that it does what they want. Other users - those who don't treat it as a black box and wish to extend functionality or develop more usefully from the code base, and those who are (because of the environment they must work in) forced to make changes to the sources - are far more comfortable with a distribution that contains multiple files split up as a developer might want to work with. I would have said that there is scope for the 3 different forms of distribution : * The base distribution that is used for users who can run the parser. * The pre-processed distribution, as before, for those users who wish to work with the sources, but don't necessarily want to (or are unable to, because of their environment) run the parser. * The amalgamation distribution, as we have now, for those users who treat the database as a black-box and never wish to know any more than that it compiled and works. -- Justin Fletcher, Senior Software Engineer Picsel Technologies Ltd Tel: +44 141 8855588 Titanium House, Kings Inch Rd, Glasgow, G51 4BP, UK Web: www.picsel.com This email is subject to disclaimer at http://www.picsel.com/disclaimer.html - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
[EMAIL PROTECTED] wrote: Can somebody please explain to my how 2 files is less manageable than 60? Richard, I think part of the problem is simple inertia. Some people have developed a methodology for using the sqlite source files based on the previous arrangement. They may have patches they apply to the files, existing makefiles, etc. The new amalgamation file breaks those methods. It is not backwards compatible. They had a working method and your change has broken that method. It's not that they can't make it work with the amalgamation, but rather that they don't think they should have to change their processes unnecessarily. It is also often easier to work with the individual source files rather than the amalgamation. Loading, searching and scrolling in a editor are often easier with smaller files, and it's often handy to have several files open to different locations when studying the source, which can be difficult with a single file in many editors. I really think most people who are asking for the individual files would be better served using CVS to get a particular version (if they don't want to track the latest developments in the head versions). Unfortunately, you make this a little harder than it needs to be by not tagging your releases in CVS. The lack of tags requires users to find the release date and time from the website's timeline page before retrieving the files based on that date and time. It would be easier to just select a particular CVS release tag. Using CVS has one drawback for many Windows users though, it doesn't provide the preprocessed source files. They still need to install a unix like toolset such as MinGW/MSYS or Cygwin to use the makefiles which generate those files. This adds additional complexity. I have used all the available methods at various times for various reasons. Now, I most often use the files you have prepared and distribute through your website. It is simply easier for me to let you do the work. I think many others would like you to simply add the amalgamation to the set of files you distribute, rather than replacing the preprocessed source. It will be easier for them if you continue to do the work that you used to do. I would like to take this opportunity to thank you again for all the work you have put into sqlite. You have created a tremendous resource which makes many peoples lives at least a little easier and hence better. I hope the rewards have been worth the effort. Dennis Cote - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
drh wrote: > I'm still having trouble trying to understand how managing > 60 separate code files is perceived to be easier than managing > just 2 files (sqlite3.c and sqlite3.h). It seems to me that > the management problem gets much easier the fewer files there > are to manage. In the case someone wants to use SQLite unchanged, it is certainly easier to manage only 2 files than 60+. But there are people - like myself - who would appreciate to have a source distribution containing the preprocessed source files as separate files as it was before. Not instead of the amalgamation distribution, but additionally. I don't know why others want or need the separate files, but I certainly can explain why I do: I have written an extension for SQLite using C++ which needs the preprocessed header files for compiling. Additionally I have to change the SQLite code at one place (essentially adding a single function call in the pager). The code change is not a big problem, but extracting the header files is quite inconvenient. Unfortunately I can't avoid to extract the header files since I can't merge my own code with SQLite code due to the fact, that SQLite is written in C and my extension in C++, and SQLite is not compilable in C++ mode. So, I would be grateful if the separate file distribution would return in addition to the amalgamation distribution. Regards, Ulrich Telle - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
On Fri, May 04, 2007 at 14:04:24 +, [EMAIL PROTECTED] wrote: > Can somebody please explain to my how 2 files is less manageable > than 60? To my mind, the only missing feature is CPP #line directives, like #line 1 "alter.c" when contents of alter.c begins. If they are in place, everything is perfectly manageable. -- Tomash Brechko - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
Richard, For what it's worth, it would be very convenient to have shell.c included in the preprocessed source distro. sqlite3.def would also be convenient, but the nm sqlite3.o | grep ... | sed ... >>sqlite3.def method seems to correctly generate sqlite3.def on my Windows system - EXCEPT, with 3.3.15 and 3.3.16, I have to manually add "sqlite3_io_trace" to sqlite3.def to get the shell to link into sqlite3.exe. Otherwise, it fails with an "unresolved external..." error. This is on Windows XP and MS VC6 using the pre-processed C source distro. shell.c was generated on my Linux box (Red Hat 7.2) using "make target_source" after running the configure script in the "regular" source distro. The same link error occurs using the sqlite3.def file from the precompiled Windows DLL distro file. Thanks! -Clark - Original Message From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> To: sqlite-users@sqlite.org Sent: Wednesday, May 2, 2007 7:53:35 AM Subject: Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14? "C.Peachment" <[EMAIL PROTECTED]> wrote: > > After clearing these warnings, I discovered that the Pelles C > compiler was unable to complete the compilation of sqlite3.c > and timed out after 300 seconds. So it appears that I need > to revert to separate source files that were available with > earlier versions of sqlite3. > I consider this to be a bug in Pelles C. It refuses to compile a valid ANSI C program. On the other hand, this is the first argument in favor of separate source files that makes sense to me. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: Re[2]: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
Hello Dr. Hipp:
I have previously reported compiler warnings to you issued
by the Pelles C MS-Windows compiler and you have repaired
them in the following release. This is the first time I have tried
to compile the single file sqlite3.c using the compiler version 3.50
and it reported some mismatches between prototypes and
subsequent declarations for the following functions. In all
cases, the prototype used a void parameter list and the
declaration used a K style empty parameter list.
line 9820: ThreadData *sqlite3ThreadData(void){
line 9833: const ThreadData *sqlite3ThreadDataReadOnly(void){
line 9844: void sqlite3ReleaseThreadData(void){
line 9876: int sqlite3MallocFailed(void){
line 16620: void sqlite3WinEnterMutex(void){
line 16637: void sqlite3WinLeaveMutex(void){
line 64683: int sqlite3_global_recover(void){
Changing the declarations as shown above eliminated
the warnings.
After clearing these warnings, I discovered that the Pelles C
compiler was unable to complete the compilation of sqlite3.c
and timed out after 300 seconds. So it appears that I need
to revert to separate source files that were available with
earlier versions of sqlite3.
Regards,
Chris Peachment
On Mon, 30 Apr 2007 21:50:44 -0400, Teg wrote:
>Hello drh,
>I'm happy with the new source release method. I was fine with the old
>way too. The new method is slightly more convenient for me when I
>upgrade.
>C
>Monday, April 30, 2007, 5:46:19 PM, you wrote:
>dhc> Martin Jenkins <[EMAIL PROTECTED]> wrote:
>>>
>>> As fas as I know, the dev team is Dr Hipp and Dan Kennedy (apologies if
>>> there's someone else and I missed you) and I agree, it is slightly odd
>>> for neither of them to reply.
>>>
>dhc> Why is it odd? The issue is not something that needs replying
>dhc> to. This is not a bug. There has been a request for a different
>dhc> kind of partially-compiled code distribution for the convenience
>dhc> of some users. We have observed the request. What more needs to
>dhc> be said?
>dhc> --
>dhc> D. Richard Hipp <[EMAIL PROTECTED]>
>dhc>
>-
>dhc> To unsubscribe, send email to [EMAIL PROTECTED]
>dhc>
>-
>--
>Best regards,
> Tegmailto:[EMAIL PROTECTED]
>-
>To unsubscribe, send email to [EMAIL PROTECTED]
>-
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: Re[2]: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
The preprocessed source code in single files (plus def file) package would be appreciated. The number one reason for me, which make the "The Amalgamation" a show stopper: Using SQLite in an open source project usually (and also in my case) means that the source code is available on a SVN/CVS/etc. repo. There are still a lot of modem, and low bandwidth user out there and it not reasonable to transfer 2+ MB files via subversion/etc. clients, on the other side several smaller files aren't a problem at all. Some older svn/cvs clients even download the whole file each time, so the 2+ MB file IS a problem for me and for other projects as well. Additionally, the package with several smaller files allows you to apply a few small additions which can be applied after each "vendor import" using a automatic or at least semi-automatic script. Patching the Amalgamation in semi-automatic way is NOT possible in a reasonable timeframe. Why can't both packages, the "Amalgamation" package and the normal preprocessed package, co-exist? Both types are useful for different purposes, so if this sounds reasonable for you (drh et al) please add it again, thanks in advantage. Best regards, Klemens Friedl - To unsubscribe, send email to [EMAIL PROTECTED] -
Re[2]: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
Hello drh, I'm happy with the new source release method. I was fine with the old way too. The new method is slightly more convenient for me when I upgrade. C Monday, April 30, 2007, 5:46:19 PM, you wrote: dhc> Martin Jenkins <[EMAIL PROTECTED]> wrote: >> >> As fas as I know, the dev team is Dr Hipp and Dan Kennedy (apologies if >> there's someone else and I missed you) and I agree, it is slightly odd >> for neither of them to reply. >> dhc> Why is it odd? The issue is not something that needs replying dhc> to. This is not a bug. There has been a request for a different dhc> kind of partially-compiled code distribution for the convenience dhc> of some users. We have observed the request. What more needs to dhc> be said? dhc> -- dhc> D. Richard Hipp <[EMAIL PROTECTED]> dhc> - dhc> To unsubscribe, send email to [EMAIL PROTECTED] dhc> - -- Best regards, Tegmailto:[EMAIL PROTECTED] - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
[EMAIL PROTECTED] wrote: Martin Jenkins <[EMAIL PROTECTED]> wrote: I agree, it is slightly odd for neither of them to reply. Why is it odd? Because you normally reply to these things, if only to say something lie "the pre-processed source for Windows is provided as a courtesy". ;) We have observed the request. What more needs to be said? Well, it appears the OP wanted something more to be said. I was just pointing out that you might be off-site. Martin - To unsubscribe, send email to [EMAIL PROTECTED] -
RES: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
-Mensagem original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 30 de abril de 2007 18:46 Para: sqlite-users@sqlite.org Assunto: Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14? Martin Jenkins <[EMAIL PROTECTED]> wrote: > > As fas as I know, the dev team is Dr Hipp and Dan Kennedy (apologies if > there's someone else and I missed you) and I agree, it is slightly odd > for neither of them to reply. > Why is it odd? The issue is not something that needs replying to. This is not a bug. There has been a request for a different kind of partially-compiled code distribution for the convenience of some users. We have observed the request. What more needs to be said? -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] - --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003 - To unsubscribe, send email to [EMAIL PROTECTED] -
RES: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
-Mensagem original- De: Bennett, Patrick [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 30 de abril de 2007 19:28 Para: sqlite-users@sqlite.org Assunto: RE: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14? People (myself being one of them) were asking if it could be put back the way it was. Several of us (those that replied at least) stated our dislike of the new single .c file format. It was also a question (hence the subject line). No one ever replied. It seemed like something worthy of at least a reply. - Patrick Bennett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, April 30, 2007 5:46 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14? Martin Jenkins <[EMAIL PROTECTED]> wrote: > > As fas as I know, the dev team is Dr Hipp and Dan Kennedy (apologies if > there's someone else and I missed you) and I agree, it is slightly odd > for neither of them to reply. > Why is it odd? The issue is not something that needs replying to. This is not a bug. There has been a request for a different kind of partially-compiled code distribution for the convenience of some users. We have observed the request. What more needs to be said? -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] - --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003 - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
People (myself being one of them) were asking if it could be put back the way it was. Several of us (those that replied at least) stated our dislike of the new single .c file format. It was also a question (hence the subject line). No one ever replied. It seemed like something worthy of at least a reply. - Patrick Bennett -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, April 30, 2007 5:46 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14? Martin Jenkins <[EMAIL PROTECTED]> wrote: > > As fas as I know, the dev team is Dr Hipp and Dan Kennedy (apologies if > there's someone else and I missed you) and I agree, it is slightly odd > for neither of them to reply. > Why is it odd? The issue is not something that needs replying to. This is not a bug. There has been a request for a different kind of partially-compiled code distribution for the convenience of some users. We have observed the request. What more needs to be said? -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
Martin Jenkins <[EMAIL PROTECTED]> wrote: > > As fas as I know, the dev team is Dr Hipp and Dan Kennedy (apologies if > there's someone else and I missed you) and I agree, it is slightly odd > for neither of them to reply. > Why is it odd? The issue is not something that needs replying to. This is not a bug. There has been a request for a different kind of partially-compiled code distribution for the convenience of some users. We have observed the request. What more needs to be said? -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
RES: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
-Mensagem original- De: Martin Jenkins [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 30 de abril de 2007 18:25 Para: sqlite-users@sqlite.org Assunto: Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14? Bennett, Patrick wrote: > I wasn't sure who maintained the binary distribution and based on the > recent list activity, I assumed someone who was responsible would've > already replied. As fas as I know, the dev team is Dr Hipp and Dan Kennedy (apologies if there's someone else and I missed you) and I agree, it is slightly odd for neither of them to reply. In the interim, could you find an old PC, install Linux on it and build the preprocessed sources locally? Another option might be to install something like Cygwin on one of your Windows boxes. Martin - To unsubscribe, send email to [EMAIL PROTECTED] - --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.449 / Virus Database: 251 - Release Date: 27/1/2003 - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
Bennett, Patrick wrote: I wasn't sure who maintained the binary distribution and based on the recent list activity, I assumed someone who was responsible would've already replied. As fas as I know, the dev team is Dr Hipp and Dan Kennedy (apologies if there's someone else and I missed you) and I agree, it is slightly odd for neither of them to reply. In the interim, could you find an old PC, install Linux on it and build the preprocessed sources locally? Another option might be to install something like Cygwin on one of your Windows boxes. Martin - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
Ok, thanks for pointing that out. I wasn't sure who maintained the binary distribution and based on the recent list activity, I assumed someone who was responsible would've already replied. Patrick -Original Message- From: Martin Jenkins [mailto:[EMAIL PROTECTED] Sent: Monday, April 30, 2007 4:09 PM To: sqlite-users@sqlite.org Subject: Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14? Bennett, Patrick wrote: > No comment at all? That's three users asking for this now. :( Dr Hipp usually responds pretty quickly, but sometimes he's away on business. You know, supporting the paying customers... ;) Martin - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
Bennett, Patrick wrote: No comment at all? That's three users asking for this now. :( Dr Hipp usually responds pretty quickly, but sometimes he's away on business. You know, supporting the paying customers... ;) Martin - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
No comment at all? That's three users asking for this now. :( Patrick -Original Message- From: Clark Christensen [mailto:[EMAIL PROTECTED] Sent: Friday, April 27, 2007 11:12 AM To: sqlite-users@sqlite.org Subject: Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14? In general, I agree. I miss the zipped set of pre-processed C source. Since you have the Linux-based build system at your disposal, you can get what you're used to having with make target_source on the Linux system. This creates a tsrc directory containing the familiar pre-processed C source for use in your Windows build. For what it's worth, I was able to build the sqlite3.dll on Windows (VC6) from the "amalgam" sqlite3.c file without having to have lemon or any of the other SQLite-specific build components - except that pesky sqlite3.def file. I still have to download the precompiled Win32 DLL to get that. Looking at the generated makefile (from the configure script) on Linux, I see there's a rule for making sqlite3.def. The algorithm (grep ... | sed ...) basically works on Windows, using the sqlite3.obj, but the resulting def is short a few lines compared to the one I downloaded. Last, I tried to build the shell from the compiled amalgam, but it errors-out on the link phase complaining about unresolved externals (sqlite3_iotrace or somesuch). And I don't have time right now to figure it out. I'm not a C programmer, and am unfamiliar with compilers, linkers, compiler options, and all that. I usually just have to do trial and error (lots of error) and eventually I figure it out. -Clark - Original Message From: "Bennett, Patrick" <[EMAIL PROTECTED]> To: sqlite-users@sqlite.org Sent: Friday, April 27, 2007 6:57:38 AM Subject: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14? The last time I downloaded SQLite was version 3.3.12. For that version (and many prior versions), I could download a preprocessed archive containing all of the source code, except parse.h, parse.c and opcode.h(? - this is from memory) were the 'generated' versions. The source for the command-line shell was there as well as all other source code. This was close to ideal for me, as I was able to use it in our (custom) build system and build for Windows and Linux with almost no effort at all. Now, I have two choices: 1) Download a tar of everything and have a version of lemon available (which nothing else here uses), as well awk and other tools which don't fit well within our windows-side compiles, or.. 2) Download a preprocessed archive that contains only two files (sqlite3.c and sqlite3.h) losing the ability to easily track changes (or make local patches / fixes if necessary) as well as no longer having the shell code. I'll have to download both archives and piece together my own build. Hopefully this doesn't come off as too much of a nag, but the way it was before was quite convenient and the new method seems to have taken the 'preprocessed' notion to the extreme. If this is how it's going to be from now on, I'll just have to adjust, but if there wasn't any specific reason for changing, you can count this as a vote for the 'old' way. :) Cheers... Patrick Bennett - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
Please provide the processed source package, as it has been the case for SQLite before. "The Amalgamation" big c file (plus header file) might be an (optional) neat package, but the standard processed source package shall be still available. The http://www.sqlite.org/sqlite-source-3_3_17.zip shall link to the processed source package, and another URI shall link to the amalgamation package. Maybe it's an option for you. Every non unix user will thank you! Best regards, Klemens Friedl - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
In general, I agree. I miss the zipped set of pre-processed C source. Since you have the Linux-based build system at your disposal, you can get what you're used to having with make target_source on the Linux system. This creates a tsrc directory containing the familiar pre-processed C source for use in your Windows build. For what it's worth, I was able to build the sqlite3.dll on Windows (VC6) from the "amalgam" sqlite3.c file without having to have lemon or any of the other SQLite-specific build components - except that pesky sqlite3.def file. I still have to download the precompiled Win32 DLL to get that. Looking at the generated makefile (from the configure script) on Linux, I see there's a rule for making sqlite3.def. The algorithm (grep ... | sed ...) basically works on Windows, using the sqlite3.obj, but the resulting def is short a few lines compared to the one I downloaded. Last, I tried to build the shell from the compiled amalgam, but it errors-out on the link phase complaining about unresolved externals (sqlite3_iotrace or somesuch). And I don't have time right now to figure it out. I'm not a C programmer, and am unfamiliar with compilers, linkers, compiler options, and all that. I usually just have to do trial and error (lots of error) and eventually I figure it out. -Clark - Original Message From: "Bennett, Patrick" <[EMAIL PROTECTED]> To: sqlite-users@sqlite.org Sent: Friday, April 27, 2007 6:57:38 AM Subject: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14? The last time I downloaded SQLite was version 3.3.12. For that version (and many prior versions), I could download a preprocessed archive containing all of the source code, except parse.h, parse.c and opcode.h(? - this is from memory) were the 'generated' versions. The source for the command-line shell was there as well as all other source code. This was close to ideal for me, as I was able to use it in our (custom) build system and build for Windows and Linux with almost no effort at all. Now, I have two choices: 1) Download a tar of everything and have a version of lemon available (which nothing else here uses), as well awk and other tools which don't fit well within our windows-side compiles, or.. 2) Download a preprocessed archive that contains only two files (sqlite3.c and sqlite3.h) losing the ability to easily track changes (or make local patches / fixes if necessary) as well as no longer having the shell code. I'll have to download both archives and piece together my own build. Hopefully this doesn't come off as too much of a nag, but the way it was before was quite convenient and the new method seems to have taken the 'preprocessed' notion to the extreme. If this is how it's going to be from now on, I'll just have to adjust, but if there wasn't any specific reason for changing, you can count this as a vote for the 'old' way. :) Cheers... Patrick Bennett - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14?
The last time I downloaded SQLite was version 3.3.12. For that version (and many prior versions), I could download a preprocessed archive containing all of the source code, except parse.h, parse.c and opcode.h(? - this is from memory) were the 'generated' versions. The source for the command-line shell was there as well as all other source code. This was close to ideal for me, as I was able to use it in our (custom) build system and build for Windows and Linux with almost no effort at all. Now, I have two choices: 1) Download a tar of everything and have a version of lemon available (which nothing else here uses), as well awk and other tools which don't fit well within our windows-side compiles, or.. 2) Download a preprocessed archive that contains only two files (sqlite3.c and sqlite3.h) losing the ability to easily track changes (or make local patches / fixes if necessary) as well as no longer having the shell code. I'll have to download both archives and piece together my own build. Hopefully this doesn't come off as too much of a nag, but the way it was before was quite convenient and the new method seems to have taken the 'preprocessed' notion to the extreme. If this is how it's going to be from now on, I'll just have to adjust, but if there wasn't any specific reason for changing, you can count this as a vote for the 'old' way. :) Cheers... Patrick Bennett - To unsubscribe, send email to [EMAIL PROTECTED] -
