Compiling for powerpc (Darwin 9/OS X 10.5)

[FakeTruth]

Is your code taking that path in cEvent? If you uncomment those lines and put a breakpoint in them, does it hit the breakpoint? If so, that's the reason for your failure - the ASSERT() macro force-terminates the program.

If there's anything that doesn't compile, please send us the patch that makes it work for you. You can either attach a patch file to the forum post, or send me an email at <my-nick> @ <my-nick>.cz

That 'weird' code path was specifically there for Mac >_>

http://stackoverflow.com/questions/14137...it-on-os-x

To comment on why I'm using sem_unlink after creation ( // _X: I'm unconvinced about using sem_unlink() just after a successful sem_open(), it seems wrong - why destroy the object just after creating? )
sem_unlink() does not destroy the object yet, it only destroys it after it has been closed

If one or more processes have the semaphore open when sem_unlink() is called, destruction of the semaphore is postponed until all references to the semaphore have been destroyed by calls to sem_close(), _exit(), or exec

http://pubs.opengroup.org/onlinepubs/790...nlink.html

[R-T-B]

Is your code taking that path in cEvent? If you uncomment those lines and put a breakpoint in them, does it hit the breakpoint? If so, that's the reason for your failure - the ASSERT() macro force-terminates the program.

If there's anything that doesn't compile, please send us the patch that makes it work for you. You can either attach a patch file to the forum post, or send me an email at <my-nick> @ <my-nick>.cz

That 'weird' code path was specifically there for Mac >_>

http://stackoverflow.com/questions/14137...it-on-os-x

To comment on why I'm using sem_unlink after creation ( // _X: I'm unconvinced about using sem_unlink() just after a successful sem_open(), it seems wrong - why destroy the object just after creating? )
sem_unlink() does not destroy the object yet, it only destroys it after it has been closed

If one or more processes have the semaphore open when sem_unlink() is called, destruction of the semaphore is postponed until all references to the semaphore have been destroyed by calls to sem_close(), _exit(), or exec

http://pubs.opengroup.org/onlinepubs/790...nlink.html

Yeah, the issue actually has nothing to do with powerpc. The issue lies solely with Darwin using screwy headers. For example, using unnamed semaphores is completely unsupported and brings a host of networking problems with it. This probably applies to intel as well.

I've basically fixed most of the issues, but my fixes are noobish and will likely break compilation on other platforms. Please wait why I test and cleanup the code a bit.

Could you guys by chance use a hand on this project? I really want to learn C and C++ and I have access to several odd pieces of hardware (PowerPC, SPARC, ARM,even a MIPS router running linux) that I could test compilation on. Would be good for an educational experience. The only thing I ask is that I could use this code in a commercial "minebox" I've been developing that is basically a low cost minecraft server in a $100 pricepoint single board computer. I assume the license terms allow that?

As far as what I can contribute, I was the author of PhoenixTerrainMod (google it) and I know a lot about terrain generation in the minecraft style. By the looks of it, you could use some help on that front.

Thanks, will continue to work on this regardless.

-RTB

[FakeTruth]

As far as what I can contribute, I was the author of PhoenixTerrainMod (google it) and I know a lot about terrain generation in the minecraft style. By the looks of it, you could use some help on that front.

Thanks, will continue to work on this regardless.

-RTB

That would be awesome!!
As for the license I have no idea, I just picked a random one

[R-T-B]

As far as what I can contribute, I was the author of PhoenixTerrainMod (google it) and I know a lot about terrain generation in the minecraft style. By the looks of it, you could use some help on that front.

Thanks, will continue to work on this regardless.

-RTB

That would be awesome!!
As for the license I have no idea, I just picked a random one

Sure, I'll see what I can do then. You'll have to be patient with me at first though, because as far as I can tell Java and C++ are about as different as night and day.

[xoft]

Pity, I wanted to try out some new terrain generation ideas I had

---

$100 SBC? Got any more info? I'd be quite interested in that
I was enthusiastic over the Raspberry Pi, until I learnt that it has only 256 MiB RAM planned; that sucks.

[tbar]

I was enthusiastic over the Raspberry Pi, until I learnt that it has only 256 MiB RAM planned; that sucks.

Why does that suck? I'm not trying to troll I'm just curious... I've got plenty of projects planned where the Raspberry Pi will be perfect for the job...

[xoft]

For MCServer, 256 MiB is just not enough for any serious server project. Half of that memory will be hogged by the system and the rest is enough for 2 players only.

Sure, there's a lot of things the RasPi will be perfect, just anything minecraft-related is not it.

---

Can you PM me with your SBC project details, so that we don't spam this forum off-topic

[R-T-B]

$100 SBC? Got any more info? I'd be quite interested in that
I was enthusiastic over the Raspberry Pi, until I learnt that it has only 256 MiB RAM planned; that sucks.

It's a mass quantity deal that may or may not meet that pricepoint, but it'll definently be under $150. It's based on a 512MB variant of the Beagleboard. There'll also possibly be a premium model based on the Pandaboard or whatever it's called.

[tbar]

For MCServer, 256 MiB is just not enough for any serious server project. Half of that memory will be hogged by the system and the rest is enough for 2 players only.

Faketruth thinks it should be able to host at least 8 players: https://forum.cuberite.org/showthread.php?tid=303

But I agree that 8 players is hard to define as a serious server project For my needs it is perfect as I don't expect more that 5-6 concurrent players...

(In the RPi the 256 MB RAM is actually split between the CPU and the GPU. The GPU requires at least 32 MB so we're actually talking about 228 MB RAM...)

[xoft]

That was before MC "upgraded" to double the build height, and was slightly under-estimated.

Right now just the chunks for a single player take up around 64 MiB, and since they are not unloaded very often, it can get to twice that amount fast. Sure, unloading them as soon as they go "out of sight" is possible but still you won't be able to fit more than 3 players.