Endianess JavaScript Issues Bounty now exceeds 500 bucks!

http://amigaworld.net/modules/news/newcomment.php?item_id=7649

Are there developers starting being interested with the cash and offer themselves to solve the bugs?

_________________
"When the Amiga came out, everyone [at Apple] was scared as hell." (J.L. Gassée, former CEO of Apple France and chief of devs of Mac II-fx, interviewed by Amazing Computing, Nov 1996).

@Raffaele

what about the v8ppc mentioned in the other thread?
http://amigaworld.net/modules/news/article.php?storyid=7649&start=40#97067

isn't this exactly what the bounty is about?
(didn't read it though)

i'd recommend to take part there?

regards...
michael

_________________
Michael Merkel
(Michael.Merkel@gmx.net Home)
Member of Amiga-Freunde Pfalz, OS4 Welt

@MichaelMerkel

Quote:

MichaelMerkel wrote: @Raffaele what about the v8ppc mentioned in the other thread? http://amigaworld.net/modules/news/article.php?storyid=7649&start=40#97067

V8 is Google's Javascript JIT, and Google decided to create their own fork of Webkit called Blink a few years ago. Needless to say, integrating v8 into Webkit may be a challenge.

Webkit's JIT, is FTLJIT.

IMHO, it's better to stick to the more modest goal of fixing the endianness issues rather than going straight for JIT.

Hans


P.S., If someone were to go down the v8ppc route, then also switching from Webkit to Blink would be a good idea.

_________________
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.

@Hans

I just notice that Netsurf got an update to 3.4 wich according to the website features JavaScript "dukTape" does this feature the endianess bug. Not a developers just wondered. http://duktape.org/

_________________
AmigaNG, YouTube, LeaveReality Studio

@amigang and all!

I never understood what is this "endianess" bug all about? (I know what endianess means, but how would that create bugs?).

Anyhow, I recompiled Duktape on my Amiga 1200 with VBCC (it is very easy because Duktape is very well written and already Amiga-ready) and it runs without problems in the few tests that I made.

Cheers!

_________________
Tygre
Scientific Progress Goes Boing!

@tygre

it likely wont be a single bug but a large number of places in the code where the developers assume a priori particular byte ordering of data, because it is de facto standard these days. there is simply no big endian consumer platforms worth to mention these days, so their assumption is actually justified. at least in 99,99% of cases. therefore if we are talking about this as "bug", its our perspective, on their part and on part of most users its simply a design decision.

there is a post of bigfoot somewhere on morph zone that explains the difficulty with fixing these "bugs", he has been working on. apparently he has done most of the work, but still wasnt able to get the executable run stable, and thats where he has given up, at least for the time being. the problem is that the numerous actual fixes he did are applied to a code base, that as it isnt being synchronized upstream becomes outdated day by day.

the changes, not to be effectively for nothing with every further revision of the engine, would have to be pushed upwards. we dont even know if such agreement could be met. it may well be that maintainers of the main repository would not like to include them as long as there is nothing significant to be gained this way.

Last edited by wawa on 23-Feb-2016 at 12:42 AM.

@wawa

Quote:

it likely wont be a single bug but a large number of places in the code where the developers assume a priori particular byte ordering of data, because it is de facto standard these days. there is simply no big endian consumer platforms worth to mention these days, so their assumption is actually justified. at least in 99,99% of cases. therefore if we are talking about this as "bug", its our perspective, on their part and on part of most users its simply a design decision.

I am very curious to "see" one of these bugs! I can understand that code like the following (others may involve unions, etc.)

int main()
{
int x = 1;

char *y = (char*)&x;

printf("%c\n",*y+48);
}


would depend on "endianness" but isn't it bad coding anyway? I mean, playing around with pointer arithmetic? I know that it is faster but maybe we could argue that such code should use "proper" functions and, thus, would be better off being not dependent on endianness

Quote:

there is a post of bigfoot somewhere on morph zone that explains the difficulty with fixing these "bugs", he has been working on. apparently he has done most of the work, but still wasnt able to get the executable run stable, and thats where he has given up, at least for the time being. the problem is that the numerous actual fixes he did are applied to a code base, that as it isnt being synchronized upstream becomes outdated day by day.

Cool! I'd like to learn from it: would you be able to point it to me?

Quote:

the changes, not to be effectively for nothing with every further revision of the engine, would have to be pushed upwards. we dont even know if such agreement could be met. it may well be that maintainers of the main repository would not like to include them as long as there is nothing significant to be gained this way.

Yes, we must be "quick" to push changes against the most up-to-date code base and it is worth being quick only if we can convince the maintainers that these changes are worth including... maybe they could be willing to integrate code in "#ifdef"? Just dreaming...

Cheers!

_________________
Tygre
Scientific Progress Goes Boing!

@amigang

Quote:

amigang wrote: @Hans I just notice that Netsurf got an update to 3.4 wich according to the website features JavaScript "dukTape" does this feature the endianess bug. Not a developers just wondered. http://duktape.org/

That's great for Netsurf. For Odyssey, you'd have to ask someone who knows how Webkit (and dukTape) works how easy/hard switching to dukTape would be. I'd expect dukTape's interface to the browser to be quite different from Webkit's JavaScript interpreter API, so swapping the interpreter out would likely take quite some effort.

Hans

Last edited by Hans on 23-Feb-2016 at 01:43 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.

@tygre
Quote:

Cool! I'd like to learn from it: would you be able to point it to me?

youll find his post here (#5)
https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=11523&forum=32#124039
rather curious stuff id say..

Quote:

maybe they could be willing to integrate code in "#ifdef"?

they might, if they think that it pays off to, and this exactly is the question..

Last edited by wawa on 23-Feb-2016 at 05:32 AM.

@wawa

Quote:

wawa wrote: @tygre it likely wont be a single bug but a large number of places in the code where the developers assume a priori particular byte ordering of data, because it is de facto standard these days. there is simply no big endian consumer platforms worth to mention these days, so their assumption is actually justified. at least in 99,99% of cases. therefore if we are talking about this as "bug", its our perspective, on their part and on part of most users its simply a design decision.

Which is why a better fix would be to make all those developers change their attitude about the "importance" of big endian support so they will cinsider this in the future. Otherwise there will constantly be new "bugs" introduced as development proceeds and Raffaele would have to collect an endless amount of $500 bounties and competent+motivsted devlopers to "fix" everything that is released. However, IMHO the chances are very slim they would care. As you say, there are no big endian systems anymore, hasn't been for a decade, so why would they care really?

A proper fix would be to migrate the platform to a small endian architecture. That process would open up a lot of other possibilities as well, since if we drop binary backwards compatibility we could have 64-bit, true SMP, true memory protection and resource tracking, and an endless stream of today's hardware with today's performance and prices.

Luckily, this is being done!

@Hans
Isn't it funny how quickly the "anything but fixing Odyssey/JavaScriptCore" people offer alternatives, that'd require much more work than the original task?

_________________
This is just like television, only you can see much further.

@TRIPOS

you still talk about something what does not exist

about endian issues I think that too, developers are supporting modern hardware and not obscure retro systems running on outdated hardware. No chance to motivate them to add support for PPC, not even with money (except someone would offer lots of it)

@TRIPOS

You made the false assumption that any further Javascritpt engine in X86 camp will be rewritten from scratch at any new release featuring an entire new famiily of bugs...

Well, development of software does not works in this way.

Actually Javascript Engine on X86 is very stable as is, and Webkit developers made just some adjustments of code at any new releases...

If our coders will be enough skilled to fix all the existing Javascript Endianess X86 calls that afflict PPC version (we are talking of allocating memory calls that sure are perfectly legit calls for X86, but in the end they result being malicious as bugs for us running on PPC Big Endian) then we will reach a stable situation and we will obtain a decent updated browser.

Just let solve our existing problem now!

Then the only tedious effort we will need for the future, will be limited only to a continuous monitoring of further modifications to original Javascript X86 code to get rid of any new bug it could occur.

_________________
"When the Amiga came out, everyone [at Apple] was scared as hell." (J.L. Gassée, former CEO of Apple France and chief of devs of Mac II-fx, interviewed by Amazing Computing, Nov 1996).

@Hans

Quote:

That's great for Netsurf. For Odyssey, you'd have to ask someone who knows how Webkit (and dukTape) works how easy/hard switching to dukTape would be.

Certainly not trivial.

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

@Raffaele

How I'd approach this (if I had any interest in fixing it, which I don't):

Roll back to the last known working version.
Apply each commit one by one to figure out which one broke it.
Look at what changed in the commit which broke it.

At least then you have a much smaller set of changes to go through. I'm amazed that somebody with the dev environment set up hasn't already done this. If there are a lot of commits between the last known good and the first known broken, then pick one in the middle to narrow it down quicker.

The change which causes the problem could have been identified by now if anybody could be bothered.

Last edited by Chris_Y on 23-Feb-2016 at 01:50 PM.

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

@TRIPOS

Quote:

Which is why a better fix would be to make all those developers change their attitude about the "importance" of big endian support

As always the hard work will be on us. But the fact is here that PPC easily reads and writes in opposite endian so perhaps using an opposite instruction would be best. And as I say, modify the compiler so endian can be specified. This shouldn't be a problem unless binary data is imported or exported which sounds like bad practice anyway.

As long as this approach doesn't affect other parts of normal code and OS calls problem solved and future proof as well.

Quote:

Luckily, this is being done!

Where is this being done? Apart from AROS?

@Chris_Y

Quote:

Chris_Y wrote: @Raffaele How I'd approach this (if I had any interest in fixing it, which I don't): Roll back to the last known working version. Apply each commit one by one to figure out which one broke it. Look at what changed in the commit which broke it. At least then you have a much smaller set of changes to go through. I'm amazed that somebody with the dev environment set up hasn't already done this. If there are a lot of commits between the last known good and the first known broken, then pick one in the middle to narrow it down quicker. The change which causes the problem could have been identified by now if anybody could be bothered.

actually, very much simplified, the approach would have be like this:
1. someone would have to ask bigfoot for sources (since as he wrote he fixed 99% of issues in his version/revision)
2. someone would have to familiarize himself with the source and approach and finalize bigfoots work (the famous last touches, which are the most of the work syndrom)
3. one would have trace the differences between bigfoots version/revision and the current one (looking at the history of commits/ diffing sources) and update the version/revision to the current one along with the fixes.
4. further maintenance as it is demanded here, to keep the code up to date, same way as in previous point.

this is considering the size and complextity of codebase a huge pile of very inconvenient work (as there is no agreement with the upstream maintainers and everything needs to be done home and by hand) and it wont be rewarded with anything in the range of few hundred euros or dollars.

actually first things would be to secure agreement with webkit maintainers and then secure and analyze bigfoots sources and his changes. simply acting up here or other forums wont improve anything a tiny bit..

@wawa

Quote:

actually, very much simplified, the approach would have be like this: 1. someone would have to ask bigfoot

I don't know who "bigfoot" is, but from what you're saying this isn't simply an endian problem in WebKit, but an endian problem in some fork of WebKit, so it's understandable that they aren't interested.

Can't "bigfoot" find the problem and fix it, since they appear to have the correct environment set up and know what they are doing?

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

@Chris_Y


Quote:

I don't know who "bigfoot" is

http://obligement.free.fr/articles_traduction/itwolsen_en.php

_________________
Support AROS sponsor a developer.

"AROS is prolly illegal ~ Evert Carton" intentionally quoted out of context for dramatic effect

@Chris_Y
bigfoot is one of the core morphos developers, who actually addressed the problem discussed here and apparently put a serious work in it. i linked to his post in my answer to tygre just above, so i think i dont need to do it again. bigfoot explains the issue and why it isnt trivial in enough detail for everybody to understand i guess.