Rhino project (half) asleep?

Marc Guillemot

unread,

Jan 21, 2008, 3:30:39 AM1/21/08

to

Hi,

first I don't want to offend committers (btw: who are you?) who may work
hard on E4X or JS 1.7 support for instance: as I'm not currently
interested in these features, I don't know how active are this areas. My
comment concerns only "normal", current features.

It seems to me that the Rhino project is currently a bit asleep. It's
not a good news for us (HtmlUnit) but there is no progress on many
issues that matter for us, even when patches are provided. I don't await
that problems get immediately fixed but there is nothing worst than silence.

Of course we (HtmlUnit again) can fork / patch / adapt the Rhino version
that we use. This is an option that we seriously consider but we would
prefer an healthy Rhino project that accepts the improvements we may
propose because maintaining a patched version requires a lot of
additional work.

How do you see Rhino's future?

Cheers and long life to the beast,
Marc.
--
Blog: http://mguillem.wordpress.com

Attila Szegedi

unread,

Jan 21, 2008, 8:13:43 AM1/21/08

to Marc Guillemot, dev-tech-js-...@lists.mozilla.org

On 2008.01.21., at 9:30, Marc Guillemot wrote:

> Hi,
>
> first I don't want to offend committers (btw: who are you?)

No offense taken. People most likely to commit something these days
are Norris Boyd, David P. Caldwell, and myself. Igor Bukanov is also
nominally still a committer, but he's absent from the project for
about two years now. (Which doesn't necessarily mean anything --
Norris was also away for quite long before he could fortunately return).

> who may work
> hard on E4X or JS 1.7 support for instance: as I'm not currently
> interested in these features, I don't know how active are this
> areas. My
> comment concerns only "normal", current features.
>
>
> It seems to me that the Rhino project is currently a bit asleep. It's
> not a good news for us (HtmlUnit) but there is no progress on many
> issues that matter for us, even when patches are provided. I don't
> await
> that problems get immediately fixed but there is nothing worst than
> silence.

Norris seems to concentrate on JS 1.7 currently, but he's committing
other patches too. David's primary area is E4X, but he is able to help
out elsewhere as well.

I myself am having a bit of guilty conscience as I can't seem to find
time lately to tend to Rhino's Bugzilla. Every now and then I'll go
through Bugzilla, review patches, and commit them. I haven't been able
to do such a "patch sweep" since end of October though. I'm aware we
have a lots of patches piled up in Bugzilla, but life is constantly
getting in the way of me spending my free time on reviewing them for
quite long now. I'm not being apologetic, it's just the way life is
now. I'm looking forward to review and commit those patches as soon as
I can, which I know isn't much of a promise... As soon as I will have
time, I will go through the patches, especially knowing that there are
people out there who depend on it.

I recognize HtmlUnit as a valuable user of Rhino -- you are basically
our "go to" target where we send people asking how do they do HTML DOM
in Rhino, which is a quite significant added value as lots of people
seem to want to be able to do that.

> Of course we (HtmlUnit again) can fork / patch / adapt the Rhino
> version
> that we use. This is an option that we seriously consider but we would
> prefer an healthy Rhino project that accepts the improvements we may
> propose because maintaining a patched version requires a lot of
> additional work.

That's correct. I do understand your concerns however.

> How do you see Rhino's future?

It's empirically proven that we need more active committers :-). I'm
trying to recruit talent from time to time - that's how David came to
the project. I also had someone turning down an invitation, which of
course I also have to respect. If someone is prolific in submitting
patches to Bugzilla, and they show a good understanding of the
codebase, then after a while it's less hassle to offer commit access
than to keep reviewing the patches. But I definitely need another
patch sweep cycle before deciding on this. Or input from other
committers who do it.

Attila.

Norris Boyd

unread,

Jan 21, 2008, 6:53:06 PM1/21/08

to

No offense taken; it's legitimate to judge the activity level on open
source projects you depend upon.

In this case, I think I've been reasonably responsive. You filed three
bugs with patches. I've accepted one and committed it to CVS, I've
responded to another and said I want to postpone it until the next
release due to the possible impact of the change. The third I have not
responded to, although I investigated it. This is
https://bugzilla.mozilla.org/show_bug.cgi?id=412247. I want to avoid
creating a FEATURE flag if I can avoid it; I looked at the
SpiderMonkey sources and they look to be ECMA compliant so I don't
understand how Firefox behaves the way it does. I need to post to the
mozilla.dev.tech.js-engine group to see if I can get any enlightenment
there. I'll try to do so as soon as I can find time; today is a
holiday in the U.S.

HtmlUnit is an important client of Rhino. I'd like to keep you happy.

--Norris

Ahmed Ashour

unread,

Jan 22, 2008, 2:24:23 AM1/22/08

to dev-tech-js-...@lists.mozilla.org

Dear all,

Thanks all for your support, as we (in HtmlUnit) are continuously enhancing javascript, we arrive to many cases that must be handled at Rhino level.

As you know, our reference is the real browsers (FF/IE) even if it doesn't comply 100% to the specs, e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=370279.

Now, as Marc said, we are considering forking, as our dependencies (other projects or end users) don't care much about which version of Rhino is used, and it seems there is a general delay in fixing issues.

Please also note that we are willing to provide any help needed.

Below are our current issues:
https://bugzilla.mozilla.org/show_bug.cgi?id=370279
https://bugzilla.mozilla.org/show_bug.cgi?id=368019
https://bugzilla.mozilla.org/show_bug.cgi?id=412247
https://bugzilla.mozilla.org/show_bug.cgi?id=392593
https://bugzilla.mozilla.org/show_bug.cgi?id=369860
https://bugzilla.mozilla.org/show_bug.cgi?id=389278
https://bugzilla.mozilla.org/show_bug.cgi?id=390659
https://bugzilla.mozilla.org/show_bug.cgi?id=374918 (we have a workaround)

Thanks again, and please consider the cumulative dependencies behind the beast.

Yours,
Ahmed Ashour

____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Norris Boyd

unread,

Jan 29, 2008, 6:46:55 PM1/29/08

to

On Jan 22, 2:24 am, Ahmed Ashour <asash...@yahoo.com> wrote:
> Dear all,
>
> Thanks all for your support, as we (in HtmlUnit) are continuously enhancing javascript, we arrive to many cases that must be handled at Rhino level.
>

> As you know, our reference is the real browsers (FF/IE) even if it doesn't comply 100% to the specs, e.g.https://bugzilla.mozilla.org/show_bug.cgi?id=370279.

Thanks for your patience while I investigated these issues. Here's
some detail on them:

370279 "Bad property order in for in loop" - best approached by a Map
factory for ScriptableObject as has been discussed in 383592 - "Switch
to HashMap for ScriptableObject property storage" which I think is too
big a change to put in this release
368019, 369860, 389278 (various regexp issues) - best addressed by
390659 "Replace Rhino regexp implementation with java.util.regex to
improve performance", assuming that the regexp languages recognized by
Java and JavaScript are compatible (I haven't analyzed this).
412247: now implemented
392593: fixed
374918 - String primitive prototype wrongly resolved when used with
many top scopes. If this has a workaround can we leave things as-is?

So my proposal is that we wrap up 1.7R1 and then look at
implementation of 383592 and 390659. I'm willing to finish off 383592
but I'd need help with 390659.

How does that sound to you on HtmlUnit?

Marc Guillemot

unread,

Jan 30, 2008, 5:14:33 AM1/30/08

to

Norris Boyd wrote:
> ...

> Thanks for your patience while I investigated these issues. Here's
> some detail on them:
>
> 370279 "Bad property order in for in loop" - best approached by a Map
> factory for ScriptableObject as has been discussed in 383592 - "Switch
> to HashMap for ScriptableObject property storage" which I think is too
> big a change to put in this release

I'm a bit disappointed that you delay it but I can understand your concerns.

> 368019, 369860, 389278 (various regexp issues) - best addressed by
> 390659 "Replace Rhino regexp implementation with java.util.regex to
> improve performance", assuming that the regexp languages recognized by
> Java and JavaScript are compatible (I haven't analyzed this).

there are some differences between JS and Java Regex. I've started to
work on a patch to use Java Regex in Rhino but it's not yet mature (it
already passes many tests).

> 412247: now implemented
> 392593: fixed
> 374918 - String primitive prototype wrongly resolved when used with
> many top scopes. If this has a workaround can we leave things as-is?

we have a workaround meaning that this doesn't hurt us anymore.
Nevertheless this is still a bug ;-(

> So my proposal is that we wrap up 1.7R1 and then look at
> implementation of 383592 and 390659. I'm willing to finish off 383592
> but I'd need help with 390659.
>
> How does that sound to you on HtmlUnit?

release early, release often (even if we don't always apply it to ourself)

For us it would be better with 370279 fixed but if you prefer to apply
383592 first in 1.7R2 then I find it perfect if you release 1.7R1 today
and 1.7R2 tomorrow ;-)

We will probably use a custom fixed version of Rhino in HtmlUnit to
allow us to be able to take snapshots of Rhino as well as to apply and
use changes before they are accepted in Rhino. Our interest is that this
custom version becomes useless therefore this won't change anything in
our motivation to contribute to Rhino.

Cheers,