When you load a xml file into DOMDocument in php, you can encounter some weired #text node during the iteration. I searched around, and found this solution, just put a line of code like below:
$dom = new DOMDocument;
$dom->preserveWhiteSpace = FALSE;
And then you are done!
And last not least this is where I found the answer, it gives a thoroughly explanation:
When you are download html with urllib or something alike, if you have this message:
File “C:\Python33\lib\encodings\cp437.py”, line 19, in encode return codecs.charmap_encode(input,self.errors,encoding_map)
UnicodeEncodeError: ‘charmap’ codec can’t encode character
Chances are you are print() out some unsupported char most likely in utf-8 in the sys.stdout, but your sys.stdout console is default to cp437.
A fix is put a line like this before the print code as here:
sys.stdout = io.TextIOWrapper(sys.stdout.buffer,'cp437','backslashreplace')
besides you can also use utf-8 as the encoder:
sys.stdout = io.TextIOWrapper(sys.stdout.buffer,'utf-8')
I googled around, doesn’t find a perfect solution. But I do come across 2 files on apple website, they actually implement the missing functions while dealing with the code ported to mingw.
For my scenario, I simply created a compiler based branch:
int mkstemp(char *template)
char *filename = mktemp(template);
if (filename == NULL)
return open(filename, O_RDWR | O_CREAT, 0600);
I also downloaded and attached here in case could be useful later: mingw.zip
swscale requires aligned memory for fast execution. But the one from c++ operator is not so. Then I looked up a new function for quick fix: _aligned_malloc.
pData = (uint8_t *)_aligned_malloc(size, 16);
Maybe this is not the best way, but good it works, haha.
You can get the high precision time with Datetime::Now, instead of with complicated: QueryPerformanceCounter
The test code is:
for (int i=0; i< 20; i++)
And this is the output:
It is precise to the 100 nanosecond as you can see from the above image.
Quick code here for you to copy and paste in your work, so save you from some typing:
public static Rectangle ConvertToRectange(RectangleF rectanglef)
return new Rectangle(
First of all, I just want to describe the problem here, I don’t have an answer.
Svn is a great tool to keep the version of changes, despite of all the greatness, there is an inconvenient issue when you committed to put it into heavy daily use. It doesn’t do well in this specific scenario:
If you want to rename a file, move it to a different folder or delete a file, you can easily do it in your ide or file explorer, just 1 or 2 clicks of mouse away. But then the svn lost the track of these file name based changes.
On the other hand, even when you feel the need to do these file name based changes, you operate on the svn directly, then you will make the project specific solution file outdated, in the case of C#, it is csproj.
In both cases, you have to redo the work manually on the other one to get updated.
Hopefully, there could be a solution here.
Maybe, a way to go is to let tortoiseSVN monitor the changes relate to the file name, then it adds the commands of changes to the pending commit list, the same way as it deals with the content changes inside a file.
here is the command line without nasm:
d:\source\lame-3.99.5>nmake libmp3lame.dll -f makefile.MSVC CPU=P3 asm=no
If you have the nasm installed: (good to have the asm optimization)
d:\source\lame-3.99.5>nmake libmp3lame.dll -f makefile.MSVC CPU=P3
and nasmw is now nasm in case you are looking for it but failed. Simply rename it if it is really needed.
windows bitmap file format doesn’t come with line stride with it, but it requires a padding to make each scan line end at 4 boundary.
Here is the doc detailed the issue:
Uncompressed data is a series of values representing either color palette indices or actual RGB color values. Pixels are packed into bytes and arranged as scan lines. Each scan line must end on a 4-byte boundary, so one, two, or three bytes of padding may follow each scan line.