Posted by Richard Cornford on 07/02/05 23:20

Onideus Mad Hatter wrote:
> Richard Cornford wrote:
>>> ...um, what the fuck does hyper text transfer protocol have
>>> to do with...ANYTHING AT ALL that we've been talkin about?
>
>>If my browser didn't cache that image (and it didn't) then
>>who did,
>
> ...why do you keep referring to inanimate objects like
> they're people?

It is reasonable in context. Someone is operating that cache, out of
choice.

> ...and why did you just contradict yourself?

Within that one sentence? I don't see that I did.

Or are you letting the fact that you only think you understand this
subject let you misinterpret what I am saying into something suited to
you limited conception?

> ...and why are you blathering on about HTTP headers

I am not talking about HTTP headers at all here. HTTP is a lot more than
just headers.

> when in that other post you were yammering on about
> how you hated my date stamp method...

Yes I was. You want to get caching working for you instead of against
you. Date stamps in query strings will not do that.

> I mean, DO YOU know how HTTP headers work?

And if I explained them to you could you tell if I was right, without
reference to RFC 2616? I won't bother because I already know the answer
to that.

<snip>
>>Ah, but I know how to do the basic prevention with scalable
>>CSS so I don't need scripts anywhere for the fall-back for
>>the javascript disabled/incapable.
>
> ...you fuckin idiot...scalable CSS...oh yeah, brilliant that:
> http://www.backwater-productions.net/_test_platform/shapes2.html
>
> Gotta love those jagged edges!

You don't think that well for someone who claims to have imagination.
Try scaling down instead of up.

> Yeesh, do you even KNOW what this fuckin thread is about?

So far it has been about a series of poor implementations of a bad idea.

> I mean, has it occurred to idiot you AT ALL why the
> JavaScript and PHP is necessary?

Necessary to get the full effect, not necessary to get workable results
for the javascript disabled/incapable.

The real point of the scalable CSS is that would allow the result to be
more dynamically fluid without detracting from the scripted end result,
and indeed contributing to the efficiency of that end result. That a
consequence would be that the users of script incapable browser would
get something instead of just a blank screen is merely a happy side
effect.

<snip>
> And again MORON, you miss the entire fuckin point of the whole gawd
> damn design. Here it is again, just for the benefit of your idiocy:
>
> JavaScript - document.body.clientWidth
> PHP - imagecopyresampled()
>
> FIGURE IT OUT, ya fuckin retard!
>
> Free cl00, without those things, THE WHOLE CONCEPT DOESN'T WORK.

As implemented it barely works with them, but it still doesn't have to
fail utterly without them.

<snip>
>>But I have other reasons for wanting that non-blank screen.
>
> Yeah your obsession with search engines, how could we forget.

My obsession with search engines? I haven't even mentioned search
engines.

<snip>
>>> That's actually on the browsers end of things and I
>>> already fixed teh problem.
>
>>Do you really think that fixed the problem? All you really
>>did was move the problem somewhere else.
>
> No it really did fix the problem actually.
> Granted I've since decided to use the client
> width instead of the a date/time stamp,

So you are saying that you had a perfectly effective solution (that we
both know was really no such thing) and for no reason what so ever you
changed it for an alternative that you assert has no advantages, and
even some disadvantages? Who are you trying to kid? Your arrogance might
prevent you form admitting it in public but you have adopted that change
because when I spelled it out to you in sufficiently simple terms that
you could actually understand you had no choice but see that I have been
right all along.

And every time I lay a suggestion out for you on a plate you will find
yourself greedily snuffling it up, because, bottom line, you know that I
understand this stuff sufficiently to implement it well, and you were
pushing the limits of your ability when you announced that you were at
the "cutting edge".

You may, for example, question my interest in scalable CSS in this
context, but if I bothered to explain the mechanism of my vision you
would have had a go at implementing it in your code before the day was
out. You cannot even conceive of a reason to be interested in CSS in
this context, so you will never work it out for yourself.

<snip>
>>And there I was expecting you to use the HTTP headers to influence
>>caching behaviour, like anyone who knows what they are doing. But
>>then you don't do you? So it is a javascript hack for you.
>
> A JavaScript hack, eh? *snicker*
> Actually doing what I did with JavaScript is not much
> different from modifying HTTP headers except you have more
> control in that you can precisely cache individual elements.

Keep making it up on the spot, we wouldn't want to leave anyone in any
doubt that you don't know what your are talking about.

> With HTTP headers it's pretty much all or nothing. Again
> though, you show off your incredible LACK of knowledge
> in JavaScript.

?

>>> See that first thing up there, that says "starttime"
>>> that's a V..A..R..I..A..B..L..E..
>
>>It is a named property of the global object. ...
<snip>
> ...wow, yer like a gawd damn Jesus killing encyclopedia
> of bullshit...

You want to spell out the wrong term, and then get upset when you are
corrected?

You realise that it is the fact that you don't know the correct
terminology that made it obvious to me that your understanding of
javascript is barley superficial.

> too bad you lack imagination and creativity,

And imagination and creativity make such a useful substitute for
technical understanding; you get to make it all up off the top of your
head and then bullshit everyone that you are some sort of expert.

> really at this point you're about as useful
> as a reference manual.

At this point you have more need of reference manuals than anyone else I
can think of.

>>A competent programmer would use a local variable in this
>>context and that certainly would be a variable, but your
>>code is devoid of local variables so not in this case.
>
> Actually starttime would need to be a global variable
> sunshine,

You think you can teach me anything about programming? Nothing in
javascript needs to be a global variable.

> since its going to be used no matter what
> and not by any specific function.

You are building unique URLs with it, you will want a distinct value for
each session of re-loading, and preferable a unique value for each
individual URL, as that will further reduce the influence of intervening
caches on the network. that would be best implemented without a global
variable.

<snip>
>> Yes (assuming consecutive requests do not happen within
>> a period shorter than the precision of the time value),
>> every request will have to be satisfied by the site's
>> server(s).
<snip>
>>A very bad idea under the circumstances.
>
> Weren't you the doofy screwball who was supporting the
> idea of HTTP headers?

The ides of HTTP headers is not something that can be supported. Maybe
the idea of using appropriate HTTP headers, but you won't find many who
don't support that (and least of those who know what HTTP is about).

> How is that any different, ya fuckin idiot!

HTTP headers are the right way of influencing caching. They may
encourage it or discourage it, and they may influence for how long a
cached resource is used before being refreshed. If you want to
discourage caching then they are the right way of doing that, as opposed
to the javascript hack. If you want to encourage caching (which you
certainly do in this case, under the right circumstances) then they are
the right way of doing that also.

>>But it doesn't solve the problem with intervening caches because two
>>individuals accessing the site at approximately the same time might
>>still send identical URLs, and the second get images scaled for the
>>first.
>
> ...right...and by some magic coincidence they would both
> be accessing it at exactly the same millisecond on exactly
> the same ISP with different resolutions?

The same apparent time (given the low resolution of the time data and
the fact that client clocks are rarely correct), different real times,
with different browser window sizes, and the ISP is pretty irrelevant.

The point of being precise about what value is really returned from (new
Date).getTime() is that in reality the coincidence doesn't have to be
anywhere near as close as the exact millisecond. Unfortunately you read
it but failed to understand it.

> Highly doubtful, Cupcake.

Unlikely but not impossible. While the optimum solution 100% eliminates
the issue (which is what made it the optimum solution).

> I think you'd have a better chance of standing out on a sunny
> day and getting struck by lighting twice in a row.

Your maths are not up to much, but then you failed to recognise the
nature of the value being used. But what do the odds of failure matter
when the risk can be eliminated entirely by making the correct design
decision at an early stage. Granted that decision cannot be made without
understanding the issues, and the code that will be employed in the
implementation.

>>> WOAH, boy that was sure complicated, .rotard,
>
>>Slightly more complex that your simplistic understanding has it.
>
> You make things complicated when they don't need to be...

I make them no more complicated than they are, and no less.

> which btw leads to mistakes, errors, fuckups, etc.

Over simplifications are also error prone.

> It is interesting to see you switch gears though to try
> and save face. At first you were claiming that I had no
> understanding at all of what I was doing and now you're
> trying to overcompensate by repeating everything I'm
> saying but in the most technobabbled jargon filled way
> possible.

It may e technobabble to you, it is the language of the specification
for javascript. The terminology that precisely fits the conceptual units
in which javascript operates. The terminology in which javascript
experts talk about the language. So it is no surprise to me that you
have no comprehension of it.

> You're not saying anything different, you're just
> saying it in a way that breeds mistakes.

Talking about, and conceiving javascript, in the exact terms in which it
is defined does not lead to mistakes. Trying to use the terminology
without understanding it (or any home-grown alternative) is very likely
to lead to them.

> It's like if I say:
>
> "Go to the store and buy some milk."
>
> And you say:
>
> "Travel to the place at which things are available for purchase and
> perform a transaction of monetary basis in order to acquire a
> container of bovine produced lactose."
>
> Are you a lawyer or a programmer?

Am I ginning instructions to a human or a computer? Try writing "tack
the current time on the end of the file name" in your javascript source
and see how far that gets you. Computers need to be given well chosen,
precise, instructions, because they will carry them out blindly. If you
don't know what an instruction is supposed to do, precisely, how could
you tell what the computer is going to do when carrying it out.

<snip>
> I do find your aversion to variables amusing,

What aversion to variables? Are you hallucinating again?

<snip>
>>> ... it HAS to reload them...you fuckin MORON!
>
>>It might have to re-load the images to display properly re-scaled
>>images but it doesn't have to re-load, re-parse, re-error-correct
>>and re-render the pseudo-XHTML tag soup and it doesn't have to
>>re-load, re-interpret and re-initialise the script.
>
> All of that is pretty much instantaneous compared to the image
> content, Junior. You're arguing about a drop in the bucket.

And the inevitable screen flicker as contents start to re-load? Hence
the CSS, but you don't see that so never mind.

<snip>
>>That is an irrelevant nonsense. I was observing that
>>your original code has an onresize handler that re-loads
>>the page whenever a resize event happens. Which mans much
>>more re-loading than is necessary.
>
> That is irrelevant nonsense, who in their right mind would
> randomly resize the page every 3 seconds?

Who said anything about randomly re-sizing the browser every 3 seconds?
I am talking about one act of re-sizing a browser resulting in many
resize events, and you trying to re-load the page at each one. Perhaps
you have never observed that phenomenon.

<snip>
>>We are actually talking about the difference between knowing what the
>>code you wire will do, and just thinking that you know what it will
>>do.
>
> Well I hate to break it to ya, Cupcake, but code isn't that
> black and white.

Tell that to the computer, they see it as binary digits, which is about
as black and white as things get.

> Granted at it's core it's one's and zero's...

Exactly.

> but when you're dealing with millions of them, well that
> certainly introduces a bit of variability.

No it doesn't. Computers use relentless mechanical logic in a completely
deterministic way. Variability is only in the mind of the observer, and
more so in the mind of the ill-informed observer.

> Programming is NOT an exact science,

It may not be a science but exact is precisely what it is.

> there IS NO WAY of knowing precisely how something
> will function in all circumstances and to even claim
> something as fucking retarded as that just makes you
> look like that much more of an idiot.

Computers are completely deterministic by definition.

> If your logic was correct we wouldn't have bug fixes,
> we wouldn't have security holes, there would
> be no viruses, no firmware updates, no patches, etc, etc, etc.

Errors certainly are made, but who is going to be making the most
errors? The programmer who knows precisely what each line they write
will do, or the programmer who assumes they know but doesn't really?

<snip>
>>>>and even remove the need for the server to flog
>>>>its guts out and so allow the process to scale
>>>>to a commercial level of web site usage.
>
>>> ...actually you really couldn't.
>
>>Actually I really could. Indeed with the cost of hard disks
>>falling as their size rockets there is no way I would even
>>consider designing a system that attempted to re-scale images
>>live for every single request.
>
> I think you're confusing processing power and memory with
> hard drive space, Kiddo.

Do your really think I would?

> Really nothing would be written to the drive at
> all...

In your implementation that is true. I, on the other hand, would store
each distinct image size to disk as it was first requested/created and
then serve subsequent requests for the same image from the disk,
eliminating the need for the server to flog its guts out re-creating an
essentially identical image. It might take a lot of disk space to store
the results but disks are cheep these days and the result would be more
responsive that 100% live image generation.

>well unless maybe you had a serious memory deficiency on yer
> system.

Memory doesn't come into it.

>>> I take back what I said earlier, if you incorporated
>>> everything into a single PHP file you would actually
>>> only be putting MORE STRAIN on the server as far as
>>> processing.
>
>>Yes, I told you it was a nonsense.
>
> ...um, you were the one who originally proposed it,
> you fuckin MORON!

I have not once suggested incorporating everything into a single PHP
file.

<snip>
>>>>Now a real expert at javascript looks at that expression and sees
>>>>the AdditiveExpression forming a single argument to a built-in
>>>>function call. They know the implications of the AdditiveExpression
>>>>and they know the behaviour of the built in function being called.
>>>>And as a result they would _never_ write this expression.
>
>>> The horrible implications of additive expressions, my Gawd, it's
>>> ADDITION!!!
>
>>Or concatenation, depending on the type of the operands.
>
> eval(logot+logoc)
>
> Hrmmm...nope, I don't see any dollar signs,

Why would you be expecting to see dollar signs, or attributing meaning
to them? In javascript dollar sighs are allowed in Identifiers, and are
one of the set of characters that may start the Identifier.

> kiddo, pretty sure that

Pretty sure?

> means they're INTEGERS

Right, so you're "pretty sure" that in javascript the absence of any
dollar signs means integers?

Well javascript has no integer data type, it only has one numeric type
and that is an IEEE double precision floating point number. So an
Identifier (that may or may not feature a dollar sign independently of
its type at any time) that refers to a numeric value is just a number,
and may be an integer if that value is an integer, but not in the sense
of being an example of an integer type.

>...say it with me INTEGERS.

It is a number.

>>It isn't possible to avoid AdditiveExpressions in javascript.
>
> ...then what the fuck are you bitchin about it for? Are ya stupid
> Richie, is that it? Got hammered the fuck into the wall one too many
> times?
>
>>The factor
>>that needs to be considered is the type of the operands, and so
>>whether
>>the result of the expression is a number or a string. In your case the
>>operands have to both be numbers so the operation is addition and the
>>result is a number. If either of the operands were a string then the
>>outcome of the statement in which expression features would be off by
>>multiple orders of magnitude.
>
> ...well, actually it's adding two integers and then
> converting them into a string...

You are saying that the expression:-

eval(logot+logoc)

- adds two numbers and then type-converts the result into a string?
Addition it does do, and then the useless eval call. there is no
type-conversion to a string in that expression.

> kinda necessary since last I checked valid CSS
> required the lil "px" on the end of all the size and location
> values...

Strictly CSS requires a type of unit to be specified on all non-zero
length/dimension values. As the expression in question forms the left
hand operand of another AdditiveExpression with the string "px" as its
other operand, the evaluation of that AdditiveExpression does
type-convert the numeric result of - eval(logot+logoc) - into a string,
and perform concatenation. But that evaluation is outside of the
expression in question, and does not happen until after the first
expression is fully evaluated.

> which is the whole reason I'm using the eval()
> function in the first place...

So when you said that you were using eval to "fuck around with multiple
variables whilst assigning them to cut down on extraneous code" you
weren't telling the truth? Well, I knew you were making it up off the
top of your head because you had no conception of why you were making a
useless eval call, but it is nice that you feel able to confirm that.

On the other hand this new justification seems to have as little
grounding in an understanding of javascript as was evident in the first.
The concatenation of 'px' happens after the eval call returns, the
addition of the numbers happens before the call to eval, and the eval
call just returns the number that resulted from the addition. The
nothing that the eval call does is no less nothing in the wider context
of the string concatenation as it was nothing in the context of the
addition.

> and again I point that you're bitching about
> something that doesn't even fucking matter.

When someone claims expertise in javascript, as you have, it is not
unreasonable to suspect deception of delusion when they demonstrate zero
comprehension of the behaviour of the code that they write themselves.

>>> Apparently this programming crisis in only known in the
>>> world of Richard Stupid.
>
>>Did I say that an AdditiveExpression would not feature in the
>>expression a competent javascript programmer would write?
>
> Well, yes, as a matter of fact you did. You said, "And as a result
> they would _never_ write this expression"...

I wrote that a real expert at javascript knows the implications of the
AdditiveExpression and the behaviour of the eval function. And as a
result they would _never_ write that expression.

That does not propose that the AdditiveExpression is misguided, but that
it is the whole expression that would not be written. And I have
adequately explained that since the eval call does nothing it is that
eval call that would not appear in the equivalent code written by
someone who know what they were doing.

> Uh oh, look out, backpedal!
>
>>>>The amateur, programming by coincidence, writes this code
>>>> without understanding what it does
>
>>> ...I'm pretty fuckin certain that it ADDS...
>
>>Or concatenates.
>
> No I'm pretty sure it's only ADDING in this particular case.

And it is being certain that the + operator will perform addition in
this context that allow the certainty that the eval call will do
nothing.

<snip>
>>> and the whole eval() part, I'm using that to fuck around with
>>> multiple variables whilst assigning them to cut down on
>>> extraneous code.
>
>>OK, this was the point of asking you the question. You are using the
>>eval function to "fuck around with multiple variables whilst assigning
>>them to cut down on extraneous code" are you? Obviously an involved
>>technical process known only to the real "experts" in javascript
>>programming :)
>
> Well last I checked I was the one with the only functioning perfect
> liquid website, so yeah, I guess that does make the expert until
> someone comes along and outmatches my design...boy we might be waitin
> a while though, huh kiddo?

That is certainly true. But expertise in the creation of what you
(alone) term a "functioning prefect liquid website" is not in dispute,
or in demand. The issue under dispute is the real level of expertise in
web technologies that you posses. Javascript is being used as an
illustrative example, and you are demonstrating an incomplete grasp of
the basics and nothing that even comes close to expertise.

<snip>
>>You don't know what the eval function does with a numeric argument, do
>>you? Lets see what the language specification has to say about the
>>eval function's behaviour under the circumstances:-
>>
>><quote cite="ECMA 262, 3rd edition: Section 15.1.2.1">
>>|
>>| 15.1.2.1 eval (x)
>>|
>>| When the eval function is called with one argument x,
>>| the following steps are taken:
>>|
>>| 1. If x is not a string value, return x.
>> ...
>></quote>
>>
>>That's right, it does nothing, NOTHING. Nada, zip, zero, nothing;
>
> Well for doing nothing you seem awfully flustered over it.

Yes, that is the test criteria; does the self proclaimed expert know
that with a non-string type argument the eval function does nothing, and
when they find out are they going to try to justify its use anyway.

>>the argument is returned unaltered.
>
> Well of course it is you fuckin doorknob there's only one
> variable in their example.

It is not an example, it is the specification for the function. eval
only recognises one argument.

> I mean if I type out eval(value); it's not gonna do
> anything.

If - value - is of string type then eval will do something, it will
process that string as a javascript Program and return the result.

> But if I throw in some more variables and a few more
> operands hey we can really start some shit!

You think? If you want to (uselessly) pass additional arguments to the
eval function you need to be throwing in more arguments, not operators
and variables.

Incidentally, "operands" means those upon which operators operate. So in
the context that you use the term it does not mean anything different
form you use of "variables".

> eval(you+are*a-fucking/idiot);

So you have made the expression that is evaluated to give the one
argument to the eval call more complex.

> There ya go, how do ya like that?

It is a more complex example of the first useless employment of the eval
function. Was there a point?

>>That is why the competent javascript programmer would not
>>ever write that expression.
>
> No shit, why would you write an expression that doesn't evaluate
> anything but one variable.

Who has written an expression that doesn't evaluate anything but one
variable (except in the technical sense where all Identifiers are
PrimaryExpressions, and thus a category of expression).

> What are you retarded or do you just not
> comprehend what you're reading?

>>"Cut down on extraneous code"? You have turned (logot+logoc) into
>>eval(logot+logoc) in order to "cut down on extraneous code"?
>
> Try it without the eval, stupid, see what happens.
> Oh hey, it fucks the whole site, fancy that!

You are forgetting I know what happens without trying it. And the
expression - (logot+logoc) - evaluates to the same type and value as
the expression - eval(logot+logoc) - just slightly faster and with less
source code. And if you cannot implement that change and have a working
result you really are pretty useless, you only have to delete 11
occurrences of a four character sequence.

> Must be that UBER programming sixth sense
> of yours, huh?

Your utter incompetence is a more likely explanation under the
circumstances.

> Yeesh, if you weren't such a fuckin MORON you'd be able to see that
> quite plainly simply by noticing the + "px"; tacked onto the end of
> the thing, ya fuckin doorknob!

And if you understood javascript your would be able to see that no such
problem exists.

The expression - (logot+logoc) + "px" - evaluates to exactly the same
value and type as the expression - eval(logot+logoc) + "px" - and
because the order of evaluation of an AdditiveExpression is left to
right the expression - logot + logoc + "px" - also produces the same
result. So it is nearly impossible to see a way of rendering the code
non-functional while removing the eval call. But when the person doing
the modifications in evidently utterly inept I suppose this sort of
outcome is to be expected.

> Obviously to anyone who isn't STUPID I'm using eval to perform
> math on integers that are going to be read as a string once
> it's finished calculating them.

You are at it again. This is your third different justification for the
use of the eval call. And it is as much utter nonsense as both the
previous two. Remember, the eval call does nothing; it returns its
argument unaltered. The math happens before the eval call, and so cannot
be influenced by it, and the type-conversion to a string and
concatenation happen after the eval call has returned. How many ways can
it be said; the eval call does NOTHING. Which is why it cannot be
justified.

>>> WOAH, this programming thing is REALLY complicated!
>
>>It certainly took me a while to get to grips with it. How long it is
>>going to take you remains to be seen.
>
> Boy it seems I'm already light years ahead of you kiddo,

You are deluded.

> you couldn't even figure out why I was using eval()
> fer fuck sake!

I didn't need to figure it out, I know that there is no reason for
performing a function call that does nothing so there is no 'why'. And
the fact that you were making a function call that did nothing told me
with absolute certainty that you did not know why you were doing it
either. And you have confirmed that with your three spurious, divergent
and off the top of your head, explanations.

<snip.
>>And it looks like I have something that you never will have; a real
>>understanding of the technologies needed to implement them.
>
> Including your "real" understanding of eval(x); too, huh? *snicker*

Yes, apparently that too.

> You should have shut yourself the fuck up when you had the chance,
> kiddo, cause now you've been pretty much exposed as a fuckin moron.
> Hell I'm tempted to start xposting into some other programming froups
> so EVERYBODY can get a laugh at you!

comp.lang.javascript would be the obvious choice. There you can expect
to find an informed opinion on the subject eval use, but you wouldn't
dare.

Richard.

[Back to original message]