I am looking in writing a git merge assistant that handles a specific work-flow (more on that in a later post) and as such am looking a ncurses interface. There are a couple of C# wrappers but they are old projects and have not been touched in years, so to even get them to compiled in order to even test them, I had to do some minor tweaking.

The first one is from Mono and it called Mono-curses and I forked it on Github and tweaked it to produce a 64-bit dylib and a PE32+ assembly.

It appears to work ok, but there is a issue with timeouts; tryout the mltest.cs sample code and you will see the inconsistent timeout events….

It also is missing mouse support… not a deal breaker for me, but it would be a nice to-have.

There are some apps such as the out-dated MonoTorrent and a C# version of Midnight Commander.

http://www.mono-project.com/docs/tools+libraries/libraries/monocurses/

Mono-Curses OS-X 64-bit

Note: This is a fork of the mono/mono-curses project

Clone the repo and checkout the osx-64bit branch

git clone https://github.com/sushihangover/mono-curses.git
git check osx-64bit 

Set our path to your 64-bit version of Mono and set your Mono package config env var to that install, configure and make the project.

Example:

export PATH=$HOME/mono-install/bin
export PKG_CONFIG_PATH=/$HOME/mono-install/lib/pkgconfig
#WARNING: by default it installs into /usr/local
./configure --prefix=/$HOME/mono-install
make 
make install

That should do it, lets do a quick arch check:

file libmono-curses.dylib 
libmono-curses.dylib: Mach-O 64-bit dynamically linked shared library x86_64

file mono-curses.dll
mono-curses.dll: PE32+ executable for MS Windows (DLL) (console) Mono/.Net assembly

FYI: The difference in a PE 32-bit and 64-bit is show below:

file mono-curses.dll
mono-curses.dll: **PE32+** executable for MS Windows (DLL) (console) Mono/.Net assembly

file mono-curses-32.dll 
mono-curses-32.dll: **PE32 **executable for MS Windows (DLL) (console) **Intel 80386 32-bit **Mono/.Net assembly

There are a couple of tests that are built during the make you can run:

(make test) mono test.exe (Unicode sample, any key to exit)
(make gtest) mono gtest.exe (Ctrl-C to exit app)
(make mltest) mono mltest.exe (Timer events do not work as expected(?), Ctrl-C to exit app)

Using Mono/.Net libraries that have native binding and you are receiving errors like “Unable to find the xxxx native library” or “DllImport error loading library”.

You can easily find where mono is looking for that native library by setting the MONO_LOG_LEVEL to debug and MONO_LOG_MASK filtering to only DLL related messages.

export MONO_LOG_LEVEL=debug
export MONO_LOG_MASK=dll
mono yourprogram.exe

I was recently using the mono-curses wrapper, or at least trying to ;-) and I knew my DYLD_LIBRARY_PATH was set properly to pick up the “libmono-curses.dylib” that I just built. But the program failed to run so I set the MONO_LOG_LEVEL and MONO_LOG_MASK env vars and re-ran the program. Yes it was finding the dylib OK but it was complaining about it being the wrong architecture…

Mono: DllImport attempting to load: 'libmono-curses.dylib'.
Mono: DllImport error loading library '/Users/administrator/Documents/Code/github/mono-curses/libmono-curses.dylib': 'dlopen(/Users/administrator/Documents/Code/github/mono-curses/libmono-curses.dylib, 9): no suitable image found.
Did find:  /Users/administrator/Documents/Code/github/mono-curses/libmono-curses.dylib: mach-o, but wrong architecture        

Checking with file and yes, it was a 32-bit version of the library:

file libmono-curses.dylib
libmono-curses.dylib: Mach-O dynamically linked shared library i386

I am compiling using a 64-bit version of Mono on OS-X and need 64-bit libraries (and native libs), so a quick fix in the mono-curses Makefile and re-compile and I have a 64-bit version (I’ll fork and fix the mono-curses project and post it to my GitHub).

file libmono-curses.dylib 
libmono-curses.dylib: Mach-O 64-bit dynamically linked shared library x86_64

After that, testing the C# ncurses wrapper went fine… ;-)

Mac OS X Framework and .dylib Search Path

The Framework and library search path is:

• A colon-separated list of directories in the user’s DYLD_FRAMEWORK_PATH environment variable.
• A colon-separated list of directories in the user’s DYLD_LIBRARY_PATH environment variable.

• A colon-separated list of directories in the user’s DYLD_FALLBACK_FRAMEWORK_PATH environment variable, which defaults to the directories:

    ~/Library/Frameworks
    /Library/Frameworks
    /Network/Library/Frameworks
    /System/Library/Frameworks
  

• A colon-separated list of directories in the user’s DYLD_FALLBACK_LIBRARY_PATH environment variable, which defaults to the directories:

    ~/lib
    /usr/local/lib
    /lib
    /usr/lib
  

Note: Mono will automatically append the appropriate suffix depending on the platform (.dylib on Mac, .so on Linux and .dll on Windows).

I use Octopress for this GitHub blog and can tend to forget to push the source to Github as it is not part of the ‘rake deploy’.

‘rake deploy’ only updates the master branch on Github on order to publish the website and instead of hack'ing the deploy function to handle pushing the ‘'source’ branch also (waiting on the Octopress 3.0 release for that), I wrote a script to handle it all.

This lazy script that does all the steps that I would have to do manually but tend to never do. And it is in my root Octopress directory so it included in my source revisions ;-)

Nothing special: just generates, deploys, adds all on the source branch along with a commit and push. For good measure it then garbage collects the repo to keep everything clean.

#!/usr/bin/env bash
echo "Generate and deploying website"
rake generate
rake deploy
echo "Commiting and pushing source files"
git add --all; 
git commit -m "New posts"; 
git push 
git gc
pushd _deploy
git gc
popd

I’m a big fan of Homebrew on OS-X and it normally it works so well that you just do not think about it. That is a very good thing, it just works, does not get in your way and anything is good.

While I was updating/upgrading packages today, I ended up running ‘brew info’:

brew info 
146 kegs, 171208 files, 8.0G

I was surprised that I had 8 GBs of hard drive space consumed by brew packages. If you did not know it, brew does not auto-purge older packages.

From FAQ:
By default, Homebrew does not uninstall old versions of a formula, so over time you will accumulate old versions.

https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/FAQ.md

It had been a long time since I did a cleanup in brew and I had well over a hundred older versions of various packages that I was not using (i.e. one that were not pinned; brew pin {FORMULA), so I ran the cleanup and freed up 7.3 GB of drive space.

brew info 
146 kegs, 63167 files, 2.7G

Clean up everything at once:

brew cleanup

Clean up just one formula:

brew cleanup {FORMULA}

Do a dry run to see what would be cleaned up:

brew cleanup -n

I posted up the PlayScript compiler 3.2.6001 to GitHub which is a merge of the remote-tracking branch ‘upstream/mono-3.2.6-branch’ into playscript-mono

FYI: I have been using tags on the playscript-mono branch to mark each of these PlayScript merges. It is a clean and lightweight way to capture and identity these version on the timeline:

git tag --list | grep playscript
playscript-3.2.2002
playscript-3.2.3001
playscript-3.2.3003
playscript-3.2.4001
playscript-3.2.5001
playscript-3.2.6001

Everyone screws up, and that comes to finger flops when typing that new tag name.

If the tag is only local, it is two step process, create a new tag from the old tag and delete the old tag:

git tag new_tag_name old_tag_name
git tag -d old_tag_name

But if you have pushed that bad tag name to a remote, then you have another two steps. Deleting that remote tag makes use of the refspec reference and only using a destination with an ‘'empty’ source. Assuming your remote is named origin (git remote -v), than this what you need to do (REMEMBER TO INCLUDE THAT COLON):

git push origin :refs/tags/old_tag_name

And push the new tag to your remote so everyone else will receive that new tag on a pull:

git push origin --tags

Note: The colon isn’t a “delete flag”. Git push and git pull both accept zero or more refspecs as their final argument(s). Now read about refspecs, really read it… . A colon separates source from destination in a refspec. The command git push origin :foo has an empty source and essentially says “push nothing to branch foo of origin”, or, in other words, “make branch foo on origin not exist”.

Sub-Note: This is NOT the same as pushing an empty branch or tag, you really are pushing ‘nothing’ and thus with nothing to reference that tag vanishes (Well I’m assuming it exists somewhere till garbage collection is run)

Sub-Sub-Note: ;-) Yes, I agree with a lot of others that instead of using an empty source in the ref spec it would be waaaayyyyy more initiative to allow a remote parameter to be passed to the existing branch and tag delete options to do this type of deletion.

Getting a list of changed files between to different branches or tags could not be any easier when using the ‘–name-only’ diff option:

git diff --name-only mono-3.2.5 mono-3.2.6

configure.in
mcs/class/Facades/Makefile
mcs/class/Facades/System.Dynamic.Runtime/TypeForwarders.cs
mcs/class/Facades/System.Runtime.InteropServices.WindowsRuntime/AssemblyInfo.cs
mcs/class/Facades/System.Runtime.InteropServices.WindowsRuntime/Makefile
...

A quickie to get the number of files changed:

git diff --name-only mono-3.2.5 mono-3.2.6|wc -l
      28

And using the ‘–name-status’ option can get you a nice two column output with the change type attribute with each file name, makes it easy to pipe to those maintenace scripts.

git diff --name-status mono-3.2.5 mono-3.2.6
M       configure.in
M       mcs/class/Facades/Makefile
M       mcs/class/Facades/System.Dynamic.Runtime/TypeForwarders.cs
A       mcs/class/Facades/System.Runtime.InteropServices.WindowsRuntime/AssemblyInfo.cs

Note: You can feed the ‘–no-color’ option to make sure that none of those ansi escape codes get send down-stream in your pipe.

Note: ‘–'porcelain’ works within the diff mode sub-option but not as a primary option.

I posted up the PlayScript compiler 3.2.5001 to GitHub which is a merge of the remote-tracking branch ‘upstream/mono-3.2.5-branch’ into playscript-mono

Been knocking these simple minors versions out, dreading the upcoming Mono 4.x changes…

Setting up a GitHub organization for PlayScript, I’ll let you know when it is up.

I posted up the PlayScript compiler 3.2.4001 to GitHub which is a merge of the remote-tracking branch ‘upstream/mono-3.2.4-branch’ into playscript-mono

Have fun…

I posted up the PlayScript compiler 3.2.3003 to Github which fixes a bunch of build issues, including a clang/ld failure if you are running the latest and greatest version from Apple.

Root repo : playscript-small-build.sh

./autogen.sh --with-mcs-docs=no --with-profile2=no --with-profile4=no --with-profile4_5=yes --with-moonlight=no --with-tls=posix --enable-nls=no --prefix=$HOME/playscript-install
make
make install