Whoops, I turned on comment moderation (I was trying to get rid of spam) and then forgot to turn it off again. My apologies to those who commented.
I'm still working on Ruby integration although I am now completely off the beaten track. Below you can see screen shots of both my C++ defintion file and some preprocessed C++ that the defintion was being applied too.
Those with a keen eye will realise that there's not a hope in hell that the code at the bottom will compile. In fact the parser breaks on CChunkIndex which isn't defined anywhere; CChunkIndex is in an #include file I told the preprocessor not to follow.
More importantly the definition doesn't take typdefs and templates into account which is going to cause all sorts of fun when the parser gets to the line: typedef CArrayTemplate...
I suspect this oversight is going to cause me a rethink of my language definition language. I am now beginning to wonder if I may not have written a definition language specifically for C++. Oh well, time will tell.
Whilst I'm - sort of - on the subject of reinventing the wheel I'm going to have a quick rant about Garage Games; specifically the Torque scripting language. I can reinvent the wheel to my hearts content because I think it's fun and no one has mission critical code depending on me.
The torque scripting language is for use in production environments and, being proprietry, should be completed before its release to the general masses. Whilst browsing their documentation I noticed that there is a chapter dedicated to why their scripting language is complete but they have ommited one very important criteria.
As someone (I think it was language guru Prof Terry) said: "Any fool can write a compiler but it's much harder to write a compiler for fools". The torque scripting language handles bad input... badly. There seems to be one generic error message (something about bad context) and it points to the wrong line.
Trying to work out whats going wrong in a scene with three objects (the player, a bullet and an enemy) is difficult. I can't imagine what it must be like to try and solve parsing errors in a large project :(
For the price (R600 if I remember - Dave bought himself a copy) I suppose that this is something that one must live with. It is unforunate though...
And that's enough ranting, and enough posting also. So...
Later!
I'm still working on Ruby integration although I am now completely off the beaten track. Below you can see screen shots of both my C++ defintion file and some preprocessed C++ that the defintion was being applied too.
Those with a keen eye will realise that there's not a hope in hell that the code at the bottom will compile. In fact the parser breaks on CChunkIndex which isn't defined anywhere; CChunkIndex is in an #include file I told the preprocessor not to follow.
More importantly the definition doesn't take typdefs and templates into account which is going to cause all sorts of fun when the parser gets to the line: typedef CArrayTemplate...
I suspect this oversight is going to cause me a rethink of my language definition language. I am now beginning to wonder if I may not have written a definition language specifically for C++. Oh well, time will tell.
Whilst I'm - sort of - on the subject of reinventing the wheel I'm going to have a quick rant about Garage Games; specifically the Torque scripting language. I can reinvent the wheel to my hearts content because I think it's fun and no one has mission critical code depending on me.
The torque scripting language is for use in production environments and, being proprietry, should be completed before its release to the general masses. Whilst browsing their documentation I noticed that there is a chapter dedicated to why their scripting language is complete but they have ommited one very important criteria.
As someone (I think it was language guru Prof Terry) said: "Any fool can write a compiler but it's much harder to write a compiler for fools". The torque scripting language handles bad input... badly. There seems to be one generic error message (something about bad context) and it points to the wrong line.
Trying to work out whats going wrong in a scene with three objects (the player, a bullet and an enemy) is difficult. I can't imagine what it must be like to try and solve parsing errors in a large project :(
For the price (R600 if I remember - Dave bought himself a copy) I suppose that this is something that one must live with. It is unforunate though...
And that's enough ranting, and enough posting also. So...
Later!
posted by Andrew at
7:40 am
|
0 comments
