@kas1e

To get a stack trace from a specific point in a program you can just insert in the source code a:

IExec->SuspendTask(NULL, STF_CRASHED)

there and it should bring up the grim reaper.

Or you could just do something like:

*(char *)0 = 0;

which will trigger a DSI and bring up the grim reaper as well.

Using Ranger you can also get a stack trace from any running program by selecting it from the process list and clicking the button next to "Stack:".

@328gts

You don't have to use AmiUpdate for the AmigaOS 4.1 FE update 1 & 2 as they are also available from the downloads section on www.hyperion-entertainment.com.

@kas1e

Whether char type defaults to signed or unsigned is and always has been platform dependent. If you require a specific type of char (signed or unsigned) you should specify it in the variable definition.

In this case:
signed char _direction = -1;

@Sbaitso

Quote:

I have the update check on startup disabled on all my AmigaOS 4 installations as it uses the www.amiupdate.net address which doesn't work due to some DNS issue and eventually times out.

Instead I have amiupdate.codebench.co.uk (as recommended in a thread on these forums) set under servers as the place to look for updates.

@geennaam

Except for a few rare exceptions it is generally fine to share the library and interface with a child process. Just make sure that you do not close them while the child process is still running.

I'm not sure what you are using the child process for but if it is to stay alive even after the original caller has left then you should not use NP_Child.

The NP_Child tag mainly does two things:
- For newlib programs it ensures that the newly created process is using the same reent data structure as the parent, which means that file descriptors and other clib constructs can be passed between the processes without problem.
- Ensures that the parent process does not exit before the child does.

@kas1e

To stop another thread in a clean way on AmigaOS requires co-operation from the thread that is to be stopped, but the kill operation has to do this by force because of how it is designed.

It would be better if MineCraft used a semaphore or other similar construct to signal the threads to stop and then used join to wait for them to end similar to the SimpleThreadTest here:

https://github.com/minetest/minetest/b ... ittest/test_threading.cpp

@kas1e

I rewrote my posix semaphore implementation as a static library so it can more easily be linked to a program and only the needed functions will be used.

https://www.dropbox.com/s/lwbg2fbefgaoy6g/libpsem.7z?dl=0

With 4.1 FE update 2 + hotfix the latest public newlib.library should now be version 53.62.

@kas1e & Skateman

Thanks for the donation!

@kas1e

New version:
https://www.dropbox.com/s/w0803hmcch2vnud/libwprintf.7z?dl=0

Adds support for %I/%i format specifiers (work identical to %D/%d) as well as wprintf()/vwprintf() functions.

@Raziel

Quote:

You're not really supposed to use it like that.

Coreutils, like some other unix programs I've come across, implements all functionality in one executable that then acts differently depending on what name it is called by from the CLI (argv[0]).

So for instance if you make a copy of the coreutils program or a soft link to it called "mkdir" then it will act when run as if it is the mkdir command, and if you call it "cp" it will act as the cp command.

If you install the coreutils archive from OS4Depot using AmiUpdate or by manually executing the AutoInstall script from a CLI then it creates the soft links for you automatically.

@Raziel

Quote:

As coreutils is from posix you should not expect it to work well with AmigaDOS style paths.

Instead you should use unix style paths, like so:
mkdir -p /work/test/test1

@billyfish

Quote:

'data' does not point to a floating point if that is what you mean. Instead it points to a signed 32-bit fixed point number which is converted to a float by casting and then dividing by the number FIXEDPOINT_FACTOR which is probably a power of two.

@geennaam

Have you tried changing the reference library_card.c/.h references to library.c/.h? It's possible that the library_card files have been removed because they were no longer needed and the driver code just hasn't been updated.

@kas1e

I've updated the posix semaphore implementation at:

https://www.dropbox.com/s/43b4g16kvhd7 ... emaphore-amigaos4.7z?dl=0

by adding the sem_trywait() function and refactoring the sem_timedwait() function.

@Raziel

Try adding the option "--sparse=never" to the cp command.

If it helps then the file corruption is likely due to a long standing bug in newlib.library that was fixed in V53.59 (AmigaOS 4.1 FE update 2 has V53.61 so it shouldn't have this problem).

You can find the latest coreutils at:
http://os4depot.net/share/development/utility/coreutils.lha

@kas1e

Quote:

That looks like it's just doing a pointer comparison to me (but maybe the equality operator is supposed to be overloaded?).

Try replacing it with:

UASSERT(strcmp(deSerializeString(is).c_str(), "foobar!") == 0);

to see if it works better.

@kas1e

Try printing the float number generated by readF1000(is) and if it's close enough to 53.534 you can just disable the assert.

BTW for gcc >= 4.8 you can change the bswap macros to:
#define __bswap_16(x) __builtin_bswap16(x)
#define __bswap_32(x) __builtin_bswap32(x)
#define __bswap_64(x) __builtin_bswap64(x)

@kas1e

I made some changes in the sem_wait()/sem_timedwait() and sem_post() functions that should hopefully fix the problem.

In the previous version it was possible that when sem_post() was called four times in quick succession that only the first thread in the wait list was signaled four times and the others were just left waiting.

https://www.dropbox.com/s/43b4g16kvhd7 ... emaphore-amigaos4.7z?dl=0

@kas1e

Can you check if there is a problem with the trigger.wait()/trigger.post() mechanism (see my edit above)?