jswoof version 1.04 has been released. providing more speed improvements. some
minor bug fixes and updated documentation.
as usual you can get the latest version from:
http://www.waynemike.co.uk/jswoof

Last month, I announced the web_send library on this list:
http://tech.groups.yahoo.com/group/json/message/1250

When hosted by your server, the web_send library turns your Firebug
console into a command line for your server-side application. The same
code can also be run by the Windows Script Host, a standard part of
all Windows releases since Windows 98. Doing so has two big
advantages:

     * no files need to be uploaded to your web server
     * you are not restricted by the Same Origin Policy

As a result, you have a command line for all JSON resources on the
Web. The world is at your fingertips!

This page explains how to use the JSON shell, with examples from
Google, Yahoo!, Twitter and Flickr.

Continue reading at:
http://waterken.sourceforge.net/web_send/wsh/

--Tyler

--
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

We have been having a heck of a time with an issue in IE8's implementation of
JSON.stringify(). It appears that IE8 *sometimes* encodes an empty string as the
string "null". If anyone has a clean work-around for this, or at least an
explanation I'd be really interested. Am I missing something?

Here is the repro:

var good = ""; // good === ""
var bad = document.createElement("input").value; // bad === ""

if (good === bad) {
	 // this is the path followed
	 alert("Strings: good === bad");
} else {
	 alert("Strings: good !== bad");
}

good = JSON.stringify(good); // good === '""' here
bad = JSON.stringify(bad); // bad === "null" here

if (good === bad) {
	 alert("JSON.stringify: good === bad");
} else {
	 // this is the path followed
	 alert("JSON.stringify: good !== bad");
}

IE may have a REFERENCE to the origianl object.

In your first example, when coerced into a string from th LEFT, they are
equivilant

The stringify method may convert t an OBJECT as null, since the element value is
not actually set.


--- In json@yahoogroups.com, "Stephen M. McKamey" <stephen@...> wrote:
>
> We have been having a heck of a time with an issue in IE8's implementation of
JSON.stringify(). It appears that IE8 *sometimes* encodes an empty string as the
string "null". If anyone has a clean work-around for this, or at least an
explanation I'd be really interested. Am I missing something?
>
> Here is the repro:
>
> var good = ""; // good === ""
> var bad = document.createElement("input").value; // bad === ""
>
> if (good === bad) {
>  // this is the path followed
>  alert("Strings: good === bad");
> } else {
>  alert("Strings: good !== bad");
> }
>
> good = JSON.stringify(good); // good === '""' here
> bad = JSON.stringify(bad); // bad === "null" here
>
> if (good === bad) {
>  alert("JSON.stringify: good === bad");
> } else {
>  // this is the path followed
>  alert("JSON.stringify: good !== bad");
> }
>

The triple-equals shouldn't be coercing the arguments before comparison. 
Reversing the order of the test to (bad === good) still results in true.  To top
that off, typeof returns "string" for both.

The other thing that is odd is that even if it were treating the value as a null
object, it should serialize as "null" but instead it actually serializes as the
escaped string '"null"'. There was a typo in the repro, it should have read:

    bad = JSON.stringify(bad); // bad === '"null"' here

What is scary about this, is that unless you fix it at the time of gathering the
data off the input element, you have no way of differentiating between a real
string and this bogus string which acts as if the user typed the word "null"
into the input.

--- In json@yahoogroups.com, "Stephen M. McKamey" <stephen@...> wrote:
>
> We have been having a heck of a time with an issue in IE8's implementation of
JSON.stringify(). It appears that IE8 *sometimes* encodes an empty string as the
string "null". If anyone has a clean work-around for this, or at least an
explanation I'd be really interested. Am I missing something?
>
> Here is the repro:
>
> var good = ""; // good === ""
> var bad = document.createElement("input").value; // bad === ""
>
> if (good === bad) {
>  // this is the path followed
>  alert("Strings: good === bad");
> } else {
>  alert("Strings: good !== bad");
> }
>
> good = JSON.stringify(good); // good === '""' here
> bad = JSON.stringify(bad); // bad === "null" here
>
> if (good === bad) {
>  alert("JSON.stringify: good === bad");
> } else {
>  // this is the path followed
>  alert("JSON.stringify: good !== bad");
> }

Below is the answer from Microsoft about this bug in JSON.stringify.  Thanks
Douglas Crockford for forwarding on to the appropriate contact at Microsoft.

It appears the short answer is that you have to test for empty strings coming
off DOM elements and replace with a real empty string.  That can be done via the
replacer function or at the time of retrieving the value.

---------- Forwarded message ----------
From: Allen Wirfs-Brock
Date: Tue, Jun 2, 2009 at 08:15
Subject: RE: [Fwd: [json] IE8 Native JSON Bug]


This is a  bug in the initial production version of IE8 that we were already
aware of.  The problem is that within the DOM a special encoding is used to
represent a missing string value.  Even though this special value is different
from the encoding of the JavaScript literal "", throughout the JScript
implementation the value is treated as being === to "" ... except for one
oversight in JSON.stringify.

Since this special value only originates from accesses to DOM objects one
workaround is to explicitly censor them on every DOM access that might return
one.  For example,
   var good, possiblyBad = good =document.createElement("input").value;
   if (possiblyBad === "") good = ""; //ensure possibly bogus "" is replaced with
a real ""
In particular, this should be done when accessing the value of an input element
if that value is going to be assigned to a structure that will be passed through
stringify.

Since the difference is only observable via stringify, another alternative is to
use the replacer function to perform the substitution:
   JSON.stringify(document.createElement("input").value,
                  function(k,v) { return v==="" ? "" : v});
   //the above will return "", not "null"

A post describing this problem and the workaround should appear on the JScript
blog (http://blogs.msdn.com/jscript/ ) sometime this week.

Allen

jswoof version 1.05 has been released. This version contains
a small fix for escaped uni-code characters during serialization.
please check out http://www.waynemike.co.uk/jswoof for more details.

--- In json@yahoogroups.com, "W" <wayne.ivor@...> wrote:
>
> jswoof version 1.04 has been released. providing more speed improvements. some
minor bug fixes and updated documentation.
> as usual you can get the latest version from:
> http://www.waynemike.co.uk/jswoof
>

Allen Wirfs-Brock suggested another work-around to the IE8 native JSON issue:

Another work-around that is isolated to a single place is to use IE8's "mutable
DOM prototypes" support to patch HTMLInputElement.prototype.value so that the
bogus "" value is filtered out.  For example:

...

(function() {

         var builtInInputValue =
Object.getOwnPropertyDescriptor(HTMLInputElement.prototype, "value").get;

         Object.defineProperty(HTMLInputElement.prototype, "value",

          { get: function() {

              var possiblyBad = builtInInputValue.call(this);

              return possiblyBad === "" ? "" : possiblyBad;

          }

          });

       })();

...

A patch like this could be conditionally executed as part of the initialization
code of a framework.

<!-- this is the javascript json parser function -->

     <script type="text/javascript" src="../jquery-1.2.6.min.js">
     </script>

     <script type="text/javascript">

     $(document).ready(function()
      {
        	 $('form#search').bind("submit", function(e)
		 {
            		 e.preventDefault();
            		 $('#content').html('');

            		 var query1 = urlencode($('input[name="user_a"]').val()); //userA
                         var query2 = urlencode($('input[name="user_b"]').val());
//userB


            		
$.ajax('http://twitter.com/friendships/exists.json?user_a='+query1+'&user_b='+qu\
ery2,
                         function(data,textdata)
			 {


                                   if(data == 'true')
                                     {
                     	               var newDiv = '<p>true</p>';
				     }

                    	      $('#content').append(newDiv);

                                 }, 'text');
                         });
                 })

           function urlencode(str) {
             return escape(str).replace(/\+/g,'%2B').replace(/%20/g,
'+').replace(/\*/g, '%2A').replace(/\//g, '%2F').replace(/@/g, '%40');
           }
     })

     </script>

<!-- javascript ends here -->

this functions will GET the json response from twitter which is true or false
after checking will append new div to the body....

problem is tht it doesnt seem to be working n i cant find the error...plzz
help...

--- In json@yahoogroups.com, "JIJO DASGUPTA (ANAND)"
> problem is tht it doesnt seem to be working n i cant find the error...plzz
help...

Your question is out of scope for this group. Ask the jQuery people.

jswoof version 1.06 has been released. containing a major speed
improvement to the array parsing functions.
As usual please check out http://www.waynemike.co.uk/jswoof for
more details.

--- In json@yahoogroups.com, "W" <wayne.ivor@...> wrote:
>
> jswoof version 1.05 has been released. This version contains
> a small fix for escaped uni-code characters during serialization.
> please check out http://www.waynemike.co.uk/jswoof for more details.
>
> --- In json@yahoogroups.com, "W" <wayne.ivor@> wrote:
> >
> > jswoof version 1.04 has been released. providing more speed improvements.
some minor bug fixes and updated documentation.
> > as usual you can get the latest version from:
> > http://www.waynemike.co.uk/jswoof
> >
>

has now been released. containing a small fix for object ordering. as usual
jswoof and all its documentation can be found at:
http://www.waynemike.co.uk/jswoof

Wayne IV Mike,

Just wanted to let you all know yajl-ruby 0.5.5 was released to github's gem
server and I'll be pushing a release to rubyforge soon as well.

This is an important release mostly because of the introduction of it's JSON gem
compatibility API. But also because I did some more investigating into the speed
of yajl-ruby compared to the JSON gem, YAML and Marshal.load/Marshal.dump

A summary of yajl-ruby's features to-date:

JSON parsing and encoding directly to and from an IO stream (file, socket, etc)
or String. Compressed stream parsing and encoding supported for Bzip2, Gzip and
Deflate.
Parse and encode multiple JSON objects to and from streams or strings
continuously.
JSON gem compatibility API - allows yajl-ruby to be used as a drop-in
replacement for the JSON gem
Basic HTTP client (only GET requests supported for now) which parses JSON
directly off the response body *as it's being received*

Also, it's:
~3.5x faster than JSON.generate
~1.9x faster than JSON.parse
~4.5x faster than YAML.load
~377.5x faster than YAML.dump
~1.5x faster than Marshal.load
~2x faster than Marshal.dump

Anyone wanting faster JSON parsing and encoding in their project should
definitely take a look at this release. Enjoy!

I had always assumed that new Date(NaN) in JavaScript would throw an exception.
I found out today that produces a toxic date object, and that different
implementations of JSON.stringify([new Date()]) do different things.

json2.js
     ["NaN-NaN-NaNTNaN:NaN:NaNZ"]

IE8
     ["--T::Z"]

FireFox
     ["Invalid Date"]


We will be correcting the ES5 standard to emit null in this case.
The 2009-06-18 edition of json2.js contains the change.

     [null]

Thanks to Joel Finch for the heads up.

Just to clarify this…

”new Date()” normally produces a perfectly ok Date object representing the
current date and time. Does your change to ES5 mean that “JSON.stringify([ <any
date object> ])” will produce “[null]”? And if not, why should it refuse to
stringify the current date and time in this manner when other dates and times
give meaningful results?

/Jakob


Fra: json@yahoogroups.com [mailto:json@yahoogroups.com] På vegne af Douglas
Crockford
Sendt: 18. juni 2009 18:43
Til: json@yahoogroups.com
Emne: [json] new Date(NaN)

I had always assumed that new Date(NaN) in JavaScript would throw an exception.
I found out today that produces a toxic date object, and that different
implementations of JSON.stringify([new Date()]) do different things.

json2.js
["NaN-NaN-NaNTNaN:NaN:NaNZ"]

IE8
["--T::Z"]

FireFox
["Invalid Date"]

We will be correcting the ES5 standard to emit null in this case.
The 2009-06-18 edition of json2.js contains the change.

[null]

Thanks to Joel Finch for the heads up.

[Non-text portions of this message have been removed]

--- In json@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:
> "new Date()" normally produces a perfectly ok Date object representing the
current date and time. Does your change to ES5 mean that "JSON.stringify([ <any
date object> ])" will produce "[null]"? And if not, why should it refuse to
stringify the current date and time in this manner when other dates and times
give meaningful results?


I meant exactly what I said. This only concerns new Date(NaN).

Then apparently you didn’t say what you meant. No offense, that was what I
needed to clarify.

“…that different implementations of JSON.stringify([new Date()]) do different
things.”

/Jakob


Fra: json@yahoogroups.com [mailto:json@yahoogroups.com] På vegne af Douglas
Crockford
Sendt: 18. juni 2009 19:52
Til: json@yahoogroups.com
Emne: Re: SV: [json] new Date(NaN)





--- In json@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:
> "new Date()" normally produces a perfectly ok Date object representing the
current date and time. Does your change to ES5 mean that "JSON.stringify([ <any
date object> ])" will produce "[null]"? And if not, why should it refuse to
stringify the current date and time in this manner when other dates and times
give meaningful results?

I meant exactly what I said. This only concerns new Date(NaN).


[Non-text portions of this message have been removed]

It might be worth noting that the Date constructor or Date.parse() fed an
incorrectly formatted date string also gives a NaN-valued Date object, which is
the more common cause.


--- In json@yahoogroups.com, "Jakob Kruse" <kruse@...> wrote:
>
> Then apparently you didn't say what you meant. No offense, that was what I
needed to clarify.
>
> "…that different implementations of JSON.stringify([new Date()]) do different
things."
>
> /Jakob
>
>
> Fra: json@yahoogroups.com [mailto:json@yahoogroups.com] På vegne af Douglas
Crockford
> Sendt: 18. juni 2009 19:52
> Til: json@yahoogroups.com
> Emne: Re: SV: [json] new Date(NaN)
>
>
>
>
>
> --- In json@yahoogroups.com, "Jakob Kruse" <kruse@> wrote:
> > "new Date()" normally produces a perfectly ok Date object representing the
current date and time. Does your change to ES5 mean that "JSON.stringify([ <any
date object> ])" will produce "[null]"? And if not, why should it refuse to
stringify the current date and time in this manner when other dates and times
give meaningful results?
>
> I meant exactly what I said. This only concerns new Date(NaN).
>
>
> [Non-text portions of this message have been removed]
>

I just ran the updated json2.js (2009-06-18) through my unit tests, and the
valueOf() solution to the NaN Date issue fails for the epoch date (0 ticks ==
false).

Code: JSON.parse("\"T\\wo\"");

In Firefox 3.5 and the latest json2.js from json.org this results in a parse
exception SyntaxError.

Expected: Two

It works in:
* The json2.js from json.org from 1-17-2008
* GWT 1.6's JSON parsing
* The window.eval snippet from http://www.ietf.org/rfc/rfc4627.txt?number=4627

Web page to reproduce in Firefox 3.5:
http://www.telparia.com/json_backslash_bug_ff35.html

I filed a bug about it: https://bugzilla.mozilla.org/show_bug.cgi?id=501156

kbrosnan from #firefox on IRC wanted me to post a message hear about it to find
out if it's a bug or by design.

So it works in some JSON parsers, just not the latest json.org and Firefox 3.5
ones. Is it bad syntax?

--- In json@yahoogroups.com, "cosmicrealms" <robert@...> wrote:
>
> Code: JSON.parse("\"T\\wo\"");
>
> In Firefox 3.5 and the latest json2.js from json.org this results in a parse
exception SyntaxError.
>
> Expected: Two

\w is not present in the JSON grammar. An implementation may produce a syntax
error. The behavior of Firefox 3.5 is correct.

--- In json@yahoogroups.com, "joel.finch@..." <joel@...> wrote:
>
> I just ran the updated json2.js (2009-06-18) through my unit tests, and the
valueOf() solution to the NaN Date issue fails for the epoch date (0 ticks ==
false).

Fix. Thanks.

cosmicrealms scripsit:
> Code: JSON.parse("\"T\\wo\"");
>
> In Firefox 3.5 and the latest json2.js from json.org this results in
> a parse exception SyntaxError.

The interpretation of string escaping means that "\"T\\wo\"" is the
external representation of a six-character string containing quote-T-
backslash-w-o-quote.  Asking JSON to parse that involves asking it
to do something with the sequence backslash-w, which is not valid JSON.
Therefore an error should result.

--
Values of beeta will give rise to dom!          John Cowan
(5th/6th edition 'mv' said this if you tried    http://www.ccil.org/~cowan
to rename '.' or '..' entries; see              cowan@...
http://cm.bell-labs.com/cm/cs/who/dmr/odd.html)

Maybe this stuff could be interesting for json2.js file as well, or maybe
not.
It is a quick and full specs ISO strings parser, really fast, widely
compatible, unobtrusive, since Date.prototype is not touched (it could be
touched if everybody agrees about it)
http://webreflection.blogspot.com/2009/07/ecmascript-iso-date-for-every-browser.\
html

Regards


[Non-text portions of this message have been removed]

Personally, I think this would have to extend the Date prototype to be fully
useful; like json2.js, its value is in allowing us to write script now using the
correct future syntax of ECMAScript 5.

Incidentally, your toISOString function doesn't have handling for the NaN case.


--- In json@yahoogroups.com, Andrea Giammarchi <andrea.giammarchi@...> wrote:
>
> Maybe this stuff could be interesting for json2.js file as well, or maybe
> not.
> It is a quick and full specs ISO strings parser, really fast, widely
> compatible, unobtrusive, since Date.prototype is not touched (it could be
> touched if everybody agrees about it)
>
http://webreflection.blogspot.com/2009/07/ecmascript-iso-date-for-every-browser.\
html
>
> Regards
>
>
> [Non-text portions of this message have been removed]
>

I noticed in the latest ECMAScript 5 spec that Date's toJSON is defined to
return the same string as Date's toISOString. (as of:
candidate-draft-tc39-2009-025_errata-5-19)

Does this mean that toISOString should now be defined to return "null" for NaN
dates, or that the strict 1:1 correspondence between toISOString and toJSON
should be relaxed?

I'm sorry to keep raising the issue of NaN dates, it's truly not all I think
about, I just don't want to head into our bold new scriptalicious future with
wiggle room for implementors.

The NaN case should be a constructor problem, no? To extend
Date.prototype.toISOString = Date.ISO("2000").toISOString;

On Jul 6, 2009 1:41 AM, "joel.finch@..." <joel@...> wrote:



Personally, I think this would have to extend the Date prototype to be fully
useful; like json2.js, its value is in allowing us to write script now using
the correct future syntax of ECMAScript 5.

Incidentally, your toISOString function doesn't have handling for the NaN
case.

--- In json@yahoogroups.com, Andrea Giammarchi <andrea.giammarchi@...>
wrote: > > Maybe this stuff...
> [Non-text portions of this message have been removed]
>




[Non-text portions of this message have been removed]

Shouldn't new Date(NaN) refer to a future date that is always just around
the corner, yet never arrives?
sorry... couldn't resist :)

On Mon, Jul 6, 2009 at 2:51 AM, Andrea Giammarchi <
andrea.giammarchi@...> wrote:

>
>
> The NaN case should be a constructor problem, no? To extend
> Date.prototype.toISOString = Date.ISO("2000").toISOString;
>
>
> On Jul 6, 2009 1:41 AM, "joel.finch@... <joel.finch%40ymail.com>" <
> joel@... <joel%402am.com.au>> wrote:
>
> Personally, I think this would have to extend the Date prototype to be
> fully
> useful; like json2.js, its value is in allowing us to write script now
> using
> the correct future syntax of ECMAScript 5.
>
> Incidentally, your toISOString function doesn't have handling for the NaN
> case.
>
> --- In json@yahoogroups.com <json%40yahoogroups.com>, Andrea Giammarchi
> <andrea.giammarchi@...>
> wrote: > > Maybe this stuff...
> > [Non-text portions of this message have been removed]
> >
>
> [Non-text portions of this message have been removed]
>
>
>


[Non-text portions of this message have been removed]

Uhm, I think new Date(NaN) should return a static historical date, new
Date(Number.POSITIVE_INFINITY) 9999-12-31T23:59:59:999 and
Number.NEGATIVE_INFINITY 0001-01-01T00:00:00.001 :D

Jokes a part, if interested, I have implemented a full(?) ECMAScript Date
constructor in vice-versa, but since vice-versa is based on stand-alone
modules/files, here I am with the code:

http://vice-versa.googlecode.com/svn/trunk/src/Date.js

toISOString is a prototype, and new Date accept ISO 8601 strings.

Regards

On Thu, Jul 9, 2009 at 8:14 PM, Arthur Blake <arthur.blake@...> wrote:

>
>
> Shouldn't new Date(NaN) refer to a future date that is always just around
> the corner, yet never arrives?
> sorry... couldn't resist :)
>


[Non-text portions of this message have been removed]

For YUI's JSON utility, I'm leveraging native behavior if present and stable. 
To that second point, I adapted the test suite for YUI's JSON util to test the
native API for potential bugs (which there have been with every implementation
to date).

I created a GitHub project to share the native testing and hopefully get some
feedback or additional tests.

http://github.com/lsmith/JSON-test-suite/tree/master

Here's a direct link to a working copy.
http://lucassmith.name/pub/JSON-test-suite/test.html

Cheers,
Luke