Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch

2008-10-14 Thread Markus Wanner
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

2008-10-14 Thread Markus Wanner
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

2008-10-14 Thread Jack Lloyd
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

2008-10-14 Thread Alex Sandro Queiroz e Silva
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

2008-10-13 Thread Richard Levitte
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


Re: [Monotone-devel] Concerns about the net.venge.monotone.stripped branch

2008-10-13 Thread Markus Wanner
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

2008-10-13 Thread Markus Wanner
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

2008-10-13 Thread Markus Wanner
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

2008-10-13 Thread Jack Lloyd
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

2008-10-13 Thread Derek Scherger
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

2008-10-13 Thread Richard Levitte
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

2008-10-13 Thread Zack Weinberg
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