Re: Citeproc-CSL Library failure

2016-09-20 Thread Michel Krämer
Hi Matt,

I’m the maintainer of citeproc-java. As far as I can tell it’s an issue with 
citeproc-java and not Nashorn. I just need to update the library but haven’t 
found the time to do so yet. As a workaround you can add Rhino to your 
classpath. This should solve the problem for the time being.

I hope this helps.

Cheers,
Michel

> On 20 Sep 2016, at 05:16, Matthew Prichard  
> wrote:
> 
> Hi,
> 
> There is a issue migrating from Rhino to Nashorn. The library Citeproc-CSL 
> fails with Nashorn. It was suggested that I should send this list an email 
> inleiu of . I don't really know much about the problem, other than the same 
> code works fine on Rhino.
> 
> You can see a stacktrace, the source code, and a little discussion at 
> https://github.com/michel-kraemer/citeproc-java/issues/28
> 
> Thanks,
> 
> Matt
> 
> -- 
> *Matthew Prichard*
> matt...@matthewprichard.net



Citeproc-CSL Library failure

2016-09-20 Thread Matthew Prichard

Hi,

There is a issue migrating from Rhino to Nashorn. The library 
Citeproc-CSL fails with Nashorn. It was suggested that I should send 
this list an email inleiu of . I don't really know much about the 
problem, other than the same code works fine on Rhino.


You can see a stacktrace, the source code, and a little discussion at 
https://github.com/michel-kraemer/citeproc-java/issues/28


Thanks,

Matt

--
*Matthew Prichard*
matt...@matthewprichard.net


Re: RFR 8166298: 3 nashorn ant tests fail with latest jdk9-dev tip

2016-09-20 Thread Hannes Wallnöfer
+1

Hannes


> Am 20.09.2016 um 15:02 schrieb Michael Haupt :
> 
> Hi Sundar,
> 
> thumbs up.
> 
> Best,
> 
> Michael
> 
>> Am 20.09.2016 um 14:51 schrieb Sundararajan Athijegannathan 
>> :
>> 
>> Please review http://cr.openjdk.java.net/~sundar/8166298/webrev.01/ for
>> https://bugs.openjdk.java.net/browse/JDK-8166298
>> 
>> Thanks,
>> 
>> -Sundar
>> 
> 
> -- 
> 
> 
> Dr. Michael Haupt | Principal Member of Technical Staff
> Phone: +49 331 200 7277 | Fax: +49 331 200 7561
> Oracle Java Platform Group | LangTools Team | Nashorn
> Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, 
> Germany
> 
> ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
> München
> Registergericht: Amtsgericht München, HRA 95603
> 
> Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
> 3543 AS Utrecht, Niederlande
> Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
> Oracle is committed to developing 
> practices and products that help protect the environment
> 



Re: RFR 8166298: 3 nashorn ant tests fail with latest jdk9-dev tip

2016-09-20 Thread Michael Haupt
Hi Sundar,

thumbs up.

Best,

Michael

> Am 20.09.2016 um 14:51 schrieb Sundararajan Athijegannathan 
> :
> 
> Please review http://cr.openjdk.java.net/~sundar/8166298/webrev.01/ for
> https://bugs.openjdk.java.net/browse/JDK-8166298
> 
> Thanks,
> 
> -Sundar
> 

-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment



RFR 8166298: 3 nashorn ant tests fail with latest jdk9-dev tip

2016-09-20 Thread Sundararajan Athijegannathan
Please review http://cr.openjdk.java.net/~sundar/8166298/webrev.01/ for
https://bugs.openjdk.java.net/browse/JDK-8166298

Thanks,

-Sundar



Re: RFR 8166296:add documentation for Date,RegExp,Error,JSON objects

2016-09-20 Thread Sundararajan Athijegannathan
+1

-Sundar


On 9/19/2016 11:13 PM, Srinivas Dama wrote:
> Hello,
>
> Please review http://cr.openjdk.java.net/~sdama/8166296/webrev.00/  for 
> https://bugs.openjdk.java.net/browse/JDK-8166296 
>
> Regards,
> Srinivas



RE: RFR 8166296:add documentation for Date,RegExp,Error,JSON objects

2016-09-20 Thread Srinivas Dama
Hi Michael,
Thank you.

Here is the latest patch with all changes.
http://cr.openjdk.java.net/~sdama/8166296/webrev.01/

Regards,
Srinivas

-Original Message-
From: Michael Haupt 
Sent: Tuesday, September 20, 2016 12:56 PM
To: Nashorn-dev
Subject: Re: RFR 8166296:add documentation for Date,RegExp,Error,JSON objects

Hi Srini,

> Am 19.09.2016 um 19:43 schrieb Srinivas Dama :
> Please review http://cr.openjdk.java.net/~sdama/8166296/webrev.00/  
> for
> https://bugs.openjdk.java.net/browse/JDK-8166296

thumbs up, provided these changes are applied:

+Date.parse=returns a number, the UTC time value corresponding to the 
+date and time interpreted from given string argument, returns NAN if 
+the argument is unrecognisable string

... from the given string argument, returns NaN if the argument is not 
recognized

+Date.UTC=returns number of milliseconds in the given date object since 
+january 1,1970,00:00:00 universal time

returns the number ... since January 1, 1970, 00:00:00 universal time

(returns *the* number / string value / year ... - please apply in all other 
places) (month names are written in upper case, please apply in all other 
places) (spaces after commas, please apply in all other places)

+Date.prototype.toString=returns string value representing given date 
+object

... representing the given date object

+Date.prototype.toDateString=returns string value representing date 
+portion of the given date object

... representing the date portion ...

(also ... representing *the* time portion ... etc., please apply accordingly 
elsewhere)

+Date.prototype.valueOf=returns number of milliseconds between 1 january 
+1970 00:00:00 UTC and the given date

Please use a consistent date formatting. "1. January 1970" or "January 1, 1970" 
in all places.

+Date.prototype.getDay=returns the day of the week for the given date 
+according to local time, 0 represents sunday

Sunday (day names begin with upper case - please apply in all places)

+Date.prototype.getSeconds=returns the seconds in the given date, 
+according to locale time

Is it "local time" or "locale time"? (I think "local" is right.) Please be 
consistent in all places.

+Date.prototype.toUTCString=converts given date to a string using UTC 
+time zone

converts the given date ...


Best,

Michael


-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | 
LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 
| 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande Handelsregister der Handelskammer 
Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment



Re: RFR 8166296:add documentation for Date,RegExp,Error,JSON objects

2016-09-20 Thread Michael Haupt
Hi Srini,

> Am 19.09.2016 um 19:43 schrieb Srinivas Dama :
> Please review http://cr.openjdk.java.net/~sdama/8166296/webrev.00/  for 
> https://bugs.openjdk.java.net/browse/JDK-8166296 

thumbs up, provided these changes are applied:

+Date.parse=returns a number, the UTC time value corresponding to the date and 
time interpreted from given string argument, returns NAN if the argument is 
unrecognisable string

... from the given string argument, returns NaN if the argument is not 
recognized

+Date.UTC=returns number of milliseconds in the given date object since january 
1,1970,00:00:00 universal time

returns the number ... since January 1, 1970, 00:00:00 universal time

(returns *the* number / string value / year ... - please apply in all other 
places)
(month names are written in upper case, please apply in all other places)
(spaces after commas, please apply in all other places)

+Date.prototype.toString=returns string value representing given date object

... representing the given date object

+Date.prototype.toDateString=returns string value representing date portion of 
the given date object

... representing the date portion ...

(also ... representing *the* time portion ... etc., please apply accordingly 
elsewhere)

+Date.prototype.valueOf=returns number of milliseconds between 1 january 1970 
00:00:00 UTC and the given date

Please use a consistent date formatting. "1. January 1970" or "January 1, 1970" 
in all places.

+Date.prototype.getDay=returns the day of the week for the given date according 
to local time, 0 represents sunday

Sunday (day names begin with upper case - please apply in all places)

+Date.prototype.getSeconds=returns the seconds in the given date, according to 
locale time

Is it "local time" or "locale time"? (I think "local" is right.) Please be 
consistent in all places.

+Date.prototype.toUTCString=converts given date to a string using UTC time zone

converts the given date ...


Best,

Michael


-- 

 
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 
München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 
3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
  Oracle is committed to developing 
practices and products that help protect the environment