The roads I take...
KaiRo's weBlog
| Zeige Beiträge veröffentlicht im August 2008 an. Zurück zu allen aktuellen Beiträgen | |||||||||||||||||||||||||||||||||||||||||||
25. August 2008
Weekly Status Report, W34/2008
Here's a summary of SeaMonkey/Mozilla-related work I've done in week 34/2008 (August 18 - 24, 2008):
The bugzilla.mozilla.org reorganization has been done during the Mozilla Summit, we now have a "SeaMonkey" product there, and I posted about new queries for SeaMonkey bug triage - please help us to get those sorted out, especially the UNCONFIRMED bugs and the ones in the "General" component need immediate work, in the longer term it would be nice to also clean out the huge list of really old bugs.
Every bugs the gets resorted to the right component or resolved counts, as it makes the real issues easier to find for the developers - thanks for your help on that work!
- Build System Work:
Now that we have our own build system in comm-central, I worked on keeping up with build system changes.
It's easy to lose track of the files we're packaging into our installers, zips and tarballs, so I added a package-compare build target that does a diff of files listed in the package manifest and the dist/bin directory. I also did a first set of packaging fixes based on the findings of those diffs. - Build/Test Machines:
I added the setting to correct tinderbox parsing of unit test logs, tried to get leak thresholds to work for the mochitests and added a build step to builders to report the package diffs. - xpfe Cleanup:
The huge patch for cleaning up xpfe/ could land, all but one file of xpfe/global and xpfe/communicator are gone from from mozilla-central. I have one more patch to complete what can be cleaned up there now and filed bugs for killing both MOZILLA_LOCALE_VERSION and MOZ_XUL_APP - the former is old and now unneeded, the latter is the default with nothing else supported any more, so we can remove all code only used when it's unset and then remove the flag itself. - L10n:
Even though we don't have localized builds for trunk yet, I added lt and pt-BR to all-locales. They'll get included once we get L10n builds from comm-central. - Various Discussions:
client.py improvements, compare-locales, comm-central build system ownership, shell service UI, release schedules, more bmo reorg, etc.
The bugzilla.mozilla.org reorganization has been done during the Mozilla Summit, we now have a "SeaMonkey" product there, and I posted about new queries for SeaMonkey bug triage - please help us to get those sorted out, especially the UNCONFIRMED bugs and the ones in the "General" component need immediate work, in the longer term it would be nice to also clean out the huge list of really old bugs.
Every bugs the gets resorted to the right component or resolved counts, as it makes the real issues easier to find for the developers - thanks for your help on that work!
Von KaiRo, um 03:32 | Tags: L10n, Mozilla, SeaMonkey, Status | keine Kommentare | TrackBack: 2
23. August 2008
KaiRo.at Mandelbrot Going Public
As comments to yesterday's post about TraceMonkey suggested I should show my code so the JIT code could be improved for things like what I'm doing, I decided to go all the way and publish this today.
I just completed putting all my code of this project under the Mozilla tri-license and making it available via both a gitweb interface and for cloning with
That said, a few details about the application itself:
This is a fun side project, its main target is for me to learn XULRunner and improve my skills with the used technologies. Its second target is to recreate an application I had started for my my final paper in school with modern technologies.
The application renders images of the Mandelbrot set fractal, the original application had nice zoom functionality and could even render the very similarly calculated family of Julia set fractals, which are both features I want to add incrementally to this XULRunner-based version as well.
The current versions calls itself "KaiRo.at Mandelbrot 4pre", which probably warrants a short view on the version history: The first version, "RK-Mandelbrot 1.0" was created in Visual Basic 3 during work on that school paper, I incremented the minor version number as I went along with that work, the version I had on a disk coming with the paper was "RK-Mandelbrot 2.0", this or a slight minor update to it was also used during the presentation/exam on that paper. I later updated it to Visual Basic 5 and played with a few features, calling the result "KaiRo-Mandelbrot 3.0", also noting the change from using my initials to the "KaiRo" name for my work. Because of this history, I'm targeting a version number of 4.0 for the XULRunner rewrite, and also using "KaiRo.at" as the vendor name, as that's also what I'm using as my corporation name prefix.
Some comments on the current code:
On the base level, I created a
In the running app (the launch script also launches the error console for debugging), the
The image you'll get with the default settings of max. 500 iterations and my custom "KaiRo.at" color palette looks like this:
Once I can do a zoom function, I hope I can produce more interesting images - I'll publish a number of them in the gallery.
There's a lot that probably can be improved in that app, it's just a fun personal playground, as I said. But if anyone wants to look into what it does and perhaps see how TraceMonkey could perform better on it, feel free to look into it, the source is all open!
I just completed putting all my code of this project under the Mozilla tri-license and making it available via both a gitweb interface and for cloning with
git clone http://git-public.kairo.at/mandelbrot.git.That said, a few details about the application itself:
This is a fun side project, its main target is for me to learn XULRunner and improve my skills with the used technologies. Its second target is to recreate an application I had started for my my final paper in school with modern technologies.
The application renders images of the Mandelbrot set fractal, the original application had nice zoom functionality and could even render the very similarly calculated family of Julia set fractals, which are both features I want to add incrementally to this XULRunner-based version as well.
The current versions calls itself "KaiRo.at Mandelbrot 4pre", which probably warrants a short view on the version history: The first version, "RK-Mandelbrot 1.0" was created in Visual Basic 3 during work on that school paper, I incremented the minor version number as I went along with that work, the version I had on a disk coming with the paper was "RK-Mandelbrot 2.0", this or a slight minor update to it was also used during the presentation/exam on that paper. I later updated it to Visual Basic 5 and played with a few features, calling the result "KaiRo-Mandelbrot 3.0", also noting the change from using my initials to the "KaiRo" name for my work. Because of this history, I'm targeting a version number of 4.0 for the XULRunner rewrite, and also using "KaiRo.at" as the vendor name, as that's also what I'm using as my corporation name prefix.
Some comments on the current code:
On the base level, I created a
mandelbrot launch script, which tires to find a XULRunner in a few places and uses it to launch the app using the application.ini inside the xulapp directory, which contains files in the usual structure for XULRunner apps.In the running app (the launch script also launches the error console for debugging), the
File menu enables access to drawing the image, saving it (very ugly right now, hardcoding /home/robert/temp/canvas-save.png as the path!) and quitting the app. The Settings enables different settings for maximum number of iterations (I'm using a simple escape time algorithm) and color palettes (which are currently stretched according to the max iterations number; also, I have not ported all palettes I had in the VB version, leaving the non-ported ones in an ugly comment in the JS file). Today, I also added a Debug menu that allows switching TraceMonkey on and off and switching between the slow but nice-looking object-oriented algorithm and the faster but not so pretty numeric algorithm. I also added a label at the bottom of the window that informs about the currently performed action and a rough time measurement when drawing is complete.The image you'll get with the default settings of max. 500 iterations and my custom "KaiRo.at" color palette looks like this:
Once I can do a zoom function, I hope I can produce more interesting images - I'll publish a number of them in the gallery.
There's a lot that probably can be improved in that app, it's just a fun personal playground, as I said. But if anyone wants to look into what it does and perhaps see how TraceMonkey could perform better on it, feel free to look into it, the source is all open!
Von KaiRo, um 19:39 | Tags: Mandelbrot, Mozilla, XULRunner | 6 Kommentare | TrackBack: 1
How Fast Is TraceMonkey In Real World?
Everybody is writing about TraceMonkey today, the just-landed-on-trunk version of the SpiderMonkey JavaScript engine with "tracing" JIT compilation for speeding up code that is run repeatedly.
What I wondered is how fast it is in code that is no benchmark but stuff a real application might use. And as I have my "Mandelbrot" fun project as a XULRunner app (see the last paragraph of recent status update post), which naturally does a lot of looping over the same equation, so I thought it might be a good candidate for optimization.
So I fired up the XULRunner app, doing four testruns of "time mandelbrot" (launching a script that runs my XULRunner build from today's trunk code under primitive unix time measuring) and looked at the amount of user and sys time used. I didn't want professional benchmarks, I wanted just a rough estimate of real world numbers, so it was OK that I needed to manually click the "Draw Image" button and manually click "File > Quit" once the CPU usage came down from fully using one core. I only wanted rough numbers to see if there's a visible difference, so I could live with those deficiencies and rounded the average of two runs roughly.
For the unoptimized, heavily JS-object-based approach I already had last week, I got a number that was about the same as I estimated previously - about 96 +/- 2 seconds. When I turned on the
But even though
Having that code activated, I turned on TraceMonkey once again. And now, it really helped: 7 +/- 0.2 seconds! That's about 30% faster!
For already optimized, pure JS math code (which is probably more real-world than nice-looking object stacking), squeezing even 30% more performance out of this calculation is surely nice!
Still, running my old Visual Basic 5 application under Wine has, apart from more features, two advantages to this XULRunner app: For one, it updates the image frame in the UI during calculation and not only at the end of execution, which is better felt performance as you see what it's doing. For the other, it's still 20% faster, using about 5.6 +/- 0.2 seconds with the same instrumentation - and that though people say VB is so slow. Bummer.
So, good work done, TraceMonkey friends. But there's still more potential to use the CPU more efficiently. Keep on the good work!
What I wondered is how fast it is in code that is no benchmark but stuff a real application might use. And as I have my "Mandelbrot" fun project as a XULRunner app (see the last paragraph of recent status update post), which naturally does a lot of looping over the same equation, so I thought it might be a good candidate for optimization.
So I fired up the XULRunner app, doing four testruns of "time mandelbrot" (launching a script that runs my XULRunner build from today's trunk code under primitive unix time measuring) and looked at the amount of user and sys time used. I didn't want professional benchmarks, I wanted just a rough estimate of real world numbers, so it was OK that I needed to manually click the "Draw Image" button and manually click "File > Quit" once the CPU usage came down from fully using one core. I only wanted rough numbers to see if there's a visible difference, so I could live with those deficiencies and rounded the average of two runs roughly.
For the unoptimized, heavily JS-object-based approach I already had last week, I got a number that was about the same as I estimated previously - about 96 +/- 2 seconds. When I turned on the
javascript.options.jit.chrome pref to run it with TraceMonkey, I saw no difference though, still the same, quite slow run time.But even though
Z = Z.square().add(aC); looks good for the Z = Z² + C equation, it's not that efficient to do two JS object creations for every iteration, so earlier in the week, I replaced that nice code with pure math and simple variables only. That helped performance a lot and saved about 90% of the time, cutting it down to about 9.4 +/- a half seconds.Having that code activated, I turned on TraceMonkey once again. And now, it really helped: 7 +/- 0.2 seconds! That's about 30% faster!
For already optimized, pure JS math code (which is probably more real-world than nice-looking object stacking), squeezing even 30% more performance out of this calculation is surely nice!
Still, running my old Visual Basic 5 application under Wine has, apart from more features, two advantages to this XULRunner app: For one, it updates the image frame in the UI during calculation and not only at the end of execution, which is better felt performance as you see what it's doing. For the other, it's still 20% faster, using about 5.6 +/- 0.2 seconds with the same instrumentation - and that though people say VB is so slow. Bummer.
So, good work done, TraceMonkey friends. But there's still more potential to use the CPU more efficiently. Keep on the good work!
Von KaiRo, um 03:45 | Tags: JavaScript, Mandelbrot, Mozilla | 4 Kommentare | TrackBack: 3
18. August 2008
Weekly Status Report, W33/2008
Here's a summary of SeaMonkey/Mozilla-related work I've done in week 33/2008 (August 11 - 17, 2008):
As a fun side project, I have started work on a new version of my old "Mandelbrot" application I did for my final paper in school, back then in Visual Basic. The application renders images of the Mandelbrot set fractal, the original application had nice zoom functionality and could even render the very similarly calculated family of Julia set fractals.
The difference this time is that this is a XULRunner application, rendering images into a <canvas> HTML element.
After getting rid of a number of early bugs in my code, this is (a thumbnail of) the first image I rendered with the color palette I ported from my old code:
The application is still quite primitive and unfortunately the JavaScript/canvas combination isn't the fastest way to do the math and paint the picture - the default 300x300 overview picture currently takes ~90 seconds of one of my Conroe cores being busy until it displays. When I get farther down the road with what I want from this app, I probably will open-source the code under the tri-license. This is mainly an educational project for me to learn how to do such a XULRunner app. Don't expect a finished app and/or something to try out yourself too soon though, this is just a fun side project - my main focus is of course on SeaMonkey!
- Vacation Catch-Up:
I spent a huge amount of time this week catching up on things that happened during my vacation and partly the Mozilla Summit, am done with all my digging through bugmail, newsgroups, planet, pushlogs and most of the normal email and started some real work again. - Mercurial Move Followup:
Catching up my the pushlog feeds on the mozilla buildsystem files we've copied in modified ways to comm-central, I ported recent fixes to our versions already, with more under review.
Additionally, --disable-compile-environment should work now (used in some L10n docs). - Build/Test Machines:
I've made a patch that should allow us to have our unit test boxes go green even though we have known leaks. We'll set thresholds to allow the current amounts of leaks without failure so we at least reliably catch when leaks increase. We'll adapt those thresholds values as possible when leaks get fixed, so that we'll hopefully only go down but not up with what we allow.
We're also working on getting Justin Wood (Callek on IRC) access to our build machines, so that he can act as a backup when I'm not around (like recently, when they broke while I was on vacation). - Bugzilla's SeaMonkey Product:
Now that the big bugzilla.mozilla.org reorganization has been done and we have a product named "SeaMonkey", we still need to see that component info gets updated and missing components are created.
Also, we have new bug triage targets and would like people to participate in killing off and/or improving our bug reports! - xpfe Cleanup:
With the new situation of only toolkit applications being based on trunk, I started work on cleaning up xpfe/ again, the first patch removes all but one file of xpfe/global and xpfe/communicator from mozilla-central. - German L10n:
I worked on resyching the German hg repo with hg trunk code together with my de team colleagues, along with fixing linebreak error made obvious by the new MozillaTranslator version and a typo.
Also, I could verify that the existing Makefile targets produce working German langpacks and tarballs for SeaMonkey - I hope we'll have the buildbot infrastructure soon to do automated localized SeaMonkey builds again. - Various Discussions:
Message view pane, separate DOM inspector repo in hg, planning of upcoming milestones and releases, SeaMonkey Status Meeting, etc.
As a fun side project, I have started work on a new version of my old "Mandelbrot" application I did for my final paper in school, back then in Visual Basic. The application renders images of the Mandelbrot set fractal, the original application had nice zoom functionality and could even render the very similarly calculated family of Julia set fractals.
The difference this time is that this is a XULRunner application, rendering images into a <canvas> HTML element.
After getting rid of a number of early bugs in my code, this is (a thumbnail of) the first image I rendered with the color palette I ported from my old code:
The application is still quite primitive and unfortunately the JavaScript/canvas combination isn't the fastest way to do the math and paint the picture - the default 300x300 overview picture currently takes ~90 seconds of one of my Conroe cores being busy until it displays. When I get farther down the road with what I want from this app, I probably will open-source the code under the tri-license. This is mainly an educational project for me to learn how to do such a XULRunner app. Don't expect a finished app and/or something to try out yourself too soon though, this is just a fun side project - my main focus is of course on SeaMonkey!
Von KaiRo, um 04:10 | Tags: L10n, Mandelbrot, Mozilla, SeaMonkey, Status | 3 Kommentare | TrackBack: 1
16. August 2008
Your next comm-central pull will break! Pull again to fix!
As Justin Wood (Callek) just checked in the move of DOM inspector to its own hg repo, your next pull of comm-central will probably error out in client.py because it needs to pull the removal of inspector from mozilla-central before it tries to add the new dom-inspector repo in the place of the previous code.
Another run of client.py should fix this again and you can pull as before.
Thanks to Justin for taking over the completion of this task!
Another run of client.py should fix this again and you can pull as before.
Thanks to Justin for taking over the completion of this task!
Von KaiRo, um 02:08 | Tags: comm-central, DOM Inspector, Mozilla, SeaMonkey | keine Kommentare | TrackBack: 0
12. August 2008
Weekly Status Report, W30/2008
Here's a very very late summary of SeaMonkey/Mozilla-related work I've done in week 30/2008 (July 21 - 27, 2008):
Sorry for this arriving that late, but I didn't get around to doing it when I was preparing for or at the Mozilla Summit, and of course not in vacation.
The Summit itself was a very successful event, mainly of connecting with people and meeting people face-to-face that I only knew the names of or had email/IRC/bugzilla contact before. The sessions were also interesting, though there were too many things I would have wanted to be at in parallel. Oh, and we had a very fruitful, long and late breakout session about release automation on Mercurial, the processes that will be set up will be made in a way that they can work with Thunderbird, SeaMonkey and Sunbird from the beginning. Thanks to the MoCo build & release team for including us there and making this possible.
I'm still digging through lots of backlog from those two weeks, so expect it to take some time still until I'm back to normal reaction times on whatever issues are out there.
And yes, the first alpha is definitely nearing, target is early to mid September now, nearly in sync with Thunderbird 3 beta 1.
- SeaMonkey & Thunderbird on Mercurial:
The switch to Mercurial was the big story of that week, including the new comm-central build system. Everything has worked fine, SeaMonkey's build machines were updated smoothly, unit test machines are a bit bumpier and still see test failures due to new code in 1.9.1 that we didn't have on cvs trunk before.
I also reviewed a couple of followups on client.py and did a few related changes after the switch myself. - SeaMonkey on Maemo:
This was just a fun thing to try out and is not a project we have plans to follow up with, but I've done a Maemo build an could actually run SeaMonkey on my N810! Even if there are some slight problems around there, I find SeaMonkey's ChatZilla more usable on it than the Pidgin IRC client adapted for that platform. - L10n:
As mentioned before, lost L10n builds on SeaMonkey trunk for the time being with the switch to Mercurial. We're planning to reinstate them as soon as the new processes for 1.9.1 are in place and we can adopt them. - Various Discussions:
Mozilla Summit, Mercurial move, etc.
Sorry for this arriving that late, but I didn't get around to doing it when I was preparing for or at the Mozilla Summit, and of course not in vacation.
The Summit itself was a very successful event, mainly of connecting with people and meeting people face-to-face that I only knew the names of or had email/IRC/bugzilla contact before. The sessions were also interesting, though there were too many things I would have wanted to be at in parallel. Oh, and we had a very fruitful, long and late breakout session about release automation on Mercurial, the processes that will be set up will be made in a way that they can work with Thunderbird, SeaMonkey and Sunbird from the beginning. Thanks to the MoCo build & release team for including us there and making this possible.
I'm still digging through lots of backlog from those two weeks, so expect it to take some time still until I'm back to normal reaction times on whatever issues are out there.
And yes, the first alpha is definitely nearing, target is early to mid September now, nearly in sync with Thunderbird 3 beta 1.
Von KaiRo, um 17:10 | Tags: L10n, Mozilla, SeaMonkey, Status | 1 Kommentar | TrackBack: 2
11. August 2008
Back But Lots Of Catch-Up To Do
So, I'm back from my Summit+vacation Canada/USA tour, after the long bus ride from Whistler to Vancouver I'm sure you heard about or were on, I spent another week in the lower Fraser Valley (i.e. the almost flat land between Vancouver and Chilliwack and the Western half of Washington state. I took lots of walks, did a huge amount of sightseeing, had a very good time and took over a thousand pictures, a selection of which I will upload to my site some time in the next few weeks.
I still need to catch up on email, bugs, planet and newsgroups even though a glanced over most of the email at nights in the hotels (thanks to Best Western for having free Internet on all their hotels!) - but there's so much going on in our community that I probably need some time to be fully back to normal.
Oh, and I didn't even do a Status Update for the week before the Summit...
Well, I'm even planning on catching up on that.
I still need to catch up on email, bugs, planet and newsgroups even though a glanced over most of the email at nights in the hotels (thanks to Best Western for having free Internet on all their hotels!) - but there's so much going on in our community that I probably need some time to be fully back to normal.
Oh, and I didn't even do a Status Update for the week before the Summit...
Well, I'm even planning on catching up on that.
Von KaiRo, um 18:16 | Tags: Canada, moz08, Mozilla, travel, USA, WA | keine Kommentare | TrackBack: 0
1. August 2008
We're Not Dead! Yet.
So, apparently, a laundry trunk crashed into the hotel's power transformator and that's why I needed to shower almost in the dark, after getting the message yesterday that a rockslide causes our trip to Vancouver being about 5 hours longer than expected.
When I had showered, I turned on my N810 though and it promptly connected to wifi (which was running on emergency power apparently), so I knew we were still alive. Losing wifi probably would have been much more fatal to this community than losing power in the rooms.
Let's just see what happens tonight when we have dinner on the top of the mountain and tomorrow when we're traveling the long route back - right through a place called "Hell's Gate"...
When I had showered, I turned on my N810 though and it promptly connected to wifi (which was running on emergency power apparently), so I knew we were still alive. Losing wifi probably would have been much more fatal to this community than losing power in the rooms.
Let's just see what happens tonight when we have dinner on the top of the mountain and tomorrow when we're traveling the long route back - right through a place called "Hell's Gate"...
Von KaiRo, um 02:08 | Tags: moz08, Mozilla, Whistler | keine Kommentare | TrackBack: 0
