Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #29361 > unrolled thread

Give alert if form checkbox array is empty

Back to article view | Back to comp.lang.javascript

Contents

  Give alert if form checkbox array is empty Bunyip <bunyip@koalanet.com.au> - 2016-01-20 13:28 +1000
    Re: Give alert if form checkbox array is empty JJ <jj4public@vfemail.net> - 2016-01-20 12:30 +0700
      Re: Give alert if form checkbox array is empty Bunyip <bunyip@koalanet.com.au> - 2016-01-20 17:55 +1000
        Re: Give alert if form checkbox array is empty JJ <jj4public@vfemail.net> - 2016-01-20 19:29 +0700
          Re: Give alert if form checkbox array is empty "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-01-20 13:46 +0100
    Re: Give alert if form checkbox array is empty Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2016-01-20 08:23 +0000
      Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-20 15:52 +0100
        Re: Give alert if form checkbox array is empty Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2016-01-20 15:43 +0000
          Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-20 17:15 +0100
            Re: Give alert if form checkbox array is empty Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-01-20 17:53 +0000
              Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-20 20:39 +0100
                Re: Give alert if form checkbox array is empty Jon Ribbens <jon+usenet@unequivocal.co.uk> - 2016-01-20 22:46 +0000
            Re: Give alert if form checkbox array is empty Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2016-01-21 07:53 +0000
              Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-21 10:52 +0100
                Re: Give alert if form checkbox array is empty Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2016-01-21 10:26 +0000
                  Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-22 00:07 +0100
    Re: Give alert if form checkbox array is empty Stefan Weiss <krewecherl@gmail.com> - 2016-01-20 10:28 +0100
      Re: Give alert if form checkbox array is empty Bunyip <bunyip@koalanet.com.au> - 2016-01-21 08:05 +1000
        Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-21 00:59 +0100
          Re: Give alert if form checkbox array is empty Stefan Weiss <krewecherl@gmail.com> - 2016-01-21 03:17 +0100
            Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-21 08:54 +0100
              Re: Give alert if form checkbox array is empty Stefan Weiss <krewecherl@gmail.com> - 2016-01-21 12:17 +0100
          Re: Give alert if form checkbox array is empty John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-21 14:16 +0000
          Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-21 19:52 -0800
            Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-22 09:48 +0100
              Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-22 10:45 -0800
                Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-23 19:41 +0100
                  Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-24 17:51 -0800
                    Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-25 19:46 +0100
                      Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-27 11:09 -0800
          Re: Give alert if form checkbox array is empty Dr J R Stockton <reply1600@merlyn.demon.co.uk.invalid> - 2016-01-23 22:22 +0000
          Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-27 11:06 -0800
            Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-28 14:46 +0100
              Re: Give alert if form checkbox array is empty Gene Wirchenko <genew@telus.net> - 2016-01-28 10:30 -0800
                Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-28 20:06 +0100
                  Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-28 23:32 -0800
                    Re: Give alert if form checkbox array is empty "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-01-29 09:05 +0100
                      Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-29 06:02 -0800
                    Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-29 20:54 +0100
                  Re: Give alert if form checkbox array is empty John Harris <niam@jghnorth.org.uk.invalid> - 2016-01-29 10:36 +0000
                    Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-09 04:39 +0100
                      Re: Give alert if form checkbox array is empty John Harris <niam@jghnorth.org.uk.invalid> - 2016-02-09 18:07 +0000
                  Re: Give alert if form checkbox array is empty Gene Wirchenko <genew@telus.net> - 2016-01-29 09:32 -0800
                    Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-29 20:34 +0100
                      Re: Give alert if form checkbox array is empty Aleksandro <aleksandro@gmx.com> - 2016-01-29 16:50 -0300
                      Re: Give alert if form checkbox array is empty Stefan Weiss <krewecherl@gmail.com> - 2016-01-30 03:31 +0100
                        Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-30 04:19 +0100
                          Re: Give alert if form checkbox array is empty Stefan Weiss <krewecherl@gmail.com> - 2016-01-30 05:01 +0100
                Re: Give alert if form checkbox array is empty Aleksandro <aleksandro@gmx.com> - 2016-01-28 16:39 -0300
              Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-29 06:04 -0800
                Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-29 20:54 +0100
                  Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-29 14:55 -0800
                    Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-30 04:55 +0100
                      Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-30 15:48 -0800
                        Re: Give alert if form checkbox array is empty Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-31 21:02 +0100
                          Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-01-31 13:08 -0800
                            Re: Give alert if form checkbox array is empty Andrew Poulos <ap_prog@hotmail.com> - 2016-02-01 12:28 +1100
                              Re: Give alert if form checkbox array is empty Scott Sauyet <scott.sauyet@gmail.com> - 2016-02-01 17:58 -0800
    Re: Give alert if form checkbox array is empty "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-01-20 06:25 -0800
    Re: Give alert if form checkbox array is empty Aleksandro <aleksandro@gmx.com> - 2016-01-20 12:54 -0300

Page 3 of 3 — ← Prev page 1 2 [3]

#29584

John Harris wrote:

> […] Thomas 'PointedEars' Lahn […] wrote:
>> Gene Wirchenko wrote:
>>> On Thu, 28 Jan 2016 14:46:44 +0100, Thomas 'PointedEars' Lahn
>>> <PointedEars@web.de> wrote:
>> Attribution _line_, not attribution novel.  Will you ever learn?
>   <snip>
> 
> If Gene is following the British advice on News bodies he is doing the
> right thing.

That’s complete bullshit, or, if you prefer the British expression, utter 
nonsense.

| INTERNET-DRAFT                               Charles H. Lindsey
| Usenet Format Working Group                  University of Manchester
|                                              March 2005
| […]
| Internet-Drafts are draft documents valid for a maximum of six
| months and may be updated, replaced, or obsoleted by other
| documents at any time. It is inappropriate to use Internet-Drafts
| as reference material or to cite them other than as "work in
| progress."

> <https://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.2.2.1>
> 
> If he is following the German advice then he is doing the wrong thing,
> but for the right reason. (To make it work).
>   <https://www.netmeister.org/news/learn2quote.html>

That is evidentially _not_ “the German advice” as the default in Mozilla 
Thunderbird, primarily maintained by a company located in the state of 
California, is a rather short attribution.  But hell freezes over before
you double-check your crazy presumptions.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29586

On Tue, 09 Feb 2016 04:39:54 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>John Harris wrote:
>
>> […] Thomas 'PointedEars' Lahn […] wrote:
>>> Gene Wirchenko wrote:
>>>> On Thu, 28 Jan 2016 14:46:44 +0100, Thomas 'PointedEars' Lahn
>>>> <PointedEars@web.de> wrote:
>>> Attribution _line_, not attribution novel.  Will you ever learn?
>>   <snip>
>> 
>> If Gene is following the British advice on News bodies he is doing the
>> right thing.
>
>That’s complete bullshit, or, if you prefer the British expression, utter 
>nonsense.
  <snip>

The text that I quoted started life as the advice to be given to
contributors to the uk.* news groups. Note the author's address.
That's why it's correct to call it the British advice.


>> If he is following the German advice then he is doing the wrong thing,
>> but for the right reason. (To make it work).
>>   <https://www.netmeister.org/news/learn2quote.html>
>
>That is evidentially _not_ “the German advice” 
  <snip>

That's the document that you, Thomas, always quote, so it is the only
evidence we have.

  John

[toc] | [prev] | [next] | [standalone]

#29485

On Thu, 28 Jan 2016 20:06:14 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

>Gene Wirchenko wrote:
>
>> On Thu, 28 Jan 2016 14:46:44 +0100, Thomas 'PointedEars' Lahn
>> <PointedEars@web.de> wrote:
>
>Attribution _line_, not attribution novel.  Will you ever learn?

     I know what a novel is, and two lines do not qualify.

>>> Scott Sauyet wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>>> Keep in mind that the built-in implementation of an algorithm is
>>>>> naturally always the most efficient one to use as it is, at best,
>>>>> provided in machine code already.
>>>> Proof by statement.
>>> I have already explained why.  It is not my problem if you are not paying
>>> attention and can only come up with apples vs. oranges.
>> 
>>      Sorry, but your reasoning is invalid.
>
>No, it is not.
>
>>      It is quite possible for an implementation to be inefficient.
>
>Yes; nobody debated that.  But AISB that reasoning presupposes that the 
>developers of script engines do not know what they are doing.  Since WLOG 

     Stating that it is possible for an implementation to be
inefficient is not the same as stating that an implementation is
inefficient.

>you do _not_ know what script engine your code will be exposed to, it is not 
>logical to write your code based on either assumption, and *that* reasoning 
>is "invalid" instead.

     One can test a variety of them.

>In addition, AISB, comparing implementations of different algorithms is 
>comparing apples and oranges; it is a fallacious argumentation.  For 
>example, you can use lodash’s _map() instead of Array.prototype.map() and 
>the former can be more efficient than the latter for the cases that _map() 
>supports (at least with regard to execution speed), but you need to be aware 
>that the former is both deficient regarding standards compliance (it does 
>not perform all the steps of the specification algorithm) and does more than 
>the standard implementation does at the same time (it does steps that the 
>specification algorithm does not contain), so in general the former *cannot* 
>be used as a stand-in for the latter.

     In general.  I deal in specific cases.

>>      I would require good reason to not use the built-in
>> implementation rather than coming up with my own, but if the built-in
>> implementation were that bad, it might be worth it.
>
>You cannot not know what you cannot know, and using conditionals in order to 

     I really doubt that it is impossible to learn if I wanted to.

>to tell script engines apart so that you could *perhaps* know that your 
>script is executed by a less efficient implementation regarding a certain 
>use-case (my research – see sig; and yes, I know that it is not up-to-date 
>*yet* – shows that with the exception of JScript you can only *infer* the 
>script engine version, and that knowledge will always be out of date at the 
>time the code is run) is only going to make your script *less* efficient 
>*for execution under all script engines* because you have to run those tests 
>precisely when your code is executed.

     I may well be able to control the execution environment so I
could well know what script engines could be executing the code.

>BTW, it is an oft-neglected fact, which can be seen in this discussion prior 
>to this posting, that the term efficiency in computer science is not limited 
>to execution speed but also has as memory-usage component.  There is runtime 
>efficiency *and* memory efficiency.

     We are quite aware of that.  Why should we belabour the obvious?

     If you are trying to be a pedant, you are not doing a very good
job of it.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#29491

Gene Wirchenko wrote:

> On Thu, 28 Jan 2016 20:06:14 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
>>Gene Wirchenko wrote:
>>> On Thu, 28 Jan 2016 14:46:44 +0100, Thomas 'PointedEars' Lahn
>>> <PointedEars@web.de> wrote:
>>
>>Attribution _line_, not attribution novel.  Will you ever learn?
> 
>      I know what a novel is, and two lines do not qualify.

It is a metaphor for “too long for the common good”.  The point is that it 
makes threads harder to read because if this is repeated or if everyone does 
it you have to read through a lot of superfluous information before you get 
to the good parts of a posting.  It wastes everybody’s time.  There is a 
good example above.  Imagine a few more quotation levels in this way, 
imaging that I had posted an attribution novel too, and you get the picture.

Whenever you are unsure whether you should do something in Usenet, do not do 
those things that likely waste your reader’s time.
 
>>>> Scott Sauyet wrote:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>> Keep in mind that the built-in implementation of an algorithm is
>>>>>> naturally always the most efficient one to use as it is, at best,
>>>>>> provided in machine code already.
>>>>> Proof by statement.
>>>> I have already explained why.  It is not my problem if you are not
>>>> paying attention and can only come up with apples vs. oranges.
>>> 
>>>      Sorry, but your reasoning is invalid.
>>
>>No, it is not.
>>
>>>      It is quite possible for an implementation to be inefficient.
>>
>>Yes; nobody debated that.  But AISB that reasoning presupposes that the
>>developers of script engines do not know what they are doing.  Since WLOG
> 
>      Stating that it is possible for an implementation to be
> inefficient is not the same as stating that an implementation is
> inefficient.

The notion of an inefficient implementation is a misconception to begin 
with.  As I indicated, an implementation can be less efficient (or more 
inefficient) than another, or more efficient (and less inefficient) than 
another.  The point here is that you cannot know what the script engine will 
be, so it is pointless and can be even counterproductive to optimize in that 
direction.  It is, however, _not_ pointless to optimize in the other 
direction: to write your own code so that it implements the most efficient 
algorithm so solve a problem.
 
>>you do _not_ know what script engine your code will be exposed to, it is
>>not logical to write your code based on either assumption, and *that*
>>reasoning is "invalid" instead.
> 
>      One can test a variety of them.

To what end?  Drawing such a conclusion from a subset of script engines – 
and it is *always* a subset – to the general case would be a hasty 
generalization and is fallacious because of that already.  Add to this that 
what you have tested today is literally obsolete tomorrow because of rapid 
releases.  Even and especially with the *same* script engine (but then a 
different version of it).
 
>>In addition, AISB, comparing implementations of different algorithms is
>>comparing apples and oranges; it is a fallacious argumentation.  For
>>example, you can use lodash’s _map() instead of Array.prototype.map() and
>>the former can be more efficient than the latter for the cases that _map()
>>supports (at least with regard to execution speed), but you need to be
>>aware that the former is both deficient regarding standards compliance […] 
>>and does more than the standard implementation does at the same time […],
>>so in general the former *cannot* be used as a stand-in for the latter.
> 
>      In general.  I deal in specific cases.

Not my problem.  The claim, or at least the implication, was a general one.

>>>      I would require good reason to not use the built-in
>>> implementation rather than coming up with my own, but if the built-in
>>> implementation were that bad, it might be worth it.
>>You cannot not know what you cannot know, and using conditionals in order
>>to
> 
>      I really doubt that it is impossible to learn if I wanted to.

That doubt is evidentially not based on rational, but on wishful thinking.  
It is along the same line of thought that people use to justify the umbrella 
term “javascript”.  Ignoring differences does not make them go away.
 
>>to tell script engines apart so that you could *perhaps* know that your
>>script is executed by a less efficient implementation regarding a certain
>>use-case (my research – […] shows that with the exception of JScript you 
>>can only *infer* the script engine version, and that knowledge will always
>>be out of date at the time the code is run) is only going to make your
>>script *less* efficient *for execution under all script engines* because
>>you have to run those tests precisely when your code is executed.
> 
>      I may well be able to control the execution environment

You can to some extent control the execution environment if it is one like 
Node.js.  But without further specification, we are discussing ECMAScript 
implementations in Web browsers here instead.

> so I could well know what script engines could be executing the code.

And then you optimize for each new version of it?  Think twice.
 
>>BTW, it is an oft-neglected fact, which can be seen in this discussion
>>prior to this posting, that the term efficiency in computer science is not
>>limited
>>to execution speed but also has as memory-usage component.  There is
>>runtime efficiency *and* memory efficiency.
> 
>      We are quite aware of that.

I do not think so.  Not once has anyone in this thread mentioned memory 
usage.

>      Why should we belabour the obvious?

If it were obvious to those making the claim, “efficiency” would not have 
been used only to refer to execution speed.
 
>      If you are trying to be a pedant, you are not doing a very good
> job of it.

Ad hominem.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29493

On 29/01/16 16:34, Thomas 'PointedEars' Lahn wrote:
> Gene Wirchenko wrote:
>>      If you are trying to be a pedant, you are not doing a very good
>> job of it.
> 
> Ad hominem.

https://i.imgflip.com/y9jps.jpg

[toc] | [prev] | [next] | [standalone]

#29499

On 01/29/2016 20:34, Thomas 'PointedEars' Lahn wrote:
> Whenever you are unsure whether you should do something in Usenet, do not do 
> those things that likely waste your reader’s time.

hy·poc·ri·sy
/həˈpäkrəsē/


- stefan

[toc] | [prev] | [next] | [standalone]

#29500

Stefan Weiss wrote:

> On 01/29/2016 20:34, Thomas 'PointedEars' Lahn wrote:
>> Whenever you are unsure whether you should do something in Usenet, do not
>> do those things that likely waste your reader’s time.
> 
> hy·poc·ri·sy
> /həˈpäkrəsē/

ad hominem
/ad ˈhɒmɪnɛm/

I said “whenever you are *unsure*”.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29502

On 01/30/2016 04:19, Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> On 01/29/2016 20:34, Thomas 'PointedEars' Lahn wrote:
>>> Whenever you are unsure whether you should do something in Usenet, do not
>>> do those things that likely waste your reader’s time.
>>
>> hy·poc·ri·sy
>> /həˈpäkrəsē/
> 
> ad hominem
> /ad ˈhɒmɪnɛm/

That was intended as a hint to "go look it up", since you're apparently
either unaware of the concept of hypocrisy or how it applies to your advice.

And now I have to tell you to "go look it up" again: this was not an ad
hominem fallacy, it was just a plain old insult. To make it simple,
here's the difference in a nutshell:

    "You are a hypocrite, therefore you are wrong."  →  ad hominem

    "You are a hypocrite."  →  insult


- stefan

[toc] | [prev] | [next] | [standalone]

#29463

On 28/01/16 15:30, Gene Wirchenko wrote:
> On Thu, 28 Jan 2016 14:46:44 +0100, Thomas 'PointedEars' Lahn
> <PointedEars@web.de> wrote:
> 
>> Scott Sauyet wrote:
>>
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Keep in mind that the built-in implementation of an algorithm is
>>>> naturally always the most efficient one to use as it is, at best,
>>>> provided in machine code already.
>>>
>>> Proof by statement.
>>
>> I have already explained why.  It is not my problem if you are not paying 
>> attention and can only come up with apples vs. oranges.
> 
>      Sorry, but your reasoning is invalid.  It is quite possible for
> an implementation to be inefficient.
> 
>      I would require good reason to not use the built-in
> implementation rather than coming up with my own, but if the built-in
> implementation were that bad, it might be worth it.
> 
> Sincerely,
> 
> Gene Wirchenko

Please don't feed the troll.

[toc] | [prev] | [next] | [standalone]

#29477

Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:

>>> Keep in mind that the built-in implementation of an algorithm is
>>> naturally always the most efficient one to use as it is, at best,
>>> provided in machine code already.

>> Proof by statement.

> I have already explained why.  It is not my problem if you are not paying 
> attention and can only come up with apples vs. oranges.

Your opinion is *not* evidence. [1]

  -- Scott

[1] No matter how often your mother tells you it is.

[toc] | [prev] | [next] | [standalone]

#29495

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Scott Sauyet wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Keep in mind that the built-in implementation of an algorithm is
>>>> naturally always the most efficient one to use as it is, at best,
>>>> provided in machine code already.
>>> Proof by statement.
>> I have already explained why.  It is not my problem if you are not paying
>> attention and can only come up with apples vs. oranges.
> 
> Your opinion is *not* evidence. [1]

It is not an opinion.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29498

Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Scott Sauyet wrote:
>>>> Thomas 'PointedEars' Lahn wrote:

>>>>> Keep in mind that the built-in implementation of an algorithm is
>>>>> naturally always the most efficient one to use as it is, at best,
>>>>> provided in machine code already.

>>>> Proof by statement.

>>> I have already explained why.  It is not my problem if you are not paying
>>> attention and can only come up with apples vs. oranges.
 
>> Your opinion is *not* evidence.

> It is not an opinion.

And in a recent post (<3460364.F9DqHdneDT@PointedEars.de>), 

Thomas 'Pointed Ears' Lahn wrote:
| Scott Sauyet wrote:
 
|> Not at all.  Perhaps the author of the code in question is simply a better
|> developer than the one who wrote that part of the script engine. 
| 
| It would seem that your hubris knows no end.

So in the world of Thomas Lahn, my suggestion that there are developers
out there who might write better code than those who happened to write
a specific portion of a browser engine is unremitting hubris, but his
blunt, as of yet unsupported, assertion that the most efficient 
implementation of an algorithm is necessarily the built-in one, is not
mere opinion.

It has to be really lonely stuck in such delusions.

  -- Scott 

[toc] | [prev] | [next] | [standalone]

#29501

Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Scott Sauyet wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Scott Sauyet wrote:
>>>>> Thomas 'PointedEars' Lahn wrote:
>>>>>> Keep in mind that the built-in implementation of an algorithm is
>>>>>> naturally always the most efficient one to use as it is, at best,
>>>>>> provided in machine code already.
>>>>> Proof by statement.
>>>> I have already explained why.  It is not my problem if you are not
>>>> paying attention and can only come up with apples vs. oranges.
>>> Your opinion is *not* evidence.
>> It is not an opinion.
> 
> And in a recent post (<3460364.F9DqHdneDT@PointedEars.de>),
> 
> Thomas 'Pointed Ears' Lahn wrote:
> | Scott Sauyet wrote:
>  
> |> Not at all.  Perhaps the author of the code in question is simply a
> |> better developer than the one who wrote that part of the script engine.
> | 
> | It would seem that your hubris knows no end.
> 
> So in the world of Thomas Lahn, my suggestion that there are developers
> out there who might write better code than those who happened to write
> a specific portion of a browser engine is unremitting hubris, but his
> blunt, as of yet unsupported, assertion that the most efficient
> implementation of an algorithm is necessarily the built-in one, is not
> mere opinion.

We are talking about *scripting* languages and *script* engines here.  AISB, 
*there*, the most efficient implementation of an algorithm – that is, of the 
*same* algorithm – is *necessarily* the built-in one because if you 
implement that algorithm – again, the *same* algorithm – by yourself *in a 
scripting language*, your code has to be parsed and compiled first, and only 
*then* the resulting bytecode or machine code is executed by the (virtual) 
machine, while the built-in code is compiled already and can be executed 
*directly*.  

Also, the built-in code is in several important cases written in such a way 
that it makes the best use of available memory (AISB, it is logical to 
assume that script engine developers know what they are doing and do not 
intentionally leave memory leaks; assuming otherwise, i.e. that script 
engine performance would have a trend to get worse with time and such a 
script engine would *still* prevail to be available for execution, is 
nonsense), while that is not true of script code (one relies on garbage 
collection there and has _not_ full control of memory usage).

We are not talking about milliseconds and kibibytes in specific script 
engines here, but of *overall*, *general* performance.  I am sorry that you 
cannot see that 1 + 1 > 1 truly is self-evident and not an opinion.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29505

Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:

>> So in the world of Thomas Lahn, my suggestion that there are developers
>> out there who might write better code than those who happened to write
>> a specific portion of a browser engine is unremitting hubris, but his
>> blunt, as of yet unsupported, assertion that the most efficient
>> implementation of an algorithm is necessarily the built-in one, is not
>> mere opinion.
 
> We are talking about *scripting* languages and *script* engines here.  AISB, 
> *there*, the most efficient implementation of an algorithm - that is, of the 
> *same* algorithm - is *necessarily* the built-in one because if you 
> implement that algorithm - again, the *same* algorithm - by yourself *in a 
> scripting language*, your code has to be parsed and compiled first, and only 
> *then* the resulting bytecode or machine code is executed by the (virtual) 
> machine, while the built-in code is compiled already and can be executed 
> *directly*.  

The only way your argument makes any sense at all is if you are to 
claim there is only a single possible bytecode version of a given 
algorithm, that by "the *same* algorithm" you suggest byte-for-byte 
identical output. 

In any other case, the fact that one version has to be compiled before 
being run and the other does not implies only a slight handicap to the 
developer of code that competes with a pre-compiled version.  If it 
runs often enough, any slight advantage in speed can overcome the 
headstart gained by not compiling the other.

So is that your contention, that you limit "same algorithm" to code 
generating the same bytecode?  If so, you're certainly using words in 
an unusual manner, which is perhaps unsurprising on USENET.  But 
you're also missing the major point that different engines implement 
the algorithms, sometimes with very different code and very different 
performance characteristics.  But if not, you're spouting nonsense.  
For any substantial bit of logic, the compilation time can easily be 
dwarfed by the running time.

> Also, the built-in code is in several important cases written in such a way 
> that it makes the best use of available memory (AISB, it is logical to 
> assume that script engine developers know what they are doing and do not 
> intentionally leave memory leaks; assuming otherwise, i.e. that script 
> engine performance would have a trend to get worse with time and such a 
> script engine would *still* prevail to be available for execution, is 
> nonsense), while that is not true of script code (one relies on garbage 
> collection there and has _not_ full control of memory usage).

Once again, you brought this up in the context of suggesting that 
Bunyip learn to use "the Array methods introduced with implementations 
of ECMAScript Edition 5 at the latest, in order to not write explicit 
loops where they are not necessary."  Do you contend that changing the 
code in this way would speed up processing or reduce memory 
consumption?

> We are not talking about milliseconds and kibibytes in specific script 
> engines here, but of *overall*, *general* performance.

That sounds like weaseling to me.

If you can't measure it, you should use some word other than 
"performance".


> I am sorry that you cannot see that 1 + 1 > 1 truly is self-evident 
> and not an opinion.

And I'm sorry that you cannot see that you've argued yourself into a 
corner and don't know how to concede gracefully.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#29509

Scott Sauyet wrote:

> The only way your argument makes any sense at all is if you are to
> claim there is only a single possible bytecode version of a given
> algorithm, that by "the *same* algorithm" you suggest byte-for-byte
> identical output. […]

Not at all (bytecode is not even required), and I am tired of trying and 
wasting free time to explain that to you.

EOD

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29510

Thomas 'PointedEars' Lahn wrote:
> Scott Sauyet wrote:

> I am tired of trying and wasting free time to explain that to you.
> 
> EOD

What a shame.  I so much enjoyed watching your pithy _ad hominem_
attacks, the extreme pedantry you use to disguise the fact that
your arguments have no merit, your contumelious browbeating of anyone
who dares to challenge the opinions you masquerade as facts, and, in
fact, the entire part you play on comp.lang.javascript.

The fact remains that you made a contention you were not able to
back up with evidence, tried to argue that it's so self-evident as
to not need support, and finally insulted those who presented 
counter-arguments,  What would you call someone else who did the same?

  -- Scott

[toc] | [prev] | [next] | [standalone]

#29512

On 1/02/2016 8:08 AM, Scott Sauyet wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Scott Sauyet wrote:
>
>> I am tired of trying and wasting free time to explain that to you.
>>
>> EOD
>
> What a shame.  I so much enjoyed watching your pithy _ad hominem_
> attacks, the extreme pedantry you use to disguise the fact that
> your arguments have no merit, your contumelious browbeating of anyone
> who dares to challenge the opinions you masquerade as facts, and, in
> fact, the entire part you play on comp.lang.javascript.

To save others from having to look it up (as I had to) "contumelious" is 
an adjective that refers to behaviour that is "scornful and insulting; 
or, insolent". It's from the Latin word "contumelia" which means "abuse, 
insult".

And "browbeat" means "to intimidate someone, typically into doing 
something, with stern or abusive words".

So wouldn't to contumely browbeat be tautological?

Andrew Poulos

[toc] | [prev] | [next] | [standalone]

#29517

Andrew Poulos wrote:
> Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:
>>> Scott Sauyet wrote:
>>
>>> I am tired of trying and wasting free time to explain that to you.
>>>
>>> EOD
>>
>> What a shame.  I so much enjoyed watching your pithy _ad hominem_
>> attacks, the extreme pedantry you use to disguise the fact that
>> your arguments have no merit, your contumelious browbeating of anyone
>> who dares to challenge the opinions you masquerade as facts, and, in
>> fact, the entire part you play on comp.lang.javascript.
>
> To save others from having to look it up (as I had to) "contumelious" is 
> an adjective that refers to behaviour that is "scornful and insulting; 
> or, insolent". It's from the Latin word "contumelia" which means "abuse, 
> insult".

Thank you.  I didn't know the etymology.  It's a word I ran across twice
in recent months.  I had to look it up as well.  I don't know if its usage 
is increasing or if it was coincidence that I ran into this unusual word 
twice in three weeks, but I figured I'd spread the joy.  It seemed an 
appropriate word to the circumstance, but perhaps someone who understands 
its nuances better might be able to correct me on that.

> And "browbeat" means "to intimidate someone, typically into doing 
> something, with stern or abusive words".
> 
> So wouldn't to contumely browbeat be tautological?

It's a good question, but I don't think so.  You can browbeat with mere
repetition or assertions of dominance, without stooping to insult.  And 
you can be contumelious without attempting intimidation.

Of course combining both is a fine art perfected by online trolls
everywhere.

  -- Scott

[toc] | [prev] | [next] | [standalone]

#29371

On Tuesday, January 19, 2016 at 9:26:12 PM UTC-6, Bunyip wrote:
> I have a form as follows:
> 
> <form enctype="multipart/form-data" method="post" action="index.html"
> name="artwork" onsubmit="return check_artwork_submit()">
> 
> <input type="checkbox" name="subjectType[]" value="Abstract" />
> Abstract<br />
> <input type="checkbox" name="subjectType[]" value="Animal" />
> Animal<br />
> <input type="checkbox" name="subjectType[]" value="Impressionist" />
> Impressionist<br />
> <input type="checkbox" name="subjectType[]" value="Landscape" />
> Landscape
> 
> <input type="submit" value="Add artwork" name="add_artwork">
> </form>
> 
> I need to check that at least one sunbjectType[] has been checked and,
> if not, throw an alert.
> 
> I've tried e.g.:
> 
> var subjectType_count = document.getElementByName('subjectType[]');
> var is_checked = false;
> for (var i = 0; i < subjectType_count; i++) {
>     if (document.artwork.elements['subjectType[]'].checked) {
>         is_checked = true;
>         break;
>     }
> }
> if (is_checked == false) {
>     alert('Please enter the subject type');
> }
> 
> ...and other snippets but none of them throws the alert. Can anybody
> help with this please?

var artForm = document.getElementById("artwork");
artForm.onsubmit = function(e){
    var subjectTypes = Array.from(this.elements["subjectType[]"]);
    if(subjectTypes.some(function(chk){ return chk.checked })) {
        alert("TRUE");
    } else {
        alert("FALSE");
        e.preventDefault();
    }
}

//polyfill where required

[toc] | [prev] | [next] | [standalone]

#29375

On 20/01/16 00:28, Bunyip wrote:
> I have a form as follows:
> 
> <form enctype="multipart/form-data" method="post" action="index.html"
> name="artwork" onsubmit="return check_artwork_submit()">
> 
> <input type="checkbox" name="subjectType[]" value="Abstract" />
> Abstract<br />
> <input type="checkbox" name="subjectType[]" value="Animal" />
> Animal<br />
> <input type="checkbox" name="subjectType[]" value="Impressionist" />
> Impressionist<br />
> <input type="checkbox" name="subjectType[]" value="Landscape" />
> Landscape
> 
> <input type="submit" value="Add artwork" name="add_artwork">
> </form>
> 
> I need to check that at least one sunbjectType[] has been checked and,
> if not, throw an alert.
> 
> I've tried e.g.:
> 
> var subjectType_count = document.getElementByName('subjectType[]');
> var is_checked = false;
> for (var i = 0; i < subjectType_count; i++) {
>     if (document.artwork.elements['subjectType[]'].checked) {
>         is_checked = true;
>         break;
>     }
> }
> if (is_checked == false) {
>     alert('Please enter the subject type');
> }
> 
> ...and other snippets but none of them throws the alert. Can anybody
> help with this please?
> 
> TIA

Apparently nobody (that I've seen) has suggested the document.forms
collection. Check that with an inspector, it might suit your needs I think.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.javascript

csiph-web