jump to navigation

Ancient V.S. Contemporary Comedies January 28, 2010

Posted by Andor Saga in Reading.
add a comment

Something I noticed while reading Lysistrata is that it was actually funny, and I enjoyed it quite a bit. Maybe it’s my taste, but I find contemporary comedies (movies) are just terrible. All the comedies my friends like, I hardly find humorous. Which makes it interesting how a play written a few thousand years ago can stay timeless and still make someone laugh. Maybe there are some good contemporary comedic plays around. I’ll have to look into this.


3D Processing.js Development Deadlock January 28, 2010

Posted by Andor Saga in Open Source, Processing.js.
add a comment

A few days ago I blogged about the problem of adding 3D to the Processing.js library. After I wrote the blog, I knew I needed to dig a bit further. A blog was okay, but I needed more. So I began the terribly confusing task of trying to categorize functions into releases and delegate the work so each developer doesn’t rely on other concurrently developing code. After I had something workable on paper, I posted it on our wiki page so it can be reviewed by the rest of the Processing.js team.


The main issue is there’s a bit of a deadlock for release 0.5. Anna is responsible for the box() function which renders a box in the scene. That function depends on Mickael’s camera() and perspective() functions, which are difficult to test without rendering something! I think to begin with, we’ll all have to work together (as in the same room) to figure all this out. Hopefully this week’s Processing.js team meeting will clear up some things.

Preliminary Plan For 3D in Processing.js January 26, 2010

Posted by Andor Saga in Open Source, Processing.js.

I was talking to Dave Humphrey on IRC about the state of the tickets which involve adding 3D functionality to the Processing.js library. And well, things are a bit hectic right now. We have a slew of tickets in lighthouse which need review, 3D dependencies haven’t been identified. We have code for drawing spheres and boxes, but no camera or perspective code checked in. All this needs some serious attention. What we need to do is identify what the dependencies are and focus our energy on getting those tickets checked in. Once that’s done, we can begin working on getting our other tickets ready for review.

Our next release is happening on the 5th. By that time we need to get a whole bunch of things ready for super review. The question is which parts? I have identified the blocking code here.


Let’s start with this object. This isn’t used by Processing.js scripts directly. It’s an internal structure for us developers working on the Pjs library. Once we have parts of it written we can all benefit from the tested code it provides. The problem is it’s huge. It has functions to scale, rotate, translate, skew, invert, etc. Luckily for us, since it isn’t exposed to users writing sketches, we can omit the functions of the class which aren’t mandatory and we can focus on the core elements, which are only a handful of functions. I believe we should concentrate on those, get the basics in then worry about the rest. I’ve tried to limit the code to the absolute minimum since the more function we add, the more tests are required. The more tests we need, the further back the release gets pushed. I want a substantial amount to get pushed, but no more than necessary. So these are the functions which need attention:

set() – Sets the matrix
mult() – Multiplies a vector by a matrix
apply() – Multiplies the matrix with another matrix

Yes, this is a very short list and I’m leaving out a whole bunch of functions. I’m even leaving out trivial code like transpose and reset (which sets the matrix to an identity matrix). These will need to get done manually until we have a test. Without a test, I don’t want to put it up for super review. We can still do translations, rotations and whatever by specifying our own matrices and calling apply(), so it still provides enough functionality to do some work.

On one hand, I don’t want to stunt the development of adding 3D to Processing.js, but I also don’t want us to push buggy code. That could leave someone scratching their head for hours because they think our code works when in fact it has a bug. I’m drawing the line at these functions. If someone notices we need another one, we’ll need a test for it. The code for these have already been written, now we have to delegate the work of writing the tests.

  • Write tests for set(), mult() and apply()


camera() ticket

The camera() function places a virtual camera in the scene. It describes where the camera is, where it’s pointing and it’s ‘up’ direction. By default, this is called when a user creates a 3D scene, this makes the implementation an absolute must and of high dependency. Even if we don’t have any objects rendered, we need this guy landed.

Luckily Mickael Medel has already written the JavaScript implementation of camera(), it just requires fixing, debugging and a test. While I was reviewing the code, I saw it depends on PVector, but that’s fine since PVector has already been checked in. Nice.

  • Fix bugs
  • Write a test for camera()


perspective() ticket

Perspective creates a viewing volume. When objects are placed ‘inside’ this volume, they appear as they do in real life. That is, when they are farther from the camera, they appear smaller. The code is written, we just need to fix, debug and write a test. Like camera(), this function is a must since it is called by default (I even checked the Processing code to make absolute sure). Perspective in turn calls frustum().

  • Fix bugs
  • Write a test for perspective()


frustum() ticket

This allows you to create the viewing volume directly with more control over the final ‘shape’ of the volume compared to perspective(). Not only is this called by perspective, but users can call it directly. So this is also of high priority. Fortunately for us, the code is quite simple and standard. Writing a test for this should be fairly straightforward.


  • Write a test for frustum()

Plan Alterations

In a few days we’ll be having our weekly Processing.js meeting. At that time we can add, remove, and alter the details of this plan. Once we have these elements in the code, the user will be able to call size() (which has already landed), call camera() and set the viewing volume with either perspective() or frustum(). The user can also change the background color (also landed) and ….that’s about it :s If we get ahead of schedule, I’ll plow on and get box() or rect() ready for review. It seems like we are taking a step backwards, but I believe this is a step in the right direction.

My Processing.js Release 0.4 January 25, 2010

Posted by Andor Saga in JavaScript, Open Source, Processing.js.
add a comment

I’m working on parts of the Processing.js library for my open source class. This marks my 0.4 release.

For this release, students in the class weren’t actually supposed to write any code. This is because we have to sort through a large number of tickets in lighthouse, which need review. The plan was that the students would do some peer or first level review. If it passed that review, we could submit the bugs for super review so the code lands in the Processing.js branch. I browsed the tickets which needed review and assigned a few to myself. I have never officially reviewed another developer’s code, so I was interested in how it would work.

I started with a quick search on code review. Some of the more valuable links I found were:
Code Review Checklist
Mozilla – How to Submit a Patch

Before starting my reviews, I compiled a short checklist of things I’ll try to enforce. Not all of them apply, but I was just getting an idea of what things to look out for in the future.

  • Does the code work?
  • Does the code have tests?
  • Does it break regression tests?
  • Is the code properly documented?
  • Does the code introduce security concerns?
  • Are function and variable names congruent with the codebase?
  • Is the indent/brace/spacing style adhered to?
  • Does the code have a performance impact?
  • Can the code be simplified?
  • Can the code be more efficient?

I ended up assigning many more tickets to myself than I was able to review. I didn’t finish my reviews partly because I got stuck trying to fix the bugs present in the code I was reviewing. I know when submitting a patch to a large open source project there’s no way someone reviewing your code will start to debug it for you. But since we’re a fairly small team, I figured I could help out. Here are the tickets I did manage to review.


Lighthouse Ticket: camera()

Testing this one took a while, but I eventually managed to make it run. One of the problems is there was this line:

if( arguments.length = 0 )

It actually took me a while to catch it and I think many developers from time to time still make this mistake. I recall reading a textbook (probably Code Complete) which mentioned that if you find yourself making this mistake often, change your style to this:

if( 0 == arguments.length )

Anytime you try to use only one equal sign, you’ll get an error telling you zero isn’t an lvalue. That is, it can’t be on the left side of an assignment. And since we’re using JavaScript, we might as well add another equals sign.

if( 0 === arguments.length )

You can see the rest of my comments on camera() in the camera lighthouse ticket.


Lighthouse ticket: join()
My additional tests: join() tests

Alex wrote a test for his implementation of join(). I wanted write a few more tests before I submitted the ticket for super review. I started writing them, but soon found that my tests were breaking the library. After some research I found that nf() was not returning the correct values. So I had to comment out those from my tests which used nf(). Once we have nf() working, I can update my tests to test for joining int and float arrays. Other than that, the code seems to pass my tests. I marked it for super review and moved on.

P3DMatrixStack object

Lighthouse Ticket: P3DMatrixStack

I got stuck on this one. The logic to multiply the matrices looked deceptively correct and simple. However the matrices that I was testing weren’t being properly multiplied. After finally just throwing in some debug print statements, I saw what was actually happening. The logic in fact was not correct. Whenever you see a matrix multiplication in nested for loops, keep in mind matrix multiplication is O(n3). If it doesn’t look like O(n3), it’s probably wrong (however there are some faster implementations). That is, there should be a bunch of logic in the last code block or there should be a third for loop.


Lighthouse ticket: frustum()

This code looks fine, it’s the same logic you can find all over the Web, but we still need a test. So I marked the ticket as “needs work”.

Remnants & More Tests Required

A lot of the other lighthouse tickets I assigned myself to review don’t have tests. Since some of the students who worked on them are no longer in the class, I’ll have to undertake writing tests for those bugs. So here are the bugs I still need to review:

Simplifying the Interface January 23, 2010

Posted by Andor Saga in C3DL, JavaScript, Open Source.
add a comment

Something I need to do is simplify the C3DL interface. When approaching such tasks, one method I found extremely useful was to analyze the code in terms of the interface, or that is from the user’s perspective. To do this I first created a basic demo of a spinning cube by writing the necessary HTML and JavaScript files. As for the HTML, it will need to be something like this:
(I emphasized the code which potentially could be changed)

    <title>Cavas3D Demo</title>
    <script>var SCRIPT_PATH = '../../canvas3dapi/'</script>
    <script src="../../canvas3dapi/c3dapi.js">
    <script src="basic_demo.js"></script>

    <canvas id="demo" width="500" height="500"></canvas>


It would be great if this could be simplified to something like this:


    <title>Cavas3D Demo</title>
    <script src="../../canvas3dapi/c3dapi.js">

    <canvas datasrc="basic_demo.js" width="500" height="500">


I removed the somewhat unintuitive SCRIPT_PATH variable and moved the basic_demo.js resource into the canvas tag making it more obvious which .js file is associated to which canvas. These changes haven’t actually been made, I’m just playing with possible changes, brainstorming which parts might be able to be modified.

Now, very few changes were made here and it will probably require a significant amount of effort to make it work. But this work is justified by the fact that the user’s experience and first impression will be more positive. If the user has to spend more than a few minutes trying to get a simple example to render, they’ll probably look for alternatives.

Let’s see how the JavaScript could be changed. Right now, you need to write something like this:
(Again, I emphasized the code which potentially could be changed)

c3dl.addMainCallBack(mainDemo, 'demo');

function mainDemo(canvasName)
  var scn = new c3dl.Scene();
  var renderer = new c3dl.OpenGLES20();
  var cam = new c3dl.FreeCamera();

  var cube = new c3dl.Collada();


Some changes I had in mind involved getting rid of the global c3dl.addModel() and c3dl.addMainCallback() calls and changing OpenGLES20 to just Renderer. The Renderer is an interesting problem. When WebGL started out as Canvas3D, we called the renderer OpenGLES11, then later it became OpenGLES20 and now it could probably be WebGL. Considering how much it has changed and will change, we’ll have to invest some time to make this stop. One simple solution is to abstract the renderer.

For example, if we change OpenGLES20 class to Renderer, the user will no longer need to be concerned what underlying rendering method is used. If a visitor loads the user’s demo, but visitor’s browser doesn’t support WebGL (i.e. it’s I.E.), the demo still loads. This of course only works if we accommodate for this case. So if the browser is IE, we use DirectX. If the browser supports WebGL, we use that. The end result is the user’s page will create the appropriate renderer without them needing to worry about the user’s browser. So let’s look at what lines changed:

function mainDemo(canvasName)
  var scn = new c3dl.Scene();
  var renderer = new c3dl.Renderer();
  var cam = new c3dl.FreeCamera();

  var cube = new c3dl.Collada();


In terms of the lines trimmed, I’m not certain how much of it is viable. The reason some of the seemingly redundant code is required was because I couldn’t devise any alternative at the time. Looking at it from a different perspective, I should be able to come up with something. In the end we’ll have an interface which is more flexible, easier to understand and of course simple.

WebGL Processing.js Reftests January 20, 2010

Posted by Andor Saga in Open Source, Processing.js, webgl.

I’m working on adding 3D functionality to the Processing.js library. Since any Processing.js scripts should render exactly the same as identical Processing scripts, it would make sense to use reference tests. This will ensure all my WebGL code is rendering objects where they should be and with correct lighting. I’m using Minefield to run the tests since it has reftest functionality along with support for WebGL to render the 3D objects.


At first I had to play around with Minefield’s configuration to get reftests working. I was able to correctly compare two identical basic HTML files. Once I got over that hurdle, I went to the next one. I knew I would need to compare screenshots from the PDE environment against whatever is rendered in the web page using PJS. To make things simple, I started to experiment with very basic (no Processing) HTML vs. PNG reftest. I had a string rendered in an HTML page and a rasterized string in a PNG file. I ran the tests, but Minefield kept telling me some arbitrary number of pixels differed between the web page and the image.

Script Vs. Script

Not finding much help on the Web, I thought it might be a better decision to simply create a Processing script in the PDE, export it to HTML as my first compare file. Then use that same Processing script to create a PJS test in another web page as the second compare file. Finally I could ask Minefield to render and compare the two. It seemed like a good idea at the time. I was getting awfully tired of taking screenshots.

My Processing test case was as simple as it could get:


I threw this in the PDE, exported it, cut out all the unnecessary CSS and got a plain black canvas rendered in a Web page. Before creating a real PJS script, I decided to first test with a page which just had an tag with the same black square. When I went back to my shell and ran the tests, they failed. Now, when reftests are executed, the browser opens a window, renders the page and closes it. This happens pretty quickly, and I saw a bunch of blue text, which was very odd. It should have been drawing the black square. It turns out I opened the exported Processing file in my default browser earlier (that’s why it worked) and now I was running the reftests in Minefield and I was getting this:

Get the latest Java Plug-in here.

That’s when I remembered Minefield doesn’t have a compatible JRE, at least for OSX. This means there’s no way I can load the applet in Minefield to properly test. Of course I can go back to an older version of Firefox which does have Java, but that won’t have support for WebGL. As much as this sucks, the situation is a bit funny.

? Vs. ?

Okay, what can I do now? I could go back and figure out how to make HTML vs. PNG comparisons work. I’m not keen on doing this because grabbing screenshots is extremely tedious. The solution is also very inflexible. If I change my PJS test script, I need to grab yet another screenshot as opposed to a simple export in PDE and trim away unneeded CSS. Another solution could involve running the reftests on another platform such as Windows or Linux. Perhaps they have Java runtimes available. Hmm… Are reftests powerful enough to have a page open with one version of Firefox and another page with Minefield? I doubt it. Maybe there is some other technique of getting this to work. I’ll bring it up in this week’s Processing.js conference call. Hopefully I’ll get some suggestions.

Offering Alms January 16, 2010

Posted by Andor Saga in Random.
add a comment

I always found it a bit awkward offering money or food to the needy if they didn’t ask. Will they be insulted? Will they reject my alms? That would be embarrassing. I was feeling terrible for tragedy that struck Haiti, but didn’t see any way I could help. So I decided to do something to help someone closer in proximity. I saw a homeless man and I forced myself to risk the embarrassment of rejection and offered food I had on me. I asked him if he’d like it, and he accepted. I felt like I helped someone out. “Be the change you want to see in the world“. I want to see more people helping one another out, so I tried and did the least I could. Then I was told the homeless guy was a retired law professor. Nice.

My girlfriend sorted our laundry a few days ago since we’ll be washing everything on the weekend. In the process, she gathered some old clothes and set them aside for donations to Value Village. When we arrived home, I realized there is probably a program in place to send donations to Haiti, so we agreed to send the bags of clothing there instead.

Unwinding the Dream Stack January 15, 2010

Posted by Andor Saga in Lucid Dreaming.
1 comment so far

I started practicing lucid dreaming several days ago and wrote a few blog posts about my experiences, thoughts, and suggestions for other beginner oneironauts. I managed to remember and record my dreams, but I wasn’t successful in achieving lucidity for the first week. But soon after my last post, I had a short lucid dream.

My experience was as follows. I woke up at 6:00 AM and went back to sleep. Every time I woke up, I would review my last dream. I then imagined I was having that dream, but imagined I knew I was dreaming. I did this until I fell asleep. I was essentially practicing MILD. After three or four times trying this, I eventually found myself lucid at the beginning of a dream. I was so excited since it has been years since I last had a lucid dream. My past experiences taught me strong emotions could abruptly end lucidity, so I tried to stay calm and casually explore this world my mind had conjured up. I did this for a quarter minute until I lost lucidity and woke up. I was happy I finally succeeded, so I turned over and told my girlfriend. She didn’t share my excitement and appeared quite apathetic. She went back to sleep left me half-sitting gawking in disbelief. Then I woke up, again.

Unwinding the Dream Stack

Most people had this ‘dream in a dream’ experience at least once. You wake up, brush your teeth, start having breakfast, then wake up. Then you wake up again. This ‘waking up to another dream’ is known as a false awakening. The recursive dream stack continues to unwind until you finally find yourself in your waking life. All this silliness teaches us an important lesson: The very first thing you should do when you wake up is a reality check. This gives you the chance to seize the opportunity to have a lucid dream if you do have a false awakening.

Analyzing Lucid Dreams

In my other blog post I wrote about the importance of analyzing your dreams. But what about analyzing lucid dreams? How can you analyze something which you can control or at least partially control? This subject borders analyzing your non-lucid dreams (which makes sense) and analyzing your waking life (which makes less sense). This subject gets pretty interesting, especially if you decide to analyze your lucid dreams while they occur. Cooool.

So after my true awakening, I began to analyze my lucid dream. I found it a bit frightening once I realized what the themes and symbols likely mean. So, I’ll have to keep them between me and my unencrypted text files. The dream wasn’t long, which is typical to the beginning lucid dreamer. So practice, practice, practice until you get your second-long lucid dreams. Then practice, practice and practice until you can lengthen those lucid dreams.

Keep Dreaming

My Processing.js Project Plan January 13, 2010

Posted by Andor Saga in Open Source.
1 comment so far

I’m back from the holidays, refreshed and ready to get back to work on my open source course! If you haven’t been following my blog, I’m a BSD (Bachelor of Software Development) degree student at Seneca College. I completed my first open source course, DPS909 and now I’m continuing my work in DPS911. In these courses, students get the opportunity of working on cutting-edge, real world software applications.


There are a group of us working on Processing.js. This involves porting the Java-based Processing language code to JavaScript. We’ve managed to get a lot of work done since John Resig started the PJS project. We did this by collaborating via IRC, blogs, wikis, Lighthouse as well as in person. I have already written a very brief description on Processing.js, so I won’t go into the details, this post mainly serves as an official start to the second part of the open source course. Last semester I left the state of my code in the 0.3 stage, so I’ll be doing bi-weekly releases over the next few weeks and take it up all the way to 1.0. I decided to post my plans for at least the next couple of releases since planning too far ahead will probably be in vain. Once I release 0.5, I’ll write another post which will detail my work on the following two.

Release 0.4 – Catching Up

Before I begin, I’ll need to first take the work of other students such as Anna’s model code and Mickael’s camera code and merge that into my code and make sure everything works as required. If not, I’ll have to revise my code or ask my group members to update their code. Once that’s done, I can fix any problems with my lighting code and move on to 0.5 work.

Release 0.5 – vertex(), triangle(), rect()

I want to veer off a bit from what I was last working on (lights), and get some basic elements such as the 3D implementations of Vertex, triangle(), rectangle() finished. Once these are done, we can start making use of some interesting Processing scripts. These will involve some WebGL work as well as working with functions like stroke and noStroke() which have an impact on the final rendered primitive.

But before that, I need to get reftests working. Right now Minefield is throwing exceptions and I have no idea why. I did some research and haven’t found much, so I may have to get some help on IRC. I already began writing reftests for triangle() and reftests for rectangle. So I may add some more tests to those and make one for vertex(), then start work on the triangle and rectangle functions for 3D.

Issues – Getting Stuck

I learned a few things from working on the first open source course. Most importantly, if you get stuck, pick up another function and work on that instead. So, my releases will have a few functions on the go in case this happens. I’ll keep my stubborn nature in check. If I see I’m just spinning my wheels and getting nowhere, I’ll switch tasks or ask for help.

Issues – Communication

Because communication is such an important part of open source development, I’ll try to stay on IRC whenever I can so I can ask for help as well as provide some help to others. I’ll also try to keep an open connection to the other students working on the project, participating in weekly or bi-weekly meeting will help a bit. Maybe I’ll hang around CDOT more.

Issues – Moving Target

The WebGL specification is a bit of a moving target. I’ve seen many developers providing interesting comments and suggestions on the mailing list. This means there may come a time when I’ll pull from the repository, build and suddenly find my code is broken. If this happens because the spec and therefore the implementation has changed, hopefully I’ll figure that out before rewriting all my code. Or better yet, I’ll make sure my code works before I decide to start changing things.

A Week of Lucidity: Night Seven (SW & HW) January 11, 2010

Posted by Andor Saga in Lucid Dreaming, Open Source.
1 comment so far

It’s been seven days and thus concludes my week of lucidity. Not surprisingly, I didn’t have a lucid dream during these past few days. At least not one I recall, but I’m getting back in the habit of recording my dreams in my dream journal, doing autosuggestions as well as practicing other techniques. If I have any interesting discoveries or actual lucid dreams, I’ll probably blog about those. Otherwise this will be my last blog on this subject for a while since I’ll be busy with school.

Lucid Dreaming Software

In my other blog I mentioned some features I would like in a dream journal application. Organizing dreams in a digital form can be helpful to define symbols for later analysis as well as identify recurring ones to help achieve lucidity. I’ll start looking for a program which suits me. Once I decide on one, I’ll have to go through the boring task of typing out all the pages I had written by hand. Maybe I’ll start keeping my laptop near my bed so this won’t be necessary in the future.

Lucid Dreaming Hardware

I decided that in the event that I don’t achieve lucidity by the end of the month, I will start to design a lucid dreaming induction device. I already started brainstorming different possibilities such as an individual-based and room-based versions. A room-based version could solve the problem of comfort, since wearing something on you head at night will probably interfere with sleep. Having three devices synchronized (maybe one affixed to the ceiling?) to the same time could increase the chance of the foreign light entering your dream world, but this may be a problem if you have a spouse.

It would be a great learning experience and very fun to build such a lucid dreaming induction device. I would of course make the final diagram, notes, and plans publicly available and any software open source so anyone else can build one for themselves. Or at least take some of my ideas and merge them with other designs already available online.

Keep Dreaming