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

Codeblocks ported to sqrat

(1/11) > >>

BlueHazzard:
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

ollydbg:
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.


--- Quote ---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...
--- End quote ---
Git rebase onto the current C::B head? So patches will apply one by one.

MortenMacFly:
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.

oBFusCATed:
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...

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

oBFusCATed:
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.

Navigation

[0] Message Index

[#] Next page