Re: [Doris] PyGame/PyOpenGL

[Nick T. <nic...@sh...>]

>> A debugger would help.
>ya think? =)

I wouldnt mind one for q2x either. I wonder if we could revive a VisualLua
one? We have one at work but obviously we can't use that. That one is
written in Python ;-). Actually there is a really basic debugger with wxLua.
I wonder if that would be the best route?

>> The tolua system saves a lot of manual work.
> But that works has been done already with the first pass, right?

I've found it just as easy to update the package file in the past, as it is
to put lots of markers in your header, but each to his own. Sometimes you
change prototypes because of parsing problems in the package. I find it
easier and quicker to just go through a file with lots of stuff commented
out.

> I would prefer that, immensely.  It's just far too easy to have the
.pkg and .h files diverge.

The following is an example from the tolua++ docs. Why don't you try this:

// tolua_export  -- export one line

//tolua_begin
  -- exports between the markers
// tolua_end

----->8----->8----->8----->8----->8----->8----->8--
#ifndef EXAMPLE_H
#define EXAMPLE_H

class Example { // tolua_export
private:
 string name;
	int number;

public:
 void set_number(int number);
 //tolua_begin
 string get_name();
	int get_number();
};
// tolua_end

#endif
----->8----->8----->8----->8----->8----->8----->8----->8--

> This could be presented as an additional tool. I don't really find
> the existing system that much of a hassle.

That's because you use Python =)

> these are entirely optional. I don't think the Lua parser or
> compiler should be, or needs to be changed.

> How would you add classes that would generate static compile time
errors without modifying the parser?

You could do it as a preprocess. I think a debugger would probably be the
most useful thing though. Once you get used to it, not have strong type
checking really isn't a problem. There are lots of Python docs and users
which say the same.

Nick