About RC3

[Game_Ender]

I think it sad that AS lacks portability but it was a developer choice.  In order to make binding easier you need compiler, platform, and architecture specific assembly.  This is fine if you write that code and keep it up to date.  You could try squirrel which appears to very similar but more portable, although with messier bindings.

Internet updates are currently at a stage which is 90% functional on the client side, minimum functional on the server side, and which has 0% test coverage.

Not trying to troll but doing it anyways: Does anything in CB have anything that is unit tested?  I am sure a decent chunk of the SDK could use them with no problem.  We have had this discussion before, but my "code and test" doctirine appeared to be shot down.

P.S.- Yes I do put my money where my mouth is, every non-gui class I make has more test code and doc lines than implementation code lines.  Which I know is not always a good thing and it does get tedious some times.

[David Perfors]

AS doesn't get any 64bit support in the near future, so there is decided that C::B is getting another engine, the devs are looking to squirel

[NeverDream]

What about Lua?  It's small, fast, and highly portable.

[MortenMacFly]

What about Lua?  It's small, fast, and highly portable.

...there are people that see Squirrel as the successor of Lua.
With regards, Morten.

[thomas]

What about Lua?  It's small, fast, and highly portable.

Before this starts off a huge avalanche of proposals ("what about Python, what about Ruby, what about (insert name here)?") let's say that the team discussed the possible alternatives and settled for squirrel/sqplus before it was ever mentioned in public that we might possibly switch to another scripting language.

The one thing that was not certain was if we would switch at all.

Indeed, we would very much have preferred staying with AngelScript, since it is really nice and easy and an excellent performer. If there had been any reasonable estimate that AngelScript would support 64bit architectures any time soon, we would definitively have decided to stick with it as the utmost first choice.

However, we do of course realize that telling the ever growing community of 64bit users that half of the IDE's functionality is not supported on their machines is a no-no.
You can tell them "wait until scripting is ported" for a while, but one day it really has to work, one way or the other. You cannot hold them back for forever.

Squirrel has a good syntax and extremely powerful and cool language features, and is a good performer.
Admitted, it has a few shortcomings, most notably a quite bad documentation and messy function binding (works like in Lua). However, there is sq-plus which wraps all that mess into some templates and a few helper classes, and about documentation... He that is without sin among you, let him first cast a stone.

[David Perfors]

and about documentation... He that is without sin among you, let him first cast a stone.

YES!!!! I can trow...


or...


wait a minute, I am a developer to.. so.... I don't WANT to document (although I am working on the documentation of C::B  :oops)

[rickg22]

Please take the time you think is necessary. As far I am concerned, I would prefer an high-quality product delivered a bit later rather than a rushed one.

Just make sure it doesn't become a Duke Nukem Forever

[Michael]

Please take the time you think is necessary. As far I am concerned, I would prefer an high-quality product delivered a bit later rather than a rushed one.

Just make sure it doesn't become a Duke Nukem Forever

 

I think we will become soon a pleasant surprise .

Best wishes,
Michael

[kylove]

Expect RC3!

[Michael]

Expect RC3!

Please be patient .

Best wishes,
Michael

[Pharaoh Atem]

I really do not know what to think now, with all the delays in C::B 1.0rc3. I guess I could take this oppertunity to work on some other projects, but C::B is a big gaping hole in many things I do. And I really cannot recommend it until a decent release is made. For now, I'm working on a bunch of NSIS projects, but hopefully in the future, I can install Code::Blocks on my Fedora Core 5 laptop and be happy that it is a release. With as many delays that Code::Blocks has had, I would call this Code::Blocks 1.0 RC final. Or even, Code::Blocks 1.0. Too many changes to warrant calling it 1.0rc3 in my book. I'm prepared for the day Code::Blocks 1.0rc3/rc final/1.0 releases and have my entire build system reconstructed. I don't want to use nightlies on my laptop because it is already cluttered with lots of different build systems and different workings. I have to still get the crosscompile tools for GCC 4.1.x, but i doubt there is such a thing.

[Game_Ender]

I think the problem is with the version number scheme, it has gotten everyone confused.  Release Candidates are just that, a build which could pretty well become the final build for that version, ie the checksum of the RC3 should/coud be equal to the checksum of 1.0 final.  It appears as if mostly bug fixes are going into the trunk right now, so we are doing pretty good.

I think CB is going to be one of the version number jumping products (not really a bad thing), after all the next version is already called 1.5, which means the release after that will most likely be 2.0.  Frankly I like the way the linux kernel does things with number like: Major.Minor.Bugfix.  You only a new major version if some massive interface breaking changes comes along with a large rewrite of the project.  Minor versions alternate between unstable and stable.  For example the next develpement version of CB would be 1.1.0 only while it was being developed.  After it finished, it would become 1.2.0.  The Bufix part of the number is for any changes or bugfixes that don't break the interface.  In our example you get 1.2.1, 1.2.2 etc.   These number don't roll over after you get to 9, so its perfectly ok to have 1.11.13.  This is also pretty close to how GCC does there release scheme, although I don't think the do the stable/unstable thing for the Minor version number.

No matter how logical the above the is, its still opinion and not a rule.  Many projects, especially those more oriented to users like to jump the version numbers.  Firefox has been doing that recently with it's skip up to 1.5 and soon 2.0.  Code::Blocks is great project and the more I use the more I like it.  I think plenty of people here want a good stable 1.0 release that they can develope some good pluggins against it.  That is why the CB team is working so hard to make sure they get this release right.

Just be patient, and forigve my minor rant on version numbering.

[Michael]

I really do not know what to think now, with all the delays in C::B 1.0rc3. I guess I could take this oppertunity to work on some other projects, but C::B is a big gaping hole in many things I do. And I really cannot recommend it until a decent release is made. For now, I'm working on a bunch of NSIS projects, but hopefully in the future, I can install Code::Blocks on my Fedora Core 5 laptop and be happy that it is a release. With as many delays that Code::Blocks has had, I would call this Code::Blocks 1.0 RC final. Or even, Code::Blocks 1.0. Too many changes to warrant calling it 1.0rc3 in my book. I'm prepared for the day Code::Blocks 1.0rc3/rc final/1.0 releases and have my entire build system reconstructed. I don't want to use nightlies on my laptop because it is already cluttered with lots of different build systems and different workings. I have to still get the crosscompile tools for GCC 4.1.x, but i doubt there is such a thing.

Hello,

IMHO, the delay of RC3 is justified for one reason or another. C::B devs work hard to provide a very good and usable IDE.

Nightly builds are IMHO not bad at all and you do not need to update each night if you do not want. Moreover, you just need one nightly if you wish and not several. One time, I had RC2 and 4-5 Nightly builds installed on my PC without any troubles.

I think that you can use a nightly for your test. Or wait for the RC3. Should not be so far...

Best wishes,
Michael

[matthewjumpsoffbuildings]

Awesome - im looking forward to it very much.

[matthewjumpsoffbuildings]

any news?