Archive for July 18th, 2008

More geocaching – urban geocaching

Friday, July 18th, 2008

Continuing the caches hunting reports :-)

This week me and Yuri went to Ibirapuera Garden, the main idea was to talk and to take the dust out of our skateboards, BUT I remembered that there were at least two caches there :P

We found both, actually it was very easy to find them. It was Yuri’s first geocaching experience and we decided to search another one near, but outside Ibirapuera. The chosen one was Cedro do Líbano, near enough to go with our vehicles (a skateboard and a long skateboard :P ). It was getting dark and the place where the cache is hidden did not help us. The cache must be very well hidden or it is not there anymore, we looked thought the place for 30 minutes and did not found it :-( ‘ll probably be back to search it again :)

Urban geocaching is very nice because of the curious people asking what you are doing with a GPS device looking for something :P They seem like the idea when you explain what geocaching is!

Tags: ,
Posted in geocaching, personal | No Comments »

Beach geocaching – Ubatuba!

Friday, July 18th, 2008

As some of my friends seemed to like Geocaching I decided to keep they (and you reading this post) updated with my searches for treasures :P

Last Saturday, July 12th (right?? :P ), I was iin Ubatuba (as I’ve already said in my last post about my GSoC project status). Looking Geocaching.com I’ve found a Multi-cache there (ok, I didn’t found it myself but someone pointed me two caches in Ubatuba). It’s the Capricorni Tropicus cache. What’s the difference between a normal cache and a multi-cache? Well, the multi-cache is a cache with multiple coordinates. The first one (the one you will find looking Geocaching.com) will point to a place where you will find tips and steps to find the new coordinates and so on.

To make it short, the coordinates pointed to Ubatuba’s downtown, there I’ve found the next steps and solved the “puzzle” to find the new coordinates. They pointed to a place that I’ve already knew (a bit), near to a beach called (should I mention the name here? :P ). If you visit Ubatuba someday you MUST go to that beach… and bring your dive equipment :P ! Well, to reach that beach you go through a road (in very bad conditions) and stop your car near to a trail. The road goes on and I never had the chance (and the curiosity) to continue on it to see where it would take. But the coordinates pointed to the end of this road :-)

Well, after reaching the end of the road and following the hints I started to follow a trail that took me to some rocks near the sea. The place is very beautiful! You have a scenic view from Ubatuba :-) My GPS was telling that the cache was near, about 40 meters on the rocks. I left my stuff with my grandfather (yes, he was hunting with me) and started to “walk” on the rocks. After reaching the right spot i started looking through the fences, rocks and everything.

Sadly I did not found it :( I’m not sure if it is still there ’cause since last September no one found it. Anyway, the place worths the visit. It’s very calm and peaceful!

Tags: , , ,
Posted in geocaching, personal | No Comments »

PyPy 2.5-features – Yet another status update

Friday, July 18th, 2008

Here comes another GSoC status update :-)

Some finished tasks:

  • throw() method on generators
  • close() method…
  • faking 2.5 behavior for IMPORT_NAME and IMPORT_FROM opcodes
  • changing the default value for magic attribute of PyCode objects
  • changing the magic number that goes in .pyc files compiled by PyPy
  • fixing tests and more tests…

From those changes the only one I would like to comment is the change of both magic numbers.

First, they have different values and meanings in PyPy. The magic number for .pyc files (defined in pypy/modules/__builtin__/importing.py) is the number that identifies the bytecode “version”. It’s used to know if the interpreter should use the .pyc file or should recompile the .py. PyPy’s value is different from CPython’s one. As we are changing some opcodes (as IMPORT_NAME, mentioned before) this number had to be changed. The old value in PyPy was 1024 (or 1024 + 2 or 1024 + 4 or 1024 + 2 + 4, depending on some command line options), the new value is 1034 (or ….). We are just using the same policy CPython uses to change the value, add 10 to the old value.

Now the PyCode magic attribute. This value is the CPython magic number (the one explained above)., the old default value was the value from CPython 2.4 (62021). Some checks against this value are made through the code to decide if the bytecode should be interpreted one way or another. One example is the IMPORT_NAME opcode. In Python 2.4 IMPORT_NAME did not have the level parameter, this parameter is new in 2.5 because of the absolute import feature. So if the bytecode represented by a PyCode object is 2.4, when we visit a import statement we should not try to pop the level value from the stack (because it’s not there), but if it is 2.5 we should! So we check the magic value. The problem is, the default value was 2.4 but we changed the opcodes to behave like 2.5, so those checks were not working. The solution was to change the magic default value to 63231 (2.5c2 value I think), so now our bytecode interpreter is (almost?) compatible with 2.5 bytecode. And our compiler is generating 2.5 compatible bytecode as well.

Tags: , , , , , , , ,
Posted in coding, computer science, free software, pypy, python | No Comments »