=== Mrokii_ is now known as Mrokii [08:31] exit === caglar is now known as Guest77758 === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu App Developer Week - Current Session: Catch that bug Quickly! - Debugging Quickly apps with pdb - Instructors: Abd4llA [15:01] ok about ready? [15:01] Day 4, keep up the energy! [15:01] take it away Abd4llA! [15:01] Thanx jcastro [15:02] Ok guys good afternoon [15:02] As you all know today we'll be talking about debuging python apps, [15:03] specially Quickly apps [15:03] Well there're tons of python debuggers out there [15:04] but I'd say in 90% of the cases, you'll be using "pdb" [15:04] pdb comes by default with the python installation [15:05] As its name shows, it stands for "Python DeBugger" [15:05] You can use pdb to track your program execution, [15:06] do post-mortum debugging [15:06] and pretty much anything a decent debugger should do :-) [15:08] So lets get rolling quickly with pdb === MSK61 is now known as MAfifi [15:09] So to start with, lets see how a normal pdb session looks like [15:09] just in the terminal issue the command "pdb" [15:10] You'll see that it accepts normal scripts as an argument [15:11] so we can pretty much launch pdb normally [15:11] pdb [15:11] that'll launch a pdb debug session for your script [15:11] starting at the first line, from there you can set your break points...etc then get rolling [15:12] or you can inject an explicit call to pdb from within your python script [15:12] so lets see how can we do that [15:12] First, as I said, this is about debugging quickly apps, but most of what we'll say today can be applied to any python scripts/programs [15:13] So, lets start by creating the sample quickly ubuntu-application template application [15:13] from your favourite workspace dir, issue create a quickly app by issuing the command [15:14] quickly create ubuntu-application DummyApp [15:14] And let me know what you see :) ? [15:15] Now as you see, this is the default template app for the ubuntu-application quickly template [15:16] It's pretty dummy, so lets try adding some "yea, dummy" functionality [15:16] there u'll find a "save" item in the "file" menu [15:17] so lets call some function when we click save [15:17] close your DummyApp [15:17] then navigate to the dummyapp dir [15:18] there, issue the command: [15:18] quickly design [15:18] That'll launch "Glade" [15:18] now click on the file menu [15:18] and click on the "save" [15:19] in the properties panel on the right [15:19] click the "Signals" tab [15:20] You'll find a subitem called "activate" under "GtkMenuItem" [15:20] There we'll write down the name of the method to call when we click save [15:20] lets call it "save_me" [15:21] so write down "save_me" in the "Handler" field of the item "activate" [15:22] so [15:22] now make sure to save [15:22] ctrl+s [15:22] close your glade [15:23] now we need to write down that method [15:23] so in your terminal, issue the command [15:23] quickly edit [15:23] that'll open all your source files [15:23] in gedit [15:24] now go to the file dummyapp [15:24] That's our main file [15:24] we need to add our save_me method to the DummyappWindow class [15:25] so navigate there, maybe under the "on_destroy" method [15:25] add the following method [15:26] def save_me(self, widget, data=None): [15:26] introduce_bug() [15:27] Now as you see, we're calling a method called introduce_bug [15:27] we'll add that function to helpers.py [15:27] so go to the top of the dummyapp file [15:27] and import it as follows [15:28] from dummyapp.helpers import introduce_bug [15:28] we'll write that function ourselves [15:28] Now navigate to helpers.py inside your gedit [15:29] and at the very bottom, write down that method [15:30] def introduce_bug(): [15:30] name = "bug" [15:30] print "I am a " + name [15:30] print "I am a healthy line" [15:30] then save your gedit [15:31] Keeping up so far? [15:31] Now save gedit, then close [15:31] then run our app by firing [15:31] quickly run [15:32] and click "save" [15:32] in your terminal you should see [15:32] I am a bug [15:33] I am a healthy line [15:37] Make sure your import line [15:38] is under the line [15:38] from dummyapp.helpers import get_builder [15:38] so at the end it'll look like [15:38] from dummyapp.helpers import get_builder [15:38] from dummyapp.helpers import introduce_bug [15:38] Now run again [15:38] quickly run [15:38] click save [15:38] test [15:38] all good ? [15:39] Now that's a bug over there [15:39] We need to hunt it down [15:39] there're several ways [15:39] but lets choose the easiest [15:40] from your command line [15:40] issue the command [15:40] pdb bin/dummyapp [15:40] Now we're starting a pdb session [15:40] it started at the first line of your script [15:41] pdb accepts commands [15:41] so issue [15:41] h [15:41] that should show the help [15:41] now we need to add some breakpoints [15:41] we know that the method save_me is the one that gets called when clicking save [15:41] so lets add a breakpoint to it [15:42] the comman b is used to add breakpoints [15:42] (Pdb) b dummyapp:134 [15:43] this way we added a breakpoint to the file dummyapp [15:43] line number 134 [15:43] you should match the line number of your def save_me [15:44] my method is defined at line 134 [15:44] so now we have a breakpoint there [15:44] let's run the code ! [15:44] c [15:44] that'll continue execution untill the first breakpoint [15:44] Good? [15:45] notice the command "c" [15:45] now we notice that it'll stop when it reads the function definition [15:46] that's not what we want [15:46] we wanna stop when it starts executing [15:46] so lets try that again [15:46] close the app [15:46] run it inside pdb [15:46] pdb bin/dummyapp [15:46] now this time, lets make the breakpoint at the introduce_bug() method call line [15:46] the first line of the "save_me" function [15:47] (Pdb) b dummyapp:135 [15:47] now lets continue execution till first breakpoint [15:47] (Pdb) c [15:47] you'll see that the application shows [15:48] and now we need to click "file-> save" [15:48] there you'll see pdb stoping at the break point [15:48] Good ? [15:49] now lets try some pdb commands [15:49] (Pdb) l [15:49] that'll list the code [15:49] (Pdb) w [15:49] stack trace [15:50] Now we can either execute the next line using "n" or step into the method "introduce_bug" [15:50] using s [15:50] so lets see [15:50] (Pdb) s [15:50] we're there now [15:50] (Pdb) n [15:50] will go to the next line [15:51] (Pdb) l [15:51] list the code there [15:51] now I see that the "print "I am a " + name" line is the one that introduces a bug and I wanna skip it [15:51] (Pdb) j 50 [15:52] That way we jumped to the next line [15:52] (Pdb) c [15:52] will continue execution without the buggy line and will print "I am a healthy line" only [15:52] Good ? [15:53] Lets try another way to trace that bug [15:53] close your session [15:53] and edit your code [15:53] quickly edit [15:53] go to dummyapp file [15:54] in save_me method [15:54] add the following line before the call to "introduce_bug" [15:54] import pdb; pdb.set_trace() [15:54] so the final method will be [15:55] def save_me(self, widget, data=None): [15:55] import pdb;pdb.set_trace() [15:55] introduce_bug() [15:55] now run the app [15:55] quickly run [15:55] go to file->save [15:56] you'll see that a pdb session will start @ the termincal [15:56] *terminal [15:56] that's another way to launch ur pdb , from within the code [15:56] now type args [15:56] that prints the arguments [15:57] (Pdb) args [15:57] also there's u and d [15:57] (Pdb) u [15:57] that goes to the upper frame [15:57] (Pdb) d [15:57] That goes to the lower one [15:57] now [15:57] (Pdb) s [15:58] step into the introduce_bug method [15:58] (Pdb) n [15:59] now you can alter your name variable [15:59] (Pdb) name = "Not a bug" [15:59] That was a quick introduction for Pdb guys :) [15:59] So thanks alot guys , more time would've been convenient :) [16:00] but hopefully it was fun :-) === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Event: Ubuntu App Developer Week - Current Session: Making your application translatable in Launchpad - Instructors: dpm [16:01] Thanks Abd4llA, and hi everyone! [16:01] Welcome to this session on setting up your project for translations in Launchpad. [16:02] My name is David Planella and I'm the Ubuntu Translations Coordinator, where I work with our translations community to bring you a localized operating System. [16:02] I also tend to help with any topics related to translations and Launchpad, and that's what we're going to talk about today :) [16:02] That's a really exciting topic to me, as Launchpad makes it really easy to make your applications translatable and available to everyone in almost any language, and I hope you enjoy it as much as I do. [16:03] Translators are really awesome people! [16:03] Anyway, let's get started, shall we? [16:03] = Assumptions = [16:03] I will start with an application ready set up for translations, so I'm not going to go into much detail there. [16:04] My intention is to focus in getting you started with exposing your project's translations to everyone for translation. [16:04] In any case, if you've got questions on this, feel free to ask either during or at the end of the session, and I'll be more than happy to answer them [16:04] We're going to be using these tools: [16:04] bzr [16:04] quickly [16:04] python-distutils-extra [16:04] In particular quickly, which we'll use to start with a nearly ready-made project with translations set up [16:05] (You can install it by running the 'sudo apt-get install quickly' command or you can get it from Applications > Ubuntu Software Center) [16:05] [16:05] = Creating the project and setting it up for translations = [16:05] [16:06] We'll use quickly to create a project called 'fooby', and then we'll set up the last touches needed to configure translations. [16:06] So if you've got all those tools installed, you can simply fire up a terminal window (Applications > Accessories > Terminal) and run the following command: [16:07] quickly create ubuntu-application fooby [16:07] This will create an application named 'fooby' [16:07] and give you some information about it on the first run [16:08] then change to the fooby folder: [16:08] cd fooby [16:08] And finally run: [16:08] python setup.py build_i18n [16:08] That should have finished the last bits to set up translations [16:09] in particular it created the po folder to contain the translations template and the translations [16:09] you can see the template: [16:09] ls po [16:09] have a look at it: [16:09] gedit po/fooby.pot [16:10] It's important to get a bit familiar with it, but you don't have to remember the whole format [16:10] you should simply know what it is for now :) [16:10] A few words on translation templates: [16:10] * Gettext: They follow the gettext format: http://is.gd/fC8p6 [16:11] * Name: They are generally named after your project, with a .pot extension. E.g. fooby.pot [16:11] * One template per app: Generally applications need only one template [16:11] * Layout: They generally live in the po/ folder, along with the translations [16:11] * Content: They are text files which contain: [16:11] * A header with metadata [16:11] * A set of message pairs: msgid are the original strings extracted from the code and exposed to translators, and msgstr are the placeholders for the translations, which are always empty in the templates. [16:12] * Launchpad import: They are imported into Launchpad and exposed for translations for all languages in https://translations.launchpad.net/$YOUR_PROJECT [16:12] * Updates: You update the template whenever you have new strings in your app and you think they are stable for translation (generally shortly before release) [16:12] * Tools: you update templates with gettext based tools: [16:12] * generally intltool -> 'cd po && intltool-update -p' [16:13] * or increasingly python-distutils-extra for python projects -> 'python setup.py build_i18n -p' [16:13] You don't have to remember all of this [16:13] But at least you should know how that you must update the template from time to time [16:13] and the command to do it [16:13] You'll see that your project still does not contain any translations, but let me give you a quick overview, so you know what we're talking about: [16:14] A few words on translations: [16:14] * Template-based: They are created from the template and share the same gettext format [16:14] * Name: They are named after the $CODE.po scheme, where $CODE is an ISO 639-2 code. E.g. ca.po for Catalan, de.po for German. Some have an optional country specifier. E.g. pt_BR.po (Portuguese from Brazil) [16:14] * Layout: they are all in the same directory as the POT template. So: [16:14] * po/fooby.pot [16:15] * po/ca.po [16:15] * po/pt_BR.po [16:15] * ... [16:15] * Creation: Launchpad creates them for you the minute someone translates the first message online [16:15] * Code integration: you can let Launchpad commit them to a branch of your choice or you can export a tarball containing them all [16:16] Anyway, let's continue. Now that you've added the template to your code, you can commit it: [16:16] You can run the following commands: [16:16] bzr add po [16:16] bzr commit -m 'Created my first ever awesome .pot template. Go translators, go!' [16:17] And let's publish it in Launchpad (note that you'll have to change the Launchpad URL to your user name instead of 'dpm'): [16:17] bzr push lp:~dpm/fooby/translations [16:17] Nothing particularly hard to understand on the naming scheme above: dpm is my user name, fooby is the project and translations is the branch name [16:18] Ok, so that completed the first step! [16:18] Next: [16:18] [16:18] = Setting up code hosting = [16:18] [16:18] We want our project to be available to everyone to translate, so we'll need to publish it in Launchpad. [16:18] That's beyond the scope of this session, so we'll continue from the already registered fooby project in Launchpad: [16:18] https://code.launchpad.net/fooby [16:19] In case you are interested, though, registering a new project in Launchpad is as easy as going to https://launchpad.net/projects/+new [16:20] Some of the URLs will not allow you some of the pages due to permissions, so if you have your own project in Launchpad, just substitute the 'fooby' part in the URL with your project's Launchpad id [16:20] The first thing we'll have to do in our project is registering a bzr branch, [16:20] so we'll simply go to the Code tab in Launchpad, choose the "Configure code hosting" link [16:21] and then on the "Link to a Bazaar branch already on Launchpad" you can enter the branch we published earlier on (~dpm/fooby/translations) [16:21] A shortcut is to simply go to: [16:21] https://code.launchpad.net/fooby/trunk/+setbranch [16:21] to do this [16:21] So now we have all we need to start setting up translations. [16:22] You see that all components in Launchpad are integrated, so you set up a branch to be linked to translations [16:22] Just as a recap, you can see and explore the resulting code from here: [16:22] https://code.launchpad.net/fooby [16:22] Feel free to browse it (http://bazaar.launchpad.net/~dpm/fooby/translations/files) [16:23] or download it (bzr branch lp:fooby) and play with it [16:23] Ok, so code hosting setup: (./) Finished! [16:23] [16:23] = Setting up translations in Launchpad = [16:23] [16:24] Now we come to the most interesting part [16:24] 1. Telling Launchpad where translations are hosted [16:24] The first step it to tell Launchpad that we want to host translations there. [16:24] On your Launchpad's project, just click on the Translations tab, or go to this URL: [16:25] (remember to change 'fooby' to your project's name) [16:25] https://translations.launchpad.net/fooby/+configure-translations [16:25] Then choose the "Launchpad" option to tell Launchpad translations will be done there, and click on "Change" [16:26] That was an easy one, wasn't it? [16:26] 2. Configuring permissions [16:26] Now we are going to tell Launchpad how we want our translations permissions to be (i.e. who and how can translate it), [16:26] and which branch translators should focus on. [16:27] Simply go to the Translations tab again and click on the "Change permissions link" [16:27] Or here's the direct link: https://translations.launchpad.net/fooby/+settings :) [16:27] I recommend the following setup: [16:28] Translations group: Launchpad Translators [16:28] Translations permissions policy: Structured [16:28] Translation focus: trunk (or choose your branch here) [16:29] Assigning the translations to a translation group will make sure a team for each language will review translations before they are submitted, ensuring the quality of translations [16:30] A translations group is a group of teams, one per language, that takes care of translations in their language [16:31] They can be specific to a project or generic. I recommend the Launchpad Translators group because it contains a set of already established and experienced teams: [16:31] https://translations.launchpad.net/+groups/launchpad-translators [16:31] as per the Structured policy [16:32] This gives you a good balance between openness and quality control: [16:32] Only the team members of an established team will be able to translate your project [16:33] And for languages without a team it will allow everyone to translate, facilitating the barrier of entry to translators at the expense of QA [16:33] The other extremes are Open or Restricted [16:33] You can learn more about these here: [16:34] https://help.launchpad.net/Translations/YourProject/PermissionPolicies [16:34] It's the project maintainer's call, but I personally discourage them to use Open [16:34] Ok, we're nearly there, next step: [16:34] 3. Setting up what needs to be translated [16:35] You need to also tell Launchpad what needs to be translated. That's again quite easy. On the Translations tab again, choose the trunk series and specify your branch there [16:35] Direct link: https://launchpad.net/fooby/trunk/+linkbranch [16:35] Another easy one [16:35] 4. Configuring imports and exports [16:36] That's for me the most interesting bit [16:36] The settings on this section basically enable Launchpad to do the work of managing translations for you [16:36] You can tell Launchpad to import your translation templates automatically whenever you do a commit [16:37] So you don't have to upload them manually [16:37] If you are migrating a project with existing translations, you can tell it to import them too [16:37] And finally, you can let Launchpad commit translations automatically to a branch of your choice [16:38] I find that just awesome [16:38] So for the imports, on the Launchpad page, on the "Import translations from branch" section: [16:39] I recommend choosing "Import template files" and then "Save settings" [16:39] For exports: look at the "Export translations to branch" section and then click on the "Choose exports branch" link [16:40] So that was it! [16:40] 4 easy steps that should not take you more than a few minutes to set up, and your app is ready for the world to translate! [16:40] Just a few final words: [16:40] [16:40] = Play with translations = [16:40] [16:41] As a developer, it might be interesting to see how translators do their work. [16:41] Exceptionally (remember how I advised not to use Open permissions, tough :) I've set the translations permissions on the fooby project to Open [16:41] So you can submit translations [16:41] and get a feel for the work that translators do [16:42] As a developer, it will give you an understanding on how they work. It is always interesting to get to know other workflows [16:43] and it's always good to have an insight on all areas of contribution related to your project [16:43] You can start translating fooby here: [16:43] https://translations.launchpad.net/fooby [16:43] [16:43] = Summary = [16:43] [16:43] Most of the steps described here today you'll only need to do once, unless you need to change the settings. They were: [16:44] 1. Setting up code hosting (in case you hadn't already) [16:44] 2. Setting up translations in Launchpad [16:44] 2.1. Telling Launchpad that it's hosting your translations (https://translations.launchpad.net/fooby/+configure-translations) [16:44] 2.2. Configuring permissions: recommended -> Structured, Launchpad Translators (https://translations.launchpad.net/fooby/+settings) [16:44] 2.3. Setting up the translations branch (https://launchpad.net/fooby/trunk/+linkbranch) [16:44] 2.4. Configuring imports and exports (https://translations.launchpad.net/fooby/trunk/+translations-settings) [16:45] So really, once your project is set up for translation, the only things you'll have to remember are: [16:45] to update the template before a release, [16:45] announce to translators that they can start their work, [16:45] and merge the translations to your main branch. [16:45] If you are using the same branch for translation imports and exports, you won't even have to do that! [16:46] So here's a reminder on how to do these steps: [16:46] Updating the translation template [16:46] --------------------------------- [16:46] python setup.py build_i18n -p # To update the template [16:46] bzr commit -m"Updated translation template" # Commit your local changes [16:46] bzr push # Push changes to the remote branch [16:47] [16:47] Call for translations [16:47] --------------------- [16:47] Just send an e-mail to launchpad-translators(at)losts(dot)launchpad(dot)net or to the list where the coordination of your project's translation is happening [16:47] [16:47] Just to finish, you'll find more information on the topics covered in this session here: [16:48] * https://help.launchpad.net/Translations/YourProject [16:48] * https://help.launchpad.net/Translations/YourProject/BestPractices [16:48] So that was it! I hope you enjoyed it and that I can soon see your projects up for translation in Launchpad [16:49] Does anyone have any questions? [16:49] MAfifi asked: What about non-python based projects? [16:49] The Launchpad part is the same for those. Let's take a C project, for example [16:50] the only differences between languages, or rather between build systems, is how you update the template [16:50] In a GNOME application in C using autotools, for example, you'd just go to the po folder [16:51] and call intltool-update -p [16:51] MAfifi asked: What if I want to submit a translation in a language no team exists for? [16:51] It all depends on the permissions you've set up for your project [16:52] With Open and Structured permissions, the translations would just be accepted [16:52] With Restricted, they'd be marked as suggestions, but would not be included in the project [16:53] until there is a team which reviews them [16:53] As the maintainer, you can bypass that and do a manual upload of the translations for which there isn't a team [16:53] But I'd rather avoid bypassing translation teams [16:54] and try to find someone that can review the translations before them being accepted [16:54] oh, MAfifi meant for translators [16:55] As a translator, the same as above applies, only that you cannot bypass translation teams as a maintainer can do [16:55] so for Structured, it there is not a team, you'd be able to submit translations, the same as in Open [16:56] For Restricted, you'd be able to submit suggestions, which are recorded in Launchpad, but would not make it into the project until a team for the language is created [16:58] Any more questions? [16:59]