Odyssey 1.23 progress: r5 RC2

@MickJT

If all that disabling debug removes is debug symbols and gstabs info then why remove it? Kas1e may not like it but he is just one developer and seeing which function your program crashes in when developing is very useful.

If debug adds actual debug code though, there may be efficiency reasons to remove it.

gstabs stuff does not affect executable size WRT to relocation etc on the size of the file on disk. I don't think debug symbols are even loaded into memory (for static builds not so sure about sobjs) until it crashes and the Grim Reaper appears.

Well, I'll think about it some more :) I want to just leave things how they are by default. If it's built with -g, then it stays that way. The ffmpeg libraries I could make an exception since they're rather big. However, those are only static libs, and so you're still going to be able to strip whatever binary you make with them.

Quote:

Yeah, that's why I was asking before whether --disable-debug did anything more than remove -g. With ffmpeg it might disable other code that's unnecessary for a release archive, but I don't think it does.

@All
I update to all 3d party libs ports, now in 1.23 we will have:

cairo : 1.12.16
pixman-1 : 0.32.4
sqlite3 : 3.8.2
ffmpeg : 2.1.1 (snapshoot from 2014.01.09)
icu : 49.1.2
libpng12 : 1.2.50
curl : 7.34.0
rtmp : 2.4
openssl : 1.0.0l
xml2 : 2.9.1
xslt : 1.1.28

As well , as with all that removing and striping final binary are "just" 52mb of size (that with attached mediaplayer libs and co), which even a bit smaller than on morphos :)

Another good news is that i have some initial version of calltips.mcc from Thore, that mean it also passed. Now some minor bugs which the same to fix as previously, and in other words i hope tomorrow to have browser running and have some tasty screenshots !

@kas1e

Awesome, great work man. Thanks for your efforts on porting Oddyssey to OS4!

Cheers,

Dragster

@kas1e
great news... Keep up the good work mate....

@kas1e
Very great news !

@kas1e

Awesome!

Sometimes I wish this forum had a like button for posts /jk

Fantastic, looking forward to the screenshots

nice work.. you doing a great job:)

@kas1e

Yaiii! \o/

Excellent work.

If I was porting it and had all the libpng problems I'd have scapped libpng and used datatypes to decode all static images instead, giving a smaller exe, no future problems with libpng incompatabilities etc. but then that would take time and everyone wants a fast port.

@Severin

Except datatypes aren't suited at all for that, and it would actually give a (much) slower result.
I could use reggae for decoding, though.

@kas1e

soon we will browsing!

Great work kas1e :)

@Fab
Quote:

What makes datatypes unsuitable for this task? Loading image data is one of the things that they were designed for.

Hans

@Hans

But in WebKit's case, for performance reasons, slice decoding is needed. With Datatypes, you get the whole thing decoded at once (and with a high memory footprint as well).

@Hans

Datatypes (at least their current implementations) are not designed for any kind of streaming - partial loading of data.

@trixie

IBrowse has been using datatypes forever with no problems with displaying or speed.

@Severin
Quote:

libpng is only 300kb of size, which is really nothing in compare with what it give in end. Besides, on morphos, odyssey use shared png.library, so those 300kb out of binary (but as core itself its pretty big, 300kb there is just nothing, so i think shared png.library or static as i do it now, there is no diffs). Rewrote all that stuff in odyssey on datatypes (even if it was of worry), instead of deal with libpng, for sure _MUCH_ harder and make no sense at all (i.e. compare pure recompile, and sitting days and code stuff, deep inside of internals of all of this, while there is some stuff to fix still).

Quote:

Core of IBrowse totaly outdated, and once (if imagine) anyone will add all that support of bloated modern things to it, everything will tells, including usage of datatypes. Ibrowse fast, because have no support of what make other browsers be slower.

Besides, we both know that png.datatype on os4 for sure outdated in compare with all the time in develop libpng.

In other words, even, and if, its still make no sense to remove as its just not worth of it.

@All
Some news:

After fixing of some usual moments, it runs, generate fontconfig, show window and happy crashes on sqlite3 functions. In end it turns that my pure recompiled sqlite3.8.2 as posix based pure like this:

./configure --build=i686-pc-cygwin --host=ppc-amigaos --disable-shared --enable-static --disable-dynamic-extensions CFLAGS='-DSQLITE_OMIT_WAL=1 -Os'

didn't works. Once i link with HansJoerg's sqlite 3.7.5 i have no crashes (or even if i link with my old sqlite3).

Sadly i do not remember now what library (or odyssey itself?) ask for new version of sqlite3, so i just currently link with Hans one, and at moment we can skipthat till more major problems not sorted.

@Fab
are you make any specific changes in sqlite3 to make it works ?

@All
So, after sqlite crash fixed, i have working main window. But, here is another problem which i think related to my current os4 compiler and all that tasty changes in terms of adding "nullptr".

I.e. some files before just do not compiles on my gcc, and bring all sort of erros about "nullptr".


I.e. file Source/Webcore/accecebility/AccessebilityNodeObject.cpp

Do not compiles before with such errors:





So i had to replace nullptr in that file on NULL, as well as do the same replaces in the ElementAncestorIterator.h and ElementIterator.h. But while that can looks logical, its still wrong when it come to c++ and all that overloading of everything (see google, it can be ok for some cases, but still can't for another, expectually for c++ and overloading).

Another error come from Source/Webcor/dom/ConainerNode.cpp, and while a bit different, still about the same nullptr, and still i had to replace it on NULL too to make it compiles (which is also can be just wrong):

Quote:


In other words, in those fils i do that changes to make it compiles on my gcc (i.e. nullptr on null).

Source/Webcore/dom/ElementAncestorIterator.h
Source/Webcore/dom/ElementIterator.h

Source/Webcore/dom/ContainerNode.cpp:
Source/Webcore/dom/element.cpp
Source/Webcore/dom/spacesplitstring.cpp
Source/Webcore/history/cachedpage.cpp
Source/WebCore/html/HTMLFieldSetElement.cpp
Source/WebCore/html/HTMLFrameSetElement.cpp
Source/WebCore/html/HTMLLegendElement.cpp
Source/WebCore/style/StyleResolveTree.cpp


I use gcc 4.4.3, while fab use 4.4.5. I do not know why i have those errors, i assume because of gcc differences, dunno.. Strange thing, is that this "nullptr" used in all other parts of webcore, and dindn't bring any errors or warning. Webkit even have nullptr.h and nullptr.cpp files, where there is special defines of nullptr for compiler which do not have it, and while it works for all parts, as i say for those files which i quote it didn't , and to make it compiles i had to replace it like this. Maybe 4.4.5 gcc deal with it normally, dunno.

Going deep inside of c++ webkit code are of course mess, and i do not know a shit there. So only idea i have for now, its build latest version from adtools (is it 4.4.5 as well ?) and try to build it.

I of course think about chaing those nullptr on something like (void *)0 , so to make it "like nullptr" or making some things like done in the google by ppls who have same kind of problems (i.e. make template/class/etc for it), but just do not know if that right to make those hacks-shmaks, while all should just compiles as it.

Visually now, its all crashes with null-pointer once i start to works with pages (db-click on some forms, etc). Even can reproduce it in "About:" page, just by clicking on credits part : click on unfold them fine, then clicking to fold them back : crash is coming.

Crash looks like this:




While crash point out on icu, i still think problem is with nullptr changes, as its all about changes in the ElementItterator.h (and crashes are in the TextBreakIterator function of webcore which then crasehs on same function in ICU itself) and related files which do not compiles as it.

Besides crashlog point out on null-pointer crash as well (r8=0x000000) which can mean exactly all that changes and that there is those situations when nullptr is must, and null can't be. I fear if i will made some replacements (like (void *)0), it still will have bad side-effects because of all those overloads and c++ crappos.

Damny damn ! Any ideas suggestion for fast fix so we can check youtube ?:)