Monthly Archives: December 2011

iTerm2: How to unsplit a pane back to a tab or window

Posted on by
7

This morning I accidentally dragged an iTerm2 tab and created a split pane in one of my tabs. I searched for quite a while to find out how to move it back to its own tab. Finally, I found it at http://groups.google.com/group/iterm2-discuss/browse_thread/thread/920ff96f710a0a93:

You can already do this by holding cmd-shift-opt and dragging the pane to a
tab bar or away from any terminal window to create a new window.

Vim screen corruption with screen/tmux and matchparen.vim

Posted on by
4

I’ve been experiencing an irritating bug for a few weeks and I finally eliminated it by disabling matchparen.vim

The bug happens when I’m using vim in an ssh session (to a Linux machine) with GNU Screen or tmux (on the server) in iTerm2.app or Terminal.app on Mac OS X and editing PHP code. If I type “require dirname(__FILE__) .“, then after typing the closing parenthesis, the screen gets corrupted such that it looks like I typed “require dirnam((__FILE_))” (missing “e”). Hitting Control-L refreshes the screen of course, but it’s irritating nonetheless.

Yesterday, I got the bug to disappear by putting this in my ~/.vimrc.local (I’m using Janus):

" vim's parenthesis highlighting causes screen corruption when vim is running
" inside GNU screen or tmux?
let loaded_matchparen = 1

I don’t know if this is a bug in matchparen.vim or something else.

If I type slowly, it looks like after typing the closing parenthesis, both the opening and closing parenthesis are highlighted correctly. Things go haywire after typing a space after the closing parenthesis. It looks like it’s attempting to replace the highlighted open parenthesis with a normal parenthesis but it does it one cursor position to the left, resulting in the “e” in dirname getting overwritten with a parenthesis and the highlighted open parenthesis is still present next to it.

Here’s a screenshot: http://cl.ly/1E1I2X0t3e1F3c3F2I2J

If I understood more clearly what the problem is, then I’d try to fix it and submit a patch, but I’m not very knowledgable about terminal issues. If someone points me in the right direction, I might be able to come up with a patch…

I’ll be posting this to the vim_dev mailing list as well.

Don’t be alarmed by super large VSIZE on OS X

Posted on by
3

(Also at https://github.com/urbancoding/jenx/issues/32)

Don’t freak out too much if 64-bit processes on OS X have a VSIZE of 10 GB or more.

    marca@SCML-MarcA:~$ cat macruby_test.rb 
    print "What's your name? "
    name = gets.chop
    puts "Hi, #{name}!"

    marca@SCML-MarcA:~$ psgrep macruby
    USER    PID  %CPU %MEM      VSZ    RSS   TT  STAT STARTED      TIME COMMAND
    marca 76551   0.0  0.3 10899176  12272 s004  S+    9:09PM   0:00.06 macruby macruby_test.rb

    marca@SCML-MarcA:~$ top -pid 76551 -l 1 | tail -2
    PID    COMMAND %CPU TIME     #TH #WQ #PORTS #MREGS RPRVT  RSHRD RSIZE VPRVT VSIZE PGRP  PPID  STATE    UID       FAULTS COW  MSGSENT MSGRECV SYSBSD SYSMACH CSW PAGEINS USER 
    76551  macruby 0.0  00:00.06 1   0   40+    131+   5640K+ 15M+  12M+  323M+ 10G+  76551 72846 sleeping 346486362 3266+  189+ 234+    115+    254+   157+    35+ 0       marca

What this shows is a ridiculously simple Ruby program (running under MacRuby) having a VSIZE of 10 GB.

OTOH, Activity Monitor shows up a much more sane “Virtual Mem” of 315.0 MB for this process:

http://cl.ly/3F3N0P2M0l2O3q0b280Y

Also, vmmap seems to indicate that most of the virtual memory comes from “reserved VM address space (unallocated)” and it seems to consider this as unimportant:

    marca@SCML-MarcA:~$ vmmap 76551
    Virtual Memory Map of process 76551 (macruby)
    Output report format:  2.2  -- 64-bit process
    
    ...
    
    ==== Summary for process 76551
    ReadOnly portion of Libraries: Total=68.5M resident=59.0M(86%) swapped_out_or_unallocated=9792K(14%)
    Writable regions: Total=8.1G written=5068K(0%) resident=5164K(0%) swapped_out=0K(0%) unallocated=8.1G(100%)
    
    REGION TYPE                      VIRTUAL
    ===========                      =======
    MALLOC                            286.3M        see MALLOC ZONE table below
    MALLOC (reserved)                   7.8G        reserved VM address space (unallocated)
    ...
    ===========                      =======
    TOTAL                               8.2G
    TOTAL, minus reserved VM space    463.3M

                                         VIRTUAL ALLOCATION      BYTES
    MALLOC ZONE                             SIZE      COUNT  ALLOCATED  % FULL
    ===========                          =======  =========  =========  ======
    auto_zone_0x100bbd000                 256.0M      10635       680K      0%
    DefaultMallocZone_0x100b5b000          29.2M      28569      3207K     10%
    DispatchContinuations_0x100bfe000      1024K          1         32      0%
    ===========                          =======  =========  =========  ======
    TOTAL                                 286.3M      39205      3887K      1%

This issue, by the way, is not specific to MacRuby (my initial suspicion). I saw a similar pattern with Xcode, which also has a VSIZE of around 11 GB. I did not see this pattern with MRI Ruby [ruby 1.9.3p0 (2011-10-30 revision 33570)], Mail.app, Finder, iTerm, Alfred, Safari, or mysqld — these apps all have a much lower VSIZE of around 3 or 4 GB each. I have no idea why.

OS X appears to “reserve” a large amount of virtual memory for 64-bit processes, but they are not necessarily using it just because it’s been reserved for them.