Odyssey 1.23 progress: r5 RC2

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 ?:)

@kas1e

Ok you are crosscompiling so maybe it's a silly question, but we doesn't have an updated GCC to try ?
For example latest YAM builds are compiled with GCC 4.7.1, Thore or Damato should have it i think ..

Try to check on: http://sourceforge.net/projects/adtools/

@kas1e

nullptr is a C++11 extension which replaces NULL with a more strictly typed replacement.

So perhaps your g++ doesn't support C++11 ?

I don't know what version of gcc brings that support in.

Judging by this it would be 4.6

https://bugzilla.mozilla.org/show_bug.cgi?id=777511

The suggestion there is to do

#define nullptr __null


BTW your crash is not because r0 in 0x00000000 it's because r8 is 0x00000000.

Can you not get the line number of the crash?

@kas1e

If the old sqlite port you have works fine, you can just keep it. A newer one isn't required.

Regarding your nullptr issue, you'd need a newer GCC (and more recent WebKit will definitely need a newer one since they use more and more C++11 features), but for this particular revision (r155188), you can just replace it with 0. Your crash issue is most likely unrelated to this, and probably caused by ICU somehow.

@samo79
Quote:
I just need to buld last one from adtools, which easy, but is last thing i want to do, as new crosscompiler as usual will bring some new bugs with which need to deal again.


Quote:

I know where adtools placed of course :) Just build new compiler now will mean recompile of whole odyssey again, as well as it will bring new bugs in new compiler which i didn't have in current one (usual stuff) and it will need again some time.

@broadblues
Quote:

It is support it. There is -std=gnu-0x and -std=c++0x which make it works. Whole Odyssey builds with it now. As well, as i says in all other places nullptr works fine in webkit, its just in those particular files it didn't compiles.

Quote:

In google there is bunch of another suggestions as well, but, if check google more deeply, they says that you can't in all the cases replace it on 0 or NULL, expectually when c++ do overloading of all stuff.

There is good pdf which explain differences with null and nullptr: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1601.pdf

After reading of which nullptr =! null for sure.


Quote:

What you mean by "can you not get the line number of the crash" ? How i can't get it, if :

7f860cb0: 80080160 lwz r0,352(r8)

mean relative access to r8 and registers dump show r8 as 0x00000000 too. (edit: fixed typo in previous post about r0).

@Fab
Quote:

I think i will build 4.4.5 to have all the same as you then.


Quote:

That what i do before. Also , in one place i had to replace 0 on nullptr back. And nullptr used in those files no everytime the same. In some its just return nullptr, in some its ? something : nullptr, and co.

Quote:

But crash point out on iterators (where i do those changes), as well as it point on those relative null pointers when crashes, as well as i tried libicu and with libicudatastub.a , and with full libicudata.a as static and all changes in libicu i do, its build it like:

./configure --build=i686-pc-cygwin --host=ppc-amigaos --with-cross-build=/usr/local/amiga/icu/source/icu_os4 --disable-shared --enable-static --disable-tests --disable-samples --disable-debug CFLAGS='-static -mlongcall' CXXFLAGS='-static -mlongcall' LIBS=-lunix

Then i also have to undef some TZNAME define (in pputl.c or something), and as i on cross-compiler i also build x86 version of libicu in another place to have those "bins" which used to generate stuff, and put them instead of ppc ones to aos4 build so be able to compile and generate everything.

That all i do, and its the same as i do before (at least my notes says so for previous versions).

In other words, seems only way to go now its build new compiler from adtools (and meet with new bugs from it, of course :) ). At least it should deal with compiling issues with nullptr, and if bug will be still here, then it will point out on icu itself indeed and then will try to rebuild icu natively on os4.

@All
That all will take some time, probably few days.

@kas1e

If you build the current adtools 4.7.x branch with gcc 4.8.x you will need to apply a small patch.

http://www.amigans.net/modules/xforum ... t_id=86806#forumpost86806

You will need to downgrade texinfo to before v5 as well.

@kas1e
Quote:

By using addr2line on the stack trace or a more recent GrimReaper ofcourse, not from the diassembly obviously.

And, without reading you link to see if there are more differences, the difference between nullptr and 0 is that mullptr invokes the pointer based overloaded function and 0 the integer (if the function is overloaded to differentiate) whether that also applies to NULL which is (void *)0L I dont know. Most of the time that should be okay. You could save yourself the time of building a gcc compiler by checking where the code crashes first!

@Mick
Quote:

There was commits 482-483 from SBA : "Fixed to allow building with latest texinfo tools", imho they deal with.

@broadblues
I know how to use crashlogs :) but i will start from new compiler because i need it soon or later. Better to do it now, and exclude from todo list (for future versions of Odyssey as well).

@kas1e

From your stack trace, it doesn't look related to these small nullptr/0 changes at all... It's really about ICU. It's not that unusual to have crashes that points to null pointers, you know... It doesn't mean it's related to these nullptr changes.

A wild guess would be ICU fails to find some of its data files, and since it's so well designed, it doesn't check for errors and crashes. So if you want to make a quick test, just change findWordBoundary to something void, and see what happens.


And about this nullptr issue, i really just replaced with 0 where needed in my port. I just didn't include this change in released sources because you may not have needed it, if you have compiled it with a newer gcc, i didn't want to change webkit sources there without reason.

@Fab
Quote:

I just reuse your data files from 1.23. So it should find all datafiles imho and all should works ?

Can you just post your configure line for libicu so i can be sure i build it same as you ? You for sure make no single change in libicu ? Not a single/simple one ?

Quote:

I build libicu without changes just like you says, as well as i reuse your datafiles from 1.23. How it can not find datafiles then ?

Quote:

Ok, will check it tomorrow.


Quote:

Omiga1200 ! i was in hope that your sources 1:1 the same as you release, and because of that make assumption that if sources have ppc-morphos-gcc-4.4.5 then sources ready to build for exactly that..

@kas1e

Well, you should run that snoopdos-like tool to check if ICU really looks for these files in progdir:resource/icublah/ dir? If you didn't specify this path anywhere in your icu build, it's extremely unlikely they will be found magically by ICU. :)