Which is probably "fixed major memory leak where Frames were not released together with their JS data - memory no longer continously consumed while browsing"
@BSZili Is your pthreads implementatio for aros/mos are the same by functionality as pthreads.library on os4 ? Why i ask, is that for building latest webkit, we need c++11 thread support in the GCC, but, that to be use pthread.library, and deadwood use your one, i want to know before start nagging everyone about if os4 one are the same and ok for, or, we need to backport your one to os4 :)
Quote:
It's not a fundamental issue, since WebKit used to work just fine on BE. It's just that nobody has looked into the issue.
We only know that Fab trying to deal with it, and can't at moment by some reassons. So probably hard one.
@kas1e I didn't mean to sound like it's a trivial thing to fix. The needle in the haystack analogy Capehill used was pretty accurate. Take into account that Fab has limited free time, so that's probably one of the reasons why he didn't fix it himself. My pthreads implementation aims to be as POSIX compatible as possible, nothing AROS/MOS specific. The OS4 pthread.library implements the most common ones, and the SDTC++ library only uses those, if I remember correctly.
Yep, that it. Sad to hear, as it mean we need to make a choice: or site for BillE will not works, but we will have your one works. Or for BillE it will works, odyssey will have last openssl, but your one didn't works :)
I am pleased to report that the Avios site still works perfectly with fix_v5.
Hmm, what's causing this? Is it the site that sends wrong SSL information? I thought with the latest OpenSSL "all" of the SSL problems are taken care of?
Probably too recent openssl give us new errors. In V3 i link againt last openssl build by Mick, and while site from BilliE start to work, site from Samo stop working. Then, Mick found that problem happens everywhere (on windows/linux as well), so we a bit downgrade. That fix problem with samo's site, while billie's one still works. Now, your one didn't , so, probably again something-somewhere in the openssl.
What about v5, is it indeed "fixed major memory leak where Frames were not released together with their JS data - memory no longer continously consumed while browsing" ?
Probably too recent openssl give us new errors. In V3 i link againt last openssl build by Mick, and while site from BilliE start to work, site from Samo stop working. Then, Mick found that problem happens everywhere (on windows/linux as well), so we a bit downgrade. That fix problem with samo's site, while billie's one still works. Now, your one didn't , so, probably again something-somewhere in the openssl.
Yeah, i talked to Mick about this and *i* think we shouldn't give in to broken sites or at least don't try to do the web admins work and workaround their faults.
If a site doesn't work with the latest openssl it's probably the site that is broken and should be fixed...at least, security is more important and i'd like to have the latest bugfixed releases of a security suite rather than be able to browse every broken site
Quote:
What about v5, is it indeed "fixed major memory leak where Frames were not released together with their JS data - memory no longer continously consumed while browsing" ?
Well, i haven't had the time to browse one of the ram eating sites i know yet, but at least it doesn't eat away that much memory under normal circumstances like it did before, so i guess it's working.
Thanks for the memory leak fix, that was really annoying, which you had to restart Odyssey after a while.
Is there any possibility to fix the proxy server settings?
What Thore told me:
Quote:
Looking at the Odyssey source all I can tell is that two string objects are created and their contents are read out when ever the a configuration is loaded, saved or reset. Each string object in the window gets a unique ID to automatically set the contents, i.e. after loading a new configuration. However, I just noticed that in contrast to all other string objects the two in question get the same ID. This definitely causes all the trouble, because one setting will be applied to two objects with different tasks and hence cause the trouble you are experiencing. This can only be fixed in Odyssey. Here are the some lines from prefswindowclass.cpp:
Thore always was good at help to find bugs (you can't imagine how much he help us at begining with first version of odyssey port).
As for your issues : yeah, i checked and its the same and for old 1.23 code, and for latest one on github, so i redirect it all to deadwood so he can fix code on github, and i in meantime will fix it in our current 1.23
First, let me post my THANKS to kas1e, Mick and anyone else that decided to jump back into the work on odyssey. It's great to see something happening again.
I've been running the new releases of odyssey on my SAM, X1K and X5K and there does seem to be some boost in speed. Nice to see.
I was most curious to see whether the new versions (especially v5) might have fixed odyssey's memory glutony.
Unfortunately, it's still there. This morning I surfed a couple js/css/gfx heavy sites and ran free memory down to ~620MB and then jumped to this relatively light site. No memory was freed.
I know someone said that odyssey/webkit doesn't deallocate unused memory, but that's not the same as freeing it. Odyssey is not the only app running.
With where AmigaOS is today, it doesn't deal well with low memory situations.
At the very least, would it be possible to add a minimum free memory setting in odyssey?
Finally, I'm noticing more lockups when the new odysseys are running. Unfortunately, I've not seen a repeatable test case, it just happens after having surfed a while. More memory issues?
Before, when you restarted Odyssey, password field copied itself in the username field, now it doesn't happens, but it doesn't work; it says: "couldn't connect to server".
Although I tried the previous version and the proxy server works.