«

VK wrote:

> Dear Richard,

This is a public newsgroup, not private e-mail.

> FAQ 4.39 does exactly what I am fighting against: it assures that array
> and hash (associative array) are the nearly the same entities, so you
> just need to pay some extra attention to the syntacs. What I want to
> put in is the truth that these are two very different entities you have
> to deal very differently.

If so, you did that in a very poor way. Make it better next time.

> Also pls do not look at this as an attack onto JavaScript.

I doubt it was. Sorry, but the reply simply showed in detail your ongoing
cluelessness on the group's main topic.

> It was a BASIC of Internet,

Pardon? You want to read e.g. RFCs 1 to 100.

> so from the beginning it needed to express the most complicated things
> in the most simple way. It is not its fault that some of its advantages
> became limitations 10-15 years later.

First, JavaScript 1.0 is dated March 1996 as it was introduced with Netscape
Navigator 2.0 (JScript, and consequently ECMAScript emerged later); not
even 10 years have passed since then. Second, the features described do
NOT present limitations at all nor are they in any way simple (as already
shown). You really want to stop posting such FUD garbage here (unless you
are have now deliberately chosen to make a complete fool out of yourself).
Only because you are not able to handle it, it is by far not a Bad Thing,
especially when one takes the low level of expertise into account that you
presented here so far.


PointedEars

Lasse Reichstein Nielsen wrote:

> While I think I understand your point, comparing Javascript
> to a class based language is rarely productive.

While the statement applies only to JavaScript prior to v2.0,
JScript prior to v7.0/.NET and ECMAScript prior to ed. 4


SCNR

PointedEars

Thomas 'PointedEars' Lahn <> writes:

> While the statement applies only to JavaScript prior to v2.0,
> JScript prior to v7.0/.NET and ECMAScript prior to ed. 4

I have come to the point where I cannot tell whether I am deliberatly
ignoring this kludge on the side of Javascript or I have actually
managed to forget it. I guess it depends on what day it is

/L
--
Lasse Reichstein Nielsen -
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

Secently I noticed your pointed ears all around my postings. No to say
I was impressed too much by them (I mean postings). For example your
comments about <204 No Content> trick:
<http://groups-beta.google.com/group/comp.lang.javascript/browse_frm/thread/2cc6b164d27077eb/e3c81c8a05c002f4?q=204+No+Content&rnum=1#e3c81c8a0 5c002f4>
demonstrates that you must be never wrote a single line in Perl.

You want a shoot? I'll give you a shoot. This FAQENTRY material is
obsolete by now. Would you be intersted to discuss the new one:
<http://www.geocities.com/schools_ring/ArrayAndHash.html> (it has the
link on the related thread in this group).

VK wrote:

> Secently I noticed your pointed ears all around my postings. No to say
> I was impressed too much by them (I mean postings).

I am not surprised by that statement. You appear to be not impressed by
anything (not even a specification or reference written by the people who
created what you try to use) which is why you drop mostly gibberish
postings here.

> For example your comments about <204 No Content> trick:
>
<http://groups-beta.google.com/group/comp.lang.javascript/browse_frm/thread/2cc6b164d27077eb/e3c81c8a05c002f4?q=204+No+Content&rnum=1#e3c81c8a0 5c002f4>
> demonstrates that you must be never wrote a single line in Perl.

I had not much practice in that language, but I had not none.
My suggestion works:

| $ perl -v
|
| This is perl, v5.8.7 built for i386-linux-thread-multi
| [...]
| $ perl
| print "HTTP/1.0 204 No content\r\nx";
| [^D]
| HTTP/1.0 204 No content
| x

It should also work in a CGI script. What is your point?


PointedEars

> | $ perl -v
> |
> | This is perl, v5.8.7 built for i386-linux-thread-multi
> | [...]
> | $ perl
> | print "HTTP/1.0 204 No content\r\nx";
> | [^D]
> | HTTP/1.0 204 No content
> | x

#!/usr/bin/perl
# The above must be always the very first line
# otherwise 500 Internal Server Error

use strict;
# the -w flag (not -v : it stays from WarningsOn)
# is usable from command prompt only
# that is not a case for a CGI script
# use strict pragma does the same trick here

print "Status: 204 No content\n";

# Double new line indicates in HTTP the end
# of headers and start of document body (if any)
# So in this space I still can send *whatever I want*
# to the browser despites it stays on the current page
# if you bother to install Amaya, I'll show it to you.
# And you *never* use anything but new lines \n in Perl headers.
# It's not Windows or Mac, it's CGI transport
# over HTTP.

print "\n\n";
# end of transmission
exit(0);
# end of prog


It's not a Perl group, but just to make my point.
And yes, I like this group, because it has a lot of smart people in
here.
And no, I don't like W3 and ECMA too much and I don't believe that
every word they say is a truth in its last instance.

And actually W3 and ECMA *are not creators* of any kind of what we are
using. We are using stuff invented and developed by smart guys in
Switzerland and in the USA Netscape and Microsoft labs mainly and
mostly.

VK wrote:
> > | $ perl -v
> > |
> > | This is perl, v5.8.7 built for i386-linux-thread-multi
> > | [...]
> > | $ perl
> > | print "HTTP/1.0 204 No content\r\nx";
> > | [^D]
> > | HTTP/1.0 204 No content
> > | x
>
> #!/usr/bin/perl
> # The above must be always the very first line
> # otherwise 500 Internal Server Error
>
> use strict;
> # the -w flag (not -v : it stays from WarningsOn)
> # is usable from command prompt only
> # that is not a case for a CGI script
> # use strict pragma does the same trick here
>
> print "Status: 204 No content\n";
>
> # Double new line indicates in HTTP the end
> # of headers and start of document body (if any)
> # So in this space I still can send *whatever I want*
> # to the browser despites it stays on the current page
> # if you bother to install Amaya, I'll show it to you.
> # And you *never* use anything but new lines \n in Perl headers.
> # It's not Windows or Mac, it's CGI transport
> # over HTTP.
>
> print "\n\n";
> # end of transmission
> exit(0);
> # end of prog
>
>
> It's not a Perl group, but just to make my point.
> And yes, I like this group, because it has a lot of smart people in
> here.
> And no, I don't like W3 and ECMA too much and I don't believe that
> every word they say is a truth in its last instance.
>
> And actually W3 and ECMA *are not creators* of any kind of what we are
> using. We are using stuff invented and developed by smart guys in
> Switzerland and in the USA Netscape and Microsoft labs mainly and
> mostly.

With regard to HTTP, the specifications for the format of an HTTP
message are fairly universally implemented.

In the particular, the status line should be transmitted as:
HTTP/<major-version>.<minor-version><SP><status-code><SP><status-message><end-of-line>

Anything else is almost universally ineffectual, which is why it didn't
work for you. Doing Status: etc would have the effect of the server
providing its own status line and the client respecting it. The status
line provided by the server in this instance would almost certainly
have been
HTTP/1.<zero or one> 200 OK
Which would have defeated your attempt to send a 204 No Content.


Also:
<end-of-line> is CRLF, not LF, I'm pretty sure (please correct me if
I'm wrong).
As a PERL programmer, remember the oft-repeated addage: be strict in
what you provide; be tolerant in what you accept. Provide the CRLF
according to spec, but accept either \r, \n, or \r\n.

PERL-wise, use strict is not necessary in the script we're talking
about, but that's minor. Using it in this case results in unnecessary
overhead.

The shebang line (#!<path-to-perl-binary>) is not "always" necessary--
this is dependent upon the server config. For instance, in IIS (at
least up to 4.0), it is ineffectual. If your Apache is configured
accordingly, the shebang might also be ignored. To be sure, it's "best"
to include it for portability, but it is certainly not "always
necessary".

The script you've written above should have been written, simply:

#!/usr/bin/perl
print "HTTP/1.0 204 No content\r\n\r\n";

Effectually little different from that proposed by our pointed-eared
friend, except that the message header is terminated by <CRLF><CRLF>,
instead of just <CRLF>.

"Christopher J. Hahn" schrieb:

> The script you've written above should have been written, simply:
>
> #!/usr/bin/perl
> print "HTTP/1.0 204 No content\r\n\r\n";
>
> Effectually little different from that proposed by our pointed-eared
> friend,
^^^^^^
That would go to far, really.

> except that the message header is terminated by <CRLF><CRLF>,
> instead of just <CRLF>.

That is why I wrote "should contain at least" but VK again did not care
to read.


Regards,

PointedEars