Next week we’ll be sprinting in New York/San Francisco to get the Zope3 framework and the first lovely applications running on Google AppEngine. You’re welcome to join us.Google AppEngine is a perfect match to the transition we at Lovely Systems made during the last 12 month in “stealth mode”. We’re using heavily WSGI and are replacing ZODB within most of our applications.Tomorrow we’re leaving to New York visiting our friend reco. dobee and I will be working on getting the component architecture running on AppEngine. Later next week we’ll fly to San Francisco to attend Google I/O and get even more insight to the technology. We’re open to release lovely.nozodb and the related components in near future, as usual - just some polishing missing…Please drop me a note (jodok@lovelysystems.com, batlogg on skype/AIM) or give me a call (+43 664 9636963) if you want to join us.  

we made it. http://www.zoomer.de is finally online.

A large part of the Lovely Team was working hard during the last 6 month to get the thing going.

The Technology behind it? Lovely!

lovely.news = cutting edge Python/Zope3 software, PostgreSQL Databases, ZEO Clusters, WSGI pipelines, Varnish Caches, Nginx Reverse Proxies, F5 Load Balancers.

.

The content on zoomer.de? Lovely as well! A young, dynamic team. Backed by long-term news experts. Just watch their video and use zoomer.de :)

Thanks a lot, lovely team. especially quodt, jukart, schwendinger, dobee, jayeff, wolfabua, stmartin, iham, pjee, haudum. you rock!

Countdown for snow-sprint is running!

continue reading the full article

I switched to Leopard on the very first day,… Finally I managed to get the lovely dev environment working :)

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”,

Lovely Systems is proud to announce the 5th Snow-Sprint in a row. Between Friday 18th of January 2008 and 25th we’ll code, talk, eat, drink, sleep, ski, snowboard in the Austrian Alps.

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

A little bit more than 1,5 years ago we founded Lovely Systems. Michael, Manfred, Sasha and me… Meanwhile we’ve grown a little bit and it turned out that the two Companies Lovely Systems in Sweden and Austria were growing in different directions: Austria headed towards Zope3 based Web2.0 Portals (our sister company - Webmeisterei got our Austrian Plone business), Sweden sticked with Plone and is now Valentine Web Systems. So girls and boys, write down the 14th of February, it’s Mr. Valentines birthday. Sasha and Tim, we wish you the best for your future and looking forward to a fruitful cooperation!

♥ 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.

Download PDF

Here is a short story about a lovely executive report about what lovely people like Jürgen (jukart) and Bernd (dobee) are doing on an average friday :) They made some changes in the zope.security package:

——————–
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?

It’s official. Lovely Systems is Strategic Developer in the Zope Foundation. I’m proud to serve in the board of directors. A warm welcome to my board fellows and the new (second) committer-member representative: Tres Seaver.

continue reading the full article