Re: [fossil-users] New Tree-View feature requires newer sqlite.
2014/1/8 Joseph R. Justice jayare...@gmail.com: Ummm... One other quite possibly naive question. I browsed in the Fossil sources briefly related to the tag you mentioned previously, the sqlite-min-to-3.7.17 tag, and if I'm understanding what I see correctly, you're doing the check for the minimum supported version based on if SQLite is reporting if specific capabilities are available, apparently on the grounds that if a given capability is available then that means the version of SQLite available is at least X. The reason for this approach is as follows. Although the tag suggests that configure checks for a minimal version of 3.7.17, in reality a check is done for the availability of the sqlite3_strglob() function. I happen to know that this function is introduced in SQLite 3.7.17. It might happen that some OS maintainers discover an unacceptable security risk in the sqlite3_strglob() function and decide to distribute a patched SQLite 3.7.17 in which the sqlite3_strglob() function is not exported to applications. In that case an implicit version check in Fossil would succeed, but it would be a lie. For this reason a real capability check is always better than an implicit version check. In other words, require-sqlite_strglob would have been a better name for this Fossil tag. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
2014/1/7 Joseph R. Justice jayare...@gmail.com: I assume you do not mean here that Fossil v 1.28 should be released concurrently with SQLite release v 3.8.3, but instead that Fossil v 1.28 should be released when it is ready on or after the moment that SQLite release v 3.8.3 is tagged (be that a day, a week, a month, whenever) such that the source for the SQLite release v 3.8.3 can be incorporated within the source for Fossil v 1.28. Yes, sure, that's exactly what I mean. May I ask why that run-time check cannot or should not be made in the release version of Fossil 1.28, rather than immediately after it is tagged such that it will only take effect in a release version for Fossil 1.29? It's fully up to the Fossil-devs what should be the minimum SQLite version Fossil is supposed to work with, and when this minimum is updated to higher SQLite versions. My proposal is based on a SQLite 3.8.3 release in February 2014. If that changes or if the Fossil developers want to move forward faster than that, it is very well possible. For Cygwin that wouldn't be a problem, as SQLite 3.8.2 is already available now as Cygwin package. For other OS distributions I don't know, I'll leave it to others to comment on that. I would agree that, unless part of the purpose (either explicit or implicit) for Fossil's existence is to act as a showcase and testbed for the latest and greatest available version of SQLite, there is no need to tie releases of Fossil to releases of SQLite. Release versions of Fossil should be made when they are appropriate and when they are ready, which does not necessarily have anything to do with the release schedule of SQLite. I agree. It would be possible to make a Fossil release at any time, independent from SQLite. As long as Fossil doesn't use any SQLite features which are not available yet in the latest SQLite release, either the latest SQLite amalgamation could be shipped with it, either the latest SQLite trunk amalgamation. The latter choice means more risk, however small in practice. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
On Mon, Jan 6, 2014 at 7:52 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: at (1): Supporting every SQLite 3.7.x release is madness, SQLite 3.7.17 is more than 7 months old now, that should be enough time for whatever distribution to upgrade to it. That depends on what other packages are using SQLite and how important the distro maintainers think the the other packages are. Even when the upstream devs of a library assert the ABI has not changed, the distro maintainers tend to be quite conservative about when to update libraries. This is because even if the ABI has not changed, the results returned may have changed in a way that breaks something else. The best way to encourage distro maintainers to stay more up to date with a library is for the library devs to also provide an exhaustive regression suite that the distro maintainers can use. And, when the results of any of these tests change, provide detailed explanations as to why the results changed. (I have, in the past, talked to a few distro maintainers. Also, my company's validation testers demand our (product engineering) test reports so they can better understand the changes we made.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
2014/1/6 Jan Nijtmans jan.nijtm...@gmail.com: (4) Immediately after the fossil 1.28 release, add a runtime-check for SQlite 2.8.2 (as suggested by Joe Mistachkin), and add WITHOUT ROWID to whatever SQL statement it is useful. Unconditionally! Implementation here: http://fossil-scm.org/index.html/timeline?r=sqliteRuntimeCheck Thanks, Joe! That's exactly what I meant, and which allows the (ugly) condition to be removed! Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
On Tue, Jan 7, 2014 at 4:37 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014/1/7 Joseph R. Justice jayare...@gmail.com: May I ask why that run-time check cannot or should not be made in the release version of Fossil 1.28, rather than immediately after it is tagged such that it will only take effect in a release version for Fossil 1.29? It's fully up to the Fossil-devs what should be the minimum SQLite version Fossil is supposed to work with, and when this minimum is updated to higher SQLite versions. My proposal is based on a SQLite 3.8.3 release in February 2014. If that changes or if the Fossil developers want to move forward faster than that, it is very well possible. For Cygwin that wouldn't be a problem, as SQLite 3.8.2 is already available now as Cygwin package. For other OS distributions I don't know, I'll leave it to others to comment on that. I fully agree that it's up to the Fossil upstream devs as to what should be the minimum version of SQLite supported with any given release version of Fossil, and also as to when the minimum version of SQLite supported should be changed (and what it should be changed to). My thought here was that the devs (or at least Dr. Hipp as the architect) seem to desire to make the minimum supported version of SQLite be 3.8.2 *now*. If that's so, why make them wait for a full release version of Fossil (e.g. until development begins for Fossil 1.29) before they can make that change? After all, it's the distributions' problem to provide the SQLite library version Fossil upstream requires, or else to patch Fossil to work with whatever version of SQLite the distribution is willing to provide. (But... See below for a countervailing point.) Ummm... As a sort of aside, I'd like to point out one thing here for the benefit of the Fossil upstream devs, on the off chance they have not yet considered it. It's something I think is a sort of corollary / consequence of what we're talking about that's obvious when you think about it carefully, but which might be easy to overlook at a first quick glance. (Ron Wilson's message kind of refers to this, but does not state it explicitly.) I'd like to explicitly state it for the record. Okay. Again, Fossil upstream devs ARE NOT REQUIRED to support using a given release version of Fossil with any random old version of SQLite a end-user (or distribution) wishes to use. The upstream devs have the right to say We only support using this release version of Fossil with at least version XY.ZZ.Y of SQLite, and will not support using this version of Fossil with any older version of SQLite. The upstream devs are (in general) all unpaid volunteers, and as such have the right to set whatever limit on support they want to set. However... Just as are the Fossil upstream devs, the developers / packagers of a given FOSS Unix/Linux distribution *are* *also* (in general) unpaid volunteers, and as such *do* *also* have the right to set whatever limit on support *they* (the distribution developers / packagers) want to set! In particular, *they* have the right to say We only support SQLite with a maximum release version of BL.EG.H, and any software which requires a version of SQLite more recent than this version is not supportable by us and we will not package and distribute it in our current version of the distribution. The distributions ARE NOT REQUIRED to support or distribute software which needs any random new version of SQLite a developer wishes to use! This means that if the minimum supported version of SQLite the Fossil upstream devs require for their new release version is XY.ZZ.Y, and the maximum supported version of SQLite the distribution developers will provide for their current release version of the distro is BL.EG.H, and XY.ZZ.Y BL.EG.H, then the new release version of Fossil will not be made available for that version of the distribution (at least until they raise their maximum supported version of SQLite), and the new release version of Fossil may not even be *useable* on that version of the distribution! Insofar as the Fossil upstream devs *desire* their current version of Fossil to be packaged and distributed by the various distributions (as opposed to requiring end-users to compile / install Fossil on their own), *this* is the problem of Fossil upstream -- to limit themselves to using only versions of libraries which are actually available within the various distributions (the major ones anyway) they want to have distribute their software. Now, I'll grant that Fossil, by its intrinsic nature and primary intended target audience (e.g. that it is a software development tool intended for use by software developers), isn't as constrained by this as would be an application intended for use by typical non-technical end-users, such as say an office productivity application or a financial / bookkeeping application, or a game, or whatever. Fossil can say you're a developer, you know how to compile
[fossil-users] New Tree-View feature requires newer sqlite.
2014/1/4 Richard Hipp d...@sqlite.org: OK, so I propose the following fix: (1) Move [bd1151126a] into a branch. (2) Remove the --disable-internal-sqlite option on trunk. Require the use of the built-in SQLite only, since SQLite needs to be built with non-standard compile-time options to fully meet the needs of Fossil. (3) Cherry-pick check-ins after [bd1151126a] onto the trunk. (4) When distributions complain, we simply explain that we tried using an external SQLite but it introduced too many complications and bugs and that we now require statically linking SQLite for reasons of security and reliability. Comments? How about this counter-proposal? Explanation follows: (1) Update fossil to require SQLite 3.7.17 as a minimum in stead of the current SQLite 3.7.0. See: http://fossil-scm.org/index.html/timeline?r=sqlite-min-to-3.7.17 (2) Eliminate the strglob() function from fossil, use the sqlite3_strglob() function (available since SQLite 3.7.17) instead. I tested this change: all unit-tests work fine. (3) After SQLite 3.8.3 is released, release fossil 1.28 with the EXACT SQLite 3.8.3 amalgamation included. (4) Immediately after the fossil 1.28 release, add a runtime-check for SQlite 2.8.2 (as suggested by Joe Mistachkin), and add WITHOUT ROWID to whatever SQL statement it is useful. Unconditionally! (5) Future official fossil release should contain an official released SQLite amagalmation as well, but less frequent: There is no need to make a new Fossil release after each SQLite release. I think this counter-proposal will gain a lot more sympathy to the various package-maintainers. And it has more advantages. Explanation: at (1): Supporting every SQLite 3.7.x release is madness, SQLite 3.7.17 is more than 7 months old now, that should be enough time for whatever distribution to upgrade to it. at (2): Code duplication is always bad. Requiring SQLite 3.7.17 as a minimum makes sure the sqlite3_strglob() function is available. That's an immediate gain. at (3): Advantage: official SQLite releases are better tested than intermediate ones. Fossil 1.27 contains a SQLite 2.8.1 beta with a bug which is crucial on Cygwin. See: http://osdir.com/ml/sqlite-users/2013-12/msg00193.html This bug is discovered during release testing of SQLite 2.8.2 (when I became Cygwin's SQLite maintainer), if fossil would have been compiled with --disable-internal-sqlite the bug would have been fixed now. at (4): If SQLite 2.8.3 is released around February, then a reasonable Fossil 1.29 release could be done mid 1014. That's more than enough time for whatever distribution to upgrade to SQLite 2.8.2. And it means that starting one month from now Fossil developers don't need to worry about WITHOUT ROWID support: just use it whenever appropriate. at (5): This means that part of the pre-release testing of every Fossil release should be a test using --disable-internal-sqlite, in order to verify that Fossil really works well with the lowest SQlite version it is documented to work with. I volunteer to do this pre-release test. On Cygwin, keeping --disable-internal-sqlite would have the advantage that fossil can take advantage of the improved win32-longpath VFS (and the new unix-cygwin VFS) without the Fossil maintainer (Jari Aalto) having to replace the SQLite amagalmation with every new Fossil release. As soon as the Cygwin enhancements are adopted by SQLite (in whatever modified form), --disable-internal-sqlite doesn't give any advantage on Cygwin any more. But as long as that doesn't happen, I hope that --disable-internal-sqlite will be kept as-is. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
On Mon, Jan 6, 2014 at 7:52 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014/1/4 Richard Hipp d...@sqlite.org: (3) After SQLite 3.8.3 is released, release fossil 1.28 with the EXACT SQLite 3.8.3 amalgamation included. I assume you do not mean here that Fossil v 1.28 should be released concurrently with SQLite release v 3.8.3, but instead that Fossil v 1.28 should be released when it is ready on or after the moment that SQLite release v 3.8.3 is tagged (be that a day, a week, a month, whenever) such that the source for the SQLite release v 3.8.3 can be incorporated within the source for Fossil v 1.28. (4) Immediately after the fossil 1.28 release, add a runtime-check for SQlite 2.8.2 (as suggested by Joe Mistachkin), and add WITHOUT ROWID to whatever SQL statement it is useful. Unconditionally! I assume here (and below) you mean SQLite 3.8.2, not 2.8.2 (and 3.8.3 instead of 2.8.3). I also assume you mean here that it be a runtime check requiring that *at* *least* SQLite 3.8.2 is available to Fossil (e.g. SQLite 3.8.2 *or later*), rather than a runtime check requiring that SQLite 3.8.2 *exactly* be available to Fossil. (Otherwise, Fossil builds using the embedded code copy of SQLite would fail at runtime, because you've just specified the embedded code copy of SQLite for this version of Fossil is 3.8.3 and not 3.8.2.) May I ask why that run-time check cannot or should not be made in the release version of Fossil 1.28, rather than immediately after it is tagged such that it will only take effect in a release version for Fossil 1.29? Sure, it means that distributions cannot distribute Fossil 1.28 (as released by Fossil upstream) using a system-provided shared library version of SQLite until they have updated that system-provided shared library version of SQLite to 3.8.2 from whatever version they currently have (call it v XY.ZZY), but so what? Distributions are used to this sort of thing, applications requiring a version of a system-provided library more recent than the version they currently make available. The distributions will just have to (1) provide a new version of the system-provided shared library version of SQLite that is sufficiently recent for Fossil v 1.28's needs (presumably either SQLite 3.8.2 or 3.8.3 at their discretion); (2) make sure that all the other applications they distribute that depend on SQLite, which currently work with SQLite v XY.ZZY, will work properly with the new version of SQLite whatever it ends up being, and patch or update those other applications as necessary; (3) make Fossil 1.28, the new version of SQLite, and any new versions of other apps available to their end-users, which the end-users can update to if and as they see fit to. (Well, unless the distributions patch their copy of Fossil v 1.28 to use their copy of SQLite v XY.ZZY, but they do that at their own risk and are responsible for all support of that combination. Fossil upstream devs will not support that combination of software.) This will require all end-users to update their copy of SQLite and possibly other applications depending on SQLite if they want to use the new release version of Fossil, but again so what? That's what distribution packaging, and distribution software update tools, are all about; to make sure that sort of thing works, everything is consistent and supported, etc. (5) Future official fossil release should contain an official released SQLite amagalmation as well, but less frequent: There is no need to make a new Fossil release after each SQLite release. I would agree that, unless part of the purpose (either explicit or implicit) for Fossil's existence is to act as a showcase and testbed for the latest and greatest available version of SQLite, there is no need to tie releases of Fossil to releases of SQLite. Release versions of Fossil should be made when they are appropriate and when they are ready, which does not necessarily have anything to do with the release schedule of SQLite. Further, release versions of Fossil should not necessarily require using the latest and greatest release version of SQLite, unless features and bug-fixes only available in that version of SQLite are required by the release version of Fossil to be made. Instead, release versions of Fossil should only require using the oldest version of SQLite providing the features that version of Fossil needs which the Fossil devs *are* *willing* *to* *support* for that version of Fossil. (If the Fossil devs say We only support using the latest and greatest release version of SQLite available at the time we made this release version of Fossil, well then so be it. The Fossil devs are volunteers, presumably not being paid (in general) to develop and support Fossil, and are not required to do anything they do not want to do.) In particular... If Fossil version M requires using SQLite version N, and if Fossil version M+1 does not require any
Re: [fossil-users] New Tree-View feature requires newer sqlite.
On Thu, Jan 2, 2014 at 9:52 PM, Nico Williams n...@cryptonector.com wrote: More generally, trying to ensure that a) there's only one copy of every library in the distro/OS, b) all version dependencies match up, is *super* hard, if not impossible. Eventually there are some very commonly used libraries where the simplest thing to do is to just ship multiple versions, but first the distro maintainer ought to make sure that the POSIX file locking disaster you mention can't happen as a result. If I may ask, because I'm confused... Is your position on distributions trying to ensure that there is only one copy of every library in the distribution by desiring (or even requiring mandatory) use by distribution-distributed applications of shared system/distribution-provided versions of libraries (instead of allowing applications to have and use private copies of libraries) that they need that: (a) it is generally a good or desirable thing (albeit a super hard task); (b) it is generally a bad or undesirable thing; (c) you have no position either way on whether it is good or bad, you are merely noting for the record that to do it is a super hard or even impossible task for the distributions; and/or (d) something else altogether (and if so what if you are willing to say)? Also, I'm curious about your claim that there are some very commonly used libraries where the simplest thing to do is to just ship multiple versions. I am *not* saying this is not the case, because I simply do not know! I haven't even attempted to do the research (nor am I sure how or if the research could be easily done). I'm certainly willing to accept that what you say on this is true. I am wondering however if you could identify some of these libraries and/or the distributions which ship multiple copies of them, at least if there are any that spring quickly to your mind. (Note, I do *not* consider that if you do or can not identify any such libraries or distributions that this means your claim about them is not true! It just means that while you might have encountered them in the past you haven't done so recently enough to recall them easily in response to a casual request.) Thanks for giving me a moment of your time. Hope this is of some use, interest. I look forward to seeing any response to this query you might care to make. Joseph ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
On Thu, Jan 2, 2014 at 2:04 PM, Joseph R. Justice jayare...@gmail.comwrote: Further, in the embedded software world at least, I expect it is often difficult or even impossible to update software in the first place to patch bugs or provide new functionality, so there is no need much less desire to worry about making it *easier* to update software; if you can't update it at all, or can only update it in the first place with the very greatest of effort for only the most critical of reasons (such as bugs which are potentially life-threatening or would cost untenable financial losses if they are not fixed), who cares if it's a only a little more difficult, relatively speaking, to update a library. Speaking as an embedded SW developer, I can tell you that the actual SW changes, and preparing the release package is easy. Actually making the release, though, is a big deal. After preparing the release package, we do regression testing. While a lot of this is automated, changes to physical inputs (switches, sensor, etc) and checking of physical outputs (indicators, motors, etc) is done manually, so these tests can take many hours. Once those tests have passed, we turn the release package over to the validation team, who preform their own (independently created) suite of tests. Once validation gives a pass, we send copies of the package to manufacturing and to our customer service organization. There is also documentation to prepare, which we can mostly complete in parallel with validation. (The validation team has access to the issue tickets, so we only need to give them a list of the ticket numbers applicable to the release.) We do use 3rd party libraries. The difference is that we have full control over what versions of each library are used. There is no one downstream from us repackaging our SW. The binaries we release are exactly what goes into the devices we created the SW for. BTW, the singular of data is datum. Over time, data set has been shortened to data, so data, as a noun, has become like sheep, which is both singular and plural. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
On Fri, Jan 3, 2014 at 1:22 PM, Ron Wilson ronw.m...@gmail.com wrote: On Thu, Jan 2, 2014 at 2:04 PM, Joseph R. Justice jayare...@gmail.comwrote: Further, in the embedded software world at least, I expect it is often difficult or even impossible to update software in the first place to patch bugs or provide new functionality, so there is no need much less desire to worry about making it *easier* to update software; if you can't update it at all, or can only update it in the first place with the very greatest of effort for only the most critical of reasons (such as bugs which are potentially life-threatening or would cost untenable financial losses if they are not fixed), who cares if it's a only a little more difficult, relatively speaking, to update a library. Speaking as an embedded SW developer, I can tell you that the actual SW changes, and preparing the release package is easy. Actually making the release, though, is a big deal. After preparing the release package, we do regression testing. While a lot of this is automated, changes to physical inputs (switches, sensor, etc) and checking of physical outputs (indicators, motors, etc) is done manually, so these tests can take many hours. Once those tests have passed, we turn the release package over to the validation team, who preform their own (independently created) suite of tests. Once validation gives a pass, we send copies of the package to manufacturing and to our customer service organization. There is also documentation to prepare, which we can mostly complete in parallel with validation. (The validation team has access to the issue tickets, so we only need to give them a list of the ticket numbers applicable to the release.) We do use 3rd party libraries. The difference is that we have full control over what versions of each library are used. There is no one downstream from us repackaging our SW. The binaries we release are exactly what goes into the devices we created the SW for. Actually... What I was thinking of here was not anything related to preparation of the software changes or release package, but instead the actual deployment of the software itself into the field, and particularly into devices which cannot be reasonably expected to be ubiquitously networked and remotely upgradeable. How does one update embedded software in a VCR or DVD player, or a refrigerator, or a vehicle (car / ship / aircraft)? Or, for that matter, update embedded software used in an important industrial process, such as a power plant (nuclear or otherwise), a chemical manufacturing or processing facility, etc where failure of the process can potentially be catastrophic so you don't *want* it to be easy to update the software (to avoid malicious changes by third parties)? If you have to send an actual technician out to perform an update of the software, or perhaps worse yet expect an *end user* to do it (or even merely enable a setting to allow it to be done remotely over a network) and then deal with all the resulting support calls, well... I have to think the expense of *that* at least equals, if not easily exceeds, the expense of preparing the update in the first place. (All the expenses mind you, including specifically all the ones you mention above.) Which means you're not going to do an update casually, or without a damn good reason to go to the expense of getting it deployed. I'll note however that I do not *think* this is an issue for FOSS Unix/Linux distributions in general. (There are distributions which have an embedded flavor derived from them; for example, Debian has an embedded software variant called Emdebian, see http://www.emdebian.org/ for more information, but I highly doubt that in these cases the embedded flavor derived distribution tail wags the primary mainstream distribution dog.) Thanks for responding. Joseph ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
On Fri, Jan 3, 2014 at 1:50 PM, Joseph R. Justice jayare...@gmail.comwrote: Actually... What I was thinking of here was not anything related to preparation of the software changes or release package, but instead the actual deployment of the software itself into the field, and particularly into devices which cannot be reasonably expected to be ubiquitously networked and remotely upgradeable. How does one update embedded software in a VCR or DVD player, or a refrigerator, or a vehicle (car / ship / aircraft)? Or, for that matter, update embedded software used in an important industrial process, such as a power plant (nuclear or otherwise), a chemical manufacturing or processing facility, etc where failure of the process can potentially be catastrophic so you don't *want* it to be easy to update the software (to avoid malicious changes by third parties)? Our products are actually components for products of other businesses, so the details vary, but they are all designed to require a special program running on a laptop or tablet to communicate with a flash loader program that is nominally permanently resident in our devices. (It is possible to update the flash loader, but requires extra steps.) This special program is specific to the producer of the final product and is normally only available to authorized service businesses. (And yes, we have variations of our flash loader for each of the final product producers.) To reduce the possibility of unauthorized SW being loaded into our products, we encrypt the binary images. Our flash loader decrypts the image as it writes the image to built in flash ROM. How a technician connects the laptop/tablet to the component devices varies based on the type of the final product and the producers' design standards. Many such products, especially modern automobiles, have (possibly hidden) service connectors that allow the service program to communicate with the products component devices via an internal diagnostic network. Other products require the technician to plug directly into the individual components devices. While I don't know much of the details, I do know that many consumer devices like BluRay players, and even TVs, are Internet enabled, so can be updated over the Internet. For example, my BluRay player at home has an obscure menu option to start the player downloading and installing the latest SW from the producer's website. If the download or installation fails, it it will automatically retry. Since mine has an Ethernet port, I can take it anywhere I can get Internet access (If need be, I can use pocket sized Ethernet to WiFi adapter.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
On Fri, 03 Jan 2014 19:28:10 +0100, Richard Hipp d...@sqlite.org wrote: On Fri, Jan 3, 2014 at 1:22 PM, Ron Wilson ronw.m...@gmail.com wrote: BTW, the singular of data is datum. It is in Latin. In English data is a mass noun or an uncountable noun. Like sand or information or water, it has no plural form and always takes a singular verb. We know that data cannot be plural in English because in English, compound nouns never take the plural form. And yet data is frequently used in compound nouns: data center, data analysis, data processing, data mining, etc. Hence, data cannot be a plural noun. as a physicist I've never seen `data' used in its singluar form and I'm sure you are not completely (although mostly) right here. but as a non-native speaker I rather resort to the Oxford Dictionary of English which says (citing it verbatim (modulo typos...)): Usage: In Latin 'data' is the plural of 'datum' and, historically and in specialized scientific fields it is also treated as a plural in English, taking a plural verb, as in 'the data were collected and classified'. In modern non-scientific use, however, despite the complaints of traditionalists, it is often not treated as a plural. Instead, it is treated as a mass noun, similar to a word like `information' which cannot normally have a plural and which takes a singular verb. Sentences such as 'data was (as well as 'data were') collected over a number of years' are now widely accepted in standard English. so your statement that it categorically cannot be used in its plural form sure is wrong. it rather seems it's the other way round: it should be used as a plural (which it is) but English usage has developed in a way that using it as a mass noun is acceptable as well. -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
On 03/01/14 21:54, j. van den hoff wrote:
[...]
as a physicist I've never seen `data' used in its singluar form and I'm
sure you are not completely (although mostly) right here. but
as a non-native speaker I rather resort to the Oxford Dictionary of
English which says (citing it verbatim (modulo typos...)):
You're both right. 'Datum' is still the correct singular, and 'data' is
the plural of 'datum'... but 'data' is now *also* a singular collective
noun, and this meaning is vastly more prevalent. So 'data was collected'
is correct, as is 'single point of data', but you can also say 'the
datum at T=0'. That is, you *can*, but nobody does ('data point' has
largely replaced 'datum' except in the most formal scientific prose).
Disclaimer: I can only speak from the perspective of UK English, where
we have TV programmes about computer programs.
BTW, this one is easy. If you want to really hurt your head, consider
'fish' vs 'fishes'... both in the plural sense.
...it is *not true* that I'm a card-carrying member of the Pedant's
Society. (It's actually made of plastic.)
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ There does not now, nor will there ever, exist a programming
│ language in which it is the least bit hard to write bad programs. ---
│ Flon's Axiom
signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
Thus said Richard Hipp on Thu, 02 Jan 2014 11:32:22 -0500: I hate having to support --disable-internal-sqlite, and I hate having to add silly work-arounds in the code to accommodate distributions trying to use an older SQLite with a newer Fossil. This impedes progress and introduces bugs. I see no reason to accomodate older SQLite libraries in Fossil code workarounds. Shouldn't we just update the following lines of configure detection to have a new requirement of SQLite = 3.8.2 and be done with it; thus also avoiding the workarounds, bugs and furthering progress? http://www.fossil-scm.org/fossil/artifact/34dd270c8b3c7e4f3de26562f9344f90055620fc?ln=51,52 What is the worst that can come of it? That some OS vendors might lag behind in Fossil versions that they distribute? As for why I used --disable-internal-sqlite in the first place... I did it because I didn't know better (and partly because for whatever reason, modifying a single file requires a recompile of all targets). :-) I still think that Fossil should warn that the system library is not capable of supporting Fossil when the option is used. Clearly it would be best if the option didn't exist, but it does exist. Thanks, Andy -- TAI64 timestamp: 400052c762c8 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
Andy Bradford wrote: I see no reason to accomodate older SQLite libraries in Fossil code workarounds. Shouldn't we just update the following lines of configure detection to have a new requirement of SQLite = 3.8.2 and be done with it; thus also avoiding the workarounds, bugs and furthering progress? Can we please add a runtime check too so that Fossil will simply emit a fatal error and exit after detecting an unsupported SQLite version (e.g. when it first tries to access a database, etc)? -- Joe Mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
2014/1/1 Andy Bradford amb-fos...@bradfords.org: ...I get this because I configure with --disable-internal-sqlite on OpenBSD. Fixed here: http://fossil-scm.org/index.html/info/c3211392da The branch timeline-utc contains another --disable-internal-sqlite - related fix (making the timeline-utc option work). Before merging this to trunk I would like some more pairs of eyes having a look at it. Anyone? Many thanks! Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
2014/1/2 Richard Hipp d...@sqlite.org: It's maddening. It makes my hair turn gray. It irks me more than seeing the noun data used as a plural. Utter madness! But we live in a fallen world. We have to do it. Please go ahead and merge. Thanks! Actually, I agree that it's madless, but I learned to live with it. And since the solution is just one line, it's not that bad. My advice: The option --disable-internal-sqlite should only be used by package maintainers, which have exact control on which SQLite version their system has. But since the SQLite version might lag somewhat behind, requiring SQLite 3.8.2 for fossil just was a little bit too soon. But I'm happy to remove this workaround in a year or so, it shouldn't be kept forever (added a note on that). Every Fossil version should be clear on which minimum SQLite version it supports. I'm assuming 3.8.0. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
_WHY_ does --disable-internal-sqlite (and the unknown versions of SQLite that follow) have to be supported ? If package/OS maintainers insist on hacking in alien shared-lib SQLite, let them own their hacks and the repercussions. Call it a major version# bump, and remove that support. -bch On 1/2/14, Richard Hipp d...@sqlite.org wrote: The silly requirement of some distributions that *everything* must be a shared library irks me beyond words. I hate having to support --disable-internal-sqlite, and I hate having to add silly work-arounds in the code to accommodate distributions trying to use an older SQLite with a newer Fossil. This impedes progress and introduces bugs. It's a lose-lose situation. And yet the distributions are dogmatic on this point. It's maddening. It makes my hair turn gray. It irks me more than seeing the noun data used as a plural. Utter madness! But we live in a fallen world. We have to do it. Please go ahead and merge. On Thu, Jan 2, 2014 at 10:33 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 2014/1/1 Andy Bradford amb-fos...@bradfords.org: ...I get this because I configure with --disable-internal-sqlite on OpenBSD. Fixed here: http://fossil-scm.org/index.html/info/c3211392da The branch timeline-utc contains another --disable-internal-sqlite - related fix (making the timeline-utc option work). Before merging this to trunk I would like some more pairs of eyes having a look at it. Anyone? Many thanks! Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
[Top-posting considered harmful. *cough*] On Thu, Jan 2, 2014 at 12:40 PM, B Harder brad.har...@gmail.com wrote: On 1/2/14, Richard Hipp d...@sqlite.org wrote: The silly requirement of some distributions that *everything* must be a shared library irks me beyond words. I hate having to support --disable-internal-sqlite, and I hate having to add silly work-arounds in the code to accommodate distributions trying to use an older SQLite with a newer Fossil. This impedes progress and introduces bugs. It's a lose-lose situation. And yet the distributions are dogmatic on this point. It's maddening. It makes my hair turn gray. It irks me more than seeing the noun data used as a plural. Utter madness! But we live in a fallen world. We have to do it. Please go ahead and merge. _WHY_ does --disable-internal-sqlite (and the unknown versions of SQLite that follow) have to be supported ? If package/OS maintainers insist on hacking in alien shared-lib SQLite, let them own their hacks and the repercussions. Call it a major version# bump, and remove that support. I never did research this for y'all. I should do that... Again... My understanding, as an external observer of some FOSS Linux/Unix distributions (primarily / especially Debian), e.g. *not* as someone currently actively involved in maintaining a distribution, packaging software for it, etc, is that distributions want to minimize the number of different and distinct source-code copies of a given chunk of software (a library for instance) found amongst all the pieces of software they distribute. They want to minimize the number of source-code copies to make it easier for them to maintain all the different software packages in the distribution, by insuring that if a given piece of software needs to change (say to update it to a new version to provide new functionality, or to patch a bug (especially a security-related bug!) in an existing version that causes the software or something depending on / using the software to malfunction), they (ideally at least) only have to change the software in one place, and then update as necessary any and all other software depending on the newly-changed software to use that newly-changed version. (If the newly-changed software maintains the same ABI as the previous version of it, this might require no changes at all, or at most a change in the packaging meta-information; if there is an ABI change but the API stays the same this will probably require a re-compilation and re-linking; if there is an API change this might require changes to the source code of the other software to accommodate the API changes.) One way they minimize the number of source-code copies of software, particularly of software that is used by other software (e.g. such as a library like SQLite), is to require the shared software to be linked in as a shared (e.g. not a binary or source-code embedded) library to all the other software making use of it. I think that, if I were ever to do the required research (which, again, I have not done to date), I would find that most major FOSS Linux/Unix distributions, and quite likely many of the commercial / closed-source distributions (I speak here not merely of RHEL, SUSE, etc but also of Solaris, HP-UX, AIX, etc), are ... I won't say dogmatic about this point, but quite serious at the least about it, precisely because it makes their lives easier and because they see it as a benefit to their end-users. I think it is not a point they would give up lightly. I realize this is likely to be a quite different viewpoint / world view than those coming from the embedded software world or from the MS Windows (and probably also Apple OS/X) world have, and I suspect also commercial / closed-source software provided for various FOSS and non-FOSS Unix/Linux distributions, because in those worlds it is common for every piece of application software to ship its own private copy of any library it requires (other than libraries which can be guaranteed to be provided by the OS vendor). Further, in the embedded software world at least, I expect it is often difficult or even impossible to update software in the first place to patch bugs or provide new functionality, so there is no need much less desire to worry about making it *easier* to update software; if you can't update it at all, or can only update it in the first place with the very greatest of effort for only the most critical of reasons (such as bugs which are potentially life-threatening or would cost untenable financial losses if they are not fixed), who cares if it's a only a little more difficult, relatively speaking, to update a library. Anyway. Insofar as SQLite intends and desires to be capable of use as a shared non-embedded library *as well as* a non-shared embedded library for software running on Unix/Linux platforms, I expect this policy (as I've asserted it to be) of the FOSS Unix/Linux distributions will affect SQLite and
Re: [fossil-users] New Tree-View feature requires newer sqlite.
On Thu, Jan 2, 2014 at 2:04 PM, Joseph R. Justice jayare...@gmail.comwrote: [Top-posting considered harmful. *cough*] On Thu, Jan 2, 2014 at 12:40 PM, B Harder brad.har...@gmail.com wrote: On 1/2/14, Richard Hipp d...@sqlite.org wrote: The silly requirement of some distributions that *everything* must be a shared library irks me beyond words. I hate having to support --disable-internal-sqlite, and I hate having to add silly work-arounds in the code to accommodate distributions trying to use an older SQLite with a newer Fossil. This impedes progress and introduces bugs. It's a lose-lose situation. And yet the distributions are dogmatic on this point. It's maddening. It makes my hair turn gray. It irks me more than seeing the noun data used as a plural. Utter madness! But we live in a fallen world. We have to do it. Please go ahead and merge. _WHY_ does --disable-internal-sqlite (and the unknown versions of SQLite that follow) have to be supported ? If package/OS maintainers insist on hacking in alien shared-lib SQLite, let them own their hacks and the repercussions. Call it a major version# bump, and remove that support. I never did research this for y'all. I should do that... Again... My understanding, as an external observer of some FOSS Linux/Unix distributions (primarily / especially Debian), e.g. *not* as someone currently actively involved in maintaining a distribution, packaging software for it, etc, is that distributions want to minimize the number of different and distinct source-code copies of a given chunk of software (a library for instance) found amongst all the pieces of software they distribute. They want to minimize the number of source-code copies to make it easier for them to maintain all the different software packages in the distribution, by insuring that if a given piece of software needs to change (say to update it to a new version to provide new functionality, or to patch a bug (especially a security-related bug!) in an existing version that causes the software or something depending on / using the software to malfunction), they (ideally at least) only have to change the software in one place, and then update as necessary any and all other software depending on the newly-changed software to use that newly-changed version. (If the newly-changed software maintains the same ABI as the previous version of it, this might require no changes at all, or at most a change in the packaging meta-information; if there is an ABI change but the API stays the same this will probably require a re-compilation and re-linking; if there is an API change this might require changes to the source code of the other software to accommodate the API changes.) One way they minimize the number of source-code copies of software, particularly of software that is used by other software (e.g. such as a library like SQLite), is to require the shared software to be linked in as a shared (e.g. not a binary or source-code embedded) library to all the other software making use of it. I think that, if I were ever to do the required research (which, again, I have not done to date), I would find that most major FOSS Linux/Unix distributions, and quite likely many of the commercial / closed-source distributions (I speak here not merely of RHEL, SUSE, etc but also of Solaris, HP-UX, AIX, etc), are ... I won't say dogmatic about this point, but quite serious at the least about it, precisely because it makes their lives easier and because they see it as a benefit to their end-users. I think it is not a point they would give up lightly. I realize this is likely to be a quite different viewpoint / world view than those coming from the embedded software world or from the MS Windows (and probably also Apple OS/X) world have, and I suspect also commercial / closed-source software provided for various FOSS and non-FOSS Unix/Linux distributions, because in those worlds it is common for every piece of application software to ship its own private copy of any library it requires (other than libraries which can be guaranteed to be provided by the OS vendor). Further, in the embedded software world at least, I expect it is often difficult or even impossible to update software in the first place to patch bugs or provide new functionality, so there is no need much less desire to worry about making it *easier* to update software; if you can't update it at all, or can only update it in the first place with the very greatest of effort for only the most critical of reasons (such as bugs which are potentially life-threatening or would cost untenable financial losses if they are not fixed), who cares if it's a only a little more difficult, relatively speaking, to update a library. Anyway. Insofar as SQLite intends and desires to be capable of use as a shared non-embedded library *as well as* a non-shared embedded library
Re: [fossil-users] New Tree-View feature requires newer sqlite.
* Richard Hipp: The silly requirement of some distributions that *everything* must be a shared library irks me beyond words. I hate having to support --disable-internal-sqlite, and I hate having to add silly work-arounds in the code to accommodate distributions trying to use an older SQLite with a newer Fossil. This impedes progress and introduces bugs. It's a lose-lose situation. And yet the distributions are dogmatic on this point. Uhm, does POSIX file locking work correctly if there are multiple copies of SQLite within the same process (assuming that there are no symbol collisions/interpositions)? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
On Thu, Jan 2, 2014 at 5:28 PM, Florian Weimer f...@deneb.enyo.de wrote: * Richard Hipp: The silly requirement of some distributions that *everything* must be a shared library irks me beyond words. I hate having to support --disable-internal-sqlite, and I hate having to add silly work-arounds in the code to accommodate distributions trying to use an older SQLite with a newer Fossil. This impedes progress and introduces bugs. It's a lose-lose situation. And yet the distributions are dogmatic on this point. Uhm, does POSIX file locking work correctly if there are multiple copies of SQLite within the same process (assuming that there are no symbol collisions/interpositions)? No it does not. But what does that have to do with static vs. dynamic linkage? -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
On Thu, Jan 2, 2014 at 4:28 PM, Florian Weimer f...@deneb.enyo.de wrote: * Richard Hipp: The silly requirement of some distributions that *everything* must be a shared library irks me beyond words. I hate having to support --disable-internal-sqlite, and I hate having to add silly work-arounds in the code to accommodate distributions trying to use an older SQLite with a newer Fossil. This impedes progress and introduces bugs. It's a lose-lose situation. And yet the distributions are dogmatic on this point. Uhm, does POSIX file locking work correctly if there are multiple copies of SQLite within the same process (assuming that there are no symbol collisions/interpositions)? No it doesn't. If you're using multiple copies of libsqlite3 to access the same DB file in the same process concurrently then you'll get corruption. In practice this just doesn't happen, but it's important to be on the lookout for this. Consider how that might happen by accident (as opposed to just for demonstration purposes). I imagine a plugin API for some library (think PAM) with multiple plugins... wanting to access the same DB -- or maybe the DB is the interface. That wouldn't happen, one hopes, and by and large it doesn't. Now imagine [wu]tmpx being replaced with a SQLite3 DB file... If [wu]tmpx were accessed using an in-process libsqlite3 and the library providing the [wu]tmpx functionality were itself available for static linking (or if the DB *were* the interface) *then* we'd have a situation ripe for this accident. But one could foresee this problem (hopefully) and act to head it off [various designs elided]. More generally, trying to ensure that a) there's only one copy of every library in the distro/OS, b) all version dependencies match up, is *super* hard, if not impossible. Eventually there are some very commonly used libraries where the simplest thing to do is to just ship multiple versions, but first the distro maintainer ought to make sure that the POSIX file locking disaster you mention can't happen as a result. It's fortunate, for example, that OpenSSL doesn't use POSIX file locking at all. Imagine it using SQLite3 for an OCSP response, CRL, and other caching! It's not such a stretch. Heimdal has an option to use SQLite3 for Kerberos ticket caching, and when used this happens in a library, which is itself used from a pluggable API (GSS) that is used in various operating system moving parts (e.g., LDAP). The problem with POSIX file locking and something like SQLite3 is that it's easy for all the pieces of such an accident to come to exist... by accident. The problem is that POSIX file locking is insane. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] New Tree-View feature requires newer sqlite.
On Thu, Jan 2, 2014 at 8:50 PM, Richard Hipp d...@sqlite.org wrote: On Thu, Jan 2, 2014 at 5:28 PM, Florian Weimer f...@deneb.enyo.de wrote: * Richard Hipp: The silly requirement of some distributions that *everything* must be a shared library irks me beyond words. [...] Uhm, does POSIX file locking work correctly if there are multiple copies of SQLite within the same process (assuming that there are no symbol collisions/interpositions)? No it does not. But what does that have to do with static vs. dynamic linkage? Pluggable interfaces + layered software. A perfect example would be nscd (the name service cache daemon), which is pluggable (see the nsswitch.conf man page). One or more plugins might need to share some common resource (e.g., Kerberos ticket caches). If that resource is a SQLite3 DB file... and if each plugin statically links with libsqlite3... and if the nsswitch dlopen()s those plugins... then bad things may happen. Things like the nsswitch generally support loading plugins at run-time, via dlopen(). There's quite a few such plugin interfaces: PAM, nsswitch, SASL, GSS, and probably many more. All it takes is for a confluence of design events to bring two SQLite3s (or other library that uses POSIX file locking) into the same process via such plugin interfaces, locking around the same files. With respect to SQLite3 the simplest thing for you to do is to advise people to... not do that. I.e., what you're already doing. The obvious workaround for anyone wanting to use SQLite3 for things like the examples I gave is to use IPC, having a separate process just for this purpose serving access to the DB. Nico -- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] New Tree-View feature requires newer sqlite.
Hello, I thought I would try the new /tree URI that has been added to Fossil, but I get the following error: Files of check-in [daff9d2062] SQLITE_ERROR: near WITHOUT: syntax error Just in case others run into this error and scratch their head for a bit as I did...I get this because I configure with --disable-internal-sqlite on OpenBSD. If I rebuild without that configure option it works nicely. Thanks, Andy -- TAI64 timestamp: 400052c452bc ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
