@Raffaele

Quote:

Raffaele wrote: @cdimauro Talking of the devil here comes CDMauro.

Then you should have understood an obvious thing: don't talk about the devil, because he can appear.
Quote:

Benvenuto! Steveme scarsi a munnezza... (Tr. from neapolitan: "Welcome. We just suffered a lack of garbage.")

And here comes the usual, and unique, "argument" that you're capable of use in a discussion: offending people.
Quote:

And perhaps write what you want.

I don't need your permission for this.
Quote:

I have enough of you and this time I will not loose my time reading your acid troll babbling.

Good. The next time avoid to talk about me, and you'll spend even less time.

@all

just for info ... some time infos can be usefull





https://buildd.debian.org/status/fetch.php?pkg=firefox&arch=ppc64&ver=59.0%7Eb4-1&stamp=1517354143&raw=0

@Raffaele
Cdimauro is super troll but i have to say that he was true about crappy P50xx cpus...

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@tlosm

It's worth noting that Debian doesn't support anything other than ppc64 little endian these days...

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

@all
To say truth, everyone can go that easy way: go to the Tobias Netzel page where he put mac-ppc fixed versions of webkit: https://sourceforge.net/projects/leopard-webkit/

Grab the version of webkit from main repo for which he lately make a fixes, then make it compiles with that patches and stuff (without any gui), and make simple shell arument so one can provide an url to the binary, and some simple cairo window in which rendering will happens.

Then, you already have working core (as it was done by Afxgroup with OWB in the begining). Then you test it all ways around, and if all going well, or making new gui on top of it, or then, incorporate morphos's gui.

At least that how i can go with it, if there will be no new version of Odyssey. And probably everyone who want browser and have skills, can go the same way.

Just no one want to worry about, as it not interesting work :) And even then, after that big non-interesting work done, no one can be sure that:

a). Tobias will continue to work on in next years
b). There is no new bugs in his ppc-patches
c). Its all will be crash free
d). No support as usuall

I do not know if there any real (by real i mean for next 10-20 years at least) solution for big-endian cpus, anymore.

Last edited by kas1e on 02-Feb-2018 at 12:28 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@Chris_Y

Debian ports keeping big endian support alive .
https://lists.debian.org/debian-powerpc/2018/01/msg00019.html

Quote:

Chris_Y wrote: @tlosm It's worth noting that Debian doesn't support anything other than ppc64 little endian these days...

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Chris_Y

that is debian ppc64 BE firefox 59

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@tlosm

Quote:

tlosm wrote: @Raffaele Cdimauro is super troll

That's your opinion based on zero facts.

The only clear fact is that you're the troll which was "promoted" to moderator in THE Italians OS4 evangelists forum. Hence your statement about me, which isn't certainly a surprise.
Quote:

but i have to say that he was true about crappy P50xx cpus...

It wasn't the only correct thing which I said.

Anyway, I'm not interested on discussing with the king of the OS4 trolls.

I stopped writing here because Darrin systematically removed all reports that I was doing against you. Basically he gave you the right to infringe the TOS, like you did/do in your Italian forum.

After some time I saw a picture where Darrin was with Trevor and some other OS4 guys. Then I've realized the reason of his behavior...

However, it's perfectly fine for me. I'm not interested on writing here anymore. Except if someone talks about me, either directly or indirectly, like Raffaele, you, or the OS4 fanatic from Israel in the other thread.

So, don't cite me, and you will not see any writing from my side. I'm perfectly happy this way.

Thanks.

@Spectre660

Quote:

Spectre660 wrote: @Chris_Y Debian ports keeping big endian support alive . https://lists.debian.org/debian-powerpc/2018/01/msg00019.html

This is only for PPC64, like tslom stated.

Anyway you don't know if the Javascript JIT compiler is working for PPC64/BE.

Finally, this patch does not mean that Debian supports ANY PPC64/BE software.

@kas1e

You have worked on the Webkit project: does it use the modern C++ (std::thread and such) a lot? This is one potential issue to worry about. At least bmalloc and some test stuff use std::thread but probably there are a lot more of C++11 stuff around.

Alternative strategy: pick the latest known-to-work branch, make sure its JS tests pass. Then move to the next branch and start checking the diff (extremely boring) and try to make the tests pass again. Rinse and repeat. Only after the JS engine is working, proceed with the browser integration.

@Mr_Capehill
Quote:

You have worked on the Webkit project: does it use the modern C++ (std::thread and such) a lot?

Not that i work with it , i only port what Fab do, i for myself know only little bits about. But i know that webkit developers inroduce C++11 as minimum somewhere around 2 years ago.

Quote:

This is one potential issue to worry about. At least bmalloc and some test stuff use std::thread but probably there are a lot more of C++11 stuff around.

At moment when i try to compile versions of webkit which fail with c++11 threading support, i open issues on adtools: https://github.com/sba1/adtools/issues/12 , and probably we find a way to make it works, through i do not test it deeply.

But, i assume once one will start to work with latest webkits, he will need to worry about GCC fixes, as well, thats for sure. Not that he will have needs to it ourself, but create tikets, wait when Sebastian will fix it (if), etc :)

Quote:

Alternative strategy: pick the latest known-to-work branch, make sure its JS tests pass. Then move to the next branch and start checking the diff (extremely boring) and try to make the tests pass again. Rinse and repeat. Only after the JS engine is working, proceed with the browser integration.

Not only extremly boring, but just unreal. They commit so much , every new branch sometime containt just totally different code base, laout and stuff, and whole project not that easy like you can compare few files and make a diff.

And even, if someone will do that boring work, you can imagine hard level of "try to make the tests pass again". Its just hardcore.

But as i say previosly someone already doing this for ppc-macs, and put his diffs on his github, so its can be done from those diffs. Even, probably, last version from deadwood can be updated later with it , but they (webkit authors) for sure again change layout, some functions removed, some added, its all really hardcore mess :)

Last edited by kas1e on 03-Feb-2018 at 07:01 PM.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

@kas1e

Quote:

kas1e wrote: Quote: This is one potential issue to worry about. At least bmalloc and some test stuff use std::thread but probably there are a lot more of C++11 stuff around. At moment when i try to compile versions of webkit which fail with c++11 threading support, i open issues on adtools: https://github.com/sba1/adtools/issues/12 , and probably we find a way to make it works, through i do not test it deeply.

I hope this gets fixed ASAP. A lot of stuff uses C++11 threading, and it's really useful to have.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@kas1e

Quote:

https://sourceforge.net/projects/leopard-webkit/

thx. ill definitely go check it. if i finally get odyssey fully compiled as is. currently stuck at 16%, i need to research linking issues. however had it laying arond for few days while trying to come forward with other things.

Quote:

cdimauro wrote: Quote: Spectre660 wrote: Debian ports keeping big endian support alive . https://lists.debian.org/debian-powerpc/2018/01/msg00019.html This is only for PPC64, like tslom stated. Anyway you don't know if the Javascript JIT compiler is working for PPC64/BE. Finally, this patch does not mean that Debian supports ANY PPC64/BE software.

For Debian, "PPC64" is the designation for BE. They use "PPC64le" (or PPC64el"?)
for little endian.

True, Debian does not support any PPC64 software, but PPC64 developers and
uses have access to their repositories, developer group lists, etc.

I find Firefox 47 works very well for almost any page on my X1000 under Ubuntu, and almost as fast
as Odyssey for Amigaworld.net. Unfortunately, one by one most of my favorite non-Amiga
pages have been becoming unusable with Odyssey.

Spectre660's link shows that there are some people working to bring PPC64 Firefox up
to date. Time will tell whether they can keep up with Firefox changing so fast.

tom

@tbreeden: do you mean that Firefox (is 47 the only version that you tried?) is using a Javascript -> PPC64 JIT, and is working correctly under Ubuntu on your X1000?

Just to understand how the JS->PPC64 situation is. Because if there's a working JIT, even only for PPC64 currently, there's a chance that it might be ported to PPC32 (albeit I think that it will require a lot of effort of very specialized people).

@cdimauro

Quote:

@tbreeden: do you mean that Firefox (is 47 the only version that you tried?) is using a Javascript -> PPC64 JIT, and is working correctly under Ubuntu on your X1000? Just to understand how the JS->PPC64 situation is. Because if there's a working JIT, even only for PPC64 currently, there's a chance that it might be ported to PPC32 (albeit I think that it will require a lot of effort of very specialized people).

No, I don't know enuf to say that, just that the Firefox 47 on my Ubuntu 17.04 Remix
distribution (put together by the AmigaOne Linux wizards)
gives a much better experience than Odyssey on my X1000.

I am still at sea with Linux, and am totally
confused by how many different things are going on.

I have tried higher versions of 32 bit and 64 bit powerpc Firefox package distributions
but have not found them reliable for me.

I've located five different js engines downloaded (binary packages with descriptions mentioning JIT),
but don't know how to find which , if any, is running with Firefox 47. It is very stable and useable,
but not super-fast.

(try
Hyperion Formum: AmigaOne X1000 - Linux only

Tom

@tbreeden

the firefox up 47 have issue on be not because js but because video accel decoding.
when libx264 and libx265 are invoked by the browser the firefox up the 47 crash. this because an endianess never fixed in the video decoders.

Last edited by tlosm on 06-Feb-2018 at 12:05 AM.

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@thread

Pretty sure Im repeating myself here and equally sure that the usual suspects will just dismiss it and keep going with their delusions unpetered.

Anyway.....

The browser situation isnt just an AmigaOS thing. Pretty much only the 3 major OSes keep up to date with browsers, and even then only le.
Best just get used to it, because while there might be updates here and there that temporarily make our browsers more uptodate we will *always* be playing catch up. Always. It's just the way it is.
Zeta/beos, sylable, cloud 9, qnx, etc., etc..... not one has a browser thats even as good as what we have. In fact completely contrary to the general theme of bitching, believe it or not we actually have it pretty good in comparison to most.

Also to whoever suggested that the AmigaOS derived oses arent capable of running a modern browser (cant recall who it was),.... may I suggest you learn a thing or two about it before offering such opinions? A webbrowser isnt far from self contained. Compile in dependancies statically and the OS is almost inconsequential.

@fishy_fis

I was thinking the exact same thing yesterday as I was webbrowsing on a Chromebook. The Chrome browser was incompatible with many sites. I was missing the spoofing feature of Odyssey. I was regretting selling my SAM460. I had it pretty good with that "outdated" browser on that underpowered Amiga.

_________________
I sold my SAM460ex lite... waiting for money to buy a Raspberry Pi... or a Classic A1000 with Buffee... or an A1222... and OS4.3 FE update 11

@fishy_fis

Quote:

Also to whoever suggested that the AmigaOS derived oses arent capable of running a modern browser (cant recall who it was),.... may I suggest you learn a thing or two about it before offering such opinions? A webbrowser isnt far from self contained. Compile in dependancies statically and the OS is almost inconsequential.

I didn't say that as I recall; I was saying that the reason other OS's (including mobile OS's) have capable web browsers is that they are backed by companies that can afford to spend good money on dedicated teams to produce a working browser. I pointed to Otter Browser which is mostly a front end to an existing rendering engine (webkit I believe) and has been in development for four years by a small team of enthusiasts, and while it's main main browser on Linux it still isn't all that great.

I similarly submit that you are overly optimistic about how simple it is to put together a browser. "Compile in dependencies statically" first requires the dependencies to compile.

_________________
I've decided to follow an awful lot of people I respect and leave AmigaWorld. If for some reason you want to talk to me, it shouldn't take much effort to find me.

@fishy_fis

Quote:

Best just get used to it, because while there might be updates here and there that temporarily make our browsers more uptodate we will *always* be playing catch up. Always. It's just the way it is.

And it's been that way for around 20 years. Except now, the internet is developed at a much faster rate. So the problem gets worse more sooner than later and keesp deteriorating.

Quote:

In fact completely contrary to the general theme of bitching, believe it or not we actually have it pretty good in comparison to most.

I'm shocked. Don't they have good developer support and for some Unix underpinnings?

Quote:

Also to whoever suggested that the AmigaOS derived oses arent capable of running a modern browser

Aside from compiler porting and endian issues there is another issue we face now. And that is resources. In particular hardware resources. The newer machines are 64-bit. But modern browsers are really starting to need 64-bit and gigs of RAM. Lack of this will soon choke us as well. Though Odyssey runs well in limitaions on a fast CPU.

Last edited by Hypex on 09-Feb-2018 at 04:03 PM.
Last edited by Hypex on 07-Feb-2018 at 02:13 PM.

@Hypex

Quote:

Hypex wrote: Quote: Also to whoever suggested that the AmigaOS derived oses arent capable of running a modern browser Aside from compiler porting and endian issues there is another issue we face now. And that is resources. In particular hardware resources. The newer machines are 64-bit. But modern browsers are really starting to need 64-bit and gigs of RAM. Lack of this will soon choke us as well. Though Odyssey runs well in limitaions on a fast CPU.

Oh, so you regularly have 20+ tabs open at once too?

I currently have 35 tabs open in Firefox, and it's using about 1 GB of RAM. That's still doable on a 32-bit system.

What we really need is a JIT interpreter for Javascript and WebAssembly. Running it in an interpreter is rather slow, and we don't exactly have the world's fastest machines. The resulting virtual machine should probably be little-endian,** because it'll allow a lot more to work that way (e.g., emscripten compiled stuff makes that assumption).

Hans


** Should be doable because PPC has byte-swapped load/store instructions.

Last edited by Hans on 08-Feb-2018 at 01:16 AM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.