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

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

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

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

[Dan Nicolaescu]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

  > 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? 

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

[Randal L. Schwartz]

>>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:

Dan> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>> 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 - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

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

[Randal L. Schwartz]

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

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?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

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

[Dan Nicolaescu]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

  > >>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
  > 
  > 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?

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..

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

[Randal L. Schwartz]

>>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:

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...

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

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

[Dan Nicolaescu]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

  > >>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > 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.

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

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 29 Aug 2007 09:28:53 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

> merlyn@stonehenge.com (Randal L. Schwartz) writes:
>> >>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:
>> 
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..
>> 
>> 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
				mituharu@math.s.chiba-u.ac.jp

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

[Dan Nicolaescu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

  > >>>>> On Wed, 29 Aug 2007 09:28:53 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:
  > 
  > > merlyn@stonehenge.com (Randal L. Schwartz) writes:
  > >> >>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:
  > >> 
  > 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..
  > >> 
  > >> 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 ... 

  > (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. 

  >     (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
  > 				mituharu@math.s.chiba-u.ac.jp

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

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 29 Aug 2007 17:47:48 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

>> No.  url-type used below is a macro.

> It should not matter ... 

>> (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
				mituharu@math.s.chiba-u.ac.jp

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

[Dan Nicolaescu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

  > >>>>> On Wed, 29 Aug 2007 17:47:48 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:
  > 
  > >> No.  url-type used below is a macro.
  > 
  > > It should not matter ... 
  > 
  > >> (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.

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

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 29 Aug 2007 18:21:34 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

>> 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
				mituharu@math.s.chiba-u.ac.jp

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

[Dan Nicolaescu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

  > >>>>> On Wed, 29 Aug 2007 18:21:34 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:
  > 
  > >> 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.

  > Is it also necessary for bootstrap-emacs?

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

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

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 29 Aug 2007 18:42:07 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

>> 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
				mituharu@math.s.chiba-u.ac.jp

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

[Dan Nicolaescu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

  > >>>>> On Wed, 29 Aug 2007 18:42:07 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:
  > 
  > >> 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.

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

[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)

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

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 30 Aug 2007 16:50:00 -0400, Richard Stallman <rms@gnu.org> said:

>     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
				mituharu@math.s.chiba-u.ac.jp

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

[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?

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

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 31 Aug 2007 14:21:11 -0400, Richard Stallman <rms@gnu.org> said:

>> 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
				mituharu@math.s.chiba-u.ac.jp

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

[Stefan Monnier]

> 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

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 31 Aug 2007 22:06:36 -0400
> Cc: dann@ics.uci.edu, emacs-devel@gnu.org, rms@gnu.org, merlyn@stonehenge.com
> 
> > 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.

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

[Richard Stallman]

    > 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?

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

[Stefan Monnier]

>> > 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

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

[Eli Zaretskii]

> Cc: mituharu@math.s.chiba-u.ac.jp,  dann@ics.uci.edu,  emacs-devel@gnu.org,
> 	  rms@gnu.org,  merlyn@stonehenge.com
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Mon, 03 Sep 2007 16:43:18 -0400
> 
> > 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?

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

[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?

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

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     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.

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

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 04 Sep 2007 14:29:55 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

> 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
				mituharu@math.s.chiba-u.ac.jp

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

[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?

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

[Stefan Monnier]

>     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

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

[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.

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

[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.

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

[Randal L. Schwartz]

>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:

>>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:
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



-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

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

[Dan Nicolaescu]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

  > >>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
  > 
  > >>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 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....

  > 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.

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

[Randal L. Schwartz]

>>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:

>> 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"?

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

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

[Dan Nicolaescu]

merlyn@stonehenge.com (Randal L. Schwartz) writes:

  > >>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:
  > 
  > >> 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.

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

[chad brown]

> 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

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

[chad brown]

Preliminary gdb info on macosx carbon crash:

> 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
> }

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

[Dan Nicolaescu]

chad brown <y@MIT.EDU> writes:

  > Preliminary gdb info on macosx carbon crash:
  > 
  > > 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
  > > }

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

[chad brown]

The current problem with multi-tty on macosx seems to come from  
configure.  Namely, this code in src/config.in:

> /* 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

results in:

> /* 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

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

[Glenn Morris]

chad brown wrote:

> 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

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

[Dan Nicolaescu]

Glenn Morris <rgm@gnu.org> writes:

  > chad brown wrote:
  > 
  > > 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... 

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

[chad brown]

> 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

> 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
>
> Lisp Backtrace:
> "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

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

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 29 Aug 2007 09:41:50 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

>> 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
				mituharu@math.s.chiba-u.ac.jp

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

[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!)


On Aug 30, 2007, at 8:08 PM, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp 
 > wrote:

>>>>>> On Wed, 29 Aug 2007 09:41:50 -0700, Dan Nicolaescu <dann@ics.uci.edu 
>>>>>> > said:
>
>>> 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
>                mituharu@math.s.chiba-u.ac.jp
>

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

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 30 Aug 2007 20:53:09 -0400, "Randal L. Schwartz" <merlyn@stonehenge.com> said:

> 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
				mituharu@math.s.chiba-u.ac.jp

>>>>>>> On Wed, 29 Aug 2007 09:41:50 -0700, Dan Nicolaescu
>>>>>>> <dann@ics.uci.edu > said:
>> 
>>>> 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.

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

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 31 Aug 2007 10:03:19 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said:

>>>>> On Thu, 30 Aug 2007 20:53:09 -0400, "Randal L. Schwartz" <merlyn@stonehenge.com> said:
>> 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
> multi-tty port in May.

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

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

[Dan Nicolaescu]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

  > >>>>> On Wed, 29 Aug 2007 09:41:50 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:
  > 
  > >> 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.

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.

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

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 31 Aug 2007 01:12:38 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:

> YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>> >>>>> On Wed, 29 Aug 2007 09:41:50 -0700, Dan Nicolaescu <dann@ics.uci.edu> said:
>> 
>> >> 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.

> 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.

> 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.

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
				mituharu@math.s.chiba-u.ac.jp

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

[Randal L. Schwartz]

>>>>> "Dan" == Dan Nicolaescu <dann@ics.uci.edu> writes:

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.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

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

[Jason Rumney]

Randal L. Schwartz wrote:
> 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.

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

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 03 Sep 2007 15:49:26 +0100, Jason Rumney <jasonr@gnu.org> said:

> Randal L. Schwartz wrote:
>> 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.

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

Right.

> 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
				mituharu@math.s.chiba-u.ac.jp

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

[Yavor Doganov]

В Tue, 04 Sep 2007 10:01:35 +0900, YAMAMOTO Mitsuharu написа:

> 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...

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

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 4 Sep 2007 06:47:23 +0000 (UTC), Yavor Doganov <yavor@gnu.org> said:

> 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.

> 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
				mituharu@math.s.chiba-u.ac.jp

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

[Richard Stallman]

    > 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.

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

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 04 Sep 2007 18:58:04 -0400, Richard Stallman <rms@gnu.org> said:

>     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
				mituharu@math.s.chiba-u.ac.jp

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

[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.

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

[YAMAMOTO Mitsuharu]

>>>>> On Wed, 05 Sep 2007 16:02:47 -0400, Richard Stallman <rms@gnu.org> said:

>> 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.

> 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
				mituharu@math.s.chiba-u.ac.jp

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

[Yavor Doganov]

YAMAMOTO Mitsuharu wrote:
> 
> The former is the Carbon+AppKit port I'm recently developing on Emacs
> 22. 
[...]
> The latter is the Cocoa/GNUstep port, developed by Adrian Robert et
> al. on 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.

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.

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

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 06 Sep 2007 08:53:26 +0300, Yavor Doganov <yavor@gnu.org> said:
--text follows this line--
> 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.

> 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.

> 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
				mituharu@math.s.chiba-u.ac.jp

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

[Yavor Doganov]

В Thu, 06 Sep 2007 17:28:05 +0900, 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.

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

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 6 Sep 2007 09:17:44 +0000 (UTC), Yavor Doganov <yavor@gnu.org> said:

>> 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.

> 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
				mituharu@math.s.chiba-u.ac.jp

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

[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.

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

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 07 Sep 2007 02:30:40 -0400, Richard Stallman <rms@gnu.org> said:

>     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.

>>>>> On Fri, 07 Sep 2007 02:30:40 -0400, Richard Stallman <rms@gnu.org> said:

> 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.

>>>>> On Fri, 07 Sep 2007 02:31:47 -0400, Richard Stallman <rms@gnu.org> said:

>       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
				mituharu@math.s.chiba-u.ac.jp

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

[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.

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

[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.

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

[dhruva]

Hi,

On 9/3/07, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> 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

-- 
Dhruva Krishnamurthy
Contents reflect my personal views only!

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

[Jason Rumney]

dhruva wrote:
> 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.

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

[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.

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

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     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?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

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

[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.

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

[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.