Python: Multi-dimensional dynamic arrays

Another very poorly documented topic is how to create dynamic arrays of type array. Every second website will show you how to create static 2D arrays, which is pretty much useless for 90% of the practical applications out there.

I 'solved' it to a degree by creating a list of array items, but this is still not ideal. I would like to use a pure multi-deminsional array of type array.

Here's how I did it:

multi_arr = []

for i in range(some_range):
   arr = array('f') # array of type float
  
   # ... populate arr ...

   multi_arr.append(arr)

Julian Day in Python

I found very little documentation on obtaining the Juilian day with the time module in Python. So this is how it's done:

import time

print time.strftime("%j")

As easy as that!

Linux: shutdown: you must be root to do that!

In order to use the console commands shutdown, poweroff, halt or reboot, one has to be a super user. One might see messages such as:

shutdown: you must be root to do that!
poweroff: must be superuser.
reboot: must be superuser.
halt: must be superuser.

In some cases the user can simply be added to the wheel group. This should give the user enough privileges to shut the machine down. A more reliable approach is to make use of Sudo, which was specifically designed to allow ordinary users to execute certain super-user-only commands.

The following section will explain how to setup sudo to allow other users to the machine down through the command line under the Gentoo distro.

Install Sudo
Login as su:

su -

Emerge Sudo:

emerge app-admin/sudo

Configure Sudo
Run visudo:

visudo

Enter the following:

# Runas alias specification
YourUserName  ALL=(root) NOPASSWD: /sbin/reboot
YourUserName  ALL=(root) NOPASSWD: /sbin/halt
YourUserName  ALL=(root) NOPASSWD: /sbin/poweroff
YourUserName  ALL=(root) NOPASSWD: /sbin/shutdown

Replace YourUserName with the user name which requires shutdown privileges.

See this guide on how to create a group which allows all its users to shut the machine down.

Named pipes issue: WaitForConnection hangs around indefinitely

I recently created an IPC client and server based on the newish NamedPipeServerStream and NamedPipeClientStream classes in .NET 3.x.

It worked great, but when trying to stop the server, the main thread would hang aound waiting for the WaitForConnection() statement to return. I tried to kill the thread in a number of ways, but to no avail.

In the end, I created an easy workaround by doing a "dummy" client connection to the server. This will cause WaitForConnection() method to continue and the thread can then be stopped gracefully.

Named pipes issue: System.UnauthorizedAccessException: Access to the path is denied.

After yesterday's triumphant discovery I had a nightmare of a day trying to figure out why my client couldn't connect to the server. Time and time again, the following exception was raised:

System.UnauthorizedAccessException: Access to the path is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.Pipes.NamedPipeClientStream.Connect(Int32 timeout)
at System.IO.Pipes.NamedPipeClientStream.Connect()

And in the debug output window:

A first chance exception of type 'System.UnauthorizedAccessException' occurred in System.Core.dll

My best googling skills couldn't find an answer for this one and I ended up trying to change the permission for the NamedPipeServerStream and venturing down the wrong path by changing the PipeAuditRule and PipeAccessRule settings.

In the end turned out my PipeDirection had to be set to InOut, even though I was only streaming information from the Server, and not receiving information.

Here's the winning line of code:

NamedPipeServerStream Pipe = new NamedPipeServerStream(PipeName, PipeDirection.InOut, 1,
   PipeTransmissionMode.Message, PipeOptions.None);

.NET IPC through Named Pipe Servers

I've been struggling to get my own IPC server and client going. The work was based on this great post on The Code Project. Even though the article was very useful, I found the code to be a bit clunky.

I restructured a lot of it into very neat client / server structure. During debugging, I stumbled onto this "new" addition in the .Net 3.5 Framework. Named pipes are neatly integrated, so no need for my client and server anymore. Doh!

Oh well, I only lost a day's worth of coding, and at least I can rest assured that this part of my project will be quite stable.

Windows Service uninstall failed

Whilst developing a Windows Service, an exception occurred. I opted not to debug and when I exited the VS instance the service naturally terminated.

When I got back into the Services MMC, my service was marked as Disabled. When trying to uninstall the service through InstallUtil myservice.exe /u, the following exception was raised:

An exception occurred during the Install phase.
System.ComponentModel.Win32Exception: The specified service has been marked for deletion

This problem is easy enough to solve. Just quit the MMC and uninstall the service again.

Visual Studio editor annoyances

I have the nasty habit of copying code and then accidentally hitting Crtl+C again without selecting any text. VS clears your current clipboard item and replaces it with the line you're on.

I find this quite annoying, but luckily there's a way to get the previous items in the clipboard back. Just keep hitting Ctrl+Shitf+V to cycle through all the previous items.

UI updates and threading

I've been working on a small Windows Forms app which has a thread running in the background. This read needs to send info back to the UI during certain intervals. It's a pretty easy problem to solve and there are numerous sources on the web explaining this.

I did come across weird behaviour when my app went into a deadlock. It hanged at the Invoke method in the following code:

// This updates some control safely
protected void UpdateSomeControl()
{
    // Check if an Invoke is required
    if (InvokeRequired)
    {
        // Update the UI through delegation
        Invoke((ThreadStart)delegate()
            {
                // ... Update the UI ...
            });
    }
    else
    {
        // ... Update the UI ...
    }
}

This is upposed to work! So what happened?

Turns out there are two types of calls to modify a control in .Net. The first is a SendMessage and the other PostMessage. Invoke uses SendMessage, which causes the update message to be sent, but hangs around until the message has been processed. BeginInvoke uses PostMessage which is basically a fire-and-and-forget approach; the message is added to the queue and the process goes of doing other work without waiting for it to processed.

So my Invoke was obviously hanging around waiting for the control update to be completed, while the control update was waiting for some other process further back in the queue... at least that's how I understand it.

To solve this issue, simply use BeginInvoke rather than Invoke. I'm sure this fix is not appropriate for all problems, but in my case it did the trick.

For a more detailed explenation, see this CodeProject page.