Have Mac OS X-related patches; need papers.

Have Mac OS X-related patches; need papers.

[Samuel Bronson]

I have some changes that I'd like to contribute to Emacs to make it work 
better with OS X (some of which I have pushed to 
lp:~naesten/emacs/nextstep-stuff and some of which is still sitting in 
my source tree).

I think I'm fairly safe in assuming that I'll need copyright assignment 
papers for this.  I already have papers for GDB (which I really ought to 
*use* at some point); how can I go about extending them?

Re: Have Mac OS X-related patches; need papers.

[John Wiegley]

>>>>> Samuel Bronson <naesten@gmail.com> writes:

> I have some changes that I'd like to contribute to Emacs to make it work
> better with OS X (some of which I have pushed to
> lp:~naesten/emacs/nextstep-stuff and some of which is still sitting in my
> source tree).

I'm curious, what changes do you have?

John

Re: Have Mac OS X-related patches; need papers.

[Glenn Morris]

Samuel Bronson wrote:

> I think I'm fairly safe in assuming that I'll need copyright assignment 
> papers for this.  I already have papers for GDB (which I really ought to 
> *use* at some point); how can I go about extending them?

I sent you the form off-list. You can't just extend the existing GDB
assignment, but you can (IIRC) do up to 4 projects with this new form at
the same time.

Re: Have Mac OS X-related patches; need papers.

[Samuel Bronson]

On Jun 30, 2012, at 10:07 PM, John Wiegley wrote:

>>>>>> Samuel Bronson <naesten@gmail.com> writes:
>
>> I have some changes that I'd like to contribute to Emacs to make it  
>> work
>> better with OS X (some of which I have pushed to
>> lp:~naesten/emacs/nextstep-stuff and some of which is still sitting  
>> in my
>> source tree).
>
> I'm curious, what changes do you have?

The ones I haven't committed yet are mostly fixes for compiler warnings.

As for the ones I have committed, you would normally be able to use  
launchpad's web UI to look at them, but right now that seems to be  
having trouble, so your best bet is probably to either grab the branch  
or try something with "bzr missing", like so:

iMac:emacs user$ bzr missing --mine -d lp:~naesten/emacs/nextstep- 
stuff lp:emacs --gnu-changelog
You have 17 extra revision(s):
2012-07-01  Samuel Bronson  <naesten@gmail.com>

	* unexmacosx.c: Update comments after experimenting with heap(1)  
during unexec ().

2012-07-01  Samuel Bronson  <naesten@gmail.com>

	Check if we need to pass -fobjc-exceptions to GCC on Mac OS X.
	Non-Apple GCCs tend to require this when building with 10.5 or newer
	SDKs; with this change, we can build out-of-the box with (say) fink's
	gcc47 version 4.7.1-1000.
	
	* src/Makefile.in: s/GNU_OBJC_FLAGS/OBJC_FLAGS/.
	* configure.in: s/GNU_OBJC_FLAGS/OBJC_FLAGS/.
	[NS_IMPL_COCOA]: Add checks for whether Objective C exceptions work
	without a flag or with -fobjc-exceptions; die if neither works.

2012-06-30  Samuel Bronson  <naesten@gmail.com>

	Don't hard-code names of autotools in Makefile.in.
	* configure.in: Add "AM_MISSING_PROG(AUTOM4TE, autom4te)".
	(Also specify the needed version in the AM_INIT_AUTOMAKE call.)
	* Makefile.in: Use variables to refer to autotools.
	(ACLOCAL, AUTOCONF, AUTOHEADER, AUTOM4TE, AUTOMAKE):
	New variables filled in by autoconf.

2012-06-30  Samuel Bronson  <naesten@gmail.com>

	* unexmacosx.c (unexec_malloc, unexec_realloc): Record available  
space, not requested.

2012-06-30  Samuel Bronson  <naesten@gmail.com>

	* unexmacosx.c: Dump EmacsZone into __UNEXEC segments, for clarity.
	Previously, they were dumped into __DATA segments, and it wasn't
	immediately obvious that these weren't just fragments of the original
	__DATA segment.

2012-06-30  Samuel Bronson  <naesten@gmail.com>

	* unexmacosx.c (copy_dysmtab): Add a FIXME before check involving a  
magic number.

2012-06-30  Samuel Bronson  <naesten@gmail.com>

	* unexmacosx.c (find_emacs_zone_regions): Add zone allocation summary  
& headers to output.

2012-06-30  Samuel Bronson  <naesten@gmail.com>

	* unexmacosx.c (unexec_malloc, unexec_realloc, unexec_free): Add  
prototypes.

2012-06-30  Samuel Bronson  <naesten@gmail.com>

	* unexmacosx.c: Rewrite allocation comments at top to reflect reality.
	Add thoughts on the possibility of using malloc_freezedry().

2012-06-30  Samuel Bronson  <naesten@gmail.com>

	* unexmacosx.c: More diagnostic tweaks and comments.
	(unexec_regions_recorder): List section type flags
	(copy_segment): Start message with "Copying", not "Writing".

2012-06-30  Samuel Bronson  <naesten@gmail.com>

	* unexmacosx: Align output on 64-bit systems, too.

2012-06-30  Samuel Bronson  <naesten@gmail.com>

	* unexmacosx.c: Add #else/#endif comments

2012-06-29  Samuel Bronson  <naesten@gmail.com>

	* unexmacosx.c (copy_data_segment): Fix bug #9927.  Dumps w/ GCC 4.7,
	though it still takes a bit of prodding to get it to build (mostly
	-fobjc-exceptions).

2012-06-29  Samuel Bronson  <naesten@gmail.com>

	* frame.c (Fx_parse_geometry): Return value from HAVE_NS path;
	fix comments on HAVE_NS #ifdef.

2012-06-29  Samuel Bronson  <naesten@gmail.com>

	* font.h (font_metrics): Copy comments from Xlib.h's XCharStruct.

2012-06-27  Samuel Bronson  <naesten@gmail.com>

	* unexmacosx.c (VM_DATA_TOP, struct region_t)
	(region_list_head, region_list_tail)
	(print_region, print_region_list, print_regions)
	(build_region_list): Remove, the data structure these build and
	display is not actually used in dumping.
	(unexec): Remove call to build_region_list ().

2012-06-27  Samuel Bronson  <naesten@gmail.com>

	* unexmacosx.c: Improve alignment of diagnostic output.

Re: Have Mac OS X-related patches; need papers.

[John Wiegley]

>>>>> Samuel Bronson <naesten@gmail.com> writes:

> As for the ones I have committed, you would normally be able to use
> launchpad's web UI to look at them, but right now that seems to be having
> trouble, so your best bet is probably to either grab the branch or try
> something with "bzr missing", like so:

Good stuff.

I've been trying for a week to get Emacs to run with "clang -O4", but at that
optimization level one of the red-black tree pointers get overwritten with a
bad value.  Debugging it involves reading a lot of assembly code, and I just
ran out of steam.  Would you be willing to work on the problem with me?

John

Re: Have Mac OS X-related patches; need papers.

[Samuel Bronson]

On Jul 1, 2012, at 10:26 PM, John Wiegley wrote:

>>>>>> Samuel Bronson <naesten@gmail.com> writes:
>
>> As for the ones I have committed, you would normally be able to use
>> launchpad's web UI to look at them, but right now that seems to be  
>> having
>> trouble, so your best bet is probably to either grab the branch or  
>> try
>> something with "bzr missing", like so:
>
> Good stuff.
>
> I've been trying for a week to get Emacs to run with "clang -O4",  
> but at that
> optimization level one of the red-black tree pointers get  
> overwritten with a
> bad value.  Debugging it involves reading a lot of assembly code,  
> and I just
> ran out of steam.  Would you be willing to work on the problem with  
> me?

Well, the Mac I'm using for this has a G5 PowerPC cpu, so it can only  
run up through OS X 10.5.8 and Xcode 3.1.4, and only ppc and ppc64  
code.  Would that be of any use?  I  see that macports has several  
versions of clang available...

Re: Have Mac OS X-related patches; need papers.

[John Wiegley]

>>>>> Samuel Bronson <naesten@gmail.com> writes:

> Well, the Mac I'm using for this has a G5 PowerPC cpu, so it can only run up
> through OS X 10.5.8 and Xcode 3.1.4, and only ppc and ppc64 code.  Would
> that be of any use?  I see that macports has several versions of clang
> available...

I'm afraid not.  We'd be reading much different assembly code. :)

Thanks,
  John