Codeblocks ported to sqrat

[BlueHazzard]

fixed and committed...

[oBFusCATed]

Thanks.

Here are two patches:
http://cmpt.benbmp.org/codeblocks/patches/sqrat/0001-scripting-Don-t-require-additional-include-paths-to-.patch
http://cmpt.benbmp.org/codeblocks/patches/sqrat/0002-scripting-Autotools-build-fixes.patch

(apply them with git am /path/to/patches/0*)

The first one simplifies the include path requirements for the scripting. The second one should fix autotools builds.

[oBFusCATed]

Is this branch ready for testing and probably merge?

[BlueHazzard]

Testing is requested!!  and probably also merging, but at first i would like to implement the wxPropertyGrid resource in the xrc system. My time is very limited at the moment, but maybe i will finish it today...

greetings

[BlueHazzard]

So i think i will give some update.

My new work and the university is claiming 120% of my time  :-\ , so i can't work on the port for at least the next month.
The current problem is, that there is a bug in the destruction of the script plugins with loaded dialogs (frames). i know how to fix the bug, but this takes some changes on the framework, and this needs time, what at the moment i don't have...

greetings...

[stahta01]

FYI: For proper Windows PCH creation sdk.h needs moved to src.

Code Select Expand


diff --git a/src/CodeBlocks.cbp b/src/CodeBlocks.cbp
index 1e6f409..090715d 100644
--- a/src/CodeBlocks.cbp
+++ b/src/CodeBlocks.cbp
@@ -1322,7 +1322,7 @@
<Unit filename="include/sdk.h">
<Option compile="1" />
<Option weight="1" />
- <Option target="sdk" />
+ <Option target="src" />
</Unit>
<Unit filename="include/sdk_common.h">
<Option target="sdk" />


Tim S.

[stahta01]

Patch to get Win32 wx30 cbp to build.

Code Select Expand


diff --git a/src/CodeBlocks_wx30.cbp b/src/CodeBlocks_wx30.cbp
index 72a5a0e..aaf47e5 100644
--- a/src/CodeBlocks_wx30.cbp
+++ b/src/CodeBlocks_wx30.cbp
@@ -1154,6 +1154,9 @@
<Unit filename="include/scripting/bindings/sq_wx/sq_wx_dialog.h">
<Option target="sdk" />
</Unit>
+ <Unit filename="include/scripting/bindings/sq_wx/sq_wx_propgrid.h">
+ <Option target="sdk" />
+ </Unit>
<Unit filename="include/scripting/bindings/sq_wx/sq_wx_type_handler.h">
<Option target="sdk" />
</Unit>
@@ -3158,6 +3161,9 @@
<Unit filename="sdk/scripting/bindings/sq_wx/sq_wx_base_controls.cpp">
<Option target="sdk" />
</Unit>
+ <Unit filename="sdk/scripting/bindings/sq_wx/sq_wx_propgrid.cpp">
+ <Option target="sdk" />
+ </Unit>
<Unit filename="sdk/scripting/bindings/sq_wx/sq_wx_constants.cpp">
<Option target="sdk" />
</Unit>


Tim S.

[oBFusCATed]

@BlueHazzard:

What version of Squirrel are you using in this branch?
Also have you seen this problem:

Code Select Expand


a<-_T("Test");
b<-_T("Test");
print(a==b); //<-- this one here prints false, instead of the expected true.

?
If you have seen it, then have you solved it?
I can see that other people have reported this problem and it has not been fixed.
There is also a patch that modifies the VM, see here: http://forum.squirrel-lang.org/mainsite/forums/default.aspx?g=posts&m=4084#post4084

@devs: What do you think of applying this patch to our VM?

[BlueHazzard]

What version of Squirrel are you using in this branch?

At the moment i'm using 3.0.4, but i will update to 3.0.6 after Alberto (fagiano) will release his bugfix, becaues there are two (non common) bugs that hopefully will get fixed.

Also have you seen this problem:

Code Select Expand


a<-_T("Test");
b<-_T("Test");
print(a==b); //<-- this one here prints false, instead of the expected true.


This is nor a bug nor a problem... This is how squirrel works with user pointers... You have to use a cmp function to compare the content of user pointers. In my version of the squirrel port this won't be a big problem, because you can work with native strings:

Code Select Expand


a<-"Test";
b<-"Test";
print(a==b);

FunctionThatOnlyCanUseWxString(a); // This will work...

c <- wxString("fail");
d <- "faile";
print(c==d); // This won't work...


It is not a intuitive thing, but if speed is what you want, this is the obvious way to deal with user pointers (and tables and strings and so on).
At the beginning i wanted to implement this patch, (or use the mingobad version of squirrel, because he has a few interesting features) but then i thought the base version of the language is used in a lot big projects, well tested and some kind of well maintained, so why use a patched untested version... I'm open for discussions on this...

In two weeks i will continue my work on this port...

greetings

[oBFusCATed]

I know that according to fagiano it is not a bug, but a feature.
But as far as I know C::B doesn't care for scripting performance, game-developers care.
We want to have something that is easy to use and not surprising. And non-working operator== for our types is quite surprising thing.
In fact it silently works and returns false, it is not a runtime error or something like that!
I'd probably be fine if this was a runtime error, so we'll know when it fails to work.

Also in HEAD we have not exposed any compare function for wxString or any other class, I don't know about your branch.

p.s. Can your tests for scripting be extracted and committed with the HEAD version of squirrel and its binding (probably partially)?

[BlueHazzard]

But as far as I know C::B doesn't care for scripting performance, game-developers care.

performance is always a requirement for c::d else i could go to eclypse

We want to have something that is easy to use and not surprising. And non-working operator== for our types is quite surprising thing.
In fact it silently works and returns false, it is not a runtime error or something like that!
I'd probably be fine if this was a runtime error, so we'll know when it fails to work.

This is a BIG point... It has to be considered... As I said, i'm open for using the == as it is expected (or, also adding a second operator for the old behaviour)

Also in HEAD we have not exposed any compare function for wxString or any other class, I don't know about your branch.

From the wiki: http://wiki.codeblocks.org/index.php?title=Scripting_commands#wxString
bool    Matches    wxString    not use '==' !!, returns true if the string contents matches a mask containing '*' and '?'

p.s. Can your tests for scripting be extracted and committed with the HEAD version of squirrel and its binding (probably partially)?

hmm... i don't remember if it is possible. I think i have added a lot string related things, that are needed in the output ( for ex. wxString constructor with native string) but it wouldn't be that hard to port, the base framework can be used for sure...

First thing i will do next is to make a separated squirrel binding version number from the sdk version number and list all difference from the binding site, so sdk version and binding version are two different numbers...

greetings

[oBFusCATed]

performance is always a requirement for c::d else i could go to eclypse

Yes, but when you don't have tight loops or calling scripts too much, then ease of use should win.
And in C::B no performance critical parts are implemented as scripts!

From the wiki: http://wiki.codeblocks.org/index.php?title=Scripting_commands#wxString
bool    Matches    wxString    not use '==' !!, returns true if the string contents matches a mask containing '*' and '?'

Not exactly the same as operator==, but it will do the job in my case. Thank you for showing it to me.

hmm... i don't remember if it is possible. I think i have added a lot string related things, that are needed in the output ( for ex. wxString constructor with native string) but it wouldn't be that hard to port, the base framework can be used for sure...

If it is too hard, just don't bother.

First thing i will do next is to make a separated squirrel binding version number from the sdk version number and list all difference from the binding site, so sdk version and binding version are two different numbers...

Sounds useful, I have been thinking about it, too.

[BlueHazzard]

Can please someone of the linux guys look over the last git hub code? i can't compile it on linux, because of undefined reference of the Property Grid XML Handler. I have looked in the libpropertygrid and it seems to get exported... It is for sure some stupid thing, but i can't find it...

thank you..

[oBFusCATed]

Are you talking about trunk/master or the code in your branch?

[BlueHazzard]

My github branch "work_ongoing"