Well, things are getting better it seems. Previously, when I would try to start Google Books, it would complain and prevent me from using it because I was in Canada. Last week I received an update and now I can read books and acquire new ones. (Well, not ones that are still covered by copyright, since Google still hasn't negotiated rights within Canada to distribute their large collection. Grr.)
This makes it competitive with my current ereader of choice, Aldiko, which I actually mistakenly thought was open source until 1 minute ago. Whoops!
2011-06-14
Food Shortages
Labels: #General, backyard bounty, community, feed me, food, local food, mold, oh the humanity, rot, starving
I am currently experiencing a dramatic food shortage caused by two main factors
When I went away to Anime North for 3 days, I went about freezing a lot of stuff, and was delighted upon my return to find the food in the refrigerator and freezer was still edible and nutritional. I could freely reach in and pull out something green or yellow or red and steal its soul to sustain my own.
Then I just went away for 2 nights to Ottawa and, while I was gone, Mold decided to move into my fridge and bring its friends, and they partied like I was five hours away (which I was). It seems like half of what I had fell under the influence: tomatoes, pesto, rice, frozen bread, tomato sauce, and a spare kidney. All must be banished from my palette.
This wasn't so bad, as it left me with canned soup, canned beans, and frozen vegetables. So why don't I get more?
Shopping
Part of the problem with shopping is that it takes time, and I'm actually busy. Not just "I got distracted and now I have to finish this in a hurry!"-busy as I sometimes get, but "I've been working 12 hours a day and 4 more days isn't enough!"-busy. But that's alright, because it's better to shop, eat, do worse on an assignment, and live, than to work hard, get perfect, and die. (Though the latter seems so romantic.)
However, I have had a card up my sleeve that my refrigerator, in its attempts to kill me, had missed: the Backyard Bounty. That's a community garden share thing, where community members provide their backyards to grow produce which is sold through a group called Backyard Bounty to its members, including myself and my girlfriend (for this year, at least).
Today was the first week for produce pickup, and I've drooled all day (sorry, old lady who sat in front of me on the bus) in anticipation for perceptually free food! I trotted over there with eagre to fill my bag with this bounty to discover a sad fact of food production:
That's arugula, thyme, another herb, and a small tomato plant: I actually requested a small one because I am nervous, and they had larger ones available.
I heard one of the organisers explain to a member that while early on there is less yield, that it would pick up over time. I have drawn a redundant and obvious graph to help illustrate.
So, now I go to chew on flowers for supper. Maybe make a salad of leaves. Maybe go to No Frills and get groceries. Eating local organic sounds like a nice idea, but I think I will have to supplement with imports or die.
No Food Left Behind (with 10% error)
To help correct my food shortage, I have one major plan: to always eat left-overs first. I often defer in eating them in favour of something I want more. I am having extra time at the start of days recently, though (waking up earlier? yahoo!), and can now afford to pack lunches for school. No Leftover Left Uneaten. Now, I just need to create left overs.
- I haven't gone to the store to buy anything in a while
- most of the food I did have rotted and sought to kill me while I ate
When I went away to Anime North for 3 days, I went about freezing a lot of stuff, and was delighted upon my return to find the food in the refrigerator and freezer was still edible and nutritional. I could freely reach in and pull out something green or yellow or red and steal its soul to sustain my own.
Then I just went away for 2 nights to Ottawa and, while I was gone, Mold decided to move into my fridge and bring its friends, and they partied like I was five hours away (which I was). It seems like half of what I had fell under the influence: tomatoes, pesto, rice, frozen bread, tomato sauce, and a spare kidney. All must be banished from my palette.
This wasn't so bad, as it left me with canned soup, canned beans, and frozen vegetables. So why don't I get more?
Shopping
Part of the problem with shopping is that it takes time, and I'm actually busy. Not just "I got distracted and now I have to finish this in a hurry!"-busy as I sometimes get, but "I've been working 12 hours a day and 4 more days isn't enough!"-busy. But that's alright, because it's better to shop, eat, do worse on an assignment, and live, than to work hard, get perfect, and die. (Though the latter seems so romantic.)
However, I have had a card up my sleeve that my refrigerator, in its attempts to kill me, had missed: the Backyard Bounty. That's a community garden share thing, where community members provide their backyards to grow produce which is sold through a group called Backyard Bounty to its members, including myself and my girlfriend (for this year, at least).
Today was the first week for produce pickup, and I've drooled all day (sorry, old lady who sat in front of me on the bus) in anticipation for perceptually free food! I trotted over there with eagre to fill my bag with this bounty to discover a sad fact of food production:
Food takes time to grow and isn't necessarily ready to be harvested when I want it.
 |
| Behold, my bounty! Green stuff, some herb, flowers?, and a tomato (plant) |
I heard one of the organisers explain to a member that while early on there is less yield, that it would pick up over time. I have drawn a redundant and obvious graph to help illustrate.
 |
| Expectation of produce amount vs. hard cold (blue) reality. Some people might shift their red line up a few blocks, too. |
No Food Left Behind (with 10% error)
To help correct my food shortage, I have one major plan: to always eat left-overs first. I often defer in eating them in favour of something I want more. I am having extra time at the start of days recently, though (waking up earlier? yahoo!), and can now afford to pack lunches for school. No Leftover Left Uneaten. Now, I just need to create left overs.
2011-06-12
GDom: three weeks in!
Labels: #GNOME, gio, refactoring, scheduling, tests, time management
Hello again.
On the planet, you may have just seen me publish last week's blog post an hour ago. These blog posts take a bit of care for me, since I don't want to rush garbage out to so many readers. I send a simpler point-form report out to the gsoc mailing list (which did go out last week) and then usually write the nicer blog post the next day. Waiting for some editing, I actually forgot to put the last one up after getting busy. Sorry! Here is the current progress, though.
Past week
Scheduling and keeping up-to-date
I'm getting better at keeping the git repository for GDom up to date, though still not quite as regularly as my dutiful mentor Alberto Ruiz has requested. I do have some school work this summer as part of my Masters that takes up part of my earlier week, so I'm going to shift my GSoC work earlier to the start of the week to ensure that I can have everything ready for Friday evening, rather than sending out my mailing list reports late on Friday night and following up with the blog post later.
Document, Element, and Node
The support for these three interfaces is almost complete now. Document will need some novel work on loading and saving from GIO streams, but the interfaces pass the unit tests. Speaking of which, these three interfaces all have beautiful unit tests now. There's probably still a little room for improvement, but I'm moving on to focus on other classes now.
Attr
I actually intended on finishing implementing this and creating tests for it this past week. The implementation was working mostly but I ran out of time for its test suite, which I'm working on today.
Refactoring
This probably isn't too interesting, but my initial plans for the class hierarchy have had to be refactored a couple times (didn't take too long), because not all interfaces described in the spec correspond perfectly to libxml2's DOM support. We now have a base DomNode that describes the DOM spec's interface, and a BackedNode that does a general implementation of it using libxml2's Xml.Node. Then, other interfaces that use libxml2's Xml.Node are based on BackedNode, while interfaces that don't just base off of DomNode, and sometimes require some local data. This might get messy when saving files back, though. Yikes!
Upcoming
Build System
When I talk to my mentor Alberto Ruiz next, I hope to discuss autotools versus WAF. I keep meaning to investigate it more myself, but ended up with Internet disruptions last week (went to Ottawa for academic reasons and my accommodation's Internet was out) and was generally busy, so this is now an item for this week.
GIO integration
Need to figure out the best way to use GIO to load and save files by stream for our underlying libxml2 usage. Currently, I just have Document reading from a Unix file path. Hehe.
Attr test case
Finish this. My general approach has been to at least stub out all the properties and methods and try obvious implementations for them first (usually doing something with an underlying libxml2 structure), and then going through the spec to write tests for the class. The tests usually reveal all the tricky points in my handling of libxml2 data, or my class hierarchy, and I make another pass to get the class compliant. It's FUN!
live.gnome.org/XML updates
I have a list of things to go up there, now that I'm into the project, including
Good day
Thanks for reading this far. Also, as noted in my previous post, if you have specific test cases (e.g. large or complex files) that you'd like to see supported, please send them to me: aquarichy at gmail dot com.
Cheerio!
On the planet, you may have just seen me publish last week's blog post an hour ago. These blog posts take a bit of care for me, since I don't want to rush garbage out to so many readers. I send a simpler point-form report out to the gsoc mailing list (which did go out last week) and then usually write the nicer blog post the next day. Waiting for some editing, I actually forgot to put the last one up after getting busy. Sorry! Here is the current progress, though.
Past week
Scheduling and keeping up-to-date
I'm getting better at keeping the git repository for GDom up to date, though still not quite as regularly as my dutiful mentor Alberto Ruiz has requested. I do have some school work this summer as part of my Masters that takes up part of my earlier week, so I'm going to shift my GSoC work earlier to the start of the week to ensure that I can have everything ready for Friday evening, rather than sending out my mailing list reports late on Friday night and following up with the blog post later.
Document, Element, and Node
The support for these three interfaces is almost complete now. Document will need some novel work on loading and saving from GIO streams, but the interfaces pass the unit tests. Speaking of which, these three interfaces all have beautiful unit tests now. There's probably still a little room for improvement, but I'm moving on to focus on other classes now.
Attr
I actually intended on finishing implementing this and creating tests for it this past week. The implementation was working mostly but I ran out of time for its test suite, which I'm working on today.
Refactoring
This probably isn't too interesting, but my initial plans for the class hierarchy have had to be refactored a couple times (didn't take too long), because not all interfaces described in the spec correspond perfectly to libxml2's DOM support. We now have a base DomNode that describes the DOM spec's interface, and a BackedNode that does a general implementation of it using libxml2's Xml.Node. Then, other interfaces that use libxml2's Xml.Node are based on BackedNode, while interfaces that don't just base off of DomNode, and sometimes require some local data. This might get messy when saving files back, though. Yikes!
Upcoming
Build System
When I talk to my mentor Alberto Ruiz next, I hope to discuss autotools versus WAF. I keep meaning to investigate it more myself, but ended up with Internet disruptions last week (went to Ottawa for academic reasons and my accommodation's Internet was out) and was generally busy, so this is now an item for this week.
GIO integration
Need to figure out the best way to use GIO to load and save files by stream for our underlying libxml2 usage. Currently, I just have Document reading from a Unix file path. Hehe.
Attr test case
Finish this. My general approach has been to at least stub out all the properties and methods and try obvious implementations for them first (usually doing something with an underlying libxml2 structure), and then going through the spec to write tests for the class. The tests usually reveal all the tricky points in my handling of libxml2 data, or my class hierarchy, and I make another pass to get the class compliant. It's FUN!
live.gnome.org/XML updates
I have a list of things to go up there, now that I'm into the project, including
- list of similar projects and how we differ
- performance test cases and results (haven't started measuring yet, though)
- list of features and suggestions to be considered in the future, after GSoC
Good day
Thanks for reading this far. Also, as noted in my previous post, if you have specific test cases (e.g. large or complex files) that you'd like to see supported, please send them to me: aquarichy at gmail dot com.
Cheerio!
GDom, after two weeks
Labels: #GNOME, API, gdom, performance, test
This was actually supposed to go up last Monday, but got missed in the busy-ness. I did send my weekly report to the GSoC mailing list, though those reports are less verbose :)
GDom is now two weeks old. Here's what we have so far:
Past week
I managed to do more research, more fully reading the DOM Level 1 Core spec (rather than my quicker review of it when I started) and it answered many of the questions I encountered after writing code the previous week.
Performance
Many people have offered a lot of suggestions regarding the direction of GDom so far and I got to discuss them with my mentor this morning [last Monday]. To ensure something useful gets created and implemented well within the GSoC time frame, GDom will remain limited to essentially wrapping libxml2 and complying with the DOM Level 1 Core spec.
In the comments from last week [two weeks ago], there was notable concern about performance of libxml2 and GObject. GDom will not be directly addressing those. It will simply be providing a much nicer API for GNOME developers to work with in most cases.
That said, I am quite interested in the resulting performance and would like to start testing performance as I go along, once most of the base has been laid. I'll probably simply measure the memory and time performance differences between libxml2 and GDom and identify some choke points. I don't expect GDom to be faster, but I hope for it to not be significantly worse. After the Summer of Code is over and GDom can provide a pretty, standard, GNOME-y API, it will be worth considering a faster, more efficient implementation of the interface. This is something I'm interested in pursuing, and would be something I would have started with this summer except for the strict time frame and progress requirements.
Request for you, XML-using reader!
If you have any specific test cases (e.g. work loads you'd like me to consider like super huge files you deal with :D), please send or explain them to me. I will test with those and see what I can do to ensure GDom isn't useless to you :D
My e-mail: aquarichy at gmail dot com
Features
Some people have named some features they'd like to see on top of GDom that go beyond the spec. I'm going to track these and keep them as a list at live.gnome.org/XML to keep them in mind and consider pursuing them after the summer.
Similar Projects
So far, I've encountered a few similar projects and had one noted to me. They're all similar in that they handle XML documents and they're written in Vala. They also no longer seem active and/or have had a goal of implementing functionality rather than reusing libxml2.
They were
Tests
I've started implementing GTests to guide the implementation of details for the classes. Hopefully this will increase API compliance and correctness, so anyone already familiar with the DOM API can use the code without surprises.
Next Week [plans for this past week, actually]
GDom is now two weeks old. Here's what we have so far:
- Most of the DOM spec's functionality for Node and Document is working
- Lots of other classes work partially
- Beginnings of test suites for Document, Node, and Element
Past week
I managed to do more research, more fully reading the DOM Level 1 Core spec (rather than my quicker review of it when I started) and it answered many of the questions I encountered after writing code the previous week.
Performance
Many people have offered a lot of suggestions regarding the direction of GDom so far and I got to discuss them with my mentor this morning [last Monday]. To ensure something useful gets created and implemented well within the GSoC time frame, GDom will remain limited to essentially wrapping libxml2 and complying with the DOM Level 1 Core spec.
In the comments from last week [two weeks ago], there was notable concern about performance of libxml2 and GObject. GDom will not be directly addressing those. It will simply be providing a much nicer API for GNOME developers to work with in most cases.
That said, I am quite interested in the resulting performance and would like to start testing performance as I go along, once most of the base has been laid. I'll probably simply measure the memory and time performance differences between libxml2 and GDom and identify some choke points. I don't expect GDom to be faster, but I hope for it to not be significantly worse. After the Summer of Code is over and GDom can provide a pretty, standard, GNOME-y API, it will be worth considering a faster, more efficient implementation of the interface. This is something I'm interested in pursuing, and would be something I would have started with this summer except for the strict time frame and progress requirements.
Request for you, XML-using reader!
If you have any specific test cases (e.g. work loads you'd like me to consider like super huge files you deal with :D), please send or explain them to me. I will test with those and see what I can do to ensure GDom isn't useless to you :D
My e-mail: aquarichy at gmail dot com
Features
Some people have named some features they'd like to see on top of GDom that go beyond the spec. I'm going to track these and keep them as a list at live.gnome.org/XML to keep them in mind and consider pursuing them after the summer.
Similar Projects
So far, I've encountered a few similar projects and had one noted to me. They're all similar in that they handle XML documents and they're written in Vala. They also no longer seem active and/or have had a goal of implementing functionality rather than reusing libxml2.
They were
- dominar
- libgdom3
- xnoise-utils (still active, part of xnoise media player)
Tests
I've started implementing GTests to guide the implementation of details for the classes. Hopefully this will increase API compliance and correctness, so anyone already familiar with the DOM API can use the code without surprises.
Next Week [plans for this past week, actually]
- Talk to my mentor Alberto Ruiz about the build system. I don't know autotools too well, and WAF was brought up as a potential solution.
- More implementation and testing for Document, Element, Node, and Attr.
- Ensure I commit and push files more regularly.
2011-06-02
Meow
Labels: #Microblog, cat, food, meow
I feel like a cat, getting bored with food and then rolling around.
In case we're out
Labels: #Microblog, mushroom soup, shopping, soup
I apparently enjoy purchasing a couple new cans of mushroom soup each time I go shopping. I haven't eaten mushroom soup in almost a month, and now my cupboard is full.
Subscribe to:
Posts (Atom)
