Stuff I needed to know

Grandma's Apple Pie (as dictated by Mum)

2011-05-19T18:00:00.001+10:00

Short Crust Pastry

Blend 125g butter, 125g plain flour and 125g self raising flour in a kitchen whiz.

Add 2 tablespoons of caster sugar and blend.

Add 1 egg yolk and combine.

Add 2-3 tablespoons of ice water (until the pastry almost combines)

Press pastry into a ball, then separate into 2/3 and 1/3 disks flattened out.

Wrap in plastic and chill for 60 minutes.

Apple Filling

Peel, core and slice 5-6 large Granny Smith Apples. Add 1 lemon, cut into quarters. Add 1/4 cup water (up to 1/2 cup).

Bring to boil and cook till softened. Add 1/2 cup sugar and stir until dissolved. Leave till cold.

Put pastry in tin and add cold apple, being sure to remove lemon. Cover with pastry. Brush the top with egg white, then sprinkle with caster sugar.

Cook at 220C for 10-15 minutes.

Turn oven down to 180C and cook for 25-20 minutes (ie, make the total oven time about 35 minutes).

Samba NAS and error code -36

2011-02-27T19:15:00.007+11:00

I just bought a Seagate GoFlex Home NAS and was wanting to backup a bunch of files to it. I ran their installer, installed all their recommended tools, configured the server, and got a Folder on my desktop representing the "GoFlex Home Public" folder on the server.

The first thing I tried to backup was their installation software, and I got this:

The Finder can’t complete the operation because some data in “some folder” can’t be read or written.

(Error code -36)

It's taken me several hours and lots of unsuccessful internet trawling to finally work out what the workaround is, so I figure its worth a post here where Google can find it for the next guy.

The problem appears to be related to the use of extended attributes, which Snow Leopard loves to attach to files these days. I believe that there is some sort of problem writing files with the com.apple.quarantine attribute to Samba mounted disks. Whilst you can try to use xattr -d to remove those attributes from your files, its tedious and very error prone.

Similarly, I found that sometimes files got stuck on the drive - you couldn't remove them, if you tried (in the terminal) you'd get permission errors. Nothing, sudo included, would allow you to fix the permissions. Yet looking in a terminal window with /bin/ls, they looked fine.

Short answer: Don't use the GoFlex Home Agent to mount network folders.

This always uses the smb: protocol to access the server. Instead, use the "Connect to server..." command on the "Go" menu in the finder, and explicitly specify that you want to use the afp: protocol instead.

Once I switched to using afp:, all of the spurious errors went away. I was able to delete all the temporarily stuck files, and I could copy whatever I liked onto the drive, regardless of the extra attributes.

Strangely enough, when I then tried out the Memeo Backup that Seagate include in the package, it warned me that my backup volume is afp: and I should use smb: instead. Yeah right. However, it looks like one reason they recommend smb: is that the afp: volume didn't seem to auto-mount when I went back in - I had to mount it for them.

Update:

Alternately, you can just wait for Apple to release OSX 10.6.7 which "resolves an issue when transferring files to certain SMB servers". Clearly, this blog post blowing the whole issue wide open had them scared and they realised they had to fix it pronto, or face my scathing posts.

Update 2:

Hmmm, despite it "mostly" working, I keep getting errors from Time Machine saying it was unable to complete the backup - it looks to me like it fails if it has to mount the drive itself.

Moral: do not buy this drive if you want to use it for Time Machine backups.

Why are my zeroes behaving like ones?

2010-11-27T13:37:00.006+11:00

Guess the output of this program:

C:\>type x.c

#include

#define ZERO 0

#define P(x) printf("x=%d",x)

main()

{

P(ZERO);

}

C:\>.\x.exe

x=1

Duh, what?

Ok, I cheated, I didn't show you the stupid compiler option I managed to pass through the use of a slightly buggy makefile.

C:\>cl /D0 x.c

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.30729.01 for 80x86

x.c

Microsoft (R) Incremental Linker Version 9.00.30729.01

/out:x.exe

x.obj

For those who don't memorise command-lines, that /D0 essentially is instructing the compiler to "define a value for the symbol 0" and the default value for definitions is "1".

Yes, the Microsoft VC90 compiler actually allows you to redefine the value of INTEGER tokens in your source code. Same thing happens at VC100.

C:\>cl /D0 x.c

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86

x.c

Microsoft (R) Incremental Linker Version 10.00.30319.01

/out:x.exe

x.obj

C:\>.\x.exe

x=1

It could be argued that it only shows up if you have one preprocessor macro using the value of another preprocessor macro, and you have to use an unlikely command-line option, so its not that tragic. But seriously guys, Apple catches you doing that sort of stupid thing at command-line parsing time...

jeff$ cc -D0 x.c

<command-line>: error: macro names must be identifiers

... and those of that that grew up with ANSI-C use macros like this all the time.

#define NAME(l) l[0]

#define ADDR(l) l[1]

#define TYPE(l) l[2]

Having those 0, 1 and 2 become subject to the whim of the command-line is unthinkable.

This all came about because of a Python-generated command line. I thought I was creating

CL /DOPTION0 x.c

but a bug meant I created this instead:

CL /DO /DP /DT /DI /DO /DN /D0 x.c

So I'm a lot more careful now.

Someone did point out to me that "All computer programs are just 0s and 1s. Looks like this one was just 1s".

Computer geek humor.

.NET corrupts heap when marshalling LPSTR

2009-07-02T15:45:00.010+10:00

(Hi Lizzie)

I've just spent the best part of a week trying to track down why my bridge from C# to C++ was working on Windows XP but crashing sporadically on Windows 7, and the answer is that .NET marshalling is trickier than you think for strings.

Essentially, I had this:

[DllImport("mydll.dll",CharSet=Ansi,CallingConvention=Cdecl)]
[MarshalAs(UnmanagedType.LPStr)]
private static extern String LookupCorrespondingString(Int32 key);

and in the DLL, I had

__declspec(dllexport) const char *LookupCorrespondingString(int key);

Whenever I called this, it would get all the way into my DLL, I could tell it was going to return a value, but during the return operation, it would crash. When I ran it in the debugger, I got output messages about how memory was being free'd into the wrong heap.

Eventually I found this article:
https://blogs.msdn.com/dsvc/archive/2009/06/22/troubleshooting-pinvoke-related-issues.aspx
which contained the useful quote (emphasis mine):

When a string buffer allocated by native code is marshaled to managed code, CLR Interop marshaller will allocate a managed string object and copy the contents of native buffer to the managed string object. Now in order to prevent a potential memory leak, CLR Interop Marshaller will try to free allocated native memory. It does so by calling CoTaskMemFree. The decision to call CoTaskMemFree is by-design. This can at times lead to crash, if memory was allocated by the called-native function using any API other than CoTaskMemAlloc family of API’s as custom allocators may allocate on different heaps.

And there was the answer. .NET was freeing the block of memory I had passed to it to help me "prevent a potential leak". The problem being the lack of ability to communicate the 'const-ness' of the underlying DLL entry point's return value in the MarshalAs() attribute.

The solution was to declare the entry point differently:

[DllImport("mydll.dll",CharSet=Ansi,CallingConvention=Cdecl)]
private static extern IntPtr LookupCorrespondingString(Int32 key);

and then when I call it, do the marshalling explicitly.

String s = Marshal.PtrToStringAnsi( LookupCorrespondingString(k) );

After I bitched and moaned about how this stuff isn't documented anywhere, Manish Jawa kindly pointed out that it is, in fact, documented in the very first sentence on this page: http://msdn.microsoft.com/en-us/library/f1cf4kkz.aspx - you can't ask for more than that.

Actually, you can and they give it to you here: http://msdn.microsoft.com/en-us/library/x3txb6xc.aspx - the problem I was experiencing and its solution spelled out.

So, the moral of the story is: if you pass native strings to .NET via the marshalling interface, make sure you use IntPtr and PtrToStringAnsi() unless you want them to be free'd for you.

Embedding .NET in an otherwise native application

2009-05-13T10:57:00.007+10:00

For reasons best known to the company I work for we embed the .NET CLR inside our otherwise native C++ MFC-based application, and for the last two weeks I've been trying to nail down why pretty much everything seems to work, except the windows where we embed the WebBrowser control via COM. No matter what I tried, IOleObject::SetClientSite() would fail and the web browser would display as an empty white rectangle on the desktop instead of in our window.

This guy seemed to have a very similiar symptom, but no answer; however, it was a fair guess he had the same problem and it was something to do with threading.

One of the guys at AutoDESK Developer Support (thanks again) pointed out that the CLR initialises the main thread to use MTA (multi-thread-apartment) mode, whereas the WebBrowser control really only works with STA (single-thread-apartment) mode. So, the solution was to ensure that I called CoInitialize(NULL) in our main thread before the CLR had a chance to mess things up.

".PDB files cannot be linked due to incompatible versions"

2009-03-31T15:01:00.003+11:00

The message ".PDB files cannot be linked due to incompatible versions" can be displayed during builds, even if the .PDB file has just been created by the current compilation (ie, its just not possible that it was built by a different version of the compiler)

The problem is that the mspdbsrv.exe process (which Microsoft uses to create PDB files) does not always terminate after linking. If you have a mixed environment where you compile and link some modules with VC7.0 and then some with VC8.0, sometimes the 8.0 mspdbsrv.exe process hangs around and interferes with subsequent 7.0 compiles.

Solution: use the Task Manager to terminate it.

Building MFC applications with Visual Studio .NET 2008 Express

2009-03-31T14:34:00.010+11:00

For reasons best known to themselves, Microsoft really really don't want you to build traditional MFC-based applications with their new Developer Studio tools - if you want the free stuff, you gotta trade in those testicles and do things with .NET or .nothing. None of the MFC libraries come in the latest Express (read: free) versions of Developer Studio, nor do such useful tools as RC and MIDL.

However...

You can get RC and MIDL from the Platform SDK.

http://www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en

And you can get an old version of the MFC and ATL libraries from the Driver Development Kit.

http://www.microsoft.com/whdc/DevTools/ddk/default.mspx

though in true Microsoft style, those headers contain compile errors.

Line 1034 and 1036 of …\include\mfc42\afxwin1.inl will probably contain the following:
_AFXWIN_INLINE CMenu::operator==(const CMenu& menu) const
{ return ((HMENU) menu) == m_hMenu; }
_AFXWIN_INLINE CMenu::operator!=(const CMenu& menu) const
{ return ((HMENU) menu) != m_hMenu; }

which is incorrect – they generate error 4430. It should be:

_AFXWIN_INLINE BOOL CMenu::operator==(const CMenu& menu) const
{ return ((HMENU) menu) == m_hMenu; }
_AFXWIN_INLINE BOOL CMenu::operator!=(const CMenu& menu) const
{ return ((HMENU) menu) != m_hMenu; }

(And people blame Windows crashes on "bad drivers" - how hard can it be to write a driver when the DDK has such blatant errors - they literally cannot have tried to compile with these headers before shipping them)

Sadly, whats discussed here only works up to VC8.0 - at 9.0 the ATL changes are too drastic, as I found out the hard way. If you want to use MFC or ATL, you can't use Visual Studio 2008 Express.

PDF to JPEG conversion

2009-01-09T18:36:00.011+11:00

Various PDFs collected from around the net would be better off as individual image files. You'd think there'd be a standard tool to convert them but I couldn't find any at a price point I was interested in. Fortunate OSX Python has access to CoreGraphics which can do the heavy lifting.


#!/usr/bin/python
import sys,re,os,os.path
from CoreGraphics import *

def doit(pdfname):
  if not re.search(".pdf$",pdfname): return
  print pdfname
  dirname = re.sub(".pdf$","",pdfname)
  try:
     os.mkdir(dirname)
  except:
     print "Can't create directory '%s'"%(dirname)
  return
  pdf = CGPDFDocumentCreateWithProvider(CGDataProviderCreateWithFilename(pdfname))
  cs = CGColorSpaceCreateDeviceRGB()
  bg = CGFloatArray(5)       # create's an array of 5 0's which is good enough for me
  for i in range(1, pdf.getNumberOfPages() + 1):
     page = pdf.getPage(i)
     r = page.getBoxRect(kCGPDFMediaBox)
     h = r.getHeight()
     w = r.getWidth()
     del page

     #c = CGBitmapContextCreateWithColor(int(w), int(h), cs, (0,0,0,0))
     c = CGBitmapContextCreateWithColor(int(w), int(h), cs, bg))
     c.saveGState()
     c.setInterpolationQuality(kCGInterpolationHigh)
     c.drawPDFDocument(r,pdf,i)
     c.restoreGState()
     c.writeToFile(os.path.join(dirname, "page%04d.jpg"%i),kCGImageFormatJPEG)
     del c
  del cs
  del pdf

if __name__=='__main__':
  for a in sys.argv[1:]: doit(a)

The original version of this script was broken by Snow Leopard (which upgraded Python to 2.6.1). The call to CGBitmapContextCreateWithColor() failed with an error message about the 4th argument which it seems to think shouldn't be a 'const float[5]'.

The solution is to pass in a CGFloatArray() object instead. I haven't been able to modify one of those, but the default thats produced when you use 'bg = CGFloatArray(5)' appears to be good enough. Those objects still look leaky as hell but what are ya gonna do?

Squirrel:~ jeff$ python
Python 2.6.1 (r261:67515, Jul  7 2009, 23:51:51)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from CoreGraphics import CGFloatArray
>>> a = CGFloatArray(5)
>>> print repr(a)
<CoreGraphics.CGFloatArray; proxy of <Swig Object of type 'CGFloatArray *' at 0x2287a0> >
>>> print repr(a[0])
swig/python detected a memory leak of type 'CGFloat *', no destructor found.
<Swig Object of type 'CGFloat *' at 0x224d10>
>>>

Brave New World

2009-01-09T16:51:00.002+11:00

Everyone else seems to be getting on to this bandwagon, so why shouldn't I?

I doubt I'll have anything interesting to say to the world - I'm far more likely to use this to record notes to myself that may conceivably be useful to others. And unlike most bloggers, I'm going to go back and edit anything that needs fixing rather than posting new articles.