porting c::b to sqrat

[BlueHazzard]

hi.
i have started to try to make a xrc support for the squirrel part. I planed to expose the basics of every wxWidgets Control class to squirrel, but i encountered immediately the copy ctor problem:

NOTE: Not all bindings should have an emptyCtor(). For example, scripts should not have the ability to create, say, a new "cbProject". Instead, it should go through the standard route: GetProjectManager().NewProject(). Another thing to note about emptyCtor() is that it imposes certain requirements on the C++ class, like that your C++ object must have a public copy constructor (but this is a requirement anyway). Look for an example in all basic classes (e.g., cbEditor). Copy constructors have been added to them which do nothing, just throw an error. They are not used by scripting (SqPlus has been patched for this) but they must exist nevertheless. Anyway, these are some "advanced" scripting issues which will become clearer once the basics are more clear. All of the wxWidgets GUI controls have private copy-ctors btw.

sqplus is outdated now since several years, and i think it isn't maintained any more.
http://sourceforge.net/projects/scrat/
sqrat is maintained and it has a interesting feature:

* NoConstructor
* CopyOnly
* NoCopy

so are there any protests against porting c::b?

if not, is there a special technique to provide patches for such big changes? Like branches with git...

greetings

[oBFusCATed]

Generally porting the squirrel bindings to something that is supported and up-to-date and understandable is always good.
But there are some requirements:
1. The currently exposed squirrel api MUST not break, so older scripts MUST run without changes
2. It must work on all platforms 32 and 64 bits
3. Someone should do it
4. If 1 is not possible we should probably look for other scripting engines (lua or python), because squirrel is pretty limited in additional libraries.

But on the other hand if I were you I'd try to do higher level binding and won't try to do 1:1 mapping between the wx classes and squirrel binding.

[BlueHazzard]

I'm still trying to port c::b to sqart, and in looks good so wide. The only problem i encounter is a bit in the UNICODE section. What is the minimal wx-version it is supported in c::b? If it is >2.8.4 there are no problems because there exists the function wxString::ToUTF8 and wxString::FromUTF8, but with a smaller version i have to look again.

I also try to implement a better way to use XRC Dialogs from squirrel. In my current implementation I use a lot wx2.9 API. Is it somehow acceptable to use this feature only with wx2.9 or should i try to implement it also for wx2.8 (witch would be a little bit of a pain in the ass). The old API would not change. So any script witch runs with the current version of c::b will work also in the new implementation...

greetings

[ollydbg]

I'm still trying to port c::b to sqart, and in looks good so wide. The only problem i encounter is a bit in the UNICODE section. What is the minimal wx-version it is supported in c::b?

The minimal wx version to build C::B is 2.8.12.

I also try to implement a better way to use XRC Dialogs from squirrel. In my current implementation I use a lot wx2.9 API. Is it somehow acceptable to use this feature only with wx2.9 or should i try to implement it also for wx2.8 (witch would be a little bit of a pain in the ass). The old API would not change. So any script witch runs with the current version of c::b will work also in the new implementation...

greetings

C::B will finally swith to use wx 3.0+ if wx released and becomes stable, but please note that this will take years to happen as I can expect. You see currently there are many issues when build C::B against wx 2.9.x +, This means C::B will use wx 2.8.x for quite a long time I think.

[ToApolytoXaos]

4. If 1 is not possible we should probably look for other scripting engines (lua or python), because squirrel is pretty limited in additional libraries.

I use ZeroBrane Studio which is implemented in Lua entirely which uses wxLua as its GUI; it works flawlessly, especially its autocompletion mechanism. I would go for either Lua or Python which I know both for C::B expansion.

[BlueHazzard]

I use ZeroBrane Studio which is implemented in Lua entirely which uses wxLua as its GUI; it works flawlessly, especially its autocompletion mechanism. I would go for either Lua or Python which I know both for C::B expansion.

I personally like squirrel because of the c++ syntax, so i'm not willing to do the work for porting c::b to a other scripting language (specially python, the ugliest language i have seen (after basic ) )

[thomas]

so are there any protests against porting c::b?

On the contrary. I tried doing that myself a bit over year or so ago, but gave up because of something. Don't actually remember what it was... I think it was difficult to bind enum values or something, and I didn't find a good solution, and then I didn't have time... or something.

If you can get this to work, that would be awesome.

Found it: http://forums.codeblocks.org/index.php/topic,16507.0.html

if not, is there a special technique to provide patches for such big changes? Like branches with git...

Morten could probably create a branch and give you write access to this branch, I guess. Other than that, the only way I see is modifying your local copy and creating a huge patch afterwards, which admittedly stinks.

Subversion really isn't made for "any random person can make branches just like they want" usage. Usually, at that occasion, I say "...and that's not needed either", but in this particular case it would really be helpful. Doing such a huge code chance without version control sucks.

[oBFusCATed]

I'm still trying to port c::b to sqart, and in looks good so wide. The only problem i encounter is a bit in the UNICODE section. What is the minimal wx-version it is supported in c::b? If it is >2.8.4 there are no problems because there exists the function wxString::ToUTF8 and wxString::FromUTF8, but with a smaller version i have to look again.

wx>2.8.4 is okay, I think at the moment we require something like 2.8.9 or 2.8.12.

I also try to implement a better way to use XRC Dialogs from squirrel. In my current implementation I use a lot wx2.9 API. Is it somehow acceptable to use this feature only with wx2.9 or should i try to implement it also for wx2.8 (witch would be a little bit of a pain in the ass). The old API would not change. So any script witch runs with the current version of c::b will work also in the new implementation...

I'd prefer if you provide API for 2.8 and 2.9. We'll support 2.8 for quite a while, I suppose, more than a year.
And it will be bad if you have to ifdef things in squirrel scripts, because there is no compilation and you'll find the errors only at runtime with the other version.

About branches: if you can handle git you can fork my repo at github - https://github.com/obfuscated/codeblocks_sf
It is often synced and we can push the changes to svn very easily, when they are ready.

[BlueHazzard]

so are there any protests against porting c::b?

On the contrary. I tried doing that myself a bit over year or so ago, but gave up because of something. Don't actually remember what it was... I think it was difficult to bind enum values or something, and I didn't find a good solution, and then I didn't have time... or something.

If you can get this to work, that would be awesome.

Found it: http://forums.codeblocks.org/index.php/topic,16507.0.html

I have read it, and the problem with the enums exists, but this is a c++/language problem. There isn't any way to automatically iterate over enums and bind them (at least as i know). This has always to be done by hand (or with a program i don't remember, but it has anyway no squirrel support). I used the same preprocessor enum binding as it is done with sqplus. To make the enum binding more secure there is the possibility to add a "enum_max" value at the end of every enum, and check in the binding if this value has changed. But i think this is overkill. If a enum changed in the sdk but not in the binding, a user will detect and report it

[thomas]

I also don't know a solution to that problem, other than doing it all by hand. I don't even know an easy and reliable solution to implement a "safeguard", such as a static_assert that fires off and breaks the build when new enums are added and the two versions are out of sync by accident.
The only way is to wait and see until either someone complains that their Code::Blocks crashes or that an enum doesn't do what it should do.

enum_max also won't work for non-contiguous enums, which we unluckily have.

It would be "kind of trivial" if we could run a script in a language that has easy regex, such as perl or python or php to generate these. Then one would only call that script once during build given a list with all headers that you want it to consider, generating the squirrel binding from the existing headers.

Unluckily, this adds a serious dependency. If we use e.g. perl for that and someone doesn't have it installed (or can't find an install package for their system), then they can't build Code::Blocks at all any more, which kind of sucks.

[BlueHazzard]

Some thoughts about the const thing:
As thomas mentioned in his post, the current implementation of const is a type of "implementing a get and set function, and denying the access on set". But is no binary constnes as expected. You can still do:

Code

> print(::EXT_WORKSPACE);
workspace
> EXT_WORKSPACE.MakeUpper();
> print(EXT_WORKSPACE);
WORKSPACE

as you see the constant "EXT_WORKSPACE" is changed, and i think this is a wrong behaviour. Also are consts in squirrel evaluated in compiling time. With this implementation this is not possible.
I would suggest to use the const_table of squirrel instead. But there is obvious not the possibility to use the wxString type, but only the string type witch comes with squirrel. This change could possibly break the api (I'm not sure in witch context this constants are used, but if they are only used with the "+" operator it won't break the api, only with functions witch use a wxString as parameter...)

greetings