The 06 February 2008 build (4866) is out.

[MortenMacFly]

It's not that it would be impossible, just that Apple does not want you to switch hardware.

Huh? I thought Apple managed to create a X86 compatible version of the OS. Does that mean although it could run on a native X86 hardware (VM) then it's forbidden by the MAC-OS EULA when I buy the MAC-OS software? So why do they sell it then as standalone product?

But I suppose you could get someone with a Mac to let you borrow it - over VNC or so ?

I don't know people with a MAC unfortunately. And those I meet that have one won't allow me VNC on it... for sure. ;-)

Or ask the guy in the Apple Store for a demonstration of the url "www.codeblocks.org" ;-)

LOL - that would be an option, indeed.

Ps.: We are getting quite off-topic... sorry.

[wobien]

The parser used to never parse on my startup but now it seems to. 

I didn't download the 4861 build, but in the 4866 build I still have to do "Re-parse now" to get the symbols in my Default workspace parsed after startup. (Windows XP)

[afb]

I thought Apple managed to create a X86 compatible version of the OS.

They did, yes. Unofficially in 2001 and officially since 2005... (Mac OS X version 10.4.4)

Does that mean although it could run on a native X86 hardware (VM) then it's forbidden by the MAC-OS EULA when I buy the MAC-OS software?

Yup.

So why do they sell it then as standalone product?

So that people who bought a Mac with a previous OS version pre-installed can upgrade ?

[thomas]

Is it just me, or is Apple even more abusive than Microsoft? You'd think they'd be happy if anyone buys their crap at all, but apparently not.

[Auria]

Well one point for Apple not supporting install of OS X on all computers is one of driver issues - everyone makes windows drivers so windows does run everywhere, and linux can afford to be a bit more buggy at drivers (or harder to setup) since it's usually free and community-maintained, but not everyone makes mac drivers and Apple can't write them all by themselves. And they couldn't advertise mac OS X installs on the average PC without drivers, cause users would try it, it wouldn't work, OS X would get a bad reputation, etc. that's how they achieve the rock stability that makes OS X users love it

HOWEVER, I think *forbidding* it is totally abusive. They could just have marked it unsupported (and of course it's more money for them this way)

[Auria]

Hmm, when would the wxDynamicLibrary bug kick in ? If they are loadable libraries, then they would probably be .bundle (or .so) rather than .dylib - since .dylib aren't loadable at runtime (only linktime) ? I don't have any problem with this when building with ./configure && make, did you have any more details (or the Bug number) on where it would apply ? Maybe it is when trying to build Code::Blocks with itself ?

As for the combos-in-toolbars, I have patched my wxWidgets configuration

Well by default the C::B build system generates .dylibs and not bundles or so files on my computer (not sure how to change that either). But .dylibs ARE definitely loadable at runtime, for instance dlopen() opens them just fine. I'm not sure why on your computer libraries build different from mine, it's perhaps a different version of autotools or something
The wxMac maintainer said wxDynamicLibrary would be re-written in the future to offer better support, anyway, so that problem will be fixed by itself.

I also heard the toolbar problem was fixed in SVN

[MortenMacFly]

Does that mean although it could run on a native X86 hardware (VM) then it's forbidden by the MAC-OS EULA when I buy the MAC-OS software?

Yup.

Ah - ok. I honestly was not aware of that. I see reasons to do so from an Apple point of view but for me this means my dreams of having MAC OS in a VM are gone. :-(

So that people who bought a Mac with a previous OS version pre-installed can upgrade ?

Ok... sounds obvious. So this would mean they basically sell updates only.

Thanks a lot for that information!

With regards, Morten.

[afb]

Well by default the C::B build system generates .dylibs and not bundles or so files on my computer (not sure how to change that either). But .dylibs ARE definitely loadable at runtime, for instance dlopen() opens them just fine.

I think the main difference was with dlclose (as in: not available with dylib)
But I also think that with Mac OS X 10.5 up, they are both the same now...
(dyld is a rather complex subject). But e.g. Perl and Python uses -bundle.
It's possible that -dylib can be made to work for plugins too, but usually isn't.

I also heard the toolbar problem was fixed in SVN

Good to hear, maybe it can be patched in to wxWidgets 2.8 too then...

"In prior versions of Mac OS X only bundles (file type MH_BUNDLE) could be unloaded.
In Mac OS X 10.5 dynamic libraries (file type MH_DYLIB) can also be unloaded when using dlopen/dlclose."

[zortich]

Code completition   :shock: is working awful.
Where is no code completion for #include <X11/Xlib.h> is available.
What about to improve it?

[Wahooney]

Could you guys please include the following into the next nightly build, it needs to be placed in lexer_squirrel.xml:
<Style name="Verbatim String"
   index="13"
   fg="0,0,255"/>

For those not in the know, it adds verbatim strings (ie. @"Hi, I'm a verbatim string") to the squirrel lexer.

Thanks guys

[Biplab]

Could you guys please include the following into the next nightly build, it needs to be placed in lexer_squirrel.xml:

Added in rev 4869. 

[Wahooney]

Thanks, Biplab :mrgreen:

[Grom]

Is any way to write a plugin under the Windows, which will automatically install new nighties. Actually after some manipulations my suse  10.3 do this...

[JGM]

using repositories on linux distros is really easy, on windows is another story

[Grom]

That is why I am talking about the updater plugin form windows. Have no time ti implement it by my self. In fact it can be done easily in Java and connected to the C::B. One weak of part time work.