[GAP] Gap.app v0.5

Russ Woodroofe rsw9 at cornell.edu
Tue May 15 11:32:37 BST 2018



Dear Max, all,

FIRST:
I had intended to get another release candidate out, but as GAP 4.9 is out yesterday, I am going to go ahead and release Gap.app 0.5.  Editions with and without a builtin copy are available at:
https://cocoagap.sourceforge.io/
I'm going to do a tiny bit more testing with GAP 4.9 before announcing to gap-forum, hopefully by the end of the day.

The edition with a built-in copy of GAP includes 4.9.1, with the following minor patches:
*  The patch from Chris Jefferson applied to allow GAP to open workspaces from paths with a space in them.  
*  The gap.sh shipped with 4.9.1 uses a hard-coded path for the gap root directory, and ignores the GAP_DIR environment variable.  I reverted to something closer to the old behavior for now.  (I will submit a patch for this on github, once I have a chance.)
*  The new gap build system hardcodes paths to libraries.  I made these relative, using the command "install_name_tool -change /Users/russw/Downloads/gap-4.9.1/extern/install/gmp/lib/libgmp.10.dylib "@executable_path/extern/install/gmp/lib/libgmp.10.dylib" gap", and similar for some package libraries.  (I will try to follow up with Max on fixing in the build system.)
More details on these patches are under the FAQ section of the Gap.app webpage.

This version of Gap.app has the following changes over the 0.5rc release candidate that I previously posted:
- Correctly handles Option-Left.  Keyboard selection handling should generally be a bit more robust.
- Typing while text is selected will generally return the insertion point to its last point on the command line.
- Updated default memory settings to match modern GAP defaults.
- GAP sheet windows are draggable, even by clicking in the toolbar area.
- Option-Clicking Gap.app menu will change "Open GAP in Terminal.app" to "Open GAP in iTerm.app"
- PrintFormattedString is patched at app startup to avoid breaking utf8 characters.  (Submitted upstream to GAPDoc.)
- Install Gap.app application bundle path into GAPInfo.
- Other polish and bug-fixing.

I think these changes address all most all of the concrete issues that Max pointed out in his previous email.  If I get significant bug reports, then I'll put out a 0.5.1 release.  (Bigger changes I'll save for 0.6. :-) )

SECOND:
On the issue of classical terminal versus non-classical terminal, it is my opinion that GAP should not limit itself to an 80x25 (or other fixed-dimension) grid of characters.  Html makes it easy to output arbitrary formatting to a command window, and is basically incompatible with the fixed-grid model (thus, incompatible with Browse).

I've made video showing off (mocking up) some of the things that could be done with the even the basic Html support that Gap.app offers.  See
https://www.youtube.com/watch?v=WVg69qX8WDY

I do know that Browse solves a lot of problems for some folks.  But I believe it is also incompatible with Jupyter, with which Gap.app has some commonalities.  Perhaps it will be possible to write code that is mostly-compatible to Browse to pop up a spreadsheet interface in Gap.app and/or Jupyter.

I'm happy to continue improving my hand-rolled terminal in other respects.  In particular, if there is interest in VT100 commands that don't require a fixed grid of characters, I'm happy to implement them.  (So far, it seems to me that mainly the color commands are used, outside of the Browse package.)

I'd also be happy to move Gap.app to use a better HTML widget, should the HTML approach take off.  The NSTextView that Gap.app now uses handles only a limited subset of HTML.

Best,

  --Russ

> On 10 Apr 2018, at 23:25, Max Horn <Max.Horn at math.uni-giessen.de> wrote:
> 
> Dear Russ, dear all,
> 
> to avoid misunderstandings: this has nothing to do with the GAP.app I provide at
>  <https://github.com/fingolfin/gap-osx-bundle>
> and which some of you know and use. Russ' provides a custom Mac GUI for GAP, while mine just is a portable GAP binary which runs in the terminal; the main reason mine is shipped as a "GAP.app" (which, when double clicked, opens a regular terminal) is a technical one (it allows me to make the code runnable from anywhere in the file system); this allows users to install via drag&drop.
> 
>> 
>> 2.
>> I'd like to in the near-to-mid term change the instructions for OS X on the gap-system.org download page from "First, download Xcode ........" to "Download this disk image, and drag Gap.app to your Applications folder".  (With GAP embedded.)  That should _significantly_ lower the barrier to entry for GAP among Mac users.
> 
> I have mixed feelings about this. First off, let me say that I think it's great you are working on this, I appreciate your efforts, and I am sorry if the following sounds too negative -- that's not how I mean it.
> 
> But, while I'd be happy to list your Gap.app as an alternativ means of installing GAP, I have great reservations about advertising it as *the* official GAP version for GAP.
> 
> While I certainly do want to give my fellow Mac users a lower entry barrier (hence my work on another GAP.app), I feel that this should still be centred around a classical terminal. In my experience, most "hand rolled" terminal replacements are inferior to a regular terminal. No offense, but I feel that this holds for the one in your Gap.app, too, so I am not sure I'd want to recommend it to e.g. my students).  At the same time, it seems less flexible than the Jupyter based front end for GAP in the works by Markus Pfeiffer et al within OpenDreamKit
> 
> (Which is why I created the app bundle above, but then didn't have the time and motivation to polish it, and setup automation to keep track with GAP updates)
> 
> Note: since you GAP.app is not signed, most normal users will have hard time running it, esp. on 10.13, unless they know the trick to "right-click and select open, then you can bypass the security checks".
> 
> Anyway, some initial feedback:
> 
> * so it asked me for the location of my GAP. I looked in that dialog, and saw that the default workspace size  is 24 MB, with a max of 256 MB. That's ridiculously small for these days. I'd use the same defaults as GAP does right now (which I don't know by heart; might be better to add checkboxes to those edit fields, labeled "Use default value", which then disable the input fields)
> 
> * What does "background saving and compressing of Gap.app sessions" mean? The background of what?
> 
> * resizing the terminal window leads to `SizeScreen([113,31]);;` etc. messages popping up
> 
> * if I select some text to copy it, afterwards I cannot type anymore, until I manually click into the edit line anymore
> 
> * something weird is going on with fonts and font sizes; it seems the inputs and outputs use a different font, which makes for a very jarring reading experience, IMHO
> 
> * the combo box for tab completion is a nice touch (SageMath has something similar implemented via ncurss in the terminal, too)
> 
> * the input history works differently from that in GAP (it's strictly linear, while in GAP, if I enter `Re` and then press up, it goes to last prior line starting with "Re". I'd not miss this if there was a way to search for previous entries by some other means, but I couldn't find one. Is there one?
> 
> * Other hotkeys don't seem to work either, e.g. esc-esc for filename completion. Is there a documentation for what's supported and what not? Seems this is just a regular macOS input field, so probably the usual subset of emacs commands, like ctrl-a, ctrl-k; and macOS standards, like alt+left-arrow for moving one word to the left; but curiously, ctrl-e is not supported?
> 
> * by using alt+left-arrow I can jump to the left of the "gap>" prompt
> 
> * when an input spans multiple line, the prompt vanishes. E.g. enter just the single digit 1, then press return; a line continuation prompt ">" is shown, but the original "gap>", which should be visible before the 1 is replaced by space
> 
> * pasting the text
>    gap> 1+2;
> in a regular GAP in a terminal is the same as pasting 1+2;  -- i.e. the gap> prompt is gobbled up. THis half works in Gap.app: pasting the text shows a double prompt, but pressing return afterwards works
> 
> * in the dihedral group example, which visualizes a poset (nice!), the window's titlebar is not clickabl everywhere -- I can only drag the window in the top half, but not in the bottom half (i.e. to the right of buttons)
> 
> * there is no ncurses support, so the Browse package with all its functionality is not supported :-(
> 
> * many Mac users use iTerm2 instead of Terminal.app, so you perhaps add a menu item to launch GAP in there, too? Or make the preferred terminal a preference (there are a few more out there, but I'd guess Terminal.app + iTerm2 cover 99% of all users).
> 
> 
>> 
>> I've automated so that anyone with Xcode can easily build a professional-looking disk image with an edition of Gap.app that includes an embedded copy of GAP.  Updating for new GAP releases should be easy.
> 
> Yeah, did that, too ;-).
> 
> 
> Cheers,
> Max
> -- 
> Prof. Dr. Max Horn
> AG Algebra
> Mathematisches Institut
> Justus-Liebig-Universität Gießen
> Arndtstraße 2
> D-35392 Gießen
> Tel: (+49) 641 99-32044
> Fax: (+49) 641 99-32049
> E-Mail: max.horn at math.uni-giessen.de
> 




More information about the Gap mailing list