Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
On Tue, Oct 14, 2008 at 06:07:54AM +0200, Richard Levitte wrote: > In message <[EMAIL PROTECTED]> on Mon, 13 Oct 2008 21:16:59 -0600, "Derek > Scherger" <[EMAIL PROTECTED]> said: > > derek> On Mon, Oct 13, 2008 at 8:45 PM, Jack Lloyd <[EMAIL PROTECTED]> wrote: > derek> > derek> > Attached is a patch for getting the PCRE runtime version as well. > derek> > > derek> > derek> Committed in ad7d563d114ba37fe5232fa429fecfc1681c3326, thanks again. > derek> > derek> Would you like to have commit access Jack? I'm not in a position to > grant > derek> that to you myself but I'm sure we could arrange it. > > That could certainly be arranged. Jack, if you're interested, please > send me public part of your monotone key, privately. Thanks guys. Who knows if I will ever have time to really work on Monotone (I would love to dig into the authorization/netsync system sometime, I still think there are some lessons we learned on OpenCM that Monotone could benefit from), but I can at least help with housecleaning occasionally. Richard, I'll send you my mtn key in a moment. -Jack ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
Hi, Alex Sandro Queiroz e Silva wrote: > The lua.h file defines LUA_RELEASE. That's the one I've been using before, which does not make much sense, because it can only serve as a build time check. It's not a runtime check like the global lua variable _VERSION. (And no, there is no _RELEASE global lua variable). Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
Hallo, Markus Wanner wrote: > Hi, > > Zack Weinberg wrote: >> well, you could always do the moral equivalent in C: >> >> lua_getglobal(L, "_VERSION"); >> std::string luaversion(lua_tostring(L, -1)); // copies >> lua_pop(L, 1); > > Hm.. I've tried that and stumbled over two problems. One is, that > mt_version.cc doesn't have access to a Lua_state object (and gets called > from sanity.cc, which doesn't either). > > The other one is, the patch version isn't included in the _VERSION > global variable: > The lua.h file defines LUA_RELEASE. Cheers, -alex http://www.ventonegro.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
Hi, Zack Weinberg wrote: > well, you could always do the moral equivalent in C: > > lua_getglobal(L, "_VERSION"); > std::string luaversion(lua_tostring(L, -1)); // copies > lua_pop(L, 1); Hm.. I've tried that and stumbled over two problems. One is, that mt_version.cc doesn't have access to a Lua_state object (and gets called from sanity.cc, which doesn't either). The other one is, the patch version isn't included in the _VERSION global variable: > # lua > Lua 5.1.3 Copyright (C) 1994-2008 Lua.org, PUC-Rio >> print(_VERSION) > Lua 5.1 >> So there's utterly no point in showing that, since we (build time) require 5.1.x anyway. I've thus reverted to show only 'Lua 5.1' in rev 6b777e3eb453b3b0be4d9aaa93e81cd56c6ca635. (As opposed to showing the patch version (i.e. "5.1.3") we've built against). Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
On Mon, Oct 13, 2008 at 7:45 PM, Jack Lloyd <[EMAIL PROTECTED]> wrote: > I could not figure out how to get the runtime Lua version (aside from > executing a line of Lua that ruturns the value of the Lua _VERSION > variable) well, you could always do the moral equivalent in C: lua_getglobal(L, "_VERSION"); std::string luaversion(lua_tostring(L, -1)); // copies lua_pop(L, 1); zw ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
In message <[EMAIL PROTECTED]> on Mon, 13 Oct 2008 21:16:59 -0600, "Derek Scherger" <[EMAIL PROTECTED]> said: derek> On Mon, Oct 13, 2008 at 8:45 PM, Jack Lloyd <[EMAIL PROTECTED]> wrote: derek> derek> > Attached is a patch for getting the PCRE runtime version as well. derek> > derek> derek> Committed in ad7d563d114ba37fe5232fa429fecfc1681c3326, thanks again. derek> derek> Would you like to have commit access Jack? I'm not in a position to grant derek> that to you myself but I'm sure we could arrange it. That could certainly be arranged. Jack, if you're interested, please send me public part of your monotone key, privately. Cheers, Richard -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
On Mon, Oct 13, 2008 at 8:45 PM, Jack Lloyd <[EMAIL PROTECTED]> wrote: > Attached is a patch for getting the PCRE runtime version as well. > Committed in ad7d563d114ba37fe5232fa429fecfc1681c3326, thanks again. Would you like to have commit access Jack? I'm not in a position to grant that to you myself but I'm sure we could arrange it. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
On Mon, Oct 13, 2008 at 11:52:53PM +0200, Markus Wanner wrote: > Hi, > > Richard Levitte wrote: > > In the same vein, the code to display the versions of SQLite, Botan > > and so on might be misleading in a shared library environment. Maybe > > it should display both the versions it was compiled against and the > > versions it's running against (if that's possible to find out, which > > isn't always a given). > > I've done that for SQLite and botan now. The mtn version --full output > now looks like (as an example): [...] Attached is a patch for getting the PCRE runtime version as well. I could not figure out how to get the runtime Lua version (aside from executing a line of Lua that ruturns the value of the Lua _VERSION variable) $ ./mtn version --full monotone 0.41 (base revision: 7aa69891001cc53af518ca9bff8e1c7dae0c280d) Running on : Linux 2.6.24.7 #1 SMP Tue Jun 24 10:34:47 EDT 2008 x86_64 C++ compiler: GNU C++ version 4.3.2 C++ standard library: GNU libstdc++ version 20080827 Boost version : 1_35 SQLite version : 3.5.9 (compiled against 3.5.9) Lua version : Lua 5.1.3 PCRE version: 7.7 2008-05-07 (compiled against 7.7) Botan version : 1.7.18 (compiled against 1.7.18) Changes since base revision: unknown # # old_revision [7aa69891001cc53af518ca9bff8e1c7dae0c280d] # # patch "mt_version.cc" # from [76772c0f83691ab5bed123dd6c95616904360c52] #to [0e9248c3606fce1b99798bb29705b5b3293e9580] # --- mt_version.cc 76772c0f83691ab5bed123dd6c95616904360c52 +++ mt_version.cc 0e9248c3606fce1b99798bb29705b5b3293e9580 @@ -83,7 +83,7 @@ get_full_version(string & out) "Boost version : %s\n" "SQLite version : %s (compiled against %s)\n" "Lua version : %s\n" - "PCRE version: %d.%d\n" + "PCRE version: %s (compiled against %d.%d)\n" "Botan version : %d.%d.%d (compiled against %d.%d.%d)\n" "Changes since base revision:\n" "%s") @@ -93,7 +93,7 @@ get_full_version(string & out) % BOOST_LIB_VERSION % sqlite3_libversion() % SQLITE_VERSION % LUA_RELEASE -% PCRE_MAJOR % PCRE_MINOR +% pcre_version() % PCRE_MAJOR % PCRE_MINOR % Botan::version_major() % Botan::version_minor() % Botan::version_patch() % BOTAN_VERSION_MAJOR % BOTAN_VERSION_MINOR % BOTAN_VERSION_PATCH % string(package_full_revision_constant); ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
Hi, Markus Wanner wrote: > Richard Levitte wrote: >> Just a moment ago, I saw a change that made the montone code depend on >> the version of SQLITE as described by a C macro. That's fine and >> dandy provided you link monotone with the static library, but what >> happens if it's linked with the shared library and then moved to >> another machine with a more modern (or even slightly older!) version >> of SQLite? Proper runtime checks are in place for SQLite and Botan since revision 7aa69891001cc53af518ca9bff8e1c7dae0c280d. SQLite seems to maintain a backwards compatible API for all versions 3.x.x. Compiling against 3.3.8 and running with 3.5.9 worked just fine for all unit test. Botan has a stable branch 1.6.x and a development one being 1.7.x. Supporting the moving target 1.7.x branch is a bit of a hassle, but OTOH we well be up and running right away when 1.8.x alias next stable branch comes out. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
Hi, Richard Levitte wrote: > In the same vein, the code to display the versions of SQLite, Botan > and so on might be misleading in a shared library environment. Maybe > it should display both the versions it was compiled against and the > versions it's running against (if that's possible to find out, which > isn't always a given). I've done that for SQLite and botan now. The mtn version --full output now looks like (as an example): monotone 0.41 (base revision: 35c9a1b5661fa713059728bec11204df5d0fe7c4) Running on : Linux 2.6.27-rc6-markus1 #4 SMP Thu Sep 18 13:30:24 CEST 2008 x86_64 C++ compiler: GNU C++ version 4.3.2 C++ standard library: GNU libstdc++ version 20080905 Boost version : 1_34_1 SQLite version : 3.5.9 (compiled against 3.3.8) Lua version : Lua 5.1.3 PCRE version: 7.8 Botan version : 1.6.3 (compiled against 1.6.3) Changes since base revision: format_version "1" new_manifest [84b53d2311043f42fcd55b15e9b548b3b9fb7e48] old_revision [67a5c30e1c38753ca92bda29120299e4872ac34b] Generated from data cached in the distribution; further changes may have been made. The cost for being independent of the actual SQLite library is having to use sqlite3_prepare() instead of sqlite3_prepare_v2(), which exists only since 3.3.14. However, as that's just 1.5 years old and because 3.3.8 is in etch, I'm trying to still support those versions. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
Hi, Richard Levitte wrote: > Just a moment ago, I saw a change that made the montone code depend on > the version of SQLITE as described by a C macro. That's fine and > dandy provided you link monotone with the static library, but what > happens if it's linked with the shared library and then moved to > another machine with a more modern (or even slightly older!) version > of SQLite? Yeah, I've been thinking about that as well. I'm not sure where to look for run time version information of the library, but I've been able to exchange *.so files without any hassle so far for versions which do not require the hex() function. > I don't know how SQLite handles such cases, but I do know that not > paying attention to that kind of thing have and still can lead to > problems. Agreed. Thanks for pointing this out. I'll check if we can add dynamic version checks as well. Regards Markus Wanner ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch
In the same vein, the code to display the versions of SQLite, Botan and so on might be misleading in a shared library environment. Maybe it should display both the versions it was compiled against and the versions it's running against (if that's possible to find out, which isn't always a given). Cheers, Richard In message <[EMAIL PROTECTED]> on Mon, 13 Oct 2008 16:12:01 +0200 (CEST), Richard Levitte <[EMAIL PROTECTED]> said: richard> Hello, richard> richard> I've been watching the development of the net.venge.monotone.stripped richard> branch for a bit, and I'm starting to notice some dependencies that I richard> find concerning. richard> richard> Just a moment ago, I saw a change that made the montone code depend on richard> the version of SQLITE as described by a C macro. That's fine and richard> dandy provided you link monotone with the static library, but what richard> happens if it's linked with the shared library and then moved to richard> another machine with a more modern (or even slightly older!) version richard> of SQLite? richard> The hex function that was just defined might already exist on a target richard> machine that has SQLite 3.3.14, but monotone would still try to inject richard> its own version if it was built on a machine that has SQLite 3.3.12. richard> I don't know how SQLite handles such cases, but I do know that not richard> paying attention to that kind of thing have and still can lead to richard> problems. richard> richard> Cheers, richard> Richard richard> richard> -- richard> Richard Levitte [EMAIL PROTECTED] richard> http://richard.levitte.org/ richard> richard> "Life is a tremendous celebration - and I'm invited!" richard> -- from a friend's blog, translated from Swedish richard> richard> richard> ___ richard> Monotone-devel mailing list richard> Monotone-devel@nongnu.org richard> http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Concerns about the net.venge.monotone.stripped branch
Hello, I've been watching the development of the net.venge.monotone.stripped branch for a bit, and I'm starting to notice some dependencies that I find concerning. Just a moment ago, I saw a change that made the montone code depend on the version of SQLITE as described by a C macro. That's fine and dandy provided you link monotone with the static library, but what happens if it's linked with the shared library and then moved to another machine with a more modern (or even slightly older!) version of SQLite? The hex function that was just defined might already exist on a target machine that has SQLite 3.3.14, but monotone would still try to inject its own version if it was built on a machine that has SQLite 3.3.12. I don't know how SQLite handles such cases, but I do know that not paying attention to that kind of thing have and still can lead to problems. Cheers, Richard -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "Life is a tremendous celebration - and I'm invited!" -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
