> On Wed, Jun 18, 2008 at 3:53 PM, Ben Lisbakken <lisba...@google.com> wrote:

>> Scott --

>> Thanks for your work on this!

>> -Ben

>> On Tue, Jun 17, 2008 at 9:44 PM, Scott Wolchok <evilspork...@gmail.com>
>> wrote:

>>> I've fixed the link. The binary is now actually at

>>> http://www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.25....
>>> . I've upgraded to Firefox 3 just now and the unit tests seem to pass,
>>> so I guess that's good too.

>>> On Jun 17, 6:52 pm, Brandon Kruger <bmk...@gmail.com> wrote:
>>> > The only file there is an older version that isn't compatible with
>>> > FF3.

>>> > Ben Lisbakken wrote:
>>> > > It looks like this is the link in his directory:

>>> > > >http://www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.8.0...

>>> > > -Ben

>>> > > On Sun, Jun 15, 2008 at 1:40 PM, Brandon Kruger <bmk...@gmail.com>
>>> > > wrote:

>>> > > > It seems your link to the binary is broken.  I look forward to
>>> > > > testing
>>> > > > it.  Thank you for your work!

>>> > > > On Jun 14, 11:35 pm, "Scott Wolchok" <evilspork...@gmail.com>
>>> > > > wrote:
>>> > > > > From: Scott Wolchok <evilspork...@gmail.com>
>>> > > > > Date: Sat, Jun 14, 2008 at 8:33 PM
>>> > > > > Subject: Re:64 bitLinux support
>>> > > > > To: Scott Wolchok <evilspork...@gmail.com>

>>> > > > > Updated patch has been posted athttp://
>>> > > > code.google.com/p/gears/issues/detail?id=335
>>> > > > > . Binary is athttp://
>>> > > > www-personal.umich.edu/~swolchok/gears/gears-linux-opt-0.3.25....
>>> > > > > . It passes the unit tests, but other than that I haven't done
>>> > > > > any
>>> > > > > testing.

>>> > > > > On Mar 11, 1:02 pm, Scott Wolchok <evilspork...@gmail.com> wrote:

>>> > > > > > On Mar 10, 7:06 am, "John Ripley" <jrip...@google.com> wrote:

>>> > > > > > > 2008/3/6 Scott Wolchok <evilspork...@gmail.com>:

>>> > > > > > > >  Here is a better (IMO) patch.
>>> > > > > > > ...
>>> > > > > > > >  Cons:
>>> > > > > > > >  * Introduces a build dependency on Boost. Developers must
>>> > > > > > > > either
>>> > > > > > > >   install Boost headers, or we must "deboostify"
>>> > > > > > > > boost/integer.hpp
>>> > > > as
>>> > > > > > > >   was done with scoped_ptr.
>>> > > > > > > ...
>>> > > > > > > >  --- base/common/int_types.h     (revision 1121)
>>> > > > > > > >  +++ base/common/int_types.h     (working copy)
>>> > > > > > > >  @@ -26,6 +26,15 @@
>>> > > > > > > >   #ifndef GEARS_BASE_COMMON_INT_TYPES_H__
>>> > > > > > > >   #define GEARS_BASE_COMMON_INT_TYPES_H__

>>> > > > > > > >  +#include <boost/integer.hpp>
>>> > > > > > > >  +#include <climits>
>>> > > > > > > >  +
>>> > > > > > > >  +//intptr_t would clash with C99 stdint.h if it got
>>> > > > > > > > included
>>> > > > somehow.
>>> > > > > > > >  +//CHAR_BIT is bits/char, and void * must be big enough to
>>> > > > > > > > hold
>>> > > > all
>>> > > > > > > >  +//pointers to objects.
>>> > > > > > > >  +typedef boost::int_t<CHAR_BIT * sizeof(void*)>::fast
>>> > > > > > > > ptrasint_t;
>>> > > > > > > >  +
>>> > > > > > > >  +
>>> > > > > > > >   #ifdef _MSC_VER
>>> > > > > > > >   #include <float.h>  // for _isnan() on VC++
>>> > > > > > > >   #define isnan(x) _isnan(x)  // VC++ uses _isnan() instead
>>> > > > > > > > of
>>> > > > isnan()
>>> > > > > > > >  Index: base/common/js_runner_ff_marshaling.cc

>>> > > >  ===================================================================
>>> > > > > > > >  --- base/common/js_runner_ff_marshaling.cc      (revision
>>> > > > > > > > 1121)
>>> > > > > > > >  +++ base/common/js_runner_ff_marshaling.cc      (working
>>> > > > > > > > copy)
>>> > > > > > > >  @@ -553,7 +553,7 @@
>>> > > > > > > >    //
>>> > > > > > > >    // We must use PRIVATE_TO_JSVAL (only works on
>>> > > > > > > > pointers!) to
>>> > > > > > > >  prevent the
>>> > > > > > > >    // garbage collector from touching any private data
>>> > > > > > > > stored in JS
>>> > > > > > > >  'slots'.
>>> > > > > > > >  -  assert(0 == (0x01 &
>>> > > > reinterpret_cast<int>(function_data.get())));
>>> > > > > > > >  +  assert(0 == (0x01 &
>>> > > > > > > >  reinterpret_cast<ptrasint_t>(function_data.get())));
>>> > > > > > > >    function_wrappers_.push_back(

>>> > > > > > > >  linked_ptr<JsWrapperDataForFunction>(function_data.get()));
>>> > > > > > > >    jsval pointer_jsval =
>>> > > > > > > >  PRIVATE_TO_JSVAL((jsval)function_data.release());

>>> > > > > > > It strikes me that this gains a dependency on the boost
>>> > > > > > > library just
>>> > > > > > > to compile 1 typedef and 1 assert. Is this preferable to just
>>> > > > > > > using a
>>> > > > > > > #define or two?

>>> > > > > > > John.

>>> > > > > > The rationale is that getting this to work across platforms
>>> > > > > > and, more
>>> > > > > > importantly, across compilers is hard and requires us to keep
>>> > > > > > up with
>>> > > > > > a variety of compilers or limit the set of usable compilers
>>> > > > > > artifically. To lose the Boost dependency, we would have to
>>> > > > > > duplicate
>>> > > > > > the effort of finding the best type to use when casting
>>> > > > > > pointers to
>>> > > > > > integers, and I think it's pretty clear that this is not as
>>> > > > > > simple as

>>> > > > > > #ifdef64BIT
>>> > > > > > typedef long ptrasint_t;
>>> > > > > > #else
>>> > > > > > typedef int ptrasint_t;
>>> > > > > > #endif

>>> > > > > > It's not this simple because there are no guarantees about the
>>> > > > > > sizes
>>> > > > > > of int and long relative to pointer sizes, which means that
>>> > > > > > each
>>> > > > > > version of each compiler is free to change this. Because the
>>> > > > > > project
>>> > > > > > does not officially support64-bitLinux, I felt that Boost had
>>> > > > > > the
>>> > > > > > minimum impact on the build process given my personal goal of
>>> > > > > > support
>>> > > > > > without commitment to any particular compiler.  Boost is
>>> > > > > > especially to
>>> > > > > > use on any sane Linux distribution (something like
>>> > > > > > "$PACKAGE_MGR
>>> > > > > > install libboost-dev" should be sufficient). I freely admit,
>>> > > > > > however,
>>> > > > > > that I am not familiar with 1) the best way to use third-party
>>> > > > > > libraries on Windows and 2) Google's process for handling that
>>> > > > > > issue.

>>> > > > > > It seems like the process is to check libraries into the
>>> > > > > > version
>>> > > > > > control system. However, I think that Boost determines some
>>> > > > > > system-
>>> > > > > > specific things during the install process, so you might simply
>>> > > > > > check
>>> > > > > > a Boost install into your version control system for each
>>> > > > > > officially
>>> > > > > > supported platform, and then set the include path appropriately
>>> > > > > > depending on the build system. Unfortunately, Subversion does
>>> > > > > > nothing
>>> > > > > > to help with the space overhead of this solution.