Stupid Programming Bugs

I will start trying to cllect stupid programming bugs that I have wasted my time on. Especially if I did not google the answer the first time. http://wiki.andy.glew.ca/wiki/Stupid_Programming_Bugs http://wiki.andy.glew.ca/wiki/Forgetting_to_flush_stdout_and_stderr_before_fork Now I'll expose how stupid a programmer I can be. By recording stupid timewasting bugs that I should have known better about. So that, I hope, I will be able to google them if I repeat the bug Ditto others.

Disambiguating names according to scopes in C++

Consider

int biff;
int var;
struct Var {
  int var;
  void foo(int var) {
      biff = var; 
  }
};

Which var is used in the assignment? Sure, a good C++ programmer knows the rules. But it can be hard to tell in a large program. You can disambiguate for the member

      biff = this->var; 

or the global

      biff = ::var; 

But so far as I know there is no syntax for arguments. I often use a naming convention

  void foo(int arg_var) {
      this->var = arg_var; 
  }

This is not unlike the widespread convention of saying

  void foo(int arg_var) {
      m_var = arg_var; 
  }

although I deprecate this because m_var for member names can lie - there may be a global of that name. Whereas this-> is not much bigger, and has the compiler check your meaning. Perhaps there should be sigils, like this-> and ::, for arguments and locals? -- Late addition, 5/25/2012: I dislike extra typing. Plus, occasionally I will do a refactoring where an arg or a global becomes a local or a member. Sometimes I want such refactorfings to show up in history diffs, sometimes not. Here's an interesting possibility: have the build or ODE system annotate the code with a hidden sigil (which I would suggest being XML, something like . Have the IDE warn if an edit would change the implicit sigil. Much as GCC warns if an inner scope hides an outer scope's name.

xpra

---+ rootless shareable and transportable X sessions.

For a long time I have been frustrated by VNC's putting all of the application windows in a big window for the X root.  It always seemed to me that you could have an X server that kept all of the windows separate - perhaps by having an infinitely resizable root - which then allows the windows to be forwarded to the user's display (I think of that as a client, but in X terms it is a display server), and treated independently there.

I'm not the only one. Googling finds many people looking for "screen for X". I guess I betray my age when I admit that my desire for this predates GNU screen and VNC.  I remember being happy when I encountered GNU screen's terminal multiplexer, since I had used similar tools elsewhere.  (By the way, while I am at it: I recently started trying to use GNU screen, after a long lapse.  One of my complaints is that GNU screen seems to be screen. I vaguely remember a terminal multiplexer that handled dumb terminals well enough, allowing you to connect separate terminal emulators, as well as other stuff.)

Anyway: screen for X...

I have looked at NX, xmove, etc., at various times, all with differing degrees of clunkiness. Nothing made mwe happy until...

---+ xpra

Hurrah for xpra! http://xpra.org/

xpra allows you to send applications from one display to another.  On an application by application basis. (Hmm, I wonder what happens to a multi-window application.)

I am happy that IT finally has a system on which they were willing to install xpra.

---+ Winswitch? not yet, maybe not ever

I am considering winswitch, http://winswitch.org/, which is layered on top of xpra or VNC or RDP or ssh -X or NX or ...

But I am not jumping at winswitch the way I am jumping at xpra, since (a) I don't want yet another insecure password system, and (b) it seems to depend on all sides running winswitch.

---+ xpra does NOT need to be installed on both sides

Typically xpra usage examples say
http://xpra.org/:

On the machine which will export the application (xterm in this example):


xpra start :100
DISPLAY=:100 xterm

For the simple case, we can then attach to this session from the same machine with:

xpra attach :100

If connecting from a remote machine, you would use something like:

xpra attach ssh:serverhostname:100

or
https://help.ubuntu.com/community/Xpra:

xpra start :7
• Start an xpra server using display number :7.
DISPLAY=:7 firefox
• Start firefox running inside the xpra server. No window will appear.
xpra list
• Show a list of xpra servers you have running on the current host.
xpra attach :7
• Attach to the xpra server that is using local display number :7. Any apps running on that server will appear on your screen.
xpra attach ssh:frodo:7
• Use ssh to attach to the xpra server that is running on machine frodo and using display :7. Any apps running on that server will appear on your local screen.
xpra start :7 && DISPLAY=:7 screen
• Start an xpra server and a screen(1) session. If any of the applications inside screen attempt to use X, they will be directed to the xpra server.
xpra stop :7
• Stop the xpra server on display number :7.

I.e. they assume that xpra is installed both on the server and on the client.

(Urg, confusing terminology. There are 3 important systems here: (1) the system where the xpra proxy server runs, (2) the system where the application software runs, and (3) the system where the display runs.)

This was a worry, since I often want to move applications to a system that may have X, but which may not have xpra on.  E.g. Cygwin/X on my Windows PC.  (I considered Winswitch for this, but it requires itself to be installed in too many places.)

I am happy to say that you do NOT need to have xpra installed on the display system.  E.g.

machine1:~$ xpra start :8
Entering daemon mode; any further errors will be reported to:
  /home/glew/.xpra/:8.log
machine1:~$
machine1:~$ DISPLAY=:8 xterm

[machine2 ~/.xpra]> ssh -X machine1 xpra attach :8

MS Outlook 2010 text selection bug - and "fix"

For quite some time now, I have been terribly frustrated using MS Outlook 2010.  It was not allowing me to select text in messages that I was reading, neither in a preview pane, now in a proper reading window.

I was only able to select text if I hit reply. In the reply email composition window I could select text.

This was frustrating.

Eventually I learned that if I hot ESCape (and possibly capslock toggle), them I could get to a mode where I could select text in a reading window.

The discussion at the following MS URL helped:

http://answers.microsoft.com/en-us/office/forum/office_2010-outlook/i-cannot-highlight-text-in-microsoft-outlook-2010/7c56d72d-b163-4941-b53f-209608481eef?page=2&tm=1336417806914#footer

Helped.  Did not describe the fix precisely, although it seems that others may have followed the same path.  One poster kept asking "Does your cursor look like a hand?", and then suggested hitting ESCape.

Well, my cursor did not look like a hand. But hitting ESCape fixed the problem anyway.

--

Sheesh, when I think of all the time I have wasted hitting reply to select and copy text...

PDX recycling

New house, new trash and recycling service.  Since I try to be green, but often have trouble find where to recycle, recorded here:

Several different relevant websites:

• City of Portland,  http://www.portlandonline.com
• Annoyingly, Portland's web pages use non-human-intelligible URLs, like ?c=41467. I hate this!
• Rates and service:  http://www.portlandonline.com/bps/index.cfm?c=41467
• Schedule:  http://www.portlandonline.com/bps/index.cfm?c=54938
• Seasonal:  http://www.portlandonline.com/bps/index.cfm?c=41471
• Xmas tree:  http://www.portlandonline.com/bps/index.cfm?c=41471&a=109113
• basically, can put whole tree out on curb 4$/6$>8 feet
• or cut into pieces, in green compost bin, or separate bundles for 3.75$
• Waste Management,  http://wmnorthwest.com/portland
• Lists of what can and cannot be taken are on web pages, although not all in one place
• Garbage: http://www.portlandonline.com/bps/index.cfm?c=55401
• Recycling: http://wmnorthwest.com/portland/recycling.html,  http://www.portlandonline.com/bps/index.cfm?c=44752
• no plastic lids, no plastic bags
• Compost: http://wmnorthwest.com/portland/yardwaste.html,  http://www.portlandonline.com/bps/index.cfm?c=47246
• most food waste, but not packaging
• most yard waste
• no plastic bags
• no pet waste
• Tough Stuff
• Plastic bags - NOT curbside.  Recycle depots, some grocery stores
• Styrofoam blocks - ??? -  Curbside trash (but often too big, e.g. for a big package) :-(
• Styrofoam packing peanuts - UPS. Not Fedex. Not recycling depots. Curbside trash.
• Electronic - NOT curbside. Some recycling depots
• Pet poop - trash
• Waste Management's "Think Green" program,  http://thinkgreenfromhome.com/
• for stuff that doesn't get picked up curbside
• call to ask for mail-back boxes for 
• batteries, 19.95$ / 4 lb
• lightbulbs (incandscent, CFL, and LED), 19.95$ / 13
• actually, web page implies only needed for CFL, mercury.
• medical waste (e.g. diabetes blood test kits, lancets, and/or needles and syringes), 45-55$
• curbside, by special arrangement, an option in Portland
• big fluorescent tubes, 69.95$ / circa 16 bulbs

Comments at beginning of line?

code; // we have comments at the end of a line
code /* and comments anywhere on a line, like in the middle */ code;
/* where "anywhere" can be at the beginning: */ code;

but it occurs to me that I often want comments at the beginning of a line, e.g.

foo(
     /* arg1= */ 111,
     /* arg2= */ 222,
)

and although /*...*/ can accomplish this, they are visually heavyweight.

I wonder if, in a hypothetical new language, we could have comments from the beginning of a line?

Now, ":" would be the most natural comment delimiter for this - if it were not already used for so much else:


foo(
     arg1:  111,
     arg2:  222,
)


Note that I have distinguished comments in a special color. One might say that such a special comment color is what we really want... I agree, and have discussed that elsewhere.  But it is certainly traditional to have program text read monocolor:


foo(
     arg1:  111,
     arg2:  222,
)


Now, you might also argue that keyword arguments subsume the example above.  Sure... but then I can create other examples that are not keyword arguments.

I can imagine comment from beginning of line delimiters other than colon, but none are quite so elegant:


foo(
     arg1>>>  111,
     arg2:>>> 222,
)



foo(
     arg1==>  111,
     arg2==> 222,
)



foo(
     arg1:::  111,
     arg2::: 222,
)


Again, we are limited by the ASCII, or UTF, character set.

Cultural Difference

Here's a cultural difference:

When I am doing test first programming (more formally known as test driven design), when I write code it has usually been tested.  To some degree.  With an automated test checked in.

But working with people who don't do test-first or TDD, they sometimes write gallumphing of code. And check it in.  No automated test. Possibly they may have manually tested it.  Or perhaps not.  Possibly they have no expectation that the code will work at all.

Now, what happens when I start using that code, expecting it to have been tested and to work?  If I'm lucky, it will break right away.  If unlucky, it will almost work... until a good while later I figure out that there are bugs in code that I thought was working.

Ideally, there was communication that "this code is not expected to work".  Verbally?  Comments in the code?

Automated tests are, in some ways, just a form of communication.  A form of communication that is in your face and hard to ignore.

Should you ever write code that isn't tested?  Sure, maybe: to sketch out an idea.  But it should be clearly documented as such.  Ideally automatically:  if code that you don't expect to work is executed, perhaps it should log or otherwise advertise that it is not expected to work.

I encountered a similar problem in another tool, that processed a class of input messages.  Now, in theory it should have been processing all of a class of input messages. It could tell the class of all inputs.  But for whatever reason only one particular example of that class of input messages was handled.  The rest were ignored. Silently.  No warnings.  Since I expected the tool to handle all of the class of input message, not just one particular type, it took me a while to onion peel.

Now, I did not fix the tool to handle all of the class of inpurt messages.  I just added one more instance.

But I could set it to warn:

if in class of input messages
      if example1 of this class ...
      else if example 2 of this class ...
      else
              warn:  I know I am supposed to do something for all of this class, but am not handling ...