. Piotr Jaroszyñski
. Rodrigo Lazo
Last updated:
June 01, 2008, 15:11 UTC
Disclaimer:
Views expressed in the content published here do not necessarily represent the views of Gentoo Linux or the Gentoo Foundation.
Bugs? Comments? Suggestions? Contact us: planet@gentoo.org
Powered by:
Planet
Welcome to Planet Gentoo Summer of Code, an aggregation of weblogs belonging to this year's Gentoo Summer of Code students. We are running this alongside Planet Gentoo and Gentoo Universe.
|
I was browsing the discussion group when I found this discussion. I was shocked. That post was the summit of the peruvian mindset problem. That guy was blaming Google of the lack of peruvian students on Summer of Code!!. I'm the first peruvian student to be part of SoC, and it never crossed my mind that my proposal could be rejected because of my nationality. I hate to see that a countryman blames somebody else of it's problems. I have seen that too many times; there are people that loves to complain about lack of opportunities here... and no matter what, they will always find a new thing to complain about. Too much complaining, we need to work harder! |
|
Google Summer of Code is over, but, hopefully, the projects are not - at least I am not going to stop working on mine. I must say that SoC was very successful for me, I have learned plenty of new things and my dream of contributing to the Paludis itself came true. I must also thank all of the folks at #paludis, especially Ciaran McCreesh, my mentor Saleem Abdulrasool and rest of the Gentoo SoC staff for all the help. |
|
Well, SoC's final deadline is a few days away, I really enjoyed this time :). Let's talk about the status now: Right now SCIRE's job subsystem is capable of create, distribute, run and monitor a job created, both for a single and for multiple clients. All this is also reflect on the UI code. Finally, all the code can be tested directly from the UI and everything seems to work (No bugs doesn't mean it's right, just that is doesn't have visible bugs). The latest patch implements the monitoring UI, and gives pretty usefull information about the job. What is missing? Once a job is completed it could be marked as finished, failed or cancelled. If the job is non-recurring, there's no problem as all this just becames historical information. But for recurring jobs is a different story as it need to be re-schedule, isn't it?. For successfully finished jobs si pretty straight forward to assume that they should be rescheduled automatically. But for failed? or cancelled?. I'm very lean towards the user-should-choose option; after all, he knows better what to do for every situation, as it may depend on the job. So the best decision is not to let somebody else do the decision :). But you also need a good default, so I'll do this as follow: if a job has been marked as failed, re-schedule it automatically, but if is has been marked as cancelled, don't do it. This implies that the job creation template should include an option to modify this behavior. Also, the re-scheduling mechanism is not that hard to implement, the problem lies on who should execute it. The observer pattern should come to the rescue. Isn't it wonderfull when you figure out something while writing a post? I should blog more often :) |
|
Finally I've finished my semester!, although technically I have to take one more exam, it's due Sunday and not that hard anyway. So I can *finally* dedicate to my soc project 24/7. Here is the status report I've sent to the gentoo-soc mailing list: Project descriptionSCIRE (Systems Configuration, Installation, and Replication Enviroment) "aims to create a widely extensible common portal for administrative tasks for multiple Linux client machines". The job subsystem deals with the creation, preprocessing, scheduling, distribution and execution of specific tasks for the client machines. Project status
The Definition column refers to the specific way to do each step, and I've learned all this time that specific things cannot be forseen so, although in the proposal there is a specification, it isn't set in stone until it's feasible do code it and to code it efficently. The main focus of the project up to today was on the scheduling and distribution steps. The former is finished and the latter has been halted until the creation step reflects the advances on the other ones. The preprocessing step will be the la it isn't essencial nor blocking of the rest. On my soc proposal I splitted the project so the backend code would be written on the first half and the UI code on the other half, but my mentor suggested me to do them on parallel. I'm a little bit behind my schedule, but now I have a lot more time to work on the project, so I'm confidence about finishing the project. Timeline9-15 July = Finishing updating the UI to reflect the latest changes 16-22 July = Finishing the distribution code 23-29 July = Work on the creation UI code 30-5 August = Finishing the Execution code 6-12 August = Finishing the creation code (both backend and UI) 13-18 August = Work on Preprocessing code. |
|
For quite some time I wanted to add docstrings to enums exposed with Boost.Python as my project's API docs seemed incomplete. Let's see how I found the solution eventually:
// Nice enum!
enum Foo
{
blah
};
While exposing the enum itself couldn't be any simpler:
BOOST_PYTHON_MODULE(enum_test)
{
bp::enum_<Foo> enum_foo("Foo");
enum_foo.value("blah", blah);
...
... adding __doc__ is completly another story.First (silly) attempt:
...
PyObject_SetAttrString(enum_foo.ptr(), "__doc__", PyString_FromString("Nice enum!"));
};
"It must work" I thought, but what I got on import then was far from satisfying:TypeError: attribute '__doc__' of 'type' objects is not writable
After digging in Boost.Python, Python C API docs and harassing people at #python:
...
PyTypeObject * pto = reinterpret_cast<PyTypeObject *>(enum_foo.ptr());
pto->tp_doc = "Nice enum!";
};
Thils looked really promising... and what? Nothing at all! Changing tp_doc had no effect whatsoever, and only after some more digging, it turned out it was too late to change it and the right way is:
...
PyTypeObject * pto = reinterpret_cast<PyTypeObject *>(enum_foo.ptr());
PyDict_SetItemString(pto->tp_dict, "__doc__", PyString_FromString("Nice enum!"));
};
Boost.Python and Python C API are fun ;) |
|
Python bindings are now available in the paludis-scm.ebuild from the Paludis overlay. Just set the python use-flag and reinstall. Comments are welcome, but keep in mind it's far from the final version :] |
|
I was supposed to give some updates about my SoC project, so here is the much delayed first one. |
|
Just a quick post. I've been working on the client and server code of SCIRE to include the new job model, is going well and today there was a interesting chat with my mentor and all the team at #gentoo-scire. This week's code delivery will be delayed a little bit, I want to include the latest modification suggested on IRC. Once I have everything set up I will do a more detailed post. On the other hand, it's getting harder to balance the Summer of Code with the University, so far so good but I have to be very organized with my time :). Tomorrow I will give a lightning talk about plan 9 (an operating system from Bell labs that was designed to make Unix obsolete.) I'm not an expert on it... but I think is very interesting and I'm sure this will be the first time my teacher will hear about Plan 9... so It's going to be fun Over and out |
|
A week and a half has been since the Summer of Code officially began. I'm feeling more and more part of this and I'm as excited as when I was elected a month or so ago. But... we need to get down to business :) All this time I've been working on two fronts. One is the database; basically defining how to create the relationships between jobs, its metadata and the target clients; the scheduling schema is going to use a crontab-like string as is by far the best way to do it and also is a well known syntax for the users. The database modifications weren't taken lightly as everything is going to be based on the database so they were very well talked with codeman and agaffney. If everything goes as it should *wink* the database schema shouldn't be modified from now on. On the other side I've been working on the client and server side of the app. I've been using pychecker to review the code. It's easy to make mistakes if you are used to use a compiler to check your code :). On the server side I've added support to command-line arguments. I'm trying to check the client-server connection before doing any other work, and for some reason the SSL authentication is throwing me an error if the server and the client are on different machines; but if they run on the same they work... weird. Once that is over I'll focus on fix all the functions I broke with the modification to the database. On a side note I finally have everything ready to work, the kvm virtual machines are working flawlessly and with the extra Gigabyte of RAM I just bought there's not a single delay while working with several virtual machines. Great! |
|
Just a quick post, my Summer of Code proposal is now available here. Any comment or feedback is more than welcome! |
|
My Summer of Code application has been accepted! When I first saw it I couldn't believe it. I have been accepted to work for the Gentoo Foundation. My proposal is "SCIRE's job subsystem implementation for both the frontend and backend."
|
|
Welcome to my brand new blog! |
Views expressed in the content shown above do not necessarily represent the views of Gentoo Linux or the Gentoo Foundation.