Compiling assemblies for Unity3D using Xamarin 6.x on OSX

8th June 2016, Xamarin releases Xamarin Studio 6.0.0 on OSX, replacing it by Visual Studio 2015 on Windows systems. This version comes with Mono 4.4.x by default, which doesn't support dotNET Framework 3.5. Problem, it's the only way to create compatible assemblies for Unity3D on OSX.

Unity3D: Returning a value from a coroutine

In Unity3D, a simple mecanism helps you to make an asynchronous call in a procedural way, and wait for it to finish: coroutines. This mecanism is not magic. It uses enumerators, that make a code block return a list of values, one by one. However, you can't get any returning value from a coroutine.

But there's a way to do it anyway.

Unity3D - Coroutines et retour de valeurs

Sur Unity3D, un mécanisme simple permet à du code procédural de lancer des traitements asynchrones et d'attendre la fin de son exécution: les coroutines.

Ce mécanisme n'a rien de magique. Il se repose sur les énumérateurs, qui permettent à du code de renvoyer une liste de valeurs, une par une. Cependant, les coroutines ne permettent pas de retourner de valeurs que l'on puisse exploiter.

Il existe toutefois une manière simple de le faire.

Edit Python files with IDLE from WinSCP

Pour une version française de l'article, cliquez sur ce lien : http://antoine-agthe.blogspot.com/2013/08/editer-des-fichiers-python-avec-idle.html

What is WinSCP?

WinSCP for Windows is a simple and powerful tool that lets you work with your server throught SSH while taking benefits of your favorite edition tools, on your favorite Operating System (I stay neutral, never said that my case, or not)

What is Python (briefly)?

Python is a programming language, quite effective, and that simple, for heavy development as for shell script.
It is a good way for whom wants to get started with the wonderful world of programming.

Context

As I was on a project that needed a Facebook connection server-side for statistic processing called once a week (CRON), I chose to use Python.

The server was an Amazon EC2 instance configured with Ubuntu LTS, and my working environment was a PC with Windows 7. I needed a simple solution to edit script files from my server directly on my computer.

I use WinSCP for years now because it makes it easy, by downloading a copy of the edited file into a local temporary file, then listening its updates, in order to upload it automatically when it's modified.

However, the default text editor of WinSCP is not enough convenient for source code editing. And so for Python files. Even if Notepad++ is my favorite editor for many file formats, it does not satisfy me as much as the default Python file editor, IDLE, provided by the Python installer.

Problem

Make IDLE be the default editor of Python files on WinSCP is not as easy as with Notepad++, because IDLE is not an executable, properly speaking.
IDLE is a Python script, interpreted by Python itself, that provides a GUI for python file editing.
So that's not a simple "path to EXE" that you have to set up in WinSCP, but a command line.

Solution

I found a way to do it thanks to the Windows registry.

Don't panic, we won't make anything in that registry, but get a string value.

On Windows, when you wanna edit a Python file, you open the context menu of the file (right click), then select Edit with IDLE.

If you don't know, you'll learn that these contextual functions are defined in the Windows registry.

To find the proper command line, I just called regedit.exe (Windows key + R, then type regedit), then searched (Ctrl+F, or Edit->Search) the following expression : Edit with IDLE.

I got a registry entry HKEY_CLASSES_ROOT\Python.File\shell\Edit with IDLE, that contained a key called command, with the following value:

"C:\Python27\pythonw.exe" "C:\Python27\Lib\idlelib\idle.pyw" -e "%1"

So in order to use IDLE with WinSCP for Python files, you just need to open the Preferences window then click "Editors", and add a new configuration for files with .py extension, select External editor, then type :

C:\Python27\pythonw.exe C:\Python27\Lib\idlelib\idle.pyw -e "!.!"

Editer des fichiers Python avec IDLE depuis WinSCP

For an english version of this article, follow this link : http://antoine-agthe.blogspot.com/2013/08/edit-python-files-with-idle-from-winscp.html

Qu'est-ce que WinSCP ?

WinSCP pour Windows est un outil simple et puissant pour qui désire travailler sur son serveur via SSH tout en bénéficiant de ses outils d'édition favoris, sur son OS favoris (je reste neutre, j'ai jamais dit que c'était mon cas … Je n'ai pas dit le contraire non plus)

Qu'est-ce que Python (vite fait) ?

Python, quant à lui, offre un rapport simplicité/performance plus que correct, que ce soit pour des développements lourds ou dans un usage type script shell.

C'est par ailleurs un très bon langage pour qui voudrait découvrir le monde merveilleux de la programmation.

Contexte

Dans le cadre d'un projet nécessitant une connexion Facebook depuis un serveur pour des traitements périodiques via CRON, j'ai privilégié l'usage d'un script en Python.

Le serveur étant une instance Amazon EC2 sous Ubuntu LTS, et mon environnement de dev étant sous Windows 7, j'avais besoin d'un moyen simple de rapatrier directement le script depuis le serveur, de pouvoir le modifier en local, et de synchroniser ces modifications sur le serveur rapidement.

J'utilise WinSCP depuis assez longtemps maintenant, car il offre cette capacité de synchronisation d'un fichier "remote" modifié en local via un fichier temporaire dont il observe les modifications.

Cependant, l'éditeur par défaut de WinSCP est loin d'être pratique quand il s'agit de modifier des fichiers Python. Si Notepad++ est mon éditeur pour de nombreux formats de fichier, il ne me satisfait pas autant que l'éditeur par défaut de Python, IDLE, fourni avec l'installeur.

Problème

Faire de IDLE l'éditeur par défaut des fichiers Python sur WinSCP n'est pas aussi simple qu'avec Notepad++, car IDLE n'est pas un exécutable à proprement parler.

IDLE est en réalité un script Python qui, s'exécutant, produit un GUI.

Ce n'est donc pas un lien vers une application que vous devez entrer dans la configuration de WinSCP, mais une ligne de commande.

Solution

La solution se trouve dans la base de registre.

Rassurez-vous, nul besoin ici de modifier cette base. Elle m'a juste été nécessaire pour connaître la ligne de commande à utiliser.

Sous Windows, quand on souhaite éditer un fichier Python, on ouvre le menu contexte du fichier (clic droit), puis on sélectionne Edit with IDLE.

Si vous ne le savez pas encore, vous apprendrez donc que ces fonctions contextuelles sont rassemblées dans la base de registre.

Pour trouver cette fonction, j'ai tout simplement exécuté regedit.exe ( touche Windows + R, saisissez regedit), puis j'ai recherché (Ctrl+F, ou menu Edition->Rechercher) l'expression Edit with IDLE.

Je suis donc tombé sur l'entrée HKEY_CLASSES_ROOT\Python.File\shell\Edit With IDLE qui contient une clé command dont la valeur est justement une ligne de commande permettant d'ouvrir un fichier python avec IDLE :

"C:\Python27\pythonw.exe" "C:\Python27\Lib\idlelib\idle.pyw" -e "%1"

Il suffit donc, pour profiter d'IDLE via WinSCP, d'ouvrir la fenêtre des Préférences de WinSCP sur l'onglet "Editeurs", et d'ajouter une nouvelle préférence pour les fichiers d'extension .py et d'utiliser un éditeur externe, en spécifiant :

C:\Python27\pythonw.exe C:\Python27\Lib\idlelib\idle.pyw -e "!.!"

Naming convention for software version

To identify a source code version is a good way to save time during development, test, and deployment phases.
Without it, it is difficult to communicate with all the collaborators, developers, software testers, and final users.

Choosing a naming convention for source code version makes project status easier to control.

Convention de nommage des versions de logiciel

Savoir identifier la version d'un logiciel permet de gagner énormément de temps lors des phases de développement, de test et des différentes phases de mise en production.
Sans cette identification, il est difficile de communiquer avec les différents acteurs d'un projet : les développeurs, les testeurs, jusqu'aux utilisateurs finaux.

En conventionnant le nommage, on assure une compréhension plus rapide de l'état d'un projet.

Gérer les différentes versions de ses librairies sous Windows

For an english version of this article, follow this link : http://antoine-agthe.blogspot.com/2013/02/deal-with-different-libraries-versions.html

Comme beaucoup de développeurs, il se peut que j'intervienne sur plusieurs projets en même temps, chacun d'eux exploitant différentes librairies.
La plupart des développeurs travaillent sur plusieurs plateformes, utilisant haXe/NME, Actionscript pour Flash/AIR, Cocos2D, Starling Framework, Apache Ant … ce qui brasse un nombreux important de répertoires de SDK, de frameworks, ou de librairies.

En parallèle, je dois tester de nouvelles versions de librairies sur des projets existants, ou sur de petits prototypes, donc je dois rendre disponible chaque version de chaque librairie afin de ne pas casser tous les projets en cours.

Les développeurs sous Linux ont pour habitude de tirer partie d'une gestion commune des librairies et de leurs versions.
Les programmes partagent naturellement leurs librairies dans des dossiers communs nommés lib, lib32 et lib64.
Pourtant tous les programmes n'utilisent la même version d'un lib.
Pour s'y retrouver facilement, ils utilisent une ligne commande ln qui crée un lien symbolique sur un fichier ou un dossier..

Un lien symbolique est comme un raccourci sous Windows, mais en plus puissant !

Pour bien comprendre la nuance entre un lien symbolique et un raccourci, il faut suivre les étapes suivante sous Windows.

• Créez un dossier nommé my_real_folder
• Un clic droit, et créez un raccourci que l'on nommera  my_shortcut
• Double cliquez sur my_shortcut.
• Vérifiez la barre d'adresse. Vous êtes dans my_real_folder.

Windows ouvre automatiquement le dossier spécifié dans le raccourci. Si vous prêtez attention à ces dossier et raccourci en ligne de commande, vous verrez qu'un raccourci est un simple fichier LNK.

Si vous tentez d'ouvrir my_shortcut comme un dossier, vous aurez une erreur ("Nom de répertoire non valide")

CECI est la grande différence entre les raccourcis et les liens symboliques.

Les liens symboliques sont gérés par le système de fichier. Ce n'est pas un fichier produit par le système d'exploitation. Le lien symbolique se comporte tout à fait comme le fichier ou le dossier auquel il fait référence.

Comment créer des liens symboliques sous Windows ?

Vous devez utiliser le mode shell (cmd) en mode administrateur, et appeler la commande mklink.

mklink permet de créer des "raccourcis" au niveau système de fichier, vers un fichier ou un dossier comme le fait ln sous Linux.

La grande différence avec ln, est qu'il faut spécifier /D si on veut référencer un dossier :

mklink /D <link> <target>

Retournons sur notre exemple précédent pour créer un lien symbolique au dossier my_real_folder, que l'on nommera my_ref_folder.
Il suffit de faire :

mklink /D my_reference_folder my_real_folder

Utilisez dir pour lister les fichiers.

Vous pouvez voir que le lien n'est pas un simple fichier, mais une entité différente du système de fichier.
Utilisez maintenant cd pour entrer dans le lien.
Dans le prompt, vous pouvez voir que le système de fichier entre vraiment dans la référence, au lieu de faire une redirection.

Ça fonctionne aussi dans l'interface graphique, où on peut voir deux différences :

• La dossier dans la barre d'adresse est bien le lien symbolique
• Le dossier référence est visible dans le volet de gauche, alors que le raccourci ne l'est pas.

Grâce à mklink, vous donc pouvez créer un dossier lib à la manière de Linux, sous Windows.

Par exemple :

Vous avez développé des projets avec Adobe Flex 3.2.0, Adobe Flex 3.4.0 et Adobe Flex 3.4.1.

Vous développez à présent des projets avec Adobe Flex 4.6.0.

Enfin, vous souhaitez tester Apache Flex 4.9.0.

Vous pouvez créer différents liens symboliques pointant sur chaque version majeure et mineure de vos librairies, comme je l'ai fait.

Sur ce screenshot, vous pouvez voir :

• flex-4.9.0 est référencé par flex-4.9
• flex-4.9 est référencé par flex-4
• et flex-4 est référencé par flex

Grâce à cette technique, si je veux créer un projet Flex 4, je peux utiliser la référence flex-4 dans ma configuration de projet.
Quand Apache Flex 4.10 sortira, je n'aurais qu'à recréer les liens symboliques et tous mes projets utilisant flex-4 en bénéficieront.

Si vous voulez utiliser une version plus précise de la librairie, il reste possible d'utiliser les dossiers réels.

Cette façon de gérer les SDKs et les librairies n'est pas la seule. Vous pouvez regrouper les différentes librairies dans un dossier spécifique à chaque langage, à chaque technologie. La technique que je décris est celle que j'utilise, et ça fonctionne plutôt bien.

Deal with different libraries versions on Windows

Pour une version française de l'article, cliquez sur ce lien : http://antoine-agthe.blogspot.com/2013/02/gerer-les-differentes-versions-de-ses.html

As many developers I have to deal with a lot of projects at the same time, each of them using quite different libraries.
Most developers work on multiplatform projects using haXe/NME, Actionscript Flash/AIR, Cocos2D, Starling Framework, Apache Ant … That means a lot of SDK/framework/library folders.

In parallel, I have to test some new library versions on existing projects, or experiment them on small prototypes, so I have to keep every single version of each library in order not to break any WIP projects.

Linux developers usually take benefits of a common way to manage libraries and versions.
Programs usually share their libraries in common folders called lib, lib32 and lib64.
But all the programs don't use the same version of their libraries.
In order to manage different versions, it is possible to use a simple command-line tool called ln that creates a symbolic reference of a folder, or a file.

A symbolic reference is like a shortcut on Windows, but more powerful.

In order to understand the difference between a symbolic reference and a simple shortcut, just follow these steps on your Windows OS.

• Create a new folder called my_real_folder
• Right click on it and create a shortcut that you'll rename my_shortcut
• Then double click to my_shortcut.
• Check the address bar. You're in my_real_folder.

Windows automatically open the folder specified in the shortcut. If you take a look on these folder and shortcut with cmd, you'll see that your shortcut is a LNK file.

If you try to open my_shortcut as a folder, an error will occur ("invalid folder name", or something like that)

THAT is the big difference between shortcuts and symbolic references.

Symbolic references are managed by the file system. It is not a simple link file produced by the operating system. A symbolic reference behaves AS the file or folder it's linked with.

How to create symbolic references on Windows ?

You have to use the cmd shell in administrator mode, and call the mklink command-line program.

mklink allows you to create a file-system-level reference on a file or a folder, as ln does on Linux.

The big difference with ln, is that you have to specify the /D parameter if you want to reference a folder:

mklink /D <link> <target>

We'll go back to our example and use this command to create a reference of our my_real_folder, that we'll name my_ref_folder.
All you have to do is tip :

mklink /D my_reference_folder my_real_folder

Then use dir to list files.

You can see that the reference is not a simple file, but a completely different entity in the file system.
Then use cd to enter the reference folder.
In the prompt, you can see that the file system really enters the reference folder, instead of doing a visible redirection.

It also works on your graphical interface, where you can see two things:

• The folder in the address bar is the reference folder
• The reference folder is visible in the folder exploration on the left, while folder shortcut is not.

Thanks to mklink, you can create a Linux lib-like folder on Windows.

For example:

You developed some projects with Adobe Flex 3.2.0, Adobe Flex 3.4.0 and Adobe Flex 3.4.1.

You currently develop some projects with Adobe Flex 4.6.0.

At least, I want to experiment Apache Flex 4.9.0.

You can create several folder references to point major and minor versions of your librairies, as I did.

On this screenshot, you can see that:

• flex-4.9.0 is referenced by flex-4.9
• flex-4.9 is referenced by flex-4
• and flex-4 is referenced by flex

Thanks to this technique, if I want to create a Flex 4 project, I can use flex-4 reference in my project configuration.

When Apache Flex 4.10 will be released, I just will recreate my references and all my projects using flex-4 reference will be updated.

If you want to use a more precise version of a tool, it is still possible if you use real folders.

This way to manage SDKs and librairies is not the only one. You can regroup libraries in a language or technology specific folder. The one I describe is the one I use, and it works great.