Re: [Sugar-devel] Managing github forks
Why not rebase to update? The current guide can lead to some messy merge commits. I guess you can fix it with an interactive rebase later, but this has always been the cleanest way I've found to keep my forks up to date as well as enabling clean merges of my forks. Manuel Quiñones mailto:ma...@laptop.org May 27, 2013 9:34 PM Hey William, What I do to keep my forked repo updated is: 1. add a remote to the main repository, call it upstream 2. keep in sync with it, fetching and merging often it is explained in our docs: http://developer.sugarlabs.org/contributing.md.html#forking http://developer.sugarlabs.org/contributing.md.html#keep%20your%20fork%20up%20to%20date -- .. manuq .. Will Orr mailto:w...@worrbase.com May 27, 2013 8:59 PM Hello, When doing work on my feature branch, usually I do a git pull --rebase origin master to update, that way my patches will cleanly apply to the master branch of the project when I file my pull request. I avoid merge commits this way as well. The downside is that I might be messing with the history of my feature branch, which might even be public. William Orr ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [sugar-build] Is webkitgtk becoming a barrier?
We have sugar-build use packages for certain packages on Fedora 19 that aren't available on Fedora 18 already (ragel, node, npm), so why not just add webkitgtk to the list as well? It makes sense enough to me, provided we're pulling a compatible version. To that end, I've already submitted a pull request. ;-) Manuel Quiñones mailto:ma...@laptop.org May 20, 2013 7:24 AM I was seeing the same :) Yes, would be nice for distro F19 to use the installed webkitgtk. Thanks! -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Daniel Narvaez mailto:dwnarv...@gmail.com May 20, 2013 4:42 AM Btw, I think we are currently triggering a webkitgtk build after every pull, even if nothing is really changed (I blame webkitgtk stupidity for that at least partially :P). I will fix that. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Daniel Narvaez mailto:dwnarv...@gmail.com May 19, 2013 6:41 AM Hey, It seems like building webkitgtk is a bit of a pain for many people. I would like people feedback on how bad of an obstacle it really is and about a couple of possible solutions: 1 Have buildbot generate snapshots of the base system dependencies which most people are unlikely to want to modify anyway and upload those. It would probably be a system.img file which you would put in your sugar-build directory. With that file present, the external sugar dependencies would not be downloaded and built at all. 2 Officially support Fedora 19, disable the webkitgtk build there and suggest people for which building webkigtk is too much to use Fedora19. Thoughts? Would you use 1/2 if it was available? -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unit tests in Sugar HTML
Manuel Quiñones mailto:ma...@laptop.org Tuesday, May 14, 2013 8:15 AM 2013/5/13 Daniel Narvaezdwnarv...@gmail.com: On Monday, 13 May 2013, Manuel Quiñones wrote: 2013/5/13 Daniel Narvaezdwnarv...@gmail.com: I'm on a phone so I have not yet taken a proper look. Though it looks pretty cool. It seems to have custom browsers support, so it should be easy to run it in sugar-html-activity. We can look at hooking this up in sugar-build/buildbot, it should not be a lot of work. I suppose it should work for the libraries too if we just put some HTML in the test dir. Yes the idea is to add unit tests in each of our libraries. I did it in lib/sugar-html-graphics inside clockjs code to get a first impression, but I will move it to sugar-html-graphics repository if we agree using Jasmine. Maybe a quick comparison with mocha (used by firefox os) would be worth it, since karma can run mocha tests too. I wouldnt spend too much time on it though. Yes I agree, I will give a look to Mocha. Maybe QUnit too. So the proposal would be: - start writting unit tests with Jasmine framework Yes! - add a command to sugar-build to run the tests with Karma Yeah, we can use the check command and run karma for the js modules. - automate tests adding Karma to buildbot Which should just work if we use the check command. Something else I would like to provide is a way to take screen snapshots. The tests could request the webview to generate a snapshot with a certain id (we could use an alert with a well known text, in lack of a better communication mecanism, could be done more cleanly with a plugin but probably not worth it for tests). At the end of test run, the runner would compare the snapshots with those in test/snapshot and complain about differences. It's trivial to implement and should be pretty useful for testing visual stuff. The thing is, in the Karma server you don't see you web application, but this: http://dev.laptop.org/~manuq/karma.png The real information appears in the command line: [sugar-build sugar-html-graphics-manuq]$ karma start INFO [karma]: Karma server started at http://localhost:9876/ INFO [Chrome 26.0 (Linux)]: Connected on socket id VrmGeTEdSMYWd82R6Emw Chrome 26.0 (Linux): Executed 2 of 2 SUCCESS (0.517 secs / 0.021 secs) and the good thing is that by default it will watch your JS files for changes and run the tests again. That's why I was thinking in a new sugar-build command. Of course the auto-run can be switched off and then the check can be added to make check, I'm +1 to that. -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Daniel Narvaez mailto:dwnarv...@gmail.com Monday, May 13, 2013 7:58 PM On Monday, 13 May 2013, Manuel Quiñones wrote: 2013/5/13 Daniel Narvaez dwnarv...@gmail.com javascript:;: I'm on a phone so I have not yet taken a proper look. Though it looks pretty cool. It seems to have custom browsers support, so it should be easy to run it in sugar-html-activity. We can look at hooking this up in sugar-build/buildbot, it should not be a lot of work. I suppose it should work for the libraries too if we just put some HTML in the test dir. Yes the idea is to add unit tests in each of our libraries. I did it in lib/sugar-html-graphics inside clockjs code to get a first impression, but I will move it to sugar-html-graphics repository if we agree using Jasmine. Maybe a quick comparison with mocha (used by firefox os) would be worth it, since karma can run mocha tests too. I wouldnt spend too much time on it though. So the proposal would be: - start writting unit tests with Jasmine framework Yes! - add a command to sugar-build to run the tests with Karma Yeah, we can use the check command and run karma for the js modules. - automate tests adding Karma to buildbot Which should just work if we use the check command. Something else I would like to provide is a way to take screen snapshots. The tests could request the webview to generate a snapshot with a certain id (we could use an alert with a well known text, in lack of a better communication mecanism, could be done more cleanly with a plugin but probably not worth it for tests). At the end of test run, the runner would compare the snapshots with those in test/snapshot and complain about differences. It's trivial to implement and should be pretty useful for testing visual stuff. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Manuel Quiñones mailto:ma...@laptop.org Monday, May 13, 2013 12:30 PM Yes the idea is to add unit tests in each of our libraries. I did it in lib/sugar-html-graphics inside clockjs code to get a first impression, but I will move
Re: [Sugar-devel] Github issue tracking
Simon Schampijer mailto:si...@schampijer.de May 11, 2013 11:55 AM Am 11.05.2013 um 16:45 schrieb Daniel Draked...@laptop.org: On Sat, May 11, 2013 at 4:15 AM, Daniel Narvaezdwnarv...@gmail.com wrote: https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27 We should probably decide if we want to keep using trac instead and if so turn the issue tracker on github off. Last time we discussed it, the idea was to keep using trac to not depend too much on closed source github. What are people thoughts these days? I would prefer to stay with trac, to avoid a split/migration, to keep the info on the tickets directly under our control, and to keep with our open source ideals. Daniel I wanted to give it a try to see how it works at least, going through the process with this ticket. I am not opposed to stay with trac though. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Daniel Drake mailto:d...@laptop.org May 11, 2013 10:45 AM I would prefer to stay with trac, to avoid a split/migration, to keep the info on the tickets directly under our control, and to keep with our open source ideals. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Daniel Narvaez mailto:dwnarv...@gmail.com May 11, 2013 6:15 AM Hello, I noticed people have started to report issues on github. https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27 We should probably decide if we want to keep using trac instead and if so turn the issue tracker on github off. Last time we discussed it, the idea was to keep using trac to not depend too much on closed source github. What are people thoughts these days? Personally I like github issue tracking a lot, though I see the point about it being closed source and I imagine a migration would be a bit of a pain. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Hello, Sticking with a privately controlled bug tracker is probably a good idea. However, trac really needs to be cleaned up, as there are a ton of 3-5 year old bugs floating around that have long since been fixed. I've started closing the few I can't reproduce in scm. As a new contributor, I initially had gotten the impression that no one used trac, and I was discouraged from reporting/fixing bugs there. -- William Orr ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Automated pyflakes checking
Walter Bender mailto:walter.ben...@gmail.com Wednesday, May 08, 2013 8:17 AM On Wed, May 8, 2013 at 5:31 AM, Daniel Narvaez dwnarv...@gmail.com mailto:dwnarv...@gmail.com wrote: On 8 May 2013 06:02, William Orr w...@worrbase.com mailto:w...@worrbase.com wrote: I've done some initial work on both sugar and sugar-toolkit-gtk3 with respect to PEP8. I've also added support for PEP8 in make check for both packages. Pull requests are here: https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/25 https://github.com/sugarlabs/sugar/pull/49 Let me know if I need to make any changes. Awesome! Thanks for working on this! +1 I didn't go through all the changes yet, but I have one general concern. You have disabled E501 (line too long), which would be fine as an intermediate step, though you seem to be regressing line length when fixing the other issues. Perhaps it make sense to do the E501 changes together so that we avoid regressions? If you end up reworking the patches it might also make sense to split them up a bit more (even arbitrarily) just to review/land more gradually and diminish a bit the risk of conflicts etc. I don't expect the review to be particularly complicated, though there are a few odd cases with line continuations that we will need to check/discuss/tweak. Also, there are a few non-pep8 fixes mixed in as well, e.g., replacing type() == with isinstance()... a needed change but perhaps the kind of thing that could go in a separate patch. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org mailto:Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Daniel Narvaez mailto:dwnarv...@gmail.com Wednesday, May 08, 2013 5:31 AM On 8 May 2013 06:02, William Orr w...@worrbase.com mailto:w...@worrbase.com wrote: I've done some initial work on both sugar and sugar-toolkit-gtk3 with respect to PEP8. I've also added support for PEP8 in make check for both packages. Pull requests are here: https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/25 https://github.com/sugarlabs/sugar/pull/49 Let me know if I need to make any changes. Awesome! Thanks for working on this! I didn't go through all the changes yet, but I have one general concern. You have disabled E501 (line too long), which would be fine as an intermediate step, though you seem to be regressing line length when fixing the other issues. Perhaps it make sense to do the E501 changes together so that we avoid regressions? If you end up reworking the patches it might also make sense to split them up a bit more (even arbitrarily) just to review/land more gradually and diminish a bit the risk of conflicts etc. I don't expect the review to be particularly complicated, though there are a few odd cases with line continuations that we will need to check/discuss/tweak. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel William Orr mailto:w...@worrbase.com Wednesday, May 08, 2013 12:02 AM I've done some initial work on both sugar and sugar-toolkit-gtk3 with respect to PEP8. I've also added support for PEP8 in make check for both packages. Pull requests are here: https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/25 https://github.com/sugarlabs/sugar/pull/49 Let me know if I need to make any changes. Thanks, William Orr Daniel Narvaez mailto:dwnarv...@gmail.com Tuesday, May 07, 2013 8:39 AM Hello, we are now automatically checking sugar and sugar-toolkit-gtk3 using pyflakes. Please make sure your patches are pyflakes clean, so that we don't break the build. (Running make check before pushing is a good way to ensure it). I'm planning to do the same with pep8, help with making the code pep8 clean would be very appreciated. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Hello, Obviously, before submitting I ran the unit tests and did a make run and performed basic tasks. I know this doesn't uncover all errors, but I just wanted you all to know I wasn't just submitting untested code. Provided unit test coverage is good (I haven't looked at the unit test suites yet), everything is probably kosher. Regarding the logic changes, those are reported as pep8 errors according the pep8 tool, which is why they were changed. I did my best to preserve the original meaning, as well as to include them as a separate (second) commit. One thing I can
Re: [Sugar-devel] Automated pyflakes checking
Daniel Narvaez mailto:dwnarv...@gmail.com Tuesday, May 07, 2013 8:39 AM Hello, we are now automatically checking sugar and sugar-toolkit-gtk3 using pyflakes. Please make sure your patches are pyflakes clean, so that we don't break the build. (Running make check before pushing is a good way to ensure it). I'm planning to do the same with pep8, help with making the code pep8 clean would be very appreciated. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel I've done some initial work on both sugar and sugar-toolkit-gtk3 with respect to PEP8. I've also added support for PEP8 in make check for both packages. Pull requests are here: https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/25 https://github.com/sugarlabs/sugar/pull/49 Let me know if I need to make any changes. Thanks, William Orr ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Problems with `make run`
Hello all, I've successfully built sugar with sugar-build, however now, when I try and do a `make run` the screen flashes black and fails to run sugar. I'm on Fedora 19 x86_64. Here is the output of logs/run.log: http://paste.fedoraproject.org/9938/67465897/ Thanks, William Orr ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)
I'm pretty new to the mailing list and the project, but I'm pretty sure that starting a new Chrome instance for every launched activity is far too taxing for the XOs. I think that Lionel's idea of using a Python activity that uses the WebKit WebView is a much, much better solution. lio...@olpc-france.org April 12, 2013 4:36 PM Hi Daniel,Impressive idea with a cool architecture. BTW, to be honest I think its too complex.Why not just create a standard Python activity template that call the WebKit WebView? Like we do today.But maybe I miss something or maybe we dont speak of the same thing?When I wrote the GSoC proposal, I think to a two steps process.What I call the first step is just to create an activity template with a full screen WebView control and a Sugar to _javascript_.So its like my work on Enyo today but:- With a better way than console-message to communicate between _javascript_ Sugar,- With a _javascript_/CSS framework to reproduce in HTML5 the Sugar LookFeel and sugar.graphics stuff,- With a _javascript_ framework that allow calling all Sugar features (telepathy, data store, l10n, dragdrop, ).We could probably do all these things without lot of change on current Sugar implementation and current Sugar activity way of working. In my mind, this could work even on Sugar 0.96-0.98 without any change!Except if Im wrong, what youre currently describe is the second step: upgrading Sugar to support directly HTML5 activities.In this second step we could imagine that Sugar will be very different than today (may be an Android layer or a Chromium layer) and that no current Python activities will work on it. BTW HTML5 activities built with the first step framework should be very easy to adapt: just need to change the _javascript_ framework implementation to use natives features instead of Sugar Python features (for example: call HTML5 storage instead of Datastore storage) and remove the XO Manifest/Package. I do like your architecture proposal for this second step but its difficult to me to think to this second step without weve got a more precise view of the first step. Lionel.De: Daniel Narvaez [mailto:dwnarv...@gmail.com] Envoy: jeudi 11 avril 2013 21:52: sugar-devel@lists.sugarlabs.orgCc: Lionel LaskObjet: Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)Hello,I spent some time today thinking and experimenting with Chromium integration and I have a more detailed plan to propose now.There is an important premise to be made. In both Chromium and Firefox OS, application's installation is very much in the hands of the web browser. It happens as the result of a user clicking on a button, inside a web store. Chromium is a bit more flexible but the other possibilities are basically just developer tools.I think this limits our possibilities a lot. We need to use the browser applications management, rather then installing applications ourselves and then launching them with some command line option. Of course Chromium is open source and we could develop the stuff which is missing. But, in my opinion it's just too much work and it's going to be a pain to maintain in the future, core developers are not going to care about it, given it's not important for their products.That said, I think I mostly figured out a plan to integrate with Chromium web apps management, without having to write a lot of code.* Chromium is started up with the sugar session, using the --no-startup-window, to make it invisible. The sugar extension has a "background" permission, which will keep it running even with no windows.* The extension runs a python script, using chrome.runtime.connectNative. Communication uses json-rpc wrapped in the message protocol supported by the extension. The python script fetches the list of installed activities (as exposed by chrome.management.getAll) and listen to changes.* The python script exposes a dbus service, allowing the sugar shell to get the list of installed applications and to display icons for them in the home. We use GIOChannel to read stdin, so that we don't block and integrate with the glib mainloop.* When the user click on an icon, a LaunchApplication is called on the dbus service, which proxies it to the extension, which launches the application. We will probably need a trivial patch to chromium to start it without UI. There is already a define for chromeos, but it's a compile time thing (in extension_prefs.cc, GetLaunchContainer).* The shell notices that a new window has been opened and associates it with the application information. This allows to activate and close the activity as necessary.* Uninstalling an activity works in the same way as launching. Shell - python script - extension.* Implementation of collaboration and datastore libraries could also be based on the python script messaging.I implemented (badly) a good part of this and I didn't find fundamental
[Sugar-devel] Sugar networking
Hello, I emailed this list some time ago about fixing Sugar bugs for my H/FOSS class at RIT. Matt and I found some bugs on our own related to the generated network neighborhood and sharing activities over the network. Is it worth our time and valuable to the community to start squashing these bugs? Or is there something more valuable we could be doing? We noticed there's a lot of talk about migrating activities over to HTML5, but we're concerned that the work we could do on that would not fit into the timeline of our class (we need some kind of deliverable in a little over a month). Any help and guidance would be appreciated! ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
