CVS HEAD fails to build on OSX 10.4 (macterm.c broken?)

[Randal L. Schwartz]

gcc -I/sw/include -L/sw/lib -c -fpascal-strings -DMAC_OSX -Demacs -DHAVE_CONFIG_H -I. -I/Users/merlyn/MIRROR/emacs-CVS/src -fpascal-strings -DMAC_OSX -Dtemacs -g -O2 -Wno-pointer-sign macterm.c
macterm.c:229: error: static declaration of 'mac_initialize' follows non-static declaration
macterm.h:639: error: previous declaration of 'mac_initialize' was here
macterm.c: In function 'mac_begin_clip':
macterm.c:423: warning: 'NewRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2877)
macterm.c:425: warning: 'NewRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2877)
macterm.c:434: warning: 'GetClip' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2014)
macterm.c:435: warning: 'SectRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:3129)
macterm.c:436: warning: 'SetClip' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:1999)
macterm.c: In function 'mac_end_clip':
macterm.c:445: warning: 'SetClip' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:1999)
macterm.c: In function 'XDrawLine':
macterm.c:527: warning: 'GetGWorld' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:240)
macterm.c:528: warning: 'SetGWorld' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:254)
macterm.c:530: warning: 'RGBForeColor' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:4520)
macterm.c:532: warning: 'LockPixels' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:184)
macterm.c:532: warning: 'GetGWorldPixMap' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:480)
macterm.c:533: warning: 'MoveTo' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2279)
macterm.c:534: warning: 'LineTo' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2316)
macterm.c:535: warning: 'UnlockPixels' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:196)
macterm.c:535: warning: 'GetGWorldPixMap' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:480)
macterm.c:537: warning: 'SetGWorld' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:254)
macterm.c: In function 'mac_create_bitmap_from_bitmap_data':
macterm.c:730: warning: 'SetRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2401)
macterm.c: In function 'XCreatePixmap':
macterm.c:755: warning: 'SetRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2401)
macterm.c:759: warning: 'NewGWorld' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:105)
macterm.c: In function 'XCreatePixmapFromBitmapData':
macterm.c:793: warning: 'GetGWorld' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:240)
macterm.c:794: warning: 'SetGWorld' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:254)
macterm.c:798: warning: 'RGBForeColor' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:4520)
macterm.c:799: warning: 'RGBBackColor' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:4535)
macterm.c:800: warning: 'LockPixels' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:184)
macterm.c:800: warning: 'GetGWorldPixMap' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:480)
macterm.c:802: warning: 'CopyBits' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:3370)
macterm.c:808: warning: 'UnlockPixels' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:196)
macterm.c:808: warning: 'GetGWorldPixMap' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:480)
macterm.c:809: warning: 'SetGWorld' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:254)
macterm.c: In function 'XFreePixmap':
macterm.c:821: warning: 'DisposeGWorld' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QDOffscreen.h:226)
macterm.c: In function 'mac_invert_rectangle':
macterm.c:895: warning: 'SetRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2401)
macterm.c:897: warning: 'InvertRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2583)
macterm.c: In function 'mac_draw_image_string_atsui':
macterm.c:991: warning: 'RGBForeColor' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:4520)
macterm.c:996: warning: 'SetRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2401)
macterm.c:998: warning: 'RGBBackColor' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:4535)
macterm.c:999: warning: 'EraseRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2565)
macterm.c:1000: warning: 'RGBBackColor' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:4535)
macterm.c:1002: warning: 'MoveTo' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2279)
macterm.c:1008: warning: 'MoveTo' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2279)
macterm.c: In function 'mac_draw_image_string_qd':
macterm.c:1104: warning: 'SwapQDTextFlags' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:687)
macterm.c:1106: warning: 'RGBForeColor' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:4520)
macterm.c:1127: warning: 'RGBBackColor' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:4535)
macterm.c:1128: warning: 'SetRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2401)
macterm.c:1130: warning: 'EraseRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2565)
macterm.c:1132: warning: 'TextMode' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:408)
macterm.c:1134: warning: 'TextFont' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:384)
macterm.c:1135: warning: 'TextSize' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:420)
macterm.c:1136: warning: 'TextFace' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:396)
macterm.c:1137: warning: 'MoveTo' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2279)
macterm.c:1138: warning: 'DrawText' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:474)
macterm.c:1141: warning: 'TextMode' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:408)
macterm.c:1142: warning: 'MoveTo' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2279)
macterm.c:1143: warning: 'DrawText' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:474)
macterm.c:1146: warning: 'RGBBackColor' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:4535)
macterm.c:1151: warning: 'SwapQDTextFlags' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:687)
macterm.c: In function 'mac_query_char_extents':
macterm.c:1283: warning: 'ATSUGetGlyphInfo' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/ATSUnicodeGlyphs.h:1001)
macterm.c:1309: warning: 'GetFontInfo' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:540)
macterm.c:1319: warning: 'CharWidth' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:486)
macterm.c:1320: warning: 'QDTextBounds' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:540)
macterm.c: In function 'mac_scroll_area':
macterm.c:1589: warning: 'NewRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2877)
macterm.c:1591: warning: 'SetRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2401)
macterm.c:1598: warning: 'DisposeRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2997)
macterm.c: In function 'XFreeGC':
macterm.c:1675: warning: 'DisposeRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2997)
macterm.c: In function 'mac_set_clip_rectangles':
macterm.c:1818: warning: 'NewRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2877)
macterm.c:1819: warning: 'RectRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:3072)
macterm.c:1822: warning: 'NewRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2877)
macterm.c:1826: warning: 'RectRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:3072)
macterm.c:1827: warning: 'UnionRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:3150)
macterm.c:1829: warning: 'DisposeRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2997)
macterm.c: In function 'x_flush':
macterm.c:1911: warning: 'QDFlushPortBuffer' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:7341)
macterm.c:1913: warning: 'QDFlushPortBuffer' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:7341)
macterm.c:1913: warning: 'GetQDGlobalsThePort' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:7070)
macterm.c: In function 'mac_compute_glyph_string_overhangs':
macterm.c:2882: warning: 'TextFont' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:384)
macterm.c:2883: warning: 'TextSize' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:420)
macterm.c:2884: warning: 'TextFace' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:396)
macterm.c:2886: warning: 'QDTextBounds' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:540)
macterm.c: In function 'note_mouse_movement':
macterm.c:4559: warning: 'PtInRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:4128)
macterm.c:4577: warning: 'PtInRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:4128)
macterm.c: In function 'get_control_part_bounds':
macterm.c:4826: warning: 'NewRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2877)
macterm.c:4831: warning: 'GetRegionBounds' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:7119)
macterm.c:4832: warning: 'DisposeRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2997)
macterm.c: In function 'XTset_vertical_scroll_bar':
macterm.c:5361: warning: 'UnionRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2482)
macterm.c: In function 'mac_tool_bar_note_mouse_movement':
macterm.c:6153: warning: 'SetRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2401)
macterm.c: In function 'fm_get_style_from_font':
macterm.c:8032: warning: 'FMGetFontTable' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:831)
macterm.c:8038: warning: 'FMGetFontFamilyInstanceFromFont' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:890)
macterm.c: In function 'init_font_name_table':
macterm.c:8221: warning: 'FMCreateFontFamilyInstanceIterator' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:687)
macterm.c:8224: warning: 'FMCreateFontFamilyIterator' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:573)
macterm.c:8227: warning: 'FMDisposeFontFamilyInstanceIterator' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:699)
macterm.c:8233: warning: 'FMGetNextFontFamily' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:615)
macterm.c:8243: warning: 'FMGetFontFamilyName' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:755)
macterm.c:8245: warning: 'p2cstr' is deprecated (declared at /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/TextUtils.h:655)
macterm.c:8249: warning: 'FMGetFontFamilyTextEncoding' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:769)
macterm.c:8266: warning: 'FMResetFontFamilyInstanceIterator' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:713)
macterm.c:8269: warning: 'FMGetNextFontFamilyInstance' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:729)
macterm.c:8283: warning: 'FMDisposeFontFamilyIterator' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:585)
macterm.c:8284: warning: 'FMDisposeFontFamilyInstanceIterator' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:699)
macterm.c: In function 'mac_load_query_font':
macterm.c:8775: warning: 'FMGetFontFamilyInstanceFromFont' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:890)
macterm.c:8789: warning: 'FMGetFontFamilyTextEncoding' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:769)
macterm.c:8842: warning: 'FMGetFontFromFontFamilyInstance' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Fonts.h:875)
macterm.c:8932: warning: 'TextFont' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:384)
macterm.c:8933: warning: 'TextSize' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:420)
macterm.c:8934: warning: 'TextFace' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:396)
macterm.c:8936: warning: 'GetFontInfo' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:540)
macterm.c:8965: warning: 'StringWidth' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:498)
macterm.c:8969: warning: 'StringWidth' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:498)
macterm.c:8972: warning: 'StringWidth' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:498)
macterm.c:8975: warning: 'StringWidth' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/QuickdrawText.h:498)
macterm.c: In function 'do_window_update':
macterm.c:10046: warning: 'NewRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2877)
macterm.c:10049: warning: 'GetRegionBounds' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:7119)
macterm.c:10055: warning: 'DisposeRgn' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2997)
macterm.c: In function 'do_grow_window':
macterm.c:10211: warning: 'SetRect' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2401)
macterm.c: In function 'XTread_socket':
macterm.c:12267: warning: 'ObscureCursor' is deprecated (declared at /System/Library/Frameworks/ApplicationServices.framework/Frameworks/QD.framework/Headers/Quickdraw.h:2125)
make[2]: *** [macterm.o] Error 1

[Dan Nicolaescu]

Post by Randal L. Schwartz
gcc -I/sw/include -L/sw/lib -c -fpascal-strings -DMAC_OSX -Demacs -DHAVE_CONFIG_H -I. -I/Users/merlyn/MIRROR/emacs-CVS/src -fpascal-strings -DMAC_OSX -Dtemacs -g -O2 -Wno-pointer-sign macterm.c
macterm.c:229: error: static declaration of 'mac_initialize' follows non-static declaration
macterm.h:639: error: previous declaration of 'mac_initialize' was here

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I deleted this declaration in CVS, does it help?

[Randal L. Schwartz]

Post by Randal L. Schwartz
gcc -I/sw/include -L/sw/lib -c -fpascal-strings -DMAC_OSX -Demacs -DHAVE_CONFIG_H -I. -I/Users/merlyn/MIRROR/emacs-CVS/src -fpascal-strings -DMAC_OSX -Dtemacs -g -O2 -Wno-pointer-sign macterm.c
macterm.c:229: error: static declaration of 'mac_initialize' follows non-static declaration
macterm.h:639: error: previous declaration of 'mac_initialize' was here

Dan> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Dan> I deleted this declaration in CVS, does it help?

Yes, it did. But now the build stops here:

Loading /Users/merlyn/MIRROR/emacs-CVS/lisp/term/mac-win.el (source)...
Cannot open load file: url
make[2]: *** [bootstrap-emacs] Error 255

[Randal L. Schwartz]

Randal> Yes, it did. But now the build stops here:

Randal> Loading /Users/merlyn/MIRROR/emacs-CVS/lisp/term/mac-win.el (source)...
Randal> Cannot open load file: url
Randal> make[2]: *** [bootstrap-emacs] Error 255

Hmm. This looks like a chicken-egg problem. url.el does indeed exist, but
how is "(eval-when-compile (require 'url))" supposed to use it before it's
installed?

[Dan Nicolaescu]

Post by Randal L. Schwartz
Randal> Loading /Users/merlyn/MIRROR/emacs-CVS/lisp/term/mac-win.el (source)...
Randal> Cannot open load file: url
Randal> make[2]: *** [bootstrap-emacs] Error 255
Hmm. This looks like a chicken-egg problem. url.el does indeed exist, but
how is "(eval-when-compile (require 'url))" supposed to use it before it's
installed?

Just deleting the (eval-when-compile (require 'url)) might work. You'd
get some byte compile warnings. Unfortunately I don't have access to a
mac, so I can't test this..

[Randal L. Schwartz]

Dan> Just deleting the (eval-when-compile (require 'url)) might work. You'd
Dan> get some byte compile warnings. Unfortunately I don't have access to a
Dan> mac, so I can't test this..

That's presuming url.el doesn't define any macros then. :)

Trying that now...

[Dan Nicolaescu]

Post by Randal L. Schwartz
Dan> Just deleting the (eval-when-compile (require 'url)) might work. You'd
Dan> get some byte compile warnings. Unfortunately I don't have access to a
Dan> mac, so I can't test this..
That's presuming url.el doesn't define any macros then. :)

Inspecting the code shows that only autoloaded functions are used from
url, so I deleted that require in CVS.

[YAMAMOTO Mitsuharu]

Dan> Just deleting the (eval-when-compile (require 'url)) might
Dan> work. You'd get some byte compile warnings. Unfortunately I don't
Dan> have access to a mac, so I can't test this..

Post by Dan Nicolaescu

Post by Randal L. Schwartz
That's presuming url.el doesn't define any macros then. :)

Inspecting the code shows that only autoloaded functions are used
from url, so I deleted that require in CVS.

No. url-type used below is a macro.

(defun mac-ae-get-url (event)
"Open the URL specified by the Apple event EVENT.
Currently the `mailto' scheme is supported."
(interactive "e")
(let* ((ae (mac-event-ae event))
(parsed-url (url-generic-parse-url (mac-ae-text ae))))
(if (string= (url-type parsed-url) "mailto")
(progn
(url-mailto parsed-url)
(select-frame-set-input-focus (selected-frame)))
(mac-resume-apple-event ae t))))

It enables Emacs to act as a system default mailer by setting
preferences in Mail.app (and optionally customizing mail-user-agent).

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Dan Nicolaescu]

Post by Randal L. Schwartz
Dan> Just deleting the (eval-when-compile (require 'url)) might
Dan> work. You'd get some byte compile warnings. Unfortunately I don't
Dan> have access to a mac, so I can't test this..

Post by Dan Nicolaescu

Post by Randal L. Schwartz
That's presuming url.el doesn't define any macros then. :)

Inspecting the code shows that only autoloaded functions are used
from url, so I deleted that require in CVS.

No. url-type used below is a macro.

It should not matter ...

Post by Randal L. Schwartz
(defun mac-ae-get-url (event)
"Open the URL specified by the Apple event EVENT.
Currently the `mailto' scheme is supported."
(interactive "e")
(let* ((ae (mac-event-ae event))
(parsed-url (url-generic-parse-url (mac-ae-text ae))))

^^^^^^^
... this is autoloaded from the same file as
url-type, so the url-type below should be defined
by the time it is used.

Post by Randal L. Schwartz
(if (string= (url-type parsed-url) "mailto")
(progn
(url-mailto parsed-url)
(select-frame-set-input-focus (selected-frame)))
(mac-resume-apple-event ae t))))
It enables Emacs to act as a system default mailer by setting
preferences in Mail.app (and optionally customizing mail-user-agent).
YAMAMOTO Mitsuharu

[YAMAMOTO Mitsuharu]

Post by Dan Nicolaescu

Post by YAMAMOTO Mitsuharu
No. url-type used below is a macro.

It should not matter ...

Post by YAMAMOTO Mitsuharu
(defun mac-ae-get-url (event)
"Open the URL specified by the Apple event EVENT.
Currently the `mailto' scheme is supported."
(interactive "e")
(let* ((ae (mac-event-ae event))
(parsed-url (url-generic-parse-url (mac-ae-text ae))))

^^^^^^^
... this is autoloaded from the same file as
url-type, so the url-type below should be defined
by the time it is used.

No. Macros cannot be `call'ed from a compiled Lisp function.

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Dan Nicolaescu]

Post by YAMAMOTO Mitsuharu

Post by Dan Nicolaescu

Post by YAMAMOTO Mitsuharu
No. url-type used below is a macro.

It should not matter ...

Post by YAMAMOTO Mitsuharu
(defun mac-ae-get-url (event)
"Open the URL specified by the Apple event EVENT.
Currently the `mailto' scheme is supported."
(interactive "e")
(let* ((ae (mac-event-ae event))
(parsed-url (url-generic-parse-url (mac-ae-text ae))))

^^^^^^^
... this is autoloaded from the same file as
url-type, so the url-type below should be defined
by the time it is used.

No. Macros cannot be `call'ed from a compiled Lisp function.

Oops, right.
You'd have to figure out a solution then, mac-win is in the dumped
image now.

[YAMAMOTO Mitsuharu]

Post by YAMAMOTO Mitsuharu
No. Macros cannot be `call'ed from a compiled Lisp function.

Oops, right. You'd have to figure out a solution then, mac-win is
in the dumped image now.

Is that preloading by necessity for the multi-tty feature? Is it also
necessary for bootstrap-emacs?

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Dan Nicolaescu]

Post by YAMAMOTO Mitsuharu

Post by YAMAMOTO Mitsuharu
No. Macros cannot be `call'ed from a compiled Lisp function.

Oops, right. You'd have to figure out a solution then, mac-win is
in the dumped image now.

Is that preloading by necessity for the multi-tty feature?

Yes.

Post by YAMAMOTO Mitsuharu
Is it also necessary for bootstrap-emacs?

I think so, but you might want to double check.

[YAMAMOTO Mitsuharu]

Post by YAMAMOTO Mitsuharu
Is that preloading by necessity for the multi-tty feature?

Yes.

I'm not familiar with the multi-tty feature and its implementation.
Could you explain more about what part of lisp/term/*-win.el is in
particular necessary to be preloaded? Separating that part from
lisp/term/*-win.el might be an option.

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Dan Nicolaescu]

Post by YAMAMOTO Mitsuharu

Post by YAMAMOTO Mitsuharu
Is that preloading by necessity for the multi-tty feature?

Yes.

I'm not familiar with the multi-tty feature and its implementation.
Could you explain more about what part of lisp/term/*-win.el is in
particular necessary to be preloaded? Separating that part from
lisp/term/*-win.el might be an option.

I don't know for sure, I'd guess that at least
mac-initialize-window-system and x-* functions.

[Richard Stallman]

No. url-type used below is a macro.

The simplest fix is to convert those macros to defuns, since
efficiency is not important here.

They could also be defsubsts, but getting the value of them
would entail such a `require' as caused trouble already.

Does this fix it?

*** url-parse.el 25 Jul 2007 11:49:25 -0400 1.16.2.1
--- url-parse.el 30 Aug 2007 14:12:14 -0400
***************
*** 30,90 ****

(autoload 'url-scheme-get-property "url-methods")

! (defmacro url-type (urlobj)
! `(aref ,urlobj 0))

! (defmacro url-user (urlobj)
! `(aref ,urlobj 1))

! (defmacro url-password (urlobj)
! `(aref ,urlobj 2))

! (defmacro url-host (urlobj)
! `(aref ,urlobj 3))

! (defmacro url-port (urlobj)
! `(or (aref ,urlobj 4)
! (if (url-fullness ,urlobj)
! (url-scheme-get-property (url-type ,urlobj) 'default-port))))

! (defmacro url-filename (urlobj)
! `(aref ,urlobj 5))

! (defmacro url-target (urlobj)
! `(aref ,urlobj 6))

! (defmacro url-attributes (urlobj)
! `(aref ,urlobj 7))

! (defmacro url-fullness (urlobj)
! `(aref ,urlobj 8))

! (defmacro url-set-type (urlobj type)
! `(aset ,urlobj 0 ,type))

! (defmacro url-set-user (urlobj user)
! `(aset ,urlobj 1 ,user))

! (defmacro url-set-password (urlobj pass)
! `(aset ,urlobj 2 ,pass))

! (defmacro url-set-host (urlobj host)
! `(aset ,urlobj 3 ,host))

! (defmacro url-set-port (urlobj port)
! `(aset ,urlobj 4 ,port))

! (defmacro url-set-filename (urlobj file)
! `(aset ,urlobj 5 ,file))

! (defmacro url-set-target (urlobj targ)
! `(aset ,urlobj 6 ,targ))

! (defmacro url-set-attributes (urlobj targ)
! `(aset ,urlobj 7 ,targ))

! (defmacro url-set-full (urlobj val)
! `(aset ,urlobj 8 ,val))

;;;###autoload
(defun url-recreate-url (urlobj)
--- 30,90 ----

(autoload 'url-scheme-get-property "url-methods")

! (defun url-type (urlobj)
! (aref urlobj 0))

! (defun url-user (urlobj)
! (aref urlobj 1))

! (defun url-password (urlobj)
! (aref urlobj 2))

! (defun url-host (urlobj)
! (aref urlobj 3))

! (defun url-port (urlobj)
! (or (aref urlobj 4)
! (if (url-fullness urlobj)
! (url-scheme-get-property (url-type urlobj) 'default-port))))

! (defun url-filename (urlobj)
! (aref urlobj 5))

! (defun url-target (urlobj)
! (aref urlobj 6))

! (defun url-attributes (urlobj)
! (aref urlobj 7))

! (defun url-fullness (urlobj)
! (aref urlobj 8))

! (defun url-set-type (urlobj type)
! (aset urlobj 0 type))

! (defun url-set-user (urlobj user)
! (aset urlobj 1 user))

! (defun url-set-password (urlobj pass)
! (aset urlobj 2 pass))

! (defun url-set-host (urlobj host)
! (aset urlobj 3 host))

! (defun url-set-port (urlobj port)
! (aset urlobj 4 port))

! (defun url-set-filename (urlobj file)
! (aset urlobj 5 file))

! (defun url-set-target (urlobj targ)
! (aset urlobj 6 targ))

! (defun url-set-attributes (urlobj targ)
! (aset urlobj 7 targ))

! (defun url-set-full (urlobj val)
! (aset urlobj 8 val))

;;;###autoload
(defun url-recreate-url (urlobj)

[YAMAMOTO Mitsuharu]

Post by YAMAMOTO Mitsuharu
No. url-type used below is a macro.
The simplest fix is to convert those macros to defuns, since
efficiency is not important here.
They could also be defsubsts, but getting the value of them would
entail such a `require' as caused trouble already.

Sorry, I don't think that working around the bootstrap issue in this
way is not a good thing to do now. We have to make it clear whether
preloading lisp/term/*-win.el is the right thing in the first place
and for what reason if so. As far as I know, no one has explained
that so far.

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Richard Stallman]

Post by Richard Stallman
The simplest fix is to convert those macros to defuns, since
efficiency is not important here.
They could also be defsubsts, but getting the value of them would
entail such a `require' as caused trouble already.

Sorry, I don't think that working around the bootstrap issue in this
way is not a good thing to do now.

I do not follow you. Do you see any reason why my patch to url.el
should not be installed?

[YAMAMOTO Mitsuharu]

Post by YAMAMOTO Mitsuharu

Post by Richard Stallman
The simplest fix is to convert those macros to defuns, since
efficiency is not important here.
They could also be defsubsts, but getting the value of them would
entail such a `require' as caused trouble already.

Sorry, I don't think that working around the bootstrap issue in this
way is not a good thing to do now.
I do not follow you. Do you see any reason why my patch to url.el
should not be installed?

The original problem that Emacs doesn't bootstrap with Carbon was
introduced by multi-tty because it changed lisp/loadup.el to preload
lisp/term/mac-win.el. So I thought the first thing to do is to
clarify this preloading is really necessary or the right thing rather
than making a workaround at the url package side. Anyway, it seems
that Stefan has already installed another change using defstruct.

Someone who is really familiar with multi-tty should explain why
preloading lisp/term/*-win.el was necessary for multi-tty.

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Stefan Monnier]

Post by YAMAMOTO Mitsuharu
Someone who is really familiar with multi-tty should explain why
preloading lisp/term/*-win.el was necessary for multi-tty.

I don't know the reason for it but it does strike me that the probability
that mac-win.el will be used in a Carbon build is very high (similarly for
w32-win.el and x-win.el in their respective builds I guess).

But of course, by this reasoning encoded-kb.el should be preloaded as well,
but Richard rejected it.


Stefan

[Eli Zaretskii]

Date: Fri, 31 Aug 2007 22:06:36 -0400

Post by YAMAMOTO Mitsuharu
Someone who is really familiar with multi-tty should explain why
preloading lisp/term/*-win.el was necessary for multi-tty.

I don't know the reason for it but it does strike me that the probability
that mac-win.el will be used in a Carbon build is very high (similarly for
w32-win.el and x-win.el in their respective builds I guess).

The *-win.el files are supposed to be used _only_ for the windowed
sessions. If some build produces only a non-windowed version (like
the --without-x on Posix platforms), then the respective *-win.el
should NOT be required.

If the multi-tty branch somehow changed that, then someone who knows
the multi-tty code should explain why.

But of course, by this reasoning encoded-kb.el should be preloaded as well,
but Richard rejected it.

He didn't reject it for the MS-Windows build, AFAIR.

[Richard Stallman]

Post by Stefan Monnier
But of course, by this reasoning encoded-kb.el should be preloaded as well,
but Richard rejected it.

He didn't reject it for the MS-Windows build, AFAIR.

The reason it should not be preloaded (on GNU/Linux) is that most
sessions won't use it. Isn't that still the case?

[Stefan Monnier]

Post by Eli Zaretskii

Post by Stefan Monnier

Post by YAMAMOTO Mitsuharu
Someone who is really familiar with multi-tty should explain why
preloading lisp/term/*-win.el was necessary for multi-tty.

I don't know the reason for it but it does strike me that the probability
that mac-win.el will be used in a Carbon build is very high (similarly for
w32-win.el and x-win.el in their respective builds I guess).

The *-win.el files are supposed to be used _only_ for the windowed
sessions. If some build produces only a non-windowed version (like
the --without-x on Posix platforms), then the respective *-win.el
should NOT be required.

Of course not. But if the build does support the Carbon|w32|X11 interface,
then it makes sense to preload (mac|w32|x)-win.el even if the user will
occasionally run with -nw in which case the file will not be used.


Stefan

[Eli Zaretskii]

Date: Mon, 03 Sep 2007 16:43:18 -0400

Post by Eli Zaretskii
The *-win.el files are supposed to be used _only_ for the windowed
sessions. If some build produces only a non-windowed version (like
the --without-x on Posix platforms), then the respective *-win.el
should NOT be required.

Of course not. But if the build does support the Carbon|w32|X11 interface,
then it makes sense to preload (mac|w32|x)-win.el even if the user will
occasionally run with -nw in which case the file will not be used.

Agreed.

Do we have a build now that doesn't behave like that?

[Richard Stallman]

Of course not. But if the build does support the Carbon|w32|X11 interface,
then it makes sense to preload (mac|w32|x)-win.el even if the user will
occasionally run with -nw in which case the file will not be used.

Why preload them if in some sessions they will not be used?
Is the purpose just to speed up startup? If so, how much
difference does it make?

[Dan Nicolaescu]

Post by Stefan Monnier
Of course not. But if the build does support the Carbon|w32|X11 interface,
then it makes sense to preload (mac|w32|x)-win.el even if the user will
occasionally run with -nw in which case the file will not be used.
Why preload them if in some sessions they will not be used?
Is the purpose just to speed up startup? If so, how much
difference does it make?

I don't know if it supposed to speed startup, but I suppose it's
probably some other reason.

There's code in `command-line' that tries to make sure that the
WINDOW_SYSTEM-win file is loaded, and it errors out if it is not.
It then proceeds to call the x-handle-args (all the
term/*-win.el files provide such a function)
After that the function
WINDOW_SYSTEM-initialize-window-system. (all the term/*-win.el files
provide such a function now).

Again, this is just reading the code, not implying anything about why
any of these things are done in that way.

So what is the problem with having *-win loaded by default?
This discussion started because the port was having issues because
mac-win.el was requiring "url" for some of its functions. Those can be
moved to another file and the port can arrange to have the functions
in question properly loaded.

[YAMAMOTO Mitsuharu]

So what is the problem with having *-win loaded by default? This
discussion started because the port was having issues because
mac-win.el was requiring "url" for some of its functions. Those can
be moved to another file and the port can arrange to have the
functions in question properly loaded.

Why not the other way around as Richard suggested? It looks more
consistent in the sense that no other non-graphic term/*.el is not
preloaded.

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Richard Stallman]

So what is the problem with having *-win loaded by default?

It isn't really a problem, it just wastes space by making Emacs bigger.
The tradeoff is that loading it when needed takes time.

I don't insist on changing it, but did anyone think about the question
in these terms?

[Stefan Monnier]

Post by Dan Nicolaescu
So what is the problem with having *-win loaded by default?
It isn't really a problem, it just wastes space by making Emacs bigger.
The tradeoff is that loading it when needed takes time.
I don't insist on changing it, but did anyone think about the question
in these terms?

I must say I'm not sure why we do preloading (and dumping), so it's a more
general question. In my view, there are two main reasons to preload:
1 - startup speed: I think this is clear enough to everybody.
2 - heap size: a bit less obvious; a preloaded package puts some of its
information (mostly the bytecode) in the `pure' storage which is not
garbage collected (and is generally slightly more compact, tho this is
negligible), so the GC'd heap is slightly smaller than if the package
had been loaded after dumping.
3 - page sharing between processes: the purespace can be shared (by the OS)
between several Emacs instances. This is probably a rather rare situation
nowadays, and the difference is likely to be negligible.
4 - resilience: if the `emacs' binary finds itself all alone (somehow all
the other .elc files are unreadable/lost), an Emacs with preloaded
packages is more likely to still be somewhat usable.

Numbers 1,2,3 improve incrementally with each added preloaded package, as
long as that package is almost always used. For any given package, the
impact is likely to be minor, so measuring the impact of preloading a single
package is likely to be futile (and very difficult because the impact will
be lost in the noise).

Number 4 improves less incrementally. Emacs may become fully unusable if
some packages can't be found and are not preloaded. So number 4 seems to
indicate that a package should be preloaded if in some circumstances the
binary may become unusable in the case where the .elc files cannot be found.


Stefan

[Richard Stallman]

You're analysis of preloading is a good one. Basically, if a package
is nearly always needed, it should be preloaded.

Whether *-win.el is nearly always needed depends on how likely
users are to use ttys instead of X11.

[Richard Stallman]

We have to make it clear whether
preloading lisp/term/*-win.el is the right thing in the first place
and for what reason if so. As far as I know, no one has explained
that so far.

These files should not be preloaded.
The whole reason for their existence is to contain
things to be loaded only if necessary at run time.

Whatever code needs to be preloaded should be elsewhere.

[Randal L. Schwartz]

Dan> Just deleting the (eval-when-compile (require 'url)) might work. You'd
Dan> get some byte compile warnings. Unfortunately I don't have access to a
Dan> mac, so I can't test this..

Randal> That's presuming url.el doesn't define any macros then. :)

Randal> Trying that now...

Ok, *with that patch* it builds and installs.

It works in terminal mode, but fails to launch in carbon mode. :(

Here's the crash log from the carbon launch. And I'm not a carbon
programmer, so someone else will have to pick up the ball from here.
I'm rolling back to 22_1 again. :(

===== Wednesday, August 29, 2007 9:28:39 AM US/Pacific =====
**********

Host Name: localhost
Date/Time: 2007-08-29 09:28:43.538 -0700
OS Version: 10.4.10 (Build 8R2218)
Report Version: 4

Command: Emacs
Path: /Volumes/UFS/MIRROR/emacs-CVS/mac/Emacs.app/Contents/MacOS/Emacs
Parent: WindowServer [111]

Version: 23.0.50 (1.1)

PID: 19093
Thread: 0

Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000048

Thread 0 Crashed:
0 org.gnu.Emacs 0x0015078f Fx_create_frame + 3608 (macfns.c:2830)
1 org.gnu.Emacs 0x000ea715 Ffuncall + 958 (eval.c:3042)
2 org.gnu.Emacs 0x0011b522 Fbyte_code + 7198 (bytecode.c:679)
3 org.gnu.Emacs 0x000ea04b funcall_lambda + 200 (eval.c:3228)
4 org.gnu.Emacs 0x000ea50b Ffuncall + 436 (eval.c:3093)
5 org.gnu.Emacs 0x0011b522 Fbyte_code + 7198 (bytecode.c:679)
6 org.gnu.Emacs 0x000ea04b funcall_lambda + 200 (eval.c:3228)
7 org.gnu.Emacs 0x000ea50b Ffuncall + 436 (eval.c:3093)
8 org.gnu.Emacs 0x0011b522 Fbyte_code + 7198 (bytecode.c:679)
9 org.gnu.Emacs 0x000ea04b funcall_lambda + 200 (eval.c:3228)
10 org.gnu.Emacs 0x000ea50b Ffuncall + 436 (eval.c:3093)
11 org.gnu.Emacs 0x0011b522 Fbyte_code + 7198 (bytecode.c:679)
12 org.gnu.Emacs 0x000ea04b funcall_lambda + 200 (eval.c:3228)
13 org.gnu.Emacs 0x000ea50b Ffuncall + 436 (eval.c:3093)
14 org.gnu.Emacs 0x0011b522 Fbyte_code + 7198 (bytecode.c:679)
15 org.gnu.Emacs 0x000ea04b funcall_lambda + 200 (eval.c:3228)
16 org.gnu.Emacs 0x000ea2a3 apply_lambda + 108 (eval.c:3147)
17 org.gnu.Emacs 0x000e9a0d Feval + 490 (eval.c:2427)
18 org.gnu.Emacs 0x0007bce6 top_level_2 + 28 (keyboard.c:1415)
19 org.gnu.Emacs 0x000e88b8 internal_condition_case + 245 (eval.c:1494)
20 org.gnu.Emacs 0x0007bd2e top_level_1 + 66 (keyboard.c:1426)
21 org.gnu.Emacs 0x000e87a9 internal_catch + 171 (eval.c:1229)
22 org.gnu.Emacs 0x0007ba4e command_loop + 147 (keyboard.c:1384)
23 org.gnu.Emacs 0x0007bb19 recursive_edit_1 + 140 (keyboard.c:993)
24 org.gnu.Emacs 0x0007bc61 Frecursive_edit + 228 (keyboard.c:1056)
25 org.gnu.Emacs 0x0007ab51 main + 2279 (emacs.c:1781)
26 org.gnu.Emacs 0x000024d6 _start + 216
27 org.gnu.Emacs 0x000023fd start + 41

Thread 1:
0 libSystem.B.dylib 0x90009cd7 mach_msg_trap + 7
1 com.unsanity.ape 0xc0001d48 __ape_agent + 307
2 libSystem.B.dylib 0x90024227 _pthread_body + 84

Thread 2:
0 libSystem.B.dylib 0x90009cd7 mach_msg_trap + 7
1 ...lagutin.audio_hijack.server 0x009553ca ah_serv_loop + 108
2 libSystem.B.dylib 0x90024227 _pthread_body + 84

Thread 0 crashed with X86 Thread State (32-bit):
eax: 0x002df340 ebx: 0x0014f985 ecx: 0x00000000 edx: 0x02800409
edi: 0x00a15270 esi: 0x00000000 ebp: 0xbffff108 esp: 0xbffff080
ss: 0x0000001f efl: 0x00010202 eip: 0x0015078f cs: 0x00000017
ds: 0x0000001f es: 0x0000001f fs: 0x00000000 gs: 0x00000037

Binary Images Description:
0x1000 - 0x17dfff org.gnu.Emacs 23.0.50 (1.1) /Volumes/UFS/MIRROR/emacs-CVS/mac/Emacs.app/Contents/MacOS/Emacs
0x642000 - 0x66bfff libncurses.5.dylib /sw/lib/ncurses/libncurses.5.dylib
0x952000 - 0x95cfff alex_lagutin.audio_hijack.server 1.4.0 /Library/Application Enhancers/Instant Hijack Server.ape/Contents/MacOS/Instant Hijack Server
0x8fe00000 - 0x8fe4afff dyld 46.12 /usr/lib/dyld
0x90000000 - 0x90171fff libSystem.B.dylib /usr/lib/libSystem.B.dylib
0x901c1000 - 0x901c3fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib
0x901c5000 - 0x90202fff com.apple.CoreText 1.1.2 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText
0x90229000 - 0x902fffff ATS /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
0x9031f000 - 0x90774fff com.apple.CoreGraphics 1.258.75 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
0x9080b000 - 0x908d3fff com.apple.CoreFoundation 6.4.7 (368.28) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x90911000 - 0x90911fff com.apple.CoreServices 10.4 (???) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
0x90913000 - 0x90a07fff libicucore.A.dylib /usr/lib/libicucore.A.dylib
0x90a57000 - 0x90ad6fff libobjc.A.dylib /usr/lib/libobjc.A.dylib
0x90aff000 - 0x90b63fff libstdc++.6.dylib /usr/lib/libstdc++.6.dylib
0x90bd2000 - 0x90bd9fff libgcc_s.1.dylib /usr/lib/libgcc_s.1.dylib
0x90bde000 - 0x90c51fff com.apple.framework.IOKit 1.4.8 (???) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x90c66000 - 0x90c78fff libauto.dylib /usr/lib/libauto.dylib
0x90c7e000 - 0x90f24fff com.apple.CoreServices.CarbonCore 682.26 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
0x90f67000 - 0x90fcffff com.apple.CoreServices.OSServices 4.1 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
0x91008000 - 0x91047fff com.apple.CFNetwork 129.21 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
0x9105a000 - 0x9106afff com.apple.WebServices 1.1.3 (1.1.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore
0x91075000 - 0x910f4fff com.apple.SearchKit 1.0.5 /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
0x9112e000 - 0x9114cfff com.apple.Metadata 10.4.4 (121.36) /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
0x91158000 - 0x91166fff libz.1.dylib /usr/lib/libz.1.dylib
0x91169000 - 0x91308fff com.apple.security 4.5.2 (29774) /System/Library/Frameworks/Security.framework/Versions/A/Security
0x91406000 - 0x9140efff com.apple.DiskArbitration 2.1.1 /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
0x91415000 - 0x9141cfff libbsm.dylib /usr/lib/libbsm.dylib
0x91420000 - 0x91446fff com.apple.SystemConfiguration 1.8.6 /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
0x91458000 - 0x914cefff com.apple.audio.CoreAudio 3.0.4 /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x9151f000 - 0x9151ffff com.apple.ApplicationServices 10.4 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
0x91521000 - 0x9154dfff com.apple.AE 314 (313) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x91560000 - 0x91634fff com.apple.ColorSync 4.4.9 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync
0x9166f000 - 0x916e2fff com.apple.print.framework.PrintCore 4.6 (177.13) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
0x91710000 - 0x917b9fff com.apple.QD 3.10.24 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
0x917df000 - 0x9182afff com.apple.HIServices 1.5.2 (???) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
0x91849000 - 0x9185ffff com.apple.LangAnalysis 1.6.3 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
0x9186b000 - 0x91886fff com.apple.FindByContent 1.5 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/FindByContent.framework/Versions/A/FindByContent
0x91891000 - 0x918cefff com.apple.LaunchServices 182 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
0x918e2000 - 0x918eefff com.apple.speech.synthesis.framework 3.5 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x918f5000 - 0x91935fff com.apple.ImageIO.framework 1.5.5 /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO
0x91948000 - 0x919fafff libcrypto.0.9.7.dylib /usr/lib/libcrypto.0.9.7.dylib
0x91a40000 - 0x91a56fff libcups.2.dylib /usr/lib/libcups.2.dylib
0x91a5b000 - 0x91a79fff libJPEG.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x91a7e000 - 0x91addfff libJP2.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
0x91aef000 - 0x91af3fff libGIF.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x91af5000 - 0x91b7bfff libRaw.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRaw.dylib
0x91b7f000 - 0x91bbcfff libTIFF.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x91bc2000 - 0x91bdcfff libPng.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x91be1000 - 0x91be3fff libRadiance.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x91be5000 - 0x91cc3fff libxml2.2.dylib /usr/lib/libxml2.2.dylib
0x91ce0000 - 0x91ce0fff com.apple.Accelerate 1.3.1 (Accelerate 1.3.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x91ce2000 - 0x91d70fff com.apple.vImage 2.5 /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
0x91d77000 - 0x91d77fff com.apple.Accelerate.vecLib 3.3.1 (vecLib 3.3.1) /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
0x91d79000 - 0x91dd2fff libvMisc.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
0x91ddb000 - 0x91dfffff libvDSP.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
0x91e07000 - 0x92210fff libBLAS.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
0x9224a000 - 0x925fefff libLAPACK.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
0x9262b000 - 0x92718fff libiconv.2.dylib /usr/lib/libiconv.2.dylib
0x9271a000 - 0x92797fff com.apple.DesktopServices 1.3.6 /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
0x927d8000 - 0x92a08fff com.apple.Foundation 6.4.8 (567.29) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x92bb0000 - 0x92bb0fff com.apple.Carbon 10.4 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x92bb2000 - 0x92bc2fff com.apple.ImageCapture 3.0.4 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
0x92bd1000 - 0x92bd9fff com.apple.speech.recognition.framework 3.6 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
0x92bdf000 - 0x92be5fff com.apple.securityhi 2.0.1 (24742) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
0x92beb000 - 0x92c7cfff com.apple.ink.framework 101.2.1 (71) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
0x92c90000 - 0x92c94fff com.apple.help 1.0.3 (32.1) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
0x92c97000 - 0x92cb5fff com.apple.openscripting 1.2.5 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
0x92cc7000 - 0x92ccdfff com.apple.print.framework.Print 5.2 (192.4) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
0x92cd3000 - 0x92d36fff com.apple.htmlrendering 66.1 (1.1.3) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering
0x92d5d000 - 0x92d9efff com.apple.NavigationServices 3.4.4 (3.4.3) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/NavigationServices.framework/Versions/A/NavigationServices
0x92dc5000 - 0x92dd3fff com.apple.audio.SoundManager 3.9.1 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CarbonSound.framework/Versions/A/CarbonSound
0x92dda000 - 0x92ddffff com.apple.CommonPanels 1.2.3 (73) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
0x92de4000 - 0x930d9fff com.apple.HIToolbox 1.4.9 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x93d67000 - 0x93e21fff com.apple.audio.toolbox.AudioToolbox 1.4.5 /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
0x93e64000 - 0x93e64fff com.apple.audio.units.AudioUnit 1.4.2 /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x9429e000 - 0x942adfff libCGATS.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib
0x942b4000 - 0x942bffff libCSync.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
0x9432b000 - 0x94634fff com.apple.QuickTime 7.2.0 /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
0x95c05000 - 0x95c09fff com.apple.URLMount 2.1.7 /System/Library/PrivateFrameworks/URLMount.framework/URLMount
0xc0000000 - 0xc000efff com.unsanity.ape 2.0.3 /Library/Frameworks/ApplicationEnhancer.framework/Versions/A/ApplicationEnhancer

[Dan Nicolaescu]

Post by Randal L. Schwartz
Dan> Just deleting the (eval-when-compile (require 'url)) might work. You'd
Dan> get some byte compile warnings. Unfortunately I don't have access to a
Dan> mac, so I can't test this..
Randal> That's presuming url.el doesn't define any macros then. :)
Randal> Trying that now...
Ok, *with that patch* it builds and installs.
It works in terminal mode, but fails to launch in carbon mode. :(

It used to do at least that much when I did the mac multi-tty port
back in May. A lot of things seem to have changed in CVS for the mac
since then.
Unfortunately I don't have access to a mac, so I can't work on
this....

Post by Randal L. Schwartz
Here's the crash log from the carbon launch. And I'm not a carbon
programmer, so someone else will have to pick up the ball from here.

Can you please run it from gdb and post the xbacktrace?
It might be something quite trivial to fix.

[Randal L. Schwartz]

Post by Randal L. Schwartz
Here's the crash log from the carbon launch. And I'm not a carbon
programmer, so someone else will have to pick up the ball from here.

Dan> Can you please run it from gdb and post the xbacktrace?
Dan> It might be something quite trivial to fix.

Would I sound ignorant if I said I don't even know how to do that? :)

I can click on the Emacs.app icon. I know where the crash log goes,
which is what I pasted.

I've never invoked gdb. How would I do that from an .app file (I think the
binary is somewhere inside)? Once I do that, how do I get an "xbacktrace"?

[Dan Nicolaescu]

Post by Randal L. Schwartz

Post by Randal L. Schwartz
Here's the crash log from the carbon launch. And I'm not a carbon
programmer, so someone else will have to pick up the ball from here.

Dan> Can you please run it from gdb and post the xbacktrace?
Dan> It might be something quite trivial to fix.
Would I sound ignorant if I said I don't even know how to do that? :)
I can click on the Emacs.app icon. I know where the crash log goes,
which is what I pasted.
I've never invoked gdb. How would I do that from an .app file (I think the
binary is somewhere inside)? Once I do that, how do I get an "xbacktrace"?

[Note that my only programming experience on a mac is porting multi-tty]

If I remember well, when you compile, an Emacs.app directory will be
created in emacs/mac.
In that directory should be a binary called "Emacs".
cd emacs/src
Run gdb like this:
gdb PATH_TO_THE_Emacs_binary

when it crashes type "xbacktrace" at the gdb prompt.

[chad brown]

Post by Randal L. Schwartz
Would I sound ignorant if I said I don't even know how to do that? :)

If you have the developer tools installed, look for an application
called CrashReporterPrefs (mine's in /Developer/Applications/
Utilities/CrashReporterPrefs.app; you could use spotlight to find
yours), and run it. It will let you choose a `Developer' option for
the crash reporter, that includes the option to try attaching to the
crashed process.

Once inside gdb, you'll need the emacs-specific stuff for gdb. If
gdb doesn't pick it up automatically, cd into `src' inside your emacs
build tree (inside gdb; for me it's ``cd /usr/local/src/emacs/src'')
and source the gdb macros there (``source .gdbinit''). This will
make `xbacktrace' (and a bunch of other stuff) available inside gdb.

I'll try this myself, once my own build finishes (my PPC laptop isn't
the fastest thing ever to `make bootstrap' anymore). Until then, I
hope this helps.

*chad

[chad brown]

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000048
0x0016887c in Fx_create_frame (parameters=8306509) at macfns.c:2830
2830 if (FRAME_HAS_MINIBUF_P (f)
(gdb) xbacktrace
"x-create-frame" (0x7ebf4d)
"x-create-frame-with-faces" (0x7ebf8d)
"make-frame" (0x7ebfe5)
"frame-initialize" (0x3861151)
"command-line" (0x395f35b)
"normal-top-level" (0x0)
(gdb) list
2825 ;
2826 }
2827
2828 /* Initialize `default-minibuffer-frame' in case this is
the first
2829 frame on this display device. */
2830 if (FRAME_HAS_MINIBUF_P (f)
2831 && (!FRAMEP (kb->Vdefault_minibuffer_frame)
2832 || !FRAME_LIVE_P (XFRAME (kb-

Vdefault_minibuffer_frame))))

2833 kb->Vdefault_minibuffer_frame = frame;
2834
(gdb) p f
$1 = (struct frame *) 0xa1cd40
(gdb) p* f
$2 = {
size = 1073742938,
next = 0xa16310,
name = 42142243,
icon_name = 58721289,
title = 58721289,
focus_frame = 58721289,
root_window = 10577012,
selected_window = 10577012,
minibuffer_window = 10604212,
param_alist = 16854077,
scroll_bars = 58721289,
condemned_scroll_bars = 58721289,
menu_bar_items = 58721289,
face_alist = 58721289,
menu_bar_vector = 58721289,
menu_bar_items_used = 0,
buffer_predicate = 58721289,
buffer_list = 8353285,
buried_buffer_list = 58721289,
menu_bar_window = 58721289,
tool_bar_window = 10763908,
tool_bar_items = 58721289,
desired_tool_bar_string = 58721289,
current_tool_bar_string = 58721289,
face_cache = 0xa3fec0,
namebuf = 0x0,
current_pool = 0x0,
desired_pool = 0x0,
desired_matrix = 0x0,
current_matrix = 0x0,
glyphs_initialized_p = 1,
external_tool_bar = 1,
tool_bar_lines = 0,
n_tool_bar_rows = 0,
n_tool_bar_items = 0,
decode_mode_spec_buffer = 0xa43fb0 "",
insert_line_cost = 0x0,
delete_line_cost = 0x0,
insert_n_lines_cost = 0x0,
delete_n_lines_cost = 0x0,
text_lines = 40,
text_cols = 80,
total_lines = 0,
total_cols = 86,
new_text_lines = 0,
new_text_cols = 0,
left_pos = 0,
top_pos = 0,
pixel_height = 640,
pixel_width = 602,
x_pixels_diff = 0,
y_pixels_diff = 0,
win_gravity = 1,
size_hint_flags = 3,
border_width = 0,
internal_border_width = 0,
column_width = 7,
space_width = 7,
line_height = 16,
output_method = output_mac,
terminal = 0xa19ca0,
output_data = {
tty = 0xa1cfe0,
x = 0xa1cfe0,
w32 = 0xa1cfe0,
mac = 0xa1cfe0,
nothing = 10604512
},
fringe_cols = 3,
left_fringe_width = 10,
right_fringe_width = 11,
want_fullscreen = 0,
menu_bar_lines = 0,
external_menu_bar = 1,
display_preempted = 0 '\0',
visible = 0 '\0',
iconified = 0 '\0',
async_visible = 0 '\0',
async_iconified = 0 '\0',
garbaged = 1 '\001',
has_minibuffer = 1 '\001',
wants_modeline = 1 '\001',
can_have_scroll_bars = 1 '\001',
vertical_scroll_bar_type = vertical_scroll_bar_right,
desired_cursor = FILLED_BOX_CURSOR,
cursor_width = 88484,
blink_off_cursor = DEFAULT_CURSOR,
blink_off_cursor_width = 0,
auto_raise = 0 '\0',
auto_lower = 0 '\0',
no_split = 0 '\0',
explicit_name = 0 '\0',
window_sizes_changed = 1 '\001',
message_buf = 0xa402b0 "",
scroll_bottom_vpos = 0,
config_scroll_bar_width = 15,
config_scroll_bar_cols = 3,
scroll_bar_actual_width = 21,
cost_calculation_baud_rate = 19200,
mouse_moved = 0 '\0',
gamma = 0,
extra_line_spacing = 0,
resized_p = 1,
force_flush_display_p = 0,
background_pixel = 16777215,
foreground_pixel = 0,
default_face_done_p = 0,
already_hscrolled_p = 0,
updated_p = 0,
minimize_tool_bar_window_p = 0
}

[Dan Nicolaescu]

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000048
0x0016887c in Fx_create_frame (parameters=8306509) at macfns.c:2830
2830 if (FRAME_HAS_MINIBUF_P (f)
(gdb) xbacktrace
"x-create-frame" (0x7ebf4d)
"x-create-frame-with-faces" (0x7ebf8d)
"make-frame" (0x7ebfe5)
"frame-initialize" (0x3861151)
"command-line" (0x395f35b)
"normal-top-level" (0x0)
(gdb) list
2825 ;
2826 }
2827
2828 /* Initialize `default-minibuffer-frame' in case this is
the first
2829 frame on this display device. */
2830 if (FRAME_HAS_MINIBUF_P (f)

The crash is not here, f seems to be OK

2831 && (!FRAMEP (kb->Vdefault_minibuffer_frame)

Can you plese check kb and if the crash is here or ...

2832 || !FRAME_LIVE_P (XFRAME (kb-

Vdefault_minibuffer_frame))))

... here

2833 kb->Vdefault_minibuffer_frame = frame;
2834
(gdb) p f
$1 = (struct frame *) 0xa1cd40
(gdb) p* f
$2 = {
size = 1073742938,
next = 0xa16310,
name = 42142243,
icon_name = 58721289,
title = 58721289,
focus_frame = 58721289,
root_window = 10577012,
selected_window = 10577012,
minibuffer_window = 10604212,
param_alist = 16854077,
scroll_bars = 58721289,
condemned_scroll_bars = 58721289,
menu_bar_items = 58721289,
face_alist = 58721289,
menu_bar_vector = 58721289,
menu_bar_items_used = 0,
buffer_predicate = 58721289,
buffer_list = 8353285,
buried_buffer_list = 58721289,
menu_bar_window = 58721289,
tool_bar_window = 10763908,
tool_bar_items = 58721289,
desired_tool_bar_string = 58721289,
current_tool_bar_string = 58721289,
face_cache = 0xa3fec0,
namebuf = 0x0,
current_pool = 0x0,
desired_pool = 0x0,
desired_matrix = 0x0,
current_matrix = 0x0,
glyphs_initialized_p = 1,
external_tool_bar = 1,
tool_bar_lines = 0,
n_tool_bar_rows = 0,
n_tool_bar_items = 0,
decode_mode_spec_buffer = 0xa43fb0 "",
insert_line_cost = 0x0,
delete_line_cost = 0x0,
insert_n_lines_cost = 0x0,
delete_n_lines_cost = 0x0,
text_lines = 40,
text_cols = 80,
total_lines = 0,
total_cols = 86,
new_text_lines = 0,
new_text_cols = 0,
left_pos = 0,
top_pos = 0,
pixel_height = 640,
pixel_width = 602,
x_pixels_diff = 0,
y_pixels_diff = 0,
win_gravity = 1,
size_hint_flags = 3,
border_width = 0,
internal_border_width = 0,
column_width = 7,
space_width = 7,
line_height = 16,
output_method = output_mac,
terminal = 0xa19ca0,
output_data = {
tty = 0xa1cfe0,
x = 0xa1cfe0,
w32 = 0xa1cfe0,
mac = 0xa1cfe0,
nothing = 10604512
},
fringe_cols = 3,
left_fringe_width = 10,
right_fringe_width = 11,
want_fullscreen = 0,
menu_bar_lines = 0,
external_menu_bar = 1,
display_preempted = 0 '\0',
visible = 0 '\0',
iconified = 0 '\0',
async_visible = 0 '\0',
async_iconified = 0 '\0',
garbaged = 1 '\001',
has_minibuffer = 1 '\001',
wants_modeline = 1 '\001',
can_have_scroll_bars = 1 '\001',
vertical_scroll_bar_type = vertical_scroll_bar_right,
desired_cursor = FILLED_BOX_CURSOR,
cursor_width = 88484,
blink_off_cursor = DEFAULT_CURSOR,
blink_off_cursor_width = 0,
auto_raise = 0 '\0',
auto_lower = 0 '\0',
no_split = 0 '\0',
explicit_name = 0 '\0',
window_sizes_changed = 1 '\001',
message_buf = 0xa402b0 "",
scroll_bottom_vpos = 0,
config_scroll_bar_width = 15,
config_scroll_bar_cols = 3,
scroll_bar_actual_width = 21,
cost_calculation_baud_rate = 19200,
mouse_moved = 0 '\0',
gamma = 0,
extra_line_spacing = 0,
resized_p = 1,
force_flush_display_p = 0,
background_pixel = 16777215,
foreground_pixel = 0,
default_face_done_p = 0,
already_hscrolled_p = 0,
updated_p = 0,
minimize_tool_bar_window_p = 0
}

[chad brown]

The current problem with multi-tty on macosx seems to come from

/* If we're using the Carbon API on Mac OS X, define a few more
variables as well. */
#ifdef HAVE_CARBON
#define HAVE_WINDOW_SYSTEM
#define HAVE_MOUSE
/* XXX The MULTI_KBOARD support does not work yet on this platform. */
#undef MULTI_KBOARD
#endif
/* If we're using the Carbon API on Mac OS X, define a few more
variables as well. */
#ifdef HAVE_CARBON
#define HAVE_WINDOW_SYSTEM
#define HAVE_MOUSE
/* XXX The MULTI_KBOARD support does not work yet on this platform. */
/* #undef MULTI_KBOARD */
#endif

with the #undef MULTI_KBOARD line commented out. This seems to be a
feature of autoconf, but I'm not familiar enough with autoconf to be
sure, or figure out how to work around it. Can someone more familiar
with autoconf either fix src/config.in or tell me how to do it, so I
can verify the diagnosis (and look for further problems)?

Thanks,
*chad

[Glenn Morris]

Post by chad brown
with the #undef MULTI_KBOARD line commented out. This seems to be a
feature of autoconf, but I'm not familiar enough with autoconf to be
sure, or figure out how to work around it. Can someone more familiar
with autoconf either fix src/config.in or tell me how to do it, so I
can verify the diagnosis (and look for further problems)?

Try the following.

(Also, these changes should be moved to configure.in so that
autoheader will regenerate src/config.in in the right format).


*** config.in 29 Aug 2007 05:27:54 -0000 1.232
--- config.in 29 Aug 2007 22:03:18 -0000
***************
*** 930,947 ****
#endif

/* Multi-tty support relies on MULTI_KBOARD. It seems safe to turn it
! on unconditionally. */
#ifndef MULTI_KBOARD
#define MULTI_KBOARD
#endif

/* If we're using the Carbon API on Mac OS X, define a few more
variables as well. */
#ifdef HAVE_CARBON
#define HAVE_WINDOW_SYSTEM
#define HAVE_MOUSE
- /* XXX The MULTI_KBOARD support does not work yet on this platform. */
- #undef MULTI_KBOARD
#endif

/* Define USER_FULL_NAME to return a string
--- 930,948 ----
#endif

/* Multi-tty support relies on MULTI_KBOARD. It seems safe to turn it
! on unconditionally.
! XXX Except on Mac Carbon, where this feature does not work yet. */
! #ifndef HAVE_CARBON
#ifndef MULTI_KBOARD
#define MULTI_KBOARD
#endif
+ #endif

/* If we're using the Carbon API on Mac OS X, define a few more
variables as well. */
#ifdef HAVE_CARBON
#define HAVE_WINDOW_SYSTEM
#define HAVE_MOUSE
#endif

/* Define USER_FULL_NAME to return a string

[Dan Nicolaescu]

Post by Glenn Morris

Post by chad brown
with the #undef MULTI_KBOARD line commented out. This seems to be a
feature of autoconf, but I'm not familiar enough with autoconf to be
sure, or figure out how to work around it. Can someone more familiar
with autoconf either fix src/config.in or tell me how to do it, so I
can verify the diagnosis (and look for further problems)?

Try the following.
(Also, these changes should be moved to configure.in so that
autoheader will regenerate src/config.in in the right format).
*** config.in 29 Aug 2007 05:27:54 -0000 1.232
--- config.in 29 Aug 2007 22:03:18 -0000
***************
*** 930,947 ****
#endif
/* Multi-tty support relies on MULTI_KBOARD. It seems safe to turn it
! on unconditionally. */
#ifndef MULTI_KBOARD
#define MULTI_KBOARD
#endif
/* If we're using the Carbon API on Mac OS X, define a few more
variables as well. */
#ifdef HAVE_CARBON
#define HAVE_WINDOW_SYSTEM
#define HAVE_MOUSE
- /* XXX The MULTI_KBOARD support does not work yet on this platform. */
- #undef MULTI_KBOARD
#endif

I moved this #undef to s/darwin.h.

Chad can you please test that it works?

Some mac person should fix MULTI_KBOARD, it should be just a matter of
correctly initializing the keyboard, but it is not easy to do without
access to the platform...

[chad brown]

Post by Dan Nicolaescu
Chad can you please test that it works?

I am able to start emacs (as a carbon app) with this change, but the
resulting Emacs is very slow, taking over a second to respond to key
presses, but not eating gobs of CPU. I started emacs -Q under gdb
to see if I could figure out where it was spending all its time, and
got a crash. This seems to be repeatable, always in the same place,
with param_index = 56. I tested without any .emacs file, also.

*chad

Post by Dan Nicolaescu
Starting program: /Applications/Emacs.app/Contents/MacOS/Emacs -Q
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000044
0x000178e4 in x_set_frame_parameters (f=0xa7e070, alist=42659139)
at frame.c:3068
3068 if (NATNUMP (param_index)
(gdb) where
#0 0x000178e4 in x_set_frame_parameters (f=0xa7e070,
alist=42659139) at frame.c:3068
#1 0x00019be8 in x_default_parameter (f=0xa7e070, alist=58878289,
prop=58879521, deflt=42659139, xprop=0x74 <Address 0x74 out of
bounds>, xclass=0x2d0040 "", type=6564589) at frame.c:4010
#2 0x00168564 in Fx_show_tip (string=8375053, frame=1670368,
parms=8374973, timeout=80, dx=40, dy=160) at macfns.c:3927
#3 0x000fab20 in Ffuncall (nargs=56, args=0xbfffce64) at eval.c:3055
#4 0x0012ce5c in Fbyte_code (bytestr=2949184, vector=-1073754528,
maxdepth=56) at bytecode.c:679
#5 0x000f9d0c in Feval (form=2917064) at eval.c:2373
#6 0x000fcd54 in internal_lisp_condition_case (var=58780825,
bodyform=2429173, handlers=2429317) at eval.c:1437
#7 0x0012d850 in Fbyte_code (bytestr=2949184, vector=-1073753232,
maxdepth=24) at bytecode.c:869
#8 0x000fa50c in funcall_lambda (fun=2429044, nargs=2,
arg_vector=0xbfffd554) at eval.c:3223
#9 0x000fac1c in Ffuncall (nargs=56, args=0x39ad329) at eval.c:3093
#10 0x0012ce5c in Fbyte_code (bytestr=2949184, vector=-1073752752,
maxdepth=24) at bytecode.c:679
#11 0x000fa50c in funcall_lambda (fun=2430556, nargs=1,
arg_vector=0xbfffd838) at eval.c:3223
#12 0x000fac1c in Ffuncall (nargs=56, args=0x3977509) at eval.c:3093
#13 0x000fc4c0 in run_hook_with_args (nargs=2, args=0xbfffd834,
cond=until_success) at eval.c:2695
#14 0x000fa958 in Ffuncall (nargs=56, args=0x38146c9) at eval.c:3017
#15 0x0012ce5c in Fbyte_code (bytestr=2949184, vector=-1073752016,
maxdepth=24) at bytecode.c:679
#16 0x000fa50c in funcall_lambda (fun=2428836, nargs=1,
arg_vector=0xbfffdb18) at eval.c:3223
#17 0x000fac1c in Ffuncall (nargs=56, args=0x39ad2f9) at eval.c:3093
#18 0x000fc6e0 in Fapply (nargs=2, args=0xbfffdb14) at eval.c:2469
#19 0x000fa958 in Ffuncall (nargs=56, args=0x3814681) at eval.c:3017
#20 0x0012ce5c in Fbyte_code (bytestr=2949184, vector=-1073751280,
maxdepth=32) at bytecode.c:679
#21 0x000f9d0c in Feval (form=2917064) at eval.c:2373
#22 0x000fcd54 in internal_lisp_condition_case (var=58721289,
bodyform=2260365, handlers=2260437) at eval.c:1437
#23 0x0012d850 in Fbyte_code (bytestr=2949184, vector=-1073750000,
maxdepth=40) at bytecode.c:869
#24 0x000fa50c in funcall_lambda (fun=2260196, nargs=1,
arg_vector=0xbfffe1fc) at eval.c:3223
#25 0x000fac1c in Ffuncall (nargs=56, args=0x380bb11) at eval.c:3093
#26 0x000fc1d0 in call1 (fn=56, arg1=58878289) at eval.c:2817
#27 0x00086ebc in timer_check (do_it_now=58878289) at keyboard.c:4697
#28 0x00086f60 in readable_events (flags=1) at keyboard.c:3713
#29 0x0008d6f8 in get_input_pending (addr=0x2ffc10, flags=1) at
keyboard.c:6900
#30 0x0008d8dc in detect_input_pending_run_timers (do_display=1) at
keyboard.c:10538
#31 0x00135e60 in wait_reading_process_output (time_limit=30,
microsecs=0, read_kbd=35, do_display=1, wait_for_cell=58721289,
wait_proc=0x0, just_wait_proc=0) at process.c:4700
#32 0x00011948 in sit_for (timeout=3143524, reading=1,
do_display=1) at dispnew.c:6610
#33 0x0009110c in read_char (commandflag=1, nmaps=2,
maps=0xbfffee50, prev_event=58721289, used_mouse_menu=0xbfffeeb8,
end_time=0x0) at keyboard.c:2997
#34 0x00092790 in read_key_sequence (keybuf=0xbfffefb8, bufsize=30,
prompt=58721289, dont_downcase_last=2899844,
can_return_switch_frame=2899844, fix_current_buffer=3155708) at
keyboard.c:9384
#35 0x00094380 in command_loop_1 () at keyboard.c:1696
#36 0x000f8478 in internal_condition_case (bfun=0x93f70
<command_loop_1>, handlers=58780825, hfun=0x8be80 <cmd_error>) at
eval.c:1494
#37 0x00085510 in command_loop_2 () at keyboard.c:1405
#38 0x000f8300 in internal_catch (tag=56, func=0x854d0
<command_loop_2>, arg=58721289) at eval.c:1229
#39 0x000851d0 in command_loop () at keyboard.c:1384
#40 0x000852f4 in recursive_edit_1 () at keyboard.c:993
#41 0x00085488 in Frecursive_edit () at keyboard.c:1055
#42 0x00084df8 in main (argc=800, argv=0xbffffac8) at emacs.c:1778
"x-show-tip" (0x28aee33)
"byte-code" (0x251103)
"tooltip-show" (0x28aee73)
"tooltip-help-tips" (0x3800409)
"run-hook-with-args-until-success" (0x3977509)
"tooltip-timeout" (0x3800409)
"apply" (0x39ad2f9)
"byte-code" (0x227d9b)
"timer-event-handler" (0xa56bd4
(gdb) p param_index
$1 = 56

[YAMAMOTO Mitsuharu]

Post by Dan Nicolaescu

Post by Randal L. Schwartz
It works in terminal mode, but fails to launch in carbon mode. :(

It used to do at least that much when I did the mac multi-tty port
back in May. A lot of things seem to have changed in CVS for the mac
since then.

Now I can hardly believe that. I couldn't find any calls to
add_keyboard_wait_descriptor in the past macterm.c in the multi-tty
branch despite the comment in process.c below:

/* Don't do this, it caused infinite select loops. The display
method should call add_keyboard_wait_descriptor on stdin if it
needs that. */
#if 0
FD_SET (0, &input_wait_mask);
#endif

I seriously suspect you ran a wrong (i.e., non multi-tty) executable.

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Randal L. Schwartz]

I seriously suspect you are wrong in your suspicion.:)

I built cvs head, and it broke as I reported. I *rebuilt* my
emacs_22_1 tagged version, and it went back to working as expected.
So, the problem is clearly cvs head.
--
Sent from my iPhone!
(And you would do it too if you could!)

Post by YAMAMOTO Mitsuharu

Post by Dan Nicolaescu

Post by Randal L. Schwartz
It works in terminal mode, but fails to launch in carbon mode. :(

It used to do at least that much when I did the mac multi-tty port
back in May. A lot of things seem to have changed in CVS for the mac
since then.

Now I can hardly believe that. I couldn't find any calls to
add_keyboard_wait_descriptor in the past macterm.c in the multi-tty
/* Don't do this, it caused infinite select loops. The display
method should call add_keyboard_wait_descriptor on stdin if it
needs that. */
#if 0
FD_SET (0, &input_wait_mask);
#endif
I seriously suspect you ran a wrong (i.e., non multi-tty) executable.
YAMAMOTO Mitsuharu

[YAMAMOTO Mitsuharu]

I seriously suspect you are wrong in your suspicion.:) I built cvs
head, and it broke as I reported. I *rebuilt* my emacs_22_1 tagged
version, and it went back to working as expected. So, the problem
is clearly cvs head.

I meant I suspected Dan has succeeded in porting/running the Mac
multi-tty port in May.

YAMAMOTO Mitsuharu

Post by YAMAMOTO Mitsuharu

Post by Dan Nicolaescu

Post by Randal L. Schwartz

On Wed, 29 Aug 2007 09:41:50 -0700, Dan Nicolaescu

It works in terminal mode, but fails to launch in carbon mode. :(

It used to do at least that much when I did the mac multi-tty port
back in May. A lot of things seem to have changed in CVS for the
mac since then.

Now I can hardly believe that.

[YAMAMOTO Mitsuharu]

Post by YAMAMOTO Mitsuharu

I seriously suspect you are wrong in your suspicion.:) I built cvs
head, and it broke as I reported. I *rebuilt* my emacs_22_1 tagged
version, and it went back to working as expected. So, the problem
is clearly cvs head.

I meant I suspected Dan has succeeded in porting/running the Mac

^not

Post by YAMAMOTO Mitsuharu
multi-tty port in May.

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Dan Nicolaescu]

Post by YAMAMOTO Mitsuharu

Post by Dan Nicolaescu

Post by Randal L. Schwartz
It works in terminal mode, but fails to launch in carbon mode. :(

It used to do at least that much when I did the mac multi-tty port
back in May. A lot of things seem to have changed in CVS for the mac
since then.

Now I can hardly believe that. I couldn't find any calls to
add_keyboard_wait_descriptor in the past macterm.c in the multi-tty
/* Don't do this, it caused infinite select loops. The display
method should call add_keyboard_wait_descriptor on stdin if it
needs that. */
#if 0
FD_SET (0, &input_wait_mask);
#endif
I seriously suspect you ran a wrong (i.e., non multi-tty) executable.

I am not sure what your intention is with this. I don't think I had a
multi-tty executable around.

When I did that work I clearly stated that I did only minimal
testing. For the record here's what that meant:
-bootstrap with --without-carbon --with-x11, make sure it works
-configure --with-carbon
-make (no rebootstrap, I kept the byte compiled files)
-check that emacs -nw starts up (don't remember what I had to do to
make it work, mainly it was compilation fixes for new interfaces)
-hack until a carbon frame is displayed, run emacs -f server-start,
check that emacsclient and emacsclient -t can connect to it.

Given that nobody else cared to make any more changes to the multi-tty
carbon port since then, and you stated that you are not interested in
maintaining the carbon port for emacs 23, it was probably not a good
investment of my time to even go that far.

[YAMAMOTO Mitsuharu]

Post by Dan Nicolaescu

Post by YAMAMOTO Mitsuharu

Post by Dan Nicolaescu

Post by Randal L. Schwartz
It works in terminal mode, but fails to launch in carbon mode. :(

It used to do at least that much when I did the mac multi-tty port
back in May. A lot of things seem to have changed in CVS for the mac
since then.

Now I can hardly believe that. I couldn't find any calls to
add_keyboard_wait_descriptor in the past macterm.c in the multi-tty
/* Don't do this, it caused infinite select loops. The display
method should call add_keyboard_wait_descriptor on stdin if it
needs that. */
#if 0
FD_SET (0, &input_wait_mask);
#endif
I seriously suspect you ran a wrong (i.e., non multi-tty) executable.

I am not sure what your intention is with this. I don't think I had a
multi-tty executable around.

As multi-tty no longer does `FD_SET (0, &input_wait_mask)' in
process.c, if no `add_keyboard_wait_descriptor' calls are made, then
Carbon Emacs reads events from the window system only rarely via
polling with SIGALRM and becomes very unresponsive as reported. I
couldn't imagine that you weren't aware of such a noticeable
deficiency when you tested it, so I suspected you ran a different
executable.

Post by Dan Nicolaescu
When I did that work I clearly stated that I did only minimal
-bootstrap with --without-carbon --with-x11, make sure it works
-configure --with-carbon
-make (no rebootstrap, I kept the byte compiled files)
-check that emacs -nw starts up (don't remember what I had to do to
make it work, mainly it was compilation fixes for new interfaces)
-hack until a carbon frame is displayed, run emacs -f server-start,
check that emacsclient and emacsclient -t can connect to it.

So you didn't type any commands in a Carbon frame. Then it is very
likely that the current Carbon port is actually as unresponsive as the
one you tested in May.

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Randal L. Schwartz]

Dan> Given that nobody else cared to make any more changes to the multi-tty
Dan> carbon port since then, and you stated that you are not interested in
Dan> maintaining the carbon port for emacs 23, it was probably not a good
Dan> investment of my time to even go that far.

I might be misreading this, but does this mean that mac carbon is essentially
dead now, and won't be fixed, thanks to multi-tty being merged?

If that's so, I'm stuck on emacs 22 then, and won't be bothering to do any
more smoke testing for OSX. Please let me know if that changes, or tell me if
there's a way to back out the multi-tty branch, or something.

[Jason Rumney]

Post by Randal L. Schwartz
I might be misreading this, but does this mean that mac carbon is essentially
dead now, and won't be fixed, thanks to multi-tty being merged?

One developer, who is currently the main maintainer for the Carbon port,
has expressed the view that merging the Cocoa port (Emacs.app) would be
a better use of his time than continuing to maintain the Carbon port
once the unicode branch is merged. It does not mean that others cannot
continue to maintain the Carbon port if they feel it is necessary, nor
does it mean that any effort to fix the bugs in the multi-tty
functionality would be wasted, as most of the non-UI Carbon code will
still be used by the Cocoa port.

In the short term, your testing effort is probably more useful on the
EMACS_22_BASE branch anyway.

[YAMAMOTO Mitsuharu]

Post by Jason Rumney

Post by Randal L. Schwartz
I might be misreading this, but does this mean that mac carbon is
essentially dead now, and won't be fixed, thanks to multi-tty being
merged?

One developer, who is currently the main maintainer for the Carbon
port, has expressed the view that merging the Cocoa port (Emacs.app)
would be a better use of his time than continuing to maintain the
Carbon port once the unicode branch is merged.

As it seems to be about me, maybe I should add a few words about that.

I think you mean something I said in the emacs-unicode list. I also
said basically the same thing recently (before Dan made a multi-tty
port for Carbon with minimal tests):

As for Mac, I'm planning to quit the development of the Carbon port
for Emacs 23, as the Cocoa/GNUstep port will replace it on that
version. So, personally I don't care if multitty is incompatible with
the current Carbon code as long as it is not for Emacs 22.x (x > 1).

http://lists.gnu.org/archive/html/emacs-devel/2007-05/msg00310.html

But I didn't mean I'll help the development of the Cocoa/GNUstep port.

Post by Jason Rumney
It does not mean that others cannot continue to maintain the Carbon
port if they feel it is necessary,

Right.

Post by Jason Rumney
nor does it mean that any effort to fix the bugs in the multi-tty
functionality would be wasted, as most of the non-UI Carbon code
will still be used by the Cocoa port.

If "the Cocoa port" means Emacs.app by Adrian Robert et al., that's
not true: it doesn't share the code with the Carbon port. On the
other hand, recently I'm developing another Cocoa port (on Emacs 22)
that has a different design and policy. It actually uses "most of the
non-UI Carbon code", and only the UI portions are reimplemented on
Cocoa. So, I'd call it "Carbon+AppKit port" rather than a Cocoa port
(the AppKit framework provides UI portions of Cocoa). It is actually
working well, and the new code is less than 6000 lines. One of its
objectives is apparently to make the 64-bit version because UI
portions of Carbon is not going to be 64-bit. (The current version of
the Carbon+AppKit port is just the first step and it still doesn't
work as a 64-bit binary.)

Currently the Carbon+AppKit port loses the destination to check in,
but I'm not in a hurry: actually, it does not provide any new or fancy
features users may want to see :-).

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Yavor Doganov]

On the other hand, recently I'm developing another Cocoa port (on Emacs
22) that has a different design and policy.

Does it compile and work on GNUstep? (I don't care about MuckOS at all.)

Also, from your words I make the conclusion that Adrian's code is bad in
one way or another -- which might be true, but you don't give much
details...

[YAMAMOTO Mitsuharu]

Post by Yavor Doganov
Does it compile and work on GNUstep? (I don't care about MuckOS at all.)

No. That's why I said "Carbon+AppKit port" (requires Carbon) in
contrast to the Cocoa/GNUstep port.

Post by Yavor Doganov
Also, from your words I make the conclusion that Adrian's code is
bad in one way or another -- which might be true, but you don't give
much details...

Please read my words as they are. I said two ports are different in
design and policy. Maybe also in objectives.

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Richard Stallman]

Post by Yavor Doganov
Does it compile and work on GNUstep? (I don't care about MuckOS at all.)

No. That's why I said "Carbon+AppKit port" (requires Carbon) in
contrast to the Cocoa/GNUstep port.

A port that supports GNUstep is much better than one which doesn't.
So unless we want to support both, we should prefer the Cocoa/GNUstep
port.

[YAMAMOTO Mitsuharu]

Post by YAMAMOTO Mitsuharu
No. That's why I said "Carbon+AppKit port" (requires Carbon) in
contrast to the Cocoa/GNUstep port.
A port that supports GNUstep is much better than one which doesn't.
So unless we want to support both, we should prefer the Cocoa/GNUstep
port.

They would not conflict/compete with each other at least immediately.
The former targets Emacs 22, and the latter Emacs 23.

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Richard Stallman]

Post by Richard Stallman
A port that supports GNUstep is much better than one which doesn't.
So unless we want to support both, we should prefer the Cocoa/GNUstep
port.

They would not conflict/compete with each other at least immediately.
The former targets Emacs 22, and the latter Emacs 23.

I have lost you -- which one is "former" and which one is "latter"?

Any new port could only be considered for Emacs 23. So if one is
aimed at Emacs 22, it would need to be upgraded to 23.

[YAMAMOTO Mitsuharu]

Post by YAMAMOTO Mitsuharu

Post by Richard Stallman
A port that supports GNUstep is much better than one which doesn't.
So unless we want to support both, we should prefer the Cocoa/GNUstep
port.

They would not conflict/compete with each other at least immediately.
The former targets Emacs 22, and the latter Emacs 23.
I have lost you -- which one is "former" and which one is "latter"?

The former is the Carbon+AppKit port I'm recently developing on Emacs
22. It shares non-UI platform-specific code with the existing Carbon
port. More precisely, the Carbon+AppKit port is created by moving the
existing UI-specific Carbon code (< 7000 lines) to a new file
mactoolbox.c, and adding new files macappkit.h and macappkit.m for
UI-specific Cocoa code (< 6000 lines) written in Objective-C.

The latter is the Cocoa/GNUstep port, developed by Adrian Robert et
al. on Emacs 23. It doesn't share any platform-specific code with the
existing one. The new code is about 14000 lines in total as of the
latest version released in December 2006. It is available from
http://emacs-app.sourceforge.net/. The author said a new version is
in preparation.

Post by YAMAMOTO Mitsuharu
Any new port could only be considered for Emacs 23. So if one is
aimed at Emacs 22, it would need to be upgraded to 23.

The Carbon+AppKit port is not strictly a new port, but can be seen as
a variant of the Carbon port. That's one of the reasons I put such a
name. The Carbon+AppKit port provides the same feature sets and
shares most of the code with the existing Carbon port.

The primary reason that I made the Carbon+AppKit port is that the
Carbon port has no chance to go 64-bit, because 64-bit support of the
UI portions in Carbon will not be provided. This fact was made public
in June 2007 and people had believed that Carbon (including UI
portions) would go 64-bit until then.

Of course, it is possible to upgrade the Carbon+AppKit port to Emacs
23. It is no harder than upgrading the Carbon port because the
difference between two "ports" is only in the UI part that gets
minimal impact from the transition from Emacs 22 to Emacs 23. But I
think it will not be late to do so after evaluating the two ports that
use Cocoa (i.e., Carbon+AppKit and Cocoa/GNUstep) from various
aspects.

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Yavor Doganov]

Post by YAMAMOTO Mitsuharu
The former is the Carbon+AppKit port I'm recently developing on Emacs
22.

[...]

Post by YAMAMOTO Mitsuharu
The latter is the Cocoa/GNUstep port, developed by Adrian Robert et
al. on Emacs 23.

[...]

Post by YAMAMOTO Mitsuharu
But I think it will not be late to do so after evaluating the two
ports that use Cocoa (i.e., Carbon+AppKit and Cocoa/GNUstep) from
various aspects.

FWIW, (probably a well known fact) -- the GNUstep project has
absolutely no plans to implement Carbon, even before Apple's
announcement which finally made it clear that using Carbon should be
discouraged.

So unless the plans of your Carbon+AppKit port are to get rid of
Carbon at some point, it is not an option for us (GNUstep users). It
is not about a conflict or competition between these two ports, we
just don't have an option if the alternative port is useless for
GNUstep. This is more than unfortunate given the fact that we've been
waiting for years for the merge of the unicode branch, hoping that the
GNUstep merge will follow shortly afterwards.

Of course, you are the one to decide what to do with your free time; I
just regret that the most active developer on that front has a
different vision that doesn't include GNUstep.

[YAMAMOTO Mitsuharu]

--text follows this line--

Post by Yavor Doganov
FWIW, (probably a well known fact) -- the GNUstep project has
absolutely no plans to implement Carbon, even before Apple's
announcement which finally made it clear that using Carbon should be
discouraged.

Even the Cocoa/GNUstep port uses Carbon (CoreGraphics) routines for
drawing texts on Mac. And I don't think Apple is discouraging whole
of the Carbon, as they are to introduce new frameworks such as
CoreText. Also, some features such as Apple event support can't go
without Carbon. Finally, there's no reason (for me) to avoid the use
of existing Carbon code that I'm really familiar with and also many
users have already tested.

Post by Yavor Doganov
So unless the plans of your Carbon+AppKit port are to get rid of
Carbon at some point, it is not an option for us (GNUstep users).
It is not about a conflict or competition between these two ports,
we just don't have an option if the alternative port is useless for
GNUstep. This is more than unfortunate given the fact that we've
been waiting for years for the merge of the unicode branch, hoping
that the GNUstep merge will follow shortly afterwards.

I think I've rather said something more advantageous to the inclusion
of the Cocoa/GNUstep port to Emacs 23: I said I would quit the
development of the Carbon port for Emacs 23, and proposed the
inclusion of the Carbon+AppKit port to (later versions of) Emacs 22,
not to Emacs 23.

Post by Yavor Doganov
Of course, you are the one to decide what to do with your free time;
I just regret that the most active developer on that front has a
different vision that doesn't include GNUstep.

GNUstep is too much for me. One of the most difficult tasks about the
Carbon+AppKit port was to absorb the difference between multiple
versions of Mac OS X, and adding more platforms exceeds my ability
(I've just started to learn Cocoa and Objective-C in July).

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Yavor Doganov]

Post by YAMAMOTO Mitsuharu
GNUstep is too much for me. One of the most difficult tasks about the
Carbon+AppKit port was to absorb the difference between multiple
versions of Mac OS X, and adding more platforms exceeds my ability (I've
just started to learn Cocoa and Objective-C in July).

But with Carbon+AppKit you're already on the ObjC train riding on the
Cocoa railroad. A GNUstep application runs flawlessly on GNU/Linux and
(in most cases) on all versions of MuckOS X plus all the other platforms
that GNUstep supports. So basically, developing for GNUstep is like
developing a Java program for GCJ/Classpath: it is usable in the Free
World as well as with proprietary Java platforms.

So we may say that one prominent incarnation of the "Java Trap" is the
"Cocoa Trap".

I have to admit that I understand your hesitation, more or less.
The trouble with Emacs on GNUstep is that GNUsteppers are not familiar
with Emacs internals and Emacs developers are not familiar with GNUstep.
It is a mountain to learn when you look from both sides.

[YAMAMOTO Mitsuharu]

Post by Yavor Doganov

Post by YAMAMOTO Mitsuharu
GNUstep is too much for me. One of the most difficult tasks about
the Carbon+AppKit port was to absorb the difference between
multiple versions of Mac OS X, and adding more platforms exceeds my
ability (I've just started to learn Cocoa and Objective-C in July).

But with Carbon+AppKit you're already on the ObjC train riding on
the Cocoa railroad. A GNUstep application runs flawlessly on
GNU/Linux and (in most cases) on all versions of MuckOS X plus all
the other platforms that GNUstep supports. So basically, developing
for GNUstep is like developing a Java program for GCJ/Classpath: it
is usable in the Free World as well as with proprietary Java
platforms.
So we may say that one prominent incarnation of the "Java Trap" is
the "Cocoa Trap".

I'm a beginner of Cocoa and Objective-C so I can't judge whether it is
also the case for Emacs. Anyway, one of the important feature of the
Carbon+AppKit port is that it shares non-UI parts, especially the
drawing part, with the Carbon port that has been tested for a long
time by many users. Also, as I said, the Carbon+AppKit port is
primarily a variant of the Carbon port, and therefore I think it can
be included to the later versions of Emacs 22. If it also had GNUstep
code, it would no longer be called as a variant.

Post by Yavor Doganov
I have to admit that I understand your hesitation, more or less.
The trouble with Emacs on GNUstep is that GNUsteppers are not
familiar with Emacs internals and Emacs developers are not familiar
with GNUstep. It is a mountain to learn when you look from both
sides.

I guess a possible reason of the one-side familiarity is that both
sides of people think GNUstep users can at least run any other flavors
of X11 builds of Emacs seamlessly.

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Richard Stallman]

Also, as I said, the Carbon+AppKit port is
primarily a variant of the Carbon port, and therefore I think it can
be included to the later versions of Emacs 22.

I do not want to add such features to Emacs 22.
Please aim at Emacs 23.

[Richard Stallman]

The Carbon+AppKit port is not strictly a new port, but can be seen as
a variant of the Carbon port. That's one of the reasons I put such a
name. The Carbon+AppKit port provides the same feature sets and
shares most of the code with the existing Carbon port.

If we install this, would we do so by changing the existing Carbon
port?

That might be something we could put into a 22.3 or 22.4 release if
Emacs 23 is not going to be as soon as we hope. It depends on how
simple and safe the changes are.

[YAMAMOTO Mitsuharu]

Post by YAMAMOTO Mitsuharu
The Carbon+AppKit port is not strictly a new port, but can be seen as
a variant of the Carbon port. That's one of the reasons I put such a
name. The Carbon+AppKit port provides the same feature sets and
shares most of the code with the existing Carbon port.
If we install this, would we do so by changing the existing Carbon
port?

The changes to the existing Carbon port is basically reorganization.
Some functions/variables are moved to a new file mactoolbox.c. Either
Carbon or Carbon+Appkit port can be built with the modified source.

Post by YAMAMOTO Mitsuharu
That might be something we could put into a 22.3 or 22.4 release if
Emacs 23 is not going to be as soon as we hope. It depends on how
simple and safe the changes are.
Also, as I said, the Carbon+AppKit port is
primarily a variant of the Carbon port, and therefore I think it can
be included to the later versions of Emacs 22.
I do not want to add such features to Emacs 22.
Please aim at Emacs 23.

I'm confused by these contradicting reactions. Anyway, I'm not in a
hurry at all as I said. We can't get 64-bit UI support until the next
Mac OS X release planed in October.

YAMAMOTO Mitsuharu
***@math.s.chiba-u.ac.jp

[Richard Stallman]

The changes to the existing Carbon port is basically reorganization.
Some functions/variables are moved to a new file mactoolbox.c. Either
Carbon or Carbon+Appkit port can be built with the modified source.

Maybe we can install that in 22.3.
I thouht this was a new port.

[dhruva]

Hi,

Post by Randal L. Schwartz
more smoke testing for OSX. Please let me know if that changes, or tell me if
there's a way to back out the multi-tty branch, or something.

With many issues cropping up due to multi-tty code, would it be
possible to have a seperate branch with pre-multi-tty into which
UNICODE could be merged in. UNICODE branch is much closer to the HEAD
than multi-tty was before merge. UNICODE is almost a platform
independent feature where as the current multi-tty is more GNU/Linux
(and other UNIX) specific. At first go, would it be better to have
UNICODE in the HEAD and get the multi-tty branch up to the HEAD level
(with UNICODE) and finally bring it in to the main stream.
We have active maintainer and development on the UNICODE branch and
issues will get resolved much faster.

The above proposition is based on a very top level view I have on this
topic not knowing the real efforts involved. I am no way trying to
undermine the efforts of the fellow developers that has gone in to the
creation of multi-tty and merging of it to the HEAD.

-dky

[Jason Rumney]

Post by dhruva
The above proposition is based on a very top level view I have on this
topic not knowing the real efforts involved. I am no way trying to
undermine the efforts of the fellow developers that has gone in to the
creation of multi-tty and merging of it to the HEAD.

We already discussed this at length a few months ago, and decided to
merge multi-tty first. The real work is in merging the unicode branch
with multi-tty whichever direction it is done in, as both branches were
being kept up to date with the trunk already, so I don't see it making
much difference, and certainly not worth the effort to go back and redo
it now.

[Richard Stallman]

At first go, would it be better to have
UNICODE in the HEAD and get the multi-tty branch up to the HEAD level
(with UNICODE) and finally bring it in to the main stream.

That would be a lot of backtracking, and it doesn't make sense.

What we need to do now is merge the multi-tty changes into the
Unicode-2 branch, then install the Unicode-2 changes into the trunk.

[David Kastrup]

Post by dhruva
At first go, would it be better to have
UNICODE in the HEAD and get the multi-tty branch up to the HEAD level
(with UNICODE) and finally bring it in to the main stream.
That would be a lot of backtracking, and it doesn't make sense.
What we need to do now is merge the multi-tty changes into the
Unicode-2 branch, then install the Unicode-2 changes into the trunk.

In my opinion, what we need to do now is cleaning up multi-tty until
people are comfortable with it. No sense in merging until that is the
case, is it?

[Richard Stallman]

Post by Richard Stallman
What we need to do now is merge the multi-tty changes into the
Unicode-2 branch, then install the Unicode-2 changes into the trunk.

In my opinion, what we need to do now is cleaning up multi-tty until
people are comfortable with it. No sense in merging until that is the
case, is it?

We should do that too. I am not sure that the order is crucial.

[Richard Stallman]

I might be misreading this, but does this mean that mac carbon is essentially
dead now, and won't be fixed, thanks to multi-tty being merged?

We have no policy that it should NOT be fixed. (I don't know much
about MacOS, and I am not sure how Carbon and Cocoa relate to each
other.)

However, fixing it is up to those who want to make it work.