@rjd324

Is that perhaps the race condition?
When you press the ok button, the input string gadget looses focus, and it’s content is “registered”, but when you press enter, the enter is seen before the input string gadgets content has been registered.

Try tab first, and then enter? (Can’t remember if tab is standard way of moving out of gadgets so might not work.)

@kas1e

Now, Im just guessing obviously. But I found this link, glgeterror not resesseting its flag, that says that "glGetError should always be called in a loop, until it returns GL_NO_ERROR".

Could it be that glGetError (line 156 testherader.c) doesn't clear all flags, but calling printf and delay does (since tehy succeed)? Perhaps just check what glGetErrors returns, and possibly wrap it in a loop?


Or something?

@kas1e
Quote:
I think I read it all. And I didn’t ask to add a printf, but the sdl error print. But perhaps that does the same thing. Just wanted to find out if the first shader in the loop failed or the last.

@kas1e

Do you know which shader fails? Just add an SDL log error whenever a shader is compiled and you should see… 4 of them, I guess from looking at the code linked.

Something like this:

My -guess- would be that DELTAMOUSE=20 controls how much you’d have to move the mouse in order to show the pointer when it’s blanked. I.e. move it less than 20 pixels (?) and it'd still be hidden.

As for sys/mman.h, for example, I simply made override includes for those, and handcrafted my own solution for Jamiga. IIRC it was however only like two-three functions used, and they were simple to implement.
It’s not a long term solution, but perhaps something to make progress. I.e. crests dummy implementations in order to see how far one gets in the compile process.

I’ve worked on the code in deadwood’s repo. Trying to gather all dependencies and build it. I’ve setup a docker container with a cross-compiler setup, SDK and a script that downloads and installs the dependencies. See the readme for instructions. Anyone with docker should be able to try it out.

For now there's a missing dependency, libicu, in my list, but I’ll try and fix that tonight.

I’ve merged the changes done by the Aros team, and my plan is to have it build, and then try and update to the next revision that the TenFourFox/leopard ppc-safari has a JIT-patch for.
I’m however currently stuck on freetype/fontconfig dependency, which I don’t know if the latest libcairo by salass00 has support for (the port only mentions an Amiga font backend).

https://github.com/deadwood-pl/Odyssey ... kim_os4_compile/README.md

@Lio

I use FKey. Usually on PC keyboards there are some mail symbols and stuff for the F-keys which I map to my email address.

There’s also AllKeys on os4depot which can map stuff to the multimedia keys of some keyboards.

I overrode malloc, free, and realloc in JamVM. Can’t remember the details, but I think I ended up using the memory pools (even though the code had Agee other methods in ifdef’s).

Hmm... looking at the code I seem to have changed the functions to call my memory functions, thought I’d made some defines for it.

Anyway, below is the code. Look for mymalloc, myfree, and myrealloc:
src/os/amiga/memory.c

And here is where I had to change it. JamVM already had its own memory allocation functions, so it didn’t call them directly:
src/alloc.c

@kas1e

Does ((double)tNow.tv_sec)) really convert from whatever type tv_sec is, to a proper double? Is it perhaps just casting whatever is there and trying to interpret is as a double?

@LiveForIt

Well, hopefully yes. It depends on someone putting it together. But that project was one of my aims. Don’t know if I’ll do it, but I’d be glad to help/get some assistance.

Hi,
I've just created a vagrant environment to use for AmigaOS4 cross compiling development. You can use it on any OS that has Vagrant (Linux, Windows and MacOS).

What is it?
* Virtual Linux environment with pre-installed AmigaOS 4 PowerPC compiler (gcc 5.5.0) and latest official SDK.
* Scripts to download SDK dependencies from third party source (f.i. os4depot) with distributed instructions.

Read more on how to install here: https://sourceforge.net/p/vagrant-amigaos4-crosscompiler/wiki/Home/

Testing, questions and suggestions are welcome!

Quote:

No... Or... yes? Can't remember which ones I used, but I should probably have used those you point at. Thinking about it, I might have actually used a diff from that place.
I'm having a hard time understanding which exact revision "our" Odyssey is using, and which ones the leopard-webkit uses. I looked at it several times but always end up confused since I always seems to find huge discrepancies between files.

Quote:
Nope. Never got that far.

I looked at this many moons ago, and now took some time with it again. What I did then was to apply the PPC-Mac patch for WebKit onto the Odyssey code. It was relatively straight forward, but since our WebKit is newer than the PPC-Mac patch, there's quite a lot missing pieces in the PPC-code. It's mostly what seems to be new calling conventions of already existing methods, f.i. low level stuff like or32() that takes its destination as registers or some sort of pointer structure, where there seems to be a new pointer structure. There's also some ABI stuff that might differ in MacOS vs AmigaOS.
I'm now basically cmaking it, finding missing methods as I go, and implement them with dummy code when I can't figure it out immediately. This way I'm hoping to get a full compile through, which of course won't work, but it'll be some sort of "proof of build". And then perhaps someone with some more PPC-knowledge could fill in the blanks, or at least give some pointers.

I have it in my GitHub: https://github.com/jaokim/odyssey, and the interesting parts reside in JavaScriptCore/assembler, f.i. MacroAssemblerPPC.h or PPCAssembler.h. Look for "#warning AmigaOS" where I've added missing stuff.

However, I don't have super high hopes on this materialising into something runnable very soon. My time is limited, and its kind of boring. But I do still feel some sense of progress... but it might also prove to be way to many changes for me to handle... Time will tell.

@AmigaBlitter
@AmigaBlitter

Technically, if I understand correctly, those functions are part of the POSIX c-standard, which isn't supported. Some functions from POSIX seem to have snuck in in both newlib and clib2, but to me it seems to be more by chance than by adhering to specific standards (although I could be wrong, I haven't read the different c specs very closely). For instance, there a few signal-related functions in clib2, that aren't in newlib. But if you think that clib2 is better, you'll soon see that clib2 lacks one functions that newlib has.

But indeed, it's a bit annoying when you find these unimplemneted, or even half implemented standards. Even the pthreads library on os4depot, which has some sort of "official" status in that it has been developed by OS4 team members, lack a few pthreads function. But I guess that's also some chosen minimum version.

@broadblues:
Thanks for the pointers!

So, I made a few updates to my code.
Added a readme, and made a few changes. I basically just made my replacement signal.h fully compatible with the current 53.30 newlib version.

I just answered your PM.
I'm however not happy with my approach, because it is a hack.

Is there any kind of "legal", or remotely acceptable approach to adding missing functionality in the SDK?

My approach has been:
1. Build the project with make, which produces a libsignal.a.
2. Copy the signal.a to SDK:local/newlib/lib

Now you have to add a "-lsignal" whenever you want to use these signal functions. However, the official SDK signal.h, differs from mine. So either I override the SDK one, by adding an "-I/path/to/my/signal.h", or I simply replace the SDK one (oh nooooo!). The latter is really not an option.
But this is somewhat cumbersome, and sometimes you can't easily change the build command line.
Is it possible to somewhere in SDK, globally add extra include files, and standard link libraries?

I'm thinking that I could just use the SDK signal.h, and make a few complements with what's missing with a file like "my_signal.h".

I was eventually forced to set one up. It's not that hard to build the adtools yourself, the most time consuming task is updating the SDK. On the Amiga it's automatically updated with AmiUpdate, but on my Linux, I have to download each lib manually. There was a script on os4depot that did kind of that, but it only supports an old SDK.
And now I've also ended up with like 3 different GCC versions, each with their own SDK. Very confusing.

I do however edit my files on the Amiga, and then transfer them to Linux where I build. Currently using subversion for transfer – would much rather have something better, more automatic.

@AmigaBlitter

Yes, you can, or just do a NOP out of it in util.h. Could be useful if something doesn't work. And it outputs stuff with DebugPrint, so it shouldn't be too bothersome. :)

I should probably have added some documentation. But basically the "signal.h" needs to override the SDK's signal.h. You can see in the makefile for the test program, that I simply set the standard includes directory to "-I .". Guess you could set it to "-I Wherever:you/put/my/stuff" in your project.

@AmigaBlitter

I added my files on my sourceforge:

https://sourceforge.net/p/jaokims-amig ... ff/code/HEAD/tree/signal/

There's also a small test program.

Hopefully it is of use. If anyone finds any errors -- there most certainly are some -- please let me know!