RE: [Doris] PyGame/PyOpenGL
Brought to you by:
trout
|
From: Nick T. <ni...@ro...> - 2004-05-01 00:39:31
|
> > I think it's because Lua defaults the value to nil if it doesn't > > find something, whereas Python recognises that its a typo. You can > > change Lua to find none existant globals using a metamethod, > > perhaps just in the debug version. Should we add this as an option > > to Doris? >=20 > Possibly, but it only sort of helps -- you still have to find the > error at run-time, and you have to go through some hoops when you DO > want to declare a global variable. It changes things enough that it > sort of stops being a Lua program. A debugger would help. > > One thing you need to do is update the GLUI packages in Doris so > > the binding can be auto generated. What else do you see will take > > all this time? > I can't stand the .pkg system. I really dislike tolua() and would > prefer to use manual bindings, to be honest. Having two sets of > headers is silly, and having it export all by default is also silly. I > would much prefer to do something like a tag for exporting to Lua, > e.g. > LUA_EXPORT void function( void ); > Is something like this possible? The tolua system saves a lot of manual work. You just have to go through and edit the interface you want to present in Lua and it does the rest for you, and all the error checking. Writing large bindings is tedious. If there were some benefit, like you want to do some clever Lua stuff then it might worth doing. For example, with enet I'd like to try doing the write to a table and it replicates idea, so there is a benefit to hand coding here. GUI APIs are just calls though and there is little benefit to hand coding. I'd say go ahead and hand code it if you like, but then if you didn't maintain it, I would have to, and I don't want to, so I'm not going to say hand code it! :) Tolua does present a mechanism to parse the .h files directly and only take out the bits you want, but you have to add // tolua_start // tolua_end style markers all over the place. This would then mean that if you redistributed this code it would contain these markers. It really doesn't take that long to do it by hand. The reason why I do it manually in this case is because I've tried other solutions and they just make the code look ugly and complicated and it doesn't save any time. In q2x I wrote a python script to generate bindings and declare variables, but this is really just to help with the conversion to Lua. Once this work is done the script will/should no longer be necessary. > > What needs doing? I thought you'd just have to swap over the half > > dozen callbacks to let the widgets operate and set GL up. I'm > > pretty sure there is code to use GL with SDL already. What else > > needs doing? >=20 > Well, all the back end stuff has to get going as well. Back end? Do you mean start up GL? I pretty sure there is code to do that in SDL. Is SDL that much hassle to get going? Please expand. > > I think some sort of class support and more though about modules > > and structure, using support from function environments, needs > > adding at this point. These could be offered as part of Doris? >=20 > I was envisioning a type system that could be done almost entirely > with a preprocessor, something like: This could be presented as an additional tool. I don't really find the existing system that much of a hassle. I thing the best solution is to provide a couple of util libraries which provide global checking and class support, and perhaps preprocessing and these are entirely optional. I don't think the Lua parser or compiler should be, or needs to be changed. Nick |