Although it was tempting to try to rewrite the whole VOIP billing front-end in Django this evening as a test, I decided that getting OpenGL-ctypes moved forward would be a bigger net win for the world. So, sat down and wrapped the GLUT font pointers and the GLU tessellation structure/functions.
I've got to find a better way to do that. I wind up pretty much writing custom code for the whole GLU library... the auto-generated wrappers help somewhat, but the callback-using code just winds up with all sorts of specialised code because it has to deal with original-object-return, with turning incoming pointers into arrays for use in the Python code, and for retaining pointers to the cCallback objects.
Problem is, it's always going to be messy dealing with the low-level guts like this. An automated wrapper generator can't tell whether a GLdouble * is an array or an output variable. That information has to be added to the system by a human being who reads the documentation. SWIG handles it with the .i file... maybe we could write something similar for ctypes, but do it in such a way that it generates a second document to feed into the wrapper-generator. Reminds me, I need to go back and un-hack parts of the openglgenerator module, it currently makes all of the structure-accepting arguments look like matrix/array arguments, which means they need to be hacked back to make them work.
There's still a crash in the GLUT font rendering, and the GLUT context in general is non-functional. I seem to be going rather slowly on all this.
Comments
2010-07-25 14:02
> and would have no Trac integ ration The trac-bzr plugin[ 1] seems to provide good integ ration between bzr and t [...]
2010-07-13 21:47
I've always been fascinated wi th the Asterisk AMI interface. So much so that I married tha t fascination with the [...]
2010-07-03 21:32
Yes, only references in dicti onaries are replaced, so hold ing references in lists, tuple s, etceteras keeps them alive.
2010-07-03 11:18
They hold references to remove and install?
2010-06-24 08:34
There's higher-level objects w hich are tracking what is repl aced (the actual Mock objects) . They hold references [...]
2010-06-24 08:23
I haven't tried it, but it see ms to me like this approach ha s one fundamental problem: If you replace all refs o [...]
2010-06-24 08:22
That's the "magic" that made m e go "ooh shiny"
2010-06-24 06:03
That's even more evil than the mock patch decorator...
2010-06-06 18:33
blush Oh.
2010-06-06 11:07
That's what the module does (a utomatically), but on a per-te st-run basis, and only for the process being tested (i [...]
2010-06-06 02:43
Maybe I'm missing something im portant here, but why not just write small scripts to mimic whatever dangerous utili [...]
2010-06-05 15:17
I thought about stubbing out t he python call to the process in the current process, but I want something which stu [...]
2010-06-05 14:47
Hmm... if Mock isn't flexibl e enough to handle mocking pro cesses adequately then I'd lik e to know how it could b [...]
2010-05-19 10:27
Hey, maybe it's a stupid new bie question, but where and ho w exactly should the patching of the core take place? [...]
2010-05-04 14:36
I used Qemu and VirtualBox pre tty extensively back when I wa s working for the OLPC, but mo st of the stuff we were [...]