The Unctuous Rants of Leif Andersen

Your Fiduciary Source for Science, Technology, Rants, and Occasional Journalism

Twitter Weekly Updates for 2010-08-01

Aug 1

Posted by Leif Andersen in This Blog | No Comments

Powered by Twitter Tools

Tags:

Twitter Weekly Updates for 2010-07-25

Jul 25

Posted by Leif Andersen in This Blog | No Comments

  • God Hinting At Retirement http://bit.ly/aDsFXb #
  • Watching google Q&A..Q: How will you computer with the iPad? A: Take flash out of froyo? Lol #
  • bleh, compete, not computer…swype fail… #
  • @mrweeeedbirdman Yeah for rolling releases…the thing that anyones me most about ubuntu (the lack thereof) in reply to mrweeeedbirdman #
  • The amazing iphone, and it's intuitive design: http://is.gd/dCOKN #
  • @mrweeeedbirdman So I'm assuming someone who simply removed su and busybox wouldn't work, (after originally installing it), yes? in reply to mrweeeedbirdman #
  • It's times like this I wish I had the doctor's sonic screwdriver…oh wait, there's one in the marketplace…never mind… #
  • Now if only I could actually use it on my phone. ;) #
  • I just beat sonic 2 on my phone…take that people who say you 'need' a hardware keyboard. ;) #

Powered by Twitter Tools

Tags:

Twitter Weekly Updates for 2010-07-18

Jul 18

Posted by Leif Andersen in This Blog | No Comments

  • @drkiki Wow…you what? in reply to drkiki #
  • @ChrisLAS I just listened to the most recent LAS, please don't try to just copy twit, you have so much more potential as your own show. #
  • @ChrisLAS, oh, and it also seemed a bit rushed. ;) #
  • Sad, this makes it almost certain that I will not be buying a droid x: http://is.gd/dpK10 #
  • Well…after some trimming, I'm down to 733 lines… I would still like to get below 500…. #
  • @ChrisLAS For starters:"The Linux news you Love from the people you trust this is the Linux Action Show" unless it was a joke I missed. ;) in reply to ChrisLAS #
  • From #TWiT IRC: I tried…Farmville…discovered all I did was click on things, wait…click on things..I might as well play my dishwasher. #
  • @ChrisLAS Oh good, you had me worried for a moment there. ;) I once started a show called TWIBS (this week in BS), being sick of twiFOO. :) in reply to ChrisLAS #
  • @Bugs5382 Sounds like I feel when I have several thousand frames of demo to render… ugg in reply to Bugs5382 #
  • @graphicall Is it just me, or is your contact us form down? #
  • @graphicall The error: Fatal error: Cannot redeclare tla_ads() (previously declared in… #
  • @graphicall …/nfs/c01/h16/mnt/5695/domains/graphicall.org/html/builds/banner.php:72) in… #
  • @graphicall … /nfs/c01/h16/mnt/5695/domains/graphicall.org/html/builds/banner.php on line 101 #
  • Tweeting from my droid x. #
  • I just had an epiphany about how asymmetric keys work! :) #
  • Woot I got matlab working on my phone #

Powered by Twitter Tools

Tags:

Blender GSoC Week 7 Status

Jul 11

Posted by Leif Andersen in Google, Linux/FLOSS, Programming, Technology | No Comments

Overall, I think this has been a good week.  I worked almost exclusively on the image comparison diff tester this week.  I wrote it in python, and it can actually work independent of blender (although it does assume that blender is on your system, and in your path, although that can be changed with the –blender-bin flag).  This means that the tests folder can be put in a zip, and placed in the same location as where the current regression tests (for blender 2.4x) are located on the website.
As I said last time, the general way to run the tests is by using python run.py.  You can use the -v flag to see the output of blender as it’s rendering it.  Also, it might be possible to avoid even having to download the images at all, by using the recently built –built-tests flag, which, instead of rendering tests, will render the images and store them in the known good folder.  (It uses the version of blender in your path).
Through the use of the –image flag, you can compare any blender image on your harddrive (currently assuming it’s in the right file structure), this allowed me to make other image comparison tests, that compared blend files built by pyunit based tests.  This (along with the hashcode operator I started putting together last week), means that most of the tools for building good unit tests (and regression tests in general), are almost build (I think).  Meaning that now the only missing piece of the puzzle is the one I was working on several weeks ago (without luck), which is:
  • A.  Getting the python API to work in background mode (which blender currently isn’t designed to do).
  • B.  Getting the python API to work properly in foreground mode (lots of stuff in bpy.wm crash.  (At least it did as of a week ago, do to low bandwidth caps here, I won’t’ merge until tomorrow evening (when I get home), so they may have been fixed by now)).
Although Andrea only looked at my code to determine good structure, etc.   I believe that most of the bugs have been removed.  (Although, this is python, and bad code doesn’t show up until someone tries to run it, and I haven’t made regression tests for my regression tests. ;) (at least not yet anyway, and it’s not on my radar in the near future)).
The comparator is also capable of producing animation tests.  However, this code is slightly buggier.  Also, by default, I’m not running the animation tests in the current regression suite, because it takes the running time up from 2:30, to over an hour.  I have a –animation flag, but it doesn’t work at the moment.  (Although the underlying code works, so it’s basically just a matter of plugging the code into the flag).
Finally, because the animation images make the overall file size ~240 MB (as apposed to 30 MB), they are not in the default build.  But rather, the user has two choices, they can either A:  Render Good ones, or B.  Use a hash code (and download images (or generate them) if something goes wrong).  The hash code also work in images.  However, the code for this is only half built.  The test case classes support it, but the surrounding structures don’t use it yet, this shouldn’t be more than an hours worth of work to implement it fully.
Finally, I didn’t do as much work as I would have liked in the HTML output.  Now, rather than using static CSS scripts from sphynx, I now build the CSS in the script itself.  (With the exception of images, I’m not sure how to do that as a python script…well, there is PIL, but I’d sooner put bamboo up my fingernails than make the needed images that way).  Although the output is starting to look like it’s from blender’s website.  (Although the table doesn’t quite fit).  Also, it will only generate images for single images (well, that, and animations, but it only does the first frame).  Eventually, the animations will be clickable, and you can view a separate HTML page for the entire animation, but that’s not built yet.  It shouldn’t be too hard to make, but I keep having to do one or the other thing, so the current implementation is old, and would probably cause the script to crash if used.

Overall, I think this has been a good week.  I worked almost exclusively on the image comparison diff tester this week.  I wrote it in python, and it can actually work independent of blender (although it does assume that blender is on your system, and in your path, although that can be changed with the –blender-bin flag).  This means that the tests folder can be put in a zip, and placed in the same location as where the current regression tests (for blender 2.4x) are located on the website.
As I said last time, the general way to run the tests is by using python run.py.  You can use the -v flag to see the output of blender as it’s rendering it.  Also, it might be possible to avoid even having to download the images at all, by using the recently built –built-tests flag, which, instead of rendering tests, will render the images and store them in the known good folder.  (It uses the version of blender in your path).
Through the use of the –image flag, you can compare any blender image on your harddrive (currently assuming it’s in the right file structure), this allowed me to make other image comparison tests, that compared blend files built by pyunit based tests.  This (along with the hashcode operator I started putting together last week), means that most of the tools for building good unit tests (and regression tests in general), are almost build (I think).  Meaning that now the only missing piece of the puzzle is the one I was working on several weeks ago (without luck), which is:A.  Getting the python API to work in background mode (which blender currently isn’t designed to do).B.  Getting the python API to work properly in foreground mode (lots of stuff in bpy.wm crash.  (At least it did as of a week ago, do to low bandwidth caps here, I won’t’ merge until tomorrow evening (when I get home), so they may have been fixed by now)).

Although Andrea only looked at my code to determine good structure, etc.   I believe that most of the bugs have been removed.  (Although, this is python, and bad code doesn’t show up until someone tries to run it, and I haven’t made regression tests for my regression tests. ;) (at least not yet anyway, and it’s not on my radar in the near future)).
The comparator is also capable of producing animation tests.  However, this code is slightly buggier.  Also, by default, I’m not running the animation tests in the current regression suite, because it takes the running time up from 2:30, to over an hour.  I have a –animation flag, but it doesn’t work at the moment.  (Although the underlying code works, so it’s basically just a matter of plugging the code into the flag).

Finally, because the animation images make the overall file size ~240 MB (as apposed to 30 MB), they are not in the default build.  But rather, the user has two choices, they can either A:  Render Good ones, or B.  Use a hash code (and download images (or generate them) if something goes wrong).  The hash code also work in images.  However, the code for this is only half built.  The test case classes support it, but the surrounding structures don’t use it yet, this shouldn’t be more than an hours worth of work to implement it fully.

Finally, I didn’t do as much work as I would have liked in the HTML output.  Now, rather than using static CSS scripts from sphynx, I now build the CSS in the script itself.  (With the exception of images, I’m not sure how to do that as a python script…well, there is PIL, but I’d sooner put bamboo up my fingernails than make the needed images that way).  Although the output is starting to look like it’s from blender’s website.  (Although the table doesn’t quite fit).  Also, it will only generate images for single images (well, that, and animations, but it only does the first frame).  Eventually, the animations will be clickable, and you can view a separate HTML page for the entire animation, but that’s not built yet.  It shouldn’t be too hard to make, but I keep having to do one or the other thing, so the current implementation is old, and would probably cause the script to crash if used.

Tags: , , ,

Blender GSoC Week 6 Status

Jul 11

Posted by Leif Andersen in Google, Linux/FLOSS, Programming, Technology | No Comments

I’ll try to make this short, as it’s late here.
Even though I got sick this week (it turned out to be just a cold/flu), and went out of town (and still am), I believe that this week has been one of the most productive weeks so far.
This week started off with me implementing some of the GUI features I worked with last week, which is to say I started making the image diff tests into an operator.  (Previously they had been baked into the tests directly).  They could be run from a Tests dropdown menu, although there was non feedback outside of the console, leading the user to believe blender had frozen while the tests were running.  Andrea pointed out that this was pointless, and that it should just be a script.  As such, I started implementing it in all in python 2.x.  The tests can be found in tests/render, and I put together a slight howto on how to run them: http://wiki.blender.org/index.php/User:LeifAndersen/GSoC2010/Howto
Render Tests
The current set of render tests requires PIL, and python 2.x. In order to run them, inside the blender source directory, look in: tests/render. There, you should find a collection of files. While the absolute path of those files doesn’t matter (aka, you could move the tests/render folder anywhere, and it would do just fine), those files must be kept in the same relationship to each other. If blender is already in your system path, just go into the folder, and run python run.py, and the script will take it’s course. If blender is not in your current path, open up run.py, and change the BLENDER_BIN variable to you blender binary, and than run python run.py. You can view the results in the console, otherwise you can see a list of all of the results, as well as diffs, by opening index.html in your web browser.
(my most recent commits have temporarily broken this as an operator, but I will soon fix that).  There is a webpage that is outputted which allows you to easily see the difference between the renders.  In addition, the algorithm for analyzing the images is much improved.
I also moved my tests.hashcode module into an operator (bpy.ops.tests.hashcode()), or Tests->Hashcode.  Although it still only gives feedback in the terminal, and only takes some things into account when making the hashcode.
As far as next week goes, I am going to spend a bit of time with the webpage.  It’s not quite flush with blender’s webpage, but it’s getting closer.  But more importantly, I can see a few more options that would allow the user to get more of the raw data behind the images (which I would assume would make it debug).  Most of this I believe can be written in HTML, but some javascript may be useful.  I also plan to get animations working with these tests, and possibly bringing this back in to work with the blender operator.  I also am going to try to get a lot more feedback this week, and hope to have the tool used soon after.  I will also spend a bit of time getting the hashcode operator to take more into account, as well as giving more feedback to the user.  (As in feedback that’s not only just console output).  I would also work on aggregating the data in the blend file for the user to test, but blender is already capable of that.  Finally, I plan on improving the integration of Ctest and CDash, but that seems trivial to do.

I’ll try to make this short, as it’s late here.
Even though I got sick this week (it turned out to be just a cold/flu), and went out of town (and still am), I believe that this week has been one of the most productive weeks so far.
This week started off with me implementing some of the GUI features I worked with last week, which is to say I started making the image diff tests into an operator.  (Previously they had been baked into the tests directly).  They could be run from a Tests dropdown menu, although there was non feedback outside of the console, leading the user to believe blender had frozen while the tests were running.  Andrea pointed out that this was pointless, and that it should just be a script.  As such, I started implementing it in all in python 2.x.  The tests can be found in tests/render, and I put together a slight howto on how to run them: http://wiki.blender.org/index.php/User:LeifAndersen/GSoC2010/Howto
Render TestsThe current set of render tests requires PIL, and python 2.x. In order to run them, inside the blender source directory, look in: tests/render. There, you should find a collection of files. While the absolute path of those files doesn’t matter (aka, you could move the tests/render folder anywhere, and it would do just fine), those files must be kept in the same relationship to each other. If blender is already in your system path, just go into the folder, and run python run.py, and the script will take it’s course. If blender is not in your current path, open up run.py, and change the BLENDER_BIN variable to you blender binary, and than run python run.py. You can view the results in the console, otherwise you can see a list of all of the results, as well as diffs, by opening index.html in your web browser.
(my most recent commits have temporarily broken this as an operator, but I will soon fix that).  There is a webpage that is outputted which allows you to easily see the difference between the renders.  In addition, the algorithm for analyzing the images is much improved.
I also moved my tests.hashcode module into an operator (bpy.ops.tests.hashcode()), or Tests->Hashcode.  Although it still only gives feedback in the terminal, and only takes some things into account when making the hashcode.
As far as next week goes, I am going to spend a bit of time with the webpage.  It’s not quite flush with blender’s webpage, but it’s getting closer.  But more importantly, I can see a few more options that would allow the user to get more of the raw data behind the images (which I would assume would make it debug).  Most of this I believe can be written in HTML, but some javascript may be useful.  I also plan to get animations working with these tests, and possibly bringing this back in to work with the blender operator.  I also am going to try to get a lot more feedback this week, and hope to have the tool used soon after.  I will also spend a bit of time getting the hashcode operator to take more into account, as well as giving more feedback to the user.  (As in feedback that’s not only just console output).  I would also work on aggregating the data in the blend file for the user to test, but blender is already capable of that.  Finally, I plan on improving the integration of Ctest and CDash, but that seems trivial to do.

Tags: , , ,

Blender GSoC Week 5 Status

Jul 11

Posted by Leif Andersen in Google, Linux/FLOSS, Programming, Technology | No Comments

This week has been one of my better weeks.  As usual, there were a few bumps this week, but not too many.
This week dealt with two things:
1.  Image comparison
2.  UI, and thus wrapping unit tests in operators to insert into the UI.
Per Matt Estela’s recommendation, I tried incorporating Perceptual Image Diff http://pdiff.sourceforge.net/ into the tests to compare images.  The pre-compiled binaries work fine, however, compiling from source presents a bit of a problem, even with all of the listed dependencies installed, it complains that several printf stamens are not declared.  I emailed the developer and am waiting for a response.  This isn’t my main priority.  However, I will keep using PIL until such time as a tool like this works.
Getting tests in blender’s UI represents some challenges that do not exist when using CTest as a testing platform.  First of all, I thought a lot about render tests.  If we use blender’s current set of regression tests that blender has, it shouldn’t be very difficult to create a tool that allows a developer to render a blend file, and than compare it to another image file, and than write another tool to run all of the tests.  The problem is that putting this into the GUI, which requires python 3.  And on top of that, developing a good UI for this sort of thing can also be a bit tricky.  Fortunately though, it still is trivial to wrap up unit tests inside an operator, so ultimately, running the tests won’t be too big of a deal, as apposed to setting them up.  I also toyed with writing the operators required in C, although this isn’t as good of an idea as writing it in python, where we could simply give developers a template file to use for their tests, but it may still prove useful.
Next week should be interesting.  Starting on Wed.  and going to the end of the week after that, I’ll be out of town.  With that being said, I won’t be out of communication, but rather, I’ll probably be spending less time on IRC.  (I’ll still try to attend the usual Sunday meeting, as well as spending an hour or so online though).  I will respond to emails as usual, albeit probably a bit slower.   I’ll post an email specifically about this to this list in case this portion of the review is missed.  I still have more UI stuff planned next week, but mainly merging the UI and rendering algorithms into one fluid tool, at which point I’ll start automating it.

This week has been one of my better weeks.  As usual, there were a few bumps this week, but not too many.
This week dealt with two things:1.  Image comparison2.  UI, and thus wrapping unit tests in operators to insert into the UI.
Per Matt Estela’s recommendation, I tried incorporating Perceptual Image Diff http://pdiff.sourceforge.net/ into the tests to compare images.  The pre-compiled binaries work fine, however, compiling from source presents a bit of a problem, even with all of the listed dependencies installed, it complains that several printf stamens are not declared.  I emailed the developer and am waiting for a response.  This isn’t my main priority.  However, I will keep using PIL until such time as a tool like this works.
Getting tests in blender’s UI represents some challenges that do not exist when using CTest as a testing platform.  First of all, I thought a lot about render tests.  If we use blender’s current set of regression tests that blender has, it shouldn’t be very difficult to create a tool that allows a developer to render a blend file, and than compare it to another image file, and than write another tool to run all of the tests.  The problem is that putting this into the GUI, which requires python 3.  And on top of that, developing a good UI for this sort of thing can also be a bit tricky.  Fortunately though, it still is trivial to wrap up unit tests inside an operator, so ultimately, running the tests won’t be too big of a deal, as apposed to setting them up.  I also toyed with writing the operators required in C, although this isn’t as good of an idea as writing it in python, where we could simply give developers a template file to use for their tests, but it may still prove useful.
Next week should be interesting.  Starting on Wed.  and going to the end of the week after that, I’ll be out of town.  With that being said, I won’t be out of communication, but rather, I’ll probably be spending less time on IRC.  (I’ll still try to attend the usual Sunday meeting, as well as spending an hour or so online though).  I will respond to emails as usual, albeit probably a bit slower.   I’ll post an email specifically about this to this list in case this portion of the review is missed.  I still have more UI stuff planned next week, but mainly merging the UI and rendering algorithms into one fluid tool, at which point I’ll start automating it.

Tags: , ,

Twitter Weekly Updates for 2010-07-11

Jul 11

Posted by Leif Andersen in This Blog | No Comments

  • Clocking in at 300 lines, I begin to wonder if my image comparitor is too large (in one file), especially as I still see ~100 more needed… #

Powered by Twitter Tools

Tags:

Twitter Weekly Updates for 2010-07-04

Jul 4

Posted by Leif Andersen in This Blog | No Comments

  • Woot, my favorite, ~150 lines of untested code… :) #
  • You know what the world needs, a good HTML debugger. Either that, or I should learn to spell border. (As apposed to boarder) #

Powered by Twitter Tools

Tags:

Twitter Weekly Updates for 2010-06-27

Jun 27

Posted by Leif Andersen in This Blog | No Comments

Powered by Twitter Tools

Tags:

Blender and Google Summer of Code (GSoC), Month One Review

Jun 21

Posted by Leif Andersen in Google, Linux/FLOSS, Programming, Technology | No Comments

It’s been almost a month since the official start date of Google Summer of Code, and, per Andrea’s recommendation, now is a good time for a month in review.  This won’t go into great detail, I will leave the weekly reviews for that.

So, just a brief checklist of what has happened:

  1. Project Started
  2. Gtest set up
  3. Pyunit setup
  4. tests module created
  5. Hashtests and image comparison tests built
  6. Learned a lot about how the Blender codebase works
  7. Made some hacks and bug reports with the Blender codebase
  8. Initial work on GUI panel for tests (originally dropped, but recently brought back into the foreground)
  9. CMake now using CTest and CDash to report the project

Read the rest of this entry »

Tags: , , ,