You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Peter Karman <pe...@peknet.com> on 2009/11/27 16:03:13 UTC
cast from pointer to integer of different size
../core/Lucy/Object/Obj.c: In function ‘lucy_Obj_hash_code’:
../core/Lucy/Object/Obj.c:34: warning: cast from pointer to integer of different
size
^^
I'm getting that warning from gcc under OSX 10.6, where pointers are 64 bits.
Usually I would just change the cast to a 64-bit sized type, but as
Obj_hash_code() is used all over the place, I'm not sure if that's the best
solution.
Thoughts?
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Re: Target platforms
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Nov 27, 2009 at 12:51:07PM -0800, Nathan Kurz wrote:
> >> Making MSVC a first class citizen would be fine if you think the return
> >> is there.
> >
> > No, as far as I'm concerned MSVC is a compatibility target.
> >
> > I think it's important for our users to provide wide portability, and that
> > means supporting MSVC. E.g. I want somebody's platform-portable wiki
> > project or MVC framework to be able to integrate Lucy without hesitation.
>
> If the goal is limited to this, would it would to target GCC and release
> binary DLL's?
That would complicate distribution and limit flexibility. Check out the kind
of difficulties that people go through to get things compiled and installed:
http://rubyforge.org/pipermail/rubyinstaller-devel/2009-March/000499.html
I want to leave open as many options for packaging Lucy as possible, by making
it as easy to build as possible.
As a matter of principle, I don't think Lucy ought to be a monoculture
programming project, bound to any particular compiler platform. We should be
working towards greater popularization of standards, not contributing to
balkanization. The Lucy core should stay portable.
As a matter of practicality, portability is not that heavy a burden for Lucy
relative to other projects of similar scope. Not that much of the core code
has to deal with OS and compiler platform dependency issues.
Nevertheless, I'm up for creative solutions that allow us to loosen the
syntax constraints without costing us too much in terms of compatibility.
> If we don't take the easy way out above, would a 'by any means
> necessary' clause allow us to compile in C++ for MSVC?
I'm cautiously optimistic that this approach will work. I've managed to get
both Lucy and KinoSearch to build and pass tests under MSVC as C++.
We're not quite done yet. I'm about 75% confident that I understand the
linking implications of building under C++ with MSVC and that it's not going
to make it any harder to build a DLL that exports all the necessary symbols.
To confirm, we should prioritize something I've put off for a little while:
binding the C tests into one shared object and the core library into another.
I'd also like to confirm that we can build and link against MSCVRT.DLL.
If all goes well... it would be nice if Charmonizer stayed C89, but everything
else, I think it makes sense to require that the compiler support your three
high-priority C99 features:
> '//' style comments
> variadic macros
> declarations anywhere you want
There are other systems we'll be leaving behind, but they're mostly older.
MSVC is the blocker.
Marvin Humphrey
Re: Target platforms
Posted by Nathan Kurz <na...@verse.com>.
On Fri, Nov 27, 2009 at 11:23 AM, Marvin Humphrey
<ma...@rectangular.com> wrote:
>> Making MSVC a first class citizen would be fine if you think the return is
>> there.
>
> No, as far as I'm concerned MSVC is a compatibility target.
>
> I think it's important for our users to provide wide portability, and that
> means supporting MSVC. E.g. I want somebody's platform-portable wiki project
> or MVC framework to be able to integrate Lucy without hesitation.
If the goal is limited to this, would it would to target GCC and
release binary DLL's? This seems like it would be a significant
simplification. Am I right to presume that there is way to produce
shared libraries with GCC that can be linked to from MSVC? Are many
of these wiki projects actually likely to include full source for
Lucy?
> MSVC has a couple important C89 limitations: it can't handle
> declaration-after-statement, and it can't handle variadic macros.
>
> Pure C89 is impossible anyway, because we need directory manipulation and c89
> doesn't specify that.
If we don't take the easy way out above, would a 'by any means
necessary' clause allow us to compile in C++ for MSVC? I'm not a
user, but a quick web search suggests this would avoid most of the
problems. It would probably create some of its own problems, but
perhaps they can be dealt with.
>> Requiring C99 might create a natural boundary between legacy and 'modern'.
>
> Except that nobody actually implements all of C99, so we'd have a nice bright
> dividing line with everybody on one side. :)
You're right. My biases were showing through. What I really meant
was "that subset of C99 that would make our lives easier and the code
clearer". I'd throw '//' style comments, variadic macros, and
declarations anywhere you want into this mix. None are necessary, but
all make things a little easier.
--nate
Re: [Lucy] Target platforms
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Sat, Nov 28, 2009 at 08:41:53PM -0600, Peter Karman wrote:
> FWIW, we make Win32 DLLs and .exe available for each Swish-e release by
> cross-compiling with mingw32 on debian-based systems (I do it on ubuntu):
I don't think this could work for us because of the memory mapping
requirement. The version of FSFileHandle I'm about to submit uses
MapViewOfFile from windows.h directly. To the best of my knowledge, MinGW
doesn't provide sys/mman.h...
http://lists.freedesktop.org/archives/fontconfig/2006-January/001919.html
... and we need either one or the other of those headers.
However, I am curious about MinGW in a different regard. Since Lucy currently
compiles on both GCC and MSVC, we shouldn't have any trouble compiling with
MinGW on Windows directly -- no need to cross-compile. I believe you can
specify which C runtime DLL to link against with MinGW, right? So it would be
possible to prepare binaries which link against MSVCRT.DLL rather than
e.g. MSVCR80.DLL.
That's very important, since every Windows box already has MSCVRT.DLL on it,
but many do *not* have later versions.
With KinoSearch, I haven't had to worry about such things because I've made
sure that it adhered to strict C89 syntax -- and since KS has been so easy to
compile, others have always been able to build the necessary packages without
much assistance from me.
If we're going to make Lucy harder to compile, we'll have to start worrying
about such issues ourselves.
> That said, I'm happy to support Marvin's desire for MSVC a compatibility
> target (esp since I haven't had to write any relevant code! ;) ).
So long as there's someone willing to step up and write the required
Charmonizer code and limited OS-specific stuff, Lucy developers working mainly
within trunk/core don't have to bear too heavy a burden.
Marvin Humphrey
Re: [Lucy] Target platforms
Posted by Peter Karman <pe...@peknet.com>.
Marvin Humphrey wrote on 11/27/09 1:23 PM:
> On Fri, Nov 27, 2009 at 10:21:06AM -0800, Nathan Kurz wrote:
>> More generally, it might be nice to make such goals explicit somewhere.
>
> Yes, for example as Parrot has done with "Target Platforms" at.
> <http://www.parrotcode.org/docs/pdd/pdd01_overview.html>.
>
>> Optimized for: 64-bit systems using GCC and supporting mmap would
>> probably be my vote.
>
> +1.
+1
>
>> Making MSVC a first class citizen would be fine if you think the return is
>> there.
>
> No, as far as I'm concerned MSVC is a compatibility target.
>
> I think it's important for our users to provide wide portability, and that
> means supporting MSVC. E.g. I want somebody's platform-portable wiki project
> or MVC framework to be able to integrate Lucy without hesitation.
>
> However, Microsoft needs to work a lot harder to make my life easier as an
> open source C developer if they want first-class status.
FWIW, we make Win32 DLLs and .exe available for each Swish-e release by
cross-compiling with mingw32 on debian-based systems (I do it on ubuntu):
http://swishewiki.org/sw/index.php/Win32#Cross-compiling_for_Windows_on_Debian_or_Ubuntu
We maintain appropriate macro checks in the source code and separate makefiles
etc. The download-and-use attraction for Windows users is huge, since that's the
expectation that community holds.
I personally have no love for the MSVC stuff, and like Marvin says, M$ needs to
work harder if they want me to write free code. Swish3 (for example) has no
explicit Win32 support and I don't intend to write any, though I'd be happy to
include it if someone contributed it. That said, I'm happy to support Marvin's
desire for MSVC a compatibility target (esp since I haven't had to write any
relevant code! ;) ).
--
Peter Karman . http://peknet.com/ . peter@peknet.com
Target platforms
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Nov 27, 2009 at 10:21:06AM -0800, Nathan Kurz wrote:
> More generally, it might be nice to make such goals explicit somewhere.
Yes, for example as Parrot has done with "Target Platforms" at.
<http://www.parrotcode.org/docs/pdd/pdd01_overview.html>.
> Optimized for: 64-bit systems using GCC and supporting mmap would
> probably be my vote.
+1.
> Making MSVC a first class citizen would be fine if you think the return is
> there.
No, as far as I'm concerned MSVC is a compatibility target.
I think it's important for our users to provide wide portability, and that
means supporting MSVC. E.g. I want somebody's platform-portable wiki project
or MVC framework to be able to integrate Lucy without hesitation.
However, Microsoft needs to work a lot harder to make my life easier as an
open source C developer if they want first-class status.
> Supported on: Any modern system with a C99 compiler? Is there any
> real reason to maintain C89 compatibility?
MSVC has a couple important C89 limitations: it can't handle
declaration-after-statement, and it can't handle variadic macros.
Pure C89 is impossible anyway, because we need directory manipulation and c89
doesn't specify that.
> Consciously unsupported: Vax, etc.
* Any system without IEEE 754 floating point numbers.
> Requiring C99 might create a natural boundary between legacy and 'modern'.
Except that nobody actually implements all of C99, so we'd have a nice bright
dividing line with everybody on one side. :)
GCC is close, but even it's not there yet.
http://gcc.gnu.org/c99status.html
So we're stuck either drawing up an arbitrary feature list, or using
time-based boundaries a la Parrot.
Marvin Humphrey
Re: cast from pointer to integer of different size
Posted by Nathan Kurz <na...@verse.com>.
On Fri, Nov 27, 2009 at 9:47 AM, Marvin Humphrey <ma...@rectangular.com> wrote:
> Hash_Code() gets called a lot, and making it 64-bit might have a slight
> negative performance impact for some 32-bit processors. However, I think
> we should be emphasizing compatibility rather than optimization for 32-bit
> machines and operating systems, freeing us up to optimize for performance on
> 64-bit systems exclusively and reducing the number of variables we have to
> bear in mind.
Yes. More generally, it might be nice to make such goals explicit somewhere.
Optimized for: 64-bit systems using GCC and supporting mmap would
probably be my vote.
Making MSVC a first class citizen would be
fine if you think the return is there.
Supported on: Any modern system with a C99 compiler? Is there any
real reason to maintain C89 compatibility?
Consciously unsupported: Vax, etc. Requiring C99 might create a
natural boundary between legacy and 'modern'.
My emphasis is not the specific details, but the idea that one should
draw the lines explicitly so as to focus one's efforts.
Nathan Kurz
nate@verse.com
Re: cast from pointer to integer of different size
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Fri, Nov 27, 2009 at 09:03:13AM -0600, Peter Karman wrote:
> Usually I would just change the cast to a 64-bit sized type, but as
> Obj_hash_code() is used all over the place, I'm not sure if that's the best
> solution.
I think the best solution might be to change Hash_Code() to return an i64_t.
Java's hashCode() and C#'s getHashCode() both return 32-bit values...
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#hashCode%28%29
http://msdn.microsoft.com/en-us/library/system.object.gethashcode.aspx
... and that influenced the original choice, but I don't recall encountering a
fundamental reason that Hash_Code() need be 32-bit.
Hash_Code() gets called a lot, and making it 64-bit might have a slight
negative performance impact for some 32-bit processors. However, I think
we should be emphasizing compatibility rather than optimization for 32-bit
machines and operating systems, freeing us up to optimize for performance on
64-bit systems exclusively and reducing the number of variables we have to
bear in mind.
Marvin Humphrey