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

Groups > comp.lang.javascript > #17422

Re: form field/spreadsheet question

Cross-posted to 2 groups.

Show all headers | View raw

On Sun, 02 Dec 2012 21:22:18 +0100, Thomas 'PointedEars' Lahn wrote:

>Wally W.  wrote:
>^^^^^^^^
>Please fix that.

Fix what?


>> On Sun, 02 Dec 2012 19:06:27 +0100, Thomas 'PointedEars' Lahn wrote:
>>> Wally W.  wrote:
>>>> On Sun, 02 Dec 2012 13:55:39 +0100, Luuk wrote:
>>>>> On 02-12-2012 05:22, Jon wrote:
>>>>>> Where can I find an editor/..../.... for Javascript?
>>>>>
>>>>> Notepad.exe, or any other text-editor....
>>>>>
>>>>>> Where can I find an ..../compiler/.... for Javascript?
>>>>>
>>>>> There is no compiler for Javascript,
>>>> 
>>>> That is an oversight in the IT world.
>>>
>>> Strictly speaking, what was stated is correct,
>> 
>> As was my statement.
>
>Most certainly not.

Then it should be easy for you to link to a program that converts HTML
documents with forms and scripting into stand-alone EXE files.

 
>>> because there is no "Javascript" language to begin with:
>>> <http://PointedEars.de/es-matrix>
>> 
>> Your link highlights in incompatibilities between script engines.
>
>I am comparing the language features supported by different ECMAScript 
>implementations there.

Which is irrelevant to what I am wanting.

 
>> A script I develop for my own use in my preferred browser may be
>> useless in someone else's preferred browser.
>
>Correct.  This is why it is important to know where implementations differ 
>and where not, so that appropriate measures can be taken by the Web 
>developer.  I am currently focusing on ECMAScript implementations;
>DOM implementations are another matter altogether (and I will probably 
>investigate them more thoroughly later).

I want it to be able to run *apart from* a browser.


>> With web pages and javascript so prevalent,
>
>There are no "web pages" and there is no "javascript".  As soon as you can 
>accept that, and stop talking like you want to sell something, understanding 
>can begin.

What am I trying to sell? Where do you read that I have a program of
the type I seek?


>> it is an oversight that there is no generally available program to
>> "compile" the pages with *some* version of javascript
>
>Different ECMAScript implementations are not versions of one imagined 
>universally implemented and uniform "javascript" language; they are separate 
>programming languages in their own right (with a common root, most of which 
>is standardized in ECMAScript).

Fine. I don't care about all the variations.

I want *one* version of javascript to debug within a browser, and then
to turn the completed effort (form and scripting) into a stand-alone
EXE file.


>> to a browser-independent EXE file.
>
>You have overlooked the existence of such programs.  

Such as?

>However, such a program 
>would not be overly useful with regard to browsers, 

It isn't intended to be useful with regard to browsers.

It is intended to be useful *apart from* browsers.


>because ECMAScript 
>implementations are scripting languages, which "[are] programming 
>language[s] that [are] used to manipulate, customise, and automate the 
>facilities of an existing system." (ECMAScript Language Specification, 5.1 
>Edition, p. 2).  As such, they are primarily interfacing languages, and APIs 
>differ among browsers.  You cannot avoid that; browser vendors will not let 
>you.  And if you are honest, you would not want to: this competition is 
>*basically* a Good Thing.

What competition?

What I seek doesn't exist.


>>> Loosely speaking it is wrong, though, because ECMAScript source code in
>>> Web browsers and elsewhere is JIT-compiled and _not_ interpreted
>>> verbatim. 
>>> Most of the script engines of ECMAScript implementations compile source
>>> code to bytecode, executed by a Virtual Machine (this applies to
>>> Netscape/Mozilla JavaScript and Microsoft JScript).  Google V8 even JIT-
>>> compiles source code to native machine code, which part of why it is so
>>> fast by comparison.
>> 
>> Which is of no help to one who wants to convert their web page,
>> complete with javascript, to a browser-independent EXE file.
>
>Those people should learn to know what they are doing before they are doing 
>it, and then might be interested in
><https://developer.mozilla.org/en/docs/GRE> pp.

One who wants to convert their web page to an EXE file doesn't want to
*write* the program to do it, they want to *use* the program to feed
their HTML file to a "compiler" and obtain a stand-alone EXE file with
the desired functionality.

Creating such a program is more in the purview of those reading
comp.lang than those in comp.lang.javascript. 

>But that has nothing to do with "web pages" (read: HTML documents) as such.

Again, missing the point for the semantics.

>>>> Spreadsheets are also "interpreted."
>>> Spreadsheets are not a programming language.
>> 
>> Missing the point for the semantics.
>
>I am not sure yet, are you trolling or are you just completely clueless?

Your reading skills appear to be quite narrow.

Everyone doesn't insist on such crisp meanings for every word when
discussing a concept.

When paired with the readiness to insult, the lack of read skill makes
quite a combination.


>> Functions in spreadsheet cells are, in a practical sense which may not
>> meet a purist's definition, "interpreted."
>
>Yes, but that is a different thing.  Functions in spreadsheet cells are a 
>part of an API, which is used with programming languages.

Irrelevant.

The point is that a human-written expression is executed by the CPU.

There is no reason why a javascript statement can't be packaged for
use by a portable engine that is not part of a browser.

There is more than one way to accomplish that: API, byte code, or
for-real compiling. I don't care *how* it is done. I would like
something that *does* it.

>> Javascript operating on forms in a web page can behave similarly to
>> simple, or not-so-simple, spreadsheets.
>
>While that is partially true, you still have no clue what you are talking 
>about.  There are programming languages, and there are APIs that can be used 
>with programming languages.  That is no different with ECMAScript 
>implementations and the DOM API.

Actually, you don't seem to understand the request.


>>>> That didn't stop someone from
>>>> writing a compiler:
>>>> http://en.wikipedia.org/wiki/As_Easy_As
>>>
>>> ISTM you are confusing things.
>>> 
>>>> How many would like a compliable web page that has:
>>>> 1. Embedded javascript
>>>
>>> Meaning what exactly?
>> 
>> For example, this web page could be converted to a stand-alone EXE
>> file with all the functionality of its scripting fully implemented:
>> http://www.pmel.org/unitconv.htm
>
>No, it could not.  The functionality of "the scripting" to be cross-browser 
>would be lost to begin with.

Fine. It doesn't need to be cross-browser when it is in a stand-alone
EXE file.


>>>> 2. A 'save as" capability to write all contents, including entered
>>>> values, to a disk file?
>>> That capability exists already.
>> 
>> Where?
>
>In all script-capable Web browsers.

Not so.

Internet explorer does not save the values entered in this form when
the page is save to the local disk:

http://voltaires.org/tech/eformulas.htm


>>>> 3. An "open file" capability to resume work on or print values in a
>>>> file placed on disk with the "save as" feature mentioned above?
>>> That too.
>> 
>> Where?
>
>Same.

See above.

>>>> I know I would like such a compiler.
>>> I do not think you know what a compiler is or where you are posting to,
>>> though.
>> 
>> I suppose the software to produce CHM ("compiled HTML") files would
>> not meet your definition of "compiler."
>
>That is correct.  Those files need an executable (HTMLHelp.exe & friends) to 
>be displayed, which in turn uses a runtime library, MSHTML.dll.  In short, 
>the browser core.  That library supports JScript, Microsoft's ECMAScript 
>implementation (through JScript*.dll), and so does Internet Explorer, for 
>example, because it is based on MSHTML.dll (which is why I am talking about 
>JScript and the MSHTML DOM and not "javascript in Internet Explorer").
>.CHM files are not executables themselves, and HTML Help certainly is not a 
>programming language.
>
><http://msdn.microsoft.com/en-
>us/library/windows/desktop/ms524402(v=vs.85).aspx>

My purpose was to illustrate another use of the word "compile" beyond
the narrow definition you seem to allow.

>> The "compiler" I would like for web pages with embedded javascript
>> would be similar, but with more features.
>
>Such as?

As listed in my first post.


>> My mention of "embedded javascript" recognizes that web pages do *not*
>> necessarily need to contain javascript. The ideas seems to be anathema
>> to some webmasters, but it is true.
>
>ACK, but your argumentation is inconsistent nevertheless.  You cannot have 
>"embedded javascript" without having "javascript".

Others seem to acknowledge the existence of javascript.

Perhaps it doesn't exist in your world of narrow definitions.

Others are able to perceive and use it just fine.

Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

form field/spreadsheet question "Jon" <no-reply@no-reply.com> - 2012-12-01 23:22 -0500
  Re: form field/spreadsheet question Luuk <luuk@invalid.lan> - 2012-12-02 13:55 +0100
    Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 12:19 -0500
      Re: form field/spreadsheet question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-02 19:06 +0100
        Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 14:29 -0500
          Re: form field/spreadsheet question Denis McMahon <denismfmcmahon@gmail.com> - 2012-12-02 20:10 +0000
            Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 17:18 -0500
          Re: form field/spreadsheet question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-02 21:22 +0100
            Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 17:15 -0500
              Re: form field/spreadsheet question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-12-03 00:29 +0100
                Re: form field/spreadsheet question Wally W. <ww84wa@aim.com> - 2012-12-02 19:55 -0500
                Re: form field/spreadsheet question Dr J R Stockton <reply1249@merlyn.demon.co.uk.invalid> - 2012-12-03 18:30 +0000
                Re: form field/spreadsheet question Andrew Poulos <ap_prog@hotmail.com> - 2012-12-04 11:26 +1100
            Re: form field/spreadsheet question John G Harris <john@nospam.demon.co.uk> - 2012-12-03 20:18 +0000
              Re: form field/spreadsheet question Andrew Poulos <ap_prog@hotmail.com> - 2012-12-04 07:43 +1100
                Re: form field/spreadsheet question John G Harris <john@nospam.demon.co.uk> - 2012-12-04 09:10 +0000
                Re: form field/spreadsheet question Andrew Poulos <ap_prog@hotmail.com> - 2012-12-04 20:31 +1100
                Re: form field/spreadsheet question Scott Sauyet <scott.sauyet@gmail.com> - 2012-12-04 06:15 -0800
                Re: form field/spreadsheet question John G Harris <john@nospam.demon.co.uk> - 2012-12-04 14:34 +0000
  Re: form field/spreadsheet question Martin Leese <please@see.Web.for.e-mail.INVALID> - 2012-12-02 11:27 -0700
    Re: form field/spreadsheet question "Jon" <no-reply@no-reply.com> - 2012-12-02 19:01 -0500
      spreadsheet-to-Javascript translator "Jon" <no-reply@no-reply.com> - 2012-12-02 20:06 -0500
        Re: spreadsheet-to-Javascript translator Patricia Shanahan <pats@acm.org> - 2012-12-03 10:26 -0800
    Re: form field/spreadsheet question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-12-03 02:42 +0000

csiph-web