Re: Re: Re: Inline::C *back* into Perl

[tilly]

You consider that making it easy?

Here are a few issues to think through.

1. Any decent GUI program needs to handle interrupts well. It was doing X, the user decides not to and interrupts it. The API that you are describing offers no good way to pass interrupts along.
2. The system that you describe doesn't seem to have a lot of debugging hooks when things go wrong.
3. A huge problem with Expect is that unusual, unexpected or unanticipated input causes programs to diverge. When the GUI and internal program diverge on what they think is being displayed, you can readily get into deadlocks.
4. What you are describing sounds like a lot of overhead at all ends.

If you want a text-based cross-language approach to GUI developlment, I would suggest using httpd instead. No, it is not perfect. But it does a good job of addressing most of the above problems and furthermore has the virtue of already being built.

[flyingmoose]

Actually, yes, I consider this very easy. I'm not trying to brag, but this part isn't complicated as long as I can beat probable performance problems. There are design challenges, but they are not intractible.

HTML

The day you see 3D games and simulations written in HTML, is the day I award Tilly the Turing Award. Nah, man, you missed the whole point of why OpenGL was important :)

Interrupts

Are you familar with the GLUT main loop? Interrupts can easily be processed in "C" code and handed back to the consumer as commands over the pipe. This includes motion events, keyboard events, etc. Just because the API supported something when it was pure "C" doesn't mean it can't support this over an IPC boundary. We are just extending methods to work over such a boundary.

Debugging hooks

Well, OpenGL itself doesn't have a lot of debugging hooks either. Essentially, the most common bug is the well known "BlackScreenOfDeath", where your camera points off into space and there is nothing you can do to figure it out. I'm proposing a packet-level (essentially) system to interface to OpenGL over named pipes. That's all. Sending OpenGL commands out of order will be the problem of the caller, though debugging facilities are certaintly being coded in. Since both sides will have debug modes that echo all commands printed to the pipes to the console, I can see the exchange between the two sides fairly clearly.

So, as alluded to earlier, I decided on the named pipe approach not Expect... Expect looks to be a decent module, but if I use two named pipes, I get greater portability across multiple languages. Performance is still a concern, but if I use display lists, I think I can get decent performance regardless of the calling language. I already have a very clean OO Perl interface which I am currently using to debug the named-pipe system and the event handlers. Parsing, since I am keeping the protocol clean, will be kept to a minimum.

I have some rough documentation here, it's still not linked from the main page of my web site: Engine. My theory as to whether it would be possible to drive an OpenGL program from Bash is a little theoretical, I at least want to try it before claiming it is possible on my home page. I definitely will be able to code up some OpenGL support (sans-C-bindings) for many languages that normally cannot do 3D graphics.

Anyhow, check out the link, I'll probably some more coded up later this week to where I can show some code -- if I'm not doing my taxes, that is :)

again, doc link: here -- it's very rough. Be kind to it!