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

Groups > comp.programming > #2569

Re: form field/spreadsheet question

Cross-posted to 2 groups.

Followups directed to: comp.lang.javascript

Show all headers | View raw

Wally W.  wrote:

> On Sun, 02 Dec 2012 21:22:18 +0100, Thomas 'PointedEars' Lahn wrote:
>>Wally W.  wrote:
>>^^^^^^^^
>>Please fix that.
> 
> Fix what?

Fix your "name".  Basic politeness requires that you use your real and full 
name (first and last suffices) as I am using mine.  That is, if I should 
consider your postings.

>>> 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.

No, AISB you have a misconception about what a compiler is.

>>>> 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.

No, it is very relevant.  The compiler would have to be of an ECMAScript 
implementation that compiles source code to native machine code, and then 
the program will be limited to the features of that particular 
implementation, and to the features of the particular runtime environment 
provided or emulated by the executable, as opposed to a cross-browser Web 
application.

>>> 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.

Which, AISB, is not feasible.  You will have to have some kind of runtime 
environment to make use of an ECMAScript implementation.  For crying out 
loud, without a runtime environment not even basic input and output is 
possible.  Where do you think window.alert() or console.log() come from?  
Not from the programming language (although that was different in Netscape 
JavaScript, versions 1.0 to 1.3.)

>>> 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?

You talk as if you were trying to sell me/us some Web application while 
obviously not knowing what you talking about.  You need to be strong now: 
You are preaching to the choir there as I/we do know what I/we are talking 
about.

>>> 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.

You don't get it, do you?

>> 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.

How so?  The runtime environment would have to be the equivalent of a 
browser, like XULRunner.

>> 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?

Among browser vendors.

> What I seek doesn't exist.

You are not very clear about what you seek, which might have to do with the 
fact that you do not understand the underlying technology.  And I am getting 
the impression that I am wasting my time here.

Will you *please* at least stop that mindless crossposting?  F'up2 cljs set 
*again*.

>>> 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.

Maybe in comp.lang.misc, but not in comp.programming.

>>But that has nothing to do with "web pages" (read: HTML documents) as
>>such.
> 
> Again, missing the point for the semantics.

Score adjusted.

>>> 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.

Actually, you don't seem to understand that you are way off-topic.  This is 
not the North Pole, and I/we am/are not Santa Claus for lusers.  If you are 
not smart enough to hack it yourself, or find it yourself, and are not 
willing to learn how to hack it or find it, go away.  We will both be better 
off without each another.

>>>>> 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

A pity.  But then I never said that it would suffice to select "Save As" 
from the "File" menu, did I?  We are in comp.lang.javascript (well, most of 
us) here, after all.  Transfer of learning, please …

>>>>> 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.

Which is irrelevant in newsgroups dealing with programming.  Here we 
understand a compiler to be a program that transforms code into another 
executable form, not merely one that compacts code.
 
>>> 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.

I have no time and could not care less to re-read the whole discussion.
I have better things to do than considering your petty requests (for 
example, I might just be thinking about writing the software you are looking 
for).  I have asked you a simple question and if you are not willing to 
answer it, that is your problem and your loss.

>>> 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.

There are many people in this field who do not know what they are talking 
about (but think they do).  But that is beside the point.

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

Or perhaps I am one of the few who know what they are talking about.
 
> Others are able to perceive and use it just fine.

Let's eat sh*t, because a million flies can't be wrong?

-- 
PointedEars

Back to comp.programming | 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 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 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