One of the "paper cuts" developers have been having with developing their MonoTouch 4.0.x (and earlier) applications is that for some networking setups, the IP of the developer's workstation detected by MonoDevelop and given to the iPhone or iPad device for debugging purposes is not correct. This often happens if the WiFi is a different network than the network that the developer's machine is connected to (although there are other scenarios as well).

Since it does not seem to be widely known about, allow me to point out that current versions of MonoTouch allow developers to modify the IP that the runtime should connect to for debugging via the iOS Settings app found on any iPhone or iPad (or Simulator). You can see a screenshot of this per-App Settings page in the screenshot to the left. Each of these fields are editable, allowing you to override the defaults filled-in by MonoDevelop.

For our upcoming 4.1 release, Rolf Kvinge and I (but mostly Rolf) have been working on improving this. Rolf has modified the code to check the value of the IP provided in the per-App Settings and if it is set to nil or "automatic", the debugger falls back to checking for a file bundled with the app called MonoTouchDebugConfiguration.txt which can list any number of IP's to try and connect to, each one being on a separate line prefixed with "IP: ". For example:

IP: 10.0.1.31
IP: 192.168.1.31
IP: 204.11.102.79

The runtime will then attempt to connect to each of these IPs asynchronously until it establishes a connection to one of them (at which point it aborts the other waiting connections). This config file solution will hopefully help simplify things for developers a bit by allowing them to pre-configure which IPs to try for their local network configuration w/o having to manually override the iPhone debug settings on the device or simulator.

For Phase 2 of our plan for World Domination, Rolf is hard at work adding support to MonoDevelop and the runtime to allow for USB debugging which will obsolete the above functionality in future versions where the developer has a MonoDevelop which supports USB debugging. For developers stuck on an older MonoDevelop (like 2.4), the solution illustrated above requires no changes to MonoDevelop and so will be available for use.

Hi,

I changed the openSUSE mkinitrd to mount the /usr filesystem in the initrd, if /usr is a separate partition. I hope this will calm down some heated discussions about systemd, udev, etc. It’s not 100% ready yet, some setups like root or /usr on nfs or md might not work as expected (*), but the common usecases should be covered. Try updating mkinitrd from the Base:System project and let me know if it works for you. Before testing it, you should do a backup of your initrd:

# cp /boot/initrd-`uname -r`{,.orig}

and create a section in /boot/grub/menu.lst pointing to the /boot/initrd-*.orig file.

Нашел замечательную программу для постинга в блоги прямо из КДЕ — Blogillo, из которого я сейчас и пишу. Программа даже уже есть в основном репозитарии системы.

Основные достоинства пока заметил два — возможность писать в различные блоги (а не только в ЖЖ, как можно было с KLuYe), и стабильная работа. Если будут еще впечатления — поделюсь

Hi all,

It’s nice to write to you again. I’ve been having a 10 days vacation (that’s why there was no week 8 report), enjoyed it and now I’m back with fresh forces.

This short (started slowly on Tuesday) week’s activity regards:
- almost fixing a bug that prevents my PackageKit software-center from prime time: package information isn’t correctly refreshed after an installation/removal
- starting work on the openSUSE integration (the corresponding Distro class, removal of forgotten apt related imports, dependency identification and testing).

I will continue work on this side and hope that by the end of the next week, will have everything working and up for testing in openSUSE.

Cya

NB: I will have to provide for testing a trunk version of pygobject since a release is delayed by another awaited merge;

Source: http://www.openclipart.org

Hello again,

this is my report for the 10th week of GSoC. Unfortunately i wasn’t able to create the beta packages i was hoping. There are still some issues to be resolved within the aug_process_tree that hopefully will be solved this weekend.

This week news:
– During some tests i carried out: small errors and space for small tweaks in code was found. Solved all of errors found.

– Code Improvements:
–>New function: struct tree **tree_get_children(struct tree * node)
–>More checks for null values etc in tree matching comparing etc
–>Better handling of comments and null labeled nodes within the configuration files parsed by augeas. I had an idea this week, after discussing with my mentor Michal, the idea was concerning the sorting of the comments and how not to mess with their order in the file. A solution was found based to the idea,at least temporary, and it is already implemented.

– Code Changes:
–>Changed functions:
—->struct tree** tree_child_sort_label(const augeas *aug,struct tree *node) now accepts the tree parent node as a parameter, changes in the code within
—->struct treeMatch* tree_compare_children(const augeas *aug,struct tree **first,struct tree **second) now accepts arrays of struct trees, changes in the code within
—->aug_process_tree still under constant changes.

The reason for all the above changes,the continuous code improvements and the delay in the completion of the aug_process_tree is based mainly due to the reason that i want to create functions that will be further useful by other developers of Augeas and will not just fulfill merging of sysconfig files but it will be possible to used/extended to other configuration files as well.

What is to be done:
-Finish aug_process_tree
-Beta Packages
-Test merging functions
-Code improvements?!