> 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....<http://www-personal.umich.edu/%7Eswolchok/gears/gears-linux-opt-0.3.2...>
>> . 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.<http://www-personal.umich.edu/%7Eswolchok/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..<http://www-personal.umich.edu/%7Eswolchok/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.