duktape error NetSurf OS3

[wawrzon]

Because clib2 uses memory pools, libnix does plain allocations.  The slowness in clib2 occurs because after a while, memory pools aren't any more efficient than plain allocations.  Switching to libnix just means it will be that slow speed all the time, which isn't really a fix.

please verify with apj (arturs) benchmark here, post #263:
http://www.amiga.org/forums/showthread.php?t=70260&highlight=clib2+libnix&page=14

i admit the circumstances may not be optimal, he probably didnt reload the page from local file, but its obvious that while libnix and ixemul are slower than clib2 initially, clib2 will eventually slow down to 3-6 slower that them. at this point using the memory allocator provided by ixemul 6x.x seems definitely fastest and most stable option. second is libnix. if you say that clib2 behaviour is not a bug but simply consequence of memory alocator using pools adnt that its normal that they will become inefficient with the time, then i wonder why to stick to that solution.

for the record. im not trying to force anything through. but i wonder.

Olaf (olsen).

could you contact him about the matter?

I'll try it when I get chance.  Actually I might ping DNADL a note as it'll most likely get tested quicker.

if you tell me where in the build scripts or headers the copmpiler options are specified i could try to compile it and post binary somewhere for people to test. the libraries/deps need to be recompiled as well i take it?

[wawrzon]

sorry, bit slow on this, trying to compile odyssey for 68k on the other end;)

i see only /dev-netsurf/workspace/netsurf/content/handlers/javascript/duktape/duk_config.h

but i do see there only general platform flag m68k (DUK_F_M68K) no mention of particular cpu target. must be somewhere before. will keep looking for that.

[wawrzon]

That is ugly, what kind of setup is this?

I haven't had that serious color problem ever.

strange. we had and still certainly have a number of pixel format problems displaying images here. denying this doesnt help to improve anything.

best thing would be to gather precise list of correctly displaying formats and those being off, maybe even with a small picture to illustrate whats wrong. can you specify it on your side, dnadnl? i dont remember how to do that exactly, but i have found the following hint:

You can use GetVPModeID to get the mode ID of the current screen and then for example p96GetModeIDAttr to find out the pixel format.

edit: i might look at aros tests, perhaps there is one that reports pixel format and can be compiled without aros libraries. we might need a handy tool to determine pixel formats.

i think its important issue, because its always the problem especially with web browsers, due to fact that amiga rtg solutions provide a number of different modes. and what looks right on one setup will look backwards on another.

[wawrzon]

in aros68k nightly iso there is test/graphics/CGXtest utility.

http://netcologne.dl.sourceforge.net/project/aros/nightly2/20160721/Binaries/AROS-20160721-amiga-m68k-bootiso.zip

i d expect it to run on genuine amiga system, it doesnt seem to need any aros specific headers, so i doubt it gets linked against aros libraries. and if it does, it shouldnt be a problem to be recompiled with amiga compiler. the source is just a single file in corresponding directory in the aros sources:

http://netcologne.dl.sourceforge.net/project/aros/nightly2/20160721/Sources/AROS-20160721-source.tar.bz2

[wawrzon]

@dnadnl

im looking at your script. i have a proposition. could you make installing cygwin optional in future versions? as well as downloading and installation of packages should be available as option the user should be perhaps presented to confirm, after the script checked for required version of particular package and found it missing.

i intend to check how it works on my debian and ubuntu build environments. i may try to implement it myself and send you a diff, but ill probably start with commenting out the unnecessary sections.

[wawrzon]

@dnadnl
no worries, i have been playing around with it at night, just must see how to properly get around that autotools version issue, also i think either one needs to install the toolchain beforehand or resign on putting it in /opt and use the user accessible location.

but it isnt pressing at all. perhaps it isnt a bad idea at all to actually employ cygwin here.

[wawrzon]

i think you must know the issue, since your script exclusively tries to relink to autom4te 2.64 instead, as far as i have brought into my experience, today usual 2.69.

im sorry, i have not looked into that further. been busy trying to get rid of some compiling issues on aros68k, i am looking forward to having odyssey web browser compiled there for 68k. but ill try to contribute to this effort as much as i able too as well.

btw. do i understand well, that the restriction is due to one machine? so i can try to employ any autom4te set i have installed? since i dont remember that problem installing netsurf toolchain by hand..

[wawrzon]

1. That is the intention once I have enough information to sensibly report the problem.
2. Hassle, but might be necessary to (dis)prove the cause.
3. Unlikely to fix this particular problem.

ad2. i would first link against bernds ixemul6x.x. this lib will almost certainly contain all linux functions you might miss with libnix. especially that arturs netsurf can be built with both ixemul and libnix. after all, its only frontend that differs, and why would reaction fronend depend on anything more linux than an sdl port? so it shouldnt be that much hassle in the final analysys.

ad3. you might rip the memory allocator out of the bernds ixemul..