Loading ...
Sorry, an error occurred while loading the content.

Re: Panther gVim

Expand Messages
  • David Sewell
    ... Buy? Surely Apple can afford to donate a copy...? If not, just set up a Paypal page for donations & I m sure the grateful Vim community will cover the cost
    Message 1 of 23 , Oct 9, 2003
    • 0 Attachment
      On Thu, 9 Oct 2003, Bram Moolenaar wrote:

      > For the GUI version I'm going to make a few modifications. Hopefully I
      > am able to finish this in time for when Panther is in the stores.
      > I'm lagging behind with my planned work, thus I can't promise anything.
      > I probably have to buy Panther first anyway!

      Buy? Surely Apple can afford to donate a copy...? If not, just set up a
      Paypal page for donations & I'm sure the grateful Vim community will
      cover the cost right away!

      David

      --
      David Sewell, Managing Editor
      Electronic Imprint, The University of Virginia Press
      PO Box 400318, Charlottesville, VA 22904-4318 USA
      Courier: 310 Old Ivy Way, Suite 302, Charlottesville VA 22903
      Email: dsewell@... Tel: +1 434 924 9973
      Web: http://www.ei.virginia.edu/
    • Bram Moolenaar
      ... Yeah, it s a bit strange to pay money for something that I made myself. Some companies give out free copies to contributors, I ll find out if Apple does
      Message 2 of 23 , Oct 9, 2003
      • 0 Attachment
        David Sewell wrote:

        > On Thu, 9 Oct 2003, Bram Moolenaar wrote:
        >
        > > For the GUI version I'm going to make a few modifications. Hopefully I
        > > am able to finish this in time for when Panther is in the stores.
        > > I'm lagging behind with my planned work, thus I can't promise anything.
        > > I probably have to buy Panther first anyway!
        >
        > Buy? Surely Apple can afford to donate a copy...?

        Yeah, it's a bit strange to pay money for something that I made myself.
        Some companies give out free copies to contributors, I'll find out if
        Apple does this.

        > If not, just set up a Paypal page for donations & I'm sure the
        > grateful Vim community will cover the cost right away!

        I'm considering this, especially since my contract work just ended.

        --
        "The sun oozed over the horizon, shoved aside darkness, crept along the
        greensward, and, with sickly fingers, pushed through the castle window,
        revealing the pillaged princess, hand at throat, crown asunder, gaping
        in frenzied horror at the sated, sodden amphibian lying beside her,
        disbelieving the magnitude of the frog's deception, screaming madly,
        "You lied!"
        - Winner of the Bulwer-Lytton contest (San Jose State University),
        wherein one writes only the first line of a bad novel

        /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
        /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
        \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
        \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
      • Benji Fisher
        ... First, I am sorry to be out of touch for so long. More on that later. Panther is due out in a few days. I will be pleasantly surprised if Vim.app is
        Message 3 of 23 , Oct 21, 2003
        • 0 Attachment
          On Thu, Oct 09, 2003 at 04:22:44PM +0200, Bram Moolenaar wrote:
          >
          > Ricardo Signes wrote:
          >
          > > When can we expect to seee Panther-compiled gVim? :)
          > >
          > > I'd be happy to try compiling it, if it's expected to be that simple...
          >
          > If you are looking for the console version: Just type "vi". :-)
          >
          > In a beta version they included version 6.2 without any patches. I'm
          > not sure what is in the final release.
          >
          > For the GUI version I'm going to make a few modifications. Hopefully I
          > am able to finish this in time for when Panther is in the stores.
          > I'm lagging behind with my planned work, thus I can't promise anything.
          > I probably have to buy Panther first anyway!

          First, I am sorry to be out of touch for so long. More on that
          later.

          Panther is due out in a few days. I will be pleasantly surprised
          if Vim.app is included. In the mean time, I still get occasional
          requests for a version that works on Panther. (I cannot upgrade from
          Jaguar until I buy a bigger hard drive for my PowerBook.) Does anyone
          have a working version? If I compile a version on Jaguar without Perl
          support, is it likely to run on Panther?

          I am testing the latest patches right now. If all works, I will
          uppload Vim.app 6.2.127 to http://macvim.swdev.org/OSX/ today. At some
          point (maybe in a week or two) we should have a discussion about how to
          provide the option for more Mac-standard menus, as in the system gvimrc
          file I distribute. Also, should we provide eVim.app etc. and a
          clickable method to run multiple instances of Vim.app ?

          --Benji Fisher
        • Thomas Koch
          ... Sorry, no. After several hours of trying (and heavy patching, i can t apply 6.2.18 to 6.2.17 and some other 6.2.x patches doesnt apply correctly, 6.2.100
          Message 4 of 23 , Oct 21, 2003
          • 0 Attachment
            Am 21.10.2003 um 15:34 schrieb Benji Fisher:

            > Panther is due out in a few days. I will be pleasantly surprised
            > if Vim.app is included. In the mean time, I still get occasional
            > requests for a version that works on Panther. (I cannot upgrade from
            > Jaguar until I buy a bigger hard drive for my PowerBook.) Does anyone
            > have a working version?

            Sorry, no. After several hours of trying (and heavy patching, i can't
            apply 6.2.18 to 6.2.17 and some other 6.2.x patches doesnt apply
            correctly, 6.2.100 for example, so i must do it by hand *grr*) i was
            not able to compile Carbon vim on Panther.

            > If I compile a version on Jaguar without Perl
            > support, is it likely to run on Panther?

            Just try it. The 10.2 Carbon Vim binary only complains about a missing
            perl library.

            Tom.
          • Bram Moolenaar
            ... I don t think so. The command-line vi is Vim 6.2, there is no GUI Vim as far as I know. ... That should work. I m not sure about Python, Panther uses
            Message 5 of 23 , Oct 21, 2003
            • 0 Attachment
              Benji Fisher wrote:

              > Panther is due out in a few days. I will be pleasantly surprised
              > if Vim.app is included.

              I don't think so. The command-line "vi" is Vim 6.2, there is no GUI
              Vim as far as I know.

              > In the mean time, I still get occasional
              > requests for a version that works on Panther. (I cannot upgrade from
              > Jaguar until I buy a bigger hard drive for my PowerBook.) Does anyone
              > have a working version? If I compile a version on Jaguar without Perl
              > support, is it likely to run on Panther?

              That should work. I'm not sure about Python, Panther uses Python 2.3.
              If you can produce an executable I could try it out. I still didn't
              have time to look into this myself...

              > I am testing the latest patches right now. If all works, I will
              > uppload Vim.app 6.2.127 to http://macvim.swdev.org/OSX/ today. At some
              > point (maybe in a week or two) we should have a discussion about how to
              > provide the option for more Mac-standard menus, as in the system gvimrc
              > file I distribute. Also, should we provide eVim.app etc. and a
              > clickable method to run multiple instances of Vim.app ?

              Sounds good to me.

              --
              ARTHUR: Who are you?
              TALL KNIGHT: We are the Knights Who Say "Ni"!
              BEDEVERE: No! Not the Knights Who Say "Ni"!
              "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
              /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
              \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
              \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
            • Benji Fisher
              ... OK, I will try posting a version with neither Perl nor Python. ... So far, I have compiled versions with Normal and Huge features. First problem: % ./Vim
              Message 6 of 23 , Oct 21, 2003
              • 0 Attachment
                On Tue, Oct 21, 2003 at 04:37:16PM +0200, Bram Moolenaar wrote:
                >
                > Benji Fisher wrote:
                >
                > > In the mean time, I still get occasional
                > > requests for a version that works on Panther. (I cannot upgrade from
                > > Jaguar until I buy a bigger hard drive for my PowerBook.) Does anyone
                > > have a working version? If I compile a version on Jaguar without Perl
                > > support, is it likely to run on Panther?
                >
                > That should work. I'm not sure about Python, Panther uses Python 2.3.
                > If you can produce an executable I could try it out. I still didn't
                > have time to look into this myself...

                OK, I will try posting a version with neither Perl nor Python.

                > > I am testing the latest patches right now. If all works, I will
                > > uppload Vim.app 6.2.127 to http://macvim.swdev.org/OSX/ today. At some
                > > point (maybe in a week or two) we should have a discussion about how to
                > > provide the option for more Mac-standard menus, as in the system gvimrc
                > > file I distribute. Also, should we provide eVim.app etc. and a
                > > clickable method to run multiple instances of Vim.app ?
                >
                > Sounds good to me.

                So far, I have compiled versions with Normal and Huge features.

                First problem:

                % ./Vim
                :gui

                does not work. A gVim window opens, but the Terminal keeps focus and
                still shows the vim window. Keyboard input goes to the Terminal window
                and vim commands do not affect either window. I have to ctrl-z (or
                switch to another Terminal window) and kill the process.

                Second problem (minor):

                The first time I tried 'make install', Stuffit Expander was too
                slow. I got a helpful message, but it was just barely visible in the
                Terminal window. I suggest moving the lines

                @echo
                @echo "--------------------"
                @echo "If this fails, run make install again after StuffIt Expander quits."
                @echo "--------------------"
                @echo

                to the 'install_macosx' target, or maybe the 'bundle-rsrc' target.

                Third problem:

                I tried enabling perl, python, ruby, and tcl (why not?) in the
                Makefile. I get warnings about precompiled headers, which I have long
                gnored, and also

                gcc: unrecognized option '-pthread'

                and then ruby.c does not compile. Removing Ruby, I still get the gcc
                warning above and then a problem in linking:

                ld: can't locate file for: -ldl

                Other things work well: 'make test' runs smoothly, and I can drag
                a file icon onto the Vim icon in the Dock. I think I will not have time
                today to try Perl, Python, Tcl, and Ruby separately, but I will try to
                get one or two working binaries uploaded before I quit for the day.

                --Benji Fisher
              • Ricardo SIGNES
                * Benji Fisher [2003-10-21T09:34:40] ... I compiled gVim (Vim.app) from CVS on Panther just a few days ago. I ve attached the output of
                Message 7 of 23 , Oct 21, 2003
                • 0 Attachment
                  * Benji Fisher <benji@...> [2003-10-21T09:34:40]
                  > Panther is due out in a few days. I will be pleasantly surprised
                  > if Vim.app is included. In the mean time, I still get occasional
                  > requests for a version that works on Panther. (I cannot upgrade from
                  > Jaguar until I buy a bigger hard drive for my PowerBook.) Does anyone
                  > have a working version? If I compile a version on Jaguar without Perl
                  > support, is it likely to run on Panther?

                  I compiled gVim (Vim.app) from CVS on Panther just a few days ago. I've
                  attached the output of :ver

                  --
                  rjbs
                • Benji Fisher
                  ... [snip] ... [snip] I am glad to hear it works OOTB. From your :version output, it looks as though you included Normal features; I usually compile Huge
                  Message 8 of 23 , Oct 21, 2003
                  • 0 Attachment
                    On Tue, Oct 21, 2003 at 11:59:00AM -0400, Ricardo SIGNES wrote:
                    > * Benji Fisher <benji@...> [2003-10-21T09:34:40]
                    > > Panther is due out in a few days. I will be pleasantly surprised
                    > > if Vim.app is included. In the mean time, I still get occasional
                    > > requests for a version that works on Panther. (I cannot upgrade from
                    > > Jaguar until I buy a bigger hard drive for my PowerBook.) Does anyone
                    > > have a working version? If I compile a version on Jaguar without Perl
                    > > support, is it likely to run on Panther?
                    >
                    > I compiled gVim (Vim.app) from CVS on Panther just a few days ago. I've
                    > attached the output of :ver
                    >
                    > --
                    > rjbs

                    > VIM - Vi IMproved 6.2 (2003 Jun 1, compiled Oct 19 2003 23:07:42)
                    > MacOS X (unix) version
                    > Included patches: 1-127
                    > Compiled by rjbs@...
                    > Normal version with Carbon GUI. Features included (+) or not (-):
                    [snip]
                    > +path_extra -perl +postscript +printer -python +quickfix -rightleft -ruby
                    [snip]

                    I am glad to hear it works OOTB. From your :version output, it
                    looks as though you included Normal features; I usually compile Huge
                    versions. The first report is that my version with -perl -python
                    (compiled on Jaguar) also works on Panther, so we can stick with that
                    for now. If you (or any other volunteer) can compile a version with
                    +perl (and maybe also +python) that runs on Panther, I will be happy to
                    post it at http://macvim.swdev.org/OSX/ .

                    --Benji Fisher
                  • Ricardo SIGNES
                    * Benji Fisher [2003-10-21T13:59:05] ... It compiled with huge features with no complaints. --enable-perlinterp did not work and I
                    Message 9 of 23 , Oct 21, 2003
                    • 0 Attachment
                      * Benji Fisher <benji@...> [2003-10-21T13:59:05]
                      > On Tue, Oct 21, 2003 at 11:59:00AM -0400, Ricardo SIGNES wrote:
                      > > I compiled gVim (Vim.app) from CVS on Panther just a few days ago. I've
                      > > attached the output of :ver
                      >
                      > I am glad to hear it works OOTB. From your :version output, it looks
                      > as though you included Normal features; I usually compile Huge
                      > versions. The first report is that my version with -perl -python
                      > (compiled on Jaguar) also works on Panther, so we can stick with that
                      > for now. If you (or any other volunteer) can compile a version with
                      > +perl (and maybe also +python) that runs on Panther, I will be happy
                      > to post it at http://macvim.swdev.org/OSX/ .

                      It compiled with huge features with no complaints. --enable-perlinterp
                      did not work and I don't use Perl in Vim, so I'm not sure where to begin
                      dealing with it.

                      Another nice thing would be for `vim` to open the same binary as
                      Vim.app; I don't know enough about MacOS to know whether that's
                      possible.

                      --
                      rjbs
                    • Benji Fisher
                      ... I cannot help there. ... You could make /usr/bin/vim a symbolic link to the executable in Vim.app . For example, if you keep Vim.app in /Applications ,
                      Message 10 of 23 , Oct 21, 2003
                      • 0 Attachment
                        On Tue, Oct 21, 2003 at 02:35:34PM -0400, Ricardo SIGNES wrote:
                        > * Benji Fisher <benji@...> [2003-10-21T13:59:05]
                        > > On Tue, Oct 21, 2003 at 11:59:00AM -0400, Ricardo SIGNES wrote:
                        > > > I compiled gVim (Vim.app) from CVS on Panther just a few days ago. I've
                        > > > attached the output of :ver
                        > >
                        > > I am glad to hear it works OOTB. From your :version output, it looks
                        > > as though you included Normal features; I usually compile Huge
                        > > versions. The first report is that my version with -perl -python
                        > > (compiled on Jaguar) also works on Panther, so we can stick with that
                        > > for now. If you (or any other volunteer) can compile a version with
                        > > +perl (and maybe also +python) that runs on Panther, I will be happy
                        > > to post it at http://macvim.swdev.org/OSX/ .
                        >
                        > It compiled with huge features with no complaints. --enable-perlinterp
                        > did not work and I don't use Perl in Vim, so I'm not sure where to begin
                        > dealing with it.

                        I cannot help there.

                        > Another nice thing would be for `vim` to open the same binary as
                        > Vim.app; I don't know enough about MacOS to know whether that's
                        > possible.

                        You could make /usr/bin/vim a symbolic link to the executable in
                        Vim.app . For example, if you keep Vim.app in /Applications , then

                        % sudo ln -s /Applications/Vim.app/Contents/MacOS/Vim /usr/bin/vim

                        ought to do it. If you want to get rid of the old binary (and runtime
                        files) you should also do the same with /usr/bin/vi . See the FAQ's at

                        http://macvim.swdev.org/OSX/

                        for similar suggestions.

                        Of course, this will create problems with updating. What happens
                        to those symbolic links if Apple decides to update the system vi[m] as
                        part of Software Update 10.3.1.17 ?

                        --Benji Fisher
                      • Eugene Lee
                        ... I prefer not to mess with system-installed stuff. A less destruction solution is to create a shell alias. A simple Bourne shell solution: $ alias vim
                        Message 11 of 23 , Oct 21, 2003
                        • 0 Attachment
                          On Tue, Oct 21, 2003 at 04:54:24PM -0400, Benji Fisher wrote:
                          : On Tue, Oct 21, 2003 at 02:35:34PM -0400, Ricardo SIGNES wrote:
                          : >
                          : > Another nice thing would be for `vim` to open the same binary as
                          : > Vim.app; I don't know enough about MacOS to know whether that's
                          : > possible.
                          :
                          : You could make /usr/bin/vim a symbolic link to the executable in
                          : Vim.app . For example, if you keep Vim.app in /Applications , then
                          :
                          : % sudo ln -s /Applications/Vim.app/Contents/MacOS/Vim /usr/bin/vim

                          I prefer not to mess with system-installed stuff. A less destruction
                          solution is to create a shell alias. A simple Bourne shell solution:

                          $ alias vim /Applications/Vim.app/Contents/MacOS/Vim


                          --
                          Eugene Lee
                          eugene at anime dot net
                        • Lars Duening
                          ... On my machine I have created an oldfashioned /usr/local directory tree and added /usr/local/bin to my PATH - no interference with the system binaries, and
                          Message 12 of 23 , Oct 21, 2003
                          • 0 Attachment
                            On Tuesday, October 21, 2003, at 02:54 PM, Benji Fisher wrote:

                            > On Tue, Oct 21, 2003 at 02:35:34PM -0400, Ricardo SIGNES wrote:
                            >
                            >> Another nice thing would be for `vim` to open the same binary as
                            >> Vim.app; I don't know enough about MacOS to know whether that's
                            >> possible.
                            >
                            > You could make /usr/bin/vim a symbolic link to the executable in
                            > Vim.app . For example, if you keep Vim.app in /Applications , then
                            >
                            > % sudo ln -s /Applications/Vim.app/Contents/MacOS/Vim /usr/bin/vim
                            >
                            > ought to do it.

                            On my machine I have created an oldfashioned /usr/local directory tree
                            and added /usr/local/bin to my PATH - no interference with the system
                            binaries, and easy to back up, too.

                            Cheers,
                            Lars
                            --
                            Lars Duening; lars@...
                            GPG Key: http://www.bearnip.com/lars/lars-duening.gpgkey
                          • Bram Moolenaar
                            ... Did this ever work for a Carbon version? I thought :gui only worked for X-Windows versions (Motif, GTK). I now tried :gui with the new version you
                            Message 13 of 23 , Oct 23, 2003
                            • 0 Attachment
                              Benji Fisher wrote:

                              > First problem:
                              >
                              > % ./Vim
                              > :gui
                              >
                              > does not work. A gVim window opens, but the Terminal keeps focus and
                              > still shows the vim window. Keyboard input goes to the Terminal window
                              > and vim commands do not affect either window. I have to ctrl-z (or
                              > switch to another Terminal window) and kill the process.

                              Did this ever work for a Carbon version? I thought ":gui" only worked
                              for X-Windows versions (Motif, GTK).

                              I now tried ":gui" with the new version you uploaded. It works, but Vim
                              doesn't fork, thus the terminal doesn't go back to the shell. I think
                              the forking was disabled in the past. Perhaps it does work in this
                              Carbon version now.

                              > Second problem (minor):
                              >
                              > The first time I tried 'make install', Stuffit Expander was too
                              > slow. I got a helpful message, but it was just barely visible in the
                              > Terminal window. I suggest moving the lines
                              >
                              > @echo
                              > @echo "--------------------"
                              > @echo "If this fails, run make install again after StuffIt Expander quits."
                              > @echo "--------------------"
                              > @echo
                              >
                              > to the 'install_macosx' target, or maybe the 'bundle-rsrc' target.

                              Can't we add a small shell script that hangs around until the files that
                              are to be unpacked exist?

                              while test ! -f some_file; do
                              sleep 1
                              done

                              > Third problem:
                              >
                              > I tried enabling perl, python, ruby, and tcl (why not?) in the
                              > Makefile. I get warnings about precompiled headers, which I have long
                              > gnored, and also

                              Those precompiled header warnings are irritating, especially since I
                              can't find a way to recompile the headers...

                              > gcc: unrecognized option '-pthread'
                              >
                              > and then ruby.c does not compile. Removing Ruby, I still get the gcc
                              > warning above and then a problem in linking:
                              >
                              > ld: can't locate file for: -ldl

                              This is probably caused by one of the configure checks that include
                              specific compile arguments. This is tricky, but there is no other way
                              to obtain those compiler arguments. The configure checks could be made
                              more robust. A language should be disabled when compiling/linking fails
                              after adding compiler flags for the language.

                              > Other things work well: 'make test' runs smoothly, and I can drag
                              > a file icon onto the Vim icon in the Dock. I think I will not have time
                              > today to try Perl, Python, Tcl, and Ruby separately, but I will try to
                              > get one or two working binaries uploaded before I quit for the day.

                              I'm glad we are making progress. And I haven't heard serious problems
                              with the new way of producing the Carbon version, this seems to be the
                              right way to go.

                              --
                              Overflow on /dev/null, please empty the bit bucket.

                              /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                              /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                              \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                              \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
                            • Eric Y. Kow
                              ... good point... the file we want is gui_mac.rsrc. There s probably some resource-fork business that I don t understand (which is the reason why we can t just
                              Message 14 of 23 , Oct 23, 2003
                              • 0 Attachment
                                On Thu, Oct 23, 2003 at 14:54:39 +0200, Bram Moolenaar Bram-at-moolenaar.net |vim-mac@.../1.0-Allow| wrote:
                                > > @echo "--------------------"
                                > > @echo "If this fails, run make install again after StuffIt Expander quits."
                                > > @echo "--------------------"

                                > Can't we add a small shell script that hangs around until the files that
                                > are to be unpacked exist?
                                >
                                > while test ! -f some_file; do
                                > sleep 1
                                > done

                                good point... the file we want is gui_mac.rsrc.
                                There's probably some resource-fork business that I don't understand
                                (which is the reason why we can't just supply gui_mac.rsrc) but this is
                                at least better than nothing.

                                --
                                Eric Kow http://www.loria.fr/~kow
                                PGP Key ID: 08AC04F9 Merci de corriger mon français.
                              • Bram Moolenaar
                                ... OK, please try this: gui_mac.rsrc: open os_mac.rsr.hqx @while test ! -f gui_mac.rsrc; do sleep 1; done -- ARTHUR: Well, I can t just call you `Man .
                                Message 15 of 23 , Oct 24, 2003
                                • 0 Attachment
                                  Eric Y. Kow wrote:

                                  > On Thu, Oct 23, 2003 at 14:54:39 +0200, Bram Moolenaar Bram-at-moolenaar.ne=
                                  > t |vim-mac@.../1.0-Allow| wrote:
                                  > > > @echo "--------------------"
                                  > > > @echo "If this fails, run make install again after StuffIt Expa=
                                  > nder quits."
                                  > > > @echo "--------------------"
                                  >
                                  > > Can't we add a small shell script that hangs around until the files that
                                  > > are to be unpacked exist?
                                  > >=20
                                  > > while test ! -f some_file; do
                                  > > sleep 1
                                  > > done
                                  >
                                  > good point... the file we want is gui_mac.rsrc.
                                  > There's probably some resource-fork business that I don't understand
                                  > (which is the reason why we can't just supply gui_mac.rsrc) but this is
                                  > at least better than nothing.

                                  OK, please try this:

                                  gui_mac.rsrc:
                                  open os_mac.rsr.hqx
                                  @while test ! -f gui_mac.rsrc; do \
                                  sleep 1; \
                                  done


                                  --
                                  ARTHUR: Well, I can't just call you `Man'.
                                  DENNIS: Well, you could say `Dennis'.
                                  ARTHUR: Well, I didn't know you were called `Dennis.'
                                  DENNIS: Well, you didn't bother to find out, did you?
                                  The Quest for the Holy Grail (Monty Python)

                                  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net \\\
                                  /// Creator of Vim - Vi IMproved -- http://www.Vim.org \\\
                                  \\\ Project leader for A-A-P -- http://www.A-A-P.org ///
                                  \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html ///
                                • Stephen Riehm
                                  Hi Bram, Eric, Just a quick note: opening .hqx files can have nasty side effects... I had real problems with that line because I ve got stuffit expander
                                  Message 16 of 23 , Oct 24, 2003
                                  • 0 Attachment
                                    Hi Bram, Eric,

                                    Just a quick note: opening .hqx files can have nasty side effects...
                                    I had real problems with that line because I've got stuffit expander
                                    configured to always expand onto the desktop (I only ever expand stuff
                                    I've just downloaded... and having it expand on the desktop means I
                                    don't lose track of the things I haven't fully tried out yet - I move
                                    them into a proper folder (or trash) after testing)

                                    Is there was to open the .hqx file in such a way that it always expands
                                    into the current directory?
                                    (ie: some special command line arg to override the user settings?)

                                    Cheers,

                                    Steve

                                    On Freitag, Oktober 24, 2003, at 12:47 Uhr, Bram Moolenaar wrote:

                                    >
                                    > Eric Y. Kow wrote:
                                    >
                                    >> On Thu, Oct 23, 2003 at 14:54:39 +0200, Bram Moolenaar
                                    >> Bram-at-moolenaar.ne=
                                    >> t |vim-mac@.../1.0-Allow| wrote:
                                    >>>> @echo "--------------------"
                                    >>>> @echo "If this fails, run make install again after StuffIt
                                    >>>> Expa=
                                    >> nder quits."
                                    >>>> @echo "--------------------"
                                    >>
                                    >>> Can't we add a small shell script that hangs around until the files
                                    >>> that
                                    >>> are to be unpacked exist?
                                    >>> =20
                                    >>> while test ! -f some_file; do
                                    >>> sleep 1
                                    >>> done
                                    >>
                                    >> good point... the file we want is gui_mac.rsrc.
                                    >> There's probably some resource-fork business that I don't understand
                                    >> (which is the reason why we can't just supply gui_mac.rsrc) but this
                                    >> is
                                    >> at least better than nothing.
                                    >
                                    > OK, please try this:
                                    >
                                    > gui_mac.rsrc:
                                    > open os_mac.rsr.hqx
                                    > @while test ! -f gui_mac.rsrc; do \
                                    > sleep 1; \
                                    > done
                                    >
                                    >
                                    > --
                                    > ARTHUR: Well, I can't just call you `Man'.
                                    > DENNIS: Well, you could say `Dennis'.
                                    > ARTHUR: Well, I didn't know you were called `Dennis.'
                                    > DENNIS: Well, you didn't bother to find out, did you?
                                    > The Quest for the Holy Grail (Monty
                                    > Python)
                                    >
                                    > /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net
                                    > \\\
                                    > /// Creator of Vim - Vi IMproved -- http://www.Vim.org
                                    > \\\
                                    > \\\ Project leader for A-A-P -- http://www.A-A-P.org
                                    > ///
                                    > \\\ Help AIDS victims, buy here: http://ICCF-Holland.org/click1.html
                                    > ///
                                    >
                                    >
                                    Steve
                                  • Daniel Sandler
                                    ... That s for sure. Is there any particular reason that BinHex is being used to encapsulate these Mac resources, rather than something a little easier to
                                    Message 17 of 23 , Oct 24, 2003
                                    • 0 Attachment
                                      > Just a quick note: opening .hqx files can have nasty side effects...

                                      That's for sure.

                                      Is there any particular reason that BinHex is being used to encapsulate
                                      these Mac resources, rather than something a little easier to manipulate
                                      from make or jam? (That is, something that can be used with blocking
                                      shell tools?) I have a couple of ideas on how this might be done:


                                      Suggestion 1: Use the OS X pseudo-file spec to manipulate resources

                                      Background: Apple's implementation of POSIX file ops for resource-fork
                                      filesystems seems to provide some pseudo-file paths allowing direct
                                      access to the different forks of a file as separate file descriptors.
                                      (There appear to be some relevant #defines in sys/paths.h .)

                                      Usage: To get started, split gui_mac.rsrc into data and resource
                                      forks:

                                      cat gui_mac.rsrc/..namedfork/rsrc > os_mac.rsr.rsrcfork
                                      cat gui_mac.rsrc/..namedfork/data > os_mac.rsr.datafork

                                      At this point, you have two files containing only data forks.
                                      Therefore, they ought to be safe to add to CVS:

                                      cvs add os_mac.rsr.{rsrc,data}fork

                                      At build time, reverse the procedure:

                                      # fictitious Makefile excerpt
                                      gui_mac.rsrc:
                                      touch gui_mac.rsrc # need to have the file present first
                                      cat os_mac.rsr.rsrcfork > gui_mac.rsrc/..namedfork/rsrc
                                      cat os_mac.rsr.datafork > gui_mac.rsrc/..namedfork/data

                                      Downside: I believe the ..namedfork spec was introduced in OS X 10.2,
                                      so you might be limiting the platforms on which vim can be built.

                                      Another downside: anything I find in a header file delimited by #ifdef
                                      __APPLE_API_PRIVATE sort of gives me the creeps. It doesn't seem to
                                      be a well-documented API, and so could go away at any time.
                                      Information on this API is scarce and sometimes inconsistent; the most
                                      authoritative note I've seen (read: "comes from an @... email
                                      address") is here: http://nntp.x.perl.org/group/perl.macosx/4260 .


                                      Suggestion 2: use DeRez/Rez, part of the OS X developer tools

                                      This is what I used to store resources in CVS for my OS X projects
                                      before I learned about the ..namedfork trick.

                                      Usage: once you have a gui_mac.rsrc you like, use DeRez to create a
                                      gui_mac_static.r (since gui_mac.r already exists to include dynamic
                                      stuff like VIM_VERSION_*) and check the new .r file into CVS. Use
                                      $REZ from the Makefile to reconstitute gui_mac.rsrc when needed.


                                      I hope this is helpful; I apologize for not submitting proper patches,
                                      but I'm not set up to build OS X vim at the moment...

                                      -dan, re-engaging his lurking device
                                    • dan sandler
                                      ... That s for sure. Is there any particular reason that BinHex is being used to encapsulate these Mac resources, rather than something a little easier to
                                      Message 18 of 23 , Oct 24, 2003
                                      • 0 Attachment
                                        > Just a quick note: opening .hqx files can have nasty side effects...

                                        That's for sure.

                                        Is there any particular reason that BinHex is being used to encapsulate
                                        these Mac resources, rather than something a little easier to manipulate
                                        from make or jam? (That is, something that can be used with blocking
                                        shell tools?) I have a couple of ideas on how this might be done:


                                        Suggestion 1: Use the OS X pseudo-file spec to manipulate resources

                                        Background: Apple's implementation of POSIX file ops for resource-fork
                                        filesystems seems to provide some pseudo-file paths allowing direct
                                        access to the different forks of a file as separate file descriptors.
                                        (There appear to be some relevant #defines in sys/paths.h .)

                                        Usage: To get started, split gui_mac.rsrc into data and resource
                                        forks:

                                        cat gui_mac.rsrc/..namedfork/rsrc > os_mac.rsr.rsrcfork
                                        cat gui_mac.rsrc/..namedfork/data > os_mac.rsr.datafork

                                        At this point, you have two files containing only data forks.
                                        Therefore, they ought to be safe to add to CVS:

                                        cvs add os_mac.rsr.{rsrc,data}fork

                                        At build time, reverse the procedure:

                                        # fictitious Makefile excerpt
                                        gui_mac.rsrc:
                                        touch gui_mac.rsrc # need to have the file present first
                                        cat os_mac.rsr.rsrcfork > gui_mac.rsrc/..namedfork/rsrc
                                        cat os_mac.rsr.datafork > gui_mac.rsrc/..namedfork/data

                                        Downside: I believe the ..namedfork spec was introduced in OS X 10.2,
                                        so you might be limiting the platforms on which vim can be built.

                                        Another downside: anything I find in a header file delimited by #ifdef
                                        __APPLE_API_PRIVATE sort of gives me the creeps. It doesn't seem to
                                        be a well-documented API, and so could go away at any time.
                                        Information on this API is scarce and sometimes inconsistent; the most
                                        authoritative note I've seen (read: "comes from an @... email
                                        address") is here: http://nntp.x.perl.org/group/perl.macosx/4260 .


                                        Suggestion 2: use DeRez/Rez, part of the OS X developer tools

                                        This is what I used to store resources in CVS for my OS X projects
                                        before I learned about the ..namedfork trick.

                                        Usage: once you have a gui_mac.rsrc you like, use DeRez to create a
                                        gui_mac_static.r (since gui_mac.r already exists to include dynamic
                                        stuff like VIM_VERSION_*) and check the new .r file into CVS. Use
                                        $REZ from the Makefile to reconstitute gui_mac.rsrc when needed.


                                        I hope this is helpful; I apologize for not submitting proper patches,
                                        but I'm not set up to build OS X vim at the moment...

                                        -dan, re-engaging his lurking device
                                      • Gregory Seidman
                                        On Fri, Oct 24, 2003 at 03:48:02PM -0700, dan sandler wrote: [...] } Suggestion 1: Use the OS X pseudo-file spec to manipulate resources [...] } cat
                                        Message 19 of 23 , Oct 24, 2003
                                        • 0 Attachment
                                          On Fri, Oct 24, 2003 at 03:48:02PM -0700, dan sandler wrote:
                                          [...]
                                          } Suggestion 1: Use the OS X pseudo-file spec to manipulate resources
                                          [...]
                                          } cat gui_mac.rsrc/..namedfork/rsrc > os_mac.rsr.rsrcfork
                                          } cat gui_mac.rsrc/..namedfork/data > os_mac.rsr.datafork
                                          [...]
                                          } At build time, reverse the procedure:
                                          }
                                          } # fictitious Makefile excerpt
                                          } gui_mac.rsrc:
                                          } touch gui_mac.rsrc # need to have the file present first
                                          } cat os_mac.rsr.rsrcfork > gui_mac.rsrc/..namedfork/rsrc
                                          } cat os_mac.rsr.datafork > gui_mac.rsrc/..namedfork/data

                                          Or, very slightly easier:

                                          gui_mac.rsrc:
                                          cp os_mac.rsr.datafork gui_mac.rsrc
                                          cat os_mac.rsr.rsrcfork > gui_mac.rsrc/..namedfork/rsrc

                                          } Downside: I believe the ..namedfork spec was introduced in OS X 10.2,
                                          } so you might be limiting the platforms on which vim can be built.

                                          It works on my 10.1 system. Can't speak for 10.0, though.

                                          [...]
                                          --Greg
                                        • Eric Y. Kow
                                          Folks, Thanks for the discussion. It s been educational. ... As a matter of personal taste, I d avoid this kind of stuff. ... I like this approach much
                                          Message 20 of 23 , Oct 25, 2003
                                          • 0 Attachment
                                            Folks,

                                            Thanks for the discussion. It's been educational.

                                            On Fri, Oct 24, 2003 at 15:48:02 -0700, dan sandler dsandler-at-dsandler.org |vim-mac@.../1.0-Allow| wrote:
                                            > Another downside: anything I find in a header file delimited by #ifdef
                                            > __APPLE_API_PRIVATE sort of gives me the creeps. It doesn't seem to

                                            As a matter of personal taste, I'd avoid this kind of stuff.

                                            > Suggestion 2: use DeRez/Rez, part of the OS X developer tools
                                            ...
                                            > Usage: once you have a gui_mac.rsrc you like, use DeRez to create a
                                            > gui_mac_static.r (since gui_mac.r already exists to include dynamic
                                            > stuff like VIM_VERSION_*) and check the new .r file into CVS. Use
                                            > $REZ from the Makefile to reconstitute gui_mac.rsrc when needed.

                                            I like this approach much better! Especially now that it has been
                                            blessed by somebody who presumably has clue what's going on :-)

                                            Is deRez'ing gui_mac.rsrc basically equivilant to de-compiling it?
                                            If so, would it be too onerous to re-write gui_mac_static.r by hand, or
                                            find the guy that wrote the original? If we're going to have some kind
                                            of source around, it might as well be readable, eh?

                                            --
                                            Eric Kow http://www.loria.fr/~kow
                                            PGP Key ID: 08AC04F9 Merci de corriger mon français.
                                          • Dany St-Amant
                                            Le vendredi, 24 oct 2003, à 17:31 Canada/Eastern, Daniel Sandler a ... As I always decode it before hand, I never saw an issue. Beside Muraoka s suggestion,
                                            Message 21 of 23 , Oct 26, 2003
                                            • 0 Attachment
                                              Le vendredi, 24 oct 2003, à 17:31 Canada/Eastern, Daniel Sandler a
                                              écrit :

                                              >> Just a quick note: opening .hqx files can have nasty side effects...
                                              >
                                              > That's for sure.
                                              >
                                              > Is there any particular reason that BinHex is being used to encapsulate
                                              > these Mac resources, rather than something a little easier to
                                              > manipulate
                                              > from make or jam? (That is, something that can be used with blocking
                                              > shell tools?) I have a couple of ideas on how this might be done:

                                              As I always decode it before hand, I never saw an issue. Beside
                                              Muraoka's
                                              suggestion, one could possible use an AppleScript as Stuffit Expander
                                              accept
                                              a destination folder through AppleScript.

                                              > Suggestion 1: Use the OS X pseudo-file spec to manipulate resources

                                              No can do. This will not work on the pre-MacOS X.

                                              > Suggestion 2: use DeRez/Rez, part of the OS X developer tools

                                              This should work fine as both MPW and old CodeWarrior version
                                              supported Rez.

                                              > Usage: once you have a gui_mac.rsrc you like, use DeRez to create a
                                              > gui_mac_static.r (since gui_mac.r already exists to include dynamic
                                              > stuff like VIM_VERSION_*) and check the new .r file into CVS. Use
                                              > $REZ from the Makefile to reconstitute gui_mac.rsrc when needed.

                                              One file should be enough as the current gui_mac.r was extracted from
                                              the original gui_mac.rsrc to properly propagate the version number.

                                              Dany
                                            Your message has been successfully submitted and would be delivered to recipients shortly.