P/Invoke tries to make your life easier by automatically converting (“marshalling”) data types from managed code to native code and the other way around.
In my last job interview I got a (rather vague) question about traversing a tree and operating on the tree nodes. I think I’ve a lot of experience in programming but I couldn’t figure out the answer on my own. The answer the guy wanted to hear was: visitor pattern.
I had never heard of it before. So, in preparation for my next job interview, I thought I take a look at it.
While trying to figure it out, I stumbled over this quote:
The Visitor pattern is possibly the most complicated design pattern you will face. (Source)
I totally agree. (And this is probably why I’ve never heard or used it before.)
But since I’m not a quitter I went on and tamed it. So, in this article I’m going to shed some light on this mysterious design pattern.
Sometimes a C/C++ function needs to store data you pass to it for later reference. If such data is a managed object (like a
class) you need to make sure that the garbage collector doesn’t delete it while it’s still used/stored in the native code.
That’s what pinning is for. It prevents the garbage collector from deleting and moving the object.
Just a quick cheat sheet about how variables in Bash get inherited.
Here’s the result of a call to
outer.sh (see below):
Call ------- From Outer (export): yes From Outer (no export): From Inner (export): From Inner (no export): Source ------- From Outer (export): yes From Outer (no export): yes From Inner (export): yes From Inner (no export): yes
The test consists of two files:
outer.sh is called by the user and internally calls
inner.sh – once directly and once with
#!/bin/bash export FROM_OUTER_EXPORT="yes" FROM_OUTER_NO_EXPORT="yes" echo "Call" echo "-------" ./inner.sh echo "From Inner (export): $FROM_INNER_EXPORT" echo "From Inner (no export): $FROM_INNER_NO_EXPORT" echo echo "Source" echo "-------" source ./inner.sh echo "From Inner (export): $FROM_INNER_EXPORT" echo "From Inner (no export): $FROM_INNER_NO_EXPORT"
#!/bin/bash echo "From Outer (export): $FROM_OUTER_EXPORT" echo "From Outer (no export): $FROM_OUTER_NO_EXPORT" export FROM_INNER_EXPORT="yes" FROM_INNER_NO_EXPORT="yes"
I had it happened a couple of times now that Mercurial on Windows would give me this error:
skipping unreadable pattern file ‘D:\Documents\Programming\YourProject\’: No such file or directory
This message is strange because the path actually exits.
After some searching I found the solution in the Mercurial bug tracker:
The title already suggests the solution. There’s an empty
ignore= entry in the global
Removing this entry solves the problem.
The file is located here:
Note: It seems this “problem” is caused by SourceTree.