Recent blog entries for lkcl

pyjamas output in my own html file with jquery


I want to reuse my python modules on html/jquery web pages.

Therefore I need to call the generated js fucntions genrated with pyjamas from my own html file.

Which .js files should I link?
How can I call the functions?

Example python file
def rmsToPeak( x ):
return x*1.41
def peakToRms( x ):
return x/1.41

Pyjamas output file functions.js:

/* start module: functions */Force
linebreak $pyjs.loaded_modules['functions'] = function (mod_name) {
if($pyjs.loaded_modules['functions'].was_initialized) return $pyjs.loaded_modules['functions'];
var $m = $pyjs.loaded_modules["functions"];
$m.repr = function() { return ""; };
$m.was_initialized = true;
if ((mod_name === null) || (typeof mod_name == 'undefined')) mod_name = 'functions';
$ = mod_name;

$m['rmsToPeak'] = function(x) {
var $mul2,$mul1;
return (typeof ($mul1=x)==typeof ($mul2=1.41) && typeof $mul1=='number'?
$m['rmsToPeak'].name = 'rmsToPeak';

$m['rmsToPeak'].bind_type = 0;
$m['rmsToPeak'].args = [null,null,['x']];
$m['peakToRms'] = function(x) {
var $div2,$div1;
return (typeof ($div1=x)==typeof ($div2=1.41) && typeof $div1=='number' && $div2 !== 0?
$m['peakToRms'].name = 'peakToRms';

$m['peakToRms'].bind_type = 0;
$m['peakToRms'].args = [null,null,['x']];
return this;
}; /* end functions */

/* end module: functions */

Syndicated 2011-08-15 17:58:35 from blog/lkcl


i'm looking up information about the PowerVR 3D SGX Engine in order to assist tomasz with his reverse-engineering project,

there is... a great deal of shit and misinformation out there. one of the down-sides of google android is that the number of forums has exploded, with the number of misinformed opinions and the sheer number of AOL-esque "metooings" just completely overwhelming the actually useful contributions - such as tomasz' work.

it took forever to find the GLES6410 project. and no, tomasz' work is NOT restricted to just the S3C6410 - it is very very relevant for absolutely all of the PowerVR SGX Series, due to the architecture of PowerVR. all that the CPU manufacturers do is provide a subtly different "shim" to access the PowerVR's registers and interrupts - that's it. beyond that: once you have a GPL Linux Kernel "shim" driver which makes the access to those registers identical right across all hardware - be it OMAP, Samsung, iMX series from FreeScale or even Intel PPA (Poulsbo, whatever, i don't actually care) from that point on it's pretty much all the same.

i say "all the same" but there do exist subtle bugs in the hardware implementations, and also variations such as the number of parallel engines and various upgrades / versions but effectively yes, it's all the same.

that makes tomasz' work um... incredibly valuable, and i would very much appreciate it if people could spread the word, pitch in and help him out. PowerVR has a hell of a lot of momentum and a very large amount of market share: it's too important to leave it to imgtec to maybe release a Free Software Library in Q3 2011.

GUI Builder Panel

Pyjamas Equivalent of Glade goes recursive…

well, i decided that just having a dynamic GUI-instatiator based on a text file wasn't enough, but that what was needed was both a widget (single dynamic instance instantiator) and a panel (subclass of that but then with an "add" method that can take the name of the widget-group to be created).

so, the UI text file contains a widget-group with a panel type in it (e.g. a Grid) called "builderpanel", and it also contains a widget-group with a… something - a row, for example, named "builderrow" in the UI text file. also in the widget-group with the panel is a button, named "add".

then, the button has the name of a callback in the UI text file, called "onAddClicked", and this function has to occur in the app, and is linked to the button. surprise-surprise, the action associated with this button is to create an instance of builderrow and to add it to the panel:

    def onAddClicked(self, sender):
        grid =
        row = grid.getRowCount() + 1
        grid.resize(row, 1)"builderrow", row, 0)

the weird thing is that at no time, in any code written, do you actually get to see what "the panel" is, because its layout is specified in the UI text file. also, nor do you see, in "python code", any of the widgets that are added as a row: there could be 50 widgets in that "row" being added, but you don't manually create them.

i think that's just wicked, and although i was originally deeply unimpressed with the idea of writing widget layouts using an application editor, i'm now completely converted to the dark side and will pretty much be doing nothing _but_ writing pyjamas applications with this method from now on.

Syndicated 2010-08-23 20:57:46 from blog/lkcl

pyjamas dynamic in-app GUI builder

dynamic creation of pyjamas GUI apps

kees bos a few months ago developed PyJsGlade which is an identical concept to wxwidgets "wxg"; glade with GtkBuilder for pygtk and qtGui for pyqt4. the basic principle is that you have a GUI-based "widget editor" tool, you edit a nice pretty app, you save it (usually as XML) and then you either auto-generate the entire app as a stub starting-point or you pass the file into a "builder" at run-time and it creates the GUI there-and-then

in python-wxwidgets there is as i understand it a bit of a problem: there is no runtime builder, but other than that, everything's hunky-dory. pyjamas, being the newcomer here, didn't have PyJsGlade until a few months ago, and kees didn't quite grok the run-time builder concept. for various reasons, i added it yesterday. ok, this morning, to be precise.

for various other reasons i'm going to make some enhancements to the concept, to effectively turn the builder class into the beginnings of an editor front-end. in other words, if you have an existing instance (which you'd like to keep), and you modify the GUI file, you can *reapply* the builder process on the existing instance and have it update properties, change positions etc. etc. instead of throwing it away.

neat, huh?

Syndicated 2010-08-15 11:38:58 from blog/lkcl


just announced an HL7 python importer, which is going to be used in gnumed. HL7 is a data exchange format for the medical profession. typically used to transfer information about patients, treatments, clinical lab reports and so on, it's _very_ comprehensive and has been through five revisions on the XML HL7 v3 specification, already.

HL7 basically stores typed hierarchical information in a flat file. it was created before XML came around, and now someone's added an XML wrapper on top of it.

there's an application called Mirth and unfortunately it's implemented in java. it's _big_ and therefore painful. for example, if you want to do something other than what mirth can cope with by default, you have to create a java extension or, even worse, a javascript one! connect the dots, with python and gnumed (which uses postgresql) and if you want to use mirth to transfer clinical lab data into gnumed, you have to know _eight_ separate programming technologies.

so i decided to look for some existing code in python, and adapt it. seems to be going well.

moinmoin jsonrpc at europython2010

ok, as part of the series of transitions to python-based technology for pyjamas, i was looking to convert the wiki at some point. it turns out that the moinmoin developers are here at europython2010, so i picked their brains and they helped me create a JSONRPC interface to moinmoin 2.0-dev. with adding page create and page load, the job's pretty much done in 150 lines of code (hooray!).

so the next thing is to add in git support, and then the existing wiki (ikiwiki) miight be convertible to a full pyjamas app (hooray!)

Syndicated 2010-07-20 22:26:26 from blog/lkcl

multitask cooperative single-process http server

egads, mouthful for a subject let alone a title of a wiki page. for various reasons i needed to create a single-process cooperative multitasking HTTP server. it seems, bar one small tolerable bug, that i succeeded in using it to create a special kind of HTTP proxy.

the problem is illustrated by being a desktop-based application and using role-based access control on the PostgreSQL database. they want to convert it to a web application, by popular demand, and tried picking random web server frameworks. unfortunately, virtually all web server frameworks assume that the SQL database is to be used for anonymous session cookie management, assume a single (global) username/password and so on.

for gnumed, such assumptions are completely unacceptable: this is confidential patient data, and there's no way that gnumed are going to redesign the database middleware to REMOVE password security.

so i came up with something that will frighten the bejabbers out of any normal web developer: a proxy which is capable of keeping a remote connection permanently open to its upstream target, as long as that upstream HTTP server supports HTTP Connection "keep-alive".

it's… well, i've been yapping about it enough, and so have the gnumed developers:

one of the problems with creating such a proxy is that you can't do it with a threaded or a forking architecture: you need to analyse the HTTP stream (check a session cookie and insert one if there isn't one) BEFORE you pass it on to the proxy, but most HTTP proxies are designed to fork first, think later.

the design also has several other uses, one of which is that it solves the issue that pyjamas-web faces. pyjamas-web is the version of pyjamas that actually executes a pyjamas app server-side and translates it into HTML. immediately you can see the problem, there, if you know that HTTP is stateless: how do you re-associate the actual in-memory running python application with the correct browser, when the application is sufficiently large that it is impractical to serialise it to disk?

Syndicated 2010-07-15 20:25:46 from blog/lkcl

mailing list transferred

hooray, another task done - sort-of. it appears that some messages were lost, leaving people wondering what the heck was going on, where's the "digest" mode (there isn't one in lamson, because zed always finds that people abuse it by replying "Re: Digest Volume 3.1415926")

had a bit of a fight with lamson: messages were bouncing from somewhere, causing multiple repeats i _cannot_ tell where from, so may end up fronting exim4 onto lamson despite my wishing not to do that. as i had to create a, the problem with redirecting to a remote queue goes away (exim doesn't redirect to properly, even if you change the SMTP port: there's supposed to be an option you can set to say "yes do it anyway" but…)

i'm getting people still saying "why are you doing this? why waste time reinventing mailing list software? why reinvent it with software that's _worse_ than [proprietary and] much better offerings? why not just use google groups" and i have to gently remind them - again - that their questions hold the answers: the alternatives are proprietary, and they're not pyjamas applications.

i stated that i'm going to uphold a principle - to use free software and to do pyjamas front-end apps - and to stop doing what i'm doing, even if it's "not as good right now" would be breaking that principle. i'm absolutely going to stick to my free-software-driven principles, because i can, and because i choose to, and that's really all there is to say.

if anyone wants to _help_ improve the software, now, they can. whereas, with the source code to, they can't. but we know this already: i just think people find it a bit unusual for someone to jump train _and_ "rip up the tracks" on a running project and start pumping on a cheap but 100% Cooperative-owned hand-driven railway cart, because they don't like the fact that the train and the carriages are all run by a big corporation.

i think… perhaps it's worthwhile mentioning the phrases "bitkeeper vs git" and "linus vs tridge" - not entirely accurate but i think you get the picture.

Syndicated 2010-07-06 15:43:11 from blog/lkcl

new mailing list almost done

ouch. lots done today. managed to delete apache config, had to recreate it. had to create due to conflicts with WSGI apache configs, i am _not_ going to try doing rewrite rules. almost got done: only need to do an email enable/disable feature and then i'm done: bye bye googlegroups.

Syndicated 2010-07-04 23:36:17 from blog/lkcl

great old hat

Django Piston

I found a great django framework extension, by virtue of accidentally searching for "django oauth":

If i didn't know pyjamas, I would be terribly excited by this extension. as it is, it's pretty good anyway (because of the json emitter for example, and the bandwidth throttling decorators).

but i find myself feeling… terribly sad, and strangely looking in pity on these excellent pieces of work, because they just look like so much damn hard work to make use of. generating pages server-side that mix data with the display mechanism is so… old! no matter how exciting and fresh the framework and the ideas and thought that goes into the framework, the technique is still "old" and inconvenient.

i feel very strange for having to point this out.

Syndicated 2010-07-04 10:46:33 from blog/lkcl

675 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!