The Unctuous Rants of Leif Andersen

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

Archive for category Technology

The Trash we Create

Aug 24

Posted by Leif Andersen in Technology | No Comments

Today was the first day back at the grind-mill, erm, University.  Originally with a 19 credit hour load, although I’ll be dropping it down to 16 so I can pursue other areas of my life (which is to say, programming, particularly Android Apps, but I’m open to any kind of programming).  At University today though, I saw some interesting things.  On top of realizing that I haven’t studied enough math this summer, I saw James, a person who I tried to help with CS 1410 the year before, reading my blag.  Not only that, but he was reading my Twitter Weekly Update Posts, a post which, in all honesty, didn’t think anyone was interested in.  (I only kept it there for posterity sake, and was looking for a way to remove it from the main feed altogether).  Or rather, I think it was my blag, not to many have this exact layout, although I admit I couldn’t read the text from where I sat.

Then later today, Daniel (another person from school),  said 10.10.10.10.10, a post I shared on Google Reader, which he apparently reads in Buzz.  Along with my blag, my twitter feed, my google status updates, and who knows what else Google thinks is me (and as such, dumps it in there), as well as the few (non-existent) posts that I actually put in buzz itself.  He also said that the weekly twiiter posts seemed somewhat pointless to him.  (Which is to say, he saw my twitter posts, and then saw my weekly twitter updates which is just a reposting on my blag of what I posted, and thinks it’s somewhat dumb).

These situations made me think of two slightly conflicting things.  First, people actually read what I write.  I find this amazing because hardly anyone besides JT, and many spam bots.  I find this amazing as I have almost put this blag in the list of things no one really wants to read, but will serve simply as a personal ID for me, and I was going to start a new blag, specifically dedicated towards programming/business related things, and keep this blag as a personal archive of my content.  But other people besides me, albeit a small group of other people, also find it interesting.  The second thing that I found interesting is all of the waste we’re putting out on the internet.  I didn’t know my twitter feed was getting posted to buzz (I found out later that it was ping.fm that was posting to buzz, not ‘as’ bad), but then I was also putting it on my blag, which was also going to buzz.  Even more, I never even touched buzz, I was just letting my content trickle into there because I didn’t really care.  So, I’m posting multiple things to multiple services, why?  Because I can?  What I really need, is a single point of entry.  Where I can post both short posts, and long, more thought out posts, like these.  I would use wordpress, but the issues is that if I use a lot of really short posts, it clutters up the whole thing, leaving the longer posts, the ones I really care about, harder to find.  I could use Ping.fm, I could even get it to post to wordpress, but I still have the issue about shorter posts becoming taking over the site.  Also, if Ping.fm goes down, I’m sunk.  Then, what about Reader?  I could share something in Google Reader, and it get’s pushed to Buzz, but nothing else, or I could set it up to post on here, but we’re back to square one about shared items covering up the content I really care about.  So, as I’m making this network, I also have to think about how long these services will last, as many of them have changing APIs, and I would like to have a life outside of keeping these tubes clean.  Also, what if I create a loop of death, say for example, I get Ping.fm to post to wordpress.com, and I get wordpress.com to post to ping.fm (via rss), the internet (or at least a little corner of it, until someone noticed and stopped it) would come to a firey ball of death.

In short, I need a better CMS.  Something that I own, but can ping to everyone else.  Something that can also accept pings of its own (from things like google reader or buzz), and re-ping them, but be smart enough not to post things twice.  Or, is all of this like a soap box, and only a few people are actually reading these narcissistic rants, and should we all get off of our soap boxes?  Although again, I did find out today that a few people do read this blag.

Either way, I’ll let you know what I figure out when I do.  And you can tell me what you think in the comments.

Tags: , ,

The Future of Computing is not Cell Phones

Aug 4

Posted by Leif Andersen in Reviews, Technology | No Comments

All over the web, Apple fanboys (aka, ‘tech bloggers’), have been saying that the future of computing is in mobile devices, and that desktop computers are just a utility.  While I admit that that laptops seem to have more functionality to desktops (although to be fair, it may just seem that way to me as I’m a student, a need a mobile computer while I’m on campus), desktops are in no way going to fade out of use.  Not only is it much easier to upgrade desktop computers, and are more powerful than mobile computers, but desktop computers are also more convenient to use in situations where constant movement is not required, allowing for greater productivity.

For example, try typing up this blog post on a desktop or laptop, now try typing it up on your ipad…sure, lug around that bluetooth keyboard if you like, but at that point, you have another device to lug around, and it becomes easier to manage a laptop (with the obvious exception of battery life).  Not only will computer scientists, engineers, and hobbyists/gamers be using desktops in the near future, but other trades such as writing, accounting, film/cgi, and many others.

Some have said that computers have become stagnate with little to no innovation.  This is simply untrue.  While the amount of power in a single core has maxed out, and the number of cores in an architecture is slowing, the amount of heat being generated by these computers (and thus by correlation the amount of math they are doing), is still growing exponentially.  Remember people, there’s more to computing that GHz/Cores/Piping/RISC/etc.  Has it gotten less sexy?  Yes, I will admit that, but remember that ‘sexy’ is not a measure of usage, but more a meter of novelty.  Most of the improvements in computers are not in the outside appearance, but in its internals.  Furthermore, ‘sexy’ can also be directly correlated to the amount of marketing a company has put into it’s products, and as we know, Apple Inc. puts in a tremendous amount of marketing.  But to some people, desktop computers are still ‘sexy’.

This doesn’t mean that mobile computing doesn’t have its place.  I recently bought a droid x (on opening day actually), and I love it.  I love the size (although I wish it was a bit bigger), I love the speed, I love it’s power.  However, I don’t use it as a productivity device (yet, I’m working on getting it set up as a tablet in conjunction with my computer), I use it as a portable media player for places like on the bus and the train, which I spend a lot of time on.  I use it for games, but most of the games I play can run on very old hardware anyway, as well as video/audio, and web browsing/email.  I do admittedly use it for some content creation though, for example the picture in this post is a scaled down version of a picture I took with it.  I also enjoy hearing people talking about mobile computing too.

So, in conclusion, while mobile devices are growing, and can be rather interesting, there is still much innovation going on in the desktop/non-cloud-computing arena.  As such, it would be much more enjoyable to listen to podcast/read blogs that talk about that, rather than the annoying amount of ‘cloud’ news that is produced now days.  As such, if anyone wants to show of their websites/products that are not cloud based in the comments, I would be very appreciative of that, and may even give my opinion of it in a future post.

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: , ,

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: , , ,

Blender GSoC Week 4 Status

Jun 18

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

Overall, I think this week I’ve started to pick up the pace, although not by too much, there’s still plenty of room for lot’s of improvement, but at this point everything is starting to feel like it goes into place, which makes me happy.

I spent a lot of time this week trying to get some of the tests to work in background mode. Unfortunately, several of the needed api calls (saving/loading/rendering/saving images), only work when in regular mode. I also had other problems with API calls not working properly even in the foreground mode, and I’ve done some more hacks on the codebase, and submitted some bug reports, although at this point, I’ve got most of the API calls I need working, albeit they’re still a bit buggy. In the end, we’ve decided to run the tests in the forground (for now), and just run the exit blender api call at the end of the test. The largest problem with this is that if the test segfaults, blender won’t quit, and the user must quit it himself. Also, it’s quite annoying to have a window pop up and close over and over again while running the tests. Thus, as soon as some of the bugs I’ve reported are fixed, I’ll be switching back to background mode.

I’ve also started doing some image comparison tests. I don’t really have any good algorithms yet, so I’m still very open to suggestions. Currently though, I’ve tried several iterations of a histogram comparison. Both comparing all the color bands at the same time, and comparing them separately, the first one is quite a bit faster, although I think that’s do to how I’m using the API calls.

Read the rest of this entry »

Tags: , , , ,

Nintendo 3DS: I Wish I Could Play

Jun 18

Posted by Leif Andersen in Reviews, Technology | 4 Comments

Just a few days ago, Nintendo released their latest hand held gaming device, the Nintendo 3DS. This pains me. Most people complain about all of the gimmicky things such 3d, I, at this point, don’t care that it’s a gimmick, I would just like to see it. Because I have optic nerve hypoplasia, I have very poor optic nerves, in fact, I can’t even see out of my left eye at all. This means that any 3d media experience that depends on the viewer having two eyes, simply doesn’t work for me. When films are color filtered, I cannot even put on the needed glasses, because I only see the tint on filter provides, meaning that everything has odd colors all over the place. If the glasses use light polarization, I do have to where the glasses, to remove one image, but it’s still in 2d, but at least it’s viewable as a 2d film. In fact, as far as I know, the only 3d system for me (besides holograms, and actual 3d objects), is head tracking, and displaying the image with proportion to the head of the observer. The main drawback to this is that only one person can do it at a time.

Now, while the Nintendo 3DS doesn’t require glasses, it still expects the user to have two eyes.  Because I have but the one eye at my disposal, the Nintendo 3DS is not usable to me.

While I am not as outraged as the person in this video, it does encapsulate the spirit of how I feel.

Blender-GSoC-Week 3 Status

Jun 13

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

As mentioned last week, this week consisted mainly of debugging parts of blender. As such, I believe that the amount of actual deliverables I produced this week is much less than it has been the first two weeks. With that being said though, I believe that I have learned more about the blender codebase than the other weeks, by quite a bit. I also found several tricks for the python API that weren’t documented in the API documentation, which should eventually make the tests much cleaner.

This week I started working with tests for operators as apposed to directly with data. The first problem I ran into was the immutability of bpy.context. I was resorting to hacks to change the context, which only was working some of the time. Thus, I went to GTest, giving it more time than I had planned on this week (a little over a day), because the C-API calls took in a bContext, rather than having it be implicit. However, I never managed to get the linking right, any probes I put into the kernel or operators itself would result with many errors, even for functions that seemed to only allocate space, thus I never got a bContext made.

Fortunately ideasman42 pointed out to me that I could pass in a dictionary, and the operators would use that instead of the value in bpy.context. I haven’t gotten it to work in all of the situations I’ve tried (yet), but many have worked, and it does seem promising. However, that only solves some of the tests, it still would be valuable to run tests using bpy.context, or some other type of implicit context, for better code coverage.

One thing that I really didn’t expect this week, was that most of the bugs I was trying to debug this week, were ones that I found. I was planning on looking for bugs on projects.blender.org, and I did find a few, but when I started building python scripts to test them, I found many more simple problems that I had to deal with first, which took most of my time.

My plans for next week:

My first order of business is to get several operators in bpy.ops.wm (mostly found in the windowmanager folder), working in the python console, and in a script (both when blender has a visible, and no visible window). Currently, I’m working on bpy.ops.wm.read_homefile(), and I’ve made some progress. However, the problem is that the bContext that is passed into it has several null elements in the console, which is expected to be non-null for windowmanager operations. Once I’ve finished that, I will finish my setup.py test, and proceed to use that as my setup method, at which point most of my tests module will become superfluous, and I may take some time dealing with that. In fact, I could likely get rid of it, with the one exception of me using it’s hashcode function. I may also read in a pre-built empty file, rather than the default .b.blend file, which could possibly break the tests if the default was changed, which would be very bad. Finally, as a side project, I’m going to start reading up on how the python API’s documentation is made (I know it’s using sphinx, but I don’t know how it works, yet), and I’ll see what I can do to start helping minddrones with that.

Tags: , ,

Android, webOS, and Lifehacker: yet another openness rant

Jun 13

Posted by Leif Andersen in Programming, Technology | No Comments

I recently went on another rant on the Ubuntu forums, you can read it more in context here, also, it is pertaining to a Lifehacker article which you can find here.

And lets not forget the open nature of the platform to allow apps to be written in HTML, CSS, Javascript, or C/C++ if you want

Um…you can write apps in all of those languages for Android, I don’t see how that makes webOS ‘more’ open than android. (Also, the iPhone let’s you use those languages too, well, I don’t know about HTML and CSS, also, I wouldn’t call them ‘languages’).

Android is open source for its core OS and allows installing apps from outside of the marketplace but so does webOS.

Really? I don’t remember webOS being open source. (Call me pedantic, but that’s a poor choice of words, unless webOS really is open source).

Google also loses by making their “default” apps (Gmail, Maps, etc.) completely closed source and even takes down anyone who tries to share them. Palm on the other hand has written every built in app according to the standards they hold their developers to and made the apps all open source so you could see exactly how they built the app.

Sure, some of the apps are closed, but others are open, such as the web browser, and the home app. Also, Google does make their default apps using the SAME sdk, using the SAME APIs that developers have access to. (Granted, they did make the APIs). So, the only company that you can hold that argument to (out of the three), is Apple, who has their own ‘special’ APIs that only they can use.

Android and webOS are both fairly open, but webOS is more open and is the winner here.

I can’t argue that, as I haven’t actually used webOS (or researched it much), the only reason I could argue the other points is because I’m only pointing inaccuracies they have about android, and taking their comments on webOS at face value.

Okay, I’m done, not going to go onto the other points…if it makes you feel any better, when I read the original article several days ago, I also got to the keyboard section and stopped. It claimed to be a review for ‘power users’, and started complaining about the ‘out-of-the-box’ keyboard. It would be okay if they said it was just a regular review for regular users, or if the keyboard was a bit tricky to install (compiling it from source etc. etc), but as long as the keyboard is only a trip to the market place, and another button click away, you can’t claim to be a review for ‘power users’, and talk about the ‘out-of-the-box’ experience like that (well, you can, but I’ll think it’s dumb ).

I’m not saying Android’s better than webOS, as I said, I haven’t tried webOS, so it might be, but that article wasn’t very good, in my opinion anyway.

Tags: , , ,