Odyssey 1.23 progress: r5 RC2

	Bottom Previous Topic Next Topic
Register To Post

« 1 ... 3 4 5 (6) 7 8 9 ... 72 »

tlosm

Re: Odyssey 1.23 progress

Posted on: 2014/2/3 15:30 #111

Quite a regular

@Fab
ot/
with 9000pro i have the same result but with more cpu consuming i have to downgrade the machine with 9250 128bit and at 1ghz cpu and only with 1gb of ram and without the Sblive 5.1 and with a standard hd and not a samsung ssd ... you think this will make me feel better because i have this exactly performances on the Xe 933 with Radeon 9250 and Mplayer under AmigaOs 4.1 and with a worst configuration?
ot/

djrikki

Re: Odyssey 1.23 progress

Posted on: 2014/2/3 15:37 #112

Quite a regular

Great to see a screenshot... okay a non-video related question from me.

Question for fab and kas1e

Okay this is fairly common in all web browsers, but a bit of a pet-hate. When the user has ONLY ONE webpage open there is really no need at all to show pages as tabs - its a complete waste of space - hide it. It only makes sense to show open webpages as tabs when there is more than one open.
I remember ages ago (possibly years) seeing what I am asking for in another browser.

Fab

Re: Odyssey 1.23 progress

Posted on: 2014/2/3 15:41 #113

Just popping in

@tlosm

It just doesn't make *any* sense at all. But what about checking if you have framedrop option enabled? If you do, just disable it.

kas1e

Re: Odyssey 1.23 progress

Posted on: 2014/2/3 15:48 #114

Home away from home

@tlosm
Just start new thread about mplayer

@fab
Do those changes, rebuild whole icu, link against it, and the same crashes :(

It there anything else i need to do in libicu ? Like some special flag in configure line ? I build my like this:

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

Also it is ok to link with that stubdata/libicudata.a ?

On what i can check snoopy log to see if it do what it should do or not ? All i have is those "ok" locks to the resource:icudt49b. I even try to catch only fails in snoopy, and it show nothing about icu, like all ok. Should be there just Open calls to those icu files, not only locks ?

EDIT: right, i see on morphos that first it doing locks (your checks from icufiles.cpp), and then, it really opens those files when owb starts, but for me no open calls happens at all , like icu didn't do what should do.

tlosm

Re: Odyssey 1.23 progress

Posted on: 2014/2/3 15:54 #115

Quite a regular

@kas1e

you true sorry my fault...

Fab

Re: Odyssey 1.23 progress

Posted on: 2014/2/3 16:01 #116

Just popping in

@kas1e

It's obvious snoopy reports access to the icu data files, since i explicitly check for them a startup. But what matters is if they're actually found by ICU when it looks for them. And it looks for them at runtime, when you access a page and render some text, not right at startup. So just check for snoopy when you actually access a page.
You can disable the function in icufiles.cpp for now if it makes it easier for you to understand what's going on.

And regarding build options, i used something like
./configure --disable-tests --disable-samples --host=ppc-morphos --disable-threads --disable-shared --enable-static --disable-dyload --enable-release --with-data-packaging=files

kas1e

Re: Odyssey 1.23 progress

Posted on: 2014/2/3 16:06 #117

Home away from home

@Fab
Imho that "--with-data-packaging=files" will make sense. Will try now.

Quote:

And it looks for them at runtime, when you access a page and render some text, not right at startup. So just check for snoopy when you actually access a page.

Imho i notice opens at startup on morphos because "About:" is already some page with content

samo79

Re: Odyssey 1.23 progress

Posted on: 2014/2/4 0:53 #118

Home away from home

@kas1e

The tube !! \o/
Very curious to see it in action even if at the end i presume we should adapt it a bit (p96 instead of cgfx) to gain the best performance

kas1e

Re: Odyssey 1.23 progress

Posted on: 2014/2/4 12:25 #119

Home away from home

@Fab
Still fighting with that sucking crap called libicu.

Don't you build libicudata.a yourself ? I find in your linking line you use it, but when i build with "release-files" , it didn't build for me any libicudata.a , and all what i have, is that datastub/libicudata.a of 900 bytes of size, and inside of which reference to icudt49_dat and when i link with it together with your changes, odyssey still don't open any icu files. (maybe that stub of libicudata.a are reasons that icu don't try to open any files and i need to make my own?)
@samo
Quote:

Very curious to see it in action even if at the end i presume we should adapt it a bit (p96 instead of cgfx) to gain the best performance

If you mean window mode, then there no differences to use p96 or cgx_wpa, as its all about the same in end.

On sams window mode will be always slow in any case, and only solution there will be to use full-screen overlay and replace cgx on on p96 one , which should do someone else later, with better skills (but i can point out on what need to change and co of course). As it seems cgx emulation of overlay do not works for us (at least, i can't tick to fullscreen in any of players, but that al also need invistigation, and currently i annoyed by libicu shit).

Edited by kas1e on 2014/2/4 12:40:57
Edited by kas1e on 2014/2/4 12:44:24
Edited by kas1e on 2014/2/5 7:33:03

MickJT

Re: Odyssey 1.23 progress

Posted on: 2014/2/4 13:33 #120

Just can't stay away

@kas1e

I'm not sure if this will help, but I remember when trying to port libICU in Linux with a cross-compiler, only the stub data file was created. I couldn't figure out how to get it to build the full data file.

I think it wasn't detecting big endian. I ported it natively and it was fine. Even though you have the stub data built, perhaps if it's built natively the problem will go away?

I had been meaning to ask you if you managed to get libICU to build a static "full" libicudata library when cross-compiling. Your previous posts indicate you did that. Maybe it's a difference in versions. What does "-static" do?

magnetic

Re: Odyssey 1.23 progress

Posted on: 2014/2/4 23:15 #121

Just popping in

@MickJT @ kas1e

I wish I was a programmer you guys are sooo cool :)

samo79

Re: Odyssey 1.23 progress

Posted on: 2014/2/4 23:41 #122

Home away from home

@kas1e

Quote:

On sams window mode will be always slow in any case, and only solution there will be to use full-screen overlay and replace cgx on on p96 one

Yep, for sure i will expect some speed issue considering my hardware, that's why i ask for a fast replacing of cgx to p96.. at this level even a little improvement would be more then welcome and might set a boundary between an usable and a not usable experience .. aniway it's too early to talk about, let's finish first, then we will test it and hopefully you might found atleast 1 skilled dev for help

Aniway did you read my PM ?

noXLar

Re: Odyssey 1.23 progress

Posted on: 2014/2/4 23:49 #123

Not too shy to talk

@magnetic

yea, it looks fun..and very advance

MickJT

Re: Odyssey 1.23 progress

Posted on: 2014/2/5 0:22 #124

Just can't stay away

@magnetic

Eh, I'm no programmer. I certainly couldn't port something like Odyssey :)

kas1e

Re: Odyssey 1.23 progress

Posted on: 2014/2/5 6:50 #125

Home away from home

@Mick
Quote:

I'm not sure if this will help, but I remember when trying to port libICU in Linux with a cross-compiler, only the stub data file was created. I couldn't figure out how to get it to build the full data file.

That boring icu builds in that ways: firstly it builds some stub + some libraries, then as the last one it build libicudata.a, to build which all that icu building process create bunch of binaries which will runs to generate icu data files and some stuff in between. So, if you build on cross-compiler, you will go till moment when icu will build all the libs except libicudata.a , then building process will try to run those generated binaries from bin directory , and as they builds for os4, they will not runs on cross-compiler env => fail to generate list of icu files => fail to generate final libicudata.a with all the stuff inside.

Solution is to build for first everything for your cross-compiler (so it will build bins for your cross-compiler and they can runs), then build exactly for aos4 in another place and use those binaries from cross-env. Then, they will runs when need and they will generate all the necessary stuff you need and will create big-fat libicudata.a (That of course if you do not use option "release-files", because with that option, icu think that there no needs to create libicudata.a ) (or i do something wrong and there need to add more flags, dunno).

In other words that what to do:

Quote:

1.
Build icu for cygwin (to use later those binaries from "bin" to generate necessary stuff):

# cd /usr/local/amiga/icu
# mkdir cygwin
# cd cygwin
# sh /usr/local/amiga/icu/source/runConfigureICU Cygwin
# make

Or if you not in cygwin instead of runConfigureICU Cygwin, you can choice one you need by runing runConfigureIcu --help, or just pure:

../../icu/source/configure --disable-shared --enable-release --enable-static --disable-tests --disable-samples --disable-debug

2.

Once everything done for cygwin , we then build it for os4 (if we want fat libicudata.a as well):

# cd /usr/local/amiga/icu
# mkdir aos4
# cd aos4
# ../../icu/source/configure --with-cross-build=/usr/local/amiga/icu/cygwin --host=ppc-amigaos \
--enable-static --disable-shared --disable-dyload --enable-release --disable-tests --disable-samples --disable-debug
# make

So, its all builds for aos4 as before (include those tools for generation in "aos4/bin", but, will use cygwin ones when time is come (i.e. when time is come to generate libicudata.a and all other stuff).

Quote:

I think it wasn't detecting big endian.

At least for me it detect endianes fine.

Quote:

I ported it natively and it was fine.

Even on native you should meet with problems when icu bins will start to generate all that icu files (i remember when i do port for previous odysseys, i had manually replace patches and co to make it all works, which was pretty boring and annoing).

Quote:

Even though you have the stub data built, perhaps if it's built natively the problem will go away?

I will go just usual normal way: i will build now icu for x86, will make some tests with x86 test-files, and then will make the same on os4 till it will start works, and then will make it in odyssey. I just hope there will be no needs to write code for making own libicudata.a.

Quote:

I had been meaning to ask you if you managed to get libICU to build a static "full" libicudata library when cross-compiling. Your previous posts indicate you did that. Maybe it's a difference in versions. What does "-static" do?

That "-static" is option for linker , to be 100% sure that all what i do not related in any way to sobjes and creation of files with dyn-ld and co (because of SDK its sometime necessary to provide -static to avoid automatic usage of sobjes). Most of time you can not use it, but i just want to be sure its always static, without sobjes. In other words its flag for linker itself, not for libicu building process.

Edited by kas1e on 2014/2/5 7:32:43
Edited by kas1e on 2014/2/5 8:14:01

Fab

Re: Odyssey 1.23 progress

Posted on: 2014/2/5 8:56 #126

Just popping in

@kas1e

I compile ICU myself with the configure line and changes i gave above. And it produces a very small libicudata.a (856 bytes, with just stubdata.ao:
00000000 R icudt49_dat as symbol).

Just in case, check what the file icu/source/config/mh-unknown looks like for you. In my case, i had to copy it from mh-linux, but it doesn't seem related to datafile package in any case, anyway.

kas1e

Re: Odyssey 1.23 progress

Posted on: 2014/2/5 9:57 #127

Home away from home

@Fab
Quote:

I compile ICU myself with the configure line and changes i gave above. And it produces a very small libicudata.a (856 bytes, with just stubdata.ao: 00000000 R icudt49_dat as symbol).

Almost the same as for me then:

Quote:

Admin@microsof-9c3473 /usr/local/amiga/icu/aos4

# ls -la stubdata/
total 16
drwxr-xr-x+ 1 Admin root 0 2014-02-05 12:40 .
drwxr-xr-x+ 1 Admin root 0 2014-02-05 13:02 ..
-rw-r--r-- 1 Admin root 4017 2014-02-05 12:40 Makefile
-rw-r--r-- 1 Admin root 940 2014-02-05 12:00 libicudata.a
-rw-r--r-- 1 Admin root 792 2014-02-05 12:00 stubdata.ao
-rw-r--r-- 1 Admin root 731 2014-02-05 12:00 stubdata.d

And that stubdata.ao are:

objdump:

Quote:

# ppc-amigaos-objdump -x stubdata/stubdata.ao

stubdata/stubdata.ao: file format elf32-amigaos
stubdata/stubdata.ao
architecture: powerpc:common, flags 0x00000010:
HAS_SYMS
start address 0x00000000

Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000000 00000000 00000000 00000034 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000000 00000000 00000000 00000034 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00000000 00000000 00000034 2**0
ALLOC
3 .rodata 00000038 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .comment 00000012 00000000 00000000 0000006c 2**0
CONTENTS, READONLY
5 .gnu.attributes 00000014 00000000 00000000 0000007e 2**0
CONTENTS, READONLY
SYMBOL TABLE:
00000000 l df *ABS* 00000000 stubdata.c
00000000 l d .text 00000000 .text
00000000 l d .data 00000000 .data
00000000 l d .bss 00000000 .bss
00000000 l d .rodata 00000000 .rodata
00000000 l d .comment 00000000 .comment
00000000 l d .gnu.attributes 00000000 .gnu.attributes
00000000 g O .rodata 00000038 icudt49_dat

# Admin@microsof-9c3473 /usr/local/amiga/icu/aos4

readelf:

Quote:

# readelf -a stubdata/stubdata.ao

ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: PowerPC
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 224 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 10
Section header string table index: 7

Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000034 000000 00 AX 0 0 1
[ 2] .data PROGBITS 00000000 000034 000000 00 WA 0 0 1
[ 3] .bss NOBITS 00000000 000034 000000 00 WA 0 0 1
[ 4] .rodata PROGBITS 00000000 000034 000038 00 A 0 0 4
[ 5] .comment PROGBITS 00000000 00006c 000012 00 0 0 1
[ 6] .gnu.attributes LOOS+ffffff5 00000000 00007e 000014 00 0 0 1
[ 7] .shstrtab STRTAB 00000000 000092 00004d 00 0 0 1
[ 8] .symtab SYMTAB 00000000 000270 000090 10 9 8 4
[ 9] .strtab STRTAB 00000000 000300 000018 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

There are no program headers in this file.

There are no relocations in this file.

There are no unwind sections in this file.

Symbol table '.symtab' contains 9 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FILE LOCAL DEFAULT ABS stubdata.c
2: 00000000 0 SECTION LOCAL DEFAULT 1
3: 00000000 0 SECTION LOCAL DEFAULT 2
4: 00000000 0 SECTION LOCAL DEFAULT 3
5: 00000000 0 SECTION LOCAL DEFAULT 4
6: 00000000 0 SECTION LOCAL DEFAULT 5
7: 00000000 0 SECTION LOCAL DEFAULT 6
8: 00000000 56 OBJECT GLOBAL DEFAULT 4 icudt49_dat

No version information found in this file.
Attribute Section: gnu
File Attributes
Tag_GNU_Power_ABI_FP: Hard float
Tag_GNU_Power_ABI_Vector: Generic
Tag_GNU_Power_ABI_Struct_Return: r3/r4

Dunno, maybe something related that i had to use '-mlongcall' for libicu ?

Btw, aslo in original ptuil.cpp, i have those erros initialy:

Quote:

../../../icu/source/common/putil.cpp: In function 'void uprv_tzset_49()':
../../../icu/source/common/putil.cpp:627: error: 'tzset' was not declared in this scope
../../../icu/source/common/putil.cpp: In function 'int32_t uprv_timezone_49()':
../../../icu/source/common/putil.cpp:637: error: expected primary-expression before ';' token
../../../icu/source/common/putil.cpp: In function 'const char* uprv_tzname_49(int)':
../../../icu/source/common/putil.cpp:1092: error: 'tzname' was not declared in this scope
../../../icu/source/common/putil.cpp:1097: error: 'tzname' was not declared in this scope
../../../icu/source/common/putil.cpp: In function 'void u_setDataDirectory_49(const char*)':
../../../icu/source/common/putil.cpp:1155: warning: suggest parentheses around assignment used as truth value
../../../icu/source/common/putil.cpp: At global scope:
../../../icu/source/common/putil.cpp:2239: warning: unused parameter 'libName'
../../../icu/source/common/putil.cpp:2246: warning: unused parameter 'lib'
../../../icu/source/common/putil.cpp:2254: warning: unused parameter 'lib'
../../../icu/source/common/putil.cpp:2254: warning: unused parameter 'sym'

I deal with them by adding to putil.cpp at lines 620 (where generic time zone layer starts) that:

#undef U_TZNAME
#undef U_TZSET
#undef U_TIMEZONE

To make it compiles , wasn't it necessary for you as well ?

Quote:

Just in case, check what the file icu/source/config/mh-unknown looks like for you. In my case, i had to copy it from mh-linux, but it doesn't seem related to datafile package in any case, anyway.

Yep, same for me.

Edited by kas1e on 2014/2/5 10:17:13

kas1e

Re: Odyssey 1.23 progress

Posted on: 2014/2/5 10:39 #128

Home away from home

@Fab
I also do search in all .cpp files of odyssey on "u_setDataDirectory" (as i read by that function directory for necessary files should be set), but found none. Where that place where those files should loads ? I just want to find that place in odyssey and put some debug code in.

Join us to improve dopus5!
AmigaOS4 on youtube

Fab

Re: Odyssey 1.23 progress

Posted on: 2014/2/5 10:50 #129

Just popping in

@kas1e

I don't have to call this function, since i set the proper data directory in ICU itself (in putils.cpp).
And that's u_getDataDirectory() that sets it itself with the default directory define, anyway (path=U_ICU_DATA_DEFAULT_DIR).

About this timezone stuff, i also had to undef as you did, but it's unrelated to your data files issue.

kas1e

Re: Odyssey 1.23 progress

Posted on: 2014/2/5 11:03 #130

Home away from home

@Fab
Have interesting moment now. Do some test with morphos version of odyssey, and once i run it and it start to open "About:" all icu resources loads. I.e. i don't need to press by mouse on anything to make them loads, just running of odyssey with "about:".

On os4, once i load odyssey with "About:" page nothing loads from icu, and nothing crashes (and no Fail calls with tries to load icu resources), but once i do unfold of credits and fold back, then i have in snoopy:

Quote:

00001 : OWB : FAIL = Open("PROGDIR/Resource/icudt49b/brkitr/en_US_POSIX.res",OLD) = [0x00000000] [283uS]
00002 : OWB : FAIL = Open("PROGDIR/Resource/icudt49b.dat",OLD) = [0x00000000] [93uS]
00003 : OWB : FAIL = Open("PROGDIR/Resource/icudt49b/brkitr/en_US.res",OLD) = [0x00000000] [69uS]
00004 : OWB : FAIL = Open("PROGDIR/Resource/icudt49b/brkitr/en.res",OLD) = [0x00000000] [62uS]
00005 : OWB : FAIL = Open("PROGDIR/Resource/icudt49b/brkitr/root.res",OLD) = [0x00000000] [61uS]

And then GR coming. What did it mean, is that patches crap still here ! "PROGDIR/Resource" by some reasons still, not "PROGDIR:Resource" while i cleary have:


#define ICU_NO_USER_DATA_OVERRIDE 1

#define U_ICU_DATA_DEFAULT_DIR "PROGDIR:Resource"

#define ICU_DATA_DIR U_ICU_DATA_DEFAULT_DIR



U_CAPI const char * U_EXPORT2

u_getDataDirectory(void) {

    const char *path = NULL;

#if defined(ICU_DATA_DIR_PREFIX_ENV_VAR)

    char datadir_path_buffer[PATH_MAX];

#endif



....

And in libicuuc.a i have found "PROGDIR:Resource", from what that "PROGDIR/Resource" come then..

EDIT: I even manually do at end of u_getDataDirectory:

Quote:

...
//u_setDataDirectory(path);
u_setDataDirectory("PROGDIR:Resource/icudt49b");
return gDataDirectory;
}

Just to see if it will works, and nope ! in snoopy still "PROGDIR/Resource". Damn, seems some other function replace it somehow somewhere or maybe i need to rebuild odyssey again (after i do changes in the unicode/putil.h so those :;/ will takes in account somewhere in webkit ?)

Edited by kas1e on 2014/2/5 11:23:39
Edited by kas1e on 2014/2/5 11:23:40
Edited by kas1e on 2014/2/5 11:24:18
Edited by kas1e on 2014/2/5 11:39:03

Register To Post	« 1 ... 3 4 5 (6) 7 8 9 ... 72 »
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )