Hi folks,
i finally managed to finalize the "pre alpha" release of the codeblocks port of sqrat.
With "pre alpha" I mean: it should be usable, and all scripts that worked with the old implementation should also work with this one (with some work, see more down).
The code can be found here: https://github.com/bluehazzard/codeblocks_sf
What is new:
* Use sqrat instead of sqplus
why?
Sqplus isn't maintained since a wile now. My initial intention was to port some more wxWidgets stuff to c::b, but the lack of features from sqplus (different ctors etc.) obstruct this. So I decided to try to port c::b to sqrat.
Advantages?
- Maintained and developed in the future
- Different Ctors for classes (no copy, copy only etc.)
- Easy parameter specialization
- Relative easy interface
* Use squirrel 3.X.X
What is the difference from the user site:
Script:
1) Squirrel scripts can now use native strings and wxStrings. No need of _T() or wxT
2) Squirrel scripts use now UTF8 and have a "full" unicode support
3) Constants are now really constants and not some obscure get functions
4) Many new functions (and more will follow)
5) The API is broken :'(. This is a consequence of squirrel 3.X.X and 3) but not as serious as it might appear, because it exists a convert plugin that (hopefully) can resolve all breaks.
Main GUI site
1) Error handling is now centralized and has a uniform layout
2) Errors are way more informative
3) The sdk interface to the script is more intuitive
4) It is prepared to use multiple vm
5) A test suite for the squirrel binding
More about the API break and how to resolve it:
In squirrel 3.X "base" is a new keyword, so it can't be used as variable name anymore.
The constants (ex. PLATFORM, PLUGIN_SDK_VERSION_MAJOR) are now real constants and not get functions from the RootTable. So thy can't be accessed anymore with "::PLATFORM". The "::" isn't necessary anymore. So now you have to use "PLATFORM". Why does I broke this? In the old binding you could change this const values (ex "EXECUTABLE_EXT = _("blabla") "). this is not intended. Now constants are real squirrel strings and replaced at compile time.
How do use my old scripts? Simply:
1) open the scripting console
2) open the src/scripts/ConvertOldToNewScript.script
3) run Plugins/Convert Scripts
4) select the scripts you want to convert (multiple files should work)
5) the plugin should now convert all constants to the right name and replace "base" with "_base"
The main work should be done. But I need some help for a few things:
1) Code style and naming conventions: I have added new classes and files and don't know if the names are acceptable.
2) Testing!!! I don't have many scripts available, so I could not test the full interface.
3) Some look over sq_wx_type_handler.h. Im not fully happy with the Var<const wxString&> implementation
4) Memory leaks. I hope I don't have introduced some leaks .
5) wx3.0 and x64 support ( I will upload the project files later).
6) Documentation: I have tried to implement some documentation with doxygen, but it isn't pretty nor complete. Has someone an idea how to improve it, or make it more readable.
7) Git. The branche is not in sync with the main branch. From quite a long time now. Can someone tell me how I can easily resync with the main branch, without 1000 conflicts...
greetings
I haven't look into your source code(I'm not familiar with either sqrat nor sqplus), but from what your post wrote, it was excellent work! Many thanks.
Quote7) Git. The branche is not in sync with the main branch. From quite a long time now. Can someone tell me how I can easily resync with the main branch, without 1000 conflicts...
Git rebase onto the current C::B head? So patches will apply one by one.
Its very interesting, indeed - however, I am not a GIT user and merging the changes into SVN manually is really hard (I tried, but gave up meanwhile ::)). You should try what ollydbg said and try re-base your copy, so that it is in sync with trunk and we can easily create a patch or alike. If you manage, you can do this more regularly from there on.
Morten: It is time to try it, then you won't look back to svn again, I promise:) BTW, I think github allows you to download the head of some branch as an archive (Download as ZIP button)
BlueHazzard: svn doesn't handle git merges, so you have to have linear history. Also it is good to do a cleanup of commit messages and some useless commits you have. See this for an overview of git rebase -i http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html
Otherwise pretty good job. What OSes have you tested this?
Quote from: BlueHazzard on February 12, 2014, 02:43:22 PM
7) Git. The branche is not in sync with the main branch. From quite a long time now. Can someone tell me how I can easily resync with the main branch, without 1000 conflicts...
Unfortunately you'll have to fix the conflicts once more time and you'll have to refix the old conflicts you've already fixed, but after you fix them then won't show up again.
It seems that you haven't fixed the autotools build system, the -unix.cbp project file is similarly broken.
Do you have any plans to do it?
Edit: Ignore the part with the -unix.cbp. It turned out that I was using old code.
Just for the record: you can use a github repo with git (obviously) and svn (https://help.github.com/articles/support-for-subversion-clients (https://help.github.com/articles/support-for-subversion-clients)).
Quote from: jens on February 13, 2014, 06:26:38 AM
Just for the record: you can use a github repo with git (obviously) and svn (https://help.github.com/articles/support-for-subversion-clients (https://help.github.com/articles/support-for-subversion-clients)).
Yes, I know about this and already using it. Still, it does not help to merge trunk into this repo to be up to date again. :-/
Quote from: jens on February 13, 2014, 06:26:38 AM
Just for the record: you can use a github repo with git (obviously) and svn (https://help.github.com/articles/support-for-subversion-clients (https://help.github.com/articles/support-for-subversion-clients)).
I made now a rebase and pushed it to github. I don't know if this was a good decision (because of the rewriting of the history...)
Don't worry too much about it. And keep in mind that the history will be re-written anyway when these changes land in trunk (git svn dcommit will make sure to execute git svn rebase)
I have now created a separate script plugin class and manage all events from there.
I added the possibility to use c::b events in scripts.
I had some difficulties with the menu events not getting handled. But after updating my compiler from 4.7 to 4.8 all works. I don't know if this had do do with a "hard" rebuild, or with the compiler version.
Can please someone test this build with a different compiler then 4.8.1 and look if the menu and c::b events work? Of course all others are also invited to test...
procedure to test:
1) Compile all
2) Run C::B sqrat port
3) Open scripting console
4) In the script console open "scripts\test\script-test-plugin.script"
5) Run Menu->Plugins->Test scripting
6) Check scripting console for output (The Volume test fails)
7) In the script console open "scripts\test\event-test-plugin.script"
8) Run Menu->Plugins->Test Event scripting
9) Open and close random project and files -> Check in the console for errors
10) Reload a plugin (repeat step 4->9 or 7->9)
thank you
greetings
Hi!
i have found a bug. A very strange bug. Can please someone review this code, if it is right:
template<>
struct Var<const wxString&> {
const wxString& value;
wxString tmp_value;
Var(HSQUIRRELVM v, SQInteger idx) : value(tmp_value){
if (!Sqrat::Error::Instance().Occurred(v)) {
wxString* ptr = ClassType<wxString>::GetInstance(v, idx);
if (ptr != NULL) {
tmp_value.Append((*ptr).c_str());
} else {
Sqrat::Error::Instance().Clear(v);
const SQChar* str;
sq_tostring(v, idx);
sq_getstring(v, -1, &str);
tmp_value = wxString::FromUTF8(str);
sq_pop(v, 1);
}
}
}
static void push(HSQUIRRELVM v, const wxString& value) {
ClassType<wxString>::PushInstanceCopy(v, value);
}
};
i need the member value to be a const ref to a wxString.
On linux this code works without problems on windows it worked with gcc 4.7 but with 4.8 the value overwrites some other variables in the code.
You can reproduce it with this steps:
1. Compile c::b from my git hub repo
2. Set breakpoint at "include/scripting/sqrat/sqrat/sqratGlobalMethodes.h" at line 184 and 185
3. Start the debugger
4. load the script "scripts/ConvertOldToNewScript.script"
5. run the script from menu plugins->Convert Scripts
5b. if a messagebox pops up press ok
6. The debugger will now stop on breakpoint 1: Look at the variable "method". It will hold the right address for the function "wx_GetFileFromUser"
7. Continue the debugger one line, it will stop on breakpoint 2
8. The pointer "method" does not point anymore to a valid function....
after investigating i found the error in the source posted previously. The address gets changed at the initialization of the reference in the first line of the constructor...
i have no clue why, or how i should fix this, because for me the code looks ugly but right...
greetings
Why do you need tmp_value and value? This seems quite odd.
You have to talk to a c++ expert but I suppose the value(tmp_value) initialization is an undefined behaviour, because the members are initialized in the order they are declared, not the order you use them in the initializer list. So you're initializing value to be a reference to uninitialized object.
If you can reorder the members, you could try it.
i tried it, but now it crashes in on a other place, and i haven't discovered yet where....
funny....
Do you know why you need the reference?
I have fixed the error. It was interesting: When i debugged the source, it jumped in the right specialized template function, but if i printed the value type outside specialized the function it showed me the wrong type. On the end i had to include the header file to the right places... it is pretty tricky to find such a error, without compiler warning, and also the right programflow, but perhaps with a wrong value interpretation...
still waiting for test results with bigger script plugins ;)
new added:
- wxBell
- wxDirSelector
- wxMessageBox
greetings
Why are you adding wxMessageBox as cbMessageBox is preferred?
i missed that cbMessageBox exists -.- i will revert this...
i added also:
* the possibility to use c::b events
* Test script to test c::b events
* Test script to test user dialogs
New added:
* XRC Dialogs can now be loaded and shown modal and not modal
* "any" wxWidgets Dialog event can now be processed in script
* The possibility to create also nested menus from a script
* Menus get cleared after unregistering a plugin
* Add function UnRegsiterPlugin to the script binding
* The "Plugin Configuration Dialog" shows now also script plugins, and they can be uninstalled (for now only unregistered) from there
* Test plugin for XRC dialogs
* Test plugin for menus
* Updated all test plugins to appear only in the Plugin/Test submenu
* Add more wxString bindings
!!!! The old script plugin samples and also the wiki are wrong. In the consructor of the plugin there needs to be the line
info = PluginInfo();
if this line isn't present all plugins share the same info field and the names get overwritten every time a new plugin gets created.
For reference: http://www.squirrel-lang.org/doc/squirrel3.html#d0e1672
still needs some testers with different compiler versions...
greetings
I hope you know you can edit the wiki yourself (use the login details for the forum).
Quote from: oBFusCATed on April 07, 2014, 12:18:27 AM
I hope you know you can edit the wiki yourself (use the login details for the forum).
Yes, i edited the wiki a lot in the past ;)
in the actual implementation of c::b and squirrel this makes no difference but in the implementation with sqrat it wont work...
I will update the wiki, as soon as the sqrat port will go into trunk...
* Add some basic wx controls functionality (didn't had time to test)
* Add more controls. Now implemented:
wxEvent, wxTextCtrl, wxButton, wxAnimationCtrl, wxCommandLinkButton, wxCheckBox, wxChoice, wxCollapsiblePane, wxComboBox, wxRadioBox, wxGauge, wxHyperlinkCtrl, wxRadioButton, wxListBox, wxCheckListBox, wxStaticText, wxSlider, wxToggleButton, wxSearchCtrl, wxColourPickerCtrl, wxDirPickerCtrl, wxFilePickerCtrl, wxTimer, wxSpinButton, wxSpinCtrl
i haven't exported all functions, only the important one.(Almost) All functions are documented with doxygen (markdown). The controls can't be created on "runtime", only imported from xrc files.
You can test the implemented controls with the xrc-test-plugin.
instruction:
1.a) Download https://github.com/bluehazzard/codeblocks_sf and compile it
1) Open Script console
2) Open "scripts/test/xrc-test-plugin.script"
3) Start test with Plugins->Test scripting-> Test XRC
4) open "scripts/test/xrc_test.xrc
5) test the controls and discover the gimmicks/bugs ;)
my plan for the future:
* implement wxPropertyGrid (next main goal)
* implement the possibility to install script plugins with the Plugin->Manage Plugins-> install
* encapsulate script plugins in .cbplugin container (for delivering xrc and script files ins one container)
* implement wxFrame
* implement wxTreeCtrl
i think the main controls are implemented now. I don't know if tabs and ScrollBars are necessary...
greetings
Hello,
I unfortunately do not currently have the time to test your excellent work.
It's a pity, because I have "wxTranslatepluginForCB" transpose.
I recouped "https://github.com/bluehazzard/codeblocks_sf" by Tortoise.
Sincerely
Two patches, so far:
http://cmpt.benbmp.org/codeblocks/patches/sqrat/0001-scripting-no-pch-build-fix.patch
http://cmpt.benbmp.org/codeblocks/patches/sqrat/0002-scripting-Fix-compilation-it-seems-that-Play-doesn-t.patch
I'm trying to make the thing to compile with autotools and noPCH.
And I'm hitting a road block:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../../../src/sdk/scripting/bindings -I../../../../src/include -I/usr/lib64/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -I../../../../../src/include -I../../../../../src/sdk/wxscintilla/include -I../../../../../src/include/scripting/squirrel -I../../../../../src/include/scripting/bindings -I../../../../../src/include/scripting/sqrat -ansi -DTIXML_USE_STL -O2 -ffast-math -DCB_AUTOCONF -fPIC -DPIC -fexceptions -MT sq_wx/sq_wxBaseControls.lo -MD -MP -MF sq_wx/.deps/sq_wxBaseControls.Tpo -c ../../../../../src/sdk/scripting/bindings/sq_wx/sq_wxBaseControls.cpp -fPIC -DPIC -o sq_wx/.libs/sq_wxBaseControls.o
In file included from ../../../../../src/include/scripting/sqrat/sqrat/sqratTypes.h:39:0,
from ../../../../../src/include/scripting/sqrat/sqrat/sqratAllocator.h:35,
from ../../../../../src/include/scripting/sqrat/sqrat/sqratObject.h:34,
from ../../../../../src/include/scripting/sqrat/sqrat/sqratTable.h:34,
from ../../../../../src/include/scripting/sqrat/sqrat.h:33,
from ../../../../../src/include/scripting/bindings/sq_wx/sq_wx_type_handler.h:5,
from ../../../../../src/include/scripting/bindings/sq_wx/sq_wxBaseControls.h:4,
from ../../../../../src/sdk/scripting/bindings/sq_wx/sq_wxBaseControls.cpp:2:
../../../../../src/include/scripting/sqrat/sqrat/sqratClassType.h: In instantiation of 'void* Sqrat::ClassTypeData<C, B>::Cast(SQUserPointer, SQUserPointer) [with C = wxSpinCtrl; B = wxSpinButton; SQUserPointer = void*]':
../../../../../src/sdk/scripting/bindings/sq_wx/sq_wxBaseControls.cpp:1104:1: required from here
../../../../../src/include/scripting/sqrat/sqrat/sqratClassType.h:64:13: error: invalid static_cast from type 'wxSpinCtrl*' to type 'wxSpinButton*'
../../../../../src/include/scripting/sqrat/sqrat/sqratClassType.h: In instantiation of 'void* Sqrat::ClassTypeData<C, B>::Cast(SQUserPointer, SQUserPointer) [with C = wxGauge; B = wxGaugeBase; SQUserPointer = void*]':
../../../../../src/sdk/scripting/bindings/sq_wx/sq_wxBaseControls.cpp:1104:1: required from here
../../../../../src/include/scripting/sqrat/sqrat/sqratClassType.h:64:13: error: invalid static_cast from type 'wxGauge*' to type 'wxGaugeBase*'
../../../../../src/include/scripting/sqrat/sqrat/sqratClassType.h: In instantiation of 'void* Sqrat::ClassTypeData<C, B>::Cast(SQUserPointer, SQUserPointer) [with C = wxComboBox; B = wxChoice; SQUserPointer = void*]':
../../../../../src/sdk/scripting/bindings/sq_wx/sq_wxBaseControls.cpp:1104:1: required from here
../../../../../src/include/scripting/sqrat/sqrat/sqratClassType.h:64:13: error: invalid static_cast from type 'wxComboBox*' to type 'wxChoice*'
Makefile:477: recipe for target 'sq_wx/sq_wxBaseControls.lo' failed
make[4]: *** [sq_wx/sq_wxBaseControls.lo] Error 1
Is there any real reason you have to bind the wxXXXBase class? This is an implementation detail the wx user shouldn't care!
Other notes:
1. There is an include for sqplus in a lot of places, still.
2. sqrat/sqrat looks ugly, I'd prefer if you remove one of the levels.
3. It will be good if all public headers for scripting could be included without the need of additional paths
4. Please keep filename only with lower case letters and underscores.
Quote from: LETARTARE on April 16, 2014, 09:47:57 AM
Hello,
I unfortunately do not currently have the time to test your excellent work.
It's a pity, because I have "wxTranslatepluginForCB" transpose.
I recouped "https://github.com/bluehazzard/codeblocks_sf" by Tortoise.
Sincerely
remember if you want to try your plugin you have to add the line
info = PluginInfo();in your constructor and to run the converter script like i described in my first post.
Quote from: oBFusCATed on April 16, 2014, 11:41:47 PM
Two patches, so far:
http://cmpt.benbmp.org/codeblocks/patches/sqrat/0001-scripting-no-pch-build-fix.patch
http://cmpt.benbmp.org/codeblocks/patches/sqrat/0002-scripting-Fix-compilation-it-seems-that-Play-doesn-t.patch
I'm not at my main pc so i can't test. Thanks for the work, because i never did something with PCH...
Quote from: oBFusCATed on April 16, 2014, 11:41:47 PM
1. There is an include for sqplus in a lot of places, still.
2. sqrat/sqrat looks ugly, I'd prefer if you remove one of the levels.
3. It will be good if all public headers for scripting could be included without the need of additional paths
4. Please keep filename only with lower case letters and underscores.
1. Hmm... i will search and remove them
2. indeed this is really ugly, but i don't wanted to change the sqrat code (the code in sqrat.h) and leave it simple to update sqrat, by only coping the sqrat folder
3. It shouldn't be necessary to use additional paths outside the scripting internal stuff. Inside scripting (like the wx thing) i used additional paths, because it was a lot work to keep in sync all include directories over all project files. I will again look into it. Thanks for pointing it out.
4. Will look into it,
Quote from: oBFusCATed on April 16, 2014, 11:41:47 PM
Is there any real reason you have to bind the wxXXXBase class? This is an implementation detail the wx user shouldn't care!
I tried to compile the code on linux today and hit the same errors. Sqrat needs the base classes for its internal type checking. I think there are needed some #ifdef because some wx controls don't have a base on linux... Still some work... ;(
greetings
Quote from: BlueHazzard on April 19, 2014, 10:53:02 PM
2. indeed this is really ugly, but i don't wanted to change the sqrat code (the code in sqrat.h) and leave it simple to update sqrat, by only coping the sqrat folder
I don't see what the problem will be. Now you have sqrat/sqrat.h and sqrat/sqrat/* if you remove the top folder you'll have sqrat.h and sqrat/* and I don't see how this will make the updating of sqrat tough and problematic.
just uploaded a fix for the unix build... (not pretty but functional, and i don't think there is a better solution, because of the different implementation on every platform...)
greetings
/home/obfuscated/projects/codeblocks/git/src/sdk/menuitemsmanager.cpp|118|warning: deleting object of abstract class type 'Menu_point_base' which has non-virtual destructor will cause undefined behaviour [-Wdelete-non-virtual-dtor]|
This is pretty bad warning/error, please fix!
Edit:
/home/obfuscated/projects/codeblocks/git/src/sdk/menuitemsmanager.cpp|201|warning: unused variable 'sub_menu' [-Wunused-variable]|
This one seems like a bug, too.
fixed and committed...
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.
Is this branch ready for testing and probably merge?
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
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...
FYI: For proper Windows PCH creation sdk.h needs moved to src.
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.
Patch to get Win32 wx30 cbp to build.
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.
@BlueHazzard:
What version of Squirrel are you using in this branch?
Also have you seen this problem:
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?
Quote from: oBFusCATed on July 06, 2014, 02:34:07 AM
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.
Quote from: oBFusCATed on July 06, 2014, 02:34:07 AM
Also have you seen this problem:
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:
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
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)?
Quote from: oBFusCATed on July 06, 2014, 12:28:16 PM
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 ;)
Quote from: oBFusCATed on July 06, 2014, 12:28:16 PM
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)
Quote from: oBFusCATed on July 06, 2014, 12:28:16 PM
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 (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 '?'
Quote from: oBFusCATed on July 06, 2014, 12:28:16 PM
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
Quote from: BlueHazzard on July 06, 2014, 02:03:19 PM
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!
Quote from: BlueHazzard on July 06, 2014, 02:03:19 PM
From the wiki: http://wiki.codeblocks.org/index.php?title=Scripting_commands#wxString (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.
Quote from: BlueHazzard on July 06, 2014, 02:03:19 PM
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.
Quote from: BlueHazzard on July 06, 2014, 02:03:19 PM
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.
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..
Are you talking about trunk/master or the code in your branch?
My github branch "work_ongoing"
You miss wxpropgrid from the link-libraries in the linux project-file.
In sc_plugin.cpp you miss "()" afgter GetName in line 77.
But with all that I get:
/home/jens/codeblocks-build/codeblocks.bluehazzard/src/sdk/scripting/bindings/sq_wx/sq_wx_base_controls.cpp:1221: undefined reference to `ScriptBindings::sq_wx_propgrid_wrapper::GetLabelEditor()'
/home/jens/codeblocks-build/codeblocks.bluehazzard/src/sdk/scripting/bindings/sq_wx/sq_wx_base_controls.cpp:1220: undefined reference to `ScriptBindings::sq_wx_propgrid_wrapper::GetEntry(wxString)'
/home/jens/codeblocks-build/codeblocks.bluehazzard/src/sdk/scripting/bindings/sq_wx/sq_wx_base_controls.cpp:1219: undefined reference to `ScriptBindings::sq_wx_propgrid_wrapper::GetRoot()'
/home/jens/codeblocks-build/codeblocks.bluehazzard/src/sdk/scripting/bindings/sq_wx/sq_wx_base_controls.cpp:1218: undefined reference to `ScriptBindings::sq_wx_propgrid_wrapper::GetSelectedProperty()'
/home/jens/codeblocks-build/codeblocks.bluehazzard/src/sdk/scripting/bindings/sq_wx/sq_wx_base_controls.cpp:1217: undefined reference to `ScriptBindings::sq_wx_propgrid_wrapper::Populate(Sqrat::Table)'
/home/jens/codeblocks-build/codeblocks.bluehazzard/src/sdk/scripting/bindings/sq_wx/sq_wx_base_controls.cpp:1215: undefined reference to `ScriptBindings::sq_wx_propgrid_wrapper_constructor(SQVM*)'
as error while linking.
Simple solution:
"sq_wx/sq_wx_propgrid.cpp" is not added to the project.
"sq_wx_propgrid.h" is also not added, but this does (obviously) no harm.
cctest-project also needs to be linked with wxpropgrid now and we get tons of warnings about not handled enum-values in libFinder-plugin.
But besides of that the linux workspace-file seems to compile fine.
*facepalm* thanks jens.... I thought wxpropgrid is a standard library, so i didn't thought that it wasn't included...
well it is bad that the sdk has a other dependency to a gui component...
So lets give some update here:
I have worked a lot in the last time, so i hadn't time to write much code, but anyway i have made some improvements:
Now it is possible to make plugins in squirrel. This means no compiling for different platforms, and having problems with binary files. Simply write your plugin in squirrel, your dialogs in xrc files and pack it to a .cbplugin file and distribute it. I will describe the detailed process, like file handling , sometime later (probably tomorrow).
For now you can test the whole thing with a plugin i uploaded on github: https://github.com/bluehazzard/cdSelectiveCompiling . You need only the "SelectiveCompiling.cbplugin" file (it is a zip file). It is a neat plugin that helps you compile large projects. The ui is sh*t, because i have my problems with the xrc file format. I will update it in the next days.
A detailed instruction how to install and use the plugin is in the readme.md file in the repository.
I'm not 100% sure if my c::b version will compile on linux, because there are some changes in sqrat, and i had no time to test it on linux. (if it won't compile try to remove the SCRAT_EXPORT and SCRAT_IMPORT compile options in the "sdk" and "compiler" targets).
[Edit:] On my linux workstation i can compile it, and it runs fine. (from time to time there is a block when i compile, but i can't reproduce it with the debugger)
As always i hope i get some feedback. (and some help with the precompiled header files)
greetings
Quote from: BlueHazzard on December 15, 2014, 02:17:07 AM
[Edit:] On my linux workstation i can compile it, and it runs fine. (from time to time there is a block when i compile, but i can't reproduce it with the debugger)
Next time it happens, please inspect your processes for wx-config/compiler zombies.
There is some strange bug in wxExecute that happens only when cb is started from terminal...
So some new updates:
The porting is done, and i don't find big bugs anymore.
Big changes since my last update:
- I have added the ability to debug squirrel scripts within c::b or any other squirrel application what uses the sqdbg library. This squirrel debugger is a separate plugin: https://github.com/bluehazzard/cbSquirrelDebugger
The actual branches on my git repo: https://github.com/bluehazzard/codeblocks_sf
- sq_debugger: You need this branch if you want test the c::b squirrel debugger. I will merge this in "cb_push_candidate" as soon as possible
- cb_push_candidate: On this branch i try to integrate my code with the trunk of c::b so that i can make a big patch and post it.
- wx30_push_candidate: On this branch i try to integrate the whole wx30 stuff. This will also be merged (or rebased) on "cb_push_candidate"
I have currently stopped implementing new stuff ( i have tons of ideas, but they have to wait), and started to review code, add documentation and find bugs. As I mentioned earlier in this thread i don't like the current include structure. I try to minimize the dependencies to header files and implement a structure for PHC. On this i could need a lot help, because i have no big experience with managing include structures.
A other work in process is the testing suite. There are still missing a lot tests, and the xrc test stuff needs a lot cleanup.
So where does i need really help from outside:
- I need help on reviewing the changes
- I need help on finding unnecessary changes in the code i have made (this whole porting process is now older than a year, I think there is a lot garbage in the code)
- reviewing specially this commit: https://github.com/bluehazzard/codeblocks_sf/commit/1fa5d5af802aa4a414dc9c6e5e67739827ad8736
- I need help on implementing the pch build process
- I need help on fixing the autobuild process ( i haven't done any work on this)
My todo for the next few days (or weeks, my time is currently limited)
- Merge all branches to "cb_push_candidate" and try a rebase to trunk
- Fix the xrc test (currently they don't work and i have to look into it why. Meanwhile you can test the XRC stuff with this plugin: https://github.com/bluehazzard/cbSelectiveCompiling)
- Fix a bug where are showed multiple copies of one error message in the scripting error dialog (this is only a cosmetic bug)
- Complete the test suite (here i can also need some help from "script kiddies" ;) )
After this changes i think the port is ready and all features for a good scripting base are implemented. If you want my changes we have then to clear how we bring them to trunk (patch or branch or whatever).
I still need testers and bug reports, because now i'm "blind" with my own work flow, i don't find glitches or non intuitive things, so someone from the outside needs to point them to me.
After the merging to trunk i have this todos:
- Implement the install.xml handling also for binary plugins*) (this is a secondary goal)
- Add scripting to the debugger (specially events for BREAK and function to add watches and watch values from the script, so that you can implement a recording of changes after a breakpoint, or automate debugging over a script)
- maybe add wxPanels to the script binding
- Add more wxControls to the binding (ex. wxGrid)
*) I have added the possibility to run script code before and after a installation / deinstallation of a scripting plugin. This code is specified in the install.xml file (like the mainfest.xml file) You can see a example in the cbSelectiveCompiling plugin installation process (a custom dialog will ask you if you really want to install this plugin).
If you test things, and find bugs, please report them on github or here.
For fast questions i try to stay in the c::b chat and answer them there.
greetings
Quote from: BlueHazzard on January 23, 2015, 01:42:22 PM
After this changes i think the port is ready and all features for a good scripting base are implemented. If you want my changes we have then to clear how we bring them to trunk (patch or branch or whatever).
I can merge the branch, so all commits will be transferred to svn.
But you have to keep the history linear and also every commit has to have a meaningful commit message.
Also if you want to get credit for your commits you have to append (thanks BlueHazzard) at the end of every commit.
After I do git svn rebase and git svn dcommit, I'll become the author of all commits.
I think, I've started an autotools port of the older version of the branch. So if you're ready just say so and we'll do the porting.