Here are the rules:
- € 2,000.- if the person starts working in October
- € 1,000.- if the person starts in November
- The person needs to stay at least 12 month at Lovely Systems. Money will be payed after 12 month.

Check our Jobs.

Welcome to Snow Sprint 2008! We are eagerly awaiting your arrival and working hard to get everything ready for you next week. That’s right…it’s NEXT WEEK!! How exciting! Whether it’s your first Snow Sprint, or you’ve been coming for years, we will be happy to see your smiling faces in the Austrian Alps!

EMAIL LIST:

This year is the largest Snow Sprint yet (50+), and with so many people coming from so many places, communication and planning are of the utmost importance. Thus, I beg you make sure that you are signed up for the Official Snow Sprint email list. This is where all official information will be sent from now on. In the next few days, there will be more information about topics, schedules, sponsorship, and more! So, please make sure you’re subscribed to that email list by sending an email, with the subject of “Subscribe” to: snow-sprint-2008-discussion@lists.openplans.org

IRC:

Also, the #snowsprint IRC channel on FreeNode is open for business! Please add #snowsprint to your auto-joined channels. Let me know if you need help getting an IRC client or connecting to the channel. During the sprint, it would be great if everyone had their IRC clients open for last minute announcements or reminders.

CALENDARS:

I am preparing an iCal file for folks to subscribe to. This will have a general schedule of events during the Snow Sprint, although nothing is set in stone. We can always make changes to events, talks, outings, based on weather, consensus, etc. If you have anything you’d like added to the calendar, let me know.

TO THE LIST!

Now before I get too far ahead of myself, subscribe to the email list! More details and information will be sent there soon.

QUESTIONS:

Miann and myself are coordinating the sprint, do not hesitate to ask either of us if you have any questions. If you have questions about the sprint CONTENT (topics, talks, technology, etc.) ask me, if you have questions about sprint LOGISTICS (arrival times, travel directions, sprint fees) ask Miann. Of course, at the sprint, you can ask either of us for help with anything, anytime! We’re here to help!

SPONSORSHIP:

We are actively seeking sponsors for Snow Sprint 2008! If you are interested in sponsoring with a donation of any amount, or if you have ideas of companies or individuals that may be interested in sponsoring this year, please contact Spanky at sponsor@3×6x9.com – we are preparing information and contacting potential donors this week.

Thank you, danke, merci, grazie, tack själv, köszönöm, kiittää te, mulţumesc

1.) Python: vanilla python didn’t build on Leopard

run configure
add “#define SETPGRP_HAVE_ARG 1″ to pyconfig.h

Note: on two of our machines we got a strange error. I didn’t manage to fix it :( (Probably someone knows what’s going on?)

>>> a=5
>>> round(a)
Bus error

2.) PostgreSQL: postgresql82 in MacPorts didn’t build as well. the patch at the macports trac helped:

— Portfile.orig 2007-10-30 11:49:08.000000000 +1100
+++ Portfile 2007-11-17 00:42:45.000000000 +1100
@@ -50,6 +50,7 @@
configure.cppflags-append “-I${worksrcpath}/src/interfaces/libpq”

build.type gnu
+build.cmd “unset LD_PREBIND LD_PREBIND_ALLOW_OVERLAP && ${build.cmd}”
build.target

test.run yes
@@ -63,7 +64,7 @@

post-build {
foreach contrib ${contribs} {
- system “cd ${worksrcpath}/contrib/${contrib}/ && ${build.cmd}”
+ system “cd ${worksrcpath}/contrib/${contrib}/ && unset LD_PREBIND LD_PREBIND_ALLOW_OVERLAP && make”
}
}

@@ -71,7 +72,7 @@
foreach contrib ${contribs} {
system “echo contrib: \”${contrib}\”"
system “cd ${worksrcpath}/contrib/${contrib}/ && \
- ${build.cmd} install ${destroot.destdir} && touch DONE”
+ make install ${destroot.destdir} && touch DONE”
}
system “cd ${destroot}${prefix}/bin && ln -sf ${libdir}/bin/psql psql82″
file delete -force ${destroot}${prefix}/share/doc/${name} \

3) MySQLdb: had some troubles as well. The sourceforge tracker helped (patched tarball):

— _mysql.c.orig 2007-11-16 22:32:38.000000000 +0100
+++ _mysql.c 2007-11-16 22:33:42.000000000 +0100
@@ -34,9 +34,6 @@
#else
#include “my_config.h”
#endif
-#ifndef uint
-#define uint unsigned int
-#endif
#include “mysql.h”
#include “mysqld_error.h”
#include “errmsg.h”
@@ -481,8 +478,8 @@
#endif
char *host = NULL, *user = NULL, *passwd = NULL,
*db = NULL, *unix_socket = NULL;
- uint port = MYSQL_PORT;
- uint client_flag = 0;
+ unsigned int port = MYSQL_PORT;
+ unsigned int client_flag = 0;
static char *kwlist[] = { “host”, “user”, “passwd”, “db”, “port”,
“unix_socket”, “conv”,
“connect_timeout”, “compress”,

This time we chose Hotel Piz Buin in the Area of Silvretta, below the highest Peak of our State – Piz Buin

(image from Wikipedia)

Sprint organisation is done on http://www.openplans.org/projects/snow-sprint-2008
We’ll definitely focus on Zope3 and High Traffic related topics – Plone People welcome!

Highlight the week in your calendar, add your name to the Openplans Wiki and book your flight.

See you in the mountains!

Jodok and the lovely team

♥ Manfred, Michael, Jodok and Armin, Bernd, Bernd, Clemens, Jeroen, Johannes, Julian, Jürgen, Manuela, Maria-Anna, Markus, Michael, Stefan and the Webmeisters Gerd, Harald, Markus and Oliver.

——————–
While deploying the first egg based portal using zc.buildout we found that idle lovely.remotetasks caused a CPU load of 5% despite doing nothing.

After some investigation with the profiler:
lovely.remotetask throws an IndexError exception if there is no job to do. It is doing this once a second.
The publisher gets a traceback for the exception using python’s traceback module.
traceback.extract_stack() uses python’s linecache module.

Now here is the problem:
linecache is extremely slow when using eggs. We could measure 54 ms for the time spent in the zope publisher!

So we changed remotetask to not throw an IndexError.
But the publisher still took 27ms.

Profiling again showed us that traceback.extract_stack() was still called somewhere.

Finally we found it in zope.security.manager.py
newInteraction was storing a traceback to be able to print a nice traceback in case newInteraction is called a second time. This is really a good thing for the developer because you get a very detailed error report which shows you exactly from where newInteraction was called the first time.

But for which price:
Removing the extraction of the traceback put down the publisher time to

2ms

So we decided to remove this feature.
The change is now in the newest egg for zope.security version 3.4.0b2

With this new version we also measured the time with zope as a trunk checkout (no eggs involved).
The publisher is now twice as fast as it was before! newInteraction is called exactly once for each request but was taking 50% of the time (without eggs) for the publisher.

Here’s Jürgens lesson: “I’m writing this just to show everyone what can happen if not enough care is taken in really critical parts inside the zope core.”

——————–

Yay! good job guys.

Questions: 
Does someone know why running python code out of eggs is slower (e.g.  linecache)? Are there other functions that are slower out of eggs? What can be done against that?