The content of this blog is my personal opinion only. Although I am an employee - currently of Nvidia, in the past of other companies such as Iagination Technologies, MIPS, Intellectual Ventures, Intel, AMD, Motorola, and Gould - I reveal this only so that the reader may account for any possible bias I may have towards my employer's products. The statements I make here in no way represent my employer's position, nor am I authorized to speak on behalf of my employer. In fact, this posting may not even represent my personal opinion, since occasionally I play devil's advocate.

See http://docs.google.com/View?id=dcxddbtr_23cg5thdfj for photo credits.

Thursday, October 11, 2012

emacs comes up with all characters boxes

This blog item not really a publication, just to record a stupid thing. This blog is the easiest place I know to record little workarounds, etc.  It's indexed.  Plus, no harm in others seeing.  And occasionally they tell me better ways to do things.

Recently have been plagued by emacs come up in VNC with all characters looking like boxes.

This requires xfs, the X Font Server, to be reset.

Error Messages in the VNC Logfiles

Last time I went looking for log messages:

_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root

Xvnc Free Edition 4.1.2
Copyright (C) 2002-2005 RealVNC Ltd.
See http://www.realvnc.com for information on VNC.
Underlying X server release 70101000, The X.Org Foundation

Tue Jan  3 10:29:51 2012
vncext:      VNC extension running!
vncext:      Listening for VNC connections on port 5904
vncext:      Listening for HTTP connections on port 5804
vncext:      created VNC server for screen 0
Could not init font path element unix/:7100, removing from list!
Warning: Cannot convert string "nil2" to type FontStruct

Tue Jan  3 10:30:13 2012
Connections: accepted:
SConnection: Client needs protocol version 3.8
SConnection: Client requests security type VncAuth(2)

Tue Jan  3 10:30:19 2012
VNCSConnST:  Server default pixel format depth 16 (16bpp) little-endian rgb565
VNCSConnST:  Client pixel format depth 8 (8bpp) rgb max 3,3,3 shift 4,2,0

Tue Jan  3 10:30:20 2012
VNCSConnST:  Client pixel format depth 16 (16bpp) little-endian rgb565

Related errors: missing lucida, courier, etc. fonts.

How to reset XFS

From IT (months ago)

for future reference, if it happens again, check your vnc log (should be something like ~/.vnc/mipscs587:1.log) for an error like:

Could not init font path element unix/:7100, removing from list!

if you see this, you need to run, as root:

/etc/init.d/xfs restart

then restart your vncserver session

Rewriting history makes you look good

One thing I dislike about rewriting history in version control systems: it makes you look smarter than you are.

Let's imagine that you are developing a feature F. So, starting from the trunk, you do it on a branch

    trunk -> F1 -> F2 -> ...

Then you realize there is a bug in the trunk is something you depend on.  You fix that, but still on your branch

    trunk -> F1 -> F2 -> bugfix_in_F

You want to put that bugfix onto the trunk as soon as possible, so you apply t to the trunk.  Now we really have a branch:

    trunk ---------------------------------> bugfix
          \                                                     /
           +->F1 -> F2 -> bugfix_in_F ->+

then eventually you merge the feature

    trunk ---------------------------------> bugfix -----> F
          \                                                  /                /
           +->F1 -> F2 -> bugfix_in_F ------> F3 -> F4

on the trunk the bugfix and the feature appear out of order - at least, out of historical order.  But at least you can see the way things were really done.

(Of course, Mercurial doesn't really support moving a bugfix like this from a branch to the trunk.  It's a partial merge.  Hint: don't use hg merge - that's a full merge - you'll get the feature F1 and F2 as well as the bugfix.   And if you undo that stuff before checking in the isolated bugfix, mercural will remember that, and make it hard to merge the feature later.
       If you are lucky, the partial merge is at file granularity. You can do 
hg update -r default; hg revert -r FeatureBranch file-that-was-bugfixed.cpp; test ...
      If less lucky, merge by hand, cherrypick, edit patch files.  ...
      Or just redo.

But apart from Mercurial's not supporting partial merges,
what I really dislike is stripping the branch away from the history,

trunk ---------------------------------> bugfix -----> F

Now, it looks like you were smarter than  you actually were: the bugfix happened out of the blue.

Worse...  working with a group like my present project that is not test-driven, you may not have a failing test for the bugfix.  Or, the failing test for the bugfix may only be integrated when you get the feature.

Sure, don't do that. I wish my project was test driven.  But ...

Must rewrite Michael Feathers' Legacy Code book.