Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

porting c::b to sqrat

<< < (2/3) > >>

BlueHazzard:

--- Quote from: ToApolytoXaos on October 16, 2013, 04:32:58 pm ---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.

--- End quote ---
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:

--- Quote from: BlueHazzard on September 29, 2013, 07:41:03 pm ---so are there any protests against porting c::b?
--- End quote ---
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


--- Quote ---if not, is there a special technique to provide patches for such big changes? Like branches with git...
--- End quote ---
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:

--- Quote from: BlueHazzard on October 16, 2013, 03:20:26 pm ---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.

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


--- Quote from: BlueHazzard on October 16, 2013, 03:20:26 pm ---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...

--- End quote ---
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:

--- Quote from: thomas on October 16, 2013, 05:15:12 pm ---
--- Quote from: BlueHazzard on September 29, 2013, 07:41:03 pm ---so are there any protests against porting c::b?
--- End quote ---
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

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page