Mathieu Gueydan

I'm just sharing here my happiness, as I received today the centurion award in Project Euler. Of course, it's not as shiny as the one related here, but I'm proud anyway.


If you're wanting to train your algorithm programming abilities, Project Euler is a good place to go. If you're new to this, let me advise you some basic tips :

1. Don't try to rush high level problems

Problems often are related to previous problems. Skipping some of them may force you to spend time trying to solve problems you don't have tools for.

2. Think about complexity first

Most of the problems ask you to iterate on things. Generally, they are several elements you may choose to iterate on. You may always want to choose the lesser complexity for your algorithm, which means, the fewer and the fastest iterations.

As you design your algorithm (in you head or on paper), you may want to shortly evaluate the number of iterations you will need to full-fill the calculation. If it's to high, you're solution is wrong.

3. Think "out of the box"

If you think you are tackling the problem from the right angle but it doesn't work, it's probably that you don't have the right angle. Most of the time, there is another way to watch the problem you didn't figured out at the moment.
Don't spend time in small optimisation and lesser algorithms improvement (I know, this is fun to do). Generally, if you're wrong, it's not about 10% it's about a factor 1000.

One slight note of caution : be aware that a few number of the first 100 problems may need you to use specific mathematical theories (often linked to Euler's work). For those ones, you may search long hours without any chance to find a solution (as it would ask you to re-invent the mathematical theory, which is not what you are trying to do). So if you are stuck on a problem for a very long time, you may want to search for associate mathematical theory. Which is not very easy without cheating.

4. Keep your programs (and keep them clean)

As each problem ask you a single answer and nobody will comes after you to read your application, you may want to write disposable code in order to spare time. Here's why I see it as a bad idea.

You will spend more time troubleshooting : involved concepts are pretty hard to understand, there is a good chance that you will miss things. And if you do, finding them in a messy code will take you a lot of time.

You will not be able to reuse things : as told before, some problems are linked to previous one. So you will often have to go back to a previous problem's solution to re-use not the code, but the way of thinking. If you coded it cleanly the first time, this will be easier.

5. Use assertions

I often suggest co-workers to make no assumption in their code (check everything always - let's keep this topic for another post).
Project Euler is a good illustration of that. I use a large amount of assertions in my code despite the low number of lines (about 50 a problem), in order to catch unpredicted cases. The algorithms you will develop are complex, and it's pretty easy to miss one spot. Your own code is the best place to check every assumption you made.

6. Don't cheat and Enjoy

So far I resisted the temptation to cheat (with the few frustrating consequences explained before when specific mathematical theories are involved in the solution). Almost every answers are available just here on internet, but the only meaning of this exercise is to improve your algorithm skills not your google search abilities.

I still can remember the joy I felt, by solving the 393th problem, after days of unsuccessful tries. It worth it.

Here are the notes I took this night while compiling Inkscape. They originally were writen as emails for the Inkscape devel list, but as they were many of them, I'll put them here and send a unique email to the list.

Just to be clear : pretty much everything in this post is not a fix for the issues I encountered, just a way to work around it in order to build Inkscape.

[Inkscape][Devel][Windows][Bazaar] Fetching source using Bazaar on Cygwin, no file fetched exceptinside .bzr folder
Hi everyone,

I just wanted to report some difficulties I add to fetch the source code of Inkscape using Bazaar on Cygwin and how I managed to go on anyway.
I'm pretty sure it's something trivial for a skilled bazaar user, but it wasn't painless for me to figure how to do, and I just want next random guy after me not having the same troubles.

What happened is that I simply followed the wiki how to that is located here
And after a few (dozens of) minutes of downloading, my local repository was empty... except for the .bzr folder.
No error happened and no error was logged anywhere.

bzr update

was only showing me something like

Tree is up to date at revision 13638 of branch ...

It looked like everything was alright, but I had no code to edit or compile. I finally figured out what happened through the

bzr status

command that led me to this error message :

bzr: ERROR: No WorkingTree exists for "file:///cygdrive/c/Donnees/home/InkscapeSource/inkscape/.bzr/checkout/

This led me to forums answers, that finally give me an explanation of the issue.
That was using :

bzr reconfigure --tree

I still had nothing but .bzr in my local folder, but this time a "bzr status" show me every single file as if they were deleted.
So I just had to

bzr revert *

I'm not sure if what happened to me was something unusual or linked to the fact I use Bazaar on Cygwin.
But I wanted this to be logged somewhere, as this may happen to someone else, that may not want to spent the few hours I spent to figure out what the matter was.

Cheers.

[Inkscape][Devel][Windows][MinGW] Compiling using mingw - as.exe cannot start
...
Now I have the sources and I try to build it using mingw.
The symptom is that this command line

g++ buildtool.cpp -o btool

is generating following error :

as.exe wasn't able to start ... 0xc0000022

This forum helped me to find this ticket.
It basically explain that the libiconv-2.dll library that was generated through the command :

g++ buildtool.cpp -o btool

is interfering with the one located in mingw environment.
So I just had to re-set my path to make it work

set PATH=C:/MinGW32bin;%PATH%

Additionally, it would be great to update the mingwenv batch file, in order to make c:/Devlibs to be located before c:/mingw in the path.

Cheers

[Inkscape][Devel][Windows][MinGW] Compiling using mingw - 'gettimeofday(timeval*, NULL)' is ambiguous
...
Next compilation error is :

buildtool.cpp: In member function 'virtual bool buildtool::Make::run(const String&)':
buildtool.cpp:10273:36: error: call of overloaded 'gettimeofday(timeval*, NULL)' is ambiguous
buildtool.cpp:10273:36: note: candidates are:
c:/mingw32bin../lib/gcc/mingw32/4.6.1/../../../../include/sys/time.h:39:29: note: int gettimeofday(timeval*, void*)
buildtool.cpp:84:12: note: int gettimeofday(timeval*, timezone*)

Which I trivially "solved" by editing buildtool.cpp and replacing :

::gettimeofday(&timeStart, NULL);

by

::gettimeofday(&timeStart, (timezone*)NULL);

Cheers

[Inkscape][Devel][Windows][Cygwin+MinW] Using bzr on Cygwin and MingW
Next compilation error is :

Make error line 0: executeCommand : could not create process : Le fichier spÚcifiÚ est introuvable.
Make error line 0: error executing 'bzr revno':

As I use MingW fr compilation but Bazaar on Cygwin, this may not be solved easily. I may have to install bazaar on Windows. For now I just faked a bzr.exe on windows that return the revision number at which I am. Here is the code :

#include <iostream>
using namespace std;
int main()
{
cout << "13638" << endl;
return 0;
}

Cheers

[Inkscape][Devel][Windows]Python] Python crash (Oxc0000022)

Next compilation error is a python.exe crash.
It appear that the used python is

c:/Devlibspythonpython.exe

Which doesn't start at all, even if launched separatedly by hand.
Fortunately I also had another python interpreter in my active PATH, so i just renamed it :

mv c:/Devlibspythonpython.exe c:/Devlibspython_python.exe

Cheers

[Inkscape][Devel][Windows][Python] New python issue "<cxxtestpart> problem:"

Next compilation error is :

Make error line 231: executeCommand : could not create process : Le fichier spécifié est introuvable.
Make error line 231: <cxxtestpart>, problem:

It appears this is the following of my previous python issue. If you grep python.exe inside files :

./build-x64.xml
./build.xml

You'll find multiple path where python interpreter path is absolutely referenced, I just changed them to my python.exe file.

Long term solution may be to make C++ compilation work with recent Mingw (that would carry a better python.exe), or to make the scripts able to use another python.
I'm not sure if one of those solution even would be possible to achieve.

Once this issue fixed, Inkscape is compiling but not linking.

[Inkscape][Devel][Windows][GetText] msgfmt crash
...
Now Inkscape is compiling, but not building yet. I got issues with msgfmt.:

##### compile gettext .po files to .mo
--- i18n / msgfmt
Make error line 421: <msgfmt> problem:

My way to "fix" the problem was to install a fresh version of gettext and libiconv for windows (from here)

And to make the path to point on this one before pointing on the C:/DevLibsbin one.

Hurray : it linked and it executes.

I'm still afraid of some patches I maid (especially if I look at this like this log :

--- distbase / copy
copy : c:/devlibs/python/python26.dll to inkscape
copy : 1 file copied
--- distbase / copy
copy : C:/Tools/python27/python.exe to inkscape/python
copy : 1 file copied)

But it linked and it executes.

Now I may start the fun part.

Cheers

Additional note about btool way to list the dep files (thanks to Failbit and JonCruz from irc://irc.freenode.org/#inkscape-devel )

When adding a cpp file :
- if you want btool to compile it, you may want to delete build.dep in src root and re-run btool
- if you want other OS's make system to be aware of it, you may want to add it (and .h too) in the folder's Makefile_insert

Makefile.am sources the Makefile_insert for each directory
then automake produces Makefile.in
then autoconf produces Makefile

A small note for the one who, like me, use this program for years.

The last precompiled version (1.9 compiled at 2008/03/03) seems not to be compatible anymore with cygwin (not sure wich version of which package, it happend for me on 2013/08/23).
This version is carrying cygwin dlls (cygwin1.dll, cygssl-0.9.8.dll, cygcrypto-0.9.8.dll).

What I did to resolve the problem is :
- recompile from source
- change the embeded libs (that can be found in cygwin/bin)

I'm not sure if recompilation was needed, probably not.

recompile :
-------------

cd proxytunnel-1.9.0

emacs Makefile

===

# CYGWIN

#OPTFLAGS += -DCYGWIN <<< uncomment this line

===

make (apparently the old warning about incompatibility that is mentionned about md4.h and md5.h in INSTALL file is deprecated, because it worked fine for me)

mv proxytunnel.exe ~/proxytunnel (or any rep)

chmod a+x ~/proxytunnel/proxytunnel.exe

--------------

change libs
--------------

cp /cygwin/bin/cygwin1.dll ~/proxytunnel

cp /cygwin/bin/cygssl-0.9.8.dll ~/proxytunnel

cp /cygwin/bin/cygcrypto-0.9.8.dll ~/proxytunnel

--------------